AI가 빠를수록 사람이 지치는 역설
"LLM을 쓰면 더 생산적이라고 느끼지만, 최근 몇 달 동안 읽기 전부터 어떤 문체와 오류를 보게 될지 안다는 느낌이 부담으로 작용한다."
Geeknews에 소개된 한 개발자의 고백이다. Claude Code로 하루 20배 산출량을 올리면서도 번아웃이 왔다는 역설. 이 글에서 흥미로운 건 LLM 자체에 대한 불만이 아니라는 점이다. 핵심은 반복성이다. 허위 가정, 환각, 단정적인 짧은 문장이 같은 패턴으로 무한 반복되고, 그걸 인간이 끝없이 검토해야 하는 구조가 피로를 만든다.
Hacker News 댓글이 이를 정확히 짚는다. "창의적이고 변화 있는 부분은 LLM이 가져가고, 반복적인 QA 도장 찍기만 남았다." 공장 자동화 시대 조립라인 노동자의 비유까지 등장한다. 속도는 기계가 가져갔고, 단조로움은 사람에게 남겨졌다.
번아웃의 실제 원인: 검증 루프의 부재
팀 리드로서 이 문제를 들여다보면 원인이 선명해진다. 번아웃은 AI를 너무 많이 써서 생기는 게 아니다. AI 생성물을 검증하는 구조 없이 인간이 그 역할을 전부 떠안기 때문에 생긴다.
에이전트가 코드를 쏟아내는 속도는 인간의 검토 속도보다 압도적으로 빠르다. 어떤 댓글 작성자는 "생성 속도가 검토 속도보다 훨씬 빠르고, 팀원이 LLM 생성 문서 30개 짜리 zip 파일을 보내고 바로 검토해달라고 한다"고 썼다. 병목은 AI가 아니라 사람이 됐고, 모든 것의 병목으로 계속 서 있는 게 피곤하다는 말이 나온다.
또 다른 구조적 문제는 멀티태스킹 압박이다. 에이전트 창 3~5개를 동시에 오가며 각 라운드가 몇 분씩 걸리면 극도로 지친다. AI-First 이전에는 개발자가 한 가지에 2시간 이상 집중할 기회가 있었다. 코딩 에이전트는 기술 스택의 폭은 넓혔지만, 깊이 일할 대역폭은 늘리지 못했다.
처방 1: AI가 AI를 검증하게 설계하라
dev.to에 소개된 멀티에이전트 코드 리뷰 파이프라인이 이 문제에 직접적인 답을 준다. 핵심 통찰은 단순하다. 단일 LLM 패스는 본질적으로 확인하는 프로세스라는 것이다. "무엇이 잘못됐나?"고 물으면, 모델은 패턴 매칭으로 문제처럼 보이는 모든 것을 나열하고, 자기 주장을 스스로 검증할 메커니즘이 없다. 철저하게 검토하라고 할수록 false positive가 늘어난다.
해법은 역할이 상충되는 두 개의 서브에이전트다.
- Finder(적대적 발견자): "이 아티팩트를 부수는 것이 당신의 임무다. 잘된 점을 언급하지 마라. 모든 출력은 발견이어야 한다."
- Validator(회의적 검증자): "각 발견을 반증하려고 시도하라. 당신의 기본 입장은 각 발견이 false positive라는 것이다."
두 에이전트를 별도 디스패치로 실행하는 것이 핵심이다. 같은 대화의 두 턴이 아니다. Validator는 Finder의 추론 과정을 보지 못하고, 발견 자체만을 독립적으로 평가한다. 그리고 최종 판정은 세 번째 LLM 호출이 아니라 결정론적 코드가 맡는다. verdict = disproved면 제거, confidence < 70이면 제거, 나머지는 심각도 × 신뢰도로 정렬. LLM에게 판단을 맡기면 앞선 두 단계의 문제를 그대로 재도입하게 된다.
처방 2: 가드레일은 확률이 아니라 코드로 강제하라
같은 맥락에서 dev.to의 결정론적 가드레일 아티클이 중요한 원칙을 제시한다. "프롬프트는 조정하고, 훅은 집행한다."
프롬프트에 "mock 라이브러리를 import하지 마라"고 써두는 것은 요청이다. 확률을 높일 뿐, 절대 막지는 못한다. 반면 Claude Code의 PreToolUse 훅은 쓰기 작업이 디스크에 닿기 전에 실행되고, 위반이 감지되면 exit code 2로 하드 블록한다. 금지된 import가 잠깐이라도 프로덕션 코드에 앉히는 창이 없어진다.
두 채널의 차이는 명확하다:
| 채널 | 동작 | 한계 |
|---|---|---|
| 프롬프트/지시 | 확률 분포를 조정 | 모델이 무시할 수 있음 |
| 결정론적 훅 | 하드 블록 또는 허용 | 우회 불가 |
반드시 지켜져야 하는 제약은 확률 게임에 맡기면 안 된다. 이걸 설계하지 않으면 팀원이 대신 그 역할을 한다.
팀 리드가 실제로 설계해야 할 검증 루프
세 기사를 종합하면 처방이 구체적으로 보인다. AI 코딩 번아웃을 막으려면 팀원의 의지력에 기댈 게 아니라, 검증 부담을 구조적으로 분산시켜야 한다.
1단계: AI 생성 코드의 1차 필터링을 AI에게 돌려줘라. Finder → Validator → 결정론적 Adjudicator 파이프라인이 정확히 이 역할을 한다. 팀원이 10개 이슈 중 8개가 false positive임을 걸러내는 데 에너지를 쓰는 대신, AI가 AI의 출력을 먼저 검증하고 살아남은 것만 인간에게 넘긴다.
2단계: 반드시 지켜야 할 제약은 훅으로 강제하라.
코딩 컨벤션, 보안 규칙, 금지 라이브러리—이것들을 스타일 가이드 문서에만 써두면 에이전트가 무시하는 순간 팀원이 다시 도장 찍기 역할을 맡게 된다. PreToolUse 훅으로 쓰기 전에 차단하면 그 창 자체가 없어진다.
3단계: 에이전트 작업 단위를 명확히 분리하라. 멀티태스킹 번아웃은 에이전트 창을 동시에 여러 개 돌리는 데서 온다. 에이전트가 처리하는 작업의 경계를 명확히 하고, 인간이 개입해야 할 체크포인트를 미리 설계하면 집중 흐름이 복원된다.
전망: '도구 사용자'에서 '워크플로우 설계자'로
"설거지를 대신해주는 기계가 생기면 창작에 집중할 수 있을 줄 알았는데, 정작 내 일을 해주는 기계가 생겨서 나는 설거지만 남게 됐다."
Hacker News의 이 댓글이 현재 많은 팀의 상황이다. AI가 창의적 구현을 맡고, 인간에게는 반복적 검증만 남은 구조. 이 역전을 막는 건 AI 사용을 줄이는 게 아니다. 검증 루프를 설계해서 반복적 검증 자체도 AI에게 맡기는 것이다.
AI-First 워크플로우의 성숙도는 "얼마나 많은 AI 도구를 쓰느냐"가 아니라 "AI 생성물이 인간에게 도달하기 전에 얼마나 잘 필터링되느냐"로 측정된다. 팀 리드의 역할은 개발자들이 AI를 더 열심히 쓰도록 독려하는 게 아니라, AI가 AI를 검증하고 코드가 확률이 아닌 규칙으로 강제되는 파이프라인을 설계하는 것이다. 번아웃은 AI를 과용해서 오는 게 아니라, 그 구조를 설계하지 않아서 온다.