인간의 확인(Human Confirmation)은 불리언 값이 될 수 없다: AI가 작성해야 하는 바인딩 요소

이전 글들은 무언가를 멈추는 것에 관한 것이었습니다. 경계가 어디에 있는지, 위험도가 어떻게 계층화되는지, 작성이 어떻게 되돌려지는지에 대한 내용들이었죠. 이번 글은 한 가지 부분에 초점을 맞춰 뒤로 물러나서 살펴봅니다.

사용자가 '예'를 클릭한 후 시스템이 실제로 보유하게 되는 정보입니다.

이는 체인에서 구축하기 너무 쉬워서 오히려 취약한 부분이기도 합니다.

1. 그것이 수렴하는 형태: 불리언 값(boolean) AI가 무언가를 작성하려고 합니다. 요청하면, 사용자는 확인 메시지를 보고 '예'를 클릭하고, 실행됩니다.

만약 '예'가 불리언 값이면, confirmed = true로 설정되는데, 여기에는 두 가지 문제가 있습니다.

더 작은 문제는 재사용 가능하다는 것입니다. 동일한 '예'가 두 번째 것을 승인할 수 있는가? 이것은 새로운 문제가 아니며, 일회성(one-shot)으로 표시하면 해결됩니다.

더 큰 문제는 더 조용합니다: 불리언 값은 증명서(credential)가 아니라 문장일 뿐입니다. '예'라는 단어는 다음 질문들에 답할 수 없습니다:

• 어떤 요청이 승인되었는가?
• 무엇을 작성하도록 승인했는가?
• 어디에 작성하도록 승인했는가?
• 얼마나 변경하도록 승인했는가?
• 언제까지 유효한가?

만약 이 질문들에 답할 수 없다면, 답변은 실행 시점에 결정되며, 그 순간은 '승낙'의 순간과 어느 정도 거리가 있습니다. 그 사이에 변하는 모든 것은 사용자에게 감지되지 않습니다.

우리가 하는 일은 '예'를 다섯 가지 것을 바인딩하는 행(row)으로 만드는 것입니다. 아래 각각의 요소들은 이것 없이는 무너집니다.

1. 무엇을 바인딩할 것인가 (Bind what): 정확한 인자들 A 확인은 해당 호출의 인자들을 문자 하나하나까지 바인딩합니다.

원래 버전에서는 도구와 그 인자들을 기록했습니다. 그것만으로 충분해 보였습니다. 작성될 내용은 고정되어 있었습니다. 무엇이 더 움직일 수 있을까요?

어디에 작성될지 말입니다.

도구 이름과 그 인자들은 모두 우리 측의 문제입니다. 실제로 쓰기가 도착하는 외부 시스템은 별개의 문제입니다. 프록시 도구의 설정은 재지정할 수 있고, 외부 서비스는 재등록할 수 있습니다. 승인된 기록은 모든 인자가 변경되지 않은 채 데이터베이스에 남아있지만, 그 목적지는 다른 것으로 교체될 수 있습니다.

기록 내용 중 어느 것도 이를 모순하지 않습니다.

해결책은 목적지까지 바인딩하는 것입니다: 이슈 시점에 기록하고, 실행 시점에 재해결하며, 두 값이 불일치할 경우 거부해야 합니다. 절대로 조용히 따라가서는 안 됩니다.

스스로 기억할 가치가 있는 점: '승인됨(approved)'과 '어디까지 승인됨(approved to where)'은 서로 다른 개념입니다.

1. 얼마나 많이 바인딩할 것인가: 쓰기 가능한 필드 도메인 왜 이것이 필요할까요? 이미 정확한 인자들을 바인딩했기 때문 아닌가요?

정확한 인자들은 전체 세트를 수락하거나 거부하는 것만 가능하지만, 확인(confirmation)이라는 것은 보통 개별 필드 단위로 이루어지기 때문입니다:
이번에는 상태가 변경될 수 있지만;
소유자가 변경되지는 않을 수도 있습니다.
쓰기 가능한 필드를 별도로 선언할 때만 이를 말할 수 있습니다.

이는 정확한 인자들을 대체하는 것이 아니라 나란히 존재합니다: 하나는 '이것들이 값인가'에 답하고, 다른 하나는 '이런 종류의 필드가 아예 쓰여질 수 있는가'에 답합니다. 관례는 시스템의 나머지 부분과 일치합니다: 아무것도 선언되지 않은 것은 제약받지 않음을 의미하며; 선언된 범위를 벗어나는 모든 것은 거부되고, 잘려나가지 않습니다(truncated). '잘려나간다'는 것은 실제로 발생한 것이 '거부되었어야 할 쓰기가 조용히 축소되어 허용되었다'로 읽힐 수 있기 때문입니다.

1. 언제 바인딩할 것인가: 기간 확인이 만료되는 시간은 새로운 정보가 아닙니다. 놓치기 쉬운 것은 만료 시점이 어디에 보관되느냐 하는 것입니다.

우리가 저지른 실수는 다음과 같습니다: 이 기간(window)이 토큰에만 존재했습니다. 토큰이 소모되면 사라졌습니다. 그래서 3개월 후에 그 행을 보면 '승인되었다'고 말할 수는 있지만, 어떤 기간이었는지 말할 수 없었습니다.

바로 그 지점에서 중요합니다. 누군가 왜 특정 시점에 쓰기가 허용되었는지 묻는다면, 기록을 확인해 보면 해당 창(window)이 문제가 된 시점의 구성에 의존했으며, 이 구성은 이미 변경되었다는 사실이 드러납니다.

수정 방법은 간단합니다. 문제 시점의 행에 해당 창을 쓰고, 나중에 그 행에서 값을 읽으세요. 현재 구성으로 다시 계산하지 마십시오.

1. 누가(who)와 무엇을(which one) 바인딩할 것인가: 운영자(operator)와 결정의 순간(moment of the decision)이라는 두 가지 마지막 요소입니다.

그리고 거부(refusal) 역시 승인(approval)과 동일한 바인딩 과정을 거칩니다.

마지막 조항은 의도적입니다. 만약 '아니요'가 자체 스위치를 가진 별도의 경로였다면, 이 둘은 분리될 것입니다. 오늘 승인에 추가된 바인딩이 내일 거부 경로에서는 잊히게 됩니다. 하나의 기록과 하나의 진입점을 공유하는 것이 이를 불가능하게 만듭니다.

1. 스스로 실행해 볼 수 있는 점검: '내 확인 절차가 충분한가?'에서 시작하지 마십시오. 더 구체적인 것부터 시작하세요:

귀하의 확인 과정 중 어떤 필드가 문제 시점에 한 번 계산되고, 실행 시점에 다시 계산됩니까?

이러한 모든 것은 변동될 수 있습니다. 이를 테스트할 세 가지 질문입니다:

같은 확인 과정을 다른 대상 시스템에 적용했을 때 성공합니까?
하나의 인수를 변경했을 때 성공합니까?
세 달 후에, 해당 창이나 정책 개정 사항이 무엇이었는지 말할 수 있습니까?

'예' 또는 '모르겠다(can't tell)'라는 답변은 바인딩되지 않은 부분이 있다는 것을 의미합니다.

마무리

처음의 모양으로 돌아가 봅시다: 만약 '예'가 불리언 값이라면, 그것은 자격 증명이 아니라 문장입니다. 그리고 사슬 속의 모든 약속은 이 부분에 의존하여 완성됩니다. 감사 기록은 누가 무엇을 승인했는지 보여줍니다. 취소(Revocation)는 승인된 쓰기를 되돌립니다. 이 부분을 얇게 만들면 나중에 연결되는 모든 링크가 조용히 이를 커버하게 됩니다.

우리가 바인딩하는 다섯 가지 요소: 정확한 인수, 목적지, 쓰기 가능한 필드 도메인, 유효성 창(validity window), 운영자 및 결정 순간입니다.

우리가 명확하게 밝히지 않은 두 가지가 있습니다. 필드 도메인(field domain)은 특정 종류의 필드가 작성될 수 있는지 여부는 말할 수 있지만, 'A가 변경했을 때만 B가 변경될 수 있다'와 같은 교차 필드 규칙(cross-field rule)을 표현할 수는 없습니다. 그리고 윈도우 컬럼(window column)이 나중에 추가되었기 때문에 그 이전의 행들은 해당 필드를 반환하지 않습니다. 이들의 윈도우는 알 수 없으며, 우리는 이에 대한 기본값을 설정하지 않습니다.

여기서 자연스러운 다음 단계이기 때문에 우리가 추구하지 않기로 결정한 질문 하나가 있습니다. 승인 건마다 자격 증명(credential)을 발행하는 것은 어떨까요?

저희가 비용을 계산해 보았습니다. 확인(confirmation)은 이미 일회성(one-shot)이며, 자격 증명(credential)은 이미 단기적이고(short-lived) 하나의 대상 시스템에 한정되어 있고, 목적지(destination) 또한 이제 바인딩됩니다. 이 모든 것이 우려 사항을 다룹니다. 추가적인 계층은 새로운 보장(guarantee)이 아니라 중복된 복잡성만 구매할 뿐입니다.

따라서 이것은 채워야 할 격차(gap)가 아니라 트레이드오프(trade-off)입니다. 이 문제는 누구나 진지하게 생각하면 물어볼 것이기 때문에 여기에 있습니다.

AI 어시스턴트의 도움을 받아 작성되었습니다. 시스템, 포지션 및 실수는 저의 것입니다.