multi-agent-systems

16 개의 포스트

toss5분 읽기큐레이션 요약

AI에게 투자정보를 말하게 하기까지

LLM을 활용한 금융 투자 정보 서비스의 핵심은 문장을 잘 생성하는 데 있지 않고, 생성 전후의 근거 선별·검증·관찰 체계를 설계하는 데 있습니다. 토스증권은 이를 위해 세 가지 관문을 제시합니다. 즉, 말할 정보를 고르고, 생성 과정을 통제하며, 결과를 평가 가능한 구조로 만드는 것입니다. ## 금융 투자 정보가 일반 요약보다 어려운 이유 - **적시성**: 시장 상황은 빠르게 변하므로 늦은 설명은 부정확한 정보가 될 수 있습니다. - **정확성**: 기사에 기업명이 등장했다는 사실만으로 해당 기업의 주가 변동을 설명할 수 없습니다. - 자회사 관련 내용인지 - 유사한 이름의 다른 기업인지 - 단순 홍보성 기사인지 구분해야 합니다. - **검증 가능성**: 모든 설명에 근거를 남기고, 결과를 평가하며, 오류 발생 시 재현할 수 있어야 합니다. - **비정상성**: 실적 시즌, 금리 이벤트, 선거, 지정학적 이슈 등에 따라 데이터 분포와 시장 반응이 달라집니다. ## LLM과 에이전트의 불확실성 - LLM은 비정형 텍스트를 자연어로 재구성하는 데 강하지만, 근거가 부족하면 유창한 오답을 생성할 수 있습니다. - 에이전트 구조에서는 다음과 같은 오류가 여러 단계로 전파될 수 있습니다. - 검색 단계에서 잘못된 근거 선택 - 툴 호출 결과의 오해 - 이전 단계의 잘못된 상태를 다음 판단에 사용 - 따라서 투자 정보 서비스에서는 에이전트의 자율성을 무조건 확대하기보다, 필요한 부분은 제한하고 생성 전후의 통제를 강화해야 합니다. ## 첫 번째 관문: 말할 정보 고르기 ### 입수 단계에서 메타데이터 구축 - 뉴스·공시·재무 데이터를 수집할 때 BERT 기반 분류 모델로 미리 분류합니다. - 데이터에는 다음과 같은 정보를 함께 저장합니다. - 산업·시장·콘텐츠 유형 등의 `taxonomy_tags` - 관련 기업인 `related_entities` - 벡터 검색을 위한 `embedding` - 검색 시점에 매번 분류하는 대신, 데이터가 들어올 때부터 검색과 검증에 필요한 구조를 갖춥니다. ### 후보를 넓게 검색한 뒤 단계적으로 축소 - 하이브리드 리트리버로 후보를 넓게 확보해 재현율을 우선합니다. - 이후 다음 절차로 부적절한 정보를 제거합니다. - **중복 제거**: 의미 유사도 기반으로 같은 이벤트를 클러스터링하고 대표 출처만 남깁니다. - **리랭킹·필터링**: 기업 주가 움직임과의 직접적 관련성을 기준으로 순위를 조정합니다. - **설명 유형 분류**: 실적, 가이던스, 기업 행동 등 주요 설명 패턴을 분류합니다. - **실패 사유 분류**: 광고성, 홍보성, 근거 부족 등의 라벨을 붙여 필터링합니다. - 최종 근거는 다음 순서로 배치합니다. - 무슨 일이 있었는가 - 대상 기업과 어떻게 연결되는가 - 주가 방향과 근거의 방향성이 일치하는가 - 근거가 충분하고 최신인가 이 과정은 LLM에 전달할 정보를 압축하고, 비즈니스 요구에 맞게 배치하는 **컨텍스트 엔지니어링**입니다. ## 두 번째 관문: 생성 과정 통제하기 ### 절차형 태스크 그래프 - 검색, 관련성 판단, 중복 제거, 근거 구성, 응답 생성 등을 독립된 단계로 나눕니다. - 각 단계의 입력·출력 스키마를 명확히 정의하면 다음 효과가 있습니다. - 단계별 디버깅과 평가 가능 - 비용과 레이턴시 예측 - 실패 지점 추적 - 단계별 폴백 설계 ### 자율형 에이전트와 절차형 오케스트레이션의 구분 - 탐색 과정 자체가 중요한 업무에는 자율형 에이전트가 적합합니다. - 투자 아이디어 발굴 - 시장 이벤트의 잠재 시나리오 탐색 - 응답 형식과 판단 절차가 명확한 업무에는 절차형 그래프가 유리합니다. - 특정 기업의 주가 등락 원인 설명 - 정해진 근거 검증과 방향성 판단 - 긴 ReAct 루프는 툴 호출, 토큰, 레이턴시와 실행 경로를 늘리므로 제품 요건이 명확할 때는 과도할 수 있습니다. - 이 경우 LLM은 검색과 판단을 모두 자율적으로 수행하기보다, 요약·재작성·근거 기반 설명에 집중시키는 편이 안정적입니다. ### 절차형 그래프의 재사용성 - 절차형 그래프는 단순한 운영 안정화 수단을 넘어 다른 에이전트가 호출할 수 있는 기능 인터페이스가 됩니다. - 예를 들어 다음과 같은 입력과 출력의 도구로 제공할 수 있습니다. - 입력: 종목, 주가 방향, 시간 범위 - 처리: 검색 → 관련성·방향성 판단 → 중복 제거 → 근거 정렬 → 설명 생성 - 출력: 설명, 근거 목록, 추론 유형 등 - 이렇게 구성하면 상위 에이전트가 복잡한 절차를 직접 계획하지 않고 검증된 기능을 재사용할 수 있습니다. ## 세 번째 관문: 평가 가능한 결과 만들기 ### 범주형 루브릭과 구조화된 출력 - 자연어 답변만 생성하지 않고, 답변과 함께 이벤트 유형·실패 사유 등의 분류값도 생성합니다. - 이를 통해 다음 지표를 측정할 수 있습니다. - 관련성 오탐 감소 여부 - 주가 방향성과 근거 방향성의 불일치 비율 - 부적절한 이슈의 통과율 - 정밀도, 재현율, F1-score - 시장 국면이 바뀌면 새로운 실패 유형과 이벤트 유형을 추가할 수 있도록 분류 체계를 유연하게 운영해야 합니다. - 운영 중 발견된 문제, 평가 데이터셋, 프롬프트 버전, 모델 버전을 연결해야 개선 효과를 재현하고 수치로 확인할 수 있습니다. ### 맥락 기반 Few-shot Retrieval - 고정된 Few-shot 예시는 다양한 금융 이벤트와 시장 국면을 충분히 대표하지 못합니다. - 대신 운영 샘플에 다음 정보를 저장합니다. - 원문 - 판단 결과 - 실패 유형 - 유사도 검색용 임베딩 - 새로운 판단 요청이 들어오면 유사한 과거 사례를 검색해 포지티브·네거티브 예시를 함께 프롬프트에 넣습니다. - 성공 사례와 실패 사례를 동시에 제공하면 모델이 판단의 경계와 오류 패턴을 더 잘 파악할 수 있습니다. - 실제 관련성 검증 태스크에서 재현율을 유지하면서 정확도와 정밀도가 개선되었으며, 특히 False Positive 감소에 효과적이었습니다. ## 프롬프트와 모델 학습을 넘어 필요한 것 - 금융 AI 서비스 품질은 프롬프트와 모델만으로 결정되지 않습니다. - 운영을 위해 다음 요소가 함께 필요합니다. - 적절한 임베딩 모델과 리트리빙 전략 - 별도 분류 모델을 활용한 데이터 구조화 - 근거 검증과 실패 유형 관리 - 단계별 추적 및 평가 - 시장 국면 변화에 따른 평가셋·프롬프트 업데이트 투자 정보 서비스에서는 LLM의 자율성을 최대화하기보다, 근거를 선별하고 검증하는 절차를 명확히 설계하는 것이 중요합니다. 검색·분류·검증은 통제 가능한 그래프로 구성하고, LLM은 구조화된 근거를 바탕으로 설명을 생성하도록 제한하는 방식이 안정성과 확장성을 함께 확보하는 현실적인 접근입니다.

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

런타임 인스턴스: Amazon Bedrock AgentCore에서 프로덕션 AI 에이전트를 위한 지속적 컴퓨팅 | Amazon Web Services

Amazon Bedrock AgentCore의 **runtime instances**는 장시간 실행, GPU 사용, 다중 에이전트 협업이 필요한 프로덕션 AI 에이전트를 위한 AWS 관리형 EC2 기반 실행 환경이다. 최대 14일 동안 세션 상태를 유지하고, 여러 에이전트가 같은 호스트와 파일 시스템을 공유할 수 있다. 기존에 직접 구성해야 했던 EC2, 네트워크, 세션 관리, 확장, 모니터링을 AgentCore API·IAM·관측성 체계와 함께 관리해 복잡한 에이전트 워크로드를 단순화한다. ## runtime instances가 해결하는 문제 - 프로토타입 에이전트를 프로덕션으로 전환하면 다음 요구사항이 발생한다. - 수 시간에서 수일 동안 지속되는 워크플로 - 여러 단계에 걸친 상태 유지 - 에이전트 간 협업과 컨텍스트 공유 - GPU 또는 운영체제 수준 접근 - 대용량·지속형 컴퓨팅 환경 - 기존에는 EC2 인스턴스, 네트워크, 세션 관리, 확장, 모니터링을 직접 구축해야 했다. - runtime instances는 이러한 인프라를 AWS가 관리하면서 기존 AgentCore API, 인증 제어, 관측성 기능과 통합한다. ## runtime microVM과 runtime instances의 차이 - **runtime microVM** - 빠른 확장에 적합한 경량 실행 환경 - 개별 호출을 최대 8시간까지 실행 - 관리형 세션 저장소를 통해 상태 기반 워크플로 지원 - **runtime instances** - AWS 관리형 EC2 기반의 지속형 실행 환경 - 공유 세션을 최대 14일까지 유지 - GPU, 직접적인 OS 접근, 장시간 실행 지원 - 여러 에이전트를 하나의 런타임에서 실행 가능 - 유휴 기간에는 세션을 중지하고 나중에 재개해 비용 절감 - 두 환경은 독립적으로 사용하거나 함께 구성할 수 있다. - 예를 들어 microVM의 오케스트레이터가 작업을 분배하고, instances의 워커 에이전트가 코드 컴파일·보안 검사·GUI 자동화 같은 무거운 작업을 수행한다. ## 에이전트 배포와 협업 방식 - CrewAI, LangGraph, LlamaIndex, Strands 등 원하는 프레임워크와 모델을 사용할 수 있다. - 애플리케이션은 `@app.entrypoint` 데코레이터를 사용하며, ZIP 파일 또는 컨테이너 이미지로 패키징한다. - 같은 세션에 속한 에이전트들은 서로를 도구처럼 호출하며 자율적으로 작업을 반복할 수 있다. - 세션이 며칠간 중단되어도 상태를 유지한 채 재개할 수 있다. - 세션을 초월해 보존해야 하는 지식은 다음 서비스와 결합할 수 있다. - Amazon EBS: 지속적인 파일 시스템과 작업 데이터 저장 - AgentCore Memory: 세션·환경을 넘어 유지되는 장기 기억 ## 코드 작성 에이전트와 리뷰 에이전트 예시 - 예제에서는 두 개의 Python 에이전트를 만든다. - **Writer**: 자연어 요구사항을 Python 코드로 변환 - **Reviewer**: 생성된 코드의 버그, 보안 문제, 스타일을 검토 - Writer는 세션 ID를 기반으로 공유 디렉터리를 만든 뒤 `code.py`를 저장한다. - Reviewer는 같은 세션 ID로 해당 파일을 읽어 코드 리뷰를 수행한다. - 두 에이전트가 같은 파일 시스템을 공유하므로 다음이 필요 없다. - 코드 파일을 별도로 업로드하거나 다운로드하는 과정 - 에이전트 간 API를 통한 데이터 전송 - 실제 운영 환경에서는 예외 처리, 파일 접근 권한, 동시성 제어, 세션 ID 검증 등을 추가해야 한다. ## 용량 공급자 설정 - 먼저 에이전트가 실행될 EC2 인프라를 정의하는 **capacity provider**를 생성한다. - 주요 설정 항목은 다음과 같다. - 운영체제: Linux 64-bit ARM - 인스턴스 유형: 예시에서는 `c7g.2xlarge` - 컴퓨팅 자원: 8 vCPU, 16 GiB 메모리 - VPC, 서브넷, 보안 그룹 - gp3 EBS 볼륨 - EC2 관리를 위한 서비스 역할과 인프라 역할 - 생성 후 상태가 `Active`가 되면 런타임에서 사용할 수 있다. - 생성 이후에는 설명 외 설정 변경이 제한되므로 인스턴스 유형, 네트워크, 보안 설정을 처음부터 검토해야 한다. ## 런타임 생성과 에이전트 배포 - Runtime에서 Compute type으로 **Instances**를 선택한다. - 앞서 만든 capacity provider를 연결한다. - 에이전트 소스는 S3에서 가져오며, ZIP 파일을 업로드할 수 있다. - 배포 시 다음 정보를 지정한다. - Python 3.13 등 언어 런타임 - `agent.py`와 같은 엔트리포인트 파일 - 에이전트의 `@app.entrypoint` 함수 - AWS Management Console뿐 아니라 AgentCore CLI, AWS CLI, IaC 도구로도 배포할 수 있다. ## 실용적인 선택 기준 - 빠른 확장과 짧은 호출 중심의 오케스트레이션에는 runtime microVM이 적합하다. - 장시간 실행, GPU, 공유 파일 시스템, 다중 에이전트 협업, OS 접근이 필요하면 runtime instances를 고려하는 것이 좋다. - 일반적으로는 microVM을 오케스트레이터로, runtime instances를 전문 워커 실행 환경으로 조합하는 구조가 효과적이다. - 비용을 줄이려면 작업이 없는 시간에 세션을 중지하고, EBS와 AgentCore Memory를 목적에 맞게 분리해 사용하는 것이 권장된다.

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

분석 에이전트의 힘으로 분석을 하나로 연결하다! 전문 조직에서 도전하는 생성 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 생성 자동화에만 집중하기보다, 도메인 지식 관리·데이터 접근 통제·분석 맥락 유지·로그 기반 개선까지 함께 설계하는 것이 중요합니다. 특히 반복 분석을 스킬과 조직 자산으로 축적해야 단기적인 생산성 향상을 넘어 지속적으로 성장하는 분석 플랫폼을 만들 수 있습니다.

원문 읽기(새 탭에서 열림)
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는 데이터가 여러 시스템에 분산되어 있고 한 번의 검색으로 답을 완성하기 어려운 기업 환경에 적합하다. 다만 반복 검색과 다수 에이전트 운영으로 비용과 지연 시간이 증가할 수 있으므로, 충분한 컨텍스트 검증을 적용할 질의 유형을 선별하고 검색 횟수·중단 조건을 함께 설계하는 것이 중요하다.

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

혁신의 새로운 시대: I/O 2026에서의 Google Research

Google I/O 2026에서 Google Research는 AI를 과학적 발견과 헬스케어 혁신을 가속하는 ‘에이전트 시대’의 핵심 기술로 제시했다. 연구용 AI 에이전트가 가설 생성부터 코드 작성·실험·검증까지 수행하고, 건강 분야에서는 개인화된 코칭과 진료 준비를 지원한다. Google은 이러한 기술이 인간의 연구 역량을 증폭할 수 있다고 강조하면서도, 실제 연구자·의료진과의 협업 및 책임 있는 공개를 병행하고 있다. ## 과학적 발견을 가속하는 AI - **Gemini for Science** - 과학 연구 전 과정을 지원하는 실험적 도구 모음이다. - 가설 생성, 계산 실험, 문헌 분석, 연구용 에이전트 활용 등을 하나의 생태계로 묶는다. - Google Cloud, Google DeepMind, Google Labs와 협력해 개발됐다. - **Empirical Research Assistance(ERA)** - 과학자가 전문가 수준의 경험적 연구 소프트웨어를 작성하도록 돕는 연구 코딩 시스템이다. - 문제와 평가 기준을 입력하면 새로운 개념을 제안하고, 코드를 작성한 뒤 결과를 평가한다. - 트리 탐색을 사용해 수천 개의 코드 변형을 반복적으로 생성·검증하며 성능을 최적화한다. - 신경과학과 우주론 연구에 활용됐으며, 호흡기 질환 입원 예측과 캘리포니아 강 유역의 계절별 유출량 예측에도 적용됐다. - **Co-Scientist** - Gemini를 기반으로 한 다중 에이전트 협업 시스템이다. - 전문화된 여러 에이전트가 가설을 생성하고, 서로 평가·토론·수정한다. - 항균제 내성, 식물 면역, 간 섬유화 등 연구 난제를 다루는 데 활용되고 있다. - **Computational Discovery** - ERA와 AlphaEvolve를 결합한 에이전트형 연구 엔진이다. - 수천 개의 코드 변형을 병렬로 생성하고 점수화해, 사람이 수개월 걸려 시험할 모델과 가설을 빠르게 비교한다. - **Hypothesis Generation과 Literature Insights** - Hypothesis Generation은 연구자와 함께 문제를 정의한 뒤, 다중 에이전트 ‘아이디어 토너먼트’를 통해 가설을 생성·논쟁·평가한다. - 생성된 주장은 클릭 가능한 인용을 제공해 과학적 검증 가능성을 높인다. - Literature Insights는 NotebookLM을 활용해 방대한 과학 문헌의 결과를 요약하고 구조화한다. - 매년 수백만 편의 논문이 발표되는 상황에서 문헌 종합을 자동화하는 것을 목표로 한다. ## 연구 자동화와 과학 검증 - Google Antigravity 같은 에이전트형 코딩 플랫폼에서 사용할 수 있는 **Science Skills**를 제공한다. - 구조 생물정보학과 유전체 분석처럼 복잡한 연구 작업을 수시간이 아닌 수분 단위로 수행할 수 있도록 지원한다. - 학술대회의 논문 심사와 검증에도 AI를 실험적으로 적용하고 있다. - **Paper Assistant Tool(PAT)**은 ICML, STOC, NeurIPS 등에서 1만 편 이상의 논문을 검토했다. - PAT의 피드백을 통해 저자가 이론적 허점을 발견하거나 새로운 실험을 수행할 수 있었다. - **Gemini Deep Think**는 수학·물리학·컴퓨터과학 연구자들과 협력해 네트워크 퍼즐의 미해결 문제, 최적화 추측, 머신러닝 최적화 현상, 경매 경제학, 우주끈의 물리적 특이점 등 전문가 수준의 난제를 다뤘다. ## AI를 활용한 헬스케어 발전 - Google은 증상 이해부터 진료 준비, 의료 기록 해석, 진료 이후 관리까지 이어지는 건강 관리 여정 전반을 AI로 지원하려 한다. - 이러한 연구를 바탕으로 **Google Health 앱**과 **Google Health Coach**를 개발했다. - Google Health 앱은 기존 Fitbit 사용자에게 순차적으로 제공되며, 개인별 상황에 맞춘 종합적이고 적응형인 건강 코칭을 제공한다. ## 증상 분석과 진료 준비 지원 - **Symptom AI** - 대화형 건강 데이터를 분석해 사용자의 증상과 관련된 감별 진단을 추론하는 연구용 도구다. - Fitbit 앱을 통한 무작위 연구에 13,917명이 참여했다. - 독립 임상의의 맹검 비교에서 Symptom AI의 감별 진단이 다른 임상의의 결과보다 약 두 배 자주 선호됐다. - 이는 AI가 다양한 표현 방식과 실제 질병 분포를 반영한 대화 데이터를 활용할 가능성을 보여준다. - **Plan for Care** - 사용자가 의사와의 진료를 준비하도록 돕는 파일럿 연구다. - 1,779명이 참여했으며, 기준 모델과 비교해 진료 준비가 더 잘 됐다고 느낀 사용자가 15% 증가했다. - 진료를 최대한 활용할 자신감이 있다고 답한 사용자도 13% 늘었다. - **개인 건강 기록(PHR) 연구** - 모델의 문맥에 개인 건강 기록을 포함했을 때 건강 관련 AI의 효과가 어떻게 달라지는지 평가했다. - 제공된 글은 PHR 연구의 구체적인 결과가 이어지기 전에 중단되어 있어, 해당 부분의 결론은 확인할 수 없다. ## 실용적인 의미 Google이 제시한 방향은 AI를 단순한 답변 도구가 아니라 가설을 세우고 실험하며 결과를 검증하는 연구 파트너로 발전시키는 것이다. 다만 과학적 정확성, 의료 안전성, 개인정보 보호가 중요한 영역인 만큼, 실제 활용에서는 AI의 결과를 연구자와 의료진이 검토하고 제한된 범위에서 단계적으로 도입하는 접근이 필요하다.

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

업무용 에이전트 도구 설계 방법 | 피그마 블로그

Gemini Enterprise는 사용자가 AI를 관리하는 대신 업무 목표에 집중하도록 설계된 에이전틱 업무 도구다. 복잡한 멀티 에이전트 작업을 단순하게 보이게 하면서도, 사용자가 언제든 개입하고 결과를 검토할 수 있도록 투명성과 책임성을 강화했다. 개인용 챗봇을 넘어 공유 프로젝트와 AI 대시보드를 통해 팀의 지식과 업무 흐름을 통합하는 것을 목표로 한다. ## 소비자용 Gemini와 기업용 경험의 연결 - 브랜드 일관성을 위해 반짝이 아이콘, 그라디언트, 둥근 형태, 의도적인 모션 등 공통된 시각 언어를 사용한다. - 프롬프트 입력창은 소비자용 Gemini와 유사하게 유지하되, 기업 환경에서는 외부 서비스 연결 기능을 더 강조한다. - Google Workspace, Jira, Notion 등 업무 도구와 연결해 AI가 업무에 필요한 맥락을 충분히 확보하도록 한다. - 기업용 AI는 단일 질문에 답하는 도구가 아니라 여러 도구와 데이터 소스를 조율하는 오케스트레이션 플랫폼으로 확장된다. ## 대화형 인터페이스를 넘어선 AI Inbox - 복잡한 업무에서는 단순한 채팅 기록만으로 여러 에이전트의 진행 상황을 파악하기 어렵다. - AI Inbox는 에이전트가 수행 중인 작업, 완료한 작업, 사용자의 개입이 필요한 작업을 한눈에 보여주는 실시간 대시보드다. - 예를 들어 다음 날 마감인 시장 분석이 완료되어 검토 대기 중인지 즉시 확인할 수 있다. - 시각적 워크플로는 질문과 답변이 반복되는 채팅보다 팀 체크인에 가까운 방식으로 장기 실행 작업을 관리하게 한다. ## 개인용 챗봇에서 공유 프로젝트로 - Gemini Enterprise는 개인별 채팅 스레드 대신 지속적으로 유지되는 공유 프로젝트 공간을 제공한다. - AI는 프로젝트의 또 다른 팀원처럼 다음과 같은 작업을 수행한다. - 업무 실행 - 논의 내용 요약 - 프로젝트 파일 검색 - 문서 작성 및 편집 - 모든 팀원이 같은 공간에서 AI의 요청과 결과를 확인할 수 있다. - 각 요청을 어느 팀원이 보냈는지 표시해 AI의 행동 맥락과 책임 소재를 명확히 한다. ## 팀 사일로를 줄이는 단일 정보 기반 - 한 팀원이 기술 명세서를 업로드하면 다른 팀원이 파일을 직접 찾지 않고도 AI를 통해 내용을 확인할 수 있다. - 프로젝트 안에 대화, 파일, AI 결과물이 함께 축적되어 팀 내 지식 격차를 줄인다. - AI가 부서별로 흩어진 정보를 연결해 조직의 단일 정보 원천 역할을 하도록 설계했다. - 이 때문에 AI는 개인 생산성 도구를 넘어 팀 전체의 지능을 증폭하는 도구로 발전한다. ## 협업 방식에 맞춘 다양한 작업 모드 - 팀원들은 공유 프로젝트에서 AI와 함께 그룹 채팅을 진행할 수 있다. - Canvas Mode에서는 AI가 작성한 문서를 생성하고 직접 수정할 수 있다. - AI의 결과물을 일회성 답변으로 소비하지 않고, 팀이 검토·편집·재사용하는 협업 산출물로 다룬다. - AI가 프로젝트 공간에 계속 존재하기 때문에 기존 대화의 맥락과 업무 진행 상황을 유지할 수 있다. ## 신뢰와 사용자 개입의 균형 - 사용자가 AI의 내부 동작을 계속 관리하지 않아도 목표 달성에 집중할 수 있도록 경험을 단순화한다. - 동시에 민감한 정보와 사업상 중요한 의사결정이 다뤄지는 만큼, 사용자가 결과를 검토하고 개입할 수 있어야 한다. - 진행 상태, 완료 여부, 검토 필요 여부를 명확히 보여주는 것이 신뢰 형성의 핵심이다. - 기업용 에이전트는 자동화 수준뿐 아니라 투명성, 추적 가능성, 책임성을 함께 제공해야 한다. 실무적으로는 에이전트를 단순한 챗봇으로 도입하기보다, 업무 도구 연결·장기 작업 상태·팀 공유 공간·사용자 승인 절차를 함께 설계하는 것이 중요하다. ખાસ히 중요한 업무일수록 AI의 자율성보다 진행 상황과 개입 지점을 명확히 보여주는 UX가 우선되어야 한다.

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

장기 실행 에이전트 애플리케이션의 컨텍스트 관리

장시간 실행되는 멀티 에이전트 시스템은 모든 대화 기록을 그대로 누적하면 컨텍스트 윈도우 한계와 응답 품질 저하에 직면한다. Slack은 이를 해결하기 위해 Director의 구조화된 Journal, Critic의 신뢰도 주석 Review, 시간순 Timeline이라는 세 가지 컨텍스트 채널을 분리해 사용한다. 각 에이전트에 필요한 맥락만 제공함으로써 팀 전체의 일관성을 유지하면서도 과도한 정보 공유로 인한 창의성 저하와 확증편향을 줄이는 것이 핵심이다. ## 장시간 에이전트 시스템의 컨텍스트 문제 - 언어 모델 API는 상태가 없으므로, 호출 간 연속성을 유지하려면 전체 메시지 이력을 매번 전달해야 한다. - 에이전트 프레임워크는 일반적으로 메시지 기록을 누적하지만, 기록이 길어질수록 컨텍스트 윈도우가 빠르게 소진된다. - 컨텍스트 한도에 도달하기 전부터 응답 품질과 추론 능력이 저하될 수 있다. - 보안 조사처럼 수백 번의 추론 요청과 수 MB의 결과를 생성하는 작업에서는 단순한 대화 기록 누적만으로는 부족하다. - 멀티 에이전트 환경에서는 모든 정보를 공유하면: - 각 에이전트의 역할과 집중력이 흐려지고 - 기존 결론에 끌리는 확증편향이 커지며 - 독립적인 탐색과 창의적 추론이 억제될 수 있다. - 반대로 공유 정보가 너무 적으면 각 에이전트가 전체 조사 방향을 이해하지 못해 결과가 단절된다. ## 세 가지 컨텍스트 채널 Slack의 보안 조사 시스템은 Director가 조사 전체를 조율하고, 여러 Expert가 증거를 수집하며, Critic이 결과를 검토하는 구조다. - **Director’s Journal** - Director의 구조화된 작업 메모이자 장기 기억이다. - 조사 중 결정, 관찰, 사실, 가설, 미해결 질문 등을 기록한다. - **Critic’s Review** - Expert의 발견 사항을 검토하고 주석을 추가한 보고서다. - 각 결과의 신뢰도 점수를 포함해 어떤 증거를 얼마나 믿을지 판단하게 한다. - **Critic’s Timeline** - 여러 결과를 시간순으로 통합한 기록이다. - 사건의 진행 순서와 인과관계를 파악하도록 돕고, 신뢰도 점수도 함께 제공한다. - 세 채널은 서로 다른 목적을 가지며, 에이전트가 전체 메시지 이력 대신 역할에 맞는 맥락을 사용하도록 한다. ## Director’s Journal의 역할 Director는 어떤 질문을 던질지, 어떤 Expert를 호출할지, 언제 조사를 종료할지를 결정한다. 여러 단계와 라운드에 걸쳐 일관된 결정을 내리려면 이전에 무엇을 발견하고 판단했는지 기억해야 한다. - Journal은 Director가 사용하는 전용 journaling tool을 통해 업데이트된다. - 시스템 프롬프트는 Director가 Journal을 자주 갱신하고 짧은 메모 형태로 기록하도록 유도한다. - 기록의 목적은 완성된 보고서를 작성하는 것이 아니라, Director의 현재 사고 과정과 조사 상태를 유지하는 것이다. - 모든 에이전트는 현재 Journal 내용을 시간순으로 프롬프트에서 전달받는다. - 각 에이전트의 시스템 프롬프트에는 다음 내용이 설명된다. - Director의 역할 - 자신과 Director의 관계 - Journal의 목적 - Journal에 기록된 내용을 해석하는 방법 ## Journal의 기록 유형 Journal은 메모를 여섯 가지 유형으로 구분한다. - **decision**: 전략적 선택 - 예: 네트워크 활동보다 인증 이상 징후에 집중하기로 결정 - **observation**: 관찰된 패턴 - 예: 성공적인 인증 전에 여러 번의 로그인 실패가 발생 - **finding**: 확인된 사실 - 예: 사용자가 기존 이력에 없는 IP에서 인증 - **question**: 아직 해결되지 않은 질문 - 예: 의심스러운 활동 전후 중 언제 VPN 연결이 성립했는가 - **action**: 수행했거나 수행할 조치 - 예: Cloud Expert에게 EC2 인스턴스 활동 조사 요청 - **hypothesis**: 현재 검토 중인 가설 - 예: 계정 탈취보다 자격 증명 대입 공격에 가까운 패턴 추가로 각 항목에는 다음 정보를 포함할 수 있다. - 우선순위 - 후속 조치 목록 - 관련 증거 자료에 대한 인용 또는 참조 - 조사 단계(phase) - 라운드 번호 - 기록 시각 Journaling tool 자체는 복잡한 추론을 수행하지 않고 항목을 누적하는 역할만 담당한다. ## Journal을 통한 팀 정렬 Journal은 Director가 조사 방향을 유지하고 필요할 때 전략을 수정하도록 돕는다. - 조사 진행 상황을 관찰하고 측정할 수 있다. - 더 이상 유용하지 않은 조사 경로나 막다른 길을 식별할 수 있다. - 새 증거에 따라 가설과 조사 우선순위를 수정할 수 있다. - 다른 에이전트에게 공통된 조사 서사를 제공해 각자의 결과가 전체 조사와 연결되게 한다. - Director가 내린 결정과 아직 남은 질문을 명시적으로 전달해, Expert들이 중복되거나 무관한 작업을 수행하는 것을 줄인다. ## 실제 Journal 기록의 특징 글의 예시에서는 커널 모듈 로딩으로 탐지된 보안 알림을 조사한다. 실제로는 개발자가 개발 환경에서 패키지를 설치하던 중 발생한 오탐이었다. - 이벤트가 직접적인 `modprobe` 실행이 아니라 패키지 설치 과정의 스크립트였다는 점을 기록한다. - 관련 Expert 영역으로 엔드포인트 텔레메트리, 사용자 권한, 호스트 설정, 사용자 행동 패턴을 지정한다. - 개인 개발자 워크스테이션과 사용자 세션으로 보이는 단서를 정리한다. - 탐지 규칙이 실제 모듈 로딩이 아니라 스크립트 경로의 `"kmod"` 문자열에 반응했을 가능성을 제시한다. - 개발 환경에서 root 권한이 의도적으로 허용된다는 사실을 확인한다. - 프로세스 부모 관계, 엔드포인트 쿼리, SSH 인증서 로그 등을 추가로 검증할 대상으로 남긴다. - 조사 중간 결론으로 해당 이벤트가 정상적인 시스템 관리 활동에 의한 오탐일 가능성을 기록한다. 실무적으로는 전체 대화 로그를 무제한 보존하기보다, 역할별로 필요한 정보를 구조화하고 요약하는 방식이 적합하다. 특히 Director의 Journal에는 결정·근거·미해결 질문을 명시하고, Critic의 결과에는 신뢰도와 시간 순서를 함께 관리하면 장기 실행 에이전트의 일관성과 독립적인 탐색을 동시에 확보할 수 있다.

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

학술 워크플로우 개선: 더 나은 그림과 피어 리뷰를 위한 두 가지 AI 에이전트 소개 (새 탭에서 열림)

구글 클라우드 연구진은 학술 연구의 효율성을 극대화하기 위해 시각화 도구인 **PaperVizAgent**와 논문 리뷰 자동화 시스템인 **ScholarPeer**라는 두 가지 AI 에이전트 프레임워크를 공개했습니다. 이 시스템들은 연구자가 단순 반복적인 작업이나 행정적 부담에서 벗어나 혁신에 집중할 수 있도록 돕는 것을 목표로 하며, 실험 결과 전문가 수준의 도식 생성과 엄격한 논문 심사 능력을 입증했습니다. 이는 AI가 단순한 보조 도구를 넘어 학술 생태계의 능동적인 참여자로 진화하고 있음을 시사합니다. ### PaperVizAgent: 출판 가능한 수준의 학술 도식 생성 PaperVizAgent는 논문 텍스트를 기반으로 전문가급의 방법론 도식이나 통계 그래프를 생성하는 자율 프레임워크입니다. * **다중 에이전트 협업:** 검색(Retriever), 계획(Planner), 스타일 지정(Stylist), 시각화(Visualizer), 비평(Critic)을 담당하는 5개의 전문 에이전트가 팀을 이루어 작동합니다. * **반복적 정교화 프로세스:** 비평 에이전트가 생성된 결과물과 원문 사이의 불일치를 찾아내면, 시각화 에이전트가 이를 피드백으로 받아 수정을 반복하며 정확도를 높입니다. * **주요 입력 요소:** 연구의 기술적 세부 사항이 담긴 '소스 컨텍스트'와 시각적으로 전달하려는 의도를 담은 '도식 캡션'만으로 고품질 이미지를 생성합니다. * **성능 입증:** 신뢰성, 간결성, 가독성, 심미성 평가에서 기존의 GPT-Image-1.5나 Paper2Any를 능가했으며, 특히 간결성과 심미성 측면에서 인간 기준 점수(50점)를 상회하는 60.2점을 기록했습니다. ### ScholarPeer: 시니어 리뷰어를 모사하는 논문 심사 에이전트 ScholarPeer는 숙련된 연구자의 워크플로우를 따라 논문의 기술적 타당성을 검증하고 심사평을 작성하는 검색 기반 멀티 에이전트 시스템입니다. * **이중 스트림 정보 처리:** 문맥 습득과 능동적 검증이라는 두 가지 경로를 통해 단순히 텍스트를 생성하는 것이 아니라, 실제 문헌에 근거한 비판을 수행합니다. * **특화된 에이전트 구성:** 실시간 웹 검색으로 도메인 지식을 보강하는 '히스토리언 에이전트'와 저자가 놓친 데이터셋이나 비교 대상을 찾는 '스카우트 에이전트'가 포함됩니다. * **기술적 검증 엔진:** 다각도 Q&A 엔진이 논문의 기술적 주장을 엄격하게 검증하여, 강점과 약점 및 저자 질문이 포함된 전문적인 리뷰 보고서를 생성합니다. * **신뢰성 확보:** 기존 자동 리뷰 시스템 대비 높은 승률(Win-rate)을 보였으며, AI 특유의 환각 현상을 줄이고 실제 인간 리뷰어와 유사한 비판적이고 구체적인 피드백을 제공합니다. ### 학술 연구의 미래와 제언 이러한 AI 에이전트들의 등장은 기하급수적으로 증가하는 논문 제출량으로 인한 리뷰어들의 피로감을 해소하고, 시각화 역량이 부족한 연구자들에게 강력한 지원군이 될 것입니다. 연구자들은 이러한 도구를 활용해 연구의 전달력을 높이는 동시에, 제출 전 셀프 리뷰 단계에서 ScholarPeer를 활용해 논문의 논리적 허점을 미리 보완함으로써 승인 가능성을 높이는 전략을 취할 수 있습니다. 결과적으로 AI 에이전트는 학술 워크플로우 전반의 질적 수준을 상향 평준화하는 데 기여할 것으로 기대됩니다.

github4분 읽기큐레이션 요약

Copilot CLI에서 /fleet으로 여러 에이전트 동시에 실행하기

Copilot CLI의 `/fleet`는 하나의 작업을 여러 독립적인 하위 작업으로 나누고, 여러 에이전트를 병렬 실행하는 기능이다. 오케스트레이터가 작업의 의존성을 분석해 실행 순서를 정하고, 결과를 검증·통합하므로 여러 파일이나 모듈을 동시에 처리할 수 있다. 다만 에이전트들이 동일한 파일을 수정하면 잠금이나 자동 병합 없이 마지막 변경이 덮어쓰므로, 작업 범위와 파일 경계를 명확히 지정해야 한다. ## `/fleet`의 작동 방식 - 사용자가 `/fleet <작업 목표>` 형식으로 목표를 전달한다. - 오케스트레이터가 목표를 독립적인 작업 단위로 분해한다. - 작업 간 의존성을 분석해 병렬 실행 가능한 항목과 순차 실행해야 하는 항목을 구분한다. - 독립적인 작업은 백그라운드 하위 에이전트에 동시에 배정한다. - 작업 완료를 확인한 뒤 다음 의존 작업을 실행한다. - 각 결과를 검증하고 최종 산출물로 통합한다. - 하위 에이전트는 각자의 컨텍스트 창을 사용하지만 동일한 파일 시스템을 공유하며, 서로 직접 대화하지 않고 오케스트레이터를 통해 조정된다. ## 시작 방법 - 대화형 CLI에서는 다음과 같이 실행한다. ```text /fleet Refactor the auth module, update tests, and fix the related docs in the folder docs/auth/ ``` - 터미널에서 비대화형으로 실행할 수도 있다. ```bash copilot -p "/fleet <YOUR TASK>" --no-ask-user ``` - `--no-ask-user`는 사용자가 추가 질문에 응답할 수 없는 비대화형 환경에서 필요하다. ## 병렬화에 적합한 프롬프트 작성 - 작업마다 구체적인 산출물을 지정해야 한다. - 파일 - 테스트 스위트 - 문서 페이지 - 특정 모듈 - “문서를 작성하라”처럼 모호한 요청은 독립 작업을 식별하기 어려워 순차 실행될 가능성이 높다. - 예를 들어 인증, 엔드포인트, 오류 문서를 각각 별도 파일로 지정하면 세 작업은 병렬 처리할 수 있다. - 여러 문서를 연결하는 `docs/index.md`처럼 다른 결과물에 의존하는 작업은 후속 단계로 명시해야 한다. ## 파일 범위와 제약 조건 지정 프롬프트에는 각 에이전트가 담당할 범위를 명확히 적어야 한다. - 담당 디렉터리나 파일을 지정한다. - 수정해서는 안 되는 영역을 명시한다. - 테스트 변경 금지 - 의존성 업그레이드 금지 - 지정 디렉터리 외 수정 금지 - 완료 조건을 제시한다. - 린트 통과 - 타입 검사 통과 - 특정 테스트 통과 - API, UI, 설정처럼 서로 다른 영역을 별도 트랙으로 나누면 병렬 실행 효과가 커진다. ## 작업 의존성 선언 - 한 작업이 다른 작업의 결과를 필요로 하면 프롬프트에 `depends on` 관계를 명시한다. - 예를 들어 다음과 같이 데이터베이스 마이그레이션, ORM 모델, API 핸들러, 통합 테스트의 순서를 지정할 수 있다. - ORM 모델이 완성된 뒤 API 핸들러와 통합 테스트를 동시에 실행하도록 구성할 수 있다. - 의존성을 명시하지 않으면 에이전트가 충돌하거나 불완전한 결과를 바탕으로 작업할 수 있다. ## 사용자 지정 에이전트 활용 - `.github/agents/`에 전문 에이전트 설정 파일을 만들 수 있다. - 에이전트마다 다음을 지정할 수 있다. - 모델 - 사용 가능한 도구 - 역할과 작업 지침 - 문서 작성에는 `technical-writer` 같은 전문 에이전트를 사용하고, 코드 변경에는 기본 에이전트를 사용하는 식으로 역할을 나눌 수 있다. - 모델을 별도로 지정하지 않으면 현재 기본 모델이 사용된다. ## 병렬 실행 여부 확인 - 오케스트레이터가 작업을 여러 트랙으로 분해했는지 계획을 먼저 확인한다. - `/tasks` 명령으로 백그라운드 작업 목록과 진행 상태를 볼 수 있다. - 여러 트랙에서 동시에 진행 상황이 보고되는지 확인한다. - 병렬화되지 않는다면 다음처럼 먼저 분해하도록 요청할 수 있다. ```text Decompose this into independent tracks first, then execute tracks in parallel. Report each track separately with status and blockers. ``` ## 주요 주의점 - 하위 에이전트는 파일 잠금 기능 없이 동일한 파일 시스템을 공유한다. - 두 에이전트가 같은 파일을 수정하면 오류나 자동 병합 없이 마지막 완료 결과가 앞선 변경을 덮어쓸 수 있다. - 따라서 각 에이전트에 서로 다른 파일을 배정해야 한다. - 하나의 파일에 여러 에이전트가 기여해야 한다면: - 각자 임시 파일에 작성한 뒤 오케스트레이터가 병합하게 하거나 - 에이전트 실행 순서를 명시해야 한다. - 하위 에이전트는 오케스트레이터와의 이전 대화 기록을 볼 수 없으므로, 전달되는 프롬프트만으로 작업할 수 있도록 지침과 제약 조건을 self-contained하게 작성해야 한다. 실제로 `/fleet`를 사용할 때는 먼저 작업을 파일·모듈 단위로 분리하고, 의존성과 검증 조건을 프롬프트에 명시하는 것이 좋다. 특히 공유 파일을 여러 에이전트가 수정하지 않도록 범위를 엄격히 나누면 병렬 처리의 속도 이점과 결과 안정성을 함께 얻을 수 있다.

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

Squad가 리포지토리 내에서 협업하는 AI 에이전트를 실행하는 방법

Squad는 GitHub Copilot 기반의 여러 AI 에이전트를 저장소 안에 직접 구성해, 설계·구현·테스트·문서화를 협업 방식으로 수행하게 하는 오픈소스 도구다. 복잡한 오케스트레이션 인프라나 고급 프롬프트 설계 없이 `squad init`만으로 팀을 구성할 수 있으며, 저장소 파일을 공유 메모리로 활용한다. 다만 완전한 자동화가 아니라 사용자가 최종적으로 모든 변경 사항과 풀 리퀘스트를 검토하고 병합해야 한다. ## 저장소 안에 구성되는 AI 개발팀 - 전역 설치: ```bash npm install -g @bradygaster/squad-cli ``` - 저장소별 초기화: ```bash squad init ``` - 초기화하면 리드, 프런트엔드 개발자, 백엔드 개발자, 테스터 등 역할별 에이전트가 생성된다. - 사용자는 자연어로 작업을 요청하고, 코디네이터 에이전트가 적절한 전문가에게 작업을 분배한다. - 각 전문가는 별도의 브랜치와 파일을 사용해 구현, 테스트, 문서화 등을 병렬로 진행한다. ## 에이전트 간 작업 조정과 독립적 검토 - 예를 들어 JWT 인증을 요청하면: - 백엔드 에이전트는 refresh token과 bcrypt를 포함한 인증 기능을 구현한다. - 테스트 에이전트는 테스트 코드를 작성하고 실행한다. - 문서화 에이전트는 변경 내용을 정리해 풀 리퀘스트를 생성한다. - 테스트 실패 시 원래 구현자가 자기 코드를 스스로 수정하지 못하도록 검토 프로토콜을 적용할 수 있다. - 다른 에이전트가 별도의 컨텍스트에서 문제를 수정하므로, 자기검토보다 독립적인 리뷰에 가깝다. - 사용자는 중간 결과를 모두 검토하기보다 내부 검증 과정을 통과한 풀 리퀘스트를 검토할 수 있다. - 에이전트가 잘못된 가정을 할 수 있으므로, 최종 검토와 병합은 여전히 사람이 담당한다. ## `decisions.md`를 활용한 공유 메모리 - 실시간 대화나 벡터 데이터베이스 대신 저장소의 `decisions.md`에 아키텍처 결정을 기록한다. - 라이브러리 선택, 명명 규칙, 데이터베이스 연결 방식 같은 결정이 구조화된 블록으로 누적된다. - 이 방식의 장점: - 결정 사항이 지속적으로 보존된다. - Git으로 버전 관리할 수 있다. - 에이전트가 어떤 근거로 작업했는지 추적할 수 있다. - 연결이 끊기거나 세션이 재시작되어도 컨텍스트를 복구할 수 있다. - 저장소 파일을 팀의 “공유 두뇌”로 사용하는 비동기 협업 모델이다. ## 컨텍스트 분할 대신 컨텍스트 복제 - 한 에이전트가 설계, 구현, 테스트, 관리까지 모두 맡으면 컨텍스트 창이 메타 작업으로 가득 차고 환각 가능성이 커진다. - Squad의 코디네이터는 실제 작업을 수행하지 않고 전문가를 호출하는 얇은 라우터 역할을 한다. - 각 전문가는 별도의 추론 호출과 컨텍스트 창을 사용한다. - 지원 모델에서는 에이전트 하나당 최대 약 200K 토큰의 컨텍스트를 활용할 수 있다. - 하나의 컨텍스트를 여러 역할이 나누는 대신, 각 에이전트가 필요한 저장소 컨텍스트를 독립적으로 복제해 병렬 추론한다. ## 파일 기반의 명시적 에이전트 기억 - 에이전트의 기억은 모델 가중치나 숨겨진 세션 상태에 의존하지 않는다. - `.squad/` 폴더에 다음과 같은 텍스트 파일을 저장한다. - **Charter**: 에이전트의 역할과 정체성 - **History**: 에이전트가 과거에 수행한 작업 - **Team decisions**: 팀 전체가 공유하는 결정 사항 - 이 파일들은 코드와 함께 버전 관리되므로 에이전트의 행동 근거를 확인할 수 있다. - 저장소를 복제하면 코드뿐 아니라 프로젝트에 맞게 온보딩된 AI 팀의 기억도 함께 가져올 수 있다. ## 다중 에이전트 개발의 진입 장벽 완화 - 기존 다중 에이전트 시스템은 오케스트레이션 계층, 프레임워크, 벡터 데이터베이스 등을 직접 구성해야 하는 경우가 많다. - Squad는 CLI 명령 두 번으로 저장소에 사전 구성된 팀을 추가한다. - 복잡한 프롬프트 설계나 별도의 중앙 인프라 없이 바로 작업을 위임할 수 있다. - 저장소에 남는 결정 기록과 에이전트 이력 덕분에 동작을 비교적 쉽게 점검하고 재현할 수 있다. 실용적으로는 반복적인 구현·테스트·문서화 작업이 많은 저장소에서 Squad를 시도해볼 만하다. 다만 AI가 생성한 모든 변경 사항을 자동 병합하기보다는, 풀 리퀘스트와 테스트 결과를 사람이 확인하는 협업 도구로 사용하는 것이 적절하다.

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

멀티 에이전트 워크

멀티 에이전트 워크플로는 에이전트들이 상태, 실행 순서, 검증 방식에 대해 암묵적으로 가정하기 때문에 쉽게 실패한다. 이를 안정적으로 운영하려면 에이전트를 대화형 인터페이스가 아니라 분산 시스템의 구성 요소처럼 다뤄야 하며, 타입 스키마·명시적 액션·강제된 인터페이스가 필요하다. 특히 MCP(Model Context Protocol)는 이러한 계약을 실행 전에 검증해 잘못된 상태가 시스템에 전파되는 것을 막는다. ## 멀티 에이전트 시스템이 실패하는 이유 - 이슈 분류, 변경 제안, 테스트 실행, 풀 리퀘스트 생성처럼 관련 작업을 여러 에이전트가 나눠 처리하면 상태와 순서에 대한 암묵적 가정이 생긴다. - 한 에이전트가 이슈를 열자마자 다른 에이전트가 이를 닫거나, 후속 검사를 알지 못한 채 변경 사항을 배포하는 문제가 발생할 수 있다. - 자연어와 일관되지 않은 JSON만으로 통신하면 필드명, 자료형, 형식이 쉽게 달라져 자동화가 불안정해진다. ## 타입 스키마로 데이터 계약 정의 - 에이전트 간 데이터 교환에는 기계적으로 검증 가능한 타입과 엄격한 스키마를 사용해야 한다. - 예를 들어 사용자 프로필을 다음처럼 정의할 수 있다. - `id`: 숫자 - `email`: 문자열 - `plan`: `free`, `pro`, `enterprise` 중 하나 - 잘못된 메시지는 다음 단계로 전달하기 전에 실패시켜야 한다. - 재시도 - 메시지 수정 - 사람에게 에스컬레이션 - 디버깅도 로그를 해석하는 방식에서 “어떤 스키마 계약을 위반했는가”를 확인하는 방식으로 바뀐다. ## 액션 스키마로 의도 명확히 하기 - 데이터 형식이 올바르더라도 “분석하고 팀이 행동하도록 돕는다”처럼 지시가 모호하면 에이전트마다 다른 결정을 내릴 수 있다. - 가능한 결과를 제한된 액션 집합으로 정의하면 자동화 가능한 결과만 반환하게 만들 수 있다. - 예시 액션: - 추가 정보 요청: 필요한 정보 목록 포함 - 담당자 지정: 담당자 식별자 포함 - 중복 이슈로 종료: 원본 이슈 번호 포함 - 조치 없음 - 에이전트는 반드시 하나의 유효한 액션을 반환해야 하며, 그 외 결과는 검증 실패로 처리해 재시도하거나 에스컬레이션한다. - 글은 멀티 에이전트 장애의 상당수가 데이터 자체보다 “잘못된 행동 선택”에서 발생한다고 설명한다. ## MCP로 인터페이스 강제 - 스키마와 액션 규칙을 문서로만 정해두면 관례에 불과하며, 모든 에이전트가 이를 지킨다는 보장이 없다. - MCP는 각 도구와 리소스에 명시적인 입력·출력 스키마를 제공하고, 도구 호출 전에 이를 검증한다. - 예를 들어 `create_issue` 도구에 입력 스키마와 출력 스키마를 함께 정의할 수 있다. - MCP를 사용하면 에이전트가 다음과 같은 오류를 일으키기 어렵다. - 존재하지 않는 필드 생성 - 필수 입력 누락 - 에이전트 간 인터페이스 형식 변경 - 실행 전에 검증하므로 잘못된 호출이 운영 시스템에 영향을 주기 전에 차단된다. ## 실용적인 적용 방향 - 에이전트 간 모든 경계에 타입 스키마를 적용한다. - 자연어 지시의 최종 결과는 제한된 액션 스키마로 변환한다. - 도구 호출과 데이터 교환에는 MCP 같은 검증 계층을 둔다. - 스키마 위반을 자동 재시도, 수정, 에스컬레이션 대상으로 명시한다. - 멀티 에이전트 시스템을 챗봇이 아니라 계약과 인터페이스를 갖춘 소프트웨어 컴포넌트로 설계하는 것이 핵심이다.

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

더 스마트한 광고를 위한 우리의 (새 탭에서 열림)

Spotify는 광고 비즈니스의 다양한 구매 채널 간에 발생하는 의사결정 로직의 파편화 문제를 해결하기 위해 멀티 에이전트 아키텍처를 도입했습니다. 기존의 하드코딩된 워크플로우 대신, 광고주의 의도를 이해하고 공유된 신호를 바탕으로 추론하는 '프로그래밍 가능한 의사결정 계층'을 구축하여 모든 채널에서 일관된 최적화를 달성하고자 합니다. 이를 통해 복잡한 비즈니스 제약 조건을 유연하게 처리하고, 기존 광고 서비스들을 에이전트가 활용하는 도구로 재정의함으로써 시스템 전반의 운영 효율성을 극대화하는 것이 이 글의 핵심입니다. ### 기존 워크플로우의 구조적 한계와 파편화 * **채널별 로직 불일치:** 동일한 백엔드 인프라를 공유함에도 불구하고 Direct, Self-Serve, Programmatic 등 각 구매 채널별로 의사결정 로직과 휴리스틱이 다르게 구현되어 동작의 불일치가 발생합니다. * **중복 구현과 기술 부채:** 예산 할당이나 인벤토리 선택과 같은 핵심 로직이 각 채널 및 사용자 접점(Spotify Ads Manager, Salesforce, Slack 등)마다 중복 구현되어 관리 비용이 증가하고 로직의 변질(Drift)이 일어납니다. * **의도 계층(Intent Layer)의 부재:** 기존 시스템은 "브라질 내 도달 범위 극대화 및 비디오 인벤토리 보호"와 같은 복합적인 목표를 이해하고 이를 실행 가능한 도구 호출 순서로 변환하는 능력이 부족했습니다. ### 멀티 에이전트 기반 의사결정 계층의 도입 * **모듈형 에이전트 구조:** 복잡하고 확률적인 광고 로직을 정적인 규칙 엔진(Rules Engine)에 가두는 대신, 상황에 따라 추론하고 실행하는 독립적인 에이전트들의 집합으로 구성했습니다. * **공유 신호 기반 최적화:** 모든 에이전트는 인벤토리, 오디언스, 성능 이력 등 동일한 기저 신호를 공유하며 광고주의 목표와 Spotify의 비즈니스 제약 조건을 동시에 고려하여 최적의 경로를 찾습니다. * **기존 서비스의 도구화:** 기존 광고 서비스들을 처음부터 다시 만드는 대신, 에이전트가 목적에 따라 호출하여 사용할 수 있는 '도구(Tools)'로 활용함으로써 오케스트레이션 성능을 높였습니다. ### 에이전트 중심 설계를 위한 기술적 패러다임 전환 * **API 설계의 변화:** 단순히 데이터를 생성하고 수정하는 CRUD 방식에서 벗어나, 에이전트가 특정 기능을 실행하기 위해 직관적으로 이해하고 사용할 수 있는 '도구 중심 API'로 재설계했습니다. * **행동 중심의 평가:** 전통적인 유닛/통합 테스트를 넘어, 에이전트가 내린 결정이 비즈니스 목표에 부합하는지 확인하는 '행동 평가(Behavioral Evaluation)' 체계를 구축했습니다. * **추론 과정의 관측성:** 시스템 성능 지표뿐만 아니라 "에이전트가 왜 그런 결정을 내렸는가"에 대한 추론 과정을 추적하여 투명성을 확보했습니다. * **자율성을 제어하는 가드레일:** 입력값 검증 수준을 넘어 반자율적인 에이전트의 결정이 비즈니스 규칙과 안전 가이드라인 내에서 유지되도록 하는 가드레일 메커니즘을 도입했습니다. 복잡한 비즈니스 로직이 여러 플랫폼에 흩어져 있다면, 이를 개별 서비스로 관리하기보다 통합된 '의사결정 엔진'으로서의 에이전트 플랫폼을 구축하는 것이 장기적인 유지보수와 기능 확장 면에서 유리합니다. Spotify는 이를 미디어 플래닝(Media Planning) 영역에 우선 적용하여 복잡한 변수 속에서도 일관된 최적화 성능을 증명하고 있습니다.

google원문

에이전트 시스템 확장의 과학 (새 탭에서 열림)

구글 리서치는 AI 에이전트 시스템 설계에 있어 '에이전트 수가 많을수록 좋다'는 기존의 통념을 깨고, 과업의 특성에 따라 최적의 아키텍처가 달라짐을 실증적으로 분석했습니다. 180가지 에이전트 설정에 대한 대규모 실험 결과, 병렬 처리가 가능한 과업에서는 멀티 에이전트가 성능을 크게 향상시키지만 순차적 추론이 필요한 과업에서는 오히려 성능을 저하시킨다는 점을 발견했습니다. 연구팀은 이러한 정량적 원칙을 바탕으로 새로운 과업에 대해 최적의 구조를 87% 확률로 예측하는 모델을 제시하며 '에이전트 스케일링의 과학'을 제안합니다. ## 에이전트 시스템의 5가지 핵심 아키텍처 연구팀은 에이전트의 확장 방식을 이해하기 위해 다음과 같은 다섯 가지 표준 아키텍처를 정의하고 비교했습니다. * **단일 에이전트 (SAS):** 혼자서 모든 추론과 행동 단계를 순차적으로 수행하며 단일 메모리 스트림을 유지합니다. * **독립형 (Independent):** 여러 에이전트가 통신 없이 병렬로 하위 작업을 수행한 뒤 최종 결과만 합산합니다. * **중앙 집중형 (Centralized):** 중앙 조정자(Orchestrator)가 작업을 할당하고 결과를 합성하는 '허브 앤 스포크' 모델입니다. * **분산형 (Decentralized):** 에이전트들이 직접 소통하며 정보를 공유하고 합의에 도달하는 P2P 방식입니다. * **하이브리드 (Hybrid):** 계층적 감독과 에이전트 간 직접 통신을 결합하여 유연성과 통제력의 균형을 맞춥니다. ## 과업 특성에 따른 성능 차이: 병렬성과 순차성 에이전트 시스템의 성능은 과업이 가진 본질적인 구조에 따라 극명하게 갈리는 것으로 나타났습니다. * **병렬 과업의 이점:** 금융 분석처럼 하위 작업 분해가 용이한 과업에서는 중앙 집중형 아키텍처가 단일 에이전트 대비 80.9%의 성능 향상을 기록했습니다. * **순차적 추론의 페널티:** 엄격한 순서가 필요한 계획 수립(PlanCraft) 과업에서는 멀티 에이전트 구조 도입 시 성능이 오히려 39~70% 급락했습니다. 이는 통신 비용이 추론에 필요한 '인지 예산'을 잠식하기 때문입니다. * **도구 사용의 병목 현상:** 사용하는 도구의 개수가 많아질수록 에이전트 간 조율에 드는 비용이 기하급수적으로 증가하는 '도구-조율 트레이드오프'가 발생합니다. ## 신뢰성 보장을 위한 아키텍처의 역할 실제 배포 상황에서 중요한 오류 확산 방지 측면에서도 아키텍처별 성능 차이가 뚜렷했습니다. * **오류 증폭 위험:** 에이전트 간 소통이 없는 독립형 시스템은 한 에이전트의 실수가 최종 결과에 미치는 악영향이 단일 에이전트보다 17.2배나 높았습니다. * **중앙 관리의 검증 효과:** 중앙 집중형 시스템은 조정자가 '검증 병목(Validation Bottleneck)' 역할을 수행하여 오류 증폭을 4.4배 수준으로 낮추며 가장 안정적인 결과를 보였습니다. ## 최적의 에이전트 설계를 위한 제언 연구팀은 과업의 도구 수와 분해 가능성 등 측정 가능한 속성을 통해 최적의 아키텍처를 결정할 수 있는 예측 모델을 개발했습니다. * 무조건 에이전트 수를 늘리기보다, 과업이 병렬 처리에 적합한지(금융 분석 등) 혹은 순차적 정확도가 중요한지(코딩, 계획 등)를 먼저 파악해야 합니다. * 시스템의 복잡도가 높아질수록 오류 확산을 막기 위해 중앙 조정자를 둔 계층적 구조를 채택하는 것이 안정성 측면에서 유리합니다. * 이 연구에서 제시된 예측 모델을 활용하면 새로운 도메인에서도 80% 이상의 정확도로 가장 효율적인 에이전트 구성을 사전에 선택할 수 있습니다.

google원문

우리가 개인용 건강 코치를 (새 탭에서 열림)

구글은 제미나이(Gemini) 모델을 기반으로 사용자의 수면, 활동 등 생체 데이터를 분석해 맞춤형 가이드를 제공하는 '개인형 AI 건강 코치(Personal Health Coach)'를 개발하고 있습니다. 이 서비스는 기존 건강 앱들의 파편화된 정보를 통합하여 행동 과학에 기반한 능동적이고 적응적인 코칭 계획을 제시하는 것을 목표로 합니다. 특히 멀티 에이전트 프레임워크와 엄격한 전문가 검증 체계를 도입하여 AI 피드백의 과학적 신뢰성과 개인화된 정확성을 동시에 확보했습니다. **제미나이 모델의 건강 코칭 최적화 기술** * **시계열 데이터 추론:** 수면 및 활동과 같은 생체 시계열 데이터에 대해 수치적 추론을 수행하며, 개인의 기준점(Baseline) 및 인구 통계 데이터와 비교 분석하여 맞춤형 통찰을 도출합니다. * **멀티 에이전트 프레임워크(Multi-agent Framework):** 여러 전문 에이전트가 협업하는 구조를 채택했습니다. * **대화형 에이전트:** 사용자의 의도를 파악하고 맥락을 수집하며 전체 프로세스를 조율합니다. * **데이터 과학 에이전트:** 코드 생성 능력을 활용해 데이터를 검색, 분석 및 요약합니다. * **도메인 전문가 에이전트:** 피트니스 등 특정 분야의 지식을 바탕으로 개인화된 운동 계획을 수립하고 수정합니다. * **시스템 조율(Steering):** 범용 모델이 건강 및 웰니스 맥락에서 유용하게 작동하도록 소비자 건강 요구사항에 맞춘 전용 시스템 지침과 평가 모델을 적용했습니다. **전문가 검증 및 사용자 중심 설계** * **과학적 근거 확보:** 검증된 코칭 및 피트니스 프레임워크를 기반으로 코칭 로직을 설계했습니다. * **전문가 자문단 운영:** '소비자 건강 자문 패널'과 전문 피트니스 코치들의 피드백을 수용하여 실제 현장에서 통용되는 맥락 정보를 통합했습니다. * **대규모 사용자 연구:** '핏빗 인사이트 익스플로러(Fitbit Insights Explorer)' 등을 통해 수만 명의 사용자로부터 실제 데이터를 수집하고 이를 모델 학습과 개선에 활용했습니다. **SHARP 평가 프레임워크를 통한 신뢰성 강화** * **5대 평가 요소:** 안전성(Safety), 유익성(Helpfulness), 정확성(Accuracy), 관련성(Relevance), 개인화(Personalization)를 기준으로 코치를 다각도 평가합니다. * **방대한 평가 데이터:** 스포츠 의학, 수면, 심장학 등 다양한 분야의 전문가들이 참여하여 100만 개 이상의 주석(Annotation)과 10만 시간 이상의 인간 평가를 진행했습니다. * **자동 평가 시스템:** 오토레이터(Autoraters)를 도입해 전문가 평가를 확장 및 가속화함으로써 웰니스 권장 사항의 과학적 정확성을 지속적으로 검증합니다. 현재 이 서비스는 미국의 핏빗 프리미엄(Fitbit Premium) 안드로이드 사용자를 대상으로 공개 프리뷰가 시작되었으며, 곧 iOS로 확대될 예정입니다. AI 코칭은 단순한 정보 제공을 넘어 개인의 생체 리듬과 목표에 맞춰 실시간으로 변화하는 '살아있는 가이드'로서의 역할을 수행하게 될 것입니다.

google원문

개인 건강 에이전트 (새 탭에서 열림)

구글 리서치는 웨어러블 기기의 시계열 데이터와 혈액 지표 등 다중 모드(multimodal) 데이터를 분석하여 개인화된 건강 통찰력을 제공하는 LLM 기반의 '개인 건강 에이전트(PHA)' 연구 프레임워크를 공개했습니다. 이 시스템은 데이터 과학, 도메인 전문가, 건강 코치라는 세 가지 전문 서브 에이전트로 구성된 멀티 에이전트 아키텍처를 채택하여 사용자의 복잡하고 모호한 건강 질문에 정밀하게 대응합니다. 대규모 실제 사용자 데이터를 활용한 광범위한 평가 결과, PHA는 기존 단일 LLM 대비 데이터 분석 및 의학적 근거 기반 조언 측면에서 월등한 성능을 입증하며 차세대 개인용 건강 관리 도구의 가능성을 제시했습니다. **사용자 중심 설계와 멀티 에이전트 구조** * 1,300개 이상의 실제 건강 질문과 500명 이상의 사용자 설문 조사를 분석하여 일반 건강 지식 이해, 개인 데이터 해석, 실천 가능한 조언, 증상 평가라는 4가지 핵심 요구 사항을 도출했습니다. * 인간 전문가 팀의 업무 방식을 모방하여 데이터 과학자, 도메인 전문가, 개인 건강 코치 역할을 수행하는 서브 에이전트들이 협업하는 구조를 설계했습니다. * 약 1,200명의 사용자로부터 동의를 얻은 핏빗(Fitbit) 활동 데이터, 건강 설문, 혈액 검사 결과를 포함한 리얼 월드 데이터셋을 평가에 활용하여 실무적인 유효성을 검증했습니다. **데이터 과학 에이전트: 시계열 데이터의 수치적 해석** * 웨어러블 기기의 복잡한 시계열 데이터를 분석하며, "최근에 더 건강해졌나요?"와 같은 사용자의 모호한 질문을 구체적인 통계 분석 계획으로 변환합니다. * 분석 계획 수립과 코드 생성의 2단계 프로세스를 거쳐 통계적으로 유효한 답변을 도출하며, 생성된 코드는 실제 데이터에서 즉시 실행 가능한 수준의 정확도를 갖췄습니다. * 평가 결과, 데이터 분석 계획 수립 능력에서 75.6%의 점수를 기록하며 기본 모델(Gemini, 53.7%)을 크게 상회하는 성능을 보였습니다. **도메인 전문가 에이전트: 근거 기반의 신뢰할 수 있는 정보** * NCBI(미국 국립생물정보센터)와 같은 권위 있는 외부 데이터베이스에 접근하여 검증된 사실에 기반한 답변을 생성하는 다단계 추론 프레임워크를 사용합니다. * 사용자의 기저 질환이나 개인 프로필에 맞춰 정보를 맞춤화하여 제공하며, 전문 보건 자격시험 문항 및 감별 진단 능력을 평가하는 벤치마크에서 우수한 성과를 거두었습니다. * 의료 전문가와 일반 소비자 모두를 대상으로 한 인간 평가를 통해 정보의 정확성과 안전성을 동시에 확보했습니다. 이 연구는 범용 LLM의 한계를 넘어 전문화된 에이전트 간의 협업이 개인화된 의료 AI 서비스에서 얼마나 중요한지를 잘 보여줍니다. 앞으로 이러한 기술이 실제 서비스에 적용된다면, 사용자는 자신의 건강 데이터를 단순히 수집하는 것을 넘어 능동적으로 이해하고 실질적인 생활 습관 변화를 이끌어내는 강력한 조력자를 얻게 될 것입니다.