첫 출력을 신뢰하지 않습니다 — Nick Saraev가 말하는 10회 eval로 오늘 프롬프트 하나를 고정합니다 | DAKER 커뮤니티

Claude Code에 수만 달러를 쓰고도, 같은 프롬프트가 어떤 날은 잘 되고 어떤 날은 무너지는 경험을 해 보셨을 겁니다. Nick Saraev의 유튜브 영상 「I Spent $31,141 & 1,000 Hours On Claude Code To Learn This」(2026-09-25)는 그 원인을 “모델이 비결정적”이라는 사실에서 출발해, 빌더가 오늘부터 바꿀 수 있는 운영 습관으로 정리합니다. 오늘은 영상 기준으로 핵심만 추리고, 반복 쓰는 프롬프트 하나를 10회 eval로 고정하는 일부터 제안합니다.

첫 출력을 신뢰하지 말고 10회 eval로 고정하는 흐름을 정리한 생성 이미지 — 설명용 생성 이미지입니다.

한 번 잘 나온 결과를 SOP에 올리지 말고, 같은 프롬프트를 여러 번 돌려 성공 횟수가 오른 변경만 남깁니다.

왜 첫 출력을 믿으면 안 되나요

영상은 대형 조직에서도 첫 출력을 그대로 표준화했다가 나중에 품질 편차로 고생하는 사례를 언급합니다. 같은 프롬프트를 여러 번 넣으면 결과가 조금씩, 때로는 크게 달라집니다. 한 번 최대치(좋은 결과)에 걸리면 “됐다”고 느끼기 쉽지만, 다음 실행에서는 최저치에 걸릴 수 있습니다. 그래서 프롬프트를 업무 절차에 넣기 전에 평가(eval)를 돌리라고 말합니다. 예로 열 번 실행해 성공 횟수를 세고, 프롬프트를 살짝 고친 뒤 다시 열 번 돌려 점수가 오른 쪽만 남기는 방식입니다. 감이 아니라 비교 가능한 숫자로 고르는 과정입니다.

스스로 점검하는 루프를 넣습니다

에세이를 한 번에 제출하지 않고 초안·수정·최종을 거치듯, 모델에도 점검 기회를 주라고 합니다. 스크린샷 비교, 예시와 대조, 웹사이트라면 Lighthouse 같은 표준 측정처럼 “무엇을 보고 고칠지”를 정해 두면, 프롬프트가 거칠어도 최종 품질이 올라가기 쉽습니다. 대회·해커톤 코드에서도 테스트 통과·형식 검사·샘플 제출 검증처럼 자동 확인 한 줄을 루프에 넣는 쪽이, “한 번에 잘 써 줘”보다 영상 메시지와 잘 맞습니다.

완료 조건만 분명히 주고, 예전의 never 나열은 줄입니다. 모르는 일은 물어보게 두는 편이 낫습니다.

맥락을 아끼고, 코드가 진실이 되게 합니다

영상은 스킬·노트·스펙이 코드보다 뒤처지면 모델이 옛 설명에 끌린다고 경고합니다. 가능하면 코드와 인라인 주석이 바로 맥락이 되게 하고, CLAUDE.md에는 선호·교훈·작업 방식처럼 “코드가 말해 주지 않는 것”만 둡니다. 채팅에서는 /context로 시스템 프롬프트·도구·MCP·스킬이 이미 창을 얼마나 먹는지 보고, 쓰지 않는 MCP와 스킬은 끕니다. 긴 설계 대화로 만든 프롬프트는 같은 창에서 계속 쓰지 말고, 내용을 복사해 새 세션으로 옮기라고 합니다. /compact도 자동 시점보다 일찍 쓰는 편이 낫다고 말합니다.

고치기 전에 목록을 받고, 병렬은 범위를 나눕니다

“앱이 깨졌으니 고쳐”보다 “문제를 나열만 하고, 아직 고치지 마”가 먼저입니다. 목록을 본 뒤 실제로 고칠 항목만 고르면, 모델이 임의로 손댄 톤·스타일까지 되돌리는 이중 비용을 줄일 수 있습니다. 서로 겹치지 않는 작업(히어로·폼·로그아웃처럼)은 병렬 서브에이전트로 돌리고 마지막에 합치는 패턴도 소개합니다. 속도는 올라가지만 충돌 가능성은 커지므로, 범위를 분명히 나누는 것이 전제입니다.

세션이 길어지면 핸드오프와 /btw

오래 대화할수록 앞뒤 지시가 섞여 모델이 중간값을 고르기 쉽습니다. 결과가 이상하면 “완료된 일·결정이 필요한 일·다음 일·열린 문제”를 요약하게 한 뒤, 틀린 부분만 고쳐서 새 메시지(또는 새 세션)로 넘깁니다. 작업 중에 궁금한 점은 /btw로 옆질문을 던집니다. 메인 맥락을 덜 오염시키면서, 끝난 뒤에야 상태를 묻는 대기 시간도 줄입니다. 조사는 싼 모델로 넓게 모으고(fan-out), 강한 모델이 결정을 내리는(fan-in) 흐름도 같은 맥락입니다.

오늘 바로 할 일

반복해서 쓰는 프롬프트(이슈 요약, 코드 리뷰, 제출 전 점검 등) 하나를 고릅니다.
성공 기준을 한 줄로 적습니다. 예: 필수 항목이 빠지지 않는다, 테스트 명령을 제안한다.
같은 입력으로 열 번 실행하고 성공 횟수를 셉니다. 숫자를 표에 남깁니다.
프롬프트를 한 가지만 고친 뒤 다시 열 번 돌려, 점수가 오른 쪽만 남깁니다.
CLAUDE.md를 열어 낡은 숫자·옛 API·더 이상 쓰지 않는 금지를 지우고, 오늘 남긴 성공 기준 한 줄을 선호 규칙으로 추가합니다.

시간이 더 있으면 MCP 목록을 줄이고, Codex 등 백업 도구용 AGENTS.md를 CLAUDE.md와 맞춰 두는 작업까지 가면 영상의 “장애 대비” 조언과도 이어집니다. 대회 저장소라면 제출 스크립트·비밀값은 사람이 관리하고, 에이전트에게는 진단 목록과 테스트 검증만 맡기는 편이 안전합니다.

정리

이 영상은 더 센 모델을 기다리라는 이야기가 아닙니다. 첫 출력을 표준으로 올리지 말고, eval·자체 점검·맥락 절약·진단 우선·핸드오프·백업 도구로 편차를 줄이라는 실무 노트에 가깝습니다. 오늘 할 일은 단순합니다. 프롬프트 하나를 골라 열 번 재고, 점수 오른 문장만 남기면 됩니다.

오늘 남긴 성공 횟수가, 내일의 CLAUDE.md보다 먼저입니다.

여러분은 어떤 프롬프트를 먼저 10회 eval에 올려 보시겠습니까? 댓글로 기준 한 줄과 성공 횟수를 공유해 주시면 다른 분에게도 도움이 됩니다.

출처
Nick Saraev, 「I Spent $31,141 & 1,000 Hours On Claude Code To Learn This」, YouTube, 2026-09-25.
https://www.youtube.com/watch?v=45K3zHckCnQ