제약만으로는 무엇을 만들지 알 수 없습니다

규제 제품을 만드는 팀은 소프트웨어의 언어로 쓰이지 않은 규정, 내부 정책, 전문가 의견을 받습니다. 자연스러운 반응은 모든 문장을 기능 요구로 바꾸는 것입니다. 백로그는 커지지만 규칙, 위험, 증거 사이의 연결은 더 찾기 어려워집니다.

제품 정의는 솔루션을 상세화하기 전에 이 연결을 만들어야 합니다. 제품 팀이 혼자 규정을 해석하거나 전문가가 인터페이스를 설계하라는 뜻이 아닙니다. 각 분야가 결정과 근거를 함께 볼 수 있는 공통의 대상을 만드는 일입니다.

의무를 관찰 가능한 상황으로 표현하기

유용한 문장은 누가, 어떤 대상에, 언제, 어떤 정보를 가지고 행동하며, 어떤 기록이 남아야 하는지를 말합니다. 이 구조는 모호함을 드러냅니다. 또한 답이 제품, 사람의 절차, 조직 통제, 또는 세 요소의 결합 중 어디에 있는지 보여 줍니다.

추적 가능성을 보장한다는 말만으로는 부족합니다. 어떤 사건이 대상인지, 누가 조회할 수 있는지, 기록이 얼마 동안 유용한지, 행동에 이의를 제기하는 방법과 정보가 없을 때 시스템의 행동을 정해야 합니다.

이 정밀함이 전문가의 검토를 대신하지는 않습니다. 확인하거나 수정할 수 있는 구체적인 대상을 제공합니다.

민감한 결정은 네 요소와 연결되어야 합니다.

이 체인은 두 가지 실패를 막습니다. 첫째는 어떻게 충족하는지 보여 주지 못하면서 준수한다고 선언하는 경우입니다. 둘째는 어떤 위험을 줄이는지 모른 채 비싼 장치를 만드는 과잉 준수입니다.

결정 기록은 짧고 살아 있어야 합니다. 완전하지만 오래된 데이터베이스는 전달을 돕지 못합니다. 되돌리기 어려운 결정, 열려 있는 가설, 아직 만들어야 하는 증거를 우선합니다.

민감한 제품은 자동화와 사람의 판단 사이 경계를 명시할 때 더 안전합니다. 규칙은 작업을 자동으로 막거나, 검토할 신호를 만들거나, 이의를 제기할 수 있는 결정을 제안하거나, 기록만 남길 수 있습니다.

각 행동은 사용자, 운영, 책임에 다른 영향을 줍니다. 구현 과정에서 우연히 정해져서는 안 됩니다. 인터페이스도 시스템이 아는 것, 추론한 것, 사람이 아직 결정해야 하는 것을 구분해 보여 주어야 합니다.

일반적인 제품 정의는 정상 흐름을 먼저 그리고 예외를 나중에 추가합니다. 규제 환경에서는 예외에 실제 위험이 들어 있는 경우가 많습니다. 데이터 부재, 불확실한 신원, 지난 기한, 충돌하는 출처, 이의가 제기된 결정, 사용할 수 없는 외부 서비스가 대표적입니다.

이 사례를 일찍 다루면 빠진 책임이 보입니다. 누가 차단을 해제하는지, 어떤 정보가 보여야 하는지, 어느 정도 지연이 허용되는지, 이후 검토를 위한 기록이 무엇인지를 정할 수 있습니다. 답은 사용자 경험만큼 아키텍처에도 영향을 줍니다.

첫 번째 증분이 전체 규제를 다루려고 해서는 안 됩니다. 좁은 범위에서 하나의 완전한 체인을 닫아야 합니다. 실제 상황, 결정, 증거, 이의 제기나 복구 방법, 그리고 이를 운영할 팀이 필요합니다.

이 범위는 긴 명세보다 강한 논의를 만듭니다. 전문가는 실제 행동을 검토할 수 있습니다. 기술 팀은 증거의 비용을 봅니다. 업무 팀은 규칙이 일상 작업을 어떻게 바꾸는지 확인합니다.

좋은 제품 정의는 규제 불확실성을 없애지 않습니다. 불확실성의 위치를 보여 줍니다. 검증된 결정, 아직 의견이 필요한 결정, 만들어질 증거, 해석이 바뀔 때 수정할 시스템 부분이 명확해집니다. 문서화된 적응 능력은 고정된 준수 약속보다 더 오래 작동합니다.