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

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

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

스펙이 명확하지 않습니다 - 개발팀의 신호를 읽는 법

스펙이 명확하지 않습니다 - 개발팀의 신호를 읽는 법

스펙이 명확하지 않습니다 - 개발팀의 신호를 읽는 법 신호는 이미 왔었다 화요일 오후 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년 차에 깨달았다. 내 머릿속 이미지를 다른 사람은 모른다. 말로 옮겨야 한다. 구체적으로. 지금도 배운다. 매 스프린트마다. 회고 때 물어본다. "어떤 스펙이 애매했나요?" "어떻게 쓰면 더 좋았을까요?" 개발자들이 알려준다. 그들이 진짜 선생님이다. 최근에 배운 것. "버튼 비활성화 조건" 항상 놓친다. 이제는 모든 버튼마다 적는다.활성화 조건 비활성화 조건 비활성화 시 색상 비활성화 시 토스트 메시지작은 것 같지만 이런 게 쌓인다.스펙이 명확하지 않다는 말. 이제는 듣기 전에 먼저 찾아낸다. 그게 성장이다.

릴리즈 전야의 야근, 피할 수 없다면 준비하자

릴리즈 전야의 야근, 피할 수 없다면 준비하자

릴리즈 전야의 야근, 피할 수 없다면 준비하자 수요일 밤 11시, 슬랙이 울렸다 집에 도착한 지 20분. 샤워하고 치킨 시켰다. 슬랭 알림이 울렸다. "K님, 결제 모듈에서 이상한 버그 발견했어요." 금요일 오전 10시 릴리즈다. 내일 목요일은 QA 최종 점검 날이다. 오늘 안 잡으면 릴리즈 미룬다. 치킨은 식었다. 노트북 켰다. 예상 못한 버그는 항상 릴리즈 전에 온다.우선순위부터 판단한다 패닉하면 진다. 지라 티켓부터 만들었다. 우선 버그 정도를 확인한다.Critical: 서비스 불가능. 결제 안 됨. 회원가입 막힘. High: 주요 기능 오작동. 데이터 꼬임. 보안 이슈. Medium: 불편하지만 우회 가능. UI 깨짐. 로딩 느림. Low: 있으면 좋지만 없어도 됨. 오타. 디자인 미세 틀어짐.이번 건은 High였다. 특정 카드사에서 결제 실패. 재현율 30%. 금액이 10만원 넘으면 발생. Critical은 아니다. 다른 카드 쓰면 된다. 하지만 High는 맞다. 고객 불편 크다. 릴리즈 연기 vs 핫픽스 판단 금요일 릴리즈를 미루면?마케팅팀이 준비한 캠페인 날아감. 2주 스프린트 일정 전체 밀림. 다른 팀 일정까지 영향.핫픽스로 가면?내일 QA 시간 부족. 또 다른 버그 나올 위험. 개발자 야근 확정.30초 고민했다. CTO한테 슬랙 날렸다. "오늘 밤에 잡고, 내일 오전 집중 QA 하는 게 어떨까요? 릴리즈는 금요일 오후 3시로 미루고요." 5분 뒤 답왔다. "ㄱㄱ" 결정 끝.이슈 트래킹 체크리스트 야근할 거면 효율적으로 한다. 지라 티켓에 템플릿이 있다. 1. 버그 재현 조건 명확히 개발자가 제일 싫어하는 말. "어? 아까는 됐는데요?" 재현 조건을 구체적으로 적었다.디바이스: iOS 15.6, Safari 계정: 테스트 계정 3개로 확인 카드사: A카드, B카드 (C카드는 정상) 금액: 100,000원 이상 재현율: 10번 중 3번영상도 찍었다. Loom으로 화면 녹화. 슬랙에 공유. 2. 로그 확인 센트리 들어갔다. 에러 로그 3건. 전부 같은 API. payment_gateway_error: card_validation_failed timestamp: 23:14:32 user_id: test_user_03 amount: 150000개발자한테 이거 캡처해서 보냈다. "이거랑 관련 있을 것 같아요." 3. 영향 범위 체크 이 버그가 다른 기능에도 영향 주는지 확인했다.일반 결제: 정상 정기 결제: 정상 환불: 정상 부분 취소: 미확인 (내일 체크)영향 범위가 좁다. 다행이다. 4. 우회 방안 준비 만약 금요일까지 못 잡으면? 고객센터 공지 준비했다. "현재 일부 카드사에서 10만원 이상 결제 시 오류가 발생할 수 있습니다. 다른 카드를 이용하시거나 고객센터로 연락 주시면 도와드리겠습니다." 최악의 시나리오도 준비. 항상 플랜 B는 있어야 한다.커뮤니케이션이 반이다 야근할 때 제일 중요한 거. 커뮤니케이션이다. 개발팀 리드한테 먼저 연락 PM이 아니라 개발 리드한테 먼저 물었다. "오늘 밤에 이거 잡을 수 있을까요? 솔직하게 말씀해주세요." "3시간 정도면 될 것 같은데, 확실하진 않아요." "그럼 자정까지 해보시고, 안 되면 내일 오전으로 미뤄도 돼요. 무리하지 마세요." 개발자를 믿는다는 신호를 줬다. 압박하면 역효과다. 이해관계자 정리 슬랙 채널에 상황 공유했다. [긴급] 릴리즈 일정 변경 안내- 버그 발견: 결제 모듈 (High 우선순위) - 조치: 오늘 밤~내일 오전 수정 - QA: 내일 오전 집중 진행 - 릴리즈: 금요일 10시 → 15시로 변경 - 영향: 마케팅 캠페인 시간 조정 필요죄송합니다. 내일 아침 9시에 상황 업데이트 드리겠습니다.마케팅팀에서 답왔다. "오케이, 캠페인 3시 이후로 조정할게요." 디자이너는 이모지만 달았다. 👍 상황을 투명하게 공유하면 다들 이해한다. 숨기려고 하면 불신만 쌓인다. 진행 상황 주기적 업데이트 자정에 개발자한테 물었다. "어떻게 되고 있어요?" "70% 정도 왔어요. 1시간 더 하면 될 것 같아요." 1시에 또 물었다. "거의 다 왔어요. 로컬에서는 재현 안 되네요. 스테이징에 배포해볼게요." 1시 반에 슬랙 왔다. "배포 완료. 테스트 부탁드려요." 테스트 10번 돌렸다. 전부 정상. "완벽해요. 고생하셨습니다." 개발자는 이미 퇴근했다. 나도 노트북 덮었다. 새벽 2시. 치킨은 차가웠지만 기분은 좋았다. 야근 이후 할 일 다음 날 목요일. 9시에 출근했다. 회고 미팅 30분 개발팀이랑 간단히 회고했다. "왜 이 버그가 늦게 발견됐을까?"테스트 케이스에 10만원 이상 시나리오 없었음. 특정 카드사 테스트 계정 부족."다음엔 어떻게 하면 좋을까?"경계값 테스트 케이스 추가. 카드사별 테스트 계정 확보. 결제 모듈은 스테이징 배포 후 1일 대기 후 릴리즈.비난하지 않았다. 프로세스를 개선하는 데 집중했다. 지라 티켓 정리 버그 티켓을 닫기 전에 문서화했다.버그 내용 재현 조건 원인 분석 (개발자가 작성) 해결 방법 재발 방지책다음에 비슷한 일 생기면 참고한다. 지라는 우리 팀의 기억이다. 팀에게 감사 표현 슬랙에 메시지 남겼다. "어제 밤 고생하신 민수님, 정말 감사합니다. 덕분에 일정 지킬 수 있었어요. 점심 제가 쏠게요." 작은 것 같지만 중요하다. 야근은 당연한 게 아니다. 그리고 팀 전체에도. "모두 빠른 대응 감사합니다. 금요일 릴리즈 무사히 하고 회식 가시죠." 분위기가 풀렸다. 야근을 줄이는 방법 사실 야근은 안 하는 게 최선이다. 매번 야근하면 번아웃 온다. 릴리즈 일정에 버퍼 둔다 나는 이제 릴리즈 2일 전에 개발 완료를 잡는다.월요일~수요일: 개발 목요일: QA 금요일: 버퍼 + 최종 체크 다음 주 월요일: 릴리즈금요일에 버그 나와도 여유 있다. 중요한 기능은 스테이징 먼저 결제, 인증, 데이터 마이그레이션. 이런 건 스테이징에 먼저 배포한다. 2-3일 돌려보고 프로덕션 간다. 급하다고 바로 배포하면 야근한다. 테스트 시나리오 꼼꼼히 QA팀 없는 회사도 많다. 우리도 그렇다. 그래서 테스트 시나리오를 개발 시작 전에 만든다.Happy path: 정상 케이스 Sad path: 에러 케이스 Edge case: 경계값, 극단적 상황이거 안 하면 릴리즈 전날 버그 나온다. 개발자랑 사전 소통 "이거 언제까지 돼요?"가 아니라 "이 기능 개발하는 데 리스크 요인이 뭘까요?" 개발자가 불안해하는 부분을 미리 안다. 거기에 시간을 더 쓴다. 의외로 대화가 답이다. 결국 준비의 문제 릴리즈 전야 야근. 완전히 막을 순 없다. 소프트웨어는 항상 예측 불가능하다. 하지만 준비하면 덜 황당하다.우선순위 판단 기준 정해두기 이슈 트래킹 템플릿 만들기 커뮤니케이션 루트 정리하기 버퍼 포함한 일정 계획이것만 해도 야근이 반으로 준다. 그리고 야근했으면 회고한다. 같은 실수 두 번 하지 않는다.금요일 오후 3시. 릴리즈 완료. 모니터링 2시간 했다. 별일 없다. 이제 맥주 마실 시간이다.