나는 작은 회사의 개발자로 근무 중이다. 회사는 10년이 좀 넘었다. 회사에는 회사의 핵심 서비스가 있고, 그것을 둘러싼 일종의 중계서버로서의 소, 중 규모의 서비스들이 위성처럼 핵심 서비스 주변을 맴돌고 있다.
중계 서비스는 회사의 경력만큼 오래된 것들이 있다. 몇 개는 php로 되어 있고, 한 두 개는 자바7과 스프링 레거시로 되어 있다. 현재 개발하는 새로운 서비스는 스프링부트로 개발 중에 있다.
특히 php로 된 오래된 서비스들은 큰 수정 없이 오래 동안 방치되어 있다. 가끔 문제가 생기거나 데이타를 추출할 때 나는 그것들을 살펴본다. 회사는 오래된 서비스에 대하여 고도화를 하거나 재개발할 생각이 없다. 회사가 이것을 방치하는 것은 옳은가?
사실, 방치가 아니라 신뢰일지도 모른다. 오래된 서비스가 오랫동안 방치 된다는 의미는, 다른 사람이 신경 쓰지 않더라도 자신의 주어진 업무를 충실하게 잘 해낸다는 의미니까. 조금 늙고 불통에 개발자에게 호의적이지 않지만, 그래도 자기 자신의 역할을 충실하게 해나가는 노견과 같다. 굳이 그런 충견을 회사 입장에서 돈과 시간을 쓰며 버리고 새로 만들 이유는 없다.
자바 개발자로 이뤄진 우리 회사에서 누군가는 그것들을 돌봐야 한다. 그리고 신입인 나는 울며 겨자먹기로 php의 운영 및 유지보수 업무를 하고 있다. 덕분에 php를 배웠다. 내가 가진 php에 대한 기술은 소스를 읽고 어떤 식으로 db와 통신하는지 이해하고, 필요에 따라 소스를 수정할 수 있는 낮은 수준이다.
php를 다루는 것이 처음에는 싫었지만 지금은 뭐 괜찮다. php를 읽고 수정하는 과정에서 배울 점은 분명하게 있으니까. 언어와 프레임워크가 가지는 인프라로서의 기능과 특징, 기술을 깊게 이해하는 것은 중요하다. 하지만 그 위에 올려져 있는 비지니스 로직은 자바로 하는 그것과 큰 차이를 가지지 않는다. 나는 php의 비지니스 로직을 읽고 이해할 수 있고, 수정할 수 있다.
그럼에도 불구하고, php로 된 서비스에 장애가 생기고 그것을 해결해야하는 순간이 찾아 오면 부담스럽다. 차라리 내가 그 소스를 매일 붙들고 있으면 괜찮다. 하지만 그것들은 정말로 두, 세 달에 한 번 장애가 발생하고, 그 기간 동안 나는 그 로직이나 특징 등을 모두 잊어버리기 때문이다. 처음으로 돌아간다. 소스를 처음부터 끝까지 다시 읽고 분석한다.
이래저래 문제는 많다. 한편, 큰 문제는 또 아니라고 생각한다. 가끔 손 봐야 하긴 하지만 그러나 그것은 자신의 소박한 업무를 충실하게 하니까.
기술부채는 짐이 가득한 집과 같고, 그것의 해소는 소라게가 새로운 집을 찾는 여정과 같지 않을까
나의 생각으로 기술부채는 1) 오류가 계속 발생하여 계속적인 유지보수를 요구하거나 2) 개발자가 어떤 장애에 대해 개발로 문제를 해소하는 것이 아닌 운영이나 직접적 조작을 통해 해소해야 하는 상황이 발생하거나 3) 서비스가 성장하여 고도화를 하거나 모듈이 늘어나는 순간 급증한다고 생각한다.
앞서의 오래된 서비스는 기술부채로서 남아있다. 그러나 해당 서비스에 대하여 추가기능이 요구되지 않고 문제 발생도 매우 적기 때문에 큰 문제가 아닐 수 있다. 그러니까 나의 생각에 기술부채는 그 서비스가 사용하는 언어나 서비스 운영 기간과 비례하지 않는다고 생각한다. 그보다는 잘 만들지 못한 서비스에 대하여, 혹은 급격하게 성장하는 서비스에 대하여 기술부채가 발생한다고 본다.
한 웹 어플리케이션의 서비스의 규모가 늘어난다는 것은, 해당 어플리케이션이 가지는 코드의 양이 늘어난다는 것과 같다. 비지니스 로직은 복잡해지고 수많은 예외에 대응해야 한다. 조건절의 깊이가 늘어난다. 코드를 이해하기 위하여 필요로한 시간이 늘어난다. 모듈화의 한계에 봉착하여 유사한 매서드가 발생하기 시작한다. 테이블이 하나 둘 씩 늘어나 수십 개로 이뤄지기 시작한다.
나는 이러한 현상을 보며 기술부채는 일종의 대청소와 유사하다는 느낌을 받는다. 버릴 것은 버리고 필요한 것만 남겨야 한다. 집에 사람이 하나 둘 씩 늘어나고 잡동사니가 쌓여가면 어느 순간 더는 감당이 안된다. 개발자가 서비스를 통제하지 못하고 서비스가 개발자를 압도한다.
하지만, 서비스를 대청소 할 수는 없다. 서비스는 멈추면 안된다. 버려서는 안되는 어떤 것을 실수로 버리는 순간 서비스가 아예 망가질 수 있다. 그러므로 대청소는 기존의 집을 정리하는 방식으로 이뤄지는 것은 위험성이 높다고 생각한다.
나는 이것이 자신의 새로운 집을 찾는 소라게와 비슷하지 않을까 생각한다. 예전의 서비스를 답습하기 보다 새롭게 서비스를 만든다. 해당 시점에서 최대한 유연한 기획을 한다. 충분한 테스트를 진행하고 기존 서비스가 담당하는 역할을 조금씩 뺏어온다. 아마 이런 흐름이 이상적이지 않을까 싶다.
어떻게 기획해야 하는가?
msa가 유행이다. 사실 msa로 갈 필요도 없다고 생각한다. 좋은 개발 디자인 패턴이 일관적으로 가지는 철학이 있다. 결합도가 낮고 응집도가 높은 서비스를 구현이 디자인 패턴들의 가장 중요한 목표이다.
나는 핵심 서비스의 업무를 최소화하고 그것 이외의 서비스를 밖으로 빼는 것이 매우 중요하다고 생각한다. 핵심 서비스는 최소한의 크기를 유지하고, 구체적인 서비스를 구현한 여러 개의 중소규모의 서비스와 결합하는 방식으로 이뤄져야 한다고 생각한다. 마치 인터페이스를 통해 교체하는 객체처럼 말이다.
핵심 서비스는 핵심적인 비지니스 로직에 집중한다. 새로운 중계 서버는 자기 복제가 가능하고 기존의 인터페이스를 통해 쉽게 결합 가능하고 언제든 교체를 할 수 있는 수준의 규모를 유지한다.
오래된 유산을 새롭게
정리해보자. 그래서 오래된 php 어플리케이션(정확하게는 레거시가 된 프로젝트)를 내가 다루면서 예전에는 불만이었지만 지금은 괜찮은 이유는 두 가지 정도이다. 첫 번째는 비지니스로직을 이해한다는 차원에서 최신 기술과 예전의 기술은 생각보다 큰 차이가 없을 수 있다는 직감 때문이다. 두 번째는 예전 개발자에게 마음 속으로 욕하면서 코드를 비난할 수 있어서이다.
두 번째는 매우 중요한 감정이자 개발의 원천이라 생각한다. 실제로 나는 php로 개발된 서비스를 6개월 정도 운영하고, 그것을 자바/스프링으로 바꿨다. 회사 입장에서는 그냥 냅두고 싶었을테다. 하지만 보안 상 문제 때문에 불가피하게 재개발하였고, 그것을 내가 담당했다. 그리고 개인적으로 만족스럽게 만들었다.
하지만 전적으로 내가 잘해서 잘 만들었다고 생각치 않는다. 레거시 프로젝트가 있었고, 나는 그것을 입사하고 5개월 동안 다뤘기 때문에 무엇이 장점이고 무엇이 단점인지를 잘 알 수 있었다.
해당 개발을 한 사람은 아마도 어떤 샘플도 없이 혼자 만들었을테다. 그 과정에서 번뜩이는 아이디어도 있었지만 불필요한 기능이나 반복되는 코드가 존재했다. 그러한 장단점을 내가 잘 끌어안으려고 노력했다. 이전 개발자의 노고 덕분에 만족스러운 서비스를 만들 수 있었다.