1. 왜 사람의 인사이트가 중요한가

AI 전환을 통한 업무 자동화의 퀄리티는 시스템의 완성도보다, 사람이 가진 인사이트에 의해 결정됩니다.
업무 자동화란 사람이 하던 일을 그대로 넘기는 것이 아닙니다.
사람이 수행하던 추상적인 사고 과정을 워크플로우로 분해해,AI가 따를 수 있는 지침으로 만드는 일입니다.

이때 핵심은 단순한 작업 순서가 아닙니다. 사람이 실제로 업무를 수행하며 사용해 온 판단 기준과 맥락입니다.

같은 업무를 AI에게 맡겨도 결과가 달라지는 이유는 여기에 있습니다.

• 어떤 순서로 행동하도록 지시하는가
• 어떤 정보를 참고하게 하는가
• 무엇을 제약 조건으로 두는가

이 차이가 결과물의 퀄리티를 완전히 바꿉니다.

예를 들어, 디자이너의 “컴포넌트 개선” 업무를 보겠습니다.

추상적 프로세스 (사람이 실제로 하는 것)
현재 컴포넌트 문제 파악더 나은 방법 탐색개선안 도출

이 상태로 AI에게 맡기면, 결과는 평범해질 수밖에 없습니다.
AI는 무엇이 문제인지, 무엇이 더 나은지, 우리 기준이 무엇인지 알지 못하기 때문입니다.

반면, 디자이너의 실제 판단 기준을 포함하면 상황은 달라집니다.

구체적 워크플로우 (판단 기준 포함)

1. 현재 컴포넌트의 사용성 이슈 분석
2. • 기준: 클릭 영역 44px 이상, 색상 대비 4.5:1 이상, 모바일 대응
2. 적절한 레퍼런스 찾기
3. • 맥락: B2B SaaS 중심, 우리와 비슷한 복잡도의 서비스
   • 판단: Figma, Notion, Linear 같은 툴 우선 참고
3. 개선된 디자인 시안 생성
4. • 제약: 기존 디자인 시스템 컬러/타이포 유지
   • 우선순위: 접근성 > 심미성

같은 “컴포넌트 개선”이지만, 후자는 디자이너가 실제로 어떻게 판단하는지가 명시되어 있습니다.
AI는 이 기준과 맥락을 전달받았을 때에만, 비로소 디자이너처럼 행동할 수 있습니다.

Claude가 Skills를 출시한 이유도 여기에 있습니다. AI는 스스로 전문가가 되지 않습니다.
전문가가 어떤 기준으로 판단하는지를 전달받을 때만, 전문가처럼 작동합니다.

2. 인사이트는 공유될 때 시스템이 된다

리트머스는 이 원칙을 개인 차원이 아니라, 조직 전체의 구조로 확장합니다.

우리는 먼저 각 개인이 자신의 업무를 자동화하도록 합니다. 업무를 수행하며 어떤 기준으로 판단했는지,
어디에서 결과의 차이가 발생했는지를 명시합니다.
이 인사이트는 개인에게 머무르지 않습니다.

• 공유되고
• 비교되고
• 논의되며
• 반복적으로 검증됩니다

그리고 일정 수준 이상의 일관성과 성과가 확인되면, 그 방식은 조직의 표준 워크플로우로 승격됩니다.
즉 리트머스의 시스템은 이렇게 만들어집니다.

• 누군가가 설계한 전사 시스템을 먼저 배포하지 않습니다
• 개인의 자동화 실험이 축적되고
• 검증된 판단 방식만이 살아남아
• 조직의 시스템으로 확장됩니다

전사 시스템은 출발점이 아닙니다. 개인의 인사이트가 충분히 검증된 뒤에 만들어지는 결과물입니다.

이것이 리트머스가 선택한 AI 전환의 방식이며, 개인의 인사이트가 조직의 시스템이 되는 구조입니다.

2025년 9월, Lovable과 v0를 비롯한 AI 툴의 성능이 급격히 성장하며 리트머스는
효율화를 통한 가격 경쟁력 확보를 목표로 전사 AI 자동화를 추진했습니다.
초기 접근은 전통적인 방식으로, C-level에서 표준 시스템과 방법을 설계하고, 이를 전 직원에게 전파하는 방식을 취했었습니다.

그러나 전파가 끝나기도 전에 여러 가지 문제가 드러났습니다.

1. AI의 발전 속도가 너무 빨랐습니다.
2. 합의한 방식이 금세 비효율적인 방법이 되었습니다.
3. 실무자들의 실험 속도를 따라갈 수 없었습니다.
4. 현장에서 더 나은 활용법이 빠르게 발견되고 공유되었지만,
5. 탑다운으로 설계된 시스템은 이 변화를 흡수하지 못했습니다.

이때 우리는 AI 도입은 ERP처럼 정답을 정해 배포하는 방식으로는 작동하지 않는다는 것을 깨달았습니다.

AI 전환은 Bottom-up이어야 합니다.

실무자가 직접 사용하며 얻은 인사이트가 공유될 때, 비로소 시너지가 만들어집니다.

리트머스는 조직을 기능(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는:
4. • 관련 문서와 요구사항 요약
   • 현재 작업 단계 및 변경 이력
   • 유사한 과거 처리 사례
   • 현재 프로젝트의 제약 조건을 자동으로 수집합니다

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

핵심 기능 2. Executive Decision Agent

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

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

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

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

핵심 기능 3. Decision Memory

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

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

1. Executive Decision Agent가 생성한 판단이 실제 업무에 적용됩니다
2. Nexus는:
3. • 해당 판단이 내려진 상황 유형
   • 사용된 Decision Context
   • 최종적으로 선택된 판단
   • 그에 따른 처리 결과를 함께 저장합니다
3. 이후 유사한 상황이 발생하면 Nexus는:
4. • 과거 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는 특정 업무를 위한 솔루션이 아니라, 조직이 실행을 생산하는 방식 그 자체입니다.

Litmers OS의 세 레이어는 각각 독립된 기능을 수행하지 않습니다.
이들은 단방향 구조가 아니라, 끊임없이 순환하는 시스템입니다.

개인의 실험은 조직의 시스템이 되고, 조직의 판단은 다시 개인의 실험을 고도화합니다.
이 순환 구조는 Litmers OS가 시간이 지날수록 더 정교해질 수 있도록 합니다.

Workbench → Foundry

개개인의 실험이 시스템이 되다.
Foundry에서 구현된 자동화 시스템은 완성된 정답으로 배포되지 않습니다. 우선, 검증된 실행 파이프라인의 형태로 각 구성원의 Workbench에 공유됩니다.

1. Foundry는 “프론트엔드 개발 자동화 시스템”과 같은 핵심 실행 파이프라인을 각 Workbench로 전달합니다
2. PM, 디자이너, 개발자는 자신의 실제 업무에서 이를 사용합니다
3. 사용 과정에서 “이 부분은 이렇게 바꾸면 더 효율적이다”, “이 판단 기준은 이 상황에 맞지 않는다”와 같은 개선 지점이 자연스럽게 드러납니다
4. 이러한 개선 사항은 개인의 노하우로 남지 않고, 팀 단위로 공유됩니다
5. 충분히 논의되고 검증된 개선만이 다시 Foundry에 반영됩니다
6. 이후 모든 프로젝트는 개선된 버전의 시스템 위에서 실행됩니다

이 과정을 통해 개인의 시도들은 점점 조직의 표준 실행 방식으로 정제됩니다.

Nexus → Foundry

조직의 판단이 시스템에 축적되다.
자동화된 실행이 반복되면, 반드시 판단이 필요한 순간이 발생합니다.
이때 Foundry는 사람에게 판단을 요청하지 않습니다.
Nexus를 호출합니다.

1. Nexus에는 C-level과 매니저가 실제로 내려온 판단이 지속적으로 축적됩니다
2. 회사의 다양한 시스템에서 발생하는 실행 결과와 맥락 데이터가 함께 기록됩니다
3. 이 데이터를 기반으로 AI CTO, AI CEO, AI PM-Lead와 같은 조직 역할별 판단 에이전트가 점점 고도화됩니다
4. Foundry에서 자동화 시스템이 실행되던 중 판단이 필요한 지점이 발생하면
5. 상황에 가장 적합한 AI Executive가 호출됩니다
6. Nexus는 해당 상황에 대한 판단을 내려 다시 Foundry로 전달합니다

이 흐름을 통해 조직의 판단 축적되고 정규화되며 실행 시스템 안으로 자연스럽게 내재화됩니다.

개인의 실험, 조직의 판단, 시스템의 실행은 각각 분리된 단계가 아니라 하나의 흐름입니다.
이 흐름이 반복될수록 Litmers OS는 스스로 고도화되는 운영체제가 됩니다.

우리는 이 구조를 설계하며 자연스럽게 르네상스를 떠올렸습니다.
르네상스의 본질은 예술의 부흥이 아니었습니다.
그 시대의 변화는, 인간의 역할이 분화되고 확장된 구조적 전환이었습니다.

AI 역시 같은 변화를 만들어내고 있습니다.
AI는 인간을 대체하지 않습니다. 대신, 인간이 수행해 온 역할을 분리하고 강화합니다.

Artist — 창의하는 인간

Artist는 질문을 만들고,
아직 정의되지 않은 가능성을 탐색합니다.

• 무엇이 문제인지 정의하고
• 어떤 방향이 의미 있는지 고민합니다

Workbench는 이 역할을 돕습니다.
반복 실행을 제거함으로써, 사람이 다시 사고와 탐색에 집중할 수 있는 시간을 돌려줍니다.

Thinker — 사고하는 인간

Thinker는 맥락을 연결하고, 상황에 맞는 판단을 내립니다.

• 여러 선택지의 영향을 비교하고
• 조직의 기준에 맞는 결정을 내립니다

Nexus는 이 역할을 시스템으로 확장합니다.
축적된 지식과 경험을 바탕으로, 조직 단위의 판단을 일관되게 수행합니다.

Builder — 구현하는 인간

Builder는 생각을 현실로 만듭니다.

• 설계를 실행으로 옮기고
• 결과물을 만들어냅니다

Foundry는 이 과정을 자동화합니다.
사람은 반복 구현에서 벗어나, 설계와 구조를 더 잘 만드는 데 집중할 수 있습니다.
AI는 인간의 세 가지 본질을 분리하고, 동시에 강화합니다.
Litmers OS는 이 역할들이 충돌하지 않고 서로를 증폭시키도록 설계된 구조입니다.