🌱 0. 서론

• 📣 스피커 : 김재민 - 토스페이먼츠
• 세션을 선택한 이유
  개발자 세션에서 치트키가 몇개 있다. 그 중 '지속가능한' 과 '설계' 는 매우 군침이 나오는 주제다. 게다가, 김재민님은 '제미니' 라는 이름으로 활동하시는 매우 유명한 분!
  

✍🏻 1. 세션 정리

👀 설계를 잘하는 방법이 있다?

주니어 개발자는 주어진 기능을 개발한다.
주로 작은 단위로 기능 개발의 업무가 주어지고 이미 가이드가 나온 방향대로 개발을 하게 된다.
조금 연차가 쌓이고 주니어에서 미들이 되는 시점부터는 '설계' 를 조금씩 하게 된다.
그리고 설계를 하면서 점차 설계의 중요성을 체감하게 된다.

요구사항 분석 -> 설계 -> 구현 -> 테스트 -> 운영

보통 어플리케이션을 개발한다고 하면 위의 플로우를 따르게 된다.
요구사항이 주어지게 되면 요구사항을 분석하고,
그 분석을 토대로 어떻게 프로그램을 구현할 것인지 설계를 한다.
그리고 그 설계에 맞추어 구현을 진행하고, 테스트를 하며 그 이후 운영을 하게 된다.

설계를 여러번 하면서 느꼈던 것은, 잘못된 설계는 구현을 어렵게 한다는 것이었다.
그래서 더더욱 설계가 중요하다고 느꼈었고,
이 세션을 통해서 더 좋은 설계, 그리고 설계를 더 잘하는 방법에 대해서 배우고 싶었다.

그런데, 이게 무슨일이람..? 🙃

예..?ㅋㅋㅋ...???????

설계를 잘하는 방법 = 설계를 하지 않는 것 😛

선생님 이해가 안됩니다.
무슨말씀이죠?
설계를 배우러 왔는데 설계를 하지 말라니요... 🙀

💎 구현에 집중해보자

🔑 keyword - '개념'

예를 들어 '웹툰 서비스' 를 개발한다고 가정해보자.
이 서비스를 만든다고 했을 때, 위와 같은 개념들이 도출된다.

그리고, 이런 개념들을 '그룹화' 하게 된다.
그런데, 여기서 그룹화를 하고나면 위의 사진 처럼 서로 다른 그룹들의 요소들이 또 다른 그룹으로 묶이게 되는 것을 볼 수 있다.
이런 개념들이 묶이게 되고, 그룹이 많아지게 되는데, 이렇게 되면 개념간의 경계, 흐름이 결국 모호해지게 된다.

🔑 keyword - '격벽'

처음에 '격벽' 이라는 단어가 무척 낯설었다.
무슨의미인지 잘 와닿지 않았다.

격벽이란

• 개념들의 벽을 만들어서 그룹화 와 조금 다르게 경계를 만드는 것.
• 개념들간의 격벽을 통해 허물어지지 않는 경계를 쌓는 것.

격벽에 대한 이해도를 조금 더 높이기 위해 적절한 예를 들자면, '방화벽' 같은 친구라고 생각하면 된다.

격벽과 방화벽

• 방화벽은 허용한 요청만 받아들이도록 하는 녀석이다.
• 허용하지 않은 요청은 튕겨낸다.
• 즉, 접근에 대한 제어와 통제를 하는 것을 말한다. 🙅🏻

이와 같은 방화벽처럼 개념들간의 벽을 세워야 한다.
위의 사진을 보면, 격벽을 통해 개념들을 제어하고 통제한다.

예를 들어, '연재' 라는 개념만이 격벽을 넘어 '작품' 에게 닿을 수 있다.

즉, 개념들이 아무렇게나 마구 접근하는 것이 아니라, 격벽을 근거로 제어하고 통제가 될 수 있다.
격벽을 넘어갈 수 있는 개념을 통제해서, 제한을 해야한다.

🧐 어? 이거 설계 아님?

개념과 격벽이라는 내용을 통해 위에 나열된 것을 보면 사실상 우리가 말하는 '설계' 라고 생각이 들 수 있다.
위와 같은 내용은 설계와 같이 보이지만, 사실 이것은 '구현'이다.

왜냐하면 위의 내용은 실제로 코드로 만들어져 있기 때문이다.
아래에서 더 코드로 알아보잣!

코드로 개념과 격벽을 느껴보기

'개념' 과 '격벽' 을 통해 내 코드가 잘 만들어져 있는지 알기 위해서는 어떻게 해야할까?
아주 간단하게는 '코드를 수정하는 것' 으로 확인할 수 있다.

격벽이 제대로 되어있지 않으면, 수정되어야 할 범위가 넓어지기 때문이다.

코드를 수정하게 되면..?

• 개념이 격벽을 통해 제대로 잘 세워진 경우 : 수정되어야 할 범위가 국소적이다.
• 잘 세워지지 않은 경우 : 수정할 곳이 엉뚱한 곳에 생기게 된다.

즉, 제어와 통제가 잘 되어야 한다.
변경범위가 격벽을 통해 세워 놓은 한계만큼만 수정되어야 한다.

격벽이 제대로 되어있지 않으면 클래스를 하나 변경했을 뿐인데 위와 같이 갑자기 수정할 곳이 마구 생기게 된다.

🍇 사례를 통해 개념과 격벽 느껴보기

사례1 - 대출 서비스

큰 개념을 작게 만들기

이 사례에서 처음에는 대출을 하나의 개념으로 보고, '신청' '실행' '상환' 세가지를 행위로 보았다.
이렇게 생각하고 서비스를 구현해보니, '대출' 이라는 개념이 너무 커보였다.

개념을 크게 잡으면 변경지점이 넓어지게 된다.
즉, 대출이라는 개념에 너무 많은 것들이 의존하게 된다.

그래서 '대출' 이라는 개념을 작게 만들어보았다.

큰 개념을 작게 변경하고 보니, 위와 같은 플로우가 서비스에 그려지게 되었다.

대출 서비스의 플로우
1. 대출을 '신청' 한다.
2. 신청이 완료되면 대출이 '실행' 된다.
3. 실제 '대출' 이 일어나게 된다.
4. 이제부터 '상환' 을 해야한다.

개념 쪼개기

서비스 개발을 하다보니 '상환' 도 분리가 필요해 보였다.
'상환 성공' 과 '상환 실패' 두가지의 개념으로 분리가 되었다.
그런데 또, 이러다 보니 '상환 실패' 역시 분리가 필요했다.
계속 이런 식으로 요구사항이 늘어나서 계속 커지고 불어 나는 상황이 오게 되었다.

뭔가 이상하다..! 🙃

격벽 세우기

이럴때는 '격벽'을 세워보자.

상환을 성공하는 것과 실패하는 것을 두고 격벽을 세워 보니, '연체' 라는 새로운 개념이 나오게 되었다.

상환 재시도, 추가 이자 에 대한 것은 '연체' 라는 새로운 개념과 함께 하는 개념이 되었다.
이 처럼 개념들의 관계를 격벽을 통해 분리시키는 것이 중요하다.

대출 서비스 사례로 알아본 개념과 격벽 정리

• 1.하나의 개념이 많이 쓰이면 분리를 검토하자.
  대출 이라는 개념이 너무 컸기때문에, 그 개념을 분리 했던 것이다.
  개념을 분리하고나면 흐름이 다른 관점으로 보일 수 있다.
• 2.상태에 의해 개념이 생기면 격벽을 세워보자
  개념을 끊어보기 위해 격벽을 세워서 다시 확인 해보자.
• 3.상태나 행위를 개념으로 착각할 수 있다.
  다만, 착각인지 아닌지 면밀히 살펴 봐야 한다.

🧥 사례 2 - 커머스 서비스

커머스 서비스에서는 '외부 연동' 사례에 대해 어떻게 '개념' 과 '격벽' 을 활용할 수 있는지 보여준다.

대부분의 커머스 서비스는 많은 '외부 연동사'를 사용한다.
이런 외부의 녀석들을 다룰 때 어떻게 해야할까?

• 이렇게 하나의 도메인에 다 때려박는건...좀...

모듈로 분리시켜볼까?
외부 연동사를 따로 모아놓는 모듈을 만들고 분리하는 것도 좋은 방법이다.
실제로, 이렇게 구현하는 곳도 많다.

개념에도 계층이 존재한다.

• 개념도 계층이 나뉘게 된다.
  즉, 개념에도 중요한 개념, 중요하지 않은 개념등으로 나뉘게 된다.
  이러한 계층을 나누기 위해서는 개념에 대한 분석이 필요하고, 이것에 대한 개념의 계층을 잘 나눠야 한다.
  즉, 비지니스 로직을 지탱하는 개념에 대한 분석이 매우 중요하다.
• 그러면 외부 연동사는 어디에 있어야 할까?
  외부 연동사는 개념의 영역이 아니다.
  왜? 말 그대로 '외부' 이고, 내가 만든 어플리케이션의 비지니스 로직에 관여하는 개념이면 안된다.
  개념이 없어야 할 외부가 내부로 침투하며 안된다.

참조 불가의 벽

• '참조 불가의 벽'
  즉 외부 연동사와 같은 영역이 분리 된 곳에서는 침투할 수 없는 벽을 세워야 한다.
  DB 와 같은 것을 통해 가지고 오는 형태가 되어야 한다.
  별도 모듈로 분리하여 참조 불가하도록 해야 한다.

커머스 서비스를 통해 배운 개념과 개념의 계층

• 계층이 자연스럽게 생긴다. 모두 같은 수준의 계층이 아니다.
• 내가 만드는 프로그램에도 개념의 게층이 있다
  모든것이 개념이 되지는 않는다.
• 핵심 개념이 되는 것들이 무엇인지 확인해야하고 점검해야한다.
  개념 영역을 분리할 수있다.
• 외부, 내부의 영역을 분리 해야한다.

🛠️ 다시 설계를 논해볼까?

🤖 하드웨어의 설계 변경

하드웨어는 설계가 변경이 가능할까?
물론..!! 하드웨어도 설계가 변경이 가능하다.

하지만..

겁.나 어.렵.다.

위의 사진을 자세히 보면 모듈과 모듈 사이에 초록색으로 납뗌한 것을 볼 수 있다.
처음 한개는 그래도 할만하겠지만, 지속적으로 설계를 바꾸기 위해 계속 납똄하고 붙이고.. 할 수 있을까?

하드웨어의 설계 변경은 어렵다.
불가능 하지는 않지만 많은 시간과 비용이 소요된다.

🏰 롯데타워의 설계

롯데타워의 설계가 변경된다고 생각해보자.

가령 이런 것이다.

👩🏻‍🚒 : 10cm 만 옮겨주세요 !!

이런 설계변경이 가능한가? ㅋㅋ..

뭐, 할 수야 있겠지만..

무너뜨리고 다시 지어야 한다.

롯데타워의 설계가 변경되는 것은 끔찍한 일이다.

👨🏻‍💻 소프트웨어의 설계 변경

그럼, 우리가 만드는 것은 무엇인가?
우리는 소프트웨어 Software 를 만든다.

Soft = Not Hard

소프트웨어는 딱딱하지 않고 부드러워야 한다.
소프트웨어의 장점은, 설계가 유연하고 변경이 가능하다는 점이다.

소프트웨어를 개발하는 개발자가 꼭 기억해야 할 것

1. 인정하자
   1. 요구사항은 계속 변한다. (요구사항은 변한다는 사실만 변하지 않는다.)
   2. 완벽한 설계란 없다. 완벽한 설계라는 건 죽어가는 소프트웨어에서만 가능하다.
   3. 소프트웨어는 소프트 해야한다.
2. 하지말자
   1. 요구사항이 완벽해야 설계 가능해요. 라고 말하지 말자
   2. 우리 설계에서 그건 개발 못해요. 라고 하지 말자. 소프트웨어는 설계가 변경 가능하다. 설계를 잘못해놓고 하는 말일 가능성이 크다.
   3. 설계를 해봐야 개발 일정이 나옵니다. 라고 하지 말자. 우리는 소프트웨어를 만드는 사람들이다. 롯데타워를 만드는 사람이 아니다.
3. 상기하자
   1. 성급한 설계는 모든 것을 망가트린다. 설계를 한 이상, 변경에 취약해진다.
   2. 과도한 설계는 모든 것을 망가트린다. 너무 멀리까지 보고 설계를 하면 망가진다. 코드로 예술을 하면 안된다
   3. 설계는 필요한 만큼만 하자. 필요한 만큼의 설계만 해야한다는 점을 항상 기억하자.

설계를 잘하는 방법이 뭐라고?

개념과 격벽을 사용해서 증명하고, 피드백 하면서 계속 구현을 하자.
테스트 코드를 통해 계속 구현을 피드백 받고 반복하다보면 설계가 나오게 된다.

🙏🏻 개인 소감

너무 재밌었다.
예시를 통해 너무나 와닿는 이야기를 해주셨다.
그래, 나는 소프트웨어를 만드는 사람이다.

완벽한 설계가 없으므로, 설게는 계속 유연하게 변할 수 있다.