AI 주도 개발 시대, “기획”에 주목해야 하는 이유

이 글은 ‘리오랩(매니패스트)’이 제작하고, 요즘IT가 기업 제휴 콘텐츠로 소개합니다.

주식 시장에서는 연일 AI 산업을 주도하는 엔비디아의 시가총액이 최고점을 경신하고, 정부는 AI 산업 양성에 국운을 걸겠다고 선언하며, AI가 우리 일터(특히, IT 업계)에 깊숙하게 침투한 지 너무 오래전이라 이미 왠지 AI가 내 사무실 옆자리에 함께하는 것같이 느껴지는 시대입니다.

우리 모두가 AI를 활용하여 생산성을 끌어올리는 것이 지상최대의 과제인 것처럼 말하는 시대, 여러분들의 프로젝트도 폭발적인 속도로 달려가고 있나요? 혹시 AI를 활용하여 개발의 속도가 빨라졌다는 뉴스에도 불구하고 프로젝트가 진행되는 속도가 예전 그대로인가요?

이 글은 바로 이 지점에서 출발합니다. AI가 코드를 생성하는 속도는 비약적으로 빨라졌다는데, 프로젝트 전체의 속도는 왜 제자리걸음인지, 그리고 이 문제를 해결하기 위해 우리가 왜 개발이 아닌 기획에 주목해야 하는지 심층적으로 분석하고자 합니다.

AI 개발의 시대, 지금도 충분한가요?

1) 이미 AI 개발의 시대

요즘 IT 업계는 'AI 개발'의 시대로 완전히 접어들었습니다. Cursor, GitHub Copilot 같은 AI 코딩 도구는 이제 선택이 아닌 필수가 되어가고 있습니다. 스택 오버플로우(Stack Overflow)의 최신 2025 개발자 설문조사에 따르면, 이미 개발자의 80% 이상이 AI 도구를 사용하고 있거나, 사용할 계획이라고 답했습니다.

계속해서 빅테크들은 "AI가 개발자를 대체할 것"이라고 말하며 인력을 감축한다는 자극적인 헤드라인이 연일 쏟아지고 있으며, 실제로 많은 개발자가 현업에서 AI 도구를 도입해 놀라운 생산성 향상을 경험하고 있다고 합니다. GitHub의 자체 연구에 따르면, AI 코딩 어시스턴트인 Copilot을 사용한 개발자 그룹은 그렇지 않은 그룹에 비해 특정 과업을 2배 이상 더 빠르게 완료했습니다. AI를 통한 개발 생산성 증가는 이제 분명한 현실입니다. 우리 모두가 이를 알고 있죠.
 

과거 며칠씩 밤을 새워가며 만들던 보일러플레이트 코드, 복잡한 유틸리티 함수, 테스트가 포함된 API 엔드포인트를 이제는 단 몇 분 만에 완성합니다. 심지어 기획자나 마케터 같은 비개발자도 간단한 프롬프트로 랜딩 페이지나 데이터 분석 스크립트를 뚝딱 만들어내는 시대가 되었습니다. 최근 요즘IT에는 비개발자 출신이 바이브 코딩을 배워 프리랜서 개발자라는 부업을 가지게 된 경험을 나누는 글이 올라와 화제였죠. 개발의 장벽은 극적으로 낮아졌고, '개발'이라는 행위 자체의 생산성은 극도로 높아졌습니다.

2) 개발이 빨라지면, 프로젝트도 빨라지나?

하지만, 여기서 우리는 현업 종사자로서 근본적인 질문을 던져봐야 합니다. 

"코드를 짜는 속도가 빨라진 만큼, 우리 프로젝트도 빨라졌습니까?"

아마 현업에 계신 많은 개발자, PM, 디자이너는 이 질문에 선뜻 "그렇다"라고 답하기 어려울 것입니다. AI와 함께함으로써 코드를 아무리 쉽고 빠르게 짤 수 있다해도, 여전히 프로젝트는 일정에 쫓기고, 예상치 못한 재작업은 반복되며, 클라이언트(혹은 내부 기획자)와의 지루한 줄다리기는 끝나지 않습니다.

프로젝트를 지연시키는 요인에는 한정된 인력에서 오는 개발 작업 속도의 한계만 있는 것이 아니기 때문입니다. 연락도 잘 닿지 않다가 프로젝트 일정 후반부에 갑자기 나타나 상세한 수정사항을 쏟아내는 클라이언트도 있고, 한창 개발과 디자인을 하고 있을 때 갑자기 웃으면서 나타나 기획안 변경사항을 들이미는 기획자도 있습니다. 갑작스러운 변덕을 부리거나, 막상 프로젝트가 진행되고 나니 자기가 원했던 건 이런 게 아니었던 것 같다며 완전히 다른 방향을 요구하는 대표님이나 이사님들도 있죠. 이런 일들은 그 어떤 AI 도구도 해결해 주지 않습니다.

혹시 여러분들은 AI가 짜준 코드를 통째로 git reset --hard 해본 경험은 없으신가요? 왜 AI가 도입되어 코드를 생산하는 속도는 10배 빨라졌다는데, 우리의 퇴근 시간과 프로젝트 마감일은 그대로일까요?

AI 시대, 더 강력해진 GIGO(Garbage In, Garbage Out) 법칙

1) AI는 코드의 품질을 결정하지 않는다

문제의 핵심은 AI 도구가 아니라, 그 도구에 우리가 무엇을 넣고 있는지에 있습니다. 컴퓨터 공학의 고전적인 격언인 GIGO(Garbage In, Garbage Out), 즉 '쓰레기를 넣으면 쓰레기가 나온다'는 법칙이 AI 시대에 와서 훨씬 더 강력하고 치명적인 모습으로 우리를 괴롭히고 있습니다.

여기서 개발자가 AI 도구에 넣게 되는 ‘'쓰레기(Garbage)'란 바로 '제대로 구조화되지 않은, 파편적이고 불분명한 기획'입니다.

개발자라면 누구나 전체 플로우가 확정되지 않은 파편적인 기획, 그리고 개발 지시가 결국엔 얼마나 큰 재앙으로 돌아오는지 잘 알고 계실 겁니다. 개발자치고 기획자들에 대해서 분노의 감정을 느껴보지 않은 사람이 얼마나 될까요. 코드를 생산하다 말고 “아, 이거 어차피 또 바뀔 텐데”라는 생각에 갑자기 현타를 느껴본 경험은 개발자라면 누구나 있을 겁니다. 기획자들의 “이거 사소한 변경인데”, “쉽게 되는 거 아니에요?”, “이번 한 번만 해주세요”에 울컥해 본 경험도요.

또한 AI 코딩 도구의 등장은 이러한 문제를 더더욱 악화시킬 수 있습니다. 과거에는 불분명한 기획에 대해 개발자가 질문하고, 대안을 모색하며, 잠재적 문제를 예측하는 생산적 마찰의 과정이 존재했습니다. 이 마찰은 초기 개발 속도를 늦추지만, 장기적으로는 거대한 재작업을 막는 안전장치 역할을 했습니다. 하지만 AI 코딩 어시스턴트는 주어진 프롬프트를 문자 그대로 해석하여 가장 최적화된 코드를 즉시 생성함으로써, 모호한 요구사항에 내재된 위험을 성찰하는 과정을 건너뛰게 만들 수 있습니다. 그 결과, AI는 모호함이 낳는 재앙적인 결과를 증폭시키는 GIGO 증폭기로 작동하게 됩니다.

2) AI가 쓰레기를 뱉게 되는 과정

우리에게 친숙한 예시를 활용하여 왜 AI 코딩 도구의 코딩 생산성이 쓰레기를 만들게 되는지 설명해 보겠습니다. 프리랜서 개발자 K씨의 평화롭던 화요일 오전을 상상해 봅시다. 클라이언트로부터 메시지가 도착합니다.

클라이언트: "K 님, 저희 일단 MVP니까, 로그인할 때는 구글 소셜 로그인만 넣어서 빠르게 만들어주세요."

K씨는 간단한 작업이라고 생각합니다. 그는 곧바로 자신이 즐겨 사용하는 AI 코딩 도구에 프롬프트를 입력합니다. 몇 번의 대화 만에 구글 로그인을 위한 OAuth 2.0 로직, 콜백 처리, JWT 토큰 발급까지 포함된 코드가 3시간 만에 완성됩니다. npm run test는 깔끔하게 통과합니다. 완벽합니다. 이 과정에서 AI는 개발자의 인지적 부담을 매우 줄여줬죠. AI를 사용한 개발의 시대가 매우 아름답게 느껴집니다.

하지만 일주일 뒤, '그 메시지'가 도착합니다.

클라이언트: "아, K 님. 저희가 내부 논의를 해봤는데, 서비스 핵심이 바이럴이라서요. 이거 사소한 변경인데, 회원 가입할 때 추천인 코드만 넣을 수 있게 해주세요."

이 사소한 변경에, K씨가 전에 만든 코드는 사실상 무용지물이 될 가능성이 커졌습니다. AI 코딩 도구는 "소셜 로그인만"이라는 첫 번째 지시에는 완벽히 부합하는 코드를 아주 쉽게 생성해 줬습니다. 하지만 그 코드는 추천인 제도를 통한 바이럴이라는 전체 제품 맥락을 고려할 수 없었기 때문에, 클라이언트의 요청은 절대 사소한 변경이 아니게 됩니다.

AI는 전체 제품 기획의 맥락을 파악하는 것이 아니라 사용자의 지시를 이행할 뿐입니다. 사용자의 지시가 명확하고 구조화되어 있지 않은 이런 상황에서 AI 도구의 막강한 생산성은, 빠르게 성공하게 해주는 것이 아니라 더 복잡하고 정교하게 실패하게 해주는 도구가 될 뿐입니다.

기획의 병목은 더 좁아지고 있다

1) 기획 병목은 언제나 있어왔다

사실 기획 병목이 어제오늘의 이야기인 것은 아닙니다. 기획 병목은 IT 업계의 오래된 숙제였습니다. 프로젝트 관리 협회(PMI)가 발간하는 보고서는 매년 프로젝트 실패의 큰 원인 중의 하나로 불분명한 요구사항 관리를 꼽아왔습니다. 예를 들어, PMI의 2014 보고서는 실패한 프로젝트의 무려 47%가 불분명한 요구사항 때문에 실패했다고 보고합니다. 제품 요구사항과 관련하여 클라이언트, 혹은 내부 기획자와의 의사소통 문제 때문에 실패한 프로젝트는 AI 코딩 도구가 등장하기 전에도 많았습니다.

기획 단계에서의 문제가 프로젝트 실패라는 가장 끔찍한 결과로 이어지지 않더라도, 여전히 기획 병목 문제는 실제 프로젝트에 영향을 끼칠 수 있습니다. 바로 기획 단계에서 제대로 명확하게 처리하지 못한 대가를 개발 단계, 제품 운영 단계에서 아주 비싼 값으로 치러야 한다는 문제죠.

기획 단계에서 문제를 제대로 잡아내지 못하고 그 문제를 개발 단계에서 발견하게 된다면, 혹은 제품 완성 이후에 발견하게 된다면 수십, 수백 배의 대가를 치러야 한다는 것은 모두가 아는 사실입니다. 소프트웨어 공학 분야의 권위자인 배리 뵘의 그 유명한 법칙이 바로 그러한 내용을 담고 있죠. 소프트웨어 프로젝트 중에 버그를 찾아 수정하는 비용은, 프로젝트가 진행될수록 기하급수적으로 증가한다는 내용입니다.

2) AI 시대, 그 병목은 더 좁아지고 있다

문제는, AI의 도움으로 개발의 생산성이 폭발적으로 향상된 지금, 이 병목이 더 좁아지고 있다는 점입니다. AI는 뵘의 법칙을 무효화해주지 못했고, 오히려 그 법칙의 시간 축을 압축시켜 버립니다. 기획 단계에서 제품 요구사항을 정확하게 확정 짓지 못하고, 정교하게 구조화하지 못한 채 빨라진 코딩 속도에만 의지해 개발을 시작하면, 그 아낀 시간을 결국 재작업으로 고스란히, 아니 그 이상으로 소모하게 됩니다.

아까 추천인 코드 예시로 돌아가 보겠습니다. 이 "사소한 변경”을 처리하기 위해 개발자 K씨는 이런 일들을 해야 합니다.

1. DB 스키마 변경: User 테이블에 referral_code (nullable, unique), recommended_by_user_id (foreign key) 등을 추가해야 합니다.
2. DB 마이그레이션: 기존 소셜 로그인 유저들에게도 이 스키마를 적용할 마이그레이션 스크립트를 작성하고 실행해야 합니다.
3. DTO 및 유효성 검사 로직 수정: RegisterUserDto 같은 데이터 전송 객체와 백엔드 유효성 검사 로직을 전면 수정해야 합니다.
4. 핵심 비즈니스 로직 수정: AuthService의 회원가입 로직을 "1. 소셜 로그인 -> 2. (선택적) 추천인 코드 입력 -> 3. 가입 완료"라는 새로운 플로우로 변경하고, 추천인 코드 유효성 검사, 포인트 적립(만약 있다면), 추천인-피추천인 관계 설정 로직을 모두 추가해야 합니다.
5. API 엔드포인트 수정: /auth/register와 같은 엔드포인트의 요청/응답 본문(Request/Response body)이 변경됩니다.
6. 프론트엔드 수정: 회원가입 UI에 "추천인 코드 (선택)" 입력 필드를 추가하고, 관련 상태 관리 로직(React Query, SWR 등)을 수정해야 합니다.
7. 테스트 코드 수정: 기존 AuthService 테스트 코드가 모두 깨지므로 수정하고, 신규 로직을 위한 테스트 코드를 작성해야 합니다.

결국 AI가 코딩 시간을 아껴준다고 하더라도, 예정에 없던 기획이 추가된 시점에서 프로젝트는 사실상 원점으로 돌아간 것이나 다름없습니다. 처음부터 기획이 정교하게 구조화되지 않는다면, 개발자들이 아무리 빠르게 일한다고 하더라도 결국 재작업 비율만 높아지고 그에 따른 개발자들의 허탈감과 피로감만 높아질 뿐, 전체 프로젝트에 사용되는 시간이 단축되지 않는 것입니다. AI를 통한 개발의 속도가 빨라질수록, 기획이라는 첫 단추를 잘못 끼웠을 때의 대가가 상대적으로 훨씬 더 고통스러워진 것입니다.

AI 시대, 핵심은 기획의 정확도

1) 기획은 더 정확하고 빠르게 구조화되어야 한다

결론적으로, 개발 영역에서 아무리 생산성이 증가했고 앞으로 더욱 더 멋진 코딩 도구가 등장하더라도, 기획이 그만큼 빠르고 정확하게 이루어지지 않으면 프로젝트 전체가 무의미하게 지연되고 불필요한 재작업 비용이 생성되는 핵심 문제는 해결되지 않습니다. 개발은 시속 100km로 질주하는데, 기획은 시속 10km로 걸어가고 있다면 프로젝트가 어떤 속도로 진행될까요? 그 과정에서 기획에 대한 불신만 뭉게뭉게 매연처럼 피어오를 뿐입니다.

지금까지 우리가 "어떻게 하면 AI를 활용하여 코드를 더 정확하고 빠르게 생산할 수 있는가?"에 몰두해 왔다면, 이제는 고민의 축을 이동해야 할 때입니다.

"어떻게 하면 AI를 활용하여 '기획'을 더 빠르고 정확하게 '구조화'할 수 있는가?"

여기서 핵심은 구조화입니다. 단순히 기존에 만들던 피피티(PPT)나 노션(Notion) 기획서를 지피티의 도움을 받아 더 빨리 쓰는 차원의 이야기가 아닙니다. AI 시대에 진정으로 필요한 기획이란, 클라이언트나 제품 책임자의 모호한 요구사항을 명확하게 확정 짓고, 개발자가 즉시 개발에 착수할 수 있는 구조화된 명세서를 산출하는 과정 자체의 혁신을 의미합니다.

흥미롭게도, 개발자들은 이미 이러한 변화의 필요성을 본능적으로 인지하고 있습니다. GitHub의 한 설문조사에 따르면, AI 코딩 도구를 통해 시간을 절약한 개발자들 중 40-47%는 그 시간을 시스템 설계 및 기획에 더 많이 투자한다고 답했습니다. 이는 개발자들이 코딩 자동화로 확보된 인지적 자원을 자연스럽게 더 상위의 문제, 즉 더 나은 기획과 아키텍처 설계에 재투자하고 있음을 보여줍니다. 개발 현장이야말로 기획의 중요성을 가장 절실히 느끼고 있는 곳입니다.

개발자가 AI 코딩 도구에 공급해야 할 진짜 ‘연료’는 다음과 같은 구조화된 산출물입니다.

• 정보 구조도: 어떤 메뉴들이 존재하고, 그 메뉴 간의 상하 관계(Depth)가 어떻게 되는가?
• 기능 명세서: 제품에는 어떤 기능들이 들어가야 하고, 각 기능에 세부 정책은 어떻게 되어 있는가?
• 유저 흐름도: 유저는 어떤 순서와 분기에 따라 이 기능을 경험하는가?

이것은 단순히 기획 문서를 쓰는 일이 아니라, 개발 이전에 시스템의 청사진을 그리는 요구사항을 엔지니어링하는 일입니다. AI를 활용하여 이러한 체계적인 문서의 형태로 기획 내용을 구조화할 수 있을 때, 우리는 AI 시대에 우리가 충분히 기획을 주목했다고 할 수 있을 것입니다.

마치며: AI 시대, 우리는 기획에 주목해야 한다

AI 코딩 도구이 강력해질수록, 그 도구가 태우는 연료인 기획의 중요성은 더더욱 커질 것입니다. AI 코딩 도구는는 강력한 F1 머신 엔진과 같고, 앞으로도 계속해서 강력해질 것입니다. 하지만 기획이라는 명확하고 구조화된 내비게이션이 없다면, 그 엔진은 엉뚱한 곳으로 빨리 질주하는 고철 덩어리에 불과합니다.

'바이브 코딩(Vibe Coding)'의 시대는 이미 펼쳐졌습니다. 우리는 바이브 코딩이라는 것을 매우 친숙하게 받아들이고 있죠. 최근 Figma는 컨퍼런스에서 '바이브 디자인(Vibe Design)'을 선언하며 디자인 영역의 AI 혁신을 예고했습니다.

우리는 IT 산업에 또 한 번의 거대한 생산성 혁신을 가져올 다음 단계, 즉 AI를 활용한 바이브 기획(Vibe Planning)에 주목해야 합니다. 여기서 바이브 기획이란, 비즈니스의 목표와 제품 사용자의 바이브(Vibe)를 포착하여, 디자이너 및 개발자들이 즉시 이해하고 실행할 수 있는 구조화된 명세로 전환하는 새로운 차원의 기획을 의미합니다. 개발자가 지긋지긋한 재작업과 소모적인 커뮤니케이션에서 벗어나, 진짜 개발의 즐거움에만 집중할 수 있는지는, 바로 이 기획에 얼마나 주목하느냐에 달려있습니다.

<참고>

manyfast.io/blog

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.