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