절차를 주는 것과 판단을 주는 것은 다르다

PRD를 입력값으로 받아서 구현(implementation)부터 subagent끼리 동작하는 에이전트 하네스를 요즘 만들면서 계속 신경 쓰는 지점이 있습니다. 동작 자체는 생각보다 빨리 됩니다. 모델은 이미 충분히 강하고, 역할을 나누고, 파일 단위로 상태를 주고받게 하고, 프레임워크의 best practice를 강제하면 기본적인 실행 흐름은 만들어집니다.

제가 어려움을 느낀 지점은 그 다음이었습니다.

• 사람이 계속 붙어 있지 않아도, 에이전트가 의도한 방향을 유지할 수 있는가?
• 코드베이스에는 맞지만 서비스 관점에서는 틀어진 결과를 어떻게 감지할 것인가?
• 절차를 수행한 것처럼 보이는 것과 실제 판단을 한 것을 어떻게 구분할 것인가?

이 질문 때문에 하네스 엔지니어링보다 llm 생태계에서의 seed와 eval을 더 보게 됐습니다.

동작과 통제는 다른 문제였다

초기에는 특정 프레임워크의 best practice를 지키게 하는 도구를 넣었습니다. 코드베이스의 패턴을 읽히고, 구현 방식이 크게 벗어나지 않도록 했습니다. 효과는 있었습니다.

• 코드 스타일은 안정됨
• 프레임워크 패턴은 더 잘 지켜짐
• 파일 구조가 덜 흔들림
• 구현물은 코드베이스에 더 잘 맞음

하지만 이 기준만으로는 충분하지 않았습니다. 코드는 맞는데 서비스 앞단이 깨질 수 있었습니다.

• 유저별 권한이 맞는가?
• 사용자가 실제로 만나는 흐름이 자연스러운가?
• 운영 중 벌어지면 안 되는 상태가 차단되는가?
• 실패했을 때 멈추거나 회수되는 기준이 있는가?

이런 기준은 프레임워크 best practice만으로는 잘 잡히지 않습니다. 코드베이스에 맞는 결과물과 서비스 관점에서 맞는 결과물은 다릅니다. 초기 하네스는 전자를 어느 정도 정렬했지만, 인간의 개입 없이 자생적으로 동작하기엔 후자를 충분히 강제하지는 못했습니다.

메일박스는 소통을 만들지만, 판단을 만들지는 않는다

하위 에이전트들의 컨텍스트를 분리하고 싶었습니다. 한 대화 안에 모든 역할이 섞이면, 어느 순간부터 누가 어떤 판단을 했는지 흐려집니다. 그래서 파일 기반 mailbox 구조의 아이디어를 떠올렸고, 도입을 하였습니다.

agent A
  → mailbox
    → agent B
      → review
        → next action

구조 자체는 의미가 있었습니다. 각 에이전트가 상태와 산출물을 파일 단위로 남기면, 다음 에이전트가 그것을 읽고 이어갈 수 있습니다. 하지만 “서로 주고받아라”는 지시만으로 유의미한 리뷰가 생기지는 않았습니다. 에이전트는 최소 1회 메시지를 남기는 식으로 절차를 만족할 수 있습니다. 문제는 그 메시지가 실제 검토인지, 통과 의례인지입니다.

리뷰가 판단이 되려면 기준이 필요합니다.

• 어떤 조건이면 반려해야 하는가?
• 어떤 근거가 있어야 승인할 수 있는가?
• 어떤 항목은 자동 판정하고, 어떤 항목은 사람이 봐야 하는가?
• 정상 케이스와 위험 케이스를 어떤 데이터로 축적할 것인가?

메일박스는 transport에 가깝습니다. 판단은 별개의 레이어입니다. 이 지점부터 하네스는 단순 실행 구조가 아니라, eval 구조를 포함해야 한다고 보게 됐습니다.

eval은 마지막 채점표보다 넓다

기존 프로그래밍이나 ML에서 평가는 비교적 선명한 경우가 많았습니다. golden case를 위한 데이터 라벨링을 통해 준비할 수 있다면 더 선명해질 수 있었습니다.

input
  → output
    → expected output / metric

테스트가 통과하는가. 정확도가 얼마인가. latency가 기준 안에 들어오는가. 정해진 metric이 좋아졌는가.

LLM과 에이전트 작업으로 오면 evaluation 평가 대상이 더 넓어지게 되었다고 저는 생각합니다.

• 도구를 맞게 호출했는가?
• 권한과 보안 조건을 놓치지 않았는가?
• 실패해야 할 케이스를 실패시켰는가?
• 사람이 봐야 할 구간을 지켰는가?

여기서는 unit test만으로 충분하지 않습니다. golden case도 필요하고, red case도 필요합니다. 정상적으로 유지되어야 하는 기준 사례와, 절대 통과하면 안 되는 위험 사례가 같이 있어야 합니다.

golden cases  → 반드시 유지되어야 하는 정상 기준
red cases     → 절대 통과하면 안 되는 실패/위험 기준
eval gate     → 다음 단계로 넘기기 전 멈추는 문
human review  → 자동 판정이 부족한 구간의 회수 지점

제가 생각하는 eval은 작업이 다음 단계로 넘어가도 되는지, 사람이 봐야 하는지, 아예 멈춰야 하는지를 나누는 기준에 가깝구나 라고 생각했습니다. 이러한 고민들이 1+1 수식처럼 명확하게 떨어지지 않으니 직관, 전략적 사고에 대한 중요성을 또 한번 생각하게 되었습니다.

seed는 시작 프롬프트가 아니다

또한 요즘 관심 있는 seed는 에이전트가 작업을 시작하기 전에 심어두는 방향, 제약, 우선순위, 금지 조건에 가깝다고 생각합니다.

seed → 방향 / 제약 / 우선순위 / 금지 조건
action → 에이전트가 수행하는 단위 작업
eval → golden case / red case / rubric / gate
human review → 자동 판정이 부족한 구간의 회수 지점

seed가 약하면 액션은 평균적인 구현 작업으로 흘러갑니다. eval이 약하면 결과물은 그럴듯하지만 신뢰하기 어렵습니다. 이 둘은 따로 떨어져 있지 않았습니다. 결과가 이상하면 결과물만 고치는 것으로 끝나지 않았습니다. 왜 그렇게 나왔는지 다시 묻고, 어떤 기준이 비어 있었는지 확인하고, 다음 실행에서 seed나 eval 후보로 반영해야 했습니다.

저는 이 흐름을 회귀 질의응답처럼 보고 있습니다.

결과물 확인
  → 왜 이렇게 나왔는지 질문
    → 비어 있던 기준 확인
      → 다음 seed / eval 후보로 반영

액션이 넓을수록 판정은 흐려진다

한 달 정도 orchestrate skill 작업하면서 가장 크게 느낀 것은, 제 나름대로 구분을 지었다고 생각했지만 과정별로 보면 하나하나가 넓어 보였습니다. 그러면서 중복 권한 / 권한 과다 현상도 보이게 되었습니다. 목적이 많아질수록 평가 기준도 많아져야 합니다. 그런데 액션을 크게 묶어버리면 무엇을 통과로 볼지 애매해집니다. 그래서 이후에는 subagent 액션 단위, 권한 단위를 분리하고, 각 과정의 eval, seed에 대해서 고려를 하게 되었습니다.

하네스에서 보고 싶은 것은 방향이었다

하네스는 결과물을 일관되게 만드는 데 도움이 됩니다. 하지만 일관성만으로는 충분하지 않았습니다. 제가 보고 싶었던 것은 단순히 같은 형식의 산출물이 아니었습니다. 사람이 계속 붙어 있지 않아도 에이전트가 의도한 방향을 유지하고 있는지, 어긋났을 때 어디서 회수해야 하는지 볼 수 있는 구조였습니다.

그래서 지금은 하네스를 이렇게 보고 있습니다.

seed
  → action
    → eval gate
      → human review
        → regression learning
          → next seed

아직 완성된 방법론이라기보다, 실험하면서 점점 선명해지는 관점에 가깝습니다. 동작은 빠르게 만들 수 있습니다. 어려운 것은 사람이 덜 개입해도 방향이 유지되는 구조라고 생각합니다. 에이전트에게 절차를 주는 것과 판단을 주는 것은 다릅니다. 제가 seed와 eval을 더 보게 된 이유도 결국 여기에 있습니다.