리뷰 기능에 대한 회고록

운영팀이랑 어떤 기능을 넣어야 유저들이 좋아할까 얘기하면서 리뷰 기능이 언급됐었다. 플랫폼 특성상 미디어에 대해서 얘기할 수 있는 공간이 있으면 페이지에 계속 머무는 시간이 증가하여 해당 기능을 넣으면 좋을 것 같다는 의견이 오고간 후에 기능 개발이 시작되었다.

들어온 지 얼마 되지 않아 바로 기능 개발에 투입되었고, 데이터베이스 설계도 처음이라 막막함이 컸다.
리뷰 기능을 구현하면서 리뷰 테이블이 멤버 테이블과 컨텐츠 테이블을 외래키로 참조해야 하는지 고민하고 있었다.

하지만 시니어께서 리뷰의 경우 멤버나 컨텐츠 정보를 조인하여 조회하는 경우가 많지 않기 때문에, 테이블을 직접 참조하기보다는 member_id, content_id와 같은 식별자 컬럼만 두는 것으로도 충분하다고 조언해 주셨다.

그동안 설계를 배울 때는 특정 데이터를 식별하는 ID가 있다면 항상 외래키(FK)로 참조하는 방식만 접해왔기 때문에 그것이 정답이라고 생각했다. 하지만 실제 서비스에서는 모든 관계를 FK로 묶다 보면 테이블 간 결합도가 높아지고, 불필요한 의존성이 생길 수 있다는 점을 알게 되었다.

이번 경험을 통해 데이터베이스 설계에서는 단순히 정규화나 관계 설정만을 고려하는 것이 아니라, 실제 데이터 사용 패턴과 서비스 구조를 고려해 적절한 수준의 의존성을 설계하는 것이 중요하다는 것을 배웠다.

아 실무를 하면서 배우는 게 엄청 많구나 라고 또 느꼈던 것이 있었다.
바로 해당 게시물에 리뷰의 답글이 몇개 달려있는지 클라이언트쪽에 데이터를 내려야했는데, 나는 당연히 content_review_reply 테이블에 content_review_id로 조회해 갯수가 몇개 있는지 sum을 해서 가져오려고 했다. 근데 시니어분께서 리뷰를 조회할 때마다 계산하느라 응답이 늦어지는 것까지 고려를 한 거냐고 물어보셨을 때 내가 전혀 생각하지도 않았던 부분을 지적해주셔서 놀랐다. 내가 서비스 경험이 부족해 이 기능을 고려할 때 거기까지 미처 생각할 수가 없었던 것이다.

리뷰의 답글이 달릴 때마다 content_review 테이블에 reply_count 컬럼을 추가해 reply 가 달리고 삭제될 때마다 reply_count를 업데이트만 해주면 content_reply의 답글 갯수를 가져올 때마다 sum 할 필요가 없어져버린다.

단순히 기능 구현에만 집중하는 것이 아니라 데이터 조회 성능과 확장성까지 고려하는 것이 중요하다는 것을 배웠다.
특히 조회 시마다 합계를 계산해서 내리기 보다, 계산된 값을 저장해서 불러오는 것이 실제 서비스 환경에서 더 효율적일 수 있다는 점을 이해하게 되었다!