AWS Summit Seoul 2026에서 본 Agentic AI: 모델보다 중요한 건 맥락!

 

2026년 AWS Summit Seoul을 다녀오며 가장 크게 남은 인상은 하나였다.

이제 생성형 AI 이야기는 "어떤 모델이 더 좋은가"에서

"AI가 실제 업무 안에서 어떻게 일하게 만들 것인가"로 넘어가고 있다는 점이다.

 

현장에서는 Amazon Bedrock, Bedrock AgentCore, Kiro, SageMaker Unified Studio 같은 서비스가 반복적으로 등장했다. AI를 잘 쓰려면 모델만 붙이면 되는 것이 아니다.

 

데이터를 정리해야 하고, 업무 맥락을 넣어야 하며, 실행 권한과 가드레일도 함께 설계해야 한다.

이번 Summit에서 내가 얻은 핵심 인사이트를 세 가지 관점으로 나눠 정리해본다.

---

1. 비즈니스 관점: AI 도입은 이제 운영의 문제다

AI를 실험하는 단계는 지났고, 이제는 실제 업무와 운영에 넣어야 한다.

SK텔레콤 세션에서는 AI 프로젝트가 실제 production까지 가지 못하는 이유를 데이터 플랫폼의 문제로 설명했다.

데이터는 많지만 표준이 다르고, 메타데이터가 부족하고,

권한과 거버넌스가 정리되지 않으면 AI가 제대로 활용하기 어렵다는 것이다.

---

CJ올리브영 사례는 production 전환을 가장 구체적으로 보여줬다.

AI-DLC라는 팀 단위 개발 프로세스를 도입해 요구사항 정의부터 설계, 구현, 테스트까지 AI와 함께 연결했다.

개인이 AI 도구를 잘 쓰는 것을 넘어, 팀 전체가 반복 가능한 구조로 AI와 협업하는 방식이었다.

Bedrock, OpenSearch, Step Functions, Lambda, Kiro를 함께 활용했다.

 

이 지점이 중요하다.
AI 도입의 병목은 더 이상 "모델을 호출할 수 있는가"가 아니다.

이미 모델은 충분히 많고, Bedrock 같은 플랫폼을 통해 접근성도 좋아졌다.

진짜 문제는 다음에 가깝다.

• 회사의 데이터는 AI가 이해할 수 있는 형태인가?
• AI가 참고해야 할 업무 맥락은 어디에 있는가?
• AI가 어떤 판단까지 해도 되고, 어디서 사람 승인이 필요한가?
• 결과를 어떻게 검증하고 다시 개선할 것인가?

즉, AI 도입은 운영 방식의 재설계에 가깝다 = AX

---

2. 기술 관점: Agentic AI의 핵심은 도구 연결보다 맥락 설계다

이번 행사에서 가장 자주 들린 키워드 중 하나는 Agentic AI였다.
에이전트가 스스로 도구를 호출하고, 정보를 찾고, 판단하고, 실행까지 하는 구조다.

 

AWS는 이 흐름을 Bedrock AgentCore와 Kiro 같은 서비스로 밀고 있었다.

 

AgentCore는 에이전트를 만들고 운영하기 위한 런타임, 메모리, 도구 게이트웨이, 인증, 관측성 같은 요소를 제공한다.

Kiro는 요구사항을 명세로 만들고, 그 명세를 코드와 테스트로 연결하는 개발 도구에 가깝다.

하지만 현장 사례를 보면, Agentic AI의 핵심은 단순히 "LLM에 도구를 붙이는 것"이 아니었다.

---

삼성전자 AIOps 세션에서는 운영 자동화를 다음 흐름으로 정리했다.

Trigger → Context → AI → Action → Guardrail → Output

알람이나 변경 이벤트가 발생하면, 로그와 메트릭, 배포 이력, 서비스 토폴로지 같은 맥락을 모은다.

그다음 AI가 분석하고, 필요한 액션을 제안하거나 실행한다. 단, 이 과정에는 반드시 가드레일과 사람의 승인이 들어간다.

---

넥슨의 Agentic Ops 사례는 더 인상적이었다.

하루 평균 모니터링 이벤트 371건, 일일 데이터 포인트 수십억, 그리고 MTTR(평균 복구 시간)은 매년 35%씩 늘어나고 있었다고 한다. 운영 복잡성이 가속되는 상황에서 사람만으로는 감당하기 어렵다는 이야기다.

 

넥슨의 접근은 LLM에게 모든 숫자 데이터를 그대로 넣지 않는 것이었다.

대신 통계 모델로 정상 범위를 먼저 정의하고, 이상 징후를 판단한 뒤, 그 결과를 LLM이 이해할 수 있는 맥락으로 바꿨다.

여기서 중요한 문장이 나왔다.

LLM은 숫자에 약하지만, 맥락만 있으면 전문가가 됩니다.

이 말이 이번 Summit의 기술적 핵심을 잘 요약한다고 느꼈다.

 

LLM은 많은 것을 할 수 있지만, 원시 데이터를 그대로 던져준다고 좋은 판단을 하는 것은 아니다.

정상과 비정상의 기준, 서비스의 특성, 과거 장애 이력, 운영자의 판단 방식이 함께 제공되어야 한다.

결국 Agentic AI의 품질은 모델 크기만으로 결정되지 않는다.
좋은 맥락을 얼마나 잘 만들고, 안전한 실행 경로에 얼마나 잘 연결하느냐가 더 중요하다.

---

3. 데이터 관점: Data Lake 다음은 Context Lake다

이번 행사에서 가장 많이 떠오른 표현은 AI-ready data였다.
AI가 활용할 수 있도록 데이터 품질, 표준, 메타데이터, 권한 체계를 갖추는 것이다.

 

그런데 세션들을 종합해보면 여기서 한 걸음 더 나아가야 한다.

운영 자체가 context-ready해야 한다.

Data Lake가 데이터를 모으는 공간이라면, 이제 필요한 것은 Context Lake에 가깝다.

 

AI가 판단할 수 있도록 업무 맥락, 의사결정 근거, 과거 사례, 실행 결과를 함께 모아야 한다.

예를 들어 운영 자동화에서는 단순히 CPU 사용률이 높다는 정보만으로는 부족하다.

• 이 서비스의 평소 트래픽 패턴은 어떤가?
• 비슷한 현상이 과거 장애로 이어진 적이 있는가?
• 최근 배포나 설정 변경이 있었는가?
• 담당자는 누구이고, 어떤 액션이 허용되는가?
• 이전에 사람이 어떻게 대응했고 결과는 어땠는가?

이런 맥락이 있어야 AI가 단순 알림을 넘어 판단 보조자가 될 수 있다.

---

AI는 더 잘 설계된 업무 흐름을 요구한다

이번 AWS Summit Seoul 2026을 통해 느낀 것은 명확하다.

AI를 잘 쓰는 회사는 단순히 최신 모델을 빨리 붙이는 회사가 아닐 것이다.
자신들의 데이터와 업무 맥락을 AI가 이해할 수 있게 정리하고,

실행 가능한 워크플로우와 안전장치를 함께 설계하는 회사일 것이다.

 

Bedrock, AgentCore, Kiro 같은 도구는 그 변화를 가능하게 하는 기반이다.

하지만 도구만으로는 충분하지 않다. 결국 중요한 질문은 이것이다.

우리 조직의 일은 AI가 이해할 수 있는 형태로 정리되어 있는가?

 

이번 Summit에서 얻은 가장 큰 배움은 여기에 있다.

---

한 줄 요약

AWS Summit Seoul 2026에서 본 Agentic AI의 핵심은 "모델"이 아니라 "데이터, 맥락, 가드레일, 실행 흐름"이었다.