레거시를 대하는 나의 자세

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

구글에서 검색하면 제일 위에 나오는 단어 이다. 아마 개발자라면 누구나 접하고 보고 듣고 경험 하는 시스템일거 같다. 

 OKKY 에서 TDD 관련 강의를 보다 어느 분인지 기억은 안나는데 명언을 하셨고 그게 확 와닿았다. 

 

 " 어제 내가 만든 소스도 레거시 입니다.  기억이 안나니까요"

와... 그랬다.. 레거시시스템을 참 싫어하면서 나도  지금 까지 수많은 레거시들을 만들었다. 왜냐면 기억이 안나기 때문이다. 

내가 겪은 회사중엔 레거시로 파티를하면 정말 대 환장 파티가 가능한곳이 상당수 있었고 , 그런 회사들의 특징은 안타깝게도 오래되고 , 안정적이고 , 관리자들에게 힘이 몰려있는경우  레거시시스템이 비례하여 많았다. 

2005년에 처음 개발을 시작해서 아직 갈길이 멀고 한창이라고 생각하지만, 아직 레거시 시스템을 어떻게 해야 할지 개인적으로는 답을 못내리고 있다. 

바꿔도 봤고 그대로 두어도 봤지만 둘다 답이 되진 않았다. 물론 내경험이 미약하여 ... 제대로 못한것도 있었고 주변환경이 안맞았던것도 있었다. 

- 바꿔야하지만 바꿀수 없다... 

 경험했던 회사중 쿠폰서비스를 하는 시스템이 있었다. 외주를 줘서 만든거 같았고 SI 업체들에서는 흔하게 그걸 만든 개발자는 퇴사를 했다고 한다. 그리고 입사 했을경우 단순 유지보수만 하고 있던 사람이 있었지만 그사람도 얼마뒤 퇴사했다. 

 내손에 이녀석이 왔다. 고칠까 ? 바꿀까 ? 다시 만들까 ? 팀장, 실장 하믈며 사장마져도 회의적이였다. 

  결론은 그대로 놔두자!! 그러고 나서 보니 아 이거 내가 잘못 생각했단 생각이 들었다. 내가 갈리고 있었다 . 안되는 요청들은 태반이고 사업팀 심지어 같은팀도 도움이 되지 않았다. 내위에 과장은 웹서비스를 해본적없는 C 개발자였고 팀장은 인프라 , 같은 개발자들은 전부 나보다 경험이 얼마 안된 신입들... 내가 독박이였다. 안되는걸 알면서 밤을 새워 보고 분명 문제가 될걸 알면서 뭔가를 덕지덕지 붙이고 있었다. 

 그렇다 ! 레거시에다 레거시를 붙이고 있었다. 문제가 있을걸 알면서도 .... 지금 그시스템은 어떻게 됬을지 모르겠다. 확실한건 아직 쓰고 있다는거다. 종종 그 쿠폰을 사은품으로 받는일이 있었기 때문에 쓰면서도 ... 복잡 미묘한 감정이.. 들었다. 

- 레거시에 금칠해봐야 레거시다 !! 

 바꿔보자 ... 다른회사에서 거의 비슷한 시스템을 다시 만났다. 이번엔 히스토리가 전무 하다. 그리고 변경도 없어서 마치 차고에 오래동안 사용안해서 먼지가 잔뜩 쌓인 티코를 만난 기분이였다. 뜯어보자 ... 하나.. 하나.. 

 Spirng Framework 를 쓴건 ..좋은데 ... 버전이 너무 낮다..2.5 버전이였다... spring boot 가 나온 마당에 고대 공룡 화석을 만났다 티코정도는 되겠지한 내가 한심스러웠다. 

 API, Web 모두... 총체적 난국이랄까... 돌아는간다... 물론 돌아는갈거다 ... 보니 7년을 그렇게 살아온 녀석이였다. 

그래서 전 회사의 경험을 거름 삼아 ! 새옷을 만들어 주고 새옷도 못입을애는 환골 탈태할 계획을 잡았다... 그게 시작이였다... 내가 진절머리날거란걸 생각지 못한 잘못된 한걸음.... 

 API 부터 바꾸었다 과감히 spring boot 2.0.1 버전으로 바꾸었고 sql , java 소스 는 모두 복사해서 그대로 붙여놓았다. 

다행(?) 인건 대부분 중요 로직은 mysql 프로시저로 다 만들어놔버려서 sql 이 그렇게 중요한게 없었고 java 소스도 마찬가지였다. 순조로웠고 QA도 무사히 통과했다. 

 Web... 이녀석이 문제였다.... JSP 로 구성되있었으나 JSP 안에는 Java, js, html 이 모두 한곳에 모여있었고 심지어 쿼리문이 들어가 있는 녀석들이 있었다... 뭐.. 좋게 말하면 Model 1... ?  구성이랄까... MVC 구성은 절대 아니였다 View 에서 모든걸 다하고 있으니 .... 

 쪼개기 시작했다... 로직따로 화면구성 따로 쿼리따로 그리고 그 쿼리를 호출할 API 를 만들고 controller, serivce 를 만들었다. 

 만들고 테스트 요청을 위해 사업팀에 QA 진행 요청을 했고 , 다됬다는 연락을 받았다. 그리고 오픈을 했다... 

근데... 장애 발생 심지어 좀 심하게 낫다. 금전 피해가 심각하게 있었고 , 서비스를 황급히 원복하고 사태 파악을 했다. 

결론은 테스트가 제대로 안됬고 , 기획자는 다됬단 말믿고 그냥 .. 나한테 다됬다고 한것...

다음 일정이 있어서 확인 못한 내잘못이 첫번째 일거 같다. 한번에 테스트가 통과한다는게 말이 되기나 하는가 ... 

 그 말도 안되는 상황을 그냥 무심코 지나쳐버린 내가 바보다 . 

그래도 난 기획자도 그리고 그기능을 사용한 사용자도 과실은 있다고 본다. 

기획자가 담당 서비스면 개편된것에 대해서 뭔가 스스로 테스트를 해봐야 하지 않나? 그리고 사용자도 분명 등록하고 제대로 등록됬는지 확인 했어야 한다. 그러나 팀장은 100% 내잘못이라고 하니... 할많하않.... 

이 상황의 끝은... 기획자는 스스로 내부 테스트를 다시 진행했고 QA 팀에 정식 QA 요청해서 두번의 거친 테스트를 시행했다... ( 진작.. 그렇게하지... ) 

사용자쪽은 다음부터 확인하겠다는 이야기를 들었다... ( 그럼 여태 안한건가 ) 

난... 쌩뚱 맞은 TDD 작성을 했다... 작성해서 코드를 붙였다... 

 레거시가 싫다. 특히 히스토리가 유실 된 녀석들은 정말 상종하기 싫다. 소스가 더러워도 히스토리라도 있으면 어느정도 유지보수라도 할수 있을거 같은데 대부분 히스토리가없어서 문제가 아닌가 싶다. 그래서 오늘도 열심히 주석을 남긴다. 내가 이렇게 싫은데 누군가 내 소스보고 욕하는꼴이 상상되서 욕좀 덜먹으려고 주석을 열심히 달고 있다. 

레거시를 갈아 엎든 그대로 두던 그건 정말 상황을 잘 고려하고 해야 할거 같다. 엎었을때의 정말 빡빡한 QA 그리고 그대로 두었을때 깔끔하게 보완가능한 솔루션 도입 그리고 상황에 맞는 해법들... 연차가 더 높아지만 더 적절하게 대처할수 있길 빈다.