목차
- Before / After — 팀 구성과 결과
- 프로젝트 시작 — AI 풀세트로 가능해 보였다
- 1개월 차 — 속도는 정말 빨랐다
- 2개월 차 — 정산 기능에서 막혔다
- $500M 펀딩 뉴스가 슬랙에 돌았다
- 채용 결정 — 시니어 1명 + 주니어 1명
- 3개월 차 끝 — 무엇이 어떻게 바뀌었나
- 다음 프로젝트에선 이렇게 하기로 했다
- 개인 의견
Before / After — 팀 구성과 결과
| 구분 | Before (3월 초) | After (5월 말) |
|---|---|---|
| 인원 | 시니어 1명 | 시니어 2명 + 주니어 1명 |
| 주요 도구 | Cursor, Claude Code, Copilot 풀세트 | 동일 (보조 역할로 격하) |
| 시니어 작업 시간의 60% | AI 지시 + 검증 | 도메인 설계, 아키텍처 |
| 운영 버그 발생률 | 2개월 차 정점 | 정점 대비 70% 감소 |
| 월 AI 도구 비용 / 시니어 1명 인건비 | 약 5% | 약 12% |
| 시니어 야근 | 주평균 8시간 | 주평균 1시간 |
그래서, 표를 보면 비용은 분명히 늘었다. 사람을 두 명 더 뽑았으니 당연한 일이다. 다만 운영 안정성과 시니어 번아웃이라는 두 축에서 큰 차이가 났다. 아래는 그 3개월을 시간순으로 풀어본 기록이다. 필자가 속한 작은 팀의 사례이고, 일반화할 의도는 없다.
프로젝트 시작 — AI 풀세트로 가능해 보였다
즉, 3월 초, 사내 결제 모듈 리팩토링과 신규 정산 기능 개발이 동시에 들어왔다. 분량은 백엔드 약 40개 엔드포인트, 프론트 12개 화면이었다. 시니어 한 명이 도구만 잘 쓰면 끝낼 수 있을 거라는 합의가 있었다.
도구 조합은 이랬다.
- Cursor 0.45 (2026년 1월 Agent 모드 GA 직후 버전, 공식 문서 기준)
- Claude Code CLI v1.0.x (Anthropic의 공식 문서 기준, 작성 시점 기준)
- GitHub Copilot (자동완성 보조)
- Sentry + Datadog (모니터링)
근거는 명확해 보였다. AI 도구 월 구독 합계가 시니어 1명 인건비의 5%도 안 됐다. 5년차 시니어가 "잘 쓰는" 조건에서 평균 2~4배 속도가 나온다는 게 당시 사내 합의였다. 그 수치 자체가 공식 벤치마크가 아니라 사내 추산이었다는 점을 미리 밝혀둔다.
1개월 차 — 속도는 정말 빨랐다
이처럼, 첫 4주 동안 결제 모듈 리팩토링이 거의 끝났다. 엔드포인트 25개를 다시 짰고, 테스트 커버리지를 41%에서 67%까지 올렸다. 시니어가 직접 코드를 친 게 아니라 "지시한" 게 더 정확하다. Claude Code에 작업 단위로 지시를 던지면 코드를 짜고 테스트까지 붙여 PR을 올렸다.
즉, 체감상 평소 대비 2.5~3배 빨랐다. 시니어의 작업은 점점 "리뷰와 지시"로 바뀌었다. 이때까지는 모든 게 좋아 보였다.
게다가, 다만 1개월 차 끝 무렵, 작은 신호가 보였다. PR 머지 후 운영에서 발생한 버그 3건이 전부 "AI가 짠 코드의 미묘한 경계 조건"이었다. 한 건은 환불 처리에서 0원 트랜잭션을 막지 못한 거였고, 두 건은 동시 요청 처리에서 락이 안 걸린 거였다. 에러는 단순했다.
psycopg.errors.SerializationFailure: could not serialize access due to concurrent update
원인을 추적해보니, AI가 짠 트랜잭션 격리 수준이 기본값이었다. 사람 시니어가 짰다면 정산 도메인에서는 SERIALIZABLE을 기본으로 두는 게 사내 규칙이었다. AI는 그 사내 규칙을 모른다.
2개월 차 — 정산 기능에서 막혔다
실제로, 문제는 신규 정산 기능에서 본격적으로 터졌다. 결제 모듈 리팩토링은 "기존 코드의 재작성"이라 AI가 패턴을 잡기 쉬웠다. 신규 정산은 달랐다. 회계 규칙, 부가세 처리, 환불 시점에 따른 정산 역산. 도메인 지식이 깊게 박혀 있어야 했다.
Claude Code가 잘 짠 부분, 못 짠 부분
실제로, Claude Code에 비즈니스 요구사항을 그대로 입력했더니 "정상 케이스"는 잘 짰다. 카드 결제 → 정산 → 정산금 지급, 이 시퀀스는 깔끔했다. 못 짠 부분은 이런 것들이었다.
- 한국 부가세 환급 처리 (월별 vs 분기별 차이)
- 카드사별 정산 주기 차이 (D+1, D+2, D+3 혼재)
- 부분 환불 시 정산금 재계산 (이미 지급된 정산금 회수)
이런 케이스마다 시니어가 직접 개입해야 했다. 직접 짜는 게 빠른 경우도 생기기 시작했다.
어디서 시간이 빠지는지 측정했다
결국, 2개월 차 3주차에 시간 측정을 다시 했다. 시니어가 실제로 코드를 짜는 시간은 줄었다. 다른 시간이 늘었다.
- AI가 짠 코드의 도메인 검증: 일평균 2.5시간
- 잘못 짠 부분 다시 지시 (프롬프트 재작성 포함): 일평균 1.5시간
- 운영 버그 디버깅 (AI가 짠 코드 한정): 주평균 6시간
:::stats 시니어 시간의 약 60%가 "AI 검증과 수습"에 들어가고 있었다. 직접 짜는 게 빠를 거라는 의심이 처음 들었다. :::
$500M 펀딩 뉴스가 슬랙에 돌았다
2개월 차 중반, 한 스타트업이 대규모 펀딩을 받았다는 뉴스가 개발자 슬랙들에서 돌았다. 정확한 회사명과 액수는 매체마다 표기가 달랐다. 물론 공통 메시지는 명확했다. "AI로 사람을 대체하는 게 아니라, AI로 못 하는 일을 사람으로 채운다"였다.
따라서, 각 매체가 짚은 핵심은 대체로 세 가지였다 (강조점은 조금씩 달랐다).
- 도메인 깊이가 필요한 영역에는 여전히 사람이 필요하다
- AI 도구 비용이 빠르게 오르면서 시니어 인건비와 격차가 줄고 있다
- AI 산출물 검증이 새로운 병목이 되고 있다
게다가, 세 번째가 가장 와닿았다. 우리 팀이 정확히 그 상태였다. 펀딩 액수의 진위 여부는 차치하고, "검증 병목"이라는 단어 자체가 그 시점 우리 팀의 진단명이었다.
채용 결정 — 시니어 1명 + 주니어 1명
3월 말, 정확히는 2개월 차가 끝날 무렵 채용을 다시 열었다. 결정 근거는 이랬다.
시니어 추가 — 도메인 검증 분담
한편, 정산 도메인을 깊게 아는 시니어가 절실했다. 회계, 부가세, 카드사 정산 주기. 이건 AI가 못 잡는다. 정확히는 "잡을 수는 있지만 검증을 사람이 또 해야 한다"가 맞다. 검증의 검증이 늘어나면 결국 시니어가 처음부터 짜는 게 빨라진다.
주니어 추가 — AI 도구 운영 분담
의외의 결정이었다. 주니어를 뽑은 이유는 "AI 도구를 시니어가 직접 다루지 않게" 하기 위해서였다. 프롬프트 작성, 결과 1차 검수, 단순 리팩토링은 주니어가 AI 도구와 함께 처리한다. 시니어는 도메인 검증과 아키텍처에 집중한다. 이 분업이 의외로 잘 맞았다.
직장에서 자주 본 패턴이긴 하다. 새 도구가 들어오면 시니어가 먼저 잡고, 결국 시니어 시간이 도구 운영에 갈려나간다. 주니어가 도구를 잡으면 시니어가 자기 일을 할 수 있다.
3개월 차 끝 — 무엇이 어떻게 바뀌었나
5월 말 기준 상태를 정리한 게 도입부의 After 표다. 거기엔 안 들어간 정성적 변화 두 가지가 있었다.
반면, 첫째, 시니어의 발언이 바뀌었다. 1개월 차에는 "AI 없으면 못 한다"였다. 3개월 차에는 "AI는 보조다. 도메인 검증은 사람이 해야 한다"였다. 같은 사람의 발언인데 톤 자체가 달라졌다.
또한, 둘째, PR 리뷰 시간이 줄었다. AI가 짠 PR을 리뷰할 때 시니어는 "이게 비즈니스 룰에 맞나"를 매번 처음부터 검토했다. 사람이 짠 PR은 "왜 이렇게 짰는지"를 묻고 답하는 대화로 끝났다. 두 리뷰의 인지 부하가 달랐다.
한편, 신규 정산 기능은 5월 말 기준 80% 완료였다. 당초 목표는 100%였으니 명목상으로는 실패한 일정이다. 물론 운영 안정성과 코드 품질을 함께 보면 그렇게 평가하긴 어렵다. 1개월 차 끝 무렵 운영에 깔린 AI 코드 일부는 6월에 시니어가 다시 짜고 있다.
다음 프로젝트에선 이렇게 하기로 했다
결국, 회고를 마무리하면서 액션 3개를 정했다. 다음 분기부터 적용한다.
- 신규 도메인 코드는 사람이 먼저 설계, AI는 구현 가속에만 사용한다. 도메인 검증을 AI에 맡기는 시도는 더 하지 않는다.
- AI 산출물 검증 시간을 일정에 사전 반영한다. "AI가 짜면 빠르다"는 가정에서 "AI가 짜면 검증 시간이 30% 추가된다"로 일정 모델을 바꿨다.
- 주니어 + AI 도구 조합을 단순 리팩토링과 보일러플레이트에 적극 적용한다. 시니어를 AI 운영 자체에서 빼낸다.
세 번째가 가장 어색한 결정이었다. 보통 "AI는 시니어 생산성 도구"라는 식으로 이야기되는데, 우리 팀에서는 정반대 결론이 나왔다. 시니어가 AI를 직접 다루면 시니어 시간이 갈려나갔다. 주니어가 AI를 다루면 시니어는 자기 일에 집중할 수 있었다. 이게 일반화 가능한 패턴인지는 잘 모르겠다.
개인 의견
펀딩 뉴스를 본 첫 반응은 "역행하는 결정 아닌가"였다. 3개월 회고를 끝낸 지금은 다르다. AI로 다 되는 영역은 분명히 있다. 도메인 검증이라는 병목은 사람 없이 못 푼다는 게 이번 분기의 결론이다. 개인적으로는 AI 도구 예산을 두 배로 늘리는 것보다 시니어 한 명을 더 뽑는 게 지난 3개월 기준으로는 더 나은 선택이었던 것 같다.
관련 글
- Gemini AI가 수백만 차량에 탑재된다 — Claude 자리를 위협한다는 통념의 함정 – Mercedes·Volvo·Honda에 Gemini가 깔리는 동안 차에서 Claude를 쓰는 그림은 거의 변하지 않았다. 이유는 단순하다.
- 중국 AI 인재 자국 잔류, 실리콘밸리 인재 전쟁 끝나나 – 통계 출력 한 줄 보고 머리가 멈췄다. ‘중국 출신 AI 인재의 미국 잔류율 56% → 38%’를 한 줄로 정리하려다 실패한 기록이다.
- Ferrari + IBM이 AI로 F1 슈퍼팬 만드는 법 — 개인화 프로젝트 회고 – Ferrari + IBM이 노린 슈퍼팬 전략의 구조와, 비슷한 개인화 시스템을 3개월 운영하며 부딪힌 현실을 시간순으로 비교한다.