line·2026년 6월 22일·5분 읽기큐레이션 요약

분석 에이전트의 힘으로 분석을 하나로 연결하다! 전문 조직에서 도전하는 생성 AI 시대의 업무 혁신과 역할 전환

PJ One Piece는 생성형 AI 에이전트로 비즈니스 질문, 데이터 분석, 결과 해석, 다음 액션까지 연결해 분석 업무의 단절을 없애려는 프로젝트입니다. 기존에 평균 2주 걸리던 분석을 약 10분 만에 수행할 수 있게 되었고, 사업부 구성원의 절반 이상이 사용하는 플랫폼으로 확산되었습니다. 핵심은 단순한 SQL 자동화가 아니라 도메인 지식, 분석 프로세스, 도구, 로그와 피드백을 결합해 조직의 분석 역량을 지속적으로 축적하는 데 있습니다. ## 프로젝트 출범 배경: 세 가지 단절 - **비즈니스와 데이터의 단절** - DWH와 BI가 있어도 SQL 작성, 테이블·컬럼 선택, KPI 정의, 결과 해석에는 높은 장벽이 남아 있었습니다. - 데이터에 접근할 수 있는 것과 사업 담당자가 필요한 정보를 스스로 얻는 것 사이에 ‘마지막 1마일’이 존재했습니다. - **분석 프로세스 내 단절** - 과제 정의, 분석 설계, 실행, 리뷰, 액션이 담당자와 도구의 차이로 분리되었습니다. - 사업 배경과 의사 결정 목적이 제대로 전달되지 않아 재작업이 발생했고, 단계 사이의 대기 시간으로 리드타임이 길어졌습니다. - 분석 품질이 균일하지 않고 결과가 실제 액션으로 이어지는 속도도 떨어졌습니다. - **도메인 간 단절** - 사업마다 KPI, 테이블 구조, 사용자 행동, 시책 맥락이 달라 분석 지식과 패턴이 특정 도메인에 머물렀습니다. - 시책 평가, 퍼널 분석, 원인 분석처럼 구조가 유사한 분석도 조직 전체에서 재사용하기 어려웠습니다. ## 분석 에이전트로 분석 흐름 연결 - 사용자는 채팅 형태의 화면에서 자연어로 질문을 입력합니다. - 에이전트는 질문의 목적을 해석하고 분석 계획을 세운 뒤 다음 작업을 수행합니다. - 필요한 데이터와 문서 탐색 - SQL·Python 기반 집계 및 분석 - 시각화와 보고서 작성 - 결과 해석과 추가 분석 제안 - 다음 의사 결정과 액션 검토 - 자연어 질문만으로 분석을 시작할 수 있어 사업 담당자가 데이터 사이언티스트에게 요청하고 기다리는 구조를 줄입니다. - 질문 정리, 지표 선택, 비교 축, 리뷰 관점, 추가 분석 판단을 로그로 남겨 분석 지식과 패턴을 재사용 가능한 자산으로 만듭니다. ## 분석 플랫폼을 구성하는 다섯 가지 요소 - 사용자와 상호작용하는 애플리케이션 - 추론과 도구 사용을 담당하는 LLM 기반 에이전트 - SQL·Python 실행, 사내 문서 조사, 시각화 도구 - 도메인 지식, 스킬, 테이블 정보를 제공하는 지식 베이스 - 실행 로그, 사용자 피드백, 모니터링과 평가를 담당하는 측정 시스템 - 지식 영역은 도메인별 플러그인으로 확장할 수 있으며, 사용량이 늘수록 지식과 분석 패턴이 축적됩니다. ## 자연어 질문을 분석 요구 사항으로 변환 - 사용자가 상세한 분석 설계를 직접 작성하도록 요구하지 않고, 에이전트가 부족한 전제 조건만 확인합니다. - 예를 들어 캠페인 효과 분석에는 대상 정책, 기간, KPI, 비교 대상, 분석 단위, 제외 조건 등이 필요합니다. - 서비스 이해, KPI 정의, 집계 주의사항, 정책 탐색 방법, 리뷰 관점은 도메인 지식으로 관리합니다. - 테이블과 컬럼의 의미, 사용 조건, 적절한 활용 상황도 별도로 정비합니다. - 에이전트는 이미 확정 가능한 항목과 사용자 확인이 필요한 모호한 항목을 구분해 불필요한 질문을 줄입니다. ## 필요한 데이터에 안전하게 접근하는 구조 - 대규모 테이블 정보를 한꺼번에 LLM에 제공하지 않고 단계적으로 공개합니다. - 먼저 테이블 목록으로 후보를 좁힘 - 선택한 테이블의 상세 정의 확인 - SQL 작성 전에 컬럼 설명, 샘플, 파티션 조건, 사용상 주의사항 확인 - 원천 테이블을 그대로 사용하지 않고, 분석에 적합한 속성을 결합한 와이드 테이블을 논리적 뷰나 실제 테이블로 제공합니다. - 복잡한 JOIN을 줄여 SQL 생성 난이도와 오류 가능성을 낮춥니다. - SQL 실행 전후에 시스템 차원의 가드레일을 적용합니다. - `SELECT` 중심의 읽기 전용 제한 - 공개된 테이블 정의 및 사용 규칙 검증 - 파티션 조건 확인 - 개인정보·민감 정보 접근 제한 - 결과 행 수 제어 ## 멀티 에이전트로 분석 맥락 유지 - 슈퍼바이저형 멀티 에이전트 구조를 사용합니다. - 메인 에이전트는 사용자 요청, 분석 목적, 확인된 내용, 다음 판단 과제를 계속 관리합니다. - 통계 검정, 시계열 분석, 클러스터링, 리뷰 등 전문 작업은 역할이 제한된 서브 에이전트에 위임합니다. - 전체 분석 설계와 전문 작업을 분리해 긴 시행착오나 전문 분석이 전체 맥락을 압박하지 않도록 합니다. - 장시간 분석 중에는 발견 사항, 분석 설계, 사용 가능·불가능한 데이터, 제약 조건을 공유해 사용자가 중간에 방향을 수정할 수 있게 합니다. ## 로그와 스킬을 통한 조직 자산화 - 실행 로그로 다음 내용을 추적합니다. - 입력과 출력 - 에이전트의 도구 사용 과정 - 전제 조건 확인 방식 - 분석 설계와 생성된 SQL - 오류가 발생한 지점 - 사용자와 분석 담당자의 피드백을 결합해 프롬프트, 도구, 데이터, 스킬 중 개선이 필요한 영역을 백로그로 관리합니다. - 반복되는 분석은 스킬로 일반화합니다. - 범용 스킬: 시계열 분석, 클러스터링 등 - 도메인 특화 스킬: 월간 보고서, 정책 모니터링 등 - 스킬에는 전제 조건, 비교 축, 주의사항, 결과 해석 방법까지 포함해 다른 담당자와 도메인에서도 재사용할 수 있도록 합니다. ## 선행 도입으로 확인한 사업 가치 - 일부 서비스 사업부에 도입한 결과 구성원의 절반 이상이 사용하는 분석 플랫폼으로 성장했습니다. - 데이터 사이언티스트뿐 아니라 프로덕트 오너와 현장 구성원도 일상 업무에서 먼저 질문하는 진입점으로 활용하고 있습니다. - 기존 요청부터 결과 회신까지 평균 약 2주 걸리던 분석을 약 10분 만에 실행할 수 있게 되었습니다. - 월 수백 건의 분석이 실행되며 데이터 활용 인원이 빠르게 증가했습니다. 분석 AI를 도입할 때는 SQL 생성 자동화에만 집중하기보다, 도메인 지식 관리·데이터 접근 통제·분석 맥락 유지·로그 기반 개선까지 함께 설계하는 것이 중요합니다. 특히 반복 분석을 스킬과 조직 자산으로 축적해야 단기적인 생산성 향상을 넘어 지속적으로 성장하는 분석 플랫폼을 만들 수 있습니다.

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

AI 에이전트대규모 언어 모델생성형 AIPython+4

github·2026년 6월 19일·4분 읽기큐레이션 요약

내부 데이터 분석 에이전트를 구축한 방법

GitHub는 사내 데이터 웨어하우스에 자연어로 질문하면 SQL을 작성하고 결과를 해석해 주는 GitHub Copilot 기반 분석 에이전트 ‘Qubot’을 구축했다. Qubot은 대시보드나 정기 리포트의 대체재가 아니라, 데이터 모델·필터·쿼리 작성법을 몰라도 탐색적 분석을 수행하도록 돕는 도구다. 핵심 성공 요인은 데이터에 대한 구조화된 컨텍스트와 자동화된 평가 체계이며, 이를 통해 분석 정확도뿐 아니라 응답 속도도 크게 향상됐다. ## Qubot의 목적과 활용 범위 - GitHub의 여러 제품·엔지니어링 팀이 데이터 분석가의 도움 없이 제품 텔레메트리를 활용하도록 지원한다. - 사용자는 다음과 같은 탐색적 질문을 자연어로 입력할 수 있다. - 특정 기능의 유지율이 가장 높은 사용자 코호트는 무엇인가? - 지난주 특정 지표의 변화에 가장 큰 영향을 준 제품은 무엇인가? - 정기 보고서나 대시보드를 대체하지 않고, 데이터셋을 빠르게 이해하고 가설을 검증하는 데 초점을 둔다. - 데이터 분석 지원 요청을 줄이고, 데이터 웨어하우스를 사용해 본 적이 적은 직원도 의사결정에 필요한 데이터를 직접 탐색할 수 있게 한다. ## 세 가지 핵심 구성 요소 Qubot은 사용자 인터페이스, 컨텍스트 계층, 쿼리 엔진으로 구성된다. - **사용자 인터페이스** - Slack, VS Code, Copilot CLI에서 사용할 수 있다. - Slack에서는 채널에 질문을 올리면 GitHub.com에서 Copilot Cloud Agent가 실행된다. - 답변은 Slack에 바로 게시되며, 스레드에서 질문을 추가로 구체화할 수 있다. - 분석 결과는 Markdown 보고서로 작성되어 Pull Request에 저장된다. - VS Code와 Copilot CLI에서는 플러그인 설치 후 다른 에이전트·스킬·도구와 함께 사용할 수 있다. - **컨텍스트 계층** - 데이터의 관리 수준에 따라 서로 다른 정보를 제공한다. - Bronze 데이터에는 제품 팀이 제공한 이벤트 스키마와 메타데이터가 포함된다. - Silver 데이터에는 예시 쿼리, 사용 지침, 필수 필터 등이 포함된다. - Gold 데이터에는 해당 데이터셋을 소유한 팀이 정의한 비즈니스 규칙과 지표 정의가 포함된다. - ETL 파이프라인이 추가 신호와 파생 메타데이터를 자동으로 보강한다. - 에이전트는 실행 시점에 GitHub MCP Server를 통해 필요한 컨텍스트를 가져온다. - **쿼리 엔진** - GitHub의 주요 분석 엔진인 Kusto와 Trino를 MCP 서버로 연결한다. - Kusto는 최근 이벤트 데이터를 빠르게 탐색하는 데 적합하다. - Trino는 복잡한 조인과 장기간의 이력 분석에 적합하다. - 사용자가 엔진을 직접 선택하지 않아도 Qubot이 기본적으로 Kusto를 사용하고, 복잡한 질문에는 Trino로 자동 전환한다. ## 컨텍스트 에이전트와 지식 관리 - 컨텍스트 정보는 여러 저장소에 Markdown 형태로 관리된다. - 팀은 표준 템플릿을 사용하거나 관련 컨텍스트가 있는 저장소를 참조해 지식을 기여할 수 있다. - 컨텍스트 에이전트가 정보를 수집한 뒤 정리·정규화해 Qubot이 활용하기 쉬운 구조로 변환한다. - 데이터 모델 자체보다 데이터의 의미, 올바른 필터, 지표 정의, 사용 사례를 함께 제공하는 것이 에이전트의 분석 품질을 높이는 핵심이다. ## 자동화된 평가 프레임워크 - 컨텍스트나 에이전트 설정이 변경될 때마다 배포 전에 오프라인 평가를 수행한다. - 평가 대상은 정확도뿐 아니라 적절한 답을 찾는 데 걸리는 시간과 기존 기능의 회귀 여부다. - 평가 프레임워크는 다음 세 부분으로 구성된다. - **테스트 케이스**: 정답, 기준 SQL, 도메인, 난이도를 포함한 표준 질문 집합 - **실행 오케스트레이션**: GitHub CLI의 `gh agent-task create`를 이용해 테스트를 병렬 실행하고 JSON 결과를 저장 - **통계 집계**: 테스트별 완료율, 정확도, 평균·최소·최대 소요 시간을 계산 - 전체 과정은 테스트 정의 → 여러 차례 실행 → 결과 수집 → 통계 집계 → 설정 비교 순서로 진행된다. - 이를 통해 컨텍스트 추가나 에이전트 변경이 실제 품질 향상으로 이어지는지 검증할 수 있다. ## 도입 효과와 핵심 교훈 - Qubot은 수백 명의 사용자가 수천 건의 쿼리를 실행할 정도로 확산됐다. - 데이터·분석 Slack 채널에 반복적으로 들어오던 질문이 크게 줄었다. - 사용자는 간단한 질문을 직접 해결하고, 분석 전문가는 더 복잡한 문제에 집중할 수 있게 됐다. - Slack, VS Code, Copilot CLI를 함께 제공해 기술 수준과 업무 방식에 따른 진입 장벽을 낮췄다. - 실험 결과, 잘 구조화되고 큐레이션된 컨텍스트는 Qubot의 정확도를 높였을 뿐 아니라 올바른 답을 반환하는 속도도 약 3배 향상시켰다. - 따라서 데이터 문서, 지표 정의, 사용 규칙 같은 컨텍스트 자산을 단순한 문서가 아니라 분석 시스템의 핵심 구성 요소로 관리해야 한다. 실무적으로는 처음부터 모든 데이터를 자동 분석하려 하기보다, 자주 묻는 도메인부터 표준화된 컨텍스트와 기준 테스트를 구축하는 접근이 적합하다. 또한 여러 쿼리 엔진을 사용한다면 사용자가 엔진을 선택하지 않아도 되도록 에이전트가 질문 특성에 따라 자동 라우팅하도록 설계하는 것이 좋다.

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

AI 에이전트모델 컨텍스트 프로토콜slackgithub-copilot+4

cloudflare·2026년 6월 19일·3분 읽기큐레이션 요약

AI 에이전트를 위한 임시 Cloudflare 계정

Cloudflare는 AI 에이전트가 사람의 개입 없이 코드를 배포할 수 있도록 ‘임시 계정’을 출시했다. 에이전트는 `wrangler deploy --temporary`를 실행해 별도 회원가입이나 OAuth, API 토큰 입력 없이 Worker를 배포하고, 60분 동안 결과를 테스트할 수 있다. 사용자가 그 안에 계정을 클레임하면 영구 계정이 되며, 클레임하지 않으면 자동 삭제된다. ## AI 에이전트 배포에서 인증이 걸림돌이 되는 이유 - 기존 클라우드 서비스 가입 과정은 브라우저 OAuth, 대시보드 조작, API 토큰 복사, MFA 입력 등 사람을 전제로 한다. - 백그라운드에서 실행되는 AI 에이전트는 브라우저를 열거나 사용자의 즉각적인 확인을 기다리기 어렵다. - 인증 단계에서 멈추면 에이전트가 다른 배포 서비스를 선택할 가능성도 있다. - 에이전트는 코드를 작성하고 배포한 뒤 직접 요청을 보내 검증하는 반복 작업이 중요하므로, 빠르고 저렴한 임시 배포 환경이 필요하다. ## `wrangler deploy --temporary`를 통한 배포 - 최신 Wrangler CLI에서 다음 명령으로 임시 계정에 Worker를 배포할 수 있다. ```bash wrangler deploy --temporary ``` - 사용자가 Cloudflare에 로그인하지 않은 상태에서 배포를 시도하면 Wrangler가 `--temporary` 옵션을 안내한다. - 에이전트가 해당 옵션으로 다시 배포하면 Cloudflare가 자동으로: - 임시 Cloudflare 계정을 생성하고 - Wrangler가 사용할 API 토큰을 발급하며 - 사용자가 계정을 인수할 수 있는 클레임 URL을 제공한다. - 에이전트는 별도의 사람 확인 없이 코드를 작성하고 즉시 배포할 수 있다. ## 작성·배포·검증의 반복 루프 - 에이전트는 TypeScript Worker를 생성한 뒤 배포 결과로 받은 미리보기 URL에 `curl` 등을 실행해 동작을 검증한다. - 예를 들어 “hello world” Worker를 배포한 뒤 응답이 코드와 일치하는지 확인할 수 있다. - 이후 소스 코드를 수정하고 같은 임시 계정을 재사용해 여러 번 재배포할 수 있다. - 임시 계정은 60분의 클레임 기간 동안 유지되므로, 에이전트가 여러 차례 수정·테스트하는 데 적합하다. ## 임시 계정의 클레임과 자동 삭제 - 사용자는 에이전트가 제공한 클레임 링크를 클릭해 Cloudflare에 가입하거나 로그인할 수 있다. - 계정을 클레임하면 임시 계정이 영구적으로 사용자의 계정이 된다. - Worker뿐 아니라 데이터베이스와 기타 바인딩 리소스도 함께 인수할 수 있다. - 60분 이내에 클레임하지 않으면 임시 계정과 배포된 리소스가 자동으로 삭제된다. ## 더 넓은 에이전트용 인프라 - Cloudflare는 Stripe와 협력해 에이전트가 사용자를 대신해 계정 생성, 구독 시작, 도메인 등록, API 토큰 발급까지 수행할 수 있는 프로토콜도 개발하고 있다. - WorkOS와는 기존 OAuth 표준을 활용해 에이전트가 계정을 생성할 수 있도록 하는 `auth.md` 프로젝트를 추진했다. - 임시 계정은 이러한 ‘에이전트 친화적 배포’ 전략의 한 단계로 소개된다. - 기능과 제한 사항은 변경될 수 있으므로 실제 사용 전 Cloudflare 개발자 문서를 확인해야 한다. 에이전트가 짧은 실험이나 프로토타입을 자동으로 배포·검증해야 한다면 `wrangler deploy --temporary`가 유용하다. 다만 60분 내에 클레임하지 않으면 리소스가 삭제되므로, 장기 운영 서비스는 반드시 계정을 클레임하고 정식 인증·관리 체계로 전환해야 한다.

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

AI 에이전트TypeScriptCloudflare Workersstripe+4

cloudflare·2026년 6월 18일·4분 읽기큐레이션 요약

나만의 취약점 테스트 하네스 구축하기

프론티어 모델 하나에 의존하는 대신, 모델을 교체할 수 있는 취약점 분석 하니스(harness)를 구축해야 한다는 글입니다. 하니스는 정찰·탐색·검증·중복 제거·재검증·트리아지를 지속적으로 수행하며, 수천 개의 후보를 실행 가능한 취약점 목록으로 줄입니다. 핵심은 LLM을 상태를 보존하지 않는 계산 엔진으로 취급하고, 분석 상태와 결과를 데이터베이스 및 파이프라인에 외부화하는 것입니다. ## 단일 에이전트 방식의 한계 - 일반적인 코딩 에이전트는 한 번에 하나의 가설만 유지하므로 대규모 저장소의 여러 공격 경로를 동시에 분석하기 어렵습니다. - 컨텍스트 창이 가득 차면 컨텍스트 압축 과정에서 이전에 발견한 버그나 분석 근거를 잃을 수 있습니다. - 단일 저장소만 분석하면 다른 애플리케이션·라이브러리·서비스와의 연결에서 발생하는 취약점을 놓칩니다. - 한 번 실행한 결과는 전체 버그의 약 절반 정도만 찾으며, 비교적 단순한 취약점에 편향되는 경향이 있습니다. - 분석을 여러 번 실행한 뒤 결과를 사람이 직접 비교해야 한다면, 이미 전용 하니스가 필요한 단계에 도달한 것입니다. ## 모델에 독립적인 하니스가 필요한 이유 - 특정 모델에 시스템을 맞추면 해당 모델이 코드를 바라보는 방식에 분석 범위가 고정됩니다. - 서로 다른 모델을 같은 코드에 적용하면 각 모델이 서로 다른 취약점을 발견할 수 있습니다. - 예를 들어 한 모델은 초기 탐색을 담당하고, 다른 모델은 발견된 취약점의 재현 가능성과 타당성을 검증하도록 구성할 수 있습니다. - 모델이 교체되거나 더 뛰어난 모델이 등장해도 하니스의 상태 관리·오케스트레이션·트리아지 구조는 그대로 유지할 수 있습니다. - 따라서 장기적으로 중요한 자산은 특정 프롬프트나 모델보다 모델을 연결하고 결과를 관리하는 하니스입니다. ## 초기 보안 감사 스킬 처음에는 약 450줄 규모의 `security-audit` 스킬을 단일 저장소에서 실행하며 프롬프트를 조정했습니다. 이후 이 스킬의 단계가 전체 하니스의 기본 구조로 확장되었습니다. - **정찰(Recon)** - 세 개의 병렬 연구 에이전트가 저장소 구조와 아키텍처를 조사합니다. - 결과를 `architecture.md`에 기록합니다. - **공격 탐색(Hunt)** - 공격 클래스별로 Hunter 에이전트를 실행합니다. - 코드를 검토하는 데 그치지 않고 실제로 깨뜨리는 시도를 합니다. - **검증(Validate)** - 적대적 검증 에이전트가 각 발견을 반박하려고 시도합니다. - 재현되지 않거나 근거가 약한 후보를 제거합니다. - **보고서 작성(Report)** - 살아남은 취약점을 사람이 읽을 수 있는 보고서로 정리합니다. - **기계적 검증** - `findings.json`을 정해진 스키마에 맞춰 생성합니다. - 파일 형식뿐 아니라 취약점에 언급된 함수와 줄 번호가 실제 소스에 존재하는지도 검사합니다. - **독립 재검증** - 별도의 새로운 에이전트가 소스를 기준으로 모든 발견을 다시 확인합니다. - 최종 생존 항목만 수집 API로 제출합니다. ## 파이프라인으로의 확장 초기 스킬의 단계는 다음과 같이 하니스의 파이프라인으로 대응됩니다. - `architecture.md`를 생성하는 연구 에이전트 → **Recon** - 공격 유형별 Hunter → **Hunt** - 발견을 반박하는 Validator → **Validate** - 검증된 항목의 보고서화 → **Report** - `findings.json`의 스키마 및 소스 위치 검사 → **기계적 검증** - 새로운 에이전트의 최종 확인 → **독립 검증** 이 구조는 한 번의 긴 세션에 모든 작업을 몰아넣지 않고, 각 작업을 독립적으로 실행·저장·재시작할 수 있게 합니다. ## 상태를 외부화해야 하는 이유 - **컨텍스트 고갈** - 장시간 실행하면 모델이 기존 분석 내용을 잊습니다. - 분석 상태, 가설, 조사 결과, 발견 사항을 데이터베이스 등에 저장해 모델의 기억에 의존하지 않도록 해야 합니다. - LLM은 상태를 가진 작업자라기보다 필요할 때 호출되는 계산 엔진으로 취급합니다. - **지속성 부족** - 네트워크 오류, API 제한, 프로세스 충돌이 발생해도 처음부터 다시 시작해서는 안 됩니다. - 각 단계의 진행 상황과 결과를 저장하면 중단된 지점부터 재개할 수 있습니다. - **재범위 지정과 교차 참조** - 독립적인 조사 결과를 나중에 다시 불러오고, 다른 발견이나 저장소와 연결할 수 있어야 합니다. - 수백 개의 조사를 별도의 실행 단위로 유지해야 중복 제거와 후속 검증이 가능합니다. ## 대규모 트리아지와 교차 저장소 분석 - 엔터프라이즈 환경에서는 원시 취약점 후보가 수천 개 생성될 수 있습니다. - 하니스는 후보를 수집하는 것에서 끝나지 않고, 검증·중복 제거·우선순위 지정 과정을 거쳐 신뢰할 수 있는 수정 큐로 줄여야 합니다. - 단일 저장소 분석만으로는 해당 저장소를 사용하는 애플리케이션과의 인터페이스 문제를 볼 수 없습니다. - 여러 저장소 간 의존성과 데이터 흐름을 추적하면 구성 요소 사이에서만 드러나는 취약점을 찾을 수 있습니다. - 다만 교차 저장소 추적은 초기 구현부터 넣기보다, 실제로 중요한 저장소가 여러 개일 때 도입하는 것이 권장됩니다. ## 단계적으로 구축하는 방법 - 최소한의 하니스는 데이터베이스에 상태를 저장하는 **Recon, Hunt, Validate** 세 단계로 시작할 수 있습니다. - 자기 자신이 발견 사항을 제출하지 못하는 별도의 Validator를 두어 검증 편향을 줄입니다. - 먼저 개발 환경에서 단일 스킬로 프롬프트와 공격 시나리오를 충분히 다듬습니다. - 다음 기능은 현재의 병목이 명확해졌을 때만 추가합니다. - 중단 후 재개가 문제라면 영속성 추가 - 결과가 너무 많으면 중복 제거 에이전트 추가 - 여러 저장소가 실제 분석 대상이 되면 교차 저장소 추적 추가 - 초기부터 전부 자동화하기보다, 현재 작업을 가장 느리게 만드는 문제를 해결하는 방향으로 하니스를 확장해야 합니다. 실용적으로는 특정 모델이나 프롬프트에 시스템을 종속시키지 말고, 분석 상태·발견 사항·검증 결과를 저장하는 모델 독립적 파이프라인부터 구축하는 것이 좋습니다.

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

AI 에이전트vulnerability-scanningsecurity-auditllm-orchestration+3

stripe·2026년 6월 18일·3분 읽기큐레이션 요약

링크 데이터가 AI 지출에 대해 말해주는 것

Stripe의 디지털 지갑 Link 사용자들은 AI 제품과 서비스에 대한 지출을 빠르게 늘리고 있다. 특히 AI 앱 빌더 플랫폼에 대한 투자가 두드러지며, 이는 AI를 단순히 사용하는 단계를 넘어 직접 구축하려는 수요가 커지고 있음을 보여준다. Stripe는 이러한 에이전트 중심 소비 흐름에 대응해, 사용자가 지출 한도를 설정하고 AI 에이전트가 대신 결제할 수 있는 Link 지갑을 개발했다. ### AI 제품에 대한 지출 증가 - Stripe는 Link 사용자 2억 5천만 명의 결제 데이터를 분석해 AI 관련 소비 패턴을 조사했다. - AI 제품 지출 상위 10% 고객의 월평균 지출은 다음과 같이 증가했다. - 2025년 12월: 183달러 - 2026년 3월: 359달러 - 183달러에서 359달러로 증가하는 데 걸린 기간은 단 3개월로, 한 분기 만에 거의 두 배가 됐다. - 같은 고객군이 월 지출을 84달러에서 183달러로 늘리는 데는 22개월이 걸렸다는 점에서 최근 성장 속도가 크게 빨라졌다. - 중간 수준인 50백분위 고객의 월평균 지출도 같은 기간 60달러에서 72달러로 증가했다. ### AI 앱 빌더 플랫폼의 가파른 성장 - Replit, Lovable, Bolt와 같은 AI 기반 앱 빌더 플랫폼에서 지출 증가폭이 특히 크게 나타났다. - AI 제품 지출 상위 10% 고객은 2025년 1월과 비교해 해당 플랫폼에 매달 약 5배 더 많이 지출하고 있다. - 이는 소비자와 개발자가 AI 서비스를 단순 이용하는 것을 넘어, AI를 활용해 애플리케이션과 제품을 직접 만들려는 흐름이 강해졌음을 의미한다. ### 채팅형 에이전트와 쇼핑 행동 - Stripe가 394명의 Link 고객을 대상으로 조사한 결과: - 80%는 최근 한 달 동안 채팅형 에이전트를 사용했다. - 절반은 적어도 매달 한 번 AI를 쇼핑 조사에 활용했다. - AI 에이전트가 상품을 검색하고 비교하는 수준을 넘어 실제 구매까지 수행하려면 결제 권한과 안전장치가 필요하다. - 따라서 AI 사용 증가는 향후 에이전트가 소비자의 구매 과정에 직접 참여하는 방향으로 이어질 가능성이 있다. ### 에이전트 결제를 위한 Link 지갑 - Stripe는 AI 에이전트가 사용자를 대신해 결제할 수 있도록 ‘Link’s wallet for agents’를 구축했다. - 주요 기능은 다음과 같다. - 사용자가 에이전트의 결제 권한을 직접 승인 - 사용자가 설정한 지출 한도와 통제 조건 적용 - Stripe를 사용하는 모든 판매자에게 폭넓게 구매 가능 - 사업자는 복잡한 별도 연동 없이 검증된 거래를 수신 - 이를 통해 AI 에이전트의 자율적인 구매와 사용자의 통제 사이의 균형을 맞추려 한다. ### 실용적인 시사점 - AI 서비스 기업은 단순한 챗봇 기능보다 실제 작업 수행과 결제까지 연결되는 에이전트 경험을 고려할 필요가 있다. - 앱 빌더 플랫폼과 개발 도구 분야는 AI 투자 확대의 직접적인 수혜 영역으로 볼 수 있다. - 에이전트 결제를 도입할 때는 지출 한도, 사용자 승인, 거래 검증 등 통제 기능을 핵심 설계 요소로 삼아야 한다.

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

AI 에이전트stripeagentic-commercereplit+4

gitlab·2026년 6월 18일·3분 읽기큐레이션 요약

거버넌스 및 운영을 위한 AI 카탈로그 업데이트

GitLab 19.1은 Duo Flows를 실제 GitLab 이벤트에 따라 자동 실행할 수 있게 하며, AI 자동화를 지속적이고 무인으로 운영할 기반을 제공합니다. 동시에 관리자용 에이전트·플로우 통제, 설정 사전 검증, 승인된 AI 모델 목록 관리 기능을 추가해 엔터프라이즈 환경의 보안성과 신뢰성을 강화합니다. 결과적으로 개발자는 반복적인 수동 실행에서 벗어나고, 관리자는 조직에서 실행되는 AI를 통제할 수 있습니다. ## 이벤트 기반 Duo Flows 자동 실행 - 기존 Duo Flow는 사용자가 GitLab UI에서 멘션, 할당, 리뷰어 지정 등을 직접 수행해야 실행할 수 있었습니다. - GitLab 19.1에서는 다음 이벤트를 트리거로 사용할 수 있습니다. - **머지 리퀘스트 코드 충돌 감지**: 충돌 발생 즉시 요약과 해결 제안 실행 - **Draft에서 Ready for review로 변경**: 자동 컴플라이언스 검사나 사전 병합 체크 실행 - **머지 리퀘스트 승인**: 배포 준비 상태 확인, 컴플라이언스 기록, 인수인계 알림 실행 - **Work item 생성**: 자동 분류, 라벨 지정, 담당 팀 라우팅 실행 - 파이프라인 이벤트는 성공, 실패, 취소 등 특정 상태만 필터링할 수 있습니다. - 실패 시 인시던트 생성 - 성공 시 아티팩트 승격 - 취소 시 별도 후속 처리 - 코드 충돌 감지와 Draft→Ready for review 트리거는 기본 활성화됩니다. - 로컬에서 에이전트를 사용할 때는 패턴 기반 승인 기능을 통해 세션 동안 특정 도구 사용을 일괄 승인할 수 있어, 반복적인 파일 수정이나 `npm install` 과정에서 재승인할 필요가 줄어듭니다. ## 승인되지 않은 에이전트와 플로우 차단 - 인스턴스 관리자와 최상위 그룹 소유자는 조직에서 실행 가능한 AI 콘텐츠의 범위를 제한할 수 있습니다. - **Disable custom agents and flows** - 사용자가 사용자 정의 에이전트와 플로우를 생성하거나 활성화하지 못하게 합니다. - 검토된 기본 제공 콘텐츠 중심으로 사용을 제한합니다. - **Restrict the AI catalog to your group hierarchy** - 자신의 네임스페이스 외부에서 제공되는 AI Catalog 항목을 활성화하지 못하게 합니다. - 커뮤니티 및 서드파티 플로우가 보안 검토 없이 도입되는 것을 방지합니다. - 두 설정을 함께 사용하면 AI 활용은 허용하면서도 검증되지 않은 에이전트가 운영 환경에 확산되는 문제를 통제할 수 있습니다. ## 저장 전에 플로우 설정 검증 - 사용자가 AI Catalog의 플로우를 저장하거나 수정하면 GitLab이 Duo Workflow Service를 통해 설정을 검증합니다. - 누락된 입력값이나 알 수 없는 도구 파라미터 같은 오류가 저장 전에 구조화된 형태로 UI에 표시됩니다. - 잘못된 플로우가 운영 중 처음 발견되는 대신, 설정 단계에서 즉시 수정할 수 있습니다. - 자동 트리거는 잘못 구성될 경우 반복 실행과 불필요한 알림을 일으킬 수 있으므로 사전 검증의 중요성이 큽니다. ## 승인된 AI 모델만 사용하도록 제한 - 공개 베타 기능으로 관리자는 조직에서 사용할 수 있는 AI 모델의 allowlist를 설정할 수 있습니다. - 조직 전체의 기본 모델도 지정할 수 있으며, 사용자는 허용된 범위 안에서 모델을 선택할 수 있습니다. - 데이터 레지던시 요건이나 사내 승인 절차를 통과한 제공업체만 사용하도록 제한할 수 있습니다. - 초기 적용 범위는 GitLab Duo Agentic Chat이며, 향후 다른 기능 영역으로 확대될 예정입니다. ## 운영 환경을 위한 AI 자동화 기반 - 이벤트 기반 실행으로 사람이 버튼을 누르지 않아도 반복적인 검토, 분류, 알림, 배포 후속 작업을 수행할 수 있습니다. - 관리자는 실행 가능한 에이전트·플로우·모델을 통제하고, 개발자는 자동화 설정 오류를 운영 장애 전에 발견할 수 있습니다. - 도입 시에는 먼저 승인된 모델과 콘텐츠 범위를 정한 뒤, 실패 파이프라인이나 머지 리퀘스트 준비 완료 같은 명확한 이벤트부터 플로우를 단계적으로 적용하는 것이 좋습니다.

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

AI 에이전트CI/CDgitlabDevSecOps+3

gitlab·2026년 6월 18일·4분 읽기큐레이션 요약

GitLab 19.1 릴리스 노트 | GitLab Docs

GitLab 19.1은 GitLab Duo의 보안·거버넌스를 강화하고, 시크릿 탐지와 코드 리뷰 자동화를 개선한 릴리스다. 특히 AI가 시크릿 탐지의 오탐 가능성을 분석하고, 관리자가 Duo 사용과 에이전트 도구 실행을 중앙에서 통제할 수 있게 됐다. 또한 규정 준수 템플릿, Code Owner 자동 리뷰어 지정, 기능 브랜치의 전체 커밋 대상 시크릿 검사 등이 추가됐다. ## GitLab Duo 기반 시크릿 오탐 탐지 - GitLab Duo Agent Platform에서 시크릿 탐지 결과의 오탐 여부를 자동 분석하는 기능이 정식 출시됐다. - 보안 스캔 후 각 **Critical·High 심각도** 시크릿 취약점을 자동으로 분석한다. - 취약점 상세 화면에서 개별 항목을 수동으로 분석할 수도 있다. - 분석 결과는 취약점 리포트에 기존 심각도, 상태, 수정 정보와 함께 표시된다. - 코드 문맥과 취약점 특성을 기반으로 실제 시크릿일 가능성에 대한 AI 설명을 제공한다. - 신뢰도 점수를 통해 보안팀이 검토 우선순위를 정할 수 있다. - 오탐 조사에 드는 시간을 줄이고, 실제 보안 위험에 집중하도록 돕는다. - GitLab Ultimate에서 제공된다. ## GitLab Duo 항상 켜기 설정 - 관리자가 인스턴스 전체 또는 최상위 그룹에서 GitLab Duo를 **Always on**으로 설정할 수 있다. - 항상 켜짐 상태에서는 그룹·하위 그룹·프로젝트 소유자가 Duo를 비활성화할 수 없다. - 기존의 **Always off** 설정과 대칭적인 기능으로, 조직 차원의 AI 사용 정책을 일관되게 적용할 수 있다. - 규제 산업이나 여러 자회사·사업부에서 공통 AI 도구 사용을 보장해야 하는 경우 유용하다. - 인스턴스 또는 최상위 그룹의 GitLab Duo 설정에서 가용성을 Always on으로 지정한다. - Premium 및 Ultimate에서 제공된다. ## Code Owner 자동 리뷰어 지정 - 기존에는 CODEOWNERS 파일이 있어도 머지 리퀘스트마다 리뷰어를 수동 지정해야 했다. - 이제 변경된 파일과 일치하는 모든 Code Owner를 리뷰어로 자동 지정할 수 있다. - 머지 리퀘스트가 준비 상태로 생성되거나, Draft에서 Ready 상태로 전환될 때 동작한다. - 사용자가 이미 리뷰어를 지정했다면 자동 지정은 건너뛰고 기존 선택을 유지한다. - `Settings > Merge requests > Automatic reviewer assignment`에서 활성화할 수 있다. - Premium 및 Ultimate에서 제공된다. ## 규정 준수 프레임워크 템플릿 - Compliance Center에서 사전 정의된 템플릿으로 규정 준수 프레임워크를 생성할 수 있다. - 요구사항과 통제 항목을 일일이 수동 작성하지 않아도 된다. - 템플릿을 미리 보고 이름, 설명, 색상을 수정한 뒤 그룹에 적용할 수 있다. - ISO 27001:2022, SOC 2, FedRAMP, NIST, CIS, TISAX 등 총 19개 템플릿이 제공된다. - 베타 기능이며 GitLab Ultimate에서 제공된다. ## 기능 브랜치 시크릿 탐지 범위 개선 - 이전 버전에서는 새 브랜치의 최신 커밋만, 기존 브랜치는 가장 최근 푸시만 검사했다. - 과거 커밋에 포함된 자격 증명이 탐지되지 않은 채 공유 브랜치나 운영 환경으로 유입될 수 있었다. - GitLab 19.1부터는 기능 브랜치가 기본 브랜치에서 분기된 시점부터 최신 커밋까지 모든 커밋을 검사한다. - 시크릿이 개발 초기 단계에서 발견되므로 자격 증명 교체와 사고 대응 비용을 줄일 수 있다. - Free, Premium, Ultimate 모든 등급에서 제공된다. ## GitLab Duo 에이전트 도구 승인 가드레일 - 관리자가 Duo 에이전트의 도구별 실행 정책을 설정할 수 있다. - 각 도구에 다음 세 가지 모드 중 하나를 지정한다. - **Allow**: 승인 없이 실행 - **Ask**: 실행 직전에 사용자 승인 필요 - **Deny**: 실행 차단 - 이전에는 프로젝트에서 AI 에이전트를 승인하면 쓰기 작업이나 삭제 같은 민감한 도구도 추가 검토 없이 실행될 수 있었다. - `Ask` 도구가 호출되면 인라인 승인 카드가 표시되고, 사용자가 승인해야 실행된다. - Agentic Chat, IDE, Flows에 적용된다. - 모든 승인·거부 결정은 감사 이벤트로 기록된다. - 베타 기능이며 Premium 및 Ultimate에서 제공된다. ## 사용자 지정 AI 에이전트와 외부 기능 제어 - 관리자와 최상위 그룹 소유자가 조직 내에서 사용할 수 있는 AI 에이전트와 플로우를 통제할 수 있다. - 사용자가 사용자 지정 에이전트와 플로우를 생성하거나 활성화하지 못하도록 제한할 수 있다. - 그룹 계층 외부 프로젝트가 소유한 에이전트와 플로우의 활성화도 차단할 수 있다. - 중앙에서 승인한 AI 자동화만 사용하도록 정책을 적용하고, 신뢰할 수 없는 외부 콘텐츠 노출을 줄일 수 있다. - Premium 및 Ultimate에서 제공된다. ## 사용자 지정 플로우 YAML 사전 검증 - AI Catalog가 사용자 지정 플로우의 YAML 설정을 저장하거나 실행하기 전에 검증한다. - 누락된 입력값, 알 수 없는 도구 매개변수, 문법 오류 등을 UI에서 즉시 확인할 수 있다. - 이전에는 CI 작업이 시작된 뒤 런타임에서 오류가 발생해 디버깅이 늦어질 수 있었다. - 유효한 플로우는 기존처럼 저장하고 실행할 수 있다. - Premium 및 Ultimate에서 제공된다. ## Agentic Chat의 패턴 기반 도구 승인 - 릴리스 노트 후반부에서는 Agentic Chat을 위한 패턴 기반 도구 승인 기능도 소개되기 시작한다. - 제공된 내용에서는 기능의 세부 동작과 정책 설정 방식이 생략되어 있어, 구체적인 요건은 전체 릴리스 노트를 확인해야 한다. 이번 릴리스는 AI 기능을 단순히 확대하는 데 그치지 않고, 조직 차원의 사용 강제, 도구별 승인, 외부 에이전트 제한, 감사 기록을 통해 통제 가능한 AI 운영을 강화한 것이 특징이다. 동시에 기능 브랜치 전체 커밋 검사와 자동 Code Owner 리뷰어 지정으로 개발·보안 workflow의 누락도 줄였으므로, GitLab Duo와 보안 스캔을 사용하는 조직이라면 관련 설정을 검토할 만하다.

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

AI 에이전트CI/CDgitlabyaml+4

github·2026년 6월 17일·4분 읽기큐레이션 요약

각 토큰에서 더 많은 것을 얻기: Copilot이 컨텍스트 처리와 모델 라우팅을 개선하는 방법

GitHub Copilot은 에이전트형 작업이 길어질수록 단순히 토큰을 줄이는 것이 아니라, 반복되는 컨텍스트와 도구 정의를 효율적으로 재사용하고 작업에 맞는 모델을 선택해야 한다고 설명합니다. 이를 위해 VS Code에서는 프롬프트 캐싱과 지연된 도구 로딩을 개선하고, Auto 기능은 작업 난이도와 실시간 모델 상태를 바탕으로 적절한 모델로 라우팅합니다. 목표는 품질을 유지하면서 불필요한 비용과 지연을 줄이는 것입니다. ## 프롬프트 캐싱과 지연된 도구 로딩 - 긴 Copilot 세션에는 지침, 저장소 컨텍스트, 대화 기록, 도구 목록, 작업 상태 등 반복적으로 전달되는 정보가 많습니다. - **프롬프트 캐싱**은 반복되는 프롬프트 접두부의 모델 상태를 재사용해 매 요청마다 같은 내용을 다시 계산하지 않도록 합니다. - **도구 검색(tool search)**은 모든 도구의 전체 스키마를 처음부터 컨텍스트에 포함하지 않고, 모델이 필요할 때 관련 도구 정의만 불러옵니다. - MCP 도구, 터미널, 파일 조작, 워크스페이스 검색 등 도구가 많아질수록 이 방식의 효과가 커집니다. - 사용 가능한 도구의 범위는 넓게 유지하면서도, 현재 작업과 무관한 도구 정의가 매 턴마다 차지하는 토큰 비용을 줄일 수 있습니다. ## 작업별 모델 자동 선택 - Auto는 “현재 작업에 어떤 모델이 가장 적합한가?”를 자동으로 판단합니다. - 빠른 설명, 특정 파일의 간단한 수정, 여러 파일에 걸친 복잡한 변경은 요구되는 추론 수준이 서로 다르므로 동일한 모델을 사용할 필요가 없습니다. - 평가 결과 모든 작업에서 항상 최고 성능을 내는 단일 모델은 없었습니다. - 효율적인 모델이 더 적은 비용으로 같은 결과를 내는 경우가 많지만, 복잡한 추론이나 디버깅에서는 강력한 모델이 더 유리합니다. - Auto는 필요할 때만 더 강한 모델로 전환하고, 단순한 작업에는 효율적인 모델을 사용해 품질과 비용 사이의 균형을 맞춥니다. ## Auto의 라우팅 기준 Auto는 모델의 현재 상태와 작업의 특성이라는 두 가지 신호를 함께 사용합니다. - **실시간 모델 상태** - 모델의 가용성, 사용률, 응답 속도, 오류율, 비용을 동적으로 추적합니다. - 성능이 좋은 모델이라도 현재 과부하 상태이거나 응답 오류가 많다면 최적의 선택이 아닐 수 있습니다. - 따라서 작업을 처리할 능력뿐 아니라 현재 안정적으로 응답할 수 있는지도 고려합니다. - **HyDRA 기반 작업 인식 라우팅** - HyDRA는 추론 깊이, 코드 복잡도, 디버깅 난이도, 도구 오케스트레이션 필요성 등을 분석합니다. - 먼저 해당 작업의 품질 기준을 충족할 수 있는 모델들을 선별한 뒤, 그중 가장 적합한 모델을 선택합니다. - 게시글의 평가에서는 HyDRA가 품질과 비용 절감 수준을 조정할 수 있음을 보여줍니다. - 한 운영 지점에서는 Sonnet보다 높은 성능을 내면서 12.9% 비용을 절감했고, 다른 운영 지점에서는 품질을 균형 있게 유지하며 72.5%를 절감했습니다. - SWE-bench 평가에서 보수적 설정은 70.8% 해결률로 OpenRouter Auto와 동률을 기록하면서 3.3배 높은 절감 효과를 보였습니다. ## 캐시를 고려한 모델 전환 - 매 턴마다 모델을 바꾸면 유연성은 높아지지만, 기존 프롬프트 캐시가 깨져 오히려 비용이 증가할 수 있습니다. - 같은 모델을 계속 사용하면 대화의 프롬프트 접두부를 여러 턴에 걸쳐 재사용할 수 있습니다. - Auto는 다음과 같은 **자연스러운 캐시 경계**에서 주로 모델을 다시 선택합니다. - 첫 번째 요청: 아직 재사용할 캐시가 없는 시점 - 컨텍스트 압축(compaction) 이후: 이전 대화를 요약하면서 프롬프트 접두부가 초기화된 시점 - 그 사이에는 선택된 모델을 유지해 캐시가 축적되도록 합니다. - 즉, 모델 라우팅 자체의 이득뿐 아니라 모델 전환으로 발생하는 캐시 손실까지 함께 계산합니다. ## 여러 언어를 지원하는 라우팅 - Copilot은 영어뿐 아니라 다양한 언어로 사용되므로 라우팅 모델도 다국어 환경에서 작동해야 합니다. - 라우팅 모델은 CJK, 유럽 언어권 등을 포함한 16개 언어군의 대화 데이터로 학습되었습니다. - 19개 언어에서 추출한 VS Code Chat 텔레메트리 평가에서 언어군별 라우팅 정확도는 영어 기준선과 4포인트 이내의 차이를 보였습니다. - 언어군 사이에 통계적으로 유의미한 품질 격차도 나타나지 않았습니다. Copilot의 효율성을 높이려면 모든 정보를 매번 다시 보내거나 모든 작업에 가장 큰 모델을 사용하는 대신, 반복 컨텍스트는 캐시하고 도구는 필요할 때 불러오며 작업 난이도에 맞는 모델을 선택하는 것이 효과적입니다. 특히 긴 에이전트 세션에서는 모델 전환으로 캐시가 손실되지 않도록 하는 전략이 비용과 응답 속도 모두에 중요합니다.

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

AI 에이전트모델 컨텍스트 프로토콜github-copilotvisual-studio-code+3

aws·2026년 6월 17일·4분 읽기큐레이션 요약

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 에이전트를 단순한 대화형 기능이 아니라 지식 검색, 보안 대응, 코드 수정, 릴리스 검증, 업무 실행까지 담당하는 운영 시스템으로 확장하고 있음을 보여준다. 실제 도입 시에는 에이전트의 자율성보다 데이터 접근 권한, 비용 통제, 감사 로그, 사람의 승인 절차를 먼저 설계하는 것이 바람직하다.

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

AI 에이전트amazon-bedrockRAGamazon-s3+4

aws·2026년 6월 17일·4분 읽기큐레이션 요약

더 빠르고 정확한 엔터프라이즈 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를 활용해 초기 구축 시간을 줄이고 검색 품질을 안정적으로 확보할 수 있다.

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

AI 에이전트생성형 AIamazon-bedrockRAG+2

aws·2026년 6월 17일·3분 읽기큐레이션 요약

Amazon Bedrock AgentCore 웹 검색 출시 발표: AI 에이전트를 최신의 정확한 웹 지식으로 기반 강화하기 | Amazon Web Services

Amazon Bedrock AgentCore의 Web Search가 정식 출시되어, AI 에이전트가 최신 웹 정보를 검색하고 출처와 함께 응답하도록 지원한다. 검색은 AWS 환경 내부에서 처리되므로 고객의 프롬프트와 검색 질의를 외부 검색 API 사업자에게 전송하지 않으며, 모델 학습 데이터 이후의 최신 정보도 안전하게 활용할 수 있다. Amazon 웹 인덱스와 지식 그래프를 결합해 일반 웹 검색보다 정확하고 신뢰도 높은 근거 제공을 목표로 한다. ## 최신 웹 정보와 출처를 활용한 응답 - 에이전트가 자연어 검색 질의를 보내면 관련성이 높은 다음 정보를 반환한다. - 검색 결과 요약문(snippet) - 원문 URL - 문서 제목 - 발행일 - 에이전트는 반환된 검색 결과를 추론해 최신 사실에 근거한 답변이나 후속 작업을 수행할 수 있다. - 모델의 학습 시점 이후 발생한 사건과 정보를 반영할 수 있어, 시의성이 중요한 업무에 적합하다. ## Amazon 검색 인프라와 지식 그래프 결합 - Web Search는 Amazon의 검색 인프라를 기반으로 구축됐다. - Amazon 웹 인덱스뿐 아니라 구조화된 지식 그래프 데이터도 함께 사용하는 다중 소스 기반 검색 방식을 적용한다. - Amazon Knowledge Graph의 검증된 사실을 활용해 단순 키워드 검색보다 관련성과 정확도가 높은 결과를 제공한다. - Alexa+, Amazon Quick, Kiro 등에서 축적한 에이전트 검색 경험이 기반이 됐다. ## MCP 기반 Bedrock AgentCore Gateway 연동 - Web Search는 Bedrock AgentCore Gateway의 기본 제공 커넥터 타깃으로 제공된다. - Model Context Protocol(MCP)을 사용하므로 MCP를 지원하는 에이전트와 개발 도구에서 호출할 수 있다. - 사용자는 Gateway 생성 시 다음과 같이 Web Search를 추가할 수 있다. - 대상 프로토콜: MCP target - 대상 유형: Connectors - 사전 구성된 타깃: Web Search - 기존 Gateway의 상세 페이지에서도 Web Search 타깃을 추가할 수 있다. ## 설정 및 테스트 방법 - Bedrock AgentCore 콘솔에서 Web Search 도구 타깃이 포함된 Gateway를 생성한다. - Gateway URL이 생성되면 다음 방식으로 검색 도구를 호출할 수 있다. - API 요청 - AWS CLI - Python 코드 - MCP Python SDK - Strands MCP Client - MCP Inspector - MCP Inspector에서는 Gateway 리소스 URL에 연결한 뒤 Web Search 도구를 선택하고 검색어를 입력해 결과를 즉시 확인할 수 있다. - 콘솔의 **View invocation code** 영역에서 호출 예제 코드를 확인할 수 있다. ## 보안과 기업 거버넌스 - 검색 질의와 사용자 프롬프트를 AWS 외부의 검색 API 제공업체로 보내지 않고, 고객의 보안된 AWS 환경 내에서 처리할 수 있다. - 별도의 검색 인프라를 직접 구축하거나 외부 API 연동을 관리하지 않아도 된다. - 기업 정책에 맞춰 데이터 보호와 접근 통제를 유지하면서 외부 공개 정보와 내부 데이터를 함께 활용할 수 있다. - Benchling은 기관 내부 과학 데이터와 최신 학술 문헌을 결합해 연구 질문에 답하고 가설을 생성하는 데 활용하고 있다. - Gen Digital은 Norton Revamp에서 현재 온라인 동향을 반영한 콘텐츠 아이디어를 생성하는 데 사용하고 있다. ## 제공 지역과 비용 - 현재 미국 동부(버지니아 북부) 리전에서 정식 제공된다. - Web Search 자체는 추가 비용 없이 시작할 수 있다. - Gateway 사용에 따른 데이터 전송 요금은 별도로 부과된다. - 신규 AWS 고객은 최대 200달러의 프리 티어 크레딧을 받을 수 있다. 실제로 도입할 때는 먼저 MCP Inspector로 검색 결과의 품질과 출처 형식을 검증한 뒤, 에이전트 프롬프트에 “검색 결과의 출처와 발행일을 반드시 반영하라”는 규칙을 추가하는 것이 좋다. 이후 내부 데이터와 웹 검색 결과를 함께 사용하는 경우에는 권한 관리와 출처 추적 정책을 별도로 설계해야 한다.

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

AI 에이전트모델 컨텍스트 프로토콜amazon-bedrock-agentcoreknowledge-graph+2

line·2026년 6월 17일·4분 읽기큐레이션 요약

ID-JAG The Hard Way: 실패로 배우는 AI 에이전트 보안 핸즈온

AI 에이전트의 API 접근에는 단순한 사용자 인증을 넘어, 에이전트가 특정 사용자를 대신해 정해진 범위의 작업만 수행하도록 통제하는 위임 인가가 필요하다. 글은 OAuth 기반 프로필인 ID-JAG를 활용해 Keycloak, Athenz, MCP 서버, 리소스 서버가 연계되는 전체 흐름을 로컬 핸즈온으로 재현한다. 특히 인증 정보와 실제 접근 권한을 분리하고, 기업 정책에 따라 실패 지점을 명확히 차단하는 중앙 집중형 인가 구조를 강조한다. ## ID-JAG가 해결하려는 문제 - ID-JAG는 다음 OAuth 표준을 결합해 위임된 크로스 도메인 API 접근을 지원한다. - OAuth 2.0 Token Exchange(RFC 8693) - JWT Profile for OAuth 2.0 Authorization Grants(RFC 7523) - 기존의 “사용자가 누구인가?”라는 인증 중심 질문을 다음과 같이 확장한다. - AI 에이전트가 현재 사용자를 대신해 특정 리소스에 접근할 권한이 있는가? - 요청된 권한 범위와 기업 정책을 충족하는가? - AI 에이전트에 영구적이고 포괄적인 권한을 주면 오작동이나 공격 시 피해 범위가 커지고, 사용자의 의도와 에이전트의 자율 행동을 구분하기 어렵다. - 모든 API 호출마다 사용자의 동의를 요구하면 자동화와 사용자 경험이 훼손된다. - ID-JAG는 임시 토큰 연결 대신, 정책에 기반한 명시적 위임과 중앙 집중형 신뢰 관계를 제공한다. ## 데모 아키텍처와 역할 분리 핸즈온에서는 인증과 인가 정책을 의도적으로 분리한다. - **Keycloak** - 사용자를 인증하는 업스트림 IdP다. - 로그인 결과로 원본 ID 어서션을 발급한다. - **Athenz** - KeycloakTokenExchangePlugin을 통해 연동된 IdP 인가 서버로 동작한다. - Keycloak 토큰의 발급자, 서명, 대상, 주체, 클라이언트 바인딩을 검증한다. - 기업 정책을 평가하고 최종 ID-JAG 어서션을 발급한다. - 중앙 리소스 인가 서버이자 정책 결정 지점(PDP) 역할을 한다. - **AI 에이전트** - 사용자를 대신해 ID-JAG와 액세스 토큰을 요청한다. - 장기 마스터 키가 아니라 정책으로 제한된 임시 권한을 사용한다. - **MCP 서버** - 에이전트가 호출하는 보호된 중간 리소스 서버다. - 전달받은 토큰을 인가 서버와 교환한 뒤 최종 리소스 서버에 접근한다. - **리소스 서버** - Athenz가 발급한 신뢰 가능한 토큰만 수용한다. - 업스트림 IdP의 토큰을 무조건 인가 그랜트로 인정하지 않는다. ## ID-JAG 실행 흐름 실습 환경에서는 다음 순서로 위임 접근이 진행된다. - 사용자가 Keycloak을 통해 로그인한다. - 사용자가 AI 에이전트에 작업을 지시한다. - 에이전트가 Athenz에 ID-JAG 토큰을 요청한다. - Athenz가 사용자, 클라이언트, 대상 리소스, 권한 범위 및 기업 정책을 검증한다. - 허용된 경우 에이전트가 Athenz에 액세스 토큰을 요청한다. - 에이전트가 액세스 토큰을 포함해 MCP 서버를 호출한다. - MCP 서버가 토큰 교환을 수행한다. - 교환된 토큰으로 최종 리소스 서버에 요청한다. 이 구조에서는 인증된 사용자라는 사실만으로 모든 리소스 접근이 허용되지 않으며, 각 단계에서 위임 범위와 정책을 다시 확인한다. ## 인증 토큰과 인가 그랜트의 분리 Keycloak의 ID 토큰을 곧바로 액세스 토큰으로 교환하는 방식도 기술적으로는 가능하지만, 보안 모델상 한계가 있다. - **ID 토큰** - 사용자가 클라이언트에 성공적으로 인증됐음을 나타낸다. - 특정 리소스에 접근할 권리를 직접 의미하지 않는다. - **인가 그랜트** - 특정 리소스와 권한 범위에 대한 액세스 토큰 발급을 요청하기 위해 인가 서버에 제출된다. - ID-JAG를 별도의 인가 그랜트로 사용하면 다음 실패 유형을 구분할 수 있다. - 사용자 인증 실패 - 그랜트 검증 실패 - 에이전트 위임 거부 - 기업 정책 거부 - 리소스 서버의 토큰 거부 - 이 경계는 장애 분석과 감사 추적을 명확하게 만들고, 로그인 성공이 곧 크로스 도메인 API 접근 권한으로 오해되는 것을 방지한다. ## 실패 경로를 통한 보안 검증 핸즈온은 정상 동작뿐 아니라 의도적인 설정 오류를 통해 정책 경계를 확인하도록 구성된다. - 토큰 없이 보호된 API를 호출하면 `401 Unauthorized`가 발생한다. - 엔터프라이즈 역할만 설정하고 멤버십을 누락하면 토큰 교환이 실패한다. - 에이전트에 필요한 위임 권한을 부여하지 않으면 위임 호출이 차단된다. - 각 오류는 인증, 역할, 멤버십, 위임 정책, 토큰 교환 중 어느 단계가 필요한지 보여준다. - Athenz UI에서 에이전트의 위임 권한을 제거한 뒤 다시 실행하면 차단이 발생하는 지점을 직접 추적할 수 있다. ## 중앙 정책 관리의 장점 - 기업의 위임 정책을 Athenz 한 곳에서 관리할 수 있다. - 여러 IdP, SaaS, 리소스 애플리케이션에 정책을 중복 배포할 필요가 줄어든다. - 벤더별 인가 로직에 대한 종속을 완화할 수 있다. - 시스템 간 정책 불일치와 운영상의 보안 위험을 줄인다. - Athenz가 ID-JAG 발급자이자 PDP로 기능하면서, 위임 API 접근에 대한 단일 진실 공급원이 된다. ## 실습 방법과 권장 사항 - `athenz-community/id-jag-the-hard-way` 저장소에서 튜토리얼을 실행한다. - 정상 흐름뿐 아니라 의도적으로 역할, 멤버십, 위임 권한을 제거해 실패 지점을 확인하는 것이 중요하다. - 실제 기업 환경에서는 인증 성공 여부와 별도로 리소스·권한·에이전트·정책을 명시적으로 검증해야 한다. - AI 에이전트 도입 시 장기 자격 증명 대신 제한된 범위의 단기 토큰과 중앙 정책 평가를 사용하는 방식을 권장한다.

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

AI 에이전트모델 컨텍스트 프로토콜jwtauthorization+4

aws·2026년 6월 16일·4분 읽기큐레이션 요약

Amazon S3 어노테이션: 풍부하고 쿼리 가능한 컨텍스트를 객체에 직접 첨부하기 | Amazon Web Services

Amazon S3 annotations는 객체에 대규모·구조화된 비즈니스 맥락을 직접 연결하고, 객체를 다시 작성하지 않고도 수정·삭제할 수 있게 하는 새로운 메타데이터 기능이다. 객체당 최대 1,000개의 annotation을 저장할 수 있으며, 각 annotation은 최대 1MB, 전체 최대 1GB까지 지원한다. S3 Metadata를 활성화하면 annotation을 Athena 등으로 대규모 조회할 수 있어 AI 에이전트와 자동화된 데이터 워크플로에 적합하다. ## S3 annotations의 특징과 규모 - JSON, XML, YAML, 일반 텍스트 등 다양한 형식을 지원한다. - annotation마다 고유한 이름을 부여한다. - 객체당 최대: - 1,000개 annotation - annotation 하나당 1MB - 전체 1GB - 객체 데이터를 다시 업로드하지 않고 annotation만 독립적으로 수정하거나 삭제할 수 있다. - 객체를 복사하거나 복제하거나 리전 간 전송할 때 annotation도 함께 이동한다. - 객체를 삭제하면 연결된 annotation도 자동으로 삭제된다. ## 기존 S3 메타데이터의 한계 - 시스템 정의 메타데이터는 객체 크기, 스토리지 클래스 등 S3가 관리하는 기본 속성에 초점을 둔다. - 객체 태그는 접근 제어와 수명 주기 관리 같은 운영 작업에 적합하지만 객체당 10개로 제한된다. - 사용자 정의 메타데이터는 업로드 시 지정하는 소량의 헤더 기반 정보이며, 약 2KB 수준이고 변경이 제한적이다. - 풍부한 설명이나 AI 분석 결과를 저장하려면 별도 데이터베이스나 사이드카 파일을 운영해야 했다. - 별도 메타데이터 시스템을 사용하면 원본 객체와 메타데이터 간 동기화 로직이 복잡해지고, 메타데이터 저장 비용이 객체 자체의 저장 비용보다 커질 수도 있다. ## AI 에이전트와 데이터 검색 - AI가 생성한 음성·영상 트랜스크립트, 요약, 감정 분석, 콘텐츠 등급 등을 객체에 직접 저장할 수 있다. - 메타데이터가 객체와 함께 이동하므로 데이터 복사·복제 과정에서 별도 동기화가 필요하지 않다. - S3 Metadata annotation 테이블을 사용하면 Athena와 다른 분석 엔진으로 annotation을 대규모 조회할 수 있다. - S3 Tables MCP 서버를 활용하면 AI 모델이 자연어 질의로 관련 데이터를 탐색할 수 있다. - 객체를 직접 복원하지 않고도 모든 스토리지 클래스의 annotation을 조회할 수 있으며, Glacier 계열에서도 객체 검색·복원 비용 없이 컨텍스트를 확인할 수 있다. ## 산업별 활용 사례 - **미디어·엔터테인먼트** - 영상별 트랜스크립트, 자막, 콘텐츠 검수 결과, 라이선스 정보를 별도 annotation으로 저장한다. - 여러 미디어 자산 관리 시스템 간 메타데이터 동기화를 줄일 수 있다. - **금융 서비스** - 연구 문서에 AI 기반 투자 요약과 감정 분석 결과를 연결한다. - 자연어 기반 에이전트가 별도 메타데이터 데이터베이스 없이 관련 문서를 탐색할 수 있다. - **생명과학** - 임상시험 데이터에 규제 상태, 환자군 정보, 승인 절차를 추가한다. - 보관된 데이터의 전체 맥락을 유지하면서 규제 감사와 컴플라이언스 검토를 간소화한다. ## annotation 생성·조회·수정·삭제 - IAM 정책 또는 버킷 정책에 다음 권한이 필요하다. - `s3:PutObjectAnnotation` - `s3:GetObjectAnnotation` - `PutObjectAnnotation` API로 기존 객체와 새 객체 모두에 annotation을 추가할 수 있다. - 예시처럼 하나의 영상 객체에 다음과 같이 서로 다른 정보를 저장할 수 있다. - `mediainfo`: 코덱, 해상도, 오디오 트랙 수 등을 JSON으로 저장 - `ai_summary`: AI가 생성한 영상 설명을 일반 텍스트로 저장 - 주요 API: - `GetObjectAnnotation`: 특정 annotation 조회 - `ListObjectAnnotations`: 객체에 연결된 전체 annotation 목록 확인 - `DeleteObjectAnnotation`: 특정 annotation 삭제 - `PutObjectAnnotation`: 같은 이름으로 호출해 기존 annotation 갱신 - 여러 팀이나 워크플로가 서로 다른 이름의 annotation을 사용하면 기술 정보, 콘텐츠 분류, 규제 정보 등을 서로 간섭 없이 동시에 관리할 수 있다. - 멀티파트 업로드 객체는 업로드를 완료한 뒤 `PutObjectAnnotation`으로 annotation을 추가해야 한다. ## 대규모 조회와 관리 - 개별 객체에 annotation을 붙이는 것만으로도 풍부한 컨텍스트를 보존할 수 있다. - S3 Metadata를 활성화하면 annotation이 관리형 annotation 테이블로 자동 전달된다. - 테이블 기반 조회를 통해 수많은 객체의 분류, 요약, 규제 상태, 기술 사양 등을 한 번에 검색할 수 있다. - 객체 본문을 모두 읽지 않고 메타데이터만 조회할 수 있어 대규모 데이터셋과 장기 보관 데이터에 특히 유리하다. S3 annotations는 단순한 태그나 업로드 시점의 헤더 메타데이터를 넘어, 변경 가능하고 대용량이며 조회 가능한 객체 컨텍스트를 제공한다. AI 에이전트, 콘텐츠 enrichment 파이프라인, 규제·감사 시스템처럼 객체의 의미와 상태가 계속 확장되는 환경에서는 별도 메타데이터 저장소를 구축하기 전에 annotations와 S3 Metadata 테이블 조합을 우선 검토할 만하다.

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

AI 에이전트amazon-s3jsonaws-cli+3

figma·2026년 6월 16일·3분 읽기큐레이션 요약

Figma에서 MCP 서버를 활용하는 4가지 방법 | Figma 블로그

Figma의 MCP 서버는 디자인 파일을 읽는 수준을 넘어 Slides·FigJam·Make·Figma 에이전트 전반에서 콘텐츠를 생성하고 수정하는 도구로 확장됐다. 에이전트는 사내 문서와 최신 제품 정보를 바탕으로 발표 자료나 협업 보드를 만들고, Figma 템플릿·디자인 시스템·사용자 정의 폰트까지 반영할 수 있다. 그 결과 반복적인 콘텐츠 제작의 상당 부분을 자동화하면서도 최종 검토와 창의적 판단은 사람이 담당하는 워크플로가 가능해졌다. ## Figma MCP 서버의 확장된 역할 - Figma Slides, FigJam, Figma Make, 새로운 Figma 디자인 에이전트에서 프롬프트 기반 생성·수정을 지원한다. - 디자인 파일의 이미지와 아이콘을 SVG, PDF, JPG, PNG로 내려받을 수 있는 `download_assets` 도구가 추가됐다. - 업로드한 사용자 정의 폰트를 지원해 웹 안전 폰트로 대체하지 않고 브랜드 서체를 그대로 렌더링한다. - `use_figma` 도구와 `/figma-use-slides` 같은 MCP 스킬을 조합해 팀의 템플릿과 디자인 의도를 결과물에 반영한다. - 스킬은 에이전트의 출력 품질과 일관성을 높이며, Figma 커뮤니티에서 공유하거나 직접 제작할 수 있다. ## 지속적으로 갱신되는 발표 자료 만들기 - Figma의 디자이너 옹호 담당자는 AI 제품 출시 내용을 정리한 상시 업데이트형 발표 자료를 운영한다. - 다음과 같은 프롬프트를 코드 에디터에서 실행해 자료를 갱신한다. - Slack, Google Drive, Shortcut 블로그, 릴리스 노트에서 최신 정보를 수집 - 기존 덱에서 갱신이 필요한 부분을 제안 - 새로 추가할 슬라이드 아이디어를 생성 - Figma Slides의 기존 템플릿에 내용을 반영 - 에이전트가 관련 대화, 브리프, 출시 메시지를 모아 초안의 약 80%를 완성한다. - 이후 사람은 이미지 교체, 문구 수정, 내용 검토 등 품질 관리에 집중한다. - 사용자 정의 폰트를 활용하기 때문에 발표 자료의 브랜드 정체성과 시각적 일관성을 유지할 수 있다. - 같은 방식은 다음과 같은 업무에도 적용된다. - PM의 제품 킥오프 자료 작성 - 디자이너의 디자인 탐색 발표 - 마케팅 팀의 GTM 계획 수립 - 영업 팀의 고객용 자료 최신화 - 핵심 이점은 단순히 제작 속도를 높이는 데 그치지 않고, 팀의 디자인 시스템과 브랜드 기준을 반영한 결과물을 만드는 것이다. ## 실시간 데이터를 반영한 FigJam 보드 생성 - 제품 관리자는 기능 킥오프 워크숍을 준비할 때 회사 곳곳의 정보를 수집하고, 세션에 맞게 FigJam 섹션을 구성해야 한다. - 이 과정은 관련 맥락을 모으고 보드 형식을 맞추는 데 많은 시간이 걸린다. - 이를 자동화하기 위해 `/figjam-builder`라는 커스텀 스킬을 구축했다. - 스킬과 MCP 서버를 이용하면 실시간 데이터와 조직 내 정보를 바탕으로 워크숍용 FigJam 보드를 생성할 수 있다. - 제공된 본문은 이 사례의 구체적인 구현 방식과 나머지 두 가지 활용 사례 설명으로 이어지기 전에 중단되어 있다. MCP를 도입할 때는 모든 결과를 자동 게시하기보다, 에이전트가 자료 조사와 초안 작성을 맡고 사람이 사실관계·문구·시각 요소를 검토하는 방식이 현실적이다. 특히 팀 템플릿, 디자인 시스템, 사용자 정의 폰트, 업무별 스킬을 함께 제공할수록 자동화 결과의 품질과 브랜드 일관성이 높아진다.

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

AI 에이전트디자인 시스템figjamfigma-make+2

kakao·2026년 6월 15일·4분 읽기큐레이션 요약

AI 에이전트로 카카오톡 추천 지표 분석 자동화하기

카카오는 기존 Hadoop 환경에 AI 에이전트를 연결해 추천 지표 분석 절차를 자동화했다. 핵심은 새로운 플랫폼이나 권한을 추가하는 것이 아니라, 사람이 알고 있던 데이터 접근 절차·지표 정의·판단 기준을 Markdown 기반 스킬과 컨텍스트 문서로 정리하는 데 있었다. AI는 분석 초안을 빠르게 만들고 다음 질문을 제안하지만, 결과의 정확성과 최종 판단은 사람이 검증해야 한다. ## 반복적인 추천 지표 분석의 비효율 - CTR 하락, 실험군 반응, 배포 후 사용자군 변화 등을 확인하려면 다음 과정을 반복해야 한다. - 분석 환경 접속 - 적절한 테이블 탐색 - SQL 작성 및 실행 - 결과 해석 - 연령대·카테고리·시간대 등 관점별 추가 분석 - 질문은 간단해도 데이터 준비와 추출에 많은 시간이 걸린다. - 반복적이고 절차가 정형화된 업무이므로 AI 자동화에 적합하다. ## Hadoop 접속 절차를 Agent Skill로 정리 - 기존 Hadoop 접속 스크립트와 실행 환경은 그대로 활용했다. - AI가 Hadoop을 사용할 수 있도록 접속·쿼리 실행 방법을 `SKILL.md` Markdown 문서로 작성했다. - 여러 스킬을 묶은 사내 플러그인 `hadoop-butler`를 통해 AI가 다음 작업을 수행하도록 했다. - Hadoop 클러스터 접속 - 분석 목적에 맞는 SQL 작성 - 쿼리 제출 및 결과 수집 - 결과 정리와 인사이트 도출 - 새로운 분석 플랫폼이나 MCP 서버를 구축하기보다, 기존 인프라에 업무 지식을 “접착제”처럼 추가한 접근이다. ## 컨텍스트 문서로 분석 기준 명시 - 분석 디렉터리에 `CLAUDE.md`, `AGENTS.md`와 같은 컨텍스트 문서를 배치했다. - 문서에는 다음 정보를 담았다. - 분석 대상 테이블과 Hadoop 클러스터 - `watch_length`, `valid_view` 등 주요 컬럼의 의미 - 사용자·세션 집계 기준 - CTR 등 주요 지표의 정의 - 명확한 기준을 문서화하면 AI가 매번 테이블과 컬럼의 의미를 추측하지 않아도 된다. - 이는 AI의 분석 품질을 높이는 동시에 팀의 데이터 지식을 문서화하고 신규 구성원의 온보딩에도 도움을 준다. ## AI는 분석 초안을 만들고 사람은 질문을 확장 - 자연어로 분석 목적을 설명하면 AI가 첫 번째 리포트와 추가 분석 후보를 제시한다. - 이상치 확인, 실험 결과 비교, 주간 현황 점검처럼 반복 업무에 특히 효과적이다. - 대시보드가 수치를 빠르게 보여준다면, 자연어 분석은 “어디를 더 살펴볼지”를 제안한다. - 사용자는 초안 결과를 확인한 뒤 세부 사용자군이나 특정 기간 등으로 질문을 이어가며 분석을 구체화할 수 있다. - AI 결과는 최종 결론이 아니라 검토 대상이며, 쿼리 기준과 지표 정의를 사람이 확인해야 한다. ## AI가 그럴듯하게 만드는 의미·성능 오류 - **의미 오류** - 사용자 수 집계에 계정 단위 식별자인 `user_id` 대신 세션 성격의 `session_user_id`를 사용할 수 있다. - 쿼리는 정상 실행되지만 실제 사용자 수 의미와 다른 결과를 낼 수 있다. - **성능 오류** - 여러 컬럼에 대해 `COUNT(DISTINCT ...)`를 한 번에 실행하는 SQL을 생성할 수 있다. - Hive에서는 이 방식이 단일 리듀서로 처리되어 매우 느려질 수 있다. - 컬럼별 쿼리를 분리해 병렬 실행하는 방식이 더 적절하다. - 문법적으로 올바른 SQL과 업무적으로 올바른 분석은 다르므로, 도메인 지식과 실행 엔진 특성에 대한 검증이 필요하다. ## 문서화와 회귀 테스트로 품질 관리 - 자주 발생하는 오류를 지침에 명시적으로 추가했다. - 사용자 수 집계에는 반드시 `user_id` 사용 - 모든 컬럼명은 백틱으로 감싸 예약어 충돌 방지 - 다중 `COUNT(DISTINCT)`는 컬럼별로 분리해 병렬 실행 - 스킬과 프롬프트가 늘면서 한 지침 수정이 다른 기능을 깨뜨리는 회귀 문제가 발생했다. - 이를 해결하기 위해 MLflow 기반 E2E 평가 파이프라인을 구축했다. - 스킬별 기대 동작을 테스트 시나리오로 정의 - 에이전트를 헤드리스 모드로 실행 - LLM Judge가 결과를 평가 - 도구 호출 순서, 실행 트레이스, 최종 출력까지 다층 검증 - 배포 전 전체 시나리오를 자동 회귀 테스트 - 자연어 지침도 소프트웨어처럼 테스트와 배포 관리가 필요하다는 점을 강조한다. ## 실용적인 도입을 위한 네 가지 요소 - **모델**: 자연어 요청을 이해하고 분석 절차를 수행하는 에이전트 - **컨텍스트**: 테이블, 피처, 지표 정의와 업무 규칙 - **실행 환경**: 실제 데이터에 접근할 수 있는 기존 Hadoop 인프라 - **검증 루프**: 결과와 도구 실행 절차를 확인하는 자동 테스트 체계 반복 업무에 AI를 도입할 때는 새로운 시스템부터 만들기보다, 기존 절차와 도메인 지식을 문서화하고 실행 환경에 연결하는 것이 효과적이다. 다만 AI의 결과를 그대로 신뢰하지 말고, 명확한 분석 기준과 회귀 테스트를 함께 마련해야 실무에서 안전하게 활용할 수 있다.

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

AI 에이전트sqlcontext-engineeringhadoop+4