프롬프팅을 넘어: 정밀한 자가 수리(Surgical Self-Repair) 기능을 갖춘 4단계 LLM 컴파일러 구축하기

단일 프롬프트는 종종 일관성이 없고 검증되지 않은 AI 출력을 생성합니다. 이를 해결하기 위해, 저는 영어 단어를 입력받아 즉시 사용 가능한 JSON 블루프린트(blueprint)로 변환하는 다단계 LLM 컴파일러인 Compyl을 구축했습니다.

Compyl은 일반적인 영어를 작동 가능한 애플리케이션을 구동하는 데 즉시 사용할 수 있는 완전하고 검증된, 기계 판독 가능한 JSON 블루프린트(UI 스키마(schema), API 스키마, DB 스키마 및 인증 규칙)로 변환합니다.

입력: "로그인, 연락처, 대시보드, 역할 기반 액세스 및 결제 기능이 있는 CRM을 구축해줘. 관리자는 분석 데이터를 볼 수 있어야 해."
출력: 4개 계층 전체에 걸쳐 완전히 동기화된 JSON 블루프린트.

왜 다단계(Multi-Stage)인가?

더 나은 이해와 오류 검사를 위해 워크플로우를 모듈별로 나누고 싶었습니다:

단계	이름	목적
1단계	렉서 (Lexer)	원시 입력을 구조화된 토큰(엔티티, 역할, 기능)으로 파싱합니다.
...

각 단계는 자체적인 시스템 프롬프트(system prompt), Pydantic 출력 스키마, 그리고 재시도 로직(retry logic)을 가진 별도의 Groq API 호출입니다.

핵심 비결: 정밀한 검증(Surgical Validation) + 수리(Repair)

이것이 Compyl을 단순한 래퍼(wrapper)와 차별화하는 지점입니다. 생성 후, 네 가지 엄격한 계층 간 의존성 검사가 자동으로 실행됩니다:

• UI ↔️ API: 모든 UI 컴포넌트는 실제 API 엔드포인트(endpoint)와 매핑되어야 합니다.
• API ↔️ DB: 모든 API 엔드포인트는 일치하는 DB 테이블을 가져야 합니다.
• UI ↔️ Auth: 인증 규칙에서 사용되는 모든 경로는 UI 스키마에 존재해야 합니다.
• Auth ↔️ System: 페이지에서 사용되는 모든 역할은 인증 스키마에 존재해야 합니다.

"정밀한(Surgical)" 수정

검사에 실패할 경우, Compyl은 전체 출력을 버리고 다시 시도하지 않습니다(이는 느리고 비용이 많이 듭니다). 대신, **표적 수리(targeted repair)**를 수행합니다. 즉, 오류 로그와 함께 문제가 발생한 계층만 LLM에 다시 보내 정밀한 수정을 요청합니다.

LLM vs SLM — 의도적인 트레이드오프 (Tradeoff)

• 1~3단계 (Groq를 통한 Llama 3.3 70B): 주로 사용자의 프롬프트가 구체적이지 않을 때 창의적인 입력과 의사결정을 수행하기 위해 사용되었습니다.
• 4단계 (규칙 기반 / 향후 SLM): 이 단계는 순수하게 기계적인 린팅 (Linting) 작업이므로, 3B~7B 규모의 소형 언어 모델 (SLM, Small Language Model)로 교체하기로 결정했습니다. 예상대로 비용은 약 30%, 지연 시간 (Latency)은 약 40% 감소했습니다.

평가 및 엣지 케이스 (Edge Cases)

10개의 실제 제품 프롬프트와 6개의 극단적인 엣지 케이스를 대상으로 테스트했습니다:

• 성공률 (Success Rate): 100% (정밀 재시도 (Surgical retry) 이후).
• 평균 지연 시간 (Avg. Latency): 엔드 투 엔드 (End-to-end) 기준 11.4초.
• 수정 성공률 (Repair Success Rate): 95.6% (감지된 46개의 계층 간 오류 중).

엣지 케이스 처리 방식:

• "멋진 것 좀 만들어줘" → 문맥을 추론하여 완전히 기능하는 엔터테인먼트 앱을 구축했습니다.
• "로그인이 있지만 인증도 필요 없는 앱" → 별도의 Guest 및 Registered User 역할을 생성함으로써 충돌을 지능적으로 해결했습니다.
• "Uber + Amazon + Instagram 같은 걸로 만들어줘" → 시스템을 깨뜨리지 않고 이들을 6개의 DB 테이블과 3개의 역할로 일관성 있게 병합했습니다.

더 시도해보고 싶은 사례들이 더 있었지만, Groq에서 제공하는 100k 토큰을 모든 사례를 시도하다가 결국 다 소진하여 한계에 도달했습니다. 하지만 더 구체적인 내용을 위해 토큰 소진 오류, 지연 시간 및 기타 모든 지표를 상세히 기록하여 제 GitHub README와 Google Doc에 남겨두었습니다.

기술 스택 (Tech Stack)

• LLM 엔진: Groq를 통한 Llama 3.3 70B (엄청나게 빠른 추론)
• 검증 (Validation): Pydantic v2 (엄격한 데이터 계약)
• 백엔드: FastAPI + Uvicorn
• 런타임 증명 (Runtime Proof): 최종 JSON으로부터 원시 SQL CREATE 문과 Flask 라우트 스켈레톤 (Skeleton)을 생성합니다.
• 호스팅: HuggingFace Spaces 상의 Docker (콜드 스타트 없음).

핵심 요약 (Key Takeaways)

1. 가장 어려운 부분은 LLM 프롬프트가 아니었습니다. 코드를 작성하기 전에 Pydantic을 사용하여 유효한 출력값이 정확히 어떤 모습이어야 하는지를 정의하는 것이었습니다.
2. 초기에는 창의적/디자인 단계에서 0.3을 사용했지만, 결정론적인 (Deterministic) 코드 수정을 강제하기 위해 수정 단계에서는 0.1로 낮추었습니다.

링크 및 피드백

• 🚀 라이브 데모 (Live Demo): HuggingFace Spaces
• 💻 소스 코드 (Source Code): GitHub Repository

이 프로젝트에 대한 여러분의 의견을 듣고 싶습니다 :)