서비스를 구축하다 보면 사용자의 결제나 예약 내역을 보여줘야 하는 순간이 반드시 찾아옵니다. 이때 흔히 간과하는 것이 바로 '정보를 보여주는 화면'과 '액션을 수행하는 화면'의 분리입니다.
이번 글에서는 사용자의 거래 상세 내역을 읽기 전용으로 제공하는 viewTransaction 패턴의 개념과 설계 기준, 그리고 올바른 활용 방법에 대해 정리해 보겠습니다.
viewTransaction이란 무엇인가?
viewTransaction은 사용자의 거래 내역 또는 특정 거래의 상세 정보를 읽기 전용(Read-only)으로 확인할 수 있도록 설계된 UI 패턴입니다.
여기서 말하는 '거래(Transaction)'란 사용자의 개인적인 활동 이력을 뜻하며, 일반적으로 다음과 같은 항목들을 포함합니다.
-
결제 완료 내역
-
예약 완료 내역
-
상품 구매 내역
-
환불 또는 취소 이력
-
외부 서비스 연동으로 생성된 정산 및 승인 기록
⚠️ 주의할 점 viewTransaction은 철저히 '조회'를 위한 기능입니다. 결제를 시작하는 버튼이나 예약을 생성하는 폼, 혹은 마케팅을 위해 공개 페이지에 노출하는 콘텐츠 카드와는 명확히 구분되어야 합니다.
언제 사용해야 하는가?
이 패턴은 주로 사용자가 자신의 개인 이력을 조회하고 상태를 확인해야 하는 맥락에서 사용됩니다.
-
결제/예약 완료 직후: 사용자가 방금 완료한 거래의 상세 내역을 다시 확인하고자 할 때 (예: 결제 성공 화면의 "거래 상세 보기" 버튼)
-
개인 대시보드(마이페이지): 사용자가 자신의 활동 이력을 모아보는 흐름 (예: 거래 요약 카드, 전체 거래 목록 조회)
-
알림 및 고객지원 흐름: 특정 거래의 상태 변경(예: "예약 확정", "환불 처리 완료")을 알리는 메시지를 클릭했을 때 해당 내역으로 딥링크 진입
-
거래 상태 검증: 사용자가 실제로 결제한 수단, 금액, 현재 진행 상태, 영수증, 외부 승인 번호 등을 직접 확인해야 할 때
Anti-Patterns에 대해서도 알아보자
viewTransaction을 잘못 배치하면 정보 구조가 무너지고 보안 문제가 발생할 수 있습니다. 다음의 경우에는 사용을 피해야 합니다.
-
메인 홈 등 공개 콘텐츠 영역: 거래 정보는 개인 데이터입니다. 로그인 전 사용자에게 노출되거나, 누구나 볼 수 있는 탐색형 피드(기사, 상품 카드 등)와 동일한 패턴으로 섞어서 배치하면 안 됩니다.
-
결제 생성 액션의 대체재: 이 기능은 "보기" 기능입니다.
startCheckout이나payNow와 같은 트랜잭션 발생 로직과 혼동하거나 결합하여 설계하지 마세요.
viewTransaction 사용 시 핵심 UX 설계 규칙
viewTransaction을 구현할 때 반드시 지켜야 할 UX 원칙 5가지는 다음과 같습니다.
-
읽기 전용이 기본: 내역 자체는 수정할 수 없는 읽기 전용으로 제공하되, 추가 액션이 필요하다면 UI상에서 명확히 분리된 버튼으로 제공합니다.
-
강력한 인증: 철저히 로그인된 사용자 본인의 거래만 조회할 수 있어야 합니다. 세션이 없다면 로그인으로 리다이렉트하고, 타인의 ID 접근은 API 단에서 차단해야 합니다.
-
명확한 상태 표시: 텍스트와 색상에만 의존하지 말고, 명확한 상태 라벨(배지)을 제공하세요. (예:
완료,처리 중,실패,환불 완료) -
외부 링크의 분리: 외부 PG사의 영수증이나 예약처 링크가 있다면, 내부 서비스의 화면 내에서 인라인으로 보여주기보다 새 창으로 열리도록 분리하는 것이 혼선을 줄입니다.
-
엣지 케이스(Edge Cases) 대비: 로딩 상태, 거래 내역이 없는 빈 화면(Empty State), 접근 권한 없음, 네트워크 오류 등에 대한 대응 UI를 반드시 마련해야 합니다.