context | 커머스/서비스기획

상위 기획 VS 하위 기획 비교

• 상위 기획 : 큰 그림을 그리는 단계 (Why & What) ➡️ "이 서비스가 왜 필요한가?", "어떤 기능을 제공해야 하는가?"
• 하위 기획 : 세부적인 실행을 정의하는 단계 (How) ➡️ "이 기능을 어떻게 만들 것인가?", "사용자는 어떻게 이용할 것인가?"

상위 기획과 하위 기능 기획 예 : 최저가 상품 추천 기능

✅ 상위 기획(High-level)

1. 목표 : 사용자가 최저가 상품을 쉽게 찾을 수 있도록 추천 시스템 도입

2. 핵심 기능

• 최저가 기준 설정 (실시간/최근 가격 변동 반영)
• AI 기반 맞춤 최저가 추천
• UI 구성 : '오늘의 최저가 추천' 섹션 추가

3. 비즈니스 가치 : 가격 민감한 사용자 유입 증가 ➡️ 구매 전환율 상승(CVR)

✅ 하위 기획(Detailed-level)

1. 세부 기능 정의

• 최저가 비교 기준 : 최근 3일간 평균 최저가 대비 5% 이상 저렴한 상품
• 사용자별 맞춤 추천 : 최근 검색/구매 내역 기반 필터링
• UI 상세
  • 리스트 형태 vs 카드형 레이아웃 비교
  • '찜하기' 버튼 추가 여부 결정

2. 데이터 흐름

• 최저가 데이터 크롤링 ➡️ DB 저장 ➡️ 알고리즘 적용 ➡️ 사용자 화면 노출

3. UX 시나리오 작성

• 사용자가 메인 페이지에서 '최저가 추천' 섹션 클릭 ➡️ 상세페이지 이동 ➡️ 비교 ➡️ 구매

UX 시나리오 작성 시 참고 요소

1️⃣ 사용자 관점에서 서술

기능 중심이 아닌 사용자 관점의 흐름을 고려해야 한다. 사용자가 서비스를 사용하는 가장 큰 목적에 따른 흐름을 파악해 보자.
흐름 속에서 어떤 가치를 제공할 수 있는지를 중점으로 고민해야 한다.
사용자가 어떤 문제를 해결하기 위해 서비스를 사용하는지. 문제 해결을 더 쉽게 도울 수 있는 방법이 무엇인지.

서비스가 목표로 하는 전환 시점이 있을 것이다. 그 시점까지 페이지가 이동은 각 기능을 통해서 된다.
주의해야 할 부분은 기능 중심으로 생각하는 것이다. 
예를 들면, 사용자는 검색창에서 상품명을 입력하고, 필터를 적용하여 가격을 정렬한 후, 구매 버튼을 클릭한다.

이것을 사용자 관점으로 바꾼다면, 아래와 같을 것이다.
필요한 제품을 찾으려는 A 씨는 검색창에 상품명을 입력한다. 하지만 원하는 가격대가 아니라 필터를 적용해 최저가를 찾는다. 가장 저렴한 가격이 표시된 상품을 발견하고 바로 구매한다.

맥락은 비슷하지만 과정 사이에 있는 사용자 행동과 목적을 엿볼 수 있다.
"필요한", "원하는 가격대", "가장 저렴한 가격이 표시된" 이런 요소들을 말이다. 이것들을 잘 엮어내어 새로운 가치를 정의하고 개선하는 것이 서비스 기획자가 해야 하는 일이다.

2️⃣ "누가 > 언제 > 왜 > 무엇을 > 어떻게" 순서로 정리하기

앞서 예를 든 내용과 같이 사용자 관점을 확장시키며 조금 더 구조적으로 생각해 볼 수 있다.

• [상황] A 씨는 아침 출근길, 지하철에서 평소 쓰던 샴푸가 거의 다 떨어졌다는 걸 떠올린다.
• [동기] "이번엔 좀 더 저렴하게 사고 싶은데, 최저가를 쉽게 찾을 수 없을까?"
• [행동] A씨는 가격 비교 앱을 열어 '오늘의 최저가 추천'을 확인한다.
• [결정] "이 브랜드 제품이 지금 20% 할인 중이네? 바로 사야겠다!"
• [결과] A씨는 최저가 상품을 클릭해 결제하고, 앱에서 배송 일정을 확인한다.

서비스 사용의 배경, 목적, 과정, 결과까지 흐름을 이어지도록 작성하는 게 중요하다.
그럼 현실적인 하나의 가설을 설정할 수 있게 된다.

3️⃣ 페르소나(Persona)와 상황(Scenario) 정의하기

페르소나를 설정하는 가장 큰 목적은 정확한 타겟 사용자를 지칭하기 위해서이며 성별, 연령, 라이프스타일을 바탕으로 정의할 수 있다.
서비스를 사용자는 주 사용자층을 알고 있다면 더욱 쉽게 설정할 수 있을 것이다.
만약 서비스 초기라 알 수 없다면, 설정 대상에 따라 크게 달라질 수 있다.

또한, 구체적인 상황을 설정해야 한다. 상황이라고 하면 라이프스타일이 여기에 해당된다.

[페르소나 예]

• 55세 김모씨, 스마트폰을 잘 사용하지만 온라인 쇼핑 경험이 적음
• 홈쇼핑을 자주 보며, 전화 주문을 선호함
• 할인 정보가 있으면 관심을 보이며, 복잡한 결제 과정은 부담스러워함

[UX 시나리오 예]

• 김모씨는 TV 홈쇼핑에서 본 상품을 온라인에서 더 싸게 살 수 있는지 궁금해졌다
• 아들이 깔아준 쇼핑몰 앱을 열어보지만, 검색이 어려워 주화 주문이 가능한지 찾는다
• "AI 보이스 쇼핑 지원" 버튼을 누르자 음성 안내로 "원하는 제품명을 말해주세요"라는 메시지가 들린다
• 김모씨는 "홍삼 세트"라고 말하고, AI가 최저가 상품을 찾아준다
• 김모씨가 "이거 주문할게"라고 말하자, 결제가 자동 진행된다
• "주문이 완료되었습니다"라는 음성이 나오고, 김모씨는 편하게 쇼핑을 마친다

이를 통해 타겟 사용자의 행동 패턴과 불편한 점(검색 어려움, 전화 주문 선호)을 파악하여 UX 시나리오를 설득력 있게 구성할 수 있다.

4️⃣ 다양한 사용자 여정 고려하기(Happy & Painful Paths)

지금까지 사용자 관점의 핵심 흐름을 고려했다면, 성공적인 해피 패스와 실패할 수 있는 예외 케이스 페인 패스를 구분한다.
대부분의 사용자가 해피 패스할 수 있을 것이라 생각은 안 해야 한다.
실패하는 오류, 이탈 케이스에 대한 페인 패스는 필수적이다. 케이스에 대해서 많은 고민과 상상이 필요하다.

[해피 패스(Happy Path) 예 - 원하는 상품을 쉽게 찾는 경우]

• A씨는 검색창에 '갤럭시 S25'를 입력한다
• 최저가 상품이 상단에 표시된다
• 가격 변동 그래프를 확인하고, 가격이 안정적인 시점이라고 판단해 구매한다.

[페인 패스(Painful Path) 예 - 원하는 상품을 못 찾은 경우]

• A씨는 '갤럭시 S25'를 검색했지만, 최저가 상품이 보이지 않는다
• 가격 비교 기능이 부족하다고 느끼고, 이탈한다
• 다른 쇼핑몰에서 구매하고 해당 서비스에 대한 신뢰도가 떨어진다

[페인 패스를 고려 예 - 검색한 상품이 최저가가 없을 때]

• 검색 상품의 유사 상품을 추천 로직 기획 : 동일 제조사/브랜드 & 동일 카테고리 & 최근 출시년도 & 최저가 상품 노출

상위 기획과 하위 기획에 대한 비교부터 UX 시나리오까지 살펴보았다.
상위 기획이 탄탄해야 하위 기획이 명확해진다. 또한, 하위 기획이 잘되어야 개발이 원활하고 실제로 서비스에서 잘 작동된다.

탄탄한 기획의 시작은 문제를 정의하는 것부터 시작된다고 생각한다. 주워진 프로젝트의 목적을 이해하고 스스로 목표를 설정할 줄 알아야 한다.
상위 기획을 하는 과정에서도 스스로에 대한 명확한 정의가 없다면 흔들릴 수 있다. 그렇게 되면 하위 기획으로 갔을 때, 본질이 더 흐려질 수 있다.
정말 어려운 일이다. 본질을 흐리지 않고 목적에 다달을 수 있는 최적의 방법을 찾아야만 한다. 가능한 현실적으로 말이다. 그리고 빨리.

사업 전략 기획 VS 서비스 기획 비교

• 사업 전략 기획은 "어떤 사업을 할 것인가?"를 정의하는 큰 그림을 그리는 역할
• 서비스 기획은 "어떤 기능을 제공할 것인가?"를 구체적으로 설계하는 역할

서비스 기획을 더 잘하기 위한 실행

앞서 정리한 표와 같이 서비스 기획자가 해야 할 역할과 대상이 다르다.
구체적으로 설계를 할 줄 알아야 하는데 사실 이 부분이 막막하다.
작성한 문서를 혼자 볼게 아니라 관련 부서 담당자들과 소통하며 설득해 나아가는 과정의 자료로 사용되기 때문이다.
내 머릿속엔 있지만, 그들도 연상할 수 있도록 만들어야 한다.
대상이 디자이너, 개발자, 운영이 될 수 있지만. 먼저 나의 직속상관을 설득하는 자료이다.

산출물인 문서를 더 잘 만들기 위한 몇 가지 실행 안을 작성해 보았다.
하면 당연히 도움이 될만한 내용이지만 실행에 옮기는 건 쉽지 않은 내용이다.

1️⃣ 사용자 중심 사고 키우기

서비스 기획의 목적은 사용자가 목적대로 흐름을 따라가 주길 바라는 것이다. 
훌륭한 기능 개선일지라도 사용자가 사용하지 않는다면 의미가 없다.
사용자가 어떤 목적으로 서비스를 사용하고 주로 어떻게 행동하는지 알아야 한다. 개략적이라도 말이다.
예를 들면, 주요 사용 디바이스는 ios이며 20대 여성이 많이 사용하는 일기앱 서비스라는 것을 인지하고 있는 상태와 그렇지 못한 상태는 다를 것이다.

실제 사용자 인터뷰를 통해 알 수 있다면 더욱 좋을 것이다. 설문 또는 대면(화상) 인터뷰를 통해 확인할 수 있다.
인터뷰 내용을 바탕으로 사용자 여정(User Journey)을 그려볼 수 있을 것이다.
우리 서비스를 알게 된 시점과 가장 많이 찾는 목적 그리고 전환이 이루어지는 시점을 고객의 목소리(VOC)를 통해 알 수 있다.
이를 통해 데이터를 만들어낼 수 있다.

하지만 오픈 초기의 서비스이거나 설문조사가 어려울 경우, 페르소나(Persona)를 구체화하여 사용자를 정의해 볼 수 있다.
페르소나는 주요 사용자를 정의하는 것을 시작으로 가설에 대한 연령, 성별, 관심사, 행동 패턴까지 분석하는 것으로 마무리된다.

유사 서비스가 있다면, 벤치마킹하는 것이 중요하다.
해당 서비스의 주요 사용자를 파악할 수 있고 시장 규모와 트렌드를 파악할 수 있다. 
특히 사용자 흐름과 강조하는 기능을 엿볼 수 있기 때문에 유사 서비스 벤치마킹은 매일 하면 좋다.
국내외 UI/UX를 중심으로 살펴보며 개인 블로그에 장단점을 기록해 보는 습관을 갖는 것도 좋다.

2️⃣ 데이터 기반 의사결정 훈련

가장 중요한 부분이라 생각된다. 하지만 데이터 중심 사고를 하는 것은 쉽지 않다.
서비스 기획자가 알아야 할 데이터 지표가 있다. MAU, DAU, CTR, CVR, LTV 등이 있다.
이를 바탕으로 일정 기간을 두고 A/B 테스트를 통한 데이터 개선 경험을 많이 쌓는 것이 서비스 기획자의 역량을 키울 수 있다.

데이터를 보려면 내가 어떤 목적을 가지고 이 서비스를 하려는지 알아야 한다.
그러려면 어떤 문제인지 정의를 해야 하고 문제를 해결하기 위한 가설을 세울 수 있어야 한다.
"문제 > 원인 분석 > 해결책(가설) > 기대 효과(목표 지표)" 구조로 정리할 수 있다.

최종적으로 정량적 데이터(숫자)와 정석적 데이터(사용자 피드백)가 결합된 리포트를 작성할 수 있다면 좋다.

3️⃣ 기획 문서 & 커뮤니케이션 스킬 강화

기획은 논리가 있어야만 한다.
특히 새로운 기능 기획 시, 논리적으로 설득력을 가져야만 한다. 기본적으로 기획자는 일을 만드는 사람이기 때문에 리소스를 사용하는 것이다. 논리가 빠진 기획안으로 소통하게 된다면 업무 추진이 안된다.

• Why : 왜 필요한가? 에 대한 문제를 정의한다.
• What : 문제를 해결하기 위한 기능을 설명/정의한다.
• How : 기능을 어떻게 구현할 것인지에 대한 UX흐름, 개발 고려사항을 작성한다. 

상황에 따라 문서의 레벨은 달라진다. 시간이 촉발할 수도, 워터풀 방식이라, 친해서(?) 등등.
무엇보다 문서 작성의 목적은 커뮤니케이션을 하기 위함이다. 물론 히스토리를 남기기 위한 것도 있지만.
기본적으로는 개발팀과 디자인팀과 소통하기 위한 문서이다. 완벽한 문서를 만들기 위해 너무 많은 시간을 소비해서는 안된다.

또한 커뮤니케이션을 소홀히 생각해서는 안된다. 서비스 기획자이야 말로 혼자서 할 수 있는 일은 전혀 없다.
다 담당자가 모여 한 땀 한 땀 해내는 일이다. 
각 실무자와 긴밀하게 소통하며 서로가 이해하기 쉽게 작성해야 한다. 특히 각자 포지션에서 고민한 내용에 대한 피드백이 있을 때 유연하게 대처할 수 있어야 한다.
기획자가 정하는 것이며 모든 책임은 기획자가 진다는 것을 잊지 말아야 한다. 
성공하면 우리 모두의 성공, 실패하면 기획자의 잘못이 될 수 있다.

4️⃣ 실행력 높이기

세상에 시간과 돈이 넉넉하다면 못할 일은 없다. 하지만 우리에겐 시간도 돈도 없다.
빠르게 실행하고 결과물을 얻는 것이 중요하다. 쿠팡을 넘어설 위한 원대한 기획안을 갖고 있어도. 완성하지 못한다면 아무 의미 없다.

큰 기획안을 쪼개서 진행할 줄 알아야 한다. 협업해야 할 실무자들이 겁내지 않도록. 상사가 의사결정을 쉽게 할 수 있도록 말이다.
쪼개는 방법은 연차가 쌓이면 자연스레 익혀질 수 있을 것 같다. 그전까지는 내부 커뮤니케이션을 통해 의사결정을 이끌어 내야 한다.
이후, 실제 유저 반응을 보며 개선점을 찾아가는 것도 방법이다.

실행력을 높이기 위한 방법 중 하나로 MVP(최소 기능 제품)이 있다.
빠르게 만들고, 사용자 반응을 확인하며 업데이트하는 방식인데. 주의해야 할 점은 목표하는 개선점에 대한 지표를 공동으로 사전 합의해야 한다.
나의 생각과 다른 사람의 생각이 다를 수 있다. 대체로 다르다.

글을 작성하며 나를 다시 되돌아보는 시간이었다. 최근 갖고 있던 고민 중 하나가 해소되었다.
서비스 기획 업무를 하며 하면 할수록 잘 모르겠다는 생각이 컸다. 오히려 퇴보하는 느낌도 있었다. 
이전에는 UI/UX에 대한 옳고 그름 기준이 생겨가고 있었는데 이제는 잘 모르겠다. 그 기획자 의도한 바일 수 있겠다는 생각이 들었기 때문이다. 
나는 업자니까 보이는 것이지만 대부분의 사용자들은 과연 느낄까 싶다. 
최근에는 주요 지표에 대한 이슈가 있어서 그저 지표만 잘 나오게끔 하는 것이 더 좋은 기획이 아닐까라는 생각도 해봤다.

그럼에도 불구하고 서비스 기획자는 논리적으로 사고하며 구체화된 실행 안을 제시할 수 있어야 한다.
논리적... 구체화... 어려운 이야기이지만. 거듭 고민하고 실행하다 보면 결국 배포하는 것이 내 일이다.

CTR과 CVR 비교표

CTR과 CVR을 서비스 기획 관점에서 해석하기

CTR과 CVR은 각각 유입(관심) 과 전환(행동) 을 측정하는 핵심 지표로, 서비스 기획에서 사용자 여정(User Journey) 을 분석하고 최적화하는 데 중요한 역할을 합니다.

서비스 기획 관점에서 핵심 포인트

1. CTR은 관심을, CVR은 실행을 의미 → CTR이 높다고 해서 반드시 성공적인 서비스가 아님. 최종 목표는 CVR 향상.
2. 광고·유입 최적화 vs. 서비스·UX 최적화 → CTR은 유입을 늘리는 전략이 중요하고, CVR은 서비스 경험을 개선하는 것이 핵심.
3. 퍼널 분석 필수 → CTR → 랜딩 페이지 방문 → 장바구니 추가 → 결제 완료까지 전 과정에서 어디서 이탈이 발생하는지 세밀한 분석 필요.

즉, CTR은 사용자 관심을 얻는 지표, CVR은 그 관심이 실제 서비스 성과로 이어지는지 판단하는 지표이므로, 기획자는 두 지표를 균형 있게 개선하는 전략을 수립해야 합니다. 

서비스기획 시, 쉽게 놓칠 수 있는 부분이기도 하고 기획서 작성이 쉽게 누락시킬 수 있는 부분이다.
당연히 새창으로, 이동으로 만들어야 하는 것을 기획서에 기재하지 않으면 만들어야할 사람에게 혼란을 야기시킨다.

페이지 새창과 이동 비교표

• 페이지 새창은 추가 정보 제공이나 중요한 작업을 유지해야할 때 적합하다.
• 페이지 이동은 사용자가 자연스럽게 다음 단계로 이어질 수 있는 경우 적합하다.

UX 관점의 고려사항

• 새창 사용 시, 사용자에게 명시적 안내 제공 (아이콘 사용 및 툴팁 추가)
• 페이지 이동 시, 사용자가 필요한 이전 페이지로 돌아갈 수 있는 명확한 네비게이션 제공 (예. '뒤로 가기' 버튼, 브래드크럼)

아래 대상자는 개인정보 보호법에 따라 연 1회 이상 회원에게 [개인정보 이용내역] 관한 내용의 메일을 고지해야만 한다.
정보주체의 수(5만 명, 100만 명)는 전년도 말 기준 직전 3개월 간 일일평균을 기준으로 산정한다.

• 5만 명 이상의 정보주체에 관하여 민감정보 또는 고유식별정보를 처리하는 자
• 100만 명 이상의 정보주체에 관하여 개인정보를 처리하는 자

11~12월에 가장 많이 볼 수 있는 개인정보 이용내역 이메일 발송 관련해 파악해야 할 내용을 간략하게 기록하고자 한다.

1. 관련 법령 및 내부 이용약관 변경 확인

2024년 기준으로는 아래 법령을 참고하면 된다.

2. 대상 회원수 파악

앞서 말한 바와 같이 개인정보 보호법에서 정하는 정보주체수가 있다. 회원수가 늘어서 또는 줄어서 대상이 아닐 수 있기 때문에 내부 서비스의 대상 회원수를 파악해 보도록 한다.

법령에서는 통합/연동 회원에 대한 발송 기준은 명시되어 있지 않다.
내부 기준에 따라 통합/연동된 계정에는 중복으로 메일을 발송하지 않아도 된다.
단, 내부적으로 기술적/정책적 기준이 정해져 있어야 한다. 통합/연동 시 마스터 계정의 이메일 정보와 이메일 중복 또는 유효성 기준이 있어야 한다.

대상 회원수를 파악하는 것은 굉장히 중요한 일이다.
누락되어서도 안되고 중복으로 여러 번 발송되어서도 안된다.

3. 콘텐츠(퍼블리싱 페이지) 준비

메일 내용에 들어갈 콘텐츠를 준비해야 한다.
일반적으로는 지난해 콘텐츠를 활용하는 편이지만 내부 협의를 통해 내용을 변경할 수 있다.
올해 트렌드는 최소한의 정보만 기재하고 링크를 삽입하는 편인 듯하다.

디자인은 부수적인 내용이고 내용의 텍스트가 중요하다.
앞서 찾은 법령 조항은 잘 입력되었는지, 내부적으로 변경된 이용약관은 없는지.
마지막으로 오탈자는 없는지 확인의 확인을 꼭 해야 한다.

쉽게 놓칠 수 있는 부분으로는 내용 푸터에 들어가는 회사 정보이다.
대표자, 주소의 변경 그리고 대표번호, 대표이메일 정보가 알맞게 기재되어 있는지 확인한다.

4. 발송 준비

1) 이메일 대량 발송 업체 선정
5만 명 이상 고객에게 메일을 발송해야 하기 때문에 일반적으로 대량 발송 업체를 통해 보낸다.
큰 불편함이 없었다면 기존에 사용하던 업체를 쓸 것이다. (나는 업체를 바꿀 것이다.)

2) 테스트 발송
위 내용이 모두 준비가 되면 테스트 발송을 해본다.
템플릿 또는 이미지로 확인한 내용과 메일로 받아본 느낌은 다르다.
로고에 서비스 홈으로 이동되는 링크와 개인정보 이용내역 버튼을 눌렀을 때 이동되는 것을 꼭 확인을 해봐야 한다.

3) 충전금 확인
내부 시스템에 따라 발송을 하기 전에 품의서를 쓰고 지출결의서를 작성하는 회사가 있을 수 있다.
그때 당연히 대상수와 예상 발생비용을 파악하기 때문에 충전금은 지금 단계에서는 파악할 필요 없다.
그래도 발송 전에 충전금이 충분한지 확인해야 한다.

4) 대량 엑셀파일 업로드 테스트
간과할 수 있는 부분이다. 준비된 엑셀파일을 미리 업로드해 볼 것을 추천한다.
파일 크기, 인원수 제한 또는 알 수 없는 오류로 인해 발송 당일 괜한 시간을 빼앗길 수 있다.

5. 이메일 대량 발송

보고한 발송일 전 일에 "예약발송"을 새벽에 해두길 권장한다.
불안하다면 평소보다 조금 더 일찍 출근해 발송하길 바란다.

대량으로 발송되면서 시스템의 일시적 오류가 발생할 수 있다.
그렇게 되면 재발송의 재발송을 해야 하는 상황이 생길 수 있다.
올해 내가 경험한 것은 금방 끝날 것 같던 이 일을 하루종일 붙잡고 할 수밖에 없었던 이유이다.

짧은 회고...

대량 엑셀파일을 업로드하면서 이메일 유효성 케이스에 대해서도 살펴볼 수 있다. 
생각보다 기상천외한 이메일을 볼 수 있다. 당연히 사용하지 않을 이메일 주소 말이다. 
이런 부분은 참고하여 회원 이메일 등록 시 유효성 케이스에 추가하면 좋을 듯하다.

개인정보 이용내역 메일을 보냈다는 것은 한 해가 마무리되는 것이기도 하다.
한 해동안 크고 작은 기능을 배포하거나 운영 건으로 수정을 했다.
아쉬운 것도 있고 생각보다 꽤 괜찮은 것도 있는 것 같다.

서비스기획자로 일하는 것은 큰 행운이다. 
비즈니스에 대한 고민을 하며 조금 더 사업적으로 괜찮은 방향을 찾고 답을 찾아가는 과정은 쉽게 해 볼 수 없는 일이기 때문이다.

지나고 보니 경험이다 생각할 수 있지만 내일 다시 찾아올 현실은 문서와 커뮤니케이션 속에 설득의 반복이다.
눈이 뻑뻑하고 따끔거려도 밝은 모니터를 보며 키보드를 두들기며 만든 문서가 구현되었을 때는 제법 성취감이 크다. 
그래서 이 일이 재밌나 보다. 모든 서비스기획자가 또는 기획자가 내년엔 조금 더 즐겁게 일했으면 좋겠다. 

플로우차트 또는 흐름도라고 불리는 이것은 서비스기획 시, 꼭 필수는 아니다. 상황에 따라 필요한 경우가 있고 목적에 따라 형태나 흐름은 달라질 수 있다. 
어디까지나 문서의 이해도를 높히기 위한 목적으로 소통을 잘하기 위한 수단일 뿐이다.

서비스기획자는 일반적으로 유저흐름(user flow)을 많이 작성한다. 화면/기능 단위 또는 사용자 행동의 시작과 끝의 과정 중에 데이터 흐름도 포함시키면 좋다.
다만, 기획자가 모든 데이터의 저장 위치와 저장 형태(기간, 기준, 용량)을 파악하긴 어렵다.
그렇기 때문에 기획안을 보완하는 과정 중에 업데이트하며 추가하는걸 권한다.

1. 플로우차트 주요 기호

위 이미지는 주로 많이 사용하는 기호이다. 외에도 다른 기호들도 있다. 
모든 기호에 대한 의미를 암기할 필요는 없다. 왜냐하면 파워포인트에서 호버했을 때 나오기 때문이다. 

목적에 맞게 기호를 사용해도 좋지만 네모 박스인 [처리]로 대부분의 표현은 가능하다.

2. 플로우차트 예시

로그인 시, 사용자 흐름 기준으로 작성한 플로우차트이다. 여기에 데이터 입력 시, 글자수 제한이나 어느 DB에서 회원정보를 비교/일치 하는지도 추가할 수도 있다.

학창시절에 흐름도에 대해 시험을 봤던 기억이 있다. 지금은 잘 기억나지 않는다.
내가 작성한게 틀릴 수 있다. 틀리면 창피한 일이긴 하나 그래도 소통하는데 목적을 두고 구체적으로 작성하면 좋은 흐름도이지 않을까라는 생각을 해본다. 그리고 틀렸다면 또 배우면 되지라는 생각이다. 
몰라서 안하는 것보다 배워서 다시 하는게 더 중요하다.