AI 코드의 80/20 법칙

AI는 내 기능(feature)의 첫 80%를 10분 만에 작성했습니다. 코드는 깔끔했습니다. 로직은 타당했습니다. 해피 패스(happy path)는 첫 시도에 바로 작동했습니다. 코드를 실행하고 작동하는 것을 보며, 개발자로서 의자에 살짝 몸을 기대게 만드는 특유의 자부심을 느꼈습니다.

저는 감명받았습니다. 앞으로 10분이면 다 끝날 것이라고 생각했습니다.
그게 화요일이었습니다. 목요일 저녁이 되어서도 저는 여전히 같은 기능을 작업하고 있었습니다.

이것은 AI에 대한 불만이 아닙니다. 작업의 형태에 대한 관찰입니다.

아무도 말하지 않는 격차

이 포스트를 작성하게 만든 기사는 제 경험과 정확히 일치하는 점을 지적합니다: AI는 첫 80%에는 놀라운 능력을 발휘하지만, 마지막 20%에서는 조용히 쓸모가 없어진다는 것입니다. AI가 실패하기 때문이 아니라, 잘못된 것, 즉 해피 패스(happy path)를 최적화하기 때문입니다. 모든 것이 제대로 돌아가는 세상 말입니다.
하지만 그런 세상은 프로덕션(production) 환경에 존재하지 않습니다.
AI 코드 생성(code generation)으로 에이전트 시스템(agent systems)을 구축하며 제가 배운 것은 다음과 같습니다:
첫 80%는 빠르고, 인상적이며, 진정으로 유용합니다. 진심입니다. 한 시간이 걸렸을 티켓(ticket)을 10분 만에 처리할 수 있는 능력은 실재합니다. 코드는 깔끔하고, 변수 이름은 합리적이며, 로직은 흐름이 좋습니다. 저는 이런 방식으로 기능을 출시해 왔으며, 그 속도(velocity)는 가짜가 아니었습니다.
하지만 마지막 20%가 바로 제가 지금 머물고 있는 곳입니다. 그곳이 실제로 작업이 이루어지는 곳입니다.
빈 상태(Empty states). 에러 경로(Error paths). Kerry에 있는 사용자가 계정을 생성했는데 그들의 표시 이름(display name)이 우연히 null인 경우에만 의미가 있는 null 체크(null check). AI가 도저히 알 수 없는 도메인 특화 로직(domain-specific logic) — 왜냐하면 그것은 특정 코드베이스, 특정 팀, 특정 행동을 하는 특정 사용자들의 축적된 컨텍스트(context) 안에만 존재하기 때문입니다.
AI는 그 중 어떤 것도 알지 못합니다. 알 수 없습니다. 그러한 컨텍스트는 학습 데이터(training data)에 들어있지 않습니다.

80/20 분할이 실제로 어떤 모습인지

구체적인 예를 들어보겠습니다. 제가 Sol Email Worker를 구축했을 때, AI는 핵심 로직을 빠르게 생성했습니다. 스레딩 (threading), 송신/답장 함수 (send/reply functions), 기본적인 라우팅 (routing) 같은 것들 말이죠. 그 부분은 코드 라인의 80%를 차지했으며 아마 20분 정도 걸렸을 것입니다.
나머지 20%의 코드를 작성하는 데는 저녁 시간의 나머지 전부가 소요되었습니다:

• 중복 제거 로직 (deduplication logic). 동일한 메시지가 두 번 처리되면 어떻게 될까요? AI는 이 부분을 확인하지 않았습니다. 실제 이메일 시스템에는 이것이 필요합니다.
• 발신자 건너뛰기 로직 (sender-skip logic). 다른 서비스에서 온 본인의 메시지들 — AI는 이를 건너뛰어야 한다는 것을 알지 못했습니다. 제가 명시적으로 추가해야 했습니다.
• 오류 복구 (error recovery). API가 예상치 못한 값을 반환하면 어떻게 될까요? AI는 그렇지 않을 것이라고 가정했습니다. 사용자는 그런 가정을 하지 않습니다.
• 로그 출력 (log output). 결정적인 것은 아니지만, 새벽 2시에 무언가 고장 났을 때 왜 그런 일이 발생했는지 이해하고 싶기 마련입니다. AI는 그 과정을 쉽게 만들어 줄 로그를 작성하지 않았습니다.
  이 중 어느 것도 AI의 잘못이 아닙니다. AI는 제가 요청한 것을 정확히 수행했습니다. 단지 제가 시작하기 전에 모든 엣지 케이스 (edge case)를 충분히 생각하지 못했기 때문에, 처음부터 그 모든 것을 요청해야 한다는 사실을 몰랐을 뿐입니다.

진짜 측정의 문제

저를 좌절시키는 것은 AI가 아닙니다. AI를 활용한 생산성을 측정하는 방식입니다. 우리는 생성된 코드 라인 수, 해결된 티켓 수, 상승하는 기여 그래프 (contribution graphs) 등을 측정합니다. 이러한 지표들은 80%를 아주 아름답게 포착합니다. 왜냐하면 그 80%는 빠르고 눈에 보이며, 목요일 오후의 초록색 사각형(GitHub 잔디)으로 나타나기 때문입니다.
20%는 보이지 않습니다. 그 누구의 대시보드도 오류 처리 (error handling)에 소비된 시간을 보여주지 않습니다. 그 누구의 스탠드업 미팅 (standup meeting)도 "어제는 널 체크 (null checks)를 하느라 시간을 보냈습니다"로 시작하지 않습니다. 그것은 어디에도 나타나지 않습니다. 하지만 실제 시간의 대부분은 바로 그곳에서 소비됩니다.
저는 더 정직한 지표를 추적하기 시작했습니다: 바로 프롬프트-배포 시간 (prompt-to-ship time) 입니다. 첫 번째 프롬프트를 입력한 시점부터 모든 엣지 케이스가 처리되어 기능이 실제로 프로덕션 (production) 환경에서 작동할 때까지 걸리는 시간 말입니다. 그 수치는 AI 생성 시간이 시사하는 것과 결코 일치하지 않습니다. 항상 최소 4배는 더 걸립니다.

이제 제가 다르게 하는 것

저는 이제 20%를 미리 예산에 반영합니다.

AI가 생성한 코드가 포함된 어떤 작업을 추정할 때, 저는 생성 시간이 제안하는 시간의 약 4배를 추가합니다. AI는 "이 기능은 10분짜리입니다"라고 말합니다. 저는 제 뇌에게 이것은 40분짜리 기능이라고 말하고 그에 맞춰 계획을 세웁니다. 저는 명시적으로 '언해피 패스 (unhappy path, 예외 경로)'를 프롬프트로 요청합니다. 네트워크가 실패하거나, API가 null을 반환하거나, 리스트가 비어 있거나, 사용자가 아무도 예상하지 못한 행동을 한다고 가정하라고 AI에게 지시합니다. 이것은 도움이 됩니다. 모든 것을 해결해주지는 않지만, 유의미한 변화를 만들어냅니다. 저는 첫 번째 초안을 결승선이 아닌 시작점으로 취급합니다. 이것이 가장 어려운 부분입니다. 첫 번째 초안은 완성된 것처럼 보입니다. 실행도 됩니다. 말이 됩니다. 하지만 완성되어 보이는 것과 실제로 완성된 것은 다른 문제이며, 그 차이는 20% 안에 존재합니다.

제가 계속 되돌아오게 되는 지점

30초의 생성 시간 이후 에러 핸들링 (error handling)에 소비한 3시간은 낭비된 시간이 아니었습니다. 그것이 실제 작업이었습니다. AI는 작업의 위치를 옮겼습니다. 구조를 작성하는 것에서 그것을 실제로 구현하는 것으로 작업을 이동시킨 것입니다. 실제로 구현하는 것은 더 느린데, 왜냐하면 AI가 가지고 있지 않은 컨텍스트 (context, 맥락)가 필요하기 때문입니다. 당신의 구체적인 상황, 당신의 구체적인 사용자들, 이 코드베이스 (codebase)와 당신의 구체적인 이력 같은 것들 말입니다. 이것은 AI의 한계가 아닙니다. 그것은 전문 지식 (expertise)이 실제로 무엇인지에 대한 설명입니다. AI가 빠른 이유는 익숙한 영역에서 작동하기 때문입니다. 언해피 패스 (unhappy path)는 매번 낯선 영역입니다. 왜냐하면 모든 코드베이스는 각자만의 '언해피' 버전을 가지고 있기 때문입니다. 다음에 AI 데모가 10분 만에 당신을 감동시킨다면, 개발자에게 그 다음에 무슨 일이 일어났는지 물어보세요. 저는 그 답변이 제 화요일의 모습과 매우 비슷할 것이라고 확신합니다.