기술 부채를 갚기 위한 첫 발을 떼기까지

송재욱2022-03-18

도메인을 이해하고, 문제를 정의한 후, 해법을 개발하는 일을 즐깁니다.

안녕하세요. LINE+의 ABC Studio 팀에서 백엔드 개발자로 살고 있는 송재욱입니다. 제가 제 자신을 개발자로 소개할 때 사용하는 문장이 있습니다.

도메인을 이해하고, 문제를 정의한 후, 해법을 개발하는 일을 즐긴다.

개발자는 단순히 코드만 짜는 사람이 아닙니다. 물론 코드를 짜는 것이 개발자가 해야 할 가장 기본이자 핵심 업무이고, 코드가 우리 작업의 결과물이라는 것을 부정할 사람은 없을 겁니다. 그러나 도메인 이해와 문제 정의 없이 코드만 짠다는 것은 우리 스스로를 저평가하는 것이라고 생각합니다.

학창 시절에는 '주어진 문제'의 '정답'만을 찾는 것이 '잘' 하는 것이었지만, 실무에서는 정답이 하나만 있는 경우보다는 선택지가 다양하게 존재하는 경우가 훨씬 많습니다. 그 다양한 선택지 중에서 골라낸, 현재 납득할 수 있는 가장 최선의 선택지를 저는 '해법'이라고 부릅니다. 즉, 하나의 문제를 해결하는 방법에는 여러 해법이 있을 수 있습니다. 이와 같이 해법을 찾기 전에 우리가 해야 할 일은 '문제 정의'입니다. 때때로 문제를 도출해서 정의한다는 것이 매우 어렵게 느껴지기도 하는데요. 그동안 대부분 주어진 문제를 풀었을 뿐, 스스로 문제를 만들어 보는 것을 학습할 기회가 많지 않았기 때문입니다. 그리고 문제를 정의하기 전에 '도메인 이해'가 선행돼야 합니다. 도메인에 대한 이해를 바탕에 두지 않으면 문제 정의가 잘못될 확률이 높기 때문입니다. '도메인을 이해하고, 문제를 정의한 후, 해법을 개발하는 일을 즐긴다'는 말은 이와 같은 과정과 경험에 바탕을 두고 있습니다.

잘못된 개발은 해법이 잘못됐거나 그전에 문제 정의가 잘못됐거나 혹은 그전에 도메인 이해가 잘못됐기 때문일 수 있습니다. 따라서 이 사이클을 자주 반복하면서 여러 피드백과 요구 사항을 반영하는 과정을 거쳐야 개발 완성도가 높아진다고 생각합니다. 이런 사이클은 특히 기술 부채를 해소할 때 그 호흡이 길어지고 더 많이 반복되는 경우가 있는데요. 기술 부채는 오랜 시간 쌓여온 자산이면서 동시에 언젠가는 청산해야 할 빚이기 때문에 단시간에 해결하기가 여간 어려운 일이 아닙니다. 기꺼이 협력해 주는 동료가 필요하며, 일을 진행하면서 복잡하게 얽힌 이해관계를 고려하는 것도 넘어야 할 산 중 하나입니다. 관성적으로 행해오던 방식에 제동을 걸고 나아가야 할 방향을 새롭게 제안하는 것은 어쩌면 코드를 짜는 것보다 더 어려운 경우가 많습니다. 저는 이번 글을 통해 제가 합류하게 된 프로젝트의 기술 부채를 어떻게 갚아 나갔는지 말씀드리려고 합니다.

Demaecan 합류

LINE은 일본에서 많은 사랑을 받고 있는 Demaecan(데마에칸, 出前館)의 지분 약 60%를 확보하며 인수했습니다. 현재 일본에서는 Demaecan과 Uber Eats가 업계 1위를 두고 치열하게 경쟁하고 있는데요. 이런 상황에서 2021년 초에 제가 속해 있는 ABC Studio 팀이 Demaecan 프로젝트에 합류하게 되었습니다. 당시 저는 처음으로 외국인과 협업해 볼 수 있는 흔치 않은 기회를 잡게 되어 고무됐습니다(LINE+에서는 흔한 일이지만 저는 당시 입사한 지 얼마 안 된 상황이었기 때문에...) 그런데 그런 제 기대와는 달리 Demaecan 프로젝트의 초기 랜딩 과정은 매우 힘들었습니다.

어떤 팀이나 프로젝트에 합류한 초기 시점에서 가장 중요한 것은 얼마나 '소프트'하게 랜딩할 수 있느냐라고 생각합니다. 그래서 좋은 팀이나 프로젝트의 멤버들은 합류한 멤버가 첫 단추를 잘 꿸 수 있도록 이런저런 도움을 주기 마련입니다. 그간의 히스토리와 함께 왜 이런 결정을 했는지 공유하고 어떤 문제가 부각되고 있는지, 현재 방치되고 있는 문제가 우선순위에서 밀린 배경은 무엇인지, 팀이나 프로젝트의 방향과 의사 결정 구조는 어떠한지, 그리고 개발자에게는 너무나도 기본적이고 필수적인 시스템 구조와 프로젝트 코드에 대한 리뷰를 해 주는 등 다각도로 도움을 줍니다. 그러나 제가 처음 마주한 프로젝트의 모습에서는 이런 것들을 기대하기 어려웠습니다. 또한 그리 친절하다고 느끼지도 못했습니다. 몇 가지 측면에서 살펴보겠습니다.

초기에는 한국과 일본의 멤버가 서로 생각을 맞추기 위해 많은 회의를 진행했습니다. 그런데 실무 개발을 구체화해야 하는 제 입장에서는 시간이 많이 흘렀음에도 여전히 회의에서 R&R이나 이해관계 정리와 같은 상위 레이어에 집중된 논의가 많아서 다소 뜬구름 잡는 기분이었습니다. 또한 관련 문서가 사내 위키 시스템에 18만건 가량 누적돼 있었는데요. 일본어를 전혀 모르는 저는 자동 번역에 의존해야 했고, 이를 떠나서도 누적된 문서의 양이 너무 많아서 핵심 내용을 찾는 게 여간 어려운 일이 아니었습니다.

코드 레벨에서는 아직도 JDK 1.6을 사용하는 프로젝트를 발견할 수 있었고, 메서드 라인이 수 백 줄이 넘는 경우도 볼 수 있었으며, 'type'을 'typ'라고 네이밍하는 것과 같이 일본식 영어 발음을 코드 네이밍으로 사용하는 경우도 많았습니다. 또 특이한 점으로 주석에 @author를 쓰고 있었는데요. 나중에 알게 된 사실이지만 개발의 상당 부분을 외주에 맡기고 있던 터라 외주사 개발자의 코드 이력을 주석으로 남기는 관행이 유지되고 있던 것이었습니다. 프로젝트 이름이 아리송한 경우도 있었습니다. 예를 들어 'ord-server'라는 프로젝트가 있는데요. 'order-server'라는 의미입니다. 'ord가 order입니다'라고 설명해야 한다는 점도 문제지만, 그 프로젝트의 상위 패키지명은 'faxreplace'입니다. 일본에서는 여전히 팩스(fax) 이용률이 높다고 하는데요. 예전 프로젝트를 마이그레이션하면서 팩스 서버를 대체한다는 의미로 'faxreplace'라고 했다고 합니다. 결과적으로 레거시를 새로운 프로젝트에서도 레거시로 유지해 버리는 인상을 주게 됐습니다. 물론 상황을 고려해 이해할 수 있는 부분도 있겠지만, 그럼에도 합류 초기에 느꼈던 당황스러움은 잊을 수가 없습니다. 이 외에도 여러 가지 면에서 언어와 문화적 차이를 가진 일본 멤버들과의 협업이 녹록지 않았습니다.

프로젝트에 합류하고 랜딩하는 과정에서 어려웠던 점을 몇 가지 말씀드렸는데요. 팀과 프로젝트에 기여한다는 것은, 제게 있어 업(業)의 본질 중 하나입니다. 자존감과 연결되는 부분이기도 하고요. 자존감을 높일 수 있는 돌파구를 찾지 못한다면, 제가 이곳에 있어야 할 의미가 없다는 말과도 같았습니다. 그렇기 때문에 엉킨 실타래를 풀기 위한 실마리를 찾는 것이 당시의 저에게는 매우 중요했습니다.

Postmortem: 레거시 시스템 회고

저는 개발자가 장애 발생 후 회고를 하듯이 Demaecan 시스템의 문제점을 해부(postmortem)해 보기로 했습니다. 시스템이 안정화된 상황이라면 코드 레벨에서 리팩토링을 생각했을 텐데요. 시스템 안정성을 해치는 요인들이 눈에 띄었기 때문에 먼저 이것부터 정리하기 시작했습니다. 그 결과 아래와 같이 크게 세 가지로 추릴 수 있었습니다.

DB 이슈
인증/보안 이슈
폴링(polling) 이슈

첫 번째로 DB 이슈는, CPU 사용량이 100%에 이르면서 장애의 직접적인 원인으로 리포팅되고 있었습니다. 두 번째로 인증/보안 이슈는, 기존 Demaecan의 서버 코드를 보다가 '어? 왜 있어야 할 게 없지?' 싶어서 확인해 보니 오랫동안 방치된 보안 이슈가 있다는 것을 발견했습니다. 또한 토큰의 시크릿 키 관리라든지, 인증 처리 방식을 개선해야 할 필요성도 보였습니다. 세 번째로 폴링 이슈는, 클라이언트인 가게와 드라이버 앱에서 서버의 데이터를 확인하기 위해 API를 호출하고 있었는데요. 그 트래픽이 빈번히 대량으로 발생하다 보니 본의 아니게 셀프 DDoS 공격이 되는 상황이었습니다. 일반적으로 시스템에서 클라이언트와 서버 간의 폴링 처리는 자연스러운 선택이라고 볼 수 있습니다만, 서비스 볼륨이 커지면서 시스템 부하가 발생할 수 있는 일종의 기술 부채가 되었다고 생각했습니다. 앞서 DB를 다운시키는 원인 중의 하나라고도 볼 수 있습니다. 이때 DB 부하의 경우는 캐시를 도입하거나 DB 트래픽을 분산하는 등의 방법으로 어느 정도 해결할 수는 있지만, 그것마저 잘 되어 있지 않은 상황이었습니다.

당시에는 최선의 선택이었다고 생각했던 것일지라도, 시간이 지나고 상황이 변하면서 레거시가 되고, 이윽고 장애로 연결되면서 기술 부채 청산 시점에 다다랐다고 시스템이 말해주는 때가 옵니다. 그러니까 당시 상황은 시스템이 '기술 부채 갚아달라!'고, '개선해 달라!'고 울부짖으며 장애를 일으키는 상황이었습니다. 물론 지금 여기서 레거시를 비판하려는 것은 아닙니다. 애당초 제가 평가할 대상이 아니라고 봅니다. 앞으로 어떻게 할지가 중요한 것이고, 이게 바로 새로 합류한 멤버들이 가져야 할 자세라고 봅니다. 힘차게 달리는 기차의 바퀴를 갈아 끼울 용기와 포용력이 있느냐, 그리고 그걸 실행할 역량이 있느냐가 중요한 포인트라고 생각합니다.

킥오프 제안, 이렇게 해보면 어떨까요?

앞서 말씀드린 레거시 시스템 회고 내용을 골자로 하되 전반적인 도메인 분리와 리팩토링을 위해 서로 맞춰야 할 공감대를 정리해서 제안했습니다.

당시 저는 Demaecan에 레거시가 많으며 기술 부채를 갚아야 할 시점이기 때문에 여러 포인트에서 개선을 진행해야 한다고 판단했습니다. 시스템 도메인을 의미 있는 단위로 나누고 도메인 간에 유기적으로 통신할 수 있는 스펙을 정리하는 것이 필요했고, DB 스키마도 다시 설계하고 운영 구조도 재정의해야 한다고 생각했습니다. 도메인 간 서로 격리된 DB 구조는 물론 샤딩까지 고려해야 한다고 생각했습니다. 보안 이슈와 관련된 결함을 개선하고 더불어 인증 시스템 자체를 분리하는 것도 필요했으며, 그 밖에 전반적으로 시스템의 기본 골격을 재정비할 필요도 있었습니다. 물론 노후화된 라이브러리도 버전업해야 했고요.

이를 위해 킥오프 제안서 외에도, 완전히 다듬지 못한 러프한 버전이긴 합니다만 전체 설계를 보다 넓은 관점에서 이해할 수 있도록 상위 개념의 시스템 디자인도 그렸습니다.

이런 것들은 모두 기술 부채를 갚기 위한 논의 시작의 근거를 마련하기 위함이었습니다. 그러나, 놀라울 만큼 관심을 받지 못했습니다. ABC Studio 내부에서는 이 과정을 치열하게 논의하면서 생각을 검토해 나갔습니다만, 일본 멤버와의 협의가 녹록지 않았고 그렇게 지지부진하게 진행되다가 묻혀 버렸습니다. 결국 당시에 실무 입장에서 진행이 이뤄진 것은 아무것도 없었습니다.

개발자이기 때문에 시스템의 안정성을 해하는 요인을 걷어내지 못한 상황은 감정적으로도 꽤나 치명적이었습니다. 문제의 원인을 파헤치고 해결하려는 과정이 미지근하다면 겉으로 드러난 문제보다 더 큰 문제가 내포돼 있을 가능성이 높습니다. 개발자들이 레거시를 싫어하지만 사실 레거시 자체가 문제는 아닙니다. 레거시는 문자 그대로 유산입니다. 당시 상황에서는 최선의 선택이 모인 결과물이고, 서비스가 발전할 수 있었던 건 원천 기술인 바로 그 레거시가 있었기 때문입니다. 다만 다시는 건들고 싶지 않다거나, 용기 내서 한 번 건드렸다가 대형 장애와 같은 많은 태클이 들어오는 바람에 아무도 건들지 못하는 영역으로 전락한다면 문제가 될 수 있습니다. 따라서 이를 고쳐 나가려는 특정 실무자를 비난해서는 결코 안됩니다. 장애는 어디까지나 조직의 문제이고, 문화의 문제이고, 시스템의 문제로 바라봐야 옳습니다. 개인을 비난하는 순간, 더는 새로운 아이디어로 도전적인 용기를 낼 사람이 나타나지 않을 것입니다. 그렇게 되면 좋은 인재는 떠나가고, 천덕꾸러기 레거시는 서비스가 종료하는 순간까지 영생을 누릴 겁니다. 바로 이 점이 제 감정을 자극했던 부분이었습니다. 나무만 보지 말고 숲을 볼 수 있어야 한다는 말은, 우리가 평소 일할 때에도 꽤나 쉽게 마주할 수 있는 상황을 위한 격언입니다.

두 번째 postmortem: 제안 실패 회고

장애가 발생하면 회고를 한다고 말했지만, 회고는 비단 장애 상황에만 하는 것은 아닙니다. 킥오프 제안이 왜 관심을 받지 못했는지와 관련해 실패 포인트를 회고할 필요가 생긴 것입니다. 스스로 반성한 부분이 많은데요. 먼저 필요하다고 보는 관점을 더욱 적극적으로 주장하지 못했던 미온적 태도를 반성해야 한다고 생각했습니다. 변명하자면, 앞으로 도전적인 프로젝트를 함께 할 일본 멤버들과 좋은 관계를 유지하는 것도 중요했으니까요. 또한 저는 단계적인 개선을 목표로 하고 있었기에 우선순위를 정하고 차근차근 밟아 나가려는 계획이었는데요. 내용이 빅뱅하자는 뉘앙스로 전달되는 바람에 공감을 얻기가 쉽지 않았다고 생각합니다.

'굴러온 돌이 박힌 돌을 뺀다'는 말처럼, 혹여라도 일본 멤버들이 제가 속한 ABC Studio를 '굴러온 돌'로 여기지는 않을지 염려됐습니다. 제가 간혹 어떤 문제 하나에 꽂히면 급발진하는 경향이 있기는 하지만, 그건 매우 드문 경우이고, 이번에는 매우 조심스럽게 다가가려고 노력했습니다. 무엇보다 10년이 넘는 시간 동안 Demaecan을 만들어 오고 성장시켜 온 일본 멤버들은 충분히 존중받아야 한다고 생각했습니다. 그렇기 때문에 어찌 보면 ABC Studio가 생각하는 더 나은 방향으로 가기 위해서는 레거시를 이해하고 있는 그들의 절대적인 지지가 필요했습니다.

조금 시간이 흐른 뒤에 들은 얘기입니다만, 리더가 이런 말을 했습니다.

'우리는 한 나라의 민생을 책임지는 서비스를 만듭니다.'

조금 거창하다고 느끼시나요? 저는 '최선을 다하자'라거나 '잘 하자'와 같은 백 마디 천 마디 말(잔소리)보다 이 한 마디의 울림이 컸습니다. 우리가 하는 일에 자존감을 가질 수 있는 부분이라고 느꼈기 때문입니다. 음식 배달 플랫폼은 음식점 사장님이나 드라이버 분들과 같이 한 가정의 생계를 책임지는 분들이 이용하는 서비스입니다. 많은 사람들이 음식을 주문하는 사용자 입장에서 서비스를 바라보기 쉽습니다. 저 또한 마찬가지였는데요. 리더의 이 말을 통해서 내가 참여하고 있는 이 프로젝트가 얼마나 가치 있고 중요한 일인가를 다시금 깨달을 수 있었습니다.

그렇기 때문에 이 서비스의 사용자를 위해서 제가 해야만 하는 일은, 시스템 관점에서 안정성을 확보하고 문제 해결에 집중하는 것이라고 생각했습니다. 이는 이해관계를 고려하고 R&R을 나누는 것보다 더 높은 우선순위를 가져야 한다고 생각했습니다. 애초에 이해관계 충돌이나 R&R 이슈는 제가 제어할 수 없는 영역이기도 했고, 그래서 되려 교통정리 좀 해달라고 많이 불평했었는데요. 이 시점 이후부터는 오롯이 엔지니어로서 내가 가장 잘 할 수 있는 일에 집중하자고 마음먹었습니다.

내 할 일은 내가 정하자

저는 시스템 안정성을 최우선으로 잡고, 어떤 일이든 도전적이고 흥미롭다면 그게 내가 할 일이라고 생각했습니다. 그래서 postmortem을 통해 도출했던 세 가지 이슈를 다시 검토했습니다.

결정하기 위한 기준을 아래와 같이 크게 6가지로 정리했습니다.

1) 핵심 업무 2) 긴급도 3) 난이도 4) 사이드 이펙트 5) 협업 6) 업무 의존성

위 기준과 더불어 업무가 얼마나 독립적인지와 개인적인 흥미도도 영향을 미쳤습니다. 이런 기준을 고려한 결과 제가 할 일은 메시징 시스템을 만드는 것으로 결정했습니다.

메시징 시스템의 목표는 명확합니다. 기존 폴링 이슈를 푸시로 해결한다는 것입니다. 이게 답니다. 이것만 잘 해내면 이 시스템의 역할은 다 한 것이라고 봐도 무방합니다. 이 시스템의 이름은 메시징 허브(messaging-hub)입니다.

아, 그리고 물론 이런 일은 저 혼자 하고 싶다고 할 수 있는 게 아닙니다. 팀 내 리소스를 고려한 팀원들의 공감과 리더의 의사 결정이 필요했습니다. 이 자리를 빌려 해야 하는 일이자 하고 싶은 일을 할 수 있게 해준 동료들과 리더에게 감사드립니다.

마치며: 2편으로 이어집니다

지금까지 Demaecan 프로젝트에 합류한 후 시스템 안정성을 해하는 기술 부채 청산을 목표로 메시징 허브를 선정하게 된 일련의 과정을 말씀드렸는데요. 다음 글(메시징 시스템(a.k.a messaging-hub) 톺아보기)에서는 구체적으로 메시징 허브를 톺아보도록 하겠습니다.

채용

ABC Studio는 일본 음식 배달 서비스 No.1을 시작으로 퀵커머스 글로벌 No.1 플랫폼까지 지향하는 프로덕트 조직입니다. 기획과 디자인, 클라이언트(iOS, Android), 프런트엔드, 서버가 하나의 팀으로 움직입니다.

혹시 시간이 지나 채용 링크로 연결되지 않는다면, LINE+ 채용 공고 페이지에서 ‘ABC Studio’를 검색해 보세요!

Server-side

Blog