지나가는 생각과 작업 메모를 정리한 글.

간단히 느낀 점

오픈클로를 사용하면서 느꼈던 점들을 간단히 정리해둔다. 주로 답답했던 부분과, 그걸 해결하려고 시도했던 방식들이다.

commit 했다고 하는데 안 되어 있다. 파일을 만들었다고 하는데 위치가 이상하다. “다 했다”는 말은 실제 상태랑 맞지 않는 경우가 많다. 다음 단계로 진행 해야 하는데 중간에 멈춰있다. 오류가 생겼는데 보고를 안한다.

이런 문제들이 종종 있어서 더 좋은 방식을 찾기 위해 시도하고 있다.

내가 시도한 것들을 하나로 정리하면, 에이전트가 작업한 결과를 신뢰할 수 있도록 만드는 작업이다.

처음에는 단순히 프롬프트로 해결하려고 했지만, 잘 지켜지지 않는 경우가 많았다.

메인 에이전트는 메시지 전달만 담당하기

메인 에이전트는 오케스트레이터로만 사용한다. 직접 작업은 하지 않고, 작업을 나누고 상태를 모아서 전달하는 역할만 한다.

실제 작업은 서브 에이전트가 맡는다. 각 에이전트는 작업이 끝나거나 문제가 생기면 메인 에이전트에게 상태를 보고한다.

이렇게 하지않고 메인에이전트가 직접 작업을 하게 되면 작업이 길어질 때 중간에 대답을 못하게 된다. 그래서 메인 에이전트는 항상 요청을 받고 응답할 수 있도록 하고,

실제 작업은 큐 형태로 관리하면서 서브 에이전트에게 맡기는 방식으로 구성한다. 이렇게 나누면 작업이 길어져도 사용자와의 통신이 끊기지 않고, 여러가지 작업을 동시에 진행하기도 더 수월해진다.

Task ID 기준으로 관리하기

모든 작업에는 Task ID를 붙인다.

이걸 기준으로 상태를 추적하고, 나중에 확인할 때도 이 ID를 기준으로 본다.

ID가 없이 진행하면 작업 단위가 흐려져서 어디까지 진행됐는지 확인하기 어렵다.

이 ID를 기준으로 세션 관리도 하면, 여러작업을 할 때에도 작업이 꼬이지 않는다.

어떤 문제가 생겼을 때도, ID를 기준으로 언급하여 상황을 명확히 할 수 있다.

작업의 현재 상태를 파일로 기록한다.

작업의 단계에 따른 상태를 정의한다.

상태의 가장 기본적인 규칙은 다음과 같다.

  • 상태를 확인한다.
  • 작업을 시작하면 상태를 기록하고,
  • 단계가 끝날 때마다 업데이트한다.
  • 다음에 뭘 해야 할지는 이 상태를 보고 판단한다.

에이전트가 하는일은 “상태파일을 보고, 현재 상태에 대한 작업을 하고, 상태를 업데이트 하는것”으로 추상화하는것이다.

이게 잘 작동하려면, 상태가 어떤 파일에 있다는 것 뿐만아니라 그리고 상태를 읽는 방법, 업데이트 하는 방법도 정의해야 한다.

이런 상태를 상태를 파일로 남기는 이유는 그게 더 명확하기 때문이다.

세션이 기억하고 있지만, 모호하기도하고 세션이 바뀌거나, 다른 에이전트가 이어서 작업할 때도 있다. 상태가 이렇게 명확하게 남아있어야 작업이 이어질 수 있다.

“상태” 라고 하여 좀 추상적이지만 종류는 다양하다. 가장 흔한 것은 체크리스트 형식의 Task 목록.

작업이 설계단계인지, 구현단계인지, 검증단계인지 같은 단계 구분도 상태로 남길 수 있다. 이런 상태는 보통 작업이 이루어지는 레포지토리에 남기기도 하고, Task에 대한 상태만 저장하는 공간에 저장하기도 한다.

결과는 검증 가능하게 남기기

“완료했다”는 말은 믿지 않는다. 검증 가능한 결과만 본다.

예를 들어

  • commit 했다면 hash를 출력하게 하고
  • 배포했다면 URL을 출력하게 한다

이렇게 해야 실제로 수행됐는지 확인이 된다.

작업 경로를 명확하게 지정하기

경로는 항상 명확하게 지정한다.

상대 경로나 애매한 경로를 쓰면 파일이 엉뚱한 위치에 생성되는 경우가 많았다.

그래서 작업 기준 경로를 정해두고 그 안에서만 작업하도록 제한한다.

실패에 대한 대응

오류가 나면 리포트하도록 한다. 당연한 처리인것 같지만, 실제로 실패시 보고가 안되는 경우가 많다.

그냥 멈춰있는데 왜 그런지 아직도 잘 모르겠다.

추가로 작업이 일정 시간 안에 끝나지 않으면 Timeout으로 간주하여, 실패로 처리하는 규칙도 추가했다.

오류에 대해서는 최대한 어떤 문제가 생겼는지, 어디서 문제가 생겼는지 보고하도록 하여 최대한 추척가능하게 만들었다.

진행 상황은 최대한 자세히 보고받기

진행 과정은 최대한 드러나게 한다.

  • 어떤 Task인지
  • 어떤 에이전트가 작업 중인지
  • 어느 단계까지 왔는지

이걸 계속 출력하게 해서 지금 뭐가 되고 있는지 볼 수 있게 만든다. 특히 뭔가 잘못되거나 멈춰있을 때, 어디서 문제가 생겼는지 알 수 있도록 하는 게 중요했다.

Cron, Skill, Agent 지침을 조합해서 작업을 반복 실행하기

전체적으로는

  • cron
  • skill
  • agent 지침

이 세 가지를 조합해서 특정 작업을 반복 실행하고, 예상한 작업을 하는지 확인하고 있다.

skill에는 작업의 세부적인 단계와 단계별 지침을 작성했는데, 전략에 따라 달라질 수 있도록 strategy를 조합해서 활용할 수 있도록하였다.

예를들면 웹 검색이라도, 트렌드 조사인지, 특정 정보에 대한 자세한 조사인지, 상품 검색인지 등 상황에 따라서 다른 전략을 취해야 하기 때문에 웹검색의 기본적인 절차는 알려주지만 상황에 맞는 전략을 지정해서 활용할 수 있도록 했다.

마무리

이런식으로 직접 뭔가 잘 안되는것을 계속 느껴보고 시도해보는 과정이 생각보다 원활하지는 않지만, 어떻게 하면 더 잘 작동할지 가설을 만들고, 시도해보는 과정이 중요하다고 생각한다. 새로운 도구나 새로운 모델이 계속 나오지만, 직접 시도하고 발견한 것의 가치는 쉽게 대체되지 않는다고 생각해서 계속 해보고 있다. 완전히 정리된 글은 아니지만 이런식으로 시도해보고 느낀 점들을 기록하는 것이 나중에 도움이 될 것 같아서 메모 겸 남겨본다.