개발자가 좋아하는 서비스 플로우

Figma

생각의 순서를 공유하기

 와이어프레임, 목업, 경쟁사 스크린샷은 잔뜩 있는데 정작 사용자가 어떤 상태에서 어떤 상태로 이동하는지가 없어서, 개발자들이 머릿속에서 다시 역설계를 해야 하는 상황이 정말 많습니다. 한국에 정말 훌륭한 디자이너가 많습니다. 그래서 대부분의 디자인 시안은 흠잡을 데 없이 아주 예쁩니다. 그런데 디자인한 화면들이 서로 어떻게 연결되는지에 대한 플로우가 있는 경우는 드뭅니다.

 

 대부분의 개발자 입장에서 서비스의 플로우는 디자인 파일보다는 상태 다이어그램에 더 가깝습니다.

1.   이 화면이 뜨기 전에 사용자는 어디에 있었는지
2.   여기서 버튼을 누르면 어디로 가야 하는지
3.   실패하면 어디로 돌려보낼지

 이 흐름이 없으면, 화면이 아무리 많아도 구현 계획이 세워지지 않습니다. 최소한 이 정도의 플로우를 그려주면 개발자와의 대화가 훨씬 덜 피곤해집니다.

 

 그래서 이 글에서는, 기획서를 한 번도 안 써본 분이라도 작성하실 수 있는 수준의 초간단 서비스 플로우 예시를 소개드리고자 합니다. 실제 프로젝트에서 거의 매번 등장하는 패턴으로 구성해 보았습니다.

 

 

 

Graphics Digital Background

게스트로 쓰다가 로그인하기

“로그인 안 해도 둘러볼 수 있고, 북마크 같은 거 할 때 로그인시키고 싶어요.”

 대부분 서비스가 이렇게 말합니다. 문장으로 들으면 쉬운데, 플로우를 안 그려오면 여기서 항상 사고가 납니다. 반대로, 이걸 깔끔하게 그려오면, 개발자 입장에서는 기획자를 꽤 신뢰하게 됩니다. 개발자 입장에서는 아마 최소한 이런 상태들이 머릿속에 있습니다.

•   GUEST_BROWSING (비로그인, 둘러보는 중)
•    WANT_ACTION (북마크/좋아요 등 ‘로그인 필요’ 행동 시도)
•    LOGIN_FORM (로그인 화면)
•    LOGIN_SUCCESS (로그인 성공)
•    BACK_TO_WHERE (원래 하려던 행동 마저 하기)

 그리고 이걸 단순화하면, 흐름은 이렇게 됩니다.

• GUEST_BROWSING
   → 유저가 콘텐츠를 스크롤하면서 구경
• GUEST_BROWSING
  → “스크랩하기” 버튼 클릭
  → WANT_ACTION 상태로 전환
• WANT_ACTION
  → “로그인이 필요합니다” 안내
  → LOGIN_FORM으로 이동
• LOGIN_FORM
  → (성공) LOGIN_SUCCESS
  → 원래 보던 화면 + 원래 하려던 액션 실행
  → 스크랩 완료 상태 표시
• LOGIN_FORM
  → (실패) 에러 메시지
  → LOGIN_FORM 유지 or 비밀번호 찾기 플로우로 분기

 

 아주 간단하게, 텍스트로는 이렇게 정리하면 됩니다.

1. 비로그인 상태 (앱/웹 첫 진입)

2. 로그인 시도

3. 로그인 성공 → 서비스 메인 화면

4. 로그인 실패 → 에러 메시지 + 재입력

5. 회원가입 진입 → 회원가입 완료 → 자동 로그인 or 로그인 화면

6. 비밀번호 찾기 요청 → 재설정 메일 발송 → 새 비밀번호 설정 → 로그인

 

 글로만 보면 좀 복잡한가요? 그림으로 그리면 간단합니다. 논리 구조로 표현해볼게요. 도형을 기준으로 나눈다면, 일반적으로 둥근 사각형을 시작/종료, 사각형을 상태/화면, 마름모는 조건/판단 공식으로 그립니다.

 

 여기서 확실히 정해주면 좋은 포인트는 두 가지입니다.

1. 로그인 후 원래 하려던 행동을 자동으로 실행할지, 한 번 더 누르게 할지
2. 원래 보던 위치(스크롤, 필터 상태)를 복원할지, 처음부터 다시 보여줄지

 

 기획서에는 굳이 어려운 용어를 쓸 필요가 없다고 생각합니다. 그냥 이렇게 써 주시면 됩니다.

1. 게스트가 스크랩 버튼을 누르면 → 로그인 → 다시 돌아와서 ‘이미 스크랩된 상태’로 보여주세요.
2. 로그인 후에도 목록/상세 스크롤 위치는 유지해 주세요.

 

 이 정도 문장만 있어도, 상태와 컨텍스트를 유지해야 하는 요구사항인지 이해하고 넘어갈 수 있습니다.

 

 

 

Anastasia Lipenkova

결제 시도하기

 결제 서비스 기획은 조금 더 기술적인 영역입니다. 초보 기획자가 많이 어려워하는 부분이기도 합니다. 창업자의 입장에서는 돈 들어오는 길이고, 개발자 입장에서는 장난치면 안 되는 길이죠. 결제의 기본 흐름은 이렇게 나눌 수 있습니다.

 

•   요금제/상품 목록 화면
•   특정 요금제 선택
•   결제 수단 선택 화면
•   결제 모듈(카드, PG사 화면 등) 진입
•   결제 성공
•   결제 실패/취소
•   성공 시 서비스 권한/상태 변경
•   실패/취소 시 안내 + 재시도 옵션

 

 그런데 개발자의 입장에서는 눈에 안 보이는 상태가 추가로 있습니다. 예를 들면 이런 상태입니다.

•   PAYMENT_INIT (결제 시작됨)
•   WAITING_FOR_PG (PG 응답 대기)
•   PAYMENT_SUCCESS (PG 성공 응답 받음)
•   PAYMENT_FAIL (PG 실패 응답 받음)
•   APPLY_RIGHTS (권한 부여 처리 중)

 

결제는 세 군데에서 동시에 일어납니다. 사용자 눈에 보이는 화면, PG사 같은 외부 결제 모듈, 그리고 서비스 내부 서버와 DB이지요. 보통 기획에서 아무 말이 없으면, 개발자들은 경험상 안전한 쪽으로 정합니다. 그래서 기획 단계에서 최소한 이 세 가지를 적어주면 좋습니다.

 

1. 언제 유료 권한을 줄 것인가?

• PG가 성공이라고 응답한 시점에 바로 권한을 준다.
• 웹훅/서버 콜백까지 확인한 뒤에 권한을 준다. (조금 더 안전한 처리)

 

2. 성공했지만 화면이 실패처럼 보일 수 있는 상황은 어떻게 처리할 것인가?

• 사용자가 결제 완료 후 브라우저를 닫았거나, 통신 오류로 성공 화면을 못 받았을 수 있습니다.
• 결제 내역 화면에서 최종 상태를 항상 확인할 수 있어야 한다라고 정책을 정하면,
• 개발자는 '리프레시 시 서버 상태 기준으로 다시 그리자'라고 판단할 수 있습니다.

 

3. 실패/취소 케이스를 어디까지 안내할 것인가?

• 결제 창에서 X 눌렀을 때 → 사용자 취소
• 한도 초과/잔액 부족 → 카드사 사유, 다시 시도 가능
• 시스템 오류 → 잠시 후 다시 시도

 

  논리 구조로 표현하면 위와 같은 그림이 그려집니다. 플로우는 이런 식으로 적어 나가시면 됩니다.

1. PG 성공 응답 받은 뒤 → DB에 결제 상태 PAID로 저장 → 이용권 시작 날짜 설정 → 성공 화면
2. 브라우저를 닫아도, 결제 내역 페이지에서는 실제 DB 상태 기준으로 성공 또는 실패를 보여준다.

 

 이 정도 문장이 들어가면, 최소한 서버 상태와 화면 상태의 차이를 알고 있는 사람의 느낌을 줄 수 있습니다. 그냥 화면만 그리는 기획보다는, 진짜 구현과 DB/PG 까지 생각하고 기획이 좋겠죠.

 

 

 

Figma

대화가 되는 플로우를 잡자

 완벽한 플로우를 그리려고 할 필요는 없습니다. 흐름을 박스와 화살표로 한 번이라도 그려본 사람과, '그냥 이렇게 해주세요' 라고 말로만 설명하는 사람 사이에는 실제 개발 단계에서 엄청난 차이가 생깁니다.

 

 예쁘게가 아니라, 상태 단위로 생각한다는걸 보여주시면 됩니다. 어디부터 어떻게 그려야 할 지 막힐 때, 그 막연한 상태를 같이 풀어서 '개발 가능한 플로우'로 만드는 역할이 제가 도와드릴 수 있는 길이라고 생각합니다.