5초 결론
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에게 글 쓰게 하기"가 전부였다. 정신 차려 보니 블로그에 울타리가 자라 있었다
일반적인 글 자동화는 단순하다.
- 정해진 시각에 돌아간다.
- AI가 글을 만든다.
- 파일로 저장한다.
- GitHub에 올린다.
- 실패하면 사람이 들여다본다.
이것만으로도 충분히 쓸모 있다.
하지만 글 수가 늘고, 12개 언어가 되고, 품질 감사와 내부 링크, 업데이트, 공개 판정까지 자동화하면 문제의 성격이 달라진다.
핵심은 더 이상 "글을 쓸 수 있느냐"가 아니라 다음과 같은 문제들이다.
- 작업자(worker) 두 개가 같은 글을 동시에 건드리면 어떻게 할까.
- 도중에 멈추면 어디서부터 다시 시작할까.
- 실패한 작업을 영원히 재시도하지 않으려면 어떻게 할까.
- 오래된 검사 결과를 새 검사 결과인 양 재사용하고 있지는 않을까.
- AI가 "사람이 확인했다"고 멋대로 말하고 있지는 않을까.
- 공개하면 안 되는 상태를 누가 막을까.
- 외부 서비스가 죽어도 공장 전체를 멈추지 않으려면 어떻게 할까.
- "100점"이라고 표시되는데, 그 100점은 정말 지금 상태를 측정한 것일까.
여기까지 오면 이미 "블로그 자동화"가 아니다.
콘텐츠를 원료로 쓰는 소형 생산 시스템이다.
Level 6: 망가져도 스스로 올바른 상태로 돌아온다
이 공장의 Level 6을 한마디로 하면 고정된 정답으로 자율적으로 돌아가는 장치다.
주요 요소는 다음과 같다.
| 장치 | 중학생에게 설명하듯 말하면 |
|---|---|
| desired state | 있어야 할 정답을 기계가 읽을 수 있는 형태로 정해 둔다 |
| reconciliation | 현재와 정답을 비교해서, 다르면 고친다 |
| lease / fencing | 같은 일을 두 명이 멋대로 동시에 하지 못하게 한다 |
| checkpoint | 어디까지 끝났는지를 공식적으로 저장한다 |
| CAS | 오래된 상태로 새로운 상태를 덮어쓰지 않는다 |
| transactional outbox | 본체만 성공하고 알림만 실패하는 식의 어긋남을 회수한다 |
| retry / quarantine | 일시적인 실패는 재시도하고, 독이 되는 데이터는 격리한다 |
| safe publication gate | 품질 조건을 채울 때까지 공개하지 못하게 한다 |
| failure injection | 일부러 망가뜨려서 정말 복구되는지 시험한다 |
| observability | 무엇이 돌아가고 무엇이 실패했는지 잴 수 있게 한다 |
어느 운영 스냅샷에서는 Level 6 설계 요건 21개 항목이 모두 PASS였고, 제어 구현 점수는 100이었다. 반면 외부 계측, 사람의 확인, 모든 worker의 장기 실적 등을 포함한 보증 점수는 약 69%였고, 공개는 아직 HOLD, Level 7도 OFF였다.
여기가 중요하다.
구현 100점과, 정말 안심하고 방치해도 되는 100점은 다르다.
테스트가 전부 통과해도, 1주일, 1개월, 반년 동안 실제로 돌려 본 증거는 시간을 들이지 않으면 만들 수 없다.
Sol의 깊은 추론과 Ultra는 '한 사람의 장고'와 '여러 사람의 병렬 작업'만큼 다르다
OpenAI 공식 설명에 따르면 GPT-5.6 Sol에는 깊이 추론하게 하는 max가 있고, 여기에 더해 ultra는 여러 에이전트를 병렬 작업 라인으로 협업시키는 고성능 설정이다.
비유하자면 이렇다.
Sol에게 깊이 생각하게 하는 경우
뛰어난 설계자 한 명을 회의실에 가둔다.
"서두르지 않아도 돼. 코드도 자료도 전부 읽어. 모순도 찾아. 끝까지 생각해."
이건 아주 강력하다.
Ultra의 경우
설계자, 구현 담당, 버그를 찾는 담당, 부수는 담당, 테스트 담당이 동시에 움직이고 마지막에 결과를 합친다.
요컨대 머리가 단순히 두 배 좋아진다기보다, 놓치는 방향이 분산된다.
OpenAI가 공개한 수치로는 Terminal-Bench 2.1에서 GPT-5.6 Sol이 88.8%, Sol Ultra가 91.9%였다. 차이는 3.1포인트지만 실패 쪽에서 보면 11.2%에서 8.1%가 되어, 단순 계산으로는 실패율이 약 28% 줄어든다. 물론 이것은 하나의 평가일 뿐이고, 모든 일에서 실패가 28% 줄어든다는 뜻은 아니다.
그래도 "거대한 저장소를 읽고, 설계하고, 구현하고, 부수고, 다시 검증한다" 같은 나눌 수 있는 일에서는 이 차이가 어느 방향인지 알기 쉽다.
무거운 Ultra가 왜 결국 더 빠를까
완성까지 걸리는 시간은 대략 이렇게 생각할 수 있다.
총 리드 타임 = 첫 구현 + 재작업 + 재테스트 + 장애 대응 + 오해 바로잡기
많은 사람은 맨 앞의 "첫 구현"만 본다.
그래서 30분 만에 답을 낸 AI는 빠르고, 2시간 걸린 AI는 느려 보인다.
하지만 2시간 걸린 쪽이 나중에 생길 6시간짜리 재작업을 없앴다면, 2시간 쪽이 더 빠르다.
제조업도 마찬가지다.
빨리 만들어 놓고 검사에서 잔뜩 걸러내는 공장보다, 처음부터 공정 능력을 높여 불량을 내지 않는 공장이 결국 더 빠르다.
이번 'Ultra 한 방'이 흥미로웠던 점은, 나중에 발견된 문제 대부분이 근본 설계를 다시 짜야 하는 종류가 아니었다는 것이다.
후공정에서 다듬은 것은 예를 들면 이런 이야기들이었다.
- 모든 worker가 실제 데이터를 진짜로 처리했다는 증거를 한 장에서 보고 싶다.
- 오래된 50/50을 새 감사의 50/50으로 쓰지 마라.
- AI 리뷰를 사람 리뷰라고 쓰지 마라.
- 외부 계측이 없으면 "알 수 없음"이라고 써라.
- worker가 아무것도 하지 않았더라도, 올바른 NOOP(할 일이 없어 의도적으로 아무것도 하지 않음)라면 실패로 취급하지 마라.
이건 "기둥이 거꾸로라서 집을 다시 짓는" 이야기가 아니다.
완성된 공장에 품질관리 부서가 들어와서 배관 라벨과 계기 교정까지 꼬치꼬치 따지는 상태다.
'울트라 원 팬'이 통한 이유
한 방에 완벽했다는 이야기가 아니다.
정확히는 처음의 설계 사상이 꽤 옳았기 때문에 그 뒤의 수정이 국소적인 선에서 끝났다는 이야기다.
처음부터 다음과 같은 질문을 설계에 넣을 수 있었던 점이 컸다.
- 동시에 실행하면?
- 도중에 죽으면?
- 이중으로 처리하면?
- 오래된 상태를 쥔 채 쓰기를 하면?
- 외부 API만 죽으면?
- 실패한 데이터가 영원히 루프를 돌면?
- 검사 자체가 망가지면?
- "전부 성공"이라고 거짓말할 수 있는 샛길이 있으면?
보통은 이런 것들을 실제 운영 장애로 하나씩 배운다.
이번에는 가상의 산업재해를 미리 일으켜 봤다.
서버를 떨어뜨리기 전에 테스트 안에서 떨어뜨려 둔다. 사람이 울기 전에 CI를 울려 둔다.
이 발상은 카오스 엔지니어링과도 궁합이 좋다. 카오스 엔지니어링에서는 평상시 상태를 측정할 수 있는 형태로 정의하고, 현실에서 일어나는 고장을 일부러 넣어서 평상시 상태가 무너지는지 확인한다.
세상 기준으로는 얼마나 대단한가
여기는 과장하지 않는 편이 재미있다.
"세계 최강의 시스템입니다"라고 하면 지나치다.
그렇다고 "AI로 블로그를 쓰고 있습니다"로 끝나는 것도 아니다.
위치를 잡자면 이 정도가 가깝다.
| 비교 대상 | 거리감 |
|---|---|
| AI에게 글을 쓰게 해서 저장 | 꽤 앞서 있다 |
| Zapier / n8n 같은 직렬 자동화 | 장애 복구와 충돌 제어에서 한 단계 이상 앞선다 |
| 개인 SaaS의 착실한 백엔드 | 같은 무대에 선 설계 요소가 꽤 있다 |
| 중소 규모 기업의 사내 자동화 기반 | 충분히 비교 대상이 된다 |
| 전담 SRE(서비스 안정성을 책임지는 엔지니어)가 있는 성숙한 상용 서비스 | 장기 운영 실적, 외부 감시, 보안 보증에서 아직 아래다 |
| Google이나 Amazon급 거대 기반 | 애초에 규모가 다른 우주다 |
개인 개발로서 이상한 점은 글을 쓰는 기능보다 실패했을 때의 작법에 이만큼 코드가 자라 있다는 것이다.
lease, fencing, CAS, outbox, quarantine, failure injection이 글 공장에 살기 시작하면, 블로그라기보다 물류센터다.
Level 7: 공장장이 스스로 개선안을 시험해 보기 시작한다
Level 6에서는 "정답"을 사람이 정한다.
망가지면 그 정답으로 되돌린다.
Level 7에서는 정답의 범위 안에서 더 나은 운영 방법을 스스로 찾는다.
그림은 이렇다.
- 품질, 속도, 비용, 대기 시간, 실패율을 동시에 측정한다.
- 안전 조건은 절대 바꿀 수 없게 해 둔다.
- 새 프롬프트나 처리 순서를 운영에 영향을 주지 않는 shadow(그림자 모드)에서 시험한다.
- 괜찮아 보이면 5%, 20%, 100%처럼 canary(소수에게 먼저 내보내는 단계적 배포)로 넓힌다.
- 품질이 떨어지면 자동으로 원래대로 되돌린다.
- 신뢰성이 나쁠 때는 실험만 멈추고 일반 생산은 계속한다.
- 무엇을 시도했고, 무엇이 좋았고, 왜 채택했는지를 실험 대장에 남긴다.
IBM 자율 컴퓨팅에서 말하는 self-optimization, Google SRE의 error budget(서비스를 느리게 만들기 전까지 감수할 수 있는 실패의 양), AWS의 canary와 rollback을 합친 생각에 가깝다.
다만 지금 당장 운영에 Level 7을 넣을 필요는 없다.
이유는 단순하다. Level 6의 장기 실적을 모으는 중이기 때문이다.
설비가 안정적인지 확인하는 중인데 AI 공장장에게 "오늘부터 라인 속도도 마음대로 바꿔도 돼"라고 하면 원인 분리가 번거로워진다.
지금 한다면 Level 7 본체가 아니라, 모든 worker의 실제 가동을 한 장으로 모으는 관측 강화가 먼저다.
결제하는 달은 '설비 투자 달'로 만들면 강하다
Ultra를 매일의 가벼운 작업에 쓸 필요는 별로 없다.
작은 수정, 정형 감사, 이미 정해진 worker 처리라면 보통의 Sol이나 깊은 추론으로 충분한 경우가 많다.
Ultra가 잘 맞는 건 실패했을 때 되돌리는 비용이 큰 일이다.
- 시스템 전체의 재설계
- 대규모 리팩터링
- worker 체계의 재편
- 모니터링과 복구 설계
- 보안 경계의 재점검
- Level 7의 shadow 기반
- 대량의 테스트와 고장 주입 추가
그래서 쓰는 방식은 평소에는 공장을 돌리고, 대공사 주제를 모아 두었다가, 상위 모드를 쓸 수 있는 시기에 한꺼번에 설비 투자를 하는 것이 합리적이다.
AI 결제를 "매일 조금씩 똑똑해지는 월정액"으로 보기보다, 한 번에 기반을 갈아엎는 공사비로 본다.
이렇게 생각하면 무거운 모델의 가치를 "답변 1회당 가격"만으로 비교하지 않아도 된다.
이번 일주일 남짓에서 가장 큰 배움
가장 큰 배움은 AI의 똑똑함을 "정답률"로만 보지 않는 것이다.
실무에서는 다음 다섯 가지가 효과를 낸다.
- 첫 설계의 정밀도 — 나중에 전부 부수지 않아도 되는가.
- 반증 능력 — 자기 안을 스스로 부술 수 있는가.
- 병렬성 — 설계, 구현, 테스트, 감사를 나눠 진행할 수 있는가.
- 증거성 — "돌아간 것 같다"가 아니라 무엇이 돌아갔는지 남길 수 있는가.
- 복구성 — 실패해도 사람을 부르지 않고 돌아올 수 있는가.
다시 말해 좋은 AI 공장은 "실패하지 않는 공장"이 아니다.
실패를 전제로 하고, 실패해도 멈추지 않고, 가짜 성공을 내지 않고, 어디서든 되돌아올 수 있는 공장이다.
결론: 속도란 끝까지 가는 속도다
일주일 남짓 만에 여기까지 온 이유를 단순히 "AI가 엄청나게 빨랐다"로 끝내면 본질을 놓친다.
효과가 있었던 건 첫 설계에 연산 자원을 두껍게 쓰고, 그 뒤에는 저렴한 일반 운전으로 돌아간 것이었다.
Ultra는 마법의 정답 버튼이 아니다. 재작업을 선불로 없애 버리는 장치에 가깝다.
한 번의 처리가 느려도 완성까지의 총 시간이 짧다면, 그건 빠른 것이다.
그리고 지금 단계에서 필요한 건 더 똑똑한 Level 7을 서둘러 얹는 일이 아니다.
Level 6을 한동안 내버려 두고, 정말 알아서 계속 일하는지 지켜보는 일이다.
공장이 한가해 보이면, 그때 AI 공장장에게 개선 권한을 넘기면 된다.
지금은 아직, 공장장에게 마음대로 라인 속도를 바꾸는 버튼을 주면 너무 재미있어진다.
- OpenAI, GPT-5.6: https://openai.com/index/gpt-5-6/
- OpenAI, GPT-5.6 일본어판: https://openai.com/ja-JP/index/gpt-5-6/
- IBM Research, Autonomic computing: https://research.ibm.com/publications/autonomic-computing-architectural-approach-and-prototype
- IBM Research, Utility functions: https://research.ibm.com/publications/achieving-self-management-via-utility-functions
- Google SRE, Error Budget Policy: https://sre.google/workbook/error-budget-policy/
- Principles of Chaos Engineering: https://principlesofchaos.org/
- AWS, Amazon ECS canary deployments: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/canary-deployment.html
