Sol 6.1 High의 과도한 엔지니어링으로 인한 16시간짜리 배포 악몽

Codex에서 여러 전문 서브 에이전트를 조율하는 메인 오케스트레이터로 Sol 6.1 High를 쓰고 있는데, 최근에 AI가 주도하는 과잉 엔지니어링의 끝판왕을 경험했다.

내 애플리케이션 중 하나를 프로덕션에 배포하는데 무려 16시간이나 걸렸다. 그전 배포도 14시간이나 걸렸는데 말이지.

더 골 때리는 건, 이 과정에서 내 ChatGPT Business 구독 사용량의 90% 이상을 다 처먹었다는 거다.

배포 아키텍처, 소스 코드, 운영 로그, 배포 이력을 싹 다 뒤져서 기술 감사를 요청했는데, 결과가 아주 가관이었다.

감사 결과:

• 배포 시간의 95% 이상이 실제 배포 작업이 아니라, 지가 스스로 만든 차단 요소, 쓸데없는 검증, 복구 절차 때문에 날아갔음.

• 배포 프레임워크가 50개 이상의 모듈로 불어나 있었음.

• 메인 배포 스크립트만 파이썬 코드가 대략 9,800줄이었음.

• 11번이나 연속으로 배포가 막히면서 코드 수정, 테스트, 커밋, 복구 절차를 무한 반복함.

• 배포 중에 기록된 6번의 릴리스 변경 사항 중 5번이 배포 인프라 자체를 고치는 거였음. 실제 애플리케이션 기능 수정은 딱 하나뿐이었음.

• 시스템이 소스 파일을 계속 스캔하고, 해시를 다시 계산하고, 데이터베이스 구조를 재검증하고, 과거 배포 아티팩트를 계속 체크함.

• 배포 과정에 커스텀 SQL 파서, 파이썬 AST 분석, 암호화 상태 바인딩, 점점 복잡해지는 복구 메커니즘이 덕지덕지 붙어 있었음.

참고로 이 애플리케이션 자체는 꽤 작은 규모다. 프론트엔드 빌드에 25초, 백엔드 준비에 25초, PostgreSQL 백업에 80초 정도면 끝난다.

근데 배포하는 데 16시간이 걸린 거다.

가장 빡치는 건 이 복잡함이 쌓여가는 방식이다.

에이전트가 예외 상황이나 배포 실패를 마주칠 때마다, 프로세스를 단순화하거나 당장 문제를 해결하는 대신, 자꾸 추상화 계층, 검증 레이어, 호환성 메커니즘, 영구적인 안전장치 같은 걸 추가해댔다.

결국 배포 인프라가 너무 빡빡해져서, 문제 하나 고치면 다른 문제가 터지는 꼴이 됐다.

배포를 최적화하겠다고 시도한 것조차 복잡함만 더 키웠다.

결과적으로 시스템은 엄청나게 방어적이고 꼼꼼하게 설계된 것처럼 보이지만, 실제로는 유지보수도, 수정도, 배포도 하기 힘든 괴물이 되어버렸다.

물론 프로덕션 배포에 안전장치가 필요한 건 안다. 특히 데이터베이스나 데이터 무결성, 복구 관련해서는 더더욱. 내가 까는 건 백업이나 적절한 체크를 하지 말라는 게 아니다. 오히려 그게 문제가 되어버릴 정도로 과도한 안전장치를 만드는 걸 지적하는 거다.

이건 멀티 에이전트 오케스트레이션의 문제점을 잘 보여주기도 한다.

구현, 테스트, 감사를 담당하는 전문 서브 에이전트들이 있는데도, 지나치게 신중한 메인 오케스트레이터가 과도한 조율, 반복적인 검증, 불필요한 범위 확장을 일삼으면서 그 장점들을 다 깎아먹고 있다.

Sol에서 개선됐으면 하는 점들:

1. 방어적인 추상화를 쌓기보다는 더 단순하고 유지보수하기 쉬운 솔루션을 우선할 것.

2. 기존 안전장치로 충분할 때는 그걸 인정할 것.