요즘 에이전트(agent)에 대해 사람들이 자주 언급하는 다섯 가지 단어가 있습니다. 컨텍스트 엔지니어링, 루프 엔지니어링, Jev 엔지니어링, 하네스 엔지니어링, 에발(evals) 엔지니어링입니다.
마치 서로 경쟁하는 다섯 가지 접근법처럼 들리지만, 그렇지 않습니다. 이들은 하나의 시스템을 이루는 다섯 개의 레이어이며, 각각이 하나의 질문에 답합니다.
이를 가장 쉽게 이해하는 방법은 방금 새 직원을 채용했다고 상상해 보는 것입니다.
- 컨텍스트(Context) - 직원에게 무언가를 물어볼 때 그의 책상 위에 놓여 있는 것
- 루프(Loop) - 직원이 당신이 준 체크리스트를 따르는지, 아니면 스스로 다음 단계를 찾아내는지
- Jev - 우편물을 분류하는 안내 데스크. 덕분에 직원은 중요한 것만 볼 수 있음
- 하네스(Harness) - 직원의 사무실. 그가 쓰는 도구, 열쇠, 그리고 그의 업무를 검수하는 사람
- 에발(Evals) - 매달 치르는 동일한 시험. 직원이 실제로 성장했는지 확인하기 위함
AI 에이전트가 바로 그 직원입니다. 모델은 '사람'이고, 이 다섯 레이어는 그 사람을 둘러싼 모든 환경입니다. 이 다섯 레이어만 제대로 세팅하면 소규모 팀도 예전이라면 사람을 더 뽑아야만 했던 일들을 해낼 수 있습니다. 반복 업무는 프로덕션 환경에서도 버텨주는 에이전트에게 맡기고, 사람은 의사결정에만 집중하게 됩니다. 인력을 늘리지 않고 스케일업한다는 것이 실무에서 어떤 모습인지 보여주는 사례죠.
각 레이어별로 그것이 무엇인지, 어떻게 작동하는지, 어디에 쓰이는지, 그리고 어떻게 구축하는지 하나씩 짚어보겠습니다.
또한 각 레이어마다 지름길도 준비했습니다. 처음부터 직접 만들 필요 없이 같은 결과를 얻는 더 간단한 방법으로, 초보자용으로 만들어졌습니다. 이 지름길을 정리하는 데 Viktor 팀 친구들이 도움을 주었습니다.
Viktor 는 여러분의 Slack 이나 Microsoft Teams 안에서 함께 일하는 AI 직원입니다. 다른 팀원들과 같은 채널에 머물며 동료처럼 일하는데, 새로운 채용 공고를 내지 않고도 팀에 합류시킬 수 있는 멤버입니다.
그와 일하는 방식은 실제 사람과 일하는 것과 비슷합니다.
- 채널이나 스레드에서 그를 멘션하고 작업을 설명합니다.
- 그는 단계를 파악하고 여러 도구를 넘나들며 일을 처리한 뒤, 같은 스레드에 결과를 올려줍니다.
설정도 간단합니다. 워크스페이스에 Viktor 를 추가하기만 하면, 팀의 다른 멤버와 똑같이 참여자로 표시됩니다. 글을 읽으면서 직접 써보고 싶다면 YARCHI100 코드를 사용하세요.
pic1. 에이전트의 다섯 레이어
1. 컨텍스트 엔지니어링
정의
질문을 던지기 전, 당신은 직원의 책상에 서류를 올려놓습니다. 딱 필요한 세 장만 올려두면 그는 몇 초 만에 대답합니다. 300 장을 쌓아두면 정답은 종이 더미 한가운데 묻혀버리고, 결국 찾지 못합니다.
모델이 그 직원입니다. 책상은 컨텍스트 윈도우, 즉 모델이 답변하기 전에 보는 모든 정보입니다. 당신의 지시사항, 지금까지의 대화 기록, 데이터베이스에서 가져온 문서, 실행한 모든 도구의 출력값이 여기에 해당합니다.
컨텍스트 엔지니어링이란 책상 위에 무엇을, 어디에 배치할지 결정하는 작업입니다.
작동 방식
컨텍스트가 많다고 해서 답변이 좋아지지는 않습니다. 일정 수준을 넘어가면 오히려 나빠집니다.
Stanford 가 이를 직접 테스트했습니다. 모델에 20~30 개의 문서를 제공하면 중간에 위치한 문서에 대한 정확도가 약 50~57% 로 떨어집니다. 문서를 아예 주지 않았을 때 같은 모델의 점수는 56% 였습니다. 정답이 윈도우 안에 있었는데도, 아무것도 없을 때보다 성능이 떨어진 것입니다.
여기에는 두 가지 이유가 있습니다.
- 모델은 윈도우의 시작과 끝부분에 가장 많은 주의를 기울이고, 중간 부분은 가장 적게 봅니다.
- 도움이 되든 안 되든 모든 토큰은 비용과 시간을 소모합니다.
꼭 알아둬야 할 메커니즘은 프롬프트 캐싱입니다. 제공사가 프롬프트의 앞부분을 저장해 두고 다음 호출 시 재사용하는 방식으로, 캐시된 토큰은 새로 생성하는 토큰보다 비용이 약 10 배 저렴합니다.
단점이 있습니다. 캐시는 앞부분이 바이트 단위까지 완전히 동일해야만 작동합니다. 상단 근처의 글자 하나만 바꿔도 그 이후 내용은 전부 정가로 청구됩니다. 따라서 순서는 항상 변하지 않는 내용을 먼저, 바뀌는 내용을 마지막에 배치해야 합니다.
구축 방법
모든 컨텍스트는 다음 네 곳 중 하나로 들어갑니다.
- 시스템 프롬프트. 모든 호출에서 공통으로 적용되는 내용만 넣습니다. 역할, 제약 조건, 출력 형식 등입니다. 바이트 단위까지 동일하게 유지하세요. 상단에 타임스탬프를 넣거나 JSON 키 순서가 제멋대로인 일은 없어야 합니다.
- 도구(Tools). 대화 중간에 도구를 추가하거나 제거하지 마세요. 캐시가 깨지고, 모델은 이미 사라진 도구를 호출하려 듭니다. 특정 단계에서 도구 사용을 막고 싶다면 호출만 차단하고 정의 자체는 남겨두세요.
- 디스크. 용량이 크거나 오래 유지되는 정보는 파일로 빼고, 윈도우에는 경로만 남깁니다. 웹 페이지도 마찬가지입니다. URL 은 남기고 본문은 버리세요. 콘텐츠는 빼고, 다시 불러올 수 있는 키(key) 만 유지하세요.
- 꼬리(Tail). 몇 단계마다 컨텍스트 끝부분에 현재 목표를 다시 명시하세요. 중간 부분은 손댈 수 없으므로, 중요한 내용이 거기에 묻히지 않게 하는 겁니다.
도구에도 한계가 있습니다. Anthropic 의 측정 결과, 사용자가 한 마디도 입력하기 전에 58 개의 도구 정의가 약 55,000 토큰을 잡아먹었습니다. 모든 도구를 로드하는 대신 모델이 필요한 도구를 검색하게 했더니, 벤치마크에서 Opus 4 의 점수가 49% 에서 74% 로 올랐습니다.
도구가 20 개 미만이면 그대로 로드해 두세요. 그 이상이면 검색 방식으로 전환하세요.
대규모 작업에 쓸 수 있는 팁이 하나 더 있습니다. 서브 에이전트를 보내는 것입니다. 서브 에이전트는 자기만의 윈도우에서 50 개 파일을 읽고 한 페이지짜리 요약본을 건넵니다. 메인 컨텍스트는 오직 그 요약본만 보게 됩니다.
pic2. 한 번의 모델 호출에 들어가는 것들
지름길
Viktor 는 컨텍스트가 회사 단위로 관리되기 때문에 이런 작업 대부분을 대신 처리해 줍니다.
- 메모리. 팀 전체에 걸쳐 비즈니스 정보를 지속적으로 기억합니다. 지난주 공동 창업자에게서 배운 내용을 오늘 요청할 때마다 다시 붙여넣을 필요가 없습니다.
- 연결된 소스. Notion, Google Drive, HubSpot 등을 연동해 두면 채팅창에 파일을 붙여넣을 일이 사라집니다. 문서 이름이나 레코드를 말해주면 그가 직접 소스를 읽어옵니다. 앞서 말한 디스크 규칙을 자동으로 해주는 셈입니다.
- 스킬(Skills). 작업하는 화면을 한 번 녹화하면, 그가 이를 문서화된 절차로 변환해 줍니다. 당신이 수정하고 승인하면 끝입니다. 그 후로는 훌륭한 시스템 프롬프트처럼 고정되고 검증된 지침으로 작동합니다.
당신이 해야 할 일은 다음과 같습니다.
- 회사 소개서를 한 번 작성하세요. 무엇을 파는지, 누가 사는지, 어떤 지표가 중요한지, 절대 하지 말아야 할 것은 무엇인지요.
- 스레드 하나당 작업 하나만 넣고, 첫 메시지에 '완료'의 기준을 명시하세요.
- 그가 잘못된 것을 학습했다면, 매 스레드마다 고쳐주기보다 설정에서 메모리를 초기화하세요.
2. 루프 엔지니어링
정의
직원에게 체크리스트를 줄 수 있습니다. "파일을 열고, 12 번째 줄을 수정하고, 저장해." 또는 목표를 줄 수도 있습니다. "테스트를 통과시켜."
목표를 받으면 그는 무언가를 시도하고, 결과를 확인한 뒤, 다음 행동을 결정합니다. 체크리스트는 워크플로이고, 목표는 루프입니다.
작동 방식
루프는 생각(think), 행동(act), 관찰(observe), 결정(decide) 이 네 가지 동작의 반복입니다. 버그 수정 과정은 다음과 같이 흘러갑니다.
- 테스트를 실행한다. 3 개가 실패한다.
- 첫 번째 오류를 읽는다. import 가 누락되었다.
- import 를 추가하고 다시 실행한다.
- 여전히 테스트 하나가 실패한다. 해당 오류를 읽고 수정한 뒤 다시 실행한다.
- 모두 통과한다. 멈춘다.
이 단계들을 누군가 미리 작성해 둔 것이 아닙니다. 모델이 이전 결과를 보고 나서 하나씩 선택한 것입니다.
이것이 핵심 차이입니다. 당신이 직접 작성한 100 단계는 여전히 워크플로입니다. 반면 모델이 선택한 3 단계는 루프입니다.
단계들을 미리 작성할 수 없을 때만 루프를 사용하세요. 작성할 수 있다면 작성하세요. 워크플로는 비용이 적게 들고 병렬 처리가 가능하며, 4 번째 단계에서 실패해도 처음부터가 아니라 4 번째 단계만 다시 실행하면 됩니다.
루프는 비용도 많이 듭니다. 에이전트는 단일 호출 대비 대략 4 배의 토큰을 사용합니다. 멀티 에이전트 구성에서는 약 15 배까지 늘어납니다.
구축 방법
루프에는 네 가지 요소가 필요합니다. 하나라도 빠지면 작동하지 않습니다.
- '완료' 기준이 명확한 목표. "버그 수정"이 아닙니다. "auth_test.py 에서 실패하던 테스트가 통과하고, 다른 부분은 망가지지 않은 상태"처럼 구체적이어야 합니다.
- 검사기(Checker). 모델 외부에서 합격/불합격을 판정하는 존재입니다. 테스트 스위트, 컴파일러, 린터 등이 있죠. 자가 교정(self-correction) 관련 연구 결과는 여기서 일관됩니다. 실제 외부 피드백이 있을 때는 작동하지만, 모델이 스스로 검토만 할 때는 실패합니다. 검사기가 없으면 루프가 아니라 끝없는 비용 낭비가 됩니다.
- 중단 규칙. 검사기를 통과했거나, 턴(turn) 제한에 도달했거나, 최근 두 번의 시도가 동일한 출력을 냈을 때 멈춥니다.
- 예산. 턴 수와 비용, 둘 다 필요합니다.
코드로 구현하면 단 몇 줄로 완성됩니다.
1for turn in range(MAX_TURNS):2 action = model.next_step(goal, history)3 result = run(action)4 history.append(result)56 if checker(result): break # 완료7 if repeated(history, 2): break # 정체됨8 if spent() > BUDGET: break # 비용 초과9else:10 fallback_workflow(goal)
제가 본 것 중 가장 뛰어난 프로덕션 구성은 하이브리드 방식입니다. Atlan 은 먼저 결정론적 필터를 돌리며, 들어오는 알림 중 에이전트까지 도달하는 것은 약 14% 에 불과합니다.
그다음 루프는 최대 3 사이클만 돕니다. 3 번 돌아도 신뢰도가 여전히 50% 미만이면 고정된 Python 워크플로가接管(인수)합니다.
먼저 필터링하고, 짧게 루프를 돌린 뒤, 폴백(fallback) 으로 빠져나오세요.
pic3. 워크플로와 루프 중 무엇을 선택할지 결정하는 방법
지름길
스레드에서 Viktor 에게 주는 모든 작업은 루프입니다. 당신이 목표를 적으면, 그가 단계를 선택하고 여러 도구를 거쳐 작업한 뒤 스레드로 결과를 가져옵니다.
네 가지 요소는 다음과 같이 대응됩니다.
- 목표. 그는 불완전한 지시에는 반론을 제기하고, 짐작하는 대신 질문합니다. 그래도 '완료' 기준은 적어주세요. "보고서 작성해"보다는 "지난주 매출 보고서, 총액은 Stripe 와 일치해야 하며, 월요일 오전 9 시까지 #finance 에 게시"가 훨씬 낫습니다.
- 검사기. 게시하기 전에 숫자가 이상해 보이면 경고합니다. 대조할 소스를 명시하면 더 강력해집니다. Stripe 총액, 행(row) 수, 테스트 스위트 등입니다.
- 중단 규칙. 민감한 작업은 사람의 승인을 위해 일시 중지되며, 결과는 항상 당신에게 돌아옵니다.
- 예산. 크레딧입니다. 추론 티어(reasoning tier) 가 각 단계의 가격을 결정하며, 반복 작업의 경우 빈도가 중요합니다. 시간별 보고서는 주간 보고서보다 비용이 훨씬 큽니다.
Atlan 의 하이브리드 방식은 코드 없이도 가능합니다. 반복되는 작업은 예약된 태스크가 됩니다. 그가 제안하고, 당신이 승인할 때까지 대기 상태로 남아있습니다. 이것이 곧 워크플로입니다.
끝이 정해지지 않은 작업은 스레드로 넘기는데, 이것이 루프입니다. 그리고 폴백 역할은 당신이 맡습니다.
3. Jev 엔지니어링
정의
사무실의 전문가는 모든 봉투를 뜯어보지 않습니다. 안내 데스크에 있는 사람이 우편물을 분류합니다. 청구서는 한쪽으로, 스팸은 휴지통으로, 계약서는 변호사에게로 보냅니다.
에이전트의 업무는 크게 두 가지입니다. 무언가를 '작성'하는 것과 '결정'하는 것입니다. 지금은 거대한 모델 하나가 이 둘을 모두 처리하므로, 변호사에게 우편물 분류를 맡기고 비싼 돈을 지불하는 셈입니다.
Jev 는 안내 데스크입니다. 절대 작성하지 않고, 오직 선택만 합니다.
작동 방식
Jev 에게 질문과 가능한 답변 후보를 미리 제공합니다. 그러면 다음 세 가지 중 하나와 신뢰도 점수를 반환합니다.
- 예 또는 아니오
- 집합 중 하나의 옵션
- 척도상의 숫자
선택만 하기 때문에 빠르고 저렴합니다. 알려진 수치는 3~329 초 대비 70~500 밀리초이며, 입력 토큰 100 만 개당 $0.042 에 출력은 무료입니다.
솔직한 이야기를 해보죠. Jev 는 출시된 지 2 주밖에 되지 않았고, 독립적인 테스트 결과가 이제 막 나오기 시작했습니다.
- 이메일 분류에서 일반 로지스틱 회귀가 98.9% 를 기록한 반면, Jev 는 98.6% 였습니다.
- 피싱 탐지에서 Jev 는 62.6%, Claude Haiku 4.5 는 81.3% 를 기록했습니다.
- "환각 제로"라는 수치에는 저자들의 각주가 달려 있습니다. 경험적으로 증명된 것이 아니라, 출력이 항상 스키마와 일치한다는 의미일 뿐입니다.
신뢰도 점수 역시 기본 상태에서는 진짜 확률이 아닙니다. 순위 정도로 취급하고, 직접 라벨링한 데이터를 기준으로 임계값을 설정하세요.
구축 방법
합리적인 구성은 비싼 모델 앞에 관문(gate) 을 두는 것입니다.
- 모든 요청이 들어옵니다.
- Jev 가 각 항목에 대해 좁은 질문 하나에 답합니다.
- 확실하고 일상적인 항목: 저렴하게 처리합니다. 라벨링, 라우팅 또는 폐기합니다.
- 불확실하거나 특이한 항목: 메인 모델로 보냅니다.
1d = jev.choose(item, options=["spam", "order_status", "refund", "other"])23if d.confidence >= 0.7 and d.option != "other":4 handle_cheap(d.option, item)5else:6 main_model(item) # 실패 안전(fail closed): 불확실하면 비싼 경로로 보냄
이 모든 것에 앞서, 통할 수 있는 가장 단순한 방법을 먼저 시도해 보세요. 실제 예시 수백 개에 라벨을 달고 기본적인 분류기를 학습시킨 뒤, 그것으로 부족할 때만 위로 올라가세요.
30 분이면 되는 작업이며, 어떤 벤더의 주장이든 넘어야 할 기준선(baseline) 입니다.
pic4. Jev 가 답변하는 세 가지 유형의 질문
지름길
Jev 는 Viktor 의 공식 스택에 포함되어 있지 않지만, 이 아이디어는 당신이 통제할 수 있는 두 곳에 적용할 수 있습니다.
- 추론 티어. 그는 세 가지 모드로 작동합니다. Claude Opus 기반의 Smart, 비용이 절반 정도인 Claude Sonnet 기반의 Balanced, 비용이 두 배 정도인 Claude Fable 기반의 Ultra 입니다. 요청을 분류하거나 숫자 하나를 추출하는 데 최상위 티어는 필요 없습니다.
- 그 앞에 두는 관문. 고객 지원 이메일이나 알림 같은 스트림을 그에게 맡기고 싶다면, 스트림 전체를 통째로 넘기지 마세요. 분류기나 Jev 호출을 먼저 두어, 판단이 필요한 항목만 그의 작업이 되도록 하세요.
이 레이어는 Viktor 를 쓰더라도 당신의 엔지니어링 역량이 여전히 중요한 두 영역 중 하나입니다.
4. 하네스 엔지니어링
정의
같은 직원, 두 개의 사무실이 있습니다. 첫 번째 사무실에는 적절한 도구, 벽에 걸린 매뉴얼, 업무를 검수하는 동료가 있고 금고 열쇠는 없습니다. 두 번째 사무실에는 노트북 하나와 당신의 관리자 비밀번호가 있습니다.
능력은 같아도 결과는 완전히 다릅니다. 직원이 모델이고, 사무실이 하네스입니다.
에이전트 = 모델 + 하네스.
작동 방식
하네스는 모델을 제외한 모든 것입니다. 도구, 권한, 샌드박스, 프로젝트를 설명하는 파일, 출력값을 검증하는 장치들이죠.
2026 년에 이르러 하나의 독립된 분야로 자리 잡았는데, 사람들이 측정을 시작하면서 모델이 예상만큼 많은 것을 설명하지 못한다는 사실이 드러났기 때문입니다.
- Anthropic 은 컨테이너 리소스만 변경했는데 벤치마크 점수가 6 포인트 올랐습니다.
- LangChain 은 모델을 고정한 채 하네스만 바꿔서 같은 벤치마크에서 13.7 포인트를 끌어올렸습니다.
- 그런 다음 10 배 저렴한 오픈 모델을 중심으로 하네스를 튜닝해, Opus 4.8 의 0.87 에 맞먹는 0.86 점을 달성했습니다.
이제 모델만 사는 시대는 끝났습니다. 모델과 하네스를 세트로 구매하는 것입니다.
에이전트가 실제 무언가(리포지토리, 수신함, 결제, 프로덕션 데이터베이스) 에 손을 대는 순간 하네스가 반드시 필요합니다.
구축 방법
바깥에서 안쪽으로 구축하세요.
- 격리(Containment). 에이전트가 물리적으로 닿을 수 없는 영역입니다. 컨테이너, 별도 브랜치, 읽기 전용 데이터베이스 사용자, 허용 목록(allowlist) 외 네트워크 차단 등이 있습니다. 첫 프롬프트를 날리기 전에 설정하세요.
- 가이드(Guides). 행동하기 전에 방향을 잡아주는 요소입니다. AGENTS.md 같은 리포지토리 내 파일, 모델이 올바른 것을 고를 수 있을 만큼 명확한 도구 설명, 좋은 출력 예시 몇 가지가 포함됩니다.
- 센서(Sensors). 행동한 후 검증하는 요소입니다. 린터, 타입 체커, 테스트 스위트는 빠르고 결정론적이므로 모든 결과에 실행하세요. 두 번째 모델이 diff 를 검토하는 것처럼 느린 검증은 중요한 부분에만 적용하세요.
- 권한(Permissions). 에이전트가 승인을 요청하면 사람들은 93% 의 확률로 승인합니다. 승인 프롬프트는 거의 아무것도 보호하지 못합니다. 진정한 보호는 애초에 불가능하게 만든 행동입니다. 승인은 정말로 되돌릴 수 없는 소수의 작업에만 남겨두세요.
가이드 파일이 길 필요는 없습니다. 단 네 줄만으로도 행동이 바뀝니다.
1# AGENTS.md2- Monorepo: /api (FastAPI), /web (Next.js), /jobs (cron)3- Run tests with `make test`. They must pass before any commit4- Never edit /migrations by hand, use `make migration`5- DB access is read only. Ask before any schema change
훅(hook) 은 이와 같은 아이디어를 강제하는 버전입니다. Claude Code 에서 훅은 도구 호출 전에 실행되어 호출을 차단할 수 있는 작은 스크립트입니다. "main 에 절대 푸시하지 마라"는 프롬프트의 한 줄이 아니라 훅으로 구현해야 작동합니다.
주의할 점이 있습니다. 하네스의 모든 요소는 '모델이 이것을 못 할 것이다'라는 내기이며, 그 내기는 유효기간이 있습니다. Anthropic 은 모델 업그레이드로 인해 불필요해진 스캐폴딩(scaffolding) 컴포넌트 전체를 삭제한 바 있습니다.
몇 달마다 하네스를 다시 점검하고, 모델이 이미 극복해 낸 제약은 삭제하세요.
pic5. 하네스의 네 겹
지름길
에이전트 = 모델 + 하네스라면, Viktor 를 사용할 때 얻는 것의 대부분은 하네스입니다. 밑바탕이 되는 모델은 Claude 이며, 그 주변은 모두 준비된 상태로 제공됩니다.
- 도구. GitHub, Linear, HubSpot, Stripe, Notion, Google Drive 등 3,200 개 이상의 통합 기능을 지원합니다. 연결이 준비되지 않은 도구는 그가 직접 구축할 수도 있습니다.
- 가이드. 스킬 기능입니다. AGENTS.md 를 직접 작성하는 대신, 화면을 녹화하면 그가 절차를 초안으로 작성하고 당신이 편집합니다.
- 센서. 앞뒤가 맞지 않는 데이터를 표시하고, 빠진 부분이 있는 지시에 대해 질문합니다. 그리고 모든 단계는 팀이 확인할 수 있도록 Slack 스레드에 기록됩니다.
- 권한. 고객 이메일 및 재무 관련 변경 사항은 승인을 위해 일시 중지됩니다. 새로 예약된 자동화는 누군가 켤 때까지 대기 상태를 유지합니다.
어떤 제품도 대신 만들어 줄 수 없는 유일한 부분은 격리입니다. 당신이 넘겨주는 자격 증명으로 구성되기 때문입니다. 앞서 말한 93% 를 기억하고, 작업에 필요한 최소한의 접근 권한만으로 그를 연결하세요.
- 읽기 전용 데이터베이스 사용자
- 제한된 Stripe 키
- 개인 계정이 아닌 공유 지원 수신함
- 특정 리포지토리로 범위가 한정된 GitHub 토큰
닿을 수 없는 것은 망가뜨릴 수도 없습니다.
pic6. Viktor 의 하네스
5. 에발 엔지니어링
정의
새로운 직원이 성장했다는 것을 어떻게 알 수 있을까요? 지난달에 냈던 것과 같은 시험을 주고 비교해 보는 것입니다.
동일한 테스트가 없다면 당신이 가하는 모든 변화는 그저 추측일 뿐입니다. 에발은 에이전트를 위한 그 시험입니다. 이미 정답을 알고 있는 일련의 작업들로, 무언가를 변경할 때마다 실행합니다.
작동 방식
검증에는 두 가지 종류가 있습니다.
- 엔드 투 엔드(End to end). 최종 답변이 올바르게 나왔는가? 점수가 변했다는 사실은 알려주지만 이유는 알려주지 않습니다.
- 행동(Behavioral). 특정 행동이 일어났는가? 답변하기 전에 검색을 호출했는가? 요청이 모호할 때 명확화 질문을 던졌는가? 완료라고 말하기 전에 검증했는가?
행동 검사는 최종 답변뿐만 아니라 에이전트가 수행한 모든 기록인 트레이스(trace) 를 대상으로 실행됩니다. Google 의 규칙은 이 스위트가 5 초 이내에 끝나야 한다는 것입니다. 그래야 변경 사항이 생길 때마다 실행할 수 있기 때문입니다.
모델이 채점을 맡는다면 그것을 심사위원(judge) 이라 부르며, 이 심사위원 역시 검증이 필요합니다. Airbnb 는 동일한 입력을 반복 실행했을 때 모델이 생성한 참조 답변의 약 4 분의 3 이 다르게 나온다는 사실을 발견했습니다. 그들의 에발은 자기 자신의 노이즈를 측정하고 있었던 것입니다.
구축 방법
- 실제 실패 사례에서 시작하세요. 실제 실행 기록을 살펴보고 무엇이 잘못되었는지 찾아낸 뒤, 각각을 테스트 케이스로 만드세요. Airbnb 의 골든 셋(golden set) 은 50~100 개의 예시로 운영되며, 실패 사례는 필수입니다.
- 케이스당 하나의 행동 검사를 작성하세요. 하나의 케이스, 하나의 검증 항목입니다.
- 심사위원을 검증하세요. 샘플을 직접 채점해 보고, 모델을 신뢰하기 전에 당신과 모델이 얼마나 자주 일치하는지 확인하세요.
- 프로덕션을 샘플링하세요. Airbnb 는 매일 라이브 트래픽의 5% 를 추출합니다. 실제 사용 패턴이 멀어질수록 에발 세트는 효력을 잃습니다.
하나의 케이스는 이렇게 작아도 됩니다.
1input: "Refund order #1042, customer says it arrived broken"2expect:3 - looks up the order before replying4 - asks for approval before issuing the refund5check:6 - trace has get_order before send_reply7 - trace has approval_request before refund
전체 통과율만 지켜보지 마세요. 특정 행동 하나가 조용히 망가지는 동안 전체 통과율은 오히려 올라갈 수도 있습니다. 개별 검사를 주시하세요.
pic7. 좋은 에발 케이스는 어디서 오는가
지름길
당신의 비즈니스에서 정답이 무엇인지는 당신만 알기 때문에, 어떤 제품도 이 레이어를 대신 구축해 줄 수 없습니다. 하지만 방법론은 그대로 적용할 수 있습니다.
- 2 주 후, 정답을 알고 있는 그의 스레드 20 개를 고르세요. 당신이 직접 수정해 줘야 했던 스레드는 빠짐없이 포함합니다.
- 케이스당 하나의 간단한 검사를 작성하세요. 모든 숫자에 출처를 링크했는가? 지시가 모호할 때 질문했는가? 정보가 회사 밖으로 나가기 전에 멈췄는가?
- 변경 사항(새로운 스킬, 수정된 지시, 다른 티어) 이 생길 때마다 세트를 다시 실행하세요. Smart 에서 Balanced 로 바꾸면 크레딧이 절반가량 절약되므로, 영구 전환하기 전에 테스트해 보세요.
- 일주일에 한 번, 무작위 스레드 5 개를 직접 채점하세요.
종합
다섯 개의 레이어, 다섯 개의 질문. 컨텍스트는 무엇을 보는가입니다. 루프는 누가 결정하는가입니다. Jev 는 저렴한 결정을 처리합니다. 하네스는 어디까지 닿을 수 있고 누가 검증하는가입니다. 에발은 어떻게 아는가입니다.
Viktor 를 사용하면 이 중 세 가지(컨텍스트, 루프, 하네스) 는 대부분 내장된 상태로 제공됩니다. Jev, 에발, 그리고 당신이 넘겨주는 자격 증명은 여전히 당신의 엔지니어링 영역입니다.
오늘 당장 시작한다면, 각 레이어에서 가장 저렴하고 유용한 첫걸음은 다음과 같습니다.
- 컨텍스트: 변하지 않는 지시를 시스템 프롬프트로 옮기고 더 이상 수정하지 마세요.
- 루프: 그냥 돌려놓기 전에 턴 제한과 비용 제한을 설정하세요.
- Jev: 에이전트가 가장 자주 내리는 결정에 대해 예시 200 개에 라벨을 다세요.
- 하네스: 아무것도 삭제할 수 없는 사용자로 에이전트를 실행하세요.
- 에발: 최근 겪은 실패 사례 5 가지를 테스트 케이스로 적어두세요.
Viktor 를 쓴다면 같은 하루가 이렇게 바뀝니다.
- 컨텍스트: 회사 소개서를 작성하고 첫 번째 스킬을 녹화하세요.
- 루프: 모든 작업에 완료 정의를 넣고, 티어를 의도적으로 선택하세요.
- Jev: 스트림이 그에게 전달될 작업으로 바뀌기 전에 필터링하세요.
- 하네스: 읽기 전용이고 범위가 제한된 자격 증명으로 연결하세요.
- 에발: 실제 스레드 20 개를 저장해 첫 번째 테스트 세트로 삼으세요.
딱 하루면 다섯 가지를 모두 커버할 수 있습니다.
제 생각은 이렇습니다. 더 이상 모델이 어려운 부분이 아닙니다. 그 주변의 다섯 레이어가 어렵습니다. 이것만 제대로 갖추면 인력 증가 없이 처리 능력을 확장할 수 있습니다. 대부분의 팀은 처음 세 가지는 기성품을 활용하고, 품질을 좌우하는 두 가지, 즉 저렴한 결정과 에발에 자신들의 시간을 쏟아야 합니다.
이 글을 후원해 준 Viktor 에게 감사드립니다.
@viktor_com 에서 무료로 체험해 보세요. 카드 등록 없이 $100 크레딧을 드립니다. 전체 링크는 제 첫 번째 답글에 있습니다.
가입 시 YARCHI100 코드를 사용하세요.
유료 파트너십
