다작 방법론 질문

Question

강의 설명에서 다작 방법론 단점으로 조합되는 가지의 수가 많아질수록 코드 복잡성 증가를 얘기하셨는데요 보완방법으로 큰 범주단위로 프로젝트를 분리하라고 설명해주셨습니다. 그렇다면, 커뮤니티 관련 프로젝트의 경우 해당 프로젝트용으로 코드 구조를 공통적으로 짰는데, 그 안에 예시로 든 웃긴짤방 앱에서는 공통 구조외에 다른 코드가 필요할 수 있잖아요. 이 경우에 이 앱(웃긴짤방 앱)만 사용할 수 있도록 공통 구조를 짠 코드에서 따로 코드를 추가해서 이 앱만 사용할 수 있도록 db 나 클라이언트에서 처리를 해서 해당 앱에서 특정 기능이나 화면을 표출할 수 있도록 처리하시는걸까요? 아니면 애초에 이런 경우가 발생하지 않도록 공통 구조를 짜놓고 이 외의 추가 구성같은건 없게끔 하시는걸까요? 혹시 이런 상황에서는 어떻게 처리하시는지 궁금합니다.!

프로그래밍좀비 · Answer

안녕하세요! 정말 실무에서 자주 마주치는 좋은 질문이네요 😊 말씀하신 상황은 개발하다 보면 정말 빈번하게 발생하는 문제입니다. 저도 이런 경우를 해결하기 위해 category 와 ui_type 을 활용한 구조로 처리하고 있어요. 구체적인 예시로 설명드리면 다음과 같이 3개의 앱이 하나의 공통 플랫폼으로 구성되어 있다고 가정해보겠습니다: 첫 번째 앱 : 대학 커뮤니티 두 번째 앱 : 웃긴 짤방 세 번째 앱 : BTS 팬 커뮤니티 Case 1: UI만 다르게 구성해야 하는 경우 첫 번째와 세 번째 앱은 기본적인 커뮤니티 형태로 동일하지만, 웃긴 짤방 앱은 이미지 중심의 다른 UI가 필요한 상황이라면 - 첫 번째, 세 번째 앱: ui_type = "v1" (기본 커뮤니티 UI) - 두 번째 앱: ui_type = "v2" (이미지 중심 UI) 이렇게 하면 같은 커뮤니티 앱이라도 ui_type 이 "v2"일 때는 완전히 다른 UI로 렌더링할 수 있습니다. Case 2: 근본적으로 다른 기능이 필요한 경우 만약 웃긴 짤방 앱이 단순한 UI 변경을 넘어서 아예 다른 기능과 구조가 필요하다면 - 첫 번째, 세 번째 앱: category = "community" - 두 번째 앱: category = "community_comic" 이처럼 아예 다른 카테고리로 분류해서 해당 카테고리에 맞는 전용 화면과 기능을 추가하는 방식입니다. 실제 구현에서는 이런 구조를 통해 데이터베이스와 클라이언트 모두에서 조건부 처리가 가능해집니다. 예를 들어 데이터 레벨 : category나 ui_type에 따라 다른 스키마나 필드 활용 클라이언트 레벨 : 해당 값들을 기준으로 다른 컴포넌트나 레이아웃 렌더링 이렇게 하면 공통 구조의 장점은 유지하면서도 각 앱의 특수한 요구사항을 유연하게 수용할 수 있어요. 완전히 별도 프로젝트로 분리하지 않고도 효율적으로 관리할 수 있는 방법이라고 생각합니다!