Goal 이란?

예전에 Team Attention 의 정구봉님과 함께 Naver D2SF 행사에서 모든 에이전트 하네스는 Goal 로 수렴할 것 이다. 라고 다같이 점심을 먹으며 이야기를 했었는데요. 이제는 모든 에이전트 하네스에는 Goal 이라는 기능이 존재합니다.

Goal 이란 기능은 왜 갑자기 등장했고 무슨 의도로 등장하게 된걸까요? 오늘은 Goal 에 대한 이야기를 조금 해보려고 합니다.

루프 엔지니어링(loop engineering)

Goal 에 대해서 이야기 하기전에 최근 핫한 루프 엔지니어링에 대해서 한번 이야기 해봐야 합니다. 루프 엔지니어링에서 루프(loop) 란 에이전트가 어떠한 작업을 목표에 도달할 때 까지 반복하는 과정 이라고 이해하는게 좋습니다.

이를 이해하기 위해서는 우리가 기존에 클로드 코드 또는 코덱스를 사용했을때 어떻게 사용했는지를 다시 되짚어 봐야 합니다. 우리는 흔히 암묵지라 불리는 우리 머릿속에 있는 목표를 생각하며 클로드 코드와 코덱스에게 작업을 해달라고 명령을 하게 됩니다.

예를 들어, 우리가 "클로드 코드 느낌의 싸이트를 만들어줘" 라고 클로드에게 명령했다고 해봅시다. 근데 결과물을 보니 색감이 클로드 색감이 아니여서 다시 클로드 코드에게 이렇게 명령합니다. "아니 클로드 코드의 색감을 먼져 파악하고 작업해야지. 이거 색감이 너무나 다르잖아"

즉, 잘못된 결과가 있을때 우리가 프롬프트 입력을 통해 항상 재개(Resume) 해야만 작업이 다시 시작됬습니다. 이때까지는 루프(loop) 를 재개하는 역할을 사람이 하고 있었던 것 이죠.

이걸 보통 HITL(human-in-the-loop) 라고 부릅니다. 즉, 사람이 반복되는 루프 안에 계속해서 감독관처럼 들어가 있었던 것 이죠.

루프를 디자인 해라(Design a loop)

우리가 이 반복되는 루프 안에서 나오려면 어떻게 해야할까요? 우리가 입력해야 하는 프롬프트를 우리가 스스로 입력하는 것이 아닌 에이전트가 루프를 재개하는 프롬프트를 입력하게 만드는 구조를 설계(Design) 해야 합니다.

이게 바로 최근에 클로드 코드의 제작자인 보리스(Boris cherny) 가 말했던 문장과 같은 의미이죠.

Boris cherny - 클로드 코드 제작자

즉, 기존에 목표에 도달하기 위해 사람이 프롬프트를 반복적으로 입력했다면 무언가 잘못됬다고 말 하는 겁니다. 

그렇다면 이 루프는 어떻게 설계해야 할까요? 어떻게 해야 에이전트가 사람 대신 루프를 재개시키는 프롬프트를 입력하게 만들 수 있는 것 일까요?

명확한 목표를 설정해라

사실 이전에 잘 만들어진 하니스(Harness) 들은 이미 루프 엔지니어링 기법을 이용하고 있었습니다. 여러분의 머릿속에 있는 암묵지를 목표화 하고, 이 목표를 에이전트가 도달할 때 까지 고삐를 채워 목표에 도달하게 합니다. 여러분이 많이 사용하시던 OmO(oh-my-opencode), OmX(oh-my-codex), Ouroboros 와 같은 도구들이죠.

즉, 여러분은 루프를 잘 설계하기 위해서는 반복되는 과정을 종료하기 위한 목표를 설계하셔야 합니다. 아까의 "클로드 코드 느낌의 웹싸이트를 만들어줘" 라는 프롬프트를 목표(Goal) 로 만드려면 우리는 어떻게 프롬프트를 입력하는게 좋을까요?

위와 같이 수치적인 목표를 설정하게 되면 에이전트가 더 비교하기 쉽습니다.

한번 루프를 진행시키고 나면 검증해야할 시간에 수치적으로 90% 이상 유사한지 테스트 해보고, 유사하지 않다면 루프를 다시 진행시키면 되기 때문입니다.

안드레 카파시(Andrej Karpathy)

예전에, 안드레 카파시(Andrej karpathy) 의 오토-리서치(Auto-Research) 가 잘 동작했던 이유도, 수치적인 목표가 존재하고 내부에서 에이전트를 목표에 도달할때 까지 잘 굴릴 수 있는 루프(loop) 를 디자인했기 때문입니다.

근데 이렇게 수치적으로 검증 가능한 루프를 디자인 하면 좋을텐데 일상생활에서는 수치적으로 변환히 어려운 정성적인 평가만이 가능한 부분이 존재합니다. 이러한 루프는 어떻게 디자인해야 할까요?

모호한 루프 디자인

개발단이 아닌 기획단의 정성적인 업무를 진행하다보면 정성적(Qualitative) 으로 평가해야 하는 경우가 많은데요.  이 경우에는 루프를 어떻게 설계해야 할까요?

함께, 모호하다고 느껴지는 목표에 도달하는 루프를 한번 설계해보도록 합시다. 예시로, 네이버에서 "강남역에서 회식하기 좋으면서 남자들이 가기 좋으면서 분위기가 좋은 맛있는 장소 20곳 선정" 이라고 해봅시다.

수치적인 목표가 있는지 파악해라

일단 정성적인것 같아도 꽤나 내부적으로 수치적으로 만들 수 있는 지표들이 보입니다. 예를 들면, "회식하기 좋은", "20 곳" 같은 부분이죠. 첫번째로 "회식하기 좋은" 이라는 목표를 달성하기 위해서는 아래와 같이 목표를 설정해 볼 수 있을 것 같습니다.

이 경우 에이전트에게 음식점 마다 네이버 블로그 리뷰를 보게 하여 이를 수치화 하게 하면 비교 가능한 수치가 됩니다.

두번째로는 "20곳" 이라는 목표를 달성하는 부분입니다. 이건 꽤나 쉽습니다. 에이전트가 한번 루프를 반복했을때 8곳 밖에 조사를 못했다멵 목표에 도달하지 못했으므로 자동적으로 루프가 재개되는 것이죠.

LLM-as-judge

그렇다면 "남자들이 가기 좋으면서 분위기가 좋은" 과 같은 부분은 어떻게 목표를 설계해볼 수 있을까요? 이것도 "회식하기 좋은" 과 같이 키워드 기반의 메트릭을 수집하여 수치적으로 비교하게 해볼 수도 있습니다.

다만 여기서는 조금 더 다른 방법을 이용해볼까 합니다. 바로 검증관(verifier) 를 만들어 보는 것 입니다. 대부분의 하네스에서는 서브에이전트(SubAgent) 라는 기능을 제공하는데요. 이 서브에이전트를 바로 감독관으로 활용하는 방법입니다.

루프를 돌리는 작업자가 맛집을 검색하고 나서 리스트업을 하면 검증관 에이전트들이 루프에 검증구간에서 소환(spawn) 되어 작업 내용을 검증해줍니다. 이를 보통 worker - validator 패턴^[1]​이라고 부릅니다. 앤트로픽이 장기간 에이전트를 돌리는 방법에서 소개되었던 패턴이죠.

근데 여기서 검증관의 판단 조건이나 페르소나를 설정해주면 조금 더 우리의 취향에 맞게 판단하도록 할 수 있습니다. LLM 이 커먼(common) 한 지식은 대부분 학습이 되었기 때문에 아래와 같은 내용도 일반적으로 잘 판단합니다.

이렇게 검증자를 마지막 구간에서 소환하게 되면 좋은 점은 확률 기계인 LLM 의 특성상 자신이 한 작업에 대해서 리뷰를 시키면 옳다고 판단하는 경향이 있는데, 검증자는 아예 새로운 문맥(Context) 에서 시작되므로 이러한 경향성이 줄어들게 됩니다^[2]​. 그래서 조금 더 객관적으로 평가가 가능하게 되는 것이죠.

클로드 코드와 헤르메스 에이전트(Hermes Agent) 의 Goal 은 자동으로 검증관을 소환하도록 설계되어 있습니다.

최대 턴 횟수 지정(Max turn)

이제 이렇게 검증관을 소환하여 20곳을 찾는 경우 검증관이 너무 빡빡하게 검수하여 10시간이 지나도 검색이 완료되지 않는 경우가 존재할 수 있습니다. 이러한 경우에는 토큰만 엄청나게 소비하게 되고, 원하는 결과를 얻지 못할 수도 있겠죠?

그래서 항상 시작하기 전에 최대 턴 횟수를 지정해주어야 합니다. 예를 들면, 아래와 같이 프롬프트를 입력해주는 것이죠.

이렇게 되면 여러분의 토큰이 비정상적으로 쓰이는 케이스를 막을 수 있습니다. 헤르메스 에이전트(Hermes Agent) 의 Goal 은 기본으로 N 턴이상 반복이 안되도록 설계되어 있습니다.

마치며

오늘은 목표 중심의 루프 엔지니어링을 알아보았는데요. 최근 Anthropic 팀의 트위터에 올라온 루프 엔지니어링 기법을 보면 목표 중심의 루프엔지니어링 이외에도 3가지의 기법이 더 존재합니다. 다음 시간에는 나머지 기법에 대해서 다뤄보도록 할게요.

항상 읽어주셔서 감사합니다 :)