Kimi K3를 활용하여 회사 OS 구축하기 (빌더 가이드)

이것은 Kimi K3가 무엇인지, 그리고 AI 에이전트만으로 전체 비즈니스를 운영하는 방법에 대한 완전한 A-Z 분석입니다.

이 내용은 Kimi와 함께 작업하는 방식에 대한 모든 것을 바꿔놓을 것입니다.

TLDR;

4480단어 분량의 글을 읽고 싶지 않다면, 여기에 에이전트에 제공할 수 있는 GitHub 레포지토리가 있습니다.

https://github.com/codejunkie99/meridian-company-os 잊어버리기 전에 이 빌드들을 북마크하세요.

서문

모든 회사 OS에 필요한 요소들, 처음부터 도출하고 각 요소를 구축하는 프롬프트. 원리를 배우고, 프롬프트를 가져가서, 여러분의 것을 구축하세요.

저는 하나를 구축했습니다 (meridian-company-os, MIT 라이선스). 이 가이드의 참조이지 핵심은 아닙니다. 핵심은 그 밑에 있는 9가지 요소들입니다. 왜냐하면 그것들이 여러분이 앞으로 구축할 모든 회사 OS의 기반이기 때문입니다.

잊어버리기 전에 이 9가지 빌드를 북마크하세요.

커맨드 콕핏: BUILD 5의 운영자 화면이자, 9가지 요소들이 합쳐진 결과물입니다.

소개

여러분은 채팅 창과 기도만으로 에이전트를 조율하고 있습니다. 돈을 쓰고, 코드를 배포하고, 다른 에이전트를 고용할 수 있는 에이전트는 하나의 회사입니다. 그리고 여러분은 검색창 수준의 도구로 그 회사를 운영하고 있습니다. 이 가이드가 그 문제를 해결합니다.

2026년 7월 현재 상황은 이렇습니다. 워커 티어의 코딩 에이전트는 한 문단으로 설명할 수 있는 모든 파일을 1분 이내에, 단돈 몇 센트로 생성합니다.

하지만 동시에 여러분의 예산을 기꺼이 소진시키고, 자체 승인을 처리하며, 새로고침하면 모든 것을 잊어버립니다. 아무도 경계를 만들지 않았기 때문입니다. 모델은 저렴해졌지만, 그 주변의 운영 구조는 구축되지 않았습니다.

회사 OS는 더 좋은 채팅 UI가 아닙니다. 그것은 언제나 다음 6가지 질문에 대한 답입니다:

• 누가 무엇을 소유하는가
• 어떤 목표가 중요한가
• 무엇이 막혀 있는가
• 돈이 얼마나 빠르게 소진되는가
• 무엇이 여러분의 승인을 기다리고 있는가
• 여러분이 없는 동안 무슨 일이 일어났는가

이 6가지 모두에 답하면 회사 OS를 가진 것입니다. 그보다 적게 답하면 데모에 불과합니다.

이것은 한 사람의 철학도 아니고, 제 레포지토리 사용법 안내도 아닙니다. 이것은 필요한 요소들입니다. 각 요소에는 코딩 에이전트에 전달할 일반화된 프롬프트, 그것이 저를 위해 생성한 참조 구현, 그리고 해당 요소가 존재한다는 증명인 체크가 포함되어 있습니다.

제 스택은 React 19 + TypeScript + Vite 였습니다. 여러분의 스택은 무엇이든 될 수 있습니다. 요소 자체는 변하지 않습니다.

전체 시스템이 실제로 어떻게 구축되었는지, 그래서 여러분이 결과물뿐만 아니라 방법 자체를 복사할 수 있도록:

• 런타임: 모든 파일은 Kimi K3를 통해 Kimi Code CLI (~/.kimi-code/bin/kimi, kimi login 한 번)로 생성되었습니다.
• 루프, 9회: 프롬프트를 작성하고, kimi -p에 파이프하고, 체크를 실행합니다. 잘못된 파일? 프롬프트를 수정하고 재생성하며, 절대 수동으로 파일을 편집하지 않습니다.
• 티어링: K3 워커 티어가 9개 중 8개 빌드를 처리했습니다. 하나(리듀서)는 프론티어 모델로 에스컬레이션되었습니다.
• 전체 실행 기간 동안 설치된 스킬: 계획 및 검토 규율을 위한 Superpowers (obra/superpowers); React 19 및 Vite 6의 버전 정확한 문서를 위한 Context7 (upstash/context7) — 덕분에 K3가 더 이상 오래된 API를 환각하지 않았습니다.

이것이 전체 툴체인입니다. 아래 모든 빌드 내에서 작동하는 모습을 보실 수 있습니다.

최종적으로 요소별로 얻게 될 것은:

• 어휘: 모든 회사 OS가 동의해야 하는 타입화된 명사들 (BUILD 0)
• 세계: 운영 중인 시드 회사, 콘솔이 절대 비어 있지 않도록 (BUILD 1)
• 진실의 단일 출처: 하나의 스토어, 하나의 리듀서, 어떤 뷰도 상태를 소유하지 않음 (BUILD 2)
• 하트비트: 회사가 여러분의 시계가 아닌 자체 시계로 움직임 (BUILD 3)
• 메모리: 새로고침 후에도 유지되는 상태 (BUILD 4)
• 운영자 화면: 무슨 일이 일어났는지, 내가 필요한지, 무엇을 해야 하는지에 답하는 하나의 화면 (BUILD 5)
• 게이트: 돈과 권한이 여러분의 승인을 위해 대기 (BUILD 6)
• 커맨드 라인: 모든 모델이 호출되기 전에 입력된 명령이 실제 행동이 됨 (BUILD 7)
• 실제 런타임: 장벽 뒤에 연결된 실제 에이전트 (BUILD 8)

이 가이드의 대상: 터미널, 코딩 에이전트를 가지고 있고, 한 번에 둘 이상의 에이전트를 실행하려는 사람. 제 파일을 복사하는 것이 아니라, 원리와 프롬프트를 가져가서 여러분의 에이전트가 여러분의 파일을 작성하게 하는 것입니다.

읽는 방법: 순서대로, 체크를 수행하면서. 각 요소는 이전 요소를 가정합니다. 체크는 해당 요소가 존재한다는 증명입니다. 체크를 건너뛰면 루머 위에 쌓는 것입니다.

모든 것의 기초가 되는 원칙. 세 가지이며, 다음 9개 빌드의 모든 설계 결정은 이 중 하나의实例입니다:

1. 회사는 상태입니다. 분위기나 채팅 기록이 아닙니다. 타입화된 사실의 하나의 트리이며, 모든 화면은 그 트리로 향하는 창일 뿐, 그 자체로 출처가 아닙니다.
2. 권력은 게이트를 통해 흐릅니다. 지출, 고용, 배포, 해고하는 모든 것은 명시적인 승인을 위해 대기합니다. 게이트가 없으면 회사가 아니라, UI가 달린 누수일 뿐입니다.
3. 기록되지 않은 것은 일어나지 않은 것입니다. 모든 하트비트, 결정, 비용은 추가 전용 로그에 기록됩니다. 로그는 회사의 기억입니다.

이제부터는 에세이가 없습니다.

사전 준비 사항

1node --version              # v20+; 모든 최신 런타임이 작동하며, 참조 구현이 사용한 버전입니다
2npm --version               # node와 함께 제공됩니다
3
4# 모든 파일을 생성하는 코딩 에이전트:
5ls ~/.kimi-code/bin/kimi    # kimi code cli 설치됨
6kimi login                  # 한 번; oauth 자격 증명을 로컬에 저장합니다
7
8# 첫 번째 프롬프트 전에 kimi code에 설치된 스킬:
9#   superpowers  (github.com/obra/superpowers)   계획 + 검토 규율
10#   context7     (github.com/upstash/context7)   최신 버전 정확한 문서

런타임을 한 번 고정하세요: Kimi K3는 참조 파일을 생성한 워커 티어입니다. 다른 모델을 실행하면 다른 파일이 생성되며, 그것은 괜찮습니다. 여러분이 여러분의 것을 구축하는 것이지 제 것을 구축하는 것이 아니기 때문입니다. 일정하게 유지해야 할 것은 프롬프트와 체크입니다.

Kimi K3를 선택한 이유

Kimi K3 한눈에 보기: 출시 사양과 공개 벤치마크 순위, 콘솔 스타일로 표시되었습니다.

런타임 선택, 빠르게. 과대광고가 아닌, 트레이드오프에 대한 설명입니다.

Kimi K3란 무엇인가

• Moonshot AI의 오픈 가중치 모델, 2026년 7월 16일 출시.
• 2.8T 스파스 MoE (토큰당 896개 전문가 중 16개 활성화), 1M 컨텍스트, 네이티브 비전.
• 최초의 오픈 3T급 모델, 현재까지 가장 큰 오픈 가중치 릴리스.
• 전체 가중치는 7월 27일에 공개됩니다. 그때까지는 호스팅 전용입니다.

어디에서 약한가 (솔직하게)

• Moonshot 자체 출시 테이블에서 Fable 5가 35개 중 22개 승리; K3는 12개 승리.
• Intelligence Index에서 189개 중 4위 (~57점, Fable 5의 60점, GPT-5.6 Sol의 59점 대비).
• FrontierMath Tier 4에서 40% 미만, 폐쇄형 프론티어는 거의 90%에 근접.
• 환각률 약 51%, 따라서 검증기를 루프 안에 유지해야 함.

어디에서 강한가 (이 정확한 워크로드)

• 블라인드 Frontend Code Arena 1위 (1,679점, Fable 5보다 앞섬).
• Terminal-Bench 2.1에서 88.3%; SWE Marathon 및 장기 지평 에이전틱 코딩에서 선도.
• "다단계 도구 호출 세션을 이탈하지 않고 견디는" 능력, 에이전트 런타임의 성패를 가르는 요소.

선택한 이유

• 오픈 가중치: 공개되면 자체 호스팅으로 런타임 소유 가능.
• 저렴함: $0.30/M 캐시 히트 입력, $15/M 출력, Fable 5 대비 약 70% 저렴.
• 하루 종일 에이전트를 실행하는데, 런타임, 데이터, 비용 곡선을 벤더로부터 임대할 수 없음.
• 에이전틱 코딩에 충분한 프론티어 수준, 오픈, 70% 저렴함은 직접 실행할 수 없는 임대형 벤치마크 포인트보다 낫습니다.

지도

9가지 요소와 참조 구현에서 생성된 파일들. 여러분의 파일 이름은 다를 것입니다. 하지만 요소 자체는 다르지 않습니다.

1any-company-os/
2  scaffold                  BUILD (이 섹션): 런타임 + 엄격한 타입, 최소 의존성
3  domain model              BUILD 0: 명사들          -> src/lib/types.ts
4  seeded world              BUILD 1: 절대 빈 부팅 없음   -> src/lib/seed.ts, skills.ts
5  source of truth           BUILD 2: 하나의 스토어          -> src/lib/store.tsx
6  heartbeat                 BUILD 3: 2.6초 틱      -> src/lib/sim.ts
7  memory                    BUILD 4: 새로고침 유지     -> persistence in store.tsx
8  operator surface          BUILD 5: 콕핏        -> src/App.tsx, views/Command.tsx
9  the gate                  BUILD 6: 승인 받은 편지함    -> views/Approvals.tsx
10  command line              BUILD 7: 명령하기         -> views/KimiSpace.tsx
11  real runtime              BUILD 8: 보호된 에이전트       -> server/kimiBridge.ts, vite.config.ts

이 가이드의 모든 10개 프롬프트는 prompts/ 디렉토리 내에 실행 가능한 파일로도 제공되며, 요소별로 하나씩 있습니다. 따라서 kimi -p "$(cat prompts/00-scaffold.md)" 명령이 바로 작동합니다.

먼저, 스캐폴드. 원칙: 의존성이 적을수록 거짓도 적습니다. 회사 OS의 유일한 임무는 신뢰할 수 있는 상태입니다. 모든 의존성은 이제 신뢰해야 하는 다른 사람의 상태입니다.

프롬프트, kimi -p를 통해:

1회사 OS를 구축 중입니다. 인간과 AI 에이전트로 구성된 회사 전체를 운영할 하나의 콘솔입니다. 린(lean)한 설정을 선택해 주세요: 타입화된 언어, 빠른 개발 루프, 가능한 한 런타임 의존성을 0에 가깝게 유지하는 것. 스캐폴드를 설정하고 무엇을 넣었는지, 왜 그랬는지 알려주세요. 한 줄로 정당화할 수 없는 것은 모두 제거하세요.

K3가 참조를 위해 생성한 것: React 19 + TypeScript 5.8 strict + Vite 6, 그리고 React 외에 정확히 하나의 런타임 의존성 (lucide-react, 아이콘용). 스크립트: dev, build (tsc -b && vite build), preview.

여기서 이미 Context7이 중요했습니다. Context7 없이 K3는 React 18 패턴으로 스캐폴드했지만, Context7이 있으면 첫 번째 시도에 설정이 Vite 6 네이티브로 나왔습니다.

CHECK: 설치 및 타입 체크, 종료 코드 0. 런타임 의존성 개수를 세어보세요. 각각을 한 줄로 정당화할 수 없다면 이 빌드는 완료되지 않은 것입니다.

1npm install && npx tsc --noEmit; echo "exit: $?"

BUILD 0: 어휘

한 줄로 설명하는 이유: 회사는 상태이므로, 어떤 행동보다 먼저 회사가 운영되는 모든 명사는 정확히 하나의 타입 정의를 가져야 합니다.

첫 번째 원칙. 인간과 에이전트로 구성된 모든 회사에 불가결하게 존재하는 것이 무엇인지 묻는다면, 7가지 명사가 나옵니다:

• 일하고 비용이 드는 행위자
• 이유를 설명하는 목표
• 무엇을 할지, 상태와 소유자가 있는 작업
• 권한을 기다리는 결정 (승인)
• 지출의 단위 (원장)
• 발생했다는 사건 (로그 줄)
• 이 모든 것을 담는 컨테이너 (회사)

모든 회사 OS는 이 7가지 명사와 의견으로 구성됩니다. 명사를 먼저 타입화하면 의견이 정직해집니다.

일반화된 프롬프트. 명사와 각각에 대해 물어야 할 두 가지 질문을 명명하며, 제 스택에 대한 언급은 없습니다:

1좋아요, 로직 전에 명사부터 원합니다. 인간과 에이전트로 구성된 회사를 운영한다면, 반드시 존재해야 하는 것들은 무엇일까요? 행위자, 목표, 작업, 승인, 지출된 돈, 로그의 한 줄, 이 모든 것을 담는 회사. 이 모든 것을 타입으로 모델링하세요, 행동은 없이. 각 명사에 대해 두 가지 질문을 하세요: 운영자가 무엇을 봐야 하는지, 시스템이 무엇을 강제해야 하는지. 상태는 문자열이 아닌 폐쇄된 유니온입니다. 돈과 토큰은 '분위기'가 아닌 숫자입니다. 그리고 두 개의 명사가 사실상 같은 것이라면, 지적해 주세요. 엉망인 상태로 배포하지 않도록 해주세요.

참조 구현. K3가 src/lib/types.ts를 생성했습니다. 416줄, 로직은 전혀 없습니다. 전체 시스템을 담는 형태, 그리고 각각 내부에 보이는 강제 질문:

1export type AgentStatus = "working" | "idle" | "paused" | "blocked" | "offline";
2
3export interface Agent {
4  id: ID; companyId: ID; name: string; title: string; department: string;
5  kind: "ai" | "human"; runtime?: string; model?: string; managerId?: ID;
6  status: AgentStatus; heartbeat: string;
7  monthlyBudget: number; spent: number;        // 강제: 지출에는 상한선이 있음
8  successRate: number; tasksCompleted: number;
9  skills: string[]; color: string; lastHeartbeat?: number;
10}
11
12export type ApprovalType = "hire" | "spend" | "override" | "publish" | "terminate";
13export interface Approval {
14  id: ID; companyId: ID; type: ApprovalType; title: string; rationale: string;
15  requestedBy: ID; amount?: number;
16  status: "pending" | "approved" | "rejected";  // 강제: 세 가지 상태, 네 번째는 없음
17  checks: PolicyCheck[];                        // 기계가 자신의 주장을 증명함
18  decidedAt?: number; decidedBy?: string;
19}
20
21export interface ActivityEvent {
22  id: ID; companyId: ID; ts: number; actorId: ID;
23  kind: "heartbeat" | "task" | "delegation" | "spend"
24      | "approval" | "governance" | "goal" | "system";
25  message: string; amount?: number;             // 기록되지 않은 것은 일어나지 않은 것
26}

Kimi 패스가 어떻게 진행되었는지: kimi -p 한 번 호출, 전체 파일을 한 번에 생성했습니다.

Superpowers 스킬이 여기서 제 역할을 했습니다. 검토 규율 덕분에 K3가 "두 개의 명사가 겹칩니다"라는 메모를 추가했습니다: 위임과 작업 할당은 거의 동일한 명사였으며, 새로운 인터페이스 대신 Task에 delegatedBy 필드로 해결되었습니다. 이것이 프롬프트의 마지막 문장이 실제 작업을 수행한 부분입니다.

CHECK: 타입 체크 통과, any 없음. 그런 다음 명사 감사: 인터페이스를 grep하여 7가지 명사 각각이 정확히 하나의 위치에 있는지 확인하세요.

1npx tsc --noEmit && grep -c "^export interface" src/lib/types.ts

BUILD 1: 세계

한 줄로 설명하는 이유: 빈 회사를 운영하는 법을 배울 수는 없습니다. 따라서 OS는 이미 운영 중인 세계로 부팅되어야 합니다.

첫 번째 원칙. 운영자 화면은 인식을 통해 가르칩니다: 예산을 초과한 에이전트, 막힌 작업, 보류 중인 채용을 보고 컨트롤이 무엇을 하는지 배웁니다. 빈 상태는 아무것도 가르쳐주지 않으며, 게다가 렌더링 버그를 숨깁니다 (빈 열과 깨진 열은 똑같이 보입니다).

따라서 모든 회사 OS는 결정론적인 시드 세계가 필요합니다: 매번 부팅할 때마다 동일한 세계, 모든 상태가 표현되고, 모든 게이트가 이미 결정을 보유하고 있는 상태.

일반화된 프롬프트:

1방금 작성한 타입을 사용하여 이미 실행 중인 회사 전체를 가짜로 만들어 주세요. 그래서 앱이 부팅되는 즉시 화면에 내용이 표시되도록요. 누가 여기서 일하나요? 실제 직함을 부여하고, 누가 누구에게 보고하는지, 예산을 절반 정도 소진한 상태, 성공률 등. 지금 무엇이 작업 중이고, 무엇이 막혀 있나요? 어떤 결정이 제 받은 편지함에서 승인을 기다리고 있나요? 모델의 모든 상태가 적어도 한 번씩 나타나야 합니다. 마치 화요일 오후 2시에 운영 중인 회사에 들어간 것처럼 느껴져야 하며, 빈 템플릿처럼 느껴져서는 안 됩니다. random()은 사용하지 말고, 매번 부팅할 때마다 동일한 세계여야 합니다.

참조 구현. K3가 두 개의 파일을 생성했습니다.

seed.ts (~600줄의 픽스처):

• 두 개의 회사, 각각 6명 이상의 에이전트, 보고 라인과 부분 소진된 예산 포함
• 미션-회사-팀 목표 트리
• 6가지 상태 모두에 걸친 작업
• 정책 검사 결과가 포함된 보류 중인 승인

그리고 skills.ts, 설치 가능한 기능 팩의 레지스트리로, 실제 출처에 크레딧을 표시:

1export const SKILLS: Skill[] = [
2  s("superpowers", "Superpowers", "obra/superpowers",
3    "https://github.com/obra/superpowers", "developer",
4    "검증된 워크플로우 슈퍼파워: TDD, 디버깅, 계획 및 검토 규율."),
5  s("context7", "Context7", "upstash/context7",
6    "https://github.com/upstash/context7", "developer",
7    "최신 버전 정확한 라이브러리 문서를 에이전트의 컨텍스트 창으로 가져옵니다."),
8  // ...디자인, 마케팅, 소셜, 재무, 운영, 법무 팩
9];

주목할 만한 루프가 있습니다. 이 파일을 생성하는 동안 Kimi Code CLI 내에서 실행 중이던 두 개의 스킬은 파일이 정의하는 레지스트리의 첫 번째 두 항목입니다.

여러분이 구축 중인 OS는 에이전트에 스킬을 설치합니다. 이는 방금 여러분이 그것을 구축하는 에이전트에 스킬을 설치한 것과 동일한 방식입니다. 방법이 곧 제품입니다.

여기서 한 번의 재생성이 필요했습니다. K3의 첫 번째 패스는 모든 작업을 in_progress 상태로 두었고, 이는 "모든 상태가 적어도 한 번씩"이라는 조건을 위반했습니다. 수정 방법은 시드를 편집하는 것이 아니라, 해당 줄을 프롬프트에 추가한 다음 kimi -p를 다시 실행하는 것이었습니다. 프롬프트를 수정하고, 절대 파일을 수동으로 편집하지 마세요.

CHECK: 두 번 부팅하고, 세계를 비교하세요. 결정론적이어야 하므로 동일해야 합니다.

1node -e "const {seedState}=await import('./src/lib/seed.ts'); \
2  console.log(Object.keys(seedState().tasks).length)"   # 매번 실행할 때마다 동일한 개수

BUILD 2: 진실의 근원

한 줄로 설명하는 이유: 회사는 상태이므로, 상태는 오직 한 곳에서만 변경될 수 있으며, 그 외의 모든 것은 창문일 뿐입니다.

첫 번째 원칙. 모든 멀티 에이전트 대시보드의 실패 패턴은 동일합니다: 다섯 개의 컴포넌트가 각각 진실의 복사본을 들고 있고, 점점 어긋납니다. 치료법은 구조적이지, 규율적인 것이 아닙니다.

하나의 스토어. 하나의 리듀서, 상태와 액션을 받아 상태를 반환하는 순수 함수. 뷰는 읽기만 하고, 디스패치만 합니다. 뷰는 절대 변이(mutate)하지 않습니다.

이렇게 하면 이후의 모든 요소 (로그, 게이트, 하트비트)가 아키텍처 결정이 아닌 리듀서 케이스가 됩니다.

일반화된 프롬프트:

1모든 화면은 각자 작은 상태 더미를 들고 있는 것이 아니라, 하나의 진실의 근원을 바라보는 창문이어야 합니다. 그 근원을 구축해 주세요. 스토어가 상태가 변경될 수 있는 유일한 장소라면, 그 형태는 무엇이며, 버튼이 직접 들어와서 엉망으로 변이시키지 않고 어떻게 변경을 요청할 수 있나요? 하나의 순수 리듀서, 하나의 액션 유니온, 일반적인 읽기를 위한 셀렉터. 나중에 세계를 다시 작성하지 않고도 새 액션을 추가할 수 있도록 유지하세요. 구축하세요. 그런 다음 제가 가장 먼저 깨뜨릴 것 같은 한 가지 사례를 알려주세요.

참조 구현. src/lib/store.tsx, 약 1,400줄: StoreProvider, useStore()가 { state, dispatch }를 반환, Action 유니온의 모든 멤버를 커버하는 리듀서, 그리고 셀렉터 (companyAgents, companyTasks, companyApprovals, agentName). 원칙 2와 3을 동시에 구현한 케이스:

1case "decideApproval": {
2  const a = s.approvals[action.id];
3  if (!a || a.status !== "pending") return s;          // 이중 결정 방지
4  const decided = { ...a, status: action.approve ? "approved" : "rejected",
5                    decidedAt: Date.now(), decidedBy: "you" } as const;
6  return {
7    ...s,
8    approvals: { ...s.approvals, [a.id]: decided },
9    activity: [{ id: crypto.randomUUID(), companyId: a.companyId,
10      ts: Date.now(), actorId: "you", kind: "governance",
11      message: `${action.approve ? "Approved" : "Rejected"}: ${a.title}` },
12      ...s.activity],                                   // 결정은 기록됨
13  };
14}

Kimi 패스가 어떻게 진행되었는지: 이것이 K3가 막힌 유일한 빌드입니다. 워커 티어에서 두 번 시도했지만, 세 가지 케이스에서 중첩 객체를 변이하는 리듀서를 생성했습니다. 두 번 모두 체크에 의해 적발되었으며, diff를 읽어서가 아닙니다. 이 빌드는 동일한 프롬프트 그대로 프론티어 모델로 에스컬레이션되었고, 첫 번째 패스에서 깔끔하게 통과했습니다.

이것이 실제로 적용된 티어링 규칙입니다: K3는 기본 워커이고, 프론티어 모델은 순수성이 핵심인 하나의 빌드를 위해 예약됩니다. 제가 가장 먼저 깨뜨릴 것 같은 사례를 묻자, 이미 결정된 승인을 다시 결정하는 것이라고 답했고, 그래서 status !== "pending" 가드가 있습니다.

CHECK: grep을 통한 완전성. Action 유니온의 모든 액션에 케이스가 있거나, 그렇지 않으면 누르기를 기다리는 죽은 버튼입니다.

1grep -c 'case "' src/lib/store.tsx    # Action 유니온의 멤버 수 이상
2npx tsc --noEmit

BUILD 3: 하트비트

한 줄로 설명하는 이유: 실제 회사는 여러분이 보고 있지 않을 때도 움직입니다. 따라서 OS는 자체 시계로 틱(tick)을 보내야 합니다. 그렇지 않으면 여러분을 거짓말로 훈련시키는 것입니다.

첫 번째 원칙. 에이전트는 지속적으로 지출하고 진행합니다. 여러분의 주의는 불연속적입니다. 클릭할 때만 변하는 콘솔은 클릭 사이에는 아무 일도 일어나지 않는다고 가르치며, 이는 정확히 틀렸고 정확히 비용이 많이 듭니다.

따라서 모든 회사 OS는 하트비트가 필요합니다: 타이머에 의해 실행되는 작고, 제한적이며, 순수한 상태 전환입니다. 제한적(Bounded)이 핵심 단어입니다. 제한되지 않은 틱은 통제 불능입니다. 제한된 틱은 시뮬레이션된 지출이 몇 푼에 불과하며 파이프가 작동함을 증명합니다.

일반화된 프롬프트:

1실제 에이전트가 하나도 연결되지 않았는데도 이 시스템이 살아 있기를 원합니다. 그래서 열었을 때 숫자가 이미 움직이고 있도록요. 운영 중인 회사의 한 하트비트, 약 2초 정도를 상상해 보세요. 무엇이 변하나요? 약간의 돈이 소진되고, 약간의 작업이 진행되며, 로그 한 줄이 추가됩니다. 그 한 단계를 순수한 state -> state 함수로 만들어서 타이머로 실행할 수 있고 절대 아무것도 손상시키지 않는다고 신뢰할 수 있게 하세요. 모든 것을 제한하세요: 틱당 지출, 틱당 진행, 로그 길이. 가장 작은 신뢰할 수 있는 움직임의 양은 얼마이며, 어떻게 통제 불능이 되는 것을 막을 수 있나요? 틱을 구축하고 선택한 숫자를 방어하세요.

참조 구현. src/lib/sim.ts: runTick(state): State, 프로바이더의 단일 인터벌에 의해 2,600ms마다 실행됩니다. 틱당: 작업 중인 에이전트 하나가 $0.40에서 $3.04까지 발생, 열려 있는 작업 하나가 3%에서 10% 진행률 증가, 하트비트 라인 추가, 로그는 최신 500개 항목으로 제한.

숫자를 방어하라고 요청했을 때, K3의 답변은 설계로 남아 있습니다: 인간의 눈에 간신히 보이는 틱 (2.6초), 1시간 시뮬레이션 비용이 주머니 돈에 불과할 정도로 작은 지출, 메모리가 증가할 수 없도록 하는 로그 제한.

1export const TICK_MS = 2600;
2
3export function runTick(s: State): State {
4  const tickN = Math.floor(Date.now() / 1000);
5  const agents = Object.values(s.agents).filter((a) => a.status === "working");
6  if (agents.length === 0) return s;
7  const actor = pick(agents, tickN);
8  const spend = +(0.4 + (tickN % 13) * 0.22).toFixed(2);   // $0.40..$3.04, 제한됨
9  // ...하나의 작업 진행, 이벤트 추가...
10  return { ...s, activity: [...events, ...s.activity].slice(0, 500) };  // 제한됨
11}

그리고 정확히 하나의 인터벌. 후속 kimi -p 편집으로 단일 훅에 범위가 지정됨: simRunning 동안, TICK_MS마다 {type:"tick"} 디스패치, 정리 시 clearInterval, 다른 곳에는 인터벌 없음.

CHECK: 30초 동안 피드를 관찰하세요. 약 2.6초마다 라인이 추가됩니다. 일시 중지하면 멈춥니다. 재개하면 움직입니다. 2.6초보다 빠르게 라인이 도착하면 두 개의 인터벌이 있다는 뜻이며, 어떤 컴포넌트가 프로바이더의 일을 하고 있다는 의미입니다.

BUILD 4: 메모리

한 줄로 설명하는 이유: 새로고침하면 자신을 잊어버리는 회사는 데모이며, 데모와 시스템의 차이는 재로드(reload)입니다.

첫 번째 원칙. 모든 상태를 두 가지 종류로 나누면 설계는 저절로 완성됩니다. 도메인 상태 (누가 여기서 일하는지, 무엇이 지출되었는지, 무엇이 결정되었는지)는 회사입니다. 반드시 유지되어야 합니다. 세션 상태 (어떤 화면에 있었는지, 열린 모달, 토스트)는 여러분의 방문입니다. 이것을 유지하는 것은 버그입니다.

따라서: 실제 편집 후 디바운스되어 작성되고, 부팅 시 복원되는 도메인 슬라이스의 허용 목록 스냅샷. 그리고 하나의 순서 법칙: 복원이 완료되기 전에는 절대 쓰지 마십시오. 그렇지 않으면 회사를 빈 상태로 덮어씁니다.

일반화된 프롬프트:

1지금은 새로고침하면 회사 전체가 시드로 다시 날아갑니다. 그것은 데모이지 시스템이 아닙니다. 상태가 재로드 후에도 유지되기를 원합니다. 무엇이 실제로 저장될 가치가 있고 무엇이 아닌지 생각해 보세요: 무엇이 실제 회사 데이터이고 무엇이 단지 제가 어디를 클릭하고 있었는지에 불과한지? 실제 데이터를 허용 목록에 추가하고, 세션 쓰레기는 명시적으로 제외하세요. 잘못된 순간에 저장하면 어떤 실패 사례가 발생하며, 좋은 데이터를 반쯤 로드된 빈 상태로 덮어쓰지 않도록 어떻게 보장할 수 있나요? 저장 및 복원 경로를 구축하고, 그 함정을 밟기 전에 순서에 대해 경고해 주세요.

참조 구현. hydrate 액션, persistable() 허용 목록 (companies, agents, goals, tasks, approvals, runs, activity, customSkills, activeCompanyId), 400ms 디바운스된 쓰기, 그리고 프롬프트에서 명명된 함정은 한 줄로 보호됨:

1useEffect(() => {
2  if (!state.hydrated) return;      // 순서 법칙: 복원 전에는 절대 쓰지 않음
3  const id = window.setTimeout(() => {
4    window.localStorage.setItem(SNAPSHOT_KEY, JSON.stringify(persistable(state)));
5  }, 400);
6  return () => window.clearTimeout(id);
7}, [state]);

Kimi 패스가 어떻게 진행되었는지: 기존 스토어에 대한 kimi -p 편집, 새 파일이 아님. 프롬프트의 경고 절이 hydrated 게이트가 존재하는 이유입니다.

함정을 밟기 전에 이름을 묻자, K3는 바로 이 경쟁 조건을 지목했습니다: 첫 번째 렌더가 스냅샷이 로드되기 전에 지속 효과를 실행하여 시드가 저장된 데이터를 덮어씁니다. 프롬프트가 버그 찾기를 결과물로 만들 때 저렴한 모델도 실제 버그를 찾습니다.

CHECK: 두 상태 모두 도달 가능합니다. 시뮬레이션을 20초 동안 실행한 후 새로고침하면 숫자가 계속 증가합니다. 키를 지우고 새로고침하면 깨끗한 시드가 반환됩니다.

1# 브라우저 콘솔에서:
2localStorage.removeItem("meridian.snapshot")   # 사용자마다 다를 수 있음; 그런 다음 리로드

BUILD 5: 운영자 화면 (Operator Surface)

한 줄 요약: 운영자는 세 가지 질문을 고정된 순서로 묻습니다(무슨 일이 일어나고 있는가, 내가 필요한가, 무엇을 해야 하는가), 메인 화면은 위에서 아래로 이 질문들에 답해야 합니다.

기본 원칙. 스크린샷에서 예쁘게 보이는 것이 아니라 질문으로부터 조종석을 도출하세요:

• 무슨 일이 일어나고 있는가: 하나의 핵심 지표와 실시간 피드.
• 내가 필요한가: 위험 레이더(누가 막혀 있는지, 누가 예산을 초과했는지)와 대기 중인 결정 건수.
• 무엇을 해야 하는가: 각각은 클릭 한 번으로 접근 가능해야 하며, 찾아 헤매는 일이 없어야 합니다.

그리고 회사는 상태(state)이기 때문에, 모든 위젯은 스토어를 순수하게 읽어야 합니다. 자체 숫자를 캐싱하는 조종석은 거짓말을 하는 계기판입니다.

일반화된 프롬프트:

1하루 종일 실제로 응시하는 단 하나의 화면이 필요합니다. 저는 운영자입니다.
2화면을 열면 다음 순서로 답을 줘야 합니다: 무슨 일이 일어나는지, 내가 필요한지,
3그리고 무엇을 해야 하는지. 즉: 우리가 이기고 있는지 알려주는 하나의 숫자,
4누가 불이 났거나 예산을 초과했는지, 내 '예스'를 기다리는 것이 무엇인지,
5팀별로 돈이 얼마나 빨리 소진되고 있는지, 방금 일어난 일의 실시간 피드가 필요합니다.
6모든 위젯은 스토어만 읽고, 자체 상태를 가지지 않으며, 내가 필요한 모든 것은
7여기서 한 번의 클릭으로 접근 가능해야 합니다. 쉘과 이 조종석을 위에서 아래로
8그 순서대로 구축해 주세요.

참조 구현. 사이드바 쉘(네비게이션, 회사 전환기, 시뮬레이션 토글)과 CommandView: 델타가 있는 북스타 지표, 위험 레이더, 게이트로 딥링크되는 승인 대기 건수, company.budgets의 부서별 소모 막대, 최신 20개 활동 피드. 모두 셀렉터 기반, 로컬 인터벌 없음, 머신 값은 모노 폰트로 표시.

Context7이 다시 한번 유용했습니다: React 19 메모이제이션 가이드가 최신 상태로 제공되어, 틱(주기)마다 리렌더링이 발생해도 오래된 API 우회 없이 비용을 낮게 유지할 수 있었습니다.

조종석은 하나의 운영자 화면입니다. Work 보드는 또 다른 화면으로, 동일한 스토어와 동일한 토큰으로 구축됩니다. BUILD 2가 존재하면, 모든 화면은 그 위의 순수한 창(window)일 뿐입니다.

CHECK: 조종석을 처음 열고 세 가지 질문에 10초 안에 클릭 없이 소리내어 답하세요. 회사를 전환하세요. 모든 위젯이 오래된 숫자 누출 없이 즉시 전환됩니다. 승인 건수를 클릭하면 게이트로 이동합니다.

BUILD 6: 게이트 (The Gate)

한 줄 요약: 권력은 게이트를 통해 흐릅니다. 따라서 지출, 고용, 출시, 해고를 결정하는 그 어떤 것도 명시적이고 기록된 '예스' 없이 처리되어서는 안 됩니다.

기본 원칙. 자율성은 권리가 아니라 예산(budget)입니다. 당신을 해칠 수 있는 다섯 가지 동사(지출, 고용, 재정의, 게시, 해고)는 각각 결정 시점에 동일한 네 가지를 필요로 합니다:

• 요청 사항
• 요청자의 근거
• 시스템 자체의 정책 검사 결과(투명하게 공개)
• 이름과 타임스탬프가 포함되어 영구 로그에 기록되는 결정

쉽게 놓칠 수 있는 한 가지 더: 정책 검사가 실패했을 때, 승인은 재정의(override)처럼 느껴져야 합니다. 기본값을 그대로 두는 곳에서 거버넌스는 죽습니다.

일반화된 프롬프트:

1전체 시스템의 규칙은 다음과 같습니다: 에이전트는 내가 '예스'라고 말하지 않으면
2절대 돈을 쓰거나, 고용하거나, 공개적인 것을 출시하거나, 누군가를 해고하지 않습니다.
3그 '예스'가 존재하는 단 하나의 수신함(inbox)을 구축해 주세요. 각 항목은 요청,
4누가 요청했는지, 이유, 금액, 그리고 시스템 자체의 정책 검사(예산 내인가?
5매니저가 있는가? 상한선 이하인가?)를 보여줘서 내가 결정하기 전에 시스템의
6추론 과정을 볼 수 있어야 합니다. 승인과 거절 모두 UI 토글만이 아니라 내 이름이
7붙은 영구적인 흔적을 로그에 남깁니다. 그리고 검사가 실패했다면 승인을 쉬운
8기본값으로 만들지 말고, 의도적으로 재정의(override)하도록 만드세요. 수신함을 구축하세요.

게이트. 각 카드는 요청, 요청자, 근거, 금액, 그리고 시스템 자체의 정책 검사 결과를 보여줍니다. 승인과 거절만이 유일한 종료 지점이며, 둘 다 로그에 기록됩니다.

참조 구현. ApprovalsView: 보류 항목을 먼저 표시하고, 각 카드에는 유형 배지, 요청자, 근거, 금액(모노 폰트), 그리고 통과/실패 상태의 정책 검사와 세부 텍스트가 포함됩니다. 프롬프트가 요구한 대로 기본값을 전환하는 코드 라인:

1const failed = a.checks.some((c) => !c.passed);
2// ...
3<button className={failed ? "danger" : "primary"}
4  onClick={() => dispatch({ type: "decideApproval", id: a.id, approve: true })}>
5  {failed ? "재정의 및 승인 (Override and approve)" : "승인 (Approve)"}
6</button>

결정 자체는 BUILD 2의 decideApproval 케이스입니다. 이것이 핵심입니다: 게이트는 화면이지만, 법칙은 리듀서(reducer)에 있습니다. UI에서만 적용되는 게이트는 단지 제안(suggestion)에 불과합니다.

CHECK: 시드된 승인 항목 하나를 승인하세요. "사용자에 의해 승인됨"이라는 스탬프와 함께 결정됨(decided) 상태로 이동하고, 거버넌스 라인이 피드에 기록됩니다. 실패한 검사가 있는 항목을 찾으세요. 버튼이 "재정의 및 승인 (Override and approve)"으로 표시되어야 합니다.

그런 다음 시뮬레이션을 1분 동안 지켜보세요: 어떤 승인이라도 당신의 클릭 없이 해결된다면, 게이트는 고장난 것이며, 그것이 고쳐질 때까지 다른 것은 중요하지 않습니다.

BUILD 7: 명령줄 (The Command Line)

한 줄 요약: 운영자는 명령을 내리며, 명령을 파싱하기 위해 모델 호출이 필요한 것은 정규식보다 느리고, 비싸며, 덜 결정적입니다.

기본 원칙. 운영자의 발언에는 두 가지 유형이 있습니다. 명령어("create task x, assign to bea, p1", "move MER-1042 to review", "budget report")는 고정된 문법과 알려진 동작을 가집니다: 로컬에서 파싱하고, 실제 스토어 액션을 디스패치하며, 정확히 무엇이 변경되었는지 출력합니다. 총 비용은 0, 대기 시간은 0입니다.

그 외의 모든 것은 대화(conversation)이며, 그것이 모델의 역할입니다. 라우팅 규칙은 결정론적( deterministic) 우선, 모델은 폴백(fallback), 그리고 항상 추적(trace)을 보여주는 것입니다. 조용히 일을 처리하는 OS는 아무것도 하지 않는 OS와 구분할 수 없습니다.

일반화된 프롬프트:

1이 회사를 운영하는 가장 빠른 방법은 클릭을 돌아다니는 것이 아니라 명령줄입니다.
2"create task: fix onboarding, assign to bea, p1" 또는 "move MER-1042 to review"
3또는 "budget report"라고 입력하면 그냥 실행하고, 스토어에 반영하고, 정확히
4무엇이 바뀌었는지 보여주는 채팅을 원합니다. 알려진 명령어라면 모델 호출도,
5비용도, 대기 시간도 없어야 합니다. 일치하는 것이 없을 때만 나중에 실제 모델로
6폴백합니다. 먼저 파싱하고, 실제 액션을 디스패치하고, 추적을 출력하세요.
7그리고 그냥 실행할 수 있는 것을 모델로 라우팅하지 마세요.

입력된 명령어는 스토어에 직접 도달하고 추적을 출력하며, 모델 호출이 없습니다. 명령어가 아닌 문장만 로컬 K3 런타임으로 폴백되며, 여기서는 `kimi -p (local, k3)` 추적과 함께 응답하는 모습을 보여줍니다.

참조 구현.

KimiSpaceView: 명령어 문법에 대한 정규식 파싱, 스토어의 셀렉터를 통한 이름-투-ID 확인, 디스패치, 추적 라인을 다시 채팅으로 출력. 이 빌드에서는 폴백 브랜치가 플레이스홀더를 출력합니다. 모델은 BUILD 8의 문제이기 때문입니다:

1if ((m = input.match(/^create task:\s*(.+?),\s*assign to\s+(\w+),\s*(p[0-3])$/i))) {
2  dispatch({ type: "createTask", title: m[1],
3    assigneeId: agentIdByName(m[2]), priority: m[3] as never, by: "you" });
4  next.push({ role: "system", body: `Created task "${m[1]}" (${m[3]}) -> ${m[2]}` });
5} else {
6  next.push({ role: "assistant", body: "(would route to local kimi runtime)" });
7}

CHECK: create task: refresh onboarding emails, assign to Bea, p1은 실제 작업을 생성하고(코드 자동 생성) 추적을 출력합니다. budget report는 부서별로 지출 한도 대비 사용액을 즉시 출력합니다. 스피너도 없고, 모델이 호출되지 않았기 때문입니다. 의미 없는 문장은 플레이스홀더에 도달합니다.

로딩 상태를 보여주는 명령어 처리는 당신이 비용을 지불하고 있는 모델 호출이며, 그래서는 안 됩니다.

BUILD 8: 실제 런타임 (The Real Runtime)

세 줄 요약: 지금까지의 모든 것은 시뮬레이션 위에서 실행됩니다. 실제 에이전트와 연결되지 않은 회사 OS는 디오라마(diorama)에 불과합니다. 마지막 요소는 실제 런타임으로의 다리(bridge)이며, 생각하고 지출할 수 있는 프로세스를 생성하기 때문에 시스템에서 가장 위험한 파일입니다.

따라서 울타리(fence)가 곧 기능입니다: 동시 실행 1개, 입력 제한, 종료 타이머, 격리된 작업 디렉토리, 절대 다시 네트워크를 타고 나오지 않는 자격 증명.

기본 원칙. 런타임이 무엇이든(CLI, API, 큐), 다리는 동일한 다섯 가지 벽이 필요하며, 각각 하나의 공격에 대응합니다:

• 동시에 몇 개: 하나. 그렇지 않으면 멈춘 실행이 쇄도(stampede)가 됩니다.
• 입력 크기: 제한됨. 그렇지 않으면 누군가가 당신의 예산에 책 한 권을 붙여넣습니다.
• 시간: 종료 타이머. 그렇지 않으면 하나의 중단(hang)이 영원히 락(lock)을 점유합니다.
• 위치: 전용 작업 디렉토리. 그렇지 않으면 에이전트가 당신의 저장소를 읽습니다.
• 누출되는 것: 없음. 모든 응답에 토큰이나 자격 증명이 절대 포함되어서는 안 됩니다.

그리고 하나의 우아한 규칙: 런타임이 없으면 시뮬레이션으로 저하(degrade)되고, 절대 충돌(crash)하지 않습니다. 콘솔은 에이전트보다 오래 살아남아야 합니다.

일반화된 프롬프트:

1좋아요, 지금까지의 모든 것은 가짜였습니다, 멋진 시뮬레이션이요. 이제 실제
2에이전트를 연결합니다. 이 기계에 실제 CLI가 설치되어 있고 로그인되어 있습니다.
3알려진 명령어가 아닌 것을 입력하면 실제 에이전트를 생성하고, 실제 모델과
4내 자격 증명을 사용하여 응답하세요. 하지만 이것은 앱에서 가장 무서운 경로입니다.
5지출할 수 있는 프로세스를 생성하는 것이기 때문에, 철저하게 울타리를 치고
6구축하기 전에 그 울타리가 무엇인지 알려주세요: 동시에 몇 개가 실행되는지,
7입력 크기는 얼마나 되는지, 얼마나 오래 실행되면 종료할지, 어디서 실행되는지,
8무엇이 절대 밖으로 새어나가면 안 되는지. 그리고 CLI가 없으면 충돌하지 말고
9시뮬레이션 모드를 유지하세요.

참조 구현. Kimi는 여기서 빌더이자 동시에 빌드된 대상입니다: 다리가 생성하는 런타임은 위의 모든 파일을 생성한 것과 동일한 ~/.kimi-code/bin/kimi이며, 운영자의 메시지를 stdin으로 받아 kimi -p로 호출되고, 기존 kimi 로그인 자격 증명을 재사용합니다.

구현된 울타리:

• 한 번에 하나의 채팅 (두 번째 동시 요청은 HTTP 409 반환)
• 8,000자 입력 제한
• 180초 종료 타이머
• 전용 .kimi-runtime 작업 디렉토리
• 토큰을 반환하는 엔드포인트 없음

두 개의 엔드포인트: GET /local-runtime/status 및 POST /local-runtime/kimi/chat. 그리고 다리가 로컬 프로세스를 생성하기 때문에, 개발 서버는 127.0.0.1에만 바인딩됩니다:

1export default defineConfig({
2  plugins: [react(), kimiOAuthProxy(), localKimiBridge()],
3  // local-first: 다리는 당신의 CLI를 생성합니다. 이 기계 밖으로 절대 노출하지 마세요.
4  server: { port: 4173, host: "127.0.0.1" },
5  preview: { port: 4173, host: "127.0.0.1" },
6});

마지막 kimi -p 편집을 통해 BUILD 7의 플레이스홀더 브랜치를 실제 POST로 교체했으며, 오프라인 폴백도 그대로 유지했습니다.

CHECK: 기능이 아니라 울타리를 증명하세요. 상태 엔드포인트가 CLI를 보고합니다. 명령어가 아닌 문장은 실제 모델이 응답합니다. 그런 다음 공격해보세요: 두 개의 채팅을 동시에 시도하면 두 번째는 409를 반환합니다. 9,000자를 붙여넣으면 생성 전에 거부됩니다. CLI 바이너리 이름을 바꾸면 앱이 시뮬레이션 모드에서 계속 실행됩니다.

1curl -s http://127.0.0.1:4173/local-runtime/status

롤아웃 (The Rollout)

주말에 구축한 OS라도 채택에는 몇 주가 걸립니다. 단계별로 진행하세요.

• 1주차, 관찰 (Observe). BUILD 0부터 5까지, 시뮬레이션만 실행합니다. 틱이 돈과 작업을 이동시키는 것을 지켜보세요. 조종석의 세 가지 질문에 10초 안에 답할 수 있게 되면 다음 단계로 넘어갑니다.
• 2주차, 게이트 (Gate). BUILD 6과 7. 시드된 승인을 결정합니다. 입력된 명령어로 회사를 운영합니다. 당신이 내리는 모든 결정이 로그에 일치하는 거버넌스 라인을 남기는 것을 확인하면 다음 단계로 넘어갑니다.
• 3주차, 연결 (Connect). BUILD 8. 실제 런타임이 채팅에 응답하며, 자동 조종 장치는 꺼진 상태를 유지합니다. 409 오류, 8k 제한, 종료 타이머가 공격했을 때 모두 작동하는 것을 확인하면 다음 단계로 넘어갑니다.
• 4주차, 운영 (Operate). 하나의 실제 에이전트, 하나의 실제 작업, 하나의 작은 예산. 모든 실행을 검토합니다. 예상치 못한 지출이나 보지 못한 결정 없이 하루가 완전히 지나가면 다음 단계로 넘어갑니다.

4주차는 숫자가 더 이상 시뮬레이션되지 않는 시점입니다. 부서별 소모, 예측, 그리고 모델/토큰 원장 — 모든 실제 비용이 에이전트와 작업으로 추적 가능합니다.

각 단계가 다음 단계를 잠금 해제합니다. 1일 차에 4주차를 시작하는 것이 교육 청구서(invoice)에 자금을 대는 방법입니다.

런북 (The Runbook)

시스템이 제기하는 모든 알람과 그에 따른 조치입니다. 신호는 모든 회사 OS에 일반적이며, 조치는 참조 구현이 가리키는 곳입니다.

• 피드가 멈추고, 시뮬레이션이 켜져 있음. 중복되거나 누락된 인터벌, 또는 뷰가 상태를 변이(mutate)시킴. setInterval은 프로바이더에 단 하나만 있어야 합니다. 뷰는 창(window)일 뿐입니다.
• 새로고침 시 숫자가 초기화됨. 스냅샷이 하이드레이트(hydrate) 전에 쓰였거나, 전혀 쓰이지 않음. 지속(persist) 효과의 하이드레이트된 게이트를 확인하세요.
• 승인이 자체적으로 해결됨. decide 액션 이외의 것이 상태를 변경함. decideApproval만이 승인 상태를 변경할 수 있습니다. 리듀서를 감사(audit)하세요.
• 소모 막대가 100% 초과. 부서가 한도를 초과함. 지출 게이트가 이미 보류 중이어야 합니다. 그렇지 않다면 검사가 누락된 것입니다.
• 명령어가 아무것도 하지 않음. 문법이 일치하지 않거나 이름이 확인되지 않음. 파싱 결과를 출력하고, 이름이 스토어에 존재하는지 확인하세요.
• 채팅이 409 반환. 실제 실행이 이미 진행 중입니다. 기다리세요. 동시 실행 1개 제한이 작동 중입니다.
• 채팅이 502 반환. 인증 프록시가 업스트림에 도달할 수 없음. 네트워크 문제입니다. 앱은 시뮬레이션 모드에서 계속 실행되어야 합니다.
• 상태가 CLI 누락이라고 표시. 런타임이 없거나 로그인되지 않음. kimi login을 실행하거나 시뮬레이션을 유지하세요. 절대 충돌하지 마세요.
• 생성 후 타입체크 실패. 생성된 파일이 모델의 의도와 다름. 프롬프트를 수정하고 다시 생성하세요. 수동으로 패치된 파일은 재현 불가능한 빌드입니다.

규칙 (Rules) — 출력하여 보관하세요

1. 회사는 상태(state)입니다: 하나의 타입화된 트리이며, 모든 화면은 창(window)이지, 소스(source)가 아닙니다.
2. 일곱 개의 명사(noun), 각각 하나의 정의. 두 개의 명사가 겹치는 것은 당신이 출시하게 될 혼란입니다.
3. 절대 비어 있는 상태로 시작하지 마세요. 모델의 모든 상태가 시드에 최소 한 번은 나타납니다.
4. 상태는 하나의 리듀서에서 변경되거나 변경되지 않습니다. 디스패치하지 않는 버튼은 죽은 버튼입니다.
5. 하트비트는 제한적입니다: 지출 제한, 진행률 제한, 로그는 500개로 제한.
6. 도메인 상태는 지속(persist)되고, 세션 상태는 절대 지속되지 않습니다. 하이드레이트 전에 절대 쓰지 마세요.
7. 권력은 게이트를 통해 흐릅니다: 지출, 고용, 재정의, 게시, 해고는 모두 '예스'를 위해 대기합니다.
8. 실패한 정책 검사는 승인을 명시적인 재정의(override)로 만들며, 절대 기본값이 아닙니다.
9. 게이트의 법칙은 리듀서에 있습니다. UI에서만 적용되는 게이트는 제안(suggestion)에 불과합니다.
10. 기록되지 않은 것은 일어나지 않은 것입니다. 모든 결정은 이름과 타임스탬프를 기록합니다.
11. 결정론적( deterministic) 우선, 모델은 폴백. 정규식을 파싱하기 위해 모델에 비용을 지불하지 마세요.
12. 모든 실제 런타임에는 다섯 개의 벽이 있습니다: 한 번에 하나, 입력 제한, 종료 타이머, 격리된 작업 디렉토리, 자격 증명 누출 제로.
13. 런타임이 죽어도 콘솔은 살아있습니다. CLI가 없으면 시뮬레이션 모드, 절대 충돌하지 않음.
14. 로컬 바인딩, 127.0.0.1. 당신의 CLI를 생성하는 다리는 외부에 노출하는 대상이 아닙니다.
15. 파일을 수정하지 말고 프롬프트를 수정하세요. K3가 작업자입니다. 빌드 하나를 에스컬레이션하고, 프로젝트 전체를 건드리지 마세요.

마무리 (Closing)

저장소가 핵심은 아니었습니다. Meridian은 하나의 스택에서 구현된 하나의 예시일 뿐이며, 그 기반이 되는 아홉 가지 요소는 당신의 스택과 무관합니다: 어휘(Vocabulary), 세계(World), 진실(Truth), 하트비트(Heartbeat), 메모리(Memory), 화면(Surface), 게이트(Gate), 명령줄(Command Line), 런타임(Runtime).

이 아홉 가지를 Rails나 Rust 또는 매크로가 있는 스프레드시트로 구축하더라도 당신은 회사 OS를 가지게 됩니다. 게이트나 로그를 건너뛰면, 어떤 언어로든 UI만 있는 누수(leak)가 생깁니다.

그리고 실제로 무엇이 이것을 구축했는지 주목하세요: 워커-티어 모델, 두 가지 스킬, 아홉 개의 프롬프트, 그리고 각각 후의 검사. 방금 읽은 방법론은 그것이 생성하는 기계(machine)입니다. 당신이 명세서(spec)를 쓰고, 저렴한 에이전트가 파일을 작성하며, 벽(walls)이 모든 사람을 정직하게 만듭니다. 당신 자신도 포함해서요.

오늘 밤: BUILD 0을 작성하세요. 당신의 에이전트를 열고, 어휘 프롬프트를 전달하고, 당신 회사의 일곱 가지 명사를 정의하게 하세요. 단 하나의 동작도 작성하게 하지 마세요. 명사가 첫날 밤의 전부이며, 그 외의 모든 것은 명사 위의 창(window)일 뿐입니다.

그러니 논쟁할 가치가 있는 질문은 이것입니다: 당신 회사의 일곱 가지 명사는 무엇이며, 거의 병합할 뻔했던 두 가지는 무엇입니까? 오늘 밤 BUILD 0을 구축하고 당신의 타입과 함께 답글을 남겨주세요.

참조 저장소를 구축하면서 작성한 제 노트에서 비롯되었습니다; 모든 파일은 Kimi K3를 통해 Kimi Code CLI에 의해 생성되었으며, 프론티어 모델이 이 글을 편집하고 하나의 에스컬레이션된 빌드(리듀서)를 처리했습니다. 주장은 여기에서 확인할 수 있습니다 (https://github.com/codejunkie99/meridian-company-os).

이 글은 Kimi K3 및 Kimi Code CLI로 구축하는 동안 저자의 노트에 의해 작성되었으며, Kimi K3 Code 및 Opus 4.7에 의해 편집되었습니다.