모두가 SDK의 도구 실행기(tool runner)를 찾는 이유는 그것이 에이전트 루프(agentic loop)를 숨겨주기 때문입니다. 저는 대신 지침에 따라 파일을 편집하는 작은 도구를 위해 루프를 직접 손으로 작성했습니다. 코드는 더 많아졌지만, 에이전트가 내부적으로 정확히 무엇을 하고 있는지 배울 수 있었고, 이는 파괴적인 작업을 수행하기 전 인간의 승인이 필요했던 첫 번째 상황에서 큰 도움이 되었습니다. 여기 수동 루프와 이를 직접 제어함으로써 얻을 수 있는 이점이 있습니다.

루프의 실체

"에이전트(agent)\

거절(denial)이 is_error: true와 메시지를 포함한 도구 결과(tool result)로서 모델에게 다시 전달된다는 점에 주목하세요. 모델은 "사용자가 쓰기 작업을 거부했습니다"라는 내용을 읽고, 다른 파일을 제안하거나 이유를 묻는 등 적응(adapt)합니다. 도구 실행기(tool runner)가 루프를 숨기고 있다면, 그 사이에 이러한 게이트(gate)를 삽입하는 것은 어색합니다. 하지만 수동 루프(manual loop)를 사용하면 이는 매우 명확해집니다.

추가할 가치가 있는 게이트들

루프를 직접 제어하게 되면, 다음과 같은 자연스러운 게이트들이 나타납니다.

• 승인 (Approval): 파괴적이거나 외부적인 작업(쓰기, 전송, 삭제)에 대한 승인.
• 로깅 (Logging): 모든 도구 호출(tool call)과 결과에 대한 로깅. 이는 에이전트가 왜 이상한 행동을 했는지 디버깅할 때 매우 귀중한 정보가 됩니다.
• 턴 제한 (A turn limit): 혼란에 빠진 에이전트가 토큰을 낭비하며 무한 루프를 돌지 않도록 제한.
• 조건부 실행 (Conditional execution): "이번 세션에서 이미 실행했다면 이 도구 호출을 건너뛰기"와 같은 조건.

let turns = 0;
while (turns++ < MAX_TURNS) {
  // ...
...

언제 다시 실행기(runner)로 돌아가야 하는가

항상 직접 구현(hand-roll)해야 한다는 뜻은 아닙니다. 승인 게이트도 없고, 특별한 로깅도 필요 없으며, 모든 도구가 자동 실행하기에 안전한 에이전트라면, 도구 실행기(tool runner)를 사용하는 것이 코드도 적고 결과도 동일하게 정확합니다. 결정 기준은 의사 결정(decision)과 행동(action) 사이에 개입이 필요한지 여부입니다. 필요하다면 수동 루프를, 필요 없다면 실행기(runner)를 사용하세요.

승인 게이트 외에 직접 구현함으로써 얻은 것은 바로 실질적인 멘탈 모델(mental model)이었습니다. 이제 에이전트가 오작동할 때, 저는 "마법이 깨졌다"라고 생각하지 않습니다. 대신 "모델이 내가 처리하지 못한 tool_use를 반환했다"라거나 "내가 잘못된 형식의 결과(malformed result)를 다시 입력했다"라고 생각합니다. 루프는 머릿속에 담아둘 수 있을 만큼 충분히 작으며, 이를 머릿속에 담아두는 것은 적어도 한 번쯤은 추가 코드를 작성할 가치가 있습니다.