프로덕트를 만들다 보면 임시저장을 도입할지 고민하게 되는 순간이 오는데요. 블로그, SNS, CMS 등 콘텐츠를 다루는 서비스라면 거의 필수처럼 여겨지는 기능이기도 합니다. 저 또한 임시저장을 넣을지 말지 고민했었고, 그 당시 개발자분과 나눈 이야기를 기반으로 정리해보았습니다.

임시저장이란?

임시저장은 사용자가 작성 중인 글을 완성하지 않은 상태에서도 저장할 수 있는 기능입니다. 제목만 입력했거나, 본문 일부만 작성한 상태에서도 저장이 가능하죠. 즉, 필수 항목이 비어있어도(NULL) 저장되어야 한다는 게 핵심입니다.

만약 임시저장에도 엄격한 검증을 적용하면 NULL 문제는 해결되지만, 그렇게 되면 ‘임시’의 의미가 사라집니다. 사용자는 글을 완성해야만 저장할 수 있게 되니까요.

기본 구조 vs 임시저장 구조

임시저장 기능은 사용자 편의성 측면에서 유용해 보이지만, 개발과 운영 측면에서 상당한 복잡도를 야기합니다. 기본 CRUD 구조와 임시저장이 포함된 구조를 비교하면 그 차이가 명확해집니다.

임시저장 데이터를 어떻게 저장할 것인가?

임시저장을 구현할 때 크게 두 가지 선택지가 있습니다.

1. 같은 테이블에 status 컬럼으로 구분
   • 임시 / 확정을 상태값으로 구분해서 하나의 테이블에 저장
   • 테이블 구조는 단순하지만, NULL 값이 많은 레코드가 섞임
2. 별도 테이블로 분리
   • 임시저장 전용 테이블을 따로 생성
   • 확정 시 데이터를 다른 테이블로 이동시켜야 함

임시저장의 문제점

1. 임시 저장 데이터의 저장 및 처리 문제

임시생성과 임시수정은 검증을 거치지 않아 빠르게 처리됩니다. 그러나 이렇게 저장된 임시 데이터를 확정 저장(수정)하는 과정에서 문제가 발생합니다.

1. 기존 수정 프로세스에 2배에 달하는 소스코드가 필요
2. 임시 데이터를 확정 시 모든 검증을 재수행해야 하는 추가 로직 필수

2. 데이터 검색의 효율성 저하

검색 성능을 최적화하려면 검색 대상 컬럼에 NULL 값이 최소화되어야 합니다. 데이터가 증가할수록 NULL 값이 많은 테이블의 검색 속도는 기하급수적으로 느려지기 때문입니다.

임시저장 데이터는 대부분의 필수 항목이 NULL 값으로 존재할 가능성이 높습니다. 이는 데이터베이스 정규화를 실패하게 만들고, 데이터 증가에 따라 검색 성능이 우상향 곡선으로 악화됩니다.

임시저장을 같은 테이블에 저장하면 테이블 분리로 인한 추가 문제는 발생하지 않습니다. 하지만 관리자 페이지에서 확정 글과 임시저장 글을 완전히 별도 페이지로 구현해야 하므로 개발 비용이 증가합니다.

정리하면

임시저장 기능을 최소화해야 하는 이유는 크게 두 가지입니다.

1. 데이터베이스의 정규화 및 성능 문제

   NULL 값 과다로 인한 구조적 비효율과 검색 성능 저하

2. 개발 복잡도 증가

   추가 API 생성 및 확정 전환 시 필요한 검증 로직으로 인한 작업 시간 증가

그렇다면 어떻게 해야할까?

임시저장을 꼭 구현해야 한다면, 최소한 이런 방법들을 고려할 수 있습니다.

1. 로컬 스토리지 우선 활용

   서버에 저장하지 않고 브라우저에 임시 데이터를 저장합니다. 개발 복잡도를 크게 줄일 수 있지만, 기기 간 동기화가 불가능합니다.

2. 보관 기간 제한

   7일 이상 된 임시저장 데이터는 자동 삭제하여 데이터베이스 부담을 줄입니다.

하지만 가장 중요한 건, 임시저장이 정말 필요한 기능인지부터 판단하는 것입니다. 겉보기엔 간단해 보이는 기능 하나가 시스템 전체에 미치는 영향은 생각보다 훨씬 크다는 것입니다. 기능을 추가하는 것만큼, 추가하지 않는 결정도 중요합니다.