왜 우리는 Runtime에서 LLM을 금지했는가 — 그리고 우리가 대신 하는 일
Source: Dev.to
위 링크에 있는 전체 글을 번역하려면, 번역이 필요한 본문 텍스트를 제공해 주시겠어요?
코드 블록, URL, 마크다운 형식 등은 그대로 유지하면서 한국어로 번역해 드리겠습니다.
Runtime에서 LLM 문제
대부분의 AI 백엔드 도구는 런타임에 LLM을 사용합니다. 모든 API 호출은 모델 추론을 트리거하고, 모든 응답은 확률적입니다. 런타임에 LLM이 API 요청을 처리하면 다음과 같은 현상이 발생합니다:
| Issue | Description |
|---|---|
| 비결정성 | 동일한 요청 → 매번 다른 응답. |
| 지연 시간 | 모델 부하에 따라 요청당 800 ms – 3 s. |
| 비용 | 트래픽에 비례하여 선형적으로 증가하는 요청당 추론 비용. |
| 보안 | 모든 엔드포인트에 존재하는 프롬프트 인젝션 표면. |
| 감사 가능성 | “왜 API가 이 값을 반환했나요?” → “모델이 그렇게 결정했어요.” |
프로토타입 단계에서는 허용될 수 있지만, 결제, 예약, 사용자 데이터 등을 처리하는 프로덕션 백엔드에서는 구조적인 위험이 됩니다.
우리의 접근 방식: 설계 시점 AI
Fascia는 AI를 설계 시점에만 사용합니다. 비즈니스를 자연어로 설명하면 AI가 구조화된 사양(코드가 아니라)을 생성합니다. 이 사양은 다음을 정의합니다:
- Entities – 필드, 관계, 상태 머신 및 불변 조건을 가진 비즈니스 객체.
- Tools – 타입이 지정된 입력/출력, 트리거 유형 및 흐름 그래프를 갖는 API 엔드포인트.
- Policies – 배포 전에 위험한 패턴을 차단하는 설계 시점 규칙.
런타임에서는 deterministic executor(Go로 작성되었으며 Cloud Run에서 약 50 ms 콜드 스타트) 가 사양을 읽고 실행합니다. LLM 추론이 없으며, 변동성도 없습니다.
런타임 실행 흐름
- 입력 검증 – 사양에 정의된 JSON 스키마에 따라.
- 인가 – JWT 검증, RBAC 역할 확인, 행 수준 소유권.
- 정책 확인 – 설계 시점 규칙을 결정적으로 적용.
- 트랜잭션 시작 – 명시적 경계, 자동 커밋 없음.
- 플로우 그래프 실행 – 타입이 지정된 노드(읽기, 쓰기, 변환, If/Switch)로 구성된 DAG.
- 불변 조건 적용 – 커밋 전에 비즈니스 규칙을 검증.
- 커밋 또는 롤백 – 전부 적용 또는 전부 취소, 부분 상태 없음.
- 감사 로그 기록 – 추가 전용, 무조건, 모든 실행에 기록.
- 타입된 응답 반환 – 사양의 출력 스키마와 일치.
지름길은 없습니다. “이 엔드포인트는 특수합니다”라는 예외도 없습니다. 이 경직성이 바로 특징입니다.
Safety Agent (설계 단계)
Safety Agent는 설계 단계에서 실행되며 다음을 수행합니다:
- 멀티 모델 교차 검증 – Claude + GPT‑4 (다른 모델 패밀리).
- 정적 분석 흐름 그래프에서 불안전한 패턴을 찾음.
- 위험 분류 – Green(안전), Yellow(경고), Red(차단).
- 테스트 케이스 생성 명세 불변조건으로부터.
Red 위험은 오버라이드 없이 배포를 차단합니다; 설계를 수정해야 합니다.
Red 패턴 예시
| 패턴 | 차단되는 이유 |
|---|---|
| 트랜잭션 경계 내에서 결제 호출 | 트랜잭션이 롤백되면 결제를 취소할 수 없습니다. |
UPDATE without WHERE clause | 예기치 않은 행에 영향을 줄 수 있습니다. |
| 트랜잭션 경계 없이 쓰기 | 실패 시 부분적인 상태가 남을 수 있습니다. |
| 소프트 삭제 대신 하드 삭제 | 복구할 수 없는 데이터 손실. |
설계 시 제약 조건
All intelligence must be captured in the spec at design time. The runtime cannot “think.” This means:
- Complex conditional logic → modeled as flow‑graph branches. → * 복잡한 조건 로직 → 흐름 그래프 분기로 모델링됩니다.
- Custom business rules → expressed in a restricted Value DSL (no arbitrary code). → * 맞춤 비즈니스 규칙 → 제한된 Value DSL(임의 코드 없음)로 표현됩니다.
- External API calls → explicit nodes with retry/timeout configuration. → * 외부 API 호출 → 재시도/시간 초과 구성이 포함된 명시적 노드.
These constraints are intentional; they make production backends provable, not probabilistic. → 이러한 제약은 의도된 것이며, 프로덕션 백엔드를 증명 가능하게, 확률적이 아닌 만들습니다.
메트릭 비교
| 메트릭 | LLM‑at‑runtime | Spec‑driven (Fascia) |
|---|---|---|
| 응답 시간 | 800 ms – 3 s (가변) | 12 – 50 ms (일관됨) |
| 결정론 | 아니오 | 예 |
| 프롬프트 인젝션 위험 | 모든 엔드포인트 | 제로 (런타임에 프롬프트 없음) |
| 요청당 LLM 비용 | 예 | 제로 |
| 감사 로그 | “모델이 결정” | 스펙 버전 + 실행 로그 |
로드맵
우리는 Fascia를 공개적으로 구축하고 있습니다. 출시 전, 1인 창업자, 150개 이상의 PR을 진행했습니다.
다음 시리즈: 리스크 엔진 – 우리가 초록, 노랑, 빨강을 분류하는 방법.