코딩 에이전트는 왜 이렇게 멍청할까
Why are coding agents so dumb?
TL;DR Highlight
모델은 좋아졌는데 에이전트(하네스)가 병목이라는 불만과 이상적인 에이전트 목록
Who Should Read
Claude Code·Codex·OpenCode 같은 코딩 에이전트를 매일 쓰며 병렬 처리·모델 선택·보안 때문에 답답한 개발자
Core Mechanics
- 모델과 에이전트는 다르다
- 모델은 텍스트를 만드는 두뇌, 에이전트는 그 텍스트를 파일·명령에 연결하는 몸이라고 구분한다.
- 글쓴이는 모델이 큰일을 하고 에이전트가 병목이라고 본다.
- 작업을 쪼개고도 하나씩 실행한다
- OpenCode는 약 1.5k줄 변경(패스프레이즈 기능)을 10개 하위 작업으로 나누고도 순서대로 처리했다.
- Claude Code는 서브에이전트를 한두 개 띄우지만 전부 끝날 때까지 기다린 뒤에 다음으로 넘어간다.
- 모델 위임을 못 한다
- 5만 줄 패턴 검사 같은 단순 작업도 비싼 최신 모델이 그대로 한다.
- 반대로 어려운 작업에서 더 똑똑한 모델을 부르지도 않아서, 모델과 사고 수준 전환을 사람이 직접 해야 한다.
- 계획서가 읽기 괴롭다
- Codex + GPT-6 Astra의 계획은 저수준 설계 결정을 두서없이 나열한 수준이었다고 한다.
- 그래서 계획 검토를 건너뛰고 바로 구현시키게 됐다고 한다.
- 사소한 질문에 멈춰서 밤새 기다린다
- 자기 전에 시킨 긴 작업이 git 브랜치 이름을 묻느라 2분 만에 멈췄다.
- 아침까지 답을 기다리며 아무 일도 하지 않았다.
Community Reactions
- 서브에이전트로 대부분 해결된다는 의견
- 서브에이전트를 쓰라고 하거나 Haiku/Sonnet 같은 모델을 지정하면 된다는 댓글이 있었다.
- 멈춤은 /loop, 보안은 샌드박스로 풀린다는 주장이다.
- 최신 모델에서는 위임이 잘 된다는 경험
- OpenCode에서 메인 모델에게 서브에이전트 모델을 고르게 했더니 난이도를 판단해 상당 부분을 다른 모델에 넘겼다는 경험이 있었다.
- 최근 3~4개월간 최신 모델이 병렬 작업과 위임을 잘한다는 의견도 있었다.
- 기본 설정이 병렬을 밀어주지 않을 뿐이라는 경험
- 사내 Qwen 3.6 서버에서 OpenCode는 순차 TODO로 동작했지만 QwenCode는 서브에이전트 약 6개를 바로 병렬 실행했다는 경험이 있었다.
- 그래서 서버에서 QwenCode 요청을 단일 큐로 직렬화해야 했다고 한다.
- Claude의 자기 문서 검색은 의도된 동작이라는 반론
- 시스템 프롬프트의 Academy Skill이 Claude 관련 질문에 문서 카탈로그를 확인하게 한다는 설명이 있었다.
- 하네스가 모델보다 앞서 나간 기능은 모델이 모르기 때문이라는 의견도 있었다.
How to Apply
- 서브에이전트와 모델을 프롬프트로 지정하기
- 오늘 쓰는 에이전트에 "독립 작업은 서브에이전트로 병렬 실행하고, 단순 검사는 저렴한 모델에 맡겨라"라고 명시한다.
- 아래 코드 예시를 붙여 넣고 병렬 실행 여부를 확인한다.
- 에이전트를 repo 디렉터리 안에 가두기
- 파일 접근 제한을 "부탁" 프롬프트가 아니라 OS 수준 샌드박스로 건다.
- 접근 범위는 작업 repo 하나로 두고 다른 repo는 세션별 읽기 전용으로 연다.
- 무인 작업 시작 전에 결정 규칙 주기
- 긴 작업을 맡기기 전에 브랜치 이름 같은 사소한 결정은 스스로 정하라고 프롬프트에 적는다.
- 질문이 꼭 필요하면 모아서 마지막에 하게 한다.
- 계획은 상위 수준부터 쓰게 하기
- 계획을 요청할 때 UI 변경이나 데이터 모델 같은 상위 수준에서 시작해 세부로 내려가라고 지시한다.
- 구현 전에 사용자 관점 문서를 함께 먼저 쓰게 하는 방법도 댓글에 나왔다.
Try It
# Claude Code / Codex / OpenCode 등 코딩 에이전트에 붙여넣기 (글쓴이가 바라는 동작을 프롬프트로 옮긴 간이 버전)
작업: {{작업 설명}}
진행 규칙:
1. 먼저 작업을 하위 작업으로 나누고, 서로 의존하지 않는 것을 표시해라.
2. 의존하지 않는 하위 작업은 서브에이전트로 병렬 실행해라.
3. 코드 검색·패턴 확인처럼 단순한 작업은 가장 저렴하고 빠른 모델에 맡겨라.
4. 테스트를 기다리는 동안 커밋 메시지 규칙 확인처럼 겹칠 수 있는 일을 먼저 해라.
5. 브랜치 이름 같은 사소한 결정은 묻지 말고 스스로 정해라. 꼭 필요한 질문은 마지막에 모아서 해라.
계획 작성 규칙: 상위 수준(UI 변경 또는 데이터 모델)부터 시작해 세부로 내려가라.
이어서 해 볼 것: 하위 작업이 실제로 병렬 실행됐는지 로그로 확인해 봐라.Terminology
관련 논문
같은 시뮬레이션, 다른 근거: 도구 출력을 파일로 넘기면 LLM 에이전트 정확도가 어디서 깎이나
긴 툴 출력을 파일로 넘기자 GPT-5.1은 정확도 11.3%p 하락, 정식 출력 지정하니 회복
가짜 뉴스가 진짜 폭락을: LLM 트레이딩 에이전트 대상 정보 주입 공격
가짜 헤드라인 한 줄로 LLM 트레이딩 에이전트 62%를 조종했다(프롬프트 주입은 14%)
Harness Engineering 101: LLM은 뇌, harness는 몸
에이전트는 JSON 배열을 관리하는 루프이고, 16개 챕터로 직접 만들어 본다
Harness²: 에이전트 harness를 스스로 고쳐 쓰는 재귀 최적화 프레임워크
모델은 고정하고 harness를 재귀로 고쳤더니 벤치마크 점수가 최대 11.8%p 올랐다
해고된 Savannah 경찰관, ICE 요원 남편에게 Flock 계정 공유
경찰관이 Flock 계정을 남편(ICE 요원)에게 공유했고, 감사에서 983건 검색이 드러나 해고됐다
tmux와 Claude Code: 세션, send-keys, 그리고 한계선
tmux로 Claude Code 여러 개를 돌리면 편하지만 에이전트 4개쯤에서 한계가 온다
Hybrid Reasoning Agents: 잠재 공간에서 생각하고 텍스트로 행동하는 LLM 에이전트
잠재 공간 추론과 텍스트 도구 호출을 섞었더니 성능 10.4%↑, 토큰 최대 54.7%↓