AI가 코드를 짜주는 시대(AI Agentic Coding)에, 개발자는 프로그래밍 언어를 배워야 할까?
들어가며
면접에서 이 질문을 받았다. 알고 있다고 생각했는데, 막상 말로 풀어내려니 생각보다 정리가 안 됐다.
면접이 끝난 뒤 다시 정리한 기록.
질문의 진짜 의도
"AI Agentic Coding 시대에 개발자가 프로그래밍 언어를 배워야 할까요?"
이 질문은 단순히 "배워야 한다 / 안 배워도 된다"를 묻는 게 아니다. 면접관이 보고 싶은 건 AI 시대에 개발자로서 본인의 가치를 어떻게 재정의하고 있는가에 대한 사고 프레임이다.
"그래도 기본은 알아야죠"라고 답하면 무난하지만 인상에 남지 않는다. "AI가 다 해주니까 안 배워도 됩니다"는 위험한 사람으로 보인다. 이 질문에는 확실한 입장 + 그 입장을 뒷받침하는 구조화된 논거가 필요하다.
내 결론: 반드시 배워야 한다
다만 배우는 이유가 달라진다.
기존에는 "코드를 작성하기 위해" 언어를 배웠다. 이제는 "AI가 생성한 코드를 판단하고 검증하기 위해" 배워야 한다. 역할이 코드 작성자(Coder)에서 코드 판단자이자 시스템 설계자(Judge & Architect)로 이동하고 있다.
자율주행에 비유하면 이해가 빠르다. 자율주행 기술이 발전했다고 해서 운전면허가 지금 당장 필요 없어지는 건 아니다. 자율주행 차량이 고속도로에서는 잘 달리지만, 공사 구간이나 비포장도로에서는 운전자가 개입해야 한다. 마찬가지로 AI가 함수 하나는 잘 짜지만, 프로덕션 장애 상황에서 AI에게 "고쳐줘"만 외칠 수는 없다. 핸들을 직접 잡을 수 있는 능력이 없으면, 자율주행이 풀지 못하는 상황에서 속수무책이 된다.
10년 뒤에는 정말 필요 없어질 수도 있다. 하지만 그건 10년 뒤의 이야기이고, 지금 이 전환기에는 오히려 언어와 프레임워크에 대한 깊이 있는 이해가 더 중요해지고 있다.
왜 여전히 필요한가: 세 가지 레이어
1. 검증과 디버깅의 책임
AI가 생성한 코드의 옳고 그름을 판단할 사람은 결국 개발자다.
나는 Claude Code를 메인 코딩 에이전트로 쓰고 있는데, AI가 제안한 코드를 그대로 머지한 적은 거의 없다. 예를 들어 AI가 만든 React 컴포넌트가 불필요한 리렌더링을 유발하는 경우가 잦다. useEffect의 의존성 배열에 매 렌더마다 새로 생성되는 객체를 넣는다거나, useMemo 없이 무거운 계산을 인라인으로 처리한다거나. 이런 문제는 React의 렌더링 모델을 이해하지 않으면 "코드가 돌아가니까 괜찮다"고 넘어가게 된다.
언어를 모르면 환각(hallucination)된 API 호출, 미묘한 메모리 누수, 비효율적인 알고리즘을 잡아낼 수 없다. AI가 생성한 코드를 프로덕션에 올리는 순간, 그 코드의 책임은 전적으로 개발자에게 있다.
2. 좋은 프롬프트는 도메인 지식에서 나온다
같은 AI를 써도 결과물의 차이가 압도적으로 갈리는 건, 프롬프트의 구체성 때문이다.
"React 컴포넌트 만들어줘"라고 하면 범용적이지만 맥락 없는 코드가 나온다. 반면 "이 컴포넌트는 Suspense 경계 안에서 동작해야 하고, TanStack Query의 useSuspenseQuery로 데이터를 페칭하되 에러 바운더리는 상위에서 처리해줘"라고 하면 프로덕션에 바로 쓸 수 있는 코드가 나온다.
이 차이는 언어와 생태계를 깊이 아는가 아닌가에서 온다. AI를 잘 부리려면 AI보다 도메인을 잘 알아야 한다.
3. 아키텍처 설계는 위임 불가 영역
함수 하나, 컴포넌트 하나는 AI가 잘 짠다. 하지만 시스템 수준의 의사결정은 여전히 사람의 영역이다.
"이 시스템을 MSA로 갈지 모놀리스로 갈지", "이 도메인 경계를 어디서 자를지", "상태 관리를 서버 상태와 클라이언트 상태로 어떻게 나눌지" — 이런 결정은 비즈니스 컨텍스트, 팀 규모, 언어/프레임워크의 특성을 모두 이해해야 내릴 수 있다. AI는 선택지를 제시해줄 수 있지만, 어떤 선택이 이 상황에 맞는지 판단하는 건 개발자의 몫이다.
그러면 뭐가 달라지는가
배워야 한다는 결론은 같지만, 학습의 무게중심이 달라진다.
문법 암기나 단순 API 사용법은 AI에게 물어보면 된다. Array.prototype.reduce()의 시그니처를 외우고 있을 필요는 없다. 대신 더 중요해지는 것들이 있다.
언어의 설계 철학과 런타임 동작 원리. JavaScript의 이벤트 루프, 클로저, 프로토타입 체인을 이해하면 AI가 생성한 코드의 잠재적 문제를 직감적으로 잡아낼 수 있다. "이 코드가 왜 동작하는지"뿐 아니라 "이 코드가 언제 깨지는지"를 아는 것이 핵심이다.
트레이드오프를 이해하는 깊이. 성능 vs 가독성, 유연성 vs 단순함, 추상화 vs 명시성 — 이런 판단은 언어와 프레임워크의 특성을 깊이 이해해야 내릴 수 있다. AI는 "How"를 잘 풀지만, "Why"와 "What if"는 결국 사람이 답해야 한다.
시스템 사고. 개별 함수가 아니라, 함수들이 모여 만드는 시스템의 흐름을 설계하는 능력. 데이터가 어디서 시작해서 어디로 흘러가는지, 에러가 발생했을 때 어디서 잡히는지, 병목이 어디에 생기는지를 구조적으로 파악하는 역량.
마무리
AI가 코드를 짜주는 시대에 프로그래밍 언어를 배워야 하느냐고 묻는다면, 나는 "오히려 지금이 더 깊이 배워야 할 때"라고 답하겠다.
AI는 코딩의 진입 장벽을 낮췄지만, 동시에 "진짜 개발자"와 "코드를 붙여넣는 사람"의 격차를 벌려놓고 있다. AI가 생성한 코드를 읽고, 판단하고, 책임질 수 있는 사람과 그렇지 못한 사람의 차이가 점점 선명해지고 있다.
자율주행이 보편화되더라도 자동차의 구조를 이해하는 엔지니어는 사라지지 않는다. 오히려 시스템이 복잡해질수록, 그 시스템을 이해하고 판단할 수 있는 사람의 가치는 올라간다.