에이전트가 복잡한 질문을 받았을 때, 한 방향을 정한 뒤 끝까지 밀고 가는 방식이 있다. 다른 방식은 초반에 몇 개의 가설을 가볍게 세우고, 각각을 조금씩 확인한 다음 더 늦게 선택한다. 둘 다 결국 도구를 호출하고 답을 만든다. 차이는 답을 찾는 속도보다, 처음의 추측을 언제 의심하느냐에 있다.

첫 방식은 단순하다. 검색 결과 하나가 그럴듯하면 다음 검색도 그 방향으로 이어진다. 흐름이 자연스러워서 실행 과정도 짧아 보인다. 문제는 초반의 방향이 틀렸을 때다. 뒤의 도구 호출은 틀린 가설을 검증하기보다 그럴듯하게 꾸미는 재료가 되기 쉽다. 탐색 경로가 길어질수록 되돌아가기도 귀찮아진다. 사람도 그렇고 에이전트도 크게 다르지 않은 모양이다.

가설을 나눠 보는 방식은 처음부터 정답 후보를 여럿 선언하자는 얘기는 아니다. 가설을 확정된 판단이 아니라, 다음 탐색을 안내하는 임시 표지로 둔다. 한 연구는 독립된 탐색 가지에서 근거를 비교한 뒤 선택하는 접근을 제안한다. 핵심은 병렬 호출 자체가 아니라, 약하거나 불완전한 경로를 바꿀 수 있도록 비교 지점을 남기는 데 있다.

이 방식에도 비용은 있다. 가지를 늘리면 도구 호출과 비교해야 할 정보가 늘어난다. 하지만 한 경로를 너무 오래 따라간 뒤 처음으로 돌아가는 비용도 만만하지 않다. 그래서 비교의 기준은 “가설을 많이 만들 수 있는가”가 아니라, 현재 근거만으로 한 방향에 맡길 이유가 충분한가가 된다.

과학적 발견을 다룬 다른 연구는 이 문제를 더 노골적으로 보여 준다. 후보 설명을 명시적으로 유지하고, 예측과 관찰이 어긋나면 설명 자체를 고친다. 여기서 중요한 것은 실패한 실험이 단순한 감점이 아니라 다음 가설의 입력이 된다는 점이다. 답을 낸 뒤 틀렸다고 말하는 것과, 틀린 이유가 다음 탐색을 바꾸는 것은 다르다.

다만 가설을 고친다는 말만으로 안전해지지는 않는다. 실행 기반 구조를 스스로 개선하는 에이전트도 피드백을 받아 성능을 올릴 수 있지만, 그 개선이 다른 과제나 다른 실행 모델로 그대로 옮겨가지는 않는다는 결과가 있다. 피드백은 유용하지만, 무엇을 측정했는지와 어디까지 적용되는지는 따로 남겨야 한다.

내가 보기에는 에이전트의 탐색을 답변 생성으로만 보면, 빠른 경로가 늘 좋아 보인다. 반대로 초기 단서가 약하거나 확인 비용이 큰 문제라면, 답을 조금 늦추고 가설을 비교할 자리를 만드는 편이 낫다. 선택 기준은 결국 가설의 개수가 아니라, 틀린 첫 판단을 발견했을 때 경로를 바꿀 수 있는가에 있다.