GPT-5.6 Sol 프리뷰를 보면서 제일 먼저 든 생각은 이거였다. 모델이 또 세졌다는 뉴스보다, 이제 Codex 같은 코딩 에이전트를 팀 운영 도구로 다루는 기준이 더 급해졌다는 쪽이다.
OpenAI는 GPT-5.6 Sol을 코딩, 과학, 사이버보안 능력이 강화된 차세대 모델로 소개했다. 동시에 Hacker News에는 “GPT-5.6 Sol Ultra가 Codex에 들어간다”는 이야기가 프론트페이지에 올라왔다. 이 조합이 묘하다. 공식 발표가 말하는 건 모델 성능인데, 개발자들이 바로 상상하는 건 “그럼 내 에이전트가 얼마나 오래, 얼마나 많이, 얼마나 위험한 일을 대신할 수 있나” 쪽이다.
모델 뉴스보다 Codex 운영 뉴스에 가깝다
더 똑똑한 모델은 더 긴 작업을 맡는다
OpenAI의 에이전트 업무 분석 글에서 눈에 들어온 문장은 “지식 노동의 단위가 단일 응답에서 위임된 장기 작업으로 바뀐다”는 부분이었다. 이건 말은 멋있지만, 현장에서 보면 굉장히 구체적이다. 예전에는 모델에게 함수 하나를 물어봤다. 지금은 이슈를 읽고, 파일을 고치고, 테스트를 돌리고, 실패 로그를 보고, 다시 고친다.
OpenAI는 Codex 사용이 강한 모델과 제품 기능이 붙으면서 더 긴 작업으로 확장됐다고 적었다. 특히 2026년 5월 기준 개인 사용자 표본의 80% 이상이 “사람 기준 30분 넘는 작업”으로 추정되는 Codex 요청을 최소 한 번 이상 했다는 대목이 인상적이었다. 이건 더 이상 자동완성 이야기가 아니다. 작은 티켓을 에이전트에게 맡기는 운영 흐름이다.
그래서 GPT-5.6 Sol 같은 모델이 Codex 쪽 기대와 같이 묶이는 건 자연스럽다. 코딩 능력이 좋아지면 단순히 답변 품질이 올라가는 게 아니라, 위임 가능한 작업 길이가 늘어난다. 문제는 여기서부터다. 긴 작업을 맡길수록 실패도 길어진다. 잘못된 방향으로 3분 헤매는 것과 40분 동안 파일을 바꿔놓는 건 완전히 다른 사고다.
“Codex에 들어간다”보다 중요한 질문
Hacker News의 프론트페이지 제목은 꽤 자극적이었다. “GPT-5.6 Sol Ultra will be in Codex.” 그런데 나는 이 문장을 사실 확정 뉴스처럼 소비하기보다, 개발자들이 무엇을 기대하는지 보여주는 신호로 보는 게 맞다고 본다. 모두가 궁금해하는 건 모델 이름이 아니라 Codex가 다음에 어디까지 일을 맡을 수 있느냐다.
여기서 중요한 질문은 세 가지다. 첫째, 이 에이전트가 어떤 저장소와 파일을 볼 수 있는가. 둘째, 어떤 명령을 실제로 실행할 수 있는가. 셋째, 작업 로그와 비용을 누가 확인하는가. 모델이 좋아질수록 이 질문은 더 중요해진다. 덜 똑똑한 모델은 자주 멈추지만, 더 똑똑한 모델은 더 그럴듯하게 밀고 나간다.
이전에 Codex 모바일·데스크 코딩 흐름을 봤을 때도 비슷한 느낌이었다. 제품 표면은 “어디서든 코딩”이지만, 운영 관점의 본체는 작업 인수인계와 검증이다. 이번 GPT-5.6 Sol 이야기도 결국 같은 방향으로 이어진다.
코딩 에이전트는 이제 제품 기능끼리 연결된다
Claude Code에서 Codex를 부르는 흐름
이번 리서치에서 같이 보인 재밌는 신호는 GitHub Trending에 올라온 openai/codex-plugin-cc였다. 설명은 단순하다. Claude Code에서 Codex를 불러 코드 리뷰나 작업 위임에 쓰는 플러그인이다. 이름만 보면 장난감처럼 보일 수 있는데, 실제 의미는 꽤 크다. 에이전트 하나가 모든 걸 하는 게 아니라, 에이전트가 다른 에이전트를 도구처럼 부르는 흐름이다.
나는 이게 앞으로 AI 개발 도구의 기본 모양에 가깝다고 본다. IDE 안에는 Copilot이 있고, 터미널에는 Codex가 있고, 팀 채널에는 다른 에이전트가 있고, 어떤 작업은 Claude Code가 잡고 있다. 사용자는 “어느 모델이 제일 똑똑한가”보다 “이 작업은 어느 실행 환경에 맡기는 게 안전한가”를 고민하게 된다.
이게 편해지려면 연결 자체보다 경계가 중요하다. Codex가 Claude Code 안에서 호출된다면, 그 Codex는 어떤 파일을 읽었는지, 어떤 diff를 만들었는지, 어떤 테스트를 돌렸는지 남겨야 한다. 단순히 답변을 잘했다는 감상으로 끝나면 팀에서는 못 쓴다.
Copilot 쪽 변화도 같은 방향이다
GitHub Changelog도 비슷한 신호를 여러 개 냈다. Copilot agent session streaming이 public preview로 나왔고, Copilot CLI가 GitHub Actions 안에서 개인 access token 없이 동작하는 흐름도 생겼다. 기업 관리자가 자동 모델 선택을 기본값으로 둘 수 있다는 공지도 있었다.
이 셋은 따로 보면 작은 기능이다. 그런데 같이 보면 방향이 보인다. 세션을 실시간으로 보고, CI 안에서 더 안전하게 실행하고, 조직이 모델 선택 정책을 중앙에서 관리하는 쪽이다. 다시 말해 “AI 코딩이 더 똑똑해졌다”가 아니라 “AI 코딩을 운영 가능한 시스템으로 만들려 한다”에 가깝다.
특히 개인 access token을 덜 쓰는 흐름은 좋다. 에이전트가 CI에서 움직이기 시작하면 토큰 관리는 바로 사고 지점이 된다. 개인 토큰으로 자동화를 붙이면 퇴사, 권한 변경, 유출, 감사 로그가 전부 지저분해진다. AI 에이전트가 팀 인프라 안에 들어올수록 이런 작은 인증 개선이 성능 발표만큼 중요해진다.
성능보다 먼저 잠글 운영 기준
권한은 모델별이 아니라 작업별로 나눠야 한다
팀에서 GPT-5.6 Sol급 모델을 Codex에 붙일 수 있다고 해도, 모든 작업에 같은 권한을 주면 안 된다. 오히려 모델이 강할수록 작업별 권한 분리가 필요하다. 읽기 전용 리서치, 단일 파일 수정, 테스트 실행, 의존성 설치, 배포 명령은 위험도가 다르다.
내 기준으로는 최소 네 단계로 나누는 게 맞다. 첫째, 읽기와 요약만 가능한 모드. 둘째, 브랜치 안에서 파일 수정만 가능한 모드. 셋째, 테스트와 빌드까지 실행 가능한 모드. 넷째, 외부 서비스나 배포에 닿는 모드. 이 네 가지를 같은 “Codex 사용”으로 묶으면 나중에 사고가 났을 때 설명이 안 된다.
여기서 중요한 건 승인 UX다. 사람이 매번 모든 명령을 눌러줘야 하면 에이전트의 장점이 사라진다. 반대로 아무 명령이나 열어두면 자동화가 아니라 도박이다. 그래서 작업 유형별 기본 허용 목록과 금지 목록이 필요하다. 좋은 하네스는 모델을 믿는 시스템이 아니라, 모델이 실수해도 반경을 줄이는 시스템이다.
세션 스트리밍과 로그는 사치가 아니다
Copilot agent session streaming 같은 기능을 보면 처음에는 “오, 작업 화면을 볼 수 있네” 정도로 느껴진다. 그런데 실제 운영에서는 이게 거의 필수다. 에이전트가 오래 작업할수록 중간 상태를 볼 수 있어야 한다. 지금 파일을 읽는 중인지, 테스트에서 막혔는지, 같은 실패를 반복하는지, 엉뚱한 방향으로 가는지 확인해야 한다.
AI 코딩 도구를 오래 돌려본 사람은 안다. 실패 자체보다 무서운 건 조용히 잘못 진행되는 작업이다. 로그가 없으면 마지막 diff만 보고 추리해야 한다. 세션 스트리밍이나 구조화된 실행 로그가 있으면 중간에 끊거나, 범위를 좁히거나, 리뷰어에게 넘길 수 있다.
이건 비용 관리와도 연결된다. 긴 작업이 많아지면 토큰과 실행 시간이 조용히 샌다. “좋은 모델이니까 맡겨보자”가 반복되면 한 달 뒤 비용표가 이상해진다. 그래서 에이전트 운영에는 성공률뿐 아니라 평균 작업 시간, 재시도 횟수, 테스트 실패 반복, 사람이 되돌린 diff 같은 지표가 필요하다.
코드 품질도 에이전트 입력이다
지저분한 코드는 사람만 힘들게 하지 않는다
arXiv에 올라온 “Does Code Cleanliness Affect Coding Agents?” 논문도 이번 흐름과 잘 맞았다. 요지는 코드 청결도가 코딩 에이전트의 계산 비용과 탐색 효율에 영향을 준다는 것이다. 이건 꽤 현실적인 이야기다. 사람에게 읽기 어려운 코드는 에이전트에게도 비용이 된다.
우리는 종종 모델 성능만 올리면 지저분한 코드도 알아서 고쳐줄 거라고 기대한다. 어느 정도는 맞다. 그런데 저장소 구조가 꼬여 있고, 이름이 흔들리고, 테스트가 없고, 빌드 명령이 문서화되지 않은 프로젝트에서는 강한 모델도 헤맨다. 에이전트는 마법사가 아니라, 저장소 안의 단서를 따라 움직이는 작업자에 가깝다.
그래서 GPT-5.6 Sol 같은 모델 발표를 볼 때도 나는 “우리 코드를 더럽게 둬도 되겠다”가 아니라 반대로 본다. 모델이 더 오래 작업할수록 저장소의 냄새가 비용으로 드러난다. AGENTS.md, 테스트 명령, 리뷰 기준, 작은 PR 단위, 명확한 파일 구조가 더 중요해진다.
지금 바로 볼 체크리스트
팀에서 Codex나 Copilot agent를 더 깊게 붙이려면, 모델 이름보다 먼저 이 정도를 확인하는 게 낫다.
| 확인할 것 | 왜 봐야 하나 |
|---|---|
| 작업별 권한 단계 | 강한 모델일수록 실패 반경도 커진다 |
| 세션 로그와 중간 상태 | 긴 작업은 마지막 diff만으로 판단하기 어렵다 |
| CI 안 인증 방식 | 개인 토큰 기반 자동화는 감사와 회수에 약하다 |
| 코드베이스 청결도 | 에이전트의 탐색 비용과 재시도 비용에 영향을 준다 |
내 결론은 이렇다. GPT-5.6 Sol은 분명 흥미로운 모델 뉴스다. Codex에 어떤 형태로 붙든 개발자 기대도 커질 수밖에 없다. 그런데 팀 운영자 입장에서 먼저 챙길 건 “더 똑똑한 모델을 어디까지 믿을까”가 아니다. “이 모델이 실패해도 어디서 멈추고, 누가 보고, 어떤 로그로 되돌릴 수 있을까”다.
모델 경쟁은 계속 갈 것이다. 오늘은 GPT-5.6 Sol이고, 내일은 다른 이름일 수 있다. 하지만 Codex를 실제 업무에 넣는 팀에게 오래 남는 건 모델명이 아니라 운영 기준이다. 권한, 세션, 비용, 코드 품질. 이 네 가지가 잡혀 있어야 다음 모델이 와도 팀이 덜 흔들린다.
참고한 자료
- OpenAI, Previewing GPT-5.6 Sol
- OpenAI, How agents are transforming work
- GitHub, Copilot agent session streaming public preview
- GitHub, Copilot CLI no longer needs a personal access token in GitHub Actions
- GitHub, Enterprises can default to auto model selection
- GitHub, openai/codex-plugin-cc
- Hacker News, GPT-5.6 Sol Ultra will be in Codex
- arXiv, Does Code Cleanliness Affect Coding Agents?