임시 저장의 의미로 상태와 별도 저장소 선택하기

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

’임시 저장’은 사용자 경험을 설명하지만 그 데이터가 도메인에서 무엇인지는 알려주지 않는다. 결제 전의 평범한 주문일 수도 있고, 완성된 주문에는 없는 필드와 규칙을 가진 준비 데이터일 수도 있다.

테이블 설계보다 이 구분이 먼저다. 임시 저장이 생명주기의 앞 단계라면 본 레코드의 상태로 표현하는 편이 자연스럽다. 별도 비즈니스 개념이라면 최종 테이블에 억지로 넣을수록 nullable 필드와 중간 단계 전용 데이터가 본 모델에 퍼질 수 있다.

생명주기의 한 단계라면 본 레코드에 둔다

상품과 수량을 이미 담았고 사용자가 결제로 넘어가기만 기다리는 주문서를 생각해보자. 레코드는 주문으로 존재하며 상태만 아직 다음으로 진행되지 않았다. 화면에서 임시 저장이라고 불러도 다른 개념이 되는 것은 아니다.

이 경우 주문 테이블에 주문 전 또는 대기 상태를 두면 하나의 스키마로 전체 생명주기를 표현할 수 있다. 주문 스펙이 바뀌어도 같은 구조가 이전 단계와 이후 단계를 함께 설명한다. 구분되는 도메인 이유가 없는데 임시 주문, 임시 상세, 임시 메타 테이블을 한 벌 더 만들면 스키마 작업만 중복된다.

준비 데이터가 다르면 별도 개념이 될 수 있다

임시 단계에 준비할 때만 쓰는 정보가 있다면 다른 설계가 가능하다. 여러 단계를 거치며 완성되지 않은 값을 모으고, 중간 절차를 위해 멈춘 뒤, 나중에 최종 주문을 만드는 흐름이 있을 수 있다. 이 데이터는 아직 완성 객체와 형태도 의미도 같지 않다.

비슷한 사례에서는 준비 데이터를 별도 테이블의 버전이 있는 JSON으로 저장했다. 이후 그 표현을 불러와 파싱한 뒤 최종 레코드를 만들었다. 최종 구조와 대응하는 테이블을 모두 복제하지 않으면서 준비 단계에만 필요한 필드가 주문 데이터에 섞이는 것을 피한 방식이다.

물리적인 분리보다 논리적인 분리가 먼저다. ’준비된 주문’과 ’주문’이 실제로 다른 개념이어야 한다. 화면에 임시 저장 버튼이 있다는 이유만으로 별도 테이블이 필요해지는 것은 아니다.

유연한 저장은 호환 비용을 다른 곳으로 옮긴다

버전이 있는 JSON 표현은 최종 모델에 필드가 추가될 때 여러 임시 테이블을 함께 고치는 일을 줄일 수 있다. 대신 파싱과 버전 호환을 코드가 떠안는다. 오래된 임시 데이터에 만료가 없다면 애플리케이션은 과거 표현을 오랫동안 이해해야 할 수 있다.

임시 데이터가 중요한 정보일수록 이 부담은 더 불편해질 수 있다. 유연한 컬럼이 자동으로 단순한 선택이 되는 것은 아니다. 눈에 보이는 스키마 중복을 버전과 불완전한 형태를 해석하는 코드로 바꾸는 선택이다.

결국 이 서비스에서 임시 저장이 어떤 의미인지, 준비 데이터가 얼마나 다른지, 얼마나 오래 다시 불러와야 하는지가 판단 기준이다. 하나의 생명주기라면 상태가 맞고, 준비 단계에 고유한 정보와 행동이 있다면 별도 저장을 검토할 수 있다. ’임시 저장’이라는 이름만으로는 답을 고를 수 없다.