AWS가 1조 원을 들여 엔지니어를 고객사에 직접 보내기 시작했다 (Forward Deployed Engineering)

1. 이 글을 쓰는 이유

 

2026년 6월 30일, AWS가 흥미로운 발표 두 개를 같은 날 냈다.

하나는 10억 달러(약 1.4조 원)를 투자해 수천 명의 엔지니어를 고객사에 직접 파견하는 전담 조직 "Forward Deployed Engineering(FDE)"을 만든다는 발표.

다른 하나는 이 FDE 모델을 AWS 직원뿐만 아니라 파트너 컨설팅사 내부에도 이식하겠다는 파트너 프로그램 발표다.

 

• AWS 공식 발표: https://www.aboutamazon.com/news/aws/aws-1-billion-forward-deployed-ai-engineers
• 파트너 확장 발표: https://aws.amazon.com/ko/blogs/apn/introducing-forward-deployed-engineering-for-partners-winning-the-future-of-enterprise-ai/

처음 읽었을 때는 그냥 "AWS가 컨설팅 사업 확장하나 보다" 정도로 생각했다.

그런데 뜯어볼수록 이건 클라우드 벤더의 비즈니스 모델 자체가 바뀌고 있다는 신호였고, 우리 같은 백엔드 개발자의 커리어에도 직접적인 영향이 있는 이야기였다.

읽으면서 이해 안 됐던 용어들(거버넌스, 온톨로지, 딜리버리 하네스)을 정리해가며 소화한 내용을 공유한다.

 

 

2. Forward Deployed Engineer가 뭔데?

 

FDE는 원래 Palantir가 만든 직군 이름이다.

엔지니어가 본사에서 제품만 만드는 게 아니라, 고객사 현장에 상주하면서 고객의 데이터와 업무에 맞게 시스템을 직접 구축해주는 모델이다.

최근에는 OpenAI, Anthropic 같은 AI 회사들도 FDE 조직을 만들면서 업계 트렌드가 됐고, 이번에 AWS가 1조 원 규모로 뛰어든 것이다.

기존 하이퍼스케일러의 방식은 이랬다.

인프라와 서비스를 판다 → 고객이 알아서 만든다 → 안 되면 SI/컨설팅사를 부른다

AWS FDE는 이 구조를 뒤집는다.

 

AWS 엔지니어가 고객 팀 안에 들어간다 → 고객의 실제 데이터와 규정 위에서 프로덕션 시스템을 같이 만든다 → 몇 주 안에 배포한다

발표문에서 AWS가 기존 컨설팅과 다르다고 강조하는 지점이 세 가지다.

1. 에이전틱 퍼스트: 챗봇이 아니라 도구를 호출하고 스스로 계획/실행하는 에이전트 시스템이 기본
2. 배포 기간을 수개월에서 수일로 단축
3. 끝나면 고객이 자립(self-sufficient)하도록 설계. 계속 의존하게 만드는 구조가 아님

이미 NBA, NFL, Southwest Airlines, Cox Automotive 등이 AWS FDE 팀과 일하고 있고, NFL의 경우 몇 주 만에 프로덕션에 진입해 NFL Fantasy AI 같은 팬 대상 제품을 만들었다고 한다.

 

 

3. "거버넌스"라는 단어가 계속 나오는 이유

 

발표문을 읽다 보면 governance라는 단어가 반복해서 나온다.

"고객의 실제 거버넌스 안에서 프로덕션 시스템을 구축한다"

처음엔 이 단어가 잘 안 와닿았다. 지배구조? 뭘 지배한다는 거지?

엔터프라이즈 IT에서 거버넌스는 이런 의미다.

데이터와 시스템을 누가, 어떤 규칙 하에, 어떻게 쓸 수 있는지에 대한 통제 체계 전체

구체적으로 풀면 이런 것들이다.

• 접근 통제: 이 데이터는 어느 부서, 어느 직급까지 볼 수 있는가 (권한, RBAC)
• 컴플라이언스: 개인정보보호법, 금융 규제 같은 법적 요구사항을 지키는 절차
• 데이터 관리 규칙: 보관 기간, 암호화 기준, 감사 로그, "고객 데이터는 절대 우리 VPC 밖으로 못 나간다" 같은 규칙
• 승인 프로세스: 프로덕션 배포 전 보안팀 검토 필수 같은 내부 절차

회사에서 일해본 사람이라면 다 겪어봤을 것이다. 사내망에서 NuGet이 401을 뱉고, SSH 하나 열려면 보안 그룹 신청서를 써야 하는 그 모든 것들. 그게 전부 거버넌스의 말단 조각들이다.

그래서 "고객의 거버넌스 안에서 만든다"는 말의 진짜 의미는 이렇다.

 

데모 환경에서 규칙 다 무시하고 돌아가는 PoC가 아니라, 그 회사의 보안 규정과 권한 체계와 컴플라이언스를 전부 통과하는 진짜 시스템을 만든다

AWS가 이 단어를 반복하는 이유도 여기 있다. 타깃 고객이 금융, 정부, 규제 산업이기 때문이다. 이 동네에서는 "만들 수 있냐"보다 "규정 안에서 만들 수 있냐"가 진짜 난이도다.

 

 

4. 온톨로지 vs 딜리버리 하네스

 

파트너 발표문에서 가장 중요한 개념이 "딜리버리 하네스(Delivery Harness)"다.

모든 FDE 프로젝트는 파트너가 영구 소유하는 재사용 가능한 하네스를 만드는데, 그 구성 요소로 도메인 온톨로지, 평가 프레임워크, MCP 서버, 에이전트 운영 도구, 컨텍스트 그래프가 나열된다.

처음에 나는 온톨로지와 하네스가 결국 같은 얘기 아닌가 생각했다. 둘 다 AI가 효율적으로 동작하도록 가이던스를 잡아주는 것이니까.

절반은 맞고 절반은 틀렸다. 핵심은 층위가 다르다는 것이다.

온톨로지는 하네스의 부품 중 하나다.

온톨로지 = 지식 (무엇을 아는가)

특정 도메인의 개념과 관계를 기계가 추론 가능한 형태로 구조화한 것이다.

커뮤니티 서비스로 예를 들면 이런 것이다.

• 게시글은 카테고리에 속한다
• 사용자는 게시글을 작성한다
• 신고가 N회 누적되면 게시글은 숨김 상태가 된다

이런 엔티티, 관계, 비즈니스 규칙의 체계. DB 스키마 + 도메인 모델 + 비즈니스 규칙을 합쳐놓은 것에 가깝다.

AI 에이전트가 이걸 알아야 "이 신고 처리해줘"라는 요청에서 뭘 조회하고 뭘 바꿔야 하는지 추론할 수 있다.

하네스 = 실행 인프라 (어떻게 안전하고 반복 가능하게 돌리는가)

에이전트를 프로덕션에서 굴리기 위한 배선 전체다. 온톨로지(지식)에 더해서:

• 평가 프레임워크(evals): 에이전트 출력이 맞는지 자동 검증. 프로덕션 에이전트에서 사실상 가장 중요한 부분
• MCP 서버: 에이전트가 실제 시스템에 연결되는 표준화된 도구 인터페이스
• 운영 도구: 모니터링, 롤백, 권한 제어
• 컨텍스트 그래프: 프로젝트마다 내린 아키텍처 결정과 그 이유의 축적

비유하자면 이렇다.

온톨로지는 지도다. 하네스는 지도 + 차량 + 안전벨트 + 계기판 + 정비 매뉴얼을 합친 것이다.

온톨로지만 있으면 AI가 "알기는" 한다. 하지만 하네스가 없으면 그 지식으로 실제 시스템을 안전하게 조작하고, 결과를 검증하고, 다음 프로젝트에 재사용할 수 없다.

AWS가 하네스를 강조하는 이유도 여기 있다. 지식(온톨로지)은 프로젝트마다 새로 만들어야 하지만, 하네스 구조 자체는 재사용되면서 복리로 쌓이기 때문이다.

실제로 공식 발표문에는 이 온톨로지가 구현된 형태도 나온다. 고객의 AWS 계정에 시맨틱 레이어를 배포하고, 이것이 엔터프라이즈 데이터 소스에 연결되어 버전 관리되는 지식 그래프를 발행하며, 에이전트가 그 위에서 추론한다.

이 문장의 함의가 재미있다.

도메인 전문성이 (퇴사할 수 있는) 사람 머릿속이 아니라 고객의 코드에 남는다.

 

 

 

5. 파트너 확장: AWS의 진짜 노림수

 

두 번째 발표문(파트너 대상)은 기술 문서라기보다 전략 문서에 가깝다.

핵심 메시지는 이렇다. FDE 역량을 AWS 직원만이 아니라 컨설팅 파트너사 내부에도 심겠다. 자격증도 교육 프로그램도 아니고, 파트너사 안에 AWS와 동일한 방법론과 프로덕션 기준으로 움직이는 상시 딜리버리 조직을 만드는 것이다.

운영 방식은 이렇다.

1. 파트너는 전담(ring-fenced) AWS 공인 엔지니어링 팀을 구성한다
2. 초기 프로젝트에서는 AWS 엔지니어가 파트너와 깊게 함께 일한다
3. 재사용 패턴이 쌓이면 AWS는 파트너 FDE 조직의 스케일링을 돕는 쪽으로 빠진다
4. 파트너 엔지니어는 고객 투입 전 AWS가 정의한 기술 기준을 통과해야 한다 (체크박스식 자격증이 아니라 AWS FDE 팀과 동일한 방법론으로 검증)

참고로 지금 당장 아무나 신청할 수 있는 건 아니다. 초기에는 소수 전략 파트너로 시작해서 딜리버리 모델을 검증한 뒤 확대할 예정이라고 한다.

 

 

6. 개발자 입장에서의 시사점

 

이 발표에서 개인적으로 주목한 포인트가 몇 가지 있다.

 

첫째, MCP가 AWS 공식 문서에 표준처럼 등장한다.

MCP(Model Context Protocol)는 Anthropic이 공개한 오픈 프로토콜인데, AWS 파트너 전략 문서에 하네스의 핵심 구성 요소로 아무 설명 없이 등장한다. 이미 업계 표준이 됐다는 뜻이다.

둘째, "프로덕션 에이전틱 시스템"을 만들 줄 아는 엔지니어의 수요가 명시적으로 선언됐다.

발표문의 논리를 뒤집으면 이렇다. 에이전트 데모를 만드는 사람은 많지만, 거버넌스를 통과하고 평가 프레임워크를 갖춘 프로덕션 에이전트를 만드는 사람은 부족하다. 그래서 1조 원을 태운다.

셋째, 앞으로 이력서에서 강해질 키워드가 보인다.

• 에이전트 평가 프레임워크(evals) 구축 경험
• MCP 서버 개발 경험
• 온톨로지/지식 그래프 설계 경험
• 규제 환경(거버넌스) 하에서의 AI 시스템 배포 경험

기존 백엔드 역량(도메인 모델링, 인프라, 보안)이 없어지는 게 아니라, 그 위에 에이전트 레이어가 얹히는 그림이다. 온톨로지 설계라는 게 결국 우리가 늘 하던 도메인 모델링의 연장선이라는 점을 생각하면, 백엔드 개발자에게는 오히려 기회에 가깝다.

 

 

후기

 

AI가 개발자를 대체한다는 이야기가 계속 나오는 시기에, 정작 AWS는 1조 원을 들여 "사람 엔지니어를 고객사에 보내는" 조직을 만들었다.

물론 그 엔지니어들은 에이전트와 함께 일하고, AI가 실행하고 인간이 검증하는 방식(AI-Driven Development Lifecycle)으로 일한다. 하지만 결국 거버넌스를 이해하고, 도메인을 온톨로지로 구조화하고, 시스템이 제대로 동작하는지 검증하는 건 사람의 일로 남는다.

바뀌는 건 "코드를 얼마나 빨리 치느냐"가 아니라 "AI가 안전하게 일할 수 있는 판(하네스)을 누가 깔 수 있느냐"인 것 같다.

 

 

 

IT 커뮤니티의 더 많은글을 보려면?:

https://www.itgo-community.com/

잇고(ITgo) — IT·개발자 커뮤니티