개발자로서 레거시를 대하는 자세

지금은 레거시가 되어버린 과거의 a-z

나는 회사에 들어올 때 신규 제품을 만들어야 하는 사명을 띄고 입사를 하게 되었는데, 그 당시 여러가지의 이유로 CS형태의 제품을 개발하게 되었다.

이유는 여러가지가 있었는데, 결론만 말하자면 웹서비스로 구성할 수 없는 형태의 제품이었다.

CS개발을 오래 하기는 했지만 웹 하고싶던 터라 참 애매해졌다 싶었는데 제품의 모든 부분을 관여하며 기획을 겸하다 보니, 애정이 생겨버렸다.

실제로 신규 제품의 처음과 끝을 모두 경험하는 것은 재미있겠다 생각했고, 그렇게 5년의 시간이 흘렀다. 벤더사의 제품이다보니 프로세스의 단단함이 필요했고, 제품이 어느정도 안정화 되었을 때 여러가지를 시도하여 적용했다. 빌드 자동화, 테스트 자동화, 리소스 자동 동기화 등등.. 인프라 스트럭처가 맘에 드는 수준까지는 아니지만 어느정도 갖춰졌다.

하지만 구시대의 유물은 언제까지나 들고있을 수 없는 법. 이따금씩 웹 해야하는 것 아니냐는 얘기가 흘러나왔다.

리뉴얼을 결정하게 되는 과정

우선 어느 회사나 마찬가지로, 오너의 한마디가 모든 것을 바꾼다. (5년 전에 그랬으면 좋았을 것 같지만..)

사실, 그럴 수 밖에 없던 것이 외적 요인은 둘째치고 개발자를 구하기가 너무 어려워 계속 그 생각을 하기는 했었다. 또 계속 React하고싶기도 했고..

하지만 5년 전에도 그랬듯 절대 웹서비스로 제공할 수 없는 형태의 제품이었기 때문에 그 부분이 먼저 해소가 되어야 했다.

위에서는 단순히 "바꾸자" 한마디로 모든 것이 결정되나, 좋은 제품을 개발하기 위해 우리는 단순하게 바뀌어서는 실패할 것이 자명했다.

다시 개발해야한다. 어떻게?

회사에 속해 새로운 무언가를 개발할 때, 크게 두가지로 나눌 수 있다.

1. 아예 없는 무언가를 창조한다.

2. 이전에 있던 무언가를 새롭게 리뉴얼한다. (빅뱅)

우리는 빅뱅이 필요했다. 하지만 문제가 다수 있었는데, 당장 눈앞에 닥친 큰 문제는 이랬다.

첫번째 문제. 동료들의 스킬이 CS에 꽤나 오래 정체되어 있었다.

보통 회사에서는 이러한 빅뱅이 있을 때 인재 영입을 통해 돌파구를 마련하는데, 나와 꾸준히 함께했던 동료들의 박탈감을 우려하여 기존 인력으로 준비했다. 뒤에 얘기하겠지만 이러한 결정은 꽤 좋은 결정이었던 것 같다.

하지만 이러한 방법이 자칫 무모한 결정이 될 수 있기 때문에 몇가지 장치를 마련했다.

• 레거시가 되어버린 과거의 전유물은 동료들이 유지보수하지 않고, 리뉴얼에 모든 역량을 쏟을 수 있도록 모든 이슈를 도맡아 처리했다. 이는 동료들이 자칫 미안함을 가질 수 있기 때문에 모두 숨겼다.

• CS와 웹은 구조적으로 많은 부분에서 차이가 있기 때문에 지속적으로 도메인 스킬을 공유하는 절차를 가졌다.

이 때 새로운 무언가를 한다는 것은 즐거운 일이라는 것을 지속적으로 전파하고 공감하는 것이 꽤나 중요하다. 나는 어쩌다보니 다양한 언어로 개발할 기회가 많았는데, 이 과정이 꽤나 재미있었고 이를 같이 일하는 동료들이 흥미롭게 생각해 잘 굴러갔던 것 같다. (아닐수도..?)

두번째 문제. 이러한 미션이 주어졌을 때 단순히 이전에 있던 X를 Y로 트랜스파일링 하는 수준이라고 생각하는 사람들이 있다는 것.

이것은 내가 생각하는 개발자로서의 마음가짐과도 연관이 있는 내용인데, 실제로 이런 사람들이 많으면 프로젝트 또는 서비스.. 등등 꽤 골치가 아파진다.

개발자는 내가 만드는 서비스에 대한 깊은 이해가 필요하다. 특히나 이런 빅뱅이 일어날 때 레거시를 참조하는 사람들이 많다.

이런 경우에 나는 아래와 같은 방법이 필요하다고 생각한다.

• 기능을 이관하는 것 보다 기능이 필요한 이유에 대한 분석을 먼저 진행한다.

실제로 아예 다른 시선으로 접근을 해야한다. 리뉴얼 하는 데에는 단순히 생김새만 바뀌는 것이 아니다. 변경되는 아키텍처에 어울리는 형태로 재구성할 것. 이는 많은 레거시를 제거할 수 있게 만드는 과정이 된다.

그것은 기획이 하는 일 아닌가요? 라고 얘기하면 반은 맞고 반은 틀렸다. 왜냐, 단순하게 기능으로 예시를 들었지만 아키텍처의 구성이 달라질 수 있기 때문. 또 다른 이유도 많지만.. 공감 못하는 부분이 있다면 설득할 자신은 없다.

하지만 유독 이러한 부분에 대한 재능이 없는 사람들이 있을 수 있는데, 이는 잘못된 것은 아니다. 우리는 개발을 잘 하면 되니까. 하지만 같은 곳을 바라볼 필요는 있기 때문에 아래와 같은 방법이 필요하다.

• 기획안에 대한 분석을 지속적으로 같이 일하는 동료들과 깊은 수준으로 나눈다.

다 하는 내용을 왜 굳이 얘기하냐면, 그냥 하는 것 보다 어떻게 하는 것이 중요하기 때문이다.

작은 단위를 지속적으로 하는 것이 중요하다. 개발에 적용하면 MVP가 될텐데, 기획안을 분석하는 행위도 MVP처럼 지속적으로 하는 것이다. 또 공유하는 것.

이는 무슨 효과를 가져올 수 있냐면, 레거시를 새롭게 리뉴얼한다 라는 한편의 자의식을 희석시키는 효과를 갖는다.

우리는 무엇을 얻었나

사실, 아무리 새로운 무언가를 즐기더라도 내가 직접 오랜시간 쌓아올린 모래성을 무너뜨리는 것은 참 가슴아픈 일이다.

그럼에도 불구하고 우리는 무엇을 얻었을까,

가장 큰 것은 먼저 동료들이 새로운 것을 두려워하지 않는 방법을 익힌 것. 사실 즐기는 방법을 익히는 것이 가장 좋지만, 이는 개인차가 있을 수 있다.

또, 무언가를 A-Z까지 직접 만들어 가는 것. 개개인에게 오너십이 생긴 것 같다.

이 모든 과정을 거치면서 얻은 넓은 시야. 앞으로 무엇이 더 필요하고, 무엇을 더 해야겠다는 것을 능동적으로 할 수 있게 되었다.

아마 이것은 또 어느 순간 리뉴얼 될 것이다. 우리는 그제서야 또 즐길 수 있지 않을까