외부 원문 링크
새로운 트렌드: 병렬 AI 에이전트를 활용한 프로그래밍
여러 코딩 에이전트(Claude Code/Codex)를 동시에 돌리는 워크플로가 시니어 엔지니어에게 자연스럽게 자리 잡고 있다. 진짜 병목은 LLM 속도가 아니라 사람의 리뷰 처리량이다.
핵심 요약
Pragmatic Engineer 의 게르겔리는 Claude Code, OpenAI Codex, Cursor 같은 에이전트 CLI 가 주류가 되며 여러 에이전트를 동시에 돌리는 새 워크플로가 퍼지고 있다고 분석한다.
핵심 관찰:
- 병렬화에 잘 적응하는 사람은 시니어/테크 리드 — 이미 여러 작업 흐름 + 코드 리뷰 + 인터럽션 처리 가 일상이라 그 스킬이 그대로 전이됨
- 단일 사용자에게 가장 큰 병목은 리뷰 처리량. Simon Willison, Armin Ronacher 모두 "검토할 수 있는 양에 한계가 있다"고 동일하게 지적
- AI 에이전트는 비결정적이라 다음 엔지니어링 관행을 강제 해야 안정적으로 굴러간다
1. 모든 변경 전 테스트 통과 강제
2. 작고 명세된 작업 단위 (예제 포함)
3. 매 N번째 작업마다 리팩터링 강제
4. 무엇을 했는지 추적 가능한 로그
5. 사소한 변경은 손으로 — 코드베이스 감각 유지
즉 병렬 에이전트는 마법이 아니라 시니어 워크플로의 자동화다.
병렬 에이전트는 '시니어 테크 리드의 일상'을 도구화한 것이다 — 동시에 여러 작업 흐름을 머릿속에 띄우고, 인터럽션을 받으며, 코드 리뷰로 게이팅하는 그 패턴. 따라서 핵심 질문은 '에이전트를 몇 개 띄우느냐'가 아니라 '한 번에 몇 개의 변경을 신뢰성 있게 검토할 수 있느냐' 다. 검토 처리량을 넘는 병렬화는 모두 일하는 척의 환상이다.
면접에서 'AI 도구를 어떻게 쓰세요'에 대답할 때 두 부류로 갈린다.
- 얕은 답변: '코드 자동완성으로 빠르게 짭니다'
- 깊은 답변: '병렬 에이전트를 띄우되 테스트 통과 강제 / 작업 분할 / 리뷰 게이팅 으로 신뢰성을 확보합니다'
후자는 실제로 운영해 본 사람만 할 수 있는 답변이다. 병렬 에이전트의 함정(검토 병목, 컨텍스트 손실, 묘하게 바뀌는 코드)을 같이 말할 수 있어야 진짜 시니어 신호로 읽힌다.
학습 포인트
면접 답변으로 연결할 학습 포인트입니다.
병목은 LLM 속도가 아니라 리뷰 처리량
병렬 에이전트가 회의적이었던 이유: AI 코드는 검토가 필요하고, 검토가 따라오지 못하면 그저 재고가 쌓이는 공장이 된다.
- LLM은 분당 수천 토큰 생성
- 사람의 코드 리뷰는 분당 수십 줄
- 즉 병렬화의 상한선은 (리뷰 속도) × (집중 가능 횟수)
실제로 성공한 사용 사례는 '주요 작업에 인지 부하를 주지 않는 부수 작업' 에 한정된다 — 리서치, 유지보수성 작업, 방향성이 분명한 작업.
에이전트를 무한히 늘리면 생산성이 비례한다고 가정하는 것. 실제로는 검토 큐가 막히는 순간 음의 생산성으로 전환된다.
병렬 워크플로는 시니어 스킬의 도구화
테크 리드의 평범한 하루는 이미 병렬이다.
- 코드 리뷰 (오프닝)
- 코딩 (메인 작업)
- 스탠드업
- 인터럽션 처리 (질문/리뷰 요청)
- 위임/명세 작성 (RFC, 티켓)
병렬 에이전트는 이 다섯 개의 시니어 일상 스킬을 그대로 요구한다. 따라서 시니어가 자연스럽게 잘하고, 주니어는 컨텍스트 스위칭/리뷰/위임 스킬을 의식적으로 훈련해야 한다.
'AI 가 시니어를 대체한다'고 생각하는 것. 실제로는 시니어 워크플로를 가진 사람이 AI 도구의 레버리지를 가장 많이 받는다.
비결정성 길들이기 — 강제할 다섯 가지 관행
AI 에이전트는 비결정적이라 같은 입력에 다른 결과를 낸다. 신뢰 가능한 워크플로로 만들려면 엔지니어링 관행을 의무화해야 한다.
1. 단위 테스트 — 검증 없이는 자기 코드도 못 믿는다
2. 작고 구체적인 작업 — 범위 + 설명 + 예제
3. 3~4 작업마다 리팩터링 — 메서드 추출/클래스 이동
4. 추적 가능한 로그 — 에이전트가 무엇을 했는지
5. 손으로 직접 — 코드베이스 감각 유지
특히 '테스트가 통과해야 다음 단계로 진행' 같은 게이팅이 결정적이다 — 이는 비결정적 도구를 결정적 워크플로 안에 넣는 표준 패턴이다.
에이전트에게 큰 task 를 한 번에 던지는 것. 큰 task 는 방향이 어긋나도 한참 뒤에 발견되고, 그동안의 리뷰 노력이 통째로 낭비된다.
읽는 순서
- 1이론
Pragmatic Engineer 원문과 Simon Willison 의 "Embracing the parallel coding agent lifestyle" 을 함께 읽고, 본인의 일주일 평균 PR 검토 가능 수 를 추정하세요. 이게 병렬화의 상한선입니다.
- 2구현
한 번 운영해보세요 — git worktree 두 개로 같은 레포에서 두 에이전트를 동시에 돌립니다. 단, 각 작업은 30분 이내 리뷰 가능한 단위 로 쪼개고, 머지 전 테스트 자동 실행을 강제합니다.
- 3실무
팀에 두 가지 메트릭을 도입: (1) PR-to-merge 평균 시간, (2) rollback 비율. 병렬 에이전트 도입 전후 4주씩 비교해 실제로 처리량이 늘었는지(또는 단지 WIP 만 늘었는지) 검증합니다.
- 4설명
팀에 5분짜리 발표를 하세요 — '왜 우리 팀은 동시에 N 개 이상 에이전트를 띄우지 않는가'. N 의 근거 를 검토 처리량과 충돌 빈도로 설명할 수 있어야 합니다.
면접 연결 질문
[감점 답변] '많이 띄우면 빨라진다'. [좋은 답변] 세 가지 축으로 답한다.
- 작업 분할: 한 번에 30분 이내 리뷰 가능한 단위로 쪼갠다 (큰 task = 늦은 발견)
- 테스트 게이팅: 변경 전후 테스트 통과를 자동화로 강제 — 비결정적 도구를 결정적 흐름에 넣는 표준 패턴
- 리뷰 큐 관리: 동시에 검토 가능한 변경 수를 N으로 제한, 초과분은 대기
추가로 '주요 작업의 인지 부하' 를 보호하는 식으로 부수 작업만 병렬화한다고 답하면 점수가 더 높다.
[감점 답변] '경험 차이'. [좋은 답변] 병렬 에이전트는 컨텍스트 스위칭, 코드 리뷰, 위임 명세 작성, 인터럽션 처리 같은 시니어 메타 스킬을 그대로 요구한다. 즉 도구는 기존 워크플로를 증폭할 뿐이라 워크플로가 약하면 노이즈가 함께 증폭된다. 따라서 도구 도입 전에 '한 번에 몇 개의 변경을 신뢰성 있게 검토 가능한가' 같은 자기 한계 측정이 먼저다.
[감점 답변] '잘 안 쓰면 느려진다'. [좋은 답변] 세 가지 안티패턴.
- 묶음 변경: 5개 PR이 같은 파일에 충돌하는 변경을 만들어 병합 비용이 폭발
- 에이전트 간 가정 충돌: A는 함수 X를 그대로 두는 가정, B는 X를 수정하는 가정 — 동시에 머지하면 묘하게 깨짐
- 리뷰 큐 적체: 검토를 미루다 컨텍스트를 잃고 'looks good' 으로 통과 → 결함이 운영까지 흘러감
방어책: 같은 모듈에는 동시 1개만, 머지 전 충돌 감지 자동화, 리뷰 24h SLA.
자기 점검
LLM 토큰 속도가 시스템 처리량을 결정한다는 오해. 실제로는 가장 느린 단계 = 사람의 리뷰가 상한선이다.
'AI라 어차피 가끔 틀린다'고 받아들이는 태도. 실제로는 결정적 게이트로 둘러싸면 비결정성을 운영적으로 길들일 수 있다.
'코딩 실력만 늘리면 된다' 는 생각. 실제로는 명세 작성/리뷰/컨텍스트 스위칭 같은 시니어 일상 스킬이 도구 효과를 결정한다.