[Rookies 개발 4기][멘토링]3차 멘토링

Seolhxx·2025년 12월 1일

SK 쉴더스

목록 보기

21/47

✈️ 2025.11.29 ✈️

분산 시스템의 엔지니어링 표준 수립: 애자일 거버넌스와 클라우드 네이티브 아키텍처

마이크로서비스 아키텍처(MSA)를 지향하는 프로젝트에서 아키텍처 다이어그램과 코드 컨벤션은 팀의 기술적 철학을 대변하는 명세서와 같다. 본 리포트에서는 3차 멘토링을 통해 지적된 설계적 결함과 운영상의 미비점을 분석하고, 이를 보완하기 위해 수립된 엔지니어링 표준을 기술한다.

1. 프로젝트 관리 체계: 데이터 기반의 애자일 프로세스

애자일 방법론의 핵심은 '속도(Speed)'가 아니라 '지속 가능성(Sustainability)'과 '예측 가능성(Predictability)'에 있다. 멘토링을 통해 확립된 칸반 및 스프린트 운영 원칙은 다음과 같다.

1.1 계층적 백로그 관리 (Epic - Story - Task)

단순 업무 나열에서 벗어나, 비즈니스 가치 중심의 계층 구조를 확립했다.

User Story: "사용자로서 ~를 하고 싶다"는 관점에서 비즈니스 요구사항을 정의하고 이를 중/대분류인 Epic으로 관리한다.
Sub-Task: 각 스토리는 백엔드 개발, 프론트엔드 연동, DB 설계 등 원자적 단위의 하위 작업으로 세분화하여 진행 상황을 가시화한다.
Story Point: 피보나치 수열(1, 2, 3, 5, 8...)을 기반으로 작업 난이도를 산정하며, 이는 팀의 벨로시티(Velocity)를 측정하는 정량적 지표가 된다.

1.2 스프린트 운영 및 번다운 차트(Burn-down Chart) 활용

스프린트 내 미완료 작업 발생 시 주말 근무를 투입하는 것은 팀의 벨로시티를 왜곡하는 행위이다. 미완료 백로그는 하위 작업으로 재분할하여 다음 스프린트로 이관하며, 이를 통해 팀의 실제 구현 역량을 파악하고 스프린트 계획의 정확도를 높인다.

2. 애플리케이션 아키텍처: 레이어드 구조와 객체 책임의 엄격화

시스템의 유지보수성을 결정하는 것은 코드 간의 응집도와 결합도이다. 멘토링 피드백을 반영하여 레이어드 아키텍처(Layered Architecture)의 표준을 재정의했다.

2.1 DTO와 엔티티의 책임 분리

Service Layer의 순수성: 서비스는 UI 전송 모델인 DTO의 구조를 인지하지 않아야 한다. 서비스는 오직 비즈니스 도메인 모델인 엔티티의 속성만 알면 되며, DTO와 엔티티 간의 변환 로직이 서비스 레이어를 침범하지 않도록 설계 표준을 수립했다.
명명 규칙(Naming Convention): CRUD 기능은 심플하게 명명하되, 복잡한 비즈니스 로직이 포함된 기능은 축약 없이 명확한 명사/동사 조합(예: calculate_discounted_price)을 사용하여 가독성을 확보한다.

2.2 REST API 성숙도 모델의 준수

API 엔드포인트 설계 시 동사 사용을 전면 배제하고 리소스 중심의 명사 설계를 원칙으로 한다. 이는 REST 성숙도 모델을 준수하여 API의 자기 서술성(Self-descriptiveness)을 높이고 서비스 간 연동의 복잡도를 낮추기 위함이다.

3. 인프라 아키텍처: 네트워크 흐름과 가용성 설계

인프라 설계의 핵심은 보안(Security)과 가용성(Availability)의 균형이다. AWS 환경에서의 네트워크 흐름을 공학적으로 재설계했다.

3.1 네트워크 계층 및 트래픽 경로

VPC 및 Subnet 배치: 공용망(Public Subnet)과 사설망(Private Subnet)을 엄격히 구분한다. 외부 유입 트래픽은 인터넷 게이트웨이(IGW)를 거쳐 Application Load Balancer(ALB)로 전달되며, 내부 서비스는 Private Subnet 내의 노드 그룹에 배치한다.
NAT Gateway의 배치: Private Subnet 내의 리소스가 외부 API(예: OpenAI)와 통신하기 위한 아웃바운드 경로는 NAT Gateway를 통해 Public Subnet으로 나가는 구조로 일원화한다.
EKS 운영 표준: Kubernetes 환경에서 ConfigMap과 Secret을 활용하여 환경 변수를 관리하며, 배포의 투명성을 위해 ArgoCD 기반의 GitOps 파이프라인을 구축한다.

4. 분산 시스템 통신 전략: 결합도 제어 (Sync vs Async)

MSA 환경에서 모든 통신을 동기(Sync) 방식으로 처리할 경우 장애 전파(Cascading Failure)의 위험이 비대해진다. 이에 따라 도메인 간 결합도를 제어하기 위한 통신 전략을 수립했다.

4.1 동기 통신 (Feign Client)

사용자 유효성 검증이나 결제 승인과 같이 즉각적인 응답이 필수적인 비즈니스 트랜잭션에 한하여 사용한다. 이 경우 타 서비스의 장애가 현재 서비스로 전파되지 않도록 서킷 브레이커(Circuit Breaker) 도입을 검토한다.

4.2 비동기 통신 (Kafka)

이벤트 기반 아키텍처(EDA)를 도입하여 도메인 간의 강결합을 해소한다.

Case: 피드 작성 시 알림 발송, 로그 수집, 통계 데이터 갱신 등.
Advantage: 프로듀서(Producer)는 메시지 큐에 이벤트를 발행한 후 즉시 응답을 반환할 수 있어 사용자 응답 시간을 단축하며, 컨슈머(Consumer) 측의 장애가 상위 서비스에 영향을 주지 않는다.

모든 통신 방식의 결정 근거는 ADR(Architecture Decision Record) 문서를 통해 기록하며, 이는 팀의 기술적 부채를 관리하는 핵심 자산이 된다.

5. 로드맵 및 향후 과제

ERD 및 엔티티 매핑: 객체지향 모델과 RDB 테이블 간의 차이를 인식하고, MSA별 독립적 DTO 소유를 통해 도메인 간 데이터 간섭을 차단한다.
AI 아키텍처 고도화: RAG(Retrieval-Augmented Generation) 아키텍처를 통해 펫 페르소나 챗봇의 정확도를 높이고, 정적/동적 다이어그램(Class/Sequence Diagram)을 통해 AI 로직의 복잡도를 관리한다.

회고

이번 3차 멘토링에 처음으로 직접 참여하며 실무 엔지니어링의 방대한 깊이를 체감했고, 그간의 불참이 너무 아쉬움으로 남을 만큼 값진 인사이트를 얻었습니다. 주말 근무가 아닌 팀의 실제 속도를 측정하여 지속 가능한 개발을 지향해야 한다는 애자일의 본질과, 패킷의 이동 경로를 논리적으로 증명해야 하는 인프라 설계의 엄격함을 배웠습니다.

또한 레이어 간 응집도를 위한 DTO 분리 원칙과 비즈니스 맥락에 따른 동기·비동기 통신 전략을 ADR로 기록하는 실무적 태도의 중요성을 깊이 숙지했습니다.

설계의 모든 선택지에 명확한 공학적 근거를 담아야 한다는 가르침을 이정표 삼아, 12월 20일 통합 시연까지 단순 구현을 넘어선 견고한 아키텍처를 완성하겠습니다. 결국 좋은 엔지니어란 기술을 나열하기보다 구조를 고민하고 자신의 설계를 당당히 표현할 줄 아는 사람임을 깨달은 소중한 시간이었습니다.