Knowledge Spine: 한 에이전트가 받은 교정을 모든 에이전트가 쓰게 하는 공유 지식 체계

Microsoft와 Keystone의 연구는 에이전트 경쟁력이 모델보다 회사가 일하며 쌓은 교정, 테스트, 교훈에서 나온다고 봅니다. 그것을 한곳에 모아 모든 에이전트가 함께 쓰게 하는 장치가 knowledge spine입니다. 따라 하려면 팀 하나를 골라 고친 내용을 테스트로 바꾸는 규칙과 지식 담당자부터 정해야 합니다.

요약

Microsoft Copilot의 최고마케팅책임자 Jared Spataro가 2026년 10월 27일 Microsoft Copilot 블로그에 올린 글입니다. Microsoft와 Keystone이 함께 한 연구를 소개합니다. 바탕 논문은 같은 달 나온 Harvard Business School 워킹 페이퍼(Sarkar 외, No. 27-038)입니다. 연구진은 먼저 AI를 깊게 쓰는 조직 29곳의 리더를 인터뷰했습니다. AI 네이티브 스타트업 18곳과 기존 대기업 11곳입니다. 여기서 만든 설문으로 미국 직원 1,000명 이상인 미국 기업 202곳을 2026년 6~9월에 평가했습니다. 업종은 금융 42곳, 제조 41곳, 소프트웨어 30곳, 헬스케어·생명과학 29곳, 유통 21곳, 기타 39곳입니다. 점수는 에이전트를 만들고, 돌리고, 조율하고, 점검하고, 거기서 배우는 관행을 얼마나 갖췄는지로 매겼습니다. 그다음 상장사 100여 곳의 2022~2025년 재무 변화를 이 점수와 맞대어 봤습니다.

점수 상위 사분위 기업은 하위 사분위보다 영업이익률이 약 5.4%p, ROA(총자산이익률)가 약 2.3%p 더 올랐습니다. 규모와 업종을 보정한 값이고 영업이익률은 97곳, ROA는 113곳을 비교했습니다. 사분위별 영업이익률 변화를 하위부터 늘어놓으면 +0.4, -0.3, +5.1, +5.8%p입니다. 한 번 꺼졌다가 오르는 J-curve(투자 초기에 성과가 잠시 떨어졌다가 나중에 오르는 곡선) 모양이지만 통계 검정으로 이 모양이 확인되지는 않았습니다. 연구진은 조직을 다시 짜는 동안 성과가 늦게 나타날 수 있다고 봅니다. 조율 체계를 갖추기 전에 에이전트부터 빠르게 깔면 이런 지연이 생길 수 있다는 해석입니다. 저자는 이 결과가 상관관계이며 인과가 아니라고 밝힙니다. 재무 기간이 지금 쓰이는 에이전트 시스템 대부분보다 앞서므로 에이전트가 이익률을 올렸다고 말할 수 없다는 점도 적었습니다. 표본은 모두 이미 AI를 쓰는 기업이라 경제 전체를 대표하지 않습니다. 이 글은 벤더인 Microsoft가 낸 글이고 knowledge spine을 자사 enterprise intelligence layer인 Microsoft IQ와 연결해 설명합니다. 아래에서 knowledge spine, 네 단계, 증거로 넓히는 권한을 차례로 풀고 첫 팀에서 돌려 볼 데이터 구조와 일정을 덧붙였습니다.

핵심 메커니즘

Knowledge Spine: 맥락과 교정을 한곳에 쌓아 모든 에이전트가 쓰는 시스템

Knowledge spine은 에이전트가 일할 때 기대는 맥락을 저장하고 고쳐 가는 공유 시스템입니다. 맥락만 담지 않고 에이전트 작업에서 나온 교정, 테스트, 교훈도 함께 담습니다. 핵심은 한 에이전트에 한 교정이 다른 에이전트에게도 돌아간다는 점입니다. 저자는 회사만의 몫이 “the corrections, tests, and lessons from its own work”라고 봅니다. 모델은 누구나 살 수 있지만 자기 업무에서 나온 교정 기록은 그 회사에만 있다는 뜻입니다. 만드는 관행은 넷입니다. 채팅, 기간계(systems of record), 사내 문서처럼 흩어진 곳에서 업무 맥락을 모아 한곳에 둡니다. 고친 내용을 정보로 다뤄 다음 버전의 테스트 케이스로 바꿉니다. 모은 정보를 합쳐 에이전트가 그 종류의 일을 처리하는 방식 자체를 바꿉니다. 마지막으로 출처의 신뢰도, 정보끼리의 충돌, 낡은 정보 교체를 책임질 담당자를 정합니다. 저자는 팀 하나에도, 회사 전체에도 같은 관행을 쓸 수 있다고 합니다. 연구 표본에서 이 기반을 갖춘 기업은 3%뿐이었습니다. 같은 종류의 일을 하는 에이전트가 여럿이거나 같은 실수가 반복되는 업무에서 효과가 큽니다. 에이전트가 하나뿐이고 교정이 드문 실험 단계라면 담당자 지정과 교정 기록부터 시작해도 됩니다.

가상 예시: 구매팀의 계약 검토 에이전트가 자동 단가 인상 조항을 놓쳤고 담당자가 이를 고쳤습니다. 이 교정은 spine에 규칙으로 들어가고 테스트 케이스가 됩니다. 다음 날 견적 비교 에이전트도 같은 조항을 확인합니다.

Agentic Operating Model: 사람이 조율하던 에이전트를 시스템이 조율하는 네 단계

연구진은 기업을 네 단계로 나눴습니다. 1단계는 AI 파일럿이 여기저기 흩어진 상태입니다. 채팅 말고는 배포가 거의 없고 실제 업무와 이어지지 않아 효과가 작습니다. 2단계에서는 에이전트가 여러 부서의 특정 업무를 실제로 맡습니다. 다만 관리·조율 체계가 없어 팀과 위원회가 투자 우선순위를 정하고 결과를 점검합니다. 사람이 에이전트를 조율하는 셈이고 이 방식은 규모를 키우기 어렵습니다. 저자가 전환점이라고 부르는 3단계에서는 사람이 아니라 시스템이 에이전트를 조율합니다. 공유 지식 기반이나 촘촘한 모니터링을 쓰고 비즈니스 성과가 에이전트의 일을 이끕니다. 대개 한 부서나 몇 개 업무에서 먼저 이뤄집니다. 4단계에서는 orchestration(에이전트 조율 계층), 거버넌스, knowledge spine이 한데 모입니다. 에이전트의 교훈을 공유 지식과 테스트에 다시 넣는 곳이 많습니다. 방향은 회사 전체가 하나의 agentic operating model(에이전트 중심 운영 모델)로 가는 것입니다. 통계 분석에서는 다섯 개 집단이 나왔고 연구진은 이를 셋째 단계에 두 가지 형태가 있는 네 단계로 해석했습니다. 단계는 한 시점의 모습이며 기업이 단계를 차례로 올라간다는 것은 가설입니다.

Evidence-Earned Autonomy: golden dataset과 기록으로 권한을 넓히고 좁히기

네 관행 밑에 깔린 공통 원칙은 observability(에이전트가 무엇을 왜 했는지 들여다볼 수 있는 상태)입니다. 앞선 기업은 출시 전에 기대 결과를 정해 둔 테스트 케이스 묶음을 만들고 여기에 과거 오류도 넣습니다. 이 묶음을 golden dataset이라고 부릅니다. 단계가 높은 기업은 운영 중 상세한 telemetry(실행 기록 데이터)를 남깁니다. 점수 상위 사분위의 76%가 에이전트 활동 기록을 검색할 수 있다고 답했고 하위 사분위는 8%였습니다. 이런 기록이 있어야 자율을 증거로 줄 수 있습니다. 에이전트가 잘하면 권한을 넓히고 틀리면 좁힙니다. 처음부터 권한을 크게 주거나 막연히 막아 두는 대신 성과 기록을 보고 조절하는 방식입니다. 실수 한 번의 비용이 큰 업무일수록 이 원칙이 맞습니다. 기록을 남길 수 없는 업무라면 권한을 넓힐 근거도 없으므로 사람 승인 단계를 유지합니다.

통념과 다른 주장

연구가 보여 준 숫자

원문은 개별 회사 사례 대신 표본 집계를 제시합니다. 기업 이름은 원문에서 밝히지 않았습니다.

대상	상황	한 일	결과	연결
4단계 기업	조율·거버넌스·spine이 모인 단계	조율 계층, 공유 맥락, 담당자, 평가셋을 갖춤	담당자 90%, orchestration layer 86%, shared context layer 76%, 평가셋 확장 66%, 교훈 자동 반영 33%	Agentic Operating Model
점수 상위·하위 사분위	상장사 2022~2025년 재무 비교	규모·업종 보정, Capital IQ 자료	영업이익률 +5.8 대 +0.4%p, ROA +2.3 대 0.0%p	Knowledge Spine (상관관계)
표본 202곳	AI 운영을 잇는 네 관행 보유 여부	에이전트 레지스트리 자동 갱신, 운영 신호로 도는 평가, 과거 오류 패턴 재사용, 작업별 모델 선택	네 가지를 모두 갖춘 곳 6곳(3%)	Evidence-Earned Autonomy

기술 디테일: 첫 spine을 직접 만든다면

아래 필드, 설정값, 기준은 실제로 돌릴 때 필요한 것을 새로 적은 가상 예시이며 원문이나 Microsoft가 밝힌 구현이 아닙니다.

spine 기록 하나를 정의하려면(Knowledge Spine) 맥락, 규칙, 교정, 교훈을 같은 틀에 넣습니다. 기록마다 출처와 담당자와 유효기간을 붙여야 담당자가 낡은 정보를 찾아 바꿀 수 있습니다. 에이전트는 작업을 시작할 때 applies_to 작업 유형으로 기록을 걸러 받아 프롬프트에 넣습니다. 저장은 문서 저장소에 메타데이터 필터와 벡터 검색을 함께 붙이는 구성이 무난합니다. 같은 key에 값이 다른 기록이 둘 이상 들어오면 자동으로 덮어쓰지 않고 담당자 확인 대기열로 보냅니다.

{
  "spine_item_id": "SP-PUR-0142",
  "kind": "correction_rule",
  "key": "contract.auto_price_escalation",
  "content": "자동 단가 인상 조항이 있으면 인상 한도와 통지 기간을 함께 표시",
  "applies_to": ["contract_review", "quote_compare"],
  "source": {"system": "구매 계약 검토 로그", "ref": "COR-2026-1103-07"},
  "owner": "구매기획팀 계약 담당",
  "valid_from": "2026-11-03",
  "review_by": "2027-05-03",
  "supersedes": null,
  "status": "active"
}

교정을 테스트로 바꾸려면(교정을 테스트로) 담당자가 에이전트 결과를 고칠 때마다 원래 입력, 에이전트 출력, 고친 출력, 원인 유형을 남깁니다. 원인 유형은 missing_rule, stale_fact, wrong_source, format 정도로 시작합니다. 이 기록에서 기대 결과를 뽑아 golden dataset에 테스트 케이스로 넣습니다. 새 버전을 낼 때마다 전체 케이스를 temperature 0으로 3회씩 돌리고 3회 모두 통과한 비율을 봅니다. 기존에 통과하던 케이스가 하나라도 떨어지면 출시를 멈춥니다. 판정은 정답 문자열 비교가 되면 코드로 합니다. 서술형이면 기준표를 준 별도 모델로 채점한 뒤 주 1회 표본 20건을 사람이 다시 봅니다.

{
  "test_case_id": "TC-PUR-0388",
  "origin": "production_correction",
  "correction_id": "COR-2026-1103-07",
  "input_ref": "contract_7781.pdf",
  "expected": {"escalation_clause": true, "cap_pct": 5, "notice_days": 30},
  "failure_pattern": "missing_rule",
  "agents": ["contract_review", "quote_compare"],
  "added_at": "2026-11-03"
}

평가를 운영 신호로 돌리려면(4단계의 평가셋 확장) 정해진 날짜가 아니라 사건이 생길 때 평가를 돌립니다. 작업 유형별 교정 비율이 지난 4주 평균보다 2배를 넘을 때, 새 원인 유형이 나왔을 때, spine 기록이 바뀌었을 때가 시작 신호입니다. 이를 위해 에이전트 레지스트리(registry)에 에이전트마다 작업 유형, 쓰는 모델, 읽는 spine 기록, 권한 수준, 최근 평가 결과를 자동으로 적습니다. 작업별 모델 선택도 여기서 관리합니다. 분류처럼 단순한 일은 작은 모델을, 계약 해석처럼 판단이 필요한 일은 큰 모델을 붙이고 같은 golden dataset으로 비교해 정합니다.

권한을 증거로 넓히려면(Evidence-Earned Autonomy) 권한을 세 수준으로 나눕니다. L0은 제안만 합니다. L1은 사람 승인 뒤 실행하고 L2는 실행한 뒤 사람이 표본을 검토합니다. 올리는 기준 예시는 직전 200건에서 승인 없이 통과한 비율 97% 이상, 중대 오류 0건입니다. 중대 오류가 한 건이라도 나오면 바로 한 단계 내립니다. 기준과 변경 이력은 레지스트리에 남깁니다.

결과당 원가를 재려면(통념과 다른 주장 2) 좋은 결과 하나의 원가를 아래처럼 셉니다. 사람 검토 시간을 빼면 원가가 실제보다 낮게 보입니다.

결과당 원가 = (모델 호출 비용 + 사람 검토 시간 × 시간당 인건비) ÷ 수정 없이 받아들인 결과 수

막히는 경우	증상	대응
교정이 채팅에만 남음	spine에 들어올 기록이 없음	결과 화면에 수정 버튼과 원인 유형 선택을 붙여 수정과 기록을 한 동작으로
spine 기록끼리 충돌	에이전트마다 다른 답	같은 key 충돌은 담당자 대기열, 처리 전까지 이전 기록 유지
golden dataset이 커지지 않음	같은 실수 재발	교정 1건당 테스트 1건 생성을 출시 조건으로
활동 기록을 못 찾음	오류 원인 추적에 며칠 걸림	실행마다 입력, 읽은 spine 기록, 출력, 모델 버전을 한 레코드로 저장
비용이 토큰만 보임	검토 인건비가 빠짐	검토 시간을 작업 레코드에 함께 기록

현업 실행 디테일: 누가, 언제, 무엇을

아래 역할, 일정, 판정 기준은 원문 권고(팀 하나나 이어진 몇 개 업무에서 먼저 증명하고 넓힌다)를 따라 새로 짠 가상 예시입니다.

역할	맡는 일
경영진 스폰서(COO·CIO)	첫 팀 선정, 8주 뒤 확대 판정
업무 팀장	대상 업무와 에이전트 범위 확정, 교정 규칙 운영
지식 담당자(spine owner)	출처 신뢰도 판단, 충돌 처리, 낡은 기록 교체
에이전트 엔지니어	spine 저장소·레지스트리·평가 파이프라인 구축
품질·평가 담당	golden dataset 관리, 주간 표본 재검토
재무 담당	결과당 원가 기준선과 변화 측정

준비물. 대상 업무에서 에이전트가 이미 처리한 최근 4주 결과와 사람이 고친 기록, 업무 규칙이 흩어져 있는 문서 목록, 담당 시스템 접근 권한, 사람 검토에 쓰는 시간 기록이 필요합니다. 에이전트가 둘 이상 같은 종류의 정보를 쓰는 업무를 고르면 교정이 다른 에이전트로 넘어가는지 확인할 수 있습니다.

기간	할 일	산출물
1~2주	교정 기록 방식 정하기, 기준선 측정	원인 유형 목록, 교정 비율·결과당 원가 기준선
3~4주	spine 기록 틀과 담당자 지정, 기존 규칙 이관	spine 기록 50~100건, 담당자 명단
5~6주	교정을 테스트로 바꾸기, 평가 자동 실행	golden dataset 첫판, 레지스트리
7~8주	운영 비교, 확대 여부 판정	판정 보고서

현업에 물을 것. 원문이 제안한 자가 점검 질문 세 가지가 출발점입니다. 하나라도 “아니오”라면 거기서 시작합니다.

1. 한 에이전트에 한 교정이 다른 에이전트에게도 전달되나요?
2. 실패가 생길 때마다 좋아지는 공통 품질 기준이 있나요?
3. 에이전트가 기대는 지식을 책임지는 사람이 있나요?

여기에 실제로 돌릴 때 필요한 질문을 더합니다.

4. 지금 에이전트 결과를 고치면 그 기록은 어디에 남나요?
5. 같은 실수가 지난달 몇 번 반복됐나요?
6. 사람 검토에 주당 몇 시간을 쓰나요?

진행 판정 기준(예시). 7~8주 운영에서 다음을 채우면 이어진 업무로 넓힙니다. 같은 원인의 교정이 기준선보다 30% 이상 줄어야 합니다. 교정 1건마다 테스트 케이스가 만들어진 비율이 90% 이상이어야 합니다. 결과당 원가는 사람 검토 시간을 포함해 기준선보다 낮아야 합니다. 하나라도 못 채우면 원인을 찾아 4주를 더 봅니다.

AX 적용 제언. 부서마다 에이전트가 생겼지만 조율은 위원회와 담당자가 맡는 2단계 회사라면 순서가 중요합니다. 이때 전사 지식 플랫폼부터 사면 연구진이 J-curve의 원인으로 짚은 상황, 곧 조율 체계보다 에이전트가 앞서 가는 상태가 이어집니다. 에이전트가 둘 이상 같은 정보를 쓰는 부서 하나(구매 계약, 고객 문의, 품질 이상 보고)를 골라 교정 기록과 담당자부터 세우는 편이 낫습니다. 경영 보고에는 토큰 비용 대신 결과당 원가와 교정 재발률을 올립니다. Microsoft IQ 같은 벤더 계층을 고를 때도 이 두 지표를 시범에서 먼저 재 보고 판단하면 벤더와 무관하게 쓸 수 있는 근거가 남습니다.

원문 사례

항목	내용
원문	Microsoft Copilot Blog, 2026.10.27, Jared Spataro(Microsoft Copilot CMO)
연구	Microsoft·Keystone 공동 연구. 바탕 논문 Sarkar, Abudurexiti, Beltinger, Daubenspeck, Iansiti(2026), HBS Working Paper No. 27-038
인터뷰	AI를 깊게 쓰는 조직 29곳(AI 네이티브 스타트업 18, 기존 대기업 11)
설문 표본	미국 직원 1,000명 이상 미국 기업 202곳, 2026년 6~9월. 금융 42, 제조 41, 소프트웨어 30, 헬스케어·생명과학 29, 유통 21, 기타 39
재무 비교	상장사 100여 곳 2022~2025년, 영업이익률 97곳·ROA 113곳, 규모·업종 보정, Capital IQ
결과	상위 사분위가 하위보다 영업이익률 약 5.4%p, ROA 약 2.3%p 더 개선. 사분위별 영업이익률 +0.4, -0.3, +5.1, +5.8%p
4단계 기업	담당자 90%, orchestration layer 86%, shared context layer 76%, 평가셋 확장 66%, 교훈 자동 반영 33%
기록	활동 기록 검색 가능 상위 사분위 76%, 하위 8%
보급	knowledge spine 기반을 갖춘 기업 3%. 각주 기준으로 AI 운영을 잇는 네 관행을 모두 갖춘 곳 202곳 중 6곳
비용	다수가 넓은 접근으로 시작, 약 절반이 토큰·지출 예산, 지출을 결과와 묶은 곳은 소수
저자 고지	초기 단계, 상관관계이며 인과 아님, 재무 기간이 현재 에이전트 시스템보다 앞섬, 표본은 AI 사용 기업이라 경제 전체 대표 아님, 단계 이동은 가설
출처 성격	벤더(Microsoft) 블로그, knowledge spine을 Microsoft IQ와 연결해 설명

핵심 개념

Frontier Firm

원문이 AI 활용에서 앞선 기업을 가리켜 쓰는 말입니다. 리더들이 이 개념을 어떻게 실천하고 무엇으로 재야 하는지 묻는다는 데서 글이 출발합니다.

orchestration layer

여러 에이전트에게 일을 나누고 순서를 정하고 결과를 모으는 조율 계층입니다.

shared context layer

에이전트들이 함께 읽는 업무 맥락 저장소입니다. knowledge spine의 바탕이 됩니다.

golden dataset

기대 결과를 정해 둔 테스트 케이스 묶음입니다. 과거 오류를 넣어 같은 실수가 다시 나오지 않는지 봅니다.

agent registry

회사 안에서 돌아가는 에이전트 목록과 각자의 역할, 모델, 권한, 평가 결과를 적어 둔 장부입니다.

J-curve

새 기술에 투자한 뒤 조직을 다시 짜는 동안 성과가 잠시 떨어졌다가 나중에 오르는 모양입니다.

Microsoft IQ

원문이 소개한 Microsoft의 enterprise intelligence layer입니다. 공유 지식을 한곳에서 고치면 모든 에이전트가 그것을 쓰게 한다고 설명합니다.

내 메모

TODO: 내 생각 추가

원문은 Microsoft Copilot Blog에 실린 Jared Spataro의 「The AI advantage your company can keep」(2026.10.27)입니다. Microsoft와 Keystone의 공동 연구와 Harvard Business School 워킹 페이퍼 「Organizing AI at Enterprise Scale: Agentic Operating Models and Firm Outcomes」(No. 27-038)를 소개하는 글입니다. 벤더가 낸 글이며 수치는 연구진이 밝힌 상관관계이며 저자도 인과가 아니라고 적었습니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 연구가 보여 준 숫자, 원문 사례 표는 원문 내용을 AX Review가 다시 정리했습니다. 기술·현업 실행 디테일, JSON 예시, 일정과 판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전체 내용과 논문 정보는 원문 페이지에서 볼 수 있습니다.