데이터 이관 방식
사실 여기에는 이야기할 것이 많지 않지만, 중요한 내용이 있기 때문에 넣었다.
앞서 깃 전략을 세울때에는, 테이블 명을 바꾸는 방식으로 접근 하려 했으나 테이블 명을 바꾸지 않고 새로운 테이블을 만들어서 정보를 삽입하는 방식으로 진행했다.
테이블 명을 바꿔서 톰캣에 문제가 생길 수도 있고 실제 운영하고 있는 서비스라 어떤 사이드 이펙트가 발생할지 몰랐기 때문이다.
그렇게 flyway로 새로운 테이블 들을 만들어서 정보를 이관시켰다(전체 코드는 GitHub 참고)
그럼 DB 관련해서는 작업이 다 끝났으니 새로운 API만 만들면 되는 것인가? 라고 생각할 수 있는데, 그렇지 않았다. 실제로 서비스 하고 있는 것이기 때문에 업그레이드하지 않고 기존 API를 사용하는 사람들도 고려해야 했다.
따라서 기존 API 버전의 서비스 로직을 새로운 테이블과 연결하도록 수정했다. 업데이트를 하지 않은 사용자들도 기존 API를 사용할 수 있어야 하며, 업데이트 이후에도 데이터를 가져올 수 있어야 했기 때문이다.
이렇게 기존 api 들을 수정하고 새로운 커스텀 시간표 요구사항에 맞춰서 새로운 api들을 추가했다. 그럼 기존 api와 새 api의 차이점이 뭔가?에 대한 의문이 들 수 있는데 완전히 새로운 서비스로 바뀌는 것이라 반환 값도 달라지고 세부적인 로직도 변화했다.
작업한 API들
그렇게 작업한 api들이다.
도메인이 복잡하고 이해할 것이 많아 정말 쉽지 않은 작업들이었다.
하지만 이러한 고생 끝에 성능이 크게 향상되었습니다.
성능 향상
로컬 기준으로 MySQL Workbench에서 단순 측정한 결과, 환경에 따라 성능 향상이 다르게 나타날 수 있지만, 최소 40% 이상의 성능 향상을 보였다.
느낀점
이번 시간표 개편 프로젝트는 단순한 기술적 과제를 넘어서, 협업과 문제 해결의 소중한 경험이었다. 이 프로젝트를 통해 저희 팀은 더 높은 수준의 데이터베이스 구조를 구현할 수 있었고, 사용자 경험을 크게 향상시킬 수 있었다.
이 과정에서 많은 도전에 직면했지만, 서로의 지혜와 노력 덕분에 모든 난관을 극복할 수 있었다. 매 순간 함께 고민하고 해결해나가며, 팀워크의 중요성과 가치에 대해 다시금 배우게 되었다.
이 자리를 빌려, 팀원 모두에게 깊은 감사를 표하고 싶다.
