원문: https://github.com/facebook/astryx/wiki/Designing-Vibe-Tests · 번역 기준: 2026-09-03
사용자를 위해 vibe test를 설계하는 AI 에이전트를 위한 플레이북입니다. 어려운 부분은 테스트를 실행하는 것이 아니라, 막연한 "X를 테스트하고 싶다"를 실행 가능하고 공정한 평가로 바꾸는 일입니다. 그 전환은 짧은 인터뷰를 통해 일어납니다. 이 페이지는 에이전트에게 어떤 질문을 해야 하는지 가르칩니다.
vibe test란 LLM이 서로 다른 구성 아래에서 과제를 얼마나 잘 수행하는지 측정하는, 구조화되고 공정한 평가입니다: 같은 prompt, 다른 조건, 측정 가능한 결과. 빠르게 움직이는 분야를 위한 나침반입니다 — 옵션들을 프로토타입하고, naive한 prompt를 던져 보고, 의견이나 기억이 아닌 데이터가 결정하게 하세요.
이것은 범용 설계 방법론이며 컴포넌트 API뿐 아니라 어떤 결정에도 적용됩니다 — 툴의 출력 포맷, skill의 문구, 워크플로우, 모델 등. Astryx에 특화된 두 가지 적용 사례는 API Arbitration과 Vibe Evaluation을 참고하세요.
사용자가 "X를 vibe test하고 싶다"고 말하면, 곧바로 prompt를 쓰기 시작하지 마세요. 먼저 네 가지 재료를 확정하는 짧은 인터뷰를 진행하세요. 각 재료마다 합리적인 기본값을 제안하고 사용자가 반응하도록 요청하세요 — 구체적인 제안에 반응하는 것이, 백지에서 spec을 작성하는 것보다 사용자에게 훨씬 쉽습니다.
네 가지 재료:
| # | 재료 | 실제로 답하려는 질문 |
|---|---|---|
| 1 | 목표와 측정(Goal & measure) | 무엇이 승자를 결정하는가? |
| 2 | 최종 사용자 입력(End-user inputs) | naive한 prompt는 어떤 모습인가? |
| 3 | 변형(Variations) | 우리는 실제로 무엇을 비교하는가? |
| 4 | 오케스트레이션과 판정(Orchestration & judging) | 누가 실행하고, 누가 채점하는가? |
순서대로 진행하세요 — 각 답이 다음 답의 입력이 됩니다.
모든 vibe test에 파이프라인이 필요한 것은 아닙니다. 이 결정에 따라 만들어야 할 scaffolding의 양이 달라지므로 intake 중에 확정하세요:
| Ad-hoc (대부분의 테스트) | Stored / scheduled | |
|---|---|---|
| 목적 | 지금 질문 하나를 해결 — API 형태, 문서 문구, "이게 도움이 되나?" | 시스템을 시간에 걸쳐 추적; nightly 벤치마크 |
| 결과 | 채팅 / 이슈 / PR에 결과 표만 보여주기 | 실행별 구조화된 JSON, 집계 + 리포트 |
| 오버헤드 | 없음 — schema도, 저장도, 리포팅 job도 없음 | 결과 schema, 저장 경로, 리포트/self-healing 루프 |
| 재사용 | 결정이 내려지면 폐기 | 실행 간 비교; 트렌드가 중요 |
기본값은 ad-hoc입니다. 사용자가 실제로 실행 간 비교나 스케줄 실행을 필요로 할 때에만 #Presenting Results의 JSON schema와 #Reporting and Self-Healing (stored tests only) 기계 장치를 만드세요. 일회성 결정이라면 표가 곧 산출물입니다.
물어볼 것: