주제에 대해 서술하기에 앞서, 업계 전체에 흔하게 퍼져 있는 “기술 부채” 메타포에 관한 오해를 풀어야 할 것 같습니다. 대부분의 사람들에게 “기술 부채”로 인한 어려움을 이야기하면, 레거시 코드들로 인해 현재 개발에 많은 어려움을 겪고 있는 상황을 떠올릴 것입니다. 이 또한 프로덕트를 개발하는 엔지니어에게 있어서 큰 어려움임은 맞습니다. 다만 원래 이 비유가 어디서부터 비롯되었는지, 어떤 상황을 문제라고 여기는 것인지는 정확히 알고 넘어가는 것이 좋을 것 같습니다. 이 글에서 다루고자 하는 내용도 원래 비유로부터 시작하기 때문입니다.

기술 부채[^1] 가 원래 설명하고 싶었던 문제 상황은, “본인이 도메인에 대해 이해하고 있는 그대로 코드를 작성하지 않는” 것입니다. 이렇게 된다면 부채를 지었을 때 계속 이자를 내야 하는 것처럼, 번 만큼 이자로 다 나가기 때문에 발전이 없을 것이라는 비유였습니다.

다만 이 비유를 처음 들었던 워드는 아래 두가지 상황을 명확히 구분합니다.

  1. 잘못된 코드를 작성하는 것 => 반대
  2. 내가 도메인에 대해 잘못 이해하고 있더라도, 이를 반영한 코드를 작성하는 것 => 찬성

이를 단순히 코드를 작성하는 것 뿐만 아니라, 어디에도 적용할 수 있습니다. 글을 쓰거나, 새로운 걸 디자인하거나 할 때 말이죠. 그리고 점차 수정해 나가면 되는 것입니다. 반대로 내가 이해한 것이 아닌 다른 것들을 녹여내기 시작한다면 이상하게 꼬여 더는 수정할 수 없는 무언가가 될 것입니다. 그렇게 되면 개선하기 더 힘들어지겠죠.

제가 이번에 작성한 뉴스레터 글을 예시로 들어보겠습니다. 원래 이 글은 젠슨 황이 회복탄력성에 대해 이야기한 글로 시작할 예정이었습니다. 다만 글의 원 목표는 글쓰기가 가져다주는 안정감에 대한 것이었죠.

적다 보니 제가 원래 작성해나가던 방향이랑 원래 목표랑 하나도 맞지 않는다는 느낌이 들었습니다. 근데 그렇다고 이 글을 살리기도 어렵다고 느꼈습니다. 애매모호하게 이해한 부분들이 서로 얽히고 섥혀, 지우지 않고서는 더 수정하기 어려운 상태로 변해버린 것입니다. 그래서 글을 다 지우고 확실히 이해한 부분부터 시작했죠. 거기서 시작해서 점차 굴려나가니 더 확실하고, 수정 가능한 형태로 글이 완성되었습니다.

이처럼 아는 부분에서 시작해서, 작업물과 나의 이해를 일치시켜 가는 것이 모든 생산 과정에서 중요하다 느꼈습니다. 여기서 쉽게 헷갈릴 수 있는 부분이, 단순 도메인에 대한 나의 이해뿐만 아니라, 내가 해당 도메인에 필요한 기능들을 구현하기 위해 실제로 필요한 기능에 대한 이해 수준도 포함해야 한다고 느낍니다.

Changelog
  • 2024-10-19: 작성
  • 2024-10-30: 예시를 추가했습니다.
  • 2024-11-08: 쉽게 오해하기 쉬운 부분을 추가했습니다.

[^1] 워드 커닝햄이 직접 설명한 영상이 있고, 이 영상의 스크립트 도 있으니 궁금하시다면 읽어 보세요.

2024. 10. 19