Litmers OS의 세 레이어

리트머스는 조직을 기능(Function)이나 직무(Role)로 설계하지 않습니다.
우리는 조직을 판단과 실행의 흐름으로 설계합니다.

전통적인 조직은 다음과 같이 질문합니다.
누가 무엇을 하는가?
이 질문은 역할을 나누는 데는 유용했지만, AI 시대의 조직을 설계하기에는 충분하지 않았습니다.

AI가 등장하면서 중요한 질문은 다음과 같이 바뀌었습니다.
이 판단은 누가 내려야 하는가?
이 실행은 사람이 해야 하는가, 시스템이 해야 하는가?
리트머스는 이 질문에서 출발했습니다.

우리는 “누가 판단하고, 누가 실행하는가”를 기준으로 조직의 역할과 시스템을 다시 나눴습니다.

  • 새로운 판단은 맥락과 책임이 필요한 영역입니다.
  • 이는 여전히 사람의 역할입니다.
  • 실행은 반복되고, 검증 가능하며, 자동화될 수 있는 영역입니다.
  • 이는 시스템이 더 잘 수행합니다.

문제는, 기존 조직 구조에서는 이 두 가지가 분리되지 않은 채 뒤섞여 있었다는 점입니다.
사람은 판단해야 할 시간에 실행에 묶였고, 시스템은 실행만 도와줄 뿐 반복되는 판단 구조를 학습하지 못했습니다.

Litmers OS는 이 구조를 바꾸기 위해 설계되었습니다.

우리는 사람에게서 불필요한 실행을 제거하고, 시스템에게는 반복 가능한 실행을 위임합니다.
그리고 사람은 다시 새로운 사고와 판단에 집중할 수 있도록 만듭니다.

이를 위해 리트머스는 조직의 모든 업무를 세 개의 레이어로 나눴습니다.

  • Workbench — 개인의 사고가 실험되고 자동화되는 공간
  • Nexus — 조직의 판단이 축적되고 재사용되는 구조
  • Foundry — 검증된 실행이 시스템으로 작동하는 생산 레이어

이 세 레이어는 역할을 나누기 위한 구분이 아닙니다. 판단과 실행이 흐르는 경로를 명확히 하기 위한 구조입니다.

Litmers OS는 아직 완성된 시스템이 아닙니다.
그러나 우리는 이 구조 위에서 실제 프로젝트를 수행하고, 실패하고, 수정하며, 점점 더 정교한 형태로 진화시키고 있습니다.

이것이 리트머스가 일하는 방식입니다.


1. Workbench — 개인의 사고를 자동화하는 레이어

Workbench는 개인이 사고는 유지한 채, 실행을 자동화하는 레이어입니다.

리트머스에서의 자동화는 일을 대신하게 만드는 것이 아니라, 
사람이 하던 사고 과정을 구조화해 시스템이 반복 실행할 수 있게 만드는 것을 의미합니다.
이를 위해 리트머스에서는 모든 직원이 Cursor를 기본 업무 환경으로 사용합니다. 개발자뿐 아니라 기획자, 디자이너, PM, 세일즈까지
동일합니다. AI는 특정 직무의 보조 도구가 아니라, 전사 공통의 업무 실행 레이어이기 때문입니다.

각 구성원은 자신의 업무 폴더에 요구사항, 산출물, 히스토리, 참고 자료를 지속적으로 축적합니다. Cursor는 이 문서들을 단순히 읽는 것이 아니라, 개인의 업무 맥락(Context)으로 이해합니다.
그 위에서 구성원은 자신의 업무 일부를 자동화하기 위해 Command라는 실행 단위를 직접 설계하고 실행합니다.

Command는 단순한 매크로나 프롬프트가 아닙니다. 업무를 수행할 때 사람이 실제로 거치는 사고 순서, 판단 기준, 제약 조건을 명시적으로 드러낸 실행 단위입니다.

예를 들어, 각 직무에서는 다음과 같은 Command를 사용할 수 있습니다.

Sales의 Command
회의록 마크다운 파일을 읽고 핵심 논의 내용과 결정 사항을 요약한 뒤 Notion CRM DB에 저장하고 후속 액션을 ClickUp 하위 태스크로 생성

PM의 Command
미팅 내용과 관련 문서를 함께 읽고 요구사항을 구조화한 문서를 생성한 뒤 개발 범위와 일정이 포함된 실행 계획 도출

디자이너의 Command
현재 컴포넌트의 사용성 이슈를 분석하고 우리 서비스와 유사한 B2B SaaS 레퍼런스를 참고해 디자인 시스템을 유지한 개선 시안 생성

개발자의 Command
새로운 API 스펙 문서를 읽고 기존 코드베이스와 비교해 변경이 필요한 파일과 영향 범위 목록 생성

이러한 Command는 일회성 실행을 위한 것이 아닙니다.
각자는 자신이 만든 Command를 실제 업무에서 반복적으로 사용합니다.

결과를 확인하고, 어디서 기대와 달라졌는지 점검하고, 판단 기준을 수정하며 점점 더 정교하게 만듭니다.
성과가 좋은 Command는 개인의 노하우로 남지 않습니다. 팀원들과 공유되고, 비교되고, 개선됩니다. 이 과정에서 개인의 업무 방식은 점점 재사용 가능한 형태로 정제됩니다.

Workbench의 핵심은 다음과 같습니다.

  • 사람은 무엇을 할지, 그리고 왜 할지를 정의합니다
  • 어떻게 실행할지는 AI OS가 담당합니다
  • 그 결과, 업무 방식 자체가 조직의 자산으로 남습니다

Workbench는 개인을 더 빠르게 만드는 도구가 아닙니다.
개인의 사고 방식을 조직이 학습할 수 있게 만드는 구조입니다.

이 레이어에서 충분히 검증된 자동화는 다음 단계에서 조직 단위의 시스템으로 확장됩니다.



2. Nexus — 조직의 판단을 대신하는 AI 레이어

Workbench에서 개인의 업무가 자동화되기 시작하면, 반드시 판단이 필요한 지점이 등장합니다.

  • 이 상황에서는 어떤 기술 스택을 선택해야 하는가
  • 관리자 권한과 책임은 어떻게 나누는 것이 적절한가
  • 지금 내릴 판단이 일정·비용·품질에 어떤 영향을 주는가

기존 조직에서는 이러한 판단을 매니저나 C-level이 직접 내려왔습니다.

그러나 이 방식은 두 가지 한계를 가집니다.

  1. 판단은 사람에게 강하게 의존되고
  2. 동일한 판단이 조직 내에서 계속 반복됩니다

리트머스는 이 구조를 그대로 자동화하지 않습니다. 판단 자체를 AI 시스템으로 이전합니다.
Nexus는 조직이 실제로 내려야 할 최종 판단을 수행하는 AI 레이어입니다.

Nexus의 역할

Nexus는 단순한 의사결정 보조 도구가 아닙니다.

  • Nexus는 판단을 정리만 하지 않습니다
  • Nexus는 초안만 제시하지 않습니다

Nexus는 조직의 판단을 대신 실행합니다.

이를 위해 Nexus는
판단이 필요한 순간을 인식하고,
판단에 필요한 맥락을 구성하며,
조직의 기준에 맞는 결론을 스스로 도출합니다.

이 모든 과정은 세 가지 핵심 기능을 중심으로 작동합니다.

핵심 기능 1. Decision Context Builder

Decision Context Builder는 Workbench 또는 외부 시스템에서 전달된 작업 요청을 기준으로 해당 상황에서 판단에 필요한 최소한의 맥락 정보를 자동으로 구성합니다.
사람은 더 이상 문서, 히스토리, 과거 사례를 직접 찾아볼 필요가 없습니다. Nexus가 판단에 필요한 컨텍스트를 하나의 구조로 정리합니다.

구체적인 작동 방식은 다음과 같습니다.

  1. 사용자가 Workbench, Teams 등에서 작업을 진행하거나 요청을 남깁니다
  2. Nexus는 해당 요청이 판단이 필요한 상황인지 자동 분류합니다
  3. 판단이 필요하다고 판단되면 Nexus는:
    • 관련 문서와 요구사항 요약
    • 현재 작업 단계 및 변경 이력
    • 유사한 과거 처리 사례
    • 현재 프로젝트의 제약 조건을 자동으로 수집합니다

이 정보가 하나의 Decision Context로 정리해 다음 단계로 전달되어, 판단을 위한 컨텍스트의 품질이 일관되게 유지됩니다.

핵심 기능 2. Executive Decision Agent

Executive Decision Agent는 Decision Context를 입력으로 받아,
조직의 기준에 맞는 최종 판단을 생성하는 역할을 수행합니다.
이 에이전트는 분석 보고서나 참고 의견을 만드는 데 목적이 있지 않습니다.
실무에서 바로 실행될 수 있는 판단과 지시를 생성하는 데 집중합니다.
사람이 매번 상황을 해석하고, 리스크를 정리하고, 선택지를 비교하는 과정을 반복하지 않도록 하기 위함입니다.

구체적인 작동 방식은 다음과 같습니다.

  1. Decision Context가 생성되면 Nexus는 상황 유형에 맞는 Decision Agent를 선택합니다
  2. Decision Agent는:
    • 현재 상황의 핵심 쟁점을 해석하고
    • 조직 기준에 영향을 미치는 주요 리스크를 식별하며
    • 가능한 선택지와 그에 따른 영향을 비교합니다
  4. 비교 결과를 바탕으로:
    • 가장 적합한 판단을 선택하고
    • 바로 실행 가능한 형태의 판단 결과를 생성합니다

이 결과는 제안이나 초안이 아니라,
조직의 기준에 따라 내려진 최종 판단으로 다음 단계로 전달됩니다.

핵심 기능 3. Decision Memory

Decision Memory는 Nexus가 수행한 판단과 그 결과를 저장하는
조직의 판단 기억 시스템입니다.
Nexus는 한 번의 판단으로 끝나지 않습니다.
내린 판단이 어떤 결과로 이어졌는지를 함께 기록함으로써, 시간이 지날수록 더 조직에 가까운 판단을 내릴 수 있도록 학습합니다.

구체적인 작동 방식은 다음과 같습니다.

  1. Executive Decision Agent가 생성한 판단이 실제 업무에 적용됩니다
  2. Nexus는:
    • 해당 판단이 내려진 상황 유형
    • 사용된 Decision Context
    • 최종적으로 선택된 판단
    • 그에 따른 처리 결과를 함께 저장합니다
  4. 이후 유사한 상황이 발생하면 Nexus는:
    • 과거 Decision Memory를 참조해
    • 조직에서 반복적으로 선택된 판단 패턴을 반영한
    • 더 일관된 판단을 생성합니다

이 과정을 통해 Nexus의 판단은 특정 개인의 경험에 의존하지 않고, 조직 전체의 경험을 반영하는 형태로 고도화됩니다.

Nexus는 다음과 같은 변화를 만듭니다.

  • 판단은 더 이상 특정 개인에게 집중되지 않습니다
  • 판단의 일관성과 속도는 시스템 수준에서 보장됩니다
  • 조직은 경험을 잃지 않고, 축적합니다

Nexus는 조직의 판단을 자동화하는 시스템이며, Litmers OS에서 가장 높은 책임을 갖는 레이어입니다.



3. Foundry — 검증된 실행을 생산하는 시스템

Workbench에서 개인의 업무가 자동화되고, Nexus를 통해 조직의 판단이 축적되면,
이제 이 모든 것을 실제로 작동하는 전사 시스템으로 만들어야 합니다.

Foundry는 Workbench에서 검증된 자동화와 Nexus에서 내려진 판단을 결합해, 조직 단위로 반복 실행 가능한 시스템을 생산하는 레이어입니다.

Foundry는 실험 공간이 아닙니다. 여기서 실행되는 프로세스는 이미 충분히 검증된 것만 사용됩니다.

  • 개인의 실험은 Workbench에서 이루어지고
  • 판단은 Nexus에서 내려지며
  • 실행은 Foundry에서만 일어납니다

즉, Foundry는 조직이 신뢰할 수 있는 실행만을 담당하는 어플리케이션 레이어입니다.

외주 개발 자동화에서 시작한 이유

리트머스는 외주 개발사입니다.
조직의 핵심 업무는 클라이언트 프로젝트를 일정·품질·비용을 지키며 완수하는 것입니다.
그래서 Foundry의 첫 번째 적용 대상은 명확했습니다.
외주 개발 프로세스 자체를 자동화한다.
이는 단순히 속도를 높이기 위함이 아니라, 외주 개발에서 반복적으로 발생하는 일정·품질·인력 의존 리스크를 구조적으로 제거하기 위한 선택이었습니다.

프론트엔드 개발 자동화 시스템 예시
Foundry에 구현된 자동화 시스템은 개별 인력의 역량에 의존하지 않습니다.
각 직무에서 검증된 Command들이 하나의 실행 파이프라인으로 통합됩니다.

  • PM의 요구사항 분석 및 User Story 도출
  • 디자이너의 컴포넌트·레이아웃 설계
  • 개발자의 Logical Architecture 설계

이 파이프라인이 Foundry에 구현되면, PM은 요구사항만 입력합니다.

시스템은 다음 과정을 자동으로 수행합니다.

  • Requirements → User Story → IA 설계
  • Logical Architecture 및 구조 설계
  • 파일 구조 및 라우팅 설계
  • 기능 단위 개발과 검증을 반복
  • 판단이 필요한 지점에서 Nexus 호출

사람은 각 단계를 직접 실행하지 않습니다.
시스템이 실행하고, 사람은 진행 상황과 결과를 확인합니다.

Foundry는 계속 진화한다

Foundry에 구현된 시스템은 한 번 만들고 끝나는 자동화가 아닙니다.

  • 실제 프로젝트에서 반복 사용되고
  • 개선 지점이 발견되면 Workbench에서 다시 고도화되며
  • 검증된 개선만이 Foundry로 반영됩니다

이 순환을 통해 Foundry는 시간이 지날수록 더 안정적이고 일관된 실행을 제공합니다.
그 결과, 조직은 프로젝트마다 새로 만드는 방식에서 벗어나 모듈과 에이전트를 조합하는 생산 구조로 전환됩니다.

Foundry는 외주 개발에만 한정되지 않는다

Foundry의 본질은 검증된 실행을 반복 가능한 시스템으로 만드는 것입니다.
이 구조는 다음 영역에도 그대로 확장될 수 있습니다.

  • 내부 제품 개발
  • 신규 서비스 실험 및 MVP 생산
  • 운영·백오피스 자동화
  • 마케팅·세일즈·CS와 같은 반복 실행 업무

Foundry는 특정 업무를 위한 솔루션이 아니라, 조직이 실행을 생산하는 방식 그 자체입니다.




Nexus 레이어 다이어그램