우리 소프트웨어 개발자들은 지난 10년 동안 데이터베이스가 존재한다는 사실을 잊으려 노력했다. 데이터베이스를 없앤 것은 아니다. 페타바이트 단위의 데이터는 여전히 저장하고 있다. 다만 평균적인 개발자 관점에서 데이터베이스는 구현 세부사항으로 밀려났고, 반드시 필요하지만 따분한 유틸리티 계층이 됐으며, 의식하지 않기 위해 노력하는 대상이 됐다.

우리는 데이터베이스를 ORM(Object-Relational Mapper) 뒤로 추상화했다. 데이터베이스를 API로 감쌌다. 반정형 객체를 컬럼에 욱여넣고 유연하다고 스스로를 설득했다. 영속성 문제가 이미 해결됐다고 자평했고, 모든 것을 분리하기 시작했다. 검색이 필요하면 검색 시스템을 덧붙였다. 캐싱이 필요하면, 마찬가지 방식으로 붙였다. 문서는 문서 저장소를 썼고, 관계는 그래프 데이터베이스를 추가하는 식이었다. 우리는 스스로 영리하다고 생각했지만, 실제로는 복잡성을 데이터베이스 엔진에서 접착 코드, 파이프라인, 운영 오버헤드로 옮겨놓았을 뿐이었다.

AI는 이런 접근의 아키텍처 취약성을 여실히 드러냈다.

AI가 스며든 애플리케이션에서 데이터베이스는 수동적인 기록 저장소가 아니라 확률론적 모델과 SoR(System of Record) 사이의 능동적 경계로 바뀐다. 멋진 데모와 미션 크리티컬 시스템을 가르는 핵심은 대개 LLM이 아니다. 핵심은 회수할 수 있는 컨텍스트, 그 컨텍스트의 일관성, 그리고 컨텍스트를 조립하는 속도다.

AI는 데이터베이스를 다시 보이게 만들었다. 갑자기 SQL을 다시 사랑하게 된 것은 아니지만, AI 메모리가 또 하나의 데이터베이스 문제에 불과하다는 사실을 깨닫고 있다. 데이터베이스는 더 이상 데이터가 사는 장소만이 아니다. AI에서 컨텍스트를 조립하는 장소가 데이터베이스이고, AI에서 컨텍스트는 전부다.

일관성과 환각

우리가 왜 이렇게 고전하는지 이해하려면, 현재 상황에 이르는 과정을 살펴봐야 한다. 우리는 지난 10년 동안 데이터베이스를 없애지 않았다. 실제로는 데이터베이스를 더 늘렸다.

현대적 애플리케이션 설계는 데이터베이스의 한계를 우회하라고 가르쳤다. 우리는 캐시, 검색 클러스터, 스트림 프로세서, 그리고 목적별 저장소가 뒤섞인 불협화음을 만들었다. 서로 다른 ‘베스트 오브 브리드’ 시스템 5개를 배선으로 엮는 방식의 다중 저장소 지속성(Polyglot Persistence)을 아키텍처 계몽이라고 믿었다. 현실에서 다중 저장소 지속성은 대체로 이력서 중심 개발에 불과했고, 복잡성을 데이터베이스 엔진에서 애플리케이션 코드로 옮겨놓았다.

‘최종적 일관성(Eventual Consistency)’이 용인될 때는 그런 방식도 통했다. 하지만 AI에는 통하지 않는다. 전혀 통하지 않는다.

실용적인 RAG 파이프라인을 떠올려보자. RAG 파이프라인은 ‘벡터를 가져온다’ 수준으로 끝나는 경우가 드물다. 진짜 엔터프라이즈 AI 워크플로우에는 의미론적 일치를 찾는 벡터 유사도 검색, 콘텐츠를 가져오는 문서 회수, 권한이나 계층 같은 관계를 이해하는 그래프 순회, 그리고 데이터가 오래되지 않았는지 확인하는 시계열 분석이 필요하다. 지난 10년 간의 덧칠식 아키텍처에서는 이런 요구를 특화 서비스 조합으로 구현했다. 벡터 데이터베이스, 문서 저장소, 그래프 데이터베이스, 시계열 시스템을 붙이는 방식이다.

덧칠식 아키텍처는 이상적이지 않았지만, AI가 만들어낸 것처럼 치명적인 문제는 아니었다. 흐름도에서 화살표 하나하나가 네트워크 홉이고, 홉이 늘어날수록 직렬화 오버헤드가 늘어난다. 상황을 더 악화시키는 요인은 분리된 각 시스템이 새로운 일관성 모델을 도입한다는 점이다. 하나의 논리적 컨텍스트로 묶여야 할 것을 물리적 시스템 6개로 쪼개면, 복잡성·지연·불일치 측면에서 비용을 치르게 된다. AI는 이런 비용에 유독 민감하다.

일반적인 웹 앱이 오래된 데이터를 보여주면, 사용자는 몇 초 동안 옛 재고 수량을 볼 수 있다. AI 에이전트가 불일치한 컨텍스트를 회수하면(예를 들어 벡터가 가리키는 문서는 관계형 저장소에서 이미 업데이트된 뒤일 수 있다), AI 에이전트는 거짓 전제를 기반으로 그럴듯한 서사를 구성한다. 업계는 이런 현상을 환각이라고 부르지만, 모델이 종종 완전히 지어내는 것은 아니다. 파편화된 데이터베이스 아키텍처가 오래된 데이터를 모델에 먹이고 있을 뿐이다. 검색 인덱스가 SoR과 ‘최종적 일관성’ 관계라면, AI는 ‘최종적으로 환각을 일으킨다’는 뜻이다.

트랜잭션 시스템이 SSOT(Single Source of Truth)인데, 벡터 인덱스가 비동기로 갱신된다고 가정해보자. AI 에이전트의 메모리에는 시간 지연이 내장된다. 관계 데이터가 드리프트할 수 있는 파이프라인으로 동기화된다면, AI 에이전트는 더 이상 사실이 아닌 관계를 ‘알고’ 있을 수 있다. 권한은 한 시스템에서 검사하고 콘텐츠는 다른 시스템에서 가져오면, 버그 하나가 데이터 유출로 이어질 수 있다.

AI가 수동형 챗봇에서 능동형 에이전트로 이동하면 문제는 더 심각해진다. 우리는 차세대 AI가 텍스트 요약을 넘어 작업을 수행하길 기대한다. 작업 수행에는 트랜잭션이 필요하다. AI 에이전트가 고객 레코드를 업데이트하고(관계형), 선호 프로필을 재인덱싱하고(벡터), 상호작용을 기록해야 한다면(문서), 데이터베이스 아키텍처가 대서사시처럼 3개 시스템에 걸친 쓰기를 조정하도록 강제하는 순간 취약성 엔진이 완성된다. 파편화된 스택에서 워크플로우 중간에 장애가 나면, AI 에이전트가 바라보는 세계는 손상된 상태로 남는다. AI 에이전트가 전체 메모리 공간에서 원자성·일관성·격리성·지속성(ACID) 보장을 신뢰하지 못하면, 신뢰할 수 있는 에이전트를 만들 수 없다.

문제의 본질은 AI가 아니다. 문제의 본질은 기본적인 아키텍처 문제다. 필자가 여러 차례 지적했듯, 신뢰할 수 없는 데이터 인프라 위에서는 신뢰할 수 있는 에이전트를 만들 수 없다. 에이전트 신뢰성 작업은 데이터베이스 작업과 분리할 수 없다.

아키텍처 측면의 제약

우리는 한동안 ‘충분히 괜찮은’ 성능을 받아들였다. 쿼리가 느리면 노드를 더 붙이는 식으로 수평 확장이 가능했기 때문이다. 하지만 AI 워크로드는 계산량이 크고, 데이터 구조의 물리학이 다시 중요해졌다.

JSON 문서를 읽는 단순한 행위를 보자. 일부 인기 문서 저장소에서는 내부 바이너리 포맷이 순차 필드 스캔을 요구한다. 순차 필드 스캔은 O(n) 연산이다. 큰 문서의 끝부분에 있는 필드를 찾으려면 엔진이 앞부분 전체를 스캔해야 한다. 단순 CMS에는 통할 수 있지만, 엔터프라이즈 규모(바이럴 이벤트 동안 초당 10만 건 요청 같은 상황)에서는 나노초가 누적되면서 완전히 무너진다. 초당 10만 건 규모에서 O(n) 스캔은 데이터 파싱만으로 CPU 코어 수십 개를 낭비할 수 있다. 반대로 최신 바이너리 포맷은 해시 인덱스 기반 내비게이션을 활용해 특정 필드로 O(1) 점프를 가능하게 만들고, 심도 깊은 문서 순회 성능을 500배 이상 끌어올린다.

이 문제는 미세 최적화가 아니다. 이 문제는 근본적인 아키텍처 제약이다. ‘나노초 몇 개’라는 말은 지연이 사용자 경험을 죽이는 규모에서 운영해본 적이 없다는 뜻이다. 추론 자체가 이미 느린 AI 환경에서, 데이터베이스는 비효율적인 알고리즘 기반 때문에 지연을 더할 여유가 없다.

인프라 구축을 멈춰야 한다

필자는 전문 도구의 자리가 없다고 말하는 것이 아니다. 다만 지난 10년의 실수는, 특화 시스템 5개를 조립하면 범용 시스템 1개보다 더 단순해질 수 있다고 가정한 데 있다. AI에서 던져야 할 질문은 ‘벡터 검색이 되는 데이터베이스는 무엇인가’가 아니다. AI에서 던져야 할 질문은 ‘컨텍스트는 어디에 있고, 컨텍스트를 조립하는 과정에서 일관성 경계를 몇 번이나 넘는가’다.

답이 ‘많다’라면, 인프라를 구축하겠다는 선언이다. 파이프라인, 재시도, 정합성 복구 로직, 지연 모니터링을 만들게 되고, 언젠가는 그런 지연을 정상으로 취급하게 된다.

대안은 데이터 모델을 물리적 의무로 취급하지 않는 것이다. 과거에는 그래프가 필요하면 데이터를 그래프 데이터베이스로 복사했다. 벡터가 필요하면 데이터를 벡터 저장소로 복사했다. 복사가 동기화라는 악의 뿌리다.

과학적인 접근은 데이터를 하나의 정규 형태로 두고, 애플리케이션 필요에 따라 어떤 형태로든 투영할 수 있게 다루는 방식이다. 관계를 순회해야 하는가? 데이터베이스가 그래프 뷰를 투영해야 한다. 시맨틱 검색이 필요한가? 데이터베이스가 벡터 뷰를 투영해야 한다. 그래프 뷰와 벡터 뷰는 파이프라인이 필요한 복사본이 되어서는 안 된다. 그래프 뷰와 벡터 뷰는 SSOT에 대한 서로 다른 렌즈가 되어야 한다. 레코드가 업데이트되면 모든 투영이 즉시 업데이트돼야 한다.

AI가 스며든 애플리케이션을 만들면서, 여러 데이터베이스를 동기화하기 위한 여러 파이프라인을 유지할 계획이라면, AI를 만드는 것이 아니다. 컨텍스트 전달 시스템을 만드는 것이고, 그에 따르는 모든 운영 리스크를 떠안는 것이다.

필자가 적용하는 규칙은 다음과 같다. 에이전트가 질문 하나에 답하기 위해 넘는 일관성 경계가 몇 개인지 세어보라. 스택 전반에 걸쳐 ‘동일한 진실’의 물리적 복사본이 몇 개인지 세어보라. 두 숫자 중 하나라도 계속 늘어난다면, 신뢰성 작업은 이미 곤경에 처했다.

AI가 데이터베이스를 다시 중요하게 만든 이유가 여기에 있다. AI는 우리 개발자들이 10년 동안 추상화로 가려온 현실을 직시하게 만든다. 소프트웨어의 어려운 지점은 지저분한 현실을 일관되고 쿼리 가능한 세계의 표현으로 바꾸는 일이다. AI 시대에는 컨텍스트가 지배한다. 데이터베이스는 따분하다는 평가에도 불구하고, 안전하게 대규모로 컨텍스트를 전달하는 데 가장 좋은 도구다. 데이터베이스는 비즈니스 가치가 없는 인프라를 걷어내게 한다. ETL 작업, 동기화 파이프라인, 객체-관계 매핑 계층, 분산 트랜잭션 코디네이터가 그런 대상이다. 최고의 코드는 작성하지 않은 코드다.
dl-itworldkorea@foundryco.com