구체적이지 않은 요구사항으로 개발하기- 확장성을 고려한 모델 설계

[shippingpark]

안녕하세요! 3기 보노 입니다.

10월 중에는 테크 포럼에 글을 써야지 계획했는데, 눈 떠 보니 11월 중순이 되었습니다.
많이 늦었지만 글자랑 대회가 끝나기 전에 한 몫 보태려 합니다.

서론

쇼케이스까지 정말 얼마 남지 않았습니다!

예상과 달리 저희 팀은 기획 변동과 디자인, 개발 설계 교체 등 많은 변화를 겪었습니다.
덕분에 일정은 빠듯해졌고, 이제 남은 2주 동안 구체적인 기획 요구사항, 디자인, 개발을 병행하며 진행해야 하는 상황입니다.

기획이 확정되지 않은 부분을 기다릴 시간이 없기 때문에,
기존 코드를 크게 수정하지 않고 추가만으로 대응할 수 있도록 확장성을 고민하며 작업 중입니다.

'추상적인 흐름은 있지만 구체적인 기획이 결정되지 않은' 현재의 상황은
'확장에는 열려있고, 변경에는 닫혀있도록 만들라'는 개방폐쇄의 원칙을 좇게 만듭니다.
(protocol을 학습할 때 접하는 자격증이라는 표현을 이해하기에도 적합한 것 같습니다)

'최대한 구체적 결정을 늦추라-'는 엉클 밥(클린 아키텍처 저자)의 조언을 새기는 상황이기도 합니다.

다양한 학습 키워드와 매칭 시켜 볼 상황인 것 같아
'구체적 요구사항이 추후 결정 되어도 문제 없도록' 만들기 위해 고민한 내용을 기록하고자 합니다.

어려운 주제를 다루거나 답을 제시하는 글은 아니지만 경험을 공유하는 자체가 누군가에게 도움이 된다면 좋겠습니다!

개발해야 하는 데 아직 결정되지 않은 게 많다

설명을 위해 저희 팀의 서비스를 간략히 설명 하자면 아래와 같습니다.

낯선 해외 여행 시 지출판단을 도와주는 앱

이 서비스에서 다루어지는 핵심 모델은

'사용자가 입력한 금액에 대하여 살지 말지 판단할' 책임을 가진 것으로,

실제 앱 화면에서는 '새'가 해당 책임을 상징합니다.

해당 모델이 필요한 화면 흐름을 기술하면 아래와 같습니다.

화면 흐름

[상황]
사용자가 지출판단을 위해

1. 여행국가 (나라)
2. 상위 카테고리
3. 하위 카테고리
4. 금액

을 입력하면

[핵심 모델]
서로 다른 기준을 가진 새들이 (판단기준들)

1. 현지인 입장에서 해당 카테고리에 해당 금액이 적절한 지
2. 한국인 입장에서 해당 카테고리에 원화로 변환한 금액이 적절한 지
3. 해당 카테고리에 해당하는 직전 소비 기록을 토대로 적절한 지

등 독립된 기준을 가지고 사용자가 입력한 금액이 적절한지 아닌지를 판단하여 보여 줍니다.

이 기능(모델)에 해당하는 hi-fi 화면을 가져와 보았습니다.

관련 화면

[새 정보]

현재 필요하지만 없는 구체적 요구사항

그리고 위의 새들을 만들기 위해 필요하지만 ,
현재 결정되지 않은(팀원이 열심히 만드는 중), 구체적 요구사항에는 아래와 같은 것들이 있습니다.

1. 각 판단기준에서(새들이) 좋다 나쁘다(O/X)를 판단할 기준값 미정
   1. 현재 국가 별 수집가능한 정보를 조사하는 팀원이 기준 마련 중
   2. 수집 가능한 정보에 따라 각각의 새들이 같은 평가 기준을 공유하진 않을 수도 있다고 전달 받음
      (ex_ 어떤 기준에서는 평균 값에서 3% 내에 있으면 긍정 판단, 어떤 기준에서는 평균 값에서 15% 떨어져 있으면 긍정 판단 등)
2. 판단기준이(새들이) 추가될 수도 있음 (세 가지 기준으로 고정 불가)

생각정리

이러한 상황에서 아래와 같은 생각을 했습니다.
(지금부터 금액평가를 수행하는 모델을 Bird 또는 새 모델이라 부르겠습니다)

1. 새들 마다 사라, 마라(O/X)를 평가하는 기준치가 다를 수 있으니 사전에 만들어 둘 수는 없겠다
2. 당장 1, 2번 새와 3번 새는 판단하기 위해 활용하는 데이터가 다르다 (1, 2는 국가 별 품목 값들을 기준, 3은 사용자 기록 기준)
3. 모든 새들이 각기 다른 타입이면 화면 계층에서 모델(도메인) 의존도가 너무 높아진다
   1. 하지만 새들을 보여주는 cell의 모양과 정보가 같으니, 분명 접점이 있다 (서로다른 타입으로 둘 필요는 없어 보인다)

결론

등등의 생각을 거쳐 내린 결론은

일관된 정보는 protocol로 추상화하고, 해당 타입을 채택한 구체적 타입을 만들자

화면 계층에서는 프로토콜 타입을 두고 구체적 구현 타입 없이도 화면을 작성할 수 있게 작성하자

입니다.

(추상적 정보와 구체적 정보를 분리함으로서)
기대하는 효과는

1. 추후 기준추가가 기존 코드의 변동을 야기하지 않을 것 (개방폐쇄원칙)
2. View가 도메인의 구체적 타입에 의존하지 않을 것 (기획의 변동이 야기되는 부분으로부터 View 독립/공수 최소화) (추상적 타입에 의존)

입니다.

모든 것은 추후 결정될 구체적 요구사항이 무엇이건 간에 영향 받지 않는 선에서 최대한 많은 개발진도를 나가기 위함 입니다.

코드 예시

추상적 정보(일관된 정보) 찾기

추상적 정보는 무엇일까요?
디자인 또한 구체적인 요구사항 없이 제작 되었기에
hi-fi 화면을 보면 '일관된 정보'가 무엇인 쉽게 찾을 수 있습니다.

1. 기준(새)의 이름 (ex 베트남 10년 차/ 한국 토박이)
2. 기준에 정보 (새 설명)
3. 찬반 여부 (O/X)
4. 각기 다른 기준을 토대로 한줄 평 ("이 가격이면 나쁘지 않아"/"너무 비싼데..? 정말 필요해?")
5. 객관적 판단 이유 ("베트남 로컬 카페의 평균 가격보다...")

각 새들이 다루는 구체적 정보나 멘트는 다르지만,
우리 서비스에서는 위의 다섯 개를 갖추어야만 '새/판단기준' 모델이라고 불릴 수 있습니다.

그러니 '새'가 되기 위한 조건을 프로토콜로 작성하였습니다

추상적 정보

/// 새가 되기 위한 조건
protocol Bird {
  var name: String { get }
  var information: String { get }
  var judgment: BirdJudgment { get }
  var opinion: String { get }
  var detail: String { get }
}

enum BirdJudgment {
  case bad
  case good
}

구체적 정보 (AbroadBird)

이렇게 공통의 추상적 정보를 protocol로 작성한 뒤
구체적 타입 작성 시 해당 프로토콜을 채택하여 각 속성에 배치될 내용을 기술하였습니다.

[위의 새를 상징하는 AbroadBird 타입]

/// 특정 해외 물가를 기준하는 새
struct AbroadBird: Bird {
  var name: String { return "" }
  var information: String { return "" }
  var judgment: BirdJudgment { return .good }
  var opinion: String { return ""
  var detail: String { return "당신의 선택은 ..." }
}

이 중 팀의 진도 상으로 구체적 기준이 마련되지 않은 정보는 새의 이름으로 노출되는 정보인 name 제외하고 전부 다 입니다.
(hi-fi화면에는 새의 멘트나 설명이 있지만 임시 값으로 구체적인 결정이 없음)

하지만 최대한 개발 진도를 많이 빼기 위해 구체적 새가 보여줄 정보에 어떤 값이 필요할 지는 유추할 수 있었습니다.
이를 고려한다면 이 정도까지는 앞서 작성해 줄 수 있게 됩니다.

/// 특정 해외 물가를 기준하는 새
struct AbroadBird: Bird {
  private let userQuestion: UserQuestion // ⭐️
  private let country: CountryCriteria // ⭐️
  var name: String { return "" }
  var information: String { return "" }
  var judgment: BirdJudgment { return .good }
  var opinion: String { return ""
  var detail: String { return "당신의 선택은 ..." }
}

유저가 요청한 질문을 담은userQuestion와 국가 품목 정보를 담은country는 모든 새들에게 필요한 정보는 아닙니다.
특별히 AbroadBird가 Bird로서 적절한 값을 반환하기 위해 필요한 정보입니다.
외부에 노출될 필요는 없지만 필요한 정보이기에 private으로 넣어주었습니다.

여기서! 구체적인 타입을 만들기 위해 속성을 추가하는 등 기능의 확장이 일어나고 있지만, Bird가 되기 위한 조건은 변화하지 않습니다 !

아래 코드는 대략적인 감을 위한 것으로 챗지피티에게 빈 칸을 채워줘 - 라고 요구한 코드를 조금 정제하였습니다.
(물론, 아예 Mock 타입을 만들어 구체적 요구사항이 결정될 때 까지 사용해 줄 수도 있을 것 같습니다!)

/// 특정 해외 물가를 기준하는 새
struct AbroadBird: Bird {
  private let userQuestion: UserQuestion
  private let country: CountryCriteria
  var name: String { return "\(country.name) 10년차" }
  var information: String { return "나는 \(country.name) 10년 차 짹짹이야! \(country.name)의 평균물가를 기준으로 너의 지출들을 판단해줄게!" }
  
  var judgment: BirdJudgment {
    let filteredItems = country.items.filter {
      $0.category == userQuestion.category && $0.subCategory == userQuestion.subCategory
    }
    
    guard !filteredItems.isEmpty else { return .bad }
    
    let averageAmount = filteredItems.map { $0.amount }.reduce(0, +) / Double(filteredItems.count)
    
    // 사용자의 금액과 평균 금액 비교
    if userQuestion.amount > averageAmount * 1.2 {
      return .bad // 사용자의 금액이 평균의 1.2배보다 높을 때
    } else if userQuestion.amount >= averageAmount * 0.8 {
      return .good // 사용자의 금액이 평균의 0.8배 이상일 때
    }
  }
  
  var opinion: String {
    switch judgment {
    case .bad: return "너무 비싼데..? 정말 필요해?"
    case .good: return "이 가격이면 나쁘지 않아"
    }
  }
  
  var detail: String {
    // 선택된 카테고리와 서브 카테고리의 평균 금액을 기준으로 세부 설명 작성
    let filteredItems = country.items.filter {
      $0.category == userQuestion.category && $0.subCategory == userQuestion.subCategory
    }
    
    guard let firstItem = filteredItems.first else {
      return "해당 품목에 대한 비교 정보가 없습니다."
    }
    
    let difference = userQuestion.amount - firstItem.amount
    if difference > 0 {
      return "당신의 선택은 \(firstItem.title)보다 \(difference) \(country.currency.unitTitle) 비싸요. 로컬 카페 <\(country.name) 카페>의 \(firstItem.subCategory) 사이즈와 비교할 때!"
    } else {
      return "당신의 선택은 \(firstItem.title)보다 \(-difference) \(country.currency.unitTitle) 저렴해요. 로컬 카페 <\(country.name) 카페>의 \(firstItem.subCategory) 사이즈와 비교할 때!"
    }
  }
}

앞서,
(추상적 정보와 구체적 정보를 분리함으로서)
기대하는 효과는

1. 추후 기준추가가 기존 코드의 변동을 야기하지 않을 것 (개방폐쇄원칙)
2. View가 도메인의 구체적 타입에 의존하지 않을 것 (기획의 변동이 야기되는 부분으로부터 View 독립/공수 최소화) (추상적 타입에 의존)

라 말했었는데요.

1 번은
위의 새가 되기 위한 필수 현조건을 protocol로 정의해 두었기에
기준이 추가된다면 단순히 이를 채택하여 구체화하는 방식으로
기준정보(새) 추가가 기존의 코드를 변화하지 않은 방식임을 보장받게 되었습니다.

또한, 2번인 View가 필요로 하는 정보는 Bird 타입으로 충족될 수 있습니다.
즉, View는 AbroadBird라는 구체적 타입을 알 필요 없이, Domain에 요청한 정보가 늘 Bird 타입으로 날아오면 충분합니다.

보다 자세히 설명하자면,
우리 프로젝트는 사전에 Model을 UseCase와 Entity로 역할 분류 하였습니다.
각 역할에 맞게 타입을 매칭 시키면 아래와 같습니다.
View - JudgmentView
UseCase - JudgmentUseCase
Entity - Bird / AboradBird

View -> UseCase

관계에서 View가 UseCase에게 건네는 요청은 아래와 같이 작성될 수 있습니다.

protocol JudgmentUseCase {
  /// 특정 국가, 카테고리, 서브 카테고리에 대한 판정을 요청하는 메서드
  func requestJudgment(userQuestion: UserQuestion) -> Result<[Bird], Error> 
}

View는 Bird의 구체적 구현 타입에 의존하지 않게 됩니다 !
어떤 과정을 거쳐서 정보가 정제 되었을 지는 몰라도 View가 필요한 정보는 Bird 타입 만으로도 충분히 전달되기 때문입니다.

let birds: [Bird] = [AbroadBird(...), LocalBird(...), PreviousDayBird(...)]

for bird in birds {
    print(bird.name)        // 각 새의 이름
    print(bird.information) // 각 새의 정보
    print(bird.judgment)    // 각 새의 판단 결과
    print(bird.opinion)     // 각 새의 의견
    print(bird.detail)      // 각 새의 세부 설명
}

이러한 고려는 '일단 나온 데 까지'의 개발 작업을 가능하게 합니다.
화면 작업 중 구체적인 기획이 나온다면 해당 내용을 해당 계층(Model/Domain)에서 작성하면 됩니다.
View는 Domain(Model)의 구체적 결정 사항에 영향을 받지 않으니 구체적 결정이 야기하는 View 계층의 수정은 최소화 될 수 있습니다.

더 나아가 이러한 작업은 각 기능 간, 계층 간 의존성을 분리시켜 유연한 테스트를 가능하게 할 것입니다!
(원하는 상황을 설정하고(input) 그를 토대로 output을 점검하기 용이해집니다) (타겟을 분리하는 등의 계층 간 물리적 분리를 진행하지는 않았습니다)

마치며

추상화된 프로토콜과 구체적 타입의 분리를 통해 변화에 대한 유연성을 높이고, 개발의 공수를 줄일 수 있었습니다.

다른 구현 방법도 비교해보고 싶었지만 시간과 경험이 부족하여 그만 글을 마무리 합니다. 피드백이나 조언은 언제든 환영합니다!

감사합니다!

[thinkySide]

구체적인 기획이 아직 정해져있지 않기 때문에, 고수준인 도메인 영역의 변화가 예상되고
그에 따라 저수준인 View 또한 도메인의 구체적인 타입에 대한 의존을 최소화해야한다!
라는 메시지가 너무나 와닿는 것 같습니다.

저는 지금까지 저수준이라면, 고수준을 의존하는 것이 당연하다고 생각했기에
모델(Entity)에 강하게 의존하는 구조로 프로젝트를 많이 진행했었습니다.
(모델을 어떻게든 확정지으려고 했던 것 같아요)

하지만 초기 개발 특성상 모델이 바뀌는 일들이 빈번해
결과적으로 View의 잦은 변경도 발생했던 것 같습니다.

보노의 글처럼 프로젝트의 특성 및 환경을 먼저 파악하는 시간을 가지고,
추상적인 정보를 모아 protocol로 묶어 구체적인 타입에 채택함으로써
양방향 모두의 의존도를 낮추는 전략을 실천해봐야겠어요!!
(이해한 내용이 맞겠죠,,?)

좋은 글 감사합니다! 👍

[shippingpark]

맞습니다! 두서없이 쓴 글인데 한톨 덕분에 글이 전달하고자 한 바가 정제된 것 같아요!

또 모델을 어떻게든 확정지으려고 했다는 말에 공감이 됩니다.
저 또한 실제 프로젝트 속에서는 저->고 로 가는 길목에는 인터페이스를 두지 않았던 것 같아요. (필요를 느끼기 어려웠습니다)
어디선가 '실제 프로젝트에서는 종종 도메인의 변동도 화면에 영향을 미치지 않기를 기대한다'는 구절을 어디서 본 것 같은데, 그 상황을 실감합니다 ㅎㅎ

추가적으로 한톨이 언급해준 키워드에 이래저래 엮이는 생각이 있어, 본문에는 언급하지 않았고 어쩌면 영양가도 없지만 흥미로울수는 있는...
생각들을 아래에 남겨봅니다!

(말이 길어져서 생각의 결론을 먼저 배치합니다!)

Bird 모델 생성은 Entity로서 고민되었지만, 우리 서비스에서 '새'의 역할은 단순 데이터 구조가 아닌 비즈니스 로직에 가까워, 이를 Entity로 보고 구체화 하는 시도는 자연스레 Entity 개념에서 벗어나 (여타 아키텍처 패턴 속) Model로 책임이 확장된 것일 수 있겠다

(관점도 다르고... 엄밀하게 정의하기 어려운 책임(Model, Entity...)의 쓰임을 구분하려 드는 게 의미가 없을 수도 있겠지만, 각기 통상적으로 굳어진 쓰임은 있는 것 같아 굳이 구별하려고 해 보았습니다)

본문에서 말하는 Bird 모델에 대한 고려는 '데이터 구조'로의 역할을 수행하도록 설정한 도메인 계층의 'Entity'로서 시작하였습니다.
하지만 고민 끝에 만들어 낸 Bird는 MVC 속 Model 관점에서 풀이되는 것이 잘 어울려 보입니다.

Entity와 Model에 대한 제 현재까지의 이해를 공유하자면 아래와 같습니다.

[Entity]
Entity는 특정 비즈니스 로직을 포함할 수 있지만, 많은 경우 데이터 구조에 초점을 맞추고 UseCase나 Service 계층이 구체적인 비즈니스 로직을 처리

[Model]
Model은 데이터와 비즈니스 로직을 함께 포함할 수 있는 경우가 많아, 단일 객체로 데이터를 처리하고 조작 가능

Bird는 기존의 Entity(사용자 질문, 나라 등)를 토대로 보여줄 값을 기준에 따라 계산하여 보일 책임을 지녔습니다. 그러니 일면 Entity가 아닌 Model에 가까워진 것이 아닐까 생각합니다. 물론 Entity도 로직을 포함할 수 있겠지만... 여지껏 Entity라 하면 데이터 구조에 초점을 맞추어 작성해 왔기에 Model과 비교하려는 것 같습니다.
클린아키텍처, DDD에서 파생된 Entity의 개념에 맞추려면 Bird의 구체적 타입 생성은 UseCase로 보는 게 좋을까? 생각하기도 했습니다.
하지만 사용자 행동 규약을 명시한 내용은 아니니만큼, 새 모델은 Entity와 UseCase 그 사이 Model 될락말락 쯤이 아닐까- 하는 두서없는 생각입니다

공감가는 댓글에 신나서 이것저것 말을 늘입니다. 감사합니다 한톨!

[thinkySide]

오,,! Model 과 Entity를 관성적으로 같은 개념으로 해석하고 있었는데,
보노의 이야기를 들으니 생각할 지점이 더 많아지는 것 같습니다!
('단일 객체로 데이터를 처리하고 조작 가능'이라는 문장이 Entity와의 미묘한 차이를 이해하는 데 도움이 되었습니다!)

새삼 단어 그 자체에서 오는 힘에 대해서도 곱씹어 보게 됩니다.
단어가 가진 진짜 의도와 맥락을 탐구하는 보노의 통찰력에 오늘도 배우고 갑니다,, 감사합니다!! 😆

[seolbotdae]

클린 아키텍처를 아직 많이 공부하지 못한 입장이라 이런저런 용어는 잘 모르지만
구체적인 모델이 정해지지 않은 상태로 개발을 하게 되는 상황이 많은 것은 많은 공감이 되는 것 같습니다!

어떻게 하면 변화에 더 유연한 개발을 할 수 있을까 고민해보던 차에 이 글을 보게 되었네요
다른 사람의 의견도 들을 수 있어서 너무 좋았습니다.

또 이런 의견이 다양할 수 있는 부분을 자신의 생각을 잘 풀어서 남들에게 공유해 주시는 것도 항상 감사하다고 생각하고 있습니다.