시스템 수준 리팩토링 시작하기
실전 시스템 수준 리팩토링 사례 공유
이 글은 다른 개발자가 작성한 코드를 남은(?) 사람들이 수정해야 하는 상황을 돕다가 씁니다. 개발자인 당사자들에게는 이미 구두로 설명하고 있습니다. 그런데, 생각해보니 이런 종류의 글이 적어도 한글로는 매우 드문 현실이라 다른 분들께도 공유하기 위해 글로 씁니다. 당장 코딩을 해야 하는 개발들에게는 우리가 시도하는 행위에 대해 이름이 필요하지 않습니다. 반면에 글로만 내용을 접하는 독자들에게는 제가 시도하는 행위의 이름과 의도를 담은 개념 설명이 필요하다는 판단에 이 글로 연재를 시작합니다.
시스템 수준 리팩토링이란
시스템 수준 리팩토링이라는 표현은 많은 사람들에게 생소할 가능성이 높습니다. 이 글을 쓰는 지금 구글에서 따옴표를 활용해 시스템 수준 리팩토링이란 문구가 모두 들어있는 웹 페이지를 검색하면 모두 8건이 나옵니다.
2021년 7월 12일 검색 결과검색 페이지 숫자로는 매우 적은 것이죠. 게다가 전부 code complete란 책의 번역서의 한 섹션 제목입니다. 8개 페이지에 들어가봤는데 모두 시스템 수준 리팩토링이란 표현이 페이지에 있을 뿐, 설명이 없습니다. 가장 많은 설명이 해당 섹션을 요약한 독자의 블로그로 보이는 페이지인데 6줄의 요약문장이 있습니다. 거기에도 시스템 수준 리팩토링에 대한 설명은 없습니다. 설시스템 수준 리팩토링에 대한 설명이 필요하다는 사실을 명확히 확인하는 장면입니다.
리팩토링에서 출발
리팩터링(refactoring)은 소프트웨어 공학에서 '결과의 변경 없이 코드의 구조를 재조정함'을 뜻한다. 주로 가독성을 높이고 유지보수를 편하게 한다. 버그를 없애거나 새로운 기능을 추가하는 행위는 아니다. 사용자가 보는 외부 화면은 그대로 두면서 내부 논리나 구조를 바꾸고 개선하는 유지보수 행위이다.
'결과의 변경 없이' 라는 말을 다른 말로 바꾸면 '기능은 그대로 두고' 가 됩니다. 그런데, 보편적으로 리팩토링은 코드 수정을 전제로 합니다. 그렇다보니 코드 수정 맥락에서 주로 설명하죠. 제가 시스템 수준이라는 표현을 붙인 이유는 사고의 수준이나 시작점이 코드가 아니라는 점을 드러내려는 의도입니다.
이미 (코드) 리팩토링을 알고 있으셨던 분들에게는 아래 정의가 적절하리라 싶습니다.
사고의 수준이나 시작점이 코드가 아닌 시스템의 각종 구성요소인 리팩토링 방식
반면에, 리팩토링이 생소한 분들을 위해서는 아래와 같이 정의할 수 있습니다.
기존의 시스템을 시스템 구성과 구성요소를 살펴, 기능 변경없이 재구성하는 활동
시스템 수준 리팩토링의 가치
개발자가 떠난 후에 새로운 개발팀이 시스템을 운영해나가야 한다고 가정해보세요. 물론, 개발자가 없는 조직에서 외주 개발을 맡겨 놓은 상황에서는 어찌 할 도리가 없습니다. 우리 조직에 개발자가 있고, 그들이 기존에 만들어진 시스템을 구성하는 프로그램이나 디자인 원칙을 포함하여 시스템 구성이 현재 상태가 된 상세한 내용을 전부 알지 못한다고 가정하죠. 이럴 때 개선이 필요하면 어떻게 해야 할까요?
사실 특별한 방법은 없습니다. 시스템 개발에 들어가는 역량과 노력의 성격은 비슷합니다. 애초에 시스템의 지속 가능성을 감안한다면 특별한 일도 아니죠. 다만, 정보시스템이란 이름으로 시스템을 사용해온 거의 모든 기업에서는 개발 프로젝트가 끝난 시스템은 잘 수정하지 않는다는 가정이나 관행이 암묵적으로 깔려 있습니다. 꽤 오랜시간 업계에서 쓰이고 있는 용어인 '유지보수', '기술부채', '차세대 프로젝트', '레거시' 같은 표현이 바로 그런 현상을 대변하는 증거입니다.
저는 시스템 수준 리팩토링을 실현 가능한 기술로 갖고 있는 개발팀이라면 엄청난 사회적 낭비를 초래해온 차세대 프로젝트는 사라지리라고 생각합니다. 물론, 단기간에 벌어질 일은 아닙니다. 무작정 외주 개발에 맡기는 경영자의 행태부터 바뀌어야 할 수도 있어서 기술 역량 문제를 넘어서는 것이기도 합니다. 그럼에도 불구하고, 원칙적으로는 앞으로 나아가야 할 길에 꼭 필요한 과제인지라 (본업인 스타트업 경영에 밀려 많은 시간을 들일 수는 없지만) 틈틈이 기록하고 공유하고자 합니다.
