"바보 같은 질문은 없다"는 우리가 서로에게 건네는 다정한 말 중 하나이며, 사람 사이에서는 실제로 그렇다. 청구 관련 코드가 어디 있는지 묻는 신입 동료는 시스템의 구조를 배우는 중이며, 그 질문은 공유된 맥락을 쌓아주고 답하는 데 1분이면 충분하다. 하지만 자율 에이전트는 이제 막 적응 중인 신입 동료가 아니다. 에이전트는 당신이 이 문장을 읽는 시간 동안 저장소 전체를 읽을 수 있다. 에이전트에게는 정말로 바보 같은 질문이 존재하며, 그중 가장 어리석은 것은 스스로 살펴보기만 하면 답할 수 있었던 질문이다.
에이전트에게 바보 같은 질문이란
바보 같은 질문이란 이미 코드베이스 안에 답이 존재하는 질문이다. "이걸 처리하는 코드는 어디 있나요?" "빌드 명령어가 뭔가요?" "이런 종류의 일에 이미 정해진 패턴이 있나요?" 사람이라면 입사 첫날 이런 질문을 하는 것이 합리적일 수 있다. 하지만 에이전트가 이런 질문을 한다는 것은, 스스로 찾아 나서는 대신 맥락을 떠먹여 받는 쪽을 택했다는 선언이나 다름없다—정작 찾아내는 일이야말로 에이전트가 당신보다 명백히 뛰어난 바로 그 일인데도 말이다.
판단 기준은 그 답이 "발견 가능한가"이다. 파일을 읽거나, 트리를 grep하거나, CI 설정을 확인하거나, 해당 영역을 건드린 최근 커밋 몇 개를 읽어서 도달할 수 있는 답이라면, 그것을 당신에게 묻는 것은 신중함이 아니다. 원래 자신이 해야 할 일을 당신에게 떠넘기는 것이다.
비동기 에이전트는 질문의 대가를 하루 단위로 치른다
바로 옆에 앉은 채팅 어시스턴트에게 질문은 저렴하다. 당신이 바로 거기 있고, 답하면, 작업은 계속된다. 하지만 TaskGoblin은 당신 옆에 앉아 있지 않다. 이슈 배정이나 멘션, 새로운 머지 리퀘스트에 의해 트리거되며, 당신이 회의 중이거나 잠들어 있거나 다른 시간대에 있는 동안 샌드박스 안에서 작업을 수행한다. 그런 세계에서 질문은 잠시 멈추는 것이 아니라 완전한 정지다.
"이걸 services/에 둘까요, lib/에 둘까요?"라고 묻고 기다리는 에이전트는, 몇 분이면 끝났을 실행을 당신이 다음번에 우연히 스레드를 볼 때까지 끝나지 않는 실행으로 바꿔버린다. 잘못된 순간에 던져진 단 하나의 예/아니오 질문이 30초짜리 실제 사고와 맞바꾸어 하루치의 실시간을 소모시킬 수 있다. 에이전트를 가치 있게 만드는 바로 그 비동기적이고 사람이 개입하지 않는 모델이, 피할 수 있었던 질문을 이토록 값비싸게 만드는 원인이기도 하다.
과잉 명세는 같은 실수를 시점만 앞당긴 것
질문이 많은 에이전트에 대한 자연스러운 방어책은 모든 것을 미리 답해두는 것이다—디렉터리 구조를 프롬프트에 붙여넣고, 명령어를 나열하고, 명명 규칙을 일일이 설명하고, 따라야 할 패턴의 조각까지 포함시킨다. 책임감 있어 보인다. 하지만 이는 같은 실수가 변장을 한 것일 뿐이다.
손으로 작성한 맥락은 코드가 앞으로 나아가는 순간부터 낡아간다. "저장소 계층은 app/Repositories에 둔다"라고 프롬프트에 미리 적어 넣을 때, 당신은 그것이 여전히 사실이라는 것, 관련된 모든 세부 사항을 빠짐없이 기억했다는 것, 그리고 그중 어느 것도 에이전트를 어제의 방식으로 편향시키지 않는다는 것에 내기를 거는 셈이다. 대개 이 내기 중 적어도 하나는 틀리고, 이제 에이전트는 스스로 읽을 수 있었던 진실 대신 당신이 제공한 사실 위에서 자신 있게 작업을 쌓아 올린다. 당신은 진짜 일—시스템의 현재 상태를 이해하는 일—을 그 일에 "관한" 일로 대체했고, 그 과정에서 결과물은 오히려 나빠졌다.
훌륭한 에이전트는 스스로 자신의 질문에 답한다
해법은 더 나은 프롬프트가 아니다. 당신의 지시를 목표로 삼고 스스로 사실을 확인하러 가는 에이전트다.
그래서 TaskGoblin의 실행은 검토 대상인 diff뿐 아니라 작업 트리 전체를, 저장소를 통째로 샌드박스에 클론하는 것으로 시작한다—근거가 되는 사실이 바로 그 자리에서 읽힐 수 있도록 하기 위해서다. 파일을 읽고, 변경할 영역의 이력을 읽고, 실행을 촉발한 이슈와 그에 달린 논의를 읽으며, 같은 스레드의 이전 실행에서 넘겨받은 인계 메모리를 읽는다. 누군가 6주 전에 프롬프트에 입력해 둔 빌드 명령어를 믿는 대신, 샌드박스 안에서 프로젝트 자체의 명령어를 실행해 실제로 무엇이 빌드되고 무엇이 통과하는지 확인할 수 있다. 당신의 도구에서 실시간 상태가 필요할 때는, 당신에게 전달을 부탁하는 대신 연동을 통해 직접 읽어온다.
그 결과 에이전트는 훌륭한 엔지니어가 한 시간 동안 코드를 읽고 나서야 도달했을 이해에 도달한다—다만 몇 초 만에, 그것도 누군가의 기억이 아니라 오늘의 코드를 기준으로 그렇게 한다.
그래도 물어야 할 때
이 모든 것이 에이전트가 절대 아무것도 묻지 말아야 한다는 뜻은 아니다. 물을 가치가 있는 질문은 코드가 진정으로 답할 수 없는 것들이다—받아들일 수 있는 두 가지 동작 중 실제로 어느 쪽을 원하는지, 위험이 따르는 마이그레이션이 이번 범위에 포함되는지, 오직 당신의 머릿속에만 존재하는 제품 관련 결정. 이런 것들은 바보 같은 질문이 아니다—당신만이 내릴 수 있는 판단이며, 훌륭한 에이전트는 추측하는 대신 이를 이르고 명확하게 드러낸다.
이 구분이 핵심이다. 코드가 어디 있는지 묻는 에이전트는 자신이 가장 잘하는 것을 낭비하고 있는 것이다. 두 제품 중 당신이 실제로 만들려는 것이 무엇인지 묻는 에이전트는, 당신이 가장 잘하는 유일한 일에 당신의 시간을 쓰고 있는 것이다. 우리는 TaskGoblin이 전자와 같은 질문에는 스스로 답하도록 만들었다—그래서 당신에게 도달하는 질문은 정말로 당신의 주의를 기울일 가치가 있는 것들뿐이도록.
