AI가 파괴한 것은 품질이 아니라 대리 지표다. Meat Proxy 방지책과 '정성껏 하는' 논의에서 생각하는 품질의 위치

서론

AI 이전에는 우리가 결과물의 품질을 직접 확인하기보다 몇 가지 대리 지표(proxy metrics)로 추측했다. 공을 들였다면, 아마 이해할 것이다. 모양이 갖춰져 있다면, 아마 제대로 된 것이다. 동료의 이름으로 도착한 것이라면, 아마 누군가 확인했을 것이다. 이 모든 것이 완벽하지는 않았지만, 어느 정도는 맞았다.

생성 AI(Generative AI)는 이 세 가지를 동시에 파괴했다. 공을 들이지 않고도, 모양이 갖춰진 것을, 아무도 확인하지 않은 채 동료의 이름으로 전달할 수 있게 되었다. 2026년 8월에 Niklas Gruhn의 에세이 'Don't be a meat proxy'에서 'Meat Proxy'라는 용어가 퍼진 것은, 이러한 붕괴가 현장에서 눈에 보이게 되었기 때문이라고 생각한다. 이는 AI 출력을 읽거나 검증하지 않고 전달하는 사람을 지칭하는 말이며, 진단으로는 정확하다.

다만, 이에 대한 대책으로 나오는 것들 대부분은, 망가진 대리 지표를 원래대로 되돌리려 애쓰느라 헛도는 경우가 많다. 대안으로 자주 언급되는 'AI를 사용해 느리고 정성껏 하자' 역시 논리는 좋지만 조건부로만 성립 가능하다. 이 글에서는 두 가지 입장을 소재로 삼아, 대리 지표가 파괴된 후 품질을 어디에 위치시켜야 할지 생각해 본다.

망가진 대리 지표를 요구하면 새로운 slop이 탄생한다

Meat Proxy 방지책으로 현장에 내려오는 것들은 '자신의 말로 다시 써라', 'AI 같은 문체를 고쳐라', '우리 스타일(스타일)에 맞추라'와 같은 종류다. 이것들은 모두, 망가진 대리 지표를 다시 요구하고 있다. 공을 들인 흔적을 보여주면 이해의 증거가 되고, 인간다운 모양새라면 사람이 확인했다는 증거가 된다는 전제에 서 있다.

하지만 그 상관관계는 이미 끊어졌다. 흔적을 요구해도 이해는 돌아오지 않고, 흔적만 생산된다. 다시 말하는 의식(儀式)은 정확했던 출력물에 손실성 변환(lossy transformation)과 인간의 실수를 섞는 것일 뿐이다. 이것이 human slop의 정체라고 생각한다.

같은 구조로, 대책이 근거 없는 취향 강요로 변질되는 경우도 많다. 'AI 대책'이라는 명목이 있으면, 취향을 규범으로 통과시키기 쉬워지기 때문이다. 이 둘 모두, 대리 지표가 파괴된 후에 대리 지표를 지키려 한 결과로 발생하고 있다.

slop의 형태는 최적화 대상에 의해 결정된다

AI slop을 익숙한 눈으로 AI 이전의 결과물을 되돌아보면, 그것 역시 어딘가 slop이었다는 사실에 놀란다. 코드뿐만 아니라 문서나 자료에서도 마찬가지다. 다만 방향이 다르다. AI의 slop은 표면이 갖춰져 있고 평균에 수렴하는 '그럴듯한 부풀리기(水増し)' 형태이고, 인간의 slop은 표기 변화나 방치, 업데이트되지 않는 문서 같은 '불일치와 방치' 형태이다.

예전에는 그것이 신경 쓰이지 않았는데, 인간의 slop은 외형적인 지저분함이 품질의 낮음을 솔직하게 보여주었기 때문이다. 지저분해 보이는 것은 감가하여 읽으면 되었다. '갖춰져 있음 = 제대로 된 것'이라는 대리 지표가 파괴된 후에야 내용물을 보는 습관이 생겼다.

차이의 근원은 제작자가 인간인지 AI인지가 아니다. 인간 slop의 대부분은 '공을 들였다는 느낌'에 최적화된 결과이며, 부풀린 보고서나 의식적인 양식이 이에 해당한다. 사람으로 만든 것 중 AI slop과 가장 비슷한 것은 검색 순위에 최적화된 대량 생산 기사(소위 '어떠셨나요 블로그')라는 것도 같은 이유다. slop의 형태는 어떤 지표에 최적화되었는지에 따라 결정된다. 앞서 언급한 human slop 역시, 망가진 지표에 최적화시킨 결과로서 이 법칙을 따르고 있다.

고쳐야 할 것은 결과물이 아니라 검증 정보다

AI 출력을 그대로 전달하는 것의 해악은 출력물의 질이 아니라 정보의 비대칭성에 있다. 보내는 사람은 무엇을 확인했는지 알고 있지만, 받는 사람에게는 전해지지 않는다. 게다가 인간의 이름이 붙음으로써 '누군가 확인했다'는 가짜 신호까지 붙는다. 생성 비용은 붕괴했지만, 검증 비용은 붕괴하지 않았다. 그래서 받는 사람은 보내는 사람보다 적은 맥락으로 전부를 다시 확인해야 한다. AgentPatterns 정리에서 말했듯이, 해악의 본체는 검증 작업의 하류로 전가되는 것이다.

그렇다면 대책은 결과물에 손을 댈 필요가 없다. 확인한 범위와 확인하지 않은 범위를 명시하는 것만으로도 본론은 해결된다. '테스트에서 확인 완료, 이 조건은 미검증, 여기는 추측'이라고 첨부하면, 결과물은 AI의 출력 그대로이고, 망가졌던 신호만 고쳐지면 된다. 대리 지표로부터 추정하게 하는 것을 멈추고, 추정하고 싶었던 내용물을 직접 전달하는 것이다.

그 위에서 인간에게 남는 것은 맥락과의 대조(照合)이다. AI는 질문받은 것에만 답한다. 실제 상황, 암묵적인 제약, 질문받지 않은 전제에 맞는지 확인할 수 있는 것은 맥락을 가진 사람뿐이다. 이것은 인간 수준으로의 퇴화가 아니라, 위임할 수 없는 몇 안 되는 일이라고 생각한다.

규범과 취향은 작성 가능한지에 따라 나뉜다

리뷰에서 강요되는 까다로움(拘り)에는 규범과 취향이 뒤섞여 있다. 이를 구분하는 기준은 간단하다. 린트(lint), 테스트, 에이전트에게 주는 지시 파일처럼 명시적인 규칙으로 작성할 수 있느냐 여부이다.

작성할 수 있다면 그것은 규범이므로 기계화하면 된다. 명문화된 규칙은 AI가 인간보다 일관되게 지키며, 리뷰를 통해 개인의 재량을 배제할 수 있다. 프롬프트로 교정할 수 없는 출력 습관도 출력 측면에서 기계적으로 제거할 수 있다 (전에 쓴 자기 방어적 코멘트 이야기가 그 예이다). 린트와 포매터(formatter)가 인간의 편차에 대해 해왔던 것을 AI에게 적용하는 것일 뿐이다.

작성할 수 없다면, 대부분은 취향이다. 다만 '왜'를 언어화하지 못했을 뿐인 암묵지(暗黙知)가 섞여 있을 때도 있다. 그러니 버리기 전에 '규칙으로 작성할 수 있는지'를 묻는 것이 가장 생산적이며, 작성할 수 있게 된 것은 자산이 된다. AI를 전제로 한 개발은 정당화할 수 없는 까다로움을 드러내는 필터 역할까지 한다.

검증 측면의 접근: AI로 이해(理解)를 구매하다

Meat Proxy 논의보다 더 합리적이라고 내가 생각하는 입장이 Nolan Lawson의 Using AI to write better code more slowly이다. 이 주장은 AI가 저품질을 빠르게 내놓는 것뿐만 아니라, 고품질을 느리게 만드는 데도 똑같이 사용될 수 있다는 것이다. 그는 여러 개의 다른 모델에게 문제를 찾게 하고 비교하여 오탐지(誤検出)를 제거하는 절차를 구성하고 있다. 개발 속도는 반드시 빨라지지 않지만, 기존의 문제점까지 파헤쳐지고 코드베이스가 어떻게 망가지는지 배울 수 있다는 장점이 있다.

이 입장이 합리적인 이유는 결과물의 표면이 아니라, 검증 측면에 개입하기 때문이다. 인간에게 흔적을 요구하는 것이 아니라, AI를 사용해서 확인된 범위를 넓히고 이해도를 깊게 한다. 얻는 것은 품질 그 자체보다 이해도에 있다. 지금까지의 말로 하자면, 망가진 대리 지표(proxy metric)를 요구하는 대신, 대리 지표가 추정하려 했던 내용을 AI로 직접 만들어 나가는 방향이다.

검증이 저렴해지면 병목은 '무엇을 하지 않을까'로 이동한다

다만, 이 방향에도 일반적인 어려움이 있다.

첫째는 멈출 곳이 사라진다는 것이다. AI에 의한 탐지가 쉬워지면 지적(指摘)의 공급은 실질적으로 무한대가 된다. Nolan 자신도 모든 것을 해결하려 하면 지루할 정도로 많이 발견된다고 쓰고 있다. 이렇게 되면 희소한 것은 탐지가 아니라 '무엇을 고치지 않을까'라는 판단이 되며, 이는 암묵지의 영역에 머문다. 전부 고치는 쪽으로 기울면 '지적 제로(指摘ゼロ)'라는 새로운 대리 지표에 최적화되고, 일어나기 힘든 상황에 대한 방어나 가정된 미래에 대한 주석이 쌓인다. 정성적인 슬롭(slop)이다.

둘째는 품질의 정의에 취향이 개입한다는 것이다. 무엇을 '문제'로 간주할지 적는 순간, 작성자의 가치관이 들어간다 (Nolan의 정의에도 지나치면 잘못된 공통화(共通化)를 낳는 DRY가 포함되어 있다). 리뷰에서 배제했던 취향이 품질 기준의 정의를 거쳐 이번에는 AI의 물량으로 되돌아온다.

셋째는 경제성이다. 속도가 빨라지지 않으면서 계산 자원만 소모하는 방법은 재량이 있는 개인이나 변화가 적은 유지보수 현장에서는 작동하지만, 처리량(throughput)으로 평가받는 조직에서는 정당화하기 어렵다. 지적을 처리하려면 영역 지식이 필요하므로, 경험이 부족한 사람일수록 지적의 홍수에 빠진다. 결국 이 방법은 '무엇을 하지 않을지 결정할 수 있는 사람'과 '느림을 허용하는 환경'을 전제로 하고 있으며, 둘 다 희소하다.

호소는 행동을 바꾸지 않는다. 환경이 바꾼다

두 가지 입장에는 공통된 구조가 있다. 둘 다 실질적으로 '인간을 위한 프롬프트'이며, 인간은 그 프롬프트를 실행하지 않는다.

한 단계 더 물러서서 생각하면, 정교함이 보상받는 경우는 결과물의 수명이나 어떤 방식으로 망가지는지가 읽힐 때로 한정된다. 이는 AI가 강점을 갖는 영역, 즉 사양이 정해져 옳고 그름을 판별할 수 있는 영역과 거의 겹친다. ‘정성껏 하면 좋다’는 조건부로만 성립하는 명제이며, 그 조건을 충족시키는 현장은 제한적이다.

미래를 예측할 수 없을 때 합리적인 것은 정교함이 아니라 가역성(reversibility)에 대한 투자다. 작게 내놓는다. 바로 되돌릴 수 있도록 한다. 비정상적으로 빨리 감지할 수 있는 메커니즘을 먼저 배치한다. 그 위에 정교함은 데이터의 이관, 권한, 외부와의 약속 같은, 되돌릴 수 없는 일방통행 부분에만 집중시킨다.

‘이것은 되돌릴 수 있는가’는 ‘이 문제가 통할까’보다 훨씬 예측하기 쉽고, 게다가 규칙으로 쓸 수 있다. 쓸 수 있는 규칙이라면 AI에게 넘길 수 있다. 되돌릴 수 없는 변경에는 무거운 검증을, 되돌릴 수 있는 변경에는 가벼운 검증과 빠른 롤백(rollback)을 배분하는 것을 명문화하면, 정교함의 배분 자체를 환경 측에 둘 수 있게 된다.

결론

요약하자면, 다음과 같다.

• AI가 부순 것은 품질이 아니라, 품질을 측정하기 위한 대리 지표(노력, 외관, 인간의 이름)다
• 망가진 대리 지표를 요구하면, 그 지표에 최적화된 새로운 슬롭(slop)이 탄생한다
• 고쳐야 할 것은 결과물이 아니라 검증 정보이며, 확인한 범위를 명시하는 것으로 충분하다
• 검증이 싸지면 희소해지는 것은 ‘무엇을 하지 않을까’라는 판단이다
• 규범은 호소만으로는 움직이지 않는다. 글로 적어 환경에 두어야 한다.

따라서 나의 결론은 소박하다. 사람에게 호소하는 것을 멈추고, 절차로 만들어 환경에 배치한다. 정교함은 일방통행 부분에만 배분하고, 그 배분 규칙마저 써서 AI에게 넘긴다. 남겨진 인간의 일은, AI가 듣지 못한 맥락에 맞는지 확인하는 것과, 무엇을 고치지 않을지 판단하는 것으로, 이 두 가지는 아직 위임할 수 없다.

슬롭의 형태는 인간이냐 AI냐가 아니라, 어떤 지표에 최적화되었느냐에 따라 결정된다. 그렇다면 최적화시키는 지표를, 노력의 흔적이든 지표 제로든 아니게 ‘확인된 범위가 명시되어 있는 것’과 ‘되돌릴 수 있는 것’으로 대체하고 싶다.

참고 링크

• Simon Willison: Don't be a meat proxy
• AgentPatterns: The Meat Proxy: Relaying Agent Output Without Reading It
• Nolan Lawson: Using AI to write better code more slowly

토론