AI 코딩 에이전트 워크플로우 정리 — 계획은 사람, 실행은 에이전트, 게이트는 CI

AI 코딩 에이전트를 붙였는데 일이 오히려 늘었다는 얘기를 자주 듣는다. 에이전트가 뱉어낸 300줄짜리 diff를 한 줄씩 뜯어보다가 "차라리 내가 쓰는 게 빨랐겠다" 싶었던 순간, 다들 한 번쯤 있었을 것이다.

그게 도구를 잘못 고른 탓인 경우는 의외로 드물다.

The New Stack이 짚은 2026년의 현업 풍경은 "어떤 도구가 이겼나"가 아니라 "어떻게 일하는 팀이 이겼나"에 가깝다. 도구는 이미 골라 쓰는 물건이 아니라 조합해 쓰는 물건이 됐고, 성과 차이는 워크플로우 설계에서 갈린다.

계획은 사람, 실행은 에이전트, 게이트는 CI

2026년 팀들이 정착한 기본 루프는 하이브리드다. IDE 안에서 사람이 계획을 세우고, 에이전트가 로컬 샌드박스에서 실행하고, 병합 전에는 반드시 CI와 PR 리뷰를 거친다.

세 자리의 주인이 각각 다르다는 게 핵심이다. 계획은 사람, 실행은 에이전트, 게이트는 CI와 리뷰어.

삐걱대는 팀을 보면 대개 이 중 한 자리가 비어 있다. 계획 없이 채팅창에 대고 "이거 고쳐줘"라고 시키거나, 게이트 없이 에이전트가 내놓은 결과를 그대로 병합하거나.

엔드투엔드 루프를 네 단계로 쪼개면

③번에 굵게 표시한 "동일한"이 생각보다 중요하다. 에이전트가 만든 코드라고 별도의 관대한 관문을 두지 않는다. 같은 기준을 통과 못 하면 그냥 떨어지는 것이다.

④번의 on-the-loop도 말장난이 아니다. 모든 단계에 개입하는 in-the-loop가 아니라, 중요한 지점에서 판단만 내리는 자리에 사람이 선다는 뜻이다.

잘 굴러가는 팀의 세 가지 습관

첫째, 작업을 캐주얼 채팅이 아니라 이슈처럼 쓴다. "로그인 버그 고쳐줘"는 요청이라기보다 감탄사에 가깝다. 배경·목표·수용 기준·제약·테스트 명령이 들어가야 한다.

## 배경
결제 완료 후 주문 상태가 간헐적으로 PENDING에 머문다. 최근 2주간 15건.

## 목표
결제 웹훅 수신 시 주문 상태를 확정 처리한다.

## 수용 기준
- 웹훅을 중복 수신해도 상태 전이는 한 번만 일어난다
- 웹훅이 유실되면 5분 내 폴링으로 보정된다

## 제약
- payments 모듈의 공개 인터페이스 변경 금지
- 기존 마이그레이션 파일 수정 금지

## 테스트 명령
./gradlew :payments:test --tests '*OrderStatus*'

여기서 진짜 일하는 건 수용 기준과 테스트 명령 두 줄이다. 에이전트가 "다 됐습니다"라고 말할 근거가 그 두 줄에서 나온다. 반대로 그 두 줄을 못 쓰겠다면, 아직 사람도 무엇을 원하는지 모르는 상태라는 신호다.

둘째, 권한을 프로덕션 시스템처럼 관리한다. 최소 권한, 짧은 수명의 토큰, 샌드박스, 감사 로그. 자율 실행이란 결국 누군가에게 파일 쓰기와 명령 실행 권한을 넘긴다는 뜻이다.

셋째, 결과를 주니어 엔지니어의 PR처럼 리뷰한다. 권위 있는 정답으로 그냥 받아들이지 않는다는 것. 잘 짜인 코드처럼 보이는 것과 맞는 코드인 것은 다른 문제다.

CLAUDE.md, 그리고 모델 역할 분담

repo 루트에 CLAUDE.md를 두는 관행이 자리를 잡았다. 매번 프롬프트에 붙여넣던 설명을 파일 하나로 고정하는 것이다. 넣을 만한 항목은 대략 이렇다.

• 서비스 구조와 도메인 용어
• 코딩 표준 — 네이밍, 레이어 규칙, 금지 패턴
• 자주 쓰는 명령 — 빌드·테스트·린트·로컬 실행
• 반복되는 구현 패턴과 참고할 예시 파일 경로

모델도 역할을 나눈다. 계획에는 더 강한 모델, 실행에는 더 빠른 모델을 쓰는 식이다. 아예 Claude Code와 Codex를 함께 굴리는 팀도 많다. 하나는 데일리 드라이버로, 다른 하나는 까다로운 변경에서 세컨드 오피니언으로.

맡길 것과, 맡기면 손해인 것

거친 기준선 하나. 손으로 2시간 넘게 걸릴 작업이면 에이전트에 넘기는 쪽이 이득이다.

솔직히 말하면 에이전트가 항상 이득은 아니다. 30분짜리 변경은 이슈를 쓰고 결과를 읽는 오버헤드가 절약분을 그대로 먹는다. 도메인 규칙이 코드와 사람 머릿속에만 있는 영역에서는 그럴듯하게 틀린 코드가 나오고, 그 틀림을 찾는 데 시간이 더 든다. 리뷰어가 한 명인 팀에서 에이전트 PR을 쏟아내면 병목이 구현에서 리뷰로 옮겨갈 뿐이다.

합쳐지는 게 아니라 조합되는 중

여기서 원문이 던지는 관찰이 재밌다. Cursor·Claude Code·Codex는 하나의 승자로 수렴하지 않는다. 대신 오케스트레이션·실행·리뷰 레이어로 서로 조합된다.

2026년 4월 초 Cursor는 병렬 에이전트 오케스트레이션 인터페이스를 내놨고, OpenAI는 Claude Code 안에서 도는 공식 플러그인을 내놨다. 경쟁사 제품 안에서 도는 플러그인이라는 게 이 판의 성격을 잘 보여준다.

관측성 스택을 떠올리면 이해가 빠르다. Prometheus가 메트릭을, Grafana가 대시보드를, PagerDuty가 알림을 맡는다. 각자 한 가지를 잘하고, 가치는 조합에서 나온다.

바닥도 깔리는 중이다. ACP(Agent Client Protocol)로 에이전트와 IDE 사이의 통신이 표준화되고 있고, 주요 코딩 에이전트는 거의 다 MCP를 지원한다. 컴포저블 생태계라는 말이 마케팅 수사가 아니라 실제 배선 이야기가 됐다.

국내 팀 사정에 대입해보면 병목이 어디에 생길지는 꽤 분명해 보인다. 네 단계 중 ①과 ④, 그러니까 계획과 리뷰가 전부 사람 몫인데 이 두 자리가 원래 얇은 조직이 많다. 코드 리뷰가 형식적으로 돌아가던 팀이 에이전트를 들이면, 검증 없이 병합되는 코드의 양만 몇 배로 늘어난다.

도입 순서를 뒤집어야 한다고 본다. 에이전트를 먼저 붙일 게 아니라, CI가 실제로 뭔가를 걸러내고 있는지부터 확인하는 게 먼저다. 수용 기준을 테스트 명령으로 옮겨 적을 수 없는 작업이라면 아직 넘길 준비가 안 된 것이라는 기준도 꽤 실용적이다.

권한 이야기도 국내에서는 결이 조금 다르다. 망분리와 반출 규정이 걸린 환경에서는 "샌드박스와 짧은 수명 토큰"이 모범 사례이기 이전에 도입 가능 여부를 가르는 전제 조건에 가깝다.

마지막으로 "2시간 이상 작업"이라는 기준선에는 함정이 하나 있다. 그 2시간이라는 추정 자체가 사람의 감이고, 리뷰 비용은 작업 시간이 아니라 diff 크기에 비례한다. 넘기기 전에 결과물을 읽는 데 얼마가 들지도 같이 세어보는 편이 안전하다.

정리하면

2026년의 AI 코딩 도구는 하나로 합쳐지는 대신 레이어로 나뉘어 조합되고 있고, 팀의 성과를 가르는 건 도구 선택이 아니라 계획–실행–CI–PR로 이어지는 루프를 얼마나 규율 있게 굴리느냐다. 이기는 팀은 제일 좋은 도구를 쓴 팀이 아니라, 워크플로우를 설계하고 뭐가 실제로 먹히는지 측정한 팀이라는 게 원문의 결론이기도 하다.

여러분 팀은 네 단계 중 어디가 제일 헐겁나요? 계획을 건너뛰는 쪽인지, 리뷰가 병목인지 궁금합니다.

---

📎 출처: 원문 보기