AI의 “완료했습니다”를 코드로 검증하기

모든 단계가 성공했는데 완료할 수 없다면

AI가 파일을 수정하고 테스트 명령을 실행한 뒤 “완료했습니다”라고 답했다고 해 볼게요. 그런데 결과 목록에 해결하지 못한 항목이 하나 남아 있어요. 테스트 단계의 상태가 성공이면 전체 작업도 성공으로 처리해도 될까요?

Agent Governance Suite, 줄여서 AGS는 이 경우를 별도로 막아요. 단계별 결과가 모두 성공이어도 미해결 항목이 남아 있으면 전체 작업을 완료 상태로 바꿀 수 없어요. 첫 번째 글에서는 이 작은 조건문에서 출발해 AI 코딩 에이전트의 작업을 어떻게 검증할 수 있는지 살펴보려고 해요.

여기서 코딩 에이전트는 답변을 만드는 데서 그치지 않고 파일 조회, 코드 수정, 명령 실행 같은 도구를 사용하는 AI를 뜻해요. 도구를 사용할 수 있게 되면 답변의 정확성에 더해 실제로 무엇을 실행했고 어떤 상태를 남겼는지도 확인해야 해요.

완료 메시지와 완료 상태를 나누기

사람에게 보여 주는 완료 메시지는 작업 결과를 설명하는 문장이에요. 반면 프로그램이 처리하는 완료 상태는 다음 단계를 실행할 수 있는지를 결정해요. 이 둘을 같은 것으로 취급하면 “테스트를 통과했다”는 설명만으로 배포 단계까지 넘어갈 수 있어요.

AGS의 워크플로는 계획과 실행 결과를 구조화된 데이터로 관리해요. 작업 목표와 범위를 담는 TaskEnvelope, 실행 단계를 담는 WorkflowPlan, 단계 결과인 StageResult, 전체 진행 상태를 담는 WorkflowReceipt가 나뉘어 있어요. 이 이름을 모두 외우기보다는 요청, 계획, 실행 결과를 서로 다른 시점의 자료로 남긴다는 점을 보면 돼요.

아래 코드는 WorkflowService.finalizeWorkflow 안에서 미해결 항목을 검사하는 부분을 그대로 발췌했어요. 바로 앞에서는 현재 작업이 실행 중인 상태인지 확인해요.

if (receipt.blockers.length > 0 || receipt.unresolved.length > 0) {
  throw new WorkflowContractError("GATE_FAILED", "Workflow has unresolved blockers or findings.", {
    blockers: receipt.blockers,
    unresolved: receipt.unresolved,
  });
}

차단 사유인 blockers나 미해결 사항인 unresolved가 하나라도 있으면 예외를 발생시켜요. 따라서 각 단계가 passed라고 보고했더라도 전체 작업을 성공으로 마무리할 수 없어요. “대부분 끝났고 한 가지는 남았다”는 상태가 완료에 섞이지 않도록 만든 조건이에요.

성공 표시만 확인하지 않는 이유

미해결 항목이 없다고 검사가 끝나는 것은 아니에요. 같은 메서드는 계획에 있는 각 단계의 결과를 찾아요. 결과가 없거나 성공 상태가 아니면 완료를 거부하고, 성공 결과가 있어도 다음 검사를 실행해요.

this.assertRequiredArtifacts(stage, result);
this.assertExecutionAssurance(stage, result);
this.assertDeclaredReceiptPolicy(receipt, stage, result);
this.assertEvaluationValidityGate(stage, result);

이 부분도 실제 코드의 연속된 네 줄이에요. 필요한 산출물이 있는지, 선언된 실행 확인 조건과 결과 기록 규칙을 만족하는지, 해당하는 평가 감사 조건이 충족됐는지를 검사해요. 필수 감사 단계가 있으면 그 단계의 성공 여부도 마지막에 다시 확인해요.

예를 들어 “타입 검사 통과”를 완료 조건으로 정했다면, 단계 이름만 typecheck라고 붙이는 것으로는 부족해요. 어떤 코드 상태에 대해 어떤 실행 결과를 근거로 성공이라고 판단했는지 연결할 수 있어야 해요. AGS의 계획과 결과 규격은 이런 연결을 기록하고 검사할 자리를 제공해요.

MCP(Model Context Protocol)는 이 과정에서 AI가 서버의 도구를 호출하는 연결 방식이에요. AGS의 MCP 서버는 단계 결과를 받을 때 revision과 실행 순서를 확인하고, 선언된 JSON Schema에 맞는지도 검사해요. 오래된 상태를 기준으로 결과를 덮어쓰거나 필요한 선행 단계 없이 뒤 단계로 넘어가는 일을 제한하는 방식이에요.

규칙을 읽게 하는 것과 규칙을 검사하는 것

“검증이 끝나기 전에는 완료라고 말하지 마세요”라는 지침도 필요해요. 다만 그 지침은 모델이 이해하고 따라야 하는 문장이에요. 서버에서 완료 요청을 거부하는 조건문과는 작동하는 위치가 달라요.

AGS에는 둘 다 있어요. 스킬 문서는 어떤 판단을 해야 하는지 설명하고, 서버는 제출된 결과가 정해 둔 형태와 상태 전이 조건에 맞는지 확인해요. 모델에게 맡길 판단과 프로그램이 검사할 조건을 나눈 셈이에요.

마지막 행은 앞의 검사를 통과했다고 자동으로 증명되지 않아요. 잘못된 요구사항을 대상으로 모든 테스트가 성공할 수도 있기 때문이에요.

무엇을 검증했고 무엇은 남아 있을까요?

저장소의 workflow-service.test.ts에는 단계가 성공했더라도 차단 사유가 남아 있으면 완료하지 못하는 경우와 독립 감사가 실패한 뒤 완료하지 못하는 경우가 있어요. 실행 순서, revision, 증거 조건을 확인하는 테스트도 함께 정의되어 있어요. 이 글의 분석에서는 테스트 코드의 입력과 기대 결과를 확인했으며, 모델의 실제 작업 성공률을 측정한 것은 아니에요.

주의할 점은 서버가 결과 형식을 검사한다고 해서 결과 내용의 진실성까지 모두 알 수 있는 것은 아니라는 거예요. 특히 계획 밖에서 들어오는 자료의 내용과 출처는 실행하는 전문 스킬이 확인해야 하고, MCP 서버가 확인하는 것은 제출된 참조·digest·검증 선언의 구조예요. 호스트 실행 확인 기능도 실행 관측을 결속하는 장치이지 테스트 설계가 충분했다는 보증은 아니에요.

이 구조에서 얻을 수 있는 효과는 완료를 거부해야 하는 조건을 코드로 명시할 수 있다는 점이에요. AI의 설명을 읽는 일에 더해, 작업의 어느 부분이 아직 끝나지 않았는지 프로그램도 판단할 수 있게 돼요. 기존 시스템에서 주문 상태를 바꾸기 전에 필수 조건을 검사하듯, 에이전트의 작업에도 완료 전 검사를 둘 수 있어요.

다음 글과 소스

다음 글에서는 대화가 압축된 뒤 작업을 이어가는 방법을 살펴봐요. 완료 조건을 정했더라도 긴 작업 중에 그 조건을 잊어버리면 다시 다른 문제를 풀게 될 수 있어요.

이 연재는 AGS 2.7.7의 커밋 f39501e를 기준으로 작성했어요. 이후 버전의 동작은 달라질 수 있어요.

• 완료 판정 구현: workflow-service.ts
• 상태 전이와 완료 조건 테스트
• 아키텍처와 실행 확인의 범위