요약: 컴플라이언스(Compliance) 검토 및 자료 검증을 사례로 들어, Human-in-the-loop 워크플로우에서의 작업 분해, 증거 상태, 인적 의사결정, 감사 기록 및 실패 경계에 대해 논의합니다.

키워드: Human-in-the-loop, AI 컴플라이언스 검토, 인적 검토, AI 워크플로우, 감사 로그, 리스크 관리

콘텐츠 추천이나 이미지 생성에서 AI 출력이 이상적이지 않다면 대개 사용자 경험이 저하되는 수준에 그칩니다. 하지만 계약, 구매, 재무, 법무 및 컴플라이언스(Compliance) 시나리오에서는 누락된 강제 조항 하나가 비즈니스 결과에 직접적인 영향을 미칠 수 있습니다.

이러한 시스템은 '모델의 답변'을 프로세스의 종착점으로 삼아서는 안 됩니다. 더 적절한 포지셔닝은 AI가 증거 정리, 차이 발견 및 기초 분류를 완료하게 하고, 반드시 사람이 담당해야 하는 판단은 권한이 있는 역할에게 명확히 넘겨주는 것입니다.

이것이 바로 Human-in-the-loop의 핵심입니다. 페이지 하단에 "결과는 참고용입니다"라는 문구를 넣는 것이 아니라, 인적 검토를 시스템 상태 머신(State Machine)의 일부로 설계하는 것입니다.

그림 1: 컴플라이언스(Compliance) 검토는 먼저 프로젝트, 참고 자료 및 검토 범위를 한정한 후 분석을 시작합니다. 标脉云의 실제 비즈니스 인터페이스 스크린샷.

사실 추출과 비즈니스 판단을 먼저 분리하라

"이 프로젝트가 컴플라이언스(Compliance)를 준수하는가?"라는 질문에는 최소한 두 가지 유형의 작업이 혼합되어 있습니다.

사실 추출(Fact Extraction)은 시스템의 보조를 받아 완료할 수 있습니다. 예를 들어 자격 요건, 날인 요구사항, 권한 문서, 마감 시간 및 무효 조항 등을 찾아내는 것입니다. 반면 비즈니스 판단(Business Judgment)은 기업의 실제 자료, 권한 제도 및 리스크 선호도를 결합해야 합니다. 예를 들어 특정 자격이 충족되는지, 특정 편차가 수용 가능한지 등을 판단하는 것입니다.

두 유형의 작업을 분리하면 출력 구조를 다음과 같이 설계할 수 있습니다:

Requirement
  - source evidence
  - extracted condition
...

모델은 "찾음", "누락 가능성 있음", "충돌 존재" 등과 같은 기계적 상태를 제시할 수 있지만, 최종적인 "충족", "미충족", "보완 필요"는 권한이 있는 인원이 확인해야 합니다.

긴 답변 대신 응답 매트릭스(Response Matrix)를 사용하라

고위험 시나리오는 단순히 자연어 요약 한 단락만을 출력하는 것이 적합하지 않습니다. 긴 텍스트는 가독성은 좋지만 항목별로 확인하기 어렵고 책임 할당에도 불리합니다.

응답 매트릭스(Response Matrix)는 요구사항을 독립적인 항목으로 나누고, 각 항목에 출처, 현재 증거, 리스크 등급, 담당자, 마감 시간 및 검토 상태를 포함하는 데 더 적합합니다. 이렇게 하면 항목별 처리가 용이할 뿐만 아니라, 중요한 요구사항이 모델에 의해 문단 중간에 작성되어 아무도 후속 조치를 하지 않는 상황을 방지할 수 있습니다.

리스크 등급 또한 모델이 완전히 자유롭게 결정해서는 안 됩니다. 먼저 명확한 규칙을 수립할 수 있습니다. 직접적인 자격 상실을 초래하는 조항은 고위험(High Risk), 자료 보완이 필요하지만 처리할 시간이 있는 경우는 중위험(Medium Risk), 표현이나 형식 문제는 저위험(Low Risk)으로 분류합니다. 모델은 규칙 매칭을 담당하고, 사람은 경계를 확인하는 역할을 합니다.

인적 검토는 단순한 체크박스가 아니다

페이지에 "읽었음" 버튼만 있다면, 시스템은 사용자가 무엇을 검증했는지 증명할 수 없습니다. 효과적인 인적 검토는 최소한 다음 사항을 기록해야 합니다:

• 검토자 및 그 역할;
• 검토 시간;
• 확인한 문서 버전 및 AI 결과 버전;
• 각 핵심 사항에 대한 결정;
• 수정 전후의 내용;
• 반려, 보완 또는 에스컬레이션(Escalation) 사유.

입력 문서가 변경되면 관련 검토 상태는 무효화되거나 재확인 단계로 진입해야 하며, 기존 결론을 계속 사용할 수 없어야 합니다.

실패 상태를 명시화하라

AI 워크플로우에서 흔히 발생하는 위험한 방식은 타임아웃, 파싱 실패, 낮은 신뢰도를 불완전하지만 정상적인 답변으로 포장하는 것입니다. 더 견고한 시스템은 다음과 같이 구분해야 합니다:

• 문서 파싱 불가;
• 관련 증거를 찾지 못함;
• 충돌하는 여러 증거를 찾음;
• 모델 신뢰도(Confidence) 부족;
• 사용자가 소스에 접근할 권한 없음;
• 작업 실행 타임아웃 또는 서비스 이상.

이러한 상태들은 서로 다른 처리 분기로 진입해야 합니다. 예를 들어 파싱 실패는 파일 교체를 요구해야 하고, 증거 충돌은 인적 선택을 요구해야 하며, 권한 부족 시에는 어떠한 조각도 노출해서는 안 됩니다.

감사 로그(Audit Log)에는 무엇을 기록하는가

사후에 판단 과정을 재구성하기 위해 로그는 입력, 처리, 출력의 세 부분을 모두 커버해야 합니다.

입력에는 파일 버전, 프로젝트 상태, 사용자가 선택한 검토 범위 및 권한 컨텍스트가 포함됩니다. 처리에는 모델 및 프롬프트(Prompt) 템플릿 버전, 검색된 증거 ID, 규칙 버전 및 이상 사항이 포함됩니다. 출력에는 초기 결과, 인적 수정, 최종 결정 및 내보내기 기록이 포함됩니다.

로그가 모든 민감한 텍스트를 무기한 저장하는 것을 의미하지는 않습니다. 시스템은 여전히 데이터 보존 주기, 비식별화(De-identification) 전략 및 접근 권한을 설정해야 하며, 어떤 내용은 해시(Hash)와 참조만 기록하고 어떤 내용은 원본 스냅샷을 반드시 저장해야 하는지 명확히 해야 합니다.

출시 전 검증은 어떻게 하는가

이러한 기능은 단순히 "맞아 보이는" 몇 가지 질문만으로 검증하기에 적합하지 않습니다. 테스트 세트는 다음을 포함해야 합니다:

• 명확히 충족되는 요구사항;
• 명확히 누락된 자료;
• 동일한 요구사항이 여러 문서에서 충돌하는 경우;
• 스캔본 및 표(Table) 내의 핵심 조항;
• 만료되었거나 대체된 문서;
• 접근 권한이 없는 민감 자료;
• 모델이 판단을 거부해야 하는 모호한 질문.

정확도뿐만 아니라 상태 전이(State transition)도 테스트해야 합니다: 작업 실패 시 재시도 가능 여부, 문서 업데이트 후 이전 결론의 무효화 여부, 검토자가 반려했을 때 담당자가 명확한 액션 아이템을 수신하는지 여부, 그리고 내보낸 내용이 최종 승인된 버전과 일치하는지 등을 확인해야 합니다.

결론

고위험 비즈니스에서 AI를 도입하는 목표는 프로세스에서 사람을 제거하는 것이 아니라, 사람의 주의력을 진정으로 판단이 필요한 곳에 집중시키는 것이어야 합니다.

사실, 증거, 기계 상태, 인적 결정 및 버전 기록이 동일한 경로(Pipeline) 상에 놓일 때, AI는 단순히 답을 생성하는 컴포넌트(Component)에서 통제 가능하고, 검토 가능하며, 감사 가능한 워크플로 노드(Workflow node)로 거듭날 수 있습니다.