개발 slecs

약혼·결혼 상태를 홈카드와 헤더 전반에 일관 노출

목차

앗, 이건 작은 기능처럼 보이지만 꽤 생각할 거리가 많은 작업이었다. 약혼·결혼 상태를 헤더와 홈카드에 노출했는데, 단순히 데이터를 끌어다 쓰는 게 아니라 사용자 정보 구조, UI 계층, 그리고 정보 아키텍처 전반을 한번 정리하는 계기가 됐다.

왜 이 상태를 노출해야 했나

우리 서비스에서 약혼·결혼 상태는 실제로는 중요한 사용자 신원 정보다. 사용자 프로필을 볼 때 상대방의 관계 상태를 알 수 있다는 것은 신뢰 형성의 첫 단계이고, 특히 홈 화면의 "홈카드" 같은 주요 진입점에 이 정보를 노출하면 사용자가 서비스 내에서 충분한 맥락을 갖고 상호작용할 수 있다. 헤더(아마 사용자 프로필 섹션일 텐데)에도 추가함으로써 페이지를 이동해도 일관되게 자신의 상태를 보여주는 경험을 만들 수 있다.

이런 작업은 보통 다음 타이밍에 발생한다:
- 기존 데이터는 있는데, UI에서 아직 안 쓰고 있는 경우 (우리 케이스인 것 같음)
- 사용자 피드백에 따라 "내 정보를 더 명확하게 보이게 해달라" 요청
- 새로운 UI 리뉴얼이나 정보 아키텍처 재정비

어디에, 어떻게 변경했나

변경 파일을 보면 스토리가 꽤 명확하다:

파일 역할 변경의 의미
src/lib/user.ts 사용자 데이터 모델 약혼/결혼 상태를 사용자 객체에서 접근 가능하도록 구조화
src/lib/characters.ts 캐릭터(아마 프로필?) 로직 사용자 상태를 캐릭터 데이터와 매핑
src/app/page.tsx 홈페이지 홈카드에서 상태 정보 렌더링
src/app/character-grid.tsx 캐릭터 그리드 UI 그리드 카드 내에서 상태 표시
src/app/chat/[slug]/chat-client.tsx 채팅 인터페이스 헤더나 사이드바 영역에서 상태 표시

핵심은 데이터층에서 먼저 정리하고, UI층에서 여러 곳에 반영했다는 것이다. 이게 중요한 이유는:

  • user.tscharacters.ts에서 상태 필드를 정의하면, 그다음 UI들(page.tsx, character-grid.tsx, chat-client.tsx)은 그걸 일관되게 사용할 수 있다.
  • 만약 나중에 상태 포맷이 바뀐다면 (예: enum으로 변경, 새 상태 추가), 데이터층 한두 곳만 수정하면 된다.

정보 노출의 일반 원칙

이런 작업을 하면서 항상 고민하는 부분들이 있다:

  • 노출 위치의 계층구조: 헤더나 카드의 "above the fold" 영역은 가장 중요한 정보를 담는다. 약혼·결혼 상태가 여기 들어갔다는 건 제품팀/기획팀이 이 정보를 충분히 중요하다고 판단했다는 뜻이다. 반대로 "설정 > 추가정보" 따위 깊은 곳에만 있다면, 굳이 여러 UI에서 중복 렌더링할 이유가 없다.

  • UI 컴포넌트 간 데이터 싱크: 홈카드, 그리드, 채팅 헤더 등 여러 곳에서 같은 상태를 보여줄 때, 혹시 한 곳에서는 "기혼" 다른 곳에서는 표시 안 되는 불일치가 생기지 않도록 주의해야 한다. 테스트 케이스를 몇 개 더 짜거나, UI 변경 시점에 한번 더 확인하는 습관이 생긴다.

  • 국제화 고려: 약혼·결혼 상태 레이블이 한국어라면, 다국어 지원 시 다른 언어로 번역 가능한 구조인지 미리 확인하는 게 좋다.

팀 관점에서의 의사결정

이 작업이 여러 파일을 건드린다는 건 코드리뷰할 때도 고려해야 할 게 많다는 뜻이다:

  • 데이터층 검수: user.ts에서 약혼·결혼 상태 필드가 제대로 정의됐는가? null 안전성은? 기본값은?
  • UI 일관성: 모든 카드/헤더에서 상태를 동일한 방식으로 표시했는가? 포맷, 색상, 아이콘 등이 통일돼 있는가?
  • 성능: 홈카드나 그리드에 많은 사용자가 나열될 때, 각 항목마다 상태를 조회하고 렌더링하는 과정이 병목이 되지 않는가?

코드 리뷰 때 이런 부분들을 체크리스트로 만들고, PR 설명에도 "왜 이 파일들을 함께 변경했고, 어떤 순서로 검수하면 좋을지" 정도를 적으면 팀원들이 훨씬 빠르게 이해할 수 있다.

배운 점과 다음 번

작은 기능 하나에도 "정보는 어디서 정의하고, 어디서 쓰고, 사용자 경험에 어떻게 반영할 건가"라는 큰 그림이 있다. 약혼·결혼 상태도 결국은 사용자를 신뢰할 수 있는 정보로 만들어주는 작업이고, 그게 UI 곳곳에 퍼져 있을 때 비로소 일관된 제품 경험이 된다.

다음에 비슷한 상태 정보(직업, 거주지, 관심사 등)를 추가할 일이 있다면, 이번에 만든 패턴을 그대로 따를 수 있을 것 같다. 데이터층 → 캐릭터 로직 → UI 컴포넌트들 순서로 체계적으로 진행하고, 각 계층에서 검증하는 식으로.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.