AI는 10분 만에 80%를 작성했습니다. 나머지 20%는 6시간이 걸렸습니다.

title: "AI는 10분 만에 80%를 작성했습니다. 나머지 20%는 6시간이 걸렸습니다."
published: false
canonical_url: https://susiloharjo.web.id/ai-code-80-percent-10-minutes-20-percent-six-hours/
description: "6개월 동안 47개의 AI 보조 기능을 추적했습니다. 80/20 법칙이 매번 유지되었습니다. 마지막 20%의 실체는 다음과 같습니다."

tags: ai, productivity, softwareengineering, devprocess, lessons

저는 화요일에 처음부터 끝까지 11분이 걸린 기능을 출시했습니다. 에이전트 (Agent)가 해피 패스 (Happy path)를 생성하고, 테스트를 실행하고, PR (Pull Request)을 열었습니다. 저는 병합 (Merge)을 클릭했습니다. 점심 식사 전에 끝났습니다.

같은 에이전트가 금요일에 기능을 출시했는데, 에이전트가 작업을 마친 후 저에게 6시간이 더 걸렸습니다. 해피 패스 (Happy path)는 동일해 보였습니다. 차이점은 마지막 20%였습니다.

그 격차가 바로 이 포스트의 주제입니다.

47개의 기능들

저는 올해 초부터 Claude Code를 주요 코드 작성 도구로 사용해 왔습니다. 3개월 차가 지난 후, 시간을 기록하기 시작했습니다. 기능당 두 가지 숫자를 기록했습니다: 첫 번째 프롬프트 (Prompt)부터 "여기에 diff가 있습니다, PR을 열까요?"라고 할 때까지의 생성 시간 (Generation time), 그리고 PR이 열린 시점부터 모든 체크가 통과되어 병합 (Merge)될 때까지의 출시 시간 (Ship time)입니다. 저는 이 두 숫자를 간단한 스프레드시트에 기록했습니다.

47개의 기능을 거치면서, 그 비율은 거의 항상 80/20이었습니다. 10% 정도의 오차는 있었습니다.

저는 프롬프팅 (Prompting) 실력이 좋아짐에 따라 그 비율이 변할 것이라고 예상했습니다. 하지만 변하지 않았습니다. 에이전트 (Agent)는 더 빨라졌습니다. 저도 더 빨라졌습니다. 우리 둘 다 속도가 올라갔습니다. 하지만 비율은 변하지 않았습니다. 그 점이 저를 놀라게 했습니다.

스프레드시트의 몇 가지 예시입니다:

• 사용자 설정 양식 (User settings form). 생성에 4분, 배포(ship)까지 38분 소요. 양식은 첫날부터 정상 작동했습니다. 38분은 싱가포르 사용자 2명을 위한 시간대 처리(timezone handling)와 프롬프트에서 언급되지 않은 "보조 이메일(secondary email)" 필드 때문이었습니다.
• 웹훅 수신기 (Webhook receiver). 생성에 12분, 배포까지 4시간 소요. 수신기는 첫 배포 시 정상 작동했습니다. 4시간은 2xx 타임아웃 시 재시도하는 결제 제공업체를 위한 멱등성 키 (idempotency keys) 처리와, 재시도마저 실패할 경우를 대비한 데드 레터 큐 (dead-letter queue) 구현 때문이었습니다.
• CSV 내보내기 (CSV export). 생성에 6분, 배포까지 2시간 소요. 내보내기는 첫 배포 시 정상 작동했습니다. 2시간은 월 경계에서 오류가 발생하는 날짜 필터와, Mac용 Excel이 렌더링을 거부한 BOM(Byte Order Mark) 문자 때문이었습니다.
• 리포팅 쿼리 (Reporting query). 생성에 18분, 배포까지 9시간 소요. 쿼리는 샘플 데이터셋에서 정상 작동했습니다. 9시간은 운영 환경의 핫 샤드 (hot shard)를 타격한 파티션 전략 (partition strategy), 누락된 두 개의 인덱스 (indexes), 그리고 제 개발자 역할(dev role)에서는 숨겨져 있던 권한 문제 때문이었습니다.

에이전트(Agent)는 제가 준 프롬프트에 맞는 올바른 코드를 작성했습니다. 지연이 발생한 지점은 제가 에이전트에게 말하지 않은 모든 것이었습니다. 왜냐하면 제가 아직 그것들에 대해 생각하지 못했기 때문입니다. 도메인 지식 (Domain knowledge). 과거 버그에서 기인한 예외 케이스 (Edge cases). 너무 잘 알고 있어서 언급하는 것조차 잊어버리는 것들 말입니다.

그것이 바로 20%입니다. 그것은 프롬프트 안에 있지 않습니다. 그것은 제가 언급하지 않은 문제의 부분들에 들어 있습니다.

마지막 20%의 실체

47개의 기능을 구현한 결과, 이 20%는 안정적으로 5가지 카테고리로 분류됩니다. 제가 배포하는 모든 기능은 이 5가지를 모두 충족합니다. 어떤 기능은 이 요소들을 강하게 맞닥뜨리고, 어떤 기능은 간신히 지나가지만, 어떤 카테고리도 완전히 건너뛰는 법은 없습니다.

빈 상태 (Empty state). 사용자가 아무것도 가지고 있지 않을 때 페이지는 어떤 모습일까요? 신규 계정, 빈 데이터베이스, 새로운 테넌트 (tenant), 첫 실행 상황 말입니다. 에이전트는 프롬프트에 "사용자의 송장을 보여줘"라고 되어 있기 때문에 데이터가 이미 있다고 가정합니다. 실제 사용자들은 송장이 0개인 상태로 나타납니다. 에이전트는 빈 상태의 UI를 작성하지 않습니다. 여러분은 출시 3일 후 고객 지원 이메일을 받고 나서야 이 사실을 알게 됩니다. 그리고 빈 상태를 작성하는 데 40분을 쓰게 됩니다.

에러 처리(Error handling). 네트워크가 실패하면 어떻게 될까요? 타사 API가 500 에러를 반환하면요? 데이터베이스 연결이 쿼리 도중에 끊기면요? 에이전트는 '행복한 경로(happy path)'만 작성합니다. 모든 것이 성공한다고 가정합니다. 모든 try-catch, 모든 폴백 UI(fallback UI), 그리고 '이것이 고장 났을 때 사용자는 무엇을 보게 될까'에 대한 결정은 여러분의 몫입니다. 위의 웹훅 수신기를 위해 에이전트는 80줄을 생성했습니다. 저는 이것이 프로덕션 준비가 되기 전에 140줄 분량의 에러 처리 및 데드레터 로직(dead-letter logic)을 추가해야 했습니다.

도메인별 예외 사례(Domain-specific edge cases). 에이전트는 ERP의 세 가지 다른 부분에서 '비어 있음(empty)'이라는 것이 세 가지 다른 의미를 가진다는 것을 모릅니다. 인도네시아 결제 형식이 다른 파서가 필요하다는 것도 알지 못합니다. 오래된 형식의 레거시 데이터에 대해서도 모릅니다. 에이전트는 아무도 알려주지 않은 지역별 설정으로 제품을 사용하는 엔터프라이즈 고객에 대해서도 모릅니다. 저는 지난 2년간 이것들을 디버깅했기 때문에 이런 것들을 압니다. 에이전트는 한 번도 들어본 적이 없습니다.

성능 급락(Performance cliff). 에이전트는 여러분이 준 예제에서 작동하는 코드를 작성합니다. 규모에 대한 스트레스 테스트는 하지 않습니다. 보고서 쿼리는 50개 행에서는 작동했지만, 플래너가 새로 파티셔닝된 테이블에 순차 스캔(sequential scan)을 선택했기 때문에 5백만 개 행에서는 작동하지 않았습니다. 웹훅 수신기는 분당 100개의 요청에서는 작동했지만, 아이뎀포턴시 캐시(idempotency cache)가 메모리 내 딕셔너리(in-memory dict)였고 워커를 200MB 후에 충돌시키면서 초당 10개 요청에서는 작동하지 않았습니다.

유지보수 비용(Maintainability tax). 저는 이것을 나중에 깨달았습니다. 에이전트는 오늘을 위한 코드를 작성합니다. 3개월 후, 요구 사항이 바뀌었을 때, 에이전트가 선택한 추상화는 맞지 않습니다. 리팩토링 비용이 다시 쓰는 것보다 더 많이 들 수 있습니다. 저는 지난 6개월 동안 두 번이나 이런 일을 했습니다. 그때마다 제가 더 장황한(verbose) 버전을 작성하지 않은 것을 후회했습니다.

제가 바꾼 4가지 것들

저는 많은 시도를 해봤습니다. 대부분은 작동하지 않았습니다. 이 4가지는 작동했습니다.

저는 4배의 예산을 잡습니다. 에이전트가 "이것은 10분짜리 기능입니다"라고 말하면, 저는 40분을 계획합니다. 아직 이 방식이 틀린 적은 없습니다. 에이전트는 더 빨라졌지만, 제가 예상하는 출시 시간 (ship time)은 그렇지 않았습니다. 4배라는 수치는 비관적인 것이 아닙니다. 그것은 단지 하나의 패턴일 뿐입니다.

저는 예외 경로 (unhappy path)를 먼저 프롬프트합니다. 에이전트가 정상 경로 (happy path)를 작성하기 전에, 저는 프롬프트에 내용을 추가합니다. "입력이 비어 있을 때는 어떤 모습이어야 하나요?" "네트워크가 실패할 때는 어떤 모습이어야 하나요?" "사용자가 예상하지 못한 행동을 할 때는 어떤 모습이어야 하나요?" 에이전트는 스스로 이런 것들을 생각하지 못할 것입니다. 제가 이름을 명시하면, 에이전트는 한 번 시도합니다. 그 시도가 훌륭하지는 않지만, 백지 상태 대신 시작점을 제공해 줍니다.

저는 실패 테스트 (failure tests)를 먼저 작성합니다. 이 방식은 느리게 느껴졌기 때문에 가장 오래 저항했습니다. 그러다 2주 동안 시도해 보았고, 이제는 예전으로 돌아갈 수 없습니다. 무엇이 이것을 망가뜨릴까요? 실제 사용자가 제가 예상하지 못한 어떤 행동을 할까요? 저는 이러한 테스트를 먼저 작성하여, 에이전트가 코드를 생성할 때 목표를 가질 수 있도록 합니다. 테스트는 제 출시 시간을 잡아먹었을 문제의 약 70%를 잡아냅니다. 나머지 30%는 여전히 나타나지만, 저는 그것들을 머지 (merge) 버튼을 누른 후가 아니라 테스트를 작성하는 동안 발견합니다.

저는 20% 저널을 작성합니다. 기능 하나당 한 줄씩 적습니다. "[기능]의 마지막 20%는 [내가 시간을 보낸 내용]이었다." 저는 47개의 기록을 가지고 있습니다. 처음 10개는 주로 빈 상태 (empty-state)와 에러 처리 (error-handling)에 관한 것입니다. 중간의 20개는 도메인 엣지 케이스 (domain edge cases)입니다. 마지막 17개는 성능 (performance)과 유지보수성 (maintainability)으로 나뉩니다. 패턴이 충분히 일관적이기 때문에, 이제 저는 어떤 카테고리를 예상해야 할지 압니다. 웹훅 (Webhooks)은 거의 항상 에러 처리입니다. 보고서 (Reports)는 거의 항상 성능입니다. 내보내기 (Exports)는 거의 항상 날짜 형식입니다.

단 하나의 규칙

어떤 기능이든 에이전트를 열기 전에, 저는 한 가지 질문을 던집니다. "사용자가 내가 생각하지 못한 어떤 행동을 할 것인가?"

만약 10초 이내에 답할 수 없다면, 저는 에이전트 (agent)를 열지 않습니다. 대신 그 질문과 함께 앉아 고민합니다. 때로는 답이 "아무것도 아님, 이건 단순함"일 때도 있습니다. 때로는 답이 "오, 사용자가 CSV에서 50,000개의 행을 가져올 것이다"일 때도 있습니다. 답이 두 번째 경우라면, 저는 프롬프트 (prompt)에 CSV 가져오기 기능을 먼저 추가합니다.

이 규칙은 저의 시간을 가장 많이 아껴주었습니다. 프롬프트가 길어지기 때문이 아니라, 제가 먼저 생각하게 만들기 때문입니다. 나머지 20%는 제가 언급하지 않은 문제의 부분들입니다. 이를 찾는 가장 좋은 방법은 생성한 후가 아니라, 생성하기 전에 질문하는 것입니다.

에이전트가 나쁘다는 뜻은 아닙니다. 에이전트 덕분에 저는 6개월 동안 12개가 아닌 47개의 기능을 출시할 수 있었습니다. 10분 만에 80%를 해내는 것은 사실입니다. 저는 다시 수동으로 작성하는 방식으로 돌아가지 않을 것입니다. 하지만 20% 또한 실재합니다. 만약 그것이 존재하지 않는 척한다면, 저의 속도 (velocity) 수치는 실제 출시 시간과 일치하지 않게 됩니다.

제가 프롬프트를 얼마나 빨리 타이핑할 수 있느냐는 기능이 프로덕션 (production) 환경에 배포되기까지 걸리는 시간과 같지 않습니다. 에이전트는 첫 번째 숫자를 작게 만듭니다. 하지만 실제로 중요한 것은 두 번째 숫자입니다.

만약 여러분도 자신만의 80/20 수치를 기록해 왔다면, 저에게 보내주세요. 저는 다른 세 명의 엔지니어와 의견을 나누어 보았는데 패턴이 비슷해 보였습니다. 이는 작은 집단입니다. 더 많은 데이터가 있다면 80/20 규칙이 보편적임을 확인하거나, 혹은 이 규칙이 어디에서 깨지는지를 보여줄 것입니다.