AI 에이전트가 빌드까지 하는 시대, 6년차의 하루 워크플로를 다시 짰습니다

 

어제 새벽 3시, 클로드 코드(Claude Code)가 lint와 테스트까지 마친 PR 일곱 개를 머지하고 있었어요. 저는 자고 있었고요. 아침에 출근해서 그 PR들을 훑어보다 손이 잠깐 멈췄습니다.

 

"이걸 내가 짠 게 맞나"가 아니라, "앞으로 내가 뭘 해야 돈을 받지"가 떠올랐거든요. 6년차의 익숙한 루틴이 그때부터 흔들리기 시작했어요.

 

클로드 코드·데빈이 PR까지 만드는 현장

상반기에 데빈(Devin)이 인프라 배포 단계까지 자율로 처리하는 걸 옆에서 보고, 그 다음 주에 클로드 코드를 야간 큐(Claude Code Routines)에 붙여본 게 결정타였어요. 계획부터 구현, 테스트, 디버그, PR 생성까지 사람 개입을 최소화한 채로 굴러가더군요.

 

수치만 보면 한동안 과장이라고 생각했습니다. 개발자의 84%가 AI 도구를 사용하고, 전체 코드의 41%는 AI가 생성한다는 조사가 돌고 있어요. 한 사내 연구에선 PR 리뷰 사이클이 31% 단축됐다는 보고가 함께 인용되는 편입니다.

 

문제는 조직 단위 체감은 10% 안팎에 머문다는 점이에요. 30% 안팎을 쥐어짜낸 개인의 시간이 어디로 흘러갔는지가 이번 워크플로 재설계의 출발점이었습니다.

 

병렬 워크트리(worktree) 세 개를 띄워놓고 반나절을 굴려본 다음에는, 코드 리뷰 에이전트가 시니어 대비 수십 배 싸다는 자료가 더 이상 마케팅 문구로 안 읽혔습니다. 코딩 속도는 분명 빨라졌어요. 다만 병목이 사라진 게 아니라 리뷰·검증 쪽으로 옮겨간 것으로 보입니다.

 

 

AI 에이전트 위임 기준, 직접 쥘 영역 가르기

가장 먼저 한 작업은 위임의 기준을 한 장으로 정리한 거였어요. 이걸 안 적어두면 매번 "이건 누가 할까"로 흔들리거든요.

 

위임하는 영역 — 명세가 명확하고 반복적인 일

 

1. 보일러플레이트 CRUD와 단위 테스트 작성
2. 라이브러리 마이그레이션 (예: AGP 메이저 업그레이드 전후 그래들(Gradle) 설정 정리)
3. 명세서가 있는 화면 단위 UI 구현
4. 의존성 충돌·빌드 캐시 정리 같은 환경 작업

 

제가 끝까지 쥐는 영역 — 문제가 불분명한 일

 

도메인 모델 설계, 모호한 요구사항을 스펙으로 깎는 작업, 장애 회고와 근본 원인 추적. 이쪽은 에이전트한테 넘기면 "그럴듯한 답"이 나오는데, 그게 가장 위험한 답이더라고요. 시니어가 돈값 하는 자리는 결국 여기라고 봅니다.

 

이 기준을 깐 다음에 하루를 세 층으로 나눴습니다.

 

• Tier 1 (오전, 인터랙티브): 사람 머리가 필요한 작업. 에이전트 끄고 진행.
• Tier 2 (오후, 병렬): 워크트리별 에이전트 2~3개 동시 운영. 머지 충돌·게이트 통과 못 한 것만 직접 개입.
• Tier 3 (퇴근 전, 야간 큐): 명확한 프롬프트·스펙으로 정리한 백로그를 큐에 등록. 자고 일어나면 PR이 와 있음.

 

처리량은 확실히 늘었습니다. 더 컸던 변화는 정신적 단편화가 줄었다는 점이에요. 인터랙티브와 감독을 시간대로 분리하니 머리가 덜 갈리는 느낌이었어요.

 

 

코딩 병목이 리뷰로 옮겨간 6년차의 하루

새 워크플로를 한 달 굴려보니, 코딩 시간은 줄었는데 리뷰 시간이 하루 2~3시간으로 늘었습니다. 개인 생산성과 조직 생산성 격차의 정체가 여기 있다는 생각이 들었어요.

 

그래서 리뷰는 3단 게이트로 운영하고 있습니다.

 

1. AI 1차 필터 — 정적 분석·테스트·관례 위반 자동 차단
2. 제가 보는 2차 — 도메인 정합성·설계 의도 일치 여부
3. 시니어 3차 — 신뢰도 통과한 코드만 최종 리뷰로 전달

 

AI 리뷰는 1차 필터일 뿐이고, 최종 책임은 사람이 진다는 선을 분명히 그어둔 게 컸어요. 이걸 흐리면 "에이전트가 통과시켰는데요" 라는 변명이 슬금슬금 들어옵니다.

 

병렬 작업도 한계가 분명했어요. 처음엔 5개까지 띄워봤는데, 4개부터는 컨텍스트 스위칭 비용이 폭증해서 제가 먼저 뻗더라고요. 개인적으로는 동시 운영 3개가 현실적 상한이라고 봅니다. "감독이 코딩보다 힘들다"는 평이 왜 도는지 그제야 이해가 됐습니다.

 

 

손이 굳지 않게 잡아두는 주간 루틴

여기서 한 가지 솔직한 걱정이 있어요. 위임만 쌓다 보면 손이 굳습니다. 그러면 1차 리뷰 정확도가 같이 떨어져요. 리뷰어가 코드를 못 읽으면 그건 더 이상 게이트가 아니라 통과 도장입니다.

 

그래서 주간 단위로 세 가지를 박아뒀어요.

 

1. 맨손 코딩 4시간

 

주 1회, 금요일 오전에 에이전트 다 끄고 직접 키보드로 한 기능을 끝까지 만듭니다. 손이 굳는 걸 막는 게 첫 번째 목적이고, 두 번째는 에이전트가 짠 코드를 읽을 때의 직관을 유지하는 거예요.

 

2. 고가치 기술 학습 5시간

 

RAG 아키텍처, LLM 파인튜닝, MLOps. 에이전트가 아직 잘 못 따라오는 영역이라는 평가가 많은 자리입니다. Supervisor 역할만으로는 미래가 불투명하다는 게 솔직한 제 판단이에요.

 

3. 장애 대응은 위임 금지

 

새벽에 알람이 울리면 제가 직접 들어갑니다. 근본 원인 추적 능력은 한 번 잃으면 회복이 어려운 영역으로 보입니다. 이걸 놓치면 시니어 자격증을 반납하는 셈이라고 생각해요.

 

 

6년차가 'Supervisor'로 살아남기 위한 한 가지

도구는 또 바뀝니다. 지금의 클로드 코드와 데빈 자리에 내년엔 다른 이름이 와 있을 거예요. 그 사이클에서 흔들리지 않으려면, 위임의 기준을 글로 적어두는 일이 생각보다 큽니다.

 

여러 구현안 중에서 최선을 고르는 판단력은 도구가 주지 않아요. 그건 장애 한 번 깊게 다뤄본 경험, 형편없는 코드 리뷰 한 번 받아본 기억에서 옵니다. 그 자산을 지키면서 에이전트한테 처리량을 빌리는 것, 그게 미드-시니어가 "주니어보다 비싸고 시니어보다 약한" 자리로 밀려나지 않는 길이라고 봅니다.

 

다음 글에서는 야간 Tier 3 큐에 프롬프트를 어떻게 깎아 넣는지, 실패율을 낮춘 템플릿 한 장을 풀어볼 생각이에요. 사실 이번 재설계에서 가장 손이 많이 간 자리가 거기였거든요.