Post

2026년 10월 7일 AI 뉴스: 검증 가능한 수학과 실행 가능한 기업 지식

2026-10-07 11:30 · ai-daily-news

오늘의 AI Daily News

작성 기준

2026년 10월 7일 11:30 KST 기준으로 공개된 공식 발표와 공식 개발자 문서만 확인했다. 이 실행 환경에서 웹 검색 결과를 정상적으로 읽을 수 없었으므로 검색 오류를 실패 사유로 삼지 않았다. 대신 OpenAI News와 10월 6일 공개된 AI 수학 성과 공개, Atlassian 협력 확대 원문을 직접 확인했다. 맥락을 위해 EU 텍스트 출처 규칙, ChatGPT 광고 업데이트, GPT-6 family 운영 가이드도 검토했다. 아래의 발표 사실은 원문에 근거하며, 개발·운영 제안은 실무 적용을 위한 해석이다.

한 문장 요약

AI가 발견한 수학은 검증 가능한 증거로, 기업 지식은 권한 있는 실행으로, AI 인터페이스의 상업성은 분리 가능한 정책으로 바뀌고 있다. 경쟁력은 모델의 문장보다 증거·맥락·권한·측정을 함께 설계하는 능력에서 나온다.

배경: 잘 답하는 AI에서 설명 가능하게 일하는 AI로

AI 제품의 첫 경쟁은 대화 품질이었다. 다음 경쟁은 검색, 코딩, 문서 요약, 이미지 생성처럼 특정 업무에서의 생산성이었다. 하지만 모델이 연구 결과를 제안하고, 사내 그래프를 읽어 프로젝트 병목을 찾으며, 고객이 결정을 내리는 화면에 상업 메시지까지 표시하는 단계에서는 질문이 달라진다. 모델이 그럴듯하게 말했는가가 아니라, 그 결론을 누가 다시 확인할 수 있는가, 어떤 자료와 권한을 거쳤는가, 외부 행동을 누가 승인했는가, 수익화가 답변을 왜곡하지 않는가가 중요해진다.

오늘의 두 핵심 발표는 서로 다른 시장을 다루지만 같은 방향을 가리킨다. 하나는 내부 frontier 모델이 낸 수학 결과를 GitHub 저장소, 증명 formalization, reasoning summary, 시도 통계와 함께 공유하는 방식이다. 다른 하나는 OpenAI 모델을 Atlassian의 Teamwork Graph와 Rovo에 연결해 Jira·Confluence·대화·사람·결정을 실제 업무 맥락으로 사용하는 방식이다. AI 출력은 단독 문장이 아니라 검증 가능한 산출물과 추적 가능한 업무 상태로 다뤄져야 한다.

수학에서는 오류 한 줄이 전체 정리를 무너뜨릴 수 있다. 기업 업무에서는 잘못된 컨텍스트, 과도한 권한, 오래된 문서, 누락된 결정이 출시 지연·고객 사고·보안 사고로 이어질 수 있다. 두 경우 모두 모델의 자신감은 증거가 아니다. AI를 도입하는 팀은 “모델이 무엇을 할 수 있나”와 함께 “모델이 만든 주장·계획·실행을 어떤 형태로 보존하고 반증·수정·승인할 것인가”를 설계해야 한다.

Top News 1. OpenAI, AI 수학 결과를 GitHub·Lean·추론 요약과 함께 공개

OpenAI는 Sharing AI progress in mathematics에서 내부 frontier 모델이 생성한 폭넓은 수학 결과를 공개한다고 밝혔다. 이번 공개는 결과 문장만 전하는 방식이 아니다. Institute for Advanced Study의 독립 자문 그룹과 공개 관행을 논의했고, 결과를 GitHub 저장소에 게시하며 논문 수정과 인용을 위한 프로토콜을 둔다. 많은 증명은 컴퓨터가 검사할 수 있는 증명 언어인 Lean으로 formalization을 함께 제공하고, formalization이 확보되는 대로 저장소를 계속 갱신할 계획이다.

공개 범위에는 과학적 투명성을 위한 추가 정보도 포함된다. OpenAI는 모델 추론의 요약 10개, ChatGPT Pro 기준 사용량으로 환산한 계산량 추정, 시도한 문제 수 통계를 공유한다고 설명했다. 평균 결과는 ChatGPT Pro thinking 약 3시간에 해당하는 계산을 사용했다. 회사는 AI가 낸 주요 과학 성과의 이해를 위한 워크숍·학회·특별 프로그램도 지원하고, 해당 모델의 책임 있는 공개를 위해 수학과 다른 과학 분야에서 내부 frontier 모델 평가를 계속하겠다고 밝혔다.

왜 벤치마크 뉴스보다 중요한가

수학은 AI의 고난도 추론 능력을 보여 주기 좋은 분야이지만, “그럴듯한 설명”과 “유효한 증명”의 차이가 가장 분명한 분야이기도 하다. 자연어 풀이가 읽기 좋아도 전제가 누락됐거나 정리 적용 범위가 틀렸거나 한 단계의 논리 비약이 있으면 결과는 성립하지 않는다. 반대로 형식 검증기는 사람이 보기엔 장황한 객체라도 정해진 공리와 추론 규칙 아래 오류를 기계적으로 확인한다.

GitHub, revision protocol, citation, Lean formalization, reasoning summary, attempt statistic을 함께 공개하는 방식이 중요한 이유가 여기에 있다. 논문 PDF만 공개하면 독자는 결론과 서술을 읽을 수 있다. 저장소까지 있으면 변경 이력과 재현 단위를 추적할 수 있다. 형식 증명까지 있으면 최소한 formalization된 부분에 대해 독립적인 검증 경로가 생긴다. 추론 요약과 시도 통계를 제공하면 성공 사례만 보고 모델이 항상 같은 성과를 낸다고 오해하는 일을 줄일 수 있다. 이것은 결과의 권위를 선언하는 방식이 아니라 공동체가 결과를 검토·반박·개선할 표면적을 넓히는 방식이다.

Lean으로 formalization됐다는 말도 과장해서는 안 된다. formalization 범위가 전체 논문인지 핵심 보조정리인지 확인해야 하고, 형식화한 정의·공리·라이브러리 의존성이 문제에 맞는지도 사람이 검토해야 한다. 컴퓨터 검증은 수학 문장의 성립을 다루며 결과의 중요성, 독창성, 설명 품질, 실제 현상에 대한 적용 가능성까지 자동 판정하지 않는다. 형식 검증은 인간 심사를 대체하기보다 심사의 역할을 더 정교하게 나눈다.

개발자에게 의미: 주장·증거·계보를 분리하라

AI가 만든 연구·분석·코드·정책 초안에도 같은 구조를 적용할 수 있다.

주장(claim): 모델이 무엇을 결론으로 제시했는가. “이 정리가 성립한다”, “이번 릴리스는 위험하다”, “이 변경이 성능 저하를 해결한다”가 여기에 속한다.
증거(evidence): 주장을 지지하거나 반박할 수 있는 입력·실험·문서·로그·증명·테스트다. 증거에는 링크, 버전, 시간, 해시, 접근 권한이 필요하다.
계보(provenance): 어떤 모델·프롬프트 클래스·도구·사람 검토·수정 단계를 거쳐 산출물이 나왔는가다. 계보는 책임과 재현을 위한 기록이지 결과의 진실성을 자동 보장하는 도장이 아니다.

이 셋을 문서 본문에 섞으면 업데이트와 감사가 어려워진다. AI가 작성한 출시 위험 요약은 읽기 쉬운 claim으로 제공하되, 각 문장에 대응하는 Jira issue·PR·테스트·결정 기록은 evidence로 연결한다. 모델 버전, retrieval snapshot, 생성 시각, 사람 승인자는 provenance ledger에 남긴다. 그러면 원본 티켓이 변경됐을 때 어떤 결론을 재평가해야 하는지, 담당자가 결론을 바꿨을 때 근거가 무엇인지, 모델 업데이트가 결과에 어떤 영향을 줬는지를 추적할 수 있다.

reasoning trace를 검증 계약으로 바꾸기

발표에 포함되는 reasoning summary는 과학 커뮤니케이션과 평가에 의미 있는 맥락을 제공할 수 있다. 그러나 실무 서비스에서 모델이 내놓은 긴 사고 과정이나 작업 내역을 그 자체로 검증 근거로 취급해서는 안 된다. 설명은 사후 합리화일 수 있고, 민감 데이터·비밀·불필요한 개인 정보가 포함될 위험도 있다. 필요한 것은 원문 사고 과정을 무제한 저장하는 일이 아니라 검증 가능한 산출물 중심의 계약이다.

finding_id
claim
confidence_or_uncertainty
evidence_refs[]
data_snapshot_digest
checks_performed[]
known_limitations[]
recommended_next_action
approval_state

evidence_refs는 원본 테이블 전체나 고객 대화를 복사하는 대신 접근 통제된 쿼리·대시보드·문서 버전의 참조를 둔다. checks_performed에는 집계 기간 비교, 결측치 검사, 재현 쿼리, 독립 계산처럼 관찰 가능한 검사를 기록한다. known_limitations에는 데이터 지연, 표본 편향, 인과 추론 불가, 정책 변경 등 결론의 경계를 적는다. 이 구조는 모델에게 더 정직한 표현을 강제하고, 리뷰어에게는 무엇을 확인해야 하는지 알려 준다.

코딩 agent도 같다. “버그를 고쳤다”는 자연어 보고보다 변경 파일, diff digest, 실행한 테스트 명령, 테스트 결과, 수정하지 않은 위험 영역, rollback 경로가 더 좋은 증거다. 수학에서 Lean proof가 자연어 풀이와 다른 검사 경로를 제공하듯, 소프트웨어에서는 compiler, type checker, test, static analysis, deployment health check가 모델 설명과 독립된 검사 경로여야 한다.

운영 포인트: 공개 전 검토와 공개 후 정정을 함께 설계하라

AI가 생성한 연구 또는 고영향 분석은 처음 공개할 때 완벽할 수 없다. 그래서 revision protocol이 중요하다. 조직도 결과의 안정성 수준, 수정 유형, 수정 식별자, 독자 고지, 인용 원칙을 사전에 정해야 한다. 오탈자·표현 개선·데이터 갱신·결론 변경·철회를 다른 사건으로 분류하고, 각각에 version, commit SHA, data snapshot, model·tool version을 연결한다.

대시보드나 지식 베이스의 AI 요약도 마찬가지다. 최신 데이터로 다시 생성한 요약이 이전 결론과 달라졌을 때 본문만 덮어쓰면 사용자는 무엇이 달라졌는지 알 수 없다. generated_at, source_snapshot_at, supersedes, changed_claims를 보존해야 한다. 경영 판단·안전 판단·고객 발송처럼 결과가 실제 행동으로 연결되는 시스템은 이전 버전이 누구에게 어떤 영향을 줬는지까지 조회할 수 있어야 한다.

Top News 2. Atlassian과 OpenAI, 기업 지식을 실행 가능한 에이전트 맥락으로 연결

OpenAI는 Atlassian and OpenAI expand partnership to turn enterprise knowledge into action에서 GPT-6 family 모델을 Atlassian 플랫폼과 Rovo 전반의 agent 경험에 제공하는 협력 확대를 발표했다. 핵심 연결 고리는 Teamwork Graph다. 이 엔터프라이즈 컨텍스트 계층은 사람, 프로젝트, 문서, 결정 사이의 관계를 연결해 AI가 회사가 실제로 어떻게 일하는지 이해하도록 돕는다.

발표문에 따르면 협력은 2023년부터 이어진 관계를 확장하는 것이며, Atlassian은 Codex와 ChatGPT Enterprise 도입도 넓히고 있다. 3,000명 이상 Atlassian 개발자가 terminal, IDE, code review workflow에서 Codex를 사용하고 있다. Teamwork Graph 기반 플러그인을 통해 Codex 사용자는 관련 work item과 기술 문서에 접근해 작성·테스트·출하 업무를 지원받을 수 있다. Atlassian은 최신 frontier 모델과 GPT-5.6 series에 대한 접근을 넓히고, OpenAI는 Jira로 핵심 workflow를 계속 관리한다.

Rovo의 예시는 제품 관리자가 출시 준비가 정상 궤도인지 묻는 상황이다. Teamwork Graph가 Jira ticket, Confluence document, 관련 discussion을 연결하면 모델은 engineering blocker, 누락된 milestone, 주의가 필요한 결정을 찾아 출시 준비도 평가와 다음 조치를 제안할 수 있다. ChatGPT와 Codex를 위한 Atlassian·Teamwork Graph CLI 플러그인, Jira work item·Confluence content·people을 prompt에 가져오는 extension, assigned work·최근 Loom·project·Bitbucket PR을 보여 주는 Atlassian Home도 언급됐다.

RAG가 문서 검색에서 업무 그래프 해석으로 이동한다

많은 기업 AI 프로젝트는 사내 문서를 벡터 DB에 넣고 질문에 답하는 형태로 시작한다. 정책 찾기, 과거 회의 요약, 기술 지식 검색에는 유용하다. 그러나 “출시가 위험한가”, “누가 이 결정을 내렸나”, “이 고객 이슈와 연결된 배포는 무엇인가”, “이 PR을 막고 있는 의존성은 무엇인가” 같은 질문은 객체와 관계, 시간, 상태, 권한을 함께 다뤄야 한다.

Teamwork Graph의 방향이 중요한 이유가 여기 있다. 프로젝트·문서·사람·결정·작업 항목을 연결하면 AI는 문장 유사도만으로 관련 자료를 꺼내는 대신 업무 모델 안에서 맥락을 구성할 수 있다. 티켓의 담당자, 상위 initiative, linked PR, 결정 문서, 변경 이력, 마감일, blocker 관계가 명시돼 있다면 “관련 문서 세 개”보다 “마감이 5일 남았고 보안 검토가 미할당이며 결제 API 변경 PR 두 개가 대기 중”처럼 행동 가능한 설명을 만들 수 있다.

그러나 그래프가 있다고 자동으로 신뢰할 수 있는 것은 아니다. 그래프의 관계는 stale할 수 있고, Jira 상태는 실제 작업 상태와 다를 수 있으며, Confluence 문서는 승인되지 않은 초안일 수 있다. “관련 있다”는 edge와 “현재 유효하다”는 판단은 다르다. AI가 그래프에서 얻은 사실을 제시할 때는 source object, last updated, owner, access scope, missing data를 보이도록 설계해야 한다. 그래프는 모델의 기억을 늘리는 장치가 아니라 검증해야 할 업무 맥락을 구조화하는 장치다.

개발자에게 의미: 검색 권한과 행위 권한을 분리하라

기업 지식을 AI에 연결할 때 가장 흔한 위험은 사용자가 볼 수 있는 정보와 AI가 할 수 있는 행동을 한 덩어리로 취급하는 것이다. 문서 열람 권한이 있다고 티켓 상태 변경, 사람 할당, 배포 승인, 고객 메시지 전송 권한까지 있는 것은 아니다. 권한 모델을 다음 세 층으로 나누는 편이 안전하다.

층	질문	예시
발견 권한	무엇을 찾을 수 있는가	프로젝트 존재, 공개 문서 제목
열람 권한	무엇의 본문을 읽을 수 있는가	해당 팀 Jira·Confluence·PR
행위 권한	무엇을 바꿀 수 있는가	티켓 생성, 담당자 변경, 배포 요청

agent는 사용자 identity와 delegation scope를 가지고 매 요청마다 필요한 최소 capability를 받아야 한다. issue:read와 issue:transition, confluence:read와 page:publish, repo:read와 pull_request:merge는 분리해야 한다. 외부 action에는 target, parameter digest, expiry, approval state를 묶고, 모델이 새 target을 제안하면 이전 승인을 재사용하지 못하게 해야 한다.

컨텍스트 조립은 query가 아니라 정책 결정이다

AI에 어떤 Jira ticket과 문서를 넣을지 정하는 retrieval은 단순한 성능 최적화가 아니다. 데이터 최소화, 비밀 보호, 편향 방지, 비용 통제, 최신성 보장을 동시에 다루는 정책 결정이다. context broker는 적어도 다음 질문에 답할 수 있어야 한다.

이 객체를 왜 가져왔는가: keyword match, graph edge, explicit link, user selection 중 무엇인가.
이 객체는 현재 유효한가: 마지막 업데이트, 상태, 승인 단계, deprecation 표시가 무엇인가.
이 객체를 사용자와 agent가 모두 볼 권한이 있는가.
일부 필드를 마스킹하거나 요약해야 하는가.
더 최신이거나 권위 있는 대체 자료가 있는가.
컨텍스트 예산 때문에 무엇을 제외했고 그 제외가 결론에 영향을 줄 수 있는가.

시스템은 retrieval manifest를 남겨야 한다. manifest에는 object ID, version, retrieval reason, access decision, redaction decision, rank, timestamp가 포함될 수 있다. 사고가 발생했을 때 “모델이 왜 오래된 정책을 따랐나”라는 질문에 답하려면 prompt transcript보다 이 manifest가 더 중요하다.

human-in-the-loop은 버튼 하나가 아니라 책임 흐름이다

모든 결과에 승인 버튼을 붙이는 것은 인간 통제가 아니다. 위험 수준에 따라 사람이 개입할 위치와 필요한 증거를 달리 설계하는 것이다.

위험 등급	예시	권장 처리
P2 낮음	문서 요약, read-only 검색, 초안 생성	자동 실행, citation·로그 보존
P1 중간	티켓 생성, 분류 변경, 내부 알림 초안	제안 후 scoped 승인, 결과 readback
P0 높음	권한 변경, 고객 발송, 비용 발생, production 배포	명시적 승인, parameter binding, 독립 검증·rollback

승인은 자연어 “진행하세요”보다 구체적 artifact와 연결돼야 한다. 배포라면 commit SHA, environment, migration 여부, rollout 범위, rollback plan에 묶는다. 티켓 변경이라면 대상 ID, 상태 전이, 담당자, 외부 노출 여부, 만료 시각을 묶는다. 실행기는 모델의 자연어를 다시 해석하지 않고 승인된 구조화 contract만 받아야 한다.

Top News 3. 출처 신호·광고·장기 실행 에이전트가 가리키는 공통 원칙

EU 텍스트 출처 규칙 대응은 API 고객이 선택 모델에서 텍스트 워터마킹을 opt-in할 수 있고, EU의 적격 ChatGPT·Codex 텍스트에는 향후 보이지 않는 watermark를 추가할 계획이라고 밝혔다. textGrain은 단어 선택에 통계적 신호를 넣고 detector가 그 신호를 평가하는 방식이다. 하지만 OpenAI는 짧고 제약된 텍스트, 수학처럼 단어 선택 자유도가 낮은 내용, 편집·번역에 대한 한계를 구체적으로 공개했다. 400-token 평가에서 동의어 10% 치환은 탐지율을 약 92%에서 66%로, 25% 치환은 17%로 낮췄다.

ChatGPT 광고 업데이트는 이미지 생성 중 Free·Go 이용자에게 명확히 라벨된 visual ad를 미국에서 시험하겠다고 했다. 광고는 생성 이미지와 분리되고 답변에는 영향을 주지 않는다는 원칙, 대화 맥락의 적합성을 판단하는 guardrail, 독립 파트너가 개인 대화에 접근하지 않고 brand suitability를 평가하는 pilot도 언급됐다. GPT-6 family 운영 가이드는 caching, compaction, monitoring, data control, representative task 평가, long-running work의 steering·async tool·delegation을 production 기본값으로 제시한다.

세 주제의 공통점은 AI 시스템이 신뢰받으려면 서로 다른 역할을 섞지 말아야 한다는 것이다. watermark는 저작권·진실성·책임을 판정하는 도구가 아니라 제한된 출처 신호다. 광고 placement는 독립 답변의 ranking path와 분리돼야 한다. agent의 계획은 실행 권한과 분리돼야 한다. 모든 결과를 한 점수, 한 UI, 한 service account로 처리하면 편해 보이지만 사건이 났을 때 누구도 무엇이 무엇을 바꿨는지 설명할 수 없다.

provenance는 boolean이 아니라 evidence envelope이다

ai_generated: true 같은 단일 필드는 곧 부족해진다. 실제 제품은 생성 경로, 출처 신호, 인간 기여, 유통 맥락, 검증 시점, 검증 한계를 분리해야 한다. watermark가 검출되지 않았다고 인간 작성임을 뜻하지 않으며, 검출됐다고 책임자·정확성·저작권 상태가 확정되는 것도 아니다. detector 결과는 detected, not_detected, inconclusive, not_supported를 구분하고, 문서 길이·언어·편집 여부·지원 모델을 함께 저장해야 한다.

고객에게는 “AI 보조 초안, 담당자 검토 완료” 같은 간단한 문구가 충분할 수 있다. 반면 내부 audit에는 model ID, content version, source digest, review timestamp, policy version, disclosure state를 보관한다. 이 envelope은 처벌 자동화가 아니라 triage와 설명 책임을 위한 것이다. 오탐·미탐이 가능한 탐지 신호 하나로 학생·직원·고객을 자동 판정하는 것은 기술적 한계를 무시하는 일이다.

광고·추천·답변의 데이터 경로를 분리하라

상업 기능이 있는 AI 제품은 다음 세 객체를 데이터 모델과 UI에서 분리해야 한다.

Answer: 사용자의 질문에 대한 독립적인 설명·비교·요약
Recommendation: 공개된 기준과 근거를 가진 선택지 제안
Sponsored placement: 대가를 받고 노출되는 광고 또는 프로모션

이들을 같은 ranking score로 합치면 투명성 요구가 들어왔을 때 분리할 수 없다. answer service가 광고 targeting feature를 읽지 못하게 하고, placement service는 답변 본문을 수정할 권한이 없게 하며, rendering 계층에서만 허용된 slot과 label을 결합하는 편이 낫다. 광고 measurement에는 최소 데이터만 전달하고, 대화 원문과 conversion data의 접근·보존 정책을 분리한다. 사용자의 opt-out은 UI 설정에만 머물지 않고 placement 호출 직전에 다시 적용돼야 한다.

long-running agent의 compaction은 대화 요약이 아니라 상태 보존이다

긴 실행에서 context를 줄이는 compaction은 비용 기능이기도 하지만 더 본질적으로는 실행 상태 보존 기능이다. 자연어 요약만 남기면 이미 보낸 메일, 생성된 티켓, 결과가 불명확한 write 요청, 대기 중인 승인, 재시도 금지 조건을 잃기 쉽다. 그러면 agent는 같은 외부 행동을 반복할 수 있다.

completed_actions
external_side_effects
pending_approvals
artifact_uris
failed_attempts
idempotency_keys
retry_policy
next_allowed_actions
policy_version

네트워크 timeout은 실패와 같지 않다. write 결과가 불명확하면 재시도 전에 외부 readback으로 결과를 조회하고, idempotency key 또는 compare-and-swap 조건을 이용해야 한다. 모델이 “완료했다”고 말하는 것은 receipt가 아니다. ticket ID, deployment health check, API response, database version처럼 외부 시스템이 반환한 독립 증거가 있어야 한다.

구현 청사진: 증거·맥락·권한·측정을 하나의 운영 모델로 묶는 법

Evidence ledger

AI가 만든 중요한 결론마다 별도의 evidence ledger record를 남긴다. 이것은 prompt 전체를 영구 보관하는 로그가 아니다. 재현과 감사를 위해 필요한 최소 단위의 메타데이터다. assessment_id, claim_digest, source_refs, source_versions, retrieval_manifest, model_release, tool_versions, policy_version, reviewer, created_at, valid_until 정도면 시작할 수 있다.

source reference는 파일 경로나 URL만이 아니라 권위와 최신성도 나타내야 한다. 정책 문서라면 승인 상태와 effective date, 코드라면 commit SHA와 CI run, 데이터라면 query digest와 snapshot time, Jira item이라면 status transition timestamp를 포함한다. 시스템은 “이 답이 무엇을 봤는가”뿐 아니라 그 자료가 당시에도 유효했는지를 되짚을 수 있어야 한다.

Context broker

retrieval을 prompt 내부의 보조 코드로 남겨 두면 데이터 경계와 평가가 흐려진다. context broker는 identity, requested task, allowed scopes, freshness policy, budget을 받아 context packet과 manifest를 반환하는 독립 계층이 될 수 있다. 목표는 가능한 많은 문서를 넣는 것이 아니라 필요한 증거를 최소 권한·최신 버전·설명 가능한 근거로 전달하는 것이다.

broker는 stale document를 버리는 것만이 아니라 최신 문서가 없음을 명확하게 알려야 한다. project status가 14일 이상 업데이트되지 않았으면 “지연된 상태 정보”를 모델과 사용자 모두에게 표시해야 한다. 부족한 정보를 모델이 그럴듯하게 보충하도록 두는 것보다 insufficient_evidence 상태를 결과 schema에 허용하는 것이 안전하다.

Proposal과 execution의 분리

AI가 외부 시스템을 조작할 수 있다면 model output을 곧바로 API call로 변환하지 않는다. 먼저 proposed_action을 만든다.

action_type
target
parameters_digest
evidence_refs
risk_level
expected_side_effect
required_approval
expiry
rollback_hint

policy service는 이 객체와 현재 권한·위험 정책을 검증한 뒤 제한된 capability token을 발행한다. executor는 token에 포함된 action·target·parameter digest와 일치할 때만 실행한다. 결과는 별도 execution_receipt로 기록하고 API readback 또는 health check로 확인한다. 그러면 AI가 계획을 잘 세워도 승인 범위를 넘어 실행하지 못하고, 승인자는 막연한 자연어가 아니라 실제 영향을 검토할 수 있다.

평가: 정답률에서 수용된 완료로

agent의 비용은 모델 토큰만이 아니다. tool 실행, sandbox, retrieval, reviewer 시간, retry, rework, incident 가능성이 모두 포함된다. 운영 지표는 cost per accepted completion으로 옮기는 편이 좋다.

model cost + tool cost + infrastructure + reviewer time + retry + rework + expected incident cost

AI가 초안을 빨리 내지만 리뷰어가 대부분 다시 작성한다면 호출 수가 늘어도 생산성은 개선되지 않는다. 반대로 더 높은 reasoning effort가 테스트 통과율과 reviewer acceptance를 높이면 모델 비용이 커져도 총비용은 줄 수 있다. 팀은 실제 repository, 실제 권한, 실제 data classification이 있는 대표 작업으로 평가해야 한다. 공개 벤치마크가 아니라 업무 단위의 성공·실패·복구 시간을 기록해야 한다.

Shadow → canary → 확대

새 모델, 새 graph connector, 새 watermark policy, 새 ad placement rule을 한 번에 전체 사용자에게 적용하면 실패 원인을 분리하기 어렵다. 과거 요청이나 동의된 샘플에서 shadow run으로 기존 결과와 비교한 뒤, 내부 사용자·낮은 위험 action·제한된 트래픽에 canary를 적용한다. rollout 조건은 “오류가 없어 보인다”가 아니라 task success, policy violation, stale citation, opt-out propagation latency, cost, human override, complaint rate 같은 사전 정의된 기준으로 정한다.

rollback도 배포 설정만 되돌리는 일로 끝나지 않는다. 이미 생성된 요약, 이미 노출된 placement, 이미 실행된 ticket transition, 이미 cache된 policy context를 각각 처리해야 한다. 콘텐츠는 version과 notice, 광고는 campaign pause와 impression reconciliation, agent action은 compensating transaction 또는 담당자 escalation, cache는 invalidation과 재검증이 필요할 수 있다.

이번 주 바로 할 일

AI가 관여하는 업무 결과를 주장·증거·계보로 나누어 저장할 위치를 정한다.
Jira·Confluence·GitHub·CRM 등 connector별로 발견·열람·행위 권한을 분리해 inventory를 만든다.
현재 RAG 또는 graph retrieval에 source version, last updated, retrieval reason, access decision을 남기는지 점검한다.
고위험 tool call을 proposed action과 execution receipt로 분리한다.
기존 agent의 긴 대화 요약이 외부 side effect와 pending approval을 보존하는지 검토한다.
생산성 dashboard에서 AI 호출 수 대신 accepted completion, review burden, rework, incident 지표를 추가한다.
사용자에게 표시되는 AI disclosure, sponsored label, uncertainty label이 데이터 모델과 실제 권한 경계까지 연결되는지 테스트한다.
새 모델·새 connector·새 정책은 shadow와 canary 단계를 거치도록 release template을 수정한다.

맺음말

오늘의 뉴스는 모델이 더 어려운 문제를 풀고, 더 많은 기업 시스템과 연결되며, 더 넓은 소비자 인터페이스에 들어간다는 소식이다. 그러나 확장의 핵심은 “더 많은 자동화” 자체가 아니다. 수학에서는 결과를 검토 가능한 artifact로 바꾸는 공개 방식이, 기업에서는 지식을 권한·시간·관계가 있는 작업 맥락으로 바꾸는 그래프가, 소비자 제품에서는 답변·광고·출처·실행을 분리하는 경계가 중요해진다.

AI 시스템이 신뢰를 얻는 순간은 모델이 가장 그럴듯하게 말할 때가 아니라, 사용자가 결과를 검토하고 반박하고 수정하고 되돌릴 수 있을 때다. 앞으로 강한 팀은 가장 긴 프롬프트를 가진 팀이 아니라, 가장 명확한 evidence ledger, 가장 좁은 capability, 가장 최신의 context, 가장 정직한 measurement를 가진 팀이 될 가능성이 크다.