좋은 설계를 시작하면서

---

Scratch

 

좋은 설계 카테고리의 시작은 Swagger API를 이용해 인증 & 인가 서비스를 만드는 것에서 출발했다.

아래는 나름 Swagger 결과 데이터를 분석해 만든 다이어그램이다.

먼저 한 일은 Swagger 결과 데이터를 타입스크립트 기반으로 파싱하는 일이었는데, 결과는 뻔하지만 좋았다.

구조적으로 잘 분리했기 때문에 테스트 코드나 케이스를 만드는 것도 어렵지 않았다.

여기서 느꼈던 점은

좋은 설계는 쉽고 정확하게 코드를 작성하게 해준다.

 

 

 

 

 

사실 위와 같은 구조를 만드는 것도 어렵지 않았다. 실제 팩트(fact)를 보면서 만들었기 때문이다.

이런 관점에서 본다면 빠져나갈 예외 케이스도 없었다. 만족할 만한 구조가 나온 것이다.

두 번째로 느낀점은

좋은 설계는 실제 현상을 기반으로 만든다.

 

 

 

 

역시 문제는 응용에 있었다.

Path만을 놓고 보자면 GET, POST와 같은 메소드(method)가 있고, /api/hello 같은 주소가 있다.

하지만 인증 & 인가 서비스를 구현하려면 어디 서버로부터 나온 건지나

어떤 역할(role)을 가지고 있는 지에 대한 정보가 필요했기 때문이다.

 

결국 저 구조체 자체에 이것저것 붙여야 하나보니

나중에 이런 저런게 필요해지면 어떻게 해야될 지 걱정이 앞섰다.

그래서 내가 좋아하는 원칙 하나를 세웠다.

좋은 설계는 변경에 닫혀있고 확장에는 열려있어야 한다.

 

 

 

 

다시 한 번 곰곰히 생각해보니... 뭔가 어색했다.

분명 확장에 걱정은 없는 건 맞는데, 한 가지 사고 실험이 길을 막았다.

SUV 한 대를 산다고 해보자.
당연하게도 장보러 가거나, 누군가를 픽업하고 어디를 이동할 때 사용할 수 있다.
하지만 뒷 자리부터 평탄화 작업을 하고 캠핑 장비로 튜닝한다면 캠핑용으로 만들 수 있다.
뒷 자리부터 다 떼고 많은 짐을 실어서 나르는 짐차 용도로 사용할 수도 있으리라.
극단적인 예시지만 뒤에 고리를 설치해서 밭 가는 기구를 결합하면 농사에도 쓸 수 있지 않을까.

 

지금까지는 저 개방-폐쇄 원칙이 범용성과 직결되어 있다고 생각했다.

Swagger에 어떤 것을 붙여도 되는 범용적인 도구라면 충분히 가능한 이야기이다.

 

그러나 오롯이 캠핑 목적이라면 SUV가 아닌 캠핑카를 사는 게 더 좋다.

짐차 용도라면 트럭을 사고, 농사에 쓰려면 트랙터를 사는 게 맞다.

여태 필자가 Swagger를 사용하는 이유를 인증 & 인가 목적이 아닌 API를 표현하는 것으로 설명하고 있었다.

SUV에 캠핑 용품을 붙여봤자 캠핑할 때는 캠핑카가 훨씬 낫다.

 

좋은 설계는 목적을 충실히 반영해야 한다.

 

 

 

 

이제 찾아야 할 마지막 숙제는 핵심적이고, 변하지 않는 걸 찾는 것이다.

SUV든 캠핑카든 트럭이든 모두가 가진 공통점 중 대표적인 건 파워트레인이라고 생각한다.

세세하게 따질 건 아니고, 쉽게 생각하면 트럭에 있는 엔진을 떼서 캠핑카에 꽂든 역할이 다를까 싶은 것이다.

Path로 따지면 메소드와 주소는 어떤 서비스를 하든 핵심적으로 변하지 않지만,

태그나 함수명은 부가적으로 사용하지 않거나 충분히 입맛따라 바뀔 수 있는 요소이다.

좋은 설계는 근본을 찾는 것부터 시작한다.

 

 

 

 

 

---

Principle

 

지금까지 이야기 했던 것을 정리하면

좋은 설계는

1. 쉽고 정확하게 코드를 작성하게 해준다.
2. 실제 현상을 기반으로 만든다.
3. 변경에 닫혀있고 확장에는 열려있어야 한다.
4. 목적을 충실히 반영해야 한다.
5. 근본을 찾는 것부터 시작한다.

이다.

 

하지만 뭐, 사실 왕도는 없다고 생각한다.

앞으로 더 좋은 게 있으면 수정 발전해나갈 생각이다.