[오다비] LMS 10배 성능 개선과 시스템 이전 (2/2)
앞선 글에서 다빈치가 오다비 LMS 개선 프로젝트를 크게 성능 개선과 품질 개선, 두 단계로 나눠 진행한 이유를 말씀드렸습니다. 또 일주일 만에 성능을 10배 넘게 개선한 방법도 알려드렸지요. 이번 글에서는 남은 한 달여의 기간 동안 품질 개선을 진행한 이유와 방법을 설명하겠습니다.
기술 변경과 품질 개선, 왜 필요했을까요?
인력을 구하기 어려운 기술 스택
고객사는 오다비 사업을 쭉 확장할 계획이었습니다. 새롭고 다양한 기능을 실험하고, 유저도 지금보다 몇 배, 몇십 배 늘리고자 합니다. 그러려면 인하우스나 외주의 형태로 개발자 인력이 필요한데요. 그런데 기존 기술을 사용할 수 있는 개발자가 적습니다. IT 외주 구인 사이트에서 각 기술을 사용 가능하다 표기한 작업자를 찾아봤습니다.
AWS AppSync, AWS Amplify는 비교적 최신 기술이라고 1편에서 말씀드렸습니다. 둘보다 훨씬 오래 쓰인 AWS EC2에 비해 작업자가 훨씬 적습니다. 인력 풀이 적으면 좋은 품질로 개발하는 뛰어난 개발자를 구하기가 정말 어렵습니다. 이미 이전에도 성능 개선을 위해 프리랜서 채용을 시도하셨지만 어려움을 겪고 무산된 적이 있으셨습니다.
데이터 특성과 맞지 않는 NoSQL DB
Amazon DynamoDB는 NoSQL(비관계형) 데이터베이스입니다. RDB(관계형) 데이터베이스에 비해 대용량의 비정형 데이터를 다루는 데 적합합니다. 동일한 학생과 시험 성적 자료가 있다면 아래와 같이 각기 다른 방식으로 자료를 저장합니다.
왼쪽이 간소화된 NoSQL형 데이터 저장 방식, 오른쪽은 RDB형 데이터 저장 방식입니다. 위 데이터에서 과학모의고사의 평균 점수를 구하고 싶다면 어느 쪽이 더 편리할까요? 왼쪽은 모든 학생의 데이터에서 과학모의고사가 있는지 확인하는 과정이 필요합니다. 학생B는 과학모의고사를 치지 않았으니 평균 계산 대상이 아니지만, 이 사실을 알기 위해 학생B의 시험 점수 데이터를 읽어야 합니다. 반면 오른쪽은 시험 점수 테이블에서 과학모의고사 점수만 바로 골라 계산할 수 있습니다.
오다비에서 중요하게 다루는 선생님과 수업, 학생, 시험 등 데이터의 특성과 서로의 관계를 고려했을 때, 관계형 데이터베이스를 이용하는 게 더 적합하다고 판단했습니다. 실제로 NoSQL을 사용하는 현재 구조에서 사업에 필요한 데이터를 잘 찾아보지 못하는 상황이었습니다.
유지보수 어려움
앞선 1편에서 가장 큰 성능 저하 원인은 DB에서 데이터를 쿼리하고 처리하는 과정의 시간 지연이었습니다. 기술이 달랐다면 이 문제도 미리 방지할 수 있었습니다. 백엔드 없이 프론트에서 실행되는 요청이 제대로 추적되지 않은 게 문제였으니까요. 백엔드 서버를 만들고 분리해 로그를 남기면, 비슷한 문제가 다시 생겨도 미리 발견해 고치기 쉽습니다. 예를 들어 DB 쿼리 응답이 늦을 때 적절한 알림이 오도록 설정할 수 있습니다.
기술 변경으로 기대한 결과
AppSync를 통해 프론트에서 작동하던 시스템을 모두 Spring백엔드 서버로 옮겨 AppSync를 완전히 제거했습니다. Amplify는 편리한 배포를 위해 일부 남겼지만, 역시 대부분의 코드를 백엔드 서버로 옮겼습니다. 연결 DB는 AWS Aurora DB로 변경하고, 기존 데이터를 마이그레이션 했습니다. 기대하는 결과는 다음과 같습니다.
개발자에게 익숙한 기술을 사용해 추후 인력 구인이 쉬워집니다.
백엔드 서버를 고품질 코드로 만들어 유지보수가 쉬워집니다.
인프라의 신뢰성이 좋아집니다.
품질 개선 후 어떤 변화가 있었을까요?
남은 프로젝트 기간 계획대로 AWS EC2로 Spring 백엔드 서버를 배포하고, DB를 변경했으며, 데이터 마이그레이션도 해냈습니다. 어떤 변화가 있었을까요?
더 짧은 시간, 적은 비용으로 개발이 가능해졌습니다.
사실 프로그램 품질 개선은 겉으로 보이는 제품 변화가 적기에 고객사 입장에서 선택하기 쉽지 않습니다. 다빈치는 앞으로 적은 비용으로 개발이 가능할 것이라고 말만 하지 않고, 행동으로 증명합니다. 개선 후 절실히 필요했으나 추가하기 어려웠던 기능을 바로 추가해 드림으로써 효과를 직접 보여드렸습니다.
기존에는 사용자의 니즈를 고려하지 않은 데이터 설계가 제품 생산성과 사용성을 해치고 있었습니다. 예시로 학생 별 시험 성적표 보기가 어려웠는데요. 폴더 구조로 비유하자면 왼쪽처럼 클래스 하위에 일자별 시험과 학생의 시험 성적이 들어가 있었습니다. 오른쪽 같은 모습이 사용자 관점에서 훨씬 유익하지 않을까요?
왼쪽 데이터 구조에서 김철수 학생의 모든 시험 성적을 보고 싶다면 어떻게 봐야 했을까요? 모든 클래스와 시험에서 김철수의 성적이 있는지 일일이 확인해야 했습니다. UI 상에서는 훨씬 복잡했는데요. 홈 > 클래스 목록 > 특정 일자 시험의 성적 관리 > 해당 학생 선택 > 성적 확인 > 날짜 변경 순이었습니다. 접근하는데 무려 5뎁스나 필요합니다.
더 큰 문제는 ‘특정 일자 시험의 성적 관리’를 눌렀을 때, 해당 학생이 없을 수도 있었습니다. 마치 폴더를 열기 전까지는 내용물을 알기 어려운 것처럼요. 그 학생이 없으면 뒤로 가 다른 시험에서 찾아야 했습니다. 로딩 속도가 느리기까지 했으니, 학생 한 명의 성적표를 확인하는 것만 해도 얼마나 번거로울지 느껴지시지요? 많은 기능이 이렇게 고려 없이 개발되어 사용하기 몹시 불편했습니다.
RDB로 데이터베이스를 변경하고 데이터 구조를 개선하면서 문제가 마법처럼 해결되었습니다. 관계형이라는 이름에서 알 수 있듯이, 연관된 데이터 간의 조회가 훨씬 쉬워졌기 때문입니다. 이제 학생의 모든 시험 성적을 클릭 두 번으로 조회할 수 있습니다. 홈 > 학생 목록 > 해당 학생 선택이면 됩니다.
학생 상세 정보 페이지를 추가해 수강한 클래스와, 클래스별 최신 성적을 바로 볼 수 있게 했습니다. 이전 워크플로를 보고 사용자 관점에서 위 방식이 더 편하다고 생각해 만들었는데요. 실제로 선생님들의 반응이 굉장히 좋았다고 들었습니다.
이 기능을 추가하는데 하루도 채 걸리지 않았습니다. 품질 개선 전 같은 기능을 추가하려면 훨씬 복잡하고 어려웠을 것입니다. 개선 후에는, 다루는 사업과 정보를 고려해 적합한 데이터 구조를 새로 설계했기에 훨씬 빠른 시간으로 개발할 수 있습니다. 고객사의 미래 시간과 자원을 몇 배로 절약시켜 드렸습니다.
사업에 필요한 데이터 분석이 쉬워졌습니다.
오다비는 선생님이 문제를 두 가지 방식으로 등록할 수 있습니다. 하나는 특허받은 자동 등록 기능이고, 하나는 직접 입력하는 수기 등록입니다.
개선 전 데이터 구조에서 자동 등록과 수기 등록 비율을 알기가 어려웠습니다. 그래서 고객사에 비율이 몇 대 몇일 것 같냐고 여쭤봤을 때, 2:8로 추측하셨습니다.
실제 비율은 5:5였습니다. 추정값과 실제값에 큰 차이가 있었습니다. 개선 후 데이터를 더 쉽게 보고 더 정확한 사업 계획을 세우실 수 있기에, 사업 임팩트가 매우 큰 작업이었습니다. 간단한 SQL만 알아두시면 개발자가 없더라도 충분히 좋은 인사이트를 얻으실 수 있습니다. 그래서 서비스로 주요 SQL도 같이 작성해 드렸습니다.
탄탄한 인프라 개선으로 문제 재발을 방지했습니다.
오다비는 처음 성능 저하 원인도 파악하기 어려워 다빈치에게 연락해 주셨습니다. Datadog 무료 플랜을 연동해 백엔드 서버 로그를 추적하게 했습니다. 성능이 느려지면, 로그로 어떤 기능에서 문제가 발생했는지 바로 알 수 있습니다. 무료 플랜이라 현재는 로그가 짧은 기간만 남는데요. 사업이 커져 더 긴 기간의 로그가 필요하시면 추가 개발 없이 플랜 업그레이드만 하면 사용하실 수 있도록 연동했습니다. 또한 DB도 Aurora로 변경하며 퍼포먼스 모니터링을 추가했습니다. 쿼리 응답 시간이 늦어질 때 바로 알림을 받을 수 있습니다.
다빈치는 누구보다 고객사의 문제를 치열하게 고민합니다.
다빈치가 오다비 프로젝트를 분석했을 때, 전체 기술을 변경하는 게 좋다는 진단을 내렸습니다. 하지만 고객사 입장에서 이런 결단을 내리기 쉽지 않습니다. 겉으로 드러나는 변화가 기능 개발에 비해 적기 때문입니다. 다빈치는 사업에 정말 필요한 게 무엇인지 고객사의 입장에서 그 어느 팀보다 깊이 고민한다는 자부심이 있습니다. 그래서 어려운 선택일지라도 고객사를 설득해 해냅니다. 실제로 오다비는 프로젝트를 진행하며 데모 때마다 이런 칭찬을 남겨주셨습니다.
생각 못하고 있었는데 먼저 챙겨주셔서 감사합니다.
골칫거리가 해결됐습니다.
왜 이제야 다빈치를 만났는지 지난 시간이 아쉽습니다
저희도 큰 보람을 느껴 정말 열심히, 행복하게 작업할 수 있었습니다.
믿고 맡겨 주신 만큼 성공적인 프로젝트 완수를 위해 휴일 밤낮 가리지 않고 문제가 있다면 해결했습니다. 고객사의 일이 곧 다빈치의 일이니까요.
다빈치는 고객사의 미래까지 고려하는 게 컨설팅이라 생각합니다. 남은 프로젝트 기간 동안 버그 수정 및 모니터링, 코드 정리, 문서화 등을 진행했습니다. 프로젝트 초기에 문서화 된 자료가 없어 코드 파악이 다소 어려웠기 때문입니다. 이 작업으로 사업 규모에 맞춰 제품을 확장할 때, 이전에 들었을 비용보다 훨씬 저렴하게 확장하실 수 있습니다.
사업 시점이나 상황에 따라 해야 할 일과 우선순위가 다릅니다. 다빈치는 고객사의 사업 파트너로써, 제일 득이 되는 방향을 제시하고 책임감 있게 완수하겠습니다. 지금 어려움을 겪고 계신다면 다빈치를 찾아주세요. 문제 해결을 위해 같이 치열하고 즐겁게 고민하겠습니다, 감사합니다.