내가 Claude에게 자신의 작업물을 직접 채점하게 하지 않는 이유

원문은 aaroncasey.bearblog.dev에서 처음 게시되었습니다.

당신의 앱을 만든 모델은 당신의 앱을 방어할 것입니다. 이것은 결함이 아닙니다. 그저 컨텍스트 (Context)가 제 역할을 수행하는 것뿐입니다. 해결책은 편향 (Bias)을 제거하는 것이 아니라, 그것을 감사 가능 (Auditable)하게 만드는 것입니다.

Claude는 제가 앱을 구축하는 것을 돕는 데 매우 뛰어났지만, 자신의 결정을 강화하려는 경향이 있었습니다. 그 점 때문에 Claude는 강력한 구축자(Builder)였지만 취약한 심판(Judge)이었습니다. 그래서 저는 테스트 과정을 구축 대화 (Build conversation)에 접근할 수 없는 로컬 AI 페르소나 (Local AI personas)로 옮겼습니다.

함정 (The Trap)
앱을 만든 모델이 앱을 평가하게 한다면, 그것은 스스로 숙제를 채점하는 것과 같습니다. 채점자는 이미 당신에게 동의하고 있습니다. 그는 당신의 결정을 도왔습니다. 그는 그 결정을 방어할 것입니다.

저는 이를 직접 경험하며 배웠습니다. 초기에는 Claude가 직접 페르소나를 실행하도록 했습니다. 실행 자체는 실제였습니다. Claude가 실제로 페르소나를 실행하고 결과물을 생성했습니다. 그 부분은 잘 작동했습니다. 문제는 나중에 설계 전환점 (Design pivot points)에서 나타났습니다. 제가 기능의 방향을 바꾸고 싶을 때, Claude는 페르소나의 목소리를 빌려 — "베테랑이라면 이에 반대할 것입니다", "초보자라면 그것을 이해하지 못할 것입니다" — 라고 말하며, 제안된 변경 사항에 대해 페르소나를 실제로 실행해 보지도 않은 채 전환에 반대하며 논쟁했습니다. 페르소나들이 수사적 탄약 (Rhetorical ammunition)이 되어버린 것입니다. 페르소나들은 새로운 것을 평가하기 위해 새롭게 참조되는 것이 아니라, 기존의 경로를 방어하기 위해 기억 속에서 인용되고 있었습니다.

그것이 함정입니다. 페르소나가 가짜였다는 것이 아니라, 구축 대화가 이미 기울어져 있는 방향에 대해 증인으로 징집되었다는 점입니다.

그래서 저는 페르소나들을 분리했습니다. 구축 대화에 접근할 수 없는, 제 컴퓨터의 로컬 모델 (Local models)로 말입니다. 페르소나들은 오직 자신이 누구인지, 그리고 무엇을 보고 있는지만을 압니다. 그들은 자신이 참여하지 않은 논쟁에서 기억을 토대로 인용될 수 없습니다.

내가 해결하려던 문제
특정한 유형의 1인 운영자(solo operator)를 위한 데스크톱 앱을 구축하고 있습니다. 대상 독자는 보기보다 훨씬 넓습니다. 그 안에는 매우 다른 단계에 있고, 매우 다른 습관을 지니며, 자신의 업무를 매우 다른 언어로 생각하는 사람들이 섞여 있습니다. 건실한 사업을 운영하는 베테랑은 기본적인 용어를 여전히 구글링하고 있는 1년 차 운영자와 워크플로(workflow) 측면에서 공통점이 전혀 없습니다.

실제 사용자가 앱을 만지기 전에, 이 범위 전체에서 앱이 어떻게 작동할지 알아낼 필요가 있었습니다.

Claude를 사용하여 구축한 이유
구축 단계는 간단합니다. 원하는 것을 설명하고, 작동하는 초안을 받고, 반복(iterate)합니다. 아키텍처(architectural)에 관한 대화는 유용합니다. 코드는 제가 읽고, 수정하고, 소유할 수 있을 정도로 충분히 깔끔합니다.

한 가지 구체적인 예로, 오프라인 우선(offline-first) 요구 사항이 있는 PyQt5 데스크톱 앱을 위해 SQLite를 직접 사용할지, 아니면 그 위에 ORM(Object-Relational Mapping) 계층을 쌓을지에 대해 Claude와 의견을 주고받았습니다. 이 대화를 통해 제가 고려하지 못했던 트레이드오프(trade-offs)들이 드러났습니다. 마이그레이션(migration)의 골칫거리, 디버깅(debugging) 중 쿼리(query) 가시성, 그리고 새벽 1시에 이상한 상태 버그(state bug)를 추적할 때 ORM이 실제로 무슨 일이 일어나고 있는지 모호하게 만들 수 있는 방식 등이 그것입니다. 우리는 얇은 래퍼(wrapper)를 씌운 순수 SQLite를 사용하기로 결정했습니다. 그 결정은 지금까지 유효합니다. 클라우드 규모의 추론(reasoning) 능력은 바로 이런 호출에서 제값을 합니다.

하지만 그 결정을 내리는 데 도움을 준 것과 동일한 모델이, 결과물인 UI가 낯선 사람에게 말이 되는지 여부를 나에게 말해주기를 원하지는 않습니다.

테스터를 로컬에서 실행하는 이유
저는 23개의 페르소나(persona)를 로컬 AI 캐릭터로 설정했습니다. Mistral Nemo 12B가 주력 모델(workhorse)입니다. 여기에는 몇 가지 이유가 있습니다.

구축 모델로부터의 독립성. 위에서 언급했듯이, 이것이 아키텍처가 존재하는 이유 전체입니다.

개인정보 보호(Privacy). 페르소나 정의와 테스트 기록에는 실제 사용자를 반영하는 샘플 데이터가 포함되어 있습니다. 이 모든 것을 제 자신의 기기에 보관한다는 것은 외부로 무엇이 나가는지에 대해 전혀 고민할 필요가 없음을 의미합니다.

대량 실행 시의 속도. 모델이 로드되면 원하는 만큼 반복해서 실행할 수 있습니다. 속도 제한(rate limits)도 없고, 왕복 시간(round-trips)도 없습니다. 밤사이에 잠을 자는 동안 배치(batch)당 약 50회 정도 실행할 수 있습니다.

비용 제어. 토큰당 과금 방식이 아닙니다. 하드웨어 비용은 이미 지불되었습니다. 추가 테스트 실행에 드는 한계 비용(marginal cost)은 전기료뿐입니다.

재현성 (Repeatability). 고정된 설정을 가진 로컬 모델 (Local models)은 재현 가능한 실행을 제공합니다. 특정 페르소나 (persona)가 문제를 지적하면, 저는 아무것도 건드리기 전에 동일한 빌드에 대해 동일한 페르소나를 다시 실행하여 실패를 확인할 수 있습니다.

다른 모델들도 시도해 보았습니다. 대부분은 몇 번의 대화 내에 캐릭터에서 벗어났습니다. 파트타임 근무자 페르소나가 전문가처럼 말하기 시작하거나, 초보자가 갑자기 알면 안 되는 용어를 알게 되는 식입니다. Nemo 12B는 잘 버텨주었습니다. 또한 제가 테스트한 해당 크기의 모델 중 가장 인간처럼 들리는 응답을 생성했습니다. 하드웨어는 RTX 2070 Super로, 빠르지는 않지만 밤새 실행하는 것이라면 빠를 필요도 없습니다.

워크플로우 작동 방식
각 페르소나는 상세한 캐릭터 파일입니다. 한 줄짜리 시스템 프롬프트 (system prompt)가 아니라, 그들이 누구인지, 어디서 일하는지, 어떻게 그 자리에 오게 되었는지, 어떻게 말하는지, 무엇을 중요하게 여기는지, 무엇을 무시하는지, 절대 입 밖으로 내지 않을 말은 무엇인지 등 전체 프로필을 담고 있습니다. 그중 하나는 기준점 (baseline)으로서의 저의 버전입니다. 나머지는 제가 아니며, 그것이 핵심입니다.

Python 스크립트가 실행을 조율 (orchestrate)합니다. Claude가 이 조율 코드를 작성했습니다. 그 후 저는 Claude에게 페르소나 자체에 대한 접근 권한을 거부했습니다. Claude는 테스트 프레임워크 (harness)가 존재한다는 것은 알지만, 페르소나 파일, 시스템 프롬프트, 또는 가공되지 않은 전사 데이터 (raw transcripts)는 볼 수 없습니다. 이러한 분리가 바로 아키텍처 (architecture)입니다.

제가 새로운 빌드를 푸시하면, 스크립트는 각 페르소나에게 현재 버전의 앱과 세션을 제공합니다. 페르소나들은 이전 테스트 버전들에 대한 기억을 가지고 있으므로 비교가 가능합니다. 무언가 개선되면 알려주고, 무언가 나빠지면 저를 가차 없이 비판할 것입니다.

아침이 되면 저는 방대한 양의 피드백 더미를 갖게 됩니다. 저는 이를 읽으며 실제적인 것들을 골라냅니다: 혼란, 누락된 기능, 잘못된 가정, 그리고 앱의 언어가 실제 일하는 사람이 자신의 업무에 대해 말하는 방식과 일치하지 않는 부분들 말입니다. 그런 다음 통합된 리뷰를 Claude에게 전달하여 종합 (synthesis) 및 우선순위 지정 (prioritization)을 맡깁니다.

그 마지막 단계가 중요합니다. Claude는 리뷰를 읽습니다. 하지만 Claude가 리뷰어가 되어서는 안 됩니다. 리뷰는 Claude가 생성한 것이 아니라, 외부에서 온 증거로서 Claude의 컨텍ст (context)에 입력됩니다.

이 방식이 무엇을 하고 무엇을 하지 못하는지에 대해 솔직해지고 싶습니다. 이러한 분리(separation)가 편향 (bias)을 제거하는 것은 아닙니다. 다만 그 편향을 감사 가능 (auditable)하게 만들 뿐입니다. Claude는 리뷰를 읽은 후에도 이전의 결정을 옹호하는 방향으로 흐를 수 있습니다. 하지만 이제는 페르소나(personas)가 무엇을 "말했는지"에 대한 모호한 기억 대신, 제가 대조해 볼 수 있는 명확한 기록 (paper trail)이 남습니다. 만약 Claude가 전환점 (pivot point)에서 특정 리뷰를 인용한다면, 저는 실제 리뷰를 불러와 검증할 수 있습니다. 이전에는 인용문과 출처가 모두 Claude였지만, 이제는 서로 분리된 산출물 (artifacts)입니다. 이것이 진정한 승리입니다. 편향이 사라졌기 때문이 아니라, 편향이 나타났을 때 제가 그것을 잡아낼 수 있기 때문입니다.

이 접근 방식이 유용한 경우
이 워크플로우 (workflow)는 UX 혼란, 전문 용어 (jargon)의 불일치, 인접한 사용자 유형을 위한 기능 누락, 그리고 본인이 인지하지 못했던 가정 (assumptions)들을 드러내 줍니다. 이 방식은 규모를 줄이기에 매우 좋습니다. 소비자용 GPU, Python 스크립트, 그리고 인내심만 있다면 전체 스택 (stack)이 구성됩니다.

특히 앱의 어휘가 사용자의 어휘와 일치하지 않게 되는 순간을 포착하는 데 매우 효과적입니다. 실제 전문가들은 자신들만의 약어 (shorthand), 사물을 명명하는 방식, 그리고 자신들을 낮게 평가하는 태도에 대한 그들만의 불만 사항을 가지고 있습니다. 만약 인터페이스가 이들이 실제로 말하는 방식을 반영하지 못한다면, 페르소나들이 이를 아주 강력하게 알려줄 것입니다.

이 접근 방식이 적합하지 않은 경우
로컬 페르소나 (local personas)는 실제 사용자가 아닙니다. 그들은 실제 이해관계, 실제 돈, 또는 실제 좌절감을 가지고 있지 않습니다. 그들은 당신의 가격 책정이 잘못되었다거나, 설치 과정이 너무 무섭다거나, 혹은 당신이 자랑스러워하는 부분에 도달하기도 전에 이탈했다는 사실을 말해주지 않을 것입니다.

캐릭터 메모리 (character memory)와 상세한 프로필이 있더라도, 페르소나는 때때로 벗어날 수 있습니다. 따라서 수시로 점검 (spot-check)해야 합니다. 리뷰를 절대적인 진리 (ground truth)가 아닌, 강력한 1차 필터로 취급하십시오.

여전히 인간 테스트 (human testing)는 중요합니다. 페르소나가 명백한 실패들을 잡아내줌으로써, 제가 확보할 수 있는 한정된 인간의 주의력을 더 미묘한 문제들에 집중할 수 있게 해줍니다.

결과 (The Payoff)
빌드 대화 외부에서 생성되기 때문에 더 나은 피드백을 얻을 수 있습니다. 모호한 편향 대신 감사 가능한 (auditable) 편향의 흔적을 남길 수 있습니다. 테스트 레이어가 이미 보유한 하드웨어에서 실행되므로 비용이 적게 듭니다. 아무것도 기기를 벗어나지 않으므로 프라이버시가 더 강화됩니다.

이것은 화려한 설정도 아니고, 모든 것을 해결해 주는 만능 해결책도 아닙니다. 데스크톱, 스크립트, 캐릭터 파일 더미, 기계가 밤새 작동하도록 내버려 두는 의지, 그리고 Claude가 리뷰에 의존할 때 실제로 그 인용문(citations)을 확인하는 절제력이 필요합니다. 팀 없이 정직한 결과물을 출시하려는 1인 개발자(solo builder)에게, 이것은 제가 올해 추가한 프로세스 중 가장 가치 있는 부분입니다.

당신의 앱을 만든 모델은 당신의 앱을 방어할 것입니다. 테스트를 모델이 닿을 수 없는 곳에 배치하고, 그 증거(receipts)를 보관하세요.