[LIFULL] 부서 배속 100일 회고 (7년 된 legacy system에 新기능 구현하기)

🧑🏻‍💻입사 156일차 / 🇯🇵일본 입국 128일차

 

    22년 9월 3일, 오늘로써 드디어 부서에 배속을 받은 지 벌써 100일이 되었다. 배속 후, 지금까지 이런저런 일들이 정말 많이 있었는데, 그 중에서도 먼저 제일 기억이 많이 남는 新기능을 구현에 대해서 기록하려고 한다.

 

현재 부서에서 담당하고 있는 서비스

    배속된 부서에서 담당하고 있는 서비스는 몇가지가 있지만, 제일 큰 규모를 차지하는 것이 LIFULL HOME'S 부동산 아카이브라는 서비스이다. 서비스 이름에서 어느 정도 알 수 있겠지만, 일본 내에서 LIFULL 을 거쳐간 모든 부동산의 과거 정보(임대, 매매, 토지 등의 시세, 주변 역 등등 제공하는 정보가 다양) 를 archiving 해둠으로써 집을 찾는 사람들이 보다 쉽게 지역별 부동산 정보를 얻을 수 있도록 도와주는 데이터베이스 역할을 하는 서비스이다.

LIFULL HOME'S 부동산 아카이브

    누군가에게 반쯤 지나가다 들은 것이라 정확한 사실은 아니지만, 부동산 정보 얻고자, 검색하여 LIFULL HOME'S (이하 LH) 웹 사이트에 들어오는 사람의 절반 정도는 부동산 아카이브를 통해 유입된다고 한다. 그래서 부서 안에서 시책으로 제시되는 SEO 최적화나 UI 개선 들도 결국 모두 LH 사이트로 유저들이 넘어가는 비율(보통, 송객률이라고 한다)을 높이기 위한 시책이 주를 이룬다. 내가 담당하게 된 新기능도 이러한 흐름에서 제시된 시책이었다.

 

구현하고자 하는 新기능

    인터넷을 통해 살고 싶은 집을 검색해보는 사람들이 제일 보고 싶어하는 것이 아마도 그 집의 내/외부 사진들일 것이다. 내가 구현한 기능도 부동산 아카이브에 모여있는 건물들의 각 호수의 사진들을 모아서 보여주는 기능(통칭 갤러리 페이지)이었다. 각 건물 별로 있는 여러 호수의 방, 주방, 화장실 등의 사진을 한 페이지에 모아서 보여주는 기능이었다.

실제 갤러리 페이지의 모습

    구현을 시작하기 전, 기능 사양서를 확인하고 DB 를 확인할 때까지는 크게 까다롭지 않은 기능 구현이라고 생각했다. 단순히, 각 건물의 ID 값과 1:N 관계를 가지는 각 호의 ID 를 조회해서 가지고 오고, 그와 관련된 이미지를 가져오기만 하면 되었고, 별도의 pagination 도 없이, S3 Bucket 에 저장되어 있는 URL을 가져오기만 했으면 되었다.

 

프로젝트 Source code 를 마주하다

    그렇게 시작은 매우 가벼운 마음으로 시작했지만, 그 마음은 오래 가지 않았다. 부동산 아카이브 프로젝트는 2016년에 시작되어 PHP 로 구성된 프로젝트이다. 기본적으로 MVC 패턴과 DI 를 도입하고 있었지만, 따로 프레임 워크나 라이브러리를 사용한 것이 아니라 누군가(?)가 만든 Custom framework 에 오랜 시간동안 여러 엔지니어들의 손을 거쳐와 지금의 코드가 되어있었다.

    그래서 일까...? 프로그래밍을 배우고 처음으로 보는 Biz 라고 하는 부분에 Business logic 들이 Controller 와 1:1 관계로 모두 분리되어 있었고, 그 중간 어딘가 애매한 위치에 Service 들도 이곳저곳에 끼여 있었다. Front End 는 Responsive design 이 아닌 HTML, CSS, 심지어 JS 까지 같은 내용의 중복된 코드들이 PC와 SP로 각각 분리(나중에 이부분에서 많이 번거로웠다...)되어 있었다.

    약 7년이라는 짧다면 짧고, 길다면 긴 기간 동안 큰 변경이나 버전 업이 있었는지는 모르지만, 실제 Product 의 소스코드는 역시 규모가 크구나하는 놀람과 함께 한 편으로는 이렇게 복잡한 구조를 가진 코드들을 언제 다 파악하지 하는 걱정이 더 컸다. 또한, Back End 뿐만 아니라 Front End 도 모두 구현을 담당하기로 했기 때문에, Routing 을 시작으로 조금씩 코드의 여기저기를 만지작 만지작 하면서, 구현에 필요한 모든 구조를 파악하는데 약 2~3일 동안 소요되었던 것 같다.

 

기능 구현을 완료하고 리뷰를 받다

    그래도 선배들에게 어찌저찌 도움을 받아서, 약 일주일에 걸쳐 Front 와 Back End 구현을 마쳤다. 하지만, 진짜 어려웠던 것은 그 뒤 Front 와 Back End 로 나누어 2명의 선배 엔지니어들에게 소스 코드 리뷰를 받기 시작하면서 시작되었다. 나 스스로는 화면이 디자인대로 잘 나와있으니까 괜찮겠지? 하면서 합리화를 하고 있었던 것 같다.... 하지만, 내가 작성한 코드들은 기존 프로젝트의 구조를 전혀 고려하지 않은채 나만의 스타일로 분류되어 있었고, 변수나 메서드 이름, 심지어 파일의 위치와 이름 등등도 모두 기존 프로젝트 구조에 맞춰서 수정해야했다.

    그리고 새롭게 추가된 코드의 안정성을 담보하기 위한 E2E 와 Unit test 작성도 반드시 해야했었기 때문에, 테스트 코드를 한번도 작성해본적 없던 나에게는 정말 힘든 시간이었다. 지금 이 순간에도 Mock data 를 위한 allow / andReturn, Unit test 를 위한 exptext / toBe 가 머리 속에 빙빙 도는 것 같다. (이 후, 시나리오 테스트 사양서를 작성하는 것도 쉽지 않았다... )

    이렇게 모든 기능을 구현한 결과, 마지막 Approve 를 받고 Merge 가 되기 직전 소스 리뷰의 갯수는 205개가 되어있었다. Front 와 Back End 구현을 동시에 했기 때문에 리뷰내용이 많았던 것도 있었지만, 위에서 언급한 자잘한 수정 사항들을 계속 다시 반영하고 반영하다 보니 실수를 하거나 놓친 부분도 정말 많았다. 이 때 처음으로 알고리즘이 아닌 단순 기능 구현에서 내가 생각보다 코딩을 잘 못하는 거일 수도 있겠구나... 라고 많이 느끼고 반성했다.

실제 Merge 후, 갤러리 페이지의 PR

 

실제 서비스 중인 프로젝트의 新기능을 구현 하면서 느낀 것들...

    첫 번째로 무엇보다 제일 크게 느낀 것이 소스코드를 읽고 구조를 파악할 수 있는 능력의 중요성이었다. 기능 구현에 사용했던 약 3주간의 기간 중 30~40% 이상의 시간을 기존 소스코드를 읽는데 사용했다. 그럼에도 불구하고 코드 구조를 내 마음대로 분류해버렸고, 그 구조들을 다시 고치는데 꽤 많은 시간을 사용해버렸다.

    두 번째로 느낀 것은 테스트의 중요성이다. 이렇게 구현된 기능은 develop 브랜치로 merge 되어 바로 내부 테스트 서버로 배포되는데, 구현 때 함께 작성한 테스트 사양서 대로 확인을 하고자 창을  하였는데, 바로 500 에러가 생겼다. 아무리 에러가 날 이유가 없는데 하고 있던 중 선배 엔지니어가 JS Minify 가 문제일 수도 있다고 이야기 해주었고, 바로 개발용 서버에서 확인해보자 똑같이 500 에러가 재현되었다. (원인은 Minify 패키지로 사용하고 있는 uglify-js 가 ES6 이상을 지원하지 않았기 때문이다...) 만약 이게 테스트 서버 확인없이 바로 라이브서버에 배포 되었다면, 정말 끔찍하다..

    세 번째로는 정말 꼼꼼한 확인이 엔지니어로 부터 필요하다는 것이다. 기능 구현을 다하고 난 뒤에도 무분별한 Flow control 사용으로 발생한 Cognitive complexity 를 해소하고, 이미지가 한 장도 없는데 없는데 타이틀이 나오는 버그를 해소하기 위해, 한 3개의 PR정도 다시 수정하는 작업을 했다. 소스 코드를 리뷰를 하는 사람, 아이디어를 낸 기획자, 디자인을 작성한 디자이너 등등 정말 여러 사람들에게 수차례 더블 체크를 받음에도 결국 문제가 발생하였다. 하지만 그 상황마다 왜 그 문제가 발생했는지 제일 잘 알고 있는 것은 결국 나였다. 그 뜻은 기능 구현을 맡은 엔지니어가 꼼꼼하게 잘 체크한다면 일을 2, 3번 다시 하는 일이 없을 것이라는 것이다.

    마지막으로 네 번째는 기능 구현 외에도 비지니스 적으로도 고려해야 할 점이 정말 많다는 것이다. 기능 구현을 하면서 까다롭게 느껴지기도 했고, 학생 때 한 번도 경험해보지 못했던 것이 SEO 최적화와 고객 데이터 관리와 같은 부분이었다. 결국 실제로 사용중인 부동산 아카이브와 같은 Product 들은 사용자 데이터를 끊임없이 분석하고, 노출 빈도를 높임으로써 가치 창출 또는 수익을 내기 위해서 존재한다. 그를 위해서 각 페이지에 적절한 Tag 나 수 없이 많은 Cookie 를 추가하고, Sitemap 을 생성해야하기도 한다. LIFULL 의 엔지니어 조직에서 말하는 "기술로 경영을 리드한다" 라고 하는 슬로건이 이때 정말 크게 와 닿었던 것 같다.

 

결론

    이렇게 여러 고난(?)을 겪으면서 어느정도 8~90% 정도 구현을 마치고, 스스로에게 현타를 느끼고 있던 나에게 선배 사원들이 이렇게 新기능 구현할 기회 자체가 잘 없기도 하고, 0 부터 100 까지 구현하는 것은 내가 맡았어도 어려웠을 거다. Front, Back End 도 주로 분담해서 구현하는데 처음으로 맡은 업무치고 양 쪽 다 잘 구현 했다고 말해주었을 때는

다음에는 더 잘해야겠다!

라고 정말 많이 생각했다. 지금 이 감정을 잊지 말고, 앞으로 200일, 300일 이상 꾸준하고 부지런하게 할 수 있도록 노력해야겠다..!!