왜 빅 테크는 코딩 테스트를 포기하지 않는가? (AI 시대를 넘어선 유의미성)

AI가 코딩을 해주는 시대, 우리가 LeetCode를 풀 필요가 있을까요?

요즘 (사실 이미 오래전부터) 개발자 커뮤니티에서 코딩 테스트 무용론이 들끓는 것을 자주 접합니다. (거의 잊을만 하면 한번씩 나오는 이야기죠) AI가 거의 완벽한 코드를 순식간에 짜주는 세상에, 왜 우리는 여전히 낡고 비효율적인 '알고리즘 문제 풀이'에 매달려야 할까요? 심지어 면접에서 LeetCode 솔루션을 한 500개 가량 통째로 외워서 합격한다는 비전공자들도 있는데 말이죠.

저 역시 수많은 빅 테크 면접을 합격해보면서, 준비 과정중에 때로는 코딩 테스트가 너무 비효율적이라고 느꼈습니다. 하지만 구글, 메타, 아마존 등 글로벌 빅 테크 기업들 뿐만 아니라 수많은 국내 기업들 역시 여전히 코딩 테스트를 가장 핵심적인 채용 필터로 사용합니다. 단순히 '전통'이기 때문일까요? 코딩 테스트는 진행하는 방식에 따라서 그 자체로 기술적 깊이(Technical Depth)와 문제 해결 역량(Problem-Solving Skill)을 동시에 측정하는 가장 효율적인 도구이며, 저 또한 면접관으로써, 지원자로써, 빅 테크 면접관들이 우리가 코드를 작성하는 능력 외의 무언가 본질적인 것을 보고 있다고 생각합니다.

이번 포스트에서는 왜 AI 시대에도 코딩 테스트가 유의미한지, 그리고 합격자들이 이 테스트를 통해 면접관에게 어떤 시그널을 보는지 제 경험을 바탕으로 이야기해 보겠습니다.

---

코딩 테스트 vs. 과제형 테스트: 빅테크의 현실적 트레이드오프

왜 현업에 더 가까운 과제형 테스트 대신 코딩 테스트를 선호하는지에 대한 이유는 채용 프로세스의 효율성과 직결됩니다.

• 효율적인 평가 시간: 라이브 코딩 인터뷰는 대개 45분~1시간으로 제한됩니다. 과제형 테스트는 문제를 읽고 요구사항을 이해하는 데만 상당한 시간이 소요되어, 제한된 면접 시간 내에 지원자의 역량을 충분히 평가하기 어렵습니다. 알고리즘 문제는 핵심 로직에 빠르게 집중할 수 있어 효율적입니다. (개인적으로 4시간 혹은 그 이상 시간을 주는 비대면 과제 테스트는 완전히 시간 낭비라 생각합니다.)
• 문제 출제 및 관리의 용이성: 빅테크 기업은 매 달 수많은 면접을 진행하며 문제 유출을 방지해야 합니다. 알고리즘 및 자료구조 문제는 기본 개념 위에서 난이도, 제약 조건, 자료구조 활용 등을 살짝 변형하는 것만으로도 새로운 문제 출제가 용이합니다. 반면, 현업 과제는 한 번 만들면 시스템의 기술 스택과 복잡한 환경 설정이 엮여 있어 문제 교체가 어렵고 출제/검증에 막대한 시간과 비용이 소모됩니다.
• 객관적인 평가 기준: 알고리즘 문제는 시간 및 공간 복잡도(Time/Space Complexity)라는 객관적이고 정량적인 평가 기준이 명확합니다. 이는 면접관 개인의 주관이 개입될 여지를 줄여, 대규모 채용에서 일관된 평가 퀄리티를 유지하는 데 유리합니다. 또한 면접 내용을 로깅만 해두면 어느 개발자가 보더라도 해당 면접 진행 내용을 빠르게 확인 가능하기도 하고요.

---

코딩 테스트는 '코딩' 능력만을 테스트하지 않습니다: 네 가지 핵심 역량

코딩 테스트는 그 이름과 달리 단순한 문법이나 구현 능력을 평가하는 자리가 아닙니다. 만약 그렇다면 AI를 쓰는게 훨씬 빠르고 정확할 것입니다. 빅 테크 면접관들이 실제로 주목하는 것은 다음과 같은 인간 고유의 핵심 역량입니다. (물론 그렇다고 문제를 못푸는걸 허용한다는건 아닙니다만..)

[문제 분해 능력]: "미로를 쪼개는 구조화된 사고"

실제 소프트웨어 개발은 단일한 문제가 아닙니다. 복잡하게 얽힌 요구사항을 논의하고, 이를 논리적인 작은 조각들로 분해하여 종합적으로 해결하는 능력이 필요합니다.

코딩 테스트에서 면접관은 지원자가 문제를 처음 듣고, 예시를 통해 핵심 제약 조건을 파악하며, 솔루션을 단계적으로 추론하는 Top-Down 사고 과정을 관찰합니다. AI는 이미 정제된 최종 코드를 주지만, 이 '추론의 궤적'은 보여주지 못합니다. 이 궤적이야말로 개발자의 문제 해결 로직을 가장 잘 드러냅니다. (풀이 과정을 보여주기야 하지만, LLM 개발자의 입장에서 보기엔, 이는 과정이라기 보다는 주입된 솔루션의 해상도라고 보는게 더 적합하다 느껴집니다.. 모델이 이해할 수 없는 논리를 강요할때 어떻게 동작하는지를 보면 알 수 있죠.)

• 시스템 디자인과의 연결고리: 시스템 디자인 인터뷰가 '큰 규모의 복잡성'을 다룬다면, 코딩 테스트는 '알고리즘적 복잡성'을 다룹니다. 두 영역 모두 복잡한 문제를 가장 효율적인 구조로 쪼개는 능력을 평가하며, 이는 수많은 컴포넌트와 트레이드오프를 관리하는 시스템 아키텍처링 사고방식의 기초가 됩니다.

[모호성 처리 및 커뮤니케이션]: "완벽하지 않은 문제에 대처하는 자세"

면접에서 제시되는 문제는 실제 업무처럼 항상 불완전하고 모호합니다. '배열의 크기는?', '입력 값의 범위는?', '시간/공간 복잡도의 제약은?'과 같은 질문이 명확하게 주어지지 않는 경우가 많습니다.

합격자는 이 모호함을 무시하고 코딩을 시작하지 않습니다. 오히려 면접관과 대화하며 제약 조건을 협의하고, 코너 케이스(Edge Case)를 스스로 정의하며 문제를 함께 완성해 나갑니다. 이는 코드를 잘 짜는 능력 이전에, 팀원으로서 불명확한 스펙을 명확히 정의하고 시스템의 요구사항을 확정할 수 있는 커뮤니케이션 능력을 평가하는 것입니다. (오히려 제약 조건을 잘 제시해서 면접관이 미끼를 물경우, 문제가 더 쉬워지기도 하죠)

[추상화 및 복잡도 최적화]: "AI를 뛰어넘는 효율성의 직관"

AI는 일반적으로 주어진 문제 정의에 대한 '직관적인 정답'을 가장 빠르게 구현합니다. 하지만 코딩 테스트에서 요구하는 것은 단순한 정답 코드가 아닙니다. 면접관은 여러분이 숨겨진 시간/공간 복잡도의 제약을 간파하고, 이를 Big O Notation으로 정량화하며, 더 높은 효율성을 위해 추상적인 자료구조나 알고리즘(예: 동적 계획법, 트라이, 세그먼트 트리)을 적용할 수 있는지를 봅니다. 이는 문제의 본질을 꿰뚫고, 트레이드오프를 통해 최적화의 한계를 돌파하는 인간 고유의 추상화 사고 영역입니다. AI는 아직 이 '최적화의 여정'을 면접관만큼 설득력 있게 설명하지 못합니다. 간혹, AI 치팅 방지 차원에서라도 역으로 일부러 비효율적인 조건을 주고 이를 맞춰 구현하도록 요구하기도 합니다. (AI는 비효율적인 솔루션을 요구할때 더 헤매곤 합니다. 정답이 아니라고 배웠을테니까요.)

[실시간 압박 관리]: "최악의 상황에서 드러나는 프로 의식"

45분~60분이라는 제한된 시간, 면접관의 시선, 그리고 갑작스러운 솔루션 막힘은 상당한 압박감으로 작용합니다. 이 압박 속에서 패닉에 빠지지 않고, 막힌 지점을 명확히 짚어내며, 백업 솔루션을 차분하게 제시하는 능력은 실제 서비스에 크리티컬한 버그가 발생했을 때 위기를 관리하는 능력과 직결됩니다. 코딩 테스트는 단순히 기술적 지식뿐만 아니라, 지원자의 멘탈과 압박 관리능력을 테스트하는 최적의 모의 환경을 제공합니다.

---

결론: AI 시대, 우리의 전략은 바뀌어야 합니다.

AI가 '정답 코드'를 빠르게 제공하는 세상에서, 코딩 테스트의 가치는 더 이상 '코딩을 할 수 있는가?'에 있지 않습니다. 이제 코딩 테스트는 '인간이 면접관을 설득하고 함께 문제를 정의할 수 있는가?'의 테스트로 진화했습니다. 올해에도 저도 면접을 몇번 봤는데, 확실히 이를 이해하고 면접을 진행하는 회사들은 이미 문제 유형이나 면접관이 보고자 하는게 바뀌었다는걸 느꼈습니다. (최적 솔루션이 아닌 요구사항을 주면서 면접관이 "원하는" 답정너를 요구하는 상황이 자주 보였습니다.)

저의 수차례 빅 테크 면접 합격 경험을 통해 제가 깨달은 것은, 합격자들은 단순히 똑똑해서 합격한 것이 아니라, 면접관의 의도를 파악하고, 자신의 강점을 최대한 어필하며, 약점을 관리하는 '실전 전략'에 능했다는 사실입니다. 물론 문제를 잘 풀어서, 버그 없이 최적 솔루션을 도출하는건 당연히 수행한다는 전제하에 말이겠죠.