빈 폴더에서 출시까지 한 흐름으로 — Work IQ Developer Tools 개발자 미리 보기
소프트웨어가 바뀌고 있습니다. 사람을 위해 만들어진 앱에서, 맥락을 추론하고 사용자를 대신해 행동하는 에이전트로 무게 중심이 옮겨 가는 중입니다. Microsoft 365 Copilot이 이 변화를 수억 명의 사용자 앞에 가져다 놓았고, Work IQ는 에이전트가 딛고 설 프로덕션급 인텔리전스 레이어를 제공했습니다.
그런데 그 사이에 빠진 조각이 있었습니다. 아이디어에서 고객 앞에서 돌아가는 프로덕션 에이전트까지 가는 경로입니다.
Microsoft가 Work IQ Developer Tools(WIQD)의 개발자 미리 보기를 발표했습니다. 스킬·커넥터·선언형 에이전트 등 어떤 플러그인이든 빈 폴더에서 게시되고 모니터링되는 제품까지 하나의 흐름으로 끌고 가는 Microsoft 365 Copilot 확장용 에이전틱 개발 경험입니다.
설치는 한 줄
# Windows에서 WIQD 설치
iex "& { $(irm 'https://aka.ms/wiqd/install.ps1') }"
# Mac / Linux에서 WIQD 설치
curl -fsSL https://aka.ms/wiqd/install.sh | bash
설치 후에는 선호하는 에이전틱 환경(예: GitHub Copilot CLI)에서 이렇게 지시할 수 있습니다.
> 사내 지원 플러그인을 만들어 줘. 지식 베이스에서 가장 많이 들어오는 질문을 처리하는
선언형 에이전트, 지원 티켓 분류를 돕는 SKILL.md 스킬, 사내 지원 플랫폼에 연결하는
원격 MCP 커넥터를 추가하고, 검증한 뒤 사내 카탈로그에 게시해 줘.
설치 한 번, 하나의 사고 모델, 하나의 흐름 안에 담긴 전체 수명 주기. 개발자가 직접 실행하든, 옆에서 함께 작업하는 Copilot이 실행하든 동일합니다.
왜 만들었나
지난 6개월 사이에 Microsoft 365 Copilot 플러그인 — 스킬, 커넥터, 선언형 에이전트 무엇이든 — 을 만들어 보셨다면 그 과정을 아실 겁니다.
스캐폴딩 → 등록 → 검증 → 공유 → 대상 지정 → 제출 → 인증 추적. 그런데 이 단계들이 서로 다른 시스템에 흩어져 있었습니다.
Work IQ Developer Tools는 이 흩어진 수명 주기를 하나의 제품 형태를 갖춘 개발자 경험으로 묶습니다. Microsoft 365 Copilot 확장 개발이 더 이상 “강력한 이너 루프 뒤에 매 단계마다 절벽”인 구조일 필요가 없어집니다.
Copilot이 가능케 한 속도로 Copilot 플러그인을 출시하려면, 전체 여정이 에이전트가 처음부터 끝까지 실행할 수 있는 하나의 표면이 되어야 합니다.
Copilot이 운전하도록 설계됐습니다
원문이 흥미로운 지점은 “CLI는 아마도 가장 덜 중요한 부분”이라고 못 박는 대목입니다. 중요한 것은 아이디어에서 프로덕션까지의 경로가 에이전트에게 통째로 넘길 수 있는 하나의 흐름이라는 사실이며, WIQD는 에이전트가 그 루프를 첫날부터 돌리는 데 필요한 모든 것을 제공합니다.
1. 에이전트 플러그인
Copilot과 IDE 채팅 안에서 전체 수명 주기를 노출합니다. 원하는 바를 서술하면(“지원 티켓 분류 에이전트를 스캐폴딩하고, Graph 커넥터를 추가하고, 검증한 뒤 평가를 생성해 줘”) 알맞은 스킬이 처리합니다. Copilot이 Copilot 플러그인을 출시하는 구조입니다.
2. 언어 서버(LSP)
플러그인 관련 파일에 대한 실시간 진단을 제공합니다. 대상은 다음과 같습니다.
- 선언형 에이전트 매니페스트
- 플러그인 매니페스트
- Adaptive Card
개발자가 타이핑하는 동안에도, 코딩 에이전트가 타이핑하는 동안에도 동일하게 작동합니다. 사람을 궤도에 붙잡아 두는 그 신호가 에이전트도 궤도에 붙잡아 둡니다.
3. 어디서나 기계 판독 가능한 출력
- 모든 대화형 프롬프트에 플래그 등가물이 존재합니다.
- 모든 명령이
--json을 지원합니다. - 종료 코드(exit code)가 안정적으로 유지됩니다.
따라서 손으로 실행하던 명령을 그대로 파이프라인에 넣을 수 있습니다.
빌드 단계에서 실제로 일어나는 일
내부적으로 빌드 단계는 다음을 수행합니다.
- 매니페스트를 생성합니다.
- 의존성을 탐색합니다 — MCP 도구(라이브 핸드셰이크를 통해), API 플러그인, 에이전트 커넥터, 스킬.
- 각 스키마를 매니페스트에 연결합니다.
- LSP를 구성합니다.
에이전트는 도구의 의미론을 이해하고, 좁은 명령 표면만으로는 불가능한 통합 결정을 내립니다.
하나의 흐름, 처음부터 끝까지
WIQD는 사람과 코딩 에이전트에게 전체 수명 주기에 대한 동일한 문법을 제공합니다.
create → configure → validate → provision → package → share → ask → eval → publish → monitor
한 번 만들고 나면 이 바퀴를 계속 돌리면 됩니다. 채팅으로 원하는 바를 서술하든, 정밀한 제어를 위해 터미널에 명령을 입력하든, CI/CD 파이프라인에 엮든 동일한 동사가 작동합니다. CLI, 에이전트 플러그인, VS Code 확장이 모두 하나의 코어 위에서 돌기 때문에 같은 엔진, 같은 동작, 같은 계약이 유지됩니다.
| 단계 | 하는 일 |
|---|---|
| Build | 플러그인 스캐폴딩, 지시문 편집, 기능·도구 연결, 현지화 |
| Quality | 매니페스트 검증, 평가(eval) 생성·실행, Work IQ를 사용한 디버깅 |
| Preview | 패키징, 프로비저닝, 실제 사용자와 공유 |
| Ship | Microsoft 365 관리 센터 또는 Partner Center를 통한 Microsoft 365 스토어 게시*, 대상 지정, 도입 현황 모니터링 |
* 곧 제공 예정(Coming soon)
플러그인이 재사용 단위, 에이전트는 조합물
WIQD의 설계 철학에서 중요한 부분입니다. 플러그인이 지속 가능한 제품 단위입니다.
하나의 플러그인은 다음을 담을 수 있습니다.
- 선언형 에이전트(declarative agent)
- 재사용 가능한 SKILL.md 스킬
- 원격 MCP 커넥터
- 이 기능들을 Microsoft 365 앱 패키지로 묶는 메타데이터
여기서 선언형 에이전트는 플러그인의 일급 구성 요소이지, 모든 재사용 가능한 기능이 그 안에 들어가야 하는 컨테이너가 아닙니다.
이 모델의 이점은 명확합니다. 팀은 집중된 기능을 한 번만 작성해 공유 레지스트리에 게시하고, 그것을 여러 에이전트 경험에 조합해 넣을 수 있습니다. 에이전트 작성자는 통합을 다시 만드는 시간을 줄이고, 플러그인 소유자는 검증·버전 관리·수정에 대한 단일 진실 공급원(single source of truth)을 유지합니다.
품질은 루프의 일부, 나중에 덧붙이는 것이 아닙니다
플러그인이 데모를 넘어 실제 워크플로로 들어가면, 출시 기준도 함께 올라갑니다. 고객은 실제로 들어오는 다양한 프롬프트 전반에서 정확하고, 근거가 있고, 일관된 플러그인을 기대합니다.
WIQD는 매니페스트를 읽어 표준 YAML 형식의 타깃 평가(eval)를 생성합니다.
- 이너 루프에서 로컬로 실행하거나 CI/CD에서 실행
- 눈대중이 아니라 실행 간 회귀(regression)를 측정
- 반복 개선
디버깅이 필요하면, 프로비저닝에서 올바른 정보를 해석해 Work IQ를 사용해 터미널에서 직접 에이전트를 호출합니다. 도구 사이에서 ID를 복사-붙여넣기 할 필요가 없습니다.
# 선호하는 에이전틱 환경에서
> 내 플러그인 구성에 기반해 평가해 줘
# 또는 CLI로
wiqd agent eval init
wiqd agent eval
실제 고객에게 출시하고, 성장시키기
기존 툴체인이 멈추고 포털 마라톤이 시작되던 지점이 바로 게시(publishing)였습니다. 이제 그 마지막 구간이 같은 흐름 안에 들어옵니다.
- 고객이 있는 곳에 게시 — 프로젝트를 떠나지 않고 Partner Center를 통해 Microsoft Marketplace에 제출하거나, LOB 시나리오를 위해 Microsoft 365 관리 센터에 제출합니다.
- 제출 전에 대상 지정 — 출시한 뒤 포털에서 타깃팅 규칙을 발견하는 대신, 앞단에서 대상을 선택합니다.
- 단일 진실 공급원 — 패키지가 제출 메타데이터를 구동하므로, 여러 시스템에 같은 데이터를 다시 입력하지 않습니다.
그리고 출시는 끝이 아니라 시작입니다. wiqd agent monitor가 Work IQ에서 사용량·상태·도입 텔레메트리를 터미널로 가져옵니다. 무엇이 작동하는지 보고, 실제 사용 데이터를 다시 평가에 반영하고, 재게시하고, 곡선이 움직이는 것을 지켜봅니다. 개발하던 환경을 떠나지 않고서 말입니다.
Work IQ와의 관계
이름 자체가 관계를 말해 줍니다. WIQD는 Work IQ Developer Tools이며, 연결은 양방향입니다.
한 방향: 프로덕션 에이전트 인텔리전스를 구동하는 동일한 Work IQ 플랫폼 위에 세워졌습니다. 에이전트가 권한 인지형 거버넌스(permission-aware governance)와 함께 조직 맥락을 추론하게 해 주는 레이어이며, 새로운 Work IQ API가 에이전트에 인텔리전스·속도·효율·확장성·보안을 기본 제공합니다.
다른 방향: 이 플랫폼이 풍부해지는 방식이기도 합니다. WIQD를 통해 출시하는 모든 플러그인은 또 하나의 특화되고 잘 범위 지정된 맥락 소스가 됩니다.
청구 시스템에 대해 추측하는 모델보다, 그 시스템을 실제로 아는 청구 에이전트가 더 강합니다.
수명 주기의 장애물을 걷어내면 개발자가 더 많은 특화 에이전트를 출시하고, 더 많은 에이전트가 Work IQ를 풍부하게 만들며, 그 위에 세워지는 다른 모든 에이전트에게 더 넓고 근거 있는 맥락을 제공합니다. 이 순환 구조가 진짜 목표입니다.
시작하기
개발자 미리 보기가 지금 열려 있습니다. 전제 조건은 다음과 같습니다.
- Node.js
- Copilot 라이선스가 있는 Microsoft 365 테넌트(프로비저닝 대상)
피드백 보내기
이것은 개발자 미리 보기이며, GA로 가는 길을 사용자 목소리가 결정합니다. 피드백 경로도 도구 안에 내장되어 있습니다.
# 선호하는 에이전틱 환경에서
> Work IQ Dev Tools에 대한 피드백을 남기고 싶어...
# 또는 CLI로
wiqd feedback
# 모든 피드백은 공개 백로그(https://aka.ms/wiqd)로 바로 등록됩니다
한국 개발자를 위한 체크포인트
- 미리 보기 단계임을 감안하세요. 게시 경로 중 Partner Center를 통한 Microsoft 365 스토어 제출은 “곧 제공” 상태입니다. 사내 LOB 시나리오(Microsoft 365 관리 센터 게시)부터 검증하는 편이 현실적입니다.
- 테넌트 준비가 전제 조건입니다. 프로비저닝할 Copilot 라이선스 보유 M365 테넌트가 필요하므로, 개발용 테넌트 확보를 먼저 확인하시기 바랍니다.
--json과 안정적 종료 코드는 CI/CD 설계의 핵심입니다. 국내 기업의 내부 배포 파이프라인(Azure DevOps, GitHub Actions 등)에 그대로 얹을 수 있는 구조이므로, 초기부터 파이프라인 통합을 염두에 두고 설계하시면 좋습니다.- 평가(eval)를 처음부터 넣으세요. 표준 YAML로 생성되므로 버전 관리가 가능합니다. 국내 조직에서 흔히 문제가 되는 “에이전트 품질을 어떻게 증명하느냐”에 대한 객관적 근거를 만들 수 있습니다.
- 플러그인 단위 재사용 설계를 권장합니다. 부서별로 비슷한 커넥터를 반복 개발하는 대신, 공유 레지스트리에 한 번 게시하고 여러 에이전트에 조합하는 방식이 장기적으로 유지보수 비용을 크게 줄입니다.
마무리
WIQD는 “새로운 CLI 하나”가 아닙니다. Microsoft 365 Copilot 확장 개발의 파편화된 수명 주기를 하나의 계약으로 통일하고, 그 흐름을 사람과 에이전트가 똑같이 실행할 수 있게 만든 시도입니다.
Defy limits. Build wicked things. — The Work IQ Dev Tools team
Copilot 확장 개발을 하고 계시거나 검토 중이시라면, 미리 보기 기간에 실제 에이전트를 하나 만들어 보고 거친 부분을 피드백하는 것이 GA 품질에 기여하는 가장 빠른 길입니다.
출처: Announcing the preview of the Work IQ Developer Tools (Microsoft 365 Developer Blog)
자세한 내용은 원문 참조.