대부분의 software는 무엇이 바뀌었는지 기억합니다. 훨씬 적은 software만이 왜 그 변경이 허용되었는지, 누가 또는 무엇이 그것을 결정했는지, 그리고 그 결정이 어떤 evidence 위에 있었는지 기억합니다. 그 빈틈에서 신뢰는 조용히 깎입니다. operations team은 보통 “지금 상태가 무엇인가”에는 답할 수 있습니다. 하지만 “우리가 어떻게 여기까지 왔는지 보여주고, 우리가 허용되어 있었다는 것을 증명하라”에는 답하지 못하는 경우가 많습니다.
Threada는 두 번째 질문에 항상 답할 수 있도록 만들어졌습니다. 모든 governed action은 receipt를 남깁니다.
receipt가 실제로 담는 것
receipt는 log line이 아닙니다. log line은 “무언가가 일어났다”고 말합니다. receipt는 나중에 decision을 재구성하고 방어할 만큼 충분히 말합니다. Threada에서 governed action은 다음을 기록합니다.
- Actor. human operator 또는 AI participant이며, distinct actor event로 기록됩니다. agent의 approval은 사람의 approval처럼 가장하지 않습니다.
- Input. WorkItem, extracted entity, requester identity, 요청이 들어온 source channel입니다.
- Evidence. citation, retrieval trace, 그리고 context가 부족했을 때의 explicit fallback reason입니다. work는 citation 또는 recorded fallback reason 없이 생성될 수 없습니다.
- Policy. 어떤 policy set이 active였는지, 어떤 version인지, tenant-wide인지 아니면 pack, workflow, channel, requester group으로 좁혀 적용되었는지입니다.
- Outcome. action이 proposed, approved, rejected, executed, succeeded, failed 중 무엇이었는지와 그것이 건드린 external record로의 linkage입니다.
그 field를 함께 읽으면 단일 단계에 대한 방어 가능한 설명이 됩니다. WorkItem lifecycle 전체에 걸쳐 읽으면 완전한 history가 됩니다.
나중에 붙이는 feature가 아니라 default로서의 auditability
대부분의 system에서 유혹은 audit을 나중에 추가하는 것입니다. feature를 ship하고, 고객이 SOC 2 evidence를 요구하거나 regulator가 찾아오면 logging을 감쌉니다. 이 순서는 거꾸로입니다. 나중에 추가한 audit은 항상 부분적입니다. decision이 만들어지는 순간 system이 context를 carry하도록 요구받지 않았기 때문입니다.
Threada는 순서를 뒤집습니다. runtime은 의미 있는 모든 transition에서 structured event, work_item_created, approval_requested, approval_decided, action_proposed, action_executed, fallback_triggered를 emit합니다. work를 수행하는 행위와 그것을 기록하는 행위가 같기 때문입니다. 별도의 “auditing 켜기” 단계는 없습니다. work가 record 밖에서 일어나는 순간이 없기 때문입니다.
이것이 우리가 model을 records-and-receipts라고 부를 때의 의미입니다. record는 생성하는 report가 아니라, 일을 올바르게 수행한 residue입니다.
receipt가 team 운영 방식을 바꾸는 이유
receipt는 quarter 끝의 auditor에게 유용합니다. 하지만 더 조용한 가치는 화요일 한가운데의 operator에게 있습니다.
모든 action이 evidence와 policy basis를 가지고 있으면 세 가지가 쉬워집니다.
- Review가 빠르고 정직해집니다. approver는 memory에서 context를 재구성하거나 original ask를 위해 requester를 쫓지 않아도 됩니다. evidence가 action 옆에 있습니다. confidence, reversibility, clarity가 decision point에 보이므로 reviewer는 speed alone이 아니라 reviewability에 맞춰 최적화합니다.
- Reversal이 안전해집니다. receipt가 policy version과 input을 명명하기 때문에 action을 rollback하는 것은 archaeology project가 아니라 defined operation입니다. 무엇을 되돌리는지, 왜 그것이 수행되었는지 압니다.
- Accountability가 대립적인 것이 아니게 됩니다. record가 스스로 조립되면 “누가 이것을 승인했나”는 비난이 아니라 field일 뿐입니다. builder, approver, governance role 사이의 separation of duties가 강제되고 보이므로, 책임성 질문은 누가 묻기 전에 이미 답해져 있습니다.
고위험 work는 사람과 함께, record 위에 남는다
Receipt가 모든 것이 자동화된다는 뜻은 아닙니다. 모든 것이 accountable하다는 뜻입니다. 고위험 automation은 explicit human-in-the-loop progression, 즉 proposed, approved, executing을 따르고, policy가 명시적으로 허용하는 곳에서만 auto-execute합니다. receipt는 특정 action이 어떤 path를 택했는지 기록합니다. automation과 approval은 긴장 관계가 아닙니다. 둘 다 trace를 남기는 step일 뿐입니다.
결과는 auditor와 새 operator에게 같은 confidence로 건넬 수 있는 system입니다. auditor는 control이 유지되었음을 봅니다. operator는 앞의 case를 마지막 사람이 어떻게 처리했는지 봅니다. 둘은 같은 receipt를 읽습니다.
Threada 아래의 베팅은 이것입니다. decision이 왜 허용되었는지를 capture하기 가장 싼 순간은 그것을 내리는 순간이며, record 밖에서 일하지 않는 team은 언제나 두 번째 질문에 답할 수 있습니다.