목차
이 글은 Anthropic 엔지니어링 블로그에 2026년 1월 21일 게재된 “Designing AI-resistant technical evaluations” 를 읽고, 내용을 정리한 글입니다. 원문: https://www.anthropic.com/engineering/AI-resistant-technical-evaluations
한 줄로 말하면 #
AI가 면접 문제를 다 풀어버리는 시대, 사람의 실력을 가려내려면 평가 자체를 ‘낯선 문제 공간’으로 옮겨야 한다.
어떤 문제를 해결하려 했나 #
Anthropic의 성능 엔지니어링 테이크홈 과제는 약 1,000명의 지원자를 효과적으로 평가해왔습니다. 그런데 Claude가 발전하면서, 모델이 이 과제를 손쉽게 풀어버리기 시작했어요.
“후보자에게 4시간 줘봤더니, 절반은 Claude한테 시키고 나머지 시간은 ‘지켜보기’.”
문제는 둘입니다.
- 익숙한 문제 공간 — 데이터 전치(transposition)·뱅크 충돌 같은 잘 문서화된 영역은 모델이 학습 데이터로 다 봤음
- 무제한 시간 — 모델이 결국 따라잡거나 능가
세 번에 걸친 재설계 끝에 Anthropic이 도달한 답이 흥미롭습니다.
해결책: 평가 설계의 다섯 원칙 #
1. 낯선 문제 공간을 골라라 #
학습 데이터가 풍부한 도메인은 피해야 합니다. 대신 충분히 분포 밖(out-of-distribution) 의 과제를 고릅니다 — 인간의 추론력이 모델의 패턴 인식보다 앞서는 영역으로요.
2. 양보다 판단력을 본다 #
원래 과제는 디버깅·도구 선택 같은 코딩 분량 위주였습니다. 개정판은 “영리한 최적화 통찰” 에 더 무게를 뒀어요. 자원 할당에 대한 판단 — 디버깅 도구를 직접 만들지, 주어진 걸 쓸지 — 같은 결정이 실력 신호가 됩니다.
3. 시간 지평을 길게(하지만 현실적으로) #
원래 4시간 → 2시간으로 단축. 모델은 결국 무제한 시간이 주어지면 따라잡지만, 충분히 긴 시간 지평에선 사람이 우위를 유지합니다.
4. 현실적 제약을 살린다 #
가상 가속기를 다루며 스크래치패드 메모리 관리, VLIW 명령 패킹, SIMD 연산 같은 현실적 제약을 포함했습니다. 인위적 난이도 대신 자연스러운 깊이가 생겼어요.
5. 끝까지 못 풀게 만든다 #
원래 과제가 성공한 핵심 이유: “강한 후보도 다 끝내지 못한다.” 그래야 실력별 신호 분리가 생깁니다.
무엇이 실패했는가 #
시도 1 실패 #
Claude Opus 4가 2시간 안에 인간을 따라잡자, “Claude를 상당히 능가해야 통과” 기준으로 올렸습니다. 결과: 후보자가 시간의 절반을 읽기에 쓰고 Claude에게 시킨 뒤 “앉아서 지켜본다” 는 역효과.
시도 2 실패 #
전치 최적화 문제로 옮겼더니, Claude가 예상 못한 최적화 기법 (전치를 구현하는 대신 계산하는 방식)을 적용해 결국 풀어버렸습니다.
시도 3 성공: Zachtronics 스타일 #
제약 강한 퍼즐형 평가 — 명령어 집합이 작고, 프로그램이 여러 통신 칩에 나뉘고, 각 칩은 명령어 10개 정도만 가짐. 학습 데이터 분포 밖이라 모델이 약하고, 사람은 커스텀 디버깅 도구를 만들어 판단력을 보여줄 수 있습니다.
핵심 결론 #
AI 시대 인재 평가가 어려워질 때 본능적으로 “그냥 AI 사용 금지하자"고 생각하기 쉽습니다. 이 글은 그 길을 거부했어요. 일에서는 AI를 쓸 텐데, 평가에서만 금지하는 건 비현실적이라는 거죠.
“현실성이 문제인 줄 알았는데, 사실은 학습 데이터에 있는 친숙한 문제가 문제였다.”
해법은 “현실 같지만 새로운 문제 공간” 입니다. AI가 학습한 적 없는 영역에서, 사람이 판단력과 도구 제작 능력을 보여줄 수 있게 설계해야 합니다.
원문이 남긴 공개 도전: 인간 최고 기록 1,363 사이클, Claude Opus 4.5 최고 1,487 사이클. 무제한 시간에서는 인간 전문가가 여전히 우위라는 증거예요.
내 작업에 적용한다면 #
이 글의 본질은 “평가 설계가 시대에 따라 진화해야 한다” 입니다. 면접만의 이야기가 아니에요.
시나리오 1 — 일반적인 데이터 분석 과정 #
분석가 채용·역량 평가에 같은 문제가 옵니다. 표준 데이터셋 분석은 LLM이 너무 잘 합니다.
[Before — 학습 데이터에 있는 문제]
"Iris/Titanic 데이터로 분류 모델 만드세요"
→ Claude가 5분 안에 완성, 변별력 0
[AI-resistant 적용]
[낯선 데이터 공간]
- 사내 도메인 특이 데이터셋 (공개 안 된)
- 의미가 모호한 컬럼 (사내 용어 가득)
[판단력 평가]
- "어떤 분석 접근을 선택했고 왜인가" 서술 요구
- 잘못된 가설을 검출하는 능력 평가
[현실적 제약]
- 메모리·시간 한도 부여
- "추가 데이터 수집이 필요한가" 판단 포함핵심: 분석 평가의 가치는 “AI가 학습한 적 없는 도메인 + 판단력 가시화” 에서 옵니다.
시나리오 2 — 웹 사이트를 자동으로 운영할 때 #
운영 자동화 시스템 자체의 평가에도 같은 원칙이 적용됩니다. 테스트셋이 학습 데이터와 비슷하면 평가가 의미를 잃습니다.
[Before — 평가셋이 너무 친숙]
"표준 PR 리뷰", "흔한 배포 시나리오"
→ 자동화 시스템이 다 통과, 실제 사고는 잡지 못함
[AI-resistant 적용]
[낯선 사고 시나리오]
- 사내 도메인 특이 장애 (조합·타이밍 의존)
- 과거 실제 사고를 변형한 평가셋
[판단력 검사]
- "이 상황에서 롤백할지 패치할지" 결정 평가
- 에스컬레이션 타이밍 판단
[현실적 제약]
- 시간 제한, 도구 제한
- "제한된 정보만으로 결정해야 하는" 상황 재현핵심: 운영 시스템의 평가셋은 “흔한 시나리오 + 사내 특이 사고” 양쪽으로 짜야 합니다. 흔한 것만으론 진짜 사고를 못 잡아요.
Anthropic 엔지니어링 블로그를 오래된 순서대로 읽고 정리합니다.
