검증자가 병목이라는 말, 절반만 맞아요 · 제166호

들어가며

몇 년 전만 해도 이 일엔 이름이 하나였어요. 프롬프트 엔지니어링. 모델이 원하는 대로 움직일 때까지 문장 하나를 고치는 작업이었죠. 작년엔 같은 일에 컨텍스트 엔지니어링이라는 이름이 새로 붙었고, 올해 스레드에선 루프 엔지니어링이라고 불러요. 그 아래엔 늘 같은 문장이 따라붙어요. “이제 병목은 모델이 아니라 검증자예요.”

이름이 바뀔 때마다 개발자들은 똑같이 반응해요. “진짜 달라진 거야, 아니면 강의 하나 팔려고 페인트만 새로 칠한 거야?” 이 의심은 대체로 옳아요. AI 도구 용어는 그게 가리키는 문제보다 훨씬 빨리 갈아치워지거든요.

그래서 하나씩 뜯어볼게요. 결론부터 말씀드릴게요. 이름이 바뀔 때마다 실제로 ‘당신이 엔지니어링하는 단위’가 바뀌었어요. 페인트가 아니라 작업 대상 자체가요. 다만 가장 최신 이름이 가리키는 문제는 진짜인데, 이름은 그 문제에 이름표만 붙일 뿐 풀어주지는 않아요.

단위는 ‘프롬프트’였어요

2022년부터 2024년까지로 잡아볼게요. 작업의 단위는 프롬프트 하나였어요. 요청 하나의 문장을 다듬는 일이죠. 퓨샷¹ 예시를 넣고, 역할을 부여하고, “단계별로 생각해봐”를 붙이고, 무엇을 먼저 물을지 순서를 바꾸고. 당신이 통제하는 표면 전체가 메시지 한 통의 텍스트였고, 그걸 제대로 쓰는 게 기술의 전부였어요.

돌이켜보면 그 시절 노하우는 거의 다 ‘한 문장을 어떻게 쓰느냐’로 수렴했어요. 예시를 몇 개 넣을지, 어떤 순서로 물을지, 역할을 어떻게 줄지. 지금도 이 감각은 유효해요. 좋은 프롬프트는 여전히 좋은 결과의 출발점이거든요. 달라진 건, 그게 더 이상 ‘전부’가 아니라는 점이에요. 일 자체가 메시지 한 통에 안 들어가게 됐으니까요.

🧩 단위가 ‘표면’이 되었어요

2025년 중반, 안드레이 카파시가 사람들이 이미 하고 있던 일에 이름을 붙였어요. 컨텍스트 엔지니어링이요. 단위가 메시지에서 창(window) 안의 모든 것으로 넓어졌어요. 시스템 프롬프트, 검색해서 끌어온 문서, 도구 정의, 그리고 매 턴마다 함께 실리는 CLAUDE.md나 AGENTS.md² 같은 지시 파일까지요. 이제 문장 하나를 다듬는 게 아니라, 하나의 표면을 큐레이션하는 일이 된 거예요.

그 표면엔 개발자들이 비싼 값을 치르고서야 깨닫는 성질이 하나 있어요. 표면에 올려둔 것 대부분이 실제 행동에 연결되지 않는다는 거예요. 「The State of AI Instruction Quality」는 결정론적 분석기를 28,721개 저장소에 돌려서, 지시 파일 중앙값이 콘텐츠 항목 50개에 실제 지시문은 12개를 담고 있다는 걸 찾아냈어요. 나머지는 제목과 배경 설명, 그리고 모델이 얼마든지 무시해도 되는 구조였고요.

더 날카로운 실패 방식은 따로 글이 됐어요. 「Do NOT Think of a Pink Elephant」는 부정형으로 쓴 제약(“목업 쓰지 마”)이 오히려 금지한 바로 그 행동의 확률을 높일 수 있다는 걸 보여줘요. 방금 이 글 제목이 당신 머릿속에 핑크 코끼리를 띄운 것과 똑같은 이유로요.

둘 다 컨텍스트 엔지니어링의 문제이고, 측정됐고 공개됐어요.

🔁 단위는 이제 ‘루프’예요

2026년 6월, 용어는 루프 엔지니어링이에요. 애디 오스마니가 보리스 체르니와 페터 슈타인베르거의 논의를 엮어 퍼뜨렸고, 몇 주 만에 타임라인 전체로 번졌어요. 이제 단위는 돌아가는 루프예요. 생성하고, 검사하고, 방향을 잡고, 다시 시도하고, 멈추는. 프롬프트는 그 안의 노드 하나가 됐어요. 컨텍스트 표면은 루프가 반복 사이에 실어 나르는 상태(state)가 됐고요.

(그림: 프롬프트 → 모델 생성 → 검증자(이만하면 됐나?) → 멈춤. 검증자에서 ‘방향 잡고 재시도’로 되돌아가는 고리가 있고, 컨텍스트 표면이 모델 생성에 함께 들어가요.)

모든 설명글이 반복하는 주장은 이거예요. 이제 한계를 정하는 건 모델이 아니라, ‘이만하면 됐다, 멈춰’를 결정하는 검사라는 거죠. 이 이름을 후하게 받아들여 볼게요. 앞의 두 이름이 은근슬쩍 넘어갔던 걸 이 이름은 정면으로 가리켜요. 한 번의 반복이 괜찮았는지, 한 번 더 돌릴지를 판정하는 장치요. 그 장치는 늘 있었어요. 재시도하는 에이전트라면 전부 갖고 있죠. 루프 엔지니어링이 보탠 건, 그 장치를 그냥 물려받는 기본값이 아니라 당신이 직접 설계하는 대상으로 끌어올렸다는 점이에요.

🔑 그래서 검증자는 뭘 검사하죠?

“검증자가 병목이다”는 좋은 슬로건이에요. 그리고 절반짜리예요. 병목이 어디인지는 짚어주면서, 그 검증자가 대체 뭘 검사해야 하는지는 말해주지 않거든요. 그 빈칸이 바로 슬로건이 건너뛴 엔지니어링 문제예요.

검사에는 두 종류가 있어요. 서로 바꿔 쓸 수 없어요. 결정론적 검사³는 코드를 실행하고, 종료 상태를 확인하고, 금지된 임포트가 있는지 훑고, 같은 입력에 늘 같은 판정을 돌려줘요. 중간에 판단이 끼지 않아요. 모델 기반 검사⁴는 다른 모델에게 “이거 괜찮아?”라고 물어요. 첫 번째 방식이 표현하지 못하는 기준, 그러니까 “이 설명이 명확한가”, “이거 무례하게 읽히나” 같은 걸 짚을 수 있어요. 대신 그 대가로, 루프가 애초에 가두려던 바로 그 불안정성을 그대로 물려받아요. 확률적으로 생성하는 쪽이 언제 끝났는지를, 확률적으로 판단하는 심판에게 맡기는 셈이에요.

실제 루프에서 둘이 갈라지는 지점을 볼게요. 에이전트에게 모듈 하나를 리팩터링하고 끝나면 멈추라고 시켰어요. 결정론적 검증자는 테스트가 여전히 통과하는지, 금지된 임포트가 슬쩍 끼어들지 않았는지 증명할 수 있어요. 매 반복마다 확인 가능한 사실이고, 다툴 여지가 없죠. 하지만 그 리팩터링이 할 만한 가치가 있었는지는 판단하지 못해요. 그래서 그걸 답하려고 모델 기반 검사를 덧붙이면, 이제 멈춤 조건이 ‘한 모델이 다른 모델의 안목을 채점하는’ 위에 얹혀요. 루프는 심판이 만족할 때 끝나는데, 그 심판은 루프가 감독하려고 존재하는 바로 그 부류의 부품이에요.

어느 쪽도 틀린 게 아니에요. 둘은 서로 다른 질문에 답해요. 내가 지금 어느 질문을 던졌는지 헷갈리는 순간, 루프는 엉뚱한 반복에서 자신 있게 멈춰버려요.

실무에서 헷갈릴 때 저는 이렇게 갈라요. “이 기준을 다른 모델에게 묻지 않고, 실행하거나 스캔해서 참·거짓으로 뽑아낼 수 있나?” 뽑아낼 수 있으면 결정론적 검사로 두는 게 거의 항상 맞아요. 값이 싸고, 흔들리지 않고, 왜 실패했는지 로그가 남거든요. 반대로 그 기준이 오직 사람 머릿속에서만 성립하면(예: “이 카피가 브랜드 톤에 맞나”) 모델 판정을 피할 도리가 없어요. 그럴 땐 최소한 판정 기준을 잘게 쪼개서, 모델이 자유롭게 총평하지 않고 체크리스트 항목별로 답하게 묶어두는 편이 흔들림을 줄여줘요. 판정을 아예 없애는 게 아니라, 판정이 흔들릴 여지를 좁히는 거예요.

이 트레이드오프, 그러니까 ‘검사가 실제로 무엇을 검사하는가’는 새로운 문제가 아니에요. 「Green Tests Don’t Mean Better Software」가 이걸 CI 버전으로 다뤄요. 초록불이 뜬 테스트는 코드가 명세에 맞는다는 걸 증명할 뿐, 그 변경이 시스템을 나아지게 했는지는 아무 말도 하지 않아요. 검사는 당신이 던지지도 않은 질문에 답한 거예요. 같은 구분을 테스트 스위트 대신 에이전트 루프에 겨누면, 모든 개발자가 이미 신뢰하는 사례로 루프 엔지니어링의 질문이 그대로 서술돼요.

오스왈드의 시선

솔직히 말씀드리면, 저는 이 이름이 반갑기도 하고 조심스럽기도 해요.

GTM 전략을 오래 짜오면서 수없이 본 패턴이 있어요. “기술이 바꿀 것이다”라는 전망은 대체로 맞아요. 다만 시기와 경로를 거의 다 틀려요. 새 용어가 뜰 때마다 저는 먼저 이 패턴부터 의심해요. 그런데 이번 세 번의 개명은 조금 달라요. 이름이 바뀔 때마다 마케팅이 아니라 작업 대상이 실제로 움직였거든요. 문장에서 표면으로, 표면에서 루프로요. 그래서 저는 이 개명들을 정직한 축에 놓아요.

다만 여기서 냉정해질 지점이 있어요. 이름은 당신에게 ‘대상’을 쥐여줘요. 검증자를 만드는 일은 여전히 당신 몫이고, 그게 일의 대부분이에요. 어떤 작업에서 ‘맞다’가 무엇인지 정의하고, 그걸 돌릴 수 있는 검사로 바꾸는 일이요.

그 일의 절반은 검사의 종류를 고르는 거예요. 데이터를 다루던 습관으로 보면 이건 측정 설계 문제예요. “이 설명이 명확한가”는 모델이 판단해야 해요. “금지된 임포트가 없다”는 결정론적 스캔이면 충분하고요. 잘못 고르면 양쪽으로 비용을 치러요. 결정론적 검사면 될 걸 모델 심판에게 맡기면 공짜로 불안정성을 사들이는 거고, 판단이 필요한 자리에 결정론적 검사를 세우면 보기보다 의미가 얕은 초록불을 얻어요. 이름은 이 선택을 눈에 보이게 만들어줄 뿐, 대신 골라주지는 않아요.

마치며

정리하면 이래요. 첫째, 프롬프트에서 컨텍스트로, 다시 루프로 이름이 바뀐 건 페인트칠이 아니라 엔지니어링하는 단위가 실제로 커진 거예요. 둘째, “검증자가 병목”은 맞지만 절반이에요. 나머지 절반은 그 검증자가 무엇을, 어떤 방식으로 검사하느냐고요. 셋째, 이름은 문제에 이름표를 달아줄 뿐, 검증자를 짓는 건 그대로 당신 숙제로 남아요.

이 루프는 부품이 여러 개예요. 앞으로 몇 편에 걸쳐 루프를 한 조각씩 떼어내서, 각 조각 아래에 측정을 하나씩 깔아볼 생각이에요. 잘못된 곳에서 울리는 검사와 아예 없는 신호를 어떻게 구분하는지, 방향을 잡는 규칙과 거부하는 규칙이 어떻게 다른지, 컨텍스트 표면에 올린 지시 하나가 매 턴 얼마의 비용을 물리는지. 오늘 글이 던진 질문들이 다음 편들의 출발점이에요.

혹시 에이전트 루프를 직접 굴려보셨다면, 멈춤 조건을 결정론적 검사로 두셨나요, 아니면 모델 심판에게 맡기셨나요? 어디서 가장 크게 데셨는지 댓글로 들려주세요. 다음 호 소재로 반영해볼게요.

💬 멈춤 조건을 어떻게 설계하셨는지 댓글로 들려주세요 · 📨 에이전트를 만드는 동료가 있다면 이 글을 전달해 주세요

참고자료 & 더 읽기

핵심 출처

reporails, “The State of AI Instruction Quality”. : 지시 파일 중앙값이 콘텐츠 50개에 실제 지시문 12개라는 데이터의 출처예요.
cleverhoods, “Do NOT Think of a Pink Elephant”. : 부정형 제약이 금지한 행동의 확률을 높인다는 주장의 출처예요.
reporails, “Green Tests Don’t Mean Better Software”. : 검사가 던지지도 않은 질문에 답한다는 논지의 출처예요.
cleverhoods, “Prompt Engineering, Context Engineering, Loop Engineering: What Actually Changed”. : 오늘 뉴스레터가 골격으로 삼은 원출처예요.

배경 지식

안드레이 카파시, ‘컨텍스트 엔지니어링’ 명명 (2025년 중반). : 이 용어가 어디서 왔는지 짚어주는 출발점이에요.
애디 오스마니, ‘루프 엔지니어링’ 정리 (2026년 6월, 보리스 체르니·페터 슈타인베르거 논의 종합). : 오늘 글의 세 번째 이름이 퍼진 경로예요.

📝 용어 설명

필자 안광섭은 세종대학교 경영학과 교수이자 OBF(Oswarld Boutique Consulting Firm) 리드 컨설턴트이다. 대학에서 경영데이터 관리, 비즈니스 애널리틱스 등 통계 및 데이터 분석을 가르치는 한편, 현장에서는 GTM 전략과 인공지능 전략 컨설팅을 이끌며 기술과 비즈니스의 접점을 설계하고 있다. AI 대화 시스템의 기억 아키텍처(HEMA) 연구로 학술 논문을 발표했으며, 매일 글로벌 AI 논문을 큐레이션하는 Daily Arxiv 프로젝트를 운영하고 있다. 고려대학교 기술경영전문대 석사과정와 KMBA을 졸업했다. 지은 책으로 《생각을 맡기는 사람들: 호모 브레인리스》가 있다.

각주

퓨샷(few-shot): 모델에게 예시 몇 개를 보여주고 원하는 형식이나 방식을 따라 하게 만드는 방법이에요. 예시 없이 그냥 시키는 것보다 결과가 안정적이에요. ↩
CLAUDE.md / AGENTS.md: AI 코딩 도구에게 “이 프로젝트에선 이렇게 일해”라고 알려주는 지시 파일이에요. 매 대화 턴마다 함께 딸려 들어가요. ↩
결정론적 검사(deterministic check): 같은 입력에 늘 같은 결과를 내는 검사예요. 코드 실행, 종료 코드 확인, 금지 단어 스캔처럼 판단이 끼지 않는 기계적 확인이에요. ↩
모델 기반 검사(model-graded check): 결과가 좋은지 나쁜지를 또 다른 AI 모델에게 물어서 판정하는 방식이에요. 사람 같은 판단을 흉내 낼 수 있지만, 그만큼 결과가 흔들릴 수 있어요. ↩