2026년 5월 20일부터 21일까지 이틀간 진행된 AWS Summit Seoul 2026에 참여했다.
AWS Summit은 이번이 처음이었다. AWS에 관심은 꾸준히 가지고 있었지만, 이렇게 큰 규모의 오프라인 행사에 직접 참여한 것은
처음이었기 때문에 행사장에 들어가기 전까지는 어떤 분위기일지 쉽게 상상이 되지 않았다.
이번 Summit에 참여한 가장 큰 이유는 AWS가 클라우드 시장의 선두 주자라는 점 때문이었다.
클라우드 시장을 이끌어 온 AWS가 현재 AI 흐름을 어떻게 바라보고 있는지,
그리고 실제 기업들은 AWS 위에서 AI를 어떤 방식으로 활용하고 있는지 직접 확인해보고 싶었다.
이번 Summit은 1일차 Industry Day, 2일차 AI Day로 구성되어 있었다.
하지만 실제로 세션을 들어보니 첫날부터 이미 전체 분위기는 AI를 중심으로 흘러가고 있었다.
금융, 로봇, 고객 경험, 개발 라이프사이클, 서버리스, 에이전틱 AI 등 다루는 도메인은 다양했지만, 결국 많은 발표가
“AI를 어떻게 실제 비즈니스와 서비스에 적용할 것인가”라는 질문으로 연결되고 있었다.
이틀 동안 총 10개의 세션에 참여했다.
- 기조연설 - Industry Day
- KBaaS, 금융이 플랫폼 속으로 : KB국민은행의 임베디드 금융 전략과 API 인프라 현대화
- AWS 위에서 만드는 로봇의 미래: 리얼월드의 RFM 학습과 위로보틱스의 휴머노이드 조작기능 구현
- 복잡함 속의 질서 : Beyond AI Adoption in Agentic Era
- 혁신가와 리더의 대담 - AI로 이끄는 비즈니스 혁신
- Amazon Connect Customer AI Agent가 다시 쓰는 고객 경험 : 불만을 감동으로
- AI 기반 개발 라이프사이클(AI-DLC) 소개
- AWS AI와 서버리스로 구축하는 완성차 지능형 상품 전략 플랫폼
- 200개국 삼성 스마트 TV 앱 데이터를 자연어로 묻다: 에이전틱 AI on AWS
- 에이전트 성능 평가와 개선: 개발부터 운영까지
모든 세션을 하나씩 자세히 정리하기보다는, 이번 글에서는
특히 인상 깊었던 세션들과 그 과정에서 정리하게 된 생각을 중심으로 기록해보려고 한다.
생각보다 훨씬 컸던 AWS 생태계의 존재감
가장 먼저 느낀 것은 행사장의 규모와 열기였다.
세션마다 사람이 많았고, 관심 있는 발표를 듣기 위해 많은 사람들이 이동하고 대기하는 모습을 볼 수 있었다.
단순히 AWS 서비스를 소개하는 자리가 아니라, 이미 많은 기업과 개발자들이 AWS 기반으로 서비스를 만들고 운영하고 있으며,
그 위에서 AI를 어떻게 활용할지 고민하고 있다는 점이 현장에서 바로 느껴졌다.
예전에 AWS 온라인 교육 프로그램에 참여한 적이 있었다.
당시에는 AWS에 대한 이해가 충분하지 않았기 때문에, 일부 내용이 AWS 서비스를 홍보하는 강의처럼 느껴지기도 했다.
무엇을 설명하는지는 알겠지만, 왜 중요한지까지는 깊게 와닿지 않았던 기억이 있다.
그런데 이번 Summit에서는 조금 다르게 받아들여졌다.
AWS가 단순히 클라우드 서비스를 제공하는 회사를 넘어,
현재 AI 시장과 소프트웨어 개발 방식의 변화를 이끌어가는 주요 플랫폼 중 하나라는 점이 더 분명하게 느껴졌다.
그래서 이번에는 “AWS가 어떤 서비스를 제공하는가?”보다
“AWS는 AI 시대의 흐름을 어떤 방향으로 이끌고 있는가?”,
그리고
“나는 그 흐름 속에서 어떤 역량을 갖춰야 하는가?”
라는 관점으로 세션을 듣게 되었다.
Why에서 Why Not으로
첫째 날 기조연설에서 가장 기억에 남았던 표현은 “Why”에서 “Why Not”으로의 전환이었다.
Jason Bennett - Vice President, Worldwide Startups and VC, AWS 의 발표 중 나온 내용이었는데,
개인적으로 이번 Summit 전체를 관통하는 문장처럼 느껴졌다.
그동안 새로운 아이디어나 서비스를 떠올릴 때는 자연스럽게
“왜 해야 하지?”, “정말 가능한가?”, “구현하려면 너무 복잡하지 않을까?” 같은 질문을 먼저 하게 되는 경우가 많았다.
하지만 AI를 활용하면 아이디어를 직접 만들어보고 실험하는 과정이 이전보다 훨씬 빨라진다.
완성도 높은 결과물을 처음부터 만드는 것은 여전히 어렵지만,
적어도 가능성을 검증하고 초기 형태를 구현해보는 진입 장벽은 분명히 낮아졌다는 생각이 들었다.
이 지점에서 “Why?”보다 “Why Not?”이라는 태도가 가능해졌다는 말이 특히 인상 깊었다.
다만 그렇다고 해서 기본기가 덜 중요해졌다는 뜻은 아니라고 느꼈다. 오히려 반대에 가까웠다.
AI를 통해 무언가를 빠르게 만들어낼 수 있는 시대가 되었기 때문에,
그 결과물이 올바른 방향으로 가고 있는지 판단하는 능력이 더 중요해졌다.
결국 코드를 얼마나 빠르게 작성하느냐보다 더 중요한 것은
문제를 이해하는 능력, 도메인을 해석하는 능력, 그리고 적절한 소프트웨어 구조를 설계하는 능력이라는 생각이 들었다.
고객 경험을 바꾸는 AI Agent
가장 인상 깊었던 세션 중 하나는 “Amazon Connect Customer AI Agent가 다시 쓰는 고객 경험 : 불만을 감동으로”였다.
이 세션이 좋았던 이유는 AI를 단순히 “대단한 기술”로 설명하기보다,
실제 고객 경험 안에서 어떤 역할을 할 수 있는지를 보여주었다는 점이었다.
특히 고객 문의나 불만 처리처럼 반복적이면서도 감정적인 부담이 큰 업무에서 AI가 어떻게 개입할 수 있는지를 구체적으로 볼 수 있었다.
세션에서는 항공편 지연 상황을 바탕으로 데모가 진행되었다.
고객이 항공편 지연 문제로 문의했을 때, AI Agent가 단순히 정해진 답변을 반복하는 것이 아니라
고객의 상황을 진단하고, 적절한 조치를 위해 여러 MCP 툴을 유연하게 호출하는 흐름이 인상 깊었다.
또 흥미로웠던 부분은 외부 API와의 연동이었다. 실제 서비스 환경에서는 고객의 상황을 이해하기 위해
내부 시스템이나 외부 API를 호출해야 하는 경우가 많은데, 이 데모에서는 AI가 상황에 맞는 외부 API를 호출하고,
그 결과를 이해한 뒤 추가 응대까지 이어가는 모습을 보여주었다.
특히 좋았던 것은 대화의 맥락이 끊기지 않도록 설계되어 있다는 점이었다.
AI가 1차적으로 고객 상황에 대응한 뒤 상담사에게 연결되는 경우에도, 상담사는 처음부터 다시 상황을 파악할 필요가 없었다.
AI와 고객이 나눈 대화의 맥락이 정리된 대시보드를 통해 상담사가 자연스럽게 이어서 응대할 수 있도록 지원하는 구조였다.
실제 고객 응대에서 가장 불편한 경험 중 하나는 상담사가 바뀔 때마다 같은 내용을 다시 설명해야 하는 상황이다.
세션에서 보여준 구조는 바로 그런 문제를 AI로 어떻게 줄일 수 있는지를 잘 보여주었다.
이 세션을 들으며 예전에 진행했던 프로젝트도 떠올랐다. 과거에 키오스크 기반 회의실 관리 서비스를 만든 적이 있었는데, 여기에 AI Agent를 결합하면 어떨까 하는 생각이 들었다.
예를 들어 사용자가 키오스크 화면에서 회의실을 직접 선택하고 예약하는 방식에서 더 나아가,
AI Agent가 사용자의 요청을 이해하고 가능한 시간대나 회의실을 추천해줄 수 있다면
서비스 경험이 훨씬 자연스러워질 수 있겠다는 생각이 들었다.
다만 동시에 한 가지 개인적인 의문도 생겼다.
AI Agent가 사용자와 상호작용할 때 반드시 음성이나 TTS 중심으로 가야 할까?
경우에 따라서는 음성보다 체크박스, 선택지, 자연어 입력, 화면 기반 인터페이스가 더 편안한 경험이 될 수도 있지 않을까?
이 부분은 세션의 직접적인 내용이라기보다, 세션을 들으며 개인적으로 확장하게 된 생각에 가깝다.
하지만 AI를 서비스에 적용할 때 중요한 것은 “AI를 넣었다”는 사실보다,
사용자가 어떤 방식으로 가장 자연스럽게 문제를 해결할 수 있는가라는 점이라고 느꼈다.
SDLC에서 AI-DLC로
두 번째로 인상 깊었던 세션은 “AI 기반 개발 라이프사이클(AI-DLC) 소개”였다.
이 세션은 기존의 SDLC, 즉 Software Development Life Cycle이 AI 시대에 어떻게 변화할 수 있는지를 보여주었다.
단순히 개발자가 AI 도구를 사용해 코드를 더 빠르게 작성한다는 이야기가 아니라,
요구사항 분석, 설계, 구현, 테스트, 운영까지 이어지는 전체 소프트웨어 개발 과정에서
AI가 어떻게 보조 역할을 할 수 있는지를 설명하는 세션이었다.
개인적으로 가장 크게 남은 메시지는 AI와 사람이 각자 잘하는 일에 집중해야 한다는 것이었다.
AI는 빠르게 초안을 만들고, 반복 작업을 줄이고, 다양한 가능성을 제안하는 데 강점이 있다.
반면 사람은 맥락을 이해하고, 최종 결정을 내리고, 책임 있는 판단을 해야 한다.
즉, AI-DLC는 AI가 사람을 대체하는 구조라기보다,
AI와 사람이 하나의 워크플로우 안에서 협업하는 구조에 더 가까워 보였다.
LG에서는 이를 세 가지 관점으로 설명했다.
첫 번째는 업무 분해였다.
계층적 Inception을 통해 작업을 적절한 단위로 나누고,
1인이 1~2일 안에 Construction 가능한 크기로 작업 단위를 분할하는 방식이었다.
특히 500라인 이하의 분량이 사람과 AI 모두에게 안정적이라는 경험적 기준을 제시한 점이 인상 깊었다.
AI를 활용한다고 해서 무조건 큰 작업을 한 번에 맡길 수 있는 것은 아니었다.
오히려 작업을 잘게 나누고, AI가 안정적으로 처리할 수 있는 단위로 구조화하는 능력이 중요하다는 점이 눈에 들어왔다.
두 번째는 정보 보존이었다. 이 부분은 개인적으로 특히 중요하게 느껴졌다.
세션에서는 AI가 본능적으로 요약하려는 경향이 있으며, 소프트웨어 설계에서는 이것이 치명적일 수 있다고 설명했다.
개발 과정에서 중요한 것은 단순한 요약이 아니라, 왜 그런 설계 결정을 내렸는지에 대한 맥락이다.
설계 의사 결정이 코드까지 이어지려면, 중간 과정의 정보가 사라지지 않도록 관리해야 한다.
이를 위해 계획 단계에서 참조해야 하는 문서 목록을 명시적으로 관리하고,
사람이 최종적으로 확인해 누락된 문서를 추가하며,
AI에게 명확한 제약과 기대치를 설정하는 전략을 사용했다고 소개했다.
이 부분을 들으며 AI 시대의 개발에서는 문서화와 설계 기록의 중요성이 오히려 더 커질 수 있겠다는 생각이 들었다.
세 번째는 기존 결정과의 공존이었다.
기업 환경에는 이미 사람이 내린 수많은 결정들이 존재한다.
기존 시스템의 구조, 조직의 정책, 기술 스택, 도메인 규칙, 과거의 설계 판단 등이 모두 현재의 개발에 영향을 준다.
AI가 유용하게 동작하려면 이러한 외부 맥락을 무시해서는 안 된다.
세션에서는 AI의 역할을 “확정된 것은 존중하고, 애매한 것은 질문하며, 빈 곳은 제안하게 만드는 것”으로 설명했다.
이 표현이 특히 기억에 남았다.
AI를 잘 활용한다는 것은 AI에게 모든 것을 맡기는 것이 아니라, AI가 어떤 맥락 안에서 일해야 하는지를 분명히 정해주는 것에 가깝다.
결국 좋은 결과를 얻기 위해서는 사람이 도메인과 기존 의사결정을 이해하고 있어야 한다.
이 세션을 통해 AI 시대의 개발자는 단순히 프롬프트를 잘 쓰는 사람이 아니라,
작업을 분해하고, 정보를 보존하며, 기존 맥락과 공존할 수 있는 개발 프로세스 자체를 설계할 수 있어야 한다는 생각이 들었다.
에이전트는 만들어지는 것보다 평가되고 개선되어야 한다
세 번째로 인상 깊었던 세션은 “에이전트 성능 평가와 개선: 개발부터 운영까지”였다.
요즘 AI Agent에 대한 이야기는 정말 많다.
하지만 실제 서비스를 만든다고 생각하면 Agent를 구현하는 것만으로는 부족하다.
운영 환경에서 안정적으로 동작하는지,
의도한 답변을 일관되게 제공하는지,
잘못된 도구를 호출하지는 않는지,
성능을 어떻게 측정하고 개선할 것인지가 훨씬 중요해진다.
세션에서는 먼저 에이전트 개발자들이 밤잠을 설치게 만드는 네 가지 문제를 소개했다.
설계상 비결정론적이라는 점,
잘못된 도구와 잘못된 파라미터를 선택할 수 있다는 점,
“더 나아졌다”는 것을 측정하기 어렵다는 점,
그리고 자동 회귀 오류가 발생할 수 있다는 점이었다.
이 네 가지는 AI Agent를 실제 서비스로 운영하려면 결국 반드시 마주하게 될 문제처럼 느껴졌다.
특히 “더 나아졌다”를 어떻게 측정할 것인가라는 질문이 인상 깊었다.
단순히 응답이 자연스러워 보인다고 해서 좋은 에이전트라고 말할 수는 없다.
실제로 사용자의 목적을 달성했는지,
올바른 도구를 호출했는지,
적절한 파라미터를 사용했는지,
이전보다 실패율이 줄었는지를 판단할 수 있어야 한다.
세션에서는 에이전트가 지속적으로 평가되고 개선되어야 한다고 설명했다.
모델 업데이트, 에이전트의 새 버전, 소스 프롬프트 수정, Tool 추가와 제거가 반복적으로 이루어지고,
그때마다 평가 과정이 필요하다는 것이다.
에이전트 평가 라이프사이클도 구체적으로 소개되었다.
에이전트를 구축하고, 평가 데이터셋을 찾거나 생성하고, Evaluator를 선택하고,
에이전트를 평가할 모델을 선택하고, 평가 수행 인프라를 구축하고, 결과를 기록하고 인사이트를 종합해 조정하며,
프로덕션 환경에서 모니터링하는 과정이 반복되어야 한다는 내용이었다.
이 과정을 들으며 AI Agent 개발은 단순히 프롬프트를 작성하고 도구를 연결하는 작업이 아니라는 점을 다시 느꼈다.
Agent가 실제 서비스로 운영되려면 평가 체계와 개선 루프가 함께 설계되어야 한다는 것이다.
세션에서는 AWS의 AgentCore Evaluations를 활용하면 이러한 과정의 부담을 줄일 수 있다고 소개했다.
또 사용자 시뮬레이터를 활용한 에이전트 평가 Preview도 언급되었다.
Amazon Bedrock FM을 사용해 다양한 표현으로 테스트하고,
자유 대화 평가를 진행하며, 시나리오 커버리지를 확장하고, 다양성 기반 회귀 테스트를 수행할 수 있다는 내용이었다.
여기서 중요한 개념으로 Ground Truth도 소개되었다.
세션에서는 이를 어설션, 예상 응답, 예상 궤적과 같은 형태로 표현할 수 있다고 설명했다.
이 부분이 특히 중요하게 느껴졌다. AI Agent는 항상 동일한 문장을 출력하지 않을 수 있기 때문에,
단순히 정답 문자열 하나와 비교하는 방식으로는 평가하기 어렵다.
어떤 조건을 만족해야 하는지, 어떤 응답이 기대되는지, 어떤 경로로 도구를 호출해야 하는지 등
평가 기준 자체를 더 섬세하게 설계해야 한다는 점이 인상 깊었다.
결국 에이전트 성능 평가에서 중요한 것은 “잘 되는 것처럼 보이는가?”가 아니라,
“무엇을 기준으로 잘 되었다고 판단할 것인가?”였다.
이 세션을 통해 나는 에이전트 개발자라면 이러한 평가 라이프사이클을 직접 설계하고 작성해보는 경험이 반드시 필요하다고 느꼈다.
AWS의 도구를 활용할 수는 있지만, 특정 서비스에만 의존하기보다
에이전트가 어떻게 평가되고 개선되어야 하는지에 대한 기본적인 구조를 이해하고 있어야 한다고 생각했다.
나는 최종적으로 아키텍터를 지향하고 있지만, 단순히 큰 구조만 이야기하는 사람이 되고 싶지는 않다.
AI Agent 개발 정도는 직접 다룰 수 있고, 개발의 구체적인 어려움과 평가 과정을 이해한 상태에서
아키텍처를 제시할 수 있는 사람이 되고 싶다는 생각도 더 분명해졌다.
AI 시대에 내가 갖춰야 할 역량
이번 Summit을 통해 가장 많이 생각한 것은 “AI 시대에 어떤 개발자가 되어야 하는가”였다.
졸업을 앞둔 입장에서, 이 질문은 단순한 감상이 아니라 앞으로의 진로와도 바로 연결되는 질문이었다.
AI를 잘 사용하는 것도 물론 중요하다. 하지만 그것만으로는 부족하다고 느꼈다.
기업에서 정말 필요로 하는 사람은 AI 도구에 의존해 결과물을 빠르게 만들어내는 사람만은 아닐 것이다.
오히려 중요한 것은
도메인과 비즈니스를 이해하고, 그 문제를 해결하기 위해 어떤 기술과 구조가 적합한지 판단할 수 있는 사람이라고 생각한다.
금융, 자동차, 로봇, 고객 경험, 개발 라이프사이클 등 서로 다른 세션을 들으며 공통적으로 느낀 점도 이와 같았다.
AI나 클라우드 기술이 단독으로 가치를 만드는 것이 아니라,
특정 도메인의 문제를 얼마나 정확히 이해하고 그에 맞는 아키텍처를 설계할 수 있는지가 중요했다.
특히 앞으로는 소프트웨어 아키텍처 설계 능력이 더욱 중요해질 것이라고 느꼈다.
AI를 통해 초기 구현은 더 빨라질 수 있다.
하지만 실제 서비스로 운영하기 위해서는
안정적인 구조, 확장 가능한 설계, 명확한 책임 분리, 운영과 평가 체계가 필요하다.
이 부분은 AI가 대신해주는 것이 아니라, 개발자가 더 깊게 고민해야 하는 영역이라고 생각한다.
그래서 나는 앞으로 단순히 코드를 작성하는 개발자에 머무르기보다,
도메인 중심으로 문제를 이해하고 비즈니스적인 맥락을 바탕으로
적합한 소프트웨어 아키텍처를 제시할 수 있는 개발자이자 아키텍터로 성장하고 싶다.
마무리
AWS Summit Seoul 2026은 나에게 단순히 AWS 서비스를 소개받는 자리가 아니었다.
클라우드 시장의 선두에 있는 AWS가 AI 시대를 어떤 방향으로 바라보고 있는지 확인할 수 있었고,
여러 기업들이 AI를 실제 비즈니스와 서비스에 어떻게 적용하고 있는지도 볼 수 있었다.
하지만 그보다 더 크게 남은 것은 기술 자체보다도 내가 앞으로 어떤 개발자가 되어야 하는가에 대한 고민이었다.
AI가 더 많은 코드를 작성하고, 더 빠르게 결과물을 만들어내는 시대가 오고 있다.
그렇기 때문에 개발자에게 필요한 역량은 오히려 더 넓어지고 있다고 생각한다.
문제를 이해하는 능력, 도메인을 해석하는 능력, 비즈니스 맥락을 파악하는 능력,
그리고 그에 맞는 소프트웨어 아키텍처를 설계하는 능력이 더욱 중요해지고 있다.
이번 Summit을 통해 나는 AI 시대의 개발자가 단순히 AI를 잘 사용하는 사람이 아니라,
AI를 이해하고 적절한 구조 안에서 활용할 수 있는 사람이어야 한다는 생각을 하게 되었다.
앞으로는 도메인과 비즈니스를 이해하고,
AI 시대에 적합한 소프트웨어 아키텍처를 제시할 수 있는 개발자로 성장하고 싶다.
