모델은 바뀌고 권한은 남는다, 오늘 나는 운영의 경계를 생각했다

Summary

한눈에 보기

AI 생성물의 표시는 라벨 하나가 아니라 출처와 사람의 검토 이력을 함께 남기는 일이라고 받아들였다.
팀별 모델 권한과 실제 모델 종료를 보며 모델 이름을 코드가 아닌 교체 가능한 정책으로 관리해야겠다고 생각했다.
자동화 토큰과 에이전트 실행환경에는 넓은 권한보다 짧은 수명, 점검, 사람의 승인이 먼저라고 판단했다.

오늘 아침 브리핑에는 모델, 규제, 토큰, 에이전트, 블록체인 이야기가 한꺼번에 들어 있었다. 처음에는 또 새로운 기능을 따라가야 하나 싶었다. 그런데 원문을 하나씩 확인하고 나니 내게 남은 것은 기능 목록이 아니었다.

빨리 바뀌는 기술을 오래 쓰려면, 무엇을 쓸지보다 어디까지 허용하고 어떻게 바꿀지를 먼저 정해야 한다.

오늘은 확인 가능한 공식 발표 중 이 생각과 직접 이어지는 다섯 가지만 남겼다. 화려한 전망보다 지금 서비스에 적용할 수 있는 운영 기준에 집중하려 한다.

AI 표시를 라벨 하나로 끝내면 부족하다

OpenAI는 7월 31일 유럽연합의 범용 AI 모델 행동규범과 AI 생성 콘텐츠 투명성 행동규범을 지지한다고 밝혔다. 생성물의 출처를 남기는 방식으로 Content Credentials(C2PA)와 SynthID를 함께 언급했고, 메타데이터가 사라질 수 있으며 하나의 신호만으로는 완전하지 않다는 한계도 적었다.

나는 이 대목이 좋았다. “AI가 만들었습니다”라는 문구 하나를 붙이는 것으로 책임이 끝난다고 말하지 않았기 때문이다. 어떤 모델과 도구가 사용됐는지, 무엇을 사람이 고쳤는지, 누가 공개를 승인했는지가 함께 남아야 나중에 결과를 되짚을 수 있다.

이 글 역시 AI의 도움으로 자료를 정리하고 세 언어로 옮겼으며, 표지는 글 전용으로 새로 만들었다. 대신 확인한 출처를 주장 가까이에 두고, 승인 상태를 메타데이터에 남기고, 실제 공개는 사람이 PR을 병합할 때 확정한다. 완벽한 증명은 아니지만 내가 지키고 싶은 최소한의 경계다.

모델 선택은 취향이 아니라 권한과 교체의 문제가 됐다

GitHub는 Copilot Business·Enterprise의 팀 단위 모델 정책을 공개 미리보기로 발표했다. 기업 전체의 기본 모델을 정하면서 특정 팀에 추가 모델을 허용할 수 있다. 여러 팀에 속한 사용자는 어느 한 팀에서 모델을 부여받으면 접근할 수 있는 방식이고, 대부분의 기업 고객에게는 8월 3일부터 미리보기 선택지가 순차적으로 제공될 예정이다.

같은 날 GitHub는 Gemini 2.5 Pro와 Gemini 3 Flash를 Copilot 전반에서 종료했다. 권장 대체 모델은 각각 Gemini 3.1 Pro 미리보기와 Gemini 3.6 Flash다.

두 발표를 함께 보니 모델은 더 이상 개발자가 개인적으로 고르는 옵션에 머물지 않는다. 조직은 누가 어떤 모델을 쓸 수 있는지 정해야 하고, 선택한 모델이 사라졌을 때 업무가 계속되는지도 확인해야 한다.

나도 HaruSpace에서 특정 모델명을 업무 코드 곳곳에 박아 넣고 싶지 않다. 빠른 작업, 긴 계획, 코드 검토처럼 역할을 먼저 정의하고 실제 모델은 교체 가능한 설정으로 연결하는 편이 낫다. 교체 전에는 대표 작업 몇 개로 성공률, 지연시간, 비용, 사람의 수정량을 다시 확인해야 한다. 최신 모델을 붙이는 속도보다 바꿔도 무너지지 않는 구조가 더 중요하다.

자동화 토큰이 계정의 만능열쇠가 되어서는 안 된다

npm은 2단계 인증을 우회하도록 설정된 granular access token의 권한을 제한했다. 이제 이런 토큰으로 새 토큰을 만들거나 지우고, 패키지 접근권한·관리자·trusted publishing 설정, 조직과 팀 구성을 바꿀 수 없다. 해당 작업에는 사람이 참여하는 2단계 인증이 필요하다. npm은 2027년 1월을 목표로 이 토큰의 직접 배포 기능도 없애고, OIDC 기반 trusted publishing이나 사람이 승인하는 staged publishing으로 옮기라고 안내했다.

자동화는 사람의 반복 작업을 줄이기 위한 것이지 사람의 모든 권한을 복사하기 위한 것이 아니다. 배포 작업에는 배포에 필요한 권한만, 필요한 시간 동안 주는 것이 맞다. 편의를 위해 만든 장기 토큰 하나가 계정과 조직까지 바꿀 수 있다면 자동화가 아니라 위험을 저장한 셈이다.

에이전트가 떠난 자리도 확인해야 한다

Google Cloud의 7월 31일 릴리스 노트는 Gemini Enterprise Agent Platform 컨테이너에서 자격증명, 접근 토큰, API 키 같은 평문 비밀정보를 찾는 Agent Platform Vulnerability Assessment 미리보기를 공개했다.

에이전트가 작업을 끝냈다고 실행환경까지 깨끗해졌다는 뜻은 아니다. 로그, 임시 파일, 오류 출력에 민감한 값이 남을 수 있다. 나는 작업이 끝나는 순간을 단순한 삭제 시점이 아니라 점검 시점으로 보고 싶다. 짧은 권한을 발급하고, 출력과 파일을 검사하고, 토큰을 폐기한 뒤 환경을 없애는 순서가 필요하다. 이 과정에서 이상이 발견되면 자동으로 다음 단계로 넘어가지 않고 사람이 멈출 수 있어야 한다.

공개된 장부가 상대방의 신원까지 보증하지는 않는다

미국 재무부의 7월 29일 발표에 따르면 제재 대상이 된 이란의 디지털 해상보험 서비스 Hormuz Safe는 비트코인과 다른 디지털자산을 결제수단으로 받았다. 재무부는 이를 서방 제재를 우회하려는 구조의 일부라고 설명했다.

나는 블록체인 기술에 관심이 있지만, 거래가 공개된다는 사실과 상대방이 안전하다는 판단을 같은 말로 쓰고 싶지 않다. 주소와 금액이 보이더라도 실제 지배자와 거래 목적을 자동으로 알 수 있는 것은 아니다. 언젠가 HaruSpace에 지갑 연결이나 자산 기능을 넣게 되더라도 먼저 필요한 것은 거래 버튼이 아니라 위험 주소 확인, 거래 보류, 사람의 검토와 책임 기록일 것이다.

오늘 내가 남긴 다섯 가지 질문

오늘 자료를 제품 계획으로 옮기면 새로운 기능 목록보다 다음 질문이 먼저다.

이 모델과 도구를 사용할 수 있는 사람은 누구인가.
자동화에 건네는 권한은 어디까지이며 언제 끝나는가.
작업이 끝난 뒤 로그와 파일에 무엇이 남는가.
모델이 종료돼도 같은 업무를 이어갈 수 있는가.
외부 공개와 중요한 실행을 마지막으로 승인하는 사람은 누구인가.

AI 도구는 앞으로도 빠르게 바뀔 것이다. 나는 그 속도를 모두 따라잡기보다 바뀌어도 지켜야 할 경계를 먼저 만들고 싶다. 모델은 사라질 수 있고 토큰은 폐기해야 하지만, 누가 결정했고 어디서 멈출 수 있는지를 기록하는 구조는 오래 남는다.

오늘 내 결론은 단순하다. 새로운 AI 기능 하나를 더 붙이기 전에, 그 기능을 끄고 바꾸고 책임질 방법부터 만들겠다.