행사 소개
AWS에서 개최한 클라우드·AI 컨퍼런스 AWS Summit 2026에 다녀왔다.
- 행사명: AWS Summit Seoul 2026
- 일시: 2026.05.20 - 2026.05.21
- 장소: COEX
업무로 인해 양일 참여는 어려웠고, 2일차에만 참여할 수 있었다. 감사하게도 회사에서 행사 참여를 허가해 줘서 연차를 소모하지 않고 다녀올 수 있었다.
기본적인 행사 소개는 아래와 같다.
2일차는 AI Day로, AI 모델과 AI를 위한 데이터 기반, 에이전트 구축 등 AI라는 메가 트렌드를 둘러싼 다양한 기술들을 다뤘다. AI 핵심 기술은 잘 알지 못하지만, AI 활용은 매우 적극적으로 하고 있는 입장에서 참석할 수 있는 세션이 제한적이었지만, 타임별로 하나 이상은 있어서 잘 골라서 세션을 들었다.
참여한 세션은 아래와 같다.
- 결제 연동, AI 코딩 에이전트가 알아서 뚝딱 - StepPay
- AI 기반 개발 라이프사이클(AI-DLC)소개 - AWS, LG전자
- 오래된 IT 시스템 현대화, 에이전틱 AI로 쉽게 - AWS
- Notion: API를 넘어 플랫폼으로 - Notion
- 프로덕션으로 가기 위한 에이전틱 AI 아키텍처 설계하기 - AWS
대부분은 AWS 제품 소개 + 각 기업의 실 사용 사례로 구성되었다.
Expo 공간에서는 AWS 제품에 대한 소개와 대기업부터 스타트업까지 다양한 기업이 기술을 소개해주고 체험할 수 있는 기회를 제공했다. 특히 GS-네오텍 부스에서 소개한 6가지 제품들 중 일부는 내가 지금 업무에서 수행하고 있는 것들의 고도화된 버전이라는 점에서 인상 깊었다. 시간과 리소스가 제공되면 저런 식으로 고도화해보고 싶다는 생각이 들었다.
참여했던 모든 부스에서 다들 너무 친절하게 제품을 설명해주시고, 질문에 답변해주셔서 감사했다.
AWS에서는 KIRO라는 IDE를 적극적으로 홍보했고, 다양한 세션과 활용 사례에서 이 Tool을 추천했다.
Kiro: Bring engineering rigor to agentic development
Kiro helps you bridge the gap from AI coding to engineering: manage intent, complete long-running tasks across large codebases, validate code correctness with an agent that learns how you work.
kiro.dev
핵심 키워드는 SDD(Spec-Driven-Development) 와 AI-DLC(AI-Driven Development Life Cycle)이다. 이 두 가지를 결합하고 이를 손쉽게 활용할수록 돕는 IDE였다. AWS에서는 "어떻게 AI 생성 결과물의 품질을 관리할지", "팀 단위 협업에서 어떻게 컨텍스트를 공유할지"에 대한 해결책으로 SDD와 AI-DLC를 제시했다. 둘 다 이미 오래전부터 있는 개념이지만 이걸 어떻게 구조화하고 일관되게 가져갈까에 대한 강점이 있다고 느꼈다. (이 부분은 아래에서 다시 다룬다.)
점심 식사도 무료로 제공 받았는데, 퀄리티가 꽤 좋았다. 역시 대대기업 Amazon인가 싶었다. (선착순 n명에게만 준걸로 알고 있다.)
(행사 참가도 무료였다)
주요 세션 리뷰 1 : AI 기반 개발 라이프사이클(AI-DLC)
AI는 0 -> 1을 잘한다. 그러나 1 -> 100까지 가는 과정에서 품질과 제품에 대한 컨텍스트를 유지하기는 쉽지 않다. 이 세션에서는 AI 에이전트에게 코딩을 맡기면서도 장기적으로 소프트웨어 품질을 유지하고, 컨텍스트를 유지하며 팀원 간의 협업을 유지하기 위한 방법을 다뤘다. 그 방법으로 제시한 것이 AI-DLC(AI Driven Development Life Cycle)이다.
https://aws.amazon.com/ko/blogs/tech/ai-driven-development-life-cycle/
AI 주도 개발 라이프사이클: 소프트웨어 엔지니어링의 재구상 | Amazon Web Services
본 게시글은 AWS DevOps & Developer Productivity Blog에 게시된 AI-Driven Development Life Cycle: Reimagining Software Engineering by Raja SP을 한국어 번역 및 편집하였습니다. 비즈니스 및 기술 리더들은 생산성 향상, 속
aws.amazon.com
나는 지금은 Claude CLI를 메인으로 사용하고, Superpowers를 메인 Harness로 사용하고 있다. 이전에는 oh-my-claudecode를 사용했다. 두 Harness 모두 공통점이 있다. 하나의 대규모 작업을 요청하면 Superpowers는 plan, spec 문서를 하나씩 생성하고, oh-my-claudecode도 비슷한 문서를 생성한다. 그리고 이 문서를 input으로 대규모 작업을 수행하게 된다. 물론 이 방법도 아주 획기적이고 여전히 유효한 방법이다. 그러나 AI-DLC는 설계부터 구현, 테스트, 배포까지 더 세밀하게 제어하는 방법론이다.
AI-DLC 전체 사이클
AI-DLC는 Inception(착수), Construction(구축), Operation(운영) 3단계로 이루어진다.
- 착수: 전체 팀이 AI의 질문과 제안을 적극적으로 검증하여 AI가 비즈니스 의도를 상세한 요구사항, 스토리, Unit으로 변환
- 구축: 전 단계의 산출물을 기반으로 논리적 아키텍처, 도메인 모델, 코드 솔루션 및 테스트를 제안하고 수행
- 운영: 이전 단계에서 축적된 맥락을 적용하여 팀 감독 하에 코드형 인프라와 배포를 관리
즉, 각 단계는 다음 단계를 위해 더 풍부한 컨텍스트를 제공하여 AI가 점점 더 정보에 기반한 결정을 할 수 있게 돕는다.
AI-DLC 워크플로우
이런 워크플로우를 가지게 되고, 실제 시연에서 특이사항은 AI-DLC 결과로 생긴 문서는 단순히 spec문서 하나, plan 문서 하나가 아니다. 위에서 언급한 Unit 단위로 쪼개서, 각 Unit별로 /inception, /construction, /operation 3개의 폴더로 구분되고, 각 폴더 안에 여러 개의 문서가 생성된다는 점이었다.
이 부분은 AI-DLC를 오픈소스로 제공해 주셔서 코드를 뜯어보며 점진적으로 내 프로젝트에 적용할 계획이다. 아마 Kiro IDE를 사용하면 이러한 문서구조를 자동으로 제공해 줄 것 같다.
https://github.com/awslabs/aidlc-workflows
LG전자 활용 사례
20여분 간의 AWS의 소개가 끝난 뒤에 LG전자에서 이 워크플로우를 LG전자 개발 라이프사이클에 활용한 사례를 소개해주셨다.
LG전자에서는 2025년 11월부터 약 5개월간의 연구와 커스터마이징을 통해 위와 같은 워크플로우를 구축하였다고 한다.
연구 과정의 핵심은 아래와 같다.
1. 업무 분해: 계층적 Inception
단순 계획을 세우면 한 사람이 작업해야 할 분량이 매우 커진다. 따라서 적절한 작업 단위(Unit)로 분해될 때까지 Inception을 계층적으로 반복하는 방법을 채택했다고 한다. 경험적 기준으로는 1인이 1-2일 내에 Construction가능한 크기로 분할하고, 500라인 이하의 분량이 사람과 AI 모두에게 안정적이었다고 한다.
2. 정보 보존: 설계 의사 결정이 코드까지 유지되도록
AI는 본능적으로 요약하려고 하고, 이는 SW 설계에서 치명적이다. 상위 설계 문서를 시작으로 Inception 단계에서 참조해야 하는 문서 목록을 명시적으로 관리하는 것으로 이 문제를 어느 정도 해결한다. 또, 사람이 최종 확인하여 누락된 문서를 추가하도록 한다. 즉, AI의 명확한 제약을 이해하고 기대치를 설정하는 게 중요하다.
3. 기존 결정과의 공존: External Context
기업 환경에는 AI가 생각하기엔 최선의 결정이 아니더라도, 이미 AI가 모르는 이유로 인해 사람이 내린 결정들이 있다. 이러한 "사람이 내린" 기존 결정을 명시화 하고, 이를 거스르지 않도록 한다. 즉, 확정된 것은 존중하도록 하고, 애매한 것은 질문하며, 빈 곳은 제안하도록 만든다.
이 3개의 과정을 통해 위의 워크플로우를 구축하였다고 한다.
이를 통해 얻은 교훈은 아래와 같다.
기존 SDLC(Soft Development Life Cycle)에서 본질은 달라지지 않았다. 그 사이에 AI가 끼어들어갔을 뿐이다.
각 조직에 맞는 워크플로우를 설계하여 고도화하는 것이 각 조직의 생산성을 높이는 길인 것 같다.
주요 세션 리뷰 2 : 프로덕션으로 가기 위한 에이전틱 AI 아키텍처 설계
최근 에이전틱 AI 구성은 점점 복잡하고, 다양한 Tool을 유연하게 사용하는 방향으로 발전하고 있다. 이 과정에서 AI를 통제하고, 위험을 방지하고, 다양한 기능을 안정적으로 추가하고 운영하기 위한 AgentOps라는 개념이 등장했다. 기존의 DevOps와도 어느 정도 비슷한 목적성을 가진다. 이 세션에서는 확장 가능한 Agentic AI 플랫품을 구축하기 위한 아키텍처 패턴을 다룬다.
이 세션을 들은 이유는 내가 지금 하고 있는 업무와 유사해서이다. 나는 이 시점에 사내 폐쇄망 환경에서 동작하는 AI Agent를 평가하기 위한 기능을 중심으로 다양한 에이전트 관리를 위한 시스템을 만들고 있다. 이런 내용을 기대하고 참여했는데, 다행히 예상했던 내용으로 구성되어 있고, 덕분에 AI Agent를 안정적으로 운영하기 위한 아키텍처에 대한 시야가 확장된 것 같다.
최근의 AI Agent 구성
최근의 AI 에이전트는 단순히 질문 -> 응답만을 수행하지 않는다. 사용자 채팅, 이미지, 문서 등 다양한 종류의 input을 받아서 RAG, Graph, Chain 등 다양한 방식으로 동작한다. 또한 파운데이션 모델(main LLM)만을 사용하는 게 아니라 기타 에이전트와 통신을 하기도 하고, DB 조회, API 호출, 검색 엔진, MCP서버 등 응답 생성을 위해 다양한 Tool들을 활용한다. 그리고 최종 응답 전에는 가드레일 검사를 통해 안전한 응답을 반환하도록 방어한다.
엔터프라이즈 구축을 위한 요소
이 세션에서는 이런 여러 가지 요소들을 안정적으로 관리될 수 있도록 하는 아키텍처를 다뤘다. 지속가능한 엔터프라이즈 AI Agent를 구현하려면 아래와 같이 다양한 요소가 필요하다.
이렇게 AI Agent 엔터프라이즈 서비스를 안정적으로 운영하기 위한 Tool들을 소개해주셨다.
- Amazon Bedrock: 모델 접근, 맞춤화, 지식 기반, 비용 및 성능 최적화, 가드레일
- Amazon Bedrock AgentCore
- 도구 및 메모리: 메모리, 게이트웨이·정책, 브라우저 도구, 코드 인터프리터
- 대규모 안정적 배포: 런타임, 에이전트 레지스트리, 인증, 페이먼트
- 운영 인사이트 확보: 관측성, 평가, 최적화
AgentCore Gateway
Gateway를 통해 다양한 서비스의 일관된 통로를 제공하고, 라우팅 담당해서 내부 서비스들은 Micro Service처럼 관리되는 구조로 작은 책임을 가진 여러 개의 서비스로 구성할 수 있겠다는 느낌을 받았다.
관측 가능성
이 부분이 나에겐 가장 중요하다. 내가 지금 당장 실무에서 하고 있는 일이다. 그만큼 이해도 잘 됐던 부분이다. 다만, 나는 여기서 극히 일부만 구현했다. 내가 하고 있는 게 매우 고도화된다면 어떻게 될지에 대한 내용으로, 도움이 많이 되었다.
Agent는 만들고 끝이 아니다. 지속적으로 관측하고, 평가하고, 개선해야 한다. LLM 모델의 변화, 데이터소스의 변화 등에 따라 Agent의 성능은 언제든 들쭉날쭉할 수 있다. 이를 측정하기 위한 다양한 방법을 통해 Agent는 지속적으로 관리가 필요하다.
측정해야 하는 요소들은 아래와 같다.
- 운영: 호출 에러, 비용, 지연시간, 처리량
- 품질: 출력 품질, 환각, 정확도, 검색 관련성, 도구 선택
- 피드백: 명시적(예/아니오 사용자의 직접적 평가), 암묵적(같은 질문의 반복)
- 안정성: 유해성, 정보 유출, 편향, 인젝션 시도
이런 것들을 관측하기 위해서는 우선 Agent 구축 과정에서 관측 가능성을 위한 로깅과 이러한 로깅이 가능하도록 하는 아키텍처 설계가 중요할 것 같다.
평가
Agent 평가를 위해 모든 지점을 로깅하고, 모든 항목을 평가해야 한다.
이러한 다양한 평가를 통해 POC를 완성하고, 프로덕션에는 추가로 실제 사용자 인터렉션 및 로그를 통해 실데이터로 평가할 수 있을 것이다. 너무 많은 내용이 있어서 이 내용은 여기까지..
Key Messages
- Gateway: 모델·도구·에이전트에 대한 모든 것을 하나의 진입점에서 일관되게 관리해야 한다.
- 관측성 / 평가 : 에이전트의 동작을 모니터링 할 수 있도록 메트릭을 수집하고, 평가 루프를 연결하여 에이전트의 품질과 안정성을 지속적으로 검증해야 한다.
- AgentOps: 에이전트를 안전하고 효율적으로 운영하기 위한 프로세스를 구축해야 한다. 보안·거버넌스, 빌드·운영, 평가, 관측성 4가지 필러를 구축해서 책임감 있게 에이전트를 확장하자.
Expo 질의 응답
대부분 순식간에 지나가서 어디서 말씀 해주셨는지 기억이 안나는 것들이 대부분이지만 끄적여본다.
AI에 데이터를 넘길 때 비식별화
- AI에 민감정보를 넘기면 안된다. 그런데 로컬 모델은 성능이 비교적 떨어진다. 이를 해결하기 위한 방법
- OCR을 통해 이미지(서류) 분석
- 비식별화 대상 추출
- 추출 결과에서 [대상자_이름_1], [대상자_주민등록번호_1], [대상자_이메일_1] 와 같은 변수로 치환
- Key-value를 따로 보관 (key=대상자_주민등록번호_1, value=980101-1111111)
- LLM 작업 요청
- LLM 작업 결과물에 다시 [대상자_주민등록번호_1] 부분을 실제 value로 치환
이렇게 하면 LLM에 사용자 민감정보를 넘기지 않고도 최신 고성능 LLM에게 작업을 맡길 수 있다.
AI-DLC 문서관리
- AI-DLC 방법론은 문서가 너무 많음
- Q: 이 문서를 다 프로젝트에서 관리하는가?
- A: 관리하지 않는다. 그냥 버릴수도 있고, 어딘가에 관리할 수도 있다.
- 프로젝트 디렉터리에 넣으면 너무 커진다.
- 이 문서만을 위한 repo를 따로 파서 거기서 project docs 또는 작업 내용을 아카이빙 한다.
- 추가로, 작업 결과나 결정사항 같은 내용만 따로 요약해서 프로젝트 디렉터리에 넣는 방안도 있을 듯 하다.
- AI-DLC는 기본적으로 하나의 작업 사이클에 대한 것이다. 각 작업마다 각각의 AI-DLC 사이클이 돈다고 생각하면 된다.
마무리
이번에 참여한 AWS Summit Seoul 2026에서는 급변하고 있는 AI 활용과 운영에 대한 다양한 인사이트를 얻을 수 있었다. AI-DLC는 기존에 작성하던 plan, spec을 더 강화시켜 줄 수 있을 것 같고, AgentOps라는 개념을 통해 AI Agent를 지속가능하게 운영하기 위한 큰 그림을 얻을 수 있었다. 또한 AWS가 다양한 서비스를 제공하는 건 알고 있었지만, 이렇게 다양한 분야의 제품이 있는지는 몰랐고, 드넓은 AWS 생태계에 첫발을 들인 기분이다. 왜 AWS를 쓰는지 알겠다.
클라우드가 내 메인 업무는 아니지만 분명 클라우드를 다룰 줄 알아야 된다고는 생각한다. 내가 만든 애플리케이션이 어떻게 배포되고 운영되는지에 대한 더 넓은 시야를 얻은 것 같다. 그리고 "진짜 최신 AI"에 대해서도 체감할 수 있었고, 다른 기업들에서는 어떻게 사용하고 있는지 알게 되었다.
내가 작게 만들고 있는 것들을 대기업이 더 전문적으로 더 많은 인력을 투입해서 만들면 어떻게 고도화될 수 있는지 느꼈던 것 같다.
내년에 또 갈듯?
'etc > 끄적끄적...' 카테고리의 다른 글
| 코딩주짓수와 구글 코딩 가이드 (0) | 2024.12.30 |
|---|---|
| [부트캠프] 제로베이스 백엔드 취업 스쿨 수강 후기 / 회고 (4) | 2024.02.03 |
| 벡엔드 개발자가 자료구조, 알고리즘 공부를 해야하는 이유 (0) | 2023.07.04 |
| 앞으로의 백엔드 공부 계획 (백엔드 공부 로드맵) (2) | 2023.06.26 |
| 어떤 백엔드 개발자가 되고싶은가? (0) | 2023.06.20 |