Decision OS는 “논의된 내용”을 “조직이 실행하고 추적할 수 있는 상태”로 바꾸는 운영 시스템이다. 회의록은 사실을 보존하고, Decision Ledger는 결정 상태를 관리하며, Action Items는 실행 상태를 추적한다. AI는 정리와 조정을 돕지만, 최종 판단과 편집권은 항상 사람에게 있다.

Decision OS의 핵심 목적은 세 가지다.

Decision OS는 단순한 회의록 정리 도구가 아니다. 빠르게 논의하고 실행하는 조직이 “왜 이 결정을 했는지”, “무엇을 희생했는지”, “누가 무엇을 해야 하는지”, “이 결정이 아직 유효한지”를 잃지 않기 위한 운영 레이어다.

조직의 의사결정은 대부분 회의, 짧은 대화, 고객·사용자 피드백, 현장 이슈, 기술적 제약, 긴급한 일정 속에서 발생한다. 문제는 결정 자체보다 결정 이후의 손실에서 생긴다.

Decision OS는 이 손실을 줄이기 위해 만들어졌다. 핵심은 모든 회의 내용을 완벽하게 요약하는 것이 아니라, 조직 운영에 영향을 주는 결정과 실행 항목을 안정적으로 상태화하는 것이다.

회의록은 누가 무엇을 말했는지에 대한 사실 기록이다. 반면 Decision Ledger는 조직이 현재 어떤 입장을 취하고 있는지에 대한 상태 기록이다.

Decision OS에서 AI는 최종 의사결정자가 아니라 조정자다. AI는 회의록이나 문서를 읽고 결정·액션 후보를 추출하고, 기대효과와 비용 관점으로 구조화하며, 충돌과 누락을 표시한다.

하지만 사람이 편집한 필드가 항상 우선한다.

Decision OS는 결정을 “해야 할 일”이 아니라 핵심 가치 간의 이동으로 본다. 좋은 결정은 어떤 가치를 올리는 동시에, 어떤 비용이나 위험을 발생시키는지 명확히 설명할 수 있어야 한다.

조직마다 Core Values는 다를 수 있다. 범용적으로는 다음과 같은 축을 사용할 수 있다.

조직에서는 “나중에 하자”, “일단 수동으로 하자”, “스코프를 줄이자”, “이번에는 예외 처리하자” 같은 말이 자주 나온다. 이런 표현은 대부분 기회비용을 동반한다. Decision OS는 이를 단순한 참고사항이 아니라 비용·위험으로 기록한다.

순수하게 좋은 결정은 드물다. 대부분의 실제 결정은 Tradeoff다. Decision OS는 이 Tradeoff를 숨기지 않고, 명시적으로 운영 대상으로 만든다.

Decision OS는 다섯 개의 핵심 레이어와 하나의 운영 대시보드로 구성된다.

원본 기록은 Decision OS의 사실 레이어다. 여기에는 회의명, 날짜, 참석자, 요약, 관련 안건, 관련 결정, 관련 액션이 연결된다.

중요한 운영 필드:

원본 기록에서 중요한 것은 “예쁘게 요약하는 것”보다 나중에 상태 변경의 근거로 쓸 수 있는 출처를 보존하는 것이다.

Agenda는 회의 전 입력 레이어다. 모든 논의가 결정이 되는 것은 아니므로, 안건은 회의에 올릴 후보를 정리하고 우선순위를 잡는 역할을 한다.

주요 필드:

Decision Ledger는 조직의 결정 상태를 저장한다. 여기서 “상태”라는 말이 중요하다. 결정은 문서가 아니라 살아있는 레코드다.

핵심 필드:

Action Items는 결정을 실행 가능한 작업으로 바꾼다.

핵심 필드:

Decision OS의 원칙상, X 하기로, X로 간다, X 도입, X는 별도 진행 같은 결정은 대부분 Action을 동반한다. 실행자가 명시되거나 추론 가능하면 Action이 생성되고, 실행자가 불명확하면 Owner를 비워둔 채 리뷰 대상으로 둔다.

Core Values는 결정과 액션을 평가하는 기준 테이블이다. Decision OS의 점수는 추상적인 우선순위가 아니라 이 가치들과의 관계로 산정된다.

각 Core Value는 다음을 가진다.

모든 Decision과 Action은 두 방향의 영향을 가진다.

조직에 따라 Positive / Negative 대신 Boost / Drag, Upside / Downside, Gain / Cost 같은 용어를 사용할 수 있다. 중요한 것은 용어가 아니라 효과와 비용을 분리해서 기록하는 구조다.

Direction은 사람이 직접 쓰지 않는다. Positive Values와 Negative Values의 존재 여부로 자동 계산한다.

Decision OS는 단순히 “중요하다”라고 쓰지 않는다. 중요도를 세 축으로 나눈다.

Magnitude는 영향의 크기와 되돌리기 어려움을 곱해서 계산한다.

해석:

Negative는 명시적으로 “단점”이라고 말하지 않아도 잡아야 한다.

특히 다음 표현은 Tradeoff의 단서다.

Review Status는 AI와 사람 사이의 검토 상태다.

AI Reconciliation은 원본 기록을 입력으로 받아 다음 작업을 수행한다.

AI는 다음을 해서는 안 된다.

새 정보가 기존 Decision과 충돌하면 데이터를 바로 바꾸지 않는다.

회의 전에는 안건을 정리한다.

목표는 회의에서 “무엇을 결정해야 하는지”를 분명히 하는 것이다.

회의 중에는 결론과 근거를 분명히 남긴다.

원본 기록은 완벽한 문장보다 원본성·추적성이 중요하다.

회의 후에는 Reconciliation 과정을 통해 원본 기록을 처리한다.

정기 운영 리뷰에서는 다음을 본다.

결정이 바뀌면 기존 레코드를 조용히 수정하지 않는다.

제목은 깨끗해야 한다.

좋은 제목:

나쁜 제목:

Decision Statement는 다음 질문에 답해야 한다.

예시:

Rationale은 단순 배경 설명이 아니라, 기대효과와 비용을 함께 설명해야 한다.

좋은 Rationale:

Action은 Done Criteria 없이는 완료 판정이 흐려진다.

좋은 Done Criteria:

운영 대시보드는 “많은 데이터를 보는 곳”이 아니라 “지금 봐야 할 상태를 드러내는 곳”이어야 한다.

현재 유효한 결정만 본다.

사람 또는 AI의 재검토가 필요한 항목만 본다.

실행 중인 작업만 본다.

어떤 Core Value에 작업과 결정이 몰려 있는지 본다.

고위험 결정은 다음 조건에서 발생한다.

이 경우 Decision Statement 또는 Action Statement 첫머리에 [고위험] 접두를 붙인다.

필수 확인:

Decision OS가 잘 작동한다는 것은 문서가 많아지는 것이 아니다. 다음이 가능해지는 것이다.

Decision OS의 한 문장 원칙: 논의에서 나온 결정은 반드시 원본 기록에 연결되고, Core Value의 기대효과와 비용으로 설명되며, 실행 가능한 Action 또는 명시적인 보류 상태로 끝나야 한다.

Decision OS는 현재 원본 기록 → 결정 → 액션의 운영 루프를 중심으로 설계되어 있다. 이후에는 다음 방향으로 확장할 수 있다.

Decision OS의 최종 목표는 결정을 더 많이 기록하는 것이 아니라, 더 빠르게 배우면서도 더 적게 잃는 조직 운영 체계를 만드는 것이다.