Us vs. Them, Hacker News에 등장. 인간 vs. AI 라벨은 Git ID에 달려 있다

Us vs. Them은 42점을 기록하며 Hacker News에 등장했고, 에이전트 기반 편집기가 갈수록 자주 만들어내는 갈등을 제기했다. AI는 어떤 줄을 수정하기 전에 망설여야 할까?

이 오픈소스 실험은 파일의 Git 이력을 재생해 텍스트 범위별로 인간 대 에이전트 점수를 부여한다. 문서 내부의 라벨은 필요하지 않다. 이 접근 방식은 기존 리포지토리와 이례적으로 잘 호환되지만, 그 단순함은 결정적인 의존성을 감춘다.

이 시스템은 문장이 합성된 듯한지 탐지하지 않는다. 대신 각 리비전에 연결된 신원을 신뢰하고, 이후 수정이 이전 저작에 어떤 변화를 주는지 계산한다. 따라서 핵심 대립은 인간과 모델의 대결이 아니다. 명시적인 리비전 이력과 불확실한 신원 간의 대립이다.

코딩 에이전트가 전체 리포지토리를 수정할 권한을 얻으면서 이 구분은 중요해진다. 이제 모델은 한 세션 안에서 문서, 구성, 테스트, 프로덕션 코드를 다시 작성할 수 있다. 팀은 어떤 변경을 면밀히 검토할지 결정할 때 최종 diff 이상의 정보가 필요하다.

Us vs. Them은 작지만 도발적인 제어 신호를 제안한다. 인간이 작성한 영역은 보호되는 “섬”이 되고, 기계가 작성한 영역은 다른 에이전트가 더 쉽게 교체할 수 있다. 이 아이디어는 출처 정보를 공개 라벨에서 편집 정책으로 바꾼다.

Hacker News 프로젝트가 Git 이력을 저작 점수로 전환한다

Us vs. Them은 저장된 모든 리비전을 증거로 취급하고, 이후 저자가 같은 텍스트를 수정할 때 그 증거를 계속 반영한다.

GitHub에서 eighttrigrams로 알려진 개발자는 이 프로젝트를 에이전트 기반 편집 환경의 텍스트를 위한 줄 단위 출처 추적 도구라고 설명한다. 프로젝트 리포지토리는 라이브러리와 명령줄 인터페이스를 모두 제공한다.

구현은 순서가 있는 문서 버전들의 연속으로 시작한다. 각 버전에는 인간 또는 에이전트로 분류할 수 있는 식별 가능한 작성자가 있어야 한다. 도구는 최종 텍스트만 검사하는 대신 이 버전들을 비교한다.

출력은 줄을 범위로 묶고 각 범위에 점수를 부여한다. 점수 1.00은 완전히 인간이 작성한 범위를 의미한다. 점수 0.00은 완전히 에이전트가 작성한 범위를 의미한다.

중간값은 혼합된 이력을 설명한다. 리포지토리는 에이전트가 이후 수정한 인간 기원 범위의 예로 0.46을 제시한다. 이 방식은 남아 있는 모든 줄을 이진 범주에 억지로 넣는 대신 스펙트럼을 만든다.

프로젝트는 생성된 텍스트의 “바다” 안에 있는 일관된 인간 영역을 “섬”이라고 부른다. 이 비유는 중요한 설계 결정을 반영한다. 보호되는 단위가 항상 변경되지 않은 한 줄은 아니다.

편집자는 문단을 나누거나 두 문장을 합치거나 인간이 작성한 블록의 일부를 조정할 수 있다. 엄격한 최종 편집자 규칙이라면 손댄 모든 내용을 기계 작성으로 선언할 것이다. Us vs. Them은 부분 수정 뒤에도 이전 기여의 일부를 보존하려 한다.

현재 인터페이스는 사용자가 Git 신원을 통해 작성자를 분류하도록 요구한다. --ours 인수는 인간을 지정하고, 다른 모든 신원은 에이전트로 간주한다. 반대인 --theirs 옵션은 에이전트를 지정하고 나머지 모두를 인간으로 처리한다.

사용자는 신원이 더 적은 쪽을 선택한다. 도구는 두 옵션을 함께 사용하는 것을 거부한다. 이는 명령을 간결하게 유지하지만, 분류 책임은 운영자에게 맡긴다.

동기 사례는 구체적이다. 개발자는 에이전트를 사용해 애플리케이션 대부분을 생성한 뒤 민감한 구성 요소를 직접 다시 작성할 수 있다. 다른 세션은 그 인간 통제 영역을 가볍게 교체해서는 안 된다.

문서에서도 같은 문제가 나타난다. 에이전트가 README 전체 초안을 작성한 뒤 관리자가 도입부를 신중히 다시 작성할 수 있다. 이후 에이전트는 다른 곳에서는 자유롭게 작업하되, 도입부는 의도적인 편집 판단으로 다뤄야 한다.

이는 단순한 화려한 시각화가 아니다. 점수는 에이전트, 검토 인터페이스 또는 리포지토리 검사에 제공되는 컨텍스트가 될 수 있다. 각 소비자는 기본 문서를 바꾸지 않고 서로 다른 임계값을 적용할 수 있다.

코딩 어시스턴트는 높은 점수의 범위를 편집하기 전에 경고를 받을 수 있다. pull request는 인간이 작성한 섬을 제거하는 변경을 강조할 수 있다. 검토자는 생성된 모든 줄을 똑같이 읽지 않고도 이러한 변경을 우선 검토할 수 있다.

이것이 프로젝트가 당장 만들어내는 변화다. 일반적으로 문제가 발생한 뒤에 확인하던 Git 이력이 다음 에이전트 기반 작업의 입력값이 된다.

인간 저작은 편집 권한이 되고 있다

중요한 질문은 모든 토큰의 공로가 누구에게 있는지가 아니라, 자동화된 편집이 어디에서 저항을 마주해야 하는지다.

전통적인 버전 관리 시스템은 변경을 기록하지만 그 변경에 도덕적 가치를 부여하지 않는다. 한 줄은 누가 작성했는지와 무관하게 현재 상태이거나 폐기된 상태다. 에이전트 기반 편집은 이 중립성의 운영상 의미를 바꾼다.

에이전트는 작업을 살펴보고, 파일을 선택하고, 변경을 작성하고, 테스트를 실행하고, 자신의 작업을 수정할 수 있다. 더 넓은 자율성은 수정 가능한 실수의 수를 늘린다. 동시에 검토 전에 인간의 의도가 사라질 수 있는 영역도 넓힌다.

대부분 어시스턴트가 만든 구성 파일을 생각해 보자. 엔지니어는 하나의 권한을 직접 강화하고, 경고를 추가하며, 그 제한이 존재하는 이유를 문서화할 수 있다. 이후 에이전트는 이력이 자신의 컨텍스트에 들어오지 않는 한 텍스트만 보게 된다.

일반 diff는 이후 에이전트가 무엇을 변경했는지 보여 준다. 하지만 제거된 한 줄이 의도적인 인간 예외를 나타냈다는 점을 자동으로 알리지는 않는다. 검토자는 주석, 커밋 메시지 또는 기억을 통해 그 중요성을 재구성해야 한다.

Us vs. Them은 저작 이력을 기계가 읽을 수 있는 힌트로 변환한다. 높은 인간 출처 점수가 해당 줄이 올바르다는 것을 증명하지는 않는다. 사람이 그곳에 직접 편집 노력을 들였으며 보존할 만한 판단을 담았을 수 있음을 뜻한다.

이 신호는 두 집단에 압력을 가한다. 에이전트 개발자는 지역적 의도를 존중하는 방법이 필요하고, 엔지니어링 팀은 모든 인간의 키 입력을 중심으로 리포지토리가 굳어지지 않도록 하는 정책이 필요하다.

강제되는 대응은 더 나은 변경 우선순위 지정이다. 자동화된 편집이 늘어나면 생성된 모든 수정을 같은 강도로 검토하기 어려워진다. 출처 점수는 부족한 인간의 주의를 집중시키는 한 가지 방법을 제공한다.

이 아이디어는 소스 코드 밖에도 적용된다. 정책 문서, 연구 노트, 제품 요구사항, 내부 지식 베이스는 생성된 초안과 신중하게 수정된 구절을 함께 포함하는 경우가 많다. 최종 형태는 협업 과정을 숨긴다.

제품 관리자는 에이전트의 시장 요약을 수용하되, 결정과 그 제약 조건은 직접 다시 작성할 수 있다. 다른 에이전트는 보조 설명과 승인된 결정을 구분해야 한다. 평면적인 문서는 그런 계층을 제공하지 않는다.

사람들은 이미 비공식적인 보호 장치를 만든다. “변경하지 말 것” 같은 주석을 추가하고, 파일을 분리하고, 테스트를 강화하거나, 프롬프트에 지시를 반복한다. 이러한 방법은 중요성을 전달하지만 수동 마크업이나 보조 인프라가 필요하다.

diff 기반 출처 추적은 Git이 이미 버전을 기록하기 때문에 더 낮은 마찰을 약속한다. 팀은 맞춤 문서 형식이 필요하지 않다. 기존 Markdown, 소스 파일 및 기타 일반 텍스트를 그대로 유지할 수 있다.

이 호환성은 Hacker News 프로젝트에 가장 강력한 실용적 장점을 제공한다. 많은 출처 추적 제안은 생성 시점에 새로운 메타데이터를 요구하는 것에서 시작한다. Us vs. Them은 팀이 이미 유지하는 이력에서 유용한 신호를 복원하려 한다.

이 프로젝트는 출처 인식 지식 작업으로 향하는 더 큰 변화에도 부합한다. 검색 가능한 엔지니어링 지식 베이스는 문서를 보존할 수 있지만, 검색만으로는 누가 각 구절을 다듬었는지 설명하지 못한다.

에이전트 기반 시스템에는 컨텍스트와 경계가 모두 필요하다. 컨텍스트는 에이전트에게 리포지토리에 무엇이 있는지 알려 준다. 경계는 어떤 부분이 의도적인 인간 통제를 반영하며 추가적인 주의가 필요한지 알려 준다.

생성된 텍스트는 쉽게 교체할 수 있기 때문에 이러한 압력은 지속될 가능성이 높다. 인간의 주의는 그렇지 않다. 집중된 인간의 판단을 식별하는 시스템은 더 희소한 자원을 보호하는 데 도움이 될 수 있다.

이 메커니즘은 AI 탐지를 피하지만 Git의 가정을 물려받는다

버전 이력은 작성자 신원과 편집 경로가 신뢰할 수 있을 때에만 문체보다 더 강한 증거를 제공한다.

대부분의 AI 텍스트 탐지기는 완성된 구절을 분석해 그 언어적 패턴이 모델 출력과 유사한지 추정한다. 이 접근 방식은 인간의 수정, 의역 또는 도메인 특화 글쓰기 이후 불안정해진다.

Us vs. Them은 더 좁은 질문을 던진다. 문체에서 최종 텍스트를 누가 작성했는지 추론하지 않는다. 대신 선언된 작성자가 각 영역을 도입하고 수정한 방식을 재구성한다.

이는 탐지보다 회계에 가깝다. 시스템은 거래를 관찰하고 이후 변경을 거치며 소유권 정보를 유지한다. 산문을 검사해 무엇이 이를 만들었는지 추측하지 않는다.

연구는 인간과 AI의 공동 저작을 고유한 귀속 문제로 설명한다. 광범위한 저작자 식별 조사는 인간 귀속, AI 탐지, 모델 귀속, 혼합 인간-기계 귀속을 서로 다른 과제로 구분한다.

혼합 사례는 특히 결과물만을 대상으로 하는 분류기에 어렵다. 한 문단은 모델 텍스트로 시작해 인간의 재작성, 에이전트로의 복귀, 또 다른 인간 수정의 과정을 거칠 수 있다. 최종 문체는 그 순서를 신뢰성 있게 드러낼 수 없다.

각 관련 상태가 커밋되었다는 가정하에, 버전 이력은 그 순서를 보존한다. 또한 설명 가능한 경로를 제공한다. 검토자는 분류기의 불투명한 확률을 신뢰하는 대신 점수 뒤에 있는 리비전을 확인할 수 있다.

프로젝트의 범위 모델은 또 다른 계층을 추가한다. 단순한 줄 귀속은 흔히 각 줄을 마지막으로 건드린 커밋을 식별한다. 반면 Us vs. Them은 일관된 영역, 분할, 병합, 희석된 저작을 고려하려 한다.

Git 자체의 blame 문서는 이것이 왜 복잡해지는지 보여 준다. Git은 파일 내에서 이동한 줄이나 파일 간에 복사된 줄을 탐지하기 위한 별도 옵션을 제공한다. 이러한 작업에는 유사성 임계값이 필요하며, 그 자체로 창작 기원을 확정할 수는 없다.

diff는 삭제와 삽입을 본다. 에이전트가 인간의 아이디어를 유지하면서 구문을 다시 작성했는지는 이해하지 못한다. 어떤 수치형 출처 추적 시스템이든 텍스트 유사성을 저작 규칙으로 변환해야 한다.

한 사람이 네 줄짜리 안전 검사를 작성했다고 가정해 보자. 에이전트는 목적을 바꾸지 않은 채 변수 이름을 바꾸고 조건을 재구성한다. 한 정책은 의도가 살아남았으므로 상당한 인간 출처를 보존할 수 있다.

다른 정책은 표면 텍스트가 바뀌었으므로 저작 대부분을 에이전트에 부여할 수 있다. 어느 쪽도 Git에서 자동으로 따라 나오지 않는다. 점수 산정 알고리즘은 변환을 거치며 기여가 어떻게 살아남는지에 대한 판단을 인코딩한다.

에이전트가 인간의 문단을 변경 없이 이동할 때도 같은 모호성이 나타난다. 위치 기반 접근은 그 이력을 잃을 수 있다. 이동 인식 접근은 이를 보존할 수 있지만, 매칭이 복사된 구절을 인식하는 경우에만 가능하다.

짧은 줄도 또 다른 과제다. “Security Requirements” 같은 제목은 신뢰할 수 있는 유사성 분석에 텍스트가 너무 적다. 그러나 그 위치와 주변 구조는 중요한 인간의 결정을 나타낼 수 있다.

생성된 자료는 인간의 콘텐츠를 흡수할 수도 있다. 에이전트는 인간의 세 문장을 가져와 열 문장으로 확장할 수 있다. 그 결과 범위에는 인간의 방향성, 기계의 표현, 그리고 새로운 주장까지 포함될 수 있다.

Us vs. Them은 희석이라는 개념을 통해 이를 인정한다. 중간 점수는 확실성보다는 혼합된 이력을 나타낸다. 이는 합리적이지만, 사용자는 각 변환이 수치를 어떻게 바꾸는지 여전히 알아야 한다.

0.46 같은 점수는 정밀해 보인다. 그 실질적 의미는 알고리즘, 임곗값, 사용 가능한 커밋에 따라 달라진다. 팀은 이를 창작 소유권에 대한 법의학적 측정치가 아니라 정책 신호로 다뤄야 한다.

이 구분은 프로젝트의 유용한 기여를 보호한다. diff 기반 출처 추적이 에이전트 행동을 개선하기 위해 법적 저작자성을 판정할 필요는 없다. 주의가 필요한 영역을 식별하기만 하면 된다.

인간 vs. AI 출처 추적에서 커밋 신원은 가장 취약한 고리다

이 도구는 선언된 저작자 정보를 추적할 수 있지만, 선언된 인간이 실제로 해당 수정본을 작성했는지는 독립적으로 검증할 수 없다.

Git 커밋에는 author와 committer 필드가 포함된다. 이 필드는 이력을 재구성하는 데 도움이 되지만, 일반적인 저장소는 명시된 신원이 변경 뒤의 키보드 사용자나 모델과 일치한다는 보장을 제공하지 않는다.

에이전트는 개발자의 로컬 계정을 통해 작업할 수 있다. Git 설정에서 해당 값이 왔기 때문에 커밋에는 개발자의 이름과 이메일이 기록될 수 있다. Us vs. Them은 구성된 신원에 따라 해당 수정본을 분류한다.

반대의 경우도 일어날 수 있다. 사람이 자동화 계정을 통해 수정하면 인간이 만든 수정 사항이 봇 신원으로 나타날 수 있다. 그 결과 점수는 인간의 관여를 과소평가하게 된다.

공유 세션은 경계를 더욱 불분명하게 만든다. 사람이 에이전트에게 패치를 요청하고, 여러 줄을 수정한 뒤, 결합된 결과를 한 번에 커밋할 수 있다. 커밋 신원은 혼합된 프로세스에 단일 저작자만 기록한다.

Git은 공동 저자 trailer를 지원하지만, 이는 커밋 수준의 선언이다. 별도의 기여자를 특정 줄에 매핑하지는 않는다. 또한 참여자가 협업 내용을 정확히 기록하는 데 의존한다.

서명된 커밋은 특정 키가 Git 객체를 승인했다는 보증을 강화한다. GitHub는 signed commits가 암호학적 서명과 연결된 신원을 바탕으로 검증을 받는다고 문서화한다.

유효한 서명도 수동으로 작성되었다는 증거는 아니다. 개발자는 검토 후 에이전트가 만든 패치에 서명할 수 있다. 이 서명은 승인과 무결성을 확립할 뿐, 모든 줄의 물리적 기원을 증명하지는 않는다.

이 한계는 핵심적인 대립 구도를 명확히 한다. 이력이 신뢰할 수 있다면 명시적 이력은 문체 추정보다 낫다. 신원이 불확실하면 점수 알고리즘이 시작되기도 전에 전체 사슬이 약화된다.

누락된 이력은 두 번째 약점을 만든다. 일부 팀은 여러 수정본을 하나의 커밋으로 스쿼시한다. 다른 팀은 모델 출력을 붙여넣고 로컬에서 편집한 뒤 최종 상태만 저장한다.

두 경우 모두 중간 협업 과정은 사라진다. 도구는 살아남은 버전만 분석할 수 있다. 따라서 깔끔한 선형 이력이 작은 커밋이 이어진 지저분한 시퀀스보다 출처 정보를 덜 제공할 수 있다.

리베이스는 커밋 구조를 다시 작성할 수 있고, 체리픽은 새 메타데이터 아래에서 변경을 복제할 수 있다. 저장소 가져오기는 이전 개발 이력을 하나의 초기 스냅샷으로 합칠 수 있다. 파일 생성 역시 유용한 중간 상태를 보존하지 않은 채 콘텐츠를 덮어쓸 수 있다.

이는 드문 엣지 케이스가 아니다. 팀은 읽기 쉬운 이력을 유지하기 위해 일상적으로 pull request를 스쿼시한다. 에이전트 기반 워크플로는 개별 커밋을 받지 못하는 임시 변경을 자주 만든다.

프로젝트의 분류 옵션은 세 번째 약점을 드러낸다. 지정된 쪽에 배치되지 않은 모든 신원은 반대 분류를 받는다. 알려지지 않은 계약자, 통합 또는 잘못 구성된 계정이 조용히 잘못된 레이블을 받을 수 있다.

이 이진 설정은 프로토타입에는 편리하다. 운영 환경에서는 unknown 상태가 유용할 것이다. 증거가 불완전할 때 미분류 저작자를 자동으로 인간이나 에이전트로 분류해서는 안 된다.

성숙한 정책에는 최소 네 가지 범주가 필요할 수 있다. 검증된 인간, 선언된 에이전트, 혼합 세션, 그리고 unknown이다. 승인은 저작자성과 분리된 상태로 남을 수 있다. 그러면 검토된 에이전트 변경이 사람이 직접 작성한 텍스트처럼 보이는 일을 막을 수 있다.

취약한 인간 작업을 과도하게 보호할 위험도 있다. 출처 점수는 정확성이 아니라 기여 이력을 측정한다. 인간이 작성한 코드에도 결함, 오래된 가정, 보안에 취약한 패턴이 포함될 수 있다.

에이전트는 높은 점수의 범위에서 망설여야 하지만, 그 범위를 신성불가침으로 취급해서는 안 된다. 적절한 대응은 검토를 요청하거나, 더 강한 근거를 제시하거나, 명확한 설명과 함께 변경을 제안하는 것일 수 있다.

반대로 낮은 점수의 텍스트도 버려도 되는 것은 아니다. 에이전트가 생성한 마이그레이션, 테스트 또는 컴플라이언스 문구는 배포 후 운영상 중요해질 수 있다. 런타임 의존성과 검토자 승인은 초기 저작자성보다 더 큰 비중을 가질 수 있다.

따라서 팀에는 여러 신호가 필요하다. 출처 정보는 소유권 규칙, 테스트 커버리지, 보안 민감도, 최근 사고, 명시적 승인과 함께 활용될 수 있다. 단일 점수로 수정 진행 여부를 결정해서는 안 된다.

프로젝트의 가장 강력한 프레이밍은 자문적 도구라는 점이다. 인간 기여가 집중된 영역을 드러내고 다른 검토 행동을 유발할 수 있다. 그 출력을 기원의 증거로 제시하는 것은 저장소 이력이 확립하는 범위를 넘어선다.

진짜 경쟁은 이력 기반 제어와 내장 메타데이터 사이에 있다

Us vs. Them은 도입 마찰 측면에서 우위에 있지만, 더 풍부한 출처 시스템은 신원, 맥락, 이식성 측면에서 우위에 있다.

이력 기반 출처 추적은 추적되는 파일에 특별한 마크업을 요구하지 않는다. 이는 일반 텍스트를 보존하고 문서를 기존 편집기, 렌더러, 저장소와 호환되게 한다.

이 접근 방식은 소급 적용도 가능하다. 이력과 신원이 남아 있다면 팀은 이미 구축된 프로젝트를 분석할 수 있다. 모든 기여자가 먼저 특수한 저작 도구를 설치할 필요가 없다.

내장 메타데이터는 반대의 경로를 택한다. 편집기나 에이전트는 작업이 일어나는 순간 각 블록을 누가 생성, 수락, 수정 또는 승인했는지 기록할 수 있다. 이는 나중의 diff로는 재구성할 수 없는 세부 정보를 포착한다.

비용은 통합에 있다. 메타데이터에는 스키마, 저장 위치, 신원 모델, 시스템 간 콘텐츠 복사 규칙이 필요하다. 사용자가 텍스트를 내보내거나 병합하거나 붙여넣을 때 도구가 이를 보존해야 한다.

인라인 마크업은 소스 파일을 어지럽힐 수도 있다. 모든 블록이 저작자 태그를 지니면 Markdown 문서는 일부 단순함을 잃는다. 사이드카 파일은 시각적 잡음을 피하지만, 설명 대상 콘텐츠와 분리될 수 있다.

Us vs. Them은 완전성보다 호환성을 선택한다. “no markup” 제약은 즉각적인 실험을 가능하게 한다. 동시에 텍스트가 바뀔 때마다 시스템이 연속성을 추론해야 함을 의미한다.

이벤트 기반 출처 추적은 저작자 신원 이상의 정보를 기록할 수 있다. 모델, 프롬프트 맥락, 승인 작업, 소스 자료, 도구 호출, 검토자를 포착할 수 있다. 이러한 세부 정보는 에이전트가 변경을 만든 이유를 설명하는 데 도움이 된다.

그러나 더 많은 메타데이터가 더 많은 신뢰를 보장하지는 않는다. 에이전트는 자신의 활동을 잘못 표기할 수 있고, 통합은 이벤트를 누락할 수 있으며, 사용자는 계측된 편집기를 우회할 수 있다. 출처 정보는 포착 경로의 신뢰성만큼만 신뢰할 수 있다.

결합 모델이 가장 신뢰할 만한 방향을 제시한다. Git 이력은 독립적인 구조적 기록을 제공하고, 서명된 에이전트 이벤트는 더 풍부한 생성 데이터를 제공할 수 있다. 두 기록 간 차이는 검토를 유발할 수 있다.

예를 들어 에이전트 플랫폼은 전용의 서명된 신원으로 커밋을 만들 수 있다. 생성된 파일과 인간이 승인한 범위를 설명하는 기계 판독 가능 명세를 첨부할 수 있다. 저장소에는 최종 텍스트와 선언된 프로세스가 모두 남는다.

해당 플랫폼 외부에서 이루어진 인간 편집은 여전히 일반 이력을 통해 나타난다. diff 기반 계층은 그 출처 정보를 계속 전달할 수 있다. 알 수 없거나 충돌하는 이벤트에는 강제 레이블 대신 낮은 신뢰도가 부여된다.

이 아키텍처는 점수를 단일 저작자성 수치에서 여러 차원으로 바꾼다. 한 범위는 높은 인간 기여도, 확인된 에이전트 수정, 명시적인 인간 승인을 동시에 가질 수 있다.

이 차원들은 서로 다른 질문에 답한다. 기여도는 누가 텍스트를 형성했는지를 묻는다. 승인은 누가 책임을 수락했는지를 묻는다. 무결성은 서명 이후 기록이 변경되었는지를 묻는다.

엔지니어링 팀에서는 승인이 작성 자체보다 더 중요할 때가 많다. 모델은 자격을 갖춘 관리자가 면밀히 검토한 올바른 코드를 생성할 수 있다. 인간 역시 의미 있는 검토 없이 안전하지 않은 코드를 작성할 수 있다.

작성자와 연구자에게는 기여도가 더 중요할 수 있다. 인간 편집 후에도 어떤 구절이 모델에서 비롯됐는지 공개해야 할 수 있다. 버전 인식 시스템은 하나의 최종 레이블보다 그러한 협업을 더 정확하게 보여줄 수 있다.

조직에는 보존성과 이식성이 핵심이 된다. 하나의 에이전트 플랫폼 안에만 저장된 출처 정보는 조직이 도구를 바꿀 때 사라진다. Git에서 파생된 기록은 저장소가 이동하는 곳 어디서나 계속 사용할 수 있다.

이 때문에 Us vs. Them은 완전한 출처 플랫폼이라기보다 유용한 기준선에 가깝다. 일반적인 버전 이력에서 얼마나 많은 정책을 도출할 수 있는지 보여준다. 동시에 버전 이력이 결코 포착하지 못한 정보도 드러낸다.

Hacker News 독자가 다음으로 주목해야 할 점

프로젝트의 가치는 세 가지 신호, 즉 점수 테스트, 에이전트 통합, 더 강력한 신원 처리에 달려 있다.

첫 번째 신호는 저장소가 실제 편집 패턴에 대한 동작 테스트를 확장하는지 여부다. 프로젝트는 이미 독자에게 알고리즘을 가장 명확하게 설명하는 자료로 테스트를 안내하고 있다.

다음으로 유용한 사례에는 문단 재작성, 블록 순서 변경, 섹션 복사, 스쿼시 병합, 생성된 파일, 인간과 에이전트의 교대 편집이 포함된다. 예상 점수를 공개하면 시스템을 더 쉽게 평가할 수 있다.

독립 사용자들이 출력을 예측하고 재현할 수 있다면 이 신호는 프로젝트를 강화할 것이다. 사소한 서식 변경으로 점수가 크게 바뀐다면, 일관된 저작자성이 일반적인 편집을 거쳐 유지된다는 주장은 약화될 것이다.

두 번째 신호는 실제 코딩 에이전트나 검토 워크플로와의 통합이다. 명령줄 보고서는 점수를 계산할 수 있음을 증명한다. 그러나 그 정보가 에이전트 행동을 바꾸는지는 보여주지 않는다.

실용적인 실험으로는 에이전트가 임곗값을 넘는 범위를 수정하기 전에 확인을 요청하게 할 수 있다. 또 다른 실험은 변경이 높은 출처 점수의 영역을 제거할 때 pull request 검토의 우선순위를 높일 수 있다.

성공은 스크린샷이 아니라 결과로 측정해야 한다. 유용한 지표에는 되돌린 수정, 검토자 수정, 놓친 결함, 불필요한 승인 요청이 포함된다.

경고가 너무 많으면 출처 피로를 유발한다. 너무 적으면 시스템은 장식적 존재가 된다. 최적의 임곗값은 저장소와 각 파일의 민감도에 따라 달라질 가능성이 크다.

세 번째 신호는 allowlist를 넘어서는 신원 모델이다. 전용 에이전트 신원, 서명된 커밋, 혼합 세션 레이블, 명시적인 unknown 상태는 프로젝트의 가장 중요한 한계를 해결할 수 있다.

이 변경은 알고리즘에 입력되는 증거를 개선하므로 이력 기반 출처 추적을 강화할 것이다. 이것이 없다면, 점점 더 유능해지는 에이전트는 계속 인간 계정을 통해 커밋하고 그 구분을 지워버릴 수 있다.

범위를 내보내는 공개 형식도 중요하다. 다른 에이전트와 검토 도구에는 결과를 소비할 안정적인 방식이 필요하다. 이식 가능한 사이드카는 일반 텍스트를 보존하면서 하나의 명령에 대한 의존을 피할 수 있다.

더 넓은 교훈은 이미 분명하다. AI 출처 정보는 문서에 레이블을 장식처럼 붙이는 데 그치지 않고 의사결정을 이끌 때 더 유용해진다.

개발자에게 그 결정은 에이전트가 한 줄을 자동으로 수정할 수 있는지 여부다. 검토자에게는 어디에 주의를 기울일지의 문제다. 조직에게는 어떤 변경에 책임 있는 인간의 승인이 필요한지의 문제다.

Us vs. Them은 이러한 거버넌스 문제를 해결하지는 않는다. 대신 이미 많은 팀이 사용하는 인프라에서 도출한 구체적인 입력을 제공한다.

이 접근 방식은 여전히 불완전한 커밋, 공유된 신원, 모호한 재작성에 취약하다. 이러한 한계는 처음부터 도입 방식을 좌우해야 한다. 점수는 검토를 시작하게 해야지, 끝내서는 안 된다.

에이전트가 수정한 리포지터리를 관리한다면 파일 하나의 이력을 살펴보고, 실제로 인간의 판단이 어디에 남아 있는지 파악하라. 그런 다음 다음 에이전트가 그 경계를 볼 수 있는지 물어보라.

이 연습은 최종 문장이 “AI가 작성한 것처럼 보이는지”를 논하는 것보다 더 많은 것을 보여준다. Hacker News 토론은 더 나은 질문을 제시한다. 당신의 편집 시스템은 인간의 의도를 존중할 만큼 충분한 증거를 보존하는가?