인프런 커뮤니티 질문&답변
작성한 질문수
다작 방법론 질문
해결된 질문
작성
·
36
0
강의 설명에서 다작 방법론 단점으로
조합되는 가지의 수가 많아질수록 코드 복잡성 증가를 얘기하셨는데요
보완방법으로 큰 범주단위로 프로젝트를 분리하라고 설명해주셨습니다.
그렇다면, 커뮤니티 관련 프로젝트의 경우
해당 프로젝트용으로 코드 구조를 공통적으로 짰는데, 그 안에 예시로 든 웃긴짤방 앱에서는 공통 구조외에 다른 코드가 필요할 수 있잖아요.
이 경우에 이 앱(웃긴짤방 앱)만 사용할 수 있도록 공통 구조를 짠 코드에서 따로 코드를 추가해서 이 앱만 사용할 수 있도록 db 나 클라이언트에서 처리를 해서 해당 앱에서 특정 기능이나 화면을 표출할 수 있도록 처리하시는걸까요?
아니면 애초에 이런 경우가 발생하지 않도록 공통 구조를 짜놓고 이 외의 추가 구성같은건 없게끔 하시는걸까요?
혹시 이런 상황에서는 어떻게 처리하시는지 궁금합니다.!
답변 1
1
안녕하세요! 정말 실무에서 자주 마주치는 좋은 질문이네요 😊
말씀하신 상황은 개발하다 보면 정말 빈번하게 발생하는 문제입니다. 저도 이런 경우를 해결하기 위해 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에 따라 다른 스키마나 필드 활용
클라이언트 레벨: 해당 값들을 기준으로 다른 컴포넌트나 레이아웃 렌더링
이렇게 하면 공통 구조의 장점은 유지하면서도 각 앱의 특수한 요구사항을 유연하게 수용할 수 있어요. 완전히 별도 프로젝트로 분리하지 않고도 효율적으로 관리할 수 있는 방법이라고 생각합니다!