[구글 엔지니어는 이렇게 일한다: 구글러가 전하는 문화, 프로세스, 도구의 모든것] CHAPTER 15 폐기 - 요약 & 발제문

사용 중인 낡은 시스템을 떼어내 새로운 환경으로 이주시키는 작업을 순차적으로 진행하여 궁극적으로는 낡은 시스템을 완전히 걷어내는 과정을 폐기라 합니다.

1. 폐기시키는 이유

‘코드는 자산이 아니라 부채다’ 라는 기본 전제에서 시작합니다. 코드가 자산이라면 낡은 시스템의 비중을 줄이고 제거할 이유가 어디 있겠습니까? 시스템을 운용하는 데 드는 운영 자원, 그리고 주변 생태계의 진화에 발맞춰 코드베이스를 업데이트하는 노력 등 비용이 계속 투입된다는 사실은 낡아가는 시스템을 계속 운영할지 아니면 슬슬 폐기시킬지를 놓고 손익을 저울질해봐야 함을 뜻합니다.

2. 폐기는 왜 그리 어려운가?

• 하이럼의 법칙에 의해 시스템은 사용자 수가 늘수록 설계자가 예상하지 못한, 전에 본 적 없는 방식으로 이용될 가능성이 커져서 폐기 작업을 그만큼 어렵게 만듭니다.
• 새롭게 만들어질 시스템과 폐기할 시스템의 기능이 일대일로 일치하는 일은 드물며, 옛 시스템의 쓰임 하나하나를 새로운 시스템을 기준으로 새로 확인해봐야 합니다.
• 옛 시스템을 향한 애착이 의외의 저항으로 나타날 수 있습니다.
• 비용을 확보해 폐기를 진행하려면 이해관계자들에게 득과 실을 납득시키기 위한 정치라는 관문도 통과해야 됩니다.

2.1 설계 단계에서의 폐기

구글은 언젠가 이루어질 폐기가 매끄럽게 진행되게 하려면 시스템을 설계할 때 다음을 권장합니다.

• 내 제품의 고객이 잠재적인 대체품으로 이주하기 얼마나 쉬울까?
• 내 시스템을 한 부분씩 점진적으로 교체하려면 어떻게 해야 할까?

회사에서 기대 수명 동안 제대로 지원하지 못할 것 같은 프로젝트는 시작하지 마십 시오. 회사에서 폐기시키기로 결정한다 해도 여전히 비용이 듭니다. 하지만 잘 계획하고 적절한 도구와 정책 개발에 투자한다면 이 비용을 상당히 줄일 수 있습니다.

3. 폐기 유형

폐기의 종류는 ‘권고’와 ‘강제’로 구분합니다.

3.1 권고 폐기

권고 폐기는 기한이 없고 조직에서도 우선순위가 높지 않은 (혹은 폐기 작업에 자원을 투입할 의지가 없는) 경우입니다. 이 유형의 폐기에는 대체로 강제성이 없습니다. 권고 폐기는 새로운 시스템이 사용자에게 주는 혜택이 매우 클 때 효과가 좋습니다.

3.2 강제 폐기

강제 폐기는 대개 낡은 시스템의 지원 종료일을 못 박는 형태로 이루어집니다. 강제 폐기를 효율적으로 수행하려면 기존 시스템을 완전히 제거하는 역할을 전담할 팀을 하나 따로 꾸리는 게 가장 좋습니다. 또한 일정대로 집행할 수 있는 권한도 주어져야 합니다.

3.3 폐기 경고

권고 폐기든 강제 폐기든 해당 시스템이 폐기 대상임을 프로그래밍적으로 알려주면 좋습니다. 단 경보 피로가 누적되지 않도록 경고 메시지에 실행 가능성과 적시성을 명시해야 됩니다.

실행 가능한 경고는 해당 문제와 관련한 전문 지식을 갖춘 평균적인 엔지니어가 이론적으로 뿐 아니라 실질적인 조치를 취할 수 있는 것입니다. 또한 이러한 실행 가능한 경고가 적시에 떠야 합니다. 예를 들어 함수 폐기 경고는 엔지니어가 해당 함수를 사용하는 코드를 작성할 때 알려주는 게 가장 좋습니다.

4. 폐기 프로세스 관리

폐기 프로젝트는 관리하고 실행해야 한다는 점에서 다른 소프트웨어 엔지니어링 프로젝트와 비슷합니다. 대신 차이점은 다음과 같습니다.

4.1 프로세스 소유자

소유권을 조정하다 보면 종종 버려진 프로젝트들이 문제를 일으킵니다. 구글은 프로젝트에 소유자가 없다면 폐기 전문가를 배정하여 시스템을 완벽하게 걷어냅니다.

4.2 마일스톤

폐기 프로젝트에서는 낡은 시스템을 완전히 제거하는 것만이 유일한 마일스톤이라고 생각하는 경향이 있습니다. 폐기팀을 관리할 때도 핵심 컴포넌트들을 하나씩 제거하는 걸 점진적 마일스톤으로 삼으면 효과가 좋습니다.

4.3 폐기 도구

대규모 변경 프로세스와 코드리뷰와 같은 폐기 도구를 사용하여 낡은 시스템 폐기 관리를 하면 ‘발견’, ‘이주’, ‘퇴행 방지’라는 이점을 줍니다.

발견

폐기를 진행하는 내내, 특히 프로세스의 초기 단계에서는 낡은 시스템을 누가 그리고 어떻게 이용하고 있는지를 알아야 합니다. 이때 쓰이는 발견 도구들은 폐기 프로세스 내내 진척 상황을 파악하는데 이용됩니다.

구글의 발견 도구로써 Code Search 같은 검색 도구와 Kythe 같은 정적 분석 도구가 있습니다. 또한 폐기시킬 심볼의 참조가 모두 제거되었는지를 확인하는 데 전역 테스트 스위트를 신탁처럼 이용합니다.

마이그레이션(이주)

구글에서는 폐기에 필요한 일의 상당 부분을 앞에서 이야기한 코드 생성 및 리뷰 도구들을 활용해 처리합니다. 특히 새로운 라이브러리나 런타임 서비스를 이용하도록 코드베이스를 업데이트할 대는 대규모 변경 프로세스와 도구가 매우 유용합니다.

퇴행 방지

새로 작정하는 코드에서 폐기 중인 대상을 이용하는 걸 퇴행이라 합니다. 구글은 퇴행을 실무 수준에서 방지하기 위해 Tricorder라는 정적 분석 프레임워크를 이용합니다. 거시적으로 빌드 시스템에 가시성 허용목록을 도입하여 폐기된 시스템에 의존하는 시스템이 새로 생겨나는 일을 막습니다. 자동화된 도구가 정기적으로 허용목록을 검사하고, 낡은 시스템과 의존성을 끊은 시스템들은 리스트에서 제거해줍니다.

5. 마치며

점점 커지고 복잡해져 가는 소프트웨어 시스템을 오래도록 관리하려면 낡았거나 더는 쓰이지 않는 시스템은 없애줘야 합니다. 정책과 도구를 적절히 활용하여 사회적인 장애물과 기술적인 문제를 잘 관리해야 폐기 프로세 스가 완벽하게 이루어질 수 있습니다. 체계적으로 잘 관리되는 폐기 프로세스가 조직에 큰 보탬이 된다는 사실을 깨닫기가 쉽진 않겠지만, 오래 살아남기 위해서는 반드시 필요합니다.

발제문

현대의 기업들은 대부분 자신들의 업무를 지원하거나 제품을 제공하는데 소프트웨어 시스템에 의존합니다. 하지만 이러한 시스템들은 시간이 지나면서 더 이상 필요하지 않게 되거나, 기술적으로 낡아 비효율적이게 됩니다. 이럴 때, 우리는 시스템을 폐기하는 것을 고려합니다. 구글은 이 책에서 시스템 폐기의 필요성, 그 과정에서 마주치는 어려움, 그리고 이를 관리하는 방법에 대해 설명했습니다.

1. CHAPTER15 폐기는 ‘코드는 자산이 아니라 부채다’라는 말에서 출발합니다. 시스템을 계속 유지하려면 운영 비용이 들게 되고, 시스템을 업데이트하기 위해 노력을 투입해야 합니다. 이런 점들을 고려하면, 기존의 낡은 시스템을 계속 유지하는 것보다 새로운 시스템으로 이동하는 것이 효율적일 수 있습니다. 하지만, 이러한 폐기 과정은 그렇게 쉽지만은 않습니다. 하이럼의 법칙에 따르면, 시스템이 사용자 수가 늘어나면 이용 방식도 다양해지고, 이로 인해 폐기 작업이 복잡해질 수 있습니다. 또한, 새로운 시스템과 기존 시스템의 기능이 완벽하게 일치하는 경우는 드뭅니다. 이외에도, 기존 시스템에 대한 익숙함과 애착, 그리고 폐기 비용에 대한 이해관계자들의 인식 등이 폐기 과정을 어렵게 만드는 요인들입니다.
   
   여러분은 이러한 폐기 과정을 어렵게 만드는 요인들을 뚫고 낡은 시스템을 걷어내 본 경험이 있나요? 있다면 멋진 무용담을 들려주세요!
   
   
2. 폐기 과정은 크게 '권고 폐기'와 '강제 폐기'로 나눌 수 있습니다. 권고 폐기는 새로운 시스템이 사용자에게 주는 혜택이 클 때 효과적이며, 강제 폐기는 일정 기간 후에 낡은 시스템을 완전히 제거하는 방식입니다. 폐기 과정을 관리하는 방법에 대해 살펴보면, 폐기 프로젝트는 다른 소프트웨어 엔지니어링 프로젝트와 비슷하게 관리해야 합니다. 소유자, 마일스톤, 그리고 도구 등을 통해 폐기 과정을 체계적으로 관리할 수 있습니다. 특히, 폐기 도구를 활용하면 시스템을 찾아내고, 이를 새로운 시스템으로 이주하고, 퇴행을 방지하는 등의 이점을 얻을 수 있습니다.
   
   우리가 사용하고 있는 라이브러리의 deprecated 경고문을 보고 최신 코드를 적용해 본 경험은 누구나 가지고 있을 것입니다. 여러분은 구글이 말하는 폐기 프로세스 관리를 느껴본 적이 있나요? 이처럼 우리는 구글에서 일하고 있지는 않지만 우리의 개발 일상에도 구글 정신을 간접적으로 체험해 본 거 같다면 공유 부탁드립니다.

본서