활동 로그(Activity log)는 에이전트가 무엇을 했는지 알려줍니다. 결정 로그(Decision log)는 에이전트가 무엇을 고려했고 무엇을 거절했는지도 알려주어야 합니다.

거절된 옵션이 없다면, 나중에 검토하는 사람은 존재하지 않았던 깔끔한 경로만을 보게 됩니다: 모델 B가 선택되었고, 작업이 재시작되었으며, 결과가 성공했다는 식입니다. 모델 A가 왜 부적절했는지, 왜 그대로 머무는 것이 더 나빴는지, 그리고 어떤 새로운 증거가 선택을 바꿀 수 있었는지에 대한 이유는 누락됩니다.

이러한 정보는 신뢰와 복구(Recovery)를 위해 중요합니다. 이를 통해 사람들은 전체 세션을 재구성하지 않고도 결정에 이의를 제기할 수 있습니다.

실행 이력(Execution history)은 필요하지만, 성격이 다릅니다

MonkeyCode의 모델 전환 기록은 커밋 c58bcd4에서 작업 및 사용자, 전환 전/후 모델 ID, 요청 ID(Request ID), 세션 로드 여부, 성공 여부, 메시지, 세션 ID 및 타임스탬프를 저장합니다.

전환 유스케이스(switch use case)는 해당 전환 기록을 생성하고, 대상 설정으로 작업을 재시작하며, 결과를 기록합니다.

이것은 가치 있는 실행 이력입니다. 이는 "어떤 전환이 요청되었고 어떤 일이 일어났는가?"에 답합니다. 아래에 확장된 거절 옵션(rejected-options) 구조는 저의 **설계 제안(design proposal)**이며, MonkeyCode의 현재 스키마나 인터페이스에 대한 주장이 아닙니다.

결과 이전에 결정을 추가하세요

재사용 가능한 기록을 통해 선택(Choice)과 실행(Execution)을 분리할 수 있습니다:

{
  "decision_id": "task-42-model-switch-7",
  "context": "The task needs the required tool-call contract.",
...

핵심 필드는 revisit_when입니다. "거절됨(Rejected)"이 보편적으로 나쁘다는 것을 의미해서는 안 됩니다. 이는 특정 컨텍스트와 증거 집합 하에서 부적절함을 의미해야 합니다.

점진적 공개(Progressive disclosure)를 위한 인터페이스 설계

이 JSON을 메인 작업 타임라인에 그대로 붙여넣지 마세요. 세 가지 계층을 사용하세요:

타임라인 (Timeline):    모델 A에서 모델 B로 전환됨
이유 (Why):         B가 요구되는 도구 호출 (tool-call) 계약을 통과함
세부 사항 (Details):     거절된 옵션 (rejected options) 2개, 증거 (evidence), 작업자 (operator), 실행 결과 (execution result)

첫 번째 계층은 재지향 (reorientation)을 지원합니다. 두 번째 계층은 빠른 신뢰 판단을 지원합니다. 세 번째 계층은 감사 (audit), 디버깅 (debugging), 그리고 이의 제기 (appeal)를 지원합니다.

실행이 실패했을 때는 결정 (decision)과 결과 (result)를 분리하여 유지하세요:

결정 (Decision): 능력 증거 (capability evidence)를 바탕으로 모델 B를 선택함
실행 (Execution): 실패로 인한 재시작; 작업은 모델 A에 남아 있음
복구 (Recovery): 재시도, 다른 옵션 선택, 또는 작업자에게 요청

그렇지 않으면 인터페이스가 선택된 동작이 실제로 효과를 발휘한 것처럼 암시할 수 있습니다.

기록 검증하기 (Validate the record)

동반 검증기 (companion validator)는 컨텍스트 (context), 선택된 증거 (chosen evidence), 최소 하나 이상의 거절된 옵션 (rejected option), 모든 거절에 대한 이유 및 재검토 조건 (revisit condition), 실행 식별자 (execution identity), 소유자 (owner), 그리고 검토 날짜 (review date)를 요구합니다.

node validate-decision-log.mjs decision-log.json
node test-decision-log.mjs

예상 출력:

PASS decision log
PASS complete decision; rejected options without reasons or revisit conditions failed

검증은 이유가 진실인지 여부를 판단할 수는 없습니다. 검증은 누락된 부분을 가시화하고 검토 도구에 안정적인 표면을 제공합니다.

기본값으로 설정하기 전에 패턴을 연구하세요

에이전트 작업을 검토하거나 복구하는 작업자 (operators)를 대상으로 작업 기반 평가 (task-based evaluation)를 수행하세요. 그들에게 두 가지 이력—실행 전용 (execution-only) 이력과 결정 및 거절 포함 (decision-plus-rejections) 이력—을 제공하고 다음을 요청하세요:

1. 동작이 왜 발생했는지 설명하기;
2. 어떤 증거에 이의를 제기할 것인지 식별하기;
3. 실패한 동작 이후 복구하기;
4. 거절된 옵션이 현재 실행 가능한지 결정하기;
5. 어떤 세부 사항이 유용했는지 또는 과도했는지 보고하기.

설명 정확도 (explanation accuracy), 복구 시간 (recovery time), 잘못된 가정 (erroneous assumptions), 그리고 세부 사항 계층의 확장성을 측정하세요. 이 글은 사용자 연구 (user study) 결과를 보고하는 것이 아니라, 해당 연구를 제안하는 것입니다.

거절된 옵션은 결정 경계 (decision boundaries)를 보존할 때 불필요한 정보 (clutter)가 되지 않습니다. 그것들은 에이전트 추적 (agent trace)을 사람이 질문하고, 수리하고, 배울 수 있는 무언가로 바꾸어 주는 반사실적 컨텍스트 (counterfactual context)입니다.

공개 사항: 저는 MonkeyCode 프로젝트에 기여하고 있습니다. 현재의 실행 이력 (execution-history) 필드들은 링크된 고정된 (pinned) 소스에 기반하고 있습니다. 거절된 옵션 (rejected-options) 스키마 (schema), 인터페이스 레이어 (interface layers), 그리고 연구 계획 (research plan)은 제안 사항이며, 독립형 검증기 (standalone validator)는 로컬에서 테스트되었습니다.