AI-Q 스킬, 리서치 에이전트의 데이터 경계

AI 요약

• 무슨 일: NVIDIA가 aiq-research agent skill을 공개해 Claude Code, Codex, OpenCode가 AI-Q 딥리서치 서버에 작업을 위임하게 했습니다.
  • 발표일은 2026년 5월 20일이며, GitHub의 .agents/skills/aiq-research 패키지와 AI-Q Blueprint 문서를 함께 봐야 합니다.
• 의미: 범용 에이전트가 검색, 인용, 평가, 인증을 직접 떠안지 않고 기업 데이터 안쪽의 연구 백엔드에 맡기는 구조입니다.
• 주의점: 서버 운영, MCP 인증, 토큰 만료, Nemotron endpoint 가용성은 여전히 도입 팀의 책임으로 남습니다.

NVIDIA가 2026년 5월 20일 공개한 AI-Q agent skill은 겉으로 보면 작은 개발자 도구 업데이트처럼 보입니다. SKILL.md 파일 하나와 Python helper script가 들어 있는 패키지입니다. 하지만 이 발표가 흥미로운 이유는 “에이전트가 더 똑똑해졌다”가 아니라, 범용 에이전트가 무엇을 직접 하지 말아야 하는지를 꽤 선명하게 드러내기 때문입니다.

NVIDIA의 설명은 단순합니다. Claude Code, Codex, LangChain Deep Agents 같은 하네스는 세션을 관리하고, 도구를 연결하고, 코드를 실행하고, 사용자의 의도를 따라 여러 단계를 굴리는 데 강합니다. 그러나 기업 내부 문서 여러 개를 읽고, 근거가 붙은 의사결정 브리프를 만들고, 장기 연구 계획을 세우고, 출처를 보존하고, 인증된 데이터 소스에 안전하게 접근하는 일까지 하네스 안에서 매번 다시 만들려면 복잡도가 개발자에게 되돌아옵니다. AI-Q skill은 이 복잡한 연구 파이프라인을 하네스 밖의 AI-Q 서버에 둔 뒤, 에이전트가 그 서버에 연구를 맡기고 구조화된 보고서를 받도록 합니다.

중요한 변화는 “스킬”이라는 단어의 무게입니다. 최근 에이전트 생태계에서 skill은 종종 프롬프트 묶음, 작업 지침, CLI wrapper, 작은 자동화 스크립트를 모두 가리킵니다. 그래서 커뮤니티에서는 skill이 유용한 재사용 단위인지, 아니면 실행 책임이 흐릿한 프롬프트 포장지인지에 대한 논쟁이 계속됩니다. 이번 NVIDIA 사례는 후자에 머물지 않으려는 시도에 가깝습니다. skill이 단순히 “이렇게 해라”라고 지시하는 것이 아니라, 별도 서버, 비동기 job, MCP 인증, 평가 harness, 인용 관리, OpenTelemetry trace와 연결되기 때문입니다.

발표의 핵심은 연구 기능이 아니라 경계입니다

NVIDIA Technical Blog는 이 skill을 “specialized deep research skill”이라고 부릅니다. 하지만 여기서 딥리서치 자체보다 더 중요한 단어는 “delegates”입니다. 에이전트 하네스가 연구 작업을 로컬 또는 호스팅된 AI-Q 서버에 넘기고, 그 서버가 검색·계획·종합·인용을 처리한 뒤 보고서를 돌려줍니다. 하네스는 연구 파이프라인 전체를 소유하지 않습니다.

이 구조는 엔터프라이즈 AI에서 꽤 현실적인 문제를 겨냥합니다. 기업 데이터는 보통 깨끗한 공개 웹 검색 API 하나로 정리되지 않습니다. SharePoint, Confluence, GitHub Enterprise, ServiceNow, 데이터 웨어하우스, 사내 정책 문서, 규제 문서, 고객별 격리 저장소가 뒤섞입니다. 접근 권한도 사람, 앱, 서비스 계정, 위임 토큰에 따라 다릅니다. 범용 에이전트가 이 모든 데이터에 직접 접근하면 권한 범위가 커지고, 감사가 어려워지고, 실패했을 때 어떤 경로로 어떤 문서를 읽었는지 추적하기 힘들어집니다.

AI-Q skill은 반대로 묻습니다. 에이전트가 민감한 원문 데이터에 직접 손을 대야 할까요? NVIDIA의 답은 “항상 그렇지는 않다”에 가깝습니다. AI-Q 서버를 데이터가 있는 환경 안쪽에 두고, 하네스는 연구 요청과 최종 보고서만 주고받는 설계를 제안합니다. 규제 산업에서 중요한 것은 모델이 모든 문서를 읽을 수 있다는 사실이 아니라, 누가 어떤 경로로 어떤 근거를 사용했는지 설명할 수 있다는 점입니다.

NVIDIA가 공개한 helper script도 이 경계를 보여줍니다. scripts/aiq.py는 /chat 요청을 보내고, deep research가 비동기로 시작되면 job id를 받아 polling하며, 완료된 report를 가져옵니다. 기본 서버 주소는 http://localhost:8000이고 AIQ_SERVER_URL로 바꿀 수 있습니다. 즉 스킬은 클라우드 SaaS 하나를 강제하기보다, 로컬 개발 환경이나 기업 내부에 띄운 AI-Q 서버를 호출하는 얇은 연결 계층입니다.

AI-Q는 범용 에이전트가 아니라 연구 백엔드에 가깝습니다

AI-Q Blueprint README는 자신을 “enterprise-grade research agent”로 설명합니다. 기본 구성은 NVIDIA NeMo Agent Toolkit과 LangChain Deep Agents 위에 올라갑니다. 빠른 인용 답변과 긴 보고서형 연구를 모두 제공하고, 평가 harness로 품질을 측정할 수 있다는 것이 핵심 주장입니다.

문서를 보면 내부 구조는 대략 네 갈래입니다. intent classifier가 요청의 성격과 연구 깊이를 판정하고, clarifier가 모호한 요청을 사람에게 확인하며, shallow researcher는 빠르고 제한된 tool-calling 검색을 처리하고, deep researcher는 계획·검색·반복·초안 갱신·출처 번호 매기기·최종 보고서 생성을 담당합니다. 특히 deep researcher 문서는 기본 연구 반복 횟수를 2회로 설명하고, planner subagent와 researcher subagent를 orchestrator가 조율하는 흐름을 보여줍니다.

이것은 Claude Code나 Codex가 하는 일과 미묘하게 다릅니다. 범용 하네스는 “이 저장소에서 버그를 고쳐라”, “이 API를 조사해 구현해라”, “테스트를 돌리고 실패를 고쳐라” 같은 사용자의 작업 흐름을 따라갑니다. AI-Q는 그중 연구라는 하위 문제를 전담합니다. 요청을 분류하고, 필요한 경우 명확화 질문을 만들고, 검색 도구를 호출하고, 결과를 근거로 보고서를 쓰는 쪽에 최적화되어 있습니다.

개발자 관점에서 이 차이는 큽니다. 코딩 에이전트에 “우리 내부 정책과 고객 계약을 읽고 이 기능을 출시해도 되는지 브리프를 써줘”라고 시키는 순간, 문제는 코드 수정이 아니라 데이터 접근, 감사, 출처, 권한 위임이 됩니다. 일반 에이전트가 브라우저와 shell, MCP 도구를 모두 붙잡고 직접 탐색하면 편해 보이지만, 운영 환경에서는 권한이 너무 넓어질 수 있습니다. AI-Q 방식은 코딩 에이전트가 연구원이 되는 것이 아니라, 검증 가능한 연구 백엔드를 호출하게 만드는 쪽입니다.

MCP 통합은 편의 기능보다 권한 모델에 가깝습니다

이번 발표에서 가장 실무적인 부분은 MCP 통합입니다. NVIDIA는 AI-Q가 NeMo Agent Toolkit 위에 있으며, MCP 서버가 function group으로 연결된다고 설명합니다. 그리고 세 가지 인증 패턴을 문서화합니다. 인증이 없는 MCP 서버, service account를 쓰는 MCP 서버, 그리고 downstream API가 AI-Q 사용자의 bearer token을 신뢰하는 경우입니다.

여기서 주목할 점은 “MCP를 붙였다”가 아니라 “MCP 인증 패턴을 나눴다”입니다. 에이전트 제품 발표는 종종 수십 개 도구와 커넥터를 붙일 수 있다고 말합니다. 하지만 기업 환경에서 더 중요한 질문은 어떤 identity로 그 도구를 호출하느냐입니다. 앱 권한으로 읽는지, 사용자 권한을 위임하는지, 장기 job이 토큰 만료를 어떻게 처리하는지, 실패 로그가 어디에 남는지가 실제 배포의 병목입니다.

NVIDIA도 이 한계를 숨기지 않습니다. 사용자 bearer token을 넘기는 패턴에서는 request token이 job submit 시점에 캡처되어 async Dask worker 안에서 복원되지만, 현재는 job 중간 토큰 refresh가 되지 않는다고 설명합니다. 토큰 TTL보다 오래 걸리는 job은 인증이 필요한 tool call에서 실패할 수 있고, worker 내부 refresh는 다음 릴리스 계획으로 남아 있습니다. 이 문장은 작지만 중요합니다. 에이전트가 “장기 작업을 한다”는 말은 인증과 세션 수명도 장기 작업에 맞게 설계되어야 한다는 뜻이기 때문입니다.

온프레미스 딥리서치가 다시 주목받는 이유

AI-Q skill의 또 다른 축은 배포 위치입니다. NVIDIA는 AI-Q Blueprint가 Docker Compose와 Helm chart를 포함하며, 개발자 노트북, 온프레미스 또는 클라우드 Kubernetes, air-gapped data center에 같은 Blueprint를 배포할 수 있다고 설명합니다. 또한 Dell AI Factory에서 검증된 reference architecture를 언급하며 금융, 공공, 제조 같은 규제 산업을 직접 겨냥합니다.

이 흐름은 최근 AI 인프라 경쟁과 잘 맞물립니다. 모델 API를 쓰는 것만으로 충분했던 단계에서는 에이전트가 클라우드 모델에 프롬프트와 문서를 보내 답을 받으면 됐습니다. 하지만 코딩 에이전트와 업무 에이전트가 실제 시스템에 연결되면서 데이터 경계가 다시 중심에 왔습니다. 소스코드, 내부 정책, 고객 계약, 보안 로그, 의료 문서, 공공 데이터는 모두 “모델이 읽을 수 있는가”보다 “어디에서 읽고, 무엇을 남기고, 누가 승인했는가”가 더 중요합니다.

AI-Q는 이 질문에 NVIDIA식 답을 제시합니다. 연구 파이프라인은 데이터가 있는 곳에서 돌리고, 필요한 모델은 NVIDIA API Catalog나 자체 호스팅 NIM으로 선택하며, Nemotron 계열 open model을 온프레미스에 둘 수 있게 합니다. cloud frontier model을 완전히 배제하자는 주장은 아닙니다. 오히려 공식 글은 복잡한 orchestration과 planning에는 frontier model을 쓰고, 민감한 연구 작업은 self-hosted model로 라우팅하거나, 엄격한 compliance 요구가 있으면 frontier model을 끌 수 있다고 설명합니다.

개발자에게 이 지점은 “모델 선택”보다 “워크플로 라우팅” 문제로 다가옵니다. 같은 에이전트 작업 안에서도 공개 웹 검색, 내부 문서 검색, 민감 데이터 요약, 최종 보고서 작성은 서로 다른 모델과 권한 경계를 가질 수 있습니다. AI-Q skill은 범용 하네스가 이 모든 분기를 직접 구현하지 않고, 연구 백엔드가 맡도록 하는 작은 표준 인터페이스처럼 작동합니다.

평가와 추적은 제품 기능이 아니라 책임 소재입니다

NVIDIA README는 AI-Q가 FreshQA, Deep Research Bench, DeepSearchQA 같은 평가 harness를 제공한다고 설명합니다. Deep Researcher 문서는 citation verification post-processing도 언급합니다. 최종 보고서가 나온 뒤 deterministic post-processing이 실제 검색된 source와 citation을 대조해 감사 가능성을 높인다는 내용입니다. NVIDIA Agent Intelligence Toolkit 문서는 LangChain, LlamaIndex, CrewAI, Microsoft Semantic Kernel 같은 기존 프레임워크와 나란히 쓸 수 있고, 특정 장기 메모리나 데이터 소스에 묶이지 않는다고 설명합니다.

이런 기능은 화려해 보이지 않습니다. 하지만 기업 에이전트에서는 바로 이 지점이 구매와 배포를 가릅니다. “보고서가 그럴듯하다”는 충분하지 않습니다. 어떤 문서에서 온 주장인지, 어떤 query가 실행됐는지, 어떤 tool이 호출됐는지, 실패했다면 어느 단계에서 실패했는지, 사람이 승인한 plan과 실제 실행이 일치하는지 확인할 수 있어야 합니다.

OpenTelemetry trace도 같은 맥락입니다. 에이전트가 내부 데이터를 읽고 결론을 냈는데 로그가 “LLM response generated” 정도로만 남으면, 보안팀과 법무팀은 그 시스템을 신뢰하기 어렵습니다. NVIDIA가 AI-Q를 단순 오픈소스 예제라기보다 reference architecture와 엮는 이유도 여기에 있습니다. 에이전트가 할 수 있는 일이 많아질수록, 실제 판매되는 것은 능력 그 자체보다 능력을 제한하고 설명하는 운영 층입니다.

단순한 프롬프트 스킬과 무엇이 다른가

커뮤니티에서 agent skill에 대한 회의론은 이유가 있습니다. 어떤 skill은 사실상 긴 시스템 프롬프트에 가깝습니다. “이 도메인에서는 이런 절차를 따라라”는 지침이 유용할 때도 있지만, 그것만으로는 데이터 접근, 오류 처리, 평가, 감사, 권한 모델이 생기지 않습니다. 오히려 skill이 많아질수록 어떤 지시가 언제 작동했는지 불투명해질 수 있습니다.

AI-Q skill의 차별점은 skill이 하네스의 행동 방식을 바꾸는 데서 끝나지 않고, 외부 시스템 호출 경로를 제공한다는 점입니다. python3 scripts/aiq.py chat "<query>"를 통해 routed /chat 요청을 보내고, deep research가 필요하면 job id를 받아 polling합니다. agents, submit, research, status, state, report, stream, cancel 같은 command도 정의되어 있습니다. 이것은 “생각을 잘해라”가 아니라 “이 서버에 작업을 맡기고 결과를 이렇게 회수해라”에 가깝습니다.

물론 이 구조가 자동으로 성공을 보장하지는 않습니다. AI-Q 서버를 운영해야 하고, 데이터 소스를 붙여야 하고, API key와 서비스 계정을 관리해야 하며, 모델 endpoint 가용성도 봐야 합니다. 문서는 Nemotron Super가 호환되고 테스트됐지만 Build API endpoint가 수요 때문에 429 또는 503을 낼 수 있다고 적고, 기본 config는 안정성을 위해 Nemotron Nano를 사용한다고 설명합니다. 이 대목은 제품 발표의 작은 주석처럼 보이지만, 운영팀에는 매우 현실적인 신호입니다. 딥리서치 품질만 보지 말고, endpoint availability와 fallback 모델, self-hosting 경로까지 같이 설계해야 합니다.

개발팀에 주는 실무적 영향

개발팀이 지금 당장 AI-Q skill을 써야 한다는 뜻은 아닙니다. 더 중요한 것은 패턴입니다. 앞으로 코딩 에이전트와 업무 에이전트는 모든 기능을 자기 안에 넣는 방향만으로 가지 않을 가능성이 큽니다. 대신 특정 능력은 skill, MCP server, workflow backend, evaluation harness, sandbox, trace system으로 분리되고, 범용 하네스는 이 능력들을 호출하는 지휘 계층이 됩니다.

이 패턴을 적용하면 팀의 설계 질문도 바뀝니다. “어떤 LLM이 연구를 잘하나”보다 먼저 물어야 할 것은 다음에 가깝습니다. 연구 작업에 필요한 데이터는 어디에 있는가. 에이전트가 원문을 직접 읽어도 되는가. 보고서에는 어떤 수준의 citation이 필요한가. 사용자의 권한을 위임해야 하는가, 앱 권한으로 충분한가. job이 오래 걸릴 때 토큰은 어떻게 갱신되는가. 실패와 재시도는 누가 기록하는가. 같은 질문에 대해 비용이 낮은 shallow path와 품질이 높은 deep path를 어떻게 나눌 것인가.

AI-Q Blueprint는 이 질문들에 대한 하나의 구현체입니다. NVIDIA 생태계에 깊이 들어간 팀에는 NIM, Nemotron, NeMo Agent Toolkit, Dell AI Factory와 연결되는 장점이 있습니다. 반대로 이미 OpenAI Agents SDK, AWS Bedrock AgentCore, Azure Foundry, LangGraph 자체 구성에 투자한 팀이라면 AI-Q를 그대로 도입하기보다 “연구 백엔드 분리”라는 구조만 참고할 수 있습니다.

한국 독자에게는 왜 중요한가

한국 기업의 AI 도입 논의에서도 비슷한 간극이 보입니다. 데모에서는 에이전트가 사내 문서를 검색하고 보고서를 쓰는 장면이 쉽게 나옵니다. 실제 도입 단계에 들어가면 개인정보, 산업별 규제, 망분리, 보안 감사, 외부 API 반출, 기록 보존, 모델 선택, 비용 통제가 한꺼번에 올라옵니다. 이때 “좋은 모델을 붙이면 된다”는 답은 너무 얕습니다.

NVIDIA AI-Q skill은 이 간극을 정확히 찌릅니다. 에이전트에게 모든 문을 열어주는 대신, 연구 파이프라인을 기업 데이터 경계 안에 두고, 범용 하네스는 구조화된 보고서를 받습니다. 잘 설계하면 코딩 에이전트가 내부 위키와 정책 문서를 직접 헤집지 않아도, 검증된 연구 서버가 필요한 근거를 찾아 인용과 함께 답을 줄 수 있습니다. 반대로 이 경계를 흐리면 skill은 또 하나의 권한 우회로가 될 수 있습니다.

그래서 이번 발표는 “NVIDIA가 딥리서치 스킬을 냈다”보다 “에이전트 능력을 어디에 배치할 것인가”라는 질문으로 읽는 편이 낫습니다. 코딩 에이전트 경쟁은 IDE와 터미널에서 시작했지만, 이제는 연구, 인증, 데이터 주권, 평가, 추적 시스템으로 확장되고 있습니다. AI-Q skill은 그 확장의 작은 사례이면서도, 에이전트 시대의 엔터프라이즈 아키텍처가 점점 더 분리되고 있다는 신호입니다.

앞으로 팀이 선택해야 할 것은 하나의 만능 에이전트가 아닐 수 있습니다. 범용 하네스는 사용자의 작업 흐름을 이해하고, 연구 서버는 데이터 경계 안에서 근거를 만들고, MCP와 서비스 계정은 접근권을 나누고, trace와 평가 harness는 사후 설명을 담당합니다. NVIDIA의 이번 업데이트가 의미 있는 이유는 바로 이 분업을 SKILL.md라는 작고 이식 가능한 단위로 드러냈기 때문입니다.