Showing Posts From

스프린트

디자이너와 개발자 사이의 기획자, 중재자가 되는 법

디자이너와 개발자 사이의 기획자, 중재자가 되는 법

오늘도 통역 중 오전 10시. 화면 정의 회의. 왼쪽엔 디자이너 수진님. 오른쪽엔 개발자 민수님. 나는 가운데. 수진님: "이 버튼은 사용자가 누를 때 약간 바운스되면서 피드백이..." 민수님: "그거 애니메이션 라이브러리 새로 써야 하는데요." 시작도 안 했는데 벌써 삐걱. 나: "일단 스펙부터 정리할게요." 피그마 켜고 화면 공유. 지라 티켓 열고. 노션에 정리 시작. 5년 차 되니까 안다. 이런 상황에서 누가 옳고 그른 게 아니라는 걸. 둘 다 각자의 영역에서 최선을 고민하는 거다. 문제는 언어가 다르다는 것.디자이너의 언어 수진님은 사용자 경험을 생각한다. "이 화면에서 저 화면으로 넘어갈 때, 자연스러운 트랜지션이 있어야 사용자가 맥락을 이해해요." 맞는 말이다. 인터랙션은 중요하다. 하지만 개발자 입장에선 '자연스러운 트랜지션'이 뭔지 모른다. 300ms? 500ms? fade? slide? 라이브러리는? CSS로 가능한지? 이럴 때 내가 하는 것.레퍼런스 찾기 "인스타그램 스토리 넘기는 느낌이요? 아니면 토스 화면 전환?"수치로 변환 "300ms 정도면 될까요? 민수님, 이 정도면 네이티브로 가능하죠?"우선순위 정리 "이번 스프린트엔 기본 전환만. 다음에 고도화."디자이너의 비전을 개발 가능한 스펙으로 바꾸는 작업. 통역이다. 정확히. 수진님: "아, 그렇게 말하면 되는구나." 나: "네. 다음엔 바로 이렇게 얘기해주세요." 회의록에 적는다.화면 전환: slide 애니메이션, 300ms, ease-in-out 레퍼런스: 토스 메인 화면 전환 우선순위: P1 (이번 스프린트)개발자의 언어 민수님은 기술 구현을 생각한다. "이 기능 API 새로 만들어야 하는데, 2주 걸려요." 디자이너는 당황한다. 화면 하나 추가인데 왜 2주? 이럴 때도 통역. 나: "수진님, 이 화면에 실시간 업데이트 필요하잖아요. 그러려면 웹소켓 연결이 필요해서 백엔드 작업이 커요." 수진님: "아... 그럼 일단 새로고침 버튼으로 시작하면 안 돼요?" 민수님: "그건 하루면 됩니다." 해결. 개발자가 '안 된다'고 할 때, 진짜 물리적으로 불가능한 게 아니다. 시간/리소스/기술 부채를 고려한 판단이다. 이걸 디자이너에게 설명하려면:기술 용어를 풀어서 "API는 서버랑 대화하는 거예요. 지금은 대화 통로가 없어서 새로 만들어야 해요."대안 제시 "실시간은 나중에. 일단 수동 새로고침으로 MVP 만들죠."트레이드오프 설명 "이거 지금 하면 다른 기능 2개는 밀려요."디자이너: "그럼 우선순위 조정해야겠네요." 나: "네. 대표님께 공유드릴게요." 지라 티켓에 적는다.[Backend] 실시간 업데이트 API 구축: 10 story points, Sprint+2 [Frontend] 수동 새로고침 버튼: 2 story points, 현재 Sprint 의존성: 백엔드 완료 후 프론트 고도화 가능중재의 기술 사실 이 일이 제일 어렵다. 둘 다 프로페셔널이다. 각자 영역에서 최선을 추구한다. 하지만 목표가 다르면 충돌한다. 디자이너: 최고의 사용자 경험 개발자: 안정적이고 유지보수 가능한 코드 둘 다 맞다. 그래서 더 어렵다. 지난주 실제 상황. 수진님: "이 페이지, 사용자별로 맞춤 레이아웃 보여주면 좋겠어요." 민수님: "그거 개인화 알고리즘 개발해야 해요. 3개월 프로젝트인데요." 둘 다 나를 본다. 나: "좋아요. 일단 목표부터 정리하죠." 화이트보드에 쓴다.문제: 사용자가 원하는 콘텐츠 찾기 어려움 목표: 콘텐츠 발견율 30% 증가 제약: 현재 스프린트 2주나: "개인화가 목표인가요, 콘텐츠 발견이 목표인가요?" 수진님: "콘텐츠 발견이요." 나: "그럼 대안이 있어요. 카테고리 필터 강화하면?" 민수님: "그건 이번 스프린트에 가능해요." 수진님: "음... 일단 그걸로 데이터 보고 개인화는 다음 분기에?" 나: "좋아요. 민수님 개발하시고, 수진님은 필터 UI 디자인. 2주 후 릴리즈하고 데이터 보죠." 중재의 핵심은 이거다.목표로 돌아가기 무엇을 해결하려는가? 방법은 여러 개다.제약 인정하기 시간, 인력, 기술. 현실을 본다.대안 제시하기 한 방법이 안 되면 다른 방법. 항상 플랜 B.단계 나누기 지금 할 것, 나중 할 것. MVP 사고.컨플루언스에 정리한다. 콘텐츠 발견율 개선 방안Phase 1: 카테고리 필터 강화 (2주) Phase 2: 데이터 수집 및 분석 (4주) Phase 3: 개인화 알고리즘 검토 (분기 단위)두 사람 다 고개 끄덕인다. 언어 배우기 5년 전엔 이게 안 됐다. 디자이너가 "인터랙션"이라고 하면 무슨 소린지 몰랐다. 개발자가 "API"라고 하면 긴장했다. 지금은 안다. 둘 다 배웠으니까. 디자인 배우는 법:피그마 직접 써본다. 기초 기능은 안다. UI/UX 기초 책 읽는다. "Don't Make Me Think" 같은 거. 디자인 시스템 공부한다. Atomic Design, 8pt grid. 레퍼런스 많이 본다. 좋은 앱 쓸 때 화면 캡처.개발 배우는 법:기술 용어 정리한다. API, DB, 서버, 클라이언트. 개발자 회의 듣는다. 모르면 나중에 물어본다. 간단한 코드 읽어본다. HTML, CSS 정도는. SQL 배운다. 데이터 직접 뽑을 수 있으면 협업 빨라진다.완벽하게 알 필요 없다. 디자이너처럼 디자인할 순 없다. 개발자처럼 코딩할 순 없다. 하지만 그들의 언어를 이해하면 된다. 통역하려면 양쪽 언어를 알아야 한다. 요즘은 수진님이 "이거 API 호출 몇 번이에요?"라고 물어본다. 민수님은 "사용자 플로우상 여기서 막히는데요?"라고 말한다. 서로 언어를 배우고 있다. 내가 계속 통역해줘서. 좋은 신호다. 회의록이 답이다 중재의 증거는 문서다. 말로만 하면 나중에 "그런 적 없는데요?"가 나온다. 그래서 나는 회의 때마다 적는다. 컨플루언스에 템플릿 만들어뒀다. 화면 정의 회의록일시: 2024.01.15 10:00 참석: 수진(디자인), 민수(개발), 나(기획) 안건: 홈 화면 개편결정 사항화면 전환 애니메이션: slide, 300ms 실시간 업데이트: Phase 2로 연기 카테고리 필터: 이번 스프린트액션 아이템 수진: 필터 UI 디자인 (01.17까지) 민수: 필터 API 개발 (01.22까지) 나: 대표님 보고 (01.16)이슈/리스크실시간 업데이트 딜레이로 사용자 피드백 우려 대안: 수동 새로고침 버튼 명확히 노출이렇게 적어두면:누가 뭘 하기로 했는지 명확 나중에 왜 이렇게 결정했는지 추적 가능 대표님한테 보고할 때 근거 자료말싸움 날 때 회의록 꺼내면 끝난다. "여기 보세요. 그때 이렇게 합의했어요." 문서는 기획자의 무기다. 감정 관리 사실 제일 어려운 건 이거다. 디자이너도 사람. 개발자도 사람. 나도 사람. 수진님이 열심히 만든 디자인, 민수님이 "이거 구현 힘든데요"라고 하면 기분 상한다. 민수님이 고민해서 짠 코드, 수진님이 "근데 이거 왜 이렇게 느려요?"라고 하면 짜증난다. 나는 그 사이에서 감정까지 조율한다. 수진님한테: "민수님이 안 된다는 게 아니라, 시간이 더 필요하다는 거예요. 기술적으로 복잡해서." 민수님한테: "수진님이 완벽주의라서 그래요. 사용자 경험 진짜 중요하게 생각하시거든요. 최대한 맞춰드리면 나중에 QA 때 편해요." 양쪽 다 이해시킨다. 그리고 내 감정도 관리한다. "왜 나만 힘들지?" 생각하면 끝이다. 중재는 원래 힘들다. 양쪽 다 만족시킬 순 없다. 목표는 최선의 타협. 완벽한 디자인도, 완벽한 코드도 아니다. 주어진 시간에 최선의 결과. 그걸 받아들이면 조금 편하다. 신뢰 쌓기 중재가 되려면 신뢰가 필요하다. 수진님과 민수님이 나를 믿어야 내 말을 듣는다. 신뢰는 어떻게 쌓나?약속 지키기 "내일까지 정리해드릴게요." 하면 정말 한다.양쪽 이해하기 디자이너 편도, 개발자 편도 아니다. 프로덕트 편.솔직하기 "이거 제가 잘 모르겠어요. 같이 알아봐요." 괜찮다.인정하기 "수진님 디자인 정말 좋았어요." "민수님 코드 리뷰 감사합니다." 진심으로.실수 인정하기 "제가 스펙을 명확히 안 적어서 혼선 있었어요. 죄송해요." 당당하게.시간 걸린다. 1년 정도? 지금은 수진님도 민수님도 내가 중간에서 정리하면 따라온다. 내가 "이게 최선"이라고 하면 믿는다. 그 신뢰가 있어서 중재가 가능하다. 실패 사례 잘될 때만 있는 건 아니다. 지난달에 망한 적 있다. 새 기능 기획. 디자이너는 복잡한 인터랙션 원했고, 개발자는 단순하게 하자고 했다. 나는 디자이너 편을 들었다. "사용자 경험이 중요하니까." 결과: 개발 일정 2주 초과. 버그 투성이. 결국 롤백. 민수님이 그랬다. "진짜님, 그때 제 말 들으셨어야죠." 맞다. 내가 기술적 제약을 무시했다. 교훈:한쪽 편 들면 안 된다. 기술 제약은 진짜 제약이다. 개발자가 "힘들다"고 하면 정말 힘든 거다.다음부터는 양쪽 의견 다 듣고 천천히 결정한다. 실패도 배움이다. 도구 활용 중재를 돕는 도구들. Figma: 디자이너랑 같은 화면 본다. Jira: 개발자랑 같은 일정 본다. Confluence: 모두가 같은 문서 본다. Slack: 비동기 소통. Zoom: 얼굴 보며 회의. 특히 Figma는 중요하다. "이 버튼이요"가 아니라 Figma 링크 공유하면 오해가 없다. "이 티켓이요"가 아니라 Jira 티켓 번호 말하면 명확하다. 도구는 언어를 통일시킨다. 그리고 Notion. 나만의 중재 가이드를 정리해뒀다. 디자이너-개발자 중재 체크리스트 목표 명확히 하기 제약 조건 확인하기 대안 3개 준비하기 우선순위 정하기 단계 나누기 회의록 작성하기 액션 아이템 할당하기회의 전에 이거 보면 덜 헤맨다. 지금도 배우는 중 5년 차지만 아직도 어렵다. 어제도 회의에서 막혔다. 수진님: "이 화면 구조 바꿔야 해요." 민수님: "지금 바꾸면 DB 마이그레이션이..." 나: "음... 일단... 데이터 보고...?" 명확한 답이 안 나왔다. 결국 CTO님께 여쭤봤다. 아직 모르는 게 많다. 하지만 계속 배운다. 디자인 강의 듣는다. 개발 세미나 간다. PM 커뮤니티에서 물어본다. "중재 잘하는 법" 같은 글 찾아 읽는다. 다른 기획자들은 어떻게 하는지. 그리고 매번 회고한다. "오늘 회의는 왜 잘 됐지?" "저번엔 왜 안 됐지?" 반복하면 조금씩 는다. 보람 힘들지만 보람도 있다. 지난주 릴리즈. 수진님 디자인에 민수님 개발. 내가 중간에서 조율했다. 출시 후 사용자 반응 좋았다. 리뷰 평점 4.7. 수진님: "우리 잘했네요!" 민수님: "다음엔 더 잘할 수 있을 것 같아요." 둘이 하이파이브. 나도 기분 좋다. 이게 중재의 보람이다. 혼자서는 못 만드는 걸 함께 만든다. 그 사이에 내가 있다. 다리 역할. 보이진 않지만 없으면 안 되는.오늘도 회의 3개. 내일도 통역 중이다. 피곤하지만 할 만하다.

Figma 화면 정의, 개발자가 이해할 수 있게

Figma 화면 정의, 개발자가 이해할 수 있게

Figma 화면 정의, 개발자가 이해할 수 있게 디자이너가 준 파일 어제 디자이너한테 화면 받았다. Figma 열었다. 예쁘다. 인터랙션도 화려하다. 프로토타입 클릭하니까 움직인다. 근데 개발자한테 공유했더니 슬랙이 왔다. "K님, 이 버튼 눌렀을 때 정확히 어떤 조건에서 어떻게 되는 거예요?" "로딩은 어느 타이밍에 보여주나요?" "에러 케이스는요?" 디자이너는 열심히 했다. 나도 확인했다. 근데 개발자 입장에선 부족하다. 항상 이렇다. 예쁜 화면과 개발 가능한 스펙은 다르다는 걸 또 배웠다.프로토타입의 함정 디자이너들은 프로토타입 툴을 잘 쓴다. Figma에서 클릭하면 화면이 넘어간다. 애니메이션도 들어간다. 멋있다. 근데 이게 함정이다. 프로토타입은 해피 케이스만 보여준다. 버튼 누르면 다음 화면. 스크롤하면 콘텐츠 나옴. 이게 전부다. 실제 개발은 다르다.로딩 중엔 뭘 보여줄까 API 실패하면 어떻게 할까 데이터가 없으면 어떤 화면 인터넷이 끊기면 동시에 두 번 클릭하면이런 거 프로토타입엔 없다. 디자이너도 모른다. 기획자가 정해야 한다. 작년에 있었던 일이다. 찜하기 버튼 기능. 디자이너는 하트 아이콘 누르면 빨갛게 채워지는 애니메이션 만들었다. 예뻤다. 개발자가 물었다. "연타하면요? API 응답 오기 전에 또 누르면요?" 그때 정의 안 했다. 나중에 QA에서 터졌다. 연타하니까 찜 목록이 꼬였다. 핫픽스 나갔다. 새벽에. 프로토타입 보고 다 됐다고 착각하면 안 된다.개발자가 원하는 건 따로 있다 개발자랑 협업 6년째다. 그들이 뭘 원하는지 알게 됐다. 예쁜 화면 아니다. 명확한 스펙이다. 명확한 스펙이란:이 데이터는 어디서 오나 (API 명세) 언제 호출하나 (타이밍) 실패하면 어떻게 하나 (에러 핸들링) 조건은 뭐냐 (if문에 들어갈 것들) 우선순위는 (뭘 먼저 만들까)디자인 파일에 이런 거 없다. 당연하다. 디자이너 일이 아니니까. 기획자가 해야 한다. 우리 팀 개발자 말이 있다. "디자인은 참고만 합니다. 스펙 보고 개발합니다." 처음 들었을 땐 서운했다. 디자이너랑 열심히 만들었는데. 근데 맞는 말이다. 개발자는 코드로 구현한다. 코드는 명확해야 한다. "대충 이런 느낌"은 코드가 안 된다. 그래서 나는 Figma 파일에 스펙을 박는다. 컴포넌트마다 코멘트로.내가 하는 방법 1. 컴포넌트별 코멘트 Figma에서 컴포넌트 선택하고 우클릭. 코멘트 단다. 예시: [로그인 버튼] - 상태: 활성/비활성 - 활성 조건: 이메일 형식 valid + 비밀번호 6자 이상 - 비활성 시: opacity 40%, 클릭 불가 - 클릭 시: 로딩 스피너 표시 (버튼 내부) - API: POST /auth/login - 성공: 홈 화면 이동 - 실패: 토스트 메시지 "로그인에 실패했습니다" (3초)처음엔 귀찮았다. 근데 이거 안 하면 슬랙 폭탄 맞는다. 미리 쓰는 게 낫다. 2. 플로우 차트 따로 프로토타입은 해피 케이스. 나는 FigJam으로 플로우 차트 그린다. 모든 분기 다 그린다.성공 케이스 실패 케이스 로딩 케이스 엣지 케이스개발자들이 이걸 더 좋아한다. 한눈에 보인다. 지난주 결제 기능 기획했다. 프로토타입은 단순했다. 버튼 누르면 완료 화면. 플로우 차트엔 14개 분기가 있었다.결제 수단 선택 전 잔액 부족 네트워크 에러 서버 에러 결제 취소 중복 결제 방지 ...이거 다 정의했다. 개발자가 고맙다고 했다. "이러면 개발 시작할 수 있어요." 3. 스펙 문서 별도 Figma는 디자인 툴이다. 스펙 문서는 아니다. 나는 Notion에 스펙 문서 따로 쓴다. 구조: # 화면명## 개요 - 목적 - 유저 플로우상 위치## 화면 구성 - 상단: 헤더 (뒤로가기, 타이틀) - 중단: 입력 폼 - 하단: 버튼## 상태 정의 ### State 1: 초기 - 데이터: 없음 - 버튼: 비활성### State 2: 입력 중 - 데이터: 부분 입력 - 버튼: 조건부 활성## API 정의 ### 요청 - Method: POST - Endpoint: /api/user/profile - Body: { name, email, phone }### 응답 - 200: 성공 - 400: 유효성 검사 실패 - 500: 서버 에러## 에러 처리 - 네트워크 에러: "인터넷 연결을 확인해주세요" - 서버 에러: "잠시 후 다시 시도해주세요" - 유효성 에러: 필드별 메시지 표시## 애널리틱스 - 화면 진입: screen_view_profile_edit - 버튼 클릭: click_save_profile - 성공: success_save_profile - 실패: fail_save_profile이거 쓰는 데 2시간 걸린다. 근데 안 쓰면 개발하면서 질문 100개 온다. 2시간이 싸다. 개발자와 리뷰 스펙 다 정의했다고 끝 아니다. 개발자랑 리뷰한다. 우리 팀은 '스펙 리뷰 미팅'을 한다. 30분. 개발 시작 전에. 내가 준비한 것:Figma 링크 플로우 차트 스펙 문서미팅에서 하는 것:화면 하나씩 설명 개발자 질문 받음 애매한 거 즉석 정리 예상 공수 확인이 미팅에서 항상 나온다. "이거 이렇게 하면 안 되나요?" "이 API는 없는데요." "이거 기술적으로 어려운데요." 좋다. 개발 시작 전에 알았다. 여기서 틀어지면 기획 수정한다. 개발 중에 틀어지는 것보다 100배 낫다. 지난달에 있었던 일. 실시간 알림 기능 기획했다. 웹소켓 써야 한다고 생각했다. 스펙 리뷰 미팅에서 백엔드 개발자가 말했다. "웹소켓 인프라 없어요. 구축하려면 2주 걸려요." 그 자리에서 폴링 방식으로 바꿨다. 30초마다 API 호출. 완벽하진 않지만 동작한다. 일정 맞췄다. 미팅 안 했으면 개발 중에 알았을 것이다. 일정 다 틀어졌을 것이다. 인터랙션 명세 디자이너가 만든 인터랙션 예쁘다. 근데 개발자는 숫자로 말해야 한다. "부드럽게 나타나요" → 개발자: "몇 초요?" "자연스럽게 사라져요" → 개발자: "어떤 easing이요?" 나는 인터랙션 명세를 쓴다. 예시: [모달 등장] - Duration: 0.3s - Easing: ease-out - Transform: translateY(100%) → translateY(0) - Opacity: 0 → 1 - Backdrop: opacity 0 → 0.6 (0.2s)[버튼 눌림] - Scale: 1 → 0.95 - Duration: 0.1s - Feedback: haptic (iOS만)[리스트 로딩] - Skeleton: 3개 표시 - Duration: 최소 0.5s (너무 빠른 깜빡임 방지) - 실패 시: 3초 후 재시도 버튼 표시디자이너한테 물어본다. "이 애니메이션 몇 초로 할까요?" 대부분 모른다. 함께 정한다. 0.3초, 0.5초 차이 크다. 개발자한테 준다. 질문 안 온다. 에러 케이스가 반이다 디자이너는 성공 케이스 그린다. 당연하다. 그게 메인이니까. 근데 실제 서비스에선 에러가 반이다. 내가 정의하는 에러:네트워크 에러 (연결 끊김) 서버 에러 (500, 502, 503) 인증 에러 (401, 403) 유효성 에러 (400) 타임아웃 (느린 네트워크) 데이터 없음 (empty state) 권한 없음 중복 요청 방지각각 어떻게 처리할지 정한다. 토스트? 모달? 인라인 메시지? 페이지 전환? 예시: [네트워크 에러] - 표시: 토스트 "인터넷 연결을 확인해주세요" - 위치: 하단 중앙 - 지속: 3초 - 액션: 재시도 버튼 (선택)[서버 에러] - 표시: 풀스크린 에러 페이지 - 메시지: "일시적인 오류가 발생했습니다" - 액션: "다시 시도" 버튼 → 이전 액션 재시도[데이터 없음] - 표시: Empty state 일러스트 - 메시지: "아직 내역이 없어요" - 액션: "추가하기" 버튼 → 생성 플로우로 이동이거 안 정하면 개발자가 알아서 한다. 그럼 일관성 없다. 어떤 에러는 토스트, 어떤 에러는 모달. 유저 혼란스럽다. 데이터 상태별 화면 API 호출하면 3가지 상태다.로딩 중 성공 실패각 상태마다 화면 다르다. 다 정의해야 한다. 예시: 피드 목록 화면 로딩 중Skeleton UI 3개 표시 상단 새로고침 인디케이터 스크롤 비활성성공 (데이터 있음)리스트 표시 Pull to refresh 활성 무한 스크롤성공 (데이터 없음)Empty state "아직 피드가 없어요" CTA 버튼실패에러 메시지 재시도 버튼 이전 캐시 데이터 표시 (선택)디자이너는 보통 "성공 (데이터 있음)" 화면만 그린다. 나머지는 내가 추가한다. Figma에 페이지 4개 만든다. 로딩/성공/Empty/에러. 개발자가 다 볼 수 있게. 우선순위 표시 기능 많으면 다 못 만든다. 시간 부족하다. 우선순위 정해야 한다. 나는 MoSCoW 방식 쓴다.Must: 필수. 이거 없으면 릴리즈 못함 Should: 중요. 있어야 하는데 밀리면 다음 스프린트 Could: 있으면 좋음. 여유되면 Won't: 안 함. 나중에 재논의Figma 코멘트에 표시한다. [M] 로그인 버튼 - 핵심 기능 [S] 자동 로그인 체크박스 - 유저 편의 [C] 생체 인증 로그인 - Nice to have [W] 소셜 로그인 - 다음 스프린트개발자들이 뭐부터 만들지 안다. 일정 타이트하면 M만 만든다. 릴리즈 한다. 나머지는 다음에. 이거 안 하면 개발자가 순서대로 만든다. Figma에 위에서부터. 그럼 Won't 먼저 만들고 Must 못 만드는 경우 생긴다. 우선순위는 기획자가 정해야 한다. 실제 데이터로 테스트 디자인 파일엔 예쁜 더미 데이터 들어있다.이름: "홍길동" 이메일: "hong@example.com" 한 줄 소개: "안녕하세요"실제는 다르다.이름: "Alexander Maximilian Constantine III" 이메일: "verylongemailaddress123456789@subdomain.domain.co.kr" 한 줄 소개: "안녕하세요반갑습니다저는서울에사는개발자입니다코딩을좋아하고커피를사랑합니다취미는등산이고..."텍스트 길면 레이아웃 깨진다. 항상. 나는 엣지 케이스 데이터 준비한다.최대 길이 텍스트 특수문자 (emoji 포함) 줄바꿈 여러 개 숫자 0, 음수, 아주 큰 수 빈 값Figma에 "엣지 케이스 테스트" 페이지 만든다. 이 데이터로 화면 그린다. 깨지는 거 미리 확인한다. 개발자랑 공유한다. "이 경우엔 말줄임(...)으로 처리해주세요" 같은 가이드 준다. 반응형 고려 모바일 앱 기획해도 디바이스 여러 개다.iPhone SE: 작음 iPhone Pro: 표준 iPhone Pro Max: 큼 iPad: 더 큼똑같은 화면이 다 다르게 보인다. 나는 최소 2가지 사이즈 정의한다.Small (iPhone SE 기준) Large (iPhone Pro Max 기준)Figma에서 프레임 2개 만든다. 같은 화면, 다른 사이즈. 버튼 크기, 텍스트 줄 수, 이미지 비율, 다 달라진다. 개발자한테 말한다. "이 컴포넌트는 flexible하게, 이건 fixed로." 안 그러면 개발자가 하나 사이즈로 만든다. Pro에선 예쁘다. SE에선 깨진다. QA에서 터진다. 개발 중 커뮤니케이션 스펙 다 정의했다. 개발 시작했다. 끝난 거 아니다. 개발 중에 계속 질문 온다. 당연하다. 스펙이 완벽할 순 없다. 나는 슬랙 채널 만든다. "#프로젝트명-개발" 규칙:질문은 여기서만 답변은 12시간 내 결정사항은 Notion 스펙 문서에 바로 반영개발자가 묻는다. "이 경우엔 어떻게 해요?" 나는 답한다. 바로. 애매하면 "30분 후에 답변드릴게요" 하고 정리한다. 절대 안 하는 것: "음... 좀 더 생각해볼게요" 하고 며칠 방치. 개발자는 기다린다. 내가 답 안 하면 일 못 한다. 블로킹 된다. 일정 밀린다. 빠른 의사결정이 좋은 기획이다. 완벽한 기획보다. 개발 완료 후 QA 준비 개발 끝났다. QA 넘긴다. 나는 QA 시나리오 미리 쓴다. 구조: # TC-001 로그인 성공 1. 로그인 화면 진입 2. 유효한 이메일 입력 3. 유효한 비밀번호 입력 4. 로그인 버튼 클릭 예상 결과: 홈 화면 이동# TC-002 로그인 실패 (잘못된 비밀번호) 1. 로그인 화면 진입 2. 유효한 이메일 입력 3. 잘못된 비밀번호 입력 4. 로그인 버튼 클릭 예상 결과: "비밀번호가 일치하지 않습니다" 토스트 표시# TC-003 네트워크 에러 1. 로그인 화면 진입 2. 비행기 모드 켜기 3. 로그인 버튼 클릭 예상 결과: "인터넷 연결을 확인해주세요" 토스트 표시이거 있으면 QA가 체계적으로 된다. 빠진 케이스 없다. QA에서 버그 나온다. 당연하다. 근데 "스펙과 다르다"와 "스펙이 없었다"는 다르다. 스펙 있으면: 개발자가 고친다. 명확하다. 스펙 없으면: "이거 기획 실수 아닌가요?" 논쟁 시작. 시간 낭비. 스펙을 명확히 하는 게 QA를 빠르게 한다. 회고 이번 스프린트 끝났다. 릴리즈 했다. 회고 미팅 한다. 나는 항상 묻는다. "스펙 정의가 명확했나요?" 개발자들이 답한다. 솔직하게. "이 부분은 애매했어요." "이건 나중에 알려주셔서 일정이 밀렸어요." "이 부분은 정말 명확해서 좋았어요." 피드백 받는다. 다음 스프린트에 반영한다. 6년 전엔 스펙을 대충 썼다. "디자인 보고 만들어주세요." 그랬다. 지금은 다르다. 개발자가 질문 없이 만들 수 있게 쓴다. 여전히 부족하다. 계속 배운다. 기획자는 디자이너도 아니고 개발자도 아니다. 둘을 연결하는 사람이다. 디자이너의 예쁜 화면을 개발자의 코드로 만들려면 번역이 필요하다. 그게 스펙 정의다. Figma 파일이 예쁜 게 중요한 게 아니다. 개발자가 이해할 수 있게 정리하는 게 중요하다.스펙 명확하면 개발 빠르다. 질문 줄어든다. 결과물 예측 가능하다. 그게 좋은 기획이다.

회의록을 꼼꼼히 쓰는 이유 - 말이 바뀌기 때문이다

회의록을 꼼꼼히 쓰는 이유 - 말이 바뀌기 때문이다

회의록을 꼼꼼히 쓰는 이유 - 말이 바뀌기 때문이다 오전 10시, 또 회의다 회의실에 들어갔다. 대표님, 개발팀장, 디자인 리드, 마케팅 매니저. 나까지 다섯 명. "이번 기능은 간단해요." 대표님이 말했다. 간단하다는 말을 들으면 긴장한다. 간단한 게 없다는 걸 6년 차가 가르쳐줬다.노트북을 켰다. Confluence 새 페이지. 제목은 "2025-01-XX 신규 기능 논의". 템플릿은 항상 같다.일시/참석자 안건 논의 내용 결정 사항 TODO타이핑을 시작했다. 대표님 말씀을 그대로 적는다. "유저가 클릭 한 번으로 바로 결제까지 가게. 네이버페이, 카카오페이 다 붙이고." 개발팀장이 말했다. "결제 모듈 연동은 2주 걸려요." "그럼 1주 만에 할 수 있는 걸로 먼저 하시고." 적었다. "개발 기간: 1주 목표 (결제 모듈 단순화)" 이게 나중에 중요하다. 3일 뒤, 말이 바뀌기 시작한다 슬랙 DM이 왔다. 대표님. "K씨, 결제 기능에 쿠폰 적용도 넣어야 할 것 같은데요?" 심장이 철렁했다. 회의록을 열었다. Ctrl+F로 "쿠폰" 검색. 없다. 답장을 보냈다. "회의 때는 쿠폰 얘기가 없었는데, 추가하시는 건가요? 개발 범위가 달라져서 일정 체크가 필요할 것 같습니다." 회의록 링크를 첨부했다. 5분 뒤 답장. "아 그랬나? 그럼 다음 스프린트에."회의록이 없었으면 어땠을까. "그때 말씀하셨잖아요" 싸움이 시작됐을 것이다. 증거가 있으니 조용히 넘어간다. 이게 회의록의 첫 번째 이유다. 말이 바뀐다. 사람은 자기 말을 기억 못 한다 이건 악의가 아니다. 정말로 기억을 못 한다. 지난달에도 있었다. 마케팅 매니저가 회의에서 말했다. "배너는 메인 상단에만 하나 넣으면 돼요. 심플하게." 회의록에 적었다. "메인 배너 1개, 상단 고정" 디자이너가 시안 만들었다. 개발자가 구현했다. QA 들어갔다. 그런데 마케팅 매니저가 지라 티켓에 댓글을 달았다. "배너가 하나밖에 없네요? 중간이랑 하단에도 필요한데요." 나는 회의록을 복사해서 댓글로 달았다. "회의록 확인 부탁드립니다. 당시 1개로 합의하셨습니다. 추가 필요 시 백로그에 등록하겠습니다." 30분 뒤 댓글. "아 맞다. 제가 착각했네요. 다음에 추가해요."사람들은 정말로 자기가 뭐라고 했는지 모른다. 특히 회의가 많으면 더 그렇다. 하루에 회의 세 개 하면 내용이 섞인다. 그래서 나는 회의 끝나고 30분 안에 회의록을 올린다. 기억이 선명할 때. 회의록은 방어 수단이다 기획자는 중간에 낀다. 위로는 대표님, 옆으로는 마케팅, 아래로는 개발/디자인. 모두가 다른 말을 한다. 그리고 나중에 "왜 이렇게 됐어요?"라고 묻는다. 이럴 때 회의록이 방패다. 작년에 있었던 일. 신규 기능 출시 후 버그가 터졌다. 심각한 건 아닌데, UX가 이상했다. 대표님이 물었다. "이거 왜 이렇게 기획했어요?" 나는 회의록을 열었다. 3개월 전 회의. "당시 개발 리소스 부족으로, 대표님께서 'MVP로 먼저 출시하고 개선하자'고 하셨습니다. 회의록 3번 항목입니다." 대표님이 회의록을 읽었다. "아, 맞네. 그럼 이번에 개선하죠." 끝. 회의록이 없었으면 나는 "기획을 왜 이렇게 했냐"는 말을 들었을 것이다. 회의록이 있으니 "당시 상황이 그랬구나"로 바뀐다. Confluence에 남기는 이유 회의록을 어디 남길까. 선택지는 많다. 노션, 구글 독스, 슬랙, 이메일. 나는 Confluence를 쓴다. 이유는 세 가지. 첫째, 검색이 쉽다. Confluence 검색창에 키워드만 치면 관련 회의록이 다 나온다. "결제 기능" 검색하면 결제 관련 회의 5개가 시간순으로 나온다. 둘째, 버전 관리가 된다. 누가 언제 뭘 수정했는지 다 남는다. "아 제가 회의록을 수정했는데요"라는 변명이 안 통한다. 셋째, 권한 설정이 명확하다. 팀 단위로 공유 설정. 전사 공개도 가능. 필요한 사람만 볼 수 있게. 슬랙은 흘러간다. 이메일은 묻힌다. 노션은 개인적이다. Confluence는 공식 기록이다. 회사에서 "공식적으로 논의된 내용"을 찾을 때, 사람들은 Confluence를 연다. 그래서 회의록도 거기 둔다. 템플릿이 중요하다 회의록을 매번 처음부터 쓰면 힘들다. 그래서 템플릿을 만들었다. # 회의 제목 일시: 2025-01-XX 10:00-11:00 참석자: @대표님 @개발팀장 @디자이너 @기획자K 작성자: 기획자K## 안건 - [ ] 신규 기능 범위 확정 - [ ] 일정 논의## 논의 내용 ### 1. 기능 범위 - 대표님: "클릭 한 번으로 결제까지" - 개발팀장: "결제 모듈 연동 2주 소요" - 결론: 1차는 단순 결제만. 쿠폰/포인트는 2차.### 2. 일정 - 목표: 2주 내 개발 완료 - QA: 3일 - 배포: 2025-02-15## 결정 사항 1. 결제 기능 MVP로 개발 (네이버페이, 카카오페이만) 2. 디자인 시안 이번주 금요일까지 3. 개발 착수 다음주 월요일## TODO - [ ] @디자이너: 결제 화면 시안 (금요일까지) - [ ] @개발팀장: 결제 모듈 기술 검토 (수요일까지) - [ ] @기획자K: 상세 스펙 문서 작성 (목요일까지)## 다음 회의 - 일시: 2025-01-XX 14:00 - 안건: 디자인 시안 리뷰이 템플릿을 쓰면 10분 만에 회의록이 완성된다. 회의 중에 논의 내용만 타이핑하면 된다. 중요한 건 "누가 뭐라고 했는지"를 명확히 적는 것이다. "결제 기능을 추가하기로 했다"가 아니라 "대표님이 결제 기능 추가를 요청했고, 개발팀장이 2주 소요 예상했고, MVP로 합의했다"고 쓴다. 나중에 누가 뭐라고 하면 이 문장을 가리킨다. 회의 중 타이핑은 실례가 아니다 예전에는 회의 중에 노트북 치는 게 실례인가 싶었다. 다들 얘기하는데 나만 타닥타닥. 그런데 지금은 당당하다. 회의 시작할 때 말한다. "회의록 작성하겠습니다." 아무도 뭐라고 안 한다. 오히려 좋아한다. 회의 끝나고 "회의록 언제 올라와요?"라고 묻는다. 회의록을 안 쓰면 더 이상하다. "그때 뭐라고 했더라?" 싸움이 시작된다. 개발자들은 특히 좋아한다. 회의 내용을 나중에 다시 안 물어봐도 되니까. 디자이너도 좋아한다. 요구사항이 명확하니까. 회의록은 나를 위한 것이기도 하지만, 팀 전체를 위한 것이다. 말이 바뀌는 순간들 경험상 말이 바뀌는 타이밍은 정해져 있다. 1. 개발이 50% 진행됐을 때 "아 그거 이렇게 하는 거 아니었는데요?" 2. QA에서 버그가 나왔을 때 "이건 버그가 아니라 스펙이 잘못된 거 아닌가요?" 3. 출시 직전 "근데 이거 빠뜨린 게 있는 것 같은데요?" 4. 출시 후 유저 반응이 안 좋을 때 "왜 이렇게 기획했어요?" 이럴 때마다 회의록을 연다. 그리고 조용히 링크를 공유한다. "당시 회의록입니다. 3번 항목 확인 부탁드립니다." 더 이상 논쟁이 없다. 팩트가 있으니까. 회의록을 안 쓰면 생기는 일 신입 때 회의록을 대충 썼다. 귀찮았다. 빨리 기획서 쓰고 싶었다. 그러다가 크게 데였다. 대표님이 요청한 기능을 개발했다. 2주 걸렸다. 배포했다. 그런데 대표님이 말했다. "이거 제가 요청한 거 아닌데요?" 증거가 없었다. 회의록이 없었다. 슬랙 대화도 지워져 있었다. 결국 내가 "제가 잘못 이해했습니다"라고 말할 수밖에 없었다. 2주 개발이 물거품이 됐다. 개발자는 화났다. 나도 억울했다. 그 이후로 회의록을 빠짐없이 쓴다. 30분짜리 회의도 쓴다. 5분짜리 스탠드업도 쓴다. 귀찮지만 안전하다. 회의록 작성 루틴 나는 회의가 끝나면 바로 회의록을 쓴다. 30분 안에. 1시간 회의면 회의록 작성에 15분. 30분 회의면 10분. 회의 중에 이미 70%는 타이핑했으니, 나머지 30%만 정리하면 된다.두괄식으로 수정 결정 사항 볼드 처리 TODO에 담당자 태그 다음 회의 일정 추가그리고 슬랙에 공유한다. "오늘 회의록입니다. 확인 부탁드립니다. 수정 사항 있으면 댓글로 남겨주세요." 24시간 안에 아무 말 없으면 확정. 이후 수정 요청은 받지 않는다. 이게 규칙이다. 디테일이 생명이다 회의록은 디테일이 중요하다. "결제 기능 추가하기로 함" - 이건 안 된다. "대표님 요청으로 결제 기능 추가. 네이버페이/카카오페이만 1차 적용. 개발 2주 예상. 디자인 시안 금요일까지. 개발팀장 기술 검토 후 최종 일정 확정 예정." - 이게 회의록이다. 누가, 무엇을, 언제까지, 왜, 어떻게. 5W1H. 특히 "왜"가 중요하다. 결정의 이유를 적어둔다. "쿠폰 기능은 2차로 미룸 (개발 리소스 부족, 우선순위 낮음)" 이 한 문장이 나중에 "왜 쿠폰 기능이 없어요?" 질문을 막아준다. 회의록은 CYA다 CYA. Cover Your Ass. 영어권에서 쓰는 표현이다. "네 엉덩이를 보호해라." 회의록은 정확히 이거다. 내 책임을 명확히 하고, 남의 책임도 명확히 한다. "K씨가 기획을 잘못한 거 아니에요?" - "당시 회의에서 이렇게 결정됐습니다." "개발이 왜 이렇게 오래 걸려요?" - "회의록에 2주로 합의됐습니다." "디자인이 왜 이래요?" - "시안 리뷰 때 승인하셨습니다." 회의록은 모두를 보호한다. 나만이 아니라. 회의록을 쓰지 않는 사람들 회사에는 회의록을 안 쓰는 사람들이 있다. "머리로 다 기억해요." - 기억은 변한다. "중요한 거만 메모해요." - 뭐가 중요한지 나중에 바뀐다. "바빠서 시간이 없어요." - 나중에 더 바빠진다. 이 사람들은 나중에 고생한다. "그때 제가 뭐라고 했죠?" 물어본다. 기억이 안 난다. 회의록은 미래의 나를 위한 투자다. 지금 30분 쓰면, 나중에 3시간을 아낀다. 회의록이 쌓이면 Confluence에 회의록이 수십 개 쌓였다. 검색하면 프로젝트 히스토리가 보인다. "이 기능 왜 이렇게 됐더라?" - 회의록 3개를 읽으면 안다. "작년에 비슷한 거 했던 것 같은데?" - 검색하면 나온다. 회의록은 팀의 기억이다. 조직의 기록이다. 신입이 오면 회의록부터 읽으라고 한다. 프로젝트 맥락을 이해하는 가장 빠른 방법이다. 결론 회의록을 꼼꼼히 쓰는 이유는 간단하다. 말이 바뀌기 때문이다. 사람은 악의 없이 기억을 왜곡한다. 나도 그렇고, 대표님도 그렇고, 개발자도 그렇다. 회의록은 객관적 기록이다. 팩트다. 증거다. Confluence에 회의록을 남기는 건 기획자의 기본이다. 귀찮지만 필수다. 회의록이 없으면 싸운다. 회의록이 있으면 조용하다. 나는 오늘도 회의록을 쓴다. 내일의 나를 위해서.회의 끝. 회의록 쓴다. 30분 안에 올린다. 이게 루틴이다.

유저 플로우를 그리며 나는 왜 집중하는가

유저 플로우를 그리며 나는 왜 집중하는가

오늘도 플로우를 그렸다 오후 2시. 회의실 화이트보드 앞에 섰다. "이 기능, 유저가 어떻게 들어오죠?" 개발자의 질문. 나는 스케치북을 펼쳤다. 다른 업무할 땐 슬랙 알림에 정신 팔린다. 기획서 쓰다가도 이메일 확인한다. 데일리 스크럼 중에도 딴생각한다. 근데 유저 플로우 그릴 땐 다르다. 시간 가는 줄 모른다. 3시간이 30분처럼. 이건 뭘까. 왜 이 작업만 몰입될까.집중되는 이유를 찾았다 며칠 전 깨달았다. 유저 플로우는 내가 컨트롤할 수 있는 영역이다. 기획서? 대표님이 "이거 아닌데"라고 뒤엎는다. 일정? 개발팀 공수 산정에 따라 달라진다. 디자인? 디자이너 의견이 더 중요할 때 있다. 근데 플로우는 내 논리다. "유저가 A를 하려면 B를 거쳐야 한다" 이건 내가 증명할 수 있다. 틀렸으면 내가 고친다. 명확하다. 정답이 있다. 불필요한 스텝은 제거된다. 최적 경로가 나온다. 이 쾌감. 정리되는 느낌. 다른 업무는 변수가 너무 많다. 플로우는 순수하게 논리만 남는다.플로우가 개발 공수를 줄인다 지난주 있었던 일. "회원가입 기능 개발 2주 걸립니다." 개발팀장이 말했다. 나는 플로우를 다시 그렸다.이메일 인증 필수인가? → 선택으로 변경 SNS 로그인 3개 다 필요한가? → 카카오만 프로필 입력 12개? → 필수 3개로 축소"이렇게 하면요?" 플로우 다시 보여줬다. 스텝이 8개에서 4개로. "이거면 1주일이요." 공수가 반으로 줄었다. 플로우를 제대로 그리면 군더더기가 보인다. "이 스텝, 꼭 필요한가?" 질문하게 된다. 불필요한 화면이 사라진다. 개발량이 줄어든다. 기획자의 자아도취가 아니다. 실제로 릴리즈가 빨라진다. 공수가 줄어든다. 개발팀도 좋아한다. "스펙 명확해요."나쁜 플로우의 징후 나쁜 플로우는 티가 난다.화살표가 꼬여 있다 분기가 5개 이상이다 "어쩌다" 도달하는 화면이 있다 뒤로가기를 누르면 혼란스럽다두 달 전 프로젝트. 장바구니 기능 기획했다. 플로우 대충 그렸다. "일단 개발 들어가요" 했다. 개발 중간에 질문 폭탄. "이 경우엔 어떻게 돼요?" "여기서 뒤로가기 누르면요?" "품절 상품은요?" 다시 플로우 그렸다. 분기가 12개였다. 복잡했다. 개발 일정 2주 늘어났다. 내가 플로우를 안 그려서 생긴 2주다. 그 뒤로 배웠다. 플로우 먼저. 개발은 나중. 정리 안 된 생각을 코드로 만들지 말자. 플로우 그리는 나만의 방식 화이트보드 앞에 선다. 일단 그린다. 디지털은 나중. 손으로 먼저. 포스트잇 활용한다. 화면 하나가 포스트잇 하나. 순서 바꾸기 쉽다. 붙였다 뗐다. 핵심 플로우(Happy Path) 먼저 그린다. 예외 케이스는 나중. 기본 동선이 명확해야 한다. 분기마다 "왜?"를 묻는다. "이 분기, 정말 필요한가?" "합칠 수 있지 않나?" 개발자 옆에 앉아서 그린다. "이거 가능해요?" 바로 물어본다. 불가능한 플로우 그리지 않는다. 완성되면 사진 찍는다. Figma로 옮긴다. FigJam에 정리해서 지라에 첨부한다. 개발자가 언제든 볼 수 있게. 플로우와 기획 품질 좋은 플로우는 좋은 기획서를 만든다. 플로우가 명확하면 기획서는 자동으로 써진다. 각 스텝이 화면 정의가 된다. 분기가 예외처리가 된다. 화살표가 인터랙션이 된다. 반대는 안 된다. 기획서부터 쓰면 플로우가 꼬인다. "이 화면 어떻게 들어와요?" 질문받는다. 플로우는 뼈대다. 기획서는 살. 뼈대 없이 살 붙이면 무너진다. 지난 분기 데이터 봤다. 플로우 먼저 그린 기능: 이슈 3개 플로우 없이 기획한 기능: 이슈 11개 숫자가 증명한다. 플로우가 기획 품질을 올린다. 디자이너와 플로우 보는 시간 목요일 오후 3시. 디자이너랑 정기 미팅. 화면 시안보다 플로우 먼저 본다. "이 플로우대로 화면 그리면 되죠?" "네, 근데 이 분기 좀 이상해요." 디자이너가 플로우 보고 피드백 준다. UX 관점에서 놓친 부분 잡아낸다. "유저가 여기서 헤매겠어요." "이 스텝, 합치는 게 나을 것 같아요." 다시 그린다. 플로우가 개선된다. 그제야 디자인 들어간다. 플로우 공유 없이 디자인부터 받으면? "이 화면 언제 나와요?" 질문하게 된다. "이전 화면이 뭐예요?" 헷갈린다. 시간 낭비다. 소통 비용이다. 플로우 하나면 해결된다. 플로우에서 발견하는 비즈니스 로직 플로우 그리다 보면 비즈니스 로직이 보인다. "여기서 결제 유도해야겠다" "이 타이밍에 알림 보내면 전환율 오를 것 같다" 서비스 기획자의 핵심은 플로우 설계다. 화면 예쁘게 만드는 게 아니다. 유저를 어떻게 우리가 원하는 방향으로 유도하느냐. 플로우는 전략이다. A 스텝에서 B 스텝으로. 이탈 최소화. CTA 버튼 위치. 정보 노출 순서. 전부 플로우에 담긴다. "여기서 뒤로가기 누르면 메인으로" → 이탈 방지 "이 화면 생략 가능" → 마찰 제거 "필수 정보는 마지막에" → 허들 낮추기 플로우에 서비스 철학이 녹는다. 플로우 검증하는 방법 혼자 그린 플로우는 위험하다. 내 머릿속에만 있는 논리다. 검증 방법 3가지.개발자한테 보여준다 "이 플로우대로 개발 가능해요?" 기술적 제약 확인한다. 불가능한 부분 수정한다.실제 유저처럼 따라간다 "내가 유저라면 이 플로우 이해할까?" 한 스텝씩 따라가본다. 헷갈리는 부분 찾는다.다른 기획자한테 리뷰받는다 "이 플로우 보고 기능 이해돼요?" 설명 없이 플로우만 보여준다. 이해 못 하면 수정한다.검증 없는 플로우는 독단이다. 틀렸는데 모르고 간다. 개발 들어가서 터진다. 플로우 그릴 때 쓰는 툴 화이트보드. 가장 자주. 펜 들고 쭉 긋는다. 자유롭다. 사진 찍어서 슬랙에 올린다. FigJam. 협업용. 개발자, 디자이너랑 같이 본다. 댓글 달린다. 수정 이력 남는다. Figma. 최종 정리용. 깔끔하게 그린다. 지라에 첨부한다. 화면 시안이랑 연결한다. 노션. 복잡한 플로우. 텍스트로 설명 추가한다. 분기별 로직 정리. DB 테이블이랑 매핑도 여기서. 툴은 중요하지 않다. 플로우가 명확하면 종이에 그려도 된다. 툴에 집착하면 본질을 놓친다. 개발팀이 좋아하는 플로우 지난주 개발팀장이 말했다. "K님 플로우는 개발하기 편해요." 이유 물었다. "예외처리가 다 들어가 있어요. 질문할 게 없어요." 개발자가 좋아하는 플로우:모든 분기에 설명이 있다 예외 케이스가 명시돼 있다 에러 상황 처리가 그려져 있다 데이터 흐름이 보인다개발자가 싫어하는 플로우:Happy Path만 있다 "나머지는 알아서" 분기 조건이 모호하다 "이건 당연한 거 아니에요?"당연한 건 없다. 모든 경우의 수를 그려야 한다. 귀찮아도 그린다. 나중에 질문받는 게 더 귀찮다. 플로우 그리기가 주는 안정감 플로우를 다 그리고 나면 안심된다. "이제 개발 들어가도 되겠다." 머릿속 생각이 밖으로 나왔다. 눈에 보인다. 검증됐다. 빠진 게 없다. 개발 중에 질문 오면? "플로우 보시면 나와 있어요." 지라 링크 던진다. 끝. 플로우 없이 개발 시작하면? 불안하다. 질문 올까봐 두렵다. "이거 생각 못 했는데..." 식은땀 난다. 플로우는 기획자의 방어막이다. "제가 이미 생각했습니다" 증거다. 실무에서 기획자는 논리로 싸운다. "왜 이렇게 기획했어요?" "플로우 보시면 이 분기 때문에 불가피합니다." 플로우가 무기가 된다. 플로우로 설득하는 순간 한 달 전. 대표님이 요구했다. "이 기능, 화면 하나에 다 넣어요." 나는 플로우 그려서 보여줬다. "한 화면에 넣으면 이렇게 됩니다." 분기가 8개. 화살표가 꼬였다. "유저가 헷갈립니다. 이탈할 겁니다." "대신 3개 화면으로 나누면?" 새 플로우 보여줬다. 깔끔했다. 각 화면의 목적이 명확했다. "이게 낫네요." 대표님이 수긍했다. 말로 설득 안 됐다. 플로우가 설득했다. 시각화된 논리는 강하다. 이해관계자 설득할 때. 플로우 하나면 10분 회의가 2분으로 줄어든다. 플로우 그리기로 성장한다 1년 전 내 플로우. Happy Path만. 예외처리 없음. "대충 이런 느낌이에요" 수준. 지금 내 플로우. 모든 분기 명시. 에러 처리. 데이터 흐름. 개발자가 질문 안 한다. 어떻게 달라졌나. 플로우 그린 개수: 약 150개. 피드백받은 횟수: 수십 번. 틀려서 다시 그린 횟수: 그것보다 많음. 플로우 많이 그릴수록 실력 는다. "이 패턴, 전에도 봤는데" 경험 쌓인다. 비슷한 플로우는 빠르게 그려진다. 기획자의 실력은 플로우에서 나온다. 화려한 기획서가 아니다. 명확한 플로우다. 신입 기획자한테 조언한다면. "기획서 잘 쓰려고 하지 마세요. 플로우 많이 그리세요." 플로우가 곧 나의 사고방식 요즘 일상에서도 플로우로 생각한다. 카페 주문. "메뉴 선택 → 옵션 선택 → 결제 → 수령" "이 카페는 플로우가 복잡하네. 주문이 어렵다." 은행 앱 쓸 때. "로그인 → 메뉴 → 송금 → 확인" "여기 플로우 좋은데? 스텝이 적네." 일상이 플로우로 보인다. 직업병인가. 아니다. 사고방식이 바뀐 거다. 세상 모든 서비스가 플로우다. 좋은 서비스는 플로우가 명확하다. 나쁜 서비스는 플로우가 꼬여 있다. 이런 시각으로 세상 보니까. 기획이 더 재밌어졌다. "저 서비스 플로우 어떻게 짰을까" 궁금해진다. 오늘도 플로우를 그린다 오후 6시. 퇴근 전. 내일 개발 착수 미팅 있다. 플로우 한 번 더 본다. 빠진 분기 없나. 예외처리 다 했나. 화살표 방향 맞나. 데이터 흐름 명확한가. 확인 끝. 지라에 첨부했다. "이제 개발해도 된다." 내일 또 플로우 그릴 거다. 다음 주에도. 다음 달에도. 플로우 그릴 때만 집중된다. 다른 업무는 산만해도. 플로우 앞에선 시간 가는 줄 모른다. 이유 알았다. 플로우는 내 논리를 증명하는 시간이다. 생각을 정리하는 시간이다. 불확실성을 제거하는 시간이다. 기획자로서 가장 순수한 시간. 논리와 구조만 남는 시간. 그래서 집중되는 거다. 그래서 좋아하는 거다.플로우 그릴 때가 가장 기획자답다. 이게 내 일이다.

MVP 한 마디로 프로젝트가 살아난다

MVP 한 마디로 프로젝트가 살아난다

MVP 한 마디로 프로젝트가 살아난다 대표님의 10개 피처 월요일 오전 10시. 기획 검토 미팅. 대표님이 말했다. "이번 릴리즈에 이거 다 넣으면 좋겠는데." 화면을 보니 피처가 10개다.소셜 로그인 3종 추가 알림 설정 상세화 프로필 편집 고도화 추천 알고리즘 개선 채팅 기능 결제 수단 추가 다크모드 언어 설정 튜토리얼 리뉴얼 통계 대시보드개발 기간은 6주. 나는 계산했다. 이거 다 하려면 최소 4개월이다.첫 반응 "네, 검토해보겠습니다." 회의실 나왔다. 개발팀장한테 슬랙 보냈다. "10개 피처, 6주. 가능?" 답장은 5초 만에 왔다. "ㅋㅋㅋㅋㅋ 농담이죠?" 디자이너한테도 물었다. "UI 작업만 2개월이요." 예상했다. 이제 대표님을 설득해야 한다. 어떻게? "안 됩니다" 는 답이 아니다. 대안을 줘야 한다. 그게 MVP다. MVP가 뭔데 Minimum Viable Product. 최소 기능 제품. 핵심만 남긴 버전이다. 10개 피처 중에서 진짜 필요한 거. 유저가 당장 써야 하는 거. 나머지는 다음 스프린트. 이게 스코프 관리의 핵심이다. 나는 회의록을 다시 봤다. 10개 피처의 목적을 정리했다.소셜 로그인: 가입률 올리기 (중요도 상) 알림 설정: 이탈 방지 (중) 프로필 편집: 사용성 개선 (중) 추천 알고리즘: 체류시간 증가 (상) 채팅: 커뮤니티 활성화 (하, 아직 유저 적음) 결제 수단: 매출 (상) 다크모드: 요청 많음 (하, 급하진 않음) 언어 설정: 해외 진출 (하, 올해 계획 없음) 튜토리얼: 신규 유저 온보딩 (중) 통계 대시보드: 내부 운영용 (하)가입률, 매출, 추천. 이 3개가 핵심이다. 나머지는 좋으면 좋은 거다. 없어도 서비스는 돌아간다.대표님 설득법 다음날 미팅을 다시 잡았다. 준비물:우선순위 매트릭스 개발 공수 추정 릴리즈 로드맵 (3개 버전)"대표님, 검토했습니다." 화이트보드에 표를 그렸다. 중요도 vs 긴급도[높음/높음] [높음/낮음] 소셜로그인 알림설정 결제수단 프로필편집 추천알고리즘 튜토리얼[낮음/높음] [낮음/낮음] (없음) 채팅 다크모드 언어설정 통계대시보드"10개 다 하면 4개월입니다. 6주 안에 하려면 3개만 가능합니다." 대표님 표정이 굳었다. "그럼 나머지는 언제?" "일단 MVP로 가시죠. 소셜로그인, 결제수단, 추천 알고리즘. 이 3개만 6주 안에 릴리즈합니다." "나머지 7개는?" "버전을 나눕니다. v1.1에 중요도 중간인 것들, v1.2에 나머지." 화이트보드에 타임라인을 그렸다.v1.0 (6주): 소셜로그인 + 결제 + 추천 v1.1 (8주 후): 알림 + 프로필 + 튜토리얼 v1.2 (12주 후): 채팅 + 다크모드 + 언어 + 통계"이렇게 하면 6주 안에 핵심 기능은 나갑니다. 매출도 올리고, 가입률도 높이고." 대표님이 잠시 생각했다. "채팅은 왜 나중에?" "지금 DAU가 500명입니다. 채팅 쓸 사람이 없어요. v1.1로 유저 늘리고 나서 넣는 게 맞습니다." "다크모드는?" "요청이 30건이에요. 전체 유저 5000명 중 0.6%. 우선순위가 낮습니다." 숫자로 말하니까 설득이 됐다. "알겠어. MVP로 가자." MVP의 힘 이 한 마디가 프로젝트를 살렸다. 10개 피처를 6주에 하면 어떻게 됐을까?개발팀 번아웃 QA 시간 부족 버그 투성이 릴리즈 유저 불만 폭증 결국 핫픽스 지옥실제로 전 회사에서 겪었다. 대표님이 "다 넣어" 해서 다 넣었다. 릴리즈 당일 서버가 터졌다. 앱스토어 리뷰 평점이 4.2에서 2.8로 떨어졌다. 복구하는 데 3개월 걸렸다. 그때 배웠다. 스코프 관리는 협상이 아니다. 생존이다.MVP 정하는 법목적을 먼저 정한다피처가 아니라 목표다. "채팅 기능을 넣는다" (X) "유저 체류시간을 20% 늘린다" (O) 목표가 명확하면 피처는 자동으로 정해진다. 채팅이 정말 체류시간을 늘릴까? 데이터는? 가설은? 이렇게 물으면 우선순위가 보인다.임팩트 vs 공수가로축: 비즈니스 임팩트 세로축: 개발 공수 [높은 임팩트 / 낮은 공수] → 당장 해라 [높은 임팩트 / 높은 공수] → MVP로 쪼개라 [낮은 임팩트 / 낮은 공수] → 시간 나면 해라 [낮은 임팩트 / 높은 공수] → 하지 마라 소셜 로그인: 높은 임팩트 / 중간 공수 → MVP 포함 다크모드: 낮은 임팩트 / 중간 공수 → 제외 이게 합리적 판단이다.유저 관점에서 생각한다내가 유저라면 뭐가 제일 필요할까? 이번 프로젝트의 타겟 유저는 "처음 가입하는 사람"이었다. 그럼 소셜 로그인은 필수다. 회원가입 장벽을 낮춰야 한다. 채팅? 친구도 없는데 누구랑 채팅해? 다크모드? 일단 가입부터 하고 나서 생각할 문제다. 유저 여정을 그려보면 답이 나온다.데이터로 검증한다감이 아니라 숫자다. "다크모드 요청이 많아요" → 몇 건? "채팅이 필요해요" → 사용률 예측은? "추천 알고리즘이 중요해요" → 현재 클릭률은? 구글 애널리틱스, 믹스패널, 앰플리튜드. 데이터를 보면 우선순위는 명확해진다. 실제로 알림 설정은 데이터 보고 v1.1로 밀었다. 현재 알림 수신율이 72%였다. 충분히 높았다. "알림 상세 설정"은 급한 게 아니었다. 개발팀 반응 개발팀장이 말했다. "10개에서 3개로 줄여줘서 고맙습니다." 진심이었다. 개발자는 완성도를 원한다. 대충 10개보다 제대로 3개가 낫다. 프론트엔드 개발자도 좋아했다. "소셜 로그인 3종만 하면 되니까 OAuth 제대로 구현할게요." 백엔드 개발자는 이렇게 말했다. "추천 알고리즘에 집중할 수 있어서 좋네요. A/B 테스트도 붙일게요." QA 담당자도 만족했다. "3개면 테스트 케이스 제대로 짤 수 있어요." 모두가 행복한 스코프. 이게 MVP의 힘이다. 디자이너 입장 디자이너도 스코프가 줄어서 좋아했다. "10개 화면 러프하게 그리는 것보다, 3개 화면 디테일 잡는 게 낫죠." 실제로 소셜 로그인 화면은 A안, B안, C안까지 뽑았다. 유저 테스트도 했다. 결제 화면은 UX 라이팅까지 신경 썼다. "결제하기" 대신 "3,000원 결제하기". 전환율이 8% 올랐다. 10개 피처를 급하게 했으면 이런 디테일은 불가능했다. MVP는 퀄리티를 보장한다. 릴리즈 결과 6주 후. v1.0이 나갔다. 3개 피처만 들어갔지만 반응은 좋았다.소셜 로그인: 가입률 32% 상승 결제 수단: 첫 주 매출 47% 증가 추천 알고리즘: 평균 체류시간 6분 → 9분앱스토어 리뷰에 이런 댓글이 달렸다. "업데이트 후 진짜 편해졌어요. 카카오로 바로 가입했습니다." "결제가 이제 되네요. 기다렸어요." "추천이 정확해요. 계속 보게 되네요." 3개만 했는데 만족도는 높았다. 왜? 제대로 했으니까. 대표님도 만족했다. "다음은 v1.1 준비하자. 잘했어." MVP로 일하는 법 이제 나는 모든 프로젝트에 MVP를 적용한다.피처 리스트를 받으면 일단 질문한다"이 기능의 목적이 뭐죠?" "유저가 정말 원하나요?" "데이터 있나요?" "안 하면 어떻게 되죠?" 질문하면 절반은 우선순위에서 빠진다.Must Have / Should Have / Nice to Have피처를 3단계로 나눈다. Must: 없으면 서비스가 안 됨 Should: 있으면 좋음 Nice: 나중에 해도 됨 Must만 MVP에 넣는다.로드맵을 그린다v1.0, v1.1, v1.2. 이렇게 버전을 나누면 대표님도 이해한다. "일단 v1.0 나가고, 다음 거는 8주 후에요." 시간 축이 명확하면 협상이 쉽다.개발팀과 미리 소통한다기획서 쓰기 전에 개발팀장한테 물어본다. "이거 공수 얼마나 나올 것 같아요?" 대략적인 추정치를 받는다. 그걸 기반으로 스코프를 조정한다. 나중에 "이거 안 돼요" 듣는 것보다 훨씬 낫다.데이터를 모은다구글 애널리틱스, 유저 인터뷰, CS 문의 내역. "요청이 많아요" 말고 "246건 요청 들어왔어요" 라고 말한다. 숫자가 있으면 설득력이 생긴다. 실패 사례 물론 실패도 있었다. 작년에 채팅 기능을 MVP에 넣었다. 대표님이 강하게 원했다. "경쟁사는 다 있어." 나는 밀어붙였다. MVP에 포함시켰다. 결과? 개발 기간 8주 → 12주로 늘어남. 릴리즈 후 채팅 사용률 3%. 유저들은 채팅을 안 썼다. 왜? 우리 서비스는 커뮤니티가 아니었다. 정보 검색 앱이었다. 채팅이 필요 없었던 거다. 나는 데이터를 무시하고 대표님 의견을 따랐다. 실수였다. 그 이후로 나는 더 단호해졌다. "근거가 없으면 MVP에 안 넣습니다." MVP는 타협이 아니다 처음엔 생각했다. MVP는 어쩔 수 없이 줄이는 거라고. 아니다. MVP는 전략이다. 핵심에 집중하는 전략. 10개를 대충 하는 것보다, 3개를 제대로 하는 게 낫다. 유저도 그걸 안다. "이것저것 다 있는데 다 별로" 보다 "기능은 적은데 하나하나 완벽해" 가 낫다. 애플이 그렇게 일한다. 아이폰 첫 버전에는 복붙도 없었다. MMS도 안 됐다. 하지만 터치 인터페이스는 완벽했다. 그래서 성공했다. 지금도 오늘도 대표님이 말했다. "이번 분기에 이거 5개 넣을 수 있지?" 나는 웃으며 말했다. "일단 MVP로 가시죠. 2개만 제대로 합시다." 대표님도 이제 안다. 내가 왜 이러는지. "알았어. 네 말대로 하자."MVP 한 마디로 프로젝트가 산다. 스코프 관리는 협상이 아니라 생존이다.