AI로 구현 브랜치는 넓게 탐색하고, 완성 뒤 좁은 PR로 다시 쪼개자는 개발 워크플로

글이 좀 어렵게 쓰였지만, 한 브랜치에서 제약 없이 구현하고 데모와 수정까지 한 뒤 AI로 깔끔한 작은 변경 묶음으로 다시 쪼개자는 얘기로 읽힘. 다만 에이전트가 만든 변경은 관련 없는 수정이 섞이는 경우가 많았는데, 이걸 정말 작은 PR 단위로 검토할지 의문임.

기능을 여러 개 구현한 뒤 코드를 보고 리팩터링하는 단계는 원래 브랜치에서 하는 게 맞아 보임. 브랜치 히스토리는 굳이 보존할 필요 없이 나중에 전부 다시 쓰거나 스쿼시해도 될 듯.

내가 읽기에는 바로 그 산만한 변경을 고치자는 글임. 복잡한 기능을 만들고 나서 순서가 있는 원자적 커밋으로 리베이스해 본 적 있는데, 수동으로도 가능한 방식임.

에이전트 변경이 엉망이면 먼저 모델보다 명세와 프롬프트 맥락을 봐야 한다고 생각함. 우리는 명세가 끝나면 즉시 AI 브랜치를 만들고 회의에서 약 3분 검토하는데, 보통 코드의 절반 이상은 쓸 만한지 빨리 판단됨.

글이 어려운 이유는 LLM이 썼거나 많이 손질한 문체 같음. 특히 사전 경계 설정이 리뷰를 가능하게 하려고 했고 그 비용이 바뀌었다는 식의 문장은 LLM 문장처럼 보임.

회사 블로그에 AI가 쓴 글을 저자 이름으로 올리는 이유를 모르겠음. 내용에 생각이 있더라도 최종 문장을 AI에 맡기면 결과물 가치가 크게 떨어지고, 채용용 블로그라면 좋은 지원자에게 오히려 거부감 줄 수 있음.