프로젝트 | 설계 단계에서 확장성에 대한 고민

 

 

✨ 주요 내용

향후에 어떤 변동(기능 변경, 외부 서비스 등)에 영향을 받지 않도록 설계할 것

 

✍ 프로젝트 설계

프로젝트를 시작하면서 설계를 시작하게 되었다.

기획은 하지 않고, 요구사항이 주어진 주문 관리 플랫폼을 설계부터 구현하게 될 예정이다.

 

고려할 점

• 스프링 부트 기반의 모놀리식 어플리케이션이나 추후 MSA로 전환할 것.
  • 실제로 초기에는 모놀리식 아키텍처로 MVP 위주로 구현하고, 추후에 MSA를 도입한다고 한다.
  • 초기에 MSA를 도입하려면 프로젝트의 불확실성, 인력 및 인프라의 제한 등 여러 요인으로 힘들다.
• 협업 동료(예. 프론트엔드 개발자)에게 문서를 어떻게 제공할 것인가?
• RESTful API 설계를 위해 고려할 점은 무엇인가?
• 엔티티 간의 관계를 어떻게 설정해야 하는가?
• 확장성은 어디까지 고려해야 하는가?

 

고려할 점이 무척 심오하고 어려웠다.

특히, 확장성을 미리 고려해야 한다는 점이 가장 어려웠다.

 

확장성과 관련된 요구사항에 따르면

1. 지역은 초기에 한정하여 운영하며, 향후 확장을 고려한 지역 분류 시스템 설계
2. 향후 확장성이라함은 지역별 필터링, 지역 정보 수정 및 추가가 용이하도록 설계할 것.
3. 음식점 카테고리 추가, 수정을 고려한 유연한 데이터 구조 설계
4. 결제 시스템은 PG사와의 연동

이 정도가 있었다.

 

 

팀원들과 고민하던 점은 아래와 같다.

⚠️고민 사항 

1. 지역의 확장성이라는 것이 시/군/구/동 데이터를 DB에 저장해야할까? API로 주소 대체를 해도 될까? 테이블을 어떻게 구성해야할까? 사용자의 주소 필드를 어떻게 설계해야할까? 등 그냥 카오스 그 잡채
2. 음식점 카테고리는 카테고리 테이블을 마련함. (정답인지 아직 모르겠지만 해결)
3. 결제 시스템을 PG사와 연동하여 결제 내역 데이터만 저장한다는 것이 어느 정도까지 저장한다는 것일까?

 

---

설계 초안 완성 후 튜터님께 피드백을 받을 예정이었는데, 회의 중에 잠시 들러 확장성과 관련해 조언을 해주셨다.

명확하지 않은 것, 확장성을 고려해야한다는 것은 지금 어떤 비즈니스 로직으로 서비스를 제공할지 고민하기 보단
향후에 어떤 변동(기능 변경, 외부 서비스 등)에 영향을 받지 않도록 설계할 것을 고민해야 한다.

 

예를 들어

• 지역과 관련해서 라이더의 활동 반경으로 배달 가능 여부 등이 정해진다든지 배달과 관련한 지역 설정 등은 아직 모호하고 변경 가능성이 높다. 이런 경우 현재의 설계가 작은 비즈니스 로직 또는 기타 모듈에 영향을 받지 않도록 구성해야 한다.
• 결제도 마찬가지로 외부 서비스(PG사?)는 변경될 수 있다. 이에 영향받지 않도록 설계할 것!
• AI도 마찬가지. 제미나이를 채택하여 개발할 것이지만 GPT나 다른 API로 변경해야 할 수도 있다.
• 또한, AI API 연결과 같이 외부 서비스와 연동하는 것은 요청 응답을 받지 못했을 때, 어떻게 대응할 것인지도 고민해봐야 한다.

 

즉, 나중에 변경하려고 할 때 모듈을 갈아끼우든지 뭘 하든지 영향을 받지 않게끔 설계하는 것이 중요하구나..

 

<결론?>

향후에 영향 X 설계 ^_^