코드를 작성하고 몇 분 후에 그것을 검토해 본 적이 있는 사람이라면 누구나 그 느낌을 알 것이다. 'diff'가 괜찮아 보인다. 물론 그렇다. 읽는 사람은 방금 모든 줄에 대해 스스로 납득시킨 바로 그 사람이기 때문이다. 명명 규칙은 의도가 아직 기억 속에 따뜻하게 남아있기 때문에 말이 되는 것처럼 느껴진다. 단축키 사용도 이유가 작업 기억(working memory) 안에 검토되지 않은 채로 놓여 있기 때문에 정당화된 것처럼 느껴진다.

이것이 콜드 컨텍스트 크리틱이 제거하기 위해 만들어진 문제이다.

핵심 아이디어

내가 게임을 개발하기 위해 만든 하니스(harness)에서는 모든 변경 사항이 코드를 작성한 것을 기억하지 못하는 새로운 모델 인스턴스에 의해 수행되는 검토 단계를 거친다. 이 모델은 변경 사항을 계획하지 않았다. 접근 방식을 주장하지도 않았다. 무언가를 마침내 통과하게 했다는 작은 안도감을 느끼지도 않았다. 그것은 diff를 받고, 마치 낯선 사람이 하듯이 그 가치에 따라 평가한다.

직관 자체는 오래되고 지루해서, 역설적으로 내가 그것을 신뢰하는 이유 중 일부가 된다: 저자는 합리화하지만, 콜드 리뷰어는 그렇지 않다. 작업을 방금 생성한 모델이나 사람은 이미 자신이 내린 선택들에 대한 편향(bias)을 가지고 있다. 그 선택들을 했다는 기억을 제거하면, 같은 실수들도 더 이상 자명하게 옳지 않게 된다. 리뷰어는 방어할 것이 아무것도 없다. 실제로 존재하는 것만을 볼 수 있을 뿐이다.

이 주장을 정확히 하고 싶다. 왜냐하면 과장하기 쉽기 때문이다. 이것은 규율(discipline), 즉 아키텍처 선택이다. 내가 특정한 극적인 프로덕션 버그를 잡았다고 말할 수는 없다. 아이디어를 팔기 위해 사건을 지어낼 생각은 없기 때문이다. 내가 할 수 있는 말은 메커니즘에 관한 것이다: 콜드 리뷰는 저자가 스스로 납득시키는 종류의 실수들—그럴듯해 보이는 단축키, 소리 내어 말하지 않은 가정, '명백히' 일어날 수 없는 엣지 케이스(edge case)—을 포착한다. 자기 검토는 바로 그러한 것들에 구조적으로 취약하다. 왜냐하면 저자가 이미 그것들을 한 번 받아들였기 때문이다.

적용 분야

콜드 크리틱은 전체 이야기가 아니라 하나의 계층이다. 이것은 동일한 불신(distrust)의 몇 가지 조각들과 나란히 놓여 있다:

• 역할별 모델 라우팅 (Per-role model routing). 더 강력한 모델이 판단 단계(계획, 비평, 평가)를 수행하고, 비용 효율적인 모델들이 일상적인 실행을 처리합니다. 리뷰어는 자신의 숙제를 채점하는 것이 아니며, 속도를 위해 선택된 것과 같은 무게급도 아닙니다.
• 차분 오라클 (A differential oracle). 핵심 게임 로직은 두 번 구현되고 공유 불변성(shared invariants)에 의해 검증됩니다. 두 구현이 의견을 달리할 경우, 적어도 하나는 틀린 것이며, 어느 쪽도 신뢰할 필요 없이 제가 알아낼 수 있습니다.
• 모든 되돌릴 수 없는 행동에 대한 인간 승인 게이트 (A human approval gate on every irreversible action). 모델이 그렇게 해야 한다고 결정했다고 해서 배포(Deploys)나 커밋(commits)이 발생하는 것이 아닙니다. 사람이 승인했기 때문에 발생합니다. 그 문은 절대 움직이지 않습니다.

저는 이 전체 과정을 자율성 사다리(autonomy ladder), 즉 L0부터 L4까지 생각합니다. 완전히 직접적인 방식에서 더 많은 독립성으로 나아가는 것입니다. 콜드 크리틱이 바로 이 사다리를 오르는 것을 방어 가능하게 만듭니다. 검증받는 대상 자체가 자신을 보증하는 것에 의존하지 않는 한, 더 많은 자율성은 안전할 수 없습니다.

솔직히 설정에 대해 말하자면

구체적으로 설명하면: 크리틱은 깨끗한 컨텍스트 창(context window)을 가진 별도의 호출입니다. 변경 사항을 생성한 대화 내용을 상속받지 않습니다. 이 변경 내용과 지켜야 할 표준(standard)을 받아서, 사람이 그 변경 사항을 보기 전에 보고합니다. 이것이 구조입니다. 가치는 기발한 프롬프트가 아니라 누락된 기억입니다. 이 설정은 리뷰어가 코드를 좋아할 이유를 절대 축적하지 못하도록 보장하기 위해 존재합니다.

그것이 제가 인간 게이트를 움직이지 않게 유지하는 이유이기도 합니다. 콜드 크리틱은 좋은 독자일 뿐, 권위자는 아닙니다. 플래그(flag)는 할 수 있지만, 배포할 수는 없습니다.

솔직한 고지

저는 이 분야에 5~6개월 정도 참여했습니다. 이전 경력은 전문 주방에서 약 6년을 보냈고 CS 학위는 없습니다. freeCodeCamp와 직접 구축하면서 배웠습니다. 게임 자체는 실제이며 Google Play에 게시되었지만, 수백만 명에게 서비스되고 있지는 않으며 저는 프로덕션 RAG나 파인튜닝(fine-tuning) 파이프라인을 운영하고 있지 않습니다. 꾸미기보다는 이것이 무엇인지 말씀드리는 것이 낫다고 생각합니다.

솔직히 말하자면, 저는 아직 시니어 엔지니어가 어디에 문제가 있는지 알려주는 '흉터'가 없습니다. 제가 할 수 있는 것은 처음부터 불신을 습관화하는 것입니다. 작성자가 편향되었다고 가정하세요. 심지어 그 작성자가 저 자신이나 제가 구동하는 모델일 때도요. 그리고 답변에 이해관계가 없는 무언가를 만들어서 검증하게 만드세요.

실제로 실행해 볼 수 있는 코드로 같은 아이디어를 보고 싶다면, differential oracle이 공개되어 있습니다: github.com/egnaro9/evals-differential-oracle. 이것은 cold critic과 같은 움직임입니다. 즉, 자신의 출력물을 믿지 않는 것입니다. 이 아이디어는 두 개의 독립적인 로직 버전을 서로 비교하고, 수천 개의 무작위 보드에 대한 불변성 테스트(invariant tests)를 추가했으며, 심지어 검증이 제대로 작동하는지 증명하기 위해 의도적으로 버그가 있는 구현까지 포함했습니다. 이것을 복제(clone)해서 pytest를 실행해 보세요. 심어진 버그를 잡아내는 것을 지켜보세요.

더 많은 정보는 egnaro9.github.io와 github.com/egnaro9에서 확인할 수 있습니다.