백오피스 튜닝기 4
개발일기
실무를 보면서 처음으로 알고리즘과 자료구조가 도움이 된다고 느꼈다.
지원부서에서 특정 기능이 안된다고 연락이 와서 살펴보는데 안되는건 아니고 그냥 느렸다. 말도 안 될 정도로…😲
의아한 마음에 최근 배포내역부터 살펴봤는데 해당 기능에 직간접적으로 영향을 줄만한 내역이 보이질 않았다.
그래서 해당 기능의 IO와 DB 쿼리부터 차근차근 확인을 했는데 별로 부하가 걸릴 것도 없었다.
“진짜 뭐지..?” 싶어서 코드를 까보니 맙소사…
해당 테이블에서 가져오는 row가 약 12,000개 정도였는데
이렇게 가져다가 시간복잡도 O(N^2)의 로직을 타고 있던 것이었다.
총 연산은 약 144,000,000회였으며, 이를 통해 클라이언트에 내려주는 데이터는 1.2MB 정도였다.
별다른 세팅도 안된 브라우저에서 싱글 스레드로 1.2MB를 통으로 렌더링하고 자빠졌으니 느릴 수밖에 없었던 셈.
…
…
…
…
…
…
…
…
…
대체 이런 코드가 어떻게 이제 와서 문제가 된 건지 원인을 찾기 위해 Git History를 보니 2017년 이후로 수정된 적이 없는 코드였다.
즉, 개발 당시에는 테이블에 row가 얼마 없었으니 아무런 문제가 되질 않다가 회사가 크게 성장하고 데이터가 쌓이기 시작하면서 파탄을 드러낸 셈이다.
테이블의 row가 1,500개였던 시절엔 2,250,000회의 루프가 돌았을 것이다.
테이블의 row가 3,000개였던 시절엔 9,000,000회의 루프가 돌았을 것이다.
테이블의 row가 6,000개였던 시절엔 36,000,000회의 루프가 돌았을 것이다.
현재는 12,000개이므로 144,000,000회의 루프가 돌고 있는 것이고… 🤢
Martin Fowler의 저서인 Refactoring에는 이런 주제가 나온다.
개발업계의 선구자로 불리는 사람들에겐 공통점이 있는데, 이 사람들은 항상 현재 자신이 맡은 임무의 완수만을 보는 게 아니고 그 이상의 미래를 생각한다는 것이다.
1990년대 후반에 Roy Fielding은 HTTP를 HTTP/1.0으로 업데이트하며 하위 호환성 문제를 고심하고 고심하다 Restful이라는 개념을 정립했다.
Martin Fowler는 미래의 동료와 자기 자신을 위해 좋은 설계와 깔끔한 코드에 항상 공을 들이고, 습관적으로 리팩토링을 할 것을 권고하며, 똑똑하고 스킬이 좋은 개발자도 좋은 개발자이지만, 좋은 습관을 아주 많이 들인 착실한 개발자도 아주 좋은 개발자라고 말한다.
자기 자신을 후자의 개발자로 보기도 하고.
“아… 나는 절대이런 식으로는개발하지 말아야겠다”
그 코드를 보면서 그동안 봐왔던 많은 글들이 한 번에 가슴으로 이해되고 와닿는 순간이었다.
(내가 개고생하니까 와닿더라…😥)
어쨌든 배운건 배운 거고, 이 폭탄을 치워야 될 사람은 결국 나인 것을… 😭
오늘 하루 내내 죽을둥살둥하며 이 코드를 고치고, 이 코드를 고침으로서 발생하는 사이드 이펙트까지 고치고…😨
우선 SQL을 갈아엎었다. 쿼리와 인덱스를 조정하여 쿼리의 성능을 높였으며, 이후 JQuery와 Mybatis로 작성돼있던 코드들을 Vue.js와 JPA로 마이그레이션했다.
그리고 재귀호출 로직을 변경했다. 굳이 재귀로 처리할 필요가 없는 로직이었기 때문이다.
그 외의 public API들과 각종 Validation 등등..
결국 모듈 하나를 통째로 고도화해버렸다.
아무튼 고생은 많이 했지만 그래도 부쩍 좋아진 성능과 새로만든 UI/UX를 보고있노라면 지원부서에서 좋아할 것 같아 힘이 난다. 🤗
큰 교훈을 얻은 하루였다.
