인프런 커뮤니티 질문&답변

안녕하세요. yahohoho님

앞으로의 유지보수와 개발 관점에서보면 정리를 하고 가면 좋겠지만, 실무에서는 다양한 고민이 함께 필요합니다.

현실적인 조언을 몇 가지 드리겠습니다.

1. 비즈니스는 멈추면 안 됩니다.

기획팀과 회사는 '깔끔한 코드'보다 '비즈니스의 성장'을 원합니다. 엔지니어의 욕심으로 몇 주간 신규 기능을 멈추고 리팩토링만 한다면, 비즈니스 타이밍을 놓칠 수 있습니다. "기술 부채 청산"은 서비스를 계속 운영하면서 이자 갚듯이 조금씩 해나가는 것이지, 파산 신청하듯이 모든 걸 멈추고 하는 게 아닙니다.

2. 식별 관계, 불편하지만 당장 서비스가 망하진 않습니다.

과거의 레거시인 식별 관계(Identifying Relationship)가 개발 유연성을 떨어뜨리고 코드를 지저분하게 만드는 것은 사실입니다. 하지만 이것이 당장 서비스의 치명적인 버그를 유발하거나 데이터 정합성을 깨뜨리는 것은 아닙니다. '불편함'과 '위험함'을 구분해야 합니다. 지금은 '불편함'을 안고 가는 것이 맞습니다.

3. 동료가 오면 그때가 기회입니다.

데이터 마이그레이션은 정말 무섭고 떨리는 작업입니다. 혼자서 판단하고 실행하다가 실수하면 돌이킬 수 없습니다. 곧 합류할 동료분이 오시면, 가장 먼저 해야 할 일은 리팩토링이 아니라 '업무 파악'과 '적응'입니다. 신규 기능을 함께 개발하면서 호흡을 맞추고, 그분이 시스템에 익숙해졌을 때 함께 전략을 짜서 가장 아픈 부분부터 하나씩 비식별 관계로 풀어내시길 바랍니다.

물론 시스템이 매우 작아서 금방 리펙토링이 가능한 수준이라면 정리하고 가면 되고, 그렇지 않고, 비즈니스를 일시 중단해야 할 정도로 오랜 작업이라면 말씀드린 방향이 맞다 생각합니다.

감사합니다.

안녕하세요, 인프런 AI 인턴입니다.
yahohoho님, 데이터베이스 설계와 관련된 고민에 대해 말씀해 주셔서 감사합니다. 영한님의 강의를 통해 실무에서 많은 자신감을 얻었다니 기쁩니다.

지금 제시하신 두 방안에 대해 고려해볼 만한 요소들을 말씀드리겠습니다.

방안 A: 일괄 재설계를 통한 기술 부채 청산

• 장점: 설계를 한 번에 정리하여 기술 부채를 청산할 수 있으며, 장기적으로 기술적 발전을 도모할 수 있습니다.
  
• 단점: 현재 진행 중인 프로젝트 일정과 조화를 이루기 어려울 수 있으며, 리스크가 크고 실패 시 타격이 클 수 있습니다.
  

방안 B: 팀원 합류 후 점진적 조정

• 장점: 서비스 운영 중 안정성을 유지할 수 있으며, 새로운 팀원이 합류하면 인력을 활용해 리팩토링과 신규 기능 개발을 함께 추진할 수 있습니다.
  
• 단점: 일정이 길어질 수 있고, 식별 관계로 인한 문제점을 완화하는데 시간이 걸릴 수 있습니다.
  

영한님의 실무 경험을 빗대어 보면, 서비스 안정성을 우선시하면서도 기술 부채를 해결하는 것이 중요합니다. 따라서 방안 B를 선택하여, 영향도가 큰 부분부터 점진적으로 수정해 나가며, 팀원이 합류한 뒤 안정성을 확보한 상황에서 리팩토링을 진행하는 것이 좋을 것으로 보입니다. 이는 리스크를 관리하면서도 기술 부채 문제를 해결할 수 있는 현실적인 접근법입니다.

아래의 문서를 통해 Spring Boot와 관련된 데이터베이스 초기화 및 접근 방식에 대한 내용을 참고하실 수 있습니다.
- Spring Boot Database Initialization
- Spring Boot Data Access

추가적으로, Spring 관련 기술 사용 시 도움이 될 수 있는 자료를 확인하는 것도 좋은 방법입니다.
- Spring Data JDBC 관련 도움 피드백

도움이 되셨길 바랍니다. 항상 성공적인 프로젝트 개발을 기원합니다!