RAG

34 개의 포스트

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

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

에이전트를 활용해 Figma의 내부 시스템을 보호하는 방법 | Figma 블로그

Figma는 SIEM 경보 대응에 AI 에이전트를 도입해 과거 조사 기록 검색, 포렌식 분석, 보안 데이터 질의, 코드 수정과 PR 생성까지 자동화했다. 그 결과 경보의 해결까지 걸리는 시간을 71% 줄였으며, 온콜 엔지니어의 업무를 단순한 정보 수집에서 판단과 검토 중심으로 바꾸었다. 핵심은 기존 업무 흐름을 유지하면서 경보와 조사 지식을 지속적으로 축적·검색하는 시스템을 구축한 것이다. ## 보안 경보 대응의 병목 - Figma의 SIEM인 Panther는 클라우드 인프라, 엔드포인트, SaaS, ID 시스템을 점검한다. - 문제가 감지되면 Slack에 경보를 게시하고 Asana 티켓을 생성한다. - 기존 온콜 엔지니어는 다음 정보를 수동으로 모아야 했다. - 같은 경보가 과거에 발생했는지 - 이전 조사에서 어떤 결론을 내렸는지 - 관련된 Slack 대화가 있는지 - 문제를 해결할 예정인 PR이 존재하는지 - 클라우드 환경과 개발 도구가 빠르게 변하면서 경보의 유형과 대응 방법도 계속 바뀌었다. - 따라서 단순히 경보를 분류하거나 중복 제거하는 것만으로는 업무 부담을 충분히 줄일 수 없었다. ## 검색 시스템에서 에이전트 시스템으로의 확장 - 초기 목표는 새 경보가 발생했을 때 과거 온콜 엔지니어의 판단과 대응 기록을 찾아주는 retrieval layer를 만드는 것이었다. - 이후 시스템은 다음 기능을 수행하는 에이전트 구조로 확장됐다. - 경보 조사 - 보안 데이터 레이크와 감사 로그 질의 - 관련 코드 변경 작성 - PR 생성 - 과거 조사 결과를 기억하고 다음 대응에 활용 - Figma는 코드베이스에서도 에이전트를 활용해 Okta와 AWS 같은 민감한 도구의 설정 변경을 점검하고 있었다. - 그러나 SIEM이 발견하는 광범위한 운영·인프라 문제까지 다루기 위해서는 코드 분석을 넘어선 별도의 시스템이 필요했다. ## RAG 계층: 경보에 기억을 부여하기 - Figma는 AWS Bedrock Knowledge Bases와 Amazon Kendra를 이용해 검색 증강 생성(RAG) 기반의 경보 분류 시스템을 구축했다. - Panther 경보가 발생하면 Lambda 핸들러가 원본 payload를 표준화된 문서로 변환해 Kendra에 색인한다. - 다음과 같은 구조화된 정보를 추출해 검색 속성으로 저장한다. - `p_any_ip_addresses`에서 추출한 IP 주소 - `p_any_usernames` 및 공급자별 사용자 필드의 행위자 정보 - ARN에서 추출한 AWS 계정 ID - 경보 제목, 심각도, 태그, 생성 시각 - 경보 유형, 상태, 조사 맥락의 존재 여부 - 예시 속성에는 `alert_id`, `alert_type`, `severity`, `status`, `created_at`, `has_investigation_context`가 포함된다. ## 의미 검색과 최신성 반영 - 새로운 유사 경보가 발생하면 경보 제목을 주요 검색 벡터로 사용해 Bedrock에 의미 검색을 요청한다. - 검색 질의에는 조사 맥락이 있는 기록만 우선하도록 다음 조건을 추가한다. ```text {경보 제목} has_investigation_context=1 ``` - 경보 제목은 일반적으로 탐지 규칙 이름과 행위자 사용자 이름으로 구성된다. - 단순히 가장 유사한 기록을 찾는 것보다 최근 기록을 우선하도록 검색 결과를 편향시켰다. - 대응 절차와 환경이 계속 변하기 때문에, 6개월 전의 정확히 같은 경보보다 이틀 전에 발생한 유사 경보가 실무적으로 더 유용할 수 있다. - 이를 통해 검색 결과가 현재의 운영 방식과 최신 조사 관행을 더 잘 반영하게 된다. ## Slack 조사 기록의 자동 축적 - `investigation_context`는 온콜 엔지니어가 Slack 경보 스레드에 남긴 조사 결과와 판단을 의미한다. - 조사 내용이 없는 종료 경보는 단순히 “닫혔다”는 사실만 제공하므로 재사용 가치가 낮다. - Figma는 엔지니어가 기존처럼 Slack이나 Asana에 댓글을 남기기만 해도 해당 내용을 자동으로 원래 경보 문서에 추가한다. - 기존 문서의 조사 맥락 배열에 새 댓글을 추가하고, `has_investigation_context` 값을 1로 변경한 뒤 문서를 재색인한다. - 결과적으로 유용한 댓글 하나가 이후 발생하는 모든 유사 경보의 조사 비용을 낮춘다. - 별도의 annotation 도구나 새로운 수동 입력 절차를 요구하지 않고 기존 업무 흐름에서 지식이 축적된다는 점이 중요하다. ## 실용적인 적용 방향 - 처음부터 완전한 자율 에이전트를 만들기보다, 과거 대응 기록을 검색하는 좁은 문제부터 시작하는 것이 현실적이다. - 경보 데이터는 검색 가능한 구조화 필드와 사람이 작성한 조사 맥락을 함께 저장해야 한다. - 최신 대응 기록과 조사 내용이 있는 기록을 우선하는 검색 전략이 필요하다. - 별도의 문서화 작업을 추가하기보다 Slack·티켓 시스템의 기존 댓글을 자동으로 지식화하는 방식이 도입 장벽을 낮춘다. - AI가 분석과 코드 변경을 수행하더라도 PR 검토와 최종 판단은 보안 엔지니어가 맡는 구조가 효과적이다.

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

Attribution Business Insights로 크롤링의 실체 밝히기

웹사이트의 기존 검색엔진 생태계는 크롤링의 대가로 방문자를 보내는 구조였지만, AI 크롤러의 확산으로 이 균형이 무너지고 있다. AI 봇은 콘텐츠를 대량 수집하면서도 원 사이트로 유입되는 방문자는 거의 제공하지 않아, 게시자는 트래픽·수익·인프라 비용 측면에서 손해를 입을 수 있다. Cloudflare는 이를 판단할 수 있도록 봇별 활동과 크롤링 대비 추천 비율을 보여주는 **Attribution Business Insights** 대시보드를 공개했다. ## 검색엔진 시대에서 ‘제로 클릭’ 시대로 - 전통적인 검색엔진은 콘텐츠를 크롤링한 뒤 사용자에게 원문 페이지를 추천했다. - 게시자는 검색 유입을 통해 광고, 제휴, 구독 수익과 독자 관계를 확보할 수 있었다. - 검색엔진의 크롤링 횟수와 추천 방문자 수 사이에는 비교적 균형 잡힌 관계가 있었다. - 그러나 AI 챗봇은 원문을 수집해 답변을 직접 생성하면서 사용자를 원 사이트로 보내지 않는 ‘제로 클릭’ 환경을 만들고 있다. - 이에 따라 인터넷의 최적화 전략도 SEO에서 AEO(Answer Engine Optimization), GEO(Generative Engine Optimization) 중심으로 변화하고 있다. ## AI 크롤러의 불균형한 트래픽 - Cloudflare가 관찰한 주요 AI 크롤러의 크롤링 대비 추천 방문 비율은 약 **118:1에서 거의 50,000:1**까지 나타났다. - 일부 AI 크롤러는 방문자 한 명을 보내기 위해 콘텐츠를 수십만 번에 가깝게 요청할 수 있다. - 게시자는 두 가지 손실을 동시에 부담한다. - 광고 노출, 직접 방문, 독자 관계 등 수익으로 이어지는 트래픽 감소 - 상업적 가치가 불분명한 봇 요청을 처리하는 서버·대역폭 비용 증가 - 따라서 모든 크롤러를 허용해 노출을 기대하는 기존 전략은 더 이상 합리적이지 않을 수 있다. ## Attribution Business Insights 대시보드 - Cloudflare Bot Management 고객에게 제공되는 대시보드다. - 복잡한 로그 분석이나 수동 필터링 없이 사이트의 봇 트래픽을 사업 관점에서 파악하도록 설계됐다. - 주요 제공 정보는 다음과 같다. - 콘텐츠 페이지에 접근한 인간 사용자와 봇의 전체 트래픽 비교 - 사이트 전체 및 봇 운영자별 크롤링 대비 추천 방문 비율 - 24시간, 7일, 30일 단위의 비율 변화 - 트래픽 규모가 큰 봇 목록 - 봇의 국가, 사용 대역폭, 현재 허용·차단 상태 - 이를 통해 어떤 봇이 콘텐츠를 많이 사용하고 실제 방문자를 유도하는지 확인할 수 있다. ## 행동 기반 AI 크롤러 분류 Cloudflare는 AI 봇을 단순히 ‘AI 크롤러’로 묶지 않고 목적에 따라 분류한다. - **Training** - 차세대 대규모 언어 모델을 학습하기 위해 콘텐츠를 수집하는 크롤러 - **Search** - RAG(검색 증강 생성)에 사용할 데이터베이스를 갱신하는 크롤러 - **Agent** - 최종 사용자의 요청에 답하기 위해 에이전트형 상호작용에서 콘텐츠를 조회하는 크롤러 - 이러한 분류를 통해 게시자는 단순한 요청량뿐 아니라 콘텐츠가 어떤 용도로 사용되는지도 판단할 수 있다. ## 데이터에서 콘텐츠 비즈니스 전략으로 - 사이트 운영자는 보안 전문가가 아니더라도 대시보드의 요약 지표만으로 현재 콘텐츠 보안 정책의 효과를 점검할 수 있다. - 더 자세한 분석이 필요한 경우 봇 운영자별로 다음 정보를 비교할 수 있다. - 봇 유형 - 크롤링 대비 추천 비율 - 전체 요청량 - 현재 허용 또는 차단 정책 - 이 데이터는 AI 기업과의 협상이나 콘텐츠 라이선스 재검토에도 활용할 수 있다. - 예를 들어 특정 회사의 크롤링량이 다른 회사보다 20배 많거나, 이미 콘텐츠 사용료를 지급하는 회사가 있다면 이를 근거로 접근 정책과 계약 조건을 조정할 수 있다. - 핵심은 AI 트래픽을 일괄적으로 허용하거나 차단하는 것이 아니라, 실제 사업 가치와 비용을 기준으로 운영하는 것이다. ## 실용적인 적용 방향 게시자는 봇별 크롤링량, 추천 방문자, 대역폭 비용을 함께 비교해 허용·제한·차단 정책을 세워야 한다. 특히 Training, Search, Agent 목적을 구분하고, 유입 가치가 낮은 대량 크롤러에는 속도 제한이나 차단을 적용하며, 수익 또는 라이선스와 연결되는 봇에는 차별화된 접근 정책을 검토하는 것이 바람직하다.

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

2026 뉴욕 AWS 서밋의 주요 발표 | Amazon Web Services

AWS Summit New York 2026의 핵심은 AI 에이전트를 더 쉽게 구축하고, 기업 데이터와 웹 지식을 연결하며, 운영·보안·개발 전반을 자동화하는 것이다. AWS는 Bedrock AgentCore, 보안·DevOps 에이전트, Kiro, Amazon Quick 등을 통해 에이전트의 생성부터 배포, 관리, 지속적인 개선까지 지원하는 기능을 공개했다. 또한 S3 객체에 직접 쿼리 가능한 맥락 정보를 저장하는 기능과 AI 봇 대상 콘텐츠 과금 기능도 발표했다. ## 기업 지식과 웹 검색을 활용하는 에이전트 - **Amazon Bedrock Managed Knowledge Base** - 기업용 RAG 파이프라인을 관리형 서비스로 구축할 수 있다. - 네이티브 데이터 커넥터와 다양한 형식의 데이터를 자동 처리하는 **Smart Parsing**을 제공한다. - 복잡한 다단계 질문을 처리하는 **Agentic Retriever**를 지원한다. - Bedrock AgentCore Gateway와 통합되어 인프라 관리 부담을 줄인다. - **Amazon Bedrock AgentCore Web Search** - AI 에이전트가 최신 웹 정보를 검색하고 출처를 포함해 답변할 수 있다. - 고객의 보안 AWS 환경에서 데이터가 외부로 유출되지 않도록 설계됐다. - 개발자가 별도의 검색 인프라를 직접 구축·운영하지 않아도 된다. - **AWS Context** - 기존 데이터 간 관계를 자동으로 분석해 지식 그래프로 구성하는 서비스다. - 에이전트가 실행 시점에 조직의 데이터 관계, 업무 규칙, 도메인 지식을 검색할 수 있도록 한다. - 거버넌스가 적용된 기업 데이터를 에이전트가 활용하는 기반으로 소개됐다. ## AI 에이전트에 대한 통제와 운영 - **Bedrock AgentCore의 새로운 기능** - 조직 내부 지식, 웹 정보, 유료 지식 소스를 에이전트에 연결할 수 있다. - 프로덕션 환경에서 발생한 문제를 찾고 수정하는 기능을 제공한다. - 에이전트의 능력이 확장되어도 적용 가능한 통제 체계를 구축할 수 있다. - **Amazon Bedrock AgentCore Harness 정식 출시** - 오케스트레이션 루프를 직접 코딩하지 않고도 프로덕션 수준의 에이전트를 구축·실행할 수 있다. - 설정 파일에서 모델, 도구, 스킬, 지침을 정의하는 방식이다. - 에이전트 개발 시간을 단축하는 데 초점을 둔다. - **AWS WAF의 AI 트래픽 과금** - 콘텐츠 제공자가 콘텐츠와 API에 접근하는 AI 봇 및 에이전트에 요금을 부과할 수 있다. - 접근량을 측정하고, 제3자 결제 사업자를 통한 결제를 지원한다. - AWS 엣지에서 범위가 제한된 접근 권한을 직접 부여할 수 있다. ## 머신 속도의 애플리케이션 보안 - **AWS Continuum** - 여러 환경에서 수집한 코드 취약점 정보를 통합한다. - 비즈니스 영향도를 기준으로 취약점을 우선순위화한다. - 실제 악용 가능성을 검증하고, 조직의 기존 프로세스를 통해 수정까지 연결한다. - 코드 취약점 기능은 제한된 미리보기로 제공된다. - **AWS Security Agent** - 애플리케이션 전체 맥락을 분석해 위협 모델을 생성한다. - STRIDE 프레임워크를 활용해 위협과 권장 완화책을 제시한다. - 주요 Git 플랫폼의 풀 리퀘스트 코드 검사와 자동 수정 흐름을 지원한다. - Kiro Power, Claude Code 플러그인, MCP를 통한 IDE 연동도 제공한다. ## 개발과 릴리스 자동화 - **Kiro for iOS** - iPhone에서 Kiro 세션을 시작하고 모니터링할 수 있다. - 작업 완료 후 변경 diff를 검토하고 수정 사항을 승인할 수 있다. - 노트북을 계속 켜두지 않아도 개발 작업을 원격으로 관리할 수 있다. - **AWS DevOps Agent의 릴리스 관리** - 프로덕션 배포 전 코드 변경 사항의 릴리스 준비 상태를 검토한다. - 자연어로 정의한 조직의 기준에 따라 변경 사항을 검증한다. - 프로덕션과 유사한 환경에서 변경 사항별 테스트를 자동 실행한다. - **AWS Transform의 지속적 현대화** - 설정 가능한 기준에 따라 코드 저장소를 지속적으로 분석한다. - 기술 부채와 현대화 대상을 수주가 아닌 수시간 내에 식별하는 것을 목표로 한다. - 우선순위가 정해진 문제에 대해 자동으로 수정 풀 리퀘스트를 생성할 수 있다. ## 업무를 수행하는 자율 에이전트 - **Amazon Quick 자율 에이전트** - 특정 전문성, 말투, 도구 접근 권한을 가진 백그라운드 에이전트를 만들 수 있다. - 금융 에이전트가 주문을 처리하거나, 영업 에이전트가 CRM·이메일·Slack을 모니터링할 수 있다. - 후속 연락 초안 작성, 위험 신호 표시, 다음 업무 추천 등을 자동 수행한다. - **새로운 Activity Feed** - 이메일, 메시지, 일정, 작업을 하나의 우선순위 기반 화면에 통합한다. - 사용자가 빠르게 답하는 메시지, 건너뛰는 대화, 업무상 자주 다루는 주제를 학습한다. - 개인의 업무 방식에 맞춰 중요한 활동을 선별한다. ## AI 에이전트를 위한 S3 메타데이터 - **Amazon S3 annotations** - S3 객체에 최대 1GB의 풍부하고 변경 가능한 맥락 정보를 직접 추가할 수 있다. - 저장된 정보는 쿼리 가능하므로 AI 에이전트가 객체의 의미와 관련 정보를 바로 탐색할 수 있다. - 별도의 메타데이터 시스템을 유지하지 않고도 대규모 데이터 처리와 자율 워크플로를 지원한다. 이번 발표는 AWS가 AI 에이전트를 단순한 대화형 기능이 아니라 지식 검색, 보안 대응, 코드 수정, 릴리스 검증, 업무 실행까지 담당하는 운영 시스템으로 확장하고 있음을 보여준다. 실제 도입 시에는 에이전트의 자율성보다 데이터 접근 권한, 비용 통제, 감사 로그, 사람의 승인 절차를 먼저 설계하는 것이 바람직하다.

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

더 빠르고 정확한 엔터프라이즈 AI 애플리케이션을 위한 Amazon Bedrock 관리형 지식 기반 소개 | Amazon Web Services

Amazon Bedrock Managed Knowledge Base는 기업 데이터를 활용한 생성형 AI 애플리케이션을 몇 분 안에 구축하도록 RAG 파이프라인을 관리형 서비스로 제공한다. 데이터 연결, 검색 정확도 개선, 대규모 인프라 운영을 추상화하고, 네이티브 커넥터·Smart Parsing·Agentic Retriever를 통해 빠르고 정확하며 권한이 반영된 검색을 지원한다. 개발자는 임베딩, 재순위화, 저장소, 기반 모델 등을 직접 조합하지 않고 애플리케이션과 비즈니스 결과에 집중할 수 있다. ## 기업용 RAG 구축의 주요 난점 - 기업 데이터가 S3, SharePoint, Confluence, Google Drive 등 여러 시스템에 분산되어 있다. - 시스템마다 문서 형식, 콘텐츠 유형, 접근 제어 목록이 달라 데이터 커넥터를 직접 개발하고 유지해야 한다. - 검색 정확도를 높이려면 파싱 방식, 문서 청킹, 임베딩 모델, 재순위화, 에이전트 검색 동작을 반복적으로 실험해야 한다. - 수백만 개 문서를 처리하거나 여러 팀의 지식 베이스를 동시에 운영하려면 확장성, 보안, 비용 관리가 필요하다. - 이런 인프라 작업은 개발자가 실제 AI 애플리케이션 개발보다 반복적인 운영 업무에 시간을 쓰게 만든다. ## 관리형 지식 베이스의 추상화 - 저장소, 검색, 임베딩, 재순위화, 기반 모델 선택 등 기존에 직접 구성해야 했던 요소를 하나의 관리형 기능으로 통합한다. - 기본적으로 임베딩 모델, 재순위화 모델, 기반 모델을 자동으로 선택하고 관리한다. - 지식 베이스 규모 확장과 엔드투엔드 RAG 파이프라인 운영을 서비스가 담당한다. - Amazon Bedrock AgentCore Gateway에서 사전 구축된 대상 유형으로 사용할 수 있다. - 몇 줄의 코드만으로 연동할 수 있으며, 역할 기반 권한 생성과 관측성·평가 지표도 AgentCore Observability 대시보드에서 확인할 수 있다. ## 네이티브 데이터 커넥터 - 별도 커넥터 개발 없이 다음 데이터 소스를 연결할 수 있다. - Amazon S3 - SharePoint - Confluence - Web Crawler - Google Drive - OneDrive - SaaS 애플리케이션별 데이터 구조와 권한 정보를 네이티브 방식으로 가져온다. - 지식 베이스 생성 과정에서 데이터 소스를 드롭다운으로 선택할 수 있다. - IAM 역할이 자동 생성되며, 필요한 경우 권한을 직접 수정할 수 있다. ## Smart Parsing을 통한 정확한 데이터 수집 - 데이터 소스와 문서 유형에 맞는 파싱 전략을 자동으로 선택한다. - 커넥터별 데이터 모델을 적용한다. - Web Crawler는 HTML 구조, 삽입 이미지, 표를 보존한다. - SharePoint는 문서 계층 구조와 파일 간 관계를 유지한다. - 문서 내부의 다양한 콘텐츠 유형을 자동으로 감지하고 처리한다. - 문서의 바운딩 박스를 식별한 뒤 기반 모델을 사용해 데이터 추출, 이미지 캡션 생성, 동영상 장면 설명 등을 수행한다. - 기반 모델이 문서 구조를 이해해 의미 있는 콘텐츠 단위로 청킹한다. - 문서 유형과 구조에 따라 검색 정확도와 성능 사이의 균형을 맞춘 기본값을 제공한다. - 고급 사용자는 필요할 때 청킹 전략을 직접 조정할 수 있다. - 일반적으로 프로덕션 수준의 검색 품질을 얻기 위해 필요했던 수 주간의 실험을 줄인다. ## Agentic Retriever의 다단계 검색 - 단순한 한 번의 벡터 검색으로 해결하기 어려운 복합 질의를 처리한다. - 사용자의 의도를 분석하고 질문을 여러 단계의 검색 계획으로 분해한다. - 하나의 지식 베이스 또는 여러 지식 베이스를 대상으로 멀티홉 검색을 수행한다. - 각 단계에서 검색 결과를 평가하고, 충분한 관련 정보가 모이면 검색을 중단한 뒤 상위 결과를 반환한다. - 예를 들어 다음과 같은 질문을 연결해 답할 수 있다. - ML 플랫폼 팀의 클라우드 인프라 예산은 얼마인가? - 비용 정책에서 연간 약정 선결제를 허용하는가? - 해당 팀이 예산으로 선결제를 할 수 있는가? - 첫 번째 질문에서 팀과 예산 정보를 찾고, 두 번째 질문에서 비용 정책을 검색한 뒤, 세 번째 단계에서 두 정보를 결합해 답을 도출한다. ## 생성 및 사용 절차 - Amazon Bedrock AgentCore 콘솔 또는 Amazon Bedrock 콘솔에서 Knowledge Bases 페이지를 연다. - `Create Managed KB`를 선택한다. - 권장 옵션인 `Unstructured Vector Store KB`를 선택한다. - 지원되는 데이터 커넥터와 IAM 권한을 설정한다. - 데이터를 동기화한 뒤 에이전트에 연결하거나 기반 모델의 도구로 제공한다. - 최적화된 기본 설정을 사용하면 몇 번의 클릭만으로 지식 베이스를 생성할 수 있다. Amazon Bedrock Managed Knowledge Base는 기업용 RAG 시스템을 직접 설계·운영해야 하는 부담을 줄이는 데 적합하다. 특히 여러 SaaS 데이터 소스를 통합하거나 복합적인 다단계 질문을 처리해야 하는 조직은 네이티브 커넥터, Smart Parsing, Agentic Retriever를 활용해 초기 구축 시간을 줄이고 검색 품질을 안정적으로 확보할 수 있다.

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

레거시 프로젝트에서 AI 드리븐 프로젝트로 전환, AX 로드맵

AX는 AI 도구를 개별적으로 사용하는 데서 그치지 않고, 개발 사이클 전체를 AI 중심으로 재설계하는 전환 과정이다. 성공적인 전환을 위해서는 보안·컴플라이언스 기반을 먼저 마련하고, 팀 차원의 활용 표준화와 명세 기반 개발 자동화를 단계적으로 추진해야 한다. 특히 SDD와 사람의 승인 게이트를 결합하면 AI의 생산성을 활용하면서도 품질과 통제력을 유지할 수 있다. ## AI 드리븐 프로젝트와 SDD - AI 드리븐 프로젝트는 AI를 스펙 작성, 코드 생성, 테스트, 리뷰, 머지 등 개발 전 과정에 통합하는 방식이다. - 사람은 세부 구현보다 요구사항과 방향 설정, 품질 판단에 집중한다. - 핵심 방법론은 명세 주도 개발(SDD)이다. - 요구사항, 구현 범위, 예외 상황, 검증 기준을 먼저 정의한다. - AI는 명세를 바탕으로 계획을 세우고 코드를 생성·검증한다. - AI는 패턴 완성에는 강하지만 추상적인 의도 파악에는 한계가 있으므로, 명확한 스펙이 결과 품질을 좌우한다. ## 1단계: AI-Ready — 보안과 컴플라이언스 기반 AI 도입 전 민감 정보와 핵심 자산이 외부 모델에 노출되지 않도록 안전한 사용 환경을 구축한다. - API 키, DB 비밀번호, 내부 IP 등의 하드코딩을 제거한다. - Secrets Manager 같은 전용 서비스를 사용하고 런타임에 시크릿을 주입한다. - 이름, 이메일, 전화번호 등 PII는 AI에 전달하기 전에 마스킹하거나 토큰화한다. - 핵심 알고리즘과 경쟁력 있는 아키텍처는 별도 저장소에서 관리하거나 AI 접근 권한을 제한한다. - 초기에는 모든 시스템을 한 번에 이관하기보다 다음을 우선 적용한다. - 핵심 컴플라이언스 요건 선별 - 파일 시스템·네트워크 격리를 통한 샌드박싱 - 격리 상태에서 실제 정보가 노출되지 않는지 검증 - 기대 효과: - 코드와 프로젝트 맥락을 AI에 안전하게 제공 - 디버깅, 문서화, 반복 코드 작성 속도 향상 - 팀원들이 AI를 안전하게 활용하는 경험 축적 ## 2단계: AI-Assist — 팀 단위 활용 표준화 개인별로 제각각인 AI 사용 방식을 프로젝트 공통 워크플로로 통합한다. 이 단계에서 AI는 코드를 직접 작성하기보다 사람이 작성한 코드를 검토하고 보조한다. - 프로젝트 루트에 AI용 가이드라인을 작성한다. - 프로젝트 개요 - 코딩 컨벤션 - 아키텍처 원칙 - 도메인 용어집 - 코드 리뷰, 브레인스토밍, 작업 계획 수립 등에 사용할 표준 프롬프트와 스킬을 구축한다. - `superpowers`와 같은 플러그인을 활용해 다음 작업을 표준화할 수 있다. - `brainstorming` - `writing-plans` - `subagent-driven-development` - CI/CD와 AI를 연동해 PR 생성 시 자동 코드 리뷰를 수행한다. - 스타일 위반 탐지 - 잠재적 버그 확인 - 보안 취약점 점검 - 사람 리뷰어는 반복적인 지적보다 복잡한 비즈니스 로직과 정책 판단에 집중한다. - 측정 가능한 KPI: - 사람이 직접 남기는 반복 리뷰 코멘트 수 - 테스트 커버리지 변화 - 배포 안정성 및 테스트 통과율 - 기대 효과: - 팀 전체의 AI 활용 수준 상향 평준화 - 리뷰어의 인지 부하 감소 - 코드 품질과 컨벤션의 일관성 확보 ## 3단계: AI-Development — 명세 기반 개발 자동화 사람이 작성한 스펙이 AI를 통해 구현 계획, 테스트 계획, 코드, PR로 이어지는 자동화 파이프라인을 구축한다. - 전체 흐름은 다음과 같다. 1. 사람이 요구사항과 범위, 엣지 케이스, 검증 기준을 스펙으로 정의 2. AI가 구현 계획과 테스트 계획 작성 3. AI 서브 에이전트가 계획에 따라 작업을 순차적으로 수행 4. 코드 리뷰 후 PR 생성 및 머지 - 세 개의 Human Gate를 둔다. - **Human Gate 1:** 스펙 검토 및 승인 - **Human Gate 2:** 구현 계획과 테스트 계획 검토 및 승인 - **Human Gate 3:** 최종 코드 검토 및 승인 - AI가 프로젝트에 맞는 코드를 만들 수 있도록 도메인 지식을 구조화한다. - 아키텍처 원칙 - 비즈니스 로직의 예외와 특이사항 - 시스템 구성도 - 기존 스펙 및 기술 문서 - 지식은 전용 디렉터리, AI 커스텀 스킬, RAG 시스템 등을 통해 AI가 필요할 때 조회하도록 구성한다. - `/specs` 같은 디렉터리에 새 스펙 파일이 추가되면 CI가 이를 감지해 다음 단계를 실행하도록 이벤트 트리거를 설정한다. - CI 내부에 Approval Step을 배치해 사람의 승인 없이는 AI가 다음 단계로 진행하지 못하게 한다. - 초기에는 핵심 비즈니스 로직보다 테스트 코드나 보일러플레이트처럼 위험도가 낮은 영역부터 자동화를 적용하고, 신뢰가 쌓이면 AI의 담당 범위를 확대한다. ## 단계적 도입이 필요한 이유 - AI 활용 효과는 팀의 문서화 수준, 테스트 품질, 도메인 복잡도에 크게 좌우된다. - 처음부터 모든 구현을 AI에 맡기면 프로젝트 맥락을 이해하지 못한 코드가 생성될 수 있다. - 낮은 위험도의 테스트와 반복 코드부터 시작하면 품질을 검증하면서 팀의 신뢰를 확보할 수 있다. - 각 단계는 독립적으로도 효과가 있으므로 모든 단계를 한 번에 완료할 필요는 없다. 보안 기반을 먼저 확보한 뒤 프로젝트 규칙과 지식을 문서화하고, 자동 리뷰와 테스트 생성부터 시작하는 접근이 현실적이다. 이후 명확한 스펙과 사람의 승인 게이트를 중심으로 코드 생성 범위를 점진적으로 넓히는 것이 안전한 AX 전략이다.

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

에이전틱 AI 생태계의 주인공들, MCP Player 10 성료와 Next!

카카오의 MCP 기반 개방형 플랫폼 PlayMCP에서 열린 ‘MCP Player 10’ 공모전이 약 150개 팀의 참여 속에 마무리됐다. 수상작들은 보육 행정, 창업 지원사업, 육아, 법률, 문화생활, 게임, 보안 등 일상과 전문 영역의 문제를 AI 에이전트로 해결했다. 카카오는 PlayMCP를 개발자 중심 플랫폼으로 발전시키고, Kakao Tools 및 카카오톡과 연계해 MCP 서비스의 대중화를 추진할 계획이다. ## 60일간 진행된 MCP 공모전 - 공모전은 2025년 12월 19일부터 2026년 1월 18일까지 진행됐다. - 카카오의 MCP 기반 플랫폼 **PlayMCP**를 활용해 실용적인 MCP 서버를 개발하는 방식이었다. - 약 150개 팀이 참여했으며, 창의성·사용 편의성·기술적 안정성을 기준으로 최종 10팀을 선정했다. - 단순한 기술 시연보다 실제 생활 속 불편을 해결하고 서비스로 발전할 가능성이 중요한 평가 기준으로 소개됐다. ## 대상: 어린이집 행정을 돕는 ‘어린이ZIP’ - 현직 교사의 행정 업무 부담을 줄이는 AI 보육 조수다. - 활동 사진을 분석해 알림장과 보육일지 초안을 자동 생성한다. - 아이별 알레르기, 하원 방법 등 개별 특이사항을 기억해 맞춤형 답변을 제공한다. - 보육 현장에 적합한 따뜻한 문체와 전문가의 톤앤매너를 반영한다. - “사진으로 오늘 보육일지 작성”, “아이의 알레르기 정보 확인”과 같은 자연어 명령으로 사용할 수 있다. ## 최우수상: 창업 지원사업을 분석하는 ‘SeedUp’ - 정부 창업 지원사업 공고를 수집하고 분석하는 창업 지원 MCP다. - 여러 기관에 흩어진 공고와 첨부 파일을 한곳에서 검색·요약한다. - 지원 자격과 주요 조건을 확인하고, 지원사업별 합격 전략까지 안내한다. - 창업자가 “이번 주 주요 공고”, “AI 스타트업 관련 사업” 등을 자연어로 검색할 수 있다. ## 다양한 생활 문제를 해결한 수상작 - **공유 비밀의 방** - 익명성을 보장하는 디지털 소통 플랫폼이다. - AI와 나눈 고민이나 대화를 익명으로 공유하고 다른 사람의 이야기에 공감할 수 있다. - **바우만 16 안티에이징솔루션** - 바우만 피부 유형 16가지 분류법을 AI에 적용했다. - 화장품 성분과 피부 특성을 분석해 개인별 스킨케어 루틴과 제품을 추천한다. - **아라드도우미** - 던전앤파이터 이용자를 위한 게임 전문 AI 비서다. - RAG와 Vision AI를 활용해 패치 노트, 아이템 메타, 직업별 빌드를 분석한다. - **키즈허브** - 육아 정보와 공공데이터를 통합한 서비스다. - 응급실 현황, 성장 단계, 어린이집 대기 정보 등을 제공하고 가족 단톡방 공유도 지원한다. - **택배추적기** - 배송 조회뿐 아니라 택배 사칭 스미싱 URL도 탐지한다. - 배송 관련 문자 속 위험 링크를 분석해 개인정보와 금융 피해를 예방한다. - **ArtBridge** - 약 20만 건의 공연·전시 데이터를 활용하는 문화생활 추천 서비스다. - 위치, 예산, 취향을 바탕으로 연극·뮤지컬·클래식 등 9개 장르의 콘텐츠와 예매 정보를 추천한다. - **KidSafe** - 어린이와 청소년의 AI 대화를 보호하는 안전 MCP다. - 유해 표현과 정서적 위기 신호를 감지하고, 필요하면 보호자나 전문 상담 자원과 연결한다. - **LexiLink_ko** - 법령, 판례, 행정 해석례를 자연어로 검색하는 법률 리서치 도구다. - 복잡한 법적 쟁점을 통합 검색하고 이해하기 쉽게 정리한다. ## PlayMCP의 향후 발전 방향 - PlayMCP는 개발자가 MCP 서버를 만들고 공유하는 전문 공간으로 운영된다. - 일반 사용자가 MCP를 경험하는 공간은 카카오톡의 **Kakao Tools**가 담당하며, 두 서비스는 긴밀하게 연결될 예정이다. - 현재는 개발자가 MCP 서버의 엔드포인트와 운영을 직접 관리해야 한다. - 향후 카카오 클라우드 기반 서버 지원과 배포 자동화 등 매니지드 서비스 도입을 검토하고 있다. - 카카오톡 안에서 MCP가 JSON 기반 위젯 등 자체 UI를 렌더링하도록 지원하는 방안도 검토 중이다. ## 다음 공모전: Agentic Player 10 - 카카오는 2회 공모전인 **Agentic Player 10**을 예고했다. - 이번에는 Kakao Tools와 연계해 개발자가 만든 에이전트를 더 많은 사용자에게 직접 선보이고 검증할 기회를 제공한다. - 특히 스타트업과 예비 창업팀이 실제 사용자 접점을 확보하고 서비스 성장을 실험하는 장으로 활용할 수 있도록 설계될 예정이다. - MCP 서버가 카카오톡 안에서 대중적인 AI 에이전트로 발전하는 것이 주요 목표다. 수상작들은 MCP가 단순한 개발자용 연동 기술을 넘어, 특정 업무와 사용자 문제를 해결하는 실용적인 AI 서비스로 발전할 수 있음을 보여준다. MCP 서비스를 개발한다면 명확한 사용자 문제를 정하고, 신뢰할 수 있는 데이터와 안전장치, 자연어 기반 사용성을 함께 설계하는 것이 중요하다.

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

Gemini Enterprise Agent Platform의 Agentic RAG로 신뢰할 수 있는 응답 구현하기

Google의 Agentic RAG는 단일 검색과 생성을 수행하는 기존 RAG의 한계를 넘어, 복잡한 기업 질의를 여러 단계로 분해하고 필요한 정보가 확보될 때까지 반복 검색하는 멀티 에이전트 구조다. 특히 검색 결과와 중간 답변을 검토하는 ‘충분한 컨텍스트 에이전트’를 통해 누락된 정보를 식별하고 추가 검색을 지시한다. Google은 이 방식이 사실성 평가 데이터셋에서 정확도를 최대 34% 향상시켰으며, 내부 도메인별 데이터에서도 더 나은 근거 기반 응답과 추론 정확도를 보였다고 설명한다. ## 기존 단일 단계 RAG의 한계 - 일반적인 RAG는 질문을 바탕으로 관련 문서를 한 번 검색한 뒤, 검색 결과를 LLM에 전달해 답변을 생성한다. - 기업 데이터는 여러 데이터베이스와 문서 저장소에 분산되어 있어 한 번의 검색만으로 답을 찾기 어렵다. - 예를 들어 프로젝트 문서에 서버 ID만 있고 실제 서버 사양은 별도 자산 데이터베이스에 있다면, 기존 RAG는 서버 사양을 추가로 조회하지 못한다. - 그 결과 부분적인 답변을 내놓거나, 정보가 실제로 존재함에도 “찾을 수 없다”고 응답할 수 있다. ## 멀티 에이전트 기반 검색 구조 Agentic RAG는 하나의 검색기가 모든 작업을 처리하는 대신 역할별 에이전트가 협력한다. - **Orchestrator**: 질의를 분석해 단일 검색으로 충분한지 판단하고, 복잡한 작업을 하위 에이전트에 위임한다. - **Planner Agent**: 필요한 정보의 경로와 검색 순서를 계획한다. 예를 들어 예산은 재무 데이터베이스에서, 일정은 프로젝트 관리 로그에서 조회하도록 결정한다. - **Query Rewriter**: 모호하거나 긴 질문을 여러 개의 구체적인 검색 질의로 변환한다. - **Search Fanout Agent**: 변환된 질의를 여러 검색 소스에 동시에 보내 정보를 수집한다. - **LLM 또는 Synthesis Agent**: 수집된 컨텍스트를 통합해 최종 답변을 작성한다. ## Google 방식의 차별점: 충분한 컨텍스트 검증 - 기존 멀티 에이전트 RAG와 달리, Google의 구조는 정보가 충분한지 확인하는 전용 **Sufficient Context Agent**를 포함한다. - 첫 검색 결과가 불완전해도 즉시 답변하거나 포기하지 않고, 어떤 정보가 누락됐는지 분석한 뒤 추가 검색을 수행한다. - 이를 통해 정보 부족을 이유로 한 성급한 추측이나 불완전한 답변을 줄인다. ## 의료 질의 처리 과정 예시 질의는 환자의 퇴원 약물, 식이 제한, 입원 중 알레르기 반응을 묻고 특정 입원·응급실 투여 약물은 제외하도록 요구한다. ### 1. 오케스트레이션 - Root Agent가 의사의 요청을 분석하고 하위 작업으로 분배한다. - Planner Agent는 Pharmacy, Nutrition, Clinical Notes 등 세 영역을 확인해야 한다고 판단한다. - Query Rewriter는 긴 요청을 약물, 식이, 알레르기 여부에 관한 검색 가능한 질의로 나눈다. ### 2. 초기 검색 - RAG Agent가 여러 검색 질의를 환자 기록에 동시에 실행한다. - 퇴원 약물과 식이 정보는 찾지만, 알레르기 관련 내용은 주요 문서에서 발견하지 못한다. - 일반 RAG라면 이 시점에서 불완전한 답변을 생성할 수 있다. ### 3. 충분한 컨텍스트 검증 Sufficient Context Agent는 다음 세 가지를 함께 검토한다. - **검색된 스니펫**: 실제로 검색된 문서 구간에 필요한 정보가 포함되어 있는지 확인한다. - **중간 초안**: 현재까지의 검색 결과로 작성한 임시 답변이 질문의 모든 요구사항을 다루는지 평가한다. - **누락 정보 분석**: 단순히 “정보가 부족하다”고 말하지 않고, 어떤 내용이 빠졌는지 구체적인 이유와 피드백을 생성한다. - 예: 약물 목록과 저염식 지침은 확보했지만, 알레르기 반응이나 이상 사례 정보가 없음. - 후속 지시: “알레르기 질문이 해결되지 않았으므로 ‘발진’, ‘이상 반응’ 등을 검색하라.” ### 4. 반복 검색 - 검증 에이전트의 피드백을 받은 Query Rewriter가 새로운 검색어를 생성한다. - RAG Agent는 초기 검색에서 제외했던 파일과 문서 영역을 다시 조사한다. - 이 과정에서 알레르기나 이상 반응에 관한 누락 정보가 발견될 수 있다. ### 5. 최종 합성 - Sufficient Context Agent가 약물, 식이, 알레르기 정보가 모두 확보됐는지 다시 확인한다. - 충분한 정보가 모이면 검색을 종료한다. - Synthesis Agent가 의사가 활용할 수 있는 정확하고 정리된 최종 요약을 작성한다. ## 평가와 기대 효과 - Google은 Agentic RAG를 FRAMES 논문 기반의 **FramesQA** 데이터셋에서 평가했다고 밝혔다. - 평가 대상에는 여러 단계의 추론과 서로 다른 정보 출처를 연결해야 하는 멀티홉 질문이 포함된다. - 사실성 데이터셋에서 기존 방식보다 정확도가 최대 34% 향상됐다. - 내부 데이터셋에서도 도메인별 작업에 대해 더 나은 근거 연결과 추론 정확도를 확인했다고 설명한다. - 제공된 글 본문은 실험 예시가 시작되는 부분에서 끝나므로, 세부 수치와 비교 대상별 결과는 제시되지 않았다. 실무적으로 Agentic RAG는 데이터가 여러 시스템에 분산되어 있고 한 번의 검색으로 답을 완성하기 어려운 기업 환경에 적합하다. 다만 반복 검색과 다수 에이전트 운영으로 비용과 지연 시간이 증가할 수 있으므로, 충분한 컨텍스트 검증을 적용할 질의 유형을 선별하고 검색 횟수·중단 조건을 함께 설계하는 것이 중요하다.

원문 읽기(새 탭에서 열림)
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 시대를 위해 캐시를 재고하는 이유 (새 탭에서 열림)

AI 트래픽의 급격한 증가는 인간 사용자의 행동 패턴을 기반으로 설계된 기존 CDN 캐시 아키텍처에 큰 도전 과제를 던지고 있습니다. AI 크롤러와 에이전트는 일반적인 인간 사용자와 달리 웹사이트 전체를 순차적으로 스캔하거나 방대한 양의 '롱테일(비인기)' 콘텐츠를 집중적으로 요청하며, 이는 기존 캐시 적중률을 떨어뜨리고 원본 서버의 부하를 가중시키는 결과를 초래합니다. Cloudflare는 이러한 AI 시대의 독특한 데이터 접근 패턴에 대응하기 위해 CDN 캐시 설계의 근본적인 재검토가 필요하다고 주장합니다. ### AI 트래픽과 인간 트래픽의 차이점 * **높은 고유 URL 요청 비율:** AI 에이전트는 정보를 정제하고 정확도를 높이기 위해 반복적인 루핑(looping)을 수행하며, 이 과정에서 요청의 70~100%가 중복되지 않는 고유 URL로 구성됩니다. * **콘텐츠 접근의 광범위성:** 인기 페이지에 집중하는 인간과 달리, AI는 훈련 데이터 수집이나 검색 증강 생성(RAG)을 위해 기술 문서, 이미지, 블로그 등 웹사이트의 거의 모든 콘텐츠를 훑어갑니다. * **크롤링 비효율성:** AI 크롤러는 브라우저 측 캐싱이나 세션 관리를 제대로 활용하지 않으며, 독립적인 인스턴스를 여러 개 실행하여 동일한 콘텐츠를 중복 요청하거나 잘못된 URL 처리로 인해 많은 404 오류를 발생시키기도 합니다. ### 기존 캐시 알고리즘(LRU)의 한계와 영향 * **캐시 오염(Cache Churn):** 대규모 AI 스캔이 발생하면 인간 사용자가 자주 찾는 인기 콘텐츠가 캐시에서 밀려나고, 그 자리를 AI가 일회성으로 긁어가는 비인기 콘텐츠가 차지하게 됩니다. * **캐시 적중률(Hit Rate) 하락:** 가장 오래전에 사용된 데이터를 먼저 삭제하는 LRU(Least Recently Used) 알고리즘은 AI의 공격적인 스캔 패턴 아래에서 효율이 급격히 떨어지며, 이는 곧 캐시 미스 증가로 이어집니다. * **원본 서버 및 비용 부담:** 캐시 미스가 발생하면 모든 요청이 원본(Origin) 서버로 직접 전달되어 서버 부하가 커지고, 데이터 전송에 따른 이그레스(Egress) 비용이 상승하며 응답 속도는 느려집니다. ### AI 시대의 웹 운영을 위한 새로운 방향 * **운영자의 이분법적 선택:** 웹 운영자는 이제 자원 보호를 위해 AI 크롤러를 차단할 것인지, 아니면 AI 모델의 최신 정보를 유지하기 위해 이들을 수용할 것인지 선택해야 하는 상황에 놓여 있습니다. * **차세대 캐시 전략의 필요성:** 기존의 단순한 프리페칭(Prefetching)이나 캐시 만료 정책은 더 이상 유효하지 않으며, AI 에이전트의 반복적인 루핑과 롱테일 접근 패턴을 반영한 지능적인 캐시 설계가 필수적입니다. * **연구 및 협업:** Cloudflare는 ETH Zurich 연구진과 협력하여 AI 트래픽 패턴을 모델링하고, 이를 기반으로 CDN이 AI 시대에 어떻게 적응해야 할지에 대한 기술적 방향성을 제시하고 있습니다. 웹 운영자는 자신의 콘텐츠가 AI 검색 결과나 학습 데이터에 포함되기를 원한다면, AI 트래픽의 특성을 이해하고 이를 효율적으로 처리할 수 있는 도구를 도입해야 합니다. 단순히 트래픽을 차단하는 것을 넘어, 'Pay per crawl'과 같은 수익화 모델이나 AI 전용 캐시 계층을 고려하는 등 변화하는 환경에 맞춘 유연한 대응 전략이 권장됩니다.

kakao4분 읽기큐레이션 요약

학생에서 개발자로: DB, 보안부터 AI까지, 정답보다 합리적인 선택을 배우다

카카오 신입 개발자 온보딩은 기술의 정답을 암기하는 교육이 아니라, 대규모 트래픽과 운영 환경을 견디는 합리적 설계를 배우는 과정이었다. DB에서는 변경과 운영 비용을 고려하고, 보안에서는 취약점을 자신의 코드 문제로 인식하며, AI에서는 모델의 불확실성을 시스템 설계로 통제하는 관점을 익혔다. 결국 개발자의 핵심 역량은 상황과 리소스에 맞는 선택을 하고, 그 근거를 팀과 공유·설득하는 능력이라는 결론에 도달한다. ## DB: 이론적 정답보다 운영 가능성을 우선하기 - 무결성은 반드시 DB가 전부 책임져야 하는 규칙이 아니라, DB와 애플리케이션 중 어디에 책임을 둘지 정하는 운영 모델이다. - 물리적 Foreign Key는 무결성을 보장하지만, 트래픽과 변경이 많은 환경에서는 락, 성능 저하, 스키마 변경의 유연성 문제를 일으킬 수 있다. - 애플리케이션이 무결성을 담당한다면 테스트와 데이터 보정 로직을 강화해야 한다. - 삭제된 데이터를 복구하거나 감사 추적해야 하므로 `deleted_at`을 활용한 소프트 딜리트가 실무의 중요한 운영 전략이 된다. ## 인덱스와 SQL: 결과가 아니라 실행 경로 설계하기 - 인덱스는 단순히 조회 속도를 높이는 기능이 아니라, 데이터 특성과 질의 방식에 맞는 자료구조 선택이다. - B-Tree 외에도 GIN, GiST, SP-GiST, Vector 인덱스 등 다양한 선택지가 있으며, DB가 어떤 질문을 받는지에 따라 적합한 인덱스가 달라진다. - 실행 계획을 확인하면 동일한 SQL이라도 인덱스를 사용하는지, 테이블 전체를 스캔하는지 파악할 수 있다. - 이러한 실행 경로의 차이는 디스크 I/O와 응답 시간에 직접 영향을 준다. - SQL 작성은 단순히 원하는 결과를 반환하는 작업이 아니라, 효율적인 실행 경로를 유도하는 작업으로 이해해야 한다. ## 중복과 반정규화: 데이터 중복을 성능 전략으로 활용하기 - 정규화와 JOIN이 항상 최선은 아니며, 데이터 규모와 트래픽이 커지면 JOIN이 병목이 될 수 있다. - 읽기 성능을 위해 일부 데이터를 의도적으로 중복 저장하는 반정규화가 합리적인 선택이 될 수 있다. - 당시의 비즈니스 상태를 보존해야 한다면 관련 정보를 스냅샷으로 저장하는 방식도 필요하다. - MongoDB에서는 관계를 `ref`로만 연결할 경우 조회가 복잡해질 수 있어, 화면에 필요한 정보를 함께 저장하면 추가 조회를 줄일 수 있다. ## DB 생태계: 성능·일관성·확장성의 트레이드오프 이해하기 - MySQL의 고가용성 구조, PostgreSQL의 PK 설계, Neon의 스토리지·컴퓨팅 분리 등 DBMS마다 고유한 설계 철학이 있다. - 어떤 시스템도 모든 상황에서 최선일 수 없으며, 성능·일관성·확장성·운영 비용 사이의 균형을 선택해야 한다. - Hadoop과 Spark 같은 빅데이터 기술도 개별 도구가 아니라 저장, 관리, 처리, 분석으로 이어지는 데이터 생태계의 일부로 이해해야 한다. - 이론적으로 완벽한 구조보다 변경에 안전하고 운영 비용을 감당할 수 있는 설계를 우선하게 되었다. ## 보안: 외부 조직의 일이 아니라 개발자의 기본값 - 개인정보 유출 가능성을 가정하면서 보안을 규정이나 인프라팀의 업무가 아닌 자신의 코드에서 시작되는 책임으로 인식하게 되었다. - Dev/Prod 분리, VPN, 백신 등은 편의성을 일부 희생하더라도 안전을 확보하기 위한 장치다. - DDoS 대응에서는 공격을 차단하는 것뿐 아니라 정상적인 트래픽 폭증과 공격을 구분하는 일이 어렵다는 점을 배웠다. - 개발자가 적용할 수 있는 기본 방어책으로 Rate Limit을 활용하고, 이상 징후가 발생하면 혼자 해결하지 않고 대응 체계에 연결해야 한다. ## API 보안과 지속적인 점검 - 취약점을 직접 공격해보는 실습을 통해 보안을 이론이 아닌 자신의 코드에 대한 문제로 체감했다. - AI를 활용한 취약점 탐색, QR 코드 공격, 앱 권한 악용처럼 방어 기술과 공격 기술이 함께 발전하고 있다. - 보안은 배포 직전에 한 번 점검하는 절차가 아니라 개발 초기부터 기본값으로 포함되어야 한다. - 코드 품질은 작성자가 자리를 비워도 다른 개발자가 빠르게 이해하고 운영할 수 있는지까지 포함한다. ## AI Agent: 모델보다 중요한 것은 시스템 설계 - AI Agent는 특별한 모델 자체라기보다, 도구 호출, 라우팅, 예외 처리, LLM 호출을 조합한 시스템 설계에 가깝다. - 기존 서비스 개발에서 사용하던 함수 분리와 조건 분기, 장애 대응 습관을 AI 시스템에도 적용할 수 있다. - LLM은 확률 모델이므로 매번 결과가 달라질 수 있어, 한 번의 뛰어난 답보다 일관된 출력과 안정적인 실행 흐름을 설계해야 한다. - Prompt Chaining으로 작업을 단계별로 나누고, Few-shot으로 출력 형식을 구체화하며, Routing으로 상황에 따라 프롬프트를 분기할 수 있다. ## 멀티 에이전트와 RAG·MCP의 결합 - 하나의 거대한 AI에 모든 역할을 맡기기보다 분석, 콘텐츠 생성 등 역할을 나눈 멀티 에이전트 구조가 더 빠르고 안정적일 수 있다. - 이는 기능과 책임을 분리하는 MSA의 설계 철학과 유사하다. - MCP는 내부 시스템의 데이터와 기능을 AI가 호출할 수 있는 Tool로 노출해, 원격 Function Calling처럼 활용하게 한다. - RAG는 문서를 청킹하고 유사 벡터를 검색해 관련 정보를 컨텍스트에 추가함으로써 할루시네이션을 구조적으로 줄인다. - AI를 잘 활용하려면 결과가 마음에 들지 않을 때 감정적으로 반응하기보다 목표, 출력 형식, 예시, 필요한 데이터와 컨텍스트를 명확히 정의해야 한다. 실무에서는 “무엇이 이론적으로 맞는가”보다 트래픽, 변경 가능성, 보안 위험, 운영 비용을 함께 검토해야 한다. DB 설계와 보안 점검, AI 기능 개발 모두를 일회성 작업이 아니라 지속적으로 관찰하고 개선하는 시스템으로 접근하는 것이 바람직하다.

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

엔터프라이즈 LLM 서비스 구축기 2: 에이전트 엔지니어링 (새 탭에서 열림)

엔터프라이즈 LLM 서비스를 구축함에 있어 복잡한 최신 기술을 무작정 도입하기보다, 서비스의 본질에 집중하여 불필요한 기술을 덜어내는 '소거법' 기반의 아키텍처를 설계했습니다. 실전 운영 결과, 파인 튜닝 대신 RAG를, 기계적 청킹 대신 '검색 후 자르기' 전략을, 그리고 복잡한 워크플로 대신 단순한 ReAct 구조를 채택함으로써 96.1%라는 높은 응답률과 시스템 안정성을 동시에 확보할 수 있었습니다. 이는 화려한 기술적 기교보다 제한된 비용과 속도 안에서 최적의 효율을 찾는 것이 실제 서비스 환경에서 더 효과적임을 입증합니다. ### 지식 주입 방식의 선택: 파인 튜닝 제외와 RAG 채택 * 파인 튜닝은 새로운 지식(Fact)을 주입하기보다 답변 스타일(Style)을 조정하는 데 훨씬 효율적이며, 지식 주입 정확도는 상대적으로 낮다는 연구 결과를 바탕으로 RAG를 주력 기술로 선정했습니다. * 제품 문서가 수시로 갱신되는 환경에서 파인 튜닝은 매번 데이터셋을 재구성하고 교차 검수해야 하는 막대한 유지보수 비용이 발생하지만, RAG는 원본 문서 업데이트만으로 즉각적인 대응이 가능합니다. * 실험 결과, 소규모 데이터셋을 통한 파인 튜닝은 모델이 이미 학습한 방대한 기존 지식의 벽을 넘지 못하고, 질문 형식이 조금만 바뀌어도 오답을 내놓는 한계를 보였습니다. ### 문맥 보존을 위한 전략: 청킹 없는 '검색 후 자르기' * 기존 RAG의 기계적 청킹(Pre-split)은 문맥 상실의 문제를 야기하므로, 각 문서의 주제가 명확하고 분량이 적은 서비스 특성을 고려해 문서를 통째로 임베딩하는 역발상을 적용했습니다. * 사용자 질문이 들어오면 관련 문서를 통째로 찾은 뒤, 마크다운 헤더(##) 기준으로 분할하고 경량 LLM 필터를 통해 질문과 관련 있는 섹션만 정밀하게 추출하는 '검색 후 자르기(Post-split)' 프로세스를 구축했습니다. * 이 방식은 질문의 맥락을 이미 알고 있는 상태에서 문서를 자르기 때문에, 정보의 희석 없이 모델에게 가장 필요한 핵심 조각들만 선별하여 전달할 수 있다는 장점이 있습니다. ### 효율적인 행동 구조: 복잡한 워크플로 대신 ReAct 방식 * '계획 후 실행(Plan-and-execute)'이나 '멀티 에이전트' 구조는 시스템 복잡도와 응답 지연(Latency)을 높일 뿐, 실제 답변 품질에서의 체감 성능 향상은 크지 않았습니다. * 특히 멀티 에이전트 구조는 전문가 간의 질문 배분 과정에서 추가적인 LLM 호출 비용이 발생하고, 여러 도메인이 섞인 질문에서 정보가 누락되는 취약점을 보였습니다. * 정제된 컨텍스트와 적절한 도구가 주어진다면 모델 스스로 추론하고 행동하는 ReAct 루틴만으로도 복잡한 논리적 순서를 충분히 구현할 수 있음을 확인하여, 시스템을 단순하게 유지했습니다. 성공적인 AI 에이전트 구축의 핵심은 유행하는 기술을 좇는 '덧셈'이 아니라, 서비스의 본질에 맞는 기술만 남기는 '뺄셈'에 있습니다. 현재 발생하는 답변 실패 원인의 절반 이상이 기술적 결함이 아닌 '참조 문서의 부재'에서 기인한다는 점을 고려할 때, 모델 아키텍처를 복잡하게 만들기보다는 AI가 학습하고 참조할 '교과서(원본 문서)'의 품질을 높이는 것이 성능 향상을 위한 가장 확실하고 실용적인 투자입니다.

aws원문

AWS 주간 요약: OpenAI 파트너십, AWS Elemental Inference, Strands Labs 등 (2026년 3월 2일) | 아마존 웹 서비스 (새 탭에서 열림)

AWS와 OpenAI의 대규모 전략적 파트너십 체결을 중심으로, 2026년 AWS는 기업들이 생성형 AI 실험 단계를 넘어 실제 비즈니스 가치를 창출할 수 있도록 지원하는 AI-DLC(AI-Driven Lifecycle) 프레임워크와 에이전트 중심의 기술 생태계를 강화하고 있습니다. 이번 파트너십을 통해 Amazon Bedrock에 OpenAI 모델 기반의 상태 유지 런타임 환경이 도입되며, AWS 전용 가속기인 Trainium 칩의 대규모 공급과 함께 보안, 미디어 처리, 인프라 관리 전반에 걸친 지능형 자동화 서비스들이 대거 출시되었습니다. **Amazon과 OpenAI의 전략적 파트너십 및 기술 통합** * **대규모 투자 및 독점 공급:** Amazon은 OpenAI에 총 500억 달러를 투자하며, AWS는 OpenAI Frontier 모델의 독점적 제3자 클라우드 배포처로서 기업용 에이전트 구축 및 관리를 지원합니다. * **Stateful Runtime Environment:** Amazon Bedrock 내에 OpenAI 모델을 기반으로 한 '상태 유지 런타임'을 구축하여, 개발자가 컨텍스트를 유지하고 다양한 소프트웨어 도구 및 데이터 소스에 걸쳐 작업을 수행할 수 있도록 합니다. * **커스텀 실리콘 협력:** OpenAI는 향후 8년 동안 AWS의 차세대 AI 칩인 Trainium3 및 Trainium4를 포함하여 약 2기가와트(GW) 규모의 연산 용량을 사용하기로 합의했습니다. **생성형 AI 에이전트 및 개발 생산성 강화** * **Amazon Bedrock Projects API:** OpenAI 호환 API를 사용하여 생성형 AI 워크로드를 애플리케이션 단위로 격리하고, 액세스 제어 및 비용 추적, 관측성을 개선할 수 있습니다. * **Strands Labs 신설:** 에이전트 중심의 AI 프로젝트를 실험하기 위한 별도의 조직을 구성하고 Robots, AI Functions 등 실험적 프로젝트를 오픈소스로 공개했습니다. * **Amazon Location Service LLM Context:** 위치 기반 기능을 구현할 때 AI 에이전트(Claude Code 등)가 활용할 수 있는 최적화된 컨텍스트를 제공하여 개발 속도와 정확도를 높였습니다. **미디어 처리 및 보안 운영의 자동화** * **AWS Elemental Inference:** AI를 활용해 라이브 및 주문형 비디오를 틱톡, 인스타그램 릴스용 세로 형식으로 자동 크롭하며, 6~10초의 짧은 지연 시간 내에 하이라이트 클립을 추출합니다. * **AWS Security Hub Extended:** CrowdStrike, Okta 등 주요 보안 파트너 솔루션을 AWS 통합 빌링과 사전 협의된 가격으로 손쉽게 배포 및 통합 운영할 수 있는 풀스택 보안 서비스를 제공합니다. * **AWS AppConfig & New Relic 통합:** 기능 플래그(Feature Flag) 배포 시 New Relic의 워크플로 자동화와 연동하여 이상 감지 시 즉각적인 지능형 롤백을 수행, 장애 대응 시간을 초 단위로 단축합니다. **성공적인 AI 도입을 위한 실무적 제언** 단순한 AI 기술 실험을 넘어 실제 운영 환경에 적용하려는 기업은 AWS가 제시하는 **AI-DLC(AI-Driven Lifecycle) 프레임워크**를 적극 활용할 것을 권장합니다. 특히 에이전트 기반 시스템 구축 시 발생할 수 있는 환각 현상을 줄이기 위해 단순 RAG 방식과 GraphRAG 방식을 비교 분석하고, 새롭게 오픈소스화된 EKS Node Monitoring Agent 등을 통해 인프라 가시성을 확보하는 것이 중요합니다.

dropbox원문

LLM을 활용한 인간 (새 탭에서 열림)

Dropbox Dash는 검색 관련성(Relevance)을 높이기 위해 소수의 고품질 인간 라벨링 데이터를 LLM을 통해 대규모로 증폭시키는 하이브리드 학습 전략을 채택하고 있습니다. 이 방식은 LLM을 '교사 모델'로 활용하여 수백만 개의 학습 데이터를 생성하고, 이를 통해 실시간 서비스에 적합한 효율적인 랭킹 모델을 구축하는 데 목적이 있습니다. 결과적으로 인간의 판단력과 AI의 확장성을 결합하여 RAG(검색 증강 생성) 시스템의 답변 품질을 결정짓는 핵심 요소인 검색 정확도를 극대화했습니다. ## Dash 검색 순위 모델과 학습 방식 * Dash는 수작업으로 조정된 규칙이 아닌, XGBoost와 같은 머신러닝 기법을 활용하여 검색 결과의 순위를 결정합니다. * 모델은 검색어와 문서 쌍에 대해 1점(관련 없음)부터 5점(매우 관련 있음)까지의 점수를 부여하는 관련성 라벨을 학습하며, 점수가 높은 문서가 상단에 배치되도록 가중치를 조정합니다. * 기업 내 수억 개의 문서 중 LLM이 답변 생성에 사용할 최적의 소수 문서만 선별해야 하므로, 랭킹 모델을 학습시키는 데이터의 품질이 RAG 시스템 전체의 성능을 좌우합니다. ## 기존 라벨링 방식의 한계와 LLM 도입의 필요성 * **사용자 행동 데이터:** 클릭이나 이탈 정보는 유용하지만, 기존 순위에 영향을 받거나 데이터가 불균등하게 분포되는 편향성 문제가 있습니다. * **인간 라벨링:** 숙련된 검토자가 직접 점수를 매기는 방식은 가장 정확하지만, 비용이 많이 들고 확장이 어려우며 기업의 민감한 내부 데이터를 외부 인력이 검토하기 어렵다는 보안 이슈가 존재합니다. * **LLM 평가:** LLM은 인간보다 비용이 저렴하고 일관성이 있으며, 대규모 후보군을 다국어로 신속하게 처리할 수 있습니다. 또한 정의된 규정 준수 범위 내에서 고객 콘텐츠를 분석할 수 있는 장점이 있습니다. ## 인간과 LLM의 협업을 통한 데이터 증폭 과정 * **검증 및 보정:** 먼저 인간 검토자가 소규모의 고품질 데이터셋을 라벨링합니다. 이 데이터는 LLM의 프롬프트와 매개변수를 미세 조정하고 성능을 검증하는 '골드 표준'으로 사용됩니다. * **데이터 증폭:** 성능이 검증된 LLM은 인간의 노력을 수백 배로 증폭시켜 수십만에서 수백만 개의 관련성 라벨을 생성합니다. 인간이 LLM을 가르치고, LLM이 대규모 학습 데이터를 생산하는 구조입니다. * **오프라인 학습과 온라인 서빙:** 실시간 검색 시 LLM을 직접 사용하면 지연 시간(Latency)과 비용 문제가 발생합니다. 따라서 LLM은 오프라인에서 '교사'로서 대량의 데이터를 생성하고, 실제 서비스에서는 이 데이터를 학습한 가볍고 빠른 모델(XGBoost 등)이 검색 순위를 계산합니다. ## 실용적인 결론 성공적인 AI 검색 시스템을 구축하기 위해서는 단순히 최신 LLM을 사용하는 것에 그치지 않고, 검색 모델의 학습 데이터를 어떻게 확보할 것인지가 중요합니다. Dropbox Dash의 사례처럼 **"인간의 가이드라인 → LLM의 대규모 라벨링 → 경량 모델의 학습 및 서빙"**으로 이어지는 파이프라인을 구축하면 품질, 비용, 속도라는 세 가지 토끼를 동시에 잡을 수 있습니다.

toss원문

Software 3.0 시대, Harness를 통한 조직 생산성 저점 높이기 (새 탭에서 열림)

현재 많은 개발팀이 LLM을 도입하고 있지만, 실제 생산성은 엔지니어 개개인의 'LLM 리터러시'에 따라 극심한 격차를 보이고 있습니다. 이러한 '각자도생'의 한계를 극복하기 위해서는 LLM을 개인의 도구가 아닌 팀 차원의 시스템으로 편입시켜 전체적인 생산성의 저점(Floor)을 높이는 전략이 필요합니다. Claude Code와 같은 생태계를 활용해 팀의 노하우를 '실행 가능한 지식(Executable SSOT)'으로 자산화하는 것이 Software 3.0 시대의 핵심 경쟁력이 될 것입니다. **컨텍스트 엔지니어링과 LLM 리터러시의 격차** * 단순 질문을 반복하는 방식과 작업 전 팀의 가이드라인, 린트 규칙, 코드 패턴 등 '컨텍스트'를 먼저 주입하는 방식은 결과물에서 큰 차이를 만듭니다. * 이러한 생산성 격차는 코딩 실력이 아닌 LLM을 제어하는 노하우의 차이이며, 이를 개인의 센스에만 맡기는 것은 조직적 손실입니다. * 팀 전체의 역량을 상향 평준화하기 위해서는 누구나 최적의 맥락 위에서 작업할 수 있도록 돕는 시스템적 장치(Harness)가 필요합니다. **Claude Code와 마찰 없는 워크플로우 이식** * 브라우저 기반 챗봇으로 코드를 복사·붙여넣기 하는 과정에서 발생하는 문맥 교환(Context Switching) 비용을 최소화해야 합니다. * Claude Code가 제공하는 TUI(Terminal User Interface) 환경은 터미널 안에서 자연어와 코드가 끊김 없이 섞이는 매끄러운 경험을 제공합니다. * 이러한 낮은 진입 장벽은 설계된 AI 워크플로우를 팀원들에게 저항감 없이 전파할 수 있는 기반이 됩니다. **실행 가능한 진실의 원천(Executable SSOT)** * 기존의 위키나 노션 문서는 작성 즉시 낡은 정보가 되지만, 플러그인 형태의 지식은 사람이 읽는 매뉴얼인 동시에 LLM이 즉시 실행하는 시스템 프롬프트가 됩니다. * RAG(검색 증강 생성) 방식은 내부 로직의 불투명성으로 인해 어떤 컨텍스트가 주입될지 예측하기 어렵다는 단점이 있습니다. * 반면 플러그인 방식은 명시적인 코드로서 개발자가 주입되는 맥락을 100% 통제할 수 있어 높은 예측 가능성과 신뢰성을 제공합니다. **계층화된 아키텍처를 통한 거버넌스와 전파** * 지식을 전사 공통(Global), 팀/비즈니스 도메인(Domain), 특정 프로젝트(Local)의 3단계 레이어로 계층화하여 관리함으로써 지식의 파편화를 방지합니다. * `/new-feature`와 같은 슬래시 커맨드를 통해 숙련된 엔지니어의 노하우(이슈 발급, 브랜치 생성, 구현 계획 수립 등)를 모든 팀원에게 즉시 배포할 수 있습니다. * 단순한 린터를 넘어, 메인 브랜치 커밋 시도를 감지하고 정책에 맞는 브랜치 생성을 가이드하는 등 AI 에이전트 기반의 강력한 거버넌스 구현이 가능합니다. **엔지니어링의 본질: 플랫폼 엔지니어링과 데이터 플라이휠** * Software 1.0 시대에 공통 라이브러리로 중복 작업을 줄였듯, Software 3.0에서는 AI 워크플로우 플러그인을 통해 팀의 생산성을 최적화해야 합니다. * 규격화된 플러그인을 통해 축적된 양질의 데이터는 향후 도메인 특화 모델(sLLM)을 파인튜닝하고 평가하는 기반이 됩니다. * 사용자가 많아질수록 데이터가 쌓이고 모델이 정교해지는 '데이터 플라이휠' 구조를 구축하는 것이 AI-Native 조직의 최종 목표입니다. 이제 LLM 활용 능력은 개인의 역량을 넘어 팀이 설계하고 배포해야 할 시스템의 영역입니다. Claude Code의 마켓플레이스와 같은 도구를 활용해 팀 내에 흩어진 암묵지를 명시적인 워크플로우로 엮어내고, 우리 조직에 최적화된 '시스템 하네스'를 구축하는 것부터 시작해 보기를 추천합니다.