저는 몇 주 전부터 _diff 부채 (diff debt)_라는 용어를 사용하기 시작했는데, 제가 받은 첫 반응은 꽤 일관적이었습니다: "그거 그냥 기술 부채 (technical debt) 아닌가요?"

아닙니다. 그리고 솔직히 말해서, 이 둘 사이의 간극이야말로 제가 이 용어를 위해 새로운 단어가 필요했던 이유 전체입니다.

우리가 이미 알고 있는 버전으로서의 기술 부채 (Technical debt)

Ward Cunningham은 90년대 초에 기술 부채 (technical debt)라는 은유를 우리에게 제시했고, 이는 정확하기 때문에 계속 살아남았습니다. 마감 기한을 맞추기 위해 빠르고 지저분하게 무언가를 출시하면, 당신이 취했던 지름길을 우회해야 할 때마다 나중에 그에 대한 이자를 지불하게 됩니다.

겉으로 드러나지 않는 부분은 기술 부채 (technical debt)가 당신이 당신이 출시한 것을 _이해하고 있음_을 전제로 한다는 점입니다. 당신은 깔끔한 해결책 대신 편법적인 해결책을 의도적으로 선택했습니다. 당신은 지금 당장 그 파일을 열어서 왜 그것이 지저분한지, 그리고 "올바른" 버전은 어떤 모습일지를 한 줄 한 줄 설명할 수 있습니다.

그것이 기술 부채 (technical debt)의 특징입니다. 그것은 정직합니다. 당신은 대출에 서명했습니다. 당신은 대략 얼마를 빌렸는지 알고 있으며, 보통 언제 그것을 갚을지에 대한 생각도 가지고 있습니다.

Diff 부채 (Diff debt)는 약관을 읽지 않은 부채입니다

이제 다른 상황을 상상해 보세요. PR (Pull Request)이 올라왔습니다. 400줄입니다. 테스트는 통과했고, CI (Continuous Integration)는 초록불이며, 시간은 늦었고, 당신이 신뢰하는 누군가(또는 무언가)로부터 왔습니다. 당신은 훑어보지만 눈에 띄는 것은 없고, 승인합니다.

당신은 지름길을 택한 것이 아닙니다. 단지 제대로 읽지 않았을 뿐입니다.

그 코드는 이제 프로덕션 (production)에 있으며, 만약 다음 달에 그것이 깨진다면 당신은 다음과 같은 사실을 알게 될 것입니다: 팀의 그 누구도 실제로 그것을 설명할 수 없다는 것입니다. 그것이 영리해서가 아니라, 어떤 인간도 머릿속에 그것에 대한 모델을 구축한 적이 없기 때문입니다. 그것은 생성되었거나, 복사해서 붙여넣었거나, 그냥 통과되었으며, 이제 당신은 버그를 디버깅하는 것이 아니라 아무도 실제로 내린 적 없는 결정을 역공학 (reverse-engineering)하고 있는 것입니다.

그것이 Diff 부채 (diff debt)입니다. 기술 부채 (technical debt)는 당신이 선택한 엉망진창인 상태입니다. Diff 부채 (diff debt)는 당신의 저장소 (repo)로부터 물려받은 미스터리입니다.

이들이 실제로 갈라지는 지점

이것이 중요한 이유: 기술 부채 (technical debt)는 당신의 대차대조표에 기록되어 있어 눈에 보이고 스프린트 (sprint) 일정에 반영할 수 있습니다. 반면 Diff 부채 (diff debt)는 장부에 전혀 기록되지 않다가, 사고 (incident)가 발생하여 억지로 빛 아래로 끌어올려지기 전까지는 존재하지 않는 것과 같습니다. 당신이 존재조차 모르는 부채는 우선순위를 정할 수 없습니다.

최근 들어 이것이 왜 훨씬 더 악화되었는가

소프트웨어를 작성해 온 역사의 대부분 동안, Diff 부채 (diff debt)는 거의 존재하지 않았습니다. 왜냐하면 코드를 '생산하는 것' 자체가 느린 작업이었기 때문입니다. 만약 사람이 400줄을 작성했다면, 그 사람은 400줄을 이해하고 있었습니다. Diff (차이점)를 만들고 그 Diff를 이해하는 데 드는 비용은 거의 동일했습니다.

AI가 이를 깨뜨렸습니다. 이제는 깨끗하고, 자신감 있어 보이며, 테스트를 마친 듯한 400줄짜리 변경 사항이 단 몇 초 만에 나타날 수 있으며, 이는 사실상 병합 (merge)하기 쉽도록 설계되어 있습니다. 하지만 이를 검토 (review)하는 속도는 전혀 빨라지지 않았습니다. 오히려 더 어려워졌다고 볼 수 있는데, 생성된 코드 (generated code)는 조용히 틀렸을 때조차 자신감 넘치는 모습을 유지하기 때문입니다.

따라서 그냥 배포해 버리라는 압박이 엄청납니다. Diff는 올바르게 보이고, 파이프라인 (pipeline)은 초록불이며, 병합 (merge)을 클릭합니다. 그리고 누군가 실제로 읽지 않은 채 그런 일이 일어날 때마다, 당신은 시간을 절약하는 것이 아닙니다. 당신은 보이지 않는 이율로 시간을 빌려 쓰고 있는 것입니다.

당신의 팀이 이를 겪고 있는지 확인하는 방법

다음 중 하나라도 익숙하게 들린다면, 당신은 Diff 부채 (diff debt)를 안고 있는 것입니다:

• PR (Pull Request)이 사람이 읽을 수 있는 속도보다 더 빠르게 승인된다.
• 500줄짜리 Diff가 단 2분 만에 "LGTM" (Looks Good To Me)과 함께 통과된다.
• 무언가 고장 났는데 "누가 이걸 작성했나?"라는 질문에 어깨를 으쓱하거나 도구의 이름이 답으로 돌아온다.
• 아무도 건드리고 싶어 하지 않는 파일이 있으며, 그 파일은 시간이 흐르며 점진적으로 구축된 것이 아니라 한 번에 병합되었다.

이 중 어느 것도 코드 품질 (code quality)에 관한 것이 아니라는 점에 주목하세요. 아름다운 코드라도 순수한 Diff 부채 (diff debt)일 수 있습니다. 징후는 코드가 어떻게 읽히느냐가 아니라, 그 뒤에 '생각하는 마음(mind)'이 있느냐 하는 것입니다.

부채 상환하기

기술 부채 (technical debt)는 리팩터링 (refactoring)을 통해 해결합니다. Diff 부채 (diff debt)는 다릅니다. 유일한 실질적인 치료법은 이해 (understanding)이며, 이를 구매하기에 가장 저렴한 시점은 병합 (merge)하기 전입니다.

도움이 되는 몇 가지 방법이 있습니다. 승인 (approval)이 단순히 "무서운 점을 발견하지 못했다"가 아니라, 실제로 "이것을 이해했다"라는 의미를 갖도록 만드세요. Diff가 누구에 의해 혹은 무엇에 의해 생성되었든 상관없이, 읽을 수 있을 만큼 충분히 작게 유지하세요. 그리고 작성자가 모델 (model)인 경우에도, 누군가가 왜 그 변경 사항이 올바른지 검토하도록 하세요. 만약 아무도 설명할 수 없다면, 그것은 통과 (green light) 신호가 아닙니다. 그것은 이자 (interest)가 조기에 나타나고 있다는 신호입니다.

따라서, 동일한 것이 아닙니다

기술 부채 (Technical debt)는 눈을 뜨고 빌린 대출입니다. Diff 부채 (Diff debt)는 읽지 않고 서명한 대출이며, 추악한 점은 만기가 될 때까지 당신이 그것에 서명했다는 사실조차 모를 수도 있다는 것입니다.

당신이 읽지 않은 Diff는 빛에 비추어 확인하지 않은 청구서와 같습니다. 그것은 단 한 번 작동하지 않을 때까지는 아주 잘 사용되는 것처럼 보입니다.

둘 다 비용을 발생시킵니다. 하지만 적어도 기술 부채의 경우, 당신은 자신이 부채를 지고 있다는 사실을 알고 있습니다.