게시판 서비스의 해시태그 기능을 개선하기 위해 직접 소스코드를 수정하며 서비스를 고도화하는 작업을 진행하였다. 게시글과 해시태그의 관계를 다대다로 가져가는 것까지는 ERD로 설계하였으나, 자바 소스를 통해 직접 수정하는 작업이 필요하였다. AS-IS 게시글 엔티티에는 단일 해시태그 필드가 있었지만, TO-BE 게시글 엔티티에는 해시태그를 HashSet에 담아서 여러개를 관리하고, 이를 ManyToMany 어노테이션을 통해, 해시태그 엔티티와의 관계를 맺어주는 수정이 필요하였다. 이러한 작업은 단순히 엔티티 수정에만 그치는 것이 아닌, Service, DTO, Response, Repository 등 수많은 소스코드에 영향을 미치는 것으로 확인되었다. 더구나 Test 코드도 모두 다시 작성해야 할만큼 영향 범위가 컸기에, 실제 운영 중인 서비스에 적용되는 고도화 작업이었다면, 정말 신중히 처리해야겠다는 생각이 들었다. 이러한 작업으로 인해 기존에 잘 작동하고 있던 서비스에 장애가 생길 수 있기 때문이다. 작업을 진행하면서 느낀 점은, 단순히 필드 하나를 수정하는 것 뿐인데도, 전체 서비스에 상당한 영향을 줄 수 있다는 점에서 프로젝트 기획 단계에서 도메인과 서비스 단을 유연하게 설계하는 것이 참으로 중요하다는 생각이 들었다. 실제로 회사에서도 고도화 작업을 진행하는데 있어서, 영향 범위가 꽤 큰 작업이 종종 생기곤 한다. 그럴 때마다, 정말 많은 시간을 투자해서 소스코드 하나 하나 버그 없이 수정해주는 방법이 있고, 아니면, 애초에 고도화 작업을 중단하는 방법이 있다. 어느정도 테스트를 통해 극복할 수 있는 영향 범위라면, 시간과 비용은 많이 들더라도 고도화 작업을 진행하기도 하지만, 정말 많은 위험성이 있는 수정의 경우에는 다른 방향으로 틀어서 새로운 작업을 진행하기도 한다. 이처럼 모든 서비스의 변경 작업은 많은 부분 리스크가 있기 때문에 정말 신중하게 진행해야 된다는 점을 다시금 배울 수 있었다.
패스트캠퍼스 [직장인 실무교육]
프로그래밍, 영상편집, UX/UI, 마케팅, 데이터 분석, 엑셀강의, The RED, 국비지원, 기업교육, 서비스 제공.
fastcampus.co.kr
본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.