숫자 하나를 먼저 보자. OpenAI의 AI 코딩 에이전트 코덱스(Codex)의 주간 활성 사용자(WAU)가 2,000만 명을 돌파했다. 3주 전 1,500만 명이었으니, 20일 만에 500만 명이 추가됐다. 같은 기간 OpenAI는 GPT-5.6 솔(Sol) API 가격을 20% 인하하며 기업 고객의 진입 장벽을 다시 한번 낮췄다. AI 코딩 도구가 '써볼 만한 실험'에서 '팀 생산성의 일부'로 자리잡는 속도가 예상보다 훨씬 빠르다는 신호다.
이 시점에서 현장에서 자주 듣는 질문이 있다. "AI가 코드를 짜면 개발자는 뭘 해야 하나요?" 솔직히 말하면 이건 틀린 질문이다. 더 정확한 질문은 이것이다. 코드 작성이 더 이상 가장 어려운 일이 아닌 세계에서, 개발자의 진짜 희소 자원은 무엇인가?
코드는 이제 '원자재'다
오랫동안 개발자의 핵심 가치는 아이디어를 동작하는 코드로 바꾸는 능력이었다. 문법을 알고, 프레임워크를 이해하고, 문서를 뒤지고, 세미콜론 하나 빠진 버그를 두 시간째 잡아내는 것. 그 과정 자체가 경쟁력이었다.
dev.to에 올라온 글 "If AI Can Write the Code, What Is a Developer Supposed to Do?" 은 이 변화를 정확하게 짚는다. 지금은 "반응형 내비게이션 바에 모바일 메뉴, 키보드 접근성, 다크 모드 토글을 추가해줘"라고 요청하면 몇 초 안에 꽤 완성도 높은 구현이 나온다. 코드 자체를 생산하는 비용이 급격히 낮아졌다. 원유에서 플라스틱이 된 것처럼, 코드는 '희소한 기술의 산물'에서 '가공해야 할 원자재'로 성격이 바뀌었다.
같은 도구, 다른 결과
이 글이 제시하는 비교 하나가 인상적이다. 같은 AI 도구를 쓰는 두 개발자를 상상해보자.
개발자 A는 "React 대시보드 만들어줘"라고 입력한다.
개발자 B는 먼저 요구사항을 분해한다. 어떤 데이터를 시각화해야 하는지, 어떤 사용자 권한 시나리오가 있는지, 접근성 기준은 무엇인지, 이 구조가 6개월 후에도 유지보수 가능한지를 먼저 생각한다. 그리고 그 판단 위에서 AI를 가속 수단으로 쓴다.
둘 다 같은 모델에 접근한다. 하지만 결과물의 품질과 유지보수 비용은 전혀 다르다. 차이는 타이핑 속도가 아니다. 무엇을 물어야 하는지 아는 것, 즉 기술적 판단(technical judgment)이다. AI가 범용화될수록 이 판단력의 격차가 더 크게 벌어진다.
AI가 코드를 쉽게 만들수록, 코드를 이해하는 일이 더 중요해진다
팀 리드로서 가장 걱정하는 지점이 여기다. AI가 생성한 코드는 겉보기에 멀쩡하다. 그런데 실제로는 불필요한 리렌더를 유발하거나, 접근성이 깨져 있거나, 지금은 동작하지만 트래픽이 10배 늘면 무너질 구조일 수 있다. 더 나쁜 경우는 그 코드를 제출한 개발자 본인도 그게 왜 그렇게 동작하는지 모르는 상황이다.
이건 역설이다. 코드를 생성하기 쉬워질수록, 코드를 읽고 판단하는 능력이 더 희소해진다. 생성은 AI가 하지만, 그 결과물이 프로덕션에 들어가도 되는지 판단하는 건 여전히 사람이어야 한다. 아무도 그 판단을 대신해주지 않는다.
주니어 개발자 문제: 가장 풀기 어려운 질문
개발자 성장 경로의 전통적인 구조를 생각해보자. 작은 버그 수정 → 기능 구현 → 설계 참여 → 아키텍처 결정. 이 경로는 어려운 문제를 반복해서 풀면서 판단력이 쌓이는 구조였다.
그런데 AI가 초급 수준의 구현 작업 상당 부분을 대체하면, 주니어 개발자는 그 경험을 어디서 쌓나? "AI로 만들 수 있다"와 "왜 이렇게 만들어야 하는지 안다"는 완전히 다른 역량이다. 전자만 익힌 채 시니어가 되면 어떤 팀이 만들어지는가. 이 질문에 아직 명확한 답을 가진 조직은 많지 않다. 업계 전체가 풀어야 할 숙제다.
그래서 개발자는 이제 무엇으로 싸우나
코드 생성이 공기처럼 흔해진 시대에 개발자의 경쟁력은 다음 영역으로 이동한다.
- 시스템 설계: 무엇을 어떻게 구조화할 것인가
- 요구사항 해석: 사용자가 진짜 필요한 게 뭔지 파악하는 것
- 판단과 거부: AI가 생성한 결과물 중 무엇을 쓰고 무엇을 버릴지
- 엣지 케이스 사고: AI가 놓치는 경계 조건과 실패 시나리오
- 접근성·보안·성능: 동작하는 것과 제대로 동작하는 것의 차이
- 커뮤니케이션: 팀과 비개발자에게 기술적 결정을 설명하는 능력
이 목록을 보면 한 가지가 보인다. 전부 사람이 판단해야 하는 영역이다. 코드를 생성하는 건 AI에게 맡기면 되지만, 그 코드가 올바른 문제를 올바른 방식으로 푸는지는 사람만이 판단할 수 있다.
'무엇을 만들 수 있나'에서 '무엇을 만들어야 하나'로
소프트웨어 개발의 병목은 이동하고 있다. 예전엔 "이걸 만들 수 있나?"가 핵심 질문이었다. 이제는 "이걸 만들어야 하나? 만든다면 어떤 방식이 맞나?"가 더 중요한 질문이 됐다. 코덱스 사용자 2,000만 명은 그 전환점이 이미 현실이 됐다는 증거다.
팀 리드 입장에서 이 변화는 채용 기준, 온보딩 설계, 코드 리뷰 방식 모두를 다시 짜야 한다는 뜻이다. AI 도구를 잘 쓰는 것과 AI 결과물을 판단할 수 있는 것은 다르다. 팀이 전자만 잘하고 후자를 키우지 않으면, 생산성 지표는 올라가고 코드베이스 품질은 조용히 무너진다. 개발자가 AI로 싸우는 시대에, 진짜 무기는 AI를 다루는 손이 아니라 AI를 판단하는 눈이다.