AI가 건드리지 못하는 병목

AI 코딩은 빨라졌는데 왜 프로젝트는 그대로일까

역설

요즘 바이브 코딩이 한참 열풍입니다.

저는 솔직히 처음엔 이게 어느정도 까지 될까 반신반의했습니다. 근데 막상 써보니까 생산성이 확 올라가는 느낌이 들더라고요. 그래서 개발자 커뮤니티를 둘러봤는데, 재밌는 걸 발견했습니다.

"바이브 코딩 덕분에 생산성 역대급이에요!" 이런 글 바로 옆에 "AI가 만든 코드 그럴싸해 보여서 믿었는데, 인증 버그 찾느라 3시간 날렸어요" 이런 글이 있습니다.

둘 다 틀린 말이 아닙니다. 둘 다 실제 경험입니다.

그러고 보니 이상합니다. 같은 도구를 쓰는데 왜 어떤 사람은 생산성이 올라가고, 어떤 사람은 오히려 시간을 더 쓰게 되는 걸까요.

사실 이건 AI 문제가 아닙니다. AI 코딩 실력이 부족한 것도 아닙니다.

저는 이걸 의도 부채 라고 부르기로 했습니다. 그리고 이걸 만드는 게 의도 격차 라고 생각하는데요. 잠시 뒤에 자세히 풀어보겠습니다.

이런 현상은 단순히 일부에서만 나타나는 현상이 아닙니다. METR의 무작위 대조 실험에서 경험 많은 오픈소스 개발자들을 대상으로 연구한 결과를 보면 생각보다 흥미로운 사실을 알 수 있습니다.

개발자들은 AI 도구가 생산성을 24% 향상시켜줄 것이라고 예측했고, 사용 후에는 20% 더 생산적이라고 느꼈습니다. 반면, 실제 측정 결과는 19% 더 느린 것으로 확인되었습니다.

연구진은 이렇게 말합니다. 개발자들이 AI 덕분에 더 빨라졌다고 느끼더라도, 실제로는 그렇지 않을 수 있다고요.

참고로 METR 연구는 이미 코드베이스를 깊이 이해하고 있는 경험 많은 개발자들을 대상으로 했습니다. 신규 프로젝트나 낯선 코드베이스에서는 AI의 패턴 매칭이 더 효과적일 수 있어서 결과가 다를 수도 있습니다. 다만 주목할 만한 건, 개발자들이 일관되게 속도 향상을 과대평가했다는 점입니다.

Copilot이나 Cursor를 도입하고 나서 코드 출력량이 3배가 되었다고 가정해봅시다. 근데 어쩐지 3주짜리 프로젝트는 여전히 3주가 걸립니다. 불가능해 보였던 스프린트도 여전히 불가능합니다.

그렇다면 우리의 시간은 대체 어디로 간걸까요?

여기에 대한 답은 AI가 건드리지 못하는 병목을 생각해 볼 수 있습니다. 그리고 아마 앞으로도 계속해서 AI가 건드리지 못할 가능성이 높습니다.

개발자 시간은 실제로 어디에 쓰이나

그렇다면 왜 이런 현상이 생기는 걸까요?

IDC의 2024 분석 보고서에서 재밌는 데이터를 발견했습니다. 개발자들의 실제 시간 배분인데요.

이 차트를 보면 실제 코딩은 16%에 불과하다는 것을 알 수 있습니다.

물론 이 연구는 엔터프라이즈 환경에 편향되어 있을 가능성이 높습니다. 스타트업이나 소규모 팀이라면 코딩 비율이 더 높겠죠.

다만 요점은 변하지 않습니다. 우리는 하루 종일 코딩한다고 느낍니다. IDE가 열려 있고, 손가락은 키보드 위에, 아이스 아메리카노의 얼음이 녹고 있으니까요. 근데 실제로는 개발자 시간의 대부분이 코드 타이핑이 아니라 그 외의 모든 것에 쓰이고 있더라고요.

AI 도입 후: 시간은 어디로 갔나

AI 코딩으로 그 16%가 확 줄어들 것 같았습니다. 근데 앞서 봤듯이, 실제로는 그렇지 않더라고요. 그렇다면 시간은 어디로 가는 걸까요?

여러 연구 결과를 보면 이 현상이 뚜렷하게 나타납니다:

- 66%의 개발자가 AI 생성 코드를 디버깅하는 데 작성 시간 절약분보다 더 많은 시간을 씀 (Stack Overflow 2025)

- 91% 증가한 코드 리뷰 시간 (Google DORA 2025)

- 45%가 선택한 최대 불만: "거의 맞지만 완전히는 아닌 AI 솔루션" (Qodo State of AI Code Quality)

- 154% 증가한 PR 크기 (Google DORA 2025)

결국 코딩에서 절약한 시간이 검증, 디버깅, 리뷰에 흡수되는 셈입니다. 마치 풍선을 누르는 것과 같다고 해야 할까요? 한쪽을 누르면 다른 쪽이 부풀어 오르니까요.

Atlassian의 2025 State of DevEx 보고서에 따르면 AI 도구가 개발자에게 주당 10시간 이상을 절약해주지만, 회의, 리뷰, 커뮤니케이션 같은 부가 작업에 다시 소모된다고 합니다. Faros AI의 분석은 10,000명 이상의 개발자를 조사한 결과 "AI가 빨라진 만큼, 그 결과물을 맞추고 확인하느라 시간이 다시 잡아먹힌다"고 밝혔습니다.

정리하면, AI가 코드를 더 빨리 생성하지만 절약된 시간이 리뷰, 디버깅, 조율에 흡수되어 팀은 여전히 느리거나, 오히려 더 느려지는 결과를 보이고 있는걸 알 수 있습니다.

의도 격차

여기서 불편한 진실을 짚고 넘어가야 할 것 같습니다. 원하는 것을 정확히 표현하는 것이 가장 어려운 부분이라는 점입니다.

앞서 언급한 의도 격차가 바로 이것입니다. 우리가 알고 있는 것과 표현할 수 있는 것 사이의 차이를 말합니다. 머릿속의 모호한 생각을 명시적인 명세로 변환하는 것이 이제 병목이 된 것입니다. 코딩 자체가 아니라요.

이건 사실 항상 프로그래밍에서 어려운 부분이었습니다. 다만 코딩 시간이 일종의 버퍼 역할을 해서 알아채지 못했을 뿐입니다. 기능을 구현하는 데 4시간을 쓰면, 무엇을 만들지 파악하는 데 쓴 2시간이 잘 느껴지지 않습니다. 코드를 작성하면서 동시에 무엇을 어떻게 만들어야할지를 고민하게 되면서 이 둘이 섞여버리니까요.

근데 AI가 코드 작성 단계를 제거해버리니까 재밌는 사실이 드러났습니다. 우리가 코드를 작성하는 동안, 사실은 동시에 요구사항도 정리하고 있었던 거더라고요.

의도 격차를 좁히는 것이 느리게 느껴지는 이유:

1. 머릿속 생각을 명시적으로 변환하는 것은 정말 어렵습니다

예를 들어, 대시보드를 만든다고 해봅시다. 나의 머릿속에는 대시보드가 어떻게 생겼으면 좋겠는지 알고 있습니다. 머릿속에서는 명확합니다. 근데 이걸 정확하게 설명하려고 하면 예상보다 훨씬 오래 걸린다는 걸 알 수 있습니다.

"대시보드가 필요해요"라는 요청이 다음과 같이 바뀝니다: "상단에 3개의 메트릭 카드가 있고, 그 아래에 시계열 차트가 있고, 최근 7/30/90일 프리셋 옵션이 있는 날짜 범위 필터가 있고, 모바일에서는 카드가 세로로 쌓이고, 색맹 사용자를 위한 접근성 있는 색상 체계가 있고, 각 컴포넌트에 로딩 상태가 있는 대시보드가 필요해요..."

머릿속 이미지는 단순했지만 명세는 그렇지 않습니다.

2. 발견은 표현 과정에서 일어납니다

명세하려고 시도하기 전까지는 우리가 실제로 원하는 것이 무엇인지 모르는 경우가 많습니다. 요구사항은 작성하는 과정에서 드러납니다.

"검색 기능이 필요해요"는 명확해 보입니다. 근데 명세를 시작하면 질문이 쏟아집니다. 퍼지 검색인가 정확히 일치인가? 대소문자 구분은? 여러 필드 검색은? 결과가 없으면 어떻게 하나? 타이핑하면서 검색할지 제출할 때 검색할지? 특수 문자는 어떻게 처리하나? 10만 개 레코드에서 성능은?

질문이 계속 늘어나고, 각 답변이 또 다른 질문을 드러냅니다.

3. 당연해 보이는 맥락이 실제로는 당연하지 않습니다

"사용자 프로필 페이지 만들어주세요."

이 요청에서 빠진 것들: 프라이버시 제어(누가 무엇을 볼 수 있나?), 편집 기능(사용자가 모든 것을 바꿀 수 있나?), 어떤 필드를 포함할지, 모바일 반응형 요구사항, 접근성 준수, 이미지 업로드 성능 요구사항, 기존 인증 시스템과의 통합...

개발자인 우리에게는 이 중 절반이 "당연한" 것입니다. 근데 AI에게는 어떤 것도 당연하지 않습니다.

사람과의 비교: 사람도 마찬가지입니다

외주 업체에 일을 맡기는 상황을 생각해봅시다.

30분 동안 작업을 설명합니다. 외주 업체가 확인 질문을 합니다. 이메일로 한 시간 더 주고받습니다. 80% 정도 맞는 결과물을 받습니다. 리뷰하고, 어디가 틀렸는지 지적하고, 수정을 기다립니다.

이제 외주 업체를 AI 에이전트로 바꿔봅시다.

같은 30분 설명. 같은 확인 주고받기. 같은 리뷰와 수정 사이클.

실행은 빨라졌지만 우리가 해야 할 일은 그대로입니다.

병목은 구현 속도가 아니라 우리의 명세 능력입니다.

이 병목이 줄어들지 않는 이유

누군가는 이렇게 생각할 수 있습니다. 미래의 AI는 우리 마음을 읽지 않을까? 뇌-컴퓨터 인터페이스나 더 나은 의도 예측 기술이 나오지 않을까?

아마 그렇지 않을 가능성이 높습니다. 근데 그 이유가 생각하는 것과는 다를겁니다. 이 병목은 뇌에서 기계로 생각을 전송하는 문제가 아닙니다. 문제는 생각이 발견될 때까지는 완전히 존재하지 않는다는 점입니다.

예를 들어볼게요. 친구한테 "점심 뭐 먹고 싶어?"라고 물으면 "아무거나"라고 대답하는 사람 있잖아요. 근데 막상 짜장면 시키려고 하면 "아, 그건 아닌데..."라고 합니다. 본인도 뭘 원하는지 몰랐던 겁니다. 뭔가를 보고 나서야 자기가 원하는 게 뭔지 알게 된 거죠.

코딩도 마찬가지입니다. 우리는 원하는 것을 안다고 생각합니다. 근데 막상 AI가 만든 결과물을 보고 나서야 "아, 내가 원했던 건 이게 아닌데"라는 걸 깨닫게 됩니다. AI가 우리를 오해하는 게 아닙니다. AI는 그냥 빈칸을 채울 뿐입니다. 그리고 AI가 무엇으로 채웠는지 볼 때까지 우리가 얼마나 많은 빈칸을 남겼는지 깨닫지 못합니다.

뇌를 읽는 기술이 아무리 발전해도 소용없는 이유가 여기 있습니다. 아직 형성되지 않은 생각은 읽을 신호 자체가 없으니까요.

의외의 긍정적 측면

근데 여기서 흥미로운 점이 있습니다. 이 병목은 사실 좋은 소식이라는 점입니다.

인간 개발자가 필수적으로 남는다는 의미이기 때문입니다. 특히 경험 있는 개발자가요. 주니어 개발자 채용은 2022년 대비 60% 감소한 반면, 시니어 채용은 안정적이거나 오히려 증가했습니다. 회사들이 시니어를 AI로 대체하는 것이 아닙니다. 의도 격차를 좁히는 일이 멘토에게 떨어지는 신입 포지션을 줄이고 있는 것입니다. 병목 작업에는 여전히 인간의 판단이 필요합니다.

프로그래밍에서 어려운 부분은 절대 타이핑이 아니었습니다. 그렇다고 문법 암기나 API 시그니처를 아는 것도 아니었습니다.

어려운 부분은 항상 생각하기 였습니다. 무엇을 만들지 파악하기. 트레이드오프에 대해 판단하기. 명시되지 않은 요구사항 인식하기. 비즈니스 로직의 맥락 파악하기.

AI가 이제 타이핑을 담당합니다. 생각은 여전히 우리가 합니다.

물론 주니어 개발자에 대한 긍정적인 시각도 존재 합니다. 오히려 이런 AI 툴에 대한 적응력과 활용력은 주니어 개발자가 더 빠르게 적응할 것이라는 점인데요. 개인적인 생각으로는 우리의 역할이 조금 바뀔 뿐이지 결국에는 주니어와 시니어 모두 계속해서 필요하게 될 것이라는 생각이 듭니다.

앞으로의 의미

AI 코딩의 이득은 분명히 있습니다. 다만 많은 곳에서 이야기하듯 과대 포장된 것 보다는 좁은 범위라는 걸 인식해야 합니다. AI가 프로젝트를 10배 빠르게 만들 것을 기대한다면 계산이 맞지 않습니다. 구현은 타임라인의 일부일 뿐이고, 의도 부채는 압축되지 않으니까요.

스프린트 속도가 두 배가 되는데 전달 타임라인이 그대로라면, 뭔가가 이 속도 개선을 흡수하고 있는 겁니다. 이미 이전부터 해오고 있었던 작업이지만 지금까지는 이름이 없었던 작업들이죠. 명확히 하기, 리뷰하기, "아니, 그게 아니라..." 사이클. 그래서 프로젝트 추정치를 코딩 속도에 비례해서 줄이면 안 됩니다.

이건 앞으로 어떤 스킬이 중요한지도 바꿉니다. AI가 코딩을 대신해주는 세상에서는 "무엇을 만들어야 하는지"를 명확히 표현할 수 있는 사람이 가치를 갖게 됩니다. 의도 부채를 방지하는 것은 코드 작성과는 다른 근육이니까요.

그런데 한 가지 살짝 불편한 생각을 해볼 수 있습니다. 대부분의 사람들이 그렇게 하지 않으면 어떻게 될까요? 명확한 의도 없이 작성된 AI 생성 코드가 다음 세대 AI의 학습 데이터가 된다면?

조금 먼 미래 같지만 생각해볼만한 주제입니다. 이 내용은 다음 글에서 살펴보겠습니다.

요약

- AI는 코딩(~16%의 작업)을 빠르게 하지, 생각(~84%의 작업)을 빠르게 하지 않습니다

- 병목은 의도 격차입니다. 우리가 알고 있는 것과 표현할 수 있는 것 사이의 거리

- 의도 격차를 좁히는 것을 건너뛰면, 의도 부채가 나중에 디버깅, 재작업, 끝없는 수정으로 돌아옵니다