[AI 활용 기록] AI로 서비스 기획안을 만들며 다시 배운 것

배경

올해 초부터 Claude를 활용해 개인 포트폴리오를 만드는 것을 시작으로, 이런저런 아이디어를 구체화하는 작업을 계속해왔다.

 

그런데 결과가 좋은 산출물로 이어지는 경우는 생각보다 드물었다. 아이디어 하나를 던지면 AI가 뭔가 그럴듯한 걸 만들어주긴 하는데, 정작 그걸 다듬으려고 다시 프롬프트를 입력하면 오히려 이미 괜찮았던 부분까지 망가지는 일이 반복됐다. 그러다 보면 결국 처음부터 다시 정리하거나, 아예 중단하는 경우가 많았다.

 

Claude, OpenAI로 시도해 본 아이디어 구체화와 목업 생성 시도

 

요즘은 "바이브 코딩"이라는 이름으로 관련 콘텐츠가 쏟아진다. 그런데 정작 "무엇이 좋은 바이브 코딩이고, 어떻게 해야 실제 결과로 이어지는가"에 대한 답은 어디서도 명쾌하게 찾기 어려웠다.

 

그 답을 직접 확인해보고 싶어서 CJ AI Wave 교육을 수료중이며, 이 글은 그중 3일간 진행한 "AI로 서비스 기획안 만들기 → 와이어프레임 제작" 실습을 복기 한 기록이다. (실습에 사용한 서비스 아이디어와 구체적인 콘텐츠는 현재 교육 과정에 진행중이기 때문에, 서비스 세부 내용을 블러 처리해 사고 과정의 흐름만 보이도록 했다.)

---

이전 시도 — 무엇이 반복적으로 실패했나

돌이켜보면 이전의 패턴은 항상 비슷했다.

 

 

 

아이디어를 던진다 → AI가 결과를 준다 → 마음에 안 드는 부분이 보인다 → "이거 고쳐줘"라고 다시 요청한다 → 그런데 고쳐달라고 한 부분만 국소적으로 바뀌고, 전체 구조와의 정합성은 오히려 깨진다 → 결국 처음부터 다시 정리한다.

 

이 패턴이 반복되면서 점점 지쳤다. "AI가 성능이 부족한가", "내가 AI로는 개발을 할 수 없는건가"라고 생각한 적도 많았다.

 

그런데 이번 실습을 통해 나서야 진짜 원인을 알게 됐다. 문제는 AI가 아니라, 내가 무엇을 원하는지 스스로 정의하지 않은 채로 판단을 AI에게 떠넘긴 것이었다. "이거 고쳐줘"는 요청이지 기준이 아니다. 무엇을 기준으로 고쳐야 하는지 나조차 몰랐으니, AI도 알 수 없었던 거다.

---

시도 — 3일간의 과정

접근 방식의 전환

이번에는 개발이나 디자인을 시작하기 전에, "좋은 서비스 기획안은 어떤 구조를 가지는가"부터 먼저 분석했다.

 

우수한 기획안 레퍼런스를 살펴보고, 단순히 기능을 나열하는 방식이 아니라 Question → 유사 서비스 분석 → Big Idea로 이어지는 흐름을 먼저 파악했다. 그리고 그 구조를 기준 삼아 내 아이디어를 채워 넣는 방식으로 접근을 바꿨다.

 

질문 발전 과정과 패턴

아이디어를 그대로 서비스로 옮기지 않고, 매 단계마다 스스로 되묻는 과정을 반복했다. 패턴으로 정리하면 이렇다.

Idea (평소 품고 있던 의문)
  → "이걸 증명할 데이터가 있는가?"
  → "관련된 효과는 무엇인가?"
  → (검증된 근거 위에서) 서비스 방향성 재정의

 

아이디어의 시작은 평소의 의문에서 출발했다. 이 의문을 그냥 서비스 컨셉으로 바로 옮기지 않고, 이를 뒷받침할 시장 데이터를 먼저 요청했고,  실제로 어떤 과학적, 상업적 효과를 갖는지 근거를 찾아 보강했다.

동시에 캔바에서 내용을 바탕으로 조사와 분석을 진행했다.

 

 

이 패턴은 기획의 거의 전 구간에서 반복됐다. 서비스의 차별점을 시각화하는 포지셔닝 맵을 만들 때도, 축 정의를 한 번에 확정하지 못하고 세 번 정도 다시 물었다. "이게 정말 내가 하려는 말이 맞나?"를 되물으며, 다시 "이 단어가 사용자 입장에서 뭘 의미하는지 애매하다"는 걸 스스로 생각하고 질문하며 최종 정리했다.

 

 

유사 서비스 분석부터 포지셔닝 맵 컨텐츠 완성

 

 

 

다이어그램도 마찬가지였다. 내가 기획한 서비스는 기능이 유연하게 순환되는 것이 핵심 주제였고,  해당 구조를 표현하기 위해 형태까지, 총 네 번 형태를 바꿨다.

 

원형 벤 다이어그램 → 세로형 순환 → 일간/주간/월간이 중첩된 순환 → 타임라인 표

Claude로 빠르게 구조를 확인하는 과정

 

AI가 만든 결과물의 완성도가 낮아서가 아니라, 매번 "내가 진짜 표현하고 싶은 게 정확히 뭐지?"를 스스로 더 명확하게 다듬어가는 과정이었다. 해당 부분에서 AI로 low quality 다이어그램을 빠르게 만들어 보며 기획안에서의 구성을 비교하여 빠르게 선택할 수 있었다. 

---

도구를 목적에 맞게 교차 활용

한 가지 도구만 붙잡고 반복하기보다, 목적에 따라 다른 AI를 병행하는 게 훨씬 효율적이었다.

• Claude는 긴 문서를 이해하고 논리적 구조를 설계하는 데 강했다. 질문을 기반으로 유사 서비스를 분석하고 차별점을 도출하면서, 서비스명·슬로건·핵심 가치까지 하나의 논리로 자연스럽게 연결할 수 있었다.
• GPT는 아이디어를 빠르게 시각화하는 데 강했다. 텍스트로만 존재하던 개념을 목업과 로고 이미지로 구체화하면서, 아이디어가 실체를 갖는 경험을 할 수 있었다.

이후 IA와 화면 구조를 설계하는 단계에서는 두 AI를 번갈아 활용해 한쪽이 만든 결과를 다른 쪽에게 검토·보완시키는 방식을 썼다. 이 교차 검증 과정에서, 처음 기획안에는 없었던 세부 내용(컴포넌트 정의, UX 원칙, 화면 간 이동 구조 등)까지 자연스럽게 구체화됐다.

Claude로 시스템 정리 후 GPT로 목업 시도

---

기획안이 구체화된 순서

전체 흐름을 정리하면 다음과 같은 순서로 진행됐다.

1. 수요 분석 → 페르소나 설정 → Needs 분석 → 니즈별 솔루션 도출 → 솔루션별 핵심 키워드 정리
2. 유사 서비스 분석·분류 → 포지셔닝 맵 → 포지셔닝별 특징 → 서비스 기능 순환 플로우 → 브랜드 아이덴티티(로고, 슬로건)
3. IA 설계 → User Flow 정의 → 화면별 역할/컴포넌트 정의 → 디자인 시스템 → UX 원칙 → 와이어프레임 제작

각 단계가 끝날 때마다 "이 내용이 앞 단계의 논리와 여전히 맞는가"를 계속 되짚었다. 이 반복적인 재검증이 없었다면, 아마 각 슬라이드가 따로 노는 기획서가 됐을 것이다.

단계별 산출물 (와이어프레임은 현재 작업중!)

---

배운 점

이번 경험에서 가장 크게 배운 것은, AI의 성능보다 입력되는 정보의 구조와 맥락이 결과의 품질을 결정한다는 것이었다.

 

어제 혼자 정리하다 문득 이런 문장을 적었다.

AI에게 입력하는 질문 자체보다, 그 질문을 만들어내는 사고 과정이 더 중요하다. 질문은 결과이고, 그 질문을 만드는 사고력이 핵심이다.

 

이번 3일이 정확히 이 문장을 증명하는 과정이었다. 좋은 결과가 나온 순간은 전부 "프롬프트를 더 정교하게 썼을 때"가 아니라, "내가 무엇을 원하는지 스스로 다시 정의했을 때"였다. 포지셔닝 맵의 축이 세 번 바뀐 것도, 순환 다이어그램이 네 번 바뀐 것도, AI가 더 나은 답을 제시해서가 아니라 매번 내가 "이게 진짜 내가 하려는 말인가"를 스스로 검증한 결과였다.

 

또 하나 배운 건, 목적에 따라 서로 다른 AI를 병행하는 게 하나의 AI만 붙잡고 반복하는 것보다 훨씬 효율적이라는 점이다. AI는 서비스를 스스로 설계해주지 않는다. 내가 정의한 방향을 기반으로 내용을 구체화해주는 도구일 뿐이고, 결국 어떤 질문과 기준을 제시하느냐가 결과의 품질을 결정한다.

 

"개선하려던 프롬프트가 오히려 망친다"던 예전의 실패도 다시 보였다. 그건 AI의 한계가 아니라, 무엇을 개선하고 싶은지 나 스스로 정의하지 않은 채로 개선을 요청했기 때문이었다.

---

아쉬운 점

시각 자료와 다이어그램 제작은 여전히 사람이 직접 손을 대야 하는 영역이 많았고, 무료 플랜에서는 원하는 수준의 결과물을 얻는 데 한계가 있었다. 결과물을 기획 의도에 맞게 다시 수정하는 데 생각보다 많은 시간이 들었다.

 

가장 크게 느낀 아쉬움은 따로 있었다. 와이어프레임에 대한 기준이 나와 AI 사이에서 서로 달랐다는 점이다. 생성된 결과물은 와이어프레임이라고 하기엔 지나치게 디테일했고, 그렇다고 실제 UI 목업이라고 하기엔 완성도가 부족한, 애매한 중간 단계의 결과였다.

 

기대한 와이어 프레임

 

프롬프팅 결과 만족스럽지 않은 애매한 와이어프레임 산출물

 

'와이어프레임'이라는 단어 하나만으로는 표현 범위와 디테일 수준에 대한 합의가 되지 않는다는 걸 뒤늦게 깨달았다. 복기해보면 좋은 와이어프레임이란 무엇인가에 대한 나의 생각 발전 과정이 와이어프레임 작업 과정에서 빠져서 나온 아쉬운 결과인 것 같다.

 

토큰 한도로 인해 중간중간 결과를 세밀하게 검토하며 수정할 기회가 충분하지 않았던 것도 아쉬웠다. 조금씩 확인하며 다듬었다면 더 나은 결과가 나왔을 거라는 생각이 든다.

---

다음에 시도할 것

다음번에는 결과물을 바로 요청하기보다, "와이어프레임이 무엇인지, 어떤 수준을 원하는지"를 AI와 먼저 합의하는 단계를 거칠 생각이다. '와이어프레임'이라는 단어만 던지지 않고, 화면의 목적과 표현 범위, 디테일 수준까지 먼저 맞춰본 뒤 제작을 시작하면 원하는 결과에 훨씬 가까워질 거라고 본다.

 

또한 한 번에 최종 결과를 요청하는 방식 대신, 기획 → IA → 화면 구조 → 와이어프레임 → UI 목업처럼 단계를 잘게 나누고, 매 단계마다 결과를 검토한 뒤 다음 단계로 넘어가는 프로세스를 적용해보고 싶다.

 

마지막으로, Pro 환경에서 프로젝트 전용 컨텍스트를 축적하는 방식을 시도해보고 싶다. 좋은 기획안과 서비스 레퍼런스뿐 아니라 디자인 시스템, UI 패턴, 컴포넌트 구조를 지속적으로 AI에게 제공해서 프로젝트의 맥락을 쌓아가고, 이를 기반으로 와이어프레임과 UI/UX 초안까지 일관성 있게 생성하는 워크플로우를 경험해보고 싶다.

---

마무리 — 시사점

개발자든 기획자든 프로덕트 메이커든, 이번 경험이 던지는 메시지는 결국 하나로 모인다. AI 시대의 경쟁력은 AI를 능숙하게 다루는 기술이 아니라, 내가 무엇을 원하는지 스스로 아는 능력, 그리고 좋은 질문을 만들어내는 사고력이라는 것이다.

 

AI를 결과물을 찍어내는 도구로만 바라보면, 첫 번째로 나온 그럴듯한 결과에 만족하고 멈추기 쉽다. 하지만 진짜 결과는 그 첫 결과물을 보고 "아니, 이게 아니야"라고 계속 되물을 수 있을 때 나온다.

 

AI는 내 생각을 대신해주지 않는다. 다만 내가 떠올린 생각을 빠르게 시각화하고, 다양한 형태로 비교하며 검증할 수 있도록 도와주는 도구다. 중요한 것은 AI가 만들어낸 결과물이 아니라, 그 결과를 바탕으로 내 생각을 계속 수정하고 발전시키는 과정이다.

 

이번 경험을 통해 내가 배운 바이브 코딩의 가치는, AI에게 답을 맡기는 것이 아니라 AI를 활용해 더 빠르게 사고를 발전시키는 데 있다는 것이었다.