[TIL] 설문과 API로 서비스 흐름 점검하기

사전 설문 문항을 만들고 BE 회의에서 피드, 랭킹, API 분담을 논의하며 사용자가 서비스를 어떻게 이용하게 될지 구체화한 기록입니다.

게시 2026/05/13 업데이트 2026/05/14

By sinyeowon

읽는 시간 4분

For the English version of this post, see here.

[TIL] 설문과 API로 서비스 흐름 점검하기

오늘 한 일

사전 설문조사 구글폼 작성 및 배포
- 사전조사를 통해 실제 타겟팅하는 사용자가 이 서비스를 사용할 의향이 있는지, 타인에게 내 소비 습관을 공개한다는 부분에 대해 거부감이 없는지 확인해보면 좋을 것 같다는 피드백을 반영함
API 명세 초안 작성
BE 회의

회의를 통해 가장 크게 느낀 점은 처음 ERD를 설계할 때 실제 사용자 흐름에 대한 이해가 부족했다는 점
기존에는 단순히 소비 기록 -> 랭킹 생성 -> AI 결과 생성 정도로만 생각했는데, 실제 와이어프레임과 연결해서 보니 사용자 입장에서 ‘어디서 어떤 결과를 보게 되는지’가 훨씬 중요했음
특히 아래 부분에서 프론트 와이어프레임과 초기 설계 차이를 발견함
- 프론트 와이어프레임 기준
  - 초기
    - 하루에 여러 주제 존재 - 한 사람마다 별칭 제공
    - 주제를 벗어난 기준을 이용한 랭킹 생성
    - 상위 3명에게만 AI 로스팅 제공
    - 4위 이하 사용자는 개인 피드백 확인 불가능
  - 중간 변경 후
    - 하루에 하나의 주제 존재
    - 주제 기준 랭킹 생성
    - 상위 3명에게만 AI 로스팅 제공
    - 4위 이하 사용자는 개인 피드백 확인 불가능
- 백엔드에서 생각한 방향
  - 개인 페이지에서 자신의 AI 로스팅 확인 가능
  - 또는 순위 공개 없이 4위 이하 사용자도 AI 피드백 확인 가능
- 즉 단순히 AI 결과를 저장하는 것이 아니라, 누가 어디서 어떤 형태로 결과를 보게 되는지도 고려해야 한다는 걸 느낌

또 하나 논의된 부분은 현재 와이어프레임에 Setlog 같은 피드 구조가 없다는 점
만약 피드를 추가한다면 시간순으로 소비 내역이 쌓이는 수직형 타임라인 구조를 생각하고 있음
- 또한 사진은 저장하지 않기로 했기 때문에, 카테고리 아이콘 / 가맹점 / 금액 / 메모 등을 활용해 소비 피드를 구성하는 방향으로 고민함
개인 페이지를 만들어 하루 소비 내역을 누적해서 보여주는 구조도 이야기함

논의를 하면서 ERD나 API를 단순 데이터 구조 관점으로만 보면 안 되고, 실제 사용자가 어떤 흐름으로 서비스를 사용하게 되는지까지 함께 봐야 한다는 걸 느꼈다.
- 특히, AI 결과를 누가 볼 수 있는가 같은 정책 하나가 API, DB 구조, 화면 설계까지 모두 영향을 준다는 점이 인상적이었다.
처음에는 기능 중심으로 설계했다면, 이제는 점점 사용자 경험 중심으로 사고하게 되는 것 같다.