개발과 인프라 관련 글을 읽다 보면 Ops로 끝나는 용어를 자주 만나게 된다.

DevOps를 이해했다고 생각하면 DevSecOps가 등장하고, AI 이야기를 따라가다 보면 AIOps와 AISecOps까지 나온다. 이름만 보면 기존 개념에 단어를 하나씩 붙인 것처럼 느껴진다.

하지만 구분하는 기준은 의외로 명확하다.

어떤 업무를 연결하는지, AI를 어디에 사용하는지, 무엇을 보호하려는지를 보면 된다.

이 글에서는 네 가지 용어를 비교하고, 하나의 서비스를 개발하고 운영하는 상황에서 각각 어떤 역할을 하는지 살펴본다.

1. 먼저 전체 그림부터 보기

여기서 AISecOps는 사용하는 조직과 자료에 따라 의미가 달라질 수 있다. 어떤 곳은 AI 기반 보안 분석을, 다른 곳은 AI 시스템과 에이전트를 안전하게 운영하는 활동을 강조한다.

따라서 이 용어를 접하면 먼저 “AI로 보안을 하는가, AI 자체를 보호하는가?”를 확인하는 편이 좋다. 실제로 AISecOps Interceptor 프로젝트는 실행하는 AI 시스템의 런타임 거버넌스에 초점을 맞춘다. 이는 해당 프로젝트의 정의로 이해해야 한다.

2. DevOps: 개발과 운영이 서비스의 전체 흐름을 함께 책임진다

개발팀이 기능을 완성해 운영팀에 전달했다고 가정해 보자.

개발 환경에서는 잘 동작했는데 실제 서버에서는 오류가 발생한다. 운영팀은 배포 정보를 충분히 전달받지 못했고, 개발팀은 운영 환경을 정확히 모른다.

이런 단절을 줄이기 위해 개발과 운영의 협업을 강조하는 접근이 DevOps다.

DevOps는 도구와 자동화뿐 아니라 팀이 책임을 공유하고 운영 결과를 개발에 반영하는 방식까지 포함한다. CI/CD는 이를 구현하는 대표적인 수단이다. IBM의 DevOps 설명

예를 들어 다음과 같은 흐름을 만들 수 있다.

코드 변경
   ↓
자동 빌드 및 테스트
   ↓
배포 준비
   ↓
서비스 배포
   ↓
운영 상태 확인
   ↓
다음 변경에 반영

이 글의 예시에서 중요한 변화는 “배포가 끝났다”의 기준이다.

파일을 서버에 올리는 것으로 끝내지 않고, 사용자 요청이 정상적으로 처리되는지까지 확인한다. 문제가 생기면 변경 사항을 추적하고 복구할 수 있어야 한다.

DevOps를 도입할 때는 다음 질문이 유용하다.

• 동일한 코드를 같은 방식으로 다시 배포할 수 있는가?
• 어떤 변경이 언제 배포됐는지 추적할 수 있는가?
• 장애가 생겼을 때 개발팀과 운영팀이 같은 정보를 보는가?
• 문제가 있는 배포를 되돌릴 수 있는가?

이 질문에 답하는 과정이 도구의 개수보다 중요하다.

3. DevSecOps: 개발과 운영의 흐름에 보안을 통합한다

배포가 빨라지면 보안 검토 방식도 달라져야 한다.

개발이 모두 끝난 뒤 보안팀이 한 번 검토하는 방식으로는, 자주 변경되는 서비스의 위험을 따라가기 어렵다.

DevSecOps는 설계·개발·테스트·배포·운영 전반에 보안을 통합하고, 개발팀·보안팀·운영팀이 책임을 공유하는 접근이다. IBM의 DevSecOps 설명

예시 파이프라인은 다음처럼 확장할 수 있다.

설계 및 위협 검토
   ↓
코드 작성
   ↓
테스트 + 코드·의존성·비밀정보 검사
   ↓
배포 구성 검토
   ↓
정책에 따른 배포
   ↓
운영 중 탐지 및 취약점 대응

여기서 각 검사는 서로 다른 문제를 찾는다.

이 표는 구현 활동을 이해하기 위한 예시다. 모든 조직이 동일한 도구나 순서로 구성해야 한다는 뜻은 아니다.

또한 스캐너를 연결했다고 보안 문제가 자동으로 해결되지는 않는다. 검사 결과를 누가 검토하고, 어떤 기준으로 수정하며, 예외를 언제 재검토할지까지 정해야 실제 업무가 된다.

예를 들어 취약점이 발견됐을 때 다음 정보가 있으면 판단하기 쉽다.

• 해당 서비스에서 문제가 되는 기능을 실제로 사용하는가?
• 외부에서 접근할 수 있는가?
• 수정된 버전이 있는가?
• 즉시 수정하기 어렵다면 적용할 완화 조치가 있는가?

DevSecOps는 이런 판단을 개발과 운영 흐름 안에서 지속하는 방식으로 이해하면 된다.

4. AIOps: AI를 활용해 IT 운영 데이터를 분석한다

AIOps는 일반적으로 Artificial Intelligence for IT Operations를 의미한다.

로그, 메트릭, 이벤트 등 운영 데이터를 분석해 중요한 이상 신호를 찾고, 연관된 문제를 묶거나 장애 원인 후보를 좁히는 데 AI와 머신러닝을 활용한다. 생성형 AI가 반드시 필요한 개념은 아니다. IBM의 AIOps 설명

여기서 자주 생기는 혼동이 있다.

AIOps의 기본 의미는 ‘AI 모델을 운영하는 일’이 아니라, ‘IT 운영에 AI를 활용하는 일’이다.

예를 들어 쇼핑몰에서 다음 알림이 동시에 발생했다고 하자.

상품 API 응답 지연
결제 API 타임아웃
DB 연결 대기 증가
일부 애플리케이션의 CPU 사용률 상승

담당자는 각각의 알림을 조사해야 한다. 하지만 모두 하나의 문제에서 파생됐을 수도 있다.

AIOps의 대표적인 활용은 이런 이벤트의 시간과 관계를 분석해, 같은 장애와 관련될 가능성이 높은 신호를 모으는 것이다. AIOps의 이벤트 연관 분석

이 사례에서 운영자가 받고 싶은 결과는 다음과 같다.

관측된 현상:
여러 API에서 같은 시간대에 지연 발생

우선 확인할 대상:
DB 연결 대기 증가

추가 확인:
최근 배포와 연결 설정 변경 여부

이 결과는 조사할 가설이다. AI가 원인을 확정했다고 받아들이기보다는 실제 지표와 변경 이력을 확인해야 한다.

실무에서 시도해 볼 만한 적용 범위는 다음과 같다.

• 반복되는 알림을 묶어 전달하기
• 장애 관련 로그를 찾아 요약하기
• 최근 배포와 이상 발생 시점을 비교하기
• 담당 팀에 조사 자료를 모아 전달하기

처음에는 분석과 추천부터 시작하고, 검증 결과에 따라 자동 조치 범위를 늘리는 구성을 고려할 수 있다.

5. AISecOps: AI로 보안을 운영하는가, AI를 안전하게 운영하는가?

AISecOps를 이해할 때는 두 가지 방향을 나눠 보면 편하다.

이 구분은 이 글에서 혼동을 줄이기 위해 사용하는 설명 방식이다.

5-1. AI를 활용한 보안 운영

첫 번째 방향은 보안 담당자의 분석과 대응에 AI를 활용하는 것이다.

예를 들어 여러 경보를 요약하거나, 의심스러운 활동의 조사 순서를 제안하고, 보안 로그를 조회할 쿼리 작성을 돕는 방식이다.

Microsoft Security Copilot도 사고 대응, 위협 헌팅, 정보 수집, 보안 상태 관리 등을 지원하는 생성형 AI 보안 솔루션으로 설명된다. Microsoft 공식 문서

가상의 계정 침해 조사에서는 다음과 같이 활용할 수 있다.

로그인 및 보안 이벤트 수집
   ↓
AI가 사건의 시간 순서 요약
   ↓
추가 조사 항목 제안
   ↓
담당자가 근거 확인
   ↓
계정 보호 및 대응

AIOps와 데이터 분석 방식이 겹칠 수 있지만, 이 예시의 목표는 보안 사고 조사다.

5-2. AI 시스템 자체의 보안 운영

두 번째 방향은 AI 서비스와 에이전트를 보호하고 통제하는 것이다.

AI 시스템도 일반 소프트웨어와 마찬가지로 접근 통제와 기반 인프라 보안이 필요하다. 여기에 모델, 데이터, 입력과 출력 등 AI와 관련된 위험을 함께 고려해야 한다. NIST도 일반적인 사이버보안 위험과 AI 고유의 위험이 겹친다고 설명한다. NIST의 AI 보안·복원력 설명

특히 에이전트가 외부 도구를 실행하면, 잘못된 판단이 실제 작업으로 이어질 수 있다.

예를 들어 운영 지원 에이전트가 로그를 읽는 권한과 서버 설정을 바꾸는 권한을 모두 가지고 있다고 하자. 외부 입력이나 도구 결과를 잘못 해석하면 의도하지 않은 변경을 시도할 수 있다.

OWASP는 과도한 기능, 권한, 자율성이 결합해 피해를 일으키는 위험을 Excessive Agency로 설명한다. OWASP: Excessive Agency

이런 시스템에서는 다음과 같은 운영 설계를 검토할 수 있다.

• 에이전트에 업무에 필요한 최소 권한만 부여하기
• 읽기 작업과 변경 작업의 권한을 구분하기
• 영향이 큰 작업에는 승인 절차 적용하기
• 도구 호출의 대상과 인자를 실행 전에 검증하기
• 실행 기록과 결과를 남기기
• 작업 횟수·시간·비용에 한도를 설정하기

핵심은 AI의 답변 품질과 함께 실제로 실행할 수 있는 행동의 범위를 관리하는 것이다.

6. 하나의 장애 상황에서 비교해 보기

이제 가상의 쇼핑몰에 결제 기능을 배포했다고 가정해 보자.

DevOps 관점

코드 변경이 테스트와 배포를 거쳐 서비스에 반영된다. 배포 후 결제 성공률과 오류율을 확인하고, 문제가 있으면 복구한다.

관심사는 변경을 전달하고 운영 결과를 반영하는 흐름이다.

DevSecOps 관점

결제 기능의 권한과 데이터 흐름을 검토한다. 코드와 의존성 등을 검사하고, 발견된 위험을 처리한 뒤 배포한다. 운영 중 발견된 취약점도 수정 흐름으로 연결한다.

관심사는 변경 과정과 운영 전반의 보안이다.

AIOps 관점

배포 이후 여러 서비스에서 발생한 알림을 분석한다. 결제 오류와 DB 대기 증가가 함께 발생했다면 관련성을 제시하고 조사할 대상을 좁힌다.

관심사는 운영 데이터에서 문제의 신호를 찾는 일이다.

AI 기반 보안 운영 관점

같은 시간대의 비정상 로그인과 권한 변경을 분석한다. 단순 장애 외에 침해 가능성도 조사한다.

관심사는 위협의 탐지와 조사다.

AI 시스템 보안 운영 관점

조사를 지원하는 에이전트가 어떤 로그를 읽고 어떤 명령을 실행할 수 있는지 통제한다. 결제 서비스 설정을 바꾸는 작업은 별도의 정책으로 검증한다.

관심사는 조사 도구로 사용되는 AI의 행동과 권한이다.

이처럼 하나의 서비스 안에서 여러 접근이 함께 적용될 수 있다.

7. MLOps와 LLMOps는 어디에 해당할까?

AIOps와 함께 자주 등장하는 용어가 MLOps와 LLMOps다.

MLOps는 머신러닝 모델을 실제 환경에서 개발·배포·관리하는 생애주기에 초점을 맞춘다. IBM도 AIOps와 MLOps를 이 기준으로 구분한다. IBM Developer의 Ops 비교

LLMOps는 보통 그중 LLM 기반 시스템의 평가와 운영을 강조할 때 사용한다.

대상을 기준으로 비교하면 이해하기 쉽다.

실제 조직에서는 이 업무들이 겹친다. 추천 모델을 배포하는 팀도 DevSecOps를 적용할 수 있고, LLM 서비스의 장애를 AIOps 도구로 분석할 수도 있다.

8. 우리 팀은 어디서부터 시작하면 좋을까?

도입 방향을 정할 때는 팀에서 반복되는 문제를 먼저 적어 보는 것을 권한다.

이 표는 도입을 위한 제안이다. AI를 적용하기 전에 데이터와 책임 범위가 정리돼 있는지도 함께 살펴봐야 한다.

서비스 이름이 시스템마다 다르고, 변경 이력이 남지 않으며, 담당자 정보도 없다면 AI 분석 결과를 검증하기 어렵다. 에이전트가 어떤 권한으로 작업하는지 모른다면 자동화 범위를 넓히기도 어렵다.

작게 시작하는 방법은 다음과 같다.

1. 반복되는 업무 하나를 선택한다.
2. 필요한 데이터와 담당자를 정한다.
3. 현재 걸리는 시간과 오류를 기록한다.
4. 자동화 또는 AI 보조를 적용한다.
5. 절약한 시간과 잘못된 결과를 함께 평가한다.
6. 검증된 범위부터 확대한다.

“AI를 도입했다”보다 “장애 조사에 필요한 자료를 모으는 시간이 줄었다”처럼 구체적인 결과를 확인하는 편이 유용하다.

9. 성과는 어떤 지표로 확인할까?

이 글에서 제안하는 평가 예시는 다음과 같다.

속도와 정확도를 함께 봐야 한다.

알림을 줄였지만 중요한 장애까지 숨겼다면 개선으로 보기 어렵다. 조사 보고서를 빨리 만들었어도 근거가 틀렸다면 검토 부담이 늘어난다. 에이전트의 작업 성공률이 높아도 허용 범위를 벗어났다면 통제를 다시 살펴봐야 한다.

팀이 원하는 결과를 먼저 정의해야 지표도 의미가 생긴다.

마치며

DevOps는 개발과 운영을 연결하고, DevSecOps는 그 흐름에 보안을 통합한다. AIOps는 운영 데이터를 분석하는 데 AI를 활용한다.

AISecOps는 자료마다 강조점이 다르므로 적용 범위를 확인해야 한다. 이 글에서는 AI를 활용한 보안 운영과 AI 시스템 자체의 보안 운영으로 나누어 살펴봤다.

앞으로 에이전트가 더 많은 도구를 실행하게 되면, 분석 결과를 검토하는 일과 실행 권한을 관리하는 일이 모두 중요해질 것이다.

새로운 용어를 도입할 때 우리 팀이 먼저 답해야 할 질문도 구체적이다.

어떤 업무를 개선하려는가? 어떤 근거로 효과를 확인할 것인가? 자동화에는 어디까지 권한을 줄 것인가?

기업에서 생성형 AI를 활용하는 방식은 빠르게 발전하고 있다. 초기에는 사내 문서를 검색해 답변하는 RAG가 중심이었다. 이후 AI가 문서를 작성하거나 시스템을 조작하는 업무자동화 단계로 넘어갔고, 최근에는 여러 AI 에이전트가 역할을 나누어 협업하는 구조가 주목받고 있다.

이 과정에서 등장한 핵심 기술이 MCP와 A2A다.

RAG만으로 업무자동화가 어려운 이유

RAG(Retrieval-Augmented Generation)는 AI가 외부 지식을 검색해 답변하도록 만드는 기술이다. 사내 규정, 업무 매뉴얼, 상품 설명서와 같은 문서를 검색하고 관련 내용을 생성형 AI에 전달함으로써 답변의 정확도를 높인다.

하지만 RAG의 역할은 기본적으로 ‘정보 제공’에 가깝다.

예를 들어 사용자가 “지난달 매출 실적을 분석하고 부진한 상품의 프로모션 계획을 만들어줘”라고 요청했다고 가정해 보자. 이 업무를 완료하려면 AI가 다음과 같은 작업을 수행해야 한다.

1. 데이터베이스에서 매출 데이터 조회
2. 상품별 실적 분석
3. 재고 시스템 확인
4. 프로모션 계획 작성
5. 담당자에게 검토 요청
6. 승인 후 마케팅 시스템에 등록

문서를 검색하는 것만으로는 이 과정을 모두 처리하기 어렵다. AI가 데이터와 업무 도구에 접근하고, 다른 에이전트와 협력할 수 있어야 한다.

MCP란 무엇인가

MCP(Model Context Protocol)는 AI 애플리케이션이 외부 데이터와 도구를 일정한 방식으로 연결하도록 만든 개방형 프로토콜이다.

기존에는 AI 모델을 데이터베이스, 파일 시스템, 협업 도구 또는 사내 API와 연결할 때마다 별도의 연동 코드를 개발해야 했다. 연결 대상이 늘어날수록 개발과 유지보수 부담도 커졌다.

MCP는 AI가 사용할 수 있는 데이터와 기능을 표준화된 형태로 제공한다. 이를 통해 AI 에이전트는 사내 문서 검색, 데이터베이스 조회, 이메일 발송, 일정 확인, 파일 생성과 같은 기능을 발견하고 사용할 수 있다.

쉽게 표현하면 MCP는 AI 에이전트가 업무 도구를 연결할 수 있게 해주는 ‘공통 연결 규격’이다.

A2A란 무엇인가

MCP가 에이전트와 도구를 연결한다면, A2A(Agent-to-Agent)는 서로 다른 AI 에이전트를 연결한다.

하나의 에이전트가 모든 업무를 담당하게 만들면 시스템이 지나치게 복잡해질 수 있다. 실제 기업에서는 역할별 에이전트를 구성하는 방식이 더 현실적이다.

예를 들어 고객의 환불 요청을 처리할 때 다음과 같이 역할을 나눌 수 있다.

• 고객상담 에이전트: 요청 내용 파악
• 주문관리 에이전트: 주문과 배송 상태 확인
• 정책 에이전트: 환불 규정 판단
• 결제 에이전트: 환불 실행
• 감사 에이전트: 처리 과정 기록

A2A는 서로 다른 회사나 개발 프레임워크에서 만들어진 에이전트가 상대방의 기능을 확인하고, 작업을 요청하며, 처리 결과를 주고받도록 지원한다.

Linux Foundation에 따르면 A2A는 2026년 4월 기준 150개 이상의 조직이 지원하고 있으며 Google, Microsoft, AWS를 비롯한 주요 플랫폼에 통합되고 있다. 공급망, 금융, 보험, IT 운영 분야에서는 실제 적용도 시작됐다.

참고: Linux Foundation A2A 발표

MCP와 A2A의 차이

구분 MCP A2A

RAG가 AI에게 필요한 지식을 제공한다면 MCP는 업무 도구를 제공하고, A2A는 함께 일할 동료 에이전트를 연결한다.

표준화가 모든 문제를 해결하지는 않는다

연결이 쉬워질수록 보안 문제는 더 중요해진다. MCP 서버나 외부 에이전트가 신뢰할 수 없는 정보를 제공할 수도 있고, AI가 필요 이상의 권한을 사용할 수도 있다.

따라서 기업은 다음과 같은 통제 체계를 함께 마련해야 한다.

• 에이전트별 최소 권한 부여
• 사용자와 에이전트의 신원 확인
• 중요한 작업에 대한 사람의 승인
• 도구 호출과 에이전트 통신 기록
• 외부 에이전트의 신뢰 수준 검증
• 입력 데이터와 응답에 대한 보안 검사

결국 MCP와 A2A는 연결을 위한 기술 표준이지, 보안과 거버넌스를 자동으로 보장하는 기술은 아니다.

마치며

기업의 생성형 AI는 문서를 검색하는 RAG에서 실제 업무를 수행하는 AI 에이전트로 발전하고 있다. 앞으로는 하나의 강력한 모델보다 여러 시스템과 에이전트를 안전하게 연결하고 조정하는 능력이 더욱 중요해질 것이다.

RAG가 기업 지식을 AI와 연결했다면 MCP는 AI와 업무 도구를 연결하고, A2A는 AI와 AI를 연결한다. 이 세 가지 기술의 결합이 지식 기반 업무자동화의 다음 단계를 만들고 있다.

RAG에서 지식 기반 업무자동화로의 발전

• 핵심 내용:
  • RAG(Retrieval-Augmented Generation)는 사용자의 질문과 관련된 사내 문서나 데이터 조각을 검색해 LLM에 제공하고, 그 근거를 바탕으로 답변을 생성하는 구조다. 모델을 다시 학습시키지 않고도 최신 내부지식을 활용하고 환각을 줄일 수 있다.
  • 초기 RAG는 질문 → 한 번 검색 → 답변하는 지식검색·챗봇 중심이었다. 최근의 Agentic RAG·Agentic Retrieval은 복잡한 질문을 여러 하위 질문으로 나누고, 다양한 지식원을 반복 검색하며, 부족한 정보를 다시 찾고, 결과를 교차검증한다.
  • 다음 단계인 지식 기반 업무자동화는 검색 결과를 답변으로 끝내지 않는다. 업무 규정과 사례를 근거로 신청서 검토, 데이터 대조, 보고서 초안, 담당자 배정, 보완요청 생성, 승인 요청과 시스템 입력까지 연결한다.
  • 발전 단계는 문서검색 → 근거 있는 질의응답 → 여러 출처의 종합·분석 → 업무 판단 보조 → 승인 기반 실행 → 결과 기록과 학습으로 볼 수 있다.
  • 핵심은 LLM 단독 성능이 아니라 데이터 수집·OCR·청킹·메타데이터·검색·재순위화·권한필터·도구연결·평가·감사까지 포함한 전체 시스템 품질이다.
• 주목받는 이유:
  • 기업은 생성형 AI의 시범 챗봇을 넘어 실제 처리시간 단축과 업무성과를 요구하고 있다. 단순 답변보다 사내 지식과 업무시스템을 연결한 자동화의 가치가 크다.
  • 규정과 매뉴얼이 자주 바뀌는 공공·금융·의료 분야에서는 모델이 학습한 과거 지식보다 현재 시행 중인 원문을 검색해 근거와 기준일을 제시하는 방식이 필요하다.
  • 긴 문서를 모두 프롬프트에 넣으면 비용이 증가하고 중요한 내용을 놓치는 ‘컨텍스트 부패’가 발생할 수 있다. 필요한 순간에 관련 정보만 가져오는 검색과 컨텍스트 엔지니어링이 중요해졌다.
  • 2026년 Azure 등 주요 플랫폼은 기본 RAG보다 복잡한 질문을 분해하고 반복 검색하는 Agentic Retrieval을 현대적인 RAG 방식으로 권장하고 있다.
• 관련 기술·용어:
  • Embedding·Vector Database: 문서와 질문의 의미를 벡터로 표현하고 유사한 정보를 검색
  • Hybrid Search: 키워드 검색과 벡터 검색을 결합해 정확한 용어와 의미 유사성을 함께 반영
  • Semantic Reranking: 1차 검색 결과를 질문과의 관련성에 따라 다시 정렬
  • Chunking: 긴 문서를 검색하기 좋은 단위로 분할하는 과정
  • Metadata Filtering: 기관, 부서, 문서종류, 시행일, 보안등급 등으로 검색범위를 제한
  • Agentic Retrieval: 질문분해, 다중 검색, 후속질문, 결과통합을 에이전트가 반복 수행
  • Knowledge Graph: 개체와 관계를 그래프로 표현해 규정·조직·업무 간 연결을 탐색
  • Context Engineering: 시스템 지시, 검색자료, 도구, 메모리, 대화이력 중 현재 작업에 필요한 정보를 선별·관리
  • Tool Use·Function Calling: LLM이 검색뿐 아니라 API와 업무시스템 기능을 호출
  • Grounding·Citation: 답변을 검색된 근거에 연결하고 출처를 표시
  • RAG Evaluation: 검색 적중률, 답변 충실성, 근거 일치도, 업무완료율 등을 평가
• 기업·산업에 미치는 영향:
  • 사내 문서검색이 개인의 노하우에 의존하던 방식에서, 기관 전체의 규정·사례·업무이력을 활용하는 지식 플랫폼으로 변화한다.
  • 신입직원의 업무 숙련시간을 줄이고 담당자마다 다른 답변을 표준화할 수 있다.
  • 단순·반복적인 자료조회와 초안 작성을 자동화해 직원은 예외판단, 민원 설득, 정책개선과 같은 고부가가치 업무에 집중할 수 있다.
  • 문서가 AI의 업무 근거가 되므로 문서 소유자, 시행일·폐기일, 버전, 보안등급과 품질을 관리하는 지식 거버넌스의 중요성이 커진다.
  • 기존 ERP·그룹웨어·전자결재·민원·CRM 시스템이 API와 MCP 같은 표준 인터페이스를 통해 AI 에이전트의 도구로 연결된다.
• 실제 활용 사례:
  • 규정 질의응답: 현행 규정과 FAQ를 검색해 답변하고 조항, 문서명, 시행일과 원문 링크를 함께 제시한다.
  • 민원처리 자동화: 민원을 분류하고 관련 규정·과거 사례를 검색해 답변 초안을 작성한 뒤 담당자에게 배정한다. 승인 후 발송하고 처리결과를 기록한다.
  • 한국장학재단: 국가장학금 신청정보와 학적·소득 자료를 대조하고 현행 지침을 검색해 누락서류와 보완요청 초안을 생성할 수 있다.
  • 국민건강보험공단: 자격·보험료 문의에 적용되는 법령과 지침을 검색하고 가입자의 상황에 맞는 처리절차를 제시하되 개인정보 조회와 처분은 권한검사·승인을 거친다.
  • 건강보험심사평가원: 청구명세와 심사기준·고시·과거 사례를 연결해 검토 근거를 제시하고, 전문가가 최종 판단하도록 지원할 수 있다.
  • IT 운영: 장애 로그, 변경이력, 운영매뉴얼과 과거 장애보고서를 검색해 원인 후보와 복구절차를 제안하고 작업계획을 결재로 연결한다.
• 한계 및 위험 요소:
  • 잘못된 검색: 가장 관련 있는 문서를 찾지 못하면 모델이 검색 결과에 충실해도 답변은 틀릴 수 있다.
  • 낡은 문서: 폐기된 규정이나 중복 문서가 검색되면 잘못된 업무처리로 이어진다.
  • 권한 누출: 검색 단계에서 사용자에게 권한이 없는 문서가 프롬프트나 답변에 포함될 수 있다.
  • 프롬프트 인젝션: 검색 문서에 숨겨진 악성 지시가 에이전트의 도구 호출과 데이터 유출을 유도할 수 있다.
  • 출처의 형식적 표시: 인용 링크가 존재해도 실제 주장과 근거가 일치하지 않을 수 있다.
  • 자동화 오류의 확대: 잘못된 답변 한 건이 아니라 잘못된 시스템 입력·대량 발송·처분으로 피해가 커질 수 있다.
  • 비용과 지연: 다단계 검색·재순위화·모델 호출은 품질을 높이지만 응답시간과 비용을 증가시킨다.
  • 대응 방향: 현행 문서 우선순위, 권한 기반 검색, 문서 버전관리, 검색·답변의 분리평가, 인용 검증, 고위험 실행 승인, 전체 작업로그와 롤백을 적용해야 한다.
• 내 생각:
  • RAG의 경쟁력은 벡터DB를 도입했는지가 아니라 올바른 문서를 올바른 권한과 시점에 찾아 실제 업무를 얼마나 정확하게 완료하는지에 달려 있다고 생각한다.
  • 업무자동화를 서두르기보다 먼저 기관의 문서체계와 데이터 품질을 정비해야 한다. AI는 혼란스러운 지식관리 체계를 자동으로 해결하기보다 그 혼란을 더 빠르게 확산시킬 수 있기 때문이다.
  • 공공기관에서는 완전자동화보다 “AI가 근거와 처리안을 제시하고 사람이 예외와 최종 처분을 판단하는 구조”가 현실적이다. 반복업무는 줄이면서 적법절차와 책임성을 유지할 수 있다.
• 출처 및 확인 날짜:
  • Microsoft Azure AI Search, Agentic Retrieval Overview
  • Microsoft Azure Cosmos DB, Agentic Retrieval Toolkit
  • Google Cloud, RAG Infrastructure Reference Architecture
  • Google Cloud, RAG Engine Overview
  • Anthropic, Effective Context Engineering for AI Agents
  • 확인 날짜: 2026-07-26

금융권 생성형 AI와 AI 에이전트

한눈에 보기

• 핵심: 생성형 AI가 질문에 답하는 도구에서 벗어나, 여러 시스템과 도구를 사용해 업무를 계획하고 실행하는 AI 에이전트로 발전하고 있다.
• 금융권의 변화: 상담·문서 요약 같은 보조 업무를 넘어 신용분석, 상품 추천, 이상거래 조사, 내부통제 점검 등으로 활용 범위가 넓어지고 있다.
• 중요한 조건: 금융에서는 정확성, 개인정보보호, 설명 가능성, 접근권한과 최종 책임을 확보해야 실제 업무에 적용할 수 있다.

1. 핵심 개념

생성형 AI

대규모 데이터를 학습한 모델이 질문에 대한 답변, 보고서, 코드, 이미지 등 새로운 결과물을 생성하는 기술이다.

AI 에이전트

사용자의 목표를 받아 다음 행동을 계획하고, API·DB·검색·업무시스템 같은 도구를 호출하며, 결과를 확인해 후속 작업까지 수행하는 시스템이다.

사용자 목표
  → 업무 계획
  → 필요한 데이터 조회
  → 도구·시스템 실행
  → 결과 검증
  → 사용자 승인 또는 최종 처리

단순 챗봇과의 가장 큰 차이는 답변 생성에 그치지 않고 외부 시스템에서 행동을 수행한다는 점이다.

2. 주목받는 이유

1. 자연어로 복잡한 금융 업무를 처리해 직원 생산성과 고객 편의성을 높일 수 있다.
2. 여러 시스템에 흩어진 정보를 검색·요약해 의사결정 시간을 줄일 수 있다.
3. 반복적인 심사·보고·점검 업무를 자동화할 수 있다.
4. 금융당국의 규제 개선으로 실제 금융 서비스 적용 속도가 빨라지고 있다.

금융위원회는 2026년 4월 보안 위험이 낮은 단순 생성형 AI 모델 변경의 경우 혁신금융서비스 재지정 없이 서면확인으로 출시할 수 있도록 절차를 간소화했다. 이는 금융회사 내부 업무 효율화와 AI 기반 금융서비스 출시가 더 빨라질 수 있음을 의미한다.

3. 금융권 활용 사례

분야 활용 예시 기대 효과

AI가 대출 승인이나 송금 같은 중대한 결정을 완전히 단독 수행하기보다는, 위험도에 따라 사람의 승인과 검증을 포함하는 구조가 적절하다.

4. 핵심 기술

• RAG: 내부 규정·상품 설명서·공시 등 신뢰할 수 있는 문서를 검색한 후 답변 생성
• 도구 호출: API, 데이터베이스, 업무시스템을 AI가 정해진 방식으로 이용
• 에이전트 오케스트레이션: 계획, 실행, 검증 등 여러 단계와 역할을 관리
• 가드레일: 금지된 요청·개인정보·위험한 행동을 탐지하고 제한
• LLMOps: 모델 버전, 프롬프트, 품질, 비용, 지연시간과 오류를 지속 관리
• 평가 체계: 정확성, 근거성, 안전성, 편향, 보안과 업무 성과를 측정

5. 한계와 위험 요소

위험 설명 대응 방향

출처

• 금융위원회 — 생성형 AI 모델 변경 시 혁신금융서비스 절차 개선 (2026-04-15)
• NIST — AI Agent Standards Initiative (2026)
• NIST — AI 에이전트 보안 고려사항 분석 (2026-05-18)
• IBK기업은행 — 2025 연차보고서 및 2026 추진 방향