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

Seolhxx·2025년 11월 17일

SK 쉴더스

목록 보기
11/47

💚 2025.11.15 💚

🌈 이벤트스토밍


도메인 복잡성 해소와 MSA 정합성을 위한 아키텍처 설계 및 구현 전략: Petlog 프로젝트를 중심으로

마이크로서비스 아키텍처(MSA)를 도입한다는 것은 단순히 시스템을 분할하는 행위를 넘어, 비즈니스 도메인의 본질적인 문제를 공학적으로 격리하고 해결하는 과정이다. 본 보고서에서는 SK쉴더스 루키즈 4기 과정 중 진행된 두 차례의 멘토링 인사이트와 이를 실제 서비스(Petlog)에 투영하기 위해 수행한 기술적 의사결정 과정을 상세히 기술한다.

1. 아키텍처 수립의 전제 조건: 문제 중심의 설계 (Problem-Centric Design)

멘토링을 통해 수립된 최우선 원칙은 '기술적 도구에 앞선 문제의 정의'였다. 아키텍처 설계 시 흔히 발생하는 오류인 '기술을 위한 기술 도입'을 경계하고, 해결하고자 하는 비즈니스 요구사항에 집중하는 공학적 접근법을 채택했다.

1.1 요구사항 명세의 재정의: What vs How

기존 요구사항 명세서의 문제점은 개발자의 관점에서 구현 방식(How)인 UI 레이아웃이나 특정 기술 스택이 혼재되어 있다는 점이었다. 이를 고객 관점의 기능적 요구사항(What)으로 정제하는 과정을 거쳤다.

  • 추상화: '로그인 페이지'와 같은 화면 중심의 서술을 '회원 식별 및 인증'이라는 도메인 중심 언어로 재편성했다.

  • 도메인 분리: 목적어 중심의 기능 분류를 통해 시스템의 핵심(Core)과 지원(Support) 도메인을 식별하고, 비즈니스 우선순위를 수립했다.

2. 도메인 모델링: 이벤트 스토밍(Event Storming)을 통한 경계 확정

마이크로서비스의 물리적 경계를 획정하기 위해 '이벤트 스토밍' 워크숍을 수행했다. 이는 비즈니스 흐름상 발생하는 도메인 이벤트를 시계열적으로 배치하고, 이를 유발하는 커맨드(Command)와 액터(Actor)를 식별하는 과정이다.

2.1 바운디드 컨텍스트(Bounded Context) 도출

워크숍 결과, 시스템은 다음과 같은 5개의 독립적인 컨텍스트로 구체화되었다.

  • 회원(User): 식별, 인증 및 자산(펫코인) 관리.

  • 펫(Pet): 개체 정보 등록 및 외부 디바이스 데이터 연동.

  • 기록(Record): AI 기반 다이어리 생성 및 멀티미디어 아카이빙.

  • 소셜(Social): 사용자 간 상호작용 및 피드 관리.

  • 쇼핑(Shopping): 상품 및 주문 트랜잭션 처리.

이 과정에서 '펫 정보 삭제 시 데이터 보존 정책'에 대한 논의가 이루어졌다. 물리적 삭제(Hard Delete) 대신 상태값 변경(Soft Delete)을 통해 사용자의 과거 기록(Record)과의 연관 관계를 유지하고, 데이터의 정합성과 비즈니스적 가치를 동시에 보존하도록 설계했다.

3. 서비스 레이어 설계: 기록(Record) 서비스의 전문성 강화

기록 서비스는 AI 모델과 사용자 업로드 데이터를 처리하는 핵심 도메인이다. 본 서비스의 안정성과 확장성을 위해 다음과 같은 설계를 적용했다.

3.1 엔티티 생명주기 분리 (DiaryImage vs PhotoArchive)

이미지 데이터의 관리 효율성을 위해 도메인을 이원화했다.

  • DiaryImage: 일기라는 비즈니스 문서에 종속된 구성 요소로서 일기 삭제 시 연쇄 삭제를 허용한다.

  • PhotoArchive: 사용자의 고유 자산으로서 영구 보존하며, 동일 리소스에 대한 중복 업로드를 방지하기 위해 ImageSource(GALLERY/ARCHIVE) 기반의 전송 로직을 구축했다.

3.2 Spring AI를 활용한 지능형 데이터 구조화

비정형 이미지 데이터를 분석하여 다이어리 본문을 생성하는 과정에서 Spring AI의 ChatModel 추상화 계층을 활용했다.

  • Structured Output: AI의 텍스트 응답을 자바 POJO(AiDiaryResponse)로 매핑하여 런타임 안정성을 확보했다.

  • Externalized Prompts: 프롬프트 관리를 비즈니스 로직과 분리하여 리소스 파일(.st)에서 로드하도록 설계, 모델 튜닝의 유연성을 확보했다.

4. 분산 환경의 정합성 보장: Feign Client 통신 및 검증

MSA 구조에서 발생하는 서비스 간 의존성 문제를 해결하기 위해 OpenFeign을 기반으로 한 통신 인터페이스를 구축했다.

4.1 연동 규약 및 존재성 검증

다이어리 생성 시 타 서비스(User, Pet)의 식별자 유효성을 보장하기 위해 생성 전 검증 로직을 강제했다.

  • Feign Client 분리: 단일 인터페이스의 비대화를 막기 위해 UserServiceClient와 PetServiceClient로 분리하여 SRP(단일 책임 원칙)를 준수했다.

  • Exception Handling: 원격 서비스에서 반환하는 404 Not Found를 FeignException으로 포착하여 로컬 트랜잭션을 중단(Rollback)시키는 방식을 통해 데이터 무결성을 확보했다.

5. 클라이언트 컨텍스트 최적화: 시공간 데이터 및 상태 동기화

사용자 경험의 일관성을 위해 프론트엔드와 백엔드 간의 상태 동기화 방식을 고도화했다.

5.1 하이브리드 위치 정보 추적

AI 다이어리의 맥락 정보를 보강하기 위해 시점별 위치 정보를 바인딩했다.

  • 실시간(GPS): 현재 시점의 작성 요청 시 브라우저 API를 통한 좌표 획득.
  • 이력(PostGIS): 과거 날짜의 기록 시 백엔드 이력 조회 API를 호출하여 시공간적 정확도를 확보했다.

5.2 실시간 데이터 동기화

JWT 토큰 내부에 정적으로 유지되던 사용자 정보를 실시간 API 조회 방식으로 전환하여, 마이페이지 등 타 도메인에서의 변경 사항이 시스템 전체에 즉시 반영되도록 개선했다.

6. 운영 거버넌스: 지속 가능한 개발과 애자일 철학의 실현

기술적 성과만큼이나 중요한 것이 운영 거버넌스의 확립이다. 멘토링 피드백을 수용하여 다음과 같은 개발 표준을 수립했다.

  • 속도(Velocity) 기반 스프린트: 미완료 작업을 주말 근무로 충당하는 대신, 팀의 실제 개발 속도를 측정하여 다음 스프린트의 가용 용량(Capacity)에 반영하는 지속 가능한 모델을 채택했다.

  • 디렉토리 구조의 표준화: 디렉토리 구조 자체가 팀의 아키텍처 철학을 대변한다는 원칙 하에, 레이어 간 의존성 방향을 명확히 하는 표준 프로젝트 템플릿을 정의했다.

  • Git 전략: 각 마이크로서비스의 독립적 배포(CI/CD)를 위해 서비스별 개별 저장소(Repository) 운영 정책을 확정했다.

7. 결론

본 프로젝트는 MSA 도입을 통해 도메인별 전문성을 확보하고, 이벤트 스토밍을 통해 비즈니스 흐름을 정교하게 설계하는 데 집중했다. 기술적 난제들은 추상화와 유효성 검증이라는 엔지니어링 원칙으로 해결했으며, 운영 측면에서는 데이터에 기반한 애자일 방법론을 도입했다.

0개의 댓글