소프트웨어도 '유지보수'가 혁신이다 — 개발자가 읽어야 할 이유

혁신보다 유지보수가 중요한 시대

실리콘밸리 전설 스튜어트 브랜드(Stewart Brand)가 87세의 나이에 신간 Maintenance: Of Everything, Part One을 출간했다. "문명 차원에서 유지보수의 중요성을 종합적으로 조망하겠다"는 선언과 함께, 오토바이부터 건물, 지구까지 — 무언가를 돌보는 행위가 왜 "급진적(radical)"인지를 묻는다.

이 책은 기술 서적이 아니다. 하지만 소프트웨어를 만드는 사람이라면 한 번쯤 멈춰서 생각해볼 메시지를 담고 있다.

유지보수는 왜 '낮은 지위'에 머무는가

MIT Technology Review의 서평을 쓴 버지니아 공대 리 빈셀(Lee Vinsel) 교수는 "유지보수 연구(Maintenance Studies)" 분야의 공동 창시자다. 그는 브랜드의 핵심 전제 — 유지보수자(maintainer)는 마땅히 존경받아야 한다 — 에 동의하면서도 책의 한계를 지적한다.

"지난 수십 년간 학자들은 도구에 기름칠하고, 마모된 부품을 교체하고, 코드베이스를 업데이트하는 작업 모두가 '혁신'보다 낮은 지위에 놓여 있음을 보여주었다."

소프트웨어 업계에서도 상황은 다르지 않다. 새 기능(Feature)을 출시한 팀은 조명을 받지만, 기술 부채(Technical Debt)를 묵묵히 갚는 팀은 스프린트 리뷰에서 주목받기 어렵다. 오픈소스 생태계의 번아웃 문제도 근본적으로는 "유지보수 노동의 비가시성"에서 비롯된다.

세 가지 유지보수 전략 — 1968년 항해 레이스에서 배우기

브랜드는 1968년 단독 세계일주 요트 레이스 '골든 글로브(Golden Globe)'에 참가한 세 항해사의 이야기로 책을 연다. 각자의 유지보수 철학이 극명하게 갈렸다.

소프트웨어 프로젝트에도 이 세 유형이 그대로 나타난다. 테스트 없이 배포하는 팀, CI/CD(지속적 통합·배포)와 모니터링을 철저히 갖추는 팀, 장애가 터지면 빠르게 대응하는 팀. 브랜드의 우화가 보여주듯, 방치형은 치명적이고 예방형이 가장 안정적이지만, 현실에서는 예방과 대응의 균형이 핵심이다.

"Move Fast and Break Things" 그 이후

서평에서 빈셀 교수가 날카롭게 짚는 대목이 있다. 실리콘밸리의 "빠르게 움직이고 부숴라(Move Fast and Break Things)" 문화가 건강한 유지보수를 해친다는 비판을 브랜드가 언급조차 하지 않는다는 점이다.

이 비판은 개발 현장에서 매일 체감하는 현실이다. 빠른 출시 주기, MVP(최소 기능 제품) 중심 개발, 기술 부채의 누적 — 이 모든 것이 "새로운 것을 만드는 일"에 보상 구조가 편중된 결과다.

학생 개발자를 위한 시사점

1. 코드 리뷰와 리팩토링(Refactoring, 코드 재구조화)을 포트폴리오에 포함하라. 새 프로젝트를 시작하는 것만큼, 기존 코드를 개선한 경험도 실력을 보여준다.
2. 오픈소스 기여는 이슈 수정부터. 화려한 신기능보다 버그 수정, 문서 개선, 의존성 업데이트로 시작하면 실제 유지보수 역량을 쌓을 수 있다.
3. "Right-to-Repair(수리할 권리)" 운동에 관심을 가져라. 브랜드도 언급하듯, 기업들이 이윤을 위해 수리 가능성을 제한하는 관행은 소프트웨어에서도 벤더 잠금(Vendor Lock-in) 형태로 나타난다.

유지보수의 정치학 — 놓친 질문들

빈셀 교수의 가장 강한 비판은 브랜드가 유지보수를 "개인의 성취와 충족"으로만 바라본다는 점이다. 현실에서 유지보수 노동은 성별·인종에 따라 불균등하게 분배되고, 기존 시스템을 유지하는 것이 때로는 필요한 변화를 가로막기도 한다.

소프트웨어 세계에서도 마찬가지다. 레거시 시스템(Legacy System, 낡은 기존 시스템)을 유지하는 것이 항상 옳은 것은 아니다. 내연기관 차량을 계속 수리하는 것보다 전기차로 전환하는 편이 나을 수 있듯, 때로는 기술 부채를 안고 가는 대신 과감하게 재작성(Rewrite)하는 판단도 필요하다.

마무리: 유지보수자에게 경의를

브랜드의 책이 완벽하지는 않지만, 핵심 메시지는 유효하다. 만드는 사람만큼 고치는 사람도 중요하다. 주니어 개발자든, 시니어 엔지니어든, 자신이 유지보수하는 코드와 시스템에 자부심을 가져도 좋다. 그것이 바로 "세상을 돌아가게 하는 일"이기 때문이다.

💡 학생 활용법: 자신의 과거 프로젝트를 꺼내 리팩토링해 보자. 6개월 전 코드를 개선하는 과정 자체가 유지보수 역량의 핵심이며, 면접에서 "기존 코드를 어떻게 개선했는가"를 보여주는 강력한 사례가 된다.