0. 서론
2026년 3월 17일에 화요일에 코엑스에서 진행한 AWS Startup Unicorn Day에 다녀왔습니다.
요즘 관심 있게 연구하고 있은 Agent AI와 온톨로지 관련 세션이 있어서 바로 신청해버렸네요.
오전 키노트 세션과 오후에는 선택해서 듣고 싶은 세션을 찾아가서 듣는 식으로 진행했는데요. 제가 들었던 내용들 간단하게 정리해서 공유드립니다.
세션 1: 한국 AI 스타트업 2026 - 기대를 넘어 산업과 현실로
발표자: 김영태 (AWS 한국 스타트업 세일즈 총괄)
이 세션은 한국 AI 스타트업 생태계가 집중하고 있는 5가지 핵심 영역과 대표적인 기업 사례를 조명했습니다.
AI Fabless (전문 AI 칩 설계):
- 범용 NPU: 데이터센터에서 엔비디아 GPU를 대체할 고성능 범용 칩 개발 (퓨리오사, 리벨리온).
- LPU: 트랜스포머 모델의 메모리 병목 현상 해결에 특화된 칩 (하이퍼엑셀).
- DPU: 데이터 액세스와 네트워크 I/O 연산을 전담하여 가속을 돕는 칩 (망고부스트).
- Edge NPU: 피지컬 AI(로봇, CCTV 등) 환경에 맞춘 저전력 특화 칩 (모빌린트).
AI 플랫폼 최적화:
- 추론 가속: vLLM 대비 3배 이상의 고효율 추론 성능 제공 (프렌들리 AI).
- MLOps 및 인프라 관리: 하이브리드/멀티 클라우드 환경의 GPU 팜 관리 (베슬 AI).
- 경량화 및 포팅: 모델 경량화 및 특정 칩(AWS 트라니움 등)으로의 포팅 지원 (노타 AI).
AI 모델 프로바이더 (파운데이션 모델):
- LLM: 한국어 특화 고성능 언어 모델 (업스테이지, 트릴리어넥스).
- 피지컬 AI: 비전-언어-행동을 관제하는 로봇 범용 OS 모델 (코멧, 리얼월드AI).
- 비전 및 감성 AI: 산업용 비전 모델(슈퍼브 AI, 스트라드비전) 및 사람의 감정을 이해하는 챗/TTS 모델(네오사피엔스, 스캐터랩).
AI 애플리 케이션 (가장 많은 스타트업이 포커스하는 영역):
- 리걸테크: 판례 분석 및 문서 작성 (로앤컴퍼니, 엘박스).
- 금융/기타: 현금 흐름 분석 및 투자 자동화 (핀다, Quantit), 이커머스 수요 예측, 마케팅 채널 분석 등.
AI 코딩:
- 자체 개발보다는 해외 글로벌 솔루션(예: 클로드 코드)을 적극 활용하는 추세입니다.
세션 2: 비전 파운데이션 모델과 데이터 플랫폼을 활용한 버티컬 AI 혁신 여정
발표자: 차문수 (Superb AI CTO)
이 세션은 기존 비전 AI의 한계를 극복하기 위해 Superb AI가 개발한 비전 파운데이션 모델 'ZERO'의 개발 과정과 산업 적용 사례를 다루었습니다.
기존 비전 AI의 한계점:
- Closed World: 새로운 객체나 환경이 추가될 때마다 처음부터 다시 학습해야 하는 문제.
- 데이터 병목: 매번 데이터를 수집, 수동 라벨링, 학습해야 하므로 높은 운영 비용과 시간이 소모됨.
- 스케일링 비용: GPU 클러스터 운영 복잡성, 인프라 분리
해결책: 비전 파운데이션 모델 'ZERO':
- Zero-shot 및 Open-world: 사전 학습된 카테고리가 없어도 텍스트나 자연어 형태로 객체를 탐지 가능.
- 멀티모달 프롬프트: 텍스트 프롬프트뿐만 아니라 이미지(비주얼 프롬프트)를 입력하여, 카테고리로 정의하기 힘든 특정 산업군의 객체도 다이내믹하게 인식 가능.
해결책 : 데이터 파이프라인 및 라벨링 자동화:
- 10억 장의 이미지를 오토 큐레이션을 통해 400만 장으로 압축.
- AWS Step Functions를 활용해 4단계(디텍션, 마스크, 포즈, 캡셔닝) 오토 라벨링 파이프라인을 구축하여 자동화율 90% 달성.
대규모 학습 인프라 및 비용 최적화 (AWS 활용):
- 인프라: AWS HyperPod(Slurm)과 FSx for Lustre를 결합하여 H200 GPU 32장 환경에서 데이터 I/O 병목 없이 분산 학습 수행.
- 비용 절감: Flexible Training Plan(FTP)을 통한 단기 고성능 GPU 예약(40% 절감)과 저렴한 인스턴스를 활용한 사전 세팅 분리로 학습 기간을 30~40일에서 10일로 단축.
산업 적용 사례 (버티컬 혁신):
- 제조: 풍력 발전소 터빈 철판 공정(SOP) 모니터링, 다품종 소량 생산 환경에서의 제품 개수 및 생산량 추적.
- 물류/리테일 및 보안: 수많은 종류의 제품 인식, "물건을 든 사람"과 같이 복잡한 상황 인지 및 검색, 화재나 사고 차량 모니터링.
세션 3: 2만 5천 명의 법률 전문가가 선택한 법률 AI 서비스 ‘슈퍼로이어‘의 성장 전략
발표자: 안기순 (로앤컴퍼니 이사/법률AI연구소장)
로앤컴퍼니의 '슈퍼로이어'가 어떻게 1년 8개월 만에 국내 변호사 대다수(약 2만 5천 명)를 사로잡았는지, 버티컬 AI의 성공 공식을 공유했습니다.
법률 산업의 페인 포인트와 생성형 AI 도입의 장벽:
- 시간이 오래 걸리는 문서 작성과 리서치로 인한 업무 병목 현상.
- 환각 현상(Hallucination): 법률 분야에서는 치명적인 오류 (영미권 징계 사례 존재).
- 보안 및 타깃 문제: 민감한 고객 정보, 로펌의 자산인 문서 유출 우려, 일반인 대상 서비스 시 법적 책임 문제.
슈퍼로이어의 해결 전략:
- 환각 최소화: 530만 건 이상의 판례/법령과 전문 출판사의 검증된 데이터를 RAG 방식으로 연동. 특허 출원한 '인용 적절성 평가' 기능으로 AI가 제시한 판례가 맞게 쓰였는지 교차 검증 지원.
- 업무 맞춤형 기능: 단순 챗봇을 넘어, 문서를 직접 편집하고 초안을 작성할 수 있는 '롱폼(Long-form)' 에디터와 특정 사건의 문서들만 모아 분석하는 '사건 기반 대화' 기능 제공.
- 철저한 보안: 학습에 고객 데이터를 사용하지 않으며, 대형 로펌을 위해 AWS 기반의 프라이빗 링크를 활용한 '클라우드 프레미스' 보안 환경 구축.
- 성과: 사용자 업무 시간 시간당 약 28.5분 절감(생산성 1.9배 향상), 첫 달 100원 프로모션 이후 정기 결제 전환율 96.7% 달성.
세션 4: 2026 투자 트렌드 속 한국 스타트업의 성장 기회 (AWS 이기혁 총괄)
핵심 주제: 제본스의 역설과 풍요의 시대, 그리고 '작은 팀'의 부상
- 제본스의 역설과 AI: 증기기관의 효율이 좋아지자 석탄 소비가 오히려 늘어난 것처럼, AI 모델의 성능이 높아질수록 인간은 AI 에이전트를 더 많이, 더 자주 사용하게 될 것입니다.
- 투자 시장의 변화: 2025년 글로벌 스타트업 투자의 48%가 AI에 집중되었습니다. 그다음 투자처로는 피지컬 AI(Physical AI)가 전년 대비 74% 성장하며 급부상 중이며, 한국 스타트업들에게 유리한 전장입니다.
2026 스타트업 3대 트렌드:
- '앙트레프레너'에서 '빌더(Builder)'로: 개발 지식이 없는 비전공자나 시니어 현업 전문가들도 AI(바이브 코딩 등)를 이용해 직접 프로덕트를 만들어내는 시대가 되었습니다.
- 작은 팀의 가치 상승: 과거에는 펀딩을 받으면 팀 규모(Headcount)를 늘리는 데 집중했지만, 이제는 AI 에이전트의 도움으로 팀 사이즈가 작아지고 있습니다. 투자 생태계에서도 "더 작은 팀일수록 투자 매력도가 높다"고 평가합니다.
- 빠른 엑시트(Exit)와 연쇄 창업: AI 기술 경쟁 속에서 수많은 소규모 팀들이 빠르게 인수(Acqui-hire)되거나 조 단위 밸류에이션으로 매각되며 연쇄 창업 생태계가 커지고 있습니다.
- 제본스의 역설과 AI: 증기기관의 효율이 좋아지자 석탄 소비가 오히려 늘어난 것처럼, AI 모델의 성능이 높아질수록 인간은 AI 에이전트를 더 많이, 더 자주 사용하게 될 것입니다.
- 투자 시장의 변화: 2025년 글로벌 스타트업 투자의 48%가 AI에 집중되었습니다. 그다음 투자처로는 피지컬 AI(Physical AI)가 전년 대비 74% 성장하며 급부상 중이며, 한국 스타트업들에게 유리한 전장입니다.
세션 5: 생성형 AI를 넘어 Agentic AI로 (AWS 김태현 총괄)
핵심 주제: 생각하고 행동하는 AI 시스템 구축을 위한 5대 요소
Generative AI vs. Agentic AI:
- 생성형 AI: 단일 턴(Single-turn) 방식. 인간이 세세하게 프롬프트를 지시하는 '오퍼레이터(Operator)' 역할을 합니다.
- 에이전틱 AI: AI가 스스로 업무를 수행. 인간은 목표와 경계를 설정하고 결과를 검토하는 '슈퍼바이저(Supervisor)' 역할을 맡습니다.
에이전틱 AI를 구성하는 5가지 핵심 요소:
- 추론 (Reasoning): 복잡한 문제를 이해하고 어떻게 접근할지 사고하는 능력.
- 계획 (Planning): 목표를 잘게 쪼개고 실행 순서를 수립.
- 도구 사용 (Tool Use): API 호출, DB 조회, 코드 실행 등 외부 시스템 연동 (최근 MCP 및 툴 콜링 확산).
- 메모리 (Memory): 단기적 작업 맥락 기억 및 장기적 사용자 선호도/상태 저장.
- 반성 (Reflection): 결과를 스스로 평가하고 오류를 수정하여 다음 행동을 개선.
도입 전략 (AIDC): AI가 비즈니스 의도를 바탕으로 설계와 실행을 주도하고, 인간은 각 단계의 정합성을 검증하는 'AI-Driven Coding(AIDC)' 방식을 추천합니다. 내부 시스템과 연결된 반복적이고 규칙적인 업무부터 작게 에이전트화를 시작하는 것이 좋습니다.
세션 6: AI 도입 변화와 업스테이지의 파트너십 전략 (업스테이지 권순일 CSO)
핵심 주제: 기업의 AI 도입 4단계와 'Agent-ready Context'의 중요성
이 세션은 B2B 솔루션 기업으로서 업스테이지가 시장의 변화를 어떻게 읽고 있는지에 대한 통찰을 제공합니다.
AI 도입의 4단계 (Evolution of AI Adoption):
- Stage 1 (단순 부착): 기존 레거시 소프트웨어에 AI(예: OCR)를 단순 추가. 즉각적 효과는 있으나 소프트웨어 본연의 가치를 넘어서진 못함.
- Stage 2 (테스크 대체): 문서 해석, 보고서 작성, 정보 추출 등 특정 단위 업무(Task)를 자동화.
- Stage 3 (프로세스 대체): 단위 업무들이 모여 전체 워크플로우를 대체. (현재 시장의 주요 투자 포인트이자 에이전트 AI의 타깃).
- Stage 4 (AI Native): 밸류체인 전체가 AI 네이티브로 재편. 기존에 4명이 하던 일을 AI가 해체하고 재조립하여 2명이 처리하고, 나머지 2명은 새로운 부가가치를 창출하는 형태. 기업은 결국 이 단계로 가야 근본적인 혁신이 가능합니다.
업스테이지의 기술적 진화와 '다큐먼트 AI':
- 초기 Stage 1/2에서 시작해, 현재는 '언어 모델(LLM)'과 비정형 데이터를 파싱해 디지털화하는 '다큐먼트 AI(Document AI)' 두 가지 핵심 프로덕트에 집중하고 있습니다.
- 최근 트렌드는 이 두 가지를 결합하여 데이터 준비부터 에이전트 활용까지 엔드투엔드(E2E)로 구축하는 것입니다.
핵심 인사이트: "AI-Ready Data"를 넘어 "Agent-Ready Context"로:
- 기술 발전 속도가 워낙 빨라, 코딩이나 논리적 추론 등 인간이 하던 '기획/고민'의 영역까지 모델이 빠르게 대체하고 있습니다. (Stage 5의 도래)
- 하지만 아무리 추론과 툴 콜링 성능이 뛰어난 모델(예: 최신 Claude)이라도 '맥락(Context)'이 주어지지 않으면 현실의 복잡한 문제를 풀 수 없습니다.
- 즉, 에이전트 시스템의 성패는 모델 자체의 성능보다 비정형 데이터를 얼마나 잘 파싱하고 정제하여 에이전트가 소화할 수 있는 맥락(Agent-Ready Context)으로 모델에 부어주느냐에 달려있습니다.
- 이러한 데이터 연동과 환경 구축을 스타트업이 자체적으로 밑바닥부터 만드는 것은 매몰 비용이 너무 크기 때문에, AWS 같은 클라우드 환경을 적극 활용하여 연결(Integration)에 집중하는 것이 핵심 파트너십 전략입니다.세션 6: AI 도입 변화와 업스테이지의 파트너십 전략 (업스테이지 권순일 CSO)이 세션은 B2B 솔루션 기업으로서 업스테이지가 시장의 변화를 어떻게 읽고 있는지에 대한 통찰을 제공합니다.
오전 세션 종료 : 스타트업을 위한 핵심 조언 및 스탠스
- "우리는 오퍼레이터인가, 슈퍼바이저인가?" 팀 내부의 일하는 방식을 점검해야 합니다. 개발, 기획, 운영 등 전 분야에서 AI 에이전트를 단순한 보조 도구(Stage 1)가 아닌 협업 동료로 격상시키고, 창업자와 팀원은 방향을 지시하고 검증하는 관리자 역할로 전환해야 폭발적인 생산성을 낼 수 있습니다.
- "인프라 구축이라는 바퀴를 다시 발명하지 마라." 데이터베이스 연동, GPU 클러스터 구성, 파이프라인 구축 등 인프라 레벨의 고민은 클라우드 관리형 서비스(AWS HyperPod, Bedrock 등)에 과감히 위임해야 합니다. 스타트업의 한정된 리소스는 '우리 도메인만의 특화된 데이터를 에이전트가 이해할 수 있는 맥락(Context)으로 가공하는 것'에 집중 투자해야 합니다.
- "작은 조직이 곧 무기다." 팀의 덩치를 키우는 것이 더 이상 성장 지표가 아닙니다. AI 네이티브 워크플로우를 갖춘 소수 정예 조직이 투자 시장에서 훨씬 높은 평가를 받습니다. 무거운 레거시가 없는 스타트업의 장점을 살려, 처음부터 AI가 업무의 중심이 되는 'AI 네이티브(Stage 4)' 구조로 비즈니스를 설계하라고 합니다.
오후 세션 1 : Text2SQL 도입 배경과 기본 아케텍처 (손희연 솔루션즈 아키텍트)
비즈니스 부서에서 단순한 데이터 조회를 요청해도, 데이터팀을 거치면 커뮤니케이션 비용이 발생하고 답변을 받기까지 며칠이 소요되는 병목 현상이 발생합니다. 이를 해결하기 위해 사용자가 자연어만 입력하면 자동으로 SQL을 생성하고 결과를 반환하는 Text2SQL 도입이 필요합니다.
AWS 기반 데이터 분석 환경 구축
Text2SQL 에이전트가 원활하게 작동하려면 기반이 되는 데이터 환경이 잘 갖춰져야 합니다.
- 저장 및 관리: Amazon S3에 데이터를 적재하고, AWS Glue Data Catalog를 통해 스키마를 자동화하여 관리합니다.
- 쿼리 실행: 서버리스 환경인 Amazon Athena를 활용해 S3 데이터를 즉시 쿼리합니다.
- 벡터 검색(Vector Search): OpenSearch를 활용하여 스키마나 예시 쿼리를 임베딩해 둡니다. 사용자의 질문과 의미적으로 유사한 스키마/쿼리를 검색해 LLM의 정확도를 높입니다.
- 에이전트 연결 (MCP 활용): 'AWS Data Processing MCP'를 활용하면 LLM이 Athena에 직접 쿼리를 날리거나 Glue에서 스키마 정보를 쉽게 받아올 수 있어 개발 부담을 크게 줄일 수 있습니다.
시맨틱 레이어(Semantic Layer)의 중요성
단순히 DB 스키마만 LLM에게 던져주면 복잡한 비즈니스 질문을 제대로 처리할 수 없습니다. 모델이 데이터의 맥락을 이해할 수 있도록 징검다리 역할을 하는 '시맨틱 레이어' 구축이 필수입니다.
- 구조적 정보: 테이블명, 컬럼명, 데이터 타입 등.
- 비즈니스 컨텍스트: 예를 들어 데이터 내의 '주니어(Junior)'라는 값이 직급인지, 특정 카드사의 고객 등급인지 명확한 비즈니스 용어 정의를 추가합니다.
- 관계(Relational) 컨텍스트: 테이블 간의 조인(Join) 관계나 외래키(Foreign Key) 정보를 명시합니다.
오후 세션 1-2. Text2SQL 실전 성능 최적화 전략 (박서영 솔루션즈 아키텍트)
단일 테이블 조회(Easy)는 기본 설정만으로도 잘 작동하지만, 조인이 많아지는 복잡한 문제(Medium/Hard) 환경에서는 실패율이 높아집니다. 이를 극복하기 위한 4가지 운영/최적화 전략입니다.
① 모호성을 해결하는 멀티턴(Multi-turn) 전략
사용자의 질문이 모호할 때(예: "2020년 이후 영업부 직원 보여줘" -> '이후'가 초과인지 이상인지, '영업부'가 어느 컬럼인지 불명확함) 에이전트가 임의로 쿼리를 짜지 않고 사용자에게 다시 되물어(Clarify) 조건을 명확히 하는 전략입니다.
② 정답지를 제공하는 퓨샷(Few-shot) 프롬프팅
비율 계산처럼 복잡하거나 모델이 자주 틀리는 특정 패턴에 대해, 미리 작성된 '완벽한 예시 쿼리(정답지)'를 함께 제공합니다. 시맨틱 레이어에서 검색 시 이러한 예시 쿼리들을 함께 컨텍스트로 넘겨주면 모델의 실수를 극적으로 줄일 수 있습니다.
③ 꼭 필요한 스키마만 남기는 스키마 프루닝(Schema Pruning)
수십 개의 테이블 스키마를 LLM에게 한 번에 주면 혼란을 겪고 토큰 비용도 폭증합니다.
- 프로세스: 질문에서 키워드 추출 -> 질문과 컬럼/테이블 간 연관성 점수화(Schema Linking) -> 연관성 높은 상위 K개(Top-K) 스키마만 선별 -> DDL과 샘플 데이터 위주로 타이트하게 압축하여 LLM에 전달.
- 효과: 엉뚱한 테이블을 참조하는 실수를 줄여 정확도가 오르고, 토큰 사용량이 획기적으로 절약됩니다.
④ 피드백 루프(Feedback Loop) 구축
운영 중 사용자가 "쿼리 결과가 이상하다"라고 피드백을 주면, 이를 단순한 에러 로그로 버리지 않고 구조화된 데이터로 수집합니다. 사람이 직접 수정(Correction)한 올바른 로직을 다시 벡터 스토어나 퓨샷 예시로 편입시켜 시스템이 스스로 진화하도록 만듭니다.
서빙 최적화 및 최종 성과
- 모델 라우팅(Routing): 모든 질문에 무거운 대형 모델을 쓰면 비용과 속도에 문제가 생깁니다. 쉬운 질문은 작고 빠른 모델로, 모호하고 복잡한 중첩 쿼리는 추론 능력이 뛰어난 대형 모델로 자동 라우팅되도록 설계하여 비용과 성능의 균형(Trade-off)을 맞춥니다.
- 옵저버빌리티(Observability): CloudWatch 등을 통해 토큰 비용, 지연 시간(Latency), 툴 호출 패턴 등을 지속적으로 모니터링해야 합니다.
- 최종 성과 (BIRD 데이터셋 기준): 위 최적화 전략들을 복합적으로 적용한 결과, 정확도는 65%에서 84.8%로 상승했고, 토큰 사용량은 73% 감소했으며, 응답 시간은 35~45초 내외로 안정화되었습니다.
비즈니스 부서에서 단순한 데이터 조회를 요청해도, 데이터팀을 거치면 커뮤니케이션 비용이 발생하고 답변을 받기까지 며칠이 소요되는 병목 현상이 발생합니다. 이를 해결하기 위해 사용자가 자연어만 입력하면 자동으로 SQL을 생성하고 결과를 반환하는 Text2SQL 도입이 필요합니다.
오후 세션 2 : AI 에이전트 빌더 ‘에이전트리아(Agent Lia)’ 개발 여정과 생존 전략
발표자: 유대훈 (제네시스랩)
제네시스랩은 AI 영상 면접(뷰인터 HR), 인터랙티브 콘텐츠, 정신건강 진단 등 복잡한 AI 서비스를 9년간 운영하며 얻은 노하우를 집약해, 범용 AI 워크플로우 빌더인 '에이전트리아'를 개발했습니다.
1. 에이전트리아(Agent Lia) 개발 배경과 핵심 기능
개발 배경 (AI 서비스 운영의 한계):
- AI 영상 면접은 영상 1개당 수만 개의 프레임을 분석하고 10~15개의 딥러닝 모델을 거쳐야 하는 극도로 복잡한 파이프라인을 가집니다.
- AI 서비스는 개발 자체보다 '프로덕션 배포 이후'가 진짜 전쟁입니다. 예상치 못한 사용자 입력과 엣지 케이스가 쏟아지는데, 이를 수정하기 위해 기획-AI연구-개발팀이 핑퐁을 치면 배포에 수 주가 걸립니다.
- 이를 해결하기 위해 개발자 없이 도메인 전문가(현업)가 직접 AI 워크플로우를 수정하고 배포할 수 있는 범용 GUI 툴의 필요성을 느꼈습니다.
핵심 차별화 기능:
- 파이썬 코드 노드: 단순 샌드박스가 아닌, 노드 자체를 비동기(Async) 함수로 변환하여 동시성 처리를 가능하게 합니다. 복잡한 제어 노드 없이 코드 단에서 흐름을 제어할 수 있습니다.
- 어빌리티(Ability) 모듈화: 만든 워크플로우를 하나의 모듈로 묶어 버저닝하고, 다른 에이전트나 MCP(Model Context Protocol) 서버로 쉽게 배포·재사용할 수 있습니다.
- 실시간 공동 편집 및 무중단 배포: Figma처럼 여러 명이 동시 편집할 수 있으며, 개발/스테이징/운영 버전을 분리해 현재 캔버스 편집이 API 프로덕션 서비스에 영향을 주지 않는 무중단 배포와 키 회전(Key Rotation)을 지원합니다.
2. 리소스를 아끼는 기술 스택 및 아키텍처 최적화
- 오토 스케일링과 비동기 처리: Amazon EKS 환경에서 KEDA를 활용해 오토 스케일링을 구현하고, API 워커(Worker)들이 SQS(큐)에서 작업을 경쟁적으로 가져가도록 설계했습니다.
- 로그 병목 해결 (Log Decoupling): LLM 실행 시 남는 로그 데이터가 30~50MB에 달해 시스템 속도를 늦추는 문제가 있었습니다. 이를 해결하기 위해 로그 저장(미터링) 역할만 분리하여 별도의 큐(Queue)로 던져 처리하게 만들었습니다.
- DB의 대통합 (PostgreSQL): 처음에는 MariaDB, ScyllaDB(고용량), Milvus(벡터 스토어) 등 여러 DB를 섞어 썼습니다. 하지만 '동적 컬럼 인덱싱 + 벡터 유사도 검색'이 결합된 복잡한 쿼리 처리에 한계를 느끼고, PostgreSQL 하나로 대통합했습니다. (pgvector로 임베딩, PgBouncer로 커넥션 관리, pg_partman으로 파티셔닝 해결)
스타트업을 위한 핵심 전략 및 조직 문화 (강조 포인트)
한정된 리소스로 거대한 프로덕트를 만들기 위해 적용했던 처절하고도 실용적인 4가지 전략을 공유했습니다.
① 의사결정은 2시간 안에 끝낸다 (커뮤니케이션 비용 최소화)
- 기획서를 완벽하게 쓰고 다수(10~15명)가 모여 토론하는 방식은 속도를 늦춥니다.
- 초기 구조 설계 시에는 개발/AI 경험이 풍부한 시니어 3명만 투입해 빠르게 뼈대를 잡았습니다.
- 잘못된 결정으로 구조를 완전히 뒤엎어야 할 때(예: 노드 연결 UX 방식 변경)도, 실패를 비난하지 않고 “경험했으니 빠르게 인정하고 수정하자"는 문화를 정착시켰습니다.
② 도그푸딩(Dogfooding) 전략: 우리가 만든 툴의 첫 번째 고객은 '우리'
- 에이전트리아 플랫폼을 개발하기 위해 필요한 내부 파이썬 코드 생성기 등을 에이전트리아로 직접 만들어서 사용했습니다.
- 초기 버그가 많고 불편하더라도 내부 팀원들이 이를 감내하고 사용해야만 압도적으로 빠른 피드백 루프를 돌릴 수 있고, 결과적으로 프로덕트의 품질(엔터프라이즈급)을 높일 수 있습니다.
③ 관리 포인트를 줄이는 배포 자동화
- 모노레포(Monorepo) 구조: 코드를 하나의 레포지토리에 모으고, 하나의 도커 이미지(Single Image)로 빌드하되 실행 엔트리 포인트만 다르게 설정하여 관리 복잡도를 확 줄였습니다.
- 개발 지시 사항이 슬랙/Jira에 등록되면, 자동으로 브랜치를 따고 Claude Code(AI)를 연동시켜 초안을 개발하는 AI 주도 개발 자동화 파이프라인을 실험하며 생산성을 극대화했습니다.
④ 조직 역할의 파괴적 혁신: "개발자는 에이전트를 만들지 않는다"
- 과거에는 개발자가 정신질환 서적, 인사(HR) 논문 등을 수십 권씩 읽어가며 도메인을 억지로 이해하고 AI를 만들었습니다.
- 현재 제네시스랩에는 개발자가 단 한 명도 없는 'AX(AI Transformation) 팀이 존재합니다.
- 역할 분리: 개발자와 AI 연구원은 '에이전트를 쉽게 만들 수 있는 빌더(도구)'를 만드는 데에만 집중하고, 실제 AI 에이전트 서비스 기획과 제작은 해당 도메인 지식을 가진 전문가(현업)가 빌더를 이용해 직접 수행합니다. 이로 인해 수개월 걸리던 에이전트 개발 시간이 단 몇 분~며칠 단위로 단축되었습니다.
오후 세션 3: 우리 서비스의 데이터로 온톨로지 구축해보기(박진우 솔루션즈 아키텍트 | AWS)
1. 온톨로지(Ontology)와 지식 그래프의 이해
- 개념: 특정 도메인의 지식을 개체(Entity), 속성, 관계, 제약조건으로 체계화하여 컴퓨터가 이해할 수 있게 만든 '지식의 지도'입니다.
- 도입 목적:
- 사일로(Silo) 제거: 데이터 사일로란 각 부서나 서비스마다 데이터가 흩어져 있고 서로 연결되지 않아 전체 맥락을 파악하기 어렵습니다. 온톨로지는 부서별로 파편화된 데이터(DB, 문서, 사내 메신저 등)를 연결합니다.
- 암묵지의 자산화: 암묵지의 부재란 언어, 문서, 데이터 등으로 공식화할 수 없는 개인의 경험, 직관, 노하우, 숙련된 기술이 조직 내에서 공유되지 않거나 소멸하는 상태를 의미합니다. 데이터는 존재하지만, 그 데이터가 실제 비즈니스 맥락에서 어떻게 연결되고 사용되는지에 대한 인간의 숙련도나 맥락적 지식을 시스템화하기 어렵습니다. 온톨로지는 회사 내 숙련된 작업자들의 직관이나 노하우(예: 특정 시간대 물류 센터 인력 배치 노하우)를 그래프 형태로 모델링하여 논리적으로 추론할 수 있게 만듭니다.
2. 온톨로지 구축을 위한 현실적인 접근법 (Start Small)
- 모든 데이터를 다 넣으려는 욕심 버리기: 사내의 모든 슬랙 메시지나 문서를 무작정 벡터 DB나 그래프 DB에 때려 넣는 것은 비효율적입니다. 비즈니스에 가장 큰 영향을 미치는 핵심 이벤트(예: 물류 창고 재고, CS 발생 포인트, 주문 발주 자동화 등)부터 작게 시작해서 관계를 모델링해야 합니다.
- 데이터 연동의 자동화 (Zero-ETL): AWS 환경에서는 S3, 다이나모DB, 오로라(Aurora) 등 다양한 소스의 데이터를 레드시프트나 오픈서치 등으로 손쉽게 동기화하는 Zero-ETL 통합이 발전하고 있어, 데이터 파이프라인 구축 부담이 과거보다 훨씬 줄어들었습니다.
3. 데모 아키텍처: 에이전트와 지식 그래프의 결합 (여행 도메인)
단순한 DB 쿼리를 넘어, 자연어로 복잡한 비즈니스 로직을 수행하는 과정입니다.
- 1단계 (기본 로드): Amazon Neptune(그래프 DB)에 공항, 국가, 라우팅 노선 데이터를 로드하고 OpenCypher 언어로 쿼리 환경을 구축합니다.
- 2단계 (자연어 에이전트): 에이전트(Strand SDK + Claude 등)를 붙여 "런던에서 나리타까지 직항 노선 알려줘"라는 자연어를 OpenCypher 쿼리로 자동 변환하여 결과를 도출합니다.
- 3단계 (컨텍스트 확장): 유저의 페르소나(가족 여행객, 가성비 추구형 등)와 장소(호텔, 관광지) 데이터를 그래프에 추가하여 개인화된 맞춤 경로를 찾아냅니다.
- 4단계 (비즈니스 수익화 연동): 에이전트가 MCP(Model Context Protocol)를 통해 Amazon Aurora(관계형 DB)에 저장된 '여행 패키지 상품 데이터'를 실시간으로 조회해, 완성된 여행 일정에 딱 맞는 수익성 상품을 최종적으로 끼워 넣어 추천합니다.
오후 세션 4: Amazon Bedrock과 기업 온톨로지로 완성하는 AI 에이전트, '릴리'
발표자: 김영수 (PFC Technologies Team Leader / AI Engineer)
'릴리'는 ChatGPT나 Claude처럼 '세상을 아는 AI'가 아니라, 사내 슬랙, 노션, 지라(Jira), 깃허브(GitHub), 데이터 웨어하우스까지 완벽히 꿰뚫고 있는 '우리 회사를 아는 AI' (조직의 PM 역할) 입니다.
1. 에이전트 도입 시 마주한 치명적인 한계점들
기업 환경에서 에이전트를 제대로 쓰려고 할 때 발생하는 3가지 근본적인 문제가 있었습니다.
- 흩어진 데이터와 인지 과부하: 사내 지식이 메신저, 위키, 코드 저장소 등에 파편화되어 있어 검색 비용이 너무 큽니다.
- 툴(MCP) 과부하로 인한 지능 하락: 슬랙, 노션, 깃허브 등 각 시스템을 연동하기 위해 수많은 도구(Tool)를 에이전트에게 쥐여주면, 에이전트의 성능이 현저히 떨어집니다. (예: 7개 도메인, 51개 툴을 주면 추론 정확도 급락)
- 'Lost in the Middle' 현상: 방대한 사내 문서를 컨텍스트에 한 번에 다 밀어 넣으면, AI가 중간에 있는 핵심 정보를 잊어버리거나 오류율이 급증합니다.
2. 해결책: '점진적 탐색(Progressive Disclosure)'과 '온톨로지'
이 문제를 해결하기 위해 릴리는 데이터를 처음부터 풀 스캔(Full Scan)하지 않고, 폴더를 타고 들어가듯 '점진적'으로 탐색하도록 설계되었습니다. 그 핵심 기반이 바로 온톨로지입니다.
- 2,500개의 테이블을 30개의 개념으로 압축:
- 2,515개나 되는 복잡한 사내 DB 테이블을 AI에게 던져주지 않았습니다.
- 대신 대출, 투자자, 상환 등 약 30개의 굵직한 핵심 개체(Entity)로 구성된 '온톨로지(시맨틱 레이어)'를 구축했습니다.
- AI는 이 30개의 상위 개념만 먼저 이해한 뒤, 필요할 때만 관계(Relation)를 타고 들어가 상세 데이터를 조회합니다. 조인(Join) 없이 관계를 추적하며 필터링과 소팅을 수행합니다.
- 마법의 단일 조회 체계 (도구 최소화):
- 비즈니스 DB뿐만 아니라 슬랙, 노션, 코드베이스 등 모든 파편화된 데이터를 '동일한 온톨로지 형태'로 구성했습니다.
- 데이터 소스가 아무리 늘어나도 조회하는 방식이 똑같기 때문에, 릴리가 사용하는 도구(Tool)는 단 4개에 불과합니다. 도구 개수를 극단적으로 줄여 AI의 추론 성능을 최상으로 유지했습니다.
3. '릴리'의 성과 및 차별화된 아키텍처
- Multi-Agent가 아닌 Single-Agent 전략: 최근 에이전트 여러 개를 붙이는 방식이 유행이지만, 이 팀은 단 하나의 에이전트만 만들고 대신 온톨로지(지식 그래프)를 확장하는 데 집중했습니다.
- 놀라운 사내 도입 지표:
- 초기(비즈니스 온톨로지 구축 전)에는 월 1,000건 미만 사용되었으나, 비즈니스 및 코드베이스 온톨로지가 완성된 후 월별 활성 대화가 32배 폭발적으로 성장했습니다.
- 현재 직원 1인당 하루 평균 13건의 질문을 하며, 월간 활성 사용자(MAU) 비율이 97.2%에 달해 사내에 도입된 일반 ChatGPT Enterprise보다 훨씬 높은 사용률을 기록 중입니다.
- 슬랙에서 과거 논의 히스토리를 찾아주거나, 에러 발생 시 처리하는 PR(Pull Request) 코드를 직접 작성해 주는 수준까지 도달했습니다.
스타트업 및 구축 실무자를 위한 핵심 인사이트
"최고의 성능을 내는 AI 에이전트는, 복잡한 프롬프트나 수십 개의 에이전트 결합에서 나오는 것이 아니라 'AI가 소화하기 좋게 잘 정제된 데이터 레이어(Semantic Layer / Ontology)'에서 나온다."
특히 모든 사내 데이터(비정형 문서, 메신저, 정형 DB)를 하나의 온톨로지 스키마 구조로 통합하여 AI에게 주어지는 툴(Tool)의 개수를 4개로 줄였다는 점은 엔지니어링 적인 팁도 얻어갈 수 있습니다.
마치며...
이번 AWS Startup Unicorn Day의 모든 세션을 관통하는 단 하나의 강력한 메시지가 있다면, 바로 "최고의 성능을 내는 AI 에이전트는 무거운 모델이나 수십 개의 화려한 툴(Tool)이 아니라, 잘 정제된 데이터 레이어(Semantic Layer, 온톨로지 등)에서 탄생한다"는 것입니다.
아무리 뛰어난 추론 성능을 가진 프론티어 모델이라도, 기업 내부에 흩어진 800페이지짜리 문서나 파편화된 슬랙 대화를 스스로 완벽히 꿰뚫어 볼 수는 없습니다. 스타트업과 개발 조직의 한정된 리소스가 향해야 할 곳은 무리한 인프라 구축이 아니라, 우리 도메인만의 고유한 데이터를 AI가 소화하기 좋게 '온톨로지'로 구조화하는 작업입니다. (단, Grpah DB로 구현하라는 것이 아니고 RDB로도 가능합니다. 그러나 점진적으로 LLM이 서치해나갈 수 있는 구조화 작업이 필요합니다.)
이제 스타트업은 팀원을 단순히 늘리는 것이 성장 지표가 되는 시대가 끝났다고 말합니다. 소수 정예 인력이 단순 오퍼레이터를 넘어선 '슈퍼바이저'로 활약하는 AI 네이티브 조직만이 다가오는 에이전틱 AI(Agentic AI) 시대의 새로운 유니콘이 될 수 있다고 언급하였습니다.
제가 다녀와서 받아적은 내용을 정리한 글이라 놓친 부분도 있을테지만, 얻은 인사이트를 조금이라도 나누고자 글을 작성해봤습니다. Agent AI, 온톨로지, 그리고 지금 진행중인 GTC에서 젠슨황의 행보 등 AI에 관심있다면 너무 빠르게 변하는 트렌드지만 도움이 될 것 같습니다! 감사합니다.