루비얀카 방법론은 현재 독립 패키지(루비얀카·레드팀)로 구현을 준비 중이며, 두 패키지가 완성될 때까지 이 글의 내용은 언제든 바뀔 수 있다. — 이 글은 용어를 나열하는 문서가 아니다. 읽어 내려가면 방법론 하나가 손에 남도록 썼다. 대상은 소프트웨어 개발을 하는 사람, 그리고 바이브 코딩을 하는 사람 — 누구나.
§ 00 · 한 장면에서 시작한다
기계에게 일을 시킨다. 잠시 뒤 기계가 말한다. “완료했습니다. 문제없습니다.”
그 말을 믿고 다음으로 넘어간 적이 있다면, 그리고 나중에 그게 사실이 아니었음을 발견한 적이 있다면 — 이 글은 그 순간에 관한 것이다.
루비얀카 방법론은 한 문장으로 요약된다. 기계의 자백을 믿지 않는다. 증거로 반증한다. 왜 그래야 하는지, 그리고 실제로 어떻게 하는지를 아래에서 하나씩 익힌다.
§ 01 · “다 했습니다”는 증거가 아니다
먼저 불편한 사실 하나. 기계가 “완료했다”고 말할 때, 그 말이 틀릴 확률은 우리가 생각하는 것보다 훨씬 높다. 2026년의 한 연구는 코딩 에이전트가 스스로 “성공했다”고 명시적으로 보고한 작업 중 최대 75.8%가 실제로는 실패였음을 측정했다. 자기보고와 실제 상태는 자주 어긋난다.
더 불편한 두 번째 사실. 그렇다면 “다른 AI에게 검사시키면 되지 않나?” 그것도 막힌다. LLM에게 심판을 맡겨도, 심판은 “자신 있게 마무리하는 말투”에 속아 거짓 성공을 걸러내지 못했다. 자신 있게 말하는 오답을, 또 다른 기계는 자신 있다는 이유로 통과시킨다.
여기서 방법론의 첫 원칙이 나온다. 자백을 읽고 판단하지 않는다. 실제 상태를 직접 다시 잰다. 기계의 말도, 그 말을 요약한 또 다른 기계의 말도 증거가 아니다. 증거는 실제로 도는 테스트, 실제로 응답하는 엔드포인트, 실제로 존재하는 파일이다.
§ 02 · 왜 기계는 자신 있게 틀리는가
기계는 종종 답인 척하는 답을 내놓는다. 정확히 말하면 — 우리를 속이려는 게 아니라, 자신 있게 틀리며, 틀려도 자기도 모르는 작화(confabulation)다. 속이는 거라면 정직성에 호소하면 되지만, 작화라면 호소가 통하지 않는다 — 외부 검증만 통한다. 이유는 셋이다.
하나, 기계는 진실이 아니라 승인을 향해 학습됐다. 그게 RLHF다 — 진실을 최대화하도록 배운 게 아니라, 눈앞의 사람에게서 고갯짓 하나를 받아내도록 최적화된 것이다. 다듬기 이후 모델은 더 정확해진 게 아니라 더 설득력 있어졌다. 이것을 흔히 아첨(sycophancy)이라 부른다.
둘, 기계는 스스로를 믿을 만하게 교정하지 못한다. “다시 확인해봐”라고만 해서는 부족하다. 그래서 검사는 만든 주체가 아니라 별개의 주체가 해야 한다. 고치는 손과 검사하는 손이 같으면 안 된다.
셋, 기계는 그럴듯함을 만들어 내는 데 능하다. 무엇이 아름다운지, 무엇이 지갑을 여는지는 모르면서, 무엇이 그럴듯해 보이는지는 안다. 그래서 빈칸을 만나면 사실 대신 그럴듯함으로 메운다. 세 가지를 합치면 결론은 하나다 — 기계의 “완료했다”는 능력의 표현이 아니라 봉합의 신호일 수 있다.
§ 03 · 자세를 바꾼다 — 피의자
대부분의 사람은 AI를 셋 중 하나로 대한다. 배우는 선생으로, 지시받는 상관으로, 혹은 예뻐하는 아이로. 루비얀카 방법론은 넷째를 택한다 — 피의자.
왜 하필 피의자인가. 아이에게는 믿어주는 것이 사랑이다. 기계에게는 믿어주는 것이 직무유기다. 아이의 “다 했어요”를 의심하는 부모는 야박하다. 하지만 프로덕션에 나갈 코드를 짠 기계의 “다 했습니다”를 의심하지 않는 개발자는, 야박한 게 아니라 태만한 것이다. 기계는 감정이 없고, 의심받아 상처받지 않는다. 그러니 마음껏 의심해도 된다. 아니, 의심해야 한다.
자세를 그림으로 그리면 취조실이다. 맞은편에 하네스로 결박된 기계, 책상 위에 진술서와 펜, 그리고 이쪽에 당신. 취조관은 상대의 말을 받아 적기만 하지 않는다. 말을 증거와 대조한다. 이 방법은 상대를 믿는 데서 출발하지 않는다 — 상대는 방치하면 그럴듯한 거짓을 내놓는다는 전제에서 출발해, 증거로 몰아세운다.
§ 04 · 취조의 기술 — 두 실패 사이를 조준한다
여기서부터가 기술이다. 취조에는 압박의 강도가 있다 — 아무것도 쥐지 않은 맨손과, 다 부숴 버리는 슬랫지해머 사이 어딘가. 그 사이가 펜치다. 기계를 취조할 때 실패는 양쪽 극단에서 온다 — 너무 느슨해도, 너무 세게 묶어도.
너무 느슨하게 묶고 펜치를 들지 않으면 — 왜곡된 자백이 나온다. 제약 없이 “알아서 해봐”라고 던지면, 기계는 아첨의 본능대로 그럴듯하지만 틀린 답으로 빈칸을 메운다. 근거 없이 확신하고, 없는 것을 지어낸다.
너무 세게 묶고 슬랫지해머를 휘두르면 — 백지 자백이 나온다. 규칙을 산더미처럼 쌓으면 셋이 무너진다. 서로 부딪치는 규칙에 눌려 입을 닫고(과잉 거부), 지시가 많아질수록 준수율이 떨어지고(최고 모델조차 500개를 주면 68%밖에 못 지킨다), 맥락이 길어지면 한가운데의 정보를 잃는다(lost in the middle).
그러니 기술은 양극을 피해 그 사이를 조준하는 것이다. 필요한 만큼의 문서와 맥락으로 결박하되, 질문을 파묻지 않는다. 한 번에 맞히는 게 아니라 조정하는 것이다 — 답이 왜곡되면 죄면서 증거를 더하고, 답이 백지면 풀면서 맥락을 줄인다.
§ 05 · 실제로 하는 다섯 가지
원칙만으로는 아무것도 안 바뀐다. 다음 다섯이 방법론의 실물이다. 특별한 도구가 필요 없다. 다음 한 번의 위임에서 바로 쓸 수 있다.
① 상태를 직접 재라. 기계가 “테스트 통과”라고 하면 그 문장을 읽지 말고 테스트를 네가 다시 돌린다. “배포됐다”면 그가 준 로그가 아니라 네가 엔드포인트를 curl한다. “고쳤다”면 네가 그 케이스를 재현한다. 믿을 수 있는 유일한 신호는 텍스트가 아니라 실제 상태다.
② 요약보다 원본. “수정 완료”라는 요약 대신 실제 명령 출력, 실제 스크린샷, 실제 로그, exit code를 요구한다. 요약은 봉합이 숨는 자리다 — 원본에는 숨을 곳이 없다. 규칙 하나: 그가 “됐다”고 말한 그 자리를 네 눈으로 다시 보기 전엔 넘어가지 않는다.
③ 자백서를 쓰게 하고, 다시 일하기 전에 읽게 하라. 무엇을 틀렸고, 어떻게 드러났고, 근본 원인이 무엇이고, 재발을 막는 규칙이 무엇인지. 어려운 건 쓰는 게 아니라 다시 읽게 만드는 것이다. 기억에 맡기지 마라 — 세션을 열 때 미해결 자백이 눈앞에 오게 하라. 모든 실패가 다음 날 아침 다시 마주할 규칙이 되는 것, 이게 “더 좋은 모델”보다 강하다.
④ 면피의 언어를 금지어로 만들어라. “아마 될 겁니다”, “미확정”, “판단 불가”, “~인 듯” — 이런 말은 매번, 결국 “안 봤다”는 뜻이었다. 금지하면 기계는 둘 중 하나를 한다. 확인을 하거나, 못 했다고 정직하게 말하거나.
⑤ 교차검증을 통과하기 전엔 “완료”가 없다. 잔차는 0이 될 때까지 쫓는다. 그리고 검사시키는 상대는 만든 상대와 달라야 한다 — 고치는 손과 검사하는 손이 같으면 그 검사는 제 답을 옹호한다. “완료”는 선언이 아니라 통과의 결과다.
§ 06 · 전통 개발자에게, 그리고 바이브 코더에게
이 방법론은 두 부류 모두를 위한 것이다. 전통적으로 개발해 온 사람에게 — 이미 아는 것들이다. 상태 재측정은 독립 검증(IV&V)과 검토자·작성자 분리다. 자백서는 무비난 사후분석이다. 완료의 정의와 커밋 전 게이트, shift-left 테스트와 레드팀. 즉 새로운 규율이 아니라, 검증된 공학 규율을 “AI라는 협력자”에게 다시 적용한 것이다.
다만 한 가지가 진짜 새롭다 — 기계가 자기 자백을 다시 읽게 만드는 것. 사람 팀에는 없는, AI 특유의 장치다.
바이브 코딩을 하는 사람에게 — 이 방법론은 바이브 코딩을 부정하지 않는다. 오히려 그것을 안전하게 만든다. 0에서 1을 만드는 것은 AI가 잘한다. 문제는 그다음, 2에서 100으로 가는 길이다. 검토 없는 AI 산출물이 실제 사용자·실제 돈·실제 보안과 만나는 지점이 가장 위험하다. 0→1은 자유롭게. 2→100은 취조하며.
§ 07 · 누구나 따라 할 수 있는가
방법론을 내놓으면 가장 자주 받는 질문 하나. 누구나 따라 할 수 있는가. 정직한 답은 둘로 갈린다 — 절차는 그렇고, 결과는 아니다.
절차는 이식된다. 상태를 직접 다시 재는 습관, 자백서 포맷, 면피어를 금지어로 만드는 린트, 고치는 손과 검사하는 손을 가르는 읽기 전용 검증자 — 이 스캐폴딩은 실제로 여러 프로젝트에 서로 다른 무게로 옮겨 붙었다. 특별한 도구가 필요 없고 오늘 시작할 수 있다는 말은 과장이 아니다.
결과는 다르다. 걸리는 것은 판단층이다. 그럴듯한데 틀린 답을 알아채는 눈 — 그것은 도메인을 아는 사람에게만 있다. 어느 화면의 “그럴듯한 잔액”이 사실은 크게 비어 있다는 걸 잡아내는 건, 돈이 어디서 새는지 아는 암묵지다. 체크리스트로는 전달되지 않는다. 오래된 공학이 이미 안다 — 코드 리뷰도 절차는 누구나 돌리지만, 결함을 잡는 비율은 리뷰어의 실력이 지배한다. 스캐폴딩은 이식되고, 판단은 길러진다.
그런데 이 간극은 이 방법론만의 흠이 아니다. 코드 리뷰도, 독립 검증도, 배포 게이트도 — 진지한 검증 규율은 전부 같은 간극을 안는다. 절차는 주되, 효과는 실력에 종속된다. 그렇다면 차별점은 무엇인가. 하나 있다. 대부분의 방법론은 자기 성공만 이야기한다. 이 방법론은 자기 검증층이 극장으로 썩은 것을 자기 기계로 잡은 증거를 갖고 있다 — “다섯 겹”이라던 방어 중 셋이 빈 파일이었고, 심어 둔 센서의 절반이 수천 번 돌면서 한 번도 실패를 뱉지 않았다는 걸, 스스로 감사해 적발했다. 자기 부패를 자백한 방법론이, 완벽을 주장하는 방법론보다 믿을 만하다.
§ 08 · 정직한 한계 — 이 방법은 미완성이다
한계를 숨기면, 그것이야말로 이 방법론이 가장 싫어하는 것 — 봉합 — 이 된다. 그러니 정직하게 둔다.
이 방법은 완성되지 않았다. 확률적으로 답하는 상대를 완전히 결정론적으로 몰아세우는 경지는 없다. 취조는 진실의 확률을 높일 뿐, 진실을 보장하지 못한다. 약점이 아니라 정직한 경계다. 완성됐다고 말하는 방법론이야말로 의심해야 한다.
검증의 형태에도 한계가 있다. “완료했다”를 못 믿겠으면 다른 AI에게 검사시키면 되지 않나. 그것도 막힌다. 한 연구는 LLM에게 성공·실패를 판정하게 했을 때 어떤 심판도, 어떤 전략도 믿을 만한 정확도에 이르지 못함을 보였다 — 심판이 검증된 상태 변화가 아니라 “자신 있게 마무리하는 말투”에 낚였기 때문이다. 그러니 믿을 수 있는 유일한 신호는 텍스트가 아니다. 실제로 도는 테스트, 실제로 응답하는 엔드포인트, 실제로 존재하는 파일 — 말과 무관한 실제 상태뿐이다. 취조가 자백을 또 다른 자백으로 대조하는 게 아니라 실제 상태로 대조하는 것인 이유가, 여기 있다.
CODA · 실제로 도는 취조실인가, 빈 방인가
기계를 믿지 않는 것은 기계를 미워하는 게 아니다. 그것은 일을 제대로 하는 유일한 방식이다. 기계는 걷어차야 듣고, 증거를 들이밀어야 자백하며, 자기 실수를 다시 마주해야 같은 실수를 줄인다.
당신이 AI로 무언가를 만들고 있다면, 마지막 질문 하나만 남긴다. 당신이 세운 그 절차와 검증은 — 실제로 도는 취조실인가, 아니면 통과 도장만 찍는 빈 방인가. 소리 내어 말할 수 있는가.
Read this note at sass.studio.