Charly Batista · 2026년 6월 23일

DBA라면 누구나 이런 아침을 겪어봤을 겁니다. 오전 9시 14분, 개발자가 슬랙으로 메시지를 보냅니다. “저기요, DB가 느려요. 결제(checkout)가 자꾸 타임아웃 나요.”

당신은 콘솔을 열고 느린 쿼리 로그를 뒤지기 시작합니다. pg_stat_statements를 띄우고, 실행 시간을 최근 스키마 변경과 맞춰보고, 통계가 오래된 건 아닌지 확인합니다. 누가 어젯밤에 인덱스를 지운 건 아닐까 의심하다가, 활성 커넥션을 보려고 터미널을 하나 더 엽니다. 그렇게 헤매다 10시 30분쯤, 드디어 범인을 찾습니다. 필터링되는 컬럼에 인덱스가 빠져 있었고, 그게 지난 배포 이후로 결제 쿼리란 결제 쿼리는 죄다 잡아먹고 있었던 거죠.

한 시간 이십 분. 그동안 개발자는 발이 묶였고 고객은 답답해했습니다. 그런데 정작 고치는 데는 10초쯤 걸렸습니다. CREATE INDEX CONCURRENTLY 한 줄이면 끝이었으니까요.

문제를 찾는 것과 고치는 것 사이의 이 간극은 예전엔 그저 좀 성가신 정도였습니다. 하지만 에이전트(agent)가 본격적으로 등장하면서, 이제는 무시할 수 없는 위험이 됐습니다. 에이전틱 시대는 기업이 만드는 애플리케이션의 종류만 바꾸는 게 아닙니다. 기업이 자기 인프라를 다루는 방식 자체를 바꿉니다. 전통적인 데이터베이스 인프라로는 에이전트가 움직이는 속도를 도저히 따라갈 수 없습니다.

해답은 사람더러 더 빨리 일하라고 다그치는 게 아닙니다. 데이터베이스가 스스로 굴러가게 만드는 것입니다. EDB Postgres® AI(EDB PG AI)는 지능을 엔진 안에 직접 심습니다. 그래서 에이전트가 움직이는 속도에 맞춰 스스로 튜닝하고(self-tune), 스스로 확장하고(self-scale), 스스로 복구합니다(self-heal). 모든 것을 최적화되고 엔터프라이즈급으로 유지해, 에이전트와 개발자가 믿고 의지할 운영 기반을 만들어 줍니다. 그러면서도 복잡함을 더하거나 통제권을 빼앗지 않습니다. 모든 자율 동작은 조직이 정한 가드레일(guardrail) 안에서만 실행되고, 원하면 사람이 직접 승인하도록(human-in-the-loop) 설정할 수도 있습니다.

이 글에서는 그게 실제로 어떻게 작동하는지 짚어봅니다. 우리 에이전틱 데이터베이스가 무엇을 하고, 어떻게 동작하며, PostgreSQL을 다루는 방식을 어떻게 바꾸는지 차례로 살펴보겠습니다.

“에이전틱 데이터베이스”가 실제로 뜻하는 것

“에이전틱(agentic)”이라는 말은 너무 헐겁게 쓰입니다. EDB Postgres AI에서는 이 말이 구체적인 무언가를 가리킵니다. 시스템이 당신의 클러스터를 쉬지 않고 지켜보고, 본 것을 바탕으로 추론하고, 추천을 만들어내고, 당신이 정한 거버넌스 수준 안에서 직접 조치까지 할 수 있다는 뜻입니다. 이 모든 건 20년 넘게 쌓인 EDB Postgres 전문성 위에 세워졌습니다. 그 패턴과 튜닝 노하우를, 일반적인 벤치마크가 아니라 당신의 실제 워크로드를 대상으로 돌아가는 자동화 계층으로 묶어낸 거죠. 그 덕분에 데이터베이스 운영이 사후 대응(뭔가 터졌으니 가서 고친다)에서 사전 예방(이게 곧 문제가 될 텐데, 해결책은 여기 있습니다. 적용할까요?)으로 바뀝니다.

추천 스코어카드: 데이터베이스의 건강 성적표

EDB Postgres AI 콘솔에서 클러스터를 열면 가장 먼저 만나는 게 **추천 스코어카드(Recommendation Scorecard)**입니다. 잠들지 않고 계속 도는 건강검진이라고 보면 됩니다.

클러스터의 Postgres 건강 상태는 다섯 가지 차원으로 평가됩니다.

1. 인덱스(Indexes) — 워크로드가 올바른 인덱스를 실제로 쓰고 있나? 빤히 빠진 부분은 없나?
2. 통계(Statistics) — 쿼리 플래너가 최신의 정확한 통계로 돌고 있나?
3. 설정(Configuration) — Postgres 설정이 당신의 환경과 워크로드 특성에 맞게 튜닝돼 있나?
4. 보안(Security) — 보안 구멍은 없나? 열려 있는 역할, 약한 인증, 암호화 안 된 연결 같은 것들 말이죠.
5. 워크로드(Workload) — 곧 추가될 차원으로, 런타임 분석을 한층 더 깊게 더해줄 예정입니다.

각 항목은 A부터 F까지 등급을 받아서, 심각한 정도가 한눈에 들어옵니다. 다만 빨간불만 켜놓고 나머지는 알아서 알아내라는 식의 대시보드와는 다릅니다. 스코어카드는 무엇을 발견했는지, 그리고 정확히 어떻게 고치면 되는지까지 보여줍니다.

실제 모습은 이렇습니다. 금융 거래 워크로드를 돌리는 예시 클러스터 LedgerDB가 인덱스 등급 D를 받았습니다. 시스템은 약 10분간 워크로드를 지켜봤습니다. 그사이 pg_stat_statements를 읽고, 가장 느린 쿼리 패턴을 골라내고, 그 쿼리들이 어떤 컬럼으로 필터링하는지 분석한 끝에, 특정 인덱스가 빠져 있다고 결론 내렸습니다. 추천은 두루뭉술하지 않습니다. 이렇게 콕 집어 줍니다.

CREATE INDEX CONCURRENTLY idx_transactions_status_account
ON public.transactions (status, account_id);

그리고 이 인덱스 하나만으로 관찰된 워크로드의 쿼리 비용이 90% 넘게 줄어들 거라고 추정합니다. 로그를 뒤질 필요도, 쿼리 플랜을 일일이 맞춰볼 필요도, 짐작할 필요도 없습니다. 시스템이 관찰하고, 추론하고, 정확한 SQL까지 내놓았으니까요. 그 자리에서 바로 승인하면 됩니다. 이 부분은 자동화(Automations) 섹션에서 더 다룹니다.

이 LedgerDB 사례는 어쩌다 한 번 나온 게 아닙니다. 모든 추천은 일반적인 규칙집이 아니라 당신의 실제 워크로드에서 나옵니다. EDB PG AI가 워크로드당 최대 8배 빠른 애플리케이션 성능과 더 낮은 리소스 비용을 낼 수 있는 비결(내부 벤치마크 기준)이 바로 여기 있습니다. 보통 속도와 비용은 서로 맞바꿔야 하지만, 여기서는 둘이 같이 좋아집니다. 문제에 리소스를 더 들이붓는 대신, 플랫폼이 워크로드 자체를 최적화하기 때문이죠. 클러스터가 수백 대에 이르는 플릿(fleet) 규모에서는 이게 실제 비용 절감으로 쌓이고, 에이전트가 기계 속도로 데이터베이스에 요청을 쏟아내기 시작할 때 꼭 필요한 그 효율성으로 이어집니다.

그런데 그 전에, 시스템은 자기가 아는 걸 대체 어떻게 아는 걸까요? 그 답이 챗봇으로 이어집니다.

AI 챗봇: 늘 대기 중인 시니어 DBA

AI 챗봇은 더 깊은 인사이트를 위한 대화형 계층을 더합니다. 여기서 꼭 짚고 넘어갈 점이 있습니다. 이 챗봇은 일반적인 Postgres 문서와 대화하는 게 아닙니다. 당신의 클러스터에 실시간으로 연결돼 pg_stat_statements를 직접 읽습니다. 그래서 모든 답이 지금 이 순간 당신의 데이터베이스가 실제로 하고 있는 일에 근거합니다.

덕분에 탭 다섯 개를 열어 직접 쿼리를 짜는 대신, 그냥 이렇게 물으면 됩니다. “LedgerDB에서 도는 쿼리들을 봤을 때, 어떤 스키마 변경이 성능을 가장 크게 끌어올릴까?” 돌아오는 건 모범 사례 목록이 아니라, 당신 워크로드에 대한 분석입니다. 총 실행 시간 기준 상위 쿼리들을 뽑아내고, 각 접근 패턴을 쉬운 말로 풀어주고, 우선순위가 매겨진 추천을 번호로 정리해 줍니다. 여기엔 복합 인덱스, 저기엔 부분 인덱스, 그리고 18개월 안에 INTEGER 한계를 넘어설 account_id 같은 것들이죠.

추천 하나하나에는 그 근거가 된 구체적인 쿼리와 그렇게 판단한 이유가 함께 달립니다. 시니어 DBA라면 똑같은 분석을 해냈겠지만, 30초가 아니라 45분에서 한 시간은 걸렸을 일입니다.

더 깊이 파고들 수도 있습니다. 왜 그 추천을 했는지, 어떤 쿼리에 근거했는지, 지금 실행 계획은 어떤지, 적용하면 어떤 위험이 있는지 물어보세요. 챗봇은 그 전체 흐름을 짚어줍니다. 빌드 시간, 락(locking) 동작, 그리고 나중에 워크로드 패턴이 바뀌면 어떻게 되는지까지요. 예전 같으면 DBA가 쿼리를 다시 돌려보고 EXPLAIN ANALYZE를 뽑아 손으로 문서화해야 했던 작업입니다. 이제는 후속 질문 하나면 끝납니다.

자동화(Automations): 잠들지 않는 시스템

챗봇과 스코어카드가 무엇을 해야 할지 알려준다면, 자동화는 그걸 대신 해줍니다. 정해진 일정에 따라, 당신이 정의한 가드레일 안에서, 에이전트가 실제로 움직이는 속도로요. 어떤 동작은 완전 자율로 돌려도 안전하고, 어떤 동작은 사람을 한 번 거치게 하고 싶을 겁니다. 그 경계는 자동화별로 직접 정합니다. 현재 릴리스에는 다섯 가지 유형이 들어 있습니다.

1. 디스크 자동 확장(Disk Autoscale) — 사용률이 임계치를 넘으면 정해진 단위로, 상한선까지 스토리지를 늘립니다. 새벽 2시에 호출받을 사람은 없습니다.

2. 인덱스 추천(Index Recommendations) — 일정 간격으로 워크로드를 평가하고 인덱스 적용 작업을 큐에 넣습니다. 빌드는 CREATE INDEX CONCURRENTLY로 실행되니 트래픽은 계속 흐릅니다.

3. 마이너 버전 업그레이드(Minor Version Upgrades) — 새 마이너 버전 이미지가 나오는지 지켜보다가, 당신의 유지보수 윈도(maintenance window)에 맞춰 업그레이드를 큐에 넣습니다.

4·5. CPU·메모리 자동 확장(CPU and Memory Autoscale) — 수요에 맞춰 규모를 적정하게 조정하는 임계치 기반 스케일링이며, 상한선을 설정할 수 있습니다.

각 항목마다 승인 방식을 고릅니다. 완전 자율로 둘지, 사람의 승인을 반드시 받게 할지요. 속도와 통제를 맞바꾸는 게 아니라, 당신 환경에 맞는 균형점을 직접 맞추는 겁니다.

눈에 보이고, 통제되는 실행

모든 자동화 동작은 플랫폼의 태스크 매니저(Task Manager)를 거칩니다. 여기서 그 작업이 무엇인지, 실행할 정확한 SQL, 승인 상태, 그리고 왜 승인이 필요한지를 확인할 수 있습니다. 승인이 필요하면 작업을 검토하고 승인하면 됩니다.

그다음 모든 내역은 변경 불가능한, 타임스탬프가 찍힌 활동 로그(Activity Log)에 남습니다. 감사 담당자가 “지난 화요일 LedgerDB에서 뭐가 바뀌었고 누가 승인했죠?”라고 물으면, 답이 거기 다 있습니다. 자동화 동작은 어느 자동화가 했는지, 승인은 누가 했는지가 전부 귀속되어 기록되니까요. 이 로그는 시스템과 함께 일하는 AI 에이전트의 컨텍스트 윈도(context window) 역할도 같이 합니다.

어떤 AI 에이전트에게도 똑같은 전문성

챗봇과 스코어카드를 떠받치는 자문(advisory) 기능은 MCP(Model Context Protocol) 서버로도 열려 있습니다. 외부 에이전트(Claude든, 직접 만든 코파일럿이든, MCP 호환 도구 무엇이든)는 똑같은 인터페이스, 똑같은 전문성, 똑같은 가드레일을 통해 클러스터 상태를 조회하고, 추천을 받아오고, 활동 로그를 읽고, 승인된 동작을 실행할 수 있습니다. EDB PG AI의 자문 계층을 당신의 나머지 AI 도구 체인과 자유롭게 결합해 쓸 수 있게 되는 거죠.

진짜 생산성 계산

이 역량들이 결국 무엇으로 합쳐지는지 구체적으로 따져봅시다.

이전: 느린 쿼리 경보가 들어옵니다. DBA가 조사를 시작합니다.

단계	소요 시간
pg_stat_statements에서 영향받은 쿼리 식별	10~15분
각 쿼리의 EXPLAIN ANALYZE 출력 분석	15~20분
테이블 통계 및 스키마와 대조	10~15분
빠진 인덱스 또는 설정 변경 사항 파악	10~15분
수정안 작성 및 검증	5~10분
유지보수 윈도에 적용	5분
개선 효과 확인	5분
합계	60~85분

이후, EDB Postgres AI 콘솔 사용 시:

단계	소요 시간
스코어카드가 문제를 드러내고 정확한 수정안 제안	30초
챗봇에 추천 설명을 요청해 근거 검증	2분
태스크 매니저에서 인덱스 작업 승인	1분
유지보수 윈도에 적용	5분
합계	약 7~8분

이건 살짝 나아진 수준이 아닙니다. 프로덕션 클러스터를 최적화하는 속도가 최대 10배 빨라진 것입니다. 데이터베이스 운영 방식 자체가 구조적으로 바뀐 거죠. 누적 효과도 무시할 수 없습니다. 일상적인 인덱스 조사에 안 쓰게 된 그 시간이, 용량 계획이나 스키마 설계처럼 진짜 전문가의 판단이 필요한 일로 돌아가니까요. 그리고 클러스터를 여러 개 굴리는 팀이라면, 예전엔 팀 하나가 붙어야 했던 환경을 이제 DBA 한 명이 가시성과 대응력을 유지하며 관리할 수 있습니다.

DBA가 아니어도 이게 중요한 이유

여기까지는 DBA 관점에서 풀었지만, 그게 전부는 아닙니다.

추천 스코어카드와 챗봇은 데이터베이스를 한 번도 튜닝해본 적 없는 개발자도 쓸 수 있도록 일부러 그렇게 설계했습니다. 지난주에 새 기능을 배포했는데 그 기능이 돌리는 쿼리가 지금 pg_stat_statements 맨 위에 올라와 있는 엔지니어라면, B-트리 인덱스 내부 구조 같은 건 몰라도 그냥 이렇게 물으면 됩니다. “이 쿼리는 왜 느리고, 어떻게 고치면 되나요?”

시스템이 쉬운 말로, 고치는 SQL까지 곁들여 알려줄 겁니다.

이렇게 Postgres 전문성을 누구나 쓸 수 있게 만든 것이야말로, EDB가 만든 것 중 잘 드러나진 않지만 더 의미 있는 부분입니다. 예전엔 수년의 경력이나, 값비싼 컨설팅, 또는 아주 참을성 많은 시니어 DBA가 있어야 얻던 전문성이, 이제는 한 번의 대화로 바뀌었으니까요.

EDB PG AI 에이전틱 데이터베이스 시작하기

추천 스코어카드, AI 챗봇, 다섯 가지 자동화, 태스크 매니저, 활동 로그, MCP 연동까지, 전부 오늘 EDB Postgres AI에서 바로 쓸 수 있습니다. 무엇이 달라지는지 가장 확실하게 체감하는 방법은, 실제 워크로드가 도는 진짜 클러스터에 연결해 10분만 지켜보게 한 뒤 챗봇에게 뭘 바꾸겠냐고 물어보는 겁니다. 아마 당신이 혼자 한 시간을 들여야 찾았을 무언가를, 당신 데이터베이스에 대해 이미 알고 있을 겁니다.

지금 바로 데모를 확인해 보세요. 이 역량들을 더 깊이 파고드는 심층 분석도 곧 EDB 웹사이트에 공개될 예정이니 기대해 주세요.

---

EDB Postgres AI 에이전틱 데이터베이스, 더 알아보기

도입이나 PoC가 궁금하시다면 EDB Korea로 문의해 주세요.

• 이메일: salesinquiry@enterprisedb.com
• 전화: 02-501-5113
• 문의하기 →

---

원문: Stop Spending Hours on What Should Take Minutes: A DBA’s Guide to EDB Postgres® AI’s Agentic Database Capabilities (EDB Blog)