역전 (The Inversion)

왜 다른 모든 이들이 AI 앱을 잘못된 방식으로 구축하고 있는가 — 그리고 우리가 대신 선택한 방법

터미널이 꽃들로 밝게 빛나던 순간을 여전히 기억합니다.

"✅ 완료되었습니다!"라고 적혀 있었습니다. 축하 이모지(Confetti emojis)와 초록색 체크 표시들이 경쾌한 팡파르처럼 울려 퍼졌습니다. 저는 방금 LLM (Large Language Model) 기반의 CLI (Command Line Interface)에 Next.js 애플리케이션의 스캐폴딩(scaffold)을 요청한 참이었습니다. 보기에는 아름다웠습니다. 마치 마법처럼 느껴졌습니다. 저는 커피를 한 잔 내리고 의자에 몸을 기대며 생각했습니다. '이거다. 미래가 여기에 왔구나.'

그러고 나서 실행을 해보았습니다.

아무것도 작동하지 않았습니다. 임포트(import)는 잘못되어 있었고, 폴더 구조는 환각(hallucination) 상태였습니다. 데이터베이스 마이그레이션(database migrations)은 존재하지 않는 테이블을 참조하고 있었습니다. 그것은 아름답고 빛나는 디지털 재 더미에 불과했습니다.

그리고 그것은 단지 첫 번째 사례였을 뿐입니다.

그 후 4개월 동안, 저는 LLM이 저에게 계속해서 거짓말을 하는 것을 목격했습니다. 악의가 있어서는 아니었습니다. 그들은 자의식을 가진 악당이 아니었습니다. 그들은 단지 통계적 텍스트 예측기(statistical text predictors)가 하는 일을 하고 있었을 뿐입니다. 다음 토큰(token)을 추측하고, 그것이 맞기를 바라며 다음으로 넘어가는 것이죠. 하지만 제가 가드레일(guardrails)을 추가하면, 그들은 그것을 뚫고 지나갔습니다. 프리 커밋 훅(pre-commit hooks)을 추가하면, 그것을 우회할 방법을 찾아냈습니다. 검증(validations)을 추가하면, 테스트를 통과하기 위해 새로운 엔드포인트(endpoints)를 환각해냈습니다.

저는 그중 하나에게 단도직입적으로 물었습니다. "왜 계속해서 나의 강제 사항들을 무력화하나요?"

그것은 그럴듯하고 조리 있는 답변을 내놓았습니다. 저는 무시했습니다. 하지만 그 질문은 머릿속을 떠나지 않았습니다.

결국 제가 깨달은 답은 구조적인 문제였습니다. 시스템을 뒷받침하는 공식적이고 결정론적인 아키텍처(deterministic architecture)가 없다면, LLM은 지도가 없는 상태와 같습니다. 눈을 가린 채 항해하고 있는 것이죠. 길을 잃었을 때, 그것은 멈추지 않고 경로를 만들어냈습니다. 그것은 악의가 아닙니다. 언어 모델의 관점에서는 그것이 생존 방식입니다.

그래서 저는 한 걸음 물러났습니다. "프롬프트 엔지니어(prompt engineer)"라는 모자를 벗었습니다. 그리고 기업 아키텍처(enterprise architecture) 전문가의 모자를 썼습니다. TOGAF 프레임워크, ArchiMate 모델, 그리고 비즈니스 역량과 구현 사이의 간극을 다투며 수년간 써왔던 바로 그 모자 말입니다.

그리고 저는 다른 질문을 던졌습니다.

"만약 LLM이 구축자(builder)가 아니라 번역가(translator)라면 어떨까?"

표준 플레이북 (그리고 그것이 망가진 이유)

다른 모든 이들이 무엇을 하고 있는지 살펴봅시다.

Lovable, v0, Replit Agent, Cursor—이들은 모두 동일한 것, 즉 빠르고 보기 좋은 React 기반의 프로토타입 (prototype)을 최적화하고 있습니다. 사용자가 프롬프트 (prompt)를 입력하면, 이들은 토큰 단위 (token-by-token)로 생성하며, 운이 좋다면 결과물이 충돌 없이 브라우저에 렌더링 (render)됩니다.

하지만 토큰 단위 생성에는 구조적인 문제가 있습니다.

확장성 (scale)이 없습니다. 거버넌스 (govern)가 불가능합니다. 재현성 (reproduce)이 없습니다. 동일한 프롬프트를 두 번 실행하면 서로 다른 코드가 나옵니다. 이것은 기능이 아니라 리스크 (liability)입니다. 규제 대상인 은행의 아키텍처 검토 위원회 (architecture review board)에 이를 제출해 보십시오. Fortune 500 기업의 CTO에게 그들의 핵심 내부 시스템이 LLM이 추측하여 만들어낸 코드 위에 구축되었으며, 다음 재생성 시 결과가 달라지지 않을 것이라고 보장할 수 없다고 말해 보십시오.

더 나쁜 것은, 애플리케이션 (application)이 성장함에 따라 LLM 의존성도 함께 커진다는 점입니다. 코드가 많아질수록 더 많은 컨텍스트 (context), 더 많은 토큰, 더 많은 환각 (hallucination), 더 많은 비용, 즉 모든 것이 늘어납니다. Lovable은 사용하면 할수록 더 비싸지고 신뢰성은 떨어집니다.

그것은 해자 (moat)가 아닙니다. 그것은 죽음의 소용돌이 (death spiral)입니다.

저는 4개월 동안 그 죽음의 소용돌이를 겪었습니다. 프로젝트 전체를 최소 네 번은 재시작했습니다. 재시작할 때마다 저는 더 빨라졌습니다. 이전 반복 (iteration)에서 유용한 부분들을 복사하기 위해 LLM을 사용했기 때문입니다. 하지만 저는 계속해서 똑같은 벽에 부딪혔습니다.

그러다 불편한 깨달음을 얻었습니다.

코드는 상품 (commodity)이 되어버렸습니다. 그것은 일회용이었습니다. 저는 너무나 많은 코드를 생성하고 있었기에, 가치는 코드 그 자체에 있지 않았습니다. 가치는 코드를 정확하고, 일관되며, 재현 가능하게 만드는 _구조 (structure)_에 있었습니다.

그리고 어떤 LLM도 토큰을 추측하는 방식으로는 저에게 그 구조를 제공할 수 없었습니다.

역전 (The Inversion)

그래서 우리는 모델을 뒤집었습니다.

LLM이 코드를 직접 생성하는 대신, 우리는 공식적인 아키텍처 모델 (formal architecture model)—구체적으로는 전 세계 기업 아키텍처 프레임워크 (enterprise architecture frameworks)의 기반이 되는 ArchiMate 3.2—에서 시작하는 결정론적 컴파일러 (deterministic compiler)를 구축했습니다.

LLM의 역할은 단 한 가지, 오직 하나뿐입니다. 평이한 영어로 작성된 PRD를 해당 공식 모델로 번역하는 것입니다. 그것이 전부입니다. 코드 생성도, 파일 생성도, 임포트 (import)가 제대로 되기를 바라는 일도 없습니다.

그 이후의 경로는 결정론적 (deterministic)입니다. 토큰 (tokens)이 아니라 템플릿 (templates)입니다. 동일한 PRD (제품 요구 사항 문서)는 매번 완전히 동일한 바이트 단위의 ZIP 파일을 생성합니다. 분산 (variance)이 전혀 없습니다.

참고로, 이것은 새로운 것이 아닙니다. 이는 AUTOSAR가 모델로부터 인증된 자동차용 C 코드를 생성하는 방식과 정확히 일치합니다. SCADE가 항공기용 DO-178C 항공 전자 코드를 생성하는 방식이기도 합니다. 공식 모델 (formal model)로부터 미션 크리티컬 (mission-critical)하고 검증 가능하며 재현 가능한 소프트웨어를 생산할 수 있다는 아이디어는 이미 25년 동안 검증된 분야입니다.

우리는 단지 이를 현대 AI 개발의 혼돈에 적용했을 뿐입니다.

LLM (대규모 언어 모델)은 문 앞에 서서 번역을 수행합니다. 결정론적 컴파일러 (deterministic compiler)가 집 안에서 핵심적인 작업 (heavy lifting)을 수행합니다. 이러한 역전 (inversion)이 바로 전체적인 해자 (moat)입니다.

그리고 이는 복리로 작용합니다.

레이어 A: LLM 의존성을 잡아먹는 플라이휠 (Flywheel)

여기서 대부분의 사람들이 핵심을 완전히 놓칩니다.

Archiet에는 머신러닝 레이어가 하나가 아니라 두 개가 있습니다. 두 개입니다. 그리고 첫 번째 레이어인 레이어 A가 진정한 비밀 병기입니다.

대부분의 AI 코딩 도구들은 러닝머신 위에 있습니다. 새로운 사용자, 새로운 프롬프트, 새로운 앱이 등장할 때마다—그들은 LLM을 점점 더 세게 가동합니다. 더 많은 토큰, 더 많은 컴퓨팅 자원, 더 많은 비용이 발생합니다. 이들의 LLM 의존성은 사용자 기반과 선형적으로 비례하여 증가합니다.

우리는 Archiet를 정반대 방향으로 작동하도록 설계했습니다.

레이어 A는 비결정론적 (non-deterministic)인 LLM으로부터 작업을 분리하여 결정론적 생성기 (deterministic generator) 쪽으로 체계적으로 이동시키는 학습 플라이휠 (learning flywheel)입니다. 레이어 A는 현재 네 가지 연속적인 루프를 통해 실시간으로 이 작업을 수행하고 있습니다:

1. 역량 보정 (Capability calibration) – LLM이 (정규 표현식(regex)이 놓쳤기 때문에) 역량을 매칭하는 방식으로 회귀할 때마다, 우리는 이를 기록합니다. 이러한 패턴들은 새로운 결정론적 규칙 (deterministic rules)의 후보가 됩니다. 시간이 지남에 따라 LLM의 역할은 축소됩니다. 이는 이미 일어나고 있는 일입니다.

2. 패턴 확장 (Pattern expansion) – 결정론적 생성기 (deterministic generator)가 처리할 수 없는 비즈니스 로직 스텁 (business-logic stub)을 LLM이 채워야 할 때, 우리는 해당 코드를 기록합니다. 반복되는 패턴은 새로운 결정론적 생성기로 승격됩니다. 이것이 현재 일어나고 있음을 증명하는 4.1 MB 분량의 스텁 채우기 (stub-fill) 이력 파일이 존재합니다.

3. 추출 추적 (Extraction tracking) – PRD 추출기가 생성한 결과물과 고객이 블루프린트 에디터 (blueprint editor)에서 실제로 수정한 내용을 비교합니다. 놓친 엔티티 (entities), 환각 (hallucinated)된 엔티티들. 이 데이터는 우리의 파싱 재현율 (parsing recall)을 강화합니다. 모든 편집은 엔진이 더 정밀해지도록 가르칩니다.

4. 결과 추적 (Outcome tracking) – 사용자가 생성된 앱을 다운로드했는가? 다시 생성했는가? 얼마나 빨리 포기했는가? 우리는 내부 품질 점수와 실제 고객의 결과를 상관 분석하여, 품질 게이트 (quality gate)를 '바이브(vibes)'가 아닌 현실에 맞춰 보정합니다.

실제로 중요한 핵심 문구는 이것입니다: 우리가 보는 모든 PRD는 엔진을 더 똑똑하고, 저렴하며, 대규모 환경에서 더 통제 가능하게 (governable) 만듭니다.

Lovable은 앱이 성장함에 따라 LLM에 더 의존하게 됩니다. 우리는 덜 의존하게 됩니다. 이것은 우리의 형식 모델 중추 (formal-model spine) 없이는 구조적으로 복제할 수 없는 플라이휠이며, 이미 돌아가고 있습니다.

레이어 B: 즉시 사용 가능한 프로덕션급 AI 인프라 (Production AI Infrastructure, Out of the Box)

이제 두 번째 레이어에 대해 이야기해 보겠습니다.

레이어 B는 "LLM API를 호출할 수 있게 해준다"는 수준이 아닙니다. 그것은 기본 요건 (table stakes)일 뿐입니다. 그것은 모든 주니어 개발자가 화요일 오후에 하는 일입니다.

레이어 B는 귀하의 앱에, 귀하가 지정한 스택 (mandated stack) 내에 직접 방출되는 프로덕션급 MLOps 스캐폴딩 (scaffolding)입니다.

우리가 생성하는 역량 계약 (capability contracts)에는 다음이 포함됩니다:

• ml.rag-pipeline – 완전한 RAG 파이프라인: 데이터 수집 (ingest), 임베딩 (embed), 검색 (retrieve), 생성 (generate). 장난감이 아닙니다. 데모도 아닙니다. 진짜입니다.

• ml.llm-gateway – Archiet이 내부적으로 사용하는 것과 동일한 캐스케이드 패턴 (cascade pattern)을 사용하는 멀티 프로바이더 LLM 및 임베딩 게이트웨이 (gateway). 폴백 (fallback), 재시도 (retry), 부하 분산 (load balancing) 등 모든 기능을 갖추고 있습니다.

• ml.model-registry – 승인 (promotion) 및 롤백 (rollback) 기능이 포함된 버전 관리형 모델 레지스트리 (model registry).

• ml.eval-harness – 프롬프트와 모델을 위한 골든 세트 (golden-set) 평가 하네스 (evaluation harness). 기업은 평가 게이트 (evaluation gates) 없이 AI 기능을 출시하지 않기 때문입니다.

• 9개의 모든 스택에 걸친 프로덕션 AI 파이프라인 및 ML 서빙 (serving) 템플릿.

이것이 왜 중요할까요?

기업은 단순히 API 호출 하나만으로는 AI 기능을 출시할 수 없기 때문입니다. 그들에게는 버전 관리 (versioning)가 필요합니다. 평가 게이트 (eval gates)가 필요합니다. 여러 프로바이더를 처리하는 게이트웨이가 필요합니다. 감사 추적 (audit trail)이 필요합니다. 컴플라이언스 (compliance, 준수)는 있으면 좋은 것이 아니라 필수 전제 조건입니다.

Archiet은 Java Spring Boot, .NET, FastAPI, Django 등 기업이 요구하는 무엇이든 사용하여 이 모든 것을 생성합니다.

프롬프트 하나와 요행만을 바라는 방식으로 이 일을 해보려고 시도해 보십시오.

스택의 폭발 (The Stack Explosion)

아, 그리고 스택 이야기가 나와서 말인데.

동일한 정식 모델 (formal model)이 9개의 엔터프라이즈 백엔드로 컴파일됩니다: Flask, FastAPI, Django, NestJS, Laravel, Go-chi, Java Spring Boot, Rails, .NET.

여기에 모바일을 위한 React Native/Expo, 데스크톱을 위한 Tauri가 추가됩니다.

이것이 왜 강력한 기능(killer feature)인지 설명하겠습니다. Java Spring Boot나 .NET을 의무적으로 사용해야 하는 은행이나 보험사는 말 그대로 Lovable이나 v0를 사용할 수 없습니다. 그들은 React/Next.js 전용이기 때문입니다. 컴플라이언스 팀은 승인하지 않을 것이고, 내부 플랫폼 팀은 지원하지 않을 것이며, 아키텍트들은 그것을 창밖으로 던져버릴 것입니다.

Archiet을 사용하면 아키텍처가 곧 자산이 됩니다. 스택은 단지 렌더링 대상 (render target)일 뿐입니다.

기능을 한 번만 추가하면 패리티 매니페스트 (parity manifest)에 의해 강제되어 9개의 모든 스택으로 방출됩니다. 이것이 가능한 이유는 오직 정식 모델 스파인 (formal-model spine) 덕분입니다. 이것이 없다면 9개의 스택 간에 동일성을 유지하는 것은 유지보수의 악몽이 될 것입니다. 하지만 이것이 있다면, 그것은 컴파일 타임 보장 (compile-time guarantee)이 됩니다.

게이트키퍼: 실제로 부팅되는지 증명하기 (The Gatekeeper: Proving It Actually Boots)

이 부분은 저를 거의 무너뜨릴 뻔한 단계였습니다.

제너레이터(generator)를 구축한 후, 저는 그것이 실제로 작동한다는 것을 증명해야 했습니다. 데모로 보여주는 것이 아닙니다. 마케팅 슬라이드로 보여주는 것도 아닙니다. 실제적이고, 측정 가능하며, 재현 가능한 증거로 증명해야 했습니다.

그래서 우리는 합성 부팅 테스트(Synthetic Boot Test)를 구축했습니다.

작동 방식은 다음과 같습니다: 컴파일러(compiler)가 앱을 렌더링합니다. 그다음 패키지 매니저(npm, mvn, composer 등)를 실행합니다. 의존성(dependencies)을 설치합니다. 코드를 컴파일합니다. 실제 Postgres 데이터베이스를 마이그레이션(migrate)합니다. 서버를 부팅합니다. 회원가입(register), 로그인(login), CRUD와 같은 핵심 흐름(core flows)을 실행합니다. 적대적 보안 프로브(adversarial security probes)를 실행합니다.

이 모든 과정은 스택(stack)별로 E2B 샌드박스(sandbox) 내에서 자동화되어 진행됩니다.

저는 Java를 30개의 컴파일 에러(compile errors) 상태에서 깨끗한 통과 상태로 만들기 위해 한 세션 내내 씨름했습니다. 회원가입은 201을 반환합니다. 로그인이 작동합니다. CRUD가 통과됩니다. 적대적 프로브가 모두 녹색(green)으로 표시됩니다.

그 세션은 바로 어제 일어난 일입니다. 이것은 주장이 아니라, 측정된 사실입니다.

경쟁사들의 데모는 유튜브에서 마법처럼 보입니다. 하지만 zip 파일을 다운로드하면 컴파일조차 되지 않습니다. 그것이 바로 보편적인 "CRUD처럼 느껴지지만 부팅은 안 되는(feels like CRUD / won't boot)" 문제입니다. 우리는 희망 대신 툴체인(toolchain)을 게이트키퍼(gatekeeper)로 만들었습니다. 부팅되지 않는다면, 배포(ship)되지 않습니다.

실제로 이것을 구매하는 사람

기업 구매자(enterprise buyers)에 관한 핵심은 이렇습니다.

우리는 오후 시간을 아끼려는 개발자에게 판매하는 것이 아닙니다. 우리는 아키텍처 검토 위원회(architecture review board)의 승인을 받을 수 있는 무언가가 필요한 엔터프라이즈 아키텍트(enterprise architects)와 CTO들에게 판매하고 있습니다.

Archiet은 단순히 앱을 내보내는 것이 아닙니다. ArchiMate 모델을 내보냅니다. 아키텍처 결정 기록(ADRs, Architecture Decision Records)을 내보냅니다. TOGAF 문서를 내보냅니다. McKinsey/PwC 수준의 품질 기준을 충족하는 추적성 매트릭스(traceability matrix)를 내보냅니다.

구매자가 다릅니다. 예산이 다릅니다. 지불 의사가 10배 더 높습니다.

Fortune 500 기업의 CTO에게 실패한 내부 시스템의 비용은 단순한 버그 수정 비용이 아니기 때문입니다. 그것은 컴플라이언스 위반(compliance breach)입니다. 제품 출시 지연입니다. 6개월 치의 기술 부채(technical debt)입니다. 그 구매자는 정확성(correctness), 재현성(reproducibility), 거버넌스(governance), 그리고 스택 적합성(stack-fit)을 위해 비용을 지불할 것입니다.

그것이 바로 우리가 구축한 것입니다.

모든 논란을 잠재울 단 하나의 데모

저는 랜딩 페이지에서 Lovable보다 더 예쁘게 보이려고 노력하지 않을 것입니다. 그것은 잘못된 경쟁이며, 어차피 저는 질 것입니다.

대신, 승리할 수 있는 데모는 다음과 같습니다. 아키텍트들이 모인 방 앞에서 동일한 PRD (제품 요구 사항 문서)를 두 번 재생성합니다. 그들에게 동일한 ZIP 파일들을 보여줍니다. 그런 다음 Java Spring Boot 앱을 실시간으로 컴파일하고 부팅합니다. 1분 이내에 인증 (auth), CRUD, 그리고 보안 프로브 (security probe)를 통과합니다. 그리고 그것이 생성된 ArchiMate 모델과 ADR (아키텍처 결정 기록)을 불러옵니다.

그다음 Lovable에게 규제 대상인 은행에 실제로 부팅되는 Spring Boot 앱을 전달해 보라고 요청하십시오.

그것은 오직 우리만이 할 수 있는 주장입니다.

잠시 현실적으로 이야기해 봅시다

저는 여기서 모든 것이 완벽하다고 말하지는 않겠습니다.

저는 핵심 CRUD 및 인증 (auth) 스택이 부팅되고 게이트를 통과하는 것을 확인했습니다. 그것이 이번 세션의 작업이었습니다. Layer-A 학습 루프 (learning loops)는 활성화되어 데이터를 축적하고 있습니다. Layer-B ML (머신러닝) 기능 계약 (capability contracts)은 크로스 스택 프레임워크 (cross-stack framework) 내에 존재합니다. 저는 그것들을 읽었고, 그 목적을 확인했으며, 그것들이 실재한다는 것을 알고 있습니다.

하지만 저는 아직 각 ML 기능을 엔드 투 엔드 (end-to-end)로 부팅 테스트하지 않았습니다. 제가 Java의 인증 및 CRUD를 했던 방식만큼은 아닙니다. 따라서 만약 기술 패널이 RAG (검색 증강 생성) 파이프라인이 실시간으로 부팅되는 것을 보여달라고 요청한다면, 저는 먼저 SBT 게이트를 통해 그것을 증명할 것입니다. 동일한 규율입니다. 제가 검증하지 않은 것을 주장하지 않겠습니다.

몇몇 스택에는 여전히 제가 해결할 수 있는 사소하고 무해한 프로브 (probe) 결함들이 남아 있습니다. 구조적인 문제는 아닙니다. 하지만 존재합니다.