로컬 우선 AI의 올바른 구현: Gemma 4 E2B와 Thinking Mode로 DiagramFlowAI 만들기

Local-First AI Done Right: How Gemma 4 E2B and 'Thinking Mode' Powered DiagramFlowAI

Over the past few months, the tech world has shifted from "AI-capable" to "Agentic-driven". But as...

Carlos Barbero2026-05-13

DiagramFlowAI 소개 #

DiagramFlowAI는 자연어 설명을 프로덕션 수준의 아키텍처 다이어그램으로 변환하는 로컬 우선(local-first) 데스크탑 애플리케이션이다(macOS, Windows, Linux 지원). 일반 워크플로에는 표준 Mermaid 문법을 생성하고, 클라우드 아키텍처에는 아이콘 매핑 구조 명령을 출력한다.

이 애플리케이션은 현대 소프트웨어 엔지니어링의 특정한 긴장 관계를 풀기 위해 만들었다. 프라이버시 대 생산성(privacy versus productivity). 아키텍트와 엔지니어가 인증 흐름, 독점 데이터 파이프라인, 보안 클라우드 경계 같은 내부 시스템을 설계할 때, 그 데이터를 클라우드 기반 LLM 엔드포인트로 보내는 건 컴플라이언스 관점에서 허용되지 않는 경우가 많다.

flutter_gemma와 LiteRT 기반으로 구동되는 DiagramFlowAI는 100% 로컬에서 실행된다. 최초 모델 다운로드 이후에는 인터넷 연결이 필요 없고, API 키도 없으며, 텔레메트리도 없다.

소스코드: github.com/carlosrgomes/DiagramFlowAI

비주류 선택: 큰 모델 대신 작은 모델 #

대부분의 AI 쇼케이스는 사용 가능한 가장 큰 모델을 기본값으로 삼는다. 이 프로젝트는 정반대 방향을 택했다. DiagramFlowAI는 의도적으로 Gemma 4 E2B와 E4B, 즉 엣지(edge) 변형 모델을 중심으로 설계했으며, 31B Dense와 26B MoE 모델은 처음부터 배제했다. 가장 작은 변형이 이 데스크탑 앱의 핵심이 된 이유, 그리고 Gemma 4의 "Thinking Mode"가 예상치 못한 기능을 열어준 과정이 이 글의 핵심이다.

고처리량 백엔드를 구축하는 경우라면 31B Dense나 26B MoE가 당연한 선택이다. 하지만 이 프로젝트의 배포 제약 조건은 완전히 다른 방향을 가리켰다.

대중적 하드웨어 요구사항: 31B 덴스 모델을 4비트 양자화(모델 가중치를 압축해 메모리 사용량을 줄이는 기법)로 실행하려면 약 16~~20GB RAM이 필요하다. E4B 모델은 4~~6GB 안에서 편안하게 동작하며 통합 GPU에서도 부드럽게 실행된다. 누구나 쓸 수 있는 앱과 고사양 워크스테이션에서만 쓸 수 있는 장난감의 차이다.
마찰 없는 온보딩(Frictionless Onboarding): 사용자가 API 키를 붙여넣어야 하는 순간, 온보딩 전환율은 급락한다. E2B와 E4B는 오픈 웨이트(open weights)이므로 사용자는 "다운로드"를 클릭하고 바로 다이어그램 작업을 시작할 수 있다. 인증 장벽도, 결제 설정도 없다.
빠른 콜드 스타트: 데스크탑 앱에서는 첫 번째 상호작용이 즉각적으로 느껴져야 한다. E2B 모델은 최신 M 시리즈 Mac과 현대적인 PC에서 몇 초 안에 로드되고 응답한다.

사용자에게 유연성을 제공하기 위해 단일 옵션을 하드코딩하는 대신, E2B(더 빠름)와 E4B(복잡한 문법에서 더 정확함) 사이를 토글할 수 있도록 설계했다.

과소평가된 슈퍼파워: Thinking Mode #

Gemma 4로 개발한다면 반드시 챙겨야 할 것이 있다. 추론 트레이스(reasoning trace)의 힘이다. flutter_gemma SDK는 Gemma 4의 내부 추론 과정을 별도의 ThinkingResponse 청크 스트림으로 노출한다.

다이어그램 생성에서 이건 판도를 바꾼다. Mermaid 문법은 악명 높을 정도로 깨지기 쉽다. 잘못 놓인 콜론 하나, 따옴표 없는 문자열 하나, 빠진 end 태그 하나가 전체 렌더를 망가뜨린다. Thinking Mode 없이는 4B 파라미터 모델이 구문적으로 깨진 DSL을 한 번에 자신 있게 출력하는 경우가 많다.

Thinking Mode를 켜면 모델은 최종 출력 전에 몇 백 토큰을 구조 계획에 쓴다("좋아, 이건 시퀀스 다이어그램이야. actor → participant → arrow → response 순서로..."). 결과적으로 최종 출력의 신뢰도가 극적으로 높아진다.

UI에서는 이 트레이스를 접힌 아코디언("Thinking · 2.4s" 형태)으로 노출했다. 이 작은 UX 선택이 원시 로그로 사용자를 압도하지 않으면서 생성 대기 시간을 생산적으로 느끼게 만들고 신뢰감을 형성한다.

4B 모델을 위한 실용적 패턴 #

몇 주간 시행착오를 거쳐 얻은 아키텍처 패턴들이다.

1. 시스템 프롬프트를 성격이 아닌 문법으로 다뤄라. 소형 모델은 패턴 매칭에 특히 뛰어나다. 500줄에 달하는 시스템 프롬프트의 목적은 AI를 "친절하게" 만드는 것이 아니라 출력 계약(output contract)을 정의하는 것이다. 명시적 구분자(<DIAGRAM>...</DIAGRAM>)를 쓰고, 가장 흔한 파서 실패 사례를 보여주는 "문법 카드(syntax cards)"를 제공한다. 모델에게 하면 안 되는 것을 가르치는 것만으로 버그 클래스 하나를 통째로 막을 수 있다.

2. 복잡한 Regex보다 계약을 믿어라. 깨지기 쉬운 마크다운 펜스를 복잡한 Regex로 처리하는 대신, 시스템 프롬프트에 정의된 XML 스타일 구분자에 의존한다. 모델이 설명 단락을 추가로 작성하더라도 실제 코드는 안전하게 감싸져 있어 쉽게 꺼낼 수 있다.

3. 복구 루프(recovery loop)를 설계하라. Thinking Mode를 쓰더라도 복잡한 다이어그램은 간헐적으로 파싱에 실패할 수 있다. 프롬프트 엔지니어링으로 100% 성공률을 목표로 잡는 대신(4B에서는 사실상 불가능), 소형 ReAct 스타일 재시도 루프를 구축했다. Mermaid 파서가 오류를 던지면 앱은 정확한 오류 메시지를 다음 턴에 다시 넣는다. 모델은 두 번째 시도에서 거의 항상 문법을 고친다.

Gemma 4 E2B와 E4B는 대규모 클라우드 호스팅 LLM 없이도 진짜 유용한 구조화된 AI 애플리케이션을 출시할 수 있다는 걸 증명한다. 배포 제약 조건을 꼼꼼히 파악하고, 시스템 프롬프트를 철저히 활용하고, Thinking Mode를 켜고, 스마트 복구 루프를 설계하면 이 엣지 모델들은 타협이 아니라 기능 그 자체가 된다.

이 글은 위 출처의 내용을 바탕으로 작성된 초안입니다. 원문의 의견과 정보를 그대로 전달하며, 별도의 견해를 포함하지 않습니다.