cloudflare2026년 8월 6일

Cloudflare AI 검색: 에이전트에게 데이터 검색 엔진을 제공하세요 (새 탭에서 열림)

Cloudflare AI Search는 Workers AI, AI Gateway, Vectorize, R2, Browser Run 등을 직접 조합하지 않아도 에이전트용 검색 엔진을 구축할 수 있도록 개발자 경험을 개선했다. 웹사이트와 파일을 쉽게 색인하고, 여러 데이터 소스를 하나의 검색 엔드포인트나 MCP 엔드포인트로 통합할 수 있으며, 임베딩과 재순위화 비용은 일부 기본 모델 사용 시 무료다. Cloudflare는 이를 자사 문서·블로그·개발자 생태계 검색과 Dev Stack MCP에 실제로 적용하고 있다. ### 에이전트용 데이터 색인 - 구조화·비구조화 데이터를 AI 에이전트가 검색할 수 있도록 색인한다. - 개별 파일뿐 아니라 소유권을 확인할 수 있는 웹사이트도 데이터 소스로 사용할 수 있다. - AI Search가 웹 크롤링, 데이터 수집, 임베딩, 검색 결과 반환 과정을 처리한다. - 현재는 Cloudflare 계정에 등록된 zone이어야 하며, 향후 소유권 확인 방식이 확대될 예정이다. ### 사이트맵 없이 웹사이트 검색 구축 - 기존에는 웹사이트 연동에 sitemap이 필요했다. - 이제 `Discover` 파싱 옵션을 사용하면 sitemap이 없는 사이트도 링크를 따라가며 페이지를 발견하고 색인할 수 있다. - 내부적으로 Browser Run의 `/crawl` 기능을 활용해 페이지를 탐색한다. - Wrangler 명령어 예시는 다음과 같다. ```bash npx wrangler ai-search instance create cloudflare-community \ --namespace dev-stack \ --source https://community.cloudflare.com \ --type web-crawler \ --parse-type discover ``` ### 여러 검색 인스턴스를 하나로 통합 - 하나의 namespace 안에 여러 웹사이트나 데이터 인스턴스를 구성할 수 있다. - `/search`와 `/mcp` 공개 엔드포인트를 활성화하면 여러 인스턴스를 한 번에 검색할 수 있다. - 별도 Worker를 작성하지 않고도 여러 소스를 대상으로 통합 검색을 제공할 수 있다. - 검색 결과에는 출처 인스턴스 정보와 인용 가능한 청크가 포함된다. ### Worker와 MCP를 통한 검색 연동 - 기존 애플리케이션이나 MCP 서버에 검색 기능을 포함하려면 namespace를 Worker에 바인딩한다. - Worker에서는 `AI_SEARCH.search()`를 호출하고, `instance_ids`로 검색 대상들을 지정한다. - `max_num_results`로 결과 수를 제한하고 `reranking.enabled`로 재순위화를 활성화할 수 있다. - Cloudflare Dev Stack MCP는 이 방식을 사용해 Docs, Blog, API Docs, Community, Astro, Vite, Vitest, Hono, Replicate, OpenNext 등 여러 표면을 한 번에 검색한다. ```json { "ai_search_namespaces": [ { "binding": "AI_SEARCH", "namespace": "cloudflare-stack" } ] } ``` - 간단히 공유 가능한 검색 URL만 필요하다면 Worker 대신 공개 엔드포인트를 활성화하면 된다. ### 공개 엔드포인트와 사용자 도메인 - namespace에 공개 URL을 활성화하면 다음 엔드포인트가 제공된다. - `/search`: 일반 검색 API - `/mcp`: MCP 클라이언트와 에이전트 연동용 엔드포인트 - 기본 공개 URL 대신 `search.example.com/mcp`처럼 사용자 정의 도메인을 연결할 수 있다. - Cloudflare Access를 도메인 앞에 배치하면 공개 엔드포인트를 인증 기반의 비공개 검색 서비스로 전환할 수 있다. ### 예측 가능한 가격 모델 - AI Search는 임베딩 및 재순위화 비용을 포함하는 방향으로 가격 모델을 설계했다. - Workers AI 카탈로그의 일부 기본 모델을 사용하면 임베딩과 재순위화가 무료다. - 토큰 수를 직접 계산해 비용을 예측해야 하는 부담을 줄이고, 데이터 규모가 커져도 비용을 예측하기 쉽게 만드는 것이 목표다. - 가격은 현재 프리뷰 단계다. ### EmDash와 Cloudflare 서비스에 적용 - Cloudflare의 오픈소스 CMS인 EmDash에는 AI Search 플러그인을 추가할 수 있다. - 이 플러그인은 EmDash로 구축한 사이트 콘텐츠에 의미 기반 검색을 제공한다. - Cloudflare는 AI Search를 Blog, Developer Docs, Cloudflare.com, EmDash 기반 사이트 등에 실제 검색 기능으로 사용하고 있다. ### Cloudflare Dev Stack MCP 사례 - Dev Stack MCP는 Cloudflare 개발자 생태계 전체에서 최신 문서를 검색해 코딩 에이전트에 제공한다. - 검색 결과에 출처와 인용 정보가 포함되어 최신 기능과 수정 사항을 반영할 수 있다. - 기존처럼 웹 검색 후 여러 페이지를 직접 가져오는 방식보다 빠르고, 토큰 사용량이 적으며, 오래되거나 부정확한 문서를 선택할 가능성이 낮다. - MCP 설정에 다음 URL을 추가하면 에이전트에서 사용할 수 있다. ```json { "mcpServers": { "dev-stack": { "url": "https://stack.mcp.cloudflare.com/mcp" } } } ``` Cloudflare AI Search는 여러 Cloudflare 서비스를 직접 연결해야 했던 검색 구축 과정을 단순화하고, 웹사이트·문서·MCP를 하나의 검색 계층으로 묶는 데 초점을 둔다. 기존 애플리케이션에 통합하려면 Worker 방식을, 빠르게 공유 가능한 검색 기능이 필요하면 공개 `/search` 또는 `/mcp` 엔드포인트를 선택하는 것이 적합하다.

semantic-searchcloudflare-workersmcpembeddings+4

aws2026년 8월 5일

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처럼 벡터 검색 결과와 가격·재고·카테고리 같은 운영 속성을 함께 사용해야 하는 경우 구조 단순화와 운영 비용 절감에 유리합니다.

semantic-searchragserverlessvector-db+2

toss2026년 7월 30일

LLM은 똑똑한데, 왜 우리 회사 일은 모를까 (새 탭에서 열림)

LLM이 사내 질문에 정확히 답하려면 단순히 관련 문서를 검색하는 것만으로는 부족하다. 문서·코드·메신저의 최신성, 상충 여부, 실제 구현과의 일치 여부까지 관리하는 신뢰 가능한 컨텍스트 계층이 필요하며, Topic은 이를 구축하기 위한 시스템이다. Topic은 원본을 의미 단위로 정규화하고, 개념과 관계를 연결한 뒤, 변경된 부분만 선택적으로 검증한다. ## 검색만으로는 신뢰를 보장할 수 없는 이유 - 검색은 질문과 관련된 텍스트를 찾아줄 뿐, 해당 정보가 최종 결정인지 판단하지 못한다. - 문서, 미팅, 코드가 서로 다른 정책을 설명할 수 있다. - 메신저 논의가 실제 결론인지, 문서가 오래된 것인지, 코드 변경이 의도된 것인지 추가 판단이 필요하다. - 에이전트가 각자 원문을 검색하면 자료 선택과 충돌 해석이 달라져 답변 일관성이 떨어진다. - Topic은 출처, 관계, 최신성, 충돌 상태를 공통 계층에서 관리해 사람과 LLM이 같은 근거를 사용하도록 한다. ## 신뢰를 구성하는 여섯 가지 축 - **Granularity**: 독립적으로 관리할 수 있는 적절한 크기와 의미의 컨텍스트인지 판단한다. - **Faithfulness**: 컨텍스트의 주장이나 설명이 원문 근거로 뒷받침되는지 확인한다. - **Staleness**: 정보가 현재도 유효한지 검사한다. - **Canonicality**: 서로 다른 이름이나 표현이 같은 대상을 가리키는지 판단한다. - **Consistency**: 여러 출처의 내용이 서로 양립하는지 확인한다. - **Coverage**: 중요한 근거와 관점이 누락되지 않았는지 살핀다. - 모든 문제를 하나의 신뢰도 점수로 합치지 않고, 규칙·LLM·사람 검토를 각각 적합한 판단에 사용한다. ## Ingest: 출처별 의미 단위를 보존한 정규화 Topic은 문서·코드·메신저의 원본을 공통 `ContentUnit`으로 변환한다. - 주요 필드: - `source_type`: document, code, messenger - `unit_type`: 문서 섹션, 메신저 스레드 등 - `source_uri`: 원문으로 돌아가는 주소 - `content_hash`: 변경 감지용 해시 - `created_at_src`, `updated_at_src` - 출처별 식별자와 구조를 담은 `metadata` - 공통 형식은 후속 추출·검증을 일관되게 만든다. - 출처별 구조는 의미 경계와 증거의 원천을 보존하기 위해 유지한다. ### 문서는 제목 계층 단위로 분할 - Markdown 문서를 고정 길이가 아니라 제목 구조에 따라 나눈다. - 상위 제목 경로를 함께 저장해 문장이 어떤 정책이나 기능에 속하는지 보존한다. - 섹션이 지나치게 긴 경우에만 추가 분할한다. - 문서 경로, 원문 URL, 작성·수정 시각도 검증 정보로 남긴다. ### 메신저는 개별 메시지보다 스레드 단위로 처리 - 메시지 하나만 보면 질문인지 결론인지 알기 어렵기 때문에 스레드 전체를 하나의 의미 단위로 삼는다. - 요약 시: - 함수명, 에러 클래스, 파일 경로 등 기술 식별자를 원문 그대로 보존한다. - 질문, 검토한 선택지, 최종 결과를 구분한다. - 확정된 내용과 미결정 내용을 나눈다. - 대화에 없는 합의를 만들어내지 않는다. - 잡담만 있는 스레드는 컨텍스트로 만들지 않는다. ### 코드는 심볼과 비즈니스 동작을 함께 표현 - 파서로 함수·클래스 등 코드 심볼을 추출한다. - 파일 경로, 심볼 종류, 시작·종료 줄, import 관계는 규칙 기반으로 수집한다. - 여러 심볼을 가로지르는 업무 동작은 `CodeSemanticCard`로 묶는다. - semantic card에는 다음 정보가 포함된다. - 업무 대상과 실제 동작 - 도메인 용어와 코드 식별자 - 저장소·파일·줄·심볼 단위의 근거 span - 기준이 된 `commit_sha` - LLM이 만든 카드는 파일·줄이 실제 존재하는지, 설명을 뒷받침하는 span이 있는지 규칙 기반으로 재검사한다. - 최종 검증에서는 카드의 설명만 믿지 않고 현재 코드의 실제 span을 다시 읽는다. ## Extract: 개념과 관계를 원문 근거와 연결 - 각 `ContentUnit`에서 개념 후보와 이를 뒷받침하는 문장을 추출한다. - 함께 등장한 후보를 중심으로 관계를 제안하고, 표현·의미가 유사한 후보의 중복 가능성을 계산한다. - 충분한 근거가 있을 때만 대표 개념으로 통합한다. - 문서·메신저·코드처럼 출처가 다른 unit 사이에도 연결 후보를 만든다. - 개념과 관계에는 원문 위치, 인용, 판단 상태를 함께 저장한다. ### 사내 용어는 사람 검토를 포함 - 띄어쓰기·대소문자 차이는 정규화와 임베딩으로 자동 탐지할 수 있다. - 사내 약어와 별칭은 잘못 합치면 검색·검증 전체를 오염시킬 수 있다. - 애매한 동의어는 즉시 병합하지 않고 `Synonym Proposal`로 등록한다. - 사람이 승인한 별칭만 관리되는 관계로 반영하며, 거절된 후보는 반복 제안하지 않는다. ### 문서와 코드 관계를 유형별로 구분 - `supported_by`: 코드가 문서의 설명을 뒷받침한다. - `contradicted_by`: 코드와 문서의 동작이 충돌한다. - `mentions`: 같은 기능을 언급하지만 일치·충돌 여부를 판단할 근거가 부족하다. - 임베딩으로 후보를 제한한 뒤, 의미 판단이 필요한 후보만 배치 검증한다. - 관계에는 유형뿐 아니라 신뢰도, 판단 이유, 원문 인용, 검증 상태를 기록한다. - 검증 실패나 낮은 신뢰도는 관계를 저장하지 않는다. 관계가 없다는 것은 무관하다는 뜻이 아니라 아직 확인되지 않았다는 의미다. ## Verify: 변경된 부분만 선택적으로 재검증 - 각 unit의 안정적인 식별자와 `content_hash`를 이용해 변경 범위를 추적한다. - 변경되지 않은 unit의 추출·관계 결과는 재사용한다. - 새로 생성되거나 변경된 unit만 다시 처리한다. - 원본이 삭제되면 해당 원본을 참조하던 관계도 정리한다. - 코드 anchor에는 검증 당시의 commit과 span hash를 저장한다. - 현재 코드에서 anchor가 사라졌으면 orphaned 상태로 표시한다. - anchor의 span hash가 같으면 의미 검증을 생략한다. - span hash가 달라졌으면 변경된 코드에 대해 faithfulness를 다시 검증한다. - 해시와 참조 무결성은 규칙 기반으로 검사하고, 실제 의미가 달라진 경우에만 LLM을 호출한다. - 이 방식은 비용을 줄이면서도 변경 원인과 컨텍스트 상태 변화를 추적하게 해준다. ## 실용적인 결론 사내 LLM의 품질을 높이려면 검색 성능만 개선하기보다, 의미 단위·원문 근거·출처 간 관계·최신성·충돌 상태를 함께 관리해야 한다. 특히 자동화는 명확한 변경 감지와 관계 추출에 사용하고, 사내 용어 통합이나 중요한 정책 판단처럼 맥락 의존적인 문제는 근거를 제시한 뒤 사람의 승인을 받는 방식이 안전하다.

semantic-searchllmhuman-in-the-loopknowledge-graph+4

meta2026년 4월 21일

커뮤니티 지식의 힘을 활용하기 위한 페이스북 그룹 검색 현대화 (새 탭에서 열림)

페이스북은 커뮤니티 내 방대한 정보를 사용자가 더 쉽고 정확하게 찾을 수 있도록 그룹 검색 시스템을 하이브리드 검색 아키텍처로 전면 개편했습니다. 기존의 단순 키워드 매칭 방식에서 벗어나 의미론적 이해를 더한 결과, 검색 정확도와 사용자 참여도가 크게 향상되었으며 오류율은 안정적으로 유지되었습니다. 특히 Llama 3를 활용한 자동화된 모델 기반 평가 시스템을 도입함으로써, 대규모 데이터 환경에서도 고도화된 품질 관리가 가능해졌습니다. ### 기존 커뮤니티 검색의 세 가지 마찰 지점 * **발견의 한계(Discovery):** 과거의 어휘 기반 검색은 정확한 키워드가 일치해야만 결과를 반환했습니다. 예를 들어 사용자가 '프로스팅을 얹은 작은 케이크'를 검색할 때, 게시물에 '컵케이크'라는 단어만 있다면 검색 결과에 노출되지 않는 언어적 간극이 존재했습니다. * **소비의 피로도(Consumption):** 사용자가 원하는 답을 얻기 위해 수많은 댓글을 일일이 읽고 합의된 의견을 찾아내야 하는 '노력의 세금(Effort Tax)' 문제가 발생했습니다. * **검증의 어려움(Validation):** 중고 거래나 전문적인 결정이 필요한 상황에서 커뮤니티의 집단 지성을 활용하고 싶어도, 흩어져 있는 전문 지식과 검증된 조언을 체계적으로 수집하기가 쉽지 않았습니다. ### 현대적인 하이브리드 검색 아키텍처 * **병렬 검색 전략:** 쿼리가 들어오면 토큰화 및 정규화를 거친 후, 어휘적 경로와 의미론적 경로라는 두 가지 파이프라인을 동시에 가동합니다. * **어휘적 경로 (Unicorn):** 페이스북의 역색인(Inverted Index) 시스템인 Unicorn을 사용해 고유 명사나 특정 문구가 포함된 게시물을 정확하게 찾아냅니다. * **의미론적 경로 (SSR):** 12레이어, 2억 개의 파라미터를 가진 검색 의미론적 리트리버(SSR) 모델이 쿼리를 벡터로 변환합니다. 이후 Faiss 벡터 인덱스에서 근사 최근접 이웃(ANN) 검색을 수행하여, 키워드가 겹치지 않더라도 개념적으로 유사한 콘텐츠를 추출합니다. ### MTML 아키텍처 기반의 L2 랭킹 * **특징 통합:** 검색 단계에서 수집된 후보군들을 대상으로 TF-IDF, BM25와 같은 어휘적 점수와 코사인 유사도 같은 의미론적 점수를 통합하여 분석합니다. * **다중 작업 다중 레이블(MTML) 모델:** 단일 목표가 아닌 클릭, 공유, 댓글 등 여러 사용자 참여 지표를 동시에 최적화하는 슈퍼모델 구조를 채택했습니다. 이를 통해 단순히 관련성만 높은 글이 아니라, 실제 커뮤니티에서 의미 있는 상호작용을 이끌어낼 수 있는 양질의 콘텐츠를 상위에 노출합니다. ### Llama 3 기반 자동화 평가 * **LLM 판독관 도입:** 고차원 벡터 공간에서의 검색 품질을 사람이 일일이 검증하기 어려운 한계를 극복하기 위해, Llama 3를 빌드 검증 테스트(BVT) 과정에 통합했습니다. * **정교한 품질 측정:** 검색 결과를 단순히 '좋음/나쁨'으로 나누지 않고, 주제나 도메인이 일치하는 '다소 관련 있음' 등의 세분화된 범주를 두어 검색 결과의 다양성과 미세한 관련성 개선 수치를 측정합니다. --- **실용적 제언** 방대한 커뮤니티 데이터를 다루는 서비스라면 단순 키워드 검색만으로는 사용자의 자연어 의도를 충족하기 어렵습니다. 페이스북의 사례처럼 정확도를 보장하는 **어휘적 검색**과 맥락을 파악하는 **의미론적 검색**을 병렬로 운영하고, 랭킹 단계에서 **사용자 반응 데이터(클릭, 공유 등)**를 다각도로 결합하는 하이브리드 전략이 검색 만족도를 높이는 핵심입니다. 또한, LLM을 평가 도구로 활용하면 수동 라벨링 비용을 줄이면서도 정교한 품질 관리가 가능해집니다.

semantic-searchdatabase-designmachine-learningnlp+4

dropbox2025년 11월 17일

Dash가 더 스마트한 AI를 위해 (새 탭에서 열림)

Dropbox Dash는 단순한 검색 시스템을 넘어 사용자의 의도를 이해하고 실행하는 에이전트형 AI로 진화하면서, 모델에 제공되는 정보를 정교하게 관리하는 '컨텍스트 엔지니어링'을 핵심 전략으로 채택했습니다. 단순히 많은 정보를 제공하는 것이 아니라 모델이 추론하고 행동하는 데 꼭 필요한 정보만을 선별하여 전달함으로써, AI의 '분석 마비' 현상과 토큰 낭비를 방지했습니다. 결과적으로 이러한 전략적 컨텍스트 관리는 모델의 판단 속도와 작업 정확도를 동시에 높이는 성과를 거두었습니다. ### 도구 정의의 최소화와 통합 인터페이스 구축 * 모델에게 너무 많은 API 호출 선택지를 주면 판단 속도가 느려지고 정확도가 떨어지는 현상이 발생했습니다. 이를 해결하기 위해 개별 서비스(Confluence, Jira, Google Docs 등)의 검색 도구를 하나로 묶은 '유니버설 검색 인덱스' 기반의 단일 도구를 구축했습니다. * Model Context Protocol(MCP)을 활용하여 도구 설명을 간결하게 유지함으로써, 모델의 컨텍스트 창(Context Window)이 사용자 요청이라는 본연의 목적에 더 많이 할애되도록 설계했습니다. * 하나의 일관된 인터페이스를 통해 정보를 검색하게 함으로써 모델의 계획 수립 과정을 단순화하고 효율성을 극대화했습니다. ### 지식 그래프를 통한 맥락적 데이터 필터링 * 단순히 여러 API에서 데이터를 가져오는 것에 그치지 않고, 검색된 결과 중 가장 관련성 높은 정보만 모델에 전달되도록 필터링 시스템을 강화했습니다. * 통합 인덱스 위에 사람, 활동, 콘텐츠 간의 관계를 연결한 '지식 그래프'를 구축하여 사용자별 맞춤형 순위 산출이 가능하게 했습니다. * 모델이 런타임에 방대한 정보를 직접 분석하는 대신, 이미 관계가 정립된 고가치 정보만 수신함으로써 추론의 질을 높이고 성능 저하를 방지했습니다. ### 복잡한 작업을 위한 전담 에이전트 도입 * 검색 쿼리 생성과 같이 복잡한 지침과 예시가 필요한 작업은 메인 모델의 컨텍스트 창을 과도하게 점유하는 문제를 일으켰습니다. * 이를 해결하기 위해 메인 에이전트는 전체적인 계획만 세우고, 구체적인 쿼리 작성은 별도의 '전담 에이전트'에게 위임하는 구조를 도입했습니다. * 역할 분담을 통해 메인 모델은 복잡한 세부 사항에 매몰되지 않고 전체 작업의 흐름에 집중할 수 있으며, 각 에이전트는 자신에게 할당된 컨텍스트 내에서 최적의 결과를 도출합니다. 효과적인 에이전트형 AI를 구축하기 위해서는 무조건 많은 데이터를 입력하기보다 모델이 처리해야 할 정보의 양과 질을 전략적으로 제어해야 합니다. 도구의 통합, 지식 그래프 기반의 정교한 필터링, 그리고 전문 에이전트로의 역할 분담은 성능 향상과 비용 절감을 동시에 달성할 수 있는 실무적인 context engineering 방안이 될 것입니다.

semantic-searchmodel-context-protocolagentic-airag+3

figma2024년 10월 24일

Figma에서 AI 기반 검색을 (새 탭에서 열림)

디자이너들은 새로 작업하기보다 기존 디자인을 찾아 재활용하는 경우가 많지만, 스크린샷만 가지고 원본 파일을 찾기는 어려웠습니다. Figma는 이 문제를 해결하기 위해 시각 검색과 의미 검색을 결합한 AI 검색을 출시했고, 검색 결과를 디자인 작업에 바로 활용할 수 있도록 했습니다. 초기에는 다음 컴포넌트를 추천하는 ‘디자인 자동완성’을 개발했지만, 사용자 연구를 통해 기존 작업을 찾고 변형하는 일이 더 근본적인 문제라는 결론에 도달했습니다. ## 기존 디자인을 찾기 어려운 문제 - 디자이너들은 원하는 디자인의 원본 파일을 찾기 위해 Slack에 동료에게 질문하거나 여러 파일을 직접 확인해야 했습니다. - 특히 파일명이나 컴포넌트 이름을 모른 채 스크린샷만 가지고 검색해야 하는 상황이 큰 문제였습니다. - Figma 내부에서도 디자인 요소를 찾는 데 상당한 시간이 소요되고 있다는 사실을 수백 건의 Slack 메시지를 통해 확인했습니다. - 이러한 문제를 해결하기 위해 Figma는 Config 2024에서 AI 기반 검색 기능을 공개했습니다. ## 시각 검색과 의미 검색 - **시각 검색(Visual search)** - 스크린샷, 선택한 프레임, 간단한 스케치 등을 입력해 유사한 디자인과 컴포넌트를 찾습니다. - 정확한 파일명이나 텍스트를 몰라도 이미지의 시각적 특징을 기반으로 검색할 수 있습니다. - **의미 검색(Semantic search)** - 사용자의 텍스트 질의를 AI가 이해하고 관련 디자인을 검색합니다. - 컴포넌트의 정확한 이름이나 설명을 몰라도 의도와 문맥에 맞는 결과를 찾을 수 있습니다. - 검색 결과는 단순히 파일을 여는 데 그치지 않고, 디자인을 미리 보거나 현재 프로젝트에 삽입하는 방식으로 활용할 수 있습니다. ## 디자인 자동완성에서 AI 검색으로 전환 - Figma는 2023년 6월 3일간의 AI 해커톤을 열었고, 20개의 프로젝트가 완성됐습니다. - 그중 하나가 작업 중인 화면을 분석해 다음에 필요할 컴포넌트를 추천하는 **디자인 자동완성** 프로토타입이었습니다. - 예를 들어 온보딩 화면을 만들 때 “Get started” 버튼을 추천하는 방식입니다. - 이 기능은 디자이너가 반복적인 작업에서 벗어나 사용자 문제와 같은 고차원적인 사고에 집중하도록 돕는 것을 목표로 했습니다. - 프로토타입의 가능성이 확인되면서 제품 로드맵에 포함됐고, 실제 제품화를 위한 개발이 시작됐습니다. ## RAG를 활용한 검색 기반 AI - Figma는 디자인 자동완성의 품질을 높이기 위해 검색 인프라를 함께 구축했습니다. - **Retrieval-Augmented Generation(RAG)**은 LLM이 답변을 생성하기 전에 관련 사례를 검색해 참고하도록 하는 방식입니다. - 자동완성 기능이 사용자가 작업 중인 화면과 유사한 기존 디자인을 찾으면, 그 사례를 바탕으로 더 적절한 다음 컴포넌트를 추천할 수 있다고 판단했습니다. - 즉, AI가 무작정 새로운 디자인을 생성하는 것이 아니라 Figma에 축적된 실제 디자인 사례를 검색하고 이를 추천의 근거로 활용하는 구조입니다. ## 사용자 연구가 바꾼 제품 방향 - Figma는 내부 팀에 프로토타입을 공유하고 디자이너들을 대상으로 사용성 연구를 진행했습니다. - 반복적인 테스트 과정에서 디자이너들이 작업을 완전히 새로 시작하지 않는다는 패턴을 발견했습니다. - 디자이너들은 과거의 탐색 결과와 기존 작업을 다시 찾아보고, 이를 변형하거나 조합해 새로운 결과물을 만듭니다. - 이 때문에 “다음에 무엇을 추천할까?”보다 “이미 존재하는 작업 중 무엇이 유용한가?”를 찾는 일이 더 근본적인 요구로 드러났습니다. - 이러한 관찰이 디자인 자동완성 중심의 방향을 AI 검색 중심으로 전환하는 계기가 됐습니다. Figma의 사례는 AI 기능을 먼저 만들고 사용자를 설득하기보다, 실제 업무에서 반복되는 불편을 관찰한 뒤 제품 방향을 조정해야 한다는 점을 보여줍니다. 특히 검색과 생성 AI를 결합하면 기존 자산을 재활용하면서도 더 정확한 추천을 제공할 수 있으므로, 조직 내 디자인 자산이 많을수록 시각·의미 검색과 RAG 기반 활용을 함께 고려할 만합니다.

semantic-searchllmragai-search+2