지난 시간 공유해 드렸던 바이브 코딩을 통한 기획과 설계의 긍정적인 경험 다들 기억하시나요?
💡지난 포스트 : 디자이너의 바이브 코딩 실전 후기 with Lovable
AI와 호흡을 맞춰 콘텐츠를 빠르게 구체화하며 얻었던 스피디한 생산성의 경험과는 반대로, 오늘은 우리가 AI 도구를 사용할 때 자칫 빠지기 쉬운 함정에 대해 이야기해 보려 합니다.
이제 AI 없이 문서를 작성하는 것이 오히려 더 어렵게 느껴지는 시대가 되었습니다. 덕분에 기획서 초안을 잡는 시간은 획기적으로 줄어들었고, 겉보기에는 작업 속도가 비약적으로 상승한 것처럼 보입니다. 하지만 아이러니하게도 전체 프로젝트의 최종 완료 시점은 우리의 기대만큼 앞당겨지지 않는 경우가 많습니다. 문서는 금방 완성되는데, 정작 그 문서를 보고 실무를 진행해야 하는 개발자와 디자이너 사이에서는 이전보다 더 많은 질문과 혼란이 오가는 광경을 마주하곤 합니다. 분명 작업의 시작점은 빨라졌는데, 왜 목적지까지 가는 길은 더 험난해진 걸까요?
그럴싸함이라는 독 : 맥락 없는 문서의 위험성
AI는 기획자가 준 기능 리스트를 바탕으로 아주 그럴싸한 PPT와 레이아웃을 만들어냅니다. 읽어보면 실제로 모두 맞는 말이에요. 내가 준 데이터로 만든 내용이니까요. 하지만 텍스트로는 완벽해 보였던 기능들이 정작 실제 화면 흐름으로 연결될 땐 툭툭 끊기는 현상이 발생합니다. 화려하게 그려진 PPT 슬라이드에 현혹되어 검증의 끈을 놓는 순간, 팀 전체가 정교하게 설계된 오류를 향해 전속력으로 달려가게 됩니다. 그래서 결국 이 문서는 예쁜 쓰레기 취급을 받게 되는 것이죠.
AI가 만든 초안은 문제 없는 이상적인 상황을 기본값으로 깔고 있습니다. AI는 수많은 데이터의 확률을 계산하여 가장 보편적이고 매끄러운 플로우를 제시하지만, 실제 서비스의 성패는 그 보편성 너머에 있는 예외 상황에서 결정됩니다. 따라서 AI가 제안하는 유저는 실제 유저가 겪을 수 있는 수많은 변수와 이탈 케이스가 완전히 배제되어 있다는 사실을 기억해야 합니다.
기획자가 AI의 초안을 유저 플로우로 옮기는 순간, 숨어있던 날카로운 질문들이 한꺼번에 터져 나오는 것은 어쩌면 당연한 일입니다. 결국 AI는 기획의 그럴싸한 골격은 만들어줄 수 있어도, 서비스의 성격과 비즈니스 목표에 부합하는 디테일까지 제시해 주지는 못합니다. AI의 결과물을 최종 목적지가 아닌, 치열한 검증을 시작하기 위한 밑바탕으로 취급해야 하는 이유가 바로 여기에 있습니다.
AI가 설계한 이상적인 유저
AI로 작성한 기획서는 곧장 이런 유저의 페르소나를 제공합니다.
- 제시된 모든 안내 문구를 꼼꼼히 정독하고,
- 설계자가 의도한 순서대로 버튼을 누르며,
- 목적을 달성할 때까지 이탈하지 않는 유저
이 자체는 전혀 틀리지 않고, 오히려 잘 정리되어 있어요. “입력값이 유효하지 않을 때 에러 메시지를 노출한다”거나, “네트워크 오류 시 재시도를 안내한다”, “권한이 없으면 접근을 제한한다”와 같은 항목들은 언뜻 보기에 매우 꼼꼼해 보입니다. 하지만 이 문장들은 현상에 대한 나열일 뿐, 서비스 전체를 관통하는 구조적 대안이 빠져 있습니다. 그 실패가 어느 지점에서 발생하고, 이후 플로우가 어떻게 이어지는지는 구조로 묶여 있지 않은 경우가 빈번합니다. 이러한 결과의 이유는 실패 이후의 연결된 동선에서 의사결정되는 유저의 과정을 놓치기 때문입니다.
실제로 AI의 초안을 검토하다 보면, 각각의 실패가 어느 시점에서 발생하며 그 직후 유저의 경험이 어떻게 이어지는 지에 대한 구조적 연결 고리가 느슨한 경우가 많습니다. 기획자는 AI가 던져준 단편적인 실패 케이스들만 고려할게 아니라 다음과 같은 구조적 질문들을 직접 던져야 합니다.
- 발생 기점 : 이 실패는 정확히 어느 프로세스 단계에서 발생하는가?
- 회복 경로 : 실패 상황에 처한 유저를 어디로 되돌려 보내야 가장 자연스러운가?
- 상태 복구 : 실패 시점에서 이전 상태로 안전하게 복구가 가능한가?
- 반복 대응 : 동일한 실패가 반복될 때 시스템은 어떤 단계적 방어 기제를 가동하는가?
결국 플로우를 명확히 정의하지 못한 문서는 유저를 미로 속에 가두는 것과 다름없습니다. 그 행간에 숨겨진 유저의 Pain Point를 읽어내어 구체적인 동선을 설계하는 것이 오늘날 기획자에게 요구되는 핵심 역량입니다. AI는 기획자가 의도한 비즈니스 맥락이나 유저의 미세한 심리 변화까지는 완벽히 파악하지 못합니다. 개발자가 코드를 짜고 오류를 검수하듯, 기획자도 AI 기획서의 논리 오류를 잡아내야 합니다.
AI를 대하는 두 가지 태도: 역할 분리와 피드백 루프
환상에 빠지지 않으려면 AI를 무턱대고 기획서 생성기로 쓰는 것이 아니라 역할을 분리하여 단계적으로 제어해야 합니다.
① 구조 모드 (Flow / Logic 중심)
먼저 AI에게 화려한 문장을 쓰게 하기 전에, 설계의 뼈대를 잡는 구조 모드를 실행합니다. 이때는 AI가 상상력을 발휘하여 빈틈을 메우지 못하도록 서술 금지에 가까운 엄격한 규칙을 부여하는 것이 핵심입니다.
화면 단위 분절 : 전체 프로세스를 세밀한 화면 단위로 나누어 정의합니다.
상태 전이 정의 : 각 화면에서 다음 화면으로 넘어가는 명확한 상태(State)를 규정합니다.
분기 조건 명시 : Yes/No 혹은 특정 조건에 따른 비즈니스 로직의 갈래를 강제로 생성하게 합니다.
예외 시나리오 강제화 : 정상 플로우가 아닌, 앞서 언급한 실패 시나리오를 의도적으로 먼저 뽑아내도록 명령합니다.
② 서술 모드 (기획서 / 공유용 문서)
구조가 확정된 후에야 문서화 단계인 서술 모드로 진입합니다. 1단계에서 확립한 플로우, 상태 정의, 제약 조건을 데이터로 입력하며 이렇게 명령합니다.
“이 구조를 전제로 기획서 초안을 다시 써줘”
이러한 단계적 접근이 필요한 이유는 명확합니다. AI는 기준이 명확하지 않으면 무한한 가능성을 동시에 열어두는 특성이 있습니다. 구현 범위와 원하는 유저 상태를 먼저 고정해두지 않고 AI에게 맡기면, AI는 확률적으로 가장 이상적이지만 정작 우리 서비스에는 맞지 않는 엇나간 초안을 끊임없이 내뱉게 됩니다.
많은 사람들이 구조 모드에서 나온 결과물을 대충 훑어보고 곧장 서술 모드로 넘어가곤 합니다. 하지만 1단계에서 정의한 내용에서 빈틈이 있다면, 2단계에서 AI가 만드는 문장은 그 빈틈을 교묘하게 정답같은 말로 덮어버립니다.
구조 모드 이후에는 반드시 논리 검증 단계가 선행되어야 합니다. AI가 뽑아준 상태 전이와 예외 시나리오를 보며, “이 단계에서 유저가 이탈하면 데이터는 어떻게 처리되는가?”, “정의되지 않은 제3의 선택지는 없는가?”를 스스로 질문하고 확정해야 합니다.
눈은 더 날카로워져야 합니다
AI는 기준이 없으면 너무 많은 가능성을 동시에 열어두게 됩니다. 그래서 원하는 결과와 구현 범위를 먼저 정해두고 쓰지 않으면 그럴듯하지만 엇나간 초안을 계속 다듬게 되죠. 특히 기획이나 디자인처럼 구조와 범위가 중요한 작업에서는 원하는 유저 상태와 구현 범위를 기준으로 먼저 고정해두고 AI를 쓰는 태도가 필요합니다. 그렇지 않으면 초안이 오히려 판단을 흐리게 됩니다.
물론 이런 방식이 모든 문제를 해결해주지는 않습니다. 서비스의 핵심 전환 지점이나, 정책과 이해관계가 얽힌 영역, 유저의 미묘한 감정 변화를 설계해야 하는 순간에는 여전히 사람이 직접 판단해야 합니다. 다만 분명한 건, AI가 잘 작동하는 구간과 위험해지는 구간은 생각보다 또렷하다는 점입니다. 구조가 아직 열려 있고 경우의 수를 넓게 탐색해야 할 때는 강력하지만, 방향이 고정돼야 하는 지점까지 맡기는 순간 오히려 판단을 흐리게 만듭니다. 결국 예쁜 쓰레기를 줄이는 방법은 AI에게 어디까지 맡기고 어디서부터 다시 가져올 지를 먼저 정하는 데 초점을 두어야 하는 것입니다.
최신 마케팅/고객 데이터 활용 사례를 받아보실 수 있습니다.