유지보수 비용이 적은 소프트웨어 개발

목표

기술 부채가 없다.
소프트웨어의 설계가 이해하기 쉬우며, 소프트웨어를 수정해야 할 때 해당 코드를 쉽게 찾을 수 있다.
소프트웨어는 유지보수성을 최우선 목표로 삼아, 개발자가 이를 잊어버리고 수년이 지난 후에도 돌아와 계속 개선할 수 있다.
소프트웨어가 완성 상태에 무한히 가까우며, 환경 변화로 인해 뒤처지거나 새로운 요구사항이 나타나기 전까지 만족스럽다.
동일한 메이저 버전의 의존성을 자신 있게 업그레이드할 수 있다.
소프트웨어가 폐기될 때 기존 시스템에서 원활하게 제거될 수 있다.

원칙

"세상에 공짜 점심은 없다"는 말을 명심하라. 아무것도 하지 않고 유지보수 비용이 적은 소프트웨어 프로젝트를 얻을 수는 없다. 유지보수 비용이 적은 소프트웨어 개발을 달성하는 핵심은 실수를 몇 가지 덜 범하는 데 있는 것이 아니라, 가능한 한 모든 사소한 일을 올바르게 해내는 데 있으며, 이는 틀림없이 상당한 난이도를 지닌다.

여기에는 유지보수 비용이 적은 소프트웨어 개발을 달성하는 데 도움이 되는 몇 가지 일반적인 원칙이 정리되어 있다:

모든 불필요한 기능을 버려라.
생태계가 건강하지 않은 언어와 툴체인의 사용을 중단하라.
표현력이 뛰어난 언어를 사용하고, 코딩 과정에서 언어의 일반적인 관용 패턴을 왜곡하거나 벗어나는 것을 피하라.
코드 악취(Code smell)를 유발할 수 있는 어떤 목적으로든 매크로 사용을 중단하라.
타입 정의나 타입 어노테이션이 있는 언어만 사용하라.
시간이 검증한 기술을 가능한 한 많이 사용하라. 이러한 기술은 더 오래 살아남을 가능성이 높기 때문이다.
문제를 거시적으로 사고하고, 전술적 프로그래밍을 피하라.
코드를 적극적으로 리팩터링하고, 소프트웨어 엔트로피를 낮추기 위해 대규모 코드 줄 수정을 허용하라.
복잡성을 사용자에게 전가함으로써 덜 필요한 설계를 과감히 잘라내라. 인간공학적이고 친절한 설계는 종종 가장 유지보수하기 어렵기 때문이다. 현실에는 이와 유사한 사례가 이미 많이 존재한다. 마크다운 에디터와 위지윅(WYSIWYG) 에디터를 비교해 보라: 전자는 사용자가 (매우 적은) 학습 비용을 지불해야 하지만, 후자는 학습 비용이 거의 없다. 그러나 후자는 유지보수성 측면에서 전자보다 훨씬 뒤떨어진다:
- 마크다운 에디터는 구조가 명확하고 사람이 읽을 수 있는 플레인 텍스트 파일을 작성하기가 더 쉽다. 위지윅 에디터가 작성하는 것은 마이그레이션하기 어려운 내부 문서 모델이거나, 완전히 혼란에 빠진 HTML이다.
- 마크다운 문서는 2050년에도 여전히 사용할 수 있으며, 마크다운 에디터는 대체로 극도로 단순하고 대체 가능하다. 위지윅 에디터는 구식이 되기 쉽고, 하위 호환성을 유지하기가 더 어려우며, 개발자 관점에서도 유지보수하기 훨씬 까다롭다. 공급업체는 2050년에 이미 존재하지 않을 가능성이 높다.
공급업체 종속(Vendor lock-in)을 초래할 수 있는 대규모 소프트웨어 프레임워크의 사용을 중단하라. 소프트웨어 프레임워크가 모든 환경에 적응하려 하거나, 올인원 솔루션을 제공하려 할 때, 그것은 더 이상 소프트웨어 프레임워크가 아니라 시한폭탄이다.
품질이 낮은 소프트웨어 패키지에 대한 의존성을 최대한 줄여라. 이는 의존성에 대한 코드 품질 검토를 의미한다. 다행히도 나쁜 코드 스타일은 식별하기 쉬우며, 패키지의 동작 원리를 실제로 완전히 이해하지 않고도 판단을 내릴 수 있는 경우가 많다.
하위 호환성이 없는 플랫폼을 위한 소프트웨어를 작성하지 마라.
소프트웨어 기능이 단일하지 않은 한, 소프트웨어가 크로스 플랫폼을 지원하도록 만드는 것을 최대한 피해야 한다.
클라우드 컴퓨팅 플랫폼이 제공하는 독점 서비스의 사용을 금지하라.
서브 의존성의 버전을 고정할 수 없는 패키지 관리자의 사용을 금지하고, Git 리포지토리를 소프트웨어 패키지의 출처로 사용하는 것을 금지하라.
꼭 필요한 경우가 아니라면 기존 표준과 프로토콜에 영합하지 마라:
- 대다수의 표준과 프로토콜은 쓰레기이며, 그중 상당수는 참고할 가치조차 없다. 그것들에 맞추는 것은 소프트웨어의 발전을 저해할 뿐이다. 예를 들어, 불행하게도 이러한 표준과 프로토콜로는 구현할 수 없는 요구사항을 맞닥뜨린 후 진퇴양난의 곤경에 빠질 수 있다.
- 무시할 수 없을 정도로 매우 대중적인 표준과 프로토콜의 인기는 대개 선점 우위와 하위 호환성 보장에서 비롯된다. 이로 인해 프로덕션 환경에서의 구현체는 온갖 기이한 엣지 케이스로 가득 차게 되며, 이러한 엣지 케이스를 수집하고 대응하는 것은 사람을 지치게 만든다.
툴체인의 추상화 수준에 주목하고, 마이그레이션이나 업그레이드가 어려운 툴체인의 사용을 중단하라.
의존성 업그레이드 시의 안전성을 높이기 위해 대량의 자동화된 통합 테스트를 작성하라.
소프트웨어 실행에 필요한 환경은 다른 프로젝트와 공유되지 않고 격리된 전용 환경이어야 한다.
기술의 자체 소유화를 중시하고, 외부 요인의 영향을 받을 수 있는 의존성을 가능한 한 분리해 내라.
코어 개발자 이외의 개발자 수를 최대한 줄여, 협업 마찰로 인한 프로젝트 개발 효율성 저하를 방지하라. 이는 교통 체증과 같아서, 가장 좋은 해결책은 도로를 넓히는 것이 아니라 동시에 달리는 차량의 수를 줄이는 것이다.

바퀴를 재발명하는 것은 안티패턴이다. 언제나 이미 발명되어 재사용을 기다리고 있는 바퀴가 하나 이상 존재하기 때문이다. 그러나 기존 바퀴를 재사용하는 것은 종종 의존성 관리 문제를 야기한다. 처음에는 순조롭게 진행되지만, 머지않아 문제들이 연달아 발생한다. 가장 쉬운 길은 종종 기술 부채를 극대화하는 길이다. 이런 길을 걷다 보면 자주 좌절감을 느끼게 된다. 시간이 흐르면 아무리 자신감과 열정이 넘치는 사람이라도 학습된 무기력에 빠져, 소프트웨어 개발이란 끝이 보이지 않는 고역이라고 생각하게 된다.

의존성을 도입할 가치가 있는지 판단하는 것은 간과하기 쉬운 중요한 능력이며, 그 이면에는 말로 표현하기 어려운 방대한 경험의 뒷받침이 필요하다. 이 능력이 부족하면 쉽게 속아 넘어가 미래의 피해자가 되거나 심지어 가해자의 공범이 된다. 대다수 개발자가 이 능력을 갖추지 못했기 때문에 업계에서 악화가 양화를 구축하는 현상이 매우 흔하게 발생한다.

일정 규모에 도달한 오픈 소스 소프트웨어 프로젝트는 똥통(Shit mountain)으로 전락하기 쉽다:

잘못된 추상화, 끔찍한 아키텍처, 무시무시한 API 표면적.
신뢰할 만한 테스트의 부족.
적극적으로 관리되지 않아 실제와 일치하지 않거나, 유용한 세부 정보를 가리거나 무시한 문서.
지나치게 많은 전술적 코딩, 너무 적은 전략적 코딩, 줄어드는 코드양보다 항상 더 많이 늘어나는 코드양.
존재하지도 않는 요구사항에 과도한 시간 비용을 투자하여 소프트웨어가 비대해지고 부패함.
……

커뮤니티에 전략적 관점에서 기준을 잡고 엄격하게 코드 리뷰를 수행하는 권위 있는 메인테이너가 있지 않은 한, 오픈 소스 소프트웨어의 참여 모델은 기여자의 수준이 얼마나 높든 간에 본질적으로 이러한 똥통을 만들어낸다. 비공개 소스 소프트웨어도 동일한 문제를 안고 있지만, 비공개 소스라는 불투명성이 이러한 문제들을 한 층 더 덮어버릴 뿐이다. 문제를 양탄자 밑으로 쓸어 넣는다고 해서 문제가 사라지는 것은 아니다.

기술 부채에서 벗어나기 위해 때로는 NIH 모자를 써야만 할 때가 있다. 바퀴를 재발명함으로써, 나쁜 서드파티 의존성에서 벗어나는 것 외에도, 바퀴를 재발명하는 행위에는 기술 부채에 짓눌린 개발자들은 영원히 알 수 없는 이점이 존재함을 깨닫게 될 것이다:

더 나은 바퀴를 발명할 가능성이 생긴다.
해결책을 발명하는 데 점점 더 능숙해진다.
의존성의 좋고 나쁨을 식별하는 능력이 점점 더 향상된다.

낮은 유지보수 비용을 목표로 할 때, 바퀴를 재발명함으로써 얻는 이득은 미래에 더욱 증폭될 수 있다: 빚을 털어내고 나면 남는 것은 모두 이자라는, 얼마나 단순한 이치인가. 시간이 지나 이러한 긍정적인 피드백이 누적되면 바퀴를 재발명한다는 선택지는 마음속에서 점점 더 중요한 위치를 차지하게 될 것이다. 다만, 바퀴를 재발명하기 전에는 항상 그 경제성을 신중하게 평가해야 한다. 모든 것을 재발명하는 것은 여전히 바람직하지 않다. 분명 어떤 바퀴는 재발명의 가성비가 매우 낮고 개발 실패 위험이 높으므로, 주의를 기울여야 한다.

배터리식 의존성 구축

일부 프로그래밍 언어와 프레임워크는 배터리가 포함되어 있다(batteries included)고 주장하는데, 이는 즉시 사용할 수 있는 고급 기능이 내장되어 있음을 의미한다. 이러한 "배터리"의 본질은 상대적으로 안정적이고 저수준의 세부 사항을 드러내지 않기 위해 극도로 노력하는 고급 API에 불과하며, 올바른 추상화와 테스트 덕분에 파괴적 변경(Breaking change)이 거의 발생하지 않는다.

"배터리"라는 개념은 의존성 관리에도 완전히 적용될 수 있다. 다음과 같은 "배터리식 의존성"을 구축할 수 있다: 이러한 의존성은 의존성을 실제로 사용하는 프로젝트와 의존성 항목 사이의 중간 계층 역할을 하며, 의존성을 바탕으로 질서 있고 깔끔한 API 세트를 제공한다. 이를 통해 비즈니스 코드가 거대하거나 수많은 매개변수를 지닌 함수나 클래스처럼 야만인들이 발명해 낸 형태를 직접 사용하는 상황을 방지할 수 있다.

이러한 의존성 중 실제로 사용되는 부분에만 집중하므로, 의존성 버전이 업데이트될 때도 동작이 여전히 예상과 일치하는지 확인하기 위해 중간 계층에 자체 테스트 코드를 작성할 수 있다. 미래에 해당 의존성을 사용할 수 없게 되었을 때, 구버전의 의존성을 유지하거나, 의존성을 교체하거나, 직접 구현하는 방식을 선택할 수 있으며, 이전에 작성한 테스트는 리팩터링 시 유효성을 보장하는 데 사용된다. 이것이 바로 자신이 만든 배터리와 타인이 만든 배터리 간의 핵심적인 차이다. 자신의 배터리는 언제든 충전하거나 용량을 늘릴 수 있지만, 타인의 배터리는 보통 방전되어 가는 것을 지켜보는 수밖에 없다.

형태상의 유사성으로 인해 배터리식 의존성과 캡슐화된 비즈니스 로직을 혼동할 수 있지만, 둘의 주된 차이점은 의존성과의 거리에 있다. 배터리식 의존성은 일반적으로 의존성에 매우 가까이 위치하며, 비즈니스 로직은 일반적으로 의존성에서 멀리 떨어져 있다. 비즈니스 로직이 관련 의존성 위에 직접 구축되는 등 극소수의 경우에만 둘은 동일한 것으로 수렴한다.

배터리식 의존성은 의존성 관리 문제의 성배처럼 보이지만, 여전히 몇 가지 문제가 존재한다:

결국 추가적인 중간 계층이므로 새로운 기능이 필요하거나 파괴적 변경을 가할 때 의존성을 직접 사용하는 것보다 다소 번거롭다.
올바른 추상화를 구축하기 어렵다. 올바른 추상화를 모색하는 과정에서 때로는 불가피하게 판을 엎고 처음부터 다시 시작해야 할 수도 있다. 사람들은 미래의 요구사항을 예측하는 능력이 부족한 경우가 많으므로, 한때 올바랐던 추상화가 미래에는 잘못된 것으로 보일 수도 있다. 사람들은 잘못된 추상화로 인해 프로젝트가 반복적인 수정의 늪에 빠질까 두려워 차라리 더 큰 소용돌이 속으로 스스로를 밀어 넣는다. 적어도 문제가 생겼을 때 남 탓을 하는 것이 항상 더 쉽기 때문이며, 이러한 생각을 반박하기는 어렵다.

소형 패키지 사용

소형 패키지는 유닉스 철학과 시맨틱 버저닝(Semantic Versioning)이 함께 구현된 형태다. 패키지의 단위가 작을수록 단일 패키지의 기능이 적어지고, 기능이 적을수록 더 안정적이며, 코드를 변경할 때 망가질 수 있는 요소도 적어진다.

소형 패키지는 때로 패키지 수의 급증으로 인한 관리 문제와 같은 새로운 문제를 유발하기도 한다. 이러한 문제는 시간이 지남에 따라 점차 누적되어 무차별 대입(Brute-force)으로는 해결하기 어려워지므로 매우 골치 아플 수 있다. 결국 이러한 추세는 Facebook의 codemod 같은 전문적인 해결책을 불러오게 되지만, 여전히 이러한 도구를 사용하는 것은 번거롭다.

가독성과 성능 사이에서 가독성을 선택

실제 코딩 과정에서 가독성과 성능 사이에서 갈등하는 상황을 마주하게 되며, 이때 개발자는 일시적인 근시안으로 인해 가독성 대신 성능을 선택하기 쉽다. 성능을 선택하는 데에는 대개 강력한 이유가 뒷받침되지 않으며, 가독성을 희생하여 성능을 취하는 트레이드오프는 훗날 돌이켜보았을 때 수지타산이 맞지 않는 경우가 많다. 어떤 경우에는 개발자가 성능을 선택하는 이유가 단지 "고성능 코드를 작성하면 자신이 똑똑해 보인다"는 유치한 심리적 이득 때문이기도 하다.

가독성과 성능 사이에서 갈피를 잡지 못할 때는 언제나 가독성을 선택해야 하며, 이는 아무리 강조해도 지나치지 않다. 이 코드가 단 한 번만 작성되고 평생 다시는 수정될 일이 없다고 확신하는가? 가독성을 선택하라. 가독성이 더 좋은 코드가 1,000배 더 느린가? 가독성을 선택하라. 눈에 띄는 부정적인 성능 영향이 실제로 관찰된다면 그때 코드를 하나 더 작성하라: 이 코드는 높은 가독성을 가진 코드를 트랜스파일한 고성능 버전이며, 이 코드가 어떻게 생성되었는지 설명하는 매우 상세한 문서를 바로 옆에 작성해야 한다.

유일한 예외는 처음부터 고성능 프로그램 작성이 목표인 경우다. 애초의 목표가 고성능이기 때문에 이 시점에서는 가독성이란 선택지가 사라진다. 그러나 고성능 프로그램이라 할지라도 코드의 가독성을 높일 기회는 여전히 존재하지만, 그러한 기회는 쉽게 감지되지 않는다. 보통 코드를 두 번째 작성할 때 비로소 눈에 띄기 마련이다. 그리고 이러한 가독성 향상의 기회를 발견했다면 더 이상 그것을 무시할 이유가 없다. 성능을 동일하게 유지하는 조건이라면, 언제나 가독성을 최대한 높여야 한다.

유지보수가 필요 없는 소프트웨어에 대한 찬미

소프트웨어의 "유지보수가 불필요함"을 하나의 미학으로 여기고 감상해야 한다. 소프트웨어의 "유지보수가 불필요한 기간"이 길어질수록, 그 "유지보수 불필요성"이 시험받은 기간도 길어지며 축적되는 아름다움도 커진다.

가장 중요한 부분은 소프트웨어가 유지보수를 할 수 없는 것도 아니고, 유지보수가 어려운 것도 아니며, 유지보수가 '필요하지 않다'는 점을 명확히 아는 것이다. 소프트웨어 코드는 그 자리에 그대로 있지만, 건드릴 필요가 없다. 여전히 요구사항을 만족하고, 정상적으로 작동하며, 아주 훌륭하게 돌아가고 있기 때문이다.

설령 유지보수가 필요한 시점이 오더라도, 소프트웨어의 유지보수 저항은 창호지처럼 가볍게 툭 치는 것만으로도 제거될 수 있어야 한다. 기술 부채가 없기 때문에 이자를 지불할 필요도 없다. 강박증이 도져 의존성을 업그레이드하고 싶은가? 문제없다. 그 업그레이드는 10분 안에 완료될 수 있고, 당신에게는 낭비할 수 있는 10분이 아주 많다. 하지만 그보다 더 좋은 것은 스스로를 이겨내고 자신의 행동을 제때 멈추는 것이다. 새로운 요구사항이 아직 생기지 않았기 때문일 뿐만 아니라, 소프트웨어가 시간에 따라 축적해 온 아름다움을 파괴하고 싶지 않기 때문이다.

이러한 감상 능력을 기르는 것은 직관에 반하기 때문에 꽤 어렵다. 사람들은 무의식적으로 사물의 참신함을 사물의 좋고 나쁨을 가늠하는 요소로 잘못 인식하곤 한다. 유행을 따르는 것이 때로는 그 무엇보다 중요해 보이지만, 조금만 생각해 보면 이는 결코 이성적이지 않다. 일상생활 속에서만 보더라도 튼튼한 재료와 성숙한 공정으로 만들어진 장치는 예상외로 내구성이 뛰어난 경우가 많다. 끊임없이 작동하는 가전제품인 냉장고가 가장 대표적인 예이며, 매년 새 냉장고로 교체하는 사람은 거의 없다. 소프트웨어는 디지털 산물로서 하드웨어보다 더 빨리 구식이 되어야 할 이유가 없으며, 업데이트하기 쉽다는 점이 업데이트의 이유가 되어서는 절대 안 된다.