2만 명의 개발자가 사용하는 Loki Mode: 4일 동안 15번의 릴리스를 진행하며 배운 Verified(검증됨) 대 Live(라이브) 자율
요약
자율 코딩 에이전트 Loki Mode가 사용자 2만 명을 돌파하며 성장 중입니다. 단순히 실행되는 것처럼 보이는 것이 아니라, 실제 코드 변경 사항과 테스트를 검증하여 신뢰할 수 있는 결과물을 만드는 'Verified' 루프 구현 과정을 다룹니다.
핵심 포인트
- 단순 프리뷰가 아닌 실제 git diff와 테스트를 통한 검증 중심의 에이전트 설계
- 4일간 15번의 마이너 릴리스를 통한 빠른 반복 개발 경험 공유
- 실행 성공 여부를 거짓으로 보고하는 기존 에이전트의 한계 극복
- 오픈 소스 기반의 자율 코딩 워크플로우 및 아키텍처 소개
커피를 절반쯤 마셨을 때, 우리의 셀프 업데이트 텔레메트리(telemetry)가 고유 개발자 수 20,000명을 돌파했다는 신호가 왔습니다. 6개월 전, Loki Mode는 개인적인 갈증을 해소하기 위한 사이드 프로젝트였습니다. 저는 제 자신의 레포지토리(repo)에 디프(diff)를 반영할 수 있을 만큼 실제로 신뢰할 수 있는 자율 코딩 에이전트(autonomous coding agent)를 원했습니다. Replit 스타일의 클라우드 샌드박스(sandbox)도, Lovable 스타일의 프리뷰(preview)도, Cursor 스타일의 에디터 창(editor pane)도 아니었습니다. 밤새 실행해 두고 아침에 돌아와 git diff 결과를 믿을 수 있는 루프(loop)를 원했습니다.
이번 주에 우리는 4일 동안 15번의 마이너 릴리스(minor releases)를 배포했으며, 마침내 목표한 결과물에 도달했다고 생각합니다.
이 포스트는 솔직한 엔지니어링 기술 문서(engineering writeup)입니다. 아키텍처(Architecture), 체크 표시가 포함된 실제 비교 표, (연습용 퀵스타트가 아닌) 실제 스펙(spec)을 사용한 실습 가이드, 스크린샷이 포함된 이슈-머지된-PR(issue-to-merged-PR) 워크플로우, 그리고 우리가 진행 과정에서 실수했던 부분들을 다룹니다. 빠르게 훑어보신다면, 섹션 4에 있는 비교 표가 핵심입니다.
1. 우리가 해결하고자 했던 문제
작년 말 Replit Agent와 Lovable이 등장하기 시작했을 때, 제가 아는 모든 창업자들은 열광했습니다. 스펙(Spec)에서 배포된 앱까지 단 90초. 공개 프리뷰 URL. 끝.
하지만 제가 직접 빌드할 때마다 조용히 한 가지 현상이 반복되었습니다. 프리뷰(preview)는 로드됩니다. Cmd+R로 새로고침하면 "Welcome to your todo app."이 나타납니다. 저는 "add todo"를 클릭하고, 무언가를 입력한 뒤 제출 버튼을 누릅니다. 그러면 요청이 에러를 조용히 삼켜버리는 함수로 전송되는 것을 보게 됩니다. 에이전트(agent)는 실행을 "완료(complete)"로 표시했습니다. 프리뷰는 무언가 실행 중임을 보여주었습니다. 프리뷰가 거짓말을 하고 있었던 것입니다.
제가 원했던 것은 간단했습니다. 빈 디프(diff)나 실패하는 테스트에 대해 작업 완료를 호출하기를 거부하는 자율 루프(autonomous loop)입니다. 진정한 게이트(gate) 말입니다. 주니어 엔지니어의 첫 단독 PR(Pull Request) 주위에 두고 싶어 할 바로 그 게이트 말이죠. "실행되는 것처럼 보이네"가 아니라
그것이 바로 Loki Mode입니다. 먼저 로컬에서 구축했고, 오픈 소스로 공개했으며, 사용자 층이 이를 찾아냈습니다.
2. 수치, 솔직한 버전
PostHog 데이터 기준 (익명 처리, LOKI_TELEMETRY_DISABLED=true 또는 DO_NOT_TRACK=1을 통해 옵트아웃 가능, 프롬프트나 PRD(제품 요구 사항 문서) 내용 또는 소스 코드는 절대 캡처하지 않음):
| 지표 | 값 |
|---|---|
| 누적 개발자 설치 수 | 20,000명 이상 |
| ... |
솔직히 말씀드리면, 이 프로젝트는 한 사람(저)이 유지 관리하고 있습니다. 현재 열려 있는 GitHub 이슈는 2개입니다. 버스 지수(Bus factor)가 1입니다. 그 대가로 빠른 릴리스 주기, 빠른 PR(Pull Request) 리뷰, 그리고 Discord에서 몇 시간 내에 답장하는 유지 관리자를 얻었습니다.
데이터가 말해주는 것: Loki를 가장 강력하게 끌어당긴 개발자들은 호스팅된 spec-to-app(명세 기반 앱 생성) 도구가 자신의 저장소(repo)에 아예 손을 대는 것을 허용하지 않는 사람들이었습니다. 셀프 호스팅(Self-hosted), 본인의 키 사용, 프록시 없음. 이 시장은 호스팅된 도구의 TAM(Total Addressable Market, 총 유효 시장)보다 크며, BSL-1.1 소스 가용(source-available) 라이선스는 정확히 이 시장을 지원하기 위해 구축되었습니다.
3. 아키텍처가 실제로 작동하는 방식
제품 비교에만 관심이 있다면 이 부분을 건너뛰셔도 좋습니다. 하지만 자신의 저장소를 이 도구에 맡기기 전에 내부 구조가 어떻게 되어 있는지 알고 싶다면 읽어보십시오.
입력값 (the "spec" surface)
명세(spec)는 다음 중 어느 것이든 될 수 있습니다:
- PRD 마크다운 파일:
./prd.md - GitHub, GitLab, Jira 또는 Azure DevOps 이슈 (URL 또는 약어). GitHub은
123,#123,owner/repo#123및 전체 이슈 URL을 허용합니다. GitLab은gitlab.com/owner/repo/-/issues/N을 지원합니다. Jira는PROJ-123또는 Atlassian URL을 지원합니다. Azure DevOps는 작업 항목(work-item) URL을 지원합니다. - OpenAPI 문서 (YAML 또는 JSON)
- OpenSpec 변경 디렉토리:
./openspec/changes/feature-x/ - 일반 텍스트 또는 YAML 한 줄 명령:
loki start "build a markdown editor with file sync"
CLI는 확장자, URL 패턴 또는 위 사항 중 어느 것도 해당하지 않는 경우를 바탕으로 사용자가 제공한 명세의 종류를 자동으로 감지합니다. 통합 진입점은 loki start이며, loki run <issue-ref>는 작동은 유지되지만 권장되지 않는(deprecated) 별칭입니다.
실행 루프: RARV-C
모든 실행은 5단계의 클로저 루프(closure loop)를 반복하며, 각 단계마다 모델 계층(model tier)이 교체됩니다:
| 단계 | 작업 | 기본 모델 계층 (Default model tier) |
|---|---|---|
| Reason (추론) | 아키텍처 결정, 작업 분해 (task decomposition), 계획 수립 | Planning (기본적으로 Claude Opus 사용) |
| ... |
C는 루프가 세션 전반에 걸쳐 복합적으로 작용하게 만드는 요소입니다. 매 반복(iteration)이 끝난 후, 에이전트는 자신이 무엇을 시도했는지, 무엇이 작동했는지, 무엇이 실패했는지, 그리고 어떤 파일이 수정되었는지를 .loki/memory/episodic/에 기록합니다. 동일한 프로젝트에서의 향후 실행(또는 교차 프로젝트 메모리가 켜져 있을 때의 형제 프로젝트) 시, 에이전트가 축적한 컨텍스트는 다음 프롬프트에서 "피해야 할 과거의 실패 사례 (PAST FAILURES TO AVOID)" 블록으로 전달됩니다.
신뢰 계층 (The trust layer)
Loki는 다음과 같은 상황에서는 실행이 완료되었다고 간주하기를 거부합니다:
- 실행 시작 시점의 커밋과 비교했을 때 차이점(diff)이 없는 경우. 항상 차단됩니다.
- 테스트 러너(test runner)가 감지되어 실행되었으나 테스트 결과가 실패(red test run)인 경우. 항상 차단됩니다.
- 실패한 홀드아웃 스펙 평가 (failing held-out spec eval) (섹션 6에서 자세히 설명). 항상 차단됩니다.
- 3인 검토자 블라인드 리뷰(3-reviewer blind review)에서 의회(council)의 거부(REJECT) 판정이 내려진 경우. 항상 차단됩니다.
모든 게이트(gate)는 .loki/verify/evidence.json에 기계가 읽을 수 있는 증거를 기록하고, .loki/verify/report.md에 사람이 읽을 수 있는 보고서를 작성합니다. 완료된 모든 실행은 팀원, 감사인 또는 PR 리뷰어에게 전달할 수 있는 휴대 가능한 .loki/proofs/<run_id>/proof.json + index.html 파일을 생성합니다.
프로바이더 라우팅 (Provider routing)
Loki는 다음과 같은 하위 에이전트 CLI 중 하나로 작업을 전달(dispatch)합니다:
| 프로바이더 (Provider) | 계층 (Tier) | 비고 |
|---|---|---|
| Claude Code | Tier 1, E2E-검증된 기본 모델 | 기본값. 가장 깊은 SDK 통합 제공. |
| ... |
또한, ANTHROPIC_BASE_URL을 통해 Anthropic API를 지원하는 모든 LLM을 사용할 수 있습니다:
# Claude 프로바이더를 로컬 Ollama (qwen2.5-coder:32b)를 통해 라우팅
export ANTHROPIC_BASE_URL=http://localhost:11434/v1
export ANTHROPIC_API_KEY=ollama
...
LOKI_MODEL_OVERRIDE는 ANTHROPIC_BASE_URL이 함께 설정된 경우에만 효과가 있으므로, Anthropic 네이티브 실행을 실수로 재라우팅하는 일은 발생하지 않습니다.
전체 멀티 프로바이더 설정: autonomi.dev/docs/multi-provider-setup.
4. 체크 표시가 포함된 비교표
이 부분은 README(리드미)에 솔직하게 적기가 어렵기 때문에 기술하지 않는 내용입니다. 각 도구가 무엇을 잘하는지, 그리고 어떤 상황에서 각 도구가 적합한 선택인지 정리했습니다.
| 기능 (Capability) | Replit Agent | Lovable | Cursor | Loki Mode |
|---|---|---|---|---|
| 즉각적인 클라우드 샌드박스 + URL | ✅ | ✅ | ❌ | ❌ |
| ... |
Replit을 선택해야 하는 경우: 목표가 학습, 데모, 교육, 또는 URL이 포함된 빠른 프로토타이핑(prototype)인 경우입니다. 그들은 정직하게 그 영역을 구축했습니다.
Lovable을 선택해야 하는 경우: 사양(spec)이 주로 시각적이며, 결과물이 랜딩 페이지나 디자인 중심의 프론트엔드(frontend)인 경우입니다. 해당 작업에 대한 그들의 결과물 수준(taste)은 진정으로 앞서 있습니다.
Cursor를 선택해야 하는 경우: 이미 작업 중인 에디터(editor) 내부에서 AI의 도움을 받고 싶은 경우입니다. Composer와 Tab 자동 완성(autocomplete) 기능은 기존의 근육 기억(muscle memory)에 잘 맞춰져 있습니다.
Loki Mode를 선택해야 하는 경우: 기존의 프라이빗 코드베이스(private codebase)에 배포해야 하거나, 머지(merge) 전의 차이점(diff)에 대해 결정론적인 CI 게이트(CI gate)가 필요한 경우, 제공자 키(provider keys)가 기기를 떠나면 안 되는 경우, 또는 검토 중인 코드를 물리적으로 수정할 수 없는 위원회(council)를 원하는 경우입니다.
이 도구들은 공존할 수 있습니다. 사양을 작성할 때는 Cursor를 사용하세요. 팀을 교육할 때는 Replit을 사용하세요. Loki가 구축하는 무엇인가를 위한 마케팅 사이트에는 Lovable을 사용하세요. Loki Mode를 선택해야 하는 핵심 근거는 구체적으로 "내 저장소(repo)로 머지하기 전의 검증된 차이점(verified diff)"입니다.
5. 워크플로우 1: 실제 PRD에서 실행 가능한 풀스택 앱까지
가장 중요한 최단 경로입니다. 마크다운(markdown) 사양을 넣으면, 실행 가능한 앱이 포함된 검증된 Git 저장소(Git repo)를 얻게 됩니다.
# 설치 (Bun 권장; v8은 Bun 전용이 될 예정입니다)
bun install -g loki-mode
...
실제 사양을 작성하세요. 에이전트(agent)는 이를 마크다운으로 읽으므로, 수락 기준(acceptance criteria)을 명확하게 작성해야 합니다. 다음은 제가 v7.26.0의 compose-first 지원을 테스트하기 위해 사용한 예시입니다:
# TaskFlow
사용자 인증(user auth), 전체 텍스트 검색(full-text search), 그리고 태그(tags) 기능이 있는 작업 추적기.
...
이를 ./prd.md로 저장하고 다음을 실행하세요:
loki start ./prd.md
보게 될 내용은 다음과 같습니다:
- Plan 자동 표시. 에이전트가 어떤 작업을 수행하기 전에, Loki는 복잡도 티어(complexity tier), 비용 추정치(cost estimate), 반복 횟수 제한(iteration cap), 시간 추정치를 출력합니다. 이 추정치는 실제입니다. 실제로 모델 가격표를 사용합니다. 거절한다고 해서 비용이 들지는 않습니다.
- 대시보드 자동 열림.
http://localhost:57374에서 새 브라우저 탭이 열립니다. (CI 환경,--detach/--background옵션 사용 시, TTY가 없는 SSH를 통해, 파이프된 stdin을 사용할 때, 또는LOKI_NO_AUTO_OPEN=1설정 시에는 생략됩니다.) - 에이전트가 반복 작업을 시작합니다. 추론(Reason), 행동(Act), 성찰(Reflect), 검증(Verify), 복합화(Compound).
대시보드에서 왼쪽 사이드바는 프로젝트를 보여줍니다. 메인 영역에는 개요(Overview), 작업(Tasks), RARV 타임라인, 품질(Quality), 비용(Cost), 라이브 앱(Live App) 탭이 있습니다.
'라이브 앱(Live App)' 탭은 저희가 2만 명을 넘어서게 만든 워크플로우 변화입니다. v7.24 이전에는 프로젝트로 cd하고, 다른 터미널에서 개발 서버를 실행한 다음, 그 서버가 올바른 포트와 통신하기만을 기도해야 했습니다. 이제 에이전트는 여전히 파일을 작성하고 있고 앱은 이미 iframe 내에서 실행되고 있습니다.
배후에서는 Council(의회)이 각 반복(iteration)을 검토합니다. Council 탭은 각 검토자가 제기한 근거(단순히 APPROVED/REJECTED 배지만 표시하는 것이 아님)와 함께 3인의 검토자 블라인드 판결(3-reviewer blind verdicts)을 보여줍니다:
Cost(비용) 탭은 반복당 지출을 추적합니다. v7.11.0에서는 80% 도달 시 사전 한도 경고(pre-cap warning) 기능이 추가되었습니다(기존의 100% 도달 시 강제 중단 기능 외에 추가됨). 이 경고는 WebSocket을 통해 방송되므로, 터미널에서 자리를 비웠더라도 모든 대시보드 페이지에 지속적인 황색 배너(amber banner)가 나타납니다:
실행이 완료되면, 프로젝트 디렉터리에 작동하는 앱이 포함됩니다:
docker compose up # 스택(stack) 실행
curl http://localhost:3000/health # 상태 정상(healthy)
npm test # 47/47 통과
그리고 휴대 가능한 증거(portable proof)도 생성됩니다:
loki proof list # 이 프로젝트의 모든 증거(proofs)
loki proof show <run-id> # 터미널에서 HTML 렌더링
loki proof open <run-id> # 브라우저에서 열기
...
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기