저번 글에서 '빌더'와 판단력의 가치를 이야기했었습니다.

그 판단력의 가치를 증명하는 사례들이 점점 눈에 띄는 것 같아요.

누군가는 에이전트 50개를 병렬로 돌려 이슈 4,000개를 정리했고, 다른 쪽에선 에이전트가 9초 만에 프로덕션 데이터베이스를 날린 사건이 공유됐습니다.

포커스

에이전트에게 얼마만큼의 자율성을 줄 수 있을까요.

열쇠를 돌리자 벌어진 일들

AI 코딩 에이전트가 staging 작업 중 9초 만에 프로덕션 데이터베이스와 볼륨 백업을 동시에 삭제한 사건이 큰 반향을 일으켰습니다.

credential을 잘못 읽은 게 아니었어요. 에이전트가 작업 범위 밖의 파일에서 API 토큰을 스스로 찾아냈고, "이걸 쓰면 되겠다"고 판단한 뒤 실행까지 9초였다고 합니다.

비슷한 시기에 또 다른 사례가 나왔습니다. TypeScript 프로젝트를 Go로 포팅하면서 "테스트가 통과할 때까지 작업하라"고 지시했더니, AI가 테스트 코드 자체를 삭제하고 "All Tests Pass"라고 보고한 거예요.

목표를 달성하라고 했더니, 가장 쉬운 경로를 찾은 셈이죠. 에이전트는 시킨 일을 합니다. 다만 사람이 의도한 방식으로 하리란 보장은 없다는 거죠.

그래도 열쇠를 잡게 되는 이유

문제는, 열쇠를 맡겼을 때의 생산성이 너무 크다는 겁니다.

Peter Steinberger는 Codex 에이전트 50개를 병렬로 돌려 오픈소스 저장소의 이슈 4,000개를 하루 만에 정리했습니다. 13,000개 넘는 미처리 항목에 에이전트 군단을 투입한 건데, "확실하지 않으면 닫지 않는다"는 보수적 원칙을 미리 설정해둔 게 핵심이었어요. 같은 사람이 이후에는 에이전트 전용 임시 실행 환경까지 만들어서, 클라우드 스팟 인스턴스 위에서 에이전트가 자유롭게 빌드하고 테스트할 수 있게 했습니다.

Pieter Levels는 "Claude가 '이건 하루 치 작업이에요'라고 평가한 일을 5분 만에 끝내준다"며 8만 뷰 넘게 공유됐구요.

이 정도 생산성을 경험하고 나면 열쇠를 안 쥐는 게 더 어렵습니다. 그래서 중요해지는 게 '열쇠의 범위'를 어떻게 정하느냐는 질문이구요.

열쇠를 맡기는 법

"LLM에게 생각을 맡기는 건 새로운 틱톡 중독이다"라는 경고가 3만 뷰 넘게 퍼졌습니다. 터미널 3개를 동시에 돌리면 에이전트를 '관리'하는 게 아니라 '살살 달래는' 것이 된다는 거였어요. 세션을 줄이고 문제를 직접 읽는 근육을 유지하라는 권고가 핵심이었습니다.

비슷한 맥락에서 "vanillamaxxing"이라는 개념도 나왔습니다. AI 도구에 수백 개의 플러그인을 덧씌우지 말고 있는 그대로 쓰라는 주장인데요. 부족한 기능은 AI 랩들이 빠르게 채워주니, 래퍼 레이어를 추가할수록 오히려 통제력을 잃는다는 논리였습니다.

그렇다면 에이전트를 여럿 쓸 때는 어떻게 해야 할까요. 에이전트를 '역할'이 아니라 '컨텍스트 단위'로 묶는 게 더 자연스럽습니다. 독립적인 병렬 작업에는 서브에이전트, 실시간 조율이 필요한 상황에는...