Building an agentic app deployer with Amazon Bedrock and AWS Lambda

🖼️ 인포그래픽

Building an agentic app deployer with Amazon Bedrock and AWS Lambda 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

PDI 브루는 자연어로 표현된 내부 도구 요구를 공통 매니페스트로 변환하고, 결정론적 프로비저닝 에이전트가 이를 안전한 서버리스 웹 애플리케이션으로 배포하는 플랫폼이다.

📌 핵심 요약

PDI 테크놀로지스는 개발 인력, 배포 파이프라인, 인증 및 유지관리 비용 때문에 우선순위에서 밀리던 소규모 내부 도구의 적체를 해결하고자 PDI 브루를 구축했다.
비기술 직원은 원하는 도구를 자연어로 설명하며, 플랫폼은 별도의 Git·터미널·데브옵스 지식 없이 통합 인증이 적용된 다중 테넌트 웹 애플리케이션을 생성하고 배포한다.
계획 에이전트는 사용자와 요구사항을 구체화하고 프런트엔드와 구조화된 배포 매니페스트를 만들며, AWS Lambda 기반 프로비저닝 에이전트는 이를 검증·분류한 뒤 필요한 자원을 결정론적으로 생성한다.
계획 계층은 기존 AI 보조 도구에서 실행되는 바이브 스킬과 AWS 경계 안의 Amazon Bedrock 호출 중 하나를 선택할 수 있지만, 두 경로 모두 동일한 JSON 매니페스트와 배포 엔드포인트를 사용한다.
기본적인 데이터 앱은 공유 CRUD 실행 환경을 사용하고, 추가 기능과 권한이 필요한 앱만 관리자 승인·정적 분석·권한 드리프트 감지를 거쳐 전용 Lambda와 최소 권한 IAM 역할을 사용한다.

🧩 주요 포인트

공통 배포 매니페스트 → 계획 도구나 실행 위치를 바꾸더라도 프로비저닝 계층과 앱 실행 구조를 그대로 유지할 수 있다.
대화형 계획과 결정론적 인프라 실행의 분리 → 사용자 경험은 유연하게 제공하면서 배포 결정의 재현성·감사 가능성을 확보한다.
공유 CRUD 기본 경로와 승인형 전용 실행 경로 → 다수의 소규모 앱은 저비용으로 운영하고, 특수 권한이 필요한 앱만 최소 권한으로 격리한다.

🧠 상세 정리

1. 내부 도구 개발의 구조적 병목

기업에는 운송비 계산기, 간단한 접수 양식, 스프레드시트 기반 대시보드처럼 작지만 필요한 내부 도구가 계속 발생한다. 그러나 이런 도구도 저장소, 빌드 파이프라인, 인증 연동, 호스팅, TLS 인증서, 도메인 이름 체계, 로깅과 유지관리까지 완전한 소프트웨어 전달 절차를 요구하므로 수익 기능보다 뒤로 밀리기 쉽다. 그 결과 개별적으로는 작지만 전체적으로는 무시하기 어려운 장기 적체가 형성된다. 약 4,000명의 직원과 200개 이상의 국가 및 지역에 걸친 20만 곳 이상의 고객 지점을 지원하는 PDI 테크놀로지스는 전통적인 배포 파이프라인이 비기술 조직의 도구 출시를 가로막고 있다고 판단했다.

2. PDI 브루의 목표와 기본 원칙

PDI 브루에서는 비기술 직원이 필요한 도구를 자연어로 설명하면 몇 초 안에 통합 인증으로 보호되는 다중 테넌트 웹 애플리케이션을 제공받는다. 요청자는 Git, 터미널 또는 데브옵스 지식 없이 자신에게 필요한 앱을 직접 출시할 수 있으며, 별도의 엔지니어링 인계가 필요하지 않다. 플랫폼은 모든 앱에 기업용 통합 인증, 범위가 제한된 IAM 권한, HTTPS와 중앙 관측성을 기본 적용해 보안이 빠진 별도 경로를 두지 않는다. 또한 수백 개의 소규모 앱이 유휴 상태에서 거의 비용을 발생시키지 않도록 서버리스와 규모 0 축소를 지향하고, 생성형 AI 기능도 개별 모델 키가 아니라 통제된 공통 경로를 통해서만 사용하도록 설계했다.

3. 계획과 실행을 분리한 에이전트 구조

이 글에서 에이전트는 목표를 받아 작업을 분해하고, 적절한 도구를 선택해 목표를 향해 행동하는 시스템으로 정의되며, 모든 판단마다 대규모 언어 모델을 호출해야 한다고 보지는 않는다. 계획 에이전트는 사용자와 대화하면서 요구사항을 구체화하고 프런트엔드를 생성한 뒤, 앱 이름·유형·데이터 스키마·접근제어 설정을 담은 구조화된 JSON 배포 매니페스트를 출력한다. 반면 AWS Lambda에서 실행되는 프로비저닝 에이전트는 요청 검증, 작업 유형 분류, 도구 선택과 자원 생성을 담당하는 결정론적 오케스트레이터다. 인프라 변경을 대화 세션이 아니라 Lambda에 맡긴 이유는 모든 결정이 기록되고 재현 가능해야 하며, 동일한 매니페스트가 항상 동일한 계획으로 이어져야 하기 때문이다.

4. 교체 가능한 계획 계층과 공통 계약

계획 계층은 하나의 환경 변수인 PLANNER_MODE로 선택되는 두 경로를 지원하지만, 어느 경로든 동일한 배포 매니페스트를 생성한다. 첫 번째 경로는 직원이 이미 사용 중인 AI 보조 도구 안에서 바이브 앱 빌더 스킬을 실행해 대화, 프런트엔드 생성과 매니페스트 작성을 처리하므로 풍부한 사용자 경험을 제공하고 AWS 측 노출 범위를 작게 유지한다. 두 번째 경로는 Teams, 웹 양식 또는 통합개발환경 같은 채널의 요청을 Amazon Bedrock으로 보내 작업을 분류하고, 같은 매니페스트를 생성하며, 필요하면 데이터 스키마를 검증하거나 보정한다. 두 경로가 하나의 계약으로 수렴하므로 프로비저닝 에이전트와 앱 실행 환경은 변경되지 않으며, 조직·작업공간·사용자별로 허용할 계획 경로를 고정할 수 있다.

5. 인증된 배포 요청의 처리 흐름

계획 에이전트가 만든 매니페스트는 HTTPS를 통해 Amazon API Gateway의 POST /deploy 엔드포인트로 전달되며, 요청은 MSAL.js로 취득한 Microsoft Entra ID 전달자 토큰으로 인증된다. API Gateway가 배포 Lambda를 호출하면 프로비저닝 에이전트는 Entra JWT의 테넌트와 만료 시점을 검증하고, 접근제어 방식이 지정됐는지 확인하며, 앱 등록 테이블에서 슬러그 소유권을 원자적으로 검사한다. 검증을 통과한 요청은 계산기나 차트 같은 정적 앱과 데이터 영속성이 필요한 풀스택 앱으로 결정론적으로 분류된다. 이후 에이전트는 AWS SDK와 Microsoft Graph API를 도구로 사용해 유형별 프로비저닝 절차와 접근제어 작업을 수행하며, 같은 입력이 같은 실행 계획을 만들도록 전체 과정을 기록한다.

6. 정적 앱과 풀스택 앱의 프로비저닝

정적 앱의 경우 에이전트는 생성된 HTML을 Entra 인증 셸로 감싸 Amazon S3에 업로드하고, Amazon CloudFront 캐시를 무효화한 뒤 Amazon DynamoDB의 앱 등록부에 정보를 기록한다. 데이터 저장이 필요한 풀스택 앱에는 앱별 DynamoDB 테이블과 API 계층 등 추가 자원이 구성되며, 생성된 API 주소가 프런트엔드에 삽입된 후 동일한 인증·호스팅 절차를 거친다. 최종 사용자는 CloudFront를 통한 HTTPS 주소로 앱에 접근하고, CloudFront Function은 슬러그 기반 도메인 요청을 S3의 올바른 앱으로 전달한다. 모든 앱은 Entra 통합 인증 뒤에 배치되고 Amazon CloudWatch에서 관측되므로, 앱 제작자가 인증·라우팅·로깅 기반을 각각 새로 구현할 필요가 없다.

7. 비동기 작업과 이중 계층 실행 모델

Microsoft 365 그룹 생성 후 디렉터리 정보가 전파되는 과정처럼 오래 걸리는 단계는 사용자의 동기 요청 안에서 기다리지 않고 Lambda의 비동기 자기 호출로 분리한다. 프로비저닝 에이전트는 자신을 이벤트 방식으로 다시 호출하고 사용자에게는 라이브 주소를 먼저 반환하며, 백그라운드 인스턴스가 느린 후속 작업을 완료한다. 대부분의 풀스택 앱은 자체 DynamoDB 테이블에 대한 단순 생성·조회·수정·삭제 작업이므로, 프로비저닝된 동시성과 가중 별칭 및 자동 카나리 롤백 보호를 갖춘 공유 CRUD Lambda를 사용한다. 이메일 발송, 특정 외부 HTTPS 도메인 호출 또는 지정 데이터 원본 접근처럼 폐쇄형 허용 목록의 기능이 필요할 때만 관리자 승인, 제출 코드의 정적 분석과 IAM 역할 드리프트 감지를 거쳐 전용 Lambda와 범위가 제한된 역할로 승격된다.

8. 통제된 앱 내 AI와 플랫폼의 보안 경계

배포된 앱은 대화, 요약, 분류와 같은 AI 기능을 선택적으로 사용할 수 있지만, 앱 작성자가 모델 엔드포인트나 API 키를 직접 다루지는 않는다. 모든 앱은 플랫폼이 제공하는 최소 권한 게이트웨이를 통해 Amazon Bedrock에 접근하며, 이 경로에는 가드레일, 사용량 한도와 전체 감사 기록을 적용한다는 것이 기본 원칙이다. 이는 생성형 AI 사용을 무제한으로 허용하는 대신, 공통 플랫폼의 보안 정책과 관측 범위 안으로 편입하는 방식이다. 결과적으로 PDI 브루의 보안 모델은 인증·권한·감사·비용 통제를 앱 제작자 개인의 구현 능력에 맡기지 않고, 프로비저닝 단계와 공유 실행 기반에서 일관되게 상속하도록 구성된다.

🧾 핵심 주장 / 시사점

에이전트형 프로비저닝의 핵심은 모든 결정을 언어 모델에 맡기는 것이 아니라, 자연어 의도 수집과 감사 가능한 결정론적 실행을 서로 다른 신뢰 경계로 분리하는 데 있다.
계획 계층과 실행 계층 사이에 안정적인 JSON 계약을 두면 사용자 채널이나 계획 모델을 교체해도 배포 API와 앱 실행 환경을 다시 설계할 필요가 줄어든다.
공유 실행 환경을 기본값으로 삼고 특수 기능만 승인형 전용 환경으로 승격하는 구조는 규모 0 비용 효율성과 앱별 최소 권한 격리를 동시에 추구한다.