프로덕트 기획은 백엔드를 알아야한다

안녕하세요!
퇴근하고 돌아온 프로덕트 디자이너 메리입니다.
오늘은 회사 카페에서 백엔드 개발자분과 대화중 나온 주제인데요. 이번 주제는 ”백엔드를 알아야 프로덕트 기획을 할 수 있다“입니다.

(연어가 강을 거꾸로 올라가듯 .. 기획을 거꾸로 가면 서버라는 뜻의 짤입니다.. 근데 곰 좀 무서운듯 ㄷㄷ)

⸻

프로덕트 기획은 단순히 화면을 구성하고 기능을 나열하는 일이 아니죠. 사용자에게 도달하는 서비스의 흐름을 논리적으로 정의하고, 기능이 실제로 작동할 수 있도록 설계하는 것이 핵심인데요. 이 과정을 구조화하려면 백엔드에 대한 최소한의 이해는 정말 필수입니다.

왜냐하면 우리가 설계하는 거의 모든 화면은 결국 데이터를 “어떻게 저장하고”, “언제 불러오고”, “누가 수정/삭제할 수 있는지”에 대한 흐름으로 만들어지거든요. 이 흐름을 움직이는 심장 같은 존재가 바로 백엔드입니다.

⸻

백엔드를 모르면 이런 일이 생깁니다 💥

1. 기획자는 “이거 리스트만 쭉 보여주면 되죠~“ 했는데,

백엔드는 “리스트가 300개인데… 페이지네이션 안 하면 터집니다” (= 한 화면에 다 나오게 만들었다가 서버와 브라우저 둘 다 사망…)

2. 디자이너는 슬쩍 “좋아요” 기능 넣었는데..

백엔드는 “유저별 좋아요 상태 저장하고, 중복 방지하고, 좋아요 수 카운트하고… 할 게 많아요”
(= 버튼 하나가 DB 테이블 하나 생성되는 순간)

3. 화면 흐름은 그럴듯한데,

프론트는 “API를 3번 호출해야 돼요… 이거 무겁고 느려요…”

이런 일, 다들 한 번쯤 겪어보셨죠? 기획자, 디자이너, 개발자 모두 고개를 끄덕이게 되는 대화입니다.

⸻

기획자는 왜 백엔드를 알아야 할까?

기획자는 기능을 나열하는 사람이 아니라 서비스의 데이터 흐름을 설계하는 사람이에요. 아래 상황에서 백엔드 이해는 큰 힘을 발휘합니다.

• 회원가입 플로우를 설계할 때, 입력한 데이터가 어떤 API를 통해 어디에 저장되고, 토큰은 어떻게 발급되고, 이후 인증은 어떤 방식으로 유지되는지 등등.

• 마이페이지나 주문 내역 같은 화면에서 어떤 데이터를 어디에서 가져오는지, 어떻게 업데이트할 수 있는지를 알고 있다면 훨씬 더 구체적인 기획이 가능합니다.

• 그리고 무엇보다도, 서버에서 가능한 일인지, 시간이 오래 걸리는 일인지, 실시간으로 처리해도 되는지 이런 기준을 잡는 눈이 생깁니다.

⸻

디자이너도 백엔드를 알면 좋은 이유

예쁘게 만드는 걸 넘어서서, 동작 가능한 디자인을 하려면 백엔드와 데이터 흐름에 대한 이해가 필요해요.

• 이 버튼을 누르면 어떤 API가 호출돼?
• 이 데이터는 새로고침하면 바뀌는 거야? 아니면 고정된 거야?
• 이 유저, 이걸 삭제할 권한은 있는 거야? (← 진짜 중요!)

이걸 알고 설계하면 디자인 단계에서부터 개발자와의 커뮤니케이션이 훨씬 부드러워지고, 불필요한 재작업도 줄어들어요.

특히 에러 설계! 이거 진짜 다들 마지막에 급하게 팝업 만들잖아요? 근데 실제로는 400, 403, 500 등 상황별로 에러 UI를 미리 설계해두면 디자인 시스템에도 깔끔하게 정리되고, 사용자 경험도 좋아집니다.

⸻

사례: 백엔드를 알면 이렇게 달라집니다.

1. 리뷰 삭제 버튼, 누구한테 보여줄까?

• 내가 쓴 리뷰에만 삭제 버튼 보여줘야 하는데, 이걸 설계 단계에서 생각 못 하면
  모두에게 보이는 불상사가 발생합니다. → 백엔드에서 권한 체크 필요!

2. 검색창에 필터 8개 넣었는데, 서버는 3개밖에 못 받아요…

• 프론트는 화려하게 만들었는데 백엔드는 “정규화된 값만 받을 수 있어요…”라고 할 수도 있어요.
  ex) ‘색상별’, ‘사이즈별’, ‘별점순 정렬’ 등 생각보다 어렵습니다!

3. 등급별 혜택 설계할 때 무리수 두면…

• 실시간 등급 산정은 서버 리소스 많이 먹어요. 매일 밤 12시에 계산되게 설계하는 게 낫기도 해요. 이걸 알고 있으면 UX 설계도 더 똑똑해질 수 있죠.

4. 에러 시나리오 미리 설계하면 멋진 디자이너로 인정받음

• 예: 서버 과부하로 응답이 안 올 수 있음 → “일시적인 오류가 발생했어요. 다시 시도해주세요” + 재시도 버튼 설계 (이거 미리 해두면 ㄹㅇ 알잘딱깔센 디자이너 됩니다.)

5. 화면 로딩은 다 같은 로딩이 아니다

• API 여러 개를 순차 호출해야 할 때는 전체 로딩보다 구역별 스켈레톤 로딩이 낫고, 이걸 고려해서 디자인하면 서비스 속도 체감이 확 좋아져요!

⸻

마무리 ✨

요약하자면 이렇습니다:
기획의 시작은 데이터 흐름이고, 그 중심엔 백엔드가 있다.

백엔드를 이해하면 기능 누락이 줄고,
개발과 디자인 사이에 오해도 적어지고,
결국엔 더 나은 사용자 경험으로 이어집니다.

꼭 코드를 짜지 않아도 괜찮아요.
하지만 적어도, 우리가 그리는 화면이 서버에서는 어떤 식으로 “돌아가는지” 정도는 알면 정말 큰 차이를 만듭니다.

그럼 다음 편에서 또 만나요!