AI 거버넌스는 문서가 아니라 운영체계다

이 글은 SK텔레콤 AI Governance Report 2026의 내용을 요약하고, SW Architect·AI Architect로서 AI Agent 구축 사업과 Enterprise AI 도입을 지원하는 필자의 관점에서 실무적 의미를 분석한 글이다. 보고서의 사실과 필자의 해석을 구분해 기술했다.

원본 PDF: SKT_AI_Governance_Report.pdf
페이지별 세부 내용과 도표는 원문에서 확인할 수 있다.

먼저 결론: 거버넌스의 단위가 ‘모델’에서 ‘업무 수행 주체’로 이동한다

이 보고서를 한 문장으로 요약하면 다음과 같다.

AI 거버넌스는 원칙을 선언하는 일이 아니라, AI 서비스와 Agent의 식별·권한·데이터·실행·평가·종료를 하나의 운영 루프로 관리하는 일이다.

보고서는 개인정보 보호를 중심축으로 삼되, 고객 대상 AI 서비스와 내부 AI Agent를 서로 다른 통제 대상으로 구분한다. 특히 내부 Agent를 단순한 소프트웨어 기능이 아니라 식별되고, 책임자가 지정되며, 성과를 평가받고, 필요하면 중단·폐기되는 업무 수행 주체로 다룬다는 점이 인상적이다.

이 접근은 내가 최근 관심을 두고 있는 다음 네 가지 주제와 정확히 만난다.

AI Architect — 모델 선택보다 중요한 권한·컨텍스트·도구·검증 구조
AI Agent 구축 — 데모 이후 운영 단계에서 필요한 통제와 관찰 가능성
Enterprise AI 도입 — 도구 배포와 함께 가야 하는 구성원 교육·책임·변화관리
AI 기반 SW 개발 방법론 — 개발 속도를 넘어 승인, 증적, 운영, 종료까지 포함하는 SDLC

1. 보고서의 전체 구조

보고서는 다음 다섯 영역으로 구성된다.

영역	핵심 내용	실무적으로 남는 질문
AI 거버넌스 원칙	T.H.E. AI, 책임체계, 위험·기회 평가	원칙을 누가 어떤 의사결정에 적용하는가?
AI 서비스의 개인정보 보호	Privacy by Design, 외부 연계, 고객 권리	데이터 처리와 AI 기능을 설계 단계에서 어떻게 연결하는가?
내부 AI 활용과 관리	사용 가이드, Agent 사번, Agent OS, 평가	Agent를 누가 소유하고 어디까지 실행하게 할 것인가?
규제 대응과 대외 협력	법·정책 모니터링, 글로벌 기준 연계	규제 변화를 현장의 통제로 어떻게 번역하는가?
주요 활동과 향후 과제	인증, 사전 예방, 생애주기, 중장기 로드맵	거버넌스의 효과를 무엇으로 측정할 것인가?

보고서의 흐름은 원칙 → 책임 → 사전 검토 → 운영 통제 → 평가와 개선으로 이어진다. 정책 문서에 머물지 않고 실행 구조를 설명하려는 의도가 분명하다.

2. 가장 중요한 다섯 가지 포인트

2.1 개인정보 보호와 AI 거버넌스를 한 의사결정 체계로 묶었다

SK텔레콤은 CPO가 개인정보 보호와 AI 거버넌스를 함께 총괄하는 체계를 제시한다. 개인정보 처리의 적법성, 기술적 보호조치, AI의 투명성·안전성·이용자 통제권을 별도 심사로 흩어 놓지 않고 하나의 서비스 의사결정에 반영하려는 구조다(원문 p.8-9).

AI Architect 관점에서 이 구조가 중요한 이유는 AI 위험이 한 영역에만 머물지 않기 때문이다. 같은 기능이라도 데이터 출처, 외부 모델, 사용자의 역할, 자동화 수준에 따라 개인정보·보안·법무·윤리 위험이 동시에 달라진다. 따라서 검토 결과도 병렬 체크리스트가 아니라 통합된 아키텍처 결정으로 귀결되어야 한다.

2.2 위험뿐 아니라 기회도 평가한다

보고서는 신뢰성, 다양성과 포용, 결정의 투명성, 윤리적 책임성을 위험 평가 기준으로 두고, 연결을 통한 고객 편의와 인류의 복지 증진을 기회 평가 기준으로 둔다(원문 p.11).

이 점은 실무적으로 중요하다. 거버넌스가 금지와 승인만 다루면 현업은 이를 ‘속도를 늦추는 절차’로 인식한다. 반대로 기대 편익과 위험을 함께 기록하면 의사결정은 다음 질문으로 바뀐다.

이 위험을 감수할 만큼 가치가 있는가? 있다면 어떤 완화 조치 아래 허용할 것인가?

즉, 좋은 거버넌스는 위험을 0으로 만드는 장치가 아니라 가치 대비 위험을 설명 가능하게 선택하는 장치다.

2.3 Privacy by Design을 전 생애주기로 확장한다

보고서는 기획 단계부터 처리 목적·범위·근거를 확인하고, 개발·운영·변경·종료까지 개인정보 보호를 연결한다. 외부 모델, 클라우드, 라이브러리, 수탁사, 국외 이전, 역할별 데이터 접근도 검토 대상이다(원문 p.16-17).

여기서 핵심은 출시 전 한 번의 승인으로 끝내지 않는다는 것이다. 모델, 데이터, Tool, 처리 목적, 외부 사업자가 바뀌면 위험도 다시 평가해야 한다. AI 시스템은 운영 중 구성요소가 자주 변하므로, 변경 관리는 거버넌스의 부가 기능이 아니라 본체에 가깝다.

2.4 AI Agent에 ‘사번’과 Owner를 부여한다

가장 눈에 띄는 부분은 AI Agent 사번제도다. Agent의 역할과 수행 업무, 책임자, 소속, 권한, 운영 상태와 성과를 등록하고 관리한다. 기본 ID로 현황을 파악한 뒤 일정 기준을 충족한 Agent에 사번을 부여하며, 역할이나 업무 범위가 바뀌면 정보도 갱신한다(원문 p.25-26).

‘사번’이라는 표현이 흥미롭지만 본질은 이름이 아니다. 핵심은 다음 세 가지다.

Identity: 이 Agent는 무엇인가?
Accountability: 누가 이 Agent의 결과와 운영을 책임지는가?
Authority: 어떤 데이터와 Tool에 어디까지 접근할 수 있는가?

마이크로서비스에 서비스 카탈로그와 Owner가 필요하듯, Agent에도 Agent Registry와 명시적 소유권이 필요하다. 다만 Agent는 정해진 API만 실행하는 서비스보다 런타임 판단의 폭이 크므로, 자율성이 높아질수록 승인과 감독은 더 정교해야 한다.

2.5 Agent OS를 거버넌스의 실행 계층으로 둔다

Agent OS는 Agent의 모델·Tool 사용, 실행 단계, 토큰과 호출량, 비용, 설정·기능 변경, 주요 실행 이력을 통합 관리하고 이상 시 실행을 중단하는 운영 기반으로 설명된다(원문 p.27).

이것은 내가 정리해 온 Harness Engineering과 맞닿아 있다. 정책만으로 Agent를 안전하게 만들 수는 없다. 정책이 실제로 작동하려면 런타임에서 다음이 가능해야 한다.

정책과 의도
    ↓
Agent Identity + Owner
    ↓
최소 권한 + 데이터 접근통제
    ↓
모델·Tool 실행 기록 + 비용 추적
    ↓
평가·승인·중단·복구
    ↓
개선 또는 폐기

즉, Agent OS는 단순한 개발 플랫폼이 아니라 Agent 거버넌스를 실행 가능한 통제로 바꾸는 Control Plane으로 읽을 수 있다.

3. 내 관심사와 담당업무 관점에서 읽은 실무적 의미

3.1 AI Architect: 아키텍처 산출물의 범위가 넓어진다

전통적인 AI 아키텍처 문서는 모델, 데이터 파이프라인, API, 인프라를 중심으로 작성한다. Agentic AI에서는 여기에 다음 산출물이 추가되어야 한다.

아키텍처 영역	반드시 답해야 할 질문	권장 산출물
목적과 책임	이 Agent가 맡는 업무와 책임자는 누구인가?	Agent Card, Owner/RACI
자율성	제안·승인·실행 중 어디까지 스스로 하는가?	Autonomy Level, Human-in-the-loop 정책
데이터	어떤 데이터에 어떤 근거로 접근하는가?	Data Flow, 데이터 분류·접근 매트릭스
Tool 권한	어떤 API·MCP·업무 시스템을 호출하는가?	Tool Allowlist, 최소 권한 정책
검증	성공과 실패를 무엇으로 판정하는가?	Eval Set, Acceptance Criteria, 정책 테스트
운영	무엇을 기록하고 언제 중단·복구하는가?	Trace Schema, Alert, Kill Switch, Rollback Plan
변경·종료	모델·프롬프트·Tool 변경과 폐기를 어떻게 관리하는가?	변경 영향평가, 재승인 조건, Retirement Plan

앞으로 AI Architect의 핵심 산출물은 ‘구성도’ 한 장이 아니라 자율성을 안전하게 운영하는 계약의 묶음이 될 것이다.

3.2 AI Agent 사업 제안·수행: 데모보다 운영 수용 기준이 먼저다

Agent 사업 제안에서는 기능 목록과 예상 생산성이 강조되기 쉽다. 그러나 보고서의 관리체계를 프로젝트에 적용하면 제안 단계부터 다음을 명시해야 한다.

Agent의 업무 경계와 금지 업무
Owner와 운영 조직, 사고 발생 시 책임·보고 체계
데이터 접근 범위와 외부 전송 여부
자율성 수준별 사람의 승인 지점
품질·안전·비용 KPI와 평가 데이터
로그·감사·이상 탐지·실행 중단 방식
모델·Tool·프롬프트 변경 시 재검증 조건
운영 종료와 권한 회수, 데이터 삭제 절차

이 항목들은 구축 후 운영팀에 넘길 부록이 아니다. RFP, 제안서, 아키텍처 정의서, 테스트 계획, 운영 인수 기준에 처음부터 들어가야 할 요구사항이다.

3.3 Enterprise AI 도입: 도구 승인과 변화관리를 함께 설계해야 한다

보고서는 구성원이 회사가 승인한 도구와 환경을 사용하고, 개인정보·기밀정보 입력을 제한하며, AI 결과의 정확성·출처·저작권을 확인한 뒤 업무에 활용하도록 한다(원문 p.23). 또한 실무협의체, 사례 중심 가이드, 외부 전문가 교육을 통해 원칙을 현장 언어로 전달한다(원문 p.24).

ChatGPT Enterprise, Claude Enterprise, Gemini Enterprise 같은 도구를 도입할 때도 라이선스 배포만으로는 부족하다. 최소한 다음 세 층이 함께 움직여야 한다.

Platform: 승인 도구, 계정, 보안 설정, 데이터 보존·학습 정책
Policy: 입력 가능 정보, 결과 검증, 공유·배포 기준
Practice: 직무별 교육, 사례 라이브러리, 질의응답 채널, 운영 데이터 기반 개선

변화관리의 목표는 모든 구성원이 규정을 암기하게 하는 것이 아니다. 업무 순간에 무엇을 입력해도 되는지, 무엇을 검증해야 하는지, 언제 전문가에게 물어야 하는지 판단할 수 있게 만드는 것이다.

3.4 AI 기반 SW 개발 방법론: SDLC에 Governance Gate가 필요하다

AI가 요구사항·설계·코드·테스트를 빠르게 생성할수록 병목은 작성에서 검증과 의사결정으로 이동한다. 따라서 AI 기반 개발 방법론에는 다음과 같은 Gate가 필요하다.

단계	Governance Gate	통과 증적
Discovery	목적·편익·영향 대상이 명확한가?	Use Case, 기대효과, 위험·기회 평가
Design	데이터·권한·외부 연계가 적절한가?	Data Flow, Threat/Privacy Model, 자율성 등급
Build	모델·Tool·프롬프트가 통제 범위 안에 있는가?	구성목록, 정책 테스트, 변경 이력
Verify	품질과 안전의 완료 기준을 충족하는가?	Eval 결과, Red Team, 승인 기록
Release	사람의 개입·중단·복구가 가능한가?	Runbook, 모니터링, Kill Switch 검증
Operate	비용·성과·위험을 함께 관찰하는가?	Trace, KPI, 사고·예외 기록
Retire	권한과 데이터가 안전하게 회수되는가?	폐기 승인, 접근권한 회수, 보존·삭제 기록

이 구조는 기존 SDLC를 버리는 것이 아니라, AI의 확률적 판단과 Agent의 실행 권한을 다룰 수 있도록 확장하는 것이다.

3.5 DDD와 Cloud Native: Agent도 경계와 소유권이 필요하다

DDD와 MSA에서 가장 중요한 것은 서비스를 잘게 나누는 일이 아니라 업무 책임과 데이터 소유권의 경계를 명확히 하는 것이다. Agent에도 같은 원칙이 적용된다.

하나의 Agent가 여러 업무 도메인의 데이터를 무제한 조회하지 않게 한다.
Tool 권한은 Agent의 역할과 Bounded Context 안에서 부여한다.
사람과 Agent의 책임 경계를 Ubiquitous Language로 명시한다.
이벤트와 실행 이력을 남겨 업무 결과의 원인을 추적할 수 있게 한다.
영향 반경이 큰 작업은 승인·보상 트랜잭션·롤백 경로를 설계한다.

Agent의 유연성을 이유로 경계를 없애면 편리한 데모는 만들 수 있지만 운영 가능한 엔터프라이즈 시스템은 만들기 어렵다.

4. 실무에 바로 적용할 ‘Agent Governance Canvas’

보고서의 내용을 프로젝트 시작 회의에서 사용할 수 있는 한 장짜리 질문으로 재구성하면 다음과 같다.

항목	핵심 질문
Purpose	어떤 업무 결과를 만들며, 하지 말아야 할 일은 무엇인가?
Identity	Agent ID, 버전, 소속, Owner는 누구인가?
Users	누가 사용하고 누가 결과의 영향을 받는가?
Data	어떤 데이터를 어떤 법적·업무적 근거로 처리하는가?
Tools	어떤 모델·API·MCP·시스템을 호출할 수 있는가?
Autonomy	제안, 초안, 승인 후 실행, 자율 실행 중 어느 수준인가?
Human Control	언제 누구의 승인·개입·재검토가 필요한가?
Evaluation	정확성·안전성·편향·비용·업무 성과를 어떻게 측정하는가?
Observability	입력, 판단 근거, Tool 호출, 결과, 비용을 어디까지 기록하는가?
Incident	이상 시 누가 중단하고 어떻게 복구·보고하는가?
Change	모델·데이터·Tool·프롬프트 변경 시 무엇을 재평가하는가?
Retirement	운영 종료, 권한 회수, 데이터 보존·삭제를 어떻게 처리하는가?

이 Canvas를 채우지 못한 Agent는 아직 운영 가능한 제품이 아니라 검증되지 않은 프로토타입에 가깝다.

5. 비판적으로 읽기: 강점과 더 확인하고 싶은 부분

강점 1. 원칙과 운영 사이의 연결이 구체적이다

T.H.E. AI라는 상위 원칙을 위험·기회 평가, 자가진단, 전문 검토, Agent 등록, 운영 기록, 평가와 개선으로 연결한다. 특히 고객용 서비스와 내부 Agent를 모두 관리 범위에 넣었다는 점이 좋다.

강점 2. 자율성을 권한·감독과 연결한다

자율성이 높을수록 사람을 제거하는 것이 아니라, 업무 영향·데이터 민감도·사용 모델·운영 환경에 따라 권한과 감독을 강화한다(원문 p.28). 이는 Human-out-of-the-loop가 아니라 Risk-adjusted Human-in-the-loop에 가깝다.

강점 3. 평가 결과를 유지·개선·종료로 연결한다

Agent를 한 번 배포하고 방치하지 않고 업무 성과, 운영 비용, 기능을 정기 평가해 유지·개선·종료를 판단한다(원문 p.29-30). 생애주기의 마지막에 ‘폐기’를 포함한 것은 실무적으로 중요하다.

더 확인하고 싶은 부분 1. 위험 등급과 통제 강도의 정량 기준

보고서는 위험 기반 차등 관리의 방향을 제시하지만, 공개된 범위에서는 위험 등급 산정식, 승인 임계치, 재평가 주기, 사고 대응 SLA 같은 정량 기준까지는 확인하기 어렵다. 실제 적용에서는 누가 판단해도 비슷한 결론에 도달할 수 있는 기준이 필요하다.

더 확인하고 싶은 부분 2. Agent OS의 기술적 강제력

Agent OS가 실행 기록과 중단 기능을 제공한다는 설명은 있으나, 공개 보고서만으로는 정책 위반을 런타임에서 어떻게 차단하는지, Tool별 권한을 어떤 단위로 격리하는지, Trace의 무결성과 재현성을 어떻게 확보하는지까지 알기 어렵다. Dashboard가 아니라 Policy Enforcement Point로서 얼마나 작동하는지가 핵심이다.

더 확인하고 싶은 부분 3. 멀티 Agent와 외부 모델의 책임 사슬

여러 Agent가 위임·협업하고 외부 모델과 Tool을 연쇄 호출하면 하나의 Owner만으로 책임 경계가 충분하지 않을 수 있다. 호출 관계, 데이터 전달, 하위 Agent의 권한 상속, 실패 전파를 포함한 End-to-End Accountability가 다음 과제가 될 것이다.

더 확인하고 싶은 부분 4. 성과 보상과 안전의 균형

보고서는 Agent의 성과를 조직 성과와 연계하고 장기적으로 KPI 반영까지 고려한다. 생산성 향상에는 도움이 되지만, 처리량 중심의 지표는 검증 생략이나 과도한 자동화를 유도할 수 있다. 따라서 성과 평가는 속도·비용뿐 아니라 오류율, 재작업률, 사고 영향도, 사람의 개입 빈도 같은 Risk-adjusted KPI와 함께 설계해야 한다.

위 항목들은 보고서에 체계가 없다는 뜻이 아니라, 대외 공개된 내용만으로는 세부 구현을 판단하기 어렵다는 의미다.

6. 내가 현장에 적용한다면

이 보고서의 내용을 AI Agent 사업과 Enterprise AI 도입에 적용한다면 다음 순서로 시작하겠다.

Agent Inventory를 만든다. 실험용·부서용·전사용 Agent를 모두 식별하고 Owner를 지정한다.
자율성 등급을 정의한다. 제안, 초안, 승인 후 실행, 제한적 자율 실행처럼 단계화한다.
데이터와 Tool 권한을 묶어서 심사한다. 모델만 승인하지 않고 Agent가 접근하는 전체 실행 표면을 본다.
공통 Eval과 정책 테스트를 자산화한다. 모델이 바뀌어도 남는 검증 기준을 만든다.
운영 Trace를 표준화한다. Agent ID, 버전, 입력, Tool 호출, 승인, 결과, 비용, 오류를 연결한다.
중단과 복구를 실제로 시험한다. 문서에 Kill Switch가 있다고 쓰는 것과 동작을 검증하는 것은 다르다.
정기 평가로 확대·개선·폐기를 결정한다. 만들어진 Agent의 수가 아니라 살아남아 가치를 내는 Agent의 비율을 본다.
교육을 역할별로 나눈다. 일반 사용자, Agent Builder, Owner, 보안·개인정보 담당자의 교육 내용은 달라야 한다.

핵심은 새로운 위원회를 더 만드는 것이 아니다. 현업의 개발·배포·운영 흐름 안에 거버넌스 증적이 자연스럽게 남도록 플랫폼과 프로세스를 함께 설계하는 것이다.

맺으며: 신뢰는 선언이 아니라 시스템의 속성이다

이 보고서가 보여 주는 가장 큰 변화는 AI 거버넌스의 중심이 윤리 원칙에서 운영 아키텍처로 이동하고 있다는 점이다. 원칙은 필요하지만 원칙만으로는 Agent의 잘못된 Tool 호출을 막을 수 없다. 책임자를 지정하고, 권한을 제한하고, 실행을 기록하고, 결과를 평가하고, 필요하면 중단·폐기할 수 있어야 한다.

AI Architect의 역할도 달라진다. 좋은 모델을 고르고 연결하는 것만으로는 부족하다. AI가 어떤 의도로, 어떤 근거와 권한을 가지고, 어디까지 행동하며, 그 결과를 누가 어떻게 검증하고 책임질지를 설계해야 한다.

신뢰할 수 있는 AI는 정확한 답을 자주 내는 AI가 아니다. 잘못될 수 있음을 전제로 관찰하고, 개입하고, 복구하고, 책임질 수 있게 설계된 AI다.

Agentic AI 시대의 경쟁력은 가장 많은 Agent를 만드는 데서 나오지 않는다. 가치 있는 Agent를 안전하게 운영하고, 경험을 다음 설계에 반영하는 조직적 학습 능력에서 나온다.

참고 자료

SK텔레콤 AI Governance Report 2026 원본 PDF