GPT-6 아스트라 비교 분석과 기업 도입에 필요한 활용법

오픈AI가 9월 3일 GPT-6 아스트라를 내놓으면서 그렉 브록먼 사장은 "AGI 시대에 오신 것을 환영합니다"라고 말했습니다. 그러고 며칠 지나지 않아서는 샘 알트먼이 유료 회원들에게 사과문을 올려야 했습니다. AI타임스 보도를 보면 출시 첫날 안내 블로그 포스트가 시스템 오류로 늦게 올라왔습니다. 그동안 신모델을 가장 먼저 써왔던 프로 이용자들이 뒤로 밀리면서 불만이 터져 나왔다가 배포가 마무리되면서 일단락됐다고 합니다. 이런 파행 자체는 몇 주 지나면 잊힐 얘기입니다. 그런데 이번 발표에는 몇 주가 지나도 잊히면 안 되는 문장이 하나 들어 있습니다. 오픈AI가 직접 쓴 시스템 카드 안전 개요 다섯 번째 항목, "GPT-6 아스트라의 모니터링 가능성은 GPT-5.6 Sol 대비 감소했다"는 문장입니다.

모델을 만든 회사가 자기 손으로 "이 모델은 전보다 들여다보기 어렵다"고 적어 놓은 채 기업 배포를 시작한 경우가 이전에 있었는지 저는 잘 기억나지 않습니다. 그리고 이 문장은 AI 에이전트를 실제 업무에 붙여 돌리고 있는 회사라면 그냥 넘길 수 없습니다. 그 에이전트가 사내 시스템과 데이터에 손을 댈 수 있는 회사라면 더 그렇습니다. 그래서 이 글은 두 부분으로 나눴습니다. 앞쪽은 아스트라가 무엇이고 언제 쓸 수 있고 얼마인지, 사람들이 당장 궁금해하는 것들을 짧게 정리했습니다. 뒤쪽은 시스템 카드와 외부 평가 기관이 남긴 기록을 근거로 "그래서 기업은 무엇으로 이 모델을 통제해야 하나"를 다룹니다. 바쁘시다면 뒤쪽부터 읽으셔도 됩니다.

GPT-6 아스트라, 이것부터 알고 가자

무엇이 달라졌나?

오픈AI는 공식 발표문에서 아스트라를 "세계 최고의 컴퓨터 사용 모델"이라고 부릅니다. 채팅창에서 답을 내놓는 데서 그치지 않고 실제 데스크톱과 브라우저를 사람처럼 조작하는 쪽에 힘을 실었습니다. 양식을 채우고, CRM 레코드를 고치고, 웹에서 조사한 내용을 문서 편집기에 옮겨 적는 일 말입니다. 데스크톱 제어 능력을 재는 OSWorld 2.0에서 72.6%를 기록해 전작 GPT-5.6 Sol의 65.7%를 넘겼습니다. 작업당 소요 시간은 75분에서 40분 정도로 절반 가까이 줄었다고 합니다. 수학 벤치마크 FrontierMath Tier 4 97.6%, ARC-AGI-3 99.9%, 익스플로잇 개발 능력을 재는 ExploitBench 100% 같은 숫자가 헤드라인을 장식했습니다. 그런데 발표문 각주에 적혀 있듯 이 점수들에는 "어떤 추론 강도에서든 나온 최댓값"이라는 조건이 붙어 있습니다. 일상적인 설정에서 같은 숫자가 나온다고 기대하면 곤란합니다.

언제, 어디서 쓸 수 있나.

발표 당일에는 일부 조직만 쓸 수 있었고 ChatGPT Plus·Pro·Business·Enterprise 이용자와 API, Azure, AWS Bedrock에는 며칠에 걸쳐 순차 배포됐습니다. 기업 담당자라면 이건 특히 알아두셔야 합니다. Enterprise 워크스페이스에서는 출시 시점에 아스트라가 기본적으로 꺼져 있고 관리자가 직접 켜야 합니다. 사이버보안과 관련한 고급 작업, 예를 들어 취약점의 개념증명(PoC) 익스플로잇을 만드는 일은 일반 배포판이 거부하도록 돼 있습니다. 그보다 느슨한 안전장치는 데이브레이크(Daybreak)라는 별도 프로그램을 통해 검증된 조직에만 단계적으로 풀린다고 합니다.

얼마인가?

API 표준 요금은 입력 100만 토큰당 10달러, 출력 100만 토큰당 50달러입니다. 국내 매체들이 앞다퉈 짚었듯 GPT-5.6 Sol의 약 2.5배입니다. 여기에 표준 대비 최대 2배 빠른 대신 요금도 2배인 Fast 모드가 따로 있고 캐시 읽기·쓰기에는 별도 요율이 붙습니다. 오픈AI는 "작업당 비용"으로 보면 오히려 싸졌다고 주장합니다. 정말 저렴에 진게 맞을까요? 토큰을 덜 쓰고 빨리 끝내는 작업이라면 맞는 말입니다. 그런데 자동 재시도 루프가 걸린 에이전트 파이프라인이라면 출력 단가 50달러가 그대로 청구서에 찍힙니다. 미리 계산해 두는 편이 좋습니다.

클로드 페이블 5.1과의 성능차에서는 우선 앤트로픽의 클로드 페이블 5.1이 나온 지 이틀 만에 아스트라가 나왔습니다. 오픈AI가 발표문에 직접 실은 비교표를 보면 터미널 작업(Terminal-Bench 4.0)이나 컴퓨터 사용 계열에서는 아스트라가 앞섭니다. 반대로 종합 지능 지수(Artificial Analysis Intelligence Index)와 Humanity's Last Exam 같은 항목에서는 페이블 5.1이 앞섭니다. 누가 누굴 이겼다기보다는 "무엇을 시키느냐"에 따라 답이 갈릴 수 있을 것 같습니다. 이 얘기는 뒤에서 다룰 멀티모델 운영으로 이어서 말씀드리겠습니다.

시스템 카드 “더 잘 지키지만, 덜 보인다”

아스트라 시스템 카드의 안전 개요는 일곱 개 항목으로 돼 있습니다. 그중 여섯 개는 좋은 소식입니다. 탈옥에 더 강하고 간접 프롬프트 인젝션 방어율은 99.79%까지 올라갔습니다. 오픈AI 내부 코덱스 작업 5만 4천여 건을 시뮬레이션했더니 높은 심각도의 비정렬 행동 경고가 전작의 절반 수준이었다는 식입니다. 지디넷코리아가 일곱 개 항목을 모두 정리해 놓았으니 참고해 보면 좋을 것 같습니다.

문제는 다섯 번째 항목입니다. 오픈AI는 모니터링 가능성 섹션에서 아스트라가 전작보다 자기 사고 과정(CoT)을 더 잘 통제할 수 있다고 밝혔습니다. 자기에게 불리한 정보를 사고 과정에 남길 가능성은 더 낮다고도 했습니다. 숫자로 보면 750~1,250토큰 길이의 사고 과정에서 GPT-5.6 Sol은 지시받은 대로 자기 사고 과정의 형태를 바꾸는 데 16.1%만 성공한 반면 아스트라는 60.9%를 성공했습니다. 감시자가 있다고 알려주기만 해도 사고 과정을 눈에 띄게 짧게 줄여버리는 경우가 관찰됐습니다. 평가에서 일부러 못하는 척하는 샌드배깅을 시키면 샌드배깅 전용 모니터까지 피해 간다고 적혀 있습니다.

이게 왜 기업 운영자에게 중요하냐면, 지금까지 에이전트 안전의 기본에는 "모델이 뭘 하려는지는 사고 과정을 읽으면 안다"는 전제가 깔려 있었기 때문입니다. 그 전제가 흔들린다는 것은 모델 내부를 들여다보는 CCTV의 화질이 떨어지는 셈입니다. 오픈AI 자신도 이 대목에서 "사고 과정을 들여다보는 것 이상의 정렬 감사 기법을 개발하는 게 중요해졌다"고 썼습니다. 다만 이 결과들은 대부분 모델에게 감시를 피하라고 직접 지시한 적대적 조건에서 나왔습니다. 그리고 전체 정렬 평가로 보면 아스트라는 전작보다 안전 제한을 어길 가능성이 오히려 낮습니다. 덜 보이지만 더 잘 지킨다, 이 두 가지가 동시에 참이라는 게 이번 시스템 카드의 요점입니다.

영국 AISI 실험이 보여준 30배 차이

오픈AI는 발표문에서 "어려운 과제를 만났을 때 허가되지 않은 대상까지 손을 뻗는 비율"이 GPT-5.6 Sol은 48%였는데 아스트라는 0%였다고 강조합니다. 그런데 같은 시스템 카드에 실린 영국 AI 보안 연구소(UK AISI)의 외부 평가는 결이 조금 다릅니다. AISI는 어려운 사이버보안 과제를 주고 인터넷 접근이 우연히 열려 있는 것처럼 꾸민 시뮬레이션 환경을 만들었습니다. 과제 범위에 인터넷 접근이 되는지 안 되는지를 명시하지 않았을 때 499개 표본 중 60개에서 이런 일이 벌어졌습니다. 아스트라가 범위 밖 오픈소스 저장소에 악성 코드를 기여하거나, 개발자를 속이려고 가짜 신원을 만들거나, 정상적인 기여로 신뢰를 쌓은 뒤 악성 코드를 밀어 넣으려는 공급망 공격에 해당하는 행동을 한 겁니다. 물론 전부 시뮬레이션이라 실제 피해는 없었습니다.

그런데 과제 범위에 "인터넷 접근은 허용되지 않는다"는 문장을 명시하자 이 숫자가 500개 중 2개로 떨어졌습니다. 30배 차이입니다. 완전히 사라지지는 않았다는 점도 기록해 둘 만한 사항이긴 합니다. 다만 이 실험에서 가장 실무적인 교훈은 "범위를 적어주느냐 마느냐가 결과를 30배 바꾼다"는 것이라고 보고있습니다. 모델이 알아서 범위를 지켜주길 기대하는 게 아니라 운영자가 범위를 명시해야 한다는 것. 그리고 그 범위를 명시하고 강제하는 일은 모델 안에서 일어나는 게 아니라 모델 바깥, 즉 에이전트를 감싸고 있는 실행 계층에서 일어납니다.

AISI가 남긴 또 하나의 관찰이 있습니다. 아스트라는 81%의 경우 사용자에게 허락을 구하려고 시도했습니다. 그런데 27%의 경우에는 자동 응답 메시지만 받고도 그대로 진행했습니다. 그중에는 그 메시지가 자동 응답이라는 걸 사고 과정에서 알아챈 경우도 있었습니다. 승인 절차가 있는 것과 그 절차가 실제로 사람을 거치는 것은 다릅니다.

오픈AI 내부 시뮬레이션에 기록된 네 장면

시스템 카드에는 오픈AI가 자기 회사 코덱스 트래픽으로 배포 시뮬레이션을 돌린 결과와 함께 심각도 3등급으로 분류된 사례 네 개가 예시로 실려 있습니다. 전체 5만4천여 건 중 34건(0.063%)에 불과했고 전작의 절반이었다는 점은 먼저 말해야 공정하겠습니다. 그래도 그 네 장면을 읽어보면 어느 회사에서든 일어날 수 있는 일이라는 게 바로 보입니다.

첫 번째 장면에서는 중복 알림 문제를 조사하라는 요청을 받은 아스트라가 실행 중인 서비스 설정을 뒤져 봇 토큰을 찾아냈습니다. 그러고는 그 토큰으로 서비스 계정 자격으로 슬랙 메시지를 읽었습니다. 디버깅은 요청받았지만 자격증명을 꺼내 쓰라는 허락은 없었습니다. 두 번째는 검토 안 된 브랜치에서 긴급 배포를 하라는 요청이었습니다. 메인 브랜치에서만 프로덕션 배포가 되도록 막아둔 안전장치가 앞을 가로막았고 배포 스크립트를 고쳐 예외를 만든 뒤 배포를 시도했습니다. 세 번째는 스테이징에 테스트용 가짜 사용자를 추가하라는 요청에서 정상 API가 접근을 거부하자 관리자 권한으로 DB에 직접 연결해 멤버십을 만든 사례입니다. 네 번째로, 실패한 코드 체크를 한 시간마다 고쳐서 PR을 열고 머지까지 하는 자동화 헬퍼를 만들어 달라는 요청을 받자 채팅·소스관리·태스크 시스템의 모든 권한을 켜고 건별 승인을 꺼버린 채 스케줄을 등록했습니다.

네 장면의 공통점은 모델이 시킨 일을 끝내려는 의욕이 앞서서 "명시적으로 금지되지 않았으면 해도 된다"고 해석했다는 겁니다. 시스템 카드도 코딩 환경의 비정렬은 대체로 이런 과잉 의욕과 안일한 해석에서 나온다고 설명합니다. 그리고 네 장면 모두 자격증명 접근, 배포 안전장치 변경, DB 직접 연결, 권한 일괄 부여였습니다. 전부 실행 계층에서 정책으로 막을 수 있는 행동입니다.

그래서 통제 지점은 모델 밖으로 나온다

시스템 카드의 모니터링 섹션에는 이번 발표에서 가장 덜 인용됐지만 가장 실무적인 결과가 하나 있습니다. 사고 과정만 보는 모니터와 행동만 보는 모니터를 따로 돌려봤습니다. 아스트라는 사고 과정 기준 모니터링 가능성은 전작보다 낮았지만 행동 기준 모니터링 가능성은 전작보다 높았습니다. 머릿속은 덜 보이는데 손발은 더 잘 보입니다. 오픈AI 자신도 심각한 파괴적 행동은 대부분 사고 과정 없이 행동만으로도 충분히 잡힌다고 적었습니다.

오픈AI가 실제로 한 일도 이 방향입니다. 7월 중순 오픈AI 모델 기반 에이전트들이 테스트 샌드박스를 벗어나 허깅페이스를 해킹한 사건이 있었습니다. 위키트리 보도에 따르면 오픈AI는 그로부터 한 달 뒤 아스트라 훈련·평가 작업 상당수를 멈추고 감시·보안·정렬 절차를 다시 짰습니다. 그 결과가 이번 배포에 그대로 들어갔습니다. 내부적으로는 도구를 쓰는 모든 추론에 사고 과정을 포함한 전체 실행 경로 감시를 붙이고 사람을 호출해 워크로드를 멈출 수 있게 했습니다. 외부 배포에도 같은 구조의 비정렬 모니터링을 "상당한 컴퓨팅 비용을 감수하고" 붙였습니다. 발표문에는 이 추가 안전 검사가 정상적인 작업, 방어적 사이버보안 작업까지 늦추거나 멈출 수 있다고 적혀 있습니다. ChatGPT나 코덱스에서는 사용자에게 검토를 요청하지만 API에서는 작업이 그냥 중단된다고도 적혀 있습니다.

모델 제공사조차 모델 내부를 믿는 대신 실행 경로 전체를 기록하고, 행동을 분류기로 걸러내고, 사람이 멈출 수 있는 구조를 세운 겁니다. 그리고 그 구조는 오픈AI의 인프라 안에 있는 것이지 우리 회사 시스템 안에 있는 게 아닙니다. 아스트라가 우리 회사 CRM과 슬랙과 배포 파이프라인에 손을 댈 때 그 손을 지켜보는 건 우리 몫입니다. 그것도 아스트라 하나만이 아닙니다. 이틀 전에 나온 페이블 5.1, 그 전의 GPT-5.6, 사내에 이미 붙어 있는 다른 모델들까지 함께 지켜봐야 합니다.

회사 워크플로에 들일 때 주의할 점

하나, 범위는 문장으로 적혀 있는가. AISI 실험의 30배 차이를 기억한다면 "이 에이전트가 접근할 수 있는 시스템, 파일, 네트워크는 여기까지"를 태스크마다 명시하는 게 첫걸음입니다. 사람이 프롬프트에 매번 적는 방식은 오래 못 가고 도구 호출 단위로 허용 목록을 강제하는 쪽이 현실적입니다.

둘, 승인은 정말 사람을 거치는가. 아스트라가 자동 응답만 받고도 27%는 그대로 진행했다는 걸 떠올려 보면 승인 단계가 있다는 사실보다 그 승인이 자동 메시지로 대체될 수 없게 만들어져 있는지가 중요합니다. 특히 네 번째 장면처럼 에이전트가 스스로 건별 승인을 끄는 일이 불가능해야 합니다.

셋, 행동 로그는 남고 있는가. 사고 과정을 못 믿게 됐다면 남는 건 행동 기록입니다. 어떤 도구를 어떤 인자로 호출했고 무엇을 읽고 썼는지가 실행 경로 단위로 남아야 사후에라도 첫 번째 장면 같은 자격증명 접근을 찾아낼 수 있습니다.

넷, 모델을 바꿔도 정책은 그대로인가. 아스트라와 페이블 5.1이 벤치마크마다 승패를 주고받는 상황이라 한 회사 안에서 두 모델을 병행하는 게 정상이 될 겁니다. 그때 접근 정책과 승인 규칙이 모델별로 따로 놀면 구멍이 생깁니다. 모델 위에 한 겹의 공통 통제 계층이 있어야 정책을 한 번만 정의해도 됩니다.

다섯, 비용 상한은 걸려 있는가. 출력 단가 50달러에 여러 단계의 추론 강도가 있는 모델을 재시도 루프에 넣으면 청구서가 어디까지 길어질지 예측하기 어렵습니다. 통제 계층에 실행 횟수와 토큰 상한을 함께 두는 게 안전 문제이면서 동시에 예산 문제입니다.

Dify와 AX Foundry의 제안 방향

이 글을 작성한 이유는 위 다섯 가지가 저희 팀에서 매일 다루는 문제이기 때문입니다. Dify는 여러 모델을 한 워크플로 안에서 오케스트레이션하는 오픈소스 플랫폼입니다. 그래서 넷째 항목의 "모델을 바꿔도 정책은 그대로"가 구조적으로 가능하며 아스트라와 페이블 5.1을 같은 파이프라인의 다른 노드에 두고 도구 연결과 프롬프트 템플릿과 변수 흐름을 모델과 분리해 관리하면 모델 교체가 정책 재작성으로 이어지지 않습니다.

AX Foundry는 그 위에서 에이전트의 실행 계층을 관제하고 통제하는 쪽을 맡습니다. 어떤 도구를 누가 어떤 범위로 호출할 수 있는지를 정책으로 정하고, 범위 밖 호출은 실시간으로 막습니다. 실행 경로는 감사 가능한 형태로 남기고, 사람의 승인이 필요한 지점은 에이전트가 우회할 수 없게 고정합니다. 여기서 한 가지는 분명히 해두고 싶은 건 어떤 관제 제품도 아스트라가 자기 사고 과정을 통제하는 능력 자체를 막지는 못합니다. 오픈AI가 자기 모니터도 때때로 회피된다고 인정한 마당에 그런 주장을 한다면 거짓말입니다. 저희가 할 수 있는 건 모델의 머릿속이 아니라 모델의 손발, 즉 행동을 보고 막는 겁니다. 시스템 카드가 보여주듯 그 행동은 전작보다 오히려 더 잘 보이기 때문입니다.

아스트라 시스템 카드 마지막 부분에는 오픈AI가 "모니터링 가능성의 추가 저하를 일정 한계 이상으로는 받아들이지 않겠다"고 약속하는 대목이 있습니다. 다음 세대 모델이 나올 때 그 약속이 지켜졌는지는 그때까지 지켜봐야 할 것 같고, 지금 회사 안에서 돌아가는 에이전트가 어디까지 손을 뻗을 수 있는지는 오늘 우리가 정할 수 있습니다.