Hunger beats tenure: 코딩 면접을 접고 prototype으로 사람을 고르는 Anthropic 팀

AI가 코딩 과제를 사람보다 잘 풀면 그 과제는 더 이상 사람을 가르지 못합니다. Anthropic의 Felix Rieseberg는 자기 팀 채용에서 코딩 면접을 빼고 지원자가 만든 작은 prototype에서 판단의 흔적을 봅니다. 따라 하려면 AI 사용을 허용한 과제와 항목별 채점표를 먼저 만들고 기존 직원에게 시험해 변별력을 확인해야 합니다.

요약

Felix Rieseberg는 Anthropic에서 Claude.ai와 Claude Code Desktop 개발을 이끈 엔지니어링 매니저입니다. Notion, Stripe, Slack, Microsoft를 거쳤습니다. 2026년 10월 27일 개인 블로그에 쓴 글에서 그는 자기 팀 후보자에게 더는 전통적인 코딩 면접을 보지 않는다고 밝혔습니다. 작은 React 과제 같은 시험을 이제 Claude가 대부분의 사람보다 잘 풀기 때문입니다. 그는 원래 짧은 코딩 과제를 성과를 약하게나마 예측하는 지표로 봤습니다. 그런데 팀에서 가장 큰 성과를 내는 빌더는 시험 점수와 상관없이 성과를 냈습니다. 대안으로 그는 이력서와 포트폴리오에서 작은 prototype(작동하는 시제품)을 찾습니다. 거기서 taste(무엇을 만들지 고르는 안목), empathy(사용자 입장을 읽는 감각), principled thinking(이유를 세워 판단하는 태도)을 봅니다. AI로 잘 만드는 사람을 가려내는 면접법은 아직 찾는 중이라고 덧붙였습니다.

글의 본론은 경력이 짧은 엔지니어에게 주는 조언입니다. 그가 말하는 junior는 직급이 아니라 사내 지위와 인맥이 없는 사람입니다. 그는 신참이 고참을 앞지르는 장면을 자주 본다며 “Hunger beats tenure”(의욕이 연차를 이긴다)라고 정리합니다. 근거는 둘입니다. 신참은 고참이 더는 보지 못하는 불편과 기회를 알아봅니다. 그리고 실행 비용이 낮아져서 지위가 없어도 결과물로 설득할 수 있습니다. 그래서 그는 회사의 돈 버는 목표에 붙어 과감한 아이디어 하나를 고르고 주말에 prototype으로 만들어 보이라고 권합니다. 아래에서 이 판단을 이루는 네 가지 메커니즘, 저자가 든 세 사례, 우리 조직의 채용과 신규 입사자 운영에 옮기는 방법을 차례로 봅니다.

핵심 메커니즘

Coding interview의 변별력 하락: AI가 대신하는 능력은 사람을 가르지 못한다

코딩 면접은 짧은 시간에 작은 문제를 푸는 능력을 봅니다. 이 능력이 실제 성과와 어느 정도 이어졌기에 오래 쓰였습니다. Rieseberg도 이를 약하지만 쓸모 있는 예측 지표로 평가했습니다. 그런데 Claude가 같은 과제를 대부분의 지원자보다 잘 풀면 사정이 달라집니다. 실제 업무에서는 그 부분을 AI가 맡으니, 그 능력의 차이가 성과 차이로 이어지지 않습니다. 그는 작은 React 과제를 내는 일을 어셈블리 퀴즈를 내는 일에 견줍니다. 둘 다 이제 Claude가 더 잘하는 영역이라는 뜻입니다. 남는 신호는 AI가 대신하지 못하는 쪽입니다. 무엇을 만들지 고르는 안목, 누구를 위해 만드는지 아는 감각, 왜 그렇게 만들었는지 설명하는 원칙이 여기에 들어갑니다.

언제 쓰나: AI 코딩 도구가 업무에 이미 깔린 팀의 채용 설계에 씁니다. 언제 안 쓰나: 보안 감사나 저수준 성능 작업처럼 사람이 코드를 한 줄씩 책임지는 직무에서는 기초 코딩 확인을 그대로 두는 편이 낫습니다. 작은 예시(가상): 사내 데이터 플랫폼팀이 SQL 작성 시험을 보는데 지원자 대부분이 AI로 만점을 받는다면, 그 시험은 이미 변별력을 잃은 상태입니다.

Prototype portfolio: 결과물에서 판단의 흔적을 읽는다

Rieseberg가 지금 찾는 것은 지원자가 직접 만든 작은 prototype입니다. prototype은 결과물이면서 판단의 기록이기도 합니다. 어떤 문제를 골랐는지에서 taste가 보이고 누구를 위해 만들었는지에서 empathy가 보입니다. 무엇을 빼고 무엇을 남겼는지는 principled thinking을 드러냅니다. 입력은 지원서와 포트폴리오 링크이고 처리는 이 세 가지를 읽는 일이며 출력은 면접으로 넘길지에 대한 판단입니다. 코딩 면접과 달리 AI 사용을 막지 않습니다. AI로 만들었더라도 고른 문제와 결정은 지원자의 것입니다.

언제 쓰나: 사용자 대면 제품, 사내 도구, 신사업처럼 무엇을 만들지가 성과를 가르는 직무에 맞습니다. 언제 안 쓰나: 포트폴리오를 공개하기 어려운 업계 출신 지원자만 받는 경우라면 별도 과제를 함께 둡니다(아래 기술 디테일 참고). 작은 예시(가상): 물류 회사 지원자가 배차 담당자의 엑셀 작업을 대신하는 작은 웹 도구를 만들어 왔다면, 기능 수보다 어떤 불편을 골랐는지를 먼저 봅니다.

Hunger beats tenure: 신참의 눈과 낮아진 실행 비용

신참에게는 강점과 약점이 하나씩 있습니다. 강점은 낯선 눈입니다. 고참은 익숙해진 불편을 더는 보지 못하지만 신참은 이상한 것을 바로 알아봅니다. Rieseberg는 Stripe의 Patrick Collison이 새로 온 사람에게 이상해 보이는 것을 적어 두라고 권한 일을 예로 듭니다. 조직이 순진한 신참을 꾸준히 받아들여야 한다는 James March의 1991년 논문도 인용합니다. March의 「Exploration and Exploitation in Organizational Learning」은 조직이 아는 것을 다듬는 활용(exploitation)에 치우치면 새로운 탐색(exploration)이 줄어든다고 봅니다. 신참은 이 탐색을 들여오는 통로입니다.

약점은 아무도 신참의 말을 듣지 않는다는 점입니다. 전통적인 조직에서는 아이디어가 관리자를 거쳐 올라가고 회사가 누군가의 아이디어에 걸려면 사회적 지위가 필요했습니다. 신참에게는 대개 더 빨리 실행하라는 기대만 주어졌습니다. Rieseberg는 실행이 더는 비싸지 않다는 점에서 이 벽이 약해졌다고 봅니다. 만드는 데 몇 주와 팀이 필요하던 때에는 누가 만들지를 위계가 정했습니다. 이제는 혼자 주말에 작동하는 결과물을 만들 수 있고 그 결과물이 지위를 대신해 설득합니다. 그가 주니어 개발자의 미래를 많은 사람보다 밝게 보는 이유가 여기에 있습니다.

Weekend prototype: 다섯 단계로 아이디어를 결과물로 바꾸기

저자는 신참이 따라 할 순서를 다섯 단계로 줍니다. 첫째, 백로그보다 사업 성과를 고릅니다. 엔지니어는 프로그램을 짜려고가 아니라 사업 가치를 만들려고 고용된다는 Patrick McKenzie의 2011년 주장을 따라, 회사의 돈 버는 영역에 붙으라고 합니다. 얼마나 높은 곳의 목표를 볼지는 상사의 상사가 무엇을 신경 쓰는지로 가늠합니다. 둘째, 성공하면 조직의 목표 달성 확률을 크게 올릴 과감한 아이디어를 몇 개 추립니다. 셋째, PRD나 설득 회의 대신 주말에 작동하는 prototype을 만듭니다. 넷째, 아이디어는 하나만 담습니다. 저자는 좋은 아이디어 셋을 나쁜 아이디어 스물 속에 묻지 말라고 합니다. 리더가 기회와 함께 이 사람이 이 일을 이끌 수 있다는 점을 한눈에 봐야 하기 때문입니다. 다섯째, 신참의 눈을 활용합니다. 사용자 대면 제품에서는 바깥 사용자가 느끼는 감각을, 인프라·도구 작업에서는 무엇이 ‘불가능’한지 모르는 상태를 무기로 씁니다.

통념과 다른 주장

저자가 든 사례

Notion offline mode: 확인한 적 없는 가정

상황: Rieseberg는 Notion 면접에서 offline mode 아키텍처를 설계하라는 질문을 받았습니다. 직원들은 이 질문을 불가능한 문제를 던지는 일종의 함정으로 여겼습니다. 한 일: 그는 신참답게 CEO Ivan Zhao가 페이지별 다운로드 방식에 반대할지를 직접 물었습니다. 결과: 데이터 모델이 복잡하다는 점은 사실이었지만 CEO가 반대한다는 믿음은 아무도 확인한 적이 없는 가정이었습니다. 연결: 신참의 낯선 눈(Hunger beats tenure)이 조직 안의 검증되지 않은 ‘불가능’을 드러낸 사례입니다.

Notion TV 대시보드: 1년 뒤 신참의 손에서 실현된 아이디어

상황: Rieseberg는 Notion 입사 직후 사무실에 대형 TV를 달아 실시간 대시보드를 띄우자고 제안했지만 조직 장벽에 막혀 접었습니다. 한 일: 약 1년 뒤 신입 Ji Pei가 같은 아이디어를 꺼냈습니다. Rieseberg는 잘 안 될 거라고 했지만 Pei는 이미 필요한 사람에게 물어 둔 상태였습니다. 결과: 다음 날 TV가 걸렸습니다. Rieseberg는 자신이 장애물 너머를 보지 못하는 고참이 됐다고 돌아봅니다. 연결: 같은 조직, 같은 아이디어라도 장애물을 모르는 신참이 더 빨리 실행한다는 점을 보여 줍니다.

Claude Code GUI: 주말 prototype에서 공개판까지

상황: Anthropic 안에서도 많은 사람이 Claude Code를 명령줄로만 썼습니다. 한 일: 비교적 새로 온 엔지니어 Anthony Morris와 Alice Zhao가 주말 동안 그래픽 화면 prototype을 만들었습니다. 결과: 첫 공개판이 약 8일 뒤 나왔고 저자는 Claude Code의 GUI가 큰 인기를 얻었다고 전합니다. 연결: Weekend prototype 다섯 단계 중 ‘주말 제작’과 ‘한 가지만’이 실제 출시로 이어진 사례입니다.

기술 디테일: AI를 허용한 채용 과제를 실제로 돌리려면

Prototype portfolio를 공정하게 받으려면 포트폴리오가 없는 지원자를 위한 대체 과제가 필요합니다. 이전 직장의 보안 정책 때문에 결과물을 공개하지 못하는 경력자가 많습니다. 실제 업무에서 뽑은 문제 하나를 주고 AI 도구 사용을 허용하며 작업 시간을 4시간 안팎으로 묶습니다. 지원자의 주말 시간을 공짜로 쓰지 않도록 유급 과제로 운영하는 편이 응시 폭을 넓힙니다. 문제는 정답이 하나인 알고리즘이 아니라 “누구의 어떤 불편을 풀겠는가”를 지원자가 고르게 열어 둡니다.

과제 환경은 회사가 깔아 줍니다. 지원자 개인 도구에 맡기면 조건이 제각각이라 비교가 어렵습니다. 회사가 코딩 에이전트 계정(예: Claude Code)과 빈 샌드박스 저장소를 주고 사내 데이터 대신 익명 샘플 데이터만 넣습니다. 사용 비용은 1인당 상한(가상 예시: 20달러)을 걸고 과제가 끝나면 대화 로그를 내보내는 기능을 켜 둡니다.

Coding interview의 변별력 하락을 반영하려면 결과물만 받지 말고 과정을 함께 받습니다. 제출물은 세 가지로 정합니다. 작동하는 결과물 링크, 에이전트와 나눈 대화 로그, 무엇을 고르고 무엇을 뺐는지 적은 1쪽 설명입니다. 대화 로그에서는 지원자가 AI 출력을 그대로 받아들였는지, 어디서 방향을 틀었는지, 검증을 어떻게 했는지를 봅니다.

평가 기록은 아래 같은 구조로 남기면 지원자 사이 비교와 사후 검증이 쉽습니다(가상 예시).

{
  "candidate_id": "C-2026-117",
  "task_id": "ops-dispatch-01",
  "artifacts": {"demo_url": "…", "agent_log": "…", "rationale_doc": "…"},
  "scores": {
    "problem_choice": 5,
    "user_empathy": 3,
    "principled_tradeoffs": 3,
    "focus_one_idea": 5,
    "business_link": 3
  },
  "evidence": {"problem_choice": "배차 담당자의 수기 재입력 단계를 골라 없앰"},
  "rater": "R2",
  "independent": true
}

채점 편차를 줄이려면 면접관 두 명이 서로의 점수를 보지 않고 다섯 항목을 0·3·5점으로 매깁니다. 항목별 차이가 2점 이상이면 둘이 근거를 맞춰 본 뒤 다시 채점합니다. 항목 기준은 아래처럼 둡니다(가상 예시).

항목	0점	3점	5점
problem_choice (taste)	주어진 기능 목록을 그대로 구현	실제 불편을 골랐으나 범위가 넓음	작고 날카로운 불편 하나를 고름
user_empathy	사용자가 누구인지 설명 없음	사용자를 정했으나 화면이 개발자 시각	처음 쓰는 사람이 막히지 않음
principled_tradeoffs	왜 그렇게 했는지 설명 없음	결정은 있으나 근거가 약함	뺀 것과 그 이유를 분명히 밝힘
focus_one_idea	아이디어 여럿이 섞임	중심은 있으나 곁가지가 큼	한 가지가 한눈에 보임
business_link	회사 목표와 연결 없음	연결을 말로만 설명	어떤 지표가 움직일지 제시

LLM을 보조로 쓸 때는 제출물 요약과 대화 로그 정리까지만 맡기고 점수는 사람이 매깁니다. 요약 모델은 temperature 0으로 두고 같은 제출물을 두 번 요약해 내용이 크게 다르면 원본을 직접 읽습니다. 판단 근거(evidence)는 반드시 원본에서 찾은 문장이나 화면으로 적습니다.

실패하는 경우와 대응. 모든 지원자가 비슷한 결과물을 내면 과제가 너무 닫혀 있다는 신호이니 문제 선택의 폭을 넓힙니다. 기존 고성과자가 과제에서 낮은 점수를 받으면 루브릭이 성과와 맞지 않는 것이니 항목을 다시 봅니다. 대화 로그가 너무 길면 지원자에게 핵심 장면 세 곳을 골라 표시하게 합니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당	하는 일
채용 매니저	해당 팀 리더	직무에서 AI가 대신하는 일과 사람이 판단할 일을 나눔, 과제 문제 선정
CHRO·채용팀	HR 파트너	채점표 표준화, 유급 과제 운영, 기록 보관, 공정성 점검
면접관 2명	팀 내 시니어와 최근 입사자	독립 채점과 보정 토론
CIO·CTO	기술 조직 책임자	과제에 쓸 AI 도구·샌드박스 제공, 데이터 반출 규칙

시작 전 준비물은 직무 기술서, 최근 1년 고성과자 3~5명의 실제 산출물, 과제에 쓸 수 있는 익명 데이터, 지원자가 쓸 AI 도구 계정입니다. 고성과자에게 같은 과제를 먼저 풀게 하는 것이 핵심 보정 단계입니다. 그들이 높은 점수를 받지 못하면 과제나 채점표가 틀린 것입니다.

면접에서 prototype을 두고 물을 질문은 이렇습니다(가상 예시).

• 이 문제를 왜 골랐나요? 다른 후보는 무엇이었고 왜 버렸나요?
• 처음 쓰는 사람이 가장 먼저 막힐 곳은 어디라고 보나요?
• AI가 낸 결과 중 받아들이지 않은 것은 무엇이고 이유는 무엇인가요?
• 이 결과물이 회사에서 움직일 숫자 하나를 꼽는다면 무엇인가요?
• 하루가 더 있었다면 무엇을 빼겠습니까?

진행 판정 기준(가상 예시)은 세 가지입니다. 고성과자 시험 채점에서 평균 20점 이상(25점 만점)이 나오는지, 면접관 두 명의 항목별 차이가 2점 이상 나는 비율이 20% 이하인지, 실제 채용 1건에서 기존 방식보다 판단 근거가 더 구체적으로 남는지를 봅니다. 셋 다 충족하면 다음 분기에 다른 팀으로 넓힙니다.

같은 원리는 채용 뒤에도 씁니다. 신규 입사자에게 첫 30일 동안 이상해 보이는 것을 목록으로 적게 하고(Collison 방식), 그중 하나를 골라 주말 수준의 작은 prototype으로 만들어 보게 합니다. 리더는 매달 한 번 이 결과물을 보는 자리를 만들어, 지위가 아니라 결과물로 아이디어가 올라오는 통로를 엽니다.

AX 적용 제언: 이 글의 쓸모는 개발 채용 하나에 그치지 않습니다. AI가 실무 기능을 대신하는 모든 직무에서 “우리 시험이 지금도 사람을 가르는가”를 점검하는 출발점이 됩니다. 순서는 이렇게 권합니다. 먼저 AI 도구가 이미 깔린 개발·데이터 조직 한 팀에서 위 4주 일정으로 시험합니다. 다음으로 기획·분석 직무의 엑셀·보고서 과제에 같은 원리를 옮깁니다. 마지막으로 신규 입사자 prototype 통로를 만들어, 연차 중심 승진과 아이디어 승인 관행을 함께 다시 봅니다. 현업 스폰서는 CHRO와 해당 부서장이 함께 맡는 편이 좋습니다.

원문 사례

항목	내용
저자	Felix Rieseberg, Anthropic 엔지니어링 매니저(Claude.ai, Claude Code Desktop, Cowork 개발 리드). 이전 Notion, Stripe, Slack, Microsoft
발표	개인 블로그, 2026.10.27, ‘management’ 분류. 같은 내용을 X에도 게시
바뀐 것	자기 팀 후보자에게 전통적 코딩 면접을 보지 않음
이유	Claude가 작은 React 과제를 대부분의 사람보다 잘 품. 최고 성과자는 시험 점수와 무관
대안	이력서·포트폴리오의 작은 prototype에서 taste, empathy, principled thinking 확인. 더 나은 면접법은 아직 찾는 중
조언 대상	직급이 아니라 사내 지위·인맥이 없는 엔지니어
인용한 사람	Patrick Collison(Stripe), James March(1991), Orson Welles(1960 인터뷰), Patrick McKenzie(2011)
사례	Notion offline mode 면접, Notion TV 대시보드(약 1년 뒤 Ji Pei가 실현), Claude Code GUI(Anthony Morris·Alice Zhao, 주말 prototype, 약 8일 뒤 첫 공개판)
다섯 단계	사업 성과 선택, 과감한 아이디어, 주말 제작, 아이디어 하나, 신참의 눈 활용
반응(보도)	The Register: Google 수석 엔지니어 Jaana Dogan도 코딩 면접을 거의 하지 않고 코딩 에이전트 사용 모습을 본다고 언급. ZipRecruiter 조사(고용주 1,500곳)에서 70%가 AI 부정행위를 막으려 감독형·대면 평가로 옮김

핵심 개념

junior

이 글에서는 직급이 아니라 사내 지위·인맥·영향력이 아직 없는 사람을 뜻합니다.

tenure

한 조직이나 직무에 머문 기간. 저자는 연차 중심 승진에 오래 비판적이었다고 밝힙니다.

PRD

Product Requirements Document. 만들 제품의 목적과 요구사항을 적은 기획 문서입니다.

exploration / exploitation

James March가 나눈 조직 학습의 두 방향. 새것을 찾는 탐색과 아는 것을 다듬는 활용입니다.

offline mode

네트워크가 끊겨도 앱을 쓸 수 있게 데이터를 기기에 받아 두는 기능입니다.

Claude Code

Anthropic의 코딩 에이전트. 처음에는 명령줄에서 주로 썼고 이후 그래픽 화면판이 나왔습니다.

내 메모

TODO: 내 생각 추가

원문은 Felix Rieseberg의 블로그 글 「Hunger beats tenure: Advice for junior engineers」(2026.10.27)이며 Latent Space AINews(2026.10.28)가 이 글을 다룬 것을 계기로 읽었습니다. 요약, 핵심 메커니즘의 원문 예, 통념과 다른 주장, 사례, 원문 사례 표는 저자가 언급한 내용을 AX Review가 다시 정리했습니다. 반응 항목은 The Register(2026.10.28) 보도를 따랐습니다. 메커니즘의 작은 예시, 기술·현업 실행 디테일, JSON 예시, 채점표, 질문, 일정·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했으며 그 안의 필드명과 숫자는 가상 예시입니다. March 논문의 탐색·활용 구분은 1차 출처(James G. March, 「Exploration and Exploitation in Organizational Learning」, Organization Science, 1991)로 보강했습니다. 원문 전체는 저자의 블로그에서 볼 수 있습니다.