OpenAI가 GPT-5.6 Sol, Terra, Luna 프리뷰를 공개했습니다. 제목만 보면 새 모델 뉴스입니다. 하지만 개발자 입장에서 중요한 지점은 “성능이 더 좋아졌다”가 아니라, 더 강한 코딩 에이전트를 제품과 조직 안에 넣을 때 운영 기준이 어떻게 바뀌는가입니다.
이번 프리뷰에서 OpenAI는 Sol을 플래그십, Terra를 일상 작업용 균형 모델, Luna를 빠르고 저렴한 모델로 설명했습니다. Sol은 제한된 파트너 대상으로 먼저 제공되고, API와 Codex 경로에서 시작합니다. 가격도 공개됐습니다. 100만 토큰 기준 Sol은 입력 $5, 출력 $30, Terra는 입력 $2.50, 출력 $15, Luna는 입력 $1, 출력 $6입니다. GPT-5.6 이후 모델에는 명시적 캐시 브레이크포인트와 최소 30분 캐시 수명이 들어가며, 캐시 쓰기는 비캐시 입력 단가의 1.25배, 캐시 읽기는 90% 할인이 적용됩니다.
이 정보는 단순 스펙표가 아닙니다. 장시간 코드 수정, 보안 분석, 대규모 리팩터링을 에이전트에 맡기는 팀이라면 비용 모델, 승인 모델, 보안 모델을 다시 잡아야 한다는 뜻입니다.
GPT-5.6 Sol의 핵심 키워드는 에이전트 작업입니다. OpenAI는 Terminal-Bench 2.1에서 명령줄 작업, 계획, 반복, 도구 조율 능력이 좋아졌다고 설명했습니다. Terminal-Bench류 평가는 단순 코드 완성보다 실제 개발 환경에 가깝습니다. 패키지를 설치하고, 테스트를 돌리고, 실패 로그를 읽고, 다시 수정하는 작업을 봅니다.
실무에서는 이 차이가 큽니다. 기존 LLM 코딩은 “함수 하나 작성”이나 “오류 메시지 설명”에 가까웠습니다. 에이전트형 코딩은 레포를 이해하고, 여러 파일을 수정하고, 테스트 결과에 따라 다음 행동을 고릅니다. 그래서 모델이 강해질수록 개발자의 역할은 프롬프트 작성자가 아니라 작업 관리자에 가까워집니다.
다만 강한 모델이 곧 안전한 자동화를 뜻하지는 않습니다. Sol은 사이버 보안과 생물학 영역에서 더 강한 능력을 보이지만, 동시에 실시간 분류기, 계정 단위 검토, 단계적 접근 제한 같은 안전장치를 함께 도입했습니다. 즉 공급자도 “모델만 풀면 된다”고 보지 않습니다. 제품에 붙이는 쪽도 같은 수준의 운영 설계가 필요합니다.
OpenAI는 GPT-5.6에서 더 깊게 추론하는 max reasoning effort와, 단일 에이전트를 넘어 subagents를 활용하는 ultra mode를 언급했습니다. 개발팀 관점에서 이건 단순히 “답변이 더 똑똑해진다”가 아닙니다. 하나의 큰 작업을 여러 하위 작업으로 쪼개 병렬 처리하는 구조가 제품 기본값이 될 수 있다는 의미입니다.
예를 들어 “결제 모듈 리팩터링”을 맡긴다고 가정해봅시다. 단일 에이전트는 파일을 읽고 순서대로 수정합니다. subagents 구조에서는 한 에이전트가 API 계약을 확인하고, 다른 에이전트가 테스트를 보강하고, 또 다른 에이전트가 마이그레이션 위험을 찾을 수 있습니다. 속도는 빨라질 수 있지만, 병합 충돌과 판단 불일치도 늘어납니다.
따라서 ultra mode류 기능을 쓰려면 작업 단위를 더 엄격히 정의해야 합니다. “알아서 개선해줘”보다 “타입 오류 제거, 공개 API 변경 금지, 테스트 추가, 마이그레이션 문서 작성”처럼 결과물을 나눠야 합니다. 병렬 에이전트는 모호한 목표를 더 빠르게 엉망으로 만들 수 있습니다.
이번 발표에서 눈여겨볼 부분은 가격뿐 아니라 prompt caching입니다. 장시간 코딩 에이전트는 레포 설명, 아키텍처 문서, 테스트 로그, 이전 결정 기록을 반복해서 넣습니다. 캐시가 없으면 매 턴 비용이 커지고, 캐시가 있어도 캐시 브레이크포인트 설계를 잘못하면 할인 효과가 줄어듭니다.
실무 기준은 간단합니다. 자주 바뀌지 않는 컨텍스트와 자주 바뀌는 컨텍스트를 분리해야 합니다. 예를 들어 다음처럼 나눌 수 있습니다.
명시적 캐시 브레이크포인트가 있는 모델에서는 고정 컨텍스트를 앞쪽에 안정적으로 두고, 변동 컨텍스트를 뒤쪽에 배치하는 것이 중요합니다. 대화마다 전체 컨텍스트를 새로 조립하면 “모델은 좋아졌는데 비용은 더 비싸졌다”는 결론이 나옵니다.
OpenAI는 Sol이 취약점 탐지와 패치 개발에는 강하지만, 평가 조건에서 완전한 브라우저 exploit chain을 자율적으로 만들지는 못했다고 설명했습니다. 동시에 ExploitBench, ExploitGym 같은 벤치마크를 언급하며 사이버 능력이 올라갔음을 인정했습니다.
이 대목은 개발팀에 현실적인 질문을 던집니다. 보안 리뷰에 AI를 붙일 것인가? 붙인다면 어디까지 허용할 것인가?
권장 접근은 “탐지 자동화”보다 “검증 가능한 패치 루프”입니다. 에이전트가 발견한 취약점 후보를 그대로 이슈화하면 노이즈가 폭발합니다. 대신 다음 산출물을 요구해야 합니다.
이 형식이 없으면 AI 보안 도구는 개발팀의 시간을 아끼는 게 아니라 triage 부담을 늘립니다.
GPT-5.6 Sol급 모델을 코딩 또는 보안 워크플로우에 넣는다면 다음 기준을 먼저 정해야 합니다.
첫째, 승인 경계를 코드로 표현해야 합니다. 파일 읽기, 테스트 실행, 문서 수정은 자동 허용할 수 있습니다. 배포, 의존성 업그레이드, 마이그레이션, 외부 API 호출은 승인 대상으로 둬야 합니다.
둘째, 실패 로그를 남겨야 합니다. 에이전트가 어떤 테스트를 실행했고, 어떤 파일을 바꿨고, 왜 그 판단을 했는지 추적할 수 있어야 합니다. 강한 모델일수록 결과가 그럴듯해서 검토가 느슨해지기 쉽습니다.
셋째, 비용 한도를 작업 단위로 잡아야 합니다. “오늘 API 비용”보다 “이 리팩터링 작업당 최대 입력/출력 토큰”이 더 실무적입니다.
넷째, 모델 티어를 작업 위험도에 맞춰야 합니다. 모든 작업에 Sol을 쓰는 건 낭비입니다. 문서 정리나 단순 테스트 보강은 저렴한 모델로 충분하고, 긴 추론이 필요한 설계 변경이나 보안 분석에만 고급 모델을 배정하는 방식이 낫습니다.
GPT-5.6 Sol 프리뷰는 “더 똑똑한 모델이 나왔다”로 끝낼 뉴스가 아닙니다. 이제 코딩 에이전트는 장난감이 아니라 운영 대상입니다. 개발팀이 먼저 준비해야 할 것은 프롬프트가 아니라 승인, 비용, 로그, 검증 기준입니다.
