운영 중인 시스템의 1:1 구조를 1:N으로 바꾸기

현장실습을 시작한지 어느덧 2주가 흘렀다. 기존에 만들어져 있는 프로젝트 위에서 엔티티에 속성을 추가해서 구현하거나, 변경된 데이터 형식에 맞춰 DTO 바꾸면서 서비스 계층 로직을 수정하고 API를 별도 추가하는 등의 구현에 어느 정도 익숙해진 참이었다. 그러다 이번에 리뷰&코멘트 기능을 기존 1:1 구조(단일 댓글)에서 1:N 구조(다중 댓글)로 변경하는 업무를 맡게 되었다. 원래 내 담당은 아니었지만, 배정된 초기 업무를 일찍 마쳐서 일정이 바쁜 다른 직원분의 업무를 지원하게 되었다. 엔티티 설계를 많이 해본 것이 아니었기에 잘 할 수 있을지 걱정이었다. 하지만 단순히 별도 테이블을 만들어 연결해주면 된다고 생각했기에 크게 어렵지 않을 것이라 예상했다.

 

하지만 막상 코드를 열어보니 상황은 생각보다 복잡했다. 기존 시스템은 댓글이 하나만 달린다는 가정하에 설계된 구조였기에 해시태그, 첨부파일, 기본문서 등의 댓글 관련 데이터들이 모두 부모 엔티티인 리뷰&코멘트와 연관관계를 맺고 있었다. 화면만 봐서는 어떤 속성이 리뷰&코멘트에 속하고 어떤 것이 댓글에 속하는지 구분하기 어려웠다. 또한 댓글 관련 속성들을 별도 DTO로 분리해서 관리하지 않고, 리뷰&코멘트 관련 객체에서 흩어져서 처리되고 있었기 때문에 속성을 구분하는 것이 더욱 힘들었다. DB 상에서도 편의를 위해 리뷰&코멘트 테이블에 모든 속성을 때려 넣은 상태였기 때문에, 흩어져 있던 연관관계들을 추출하여 별도 댓글 엔티티로 재정립하는 과정은 엔티티 설계 경험이 부족한 나에게 험난한 도전이었다.

 

또한 단순히 댓글 엔티티만 분리하면 되는 문제도 아니었다. 해시태그나 첨부파일 등 댓글에 포함될 부가 속성을 처리하는 로직이 각각의 도메인 패키지에 산재해 있었고, 기존의 리뷰&코멘트 엔티티와 결합되어 있었다. 이 로직들이 더 이상 리뷰&코멘트가 아닌 새로운 댓글 엔티티를 참조하도록 의존성을 변경해야 했다. 기존의 단일 댓글 구조에 맞춰져 돌아가고 있던 서비스 코드를 수정하는 과정에서 사이드 이펙트가 발생하지 않도록 코드를 짜는 것 또한 까다로웠다. 이미 돌아가고 있는 코드를 분석해 의존성을 끊어내고, 새로운 설계 방향으로 안전하게 변경하는 과정이 신규 개발보다 더 까다롭고 높은 분석력이 요구된다는 것을 느꼈다.

 

그리고 리뷰&코멘트를 수정할 때 JPA의 변경감지 기능을 이용해 수정하는 것이 아니라, 별도 새 엔티티를 new 키워드로 생성하고 ID를 기존 엔티티의 ID로 설정하는 방식으로 수정 로직이 구현되어 있었다. 이 구조를 파악하지 못한 상태에서 구현을 하다보니 문제가 생겼다. 리뷰가 수정되면서 새로운 리뷰&코멘트 객체가 생성되자, 기존에 맺어두었던 댓글 엔티티와의 연관관계가 끊겼다. 때문에 댓글 엔티티에 대해 JPA의 변경 감지 기능이 동작하지 않았고, 댓글에 속한 해시태그나 첨부파일 수정 사항이 DB에 반영되지 않았다. 새롭게 생성된 객체에 기존 댓글들과의 연관관계를 다시 수립해주고 나서 문제가 해결되었다. 이 원인을 파악하는 데 오랜 시간이 걸렸다.

 

책을 읽을 때 과도하게 비판적이거나 자신의 주관을 지키려는 태도를 취하면, 글이 전달하고자 하는 핵심을 온전히 받아들이지 못하는 경우가 있다. 코드를 읽을 때도 마찬가지로, 코드를 작성한 사람의 의도를 이해하기 위해서는 나의 관점을 잠시 내려놓고 그 코드가 왜 그런 구조와 흐름을 갖게 되었는지를 따라가려는 자세가 필요하다는 것을 느꼈다. '나라면 이렇게 짰을 텐데'라는 생각을 앞세워 코드를 보다 보니, 사소해 보이는 흐름이나 맥락을 놓치게 되고, 그 결과 데이터가 어떤 방식으로 관리되고 흘러가는지를 잘못 이해하게 될 수 있다는 점을 깨달을 수 있었다.

 

데이터 이관 전략도 고민해야 했다. 급하게 구조를 변경하면 운영 중인 화면(View)에서 기대하는 데이터 형식이 달라져서 에러가 발생할 수 있기 때문이었다. 새로운 댓글 엔티티를 생성하되 기존 리뷰&코멘트 엔티티의 댓글 관련 컬럼들은 삭제하지 않고 유지했다. 이전 레거시 데이터를 통해 뷰쪽에서 렌더링 해주고 있었기 때문이다. 별도 댓글 엔티티가 생성됨에 따라, 리뷰&코멘트 엔티티에는 댓글과 관련된 속성이 null로 들어가게 하고 댓글 엔티티에 저장되도록 했다. 그리고 추후 댓글과 관련된 속성 값이 아직 리뷰&코멘트 엔티티에 저장되어 있는 과거 데이터들에 대해, 댓글 관련 속성들을 새 댓글 엔티티로 모두 이관한 뒤, 댓글과 관련된 속성은 리뷰&코멘트 엔티티에서 제거하는 방식으로 설계하였다.

 

댓글에 달리는 첨부파일의 경우, 기존 단일 코멘트 기반의 레거시 형태의 데이터라면 기존 리뷰&코멘트 엔티티와 연결을 끊고 댓글 엔티티와 연결을 맺도록 하였다. 그리고 다운로드 할 때는 리뷰&코멘드 엔티티와 연결이 맺어져 있으면 단일 댓글 구조의 레거시 데이터로 간주하고, 댓글 엔티티와 연결을 맺고 있다면 바뀐 다중 댓글 구조 기반에서 생긴 데이터로 간주하여 호환되도록 하였다. 그리고 뷰 로직에서는 전달받은 DTO에 신규 댓글 데이터가 존재하면 새로운 구조로 렌더링하고, 그렇지 않다면 기존의 방식대로 렌더링 하도록 했다. 데이터 이관이 완료되지 않은 시점에서도 에러 없이 서비스가 운영되도록 호환성을 고려해야 했다.

 

결국 마음가짐이 중요하다는 것을 깨달았다. 처음 코드를 까봤을 때 몇 천 줄이 넘는 파일들이 여러 개이다 보니, 시작부터 압도되어 자신감을 잃었던 것 같다. 그러다 보니 코드 흐름을 주도적으로 파악하기보다 AI에 의존하게 되었는데, 오히려 독이 되었다. 내가 내용을 모르니 AI가 답변을 줘도 사실 여부를 판단할 수 없어 와닿지 않았고, 의존할수록 전체적인 구조는 더 안 보이고 능률만 떨어졌다. 무엇보다 AI가 여러 클래스들과 얽혀있는 복잡한 연관 관계를 모두 파악하지 못하기 때문에, 정확한 답변을 내놓지 못하는 경우가 많았다. 오히려 긴장을 풀고 가벼운 마음으로 함수 하나, 모듈 하나씩 차분히 따라가다 보니 그제야 흐름과 구조가 눈에 들어왔다. 전체적인 큰 그림을 알게 되니 문제가 터져도 어디가 원인인지, 데이터 흐름을 확인하려면 어디에 로그를 찍어야 할지 스스로 판단할 수 있었다. 당장 빨리 구현해야 한다는 압박감을 내려놓고, 차근차근 구조와 흐름을 온전히 내 것으로 만드는 과정이 중요하다고 생각되었다.