문 앞의 에이전트 — 에이전트 기반 접근(Agentic Access)이 데이터베이스 보안의 불문율을 깨뜨리는 이유

API 시리즈는 외부에서 계약(contract) 문제를 살펴보았습니다. 즉, 알려진 소비자, 공유된 컨텍스트(context), 그리고 인간의 판단을 중심으로 설계된 인터페이스를 에이전트(agents)가 호출할 때 어떤 일이 발생하는지를 다루었습니다. 이번 시리즈는 반대 방향에서 살펴봅니다. 데이터 경계(data boundary) 자체가 데이터베이스는 전혀 알지 못하는 규칙을 강제하기 위해 애플리케이션 계층(application layer)에 의존하고 있었다면 어떤 일이 벌어질까요?

거의 모든 엔터프라이즈 데이터 아키텍처(enterprise data architecture)에는 깊이 박혀 있는 가정이 하나 있습니다. 이것은 너무나 근본적이어서 대부분의 조직은 이를 문서화한 적도, 의문을 제기한 적도 없습니다. 그 가정은 바로 이것입니다: 애플리케이션이 문지기(gatekeeper)라는 것입니다.

최종 사용자(end user)와 원시 데이터(raw data) 사이에 존재하는 모든 것 — 비즈니스 규칙(business rules), 검증 로직(validation logic), 무결성 검사(integrity checks), 트랜잭션 경계(transactional boundaries), 데이터 품질 제어(data quality controls) — 는 애플리케이션 계층에 존재합니다. 데이터베이스는 데이터를 저장합니다. 애플리케이션은 데이터에 어떤 일이 일어날지를 제어합니다.

그 가정은 이전에는 결코 시험받지 못했던 방식으로 시험대에 오를 예정입니다.

이것은 새로운 아이디어가 아닙니다 — 우리는 그것을 버렸었습니다

이것이 항상 수용되는 모델이었던 것은 아니라는 점을 기억할 가치가 있습니다. 30~40년 전, 엔터프라이즈 관계형 데이터베이스(relational databases)의 초기 시대에는 데이터베이스가 곧 제어 계층(control layer)이었습니다. 비즈니스 규칙은 저장 프로시저(stored procedures)에 존재했습니다. 제약 조건(constraints)이 데이터 품질을 강제했습니다. 트리거(triggers)가 무결성을 유지했습니다. 로직은 데이터와 가까웠고, 데이터베이스가 권위(authority)였습니다.

REST API와 미들 티어(middle tiers)가 엔터프라이즈 시스템의 일반적인 형태가 되기 전, 오래된 Visual Basic 클라이언트-서버 시절에 이와 유사한 버전을 다루었던 기억이 납니다. VB 프런트엔드는 ODBC를 통해 데이터베이스에 연결되었으며, 종종 애플리케이션 설정이나 코드 어딘가에 임베디드된 스키마 사용자 이름과 비밀번호를 사용했습니다. 애플리케이션이 데이터를 업데이트해야 했기 때문에, 명백한 답은 해당 스키마에 테이블에 대한 쓰기 권한(write access)을 부여하는 것이었습니다.

그 방식은 작동했지만, 보안 측면에서는 악몽과 같았습니다. 만약 해당 자격 증명(credentials)이 유출된다면, 데이터베이스는 사실상 무방비 상태가 되기 때문입니다. 이에 대한 완화 조치(mitigation)로 직접적인 테이블 업데이트를 제거하고, 모든 변경 사항이 PL/SQL 프로시저(procedures)를 통해서만 이루어지도록 강제했습니다. VB 애플리케이션은 제어된 작업(governed operations)을 호출할 수는 있었지만, 하위 테이블에 원하는 대로 마음껏 쓸 수는 없었습니다. 또한, 호출이 예상된 경로를 통해 이루어지는지 확인하기 위해 토큰 체크(token check)도 사용했습니다.

현대적인 기준에서 볼 때 우아한 방식은 아니었지만, 원칙은 확실했습니다. 데이터베이스가 호출자에게 가공되지 않은 쓰기 권한(raw write access)을 신뢰하지 않는다는 것이었습니다. 대신 제어된 작업(controlled operations)을 노출하는 방식을 취했습니다.

이 모델은 의도적으로 해체되었으며, 여기에는 그만한 이유가 있었습니다. 저장 프로시저(Stored procedures)는 테스트하기 어려웠고, 버전 관리(version control)가 고통스러웠으며, 애플리케이션 프레임워크가 가능하게 한 애자일 개발(agile development) 방식에 저항적이었습니다. 분산 아키텍처(distributed architectures)가 등장함에 따라, 데이터베이스 중심의 로직은 병목 현상(bottleneck)이 되었습니다. 확장하기 어렵고, 변경하기 어려우며, 여러 팀에 걸쳐 소유권을 관리하기가 힘들었습니다. 애플리케이션 계층(application layer)은 속도, 유연성, 그리고 관심사의 분리(separation of concerns)를 제공했습니다. 로직을 데이터베이스 밖으로 옮기는 것은 트레이드오프(trade-offs)를 이해하는 아키텍트들이 내린 의식적이고 합리적인 결정이었습니다.

당시에는 거의 눈에 띄지 않았던 결과는 데이터베이스가 점점 더 얇아졌다는 점입니다. 스키마(Schemas)는 완화되었습니다. 제약 조건(Constraints)은 애플리케이션 계층의 검증(validation)을 위해 폐기되었습니다. 비즈니스 규칙(Business rules)은 서비스 계층(service layers)과 API로 이관되었습니다. 데이터베이스는 데이터를 저장하고 검색하는 데에는 매우 능숙해졌지만, 그 데이터가 어떤 모습이어야 하는지 또는 어떻게 동작해야 하는지를 결정하는 일에는 점차 관여하지 않게 되었습니다.

수십 년 동안 이 방식은 잘 작동했습니다. 애플리케이션, 또는 이후의 미들웨어(middle tier)가 항상 그 자리에 있었기 때문입니다. 그것은 데이터로 들어가는 유일한 문이었고, 규칙이 있는 문이었습니다. 하지만 과거의 교훈은 사라지지 않았습니다. 만약 미들웨어가 규칙을 집행하는 주체라면, 이를 우회하는 모든 것은 동일한 종류의 위험을 다시 불러일으킵니다.

애플리케이션 계층은 더 이상 보장되지 않는다

AI 에이전트 (AI agents)는 이를 근본적으로 변화시킵니다. 이는 이론적인 위험이 아니라, 이미 펼쳐지고 있는 실질적인 아키텍처적 현실 (architectural reality)입니다.

자율적으로 작동하는 에이전트는 애플리케이션이 강제하도록 설계된 워크플로 (workflow)를 따르지 않을 수 있습니다. 에이전트는 양식을 제출하거나, 검증 루틴 (validation routine)을 트리거하거나, 예상된 순서대로 서비스 계층 (service layer)을 호출하지 않을 수도 있습니다. 통합 방식에 따라, 에이전트는 도구 (tools), 서비스 자격 증명 (service credentials), 생성된 SQL, 또는 기존 애플리케이션이 의도했던 것보다 더 낮은 수준의 작업을 노출하는 API를 통해 데이터에 쿼리하거나 데이터를 작성할 수 있습니다. 에이전트를 관리하는 오케스트레이션 계층 (orchestration layer)이 어느 정도의 제약을 가할 수는 있지만, 귀하의 비즈니스 규칙 (business rules)을 인코딩한 것은 애플리케이션이 아닙니다. 오케스트레이션 계층은 귀하의 데이터 모델 (data model)의 이력, 조직의 무결성 요구 사항 (integrity requirements), 또는 20년의 개발 기간 동안 스키마 (schema)에 녹아든 가정들에 대해 거의 알지 못합니다.

이는 보안 문제일 뿐만 아니라, 보안은 그 일부에 불과합니다. 이는 훨씬 더 광범위한 통제력의 상실입니다. 전형적인 엔터프라이즈 시스템의 애플리케이션 계층 (application layer)에 실제로 무엇이 존재하는지 생각해 보십시오:

• 비즈니스 규칙 (Business rules) — 자격 확인, 승인 워크플로우, 상태 전이 로직, 가격 책정 규칙 등입니다. 이 중 그 어느 것도 데이터베이스에 들어있지 않습니다. 애플리케이션이 이를 먼저 가로채지 않는다면, 데이터베이스는 이러한 규칙을 모두 위반하는 레코드라도 그대로 수용할 것입니다.
• 데이터 품질 제어 (Data quality controls) — 형식 검증, 외래 키 (foreign keys) 이상의 참조 확인, 필드 간 일관성 규칙 등입니다. 데이터베이스에 직접 기록하는 에이전트는 이 모든 것을 우회합니다.
• 트랜잭션 경계 (Transactional boundaries) — 무엇이 완전한 작업(operation)을 구성하는지는 애플리케이션이 정의합니다. 데이터베이스는 트랜잭션 내에서 원자성 (atomicity)을 강제하지만, 무엇이 해당 트랜잭션에 포함될지를 결정하는 것은 애플리케이션입니다. 에이전트는 논리적 작업을 완료하지 못한 채 부분적인 상태만을 기록할 수 있습니다.
• 감사 및 컴플라이언스 훅 (Audit and compliance hooks) — 많은 시스템에서 컴플라이언스 로깅은 애플리케이션 코드에 구현되어 있습니다. 데이터베이스에 대한 직접적인 접근은 이러한 로깅에 포착되지 않습니다.
• 최종 사용자 신원 (End user identity) — 아마도 가장 결정적인 문제로, 데이터베이스는 일반적으로 단일 애플리케이션 자격 증명 (credential)만을 인식합니다. 데이터베이스는 특정 작업 뒤에 어떤 최종 사용자가 있는지 알지 못합니다. 애플리케이션은 이를 알고 있었습니다. 하지만 서비스 계정이나 API 자격 증명을 통해 자율적으로 행동하는 에이전트는 그러한 컨텍스트를 완전히 제거해 버립니다.

이 각각의 요소는 개별적으로 하나의 격차 (gap)를 나타냅니다. 이들이 모이면, 애플리케이션 계층이 우회될 때 단순히 기능을 상실해 버리는 통제 프레임워크 (control framework)가 됩니다.

스키마 문제 (The Schema Problem)

이 위험은 유연성을 위해 내려온 지난 10년간의 아키텍처 선택들로 인해 더욱 심화됩니다. 유연한 스키마 — JSON 컬럼, 문서 저장소 (document stores), 스키마 온 리드 (schema-on-read), EAV 패턴 — 로의 전환은 현대적 개발이 요구하는 변화의 속도에 대한 정당한 대응이었습니다. 만약 애플리케이션이 입력되는 내용을 제어하고 있다면, 어느 정도의 스키마 유연성은 관리 가능한 수준입니다. 애플리케이션이 스키마에 없는 구조를 제공하기 때문입니다.

애플리케이션을 제거하면, 유연한 스키마 (flexible schema)는 부채가 됩니다. 문서 저장소 (document store)나 느슨한 타입의 컬럼 (loosely-typed column)에 데이터를 쓰는 에이전트는 구조적 저항을 거의 받지 않습니다. 쓰기 시점에는 아무것도 깨지지 않습니다. 데이터는 수용될 것입니다. 하지만 그 피해는 소리 없이 누적되며, 잠재적으로 탐지하거나 되돌리기가 매우 어려울 수 있습니다.

여기서 언급할 만한 반론이 하나 있습니다. 업계가 스키마 유연성으로부터 멀어질 때조차 강력하고 제약이 있는 관계형 데이터 모델 (relational data models)을 유지하며 스키마 유연성에 저항했던 조직들은, 이제 오히려 더 잘 보호받고 있다는 사실을 깨달을지도 모릅니다. 민첩성 (agility)의 장애물로 자주 비판받던 경직된 스키마 (rigid schemas)가 일종의 구조적 방어 수단임이 드러난 것입니다. 스키마가 비즈니스 규칙 (business rules)을 강제할 수는 없지만, 적어도 구조적으로 유효하지 않은 데이터는 거부할 수 있습니다.

역사의 회전 (The Wheel Turns)

아이러니는 날카롭습니다. 애플리케이션 계층 (application layer)이 해체되고 있는 바로 이 시점에, 우리는 데이터베이스가 강제하는 로직 (database-enforced logic)의 가치를 재발견하고 있습니다. 제약 조건 (constraints), 규칙 (rules), 데이터 근처에서의 무결성 강제 (integrity enforcement)를 포함하는 두터운 데이터베이스 모델 (thick database model)은 2010년의 모습보다 훨씬 더 선견지명이 있었던 것으로 보입니다.

해당 모델에 대한 역사적인 반대 의견들은 실재했으나, 이제 그 힘이 약해지고 있습니다. 데이터베이스에 로직을 내장하는 것에 반대하는 가장 강력한 두 가지 논거는 개발 비용과 강력한 스키마의 경직성이었습니다. 이 두 가지 모두 인간이 인간의 속도로 작업하며, 그 로직을 작성하고 유지하는 비용을 감당해야 한다는 가정에 기반하고 있었습니다.

AI 지원 개발 (AI-assisted development)은 그 계산법을 바꿉니다. 과거에는 작성하고 유지하는 데 상당한 시간이 걸렸을 복잡한 제약 조건 (constraints), 검증 규칙 (validation rules), 스키마 정의 (schema definitions)를 이제 훨씬 더 빠르게 생성, 테스트 및 진화시킬 수 있습니다. 데이터베이스 강제 로직을 비실용적으로 만들었던 마찰 (friction)은, 정작 그 필요성이 증가하는 시점에 줄어들고 있습니다. 역사적으로 개발 속도의 적이었던 강력하고 잘 정의된 스키마 (strong, well-defined schemas)조차도, 도구 (tooling)가 스키마 진화 비용의 상당 부분을 흡수할 수 있게 되면서 장애물이 덜 되는 것입니다.

이것이 모놀리식 저장 프로시저 (monolithic stored-procedure) 아키텍처로 돌아가야 한다는 의미는 아닙니다. 이는 애플리케이션이 더 이상 루프 (loop) 안에 있다고 가정할 수 없을 때, 제어권이 어디에 위치해야 하는가라는 질문을 진지하게 받아들여야 함을 의미합니다.

조직이 지금 던져야 할 질문

당신이 데이터 무결성 (data integrity)이라고 믿는 것 중 실제로 데이터베이스에 존재하는 양은 얼마나 되며, 당신이 곧 우회하게 될 애플리케이션에 존재하는 양은 얼마나 됩니까?

대부분의 조직에게 정직한 답변을 내놓으려면 의도에 대한 명확한 정리가 필요합니다. 애플리케이션 아키텍트들은 데이터베이스가 얼마나 얇은지(thin) 정확히 알고 있었으며, 이를 얇게 만드는 것이 목표였습니다. 로직을 애플리케이션 레이어 (application layer)로 이동시키는 것은 의도적이었고, 숙고되었으며, 그 자체의 기준에서 성공적이었습니다. 이것은 실수나 간과가 아니었습니다. 이는 수년 동안 규율 있게 실행된 설계 철학이었습니다.

문제는 그 결정들이 틀렸다는 것이 아닙니다. 문제는 그 결정들이 애플리케이션이 루프 안에 머물 것이라고 가정할 수 있었던 세상에서는 옳았다는 점입니다. 이제 그 가정은 더 취약해졌습니다. 얇은 데이터베이스를 정답으로 만들었던 맥락이 변화했으며, 당시에는 합리적이었던 결정들을 이제는 재검토해야 합니다.

이 시리즈의 후속 기사들은 이 문제의 구체적인 차원들 — 신원 및 책임 (identity and accountability), 트랜잭션 무결성 (transactional integrity), 스키마 및 스토리지 모델 (schema and storage models), 거버넌스 및 컴플라이언스 (governance and compliance) — 그리고 이를 해결하기 위해 데이터베이스 관리 시스템 (DBMS)이 무엇이 되어야 하는지를 살펴봅니다. 하지만 출발점은 이 문제가 존재한다는 것, 이것이 구조적이라는 것, 그리고 지난 30년 동안 축적되어 왔다는 사실을 인식하는 것입니다.

에이전트가 문 앞에 와 있습니다. 그 문은 이것을 위해 설계되지 않았습니다.