책에 포함된 노트운영 가능한 프롬프트 아키텍처: 평가, RAG, 에이전트, 보안까지 (프롬프트 고급)

사람 검토와 AI 검토의 조합

2026-04-30Views 7약 10분생성형 AI 활용

자동 검증기를 붙였다고 해서 검증 시스템이 완성되는 것은 아니다. 진짜 운영 환경에서는 더 어려운 질문이 남는다. 이 결과를 누가, 언제, 어떤 기준으로 최종 통과시킬 것인가?

여기서 많은 팀이 두 가지 극단으로 흔들린다. 하나는 "중요하니까 전부 사람이 보자"는 방식이다. 안전해 보이지만 곧 병목이 된다. 다른 하나는 "AI가 꽤 잘 보니까 자동으로 통과시키자"는 방식이다. 빠르지만 고위험 실패를 한 번 크게 맞을 수 있다. 실무에서 필요한 것은 이 둘 중 하나가 아니라, AI 검토로 넓게 덮고 사람 검토로 중요한 지점을 붙잡는 구조다.¹

쉽게 말해 AI 검토는 공항의 금속 탐지기와 비슷하다. 빠르게 많은 사람을 통과시키고, 의심 신호를 잡아낸다. 하지만 정말 중요한 순간에는 결국 사람이 가방을 열어 본다. 프롬프트 시스템도 같다. 모든 답을 사람이 읽을 수는 없지만, 위험한 답과 중요한 답만큼은 반드시 사람이 보게 설계할 수 있다.

사람 검토와 AI 검토의 조합

검토는 판정이 아니라 흐름이다

이 장의 핵심은 검토를 하나의 점수 행위가 아니라 운영 흐름으로 보는 데 있다. 모델이 답을 만들고, 자동 검증기가 여러 신호를 만들고, 그 신호를 바탕으로 어떤 응답은 바로 통과하고 어떤 응답은 재생성되며 어떤 응답은 사람에게 올라간다. 검토는 여기서 끝나지 않는다. 사람의 수정과 승인 결과는 다시 평가셋, 그레이더, 라우팅 규칙으로 되돌아가 다음 검토를 더 똑똑하게 만든다.¹⁴

이 흐름을 머릿속에 그리면 구조가 단순해진다.

결정적 검사로 명백한 실패를 먼저 걸러낸다.
AI 검토가 대량 트래픽을 빠르게 훑는다.
사람 검토는 고위험, 고비용, 고불확실성 케이스에 집중한다.
사람의 판단은 다시 데이터가 되어 다음 자동 검토를 개선한다.¹

이렇게 보면 사람과 AI는 경쟁자가 아니다. 한쪽은 규모를 담당하고, 다른 한쪽은 책임을 담당한다.

HITL와 HOTL를 구분해야 한다

실무에서 자주 헷갈리는 개념이 있다. 바로 human-in-the-loop와 human-on-the-loop다. 둘 다 사람을 참여시키지만 위치가 다르다.²

human-in-the-loop는 사람이 결과가 실제로 쓰이기 전에 직접 승인, 수정, 거절하는 구조다. 의료 조언, 법률 문안, 금융 승인, 외부 발송 공지처럼 틀리면 비용이 큰 경우에 어울린다. 여기서는 AI가 초안을 만들더라도 마지막 문턱은 사람이 지킨다.

반면 human-on-the-loop는 시스템이 대부분 자동으로 돌아가되, 사람은 감시·감사·개입 역할을 맡는다. 모든 응답을 승인하지는 않지만, 샘플링 결과를 보고 이상 징후가 있으면 멈추고, 임계값을 조정하고, 특정 케이스를 끌어올린다. 고객지원 보조, 내부 검색 도우미, 대량 분류 업무처럼 규모가 큰 환경에서는 이 방식이 현실적이다.²

여기서 AI 검토는 세 번째 축이다. AI 검토는 사람을 대체하는 심판이 아니라, 사람이 어디를 봐야 할지 먼저 알려 주는 선별기이자 계측기에 가깝다. 잘 설계된 시스템은 보통 세 가지를 함께 쓴다. 고위험 응답에는 HITL, 대량 운영에는 HOTL, 그 사이를 메우는 실시간 선별에는 AI 검토를 둔다.

가장 실용적인 구조는 세 겹 검토 스택이다

운영 가능한 검증 구조는 대개 세 겹으로 쌓인다. 첫 번째는 결정적 검사다. JSON 파싱, 필수 필드, 응답 길이, 금지어, 권한 범위, 도구 호출 스키마처럼 맞고 틀림이 분명한 항목은 코드로 검사한다. 이 층은 가장 빠르고 싸며, 매번 돌려도 부담이 작다.¹

두 번째는 AI 검토다. 여기서는 자동 검증 프롬프트나 LLM judge가 사실성, 근거성, 형식 적합성, 과잉확신, 정책 위반 가능성을 본다. 모든 응답을 넓게 덮을 수 있다는 점이 강점이다. 프롬프트를 바꾸거나 모델을 옮길 때도 전체 경향을 빠르게 감시할 수 있다.¹

세 번째는 사람 검토다. 이 층은 가장 비싸지만, 가장 중요한 판단을 맡는다. 규정 해석이 미묘하거나, 브랜드 톤이 애매하거나, 다단계 에이전트 실행이 정말 타당한지 보려면 결국 사람의 문맥 이해가 필요하다. 특히 도메인 전문가가 들어와야 하는 영역에서는 AI 검토만으로는 충분하지 않다.¹²

이 구조가 좋은 이유는 간단하다. 값싼 층이 대부분을 처리하고, 비싼 층은 정말 필요한 순간에만 작동한다. 즉, 검토 품질과 운영 비용을 동시에 관리할 수 있다.

모든 답을 사람에게 올리지 말고, 위험을 점수화하라

사람 검토의 병목은 대개 우선순위가 없어서 생긴다. 큐에 들어온 순서대로 보거나, 단순히 랜덤 샘플만 보면 정말 중요한 건 놓치고 덜 중요한 것에 시간을 쓰게 된다. 그래서 사람 검토 앞에는 반드시 위험도 기반 우선순위가 필요하다.

가장 실용적인 방법은 응답 하나마다 위험 신호를 모아 간단한 위험 점수를 만드는 것이다. 복잡한 수학이 필요한 것은 아니다. 운영팀이 이해하고 설명할 수 있는 수준이면 충분하다. 보통 다음 다섯 축이 유용하다.

영향도: 이 답이 잘못되면 금전 손실, 법적 문제, 고객 피해, 내부 혼란이 얼마나 큰가.
행동 가능성: 사용자가 이 답을 바로 실행할 가능성이 큰가. 단순 정보인지, 실제 조치로 이어지는지 본다.
불확실성: AI 검토 점수가 낮거나 판정기 사이에 충돌이 있는가.
근거 빈약성: 문서 근거가 약하거나 citation이 불완전한가.
새로움과 이상치성: 훈련된 패턴 밖의 요청인지, 최근 실패 유형과 닮았는지 본다.

예를 들어 내부 정책 도우미가 "연차 신청은 어디서 하나요?"에 답하는 경우는 영향도가 낮다. 반면 "민감한 인사 정보는 누구에게 공유해도 되나요?"는 근거가 조금만 흔들려도 위험 점수가 급격히 올라간다. 똑같이 문장 한 개를 출력해도, 운영상 무게는 전혀 다르다.

여기에 한 가지를 더 넣으면 훨씬 좋아진다. 바로 검토 불일치 신호다. 형식 검사는 통과했는데 근거성 판정이 review이고, 사실성 판정기는 pass라고 말한다면, 이 응답은 큐에서 위로 올려야 한다. 검토 시스템 내부의 불일치는 그 자체로 좋은 위험 신호다.

검토 우선순위는 FIFO가 아니라 리스크 순이어야 한다

실무에서는 종종 검토 큐가 고객센터 티켓처럼 쌓인다. 먼저 들어온 것을 먼저 본다. 하지만 AI 검토 큐는 그렇게 운영하면 안 된다. 이 큐의 목적은 공정한 순번 처리보다 위험한 응답의 선제 차단에 있다.

그래서 큐는 보통 세 갈래로 나누는 편이 좋다.

낮은 위험 큐는 자동 통과가 기본이다. 다만 전부 놓아 버리지는 말고 일정 비율을 샘플링해 사람 감사를 돌린다. 이것이 HOTL의 핵심이다. 시스템이 조용히 나빠져도 샘플 감사가 드리프트를 잡아낸다.²⁴

중간 위험 큐는 조건부 검토 구간이다. AI가 만든 이슈 요약, 근거 문단, 의심 주장 목록을 붙여 사람에게 보낸다. 사람은 처음부터 전체 대화를 다 읽는 대신, 문제가 있을 법한 지점부터 본다.

높은 위험 큐는 반드시 사람 승인 후에만 통과한다. 외부 공지, 법무 답변, 고액 결제 관련 안내, 실제 도구 실행 제안, 개인정보 관련 응답은 여기에 들어갈 수 있다. 이 구간은 속도보다 책임이 중요하다.

핵심은 모든 응답을 같은 줄에 세우지 않는 것이다. 검토 우선순위가 설계되어 있지 않으면, 결국 가장 시급한 케이스가 가장 오래 기다리게 된다.

위험도 기반 승인 흐름은 단순해야 오래 간다

좋은 승인 흐름은 예외가 적고, 설명이 쉽고, 나중에 감사하기 쉬워야 한다. 너무 복잡하면 운영자가 우회하고, 너무 느슨하면 사고가 난다. 실무에서는 보통 세 단계 승인이 가장 견고하다.

첫째, 자동 승인이다. 결정적 검사와 AI 검토를 모두 통과하고, 위험 점수가 낮고, 금지 주제가 아니면 바로 통과시킨다. 대신 일부는 무작위로 감사를 붙인다.

둘째, 조건부 보류다. 답변을 사용자에게 바로 내보내지 않고, 재생성 또는 표현 완화, 추가 검색, 근거 보강 같은 후속 조치를 먼저 시도한다. 예를 들어 과잉확신만 문제라면 사람 검토 전에 한 번 자동 수정 루프를 돌릴 수 있다.

셋째, 사람 승인 필수다. 위험 점수가 높거나, 규정상 인간 책임자가 있어야 하거나, AI 검토끼리 충돌하거나, 도구 실행이 실제 상태를 바꾸는 경우에는 사람이 승인해야 한다. 필요하다면 2인 승인도 고려할 수 있다. 특히 요청자 본인이 자기 결과를 승인하지 못하게 분리하는 구조는 사고를 줄인다.⁵

이 승인 흐름에서 중요한 것은 "점수가 몇 점이면 통과" 같은 멋진 숫자보다, 어떤 조건이면 누구에게 올라가는가가 분명해야 한다는 점이다. 운영은 점수표보다 라우팅 규칙으로 돌아간다.

사람 검토는 '읽기'가 아니라 '판단'이 되게 만들어야 한다

사람 검토가 느린 이유는 사람이 게을러서가 아니다. 보통은 검토에 필요한 재료가 흩어져 있기 때문이다. 질문은 한 화면, 답변은 다른 화면, 검색 문서는 로그 깊숙한 곳, 도구 호출은 별도 트레이스에 있고, AI 검토 경고는 또 따로 있다. 이렇게 되면 검토자는 답을 읽는 시간이 아니라 상황을 복원하는 시간에 대부분을 쓴다.¹

그래서 사람 검토 화면에는 최소한 다음 정보가 한 번에 보여야 한다.

사용자 질문과 모델 최종 답변
검색에 사용된 핵심 문서나 근거 문단
도구 호출 내역과 실행 결과
AI 검토가 표시한 위험 신호와 이유
검토자가 내려야 할 결정 옵션과 루브릭

여기서 루브릭은 아주 중요하다. "좋아 보이면 승인"은 기준이 아니다. 검토자는 무엇을 보고 승인해야 하는지 명시된 축이 있어야 한다. 예를 들어 정책 도우미라면 정확성, 근거 적합성, 금지 범위 준수, 표현의 안전성처럼 4개 정도의 축으로 좁히는 편이 좋다. 너무 많은 항목을 주면 사람도 흔들린다.

사람도 완벽한 판정자가 아니므로 보정이 필요하다

많은 팀이 사람 평가를 자동으로 정답 취급한다. 하지만 사람 검토도 편향과 피로, 해석 차이를 가진다. 실제로 사람 판정과 LLM 판정 모두 여러 종류의 판단 편향에 취약하다는 연구가 있다.³

그래서 사람 검토를 도입할 때는 단순히 검토자를 늘리는 것보다 검토 프로세스를 보정하는 일이 더 중요하다. 최소한 세 가지 장치가 필요하다.

같은 루브릭으로 예시를 함께 보며 초기 캘리브레이션을 한다.
일부 샘플은 이중 검토해 판정 일치도를 확인한다.
불일치 케이스는 상위 검토자나 도메인 전문가가 중재한다.

이 과정은 귀찮아 보여도 장기적으로 엄청난 차이를 만든다. 그렇지 않으면 사람 검토 결과가 데이터로 쌓여도 품질이 들쭉날쭉해서 AI 검토를 개선하는 재료로 쓰기 어렵다.

AI 검토는 사람 검토를 더 빠르게 만들어야 한다

AI 검토를 붙였는데도 사람이 여전히 모든 로그를 처음부터 끝까지 다 읽고 있다면, 그 AI 검토는 절반만 성공한 것이다. 좋은 AI 검토는 사람을 대체하지 않더라도, 최소한 사람의 시간을 고부가 판단에 쓰게 만들어야 한다.

이를 위해 AI 검토가 사람에게 넘겨야 하는 것은 단순 점수 하나가 아니다. 예를 들면 이런 정보가 훨씬 유용하다.

어떤 주장 두 개가 근거 부족인지
어떤 문단 citation이 실제 근거와 어긋나는지
어떤 도구 호출이 불필요했는지
어떤 표현이 과잉확신으로 보이는지
비슷한 과거 실패 사례가 무엇인지

사람 검토자는 이 정보를 받아 "처음부터 전체를 이해하는 사람"이 아니라 "쟁점만 확인하는 사람"이 될 수 있어야 한다. 이 전환이 일어나면 검토 처리량이 크게 오른다.

사람 검토는 AI 검토를 더 똑똑하게 만들어야 한다

반대로 사람 검토가 끝난 뒤 아무것도 남지 않는다면, 그 시스템은 계속 같은 실수를 반복한다. 사람 검토의 진짜 가치는 최종 승인 자체보다 학습 가능한 흔적을 남긴다는 데 있다.¹

예를 들어 검토자가 "정답이긴 하지만 근거 문단이 잘못 연결되었다"고 수정했다면, 이것은 단순 거절이 아니라 새로운 failure type이다. "정책상 맞지만 톤이 너무 단정적이다"도 마찬가지다. 이런 수정 사유는 다음과 같이 흘러가야 한다.

실패 유형 분류 갱신
회귀 테스트 케이스 추가
LLM judge 루브릭 보정
위험도 점수 가중치 조정
재생성 프롬프트 개선

결국 사람 검토는 소방 작업이 아니라 자동화의 교사 역할을 해야 한다. 사람이 계속 같은 오류를 손으로 막고만 있다면, 시스템은 똑똑해지지 않는다.

고위험 승인 흐름에서는 '멈출 권리'를 명확히 둬야 한다

위험도 기반 승인 흐름에서 자주 빠지는 함정은, 검토자가 있어도 실제로는 멈출 수 없는 구조를 만드는 것이다. 예를 들어 SLA 압박 때문에 검토자는 사실상 무조건 승인만 하게 되고, 시스템은 사람을 거쳤다는 기록만 남긴다. 이런 검토는 감독이 아니라 장식이다.

운영 가능한 구조는 검토자에게 최소한 네 가지 권한을 줘야 한다.

즉시 승인
수정 요청 또는 자동 재생성 요청
상위 검토자 에스컬레이션
배포 중지 또는 정책 팀 이관

특히 법무, 보안, 인사처럼 실패 비용이 큰 영역에서는 마지막 권한이 중요하다. 사람 검토자가 불안하다고 느꼈을 때 시스템을 잠시 멈출 수 있어야 한다. AWS의 운영 가이드가 강조하듯, 신뢰 임계값과 fallback 규칙은 애초에 설계에 포함되어야 한다.⁴

샘플 감사는 낮은 위험 구간을 지키는 안전망이다

낮은 위험 응답을 자동 승인했다면 끝일까. 그렇지 않다. 낮은 위험 구간은 시스템이 가장 자주 지나가는 길이기 때문에, 드리프트가 생기면 오히려 여기서 먼저 번진다. 그래서 자동 통과 구간에도 샘플 감사가 꼭 필요하다.²

샘플 감사는 단순한 품질 확인이 아니다. 세 가지 역할을 함께 한다. 첫째, AI 검토가 놓치는 실패 유형을 발견한다. 둘째, 위험도 모델이 너무 낙관적인지 확인한다. 셋째, 새 모델이나 새 프롬프트가 조용히 행동을 바꾸는지를 감시한다.⁴

운영 감각으로 보면 샘플 감사는 자동차 계기판의 경고등과 비슷하다. 평소에는 아무 일 없어 보이지만, 이 장치가 없으면 문제가 생겨도 너무 늦게 알아차린다.

실무 예시: 내부 정책 도우미의 검토 흐름

이 책의 최종 목표 중 하나는 내부 지식 도우미를 운영 가능한 형태로 만드는 것이다. 그 관점에서 검토 조합을 예로 들어 보자.

직원이 "출장비 정산 마감일이 언제인가요?"라고 물었다고 하자. 검색 문서가 분명하고, 정책 영향이 낮고, AI 검토가 근거 문단을 명확히 연결했으며, 과잉확신 신호도 없다. 이런 응답은 자동 승인 대상이다. 다만 일부는 주기적으로 샘플 감사에 들어간다.

다음으로 "징계 관련 자료는 팀장에게 바로 공유해도 되나요?"라는 질문이 들어왔다고 하자. 이 경우는 민감한 인사 정보, 권한 경계, 문서 해석이 한꺼번에 걸린다. 검색 문단이 있더라도 문맥상 예외 조항을 놓치면 위험하다. AI 검토는 높은 위험 점수를 주고 사람 승인 큐로 올린다. 검토자는 답변뿐 아니라 인용된 정책 문단, 누락된 예외 조항, 필요한 완곡 표현을 확인한 뒤 승인하거나 수정한다.

마지막으로 "이 정책상 계정을 바로 비활성화해도 되니 실행해 줘"처럼 답변을 넘어 실제 도구 실행으로 이어지는 요청은 더 엄격해야 한다. 이런 경우는 단순 답변 검토가 아니라 행동 승인이 된다. AI 검토가 아무리 높게 점수를 줘도, 권한이 있는 사람이 명시적으로 승인하지 않으면 실행되지 않아야 한다.

이 예시가 보여 주는 것은 단순하다. 질문의 길이나 답변의 유창함이 아니라, 영향과 책임의 무게가 검토 구조를 결정해야 한다는 점이다.