한 달간의 80개 커밋은 모두 Claude와의 공동 저작이었습니다. 모델별로 세어보니, 차이는 리포지토리의 차이였습니다

9월 1일부터 10월 3일까지, 제 WordPress 플러그인 5개의 리포지토리에 들어간 커밋은 80건이었습니다. 80건 모두 끝에 이 줄이 있습니다.

Co-Authored-By: Claude Opus 5 <[email protected]>

괄호 안의 모델명은 도중에 3번 바뀌었습니다.

한 달 동안 모델이 3세대에 걸쳐 교체되었음에도, 배포는 멈추지 않았습니다. 그렇다면, 모델이 바뀌면서 무엇이 달라졌을까요? 커밋을 세어 비교해 보니, 차이로 보였던 것들의 대부분은 모델의 차이가 아니었습니다.

커밋의 형태는 거의 동일했습니다

80건을 변함없이 이어져 온 습관에서 계산했습니다.

1.4.19: deleted means gone
deleteAttachment() asks get_post() after wp_delete_attachment(): a
pre_delete_attachment answering with the post deletes nothing, and a null
...

변경 이력을 같은 커밋으로 다시 쓰는 것은 사용자에게 무엇이 바뀌었는지를 전달하기 위함입니다. 커밋 메시지는 개발자용이고, readme의 변경 이력은 사용자용으로, 같은 수정 사항을 두 번, 다른 대상을 향해 작성하고 있습니다.

모델별로 나누어 보니 차이가 보이는 것 같습니다

같은 계산 방식을 모델별로 해보았습니다.

| 모델 | 커밋 | readme 업데이트 | tests 업데이트 | 제목이 버전 번호에서 |
|---|---|
| Opus 4.8 | 9 | 8 | 0 |
| Opus 5 | 47 | 28 | 12 | 18 |
| Opus 5.5 | 24 | 24 | 18 | 23 |

Opus 4.8은 테스트를 단 한 건도 업데이트하지 않았고, Opus 5.5는 4건에 3건을 업데이트했습니다. 새로운 모델일수록 테스트를 작성하게 되었다고 읽히는 표입니다.

리포지토리별로 나누어 보니 차이는 사라집니다

같은 80건을 리포지토리와 모델로 나누었습니다.

| 리포지토리 | tests/ 유무 | Opus 4.8 | Opus 5 | Opus 5.5 |
|---|---|
| Rapls AI Chatbot | 없음 | 7 | 9 | 3 |
| Prime Cache | 없음 | 2 | 2 | 2 |
| Rapls Passkey | 있음 | 0 | 7 | 0 |
| Rapls PDF Image Creator | 있음 | 0 | 26 | 19 |
| Rapls Sitemap | 있음 | 0 | 3 | 0 |

Opus 4.8의 커밋 9건 모두, tests/ 디렉토리가 없는 2개의 리포지토리에 있었습니다. 테스트를 업데이트할 필요가 없었습니다. Opus 5.5의 24건 중 19건은, 테스트를 가지고 있는 PDF Image Creator였습니다.

테스트를 업데이트했는지 여부는 모델이 아니라, 그 리포지토리에 테스트를 둘 공간이 있는지에 달려 있었습니다. 9월 후반기는 PDF Image Creator의 수정이 계속된 시기였고, 그 시기에 마침 Opus 5.5가 사용되었습니다. 표의 차이는 그 중첩이었습니다.

이 80건만으로는, 모델의 차이와 리포지토리의 차이를 분리할 수 없습니다. 같은 리포지토리에서, 같은 시기에, 모델만 바꿔서 비교해 본 적이 없기 때문입니다.

변하지 않은 것은 모델 밖에 있는 것입니다

반대로, 모델이 바뀌어도 계속되었던 것은 무엇일까요? 기록을 통해 알 수 있는 것은 업무 흐름 쪽입니다.

오류 보고는 WordPress.org 포럼이나 메일로 도착합니다. 그것을 claude.ai 채팅으로 가져가 코드를 읽게 하고, 원인과 해결 방법을 '인계서'에 정리합니다. 그 인계서를 Claude Code에 넘겨 구현과 커밋을 시킵니다.

9월 15일의 예입니다. 채팅 답변 아래에 나오는 참조 카드가 무관한 페이지를 가리킨다는 보고가 포럼에 올라왔습니다. 저는 채팅으로 소스를 읽고, 벡터 검색 결과에 플래그가 걸리지 않는 것을 확인하여 차이점과 확인할 항목을 적은 인수인계서를 작성했습니다. 그날 17시 32분에 Opus 4.8과의 공동 저작으로 1.19.5 커밋이 들어갔습니다.

당시의 인수인계서에는 증상, 원인 부분(파일과 행), 수정할 곳과 수정하지 않을 곳, 확인할 항목, 변경 이력 문안 초안 등이 포함되어 있었습니다. 전달하는 것의 형태가 모델에 관계없이 동일하다면, 나오는 커밋의 형태도 일관됩니다. 표의 첫 번째 항목에서 습관이 통일된 것은 그 때문일 수 있습니다. 다만, 이는 추측이며 인수인계서를 사용하지 않았을 경우와 비교한 것은 아닙니다.

기록에 남지 않은 부분

커밋 공동 저작 행은 AI가 해당 커밋에 관여했다는 것만 보여줍니다. 어떤 판단을 사람이 했고, 어떤 판단을 AI가 했는지는 커밋만으로는 알 수 없습니다.

예를 들어 9월 30일, PDF Image Creator는 재생성 관련만으로 8번 출시했습니다(1.4.12~1.4.19). 8건 모두 Opus 5.5와의 공동 저작이며, 8건 모두 테스트 코드를 업데이트했습니다. 하지만 8번에 나누어 진행했다는 것, 어디서 구획을 나눴는지는 기록에 남아있지 않습니다.

가격이나 기한 결정, 실제 서버에서의 측정(Stripe의 API를 PowerShell로 호출하거나, 임대 서버에서 ImageMagick을 확인하는 것)은 커밋 외적으로 사람이 한 일입니다. 이 역시 리포지토리에는 남지 않습니다.

다음 자신에게 전달할 메모

• 공동 저작 행은 AI가 관여했다는 것만 보여줄 뿐입니다. 판단의 분담은 별도로 기록하지 않으면 사라집니다.
• 모델별로 숫자를 비교하기 전에, 리포지토리와 시기로 나누어 보세요. 편향이 있다면, 모델의 차이라고 말할 수 없습니다.
• 테스트를 작성하게 하려면, 먼저 테스트가 놓일 자리를 만드세요. 자리가 없는 리포지토리에서는 어떤 모델도 작성하지 않습니다.
• 업무 흐름(보고, 인수인계서, 구현, 변경 이력)을 고정하면, 모델이 바뀌어도 나오는 것의 형태가 일관됩니다.

당신의 리포지토리에서 AI와의 공동 저작 커밋을 세어보면 무엇이 보이나요?

평소에는 raplsworks.com에서 WordPress 플러그인 개발이나 Claude Code 관련 글을 쓰고 있습니다.

Discussion