바뀌었습니다
Copilot Studio를 오랜만에 열어본 분이라면 낯선 단어를 마주쳤을 겁니다. 하네스(harness). 게다가 그중 하나는 이름이 GitHub Copilot 하네스입니다. Power Platform 이야기를 하는 줄 알았는데 왜 갑자기 GitHub일까요. 이번 호에서는 이 이름 변경이 무엇을 의미하는지, 그리고 여러분이 다음 에이전트를 만들 때 무엇을 골라야 하는지를 정리합니다.
1 · 무엇이 바뀌었나 — '경험'에서 '하네스'로
그동안 Copilot Studio에는 두 갈래 길이 있었습니다. 홈페이지의 토글로 켜고 끄던 새 경험(New experience)과 클래식 경험(Classic experience)입니다. 이름만 놓고 보면 UI 개편처럼 들립니다. 새 화면과 옛 화면, 취향껏 고르라는 이야기처럼요.
그런데 실제로 두 경험은 화면만 다른 것이 아니었습니다. 요청을 해석하는 방식, 도구를 부르는 방식, 실패했을 때 대응하는 방식, 심지어 과금 방식까지 달랐습니다. 엔진이 다른데 겉면 이름으로 불러왔던 셈입니다.
| 이전에 부르던 이름 | 지금의 정식 명칭 |
|---|---|
| 새 경험(New experience) | GitHub Copilot 하네스 |
| 클래식 경험(Classic experience) | 표준 하네스(Standard harness) |
| (M365 Copilot 확장) | Copilot 챗 하네스(Copilot chat harness) |
세 번째 줄이 중요합니다. Microsoft 365 Copilot을 확장하는 시나리오는 예전에도 있었지만, 이제는 별도의 하네스로 명확히 분리되어 세 갈래가 되었습니다. "두 개의 경험 중 하나를 고르는 문제"가 "세 개의 런타임 중 하나를 고르는 설계 결정"으로 승격된 것입니다.
2 · 그래서 하네스가 뭔가요
harness는 원래 마구(馬具)를 뜻합니다. 말과 마차를 연결하는 장치죠. 말이 아무리 좋아도 마구가 부실하면 마차는 원하는 곳으로 가지 않습니다. Microsoft가 이 단어를 고른 이유는 정확히 그 그림 때문입니다.
여러분이 에이전트를 설계하고, 선택한 모델이 추론과 생성을 담당한다. 하네스는 그 사이에 있는 런타임이다.
즉 하네스가 하는 일은 네 가지입니다.
여기서 자주 나오는 오해 하나를 짚고 갑니다. "최신 모델을 쓰니까 좋은 에이전트"가 아닙니다. 모델은 마구에 매인 말입니다. 같은 모델을 얹어도 하네스가 다르면 결과가 달라집니다. 표준 하네스에 최신 모델을 물려도 여러분이 정의한 토픽 밖으로는 나가지 않고, GitHub Copilot 하네스는 목표만 주면 스스로 단계를 쪼갭니다.
모델 선택은 성능 튜닝이고, 하네스 선택은 아키텍처 결정입니다. 순서가 뒤바뀌면 안 됩니다.
3 · 왜 하필 'GitHub Copilot' 하네스인가
가장 많이 받는 질문입니다. Power Platform 제품 안에 왜 GitHub 브랜드가 들어왔을까요. 이 작명은 마케팅이 아니라 엔진의 출처를 밝힌 것에 가깝습니다. 문서가 설명하는 이 하네스의 구성 요소를 나열해 보면 답이 보입니다.
이 목록을 개발자에게 보여주면 곧바로 알아봅니다. GitHub Copilot CLI와 Copilot 클라우드 에이전트가 이미 쓰고 있는 개념들과 정확히 겹치기 때문입니다. 스킬, 메모리, 샌드박스, 도구 오케스트레이션, 계획→실행→복구 루프는 코딩 에이전트 세계에서 수년간 다듬어진 패턴입니다.
개발자 영역에서 검증된 에이전트 런타임을, 코드를 쓰지 않는 비즈니스 메이커의 로우코드 화면 위로 그대로 끌어올렸다. (이하 필자 해석)
이름을 "고급 하네스"나 "프리미엄 하네스"로 붙였다면 그저 등급처럼 보였을 겁니다. GitHub Copilot이라는 이름을 붙였다는 건 "이건 개발자용 에이전트와 같은 엔진이다"라는 기술적 선언입니다. 그리고 뒤에서 볼 과금 방식까지 GitHub 쪽 방식(Copilot Credits)을 따라갑니다. 이름과 실체가 함께 움직인 셈입니다.
4 · 세 가지 하네스, 세 가지 성격
GitHub Copilot 하네스 — 판단하는 동료
가장 강력한 선택지입니다. 고정된 스크립트를 따르는 대신 목표를 받아 스스로 계획을 세웁니다. 커넥터, 지식, MCP, 연결된 에이전트를 오가며 필요한 도구를 고르고, 중간에 단계가 실패하거나 요청이 바뀌면 경로를 수정합니다.
차별점 중 실무에서 가장 크게 체감되는 것은 파일 처리입니다. Word, Excel, PowerPoint, PDF를 네이티브로 만들고 편집하고 그 내용을 근거로 추론합니다. 문서가 곧 업무인 조직에서는 이 한 줄이 도입 여부를 가르기도 합니다.
표준 하네스 — 약속대로 움직이는 창구
예측 가능성이 무기입니다. 여러분이 토픽, 프롬프트, 분기를 정의하면 그대로 동작합니다. 같은 질문에 같은 답이 나옵니다. 기존 프롬프트 라이브러리와 사내 지식을 그대로 활용할 수 있고, 지금까지 만들어 둔 자산이 여기 쌓여 있습니다.
"AI가 알아서 판단하는 게 늘 좋은 것 아닌가요?"라는 질문에 대한 답이 여기 있습니다. 규정 안내, 승인 조건, 요금 계산처럼 답이 흔들리면 안 되는 영역에서는 창의성이 리스크입니다. 자율적 추론이 필요 없는 자리에 자율성을 넣으면 관리 비용만 늘어납니다.
Copilot 챗 하네스 — 이미 있는 자리로 답을 배달
목표가 다릅니다. 새 채널을 만드는 게 아니라, 직원이 이미 매일 쓰는 Microsoft 365 Copilot Chat 안으로 사내 지식을 연결합니다. 직원 입장에서는 별도 앱을 열 이유가 없습니다. 늘 쓰던 창에서 사내 문서에 근거한 답이 나옵니다.
대신 성격이 분명합니다. 현재의 챗 모델 위에서 동작하고, 게시 대상은 사내 팀으로 한정됩니다. 파일 생성이나 복잡한 오케스트레이션은 이 하네스의 목표가 아닙니다.
한 장 비교표
| 고려 항목 | GitHub Copilot 하네스 | 표준 하네스 | Copilot 챗 하네스 |
|---|---|---|---|
| 가장 잘 맞는 곳 | 복잡한 다단계 업무 프로세스 | 규칙 기반 에이전트 · 정형 대화 | 사내 지식으로 M365 Copilot Chat 확장 |
| 동작 방식 | 목표를 스스로 단계로 쪼개 추론 | 정의한 토픽과 규칙을 따름 | 사내 지식을 M365 Copilot Chat에 연결 |
| 문제 발생 시 | 재시도 · 대체 경로 자동 탐색 | 만들어 둔 경로대로 | 해당 없음 |
| 파일 작업 | Word · Excel · PPT · PDF 생성/편집/추론 | 해당 없음 | 해당 없음 |
| 스킬 · 메모리 | 지원 | 해당 없음 | 해당 없음 |
| 게시 대상 | 사내 + 외부 고객 | 사내 + 외부 고객 | 사내 전용 |
| 과금 | Copilot Credits (사용량 기반) | Copilot Studio 라이선스 · 용량 | 사용량 기반 또는 M365 Copilot USL에 포함 |
5 · 그럼 어떤 하네스를 골라야 하나
세 문장으로 줄이면 이렇습니다.
실무 판단 순서
| 순서 | 질문 | 예 | 아니오 |
|---|---|---|---|
| Q1 | 직원이 이미 쓰는 M365 Copilot Chat 안에서 답만 주면 되는가? | Copilot 챗 하네스 | ↓ Q2로 |
| Q2 | 업무 절차를 내가 전부 그릴 수 있는가? (경로가 유한하고 명확) | ↓ Q3으로 | ↓ Q4로 |
| Q3 | 답이 항상 똑같아야 하는가? | 표준 하네스 | ↓ Q4로 |
| Q4 | 문서 생성·편집, 여러 도구 연계, 실패 복구가 필요한가? | GitHub Copilot 하네스 | 표준 하네스 |
판단을 도와주는 세 가지 질문
6 · 에이전트만 있는 게 아닙니다 — 워크플로우까지 넣은 선택지
여기서 한 단계 더 들어갑니다. Copilot Studio에서 만들 수 있는 것은 에이전트만이 아니고, 빌딩 블록마다 탈 수 있는 하네스가 정해져 있습니다. 이 대응 관계를 모르면 "왜 이 메뉴에서는 저 기능이 안 보이지?"에서 막힙니다.
| 빌딩 블록 | 무엇인가 | 어떤 하네스에서 도나 |
|---|---|---|
| 에이전트(Agents) | 대화하고 판단해 작업을 수행 | 세 하네스 모두 |
| 워크플로우(Workflows) | 드래그앤드롭 캔버스로 만드는 자동화. 단계마다 추론·행동 가능 | GitHub Copilot 하네스 전용 |
| 에이전트 플로우(Agent flows) | 기존 방식의 플로우. Power Automate와 유사한 경험 | 표준 하네스 |
에이전트와 워크플로우, 무엇이 다른가
같은 하네스 위에 있어도 성격이 반대입니다.
워크플로우가 절차를 붙잡고, 판단이 필요한 지점에서만 에이전트를 호출한다.
예를 들어 매월 정산 프로세스라면 — 일정 트리거 → 데이터 수집(워크플로우) → 예외 건 판단(에이전트 호출) → 승인 요청(휴먼인더루프) → 보고서 생성 → 발송. 절차의 뼈대는 예측 가능하게 두고, 사람의 판단이 필요했던 지점만 에이전트에게 넘기는 구조입니다. 워크플로우는 에이전트를 호출할 수 있고, 반대로 에이전트가 플로우를 호출할 때 트리거를 쓰면 워크플로우를 에이전트의 도구로 붙일 수도 있습니다.
확장된 의사결정 지도
| 상황 | 권장 조합 |
|---|---|
| 절차가 고정, 판단 불필요 | 표준 하네스 + 에이전트 플로우 |
| 절차가 고정, 일부 단계만 판단 필요 | GitHub Copilot 하네스 + 워크플로우(에이전트 호출 노드 포함) |
| 절차가 유동적, 목표만 명확 | GitHub Copilot 하네스 + 에이전트 |
| 대화가 중심, 답변 일관성이 최우선 | 표준 하네스 + 에이전트 |
| 사내 지식 질의응답, 별도 채널 불필요 | Copilot 챗 하네스 + 에이전트 |
7 · 시작하기 전에 반드시 알아야 할 세 가지
① 하네스는 나중에 바꿀 수 없습니다
⚠️ GitHub Copilot 하네스로 만든 에이전트는 표준 하네스로 옮길 수 없고, 그 반대도 불가능합니다. 하네스는 생성 시점에 정하는 결정이며, 되돌리려면 다시 만들어야 합니다.
그래서 PoC 단계에서 "일단 익숙한 걸로 만들고 나중에 옮기죠"라는 계획은 성립하지 않습니다. 파일럿을 시작하기 전에 목적지를 정해야 합니다.
② 만드는 방식 자체가 다릅니다
표준 하네스에서는 토픽을 만들고 분기를 그렸습니다. GitHub Copilot 하네스는 자연어 우선(natural-language-first)입니다. 에이전트를 말로 설명하면 시스템이 내부 구성을 생성합니다. 화면도 단일 서피스로 통합되어 Build / Preview / Evaluate / Monitor 네 탭으로 정리됩니다.
또 하나. 표준 하네스에서는 오케스트레이션 동작을 설정할 수 있었지만, GitHub Copilot 하네스는 향상된 오케스트레이션이 모든 에이전트에 기본 적용되며 선택 항목이 아닙니다. 조정 손잡이가 줄어든 대신 기본값이 올라간 셈입니다.
③ 과금 모델이 갈라집니다
| 하네스 | 과금 |
|---|---|
| GitHub Copilot 하네스 (에이전트 · 워크플로우) | Copilot Credits — 사용량 기반 |
| 표준 하네스 (에이전트 · 에이전트 플로우) | Copilot Studio 라이선스 · 용량 모델 |
| Copilot 챗 하네스 | 사용량 기반 또는 M365 Copilot 사용자 구독에 포함 |
주의할 점이 하나 더 있습니다. 사용량 기반 과금은 운영뿐 아니라 빌드·테스트·평가에도 적용됩니다. 개발 단계에서도 크레딧이 소모된다는 뜻이므로, PoC 예산을 잡을 때 이 항목을 빼놓으면 안 됩니다.
워크플로우 쪽도 확인이 필요합니다. 워크플로우는 실행하는 액션마다 용량을 소모하고, 환경의 선불 용량을 모두 쓰면 새 실행이 차단됩니다(이미 실행 중인 건은 정상 완료). Power Platform 관리 센터에서 플로우별 액션 사용량을 주기적으로 확인하고, 필요하면 종량제 과금을 켜두는 편이 안전합니다.
8 · 한 줄로 정리하면
이번 변화의 본질은 메뉴 개편이 아닙니다.
"만들기 전에 골라야 하는 것은 모델이 아니라 하네스입니다."
GitHub Copilot이라는 이름이 Copilot Studio 안으로 들어온 것은, 개발자가 쓰던 에이전트 엔진과 비즈니스 메이커가 쓰던 로우코드 도구 사이의 경계가 옅어지고 있다는 신호이기도 합니다. 다음 에이전트를 만들 때 첫 화면에서 잠깐 멈춰 서서 물어보시길 권합니다 — 이 일은 절차인가, 판단인가.