공개 사항 (Disclosure): Mora OS는 Codex Pro를 사용하여 제 개인 하드웨어에 구축한 개인 프로젝트입니다. 이 글은 AI의 도움을 받아 작성되었지만, 저라는 인간을 통해 여러 차례의 질문, 편집, 재작성 및 개선 과정을 거쳤습니다. 🙂

저는 미래가 커피숍 하나를 사이에 두고 조립되고 있다는 느낌을 피하기가 거의 불가능한 샌프란시스코 베이 지역 (San Francisco Bay Area)에 살고 있습니다.

지난 몇 년 동안, 그 미래는 주로 채팅창 (chat box)의 형태로 도착했습니다.

저는 채팅을 좋아합니다. 끊임없이 사용하죠. 하지만 AI를 제 삶에서 진정으로 유용하게 만들려고 노력하면 할수록, 그 핵심적인 결함이 더욱 분명해졌습니다.

채팅창이 저에게 오케스트레이션 (orchestration)을 하게 만들고 있다는 점이었습니다.

저는 무엇을 물어봐야 할지 기억해야 했습니다. 컨텍스트 (context)를 찾아내야 했습니다. 메시지, 날짜, 파일, 그리고 이전의 결정 사항들을 프롬프트 (prompt)에 붙여넣어야 했습니다. 답변을 가져와서 실제 작업이 이루어지는 곳으로 다시 옮겨야 했습니다. 그러고 나서 일주일 뒤, 저는 상황 전체를 다시 설명해야 했습니다.

그것은 어시스턴트 (assistant)가 아닙니다. 그것은 기억상실증에 걸린 아주 똑똑한 컨설턴트일 뿐이며, 저는 여전히 그 사람의 프로젝트 매니저 (project manager) 역할을 하고 있습니다.

그래서 저는 다른 무언가를 만들기 시작했습니다.

저는 그것을 Mora OS라고 불렀습니다. 제가 이미 사용 중인 시스템을 관찰하고, 지속적인 메모리 (durable memory)를 유지하며, 무엇이 내 주의를 끌 가치가 있는지 결정하고, 행동을 제안하며, 네이티브 Mac 및 iPhone 경험 전반에서 제가 그 행동들을 감독할 수 있게 해주는 프라이빗 (private), 로컬 우선 (local-first), 휴대 가능한 에이전틱 AI (Agentic AI) 운영체제입니다.

이것은 출시 발표나 승전보가 아닙니다. 시스템을 바닥부터 구축하고, 중요한 부분에서 실수를 저지르고, 업계가 병행하여 배우고 있는 것들을 연구하며, 운영체제 (operating-system)라는 은유가 마케팅 용어가 아니었다는 것을 점진적으로 발견해 나가는 과정에 대한 이야기입니다.

그것은 아키텍처 (architecture)였습니다.

채팅만으로는 충분하지 않게 된 순간

The same builder moving from manual chat orchestration to a layered personal operating system

저의 첫 번째 본능은 예측 가능했습니다. 에이전트 (agent)에 더 많은 도구를 연결하는 것이었습니다.

이메일 (Email). 캘린더 (Calendars). 메시지 (Messages). 파일 (Files). 메모리 저장소 (Memory store). 나중에는 건강 데이터 내보내기 (health exports)와 휴대폰 컴패니언 (phone companion)까지 추가했습니다. 모델이 모든 것에 접근할 수 있다면, 분명 유용해질 것이라고 생각했습니다.

실제로 모델의 능력은 향상되었습니다.

하지만 자동으로 더 신뢰할 수 있게 된 것은 아니었습니다.

연결이 늘어날수록 새로운 질문들이 생겨났습니다:

• 어떤 소스가 실제로 최신 상태인가?
• 나에게 온 메시지인가, 내가 보낸 메시지인가, 아니면 단순히 그룹 채팅에서 보이는 메시지인가?
• 내가 이미 처리한 문제인가?
• 특정 항목이 유용한 배경 지능 (background intelligence)인가, 아니면 개인적인 의무 사항인가?
• 모델이 보고 있는 것이 증거인가, 오래된 기억인가, 아니면 그 둘이 확신에 차서 섞인 결과물인가?
• 시스템이 어떤 행동을 제안했다면, 누가 이를 승인했는가?
• 내가 무언가를 거절했다면, 모델이 이를 학습할 것인가, 아니면 내일 그냥 다시 보여줄 것인가?
• 커넥터 (connector)가 조용히 실패한다면, 시스템의 나머지 부분은 아무 일도 없었던 것처럼 행동할 것인가?

문제는 더 이상 "어떻게 하면 더 나은 프롬프트 (prompt)를 만들 수 있을까?"가 아니었습니다.

문제는 "모델이 내 삶에 안전하게 참여할 수 있도록 모델 주변에 어떤 서비스들이 존재해야 하는가?"였습니다.

그 질문이 어시스턴트를 운영체제 (OS)로 바꾸어 놓았습니다.

실패로부터 드러난 아키텍처 (architecture)

A hand-drawn cutaway of the Mora OS layers, from local connectors to memory, governance, cockpit, and Doctor

저는 화이트보드에 전체 시스템을 올바르게 설계한 다음 구현한 것이 아닙니다. 아키텍처는 각각의 지름길(shortcut)들이 서로 다른 방식으로 실패하면서 자연스럽게 드러난 결과였습니다.

현재의 설계는 여섯 가지 책임을 가집니다.

1. 현실을 최신인 것처럼 가장하지 않고 감지하기

Mora OS는 유형화된 명령줄 인터페이스 (command-line interfaces)를 강력하게 선호하며, 좁은 범위의 어댑터 (adapters)를 통해 로컬 및 연결된 소스로부터 데이터를 수집합니다.

모든 관찰 데이터에는 출처 (provenance)가 필요합니다:

• 어디에서 왔는가;
• 소스가 데이터를 생성한 시점은 언제인가;
• 시스템이 이를 관찰한 시점은 언제인가;
• 어떤 최신성 예산 (freshness budget)이 적용되는가;
• 데이터 가져오기 (pull)가 완료되었는가, 부분적인가, 형식이 잘못되었는가, 권한이 없는가, 아니면 사용할 수 없는 상태인가.

“연결됨 (Connected)”이 “동기화됨 (synced)”과 같은 것은 아닙니다.

“인증됨 (Authenticated)”이 “최신임 (fresh)”과 같은 것도 아닙니다.

“결과 없음 (No results)”이 “아무 일도 일어나지 않음 (nothing happened)”과 같은 것도 아닙니다.

아름다운 대시보드가 오래된 데이터를 자신 있게 요약해서 보여주기 전까지는 이 말이 당연하게 들립니다.

Mora OS에서 가장 중요한 설계 결정 중 하나는 따라서 화려하지 않습니다: 불확실성 (uncertainty)은 일급 상태 (first-class state)이다. 시스템은 자신이 모른다고 말할 수 있어야 합니다.

2. 모델 외부에 휴대 가능한 두뇌를 유지하라

메모리 시스템인 Mora는 로컬에 존재하며, 특정 모델이나 에이전트 런타임 (agent runtime)과 독립적으로 휴대할 수 있습니다.

이는 처음 생각하는 것보다 훨씬 더 중요합니다.

모델은 변합니다. 컨텍스트 윈도우 (Context windows)도 변합니다. 에이전트 프레임워크 (Agent frameworks)도 변합니다. 가격 정책도 변합니다. 개인의 역사는 추론 엔진 (reasoning engine)이 교체될 때마다 사라져서는 안 됩니다.

연구 커뮤니티는 여러 방향에서 유사한 아이디어로 수렴하고 있습니다. MemGPT는 긴 컨텍스트 관리 (long-context management)를 운영체제의 가상 메모리 (virtual memory)처럼 구성했습니다. Generative Agents 연구는 관찰 (observation), 성찰 (reflection), 검색 (retrieval), 그리고 계획 (planning)을 결합했습니다. 더 최근에는 Anthropic이 컨텍스트 엔지니어링 (context engineering)에 관한 연구에서 컨텍스트를 의도적으로 큐레이션해야 하는 유한한 자원으로 설명했습니다.

저의 실용적인 버전은 양동이가 아니라 사서 (librarian)입니다.

The builder as a librarian compressing observations into durable memory and paging only relevant context

가공되지 않은 관찰 (Raw observations)이 모두 영구적인 진실로 승격되는 것은 아닙니다. 유용한 결과물은 출처 (provenance)를 가진 압축된 내구성 있는 메모리가 됩니다. 반복되는 내용은 압축됩니다. 오래된 자료는 검토될 수 있습니다. 검색 (Retrieval)은 아카이브 전체를 프롬프트 (prompt)에 쏟아붓는 대신 작업 범위에 맞춰 제한됩니다.

목표는 “모든 것을 영원히 기억하는 것”이 아닙니다.

목표는 다음과 같습니다:

유용한 것은 보존하고, 출처를 알 수 있게 하며, 관련이 있을 때 검색하고, 소유자가 이를 다른 곳으로 옮길 수 있게 하는 것입니다.

그렇게 함으로써 개인화 (personalization)는 특정 벤더의 채팅 기록 (chat history)에서 발생하는 부수 효과가 아닌, 소유 가능한 자산이 됩니다.

3. 지능 (intelligence)과 의무 (obligation)를 분리하기

가장 까다로운 버그 중 하나는 무해해 보였습니다.

Mora OS는 그룹 대화에서 활발한 논의 내용을 가져와 '일일 지능 (Daily Intelligence)'으로 요약할 수 있었습니다. 하지만 그 하류 (downstream) 단계에서, 동일한 콘텐츠가 제가 개인적으로 수행해야 할 작업으로 오인될 수 있었습니다.

그 경험을 통해 저는 두 개의 분리된 경로 (lanes)를 구축하는 법을 배웠습니다.

Two evidence rivers remain separate: background intelligence and verified personal action

**지능 경로 (intelligence lane)**는 다음과 같이 질문합니다:

• 이것이 새로운 정보인가?
• 유익한 정보인가?
• 검증된 관심사, 프로젝트, 또는 관계와 일치하는가?
• 오늘날의 주의력 예산 (attention budget) 내에서 제한된 슬롯을 차지할 가치가 있는가?

**개인적 행동 경로 (personal-action lane)**는 훨씬 더 높은 기준을 가집니다:

• 직접적인 요청이 있는가?
• 소유권이 검증되었는가?
• 책임이 나에게 있는가?
• 이미 처리되었는가?
• 제안된 다음 단계를 뒷받침하는 근거는 무엇인가?

배경 지능 (Background intelligence)은 브리핑을 풍성하게 만들 수는 있습니다. 하지만 그것이 조용히 작업 (task), 긴급 알림, 또는 외부 행동으로 변해서는 안 됩니다.

이 모델 전 단계의 게이트 (pre-model gate)는 시스템에서 가장 중대한 부분 중 하나가 되었습니다. 이는 추론 (reasoning) 비용을 지불하기 전에 노이즈를 줄여주고, 잘못된 의무가 발생하는 범주 전체를 방지하며, 무엇이 수용되고 무엇이 배제되었는지에 대한 감사 가능한 설명 (auditable explanation)을 생성합니다.

OpenAI의 에이전트에 대한 실용 가이드 (practical guide to agents) 또한 고위험 작업에 대해 계층화된 가드레일 (guardrails)과 인간의 개입을 유사하게 강조합니다. 에이전트의 신원 및 권한 부여 (agent identity and authorization)에 관한 NIST의 연구는 동일한 더 깊은 문제를 지적합니다: 에이전트에게는 지능 그 이상의 것이 필요합니다. 에이전트에게는 제한된 권한 (bounded authority), 신원 (identity), 감사 (auditing), 그리고 부인 방지 (non-repudiation)가 필요합니다.

4. 받은 편지함(inbox)을 주의력 계약(attention contract)으로 교체하기

정보원(sources)과 게이트(gates)가 구축된 후, 나는 또 다른 실수를 저질렀습니다: 너무 많은 것을 보여주었습니다.

조종석(cockpit)이 유용한 이유는 단순히 모든 것을 집계하기 때문이 아닙니다. 만약 다섯 개의 시끄러운 피드(feeds)를 하나의 거대한 피드로 만든다면, 그것은 단지 불안을 중앙 집중화했을 뿐입니다.

이제 Daily Intelligence에는 명시적인 주의력 예산 (attention budget)이 있습니다. 항목들은 제한된 수의 가시적인 슬롯(slots)을 차지하기 위해 경쟁합니다. 시스템은 무엇이 적격했는지, 무엇이 누락되었는지, 그리고 그 이유가 무엇인지를 기록합니다.

Agentic Tasks (에이전트적 작업)는 또 다릅니다. 이것들은 "흥미로운 제안"이 아닙니다. 대기열에 있는 작업은 다음을 필요로 합니다:

• 소유자 (owner);
• 증거 (evidence);
• 긴급 사유 (urgency reason);
• 다음 단계 (next step);
• 상태 (state);
• 대기열을 벗어나기 위한 조건 (condition for leaving the queue);
• 생명주기 및 중복 제거 영수증 (lifecycle and deduplication receipts).

그 차이는 미묘하지만 근본적입니다:

Daily Intelligence는 내가 이해하도록 돕습니다. Agentic Tasks는 나에게 결정하거나 행동할 것을 요구합니다.

두 가지 모두 더 깊고 증거에 기반한 대화를 위해 Ask Mora로 연결될 수 있습니다. 하지만 채팅은 이제 OS 내부의 보조적인 표면 (supporting surface)일 뿐이며, OS 그 자체는 아닙니다.

5. 행동을 초안 우선(draft-first) 및 승인 형태(approval-shaped)로 만들기

가장 쉬운 에이전트 데모는 가장 위험한 데모이기도 합니다: "메시지를 보내는 것을 지켜보세요."

Mora OS는 정반대의 가정에서 시작합니다.

읽기(Reads)는 권한 측면에서 비용이 저렴합니다. 초안(Drafts)은 되돌릴 수 있습니다. 외부 쓰기(External writes)는 중대한 결과를 초래합니다.

따라서 행동은 다음과 같은 명시적인 단계를 거칩니다:

1. 분석(analyze);
2. 계획 및 영향 예측(plan and preview impact);
3. 정책상 필요한 경우 승인 요청(request approval when policy requires it);
4. 멱등성(idempotently) 있게 실행;
5. 사후 상태 검증(verify the post-action state);
6. 감사 영수증(audit receipt) 추가.

시스템은 신뢰가 쌓임에 따라 작업 유형별로 더 자율적(autonomous)이 될 수 있지만, 자율성은 성격 설정(personality setting)이 아닙니다. 그것은 관찰된 신뢰성(reliability)에 기반한 정책 결정입니다.

이러한 구분은 중요합니다. 왜냐하면 에이전트 보안(agent security)은 시스템 프롬프트에 "주의하세요"라는 문구를 추가한다고 해서 해결되는 문제가 아니기 때문입니다. 에이전트 하이재킹 (agent hijacking)에 관한 NIST의 연구는 신뢰할 수 있는 지침(trusted instructions)과 신뢰할 수 없는 외부 데이터(untrusted external data)를 혼합하는 것의 위험성을 강조합니다. 개인용 OS에서 이메일, 메시지, 웹 페이지, 문서는 모두 잠재적으로 적대적인 입력(hostile inputs)입니다.

모델은 제안(propose)할 수 있습니다. 커널(kernel)은 그 제안이 무엇이 될 수 있는지를 결정합니다.

6. 프로세스만이 아니라 전체 여정을 진단하라

그 후 Mac 앱이 빈 화면으로 변했습니다.

백엔드(backend)는 실행 중이었습니다. 헬스 엔드포인트(health endpoint)는 성공을 반환했습니다. 애플리케이션 프로세스도 존재했습니다. 빌드(Builds)도 통과했습니다. 인프라(infrastructure) 관점에서는 모든 것이 정상적으로 보였습니다.

사용자 관점에서는 제품이 그냥 하얀 직사각형일 뿐이었습니다.

A blank native window leads to a visual end-to-end Doctor that verifies the experience, not merely the process

그 실패는 제가 발견한 프로덕션 품질(production quality)에 대한 가장 명확한 정의가 되었습니다:

시스템은 구성 요소들이 성공을 주장할 때 건강한 것이 아니라, 사용자의 핵심 여정(critical journey)이 작동할 때 건강한 것이다.