[오다비] LMS 10배 성능 개선과 시스템 이전 (1/2)
오다비는 대치동 학원가 선생님을 위한 LMS(학습 관리 시스템)입니다. 선생님의 클래스(수업)와 문제지, 학생을 등록해 편하게 관리할 수 있습니다. 예시로 문제지를 엮어 시험을 만들 수 있고, 각 시험 별 학생들의 성적이나 문항별 정답률을 계산하는 기능을 제공합니다. 선생님들의 많은 호응을 받아 일주일에 10건 이상의 인바운드 문의가 들어오고 있습니다.
고객사는 오다비를 처음 타 SI 업체에서 구축하셨습니다. 그 후로 기능 추가나 개선이 필요할 때마다 외주 및 1인 직원을 활용하셨다 합니다. 꾸준히 고객이 늘어 사업이 성장하던 중, 서비스 성능 저하 문제로 다빈치를 찾아주셨습니다. 고객이 늘수록 서비스 속도가 현저히 느려져, 인바운드 문의가 들어와도 신규 고객을 받지 못하는 상황이었습니다. 당시 오다비 시스템을 재현한 접속 화면입니다.
첫 대쉬보드 로딩부터 10초에 달하는 긴 시간이 걸립니다. 다빈치에서 이 화면의 로딩 시간을 아래와 같이 1초대로 단축하는 데 얼마나 걸렸을까요?
다빈치는 개발 문서도 남아있지 않은 서비스 성능을 단 1주일 만에 10배 이상 개선했습니다. 고객사는 바로 인바운드 영업을 재개해 신규 고객을 받으실 수 있었습니다. 어떻게 가능했을까요? 다빈치 컨설팅은 무엇이 다를까요?
사업가의 시각에서 프로젝트를 계획합니다.
기존 오다비는 AWS Ampilify, AWS AppSync 를 사용했습니다. AWS에서 제공하는 최신 관리형 서비스입니다. 서비스 페이지를 보면 공통으로 “서버리스”, “빠른 개발”, “빠른 배포”등의 키워드가 나옵니다. 해당 기술들은 규모가 작은 서비스를 빠르게 개발하고 실험하는 데 적합합니다. 오다비처럼 제공하는 기능이 복잡하고 다양한 서비스에서, 기술에 대한 이해 없이 사용하면 독이 될 수 있습니다.
예시를 보겠습니다. 선생님이 등록한 문제지 목록을 등록 날짜순으로 조회하는 간단한 페이지입니다. 정상적으로 개발된 서비스라면 아래와 같이 한 번의 API 요청으로 목록을 불러올 수 있습니다.
그런데 오다비에서는 20건이 넘는 요청이 발생하고 있었습니다.
개발을 잘 모르는 분이 보시기에도, 문제지 10개를 조회하는데 29건의 네트워크 요청이 발생하는 상황은 이상하지 않나요? 동일한 문제가 서비스 전체에 있었습니다. 성능 문제를 근본적으로 해소하려면 긴 시간이 걸릴 것으로 보였습니다.
다빈치가 산정한 전체 프로젝트 기간은 6주입니다. 크게 두 단계로 나눠 진행했습니다.
DB 쿼리 최적화로 성능 개선 (1~2주)
당시 오다비는 성능 저하로 인바운드 영업을 잠시 중단하셨습니다. 전체 기간인 6주 동안 중단한 채로 신규 고객을 받지 못하면 큰 사업 손실입니다. 다음 단계에서 중복 개발을 조금 하더라도, 성능 개선을 먼저 해 고객사의 불편을 빠르게 해소하는 걸 목표했습니다.
사용 기술 변경, 코드 품질 개선 및 데이터 마이그레이션 (4~5주)
앞서 말한 AWS Ampilify, AWS AppSync 는 최신 서비스라, 해당 기술을 능숙하게 사용해 좋은 품질로 작업할 개발자를 구하기 어렵습니다. 고객사는 오다비에 새로운 기능을 계속 추가하며 사업을 확장할 계획이었습니다. 추후 개발 인력을 구하기 쉽도록 기술을 변경하며, 코드 품질도 함께 개선하기로 했습니다. 기술에 대한 이해 없이 개발한 낮은 품질의 코드 때문에, 개발이 갈수록 어려워지는 문제도 있었기 때문입니다.
1주일로 서비스 성능을 10배 개선했습니다.
오다비는 DB 데이터가 가장 많은 테이블의 데이터 수가 몇만 건으로, 성능 문제가 발생할 단계가 아니었습니다. 그런데도 저하가 일어났던 원인은 무엇이었을까요? 프로젝트 개발 문서가 남아있지 않고 코드 품질도 낮은 상황이라 파악이 쉽지 않았습니다. 그래도 다빈치의 뛰어난 개발자들은 단 며칠간 빠르게 파악해 개선해 냈습니다.
위의 문제지 조회를 예시로 보겠습니다. 오다비에서는 선생님이 등록한 문제지를 조회하기 위해 우선 DB에서 모든 문제지를 10개씩 나눠 조회했습니다. 전체 문제지가 500개 있다면, DB에 문제지 10개 조회를 50번 반복합니다. 여기서 불필요한 지연이 생깁니다.
그리고 AppSync 에서 조회한 500개의 문제지 중 A 선생님의 문제지를 필터링합니다. 불필요한 지연이 추가로 생깁니다.
고객인 선생님의 수와 등록한 문제지 수가 증가하면 어떻게 될까요? 각 단계에서 지연이 증가하니 예상 응답 속도는 그림과 같이 선형적으로 점점 더 느려집니다.
다빈치는 우선 AppSync에서 DB로 보내는 쿼리를 모두 최적화했습니다. DB에서 데이터를 조회할 때 A 선생님의 문제지만 조회하도록 개선했습니다.
개선 후 반복 조회가 사라지고, AppSync의 필터링 작업도 사라졌습니다.
또한 쿼리 별로 적절한 DB 인덱스도 설정했습니다. DB 인덱스는 쉽게 말해 데이터를 필요한 순서로 미리 정렬하는 기능입니다. 여러 선생님이 각자 문제지 데이터를 입력하면 DB에는 입력한 순서대로 문제지가 섞여 있습니다. 이를 미리 선생님 별로 정렬하도록 설정하면, 조회 시 DB에서 각 선생님 구간의 데이터만 읽기에 훨씬 빨라집니다. 데이터가 많아질수록 시간 감소 효과는 더 분명해집니다.
서비스의 모든 쿼리를 찾아 위의 최적화를 적용했습니다. 1차 개선으로 실제 로딩 속도가 얼마나 빨라졌을까요?
기능 별로 최소 3배부터 최대 10배까지, 짧은 기간에 크게 개선했습니다. 단순히 속도가 빨라진 것보다 중요한 개선 사안도 있습니다. 이제 고객이 10배, 20배 늘어나도 더 이상 속도 저하가 일어나지 않습니다.
고객사의 미래 계획까지 고려해 개발합니다.
성능 개선과 동시에 다른 작업도 진행했습니다. 기존 개발 환경은 테스트와 운영(실제 서비스)환경, 두 개가 있었습니다. 테스트 환경은 운영에 비해 적은 양의 가짜 데이터만 들어있어서, 운영 환경에서 보이는 성능 저하가 생기지 않았습니다.
그래서 다빈치에서는 운영 환경과 동일한 데이터를 사용하는 별도 환경인 ‘핫픽스’ 환경을 구축해 드렸습니다.
추후 다른 개발사에 외주를 맡기시거나, 내부 개발자가 개발할 때 다시 성능 문제가 발생한다면, 별도로 재연할 필요 없이 핫픽스 환경에서 바로 대응할 수 있습니다. 또, 남은 프로젝트 기간 동안 개선 작업이 있을 때마다 고객사가 핫픽스 환경에서 바로바로 직접 사용해 보실 수 있었습니다.
다빈치는 주기적인 데모와 활발한 소통으로 완성도 높은 결과물을 보여드립니다.
다빈치는 프로젝트 전체 마일스톤을 세워 고객사에 공유하고 데모로 실현합니다. 실제로 오다비 프로젝트 시작 1주일 후 성능 개선 데모를 보여드렸습니다. 그리고 바로 다음 날 운영 환경에 적용해 성능 문제를 해결했습니다.
오다비는 핫픽스 환경을 구축해 드렸기 때문에, 데모가 아니어도 언제든 접속해 진행 상황을 보실 수 있었습니다. 다빈치는 어떤 일을 했는지 글이나 PPT 슬라이드로 설명하기보다, “사용해 볼 수 있는 제품”을 보여드리는 게 가장 투명하고 좋은 방법이라 생각해 실천합니다.
그런데, 위 마일스톤 달력에 공휴일 표기가 없는 걸 눈치채셨나요? 지난 5월 15일은 ‘부처님오신날’이었는데요. 다빈치는 고객사의 문제를 곧 다빈치의 문제라 생각하기에, 휴일 밤낮 가리지 않고 소통에 열려 있습니다. 실제로 오다비에서 핫픽스 환경 사용 중, 해당일에 오류를 발견해 연락을 주셨습니다. 다빈치는 즉시 확인 후 조치해 드렸습니다. 당시 주고받은 메일입니다.
이렇게 주기적인 데모와 언제든 열린 소통이 있으니 자연스럽게 결과물의 완성도가 높습니다. 고객사의 만족도 역시 늘 높습니다.
사업 상황에 따라 같은 문제라도 최선의 해결법이 다릅니다. 만약 사업을 확장할 계획이 없으셨거나, 신규 고객이 더 들어오지 않는 상황이라면 다른 방식을 제안했을 것입니다. 하지만 오다비의 당시 상황에 맞춘 판단으로 최초 1주일을 성능 개선에 집중했습니다. 고객사는 크게 만족하셨습니다.
이제 걱정 없이 신규 고객을 10배, 20배까지 받으실 수 있으니, 다빈치도 안심하고 남은 기간 시스템 이전 및 품질 개선 작업에 집중할 수 있었습니다. 이어지는 글에서는 오다비에 왜 품질 개선이 필요하다는 진단을 내렸는지, 다빈치는 어떤 방식으로 필요성을 증명했는지 다루도록 하겠습니다. 감사합니다.