vector-db

12 개의 포스트

aws4분 읽기큐레이션 요약

AWS 주간 요약: AWS Heroes Summit, Amazon Bedrock의 웹 검색, Dogwood, Kiro Crew 등 (2026년 8월 10일) | Amazon Web Services

AWS는 AI 에이전트의 실시간 정보 활용, 실행 환경 제어, 벡터 검색, 거버넌스와 협업 개발을 강화하는 기능들을 대거 공개했다. Amazon Bedrock의 웹 검색·전용 런타임·DynamoDB 벡터 검색과 AWS Transform의 지속적 현대화가 주요 출시 내용이며, Dogwood와 Agent Plugins를 통해 에이전트의 안전성과 이식성도 확대한다. 또한 AWS Heroes Summit과 Kiro Crew를 통해 개발자 커뮤니티와 멀티에이전트 개발 경험을 강화하고 있다. ## AWS Heroes Summit - 전 세계 AWS Heroes가 초청된 연례 행사로, AI·서버리스·컨테이너 분야 전문가들이 참여했다. - AWS 내부 제품·서비스 팀과 직접 기술 토론, 심층 세션, 피드백 교환을 진행했다. - AWS CEO 맷 가먼의 대담과 James Hamilton의 AMA, 제품 팀별 브레이크아웃 세션 등이 열렸다. - 참가자 간 지식 공유와 협업 기회 확대가 행사의 핵심 성과였다. ## Amazon Bedrock의 웹 검색 - Amazon Bedrock에서 OpenAI 모델이 인터넷을 검색하고 최신 정보를 가져올 수 있게 됐다. - GPT-5.4, GPT-5.5, GPT-5.6 Sol·Terra·Luna 모델이 학습 데이터 이후의 실시간 웹 콘텐츠를 활용할 수 있다. - AI 에이전트가 최신 뉴스나 외부 정보를 바탕으로 답변하도록 구축할 수 있다. - 데이터가 보안이 적용된 AWS 환경에 머물며 외부 데이터 반출 없이 사용할 수 있어 데이터 레지던시 요구사항에 유리하다. ## Bedrock AgentCore 전용 런타임 인스턴스 - AI 에이전트를 전용 런타임 인스턴스에 배포하고 실행할 수 있다. - 에이전트 실행 환경을 더 세밀하게 제어할 수 있으며 성능과 비용을 예측하기 쉽다. - 실행 리소스와 운영 특성이 중요한 프로덕션 에이전트에 적합하다. ## DynamoDB 벡터 검색 - 기존 DynamoDB 데이터와 AI용 벡터 임베딩을 같은 데이터베이스에 저장할 수 있다. - 별도의 벡터 데이터베이스를 운영하지 않고도 의미 기반 검색을 제공한다. - 에이전트 메모리에 저장된 정보에서 관련 내용을 검색해 응답을 보강하는 에이전틱 그라운딩에 활용할 수 있다. - DynamoDB 기반 운영 모델을 유지하면서 예측 가능한 성능으로 벡터 검색을 추가할 수 있다. ## AWS Transform의 지속적 현대화 - 소스 코드 저장소를 대규모로 분석해 기술 부채를 식별하고 수정한다. - 메인프레임과 레거시 워크로드를 일회성 마이그레이션이 아니라 지속적·자동화된 방식으로 현대화한다. - AWS Transform용 Kiro Power와 에이전트 플러그인을 통해 개발 작업을 자동화할 수 있다. ## Lambda 네트워크 대역폭 확대 - Lambda 함수의 네트워크 대역폭이 최대 3,000Mbps로 증가했다. - VPC 외부에서 실행되며 메모리가 2GB 이상인 함수의 네트워크 대역폭이 메모리에 비례해 확장된다. - 2GB 메모리에서는 625Mbps, 10GB 메모리에서는 최대 3,000Mbps를 제공한다. - 대용량 데이터 처리나 Lambda와 다른 AWS 서비스 간 통신이 많은 작업의 성능을 높일 수 있다. ## Dogwood와 시간 기반 에이전트 거버넌스 - AWS는 AI 에이전트용 거버넌스 언어인 Dogwood를 오픈 소스로 공개했다. - Cedar 정책을 지원하고, 에이전트 행동의 시간적 조건을 표현할 수 있다. - AgentCore의 temporal policy는 현재 요청만이 아니라 세션 내 과거 행동 이력에 따라 정책 결정을 내린다. - 반복적인 행동, 특정 순서의 작업, 이전 행동에 따른 권한 제한 등 상태ful한 에이전트 통제가 가능하다. ## Agent Plugins 표준 - Agent Plugins는 AI 에이전트 확장을 위한 오픈 소스·벤더 중립 표준이다. - 하나의 형식으로 확장 기능을 패키징해 Kiro, VS Code, Cursor 등 표준을 구현한 여러 클라이언트에서 사용할 수 있다. - 특정 개발 도구에 종속되지 않는 에이전트 확장 생태계를 구축하는 것이 목적이다. ## Kiro Crew의 멀티에이전트 개발 - Kiro Crew는 작업 상태를 지속적으로 유지하는 협업형 개발 workspace다. - 단일 채팅 세션을 넘어 여러 저장소, 도구, 날짜에 걸친 엔지니어링 작업을 관리한다. - 여러 작업을 병렬로 실행하거나 하위 에이전트에게 작업을 위임할 수 있다. - 하위 에이전트가 작업 결과를 보고하므로 개발자가 자리를 비운 동안에도 작업이 진행된다. 이번 발표의 방향은 AI 에이전트를 단순한 대화형 도구에서 실시간 검색, 장기 실행, 상태 기반 권한 관리, 협업 자동화가 가능한 운영 시스템으로 발전시키는 데 있다. 실제 도입 시에는 Bedrock 웹 검색의 데이터 통제, AgentCore의 실행 비용, Dogwood 기반 정책 설계, DynamoDB 벡터 검색의 데이터 규모를 함께 검토하는 것이 좋다.

원문 읽기(새 탭에서 열림)
aws4분 읽기큐레이션 요약

Amazon DynamoDB, 이제 모든 규모에서 실시간 벡터 검색 지원 | Amazon Web Services

Amazon DynamoDB에 벡터 검색 기능이 정식 출시되어, 운영 데이터와 벡터 임베딩을 한 테이블에 저장하고 별도 벡터 데이터베이스 없이 유사도 검색을 수행할 수 있게 되었습니다. 서버 관리나 데이터 동기화 파이프라인 없이도 단일 자릿수 밀리초 지연 시간과 99% 이상의 재현율을 목표로 하며, 수조 개 벡터까지 확장할 수 있습니다. 기존에 DynamoDB를 사용하는 애플리케이션이라면 의미 기반 검색, RAG, 추천 시스템 등을 더 단순한 구조로 구현할 수 있습니다. ## DynamoDB 네이티브 벡터 검색의 특징 - 벡터 임베딩을 DynamoDB의 운영 데이터와 함께 저장합니다. - 별도 벡터 데이터베이스로 데이터를 복제하거나 동기화할 필요가 없습니다. - 서버 프로비저닝, 패치, 소프트웨어 설치, 유지보수가 필요 없는 서버리스 방식입니다. - 벡터 인덱스는 저장 용량 제한 없이 수평 확장됩니다. - 기존 DynamoDB와 동일한 서버리스 인프라 및 요청 단위 과금 모델을 사용합니다. - 에이전트 메모리, 검색 증강 생성(RAG), 추천 엔진, 개인화, 이상 탐지 등에 활용할 수 있습니다. ## 벡터 저장 및 검색 방식 - 사용자가 선택한 임베딩 모델로 텍스트를 벡터로 변환합니다. - Amazon Bedrock Titan Text Embeddings - Cohere Embed - OpenAI 임베딩 모델 등 - 임베딩은 DynamoDB의 기존 `List` 데이터 타입에 여러 `Number` 값으로 저장합니다. - 별도 벡터 전용 데이터 타입이나 테이블 스키마 변경이 필요하지 않습니다. - `PutItem` 또는 기존 항목을 수정하는 `UpdateItem`으로 벡터를 저장합니다. - 벡터 인덱스를 생성한 뒤 `SearchVectors` API로 검색합니다. - 검색 요청에는 다음 정보를 포함할 수 있습니다. - 검색용 쿼리 벡터 - 반환할 결과 수(최대 100개) - 파티션 키 값 - 선택적 필터 조건 - 결과는 유사도에 따라 정렬되어 반환되며, 벡터와 함께 상품명·가격 등 운영 데이터도 조회할 수 있습니다. ## 지원되는 인덱스 및 거리 함수 - 최대 4096차원 벡터를 지원합니다. - 다음 거리 함수를 제공합니다. - **Cosine**: 벡터의 크기보다 방향을 비교하며, 텍스트 의미 유사도에 적합합니다. - **Euclidean**: 벡터 간 실제 거리를 비교하며, 크기 자체가 중요한 데이터에 사용할 수 있습니다. - **Dot product**: 방향과 크기를 모두 반영하며, 관심도와 빈도를 함께 고려하는 추천 시스템 등에 적합합니다. - 일반적으로 임베딩 모델을 학습하거나 사용하는 방식에 맞는 거리 함수를 선택하는 것이 좋습니다. - Cosine과 Euclidean은 점수가 낮을수록 유사하고, Dot product는 점수가 높을수록 유사합니다. ## 파티션 키와 인라인 필터 - 벡터 인덱스에 파티션 키를 지정하면 벡터를 분산 저장하고 검색 범위를 제한할 수 있습니다. - 예를 들어 `marketplace`를 파티션 키로 설정하면 미국 시장 상품만 검색할 수 있습니다. - 대규모 데이터셋이나 높은 검색 처리량이 필요한 경우 파티션 키 사용이 권장됩니다. - 검색 시 일반 속성을 이용한 인라인 필터를 적용할 수 있습니다. - 예: `category = footwear` - 필터는 정확히 일치하는 값만 지원합니다. - `BETWEEN`, `BEGINS_WITH` 같은 범위 조건은 지원하지 않습니다. - 검색 결과에 반환할 속성은 전체 속성을 포함하거나 필요한 속성만 프로젝션할 수 있습니다. ## 상품 카탈로그 적용 예시 - 기존 `ProductCatalog` 테이블에 다음과 같은 운영 데이터가 있다고 가정합니다. - `productId` - `category` - `description` - `marketplace` - `name` - `price` - 상품 설명을 임베딩으로 변환한 뒤 `descriptionEmbedding` 속성으로 저장합니다. - `descriptionEmbedding`을 대상으로 `ProductDescriptionIndex` 벡터 인덱스를 생성합니다. - 인덱스 설정 예시는 다음과 같습니다. - 벡터 속성: `descriptionEmbedding` - 거리 함수: `Cosine` - 파티션 키: `marketplace` - 필터 속성: `category` - “lightweight running shoes for summer” 같은 자연어 검색어를 동일한 임베딩 모델로 변환합니다. - `US` 시장과 `footwear` 카테고리로 범위를 제한하고 Top K를 5로 설정하면, 의미적으로 가장 가까운 상품 5개를 유사도 순으로 반환합니다. ## 기존 구조와 비교한 장점 - 기존에는 DynamoDB 데이터를 전용 벡터 저장소로 복제해야 했습니다. - 이 방식은 다음과 같은 부담을 만들었습니다. - 데이터 동기화 파이프라인 운영 - 데이터 이동 비용 - 별도 데이터베이스 라이선스 및 운영 비용 - 두 시스템 간 일관성 관리 - 대규모 환경에서 예측 가능한 지연 시간 유지 - DynamoDB 네이티브 벡터 검색은 운영 데이터와 벡터를 한곳에서 관리해 이러한 복잡성을 줄입니다. 기존 운영 데이터가 DynamoDB에 있다면, 별도 벡터 데이터베이스를 추가하기 전에 네이티브 벡터 검색을 우선 검토할 만합니다. 특히 자연어 상품 검색이나 RAG처럼 벡터 검색 결과와 가격·재고·카테고리 같은 운영 속성을 함께 사용해야 하는 경우 구조 단순화와 운영 비용 절감에 유리합니다.

원문 읽기(새 탭에서 열림)
aws3분 읽기큐레이션 요약

에이전트형 AI 애플리케이션 구축을 위한 차세대 Amazon OpenSearch Serverless 소개 | Amazon Web Services

Amazon OpenSearch Serverless 차세대 버전은 AI 에이전트용 검색·벡터 백엔드로, 트래픽이 없을 때는 0까지 축소되고 필요할 때 초당 수천 건까지 확장됩니다. 기존 피크 용량 기준 클러스터 대비 최대 60% 비용을 절감할 수 있으며, 리소스 생성과 용량 확장이 이전 세대보다 크게 빨라졌습니다. Vercel, Kiro, Claude Code, Cursor 등과의 통합으로 인프라 관리 없이 몇 분 안에 프로덕션 수준의 검색 시스템을 구축할 수 있습니다. ## 서버리스 확장성과 비용 최적화 - 트래픽에 따라 용량을 0에서 수천 RPS 수준까지 자동 확장하고, 유휴 상태에서는 다시 0으로 축소합니다. - 기존 OpenSearch Service 클러스터를 피크 트래픽에 맞춰 프로비저닝하는 방식보다 최대 60% 비용을 절감할 수 있습니다. - 리소스 생성 시간은 수초이며, 이전 세대보다 용량 확장 속도가 최대 20배 빠릅니다. - 인덱싱, 검색, GPU 가속에 사용한 OpenSearch Compute Unit(OCU) 기준으로 컴퓨팅 비용이 부과됩니다. - 스토리지는 GB-month 기준으로 별도 과금됩니다. ## 차세대 컬렉션 생성 - AWS Management Console의 **Serverless → Create collection**에서 차세대 OpenSearch Serverless 컬렉션을 생성할 수 있습니다. - 출시 시 지원되는 컬렉션 유형은 다음 두 가지입니다. - `SEARCH`: 전문 검색 - `VECTORSEARCH`: 벡터 검색 - **Express create**를 사용하면 별도 설정 없이 기본값과 보안 정책이 자동 적용됩니다. - 일부 설정은 컬렉션 생성 후에도 변경할 수 있습니다. - 기존 OpenSearch Serverless 인프라를 사용하려면 **Switch to Classic**을 선택해야 합니다. ## 컬렉션 그룹과 용량 설정 - AWS CLI 또는 SDK를 이용해 컬렉션 그룹과 컬렉션을 생성할 수 있습니다. - 컬렉션 그룹에서 차세대 세대(`NEXTGEN`), 대기 복제본, 인덱싱·검색 용량 한도를 설정합니다. - 예시에서는 인덱싱과 검색 용량을 다음과 같이 설정합니다. - 최대 용량: 각각 96 OCU - 최소 용량: 각각 0 OCU - 컬렉션은 상위 컬렉션 그룹의 세대 설정을 상속합니다. - 컬렉션 그룹 생성 시 `standby-replicas ENABLED`를 지정해 대기 복제본을 활성화할 수 있습니다. - 제공된 CLI 예시는 글에서 같은 명령이 중복 제시되어 있으며, 2026년 5월 업데이트에서 최대 인덱싱·검색 용량 기본값이 96으로 수정되었습니다. ## AI 에이전트 개발 플랫폼 통합 - Vercel 콘솔에서 새 OpenSearch 컬렉션을 생성하거나 기존 OpenSearch Serverless 컬렉션을 연결할 수 있습니다. - 애플리케이션 성장에 맞춰 검색 기능을 단계적으로 추가할 수 있습니다. - Claude Code, Cursor, Kiro를 사용하면 아이디어에서 작동하는 프로토타입까지 빠르게 구현할 수 있습니다. - OpenSearch Agent Skills는 검색 도메인 지식, 모범 사례, 다단계 실행 로직을 에이전트에 제공합니다. - Kiro Powers의 OpenSearch Launchpad는 검색 애플리케이션의 아키텍처를 계획하고 구현하는 과정을 안내합니다. ## 제공 범위와 사용 시작 방법 - 차세대 OpenSearch Serverless는 정식 출시되었으며, 기존 OpenSearch Serverless가 제공되는 모든 AWS 상용 리전에서 사용할 수 있습니다. - 콘솔, AWS CLI, AWS SDK를 통해 컬렉션을 생성할 수 있습니다. - 자세한 관리 방법과 가격은 Amazon OpenSearch Service 공식 문서와 가격 페이지에서 확인할 수 있습니다. AI 에이전트의 검색·벡터 기능을 구축한다면, 트래픽 변동이 크거나 초기 인프라 운영 부담을 줄이고 싶은 경우 차세대 OpenSearch Serverless가 적합합니다. 특히 Vercel이나 Kiro를 사용하는 팀은 Express create와 기본 통합 기능을 활용해 빠르게 시작한 뒤, 필요에 따라 OCU 한도와 검색 기능을 확장하는 방식을 추천합니다.

원문 읽기(새 탭에서 열림)
line원문

ODW #5: 벡터 DB와 에이전트 스킬로 RAG 시스템 만들기 (새 탭에서 열림)

LY Corporation에서 진행된 이번 워크숍은 대량의 마크다운 문서를 효율적으로 검색하기 위해 ChromaDB 기반의 RAG(검색 증강 생성) 시스템을 구축하고, 이를 에이전트 스킬과 결합하여 개발자 경험을 혁신하는 방법을 다룹니다. 단순히 문서를 데이터베이스화하는 것을 넘어, AI 에이전트가 데이터의 구조와 활용법을 이해하도록 돕는 '스킬' 정의를 통해 검색 정확도와 업무 효율을 동시에 높이는 실무적인 접근법을 제시합니다. 이러한 시스템은 향후 자연어 기반의 문서 검색을 넘어 코드 생성 및 리뷰 프로세스에 지식 베이스를 직접 연결하는 핵심 도구로 활용될 수 있음을 시사합니다. ### 개발 생산성 향상을 위한 RAG의 도입 배경 * 대규모 앱 개발 과정에서 발생하는 빌드 에러, 아키텍처 가이드라인 준수 등의 문제를 해결하기 위해 방대한 문서가 존재하지만, 이를 검색하고 숙지하는 데 많은 리소스가 소모됩니다. * 동료 전문가에게 직접 질문하는 방식은 질문자와 답변자 모두의 시간을 소모하므로, 자연어로 대량의 데이터를 검색할 수 있는 자동화된 구조가 필요합니다. * RAG 기법을 도입하면 AI 에이전트에게 신뢰할 수 있는 외부 지식을 제공하여, 환각 현상을 줄이고 보다 정확한 응답을 생성할 수 있습니다. ### ChromaDB와 Swift Evolution을 활용한 데이터 적재 * 오픈소스 벡터 DB인 ChromaDB를 활용하여 로컬 환경에서 파이썬 및 자바스크립트 라이브러리를 통해 데이터를 간단히 적재하는 시스템을 구축했습니다. * 약 500여 건의 Swift 언어 사양 제안 문서(Swift Evolution)를 예제로 사용하였으며, 이는 ID(SE-XXXX), 구현 상태, 작성자 등 정형화된 메타데이터를 포함하고 있어 RAG 실습에 적합합니다. * 워크숍에서는 로컬 DB를 구축하고 MCP(Model Context Protocol) 도구를 통해 Claude Code와 같은 코딩 에이전트가 DB를 참조하도록 구성했습니다. ### 에이전트 스킬을 통한 지능형 검색 최적화 * 단순히 MCP 도구만 연결하면 에이전트가 DB의 컬렉션 명이나 메타데이터 구조를 몰라 검색에 어려움을 겪을 수 있으므로, 이를 보완하기 위한 '에이전트 스킬'을 정의했습니다. * 스킬 내부에 "Swift Evolution 지식을 검색하려면 ChromaDB의 특정 컬렉션을 참조한다"는 지침과 메타데이터 활용법을 명시하여 에이전트의 컨텍스트를 강화했습니다. * 이를 통해 사용자가 "SE-0500에 대해 조사해줘"라는 짧은 명령어만 입력해도 에이전트가 스스로 최적의 검색 파라미터를 설정하여 정확한 정보를 찾아내게 됩니다. ### RAG 시스템의 확장과 실무 적용 * 구축된 시스템은 단순한 문서 검색을 넘어, 코딩 에이전트가 스스로 지식을 검색해 코드를 생성하거나 특정 규칙에 기반하여 코드 리뷰를 수행하는 등 고도화된 업무에 활용 가능합니다. * 워크숍에서는 참가자들이 직접 마크다운 문서를 DB에 적재하고 스킬을 작성하는 실습을 진행했으며, 결과물을 사내 클라우드(Flava)에 배포하여 공유하는 방법까지 포함했습니다. * 1,000명 이상의 직원이 참여한 이번 사례는 이론적인 개념 전달과 실제 업무 문서를 활용한 실습의 균형이 AI 도구 내재화에 얼마나 중요한지를 보여줍니다. 방대한 내부 문서를 보유한 조직이라면 ChromaDB와 같은 가벼운 벡터 DB와 MCP 기반의 에이전트 스킬을 결합해 보시기 바랍니다. 초기 구축 비용 대비 개발자가 정보를 찾는 시간을 획기적으로 단축할 수 있으며, 특히 사내 코딩 표준이나 복잡한 도메인 지식을 AI 에이전트에게 즉시 학습시키는 가장 효율적인 경로가 될 것입니다.

cloudflare원문

AI 검색: 에이전트를 위한 검색 프리미티브 (새 탭에서 열림)

Cloudflare가 출시한 **AI Search**(구 AutoRAG)는 AI 에이전트가 방대한 데이터에서 필요한 정보를 제때 찾을 수 있도록 돕는 플러그 앤 플레이 방식의 검색 기본 요소(primitive)입니다. 개발자가 벡터 인덱스 구축, 데이터 파싱, 청킹, 동기화 로직을 직접 구현할 필요 없이 에이전트별로 독립적인 검색 인스턴스를 동적으로 생성하고 관리할 수 있게 해줍니다. 이 서비스는 하이브리드 검색과 관리형 스토리지를 결합하여 복잡한 인프라 설정 없이도 고성능 RAG(검색 증강 생성) 시스템을 구축할 수 있는 환경을 제공합니다. ### 하이브리드 검색과 결과 통합 * 단일 쿼리로 시맨틱 매칭(벡터 검색)과 키워드 매칭(BM25)을 동시에 수행합니다. * 벡터 검색과 키워드 검색이 병렬로 실행되며, 두 결과를 지능적으로 결합하여 최적의 검색 순위를 도출합니다. * 현재 Cloudflare의 공식 블로그 검색 엔진에도 이 기술이 적용되어 실질적인 성능을 증명하고 있습니다. ### 관리형 스토리지와 동적 인스턴스 관리 * 각 검색 인스턴스는 R2 기반의 자체 스토리지와 Vectorize 인덱스를 내장하고 있어, 외부 데이터 소스 연결이나 버킷 설정 없이 API를 통해 파일을 직접 업로드하고 인덱싱할 수 있습니다. * `ai_search_namespaces` 바인딩을 통해 Worker 실행 중에 런타임에서 인스턴스를 동적으로 생성하거나 삭제할 수 있습니다. * 이를 통해 고객별, 언어별, 또는 에이전트별로 개별 검색 컨텍스트를 즉시 할당할 수 있어 멀티테넌시(Multi-tenancy) 환경 구축이 용이합니다. * 문서에 메타데이터를 첨부하여 쿼리 시 특정 필드(예: 타임스탬프)를 기준으로 가중치를 조절(Boosting)하거나, 한 번의 호출로 여러 인스턴스를 동시에 검색하는 기능을 지원합니다. ### 고객 지원 에이전트에서의 실전 활용 * 공통 제품 문서(Shared Docs)와 개별 고객의 과거 상담 이력(Per-customer History)을 분리하여 관리할 수 있습니다. * 새로운 고객이 유입될 때 `env.SUPPORT_KB.create()` 메서드를 호출하여 해당 고객 전용의 검색 인스턴스를 즉석에서 생성합니다. * 상담이 종료될 때마다 해결책 요약본을 해당 인스턴스에 저장함으로써, 에이전트가 과거의 실패한 해결책을 반복하지 않고 맥락에 맞는 답변을 하도록 유도합니다. * Agents SDK와 결합하여 LLM이 `search_knowledge_base` 같은 도구를 사용해 공통 지식과 개인화된 이력을 동시에 조회하고 판단할 수 있는 지능형 워크플로우를 구현합니다. 복잡한 검색 파이프라인 구축에 시간을 쏟는 대신 AI Search를 활용하면 에이전트의 핵심 로직과 사용자 경험에 더 집중할 수 있습니다. 특히 멀티테넌트 SaaS 환경이나 사용자별 장기 기억(Memory)이 필요한 에이전트를 개발 중이라면, Cloudflare의 AI Search와 Agents SDK를 결합하여 인프라 부담 없이 확장 가능한 시스템을 구축해 보기를 권장합니다.

microsoft원문

Microsoft Learn MCP 서버 구축기 (새 탭에서 열림)

Microsoft Learn MCP(Model Context Protocol) 서버는 AI 에이전트가 신뢰할 수 있는 최신 기술 문서를 실시간으로 활용할 수 있도록 설계된 원격 서버입니다. 기존의 복잡한 API 통합 방식 대신 표준화된 프로토콜을 채택하여 에이전트가 런타임에 도구를 스스로 발견하고 실행하게 함으로써, 개발자가 브라우저 이동 없이 개발 환경 내에서 정확한 기술 가이드를 받을 수 있도록 지원합니다. ### MCP 도입 배경과 서버 방식의 이점 * **에이전트 네이티브 표준:** MCP는 에이전트가 기능을 실시간으로 협상하고 결과를 스트리밍하는 표준을 제공하여, 수동 검색이나 별도의 임베딩 관리 없이도 최신 데이터를 활용할 수 있게 합니다. * **통합의 단순화:** 클라이언트가 개별 API의 인증, 요청 형식, 에러 처리를 직접 구현할 필요 없이 MCP 호환 에이전트라면 서버 연결만으로 도구 스키마를 자동 인식하고 사용할 수 있습니다. * **지식 서비스의 재사용:** "Ask Learn" 서비스와 동일한 벡터 저장소 및 지식 서비스를 백엔드로 사용하여, RAG(검색 증강 생성) 기반의 높은 정확도와 최신성을 보장합니다. ### 핵심 도구 및 아키텍처 * **제공 도구:** 문서 제목과 URL을 찾는 `microsoft_docs_search`, 전체 문서 내용을 가져오는 `microsoft_docs_fetch`, 언어별 코드 예제 검색에 최적화된 `microsoft_code_sample_search`를 제공합니다. * **시스템 구조:** Azure App Service에 호스트된 C# SDK 기반의 원격 서버로 운영되며, Streamable HTTP Transport를 통해 클라이언트와 통신합니다. * **에이전트 워크플로우 최적화:** LLM 에이전트가 익숙한 '검색 후 읽기' 패턴을 따를 수 있도록 내부 API의 복잡한 파라미터를 직관적인 도구 운영 방식으로 압축하여 제공합니다. ### 운영 및 설계상의 주요 교훈 * **도구 설명이 곧 사용자 경험:** AI 모델에게 도구와 파라미터 설명은 매뉴얼과 같습니다. 단어 선택의 미세한 차이가 도구 활성화율에 직접적인 영향을 미치므로 데이터 기반의 지속적인 최적화가 필요합니다. * **도구 조합의 시너지:** 검색 도구로 최적의 일치 항목을 찾은 후 전체 문서를 읽어 답변의 근거를 강화하는 '도구 조합' 방식을 명시적으로 가이드하여 인용 품질을 개선했습니다. * **분산 시스템으로서의 운영:** 공용 MCP 서버는 다중 지역 배포, 동적 확장, CORS 관리 등 일반적인 상태 비저장(Stateless) 서비스와 동일한 운영상의 복잡성을 가집니다. * **방어적 스키마 진화:** 동적 발견 구조임에도 불구하고 파라미터를 하드코딩하는 클라이언트를 위해, 명칭 변경 시 기존 이름을 병행 지원하는 유예 기간을 두는 등 안정적인 서비스 진화 전략이 중요합니다. ### 실용적인 활용 및 기대 효과 개발자는 이제 브라우저를 열고 검색 결과를 훑어보는 번거로운 과정 대신, 선호하는 AI 에이전트에 Learn MCP 서버를 연결하여 Microsoft 기술 문서를 코드 맥락에 즉시 적용할 수 있습니다. 이는 개발 워크플로우 내에서 정확한 공식 문서를 기반으로 한 자동화된 코딩 지원과 문제 해결을 가능하게 합니다.

aws원문

Amazon OpenSearch Service, GPU (새 탭에서 열림)

Amazon OpenSearch Service가 벡터 데이터베이스의 성능을 극대화하고 비용을 절감하기 위해 서버리스 GPU 가속 및 자동 최적화 기능을 도입했습니다. 이 기능을 통해 사용자는 수십억 건 규모의 벡터 인덱스를 기존보다 최대 10배 빠른 속도와 4분의 1 수준의 비용으로 구축할 수 있으며, 복잡한 수동 튜닝 없이도 최적의 검색 품질을 유지할 수 있습니다. 결과적으로 생성형 AI 애플리케이션 개발에 필요한 대규모 벡터 검색 환경을 훨씬 더 경제적이고 효율적으로 운영할 수 있게 되었습니다. **GPU 가속을 통한 대규모 벡터 데이터베이스 구축** * **성능 및 비용 혁신:** 비가속 환경 대비 인덱싱 속도는 10배 빨라진 반면, 관련 비용은 75%까지 절감되었습니다. 이를 통해 10억 개 규모의 벡터 데이터베이스를 1시간 이내에 생성할 수 있는 놀라운 확장성을 제공합니다. * **서버리스 관리 모델:** 사용자가 직접 GPU 인스턴스를 할당하거나 관리할 필요가 없으며, 실제 처리량에 따른 OCU(OpenSearch Compute Units) 단위로만 비용을 지불하면 됩니다. * **보안 및 통합:** 가속화된 작업은 사용자의 VPC(Amazon Virtual Private Cloud) 내에서 안전하게 격리되어 실행되며, 기존 OpenSearch 서비스의 워크플로우 내에서 자연스럽게 통합됩니다. **자동 최적화(Auto-optimization) 기반 성능 튜닝** * **자동화된 균형 탐색:** 벡터 데이터의 특성에 맞춰 검색 지연 시간, 검색 품질(재현율), 메모리 요구 사항 사이의 최적의 균형점을 시스템이 자동으로 찾아냅니다. * **전문성 장벽 완화:** 과거에는 벡터 인덱스 최적화에 몇 주간의 수동 튜닝과 전문 지식이 필요했으나, 이제는 설정 하나만으로 기본 구성보다 뛰어난 비용 효율성과 재현율을 확보할 수 있습니다. * **유연한 적용 범위:** 새 도메인이나 컬렉션을 생성할 때는 물론, 기존에 운영 중인 환경에서도 설정을 업데이트하여 즉시 최적화 기능을 활성화할 수 있습니다. **실제 적용 방법 및 권장 사항** 생성형 AI 애플리케이션이나 대규모 지식 베이스를 구축하려는 개발자는 AWS 콘솔의 '고급 기능' 섹션에서 GPU 가속을 활성화하는 것만으로 즉시 성능 향상을 경험할 수 있습니다. 기술적으로는 인덱스 설정 시 `index.knn.remote_index_build.enabled` 옵션을 `true`로 설정하여 GPU 기반의 원격 인덱스 빌드를 활성화할 것을 권장하며, 이를 통해 대량의 데이터를 벌크(Bulk) API로 처리할 때 최적의 가속 효과를 얻을 수 있습니다.

aws원문

확장성과 성능이 향상 (새 탭에서 열림)

Amazon S3 Vectors가 정식 출시(GA)되어 클라우드 객체 스토리지에서 기본적으로 벡터 데이터를 저장하고 검색할 수 있는 길이 열렸습니다. 기존 전용 벡터 데이터베이스 대비 비용을 최대 90% 절감할 수 있으며, 서버리스 아키텍처를 통해 인프라 관리 부담 없이 대규모 AI 애플리케이션을 구축할 수 있습니다. 이번 정식 버전은 프리뷰 대비 확장성과 성능이 대폭 강화되어, 대규모 RAG(검색 증강 생성) 및 AI 에이전트 워크로드를 안정적으로 지원합니다. **비약적인 확장성 및 성능 향상** * **인덱스 규모 확장:** 단일 인덱스에서 최대 20억 개의 벡터를 지원하며, 벡터 버킷당 총 20조 개의 벡터를 저장할 수 있어 프리뷰 대비 확장성이 40배 향상되었습니다. * **검색 속도 최적화:** 빈번한 쿼리의 경우 응답 속도를 100ms 이하로 단축했으며, 간헐적인 쿼리도 1초 미만의 지연 시간을 유지하여 실시간 대화형 AI에 적합합니다. * **검색 결과 확대:** 쿼리당 반환 가능한 검색 결과 수를 기존 30개에서 100개로 늘려 RAG 애플리케이션에 더 풍부한 컨텍스트를 제공합니다. * **쓰기 처리량 강화:** 초당 최대 1,000건의 PUT 트랜잭션을 지원하여 실시간 데이터 스트리밍 및 대량의 동시 쓰기 작업을 원활하게 처리합니다. **서버리스 아키텍처를 통한 운영 및 비용 효율화** * **완전 관리형 서비스:** 별도의 인프라 설정이나 프로비저닝이 필요 없는 서버리스 구조로, 사용한 만큼만 비용을 지불하는 종량제 모델을 채택했습니다. * **비용 절감:** 전용 벡터 데이터베이스 솔루션과 비교했을 때 벡터 저장 및 쿼리 비용을 최대 90%까지 낮출 수 있어 경제적입니다. * **개발 수명 주기 지원:** 초기 프로토타이핑부터 대규모 프로덕션 배포까지 동일한 스토리지 환경에서 유연하게 대응할 수 있습니다. **에코시스템 통합 및 가용성 확대** * **Amazon Bedrock 연동:** Amazon Bedrock 지식 기반(Knowledge Base)의 벡터 스토리지 엔진으로 정식 지원되어 고성능 RAG 어플리케이션 구축이 용이해졌습니다. * **Amazon OpenSearch 통합:** S3 Vectors를 스토리지 계층으로 사용하면서 OpenSearch의 강력한 검색 및 분석 기능을 결합하여 사용할 수 있습니다. * **지역 확장:** 프리뷰 당시 5개였던 지원 리전을 서울을 포함한 전 세계 14개 AWS 리전으로 확대하여 접근성을 높였습니다. 전용 벡터 DB 도입에 따른 비용과 운영 복잡성이 부담스러웠던 기업이라면, S3의 높은 가용성과 보안을 그대로 누리면서 대규모 벡터 검색을 구현할 수 있는 S3 Vectors 도입을 적극 검토해 보시기 바랍니다. 특히 Amazon Bedrock과의 유연한 통합을 통해 생산성 높은 AI 서비스를 빠르게 시장에 출시할 수 있습니다.

dropbox원문

Mobius Labs의 Aana 모델을 (새 탭에서 열림)

Dropbox는 최근 인수한 Mobius Labs의 멀티모달 AI 모델 'Aana'를 지능형 비서인 Dropbox Dash에 통합하여, 텍스트를 넘어 이미지와 비디오, 오디오를 깊이 있게 이해하는 검색 환경을 구축하고 있습니다. Aana는 기존 방식보다 훨씬 적은 연산 자원을 사용하면서도 다양한 미디어 간의 복잡한 관계를 분석하여, 사용자가 방대한 양의 멀티모달 콘텐츠에서 필요한 정보를 자연어 검색만으로 즉시 찾아낼 수 있게 돕습니다. 이를 통해 파편화된 미디어 데이터는 연결된 지식 자산으로 전환되며, 창의적인 협업과 업무 효율성을 극대화하는 기반이 마련되었습니다. **확장성을 고려한 멀티모달 분석 엔진** - 비디오와 오디오는 장면 전환, 화자 변경, 화면 내 텍스트, 동작 등 정보의 층위가 복잡하여 기존에는 검색과 정리가 매우 어려웠습니다. - Aana는 텍스트, 이미지, 오디오를 개별적으로 처리하는 대신, 이들이 서로 어떻게 상호작용하며 의미를 형성하는지 분석하는 통합적 접근 방식을 취합니다. - 모든 분석 정보는 '공유 벡터 공간(Shared Vector Space)'으로 변환되어, "발표자가 API 흐름을 설명하는 부분"과 같은 구체적인 맥락 기반의 검색을 가능하게 합니다. **효율적인 추론을 위한 기술적 아키텍처** - 오디오 분석에는 Whisper를 최적화한 `faster-whisper-large-v3-turbo` 모델을 사용하며, 시각 및 언어 시스템에는 트랜스포머 기반의 MoE(Mixture-of-Experts) 아키텍처를 적용했습니다. - **HQQ(High Quality Quantization) 시스템:** 4비트 및 8비트 저비트 추론을 지원하여 대규모 데이터 처리 시 발생하는 컴퓨팅 비용과 메모리 요구량을 획기적으로 낮췄습니다. - **Gemlite 기술:** 커스텀 GPU 커널을 통해 행렬 곱셈과 어텐션 레이어 같은 핵심 AI 연산을 가속화합니다. - **Aana SDK:** 모델 조정, 배치 처리, GPU 활용 최적화를 관리하는 유연한 프레임워크를 제공하여 복잡한 멀티모달 워크플로우를 효율적으로 배포할 수 있도록 지원합니다. **미디어 데이터를 지식으로 전환하는 미래 가치** - 전통적인 아키텍처의 극히 일부에 불과한 컴퓨팅 자원만으로도 엑사바이트(exabytes)급의 방대한 데이터를 분석할 수 있는 경제성을 확보했습니다. - 단순 검색을 넘어 회의 요약, 특정 시각적 모티프 탐색 등 멀티모달 데이터를 해석하고 자동으로 통찰을 제공하는 '에이전틱 워크플로우(Agentic workflows)'의 기반이 됩니다. - 마케팅, 크리에이티브, 기술 팀은 수년 치의 미디어 아카이브를 수동으로 뒤지는 대신, AI를 통해 즉각적인 답변을 얻고 아이디어를 실행에 옮길 수 있습니다. Dropbox Dash와 Aana의 결합은 사용자가 콘텐츠의 형식이나 위치에 구애받지 않고 업무의 맥락에 집중할 수 있게 합니다. 특히 영상 속 특정 장면을 찾기 위해 타임라인을 일일이 훑어야 했던 수고를 덜어줌으로써, 미디어 집약적인 업무를 수행하는 전문가들에게 실질적인 생산성 향상을 제공할 것으로 기대됩니다.

line원문

Milvus: LINE VOOM의 실시간 추천 시스템을 위한 대규모 벡터 DB 구축기 (새 탭에서 열림)

LINE VOOM은 기존 오프라인 배치 기반 추천 시스템의 한계인 콘텐츠 노출 지연 문제를 해결하기 위해 대규모 벡터 데이터베이스인 Milvus를 도입하여 실시간 추천 시스템을 구축했습니다. 이를 통해 신규 콘텐츠를 즉각적으로 추천 후보군에 반영할 수 있게 되었으며, 철저한 검증 과정을 거쳐 분산 환경에서의 안정성과 성능을 확보했습니다. ### 기존 시스템의 한계와 실시간 추천의 필요성 * 기존 시스템은 포스트 임베딩 생성과 유사도 검색 과정을 일 단위 오프라인 배치로 처리하여, 신규 콘텐츠가 추천되기까지 최대 하루의 시간이 소요되었습니다. * 새해 인사나 스포츠 경기 하이라이트처럼 즉시성이 중요한 '신선한 콘텐츠'가 사용자에게 바로 전달되지 못해 사용자 경험이 저하되는 문제가 있었습니다. * 이를 해결하기 위해 오프라인 저장소를 온라인으로 전환하고, 중간 과정 없이 실시간으로 유사성 검색을 수행할 수 있는 시스템 구조로 개편했습니다. ### 벡터 DB 선정 배경과 Milvus 채택 이유 * 벡터 전용 DB, 오픈소스, 온프레미스 구축 가능성, 고부하 환경에서의 저지연 성능을 핵심 기준으로 삼아 Milvus와 Qdrant를 비교했습니다. * Milvus는 Qdrant 대비 높은 QPS(Query Per Second)와 낮은 지연 시간을 보였으며, 스토리지와 컴퓨팅이 분리된 아키텍처를 통해 더 높은 안정성을 제공했습니다. * 10가지 이상의 다양한 인메모리 인덱스 유형을 지원하여 시나리오별 최적화가 용이하고, 활발한 커뮤니티를 통해 기술적 이슈 대응이 빠르다는 점을 높게 평가했습니다. ### 카오스 테스트를 통한 장애 시나리오 식별 * 분산 환경에서의 안정성을 검증하기 위해 파드 킬(Pod Kill), 스케일 인/아웃 등 고의적인 장애를 주입하는 카오스 테스트를 수행했습니다. * 테스트 결과, 쿼리 코디네이터(Querycoord)나 Etcd 장애 시 컬렉션이 릴리스되거나 메타데이터가 손실되어 검색이 불가능해지는 심각한 결함을 사전에 발견했습니다. * 또한 특정 코디네이터 노드가 단일 실패 지점(SPOF)이 되어 전체 시스템에 영향을 줄 수 있음을 확인했습니다. ### 시스템 안정성 강화를 위한 고가용성 설계 * **컬렉션 고가용성(HA) 구성**: 두 개의 컬렉션에 임베딩을 이중으로 기록(Dual-writing)하고, 장애 발생 시 클라이언트 단에서 별칭(Alias)을 즉시 교체하여 사본 컬렉션을 참조하도록 구현했습니다. * **코디네이터 고가용성 구성**: 단일 파드로 작동하여 장애에 취약한 코디네이터 노드들을 액티브-스탠바이(Active-Standby) 모드로 설정했습니다. * 이를 통해 인덱스 코디네이터 등이 중단되더라도 대기 중인 노드가 즉시 역할을 이어받아 인덱스 생성 실패 및 서비스 중단을 예방할 수 있는 구조를 갖추었습니다. 대규모 실시간 추천 환경에서 벡터 DB를 성공적으로 운영하려면 단순히 검색 성능만 고려하는 것이 아니라, 구성 요소별 장애 시나리오를 면밀히 분석하고 컬렉션 이중화 및 코디네이터 고가용성 설계를 통해 복원력을 확보하는 것이 매우 중요합니다.

line원문

문의 대응을 효율화하기 위한 RAG 기반 봇 도입하기 (새 탭에서 열림)

LY 주식회사의 SR(Service Reliability) 팀은 반복되는 AWX 플랫폼 관련 문의를 효율적으로 처리하기 위해 RAG(검색 증강 생성) 기반의 지원 봇을 도입했습니다. 이 시스템은 사용자가 방대한 가이드 문서를 읽지 않고 중복된 질문을 던질 때 발생하는 운영 리소스 소모 문제를 해결하기 위해 고안되었습니다. 사내 위키와 과거 상담 이력을 활용해 정확도 높은 답변을 생성함으로써 관리자의 개입 없이도 사용자 문제를 신속하게 해결하는 성과를 거두었습니다. **AWX 지원 봇의 기술 스택 및 구성** - **LLM 및 프레임워크:** OpenAI의 GPT 모델을 메인 엔진으로 사용하며, LangChain 프레임워크를 통해 전체적인 워크플로를 관리합니다. Slack과의 연동은 Bolt for Python을 활용했습니다. - **임베딩 모델:** 다국어 지원 및 문장 비교 성능이 뛰어난 'paraphrase-multilingual-mpnet-base-v2' 모델(SBERT)을 선택하여 글로벌 임직원의 다양한 언어 문의에 대응합니다. - **벡터 데이터베이스:** 사내에서 PaaS 형태로 제공되어 접근성이 높은 OpenSearch를 사용하며, 텍스트 데이터를 고차원 벡터로 변환하여 저장하고 검색합니다. **RAG 및 벡터 검색을 통한 답변 정확도 향상** - **LLM의 한계 극복:** 학습되지 않은 최신 정보 부재나 허위 정보 생성(Hallucination) 문제를 해결하기 위해, 질문과 관련된 신뢰할 수 있는 컨텍스트를 LLM에 함께 전달하는 RAG 기법을 적용했습니다. - **벡터 검색 원리:** 사용자의 질문을 임베딩하여 벡터화한 뒤, 벡터 DB 내에서 의미적으로 유사한 문장들을 k-NN(최근접 이웃) 방식으로 검색하여 최적의 참고 자료를 추출합니다. - **유사도 기반 추출:** 단순 키워드 매칭이 아닌 의미적 유사성을 판단하므로, 'Buy'와 'Purchase'처럼 단어는 달라도 맥락이 같은 정보를 정확히 찾아낼 수 있습니다. **봇 워크플로 및 데이터 활용 전략** - **사용자 상호작용:** 사용자가 Slack으로 문의하면 봇이 사내 위키와 과거 Slack 스레드 데이터를 검색합니다. 추출된 데이터를 바탕으로 LLM이 1차 답변을 제공하며, 해결되지 않을 경우에만 '관리자 호출' 버튼을 통해 담당자를 연결합니다. - **데이터 소스 다각화:** 공식 가이드 문서뿐만 아니라 실제 사용자들이 겪었던 문제와 해결책이 담긴 'Slack 문의 스레드 데이터'를 함께 인덱싱하여 실무적인 답변이 가능하도록 구성했습니다. - **리소스 최적화:** 봇의 자동 응답을 통해 단순 반복 문의에 대한 관리자의 수동 대응 시간을 줄이고, 개발 조직이 서비스 운영 본연의 업무에 더 집중할 수 있는 환경을 조성했습니다. RAG 기반 시스템을 구축할 때 가장 중요한 것은 신뢰할 수 있는 데이터 소스의 확보입니다. LY의 사례처럼 공식 문서와 실제 상담 이력을 병행 활용하면 LLM이 훨씬 구체적이고 실무에 유효한 답변을 생성할 수 있습니다. 운영 중인 서비스의 문의 대응 리소스가 부담된다면, 익숙한 벡터 DB와 오픈소스 임베딩 모델을 조합한 RAG 봇 도입을 적극 추천합니다.

figma4분 읽기큐레이션 요약

피그마 AI 검색의

Figma의 AI 검색은 텍스트·이미지·레이어 선택을 동일한 임베딩 공간에서 비교해 디자인과 컴포넌트를 의미적으로 찾도록 구축됐다. 핵심 기반은 CLIP 멀티모달 임베딩 모델과 벡터 검색 인덱스이며, 수십억 개의 임베딩을 생성·관리하면서도 비용과 처리량을 고려한 인프라 설계가 필요했다. 특히 파일 내부의 검색 가능한 프레임을 식별하고 썸네일과 임베딩을 비동기적으로 생성하는 과정이 주요 기술 과제였다. ## AI 검색이 해결하는 문제 - **디자인 검색** - 조직이나 팀 전체의 Figma 파일에 포함된 프레임을 검색한다. - 파일명이나 레이어 이름이 없어도 프레임의 시각적 내용으로 찾을 수 있다. - 텍스트 설명, 스크린샷, 선택한 Figma 레이어를 검색 입력으로 사용할 수 있다. - 선택 영역은 새 스크린샷으로 렌더링한 뒤 이미지 검색과 같은 경로로 처리한다. - **컴포넌트 검색** - 기존 Assets 검색의 엄격한 텍스트 일치 방식을 의미 기반 검색으로 확장했다. - 예를 들어 이름이 😀인 컴포넌트를 “smiley”, “happy”, “face”, “grin” 같은 표현으로도 찾을 수 있다. - 컴포넌트 이름과 설명에 검색 키워드를 일일이 추가하는 SEO 작업이 필요 없다. - 컴포넌트 역시 스크린샷이나 레이어 선택을 이용해 시각적으로 검색할 수 있다. ## CLIP 기반 멀티모달 임베딩 - 임베딩 모델은 텍스트나 이미지를 의미를 보존한 숫자 배열로 변환한다. - Figma는 현재 오픈소스 **CLIP** 모델을 사용한다. - CLIP은 이미지와 텍스트를 같은 벡터 공간에 표현한다. - 고양이 이미지의 임베딩과 `"cat"`이라는 텍스트의 임베딩이 서로 가까운 위치에 놓인다. - 따라서 이미지와 텍스트를 서로 다른 입력 방식으로 검색해도 의미적으로 비교할 수 있다. - 모델은 고객의 비공개 Figma 파일이나 고객 데이터를 학습에 사용하지 않았다. - 공개된 무료 Community 파일의 UI 이미지로 미세 조정했다. - 초기에는 선택 영역을 JSON 같은 텍스트 표현으로 변환해 임베딩하는 방식도 검토했다. - 그러나 이미지로 임베딩을 생성하는 방식이 더 나은 검색 결과를 제공했다. - 스크린샷 검색과 동일한 처리 경로를 사용할 수 있다는 장점도 있었다. ## 벡터 검색 처리 방식 - 검색 대상 콘텐츠마다 임베딩을 생성해 벡터 검색 인덱스에 저장한다. - 예: 디자인 시스템의 모든 컴포넌트와 각 컴포넌트의 임베딩 - 사용자가 검색하면 입력을 먼저 임베딩으로 변환한다. - 텍스트 검색은 입력 문장을 임베딩 모델에 전달한다. - 스크린샷 검색은 이미지에서 임베딩을 생성한다. - 레이어 선택 검색은 선택 영역을 스크린샷으로 만든 뒤 임베딩한다. - 생성된 쿼리 임베딩과 인덱스의 임베딩 사이 거리를 계산해 가장 가까운 항목을 반환한다. - 전통적인 문자열 검색처럼 검색어와 색인 항목을 직접 비교하는 것이 아니라, 고차원 벡터 공간에서 최근접 이웃을 찾는다. ## 검색 가능한 프레임 식별 - Figma 파일 깊숙한 곳에 있는 모든 검색 대상 프레임을 찾아야 한다. - 각 프레임에 대해 다음 작업을 수행한다. - Figma 레이어를 렌더링해 썸네일을 생성한다. - 썸네일에서 임베딩을 생성한다. - 메타데이터와 임베딩을 검색 인덱스에 기록한다. - 게시되지 않은 프레임은 일반적인 방식으로 쉽게 열거할 수 없다는 문제가 있다. - 이를 해결하기 위해 비동기 작업에서 서버 측 C++ Figma 에디터를 헤드리스 방식으로 실행한다. - 서버에서 C++ 에디터를 실행하기 위해 별도의 샌드박싱 기술을 사용한다. ## 저장소와 인프라 선택 - Figma는 자체 RDS 클러스터도 운영하지만, AI 검색에는 DynamoDB를 사용한다. - AI 검색의 저장 요구사항이 복잡한 관계형 트랜잭션보다 단순한 키-값 저장에 가깝기 때문이다. - 주요 요구사항은 다음과 같다. - 임베딩과 관련 메타데이터의 대량 저장 - 높은 쓰기 처리량 - 검색 시 빠른 읽기 - 대규모 인덱스 생성 및 갱신 처리 - 전체 시스템은 수십억 개의 임베딩을 생성하고 색인해야 하므로 검색 품질뿐 아니라 생성 비용과 운영 비용도 중요한 설계 기준이 된다. Figma의 접근 방식은 이미지와 텍스트를 하나의 의미 공간에 매핑하고, 프레임·컴포넌트별 임베딩을 사전에 구축하는 것이다. 유사한 기능을 구현한다면 먼저 검색 대상을 안정적으로 열거하고, 렌더링·임베딩 생성·색인 갱신을 비동기 파이프라인으로 분리하며, 모델 학습 데이터와 고객 데이터의 경계를 명확히 관리하는 것이 중요하다.

원문 읽기(새 탭에서 열림)