설계는 즐겁다.
“로그인 기능 만들어줘.”
예전엔 이 한 문장이 회의실에서 끝나지 않았다.
화면 정의서, 기능 목록, 예외 케이스, 개발 일정…
로그인 하나로 문서가 자랐다.
그런데 요즘은 다르다.
AI에게 말을 걸면, 결과물이 바로 나오기도 하는 시대다.
개발이 바이브 코딩(Vibe Coding)으로 빨라질수록, 기획의 역할은 어떻게 변해야 할까?
기획자는 화면을 그리는 사람이 아니라, 비즈니스의 원리와 의도(Intent)를 설계하는 사람이 되어야 한다.
나는 이 변화를 이렇게 정리해 본다.
기획은 이제 “문서”가 아니라, 아키텍처(Architecture)가 된다.
과거의 기획은 자연어와 와이어프레임으로 의도를 설명했다.
앞으로의 기획은 AI가 오해 없이 실행할 수 있는 구조로 의도를 만든다.
말하자면,
“로그인 화면이 필요해요”가 아니라
“누가, 언제, 어떤 조건에서, 무엇을 통과해야, 어떤 상태가 되는가”를 정의하는 일이다.
여기서 중요해지는 게 두 가지다.
자연어의 정밀화
기획자의 문장은 더 ‘예쁘게’가 아니라 더 ‘정확하게’ 진화한다.
요구사항을 비즈니스 규칙(Business Rules)과 예외 상황으로 쪼개고, 서로 충돌하지 않게 맞춘다.
결국 화면보다 먼저 나오는 건 이런 질문이다.
비밀번호 5회 실패 시 무엇이 잠기는가?
잠김은 얼마나 유지되는가?
고객센터 해제는 가능한가?
법/보안/브랜드 정책과 충돌은 없는가? 같은 질문이다.
BPM의 부활
BPMN 같은 표준 프로세스 모델은 AI에게 꽤 친절한 설계도다.
기획자는 기능을 나열하는 사람이 아니라, 업무의 처음부터 끝까지(End-to-End)를 데이터와 흐름으로 설계하는 비즈니스 아키텍트가 된다.
화면은 결과다.
원인은 프로세스와 규칙이다.
기획이 문서를 만드는 과정이었던 이유는 간단했다.
“만들기 전에 확인”해야 했기 때문이다.
하지만 AI가 실시간으로 구현을 돕기 시작하면,
기획 단계에서 이미 동작하는 것을 보며 검증한다.
실시간 가상 시나리오
예전엔 이런 말을 했다.
“아마 이 구간에서 이탈이 있을 것 같아요.”
이제는 이렇게 된다.
“이 흐름으로 시뮬레이션 돌려보니, 가입 전환이 여기서 꺾이네요.”
기획은 주장보다 가설–검증 루프가 빨라진다.
문서가 ‘설득 도구’였다면, 시뮬레이션은 ‘판단 도구’가 된다.
기획-개발 경계의 소멸
정의한 의도가 바로 알파 버전으로 떠오르면,
“기획-개발-검토”는 일(日) 단위가 아니라 분(分) 단위로 줄어든다.
문서는 더 이상 본문이 아니다.
실행이 본문이고, 문서는 부록이 된다.
이제 기획자는 사람에게 일을 나누는 것만으로 부족하다.
목적이 다른 AI들을 묶어 일하게 만드는 감독관이 된다.
나는 이 역할이 꽤 “지휘자” 같다고 느낀다.
악기가 사람에서 에이전트로 바뀌었을 뿐이다.
프롬프트 엔지니어링의 고도화
핵심은 멋진 문장이 아니다.
전략을 컨텍스트로 바꿔 주입하는 능력이다.
이 기능은 어떤 비즈니스 목표를 위한 것인지
어떤 정책을 절대 어기면 안 되는지
어떤 데이터만 써야 하는지
결과물의 품질 기준은 무엇인지
AI는 실행이 빠르다.
그래서 더더욱, 입력의 구조가 실력이 된다.
Guardrail: 최종 의사결정자의 자리
AI가 만든 결과물이 “그럴듯한가”가 아니라
“우리 서비스의 윤리/보안/브랜드/정책에 맞는가”를 판단해야 한다.
기획자는 점점 더 검토자이자 책임자가 된다.
빠른 실행을 허용하되, 망가지는 방향으로 빨라지지 않게.
속도가 빨라지면 지식은 파편화된다.
회의는 늘고, 결정은 쌓이고, 근거는 흩어진다.
AI는 데이터를 처리해 주지만,
우리 서비스만의 철학까지 자동으로 만들어주진 않는다.
그래서 PKM(개인 지식 관리)은 취미가 아니라 인프라가 된다.
컨텍스트 저장소
의사결정 이력
시장분석과 근거
실패 기록과 회고
정책의 변천
“우리는 이걸 왜 안 하기로 했는가”의 이유
이것들을 Obsidian 같은 도구로 축적해 두면,
AI는 그 저장소를 통해 “우리답게” 일할 수 있다.
결국 기획자의 실력은
의도를 설계하는 힘 + 맥락을 보존하는 힘으로 나뉜다.
도구는 “설명(PPT/Word/Figma)”에서 “실행(AI Prompt/Workflow/Logic Model)”로 이동한다.
업무는 “요구사항 상세화/조율”에서 “비즈니스 로직 설계/에이전트 지휘”로 이동한다.
산출물은 “문서”에서 “동작하는 프로토타입 + 비즈니스 아키텍처(프로세스·룰·데이터·가드레일)”로 이동한다.
결론적으로,
개발이 ‘Vibe’로 해결되는 시대에 기획자는 What보다
Why와 How it works logically를 정의하는 사람으로 이동한다.
화면을 그리는 Writer가 아니라,
비즈니스의 원리와 데이터 흐름을 설계하는 Product Architect로.
바뀐 역할은 “감”이 아니라 “지식 체계”로 지탱된다.
기존의 BOK들과 AI 워크플로우를 연결하면, 기획자의 역량은 네 가지 층으로 정리된다.
가치 제안/수익 구조 설계
목표–로드맵 정렬(Strategy Analysis)
문제를 데이터/로직으로 구조화
가설을 시뮬레이션으로 검증
BPMN 2.0으로 End-to-End 모델링
비즈니스 룰/정책을 의사결정 테이블로 구조화
프로세스 마이닝으로 병목/낭비 탐지
도메인 모델(Entity/Relationship) 정의
인텐트 구조화(오해 없는 입력 설계)
에이전트 오케스트레이션(역할/순서/데이터 전달)
데이터 스키마(JSON 등) 선정/정의
RAG 전략(지식 베이스 구성/연결)
AI Guardrails(윤리/보안/정책 준수)
KPI/성능 지표로 전후 비교
변경/버전/형상 관리
엣지 케이스 중심 QA 시나리오
BPM CBOK이 업무 흐름을 표준화해 “어디를 자동화할지”를 보이게 하는 지도라면, BABOK은 올바른 문제를 정의하고 합의를 만들어 “무엇이 가치인지”를 결정하게 하는 렌즈다. 그리고 AI-Native Product Architect는 그 둘을 이어, 의도와 규칙과 데이터를 실행 가능한 입력으로 구조화해 “바로 구현”까지 연결한다. 결국 기획은 관리나 문서화에 머무르지 않고, 가치(Why)–논리(How)–실행(Prototype)을 한 호흡으로 설계하는 쪽으로 이동한다.
기획은 변화한다. 더 넓은 지식의 숲으로 걸어 들어간다.
그리고 그곳에서, 기획자는 Product Architect가 된다.