AI야, 기획 아이디어 줄래?

IT 기획 실무: AI로 1시간 만에 고퀄리티 PRD(기획서) 작성하는 법 IT 기획 실무: AI로 1시간 만에 고퀄리티 PRD(기획서) 작성하는 법 실전 프로세스 서론: “빈 화면”을 깨는 가장 빠른 방법 기획자의 최대 적은 종종 경쟁사가 아니라 아무것도 없는 문서 첫 화면 입니다. PRD(Product Requirement Document)는 배경, 목표, 유저 스토리, 기능 요구사항, 정책, 예외 케이스까지 다 담아야 해서 제대로 쓰면 며칠이 훌쩍 지나가죠. 하지만 AI를 “대필”이 아니라 논리 파트너 로 쓰면 흐름이 바뀝니다. Perplexity로 근거를 모으고, Claude로 구조를 세우고, 예외 케이스로 디테일을 두껍게 만들면 1시간 내외 로 “공유 가능한 수준의 PRD”를 만들 수 있습니다. 오늘의 목표 ① 근거 있는 방향성 ② 읽기 쉬운 구조 ③ 개발 커뮤니케이션이 줄어드는 정책/예외 케이스를 1시간 안에 확보하기 (PRD가 아니라 PRD의 “뼈대 + 근거 + 리스크 지도”를 만드는 느낌으로 가면 속도가 납니다.) 📚 목차 1시간 PRD 타임박스 플랜 1단계: 시장 조사와 벤치마킹 자동화 (Perplexity) 2단계: 서비스 로직과 유저 스토리 설계 (Claude) 3단계: 예외 케이스 및 정책 고도화 AI 기획서 작성 시 주의할 점 (Golden Rules) 바로 복붙 가능한 PRD 템플릿 결론: 기획자는 ‘결정’하는 사람 FAQ ...

[기획자 가이드] 개발자와 말이 통하는 데이터베이스(DB) 기초: 테이블과 관계 [기획자 가이드] 개발자와 말이 통하는 데이터베이스(DB) 기초: 테이블과 관계 업데이트: 2026-02-18 · 키워드: DB, 테이블, PK/FK, 1:N 관계, 배송지 템플릿 서비스 기획을 하다 보면 이런 고민이 튀어나옵니다. “유저 한 명이 여러 개의 배송지를 가질 수 있게 하려면 기획서를 어떻게 써야 하지?” “쿠폰 정보는 회원 정보 안에 넣어야 할까, 따로 빼야 할까?” 정답은 화면(UI)에서만 나오지 않습니다. 대부분 데이터베이스(DB) 구조 쪽에 숨어 있어요. 기획자가 DB를 설계할 필요는 없습니다. 대신 테이블 과 관계 를 이해하면, 화면 설계(W/F)와 정책 정의가 동시에 단단해집니다. 말하자면, UI는 무대고 DB는 무대 뒤 소품 창고입니다. 창고가 엉키면 무대도 넘어집니다. 🎭 📚 목차 DB는 엑셀 파일과 비슷하다: 테이블(Table)의 이해 기획자가 알아야 할 3가지 관계(Relationship) 기획자가 DB 구조를 이해하면 얻는 이득 [템플릿] 배송지(1:N) 기능을 한 번에 정리하는 화면 명세 + 정책 실무 적용: 쿠폰/주문까지 관계로 기획서 쓰는 법 결론: 화면 뒤의 흐름을 보세요 FAQ 1) DB는 엑셀 파일과 비슷하다: 테이블(Table)의 이해 DB를 가장 쉽게 이해하는 방법은 “거대한 엑셀” 이라고 생각하는 것입니다. 엑셀의 시트 하나가 DB에서는 테이블(Table) 이 됩니다. (엑셀은 실수하면...

"기획서는 피그마에 있습니다" | 따로 문서 만들지 않는 피그마 스펙(Spec) 작성법 "기획서는 피그마에 있습니다" - 따로 문서 만들지 않는 '피그마 스펙' 작성법 피그마에서 화면을 수정하면 노션 기획서 스크린샷도 다시 찍고, 정책도 고치고, 링크도 갈아끼우고… 이건 기획이 아니라 복붙(CTRL+C/CTRL+V) 올림픽 입니다. 🥲 이제 화면과 기획서를 분리하지 마세요. 피그마를 단순한 디자인 툴이 아니라 살아있는 기획서(Spec) 로 만드는 방법을 정리했습니다. 목표는 하나, 팀원이 묻기 전에 파일이 답하게 만들기입니다. 📚 목차 왜 '피그마 네이티브' 기획서인가? 따로 문서 만들지 않는 3가지 레이아웃 전략 개발자가 읽기 편한 스펙 기술 가이드 (Data/Logic/Interaction/Edge) Dev Mode로 스펙을 '링크+주석+상태'로 완성하기 피그마 스펙이 지저분해지지 않게 만드는 정리 규칙 공유 전 5분 점검 체크리스트 FAQ 1) 왜 '피그마 네이티브' 기획서인가? 화면과 정책이 한곳에 모이면 협업 효율이 확 올라갑니다. 피그마 네이티브 기획서의 핵심 가치는 아래 3가지입니다. Single Source of Truth : "어디가 최신이에요?" 질문이 사라집니다. 맥락 유지 : 기능을 보면서 바로 옆에서 정책을 읽으면 오해가 줄어듭니다. 업데이트 부담 감소 : 화면이 바뀌면 기획서도 사실상 같이 바뀝니다. (스크린샷 재촬...

"말보다 화면으로 보여주세요" – 기획자의 피그마 프로토타이핑 생존기 "말보다 화면으로 보여주세요" – 기획자의 피그마 프로토타이핑 생존기 "이 버튼을 누르면 어디로 가나요?", "팝업이 뜨는 건가요, 페이지가 바뀌는 건가요?" 기획서 리뷰 시간에 질문 폭탄을 맞아 손이 마르는 경험이 있다면, 이제 프로토타이핑(Prototyping) 을 시작할 타이밍입니다. 여기서 중요한 포인트는 하나입니다. 기획자의 프로토타입 목표는 ‘화려함’이 아니라 논리적 근거를 클릭으로 증명 하고 UX 결함을 사전에 검증 하는 것입니다. 📚 목차 기획자가 프로토타이핑을 해야 하는 3가지 이유 기획자를 위한 핵심 기능 2개: Navigate to, Open overlay Navigate to로 유저 플로우를 “한 번에” 보여주는 법 Open overlay로 팝업/바텀시트를 “현실처럼” 만드는 법 프로토타입 공유 전 자가점검 체크리스트(Dead-end 제거) 20분 생존 루틴: 해피 패스만 빠르게 연결하는 순서 주석 템플릿: 개발자/디자이너 질문을 미리 막는 문장 FAQ 1) 기획자가 프로토타이핑을 해야 하는 3가지 이유 프로토타이핑은 “보기 좋아서”가 아니라 기획자의 생존과 직결됩니다. 커뮤니케이션 비용 절감 : 백 마디 설명보다 한 번의 클릭이 정확합니다. UX 논리 검증 : 정적인 화면에선 보이지 않는 막다른 길(Dead-end), 불필요한 단계가 튀어나옵니다. 의사결정권자 설득 : "왜 여기 있어요?"에 "직접 ...

커뮤니케이션의 완성: 데브 모드(Dev Mode)를 활용한 친절한 기획서 작성법 커뮤니케이션의 완성: 데브 모드(Dev Mode)를 활용한 친절한 기획서 작성법 기획자가 피그마에서 화면 설계를 마쳤다고 해서 기획이 끝난 건 아닙니다. 진짜 완성은 개발자가 내 의도를 100% 이해하고 구현에 착수 하는 순간에 옵니다. 이제는 PPT/노션에 캡처를 붙여 설명하지 않아도 됩니다. 피그마의 데브 모드(Dev Mode) 와 몇 가지 장치만으로도 충분히 ‘친절한 기획서’를 만들 수 있어요. 📚 목차 Dev Mode, 기획자가 왜 알아야 할까? 친절한 기획서의 뼈대: 3단 구조(상태-주석-링크) 섹션(Section)과 Ready for dev로 “여기부터 개발하세요” 표시하기 Annotation(주석)으로 ‘로직’을 레이어에 직접 고정하기 [추가] 화면 유형별 Annotation 템플릿(목록/상세/폼/결제) 컴포넌트 이름/라이브러리 유지가 Dev Mode에서 빛나는 이유 Dev resources로 Jira/Notion 링크를 “레이어에 붙이는” 방법 Variables로 다크모드·다국어까지 Dev Mode에서 확인 가능하게 기획서 퀄리티를 올리는 마지막 1%: 스펙 자동화 개발자가 바로 코딩하는 Dev Mode 체크리스트 FAQ 1) Dev Mode, 기획자가 왜 알아야 할까? Dev Mode는 개발자가 디자인을 코드로 옮기기 쉽게 돕는 환경입니다. 기획자가 이 환경을 이해하면 “전달”이 아니라 “구현 시작”을 만들어낼 수 있습니다. 정확한 데이터 전달 : 텍스트...