저는 개발자 도구를 만들기 위해 시작한 것이 아니었습니다. 오랫동안 저는 제 삶의 모든 부분에서 AI와 함께 작업해 왔습니다. 딸들에 대한 일상적인 대화부터 프로젝트 계획, 아직 존재하지 않는 아이디어들에 이르기까지 말이죠. 목표는 언제나 동일했습니다. 삶을 편하게 만들고, 더 많은 일을 해내며, 인간과 AI 사이의 장벽을 허무는 것 — 즉, AI를 검색창이 아닌 파트너로 대하기 시작하는 것이었습니다.

그 과정 중 어느 시점에서, 이 파트너십은 진지해졌습니다. 제 프로젝트들이 머무는 워크스페이스에는 AI 코딩 에이전트(AI coding agents)를 위한 지침 시스템이 생겨났습니다. 즉, 현재 모두가 작성하고 있는 파일들인 AGENTS.md, CLAUDE.md, 기술 디렉토리(skills directory), 그리고 에이전트가 작업 계획을 세우고, 로그를 남기고, 검증하는 방식에 대한 규칙들 말입니다.

그러다 저는 불편한 질문을 던졌습니다: 이 중 실제로 지켜지는 것이 있기는 한가?

"에이전트가 지키는 것처럼 보이는가"가 아닙니다. 저장소(repository)만 보고서 누군가가 지침이 준수되었는지 _알아낼 수 있는가?" 제 규칙 대부분에 대한 답은 '아니오'였습니다. 자체적인 감사(audit) 결과, 제 지침에서 모든 커밋(commit) 전에 반드시 실행되어야 한다고 명시한 두 가지 체크 사항은 그 무엇에 의해서도 호출되지 않았습니다. CI, 훅(hook), 예약된 작업(scheduled task) 그 무엇도 없었습니다. 그 규칙은 존재했던 내내, 그저 기억하는 사람에 의해서만 강제되어 왔을 뿐입니다. 최근 200개의 커밋을 다시 재생해 본 결과, 인덱스 최신성(index-freshness) 규칙 하나만으로도 61개의 대상 커밋 중 29개에서 실패했을 것입니다. 대략 절반에 달하는 수치입니다. 제 지침은 규칙이 아니었습니다. 그것은 서식만 갖춘 희망 사항이었습니다.

그래서 다른 사람들의 지침도 마찬가지인지 궁금해졌습니다. 저는 도구를 만들었고 측정했습니다.

제가 측정한 것, 그리고 수치에 앞서 고려해야 할 두 가지 정직한 한계

저는 **8개의 공개된 에이전트 지침 컬렉션(public agent-instruction collections)**을 분석했습니다. 이는 1,332개의 지침 단위와 17,611개의 개별 지침으로 구성되었으며, 각 컬렉션은 고정된 커밋 SHA(pinned commit SHA)를 기준으로 분석되었고, 도구와 함께 각 저장소별 원본 JSON이 공개되었습니다.

지침이 확인 가능 (CHECKABLE) 하다는 것은, 리뷰어가 저장소(repo)를 통해 해당 지침이 실제로 수행되었는지 여부를 판단할 수 있는 경우를 의미합니다. 즉, 체크박스 형태이거나, 실행 가능한 명령어를 포함하거나, 구체적인 파일 아티팩트 (file artifact)를 명시하거나, 종료 코드 (exit code), 디프 (diff), 단언 (assertion) 등을 참조하는 경우입니다. 그 외의 모든 것은 주장 가능 (CLAIMABLE) 합니다. 즉, 해당 지침이 수행되었다는 유일한 증거는 에이전트가 그렇다고 말하는 것뿐입니다.

수치를 제시하기에 앞서, 아래의 모든 내용을 규정하는 두 가지 한계점을 먼저 짚고 넘어가겠습니다.

첫째: 확인 가능성이 곧 품질은 아닙니다. 저를 포함하여 그 누구도 확인 가능성이 낮은 지침이 더 나쁜 결과를 초래한다는 것을 입증하지 못했습니다. 입증된 결과는 더 좁은 범위이며, 제 생각에는 더 중요한 내용입니다: _그 누구도 어느 쪽이 더 나은지 판단할 수 없다_는 것입니다. 이것이 더 약한 주장이며, 더 방어 가능하고, 행동에 옮길 가치가 있는 유일한 주장입니다.

둘째: 이 지표는 의도적으로 상향 편향되어 있습니다. 모든 모호한 지침도 확인 가능한 것으로 간주됩니다. 단순히 파일 이름만 언급하거나, 단순히 명령어 단어만 포함되어 있어도 확인 가능한 것으로 집계됩니다. 아래의 모든 수치는 상한선 (ceiling) 입니다. 실제 수치는 이보다 낮습니다. 또한 이 지표는 문서만을 읽습니다. 조사된 프로젝트 중 하나는 실제 에이전트를 구동하고 등급을 매기는 별도의 평가 하네스 (eval harness)를 배포하고 있는데, 이 방법으로는 이러한 실제 강제성 (enforceability)을 포착할 수 없습니다. 문서 분석에는 측정할 수 없는 하한선이 존재합니다.

수치

8개의 컬렉션 전체를 통틀어, **확인 가능한 절차적 지침 (procedural instructions)의 중앙값은 11.1%**였습니다. 범위는 2.2%에서 22.9% 사이였습니다. 샘플 중 가장 우수한 컬렉션조차 절차적 지침의 4분의 3이 검증 불가능한 상태로 남아 있으며, 가장 열악한 컬렉션은 98%가 그렇습니다.

중앙값보다 저를 더 놀라게 한 두 가지 결과가 있습니다.

8개 컬렉션 중 5개는 출력 아티팩트 (output artifacts)를 전혀 요구하지 않습니다. "약속되었으나 누락된" 것이 아니라, 아예 아무것도 약속되지 않았습니다. 지침에서 존재를 요구하는 파일이 없습니다. 세션이 종료된 후에도 남아 있는 것이 없습니다. 리뷰어가 감사 (audit)할 수 있는 것이 아무것도 없습니다.

나머지 세 곳은 아티팩트 (artifacts) 생성을 약속합니다. 그리고 그들이 규정하는 103개의 고유한 아티팩트 중, 44개는 해당 리포지토리(repositories)의 어떤 커밋에서도 존재한 적이 없습니다. 43퍼센트입니다. 저는 이를 **유령 아티팩트 (phantom artifacts)**라고 부릅니다. 아무도 확인하지 않기 때문에 어떤 모델도 이를 건너뛰다 적발된 적이 없는 지침입니다. (검사는 현재의 트리(tree)뿐만 아니라 전체 git 히스토리를 탐색합니다. 즉, 한 번 존재했다가 삭제된 아티팩트는 유령이 아닙니다.)

따라서 이 분야는 두 가지 실패 모드로 나뉩니다. 검증 가능한 주장을 전혀 하지 않는 컬렉션과, 낙관적으로 편향된 동전 던지기 확률 정도로 주장이 실패하는 컬렉션입니다.

한 가지 장르에 대한 참고 사항을 덧붙이자면, 모든 것을 검증 가능성(checkability)으로 점수 매기는 것은 이 연구를 그르칠 수 있는 명백한 방법이기 때문입니다. 어떻게 생각할 것인가에 대한 지침 — 예: "구축하기 전에 가정을 명시하라" — 은 파일이 아닌 판단을 생성합니다. 이러한 지침은 검증 가능성이 약 0%에 가깝지만, 이는 결함이 아니라 해당 장르가 의도대로 작동하고 있는 것입니다. 헤드라인 수치들이 절차(procedure)에 대해서만 나타나는 이유도 바로 이 때문입니다.

도구

측정 도구는 kibsu입니다. 오픈 소스이며, 의존성(dependencies)이 없고, Python 3.8+ 환경에서 작동하며, 읽어들이는 리포지토리에 아무것도 쓰지 않습니다.

pip install kibsu
python -m kibsu report /path/to/any/repo

이 도구는 모든 보고서의 끝에 *"이 리포지토리에 아무것도 쓰이지 않았습니다 — 확인하려면 git status를 실행하세요"*라는 문구를 남기는데, 이 한 문장이 바로 설계 철학입니다. 리포지토리별로 고정된 SHA를 포함한 이번 조사의 가공되지 않은 증거는 다음 리포지토리에 있습니다: https://github.com/M-Bajalan/kibsu

이 도구가 공개적으로 진단한 첫 번째 리포지토리는 바로 자기 자신이었으며, 판결은 *"5개 중 0개 준비됨"*이었습니다. 자기 자신에 대한 진실을 말하며 시작한 것입니다. 저는 이 상태를 유지할 계획입니다.

다음 단계 — 그리고 제가 속임수를 쓴다면 당신이 저를 잡아내는 방법

제 개인 작업 공간의 지침 시스템은 절차(procedure)만 검증 가능한 항목이 **28.65%**로 측정되었습니다. 이는 공개 중앙값의 약 2.6배이지만, 여전히 10개 중 7개의 지침은 실패하고 있습니다. 계획은 이 도구의 자체적인 발견을 사용하여 이를 개선하고, 개선 전후를 공개하는 것입니다.

그 계획에는 명백한 공격 지점이 있습니다. 바로 _"당신은 당신 자신의 지표(metric)를 위해 최적화했다"_는 점입니다. 이는 부분적으로 옳으며 숫자로 답변할 수 없는 문제이기에, 저는 대신 용어들을 사전 등록(pre-registered)했습니다. 베이스라인(baseline)은 단 하나의 기술이 개선되기 전, SHA에 고정(pinned)되어 기록되었습니다. 예측은 다음과 같습니다: 절차(procedure)-장르 점수는 상승할 것이며, 교리(doctrine)-장르 점수는 ≈0을 유지할 것으로 예상됩니다. 왜냐하면 교리는 결과물(artifacts)이 아닌 판단(judgment)을 생성하며, 교리 점수가 상승한다는 것은 제가 지표를 조작(gamed)했음을 의미하기 때문입니다. 모든 재작성(rewrite)은 텍스트 차이(text diff)로 공개되므로, 여러분은 퍼센트(percentage)를 신뢰하는 대신 각 변경 사항을 직접 판단할 수 있습니다.

이 도구는 세 단계 중 제1막인 '진단(diagnose)'입니다. 제2막은 부족한 것들 — 즉, 어떤 에이전트라도 저장소(repository)에 처음 들어왔을 때 마지막 작업부터 바로 이어서 수행할 수 있게 해주는 지도, 인덱스(index), 로그(log), 그리고 커밋 게이트(commit gates)를 구축하는 단계입니다. 제3막은 시간이 흐름에 따라 커밋(commit) 전반에 걸쳐 이것이 효과가 있었는지 측정합니다. 자신의 효과를 스스로 측정하는 개발자 도구는 거의 없습니다. 위의 어떤 숫자보다도 바로 그 점이 핵심입니다.

이 모든 것을 공개하는 또 다른 이유가 있습니다. 제가 AI와 함께 작업하며 알게 된 모든 것은 자신이 발견한 것을 공유해 준 사람들로부터 배웠습니다. 저는 항상 커뮤니티의 학습으로부터 얻습니다. 이러한 작업 방식이 제 삶에 어떤 변화를 가져왔는지 보았을 때, 모든 사람이 이를 사용하고 그 차이를 느낄 수 있기를 바랐습니다. 이것은 제가 돌려드리는 저의 몫입니다.

_kibsu_는 '밟다'라는 뜻의 _kabāsu_에서 유래한 아카드어입니다: 뒤에 남겨진 흔적, 행동의 과정, 계산의 방식. 사전적 정의가 곧 아키텍처(architecture)가 되었습니다.

저의 지시, 통제 및 검토 하에 AI 코딩 어시스턴트(coding assistants)를 사용하여 구축되었습니다 — 커밋 트레일러(commit trailers)에 어떤 어시스턴트가 사용되었는지 기록되어 있습니다. 검증 가능한 주장(verifiable claims)에 관한 프로젝트라면 검증 불가능한 저자(author) 라인을 가져서는 안 되기 때문입니다.