이해해요. 다들 그런 적이 있죠 — 마감이 점점 다가오고, 클라이언트가 목에서 숨을 쉬는 것 같고, 코드 한 부분은... 그냥 말로만 해도 참을성과 의지만으로 유지되고 있는 것 같아요.

마침내 기능이 작동하게끔 만들었을 때, 달아나버리고 다시는 돌아보지 말 생각이 들 정도로 강한 유혹이 올 겁니다.

하지만 소프트웨어 개발에 관한 한 가지 사실이 있죠 — 그것은 결코 정말 완료되지 않는다는 것이죠.

"작동한다"는 것은 일시적인 상태일 뿐이고, 그 말에 고수할수록 당신이 숙명을 따라다니는 디지털 프랑켄슈타인의 괴물을 만들게 되죠.

기술적 부채가 쌓입니다

매끄러운 수정, "나중에 수정해야 할 사항", "이건 아마 문제가 될 일이 없겠지…"와 같은 말은 모두 당신의 이성에 비해 고금리 대출을 받는 것과 같습니다. 처음에는 필요 악으로 보일지 모르겠지만 시간 내에 출시를 하고, 기능이 공개되며 모두가 자신에게 박수를 칩니다.

하지만, 금융의 상당 합당한 대변으로 기술적 부채는 이자가 발생하는 짜증스러운 습관이 있습니다. 그 빠른 해킹? 새로운 코드와 상호작용할 때 예상치 못하게 손상됩니다. 문서화가 잘되지 않은 함수? 이제 몇 시간을 소비해서 역공학 분석해야 합니다.

여기 중요한 것이 있습니다 — 이자는 지수 함수적입니다. 기술적 부채를 무시할수록 수정하기가 더 어렵고(비용도 높아집니다). 작은 문제는 얽힐수록 복잡한 문제가 만들어집니다.

기술 부채는 코드베이스를 딱딱한 단일체로 만들어 버립니다. 변경 사항을 가할 때는 일련의 Jenga 블록을 옮기는 것처럼 무서운 게임이 됩니다. 부채가 있는 코드베이스에서 작업하는 것은 기분을 꺾는 일입니다. 무언가 위대한 것을 만들고 있는 대신 불을 끄느라 바쁘다는 느낌이 듭니다.

가장 나쁜 부분은 비기술 이해 관계자에게는 종종 보이지 않는다는 것입니다. 기능을 생산하는 대신 리팩터링해야 하는 이유를 설명하는 것은 짜증날 수 있습니다.

버그는 암송문이 된다

몇 달 동안 잠들어 있는 코드를 살펴보고 암윽한 기능 장애를 터뜨리기 전까지를 위한 특별한 지옥이 있습니다. 이것은 전설이 되는 버그, 개발자들 사이에서 속삭이며 말하는 이야기가 됩니다. 불가피한 한계점이 다가오면 당신은 더 이상 개발자가 아닙니다 — 반 기억된 목격 정보와 모호한 오류 메시지를 기반으로 신화적인 짐승을 추적하려는 암송학자입니다.

우리 모두 한 적이 있습니다. 분명히. 낯선 예외 상황을 위해 서두르게 구현된, 제대로 문서화되지 않은 해결책을 발견한 적이 있을 것입니다. 그 당시에는 작동했고, 다음 위기로 넘어갔고, "나중에" 고치겠다는 어딘가에 메모한 것이 있었죠. 그로부터 수개월 후, 보통의 변경이 전체 시스템을 붕괴시키게 만듭니다. 이제 거의 기억나지 않는 코드에 몸 담고, 프로젝트 마감 기한이 앞다퉈 닥쳐올 때 그 신비한 논리를 이해하려고 애쓰고 있군요.

이것이 서둘러된 패치와 무시된 해야 할 일의 대가입니다. 그 "임시" 해결책들이 시간을 흡수하는 블랙홀로 변모하여 진전을 방해하고, 적극적인 개발자가 아닌 지친 버그 사냥꾼으로 만드는 것입니다.

직원들의 의욕이 꺾여요

내가 그렇게 했다. 모든 변경 사항이 도박 같이 느껴지는 프로젝트에 참여한 적이 있습니다. 단 한 가지 버그를 수정하는 것조차 세 가지 더 발생시킬 수 있는 것처럼 느껴졌죠. 계속되는, 이식되는 불확실성은 의욕을 제압하는 요인입니다. 숨겨진 문제로 가득한 코드베이스에서 작업하는 것은 지뢰 필드를 걷는 것 같은 느낌인데요 - 항상 다음 폭발에 대비하고 있습니다.

이러한 환경으로 인해 개발자들은 시작하기도 전에 포기할 것 같은 기분이 들 수 있어요. 코드베이스에 숨어 있는 고대의 문서화되지 않은 공포물과 만나는 순간 우리가 마음먹은 우아한 해결책을 왜 만들어야 하는 걸까요? 좌절이 쌓이고, 단축키가 통상이 되며, 당신의 작업에 대한 자부심이 천천히 침식됩니다.

더 나쁜 것은, 최고의 개발자들이 가장 빨리 질리게 되는 사람들이에요. 누구나 건축을 하는 대신 불을 끈다고 하루를 보내고 싶어하지는 않잖아요. 의욕 상실된 팀은 인재의 회전 문제가 되어, 남아 있는 사람들은 더 많은 일을 해야 하며, 더욱 거세지는 쇠퇴 사이클에 기여하게 됩니다.

비즈니스에 악 영향

잘 관리되지 않은 코드베이스는 전략적인 책임을 가집니다. 빠르고 더러운 해킹이 시간 내에 릴리스를 푸시하는 데 도움이 될 수 있지만, 장기적으로 큰 비용이 들 수 있어요. 기술적 부채가 비즈니스에 직접적으로 해를 끼친다는 것을 여기에서 확인해보세요:

민첩성? 그게 뭐죠? 심지어 작은 새로운 기능을 구현하는 것조차 높은 위험이 따릅니다. 예상치 못한 부작용과 핵심적인 것을 망칠까 두려워하여 변경 사항이 기하급수적으로 시간이 많이 소요됩니다. 당신이 스파게티 코드를 해치우는 동안 경쟁업체는 혁신을 추구하고 시장 점유율을 늘리고 있습니다.

억지로 인해 시장이 변하거나 새로운 기회가 발생했을 때 회전하기가 어려워집니다. 판매 팀이 절박히 원하는 핫한 새로운 기능은 기술적 부채에 묶여, 적시에 (혹은 정신 나간 방식으로) 제공하기 불가능할지도 모릅니다.

규모 확장 문제가 하드웨어 때문인 줄 알았나요? 때로는 증가된 부하를 처리할 수 없는 잘못 설계된 코드가 원인일 수도 있습니다. 예상치 못한 병목 현상과 납득할 수 없는 충돌은 성장을 불가능하게 만듭니다.

이것은 개발팀의 문제뿐만이 아닙니다. 기술적 부채는 수익 손실, 짜증 난 고객, 경쟁력을 유지하기 어려운 비즈니스로 직결됩니다. 코드 유지보수를 핵심 가치로 내세우는 기업들이 장기적인 성공을 위한 위치에 있습니다.

소프트웨어 개발은 복잡해요.

하지만 장기적인 건강보다 단기적인 안위를 선택하는 것이 프로젝트(그리고 경력)를 불태워 버리는 방법이에요.

그래서 다음에 "건들지 마"라고 중얼거리고 천천히 물러나려는 유혹을 느낄 때, 지금 어려운 일을 해서 미래의 자신(아마도 동료들도)이 고마워할 것을 기억해 주세요.