Showing Posts From

Prd

팀원 300명 회사의 조직 문화 - 스타트업 vs 중견기업

팀원 300명 회사의 조직 문화 - 스타트업 vs 중견기업

팀원 300명 회사의 조직 문화 - 스타트업 vs 중견기업 300명이라는 애매한 숫자 우리 회사 직원이 300명이다. 스타트업이라고 하기엔 크고, 중견기업이라고 하기엔 작다. 시리즈 B 받고 3년째다. 채용 공고에는 "스타트업의 역동성과 안정성을 모두"라고 쓴다. 입사하고 보니 둘 다 반쪽이다. 스타트업처럼 빠르지도, 대기업처럼 체계적이지도 않다. 예전 회사는 50명이었다. 대표님이 내 자리까지 왔다. "K님, 이거 어떻게 생각해요?" 3초 만에 결정났다. 지금은 다르다. 대표님 얼굴 본 지 두 달됐다. 결정은 회의 3번 거쳐야 난다.의사결정의 속도 50명 회사 때. 기능 추가 제안했다. 대표님한테 슬랙 보냈다. 30분 후 "ㄱㄱ" 답장 왔다. 다음 날 개발 들어갔다. 일주일 후 배포됐다. 실패하면? 다시 빼면 됐다. 지금은? 기획서 쓴다. 5페이지. 팀장님께 보고한다. "임원진 공유해볼게요." 일주일 후. "전략실이랑 먼저 얘기해보래요." 전략실 미팅 잡는다. 2주 걸린다. 미팅 가면 질문 폭탄이다. "시장 규모는요?" "경쟁사 벤치마크는요?" "예상 MAU는요?" 답변서 쓴다. 10페이지 됐다. 다시 검토 들어간다. "데이터팀이랑 검증 필요해요." 한 달 지났다. 아직 개발 안 들어갔다. 그새 경쟁사가 비슷한 거 냈다.협업의 복잡도 50명 때는 단순했다. 기획자 3명, 개발자 15명, 디자이너 4명. 다 알았다. 이름도, 성향도. "민수님 이거 가능해요?" "어, 2일이면 돼요." 끝이었다. 지금은? 서비스기획팀 8명. 개발본부 80명. 4개 팀으로 나뉨. 디자인실 12명. 앱, 웹, 브랜드로 분리. 기능 하나 추가하려면. 먼저 어느 팀 업무인지 파악한다. 백엔드인지, 프론트인지, 둘 다인지. 그 다음 담당자 찾는다. 지라에서 이름 검색한다. 조직도 열어본다. 슬랙 DM 보낸다. "안녕하세요, 서비스기획팀 K입니다." 처음 보는 사람이니까 정중하게. 답장이 온다. "저희 팀 업무 아닌 것 같은데요." "XX팀 YY님께 여쭤보세요." YY님 찾는다. 또 DM 보낸다. 이게 3번 반복된다. 결국 찾았다. "이거 공식 요청으로 올려주세요." 지라 티켓 생성한다. 기획서 첨부한다. 스펙 명세서도 쓴다. 우선순위 협의한다. 백로그 쌓인다. 일정 조율한다. 다른 팀 일정이랑도 맞춰야 한다. 미팅 잡는다. 참석자가 6명이다. 30분 회의에 6시간 투입되는 셈이다.정치의 시작 50명 때는 정치가 없었다. 다 똑같이 바쁘고 똑같이 야근했다. 목표도 하나였다. 살아남기. 300명은 다르다. 부서가 생겼다. 부서마다 이해관계가 다르다. 서비스기획팀은 신기능 원한다. 개발팀은 안정화 원한다. CS팀은 버그 수정 원한다. 다들 우선순위가 다르다. 회의 때 티격태격한다. "이건 우리가 먼저예요." 임원진도 쪼갠다. CTO는 기술 부채 해결 밀어붙인다. CPO는 신규 피처 요구한다. 중간에 낀 우리는? 눈치 본다. 어느 쪽이 더 센지. 어떤 팀은 예산 많다. 어떤 팀은 헤드카운트 늘어난다. 우리 팀은? 그대로다. 불만 쌓인다. "왜 저 팀만 지원해줘요?" 커피챗에서 푼다. 누가 승진했다는 소식 들린다. 내가 아는 그 사람이다. 일은 나만큼 안 했는데. "발표를 잘하더라." "임원진이랑 친하더라." 이런 말이 돈다. 나도 모르게 계산한다. 이 프로젝트 하면 누구한테 보일까. 이 회의엔 누가 참석할까. 예전엔 안 그랬다. 일만 잘하면 됐다. 이제는 보여줘야 한다. 프로세스라는 이름의 족쇄 50명 때는 프로세스가 없었다. 필요하면 만들었다. 불편하면 바꿨다. 지금은 프로세스가 먼저다. "절차 따라주세요." "승인 받으셨어요?" 기획서 템플릿이 있다. 10페이지 분량이다. 빈칸 다 채워야 한다. "이거 꼭 써야 해요?" "네, 규정이에요." 누가 만든 규정인지는 모른다. 코드 리뷰 프로세스 생겼다. 2명 이상 승인 받아야 한다. 긴급 버그 수정도 마찬가지다. 장애 나면? 장애 보고서 쓴다. 회고 미팅 잡는다. 재발 방지 대책 수립한다. 좋은 건 안다. 체계가 필요한 거. 근데 가끔은 답답하다. "일단 빠르게 해보는 게 어때요?" "프로세스 무시하면 나중에 문제 돼요." 맞는 말이긴 한데. 정보의 비대칭 50명 때는 다 알았다. 회사 상황. 다음 분기 계획. 누가 그만둔다는 것도. 전체 회의가 한 달에 한 번 있었다. 다 모였다. 대표님이 직접 얘기했다. "이번 달 매출 3억입니다." "다음 달 목표는 4억입니다." "투자 유치 진행 중입니다." 투명했다. 질문하면 바로 답해줬다. 숨길 게 없었다. 지금은? 전체 회의 분기에 한 번이다. 300명이 한 곳에 못 모인다. 온라인으로 한다. 발표 자료는 PPT 50장이다. 각 본부장이 돌아가며 발표한다. 우리 본부 차례 때만 집중한다. 질문? 사전에 받는다. 선별해서 답한다. 민감한 건 "오프라인에서 따로"다. 매출이 얼마인지 모른다. 우리 팀 예산이 얼마인지도 모른다. 회사 전체 로드맵은 더 모른다. 내 업무에만 집중한다. 터널 비전이다. 옆 팀이 뭐 하는지도 잘 모른다. 정보는 위에서 내려온다. 필요한 것만. 필터링돼서. 장점도 있긴 하다 불평만 한 건 아니다. 300명의 장점도 분명하다. 50명 때는 불안했다. 다음 달 월급 나올까. 투자 못 받으면 어쩌지. 지금은 좀 안정적이다. 월급은 제때 나온다. 4대 보험도 빠짐없다. 복지가 생겼다. 점심 식대 지원된다. 휴게실에 간식 있다. 연차도 눈치 안 보고 쓴다. 전문성도 높아졌다. 50명 때는 기획자가 다 했다. 디자인도 조금, 개발도 조금. 지금은 각자 역할이 명확하다. 나는 기획만 한다. 대신 기획을 깊게 한다. 배울 사람도 많다. 시니어 기획자가 3명이다. 질문하면 답해준다. 시스템도 갖춰졌다. 데이터 대시보드 있다. 지표 보면서 일한다. 감이 아니라 데이터로. 50명 때는 맨땅에 헤딩이었다. 지금은 레일이 깔려 있다. 그 위에서 달린다. 느리긴 해도 안전하다. 혼자 삽질할 일은 없다. 누군가는 답을 안다. 어느 쪽이 나을까 자주 생각한다. 50명으로 돌아갈까. 300명에 남을까. 50명의 짜릿함. 빠른 실행. 내 손으로 직접 만드는 느낌. 300명의 안정감. 체계. 전문성. 둘 다 맞는 말이다. 둘 다 틀린 말이기도 하다. 50명은 성장이 불안하다. 언제 죽을지 모른다. 올인하기 무섭다. 300명은 답답하다. 내 영향력이 작다. 톱니바퀴 하나 같다. 결국 타이밍이다. 20대 초반이면 50명이다. 실패해도 괜찮다. 배우는 게 많다. 30대 초반인 지금은? 300명이 맞는 것 같다. 커리어도 쌓이고. 월급도 괜찮고. 근데 가끔 그립다. 50명 때의 속도. 회의 30분에 결정 나던 때. 대표님이랑 직접 얘기하던 때.300명은 어정쩡하다. 스타트업의 속도도, 대기업의 체계도 반쪽이다. 근데 이게 현실이다. 회사는 계속 커진다. 나는 적응한다.

합정동 원룸에서 일하는 이 느낌

합정동 원룸에서 일하는 이 느낌

합정동 원룸에서 일하는 이 느낌 퇴근하고 집에 와도 7시 40분에 문 열었다. 현관 불 켜니까 70만원짜리 원룸이 보인다. 책상, 침대, 옷장. 끝이다. 신발 벗고 노트북 가방 내려놓는다. 회사 맥북 프로 하나, 개인 맥북 에어 하나. 둘 다 오늘 켰다. 씻고 나와서 배달 음식 시켰다. 떡볶이 세트. 20분 걸린단다. 그 사이에 노트북 켠다. 개인 거. 토스 업데이트됐다는 알림 와 있다. 바로 깐다.온보딩 플로우가 바뀌었다. 스크린샷 찍는다. 노션에 붙인다. "토스 온보딩 업데이트 - 2025.01.15" 페이지 만들었다. 변경점 쓴다. 3단계에서 2단계로 줄였네. 권한 요청 타이밍도 바뀌었다. 떡볶이 왔다. 먹으면서 계속 본다. 사이드 프로젝트라는 이름의 먹고 나서 설거지했다. 9시 10분이다. 회사 일 끝났으니 이제 내 일 할 시간. 사이드 프로젝트 피그마 파일 열었다. "독서 기록 앱" 기획 중이다. 벌써 3개월째. 지난주에 로그인 플로우 그렸다. 오늘은 홈 화면. 어떤 정보를 먼저 보여줘야 할까. 읽고 있는 책? 목표 달성률? 친구들 활동? 30분 그렸다. 마음에 안 든다. 지웠다. 다시 그린다.10시 넘었다. 아직도 홈 화면 하나 못 그렸다. 회사에서는 하루에 화면 10개씩 그린다. 여기서는 하나도 못 그린다. 왜 그럴까. 생각해봤다. 회사 일은 deadline이 있다. 개발자가 기다린다. 디자이너가 기다린다. 대표님이 기다린다. 사이드 프로젝트는 아무도 안 기다린다. 나만 기다린다. 그래서 더 어렵다. 완벽하게 하고 싶어진다. 회사 일은 일단 MVP로 가는데, 내 프로젝트는 처음부터 완벽해야 할 것 같다. 말이 안 되는 건 안다. 그래도 그렇다. 일이 취미가 되는 순간 11시쯤 됐다. 피그마 닫았다. 유튜브 켰다. PM 관련 영상 찾아본다. "Product Manager가 알아야 할 데이터 분석" 영상 나온다. 36분짜리. 본다. SQL 쿼리 나온다. 잘 모른다. 그래도 본다. 메모한다. "SELECT user_id, COUNT(*) FROM events WHERE..." 이런 거. 언젠가 쓸 수도 있다. 자정 넘었다. 영상 끝났다. 침대에 누웠다. 폰 든다. 브런치 열었다. 다른 PM들 글 읽는다. "주니어 기획자가 저지르기 쉬운 실수 5가지" 글이 떴다. 읽는다. 나도 다 해봤다. 1시 반이다. 자야 한다. 내일 9시 반까지 회사 가야 한다.폰 내려놓았다. 다시 든다. 링크드인 열었다. 피드 확인한다. 누가 이직했다. 누가 승진했다. 누가 사이드 프로젝트 런칭했다. 다들 열심히 산다. 나만 이러는 게 아니구나. 위로가 된다. 동시에 불안해진다. 70만원짜리 방에서 이 방에 산 지 2년 됐다. 처음 왔을 때는 회사 일만 했다. 퇴근하면 넷플릭스 보고 잤다. 지금은 다르다. 퇴근하면 더 일한다. 회사 일 말고 내 공부. 내 프로젝트. 내 성장. 언제부터였을까. 작년 여름쯤이었던 것 같다. 회사에서 프로젝트 하나 말아먹었다. 내 기획이 문제였다. 유저 니즈 파악을 잘못했다. 데이터를 안 봤다. 가정만 했다. 3개월 개발했는데 릴리즈하고 한 달 만에 없앴다. 아무도 안 썼다. 그때 느꼈다. 내가 모르는 게 너무 많다. 그 뒤로 집에서 공부하기 시작했다. 경쟁사 앱 분석. PM 책 읽기. SQL 독학. 사이드 프로젝트. 처음엔 힘들었다. 지금은 습관이다. 일과 삶의 경계 남자친구가 물어본 적 있다. "너 언제 쉬어?" 대답 못 했다. 쉬는 게 뭘까. 넷플릭스 보는 거? 그것도 경쟁사 오리지널 콘텐츠 UX 분석하면서 본다. 친구 만나서 밥 먹는 거? 그것도 식당 앱 주문 플로우 체크한다. 여행 가는 거? 그것도 여행 앱 북마크 기능 스크린샷 찍는다. 모든 게 일이 된다. 아니면 일감이 된다. 병일까? 아닐 것 같다. 좋아서 하는 거니까. 그런데 가끔 피곤하다. 머리가 아니라 마음이. 합정동 밤 2시 결국 2시가 됐다. 내일 회의 있다. 9시 반 데일리 스크럼. 10시 디자이너 싱크. 11시 개발 이슈 정리. 2시 이해관계자 미팅. 준비해야 한다. 자야 한다. 불 껐다. 침대에 누웠다. 천장 본다. 어둡다. 이게 맞나. 이렇게 사는 게. 모르겠다. 그냥 내일도 이렇게 살 것 같다. 책상에 맥북 두 개 놓여 있다. 회사 거, 내 거. 경계가 없다. 책상도, 시간도, 마음도. 70만원짜리 원룸. 합정동. 31살. 기획자. 이게 지금 내 삶이다.내일도 똑같겠지 눈 감았다. 내일 알람은 7시 반이다. 일어나면 회사 간다. 퇴근하면 집 온다. 노트북 켠다. 그렇게 산다. 매일. 이게 성장인지 집착인지 모르겠다. 그냥 멈출 수가 없다.합정동 원룸. 불 꺼진 방. 노트북 슬립 모드 불빛만 깜빡인다.

남자친구가 마케터라서 좋은 점, 어려운 점

남자친구가 마케터라서 좋은 점, 어려운 점

저녁 8시, 합정동 카페 남자친구가 늦는다고 문자 보냈다. 광고 캠페인 론칭이래. 나도 스프린트 마지막 주라 7시에 겨우 퇴근했다. 카페에 먼저 와서 노트북 켰다. 지라 티켓 정리. 내일 개발자한테 물어볼 거 메모. 그가 도착했을 때 나는 피그마를 보고 있었다. "또 일해?" 그가 웃으며 말했다. "너도 노트북 가방 메고 왔잖아." 나도 웃었다. 우린 둘 다 안다. 저녁 약속이라고 일을 완전히 떠날 수 없다는 걸.같은 팀 같지만 다른 팀 그와 사귄 지 2년. 둘 다 비즈니스 직군이라 통하는 게 많다. 회사 구조, 정치, 스트레스. 그런데 관점은 완전히 다르다. 그는 마케터다. 퍼포먼스 마케팅팀. 매일 광고 대시보드 본다. CPC, CVR, ROAS. 숫자로 성과 나온다. A/B 테스트 돌리고, 캠페인 최적화하고, 예산 분배한다. 나는 기획자다. 프로덕트 오너. 유저 플로우 그린다. 백로그 관리한다. 개발자, 디자이너랑 협업한다. 성과는... 글쎄. 릴리즈하고 한참 뒤에 알 수 있다. 지난주 저녁. 내가 말했다. "오늘 개발자가 또 스펙이 명확하지 않다고 했어. 다시 정리해야 돼." 그가 말했다. "스펙을 명확하게 못 줬으면 네 잘못 아니야?" 순간 화났다. 그런데 그는 악의가 없었다. 마케터 관점에선 당연한 말이다. 캠페인 브리프가 불명확하면 대행사가 못 하니까. 나는 설명했다. "기획은 그렇게 단순하지 않아. 개발하면서 바뀌는 거야. 기술적 제약도 있고." 그가 고개를 끄덕였다. 이해한다는 표정이었지만, 완전히 이해할 순 없다는 것도 알았다. 나도 그의 일을 완전히 이해 못 한다. 그가 "CPA가 너무 높아서 스트레스야"라고 하면, 나는 고개를 끄덕인다. 그런데 정확히 얼마나 심각한지는 모른다.서로의 일을 이해한다는 것 좋은 점도 많다. 회사 이야기를 할 수 있다. 친구들한테 얘기하면 "그게 뭔데?"부터 설명해야 한다. 그는 안다. 스프린트가 뭔지, 백로그가 뭔지, KPI가 뭔지. 그도 나한테 말한다. 광고 소재 테스트 결과, 타겟 오디언스 세그먼트, 퍼널 최적화. 나는 대충 이해한다. 완벽하진 않지만, 공감은 할 수 있다. 한 달 전이었다. 내가 기획한 기능이 드디어 릴리즈됐다. 3개월 걸렸다. 개발 일정 지연, 디자인 수정, 이해관계자 설득. 힘들었다. 그날 저녁, 그가 꽃을 사왔다. "고생했어. 알아, 얼마나 힘들었는지." 눈물 날 뻔했다. 회사에서는 아무도 몰라준다. 대표님은 "다음 기능은 언제 돼요?"만 물어본다. 개발자들은 이미 다음 스프린트에 집중한다. 그런데 그는 안다. 기획자가 릴리즈까지 가는 게 얼마나 험난한지.균형이 어렵다 문제는 균형이다. 저녁에 만나도 일 얘기를 한다. 자연스럽게 나온다. "오늘 회의가 지옥이었어", "대표님이 또 우선순위를 바꿨어", "광고 성과가 안 나와서 미치겠어". 처음엔 괜찮았다. 서로 공감하고, 조언하고, 위로했다. 그런데 요즘은 피곤하다. 지난 토요일. 우린 한강에 갔다. 돗자리 깔고 누웠다. 그가 핸드폰을 봤다. 광고 대시보드였다. "주말인데." 내가 말했다. "응, 그냥 확인만." 그가 대답했다. 나도 노트북을 가져왔다. 월요일 스프린트 계획. 그가 눈치챘다. "너도?" "응. 그냥 정리만." 우린 웃었다. 자조적으로. 저녁엔 논현동 맛집에 갔다. 파스타가 맛있었다. 그런데 그가 말했다. "여기 마케팅 잘하네. 인스타 광고 봤어. 크리에이티브가 좋더라." 나는 말했다. "앱 UX가 별론데. 예약 플로우가 너무 복잡해." 우린 각자의 관점으로 세상을 본다. 맛집도 일의 연장이 된다. 집에 돌아와서 그가 말했다. "우리 일 얘기 좀 덜 하자." 나도 동의했다. "응. 주말엔 일 금지." 그런데 지키기 어렵다. 일이 우리 삶의 큰 부분이니까. 다른 관점이 주는 것 싸운 적도 있다. 내가 새로운 기능을 기획했다. 유저 리서치 결과, 데이터 분석, 경쟁사 벤치마킹. 3주 걸렸다. 그한테 자랑스럽게 보여줬다. 그가 말했다. "이거 마케팅으로 푸시할 수 있어? 유저한테 어떻게 알릴 건데?" 순간 멈췄다. 생각 안 했다. 화가 났다. "아직 개발도 안 들어갔는데 벌써 마케팅?" 그가 말했다. "기능 만들어도 유저가 모르면 의미 없잖아. GTM 전략은 생각했어?" 말이 맞았다. 그런데 인정하기 싫었다. "너는 기획을 몰라서 그래. 일단 만들고 생각하는 거야." "너는 마케팅을 몰라서 그래. 만들기 전에 생각해야지." 우린 서로 쳐다봤다. 둘 다 틀리지 않았다. 둘 다 맞았다. 결국 내가 말했다. "...다음부턴 GTM도 같이 생각할게." 그가 웃었다. "나도 기획 관점 배울게." 싸움이 배움이 됐다. 지금은 기획할 때 그한테 먼저 보여준다. 그는 마케터 관점에서 피드백 준다. "이 기능, 유저한테 어떻게 설명할 거야?", "이 문구, 광고 카피로 쓸 수 있어?", "이 플로우, 전환율 생각했어?" 나도 그의 캠페인 기획서를 본다. 기획자 관점에서 피드백 준다. "이 랜딩페이지, UX가 별론데", "CTA 버튼이 너무 많아", "유저 플로우가 자연스럽지 않아". 우린 서로를 보완한다. 완벽하진 않지만, 시도한다. 경계선 긋기 한 달 전, 우린 규칙을 만들었다.평일 저녁 9시 이후 일 얘기 금지. 주말 중 하루는 완전 디지털 디톡스. 데이트 중 회사 슬랙 확인 금지.지키기 어렵다. 특히 릴리즈 주간이나 캠페인 론칭 기간엔 불가능하다. 그래도 노력한다. 지난주 목요일. 내가 개발자랑 싸웠다. 스펙 해석 문제였다. 스트레스 폭발. 저녁에 그를 만났다. 쏟아내고 싶었다. 그런데 시계를 봤다. 9시 5분. "오늘 힘들었어?" 그가 물었다. "응. 그런데 9시 넘어서. 내일 얘기할게." 그가 내 손을 잡았다. "괜찮아. 힘들면 얘기해." 결국 얘기했다. 규칙을 깼다. 그런데 괜찮았다. 완벽하게 지키려고 하지 않는다. 유연하게 조정한다. 지난 일요일. 우린 경복궁에 갔다. 핸드폰을 호텔에 두고 왔다. 둘 다. 처음엔 불안했다. 슬랙 알림 올 텐데. 긴급한 거 있으면 어쩌지. 그런데 30분 지나니 괜찮았다. 세상은 돌아간다. 내가 없어도. 우린 걸었다. 단풍을 봤다. 커피를 마셨다. 일 얘기를 안 했다. 저녁에 호텔로 돌아와서 핸드폰을 켰다. 슬랙 알림 37개. 그의 핸드폰도 마찬가지. 우린 웃었다. "내일 보자." "응. 내일." 그날 밤, 우린 그냥 사람이었다. 기획자도, 마케터도 아니었다. 그냥 우리. 아직 배우는 중 완벽하지 않다. 여전히 일 얘기를 너무 많이 한다. 여전히 저녁에 노트북을 연다. 여전히 서로의 관점이 부딪친다. 그런데 괜찮다. 우린 배운다. 그는 내가 스프린트 회고할 때 스트레스받는 걸 안다. 그날 저녁엔 좋아하는 디저트를 사온다. 나는 그가 광고 성과 안 나올 때 예민해지는 걸 안다. 그럴 땐 조언하지 않는다. 그냥 듣는다. 어제 저녁, 그가 물었다. "나랑 사귀어서 좋아?" 나는 생각했다. 진짜 좋은가? 좋다. 힘들어도 좋다. 그는 내 일을 이해한다. 완벽하진 않지만 충분하다. 그는 내가 릴리즈할 때 축하해준다. 개발자랑 싸울 때 공감해준다. 기획자가 얼마나 외로운 직업인지 안다. 나도 그의 일을 이해한다. 캠페인 성과가 좋을 때 진심으로 기뻐한다. 광고 예산 깎일 때 화를 같이 낸다. 마케터가 얼마나 숫자에 시달리는지 안다. 우린 같은 세계에 산다. 비즈니스, KPI, 회의, 스트레스. 다른 직군이지만 같은 세계. "좋아." 내가 대답했다. "나도." 그가 웃었다. 오늘도 우린 각자의 일을 한다. 그는 광고 대시보드를 본다. 나는 지라 티켓을 정리한다. 저녁에 만나서, 일 얘기를 조금 하고, 일 아닌 얘기도 하려고 노력한다. 완벽하진 않다. 그런데 충분하다.같은 세계에 살지만, 다른 관점을 가진 사람과 산다는 것. 어렵지만 배운다.

목요일 저녁 백로그 정리, 내일의 스프린트를 결정한다

목요일 저녁 백로그 정리, 내일의 스프린트를 결정한다

목요일 저녁 백로그 정리, 내일의 스프린트를 결정한다 목요일 오후 5시 30분 회의가 끝났다. 개발팀은 퇴근 준비 중이다. 나는 이제 시작이다. 내일이 금요일이다. 스프린트 플래닝이 10시다. 준비 안 하면 내일 1시간 회의가 3시간 된다. 경험으로 안다. 지라를 켠다. 백로그 티켓 47개. 우선순위 없음이 23개다. 웃긴다.실패한 스프린트의 공통점 지난 3개월 데이터를 봤다. 실패한 스프린트 5번. 공통점이 있다. 목요일에 백로그 정리를 안 했다. 금요일 아침에 즉흥으로 뽑았다. 결과:스토리 포인트 추정 2배 차이 개발 중 스펙 질문 폭탄 스프린트 중간에 티켓 교체 번다운 차트는 계단식데일리에서 "이거 왜 하는 거죠?"가 나오면 끝이다. 목요일의 30분이 2주를 결정한다. 백로그 정리 루틴 5시 반부터 시작한다. 순서가 있다. 1단계: 현실 파악 (10분) 이번 스프린트 남은 티켓 확인. Done: 12개, In Progress: 5개, To Do: 3개. Progress 중인 것들 상태 확인. 슬랙으로 개발자한테 물어본다. "내일까지 되나요?" 대부분 "힘들 것 같아요"다. 알았다. 다음 스프린트로 넘긴다.2단계: 백로그 우선순위 (20분) 백로그 상단부터 본다. 우선순위 기준은 명확하다.대표님이 언급한 것 (어쩔 수 없다) 유저 불편 티켓 (CS 3건 이상) 기술 부채 (개발팀 요청) 신규 피처 (데이터 있는 것부터)'하면 좋은 것'은 과감히 뺀다. 백로그 하단으로 보낸다. 아카이브 직전이다. 우선순위 태그를 단다. P0, P1, P2. P3는 사실상 안 한다는 뜻이다. 3단계: 스토리 스플릿 (30분) 큰 티켓을 쪼갠다. '회원 정보 수정 기능'은 너무 크다. 쪼개면:닉네임 변경 (2포인트) 프로필 사진 업로드 (3포인트) 비밀번호 변경 (5포인트, 보안 검토 필요)각각 독립적으로 배포 가능하게. MVP 마인드다. 억셉턴스 크리테리아를 명확히 쓴다. "언제 이게 완료된 건가요?" 기준이다. [완료 조건] - 사용자가 닉네임 입력 시 중복 체크 완료 - 특수문자 제한 (한글, 영문, 숫자, _, - 만) - 변경 완료 시 토스트 메시지 노출 - 프로필 화면에 즉시 반영이렇게 써야 개발자가 "됐습니다" 할 수 있다.개발자랑 사전 싱크 7시다. 백엔드 리드가 아직 있다. 슬랙을 보낸다. "내일 플래닝 전에 5분만 주세요" 이게 핵심이다. 금요일 회의 전에 개발 리드랑 미리 본다. "이 티켓들 다음 스프린트에 넣으려는데, 공수 어떠세요?" 리드가 대략 본다. "이건 3포인트보다 5포인트일 것 같은데요. API 새로 만들어야 해서." 좋다. 미리 알았다. 내일 회의에서 시간 안 뺏긴다. "이건 순서 바꾸면 안 돼요? 인증 기능 먼저 해야 이게 가능해요." 아. 의존성을 놓쳤다. 티켓 순서를 바꾼다. 이 5분이 내일 30분을 아낀다. 플래닝 회의가 1시간 안에 끝난다. 스프린트 골 초안 작성 백로그 정리가 끝났다. 이제 스프린트 골을 쓴다. 막연하게 "기능 개발"이 아니다. 측정 가능하게 쓴다. 이번 스프린트 골 (2주) 1. 회원 정보 수정 기능 배포 (닉네임, 프로필 사진) → 목표: 주 활성 유저 중 10% 이상이 프로필 편집 경험2. 검색 결과 필터링 개선 → 목표: 검색 후 이탈률 현재 45% → 35%로 감소3. 기술부채: 레거시 API 3개 마이그레이션 → 목표: 응답속도 평균 1.2초 → 0.8초구체적이다. 2주 후에 "했다/못했다"가 명확하다. 이걸 컨플루언스에 써둔다. 내일 회의 시작하면서 이걸 먼저 공유한다. "이번 스프린트 우리 목표입니다. 이거 동의하시나요?" 여기서 동의가 나와야 한다. 목표 없이 시작하면 2주 뒤에 "뭐 했지?" 상태다. 커뮤니케이션 사전 정리 8시다. 마지막 단계다. 관련 부서에 헤드업을 준다. 디자인팀 슬랙: "내일 스프린트에 프로필 편집 기능 들어가요. 디자인 시안 최종 컨펌 부탁드려요." 마케팅팀 이메일: "2주 후 검색 필터 개선 배포 예정입니다. 공지 필요하면 말씀해주세요." CS팀 슬랙: "회원정보 수정 기능 다음 스프린트에 개발합니다. 관련 문의 패턴 있으면 공유 부탁드려요." 이렇게 미리 알린다. 스프린트 중간에 "어? 몰랐는데요?" 안 나온다. QA팀한테는 테스트 케이스 초안을 보낸다. 어차피 개발 끝나고 보내면 늦다. 지금 보내서 피드백 받는다. 내일을 위한 체크리스트 노션에 체크리스트를 만든다. [금요일 스프린트 플래닝 준비 완료] ✅ 백로그 우선순위 정렬 (P0 7개, P1 12개) ✅ 큰 티켓 스플릿 완료 (3개 → 9개) ✅ 억셉턴스 크리테리아 작성 ✅ 개발 리드 사전 싱크 완료 ✅ 스프린트 골 초안 작성 ✅ 관련 팀 헤드업 발송 ✅ 의존성 티켓 순서 조정 ⬜ 회의실 예약 확인 (내일 아침)8개 중 7개 체크. 회의실은 내일 아침에 확인한다. 목요일이 금요일을 만든다 8시 반이다. 퇴근한다. 동료가 본다. "백로그 정리해요? 내일 아침에 하면 되는데." 안 된다. 내일 아침은 슬랙 폭탄이다. 목요일 저녁 1시간이 금요일을 결정한다. 준비 안 하고 플래닝 들어가면:티켓 설명하는데 20분 우선순위 토론 30분 "이거 왜 해요?" 질문에 횡설수설 포인트 추정 왔다갔다 회의 3시간, 결론은 애매준비하고 들어가면:스프린트 골 공유 5분 티켓 훑기 20분 포인트 추정 20분 질문 대응 10분 회의 1시간, 모두 명확차이는 목요일 저녁이다. 집에 간다. 내일은 9시 반 출근이다. 9시 50분까지 커피 마시고. 10시 정각에 회의 시작. "이번 스프린트 목표부터 볼까요?" 회의는 딱 1시간 걸릴 것이다. 목요일의 내가 만들어놓은 길이다.목요일의 1시간이 2주를 구한다. 준비는 즉흥을 이긴다.

기획은 누구나 할 수 있다는 말에 대해

기획은 누구나 할 수 있다는 말에 대해

기획은 누구나 할 수 있다는 말에 대해 어제 들은 말 "기획이요? 솔직히 누구나 할 수 있지 않나요?" 신입 개발자가 던진 말이다. 악의는 없었다. 순수하게 궁금해서 물은 거였다. 나도 안다. 그래도 순간 멍했다. 6년이다. 6년 동안 뭘 배웠나 싶었다. 점심시간에도 그 말이 맴돌았다. 퇴근길에도. 집에 와서도. 그래서 쓴다. 정리하고 싶다. 나한테도 설명하고 싶다.누구나 할 수 있다는 착각 처음 듣는 말은 아니다. 대학생도 말한다. 마케터도 말한다. 심지어 대표님도 가끔. "이거 기획서 간단한데 왜 이렇게 오래 걸려?" 간단해 보인다는 거다. 화면 몇 개 그리고. 버튼 위치 정하고. 그게 전부 아니냐고. 맞다. 결과물만 보면 간단하다. A4 20장. 피그마 파일 하나. 그게 전부처럼 보인다. 근데 그 뒤에 뭐가 있는지 모른다. 안 보인다. 안 보이니까 없는 줄 안다. 작년에 결제 플로우 개선 기획했다. 최종 산출물은 화면 8개. 간단해 보였다. 근데 그 전에:경쟁사 7개 앱 결제 플로우 분석 (이틀) 유저 인터뷰 12건 (일주일) CS 데이터 분석 300건 (사흘) 이탈률 구간별 분석 (이틀) 개발 공수 산정 3번 (각각 다른 방식) 법률 검토 (PG사 담당자 미팅 2번) 디자이너랑 와이어프레임 10번 수정 이해관계자 설득 미팅 4번총 3주 반. 화면 8개 나오는 데 3주 반. 이게 보이나. 안 보인다. 결과물만 본다. 그래서 쉬워 보인다.기획이 아니라 의사결정이다 기획자가 하는 일. 화면 그리는 게 아니다. 의사결정이다. 매일 수십 개 결정한다:이 기능 넣을까 말까 A안 B안 중 뭘 선택할까 이번 스프린트에 들어갈까 우선순위가 높을까 낮을까 개발 공수 대비 효과가 있을까 유저가 진짜 원하는 걸까 비즈니스 목표와 맞을까하나하나가 결정이다. 그리고 각각 근거가 필요하다. "왜 이렇게 기획했어요?" 이 질문에 답해야 한다. 매번. 개발자한테. 디자이너한테. 대표님한테. PM한테. "그냥요"는 없다. "느낌상요"도 없다. 데이터 보여줘야 한다. 로직 설명해야 한다. 지난주 상품 상세 개편 기획했다. 리뷰 섹션을 위로 올릴지 말지. 간단한 결정 같다. 근데:현재 리뷰 클릭률 8.2% 리뷰 본 유저의 구매 전환율 23% (안 본 유저 12%) 스크롤 도달률 상위 3개 섹션 분석 경쟁사 5곳 리뷰 배치 비교 A/B 테스트 시나리오 2가지 개발 공수 각각 3일, 5일이 정도 준비하고 회의 들어간다. 그래야 "그냥 위로 올려보면 어때요?"라는 질문에 답할 수 있다. 누구나 할 수 있나. 이런 결정을. 보이지 않는 6년 1년 차 때는 몰랐다. 화면만 그렸다. 예쁘게 그리면 됐다. 2년 차. 개발자가 물었다. "이거 예외 케이스는요?" 뭔 예외. 그냥 로그인하면 되지. 근데 아니었다:비밀번호 틀리면? 계정 잠금되면? 소셜 로그인 토큰 만료되면? 네트워크 끊기면? 기기 변경했으면? 탈퇴 후 재가입이면?로그인 하나에 경우의 수가 20개였다. 그때 알았다. 기획이 화면 그리기가 아니라는 걸. 3년 차. 데이터 보기 시작했다. SQL 배웠다. 쿼리 짜는 건 못해도 읽을 순 있다. 유저 행동 데이터 보니까 달랐다. 내가 생각한 플로우로 안 움직인다. 메인에서 상세로 간다고 생각했다. 근데 30%는 검색에서 바로 상세로 간다. 20%는 푸시 알림에서. 15%는 URL 직접 접근. 시작점이 다르면 컨텍스트가 다르다. 같은 화면이어도 다르게 기획해야 한다. 4년 차. 우선순위를 배웠다. 다 중요하다. 근데 다 못 한다. 개발 리소스는 한정됐다. 이번 분기 목표는 정해졌다. 뭘 먼저 할까. RICE 스코어링 배웠다. ICE 모델도. 근데 공식만으론 안 됐다. 정치도 있다. 파워게임도. CEO가 원하는 기능. 개발팀이 싫어하는 기능. 유저는 원하는데 매출은 안 나는 기능. 어떻게 조율할까. 어떻게 설득할까. 이게 기획자 일이었다. 5년 차. 실패를 배웠다. 기획한 기능 3개 중 2개는 실패다. 쓰레기 기능 만들었다. 아무도 안 쓴다. DAU 0.8%. 개발 3주 걸렸는데. 왜 실패했나. 가설이 틀렸다. 유저 니즈를 착각했다. 검증 없이 밀어붙였다. 이것도 배움이다. 실패 안 해본 기획자 믿기 힘들다. 6년 차. 지금. 시스템으로 본다. 한 기능이 다른 기능에 영향 준다. 푸시 알림 하나 추가하면:알림 센터 UI 수정 알림 설정 메뉴 추가 푸시 발송 로직 개발 CS 응대 가이드 작성 앱 용량 증가 (SDK 추가) 배터리 소모 테스트 개인정보처리방침 수정하나가 아니다. 연결돼 있다. 전체를 봐야 한다. 이게 6년이다. 보이지 않는 6년.전문성이라는 것 의사가 "의학은 누구나 할 수 있다"고 들으면 어떨까. 변호사가 "법률은 간단하다"고 들으면. 개발자가 "코딩은 쉽다"고 들으면. 화낼 거다. 당연히. 근데 기획자는 참는다. 웃으면서 "네, 쉬워 보이죠"라고 한다. 왜. 왜 우리는 전문성을 주장 못 할까. 코드는 보인다. 복잡함이 보인다. 법률 용어는 어렵다. 의학 용어는 더 어렵다. 근데 기획은 한글이다. 평범한 말로 쓴다. 그래서 쉬워 보인다. 여기에 함정이 있다. 쉬운 말로 복잡한 걸 설명하는 게 기획이다. 어렵게 쓰면 못하는 거다. 좋은 기획서는 중학생도 이해한다. 근데 그 기획서 나오기까지는 중학생이 못 한다. 전문성은 결과물의 복잡함이 아니다. 과정의 깊이다. 설명하는 법을 배워야 한다 어제 그 신입 개발자. 오늘 다시 만났다. "어제 그 말, 기분 나빴으면 미안해요." "아니다. 괜찮다." 근데 괜찮지 않았다. 그래서 말했다. "기획이 쉬워 보이는 거, 이해한다. 근데 한 번 해볼래?" "네? 제가요?" "다음 주 소셜 공유 기능. 기획해봐. 화면 3개면 된다. 간단하다." 얼굴이 굳었다. "저는... 기획 안 해봐서..." "누구나 할 수 있다며." 침묵. 길었다. "농담이다. 근데 진짜 해봐. 도와줄게. 뭐가 어려운지 직접 느껴보면 좋겠다." "...해볼게요." 이게 답이다. 말로 설명 안 된다. 직접 해봐야 안다. 기획자의 전문성. 말로 증명 안 된다. 포트폴리오로 보여줘야 한다. "이 기능 제가 기획했는데요, MAU 30% 올랐어요." "이거 제가 개선해서 이탈률 15% 줄었어요." "A/B 테스트 10번 돌려서 이 안 찾았어요." 숫자로 말해야 한다. 결과로 보여줘야 한다. 그래도 배워야 하는 것들 6년 차인데도 모르는 게 많다. SQL 더 잘하고 싶다. 쿼리 직접 짜고 싶다. 개발자 괴롭히기 싫다. 데이터 분석 더 배우고 싶다. 코호트 분석. 퍼널 분석. 툴만 다루는 게 아니라 인사이트 뽑고 싶다. UX 리서치 제대로 배우고 싶다. 유저 인터뷰 더 잘하고 싶다. 편향 없이 질문하고 싶다. 비즈니스 감각 키우고 싶다. 매출 구조 이해하고 싶다. 단가, 마진, LTV, CAC. 숫자로 말하고 싶다. 개발 프로세스 더 알고 싶다. API 구조. 데이터베이스 설계. 그래야 현실적인 기획 나온다. 배울 게 산더미다. 6년 했는데도. 12년 차 선배 보면 더 멀다. 누구나 할 수 있다고? 6년 배우고도 부족한데. 인정받는 방법 결국 실력이다. 말로 안 된다. 좋은 기획 하나가 백 마디 설명보다 낫다. 성공한 프로젝트 하나가 증명이다. 그래서 열심히 한다. 경쟁사 앱 분석한다. 유저 리뷰 읽는다. 데이터 본다. 주말에 PM 책 읽는다. 온라인 강의 듣는다. 사이드 프로젝트 기획한다. 이게 전문성이다. 계속 배우는 것. 계속 고민하는 것. "기획은 누구나 할 수 있다"는 말. 반은 맞다. 누구나 시작할 수 있다. 맞다. 진입장벽이 낮다. 맞다. 근데 잘하는 건 다르다. 지속하는 건 다르다. 깊이 파는 건 다르다. 누구나 피아노 칠 수 있다. 건반 누르면 소리 난다. 근데 피아니스트는 아무나 못 된다. 누구나 글 쓸 수 있다. 한글 안다. 근데 작가는 아무나 못 된다. 기획도 같다. 누구나 할 수 있다. 근데 잘하는 건 다르다. 오늘의 결론 그 신입 개발자. 사실 고맙다. 질문 던져줘서. 덕분에 정리했다. 내가 뭘 배웠는지. 뭘 하는지. 6년. 길다면 길다. 짧다면 짧다. 근데 분명 배운 게 있다. 의사결정하는 법. 우선순위 정하는 법. 데이터 읽는 법. 사람 설득하는 법. 실패 받아들이는 법. 이게 기획자다. 화면 그리는 사람 아니다. 의사결정하는 사람이다. 내일 출근하면 또 듣겠지. "이거 왜 이렇게 기획했어요?" 괜찮다. 답할 수 있다. 근거 있다. 데이터 있다. 그게 전문성이다. 6년이 준 것. 누구나 할 수 있다고? 해봐. 해보고 말해.기획은 쉽지 않다. 그래서 계속 배운다.

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 준비했다. 또 설득한다.