AWS는 왜 AI 엔지니어를 고객사에 직접 투입하나: 기업 AI 경쟁의 다음 전장

1. AWS의 발표를 “컨설팅 확대”로만 보면 놓치는 것

AWS는 2026년 6월 30일, 고객사 내부에 AI 엔지니어를 직접 투입하는 Forward Deployed Engineering, 즉 FDE 조직을 신설하고 10억 달러를 투자하겠다고 밝혔다. AWS 설명에 따르면 이 조직은 수천 명 규모의 전문가를 고객 팀과 함께 일하게 하며, 에이전틱 AI 솔루션을 공동 개발하고 배포하는 것을 목표로 한다. 이미 Allen Institute, Cox Automotive, NBA, NFL, Ricoh, Southwest Airlines 등이 AWS FDE 팀과 협업하고 있다고 AWS는 밝혔다. 다만 이 10억 달러는 외부 기업에 대한 지분 투자라기보다, AWS가 FDE 조직과 인력·도구·운영 체계에 배정하는 내부 리소스 성격으로 이해하는 것이 정확하다. TechCrunch도 이 금액이 OpenAI·Anthropic의 조인트벤처형 FDE 투자(각각 40억·15억 달러)와 달리 아마존의 내부 자원 배정이라는 점을 짚었다. 출처: AWS invests $1 billion to embed AI forward deployed engineers with customers, Amazon launches new $1 billion FDE org, following OpenAI and Anthropic – TechCrunch

이 발표의 핵심은 “AWS가 고객을 더 잘 도와주겠다”가 아니다. 클라우드 사업자가 기업 AI의 마지막 병목을 어디로 보고 있는지가 중요하다. 지금까지 클라우드 AI 경쟁은 주로 세 가지 축으로 설명됐다. 첫째, 더 강한 파운데이션 모델을 얼마나 많이 제공하는가. 둘째, 추론 비용과 지연 시간을 얼마나 낮출 수 있는가. 셋째, 개발자가 빠르게 애플리케이션을 만들 수 있는 도구를 얼마나 제공하는가. 그러나 실제 기업 현장에서는 이 세 가지가 충분해도 AI 프로젝트가 운영 단계로 넘어가지 못하는 경우가 많다.

이유는 단순하다. 기업 AI는 모델만으로 작동하지 않는다. 모델은 문장을 만들고 판단을 보조할 수 있지만, 실제 업무 성과는 “그 모델이 어떤 데이터에 접근할 수 있는가”, “어떤 시스템을 호출할 수 있는가”, “어떤 권한으로 실행되는가”, “잘못 실행했을 때 누가 멈추고 되돌릴 수 있는가”에서 갈린다. AWS가 FDE를 통해 고객사의 비즈니스, 엔지니어링, 보안 팀과 함께 생산 AI 시스템을 만들겠다고 한 것은 이 문제를 직접 겨냥한 움직임이다. 출처: AWS invests $1 billion to embed AI forward deployed engineers with customers

Reuters는 AWS가 고객사에 5~6명 규모의 엔지니어 팟을 45일 단위로 투입해, 고객의 워크플로우 안에서 에이전틱 AI 패턴을 구현하고 프로덕션 수준의 코드를 작성하는 방식으로 이 조직을 운영한다고 보도했다. 이 대목은 FDE가 단순 자문 조직이 아니라 실제 구현과 조직 조율을 함께 담당하는 실행 조직임을 보여준다. 출처: Amazon’s AWS commits $1 billion toward new unit for embedded AI engineers – Reuters (via Yahoo Finance)

따라서 이번 발표는 클라우드 시장의 경쟁 단위가 바뀌고 있음을 보여준다. 과거에는 “우리 클라우드에 더 많은 모델이 있다”, “우리 API가 더 빠르다”, “우리 GPU 공급이 더 안정적이다”가 차별화의 중심이었다. 이제 기업 고객은 더 실무적인 질문을 던진다. “우리 영업 승인 프로세스에 붙일 수 있는가”, “우리 보안팀이 승인할 수 있는가”, “우리 ERP와 CRM에 연결할 수 있는가”, “장애나 오답이 났을 때 감사할 수 있는가”, “PoC가 끝난 뒤 내부 팀이 운영할 수 있는가.” 이 질문에 답하지 못하면 모델은 좋아도 예산을 계속 받기 어렵다.

2. 왜 기업 AI PoC는 많은데 운영 전환은 어려운가

대부분의 기업은 이미 생성형 AI를 써봤다. 회의록 요약, 문서 초안 작성, 코드 보조, 고객 문의 응답, 검색형 챗봇, 내부 지식 질의응답 같은 PoC는 비교적 빠르게 만든다. 문제는 그다음이다. PoC는 샘플 데이터, 제한된 사용자, 수동 검수, 느슨한 권한으로도 돌아간다. 운영 서비스는 다르다. 실제 고객 데이터, 권한 체계, 장애 대응, 규제 감사, 비용 한도, 성능 SLA, 현업 책임자가 붙는다.

첫 번째 병목은 데이터 접근이다. 기업 데이터는 한곳에 있지 않다. 문서는 SharePoint나 Google Drive에 있고, 고객 정보는 CRM에 있고, 주문·정산은 ERP에 있고, 로그는 데이터 웨어하우스나 관측성 플랫폼에 있고, 사내 정책은 위키와 티켓 시스템에 흩어져 있다. AI가 의미 있는 답을 하려면 이 데이터들을 문맥에 맞게 가져와야 하지만, 아무 데이터나 가져오면 보안 사고가 된다. 부서, 직무, 지역, 고객 등급, 계약 조건에 따라 접근 범위가 달라져야 한다.

두 번째 병목은 권한과 실행이다. 챗봇이 “이 고객에게 환불이 가능합니다”라고 답하는 것과 실제 환불 API를 호출하는 것은 완전히 다른 위험이다. 전자는 정보 제공이고, 후자는 기업의 재무·법무·고객 경험에 영향을 주는 실행이다. AI 에이전트가 업무 시스템을 호출하려면 역할 기반 권한, 최소 권한, 승인 단계, 작업 한도, 롤백 경로가 필요하다. AWS의 보안·거버넌스 지침도 AI 아키텍처에서 최소 권한 IAM 역할, 도구 권한 범위 제한, 프롬프트 검증, 출력 검증, 도구 호출과 프롬프트 이력 감사 로그를 핵심 통제로 다룬다. 출처: Security and governance – AWS Prescriptive Guidance

세 번째 병목은 업무 프로세스 재설계다. 많은 기업이 AI를 기존 업무 화면 옆에 “챗봇 하나”로 붙인다. 이 방식은 도입이 쉽지만 성과가 작다. 현업은 기존 시스템을 계속 쓰고, AI 답변을 복사해 붙여넣고, 오류를 사람이 고친다. 진짜 성과는 업무 단계 자체를 바꿀 때 나온다. 예를 들어 영업 제안서 작성이라면 AI가 과거 제안서, 고객 산업 정보, 가격 정책, 법무 승인 조건을 가져와 초안을 만들고, 담당자가 검수하고, 승인 워크플로로 넘기고, 최종본을 CRM에 남기는 흐름까지 연결돼야 한다. 이는 단순 프롬프트 엔지니어링이 아니라 업무 설계와 시스템 통합의 문제다.

네 번째 병목은 운영 책임이다. 모델 업데이트로 답변 품질이 바뀌면 누가 감지하는가. 특정 부서에서만 환각이 늘어나면 누가 조사하는가. 민감 데이터가 프롬프트에 섞이면 누가 차단하는가. 토큰 비용이 예상보다 빠르게 증가하면 어떤 업무를 제한하는가. AI 시스템은 배포 이후에도 계속 관찰하고 조정해야 한다. PoC에서 “잘 되는 데모”였던 것이 운영에서 “관리해야 할 생산 시스템”으로 바뀌는 순간, 조직은 소프트웨어 운영과 AI 리스크 관리를 동시에 해야 한다.

3. FDE는 외주 개발자가 아니라 ‘현장 구현 조직’에 가깝다

Forward-Deployed AI Engineer를 단순한 외주 개발자나 클라우드 기술지원 담당자로 보면 역할을 과소평가하게 된다. FDE는 고객 현장에 들어가 업무를 관찰하고, 시스템 제약을 이해하고, 보안팀과 논의하고, 현업의 판단 기준을 모델과 워크플로에 반영하는 실행자에 가깝다. 팔란티어식 FDE 모델이 자주 비교 대상으로 거론되는 이유도, 요구사항 문서를 받아 사무실에서 개발하는 방식이 아니라 고객 조직 안에서 문제를 정의하고 즉시 검증하는 방식이기 때문이다. 출처: [이슈리포트] LLM기업의 컨설팅화, FDE 시대 – 아이티데일리

AWS FDE의 차별점은 이 역할을 클라우드 플랫폼과 에이전틱 AI 실행 환경에 묶으려 한다는 점이다. AWS는 FDE 조직이 고객사의 데이터, 거버넌스, 프로세스와 함께 생산 AI 시스템을 만든다고 설명한다. 또 전통적 컨설팅처럼 진단과 권고에 머무는 것이 아니라, 장기적으로 고객이 자립할 수 있도록 솔루션과 엔지니어링 역량을 함께 남기는 것을 목표로 한다고 강조한다. 출처: AWS invests $1 billion to embed AI forward deployed engineers with customers

실무적으로 FDE는 네 가지 역할을 겹쳐 수행한다. 첫째, 제품 엔지니어다. 사용자가 실제로 쓸 수 있는 화면, API, 워크플로, 자동화 경로를 만든다. 둘째, 솔루션 아키텍트다. 어떤 데이터 소스를 연결하고, 어떤 모델을 쓰고, 어떤 계층에서 검증할지 설계한다. 셋째, 업무 분석가다. 현업이 실제로 어떤 판단을 하고 어떤 예외를 처리하는지 파악한다. 넷째, 보안·운영 조율자다. 권한, 로그, 승인, 배포, 모니터링 체계를 보안·플랫폼 조직과 맞춘다.

이 역할이 중요한 이유는 기업 AI가 “정답을 아는 모델”보다 “실행 가능한 시스템”을 요구하기 때문이다. 고객지원 에이전트를 예로 들자. 좋은 모델은 고객 문의를 이해하고 친절한 답변을 만들 수 있다. 하지만 기업용 고객지원 에이전트는 여기에 그치면 안 된다. 고객 등급을 확인하고, 계약상 지원 범위를 조회하고, 과거 티켓을 찾아보고, 환불·교환 권한을 확인하고, 답변 초안을 만들고, 고위험 케이스는 사람에게 넘기고, 모든 판단 근거를 남겨야 한다. 이 전체 흐름을 설계하는 사람이 FDE다.

4. 기업 AI 구현 아키텍처: 모델보다 중요한 연결 계층

기업 AI를 운영 시스템으로 만들려면 대략 여섯 개 계층이 필요하다. 첫째, 사용자 접점이다. 사내 포털, 고객센터 콘솔, 개발자 도구, 슬랙·팀즈 같은 협업 도구, 모바일 앱이 여기에 해당한다. 둘째, 오케스트레이션 계층이다. 사용자의 의도를 해석하고, 필요한 도구를 고르고, 지식 검색과 API 호출 순서를 정한다. AWS의 에이전틱 AI 오케스트레이션 패턴은 Bedrock Agents가 자연어 프롬프트를 해석하고, 도구나 API를 호출하며, 기업 지식에 기반해 구조화된 결과를 만들 수 있다고 설명한다. 출처: Pattern 2: Agentic AI orchestration with Amazon Bedrock

AWS의 발표는 이 계층에 대한 구체적인 접근도 제시한다. AWS FDE 팀은 고객의 AWS 계정 안에 시맨틱 레이어(semantic layer)를 배포해 기업의 데이터 소스에 연결하고 메타데이터를 보강하며, 거버넌스가 적용되고 버전 관리되는 지식 그래프(governed, versioned knowledge graph)를 통해 에이전트가 기업 지식 위에서 추론하도록 만든다고 설명한다. 출처: AWS invests $1 billion to embed AI forward deployed engineers with customers
이 접근이 모든 지식 검색 문제를 해결하는 것은 아니지만, FDE의 산출물이 단순히 애플리케이션 하나를 완성하는 데 그치지 않고, 프로젝트가 끝난 뒤에도 내부 팀이 재사용할 수 있는 지식 구조와 운영 패턴을 남긴다는 점에서 기업 AI 구현의 중요한 참고 패턴으로 볼 수 있다.

셋째, 지식 검색 계층이다. 문서, 정책, 제품 설명, 과거 케이스, 코드 저장소, 데이터베이스에서 관련 정보를 찾아 모델 입력에 붙인다. 이때 단순 키워드 검색만으로는 부족하다. 문서 권한을 유지해야 하고, 최신 문서를 우선해야 하며, 출처를 남겨야 하고, 답변에 사용된 근거를 사용자가 검토할 수 있어야 한다. 넷째, 도구 호출 계층이다. ERP, CRM, ITSM, 결제, 재고, 이메일, 코드 저장소, 배포 파이프라인 같은 시스템과 연결된다. 이 계층에서는 “조회”와 “변경”을 엄격히 나눠야 한다.

다섯째, 거버넌스 계층이다. 어떤 사용자가 어떤 프롬프트를 보냈고, 에이전트가 어떤 지식을 검색했고, 어떤 API를 호출했고, 어떤 결과를 냈는지 기록한다. 프롬프트 인젝션 방어, 민감 정보 마스킹, 출력 검증, 정책 위반 차단도 이 계층에 포함된다. AWS 보안 지침은 서버리스 AI 아키텍처가 동적 실행 경로, 데이터가 많은 프롬프트, 파운데이션 모델을 통한 외부화된 로직, 자율적 도구 호출 때문에 새로운 공격 표면과 책임 문제를 만든다고 설명한다. 출처: Security and governance – AWS Prescriptive Guidance

여섯째, 운영 계층이다. 품질 평가, 비용 모니터링, 지연 시간, 실패율, 사용자 피드백, 모델 변경 영향, 업무 KPI를 추적한다. AI 시스템은 일반 소프트웨어처럼 버전 관리와 배포 관리가 필요하지만, 여기에 데이터 드리프트, 프롬프트 변경, 모델 응답 변동성까지 더해진다. 운영 계층이 없으면 AI는 처음에는 신기한 도구로 받아들여지지만, 곧 “가끔 맞고 가끔 틀리는 블랙박스”로 밀려난다.

이 구조를 간단히 그리면 다음과 같다.

사용자/업무 화면
    ↓
의도 해석·에이전트 오케스트레이션
    ↓
권한 확인 ─ 지식 검색 ─ 도구/API 호출
    ↓
출력 검증·승인·휴먼 인 더 루프
    ↓
업무 시스템 반영·로그·감사·모니터링

핵심은 각 계층이 따로 존재하는 것이 아니라 하나의 책임 사슬로 묶여야 한다는 점이다. “모델이 답했다”가 아니라 “누가 어떤 권한으로 어떤 근거와 어떤 도구를 사용해 어떤 업무 결과를 만들었는가”를 설명할 수 있어야 한다. 이것이 기업 AI 구현의 최소 조건이다.

5. AI 에이전트는 자동화가 아니라 ‘권한 있는 실행’의 문제다

AI 에이전트라는 표현은 과장되기 쉽다. 하지만 기업 환경에서 에이전트의 본질은 자율성이 아니라 권한 있는 실행이다. 사용자의 요청을 이해하고, 필요한 정보를 찾고, 여러 단계를 계획하고, 도구를 호출해 결과를 만드는 능력이다. Amazon Bedrock Agents는 회사 시스템, API, 데이터 소스와 연결해 다단계 작업을 자동화하는 생성형 AI 애플리케이션을 가능하게 한다고 설명한다. 또 다중 에이전트 협업, 검색 증강 생성, 오케스트레이션과 실행, 메모리, 코드 해석 등을 주요 기능으로 제시한다. 출처: Amazon Bedrock Agents

그러나 “에이전트가 할 수 있다”와 “기업이 허용해야 한다”는 다르다. 예를 들어 구매 부서의 AI 에이전트가 공급업체 견적을 비교하고 추천하는 것은 비교적 낮은 위험일 수 있다. 하지만 실제 발주서를 생성하고 계약 조건을 바꾸고 지급 일정을 확정하는 것은 높은 위험이다. 따라서 기업은 에이전트 업무를 위험 등급으로 나눠야 한다.

낮은 위험 업무는 요약, 검색, 초안 작성, 분류, 추천이다. 중간 위험 업무는 내부 시스템 조회, 티켓 생성, 승인 요청 초안 작성, 정책 위반 가능성 탐지다. 높은 위험 업무는 고객 통지, 금전 거래, 계약 변경, 개인정보 수정, 인사 평가, 보안 설정 변경, 배포 실행이다. 낮은 위험 업무는 자동 응답까지 허용할 수 있지만, 높은 위험 업무는 사람 승인, 이중 확인, 롤백 절차, 사후 감사가 필요하다.

이 구분은 기술보다 경영 의사결정에 가깝다. CTO와 보안 책임자는 “어떤 에이전트를 만들 것인가”보다 “어떤 권한을 AI에게 줄 것인가”를 먼저 정해야 한다. 현업 리더는 “어디까지 자동화하면 생산성이 오르고, 어디부터는 책임 위험이 커지는가”를 정해야 한다. FDE가 고객사에 들어가야 하는 이유도 여기에 있다. 권한 경계는 문서만 읽고 설계할 수 없다. 실제 업무 예외, 승인 관행, 조직 정치, 규제 해석을 알아야 한다.

6. 보안 거버넌스: AI 도입의 브레이크가 아니라 가속 장치

기업 AI 프로젝트에서 보안팀은 종종 “막는 부서”로 오해받는다. 하지만 운영 단계의 AI에서 보안 거버넌스는 속도를 늦추는 장치가 아니라 반복 배포를 가능하게 하는 기반이다. 보안 기준이 명확하면 현업과 개발팀은 어디까지 자동화할 수 있는지 빨리 판단할 수 있다. 기준이 없으면 모든 프로젝트가 개별 심사로 밀리고, PoC는 늘어나지만 운영 승인은 지연된다.

첫 번째 원칙은 최소 권한이다. 에이전트는 사람 계정을 빌려 쓰면 안 된다. 업무별 서비스 역할을 만들고, 조회·생성·수정·삭제 권한을 분리해야 한다. AWS 지침도 Lambda 함수, 에이전트, 모델에 최소 권한 IAM 역할을 정의하고, Bedrock agent가 필요한 도구에만 접근하도록 제한하는 통제를 제시한다. 출처: Security and governance – AWS Prescriptive Guidance

두 번째 원칙은 데이터 분류다. 모든 문서와 데이터가 같은 위험을 갖지 않는다. 공개 가능한 제품 설명, 내부 전용 정책, 고객 개인정보, 의료·금융 정보, 영업비밀은 접근·저장·로그 정책이 달라야 한다. AI 입력과 출력에 민감 정보가 포함될 수 있으므로, 프롬프트와 응답도 데이터 자산으로 관리해야 한다. 특히 에이전트가 검색한 문서 일부를 응답에 포함할 때 원래 문서의 접근 권한을 무시하면 내부 정보 유출이 발생할 수 있다.

세 번째 원칙은 네트워크와 데이터 보호다. Amazon Bedrock FAQ는 Bedrock에서 고객 콘텐츠가 기본 모델 개선에 사용되지 않고 모델 제공업체와 공유되지 않으며, 데이터가 전송 중과 저장 중 암호화되고, PrivateLink를 통해 VPC와 Bedrock 사이의 비공개 연결을 구성할 수 있다고 설명한다. 이는 엔터프라이즈 AI 도입에서 중요한 출발점이지만, 그것만으로 충분하지는 않다. 기업 내부 애플리케이션, 로그 저장소, 벡터 데이터베이스, API 게이트웨이, SaaS 연동도 같은 수준의 통제가 필요하다. 출처: Amazon Bedrock FAQs

네 번째 원칙은 감사 가능성이다. 에이전트가 “왜 그런 결론을 냈는가”를 완벽히 설명하기는 어렵더라도, 최소한 어떤 입력을 받았고 어떤 도구를 호출했고 어떤 근거 문서를 사용했는지는 남겨야 한다. AWS 문서도 도구 호출과 프롬프트 이력에 대한 감사 로그가 사고 대응과 포렌식 조사에 중요하다고 설명한다. 출처: Security and governance – AWS Prescriptive Guidance

다섯 번째 원칙은 휴먼 인 더 루프다. 모든 업무에 사람 검수가 필요한 것은 아니다. 하지만 고위험 작업에는 사람이 승인해야 한다. 이때 사람 검수는 단순히 “확인 버튼”을 누르는 형식이어서는 안 된다. AI가 사용한 근거, 변경될 필드, 예상 영향, 되돌리기 방법이 함께 제공돼야 한다. 그래야 검수자가 책임 있는 판단을 할 수 있다.

7. AWS의 전략적 의도: 인프라 공급자에서 AI 전환 실행 파트너로

AWS의 FDE 투자는 클라우드 사업자의 정체성 전환으로 읽을 수 있다. AWS는 오랫동안 인프라, 관리형 서비스, 개발자 도구, 파트너 생태계를 통해 기업 디지털 전환의 기반을 제공해 왔다. 생성형 AI 시대에는 이 기반 위에 모델, 에이전트, 보안, 데이터 서비스를 얹었다. 하지만 기업 고객이 실제 성과를 요구하기 시작하면서 “플랫폼을 제공했으니 고객이 알아서 만들라”는 방식만으로는 부족해졌다.

AWS 입장에서 FDE는 세 가지 전략적 효과를 가진다. 첫째, 사용량을 만든다. 기업이 AI를 실험만 하면 클라우드 소비는 제한적이다. 업무 시스템에 AI가 들어가고, 에이전트가 반복 실행되고, 데이터 파이프라인과 관측성 체계가 붙어야 지속적인 사용량이 생긴다. 둘째, 고객 락인을 강화한다. 단순 모델 호출은 비교적 이동이 쉽지만, 데이터 권한, 워크플로, 에이전트, 로그, 운영 체계가 특정 클라우드 환경에 깊게 묶이면 전환 비용이 커진다. 셋째, 제품 피드백 루프를 확보한다. FDE가 고객 현장에서 겪는 문제는 Bedrock, SageMaker, Amazon Q, 보안 서비스, 데이터 서비스 개선으로 이어질 수 있다.

이 점에서 FDE는 영업 조직도, 컨설팅 조직도, 순수 제품 조직도 아니다. 고객의 실제 문제를 해결하면서 플랫폼의 사용 패턴을 만들어내는 경계 조직이다. OpenAI가 파트너 네트워크와 전문 자격을 통해 기업 배포 역량을 확장하려는 움직임, 여러 AI 기업이 FDE형 조직을 강화하는 흐름도 같은 맥락에서 볼 수 있다. 출처: Introducing OpenAI Partner Network, 오픈AI 배포 책임자가 밝힌 코덱스 성장세와 AI 가격 하락 및 ROI 과제

다만 AWS가 이 방향을 택했다고 해서 FDE가 모든 기업 AI 도입의 정답이라는 뜻은 아니다. 대규모 고객에게는 현장 투입형 엔지니어링이 효과적일 수 있지만, 모든 조직이 같은 방식으로 지원받을 수는 없다. 또 외부 엔지니어가 빠르게 만들어준 시스템이 내부 운영 역량으로 흡수되지 않으면, 나중에는 또 다른 의존성이 된다. AWS도 FDE 배포가 끝날 때 고객이 자립할 수 있도록 한다고 강조하지만, 실제 자립 여부는 고객사의 조직 설계와 학습 의지에 달려 있다. 출처: AWS invests $1 billion to embed AI forward deployed engineers with customers

8. 기업이 AI 벤더를 평가할 때 봐야 할 10가지

AWS의 움직임이 기업에게 주는 실무적 메시지는 분명하다. 이제 AI 벤더 평가는 모델 벤치마크 비교표로 끝나면 안 된다. 다음 항목을 함께 봐야 한다.

이 표에서 중요한 것은 각 항목이 서로 연결돼 있다는 점이다. 데이터 보호가 약하면 고위험 업무로 확장할 수 없다. 감사 로그가 약하면 보안팀 승인을 받기 어렵다. 시스템 연동이 약하면 업무 성과가 작다. 지식 이전이 약하면 PoC는 성공해도 내부 확산이 느리다. ROI 측정이 약하면 다음 예산을 받기 어렵다.

9. 실사용 시나리오: 어디에 FDE형 접근이 필요한가

시나리오 1: 고객지원 에이전트

상황: 고객센터가 반복 문의와 복잡한 정책 확인으로 병목을 겪는다. 입력: 고객 문의, 등급, 계약 조건, 과거 티켓, 정책 문서. 실행 흐름: 에이전트가 의도를 분류하고 정책·고객 상태를 조회해 답변 초안을 만들며, 환불 등 금전 영향 작업은 상담원 승인을 거친다. 출력: 근거가 붙은 답변 초안, 처리 코드, 후속 티켓. 주의점: 개인정보 접근권, 승인 권한, 오안내 책임 소재를 명확히 해야 한다. Bedrock Agents의 다단계 작업 자동화 지향과 맞닿아 있다. 출처: Amazon Bedrock Agents

시나리오 2: 영업 제안서 자동화

상황: 엔터프라이즈 영업팀이 고객별 제안서 작성에 많은 시간을 쓴다. 입력: 고객 산업, 과거 제안서, 가격 정책, 법무·보안 문서, 경쟁사 정보. 실행 흐름: 에이전트가 고객 상황을 요약하고 사례를 검색해 초안을 작성하며, 가격 예외는 승인 워크플로로 넘긴다. 출력: 제안서 초안, 리스크 체크리스트, 승인 필요 항목, CRM 업데이트. 주의점: 가격·계약 조건은 민감 정보라 AI가 임의로 할인이나 법무 문구를 바꾸지 못하도록 출력 검증과 승인 단계가 필요하다.

시나리오 3: 개발·운영 현대화

상황: 오래된 애플리케이션을 컨테이너·관리형 서비스로 현대화해야 하지만 내부 팀 여력이 부족하다. 입력: 코드 저장소, 배포 스크립트, 인프라 구성, 장애 로그, 보안 정책. 실행 흐름: AI가 코드 구조를 분석해 마이그레이션 작업을 쪼개고 테스트·배포 변경안을 만들면 엔지니어가 검수한다. 출력: 변경 PR, 테스트 결과, 배포 계획, 롤백 절차. 주의점: 자동 생성된 코드·인프라 변경은 반드시 리뷰·테스트를 거쳐야 한다. 에잇퍼센트의 Kiro CLI 기반 현대화 사례가 이런 접근을 보여준다. 출처: 에잇퍼센트의 Kiro CLI 기반 Amazon ECS 현대화 여정

시나리오 4: 보안 운영 보조

상황: 보안팀이 경보 과다, 위협 모델링, 정책 검토, 사고 대응 문서화로 부담을 느낀다. 입력: 보안 경보, CloudTrail·Config 로그, 자산 목록, 취약점 리포트, 내부 정책. 실행 흐름: 에이전트가 경보를 분류하고 자산·변경 이력을 조회해 위험도와 대응 절차 초안을 만들며, 차단·권한 변경은 담당자 승인을 거친다. 출력: 사고 요약, 근거 로그, 권장 조치, 티켓 업데이트. 주의점: 보안 에이전트는 강한 권한을 갖기 쉬워 권한 분리와 감사 로그가 필수다. 최소 권한·도구 권한 제한·감사 로그 원칙이 특히 중요하다. 출처: AWS Prescriptive Guidance: Security and governance, AWS Security Agent 기능 업데이트

10. 외부 AI 구현 조직을 쓸 때 기업이 지켜야 할 선

FDE형 조직은 초기 속도를 높일 수 있다. 하지만 기업 입장에서 가장 위험한 시나리오는 “외부 팀이 다 만들어줬는데 내부에는 아무도 이해하지 못하는 시스템”이다. AI는 한 번 만들고 끝나는 프로젝트가 아니다. 데이터가 바뀌고, 업무 정책이 바뀌고, 모델이 바뀌고, 규제가 바뀐다. 내부 팀이 운영 원리를 이해하지 못하면 작은 변경도 외부 지원에 의존하게 된다.

따라서 외부 AI 구현 조직을 활용할 때는 세 가지 선을 정해야 한다. 첫째, 데이터와 권한 설계의 최종 책임은 내부에 둔다. 외부 팀이 권한 구조를 제안할 수는 있지만, 어떤 데이터에 누가 접근할 수 있는지 결정하는 것은 기업 자신의 책임이다. 둘째, 핵심 업무 규칙은 내부 현업이 검수한다. AI가 업무를 자동화하려면 현업의 암묵지를 명시적 규칙으로 바꿔야 한다. 이 과정에 현업이 빠지면 그럴듯하지만 쓸 수 없는 시스템이 나온다. 셋째, 운영 인수 기준을 계약과 프로젝트 목표에 넣는다. 코드, 아키텍처 문서, 프롬프트·정책 버전, 테스트 세트, 모니터링 대시보드, 장애 대응 절차, 비용 한도, 교육 자료가 남아야 한다.

좋은 FDE 프로젝트의 산출물은 애플리케이션 하나가 아니다. 반복 가능한 패턴이어야 한다. 예를 들어 고객지원 에이전트를 만들었다면, 그 경험이 영업, 재무, 인사, 개발 운영으로 확장될 수 있어야 한다. 공통 권한 모델, 공통 로그 포맷, 공통 승인 컴포넌트, 공통 품질 평가 방식이 남아야 한다. 그래야 첫 프로젝트가 비용이 아니라 플랫폼 투자가 된다.

11. ROI는 “AI가 똑똑한가”가 아니라 “업무가 달라졌는가”로 측정해야 한다

기업 AI의 ROI 측정은 어렵다. 단순히 “사용자가 몇 명인가”, “프롬프트를 몇 번 보냈는가”로는 부족하다. 사용량은 호기심도 반영한다. 중요한 것은 업무 결과다. 고객지원에서는 평균 처리 시간, 1차 해결률, 상담원 후처리 시간, 오답 정정률을 봐야 한다. 개발 조직에서는 PR 처리 시간, 테스트 실패율, 배포 빈도, 장애 복구 시간을 봐야 한다. 영업에서는 제안서 작성 시간, 승인 지연, 전환율, 할인 예외율을 봐야 한다.

또 비용을 함께 봐야 한다. AI 비용은 모델 호출 비용만이 아니다. 데이터 인덱싱, 벡터 검색, 로그 저장, 보안 검토, 현업 검수, 운영 모니터링, 재학습과 평가 비용이 포함된다. 고성능 모델을 모든 요청에 쓰는 것은 비효율적일 수 있다. 조회·분류·초안 작성에는 상대적으로 가벼운 모델을 쓰고, 복잡한 판단이나 고위험 요약에는 더 강한 모델을 쓰는 식의 라우팅이 필요하다. 이때도 모델 선택권, 비용 관측성, 품질 평가 체계가 있어야 한다.

AWS Bedrock FAQ는 CloudWatch 지표를 통해 입력·출력 토큰을 추적할 수 있다고 설명한다. 이는 비용 통제의 한 요소지만, 기업은 여기에 업무 KPI를 붙여야 한다. “토큰을 얼마나 썼는가”보다 “토큰 사용이 어떤 업무 성과로 이어졌는가”가 중요하다. 출처: Amazon Bedrock FAQs

12. 다음 전장은 모델 경쟁 이후의 운영 경쟁이다

모델 성능 경쟁은 계속된다. 더 긴 문맥, 더 낮은 지연 시간, 더 나은 추론 능력, 더 낮은 비용은 여전히 중요하다. 하지만 기업 시장에서는 모델이 일정 수준 이상 좋아질수록 차별화의 중심이 바뀐다. 어떤 모델을 쓰느냐보다 어떤 업무에, 어떤 데이터로, 어떤 권한 아래, 어떤 검수 체계로, 어떤 운영 지표를 보며 쓰느냐가 더 중요해진다.

이 변화는 시장 경계를 흐리게 만든다. 클라우드 기업은 컨설팅과 SI 영역으로 들어오고, 컨설팅 기업은 AI 에이전트와 플랫폼 역량을 강화하고, SaaS 기업은 자기 제품 안에 에이전트를 넣고, 모델 기업은 파트너 네트워크와 현장 배포 조직을 키운다. 기업 고객 입장에서는 선택지가 많아졌지만, 동시에 판단이 어려워졌다. 이제 “어느 모델이 제일 좋은가”라는 질문만으로는 부족하다. “누가 우리 조직의 업무와 데이터와 보안 현실을 이해하고, 운영 가능한 AI 시스템으로 바꿀 수 있는가”를 물어야 한다.

AWS의 FDE 투자는 이 방향을 선명하게 보여준다. 이것은 AWS가 기업 AI 시장을 장악한다는 보장이 아니다. 또한 모든 기업이 AWS식 FDE를 써야 한다는 뜻도 아니다. 다만 한 가지는 분명하다. 기업 AI의 병목은 점점 실험실이 아니라 현장에 있다. 모델 호출은 쉬워졌지만, 업무에 심는 일은 여전히 어렵다. 그리고 그 어려움이 다음 경쟁의 핵심이다.

기업이 지금 해야 할 일은 AI 도입을 “도구 구매”가 아니라 “운영 체계 구축”으로 재정의하는 것이다. 첫 프로젝트부터 권한, 데이터, 로그, 검수, 비용, KPI, 지식 이전을 설계해야 한다. 외부 전문가를 활용하더라도 내부 책임 구조를 세워야 한다. 그래야 AI가 데모를 넘어 조직의 실행 능력이 된다.

마지막으로 기억할 문장은 하나다. 기업 AI 도입의 성패는 어떤 모델을 선택하느냐보다, 그 모델을 조직의 데이터·권한·업무 흐름 안에 얼마나 안전하고 지속 가능하게 구현하느냐에 달려 있다.

참고 출처

• AWS invests $1 billion to embed AI forward deployed engineers with customers
• Amazon’s AWS commits $1 billion toward new unit for embedded AI engineers – Reuters (via Yahoo Finance)
• Amazon launches new $1 billion FDE org, following OpenAI and Anthropic – TechCrunch
• Amazon Bedrock Agents
• Amazon Bedrock FAQs
• Security and Compliance – Amazon Bedrock
• AWS Prescriptive Guidance: Security and governance
• Pattern 2: Agentic AI orchestration with Amazon Bedrock
• Agentic AI patterns and workflows on AWS
• [이슈리포트] LLM기업의 컨설팅화, FDE 시대 – 아이티데일리
• 에잇퍼센트의 Kiro CLI 기반 Amazon ECS 현대화 여정
• AWS Security Agent 기능 업데이트
• Introducing OpenAI Partner Network
• 오픈AI 배포 책임자가 밝힌 코덱스 성장세와 AI 가격 하락 및 ROI 과제