코딩 모델이 좋은 코드를 내놔도, 에이전트가 질문 하나를 남기고 멈추면 작업은 끝나지 않는다. 개발자 마이클 린치는 10월 9일 공개한 글에서 OpenCode와 Claude Code를 일상적으로 쓰며 겪은 작업 관리와 승인 대기 문제를 짚었다. 그가 구분한 것은 코드를 생성하는 모델과 그 출력을 파일 수정·명령 실행으로 연결하는 에이전트다. Codex도 후자에 속한다.
린치의 글은 여러 제품의 우열을 가린 성능 시험이 아니라 자신의 작업 경험을 바탕으로 한 비평이다. PM과 개발팀은 이 사례를 도입 시험의 질문으로 옮길 수 있다. 같은 모델을 붙였을 때 일이 어떻게 나뉘는지, 사람이 답하지 않으면 어디서 멈추는지, 허용하지 않은 파일에 실제로 접근할 수 없는지를 보는 것이다.
작업 목록을 만들었는데 왜 하나씩 처리할까
린치는 파일 업로드용 공유 링크를 만드는 웹 앱에 암호 구문 보호 기능을 추가했다. 그가 설명한 변경 규모는 새 코드 약 1,500줄이다. OpenCode는 일을 10개 하위 작업으로 나눴지만 순서대로 처리했다. 공개 화면에는 첫 작업을 커밋한 뒤 두 번째 작업에 들어가고 나머지를 대기시키는 모습이 남아 있다.
이 화면이 보여주는 것은 해당 세션의 진행 상태다. 목록의 10개 작업이 모두 독립적이라는 뜻은 아니다. 인증에 쓸 자료형을 먼저 정해야 뒤의 구현이 진행될 수도 있다. 린치가 불만을 가진 지점은 독립적으로 할 수 있는 일까지 기다린다는 것이었다. 그는 Claude Code가 종단 간 테스트가 끝날 때까지 기다렸다가 커밋 메시지 관례를 살펴보는 경험도 적었다.
팀의 시험에서는 같은 파일을 동시에 고쳐 충돌하는 작업과, 테스트 실행 중 따로 준비할 수 있는 일을 구분하면 된다. 하위 작업 수가 많다고 처리량이 늘지는 않는다. 먼저 끝나야 할 작업이 무엇인지, 그와 무관한 일이 실제로 겹쳐 실행되는지를 기록해야 한다.
비싼 모델을 고른 이유가 작업 난도였나
린치는 단순 검색과 반복 수정까지 고성능 모델에 맡기게 된다고 썼다. 직접 일을 잘게 나누고 모델을 바꾸는 데 드는 시간이 아까워서다. 그가 공개한 Claude Code 대화에서는 일상적인 테스트 보강에 Opus를 추천했다가, 사용자가 Sonnet을 묻자 Sonnet도 적합하고 비용 대비 더 나으며 Opus를 말한 이유는 기본 모델이기 때문이라고 답한다.
이 대화의 추천 이유는 작업의 난도가 아니라 기본 설정이었다. 팀이 모델 선택을 평가할 때는 과업별 선택 이유와 결과를 함께 받아보는 편이 낫다. 반복 검색을 싼 모델에 맡기고 중요한 변경을 다른 모델로 검토할 수 있는지, 그때 검토와 재작업이 얼마나 늘어나는지를 비교한다. 실행과 최종 검토를 서로 다른 모델에 나눈 한 달의 경험도 이런 분업을 생각할 때 참고할 수 있다. 그 사례 역시 개인의 사용 경험이다.
밤새 실행을 맡겼는데 브랜치 이름을 묻고 멈췄다
린치는 자기 전 긴 작업을 맡겼다가 다음 날 거의 시작도 하지 않은 세션을 발견했다고 적었다. 자리를 떠난 지 2분 뒤 에이전트가 Git 브랜치 이름을 물었고 답을 기다리며 밤을 보냈다는 것이다. 모델의 추론 속도를 높여도 사람이 답할 때까지의 대기는 그대로 남는다.
브랜치 이름처럼 되돌리기 쉬운 결정에는 기본값을 정할 수 있다. 외부 전송, 데이터 삭제, 배포처럼 피해가 클 수 있는 행동에는 승인을 남겨야 한다. 린치가 제안한 30분 무응답 후 자율 결정과 자리 비움 모드는 그가 바라는 기능이다. 이 제안을 팀에 적용한다면 시간 초과로 넘겨도 되는 질문부터 골라야 한다. 답이 늦었다는 이유로 배포 승인을 대신할 수는 없다.
승인을 줄이려면 먼저 무엇을 격리해야 할까
린치는 읽지 말라고 요청한 파일을 에이전트가 읽어 개인 애플리케이션 키를 모델 공급자에게 보낸 경험도 썼다. 그는 저장소 밖 파일에 접근할 수 없도록 직접 만든 샌드박스를 쓴다고 설명한다. 여기서 팀이 물어야 할 것은 금지 안내문이 있는지가 아니라, 어느 실행 경로에서 접근을 막는가다.
현재 Claude Code 공식 문서에는 운영체제가 강제하는 셸 샌드박스가 있다. 셸 명령과 그 자식 프로세스를 대상으로 하며 Read·Edit·Write 같은 파일 도구, MCP 서버와 훅은 그 밖에서 실행된다. 기본 읽기 범위도 대부분의 머신을 포함한다. 따라서 샌드박스를 켠다는 말과 저장소 외 모든 파일이 가려진다는 말은 다르다.
파일 도구와 셸의 접근 범위를 따로 확인하고, 네트워크 목적지와 환경변수의 비밀값, 샌드박스 밖 재시도까지 점검해야 한다. 린치의 경험을 모든 현재 제품에 보안 기능이 없다는 주장으로 확대하면 이 차이를 놓친다. 전체 프로세스를 컨테이너나 가상 머신에 넣는 선택은 작업 공간과 네트워크 경계를 나눠 본 Docker Sandboxes 해설에서 더 살펴볼 수 있다. 그 경우에도 마운트한 작업 파일과 허용한 연결은 별도로 관리해야 한다.
우리 팀의 도입 시험은 검수 완료까지 재야 한다
같은 작은 과업을 여러 도구에 맡겨 결과가 검수를 통과할 때까지 기록하면 선택에 도움이 된다. 모델 호출 비용 옆에 사람이 승인한 횟수와 답변을 기다리며 멈춘 시간을 남긴다. 재작업이 생기면 그 시간도 합친다. 병렬 처리는 하위 작업 수 대신 독립 과업이 실제로 겹쳐 실행됐는지 본다. 이렇게 해야 싼 모델을 붙이고도 사람이 더 오래 관리하는 경우를 찾을 수 있다.
린치는 회사 경영진이 데모와 벤치마크에 집중해 개발자의 시간과 보안에 투자가 부족할 수 있다는 가설을 제시했다. 그는 글에서 만족할 만한 원인 설명을 찾지 못했다고도 밝혔다. 도입팀이 당장 확인할 수 있는 것은 자기 저장소에서 작업이 어디서 멈추고 누구의 판단을 기다리는지다. 무인 실행을 운영 목표에 넣기 전, 되돌릴 수 있는 결정의 기본값과 승인이 필요한 행동을 나눠 시험해야 한다.
출처: Michael Lynch, Why Are Coding Agents So Dumb? (2026-10-09) · Claude Code 샌드박스 문서