Codex 서브에이전트 병렬개발 후기: 토큰은 빠르게 녹고, 파일은 비어 있었다 🫠

이번 프로젝트를 진행하면서 Codex 서브에이전트 기반 병렬개발을 시도해봤다.

가볍게 테스트한 건 아니었다.
이미 프로젝트를 며칠 진행하면서 주간 사용량을 거의 다 쓴 상태였다.

운 좋게 중간에 토큰 리셋이 한 번 되었지만, 다시 이틀 만에 사용량을 거의 다 써버렸다.
그래서 이후에는 최대한 토큰을 아껴가며 개발을 이어가야 했다.

그 과정에서 사용해본 것이 Codex-Spark였다.

처음부터 Spark에게 전체 프로젝트를 통째로 맡긴 건 아니었다.
오히려 Spark가 실수하지 않도록 작업을 아주 잘게 쪼갰다.

진행 방식

먼저 5.5 모델, 인텔리전스 매우 높음 설정으로 전체 개발 플랜과 가이드라인을 만들었다.

그다음 이 전체 플랜을 Spark가 바로 수행할 수 있는 수준의 세부 개발 지침 문서들로 다시 쪼갰다.

즉, Spark 하나가 전체 개발 플랜을 읽고 알아서 판단하는 구조가 아니었다.

각 Spark 서브에이전트는 작업 하나당 지침 문서 하나만 보고, 해당 작업만 부분적으로 완료하는 방식이었다.

구조는 이런 식이었다.

• 전체 개발 플랜 작성
• 기능별, 파일별, 작업별로 세부 지침 분리
• Spark 전용 작업 문서 다수 생성
• 각 Spark는 문서 1개만 보고 단일 작업 수행
• 작업 후 보고 및 현황 로그 업데이트

최대한 복잡도를 낮춘 구조였다.
Spark가 큰 그림을 해석하지 않아도 되도록 만들었다.

그런데도 토큰은 정말 빠르게 녹았다. 🔥

토큰이 부족해서 크레딧까지 충전했다

프로젝트 도중 이미 주간 사용량을 거의 다 쓴 상태였다.

운 좋게 한 번 리셋되었지만, 다시 이틀 만에 거의 다 써버렸다.
결국 토큰이 0에 가까워졌고, 더 진행하려면 다른 방법이 필요했다.

그래서 크레딧도 충전했다.

크레딧으로 어떻게든 개발 플랜은 끝까지 밀어붙였다.
하지만 체감상 크레딧 소모는 꽤 컸다.

구독 플랜 대비 효율적이라고 느껴지지는 않았다.
그래도 여기까지 온 이상, 결과물만 제대로 나오면 된다고 생각했다.

플랜도 있었고, 세부 지침도 있었다.
작업은 잘게 쪼개져 있었고, Spark는 각자 맡은 문서 하나만 보면 되는 구조였다.

그래서 기대감이 있었다.

문제는 결과물이었다

최종 작업이 끝난 뒤 파일들을 확인했다.

파일은 생성되어 있었다.
디렉터리 구조도 있었다.
플랜에 맞는 파일명들도 만들어져 있었다.

겉으로는 작업이 진행된 것처럼 보였다.

그런데 파일을 열어보니 이상했다.

내용이 비어 있었다.

한두 개만 그런 게 아니었다.
생성된 파일 대부분이 빈 파일이었다.

순간 허탈했다.

전체 개발 플랜을 대충 던진 것도 아니었다.
Spark가 헷갈리지 않도록 세부 지침 문서를 엄청 많이 만들었다.
작업 하나당 문서 하나만 보고 진행하도록 했다.

그런데도 결과물은 빈 파일이었다.

보고는 있었다.
로그도 있었다.
파일도 있었다.

하지만 정작 코드가 없었다.

Spark에서 가장 실망했던 부분 🤔

이번 경험에서 가장 크게 느낀 문제는 이것이다.

작업을 충분히 잘게 쪼개도, Spark의 결과물을 그대로 신뢰하기는 어렵다.

만약 전체 프로젝트를 Spark에게 통째로 맡겼다면, 실패할 수도 있다고 생각한다.
큰 맥락을 이해해야 하고, 여러 파일 관계도 고려해야 하고, 판단할 게 많기 때문이다.

하지만 이번에는 그런 방식이 아니었다.

Spark가 할 일은 아주 제한적이었다.
지침 문서 하나를 보고, 거기에 적힌 작업 하나를 수행하는 구조였다.

그럼에도 결과물은 비어 있었다.

이건 단순히 “복잡한 병렬개발이라 실패했다”의 문제가 아니다.
세부 작업 단위로 쪼갠 뒤에도 산출물 검증이 안 됐다는 게 핵심이다.

AI 개발에서 중요한 건 “진행했다는 보고”가 아니다.
실제로 파일 안에 코드가 있어야 한다.
실행 가능해야 한다.
최소한 결과물이 존재해야 한다.

이번 경우에는 그 기본 기준을 통과하지 못했다.

한 번 더 해봤지만 결과는 같았다

처음에는 내 설정 문제일 수도 있다고 생각했다.

지침 문서가 부족했나?
작업 분리가 애매했나?
Spark가 볼 문서 범위가 너무 넓었나?

그래서 같은 방식으로 다시 한 번 시도했다.

하지만 결과는 크게 달라지지 않았다.

결국 남은 건 더 줄어든 사용량과, 또다시 비어 있는 파일들이었다. 🫠

결론: Spark는 세부 작업 기반 병렬개발에도 조심해야 한다

내 기준에서 Codex-Spark는 현재 병렬개발에 적합하지 않았다.

특히 이번 사례는 단순히 Spark에게 큰 작업을 맡겼다가 실패한 게 아니다.

전체 개발 플랜을 세우고,
그걸 Spark 전용 세부 작업 문서로 쪼개고,
각 Spark가 문서 하나만 보고 작업하게 했는데도 실패했다.

이 지점이 가장 중요하다.

Spark는 간단한 코드 조각이나 짧은 수정 작업에는 쓸 수 있을지 모른다.
하지만 여러 Spark가 각자 세부 지침을 따라 작업하고, 그 결과물을 모아 개발을 진행하는 구조에서는 신뢰하기 어려웠다.

특히 이런 작업에는 조심해야 한다.

• 여러 파일을 생성하는 작업
• 작업 단위를 많이 쪼개야 하는 개발
• 지침 문서 기반으로 진행하는 서브에이전트 작업
• 보고와 실제 산출물이 반드시 일치해야 하는 작업
• 토큰과 크레딧 비용이 부담되는 작업

이번 실험에서 Spark는 작업 중인 것처럼 보이게 만드는 능력은 있었지만, 검증 가능한 결과물을 안정적으로 남기는 능력은 부족했다.

이번 경험에서 얻은 교훈 📝

첫째, 작업을 잘게 쪼갠다고 안전해지는 건 아니다.
세부 지침을 줘도 결과물 검증은 반드시 필요하다.

둘째, AI의 진행 보고를 그대로 믿으면 안 된다.
로그보다 중요한 건 실제 파일 내용이다.

셋째, 파일이 생성됐다고 개발이 끝난 게 아니다.
파일 안에 코드가 있어야 하고, 실행 가능해야 한다.

넷째, 토큰을 아끼려고 선택한 모델이 오히려 더 비싼 선택이 될 수 있다.
결과물이 없으면 사용량을 얼마나 아꼈는지는 의미가 없다.

다섯째, 크레딧 충전은 신중해야 한다.
구독 대비 체감 소모가 컸고, 결과물이 실패하면 비용 부담이 더 크게 느껴진다.

앞으로는 이렇게 쓸 생각이다

앞으로 Spark는 병렬개발보다는 아주 작은 단위 작업에만 제한적으로 사용할 것 같다.

특히 Spark처럼 저비용·고속 실행을 기대하고 쓰는 모델일수록, 검증 없이 오래 돌리면 위험하다.

최종 정리

이번 경험은 꽤 비싼 교훈이었다.

프로젝트를 진행하면서 주간 사용량을 며칠 만에 거의 다 썼고, 운 좋게 한 번 리셋되었지만 다시 이틀 만에 거의 다 써버렸다.

토큰을 아껴야 하는 상황에서 Spark를 선택했다.
부족한 부분은 크레딧까지 충전해서 어떻게든 개발 플랜을 마무리했다.

그리고 기대감을 갖고 결과물을 열어봤다.

하지만 파일은 비어 있었다.

더 허탈했던 건, Spark에게 전체 개발을 통째로 맡긴 게 아니었다는 점이다.

전체 플랜을 세부 작업으로 쪼개고,
Spark 전용 지침 문서를 많이 만들고,
작업 하나당 문서 하나만 보게 했다.

그런데도 결과물은 빈 파일이었다.

결론은 간단하다.

Codex-Spark는 현재 기준으로 세부 지침 기반 병렬개발에도 신뢰하기 어려웠다.
작업을 잘게 쪼개도, 산출물 검증 없이는 위험하다.

이번 실험의 한 줄 요약은 이거다.

“작업은 잘게 쪼갰고, 토큰과 크레딧도 썼지만, 결과물은 비어 있었다.” 🫠