소개

최근 해커톤에 참여했던 프로젝트를 계속 디벨롭하고 있고, 그 과정을 기록으로 남기고자 합니다.
프로젝트명은 아이바(Aiva) 로, 생성형 AI 기반 육아 챗 서비스입니다. 팀 내 AI 개발자분께서 7세 미만 육아 도메인에 특화된 모델을 파인튜닝해주셨고, 회원가입 시 입력한 육아 정보를 바탕으로 사용자가 채팅으로 질문하면 맞춤형으로 답해줍니다.

채팅뿐 아니라 커뮤니티 기능을 통해 양육자 간 정보 공유와 소통을 지원하고, 알림 서비스로 개인별 육아 정보를 큐레이션합니다. 또한 구독제를 도입해 더 전문적인 모델 사용과 일일 채팅 횟수 상향을 제공하도록 설계했습니다.

msa 도입배경

아이바는 표면적으로는 ‘채팅 서비스’이지만, 실제로는 커뮤니티/알림/구독/결제 등 다양한 도메인이 얽혀 있습니다. 이 참에 MSA(Microservices Architecture) 를 직접 도입해보며 학습·검증하자는 목표를 세웠습니다.

해커톤 기간 내 전부 구현하는 건 무리라는 걸 알았기에, 해커톤 종료 후 개인적으로 프로젝트를 이어가며 적용했습니다. 솔직히 지금 단계에서는 오버스펙에 가깝지만, 개념으로만 알던 MSA를 실전에서 다뤄보며 배우는 것에 의의를 두었습니다.

그렇다면 실무에서는 왜 MSA를 택하고, 어떻게 도입할까요? 아주 짧게 개념을 정리하면:

• 왜: 팀 단위 병렬 개발, 독립 배포, 장애 격리, 도메인 경계 명확화, 확장성(서비스별 스케일 아웃)
• 어떻게: 도메인 분해 → 데이터베이스 분리 → 서비스 간 통신 전략(REST/gRPC/이벤트) 수립 → 모니터링(로그/메트릭/트레이싱) → 배포/테스트 자동화(CI/CD 등)

(각 항목의 구체 적용과 트레이드오프는 다음 글들에서 서비스별로 자세히 다룰 예정입니다.)

아이바: msa 아키텍처 설계

기본 설계

• 도메인 분리: User / Chat / Community / Notification / Subscription (총 5개)
• 데이터 격리: 각 서비스는 자체 MySQL(스키마/인스턴스 분리)
• API Gateway: Spring Cloud Gateway로 라우팅, 인증, 로드밸런싱 중앙화
• 캐싱/세션: Redis로 세션 공유와 읽기 최적화 캐싱
• 통신 방식: 서비스 내부는 동기(REST/gRPC) + 비동기(Kafka) 혼합
• 모니터링: 로깅/메트릭/트레이싱을 서비스별로 수집·대시보드화(예정예정)

기술 스택

• Backend: Kotlin/Spring Boot
• API Gateway: Spring Cloud Gateway
• DB: MySQL (서비스별 독립 인스턴스/스키마)
• Cache/Session: Redis
• Messaging: Kafka (알림/이벤트)
• Push: FCM
• CI/CD & Monitoring: (Not yet..)

마무리

MSA 도입의 시작.. 대서막....!
해커톤 일정에 쫓겨 초반 아키텍처를 엉성하게 잡았고, 이후 『가상 면접 사례로 배우는 대규모 시스템 설계』 스터디와 추가 학습을 거치며 여러 번 갈아엎었습니다. 이제야 벨로그에 정리하며 기반을 다질 수 있을 만큼 방향이 잡힌 듯합니다.

물론 아직 부족한 부분이 많고, 앞으로도 계속 수정과 개선이 뒤따를 겁니다. 개발은 원래 그런 과정이니게..
점진적으로 나아가 보겠습니다. 아좌좌~