운영 데이터베이스에서 잘못된 쓰기 하나가 발생했을 때, 실무자가 마주하는 선택지는 대개 두 가지다. 그냥 두고 손으로 데이터를 고치거나, 백업 시점으로 전체를 되감는 것이다. 전자는 어떤 행이 얼마나 오염됐는지 정확히 알기 어렵고, 후자는 그 사이에 쌓인 정상 트랜잭션까지 함께 날아간다. 최근 Show HN에 공개된 EterDB는 이 지점을 겨냥한다. PostgreSQL 18을 기반으로 한 포크로, '트랜잭션 단위 되돌리기(undo)'를 내세운다. 데이터베이스 전체가 아니라 문제가 된 트랜잭션 하나만, 그것도 서비스가 살아 있는 상태에서 되돌리겠다는 것이 핵심 주장이다.
무엇을 풀려는 도구인가
제작자가 든 사례는 실무에서 흔한 사고들이다. 어떤 필터 조건이 의도보다 넓게 걸려서 테스트용 공급업체를 지우려다 실제 공급업체까지 함께 삭제된 경우, EterDB는 사라진 바로 그 행들을 모든 컬럼값이 온전한 상태로 복원한다고 설명한다. 또 다른 예는 마이그레이션이 컬럼을 드롭했는데 여전히 그 컬럼을 읽는 코드가 남아 있는 상황이다. 이때도 전체 복원이나 다운타임 없이 마이그레이션 이전의 컬럼과 값을 되살린다고 한다. 공통점은 '되돌리는 범위를 사고가 건드린 데이터로 좁힌다'는 발상이다.
가장 눈에 띄는 부분은 읽기 의존성 추적이다. 나쁜 값이 한 번 기록되면, 이후의 다른 트랜잭션들이 그 값을 읽고 나름의 결론을 계산해 또 다른 쓰기를 만들어낸다. 오염이 연쇄적으로 번지는 것이다. EterDB는 읽기를 추적하기 때문에 어떤 쓰기가 문제의 값에 의존했는지 알 수 있고, 그 쓰기들을 함께 되돌리거나, 되돌리지 않을 경우 무엇이 어긋나는지를 보여준다고 설명한다. 백업은 이런 선택지가 없다. 전부 되감는 것 외에는 방법이 없기 때문이다. 이 차이가 EterDB가 스스로를 백업과 구분 짓는 지점이다.
어떻게 동작한다고 말하는가
기술적으로는 두 축이 언급된다. 하나는 행 버전(row versions)이다. 포스트그레스는 원래 MVCC 구조에서 갱신·삭제 시 이전 버전을 즉시 없애지 않고 유지한다. EterDB의 되돌리기와 시간 여행(time travel) 기능은 이런 버전 이력을 붙잡아 두는 방향의 확장으로 읽힌다. 다른 하나가 앞서 말한 읽기 의존성 캡처다. 어떤 트랜잭션이 어떤 값을 읽었는지까지 기록해 두어야 연쇄 오염을 계산할 수 있다. 다만 공개된 설명은 '행 버전에서 읽기 의존성 캡처까지'라는 큰 얼개만 제시할 뿐, 그 이력을 얼마나 오래 보관하는지, 저장 공간과 쓰기 성능에 어떤 부담을 주는지에 대한 구체적 수치는 담겨 있지 않다.
라이선스와 배포 방식은 채택 문턱을 낮추려는 의도가 읽힌다. 엔진과 eter CLI는 아파치 2.0 라이선스이며, 스토리지와 시간 여행 기능까지 포함된다고 한다. 시험 방법도 단순하다. docker compose up으로 띄운 뒤 자기 데이터베이스에서 살아 있는 트랜잭션을 직접 되돌려 보라는 것이다. 별도 계정이나 클라우드 가입 없이 로컬에서 동작을 확인할 수 있다는 점은 실무자 입장에서 부담 없이 만져 볼 이유가 된다.
실무자가 따져 봐야 할 것
발상은 매력적이지만, 도입 판단은 냉정할 필요가 있다. 읽기까지 추적한다는 것은 곧 모든 읽기에 대한 메타데이터를 어딘가에 남긴다는 뜻이고, 이는 쓰기 위주 워크로드에서 상당한 오버헤드로 이어질 수 있다. 이력을 얼마나 오래 유지하느냐에 따라 되돌릴 수 있는 시간 창과 저장 비용이 정비례로 늘어난다. 사고가 난 지 며칠 뒤에 발견된 경우에도 되돌릴 수 있는지는 결국 이 보관 정책에 달려 있는데, 현재 공개된 정보만으로는 그 경계를 알 수 없다.
또한 포스트그레스 '포크'라는 점은 양날의 검이다. 본가 포스트그레스가 버전을 올릴 때마다 이 포크가 얼마나 빠르게 따라오는지, 확장(extension)이나 복제 구성과 어떻게 맞물리는지가 장기 운영의 관건이 된다. 아파치 2.0으로 코드가 열려 있어 검증과 자체 운영이 가능하다는 점은 분명한 강점이지만, 프로덕션의 결정적 데이터를 맡기려면 되돌리기 자체가 트랜잭션 정합성을 깨지 않는지, 연쇄 되돌리기가 제약 조건과 외래키를 어떻게 다루는지 등을 직접 실험으로 확인해야 한다. EterDB의 진짜 가치는 결국 사고가 났을 때 '전부 아니면 전무' 대신 '건드린 만큼만' 되돌린다는 선택지를 준다는 데 있으며, 그 선택지가 자신의 워크로드에서 실제로 작동하는지는 docker compose 한 줄로 시작하는 검증에서 판가름 난다.