엔지니어의 취업과 성장을 위한 멘토링을 운영하고 있습니다. 많은 관심 바랍니다 🙇♂️
서론
코딩테스트를 생각한다면 해리포터의 디멘터가 떠오른다. 디멘터란 곁에 있는 것만으로도 무력감과 심리적 위축을 주는 대표적인 허구의 생물이라고도 할 수 있는데, 내게 코딩테스트가 이와 비슷하다. 주변 동료와도 코딩테스트 관련 이야기를 나누다 보면 이따금 답답해하고 숙연해지는 경우가 많았는데 이로 보아, 아마도 나뿐 아니라 다른 이들도 그렇게 느낄 확률이 크다고 생각한다.
코딩테스트는 모두에게 평등하다. 적어도 개발자 취업 시장을 본다면 경력/스택/학벌/출신 상관없이 (면접관을 제외하면) 모두에게 부담을 주는 도구라고 볼 수 있는데, 필자가 존경하고 대단하다고 생각하는 동료와 선배, 천재 주니어들도 코딩테스트 앞에선 종종 무너지기 일쑤였으며, 그 대단한 Homebrew의 창시자 Max Howell와 Rails의 창시자 DHH 역시 코딩테스트의 벽 앞에 심히 좌절하곤 했다.
코딩테스트는 준비하는 잠깐만 잘하다 까먹는 점에서 휘발성 메모리와 같다. 대중없이 빠르게 쌓인 알고리즘 지식은 곧 현업의 복잡한 문제를 맞딱드리다 보면 전원 공급(Capacitor Recharge)이 중단되어 휘발되기 마련이며, 몇 안 남은 지식도 현업의 백로그앞에 가비지 컬렉팅( Garbage Collection)될 가능성이 높다.
이토록 불편했던 코딩테스트가 기존 전통적 한계와 더불어, AI의 등장으로 곧 사라질 것 같다고 조심스럽게 주장해본다. 그리고 이후 본론 부터는 코딩테스트를 매번 쓰자니 귀찮아서 “코테”라고 지칭하겠다.
개인적인 생각과 양심고백
앞서 코테에 대하여 한껏 쫄아 아쉬운 표현을 나열했지만, 필자는 과거 코테에 상당히 자신이 있었고 긍정적으로 생각했다. 대회에서 수상할 실력은 결코 아니었겠지만, 과거 글로벌 게임사에 입사했을땐 코테 점수 1등으로 입사했었으며, 그곳에서 당시(2016년) 선진 문물인 LeetCode 도입을 적극 제안하기도 했다. O2O 스타트업에 재직할 당시엔, 팀의 매니저로서 글로벌 추세에 맞게 코테를 도입하는 것이 팀의 경쟁력을 도모하는 일이라 판단하여, 반대에도 불구하고 부분적으로 도입하기도 했었다. 그러나 이러한 코테에 대한 좋았던 인식은 긴 시간 아주 점진적으로 변화되었다.
필자는 지난 8년 동안 스타트업씬에서 개발자를 채용하고 팀을 빌딩 해왔다. 면접관으로 참여한 면접만해도 족히 천명정도는 될 것이며, 직접 채용한 사람도 (지금 세어보니) 50명 정도는 되는것 같다. 이 기간동안 꾸준히 느껴온 후 나름대로 결론내린 생각이 있는데 “코테를 통해 검증하려는 능력 혹은 기대했던 능력들이 현업에서 좀처럼 발휘가 잘 안된다는 사실”이었다.
그럼에도 불구하고 코테를 가장 중요한 전형의 1단계로 오랫동안 유지했던 이유는 다른 “선진 조직들이 하기 때문”이라는 이유가 가장 비중이 컸으며 “그들이 하는데 다 이유가 있겠지” 하는 나이브한 생각으로 장시간 정당화되어 왔던 것 같다. 그 외에도 수없이 쏟아지는 이력서를 필터링하는 단순 허들로서도 의미가 있었겠지만, 그것의 저의는 지원자의 능력을 제대로 검증하기 위함보단, 우리 팀의 기술적 자존감을 세우기 위함도 이었으며 그외에도 면접관으로서 기술적 권위를 의도적으로 세우려는 얄팍함도 약간은 있었다. (솔직히 조금의 귀찮음도 있었다 😇)
코딩 테스트의 전통적 한계
AI가 도래하기 이전부터 많은 이들이 알고리즘/자료구조 기반 코딩테스트의 한계와 문제점에 대해서 누누이 지적해왔다. 이를 하나씩 읽어보고 취합해 본 결과, 논리학에서 이야기하는 타당성의 문제로 적당히 분류할 수 있었다.
<내용 타당도의 문제> 검증하려는 하는 역량을 잘 대변하는가?
코테에서 필요한 능력이 실제 직무 역량을 대변하지 못한다는 관점인데 실제 업무는 변화무쌍한 환경에서 레거시 코드를 읽고, 디버깅하며, 동료와 협업하는 과정이지만, 코테에서 필요하는 역량은 제한된 시간 내에 고립된 환경에서 정답이 정해진 '퍼즐'을 푸는 것에 가깝다는 지적이다. 둘 사이엔 인과는 커녕 상관관계로봐도 관계가 그리 밀접해 보이지 않는다.
이 문제를 더 잘 설명 하기 위해 고차원적인 설명을 덧붙이거나 논문까지 볼 필요도 없을 것 같다. 코딩 테스트 서비스를 세계에서 가장 잘 팔고 있는 Hanker Rank의 최근 리포트에선 전체 엔지니어 중 “약 77%의 엔지니어는 코딩테스트의 역량과 실제로 필요한 직무 역량과는 차이”가 있다고 응답했다. 이는 나뿐만 아니라 대부분의 엔지니어가 암묵적으로 동의하는 컨센서스라고 봐도 무리가 아니다. 이는 내용상으로 타당성이 떨어진다는 내용 타당도 문제에 속한다.
<구성 타당도의 문제> 검증하려는 하는 역량을 제대로 평가하고 있는가?
가장 저명한 소프트웨어 학술 컨퍼런스인 FSE에 등재된 논문 Does Stress Impact Technical Interview Performance? (Behroozi et al., 2020)에선, 실제 개발자들을 대상으로 한 실험에서, 시간제한이 있는 상황에서 면접관이 지켜보는 공개 코딩(Public) 환경과 혼자 푸는 비공개(Private) 환경을 비교했으며, 시간제한이 있는 상황에서 면접관이 지켜보는 것만으로도 참가자의 퍼포먼스가 절반 이하로 떨어졌다는 것이 실험적으로 확인된다. 특히, 비공개 환경에서는 전원 통과했던 내향적 참가자들이 공개 환경에서는 전원 탈락하는 극단적인 결과가 나타나기도 했다.
이로 보아, 제한 시간이 빡빡하거나 면접관이 라이브로 감시하는 제도를 코테를 운영한다면, 지원자의 기술 역량보단 “사회적 불안(Social Anxiety) 상황에서의 수행 능력”을 측정한다고 보는 편이 더 적합하다.
마이크로소프트에도 기재된 논문 Behroozi et al. (2019), “Hiring is Broken: What Do Developers Say About Technical Interviews? dptj 에선, 코테가 무엇보다 “객관적”인 것처럼 보이지만 문제 선정과 평가 단계에서 제공자 측의 편향이 강하게 개입되어 제대로 된 직무 역량 평가가 어렵다는 것을 지적하면서 동시에, 코테를 준비하는 지원자들은 직무 역량 혹은 실무 응용과 전혀 상관없는 방법인 단순 암기로 이를 준비하고 있다는 문제 또한 지적하고 있다.
위 두가지 문제 모두 검증하려고 하는 역량을 올바른 방법으로 검증하지 못하는 전형의 구성과 방식의 문제 즉, 구성 타당도의 문제라고 말할 수 있다.
<예측 타당도의 문제> 코테 점수가 높은 사람이 실제 직무 성과도 좋았는가?
Google의 부사장(SVP)이었던 Laszlo Bock은 뉴욕타임스(NYT)와 본인의 저서 Work Rules!에서 "구글이 수십 년 동안 수집한 데이터를 분석한 결과, 난해한 알고리즘 문제나 기이한 퍼즐(Brainteasers)의 점수는 지원자의 입사 후 직무 성과와 '상관관계가 0(zero correlation)에 가깝다"고 밝혔다.
또한 HR SaaS이자 빅 데이터기업인 Evolv는 The Atlantic에 기고한 They're Watching You at Work이라는 아티클에서 “채용 과정에서 실시한 기술 스크리닝 테스트(유사 코딩 테스트 등)의 점수는 입사 후 재직 기간(Retention)이나 생산성(Productivity)과 유의미한 상관관계가 없다”고 밝혔다.
이 두 가지의 사례는 코테의 고득점자와 직무 성과가 유의미한 관계가 없다는 예측 타당도의 문제를 지적하고 있다.
위 “코테의 전통적 한계”에 대한 내용을 압축 요약하면 다음과 같다.
- 코테는 기대하는 역량을 제대로 대변하지 못하며 (내용 타당도의 문제)
- 코테는 기대하는 역량을 제대로 평가하지도 못하고 (구성 타당도의 문제)
- 뽑고나서 보니 코테를 잘하는 것과 기대 역량과는 상관이 없다. (예측 타당도의 문제)
전반적으로 코테에 대하여 부정 편향을 가득 앉고 글을 쓰는 느낌이 들긴 하지만, 필자는 복잡한 알고리즘 및 자료구조에 대한 지식 자체를 깎아내리려는 의도는 전혀 없다. 해당 지식들이 컴퓨터 공학을 이루는 근간이자 우리가 다루고 있는 엔지니어링의 코어라는 것에서 격하게 공감하고 있으며, 불과 얼마 전까지도 동료 엔지니어와 어떤 기능에서 동작하는 “LRU 캐시 내 TTL 문제”를 두고 깊이 있는 논의를 나누기도 했었다.
알고리즘과 자료구조 역량이 매우 중요한 퀀트매매 개발자, 컴파일러 개발자, 오픈소스 컨트리뷰터, 그외 모든 참 개발자들에겐 여전히 전통적인 방식의 코테가 기대 역량을 효과적으로 검증할 수 있는 수단이 될 수 있다.
AI 시대의 코딩테스트의 한계
위 설명한 코테의 타당성 문제들은 AI 시대 이전부터 언급되어 온 전통적인 관점에서의 한계들이다. 아래 내용부턴 이 글의 본격적인 주제인 “AI 등장 이후 기존 전통적 한계와 합쳐져서 코딩 테스트가 얼마나 무용해졌는지”를 본격적으로 주장해 보겠다.
망가진 도구
불과 얼마전 Interview Coder와 Cluely라는 충격적인 도구가 출시되어 업계를 뒤흔든 적이 있다. 이 도구들은 대놓고 “감지 불가능”이라는 특장점으로 내세워 코드 테스트를 해킹한다. OS 레벨에서 오버레이를 띄워 코칭을 해주기 때문에, LeetCode와 CodePad 류의 브라우저 기반의 감독 시스템으로선 이를 방어할 방도가 없다. 대부분의 경우 감독관은 이 도구가 실행되고 있는지조차 인지하지 못하는 상태에서 지원자의 풀이에 흡족해하며 합격을 준다고 한다.
또한 HankerRank의 CEO Vivek Ravisankar는 The State of AI Engineer Hiring: Cheating, AI Adoption,Junior Devs 라는 최근 인터뷰 영상에서 치팅을 막으려는 시도가 "끝없는 두더지 잡기(Whac-A-Mole)"이며, 사실상 승산이 없음을 인정했다. 그는 문제를 유출하거나 AI를 쓰는 것을 '막는(Prevent)' 것이 아니라, 어떻게 평가할 것인가로 패러다임을 전환해야 한다고 공식적으로 언급했다.
Interview Coder가 발견한 Hacker Rank의 방어 시스템에 대한 이 아티클을 보고있노라면 Vivek Ravisankar가 왜 승산이 없다고 했는지 어느정도 납득할 수 있다.
이러한 어뷰징은 쉽게 예상할 수 있듯 “변별력 상실”이라는 문제를 낳고 역량 미달의 사람을 뽑는 채용 실패로 이어지며, 결국 팀의 실패로 이어질 수 있는 심각한 문제를 야기할 수 있다.
직접 코딩의 종말
얼마 전 작성했던 “개발자는 언제쯤 AI에게 대체될까?”라는 아티클에서 급변하고있는 소프트웨어 엔지니어의 역할에 대해 이야기해 본 적이 있다. 모든 개발자는 머지않아 SWE Agent(자율형 엔지니어 에이전트)를 감독하는 역할을 맡을 수 있고, AI Model(as Software)을 운영/감독하거나 이 모든 것들의 법무 책임자가 되어있을 수 있다. 아니면 Product Builder가 되어 있을 수도 있겠다. 미래에 대해서 누구도 확실하게 단언할 순 없겠지만, 어떤 역할을 하든 간에 직접 코딩하여 기능을 구현하고 디버깅하는 일은 안 하고 있을 가능성이 높다.
누군가는 이러한 주장들이 소수의 의견이거나 주관적 견해에 불과하다고 여기겠지만, 시간이 지날수록 확고해지는 저명한 기관과 인사들의 코딩 종말론(AI 대망론)을 듣고 있노라면, 단순 소수의 의견이라고 치부하긴 어렵다. 이런 흐름은 점차 직접 코딩하는 시대를 끝낼 것이며, 그때 지금의 코딩테스트는 설득력이 많이 부족할 것이다.
| 시기 | 발언자 / 소속 | 핵심 발언 (요약) | 원문 링크 |
|---|---|---|---|
| 2025.10 | GitHub(Universe 2025) | "개발자는 이제 '시스템 사상가(System Thinkers)'다. AI가 코딩을 수행하는 동안, 인간은 전체 시스템의 아키텍처와 흐름을 통제하는 역할로 전환되었다." | GitHub Blog |
| 2025.09 | Gartner(AI Code Assistant MQ) | "2028년에는 엔지니어의 75%가 AI 코딩 에이전트를 사용할 것이며, 단순 코딩 업무는 AI에게 위임되고 인간은 감독자(Supervisor) 역할로 재배치될 것이다." | Gartner MQ Report |
| 2025.08 | Thomas Dohmke(GitHub CEO) | "개발자라는 정체성의 혁명이 일어났다. 이제 코딩은 더 이상 인간만의 전유물이 아니다. AI를 받아들이지 않는 개발자는 설 자리를 잃을 것이다." | Thaki Cloud Blog |
| 2025.07 | Andrew Ng(AI Fund) | "우리는 이제 AI 에이전트와 협업하여 '코딩'이 아닌 '애플리케이션 구축'을 하는 시대로 진입했다. 속도가 아닌 '워크플로우 설계'가 핵심 경쟁력이다." | YouTube (AI Fund) |
| 2025.05 | Demis Hassabis(Google DeepMind CEO) | "AI의 발전 속도는 산업혁명보다 10배 빠르다. 코딩 능력은 AI가 가장 먼저 정복한 영역이며, 인간은 이제 더 높은 차원의 창의적 문제 해결에 집중해야 한다." | The Guardian |
| 2025.04 | Satya Nadella(Microsoft CEO) | "현재 마이크로소프트 코드의 30% 이상이 AI에 의해 작성되고 있다. 우리는 개발자가 AI와 짝을 이뤄 생산성을 극대화하는 새로운 패러다임을 목격하고 있다." | CNBC |
| 2025.04 | Jensen Huang(NVIDIA CEO) | "프로그래밍 언어를 배울 필요가 없다. 가장 강력한 프로그래밍 언어는 이제 영어(English)다. 누구나 AI와 대화하며 소프트웨어를 만들 수 있다." | Tom's Hardware |
| 2025.02 | Sam Altman(OpenAI CEO) | "코딩은 AI가 가장 잘하는 분야 중 하나가 되었다. 미래의 개발자는 코드를 작성하는 사람이 아니라, AI에게 무엇을 만들지 지시하는 기획자에 가까워질 것이다." | Lex Fridman Podcast |
| 2025.01 | François Chollet(Keras 창시자) | "소프트웨어 엔지니어링 2.0 시대다. 더 이상 문법(Syntax)을 고민할 필요가 없다. 데이터의 흐름과 시스템의 논리적 구조를 설계하는 것이 유일한 과제다." | Chollet Blog |
| 2025.01 | Mustafa Suleyman(Microsoft AI CEO) | "AI는 단순한 도구가 아니다. 코딩의 주도권은 이미 AI로 넘어갔으며, 인간은 AI가 생성한 결과물을 검증하고 통합하는 역할로 이동했다." | LinkedIn Post |
지금까지 나온 내용을 정리해 보면, 코딩 테스트는 오래전부터 타당성의 문제를 지니고 있었기에 그 필요성을 꾸준히 의심 받아왔으며 AI의 등장으로 근본의 가치가 훼손되어 조만간 사라지게 될 가능성이 높다. 적어도 제한된 환경에서 알고리즘 문제를 푸는 지금의 형식은 확실히 사라질 것이다.
코딩 테스트의 최근 흐름
최근 1년 동안 개발자 채용을 위해 알고리즘, 자료구조 기반의 코딩테스트를 운영하다 이에 한계를 느껴, 다른 방식으로 전환한 사례는 쉽게 찾아볼 수 있었다.
GitLab
형상관리도구로 시작하여 DevSecOps 플랫폼으로 진화한 GItLab은 기존에 시행하던 알고리즘, 자료루조 기반의 코딩테스트와 구두형 CS 인터뷰를 새로운 방식으로 전환했던 대표적인 기업이다. 자사 블로그에 남긴 The trouble with technical interviews? They aren't like the job you're interviewing for 아티클을 보면 기존 전형의 두 가지 문제점을 비꼬았다.
- 시니어보단 준비할 시간이 많은 주니어가 합격하는 역설
- “말은 잘하는데 실제로 코드를 못 쓰는 사람을 걸러내지 못했다”
GitLab은 이후 풀리퀘 기반의 문제 해결 프로젝트로 전환하여, ‘실제 GitLab에서 일할 수 있는가’를 훨씬 잘 검증할 수 있게 되었다고 말했다.
Meta
메타는 대략 15년동안 “LeetCode 스타일”의 코딩테스트를 유지하다, 돌연 올해 7월 이를 전면 폐지했다. “실제 개발 환경에서는 AI 도구 사용이 일상화”되고 있다는 점과 “치팅을 막을 수 없다는것”이 핵심적인 이유였다. 전환된 전형은 AI-Enabled Interview 라고 하는데 CoderPad 환경에서 60분간 진행되며, AI 어시스턴트 챗 기능이 같이 제공된다. 문제 유형 또한 단순 알고리즘이 아닌 AI와 함께 프로젝트의 기능을 추가하거나 디버깅하는 형태로 진행된다.
이를 통해서 메타가 검증하고자 하는 능력은 다음과 같다.
- 문제 해결 (Problem Solving): 코드를 작성하기 전 문제를 명확히 하고, 요구사항 체크리스트를 작성하여 모호함을 제거하는 능력
- 코드 개발 및 이해 (Code Development): 기존 코드베이스의 구조를 빠르게 파악하고, 기존 스타일을 해치지 않으면서 기능을 확장하는 능력 (프로덕션 코드와 유사하게
main.py,requirements.txt,package.json등에 대한 이해도) - 검증 및 디버깅 (Verification): 코드를 작성 후 눈으로만 확인하는 것이 아니라, 테스트 케이스를 작성하고 엣지 케이스를 검증하며, 회귀를 방지하는 능력
- 기술적 커뮤니케이션 (Technical Communication): 모든 생각을 나열하는 것이 아니라, AI가 코드를 생성하는 동안 다음 단계를 설명하거나 트레이드오프를 논의하는 능력
Canva
Canva 또한 AI 사용을 엄격히 제한한 환경에서 알고리즘을 푸는 방법으로 개발자를 채용하던 회사였다. 그러다 올해 6월, 자사 블로그 아티클 Yes, You Can Use AI in Our Interviews. In fact, we insist 에서 "실제로는 엔지니어의 절반 이상이 매일 AI 쓰는데, 채용에서 금지하는 게 말이 안된다”라는 주장과 함께 기존 방식을 모두 폐지 했으며 AI와 협업하는 방법, AI 출력물 디버깅 능력, 엔지니어링 판단력 평가로 전환 되었다. 이는 전통적인 알고리즘 기반의 코테의 한계를 느끼며 전환한 다른 조직들의 흐름과 궤를 같이한다.
위 세 개의 팀 이외에도 Microsoft, Slack, Atlassian 등, 수많은 팀이 전통적인 방식의 알고리즘 코딩 테스트를 폐지하고 현실의 직무 역량과, AI 시대에 걸맞는 전형으로 개편했다. 이는 신문물을 빠르게 수용하는 몇 개의 스타트업 이야기가 결코 아니다. 미국의 빅테크와 전 세계에 가장 뛰어난 제품을 공급하는 데카콘 및 유니콘들의 이야기이다.
코딩 테스트가 없어진 세계
누차 이야기하지만, 제한된 환경에서 푸는 알고리즘 기반의 코딩 테스트는 없어질 것이다. 이후 세계가 어떻게 되고 훌륭한 개발자를 어떻게 검증하게 될 지 단언할 순 없지만, 앞서 “최근 흐름” 섹션에서 여러 팀이 전환한 사례들을 보면 어느 정도 그 기조를 읽을 수 있었고, 그것은 다음과 같다.
- 암기형 지식보단 실무 역량 위주의 검증
- Close AI Test 보단 Open AI Test로의 전환
- AI 혹은 동료가 작성한 코드를 리뷰를 빠르고 정확하게 리뷰하는 능력
암기형 지식보단 실무 역량 위주의 검증으로 변화될 것으로 보이며, AI(Code Assistant Chat)을 활용하여 실제 제품을 완성도 있고 빠르게 만드는 능력을 확인할 것 같다. 추가로 AI 시대엔 코드를 작성하는 비용이 0에 수렴할 것이어서 수 많은 코드를 잘 검증할 수 있는 능력. 즉, AI 혹은 다른 동료가 작성한 코드를 빠르게 이해하고 리뷰하는 능력도 중요해질 것 같다.
마무리
이 글은 사실, 개인적으로 같이 일하고 싶은 동료 상과 그들을 뽑기 위한 검증 방식이 정확히 일치하지 않아서 오는 괴리에서 출발했다. 물론 코테 이후 기술 면접에서 많은 것을 검증하긴 할 테지만 무엇보다도, 그들의 실무 역량을 오롯이 검증하는 단계이며 서류 합격 후 가장 많은 잠재적 동료가 있을 수 있는 해당 전형을 이런 식으로 구성하는 건 채용 성과 측면에서 효율이 많이 떨어진다고 생각해 왔다.
다행히도 리서치를 거듭 진행할수록, 미국의 빅테크와 더불어 전 세계에 제품을 공급하는 위대한 팀들도 동일한 문제의식을 느껴 전형을 개편하고 있다는 점에서, 이는 나 혼자만의 생각은 아니라는 위안을 조금 얻기도 했다.
국내에선 아직도 많은 팀이 “지원자 근원에 있는 기본기”를 검증한다는 명목으로 “LeetCode 스타일”의 코딩테스트를 유지하고 있고, 이를 준비하는 대다수의 지원자는 패턴을 단순 암기하는 방식으로 “LeetCode 스타일”의 코딩테스트를 준비한다. 이 모든 과정이 “지원자 근원에 있는 기본기”를 검증하는 측면에서 의미가 아예 없지는 않겠지만, 우리가 선택할 수 있는 방법 중 안 좋은 방법임에는 여러모로 틀림없다.
코테가 없어진 세계, AI가 전체 코드의 80% 이상을 작성하는 시대, 더 나아가 개발자의 역할이 재정의된 사회에서 어떻게 개발자를 검증하는것이 좋을지 대략 정리해봤다. 우리의 관성과 게으름을 너머 미래의 동료를 뽑는 이 과정에 조금만 더 신경을 쓴다면, 생각보다 많은 문제가 해결될 수 있을것이라 확신한다.
혹여나 나중에 어느 팀에 들어가 JD를 작성할 기회가 생긴다면, 알고리즘 기반의 코딩 테스트는 고려하지 않을것이다. 😎
글쓴이 프로필
좋은 글 잘 읽었습니다.