# AWS summit 2026 회고
## IND225: 삼성전자의 에이전틱 AI 전략-개발혁신과 AIOps 여정
삼성전자는 AI Ops의 핵심을 자동화가 아닌, 사람이 빠르게 판단하기 위해 필요한 정보를 AI가 빠르고 읽기 쉬윕게 모아주는 것.
삼성전자 발표에서 AI Ops 관점에서 크게 네가지를 제시했습니다.
### 운영 규모보다 운영 복잡성
21억명의 사용자, 60여 개의 서비스, 수십억개의 기기, 여러 글로벌 리전, EKS, Aurora DB, DynamoDB 등 복잡한 운영 환경을 가지고 있는데, 이는 단순히 "큰 시스템"이 아니라, **여러 서비스와 데이터 흐름이 동시에 얽혀있는 환경에서 장애 원인을 사람이 즉시 파악하기 힘들다는 점**입니다.
AI Ops는 AI 모델을 붙이는 것보다는, 흩어진 운영 데이터를 서로 연결하는 것입니다.
### AI Ops 에이전트의 역할 정의
삼전은 AI Ops 에이전트를 운영 도메인 담당으로 지정하고, 메트릭과 로그를 교차 분석하도록 합니다. 시큐리티 에이전트는 WAF 로그를 Text to SQL로 질의, 분석하여 공격을 탐지하고 보고 하도록 했습니다.
* 운영 에이전트: 메트릭 로그 기반 장애 원인 분석
* 보안 에이전트: WAF 로그 기반 공격 탐지 및 보고
* 변경 분석 에이전트: IaC 변경 영향도 분석
* 리뷰 자동화 에이전트: 아키텍처 리뷰 체크리스트 점검
### 데이터 구분
삼전은 AI Ops에게 제공하는 데이터를 세 가지로 구분합니다.
* 기준 데이터: 체크리스트, 보안 정책, 표준 가이드(AI가 지키는 규칙 및 guardrail)
* 상태 데이터: 로그, 매트릭, 알람 (현재 상황 파악 용)
* 지식 데이터: 장애 히스토리, 운영 메뉴얼, 위키, 과거 사례 (원인과 대응 방안 도출)
여기서 중요한건 암묵지를 문서화하는 것. 표면적인 데이터뿐만 아니라, 내부 사정까지 이해하기 위함.
### Human-in-the-loop
AI는 원인 후보 탐색, 변경 영향도 분석, 리포트 생성의 역할을 수행하지만, 결국 책임은 사람이 집니다. 그러면 결국 사람이 판단할 수 있도록 정보를 충분히 쉽게 제공하는 구조가 중요합니다.
* AI가 상황을 요약
* AI가 원인 후보를 정렬(우선순위)
* AI가 근거(메트릭 등)을 함께 제시
* 사람이 승인하면 후속 작업이 자동으로 진행.(재처리, 알림, 티켓 생성 등)
결국 **사람이 판단하는데 걸리는 시간을 단축하는데 목표**를 가집니다.
### 적용하기
#### 운영
"운영 자동화"가 아니라, 에이전트별 책임을 작게 나눌 수 있을 것 같습니다. (운영 사업엔 현실적으로 어렵겠지만.. 가능하다는 가정)
* 로그 분석 에이전트: 대량 로그에서 이상 패턴 **요약**
* 장애 원인 분석 에이전트: 에러율, 인프라 상태 등을 연결하여 원인 후보 제시
* 탐지 룰 검토 에이전트: Sigma Rule, STIX, 내부 탐지 정책과 실제 로그의 적합성 검토
* 백오피스 운영 에이전트: 관리자 액션, 실패 작업, 재처리 대상, 사용자 문의를 요약
* 변경 영향도 분석 에이전트: 배포 전후 변경 사항 수집 파이프라인, DB, API, 탐지 로직이 미치는 영향 분석.
#### 개발
코드 작성에 있어서 변경 영향도 분석(특정 변경이 프로덕션에 어떤 영향을 줄 수 있는지 AI가 사전에 분석)
* DB 스키마/아키텍처 변경
* 백오피스 관리자 기능 변경
* 외부 연동 API 변경
* 인프라 설정 변경
PR이 생성됬을때 AI가 답할 수 있는 질문들:
* 이 변경이 어떤 서비스, 테이블, API에 영향을 주는가?
* 장애가 발생한다면 어떤 것들이, 어떻게, 무엇으로 인해 나타날 가능성이 높은가?
* 롤백이 가능한가?
* 기존 운영/보안 정책과 충돌하지 않는가?
* 테스트가 충분히 됐는가?
* 장애 발생시 가시성이 확보되었는가?
#### 데이터
AI가 잘 동작하기 위해서는 좋은 데이터가 있어야하고, AI가 이해하기 쉬운 markdown / yaml 형태가 적합합니다.
* 과거 장애 보고서
* 장애 조치 History
* 재발 방지 대책
* 운영 메뉴얼
* 특이사항
* 오탐 / 미탐 사례
* 운영 문의/대응 History
## PRT219-S: 에이전트의 진화 (sponsored by Anthropic)
**"AI를 도입했을때 나의 역할이 바뀌었다면 성공적인 AX 전환이 되었다."**
과거 소프트웨어는 도구에 불가했지만, 현 시대에서는 소프트웨어를 "동료" 처럼 사용하고 있습니다.
질의응답만 가능했던 과거와 다르게, 현재는 Plan, Act, Reflect 사이클을 돌면서 하나의 작업을 완료하는 Agent의 등장으로 LLM은 이제 동료가 되었습니다.
그러면동료가 된 시점에서 우리는 어떤것들을 준비해야하나?
발표에서 강조하는 핵심은 "Claude가 코드를 잘 짠다" 또는 "Cluade Code 같은 좋은 도구가 나왔다" 가 아니라, 이러한 도구로 인해서 사람의 역할이 바뀌었다는 점을 강조했습니다.
한 회사의 예시를 드는데, 이 A회사는 개발 생산성을 높이기 위해 AI를 도입했지만 사람의 역할은 그대로였습니다.\
개발자는 여전히 코드를 작성하고, AI는 함수 작성이나 리팩토링 같은 일부 작업을 제안하는 보조 역할을 맡았습니다.
이 방식은 생산성에 도움이되지만, 자세히 들여다보면 기존 업무 방식 위에 AI를 덧붙인 형태입니다.
* 사람 -> 코드를 작성.
* AI -> 코드를 조금 더 잘 쓰게 도와주는 도구
다른 B회사는 조금 다르게 적용시켰습니다.
* **사람 -> 방향을 수립, 결과를 검토, 판단**
* **AI -> 코드를 작성.**
사람을 작성자가 아닌 설계자 & 검토자로 역할이 바뀌었습니다. 결국 이 차이가 AX 전환의 성공 여부를 판단하는 핵심이라는 메시지를 전달합니다.
### **“AI 도입 이후, 나의 역할은 실제로 바뀌었는가?”**
예전 같았다면 “아직 그렇지 않은 상황이 더 많다”고 답했을 것 같습니다.\
AI를 사용하고는 있지만, 저는 여전히 요구사항을 파악하고, API를 설계하고, 코드를 작성하고, 테스트하고, 운영 중 발생하는 문제를 확인하고 있었습니다. AI는 제가 작성한 코드를 개선하거나, 막힌 부분을 설명해주거나, 더 나은 구현 방식을 제안하는 보조 도구에 가까웠습니다.
* 나: 개발을 한다.
* AI: 내가 개발을 더 잘할 수 있게 도와준다.
하지만 최근 회사 업무를 기준으로 보면, 다릅니다.
현재 저는 1인 프로젝트를 인수인계받고 있고, 동시에 리팩토링을 진행하고 있습니다. \
이 상황에서는 단순히 코드를 수정하는 것보다 먼저 프로젝트를 이해하는 일이 중요합니다. 전체 구조가 어떻게 되어 있는지, 각 디렉터리와 파일이 어떤 책임을 가지고 있는지, 요청이 들어왔을 때 어떤 흐름으로 처리되는지, 핵심 비즈니스 로직이 어디에 있는지 파악해야 합니다. 또한 외부 시스템이나 DB와 강하게 연결된 부분, 수정하면 위험한 코드와 비교적 안전하게 정리할 수 있는 코드도 구분해야 합니다.
과거였다면 이 과정을 대부분 직접 했을 것입니다.\
파일을 하나씩 열어보고, 호출 관계를 따라가고, 흐름을 메모하면서 프로젝트를 이해했을 것입니다.
하지만 지금은 이 과정에서 AI에게 꽤 많은 역할을 넘기고 있습니다.
* 이 프로젝트의 전체 구조를 설명해줘.
* 각 메서드안의 역할들을 요약해줘.
* 요청 흐름을 추적해줘.
* 수정하면 위험한 코드와 안전하게 정리할 수 있는 코드를 구분해줘.
* 현재 코드가 프론트 프로젝트의 구조를 바꾸지 않고도 문제가 없는지 검토해줘.
제 역할도 바뀌고 있습니다.
AI: 프로젝트 구조를 요약하고, 코드 흐름을 추적하고, 리팩토링 후보를 제안한다.\
나: 설명이 실제 코드와 맞는지 검토하고, 위험도를 판단하고, 최종 변경 여부를 결정한다.
물론 AI에게 바로 “이 코드 리팩토링해줘”라고 맡기는 것은 위험합니다.\
인수인계받는 프로젝트에는 문서화되지 않은 비즈니스 규칙이나, 특정 운영 이슈를 피하기 위한 방어 코드가 숨어 있을 수 있기 때문입니다.
그래서 AI는 이해와 정리를 도와주지만, 최종 판단과 책임은 여전히 사람이 가져야 합니다.
결국 제 업무에서도 역할 변화가 조금씩 일어나고 있습니다.\
AI에게 구조 파악, 흐름 정리, 리팩토링 후보 탐색을 맡기고, 저는 그 결과를 검토하고 판단하며 책임지는 역할로 이동하고 있습니다.
이 발표를 바탕으로 제가 일하는 방식이 올바른 방향으로 흘러가고 있다는 점에 있어서 도움이 많이 되었던 것 같습니다.
## IND303: LG U+의 에이전틱 AI 기반 대규모 마이그레이션 여정
LG유플러스는 100개 이상의 온프레미스 애플리케이션을 운영하고 있었는데, 서비스마다 인프라·로그·보안·운영 방식이 모두 따로 관리되고 있었습니다. 개발 또한 여러 외주사 중심으로 진행되다 보니 기술 스택과 코드 품질, 운영 방식이 제각각이었고,
그 결과 아래 문제들이 발생:
* 통합 모니터링이 어렵고
* 보안 정책 적용이 느리며
* AI 같은 신기술 도입 속도가 떨어지는 구조적 문제
이번 프로젝트의 핵심 목표는 단순히 “클라우드로 옮기는 것”이 아니라, AI 기반 혁신이 가능한 운영 구조 자체를 만드는 것이었습니다.
LG유플러스는 마이그레이션 과정을 4단계로 나누고, 단계별로 AI 에이전트를 붙여 자동화·표준화하는 방식을 선택했습니다.
### 1. Assessment 단계
"현재 시스템을 AI가 이해해야 한다."\
현재 시스템을 이해하기 위해서는 기존 시스템에 대한 이해도가 높아야하는데, 아래 문제점들이 있음
* 문서가 오래됨
* 최신 변경사항이 반영이 안됨
* 실제 운영 지식 또는 결정들은 사람들의 머릿속에만 존재
이를 해결하기 위해 3가지를 동시에 진행.
1. 산출물 분석: \
산출물(설계 문서, 운영 문서, 아키텍처 문서, 형상관리 자료)을 통해 애플리케이션 구조, 서비스 간 의존성, 전환 영향도 분석
2. 인터뷰 기반 분석:\
운영 담당자, 개발자, 외주사와의 인터뷰 내용을 AI가 정리 분석하여, 실제 운영 흐름, 장애 포인트, 숨겨진 의존성, 특정 배치나 스케줄링 로직을 추출.
3. 소스코드 분석:\
실제 코드를 읽고 실제 호출 관계, DB 의존성, 라이브러리 사용 패턴, 레거시 프레임워크 여부, 리팩토링 난이도를 파악.
### 2. Design 단계
"AI가 목표 구조와 리팩토링 포인트를 설계한다"
Assessment 바탕으로 아래를 정의:
* 어떤 구조를 바꾸고
* 무엇을 수정
결과값으로는
* 목표 아키텍처
* 리팩토링 항목
* 수정 우선순위 를 도출
### 3. Migration 단계
"실제 변환 작업에도 AI를 사용한다"
AI는 이 시스템은 어떤 문제 떄문에 수정해야 하는가, 운영 환경에서 어떤 제약이 있는가 등 넓은 범위를 고려한 형태로 접근.
* 코드 변환
* 설정 수정
* 환경 변경
* 인프라 구성 변경
같은 반복 작업을 지원하여 대규모 애플리케이션을 동시에 빠르게 전환하려 함.
### 4. Scale-out 단계
"한 번 만든 패턴을 계속 재사용한다"
대규모 마이그레이션에 필요한 건, 하나보다 100개를 반복 가능한 구조가 중요함.
* 반복적으로 등장하는 문제
* 공통 리팩토링 패턴
* 자주 발생하는 변환 방식
을 재사용 가능한 형태로 표준화.
예를 들어,
* 특정 프레임워크 변환 패턴
* 공통 인증 처리 방식
* 로그 구조 변경 방식
* 배포 구조 변경 패턴
등을 템플릿화하여 애플리케이션에 적용하는 구조를 만듬.
결국 AI를 코드 생성하는 도구가 아닌, 대규모 전환 방법론 자체를 표준화하는 엔진처럼 사용.
이 발표를 들었을 때, 단순히 “대기업의 클라우드 마이그레이션 사례”라기보다는, 현재 제가 하고 있는 통일되지 않은 프로젝트 리팩토링에도 거의 동일한 접근을 적용할 수 있겠다는 생각이 들었습니다.
실제로 레거시 프로젝트들은 문제를 가지고 있습니다.
* 문서는 최신 상태가 아니고
* 실제 구조는 코드 안에만 존재하며
* 중요한 운영 지식은 특정 담당자의 경험에 의존하고
* 서비스마다 구조와 스타일이 달라 일관성이 없습니다.
결국 리팩토링 이전에 가장 먼저 필요한 건 “현재 시스템을 이해하는 과정”인데, 이 과정 자체가 가장 많은 시간을 소모합니다.
그럼 앞으로 어떻게 바꿔가야 할까?
## 1. AI에게 먼저 “구조 이해”를 맡기기
“코드를 작성하기 전에 AI로 시스템을 먼저 모델링하는 단계”
이제 AI는 단순 코드 자동완성보다:
* 구조 요약
* 호출 흐름 추적
* 의존성 분석
* 리스크 탐지\
같은 영역에서 훨씬 강력해지고 있습니다.
예를 들어 지금처럼:
* 이 프로젝트의 전체 구조를 설명해줘.
* 핵심 비즈니스 로직이 어디 있는지 찾아줘.
* 수정 위험도가 높은 영역을 구분해줘.
같은 질문들을 반복적으로 던지면서:
* 프로젝트 구조 문서
* 리팩토링 가이드
* 위험 영역 맵\
을 계속 축적하는 방식이 앞으로 매우 중요해질 것 같습니다.
## 2. 리팩토링을 “패턴화”하기
“내가 변경 패턴을 얼마나 시스템화할 수 있는가”
발표에서 가장 중요했던 건 Scale-out 단계였습니다.\
“반복 가능한 방식으로 계속 수정할 수 있는가” 중요한데,
예를 들어 앞으로는:
* API 구조 표준화
* 예외 처리 방식 통일
* 로깅 방식 통일
* DB 접근 패턴 정리
* DTO 규칙 통일
* 인증 처리 공통화
같은 것들을 하나씩 패턴으로 만들어야 합니다.
그리고 이걸 템플릿으로 축적하면, 다음 리팩토링 속도가 급격히 빨라질 수 있습니다.
결국 앞으로는:\
“혼자 모든 코드를 직접 작성하는 개발자” 보다는,
AI를 활용해:
* 복잡한 시스템을 빠르게 이해하고
* 변경 방향을 설계하고
* 반복 가능한 구조로 정리하는 사람
의 생산성이 훨씬 높아질 가능성이 크다고 느꼈습니다.
그리고 지금처럼:
* 인수인계를 받으면서
* 구조를 파악하고
* 리팩토링 포인트를 정리하고
* AI에게 지속적으로 프로젝트를 설명시키는 경험 자체가
오히려 앞으로 중요한 훈련이 될 수도 있다는 생각이 들었습니다.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://wonjoon.gitbook.io/joons-til/reviews/aws-summit-2026.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.