AWS Unicorn Day Seoul 2026 후기
AI와 함께하는 개발이 AWS와 결합했을 때 어떤 시너지를 만들 수 있는지, 여러 기업과 세션 사례를 통해 확인할 수 있었습니다.
이번 글에서는 제가 들었던 세션에서 인상 깊었던 내용과 함께, 세션 중 언급된 주요 용어와 개념을 정리해보려고 합니다. 현장에서 간략히 메모한 내용을 바탕으로 복기한 것이기 때문에, 일부 표현이나 세부 내용은 실제 발표와 다소 차이가 있을 수 있습니다.
데이터팀 부담을 줄이는 Text2SQL 구현부터 운영 팁 대방출
손회연 솔루션즈 아키텍트, 박서영 솔루션즈 아키텍트 (AWS)
비즈니스 현장에서 데이터 기반 의사결정의 중요성이 커지고 있지만, SQL을 모르는 구성원이 데이터에 직접 접근하기는 여전히 어렵습니다. 본 세션에서는 스타트업 환경에서 LLM, 프롬프트 엔지니어링, RAG를 활용해 Text2SQL을 빠르게 구현하는 방법을 다루고 실제 서비스에서 정확도를 끌어올리기 위한 실전 노하우를 공유합니다.
Text2SQL 구현 및 운영 팁
Text2SQL을 운영할 때는 단순히 자연어를 SQL로 변환하는 기능 자체보다, 사용자가 원하는 결과를 안정적으로 얻을 수 있도록 제약 조건과 운영 지표를 함께 설계하는 것이 중요해 보였습니다.
-
Multi-turn 질의에서는 제약을 명확히 정의해야 합니다.
사용자가 여러 번에 걸쳐 질의를 이어가는 경우가 많기 때문에, 이전 대화의 맥락을 어디까지 반영할지, 어떤 테이블과 컬럼을 사용할 수 있는지 명확히 제한해야 합니다. -
Few-shot 예시와 schema pruning을 함께 적용하면 좋습니다.
LLM에 적절한 예시를 제공하고, 질의와 관련성이 낮은 스키마 정보를 제외하면 노이즈를 줄일 수 있습니다. 결과적으로 더 정확하고 일관된 SQL 생성을 기대할 수 있습니다. -
User feedback을 기반으로 A/B 테스트를 진행해야 합니다.
생성된 SQL이 실제 사용자의 의도와 맞는지 확인하려면 사용자 피드백을 수집하고, 프롬프트나 모델 구성의 변경 효과를 실험적으로 비교하는 과정이 필요합니다. -
Dynamic model selection을 고려할 수 있습니다.
모든 질의에 동일한 모델을 사용하는 대신, 질의 난이도나 비용, 응답 시간 요구사항에 따라 적절한 모델을 선택하는 방식입니다.
성능을 파악하기 위한 observability 지표로는 응답 시간, 세션당 평균 턴 수, SQL 생성 성공률, 사용자 피드백 결과 등을 활용할 수 있습니다. AWS 환경에서는 Amazon Bedrock과 Amazon CloudWatch를 함께 사용해 모델 호출 및 애플리케이션 운영 지표를 관찰할 수 있습니다.
용어 정리
-
Schema pruning
전체 데이터베이스 스키마 중 현재 질문과 관련성이 높은 테이블, 컬럼, 관계만 선별해 LLM에 전달하는 방식입니다. 불필요한 스키마 정보가 줄어들면 모델이 엉뚱한 테이블을 참조하거나 잘못된 조인을 생성할 가능성을 낮출 수 있습니다. -
Dynamic model selection
요청의 복잡도, 비용, 지연 시간, 정확도 요구사항에 따라 사용할 모델을 동적으로 선택하는 전략입니다. 간단한 질의는 비용이 낮고 빠른 모델로 처리하고, 복잡한 분석 질의는 더 성능이 높은 모델로 처리하는 식으로 운영할 수 있습니다.
우리 서비스의 데이터로 온톨로지 구축해보기
박진우 솔루션즈 아키텍트 (AWS)
이번 세션에서는 최근 많은 고객이 고민하는 온톨로지에 대해 함께 살펴보고, AWS에서 온톨로지를 구성하는 방법을 알아봅니다. AWS의 Agentic AI 서비스와 Neptune, RDB, Analytics 서비스를 활용해 데이터를 그래프화하고, 기존 정형/비정형 데이터를 온톨로지에 추가하는 방법을 다룹니다. 또한 Agent를 활용해 데이터 사일로를 제거하고 서비스, 기획, 마케팅에서 활용하는 방안을 제시합니다.
LLM을 적용하면서도 기존 데이터베이스의 자산을 효과적으로 활용하려면 어떤 접근이 좋을까요? 이 세션에서는 그 답 중 하나로 온톨로지와 그래프 기반 데이터 활용을 다뤘습니다.
온톨로지는 특정 도메인 안에서 사용되는 개념, 구성 요소, 관계, 조건, 개체를 명시적으로 정의하는 방법입니다. 지식 그래프나 Semantic Web과도 밀접하게 연결되어 있습니다.
핵심 사용 사례는 흩어진 데이터를 통합하고, 데이터 간 관계를 바탕으로 암시적인 정보를 추론하며, 사용자의 의도를 더 잘 파악하는 데 있습니다. 예를 들어 물류 시스템을 관리한다면 디지털 트윈을 구현해 다양한 시나리오를 실험하고, 이를 바탕으로 새로운 프로세스를 제안할 수 있습니다.
다만 데이터 통합에는 현실적인 장벽이 존재합니다. “모든 데이터를 한곳에 올려두고 AI에게 물어보면 되지 않을까?”라고 생각하기 쉽지만, 실제로는 ‘모든 데이터를 다 올린다’는 것 자체가 매우 어렵습니다.
대표적인 이유는 다음과 같습니다.
-
Tacit knowledge, 즉 암묵지가 존재합니다.
개인의 경험, 노하우, 직관처럼 문서나 시스템으로 명확히 정리되지 않은 지식은 데이터화하기 어렵습니다. -
Data silo가 존재합니다.
팀마다 다른 포맷, 다른 저장소, 다른 용어를 사용할 수 있습니다. 심지어 같은 ‘유저’라는 단어도 서로 다른 의미로 사용될 수 있습니다.
따라서 온톨로지는 모든 데이터를 무작정 통합하는 방식이 아니라, 비즈니스 목적을 중심으로 필요한 데이터부터 선별해 구축하는 방식이 적합합니다. 최종 의사결정 역시 개별 데이터만 볼 것이 아니라, 전체 맥락을 함께 고려해야 합니다.
온톨로지에 어떤 데이터를 포함할지는 다음과 같은 질문을 통해 정리할 수 있습니다.
- 해결하려는 목적은 무엇인가요?
- 해당 목적에 필요한 데이터가 실제로 존재하나요?
- 데이터는 어떤 방식으로 수집되고 적재되나요?
- 데이터는 현재 어떻게 사용되고 있나요?
AWS 환경에서 온톨로지를 구현하는 방법 중 하나로는 오픈소스 SDK인 Strands Agents와 AWS의 그래프 데이터베이스인 Amazon Neptune을 함께 활용하는 접근이 소개되었습니다. 이 방식은 에이전트가 자연어 질의를 받아 그래프 데이터베이스 질의로 변환하고, 그래프 관계를 탐색한 결과를 다시 사용자에게 설명하는 형태로 확장할 수 있습니다.
또한 Amazon Redshift의 Zero-ETL 통합은 운영 데이터베이스의 데이터를 분석 환경으로 더 쉽게 연결해, 분석·AI/ML·리포팅에 더 신선한 데이터를 활용할 수 있도록 돕습니다. 다만 Zero-ETL이 모든 데이터 변환 과정을 없애거나, 데이터베이스를 곧바로 LLM이 완벽하게 이해하도록 만들어주는 것은 아닙니다. 데이터 모델링, 권한, 품질 관리, 비즈니스 용어 정리는 여전히 별도로 설계해야 합니다.
기업의 온톨로지를 구현할 때 반드시 그래프 DB를 사용해야 하는지도 신중히 판단해야 합니다. 예를 들어 여행 정보는 항공, 숙박, 관광, 맛집 등 다양한 도메인이 복잡하게 연결되므로 그래프 DB가 적합해 보일 수 있습니다. 반면 실제 서비스 구현에서는 기존 RDB의 조인 구조가 더 쉽고 빠르며 직관적일 수도 있습니다.
결국 중요한 것은 “그래프 DB를 써야 하는가?”가 아니라, 해결하려는 문제와 데이터 관계의 복잡도에 비해 그래프 모델이 충분한 가치를 제공하는가라고 느꼈습니다.
용어 정리
-
OWL(Web Ontology Language)
웹에서 온톨로지를 표현하기 위해 사용하는 표준 언어입니다. 클래스, 속성, 관계, 제약 조건 등을 기계가 이해할 수 있는 형태로 정의할 수 있어 Semantic Web과 지식 그래프 구현에 활용됩니다. -
Semantic Web
웹상의 정보에 의미와 관계를 부여해, 사람이 읽는 문서뿐 아니라 기계도 데이터의 의미를 이해하고 처리할 수 있도록 하려는 개념입니다. 온톨로지와 RDF, OWL 같은 표준 기술이 자주 함께 언급됩니다. -
디지털 트윈(Digital Twin)
현실 세계의 시스템, 장비, 공정, 공간 등을 디지털 환경에 복제한 모델입니다. 실제 운영 데이터를 기반으로 현재 상태를 모니터링하거나, 특정 조건에서 어떤 결과가 발생할지 시뮬레이션하는 데 활용됩니다. -
Data silo, 데이터 사일로
데이터가 부서, 시스템, 서비스별로 분리되어 서로 연결되지 않는 상태를 의미합니다. 데이터 사일로가 심하면 같은 고객이나 상품에 대한 정보가 여러 시스템에 흩어져 전체 맥락을 파악하기 어렵습니다. -
Strands Agents
AWS가 공개한 오픈소스 AI 에이전트 SDK입니다. 모델 중심 접근 방식으로 AI 에이전트를 구성할 수 있으며, Amazon Bedrock 같은 AWS 서비스뿐 아니라 다양한 외부 모델·도구와도 연계할 수 있습니다. -
Zero-ETL
별도의 ETL 파이프라인 구축 부담을 줄이고, 운영 데이터 소스의 데이터를 분석 시스템으로 더 쉽게 연동하기 위한 접근입니다. AWS에서는 Amazon Redshift와 여러 데이터 소스 간의 Zero-ETL 통합을 제공하며, 분석과 AI/ML에 더 신선한 데이터를 활용하는 데 목적이 있습니다.
참고 자료
바이브 코딩으로 완성하는 AWS 서버리스 OpenClaw
정도현 수석 컨설턴트 (주식회사 로보코)
이 세션에서는 바이브 코딩을 활용해, 최근 화제를 모으고 있는 오픈소스 프로젝트 OpenClaw를 AWS 서버리스 인프라로 마이그레이션한 Serverless-OpenClaw 프로젝트를 단 하루 만에 구축한 실전 노하우를 공유합니다. 발표자는 AWS에서 소프트웨어 개발자 및 테크니컬 트레이너로 오랜 기간 근무한 경험을 바탕으로, Fargate, Lambda, API Gateway, DynamoDB를 조합해 강력한 보안을 유지하면서도 월 $1 수준의 운영 비용을 달성한 아키텍처를 설계했습니다. 세션에서는 아키텍처 설계, 보안 강화, 비용 최적화 전략을 바이브 코딩으로 구현하는 전 과정을 다루며, 특히 바이브 코딩의 효과를 극대화하는 핵심 기법인 TDD 기반 품질 확보, 인터뷰 기반 설계, 점진적 구현, AI에게 효과적으로 맥락을 전달하는 프롬프트 전략 등 실무에서 바로 적용할 수 있는 모범사례를 소개합니다.
개인적으로 가장 인상 깊었던 세션이었습니다. 저는 그동안 배포 과정을 직접 하나씩 설정하는 방식에 익숙했기 때문에, AWS CLI를 활용하면 Agent에게 배포 작업의 상당 부분을 맡길 수 있다는 점이 특히 새롭게 다가왔습니다.
물론 Agent에게 배포를 맡긴다고 해서 모든 과정이 자동으로 안전해지는 것은 아닙니다. 오히려 명확한 제약 조건, 검증 파이프라인, 비용 상한, 보안 기준을 더 꼼꼼히 정의해야 합니다. 그래서 이번 정리에서는 구현된 아키텍처 자체보다, 그 아키텍처를 구현하기 위해 사용한 프롬프트 전략과 개발 방식에 초점을 맞췄습니다.
먼저 프로젝트의 성격에 따라 배포 아키텍처를 설계하는 인터뷰 세션을 진행해야 합니다. 이 세션에서는 비용 최적화를 주요 목표로 두고, AWS CDK 스택을 기준으로 요구사항을 구체화합니다. 인터뷰 과정에서 여러 trade-off를 비교하고, 프로젝트에 적합한 월 최대 비용을 고정합니다.
예를 들어 저는 개인 프로젝트에 월 최대 20달러 정도까지 사용할 의향이 있었기 때문에, Lightsail 인스턴스를 추천받았습니다. 이후 해당 인스턴스에 프론트엔드, 백엔드, 데이터베이스를 Docker로 모두 띄워 구현했습니다. 확장 가능성을 고려했을 때 기존에 사용했던 Railway + Vercel 조합보다 더 저렴하고 관리하기 편했으며, 성능과 속도 면에서도 만족스러웠습니다.
또 하나 인상 깊었던 점은 검증 방식이었습니다. 매 배포마다 사람이 직접 모든 것을 검증하는 방식은 비효율적이며, Human in the Loop(HIL)가 병목이 될 수 있습니다. 대신 AI가 한 번 더 리뷰하도록 구성하고, 그 결과를 리포트 형태로 받아 사람이 최종 확인하는 방식이 더 현실적일 수 있습니다.
다음과 같은 검증 파이프라인을 모두 통과해야 커밋할 수 있도록 강제하는 방식이 소개되었습니다.
-
TDD 기반 검증
테스트 케이스를 모두 통과할 때까지 구현을 수정합니다. -
Pre-commit hook
커밋 전에 ESLint, Vitest, 타입 검증 등을 실행합니다. -
Pre-push hook
원격 저장소에 push하기 전에 E2E 테스트와 CDK Synth 검증을 수행합니다. -
README의 제약 조건 검증
예를 들어 NAT Gateway 사용 금지, 월 비용 상한 준수 여부 등을 확인합니다. -
비용 및 보안 체크리스트 검증
/cost,/security와 같은 skill 또는 체크리스트를 활용해 비용과 보안 조건을 검토합니다.
처음에는 이러한 검증 파이프라인을 직접 적용하기 복잡해 보일 수 있습니다. 하지만 참고 자료의 GitHub repository를 clone한 뒤, Agent에게 “이 검증 파이프라인을 내 프로젝트에 맞게 적용하고 싶다”고 요청하면 자동화 코드를 작성하도록 유도할 수 있습니다.
용어 정리
- CDK Synth
AWS CDK 코드가 CloudFormation 템플릿으로 정상 변환되는지 확인하는 과정입니다. 배포 전에 인프라 정의가 올바른지 검증하는 데 활용됩니다.