AI가 LeetCode를 3초에 푸는 시대, 코딩테스트는 어디로 가는가

2025년 1월, 컬리(Kurly)가 개발자 공채 코딩테스트에서 ChatGPT 사용을 공식 허용했다. 네카라쿠배당토가 일제히 AI 사용을 금지하고 있던 상황에서 이례적인 결정이었다. 업계의 반응은 극명하게 갈렸다. "실무를 반영한 합리적 판단"이라는 찬사와 "코딩테스트의 존재 의미를 스스로 부정한 것"이라는 비판이 동시에 터져 나왔다.

그런데 냉정하게 생각해 보자. AI가 알고리즘 문제를 인간보다 빠르고 정확하게 푸는 건 이미 기정사실이다. 그렇다면 질문은 "코딩테스트가 필요한가?"가 아니라, **"코딩테스트가 무엇을 측정해야 하는가?"**로 바뀌어야 한다.

코딩테스트는 원래 무엇을 측정하려 했나

코딩테스트의 역사는 1960년대 IBM까지 거슬러 올라간다. 당시에는 컴퓨터 자원이 극도로 제한적이었기 때문에, 메모리를 아끼고 연산을 줄이는 알고리즘 설계 능력이 곧 개발자의 생존력이었다. 한국에서는 2000년대 초반 IT 붐과 함께 삼성, LG, 네이버 등이 공채에 코딩테스트를 도입하면서 업계 표준으로 자리 잡았다.

핵심은 이것이다. 코딩테스트가 진짜 측정하려 했던 건 **"DP 점화식을 외우고 있느냐"가 아니라 "제한된 자원 아래서 문제를 구조화하고 효율적으로 해결할 수 있느냐"**였다. 그런데 어느 순간 수단이 목적이 되어 버렸다. 세그먼트 트리를 완벽하게 구현하는 지원자가 정작 REST API 설계나 DB 인덱스 전략에서는 막히는 아이러니가 일상이 된 것이다.

AI가 드러낸 기존 코딩테스트의 구조적 결함

AI의 등장은 코딩테스트의 본질적 약점을 수면 위로 끌어올렸다. 지금의 코딩테스트가 가진 문제를 정리하면 다음과 같다.

첫째, 실무와의 괴리. 백엔드 개발자의 일상은 알고리즘 퍼즐 풀이가 아니다. 서비스 간 통신 설계, 트랜잭션 관리, 장애 대응, 코드 리뷰 — 이런 것들이 실무다. 그런데 코딩테스트는 여전히 "혼자서, 아무것도 참고하지 않고, 제한 시간 안에" 문제를 푸는 방식을 고수한다.

둘째, 측정의 무효화. AI가 LeetCode Hard 문제를 몇 초 만에 풀어버리는 시점에서, 동일한 유형의 문제로 인간의 "코딩 능력"을 측정하겠다는 건 계산기가 있는 시대에 암산 속도로 수학자를 평가하겠다는 것과 다를 바 없다.

셋째, 스트레스로 인한 왜곡. 압박 속에서 빠르게 사고하는 능력과 좋은 소프트웨어를 만드는 능력은 별개다. 실무에서는 문제를 조사하고, 숙고하고, 다양한 해결책을 비교한 뒤 최적의 설계를 찾는 과정이 훨씬 중요하다.

그래서 코딩테스트가 사라질까?

결론부터 말하면, 사라지지 않는다. 다만 근본적으로 바뀐다.

Gartner는 2026년까지 약 50%의 글로벌 조직이 AI 없는 환경에서 지원자의 독립적·비판적 사고를 별도로 평가하게 될 것이라 전망했다. 동시에 75%의 기업이 채용 과정에 AI 역량 평가 테스트를 도입할 것으로 예상했다. 양쪽 방향이 동시에 진행되는 것이다.

이 두 흐름을 종합하면, 미래의 개발자 평가는 크게 세 가지 축으로 재편될 가능성이 높다.

1. AI 협업 능력 평가 — "AI와 함께 풀어라"

AI 도구 사용을 허용한 상태에서 복잡한 문제를 해결하게 하고, 다음을 평가한다.

• 프롬프트를 얼마나 정확하게 설계하는가
• AI가 생성한 코드의 한계와 버그를 식별할 수 있는가
• AI 출력을 비판적으로 검토하고 개선할 수 있는가

컬리의 시도가 바로 이 방향이다. 단순히 "AI 써도 돼요"가 아니라, AI를 도구로 활용하는 역량 자체를 직무 능력으로 간주하겠다는 선언이다.

2. 시스템 설계·아키텍처 판단 — "왜 이렇게 설계했는가"

백엔드 개발자에게 가장 현실적이면서도 AI가 대체하기 어려운 영역이다. 예시 과제를 들어보면 이렇다.

• "주문량이 10배 증가할 때 이 MSA 구조에서 병목이 어디에 생기는가? 어떻게 해결하겠는가?"
• "이 결제 시스템에서 정합성을 보장하면서 성능을 개선할 방법을 제안하라."
• "기존 모놀리스를 MSA로 전환할 때 서비스 경계를 어떻게 나누겠는가?"

이런 질문에는 정답이 없다. 트레이드오프를 이해하고, 맥락에 맞는 판단을 내리는 능력을 본다. AI는 선택지를 나열해 줄 수 있지만, 비즈니스 맥락과 팀 상황을 고려한 최종 의사결정은 사람의 영역이다.

3. 코드 리뷰·디버깅 역량 — "이 코드의 문제를 찾아라"

AI가 생성한 코드(혹은 의도적으로 결함을 삽입한 코드)를 주고 문제를 찾아내게 하는 방식이다. 이것은 몇 가지 면에서 기존 코딩테스트보다 훨씬 실무에 가깝다.

• 실제 개발 환경에서 가장 많은 시간을 쓰는 활동이 코드 리뷰다
• AI 시대에는 "AI가 작성한 코드를 감독하는 개발자"의 역할이 핵심이 된다
• 보안 취약점, 성능 병목, 설계 원칙 위반을 동시에 파악하는 종합적 역량을 측정할 수 있다

백엔드 개발자가 지금 준비해야 할 것

채용 시장의 키워드가 "얼마나 많이 뽑느냐"에서 "누구를 뽑느냐"로 이동했다. 기업의 63%가 AI 도입 확대에 따라 인력 규모를 줄이고 질적 채용으로 전환하고 있다는 조사 결과도 나왔다. 그렇다면 백엔드 개발자로서 무엇을 준비해야 하는가.

알고리즘 기초는 여전히 유효하다. 다만 투자 비율을 조정해야 한다. 시간복잡도 분석, 자료구조 선택 기준, 문제 분해 전략 같은 "사고의 뼈대"는 AI 시대에 오히려 더 중요하다. 이것이 없으면 AI가 생성한 코드가 왜 비효율적인지조차 판단할 수 없다.

시스템을 직접 설계하고 구축하는 경험을 쌓아라. 헥사고날 아키텍처로 정산 시스템을 구현해 본 경험, MSA를 Docker Compose로 구성해 본 경험, CI/CD 파이프라인을 설계해 본 경험 — 이런 것들이 알고리즘 문제 500개보다 강력한 증거가 된다.

AI 도구를 실무 워크플로우에 통합하라. Claude Code, Copilot, Cursor 같은 도구를 "신기한 장난감"이 아니라 "일상적인 생산성 도구"로 사용하는 습관을 들여라. AI를 얼마나 자연스럽게 활용하느냐가 곧 개발자의 경쟁력이 되는 시대다.

기술 의사결정 과정을 문서화하라. "JPA + QueryDSL을 선택한 이유", "BigDecimal을 도입한 배경", "서비스 경계를 이렇게 나눈 근거" — 이런 기록이 포트폴리오의 핵심이 된다. 기업이 보고 싶은 건 "무엇을 만들었는가"가 아니라 **"왜 그렇게 만들었는가"**다.

마치며

코딩테스트를 둘러싼 논쟁의 본질은 결국 하나로 수렴한다. 개발자의 가치는 코드를 "작성"하는 데 있지 않고, 문제를 "정의"하고 "해결"하는 데 있다. AI가 코드 작성을 대신해 줄수록, 오히려 어떤 문제를 풀어야 하는지 판단하고, AI가 만든 결과물이 비즈니스 맥락에서 적절한지 검증하는 능력의 가치는 올라간다.

IBM이 1960년대에 알고리즘 문제를 처음 출제했을 때 그 의도는 "이 사람이 제한된 자원으로 문제를 해결할 수 있는가"였다. 60년이 지난 지금, 자원의 정의가 바뀌었을 뿐 질문의 본질은 동일하다. 다만 "제한된 자원"이 메모리와 CPU에서 시간, 맥락, 그리고 판단력으로 바뀌었을 뿐이다.

코딩테스트는 사라지지 않는다. 다만 더 이상 "알고리즘을 외웠는가"를 묻지 않을 뿐이다.