백업 시스템에 계속 막히는 이유, 'SSOT는 DB 하나로'

더배러 방 낮 시간에는 한 참여자의 시스템 설계 고민이 화두로 떠올랐다. 문서-백업 구조를 직접 구현하려다 계속 막힌다는 토로였다. 이를 지켜본 다른 참여자는 "백업기능 구현이 어려운거였군요.. 토큰먹는 하마에요"라며 공감했다. 백업 로직 자체가 생각보다 복잡해 AI에게 맡겨도 상당한 토큰을 소모하는 작업이었다는 뜻으로 읽힌다.

논의는 이내 근본적인 설계 방향에 대한 조언으로 옮겨갔다. 한 참여자가 "어차피 db에 기록되는 거 아닌가용?"이라고 되묻자, 다른 참여자는 좀 더 단정적으로 정리했다. "그러면 잘못된 설계가 맞긴 합니다 source of truth는 db 하나로만 구성해야 유지관리가 가능해집니다"라는 답이었다. 백업 대상이 여러 갈래로 흩어져 있는 구조 자체가 문제의 근원이며, 진실의 기준점을 DB 하나로 좁혀야 관리가 가능해진다는 취지였다.

이 조언에 이어 좀 더 구체적인 아키텍처 원칙도 공유됐다. 한 참여자는 "이렇다는데, 일단 유튜브 보죠..ㅎ"라며 참고 자료를 소개하는 동시에, "Single Logical Source of Truth = DB Binary Storage = Object Storage 결속 = ID + Version + Hash"라는 구조를 함께 제시했다. DB가 논리적 진실의 기준이 되고, 실제 바이너리 데이터는 별도의 오브젝트 스토리지에 두되 ID·버전·해시로 서로를 엮는 방식이다.

이 대화는 단순한 백업 기능 구현을 넘어, 데이터가 여러 곳에 흩어질 때 발생하는 근본적인 설계 문제를 짚었다는 점에서 의미가 있다. 백업 기능 자체가 "토큰먹는 하마"로 표현될 만큼 AI에게도 부담스러운 작업이었다는 점은, 잘못된 아키텍처가 개발 비용을 눈에 띄게 늘린다는 사실을 시사한다. 진실의 기준을 하나의 DB로 모으고, 실제 파일·이미지 같은 무거운 데이터는 별도 스토리지에 두되 ID·버전·해시로 연결하는 구조는, 이날 대화에서 나온 조언들이 자연스럽게 수렴한 결론으로 보인다. 백업을 여러 군데서 따로 관리하려다 막힌 경험이, 결국 시스템 설계 원칙 자체를 다시 세우는 계기가 된 셈이다.

이 대화가 흥미로운 지점은, 처음 고민을 나눈 참여자가 곧바로 정답을 받은 것이 아니라 스스로도 "어차피 db에 기록되는 거 아닌가용?"이라는 되물음을 통해 문제를 재확인하는 과정을 거쳤다는 점이다. 이 되물음에 대한 답이 "잘못된 설계가 맞다"는 명확한 진단으로 돌아오면서, 막연했던 어려움이 구체적인 설계 원칙 부재로 정리됐다. 여러 소스에 데이터를 흩어 두고 그때그때 동기화를 신경 쓰는 방식은, 초기에는 간단해 보여도 유지관리 단계에서 반드시 비용을 치르게 된다는 점을 이 대화는 다시 한번 확인시켜준 셈이다.