본문으로 건너뛰기

의사결정 로그

맥락, 근거, 결과가 포함된 주요 조직 의사결정 아카이브

개요​

Kyndof의 의사결정 로그는 전략적 전환, 아키텍처 약속, 정책 변경, 주요 투자 등 중대한 조직적 선택을 기록합니다. 실행에 초점을 맞춘 프로젝트 아카이브와 달리, 의사결정 로그는 선택의 이면에 있는 논리를 강조합니다: 어떤 옵션이 존재했는지, 왜 이 경로를 선택했는지, 무엇이 일어날 것으로 예상했는지, 실제로 무엇이 발생했는지.

조직은 결정 자체보다 그 논리를 더 빨리 잊습니다. 아키텍처를 선택한 지 6개월 후, 팀은 당시 최적이 되게 만든 제약 조건을 기억하지 못한 채 그 선택에 의문을 제기합니다. 의사결정 로그는 무엇이 결정되었는지뿐만 아니라 왜 그렇게 결정되었는지를 보존함으로써 이러한 조직적 기억상실을 방지합니다.

의사결정 로그는 여러 대상을 위해 봉사합니다: 전략적 패턴을 검토하는 리더십, 시스템 논리를 이해하는 팀, 조직적 사고를 학습하는 신규 멤버, 선례를 찾는 미래의 의사결정자. 잘 유지된 의사결정 로그는 여러 결정에 걸쳐 패턴이 나타남에 따라 시간이 지남에 따라 가치가 복리로 증가합니다.

의사결정 유형 및 범위​

모든 선택이 의사결정 로그에 속하는 것은 아닙니다. Kyndof는 지속적 영향, 상당한 자원, 또는 광범위한 조직적 범위를 가진 결정을 기록합니다:

전략적 결정​

시장, 제품, 비즈니스 모델, 또는 조직 방향에 대한 선택. 전략적 결정은 Kyndof가 수년에 걸쳐 무엇이 되는지를 형성합니다.

아키텍처 결정​

장기적 영향이 있는 기술적 선택: 기술 선정, 시스템 설계, 통합 접근방식, 플랫폼 약속. Kyndof는 Architecture Decision Records (ADR) 형식을 사용합니다.

정책 결정​

Kyndof가 운영되는 방식을 지배하는 규칙: 승인 워크플로우, 자원 배분 기준, 보안 요구사항, 프로세스 표준. 논리의 투명성이 수용과 준수를 높입니다.

투자 결정​

상당한 자원 약속: 주요 프로젝트, 기술 구매, 파트너십 계약, 채용 계획. 기대 수익을 문서화하면 이후 결정 품질의 검증이 가능합니다.

의사결정 기록 구조​

제목 및 메타데이터​

결정의 본질을 전달하는 설명적 제목. 결정 날짜, 의사결정자(RABSIC 역할), 상태, 다른 결정과의 관계 포함.

맥락 섹션​

왜 이 결정이 지금 중요한지. 해결되는 문제, 현재 상황, 작용하는 제약 조건, 결정 압력을 만드는 힘을 설명합니다.

결정 섹션​

실제로 이루어진 선택을 명확하고 모호하지 않게 기술합니다. 핵심 매개변수, 경계, 구현 원칙도 명시합니다.

결과 섹션​

긍정적, 부정적 모두를 포함한 예상 결과. 솔직한 결과 평가는 트레이드오프를 인정합니다.

검토된 대안​

다른 실행 가능한 옵션. 접근방식, 장단점, 선택되지 않은 이유를 문서화합니다.

검증 계획​

이 결정이 올바른 것으로 판명되었는지 어떻게 알 수 있는지. 성공 지표, 검토 날짜, 재고 기준 포함.

2026년 주요 결정​

ADR-001: Knowledge Graph 아키텍처​

날짜: 2026-02-01 Accountable: CTO 상태: 수용 및 구현 중

결정: World Model 엔티티 및 관계 관리를 위한 마크다운 기반 Knowledge Graph 아키텍처 채택.

맥락: 조직은 엔티티(사람, 회사, 프로젝트, 개념)와 그 관계를 포착하기 위한 지속 가능하고 확장 가능한 지식 관리가 필요했습니다.

선택된 접근방식: Git 내 마크다운 파일에 엔티티용 구조화된 템플릿, 타임라인 우선 구성, 양방향 링크 구문, 날짜 기반 아카이빙.

핵심 트레이드오프:

  • 사람이 읽기 쉬움, git 네이티브, 진입 장벽 낮음, 유연한 구조
  • 스키마 검증 없음, 수동 양방향성, 링크 취약성, 규율 필요

거부된 대안:

  • 구조화된 데이터베이스 (PostgreSQL/Neo4j) - 너무 무거움, 버전 관리 미흡
  • JSON/YAML 파일 - 사람이 읽기 어려움
  • 위키 시스템 (Notion/Obsidian) - 벤더 종속, git 네이티브 아님
  • RDF/Semantic Web - 사용 사례 대비 과도한 복잡성

검증 계획: 엔티티 수(목표: 6개월 내 100+), 출처 속성 비율(목표: 80%+), 깨진 링크 비율(목표: \\\\<5%).

교훈: 마크다운으로 단순하게 시작하는 것이 특화된 도구가 필요한 복잡한 시스템보다 더 지속 가능함이 입증됨.

의사결정 프로세스​

1. 문제 정의​

솔루션 고려 전 결정이 필요한 문제를 명확히 정의.

2. 대안 생성​

체계적으로 실행 가능한 옵션 생성. 평가 전 3-5개의 진지한 대안을 목표.

3. RABSIC 배정​

RABSIC-Engine 에이전트를 사용하여 책임 구조 결정. 정확히 하나의 Accountable 당사자 필수.

4. 영향 분석​

각 대안의 결과 평가. 비즈니스 가치, 기술 부채, 조직 변화, 리스크 노출, 자원 요구사항 고려.

5. 이해관계자 자문​

결정 전 Consulted 당사자 참여. 진정한 양방향 커뮤니케이션.

6. 결정 승인​

Accountable 당사자가 분석과 자문 기반으로 최종 결정. 명시적이고 문서화된 승인.

7. 커뮤니케이션​

결정 후 모든 영향받는 당사자에게 통보. Back-Writer 에이전트가 Notion과 Slack으로 커뮤니케이션 처리.

8. 검증 추적​

결정 결과 평가를 위한 지표와 검토 날짜 설정. Analyst 에이전트가 검증 지표 추적.

의사결정 검토 및 수정​

정기 검토​

전략적 결정은 분기별, 아키텍처 결정은 반기별, 정책 결정은 연간 검토.

트리거 기반 검토​

시장 변화, 기술 변경, 경쟁사 움직임, 내부 역량 변화 등 중요 이벤트가 비정기 검토 유발.

결정 폐기​

비효과적이거나 상황이 변한 결정은 명시적으로 폐기. 왜 더 이상 적용되지 않는지, 무엇이 대체하는지 기록.

결정 대체​

새 결정이 이전 결정을 대체할 수 있음. 명확한 대체 관계로 상충하는 활성 결정 방지.

의사결정에서 학습하기​

  • 결정 품질 평가: 결과를 초기 기대와 대비 평가
  • 가정 테스트: 어떤 가정이 정확했고 어떤 것이 아니었는지 추적
  • 패턴 인식: 시간에 걸쳐 반복되는 패턴 식별
  • 프로세스 개선: 결정 결과를 사용하여 의사결정 프로세스 자체 정제

일반적인 의사결정 함정​

분석 마비: 제한된 단점이나 쉬운 되돌림이 가능한 결정을 과도하게 분석. 성급한 약속: 문제 이해나 대안 생성 전에 결정. 형식적 자문: 진정한 고려 없이 자문의 형식만 거치는 것. 합의 추구: 모든 사람의 동의를 얻으려 하는 것. 하나의 Accountable 당사자가 자문 후 결정을 내림. 암묵적 결정: 무행동을 통해 선택이 일어나게 두는 것. 검증 회피: 결과 추적을 건너뛰는 것. 검증은 비난이 아니라 학습.

관련 문서​

원본 문서: Notion - RABSIC & Value Stream 운영 가이드 최종 동기화: 2026-02-08