GPT-5.6와 ChatGPT Work: 프로덕션 등급 에이전트 제어 플레인 설계

서론

2026년 7월 출시된 GPT-5.6은 단순히 또 하나의 모델 출시로 읽힐 수 있습니다. Sol이 플래그십 경로, Terra가 균형 옵션, Luna가 더 빠르고 저렴한 계층입니다. 공식 출시에는 코딩, 전문 업무, 과학, 컴퓨터 사용, 보안 전반에 걸친 광범위한 평가가 포함되어 있습니다.

이러한 해석은 정확하지만 불완전합니다.

GPT-5.6을 이해하는 더 유용한 방식은 운영적인 측면입니다. OpenAI는 이전에 에이전트 빌더들이 커스텀 오케스트레이션 코드 내에 숨겨야 했던 여러 결정 사항을 공개했습니다: 얼마나 많은 추론을 할당할지, 언제 병렬 에이전트를 사용할지, 모든 중간 결과를 모델에 반환하지 않고 도구를 조정하는 방법, 그리고 모델 역량을 작업의 가치와 위험에 매칭하는 방법 등입니다.

동시에 ChatGPT Work는 Codex와 관련된 장기 실행 작업 모델을 문서, 스프레드시트, 슬라이드, 웹사이트, 연결된 애플리케이션, 브라우저 동작, 컴퓨터 사용, 예약된 작업을 포함하는 더 넓은 작업 공간으로 확장합니다.

이러한 기능은 더 큰 엔지니어링 책임을 수반합니다. 더 강력한 모델에 더 많은 도구를 제공하는 것이 자동으로 신뢰할 수 있는 디지털 워커를 만드는 것은 아닙니다. 더 오랜 시간 동안, 더 넓은 데이터 범위에서 작동하고 더 중요한 변경을 수행할 수 있는 시스템이 생성됩니다.

프로덕션 설계는 실행이 시작되기 전에 여러 질문에 답해야 합니다:

• 누가 작업을 승인했는가?
• 에이전트가 읽을 수 있는 것은 무엇인가?
• 변경할 수 있는 것은 무엇인가?
• 어떤 작업에 승인이 필요한가?
• 얼마나 많은 시간과 비용을 사용할 수 있는가?
• 결과가 정확하다는 증거는 무엇인가?
• 문제 발생 시 팀은 워크플로를 어떻게 중단하거나 복구하는가?

이 가이드는 GPT-5.6, ChatGPT Work, Codex 또는 커스텀 에이전트로 구축하는 팀을 위한 제어 플레인 접근법을 제시합니다. 모델 역량을 운영 권한과 분리하고 구체적인 시나리오, 라우팅 규칙, 평가 지침, 재사용 가능한 정책 템플릿을 제공합니다.

주요 시사점

• GPT-5.6은 역량 및 컴퓨트 메뉴로 취급하는 것이 가장 좋습니다. Sol, Terra, Luna는 모델 경로이며, 추론 노력과 멀티 에이전트 실행은 별도의 예산 제어 항목입니다.
• ChatGPT Work는 위임 단위를 단일 답변에서 파일, 연결된 앱, 브라우저 작업, 컴퓨터 사용, 예약된 작업을 포괄하는 완료된 결과물로 변경합니다.
• 프로덕션 에이전트는 모델 주변에 제어 플레인이 필요합니다: 작업 분류, 범위가 지정된 ID, 도구 정책, 승인 게이트, 관찰 가능성, 평가, 예산, 복구.
• 공개 벤치마크는 후보 모델 발견에 유용하지만, 프로덕션 배포 결정에는 프라이빗 작업 세트가 필수적입니다.
• 팀은 되돌릴 수 있고 검토 가능한 워크플로로 시작하여 증거를 수집한 후에만 자율성을 확장해야 합니다.

GPT-5.6에서 실제로 변경된 사항

GPT-5.6은 ChatGPT, Codex 및 API에서 세 가지 역량 계층을 제공합니다:

• Sol: 최고 역량 경로
• Terra: 일상 작업을 위한 균형 경로
• Luna: 가장 빠르고 경제적인 경로

OpenAI는 이러한 이름을 임시적인 날짜 스탬프 모델명이 아닌 지속적인 역량 계층으로 설명합니다. 이러한 구분은 프로덕션 시스템에 유용합니다.

다음과 같은 정책을 사용하면 향후 스냅샷 변경에도 안정적으로 대응할 수 있습니다: "일상적인 리포지토리 유지보수에는 Balanced 티어를 사용하세요". 재현 가능성이 중요한 경우, 팀은 정확한 스냅샷을 별도로 고정할 수 있습니다. 이 방법은 모델 ID를 프롬프트, 스크립트, 작업 큐, 환경 변수 등에 분산시키는 방식보다 더 깔끔합니다.

추론 노력과 멀티 에이전트 실행

GPT-5.6은 또한 더 명시적인 컴퓨팅 제어 기능을 추가했습니다.

max는 하나의 모델 경로가 추론, 대안 탐색, 검증, 작업 수정에 더 많은 시간을 사용할 수 있게 합니다. ultra는 여러 에이전트가 병렬 작업 스트림에서 협력하도록 조정합니다.

이는 서로 다른 제어 방식입니다:

• 더 많은 추론은 하나의 경로가 더 오랫동안 조사하고 검증할 수 있게 합니다.
• 멀티 에이전트 실행은 동시 작업 스트림에 추가 컴퓨팅을 투입한 후 결과를 종합합니다.

작업에 따라 하나, 둘 다, 또는 아무것도 필요하지 않을 수 있습니다. 특히 하위 작업이 동일한 불확실한 가정을 공유하거나 동일한 제한된 자격 증명을 필요로 하는 경우, 병렬 실행이 항상 더 나은 것은 아닙니다.

프로그래매틱 툴 호출

OpenAI는 프로그래매틱 툴 호출을 모델이 도구를 조정하고, 중간 결과를 처리하며, 어떤 정보를 모델에 반환해야 하는지 결정하는 경량 프로그램을 작성하고 실행하는 방법이라고 설명합니다.

이를 통해 반복적인 컨텍스트 전송을 줄일 수 있습니다. 모든 데이터베이스 행, 브라우저 응답, 도구 결과를 모델에 반환하는 대신, 메모리 내 프로그램이 먼저 데이터를 필터링하고 집계할 수 있습니다.

이러한 효율성에는 운영상의 절충이 따릅니다. 더 많은 로직이 실행 계층으로 이동하므로, 팀은 이러한 중간 단계에 대한 명확한 추적, 제한, 데이터 처리 규칙이 필요합니다.

GPT-5.6 릴리스는 또한 Responses API에 멀티 에이전트 베타를 도입합니다. 따라서 병렬 실행은 애플리케이션 수준의 오케스트레이션 패턴뿐만 아니라 API 수준의 기능이 되고 있습니다.

가격은 라우팅 입력입니다

출시 시점의 공식 가격은 다음과 같습니다:

경로	입력 100만 토큰당 가격	출력 100만 토큰당 가격
GPT-5.6 Sol	$5.00	$30.00
GPT-5.6 Terra	$2.50	$15.00
GPT-5.6 Luna	$1.00	$6.00

이 가격은 라우팅 결정의 입력일 뿐, 결정 자체는 아닙니다.

더 저렴한 모델이 반복적으로 재시도하거나, 불필요한 컨텍스트를 읽거나, 검토자가 거부하는 작업을 생성하는 경우 승인된 결과당 비용이 더 많이 들 수 있습니다. 더 강력한 모델이 한 번에 작고 검증된 변경으로 작업을 완료한다면 실제로는 더 저렴할 수 있습니다.

올바른 지표는 단순히 토큰당 비용이 아닙니다. 승인된 결과당 비용이 중요합니다.

ChatGPT Work가 위임의 단위를 바꿉니다

ChatGPT Work는 애플리케이션과 파일을 넘나들며 작업하고, 몇 시간 동안 지속되며, 목표를 더 작은 단계로 나누고, 완성된 결과물을 생성할 수 있는 에이전트로 제시됩니다.

OpenAI는 Codex 기술이 제품에 내장되어 있다고 말하지만, 대상은 소프트웨어 엔지니어링보다 더 넓습니다. 예시 작업 흐름은 다음과 같습니다:

• 예산 분석
• 캠페인 브리프
• 리드 검토
• 제품 출시 점검
• 경쟁사 조사
• 문서
• 스프레드시트
• 프레젠테이션
• 웹사이트

중요한 변화는 위임의 단위입니다.

일반적인 채팅 턴은 답변을 요청합니다. Work 작업은 결과물을 요청합니다.

그 결과물을 위해 시스템은 다음을 수행해야 할 수 있습니다:

1. 여러 출처를 읽습니다.
2. 새로운 정보가 나타나면 방향을 전환합니다.

정보가 나타납니다.
3. 여러 개의 아티팩트를 생성합니다.
4. 사람의 승인을 기다립니다.
5. 사용자가 자리를 비운 동안 예약된 작업을 통해 계속 진행합니다.
6. 연결된 앱, 임베디드 브라우저 또는 데스크톱 컴퓨터를 사용합니다.

OpenAI는 또한 제품 표면을 통합하고 있습니다. Chat, Work 및 Codex는 업데이트된 데스크톱 환경에서 사용할 수 있으며, 브라우저 기능은 더 넓은 제품 환경으로 이동하고 있습니다.

이를 통해 로컬 파일, 웹 페이지, 연결된 서비스, 브라우저 작업 및 장기 실행 작업을 포괄하는 하나의 권한 경계가 생성됩니다.

따라서 엔터프라이즈 제어는 인터페이스만큼 중요합니다. 관리자 커넥터 관리, 규정 준수 기능 및 검토 메커니즘은 모두 동일한 문제를 지적합니다. 에이전트는 올바른 신원, 필요한 최소한의 컨텍스트, 가시적인 효과 및 복구 경로를 가지고 작동해야 합니다.

팀이 ChatGPT Work를 직접 사용하지 않고 사용자 정의 API 에이전트를 구축하더라도 Work는 유용한 참조 운영 모델입니다. 이는 어시스턴트가 지속적인 작업자가 될 때 나타나는 문제점을 드러냅니다.

• 상태
• 도구 신원
• 승인
• 스케줄링
• 아티팩트
• 거버넌스

이해해야 할 용어: 모델, 하네스, 에이전트, 제어 평면

모델

모델은 입력 컨텍스트를 출력 및 도구 결정에 매핑합니다. 여기에는 기능, 제한 사항, 가격, 지연 시간 및 안전 동작이 있습니다.

Sol, Terra 및 Luna는 모델 계층입니다. 모델 자체는 조직의 권한을 결정하지 않습니다.

에이전트 하네스

에이전트 하네스는 모델을 둘러싼 소프트웨어입니다. 컨텍스트를 선택하고, 도구를 노출하며, 명령을 실행하고, 상태를 저장하며, 실패를 재시도하고, 실행이 완료된 시점을 결정합니다.

모델과 작업이 동일하게 유지되더라도 하네스를 변경하면 비용과 안정성이 크게 달라질 수 있습니다. 큰 컨텍스트 창을 반복적으로 전송하는 하네스는 중간 결과를 필터링하는 하네스보다 훨씬 더 많은 비용이 들 수 있습니다.

따라서 "모델 성능"은 하네스도 함께 지정되지 않으면 불완전합니다.

에이전트

에이전트는 다음을 결합합니다:

• 모델
• 목표
• 도구
• 상태
• 하네스

에이전트는 여러 단계를 수행하고 도구 결과에 반응할 수 있습니다. 장기 실행 에이전트는 하위 작업 또는 하위 에이전트를 생성할 수 있지만, 병렬 작업자가 자동으로 안전한 멀티 에이전트 시스템을 형성하지는 않습니다. 이들은 여전히 예산, 권한 및 최종 승인 결정을 공유합니다.

제어 평면

제어 평면은 에이전트 실행을 관리하는 정책 및 운영 계층입니다.

이는 다음을 수행합니다:

• 작업 분류
• 경로 선택
• 범위가 지정된 자격 증명 발급
• 승인 적용
• 추적 기록
• 결과 평가
• 작업 중단
• 작업 롤백

실행 평면은 작업을 수행합니다. 이 둘을 분리하면 팀이 프로덕션 코드를 배포하거나 외부 메시지를 보낼 수 있는 사람을 변경하지 않고도 모델을 변경할 수 있습니다.

승인 게이트

승인 게이트는 권한이 있는 사람이나 결정적인 정책 없이는 에이전트가 통과할 수 없는 의사 결정 지점입니다.

승인은 특정 조치와 그 증거에 첨부되어야 합니다.

유용한 승인 요청은 다음과 같습니다.

이 최종 이메일을 첨부된 수신자 목록과 승인된 콘텐츠를 사용하여 이 412명의 수신자에게 보내는 것을 승인합니다.

취약한 승인 요청은 다음과 같습니다.

마케팅 작업을 승인합니다.

승인 테스트

승인 테스트는

요청된 결과가 완료되었습니다.

다음과 같은 경우일 수 있습니다:

• 단위 테스트
• 스키마 검증
• 렌더링된 문서 검토
• 조정 합계
• 인간 평가 기준표
• 보안 검사
• 코드 소유자 승인

모델이 "완료"라고 말하는 것은 상태 주장일 뿐, 수락 테스트가 아닙니다.

프로덕션 에이전트 제어 평면

유용한 프로덕션 제어 평면에는 8가지 책임이 있습니다.

1. 작업 분류

분류는 다음을 포함해야 합니다:

• 도메인
• 영향
• 되돌릴 수 있는 정도
• 데이터 민감도
• 모호성
• 예상 가치
• 검증 강도

"FAQ 초안 업데이트"와 "인증 정책 변경"은 모두 텍스트 편집을 포함할 수 있지만, 서로 다른 경로에 속합니다.

2. 모델 및 노력 예산 선택

가장 저렴한 적격 경로가 합리적인 기본값이지만, 적격성은 가격보다 우선해야 합니다.

예시:

• 저위험 추출에는 Luna
• 강력한 소스 확인이 필요한 중간 수준 분석에는 Terra
• 아키텍처 검토, 보안 검토 또는 어려운 저장소 진단에는 Sol
• 작업이 명확하게 분해되고 추가 병렬 비용이 정당화되는 경우에만 Ultra

3. 범위가 지정된 실행 ID 생성

에이전트는 작업에 필요한 정확한 저장소, 폴더, 애플리케이션 또는 레코드에 대한 단기 자격 증명을 받아야 합니다.

단순히 편리하다는 이유로 개발자의 전체 브라우저 세션을 상속받아서는 안 됩니다.

실행 ID는 로그에 표시되어 팀이 모든 외부 작업을 추적할 수 있어야 합니다.

4. 도구 정책 적용

이는 별개의 기능입니다:

• 읽기
• 쓰기
• 보내기
• 구매
• 삭제
• 배포
• 권한 변경

사서함을 검색할 수 있는 커넥터가 자동으로 이메일을 보낼 수 있어서는 안 됩니다. 저장소를 검사할 수 있는 GitHub 통합이 자동으로 풀 리퀘스트를 병합할 수 있어서는 안 됩니다.

5. 승인 및 결정론적 검사 시행

승인 게이트는 중요한 조치 직전에 나타나야 하며, 효과와 증거에 대한 간결한 미리보기를 보여주어야 합니다.

소프트웨어의 경우 증거에는 다음이 포함될 수 있습니다:

• 차이점
• 단위 테스트
• 유형 검사
• 보안 검사
• 배포 계획

재무의 경우 다음이 포함될 수 있습니다:

• 소스 합계
• 조정
• 수식 검증
• 차이 검사

6. 이벤트 추적 기록

추적에는 다음이 포함되어야 합니다:

• 목표 변경
• 소스 검색
• 도구 호출
• 승인
• 아티팩트
• 오류
• 재시도 이유
• 토큰 사용량
• 경과 시간
• 최종 상태

짧은 요약은 운영에 유용하지만, 사고 검토에는 충분하지 않습니다.

7. 예산 및 중지 조건 시행

유용한 제한 사항은 다음과 같습니다:

• 토큰 예산
• 도구 호출 예산
• 실제 시간 제한
• 재시도 제한
• 금전적 상한
• 파일 수 제한
• 차이 크기 제한

약하거나 반복되는 실행을 중단하는 것은 자율성의 실패가 아닙니다. 이는 정책의 성공적인 적용입니다.

8. 복구 책임

복구에는 다음이 포함될 수 있습니다:

• 파일 복원
• 커밋 되돌리기
• 자격 증명 취소
• 예약된 작업 취소
• 초안 삭제
• 사고 열기

시스템이 실행 전에 복구를 설명할 수 없다면, 해당 작업은 무인 운영에 적합하지 않습니다.

작업 형태별 Sol, Terra, Luna 라우팅

모델 라우팅은 엔지니어, 제품 관리자 및 보안 검토자가 읽을 수 있을 만큼 명확해야 합니다.

다음 표는

시작점이지, 보편적인 순위가 아닙니다.

경로	적합한 작업 형태	요구되는 증거	일반적인 권한
루나	분류, 추출, 포맷팅, 저위험 요약, 제한적 코드 검색	스키마 검증, 샘플 검토, 소스 링크	읽기 전용 또는 초안 전용
테라	일상적인 저장소 변경, 문서 생성, 알려진 워크플로우, 중간 수준 분석	대상 테스트, 아티팩트 검증, 사람의 스팟 체크	범위 제한 쓰기, 되돌릴 수 없는 외부 작업 금지
솔	모호한 진단, 시스템 간 분석, 아키텍처 작업, 보안 검토, 고가치 연구	광범위한 결정론적 검사, 검토자가 볼 수 있는 근거, 소스 출처	명시적 승인이 있는 범위 제한 쓰기
솔 max	더 많은 탐색과 수정이 품질을 향상시킬 수 있는 어려운 단일 스레드 추론	체크포인트, 비용 한도, 최종 검증	솔과 동일한 권한
솔 ultra	독립적인 작업 스트림이 있는 고가치 병렬화 가능 작업	작업 스트림별 증거, 종합 검토, 총 예산 한도	가능한 경우 별도의 범위가 지정된 ID

마지막 열이 가장 중요합니다.

모델의 능력이 권한을 증가시켜서는 안 됩니다.

루나에서 솔로 전환한다고 해서 쓰기 액세스 권한이 조용히 추가되어서는 안 됩니다. 추론 노력을 높인다고 해서 초안이 승인된 외부 메시지로 바뀌어서는 안 됩니다. 울트라는 모두 제한 없는 프로덕션 자격 증명을 공유하는 여러 작업자를 생성해서는 안 됩니다.

증거 기반 에스컬레이션

루나 경로는 다음과 같은 경우 에스컬레이션될 수 있습니다:

• 신뢰도가 임계값 아래로 떨어질 때
• 필수 필드를 추출할 수 없을 때
• 소스가 충돌할 때
• 검증이 실패할 때

테라 코딩 작업은 다음과 같은 경우 에스컬레이션될 수 있습니다:

• 두 번의 제한된 시도 후에도 실패한 테스트가 설명되지 않은 상태로 남아 있을 때
• 변경 사항이 보안 경계를 넘을 때
• diff가 예상 파일 수를 초과할 때

솔 경로는 요구 사항이 충돌하거나 남은 유일한 조치가 되돌릴 수 없는 경우 중단하고 사람에게 물어야 합니다.

다운그레이드도 유용함

솔이 계획을 수립하면 테라나 루나가 좁은 검사 하에 반복적인 하위 작업을 실행할 수 있습니다.

강력한 모델은 모든 항목을 처리하는 대신 샘플을 검토할 수 있습니다. 이는 판단과 볼륨을 분리하여 비용을 크게 줄일 수 있습니다.

권한 아키텍처 및 승인 경계

권한 시스템은 동사로 시작해야 합니다.

읽기
검색
초안 생성
수정
보내기
병합
배포
삭제
구매
액세스 권한 부여

이러한 동사는 서로 다른 결과를 초래합니다.

많은 제품 통합은 여러 작업을 하나의 광범위한 OAuth 범위 뒤에 배치합니다. 따라서 제어 평면은 더 좁은 작업을 노출하는 애플리케이션 측 프록시가 필요할 수 있습니다.

동사와 리소스 바인딩

"Google Drive 읽기"는 많은 워크플로우에 너무 광범위합니다.

더 좁은 규칙은 다음과 같을 수 있습니다:

18:00 UTC까지 Q3 기획 폴더와 승인된 브랜드 템플릿 폴더를 읽습니다.

저장소의 경우 네트워크 액세스가 비활성화된 하나의 작업 트리로 액세스가 제한될 수 있습니다. 데이터베이스의 경우 읽기 복제본이나 관리형 뷰가 일반적으로 프로덕션 자격 증명보다 안전합니다.

조건 추가

예시:

• 이메일 초안은 자동으로 생성될 수 있지만, 보내려면 승인이 필요합니다.
• 풀 리퀘스트는 자동으로 열릴 수 있지만, 병합하려면 녹색 CI와 코드 소유자가 필요합니다.
• 예약된 작업은 대시보드를 새로 고칠 수 있지만,

데이터 소스를 변경하려면 관리자 권한이 필요합니다.

직무 분리 유지

변경을 생성하는 에이전트가 정확성에 대한 유일한 판단자가 되어서는 안 됩니다.

유용한 증거는 다음에서 얻을 수 있습니다:

• 결정론적 테스트 실행기
• 별도의 검토 모델
• 인간 소유자

두 번째 모델이 책임 있는 인간을 대체할 수는 없지만, 조치가 외부로 표출되기 전에 의견 차이를 드러낼 수 있습니다.

공급업체의 보호 장치는 한 계층에 불과합니다. 사용자가 특정 저장소를 테스트할 권한이 있는지, 고객이 변경을 승인했는지, 또는 프로덕션 유지보수 기간이 열려 있는지를 알 수 없습니다.

애플리케이션 권한 부여는 여전히 구축자의 책임입니다.

구체적 시나리오 및 실패 모드

시나리오 1: 릴리스 준비 상태 에이전트

팀이 ChatGPT Work 또는 사용자 정의 에이전트에게 다음을 검토하도록 요청합니다:

• 출시 계획
• Jira 이슈
• 저장소
• 시장 출시 문서

필요한 산출물은 소유자와 차단 요소를 나열한 준비 상태 보고서입니다.

에이전트는 네 가지 소스를 모두 읽고 보고서를 생성할 수 있습니다. 승인 없이 이슈 상태를 편집하거나 소유자에게 메시지를 보낼 수 없습니다.

실패 모드: 오래된 컨텍스트

에이전트가 캐시된 문서를 사용했기 때문에 보고서가 이미 해결된 이슈를 인용합니다.

컨트롤 플레인은 직접 소스 링크와 타임스탬프를 요구해야 합니다.

실패 모드: 거짓 완료

모든 체크리스트 행에 텍스트가 포함되어 있다는 이유로 에이전트가 릴리스 준비가 완료되었다고 선언합니다.

대신 수용 테스트는 모든 차단 종속성에 대해 확인된 소유자, 날짜 및 현재 상태를 요구해야 합니다.

시나리오 2: 코딩 에이전트 종속성 업그레이드

작업은 모노레포 전반에 걸쳐 라이브러리를 업그레이드하는 것입니다.

마이그레이션이 문서화되어 있고 테스트 스위트가 강력하기 때문에 Terra가 시작합니다. 브랜치를 생성하고, 잠금 파일과 영향을 받는 패키지를 편집하며, 대상 검사를 실행합니다.

컴파일러 오류로 인증 모듈에서 문서화되지 않은 API 변경이 드러납니다. 이로 인해 Sol로 에스컬레이션됩니다.

모델은 변경되지만 권한은 변경되지 않습니다.

Sol은 동일한 작업 트리와 배포 토큰을 받지 않습니다. diff가 권한 부여 로직에 영향을 미치는 경우, 정책에 보안 검토 게이트가 추가됩니다.

완료 조건:

• 단위 테스트
• 타입 검사
• 종속성 감사
• 검토자 승인 마이그레이션 노트

작동하는 것처럼 보이지만 이러한 검사를 건너뛰는 패치는 수락되지 않습니다.

시나리오 3: 예약된 고객 피드백 워크플로우

매일 아침 에이전트가 새로운 지원 티켓을 읽고, 주제를 클러스터링하며, 제품 브리프를 업데이트합니다.

Luna는 민감한 필드가 제거된 후 티켓을 분류할 수 있습니다. Terra는 소스 링크가 포함된 브리프 초안을 작성할 수 있습니다.

어느 루트도 다음을 수행할 수 없습니다:

• 티켓 종료
• 기능 약속
• 고객 연락

실패 모드: 점진적 범위 확장

새로운 지시가 에이전트에게 "명백한 응답도 처리하라"고 말합니다.

이로 인해 내부 분석 워크플로우가 외부 커뮤니케이션으로 전환됩니다.

작업 분류기는 새로운 전송 동사를 감지하고 별도의 정책, 승인된 템플릿, 샘플링 계획 및 인간 소유자를 요구해야 합니다.

시나리오 4: 고가치 연구 작업

한 회사가 세 가지 아키텍처 옵션을 평가하고 있습니다.

Sol ultra가 별도의 작업 스트림을 할당합니다:

• 성능
• 보안
• 마이그레이션 비용
• 공급업체 위험

작업 스트림이 독립적이므로 병렬 실행이 정당화됩니다.

독립적이며 결정은 가치 있는 것입니다. 각 작업자는 소스 요구사항과 고정된 예산을 받습니다.

실패 모드: 상관관계가 있는 증거

모든 작업자가 동일한 벤더 벤치마크를 인용하며, 동의하는 것처럼 보입니다.

종합 게이트는 소스 다양성을 측정하고, 공유된 근거 없는 가정을 플래그 지정하며, 각 옵션에 대해 최소 하나의 반대 논거를 요구해야 합니다.

더 많은 에이전트는 커버리지를 개선하는 것만큼이나 쉽게 잘못된 전제를 증폭시킬 수 있습니다.

공개 코딩 벤치마크가 발견 도구인 이유

공개 벤치마크는 유용하지만, 생산 환경 기본값을 직접 결정해서는 안 됩니다.

OpenAI의 SWE-Bench Pro 감사에서는 공개 작업의 상당 부분에 다음과 같은 문제가 있다고 보고했습니다:

• 지나치게 엄격한 테스트
• 불완전한 프롬프트
• 낮은 커버리지 테스트
• 숨겨진 테스트와 일치하지 않는 동작을 유도하는 프롬프트

이것이 모든 공개 벤치마크가 쓸모없다는 의미는 아닙니다.

이는 점수가 데이터셋과 하네스의 측정 오류를 상속받는다는 것을 의미합니다.

공개 평가는 다음에 유용합니다:

• 후보 모델 발견
• 공개된 방법 비교
• 광범위한 기능 변화 식별
• 내부 평가 큐 구축

하지만 특정 모노레포, 비즈니스 워크플로우 또는 데이터 환경에서 모델이 안전한 변경을 수행할지 여부는 답할 수 없습니다.

제어 평면은 각 라우팅 결정과 함께 벤치마크 출처 정보를 저장해야 합니다:

• 데이터셋 버전
• 작업 제외 사항
• 하네스
• 도구 구성
• 추론 노력
• 시도 횟수
• 비용 가정

이러한 세부 정보 없이 벤치마크 점수는 마케팅 표현에 불과해집니다.

실제 작업에서 개인 평가 구축

Databricks는 수백만 줄의 코드베이스 평가에서 유용한 예를 제공합니다.

팀은 실제 사람이 작성한 풀 리퀘스트에서 다음 언어로 작업을 구축했습니다:

• Python
• Go
• TypeScript
• Scala
• Rust
• Java
• Protobuf
• gRPC
• Bazel

의미 있는 테스트가 포함된 최근의 대표적인 변경 사항을 선택하고, 의도를 유지하면서 해결책을 드러내지 않도록 작업 설명을 다시 작성했으며, 각 샘플을 수동으로 검토했습니다.

팀은 초기 설정에서 정보 유출도 발견했습니다. 에이전트가 Git 기록에서 미래 커밋을 복구할 수 있었습니다. 평가 실행 중에는 작업 트리가 저장소 기록과 격리되었습니다.

이 세부 사항은 최종 순위보다 더 중요합니다. 이는 벤치마크가 우연히 엔지니어링 능력 대신 지름길 발견을 측정할 수 있음을 보여줍니다.

더 작은 내부 세트 구축

팀은 30~60개의 작업으로 시작할 수 있습니다.

다음 조건을 만족하는 승인된 과거 변경 사항을 사용하세요:

• 명확한 문제
• 의미 있는 테스트
• 제한된 범위

다음 유형을 혼합하여 포함하세요:

• 일상적인 유지보수
• 버그 진단
• 여러 파일에 걸친 리팩터링
• 프론트엔드 작업
• 구성
• 보안에 민감한 예 1~2개

변경 전 저장소 상태를 보존하고 최종 패치는 숨기세요.

먼저 결정론적 테스트로 평가

사람이나 모델이 판단하기 전에 결정론적 테스트를 먼저 사용하세요.

그런 다음 다음 사항에 대해 수동 검토를 추가하세요:

• 요구사항 충실도
• 차이점 품질
• 유지보수성
• 불필요한 변경

LLM 판단자가 모든 정확성 검사를 대체하지 못하게 하세요. 판단 모델은 논리적으로 들리는 답변에 보상을 줄 수 있습니다.

모델과 하네스를 함께 측정

다음을 기록하세요:

• 성공률
• 총 비용
• 경과 시간
• 전송된 총 컨텍스트
• 도구 호출
• 재시도

변경된 파일

• 검토자 수정 사항
• 롤백 비율

최고의 경로는 팀의 제약 조건 내에서 허용되는 결과물을 만들어내는 경로이지, 공개 점수가 가장 높은 경로가 아닙니다.

재사용 가능한 에이전트 정책 템플릿

다음 YAML은 API 스키마가 아닌 정책 아티팩트입니다. 귀하의 ID 공급자, 작업 큐, 커넥터, 리포지토리 제어 및 감사 시스템에 맞게 조정하십시오.

policy_version: 1
workflow: release_readiness
owner: product-operations

classification:
  impact: medium
  reversibility: high
  data_sensitivity: internal
  ambiguity: medium
  verification: strong

routing:
  default:
    model_tier: terra
    reasoning_effort: medium
  escalate_to_sol_when:
    - conflicting_sources
    - unresolved_blocker_after_2_attempts
    - security_boundary_detected
  ultra:
    allowed: false

budget:
  max_wall_minutes: 45
  max_tool_calls: 120
  max_retries_per_step: 2
  max_estimated_usd: 12

access:
  jira:
    verbs: [read]
    projects: [NX]
  github:
    verbs: [read]
    repositories: [We0 AI/product]
  drive:
    verbs: [read, create_draft]
    folders: [launch-plans]
  external_send: deny
  deploy: deny
  grant_access: deny

approvals:
  - action: publish_report
    role: product-director
    evidence:
      - source_links_present
      - blockers_have_owner_and_date
      - unresolved_conflicts_listed

acceptance:
  required_checks:
    - schema_valid
    - all_sources_fresh_within_24h
    - no_unattributed_claims
    - human_approval_recorded

recovery:
  on_budget_exceeded: stop_and_notify
  on_tool_error_repeat: stop_and_attach_trace
  on_policy_violation: revoke_credentials_and_open_incident

이 템플릿은 몇 가지 의도적인 선택을 반영합니다.

• 에스컬레이션은 권한이 아닌 기능을 변경합니다.
• Ultra는 워크플로우 소유자가 명시적으로 활성화하지 않는 한 비활성화 상태로 유지됩니다.
• 외부 전송과 배포는 별개로 거부됩니다.
• 승인은 모델 신뢰도가 아닌 검사로 표현됩니다.
• 복구는 실행 전에 정의됩니다.

코딩 워크플로우의 경우 보고서 검사를 다음으로 대체하십시오.

• 대상 테스트
• 타입 검사
• 린트
• 보안 검사
• Diff 크기 제한
• 코드 소유자 검토

스프레드시트 워크플로우의 경우 다음을 요구합니다.

• 수식 검증
• 소스 조정
• 렌더링 검사

증거는 변경되지만 제어 평면 구조는 안정적으로 유지됩니다.

관찰 가능성, 예산 및 복구

장기 실행 에이전트는 새로운 관찰 가능성 문제를 야기합니다.

기존 요청 로그는 하나의 API 호출을 보여줄 수 있습니다. 에이전트 추적에는 수백 개의 결정, 도구 호출, 재시도 및 중간 아티팩트가 포함될 수 있습니다.

팀에게는 다음 두 가지가 모두 필요합니다.

1. 조사를 위한 완전한 추적
2. 운영을 위한 간결한 실행 원장

실행 원장 필드

유용한 원장에는 다음이 포함됩니다.

• 안정적인 실행 ID
• 시작 사용자
• 정책 버전
• 목표
• 모델 계층 및 스냅샷
• 추론 노력
• 하위 에이전트 수
• 도구 범위
• 승인
• 비용
• 경과 시간
• 승인 검사
• 최종 아티팩트 링크
• 최종 상태
• 에스컬레이션 사유

이를 통해 다음과 같은 질문에 답할 수 있습니다.

• Terra가 실패한 후 Sol이 승인율을 개선했습니까?
• 어떤 워크플로우가 검토자 시간을 가장 많이 소모합니까?
• 어떤 도구가 가장 많은 재시도를 유발합니까?
• 어떤 경로가 가장 높은 롤백 비율을 생성합니까?

사용

다차원 예산

단순히 금액 제한만 두면 저렴한 모델이 너무 오래 루프를 돌 수 있습니다.

단순히 시간 제한만 두면 값비싼 병렬 작업이 폭발적으로 증가할 수 있습니다.

유용한 예산 차원은 다음과 같습니다.

• 금액
• 실제 소요 시간(벽시계 시간)
• 토큰 사용량
• 도구 호출
• 재시도 횟수
• 파일 수
• Diff 크기
• 하위 에이전트 수

테스트 복구

복구는 다른 기능과 마찬가지로 테스트해야 합니다.

유용한 테스트는 다음과 같습니다.

1. 실행 도중 커넥터를 제거합니다.
2. 에이전트가 재시도 후 외부 작업을 반복하지 않는지 확인합니다.
3. 자격 증명을 만료시키고 추적 로그에 실패 원인이 설명되는지 확인합니다.
4. 예약된 작업을 취소하고 이후 실행이 중단되는지 확인합니다.
5. 생성된 커밋을 되돌리고 관련 아티팩트를 대체됨으로 표시합니다.

사고 검토 시 다음을 구분해야 합니다.

• 모델 실패
• 하네스(Harness) 실패
• 정책 실패
• 도구 실패
• 인간 승인 실패

"AI"에 책임을 돌리면 실제로 개선할 수 있는 구성 요소가 가려집니다.

도입 플레이북 및 검토 체크리스트

빈번하고, 측정 가능하며, 되돌릴 수 있는 하나의 워크플로우부터 시작하십시오.

좋은 후보는 다음과 같습니다.

• 릴리스 준비 보고서
• 이슈 분류
• 문서 업데이트
• 테스트 실패 요약
• 내부 연구 브리핑

첫 배포 시 다음은 피하십시오.

• 외부 커뮤니케이션
• 프로덕션 변경
• 결제
• 접근 권한 부여
• 삭제 워크플로우

인간 기준 기록

다음을 측정하십시오.

• 워크플로우에 소요되는 시간
• 사용된 출처
• 발생한 오류
• 검토자가 기대하는 증거

기준선이 없으면, 더 빠른 에이전트 출력이 단순히 더 많은 작업을 수정으로 전가할 수 있습니다.

섀도우 모드로 실행

인간이 실제 워크플로우를 독립적으로 완료하는 동안 에이전트가 아티팩트를 생성하도록 하십시오.

결과를 비교하고 실패 모드에 레이블을 지정하십시오. 이러한 실행을 사용하여 권한을 높이기 전에 비공개 평가를 구축하십시오.

검토 체크리스트

초안 전용 접근 권한에서 범위가 지정된 쓰기 접근 권한으로 이동하기 전에 다음을 확인하십시오.

• 작업 정의가 평가하기에 충분히 구체적입니까?
• 모델 계층과 추론 노력이 정책에 따라 선택되었습니까?
• 권한을 확장하지 않고 에스컬레이션이 가능합니까?
• 모든 도구에 명시적인 동사와 리소스 범위가 있습니까?
• 자격 증명이 수명이 짧고 실행에 귀속됩니까?
• 모든 되돌릴 수 없거나 외부에 보이는 작업에 게이트가 있습니까?
• 승인 검사가 모델의 완료 주장과 독립적입니까?
• 추적 로그에 출처, 작업, 승인, 오류 및 비용이 포함됩니까?
• 예산이 금액, 시간, 재시도, 도구 및 폭발 반경을 포괄합니까?
• 자격 증명 폐기, 취소 및 롤백이 테스트되었습니까?
• 비공개 평가에 일반적이고 위험도가 높은 엣지 케이스가 포함됩니까?
• 명명된 인간 소유자가 워크플로우 결과에 대해 책임을 집니까?

한 번에 한 차원씩만 확장하십시오.

팀은 초안 전용 출력을 유지하면서 새 데이터 소스를 추가하거나, 동일한 모델과 작업을 유지하면서 범위가 지정된 쓰기 접근 권한을 추가할 수 있습니다.

모델, 도구, 권한 및 일정을 함께 변경하면 회귀 원인을 파악하기 어렵습니다.

빌더가 지금 해야 할 일

GPT-5.6과 ChatGPT Work는 에이전트 인프라가 그 자체로 제품 카테고리로 자리 잡고 있음을 증명합니다.

모델 계층은 계속해서 변화할 것입니다. 오래 지속되는 작업은 개인 평가, 예산, 관찰 가능성 및 워크플로우 정의를 통해 안전한 실행을 가능하게 하는 제어 평면입니다.

해당 모델 변경 사항은 안전합니다.

경로 레지스트리 생성하기

Sol, Terra, Luna 및 OpenAI 이외의 후보 모델을 위한 소규모 레지스트리를 만듭니다.

다음을 저장합니다:

• 자격 요건
• 데이터 정책
• 허용되는 노력 범위
• 비용 가정
• 알려진 오류 모드

비공개 평가 큐를 추가하여 새 모델이 소셜 미디어 인상만으로 프로덕션 기본값이 되지 않도록 합니다.

인증 프록시 추가

에이전트와 중요한 도구 사이에 인증 프록시를 배치합니다.

다음을 노출합니다:

• 좁은 동사
• 수명이 짧은 자격 증명
• 승인 후크
• 멱등성 키

작업이 ChatGPT Work, Codex, 사용자 정의 애플리케이션 또는 예약된 백엔드 작업에서 시작되든 동일한 경계를 유지합니다.

자율성 이전에 승인 정의

작업이 어떻게 검증되는지 설명할 수 있는 팀은 단계적으로 안전하게 자동화할 수 있습니다.

검증을 정의할 수 없는 팀은 벤치마크 점수와 관계없이 에이전트가 몇 시간 동안 실행되도록 할 준비가 되지 않은 것입니다.

결과 수준에서 비용 검토

다음 항목별로 달러 및 작업 시간을 추적합니다:

• 승인된 결과물
• 병합된 변경 사항
• 해결된 티켓
• 승인된 분석

이를 통해 모델 라우팅, 하네스 효율성 및 검토자 작업량을 조정할 수 있습니다.

또한 다음 주력 모델이 출시될 때 팀이 근거 있는 답변을 얻을 수 있습니다.

경계 및 미해결 질문

출시 자료의 여러 주장은 여전히 벤더가 보고한 것입니다.

공급자 간 벤치마크 비교는 다음 항목에서 서로 다릅니다:

• 하네스
• 추론 설정
• 가격 책정 가정
• 도구 구성
• 데이터 세트

이러한 주장을 내부 테스트를 위한 가설로 취급합니다.

프로그래매틱 도구 호출 및 다중 에이전트 실행은 컨텍스트 오버헤드를 줄일 수 있지만, 추적이 약할 때 중간 로직의 가시성을 떨어뜨릴 수도 있습니다.

규제된 워크플로에서 이러한 기능을 사용하기 전에 다음을 확인합니다:

• API가 기록하는 내용
• 애플리케이션 로그가 보관하는 내용
• 중요한 중간 데이터가 처리되는 방식
• 워크플로가 필요한 보존 정책과 호환되는지 여부

ChatGPT Work의 연결된 애플리케이션 및 컴퓨터 사용 기능은 유틸리티를 증가시키는 동시에 권한 경계를 확장합니다. 가용성, 관리 제어 및 커넥터 권한은 요금제 및 배포에 따라 다를 수 있습니다.

제품 발표는 작업 공간별 보안 검토를 대체할 수 없습니다.

또한 인간-시스템 문제가 있습니다. 에이전트가 몇 시간 동안 계속 작동할 때 사용자는 자세히 관찰하지 않은 작업을 승인할 수 있습니다. 더 나은 요약이 도움이 되지만, 승인 품질은 결정 시점에 제안된 효과, 불확실성 및 실패한 검사를 표시하는지에 달려 있습니다.

제품 디자인은 인간의 주의를 보호해야 하며, 단순히 클릭을 요청해서는 안 됩니다.

따라서 가장 강력한 모델이 최종 아키텍처는 아닙니다.

프로덕션 품질은 다음 간의 관계에서 비롯됩니다:

• 모델
• 하네스
• 정책
• 도구
• 증거
• 책임 있는 소유자

에이전트 제어 플레인이 바로 이 관계를 명시적으로 만듭니다.

FAQ

GPT-5.6이란 무엇인가요?

GPT-5.6은 OpenAI의 2026년 7월 모델 제품군으로, Sol, Terra, Luna 기능 계층으로 구성됩니다. Sol은 최고 성능 경로, Terra는 성능과 비용의 균형, Luna는 속도와 경제성을 우선시합니다.

ChatGPT Work란 무엇인가요?

ChatGPT Work는 파일, 애플리케이션, 브라우저 작업, 컴퓨터 사용 전반에 걸친 장기 실행 작업을 위한 에이전트 작업 공간입니다.

예약된 작업. 일반 대화 턴과 달리, Work 태스크는 완료된 결과물이나 산출물을 중심으로 설계됩니다.

에이전트 제어 플레인이란 무엇인가요?

에이전트 제어 플레인은 에이전트 실행을 관리하는 정책 및 운영 계층입니다. 작업을 분류하고, 모델 경로를 선택하며, 범위가 지정된 자격 증명을 발급하고, 도구 제한을 적용하며, 승인을 강제하고, 추적을 기록하며, 결과를 평가하고, 예산을 통제하며, 복구를 관리합니다.

에이전트 하니스는 제어 플레인과 어떻게 다른가요?

하니스는 컨텍스트를 조합하고, 도구를 노출하며, 상태를 저장하고, 작업을 실행하며, 재시도를 관리하는 소프트웨어입니다. 제어 플레인은 해당 하니스가 어떻게 작동할 수 있는지, 즉 권한, 라우팅, 예산, 승인, 평가 및 복구를 관리합니다.

팀은 언제 Sol, Terra 또는 Luna를 사용해야 하나요?

Luna는 위험이 낮은 추출, 분류 및 서식 지정에 적합합니다. Terra는 일상적인 저장소 작업, 문서 생성, 그리고 강력한 검증이 수반되는 중간 수준의 분석에 적합합니다. Sol은 모호한 진단, 아키텍처, 보안 검토 및 고가치 연구에 더 적합합니다.

Sol로 전환하면 에이전트에 더 많은 권한이 부여되나요?

아니요. 모델 역량과 운영 권한은 분리되어 있어야 합니다. Luna나 Terra에서 Sol로 업그레이드하는 것은 추론 능력을 변경해야 하며, 도구 접근, 쓰기 권한, 배포 권한 또는 승인 요구 사항을 변경해서는 안 됩니다.

프로덕션 환경 선택에 공개 벤치마크가 충분하지 않은 이유는 무엇인가요?

공개 벤치마크에는 결함이 있는 작업, 하니스별 가정 또는 데이터 누출이 포함될 수 있습니다. 후보군을 발견하는 데는 유용하지만, 실제 환경에서 비용, 신뢰성, 검토 부담 및 안전성을 측정하려면 실제 내부 작업을 기반으로 한 비공개 평가가 필요합니다.

장기 실행 에이전트의 경우 무엇을 기록해야 하나요?

로그에는 목표, 모델 경로, 추론 노력, 도구 호출, 출처, 승인, 오류, 재시도, 토큰 사용량, 비용, 경과 시간, 산출물, 검증 결과, 에스컬레이션 이유 및 최종 상태가 포함되어야 합니다.

관련 도구

• ChatGPT: 채팅, Work, 연결된 도구 및 장기 실행 작업을 위한 OpenAI의 제품 인터페이스입니다.
• OpenAI API: GPT-5.6 및 Responses API로 애플리케이션을 구축하기 위한 공식 플랫폼입니다.
• Codex: 저장소 작업, 소프트웨어 엔지니어링 및 에이전트 기술을 위한 OpenAI의 코딩 에이전트 플랫폼입니다.
• 프로그래매틱 도구 호출: 인메모리 프로그램으로 도구를 조정하고 중간 결과를 처리하기 위한 OpenAI의 공식 가이드입니다.
• NIST AI 리스크 관리 프레임워크: AI 리스크를 식별, 측정 및 관리하기 위한 거버넌스 프레임워크입니다.
• Databricks: 엔지니어링 팀이 실제 저장소 변경 사항을 기반으로 비공개 코딩 에이전트 평가를 발표한 데이터 및 AI 플랫폼입니다.

관련 링크

• GPT-5.6 일반 사용 가능: 모델 계층, 기능 세부 정보, 가용성 및 가격을 포함한 OpenAI의 공식 GPT-5.6 릴리스입니다.
• GPT-5.6 Sol 미리보기: OpenAI의

Sol 모델의 이전 기술 프리뷰.

• 야심찬 업무를 위한 ChatGPT: ChatGPT Work와 그 장기 실행 작업 모델을 설명하는 OpenAI의 공식 발표.
• 프로그래매틱 도구 호출 문서: 도구 호출의 프로그래매틱 조정을 위한 공식 개발자 문서.
• 코딩 평가에서 신호와 노이즈 분리하기: 공개 코딩 벤치마크의 신뢰성 문제에 대한 OpenAI의 감사 및 논의.
• GPT-5.6 시스템 카드: GPT-5.6에 대한 OpenAI의 공식 안전 및 성능 평가 문서.
• Databricks 코딩 에이전트 벤치마크: 수백만 줄 규모의 코드베이스에서 실제 풀 리퀘스트를 기반으로 구축된 비공개 평가.

요약

GPT-5.6은 팀에게 기능, 비용, 추론 노력, 다중 에이전트 실행에 대한 더 명확한 메뉴를 제공합니다. ChatGPT Work는 이러한 기능을 파일, 애플리케이션, 브라우저, 예약된 워크플로 전반의 지속적 작업으로 확장합니다.

프로덕션 환경의 과제는 단순히 가장 강력한 모델을 선택하는 것이 아닙니다. 팀은 범위가 제한된 정체성, 세분화된 도구 권한, 승인 게이트, 독립적 수락 검사, 전체 추적, 다차원 예산, 비공개 평가, 검증된 복구도 필요로 합니다.

하나의 되돌릴 수 있는 워크플로부터 시작하고, 인간 기준을 기록하며, 섀도우 모드로 실행하고, 한 번에 하나의 권한 차원만 증가시키십시오.

프로덕션 등급의 에이전트는 단지 도구를 가진 강력한 모델이 아닙니다. 측정 가능하고, 되돌릴 수 있으며, 책임질 수 있는 제어 평면 내에서 작동하는 모델입니다.