AI가 코드를 쓰는 시대, 개발자의 진짜 역량이 드러난다

게시 2026/02/21 업데이트 2026/02/21

By Juho

24 분읽는 시간

개요

AI 시대에 개발자의 역할이 어떻게 달라지고 있는지, 그리고 무엇을 준비해야 하는지에 대한 글이다. AI로 인한 생산성 향상에 대한 기대와 대체 가능성에 대한 불안이 공존하는 가운데, 개발자에게 진짜 필요한 역량이 무엇인지 정리한다.

핵심 주장은 명확하다. 개발자의 역할은 사라지는 것이 아니라 코드 작성자에서 리뷰 및 승인권자로 무게 중심이 이동하는 것이며, 이 과정에서 요구되는 역량은 지금도 좋은 개발자에게 필요한 것들과 본질적으로 같다.

ChatGPT 이후 3년, 달라진 개발자의 하루

2022년 말 ChatGPT가 등장했을 때 이 속도로 발전할 것이라 예상한 사람은 많지 않았다. 당시에는 할루시네이션 이슈도 많았고 출력의 품질 자체도 좋지 않았다.

하지만 불과 3년 만에 개발자의 하루는 크게 변했다. 기존 개발자의 업무는 “자연어 요구사항 분석 → 설계 → 직접 구현”이라는 일련의 과정을 직접 수행하는 것이었다. 아침에 출근하면 에디터를 열고 빈 파일에 커서를 놓는 것으로 하루를 시작했다.

현재는 직접 코딩하기보다 AI에게 맥락을 전달하고, 생성된 코드를 읽고, 고치고, 다시 요청하는 것이 하루의 상당 부분을 차지한다. 이미 AI 코딩 에이전트는 단순 보조 수준을 넘어섰다. 프롬프트만 잘 제공하면 함수 하나, 모듈 하나 정도는 사람이 작성한 것과 구별하기 어려운 코드를 내놓는다.

모든 코드를 직접 한 줄씩 작성하는 방식은 최소한 일부 업무에서는 점점 비효율이 되어가고 있다. 앞으로 변화 속도는 더 빨라질 가능성이 높다.

작성자에서 의사결정권자로

코드를 통해 제품을 생산하는 행위가 직접적인 코드 작성에서 “코드에 대한 판단”으로 이동하고 있다. 여기서 판단이란 단순히 AI 출력이 의도대로 됐는지 확인하는 것이 아니다. 비즈니스 의도가 기술적 구현으로 올바르게 번역됐는지 검증하는 과정을 의미한다.

리뷰 과정에서 인간은 고맥락의 체크리스트를 확인해야 한다. 이 코드가 런타임에서 큰 문제가 없을지, 장기적인 변화에 대비할 수 있는 코드인지, 빠진 예외처리는 없을지, 정책에 위반되는 코드는 없는지를 판단해야 한다.

최종적으로 승인 도장을 찍는 사람이 존재한다는 것은 여전히 “인간이 이해하기 쉬운 코드”를 작성해야 한다는 것을 의미한다. 인간이 코드를 읽을 필요가 없다면 모든 코드를 기계어로 작성해도 된다. 하지만 문제가 생기면 책임을 져야 하는데, 그 코드를 읽지도 않고 라이브에 배포할 수 있겠는가.

코드에 대한 책임을 질 사람이 필요하다

AI가 코드 리뷰까지 할 수 있게 되더라도 최종적인 “문제 없음” 승인 도장을 찍는 인간의 역할은 여전히 존재할 것이다. 그 이유는 기술적 가능성이 아닌 훨씬 더 근본적인 곳에 있다.

AI가 작성한 코드로 결제 로직에 버그가 생겨 고객에게 잘못된 금액이 청구됐을 때, 과연 누가 책임을 지는가?

AI는 법적으로 인격체가 아니기 때문에 책임을 질 수 없다. 결국 그 코드를 리뷰하고 승인한 개발자, 그리고 그 개발자가 속한 조직이 책임을 져야 한다.

이 방향성은 이미 여러 규제로 나타나고 있다.

규제와 실제 사례

2024년 발효된 EU AI Act는 의료, 금융, 인프라 같은 고위험 영역에서 AI 시스템에 인간 감독을 의무화했다. AI가 판단을 내리더라도 인간이 리뷰 가능하도록 만들어야 한다는 원칙을 법으로 못 박은 것이다.

다른 분야의 사례도 같은 방향을 가리킨다.

분야	사례	책임 귀속
자율주행	자율주행차 사고	제조사와 운전자
의료	FDA 승인 의료 AI 진단 도구	최종 판단은 의사
금융	2010년 Flash Crash (알고리즘 트레이딩 연쇄 폭락)	알고리즘 운영 주체

자동화가 고도화될수록 책임 구조는 희미해지는 것이 아니라, 오히려 더 선명하게 인간 쪽으로 귀속되는 경향이 있다.

AI 시대에 요구되는 핵심 역량

AI 시대이니 프롬프트를 잘 다루는 것이 핵심 역량이 될 것 같지만, 실제로는 다르다. “유명한 개발자 누구처럼 짜줘”라는 프롬프트는 누구나 작성할 수 있다. 중요한 것은 그런 프롬프트를 넣었음에도 품질 기준을 충족하지 않는 코드가 출력됐을 때 문제를 감지할 수 있는 능력이다.

장기 변경 비용을 예측하는 역량

AI는 “작동하는 코드”를 만드는 데 최적화되어 있다. 학습 데이터에서 가장 빈번하게 등장하는 패턴을 재현하는 것이 AI의 동작 방식이다. 하지만 지금 당장 작동하는 코드와 6개월 뒤에도 유지보수가 쉬운 코드는 전혀 다른 기준이다.

소프트웨어의 품질은 원래 즉시 드러나지 않는 성질의 것이다. 나쁜 설계의 비용은 코드를 작성한 시점이 아니라, 그 코드를 변경해야 하는 시점에 발생한다. 실제로 LinkedIn에서는 “AI로 만들었는데 유지보수가 어려워서 개발자를 고용했다”, “기능을 도저히 못 붙여서 접었다”는 글이 늘고 있다.

코드를 다각도로 평가하는 역량

기능적 정확성은 테스트로 어느 정도 검증할 수 있다. 더 까다로운 것은 구조적 품질이다. 이 모듈의 책임 범위가 적절한가, 의존성 방향이 맞는가, 인터페이스가 변경에 유연한가. 이런 질문들은 자동화된 테스트로는 잡기 어렵다.

그 너머에는 성능적 함의도 있다. AI가 생성한 코드가 작동은 하지만, 데이터가 10배 늘었을 때도 괜찮을까. 보안적 측면도 있다. 입력 검증이 충분한가, 권한 확인이 빠져 있지는 않은가.

AI의 생성 속도가 빨라질수록 이 문제는 더 심각해진다. 사람이 직접 코드를 작성하던 시절에는 생산량에 물리적 상한이 있었다. 생산 속도와 리뷰 역량 사이에 어느 정도 균형이 자연스럽게 유지됐다. 하지만 AI가 수 초 만에 수백 줄을 생성하는 환경에서는 이 균형이 쉽게 깨진다.

많은 회사들이 AI를 도입했음에도 생산성 증가를 못 느끼는 이유가 바로 여기에 있다. 코드 생산은 빨라졌지만 AI가 뱉은 코드를 리뷰하는 과정이 병목이 되는 것이다.

추상화 역량

AI도 인터페이스를 정의하고 클래스를 나누고 모듈을 분리할 수 있다. 형식적인 측면에서는 잘하는 경우도 있다. 하지만 AI가 만드는 추상화와 숙련된 개발자가 만드는 추상화 사이에는 결정적인 차이가 있다.

AI의 추상화는 학습 데이터의 통계적 평균에 기반한다. 수많은 프로젝트에서 본 “그럴듯한 패턴”을 현재 상황에 적용하는 방식이다. 반면 실제 소프트웨어 설계는 한정된 자원과 불확실한 미래 속에서 무엇을 포기할지 결정하는 트레이드오프의 영역이다.

AI 출력 코드의 위험한 점은 겉보기에 좋아 보인다는 것이다. 파일이 적절히 나뉘어 있고, 네이밍도 관례를 따르고, 패턴도 익숙하다. 문제는 실제로 변경이 필요한 시점에 드러난다. 결제 수단 하나를 추가하려고 하는데, “깔끔하게 나뉘어 있던” 구조의 여기저기를 동시에 수정해야 한다는 것을 그제야 깨닫게 된다.

프론트엔드에서 흔히 보이는 예시도 있다. AI에게 대시보드 컴포넌트를 요청하면, 하나의 거대한 컴포넌트에 데이터 페칭, 상태 관리, UI 렌더링을 모두 넣거나, 반대로 간단한 차트 하나에 커스텀 훅 세 개와 컨텍스트 프로바이더를 만들어놓기도 한다. 전자는 추상화 부족이고, 후자는 추상화 과잉이다. 적절한 추상화란 현재 상황에서 딱 필요한 만큼의 구조를 만드는 것이고, 이 “만큼”을 판단하는 것은 맥락을 아는 사람만 할 수 있다.

암묵지를 명시화하는 역량

“뭔가 이상한데”라는 직감을 “이 함수는 두 가지 책임을 가지고 있다”, “이 인터페이스가 변경에 취약하다”는 구체적인 언어로 바꿀 수 있어야 AI에게 올바른 명령을 내릴 수 있다.

여기서 말하는 것은 few-shot 예시나 chain-of-thought 같은 형식적 프롬프트 기법이 아니다. 모델이 발전하면서 그런 것들은 자연스럽게 희석된다. 핵심은 무엇을 만들어야 하는지 명확하게 정의하고, 어떤 맥락이 중요한지 판단해서 전달하는 능력이다.

이 역량들의 유효기간은 도구 숙련도보다 훨씬 길다. 도구 숙련도의 수명은 도구의 교체 주기에 묶여 있다. jQuery가 React에 밀리는 데 몇 년, Webpack이 Vite에 밀리는 데 또 몇 년이 걸렸다. 반면 설계 판단과 암묵지 언어화 역량의 수명은 소프트웨어의 본질적 복잡성이 존재하는 한 유효하다.

의도적 수련 설계의 필요성

“도구가 할 수 없는 것에 집중하라”고 말하면서 정작 그것을 기를 기회가 줄어드는 모순적인 상황이 발생한다. 해법은 두 층으로 나뉜다.

AI에게 넘기지 말아야 할 두 지점 - 설계와 리뷰

업무 흐름 안에서 AI에게 넘기지 말아야 할 지점이 두 군데 있다. 코드 작성 앞단의 설계와 뒷단의 리뷰다.

프롬프트를 치기 전에 “이 모듈이 외부에 노출할 인터페이스는 무엇인가”, “책임의 경계는 어디에 그을 것인가”를 먼저 정의하는 과정을 거치면, AI가 만들어낸 결과물을 자신의 설계 결정과 비교할 수 있게 된다. AI가 다른 구조를 선택했다면 왜 그랬는지 분석하게 되고, 내가 놓친 것은 없는지 다시 생각하게 된다.

AI에게 PR 리뷰를 맡기고 별다른 문제가 없으면 그냥 승인해버리는 습관은 위험하다. 코드 리뷰는 요구사항, 설계 의도, 비즈니스 맥락을 동시에 고려하면서 코드를 읽는 과정이다. 이 과정 자체가 설계 감각을 유지하는 훈련이다.

의도적으로 직접 짜보는 시간

설계 감각은 구현의 고통을 알아야 생긴다. 어떤 구조가 변경에 취약한지를 직접 손으로 겪어봐야 “이 추상화가 잘못됐다”는 직감이 형성된다. 겪어보지 못한 고통은 감각으로 남지 않는다.

주니어 개발자의 경우 특히 그렇다. 경험이 적은 상태에서 AI가 생성한 코드를 리뷰하는 것은, 아직 운전을 배우는 중인 사람에게 자율주행차의 판단을 평가하라고 하는 것과 비슷하다. 직접 핸들을 잡아봐야 도로 위의 감각이 생기는 것처럼, 직접 코드를 짜봐야 구조에 대한 감각이 생긴다.

미래의 개발자에게 코딩 역량은 매일 하는 업무가 아니라 판단력을 유지하기 위한 훈련이 될 가능성이 높다. 사이드 프로젝트나 개인 학습에서는 의도적으로 AI를 내려놓고 처음부터 끝까지 직접 구현해보는 시간을 만드는 것이 좋다.

“왜”를 언어화하는 연습

두 가지를 관통하는 태도가 있다. “뭔가 이상한데”라는 직감이 드는 순간, 그 감각을 그냥 넘기지 않고 왜 그렇게 느꼈는지 명확한 말로 표현할 수 있을 때까지 다듬는 것이다.

“이상한데”에서 멈추면 직감에서 끝나지만, “이 함수가 두 가지 책임을 가지고 있다”까지 가면 언어가 된다. 직감은 나만 아는 것이고, 언어는 쓸 수 있는 것이다. 언어가 되어야 AI에게 정확한 지시를 내릴 수 있고, 팀원에게 설명할 수 있고, 다음에 비슷한 패턴을 만났을 때 알아챌 수 있다.

결국 본질은 변하지 않았다

Fred Brooks는 1986년에 소프트웨어의 복잡성을 두 가지로 나눴다.

구분	설명	AI의 역할
우발적 복잡성	도구의 한계에서 오는 것 (보일러플레이트, 반복 패턴, 문법 오류)	AI가 해결할 수 있다
본질적 복잡성	문제 자체에 내재된 것 (비즈니스 요구사항의 모호함, 상충하는 설계 목표, 미래 변경의 불확실성)	AI가 발전해도 사라지지 않는다

AI가 이전 도구들과 근본적으로 다른 것은 사실이다. 농기구나 기계와 달리 AI는 스스로 추론하고 생성한다. 그렇다면 왜 요구되는 역량이 바뀌지 않는다고 할 수 있을까.

논리는 책임에서 시작한다. 책임을 진다는 것은 판단을 한다는 뜻이고, 판단의 질은 코드의 구조적 건강함을 알아보는 눈, 도메인에 맞는 추상화를 구분하는 감각, 장기 변경 비용을 예측하는 능력에서 온다. 이것들이 항상 좋은 개발자와 평범한 개발자를 갈랐던 것들이다.

인간이 판단과 책임의 주체로 남아 있는 한, 그 판단에 필요한 역량의 본질은 바뀌지 않는다. 코드 생산이 자동화될수록 그 생산물을 검수하는 판단력의 비중이 오히려 부각될 것이다.

결론

불과 1년 전만 해도 프롬프트 엔지니어링이 중요한 화두였지만, 지금은 스킬, 병렬 에이전트, 팀 같은 키워드로 바뀌었다. 6개월만 지나도 이 키워드들도 다시 바뀔 것이다. AI는 결국 초등학생이 프롬프트를 대충 작성해도 제대로 된 출력을 내는 수준까지 발전할 것이다.

지금 도구를 잘 사용하는 방법에만 집중하는 것이 정말 옳은 방향일까. 오히려 도구를 잘 깎는 것에만 집중하면 도태되기 쉬워질 수 있다.

물이 빠지면 누가 발가벗고 수영했는지 알 수 있다. 물이 빠지는 속도는 분명히 빨라지고 있다.

Reference

AI가 코드를 쓰는 시대, 개발자의 진짜 역량이 드러난다 - Evans Library

AI Dev Skill Development