[객체지향 시스템 디자인 원칙] 내 생각 Q&A - 7장. 모듈화 달성하기

목차

 

  이 글은 ['객체지향 시스템 디자인 원칙'을 읽으며 정리한 내 생각 - LLM과의 Q&A 기반 사고 확장] 글을 챕터별로 나눈 시리즈 중 하나 입니다. 전체 흐름을 보고 싶거나, 다른 챕터를 확인하고 싶으시다면 위 통합글을 참고해주세요.

 

  이 글은 책 내용을 요약하거나 정리한 글이 아닙니다. 책을 읽고 난 뒤 제 생각을 중심으로 정리한 글 입니다. '객체지향 시스템 디자인 원칙'을 읽으며, 느낀점이나 좋았던 점 및 책에 제시된 연습문제를 LLM에게 알려줬습니다. 이를 바탕으로 제 생각을 기반으로 책의 연습문제를 변형하거나, 새로운 질문을 생성하게 했습니다. 그 후 제가 그 질문에 답하고, LLM과 토론하는 방식을 사용해 사고를 확장해봤습니다. 이 글은 그 질문과 답변을 모아둔 글 입니다. 자세한 작성 배경은 통합글에서 확인하실 수 있습니다.

 

※ Q1, Q2와 같은 질문 외의 모든 답변은 LLM을 쓰지 않고 제가 직접 답변한 내용입니다. 이후 LLM과 토론하며 생각이 조금씩 바뀐 부분들도 있으나, 최대한 초안 답변으로 올렸습니다.

※ 제 생각을 적은 것으로, 일반적인 개발자들의 생각이나 사실과 다소 다를 수 있습니다.

 

 

---

 

7장. 모듈화 달성하기

Q1. "깊이 있는 모듈"이란 무엇이었나?

배경:

책에서는 "깊이 있는 모듈이란 적은 인터페이스로 많은 작업을 수행하는 모듈"이라고 정의하고, 관련 기능을 내부로 숨겨서 모듈을 안정적으로 유지하는 걸 강조했어.

질문:

• 지금까지 만들어본 모듈(또는 클래스) 중에서 *‘이건 진짜 깊이 있었지’*라고 느꼈던 경험이 있을까?
• 반대로, *‘겉보기만 번듯하고 깊이는 얕았던 모듈’*이 있다면 그 예시는?
• 어떤 기준으로 ‘인터페이스를 줄이고 내부 복잡도는 감추자’는 결정을 내렸는지도 궁금해.

 

내 답변

  최근 프로젝트에서 토큰 발급 받는 부분이 꽤 잘만들었다고 생각해. 단순히 id,pw로 인증할 수 없는 요구사항을 가진 서비스야. 기본적으로 본인인증이 필요해. 이 때, 현재 고객이 접속한 환경에 따라 다른 인증 방식을 쓸 수 있어야 했어. 근데 난 이걸 프론트엔드에서 판단해서 인증 방식을 선택하게 하고 싶지 않았던거야. 인증에 대한 내부 구현을 외부에서 최대한 모르게 하고 싶었던거지. 물론 프론트엔드도 회사입장에선 내부지만, 아무튼 외부망에 언제나 열려있으니까. 또한 발급된 토큰은 이후 프론트엔드에서 고객이 행하는 모든 동작에 대해 백엔드로 들어올꺼야. 이 때, 인증 방식에 따른 차이를 백엔드 메인 로직에서 신경쓰게 하고 싶지 않았어. 그래서 이것들을 모두 래핑한 하나의 토큰 발급 API를 만들어뒀어.

 

  실제로 프론트엔드에서 주는 정보는 하위 이용기관 구분값이랑 현재 고객의 접속환경 정도 뿐이야. 이걸보고 백엔드에서 어떤 인증방식을 사용할지 판단하고, 필요하다면 프론트를 리다이렉트 시켜서 처리해. 그리고 추가로 고객의 역할도 나뉘는데, 일단 본인 인증은 기본적으로 필요해. 그리고 추가로 하위 이용기관을 등록을 할 수 있어. 그러니 본인인증은 서비스를 진입하기 위한 필요조건인거고, 본인인증만 통과한 경우엔 익명인 셈이고, 1개 이상 등록했을 시엔 고객의 하위 이용기관 특정이 가능한 구조야. 또, 하위 기관 특정 됬을 시 이 고객이 유효한 고객인지도 확인하지. 이에 따라 발급되는 토큰도 달라져. 이런 부분까지 래핑해서 최종적으로 프론트로 그냥 토큰만 가는거야.

 

  프론트엔드쪽에선 그냥 토큰달라고 해서 준거라 생각되겠지만, 실제론 분리된 코드들 다 합쳐보면 천 줄은 가볍게 넘을꺼야. 어찌보면 너무 책임이 많기도 한데, 어쨌든 이걸 통해 이후 백엔드의 모든 메인 로직 설계가 엄청 간편해졌고, 프론트는 뭐 보다시피 엄청 간단하지. 그냥 토큰 발급받고 그거 다른 API 호출할때마다 넣어주면 끝임 ㅋㅋ. 적절한 트레이드오프였다고 생각해.

 

  겉보기만 번듯하고 깊이는 얕았던 모듈이라면, 주로 외부 API를 bypass한 경우야. 사실상 인프라에 대한 책임만 지는 단순 바이패스 API인거지. 역할은 그저 외부와 내부 사이의 DMZ 영역 정도의 역할이야.

 

  어떤 기준으로 인터페이스를 줄이고 내부 복잡도를 감추자는 결정을 내렸는지는 사실 내 관점은 코드 내의 객체들의 협력이나, 외부와의 협력이나 동일하게 생각해. 단일 모듈 코드짤 때 생각한 방식 그대로 멀티 모듈에 대해서도 생각해. 보통 초기 개발할 때 코드개발보다는 전체적인 구조먼저 잡고 가는편이라, 최대한 ‘간단하게’, ‘이걸보고 누가 질문을 최대한 안하게’가 목표야. 간단하면 “아 이것만 보내면 되요? ㅇㅋㅇㅋ” 이걸로 끝나거든.

 

 

Q2. 세영이 생각하는 "모듈의 인터페이스 명세"는 어떤 구조여야 할까?

배경:

7.2는 모듈의 인터페이스를 단순하고 깔끔하게 유지해야 한다는 이야기였어.

특히 하위 호환성과 확장성, 소유권, 참여 규칙 등이 강조됐지.

질문:

• 지금까지 만든 모듈에서, 외부에 노출한 인터페이스를 설계할 때 어떤 기준을 갖고 설계해?
• 예를 들어 Service, Facade, Controller, UseCase 등에서 "이건 외부에 노출해도 되고, 이건 숨겨야 한다"고 나누는 기준이 있어?
• 또 "확장 지점을 어떻게 제공할 것인가"에 대해서 명시적으로 고민해본 적 있다면 그 예시도 궁금해.

 

내 답변

  난 백엔드 개발을 위주로 하고 있어. 그리고 일부 네트워크나 DB 등 인프라에 대한 고려도 내 몫인 경우가 있어. 내 경우 기본적으로 외부의 요청을 최대한 믿지 않아. 예를들어 프론트엔드에서 주는 데이터는 언제든 변조될 수 있다고 생각해.

 

  이런 관점에서 내 기준은 간단한데, 내가 처리할 수 있는 복잡한건 모두 내가 처리하고, 외부에 노출은 최소한만 한다는 기준이야. 이건 단일 모듈 내의 객체 설계시나, 외부 모듈과의 API 설계 시 모두 고려하는 점이야. 다만 좀 더 외부를 간단하게 만드는데 집중하긴 해. 내부의 복잡함은 우리쪽에서 처리하더라도, 내부에서의 문의는 사실 처리하기 쉽잖아. 반면에 외부로 노출된 API 에 대해서는 우리쪽 업무를 잘 모르는 사람도 쓸 수 있으니까. 최대한 간단하게 하는게 문의를 덜받는 방법인 것 같아.

 

  너가 예시로 든 기준으로는 API 관점에서는 Controller만 노출해. 그리고 라이브러리 관점에서는 facade만 노출해. 그 외에는 노출을 최대한 꺼리는편이야.

 

  확장 지점은 사실 불필요한걸 많이 두는건 그렇 게 좋아하지 않아. 예를들어 막 비고1, 비고2, 비고3, … 이런식의 확장지점은 안이쁘다고 생각해. 다만 설계시 초기엔 필요없지만, 이건 확장될만한데? 싶은건 미리 추가해두기도 해. 이 경우 문서상 ‘확장 대비’ 이런식으로 미리 적어두는편이야. 또 현재는 단일 값으로 받더라도 이후 N개로 늘어날만하다 하다면 미리 Array 형태로 구성해두는 이런식이야. 이 경우에도 현재는 1개이나, 이후 확장 가능하다는 식으로 적어두는 편이야. 사실 정말 큰 변경이 있다면 버전 방식의 API로도 괜찮다고 보거든.

 

 

Q3. 이벤트 기반 모듈 분리나 알림 시스템과 관련한 너의 경험

배경:

7.3.5~7.3.6에서는 이벤트 기반 분리와 알림 시스템 예제가 나왔어.

세영도 이벤트 기반 아키텍처 과제 경험이 있다고 했지.

질문:

• 지금까지 만든 이벤트 기반 시스템 중에서 "이건 설계 잘했다" 싶은 구조가 있었어?
• 이벤트 도입할 때 가장 힘들었던 점이나, 반대로 "이건 도입하길 잘했다"고 느낀 순간은?

 

내 답변

  대학교 때 상황인지에 대한 국가 프로젝트에 참여한 적 있어. 10개 이상의 대학교와 여러 업체가 공동으로 진행한 프로젝트였어. 이 때 내가 맡은 역할은 안드로이드 기반 환경에서, 각 대학교 및 업체가 만든 컴포넌트 앱들이 이벤트 기반으로 동작할 수 있도록 프레임워크를 만드는거였어. 그리고 일부 데이터 수집 모듈도 여기에 포함되어 있었어.

 

  컴포넌트들은 프레임워크 내에서, 데이터를 수집하는 컴포넌트앱도 있고 그걸 사용해 다양한 상황인지를 수행하는 모듈이 있고, 그걸 사용자에게 보여주는 모듈도 있었어. 각 기관이 독립적으로 만들 수 있도록 각자 별도의 앱을 만들었었어. 즉, MSA 구조라고 보면 되겠네. 이 때 서로간의 컴포넌트를 정확히 모르더라도, 그냥 원하는 수집 데이터를 구독하면 받을 수 있도록 설계했었어.

 

  가장 힘들었던점은 사실 당시 교수님이 좀 완벽주의자셔서, 기간 얼마 안남아도 더 좋은 구조가 생각나면 무조건 갈아엎으셨어. 그리고 교수님은 절대 코딩에 손대지 않으셨어. 물론 코딩 엄청 잘하시는분인데도 토론만 딱 하고 가심. 교육상 그러시는건 알지만 힘들긴 했지. 솔직히 말하면 현재 회사에서 일하면서도, 힘듬 최대치로 보면 아직 대학교때가 더 빡쌨던거같아. 결론적으로, 모든 코드를 하나로 붙여보면 10만줄은 가뿐히 넘는 프레임워크 앱이 만들어졌고, 별 문제없이 잘 동작했어. 아 추가로 여러 대학교나 기업들이 참여하고, 내가 학년이 낮다보니.. 아무래도 당시 요구사항이 들어올 때 그걸 내가 잘 쉴드치지 못한점도 좀 힘들었네.