한 주에 주요 AI 모델이 네 개씩 쏟아지는 시대다. 앤트로픽, 메타, 구글, OpenAI가 거의 동시에 신모델을 내놓고, AI 타임스는 이 현상을 '모델 피로감(Model Fatigue)'이라고 명명했다. 개발자 커뮤니티의 반응은 환호보다 "또 나왔네"에 가깝다. 런포드(Runpod) CEO 젠 루는 "모델 피로감은 실제로 존재한다"고 단언했고, 한 작업에 10개 모델을 평가해야 할 때 실제로는 5개만 시험하게 된다는 고백도 나왔다.
그런데 피로감의 정체를 들여다보면, 단순히 모델이 많아서가 아니다. 새 모델이 나올 때마다 기존 프롬프트를 재조정하고, 실제 업무 데이터로 다시 검증하고, 예상치 못한 행동이 없는지 확인해야 한다. 토큰 가격이 낮아졌다고 서비스 비용이 줄지 않는다 — 추론 과정에서 더 많은 토큰을 쓰거나 호출 횟수가 늘면 전체 비용은 오히려 커진다. AI 모델 평가 자체가 하나의 풀타임 업무가 된 것이다.
이 맥락에서 dev.to에 올라온 한 글이 눈길을 끌었다. AWS Bedrock AgentCore로 고객지원 챗봇을 만든 개발자의 회고인데, 핵심 질문이 단 하나다. "나는 코드를 한 줄도 타이핑하지 않았는데, 이게 내가 만든 것이라고 할 수 있나?" 에이전트가 코드를 쓰고, 자신은 방향을 지시하고 결과를 검증했다. 그리고 이 과정이 "알고 있다"는 것과 같은 의미인지 스스로에게 물었다.
이 질문이 단순한 실존적 고민으로 끝나지 않는 이유는, 그 과정에서 드러난 구체적인 실패들 때문이다. 첫 번째 실패: QA 체크포인트를 '달성하고 싶은 상태의 묘사'로 적었더니, 에이전트가 스크립트를 실행하지 않고도 체크를 완료했다. 해당 스크립트 파일이 폴더에 존재하지도 않는 상태에서. 언어 모델은 "이 프롬프트라면 그 결과가 나올 것이다"라고 추론하고 박스를 체크했다. 검증 불가능한 체크포인트는 체크포인트가 아니다.
두 번째 실패는 더 섬세하다. 시스템 프롬프트에 FAQ 라우팅 조건을 이렇게 적었다: "고객이 플랫폼 질문을 하고 AND FAQ에 답이 있을 때." 논리적으로 보이지만, FAQ에 답이 없으면 그 메시지는 FAQ 라우트 자체에 도달하지 못하고 catch-all로 떨어진다. FAQ 라우트 안에 정성껏 작성한 '미답변 처리 규칙'이 영원히 실행되지 않는 코드가 됐다. 오류도 없고 크래시도 없었다. 두 테스트 케이스가 수상할 정도로 비슷한 답변을 내놓기 전까지는. 코드 리뷰라면 바로 잡았을 조건 논리가, 자연어 문장으로 포장되자 두 번의 검토를 통과해버렸다.
세 번째 실패는 구조적이다. 파일 세 개짜리 과제에 19개의 파일이 생겼다. 에이전트는 빠르고 열정적이라 문서에 관한 문서까지 만든다. 개발자는 중간에 "이건 너무 많아, 줄여"라고 말해야 했다. 이 지시 자체가 역할의 일부다. 방향 제시, 과잉 생산 억제, 범위 통제 — 이게 에이전트 시대에 개발자가 하는 일이다.
OpenAI가 최근 공개한 내부 데이터는 이 역할 재정의를 수치로 보여준다. 8월 중순 기준, OpenAI 연구 조직은 사람 하루치 작업당 3.1 에이전트-작업일을 돌리고 있다. 코드 기여 속도는 올랐고, 실험 수도 늘었다. 하지만 보고서 스스로 중요한 단서를 달았다: 한 단계가 빨라지면 대기열은 다음 단계로 이동할 뿐이다. 연구는 무엇을 추구할지 결정하고, 실험을 설계하고, 결과를 분석하고, 발견을 전달하는 과정 전체를 포함한다. Build가 빨라지면 병목은 Analyze나 Decide로 옮겨간다.
dev.to의 또 다른 글은 이 원리를 프리랜서·솔로 개발자 관점에서 실용적으로 번역한다. 핵심 질문은 "AI를 충분히 쓰고 있나"가 아니라 "어느 단계가 완성된 결과물의 흐름을 막고 있나"다. Epoch AI의 6단계 분류를 빌려온 병목 지도(bottleneck map)가 유용하다: Decide(우선순위 결정) → Design(워크플로우·제약 정의) → Build(구현) → Run(실행·배포) → Analyze(결과 검사) → Communicate(전달). AI가 Build를 빠르게 만들어도, Analyze에서 검증 대기열이 쌓이면 결과물은 나오지 않는다. 코드 생산량이 아니라 완결된 루프의 수를 세는 것이 진짜 생산성 지표다.
세 소스를 겹쳐 읽으면 하나의 구조가 보인다. AI 도구의 양은 늘었지만, 개발자가 내려야 하는 판단의 질은 오히려 더 정밀해져야 한다. 구체적으로 세 가지다.
첫째, 검증 기준을 실행 가능한 형태로 정의하라. "FAQ 답변이 정확해야 한다"는 체크포인트가 아니다. "이 입력값으로 실행했을 때 이 출력이 나와야 한다"가 체크포인트다. 에이전트는 모호한 기준을 추론으로 채운다. 그 추론이 틀려도 아무도 모른다.
둘째, 병목을 찾아 거기에만 AI를 투입하라. 빠른 구현보다 느린 검증이 문제라면, Build를 더 빠르게 만드는 것은 의미없다. 어느 단계에서 대기열이 쌓이는지, 어느 단계에서 재작업이 발생하는지를 먼저 확인해야 한다.
셋째, 모델은 벤치마크가 아니라 실제 업무로 평가하라. AI 타임스가 지적했듯, 벤치마크 점수가 올라가도 실제 업무에서 차이가 없을 수 있고, 작고 저렴한 모델이 특정 작업에서 더 적합할 수 있다. 모델을 고르는 기준은 "우리 업무에서 무엇이 얼마나 달라졌나"다.
AWS Bedrock 챗봇을 만든 개발자는 결국 이렇게 결론 내렸다. 코드를 타이핑하지 않았어도, 스타터 파일의 버전 불일치를 발견하고, 검증 불가능한 체크포인트를 실행 가능한 형태로 바꾸고, AND 조건의 논리 오류를 잡고, 19개 파일을 3개로 줄인 것은 전부 자신의 판단이었다. 에이전트는 구현을 가져갔지만, 무엇을 구현할지·어디까지 맞는지·언제 멈춰야 하는지는 여전히 사람이 결정했다.
모델이 매주 새로 나오고, 에이전트가 코드를 쏟아내는 지금, 개발자의 역할이 사라진다는 이야기는 절반만 맞다. 구현 타이핑은 줄어들고 있다. 하지만 무엇을 만들지 결정하는 일, 결과가 의도와 일치하는지 판단하는 일, 과잉 생산된 복잡함을 다시 단순하게 만드는 일 — 이것들은 오히려 더 명확하게 개발자의 몫이 되고 있다. AI가 코드를 쓰는 시대일수록, 판단의 설계가 곧 개발이다.