요약: AI의 능력이 향상됨에 따라 기술적 후보자 평가가 어려워지고 있습니다. Anthropic은 성능 엔지니어 채용을 위해 가정 연산기 시뮬레이터를 최적화하는 테이크홈 테스트를 설계했지만, Claude Opus 4와 Opus 4.5의 등장으로 인해 테스트를 세 번이나 재설계해야 했습니다. 무제한 시간을 주면 여전히 인간 전문가가 모델보다 우수한 성능을 보이지만, 제한된 시간 내에서는 최상위 후보자와 최상위 모델을 구별할 방법이 필요합니다. Anthropic은 원본 테스트를 오픈 챌린지로 공개하며, Claude Opus 4.5의 성능(1487 사이클)을 넘어서는 해결책을 제출한 지원자들에게 채용 기회를 제공하고 있습니다.
Anthropic의 성능 최적화팀 리드인 Tristan Hume이 작성했습니다. Tristan은 Anthropic이 수십 명의 성능 엔지니어를 채용하는 데 도움을 준 테이크홈 테스트를 설계하고 재설계했습니다.
AI 능력이 향상됨에 따라 기술적 후보자 평가가 더 어려워지고 있습니다. 오늘날 인간의 기술 수준을 잘 구별하는 테이크홈 테스트는 내일이면 모델이 쉽게 해결할 수 있어 평가에 무용지물이 될 수 있습니다.
2024년 초부터 우리의 성능 엔지니어링 팀은 가상 연산기에서 코드를 최적화하는 테이크홈 테스트를 사용해왔습니다. 1,000명 이상의 후보자가 이 테스트를 완료했고, 그중 수십 명이 현재 여기에서 일하고 있습니다. 여기에는 Trainium 클러스터를 구축하고 Claude 3 Opus 이후 모든 모델을 배포한 엔지니어들도 포함됩니다.
하지만 각각의 새로운 Claude 모델은 우리에게 테스트를 재설계하도록 강요했습니다. 동일한 시간 제한을 두었을 때, Claude Opus 4는 대부분의 인간 지원자보다 우수한 성적을 거두었습니다. 그래도 우리는 최상의 후보자들을 구별할 수 있었습니다. 하지만 Claude Opus 4.5는 그들과도 대등한 성적을 거두었습니다.
인간은 무제한 시간이 주어지면 여전히 모델을 능가할 수 있지만, 테이크홈 테스트의 제약 조건 하에서는 우리는 더 이상 최상위 후보자들의 출력과 우리의 가장 강력한 모델을 구별할 방법이 없었습니다.
저는 테스트가 여전히 신호를 전달할 수 있도록 보장하기 위해 테이크홈 테스트를 세 번 반복했습니다. 매번 저는 평가가 AI 보조에 대해 얼마나 견고한지, 그렇지 않은지에 대해 새로운 것을 배웠습니다.
이 게시물에서는 원본 테이크홈 디자인, 각 Claude 모델이 어떻게 그것을 격파했는지, 그리고 테스트가 우리 최상위 모델의 능력보다 앞서 나가도록 보장하기 위해 저가 취해야 했던 점점 더 기이한 접근 방식들을 설명합니다.
우리가 수행하는 작업은 모델과 함께 발전해왔지만, 우리는 여전히 더 많은 강력한 엔지니어가 필요합니다. 단지 그들을 찾는 방법이 점점 더 창의적일 뿐입니다. 이를 위해 무제한 시간을 두면 최고의 인간 성능이 여전히 Claude가 달성할 수 있는 것을 능가하므로 원본 테이크홈을 오픈 챌린지로 공개합니다.
Opus 4.5를 능가할 수 있다면 우리는 여러분으로부터 듣고 싶습니다 – 세부 사항은 이 게시물 하단에 있습니다.
테이크홈의 기원
2023년 11월, 우리는 Claude Opus 3를 학습하고 출시할 준비를 하고 있었습니다. 새로운 TPU와 GPU 클러스터를 확보했고, 대규모 Trainium 클러스터가 다가오고 있었으며, 우리는 연산기에 과거보다 훨씬 더 많은 비용을 지출하고 있었습니다. 하지만 새로운 규모에 맞는 성능 엔지니어가 충분하지 않았습니다.
저는 Twitter에 게시하여 사람들에게 이메일을 보내달라고 요청했고, 이를 통해 우리의 표준 인터뷰 파이프라인을 통해 평가할 수 있는 것보다 더 많은 유망한 후보자를 확보했습니다. 이 과정은 직원과 후보자 모두에게 상당한 시간을 소비합니다.
우리는 후보자를 더 효율적으로 평가할 방법이 필요했습니다. 따라서 저는 역할의 요구사항을 적절하게 포착하고 가장 유능한 지원자를 식별할 수 있는 테이크홈 테스트를 설계하기 위해 2주를 보냈습니다.
디자인 목표
테이크홈 테스트는 평판이 좋지 않습니다. 보통 엔지니어들이 지루해하는 일반적인 문제들로 가득 차 있으며, 좋은 필터로 작동하지 않습니다.
저의 목표는 달랐습니다. 후보자들이 참여하는 것을 흥분하게 만들고 고해상도로 그들의 기술적 기술을 포착할 수 있는 진정으로 매력적인 것을 만드는 것이었습니다.
이 형식은 또한 성능 엔지니어링 기술을 평가하는 데 있어 라이브 인터뷰에 비해 장점을 제공합니다:
- 긴 시계: 엔지니어는 코딩할 때 1시간 미만의 마감기한에 거의 직면하지 않습니다. 4시간 창(나중에 2시간으로 단축)은 실제 업무의 특성을 더 잘 반영합니다. 여전히 대부분의 실제 작업보다는 짧지만, 우리는 부담스러운 정도와 균형을 맞출 필요가 있습니다.
- 현실적인 환경: 지켜보거나 설명을 기대하는 사람이 없습니다. 후보자는 방해 없이 자신의 편집기에서 작업합니다.
- 이해와 도구링을 위한 시간: 성능 최적화는 기존 시스템을 이해하고 때로는 디버깅 도구를 구축해야 합니다. 두 가지 모두 일반적인 50분 인터뷰에서 현실적으로 평가하기 어렵습니다.
- AI 보조와 호환성: Anthropic의 일반적인 후보자 가이드라인은 특별히 명시하지 않는 한 후보자가 AI 없이 테이크홈을 완료하도록 요청합니다. 이 테이크홈의 경우, 우리는 명시적으로 그렇지 않음을 나타냅니다. 더 긴 시계 문제는 AI가 완전히 해결하기 더 어려우므로, 후보자는 AI 도구(직장에서처럼)를 사용할 수 있지만 여전히 자신의 기술을 시연해야 합니다.
형식별 목표 외에도 저는 테이크홈을 만들 때 사용하는 것과 동일한 원칙을 적용했습니다:
- 실제 작업 대표성: 문제는 후보자에게 실제 업무가 무엇을 포함하는지 맛보기를 제공해야 합니다.
- 높은 신호: 테이크홈은 단일 통찰에 의존하는 문제를 피해야 하며, 후보자가 자신의 전체 능력을 보여줄 수 있는 많은 기회를 보장해야 합니다 – 운에 맡기는 것을 최소화합니다. 또한 넓은 점수 분포를 보장하고, 강력한 후보자도 모든 것을 완료하지 못할 정도로 충분한 깊이가 있어야 합니다.
- 특정 도메인 지식 불필요: 기본 기술이 좋은 사람은 업무에서 구체적인 내용을 배울 수 있습니다. 좁은 전문 지식을 요구하면 불필요하게 후보자 풀을 제한합니다.
- 재미: 빠른 개발 루프, 깊이가 있는 흥미로운 문제, 창의성을 위한 공간.
시뮬레이션된 머신
저는 TPU와 유사한 특성을 가진 가상 연산기의 Python 시뮬레이터를 구축했습니다. 후보자는 Trainium에서 우리가 가지고 있는 도구링과 유사하게 모든 명령을 보여주는 핫 리로딩 Perfetto 트레이스를 사용하여 이 머신에서 실행되는 코드를 최적화합니다.
머신에는 연산기 최적화를 흥미롭게 만드는 기능이 포함되어 있습니다: 수동 관리 스크래치패드 메모리(CPU와 달리 연산기는 종종 명시적 메모리 관리가 필요함), VLIW(각 사이클마다 병렬로 실행되는 여러 실행 유닛, 효율적인 명령 패킹 필요), SIMD(각 명령에서 여러 요소에 대한 벡터 연산), 멀티코어(코어 간 작업 분배).
작업은 병렬 트리 순회이며, 대부분의 성능 엔지니어가 아직 딥러닝에서 작업하지 않았고 업무에서 도메인 구체 사항을 배울 수 있도록 고의로 딥러닝 맛이 아닙니다.
이 문제는 과거에 대한 헌사로, 소수의 후보자만 이전에 접했던 고전적인 ML 최적화 문제인 브랜치리스 SIMD 결정 트리 추론에서 영감을 받았습니다.
후보자는 완전 직렬 구현으로 시작하여 머신의 병렬성을 점진적으로 활용합니다. 웜업은 멀티코어 병렬성이고, 그 후 후보자는 SIMD 벡터화 또는 VLIW 명령 패킹 중 하나를 처리할지 선택합니다. 원본 버전에는 후보자가 먼저 디버깅해야 하는 버그도 포함되어 있어, 도구링 구축 능력을 시험합니다.
초기 결과
초기 테이크홈 테스트는 잘 작동했습니다. Twitter 배치에서 한 사람이 다른 모든 사람보다 상당히 높은 점수를 받았습니다. 그는 2월 초에 시작했으며, 표준 파이프라인을 통한 첫 번째 채용으로부터 2주 후였습니다.
테스트는 예측력이 있었습니다. 그는 즉시 커널 최적화를 시작했고 텐서 인덱싱 수학이 32비트를 오버플로우하는 출시 차단 컴파일러 버그에 대한 해결책을 찾았습니다.
다음 1년 반 동안 약 1,000명의 후보자가 테이크홈을 완료했고, 이는 우리가 현재 성능 엔지니어링 팀의 대부분을 채용하는 데 도움이 되었습니다.
이는 문서상 경험이 제한된 후보자에게 특히 가치 있었습니다. 우리의 가장 고성능 엔지니어 중 몇 명은 학부생에서 바로 왔지만 테이크홈에서 충분한 기술을 보여 자신 있게 채용할 수 있었습니다.
피드백은 긍정적이었습니다. 많은 후보자들이 즐겁게 하고 있어서 4시간 제한을 초과하여 작업했습니다.
가장 강력한 무제한 시간 제출물에는 완전 최적화 미니 컴파일러와 제가 예상하지 못한 여러 가지 똑똑한 최적화가 포함되었습니다.
Claude Opus 4가 그것을 격파했습니다
2025년 5월까지 Claude 3.7 Sonnet은 이미 50% 이상의 후보자가 Claude Code에 전적으로 위임하는 것이 더 나은 지점까지 올라와 있었습니다.
그런 다음 저는 사전 출시 버전의 Claude Opus 4를 테이크홈 테스트해 보았습니다. 4시간 제한 내에 거의 모든 인간보다 더 최적화된 솔루션을 내놓았습니다.
이것은 Claude 모델이 격파한 첫 번째 인터뷰가 아니었습니다. 저는 2023년에 초기 Claude 모델이 많은 지식을 가지고 있던 공통 작업을 기반으로 우리 당시의 질문이 쉽게 해결할 수 있었기 때문에 라이브 인터뷰 질문을 특별히 설계했습니다.
저는 지식보다 문제 해결 기술을 더 요구하는 질문을 설계하려고 했고 여전히 실제 작업에서 해결한 실제(하지만 틈새) 문제를 기반으로 했습니다.
Claude 3 Opus는 그 질문의 1부를 격파했고, Claude 3.5 Sonnet은 2부를 격파했습니다. 우리는 여전히 이것을 사용하는데, 우리의 다른 라이브 질문들도 AI에 저항하지 않기 때문입니다.
테이크홈의 경우 직접적인 해결책이 있었습니다. 문제는 누구도 4시간 내에 탐색할 수 있는 것보다 훨씬 더 깊이가 있었으므로, 저는 Claude Opus 4를 사용하여 어디서 어려움을 겪기 시작하는지 식별했습니다. 그것이 버전 2의 새로운 시작점이 되었습니다.
저는 더 깨끗한 스타터 코드를 작성하고, 더 깊이를 위해 새로운 머신 기능을 추가하고, 멀티코어(Claude가 이미 해결했고, 신호를 추가하지 않고 개발 루프만 늦추는)를 제거했습니다.
또한 시간 제한을 4시간에서 2시간으로 단축했습니다. 저는 원래 후보자들이 버그나 혼란에 잠시 갇혔을 때 침몰할 위험을 줄이는 것을 선호한다는 피드백에 따라 4시간을 선택했지만, 일정 관리 오버헤드로 인해 우리 파이프라인에 몇 주의 지연이 발생하고 있었습니다. 2시간은 주말에 넣기가 훨씬 쉽습니다.
버전 2는 디버깅과 코드 볼륨보다는 똑똑한 최적화 통찰력을 강조했습니다. 몇 달 동안 잘 작동했습니다.
Claude Opus 4.5가 그것을 격파했습니다
사전 출시 Claude Opus 4.5 체크포인트를 테스트했을 때, 저는 Claude Code가 2시간 동안 문제를 작업하며 점진적으로 솔루션을 개선하는 것을 지켜보았습니다.
초기 병목 현상을 해결하고 모든 일반적인 마이크로 최적화를 구현했으며 1시간 미만으로 우리의 합격 기준을 충족했습니다.
그런 다음 그것은 극복할 수 없는 메모리 대역폭 병목 현상에 부딪혔다고 확신하며 멈췄습니다. 대부분의 인간도 동일한 결론에 도달합니다.
하지만 병목 현상을 우회하기 위해 문제 구조를 활용하는 똑똑한 트릭들이 있습니다.
제가 Claude에게 도달할 수 있는 사이클 수를 알려주자, 잠시 생각한 후 트릭을 찾았습니다. 그런 다음 디버깅, 튜닝 및 추가 최적화를 구현했습니다.
2시간 시점에 점수는 해당 시간 제한 내의 최고 인간 성적과 일치했으며, 그 인간은 4와 함께 강력한 사용을 했습니다.
더 엄격한 테스트를 위해 내부 테스트 시간 계산 하네스에서 시도해 보았고, 2시간 안에 인간을 능가하고 시간과 함께 계속 상승할 수 있다는 것을 확인했습니다.
출시 후 우리는 하네스를 일반적인 방식으로 개선했고 더 높은 점수를 얻었습니다.
문제가 있었습니다. 우리는 테이크홈에서 최상의 전략이 Claude Code에 위임하는 모델을 출시하려고 했습니다.
옵션 고려
일부 동료들은 AI 보조를 금지할 것을 제안했습니다. 저는 그렇게 하고 싶지 않았습니다. 시행 문제 외에도, 사람들이 우리의 작업에서 계속 중요한 역할을 한다는 감각 때문에, 저는 그들이 AI가 있는 환경(직장에서처럼)에서 자신을 구별할 수 있는 방법을 알아낼 수 있어야 한다고 느꼈습니다.
저는 아직 인간이 몇 시간보다 긴 작업에서만 우위를 가진다는 생각에 굴복하고 싶지 않았습니다.
다른 사람들은 기준을 “Claude Code가 단독으로 달성하는 것을 실질적으로 능가하는 것”으로 높일 것을 제안했습니다.
여기서의 우려는 Claude가 빨리 작동한다는 것입니다. 인간은 보통 최적화를 시작하기 전에 2시간의 반을 문제를 읽고 이해하는 데 보냅니다.
Claude를 조종하려는 인간은 늘 뒤처져 있을 것 같으며, Claude가 한 일을 사후에만 이해할 것입니다.
지배적인 전략은 뒤로 물러나서 지켜보는 것이 될 수 있습니다.
오늘날 Anthropic의 성능 엔지니어들은 여전히 해야 할 많은 작업을 가지고 있지만, 더 어려운 디버깅, 시스템 설계, 성능 분석, 우리 시스템의 정확성을 확인하는 방법, 그리고 Claude의 코드를 더 단순하고 우아하게 만드는 방법을 파악하는 것처럼 보입니다.
불행히도 이러한 것들은 많은 시간이나 공통 컨텍스트 없이 객관적인 방식으로 테스트하기 어렵습니다.
직업을 대표하는 인터뷰를 설계하는 것은 항상 어려웠지만, 이제는 그 어느 때보다 어렵습니다.
하지만 저는 새로운 테이크홈을 설계하는 데 투자한다면, Claude Opus 4.5도 그것을 해결하거나, 인간이 2시간 내에 완료할 수 없을 정도로 너무 어려워질까 봐 걱정했습니다.
시도 1: 다른 최적화 문제
저는 Claude가 제가 설계하는 무엇이든 빨리 구현하는 데 도움을 줄 수 있다는 것을 깨달았고, 이는 저가 더 어려운 테이크홈을 개발하도록 동기를 부여했습니다.
저는 Anthropic에서 수행한 가장 까다로운 커널 최적화 중 하나를 기반으로 한 문제를 선택했습니다. 뱅크 충돌을 피하면서 2D TPU 레지스터에서 효율적인 데이터 전치입니다.
저는 이것을 시뮬레이션된 머신에서 더 간단한 문제로 정제했고 Claude가 하루 만에 변경 사항을 구현했습니다.
Claude Opus 4.5는 제가 생각하지도 않은 훌륭한 최적화를 찾았습니다.
신중한 분석을 통해, 데이터를 전치하는 방법을 파악하는 대신 전체 계산을 전치할 수 있다는 것을 깨달았고, 그에 따라 전체 프로그램을 다시 작성했습니다.
내 실제 경우에서는 이것이 작동하지 않았을 것이므로, 저는 문제를 수정하여 그 접근 방식을 제거했습니다.
Claude는 진전을 했지만 가장 효율적인 솔루션을 찾을 수 없었습니다.
새로운 문제가 있는 것 같았으니, 이제 인간 후보자들이 충분히 빨리 해결할 수 있기를 바랄 뿐이었습니다.
하지만 약간의 의심이 들었으므로 더 긴 생각 예산을 사용하여 Claude Code의 “ultrathink” 기능으로 이중 확인했습니다… 그리고 그것이 해결했습니다.
뱅크 충돌을 수정하는 트릭도 알고 있었습니다.
후견으로 보면, 이것은 시도할 올바른 문제가 아니었습니다.
많은 플랫폼의 엔지니어들이 데이터 전치와 뱅크 충돌로 어려움을 겪었으므로 Claude는 활용할 수 있는 상당한 훈련 데이터가 있습니다.
제가 제 솔루션을 원칙에서 찾았지만, Claude는 더 큰 경험 도구 상자에서 활용할 수 있습니다.
시도 2: 더 이상하게 가기
저는 인간의 추론이 Claude의 더 큰 경험 기반을 이길 수 있는 문제가 필요했습니다. 분포에서 충분히 벗어난 것입니다.
불행히도 이것은 직업처럼 인식될 수 있는 목표와 충돌했습니다.
저는 제가 즐겼던 가장 이상한 최적화 문제에 대해 생각했고 Zachtronics 게임에 도착했습니다.
이러한 프로그래밍 퍼즐 게임은 비정상적이고 제약이 많은 명령어 세트를 사용하여 비전형적인 방식으로 프로그래밍하도록 강제합니다.
예를 들어, Shenzhen I/O에서 프로그램은 각각 약 10개의 명령어와 하나 또는 두 개의 상태 레지스터만 보유하는 여러 통신 칩으로 분할됩니다.
똑똑한 최적화는 종종 상태를 명령 포인터나 분기 플래그에 인코딩하는 것을 포함합니다.
저는 최소 명령어 수에 대한 솔루션을 최적화하는 작고 제약이 많은 명령어 세트를 사용하는 퍼즐로 구성된 새로운 테이크홈을 설계했습니다.
저는 하나의 중간 난이도 퍼즐을 구현하고 Claude Opus 4.5에서 테스트했습니다.
실패했습니다.
저는 더 많은 퍼즐을 채우고 동료들이 저보다 문제에 덜 깊이 빠져 있는 사람들도 여전히 Claude를 능가할 수 있는지 확인했습니다.
Zachtronics 게임과 달리, 저는 고의로 시각화나 디버깅 도구를 제공하지 않았습니다.
스타터 코드는 솔루션이 유효한지 여부만 확인합니다.
디버깅 도구를 구축하는 것은 테스트되는 것의 일부입니다. 잘 만든 print 문을 삽입하거나 코딩 모델에게 몇 분 안에 대화형 디버거를 생성하도록 요청할 수 있습니다.
도구링에 투자하는 방법에 대한 판단은 신호의 일부입니다.
저는 새로운 테이크홈에 상당히 만족합니다.
더 독립적인 하위 문제로 구성되어 있으므로 원본보다 분산이 낮을 수 있습니다.
초기 결과는 유망합니다. 점수는 후보자의 과거 작업의 수준과 잘 상관되며, 제 가장 유능한 동료 중 한 명은 지금까지 어떤 후보자보다 높은 점수를 받았습니다.
저는 여전히 원본의 현실성과 다양한 깊이를 포기한 것을 슬퍼합니다.
하지만 현실성은 우리가 더 이상 가질 수 없는 사치일 수 있습니다.
원본은 실제 작업과 비슷하기 때문에 작동했습니다.
대체물은 새로운 작업을 시뮬레이션하기 때문에 작동합니다.
오픈 챌린지
우리는 무제한 시간으로 시도할 수 있는 사람을 위해 원본 테이크홈을 공개하고 있습니다.
인간 전문가는 충분히 긴 시계에서 현재 모델에 대해 우위를 유지합니다.
제출된 가장 빠른 인간 솔루션은 Claude가 광범위한 테스트 시간 계산으로 달성한 것을 실질적으로 능가합니다.
공개된 버전은 처음부터 시작하지만(버전 1처럼) 버전 2의 명령어 세트와 단일 코어 디자인을 사용하므로 사이클 수는 버전 2와 비교할 수 있습니다.
성능 벤치마크(시뮬레이션된 머신의 클럭 사이클로 측정):
- 2164 사이클: 테스트 시간 계산 하네스에서 여러 시간 후의 Claude Opus 4
- 1790 사이클: 캐주얼 Claude Code 세션에서의 Claude Opus 4.5, 약 2시간 내의 최고 인간 성적과 일치
- 1579 사이클: 테스트 시간 계산 하네스에서 2시간 후의 Claude Opus 4.5
- 1548 사이클: 테스트 시간 계산에서 2시간보다 훨씬 더 많은 시간 후의 Claude Sonnet 4.5
- 1487 사이클: 하네스에서 11.5시간 후의 Claude Opus 4.5
- 1363 사이클: 개선된 테스트 시간 계산 하네스에서 여러 시간 후의 Claude Opus 4.5
GitHub에서 다운로드하세요.
1487 사이클 미만으로 최적화하여 출시 시 Claude의 최고 성능을 능가하면 performance-recruiting@anthropic.com으로 코드와 이력서를 보내주세요.
또는 일반적인 프로세스를 통해 신청할 수 있으며, 이것은 우리의 (현재) Claude 저항 테이크홈을 사용합니다.
얼마나 오래 지속되는지 궁금합니다.
핵심 포인트
- Anthropic은 Claude 모델의 발전(Opus 4, Opus 4.5)에 따라 성능 엔지니어 채용용 테이크홈 테스트를 세 번 재설계해야 했습니다.
- 무제한 시간을 주면 여전히 인간 전문가가 현재 모델보다 우수한 성능을 발휘하지만, 제한된 시간 내에서는 인간과 최상위 AI 모델을 구별하는 데 어려움을 겪고 있습니다.
- 새로운 테이크홈은 Zachtronics 게임에서 영감을 받은 비전형적이고 제약이 많은 명령어 세트 기반 문제로, 후보자가 직접 디버깅 도구를 구축해야 하는 창의적인 접근 방식을 채택했습니다.
- 원본 테스트는 오픈 챌린지로 공개되었으며, Claude Opus 4.5의 최고 성능인 1487 사이클 미만으로 최적화하는 인간에게 채용 기회를 제공합니다.
- AI 시대의 기술적 평가는 실제 업무 현실성과 AI 저항성 사이의 균형을 찾는 새로운 접근 방식이 필요합니다.
출처: Designing AI resistant technical evaluations \ Anthropic
