소프트웨어 설계를 위한 추상적, 구조적 사고 - 이선협

우리는 어떤 시니어가 되어야 하는가?

시니어 개발자는 풍부한 경험과 직관이 있지만, 경험과 직관에 의존하면 분명한 한계가 있다. 어떠한 문제를 발견하더라도 유연하게 해결할 수 있는 방법론을 익히는 것이 중요하다.

추상적 사고

개발자가 하는 거의 모든 일은 추상적이고 구조적인 생각을 통해 나온다.

추상
여러가지 사물이나 개념에서 공통 되는 특성이나 속성 따위를 추출하여 파악하는 작용

같은 지구를 나타낸 것이지만 사물을 어떻게 바라보냐에 따라서 어떤 게 추출되고 어떻게 표현되는 것인지 달라진다. 이를 추상화라고 할 수 있다. 결국 추상의 핵심은 사물을 단순화하고 재해석 하는 것이라고 할 수 있다. 그렇다면 어떻게 재해석 할 수 있을까?

요소 환원주의 (르네 데카르트)
무언가 높은 단계의 개념을 더 낮은 단계의 요소로 분해해서 정의하는 사고 방식 (사람 - 팔, 다리, 몸통 / 피부, 살, 뼈 / 세포, 혈관)

 

추상화 하는 과정

추상화는 더 구체적일 수도 있고 추상적일 수도 있다. 계층이라는 것이 존재하기 때문에 우리는 적절한 추상화 수준을 정해야 한다. 과도한 추상화는 실제를 파악할 수 없게 만든다. 올바른 추상화는 적절한 수준과 관점을 통해 나올 수 있다.

어디까지 구체화 할 것인가? 어디까지 추상화 할 것인가?

구조적 사고

구조적 사고란 내용을 겹치지 않고 빈틈없지 정리하는 것을 말한다. 그렇다면 구조화를 어떻게 할 수 있을까?

• 목적이 무엇인가?
• 어떻게 묶고 나누는 것이 좋을까?
• 어떤 순서로 나열하는 것이 좋을까?

중요한 것은 어떻게 나누고 채울 것인가를 정하는 것이다.

통계를 User 나 Post 에서 불러와서 보여줄 수도 있지만 성능을 위해 TotalStatus 라는 도메인을 추가했다. 도메인이 다른 데이터와 겹치니까 구조적이지 않다고 볼 수도 있지만 우리가 이 사실을 미리 알고 있다면 다시 한 번 구조화를 할 수도 있다. 주황색 영역은 통계 모듈, 초록색 영역은 코어 모듈이라고 가정한다. 이렇게 시스템적으로 분리를 해둔다면 구조적으로 문제가 없다. 즉, 구조화도 추상화처럼 단계가 있다.

---

추상화와 구조화의 구체적인 방법

문제 해결에 접근하는 두 가지 방법론

• Top-Down : 큰 문제를 정의하고 세부적인 문제를 찾아 해결하는 방법론
• Bottom-Up : 세부적인 문제를 해결하여 문제하여 전체 문제의 답을 찾는 방법

두가지 방법론은 상호 보완적이다.

모델링

추상적이고 구조적인 사고를 통해 모델을 만들 수 있다. 이 모델은 세상을 표현하기 위한 방법 중 하나이다. 모델을 만들 떄 추상화와 구조화는 동시에 발생한다. 모델링(Modelling)을 할때는 세 가지 방법을 이용한다.

 

Classification (분류)

어떻게 분류할 것인가? 최대한 비슷한 단위로 묶는 것이 좋다.

• Categorizing (비슷한 요소끼리 묶기)
  • 쇼핑몰 카테고리 (가구, 의류)
  • 나이 (10대, 20대)
• Grouping (특정한 기준으로 묶기)
  • 반 (1반, 2반)
  • 로그 (2월 1일, 2월 2일)
  • Lebeling 을 통해 요소에 속성을 부여한 뒤 묶는 것도 가능 - 태그

Abstraction (추상화)

어떻게 바라볼 것인가? 요소에서 관심있는 것을 뽑아내는 것

• Projection : 요소에서 필요한 내용을 뽑아내는 것
  • Class, Domain, Model ..
• Layering : 요소를 계층으로 나누는 것
  • 한 요소를 여러 관점으로 볼 수 있다.
  • OSI 7 Layer, Layered Architecture ...
  • 사물과 행위 모두 해당 된다.

Generalization (일반화)

어떤 공통점이 있는가? 비슷한 것을 묶어서 재사용할 수 있게 하는 것

• Pattern
  • 비슷한 사용 사례를 묶어 공통적으로 쓸 수 있게 하는것
  • Design Pattern, Function ...

프레임워크(Framework) 사고

• Frame과 Work를 합친 단어
• 틀에 맞춰 작업하는 것을 의미한다.
• 추상적이고 구조적인 사고를 통해 프레임워크를 만들 수 있다.
• 문제 -> 분석/분해 -> 결합

---

소프트웨어 설계

도메인 모델링

• 정의
  • 도메인은 우리가 해결한 '문제'에 대한 비즈니스 전문 지식
  • 요구사항과 전문 지식을 개발 세계의 언어로 바꿔야 한다.
  • 도메인 모델링은 ==비즈니스를 프로그램 세계로 표현==하는 것
• 내용
  • 요구사항에 핵심 요소를 찾을 수 있다.
  • 실제로는 여러 도메인 전문가랑 이야기를 하면서 더 많은 것을 뽑아내야한다.
  • 요구사항 수집 -> 전문 지식 습득 -> 모델링 -> 피드백 -> 요구사항 수집
  • 도메인 모델을 통해서 구체화 하는 것도 가능하다. 실제 코드에서는 데이터 속성을 추가하고 함수를 통해서 행위를 표현하게 된다.

아키텍처

• 정의
  • 아키텍처는 개발자가 일을 하는 방법을 나타낸다.
  • 아키텍처는 소프트웨어를 어떻게 만드는가와 어떻게 나누는가를 나타낸다.
• 내용
  • 요구사항 수집 -> 컨셉 -> 구현 -> 피드백 -> 요구사항 수집
  • 아키텍처는 요구사항과 조직에 따라 달라질 수 있다.
• 컨셉 아키텍처
  • 추상화된 시스템을 나타내고, 소프트웨어에 따라 달라질 수 있다.
  • 그에 따라 추상화, 구조화를 해보자
    • 전체 시스템 / 애플리케이션 / 서브시스템 / 모듈 / 인터페이스(통신) / 시스템 외부
• 구현 아키텍처
  • 컨셉을 여러 단계에 거쳐 구체화 한다. 비즈니스 요구사항과 조직 상황에 따라 달라지며 하향식으로 추상화, 구조화 할 수 있다.
  • 어떤 요구 사항인가?
    • 요구 사항에 따른 모데인 모델을 반영할 수 있는가?
    • 도메인 모델을 카테고라이징 할 수 있는가?
      달성해야할 성능 지표가 있는가?
    • 요구사항에 적합한 기술을 알고 있는가?
  • 우리 조직의 상황은 어떤가?
    • 개발자가 몇 명인가?
    • 각자 직군이 어떻게 되는가?
    • 퍼포먼스가 어떻게 되는가?

코드 작성

프로그래밍은 하나의 문제를 해결하기 위한 패러다임과, 그에 따른 방법론으로 구성된다. 사실, 패러다임은 컴퓨터가 보기엔 큰 의미가 없다. 패러다임은 사람을 위한 것이다.

리팩토링

리팩토링은 기능을 수정하는 것이 아니라, 기능은 그대로 두고 코드를 개선하는 것

3가지 리팩토링 방법

• 추상화 : 코드내용을 숨길 것인가 드러낼 것인가
• 구조화 : 코드 내용을 분리할 것인가 합칠 것인가
• 일반화 : 공통되는 내용을 분리할 것인가 의도적으로 중복시킬 것인가

---

느낀점

• 어떠한 작업을 하거나 설계를 할때 이선협님이 말한 것처럼 경험을 통해 직관적으로 떠올리거나 이렇게 해왔기 때문에 관성적으로 해왔던 일들이 있다. 다음에는 정확한 방법론을 통해서 어디까지 구체화하고 어디까지 추상화해야할 것인지 단계뼐로 접근하는 습관을 길러야겠다.
• 모델링과 도식화를 많이 해보고, 여러 관점에서 바라보는 훈련을 하자.