처음 보는 서비스를 개선하라는 업무가 나에게 주어졌을 때 무엇부터 해야할까요?
구체적인 내용은 별도 포스트로 다루고, 제가 실제로 진행 했던 순서대로 간단히 기록해보려고 합니다.
상황 파악
어느날 갑자기 빌링 정보를 처리하는 배치의 성능 개선을 맡게 되었습니다. 대략적으로 파악해보니, 기존의 Spring으로 구현되어 있던 것을 배치 작업에 적합한 Spring Batch로 마이그레이션하였으나 성능이 예상보다 떨어지는 상황임을 파악하였습니다.
기술부채 갚아나가기
구현된 기능들은 개발 당시에는 최선이었음이 분명한 기능들입니다. 과거에는 몰랐지만, 경험이 쌓이다 보니 기술부채가 있더라도 필요에 따라 빠르게 개발되어야만 하는 경우가 있다는 것을 알고 있습니다. 그 덕분인지 회사가 급격하게 성장하였고, 처리해야할 데이터도 많아졌으며 처리에 필요한 시간도 늘어났습니다.
성장을 위해서 도입했던 기술부채를 이제는 갚아야 할 시간입니다. 전혀 다른 새로운 것을 갑자기 도입해서 처리하기에는 시간이 너무 오래 걸리고, Side Effect가 생길 가능성도 큽니다. 기존 프레임워크 상에서 성능 개선을 통해 시간을 벎과 동시에 많은 데이터들을 처리하기에 알맞은 새 프레임워크로의 전환을 꾀해야 합니다. 우선 성능 개선을 통해서 시간을 벌어보기로 합니다.
업무 프로세스 분석
기존의 배치가 어떤 업무들이 어디서 어떤 역할을 하고 있는지 알아야 개선도 가능합니다. 현재 프로세스를 간단하게 흐름도로 그려봅니다.
흐름도를 보면 대충 감이 잡힐 법도 합니다. 잘 이해가 안가는 것은 따로 정리하고, 흐름도를 그렸을 때 작업이 중복되거나 이게 여기 꼭 필요한지 의문이 드는 것들을 정리합니다.
인터뷰
현재 업무를 잘 알고 있는 시니어 개발자분께 수시로 인터뷰를 잡고, 또는 계속 자리에 가서 물어봅니다. 이건 꼭 필요한건지? 왜 여기에서 하는건지? 궁금했던 점을 해결해 나가고 서로 묻고 답하다 보면 꼭 이곳에서 하지 않아도 되는 업무, 과거에는 필요했지만 현재는 필요없어진 업무와 같은 개선이 필요한 업무들이 보입니다.
다시 현재
현재 배치 개선을 통해 시간을 벌면서, 차세대 아키텍처를 구상중입니다. 데이터 증가 폭에 따른 처리 소요 시간은 특정 임계점이 지나면 폭발적으로 증가하므로 시간 벌기가 쉽지 않습니다. 운영과 개발을 병행하는 DevOps는 쉽지 않은 길인 것 같습니다.
다음 포스트에서는 업무 프로세스를 어떻게 정리했는지, 어떻게 시간을 벌었는지 구체적으로 다뤄보겠습니다.