이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
개인 프로젝트에서 간단한 정산 기능을 기획할 때 원장 구조를 처음 고민했습니다. 처음에는 거래 내역을 단일 테이블에 모두 넣으려 했는데, 취소와 환불이 발생하면 어느 시점의 잔액이 정확한 잔액인지 추적이 어려워졌습니다. 찾아보니 이중 기입 원칙처럼 차변·대변 구조로 분리하면 모든 시점의 잔액을 재현할 수 있다는 점을 알게 됐습니다. 이 구조로 바꾸면서 취소 건도 새로운 거래 행으로 기록해 원본을 수정하지 않는 방식을 택했고, 정합성이 크게 개선됐습니다. 결제 원장 설계에서 중요하게 생각하는 것은 불변성(immutability)과 조회 성능 두 가지입니다. 원장은 한 번 기록된 행을 수정하지 않는 구조가 감사(audit) 추적에 유리하고, 인덱스 전략은 정산 주기와 조회 패턴에 맞게 설계되어야 한다는 점을 배웠습니다.
개인 프로젝트로 간단한 정산 기능을 기획할 때, 제가 직접 부딪힌 건 취소와 환불이 생기면 어느 시점의 잔액이 맞는지 추적이 안 된다는 점이었습니다. 처음엔 거래를 단일 테이블에 넣고 원본을 수정하려 했는데, 그러자 과거 잔액을 재현할 수 없었습니다. 그래서 저는 이중 기입 원칙처럼 차변·대변 구조로 나누고, 취소 건도 원본을 고치지 않고 새로운 거래 행으로 쌓는 방식으로 바꿨습니다. 그러자 모든 시점의 잔액을 재현할 수 있어 정합성이 크게 좋아졌습니다. 원장은 한 번 기록한 행을 수정하지 않는 불변 구조가 감사 추적에 유리하다는 걸 그때 배웠습니다. 다만 제 한계도 인정합니다. 모든 거래를 쌓기만 하면 잔액 조회를 위해 이벤트를 집계하는 비용이 커져, 불변성과 조회 성능 사이에 거래가 있습니다. 또 세무·정산 주기 요건을 DB 초기에 반영하는 건 실무 경험이 필요한데, 저는 작은 프로젝트 수준입니다. 그래서 원장 설계를 불변성과 조회 성능을 함께 저울질하는 일로 보려 합니다.
결제 원장과 DB 구조를 기획할 때 제가 의식하는 건 정합성과 성능이 부딪힌다는 점입니다. 원장은 차변·대변을 한 트랜잭션으로 묶는 이중 기입이 표준이라 정합성은 탄탄하지만, 거래가 몰리면 그 묶음을 처리하느라 성능 병목이 생깁니다. 또 모든 거래를 append-only로 쌓으면 감사 추적은 자연히 보장되지만, 잔액을 보려고 이벤트를 매번 집계하는 비용이 듭니다. 그래서 저는 어느 쪽도 공짜가 아니라는 걸 전제로, 조회 패턴과 정산 주기를 보고 정규화 수준이나 집계 방식을 정하는 게 핵심이라고 봅니다. 다만 제 한계도 인정합니다. 어느 거래량에서 락 경합이 실제 병목이 되는지, 이벤트 집계 비용이 감당 가능한지는 실제 규모를 다뤄 봐야 하는데 저는 작은 프로젝트로 원리를 익힌 단계입니다. 그래서 원장 설계를 한 원칙으로 닫지 않고, 정합성·성능·감사 사이의 거래를 조회 패턴에 맞춰 가르는 일로 보려 합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.