개발자 커뮤니티, F-lab 데브클럽 "오늘도 한 페이지" 북 멘토링 후기

 

안녕하세요~ 개발자 멍구입니다!

최근 몇 달 동안 F-lab의 데브클럽에 참여하고 있는데요. 이곳은 개발자의 성장을 돕는 다양한 프로그램을 운영하는 커뮤니티입니다.

다양한 기회가 많지만, 이런저런 핑계를 대며 활발하게 참여하지 못했어요. 🥲

 

 

그러던 중에 이번 주말, 카페에서 열린 "오늘도 한 페이지" 북 멘토링 프로그램에 잠깐 참여해봤습니다.

이 프로그램은 매주 특정 IT 서적의 일부를 읽고, 멘토님과 함께 내용을 정리하며 의견을 나누는 방식으로 진행됩니다.

 

 

---

"오늘도 한 페이지" 프로그램, 어떤 점이 좋았을까?

이 프로그램의 가장 큰 장점은 혼자 읽기 어려운 IT 서적을 멘토님의 설명과 함께 쉽게 이해할 수 있다는 점이었어요. 특히, 궁금한 점을 자유롭게 질문하고 다양한 피드백을 받을 수 있다는 것이 큰 메리트였습니다.

이번 세션에서는 "논리적 아키텍처 만들기" 라는 주제를 다뤘어요. 서비스 초기 설계 단계에서 중요한 컴포넌트 식별, 도메인 분리, 역할 및 책임 정의 등 개발자라면 한 번쯤 고민해봐야 할 핵심 개념들을 배울 수 있었어요. 들었던 내용 보면서 공부 겸 메모해본 내용도 적어봐요!

 

 

---

논리적 아키텍처 만들기

1. 초기 컴포넌트 식별

Work Flow 접근법

• 서비스의 전체 흐름을 도식화하고, 각 단계에서 필요한 기능을 정리한다.
• 예시: Survey Domain / Customer Domain / Ticketing Domain 등으로 도메인을 나눌 수 있음.
• 티켓 생성 → 할당 및 라우팅 → 고객 알림 → 티켓 완료 → 설문조사 전달 등의 과정 식별.

2. 요구사항을 컴포넌트에 할당

• 각 기능을 담당할 컴포넌트를 나누고, 역할을 명확하게 설정.
• 책임이 과중한 컴포넌트가 있다면, 분리해서 최적화.

3. 역할 및 책임 분석

• 역할 분리를 통해 각 컴포넌트가 독립적으로 작동할 수 있도록 설계.
• 유저 스토리를 컴포넌트에 할당 → 역할 및 책임 분석 → 아키텍처 특성 분석 → 리팩토링 진행.

4. 이벤트 스토밍

• 필요한 이벤트들을 포스트잇에 작성해 화이트보드에 붙여가며 전체 구조를 시각화하는 방법.

5. 안티 패턴 피하기

• CustomerManager, ItemManager, OrderManager 등 지나치게 포괄적인 네이밍을 피해야 한다.
• 예: OrderManager가 주문만 처리하는 줄 알았는데, 환불, 배송까지 담당하고 있다면 역할이 모호해질 수 있음.

 

 

 

---

마무리하며

이번 북 멘토링 세션을 통해 혼자서는 이해하기 어려웠던 내용을 쉽게 배울 수 있었어요.

IT 서적을 읽는 게 부담스럽거나, 아키텍처 설계에 대한 인사이트를 얻고 싶은 분들에게 강력 추천하는 프로그램입니다!

F-lab 데브클럽에는 이외에도 다양한 성장 기회가 많으니, 관심 있는 분들은 한 번 참여해보시는 것도 좋을 것 같아요. 😉

지금까지 개발자 커뮤니티, F-lab 데브클럽 "오늘도 한 페이지" 북 멘토링 후기를 짧게 적어봤어요. 그럼, 즐거운 주말 보내세요!