Dev log
2026 AWS Summit Seoul 방문기
AWS Summit Seoul에서 들은 세션과 현장 사진을 바탕으로 클라우드, AI, 인프라 운영 관점에서 얻은 생각을 정리한 방문기입니다.
- 행사: AWS Summit Seoul 2026
- 날짜: 2026-05-21
- 관심 주제: 생성형 AI, 클라우드 아키텍처, 운영 자동화, 관측 가능성, 비용 최적화
방문 목적
이번 AWS Summit에 방문한 목적은 단순히 AWS 서비스를 많이 알아보는 것보다, 실제 서비스들이 클라우드를 어떤 관점으로 설계하고 운영하는지 확인하는 것이었다.
- AI 기능을 운영할 때 필요한 인프라 설계 기준을 보고 싶었다.
- 현재 개발 시장의 트렌드와 기술을 보고 싶었다.
- 서버리스, 컨테이너, 관측 가능성, 비용 관리 사례를 확인하고 싶었다.
- BizKit AI 서버나 성당 앱 v2 같은 프로젝트에 적용할 수 있는 아이디어를 찾고 싶었다.
현장 분위기
이번 행사장에서는 AWS의 AI와 관련된 새로운 기능 발표, 협력사들의 AI서비스 활용 사례, AI Agent와 관련된 정보가 많이 보였다. 단순히 특정 서비스를 소개하는 세션보다, 실제 운영에서 어떤 문제가 생기고 AWS 서비스를 어떻게 조합해 해결하는지 설명하는 흐름이 인상적이었다.
세션 1. 기조연설
6가지의 주제가 다뤄졌다.
- AI시대 개발자들의 마음가짐
- AI-DLC, Kiro
- 우아한형제들 개발자 분들의 위 두 방법에 대한 개발 방법
- AWS의 Lambda, S3확대, Bedrock서비스 소개
- 아모레퍼시픽의 서비스 개발 소개
- AI서비스 실제 구현 사례 소개(아마존, ZOOX(자동차), KBS, Config(로봇))
세션에서 다룬 내용
AWS의 AI Agent 서비스를 소개하고 S3의 더 다양한 데이터 형식 지원, 협력사들의 활용 사례들을 발표하였다.
배민의 하네스 엔지니어링
아모레퍼시픽의 AI서비스 플로우
세션 2. AI 에이전트, AgentCore로 프로덕션까지
세션에서 다룬 내용
LG전자의 Amazon Bedrock을 이용해 Agent를 구축한 사례를 다루었다.
- 에이전틱 AI 시스템- PoC to Production
- Amazon Bedrock AgentCore
- 프로덕션 에이전트를 위한 8가지 규칙
- LG전자 AlOps 사례 : ThinQ Al Agent
기억에 남은 포인트
| 포인트 | 내용 |
|---|---|
| 프로덕션 체크리스트 | 신뢰성, 확장성, 메모리, 보안, 비용을 고려해야 한다. |
| Amazon Bedrock AgentCore | 위 체크리스트를 만족하고 확장성이 좋다. |
| 아키텍처 | 실행 계층, 보안/제어 계층, 도구 계층, 관찰 계층으로 이루어져있다. 실행계층 - 에이전트의 실행, 사용자와 대화, mcp프로토콜 호출(LLM)한다. 보안/제어 계층 - 본인확인, 비즈니스 규칙을 검증한다. 도구 계층 - 브라우저나 코드를 생성해 작업을 진행한다. 관찰 계층 - 에이전트의 동작과정을 실시간으로 관찰하고 성능을 추적한다. |
| 에이전트에 필요한 8가지 규칙 | 1. 문제에서부터 출발하고, 작게 시작하세요(에이전트의 작업, 톤, 기준점) 2. 처음부터 옵저버빌리티를 구성하세요.(개발단계부터 데이터 쌓아두기) 3. 도구 및 API연동을 계획하세요. 4. 에이전트 평가를 자동화하세요. 5. 멀티 에이전트를 활용하세요.(에이전트에 역할부여) 6. 여러사용자로 안전하게 확장하고, 개인화된 경험을 제공하세요.(사용자별 컨텍스트, 세션 격리) 7. 가능하면 코드를 사용하세요.(에이전트는 추론에만 계산, 검증, 규칙은 코드로 처리) 8. 테스트, 테스트, 또 테스트! (여러가지 테스트를 계속 진행) |
| LG전자의 ThinQ 공통 플랫폼의 AI Agent | 사내 업무대응을 Agent로 구현하여 담당자 연락 없이 24시간 메신저/web에서 Agent로 대응이 가능해 개발자가 기능개발에 집중할 수 있게 되었다. AI Agent 설계 핵심3가지는 역할을 나누고, 데이터의 품질을 높이고, 평가할 수 있어야한다. 데이터의 품질이 좋아야 하기 때문에 코드처럼 pr하며 관리했고, 운영은 AgentCore에 맡기고 데이터 품질에 더 집중하였다고 한다. |
카테부에서 프로젝트 할 때 고민했던 부분이 많이 있었다. 에이전트까지 개발은 아니었지만 LLM의 작업을 어떻게 검증, 평가, 관찰 할 것인가. 테스트 데이터 셋을 만들었지만 데이터셋이 완벽한가 에는 의문점이 계속 남아있었고, 어느 부분에서 병목이 발생하는지 자세하게 관찰하는 부분이 부족했던 것 같다. 여러가지 테스트를 반복적으로 진행해서 데이터의 품질을 높이는 방향도 항상 고려해야겠다.
세션 3. LLM 애플리케이션 프로덕션 운영, Observability
세션에서 다룬 내용
LLM 애플리케이션에 대한 내용을 다루었다.
- LLM 애플리케이션 만들기 쉬워졌지만 운영에서의 문제점
- LLM 애플리케이션의 파이프라인
- Provider LLM VS Local LLM
- 기존 모니터링 툴과 다른 LLM Observability
기억에 남은 포인트
| 포인트 | 내용 |
|---|---|
| 운영에서의 어려운 점 | 애플리케이션 개발은 쉬워졌지만 운영에서의 어려운 부분이 있다. 모델의 교체에 따른 통제 불가능한 영역, 할루시네이션에 대한 판단을 사용자에게 제공 하는 것 |
| LLM API 파이프라인 | User Input -> Prompt Template -> LLM API -> Response -> Action 26년5월 현재는 여기에 RAG, Agent 등 다양한 기술이 추가되고있다. |
| 기존 API와 차이 | 1. 비결정적 출력 - 매번 다른 답이 나온다. 2. Latency 구조 - 일반 API는 수십 ms가 걸리지만 LLM은 초단위 응답 |
| ProviderLLM 과 Local LLM | ProviderLLM은 Local LLM 보다 모니터링 할 수 있는 영역이 적다. API에 의존하게 된다. 즉 모델서빙에 관한 부분은 외부에 맡기게 된다. 공통적으로는 응답품질, 프롬프트품질, 토큰 효율성을 파악할 수 있어야 한다. |
| LLM Observability | Application Layer - 사용자 요청 단위의 전체 흐름 추적(E2E Latency, Chain&&Agent, 프롬프트와 응답) LLM API Layer - 모델 호출 한 건의 성능과 비용 추적(TTFT, TPOT, TPS, Token Usage, Cost, Rate Limit) Infrastructure Layer - GPU 서빙 인프라(GPU, KV Cache, vRAM 사용량) |
카테부 프로젝트에서 제일 힘들었던 부분이다. 개발은 하고 있는 기능에 대해 성능을 측정하고 모니터링한다는게 어려웠다. 그라파나에 Runpod에 배포되어있는 LLM까지 시각화 해서 한눈에 보고 싶다는 생각이 많이 들었다. 당장 개발에 필요한 FastAPI로그, 모델쪽에는 RunPod에서 제공하는 vllm워커에 있는 기본 로그에만 의존했는데 다음 LLM프로젝트를 진행한다면 세션의 내용을 기억해서 모든 영역에 대해 한눈에 볼 수 있도록 시각화까지 한다면 효율적이게 개발이 가능하지 않을까 생각했다.
세션 4. 누구나 손쉽게 개발효율 200% 향상시키는 Kiro 활용법
세션에서 다룬 내용
AWS에서 새로 출시한 KIRO IDE를 활용하는 방법
- 컨텍스트 엔지니어링
- kiro의 3가지 도구 : MCP, Steering, Powers
- 시연
kiro를 사용하는 방법에 대한 세션이었다. 지금 Claude Code나 Codex를 제대로 활용하고 있는지 의문점이 들어 오픈소스 Agent를 사용해볼 계획에 있다. kiro는 IDE 안에서 요구사항, 하네스, 작업 흐름을 함께 관리해서 개발자가 편하고 쉽게 Agent를 사용할 수 있도록 하는 방향이 인상적이었다. 실제 프로젝트에 적용한다면 코드 생성 능력보다 작업 기준을 얼마나 안정적으로 유지하는지 확인해보고 싶다.
세션 5. 에이전트 성능 평가와 개선: 개발부터 운영까지
세션에서 다룬 내용
- AgentCore Evaluation과 Strands Evaluation을 활용한 성능 측정 방법
- AgentCore Evaluation을 통해 프로덕션 환경에서 에이전트를 지속적으로 모니터링하고 개선하는 방법
AgentCore를 사용해보지 않아 성능평가에 대한 중점으로 보았다.
| 포인트 | 내용 |
|---|---|
| 에이전트 평가방법 | 온디맨드 평가와 온라인 평가로 나뉘어진다. 배포전 타겟 테스팅을 하고 출시 전 벤치마크 테스트를 통해 품질을 보증하고, 배포 후에는 연속 샘플링, 연속 샘플링으로 지속적인 모니터링을 한다. |
| AgentCore Evaluation | 온디맨드 : 개발자가 Evaluation 데이터셋을 직접 생성하고 AgentCore Evaluation은 그 데이터셋을 기반으로 개발자에게 결과를 반환 온라인 : 사용자가 에이전트를 사용함에 따라 나온 결과값에 대해 Evaluator를 선택해 나온 결과를 개발자에게 지속적으로 반환 |
| 사용자 시뮬레이터 | 평가 데이터셋이 없거나 실제 사용을 통해서 생성한 데이터셋이 없는 경우에도 평가를 진행 할 수있게 해준다. -다양한 표현으로 테스트해서 매번 다른 문구, 경로를 생성해 엣지케이스를 발견 -고정 스크립트가아닌 실제 사용자 행동을 현실적으로 재현 -페르소나, 목표만 정의하면 대화를 자동으로 생성 -동일 의도의 다양한 표현에 일관 대응하는지 검증 |
| 코드 기반 Evaluator | LLM기반은 모든 점수에 LLM을 호출해 비용, 레이턴시가 증가하고, 동일한 입력에 대해 다른 점수가 나오며, 정확한계산, sql구문, json스키마 준수 여부를 안정적으로 검증할 수 없다. 하지만 코드기반은 위와 반대이기에 CI/CD 회귀 게이팅, 대규모 구조화된 출력검증, 정밀도 및 정확한 검사에 사용을 추천한다. |
| Ground Truth | LLM응답의 주관적인 것을 측정 가능한 것으로 전환하여 평가 어션셜 : 응답이 반드시 충족해야 하는 자유형식 텍스트 사실 - 규정준수 : '면책 조항 포함 필수' - 어조 : '공감적이어야 함' - 안전 : '자해를 권장해서는 안 됨' - 정확도 : '가격은 정확해야 함' 예상응답 : 에이전트의 최종 답변이 무엇을 말해야 하는지 - FAQ 봇 : 정확한 답변이 요구됨 - 수학/금융 : 정확한 결과 필요 - 회귀 : 알려진 정상 상태와 비교 - 턴별 : 추적 ID를 답변에 매핑 예상 궤적 : 에이전트가 반드시 호출해야 하는 순서가 지정된 도구 이름 - 다단계 워크플로우 - 보안, 감사 - 테스트 |
카테부 프로젝트에서 고민했던 내용이 담겨져 있었다. 점수를 LLM이 판단하게 한다. 이 계산이 적합한지 어떻게 평가 할 수 있을까? 매번 달라지는 점수는 신뢰성이 있는가? AgentCore Evaluation에서도 그런 부분은 코드기반으로 평가를 진행한다고 한다. Agent서비스를 개발할때 개발과정에서 평가시스템도 개발해야할텐데 Ground Truth관련 내용이 도움이 될 수 있을것같다.
느낀점
이번 AWS Summit에서 반복해서 확인한 흐름은 LLM을 단순 호출하는 단계를 넘어, Agent를 어떻게 평가하고 운영할 것인가로 관심이 이동하고 있다는 점이었다. AI 기능은 모델 선택만으로 끝나지 않고, 요청 추적, 실패 상태, 비용 관리, 관측 가능성까지 함께 설계하는 방향으로 많은 부분에서 측정하고 여러 방향으로 시도해봐야 한다는 것이다. BizKit AI 프로젝트에서도 모델 선택과 API 설계는 진행했지만, 평가와 관측 체계는 충분히 남기지 못했다. 다음 AI 프로젝트에서는 기능 구현과 동시에 측정 가능한 구조를 만들고, 코드 기반 검증과 Ground Truth를 함께 설계해야겠다고 느꼈다.
부스에서 재미로 해본 Kiro MBTI
