React 전체 Hooks 전환 히스토리를 Gemma 4에 넣어보니 놓친 점이 드러났다.

출처: Dev.to

“어떤 커밋이 모든 것을 망가뜨렸을까?”
레거시 코드베이스를 물려받은 모든 개발자는 이 질문을 해봤을 것입니다. 하지만 우리는 그에 대한 좋은 답을 찾을 방법이 없었습니다.

6개월 전, 제가 물려받은 코드베이스에서 프로덕션 이슈를 디버깅하고 있었습니다. 그 버그는 오래전부터 존재했는데, 우회 방법에도 우회가 있었기 때문에 오래됐다는 걸 짐작할 수 있었습니다. 하지만 언제부터 시작됐는지, 어떤 변경이 원인인지 파악하지 못했습니다.

git log를 열어봤습니다. 2,847개의 커밋, 3년치 히스토리. 모든 결정, 모든 실수, 모든 리팩터링이 “critical auth bug 수정”부터 “그냥”까지 다양한 커밋 메시지에 잠겨 있었습니다.

저는 검색 엔진이 아니라 역사가가 필요했습니다.

그래서 CodeDNA를 만들었습니다.

제가 수작업으로 답을 찾을 수 없었던 질문: 이 코드베이스의 품질이 언제부터 떨어지기 시작했고, 그 원인은 무엇인가?

표준 git 도구는 얼마나 일어났는지만 알려줍니다. 커밋 그래프는 속도를 보여주고, git blame은 누가 무엇을 건드렸는지 알려주지만, 왜 특정 기간이 혼란스러웠는지, 2019년 3월 API 변경이 6월 버그 클러스터와 어떻게 연결되는지는 알려주지 못합니다.

그 연결 고리는 시간을 초월한 추론을 필요로 합니다—180개의 커밋을 맥락 속에 두고 인과 사슬을 추적하는 것이죠. 바로 Gemma 4의 Thinking Mode가 설계된 이유입니다.

솔직히 말씀드리자면, “LLM을 썼다”는 말과 “Gemma 4를 의도적으로 사용했다”는 말은 다릅니다.

Thinking Mode가 이 프로젝트가 존재하는 이유입니다.

개발 과정에서 동일한 프롬프트를 여러 모델에 테스트했습니다. 일반적인 instruction‑tuned 모델은 요약만 만들어 냈고, 키워드 수와 패턴을 보고했습니다. 반면 Gemma 4는 Thinking Mode를 통해 패턴을 추론했습니다—특정 API 변경 뒤에 왜 수정 커밋 클러스터가 나타났는지를 추적했습니다.

UI에 표시되는 실시간 추론 스트림은 장난이 아닙니다. git log를 붙여넣고 오른쪽 패널에서 Gemma의 분석이 실시간으로 흐르는 모습을 보면, 구조화된 결과가 출력되기 전까지 인과 사슬을 구축하는 과정을 눈으로 확인할 수 있습니다. 이는 사후에 이야기를 꾸며낸 것이 아니라, 실제 분석 과정이 시각화된 것입니다.

128K 컨텍스트는 또 다른 전제 조건입니다.

파일 통계가 포함된 180개의 커밋은 대략 35,000~40,000 토큰의 압축 히스토리입니다. 3월 피벗이 6월 버그 폭풍을 일으켰다는 것을 감지하려면 두 시점을 같은 컨텍스트 윈도우에 넣어야 합니다. 128K가 없으면 청크 단위로 나눠야 하는데, 이는 인과 사슬을 완전히 파괴합니다.

프라이버시는 구조적인 문제이며 선택 사항이 아닙니다.

git 히스토리에는 독점 모듈명, 보안 패치 설명, 아직 공개되지 않은 기능 브랜치 등이 들어 있어 비즈니스 로직을 역추적할 수 있습니다. 저는 CodeDNA가 자신만의 API 키로 실행되고 데이터를 전혀 보관하지 않도록 설계했습니다. 이는 기능 토글이 아니라, 실제 엔지니어링 팀이 사내 레포지토리를 안심하고 사용할 수 있는 유일한 방법이라고 생각합니다.

제가 React 레포지토리의 2018‑2019 Hooks 전환 기간을 주요 테스트 케이스로 선택한 이유는 단 하나입니다: React를 아는 개발자는 2분 안에 결과를 검증할 수 있기 때문입니다.

다른 프로젝트 아이디어들은 검증이 어려웠습니다. 금융 이상 탐지는 도메인 전문가가 필요하고, CVE 스캔은 지식 컷오프 문제가 있고, 음식 사진 분석은 흐린 사진 때문에 데모가 깨지고, Git 히스토리는 공개 커밋이라 검증이 가능합니다.

Gemma 4에 2018년 9월부터 2019년 6월까지의 커밋을 입력했습니다. 데모에서는 24개의 커밋, 전체 실행에서는 약 180개의 커밋을 사용했습니다. Hooks 시기는 대규모 오픈소스 프로젝트 중에서도 가장 구조적으로 중요한 전환점 중 하나입니다.

Gemma 4가 찾아낸 내용

1. 첫 번째 마일스톤 – 2018년 7~9월에 기능 폭발이 있었음. Scheduler 시간 슬라이스 인프라(Scheduler.js에 144개의 삽입)와 React.lazy, Suspense, createContext v2가 6주 안에 연속적으로 추가되었습니다.

   • 이는 사실에 부합합니다. 모든 React 개발자는 이것이 Hooks 공개 이전의 기반 구축 기간임을 알고 있습니다.

2. 놀라운 마일스톤 – Gemma 4는 2019년 1~2월을 안정성 → 버그 폭풍 전환 시기로 표시했습니다. ca53456(useRef 수정)과 cb54567(무한 useEffect 루프 수정)이 16.8.0 릴리스 며칠 뒤에 발생했으며, 이 기간 동안 ReactFiberHooks.js가 8번 수정된 반면 이전 안정 단계에서는 2번에 불과했습니다.

   • 직접 확인해 보니 정확합니다. 16.8.0(2019년 2월 6일) 릴리스 이후, Hooks 구현의 엣지 케이스를 다루는 핫픽스 클러스터가 이어졌습니다. 파일 수준의 커밋 통계가 이를 보여 주지만, 전체 24개의 커밋을 동시에 살펴봐야 보이는 현상입니다.

3. 건강 점수 – 79/100

   • 세부 항목: 커밋 메시지 품질 +15, 2019‑05에 보이는 명확한 리팩터링 시대 +10, 버그‑수정 비율 21%에 -10, ReactFiberHooks.js의 집중적인 churn에 중립점. 모든 요소와 근거가 표시됩니다. 블랙박스 숫자가 아닙니다.

Gemma 4가 구체적인 인사이트(기업식 표현이 아닌)를 내도록 만드는 것이 가장 큰 난관이었습니다. 세 차례의 큰 반복을 거쳤습니다.

반복 1 (실패)

프롬프트: “이 코드베이스의 이야기를 알려줘.”
결과: 아름답게 꾸며진 환상. “팀은 어려운 리팩터링 기간 동안 기술 부채를 해결하려 애썼다.” 라는 식의 문장은 의미가 없음. 커밋 해시가 전혀 언급되지 않음.

반복 2 (조금 개선)

금지어 리스트 추가: “technical debt”, “the team”, “seems like”, “likely indicates”, “possibly”, “perhaps”.
인사이트가 다소 사실에 기반했지만 여전히 모호함. “이 기간에 많은 수정이 있었다”는 식으로 구체적인 수치나 기간, 수정 내용이 누락됨.

반복 3 (돌파) – 메타데이터 주입

모델 호출 전, 전처리기가 다음을 추출함:

• 월별 커밋 히스토그램: 2019-03: 47 commits, 2019-02: 12 commits
• 주요 변경 파일: ReactFiberHooks.js가 8번 수정됨
• 버그‑수정 비율: 21%

이 메타데이터를 프롬프트에 포함시키면 모델의 역할이 **카운팅