레거시가 만든 성장,
레거시가 만들 성장
모요의 기술 팀은 항상 당시의 비즈니스 상황, 팀의 여건, 기술적 제약 속에서 우리가 생각할 수 있는 최선을 선택했고, 그 결정들이 하나둘 모여 지금의 서비스를 만들어냈죠. 그 위에서 아주 빠르게 속도를 내며 새로운 기능을 만들고 제품을 고도화 해나갔어요.
그렇게 쌓인 것들이 시간이 흐르며 ‘레거시’라 불리게 되었어요.
’레거시’는 분명 우리를 성장시키고 앞으로 밀어주던 것들이었어요. 그러나 점차 발목을 잡기 시작하고 더욱더 느려지게 하는 것이 되었죠. 그때의 최선을, 지금의 최선으로 이어가기 위해서 어떤 노력을 하고 있는지 이야기하려고 해요.
레거시를 이해하는 첫걸음, ‘지금 시스템을 얼마나 알고 있는가?’
모요 초창기엔 빠르게 기능을 만들어내는 게 최우선 과제였어요.
그 덕분에 많은 걸 빠르게 시도하고 만들 수 있었지만, 시간이 지나면서 시스템은 점점 복잡해졌고 그에 따라 다양한 문제가 발생하기 시작했어요. 그런데 문제는 단순히 문제가 있다는 것이 아니라, 우리가 그 문제를 얼마나 잘 파악하고 있는가에 있었어요.
레거시가 점차 눈덩이처럼 불어나고 있지만, 명확하게 무엇이 문제인지 파악을 하지 못하고 있는 것은 우리가 지금의 시스템 상태를 제대로 이해하고 있지 못하다는 것이었죠.
오류가 나도 원인을 찾기 어렵고, 팀마다 각자 다른 정책과 방식으로 운영되고 있다 보니 같은 문제를 반복해서 마주하게 됐어요. 그래서 우리가 가진 시스템을 ‘제대로 보는 것’부터 시작하기로 했어요.
장애 원인조차 보이지 않던 시절에서, ‘보이는 시스템’으로
그 중 첫 번째는 잘 활용하지 못하고 있던 DataDog과 Sentry를 제대로 연동하는 작업이었어요.
이를 바탕으로 서비스의 부하와 장애, 에러들의 정량적 지표들을 바탕으로 얼마나 많은 문제들이 있는지 확인할 수 있었어요. 우리가 제대로 보고자 하는 것들을 볼 수 있는 최소한의 환경은 구축했지만 에러 로그는 하루에 천 건이 넘게 쏟아졌고, 그 안에서 중요한 이슈를 식별하는 것조차 힘들었어요.
그래서 저희는 모니터링 시스템을 구축하고, 의미 없는 에러의 ‘소음’을 줄이는 작업에 집중했어요.
중복되거나 무시해도 되는 에러들과 서비스에 부하를 일으키고 있는 원인들을 하나씩 정리하면서, 지금은 하루 평균 에러가 100~200건대로 줄었어요. 이제는 정말 중요한 신호에 집중할 수 있는, 모니터링 가능한 최소한의 환경이 만들어졌어요.
(왼쪽) 기존 오류 수 / (오른쪽) 개선 후의 오류 수
그러나 여전히 지속적으로 발생하는 에러들이 있고, 문제 상황을 빠르게 탐지하는 것을 넘어 그 원인을 더 빠르게 파악하고 개선할 수 있도록 개선하는데 시간을 투자하고 있어요.
복잡해진 개통 서비스, 처음부터 다시 설계하고 있어요
앞서 이야기한 ‘보이는 시스템’으로 나아가는 것과 함께 현재 운영하는 서비스를 더 잘 운영할 수 있도록 개선하는 것에도 많은 힘을 쏟고 있어요. 그중 하나가 유저의 정보를 바탕으로 직접 개통까지 해주는 가장 핵심적이고 중요한 서비스인 ‘개통’을 처음부터 다시 설계하고 만드는 것이에요.
저희는 유저에게 가장 좋은 경험을 주겠다는 열정으로 유저가 불필요한 과정을 거치지 않도록 상황에 따라 다양한 플로우 정책들을 적용해 왔고, MNO(SKT/KT/LG), MVNO(알뜰폰 통신사)와의 개통 연동과 함께 다양한 제휴사의 요구사항도 함께 최대한 반영을 해왔었죠.
그러다 보니 운영 정책을 많이 고려하지 않고 상황에 따라 하드코딩을 해가며 최대한 빠르게 다양한 요청에 대응했어요. 그 결과 ‘개통’은 다양한 비즈니스의 요구와 정책들이 점점 얽히고 복잡해지며 점점 확장하기 어려운 구조가 되었고, 단순한 수정조차 부담이 되는 상황이 되었어요.
그러나 개통이라는 서비스는 지금도, 앞으로도 저희에게 너무나도 중요한 서비스라는 걸 너무나 잘 알기 때문에 앞으로도 잘 운영해 나가기 위해서 핵심 개념을 정리하고, 책임과 역할을 분리하면서 구조적으로도 더 나은 방향으로 새롭게 구축해 가고 있어요.
개통 정책 정리 문서
이를 통해 단순히 신청의 정보를 입력받는 플로우, 그 과정에서 다양하고 복잡한 정책들, 통신사들과 연동되는 개통이 명확하게 분리되어 훨씬 더 관리하기 용이한 구조로 나아가려고 해요.
이건 단순히 과거의 방식이나 개발이 잘못되었다는 뜻이 아니에요. 그 시점의 선택이 있었기에 지금의 서비스가 가능했으니까요. 지금은 그 위에, 다음 단계를 위한 설계를 더하고 있는 중이에요.
물론 새롭게 설계하고 구축는 과정은 쉽지 않아요. 하지만 이러한 시간을 투자해서 충분히 고도화된 서비스로 거듭날 수 있다면, 유저에게 더 나은 경험과 다양한 요구사항도 녹여낼 수 있을 거라고 기대하고 있어요.
빠른 개발과 반복되는 레거시, 이제는 다르게 해보려고 해요
모요는 지금도 빠르게 제품을 개발하고 있는 팀들이 많아요. 이 속도는 모요 팀의 큰 장점이지만, 그만큼 빠르게 만들어낸 구조들이 시간이 지나면서 눈덩이처럼 불어나는 경험도 자주 했어요. 초기 대응으로 만든 코드가 시간이 지나며 시스템 전반에 영향을 주고, 그때 하지 못한 정리가 결국 더 큰 기술적 비용으로 돌아오는 걸 경험했어요.
그래서 요즘엔 빠르게 만들되, 반복되지 않도록 만드는 방법을 더 많이 고민해요. 어떤 구조로 만들어야 나중에도 유지보수가 가능한지, 정책은 어떻게 분리하는 게 좋을지, 과거의 경험이 다시 반복되지 않도록 만드는 것이 지금의 과제이자 기회라고 생각하고 있어요.
여러 스쿼드와 Platform 조직이 함께 앞으로 나아가기 위해 다양한 고민을 바탕으로 실행해가고 있어요. 아마 ‘레거시’는 완전 없어지지는 않을 거예요. 그리고 꼭 없애야만 한다고 생각하지도 않아요. 지금의 규모에 멈춰있지 않고, 더 크게 성장하기 위해서 우리는 그걸 이해하고, 다루고, 넘겨줄 줄 아는 팀이 되기 위해 계속 노력하고 있어요.
그때의 선택이 만들어준 지금, 지금의 선택이 만들어갈 다음. 레거시가 만든 성장 위에서, 또 다른 성장을 준비하고 있어요.
* 프론트엔드 챕터에 대해 더 궁금하다면, 자주 묻는 질문 : 프론트엔드 개발자 편을 확인해 주세요.