5초 결론
실무에서 빠른 AI란 먼저 답하는 AI가 아니다. 완성까지의 재작업을 줄이는 AI가 빠른 AI다.
한 콘텐츠 생산 파이프라인은 며칠에서 약 일주일 정도의 집중 개조를 거치며 단순한 “AI가 글을 쓰고 파일을 저장하는 자동화”에서 모니터링, 복구, 동시 실행 제어, 체크포인트, 불량 작업 격리, 품질 게이트, 증거 관리까지 갖춘 작은 자율 공장으로 변했다.
큰 설계 변경에는 GPT-5.6 Sol의 깊은 추론뿐 아니라 여러 작업 흐름을 병렬로 조정하는 ultra가 특히 효과적이었다. 한 번의 실행은 무겁지만, “구현→구조적 버그 발견→재설계→재테스트→또 다른 충돌 발견”이라는 긴 재작업 사슬을 줄일 수 있다.
제조업식으로 말하면 사이클 타임은 길어도 재작업률이 낮아 전체 리드 타임은 짧아질 수 있다.
먼저 주의: Level 6과 Level 7은 국제 표준이 아니다
이 글의 Level 6과 Level 7은 ISO 같은 공식 등급이 아니라 이 시스템의 성숙도를 설명하기 위한 로컬 라벨이다.
개념적 배경은 IBM의 autonomic computing 연구와 가깝다. IBM은 스스로 구성하고, 치유하고, 최적화하고, 보호하는 시스템을 연구해 왔다.
여기서는 정해진 올바른 상태로 스스로 돌아가는 단계가 Level 6, 그리고 안전 규칙을 지키면서 더 나은 운전 방식을 스스로 실험하는 단계가 Level 7이다.
처음에는 “AI에게 글을 쓰게 하자”였다. 그런데 블로그에 fencing이 자랐다
단순 자동화는 예약 실행, AI 생성, 파일 저장, GitHub 반영, 실패 시 사람 확인이면 끝난다.
하지만 다국어, 품질 감사, 내부 링크, 갱신, 게시 판정까지 자동화하면 질문이 바뀐다.
두 worker가 같은 글을 동시에 수정하면? 중간에 죽으면 어디서 재개하지? 실패 항목이 영원히 재시도되면? 오래된 감사 결과가 새 증거처럼 재사용되면? AI가 실제로 없었던 인간 검토를 만들어내면? 외부 서비스가 죽어도 안전한 로컬 생산은 계속할 수 있는가?
여기부터는 블로그가 아니라 콘텐츠를 원료로 쓰는 생산 시스템이다.
Level 6: 망가져도 스스로 정상 상태로 돌아오기
Level 6의 핵심은 “정답 상태는 이미 정의되어 있고, 현재 상태가 벗어나면 시스템이 차이를 찾아 되돌린다”이다.
주요 장치는 desired state, reconciliation loop, lease/fencing, formal checkpoint, CAS, transactional outbox, 제한된 retry, quarantine, 게시 안전 게이트, failure injection, observability다.
한 운영 스냅샷에서는 Level 6 구현 요구 21개가 모두 PASS였고 제어 구현 점수는 100이었다. 그러나 외부 측정, 인간 증거, 장기 운영 건전성까지 포함한 assurance는 약 69%였고 게시도 HOLD, Level 7도 OFF였다.
즉 코드가 100점인 것과 장기간 안심하고 방치할 수 있는 것이 100점인 것은 다르다.
깊게 생각하는 Sol과 Ultra: 한 명의 장고와 여러 전문가의 병렬 작업
OpenAI는 GPT-5.6 Sol에 더 깊게 추론하는 max를 제공하고, ultra는 복잡한 작업에서 여러 에이전트의 병렬 작업을 조정하는 설정으로 설명한다.
깊은 Sol은 매우 뛰어난 엔지니어 한 명에게 저장소와 요구사항을 주고 충분히 생각하게 하는 그림이다.
Ultra는 설계자, 구현자, 테스트 담당, 비판자, “이거 일부러 망가뜨려 보자” 담당이 동시에 일한 뒤 결과를 합치는 그림에 가깝다.
지능이 단순히 두 배가 되는 것은 아니다. 서로 다른 방향의 맹점을 동시에 공격할 수 있다는 점이 핵심이다.
OpenAI 공개 값에서 Terminal-Bench 2.1은 Sol 88.8%, Sol Ultra 91.9%다. 실패 쪽만 보면 11.2%에서 8.1%로 줄어, 해당 벤치마크 기준 약 28% 감소다. 모든 프로젝트에서 버그가 28% 줄어든다는 뜻은 아니지만, 복잡하고 분할 가능한 작업에서 병렬 에이전트가 왜 유리한지 보여주는 예다.
무거운 Ultra가 왜 결국 더 빠를 수 있는가
개발 전체 시간은 이렇게 보는 편이 낫다.
전체 리드 타임 = 최초 구현 + 재작업 + 재테스트 + 장애 복구 + 요구 오해 수정
30분 만에 구현한 결과가 이후 6시간의 수정 작업을 만든다면 빠른 것이 아니다. 2시간을 들여 구조를 제대로 잡고 이후 재작업을 없앴다면 그쪽이 더 빠르다.
이번 “Ultra 한 방” 이후의 수정도 뿌리부터 다시 만드는 작업보다 증거와 관측을 강화하는 작업이 많았다. 모든 worker의 실제 처리 증명, 과거 감사 기록 재사용 금지, AI 검토와 인간 검토 구분, 외부 증거가 없으면 UNKNOWN 표시, 올바른 NOOP를 실패로 취급하지 않기 등이었다.
집의 기초를 다시 파는 것이 아니라 완성된 공장에 QC팀이 들어와 계기판을 하나씩 교정하는 상황에 가깝다.
첫 한 방이 버틴 이유
한 번에 완벽했다는 뜻은 아니다. 처음부터 동시 실행, 중간 사망, 오래된 worker의 지연 쓰기, 외부 API 장애, 무한 재시도, 검사기 자체 고장, 거짓 성공 같은 질문을 설계에 포함한 덕분에 이후 수정 범위가 작았다.
Chaos Engineering의 핵심도 비슷하다. 정상 상태를 측정 가능한 값으로 정의하고 현실적인 장애를 일부러 넣어 시스템이 버티는지 확인한다.
쉽게 말하면 실전이 울기 전에 테스트를 울린다.
세상 기준으로 어느 정도인가
일반적인 AI 글 생성이나 직렬형 Zapier/n8n 자동화보다 훨씬 복잡하다. 동시성, 복구, 상태 무결성, 증거, 장애 격리가 있기 때문이다.
진지하게 만든 개인 SaaS 백엔드나 작은 회사의 내부 자동화 플랫폼과는 상당수 설계 주제가 겹친다.
반면 전담 SRE와 보안팀이 운영하는 성숙한 상용 서비스와 비교하면 장기 운영 실적, 독립 보안 검증, 대규모 부하 기록, 실제 사용자 영향 측정이 부족하다. Google/Amazon급과 비교하는 것은 규모가 다른 우주다.
개인 프로젝트로 특이한 점은 글쓰기 기능보다 실패했을 때 어떻게 행동할지에 코드가 많이 붙었다는 것이다.
Level 7: 공장장이 통제된 실험을 시작한다
Level 7에서는 품질, 속도, 비용, 대기시간, 실패율을 함께 측정하고, 안전 규칙은 optimizer가 바꾸지 못하게 한다. 새로운 prompt나 작업 순서를 shadow로 시험하고, 좋으면 canary로 조금씩 확대하고, 품질이 떨어지면 자동 rollback한다. 신뢰성이 나쁘면 실험만 멈추고 검증된 생산은 계속한다. 그리고 모든 실험은 가설, 기준선, 결과, rollback 지점을 원장에 남긴다.
IBM의 self-optimization, Google SRE의 error budget, canary/rollback 배포 철학과 닮아 있다.
하지만 지금 Level 7을 바로 켜는 것은 이르다. Level 6의 장기 운영 증거를 모으는 동안 정책까지 자동으로 바뀌면 원인 분석이 어려워진다.
먼저 필요한 것은 모든 worker의 실제 실행을 한 장에서 볼 수 있는 운영 원장이다.
유료 기간은 ‘설비 투자 기간’으로 쓰면 효율적이다
Ultra를 매일의 작은 수정에 쓸 필요는 없다. 정형화된 worker, 반복 감사, 작은 패치에는 일반 Sol이나 깊은 추론이 충분한 경우가 많다.
Ultra는 시스템 전체 재설계, 대규모 리팩터링, worker 구조 변경, 복구 설계, 보안 경계, shadow 실험 기반, 대량 fault injection처럼 잘못 시작하면 재작업 비용이 큰 일에 쓰는 편이 좋다.
즉 평소에는 공장을 운영하고, 큰 개선 항목을 모아두었다가 강한 모드를 쓸 수 있는 시기에 설비 투자처럼 한 번에 밀어붙이는 전략이 합리적이다.
약 일주일 동안 얻은 가장 큰 교훈
실무 AI의 성능은 정답률만이 아니다. 초기 설계 품질, 자기 반박 능력, 병렬 작업 능력, 실제 실행을 증명하는 기록, 실패 후 복구 능력이 매우 중요하다.
좋은 자율 공장은 실패하지 않는 공장이 아니다.
실패를 예상하고, 거짓 성공을 만들지 않으며, 안전한 작업은 계속하고, 언제든 검증된 상태로 돌아갈 수 있는 공장이다.
결론: 속도는 결승선까지의 시간이다
약 일주일 만에 크게 진화한 이유는 AI가 코드를 빨리 썼기 때문만이 아니다. 비용이 큰 초기 설계에 강한 추론과 병렬 작업을 집중하고, 이후 일상 생산은 더 가벼운 방식으로 돌리는 구조가 효율적이었다.
Ultra는 마법의 정답 버튼이라기보다 미래의 재작업을 선불로 줄이는 장치에 가깝다.
한 번이 느려도 전체 프로젝트가 빨리 끝나면 그게 진짜 빠른 것이다.
- OpenAI GPT-5.6: https://openai.com/index/gpt-5-6/
- IBM Research Autonomic Computing: https://research.ibm.com/publications/autonomic-computing-architectural-approach-and-prototype
- Google SRE Error Budget: https://sre.google/workbook/error-budget-policy/
- Principles of Chaos Engineering: https://principlesofchaos.org/
- AWS Canary Deployments: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/canary-deployment.html
