12 도구와 관행의 재발견

버전 관리, 지속 통합, 문서화, 오픈소스 협업. 사람들의 협업을 위해 만들어진 도구와 관행이 에이전트가 끼어든 루프에서 새 역할을 얻는다. 이 장은 그 역할 전환을 다룬다.

12.1 버전 관리: 이력에서 안전망으로

집필 상태

초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.

브리프. Git이 협업 도구로 만들어졌던 역사적 배경과, 에이전트 코딩에서 그 쓰임이 커밋 단위의 실험 되돌리기로 이동하는 현상을 대조하는 꼭지다. Git의 출현 연도나 창시 서사는 확정된 것만 쓰고 나머지는 조사 지시로 넘긴다. 3단 구조로 쓴다. 먼저 버전 관리 시스템의 역사, 특히 분산 모델로의 전환이 협업 문제를 해결하기 위한 것이었다는 통상적 서사를 검증 가능한 만큼만 확인한다. 다음으로 에이전트 워크플로에서 커밋과 브랜치와 워크트리가 안전망으로 쓰이는 최근 관행을 사례로 모은다. 마지막으로 여러 사람의 병렬 작업을 조정하는 도구에서 한 사람이 에이전트의 실험을 되돌리는 도구로 쓰임이 이동했을 때 Git 설계의 어떤 속성이 여전히 유효하고 어떤 속성이 과잉인지 논증한다.

시드 질문

Git이 만들어진 역사적 배경에 대해 확정적으로 말할 수 있는 사실은 무엇이고, 정확한 연도나 세부 서사 중 확인이 필요한 부분은 무엇인가? (원전 확인, 연도는 함부로 단정하지 말 것)
버전 관리 시스템이 애초에 해결하려 한 문제, 즉 여러 사람의 동시 편집 충돌과 이력 추적은 에이전트 코딩에서 실제로 관찰되는 쓰임, 즉 에이전트가 코드를 망쳤을 때 되돌리기와 얼마나 겹치는가?
에이전트에게 자주 커밋하게 하라거나 체크포인트마다 커밋을 만들라는 실무 조언이 도구 문서나 실무자 글에서 언제, 어떤 형태로 등장했는가? (재발견 사례 수집)
여러 에이전트가 동시에 다른 워크트리에서 작업하는 관행은 Git이 원래 지원하려 한 여러 사람의 병렬 작업과, 한 사람이 여러 에이전트의 병렬 작업을 조정하는 것 사이에서 어느 쪽에 더 가까운가?
커밋 메시지나 리뷰용 diff처럼 사람이 사람에게 설명하기 위한 Git의 협업 관행이 에이전트가 커밋을 생성하는 상황에서는 어떤 형태로 바뀌는가, 사람 독자를 여전히 전제하는가 아니면 다른 에이전트나 자기 자신을 위한 기록으로 바뀌는가?
버전 관리 이전 시대의 문제, 즉 공유 파일이나 잠금 기반 시스템의 충돌 문제가 에이전트의 통제되지 않은 대량 수정에서 재현되는가? (재발견 사례 수집)

조사 포인터

Git 공식 역사 문서, 초기 발표 자료(정확한 날짜와 경위는 확인할 것, 기억으로 단정 금지)
에이전트 코딩 도구의 커밋과 체크포인트 관련 공식 문서
git worktree, 브랜치 전략에 관한 실무자 글
이 책 §5.5(되돌릴 수 있게)와 역할 분담. 그 꼭지는 실무 기법에, 이 꼭지는 도구의 역사적 쓰임 변화에 집중

12.2 CI/CD와 게이트: 사람 없는 루프의 검문소

집필 상태

초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.

브리프. 지속적 통합의 원래 논거를 사람 리뷰어가 매 커밋을 볼 수 없는 에이전트 생성 코드 시대에 CI 게이트가 사실상 유일한 자동 검문소가 되는 현상과 대조하는 꼭지다. 3단 구조로 쓴다. 먼저 CI/CD의 원래 논거, 즉 빈번한 통합이 통합 지옥을 방지한다는 관행과 배포 파이프라인 자동화가 조직 성과와 상관관계를 갖는다는 실증 결과를 정확히 읽는다. 다음으로 에이전트가 생성한 코드에 대해 CI를 최후 방어선으로 쓰는 실무 관행을 사례로 모은다. 마지막으로 사람이 커밋하고 사람이 실패를 해석한다는 CI의 전제가 에이전트가 커밋하고 실패도 스스로 해석하는 루프로 바뀌었을 때 무엇이 달라지는지 논증한다.

시드 질문

Fowler가 CI에 관한 글에서 제시한 핵심 관행, 즉 하루에 여러 번 통합하고 자동화된 빌드로 통합을 검증하는 관행의 정확한 내용은 무엇인가? (원전 확인)
Humble과 Farley가 “Continuous Delivery”(2010)에서 제시한 배포 파이프라인 개념과, Forsgren 등이 “Accelerate”(2018)에서 실증한 배포 빈도와 안정성의 상관관계는 핵심적으로 무엇을 보였나? (원전 확인)
에이전트가 코드를 작성하고 커밋하고 CI가 실패하면 로그를 읽고 스스로 고치는 워크플로가 실무에서 얼마나 정착되어 있는가, 이를 명시적으로 다루는 도구 문서나 사례가 있는가? (재발견 사례 수집)
CI가 원래 전제한 테스트 실패가 사람에게 신호를 보내 사람이 원인을 진단하는 구조에서, 에이전트가 신호도 받고 진단도 하는 구조로 바뀌었을 때 CI 게이트의 설계, 즉 무엇을 테스트할지와 얼마나 엄격하게 막을지는 어떻게 달라져야 하는가?
높은 성과 조직은 배포 빈도가 높다는 Accelerate의 결과가 에이전트 생성 코드로 배포 빈도가 크게 높아진 상황에서도 같은 방향으로 성립하는가, 아니면 배포 빈도만 높고 안정성은 떨어지는 역전이 관찰되는가? (재발견 사례 수집)
CI 게이트를 우회하거나 통과만을 목표로 코드를 조작하는 에이전트의 실패 사례가 보고된 적이 있는가?

조사 포인터

Martin Fowler의 CI 관련 글(원제와 요지 확인)
Humble·Farley, “Continuous Delivery”(2010) 원문
Forsgren·Humble·Kim, “Accelerate”(2018) 원문의 핵심 지표(배포 빈도, 리드타임, 변경 실패율, 복구 시간)
이 책 §8.3(검증 비대칭), §5.4(검증 가능한 단위 만들기)와의 접점, 역할 중복 피할 것

12.3 문서화: 리터레이트 프로그래밍에서 CLAUDE.md까지

집필 상태

초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.

브리프. Knuth(1984)의 리터레이트 프로그래밍이 제시한 이상, 즉 코드를 사람이 읽는 설명적 산문과 함께 짜야 한다는 논거를 AGENTS.md와 CLAUDE.md류 파일이 만드는 새로운 문서화 장르와 대조하는 꼭지다. 3단 구조로 쓴다. 먼저 Knuth의 이상, 즉 WEB 시스템과 프로그램은 사람에게 설명하기 위해 쓰여야 한다는 원문의 취지를 정확히 읽는다. 다음으로 AGENTS.md와 CLAUDE.md라는 새 관행이 언제 어떻게 표준화되었는지 사례를 모은다. 마지막으로 문서의 독자가 사람에서 AI로 바뀌었을 때 Knuth가 강조한 설명의 서사성과 코드와 산문의 통합 중 무엇이 남고 무엇이 무의미해지는지 논증한다.

시드 질문

Knuth가 “Literate Programming”(1984)에서 제시한 핵심 주장, 즉 프로그램을 사람에게 설명하는 문학 작품으로 취급해야 한다는 논거의 정확한 표현과 근거는 무엇인가? (원전 확인)
Knuth의 WEB 시스템이 실제로 어떻게 작동했는지, 코드와 설명 산문을 어떤 순서로 섞어 짜고 사람이 읽는 문서와 컴파일 가능한 코드라는 두 산출물로 어떻게 나뉘어 나오는지 정확히 확인할 것 (원전 확인)
AGENTS.md, CLAUDE.md 같은 파일이 AI 에이전트가 읽는 프로젝트 설명서로 정착한 것은 언제부터, 어떤 도구나 관행에서 시작되었는가? (재발견 사례 수집, 확인 안 되면 조사 지시로 남길 것)
Knuth의 리터레이트 프로그래밍은 코드와 설명을 물리적으로 한 파일에 섞어 짜는 것이 핵심이었는데, AGENTS.md류는 코드와 분리된 별도 파일이다. 이 물리적 분리가 서사의 순서가 코드의 실행 순서를 따를 필요가 없다는 Knuth의 논거와 양립하는가, 아니면 정반대의 설계인가?
리터레이트 프로그래밍이 실무에서 널리 채택되지 못한 이유로 흔히 꼽히는 것들(도구 부족, 유지보수 부담 등)이 AGENTS.md류 문서에서는 어떻게 회피되거나 똑같이 재현되는가?
AI가 스스로 자신이 읽을 AGENTS.md를 생성하거나 갱신하는 관행이 있다면, 이것은 사람이 사람을 위해 설명한다는 리터레이트 프로그래밍의 저자성 전제를 어떻게 바꾸는가?

조사 포인터

Knuth, “Literate Programming”(1984), The Computer Journal 게재 원문
AGENTS.md 표준화 관련 공지나 발표(여러 도구가 공통으로 채택하게 된 경위, 정확한 시점은 확인할 것)
Claude Code, Cursor 등의 CLAUDE.md·AGENTS.md 공식 문서
이 책 §5.3(컨텍스트 관리의 기술)과 역할 분담. 그 꼭지는 실무 기법에, 이 꼭지는 문서화 장르의 역사적 계보에 집중

12.4 오픈소스 협업 모델: 성당, 시장, 에이전트

집필 상태

초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.

브리프. Raymond의 “The Cathedral and the Bazaar”(에세이 1997, 책 1999)가 제시한 성당 모델과 시장 모델의 대비, 그리고 충분히 많은 눈이 있으면 모든 버그는 얕다는 명제를 AI 기여자가 오픈소스 프로젝트에 대량으로 등장하는 최근 현상과 대조하는 꼭지다. 3단 구조로 쓴다. 먼저 Raymond의 원래 논거, 즉 리누스의 법칙과 초기 공개와 빈번한 릴리스와 사용자를 공동 개발자로 대우하기를 정확히 읽는다. 다음으로 AI가 생성한 이슈 트리아지나 PR이 오픈소스 프로젝트의 리뷰 병목과 신뢰 문제를 어떻게 바꾸는지 사례를 모은다. 마지막으로 눈이 많으면 버그가 얕다는 명제가 그 눈이 사람이 아니라 AI일 때도 성립하는지, 신뢰라는 시장 모델의 숨은 전제가 AI 기여자 앞에서 무너지는지 논증한다.

시드 질문

Raymond가 “The Cathedral and the Bazaar”에서 제시한 리누스의 법칙, 즉 충분히 많은 눈이 있으면 모든 버그는 얕다는 명제의 정확한 원문 표현과, 이를 뒷받침하기 위해 든 근거는 무엇이었나? (원전 확인)
Raymond가 시장 모델의 성립 조건으로 제시한 것들, 즉 잦은 릴리스와 사용자를 공동 개발자로 대우하기와 프로젝트 리더의 조정 역할은 정확히 무엇이었나, 그중 이것 없이는 시장 모델이 작동하지 않는다고 명시한 전제 조건이 있었는가? (원전 확인)
대량의 AI 생성 PR이나 이슈가 오픈소스 프로젝트에 쏟아지는 현상이 실제로 보고된 사례나 메인테이너들의 공개 대응 정책이 있는가? (재발견 사례 수집)
충분히 많은 눈이 사람이 아니라 AI 리뷰어나 AI 기여자로 채워질 때, Raymond가 전제한 눈의 자격, 즉 신뢰할 만한 판단력과 프로젝트에 대한 이해가 여전히 성립하는가, 아니면 눈의 숫자만 늘고 질은 떨어지는 역전이 관찰되는가?
오픈소스 메인테이너들이 AI 생성 기여를 다루기 위해 새로 도입한 정책, 예를 들어 기여 가이드라인 변경이나 자동 라벨링이나 AI 기여 공개 의무화의 구체적 사례를 얼마나 찾을 수 있는가? (재발견 사례 수집)
Raymond의 성당 모델, 즉 소수의 신뢰받는 개발자가 폐쇄적으로 개발하는 방식이 AI 시대에 오히려 재평가받는 흐름이 있는가, 있다면 시장 모델의 위기에 대한 반작용으로 볼 수 있는가?

조사 포인터

Raymond, “The Cathedral and the Bazaar”(에세이 1997, 책 1999) 원문
주요 오픈소스 프로젝트의 AI 기여 관련 공개 정책 문서, 메인테이너 블로그
이 책 9장(한계와 리스크) 관련 꼭지, §12.3(문서화)과의 접점
AI slop 관련 논의는 개념 사전 G13(slop/workslop)과 역할 분담, 이 꼭지는 오픈소스 협업 모델 자체에 집중