내가 가장 신뢰한 모델이 나를 막다른 길로 안내했다

2026-06-24 · Ascendy Engineering

TL;DR

Ascendy의 사진 전처리 인프라는 외부 멀티모달 API → 자체 클러스터 GPU → managed GPU → serverless라는 4단계를 실제로 거쳤다. (인프라 기술 디테일은 AI 서빙 진화 시리즈에 이미 적었다 — 이 글은 그 결정의 모델 측면, 즉 어느 모델이 무엇을 추천했고 왜 막혔나에 집중한다.)
그 길의 핵심은 이거다 — 내가 가장 신뢰한 모델(Claude)이 추천한 구조가 막다른 길이었다. 그리고 그 모델은 자기가 추천한 구조 안에서만 맴돌 뿐, 그 바깥을 보여주지 못했다.
막힌 곳을 뚫은 건 다른 계열의 모델이었다. 반대로 그다음 결정적 구현은 다시 Claude가 했다. 어느 단일 모델도 한 번에 정답을 주지 않았다.
정답은 어느 한 모델 안에 없었다. 모델 사이를 오가는 과정에 있었다. 그 과정을 매번 손으로 하다 지쳐서 자동화한 것이 redteam이다.

이 글에 대하여. 여기 적힌 4단계는 Ascendy의 AI 전처리 인프라가 실제로 거친 경로다. 그래서 글이 흔들리지 않는다 — 전부 진짜 겪은 일이기 때문이다. 같은 인프라 여정의 결과물 관점은 AI 서빙 진화 시리즈에 이미 적었다. 이 글은 그 결정에 어떻게 도달했는가에 집중한다.

1. 가장 쉬운 답이 스케일에서 깨졌다

사진 전처리를 외부 멀티모달 API 직접 호출로 시작했다. 몇백 장은 됐다. 하지만 클라우드라면 수천, 수만 장을 다뤄야 하는데 그 구조로는 비용이 터져 서비스 자체가 성립하지 않았다.

한 모델에게 “이걸 어떻게 처리하지?”라고 물으면 가장 쉽고 그럴듯한 답이 먼저 온다. 그 답은 몇백 장에서는 완벽했다. 스케일에서 깨졌을 뿐이다.

2. 신뢰가 막다른 길이 된 지점

직접 GPU로 처리하고 싶다고 하자 Claude가 우리 클러스터에 GPU 노드를 직접 띄우는 방식을 추천했다. 나는 Claude를 가장 신뢰했고, 그대로 갔다.

결과는 쪼개 쓰는 비효율 GPU, 비싼 비용, 그리고 끝없는 OOM이었다. 유저도 없는데 고가 GPU 노드를 24시간 상시로 돌리는 것도 과했다. 무엇보다 — Claude는 자기가 추천한 그 구조 안에서 맴돌 뿐이었다. OOM을 줄이는 법, GPU를 더 잘 쪼개는 법은 알려줬지만, “애초에 이 구조가 아닐 수 있다”는 바깥은 보여주지 못했다.

이게 이 글의 심장이다. 가장 신뢰한 모델일수록, 그 모델의 시야가 곧 내 시야의 한계가 된다. 모델이 틀려서가 아니다. 자기가 세운 전제 안에서 최선을 다하느라, 그 전제 자체를 의심하지 못하는 것이다. 사람도 그렇다.

3. 다른 계열의 모델이 시야를 메웠다

막혀서, 같은 고민을 그대로 GPT와 Gemini에게 가져갔다.

둘은 managed GPU 서비스라는, 그때까지 내가 물어보던 모델의 사고 범위에 없던 축을 제시했다. 자체 상시 GPU 노드 대신 그쪽으로 처리를 돌리니, 수천 장이 처리됐고 OOM도 사라졌다.

중요한 건 그 서비스가 정답이었다는 게 아니다. 막다른 길을 벗어나게 한 축이 처음 모델의 사고 범위 바깥에 있었다는 사실이다. 다른 계열의 모델이 그 빈자리를 메웠다.

4. 방향과 구현이 서로 다른 모델에서 나왔다

이번엔 안 쓸 때도 비용이 나가는 게 아까웠다. 다시 모두에게 물었다. Gemini가 서버리스로 바꾸라는 방향을 줬다. 그 아이디어를 들고 가 실제로 구현한 건 — 다시 Claude였다. 운영비가 급감했다.

여기서 분명히 해두자. 이건 Claude를 깎아내리는 글이 아니다. 마지막 구현은 Claude가 가장 잘했다. 2단계의 막다른 길도 “Claude가 틀렸다”가 아니라 “어떤 단일 모델도 자기 시야 밖을 못 본다”는 구조적 사실의 사례일 뿐이다. 나는 Claude를 버린 게 아니라, 다른 모델과 교차시켰다.

정답은 모델 사이에 있었다

네 단계를 지나고 남은 결론은 하나다.

정답은 어느 한 모델 안에 없었다. 모델 사이를 오가는 과정에 있었다.

계획을 준 모델, 막다른 길로 이끈 모델, 그 길을 벗어나게 한 모델, 최종 구현을 한 모델이 전부 달랐다. 어느 하나에 전부를 맡겼다면 나는 아직 OOM과 싸우고 있을 것이다.

그런데 이 “모델 사이를 오가는 일”을 매번 손으로 하는 건 지치는 일이다. 같은 고민을 세 모델에게 복사해 붙이고, 답을 비교하고, 어느 게 자기 전제에 갇힌 답인지 가려내는 일. 매번 같은 종류의 가치를 줬기 때문에, 결국 자동화했다. 그게 redteam이다 — 작성자와 다른 계열의 모델이 코드를 독립적으로 검토하도록 강제하는 멀티모델 교차검증 하네스.

도구가 먼저 있고 사례를 갖다 붙인 게 아니다. 사례가 먼저 있었고, 그것이 도구를 낳았다. redteam의 원칙은 이 일화를 코드 리뷰로 옮긴 것뿐이다 — 코드를 짠 모델이 그 안전성을 스스로 판단하면 안 되고, 리뷰어는 작성자와 다른 계열이어야 동조를 깬다.

같은 생각을 자율 루프 관점에서 본 글은 루프 엔지니어링의 심장은 검증이다에 적었다.

저작·인용: 이 글은 Ascendy Engineering이 작성했으며 출처 표기 시 재인용 가능합니다. 잘못된 정보를 발견하면 GitHub 이슈로 알려주세요.

Tags: multi-model, redteam, ai-infra, cross-review, build-in-public