2023년 인프콘 후기 - #1 소프트웨어 설계를 위한 추상적, 구조적 사고

Joshua_Kim·2023년 8월 15일
9

2023년 인프콘 회고

목록 보기
2/7
post-custom-banner

🌱 서론

  • 📣 스피커 : 이선협 (코발트)
  • 세션을 선택한 이유
    - 이제 막 3년차 개발자로 들어가는 시점에서, 소프트웨어 설계, 추상적 사고, 구조적 사고 라는 키워드를 들었을 때, 이제 나도 그런것 들에 대해 고민 해봐야 하지 않을까 생각하게 했다.
    - 단순히 코드를 '기능이 돌아가도록' 하는 것을 넘어 '더 좋은 소프트웨어' 에 대한 고민을 하고 있었다.

✍🏻 세션 정리

1. 개발자와 프로그램

개발자가 하는 일은 무엇인가 ?

개발자는 '프로그램을 만드는 일' 을 한다.

프로그램은 왜 만들어는가?

프로그램은 '문제를 해결하기 위해' 만들어진다.

그렇다면, 개발자라는 존재는 어떤 존재인가?

개발자는 '프로그램'을 통해 '문제를 해결'하는 존재.
그리고 개발자로서 일하는 것은 이런 문제를 해결함을 통해 금전적 이익💰을 얻는 행위를 하는 것을 의미한다.

🍬 문제 해결을 위한 프로세스

이런 프로세스를 기반으로 다양한 방법론들이 있다.
이러한 프로세스가 왜 팔요한 이유는 다음과 같다.

  1. 현실의 문제를 컴퓨터라는 가상의 공간에서 해결을 해야 하므로, 적합한 설계가 필요하다.
  2. 설계가 되었으면, 현실의 문제를 컴퓨터 시스템에서 해결 하도록 전산화 하는 과정이 필요하다.

개발자는 단순히 '코드 작성' 만을 하는 것이 아니라, 위 사진에서 보이는 프로세스 전반에 걸쳐서 역할을 하게 된다.
개발자가 문제를 해결함에 있어서 풍부한 경험, 직관이 있다면, 그것에 의존하게 되지만 한계가 존재한다.
(물론, 경험과 직관 또한 매우 중요하다)

  • 경험하지 못한 새로운 문제 직면,
  • 잘못된 직관을 가졌을 경우

그러므로 '유연하게 해결할 수 있는 방법론'을 익히는 것이 중요하다. 🔑

  • 이를 통해 경험, 지식 범위를 벗어나 다양한 도메인, 환경에 빠르게 적응할 수 있다.

2. 추상적, 구조적 사고

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

🍧 유연하게 해결할 수 있는 방법론 1 - 추상적 사고

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

사실, 개발자들은 추상 이라는 개념을 상당히 많이 접한다.
하지만, 제대로 설명하기란 쉽지않다.

공통화와 추출 : 추상에서 가장 중요한 기법

  • 공통된 요소를 뽑아내는 것. 이것이 추상의 핵심이다.
  • 사물을 어떻게 바라보는가? 에 따라 추출되고 공통되는 부분이 다르다.

추상의 핵심 : 사물을 단순화하고 특정 관점에 따라 재해석하는 것.

🍒 어떻게 사물을 단순화하고 재해석하는가?

현상 / 물체 -> 분석 / 해체 -> 결합

대상을 가능한 만큼 분해 후, 의도목적을 가지고 결합한다.
여기서 중요한 것은 '무의미한 분해는 의미가 없다' 는 것이다.
뼈만 보고 원래 진짜 모습을 알 수 없듯이, 과도한 추상화는 실제를 파악할 수 없다.
즉, 과도한 추상화는 개발에서도 위험하다.

어떤 기준으로 분해하고, 어떤 의도와 목적으로 결합하느냐에 따라 추상화의 결과가 다를 수 있다.

👉🏻 올바른 추상화는 '적절한 수준과 관점' 을 통해 나올 수 있다.


🍰 유연하게 해결할 수 있는 방법론2 - 구조적 사고

구조적 사고의 3가지 키워드 🔑

  • 목적
  • 무엇을 묶고 나눌 것인가
  • 어떤 순서로 나열할 것인가

👉🏻 구조적 사고: "어떻게 나누고 채울 것인가" 에대해 고민하는 것,

🍧 추상화와 구조화에 대한 절대적인 기준은 없다.
늘 그렇듯, 은탄환은 존재하지 않는다.
구조화와 추상화는 흑백논리처럼 되거나 안되거나의 문제가 아니라, 계층과 같이 단계가 있다.

🍡추상화와 구조화의 실무에서의 적용점

탑다운, 바텀업

탑다운

  • 큰 문제를 먼저 정의하고, 세부적인 문제를 찾아 해결하는 방법론
  • 하향식 접근법
  • 문제를 큰 문제에서 작은 문제의 방향으로 '분해'한다.

바텀업

  • 세부적인 문제를 해결하면서 전체 문제를 답을 찾음
  • 상향식 접근법
  • 작은문제를 '결합'하면서 큰 문제를 해결 한다.

🍰 두 방법은 상호 보완적이다.

모델

개발자는 현실의 문제를 추상적이고 구조적인 사고를 통해 모델로 표현 할 수 있다.

모델링 기법의 3가지

🍡Classification

  • '어떻게 분류할 것인가?'
  • Categorizaing : 비슷한 요소끼리 묶는것
  • Grouping : 특정한 기준으로 묶는 것.

🍭Abstratcion

  • '사물을 어떻게 바라볼 것인가?'
  • Projection : 요소에서 필요한 내용을 뽑는것
  • Layering: 요소를 계층으로 나눔

🍬Generalization

  • '어떤 공통점이 있는가?'
  • Pattern: 비슷한 사용사례를 묶어 공통적으로 쓸 수 있게 하는것.
  • 디자인 패턴등이 좋은 예시.

3. 소프트웨어 설계

소프트웨어는 다음 3가지 과정을 거쳐 만들어진다.
1. 도메인 모델링
2. 아키텍쳐
3. 코드 작성

🍫 도메인 모델링

위에서 언급했듯이 개발자는 문제를 프로그램을 통해 해결하는 존재를 의미한다. 👨🏻‍💻

도메인은 우리가 해결할 문제 를 의미하며,
그러므로 개발자는 도메인을 통해 비지니스 로직을 설게 하는 것이다.

도메인 모델링 : 비지니스를 프로그램 세계로 표현하는 것.
즉, 요구사항과 전문지식을 개발세계로 변화시키는 과정을 의미한다.

모델링은 단계적인 추상화를 통해 현실의 문제를 프로그램 세계로 변화시킬 수 있다.
도메인 모델을 추상화를 통해 구체화 시키면 비지니스 문제를 개발세계로 가져올 수 있다.

🍪 아키텍쳐

아키텍쳐 : 개발자가 일을 하는 '방법' 을 의미한다.
아키텍쳐는 소프트웨어를 '어떻게 만드는가', '어떻게 나누는가' 를 의미한다.

일을 하는 방법을 의미하므로, 소프트웨어의 요구사항과 조직에 따라 달라질 수 있다.
아키텍쳐 문서를 통해 개발자들 간의 규칙을 생성할 수 있다.

아키텍쳐는 조직의 상황에 따라 변동가능하므로 언제든 변경가능하다는 유연한 사고를 가지는 것이 중요하다.
조직에서 가장 적정한 아키텍처가 무엇인지에 대한 고민은 필수적이다.

💻 코드작성

패러다임

프로그래밍 패러다임

  • 프로그램을 바라보는 관점. 인식의 틀
  • 소프트웨어가 무엇으로 구성되어 있는가?

프로그래밍은 하나의 문제를 해결하기 위한 패러다임과, 그에 따른 방법론으로 구성된다.

사실, 패러다임은 컴퓨터가 보기엔 큰 의미가 없다. 패러다임은 사람을 위한 것이다.

패러다임의 좋은 예시 : 객체지향 패러다임
이러한 객체지향 패러다임을 필두로 여러 객체지향적 코딩 방법론이 생기게 되었다.

👉🏻 내가 만드는 소프트웨어는 어떤 패러다임이 적합한지 고민하는 것이 매우 필요하다.

로직

로직의 3가지 관점

  • usecase: 로직이 어떤 기능을 위해 존재하는지. 기능에 어떤 로직이 필요한가?
  • aspect : 로직이 어떤 관점에서 사용되는지. 공통적으로 사용되는 로직이 무엇인가?
  • function : 로직을 구성하는 함수. 로직에 어떤 함수가 필요한가?

세 가지 관점에 따라 로직을 분류 할 수 있다.

리팩토링

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

3가지 리팩토링의 방법

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

👉🏻추상화, 구조화, 일반화의 '수준을 정하는 것'이 리팩토링 이다.

🙏🏻 개인 소감

추상화와 구조화에 대한 인상적인 비유와 설명을 들었다.

개발이라는 것이 단순히 코드를 작성하고 기능을 동작하는 것에 그치지 않고,
더 좋은 코드를 위해 고민하고 생각을 끊임없이 하는 철학적인 것임을 다시 확신하게 되었다.

개발자는 코더가 아니다.
개발자는 소프트웨어을 찍어내는 사람이 아니다.

고민하지 않고,
더 욕심내지 않으면 성장할 수 없다.

profile
인문학 하는 개발자 💻
post-custom-banner

0개의 댓글