슬랙 폭탄의 아침, 어떻게 대응할 것인가

슬랙 폭탄의 아침, 어떻게 대응할 것인가

8시 52분, 슬랙을 연다 출근하자마자 노트북을 켰다. 슬랙이 열렸다. 빨간 알림. 47개. 심호흡 한 번 하고 커피 한 모금 마셨다. 아직 9시도 안 됐는데.메시지들을 쭉 훑었다. "K님 이거 급합니다" "어제 요청드린 건 언제쯤?" "화면 정의서 확인 부탁드려요" "@기획자K 대표님이 이거 물어보시는데요" 전부 다 급하다고 한다. 근데 정말 급한 건 3개 정도다. 경험상 그렇다. 첫 5분이 하루를 결정한다 예전에는 위에서부터 순서대로 답했다. 그게 잘못이었다. 메시지 순서 = 중요도가 아니다. 보낸 사람의 급함 = 내 우선순위도 아니다. 지금은 다르게 한다. 1단계: 읽지 않고 분류부터멘션(@) 있는 것만 먼저 체크 DM은 제목만 훑음 채널 메시지는 나중2단계: 5초 룰 각 메시지당 5초만 쓴다. 판단만 한다."지금 답해야 함" → 🔴 "오늘 중" → 🟡 "이번 주" → 🟢 "답 안 해도 됨" → ⚪이모지로 표시해둔다. 내 마음속으로. 3단계: 🔴만 처리 진짜 급한 건 많아봐야 5개다. 나머지는 나중이다.급한 척하는 메시지 거르기 "급합니다"라고 쓴 메시지의 80%는 안 급하다. 진짜 급한 건 이렇게 온다:"운영 에러 발생" "대표님이 30분 뒤 미팅에서 물어보신대요" "유저 cs 폭주 중"나머지는 대부분 이거다:"제가 급해요" (= 당신 일정은 모름) "오늘까지 가능할까요?" (= 어제 줬으면 좋았을 걸) "확인 좀" (= 대충 봐주세요)구분하는 법. 누가 물어보나 대표님, 이해관계자, 개발 리드가 물으면 🔴. 주니어 개발자, 디자이너가 물으면 🟡. 마케팅 인턴이 물으면 🟢. 냉정하지만 사실이다. 언제까지인가 "지금 당장" → 🔴 "오늘 중" → 🟡 "이번 주" → 🟢 "괜찮을 때" → ⚪ 왜 급한가 썼나 이유 없으면 안 급하다. "릴리즈 전이라" → 🔴 "회의 자료 필요" → 🟡 "궁금해서요" → 🟢 답하는 순서 🔴 급한 것부터 처리한다. 근데 답하는 방식이 있다. 즉답형 (30초 이내) "네, 10시까지 드릴게요" "확인했습니다" "지라 티켓 확인 부탁드려요" 이런 건 바로 답한다. 고민할 필요 없다. 조사형 (5분 이상) "스펙 확인해보고 답드릴게요" "개발팀이랑 싱크 후 회신 드립니다" 이건 시간이 걸린다. 답장에 "언제까지"를 꼭 쓴다. 안 그러면 30분마다 물어본다. 거절형 "이번 스프린트에는 어려울 것 같아요" "우선순위상 다음 주 가능합니다" 이유를 쓴다. 안 그러면 싸운다.실전 사례 어제 아침. 슬랙 62개. 10분 만에 처리한 방법 9:00 - 슬랙 열고 스크롤만. 읽지 않음. 9:03 - 멘션 7개 확인. 🔴 2개, 🟡 3개, 🟢 2개. 9:05 - 🔴 2개 답장. 첫 번째: "운영 DB 에러요" → "확인했습니다. 개발팀 호출할게요" 두 번째: "대표님이 MAU 수치 물으심" → "5분 뒤 노션에 정리해드립니다" 9:10 - 🟡 3개 일정 잡기. "화면 정의서 리뷰" → "오후 2시 30분 어떠세요?" "백로그 우선순위" → "내일 스프린트 리뷰 때 논의합시다" "스펙 질문" → "컨플에 댓글 달아주시면 확인할게요" 9:15 - 🟢 2개 무시. "이 기능 왜 이렇게 됐어요?" → 나중에. 급하지 않다. 10시쯤 답했다. 충분했다. 안 읽는 메시지 몇 가지는 아예 안 읽는다. 1. 단톡방 잡담 "점심 뭐 먹지" "주말에 뭐 했어요" 보지 않는다. 시간 낭비다. 2. 이미 해결된 스레드 누가 답 달았으면 나는 패스. 굳이 끼어들 필요 없다. 3. 나랑 상관없는 기술 논의 "React 18 마이그레이션" "DB 인덱스 최적화" 개발자들이 알아서 한다. 내가 끼어들면 방해만 된다. 4. 'FYI' 메시지 "참고만 하세요" 읽지 않는다. 진짜 중요하면 멘션 달았을 거다. 시간대별 전략 슬랙은 하루 종일 온다. 시간대별로 대응이 다르다. 오전 (9-11시)🔴만 처리 🟡은 시간 잡기만 🟢은 무시아침에는 집중력이 좋다. 기획서 쓸 시간이다. 슬랙에 빠지면 하루가 날아간다. 점심 (12-1시)밀린 🟡 처리 간단한 답장만밥 먹으면서 폰으로 본다. 노트북 열면 일하게 된다. 오후 (2-5시)회의 많음 🟢도 처리 시작 내일 준비회의 사이사이 시간에 답한다. 저녁 (6-7시)급한 거 없으면 안 봄 있어도 내일로 미룸퇴근 시간이다. 슬랙 끄고 집에 간다. 도구와 팁 몇 가지 설정이 도움된다. 알림 커스터마이징멘션만 알림 ON 채널 알림은 OFF DM도 소리 OFF소리 나면 집중 못 한다. 상태 메시지 활용 "🔴 급한 업무 중 (11시까지)" "📝 기획서 작성 중" "🍔 점심 (1시 복귀)" 이거 해놓으면 급한 거 아니면 안 보낸다. 스레드 적극 사용 답장은 스레드로. 채널에 바로 답하면 누가 누구한테 한 말인지 헷갈린다. 슬랙 끄기 집중할 때는 슬랙을 끈다. 30분, 1시간씩. "방해금지 시간" 설정해둔다. 안 그러면 2분마다 메시지 온다. 경계 설정하기 슬랙은 끝이 없다. 경계를 정해야 한다. 즉답 노예 되지 않기 "K님 답장 빠르시네요" 칭찬 아니다. 함정이다. 빨리 답하면 앞으로도 빨리 답해야 한다. 기대치를 낮춰둔다. '급합니다' 남발 견제 "무엇이 급한가요?" "언제까지 필요하신가요?" 되물으면 생각하게 된다. 진짜 급한지. 야근 시간 슬랙 안 보기 8시 넘으면 끈다. 내일 볼 거다. "어? 못 봤네요" 이게 정답이다. 실수와 배움 초반에는 다 답했다. 47개 메시지. 47개 답장. 3시간 걸렸다. 기획서는 못 썼다. 회의 준비도 못 했다. 하루가 슬랙으로 끝났다. 지금은 안다. 슬랙은 내 일이 아니다 슬랙 답하는 게 일이 아니다. 서비스 기획하는 게 일이다. 유저 플로우 그리는 게 일이다. 데이터 분석하는 게 일이다. 슬랙은 도구다. 주인이 되면 안 된다. 모든 메시지에 답할 필요 없다 안 답해도 된다. 정말이다. 중요하면 다시 물어본다. 두 번 물어봐도 안 중요하면 그냥 그런 거다. 우선순위는 내가 정한다 "이거 급해요" 급한지는 내가 판단한다. 보낸 사람이 정하는 게 아니다. 한 달 후 이 방식으로 한 달 지났다. 바뀐 것들. 오전 2시간 확보 9시~11시는 내 시간이다. 슬랙 최소화. 기획서 작성. 생산성이 3배 올랐다. 스트레스 감소 "답 안 했다고 뭐라 하면 어쩌지" 걱정했는데 아무 일 없었다. 정말 급하면 전화 온다. 전화 안 오면 안 급한 거다. 관계 개선 답장 늦어도 이유를 말하니까 이해한다. "스펙 정리 중이라 오후에 드릴게요" 이렇게 말하면 기다린다. 무작정 답 안 하는 것과 다르다. 마무리 슬랙은 폭탄이다. 매일 터진다. 해체하는 법을 배워야 한다. 급한 선 하나 긋고. 중요한 선 하나 긋고. 그 안에 있는 것만 처리한다. 나머지는 내일.슬랙 끄고 일하는 시간. 그게 진짜 일하는 시간이다.

AS-IS TO-BE로 보면 이 기획이 말이 된다

AS-IS TO-BE로 보면 이 기획이 말이 된다

AS-IS TO-BE로 보면 이 기획이 말이 된다 또 왜냐고 묻더라 회의실. 개발팀장이 물었다. "이 기능 왜 만들어요?" 기획서 12페이지. 유저 플로우 3개. 예상 효과까지 썼다. 그래도 묻는다. 왜. 숨 한번 쉬고 화이트보드 들었다. "AS-IS TO-BE로 보면요." 왼쪽에 현재. 오른쪽에 목표. 3분 만에 이해했다. 질문 끝. 이게 6년차에 배운 거다.1년 전 나는 설명을 못했다 기획서를 길게 썼다. 배경, 목적, 기대효과, 상세기능, 예외케이스. A4 20장. 2주 걸렸다. 대표님이 물었다. "한 줄로 요약하면?" 버벅댔다. "그러니까... 유저가..." 답을 못했다. 내가 뭘 기획한 건지 모르겠더라.디자이너가 물었다. "지금 화면이랑 뭐가 달라져요?" 또 버벅였다. "일단... 버튼이 추가되고..." 그게 다였다. 버튼 추가. 왜 추가하는지 설명 못했다.개발자가 말했다. "스펙이 불명확해요." 화났다. 20장이나 썼는데. 지금 생각하면 맞는 말이었다. 나도 몰랐으니까. 뭘 만드는지.선배가 알려준 프레임워크 점심 먹다가 토로했다. "기획서 써도 이해를 못 해요." 선배가 웃었다. 8년차 PM. "AS-IS TO-BE 써봤어?" 처음 들었다.선배가 노션 켰다. 기획서 첫 장. 표 하나.구분 AS-IS TO-BE현재 ... ...목표 ... ..."이것만 명확하면 돼." 그게 다였다."현재 뭐가 문제야?" "목표는 뭐야?" "어떻게 바뀌는 거야?" 세 질문. 이걸 답하면 기획이 된다고 했다. 반신반의했다. 너무 간단해서. 첫 적용, 회원가입 개선 다음 프로젝트. 회원가입 개선. 일단 AS-IS 썼다. AS-IS (현재 상태)회원가입 7단계 완료율 42% 평균 소요시간 3분 20초 이탈 지점: 본인인증(38%), 약관동의(25%) 유저 피드백: "너무 복잡해요" (CS 월 230건)구체적으로 썼다. 숫자로.TO-BE 정의했다. TO-BE (목표 상태)회원가입 3단계 완료율 목표 65% 평균 소요시간 1분 30초 소셜 로그인 우선 노출 필수 정보만 1차 수집, 나머지는 사용 중 수집변화가 명확했다. 7단계 → 3단계.이걸 기획서 첫 장에 넣었다. 페이지 수 12장 → 6장. 설명 시간 30분 → 10분. 질문 거의 없었다. 개발팀장이 말했다. "이제 이해됐어요."왜 이게 작동하는가 3개월 써보니 알았다. 사람들은 "변화"를 이해하고 싶어 한다.기획서는 보통 목표만 쓴다. "회원가입을 개선한다." 현재가 없다. 비교 불가. 얼마나 개선되는지 모른다.AS-IS TO-BE는 변화를 보여준다. 변화 = TO-BE - AS-IS 이게 기획의 가치다. 현재 7단계 → 목표 3단계 = 4단계 개선. 숫자로 보인다. 명확하다.대표님이 좋아하는 이유. "투자 대비 효과"가 보인다. 개발 2주 → 완료율 23%p 상승. ROI 계산 가능.개발자가 좋아하는 이유. "왜 만드는지" 명확하다. 현재 문제 → 해결 방향. 동기부여 된다.디자이너가 좋아하는 이유. "비포 애프터"가 명확하다. 화면 개선 방향 잡힌다. 레퍼런스 찾기 쉽다. 실전 적용 3가지 케이스 케이스 1: 검색 기능 개선 AS-IS검색 결과 없음: 43% 재검색률: 67% 이탈률: 52% 검색어 자동완성 없음 오타 보정 없음TO-BE검색 결과 없음: 목표 15% 연관 검색어 제안 오타 자동 보정 인기 검색어 노출 검색 히스토리 저장변화: 검색 실패 → 검색 성공. 개발 공수: 3주. 예상 효과: 검색 성공률 28%p 상승. 승인까지 2일.케이스 2: 결제 플로우 단순화 AS-IS결제 5단계 결제 완료율 68% 평균 소요 시간 2분 40초 이탈 지점: 배송지 입력(45%) 모바일 결제 포기율 38%TO-BE결제 3단계 결제 완료율 목표 82% 배송지 자동 불러오기 간편결제 우선 노출 원클릭 결제 옵션변화: 클릭 수 감소. 완료율 증가. 개발 공수: 4주. 예상 매출 증가: 월 1,200만원. CFO가 바로 승인했다.케이스 3: 푸시 알림 재설계 AS-IS푸시 발송: 하루 평균 8건 오픈율: 12% 설정 해제율: 주 3.2% 타이밍: 오전 10시 일괄 발송 개인화 없음TO-BE푸시 발송: 유저당 하루 최대 3건 오픈율 목표: 25% AI 기반 발송 시간 최적화 유저 행동 기반 개인화 알림 카테고리 선택 가능변화: 스팸 → 유용한 정보. 개발 공수: 2주. 예상 효과: 재방문율 15% 증가. 마케팅팀이 환호했다. AS-IS 작성할 때 팁 현재를 객관적으로 써야 한다. 주관 빼고. 숫자로.나쁜 예시 "현재 회원가입이 복잡함" 얼마나 복잡한지 모른다.좋은 예시 "현재 회원가입 7단계, 완료율 42%, 평균 3분 20초 소요" 측정 가능하다. 비교 가능하다.AS-IS 작성 체크리스트: 숫자로 표현했는가 측정 가능한가 누가 봐도 동의하는가 문제가 명확한가 데이터 출처가 있는가데이터 없으면 추정한다. "CS 문의 주 평균 50건" "유저 인터뷰 10명 중 7명 불편 호소" "경쟁사 대비 2단계 더 많음" 완벽하지 않아도 된다. 없는 것보단 낫다. TO-BE 작성할 때 팁 목표는 현실적이어야 한다.나쁜 예시 "완료율 100%" 불가능하다. 신뢰 떨어진다.좋은 예시 "완료율 42% → 65% (목표)" 달성 가능하다. 근거 있다.TO-BE 작성 체크리스트: AS-IS보다 나은가 측정 가능한가 달성 가능한가 기간이 명확한가 비용 대비 효과적인가목표 설정 근거:경쟁사 벤치마크 "네이버는 3단계, 카카오는 2단계"과거 데이터 "작년 A 기능 개선 시 15% 상승"유저 리서치 "10명 중 8명이 3단계가 적당하다고 응답"숫자에 이유를 단다. 설명이 쉬워진다 이제 어떤 질문에도 답한다."왜 만들어요?" → "AS-IS가 이래서 TO-BE로 가려고요." "얼마나 좋아져요?" → "42%에서 65%로 예상돼요." "꼭 해야 해요?" → "현재 이탈률 58%인데 개선 안 하면 더 오를 거예요." "다른 방법은 없어요?" → "이 방법이 가장 빠르고 효과적이에요. AS-IS TO-BE 비교표 보시면..." 한 방에 끝난다.설득이 쉬워졌다. 표 하나면 된다. 말 많이 안 해도 된다.회의 시간 절반 줄었다. 전: 1시간 후: 30분 질문 80% 감소. 복잡한 기획도 단순해진다 3개월 전. 앱 전면 개편 기획. 120개 화면. 기능 50개. 막막했다.AS-IS TO-BE로 쪼갰다. 화면별로. 기능별로. 유저 플로우별로.메인 화면AS-IS: 최신순 나열, 평균 체류 28초 TO-BE: 개인화 추천, 목표 체류 60초마이페이지AS-IS: 5depth, 원하는 기능 찾기 어려움 TO-BE: 2depth, 자주 쓰는 기능 상단 고정알림 센터AS-IS: 시간순 나열, 확인률 23% TO-BE: 중요도 기반 정렬, 목표 확인률 45%50개 기능 → 50개 AS-IS TO-BE.대표님이 말했다. "이제 보이네요. 왜 개편하는지." 4개월 프로젝트 승인. 개발 시작. 이해관계자 설득에 최적 마케팅팀과 싸웠다. "푸시 더 보내야죠!" 나: "오픈율 12%인데요." 마케팅: "그래도 보내야 해요!"AS-IS TO-BE 보여줬다. AS-IS하루 8건 발송 오픈율 12% 푸시 해제율 주 3.2% 3개월 후 푸시 수신 유저 0명 예상TO-BE하루 3건 발송 (선별) 오픈율 목표 25% 푸시 유지율 상승 장기 채널 확보마케팅팀 조용해졌다. "...그럼 개인화 로직은?" 협의 시작.경영진 보고도 마찬가지. 숫자 좋아한다. 변화 좋아한다. AS-IS TO-BE면 충분하다. 실무에서 쓰는 템플릿 노션에 템플릿 만들었다. ## AS-IS TO-BE 분석### AS-IS (현재 상태) - 측정 지표 1: - 측정 지표 2: - 측정 지표 3: - 주요 문제점: - 데이터 출처:### TO-BE (목표 상태) - 목표 지표 1: - 목표 지표 2: - 목표 지표 3: - 개선 방향: - 달성 기간:### GAP 분석 - 변화량: - 필요 리소스: - 예상 효과: - 리스크:### 실행 계획 - 1단계: - 2단계: - 3단계:모든 기획에 쓴다.5분이면 작성 가능하다. 처음엔 10분 걸렸다. 지금은 자동이다.팀원들도 쓰게 했다. 처음엔 귀찮아했다. 2주 후 모두 쓴다. "설명하기 편해요." 6개월 후 변화 기획서 페이지 수: 20장 → 8장. 승인 기간: 2주 → 3일. 개발 착수 지연: 40% → 5%. 회의 시간: 평균 1시간 → 30분. "스펙 불명확" 지적: 주 5회 → 주 1회.숫자로 증명됐다. AS-IS TO-BE가 작동한다.대표님이 말했다. "기획이 명확해졌어요." 최고의 칭찬. 주의할 점 AS-IS TO-BE가 만능은 아니다.안 맞는 경우:신규 서비스 (AS-IS 없음) 탐색적 프로젝트 컨셉 기획 단계이럴 땐 다른 프레임워크.흔한 실수:AS-IS를 부정적으로만 씀 TO-BE가 너무 이상적 측정 불가능한 목표 숫자 없이 감으로객관성 잃으면 의미 없다.보완 방법:유저 리서치 함께 데이터 분석 병행 프로토타입 검증 A/B 테스트 계획AS-IS TO-BE는 시작이다. 지금도 쓴다 오늘도 기획서 썼다. 첫 장. AS-IS TO-BE. 10분 걸렸다.슬랙에 공유했다. 개발팀장: "명확하네요. 이번 주 스프린트에 넣을게요." 디자이너: "화면 컨셉 잡혔어요." 마케팅: "예상 효과 공유 부탁드려요." 질문 끝.퇴근길 지하철. 주니어한테 DM 왔다. "선배님, AS-IS TO-BE 어떻게 쓰는 거예요?" 템플릿 보냈다. "한번 써봐. 세상이 달라질 거야." 6년차가 1년차한테 배운 거. 또 전달한다.기획은 복잡하지 않다. 현재 → 목표. 이게 전부다. AS-IS TO-BE로 보면, 모든 기획이 말이 된다.내일 회의. 새 프로젝트. AS-IS TO-BE 준비했다. 또 설득한다.

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

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

회의록을 꼼꼼히 쓰는 이유 - 말이 바뀌기 때문이다 오전 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분 안에 올린다. 이게 루틴이다.

경쟁사 앱 분석, 퇴근 후의 나의 일상

경쟁사 앱 분석, 퇴근 후의 나의 일상

알림 울리면 조건반사 퇴근하고 집 와서 샤워하고 배달 음식 시켰다. 치킨. 지난주에도 치킨. 핸드폰 진동. 토스 업데이트. 또. 이번 주만 세 번째다. 일단 다운로드. "뭐가 바뀌었지?" 릴리즈 노트 읽는다. '사용자 경험 개선'이래. 구체적으로 뭔데. 앱 켜본다. 홈 화면. 레이아웃 바뀜. 주요 기능 위로 올렸네. 스크롤 깊이 줄였구나. 메뉴 구조 바뀜. 3뎁스를 2뎁스로. 똑똑하다. 신규 기능. '빠른 송금'. 최근 송금 내역에서 바로. 탭 수 2개 줄었네. 노트 앱 켠다. 스크린샷 5장 찍었다. 폴더에 저장. '토스_241204_홈개편'.치킨 먹으면서 본다. 노션 펼친다. '경쟁사 분석' 페이지. 토스, 카카오뱅크, 뱅크샐러드. 우리 앱도. 표 정리돼 있다. 업데이트 날짜, 변경 내용, 내 해석, 우리 적용 가능성. 토스 항목 추가한다. - 날짜: 2024.12.04 - 주요 변경: 홈 레이아웃 개편, 빠른 송금 추가 - 장점: 사용자 동선 단축, 주요 기능 접근성 상승 - 단점: 기존 사용자 혼란 가능성 (공지 없었음) - 우리 적용: 홈 개편 제안서에 벤치마크로 쓸 것이게 벌써 습관이다. 퇴근 후 루틴. 분석하는 나만의 프레임 노션에 템플릿 만들어뒀다. 6개월 전에. 처음엔 막 봤다. 그냥 '좋네', '별로네'. 그게 다였다. 3개월 차쯤 깨달았다. 체계 없으면 의미 없다는 걸.템플릿 구조는 이렇다. 1. 첫인상 (30초)뭐가 달라졌나 어디부터 눈에 들어오나 사용자가 제일 먼저 알아챌 변화2. UI 분석 (5분)레이아웃 변경점 컬러/폰트/아이콘 변화 정보 위계 구조 스크린샷 저장 (Before/After 비교)3. UX 분석 (10분)사용자 플로우 변화 (피그잼에 그림) 탭 수 계산 인터랙션 변경점 에러 처리 방식 온보딩 있는지4. 기능 분석 (10분)신규 기능 목록 개선된 기능 삭제된 기능 (있으면 주목) 핵심 기능과의 연결성5. 데이터 추론 (5분)왜 이렇게 바꿨을까 어떤 데이터를 봤을까 우리 데이터와 비교하면 효과 예상6. 적용 가능성 (5분)우리 서비스에 쓸 수 있나 바로 쓸 것 / 변형해서 쓸 것 / 참고만 제안서 작성 필요 여부 우선순위 (상/중/하)총 30분 이내. 더 길어지면 산으로 간다. 치킨 다 먹었다. 손 씻고 노트북 앞 앉는다. 오늘의 분석: 카카오뱅크 카카오뱅크 업데이트 어제 떴다. 아직 안 봤다. 다운로드. 로그인. 첫인상. 하단 탭바 바뀜. 5개에서 4개로. '혜택' 탭 없어짐. 재밌네. 혜택을 왜 뺐지. 사용률 낮았나. 아니면 홈에 통합했나. 홈 들어간다. 역시. 혜택 섹션 홈 중간에 있다. 스크롤 깊이 체크. 3.5스크롤. 전엔 혜택 탭 누르면 바로였는데. 사용자 입장. 혜택 보려면 홈 켜고 스크롤. 탭 하나 줄었지만 액션은 늘었다. 왜 이렇게 했을까.노션에 적는다. 가설 1: 혜택 탭 사용률 낮음 → 탭 공간 효율화 가설 2: 홈 체류 시간 늘리기 전략 (다른 기능 노출 위해) 가설 3: 주요 기능 집중 (송금/조회/카드)우리 앱은. 하단 탭 5개다. 홈, 거래내역, 혜택, 자산, 전체. 혜택 탭 사용률. 지난달 GA 데이터 봤었다. 8.3%. 낮다. 홈이 62%, 거래내역 21%, 자산 5.4%, 전체 3.3%. 혜택 빼면. 나머지 탭 더 눈에 띈다. 자산 탭 활성화 전략 쓸 수 있다. 메모 추가. 우리 적용 가능성: 상 - 다음 분기 홈 개편 때 혜택 통합 제안 - A/B 테스트 필요 (탭 4개 vs 5개) - 예상 효과: 홈 체류시간 15% 상승, 자산 탭 유입 20% 상승피그잼 켠다. 플로우 그린다. 기존: 홈 → 하단 혜택 탭 → 혜택 목록 (2탭) 변경: 홈 → 스크롤 → 혜택 섹션 (1탭 + 스크롤) 트레이드오프 명확하다. 접근성 vs 공간 효율. 우리 선택은 뭘까. 내일 팀 회의 때 물어볼 것. 다른 앱들도 체크 카카오뱅크만 보면 편향된다. 경쟁사 3개 이상은 봐야 트렌드가 보인다. 토스, 카카오뱅크, 뱅크샐러드. 오늘은 네이버 페이도. 네이버 페이 켠다. 2주 전 업데이트. 홈. 세로 스크롤에서 가로 캐러셀로 바뀜. 주요 기능 카드들. 스와이프로 빠르게 훑는다. 좋네. 우리 앱도 고민했었다. 세로 vs 가로. 결론은 세로였다. 정보량 많아서. 근데 네이버는 가로로 갔다. 왜. 앱 UX 컨셉이 다르다. 네이버는 '빠른 실행'. 우리는 '정보 제공'. 타겟도 다르다. 네이버는 20-30대 중심. 우리는 30-40대. 메모. 트렌드: 가로 캐러셀 증가 추세 - 토스: 하단 퀵메뉴 - 네이버: 홈 메인 - 카카오: 혜택 섹션이유 추정: - 모바일 네이티브 세대 증가 - 숏폼 콘텐츠 영향 (스와이프 익숙) - 정보 밀도 높이기우리 적용: 중 - 세로 레이아웃 유지하되 부분 적용 검토 - 이벤트/프로모션 영역에 캐러셀 테스트시계 본다. 밤 11시. 벌써. 분석 3개 끝. 30분씩 90분. 계획대로. 쌓이는 인사이트 노션 '경쟁사 분석' 페이지. 스크롤 내린다. 항목이 127개다. 6개월간. 처음엔 막막했다. '이거 언제 써먹지'. 근데 쓸 일 생긴다. 생각보다 자주. 지난달. 대표님이 물었다. "홈 개편하면 사용자 어떻게 반응할까요?" 자료 꺼냈다. 경쟁사 5개 홈 개편 사례. "토스는 체류시간 18% 올랐고, 카카오는 초기 이탈 12% 줄었습니다. 다만 뱅크샐러드는 첫 주 CS 문의 30% 증가했습니다." 대표님 표정 바뀌었다. "준비 많이 했네요." 아니다. 그냥 매일 보는 거다. 기획서 쓸 때도. 레퍼런스 찾는 시간 줄었다. 예전엔 구글링 1시간. 지금은 내 노션 10분. "이 기능 다른 데는 어떻게 구현했어요?" 폴더 열면 된다. 스크린샷 다 있다. 개발팀도 좋아한다. 말로 설명하는 것보다 화면 보여주는 게 빠르니까. "이런 느낌이에요. 토스처럼." "아 이거요? 가능하겠는데요." 대화 끝. 스펙 명확해진다. 데이터 없을 때도 쓴다. 우리 서비스는 신규라 데이터 적다. "이 기능 효과 있을까요?" "유사 사례 보면 전환율 5-8% 향상됐습니다." 근거 있는 추정. 아무것도 없는 것보단 낫다. 함정도 있다 주의할 것들. 6개월간 배웠다. 1. 맥락 없이 따라하기 경쟁사가 했다고 다 좋은 건 아니다. 그들의 사용자와 우리 사용자는 다르다. 서비스 단계도 다르다. 토스 따라했다가 망한 앱 많다. 토스는 토스니까 되는 거다. 우리 데이터, 우리 상황에 맞게 변형해야 한다. 2. 최신만 보기 새 업데이트만 쫓으면 트렌드 놓친다. 가끔 1-2년 전 버전도 본다. '왜 이렇게 바뀌었나' 흐름이 보인다. 서비스 진화 방향. 그게 더 중요하다. 3. 겉만 보기 화면만 보면 50%다. 실제로 써봐야 한다. 회원가입부터 주요 기능까지. 불편한 점, 좋은 점. 사용자 입장에서 느껴지는 게 진짜다. 4. 기록 안 하기 분석하고 머릿속에만 있으면 1주일 후 까먹는다. 기록해야 쓴다. 체계적으로 쌓아야 자산이 된다. 귀찮아도 한다. 미래의 나를 위해. 효율 올리는 팁 30분 안에 끝내려면 방법이 있다. 매일 하지 않는다 업데이트 알림 올 때만. 주 2-3회. 매일 하면 번아웃. 일도 아닌데. 템플릿 따른다 즉흥으로 보면 시간 잡아먹는다. 정해진 틀. 30분 타이머. 끝나면 끝. 스크린샷 깔끔하게 폴더 구조 정리.경쟁사별 폴더 날짜_기능명으로 파일명 관련 파일끼리 묶기나중에 찾기 쉽다. 핵심만 메모 장황하게 쓰지 않는다. 변경점 이유 추정 우리 적용세 줄이면 된다. 주간 리뷰 일요일 저녁. 이번 주 분석 훑어본다. 패턴 보인다. "아, 요즘 다들 이런 거 하네." 그게 트렌드다. 월요일 회의 때 꺼낸다. 팀과 공유하기 혼자 보면 아깝다. 2주마다 '경쟁사 트렌드' 세션 연다. 30분. 슬랙에 요약 올린다. 📱 경쟁사 업데이트 (12/1-12/15)주요 트렌드: 1. 홈 레이아웃 간소화 (토스, 카카오) 2. 가로 캐러셀 증가 (네이버, 뱅크샐러드) 3. AI 추천 기능 강화 (토스, 케이뱅크)우리 적용 제안: - 홈 개편 시 레퍼런스로 활용 - Q1 로드맵에 캐러셀 실험 추가 검토반응 온다. 디자이너: "캐러셀 레퍼런스 더 주실 수 있어요?" 개발자: "이거 구현 난이도 어느 정도죠?" 팀장: "다음 스프린트 때 논의해봅시다." 공유하면 가치 생긴다. 혼자 알면 내 지식. 팀이 알면 회사 자산. 지라 티켓도 만든다. '경쟁사 벤치마크 반영' 나중에 기획서 쓸 때 티켓 링크 건다. 히스토리 남는다.노트북 닫는다. 자정 넘었다. 내일 데일리 스크럼 9시 반. 7시간 후. 경쟁사 앱 분석. 퇴근 후 루틴. 피곤하지만 안 하면 불안하다. 뒤처지는 것 같아서.

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

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

오늘도 플로우를 그렸다 오후 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시. 퇴근 전. 내일 개발 착수 미팅 있다. 플로우 한 번 더 본다. 빠진 분기 없나. 예외처리 다 했나. 화살표 방향 맞나. 데이터 흐름 명확한가. 확인 끝. 지라에 첨부했다. "이제 개발해도 된다." 내일 또 플로우 그릴 거다. 다음 주에도. 다음 달에도. 플로우 그릴 때만 집중된다. 다른 업무는 산만해도. 플로우 앞에선 시간 가는 줄 모른다. 이유 알았다. 플로우는 내 논리를 증명하는 시간이다. 생각을 정리하는 시간이다. 불확실성을 제거하는 시간이다. 기획자로서 가장 순수한 시간. 논리와 구조만 남는 시간. 그래서 집중되는 거다. 그래서 좋아하는 거다.플로우 그릴 때가 가장 기획자답다. 이게 내 일이다.