AWS Summit Seoul 2026 후기 — AI-DLC·에이전틱 AI·서버리스 온콜 세 세션을 개발자 시선으로

AWS Summit Seoul 2026에서 참여했던 세션을 간단하게 정리해서 공유합니다.

1. AI-DLC: 코드 생성 가속만으로는 생산성이 오르지 않는다

첫 세션은 AI 개발 라이프사이클(AI-DLC) 방법론 소개(AWS 김수현)와 LG전자의 실제 적용기(박태진)로 나뉘었습니다.

생산성의 역설

AI 개발 도구는 빠르게 진화했습니다. 2023년 자동완성, 2024년 대화형 어시스턴트, 2025년 도구를 쓰는 에이전트, 2026년 자율 협업하는 멀티 에이전트로 이어졌습니다. 그런데 발표가 인용한 연구 결과는 기대에 못 미쳤습니다.

• 한 연구에서 AI를 활용해도 생산성 향상은 10~15%에 그쳤습니다. 반복 코드·테스트에는 유용했지만 복잡한 비즈니스 로직이나 대규모 리팩토링에는 효과가 낮았습니다.
• METR 연구에서는 숙련 개발자 16명에게 246개의 실제 이슈를 맡겼더니, AI 도구를 쓴 쪽이 오히려 19% 더 느렸습니다.

원인은 코딩이 개발자 업무의 일부일 뿐이라는 점이었습니다. 개발자 업무는 설계·분석, 소통·의사결정, 테스트·검증, 코딩으로 나뉘고 그중 코딩은 약 20%입니다. 코드 생성만 빨라지면 SDLC 전체로 보면 개선 폭이 작습니다. 게다가 팀끼리 서로 기다리고(개발↔QA↔운영) 각자 AI를 따로 쓰다 보니 컨텍스트가 단절돼 산출물 품질이 들쭉날쭉해집니다.

두 안티패턴, 그리고 HITL

발표는 AI 활용을 두 안티패턴으로 정리했습니다.

AI-DLC는 전 과정에서 AI를 쓰되 단계마다 사람이 검토·승인하는(Human-in-the-Loop) 방식으로 두 안티패턴을 보완합니다. 도구는 이미 도입돼 있지만 사람·프로세스의 체계가 비어 있고, AI-DLC가 채우려는 곳이 거기라는 설명이었습니다.

협업 모델은 사람이 의도를 전달하면 AI가 명확화 질문을 던지고, 사람이 답하면 AI가 산출물을 생성하고, 다시 사람이 리뷰·승인하는 순환입니다. 한 사이클을 볼트(Bolt)라 부르며 스프린트와 비슷하지만 더 작은 단위로 반복합니다. 인셉션(요구사항 이해·설계·작업 분해) → 컨스트럭션(코드·인프라 설계·생성·테스트) → 오퍼레이션(빌드·테스트·배포)의 3단계로 돌아가고, 모든 의사결정과 산출물이 생명주기 끝까지 기록되므로 대화 세션이 끊겨도 컨텍스트가 이어집니다. 그린필드/브라운필드를 AI가 스스로 판단하고 단순 버그픽스는 단계를 다 거치지 않는 식의 적응형 워크플로우도 강조됐습니다. 데모는 AWS의 에이전틱 코딩 도구 Kiro IDE로 진행됐습니다.

LG전자 적용기

박태진 위원이 다룬 대상은 수백 개 람다·컨테이너로 이루어진 수백만 라인 규모의 B2B 서버 플랫폼이었습니다. 고민은 "수십 명이 같은 설계 원칙을 같은 해석으로 구현하게 하는 법"과 "AI가 설계 단계에 어디까지 기여할 수 있나"였습니다. 작년 12월 3일간의 핸즈온에서는 하루로 잡았던 인셉션이 이틀로 늘고, 3일 내 통합에 실패해 5일간 바이브 코딩을 더 붙여 겨우 마무리했다고 합니다.

여기서 조직에 맞게 세 축을 커스터마이징했습니다.

• 계층적 인셉션. 인셉션의 본질은 업무 분해입니다. 한 번에 수십 명의 업무를 나눌 수 없으므로 팀 → 파트 → 개인으로 반복해 쪼갰고, 목표는 한 사람이 1~2일 내에 컨스트럭션할 크기였습니다. 한 단계의 정보량은 약 500라인이 사람과 AI 모두에게 안정적이었습니다.
• 대용량 산출물 처리. AI는 컨텍스트가 압박되면 읽을 문서를 스스로 생략하고 요약·누락하는 경향이 있는데, 설계에서는 치명적입니다. 그래서 각 단계가 읽어야 할 문서 목록을 명시하게 하고, 마지막에 사람이 누락 문서를 확인·추가하는 단계를 넣었습니다.
• 기존 결정과의 공존. 기업에는 이미 업무분장·API 경계·코딩 룰·기존 모듈이 있습니다. 이를 전제로 받아들이고 이슈를 드러내도록 External Context 수집, Source Tree, Unit Generation Draft, API Validation 단계를 추가했습니다.

사내 SRS/HLD/LLD 프로세스와 Jira·Confluence 등록까지 유틸리티 단계로 통합했고, 체감 생산성은 1.5~2배였습니다. 이 수준에 그치는 이유는 분명합니다. AI의 문서 생성은 빠르지만 읽고 판단·승인하는 병목은 여전히 사람에게 있기 때문입니다(그나마 사람이 글 쓰는 속도보다 읽는 속도가 빨라서 이득이 납니다). 부가 효과로, 보통 개발 후에 부가 작업으로 쓰던 SRS가 코딩 전에 자연스럽게 생성되고 그 Acceptance Criteria가 테스트 케이스로 이어져 추적성이 생겼습니다.

개발자 관점 적용 포인트

• "코드 생성 속도"만 KPI로 보면 함정이다. 팀의 병목도 설계·리뷰·승인·컨텍스트 전달에 있을 가능성이 높습니다.
• HITL을 기본값으로 둔다. AI에 통째로 맡기지 말고 단계별 승인 게이트를 둔 워크플로우를 설계합니다.
• 컨텍스트를 산출물로 남긴다. 의사결정·설계 문서를 코드와 함께 버전 관리하면 세션이 끊겨도, 사람이 바뀌어도 이어집니다.
• AI의 요약·누락 습성을 경계한다. 누락이 치명적인 단계에서는 읽어야 할 문서를 명시하고 사람이 검증합니다.

박태진 위원의 마무리: "AI는 도깨비 방망이가 아니다. 교과서에서 배웠지만 현실에서 못했던 것들을 제대로 할 수 있게 해주는 도구다. 개념을 이해하고 각자 환경에 맞게 다듬어라."

2. 에이전틱 AI: 도입 여부가 아니라 어떤 지표를 움직이는가

두 번째 세션(LG CNS 이상원)은 질문을 바꾸자는 이야기였습니다. "AI를 도입했나?"가 아니라 "AI가 매출·생산성·비용·CX 같은 지표를 실제로 바꾸고 있나?"이고, 대부분은 후자에 답하지 못한다는 진단이었습니다. 기술이 아니라 비즈니스 병목을 풀고, 자율성 수준을 비즈니스 맥락에 맞게 설계하는 것이 핵심입니다.

자율성 수준에 따른 4단계 분류

완전 자율 AI만 떠올리기 쉽지만 엔터프라이즈에서는 그대로 적용하기 어렵습니다. LG CNS는 자율성 수준에 따라 네 가지로 나눴고, 각각 직접 구축한 사례를 붙였습니다.

네 유형 사이에 우월한 것이 있는 게 아니라, 비즈니스 맥락과 ROI에 맞는 유형을 고르는 것이 핵심이라고 강조했습니다. 네 사례의 공통점은 두 가지였습니다. AI 기술이 아니라 비즈니스 병목에서 출발했고("어떤 모델 쓸까"가 아니라 "어떤 병목을 풀까"), 자율성 수준을 비즈니스 맥락에 맞춰 설계했습니다.

무엇을 측정할 것인가

도입 단계부터 에이전트가 어떤 비즈니스 지표를 움직일지 정의하고 시작해야 한다는 것이 밸류 아키텍처의 요지였습니다. 착수 전 고객과 합의하는 지표는 세 가지였습니다.

1. ROI — 매출 증대 / 비용 절감 / 속도. "하루 몇 시간 걸리는 업무를 몇 시간으로?"처럼 정량화합니다.
2. 고객 경험 지표(NPS·CX) — 정량 지표가 안 나올 때 씁니다(유통 C사).
3. TTM(Time-to-Market) — 리드타임 감축, 빠른 고객 대응(제약 D사).

실행은 Discovery(도입 정당성·방향·유스케이스 발굴) → Prototyping(단순 POC가 아니라 MVP에서 확장 가능한 단계적 접근) → Build(AWS 기반 플랫폼으로 지속 확장)의 3단계로 제시됐습니다.

발표 중 기억에 남는 문장: "POC를 위한 POC를 멈춰라." "AI가 되는지 한번 보자"가 아니라 "이 에이전트가 어떤 지표를 움직이나"를 들고 시작하라는 뜻입니다.

개발자 관점 적용 포인트

• 자율성 레벨을 아키텍처 결정으로 다룬다. "완전 자율 = 목표"가 아닙니다. 크리티컬한 대고객 경로엔 HITL 안전망을, 정형 반복 업무엔 풀 오토메이션을 둡니다.
• 기존 자동화(RPA/DX)와 공존하도록 설계한다. 슈퍼/플래너 에이전트가 MCP 또는 RPA를 골라 호출하는 구조여서 기존 자산을 다 갈아엎지 않습니다.
• 데이터 파이프라인이 곧 성패다. 풀 에이전틱 사례의 핵심은 비정형 데이터 전처리 에이전트와 10여 개 시스템 통합이었습니다.
• KPI를 먼저 못 박는다. AI 기능을 붙일 때 "이게 어떤 지표를 움직이나"를 착수 조건으로 둡니다.

3. 장애에 강한 팀: 서버리스 온콜과 셀프서비스 모니터링

세 번째 세션은 두 회사의 실전 사례였습니다. 올리브영(이태근)은 서드파티 온콜이 "전화가 안 울리는" 문제를 Amazon Connect로 다시 풀었고, 당근(김수빈)은 모니터링 알람이 플랫폼팀 한 곳에 몰리는 병목을 플랫폼 엔지니어링으로 풀었습니다.

1부 — Amazon Connect로 온콜 재구축

서드파티 온콜을 걷어낸 이유는 세 가지였습니다. 해외번호 발신이 국내 통신사 스팸 정책에 막혀 전화가 오지 않았고, 간헐적 발신 실패로 정작 급할 때 전화를 못 받았으며, 고정 비용보다 Amazon Connect의 사용량 기반 과금이 오히려 저렴했습니다.

설계 철학은 "단순하면서도 확실하게 전화를 울린다"였습니다. 발신은 신뢰할 수 있는 Amazon Connect로 두고, 트리거는 별도 API 대신 이메일을 택했습니다. 모든 모니터링 솔루션이 이메일을 보낼 수 있으니 CloudWatch·Datadog 어디서든 알람을 쏠 수 있어 범용성이 확보됩니다. 수신자는 DB 없이 그룹메일로 관리해 운영을 간단히 했습니다. 전체가 서버리스로 구성됩니다.

CloudWatch / Datadog / Slack
        │ (임계치 트리거, 이메일 발송)
     그룹메일
        │
   Amazon SES
        │ (이메일 원문 그대로)
   SNS → SQS
        │
     Lambda  ── Amazon Connect (전화 발신)
              └ AWS End User Messaging (SMS 발송)

라우팅은 RFC 5233 플러스 어드레싱으로 풀었습니다. id+01012345678@domain처럼 + 뒤 태그는 수신에 영향을 주지 않는 표준 기능이라, 여기에 전화번호를 넣어 "이 알람을 누구에게 보낼지"를 이메일 주소만으로 지정했습니다. 이메일 제목이 곧 장애 내용이고, 전화를 받으면 그 제목이 TTS로 재생됩니다.

POC에서는 두 가지를 겪었습니다. 비공개 그룹메일인데 스팸메일이 무작위로 날아와 트리거된 적이 있어, 모니터링 툴이 보낸 메일만 파싱하는 방어 로직을 Lambda에 추가했습니다. 또 StartOutboundVoiceContact API가 인스턴스 생성 시 초당 1회가 기본이라 50명 대량 발신에서 일부만 전화가 갔습니다. 한도를 5회로 증설한 뒤 실측해 4회로 고정(Lambda 동시 실행 4)했고, 46명 발신이 120초에서 17초로 약 90% 줄었습니다. 다만 Connect는 서버리스라도 실제 발신은 통신사 인프라를 쓰므로 한도를 무한정 늘릴 수는 없습니다.

전화와 SMS를 이중화해 기록성·가독성을 확보했고(회의·이동 중 못 받아도 내용 파악), 1년 넘는 운영에서 발신 실패율 0%를 기록했습니다. 발신 성공까지 로깅해 "전화가 잘 도달한다"를 증명했고(이관 계기 자체가 발신 실패였으니까), SRE팀이 만든 것을 사내 모든 개발자가 쓰도록 IDP에 셀프서비스 가이드를 정리했습니다.

2부 — 플랫폼 엔지니어링으로 모니터링·운영 고도화

당근은 공통 서비스 개발팀이 사내 플랫폼을 운영하는데, 지표가 산재하고 장애 시 수동으로 확인·조치해야 한다는 한계가 있었습니다. 두 축으로 풀었습니다.

먼저 CloudFront 중심의 가시성 확보입니다. 대상은 사내 이미지 플랫폼이고, 다운로드 경로는 WAF → CloudFront → Lambda@Edge(리사이징) → S3, 업로드 경로는 API 서버 → DynamoDB/ElastiCache + S3입니다. 레이어별로 WAF 차단, CloudFront 캐시 적중률·응답시간, Lambda@Edge 리사이징 정상 여부, DynamoDB 읽기 스로틀링, ElastiCache 히트율·eviction 등을 지표로 정의했습니다. 환경(dev/prod) × 4개 국가의 곱집합으로 리소스가 8~24개까지 늘어나는 문제는 Grafana에서 환경·리전을 변수로 선언해 리소스를 자동 파생시켜 풀었습니다. 변수만 바꾸면 대시보드가 갱신되므로 중복 대시보드를 없애는 게 유지보수의 핵심이었습니다. 알람도 순간 스파이크는 무시하고 지속될 때만 트리거하도록, 환경·지역별로 다른 임계치를 두도록 튜닝했고, 구축 후 방치하지 않고 매주 점검했습니다.

운영 개선의 핵심은 MSK 셀프서비스화였습니다. 규모는 1200개 이상의 토픽, 4000개 이상의 파티션, 멀티 클러스터, 초당 최대 40만 메시지였습니다. 병목은 컨슈머 Lag 알람이 공통팀 한 곳에 집중(월 40건 이상)된다는 점이었습니다. 공통팀이 약 2분간 확인하고 담당 조직을 찾아 전파하면 서비스팀이 처음 조치하기까지 약 8분이 걸렸습니다. 이를 카프카 셀프서비스 플랫폼 "카라반(Karavan)"으로 풀었습니다. 토픽·컨슈머그룹의 오너십(담당 조직, 사내 메신저 멘션)을 구조화하고, 서비스팀이 직접 Lag 임계치를 설정해 알람을 받게 하니 확인·조치까지 1분 미만으로 줄었습니다. 다만 Apache Beam·StarRocks처럼 오프셋을 수동 관리하는 컨슈머는 Lag가 0과 수천을 오가며 비정상으로 보여 알람 조정이 필요했고, 같은 토픽도 지역별 사용 패턴이 달라 임계치를 달리 설계해야 했습니다.

그 결과 플랫폼 조직의 역할이 "지표 수집 → 대시보드 → 알람 확인 → 오너 찾아 전달"에서 "임계치 설계 + 오너십 메타데이터 구조화 + 셀프서비스·가드레일 제공"으로 바뀌었습니다.

개발자 관점 적용 포인트

• 온콜은 비싸고 복잡할 필요가 없다. 이메일을 트리거로 쓰면 모든 모니터링 툴과 즉시 연동되고, SES → SNS → SQS → Lambda → Connect로 서버리스 + 사용량 과금이 됩니다. 라우팅을 주소에 인코딩하는 플러스 어드레싱은 바로 응용할 수 있습니다.
• "서버리스 = 무한 확장"이 아니다. 외부 인프라(통신사)에 닿는 API는 rate limit이 현실 제약입니다. 대량 발신은 동시 실행 수로 흐름을 제어합니다.
• 알람 라우팅 병목은 셀프서비스로 푼다. 플랫폼팀이 모든 알람의 중계자가 되면 그게 곧 병목입니다. 오너십 메타데이터와 셀프서비스 설정으로 위임하면 대응 시간이 8분에서 1분으로 줄었습니다.
• 대시보드는 변수화하고 매주 손본다. 환경×리전 곱집합을 Grafana 변수로 다루면 중복이 사라지고, 임계치·알람은 운영하며 계속 조정해야 살아 있는 모니터링이 됩니다.

4. 마무리

주제는 달랐지만 세 세션이 같은 이야기를 하고 있었습니다. AI든 운영이든, 도구를 도입했다는 사실이 아니라 일하는 방식을 어떻게 설계했는지가 성과를 가릅니다.

• AI-DLC는 자율성을 통째로 넘기지 않고 단계마다 사람의 승인을 끼워 넣었습니다.
• 에이전틱 AI 사례는 자율성 수준 자체를 비즈니스 맥락에 맞춰 고르는 것을 설계로 봤습니다.
• 온콜·모니터링 사례는 가장 단순한 구조를 택하고, 운영을 셀프서비스로 위임할 때 확장된다는 점을 보여줬습니다.