메타데이터
- 날짜: 2026-07-19
- 채널: aiDotEngineer
- 발표자: Annabelle (Langfuse, Growth Engineer)
- 원본 URL: https://www.youtube.com/watch?v=eAXxdtNlK04
- 태그: #AI #LLM #에이전트 #자기개선루프 #평가 #evaluator #프롬프트최적화 #langfuse
1계층 — 핵심 주장 및 논거 (상세)
2026년 6월 현재 AI 업계는 "루프(loop)" 열풍이다. Boris(코딩 에이전트 진영), Peter Steinberger는 "프롬프트를 쓰지 말고 루프를 설계하라"고 말하고, Karpathy의 자동 리서치·자기개선(auto-improvement) 화두도 올해 초부터 크게 확산됐다. 그런데 이런 담론은 대부분 개발자(코딩) 관점에서 나온다. 코딩이 자기개선 루프에서 유독 잘 작동하는 이유는 명확한 타겟 함수(target function)가 있기 때문이다 — "코드가 컴파일되는가, 안 되는가." 물론 컴파일된다고 좋은 코드라는 보장은 없지만, 최소한 "작동은 한다"는 확실한 신호를 준다.
문제는 의료 규제 준수, 헬스케어, 챗봇 등 대부분의 실제 AI 애플리케이션 도메인에는 이런 명확한 예/아니오 타겟 함수가 없다는 것이다. 에이전트에게 주는 목표(target)는 본질적으로 항상 불완전하다 — 처음엔 A 방향이 최적이라 생각하지만 실제 최적 지점은 다른 곳에 있을 수 있고, 이걸 알아내는 데는 시간이 걸린다. 그럼에도 불구하고, 타겟 함수를 정교하게 포착하고 좋은 평가자(evaluator)를 구축하는 데 투자하는 팀이 결국 애플리케이션을 지속적으로 개선하고, 확신을 갖고 배포(ship)할 수 있는 팀이라는 것이 Langfuse 팀의 관찰이다. 왜냐하면 시스템이 의도한 대로 작동한다는 걸 알면, 코드를 푸시한 뒤에도 밤에 편히 잘 수 있기 때문이다.
이걸 검증하기 위해 Langfuse 팀은 "가장 명확한(clear-cut) 타겟 함수"를 찾을 수 있는 실험을 설계했다: 단일 라벨 분류(single-label classification). 참/거짓이 명확히 갈리는 task이기 때문에, "타겟 함수의 역할"을 자기개선 루프에서 순수하게 관찰할 수 있는 최적의 실험 조건이다.
실험 설계
- 태스크: arXiv 논문을 제목·초록 기반으로, 저자가 붙인 primary label(카테고리)로 분류
- 데이터: fit(학습/에러분석용) 200개, validate(검증) 100개, test(홀드아웃) 300개
- 에이전트: GPT-5-nano 기반의 단순 프롬프트 (일부러 작고 저렴한 모델 선택 — 자기개선이 저비용 모델에서도 통하는지 보기 위함)
- 최적화기(optimizer): Claude Code + Opus 4.8(프론티어 모델)이 프롬프트 업데이트를 제안. 컨텍스트로 GPT-5 프롬프팅 가이드와, 루프 절차를 설명하는 task.md를 참조
- 기본 프롬프트: 라벨을 그냥 나열한 플랫 리스트 + "이 논문을 라벨링하라"는 단순 지시 (설명 없음, 사고 방식 안내 없음 — 의도적으로 미니멀하게 시작)
루프 절차
- fit·validate 셋에 기본 프롬프트를 돌려 baseline 정확도 산출
- fit 셋에서 에러 분석 — 어떤 카테고리가 자주 맞는지, 어떤 라벨 쌍이 자주 혼동되는지, 그 근거가 되는 abstract/title 패턴 파악
- 가장 큰 에러 카테고리에 대해 Opus가 프롬프트 수정 가설을 제안하고 반영
- validation 셋에서 개선이 확인될 때만 그 수정을 채택(overfitting 방지)
- 정지 조건: 15회 반복 완료 또는 92% 정확도 도달
- 정지 후 마지막에 한 번, 이전까지 전혀 노출되지 않았던 test 셋으로 최종 검증
결과
- 1회차: 68% → 3~4회차: 83%까지 상승 후 ~80% 선에서 정체(plateau)
- test 셋(unseen 300개)에서도 80.2% — 일반화가 잘 됐음을 확인
- 가장 흥미로운 지점: 1회차 반복만으로 68%→78%까지 약 10%p가 즉시 상승. 이후 반복에서는 미세한 개선만 있었음. 즉 "가장 큰 정보"는 첫 번째 루프에서 이미 다 뽑아냈다는 뜻.
- 정체 원인 분석: 라벨 자체에 원 저자의 "창의적 재량"이 있었음 — 설명상 다른 라벨이 더 타당해 보여도 저자가 그 순간의 판단으로 다른 라벨을 택한 경우가 있고, 이건 데이터에 기록되지 않으므로 100% 정확도는 애초에 불가능한 상한선이 존재했던 것.
첫 반복에서 실제로 무엇이 바뀌었나
Opus가 프롬프트에 추가한 것은 (발표자가 예상했던 "라벨별 설명 추가"가 아니라):
- 일반적인 분류 접근법 — 라벨을 고를 때 모델이 어떤 기준으로 사고해야 하는지에 대한 가이드
- 유사 클래스 간 구분 기준 — 두 라벨이 헷갈릴 때 어떻게 판단할지, 더 구체적인(specific) 라벨을 더 포괄적인(broad) 라벨보다 우선하라는 규칙(라벨 구조에 내재된 암묵적 위계 활용)
- 자주 혼동되는 항목 쌍의 구체적 예시
Opus의 추론(reasoning) 트레이스를 들여다본 결과: "64개의 에러가 있다 → 지배적 패턴은 이것이다 → 가장 많이 혼동되는 라벨 쌍은 이것이다 → 이 패턴을 정확히 겨냥한 규칙을 추가하면 해결된다"는 식으로, 명확하게 정량화 가능하고 신뢰할 수 있는 실패 모드를 근거로 가설을 세우고 검증했다. 이게 가능했던 이유는 (a) 참/거짓이 명확한 신호였고 (b) 200개 fit 데이터 + 라벨 10개뿐이어서 라벨당 데이터 커버리지가 충분했기 때문.
그러나 실제 프로덕션은 다르다
대부분의 실제 애플리케이션에는 이런 결정론적(deterministic) 예/아니오 타겟 함수가 없다. LLM-as-judge 방식도 비결정적이라, 같은 평가자로 같은 결과물을 여러 번 평가해도 다른 점수가 나올 수 있다. 그렇다면 "명확한 신호(high-signal feedback)"를 다른 도메인(수직 전문 에이전트, 의료기기 규제 요건 추출 자동화 등)에 어떻게 이식할 것인가?
저신호(low-signal) vs 고신호(high-signal) 평가자
- 저신호: "정확성(correctness)", "도움이 됨(helpfulness)", "환각(hallucination)" 같은 범용 평가자를, 0~1 또는 1~5 같은 스케일로 점수화하는 방식. 초기에는 유용했지만, 각 점수가 "정확히 무엇을 의미하는지"를 엄밀하게 정의해야 제대로 작동하는데 실무에서는 거의 그렇게 하지 않는다. 그 결과 문맥에 따라 관점이 흔들리고 실행마다 일관성이 떨어진다.
- 고신호: 도메인에 맞춰 "좋다(good)"의 기준을 예/아니오 질문으로 구체화한 것. 예:
- "답변이 지식베이스(retrieved context)에 근거하는가? — yes/no" (이전 단계에서 검색된 컨텍스트에 실제로 그 내용이 있는지 체크)
- "브랜드명이 정확히 표기됐는가? — yes/no" (실제 사례: 영어 회사명이 스페인어로 자동 번역되지 않았는지 체크)
- "이 답변이 알려진 5가지 실패 모드 중 어디에 해당하는가?" — 카테고리 분류형 체크
이런 고신호 평가자는 데이터를 직접 들여다보고, "좋다는 게 뭔지", 도메인 전문가에게 무엇이 중요한지를 이해해야 만들 수 있다. "코드 컴파일 여부" 같은 명확한 기준이 없는 도메인일수록 이 사고 전환이 필요하다.
데이터 볼륨
Langfuse 팀은 arXiv 논문이 워낙 많아 수천 개를 쓸 수도 있었지만, 200/100/300 분할만으로도 충분히 고신호 피드백을 얻었다. 애플리케이션 복잡도와 단계 수에 따라 필요 볼륨은 달라지지만, "볼륨 + 고신호 피드백"이 자기개선 루프의 기반이다.
고신호 피드백을 구축하는 방법 (실행 절차)
- 도메인 전문가와 함께 일하기 — "고객과 대화하라"는 뻔한 조언이지만, 여기서는 전문가의 지식을 구체적인 예시로 인코딩하는 데 쓴다. 전문가에게 "기대하는 출력이 무엇인지" 예시를 만들게 하고, 샘플 실행 결과를 함께 리뷰하며 "왜 이건 되고 저건 안 되는지"를 물어본다. 이 과정에서 전문가가 암묵적으로만 알고 있던 판단 기준이 드러나고, 실패 모드를 식별하고 "좋다"의 정의를 세울 수 있다.
- 이걸로 고신호 평가자를 만든다.
- 프로덕션에 배포된 뒤에는 사람이 직접 데이터를 리뷰한다 — 코딩 에이전트에게만 맡기지 말고 사람이 직접 훑어보며 애플리케이션의 초기 스코프가 무엇이었는지, 지금 무엇을 하고 있는지 이해한다. 스코프와 실패 모드는 시간이 지나며 바뀌고, 기능 확장의 여지도 생긴다. 고객이 실패를 발견하기 전에 먼저 잡아야 한다.
- 시스템 전체를 "일반화해야 하는 시스템"으로 사고한다 — 예시들이 프로덕션에서 마주칠 상황을 대표하도록 구성하고, 전통적 머신러닝처럼 train/validate/test 검증 메커니즘을 반드시 내장한다(overfitting 방지).
- 루프에 탈출구(escape hatch)를 준다 — 정지 조건 없이 몇 시간이고 벽에 부딪히며 토큰만 태우게 두지 말 것. 이것이 바로 이 발표 제목 "Stop Burning Tokens"의 요지다.
2계층 — 주요 개념 설명 및 사례
- 타겟 함수(Target Function): 에이전트가 도달하려는 목표를 수치·판정 가능한 형태로 정의한 것. 코딩에서는 "컴파일 성공/실패"가 자연스러운 타겟 함수. 다른 도메인에서는 이걸 스스로 설계해야 하며, 설계가 부실하면 자기개선 루프 자체가 방향을 잃는다.
- 자기개선 루프(Self-Improvement Loop): 베이스라인 실행 → 에러 분석 → 가설 기반 프롬프트(또는 시스템) 수정 → 검증셋 재확인 → 반복. 이 실험에서는 Claude Code(Opus 4.8)가 "최적화기" 역할을 하고, GPT-5-nano가 실제 태스크를 수행하는 "에이전트" 역할을 분리해서 맡았다.
- fit / validate / test 3분할: 전통적 ML 워크플로우를 그대로 프롬프트 최적화에 적용한 것. fit에서 에러를 찾고, validate에서 그 수정이 일반화되는지 확인 후에만 채택하고, test는 전체 과정이 끝날 때까지 완전히 격리해 최종 일반화 성능만 확인한다. 이렇게 해야 "우연히 fit 데이터에만 맞는 수정"을 걸러낼 수 있다.
- 에러 클러스터 분석: 개별 오답이 아니라 "어떤 라벨 쌍이 반복적으로 혼동되는가", "어떤 카테고리가 유독 실패율이 높은가"를 패턴 단위로 파악하는 것. 이 실험에서 Opus는 "64개 에러 중 지배적 패턴 X, 가장 혼동되는 라벨 쌍 Y"를 정량적으로 뽑아내고 그에 맞춘 가설을 세웠다.
- 1회차 급상승 현상: 68%→78%로 첫 반복에서 대부분의 개선폭(전체 개선의 약 2/3)이 나왔다는 관찰. 이는 "초기 프롬프트가 얼마나 미니멀했는가"에 크게 좌우되지만, 동시에 "고신호 피드백이 있으면 최적화기가 정말 빠르게 핵심 개선점을 찾아낸다"는 걸 보여주는 사례이기도 하다.
- LLM-as-judge의 비결정성: 같은 평가자 프롬프트로 같은 출력을 여러 번 채점해도 점수가 요동칠 수 있다는 문제. 이 때문에 "정확성 1~5점" 같은 저신호·모호한 평가 기준은 자기개선 루프의 신호로 쓰기에 부적합하다.
- 고신호 vs 저신호 평가자 구분: 핵심 차이는 "예/아니오로 명확히 답할 수 있는가"와 "그 판단 기준이 데이터·전문가 지식에 근거해 명시적으로 정의됐는가"다. "정확성이 있는가?"보다 "이 답변이 검색된 컨텍스트에 실제로 존재하는 사실을 담고 있는가?"가 훨씬 검증 가능하고 일관된 신호를 낸다.
- 브랜드 보이스 체크 사례: 영어 회사명이 답변 과정에서 실수로 스페인어 등으로 자동 번역돼버리는 실패 모드를 예로 들며, 이런 구체적이고 좁은 범위의 yes/no 체크가 "브랜드 보이스가 적절한가?" 같은 막연한 평가보다 훨씬 유용하다고 설명.
3계층 — 실행 포인트 및 시사점
- 자기개선 루프를 도입하기 전에, 먼저 "우리 도메인의 타겟 함수는 무엇인가"부터 정의하라. 코딩처럼 명확한 예/아니오 기준이 없다면, 그걸 만드는 작업 자체가 선행 과제다. 이 작업 없이 바로 루프/에이전트 자동화부터 붙이면 최적화 방향을 잃는다.
- 범용 평가자("정확성", "도움이 됨" 1~5점)에 의존하고 있다면 재점검하라. 각 점수가 무엇을 의미하는지 엄밀히 정의돼 있지 않다면, 그건 자기개선 루프의 신호로 쓰기엔 너무 약하고 실행마다 일관성이 없을 가능성이 높다.
- 데이터를 직접 보고 도메인 전문가와 함께 "좋다"의 기준을 예/아니오 질문 단위로 쪼개라. "검색된 컨텍스트에 근거하는가", "알려진 실패 모드 중 무엇에 해당하는가"처럼 구체적이고 검증 가능한 형태로.
- fit/validate/test 분할과 정지 조건(반복 횟수 상한, 목표 정확도)을 루프 설계 초기에 명시하라. 그렇지 않으면 개선 없이 토큰만 소모하며 무한 반복하는 리스크가 있다.
- 첫 반복에서 가장 큰 개선이 나올 가능성이 높다는 걸 인지하고, 초반 결과만 보고 "이 정도면 충분하다"고 판단할 타이밍을 미리 정해두라. 이 실험처럼 1회차에 개선의 대부분이 몰릴 수 있으므로, ROI 관점에서 "몇 회차까지만 돌리고 멈출지"를 사전에 결정하는 게 토큰 낭비를 막는다.
- 프로덕션 배포 후에도 사람이 직접 데이터를 리뷰하는 루틴을 유지하라. 코딩 에이전트에게 리뷰까지 위임하면 스코프 변화나 새로운 실패 모드를 놓칠 수 있다. 고객이 발견하기 전에 사람이 먼저 잡아야 한다.
- 작고 저렴한 모델(GPT-5-nano급)도 고신호 피드백만 있으면 상당한 자기개선이 가능하다. 반드시 프론티어 모델을 에이전트로 써야 자기개선이 되는 게 아니라, 최적화기(옵티마이저) 쪽에 더 강한 모델을 쓰고 실행 에이전트는 저렴하게 가져가는 구조도 비용 효율적 대안이 될 수 있다.
4계층 — 핵심 요약 (20줄)
- Langfuse의 Annabelle이 발표: "토큰 그만 태우고, 자기개선 루프에 도메인 전문성부터 넣어라."
- 2026년 6월 현재 업계는 "프롬프트 대신 루프를 설계하라"는 흐름(Boris, Peter Steinberger, Karpathy의 auto-improvement)이 확산 중.
- 코딩이 자기개선에 유독 잘 맞는 이유는 "컴파일 성공/실패"라는 명확한 타겟 함수가 있기 때문.
- 의료·헬스케어·챗봇 등 대부분 도메인은 타겟 함수가 불명확하고 항상 불완전하다.
- 타겟 함수와 좋은 평가자에 투자한 팀만이 지속적으로 개선하고 자신 있게 배포한다.
- 실험: 가장 명확한 타겟 함수인 "arXiv 논문 라벨 분류"(단일 라벨, 정답 有)로 자기개선 루프를 테스트.
- 구조: GPT-5-nano(실행 에이전트) + Claude Code/Opus 4.8(최적화기), fit 200/validate 100/test 300 분할.
- 절차: 베이스라인 측정 → fit셋 에러 클러스터 분석 → 최대 에러 카테고리에 프롬프트 수정 제안 → validate셋에서 개선 확인 시만 채택 → 15회 또는 92% 도달 시 종료 → test셋 최종 검증.
- 결과: 68%(1회차) → 83%(3~4회차 피크) → 약 80%대 정체, test셋 80.2%로 잘 일반화됨.
- 가장 큰 개선은 1회차 한 번에 발생(68→78%) — 이후 반복은 미세 조정 수준.
- Opus가 실제로 추가한 건 라벨 설명이 아니라 "분류 접근법 가이드 + 유사 클래스 구분 규칙 + 혼동 사례 예시".
- Opus의 추론 과정은 "64개 에러 중 지배 패턴/최다 혼동 라벨 쌍 파악 → 가설 수립 → 해당 패턴 정조준 수정"으로 매우 정량적이었다.
- 100% 미도달 원인은 원저자의 라벨링 시 "창의적 재량"이 있어 원천적으로 상한선이 존재했기 때문.
- 현실 문제: 대부분 애플리케이션엔 이런 결정론적 예/아니오 타겟이 없고, LLM-as-judge는 비결정적이라 같은 걸 채점해도 점수가 흔들린다.
- 저신호 평가자: "정확성/도움이 됨" 같은 1~5점 채점은 점수 정의가 부실하면 일관성 없는 약한 신호에 불과하다.
- 고신호 평가자: "답변이 검색된 컨텍스트에 근거하는가", "브랜드명이 정확한가(예: 스페인어로 오역 안 됐는가)", "알려진 실패 모드 중 무엇인가" 같은 예/아니오 형태.
- 고신호 평가자는 데이터를 직접 보고 도메인 전문가와 함께 "좋다"의 기준을 구체화해야 나온다.
- 실행 절차: (1) 전문가와 협업해 기대 출력 예시·실패 모드 도출 → (2) 고신호 평가자 구축 → (3) 프로덕션 데이터를 사람이 직접 리뷰 → (4) train/validate/test 검증 메커니즘 내장 → (5) 루프에 정지 조건(탈출구) 부여.
- 데이터 볼륨은 fit 200/validate 100/test 300 정도로도 충분한 고신호 피드백을 얻을 수 있었다(복잡도에 따라 조정 필요).
- 결론: 목표는 사람과 에이전트가 함께 개선해가는 시스템이지, 정지 조건 없이 몇 시간이고 토큰만 태우는 루프가 아니다.
원문 소스
- yt-dlp 자동 자막(영어) 기반 전문 번역/정리. 원본 한국어 자막 없음(한국어 자막 다운로드 시 429 Rate Limit으로 실패, 영어 자막으로 대체).