아무도 실제로 추적하지 않는 격차

Git 히스토리는 특정 워크스테이션이 커밋을 푸시했다는 사실을 알려줄 수 있습니다. 하지만 그 변경 사항을 실제로 누가 또는 무엇이 만들어냈는지는 알려주지 못합니다. 당신이었나요? IDE 내부에서 실행 중인 AI 에이전트였나요? CI 작업이었나요? 아니면 연결해 두었다는 사실조차 잊어버린 어떤 벤더 도구였나요?

오랫동안 그 질문은 학술적인 문제에 불과했습니다. 하지만 이제는 아닙니다. AI가 개입된 상태로 더 많은 코드를 작성할수록, 하나의 조용한 가정이 점점 더 흔들리고 있습니다. 바로 모든 커밋 뒤에는 인간 저자가 있다는 가정입니다. 감사 추적(Audit trails), 장애 검토(Incident reviews), 컴플라이언스 워크플로우(Compliance workflows) 등 이 모든 것들이 이 가정에 의존하고 있습니다. 그리고 이 가정이 무너지고 있습니다.

Matrix Scroll은 이를 해결하기 위한 작고 개방적인 시도입니다. 이 도구는 커밋에 서명된 출처 봉투(signed provenance envelope)를 첨부하며, 누구나 오프라인에서 이를 검증할 수 있습니다.

실제로 하는 일

에이전트의 도움을 받은 커밋은 다음과 같은 정보를 기록하는 서명된 JSON 봉투를 포함할 수 있습니다:

• 행위자 (인간 또는 에이전트)
• 변경 사항을 생성한 도구
• 선택적인 제한된 범위 (bounded scope)
• 매니페스트(manifest)의 정규화된 버전에 대한 Ed25519 서명

서명 입력값은 엄격하며 솔직히 말해 다소 지루할 정도입니다. 하지만 그것이 핵심입니다. 구현 방식에 관계없이 바이트 단위로 재현 가능해야 하므로 다음과 같은 규칙을 따릅니다:

• 서명 전 최상위 서명 블록을 제거합니다.
• 객체 키(object keys)를 재귀적으로 정렬합니다.
• 컴팩트한 구분자, ASCII 이스케이프, UTF-8 바이트를 사용합니다.
• NaN이나 Infinity는 허용하지 않습니다.

장치 ID는 SHA-256(public_key)의 처음 8개 대문자 16진수 문자를 가져와 MS-XXXX-XXXX 형식으로 구성됩니다. 검증은 쉬운 부분입니다. 정규화된 매니페스트 바이트를 가져와 내장된 공개 키 및 서명과 대조하면 됩니다. 중간에 개입하는 중앙 서비스는 없습니다.

설치 없이 체험해 보기

전적으로 클라이언트 측에서 실행되는 브라우저 검증기가 있습니다. 아무것도 업로드되지 않습니다:

(̿▀̿‿ ̿▀̿ ̿) :    https://matrixscroll.com/verify/

10초만 투자해 보세요:

1. Load Commit Envelope → Verify Signature를 클릭하세요. 그러면 VALID 결과와 함께 디바이스 ID (device ID), 모드 (mode), 알고리즘 (algorithm), 그리고 정규화된 바이트 수 (canonical byte count)를 확인할 수 있습니다.
2. 이제 Tamper Sample → Verify Signature를 다시 클릭하세요. 결과가 INVALID로 바뀌며 무엇이 잘못되었는지 정확히 알려줍니다. 예: "Device ID mismatch: expected MS-4319-20D5, manifest says MS-TAMP-ERED".

이러한 왕복 과정(round trip)이 기본적으로 핵심 아이디어입니다. 즉, 바이트가 변경되는 즉시 진정으로 실패하는 서명(signature)을 만드는 것입니다.

리포지토리(repo)에 추가하기

pip install "matrixscroll==0.2.6"
matrixscroll hook-install
matrixscroll hook-status

커밋을 에이전트가 생성한 것으로 표시하려면:

export MATRIXSCROLL_ACTOR_TYPE=agent
export MATRIXSCROLL_TOOL=agent-runner
git commit -m "feat: agent change"
...

CI에서 풀 리퀘스트 (pull request)를 제한하고 싶으신가요? GitHub Action ("Scroll Gate")은 머지(merge) 전에 PR 범위 내의 모든 커밋을 검증합니다:

- uses: SSX360/matrixscroll-verify-action@v1  with:
    matrixscroll-version: "0.2.6"
    require-mode: # ...

훅 (Hooks)은 기본적으로 경고 (warn) 모드로 설정되어 있습니다. 서명 실패 시 실제로 차단하기를 원한다면 .git/matrixscroll/config.json에서 "enforce": true로 설정하세요.

적용 범위 (및 적용되지 않는 범위)

이 부분은 솔직하게 말씀드리고 싶습니다. 보안 도구는 적용 범위 (scope)를 정확히 정의함으로써 신뢰를 얻기 때문입니다.

Matrix Scroll은 커밋 시점의 출처 (provenance)를 다룹니다. 이는

현재 배포 중: PyPI 0.2.6, Git hooks, 브라우저 검증기(browser verifier), 그리고 GitHub Action을 통한 PR 범위 검증(PR-range verification).

진행 중: 전용 보안 요소(SE050)를 통한 하드웨어 기반 서명(hardware-backed signing), 외부 Ed25519 키 백엔드, 그리고 투명성 로그(transparency-log) 통합.

현재 기본 설정은 소프트웨어로 에뮬레이션된 키 — 즉 "L1" 모드 — 를 사용하며, 이는 로컬 개발, 데모 및 CI를 위해 의도되었습니다. 하드웨어 기반 키(Hardware-rooted keys)는 다음 신뢰 계층(trust layer)이며, 제가 가장 먼저 내세우는 기능은 아닙니다.

따라서 만약 당신의 위협 모델(threat model)에 로컬 머신이 완전히 침해된 상황이 포함되어 있다면, 에뮬레이션 경로는 아직 당신을 보호하지 못할 것입니다. 하드웨어 작업이 바로 그 문제를 해결하기 위한 것입니다. 과장해서 홍보하기보다는 차라리 솔직하게 말씀드리고 싶습니다.

프로토콜, JSON 스키마(JSON schemas), 그리고 적합성 벡터(conformance vectors)는 모두 공개되어 있으므로, 누구나 이 형식을 구현하거나 분석할 수 있습니다.

링크

• Spec: https://matrixscroll.com/spec/
• Verifier: https://matrixscroll.com/verify/
• Comparison vs Sigstore/SLSA/peers: https://matrixscroll.com/compare/
• GitHub: https://github.com/SSX360/matrixscroll

AI 보조 코드를 위한 출처(provenance)에 대해 고민해 보셨거나, 혹은 커밋(commit)이 이 문제를 해결하기에 적절한 계층이 아니라고 생각하신다면, 댓글을 통해 진심으로 의견을 듣고 싶습니다.

fin.