Showing Posts From
서비스기획
- 25 Dec, 2025
6년차 기획자의 진급 고민
6년차 기획자의 진급 고민 6년이 됐다 어제 캘린더를 보다가 깨달았다. 내가 기획자로 첫 출근한 게 2019년 3월이었다. 지금 2025년 1월. 정확히 6년 차다. 신입 때는 와이어프레임 하나 그리는 것도 떨렸는데. 지금은 전체 서비스 구조를 혼자 설계한다. 개발팀 스프린트 계획도 내가 리드한다. 대표님한테 "이건 왜 안 되냐"는 질문에 데이터 들고 설득도 한다. 그런데 요즘 자주 생각한다. 이제 뭐지? 다음 단계가 뭔지 모르겠다.현실적인 선택지는 세 가지 점심 먹으면서 선배 기획자한테 물었다. "저 이제 어떻게 해야 돼요?" 선배가 웃으면서 말했다. "리드 기획자, 프로덕트 매니저, 아니면 이직." 집에 와서 노트에 정리해봤다. 1. 리드 기획자 (Lead Planner)우리 팀 구조상 가능한 직급 3명 정도 관리하면서 계속 기획 연봉은 7500만원 정도? 하지만 여전히 실무자2. 프로덕트 매니저 전환PM은 더 넓게 본다. 비즈니스까지. 데이터 분석 더 잘해야 함 사업부 리더들이랑 싸워야 함 솔직히 겁난다3. 큰 회사로 이직네이버, 카카오급 가면 시스템 배운다 연봉은 더 오를 수도 근데 나이 31살, 이직 타이밍?세 개 다 장단점이 있다. 답이 안 나온다. 지금 회사에서의 현실 화요일에 대표님이 나를 불렀다. "K씨, 우리 새 서비스 기획 맡아줄 수 있어요? 예산 확보됐어요." 좋은 기회다. 근데 질문을 했다. "제가 PM으로 하는 건가요, 아니면 기획자로 하는 건가요?" 대표님이 잠깐 멈췄다. "음... 일단 기획으로 시작하고, 성과 나오면 PM 검토해볼게요." 나왔는데 기분이 묘했다. 성과 나오면, 이라는 말이 계속 걸린다. 6년 동안 런칭한 기능이 8개다. 월 활성 사용자 20만 만든 기능도 있다. 그래도 아직 '검토'다. 우리 회사 구조상 기획자 위에는 사업부장이다. PM 직급이 없다. 만들어지려면 조직 개편이 필요하다. 언제? 모른다. 현실적으로 여기서는 리드 기획자가 천장이다.다른 기획자들은 어떻게 하나 목요일 저녁, PM/기획자 커뮤니티 모임 갔다. 7년 차 언니가 있었다. 최근에 PM으로 전환했다고 한다. "어떻게 했어요?" "회사 옮겼지. 기획자로는 한계 느껴서." 5년 차 오빠도 있었다. "나는 리드로 만족해. PM은 정치 싸움이더라. 난 기획이 좋아." 8년 차 선배는 프리랜서 했다. "월 500 받고 외주 기획 해. 자유롭고 좋아. 근데 불안하긴 해." 다들 다르다. 정답이 없다는 게 더 답답하다. 집에 와서 맥주 마시면서 생각했다. 나는 뭘 원하는 거지? 내가 정말 원하는 건 뭔가 금요일 퇴근하고 남자친구 만났다. 고민 이야기했다. "너는 뭐가 제일 재밌어?" 질문이 단순했는데 대답이 안 나왔다. "음..." 생각해봤다. 유저 플로우 그릴 때? 재밌다. 새 기능 기획할 때? 재밌다. 데이터 보고 가설 세울 때? 약간 재밌다. 근데 제일 싫은 건? 이해관계자 조율. 일정 압박. 의사결정권 없는 것. "나는 기획은 좋은데, 권한이 없는 게 싫은 것 같아." 남자친구가 웃었다. "그럼 PM 해야지. 그게 의사결정자잖아." 맞는 말이다. 근데 PM 되려면 숫자를 봐야 한다. 매출, 전환율, 리텐션, CAC, LTV. 지금도 보긴 하는데 주도적으로는 아니다. 그리고 PM은 실패하면 책임진다. 기획자는... 솔직히 좀 숨을 수 있다. 무섭다.6개월 실험을 하기로 했다 주말 내내 고민했다. 일요일 밤, 결론 냈다. 당장 결정하지 말자. 6개월 실험하자. 실험 1: PM 역량 키우기데이터 분석 강의 듣기 (SQL 마스터) 비즈니스 지표 공부 (매출, 마케팅) 실제 숫자로 의사결정 연습실험 2: 리더십 경험 쌓기신입 기획자 멘토링 자원하기 프로젝트 리드 해보기 팀 회고 진행해보기실험 3: 시장 조사PM 채용공고 매주 체크 이직 상담 2곳 받아보기 연봉 시장가 파악6개월 후, 2025년 7월. 그때 가서 다시 판단한다. 지금 회사에서 PM 가능성 있나? 없으면 이직 준비. 있으면 협상. 리드 기획자로 만족할 수 있나? 있으면 여기 남기. 없으면 큰 회사로. 프리랜서 해볼까? 재정 계산해보고 결정. 일단 6개월. 움직이면서 답을 찾는다. 6년 차의 진급은 실력만으론 안 된다 월요일 출근했다. 새 서비스 기획 맡기로 했다. 대표님한테 말했다. "이번엔 PM 역할로 해보고 싶어요. 비즈니스 지표까지 책임지고 싶습니다." "오, 좋아요. 그럼 매출 목표도 같이 세워볼까요?" 떨렸다. 근데 "네" 했다. 이게 내 실험의 시작이다. 6년 차 진급 고민의 진짜 문제는 이거다. 실력만으로는 안 올라간다. 기획 능력? 있다. 와이어프레임? 잘 그린다. 협업? 잘한다. 근데 그걸로는 PM 못 된다. 필요한 건:비즈니스 이해 데이터 기반 의사결정 리더십 경험 실패 책임지는 용기 타이밍마지막 타이밍이 제일 중요하다. 회사가 성장하는 시점, 조직이 확장되는 시점, 내 성과가 증명된 시점. 이 세 개가 맞아떨어져야 한다. 그래서 6개월 실험이다. 타이밍을 만들거나, 찾는다.지금 당장 답이 없어도 괜찮다. 움직이면서 찾는다. 6개월 후에 다시 쓴다.
- 23 Dec, 2025
스톡옵션의 현실 - 기획자의 성과는 어떻게 평가되나
스톡옵션 받았다 작년 말 연봉 협상 때였다. 대표님이 말했다. "올해는 스톡옵션도 드립니다. 300주요." 좋은 건가? 싶었다. 주변에서 물어봤다. 개발자 선배는 "회사 망하면 휴지"라고 했다. 디자이너 동기는 "그거 받아도 현금화는 언제 되냐"고 했다. 나도 잘 몰랐다. 그냥 받았다. 계약서에 사인했다. 베스팅 4년, 1년 cliff. 무슨 뜻인지도 제대로 모르고.문제는 그 다음이었다. 기획자 성과를 뭘로 재나 3개월 후 1분기 리뷰. "K님, 이번 분기 성과를 정리해주세요." 막막했다. 개발자는 명확하다. 코드 머지 수, 버그 픽스, 배포 횟수. 디자이너도 있다. 화면 수, 디자인 시스템 컴포넌트, 사용성 개선. 기획자는? 나는 이렇게 정리했다.신규 기능 3개 런칭 유저 플로우 개선 5건 A/B 테스트 2건 진행팀장님이 물었다. "그래서 이게 비즈니스에 어떤 임팩트를 줬나요?" 말문이 막혔다.MAU는 올랐다. 근데 내 기능 때문인가? 마케팅 프로모션도 있었다. 계절적 요인도 있었다. 내가 기여한 게 몇 %인지 모른다. 리텐션은 떨어졌다. 근데 내 탓인가? 경쟁사가 업데이트했다. 서버 장애도 있었다. 뭐가 원인인지 알 수 없다. 팀장님은 말했다. "정량적으로 증명해야 합니다. 스톡옵션은 성과 기반이니까요." 그날 밤 잠을 못 잤다. 개발자는 다르다 옆자리 개발자를 봤다. 그는 PR 300개를 머지했다. 숫자가 명확하다. 핵심 기능의 성능을 40% 개선했다. 측정 가능하다. 장애 대응 3건. 기록에 남는다. 그의 스톡옵션은 나보다 많다. 500주. 당연하다고 생각했다. 성과가 명확하니까. 디자이너 동기도 마찬가지다. 디자인 시스템 구축으로 개발 시간 30% 단축. 사용성 테스트로 이탈률 15% 감소. 숫자로 말한다. 나는? 기능을 잘 정의했다. 근데 숫자는? 개발자랑 소통 잘했다. 근데 지표는? 유저 니즈를 파악했다. 근데 증명은?인사팀에서 메일이 왔다. "올해부터 성과평가 기준이 바뀝니다. OKR 기반입니다." 또 숫자다. OKR은 답이 아니었다 우리 팀은 OKR을 세웠다. Objective: 유저 경험 개선 Key Result 1: NPS 10점 향상 Key Result 2: 주요 플로우 이탈률 20% 감소 Key Result 3: 고객 문의 30% 감소 좋아 보였다. 측정 가능해 보였다. 3개월 후. NPS는 8점 올랐다. 목표 미달. 근데 우리 기능 때문인가? 고객센터 개선도 있었다. 이탈률은 25% 감소했다. 목표 초과 달성. 근데 내 기획 때문인가? UX 라이팅 변경도 있었다. 고객 문의는 40% 감소. 좋다. 근데 내 역할은? FAQ 개선은 CS팀이 했다. 또 모호하다. 팀장님은 말했다. "K님 기여도를 명확히 해야 스톡옵션 추가 부여가 가능합니다." 나는 물었다. "어떻게요?" "그게... 고민입니다." 둘 다 모른다. 평가 기준을 만들어봤다 혼자 정리했다. 기획자 성과를 어떻게 측정할까.기능 출시 속도분기당 런칭 개수 기획부터 배포까지 걸린 시간 재작업 횟수문제: 속도가 빠르다고 좋은 기획은 아니다.데이터 임팩트담당 기능의 사용률 전환율, 리텐션 개선도 A/B 테스트 승률문제: 다른 변수가 너무 많다.협업 기여도개발자 피드백 점수 커뮤니케이션 효율성 프로젝트 지연 횟수문제: 정성 평가다. 또 주관적이다.전략적 기여신규 사업 기회 발굴 경쟁사 분석 퀄리티 로드맵 정확도문제: 단기간에 측정 불가능. 어느 것도 완벽하지 않다. PM 커뮤니티에 물었다. "여러분은 어떻게 평가받나요?" 댓글이 30개 달렸다. 대부분 "저도 모르겠어요"였다. 타사 사례를 찾아봤다 토스는 어떻게 할까. 채용 공고를 봤다. "문제 해결 능력", "데이터 기반 의사결정". 추상적이다. 당근마켓은? 블로그를 읽었다. "유저 임팩트 중심". 구체적이지 않다. 해외 사례도 찾았다. Google은 Peer Review. 동료 평가. Amazon은 Narrative. 스토리텔링. Facebook은 Impact. 근데 정의가 모호. 큰 회사도 고민한다는 걸 알았다. 위안이 됐다. 근데 해결책은 없었다. 링크드인에서 외국 PM에게 DM을 보냈다. "How do you measure your performance?" 답장이 왔다. "Honestly? It's still a struggle. We try to connect features to business metrics, but there's always gray area." 그레이 에리어. 맞는 말이다. 현실은 정치다 결국 깨달았다. 기획자 평가는 숫자가 아니다. 관계다. 대표님이 좋아하는 프로젝트를 했나. 팀장님이 인정하는 결과를 냈나. 개발팀이 "K님과 일하고 싶다"고 말하나. 스톡옵션 추가 부여 명단이 나왔다. 개발자 3명, 디자이너 1명, 마케터 1명. 기획자는 없었다. 인사팀에 물었다. "기획자는 왜 없나요?" "아, 기획 직군은 정량 평가가 어려워서요. 내년에는 기준을 만들어볼게요." 내년에도 똑같을 거다. 동기 개발자는 이번에 200주를 더 받았다. 축하한다고 말했다. 진심이었다. 부럽진 않았다. 그냥 다른 거다. 그는 코드를 쓴다. 나는 문서를 쓴다. 그는 빌드한다. 나는 조율한다. 그는 측정된다. 나는 해석된다. 공평하지 않다. 근데 어쩔 수 없다. 그래도 일은 한다 다음 분기 기획을 시작했다. 신규 기능 2개, 개선 작업 5개. 데이터 대시보드도 만들 거다. 내 기여도를 추적하려고. GA4를 배우고 있다. SQL 강의도 듣는다. A/B 테스트 설계 책도 샀다. 스톡옵션이 의미 없다는 건 아니다. 회사가 잘되면 나도 좋다. 다만 기대는 안 한다. 현금으로 연봉을 올리는 게 낫다. 다음 이직 때는 스톡옵션 비중을 줄이고 베이스를 올릴 거다. 기획자의 스톡옵션. 로또 같은 거다. 당첨되면 좋고, 아니면 말고. 커피 마셨다 오후 3시. 카페인 네 번째. 내일 스프린트 플래닝이다. 백로그를 정리한다. 개발자가 물어볼 거다. "이 기능, 왜 만들어야 하죠?" 나는 대답할 거다. "데이터를 보면요, 이 플로우에서 이탈이 30%입니다. 경쟁사는 이렇게 해결했고요, 우리는 이렇게 차별화할 수 있습니다." 설득한다. 조율한다. 문서화한다. 측정은 안 되지만 필요한 일이다. 스톡옵션이 늘든 안 늘든. 이 일은 계속한다. 퇴근 시간이다. 지라 티켓 3개가 남았다. 내일 하자.성과는 숫자로 말하는데, 내 일은 숫자가 안 나온다. 그게 기획자다.
- 15 Dec, 2025
긴급 버그 vs 기획 이슈, 우선순위를 정하는 기준
긴급 버그 vs 기획 이슈, 우선순위를 정하는 기준 목요일 오후 3시, 슬랙 폭탄 목요일이다. 릴리즈 전날. 슬랙 알림이 17개. "회원가입 버튼이 안 눌려요 (iOS 14)" "메인 배너 이미지 깨져요" "근데 프로필 수정 기능은 언제 들어가요?"한숨. 개발팀장이 전화했다. "K님, 뭐부터 할까요?" 이게 매주 반복된다. 릴리즈 주간마다. 3개월 전의 나 예전엔 소리 큰 사람 먼저 처리했다. 대표님이 언급하면 → 최우선 개발팀이 짜증내면 → 미뤄짐 디자이너가 조용하면 → 잊혀짐 결과? 릴리즈는 계속 미뤄지고. 팀은 지치고. 내 신뢰도는 바닥. 스프린트 회고에서 개발자가 말했다. "우선순위 기준이 뭔가요?" 대답 못 했다. 기준이 없으면 매번 싸운다기준 없이 판단하면. 매번 설명해야 한다. "왜 내 이슈는 안 해요?" "이거 급한데요?" "지난주엔 이런 거 바로 했잖아요" 에너지 소진. 시간 낭비. 팀 사기 저하. 그래서 만들었다. 우선순위 매트릭스. 내가 쓰는 4단계 기준 1단계: 영향도 확인 질문 3개몇 명한테 영향? 핵심 기능인가? 비즈니스 임팩트?회원가입 버튼 안 눌림 → 전체 유저, 핵심 기능, 매출 직결 프로필 이미지 안 보임 → 일부 유저, 부가 기능, 매출 무관 숫자로 본다. 감이 아니라. 예시결제 버그: 전체 유저(100%) + 핵심 + 매출 직결 → Critical 설정 화면 오타: 소수 유저(5%) + 부가 + 매출 무관 → Low2단계: 시급성 판단 3가지 기준지금 안 하면 릴리즈 불가? 회사 평판 리스크? 법적/보안 이슈?하나라도 Yes면 급함. 배너 이미지 깨짐 → 릴리즈 가능, 평판 영향 적음, 법적 무관 → 중간 개인정보 노출 버그 → 즉시 핫픽스 타임라인을 본다. "급하다"는 말만으론 부족. 3단계: 공수 산정 개발자한테 묻는다. "얼마나 걸려요?" 30분 이하 → 바로 반나절 → 스프린트 내 하루 이상 → 백로그 중요하지만 시간 오래 걸리면? 다음 스프린트. 작은 거 먼저 처리하면. 팀 사기도 오른다.실제 케이스iOS 버튼 버그: 영향도 高, 시급 高, 공수 2시간 → 당일 처리 프로필 수정: 영향도 中, 시급 低, 공수 3일 → 다음 스프린트 배너 이미지: 영향도 中, 시급 中, 공수 30분 → 당일 처리4단계: 기회비용 계산 이걸 하면 뭘 못 하나? A 버그 잡으면 → B 기능 개발 미뤄짐 B 개발하면 → C 테스트 시간 부족 트레이드오프. 항상 존재한다. 회의에서 말한다. "이거 하면 저건 다음 주입니다" 명확하게. 실전 적용: 지난주 목요일 상황릴리즈 D-1 긴급 이슈 5개 기획 요청 3개이슈 리스트[P0] 결제 실패율 급증 (20% → 35%) [P1] 검색 결과 정렬 오류 [P1] 푸시 알림 이미지 깨짐 [P2] 프로필 편집 느림 [P2] 메인 배너 오타 [기획] 소셜 로그인 추가 [기획] 위시리스트 기능 [기획] 알림 설정 세분화판단 과정 먼저 매트릭스 그렸다. 화이트보드에.영향도 시급성 공수 결정결제 버그 高 高 2시간검색 오류 中 中 4시간푸시 이미지 中 低 1시간프로필 느림 低 低 1일배너 오타 低 低 10분소셜 로그인 中 低 3일위시리스트 低 低 1주알림 설정 低 低 2일최종 결정목요일: 결제 버그 + 배너 오타 금요일 오전: 검색 오류 금요일 오후: 푸시 이미지 + 릴리즈 다음 주: 프로필 개선 2주 후: 소셜 로그인개발팀한테 공유했다. 이유와 함께. "결제가 안 되면 매출이 멈춥니다. 검색은 불편하지만 우회 가능합니다." 반발 없었다. 기준이 명확하니까. 팀과 공유하는 방법 혼자 판단하면 안 된다. 기준을 투명하게. 매주 월요일우선순위 매트릭스 리뷰 이번 주 Top 3 합의 백로그 정리이슈 발생 시슬랙에 즉시 기준 적용 "영향도 高, 시급 中, 공수 4시간 → 내일 처리" 반론 있으면 회의스프린트 회고잘한 판단 / 아쉬운 판단 기준 업데이트컨플루언스에 문서화했다. "우선순위 판단 가이드" 누가 물어도. 여기 보라고. 자주 하는 실수들 실수 1: 목소리 큰 사람 먼저 대표님 요청이라고. 무조건 최우선 아니다. 영향도 낮으면. 정중하게 설명한다. "네, 중요하지만 결제 버그가 먼저입니다. 내일 시작할게요." 근거 있으면. 받아들인다. 실수 2: 완벽주의 "모든 버그 다 잡고 릴리즈" 불가능. 영원히 못 낸다. Critical만 잡고. 나머지는 백로그. 완벽보다 실행. 실수 3: 기준 없이 '감'으로 "이거 급해 보이는데?" 숫자로 말한다. "전체 유저의 3%에게만 발생, P2입니다." 데이터 기반. 감정 배제. 실수 4: 개발자한테 판단 떠넘김 "어떻게 생각해요?" 내가 정해야 한다. PM/기획자니까. 개발자는 공수만. 우선순위는 내 일. 판단 못 할 때 그래도 애매할 때 있다. 해결법 3가지데이터 확인GA 보고 영향 받은 유저 수 CS 문의 건수 실패율 그래프이해관계자 회의15분 긴급 미팅 각자 입장 청취 다수결 or PM 결정MVP 사고최소한으로 해결 가능? 임시 방편 먼저 근본 해결은 나중완벽한 판단은 없다. 빠른 판단이 중요. 3개월 후 이제는. 이슈 터져도 덜 당황한다. 기준이 있으니까. 팀도 안다. 개발자가 먼저 말한다. "이거 P1인 것 같은데요?" 디자이너도. "이건 다음 스프린트 가능한가요?" 우선순위 언어. 팀 전체가 쓴다. 릴리즈 주간. 여전히 바쁘다. 하지만. 싸우진 않는다.기준 없으면 매번 싸운다. 기준 있으면 한 번만 설명한다.
- 14 Dec, 2025
이해관계자 미팅, 기획서 없이 가면 안 되는 이유
기획서 없이 간 미팅의 참사 작년 10월이었다. 마케팅팀 요청으로 잡힌 미팅. 이벤트 배너 위치 조정 건이었다. "간단한 거니까 구두로 설명하면 되겠지." 착각이었다. 회의실에 들어갔다. 마케팅팀 3명, CS팀 2명, PM 1명. 총 6명. 나는 맨손이었다. 노트북도 안 가져갔다. "배너를 메인에서 서브로 옮기려고요." 마케팅팀장이 물었다. "왜요?" "클릭률이 낮아서요." "얼마나 낮은데요?" "음... 한 0.3% 정도?" "그게 낮은 건가요?" 대답 못 했다. 벤치마크 데이터가 없었다. CS팀에서 또 물었다. "옮기면 문의 늘지 않나요?" "아니요, 괜찮을 거예요." "근거가?" 없었다. 30분 동안 질문만 받았다. 하나도 제대로 답 못 했다. 미팅 끝나고 PM이 말했다. "다음엔 자료 가져와." 얼굴이 화끈거렸다.기획서는 방패다 그 뒤로 자료 없이 미팅 간 적 없다. 기획서가 있으면 공격당하지 않는다. 정확히는 공격을 막을 수 있다. "왜 이렇게 기획했어요?" 기획서 3페이지 펼친다. "유저 리서치 결과 보시면, 73%가 현재 플로우에서 이탈했습니다." "개발 공수는요?" 기획서 5페이지. "백엔드 3일, 프론트 2일, QA 1일 예상입니다." "경쟁사는 어떻게 하는데요?" 기획서 7페이지. "토스, 카카오, 네이버 3사 비교표 첨부했습니다." 질문이 나올 때마다 기획서 넘긴다. 답이 다 있다. 미팅이 30분 만에 끝난다. 결정도 빠르다. 기획서는 방패이자 무기다. 지난달 경영진 보고 때였다. 신규 기능 기획안 발표. 대표님이 물었다. "이거 만들면 매출 오르나요?" 기획서 10페이지 띄웠다. "예상 전환율 개선 15%, 월 예상 매출 증가 2300만원입니다." "근거는?" "A/B 테스트 결과와 유사 케이스 벤치마킹입니다. 상세 계산식은 11페이지에 있습니다." 대표님이 고개 끄덕였다. "좋아요, 진행하세요." 5분 만에 승인났다. 자료 없었으면 한 시간 설득해도 안 될 일이었다.이해관계자는 말을 안 믿는다 마케팅팀, CS팀, 경영진. 모두 다르게 생각한다. 마케팅팀은 노출을 원한다. 배너 크게, 버튼 눈에 띄게. CS팀은 문의 감소를 원한다. UI 명확하게, 설명 자세하게. 경영진은 매출을 원한다. 전환율 높이고, 비용 줄이고. 기획자는 그 중간에 있다. 모두를 만족시킬 순 없다. 그래서 기획서가 필요하다. "이 기능은 마케팅 효율을 15% 높이지만, CS 문의는 5% 늘 수 있습니다. 하지만 FAQ 보강으로 대응 가능합니다." trade-off를 명시한다. 선택지를 준다. "A안은 개발 2주, 매출 효과 중. B안은 개발 1개월, 매출 효과 대. 어떤 걸 선택하시겠습니까?" 결정권자가 판단한다. 나는 정보를 제공한다. 기획서 없이 말로만 하면? "그냥 이게 좋을 것 같아요." 신뢰 제로다. 지난주 CS팀 미팅. 환불 프로세스 개선 건. CS팀장이 말했다. "환불 버튼 더 숨겨주세요. 악용 사례가 많아요." 나는 기획서를 펼쳤다. "환불 클릭 중 실제 악용은 3%입니다. 97%는 정당한 사유입니다. 버튼 숨기면 정상 유저 불편도가 40% 상승합니다." 데이터를 보여줬다. CS팀장이 인정했다. "그럼 악용 방지는 어떻게 하죠?" "2단계 인증과 사유 작성 필수로 가겠습니다. 예상 악용 감소율 60%입니다." 기획서 다음 페이지에 있었다. CS팀장이 동의했다. 데이터를 믿었다. 말은 안 믿는다. 숫자는 믿는다. 기획서에 들어갈 것들 매번 같은 구조로 작성한다. 이해관계자가 예측 가능하게. 1. 배경 (Background) 왜 이 기획을 하는가. 한 문장으로. "현재 결제 이탈률 38%, 업계 평균 22% 대비 16%p 높음." 문제를 정의한다. 숫자로. 2. 목표 (Goal) 무엇을 달성할 것인가. 측정 가능하게. "결제 이탈률 38% → 25% 감소. 예상 매출 증가 월 4500만원." 목표가 애매하면 미팅이 산으로 간다. 3. 현황 분석 (AS-IS) 지금 어떤 문제가 있는가. 유저 플로우, 스크린샷, 데이터. "현재 결제 페이지 로딩 4.2초. 이탈 지점 76%가 로딩 중." 문제를 시각화한다. 4. 개선안 (TO-BE) 어떻게 바꿀 것인가. 와이어프레임, 플로우 차트. "로딩 1.5초로 단축. 진행 상태 표시 추가. 간편결제 우선 노출." before-after 비교. 한눈에 보이게. 5. 예상 효과 (Expected Impact) 바꾸면 뭐가 좋아지나. 정량적, 정성적. "예상 이탈률 13%p 감소. 월 결제 건수 2200건 증가. 유저 만족도 상승." 숫자가 있으면 설득력 100배. 6. 일정 및 리소스 (Timeline & Resources) 언제, 누가, 얼마나 걸리나. "백엔드 5일, 프론트 3일, 디자인 2일, QA 2일. 총 12일. 개발자 김OO, 디자이너 이OO 투입." 일정 없으면 '언제 돼요?' 질문 폭탄. 7. 리스크 및 대응 (Risk & Mitigation) 뭐가 잘못될 수 있나. 어떻게 대응하나. "외부 결제 모듈 지연 가능성. → 대체 모듈 사전 검토 완료." 리스크 언급 안 하면 나중에 책임진다. 이 구조로 작성하면 30분 미팅이 10분이 된다.구두 설명이 위험한 이유 작년에 마케팅팀이랑 일했다. 신규 이벤트 페이지 기획. 미팅에서 구두로 합의했다. "메인 배너 넣고, 타이머 달고, 공유 버튼 추가하죠." 다들 고개 끄덕였다. 회의록도 썼다. 2주 뒤 개발 완료. 마케팅팀한테 공유했다. "어? 이거 아닌데요." "네? 미팅에서 합의한 거잖아요." "타이머는 상단에 달라고 했는데, 이건 하단이잖아요." 회의록 다시 봤다. "타이머 추가"라고만 써있었다. 위치는 없었다. "그리고 공유 버튼은 이미지도 같이 공유되게 해달라고 했는데요." 그런 얘기 없었다. 아니, 있었나? 기억 안 났다. 결국 재작업. 개발자 3일 추가 투입. 개발자가 나한테 말했다. "다음엔 기획서에 다 적어줘." 내 잘못이었다. 구두 설명은 휘발된다. 사람마다 이해도 다르게 한다. "버튼을 크게 만들어주세요." 마케팅팀 생각: 화면의 30% 차지하는 버튼. 내 생각: 기존 버튼의 1.5배. 개발자 생각: 폰트 사이즈만 키우면 되나? 같은 말을 다르게 이해한다. 기획서에 적으면? "버튼 크기: 가로 280px, 세로 56px. 패딩 16px. 폰트 18px Bold." 오해할 여지가 없다. 지금은 모든 미팅에 기획서를 가져간다. 회의 중에도 바로 수정한다. "아, 타이머 위치는 상단이 맞죠? 지금 기획서에 반영할게요." 화면 공유하고 실시간으로 고친다. 다같이 확인한다. "네, 이거 맞습니다." 미팅 끝나면 기획서 링크 공유. Notion 또는 Confluence. "오늘 합의한 내용입니다. 내일까지 최종 검토 부탁드립니다." 24시간 안에 이의 제기 없으면 확정. 그 뒤론 "그런 거 아니라고 했는데요" 없다. 이해관계자별 맞춤 전략 같은 기획서를 모두에게 보여주지 않는다. 버전을 나눈다. 경영진용1페이지 요약본. Executive Summary. 목표, 예상 효과, 일정, 비용. 세부 기획은 부록. 대표님은 디테일 안 본다. 결론만 본다.지난달 신규 기능 보고. 1페이지: "예상 MAU 15% 증가, 월 매출 3200만원 증가, 개발 기간 6주." 대표님 반응: "좋아요, 진행하세요." 30초 만에 승인. 마케팅팀용유저 플로우 중심. 어떻게 유입되고, 어디서 전환되나. 경쟁사 사례. 측정 지표: CTR, CVR, ROAS.지난주 이벤트 페이지 기획. 마케팅팀한테는 유저 여정 5단계로 설명. "랜딩 → 관심 유도 → 참여 → 공유 → 전환." 각 단계별 예상 전환율 명시. 마케팅팀 만족. "이해 쉽네요." CS팀용유저 불편 포인트 해결 중심. FAQ 변경사항. 예상 문의 증감. 대응 가이드.환불 프로세스 개선 때. CS팀한테는 문의 시나리오 10개 작성해서 공유. "이런 경우엔 이렇게 답변하시면 됩니다." CS팀장: "이거면 충분하겠네요." 개발팀용기능 명세 상세. API 스펙, 데이터 구조, 예외 처리. 와이어프레임, 인터랙션 정의. 개발 우선순위.개발자한테는 테크 스펙 문서 별도. "이 필드는 필수, 저 필드는 선택. 에러 코드는 400, 401, 403..." 개발자: "이 정도면 작업 가능." 같은 내용, 다른 포커스. 이해관계자가 원하는 걸 준다. 기획서 작성 시간은 투자다 기획서 한 건 쓰는 데 보통 하루 걸린다. 8시간. 적지 않다. "기획서 쓸 시간에 개발자랑 얘기하는 게 빠르지 않아요?" 신입 기획자가 물었다. "아니." 기획서 8시간 쓰면, 미팅 시간 20시간 줄어든다.이해관계자 설득 미팅: 2시간 → 30분 개발 커뮤니케이션: 3시간 → 1시간 수정 요청 대응: 5회 → 1회 재작업: 3일 → 0일기획서 없으면 모든 게 늘어난다. 일정, 비용, 스트레스. 지난해 프로젝트 복기했다. 기획서 있던 프로젝트: 평균 일정 준수율 87%. 기획서 없던 프로젝트: 평균 일정 준수율 43%. 2배 차이. 기획서는 시간 낭비가 아니다. 시간 절약이다. 요즘은 템플릿을 만들어뒀다. Notion에 12개.신규 기능 기획서 템플릿 개선 기획서 템플릿 A/B 테스트 기획서 템플릿 이해관계자 보고서 템플릿복붙하고 내용만 채운다. 2시간 안에 초안 완성. 효율이 오른다. 구두 합의는 합의가 아니다 법적으로도 문서가 우선이다. "미팅에서 그렇게 하기로 했잖아요." "회의록에 없는데요?" 끝이다. 회사에서도 마찬가지다. 구두 합의는 합의가 아니다. 기록된 합의만 합의다. 작년에 프로젝트 하나 엎어질 뻔했다. 마케팅팀이랑 합의한 기능. 구두로만. 개발 80% 진행됐을 때 마케팅팀장이 바뀌었다. 새 팀장: "이거 왜 만들어요?" "전임 팀장님이랑 합의했습니다." "문서 있어요?" 없었다. "그럼 필요 없는 거 아니에요? 중단하죠." 3주치 개발이 날아갈 뻔했다. 다행히 슬랙 대화 기록이 있었다. 그걸 증거로 제시했다. "합의 내용입니다." 겨우 프로젝트 살렸다. 그 뒤론 모든 합의를 문서화한다. 미팅 끝나면 바로 회의록 공유. "오늘 합의 사항입니다. 48시간 내 이의 없으면 확정으로 간주합니다." 이의 제기 없으면 스크린샷 찍어서 보관. 나를 지키는 무기다. 기획서는 커뮤니케이션 비용을 줄인다 개발자가 10명이면, 10명한테 다 설명해야 한다. 1명당 30분. 총 5시간. 다음 날 또 물어본다. "그거 어떻게 하기로 했죠?" 다시 설명. 또 5시간. 기획서 하나 쓰면? "여기 보세요." 링크 하나. 10초. 질문 오면 문서 섹션 링크. "4번 항목 보시면 됩니다." 설명 반복 제로. 지난달 신규 기능 개발. 백엔드 3명, 프론트 2명, 앱 2명. 총 7명. 기획서 공유하고 질문 받았다. 슬랙에 7개 질문 왔다. 모두 기획서에 답 있었다. "3페이지 두 번째 단락 보시면 됩니다." 링크만 7번 보냈다. 커뮤니케이션 시간 90% 감소. 기획서는 자동응답 봇이다. 나를 지키는 기획서 기획은 모호하다. 정답이 없다. "이게 최선인가요?" "더 나은 방법은 없나요?" 항상 의심받는다. 기획서는 내 결정을 정당화한다. "왜 이렇게 기획했어요?" 기획서를 펼친다. "유저 리서치 32명, 경쟁사 분석 5개사, A/B 테스트 결과 반영했습니다." 프로세스를 보여준다. "감으로 한 거 아니에요?" "데이터 기반입니다. 8페이지 참고하세요." 감이 아님을 증명한다. 지난주 경영진 미팅. CFO가 물었다. "이 기능 꼭 필요한가요? 비용이 만만치 않은데." 기획서 12페이지 띄웠다. "없으면 월 예상 손실 5200만원입니다. ROI 계산식은 여기 있습니다." CFO가 계산기 두드렸다. 10초 뒤 고개 끄덕였다. "알겠습니다." 기획서가 나를 지켰다. 기획서 없었으면? "그냥 필요할 것 같아서요." 신뢰 제로. 승인 제로. 기획자는 증명해야 하는 직업이다. 기획서는 증명서다.기획서는 선택이 아니다. 생존이다. 다음 미팅엔 꼭 가져가라.
- 08 Dec, 2025
슬랙 폭탄의 아침, 어떻게 대응할 것인가
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배 올랐다. 스트레스 감소 "답 안 했다고 뭐라 하면 어쩌지" 걱정했는데 아무 일 없었다. 정말 급하면 전화 온다. 전화 안 오면 안 급한 거다. 관계 개선 답장 늦어도 이유를 말하니까 이해한다. "스펙 정리 중이라 오후에 드릴게요" 이렇게 말하면 기다린다. 무작정 답 안 하는 것과 다르다. 마무리 슬랙은 폭탄이다. 매일 터진다. 해체하는 법을 배워야 한다. 급한 선 하나 긋고. 중요한 선 하나 긋고. 그 안에 있는 것만 처리한다. 나머지는 내일.슬랙 끄고 일하는 시간. 그게 진짜 일하는 시간이다.
- 03 Dec, 2025
스펙이 명확하지 않습니다 - 개발팀의 신호를 읽는 법
스펙이 명확하지 않습니다 - 개발팀의 신호를 읽는 법 신호는 이미 왔었다 화요일 오후 3시. 슬랙 알림. "K님, 이 부분 스펙이 명확하지 않은데요?" 심장이 내려앉는다. 어제 밤 11시까지 작성한 PRD였다. 3번 검토했다고 생각했는데. 돌아보니 신호는 있었다. 월요일 스프린트 회의 때 백엔드 개발자 J님이 물었다. "이 케이스는 어떻게 처리하나요?" 나는 대답했다. "그건... 일단 논의해볼게요." 그게 신호였다. 명확하지 않다는 신호. 개발자는 직접적으로 말하지 않는다. "이건 불가능합니다" 전에 "이 부분 좀 애매한데요" 가 먼저 온다. "스펙이 명확하지 않습니다" 는 이미 3번째 신호다. 6년 차에 깨달은 것. 개발자의 질문은 단순한 질문이 아니다. PRD의 구멍을 발견했다는 신호다.모호한 표현의 전형 내 PRD에서 가장 많이 쓴 표현들. 하나씩 지워나가는 중이다. "적절하게" 뭐가 적절한가. 5개? 10개? 1000개? 개발자는 숫자로 말한다. "필요시" 언제가 필요한 때인가. 조건이 없으면 코드를 쓸 수 없다. if문에는 boolean이 필요하다. "사용자가 원하는" 어떤 사용자? 무엇을 원하는지 어떻게 판단? 데이터는? "적당히" 이게 제일 위험하다. 개발자의 적당함과 기획자의 적당함은 다르다. 100% 다르다. 지난주 기획서. "리스트는 적당한 개수로 표시" 개발자는 20개로 구현했다. 나는 5개를 생각했다. 다시 작성했다. "리스트는 최대 5개 표시. 5개 초과 시 '더보기' 버튼 노출. 더보기 클릭 시 10개 단위 추가 로딩." 구체적 숫자. 조건. 예외 케이스. 이게 명확함이다.체크리스트를 만들었다 PRD 작성 후 이 항목들을 체크한다. 하나라도 빠지면 슬랙 폭탄 확정이다. 1. 숫자가 있는가최대/최소 값 타임아웃 리스트 개수 페이지네이션 단위 캐시 시간 파일 용량 제한숫자 없으면 개발자가 정한다. 그리고 그건 내가 원한 숫자가 아니다. 2. 모든 케이스를 적었는가정상 케이스 에러 케이스 엣지 케이스 네트워크 끊김 데이터 없음 권한 없음 동시 접속에러 케이스를 안 쓰면 개발자가 "에러 발생" 토스트만 띄운다. 사용자는 뭐가 문제인지 모른다. 3. 우선순위가 명확한가Must have Should have Nice to have전부 중요하다고 하면 전부 중요하지 않은 것이다. 개발 기간 2주인데 요구사항 30개. 불가능하다. 우선순위 없으면 개발자가 정한다. 쉬운 것부터. 중요한 게 아니라. 4. 판단 기준이 있는가"최신순"이면 → 어떤 날짜 기준? "인기순"이면 → 어떤 지표? "추천"이면 → 무슨 알고리즘?기준 없으면 개발자가 정한다. 그리고 PM은 나다. 내가 정해야 한다.진짜 문제는 화면 밖에 있다 가장 많이 놓치는 부분. 화면에 보이지 않는 것들. 상태 관리. A 화면에서 데이터 수정하면 B 화면에도 반영되나? 새로고침 해야 하나? 자동으로 되나? 안 적으면 개발자는 가장 쉬운 방법을 선택한다. 새로고침. 지난달 릴리즈. 프로필 수정 기능 추가했다. PRD에는 프로필 수정 화면만 있었다. QA 단계에서 발견했다. 프로필 수정 후 메인 화면 가면 이전 프로필 정보 그대로다. 앱 재시작해야 반영된다. 다시 개발 2일. 릴리즈 하루 연기. 이제는 적는다. "프로필 수정 완료 시, 해당 데이터를 사용하는 모든 화면에 실시간 반영. 메인 화면, 설정 화면, 마이페이지 포함." 데이터 플로우. API 호출 시점. 캐시 정책. 화면 전환 시 동작. 보이지 않는 것도 스펙이다. 개발자의 질문 패턴 6년간 받은 질문들을 정리했다. 패턴이 있다. "이 케이스는요?" → PRD에 해당 케이스 없음 → 내일까지 추가 스펙 정리 필요 "이게 가능한가요?" → 기술적으로 어려움 → 대안 논의 필요 "왜 이렇게 하나요?" → 더 좋은 방법 있다는 신호 → 이유 설명 or 방법 수정 "급한가요?" → 다른 급한 일 있음 → 우선순위 재조정 필요 "디자이너분과 얘기했나요?" → 디자인-개발 간 괴리 있음 → 3자 회의 필요 질문을 무시하지 않는다. 모든 질문은 리스크 신호다. 금요일 오후 3시 이후의 질문. 이건 월요일 이슈로 번진다. 바로 응답한다. 구체성의 기준 "어느 정도로 구체적이어야 하나요?" 신입 기획자가 물었다. 대답했다. "개발자가 당신 자리에 안 와야 할 정도로." PRD만 보고 개발 가능하면 됐다. 슬랙으로 질문 안 하면 됐다. 회의 안 잡으면 됐다. 물론 불가능하다. 100% 명확한 PRD는 없다. 하지만 90%는 가능하다. 질문 10개를 3개로 줄일 수 있다. 구체성의 기준. 다른 사람이 읽고 같은 그림을 그릴 수 있는가. 테스트 방법이 있다. PRD를 다른 기획자에게 보여준다. 설명 없이. 그림 그려보라고 한다. 내가 생각한 것과 다르면 그건 명확하지 않은 것이다. 요즘은 ChatGPT에게 물어본다. "이 스펙으로 개발하면 어떤 질문이 나올까?" 의외로 정확하다. 내가 놓친 케이스를 찾아낸다. 스프린트 첫날의 루틴 월요일 아침 10시. 스프린트 시작. 예전에는 티켓만 할당하고 끝났다. 지금은 다르다. 티켓 하나씩 읽는다. 개발자들 앞에서. "이해 안 되는 부분 있으면 바로 말해주세요." 5분이면 나온다. 애매한 부분. 놓친 케이스. 기술적 제약. 그 자리에서 정리한다. 티켓 수정한다. 디자이너 부른다. 3자 회의 즉석에서 한다. 이렇게 하니 중간 질문이 70% 줄었다. 일정 변경이 50% 줄었다. 시간 투자다. 스프린트 첫날 1시간. 나중에 3시간 아낀다. 목요일에 "이거 어떻게 하나요?" 듣는 것보다 월요일에 1시간 쓰는 게 낫다. 결국 학습이다 명확한 스펙 작성은 기술이다. 타고나는 게 아니다. 나도 1년 차 때는 엉망이었다. "대충 이런 느낌으로" "예쁘게" "사용자 친화적으로" 개발자들이 매일 물었다. 뭐가 예쁜 건지. 어떤 게 친화적인 건지. 3년 차에 깨달았다. 내 머릿속 이미지를 다른 사람은 모른다. 말로 옮겨야 한다. 구체적으로. 지금도 배운다. 매 스프린트마다. 회고 때 물어본다. "어떤 스펙이 애매했나요?" "어떻게 쓰면 더 좋았을까요?" 개발자들이 알려준다. 그들이 진짜 선생님이다. 최근에 배운 것. "버튼 비활성화 조건" 항상 놓친다. 이제는 모든 버튼마다 적는다.활성화 조건 비활성화 조건 비활성화 시 색상 비활성화 시 토스트 메시지작은 것 같지만 이런 게 쌓인다.스펙이 명확하지 않다는 말. 이제는 듣기 전에 먼저 찾아낸다. 그게 성장이다.