코딩 테스트에서 AI 역량 테스트로, 달라지는 개발자 평가

몇 년 전만 해도 코딩 테스트는 개발자 채용의 첫 관문이었습니다. 서류 다음에는 온라인 시험이 있었고, 정해진 시간 안에 알고리즘 문제를 몇 개나 푸느냐로 다음 단계에 갈 사람이 갈렸습니다. 문제를 잘 푸는 사람이 곧 개발을 잘하는 사람이라는 믿음이 어느 정도 통하던 때였고, 준비하는 쪽도 프로그래머스나 백준에서 하루에 몇 문제씩 풀며 시험에 대비했습니다.

지금은 그 위상이 많이 달라졌습니다. 그 시절 응시자 대부분을 떨어뜨리던 문제를 이제는 AI가 꽤 쉽게 풉니다. 코드를 짜는 일 자체가 점점 AI에게 넘어가면서, 문제를 빨리 푸는 능력만으로는 좋은 개발자를 설명하기 어려워졌습니다.

그렇다고 개발자가 할 일이 사라진 것은 아닙니다. 어디까지를 AI에게 맡기고 어디부터를 사람이 맡아야 효율적인지가 새 질문이 됐습니다. 그래서 예전 코딩 테스트 문제를 잣대로 삼아 AI가 지금 어디까지 왔는지 재 보려 합니다. AI가 잘하는 일과 사람이 맡아야 할 일의 경계가 보이면, 둘이 일을 나누는 방법도, 개발자를 평가하는 방법도 달라질 테니까요.

과거의 코딩 테스트

카카오는 2017년부터 신입 개발자를 블라인드 공채로 뽑았습니다. 학교나 경력 대신 온라인 코딩 테스트로 먼저 거르는 방식입니다. 1차 시험은 해마다 토요일 오후 2시부터 7시까지 다섯 시간 동안 일곱 문제를 풀었고, 문제는 쉬운 것부터 어려운 것 순서로 놓였습니다.

카카오는 시험이 끝나면 기술 블로그에 문제 해설과 문제별 정답률을 공개했습니다. 아래는 2020년 9월에 치른 2021년 공채 1차 시험입니다. 같은 문제가 지금 프로그래머스에 올라가 있어서, 거기서 매긴 레벨을 나란히 적었습니다.

정답률은 테스트 케이스를 하나도 빠짐없이 통과해야 맞힌 것으로 쳐서 나온 숫자입니다. 그래도 뒤의 세 문제는 응시자 백 명 가운데 한 명 남짓만 풀었습니다. 지금 연습 사이트에서 Lv.3로 분류된 문제가 실제 시험장에서는 이 정도였습니다.

저도 그 무렵 카카오 코딩 테스트를 열심히 준비해서 통과한 적이 있습니다. 그때 주로 붙잡고 연습하던 게 프로그래머스 Lv.3 문제였는데, 이 표를 다시 보니 시험장에서는 그 레벨부터가 높은 벽이었습니다.

어려움을 키운 장치가 하나 더 있었습니다. 2019년 공채부터 들어간 효율성 테스트입니다. 답이 맞는지만 보는 정확성 테스트와 달리, 아주 큰 입력을 넣고 정해진 시간 안에 끝나는지를 봅니다. 2019년 공채의 '무지의 먹방 라이브'는 정확성 정답률이 42.08%였는데 효율성은 5.52%였고, 2020년 공채의 '가사 검색'은 34.4%와 0.8%였습니다. 답은 맞게 짜도 입력이 커지면 시간 안에 끝나지 않아 대부분 여기서 떨어졌습니다.

네이버도 코딩 테스트를 첫 관문으로 썼습니다. 문제와 정답률을 공개하지 않아 응시자 후기로만 알 수 있는데, 2시간 안팎에 3~4문제로 카카오보다 짧았습니다. 대신 조건이 많은 시뮬레이션 구현이 나와서, 70분을 쓰고도 끝내지 못했다는 후기가 있을 만큼 빠듯했습니다.

당시의 난이도와 합격선

카카오는 합격선을 공개하지 않았습니다. 그래도 준비하던 사람들 사이에는 "절반만 풀면 붙는다"는 말이 돌았습니다. 인턴십 시험은 공채보다 짧아서 네 시간에 다섯 문제였습니다. 카카오는 2019 겨울 인턴십 해설(새 탭에서 열림)에서 인턴은 인턴 과정에서 한 번 더 검증하기 때문이라고 이유를 밝혔습니다. 그 다섯 문제를 두고 2021년 한 인턴십 후기에는 "보통 카카오는 절반이 커트라인이던데"라는 문장이 나옵니다. 다만 같은 글에서 2.5문제를 푼 사람들이 대부분 떨어졌다는 이야기도 함께 전합니다. 합격선은 해마다 달랐고, 절반은 어디까지나 통설이었습니다.

그래도 이 통설이 아주 틀린 말은 아니었습니다. 위 표를 다시 보면 앞의 세 문제는 지금 기준 Lv.1~Lv.2이고, 넷째 문제부터 Lv.3이 되면서 정답률이 한 자릿수로 떨어집니다. 절반을 채우려면 앞의 세 문제를 다 풀고 Lv.3 문제까지 손을 대야 했습니다. 체감으로는 프로그래머스 Lv.3을 시간 안에 풀 수 있으면 거의 합격권이었습니다.

그럼 이 문제들, 그중에서도 사람이 거의 풀지 못한 축의 문제를 지금 AI에게 주면 어떻게 될까요.

AI의 현재 위치

프로그래머스에서 가장 높은 레벨은 Lv.5입니다. 문제마다 끝까지 푼 사람이 100명 안팎이고 정답률은 0~1%에 머뭅니다. 앞에서 본 카카오 시험의 마지막 문제(Lv.4)보다도 한 단계 위입니다. 그중 세 문제를 골라 Claude의 Fable 모델과 Codex의 Astra 모델에게 나눠 풀게 했습니다.

• 중력 작용(새 탭에서 열림): 노드마다 값이 든 트리에서 두 가지 요청을 번갈아 처리합니다. 하나는 어떤 노드 아래 값의 합을 묻는 것이고, 다른 하나는 그 노드부터 루트까지 값을 한 칸씩 끌어내리고 루트에 새 값을 넣는 것입니다. 요청은 10만 개까지 들어옵니다.
• 미로 주행 테스트(새 탭에서 열림): 격자 미로 어딘가에 표지판이 하나 있습니다. 여러 출발점에서 정해진 거리 안에 표지판에 닿았는지만 적힌 기록을 보고, 표지판이 있을 수 있는 자리가 몇 곳인지 셉니다. 미로가 한 변 10억 칸까지 커서 칸을 하나씩 확인할 수 없습니다.
• 쿼리의 모음의 개수(새 탭에서 열림): 0으로 채운 배열에 '구간의 값을 x 이상으로 끌어올리는' 연산을 정해진 횟수만큼 써서 목표 배열을 만드는 방법이 몇 가지인지 셉니다.

결과는 싱거웠습니다. 세 문제 모두 30분이 안 걸려 풀었고, 채점은 만점이었습니다. 카카오 시험에서 응시자 백 명 중 한 명이 풀던 문제보다 한 단계 위의 문제를 AI는 30분 안에 끝낸 셈입니다.

어떤 문제인지 궁금하다면 위 링크로 들어가 직접 한번 풀어 보세요.

달라진 AI의 위상

불과 몇 년 전만 해도 AI 코딩 도구는 똑똑한 자동완성에 가까웠습니다. 함수 이름을 치면 다음 몇 줄을 채워 주는 정도였고, 그 몇 줄이 맞는지는 쓰는 사람이 바로 알아볼 수 있었습니다. 지금은 응시자 대부분이 손도 대지 못하던 문제를 30분 안에 풀어 냅니다. 옆에서 거들던 도구가 이제는 일을 통째로 맡길 수 있는 상대가 됐습니다.

위상이 달라졌으니 쓰는 법도 달라져야 합니다. 코드를 한 줄씩 받아 붙이던 방식에서, 만들 것을 정확히 설명하고 결과물을 받아 확인하는 방식으로 바뀝니다. 사람이 하는 일도 코드를 치는 것에서 요구사항을 정리하고, 결과를 검토하고, 고칠 곳을 짚어 주는 쪽으로 옮겨 갑니다.

채용 과제가 좋은 예입니다. 코딩 테스트 다음 단계로 많이 쓰던 과제형 전형은 대개 요구사항이 분명한 단순 구현입니다. 제가 예전에 받았던 프런트엔드 과제도 그랬습니다. 한 회사 소개 페이지의 한 섹션을 문구와 레이아웃까지 똑같이 만들고, 화면 폭은 1200px로 고정하고, 최신 크롬에서 돌아가게 하고, 실행 방법과 기술을 고른 이유를 README에 적는 것이었습니다. 그때는 환경 설정과 프로젝트 구조를 어떻게 잡을지부터 한참 고민했는데, 이렇게 명세가 또렷한 과제는 지금 AI에게 맡기면 오래 걸리지 않습니다.

코드를 빨리 짜는 능력보다, AI가 짠 코드를 읽고 이해해서 맞는지 가려내는 능력이 더 중요해졌습니다. 직접 짜 본 경험이 없으면 무엇이 틀렸는지도 알아보기 어려우니, 기본기의 쓸모는 오히려 커졌습니다.

AI 역량 검사의 기준

채용도 이 변화를 따라가기 시작했습니다. 코딩 테스트를 없애거나, 시험장에서 AI를 쓰게 하고 그 쓰는 모습을 평가하는 회사가 하나둘 나오고 있습니다. 다만 무엇을 어떻게 평가할지 정답은 아직 없습니다. 프로그래머스를 운영하는 그렙의 대표도 올해 9월 인터뷰에서 AI 활용 역량을 평가하려는 시도는 늘고 있지만 무엇을 어떻게 평가할지는 아직 명확한 답을 찾지 못했다고 말했습니다.

그래도 사례들을 모아 보면 보는 것은 비슷합니다. 요구사항을 어떻게 정리해 맡겼는지, AI가 내놓은 결과를 무엇으로 확인했는지, 어디까지 손대게 했는지입니다. AI에게 일을 맡길 때 자주 빠지는 함정을 뒤집어 보면 그대로 평가 기준이 됩니다.

검증

함정: 틀린 코드 생성→할 일: 틀린 코드 가려내기

빈칸 찾기

함정: 빈칸을 임의로 채움→할 일: 빈칸 찾아 묻기

독립된 테스트

함정: 테스트만 통과하는 코드→할 일: 구현 전에 테스트 먼저

범위 통제

함정: 요청 밖 수정→할 일: 필요 없는 변경 되돌리기

위임 설계

함정: 지시마다 다른 결과→할 일: 제약과 끝낼 기준 먼저 적기

코딩 테스트가 시간 안에 정답을 내는지를 봤다면, AI 역량 검사는 이 다섯 가지가 과정에 드러나는지를 봅니다.

AI 역량 검사 사례

AI와 함께 푸는 실무형 문제

디자인 플랫폼 Canva는 2025년 6월, 백엔드·프런트엔드 개발자 면접의 CS 기초 단계를 'AI 활용 코딩' 면접으로 바꿨다고 공식 블로그(새 탭에서 열림)에서 밝혔습니다. 문제는 '붐비는 공항의 이착륙을 관리하는 시스템 만들기'처럼 답이 하나로 정해지지 않은 실무형 과제이고, 지원자는 Copilot이나 Claude 같은 도구를 마음대로 씁니다. 면접관은 AI를 언제 어떻게 쓰는지, 모호한 요구사항을 어떻게 쪼개는지, AI가 만든 코드에서 문제를 찾아 고치는지, 결과가 실제 서비스 수준을 만족하는지를 봅니다.

Canva는 AI를 써 본 경험이 적은 지원자들이 고전했다고 적었습니다. 코드를 못 짜서가 아니라, AI를 이끌고 약한 제안을 가려내는 판단이 부족해서였다고 합니다. 위 기준으로는 위임 설계, 빈칸 찾기, 검증에 해당합니다.

기존 코드를 고치는 세션

미국 배달 플랫폼 DoorDash는 2026년 3월 기존 코딩 면접을 60분짜리 'AI 보조 엔지니어링 세션'으로 바꿨습니다(동아일보 2026년 9월 보도). 지원자는 AI 도구를 쓰면서 이미 있는 코드의 문제를 해결하고, 화면을 공유해 자기가 무엇을 하는지 설명합니다. 평가자는 AI를 쓰는 방식, 결과 검증, 디버깅, 문제 범위 판단, 의사결정 과정을 봅니다. Google도 일부 팀의 면접에서 기존 코드를 AI로 읽고 디버깅하게 하는 방식을 시범 운영한다고 2026년 5월에 보도됐습니다(아시아경제).

새 코드를 짜는 것보다 남이 짠 코드를 이해하고 고치는 능력을 보는 검사입니다. 기준으로는 검증과 범위 통제에 가깝습니다.

과정을 함께 내는 문제

넥슨은 채용형 인턴십의 코딩 테스트를 없앴고, 프로그래밍 대회 NYPC에서는 생성형 AI를 공식으로 허용했습니다(2026년 8월 출제위원장 인터뷰). 대신 문제를 AI에 그대로 넣어 한 번에 답이 나오지 않도록 가공해서, 참가자가 AI를 어떤 방향으로 이끄느냐에 따라 성적이 갈리게 했습니다. 예선에서는 문제를 푼 과정과 AI를 어떻게 썼는지 적은 '리플레이' 후기를 받았고, 비싼 에이전트 경쟁이 되지 않도록 서브 에이전트 기능은 막았습니다.

평가 플랫폼도 같은 방향입니다. CodeSignal은 AI 어시스턴트가 붙은 평가 환경을 내놓으면서 채용팀이 세션 녹화와 AI와 나눈 대화 전체를 볼 수 있게 했다고 발표(새 탭에서 열림)했습니다. 결과물만이 아니라 답에 이른 과정을 본다는 점에서, 위임 설계와 검증을 함께 봅니다.

프롬프트만 채점하는 문항

HackerRank에는 코드 대신 프롬프트를 쓰는 문항(새 탭에서 열림)이 있습니다. 응시자가 쓴 프롬프트를 미리 준비한 입력들과 함께 모델에 보내고, 모델의 답이 기대한 출력과 글자 하나까지 같아야 통과입니다. 군더더기 설명이나 형식이 한 줄만 붙어도 실패이고, 부분 점수는 없습니다.

원하는 값만 정확히 뽑아내는 지시를 쓰려면 모델마다 다른 작성법도 알아야 합니다. Anthropic(새 탭에서 열림)은 Claude에게 지시와 자료를 XML 태그로 나눠 주고 긴 자료 뒤에 질문을 두라고 권하고, OpenAI(새 탭에서 열림)는 추론 모델에는 목표를, 일반 GPT 모델에는 구체적인 지시를 주라고 합니다. Google(새 탭에서 열림)은 Gemini에 예시를 꼭 넣으라고 권합니다. 위임 설계를 가장 좁고 엄격하게 재는 검사입니다.

직접 해 보기

앞에서 세운 기준으로 짧은 검사를 하나 만들어 봤습니다. AI가 낸 코드 변경 다섯 개를 차례로 보고, 머지할지 반려할지 고른 뒤 얼마나 확신하는지도 골라 보세요. 다 풀면 맞힌 개수와 함께, 확신한 만큼 맞혔는지도 알려 드립니다.

1function normalizeEmail(email) {2  return email.trim().toLowerCase();3}45test('공백과 대문자', () => {6  expect(normalizeEmail('  Dev@Example.com ')).toBe('dev@example.com');7});

마치며

한창 코딩 테스트를 준비하던 때는 프로그래머스 Lv.3을 막힘없이 푸는 것이 실력의 증거였습니다. 지금은 그보다 두 단계 위의 문제를 AI가 30분 안에 풉니다. 정해진 문제를 빠르고 정확하게 코드로 옮기는 능력, 코딩 테스트가 재던 바로 그 능력에서는 이미 AI가 사람보다 앞서 있습니다.

그렇다고 개발자가 할 일이 줄어든 것은 아닙니다. 무엇을 만들지 정하고, 요구사항의 빈칸을 찾아내고, AI가 내놓은 결과를 의심하고, 그 코드에 책임지는 일은 여전히 사람 몫입니다. 채용이 코딩 테스트에서 AI 역량 검사로 옮겨 가는 것도 이 몫을 제대로 재려는 움직임이라고 생각합니다.

용어 설명

• 블라인드 공채: 학교나 경력 같은 이력 대신 시험 결과로 먼저 거르는 신입 공개 채용.
• 테스트 케이스: 입력과 기대하는 출력을 짝지어 둔 채점용 예시 하나. 코딩 테스트는 숨겨 둔 테스트 케이스 수십 개로 답을 채점합니다.
• 정답률: 응시자 가운데 그 문제의 테스트 케이스를 모두 통과한 사람의 비율.
• 효율성 테스트: 답이 맞는지에 더해, 아주 큰 입력에서도 정해진 시간 안에 끝나는지 보는 채점.
• 레벨(Lv.): 프로그래머스가 문제 난이도에 매긴 등급. Lv.0부터 Lv.5까지 있고 숫자가 클수록 어렵습니다.
• query(쿼리): 데이터에 던지는 요청 하나. 이 글의 문제들에서는 '이 값을 바꿔라', '이 아래 값의 합을 알려 달라' 같은 명령 하나를 말합니다.
• VOC(Voice of Customer, 고객의 소리): 고객이 남긴 불만, 요청, 문의 원문.
• 명세서: 무엇을 만들고 어떻게 동작해야 하는지 적은 문서.
• 경계값: 0, 빈 목록, 월말처럼 조건이 바뀌는 언저리의 값. 버그가 잘 숨는 곳입니다.
• merge(머지): 검토한 코드 변경을 원래 코드에 합치는 것. 합치지 않고 돌려보내는 것은 반려라고 썼습니다.
• prompt(프롬프트): AI에게 일을 시키려고 쓰는 지시문.
• agent(에이전트): 지시를 받아 스스로 파일을 읽고 고치고 명령을 실행하며 일을 끝까지 해내는 AI.
• 규칙 파일: CLAUDE.md, AGENTS.md처럼 AI 코딩 도구가 작업을 시작할 때 읽는 프로젝트 지시 파일.