AutoBe: 약한 로컬 LLM들이 AI 백엔드 생성기의 아키텍처를 어떻게 고쳤는가

무슨 일이 있었나

AutoBe는 TypeScript, NestJS, Prisma를 사용하여 완전한 백엔드 애플리케이션을 생성하는 오픈소스 AI 에이전트입니다. 처음에는 100% 컴파일 성공을 달성했지만, 코드는 유지보수가 불가능했습니다—코드 재사용이 없어서 작은 변경 사항마다 모든 것을 다시 생성해야 했습니다. 팀은 모듈식 코드 생성 중심으로 시스템을 재구축했고, 이로 인해 성공률이 즉시 40%로 떨어졌습니다.

디버깅의 돌파구

새로운 아키텍처가 모듈 간 의존성을 도입했을 때, 팀은 의도적으로 약한 로컬 LLM을 사용하여 존재하지 않았던 버그를 찾았습니다. qwen3-30b-a3b-thinking 모델은 약 10%의 성공률을 보였고, AST 스키마 모호성과 잘못된 구조를 드러냈습니다. qwen3-next-80b-a3b-instruct 모델은 약 20%의 성공률을 보였고, 중첩 관계에서의 타입 불일치와 경계 사례를 드러냈습니다.

그 낮은 성공률은 가치 있었습니다: 각 수정 사항이 전체 시스템을 강화했습니다. 스키마가 30B 모델이 오해할 수 없을 정도로 정확해지면, 더 강력한 모델도 틀리지 않습니다. 이 접근 방식은 또한 로컬 LLM의 비용 이점을 강조합니다—경계 사례를 발견하려면 수백 번의 생성-컴파일-진단 주기가 필요하며, 이는 클라우드 API 가격으로는 비용이 너무 높습니다.

아키텍처 전환

팀은 프롬프트 엔지니어링에서 검증 피드백이 있는 스키마 설계로 전환했습니다. 시스템 프롬프트를 거의 없애고 모든 제약 조건을 함수 호출 스키마로 옮겨, 검증 피드백이 가르치도록 했습니다. AutoBe는 LLM이 생성하기 특히 어려운 세 가지 AST 유형을 사용합니다: AutoBeDatabase(Prisma 모델, 관계, 인덱스), AutoBeOpenApi(OpenAPI 스키마, 엔드포인트, DTO), AutoBeTest(30개 이상의 표현식 유형).

이러한 구조는 무제한 유니온 타입, 무제한 깊이, 재귀 참조를 포함하기 때문에 어렵습니다. 예를 들어, 컴파일러 AST에는 IArrayLiteralExpression 및 IObjectLiteralExpression과 같은 유형이 포함되어 있으며, 이는 IExpression[]에 대한 재귀 참조를 포함합니다.

결과

검증 피드백만으로 팀은 6.75%의 원시 함수 호출 성공률에서 100%로 향상되었습니다. 이제 GLM v5로 다시 100% 성공을 달성했으며, 다른 로컬 모델도 성능이 향상되고 있습니다.