CODR란? 판단을 기록하는 4단계 표준

결정은 매일 내려지지만, 그 결정을 '다시 쓸 수 있는 형식'으로 남기는 조직은 드뭅니다. 판단 기록 CODR은 상황·선택지·결정·근거 네 가지를 한 묶음으로 남겨, 흩어진 판단을 조직의 자산으로 바꾸는 표준입니다.
CODR이란 무엇인가 — 판단 기록의 4단계
CODR은 하나의 판단을 네 가지 요소로 구조화하는 기록 표준입니다. 무엇을 결정했는지뿐 아니라, 어떤 상황에서 어떤 선택지를 두고 왜 그 결정을 내렸는지까지 함께 남깁니다. 핵심은 '결과'가 아니라 '판단의 맥락과 근거'를 보존하는 데 있습니다.
- Context(상황): 어떤 조건·제약·문제가 결정을 촉발했는가
- Options(선택지): 검토한 대안과 각각의 장단점
- Decision(결정): 무엇을 선택했는가
- Reason(근거): 왜 그 선택이 그 시점에 옳았는가
ADR·결정 로그와 CODR의 관계
판단을 구조화해 기록하려는 시도는 소프트웨어 업계에서 먼저 자리잡았습니다. 마이클 나이가드(Michael Nygard)가 2011년 제안한 ADR(Architecture Decision Record)은 상태·상황(Context)·결정(Decision)·결과(Consequences)를 한 문서로 남기는 방식이고, 이런 ADR을 모아둔 것이 결정 로그(decision log)입니다. 나이가드는 '새로 합류한 사람이 과거 결정의 근거를 모르면, 맹목적으로 따르거나 맹목적으로 바꾸는 두 가지 선택밖에 없다'고 지적했습니다.
CODR은 이 흐름을 잇되 적용 범위를 넓힙니다. ADR이 주로 아키텍처 같은 기술 결정을 대상으로 한다면, CODR은 제조·물류·건축처럼 현장에서 비정형 대화로 오가는 운영 판단까지 포괄합니다. 결정 시점의 '근거(Reason)'를 명시화해, 비슷한 상황이 다시 왔을 때 바로 비교·재사용할 수 있게 한 점이 차이입니다.
제조 현장의 CODR 예시
예를 들어 한 부품의 공급사를 교체하는 판단을 CODR로 남기면 다음과 같습니다.
- Context: 기존 공급사 납기 지연이 3개월 누적, 라인 정지 위험
- Options: A사(단가 높음·납기 안정) / B사(단가 낮음·품질 미검증) / 기존사 유지(개선 약속)
- Decision: A사로 1차 전환, B사는 소량 병행 검증
- Reason: 라인 정지 손실이 단가 차이를 초과, 품질 리스크는 단계 검증으로 흡수
1년 뒤 비슷한 공급 이슈가 생겼을 때, 후임자는 같은 고민을 처음부터 반복하지 않습니다. '왜 그때 단가 높은 A사를 택했는가'라는 근거가 남아 있어, 그 판단을 신뢰하거나 조건이 달라졌음을 근거로 다르게 결정할 수 있습니다.
자주 묻는 질문
CODR과 ADR은 무엇이 다른가요?
ADR은 주로 소프트웨어 아키텍처 결정을 대상으로 하고, CODR은 제조·물류·건축 등 현장 운영 판단까지 포괄합니다. 또 CODR은 결정 시점의 '근거'를 명시해 유사 상황에서의 재사용을 전제로 설계되었습니다.
기존 결정 로그(decision log)를 쓰면 충분하지 않나요?
결정 로그는 결정과 그 이유를 모아두는 좋은 출발점입니다. CODR은 여기에 '선택지'와 '근거'를 표준 항목으로 강제해, 사람마다 기록 편차가 생기는 문제를 줄이고 검색·비교가 가능하도록 합니다.
출처 · 참고자료
- Architectural Decision Records (ADRs) — adr.github.io
- Decision record template by Michael Nygard — GitHub - architecture-decision-record
- Why you should be using architecture decision records to document your project — Red Hat