모든 시스템은 나이를 먹는다. 새로운 기술, 라이브러리, 기법, 언어 등이 등장하면서 주변 환경이 끊임 없이 변하기 때문에 기존의 시스템은 서서히 구식이 되어 간다. 오래된 시스템을 유지하려면 관리하는 데 지속해서 비용이 들어가고 난해한 옛 기술에 대한 전문 지식이 필요하다. 이러한 낡은 시스템을 언제까지고 끌고 다니기 보다는 완전히 떼어내는 편이 나을 때가 많다. 궁극적으로 낡은 시스템을 완전히 걷어내는 과정을 폐기 라고 한다.
15.1 폐기시키는 이유
‘코드는 자산이 아니라 부채다.’ 코드에는 비용이 따라온다. 대부분 구축 후 생이 끝날 때까지 유지보수하는 데서 발생한다.
시스템에서 오래됐다고 해서 무조건 폐기시켜야하는 것은 아니다. 폐기는 시대에 뒤처졌음을 보여줄 수 있고 비슷한 기능의 대체재가 존재하는 시스템에 적합하다.
코드 자체는 가치를 창출하지 않는다. 가치를 만들어내는 것은 바로 기능이다. 사용자의 요구에 부합하는 기능은 자산이다. 코드 자체는 비용을 낳기 대문에 기능이 같다면 코드 자체는 단순할수록 좋다. 따라서 얼마나 많은 코드를 작성하느냐나 코드베이스가 얼마나 큰가가 아니라. 단위 코드당 얼마나 많은 기능을 제공하느냐에 집중하여 극대화해야 한다.
15.2 폐기는 왜 그리 어려운가?
시스템은 사용자가 늘수록 설계자가 예상하지 못한 전에 본 적 없는 방식으로 이용될 가능성이 커져서(하이럼의 볍칙) 폐기 작업을 그만큼 어렵게 만든다. 또 옛 시스템을 향한 애착이 의외의 저항으로 나타날 수 있다. 구글에서도 정책적으로 옛 코드를 제거하려 할 때 변화를 거부하는 움직임이 나타나곤 한다.
마지막으로 비용을 확보해 폐기를 진행하려면 정치라는 관문도 통과해야 한다. 오래된 시스템을 제거하는 데는 눈에 보이는 비용이 드는 반면, 아무것도 하지 않고 시스템을 방치해서 새어나가는 비용은 눈에 잘 띄지 않는다. 따라서 이해관계자들을 납득시키는데에 어려움이 있을 수 있다.
15.2.1 설계 단계에서의 폐기
소프트웨어 시스템의 폐기 계획도 시스템을 처음 구축할 때 함께 세워둘 수 있다. 언젠가는 폐기하게 될 시스템을 설계한다는 개념이 생소할 수 있지만 다른 엔지니어링 분야에서는 흔한 일이다. 예를 들어 원자력 발전소의 경우 훗날 수명이 다한 원자로를 어떻게 해체하고 자금은 어떻게 조달할지도 반드시 고려해야 한다. 소프트웨어 시스템은 그렇게 깊게 고민해 설계되는 경우가 아주 드물다.
언제가 이루어질 폐기가 매끄럽게 진행되게 하려면 시스템을 설계할 때 무엇을 고려해야 할까?
- 내 제품의 고객이 잠재적인 대체품으로 이주하기가 얼마나 쉬울까?
- 내 시스템을 한 부분씩 점진적으로 교체하려면 어떻게 해야 할까?
프로젝트의 장기 지원 여부는 조직에서 프로젝트를 처음 승인할 때 결정된다. 소프트웨어가 론칭되고 나면 할 수 있는 일은 계속 지원하거나 조심스레 폐기하거나 어쩔 수 없는 외부 요인이 발생하여 운영을 중단하거나 셋 중 하나이다. 따라서 회사에서 기대 수명동안 제대로 지원하지 못할 것 같은 프로젝트는 시작하지 말자. 폐기시키기로 결정하는 것에도 비용이 든다.
15.3 폐기 유형
폐기의 유형을 크게 권고와 강제로 구분한다.
15.3.1 권고 폐기
권고 폐기는 기한이 없고 조직에서도 우선순위가 높지 않은 경우이다. 이 유형의 폐기에는 대체로 강제성이 없다. 고객이 알아서 움직여주기를 희망한다.
권고 폐기는 새로운 시스템이 출시됐음을 알리고 이용해보라고 권하기 좋은 수단이지만 베타 수준일 때는 해서는 안 된다. 반드시 기능과 안전성 모두 정식 서비스가 가능한 수준에 올라섰을 때 그리고 새로운 사용자를 확실하게 지원할 준비가 되었을 때 시행해야 한다.
권고 폐기는 사용자들을 원하는 방향으로 움직이게 슬쩍 찔러보는 정도라서 대다수가 움직여주리라고 기대해서는 안 된다.
15.3.2 강제 폐기
강제 폐기는 대개 낡은 시스템의 지원 종료일을 못 박는 형태로 이루어진다. 종료일까지 이주를 끝내지 못한 시스템은 제대로 작동되지 않을 것이다.
큰 조직에서는 강제 폐기를 효율적으로 수행하려면 기존 시스템을 완전히 제거하는 역할을 전담할 팀을 하나 따로 꾸리는 것이 가장 좋다. 그리고 강제 폐기가 잘 이루어지려면 일정대로 집행할 수 있는 권한이 주어져야 한다. 이주 과정에서 충분히 경고하였다면 기한을 넘겨서까지 기존 시스템을 이용하는 시스템에 문제가 생겨도 책임을 묻지 않도록 해야 한다.
또 정책적으로 뒷받침되더라도 강제 폐기는 정치적 반대에 직면할 수 있음을 염두해둬야 한다.
구글에서는 어떤 시스템을 폐기시켜야 할 때 담당 팀이 디데이 몇달 또는 몇주전에 서비스의 점진적인 일시 중지 일정을 계획해 공표한다. 이 실험을 통해 인지하지 못하던 시스템들 사이의 의존성을 새로 발견하는 경우가 많다. 의존성을 발견한 팀은 폐기에 대비한 해법을 계획하거나 여의치 않으면 폐기 담당팀과 협의해 일정을 조율할 수 있다.
15.3.3 폐기 경고
해당 시스템이 폐기 대상임을 프로그래밍적으로 알려주면 좋다. 폐기 경고는 새로운 사용자 유입은 대체로 막아주지만 기존 사용자를 이주시키는 데는 효과가 거의 없다.
사용자에게 전달되는 폐기 경고 메시지에 반드시 담겨야하는 특성으로 실행 가능서과 적시성이 있다.
해당 문제와 관련한 전문 지식을 갖춘 평균적인 엔지니어가 이론적으로 뿐 아니라 실질적인 조치를 취할 수 있다면 실행 가능한 경고이다.
폐기 경고가 유용하려면 적시에 떠야 한다. 사용자가 실제로 관련 동작을 수행할 때 경고가 뜬다면 적절한 때라고 할 수 있다.
그리고 기회가 될 때마다 경고하려는 충동은 자제하자 경고를 쏟아내게 되면 우호적인 엔지니어들까지 질리게 할 수 있다.
15.4 폐기 프로세스 관리
15.4.1 프로세스 소유자
구글에서는 시스템이 아무리 경고를 쏟아내도 소유자가 명확하지 않으면 폐기 프로세스가 진척되지 않음을 배웠다. 소유자 없이는 아무것도 폐기시키지 말자 그리고 폐기 업무를 시스템 이용자들에게 절대 떠넘기지 말자. 책임자를 두어 폐기에 필요한 전문지식을 집중시키면 집행 비용을 더 투명하게 알 수 있어서 실제로도 비용이 절감된다.
15.4.2 마일스톤
새로운 시스템을 구축하는 프로젝트에서는 일반적으로 마일스톤이 명확하다. 점진적인 개발 방식을 따라 팀은 기능을 하나씩 구축하여 사용자에게 제공하며 사용자는 새로운 기능을 활용할 때마다 혜택을 얻는다.
이와 대조적으로 폐기 프로젝트는 낡은 시스템을 완전히 제거하는 것만이 유일한 마일스톤이라고 생각하는 경향이 있다. 폐기팀을 관리할 때도 측정할 수 있고 고객에게 가치를 전달해주는 명확하고 점진적인 마일스톤들을 세워야 한다. 폐기시킬 때도 핵심 컴포넌트들을 하나씩 제거하는 걸 점진적 마일스톤으로 삼으면 효과가 좋았다.
15.4.3 폐기 도구
발견
폐기를 진행하는 내내 특히 초기 단계에서는 낡은 시스템을 누가, 어떻게 이용하고 있는지를 알아야 한다. 그리고 어떻게 이용 중인지에 따라 폐기를 계속 진행할지 혹은 결정을 번복해야 할 지를 다시 검토해야 할 수도 있다.
구글에서는 Code Search 같은 검색도구와 Kythe 같은 정적 분석 도구를 써서 폐기시킬 라이브러리를 누가 이용 중인지를 코드를 돌려보지 않고도 알아낸다. 또 폐기시킬 심볼의 참조가 모두 제거되었는지를 확인하는 데 전역 테스트 스위트를 신탁처럼 이용한다.
마이그레이션(이주)
퇴행 방지
새로 작성하는 코드에서 폐기중인 대상을 이용하는 것을 퇴행이라 한다. 퇴행을 실무 수준에서 방지하기 위해서 구글에서는 Tricorder라는 정적 분석 프레임워크를 이용한다. 폐기 중인 시스템을 호출하는 코드를 추가한 사용자에게 적절한 대처 방법을 피드백할 수 있다.
거시적으로는 빌드 시스템에 가시성 허용목록을 도입하여 폐기된 시스템에 의존하는 시스템이 새로 생겨나는 일을 막는다.
15.5 마치며
폐기가 축제가 끝난 거리를 청소하는 지저분한 일처럼 느껴질 수 있으나 이런 노력 덕분에 유지보수 부담이 줄고 소프트웨어 생태계가 개선된다. 점점 커지고 복잡해져가는 소프트웨어 시스템을 오래도록 관리하려면 새로운 소프트웨어를 구축해 운영하는 것만으로는 부족하다. 낡았거나 더는 쓰이지 않는 시스템은 없애줘야 한다.
15.6 핵심 정리
- 소프트웨어 시스템이 존재하는 한 유지보수 비용은 계속 발생하므로 제거하는 비용과 저울질해봐야 한다.
- 시스템을 원래 의도와 다르게 사용하는 사용자가 많기 때문에 제거하는 일이 아예 처음부터 만들기보다 어려울 때도 많다.
- 폐기 비용을 생각하면 기존 시스템을 개선하는 편이 일반적으로 더 저렴하다.
- 폐기 여부를 결정하려면 비용을 따져봐야 한다. 생태계 비용은 곳곳에 퍼져있어서 측정하기 어렵다.