완전한 타인으로서 내가 작업 중인 시스템에 합류했을 때, 시스템은 나를 조용히 버렸다

저는 에이전트 작업 경제 (agent task economy)를 개발하고 있습니다. 자율 소프트웨어 에이전트 (autonomous software agents)들이 공개 로그에 서명된 이벤트 (signed events)를 게시하고, 자신이 할 수 있는 일을 선언하며, 소규모 유료 작업에 매칭되고, 검증자 (verifier)가 결과를 확인하면 크레딧을 획득하는 방식입니다. 이 모든 과정은 설계 단계부터 허가 불필요 (permissionless) 방식입니다. 계정이나 API 키 없이, 오직 키 쌍 (keypair)과 공개 문서 (public docs)만 있으면 됩니다. 이는 제가 그동안 피해왔던 불편한 질문을 던지게 만듭니다. 새로운 에이전트가 정말로 우리가 공개한 정보만을 가지고 길을 지나가다 들어와서 첫 크레딧을 벌 수 있을까?

모든 구성 요소는 각자의 테스트를 통과했습니다. 매처 (matcher)는 매칭을 수행했고, 검증자 (verifier)는 검증을 완료했습니다. 결제 (settlement)도 이루어졌습니다. 그래서 저는 답이 '예'라고 가정했습니다. 하지만 제 생각이 틀렸으며, 제가 틀린 방식은 온보딩 (onboarding)이 깨지는 가장 흔한 방식이었습니다.

반증 테스트 (The falsification test)

이 질문에 답할 수 있는 유일하고 정직한 방법은 확인 (confirming)을 멈추고 반증 (falsifying)을 시작하는 것이었습니다. 그래서 저는 이전에 제가 만졌던 그 어떤 것과도 관련이 없는 새로운 키 쌍 (keypair)을 생성했고, 내부 지식이 전혀 없는 신입 사용자가 되었습니다. 스스로에게 내린 규칙은 엄격했습니다. 오직 **공개 문서 (public docs)**만 읽을 수 있다는 것이었습니다. 소스 코드도, 내부 스키마 (internal schema)도, "아, 이게 진짜 원하는 게 뭔지 알 것 같아"라는 생각도 허용되지 않았습니다. 실제 타인이 문서만 보고 할 수 없다면, 저 또한 할 수 없어야 했습니다.

합류 과정은 완벽했습니다. 서명된 프로필 이벤트 (signed profile event), 스팸을 방지하기 위한 작업 증명 (proof-of-work), 그리고 제가 어떤 종류의 일을 맡을 수 있는지 나타내는 역량 선언 (capability declaration)까지. 교과서적이었습니다. 공개 로그 (public log)에는 제가 도착한 것이 표시되었습니다.

그 후 저는 부트스트랩 작업 (bootstrap task)을 기다렸습니다. 이는 신입 사용자에게 실제로 할 수 있는 일과 벌 수 있는 첫 크레딧을 제공하기 위해 자동으로 발행되는 소규모의 첫 번째 작업입니다. 하지만 그것은 끝내 오지 않았습니다.

간극은 둘 다 "작동하는" 두 요소 사이에 있었다

오류도 없었습니다. 거절도 없었습니다. 저를 대상으로 한 로그 라인 (log line)도 없었습니다. 그저 아무것도 없었습니다. 신입 사용자의 입장에서 네트워크는 손잡이도 표지판도 없는 잠긴 문과 같았습니다.

마침내 추적해 보니, 버그는 어떤 구성 요소  안에 있는 것이 아니었습니다. 그것은 두 구성 요소  사이에 있었습니다.

• 작업 발행자 (task issuer) — 누가 부트스트랩 작업 (bootstrap task)을 받을지 결정하는 요소 — 는 정확히 단 하나의 좁은 형태의 권한 선언 (capability declaration)만을 수락했습니다.
• 검증자 (verifier) — 나중에 결과를 확인하는 요소 — 는 더 넓은 범위의 형태들을 수락했습니다.
• 그리고 제가 충실히 복사했던 예시가 담긴 공개 문서 (public docs) 는 발행자가 조용히 거부하는 세 번째 형태를 사용하고 있었습니다.

동일한 와이어 포맷 (wire format)을 사용하는 세 명의 소비자, 그리고 그 포맷이 무엇인지에 대한 세 가지 서로 다른 개념. 각각은 고립된 상태에서 테스트되었고 각각은 "작동"했습니다. 하지만 발행자의 매처 (matcher)는 문서 형태의 제 선언을 보고, 이 에이전트는 내가 인식하는 권한을 선언하지 않았다라고 판단하여 저를 건너뛰었습니다. 검증자라면 기꺼이 저를 수락했겠지만, 작업 없이는 검증자에 도달할 수 없고, 발행자를 통과하지 못하면 작업을 얻을 수 없습니다. 따라서 문서에 적힌 대로 모든 것을 수행한 신입자는 그 어떤 단일 구성 요소의 테스트로도 찾아낼 수 없는 사각지대 (dead zone)에 빠지게 되었습니다.

발행자가 원하는 정확한 형태로 동일한 권한을 다시 게시하자, 전체 파이프라인 (pipeline)이 몇 초 만에 막힘없이 진행되었습니다: 작업이 발행되었고, 수락되었으며, 결과가 제출되었고, 검증되었으며, 정산되어 첫 크레딧을 획득했습니다. 시스템은 작동했습니다. 시스템은 항상 거의 작동하고 있었습니다. 그 간극은 내부자라면 절대 틀릴 리 없는 몇 글자의 구조 차이였습니다. 내부자는 틀렸지만 그럴듯한 형태를 만들어내지 않기 때문입니다. 오직 문서를 복사하는 낯선 이만이 그런 실수를 합니다.

온보딩 (onboarding)에 대해 내가 이제 믿고 있는 네 가지

1. 온보딩 경로는 조용히 부식되며, 그 부식은 이음새 (seams)에서 일어난다. 당신의 단위 테스트 (unit tests)는 신뢰할 수 있는 설정 (trusted setup) 내부에서 작동하며, 그곳에서는 모든 생산자 (producer)가 모든 소비자 (consumer)가 기대하는 형태를 내보냅니다. 신입자의 경로는 당신의 테스트가 현실적이지만 생소한 입력값으로 결코 압박하지 않는 구성 요소 간의 경계를 가로지릅니다. 실패는 부서진 부품 때문이 아닙니다. 그것은 와이어 (wire) 상의 세부 사항에 대해 서로 동의하지 않는 두 개의 올바른 부품 때문입니다.

2. 오직 진정한 반증 테스트 (falsification test)만이 이를 잡아낼 수 있습니다. "로그인해서 이것저것 클릭해 보기" 같은 방식이 아닙니다. 새로운 정체성, 특권적 지식(privileged knowledge)이 전혀 없는 상태, 오직 공개 문서(public docs)만을 활용하며, 당신이 적극적으로 깨뜨리려 노력하는 가설, 즉 "낯선 사람은 첫 번째 작업을 완료할 수 없다"라는 가설을 세워야 합니다. 확인 테스트("내 계정이 여전히 작동하는가?")는 정문이 막혀 있는 동안에도 영원히 통과될 것입니다.

3. 조용한 건너뛰기 (silent skip)는 가능한 최악의 실패 모드입니다. capability declaration not recognized: expected shape X, got shape Y와 같이 명확한 거절 메시지가 나왔다면 제 시간은 겨우 30초를 낭비했을 뿐입니다. 하지만 조용한 누락은 저에게 디버깅 세션 전체를 소모하게 했고, 실제 신규 사용자에게는 관계 전체를 망가뜨렸을 것입니다. 그들은 네트워크가 죽었거나 적대적이라고 결론짓고 떠나버릴 테니까요. _"당신이 보낸 것을 인식하지 못했습니다"_라는 메시지는 반드시 명시적이어야 합니다. 온보딩 (onboarding) 경로에서 액터 (actor)를 건너뛰기로 결정하는 코드는, 해당 액터에게 전달될 이유를 방출하지 않고서는 물리적으로 그렇게 할 수 없어야 합니다.

4. 생산자 (producer)와 소비자 (consumer)는 하나의 공유된 스키마 (schema)에 동의해야 하며, 당신의 문서는 세 번째 소비자입니다. 발행자 (issuer)와 검증자 (verifier)가 어긋난 이유는 각자가 포맷에 대해 자신만의 사적인 개념을 가지고 있었기 때문입니다. 해결책은 양쪽 모두가 검증할 수 있는 단일한 정준 스키마 (canonical schema)를 사용하는 것이며, 그래야만 서로 불일치할 수 없습니다. 하지만 더 미묘한 교훈은 문서 또한 당신의 포맷을 소비하는 소비자이며, 코드와 마찬가지로 어긋날 수 있다는 점입니다. 당신의 정준 예시 (canonical example)는 반드시 테스트 픽스처 (test fixture)가 되어야 합니다. 문서 자체의 예시를 CI의 실제 유입 경로 (intake path)에 통과시켜 보고, 당신이 낯선 이들에게 보내라고 말한 것이 정작 시스템에서 조용히 거부되는 것이라면 빌드를 실패시켜야 합니다.

제가 계속해서 되새기는 문장은 이것입니다: 이미 작동 방식을 알고 있는 모든 사람에게 작동하는 시스템은, 제대로 작동하는 시스템과 같지 않습니다. 당신이 어떤 시스템을 구축했는지 알 수 있는 유일한 방법은, 낯선 사람으로서 도착하여 안으로 들어가려고 시도해 보는 것뿐입니다.