레거시 시스템은 언제 개편해야 할까?

국내 IT 기업은 한국을 넘어 세계를 무대로 할 정도로 뛰어난 기술과 아이디어를 자랑합니다. 이들은 기업 블로그를 통해 이러한 정보를 공개하고 있습니다. 요즘IT는 각 기업의 특색 있고 유익한 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하고 있을까요?

이번 글에서는 글로벌 알람 앱 ‘알라미’를 서비스하는 딜라이트룸이 레거시 시스템을 왜 개편해야 하는지, 그 이유와 과정에 대해 소개합니다.

어느 조직이든 존재하는 레거시 시스템은 일정 시점에 한계에 도달하며 개편이 요구됩니다. 새로운 조직에 합류하고 레거시 개편 프로젝트를 담당하면서 얻은 배움들을 공유해 보고자 합니다.

레거시 시스템, 왜 개편되어야 하는가

실무에서 레거시 시스템이라는 표현은 흔히 들을 수 있습니다. 그렇다면 레거시 시스템이라고 분류할 수 있는 기준은 무엇일까요?

위키백과에서는 레거시 시스템을 아래와 같이 정의합니다.

레거시 시스템(legacy system)은 낡은 기술이나 방법론, 컴퓨터 시스템, 소프트웨어 등을 말한다. 이는 현대까지도 남아 쓰이는 기술을 부르는 말일 수도 있지만, 더 이상 쓰이지 않더라도 현대의 기술에 영향을 주는 경우도 포함한다. <출처: 위키백과>

‘낡은 기술’은 단순히 사용한 지 오래된 기술을 말하는 것이 아닙니다. 어떤 기술이든 시간이 지나면서 기존의 것을 개선하는 여러 방법론, 시스템들이 나오게 됩니다. 레거시 시스템은 이러한 새로운 기술이 오랜 기간 적용되지 않은 채 유지되는 시스템이라고 할 수 있습니다. 실제로 업무를 하다 보면 간단한 요구사항에도 여러 곳을 수정해야 하거나, 프로그램을 확장시키는 것에 어려움이 느껴질 경우 레거시 시스템이라고 부르는 등 더 폭넓은 개념으로 사용되기도 합니다.

이 지점에서 레거시 시스템이 갖고 있는 문제는 무엇인지 정리하는 것이 개편 전략을 수립하는 데 도움을 줍니다. 레거시라 느껴진다고 해도 잘 돌아가고 있는 시스템이라면, 자원이 유한한 조직에서 레거시 개편은 불필요하거나 우선순위가 낮은 과제가 될 것입니다. 레거시 시스템을 불평하는 것은 너무나 쉬운 일이기 때문에 ‘개편’에 대한 논의가 시작되었을 때 정말 필요한가를 파고들며 불필요하게 진행되는 것을 주의해야 합니다.

• 지금 레거시 시스템이 갖고 있는 문제는 무엇인가?
• 해당 문제가 현재 업무에 어떤 영향을 주는가?
• 그 영향이 조직의 다른 목표를 우선할 정도로 중요한가?

위와 같은 질문에서 레거시 시스템을 개편해야 하는 이유를 명확히 답하지 못한다면 개편이 필요하지 않은 상황일 수 있습니다. 사용한 지 오래된 기술이라서, 신기술로 만들어진 프로그램보다 구동하는 것이 번거로워서, 소스코드를 손대기 어려워서. 이와 같이 단편적인 것보다는 구체적이고 종합적인 문제 분석이 필요합니다.

• 현재의 레거시 시스템은 외부 서비스의 의존도가 높고, 테스트하기 어려우며, 처리 속도가 느리다.
• 당장의 업무 수행에는 도움이 되지만, 새로운 기능을 추가하거나 장기적인 프로젝트의 비전을 달성하기에는 높은 복잡도로 생산성이 낮아 어려움이 있다.
• 조직에서 무엇보다 우선하고 있는 특정 가치를 달성하기 위한 핵심 도구이지만 시스템의 한계로 인한 빠른 서비스 개선이 어려우므로 개편이 필요하다.

위와 같이 조직 전반적인 관점, 비즈니스적 관점에서 바라볼 필요가 있습니다. 어떤 소프트웨어든 개선해야 할 점이 있지만 비즈니스 목표 달성, 리소스 투입 대비 효과, 해결 과제의 우선순위에 따라 전략적으로 일부러 개선 작업이 미뤄지곤 합니다.

기술적으로 부족한 점이 있어도 비즈니스 가치를 창출하고 전달하는 데 충분하다면 개편 추진은 기술 부채를 해결하고자 하는 심리이거나, 해결해야 하는 더 중요한 문제를 발견하지 못한 것일 수 있습니다. 따라서 해결할 문제로서 결정짓는 것은 기술 부채의 관점과 비즈니스 관점을 더해 종합적으로 살펴보아야 합니다.

명확하게 문제 정의를 하다 보면 어떤 부분을 개선해야 하는지, 얼마만큼의 리소스가 필요할지 감이 잡힙니다. 탄탄한 토대를 만들고 작업을 시작하는 것은 그렇지 않은 것과 큰 차이의 결과를 가져올 수 있습니다.

무엇을 개편해야 하는가?

문제 정의를 완료하고 개편을 하기로 결정했다면, 중요한 첫걸음은 요구사항을 정리하는 일입니다. 레거시 시스템에 대한 이해가 전무하고 참고할 만한 문서가 없는 상태라면 매우 고통스러운 일이 될 수 있습니다. 하지만 무엇을 개선 해야 하는지 알아야 올바른 방향과 전략을 수립할 수 있기에 필수적인 과정이죠.

개편하고자 하는 것은 전반적인 시스템 전체가 될 수 있고, 인프라 개선이나 코드 리팩터링 등 특정 범위로 나눌 수도 있습니다. 적정한 범위를 알기 위해서는 시스템을 이해하고 개선점들을 추출해야 합니다. 이때 스스로 혼자 모든 것을 파악하려고 하지 말고 기존 작업자들이나 히스토리를 아는 사람들의 도움을 최대한 많이 받기 위해 노력해야 합니다. 소스코드나 문서에 남아있지 않는 여러 의존성들이 존재할 수 있기 때문입니다.

기존 시스템 이해를 위해 해야 할 일

• 기존 작업자가 있을 경우 시스템에 대한 전반적인 설명을 요청하고 시스템을 구축하면서 어려웠던 점이 무엇인지 묻는다.
• 시스템을 파악하면서 생기는 궁금한 점은 작은 것이라도 적어두었다가 공유해서 도움을 청한다.
• 시스템이 전반적으로 실행되는 흐름을 그려보고 어떤 점이 문제인지 찾는다.

가장 위험한 것은 소스코드를 몇 번 훑어보고 시스템을 다 안다고 착각하는 것입니다. 물론 실제로 개편 작업을 시작하기 전에 모든 로직과 의존성을 파악하기란 불가능합니다. 다 아는 것 같아도, 간단해 보여도 한 번 더 확인해 보는 것이 개편 시스템 배포 후 장애를 맞이하는 가능성을 줄여줍니다. 어떤 것을 파악하고 질문해야 할지 모르겠다면 팀에서 비즈니스 히스토리를 가장 잘 알고 있는 팀원이나 리드의 도움을 받는 것도 방법입니다.

그들로부터 놓치고 있던 것을 캐치할 수 있고, 인지하고 있지 못했던 내외부 의존성에 대한 정보도 얻을 수 있습니다. ‘이 부분은 이렇게 처리되는 거겠지’ 단정 짓고 넘어가지 말고 사소한 부분이라도 공유했을 때 도움을 얻는 경우가 생각보다 많습니다. 특히 레거시 개편이라는 프로젝트는 쓸 수 있는 시간은 정해져 있지만, 작업 범위는 전략이나 계획에 따라 막연하게 커질 수 있습니다. 따라서 최대한 많은 정보를 습득하고 정리하는 것이 좋습니다.

정보를 얻었다면 개편 방향성을 정해봅니다. 아래와 같은 예시를 들 수 있겠습니다.

• 팀에 익숙한 언어로 시스템을 재구축
• 배포 인프라는 기존 시스템을 그대로 활용
• 유지 보수에 용이한 모듈 구조 도입
• 외부 서비스의 영향을 최소화할 수 있는 헥사고날 아키텍처 도입
• 불필요한 외부 서비스와의 데이터 동기화 작업 단계 제거

이렇게 정리되어 있다면 동료들이 의견을 주기도 쉬워집니다. 팀 내에 공유하고 더 좋은 방향성이 있을지 리뷰를 받고 피드백을 반영하며 발전시켜 나갑니다.

시스템 재구축 vs 리팩터링

시스템을 재구축할 것인지 리팩터링 할 것인지도 중요한 의사결정 중 하나가 됩니다. 리팩터링 크기가 새로 만드는 수준이고, 테스트하기 어려운 상황이라면 아예 새로 구축하는 방향이 나을 수 있습니다. 대신 이때 주의해야 할 것은 기존 시스템과의 호환성입니다. 새로운 시스템으로 변경되었다고 해서 이해관계자의 생산성이 크게 저하되어서는 안 되고, 기존 시스템에서의 작업 내역이나 데이터가 보존되어야 할지 아니면 증발되어도 괜찮은지 충분한 논의를 한 후 방식을 결정해야 합니다.

레거시 시스템 개편 시에는 신경 써야 할 것이 정말 많습니다. 작은 부분이라도 적어두고 한 번씩 메모한 내용을 검토하며 놓친 것은 없을지 살펴보면 도움이 많이 됩니다.

작업 단계 쪼개기

요구사항이 정리되고 무엇을 개선해야 할지 정리가 되었다면 해당 내용을 토대로 작업 범위를 나누면 좋습니다. 프로젝트를 큰 기능으로 나누고, 각 기능 내에서도 시간이 걸릴 것 같은 굵직한 기능을 나열하고 작업 범위를 정합니다. 딜라이트룸에서는 2주 단위의 스프린트로 업무가 진행되는데, 조직 내에서 사용되는 스프린트 단위를 이용해 작업 범위를 정하면 다른 팀과의 협업이나 검토 및 공유 측면에서도 수월하게 업무를 진행할 수 있습니다.

너무 짧지도 길지도 않게 적절하게 작업 범위를 정해서 1차, 2차, …, n차 순으로 진행하면 피드백도 더 자주 받을 수 있고 작업자 스스로도 방향성을 확인하면서 나아갈 수 있습니다.

이 방법은 분기별 OKR를 논의하거나 팀원들에게 공유할 때도 ‘이번 분기에 2차 작업 완료가 목표다’와 같이 쓰이며, 소통 시에도 유용하게 사용되었습니다. 검토자에게도 각 차수별로 리뷰하기에 적절한 양이 전달되어 유의미한 피드백을 받을 수 있습니다. 반드시 적절하게 작업을 쪼개어 진행해야 하는 이유입니다.

개편 이후

드디어 여러 과정을 거쳐 개편을 완료하게 되면 잠시 숨을 돌리고 난 후, 다음을 차근히 준비해 볼 수 있습니다.

• 남은 태스크 정리 및 액션 아이템 생성
• 유관자와의 정기 미팅으로 개선점을 발굴
• 회고를 통해 잘한 점, 아쉬운 점 되새기기
• 배운 점을 조직에 공유

레거시 시스템을 개편할 수 있는 리소스를 할애해 준 팀에 감사함을 느끼며 앞으로 나아갈 길을 점검하고 지나온 길을 회고해 봅니다. 잘했다 싶은 것도 있을 것이고, 아쉬운 부분도 있을 것입니다. 어떤 것이든 정직하게 마주하며 성장의 밑거름으로 삼습니다. 다음에는 더 잘할 수 있게 됩니다. 어쩌면 제가 놓친 더 좋은 방법이 있었을지도 모릅니다. 다양한 도전을 하며 그 방법을 찾아나가는 여정에 있습니다. 다음엔 더 잘할 수 있을 거라 기대하며 지난 경험에서 배운 점에 대한 회고를 마무리해 봅니다.

<원문>

레거시 시스템, 언제 개편해야 할까?
 

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.