"Show me all running EC2 instances in us-east-1," 이 한 문장이면 충분합니다. 복잡한 AWS 관리 콘솔을 헤매거나 CLI(명령줄 인터페이스) 문서를 뒤질 필요 없이, SRE(사이트 신뢰성 엔지니어)나 DevOps(개발과 운영의 통합) 엔지니어가 평소 쓰는 말로 인프라 상태를 확인할 수 있게 된 것입니다.

그동안 엔지니어들은 비즈니스 요구사항을 정확한 API 구문으로 바꾸고, 여러 서비스의 대시보드를 오가며 소위 '컨텍스트 스위칭' 비용을 지불해 왔습니다. 장애가 발생하면 CloudWatch 로그를 보고, EC2(가상 서버) 상태를 확인한 뒤, 다시 IAM(권한 관리) 정책을 대조하는 식의 파편화된 작업이 반복되었습니다. 이러한 마찰은 인프라 규모가 커질수록 기하급수적으로 늘어나며, 결국 단순 반복적인 스크립트 작성에 많은 시간을 뺏기는 결과로 이어졌습니다.

이제 Amazon Bedrock AgentCore Runtime(에이전트 실행 환경)과 MCP(모델 컨텍스트 프로토콜, AI 모델이 외부 도구와 소통하는 표준 규격) 지원을 통해 이 과정이 완전히 바뀝니다. Amazon Quick과 AWS 서비스를 직접 연결하는 AWS API MCP 서버를 통해, 자연어 질의를 즉각적인 AWS API 호출로 변환하는 대화형 AI 어시스턴트 구현이 가능해졌기 때문입니다.

Bedrock AgentCore Runtime과 MCP 서버의 구성 요소

사용자가 Amazon Quick(사용자와 AI가 소통하는 인터페이스)에 접속해 자연어로 명령을 내리는 순간부터 전체 프로세스가 시작된다. 이 요청은 가장 먼저 Amazon Bedrock AgentCore Runtime(에이전트 실행 및 보안 경계 역할)으로 전달된다. 쉽게 말하면 AgentCore Runtime은 입구에서 출입증을 검사하고 내부 작업을 지휘하는 총괄 매니저와 같다. 이 매니저는 요청이 안전한지 확인하고 적절한 도구에 연결하는 보안 경계 역할을 수행하며 전체적인 에이전트 실행 과정을 관리한다. 기존에는 SRE(Site Reliability Engineering, 사이트 신뢰성 공학) 엔지니어가 직접 콘솔과 CLI 문서를 오가며 명령어를 조합해야 했지만 이제는 이 런타임이 그 과정을 자동화하여 도구 간 전환 비용을 줄인다.

자연어를 실제 AWS 명령어로 바꾸는 핵심 장치는 AWS API MCP Server(자연어를 AWS CLI 명령어로 변환하는 브릿지)다. 여기서 MCP는 모델 컨텍스트 프로토콜(Model Context Protocol)의 약자로 AI 모델이 외부 도구와 소통하는 표준 방식을 의미한다. 비유하자면 외국어로 된 주문서를 읽고 주방장이 이해할 수 있는 표준 레시피로 번역해 주는 전문 통역사와 같다. 예를 들어 사용자가 특정 지역의 실행 중인 EC2 인스턴스를 보여달라고 말하면 MCP 서버가 이를 정확한 AWS CLI(Command Line Interface, 명령줄 인터페이스) 명령어로 변환해 전달한다. 이 통역사 역할을 하는 서버 이미지는 Amazon ECR(Elastic Container Registry, 컨테이너 저장소)에 저장되어 있으며 필요할 때마다 호출되어 실행된다. 최신 이미지는 AWS Marketplace – AWS API MCP Server에서 확인할 수 있다.

보안의 핵심은 Amazon Cognito(인증 및 인가 서비스)가 담당한다. Cognito는 사용자가 누구인지 확인하고 권한을 부여하기 위해 JWT(JSON Web Token, 디지털 신분증과 같은 토큰)를 발행한다. 사용자가 요청을 보낼 때 이 토큰을 함께 제출하면 AgentCore Runtime이 이를 검증해 허가된 사용자만 명령을 내릴 수 있게 제어한다. 쉽게 말하면 Cognito가 신분증을 발급하고 AgentCore Runtime이 그 신분증의 진위 여부를 판별하는 구조다. 특히 Cognito에서 설정한 OAuth 2.0 스코프(Scope, 권한 범위)를 통해 읽기나 쓰기 같은 세부 권한을 제어하며 MCP 서버 자체는 AgentCore Runtime이 이미 검증을 마쳤다는 신뢰를 바탕으로 동작한다. 이렇게 구성된 5가지 스택은 복잡한 API 문법을 몰라도 자연어만으로 인프라를 정교하게 제어할 수 있는 기반이 된다.

JWT 인증부터 API 실행까지의 4단계 동작 원리

사용자가 시스템에 접근할 때 가장 먼저 마주하는 관문은 디지털 신분증을 발급받는 과정이다. 아마존 코그니토 유저 풀(Amazon Cognito User Pool, 사용자 인증 및 권한 관리 서비스)이 이 역할을 맡아 JWT(JSON Web Token, 인증 정보를 담은 암호화 토큰)를 생성해 사용자에게 전달한다. 쉽게 말하면 놀이공원 입구에서 본인 확인을 거쳐 자유이용권을 받는 것과 같다. 이렇게 발급된 토큰은 이후 모든 요청의 Authorization 헤더에 베어러(Bearer) 토큰 형태로 포함되어 에이전트코어 런타임(AgentCore Runtime, AI 에이전트를 실제로 구동하는 실행 환경)으로 전달되며, 시스템은 이 토큰을 통해 요청자가 누구인지 식별한다.

전달받은 토큰이 위조되지 않았는지 검증하는 단계는 보안의 핵심이다. 에이전트코어 런타임은 자격 증명 제공자(IdP)의 디스커버리 URL을 통해 토큰의 서명과 유효성을 실시간으로 확인한다. 비유하자면 보안 요원이 신분증의 홀로그램이 진짜인지 확인하기 위해 본사의 공식 검증 서버에 접속해 대조해보는 과정이다. 이때 사용되는 URL 패턴은 `https://cognito-idp.$REGION.amazonaws.com/$POOL_ID/.well-known/openid-configuration` 형태로, 여기서 공개 키 정보를 가져와 토큰의 암호화 서명을 해독하고 만료 여부를 판별한다. 이 엄격한 검증 과정을 통과하지 못한 요청은 즉시 거부되어 내부 인프라에 접근할 수 없다.

신분 확인이 끝나면 이제 요청자가 어떤 작업까지 수행할 수 있는지 결정하는 권한 매핑 단계로 진입한다. 특히 기계 간 통신(Machine-to-machine) 애플리케이션 설정에서 정의한 읽기(Read)와 쓰기(Write) 스코프(Scope, 접근 허용 범위)가 MCP 서버가 사용하는 IAM(Identity and Access Management, AWS 자원 접근 제어 서비스) 권한과 1대1로 연결된다. 예를 들어 읽기 권한만 부여받은 사용자가 인프라 설정을 변경하려 하면, 시스템은 매핑된 IAM 정책을 확인해 해당 동작을 즉시 차단한다. 신분증에 적힌 등급에 따라 출입 가능한 구역과 사용할 수 있는 도구가 엄격하게 제한되는 체계라고 이해하면 쉽다.

마지막으로 실제 API 명령이 수행되는 MCP 서버 단계에서는 효율성을 위해 독특한 설정이 적용된다. 환경 변수에서 `AUTH_TYPE=no-auth`로 설정되는데, 이는 MCP 서버 자체가 개별적으로 인증 절차를 밟지 않는다는 의미다. 자칫 보안 구멍처럼 보일 수 있지만, 이미 앞단의 에이전트코어 런타임이 강력한 보안 경계 역할을 수행했기에 안전하다. 비유하자면 건물 정문에서 보안 요원이 신분증과 권한을 완벽하게 검사해 통과시킨 사람만 들어올 수 있는 내부 구역이기에, 정작 업무를 처리하는 담당자는 다시 신분증을 요구하지 않고 바로 명령을 수행하는 방식이다.

'수동 CLI 조합'과 '대화형 에이전트'의 작업 효율 비교

인프라 관리자가 장애를 처리하거나 자원을 점검할 때 가장 먼저 하는 일은 수많은 브라우저 탭을 빠르게 오가는 것이다. AWS 매니지먼트 콘솔(웹 기반의 서비스 관리 화면)에서 현재 상태를 확인하고, CLI(명령줄 인터페이스, 텍스트로 명령을 내리는 도구) 문서를 뒤져 정확한 옵션과 구문을 찾은 뒤, 다시 서비스 대시보드로 돌아와 결과를 대조하는 과정이 쉴 새 없이 반복된다. 비유하자면 요리를 하는데 재료 하나를 찾을 때마다 서로 다른 동네의 마트로 이동하며, 매번 두꺼운 레시피 책의 페이지를 처음부터 다시 넘겨 정확한 계량법을 찾는 상황과 비슷하다. 비즈니스 관점의 질문을 기술적인 API 구문으로 사람이 직접 번역하고 서비스 간의 호출 순서를 수동으로 연결해야 하기에, 작업자의 인지 부하가 커지고 흐름이 끊기는 마찰이 발생한다.

대화형 에이전트 방식은 이처럼 파편화된 작업 경로를 하나의 매끄러운 직선 흐름으로 통합한다. 관리자가 일상적인 언어로 질문을 던지면 에이전트가 이를 즉시 최적의 API 구문으로 변환해 실행하고 결과까지 반환하는 단일 인터페이스로 작동한다. 쉽게 말하면 전문 비서에게 필요한 결과물만 요청하면, 비서가 내부적으로 복잡한 매뉴얼을 찾고 적절한 도구를 사용해 정답만 요약해서 가져다주는 식이다. 예를 들어 특정 지역에서 실행 중인 인스턴스 목록을 보여달라고 말하면, 사용자가 직접 명령어를 조합하거나 여러 화면을 전환하며 데이터를 수집할 필요 없이 즉각적이고 정확한 답변을 얻게 된다. 이는 단순한 속도 향상을 넘어, 명령어를 외워야 한다는 심리적 부담을 없애고 작업의 정확도를 높이는 결과로 이어진다.

시스템 아키텍처 관점에서도 관리 효율이 크게 개선된다. 기존 방식에서는 개별 워크플로우를 구축할 때마다 서비스 간의 연결 로직을 매번 새로 짜야 했지만, 이제는 재사용 가능한 단일 통합 서버를 통해 AI 에이전트와 AWS 서비스가 상호작용하는 방식을 표준화한다. 비유하자면 매번 새로운 목적지로 갈 때마다 임시 도로를 닦는 대신, 이미 잘 구축된 고속도로 하나를 모든 차량이 공유하며 빠르게 이동하는 것과 같다. 여기에 기업 환경에서 필수적인 보안과 투명성까지 확보했다. 모든 요청과 실행 내역은 Amazon CloudWatch(AWS의 모니터링 및 로그 기록 서비스)에 상세히 기록된다. 이를 통해 나중에 누가 어떤 명령을 내렸는지 명확하게 추적하는 감사 경로를 확보할 수 있으며, 까다로운 기업의 컴플라이언스(법적 규제 준수) 기준을 자연스럽게 충족하게 된다.

SRE와 DevOps 엔지니어가 체감할 실질적 변화

SRE(사이트 신뢰성 엔지니어)와 DevOps(개발 및 운영 통합) 엔지니어들은 장애가 발생하면 AWS 관리 콘솔과 CLI(명령줄 인터페이스) 문서, 그리고 여러 서비스 대시보드를 쉴 새 없이 오간다. 비즈니스 요구사항을 정확한 API 구문으로 변환하고 여러 서비스에 걸쳐 호출 체인을 구성하는 과정에서 상당한 인지적 부하가 발생한다. 특히 긴박한 장애 대응 상황에서는 CloudWatch 로그와 EC2(가상 서버) 인스턴스 상태, IAM(ID 및 액세스 관리) 정책을 서로 다른 인터페이스에서 교차 참조해야 하므로 대응 속도가 늦어질 수밖에 없다. 이러한 도구 간의 전환은 단순한 불편함을 넘어 대응 골든타임을 놓치게 만드는 실질적인 병목 지점으로 작용해 왔다.

이번 변화는 이러한 도구 간의 전환 비용을 원천적으로 제거하는 데 집중한다. 비유하자면 수많은 매뉴얼 책자를 일일이 뒤져가며 조작법을 찾던 방식에서, 모든 매뉴얼을 숙지한 숙련된 조수에게 말로 지시하는 방식으로 바뀌는 것이다. 자연어 쿼리가 즉시 AWS API 호출로 변환되면 복잡한 구문을 외울 필요가 없어지며 이는 곧 MTTR(평균 복구 시간)의 단축으로 이어진다. 특히 인프라 쿼리에 대한 진입 장벽이 낮아지면서 신입 엔지니어들도 빠르게 상황을 파악할 수 있게 되며, 특정 숙련자에게만 의존하던 운영 구조에서 벗어나 팀 전체의 운영 효율이 상향 평준화되는 효과를 거둔다.

보안 체계의 변화는 더욱 실질적이다. 기존에는 운영 편의를 위해 개별 사용자 계정에 광범위한 권한을 부여하는 경우가 많았으나, 이제는 IAM 실행 역할(Execution Role)을 통해 제어된 권한만 부여한다. 쉽게 말하면 관리자 마스터 키를 사용자에게 직접 주는 대신, AI 에이전트가 특정 작업만 수행할 수 있도록 제한된 임시 출입증을 사용하는 구조다. 이는 보안의 핵심인 최소 권한 원칙을 구현하는 방식으로, 모든 요청은 기존 IAM 권한 내에서 안전하게 실행된다. 또한 모든 활동이 CloudWatch를 통해 상세한 감사 추적 기록으로 남으므로 규제 준수와 보안 감사를 동시에 해결할 수 있다.

실제 구현을 위한 AgentCore Runtime의 신뢰 정책과 실행 역할 설정은 다음과 같은 구조를 가진다.

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Principal": {

"Service": "bedrock.amazonaws.com"

},

"Action": "sts:AssumeRole"

}

]

}

이러한 설정은 AgentCore Runtime이 강력한 보안 경계 역할을 수행하게 만든다. 요청이 MCP(모델 컨텍스트 프로토콜) 서버에 도달하기 전 Runtime 단계에서 JWT(JSON 웹 토큰) 검증을 거치므로, 내부 서버는 이미 인증된 요청만을 처리하게 된다. 이는 인프라 제어권이라는 강력한 권한을 AI에게 맡기면서도, 실제 실행 단계에서는 엄격한 권한 제어 체계를 유지할 수 있게 하는 핵심 장치다. 결과적으로 운영자는 복잡한 설정 없이도 안전하게 자연어 기반의 인프라 제어 환경을 구축할 수 있다.

한국 AI 실무자를 위한 도입 가이드와 주의점

개발자가 초기 테스트 단계에서 가장 많이 사용하는 설정은 모든 문을 열어두는 마스터키 방식이다. 실제로 테스트 환경에서는 편의를 위해 `arn:aws:s3:::*` 같은 와일드카드(전체 선택 기호)를 사용해 모든 S3 버킷에 접근하도록 설정하곤 한다. 하지만 이를 그대로 운영 환경에 가져가는 것은 보안 사고의 지름길이다. 쉽게 말하면 모든 방의 열쇠를 하나로 합친 마스터키를 외부인에게 맡기는 것과 같다. 운영 단계에서는 반드시 특정 ARN(Amazon Resource Name, 리소스 고유 식별자)만 지정해 꼭 필요한 데이터에만 접근하게 하는 최소 권한 원칙을 철저히 지켜야 한다. 더불어 Cognito(코그니토, AWS 인증 서비스)의 커스텀 스코프를 활용해 읽기 권한과 쓰기 권한을 엄격히 분리하는 작업이 병행되어야 한다. 비유하자면 도서관에서 책을 읽을 수 있는 권한과 책의 내용을 수정할 수 있는 권한을 다르게 부여해 데이터 오염을 막는 것과 같다. 권한을 세분화하지 않으면 단순 조회용 봇이 실수로 중요한 설정 파일을 삭제하는 치명적인 결과로 이어질 수 있다.

초기 설정 화면에서 네트워크 모드를 Public(공개)으로 두는 것은 빠른 연결을 위한 임시 조치일 뿐이다. 이 설정은 인터넷 어디서나 접근이 가능해 편리하지만 기업의 핵심 자산이 외부에 노출될 위험이 매우 크다. 운영 단계로 넘어갈 때는 반드시 VPC(Virtual Private Cloud, 가상 사설 클라우드) 옵션으로 전환해야 한다. 쉽게 말하면 누구나 들어올 수 있는 광장형 매장에서 전용 보안 요원이 지키는 프라이빗 룸으로 사무실을 옮기는 과정이다. 특히 보안 규정이 까다로운 한국의 기업 환경에서는 네트워크 격리가 선택이 아닌 필수다. 외부망과 완전히 분리된 가상 네트워크 안에서 AI 에이전트가 작동하게 함으로써 데이터 유출 경로를 원천적으로 차단하는 전략이 요구된다. 이는 단순히 기술적인 설정을 넘어 기업의 데이터 주권을 지키는 가장 기본적인 방어선이 된다.

보안 사고가 터진 뒤에 누가 무엇을 했는지 찾아내는 작업은 생각보다 고통스럽고 시간이 많이 걸린다. 이를 방지하기 위해 CloudWatch(클라우드워치, AWS 모니터링 서비스)의 감사 추적 기능을 활용한 로그 체계를 촘촘하게 구축해야 한다. 한국형 거버넌스 관점에서 보면 이는 단순한 기록을 넘어 법적 증빙이나 내부 감사 시 제출해야 하는 필수 리포트가 된다. AI 에이전트가 어떤 API를 호출했고 어떤 데이터를 조회했는지 모든 발자취를 남기는 시스템이다. 비유하자면 건물 내 모든 출입문에 고해상도 CCTV를 설치하고 출입 기록을 초 단위로 저장하는 것과 같다. 이러한 감사 로그가 완벽히 갖춰져야만 AI에게 인프라 제어권을 부여했을 때 발생하는 심리적 불안감을 해소하고 실질적인 운영 신뢰도를 확보할 수 있다. 이처럼 로그는 문제가 생겼을 때의 추적 도구이자 평소에는 시스템의 정상 작동을 증명하는 유일한 근거가 된다.