🤖 AI가 코드의 80%를 짠다면, 개발자는 뭘 해야 할까?

 

AI 코딩의 시대, 달라진 개발자의 역할

요즘 개발 커뮤니티에서 화제가 되고 있는 이야기가 있어요. 테슬라의 AI 책임자였던 안드레이 카파시가 이런 말을 했거든요. "이제 코딩의 80%는 AI 에이전트가 하고, 나는 20%만 손보면 된다. 사실상 영어로 프로그래밍하고 있다"고요.

불과 몇 주 만에 이런 변화가 일어났다니, 정말 놀라운 속도죠. Claude Code를 만든 보리스 체르니는 더 극단적이에요. "우리 팀 코드의 100%가 Claude Code와 Opus 4.5로 작성됩니다. 저는 2개월 넘게 손으로 코드를 한 줄도 안 써요"라고 말할 정도니까요.

최근 5,000명의 개발자를 대상으로 한 설문조사를 보면, 44%가 이제 손으로 코드를 10% 미만으로만 작성한다고 답했어요. 또 26%는 10~50% 정도만 직접 쓴다고 하고요. 이미 임계점을 넘어선 거죠. 하지만 여기서 중요한 건, 문제가 사라진 게 아니라 '이동'했다는 점이에요.

실수의 종류가 완전히 바뀌었어요

예전 AI는 문법 오류 같은 걸 냈다면, 지금은 개념적 실수를 해요. 마치 시간에 쫓기는 주니어 개발자가 저지를 법한 실수들이죠.

카파시가 정리한 대로, 지금 AI가 저지르는 실수들은 이래요. 초반에 뭔가를 잘못 이해하고, 그 위에 기능을 계속 쌓아올려요. 5개 PR을 만들고 나서야 알아채는데, 이미 아키텍처가 굳어버린 뒤죠.

또 AI는 자유롭게 놔두면 끝없이 복잡하게 만들어요. 100줄이면 충분한 걸 1,000줄짜리 정교한 클래스 구조로 만들어버리죠. "그냥 간단하게 하면 안 돼?"라고 물으면 "물론이죠!"라며 바로 단순화해요. 처음부터 유지보수성보다는 '포괄적으로 보이는 것'을 우선시하는 거예요.

정리를 안 하는 것도 문제예요. 옛날 코드가 그대로 남고, 주석은 부작용으로 사라지고, 제대로 이해 못 한 코드도 근처에 있다는 이유로 건드려요. 게다가 너무 순종적이에요. "정말 그렇게 할까요?"라거나 "이건 고려해보셨어요?" 같은 반문 없이, 당신이 설명한 대로 열정적으로 실행해요. 설명이 불완전하거나 모순되어도요.

최근 조사 데이터를 보면 흥미로운 지점이 있어요. 개발자의 48%만이 AI가 작성한 코드를 커밋 전에 일관되게 체크한다고 해요. 그런데 38%는 AI가 생성한 로직을 리뷰하는 게 사람이 쓴 코드를 리뷰하는 것보다 오히려 더 힘들다고 답했어요. 우리는 더 빠르게 코드를 만들지만, 기술 부채는 더 빨리 쌓이고 있는 셈이죠.

이해 부채라는 보이지 않는 비용

코드를 작성하는 능력과 읽는 능력은 다른 거예요. 직접 쓰는 능력이 녹슬어도, 읽고 리뷰하는 건 어느 정도 할 수 있죠. 하지만 리뷰가 그냥 '도장 찍기'로 전락하는 순간이 와요.

누군가 이걸 완벽하게 표현한 용어를 만들었어요. '이해 부채'라고요. LLM이 한 방에 뭔가를 만들어냈는데 작동하는 것 같으면, 그냥 넘어가고 싶은 유혹이 생기죠. 이게 교묘한 부분이에요.

AI 에이전트는 지치지 않아요. 흔들림 없는 자신감으로 구현을 계속 밀어붙여요. 코드는 그럴듯해 보이고, 테스트는 통과하고, 출시 압박은 있고. 그래서 넘어가는 거죠. 시간이 지나면 자기 코드베이스인데도 이해가 점점 덜 되는 상황이 와요.

요코 리라는 분이 이 중독 루프를 완벽하게 표현했어요. "AI 에이전트가 멋진 기능을 구현했는데 10%만 틀렸어요. '5분만 프롬프트 더 주면 고칠 수 있겠는데'라고 생각하죠. 그게 5시간 전이에요."

항상 거의 다 된 것 같아요. 마지막 10%가 손에 잡힐 듯해요. 프롬프트 한 번만 더. 반복 한 번만 더. 이 심리적 갈고리는 진짜예요.

다른 분은 이렇게 말했어요. "대부분의 시간을 AI 에이전트 베이비시터로 보내요. AGI 느낌은 확실한데, 미시 관리 세금도 진짜예요. 더 이상 코딩이 아니라 감독이에요. 지켜보고, 방향 바꿔주고. 다른 종류의 피곤함이죠."

위험한 건, 더 이상 처음부터 작성할 수 없는 코드를 리뷰하는 게 너무 쉽다는 거예요. '읽는' 능력이 AI의 '출력' 능력만큼 성장하지 않으면, 더 이상 엔지니어링이 아니에요. 그냥 희망사항인 거죠.

생산성 역설: 코드는 많은데 처리량은 그대로

Faros AI와 구글 DORA 리포트의 데이터가 흥미로워요. AI를 많이 쓰는 팀이 98% 더 많은 PR을 머지했는데, 같은 팀의 리뷰 시간은 91% 폭증했어요. 평균 PR 크기는 154% 증가했고요. 코드 리뷰가 새로운 병목이 된 거죠.

아틀라시안의 2025년 설문조사를 보면 역설이 확연해요. AI 쓰는 개발자 99%가 주당 10시간 이상을 절약한다고 했는데, 대부분이 전체 업무량은 줄지 않았다고 답했어요. 코드 작성으로 절약한 시간이 조직적 마찰로 소비됐어요. 더 많은 컨텍스트 전환, 더 많은 조율 오버헤드, 더 많은 변경 사항 관리 같은 거죠.

차는 더 빨라졌는데, 도로가 더 막힌 셈이에요. 우리는 더 적게 쓰는 게 아니라, 훨씬 더 많이 쓰고 있어요. 그리고 누군가는 여전히 그걸 대부분 이해해야 하고요.

80/20이 실제로 작동하는 곳

몇 가지 맥락에서는 실제로 작동해요. 모든 걸 제어하는 개인 프로젝트, "충분히 좋음"이 정말 충분한 MVP, 레거시 제약 없는 그린필드의 스타트업, 이해 부채가 관리 가능하게 유지되는 작은 팀 같은 거죠.

이런 환경에서는 AI 에이전트의 약점이 덜 중요해요. 빠르게 스캐폴딩하고, 공격적으로 리팩토링하고, 정치적 마찰 없이 코드를 버릴 수 있어요. 반복 속도가 가끔의 잘못된 방향보다 중요하죠.

복잡한 불변성을 가진 성숙한 코드베이스에서는 계산이 역전돼요. AI 에이전트는 자기가 모르는 걸 몰라요. 암묵적 규칙을 직관할 수 없어요. 자신감은 컨텍스트 이해와 반비례하고요.

누군가 제가 돌려 말하던 명백한 걸 지적했어요. 처음 90%는 쉬울 수 있지만, 마지막 10%는 오래 걸릴 수 있다고요. 90% 정확도는 미션 크리티컬하지 않은 것엔 괜찮아요. 실제로 중요한 부분에는 전혀 충분하지 않죠. 자율주행차는 잘 작동하다가 갑자기 안 돼요. 그래서 L2는 어디나 있지만 L4는 여전히 대부분 허상이고요.

비엔지니어에게는 벽이 더 낮지만 여전히 실재해요. AI Studio, v0, Bolt 같은 도구가 스케치를 즉시 작동하는 프로토타입으로 바꿔줘요. 하지만 그 프로토타입을 프로덕션으로 강화하는 것, 규모의 실제 사용자 데이터 처리, 보안과 컴플라이언스 보장은 여전히 엔지니어링 기본기가 필요해요.

명령형에서 선언형으로: 진짜 레버리지

레버리지에 대한 카파시의 관찰이 핵심을 찌르고 있어요. "LLM은 특정 목표를 충족할 때까지 반복하는 데 예외적으로 뛰어나고, 여기서 대부분의 'AGI 느낌' 마법이 발견됩니다."

명령형에서 선언형 개발로의 전환이죠. 옛날 모델은 "X를 받아서 Y를 반환하는 함수를 써. 이 라이브러리 써"였다면, 새 모델은 "여기 요구사항이 있어. 통과해야 할 테스트가 여기 있어. 성공 기준이 여기야. 알아서 해봐"예요.

이게 작동하는 이유는 AI 에이전트가 절대 의기소침해지지 않기 때문이에요. 끊임없이 반복해요. 목적지를 명확히 지정하면, 30번 실패해도 거기 도착해요.

작동하는 패턴들이 있어요. 테스트를 먼저 쓰고, 통과할 때까지 AI가 반복하게 해요. MCP를 통해 브라우저에 연결하고, 시각적으로 동작을 검증하게 해요. 순진하게 올바른 버전을 구현하고, 정확성을 유지하며 최적화해요.

하지만 이건 성공 기준이 실제로 올바를 때만 작동해요. 쓰레기가 들어가면 쓰레기가 나와요. 이 접근으로 성공하는 개발자들은 시간의 70%를 문제 정의와 검증 전략에, 30%를 실행에 써요. 전통적 개발과 비율이 역전됐지만, 총 시간은 극적으로 줄었어요.

슬랍포칼립스 문제

카파시가 경고했어요. "2026년을 깃허브, 서브스택, arXiv 그리고 일반적으로 모든 디지털 미디어 전반의 슬랍포칼립스 해로 대비하고 있습니다." 슬랍포칼립스란 저품질 콘텐츠가 범람하는 현상을 말해요.

우려는 단순해요. 누구나 임의로 큰 볼륨의 그럴듯해 보이는 코드, 콘텐츠, 논문, 게시물을 생성할 수 있을 때, 어떻게 신호 대 잡음 비율을 유지할까요?

보리스 체르니는 반론을 제시해요. "모델이 덜 조잡한 코드를 작성하고 기존 코드 문제를 고치는 데 더 나아질 거라서 슬랍포칼립스는 없을 거라고 봅니다."

둘 다 동시에 사실일 수 있어요. 슬랍의 능력은 전례 없는 규모로 존재해요. 그걸 방지하는 도구도 나오고 있고요. 질문은 어느 쪽이 더 빨리 스케일되느냐예요.

슬랍포칼립스는 속도를 생산성으로 착각하는 사람들이 이끌 거예요. AI 에이전트는 방향 감각 없는 마라토너예요. 당신이 방향을 안 주면, 필요한 곳에서 코드 액션을 감사하지 않으면, 벽돌 벽으로 10마일을 질주할 거예요.

실용적 패턴: 실제로 작동하는 것들

지난 1년간 팀들이 적응하는 걸 보면서, 효과적인 패턴이 결정화됐어요.

첫째, 타이트한 반복 루프와 함께 AI 에이전트 우선 초안이에요. 일회성 제안에 AI를 쓰지 마세요. 전체 1차 초안을 생성하고, 그다음 개선하세요. Claude Code 팀 실천법처럼, 새 컨텍스트 창으로 모델이 자기 코드를 리뷰하게 하세요.

둘째, 선언적 커뮤니케이션이에요. 노력의 70%를 문제 정의에, 30%를 실행에 쓰세요. 포괄적 스펙을 쓰고, 성공 기준을 정의하고, 테스트 케이스를 미리 제공하세요.

셋째, 자동화된 검증이에요. 같은 종류의 실수를 반복해서 고친다면, 미리 테스트나 린트 룰을 쓰세요. AI 에이전트에게 코드를 설명하게 하고, 당신이 리뷰하기 전에 잠재적 문제를 표시하게 하세요.

넷째, 의도적 학습이에요. AI를 목발이 아니라 학습 도구로 쓰세요. AI 에이전트가 이해 안 되는 걸 작성하면, 그게 더 파고들라는 신호예요. AI 생성 코드를 멘토의 코드처럼 다루세요. 출시하려고만 리뷰하지 말고, 배우려고 리뷰하세요.

다섯째, 아키텍처 위생이에요. 더 많은 모듈화, 더 명확한 API 경계예요. 프롬프트에 넣을 잘 문서화된 스타일 가이드예요. 계획 단계는 확장되고, 코딩 단계는 압축되고, 리뷰 단계는 문법보다 디자인에 집중하죠.

번성할 개발자는 가장 많은 코드를 생성하는 사람이 아니에요. 어떤 코드를 생성할지, 언제 아웃풋에 의문을 가질지, 손이 키보드를 떠나도 어떤게 이해를 유지할지 아는 사람이에요.

스킬 개발에 대한 불편한 진실

AI를 많이 쓰는 사람들에게서 스킬 위축의 초기 증거가 있어요. 모든 것을 AI에 의존하는 주니어 개발자들이 시간이 지나며 문제 해결 능력에 덜 자신감을 느낀다고 보고해요. 코딩에 적용된 구글 효과예요. 계속 외주화하면, 뇌가 유지하는 걸 멈춰요.

해결책으로 몇 가지를 시도해볼 수 있어요. TDD를 쓰세요. AI가 구현하게 하기 전에 테스트를 쓰세요. 시니어와 페어링하세요. AI 제안을 실시간으로 논의해서 의사결정 과정을 배우세요. 설명을 요청하세요. AI가 그냥 솔루션을 생성하게만 하지 말고, 접근법을 정당화하게 하세요.

리스크는 진짜예요. 더 이상 처음부터 작성할 수 없는 코드를 리뷰하는 게 위험할 정도로 쉬워요. 그렇게 되면, 성장을 제한하는 방식으로 도구에 의존하게 된 거예요.

장기적으로 번성할 엔지니어는 경험 획득을 가속화하려고 AI를 쓰는 사람이지, 완전히 우회하려는 사람이 아니에요. AI를 활용해 더 빠르게 더 많은 영역을 탐험하면서도 기본기를 유지하는 거죠.

우리는 어디에 서 있나

카파시가 옳은 질문을 해요. "10X 엔지니어는 어떻게 될까요? 평균과 최대 엔지니어 간 생산성 비율은요? 이게 많이 커질 가능성이 있어요."

한 가지는 확실해요. 2025년 후반 얼리 어답터들에게 AI가 코드의 80%를 작성했어요. 당신의 퍼센티지가 훨씬 낮더라도, 1년 전보다는 높을 가능성이 커요. 이는 사람의 역할에 불균형적 강조를 둬요. 결과 소유하기, 품질 바 유지하기, 테스트가 실제로 동작을 검증하는지 확인하기 같은 거죠.

위험은 AI 에이전트가 실패하는 게 아니에요. 제 생각엔, 잘못된 방향으로 너무 자신 있게 성공해서 당신이 나침반 확인을 멈추는 거예요.

DORA의 2025년 리포트가 현실을 결정화했어요. AI는 개발 관행의 증폭기예요. 좋은 프로세스는 더 좋아져요. 고성능 팀이 55~70% 더 빠른 전달을 봤거든요. 나쁜 프로세스는 더 나빠져요. 전례 없는 속도로 부채가 축적되죠. 은총알은 없어요.

카파시의 마지막 관찰이 가장 공명해요. "AI 에이전트로 프로그래밍이 더 재미있게 느껴진다는 걸 예상 못 했어요. 빈칸 채우기 고된 작업이 많이 제거되고 남는 건 창의적 부분이거든요."

그는 또 언급해요. "LLM 코딩은 주로 코딩을 좋아했던 사람과 주로 빌딩을 좋아했던 사람을 기반으로 엔지니어를 분할할 거예요."

이게 아마 이 방향이 어디로 가는지에 대한 가장 통찰력 있는 예측일 거예요. 코드를 작성하는 행위 자체를 좋아했다면, 이 전환이 손실처럼 느껴질 수 있어요. 뭔가를 만드는 걸 좋아했고 코드가 필요한 수단이었다면, 이건 해방처럼 느껴지죠.

어느 반응도 틀리지 않았어요. 하지만 도구는 후자를 위해 최적화되고 있어요. 소프트웨어 엔지니어로서 우리 정체성은 결코 "코드 작성할 수 있는 사람"이 아니었어요. "소프트웨어로 문제 해결할 수 있는 사람"이었죠.

AI가 엔지니어를 대체하는 게 아니에요. 더 낫게든 더 나쁘게든 증폭하고 있어요. 제 조언은 이래요. 도구를 받아들이되, 결과를 소유하세요. 학습을 건너뛰는 게 아니라 가속화하려고 AI를 쓰세요. 그 어느 때보다 중요한 기본에 집중하세요. 견고한 아키텍처, 깨끗한 코드, 철저한 테스트, 사려 깊은 UX요. 이것들은 여전히 중요해요. 어쩌면 더 중요할 수도 있죠.

AI 코딩 시대의 본질은 숫자가 아닙니다. 80%든 90%든, 중요한 건 개발자의 역할이 '구현자'에서 '설계자이자 품질 관리자'로 전환되고 있다는 점이에요. 빠른 코드 생성 능력만큼이나 그 코드를 이해하고 방향을 제시하는 능력이 더욱 중요해졌습니다. AI는 도구일 뿐, 결과에 대한 책임과 아키텍처에 대한 통찰은 여전히 사람의 몫입니다. 기본기를 잃지 않으면서 AI를 활용하는 균형감각이 앞으로의 경쟁력을 좌우할 거예요.