AI에 흔들리지 않는 기술 평가 설계하기

Anthropic 성능 최적화 팀 리드 Tristan Hume가 작성했습니다. Tristan은 Anthropic이 수십 명의 성능 엔지니어를 채용하는 데 활용한 과제형 테스트를 설계했고, 여러 차례 재설계해왔습니다.

AI 역량이 향상될수록 기술 인재 평가는 점점 어려워집니다. 오늘날 지원자 간 실력 차이를 잘 드러내는 과제형 테스트가, 내일이면 모델이 손쉽게 풀어버려 평가 도구로서의 의미를 잃을 수 있기 때문입니다.

2024년 초부터 우리 성능 엔지니어링 팀은 가상 가속기에서 코드를 최적화하는 과제형 테스트를 사용해왔습니다. 지금까지 1,000명 이상의 지원자가 이 테스트를 완료했고, 그중 수십 명이 현재 Anthropic에서 일하고 있습니다. 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 클러스터 도입도 앞두고 있었습니다. 과거보다 훨씬 많은 비용을 가속기에 투자하고 있었지만, 늘어난 규모를 감당할 성능 엔지니어가 부족했습니다. 트위터에 글을 올려 이메일을 달라고 했더니, 기존 면접 파이프라인으로는 감당할 수 없을 만큼 많은 유망한 지원자가 몰려왔습니다. 기존 면접 과정은 재직자와 지원자 모두에게 상당한 시간을 요구하는 구조였기 때문입니다.

더 효율적인 평가 방법이 필요했습니다. 그래서 2주 동안 직접 과제형 테스트를 설계했습니다. 이 직무가 실제로 요구하는 역량을 충분히 반영하면서도, 가장 뛰어난 지원자를 가려낼 수 있는 테스트를 목표로 했습니다.

설계 목표

과제형 테스트는 평판이 좋지 않습니다. 대부분 뻔한 문제로 채워져 있어 엔지니어들은 지루해하고, 필터로서의 기능도 떨어집니다. 제 목표는 달랐습니다. 지원자가 참여하고 싶어질 만큼 흥미로운 과제를 만들되, 높은 해상도로 기술 역량을 포착할 수 있어야 했습니다.

성능 엔지니어링 역량을 평가하는 데 있어, 이 형식은 실시간 면접 대비 몇 가지 장점이 있습니다:

충분한 시간: 엔지니어가 실무에서 1시간 이내에 코드를 완성해야 하는 경우는 거의 없습니다. 4시간(이후 2시간으로 단축)이라는 시간은 실제 업무 특성을 더 잘 반영합니다. 실제 작업에 비하면 여전히 짧지만, 지원자의 부담과 균형을 맞춰야 합니다.

현실적인 환경: 누가 지켜보거나 설명을 요구하지 않습니다. 지원자는 자신의 에디터에서 방해 없이 작업할 수 있습니다.

이해와 도구 구축을 위한 시간: 성능 최적화는 기존 시스템을 이해하고 때로는 디버깅 도구를 직접 만들어야 합니다. 50분짜리 일반 면접으로는 이를 현실적으로 평가하기 어렵습니다.

AI 보조 도구와의 호환: Anthropic의 일반 지원자 가이드라인에서는 별도 안내가 없는 한 과제형 테스트에서 AI를 사용하지 말 것을 권장합니다. 이 과제에서는 명시적으로 AI 사용을 허용합니다.

시간이 긴 문제일수록 AI가 완벽하게 풀기 어렵기 때문에, 지원자가 실무에서처럼 AI 도구를 활용하면서도 자신의 역량을 보여줄 수 있는 구조입니다.

이러한 형식별 목표 외에도, 면접 설계 시 항상 적용하는 원칙들을 과제형 테스트에도 반영했습니다:

실제 업무의 반영: 문제를 통해 이 직무가 실제로 어떤 일을 하는지 감을 잡을 수 있어야 합니다.

높은 신호: 하나의 핵심 통찰에 좌우되는 문제는 피하고, 지원자가 자신의 역량을 충분히 드러낼 기회를 여러 차례 제공해야 합니다. 운에 의한 변수를 최소화하고, 점수 분포가 넓어야 하며, 뛰어난 지원자도 모든 문제를 끝낼 수 없을 만큼 깊이가 있어야 합니다.

특정 도메인 지식 불필요: 기초가 탄탄한 사람이라면 세부 지식은 입사 후에 배울 수 있습니다. 좁은 전문성을 요구하면 지원자 풀만 불필요하게 제한됩니다.

재미: 빠른 개발 루프, 깊이 있는 흥미로운 문제, 그리고 창의성을 발휘할 여지가 있어야 합니다.

가상 머신

TPU와 유사한 특성을 갖는 가상의 가속기를 Python 시뮬레이터로 구현했습니다. 지원자는 이 머신에서 실행되는 코드를 최적화하며, 모든 명령어를 보여주는 핫 리로딩 방식의 Perfetto 트레이스를 활용합니다. Trainium에서 사용하는 도구와 유사한 방식입니다.

이 머신에는 가속기 최적화를 흥미롭게 만드는 여러 특성이 포함되어 있습니다. 수동 관리 방식의 스크래치패드 메모리(CPU와 달리 가속기는 명시적 메모리 관리가 필요한 경우가 많습니다), VLIW(매 사이클마다 여러 실행 유닛이 병렬로 동작하며 효율적인 명령어 패킹이 필요), SIMD(명령어 하나로 다수 요소에 대한 벡터 연산 수행), 그리고 멀티코어(여러 코어에 작업 분산)가 그것입니다.

과제는 병렬 트리 순회(parallel tree traversal)로, 의도적으로 딥러닝 느낌을 배제했습니다. 대부분의 성능 엔지니어가 아직 딥러닝 경험이 없었고, 도메인 지식은 입사 후 배울 수 있기 때문입니다. 이 문제는 고전적 ML 최적화 과제인 branchless SIMD 결정 트리 추론에서 영감을 받았습니다. 과거에 대한 오마주이기도 한 이 문제를 이전에 접해본 지원자는 극소수였습니다.

지원자는 완전히 직렬화된 구현에서 시작하여 점진적으로 머신의 병렬성을 활용해 나갑니다. 워밍업은 멀티코어 병렬화이고, 그 후에는 SIMD 벡터화와 VLIW 명령어 패킹 중 원하는 방향을 선택합니다. 초기 버전에는 먼저 수정해야 하는 버그도 포함되어 있어, 도구를 직접 만들어 디버깅하는 역량도 평가할 수 있었습니다.

초기 결과

처음 만든 과제형 테스트는 잘 작동했습니다. 트위터를 통해 유입된 지원자 중 한 명이 다른 모든 지원자를 크게 앞서는 점수를 받았습니다. 그는 기존 파이프라인을 통한 첫 채용자들이 합류한 지 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시간이 되었을 때 점수는 같은 시간 제한 내 최고 인간 성과와 동일한 수준이었습니다. 그런데 그 사람도 Claude 4의 도움을 적극 활용한 결과였습니다.

더 엄밀한 검증을 위해 내부 테스트 타임 컴퓨트 하니스에서도 실행해봤고, 2시간 내에 사람을 이기는 것은 물론 시간이 지날수록 점수가 계속 올라감을 확인했습니다. 출시 후에는 하니스를 범용적으로 개선해 더 높은 점수를 얻기도 했습니다.

문제가 생겼습니다. 곧 출시될 모델에서 과제형 테스트의 최적 전략이 "Claude Code에 위임하기"가 되는 상황이었습니다.

선택지 검토

일부 동료들은 AI 보조를 금지하자고 제안했습니다. 저는 그렇게 하고 싶지 않았습니다. 집행의 어려움을 차치하더라도, 사람이 여전히 우리 업무에서 핵심적인 역할을 하는 이상, 실무와 마찬가지로 AI를 사용할 수 있는 환경에서도 스스로를 차별화할 수 있는 방법이 분명히 있을 거라는 직감이 있었습니다. 사람의 우위가 몇 시간 이상의 작업에서만 존재한다는 생각에 아직 항복하고 싶지 않았습니다.

다른 동료들은 "Claude Code 단독 결과를 크게 상회하는 수준"으로 기준을 올리자고 했습니다. 문제는 Claude의 작업 속도입니다. 사람은 보통 2시간 중 절반을 문제를 읽고 이해하는 데 씁니다. Claude를 조종하려는 사람은 Claude가 한 일을 사후에야 파악하며 끊임없이 뒤처질 가능성이 높습니다. 결국 지배 전략이 "가만히 앉아서 지켜보기"가 될 수도 있다는 우려였습니다.

현재 Anthropic의 성능 엔지니어에게는 여전히 할 일이 많지만, 그 일의 성격은 달라졌습니다. 까다로운 디버깅, 시스템 설계, 성능 분석, 시스템의 정확성을 검증하는 방법 모색, 그리고 Claude의 코드를 더 간결하고 우아하게 만드는 방법 탐구가 주된 업무입니다. 안타깝게도 이런 역량은 충분한 시간이나 공유된 맥락 없이는 객관적으로 평가하기가 매우 어렵습니다. 실제 업무를 반영하는 면접을 설계하는 건 원래도 어려웠지만, 지금은 그 어느 때보다 어려워졌습니다.

새로운 과제를 설계하는 데 투자하더라도, Claude Opus 4.5가 그것마저 풀어버리거나, 아니면 난이도를 높인 나머지 사람이 2시간 안에 풀 수 없는 문제가 될까 봐 걱정이었습니다.

시도 1: 다른 종류의 최적화 문제

Claude를 활용하면 제가 설계한 것을 빠르게 구현할 수 있다는 점을 깨닫고, 더 어려운 과제를 만들어 보기로 했습니다. Anthropic에서 수행했던 까다로운 커널 최적화 중 하나를 기반으로 문제를 선정했습니다. 뱅크 충돌(bank conflict)을 피하면서 2D TPU 레지스터에서 효율적인 데이터 전치(transposition)를 수행하는 문제였습니다. 이를 시뮬레이션 머신 위의 더 단순한 문제로 정제한 뒤 Claude에게 구현을 맡겼더니, 하루도 안 되어 완성되었습니다.

Claude Opus 4.5는 제가 미처 생각하지 못한 훌륭한 최적화 방법을 찾아냈습니다. 면밀한 분석을 통해 데이터를 전치하는 대신 연산 자체를 전치할 수 있다는 사실을 파악하고, 프로그램 전체를 그에 맞게 다시 작성한 것입니다.

실제 제 경우에는 이 접근법이 통하지 않았기 때문에, 해당 방식을 사용할 수 없도록 문제를 수정했습니다. 그러자 Claude는 어느 정도 진전을 보였지만, 가장 효율적인 해법까지는 도달하지 못했습니다. 새로운 과제가 완성된 것 같았고, 이제 지원자들이 충분히 빠르게 풀 수 있기를 바라기만 하면 됐습니다. 하지만 찜찜한 느낌이 있어서 Claude Code의 "ultrathink" 기능으로 더 긴 사고 예산을 주고 다시 시도해 봤더니... 풀어버렸습니다. 뱅크 충돌을 해결하는 트릭까지 알고 있었습니다.

돌이켜 보면, 이건 적절한 문제가 아니었습니다. 여러 플랫폼의 엔지니어들이 데이터 전치와 뱅크 충돌 문제로 오랫동안 씨름해 왔기 때문에, Claude가 활용할 수 있는 학습 데이터가 상당했던 것입니다. 저는 기본 원리에서 출발해 해법을 찾았지만, Claude는 훨씬 광범위한 경험의 도구 상자를 활용할 수 있었습니다.

시도 2: 더 특이한 방향으로

Claude의 방대한 경험 기반보다 인간의 추론 능력이 유리한 문제가 필요했습니다. 분포에서 충분히 벗어난(out of distribution) 문제여야 했죠. 안타깝게도 이 조건은 실제 업무와 유사해야 한다는 목표와 충돌했습니다.

가장 독특하면서도 재미있었던 최적화 문제들을 떠올리다 Zachtronics 게임에 착안했습니다. 이 프로그래밍 퍼즐 게임들은 특이하고 극도로 제한된 명령어 집합을 사용해 비관습적인 방식으로 프로그래밍하도록 강제합니다. 예를 들어 Shenzhen I/O에서는 프로그램이 서로 통신하는 여러 칩에 분산되며, 각 칩은 하나 혹은 두 개의 상태 레지스터와 약 10개 남짓한 명령어만 담을 수 있습니다. 영리한 최적화를 위해서는 명령어 포인터나 분기 플래그에 상태를 인코딩하는 기법이 필요합니다.

극도로 제약된 소규모 명령어 집합을 사용하는 퍼즐들로 구성된 새로운 과제를 설계했습니다. 목표는 최소 명령어 수로 솔루션을 최적화하는 것이었습니다. 중상 난이도의 퍼즐 하나를 구현한 뒤 Claude Opus 4.5에 테스트했더니, 실패했습니다. 퍼즐을 더 추가한 후 동료들에게 검증을 부탁했고, 이 문제에 저만큼 익숙하지 않은 사람도 여전히 Claude보다 좋은 성적을 낼 수 있음을 확인했습니다.

Zachtronics 게임과 달리, 시각화나 디버깅 도구는 의도적으로 제공하지 않았습니다. 스타터 코드는 솔루션의 유효성 검사만 수행합니다. 디버깅 도구를 직접 만드는 것 자체가 평가 대상입니다. 잘 설계된 print문을 삽입해도 되고, 코딩 모델에게 몇 분 만에 인터랙티브 디버거를 생성하도록 요청해도 됩니다. 도구 구축에 어떻게 투자할지 판단하는 능력 자체가 평가 요소인 셈입니다.

새로운 과제에 나름 만족하고 있습니다. 독립적인 하위 문제가 여럿 포함되어 있어 기존 과제보다 분산(variance)이 낮을 수 있습니다. 초기 결과도 긍정적입니다. 점수가 지원자의 과거 이력 수준과 잘 상관되며, 제가 아는 가장 뛰어난 동료 중 한 명이 지금까지의 어떤 지원자보다 높은 점수를 받았습니다.

기존 과제가 가진 현실성과 다양한 깊이를 포기한 건 여전히 아쉽습니다. 하지만 현실성은 이제 누릴 수 없는 사치가 되었는지도 모릅니다. 기존 과제는 실제 업무를 닮았기에 효과적이었습니다. 새 과제는 생소한 업무를 시뮬레이션하기에 효과적입니다.

오픈 챌린지

기존 과제를 시간 제한 없이 누구나 도전할 수 있도록 공개합니다. 충분히 긴 시간이 주어지면 인간 전문가는 현재 모델에 비해 여전히 우위를 유지합니다. 역대 가장 빠른 인간 제출 기록은, Claude가 대규모 테스트 시점 연산을 투입하고도 달성한 결과를 크게 상회합니다.

공개 버전은 처음부터 시작하는 방식(버전 1과 동일)이지만, 버전 2의 명령어 집합과 단일 코어 설계를 사용하므로 사이클 수는 버전 2와 비교할 수 있습니다.

성능 벤치마크 (시뮬레이션 머신의 클럭 사이클 기준):

• 2164 사이클: Claude Opus 4 — 테스트 시점 연산 하네스에서 수 시간 소요
• 1790 사이클: Claude Opus 4.5 — 일반적인 Claude Code 세션에서 달성, 인간 최고 기록(2시간 기준)과 거의 동등
• 1579 사이클: Claude Opus 4.5 — 테스트 시점 연산 하네스에서 2시간 소요
• 1548 사이클: Claude Sonnet 4.5 — 테스트 시점 연산에 2시간 이상 대폭 초과 소요
• 1487 사이클: Claude Opus 4.5 — 하네스에서 11.5시간 소요
• 1363 사이클: Claude Opus 4.5 — 개선된 테스트 시점 연산 하네스에서 수 시간 소요

GitHub에서 다운로드하세요. 출시 시점 Claude 최고 기록인 1487 사이클 미만으로 최적화에 성공하셨다면, [email protected]으로 코드와 이력서를 보내 주세요.

또는 현재 Claude가 풀지 못하는 새로운 과제를 사용하는 일반 채용 프로세스로 지원하실 수도 있습니다. 이 과제가 얼마나 오래 버틸지, 저희도 궁금합니다.