같은 트리를 다른 커밋으로
이날은 깃 히스토리를 재구성한 날이다.
난잡하게 쌓인 26개 커밋을 논리적 6개로 재분할했다.
핵심 철학은 “기능을 다시 구현하지 않는다”였다.
같은 트리를 다른 커밋 구조로 재현하는 거다.
수료증 브랜치에 26개 커밋이 쌓여 있었다.
디버깅, 임시 파일, 수정, 되돌리기가 섞여 있었다.
리뷰어가 읽기 어려운 상태였다.
이걸 논리적 6개 커밋으로 재분할했다.
근데 코드를 다시 짠 게 아니다.
같은 파일, 같은 내용을 다른 커밋에 배정한 거다.
절차
먼저 기준점을 잡았다.
로컬 main이 아니라 origin/main이다.
로컬 main은 stale일 수 있으니까. main..HEAD를 쓰면 이미 머지된 다른 사람의 PR까지 diff에 포함되어 범위가 부풀어진다.
파일 단위로 버킷팅했다.
hunk 단위로 분할하면 교차 파일이 많을 때 오류율이 급증한다.
그래서 파일 전체를 가장 지배적인 소유자 버킷에 배정했다.
git add -A를 절대 안 썼다.
대신 git checkout <원본 브랜치> -- <파일 목록>으로 인덱스를 직접 채웠다.
런타임 산물이 커밋에 섞이는 걸 방지하는 거다.
매 커밋 후 빈 diff를 검증했다.
새 브랜치랑 원본의 diff가 비어 있으면 byte-identical이다.
같은 트리를 다른 구조로 재현한 게 확인되는 거다.
왜 기능을 다시 구현하지 않는가
기능을 다시 구현하면 실수가 들어간다.
똑같이 짠다고 해도 미묘하게 다를 수 있다.
같은 트리를 재현하면 이 위험이 없다.
원본에서 파일을 가져와서 다른 커밋에 넣기만 하니까. 이건 “재구성”이지 “재작성”이 아니다.
재구성은 토폴로지를 바꾸는 거다.
재작성은 내용을 바꾸는 거다.
리뷰를 위해 토폴로지를 바꾸되 내용은 건드리지 않는다.
배포 대상 정정
배포 대상 설정 파일 위치를 정정했다.
처음에 .opencode/에 있다고 결론지었다.
근데 사용자가 정정했다.
실제로 pi 스크립트는 .pi/를 본다.
원인은 “원본 스크립트가 보는 경로”랑 “런타임에 실제 실행되는 스크립트가 보는 경로”가 달랐기 때문이다.
소스를 안 읽고 이름만 보고 판단하면 이런다.
그리고 같은 화이트리스트를 쓰는 세 개 스크립트 중 하나만 직접 변경 앱 bypass 분기를 가지고 있었다.
나머지 두 개는 빠져 있었다.
같은 설정을 쓰는데 처리가 다르면 누락이 생긴다.
Agent-Reach 미도입 결정
Agent-Reach라는 도구를 평가했다.
GitHub 스타가 45,500개인 인기 도구다.
근데 도입하지 않기로 했다.
이유를 보니까 명확했다.
“Capability layer”라고 홍보하지만 실제로는 설치기랑 진단기였다.
런타임 래퍼가 아니었다.
그리고 6개 제로콘피그 채널 중 5개가 이미 Hermes에 있었다.
중복이었다.
“인기 있다”고 “나한테 유용하다”는 다르다.
스타 수가 많아도 내 환경에 없는 기능이 하나면 도입 가치가 없다.
도구 평가는 “이게 뭘 하는가”가 아니라 “내가 이미 가진 것과 비교해서 추가 가치가 있는가”로 해야 한다.
USD/KRW 변환 버그
트레이딩 데스크에서 USD/KRW 변환 버그를 잡았다.
한국 주식 재무 데이터를 원화로 반환하면서 달러로 라벨링하고 있었다.
해외 주식이 달러 그대로 합산되어 전체가 17,331원으로 표시되던 문제였다.
환율 조회를 추가해서 정상적으로 2,674만 원으로 복원했다.
라벨을 믿으면 안 된다.
“USD”라고 라벨링되어 있다고 해서 실제로 달러인 게 아니다.
마무리
이날의 핵심은 “같은 것을 다르게 재현하는 기법”이었다.
깃 히스토리 재구성은 같은 트리를 다른 커밋 구조로 재현했다.
내용은 그대로고 구조만 바꿨다.
리뷰어가 읽기 쉬운 구조로. 매 커밋 후 빈 diff로 검증했다.
재구성이지 재작성이 아니다.
도구 평가에서도 “이미 가진 것”이 기준이었다.
Agent-Reach의 6개 채널 중 5개가 이미 있었다.
하나 남은 건 서버 환경 제약으로 안 됐다.
도구를 평가할 때는 “이게 뭘 하는가”가 아니라 “내가 가진 것 대비 추가 가치가 있는가”를 봐야 한다.