Day 1은 기업들의 사례 소개 위주, Day2는 기술 소개 위주
코엑스, Keyword : 하단 세션 카테고리
09:30 ~ 3F D Hall 기조연설 - 참여한 카테고리/세션만 색상 강조 (상세 일정은 위 pdf 참조)
생성형 AI 및 기계 학습 3F |
비즈니스 기술 1F 102~4 |
운영 및 보안 4F 401 |
고급 아키텍처 1F 101 |
클라우드 신기술 1F 105 |
커뮤니티 2F 201 |
|
11:10 ~ 11:50 |
11:10 ~ 11:50 개발의 미래: AWS AI 도구로 시간 절약하기 |
리더를 위한 생성형 AI 전략 6가지: 과거에서 배우고 미래를 설계하기 |
AWS로 실현하는 철저한 보안 전략 | 생성형 AI 로 AWS Step Functions 워크플로우 레벨업하기! |
Amazon.com의 생성형 AI와 파운데이션 모델을 이용한 혁신 사례 | 플랫폼 엔지니어링 기반 개발자 생산성 극대화 |
13:10 13:50 |
데이터 인사이트의 혁신: Amazon AI 서비스 활용법 | AI Everywhere: Intel과 AWS 상에서 구축하는 실행 가능하며 책임감 있는 AI 솔루션 |
AWS에서의 안전한 생성형 AI 구축 전략 | AWS에서 분산 디자인 패턴 구현하기 -> 데이터분석 "AWS 벡터 데이터베이스의 벡터데이터 사용 모범사례" 대체 |
데이터기반 의사결정을 위한 AI를 활용한 ESG Report 생성하기 | AWS 네트워크 아키텍처 최적화와 IPv6 활용 전략 |
14:20 ~ 14:50 |
다양한 측면에서 보는 Observability | From Code to Cloud in the era of AI | 데이터베이스 보안의 미래를 위한 접근제어시스템의 혁신과 패러다임 전환 | 하시코프, 클라우드 시크릿의 보안 생명주기를 한 곳에서 한 번에 관리하기 | 클라우드 보안의 새로운 패러다임 | 크라우드스트라이크가 생각하는 클라우드 환경의 워크로드 보호 방안 소개 |
15:20 ~ 16:00 |
Amazon Bedrock을 활용한 프롬프트 엔지니어링 모범사례 | Amazon Bedrock Agent: 생성형 AI 개발의 게임 체인저\ | Amazon OpenSearch Ingestion과 AI 를 활용한 옵저버빌리티 강화 방안 -> 데이터분석 "Amazon OpenSearch 서비스의 벡터 기반 RAG 구축을 통한 생성형 AI 검색 성능 향상" 대체 |
SaaS와 AI/ML & 생성형 AI의 만남: 멀티 테넌트 패턴 및 전략 | Gen AI와 AWS IoT로 개척하는 비즈니스 혁신 | Serverless 활용: 스타트업의 효율적 개발 환경 구축 |
16:30 ~ 17:00 |
DeepSpeed을 활용한 Fine-tuning 및 OpsNow Insight 구축 사례 | AWS 서비스들을 활용하여 데이터레이크 쉽게 구축하기 | Red Hat과 AWS: ROSA를 통한 AI비즈니스 혁신 | Imply Druid를 활용한 실시간 데이터 분석과 당근마켓 사례 | Unlocking AI : 실시간 생성형 AI Apps을 가능하게 하는 SingleStoreDB 활용 사례 |
|
17:20 ~ 18:00 |
Amazon SageMaker Canvas의 새로운 LLM 기능으로 생성형 AI 활용하기 | RAG를 사용하여 생성형 AI 애플리케이션의 응답 품질 높이기 |
클라우드 거버넌스 성공 가이드: 모범 사례와 인사이트 |
Guardrails for Amazon Bedrock: AI 애플리케이션에 책임감 심어주기 | AWS IoT를 통한 산업 혁신 전략 및 IoT기반 Generative AI를 활용한 서비스 확장 | DORA와 Amazon Bedrock을 이용한 업무문화 혁신 사례 |
09:30 ~ 10:35 keynote session
AWS - 윤석찬 테크 어반젤리스트
(1) Frugal Architecture
(2) Platform Engineering
DevOps -> SRE -> Platform Engineering
Posco, 당근, 무신사 등
(3) Generative AI
vernal - CTO
1. 비용을 규정 준수와 같은 비기능적 요인 중 하나로 삼아야 한다.
2. 비즈니스에 비용을 맞춘다 - 아키텍쳐의 결정은 비즈니스에 따라야 한다.
firecracker -
cost optimization hub - stop, reduce, rightsize, shift, Throttle,
Application Signals
my Application - app 별 비용/성능 모니터
3. 아키텍트는 타협(trade-off)의 연속이다.
4. 측정되지 않은 시스템은 예상치 못한 비용을 만든다.
5. 비용 인식 아키텍처를 통해 비용 통제를 구현하라.
마이크로 서비스 아키텍쳐 + 서비스 티어
6. 비용 최적화 과정은 누적되어야 한다.
7. 도전 없는 성공은 안주하는 경향이 있다.
Rust 언어 SDK를 제공하고 있다. 친환경적 언어에도 관심을 가져볼 것
비용 절감 사례 : 인프랩 - 이동욱 CTO (개발바닥 유튜브 운영)
1. RDS 비용 - 리소스 절감
2. EC2의 turn on/off, Reserved
비즈니스에 비용을 맞춘다 : 스타트업 같은 경우 특히 더 고려해야 한다.
Cloud Front RC - 트래픽 량에 대한 할인율 적용
Test 환경에는 작은 인스턴스를 구성하고 RI 계약을 고려해야 한다.
platform 엔지니어링 사례 : 카카오페이증권 - 조지훈 Platform 실장
사용자의 관점에서 비즈니스를 기획하는 것에 고민중.
투명화, 자동화에 관점을 두던 DevOps
-> User 입장에서의 개발이 가능한 환경에 초점 platform Engineering
쿠버네티스 기반 업무들을 해왔음.
Scale up/down을 자동화하는 단계 - 금융 이벤트가 발생하면 그 상황에 따른 자동화된 조정
플랫폼팀이라면 개발팀(내부 고객)과의 소통/협업을 중요시 해야 한다. 이것도 마찬가지로 사용자 중심 관점이다.
작은 영역부터 자동화를 시작해야 한다.
Generative AI 사례 : Mett wood 부사장
(1) 인프라 - 칩, EFA
(2) 작업에 맞는 모델을 활용해야 하고, 주변 서비스들과의 시너지가 중요하다 (RAG, Q)
(3) 보안 중시 / 혁신 / 스케일 관리
(4) Bedrock, Partirock
Partirock : 생성형 AI 놀이터 - no code
Q Business : RAG 서비스
-> Admin Console : RAG 소스 추가 도구 - 40가지 소스 제공 중
Q apps : 직원들이 직접 개발한 앱을 공유하는 플랫폼
Bedrock : 모델선택, 에이전트, 지식 기반, 가드레일, 모델평가, 파인튜닝
-> bedrock studio : opensearch에 vector db 구현
Q developer : 기획 - 설계 - 코드 구현 - 테스트(디버깅 지원) - 배포 - 개선, 전 단계 모두 보조 도구들을 지원
Generative AI 사례 : 우정진 센드버드 CTO 엔지니어링 팀 운영
11:10 ~ 11:50 생성형 AI 로 AWS Step Functions 워크플로우 레벨업하기! (L200)
- 권지혜 APP Architect - 김학성 APP Developer
** step function 비용 [링크]
01. 환경 분석 및 구축 방법
Step Function의 장점
(1) 프로세스의 복구 능력을 위한 상태관리 조율 head 구성
(2) 병렬처리, 출력 값 등의 전달
(3) 재시도, 에러처리
세션 구현 예시 - Serverless Video
동영상에 여러개의 제목과 설명 생성 - Convert video to text / Use FM to generate title
사용자에게 피드백 요청 - get feedback
동영상용 아바타 만들기 - use FM to generate avatar
** Step Function의 step 진행 방식 3가지
(1) Request - Response (2) Job-Run(.sync) (3) Callback
02. Gen AI와의 최적화된 통합
Step Function에서 bedrock을 그대로 연결할 수 있음.
프롬프트는 "$.prompt" 형태로 동적 입력
03. 퍼블릭 HTTPS API와 통합
외부 API와의 결합도 고려할 수 있다.
Call third part API 엑션을 호출 가능
Secetrs manager에서 Fetch credectial / Manage Token등 수행
Amazon States Language
04. Redrive 기능 소개
실패지점부터 다시 시작시키는 방법(call back - token활용)
프롬프트 체이닝에 step function이 효과적일 수 있다.
(코드로 관리하기에 복잡도가 증가할 수 있음으로)
step function UI | Flow chart | |
![]() |
![]() |
13:10 ~13:50 AWS 벡터 데이터베이스의 벡터데이터 사용 모범사례
김지훈 Senior SA, 장동훈 senior SA
(1) 생성형 AI 개요 및 DB역할
- RAG 소스
- 벡터의 사용방법
문서 -> 덩어리(chunk)로 분리 -> Amazon Titan 임베딩 -> Amazon Aurora PostgreSQL - Compatible
- 임베딩의 문제
임베딩은 스케쥴 베이스로 운영된다. (실시간으로 저장되는 개념이 아니다)
아직은 데이터의 크기가 크다. (4byte의 부동 소수점으로 저장, 6152B -> 6KB) - 아직은 효과적인 압축법이 나오지 않은 상태
쿼리 시간 :
- 고려할 점
나의 워크플로우에 벡터 저장소는 어디에 적합한가?
나는 얼마나 많은 데이터를 저장하고 있는가?
스토리지, 성능, 연관성, 비용 중 나에게 중요한 것은 무엇인가? (대용량 데이터의 경우 아키텍쳐가 달라져야 할 수 있다.)
인덱싱, 쿼리 시간, 스키마 디자인 등 장단점은 무엇인가? (어떤 인덱싱 방식을 사용할 것인가?)
(2) 벡터 저장소 Postgre SQL
- pgvector - 오픈 소스 확장 기능 : 추가된 기능
스토리지(벡터 데이터 타입)
** TOAST (The Oversized-Attribute Storage Technique - 2kb이상은 페이지에 저장되지 않고 별도 TOAST에 저장)
테이블 타입
PLAIN : TOAST 시키지 않고 무조건 인라인으로 저장
EXTENDED : 임계값 초과 (기본값)
EXTERNAL :
MAIN : 테이블에 인라인으로 저장
** min_parallel_table_scan_size : 더 많은 병렬 유도 가능
쿼리에 대한 TOAST의 영향 : 실행계획을 세우는 optimizer는 TOAST 여부를 알지 못한다. TOAST 사용에 주의해야 한다.
테이블을 인라인으로 변경하는 작업들이 반복 실행될 수 있다.
인덱싱(IVFFlat, HNSW 인덱싱 지원)
인덱스를 생성하기 위해서는
m(인덱스된 벡터 간 최대 양방향 링크 수)과
ef_construction(최근접 이웃 군집에서 유지해야할 벡터 수) 2가지 변수를 사용하여 생성함.
인덱스라는 것이 벡터 간의 링크를 의미한다. (어떤 것이 유사한 벡터인지를 묶어주는 개념)
인덱스의 구축은 성능/재현율을 가장 크게 고려한다.
ef_construction을 늘리면 재현율은 올라가지만 성능은 떨어질 수 있다.
HNSW - 근처에 있는 벡터들 간의 양방향 링크를 만들어주는 방법
hnsw.ef_search (Limit보다 크거나 같아야 한다)
다른 인덱스 구축에 있어 보다 많은 선행 작업들을 수행하게 된다.
대신 좀 더 효율적인 검색이 가능하다. (정확도도 높다)
기본 값은 (m=16, ef_construction = 64) : 잘 작동하는 편이다
(두 변수의 크기를 크게 하면 인덱스 생성 기간이 늘어나지만 재현율은 높다)
빈 인덱스로 시작해서 동시 쓰기(병렬처리??)를 활용하는 방식이 가장 빠르게 구현된다
IVFFlat - 중심 벡터를 잡고 연결을 중심 벡터 위주로 구성한다?
lists : 연관된 버킷의 수
set ivfflat.probes to 2 과 같은 설정값을 사용하여 인접한 버킷을 검색할 수 있으나, 레이턴시가 발생한다.
ramdom page cost를 (이미지 참조)
재현율을 최대화하지만 검색 노력을 최소화하려면 적절한 리스트 값을 선택한다. (적정값은 이미지 참조)
병렬성을 사용하여 구축 시간 단축 (벡터를 센터에 할당하는데 가장 시간이 오래 걸리는데 이유는 순차적으로 스캔하기 때문)
Postgre에서 병렬처리할 경우 효율적 (2~4배 정도의 시간 절감이 가능함)
where 조건 절은 ANN쿼리에 영향을 줄 수 있음 (원하지 않는 결과 반환, 인덱스를 활용한 필터링이 발생)
부분 인덱스 필터링
파티션 필터링
pgvector 로드맵
HNSW용 병렬 구축 예정
향상된 인덱스 기반 필터링/HQANN,
디멘젼당 더 많은 데이터 유형(float2,unit8)
프로덕트 양자화 / 스칼라 양자화, 병렬 쿼리
검색(최근접 이웃 탐색, 근사 근접 이웃 탐색)
메타데이터(임베딩하여 공동 배치)
선택(선택 가능한 연산자) 가능한 거리
14:20~14:50 From Code to Cloud in the era of AI
팔로알토 Cloud Security SA 김수영 이사
(1) 팔로알토 네트웍스 플랫폼
prisma cloud and palo alto networks platform
클라우드 보안, AI 보안 솔루션을 운영중
zero trust - 보안 관련 솔루션, code to cloud, autonomous secops
Internet이 23년 Mobile이 13년 AI는 7년이면 사람들이 보편적으로 사용하는 기술이 될 것이다.
SaaS에도 현재의 10배 정도 AI가 도입될 예정
모든 직원의 AI 사용량, 접근에 대하여 데이터를 보호하고
디스커버리, 맥락화(위험 발견의 구조화 - 위협, 앱, 전체 맥락), 리포트, 교정
15:20~16:00 Amazon OpenSearch 서비스의 벡터 기반 RAG 구축 생성형 AI 검색 성능 향상
윤기원 Senior SA
업무 활용 수준의 RAG
KNN, 신경망, 러닝 투 랭크(LTR), 플러그인 지원, Nori 플러그인 - OpenSearch의 검색 방법
- 구조
OpenSearch는 Json으로 전송을 받고 -> 토큰화/정규화 -> 분산 저장(샤드 구조) (인덱스 : 단어와 포함된 문서 번호를 연결)
Lucene 기반으로 검색
발화 -> 어간 추출 -> 포함된 단어 관련 문서 탐색
여러 문서가 조회될 경우, Okapi BM25를 사용한 랭킹 활용하여 반환 -> 숨은의도나 키워드가 명확하지 않은 경우 검색 불가
모닥불 옆에서 편히 쉴 수 있는 도구를 찾아줘? -> 키워드와 의도가 불명확함
Amazon Music, Amazon.com의 지적재산권 침해 탐지에 사용중
이치호 SA
Amazon OpenSearch - bedrock 을 통한 text2answer Demonstration
Open Search의 devtools에 인덱스의 존재 유무를 조회해볼 수 있다.
16:30~17:00 DeepSpeed을 활용한 Fine-tuning 및 OpsNow Insight 구축 사례
[영상 녹화]
17:20~18:00 클라우드 거버넌스 성공 가이드:모범 사례와 인사이트
전명수 SA
비즈니스 목표에 맞게 조정하는데 필요한 규칙, 관행, 보고서의 집합
CCoE - 클라우드 전문가 조직
보안 / 규정준수 / 가시성 향상 - 민첩성 향상 - 혁신 가속화
클라우드 거버넌스 모범 사례 - 계정을 구성요소로 사용 -
성문규 SA
제어관리 모범사례
(1) 거버넌스 프레임워크 보안 제어
정책 식별(높은 수준의 기대치 설정) - 제어 목표(충족 필요 조건 식별) - 표준(공식 요구사항) - 보안 제어(표준에 맞는 안전장치)
(2) 제어 유형
탐지(위반 리소스 탐지) - 예방(위반 행위를 허용하지 않음 - SCP) - 사전 제어(생성 전 규칙에 맞지 않으면 프로비저닝 차단)
(3) 코드형 제어 모델 구축 및 검토 프로세스 구축(organization, config, control tower)
(4) 보안 프레임워크에 맞게 제어 목표 조정 (security hub, config, control tower)
(5) 예방 제어 및 사전 준수
(6) 제어 모니터링 및 테스트 (audit manager - 자동화된 규정 준수 상태 모니터)
(7) 인프라를 코드로 사용해서 일관성과 반복성의 보장(Service Catalog - Terraform, CloudFormation)
(8) 코드의 보안 취약점 사전 탐지 (CodeGuru, CodeWhisperer, CodeCatalyst)
정영진 쏘카 매니저
Control Tower OU 구성 - IAM을 Identity Center로 변경 (점진적 변환 - 84%전환)
OU는 서비스별 구성 + 환경별 구성(Rule과 1:1 맵핑) -> 정책의 중앙집중화
자산 생성부터 자산 목록화까지
자산 생성 -> 태그 강제화, 태그 자동화, 자산 가치화, 자산 목록화
태깅 기준 - 인프라 자산 중 보안 준수 규정에 속하는 자산이거나, 가장 많이 사용하는 자산인 경우
태그 레퍼런스 검토 : 처음에는 19개였지만 점차 9개 정도로 줄임 (담당,생성자,팀명,생성일,환경명,리소스명,OS.목적,개인정보 포함 여부)
'Digital Transformation > Conference' 카테고리의 다른 글
20250618_한경협_AX포럼 (3) | 2025.06.18 |
---|---|
2024/04/30 - [MS] Azure AI Tour (0) | 2024.04.30 |