용어집
《검증과 품질 보증: '맞아 보이는 것'을 통과시키지 않기》의 용어 66개. 레슨 본문에서 처음 등장하는 용어에 마우스를 올리면 정의를 볼 수 있습니다.
| 용어 | 정의 | 출처 |
|---|---|---|
| 완료된 것처럼 보인다 | Claude가 멈추는 지점. 스스로 실행할 수 있는 검사가 없으면 '완료된 것처럼 보인다'가 파이프라인 전체에 존재하는 유일한 신호가 된다. | Best practices for Claude Code — Claude Code official documentation |
| 검증 루프 | 돌릴 수 있는 검사가 파이프라인에 하나도 없을 때 결국 사람이 떠맡게 되는 역할. 모든 실수가 알아채 주기를 기다리게 된다. | Best practices for Claude Code — Claude Code official documentation |
| trust-then-verify gap | 공식 문서가 이 현상에 붙인 이름. Claude는 그럴듯해 보이지만 엣지 케이스를 처리하지 않는 구현을 내놓고, 먼저 믿게 되며, 검증은 일어나지 않거나 너무 늦게 일어난다. | Best practices for Claude Code — Claude Code official documentation |
| 주장 | 믿을지 말지 고를 수밖에 없는 문장. '로직은 올바릅니다', '문제없을 겁니다', '이미 최적화했습니다', '실행 중 에러는 없었습니다'. | Best practices for Claude Code — Claude Code official documentation |
| 증거 | 다른 사람이 똑같은 방식으로 다시 돌려 볼 수 있는 것. 명령과 그 원본 출력, 종료 코드, 실패한 테스트 이름 목록, 스크린샷, 변경 전후의 수치 비교. | Best practices for Claude Code — Claude Code official documentation |
| 결정론적 시스템 | 컴퓨팅에서 동일한 입력이 주어지면 매번 동일한 출력을 내놓는 시스템. 이 코스의 검증기가 바로 그 '예측 가능하게 멍청한' 물건이며, 결정론적인 것으로 비결정론적인 것을 단속한다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 비결정론적 | 에이전트 시스템은 시작 조건이 같아도 서로 다른 응답을 생성할 수 있다. 프롬프트에서 한 글자도 바꾸지 않아도 두 실행의 결정이 일치한다는 보장은 없다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 복리로 불어나는 에러 | 에이전트 시스템에서 에러는 복리로 불어난다. 한 단계의 실패가 에이전트를 완전히 다른 궤적으로 탐색하게 만들고, 잘못된 결과를 근거로 새 결정을 내리게 되어 결과가 예측 불가능해진다. | How we built our multi-agent research system — Anthropic Engineering |
| 샌드박스 환경 | Anthropic이 에이전트를 광범위하게 테스트하라고 권하는 곳. 자율성은 더 높은 비용과 에러가 복리로 불어날 가능성을 뜻하므로, 적절한 가드레일과 함께 샌드박스에서 시험한다. | Building Effective AI Agents — Anthropic Engineering |
| ground truth | 실행 중에 에이전트가 환경으로부터 얻는 실제 피드백. 도구 호출 결과나 코드 실행 결과 같은 것으로, 자신의 진척을 평가하는 데 쓴다. | Building Effective AI Agents — Anthropic Engineering |
| 결과를 눈에 보이게 개선할 때 | 복잡성을 더해도 되는 입장 조건. 복잡성은 그것이 결과를 눈에 보이게 개선할 때에만 더할 것을 고려해야 한다. | Building Effective AI Agents — Anthropic Engineering |
| stop_reason | 하네스 루프를 구동하는 모델 응답의 필드. 값이 tool_use면 도구를 실행해 되먹이고, end_turn이 되면 루프가 빠져나온다. | Tool use with Claude — Claude API documentation |
| end_turn | stop_reason의 값 하나. 모델이 이번 턴에 도구를 더 부를 생각이 없다는 뜻이고, 그게 전부다. | Tool use with Claude — Claude API documentation |
| tool_result | 도구 실행 결과를 모델에 되먹이는 메시지 블록. tool_use_id로 대응하는 tool_use와 짝지어지며, 검증기의 출력이 이것을 통해 대화로 흘러들어온다. | Tool use with Claude — Claude API documentation |
| run_check | 검증 스크립트를 모델이 호출할 수 있는 도구로 감싸, 루프 안에서 스스로 검사를 돌리고 결과를 읽게 하는 것. 종료 코드와 stdout을 있는 그대로 넘긴다. | Best practices for Claude Code — Claude Code official documentation |
| 종료 코드 | 검증 스크립트가 결론을 표현하는 방법. 0은 통과, 0이 아니면 실패이며, CI와 셸의 &&가 그대로 쓴다. | Best practices for Claude Code — Claude Code official documentation |
| 통과/실패 | 검사가 내놓을 수 있는 객관적인 이분 결과. 이것이 있으면 루프가 스스로 닫힌다 — Claude가 작업을 하고, 검사를 돌리고, 결과를 읽고, 통과할 때까지 반복한다. | Best practices for Claude Code — Claude Code official documentation |
| 픽스처 | 미리 저장해 둔 모범 답안 파일. 실행 후 출력을 그것과 비교하며, 공식 검사 메뉴의 '출력을 픽스처와 diff하는 스크립트'가 이것을 쓴다. | Best practices for Claude Code — Claude Code official documentation |
| 종료 상태 | 기본 판정 방식. 에이전트가 특정 프로세스를 따랐는지가 아니라 올바른 최종 상태에 도달했는지를 판정한다. | How we built our multi-agent research system — Anthropic Engineering |
| 턴별 분석 | 종료 상태 평가가 대체하는 접근. 에이전트의 행동을 턴마다 확인하며 모든 중간 단계를 검증하려 드는 것. | How we built our multi-agent research system — Anthropic Engineering |
| 검증 체크포인트 | 복잡한 워크플로에 몇 군데 두는 개별 관찰 지점. 모든 중간 단계를 검증하는 대신 '특정 상태 변화가 일어났어야 한다'를 확인한다. | How we built our multi-agent research system — Anthropic Engineering |
| 복구 체크포인트 | 9번째 코스에서 말하는 쪽. 에이전트의 실행 중 상태를 디스크에 써 두어 크래시 후 거기서 재개할 수 있게 하는 것으로, 목적은 복구이지 판정이 아니다. | How we built our multi-agent research system — Anthropic Engineering |
| 성공 기준 | '올바른 종료 상태'를 구체적인 숫자나 분명한 판정으로 바꾸는 요구의 묶음. 아무리 해도 쓸 수 없다면 그 작업은 애초에 에이전트에 통째로 맡겨 혼자 돌리게 할 것이 아니었다. | Define success criteria and build evaluations — Claude API documentation |
| 측정 가능할 것 | 성공 기준의 첫 번째 강한 요구. 정량 지표나 잘 정의된 정성 척도를 쓰라는 것이며, 숫자는 명확성과 확장성을 준다. | Define success criteria and build evaluations — Claude API documentation |
| 달성 가능할 것 | 성공 기준의 두 번째 강한 요구. 업계 벤치마크, 앞선 실험, AI 연구, 전문 지식에 근거해 목표를 잡고, 현재 프런티어 모델의 능력에 비추어 비현실적이어서는 안 된다. | Define success criteria and build evaluations — Claude API documentation |
| 다차원 평가 | 대부분의 사용 사례는 여러 성공 기준에 걸친 평가를 필요로 한다. 차원들이 서로를 무너뜨리므로 지름길의 여지가 줄어든다. | Define success criteria and build evaluations — Claude API documentation |
| 궤적 단언 | 선택적인 추가 항목. 프롬프트-응답 쌍마다 에이전트가 호출하리라 기대하는 도구를 함께 명시해, 각 도구의 목적을 파악했는지 재는 것. | Writing effective tools for agents — with agents — Anthropic Engineering |
| expectedTools | 궤적 단언을 담는, 평가 케이스의 선택적 필드. 순서나 호출 횟수와 무관하게 최소한 이 도구들은 건드렸기를 기대한다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 중복된 도구 호출 | 진단 지표 하나. 호출 횟수가 눈에 띄게 많다면 대개 페이지네이션이나 토큰 상한 파라미터의 크기를 조정할 필요가 있다는 신호다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 도구 에러 | 진단 지표 하나. 잘못된 파라미터로 인한 에러가 많다면 대개 그 도구의 설명이 더 분명해지거나 더 나은 예시가 필요하다는 신호다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 코드 기반 채점 | 채점 방법 줄 세우기의 1위. 가장 빠르고 가장 믿을 만하며 확장성이 대단히 좋다. 약점은 규칙에 덜 얽매인 판단이 필요한 복잡한 사안에서 결이 부족하다는 것이다. | Define success criteria and build evaluations — Claude API documentation |
| LLM 기반 채점 | 줄 세우기의 2위. 빠르고 유연하며 확장 가능하고 복잡한 판단에 적합하지만, 전제는 먼저 신뢰할 수 있는지 시험하고 그다음에 확장하는 것이다. | Define success criteria and build evaluations — Claude API documentation |
| 사람 채점 | 줄 세우기의 3위. 가장 유연하고 품질도 가장 높지만 느리고 비싸므로 가능하면 피한다. | Define success criteria and build evaluations — Claude API documentation |
| 정확 일치 | 검증기 스펙트럼의 가장 왼쪽 형태. 모델의 출력이 미리 정해 둔 올바른 답과 일치하는지를 재며, 보통 공백과 대소문자를 정규화한 뒤에 비교한다. | Define success criteria and build evaluations — Claude API documentation |
| output == golden_answer | 정확 일치의 최소 형태로, 동등 비교 하나뿐이다. 단순하고 모호하지 않아 답이 뚜렷하게 갈리고 범주형인 작업에 맞는다. | Define success criteria and build evaluations — Claude API documentation |
| 정규화 | 비교하기 전에 의미를 담고 있지 않은 차이를 지우는 것. 연속된 공백 접기, 앞뒤 떼기, 대소문자 통일이며, 금액이라면 통화 기호와 천 단위 구분자와 단위도 씻어 낸다. | Define success criteria and build evaluations — Claude API documentation |
| 결정론적 검증기 | 이 코스의 핵심 기법. 매번 같은 결론을 내는 코드로 비결정론적 시스템의 출력을 단속하며, 통과/실패와 읽을 수 있는 실패 이유를 돌려준다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 스펙트럼 | 검증기는 몇 개의 배타적인 선택지가 아니라 연속된 띠를 이룬다. 한쪽 끝은 픽스처와의 정확한 문자열 일치이고, 다른 쪽 끝은 Claude에 판정을 맡기는 것이다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| strict: true | 도구 정의에 더하는 한 줄. Claude의 도구 호출이 선언해 둔 스키마와 언제나 정확히 일치하도록 보장해, 한 부류의 구조 검증을 플랫폼 차원의 보장으로 앞당긴다. | Tool use with Claude — Claude API documentation |
| 거짓 음성 | 검증기가 올바른 출력을 실패로 판정하는 것. 에러를 통과시키는 것이 아니라 올바른 것을 억울하게 벌준다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 지나치게 엄격한 검증기 | 결정론적 검사가 실패하는 가장 흔한 방식. 형식, 문장 부호, 유효한 다른 표현 같은 겉도는 차이 때문에 올바른 응답을 거부한다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 자유 형식 텍스트 | 조사나 요약 같은 산출물. 형식이 자유롭고 정답이 하나인 경우가 드물어 프로그램으로 평가하기 어렵다. 이런 출력을 채점하는 데는 LLM이 자연스럽게 들어맞는다. | How we built our multi-agent research system — Anthropic Engineering |
| 사람의 리뷰 | 자동 테스트 너머로 여전히 빠질 수 없는 단계. 자동 테스트는 기능이 올바른지를 검증하지만, 해법이 더 넓은 시스템 요구사항에 부합함을 보장하려면 여전히 사람의 눈이 필요하다. | Building Effective AI Agents — Anthropic Engineering |
| LLM 판정자 | 자유 형식 텍스트 출력에 점수를 매기기 위한 모델 호출. 결정론적 검사가 닿지 못하는 자리에 놓이는 것이지 그 대체재가 아니다. | How we built our multi-agent research system — Anthropic Engineering |
| 루브릭 | 막연한 '좋은가'를 구체적인 질문 몇 개로 쪼개고, 각각을 따로 답하고 따로 점수 매기는 것. 리서치 과제를 위한 기성 분해는 다섯 차원이다. | How we built our multi-agent research system — Anthropic Engineering |
| 근거를 먼저 쓰고 점수를 나중에 | 판정자 프롬프트의 결정적인 기법. 점수를 내기 전에 먼저 추론하게 하고 그 추론은 버린다. 채점 성능이 올라가며 특히 복잡한 판단에서 효과가 크다. | Define success criteria and build evaluations — Claude API documentation |
| 새 컨텍스트 | 리뷰어가 앉아야 할 자리. 출력과 주어진 기준만 볼 뿐 그 변경을 만들어 낸 추론은 보지 못하므로, 결과 자체를 놓고 판정한다. | Best practices for Claude Code — Claude Code official documentation |
| 자기 보고 | 에이전트가 자기 과정을 서술한 것('권위 있는 출처 세 곳을 확보해 교차 검증한 뒤 비율을 확정했습니다'). 그 자체로는 증거로 치지 않는다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 원본 트랜스크립트 | 도구 호출과 도구 응답까지 포함한 실행 로그. 에이전트의 사고 사슬에 명시적으로 기술되지 않은 행동을 잡아내는 데 쓴다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 문제를 찾으라고 시키기 | 판정자의 첫 번째 실패 양상. 빈틈을 찾으라고 지시받은 리뷰어는 작업이 멀쩡할 때도 대개 뭔가를 보고하는데, 그것이 자기가 지시받은 일이기 때문이다. | Best practices for Claude Code — Claude Code official documentation |
| 과잉 설계 | 모든 리뷰 지적을 쫓아다닌 결과. 추상화 계층이 늘고, 방어 코드가 붙고, 일어날 수 없는 경우를 위한 테스트가 생긴다. | Best practices for Claude Code — Claude Code official documentation |
| 효과 크기 | 변경 하나로 벌어진 간격이 얼마나 큰가. 71.2%에서 72.4%인가, 30%에서 80%인가. 간격이 클수록 필요한 표본은 적다. | How we built our multi-agent research system — Anthropic Engineering |
| 평가 세트 | 검증 가능한 결과가 짝지어진 과제 묶음. 공식이 시작한 규모는 실제 사용을 대표하는 질의 20개 정도이며, 수백 개가 모일 때까지 기다리지 않는다. | How we built our multi-agent research system — Anthropic Engineering |
| 검증 가능한 결과 | 모든 평가 프롬프트에 짝지어져 있어야 하는 것. 판정할 수 있는 종료 상태, 문자열, 상태 변화, 또는 루브릭이며, 이것이 없으면 그 프롬프트는 평가 과제가 아니라 데모다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 엣지 케이스 | 빈도는 낮지만 실제로 일어나는 상황(정보 누락, 여러 요청 혼재, 도구 에러). 평가 세트에서 보험이지 몸통이 아니다. | Define success criteria and build evaluations — Claude API documentation |
| 품질보다 개수를 앞세우기 | 평가 세트 설계 원칙. 신호가 다소 약하더라도 자동 채점되는 문제가 많은 편이, 사람이 손으로 고품질 채점하는 문제가 적은 편보다 낫다. | Define success criteria and build evaluations — Claude API documentation |
| 실제 분포 | 평가가 붙잡고 있어야 할 것. 평가 과제는 실제 사용에 뿌리를 두어야 하며, 어느 프롬프트를 가리키며 '지난주에 사용자 세 명이 정확히 이렇게 물었다'고 말할 수 있어야 한다. | Define success criteria and build evaluations — Claude API documentation |
| 홀드아웃 세트 | 처음부터 따로 떼어 두고 일상적인 튜닝 동안에는 보지도 돌리지도 건드리지도 않는 케이스 묶음. '학습용' 평가에 과적합되지 않았음을 이것으로 확인한다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| dev 세트 | 날마다 프롬프트를 바꿀 때 반복해서 돌리는 케이스 묶음. 자주 돌릴수록 좋으며, 그 점수는 항법이지 판결이 아니다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 과적합 | 프롬프트와 도구 구성을 합친 전체가 과제 자체의 규칙성이 아니라 평가 재료의 특징을 배우는 것. 계속 실패하는 케이스 하나를 위해 시스템 프롬프트에 한 문장을 하드코딩하는 것이 그 예다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 보장되지 않는다 | 어떤 이상적인 동작(모델이 빠진 필수 파라미터를 스스로 되묻는 것 같은)에 대해 공식 문서가 쓰는 표현. 특히 더 모호한 프롬프트와 능력이 낮은 모델에서 그렇다. | Tool use with Claude — Claude API documentation |
| 평가 트랙 | 평가 세트와 계층화된 채점과 하네스 루프를 하나로 용접한, 돌아가는 프로그램. 명령 하나를 치면 점수가 무엇이 좋아졌고 무엇이 그대로이며 옳던 것이 깨지지는 않았는지를 말해 준다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 스텁 client | 고정된 큐 순서대로 응답을 뱉는 가짜 messages.create. 모델의 동작을 통제 변수로 만들어 트랙 전체를 재현 가능하게 한다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 응답 큐 | 스텁 client 뒤에 미리 써 두는 응답 시퀀스. 두 프롬프트 버전의 차이가 두 벌의 큐에 고정되며, '새 프롬프트가 먹혀서 모델이 이렇게 답한다고 가정한다'가 데이터로 인코딩된다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| 태스크 격리 | 평가 과제 하나에 독립적인 루프 하나, 독립적인 messages 하나. 끝나면 버린다. 구현은 messages를 함수 밖으로 끌어올리지 않는 것뿐이다. | Writing effective tools for agents — with agents — Anthropic Engineering |
| is_error | 도구 예외를 되먹일 때 tool_result에 붙이는 표시. 예외를 잡아 이 표시가 붙은 결과로 감싸 모델에 돌려주고, 동시에 에러 카운터를 하나 올린다. | Tool use with Claude — Claude API documentation |