AI가 코드를 대신 써주는 시대가 왔다. GitHub Copilot, Claude, Cursor 같은 도구들이 개발자의 손가락을 대체하기 시작했다. 이제 “코드를 잘 치는 능력”만으로는 살아남기 어렵다.
그렇다면 개발자는 어디로 가야 하는가? 내 결론은 명확하다. 개발자는 최종적으로 기획자가 되어야 한다.
단순히 직군을 바꾸라는 이야기가 아니다. 기술적 깊이 위에 기획 역량을 쌓아, 문제를 정의하고 AI와 팀을 움직여 결과를 만드는 사람이 되어야 한다는 뜻이다.
코딩의 가치가 변하고 있다
불과 2~3년 전까지만 해도, 개발자의 가치는 “구현 능력”에 크게 의존했다. 복잡한 알고리즘을 짜고, 성능을 최적화하고(같은 일을 더 빠르게, 메모리를 덜 쓰며 하도록 코드를 다듬고), 버그 없는 코드를 빠르게 작성하는 것이 핵심이었다.
하지만 AI 코딩 도구의 등장으로 이 공식이 흔들리고 있다. AI는 이미 대부분의 보일러플레이트 코드를 순식간에 생성하고, 디버깅을 도와주며, 심지어 프로그램을 어떤 덩어리로 나눌지 정하는 아키텍처 제안까지 한다. “만드는 행위” 자체의 희소성이 급격히 떨어지고 있는 것이다.
그렇다면 개발자에게 남는 진짜 가치는 무엇일까?
바로 “무엇을, 왜 만들어야 하는지 정의하는 능력”이다.
개발자 출신 기획자의 무기: 구현 레벨의 예측력
내가 말하는 “기획자”는 특정 직군의 이름이 아니다. 프로덕트(회사가 만들어 사용자에게 내놓는 서비스나 앱) 방향을 정하는 PM, 기능 요구사항을 설계하는 서비스 기획자, 기술 전략을 수립하는 테크 리드 — 이 모든 역할을 상황에 따라 넘나드는 하이브리드 역할이다.
개발자가 이 역할로 전환했을 때 가장 큰 강점은 “구현 레벨의 예측력”이다.
일반 기획자가 “이런 기능 만들어주세요”라고 요구하면, 개발팀에서 “이건 안 됩니다”, “이건 3주 걸립니다”라고 돌려보내고, 기획자가 고쳐서 다시 보내는 핑퐁(탁구공처럼 요구와 거절이 오가는 것)이 시작된다. 그런데 개발을 깊이 해본 사람은 기획 단계에서 이미 이런 것들을 머릿속에서 시뮬레이션할 수 있다.
- 이 기능은 기존 DB 스키마로 가능한가? 컬럼이나 테이블을 새로 만들어야 하는가?
- 이 요구사항은 어떤 예외 케이스를 만드는가? 여기서 예외 케이스는 자바의 예외가 아니라 「평소와 다른 상황」이다. 예를 들어 같은 버튼을 두 번 누르면, 결제 도중 창을 닫으면 어떻게 되는가
- 이 규모의 트래픽을 이 구조로 감당할 수 있는가?
- 이 기능을 추가했을 때 기존 시스템에 미치는 사이드 이펙트는?
기획서는 무엇을 만들지 적은 문서다. 어떤 화면에 무엇이 보이고 버튼을 누르면 무엇이 일어나는지를 적는다(요구사항 정의서, 기능정의서가 이런 문서다). 개발을 해본 사람은 위 질문의 답을 기획서에 미리 담아 둘 수 있다.
기획서 자체의 완성도가 다르다. 기술적 실현 가능성이 검증된 기획서는 개발팀과의 커뮤니케이션 비용을 극적으로 줄이고, 프로젝트 전체 속도를 끌어올린다.
(한 사람)"] E -->|"AI 활용 구현"| F["결과물"] end style 기존 fill:#1a1a2e,stroke:#e94560,color:#eee style AI시대 fill:#1a1a2e,stroke:#0f3460,color:#eee style A fill:#16213e,stroke:#e94560,color:#eee style B fill:#16213e,stroke:#e94560,color:#eee style C fill:#16213e,stroke:#e94560,color:#eee style D fill:#0f3460,stroke:#53d8fb,color:#eee style E fill:#0f3460,stroke:#53d8fb,color:#eee style F fill:#0f3460,stroke:#53d8fb,color:#eee
그림의 클라이언트는 프로그램을 맡긴 고객이다. 「기존 구조」 상자는 지금까지의 모습이다. 클라이언트 → 기획자 → 개발자로 이어지는 전달 과정에서 정보가 왜곡되고, “안 됩니다”와 “수정해주세요”의 핑퐁이 반복된다. 「AI 시대 구조」 상자는 내가 그리는 모습이다. 가운데 상자는 두 사람이 아니라, 개발과 기획을 같이 하는 한 사람이다. 그 한 사람이 요구사항을 직접 파악하고, AI와 함께 결과물까지 만들어낸다.
정보 왜곡 문제: 말전달 게임의 종말
기존 소프트웨어 개발 프로세스에는 고질적인 문제가 있었다. 정보 왜곡이다.
클라이언트가 원하는 것을 기획자에게 말하면, 기획자는 자신의 이해 범위 안에서 기획서를 작성한다. 개발자는 그 기획서를 보고 코드를 짠다. 마치 말전달 게임처럼, 단계를 거칠수록 원래 의도와 결과물 사이의 간극이 벌어진다.
왜 이런 일이 발생할까?
- 기획자가 기술을 모른다 — 비현실적인 스펙(기획서에 적는 「이렇게 동작해야 한다」는 요구 내용)을 작성하거나, 기술적으로 가능한 더 나은 대안을 놓친다.
- 개발자가 현장을 모른다 — 클라이언트를 직접 만나지 않으니, “왜 이걸 만들어야 하는지” 이해하지 못한 채 구현만 한다.
- 양쪽 모두 불만이 쌓인다 — 기획자는 “왜 내가 원하는 대로 안 만들어주지?”, 개발자는 “왜 이런 비현실적인 걸 요구하지?”
하지만 한 사람이 클라이언트를 직접 만나고, 요구사항을 이해하고, 기술적으로 실현 가능한 형태로 바로 설계할 수 있다면 — 이 말전달 게임 자체가 사라진다.
기술을 아는 만큼 AI를 잘 부린다
AI 시대에 가장 중요한 공식이 하나 있다:
생산성 격차 = 기술 이해도 격차
같은 AI 도구를 쓰더라도, 기술의 디테일을 아는 사람과 모르는 사람의 결과물은 천지차이다.
“버튼 하나 만들어줘”라고 하는 사람과, “이 버튼은 debounce 300ms 적용하고, 클릭 시 optimistic update로 UX 체감 속도 높여줘”라고 하는 사람이 AI에게서 받는 결과물은 완전히 다르다.
두 번째 사람의 말을 풀면 이렇다.
이 버튼은 누를 때마다 서버에 「이거 처리해 줘」라는 요청을 보내고, 서버가 처리한 결과를 응답으로 돌려받는다고 하자.
- 디바운스 300ms — 사용자가 버튼을 연달아 눌러도, 마지막으로 누른 뒤 300밀리초(0.3초)를 기다렸다가 한 번만 처리하라는 뜻이다. 성급하게 두세 번 눌러서 같은 요청이 서버로 여러 번 가는 일을 막는다
- 낙관적 업데이트 — 서버 응답을 기다리지 않고 화면부터 바뀐 결과로 그려 두라는 뜻이다. 나중에 서버가 「처리하지 못했다」는 응답을 돌려주면 그때 화면을 되돌린다
- UX 체감 속도 — 실제 처리 시간이 같아도 사용자가 「빠르다」고 느끼게 하라는 뜻이다
첫 번째 사람은 디바운스도 낙관적 업데이트도 말하지 않았다. 그러면 AI가 만든 버튼에 이 처리가 들어 있을지는 AI가 알아서 정한다. 두 번째 사람은 이런 처리가 있다는 걸 알기 때문에 요구할 수 있었다. 위 공식이 말하는 격차가 이것이다.
기술을 아는 만큼 AI에게 디테일하게 요구할 수 있고, 디테일한 요구는 디테일한 결과를 만든다.
이것은 단순히 개발자에게만 해당되는 이야기가 아니다. 역으로, 기획자도 개발 공부를 해야 하는 시대가 오고 있다는 뜻이다. AI를 더 정밀하게 활용하기 위해, 기술적 배경 지식이 필수가 되는 것이다.
결국 양쪽이 중간에서 만나게 된다. 개발자는 기획 역량을 올리고, 기획자는 기술 이해도를 높이는 — T자형 인재로 수렴하는 흐름이다. T의 세로획은 원래 깊게 아는 분야(개발자라면 개발, 기획자라면 기획)이고, 가로획은 그 옆으로 넓혀 가는 분야다. 아래 그림은 양쪽이 각자 가로획을 넓혀 같은 자리에서 만나는 모습이다.
모든 도메인에 해당되는 보편 원칙
이 이야기가 웹 개발자에게만 해당된다고 생각할 수 있다. 하지만 그렇지 않다. 여기서 도메인은 웹 · 임베디드 · 모바일처럼 개발하는 분야를 말한다.
- 웹 개발자는 웹을 사용하는 사용자를 이해해야 한다.
- 임베디드 개발자는 그 시스템을 현장에서 운용하는 사람을 이해해야 한다.
- 모바일 개발자는 다양한 환경에서 앱을 사용하는 사용자를 이해해야 한다.
도메인이 무엇이든, 핵심은 동일하다. “누구를 위해 만드느냐를 이해하는 사람이 가장 좋은 결과물을 만든다.”
AI가 “만드는 행위”를 대체할수록, “무엇을 왜 만들어야 하는지 정의하는 능력”이 모든 도메인에서 공통적으로 요구되는 핵심 역량이 된다.
개발자가 기획으로 갈 때 채워야 할 것
그렇다면 개발자가 기획 역량을 키울 때, 어떤 부분이 가장 부족할까?
현장 감각과 클라이언트 이해력이다.
개발자는 시스템적 사고, 논리적 설계, 기술적 판단력에서는 강하다. 하지만 “클라이언트가 실제로 뭘 필요로 하는지”를 파악하는 데에는 익숙하지 않은 경우가 많다.
기획의 시작점은 결국 사용자다. 사용자가 어떤 상황에서, 어떤 불편함을 겪고 있으며, 진짜 원하는 것이 무엇인지를 알아야 명확한 스펙과 개발 목적이 나올 수 있다. 이것은 코드로 해결할 수 있는 문제가 아니라, 사람을 직접 만나고, 관찰하고, 대화하면서 키울 수 있는 능력이다.
개발자가 이 능력까지 갖추게 되면, 진정한 의미의 “원맨 팀”이 된다:
- 클라이언트를 직접 만나서 진짜 문제를 파악한다.
- 기술적 실현 가능성을 검증하며 기획한다. 앞의 「구현 레벨의 예측력」에서 든 질문 — 지금 DB 스키마로 되는가, 어떤 예외 케이스가 생기는가, 트래픽을 견디는가, 사이드 이펙트는 없는가 — 을 기획하는 단계에서 스스로 던지고 답한다.
- AI를 활용해 직접 구현까지 해낸다.
- 결과물을 클라이언트에게 전달하고 피드백을 받는다.
네 단계 중 AI의 손을 빌리는 것은 3번 구현이다. 1번, 2번, 4번은 여전히 사람이 한다. 코드 치는 일을 AI에게 넘길 수 있게 되면서, 1·2·4번을 하던 사람이 구현까지 끝낼 수 있게 된다.
한 사람이 이 사이클을 전부 돌릴 수 있다. 과거에는 팀 단위로 해야 했던 일을 AI와 함께 한 사람이 해내는 시대가 오고 있는 것이다.
AI 시대 개발자 생존 전략 정리
| 구분 | 과거 | AI 시대 |
|---|---|---|
| 핵심 가치 | 코드 구현 능력 | 문제 정의 + AI 활용 능력 |
| 커뮤니케이션 | 기획서 받아서 개발 | 클라이언트와 직접 소통 |
| 역할 범위 | 개발만 담당 | 문제 파악 + 기획 + 구현 + 피드백 (원맨 팀 네 단계) |
| 생산성 결정 요인 | 코딩 속도 | 기술 이해도 기반 AI 활용력 |
| 성장 방향 | 기술 스페셜리스트 (T의 세로획만 있는, 한 분야만 깊은 사람) | T자형 하이브리드 인재 |
결론: 코드가 아닌 문제를 정의하는 사람이 되어라
AI는 도구다. 아무리 뛰어난 도구라도, 무엇을 만들어야 하는지 모르면 쓸모가 없다.
개발자의 미래는 “더 빠르게 코드를 치는 것”이 아니라, “더 정확하게 문제를 정의하고, AI를 활용해 최적의 솔루션을 만들어내는 것”에 있다.
지금 당장 할 수 있는 것들:
- 클라이언트와 직접 대화하는 기회를 만들어라. 기획 회의에 참여하고, 사용자 인터뷰에 동석해라.
- 기술적 판단력을 꾸준히 키워라. AI에게 디테일한 지시를 내릴 수 있는 건 기술을 아는 사람뿐이다.
- AI 도구를 적극 활용하되, 주도권은 반드시 쥐고 있어라. AI는 실행자이고, 당신이 기획자다.
- “왜?”라는 질문을 습관화해라. 기능을 만들기 전에 “왜 이게 필요한지”를 먼저 묻는 사람이 결국 살아남는다.
개발자로서의 기술적 깊이는 당신의 가장 강력한 무기다. 거기에 기획 역량과 현장 감각을 더한다면, AI 시대에서 대체 불가능한 인재가 될 수 있다.
AI 시대에 개발자의 역할이 어떻게 변할지, 이미 기획 영역으로 넓혀 가 본 경험이 있다면 댓글로 남겨 주면 좋겠다.
자신만의 철학을 만들어가는 중입니다.
댓글남기기