AI 시대 기술 면접은 지금 방식 그대로 써도 될까요? AI가 take-home 과제를 뚝딱 풀어주는 현실에서, 면접이 측정하는 게 진짜 역량인지 AI 활용 능력인지 모호해졌습니다. 이 글에서 그 해답을 정리했습니다.
AI 시대 기술 면접, 지금 방식 그대로 써도 될까요?
안녕하세요! 혹시 최근 채용 과정에서 뭔가 이상하다는 느낌 받으신 적 있나요? take-home 제출물이 너무 완벽하다거나, 알고리즘 문제를 막힘 없이 풀어내는데 막상 “왜 이렇게 짰어요?”라고 물으면 말문이 막힌다거나요. 저는 솔직히 요즘 그런 상황을 주변에서 자주 듣고 있어요 😮 그러던 중 GeekNews에서 프랑스 엔지니어 Julien Danjou가 쓴 “AI 시대의 기술 면접”을 발견했는데, 단순한 의견 글이 아니라 면접의 구조 자체를 프레임워크로 분석한 글이었습니다.
GeekNews 댓글에서 jjpark78님이 “어차피 업무할 때 AI를 쓸 텐데 배제하는 건 의미가 있나? 현장에서 어떻게 AI를 쓰고 사고하는지 보는 게 더 맞지 않을까요?”라고 하셨는데, 저도 처음엔 같은 생각이었거든요. 근데 원문을 끝까지 읽고 나니 생각이 꽤 바뀌었어요. 그래서 직접 원문을 다 읽고 제 관점을 섞어 정리해봤습니다.
📌 목차
- 왜 AI 시대엔 면접 방식이 흔들리는가
- 좋은 면접의 두 가지 기준: 신호 품질 vs 회사 비용
- 면접 유형 4가지 완전 분석
- 기초 역량 vs 도구적 역량: 진짜 봐야 할 것
- AI 시대 기술 면접을 조정하는 5가지 실전 전술
- 이런 분들께 적극 추천합니다
- 자주 묻는 질문 (FAQ)
1. 왜 AI 시대엔 면접 방식이 흔들리는가
저자는 글의 첫 문장부터 도발적인 질문을 던집니다. “AI 모델과 도구가 이렇게 빠르게 진화하는데, 엔지니어가 6개월 후에도 코드를 직접 작성하거나 리뷰할까?” 2026년 현재, Mistral의 CEO Arthur Mensch는 “AI 모델은 매 12개월마다 약 1년치 소프트웨어 엔지니어링 경험을 쌓는다”고 말했어요. 이 속도라면 지금 면접에서 보는 역량들이 곧 의미 없어질 수도 있다는 거죠.
그런데 현실은 어떨까요? 저자에 따르면 대부분의 기업은 그냥 현상 유지를 택했습니다. 심지어 AI 혁명을 주도하는 Anthropic조차 take-home 채용 가이드라인에 “별도 지시가 없는 한 Claude 없이 완료하라”고 명시하고 있어요. 변화를 만들어내는 회사도 내부 채용 기준은 예전 방식을 고수하고 있다는 게 아이러니하죠.
① Brandolini의 법칙 — AI 시대 take-home의 비극
저자가 인용한 Brandolini의 법칙이 인상적이에요. “잘못된 코드를 반박하는 데 드는 에너지는 그 코드를 생산하는 데 드는 에너지보다 훨씬 크다.” AI가 take-home 과제를 몇 분 만에 그럴듯하게 풀어주면서, 비용 부담이 지원자에서 면접관으로 이동했습니다. 2026년엔 take-home 제출물 대부분이 AI로 생성되거나 최소한 AI 도움을 받았을 가능성이 높아요. 면접관만 힘들어진 구조가 된 거죠.
💡 실제 활용 시나리오 예시:
스타트업 A사가 백엔드 엔지니어 take-home으로 “간단한 REST API 구현”을 냈더니, 지원자 30명 중 27명이 완벽한 코드를 제출했어요. 면접관 3명이 주말 내내 리뷰했는데, 라이브 인터뷰에서 “이 코드 이 부분 왜 이렇게 짰어요?”라고 물으니 절반이 제대로 설명하지 못했다고 합니다.
2. 좋은 면접의 두 가지 기준: 신호 품질 vs 회사 비용
저자는 면접을 평가하는 기준을 딱 두 가지로 정리합니다. 신호 품질(Signal Quality)과 회사 비용(Cost to Company). 이 프레임이 생각보다 꽤 유용해요. 이 두 축을 기준으로 어떤 면접이 좋고 나쁜지 판단할 수 있습니다.
① Signal Quality — 진짜 실력을 얼마나 잘 잡아내는가
신호 품질이 높은 면접은 네 가지 조건을 갖춰야 해요. 준비량에 흔들리지 않아야 하고(면접 특화 준비만 열심히 한 사람이 유리하면 안 됨), 현실과 닮아야 하고(실제 업무 상황에 가까워야 함), 모두에게 공평해야 하고(유료 멘토링 받은 사람이 유리하면 안 됨), 적절히 어려워야 합니다. 여기서 핵심은 “어렵다”는 게 트릭 문제가 아니라, 저자의 표현대로 “여러 통찰이 필요한 광범위하고 모호한 문제”여야 한다는 거예요.
💡 실제 활용 시나리오 예시:
리트코드 Easy 문제는 30분 연습하면 풀 수 있어서 신호 품질이 낮아요. 반면 “트래픽이 몰리는 상황에서 결제 시스템을 설계하되, 일관성과 가용성 중 어떤 걸 선택할지 트레이드오프를 설명하라”는 문제는 단순 암기로 답하기 어렵고, 실제 사고 방식이 드러납니다.
② Cost to Company — 좋은 면접에도 비용이 든다
면접 질문 하나 만드는 데 얼마나 걸릴 것 같으세요? 저자에 따르면 초안 설계, 내외부 후보 대상 테스트, 직무·레벨별 스코어카드 작성, 면접관 교육까지 상당한 시간이 필요해요. 그리고 질문은 계속 보정되어야 하기 때문에 한 번 만들고 끝이 아닙니다. 후보 매력도도 중요한데, 너무 지루하거나 시간이 과도하게 드는 절차는 우수한 엔지니어를 떠나게 만든다는 것도 잊으면 안 돼요.
💡 실제 활용 시나리오 예시:
B사는 take-home으로 48시간짜리 프로젝트를 요구했다가 시니어 후보군의 70%가 지원을 포기하는 경험을 했어요. 반면 6시간 이하로 제한하고 명확한 가이드를 제공하니 지원율과 완성도 모두 올라갔다고 합니다.
3. 면접 유형 4가지 완전 분석
저자는 면접을 크게 4가지로 나눠요. 각각 신호 품질과 회사 비용이 다르고, AI에 대한 취약성도 다릅니다. 아래 표로 먼저 전체 구조를 파악하고 하나씩 뜯어볼게요.
| 면접 유형 | 신호 품질 | 회사 비용 | AI 취약성 |
|---|---|---|---|
| Take-home | 높음 (AI 이전) | 중간 | 매우 높음 |
| Live exercise | 중간 | 중간 | 높음 |
| Presentation | 낮음 | 낮음 | 낮음 |
| Actual work | 높음 | 높음 | 낮음 |
① Take-home — 가장 타격이 큰 유형
원래 take-home은 설계, 코딩, 디테일, 테스트까지 광범위한 신호를 줘서 신호 품질이 높았어요. 6시간 이상 투자하면 동기까지 증명할 수 있었죠. 근데 이제 AI가 몇 분 만에 그럴듯한 코드를 만들어냅니다. 문제 유출까지 되면 “AI가 강력한 코치” 역할을 하니 신호가 거의 없어지는 거예요.
💡 실제 활용 시나리오 예시:
C사 면접관이 take-home 제출물을 Claude에 붙여넣고 “이 코드 문제점 찾아줘”라고 했더니, AI가 즉시 버그 3개를 찾아냈어요. 그 코드를 쓴 지원자는 정작 라이브 면접에서 같은 부분을 설명하지 못했죠. take-home 제출 자체가 역량 검증이 아닌 AI 활용 검증이 된 상황입니다.
② Live exercise — 알고리즘, 시스템 설계 등
라이브 코딩, 알고리즘, 시스템 설계, postmortem 리뷰 등이 여기 포함돼요. “Netflix 아키텍처 설계해봐”, “rate-limiter 작성해봐” 같은 문제를 면접관 앞에서 즉석 해결하는 방식이죠. 신호 품질은 중간이지만, 제대로 설계되면 꽤 객관적이에요. AI가 위협이 되긴 하지만 실시간으로 사고 과정을 공유해야 하니 take-home보다는 덜 취약합니다.
💡 실제 활용 시나리오 예시:
시스템 설계 면접에서 “1억 명이 쓰는 실시간 채팅 서비스 설계”를 내고, 면접관이 중간에 “갑자기 메시지 순서 보장이 필요해졌어요”라고 요구사항을 바꾸면? 사전에 암기한 다이어그램이 아닌, 실제 사고 유연성을 바로 볼 수 있어요.
③ Presentation — 낮은 신호 품질의 함정
“주도한 프로젝트 설명해봐”, “아키텍처 다이어그램 그려봐” 같은 형식이에요. 회사 비용이 낮아서 많이 쓰는데, 신호 품질 실패 모드가 많습니다. 주니어라서 흥미로운 문제를 다뤄본 적이 없거나, 자신의 기여를 과장하거나, 발표는 잘하지만 실행은 못하는 경우가 여기서 걸러지지 않아요. 저자는 “다르게 했다면?”, “요건 X를 바꾸면?” 같은 회고·가설 질문을 추가하면 신호를 높일 수 있다고 해요.
💡 실제 활용 시나리오 예시:
“가장 어려웠던 기술 문제 설명해봐”라고만 하면 준비된 발표를 듣게 돼요. 하지만 “그 결정, 지금 돌아보면 뭘 다르게 했을 것 같아요?”라고 추가하면 진짜 사고 방식이 드러납니다. D사가 이 방식으로 바꾼 후 온보딩 성공률이 눈에 띄게 올라갔다고 해요.
④ Actual work — 가장 정직하지만 현실적으로 어려운 방법
1주일간 유료로 함께 일하는 방식. Linear 같은 회사가 씁니다. 신호 품질은 최고지만 회사 비용도 최고예요. GeekNews에서 roxie님이 “저한텐 1주 같이 일하기 좋은 것 같아요”라고 하셨는데, 저도 동의해요. laeyoung님이 소개한 PostHog의 ‘New Day’ 프로세스(하루짜리, 참가비로 $1,000 지급)는 훌륭한 절충안이에요. 대부분 기업엔 현실적으로 어렵지만, 스타트업이라면 충분히 시도해볼 만합니다.
💡 실제 활용 시나리오 예시:
PostHog는 지원자를 하루 초대해 실제 이슈를 함께 해결하고, 채용 여부와 관계없이 $1,000을 지급합니다. 지원자 입장에서는 회사 문화를 직접 체험하고, 회사 입장에서는 협업 방식을 볼 수 있어 서로에게 유익한 구조예요.
4. 기초 역량 vs 도구적 역량: 진짜 봐야 할 것
저자가 이 글에서 가장 강조하는 개념이 바로 Foundational Skill(기초 역량)과 Instrumental Skill(도구적 역량)의 구분이에요. 철학자 Lewis Mumford의 Tool vs Machine 개념에서 가져왔는데, AI를 단순히 명령을 따르는 기계처럼 쓰는 엔지니어와 자신의 도구로 활용하는 엔지니어를 구분해야 한다는 거예요.
① Foundational Skills — 쌓기 어렵고 오래가는 역량
기초 역량에는 원초적 지적 능력, 분산 시스템·마이크로서비스 같은 깊은 전문성, 이차적 추론 능력, 직업 윤리와 회복력 등이 포함됩니다. Peter Drucker의 말처럼 “사람은 손만 고용할 수 없다; 항상 사람 전체가 따라온다.” AI가 아무리 발전해도 이런 근본 역량은 대체하기 어렵고, 입사 후에도 빠르게 가르치기 힘들어요. 면접에서 이걸 봐야 하는 이유가 여기 있습니다.
💡 실제 활용 시나리오 예시:
“지금까지 가장 어렵게 해결한 기술적 문제가 뭔가요?”라고 물었을 때, 단순히 결과를 설명하는 사람과 “이런 트레이드오프가 있었고, 이런 이유로 이걸 선택했어요. 지금 돌아보면 이 부분은 달리할 것 같아요”라고 답하는 사람은 기초 역량의 깊이가 다릅니다.
② Instrumental Skills — 빠르게 배울 수 있는 도구 역량
프로그래밍 언어 중급 숙련도, AI 프롬프트 튜닝, 텍스트 에디터 사용법 같은 건 도구적 역량이에요. 중요하지 않다는 게 아니라 입사 후 빠르게 배울 수 있다는 거예요. 저자의 핵심 주장은 이겁니다: AI 숙련도는 도구적 역량이라 면접의 주 평가 항목이 되면 안 된다. AI가 6개월 후에 어떻게 바뀔지 모르는데, AI 프롬프팅 잘하는 사람을 뽑는 건 불안정한 기준이에요. 이것이 핵심입니다. AI 모델 자체가 계속 진화하면, 그 모델에 특화된 스킬은 금방 쓸모없어지거든요.
💡 실제 활용 시나리오 예시:
E사가 “Cursor AI 능숙하게 다루는 사람”을 채용 기준으로 내세웠다가, 6개월 후 팀이 Windsurf로 전환하면서 그 기준 자체가 무의미해진 사례가 있어요. 반면 “복잡한 시스템에서 병목을 찾아내는 능력”을 기준으로 뽑은 사람은 어떤 도구든 빠르게 활용했다고 합니다.
5. AI 시대 기술 면접을 조정하는 5가지 실전 전술
저자의 결론은 명확합니다. “면접에서 AI를 일반적으로 배제해야 한다.” 하지만 단순히 “AI 쓰지 마세요”라고 공지하는 게 아니라, 구조적 변화가 필요해요. 원문에서 제시하는 구체적인 전술 5가지를 정리해봤습니다.
1) Take-home에 라이브 후속 면접 반드시 연결하기
take-home을 완전히 없애기 어렵다면, 반드시 라이브 후속 면접으로 연결하세요. “이 코드 왜 이렇게 짰어요?”, “여기서 다른 접근법은 뭐가 있었나요?”, “트래픽이 10배 늘어나면 어떻게 될까요?” 같은 질문으로 정말 본인이 한 작업인지 확인할 수 있어요. AI가 코드를 짜줬더라도 이런 질문엔 직접 사고해야 답할 수 있으니까요. 이게 이게 생각보다 훨씬 효과적이에요.
💡 실제 활용 시나리오 예시:
F사는 take-home 제출 후 반드시 30분 코드 워크스루를 진행합니다. “이 함수에서 에러 처리 어떻게 생각하셨어요?”라는 질문만으로도 AI 작성 코드와 본인 작성 코드를 명확히 구분할 수 있었다고 해요. 실제로 리뷰 거절률이 40% 줄었습니다.
2) 코드 리뷰 능력을 별도 항목으로 평가하기
저자가 특히 강조하는 부분이에요. 리뷰 능력 평가를 별도 면접 항목으로 넣으라는 거예요. AI 계획서, postmortem 보고서, 기존 코드베이스, 제품 요구사항 문서, 시스템 아키텍처 다이어그램 등을 보여주고 “어떻게 개선하겠어요?”라고 물어보는 거죠. 이런 리뷰 문제는 만들기도 쉽고, 실제 업무와 직결되며, AI로 흉내 내기 어렵습니다. 그리고 이건 AI 시대에 오히려 더 중요한 역량이기도 해요.
💡 실제 활용 시나리오 예시:
G사는 “버그가 있는 코드 10줄”을 면접 자료로 줍니다. 지원자가 “여기 race condition 있어요”, “이 쿼리 N+1 문제 있어요”라고 말하면 실전 역량이 바로 드러나요. 리트코드 Easy보다 업무 현장과 훨씬 가까운 면접입니다.
3) 면접 문제 유출에 맞서 명확한 준비 가이드 공개하기
Glassdoor에 면접 문제가 올라오는 건 시간 문제예요. AI까지 더해지면 유출 효과가 폭발적으로 커지죠. 저자의 역설적 제안은 오히려 준비 범위를 명확히 공개하라는 거예요. “시스템 설계는 데이터베이스 중심”, “알고리즘은 그래프 문제” 이런 식으로요. 준비 범위를 알려주면 모든 지원자가 동등하게 준비할 수 있어 공평해져요. 어차피 유출될 거라면 먼저 통제권을 쥐는 겁니다.
💡 실제 활용 시나리오 예시:
H사는 채용 공고에 “면접 형식: 45분 시스템 설계(캐싱·메시지 큐 관련), 30분 코드 리뷰(Python)”를 명시해요. 지원자들이 더 잘 준비해 오고, 면접관도 일관된 기준으로 평가할 수 있어 채용 만족도가 높아졌다고 합니다.
4) 오프사이트 혹은 도구 제한 환경 만들기
화이트보드 코딩이 현실적이지 않다는 비판이 많지만, 저자는 다른 각도로 봐요. 도구를 제한한 환경의 면접은 기초 역량을 가장 직접적으로 볼 수 있는 방법이라고요. 프랑스 교육 시스템을 사례로 드는데, 계산기도 참고자료도 없이 광범위하고 모호한 문제를 푸는 시험이 130년째 이어지고 있고, 그 이유는 단 하나 — 기초 능력 평가에 초점을 두기 때문이에요. 면접관에게 화이트보드 앞에서 생각을 펼치게 하는 게 AI 시대엔 오히려 더 유효한 방식일 수 있습니다.
💡 실제 활용 시나리오 예시:
I사는 최종 면접을 오피스 현장에서 화이트보드로 진행합니다. 처음엔 “온라인이 편한데”라는 반응도 있었지만, 지원자들이 오히려 “회사가 진지하게 뽑는다는 느낌을 받았다”며 긍정적으로 반응했다고 합니다.
5) false negative를 두려워하지 말고, 온보딩을 강화하기
면접은 완벽할 수 없어요. false negative(실제로 좋은 사람을 탈락시키는 것)와 false positive(실력 없는 사람을 합격시키는 것)는 항상 존재합니다. 저자는 false negative는 어쩔 수 없지만, false positive는 명확한 온보딩과 첫 시즌 마일스톤으로 빠르게 정리할 수 있다고 해요. Warren Buffett의 말처럼 “integrity, intelligence, energy — 첫 번째가 없으면 나머지 둘이 당신을 죽인다.” 면접에서 모든 걸 걸러내려 하지 말고, 온보딩 구조를 신뢰하는 전략이 현실적입니다.
💡 실제 활용 시나리오 예시:
J사는 3개월 온보딩에 명확한 마일스톤을 설정합니다. “1달 내: 첫 PR 머지”, “2달 내: 독립적으로 이슈 해결”, “3달 내: 팀 스프린트 기여”. 이 구조 덕분에 입사 후 맞지 않는 사람을 6개월 이상 끌고 가는 일이 눈에 띄게 줄었다고 합니다.
6. 이런 분들께 적극 추천합니다
- 채용 담당자나 엔지니어링 매니저로서 기술 면접 설계를 고민하고 있는 분
- take-home 과제 평가에 시간을 너무 많이 쏟고 있다고 느끼는 면접관
- AI 도구를 면접에 허용할지 말지 결정해야 하는 HR·채용팀
- 면접 준비 중인데 AI 사용 기준이 회사마다 달라서 혼란스러운 지원자
- 신호 품질 없는 면접을 반복하다가 좋은 사람을 놓쳤던 경험이 있는 분
- 스타트업에서 빠르게 채용 프로세스를 만들어야 하는 CTO·리드 개발자
7. 자주 묻는 질문 (FAQ)
Q. 업무에서 AI를 쓰는데 면접에서 AI를 배제하는 건 모순 아닌가요?
A. 처음엔 저도 그렇게 생각했어요. 하지만 저자의 구분이 설득력 있어요. 면접은 AI 도구 활용 능력이 아니라 기초 역량을 보는 자리예요. 드라이버 면허 시험에서 내비게이션을 쓰지 않는 것과 비슷해요. 실제 운전엔 내비를 쓰지만, 시험에서는 기본 운전 능력을 봐야 하니까요. AI 숙련도는 입사 후 빠르게 배울 수 있지만, 기초 사고 역량은 쉽게 가르치기 어렵습니다.
Q. take-home을 아예 없애는 게 나을까요?
A. 반드시 없앨 필요는 없어요. 핵심은 take-home을 단독으로 쓰지 말라는 거예요. 반드시 라이브 후속 면접과 연결하세요. take-home에서 제출한 코드를 기반으로 “왜 이렇게 짰어요?”, “이 부분 다르게 할 수 있었을 것 같은데요”라는 질문을 하면, AI로 짠 코드인지 본인이 짠 코드인지 30분 안에 명확해집니다.
Q. 면접 문제가 유출됐을 때 어떻게 대응해야 하나요?
A. 막으려 하면 지고, 통제하면 이겨요. 유출된 문제는 주기적으로 교체하고, 새 문제엔 명확한 준비 범위를 공개하세요. “이번 시스템 설계 면접은 분산 캐싱 위주”라고 미리 알려주면 유출 정보로 유리해지는 사람이 없어져요. 오히려 모두가 공평하게 준비할 수 있는 환경이 만들어지고, 오래된 문제는 아예 공식 블로그에 공개해버리는 전략도 있습니다.
✍️ 글을 마치며
AI가 코드를 대신 써주는 시대에 기술 면접은 더 이상 “얼마나 빨리 코드를 짜는가”를 봐선 안 돼요. 대신 “어떻게 생각하는가”, “복잡한 상황에서 어떤 판단을 내리는가”, “무엇을 배울 수 있는가”를 봐야 하고, 그건 take-home보다 live exercise와 리뷰 능력 평가에서 더 잘 드러납니다. AI가 Pharmakon(치료제이자 독)인 것처럼, 면접에서 AI를 어떻게 다루느냐가 채용 품질을 가르는 핵심이 됐습니다.
저는 이 글을 읽고 나서 가장 먼저 take-home 후속 30분 코드 워크스루를 도입해볼 것 같아요. take-home을 없애기보다 “제출물 기반 라이브 질문”만 추가해도 신호 품질이 훨씬 높아질 거고, 비용 대비 효과가 가장 클 것 같거든요.
여러분은 어떤 부분이 가장 인상적이셨나요? 면접관이신 분은 실제로 어떻게 운영하고 계신지, 지원자이신 분은 AI 사용 기준에 대해 어떻게 생각하시는지 댓글로 자유롭게 의견 남겨주세요! 😊