- 09 Dec, 2025
디자이너와 개발자 사이의 기획자, 중재자가 되는 법
오늘도 통역 중 오전 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개. 내일도 통역 중이다. 피곤하지만 할 만하다.
- 09 Dec, 2025
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 파일이 예쁜 게 중요한 게 아니다. 개발자가 이해할 수 있게 정리하는 게 중요하다.스펙 명확하면 개발 빠르다. 질문 줄어든다. 결과물 예측 가능하다. 그게 좋은 기획이다.
- 09 Dec, 2025
데이터로 증명하라 - 기획자가 SQL을 배워야 하는 이유
데이터로 증명하라 - 기획자가 SQL을 배워야 하는 이유 오늘도 데이터팀에 요청했다 "이 기능 사용자 몇 명이에요?" 개발자가 물었다. 나는 대답을 못 했다. 예상은 있다. 많지 않을 것 같다. 근데 숫자는 모른다. "데이터팀에 요청했어요." 개발자는 한숨을 쉬었다. 3일 걸린다는 걸 안다. 그 사이에 우선순위는 또 바뀐다.이게 3번째다. 이번 주에만. 매번 데이터팀 눈치를 본다. "저기... 혹시 이것도 가능할까요?" 하면서. 데이터팀도 바쁘다. 나만 바쁜 게 아니다. 그들은 대시보드 만들고, 경영진 보고서 쓰고, 데이터 파이프라인 관리한다. 내 요청은 우선순위에서 밀린다. 당연하다. 근데 문제는 그 사이에 일정이 간다는 거다. 직관은 있는데 증명이 안 된다 대표님이 물었다. "이 기능 왜 넣어야 해요?" 나는 설명했다. 유저 플로우를 그렸다. 경쟁사 사례를 보여줬다. 사용자 인터뷰 내용도 공유했다. "좋아요. 근데 데이터는요?" 말문이 막혔다. 직관적으로는 확신이 있다. 6년 동안 쌓인 감각이 있다. 이건 필요한 기능이다. 유저들이 원한다. 근데 숫자가 없다. "한 30%는 쓸 것 같은데요." "같은데요가 아니라 데이터로 보여주세요." 회의는 다음 주로 미뤄졌다. 데이터팀에 또 요청했다.집에 오면서 생각했다. 언제까지 이럴 건가. 내 직감을 증명할 방법이 필요하다. 스스로. SQL을 배우기로 했다 주말이다. 노션에 '공부' 페이지를 만들었다. "SQL 기초부터." 검색했다. 자료는 넘친다. 유튜브, 인프런, 유데미, 블로그. 문제는 뭐부터 봐야 하는지 모른다는 거다. 데이터 분석가가 되려는 게 아니다. 나는 기획자다. 필요한 건 복잡한 분석이 아니다.이 기능 사용자 몇 명? 이탈률 얼마? 어느 시간대에 많이 써? A/B 테스트 결과는?이 정도만 뽑을 수 있으면 된다.첫 주는 개념만 봤다. SELECT, FROM, WHERE. 테이블이 뭔지. 데이터베이스가 뭔지. 하나씩 따라 쳤다. Notion에 정리했다. SELECT user_id, created_at FROM users WHERE created_at > '2024-01-01'이게 돌아갔다. 짜릿했다. 개발자한테 부탁했다 "혹시 테스트 DB 접근 권한 받을 수 있을까요?" 개발자가 의외라는 표정을 지었다. "SQL 배우려고요?" "네. 매번 데이터팀 귀찮게 하기 싫어서요." 5분 만에 권한이 생겼다. DBeaver를 설치했다. 테이블 목록을 봤다. users, orders, payments, logs... 어지러웠다. 이게 뭐고 저게 뭔지. "이 테이블에 뭐가 들어있어요?" 개발자가 옆에 앉았다. 30분 동안 설명해줬다.users: 회원 정보 user_actions: 유저 행동 로그 feature_usage: 기능 사용 기록"여기서 대부분 뽑을 수 있을 거예요." 감사했다. 진심으로. 첫 쿼리를 짰다 "이번 달 신규 가입자 수" 손이 떨렸다. 근데 써봤다. SELECT COUNT(*) as new_users FROM users WHERE created_at >= '2024-11-01' AND created_at < '2024-12-01'실행. 3초. 숫자가 나왔다. 1,247명. 이걸 이제 내가 직접 뽑는다. 다음 쿼리. "이 기능 사용자 수" SELECT COUNT(DISTINCT user_id) as active_users FROM feature_usage WHERE feature_name = 'wishlist' AND used_at >= '2024-11-01'832명. 전체 DAU 대비 18%. 이 숫자가 내 손으로 나왔다. Notion에 정리했다. 쿼리를 저장했다. 다음에 또 쓸 거다. 회의가 달라졌다 다음 주 회의. 대표님이 물었다. "이 기능 얼마나 써요?" 노트북을 열었다. 쿼리를 돌렸다. 20초. "지난주 기준 일평균 1,200회 사용됩니다. 전체 사용자의 22%가 최소 1회 이상 이용했고요." 회의실이 조용해졌다. "시간대별로는 오후 2시에서 4시 사이가 피크고, 모바일이 73%입니다." 대표님이 고개를 끄덕였다. "좋아요. 이 방향으로 가시죠." 회의는 30분 만에 끝났다. 결론이 났다. 전에는 3일 기다리고, 데이터 받아서, 다시 회의 잡고, 그랬다. 이제는 즉석에서 확인한다. 개발자가 나중에 슬랙을 보냈다. "기획자님 SQL 하시는 거 멋있어요. 소통이 빨라져서 좋네요." 저장했다. 이 칭찬. 내가 자주 쓰는 쿼리 5개 Notion에 템플릿을 만들었다. "자주 쓰는 쿼리 모음" 1. 기능별 사용자 수 SELECT feature_name, COUNT(DISTINCT user_id) as users, COUNT(*) as total_uses FROM feature_usage WHERE used_at >= '2024-11-01' GROUP BY feature_name ORDER BY users DESC우선순위 정할 때 쓴다. 어떤 기능을 먼저 개선할지. 2. 일자별 트렌드 SELECT DATE(created_at) as date, COUNT(*) as count FROM user_actions WHERE action_type = 'purchase' AND created_at >= '2024-11-01' GROUP BY DATE(created_at) ORDER BY date그래프 그릴 때 쓴다. 트렌드를 본다. 3. 유저 세그먼트별 비교 SELECT u.user_tier, COUNT(DISTINCT o.user_id) as purchasers, AVG(o.amount) as avg_amount FROM users u LEFT JOIN orders o ON u.user_id = o.user_id WHERE o.created_at >= '2024-11-01' GROUP BY u.user_tier페르소나별 차이를 본다. VIP는 어떻게 쓰나. 일반 유저는 어떤가. 4. 퍼널 분석 SELECT COUNT(DISTINCT CASE WHEN step = 'view' THEN user_id END) as views, COUNT(DISTINCT CASE WHEN step = 'click' THEN user_id END) as clicks, COUNT(DISTINCT CASE WHEN step = 'purchase' THEN user_id END) as purchases FROM user_funnel WHERE date >= '2024-11-01'어디서 이탈하나. 어느 단계를 개선해야 하나. 5. 코호트 리텐션 WITH first_action AS ( SELECT user_id, MIN(DATE(created_at)) as first_date FROM user_actions GROUP BY user_id ) SELECT fa.first_date, COUNT(DISTINCT fa.user_id) as cohort_size, COUNT(DISTINCT CASE WHEN DATE(ua.created_at) = fa.first_date + INTERVAL 7 DAY THEN ua.user_id END) as week_1_retained FROM first_action fa LEFT JOIN user_actions ua ON fa.user_id = ua.user_id GROUP BY fa.first_date이건 좀 복잡하다. 개발자가 도와줬다. 근데 이제 이해한다. 이 5개면 웬만한 건 커버된다. 나머지는 응용이다. 틀리는 것도 배움이다 처음엔 많이 틀렸다. SELECT COUNT(user_id) FROM users WHERE signup_date > '2024-11-01'이게 왜 안 되지? 10분을 고민했다. 칼럼명이 틀렸다. signup_date가 아니라 created_at이었다. SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING COUNT(*) > 5이건 왜 느리지? 3분이 걸렸다. 인덱스가 없었다. 개발자가 알려줬다. "WHERE 절에 자주 쓰는 컬럼은 인덱스가 있어야 빨라요." 배웠다. 메모했다. JOIN을 처음 썼을 때. SELECT u.name, o.amount FROM users u, orders o WHERE u.user_id = o.user_id결과가 이상했다. 중복이 너무 많다. LEFT JOIN을 써야 했다. INNER JOIN과 뭐가 다른지. 그때 알았다. 틀릴 때마다 검색했다. 스택오버플로우, 블로그, GPT. 그렇게 3개월이 지났다. 이제는 A/B 테스트도 직접 본다 마케터가 물었다. "A안이 나아요, B안이 나아요?" 전에는 데이터팀에 요청했다. 이제는 직접 본다. SELECT variant, COUNT(DISTINCT user_id) as users, COUNT(DISTINCT CASE WHEN converted = 1 THEN user_id END) as conversions, ROUND(100.0 * COUNT(DISTINCT CASE WHEN converted = 1 THEN user_id END) / COUNT(DISTINCT user_id), 2) as cvr FROM ab_test_results WHERE test_id = 'homepage_cta_test' GROUP BY variant결과가 나왔다.A안: CVR 3.2% B안: CVR 4.1%"B안이 27% 더 높네요." 마케터가 놀랐다. "어떻게 이렇게 빨리?" "SQL 좀 배웠어요." 30분이면 끝난다. 전에는 하루 이틀 걸렸다. 속도가 경쟁력이다. 빠르게 확인하고, 빠르게 결정하고, 빠르게 실행한다. SQL이 이걸 가능하게 했다. 여전히 데이터 분석가는 아니다 착각하면 안 된다. 나는 여전히 기획자다. 복잡한 통계 분석은 못 한다. 회귀분석, 머신러닝, 이런 건 데이터팀의 영역이다. 내가 하는 건 '기본 집계'다.COUNT: 몇 개 SUM: 합계 AVG: 평균 GROUP BY: 그룹별로 JOIN: 테이블 연결이 정도만 쓴다. 근데 이게 내 일의 80%를 커버한다. 나머지 20%는 여전히 데이터팀에 요청한다. 그들의 전문성이 필요한 부분. 근데 그 20%를 요청할 때도 달라졌다. "이 두 테이블을 조인해서 이런 결과를 보고 싶은데, 제 쿼리가 맞나요?" 데이터 분석가가 말했다. "거의 맞는데 여기만 수정하면 돼요." 소통이 빨라졌다. 같은 언어를 쓴다. 기획자에게 SQL이 필요한 이유 정리해봤다. 내 경험 기준으로. 1. 속도 데이터팀 요청 → 대기 → 결과 받기: 2-3일 직접 쿼리: 5분 의사결정 속도가 10배 빨라진다. 2. 자율성 "이것도 가능할까요?" 하면서 눈치 볼 필요 없다. 궁금하면 바로 확인한다. 밤 11시에도. 3. 정확성 내가 원하는 게 뭔지 정확히 안다. 설명할 필요가 없다. "아 그게 아니라 이걸로 봐주세요" 하는 왕복이 사라진다. 4. 신뢰도 "데이터 기반으로 얘기하네" 하는 인식이 생긴다. 회의에서 발언권이 달라진다. 숫자로 말하니까. 5. 성장 데이터를 보는 눈이 생긴다. 어떤 지표가 중요한지. 어떻게 측정할지. 기획 실력이 올라간다. 당연히. 시작하는 법 주변 기획자들이 묻는다. "어떻게 시작했어요?" 내 방법은 이랬다. 1주차: 기본 개념SELECT, FROM, WHERE 유튜브 '생활코딩 SQL' 시리즈 하루 30분씩2주차: 실습 환경개발자한테 테스트 DB 권한 요청 DBeaver 또는 TablePlus 설치 우리 회사 테이블 구조 파악3-4주차: 기본 쿼리COUNT, SUM, AVG GROUP BY, ORDER BY 회사 데이터로 직접 실습2개월차: JOININNER JOIN, LEFT JOIN 테이블 두 개 연결하기 실무에서 자주 쓰는 패턴 익히기3개월차: 응용서브쿼리 CASE WHEN 날짜 함수여기까지면 충분하다. 나머지는 필요할 때 찾아보면 된다. 추천 자료 내가 실제로 도움받은 것들. 온라인 강의인프런 '모두를 위한 SQL' (입문) 유데미 'SQL for Data Analysis' (실무)책'모두의 SQL' (길벗, 입문자용) 'SQL 첫걸음' (한빛미디어)도구DBeaver (무료, 추천) TablePlus (유료지만 이쁨) SQL Fiddle (온라인 연습)커뮤니티생활코딩 SQL 오픈채팅방 데이터 분석 스터디 모임혼자 하면 힘들다. 같이 하는 사람을 찾아라. 3개월 후 오늘 주간회의. 대표님이 물었다. "이번 분기 KPI 진행률은?" 노트북을 열었다. 저장해둔 쿼리를 실행했다. "가입자 목표 대비 87%, 매출은 92% 달성 중입니다. 예상대로면 이번 주 목요일에 100% 도달합니다." 5초 만에 대답했다. 대표님이 웃었다. "준비성이 좋으시네요." 준비한 게 아니다. 매일 보고 있다. SQL로. 퇴근길에 생각했다. SQL을 배우기 전과 후. 전에는 데이터가 '누군가 주는 것'이었다. 이제는 '내가 뽑는 것'이다. 이 차이가 크다.데이터로 증명할 수 있다는 건, 내 의견이 아니라 사실로 말할 수 있다는 것이다. SQL은 그 도구다.
- 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배 올랐다. 스트레스 감소 "답 안 했다고 뭐라 하면 어쩌지" 걱정했는데 아무 일 없었다. 정말 급하면 전화 온다. 전화 안 오면 안 급한 거다. 관계 개선 답장 늦어도 이유를 말하니까 이해한다. "스펙 정리 중이라 오후에 드릴게요" 이렇게 말하면 기다린다. 무작정 답 안 하는 것과 다르다. 마무리 슬랙은 폭탄이다. 매일 터진다. 해체하는 법을 배워야 한다. 급한 선 하나 긋고. 중요한 선 하나 긋고. 그 안에 있는 것만 처리한다. 나머지는 내일.슬랙 끄고 일하는 시간. 그게 진짜 일하는 시간이다.
- 07 Dec, 2025
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 준비했다. 또 설득한다.