AI 리뷰 체인의 '신뢰 세탁' ── 왜 다단계 리뷰일수록 '안심'이 위험한가

AI에게 코드를 작성하게 하고, 다른 AI에게 리뷰를 시키고, 거기에 추가적인 체크를 거친 뒤, 마지막에 인간이 승인한다——. 이런 다단계 리뷰 체인(Review Chain)을 구축했는데도, "품질이 올라간 실감이 없다", "오히려 이전보다 놓치는 부분이 늘어난 것 같다"라고 느낀 적은 없는가.

리뷰 단계를 늘렸는데도 사고가 발생한다. 이는 운영이 허술해서가 아니라, 다단계 리뷰 특유의 구조적인 함정에 빠져 있기 때문일지도 모른다.

본 기사에서는 그 함정을 "신뢰 세탁 (Trust Laundering)"이라고 명명하여 정의하고, 이를 피하기 위한 HITL (Human-in-the-Loop: 인간을 판단의 고리 안에 넣는 설계)을 내일부터 자신의 설계에 반영할 수 있는 수준으로 정리한다.

직접 코드를 작성하는 구현 기사가 아니라, 설계 사상과 그 구체적인 패턴에 관한 이야기다. 다만 "주의하자"로 끝내지 않고, 자기 진단 체크리스트와 설계 패턴까지 도출한다.

머니 론더링(Money Laundering)은 출처가 불분명한 돈을 여러 계좌나 거래를 경유하게 함으로써, 최종적으로 "깨끗한 자금"처럼 보이게 만드는 행위다.

신뢰 세탁은 이것의 리뷰 버전이다.

충분히 검증되지 않은 판단이 여러 AI 리뷰를 거치는 동안 "검증 완료"된 것처럼 보이는 현상.

각 단계에서 "체크 완료"라는 흔적(✓ 또는 LGTM)이 쌓인다. 마지막에 인간은 그것을 보고, "이만큼 통과했으니 괜찮겠지"라며 판단을 맡겨버린다. 하지만 각 리뷰가 실질적인 검증을 수행하지 않았다면, 쌓여 있는 것은 검증의 사실이 아니라 검증의 "겉모습"뿐이다.

세탁되는 것은 돈이 아니라, 책임이다. "누군가/무언가가 제대로 봤을 것이다"라는 분위기만 남고, 실제로는 아무도 최종적인 책임을 지지 않는 상태가 완성된다.

각 단계에서 "✓"가 쌓일수록 안심하게 되지만, 실질적인 검증은 아무도 수행하지 않는다.

신뢰 세탁은 관계자 중 누군가가 태만해서 발생하는 것이 아니다. 오히려 모두가 "자신의 역할을 다했다"라고 생각하고 있음에도 발생한다. 원인은 다음 4가지에 있다.

인간의 리뷰는 시간과 비용이 들기 때문에 쉽게 양산할 수 없다. 반면, AI의 "LGTM"은 실질적으로 비용 없이 무한히 내보낼 수 있다. 승인의 비용이 낮아지면 승인 1개당 가치가 떨어진다——통화를 너무 많이 발행했을 때와 같다. ✓가 대량으로 나열되어 있어도, 그것은 "많이 검증되었다"는 것을 의미하지 않는다.

징후: 리뷰 AI가 거의 100% "승인"을 반환하고 있다. 거절이나 보류가 거의 나오지 않는다.

인간은 자동화된 시스템이 내린 판단을 과도하게 신뢰하는 경향이 있다 (Automation Bias). 화면에 ✓가 나열되어 있으면 뇌는 "이미 확인된 것"으로 취급하여 스스로 정밀하게 조사하는 모드로 들어가기 어려워진다. 본래 체크해야 할 인간이 ✓의 존재 자체로 인해 사고를 생략해 버린다.

징후: 인간의 최종 승인에 걸리는 시간이 극단적으로 짧다. 차이점(Diff)을 열어보지 않고 승인한다.

"다단계로 체크하고 있으니 안전하다"라는 발상은 각 단계의 체크가 독립적임을 암묵적으로 전제하고 있다. 하지만 비슷한 학습 데이터, 비슷한 프롬프트, 비슷한 가치관을 가진 AI를 나열해 보아도, 그것들은 똑같은 실수를 똑같이 놓친다. 독립된 3개의 눈이 아니라, 똑같은 눈을 3개 나열하고 있을 뿐이다——독립 체크의 환상이다.

징후: 리뷰 AI들끼리 거의 동일한 지적만 한다. 혹은 동일한 전제 오류를 모든 단계가 공유하고 있다.

인간은 "AI가 여러 단계를 거쳤으니까"라고 생각한다. 반면 시스템 설계는 암묵적으로 "마지막에 인간이 보니까"라며 인간에게 의존한다. 양측 모두 "최종적인 보루는 상대방에게 있다"라고 믿음으로써, 실제로는 아무도 최종 책임을 맡지 않는 진공 지대가 생긴다. 이는 집단에서의 책임 분산 (Diffusion of Responsibility) 그 자체다.

징후: 사고 후에 "AI가 통과시켰으므로", "최종 체크는 자동화되어 있었으므로"라는 설명이 나온다.

다음 중 몇 가지나 해당되는가?

• 리뷰 AI가 "거절" 또는 "수정 필요"를 내놓는 것을 최근에 본 적이 없다
• 인간의 최종 승인은 대개 몇 초에서 십수 초 내에 끝난다
• 각 리뷰 AI에 전달하는 지시 사항이 실질적으로 거의 동일한 내용이다
• 리뷰 결과는 "OK / NG"의 이진(Binary) 값이며, 근거가 남아 있지 않다
• 문제가 발생했을 때 "누구의 판단 실수인지" 한 사람을 특정할 수 없다
• "AI가 통과시켰으니까 괜찮을 줄 알았다"라고 말한(생각한) 적이 있다

3개 이상 해당된다면, 리뷰 체인은 "검증"이 아니라 "검증의 겉모습"을 생산하고 있을 가능성이 높다. 다음 장에서 바로잡자.

여기서부터가 본론이다. HITL(Human-in-the-Loop)은 '마지막에 인간을 두는 것'이 아니다. 그저 배치만 해두는 인간은, 체크 표시(✓)를 바라보며 도장을 찍는 의식의 담당자(rubber stamp)가 되어, 신뢰 세탁(trust laundering)의 최종 공정에 편입되어 버린다.

인간을 “involved(실제로 관여하고 있는)” 상태로 유지하기 위한 원칙을, **원칙 → 흔한 안티패턴(Anti-pattern) → 설계 패턴(Design pattern)**의 3종 세트로 제시한다.

안티패턴: 일단 워크플로우의 마지막에 '인간의 승인'을 둔다. 무엇을 판단해주길 원하는지는 정하지 않았다. -
설계 패턴: '어디서, 무엇을, 어느 정도로 인간이 판단할지'를 먼저 결정한다. 전부를 보여주는 것이 아니라, 리스크가 높은 변경(인증, 과금, 데이터 삭제, 외부 공개 등)에만 인간의 판단을 집중시키고, 그 외에는 AI에게 맡긴다. 판단해주길 원하는 단 한 가지 포인트를 명시하여 전달한다.

안티패턴: 리뷰 AI에게 'OK인지 NG인지'를 답하게 한다. 출력이 'LGTM'뿐이다. -
설계 패턴: AI에게 판단을 내리게 하지 말고, 판단의 재료를 내놓게 한다. '이 부분이 우려 사항임', '그 근거는 이것임', '확인해야 할 차이점(diff)은 여기임'. 최종적인 가부 판단은 인간(책임자)이 내린다. AI는 리뷰어가 아니라, 우수한 조사 어시스턴트(assistant)로 사용한다.

안티패턴: 동일한 모델에 동일한 지시를 내린 리뷰를 3단으로 나열하고, 이를 '삼중 체크'라고 부른다. -
설계 패턴: 각 리뷰에 서로 다른 역할과 서로 다른 관점을 할당한다. 예를 들어 하나는 보안 관점, 하나는 가독성·유지보수성 관점, 하나는 요구사항과의 정합성 관점이다. 관점을 분리함으로써 상관관계가 있는 간과(miss)를 줄여야 비로소 '다단계'로서의 의미가 생긴다.

안티패턴: 리뷰 결과를 초록색 체크 표시로만 표시한다. -
설계 패턴: '신뢰도가 낮은 부분', '판단이 갈린 부분', '의도적인 반대 의견'을 전면에 내세운다. 인간이 '생략'하기 어렵도록, 안심시키는 정보가 아니라 걸림돌이 되는 정보를 보여준다. 초록색 일색인 대시보드는 자동화 편향(automation bias)을 유발하는 장치가 될 수 있다.

안티패턴: '체인 전체에서 승인됨' 상태로 만들어, 최종 책임자를 모호하게 한다. -
설계 패턴: 최종적으로 '이 머지(merge)는 이 사람이 판단했다'라고 한 명에게 귀속시킨다. AI의 리뷰는 판단의 보조일 뿐, 책임을 대신하는 것이 아님을 제도적으로 명문화한다. 'AI가 통과시켰으니까'라는 변명을 할 수 없는 구조로 만든다.

AI는 '승인'이 아니라 '지적'을 내놓고, 판단과 책임은 인간에게 집약한다.

원칙을 일상적인 운용에 적용할 때 효과적인, 도구나 조직에 의존하지 않는 일반적인 패턴을 나열한다.

판정에 구조화된 포맷을 강제한다: 리뷰의 결론을 자유 기술이 아니라, '승인/반려', '그 이유', '확인한 관점', '보류한 관점'과 같이 정해진 항목으로 남기게 한다. 근거가 필수적이 됨으로써 공허한 승인이 나오기 어려워진다. -
게이트(Gate)를 '전부 초록색 = 자동 통과'로 만들지 않는다: CI나 자동 체크가 전부 초록색이라 하더라도, 그것은 자동 머지 허가가 아니라 '인간이 판단하기 위한 전제 조건이 갖춰진' 상태로 정의한다. 중단할 권한과 책임을 제도로서 인간 측에 남겨둔다. -
통합점을 일원화한다: 변경 사항이 최종적으로 합류하는 지점을 하나로 좁히고, 그 직전에 반드시 사람의 판단을 딱 한 번만 거치게 한다. 판단 지점을 분산시키면 어디서든 누군가 보고 있는 것 같지만, 결국 어디에서도 아무도 보고 있지 않은 상태가 되기 쉽다. -
거절 실적을 모니터링한다: 리뷰 AI의 반려율과 인간의 반려율을 기록한다. 장기간 제로(0)가 지속된다면, 그것은 체크가 제대로 기능하고 있다는 증거가 아니라, 기능하지 않고 있다는 신호로 취급한다.

이것들은 '인간의 수고를 늘리기 위함'이 아니라, 늘려야 할 한 지점과 안심하고 맡겨도 되는 대부분을 구분하기 위한 메커니즘이다.

여기까지 읽으면 '결국 모든 단계에 인간을 끼워 넣으면 되는 것 아닌가'라고 생각할 수도 있지만, 그것은 또 다른 실패다. 모든 공정에 인간을 끼워 넣으면 AI로 개발 속도를 높인 의미가 사라지고, 리뷰 피로(review fatigue)로 인해 판단의 질도 떨어진다. 아이러니하게도 인간을 너무 많이 끼워 넣어도——형식적인 체크가 늘어나면서——신뢰 세탁은 발생한다.

요점은 배치의 문제다. 리스크가 높은 곳에는 인간의 판단을 두텁게 하고, 낮은 곳은 AI에게 대담하게 맡긴다. 판단 지점은 비용이므로, 무한히 둘 수 없다는 전제하에 '어디에 두어야 가장 효과적인가'를 설계한다. 모든 것을 보는 인간은, 아무것도 보지 않는 인간과 다를 바 없다.

다단계 리뷰는 그 자체로 품질이나 안심을 보장하는 것이 아니다. 설계를 잘못하면 검증의 '겉모습'만 양산하고 책임을 희박하게 만드는 장치——신뢰 세탁의 메커니즘——가 될 수도 있다.

핵심은 인간을 '마지막에 두는 것'이 아니라 '실제로 판단하게 하는 것'이다. 그러기 위해서,

• 판단 지점 (Judgment point)을 의도적으로 설계하고,
• AI에게는 가부(可否)가 아닌 근거를 제시하게 하며,
• 리뷰의 관점을 분화시키고,
• 안심이 아닌 위질감 (引っかかり)을 가시화하며,
• 책임을 한 사람에게 고정한다.

발상을 한마디로 바꾼다면, 다음과 같다.

「AI에게 리뷰를 시키는 것」에서, 「인간이 판단하기 위해 AI를 사용하는 것」으로.