개발자는 지난 10여 년 동안 데이터베이스의 존재를 잊으려 노력했다. 물론 데이터베이스를 문자 그대로 배제한 것은 아니다. 여전히 페타바이트 단위의 데이터를 저장하고 있다. 다만 대부분 개발자는 데이터베이스를 점차 구현 세부 사항으로 인식하기 시작했다. 필수적이지만 변화가 없는 유틸리티 계층으로 취급되면서, 가능한 한 깊이 고민하지 않으려 애써 온 대상이 된 것이다.

개발자는 ORM(object-relational mappers) 뒤로 데이터베이스를 추상화했고, API로 감싸 내부를 드러내지 않도록 했다. 반정형 객체를 컬럼에 밀어 넣으며 이를 유연한 구조라고 스스로 합리화하기도 했다. 데이터 영속성은 이미 해결된 문제라고 여기며, 시스템 전반을 분리하는 방향으로 설계를 전개했다. 검색이 필요하면 별도의 검색 시스템을 붙였고, 캐싱이 필요하면 캐시를 도입했다. 문서는 문서 저장소를 사용했고, 관계 표현이 필요하면 그래프 데이터베이스를 추가했다. 이러한 선택이 영리한 접근이라고 생각했지만, 실제로는 데이터베이스 엔진이 담당하던 복잡성을 접착 코드와 데이터 파이프라인, 운영 부담으로 떠넘긴 셈이었다.

AI의 등장은 그동안의 접근 방식이 지닌 아키텍처적 취약성을 여과 없이 드러냈다.

AI가 적용된 애플리케이션 환경에서 데이터베이스는 더 이상 수동적인 기록 저장소에 머물지 않는다. 확률적 모델과 시스템의 기준 데이터 사이를 잇는 능동적인 경계로 역할이 바뀐다. 인상적인 데모와 미션 크리티컬 시스템을 가르는 요소는 대체로 LLM 자체가 아니다. 어떤 맥락을 얼마나 잘 가져올 수 있는지, 그 맥락이 얼마나 일관성을 유지하는지, 그리고 이를 얼마나 빠르게 조합할 수 있는지가 결정적인 차이를 만든다.

AI는 데이터베이스를 다시 전면에 등장시켰다. 갑자기 SQL을 다시 사랑하게 된 것은 아니지만, AI의 메모리 문제 역시 또 하나의 데이터베이스 문제라는 사실을 인식하게 됐다. 데이터베이스는 더 이상 데이터가 존재하는 장소에 그치지 않는다. 맥락이 구성되는 공간이 됐고, AI 환경에서 맥락은 모든 것을 좌우하는 핵심 요소로 자리 잡고 있다.

일관성과 환각 문제

우리가 왜 이런 어려움에 직면했는지를 이해하려면, 지금에 이르기까지의 과정을 돌아볼 필요가 있다. 지난 10년 동안 우리는 데이터베이스를 제거한 것이 아니다. 오히려 데이터베이스를 더 늘려왔다.

현대적인 애플리케이션 설계는 데이터베이스의 한계를 우회하는 방식을 가르쳐 왔다. 캐시를 구축하고, 검색 클러스터를 도입했으며, 스트림 프로세서를 추가하고, 특정 목적에 맞춘 각종 저장소를 뒤섞어 사용했다. 5개에 달하는 ‘최고의 조합’ 시스템을 엮는 이른바 ‘폴리글랏 퍼시스턴스(polyglot persistence)’가 아키텍처적 진보라고 스스로를 설득했다. 그러나 현실에서는 데이터베이스 엔진이 처리하던 복잡성을 애플리케이션 코드로 떠넘긴, 이력서 중심의 개발에 가까운 선택이 대부분이었다.

이 방식은 ‘최종적 일관성(eventual consistency)’이 허용되던 시기에는 작동했다. 하지만 AI 환경에서는 전혀 통하지 않는다.

실제 검색 증강 생성(retrieval-augmented generation, RAG) 파이프라인을 떠올려보면, 단순히 ‘벡터를 가져오는 것’만으로 끝나는 경우는 거의 없다. 기업 환경에서 운영되는 AI 워크플로우에는 의미적 유사성을 찾기 위한 벡터 유사도 검색, 실제 콘텐츠를 불러오기 위한 문서 검색, 권한이나 계층 구조와 같은 관계를 이해하기 위한 그래프 탐색, 그리고 데이터가 최신 상태인지 확인하기 위한 시계열 분석이 함께 필요하다. 지난 10년간 이어져 온 ‘볼트온’ 아키텍처에서는 이러한 요구를 충족하기 위해 벡터 데이터베이스, 문서 저장소, 그래프 데이터베이스, 시계열 시스템 등 각기 다른 전문 서비스를 조합하는 방식으로 구현해 왔다.

이런 볼트온 아키텍처는 이상적인 구조는 아니었지만, AI가 등장하기 전까지는 치명적인 문제로 인식되지는 않았다. 그러나 이 구조에서는 흐름도에 표시된 화살표 하나하나가 모두 네트워크 홉을 의미하고, 홉이 늘어날수록 직렬화에 따른 오버헤드가 누적된다. 여기에 더해, 각각의 분리된 시스템은 저마다 다른 일관성 모델을 도입한다. 하나의 논리적 맥락으로 처리돼야 할 정보를 여섯 개의 물리적 시스템으로 쪼개는 순간, 복잡성, 지연 시간, 그리고 불일치라는 비용을 동시에 떠안게 된다. AI는 이러한 비용에 특히 민감하게 반응한다.

일반적인 웹 애플리케이션에서 오래된 데이터가 표시될 경우, 사용자는 몇 초 동안 이전 재고 수치를 보게 되는 정도에 그친다. 하지만 AI 에이전트가 일관되지 않은 맥락을 가져오는 상황에서는 문제가 전혀 다른 양상으로 전개된다. 예를 들어, 벡터 검색 결과가 이미 관계형 데이터 저장소에서 업데이트된 문서를 가리키고 있다면, AI는 잘못된 전제를 바탕으로 그럴듯한 서사를 구성하게 된다. 이를 흔히 환각이라고 부르지만, 많은 경우 모델이 없는 내용을 지어내는 것은 아니다. 분절된 데이터베이스 아키텍처로 인해 오래된 데이터가 입력으로 전달되고 있을 뿐이다. 검색 인덱스가 기준 시스템과 최종적 일관성만을 유지하고 있다면, AI 역시 결국 환각하게 되는 구조에 놓이게 된다.

트랜잭션 시스템이 기준 데이터의 출처라고 하더라도, 벡터 인덱스가 비동기적으로 업데이트된다면 에이전트의 메모리에는 시간 지연이 내재된다. 관계형 데이터가 파이프라인을 통해 동기화되면서 점차 어긋날 수 있다면, 에이전트는 더 이상 유효하지 않은 관계를 여전히 사실로 인식하게 된다. 권한 검사는 한 시스템에서 이뤄지고 콘텐츠는 다른 시스템에서 가져오는 구조라면, 단 하나의 버그만으로도 데이터 유출로 이어질 수 있는 위험한 상태가 된다.

이 문제는 수동적인 챗봇에서 능동적인 에이전트로 넘어갈수록 더욱 심각해진다. 차세대 AI는 단순히 텍스트를 요약하는 수준을 넘어 실제 작업을 수행할 것으로 기대된다. 그러나 작업을 수행한다는 것은 곧 트랜잭션을 처리해야 한다는 의미다.

예를 들어 에이전트가 고객 기록을 업데이트하고(관계형 데이터), 선호도 프로필을 다시 인덱싱하며(벡터), 상호작용 내역을 로그로 남겨야 한다면(문서), 데이터베이스 아키텍처는 서로 다른 세 시스템에 대한 쓰기 작업을 조율하기 위해 사가 패턴을 요구하게 된다. 이 구조는 곧 취약성을 만들어내는 장치가 된다. 분절된 스택 환경에서는 워크플로우가 중간 단계에서 실패할 경우, 에이전트가 인식하는 세계 자체가 손상된 상태로 남게 된다. 메모리 전체에 걸쳐 원자성, 일관성, 격리성, 지속성으로 구성된 ACID 보장을 신뢰할 수 없다면 신뢰할 수 있는 에이전트를 구축하는 것은 불가능하다.

이는 AI 자체의 문제가 아니다. 근본적으로는 아키텍처의 문제다. 앞서 언급했듯 신뢰할 수 없는 데이터 인프라 위에서는 신뢰할 수 있는 에이전트를 만들 수 없다. 에이전트의 신뢰성을 확보하는 작업은 데이터베이스 작업과 분리될 수 없는 관계에 있다.

아키텍처적 제약

수년 동안 개발자는 성능이 충분히 좋다는 수준에 만족해 왔다. 쿼리가 느리면 노드를 추가해 수평 확장을 하면 된다고 여겼기 때문이다. 그러나 AI 워크로드는 연산 집약적이며, 데이터 구조에 내재된 물리적 특성이 다시 중요해지는 국면에 접어들었다.

예를 들어 JSON 문서를 읽는 단순한 작업을 살펴보자. 일부 널리 사용되는 문서 저장소에서는 내부 바이너리 포맷 특성상 필드를 순차적으로 스캔해야 한다. 이는 O(n) 연산이다. 대형 문서의 끝에 있는 필드를 찾으려면, 그 이전의 모든 내용을 훑어야 한다는 의미다. 이런 방식은 간단한 콘텐츠 관리 시스템에서는 작동할 수 있지만, 엔터프라이즈 규모에서는 전혀 통하지 않는다. 예컨대 바이럴 이벤트로 초당 10만 건의 요청이 몰리는 상황에서는 나노초 단위의 지연이 누적되며 문제가 된다. 이 정도 규모에서 O(n) 스캔은 데이터 파싱에만 수십 개의 CPU 코어를 낭비하게 만든다. 반면 최신 바이너리 포맷은 해시 인덱스를 활용한 탐색 방식을 적용해 특정 필드로 O(1)에 접근할 수 있도록 설계돼 있다. 이를 통해 대규모 문서의 깊은 구조를 탐색하는 작업에서도 최대 500배 이상의 성능 향상을 제공한다.

이는 미세한 최적화의 문제가 아니다. 근본적인 아키텍처 제약에 해당한다. “고작 나노초 차이”라는 말은 사용자 경험을 좌우할 만큼의 지연이 발생하는 규모에서 시스템을 운영해 보지 않았을 때 나오는 인식이다. 추론 자체가 이미 느린 AI 환경에서는 비효율적인 알고리즘적 기반 때문에 데이터베이스가 추가적인 지연을 만들어내는 여유는 없다.

인프라를 직접 만들려는 시도를 멈춰라

전문화된 도구가 설 자리가 없다는 뜻은 아니다. 문제는 지난 10년 동안 우리가 5개의 전문 시스템을 조합하면 하나의 범용 시스템보다 더 단순한 구조를 만들 수 있다고 가정해 왔다는 데 있다. AI 환경에서 던져야 할 질문은 “어떤 데이터베이스가 벡터 검색을 지원하는가”가 아니다. 진짜 질문은 “맥락은 어디에 존재하는가, 그리고 그 맥락을 조합하기 위해 얼마나 많은 일관성 경계를 넘고 있는가”다.

그 답이 “많다”라면, 이는 곧 인프라를 직접 구축하겠다는 선택과 다르지 않다. 데이터 파이프라인을 만들고, 재시도 로직을 설계하며, 정합성을 맞추기 위한 조정 로직과 지연을 감시하는 모니터링 체계를 구축하게 된다. 그리고 언젠가는 그 지연을 정상적인 상태로 받아들이게 될 것이다.

대안은 데이터 모델을 물리적 필연으로 취급하는 관점을 버리는 데 있다. 과거에는 그래프가 필요하면 데이터를 그래프 데이터베이스로 복사했고, 벡터가 필요하면 벡터 저장소로 데이터를 옮겼다. 그러나 이러한 복사 자체가 동기화 문제를 낳는 근본적인 원인이다.

과학적인 접근 방식은 데이터를 하나의 정본 형태로 두고, 애플리케이션이 필요로 하는 다양한 형태로 이를 투영하는 데서 출발한다. 관계를 따라 탐색해야 한다면 데이터베이스는 그래프 뷰를 제공해야 하고, 의미 기반 검색이 필요하다면 벡터 뷰를 제공해야 한다. 중요한 점은 이들이 파이프라인을 통해 따로 복사된 데이터여서는 안 된다는 것이다. 하나의 단일한 기준 데이터 위에 서로 다른 렌즈를 씌운 것처럼 동작해야 한다. 레코드가 업데이트되는 순간, 모든 투영 결과 역시 즉시 함께 갱신돼야 한다.

AI가 적용된 애플리케이션을 구축하면서 여러 데이터베이스를 동기화하기 위해 다수의 파이프라인을 유지할 계획이라면, 그것은 AI를 만드는 일이 아니다. 맥락 전달 시스템을 구축하고 있는 것이며, 그에 수반되는 모든 운영 리스크를 스스로 떠안는 선택을 하고 있는 셈이다.

필자가 적용하고 싶은 판단 기준은 단순하다. 에이전트가 하나의 질문에 답하기 위해 넘어야 하는 일관성 경계가 몇 개인지 세어보는 것이다. 또 동일한 사실이 스택 전반에 걸쳐 몇 개의 물리적 복사본으로 존재하는지도 따져봐야 한다. 이 두 수치 중 어느 하나라도 계속 늘어나고 있다면, 신뢰성을 확보하기 위한 작업은 이미 어려운 국면에 들어선 것이다.

이 때문에 데이터베이스가 다시 중요해지고 있다. AI는 지난 10년 동안 우리가 애써 추상화해 온 현실과 마주하도록 강제하고 있다. 소프트웨어에서 가장 어려운 부분은 혼란스러운 현실을 일관되고 질의 가능한 세계의 표현으로 바꾸는 작업이다. AI 시대에는 맥락이 모든 것을 지배한다. 지루하다고 여겨져 온 데이터베이스는 여전히 그 맥락을 대규모 환경에서도 안전하게 전달할 수 있는 가장 강력한 도구다.

데이터베이스는 비즈니스 가치를 만들어내지 못하는 인프라를 제거할 수 있게 해준다. ETL 작업, 동기화 파이프라인, 객체 관계 매핑 계층, 분산 트랜잭션 조정기와 같은 요소들이 여기에 해당한다. 결국 가장 좋은 코드는 작성하지 않아도 되는 코드다.
dl-itworldkorea@foundryco.com