미어캣굴

사진: Unsplash의Florian Olivo

프로그래밍을 배우지 않고도 웹앱 하나쯤 만들 수 있는 시대가 왔다. 기획자 입장에서 이보다 반가운 소식이 있을까.

예전엔 아이디어가 떠올라도, 개발자에게 상세 기획서를 전달하고 구현 가능성을 따져보며 몇 번의 커뮤니케이션을 거쳐야 했다. 그마저도 개발 우선순위에 밀리면 실현되기 어려웠다.

하지만 지금은 다르다. 생성형 AI 기술의 발전은 '말로 만드는 서비스'를 현실로 만들고 있다.

특히 요즘 자주 들리는 키워드, ‘바이브 코딩(Vibe Coding)’은 그 흐름의 상징처럼 언급된다.

타이핑보다 말이 빠르다는 어느 개발자의 고백, 프롬프트 한 줄로 앱 프로토타입을 뽑아내는 실험 결과들,

그리고 실제로 코딩을 몰라도 Cursor, Replit, Claude 같은 툴을 활용해 결과물을 만들어낸 사례들.

서비스 기획자는 더 이상 ‘화면을 그려주는 사람’에 머무르지 않는다. 이제는 직접 MVP를 만들어볼 수 있는 손을 갖게 된 셈이다.

텍스트만 잘 다루면 된다. 문제를 서술하고, 요구를 설명하고, 흐름을 조율하면, AI가 코드로 번역하고 결과로 보여준다.

기술의 진입장벽이 낮아질수록, 기획자의 영향력은 커질 수도 있다.

실행의 속도, 실험의 횟수, 설득의 과정 모두 달라질 수 있기 때문이다.

하지만 그럴수록 남는 질문도 있다.

이건 정말 기획자의 ‘무기’가 될 수 있을까? 아니면 '무기'를 가장한 '함정'일까?

사진: Unsplash의Shoeib Abolhassani

1. 설명할 수 있는 아이디어가 손으로 만들어진다

왜 무기인가?

“아이디어 → 코드 → 결과물” 사이의 시간이 비약적으로 단축되기 때문이다.

기획자의 오래된 고민 중 하나는 ‘이걸 어떻게 보여줄까’다. 말로 설명하자니 감이 안 오고, 와이어프레임으로는 부족하다.

프로토타입을 만들고 싶지만, 툴도 낯설고 구현은 더더욱 어렵다.

하지만 지금은 다르다.

예를 들어,

“이메일을 입력받아서 DB에 저장하는 간단한 폼 만들어줘.”

라고 프롬프트를 던지면, Cursor 같은 툴은 HTML과 Firebase 연동 코드까지 덜컥 만들어낸다.

그 코드가 완벽하다는 뜻은 아니다. 하지만 이걸 실행해서 눈으로 보여줄 수 있다는 게 중요하다.

디자인 없이도, 스토리보드 없이도, 기획을 ‘보여주는’ 시대가 열린 셈이다.

실행물은 언제나 말보다 설득력이 있다.

기획서 없이 기획을 증명하는 것, 이것이야말로 속도와 신뢰의 결정판이다.

2. 사전 검증용 MVP를 스스로 만들 수 있다

왜 무기인가?

‘가설’이 실제 유의미한지, 개발 리소스를 쓰기 전에 미리 실험해볼 수 있기 때문이다.

기획자는 항상 선택과 집중의 문제에 부딪힌다.

‘이 기능이 정말 필요한가?’

‘우선순위를 어디에 둘 것인가?’

예전엔 A/B 테스트를 하려면 꽤 많은 리소스가 필요했다.

하지만 지금은,

“검색창 + 태그 필터 기능이 있는 이벤트 아카이브 페이지 만들어줘.”

라고 입력하면, HTML과 JS 코드가 자동으로 구현된다.

실제 데이터는 더미 JSON으로 채워서 인터랙션을 체험해볼 수 있다.

물론 이건 실서비스는 아니다. 하지만 MVP 수준의 체험은 가능하다. 반응을 테스트하고, 피드백을 받을 수 있다.

‘아이디어를 바로 실험할 수 있는 능력’은 이제 기획자에게도 가능한 일이 되었다.

그 자체로 ‘개발 요청 리스트’는 더 정제되고, 기획 우선순위는 더 명확해진다.

3. 기능 정의 능력 = 프롬프트 작성력

왜 무기인가?

기획자가 평소에 다져온 ‘요구 정리 능력’이 AI의 성능에 그대로 반영되기 때문이다.

AI에게 바라는 건 ‘센스’가 아니다.

프롬프트라는 입력값을 통해 조건을 명확히 설정하는 것이다.

예를 들어,

❌ “UX를 직관적으로 개선해줘” → AI는 ‘직관적’이 뭔지 모른다.

✅ “화면 크기 768px 이하일 때 사이드바를 접히는 토글 버튼으로 바꿔줘” → 명확하다.

기획자라면 이 차이를 직감적으로 안다.

정확한 요구, 조건화된 언어, 예외 사항까지 고려한 시나리오. 이런 역량은 프롬프트를 구성할 때 빛을 발한다.

즉, 기획을 잘하는 사람일수록 AI를 잘 다룬다. 이건 단순한 사용법의 문제가 아니라,

‘정확히 설명할 수 있는 사람’이 결과도 빠르고 정확하게 끌어낸다는 뜻이다.

4. 협업 언어로서의 ‘자연어’

왜 무기인가?

바이브 코딩은 개발자뿐 아니라 디자이너, 마케터와의 협업에도 유용한 인터페이스다.

예를 들어,

디자이너가 “이 인터랙션, 구현 가능해?”라고 물을 때,

기획자는 그 자리에서 AI에게 시켜 구현해볼 수 있다. 심지어 웹에서 바로 돌려보고, 필요하다면 GIF로 녹화해 보여줄 수도 있다.

이건 회신 속도를 단축시키는 것을 넘어, 팀 내 역할을 더 명확하게 만들고 커뮤니케이션의 허들을 낮춰주는 기능이다.

기획자는 원래도 팀의 중간자였다.

이제 그 역할을 더 빠르고 명확하게 할 수 있게 된 것이다.

자연어는 모두의 언어다. 바이브 코딩은 기술이 아니라, 협업을 위한 도구에 가깝다.

1. 코드가 작동한다고 해서 ‘써도 되는 코드’는 아니다

왜 함정인가?

실행되는 것과 ‘서비스에 쓸 수 있는 것’은 다르기 때문이다.

AI가 만들어주는 코드는 겉보기에 완성형처럼 보인다. 로그인 화면도 만들고, 버튼도 눌리고, 데이터도 저장된다.

하지만 그게 진짜 ‘써도 되는 코드’일까?

예를 들어,

AI가 만들어준 로그인 기능에는 세션 처리가 없다.

입력값 검증도 빠져 있고, 아이디와 비밀번호가 암호화되지 않은 채 전송된다.

기획자는 실행된다는 이유만으로 안심하지만,

개발자가 코드를 검토하는 순간 말한다.

“이건 실제 서비스에서는 절대 쓰면 안 되는 코드예요.”

코드가 돌아간다고 해서 그게 곧 완성이라는 착각은,

기획자에게 치명적인 리스크다.

특히 보안, 성능, 확장성은 기획자가 쉽게 파악할 수 없는 부분이라 더 위험하다.

2. 프롬프트가 모호하면, 결과물은 더 엉망이다

왜 함정인가?

요구가 구체적이지 않으면, AI는 ‘알아서’ 이상한 선택을 하기 때문이다. AI는 사람처럼 “그 느낌 뭔지 알지?”를 모른다.

그래서 프롬프트가 모호하면, 엉뚱한 해석을 한다.

예를 들어,

“모던한 느낌으로 디자인 바꿔줘”라고 하면,

버튼은 커지고, 폰트는 고딕, 컬러는 온통 파란색으로 덮인다.

“뉴스 기사 페이지처럼 만들어줘”라고 하면,

헤드라인만 덜렁 뜨고 나머지는 없다.

기획자가 기대한 ‘구체적 구조’나 ‘레이아웃 기준’이 명시되지 않으면

AI는 ‘자기만의 기준’으로 결과를 생성한다. 결국 기획자는 결과물을 다시 수정해야 하고, 처음부터 정확하게 전달했으면 없었을 소통 비용이 반복된다. AI와의 협업은 오히려 더 고도로 정제된 언어 능력을 요구한다.

3. 문제 생기면 ‘아무것도 못 한다’

왜 함정인가?

AI가 만들어준 코드를 이해하지 못하면, 에러 발생 시 손쓸 방법이 없기 때문이다.

코드가 잘 돌아갈 때는 문제없다.

하지만 작은 이슈라도 생기면, 진짜 고비는 그때부터다.

예를 들어,

버튼을 눌렀는데 아무 동작이 없다.

콘솔에는 오류 메시지가 계속 뜨는데, 이게 무슨 뜻인지 도무지 모르겠다. 결국 기획자는 다시 개발자에게 요청할 수밖에 없고,

“이건 제가 만든 건데…”라는 민망한 상황도 생긴다. 기획자가 직접 만든 코드인데, 고칠 수는 없다면

그건 자율이 아니라 ‘의존’이다. 이런 상황이 반복되면, 팀 내 신뢰나 속도 모두 손해를 본다.

4. 완성물을 ‘관리’할 수 없다

왜 함정인가?

처음엔 빨리 만들어지지만, 유지보수는 불가능에 가깝기 때문이다.

AI는 빠르게 코드를 만들어주지만,

그 구조가 실무에서 유지하기 좋은 방식인 경우는 거의 없다.

예를 들어,

기능이 5개 들어간 페이지를 만들었는데, 코드가 전부 한 파일에 뒤엉켜 있다.

기획자는 “여기 이 기능만 수정하면 되겠지” 싶지만,

실제로는 전체를 다시 짜야 할 상황이 벌어진다. 모듈화도 없고, 네이밍도 직관적이지 않다.

심지어 예외 처리나 사용자 대응 흐름도 정리되어 있지 않다. 결과적으로 초기 구현 속도는 빠를 수 있어도,

실제 운영 단계에서 발생하는 문제를 감당할 수 없다. 서비스는 ‘만드는 것’보다 ‘관리하는 것’이 더 어렵다는 걸 잊지 말아야 한다.

정리하자면

• 셀 병합
• 행 분할
• 열 분할
• 너비 맞춤
• 삭제

그래서 기획자는 어떻게 대비해야 하나?

바이브 코딩은 기획자에게 분명 기회다.

하지만 그것이 곧바로 ‘실무 생산성’으로 이어지려면, 몇 가지 준비와 분별이 필요하다.

기획자는 더 이상 단순히 ‘아이디어를 설명하는 사람’이 아니다.

이제는 ‘기술을 다루는 기획자’가 되어야 한다.

그렇다면, 구체적으로 어떻게 준비해야 할까?

1. 코드를 ‘읽는 능력’부터 키운다

직접 짜는 것보다 먼저, 이해하고 해석할 수 있는 능력이 중요하다.

HTML/CSS/JS의 기초 구조 정도는 ‘구문 분석’할 줄 알아야 한다.

코드 한 줄의 의미를 알고 있어야, AI가 무슨 실수를 했는지도 파악할 수 있다.

• 최소한 콘솔 에러 메시지를 읽고, 키워드를 검색할 수 있어야 한다.
• ChatGPT에게 오류 로그를 붙여넣을 수 있을 정도의 ‘이해력’만 있어도 괜찮다.

이건 개발자가 되자는 말이 아니다. 기획자도 구글링이 가능해야 한다는 뜻이다.

2. 프롬프트를 ‘기획서처럼’ 쓴다

프롬프트는 요청이자 설계다.

기획자가 평소 쓰는 기획안처럼, 프롬프트도 조건, 예외, 목적이 명확해야 한다.

❌ "깔끔한 디자인으로 바꿔줘"

✅ "배경은 흰색, 텍스트는 검정, 버튼은 원형으로 파란색이며 hover 시 그림자 효과 추가"

• 문장으로 기획서를 쓰는 연습이 필요하다.
• 구체화하는 습관이 프롬프트의 질을 바꾼다.

AI는 센스를 보완해주는 도구가 아니다. 센스를 구조화하는 도구다.

3. ‘테스트 환경’을 일상화한다

기획자가 만든 코드가 실제 서비스에 바로 쓰일 일은 드물다.

하지만 ‘실험실’에서는 얼마든지 써볼 수 있다.

테스트 공간을 만드는 습관이 기획자의 실험력을 높인다.

• Replit, CodePen, Vercel 같은 툴로 테스트 페이지를 직접 띄워보자.
• 가상의 데이터를 활용해 가설을 시각화해보는 연습을 하자.

한 줄 코드가 아닌, ‘시나리오 단위’로 결과물을 점검하는 눈이 생긴다.

4. ‘실무로 쓸 수 없는 코드’를 구분하는 감각

AI가 만들어준 코드는 빠르고 편하지만,

보안, 성능, 구조 측면에선 실무 투입이 어렵다.

• 로그인/회원가입처럼 민감한 기능은 ‘개발자 리뷰 필수’로 명시하자.
• 입력값 검증, 인증 처리 등은 ‘검토 체크리스트’를 만들어 놓는 것이 좋다.

기획자에게 필요한 건 완벽한 구현이 아니다. “이건 실무에서 검토가 필요하다”는 판단 기준이다.

5. 개발자와의 역할 구분을 재정의한다

바이브 코딩을 잘하는 기획자는 개발자를 대체하지 않는다.

오히려, 더 정제된 질문과 더 정확한 명세서를 전달하게 된다.

• “이거 되나요?” 대신 → “여기까지 AI로 만들었고, 이 부분에서 API 연동이 필요해요”
• “이렇게 구현해주세요” 대신 → “이건 AI가 만든 코드인데 리뷰 부탁드려요”

즉, 바이브 코딩은 ‘개발자의 영역을 침범하는 도구’가 아니라, ‘더 나은 협업을 위한 브리프’다.

사진 설명을 입력하세요.

바이브 코딩은 기획자에게 새로운 역할을 부여한다.

예전처럼 ‘기획서만 잘 쓰는 기획자’로는 부족하다.

실행해보고, 실험해보고, 구조를 판단할 수 있는 기획자가 필요한 시대다.

그리고 그 변화는, 지금 이 글을 읽고 있는 기획자부터 시작될 수 있다