사람들이 '에이전트'라고 부르는 것들의 대부분은 LLM 호출 한 번이면 끝날 워크플로우입니다. 50줄짜리 재정의.

맞는 말임. 근데 더 큰 숨겨진 비용은 디버깅이야. 워크플로우가 깨지면 어디서 실패했는지 정확히 알 수 있거든. 근데 에이전트가 이상한 짓을 하면, 어디서 환각(hallucination)을 일으켜서 엉뚱한 길로 샜는지 47번의 추론 루프를 다 읽어봐야 해. 테스트할 땐 완벽하게 작동하던 에이전트가, 고객한테 보내야 할 결과를 자기 자신한테 메일로 보내버려서 월요일 절반을 원인 파악하는 데 쓴 적이 있어. 흐름도만 있었어도 바로 잡았을 문제지.

디버깅은 아무도 처음에 고려하지 않는 세금 같은 거지. 워크플로우는 단계마다 실패 경로가 하나뿐이지만, 에이전트는 모델이 선택할 수 있는 모든 분기점마다 실패 가능성이 곱절로 늘어나. 그래서 버그 하나가 생기면 '47번의 턴 중 어디서 잘못된 거지? 그리고 이게 재현 가능할 정도로 결정론적이었나?'라는 의문이 드는 거야. 월요일에 스스로 이메일 보내는 게 그 전형적인 예시지. 사후 추적은 도움이 되지만, 애초에 버그를 막으려면 기본적으로 결정론적인 설계가 필수야. 그 단계를 가드레일이 있는 에이전트 방식으로 유지했어, 아니면 고정된 방식으로 다시 짰어?

정치 연구 추적기 만들면서 똑같은 고민 했음. 처음엔 에이전트 방식으로 짰는데, 법안 찾고 요약해서 슬랙으로 보내는 게 60% 정도만 성공하더라. 비결정론적이라 버그 잡기가 너무 빡셌음. 결국 결정론적 파이프라인 3개로 쪼개서 LLM 호출 한 번씩만 하게 바꿨더니 훨씬 나음.

이건 좀 말이 안 됨. 'LLM 호출 한 번'이라는 건 에이전트 프로세스에 대한 상위 인터페이스를 말하는 것뿐임. 실제로는 LLM 호출 엄청 많이 일어남. 그냥 안 보이는 것뿐이지.

에이전트가 숨겨진 호출을 많이 한다는 건 동의해. 하지만 기준은 호출 횟수가 아니라 누가 흐름을 제어하느냐야. 워크플로우도 네가 순서를 정해놨다면 LLM을 50번 호출해도 여전히 워크플로우지. 모델이 런타임에 다음 단계를 결정할 때 비로소 에이전트가 되는 거야. '한 번의 호출'이라는 건 말 그대로 요청 한 번을 의미하는 게 아니라, 고정된 제어 흐름을 뜻하는 약어였어.