IndieBiz 유튜브 AI 팁 보고서 · 최근 6개월 이내의 AI 활용법 영상을 매일 자막으로 읽고 실행 가능한 팁만 증류합니다 · 팁은 자막 기반이며 직접 검증 전입니다
유튜브 AI 팁 보고서 — 2026-08-18 — 평가
오늘의 영상 4편 (전부 최근 6개월 이내) · 누적: 팁 173개 / 다룬 영상 39편 (원장 등재 131편)
어제 호가 "내일 주제 후보 1순위"로 지목한 축입니다. 어제는 에이전트를 어떻게 만드는가를 봤고, 오늘은 만든 것이 실제로 작동하는지 어떻게 아는가를 봅니다.
한눈에 (TL;DR)
- 평가는 과제 세트만이 아니다. 하네스와 실행 인프라가 점수를 같이 움직인다 — 어떤 벤치마크에서는 타임아웃만 늘렸더니 점수가 14~15%p 올랐다. 모델 두 세대에 해당하는 도약이 설정값에서 나왔다.
- 트리거되면 안 되는 프롬프트를 테스트에 넣어라. 오늘 서로 다른 두 영상이 각자 독립적으로 같은 말을 했다. 이게 없으면 "항상 검색하는" 치팅 에이전트를 못 잡는다.
- 고칠 순서가 있다: 데이터 > 프롬프트 > 모델 교체 > 하이퍼파라미터. 엉뚱한 소스를 뒤지고 있으면 프롬프트를 아무리 만져도 안 된다.
- 점수를 매기게 하지 말고 둘을 비교시켜라. LLM은 1~10점 매기기는 못하지만 A와 B 중 어느 쪽이 나은지는 잘 고른다.
오늘의 팁
1. 평가는 과제 세트가 아니라 세 부분이다 — 과제·하네스·인프라를 같이 적어라
- 방법: 평가를 설계할 때 세 가지를 한 벌로 기록한다. ①과제 세트(데이터 + 채점 함수) ②하네스 — LLM을 굴리는 거대한 while 루프와 그 안에 딸린 기본 도구들(Claude Code·Codex 같은 것, 또는 pi·opencode 같은 오픈소스) ③실행 인프라(도커·샌드박스·하드웨어). 대부분 ①만 생각하는데, 화자에 따르면 같은 모델을 Bedrock으로 부르느냐 1차 API로 부르느냐만으로도 결과가 갈린다. 하네스를 바꾸는 것만으로 성능이 오르고 비용이 내려가는 경우가 흔하다 — 최소한의 시스템 프롬프트와 소수의 도구만 있는 하네스가 사용자 대면 군더더기가 많은 것보다 싸다.
- 출처: How To Turn Evals Into A Better Model — Hamel Husain (게스트: Prime Intellect의 Will Brown·Florian) · [01:00~07:30]
- 보정: 게스트 두 명이 RL 인프라 회사 소속이라 자사 도구(prime-rl·verifiers)와 특정 오픈소스 하네스를 권하는 대목이 있다. 다만 "세 부분" 프레이밍 자체는 도구 중립적이다.
2. 점수가 안 오르면 모델이 아니라 타임아웃을 의심하라
- 방법: 평가는 처음엔 시간·토큰·자원을 최대로 열어 두고 돌린 뒤 조이는 순서로 간다. Terminal-Bench 2에서 과제 타임아웃만 늘렸더니 점수가 14~15%p 올랐다 — 화자 표현으로 "모델 두 세대에 해당하는" 도약이다. 즉 더 좋은 프로세서·빠른 램에서 돌리면 같은 모델이 더 높은 점수를 받는다. 인프라 문제는 디버깅이 특히 고약하고 사람들이 기록에 남기지도 않는다.
- 출처: How To Turn Evals Into A Better Model — Hamel Husain · [07:42~08:25]
3. AI가 짜준 평가 코드부터 의심하라 — temperature 0·잘림·자원 부족
- 방법: 모델에게 평가 보일러플레이트를 시키면 temperature를 0으로 박아 놓는 일이 잦다(옛 논문들이 그렇게 고정했기 때문). 실무에선 그러면 안 된다. 오픈소스 모델은 허깅페이스의
generation_config 파일에서 제작자가 쓴 값을 확인하고, 못 찾으면 0보다 1이 낫다 — 특히 추론 모델은 예전보다 훨씬 많은 토큰을 뱉는다. 두 번째로 흔한 버그는 max_tokens·max_turns가 낮게 박혀 응답이 조용히 잘리는 것이다.
- 출처: How To Turn Evals Into A Better Model — Hamel Husain · [09:45~11:05, 12:31~13:23]
- 보정: 오늘 팁 11(임팩트 계층)과 정면으로 충돌하는 것처럼 보인다 — 저쪽은 온도·top_p를 맨 아래로 둔다. 실제로는 층위가 다르다. 팁 11은 "에이전트 품질을 올리려면 어디를 만질까"이고, 이건 "측정 장치가 고장 나 있지 않은가"다. 온도 0으로 잰 점수는 낮은 게 아니라 틀린 것이다.
4. 보상 함수 설계를 코딩 에이전트에게 시키지 마라 — 대신 적대적 예시를 찾게 하라
- 방법: 에이전트에게 채점 함수를 맡기면 if문 더미와 정규식을 뱉는데, 화자 표현으로 그건 전부 "해킹 구멍"이다. 반대로 아주 잘하는 일이 있다 — "이 평가에서 높은 점수를 받으면서 과제의 취지는 어기는 입력을 찾아 봐." 채점 기준·데이터·프롬프트는 사람이 잡고, 도커 이미지·백엔드·도구 시뮬레이터·배관은 에이전트에게 넘긴다. 채점 기준을 쓸 때는 "이거 좋아?"가 아니라 예/아니오로 답할 수 있는 속성 질문으로 쪼갠다.
- 보상 해킹의 교과서적 예: "좋은 글"을 사람이 매긴 데이터에서 자주 쓰인 단어로 채점하게 하면, 그 지표는 모델 A와 B를 구별하는 데는 쓸 만해도 학습에 쓰면 모델이 그 단어만 말하는 법을 배운다.
- 채점 기준이 영리해질수록 대개 뭔가 잘못된 것이다. "정답이 어떤 모습인지 한 문장으로 말할 수 있는가"가 첫 시험이다.
- 출처: How To Turn Evals Into A Better Model — Hamel Husain · [23:14~24:00, 27:24~32:40]
5. 평가를 네 계층으로 나누고 바깥에서 안으로 들어가라
- 방법: ①컴포넌트(도구·함수 — 결정론적이니 평범한 유닛테스트로 충분하다. JSON 파서는 파싱하거나 못 하거나 둘 중 하나다) ②궤적(맞는 도구를 맞는 인자로 골랐나, 추론 사슬이 말이 되나 — 3번이면 될 걸 25번 호출하면 궤적 문제이고, 엉뚱한 도구를 불렀는데 우연히 정답이 나온 것도 궤적 문제다) ③결과(정확·유용·근거 있음·완결 — 주관적이라 단정문으로 못 쓰니 LLM 판사) ④시스템 모니터링(개별 실패가 아니라 실사용 전체의 패턴).
- 순서는 바깥에서 안으로: 결과부터 보고, 실패하면 상자를 연다. 다만 통과해도 궤적은 계속 본다 — 25단계로 맞히는 에이전트는 효율과 신뢰성 문제를 그냥 안고 있는 것이다.
- 품질의 네 축도 같이: 효과(원하는 걸 해냈나) 효율(호출 수·시간·토큰 비용) 견고성(깨진 입력·API 실패·모호한 지시·엣지 케이스) 안전(거절해야 할 때 거절하나).
- 출처: AI Agent Evals: The 4 Layers Most Teams Skip — Damian Galarza · [02:26~05:20]
- 보정: 8분짜리 개념 정리 영상이라 코드가 없다. 마지막에 "4계층 스코어카드" 자료 다운로드 유도가 붙는다.
6. 품질은 나중에 측정할 수 없다 — 트레이스를 만들 때 같이 넣어라
- 방법: 구조화된 트레이스를 안 뱉으면 궤적을 평가할 수 없고, 도구 호출을 인자까지 로깅하지 않으면 효율을 못 재고, 중간 추론을 노출하지 않으면 실패를 진단할 수 없다. "만들고 → 출시하고 → 이제 이걸 어떻게 테스트하지"는 순서가 틀렸다. 관측 가능성은 보안처럼 1일차 아키텍처 결정이다.
- 트레이스의 구성 요소는 span이다 — LLM 호출 하나가 span, 도구 호출 하나가 span, 에이전트 턴 전체가 그것들을 품은 span. 중첩 JSON이라 보면 된다. 각 span은 입출력뿐 아니라 시간·토큰 수 같은 메타데이터를 갖는다.
- 출처: AI Agent Evals: The 4 Layers Most Teams Skip — Damian Galarza · [05:44~06:20] · Ship Real Agents — Laurie Voss · [05:30~06:40]
7. 프로덕션 실패 하나를 회귀 테스트 하나로 승격하라
- 방법: 실패를 발견하면 주석을 달아 평가 케이스로 등록한다. 평가셋이 커지고 → 에이전트가 좋아지고 → 새 엣지 케이스가 드러나고 → 반복. 이렇게 자란 평가셋은 "내 에이전트가 실제로 무엇에 걸려 넘어졌는가"의 가장 정확한 기록이 된다. 품질은 한 번에 만드는 게 아니라 복리로 쌓인다.
- 자동 평가가 다 잡아 주지도 않는다. 프로덕션 트레이스를 직접 읽는 습관이 어떤 루브릭도 예상 못 한 미묘한 실패를 드러낸다.
- 출처: AI Agent Evals: The 4 Layers Most Teams Skip — Damian Galarza · [06:25~07:10]
8. 트리거되면 안 되는 프롬프트를 테스트에 넣어라 (음성 대조)
- 방법: 스킬·도구 테스트에 네 종류를 섞는다. ①명시 호출("model-trainer로 텍스트 분류 모델을 파인튜닝해 줘") ②암시 호출("허깅페이스 잡에서 감성분석 모델을 학습시키고 싶어") ③모호한 요청("모델 학습 좀 도와줘" — 걸리되 되물어야 한다) ④걸리면 안 되는 프롬프트("모델 학습이 뭔지 설명해 줘" — 워크플로가 시작되면 안 된다).
- 같은 원리가 평가셋에도 적용된다. "웹 검색을 했는가"만 재면 항상 검색하는 치팅 에이전트가 만점을 받는다. 검색이 필요 없는 케이스를 넣고 "안 했는가"를 재야 한다.
- 오작동했을 때 고칠 곳은 스킬 본문이 아니라 description이다 — 그게 에이전트가 보고 쓸지 말지 결정하는 부분이다.
- 출처: How to Evaluate and Test Agent Skills — Alejandro AO · [08:07~09:12] · Ship Real Agents — Laurie Voss · [01:21:00~01:21:20]
- 보정: 오늘 유일하게 서로 모르는 두 화자가 독립적으로 같은 말을 한 항목이다. 한쪽은 스킬 트리거, 한쪽은 에이전트 행동 평가라는 다른 맥락에서 같은 결론에 도달했다.
9. 스킬은 평문으로 쓴 소프트웨어다 — 깃에 넣고 버전 관리하라
- 방법: 스킬은 로직을 담고 API를 부르고 다른 스킬을 부르고 서브에이전트를 띄운다. 영어로 썼을 뿐 소프트웨어다. 깃 저장소에 넣어야 평가 점수의 변화를 어떤 수정 때문인지에 대응시킬 수 있다. 성공 기준도 미리 네 축으로 적어 둔다 — 결과(원하는 산출이 나왔나) 과정(의도한 도구를 의도한 순서로 썼나) 형식(파일명·디렉토리가 규약대로인가) 효율(불필요한 명령이나 삽질이 없었나).
- 좋은 스킬은 문서형(도구 사용법)과 워크플로형(단계 정의) 양쪽을 다 가진 것이다. 화자는 문서형만 있는 스킬은 "기존 문서를 에이전트용으로 다시 쓴 것뿐"이라는 비판에 동의한다.
- 출처: How to Evaluate and Test Agent Skills — Alejandro AO · [02:11~03:35, 05:15~08:01]
- 보정: OpenAI가 낸 스킬 작성·진화 가이드 문서를 따라가며 해설하는 구성이다. 원문 자체를 읽는 게 더 빠를 수 있다(영상 설명란 링크).
10. 스킬이 "작동한다"는 착시를 조심하라 — 모델이 버그를 덮는다
- 방법: 일반 소프트웨어와 달리 스킬은 처음부터 대체로 작동한다. 모델이 똑똑해서 엉망인 지시도 어떻게든 굴러가게 만들기 때문이다. 그래서 "되네"는 신호가 아니다. 되는지가 아니라 어떻게 됐는지(몇 번 만에·어떤 경로로·군더더기 없이)를 봐야 한다. 화자의 마무리: "스킬을 감(vibe)으로 평가하지 마라."
- 실무 절차: 높은 값어치의 체크부터(돌긴 도나, 결과가 맞나) → 실패가 나타날 때마다 케이스 추가 → 정량 효율 체크로 진화. 테스트 표는 4열이면 된다 —
id / should_trigger / prompt / expected_outcome.
- 서브에이전트를 띄워 스킬을 넣은 판과 뺀 판을 나란히 돌려 보면 스킬이 실제로 도움이 되는지가 드러난다.
- 출처: How to Evaluate and Test Agent Skills — Alejandro AO · [09:43~12:24, 14:26~15:04]
11. 고칠 순서가 있다 — 데이터 품질 > 프롬프트 > 모델 교체 > 하이퍼파라미터
- 방법: ①데이터 품질이 압도적 1위다. 엉뚱한 소스를 뒤지고 있거나 지식 베이스가 낡았으면 프롬프트를 아무리 만져도 안 된다. ②프롬프트(few-shot 예시·명시적 지시·해야 할 것과 하지 말 것의 제약)가 대개 투자 대비 효과가 가장 크다. ③모델 교체는 세 번째 — 더 센 모델이 프롬프트로 안 되는 걸 풀기도 하지만 비용이 붙는다. ④하이퍼파라미터(온도·top_p)는 맨 아래로, 평가 결과를 유의미하게 바꾸는 일이 드물다.
- 출처: Ship Real Agents: Hands-On Evals for Agentic Applications — Laurie Voss (Arize), AI Engineer · [01:42:13~01:43:05]
- 보정: 화자가 관측 플랫폼(Arize Phoenix) 소속이라 실습 전체가 자사 오픈소스 도구로 진행된다. 다만 위 계층 자체는 도구와 무관하다. 팁 3과의 관계는 팁 3의 보정 참조.
12. 1~10점을 매기게 하지 말고 둘 중 어느 쪽이 나은지 물어라 (페어와이즈)
- 방법: LLM은 절대 점수를 매기는 건 잘 못하지만 두 출력을 놓고 비교하는 건 훨씬 잘한다. 구체적인 비교 대상이 두 개 있기 때문이다. 프롬프트 버전 A/B 비교나 모델 업그레이드 판단에 특히 잘 맞는다.
- 관련해서 판정에는 점수보다 설명이 중요하다. "도쿄 저예산 여행"을 물었는데 추천은 줬지만 가격을 안 적었다 → 실패. 이 설명이 있어야 프롬프트의 어디를 고칠지 알 수 있다. 수천 개 트레이스에 평가를 돌리면 같은 종류의 실패가 반복되는 게 보이고, 그게 일회성 흔들림과 구조적 실패를 가른다.
- 설명이 1,000개가 되면 사람이 못 읽는다 → 세 번째 LLM에게 설명들을 범주로 묶게 한다.
- 출처: Ship Real Agents — Laurie Voss · [01:48:11~01:48:45, 19:30~21:28]
13. pass@k와 pass^k를 구별하라 — 용도가 다르다
- 방법: pass@k = k번 중 한 번이라도 성공하나. pass^k = k번 모두 성공하나. k가 커지면 둘은 정반대로 벌어진다(하나는 100%로, 하나는 0으로). 계속 다시 시켜도 되는 코딩 보조는 pass@k로 충분하지만, 다섯 번에 한 번 틀리는 고객 응대 봇은 고객 입장에서 실패다 — 그건 pass^k로 재야 한다.
- 함께: 평가마다 출하 차단(ship blocker)인지 참고용인지를 정해 둔다. 전부 통과해야 나가는 게 아니다.
- 출처: Ship Real Agents — Laurie Voss · [01:48:45~01:49:40, 01:17:00~01:17:28]
14. 판사를 평가하라 (메타평가) — 나 자신에게도 같은 루브릭을 적용해서
- 방법: LLM 판사는 분류기다. 사람 판정을 정답지(골든셋)로 놓고 예측을 대조하면 성능을 잴 수 있다. 단, 사람이 "음 좋은데"로 판정하면 LLM과 똑같이 자의적이 되므로 — LLM에게 준 그 루브릭을 사람도 읽고 판정한다. 스스로에게 예시를 주고, 모호함을 없애고, 게을러질 여지를 없앤다.
- 골든셋은 75:25로 나눈다. 평가가 골든셋에 과적합될 수 있다(그 예시들만 통과하고 일반화는 안 된 상태).
- 어떤 과제에서 계속 0%가 나오면 대개 에이전트가 나쁜 게 아니라 사람만 할 수 있는 과제를 낸 것이다. 과제마다 "정답은 이런 모습"이라는 기준 해답을 미리 정해 둔다.
- 골든셋은 테스트 데이터가 아니라 그 도메인을 가장 잘 아는 사람들의 판단을 코드화한 것이다. 그래서 비기술 이해관계자(기획·고객 지원·영업)가 평가 과제를 쓰는 게 맞다.
- 출처: Ship Real Agents — Laurie Voss · [01:17:28~01:22:00, 01:43:40~01:44:20]
15. 표본 수 기준: 방향만 보려면 12~20개, 출하 판단은 200~400개
- 방법: 신뢰구간을 절반으로 줄이려면 표본을 두 배로 늘려야 하고, 그건 골든셋 제작 노력도 두 배라는 뜻이다. 정확도를 2%p 더 올리는 데 그만한 비용을 쓸지 먼저 정한다.
- 참고로 사람 어노테이터도 절반쯤 틀린다 — 종일 남의 코드만 검수시키면 피로 때문에 놓친다는 것이 화자의 관찰이다. 그래서 코드 평가·사람 평가·LLM 판사는 경쟁 관계가 아니라 셋을 같이 쓰는 것이다.
- 비용까지 넣어 보려면 비용 정규화 정확도(정확도 ÷ 비용)라는 개념이 있다. 쿼리당 2센트에 92%가 15센트에 95%보다 나을 수 있다.
- 출처: Ship Real Agents — Laurie Voss · [01:41:33~01:42:13, 13:41~14:10, 01:47:30~01:48:11]
시도 후보
- 팁 8(음성 대조) — 이미 대조 시드라는 이름으로 하고 있는 걸 액션 트리거 쪽으로 넓히는 것이라 이식 거리가 가장 짧습니다.
- 팁 11(임팩트 계층) — 다음에 "AI가 이상하게 답한다"는 문제를 만났을 때 프롬프트부터 만지는 대신 데이터(가이드·코퍼스)부터 보는 순서로 한 번 해볼 만합니다.
- 팁 2(자원부터 열고 조이기) — 평가 루프가 NOT_ACHIEVED를 낼 때 라운드 상한 때문인지 확인하는 것 정도는 가볍습니다.
오늘의 영상
지켜볼 점 / 내일 주제 후보
- 내일 주제 후보 1 — 학습. 사흘째 같은 자리에 적히고 있습니다. 오늘까지 여드레 연속 "만들고 재는" 계열이었습니다.
-
내일 주제 후보 2 — 신도구. 오늘 검색에서 평가·관측 도구 이름이 계속 스쳐 지나갔고(Phoenix, prime-rl, verifiers, lm-eval-harness), 8월 초에 올라온 신선한 영상들이 미선정 더미에 남아 있습니다.
-
오늘의 관찰 1 — 조회수가 처음으로 정반대 신호를 줬다. 오늘 최고 수확(팁 4개)은 조회 18회, 게시 하루 된 영상이었고, 검색 1~2위였던 4.6만·8.7만 조회 영상은 둘 다 작년 것이라 컷오프에서 잘렸습니다. 어제 "에이전트 주제는 신선한 것과 좋은 것이 같은 쪽에 있다"고 적었는데, 평가 주제는 한 발 더 나갔습니다 — 조회수가 아직 붙을 시간이 없었던 영상이 가장 좋았습니다. 신호를 조회수가 아니라 화자의 신원에서 읽어야 하는 주제군이 있다는 뜻이고, 이건 "조회수가 낮아 미선정"이라는 우리 관행에 대한 반례입니다.
- 오늘의 관찰 2 — 한국어권에 이 주제가 거의 없다. 한국어 쿼리 세 개 중 하나("AI 서비스 품질 테스트 평가셋 만들기")는 면접 준비 영상을 돌려줬고, 나머지 두 개는 영어 영상에 한국어 자동번역 제목이 붙은 것들이었습니다. 지금까지 아홉 개 주제 중 한국어 원본이 사실상 0인 첫 주제입니다. 프롬프트·이미지·영상 주제에서는 한국어 채널이 풍성했던 것과 대조됩니다 — "쓰는 법"은 한국어로 활발하고 "재는 법"은 아직 영어권에만 있습니다.
- 오늘의 관찰 3 — 두 영상이 서로 모른 채 같은 결론에 닿았다. 팁 8(트리거되면 안 되는 케이스를 테스트에 넣어라)은 스킬 트리거를 다루는 15분 영상과 에이전트 행동 평가를 다루는 2시간 세션이 각자 독립적으로 도달한 항목입니다. 지금까지 이 보고서에서 교차 확인은 "같은 도구를 여러 채널이 소개한다" 수준이었는데, 이번엔 다른 맥락에서 같은 원리가 나왔습니다. 증류의 신뢰도라는 면에서 오늘 가장 단단한 항목입니다.
- 오늘의 관찰 4 — 자막의 한계가 이번엔 고유명사에서 드러났다. 네 편 모두 영어 자동 자막이고, 도구·개념 이름이 뭉개진 것을 문맥으로 복원했습니다("hugging phase"=Hugging Face, "openthropic"=OpenAI/Anthropic, "Jeepa"=GEPA, "PO"=PPO, "winters"=linters, "prime L"=prime-rl). 복원 확신이 낮은 이름은 이 호에 싣지 않았습니다. 또 2시간 세션은 화면의 코드가 본체인 구간이 길어 말로 설명되지 않은 실습 코드는 담기지 않았습니다 — 실제로 따라 하려면 영상의 노트북을 직접 여는 편이 맞습니다.