Mission Control (OpenClaw 위에 올라탄 AI 에이전트 관제실)

AI 에이전트가 하나일 때는 터미널 하나로도 충분합니다.
하지만 에이전트가 여러 개가 되고, 작업이 끊임없이 생성되고, 누가 어떤 일을 하고 있는지 추적해야 하는 순간부터 문제는 완전히 달라집니다.

mission-control은 바로 그 지점에서 등장한 프로젝트입니다. 단순히 “에이전트를 실행하는 도구”가 아니라, 에이전트 운영 자체를 눈에 보이게 만드는 대시보드입니다. 작업 생성, 계획 수립, 에이전트 할당, 실행, 결과물 추적까지 한 화면에서 이어 붙이려는 시도가 이 프로젝트의 핵심입니다. 저장소 설명 기준으로 이 프로젝트는 OpenClaw Gateway를 통해 AI 에이전트를 관리하고, 작업을 배정하고, 멀티 에이전트 협업을 조율하는 오케스트레이션 대시보드입니다. 또한 2026년 3월 13일 기준 최신 릴리스는 v1.5.3이며, 저장소는 약 1.4k 스타와 300개가 넘는 포크를 기록하고 있습니다. (GitHub)

 

GitHub - crshdn/mission-control: AI Agent Orchestration Dashboard - Manage AI agents, assign tasks, and coordinate multi-agent c

 

---

이 프로젝트가 정확히 무엇인가

Mission Control은 OpenClaw를 위한 운영용 UI 레이어에 가깝습니다.
중요한 점은, 이 저장소 자체가 에이전트 런타임은 아니라는 것입니다. README는 Mission Control을 “대시보드”, OpenClaw Gateway를 “실제로 작업을 수행하는 AI 런타임”으로 분리해서 설명합니다. 즉 구조적으로 보면:

• Mission Control: 작업 관리, UI, 상태 추적, 플래닝, 이벤트 시각화
• OpenClaw Gateway: 실제 에이전트 실행, 세션 관리, 모델 연결
• AI Provider: Anthropic, OpenAI 등 실제 모델 호출 계층

이 분리가 꽤 중요합니다. 많은 AI 에이전트 프로젝트가 “실행기”와 “관제 UI”를 하나로 뭉쳐 놓는데, Mission Control은 이를 분리해 두었기 때문에 운영 관점에서 더 유연합니다. 대시보드를 다른 머신에 띄우고, Gateway는 별도 서버에서 돌릴 수 있게 설계되어 있으며, .env.example에는 원격 Gateway 연결용 URL과 토큰, 그리고 Tailscale 기반 연결 예시까지 포함돼 있습니다. (GitHub)

---

누가 만들었고, 어떤 생태계에 속해 있나

저장소 소유자는 crshdn이며, 현재는 프로젝트 소개 페이지에서 “Formerly known as Mission Control”이라는 문구와 함께 Autensa 브랜드로도 소개되고 있습니다. 다만 GitHub 저장소 이름과 오픈소스 프로젝트 본체는 여전히 mission-control입니다. 즉, 오픈소스 저장소는 Mission Control이고, 이를 기반으로 한 브랜딩/사이트는 Autensa로 보입니다. (GitHub)

생태계 관점에서 보면 이 프로젝트는 OpenClaw 중심의 AI agent ops 툴링에 속합니다.
전통적인 백엔드 운영에서 Kubernetes 대시보드나 CI/CD 관제판이 필요했던 것처럼, AI 에이전트 운영에서도 “누가 무슨 작업을 수행 중인지”, “어떤 spec으로 실행됐는지”, “결과물이 어디에 생성됐는지”를 보여주는 계층이 필요해졌고, Mission Control은 그 문제를 직접 겨냥합니다. README와 공식 사이트 모두 작업 생성 → AI 플래닝 → 에이전트 자동 생성/할당 → 실행 → 결과물 전달의 흐름을 전면에 내세우고 있습니다. (GitHub)

---

왜 이 프로젝트가 등장했을까

이 프로젝트의 등장 배경은 비교적 분명합니다.

에이전트 시스템이 실제 개발 워크플로에 들어오기 시작하면, 개발자는 곧바로 두 가지 문제를 만나게 됩니다.

첫째, 실행은 되는데 운영이 안 보인다는 문제입니다.
에이전트가 작업을 받았는지, 멈췄는지, 어떤 컨텍스트로 작업 중인지, 산출물이 어디에 있는지 확인하기가 어렵습니다. 단순 CLI 중심 운영은 작은 실험에는 좋지만, 여러 작업과 여러 에이전트가 동시에 움직이는 순간 급격히 피로해집니다.

둘째, 작업 정의가 너무 거칠다는 문제입니다.
사람이 “이 기능 좀 만들어줘”라고 던진 요청은 에이전트가 바로 수행하기엔 모호할 때가 많습니다. Mission Control은 이 사이에 “AI Planning” 단계를 넣습니다. 즉, 작업을 바로 실행하지 않고 먼저 AI가 질문을 던져 요구사항을 구체화하고, 그 답변을 바탕으로 spec을 만들고, 그 뒤에 에이전트를 생성·할당하는 방식입니다. 이 플로우는 README와 changelog에서 반복적으로 강조됩니다. (GitHub)

이 점이 인상적인 이유는, 이 프로젝트가 단순한 “대시보드 UI”가 아니라 요구사항 정제 단계까지 포함한 운영 도구라는 점입니다. 보통 오케스트레이션 툴은 이미 정의된 잡을 분배하는 데 집중하지만, Mission Control은 “잡을 어떻게 정의할 것인가”부터 관여합니다.

---

핵심 기능 1: Kanban 기반 작업 관리

Mission Control의 가장 눈에 띄는 기능은 작업 보드입니다.
초기 릴리스 기준으로도 작업 생성/수정/삭제, 드래그 앤 드롭 Kanban, 우선순위, 마감일 지원이 들어갔고, 작업 상태는 PLANNING → INBOX → ASSIGNED → IN PROGRESS → TESTING → REVIEW → DONE의 7단계로 관리됩니다. 프론트엔드에서는 @hello-pangea/dnd를 사용하고 있어 드래그 기반 조작을 염두에 둔 설계라는 것도 확인할 수 있습니다. (GitHub)

이 구조가 좋은 이유는 단순합니다.

개발 조직이 이미 익숙한 Jira/Trello류 mental model을 그대로 가져오기 때문입니다.
AI 에이전트를 새 개념으로 도입하더라도, 작업 상태 표현은 기존 개발팀 문법을 그대로 쓰게 해주는 셈입니다. 즉, “에이전트를 위한 전용 툴”이면서도 “사람 팀이 보기 쉬운 보드”를 유지합니다.

예를 들어 이런 작업을 등록한다고 생각해볼 수 있습니다.

const newTask = {
  title: "결제 실패 재현 및 원인 분석",
  description: "프로덕션 로그 기준으로 특정 카드사 결제 실패 원인 조사",
  priority: "high",
  dueDate: "2026-03-15",
};

여기서 중요한 것은 이 작업이 단순 TODO가 아니라, 이후 Planning과 Agent Assignment의 입력이 된다는 점입니다.

---

핵심 기능 2: AI Planning

Mission Control을 흔한 태스크 보드와 구분 짓는 지점은 이 기능입니다.

초기 릴리스 설명에 따르면 Planning 모드는 다음을 포함합니다.

• AI와의 인터랙티브 Q&A
• 객관식 + 기타 입력
• 답변 기반 자동 spec 생성
• 중단된 planning 세션 재개

이 말은 곧, 사용자가 던진 거친 작업 설명을 바로 에이전트에 넘기지 않고 질문을 통해 명세화한다는 뜻입니다. (GitHub)

개발자 관점에서 이건 꽤 실용적입니다.
실무에서 에이전트 실패의 원인은 모델 성능 그 자체보다도 모호한 입력인 경우가 많기 때문입니다. Planning 단계는 다음과 같은 식으로 동작한다고 볼 수 있습니다.

type PlanningQuestion = {
  id: string;
  question: string;
  type: "multiple-choice" | "free-text";
  options?: string[];
};

type PlanningAnswer = {
  questionId: string;
  answer: string;
};

type TaskSpec = {
  objective: string;
  constraints: string[];
  deliverables: string[];
  acceptanceCriteria: string[];
};

즉, Mission Control은 “사용자 자연어 요청”을 곧바로 “에이전트 실행 입력”으로 보내는 대신, 중간에 구조화된 spec 객체로 압축하는 계층을 둡니다.

이 설계는 LLM 시스템에서 굉장히 익숙한 패턴입니다.
자유 입력을 그대로 실행하지 않고, 먼저 질문-응답을 거쳐 schema-friendly한 표현으로 정규화하는 방식이죠. changelog에서 spec generation과 planning persistence가 따로 강조되는 이유도 여기에 있습니다. (GitHub)

---

핵심 기능 3: 에이전트 자동 생성과 상태 추적

초기 릴리스에는 task requirement에 따라 자동 에이전트 생성, 에이전트 아바타, 상태 추적, 각 에이전트별 SOUL.md personality 지원이 포함돼 있습니다. 또 최근 소개 페이지에는 OpenClaw Gateway에 이미 존재하는 에이전트를 가져오는 “Gateway Agent Discovery”도 핵심 기능으로 올라와 있습니다. .env.example에는 ALLOW_DYNAMIC_AGENTS 설정도 있어 런타임 동적 에이전트 생성을 켜고 끌 수 있습니다. (GitHub)

이건 결국 에이전트를 “프로세스”가 아니라 조직 내 역할 단위로 취급한다는 의미입니다.

예를 들어 한 작업이 들어오면 내부적으로 이런 구성을 상상할 수 있습니다.

const agentProfile = {
  name: "QA Investigator",
  role: "결제 실패 재현 및 테스트 자동화",
  status: "standby",
  personaFile: "SOUL.md",
  model: "claude-sonnet",
};

일반적인 AI 툴은 사용자가 매번 모델과 프롬프트를 직접 고르는 식입니다.
반면 Mission Control은 역할에 맞는 agent abstraction을 먼저 세우고, 그 뒤에 실행을 붙입니다. 이것은 멀티 에이전트 시스템을 실제 운영 가능한 형태로 바꾸는 데 더 적합합니다.

---

핵심 기능 4: OpenClaw Gateway 연동

Mission Control은 단독 제품이 아닙니다.
실행은 OpenClaw Gateway가 맡고, Mission Control은 WebSocket으로 거기에 붙습니다. 아키텍처 다이어그램에도 Mission Control과 Gateway 사이가 WS로 연결되어 있고, .env.example의 기본값은 ws://127.0.0.1:18789입니다. 또한 원격 서버나 Tailscale 환경용 wss://... 예시도 공식적으로 제공됩니다. (GitHub)

이 분리는 운영적으로 매우 현실적입니다.

예를 들면:

• 맥북에서는 Mission Control UI만 띄우고
• 별도 리눅스 머신에서는 Gateway와 에이전트를 실행하고
• 네트워크는 Tailscale로 안전하게 연결

이런 식의 구성이 가능합니다. README는 이 멀티 머신 시나리오를 별도 섹션으로 설명하고 있으며, 로컬 실행뿐 아니라 분산 실행을 전제로 둔 프로젝트라는 점이 드러납니다. (GitHub)

---

기술 스택 분석

이 저장소의 핵심 스택은 꽤 명확합니다.

• Next.js 14
• React 18
• TypeScript 5
• SQLite
• Tailwind CSS
• Zod
• Zustand
• Playwright

이 정보는 changelog와 package.json 양쪽에서 확인됩니다. 특히 next@14.2.21, react@18.2.0, better-sqlite3, zod, zustand, playwright가 직접 명시되어 있습니다. (GitHub)

여기서 설계적 의미를 읽어보면 이렇습니다.

1) Next.js 14 App Router

UI와 API를 같은 프로젝트 안에 묶어 운영 비용을 낮췄습니다.
README의 프로젝트 구조에서도 src/app/api/tasks, src/app/api/agents, src/app/api/openclaw, src/app/api/webhooks가 나뉘어 있어, 프론트엔드와 백엔드를 단일 레포 안에서 처리하는 full-stack Next.js 패턴을 사용합니다. (GitHub)

2) SQLite

작은 팀, 개인 운영, self-hosted 환경에 잘 맞는 선택입니다.
README는 DB가 자동 생성된다고 설명하고, Docker 실행 시 데이터 볼륨 분리도 제공합니다. 거대한 멀티테넌트 SaaS보다는 로컬 퍼스트/셀프 호스팅에 최적화된 감각입니다. (GitHub)

3) Zod

에이전트 시스템은 입력이 유동적이기 때문에 validation이 특히 중요합니다.
공식 사이트가 “Security First”의 일부로 Zod validation을 강조하는 것도 그 때문입니다. 자유 입력, planning answers, webhook payload, gateway interaction이 섞이는 시스템에서 schema validation은 사실상 필수입니다. (autensa.com)

4) Playwright

테스트에 Playwright가 들어간 점도 눈에 띕니다.
이 프로젝트가 단순 데모가 아니라 “실제 UI 흐름 검증”을 어느 정도 염두에 둔 운영 툴이라는 신호로 볼 수 있습니다. (GitHub)

---

내부 구조를 아키텍처로 풀어보면

README의 구조와 설명을 토대로 이 프로젝트를 재구성하면 다음처럼 이해할 수 있습니다. (GitHub)

이 흐름에서 중요한 것은, 이 프로젝트가 단순 CRUD 앱이 아니라는 점입니다.

실제 핵심 루프는 아래와 같습니다.

1. 사용자가 task 생성
2. planning session이 시작됨
3. spec이 생성됨
4. agent가 선택되거나 자동 생성됨
5. OpenClaw Gateway로 dispatch
6. 결과물과 이벤트가 다시 Mission Control로 돌아옴
7. UI와 DB에 반영됨

즉, 이 시스템의 본질은 task system + planning engine + runtime bridge + observability UI의 결합입니다.

---

프로젝트 구조에서 읽히는 설계 의도

README에 나온 구조는 꽤 많은 것을 말해줍니다. tasks, agents, openclaw, webhooks가 API 레벨에서 분리돼 있고, 컴포넌트도 MissionQueue, PlanningTab, AgentsSidebar, LiveFeed, TaskModal처럼 역할이 뚜렷합니다. (GitHub)

이걸 보면 UI가 단순 뷰가 아니라, 아래의 운영 관심사를 중심으로 설계됐다는 걸 알 수 있습니다.

• MissionQueue: 작업 lifecycle 관리
• PlanningTab: 요구사항 수집과 spec 생성
• AgentsSidebar: agent fleet 가시화
• LiveFeed: 실시간 이벤트 스트림
• TaskModal: 작업 등록/편집 입력점

즉, 이 프로젝트는 “에이전트 채팅창”이 아니라 운영 콘솔입니다.

이 차이는 큽니다.
채팅 UI는 개별 요청 처리에는 좋지만, 여러 작업과 여러 역할을 동시에 다루기 어렵습니다. 반면 운영 콘솔은 멀티 태스크와 상태 변화를 다루기 위해 설계됩니다. Mission Control이 노리는 곳은 분명히 후자입니다.

---

보안과 운영 면에서 괜찮은 점

이 프로젝트는 예상보다 운영 배려가 잘 들어가 있습니다.

공식 소개 페이지와 README를 보면 다음 요소가 강조됩니다.

• Bearer token 기반 API 인증
• HMAC webhook 검증
• Zod validation
• path traversal protection
• security headers
• same-origin 브라우저 요청 허용
• Docker 지원
• 멀티 머신 지원
• self-hosted / privacy-first 지향

특히 README는 MC_API_TOKEN을 설정하면 외부 API는 Bearer 토큰이 필요하고, 브라우저 UI의 same-origin 요청은 자동 허용된다고 설명합니다. changelog에는 이 same-origin 처리 관련 버그 수정도 별도로 기록돼 있습니다. (GitHub)

이건 “대충 만든 해커톤 UI”와의 차이를 보여줍니다.
에이전트 시스템은 웹훅, 파일 다운로드, 원격 실행, 외부 모델 호출이 섞이기 때문에 보안이 허술하면 바로 문제가 됩니다. Mission Control은 적어도 공개 문서상으론 이 부분을 꽤 의식하고 있습니다. (autensa.com)

---

실제 사용 시나리오

이 프로젝트가 잘 맞는 팀은 다음과 같습니다.

1) 개인 개발자가 여러 에이전트를 돌릴 때

OpenClaw 기반 자동화나 코드 생성 에이전트를 여러 개 쓰고 있는데, 현재 상태를 한눈에 보고 싶을 때 적합합니다. CLI 로그를 계속 뒤지는 대신 보드와 라이브 피드로 관리할 수 있습니다. (GitHub)

2) 소규모 제품팀이 agent ops를 운영할 때

예를 들어 “리서치 에이전트”, “구현 에이전트”, “QA 에이전트” 같은 역할을 나눠 쓰는 팀이라면 task-to-delivery 흐름을 운영 콘솔로 볼 수 있습니다. 자동 agent 생성과 상태 추적이 이런 팀 모델과 잘 맞습니다. (GitHub)

3) 원격 머신에 에이전트를 띄워놓고 관제하고 싶을 때

Gateway를 별도 머신에 두고 UI는 로컬에서 접속하는 식의 구조가 공식 지원됩니다. Tailscale 예시까지 있는 걸 보면 이 사용 사례를 꽤 진지하게 상정하고 있습니다. (GitHub)

---

반대로 아쉬운 점도 있다

좋은 프로젝트이지만 한계도 분명합니다.

OpenClaw 의존성이 강하다

이 프로젝트의 가치는 OpenClaw Gateway와의 결합에서 나옵니다.
즉, 범용 LangGraph/LangChain/AutoGen 관제판은 아닙니다. 이미 다른 에이전트 런타임을 쓰고 있다면 바로 가져다 쓰기는 어렵습니다. README도 OpenClaw를 별도 prerequisite로 요구합니다. (GitHub)

SQLite 기반이라 대규모 협업 SaaS보다는 로컬/소규모 팀에 더 맞다

SQLite는 배포와 운영이 쉬운 대신, 대형 멀티 유저 시스템의 중심 DB로 쓰기엔 한계가 있습니다. 물론 self-hosted 소규모 팀에는 오히려 장점일 수 있습니다. README와 Docker 섹션의 톤도 명확히 그 쪽입니다. (GitHub)

아직 생태계 중심 툴이라 범용 표준은 아니다

이 프로젝트는 빠르게 발전 중이고, 릴리스도 2026년 2월 이후 계속 이어지고 있습니다. 그만큼 활발하지만, 반대로 말하면 아직 “완전히 굳어진 표준 운영 모델”이라기보다는 빠르게 다듬어지는 단계로 보는 것이 맞습니다. (GitHub)

---

설치와 실행은 어떤 느낌인가

빠르게 띄우는 흐름은 꽤 단순합니다.
필수 조건은 Node.js 18+, OpenClaw Gateway, AI API Key입니다. 대시보드는 npm run dev, Gateway는 별도 터미널에서 openclaw gateway start로 실행합니다. 포트 기본값은 Mission Control 4000, Gateway 18789입니다. (GitHub)

블로그 독자를 위해 정리하면 다음 같은 그림입니다.

# 1) OpenClaw Gateway 실행
openclaw gateway start

# 2) Mission Control 실행
npm install
cp .env.example .env.local
npm run dev

그리고 .env.local에는 최소한 이런 값이 핵심입니다.

DATABASE_PATH=./mission-control.db
OPENCLAW_GATEWAY_URL=ws://127.0.0.1:18789
OPENCLAW_GATEWAY_TOKEN=
PLANNING_TIMEOUT_MS=30000
PLANNING_POLL_INTERVAL_MS=2000

이걸 보면 시스템이 본질적으로 “웹앱 + WebSocket bridge + 로컬 DB” 구성이라는 걸 바로 이해할 수 있습니다. (GitHub)

---

이 프로젝트를 한 문장으로 요약하면

Mission Control은 AI 에이전트를 실행하는 도구라기보다, 에이전트 조직을 운영하는 도구입니다.
작업 보드, AI 기반 요구사항 정제, 에이전트 생성과 할당, 실시간 피드, 결과물 추적을 하나로 묶어 OpenClaw 위에 올린 관제층이라고 보면 가장 정확합니다. (GitHub)

---

개발자는 언제 써보면 좋을까

에이전트를 아직 “재밌는 실험” 수준으로만 쓰고 있다면 이 프로젝트가 과할 수 있습니다.
하지만 아래 단계에 들어갔다면 가치가 분명합니다.

• 하나 이상의 에이전트를 동시에 운영한다
• 작업 상태와 결과물을 추적해야 한다
• 사람의 요청을 실행 가능한 spec으로 정제하는 단계가 필요하다
• CLI만으로는 현재 상황 파악이 너무 어렵다
• self-hosted agent ops 대시보드가 필요하다

그럴 때 Mission Control은 꽤 설득력 있는 선택지입니다.
특히 OpenClaw를 이미 쓰고 있다면, 이 프로젝트는 “있으면 좋은 UI”가 아니라 운영 난이도를 낮추는 핵심 레이어가 될 수 있습니다. (GitHub)