문서 협업에서 AI 프롬프트를 새 작업 단위로 기록한다

코드 협업은 커밋을 기준으로 이뤄지지만, AI가 편집하는 문서에서는 프롬프트 한 번의 실행을 더 작은 작업 단위로 기록할 수 있다는 제안이다. 제안된 방식은 변경을 만든 주체와 승인한 사람, 승인 이유를 글자 단위의 변경 이력과 연결한다.

코드는 작성 중인 상태가 제대로 작동하지 않을 수 있어, 개발자는 대개 작업을 커밋으로 묶어 공유한다. 커밋은 결과를 보존하지만 작업의 이유까지 담지는 않는다. 반면 AI 에이전트는 프롬프트를 받아 코드를 수정하고 검사한 뒤 결과를 돌려준다. 이에 따르면 프롬프트 실행은 커밋보다 작으면서도, 변경 전에 작성된 설명과 실행 기록을 함께 남기는 체크포인트가 된다. 다만 에이전트의 설명은 변경을 정당화하는 자체 설명이지, 변경이 옳다는 검증은 아니다. 커밋과 협업에 관한 배경 자료로 ‘Software Is Made Between Commits’와 GitHub의 스택형 풀 리퀘스트 안내를 든다.

계약서는 코드처럼 정의된 용어와 조항 간 참조가 맞아야 하지만, 문장 자체는 편집 도중에도 읽을 수 있다. 용어를 바꾸거나 조항 번호를 고치는 동안 나머지 내용이 맞지 않을 수 있어 변호사들은 초안을 따로 작업한 뒤 수정 사항을 주고받는다. 이 글은 이메일로 오가는 수정 제안을 코드의 커밋·차이 비교·검토 과정에 빗댄다. 두 차례 검토 사이에 양쪽 초안이 달라지는 현상도 코드의 병합 충돌과 닮았다는 설명이다.

AI가 추적 변경 사항으로 수정안을 제안하면 실행 한 번을 하나의 제안 묶음으로 기록할 수 있다. 각 제안을 수락하거나 거절한 사람과 제안한 주체를 따로 남기고, 승인자와 이유도 변경된 글자에 연결한다. 기존 풀 리퀘스트에서는 작성자와 커미터를 구분하더라도 승인 정보는 코드 줄별 기록에 포함되지 않는다는 것이 글의 지적이다. AI가 만든 풀 리퀘스트 대부분에 사람의 검토 기록이 없다는 연구도 근거로 언급한다(연구 자료). 제안별로 결정을 기록하면 사람의 감독 여부를 측정할 수 있다는 주장이다.

서버가 기록하는 변경에는 그 변경이 누구를 위해 이뤄졌는지도 포함한다. 따라서 에이전트의 제안과 사람이 여러 제안을 승인한 기록이 뭉뚱그려 하나의 ‘AI’ 변경으로 처리되지 않으며, 하위 실행은 이를 시작한 실행에 포함된다. 사용자가 텍스트를 선택하면 각 부분의 작성자, 편집 시각과 버전, 대체된 단어를 확인할 수 있다. 에이전트가 쓴 문장에는 누가 승인했는지와 에이전트가 밝힌 이유도 표시한다. 이를 위해 색인기는 문단별 기록을 순서대로 재생해 글자마다 작성자를 유지한다.

에이전트는 조항을 수정하기 전에 변호사가 이전 문구를 다시 썼거나 제안을 거절한 이력을 확인할 수 있다. 도구로 조항의 변경 이력을 읽고 비슷한 제안을 하기 전에 과거의 실수를 피하도록 돕는다는 취지다.

다만 프롬프트 실행을 안전한 단위로 보려면 검사도 통과해야 한다. 계약서에는 컴파일러가 없으므로, 실행 결과를 받아들일 때 적용할 검사는 코드의 린트나 테스트보다 약하다. 글은 문서마다 유용성이 다를 수 있는 후속 영향과 의존 관계를 살피지만, 일반적으로는 경고 수준의 기록이라고 설명한다. 문단 이력도 텍스트를 자르거나 바꾸고 옮기는 상황을 완전히 처리하지 못하며, 계보 복원은 여러 단계를 거친 최선의 추정이다.

참고 자료: Nathan Sobo, ‘Software Is Made Between Commits’, ‘Stacked pull requests generally available’, Kacper Duma 외, ‘These Aren’t the Reviews You’re Looking For: How Humans Review AI-Generated Pull Requests’.