실수로 DELETE 날린 그 순간을 위한 데이터베이스
DB 운영하다가 WHERE 절 빼먹고 UPDATE 날려본 적 있으신가요? 아니면 스테이징인 줄 알고 프로덕션에 마이그레이션을 돌렸다거나요. 이런 사고는 누구에게나 일어나고, 그 순간부터 몇 시간짜리 복구 작업이 시작되죠. EterDB는 이 문제를 정면으로 겨냥한 프로젝트예요. PostgreSQL을 포크해서 '사고가 났을 때 되돌리는 걸 쉽게' 만드는 데 초점을 맞췄다고 소개하고 있거든요.
먼저 '포크'가 뭔지 짚을게요. 오픈소스 프로젝트의 코드를 복사해서 별도의 방향으로 발전시키는 걸 포크라고 해요. Postgres는 확장(extension) 시스템이 잘 되어 있어서 대부분의 기능은 확장으로 붙이는데, 저장 엔진이나 트랜잭션 처리처럼 코어 깊숙한 부분을 바꿔야 하면 포크를 하게 돼요. EterDB가 포크를 택했다는 건, 그만큼 내부를 손봐야 하는 기능이라는 뜻이기도 하고요.
기존 Postgres에서 복구가 왜 고통스러운가요
Postgres에는 원래 PITR(Point-In-Time Recovery)이라는 기능이 있어요. 이게 뭐냐면, 특정 시점으로 DB를 되돌리는 기능인데요. 원리는 이래요. Postgres는 모든 변경 사항을 WAL(Write-Ahead Log)이라는 로그 파일에 순서대로 기록해요. 그래서 '어제 새벽에 떠둔 전체 백업' 위에 '그 이후의 WAL'을 사고 직전 시점까지만 재생하면 그 시점의 DB가 복원되는 거죠.
문제는 이 과정이 실무에서 정말 번거롭다는 거예요. 전체 백업을 다른 서버에 풀어야 하고, WAL을 시간 순으로 재생하는 데 데이터 크기에 따라 수십 분에서 몇 시간이 걸려요. 그렇게 만든 복원본에서 잘못된 테이블만 골라서 다시 프로덕션으로 옮겨야 하고요. 그 사이에 들어온 정상 트랜잭션은 어떻게 할 건지도 고민해야 해요. 게다가 '정확히 몇 시 몇 분에 사고가 났는지'를 모르면 시점을 잡는 것부터 헤매게 되죠. AWS RDS 같은 관리형 서비스도 PITR을 제공하지만, 결국 새 인스턴스를 하나 통째로 띄우는 방식이라 빠르지 않아요.
재미있는 건 Postgres가 원래 '타임 트래블' 기능을 갖고 있었다는 사실이에요. 1990년대 초기 버전에는 과거 시점의 데이터를 조회하는 기능이 있었는데, 성능과 저장 공간 문제로 6.2 버전에서 빠졌어요. 지금도 Postgres는 MVCC 구조 덕분에 업데이트된 행의 이전 버전을 VACUUM이 치우기 전까지는 디스크에 남겨두거든요. 그래서 pg_dirtyread 같은 확장으로 방금 지운 데이터를 긁어내는 꼼수도 있는데, 이건 어디까지나 운이 좋을 때 얘기고 정식 기능이 아니에요.
EterDB가 노리는 지점
EterDB가 정확히 어느 방식으로 구현했는지는 공식 문서를 봐야 하지만, 이런 '복구 친화적 DB'가 취하는 접근은 보통 두 갈래예요. 하나는 과거 버전을 지우지 않고 보존해서 특정 시점의 데이터를 바로 쿼리하고 그 시점으로 즉시 되돌릴 수 있게 하는 방식이에요. Oracle의 Flashback이 이 계열이죠. 다른 하나는 스토리지를 스냅샷과 브랜치 단위로 관리해서, 사고 직전 시점의 브랜치를 순식간에 만들어내는 방식이에요. Neon이 이 방향을 대표하고요.
어느 쪽이든 핵심 가치는 같아요. '백업에서 복원'이라는 몇 시간짜리 작업을 '몇 분 전으로 되돌리기'라는 몇 초짜리 명령으로 바꾸는 것. 그리고 전체 DB가 아니라 특정 테이블이나 특정 행만 골라서 되돌릴 수 있게 하는 것. 사고 대응에서 제일 중요한 건 복구 시간(RTO)인데, 이걸 극적으로 줄이겠다는 거죠.
비슷한 시도들과 비교하면
이 분야는 요즘 꽤 뜨거워요. Neon은 Postgres의 스토리지 계층을 분리해서 브랜칭과 시점 복원을 제공하고, Databricks에 인수되기도 했죠. Supabase는 관리형 PITR을 제공하고요. Dolt는 아예 git처럼 커밋과 브랜치가 있는 SQL DB를 표방해요. PlanetScale은 MySQL 쪽에서 스키마 변경을 브랜치로 관리하고 되돌리는 걸 강조하고요.
EterDB의 차별점은 '관리형 서비스'가 아니라 '직접 띄울 수 있는 Postgres 포크'라는 데 있어 보여요. Neon이나 Supabase의 복구 기능은 그 회사 클라우드를 써야 얻을 수 있는데, 포크라면 온프레미스나 자체 인프라에서도 쓸 수 있으니까요. 대신 포크의 숙명적인 단점도 있어요. Postgres 본가가 새 메이저 버전을 낼 때마다 따라가야 하고, 인기 확장(PostGIS, pgvector 등)이 제대로 도는지 검증해야 하고, 무엇보다 프로젝트가 오래 유지될지 믿을 수 있어야 하죠. 초기 단계 프로젝트라 이 부분은 아직 지켜봐야 해요.
한국 개발자라면
당장 프로덕션을 EterDB로 바꾸는 건 권하기 어려워요. 다만 두 가지는 지금 해볼 만해요. 첫째, 우리 팀의 복구 절차를 실제로 연습해보기. 백업이 있다는 것과 그걸로 30분 안에 복구할 수 있다는 건 완전히 다른 얘기거든요. 둘째, 사이드 프로젝트나 개발 환경에 EterDB를 띄워보고 '실수 후 되돌리기'가 실제로 어떤 경험인지 체험해보기. 이런 도구를 써보면 사고 대응에 대한 기준 자체가 올라가요.
그리고 RDS나 Aurora를 쓰는 팀이라면 이미 갖고 있는 PITR과 스냅샷 기능을 제대로 이해하고 있는지, 복구에 실제로 몇 분이 걸리는지 한 번쯤 재보세요. 사고는 항상 준비 안 된 순간에 오니까요.
정리하며
한 줄 요약: 사고는 막을 수 없고, 얼마나 빨리 되돌리느냐가 실력이에요. EterDB는 그 '되돌리기'를 DB의 기본 기능으로 만들려는 시도예요.
여러분 팀은 프로덕션 DB 사고가 났을 때 복구까지 몇 분 걸리는지 알고 계세요? 최근에 겪은 DB 사고와 그때 배운 교훈이 있다면 공유해주세요.
🔗 출처: Hacker News