빈 일기장 첫 화면, 백엔드에서 초대장으로 바꾸기

마음기록 앱을 만들다 보면 가장 먼저 마주치는 게 '아무것도 없는 첫 화면'이에요. 처음 들어온 사람에게 텅 빈 목록을 보여주면 '뭘 하라는 거지' 싶어서 그냥 나가버리기 쉽죠. 혹시 이 빈 화면을 프론트 문제로만 생각한 적 없나요? 직접 만들어 보니, 이건 백엔드에서 먼저 손대야 하는 문제였어요.

빈 화면 안에는 세 가지 상태가 섞여 있어요

목록을 부르는 API 하나가 실제로는 세 가지 상황을 반환해요. 아직 불러오는 중, 진짜로 기록이 0개, 그리고 에러. 이 셋을 프론트가 눈치로 구분하게 두면 로딩 중인데도 "기록이 없어요"가 잠깐 뜨는 어색한 화면이 나와요.

그래서 상태를 3가지로 명시했어요. 기록이 없으면 HTTP 200에 빈 배열 [], 실패는 4xx/5xx로 분명하게 갈랐죠. 돌려 보니, '비어 있음'과 '못 불러옴'을 서버가 미리 나눠주는 것만으로 프론트 분기가 훨씬 단순해졌어요.

'처음 온 사람'인지 서버가 먼저 알아야 해요

로그인만 갓 끝낸 사용자는 자기 데이터가 0줄이에요. RLS(행 수준 보안)를 켜두면 남의 기록은 애초에 조회되지 않으니, 빈 배열이 뜨는 게 정상이에요. 문제는 '한 번도 안 쓴 사람'과 '다 지운 사람'을 같은 빈 배열로 취급하면 초대 문구를 언제 띄울지 판단이 안 선다는 거예요.

적용해 봤더니, 응답에 hasEverWritten 같은 불리언 필드 1개만 더 넣어도 충분했어요. 쿼리 한 번으로 "이 사람은 처음이구나"를 서버가 알려주니, 프론트는 그 값만 보고 초대 화면과 빈 목록을 갈라요.

초대장은 서버가 미리 차려둬요

빈 화면을 초대장으로 바꾸는 핵심은, 처음 온 사람에게 시작점을 쥐여주는 거예요. 저는 추천 프롬프트 3~4개를 서버에서 내려줬어요. 클라이언트에 하드코딩하지 않고 응답에 담으면, 문구를 바꿀 때 앱 배포 없이 API만 손보면 되거든요.

로그인→빈 배열+처음 플래그 확인→서버가 추천 프롬프트 제공→첫 기록 저장

테스트해 보면, 이 3단계가 어긋날 때 대부분 '빈 배열=에러'로 뭉뚱그린 코드에서 문제가 나요. 혼자 운영하면서 배운 건, 빈 상태야말로 설계가 필요한 정상 흐름이라는 점이에요.

플랜티(plan-t)는 아직 개발 중이라 이 첫 화면을 계속 다듬고 있어요. 빈 화면은 막다른 길이 아니라, 서버가 먼저 준비해두는 첫 문장일 수 있어요.