모든 개발자가 겪어봤을 일입니다. 몇 달 후에 프로젝트를 열고, '캐시 레이어 리팩토링'이라고 적힌 커밋을 보며 생각합니다... 내가 이걸 왜 했지? diff는 무엇이 변경되었는지 모든 줄을 보여줍니다. 하지만 그것이 왜 변경했는지는 절대 알려주지 않습니다.

바로 그 빠진 '왜(why)'가 제가 Alpheon으로 고치려고 노력해 온 부분입니다. git diff를 읽고 인수인계 메모를 작성하는 작은 도구입니다. 무료 버전은 사용자가 직접 작성한 템플릿을 채워줍니다. 하지만 저는 더 어려운 질문에 답하고 싶었습니다. 모델이 오직 diff만 가지고, 지어내는 것 없이 스스로 추론하여 이유를 재구성할 수 있을까?

그래서 제가 스트레스 테스트를 진행했습니다. 여기서 배운 점들을 공유합니다.

모델보다 중요한 규칙

결과가 나오기 전에, 이 부분이 저에게 가장 중요합니다. 확신에 차서 이유를 지어내는 도구는 아무 도구가 없는 것보다 더 나쁩니다. 왜냐하면 잘못된 '왜'가 마치 사실인 것처럼 기록되고, 다음 사람이 그것을 믿게 되기 때문입니다.

그래서 모델에게는 엄격한 지침이 주어졌습니다:

1. 모든 주장(claim)은 diff의 증거에 근거해야 합니다. 티켓, 사용자 또는 동기를 절대 지어내지 마십시오.
2. 추론할 때는 '아마도(likely)' 또는 '보기에(appears to)'라고 말하십시오. 신중하게 표현된 실제 이유가 자신감 있는 추측보다 낫습니다.
3. 주장이 근거를 갖도록 실제 코드 심볼과 값을 참조하십시오.
4. 커밋 메시지를 단순히 반복하지 마십시오. 코드 자체로부터 추론하십시오.
5. 아래의 모든 내용은 모델이 압박 속에서도 실제로 이 규칙들을 준수하는지에 달려 있습니다.

실제 예시

메시지가 단지 '캐시가 가득 찼을 때 정지(stall) 방지'인 커밋을 가져와 봅시다. diff는 작습니다. 원래 무조건 쓰기만 하던 deposit 경로가 이제 오버플로우를 먼저 확인합니다. 이 도구가 생성한 결과는 다음과 같습니다:

"이 변경 사항은 캐시가 가득 찼을 때 작성자가 정지하는 것을 방지합니다. 원래 코드는 항목들을 완전히 수용할 수 없을 때도 계속 쓰려고 시도하여, 가득 찬 저장소에 대해 루프에 빠질 수 있었습니다. 이제 경로는 전후 용량을 측정하고, 오버플로우를 계산하며, 보류 중인 항목을 무조건 지워 작성자가 계속 진행할 수 있도록 해줍니다."

시도했으나 거부됨: diff(차이점)는 무조건적인 쓰기(unconditional write)를 오버플로우를 인식하는 쓰기(overflow-aware write)로 대체합니다. 이는 이전의 단순 쓰기 방식이 정체(stall)를 유발하여 폐기되었던 접근 방식이었음을 시사합니다.

이것은 커밋 메시지를 단순히 바꾸어 말한 것이 아닙니다. 코드를 읽고, 실제 실패 지점(정체 루프)을 식별했으며, 기존의 잘못된 접근 방식이 무엇이었을지 추론해낸 것입니다. 이것이 바로 세션이 종료되는 순간 보통 증발해 버리는 바로 그 추론 과정입니다.

정직하게 스트레스 테스트하기

하나의 좋은 사례는 아무것도 증명하지 못합니다. 누구나 체리피킹(cherry-pick)할 수 있기 때문입니다. 그래서 저는 한 줄짜리 수정부터 40,000자 길이의 단일 리팩터링(refactor)에 이르기까지, 실제의 복잡한 코드베이스에서 가져온 일련의 커밋들에 대해 테스트를 실행했습니다. 간결한 커밋 메시지, 의존할 문서 없음 등 의도를 복구하기 위한 최악의 조건들이었습니다.

저는 모든 결과를 수동으로 채점했습니다. 완벽했다고 거짓말하지는 않겠습니다. 정직함이 핵심이기 때문입니다.

1. 대부분: 정확함. diff에 근거한 실제적인 추론을 수행하며, 불확실한 부분에서는 올바르게 확답을 피했습니다.

2. 일부: 그럴듯함. 코드에서 동기가 진정으로 보이지 않는 변경 사항(예: 카메라 경계 조정 등)의 경우, 안전하게 접근하여 주로 변경 사항만을 설명했습니다. 틀린 것은 아니지만 내용이 빈약했습니다.

3. 제로(0): 환각(hallucination). 40,000자 길이의 리팩터링처럼 모델이 감당하기 벅찰 만한 큰 작업까지 포함하여, 전체 배치에서 단 하나의 지어낸 이유도 발견되지 않았습니다.

마지막 문장이 제가 밤잠을 설치게 만드는 부분이면서, 동시에 제가 이 모델을 신뢰하게 만든 부분입니다. 이러한 도구들의 실패 모드는 모호함이 아니라, 자신 있게 틀리는 것입니다. 가혹한 테스트 세트 전체에서 조작된 이유가 단 하나도 나오지 않았다는 점은 보고할 가치가 있는 결과입니다.

타인의 API가 아닌 로컬에서 실행되는 이유

사람들이 이를 묻기에 답변하자면, 이 모델은 제3자 API가 아닌 제가 제어하는 GPU에서 실행됩니다. 여러분의 코드는 OpenAI나 그 누구에게도 전송되지 않습니다. 여러분의 비공개 diff를 읽는 것이 주된 임무인 도구로서, 이는 타협할 수 없는 부분이었습니다.

여러분이 잊어버린 저장소(repo)에서 직접 시도해 보세요

여기 재미있는 부분이 있습니다. 커밋 내용이 더 이상 이해되지 않았던 프로젝트를 찾아가서, 실제 "왜(why)"가 무엇이었는지 확인해 보세요.

핵심 도구는 오픈 소스(open source)이며, MIT 라이선스, 단일 파일, 의존성 제로(zero dependencies)입니다:

github.com/BravoAlphaSix/alpheon

이 아이디어가 공감을 불러일으킨다면, 스타(star)를 눌러주는 것이 진심으로 도움이 됩니다. 그것이 "잃어버린 왜(why)" 문제와 싸우는 다음 사람이 이 프로젝트를 찾을 수 있는 방법이기 때문입니다. 그리고 만약 여러분이 무언가에 이 도구를 실행했을 때, 결과가 좋든 나쁘든 놀랍다면 댓글로 알려주세요. 저는 공개적으로(in the open) 빌드하고 있으며, 실패 사례는 여러분이 저에게 줄 수 있는 가장 유용한 것입니다.