코딩 AI, 일당백 알바생은 뽑았는데 사수는 여전히 나입니다

1. “이 코드, 제가 짠 게 아닙니다”

며칠 전, 동료의 다급한 호출을 받았습니다. 사용자가 몰리는 특정 페이지의 속도가 갑자기 느려졌다는 겁니다. 코드를 뜯어보니 범인은 데이터베이스를 호출하는 로직이었습니다. 언뜻 보기엔 멀쩡했습니다. 필요한 데이터를 가져와 순서대로 보여주는, 교과서 같은 코드였죠. 그런데 자세히 보니 이상했습니다. 목록에 보여줄 10개의 데이터를 위해, 데이터베이스를 10번이나 따로따로 호출하고 있었습니다. 식당에서 손님 10명의 주문을 받으려고 주방에 10번 뛰어 들어가는 꼴입니다. 당연히 느릴 수밖에요.

범인을 찾아낸 동료가 멋쩍게 웃으며 말했습니다. “이 부분, 제가 안 짰어요. 코파일럿한테 시켰더니 이렇게 만들어주더라고요.” 코파일럿은 깃허브가 만든 AI 코딩 보조 도구입니다. 개발자가 주석이나 코드 몇 줄을 입력하면, 다음 코드를 알아서 완성해 줍니다. 저도 매일 쓰는 편리한 도구입니다. 하지만 이런 식의 ‘숨은 지뢰’를 종종 만들어냅니다. AI는 ‘데이터를 가져와 목록으로 보여준다’는 명령을 글자 그대로 이행했을 뿐, 그게 서버에 얼마나 부담을 주는지, 더 효율적인 방법(가령, 한 번의 호출로 10개 데이터를 모두 가져오는 것)이 있는지는 전혀 고려하지 않은 겁니다.

결국 우리는 AI가 만든 코드를 사람이 다시 고쳐 써야 했습니다. 코드를 ‘생산’하는 시간은 단 몇 초였을지 몰라도, 그 코드가 일으킨 문제를 ‘해결’하는 데는 반나절이 걸렸습니다. AI 코딩 도구가 개발 현장을 바꾸고 있다는 건 명백한 사실입니다. 하지만 그 변화의 실체는 ‘개발자 없이 AI가 알아서 프로그램을 뚝딱 만든다’는 식의 장밋빛 전망과는 거리가 멉니다. 오히려 우리는 더 교활하고 까다로운 문제들과 씨름하게 됐습니다.

2. AI는 어떻게 코드를 ‘만들어’낼까: 천재적인 암기왕의 한계

많은 분들이 AI가 정말로 ‘이해’하고 ‘사고’해서 코드를 짠다고 생각합니다. 반은 맞고 반은 틀린 이야기입니다. 현재의 코딩 AI들은 대부분 LLM(Large Language Model)이라는 기술에 기반합니다. 쉽게 말해, ‘사람 말을 흉내 내 엄청나게 많은 텍스트를 학습한 문장 생성 AI’입니다. 인터넷에 공개된 수십억 줄의 코드를 통째로 외운 ‘천재적인 암기왕’이라고 생각하면 쉽습니다.

LLM의 작동 방식은 확률 게임에 가깝습니다. 우리가 “데이터베이스에서 사용자 정보를 가져오는 코드를 짜줘”라고 명령하면, AI는 자신이 학습한 방대한 코드 속에서 이 문장 다음에 나올 확률이 가장 높은 코드 조각들을 순서대로 조합해 제시합니다. 마치 우리가 “동해물과 백두산이…” 다음에는 자연스럽게 “마르고 닳도록”이 나올 것을 아는 것과 비슷합니다. 워낙 많은 모범 답안을 외우고 있어서, 대부분의 경우 꽤 그럴듯한 코드를 내놓습니다.

하지만 핵심은 여기에 있습니다. AI는 코드의 ‘의미’나 ‘맥락’을 이해하지 못합니다. 그저 패턴을 흉내 낼 뿐입니다.

• 비유하자면, AI는 주방의 모든 레시피를 달달 외우고 있는 요리사와 같습니다. ‘계란 프라이 레시피’를 달라고 하면 완벽한 레시피를 즉시 내놓습니다. 하지만 ‘기름이 다 떨어졌는데 아침 식사로 뭘 만들 수 있을까?’라고 물으면 답하지 못합니다. 레시피에 없는 ‘상황’과 ‘제약 조건’을 이해하고 대안을 찾는 창의적 문제 해결 능력이 없기 때문입니다.
• 앞서 동료의 사례에서 AI가 비효율적인 코드를 만든 이유도 마찬가지입니다. AI의 학습 데이터에는 ‘하나씩 반복해서 처리하는’ 패턴의 코드가 많았을 것이고, AI는 그저 그 패턴을 충실히 따른 것뿐입니다. 이것이 시스템 전체의 성능에 어떤 영향을 미칠지는 AI의 고려사항이 아닙니다.

이것이 바로 코드 ‘생성(Generation)’과 소프트웨어 ‘개발(Development)’ 사이의 거대한 간극입니다. AI는 코드 생성의 달인이지만, 좋은 소프트웨어를 개발하는 데 필요한 전체적인 그림을 보지 못합니다.

3. 데자뷔: 30년 전에도 ‘코드 없는 개발’을 꿈꿨다

현재의 AI 열풍을 보고 있으면 1980년대와 90년대의 풍경이 떠오릅니다. 바로 ‘4세대 언어(4GL)’와 ‘CASE(Computer-Aided Software Engineering) 도구’의 시대입니다.

당시에도 개발자 부족과 소프트웨어 개발의 복잡성은 큰 골칫거리였습니다. 그래서 업계는 야심 찬 해결책을 내놓았습니다. 복잡한 코딩 없이, 사람이 쓰는 말에 가까운 쉬운 언어(4GL)로 원하는 기능을 명시하거나, 설계도를 그리면(CASE) 컴퓨터가 알아서 코드를 만들어주는 세상을 꿈꿨습니다. ‘개발의 민주화’, ‘생산성의 비약적 향상’ 같은 구호도 지금과 판박이였습니다.

결과는 어땠을까요? 절반의 성공, 절반의 실패로 끝났습니다. 이 도구들은 특정 영역에서는 분명 유용했습니다. 예를 들어, 기업 내부의 단순한 데이터베이스 관리 화면이나 정형화된 보고서를 만드는 데는 탁월한 성능을 보였습니다. 반복적이고 예측 가능한 작업의 자동화에는 성공한 셈입니다.

하지만 복잡하고, 독창적이며, 끊임없이 변하는 요구사항을 가진 ‘진짜’ 소프트웨어를 만드는 데는 처참히 실패했습니다. 이유는 간단합니다.

1. 유연성 부족: 도구가 정해놓은 틀 안에서만 작동했습니다. 틀을 조금이라도 벗어나는 기능을 구현하려면, 결국 개발자가 다시 날것의 코드를 만져야 했습니다. 오히려 도구가 생성한 복잡한 코드를 해독하느라 일이 두 배로 늘기도 했습니다.
2. 성능 문제: 자동 생성된 코드는 사람이 직접 짠 코드보다 비효율적이고 무거운 경우가 많았습니다. 간단한 장난감을 만들 때는 문제가 없지만, 수만 명이 사용하는 서비스를 만들기에는 역부족이었습니다.
3. ‘추상화의 누수(Leaky Abstraction)’: 아무리 도구로 세부 사항을 감춰도, 결국 개발자는 그 밑단에서 무슨 일이 벌어지는지 알아야만 했습니다. 문제가 터졌을 때 원인을 찾으려면, 자동 생성된 코드의 내부까지 파고들어야 했기 때문입니다.

AI 코딩 에이전트는 4GL이나 CASE 도구보다 훨씬 강력하고 유연합니다. 하지만 본질적으로 같은 한계를 공유합니다. ‘무엇을 만들지’ 명확히 지정해주면 그럴듯한 결과물을 내놓지만, 그 ‘무엇’을 정의하고, 여러 결과물을 엮어 하나의 ‘제품’으로 만들고, 예상치 못한 문제를 해결하는 영역에서는 여전히 인간의 개입이 필수적입니다. 역사는 반복됩니다. 도구만 바뀌었을 뿐입니다.

4. 코드 더미와 소프트웨어 제품의 차이

AI가 쓴 코드의 양이 늘어나는 것과, 우리가 쓸 수 있는 소프트웨어가 많아지는 것은 전혀 다른 이야기입니다. 집을 짓는 데 비유해 봅시다. AI는 벽돌, 창문, 문짝 같은 개별 부품을 세상에서 가장 빨리, 가장 많이 만들어내는 공장과 같습니다. 하지만 이 부품들을 모아 실제 사람이 살 수 있는 집을 짓는 것은 전혀 다른 차원의 일입니다.

소프트웨어 개발도 마찬가지입니다. AI가 생성한 코드 조각들은 아직 ‘제품’이 아닌 ‘재료’에 불과합니다. 이 재료들을 엮어 하나의 완성된 제품으로 만드는 ‘마지막 1마일(Last Mile)’에는 다음과 같은 인간의 고유한 역량이 필요합니다.

표에서 보듯, AI는 속도와 개별 기능 구현에서는 인간을 압도하지만, 전체를 보고 판단하는 영역에서는 명백한 한계를 보입니다.

• 첫째, 아키텍처 설계입니다. 어떤 기능을 어디에 배치할지, 데이터는 어떻게 흘러가게 할지, 미래의 확장을 고려해 어떤 구조를 택할지 결정하는 일입니다. 이는 집의 설계도를 그리는 건축가의 역할이며, 현재 AI는 해내지 못합니다. AI에게 “쇼핑몰 만들어줘”라고 하면, 그럴듯한 로그인 기능, 상품 목록 기능 코드는 각각 만들어낼 수 있습니다. 하지만 이 기능들이 서로 어떻게 맞물려야 효율적으로 작동하는지에 대한 청사진은 제시하지 못합니다.
• 둘째, 요구사항 분석입니다. 뛰어난 개발자는 고객이나 기획자가 “A라는 버튼을 만들어주세요”라고 할 때, 곧이곧대로 만들지 않습니다. “왜 그 버튼이 필요하신가요?”라고 되물어 진짜 문제를 파악하고, 더 나은 해결책 B나 C를 제안합니다. AI는 이런 ‘왜’라는 질문을 던질 수 없습니다. 주어진 명령을 수행하는 충실한 하인일 뿐, 목표를 함께 고민하는 파트너가 아닙니다.
• 셋째, 기술 부채(Technical Debt) 관리입니다. 기술 부채란 ‘지금 당장 빠른 길을 택하느라 미래에 치러야 할 비용’을 뜻합니다. 가령, 앞서 언급한 비효율적인 데이터베이스 호출 코드가 바로 기술 부채입니다. 당장 기능은 돌아가지만, 나중에 시스템 전체의 발목을 잡습니다. AI는 속도를 우선시하기에 이런 기술 부채를 남발하는 경향이 있습니다. 이 부채를 갚고, 코드를 건강하게 유지하는 것은 전적으로 인간 개발자의 몫입니다.

결국 AI는 ‘코드 작성’이라는 행위의 비용을 극적으로 낮췄지만, 그 코드를 검토하고, 통합하고, 책임지는 비용은 오히려 높이고 있는 셈입니다.

5. 흔한 오해 두 가지 바로잡기

AI 코딩 도구를 둘러싼 장밋빛 전망 속에는 우리가 경계해야 할 두 가지 흔한 오해가 있습니다.

첫 번째 오해: “AI가 개발자를 대체할 것이다.”

결론부터 말하면, AI는 ‘어중간한’ 개발자를 대체할 뿐, ‘뛰어난’ 개발자의 가치는 오히려 더 높아질 겁니다. AI의 등장은 개발자에게 요구되는 역량의 기준을 상향 평준화시킵니다. 과거에는 단순히 문법에 맞춰 코드를 빨리 짜는 능력이 중요했다면, 이제 그런 일은 AI가 더 잘합니다.

이제 개발자의 핵심 역량은 ‘코딩’에서 ‘판단’으로 이동합니다.

• AI가 생성한 여러 코드 후보 중 어떤 것이 가장 효율적이고 안전한지 판단하는 능력
• 이 코드를 시스템의 어느 부분에, 어떤 방식으로 통합해야 할지 설계하는 능력
• AI가 만든 코드에서 발생한 미묘한 버그의 근본 원인을 찾아 해결하는 능력

이는 마치 계산기가 등장했다고 해서 수학자의 가치가 떨어지지 않은 것과 같습니다. 단순 계산은 기계에 맡기고, 수학자는 더 고차원적인 문제 해결에 집중하게 된 것처럼 말입니다. 개발자의 일은 ‘손으로 코딩하는 사람’에서 ‘AI라는 강력한 도구를 지휘하는 설계자이자 품질 관리자’로 진화하고 있습니다.

두 번째 오해: “코드 생산량이 늘면 소프트웨어 생산량도 는다.”

이는 전형적인 양과 질의 혼동입니다. 하루에 1만 줄의 코드를 쏟아낸다고 해서 1천 줄의 코드를 짠 날보다 10배 더 많은 일을 한 것이 아닙니다. 오히려 그 1만 줄의 코드가 서로 얽히고설켜 유지보수 불가능한 ‘스파게티 코드’라면, 생산성은 마이너스입니다.

소프트웨어 개발의 진짜 병목은 코드 입력 속도가 아닙니다. 진짜 병목은 ‘생각하는 시간’입니다. 무엇을 만들어야 할지 고민하고, 어떻게 만들지 설계하고, 제대로 만들어졌는지 테스트하고, 동료들과 소통하고 합의하는 시간이 전체 프로젝트의 90%를 차지합니다. 코드를 쓰는 시간은 극히 일부입니다. AI는 이 일부를 단축시켜줄 뿐, 가장 중요하고 오래 걸리는 ‘생각의 병목’은 해결해주지 못합니다.

6. 결국 ‘판단의 값’이 모든 것을 결정한다

결론은 의외로 간단합니다. AI 시대에 개발자의 몸값은 떨어지는 게 아니라, 특정 역량을 가진 개발자의 몸값이 폭등하게 될 겁니다. 바로 ‘판단’을 내리는 역량입니다.

코드를 생성하는 비용이 AI 덕분에 거의 0에 가까워지고 있습니다. 누구나 아이디어만 있으면 그럴듯한 코드 조각을 몇 초 만에 얻을 수 있습니다. 공급이 넘쳐나면 가치는 떨어지는 법, 이제 코드 자체는 더 이상 귀하지 않습니다.

그렇다면 무엇이 귀해질까요? 바로 그 수많은 코드 조각들 앞에서 올바른 ‘선택’과 ‘결정’을 내리는 능력, 즉 ‘판단의 값(Value of Judgment)’입니다.

• 이 기능은 정말 우리에게 필요한가?
• AI가 제안한 5가지 방법 중 어떤 것이 우리 시스템에 가장 적합한가?
• 이 코드는 1년 뒤에도 유지보수할 수 있는 형태인가?
• 지금의 빠른 구현과 미래의 안정성 사이에서 어떤 절충안을 택해야 하는가?

이런 질문에 답하는 능력은 AI가 줄 수 없습니다. 수많은 성공과 실패의 경험, 시스템 전반에 대한 깊은 이해, 비즈니스 목표와의 연계까지 고민하는 통찰력에서 나옵니다. AI가 강력한 조수 역할을 해줄수록, 이런 판단을 내리는 ‘사수’의 역할은 더욱 중요해지고 그 가치는 천정부지로 솟을 겁니다.

따라서 지금 프로그래밍에 입문하는 분이나 주니어 개발자라면, 단순히 코딩 기술을 익히는 데서 멈춰선 안 됩니다. 오히려 한발 더 나아가야 합니다. 내가 만들고 있는 소프트웨어의 전체 구조를 그려보고, 내가 짠 코드가 다른 부분에 어떤 영향을 미칠지 상상하고, 더 나은 설계를 끊임없이 고민하는 훈련을 해야 합니다. AI를 부릴 수 있는 ‘판단력 있는 시니어’가 되는 길, 그것이 AI 시대에 살아남는 유일한 방법입니다.

7. 독자가 던질 법한 질문들

Q. 하지만 앞으로 AI가 더 발전해서 아키텍처 설계나 요구사항 분석까지 다 하는 ‘완전체’가 되지 않을까요? 소설 같은 이야기일까요?

A. 언젠가는 가능할지도 모릅니다. 하지만 그것은 우리가 ‘강인공지능(AGI)’이라고 부르는, 인간과 동등하거나 뛰어넘는 지능체의 등장을 의미합니다. 이는 현재의 LLM과는 차원이 다른 기술적 도약이며, 실현된다면 개발자 직군뿐 아니라 인류 사회 전체의 근간을 바꿀 사건입니다. 지금 당장 3~5년 내의 현실적인 변화를 이야기하는 맥락에서, ‘완전체 코딩 AI’를 걱정하는 것은 19세기 마부들이 자동차의 등장을 걱정하는 대신 순간이동 기술을 두려워하는 것과 비슷합니다. 우리는 눈앞의 변화에 먼저 적응해야 합니다.

Q. 그렇다면 주니어 개발자로서 코딩 공부보다 프롬프트 엔지니어링(AI에게 질문을 잘하는 기술)을 더 열심히 배워야 할까요?

A. 절대 그렇지 않습니다. 오히려 그 반대입니다. 코딩의 기초가 부실하면 AI가 생성한 코드가 좋은 코드인지 나쁜 코드인지조차 판단할 수 없습니다. 이는 마치 영어를 전혀 모르는 사람이 번역기만 믿고 중요한 비즈니스 계약서를 검토하려는 것과 같습니다. 번역기가 미묘한 뉘앙스를 틀리게 번역해도 알아챌 방법이 없습니다. 코딩의 기본 원리, 자료구조, 알고리즘, 네트워크, 데이터베이스에 대한 깊은 이해가 있어야만 AI를 유능한 부사수로 부릴 수 있습니다. 프롬프트 엔지니어링은 그 위에 더해지는 양념 같은 기술이지, 주춧돌이 될 수는 없습니다.

Q. 저희 회사에서는 개발 인력을 줄이고 AI 도구를 도입해 비용을 절감하자는 이야기가 나옵니다. 정말 효과적인 방법일까요?

A. 단기적으로는 비용이 줄고 코드 생산량이 늘어나는 것처럼 보일 수 있습니다. 하지만 이는 매우 위험한 착시효과일 가능성이 높습니다. 경험 없는 인력이 AI를 이용해 마구 찍어낸 코드는 앞서 말한 ‘기술 부채’를 기하급수적으로 쌓게 됩니다. 결국 1년 뒤, 시스템은 누구도 손댈 수 없는 괴물이 되어 있을 것이고, 그 재앙을 수습하기 위해 남은 소수의 시니어 개발자들은 번아웃에 시달리게 될 겁니다. 이는 경험 많은 셰프들을 해고하고 주방에 최신형 전자레인지를 들여놓는 것과 같습니다. 음식은 빨리 나오겠지만, 식당은 오래가지 못할 겁니다. AI는 인력을 대체하는 수단이 아니라, 뛰어난 인력의 역량을 증폭시키는 도구로 활용할 때 가장 큰 가치를 발휘합니다.