시작은 익숙한 레이어드 아키텍처로프로젝트의 시작은 가장 익숙한 레이어드 아키텍처였다.서비스 초기에 중요한 건 복잡한 설계보다 빠르게 동작하는 결과물을 내는 것이었고, 레이어드 구조는 단순하면서도 직관적이어서 빠른 개발에 적합하다고 생각했다.서비스 구조 설계서비스 구조는 전통적인 레이어드 아키텍처를 기반으로 Controller, Service, Repository 세 계층으로 나누고 외부 이벤트 처리를 위해 Mqtt Consumer를 추가했다. Controller 영역클라이언트의 요청을 가장 먼저 받는 진입점 역할이다.요청을 검증하고, 비즈니스 로직 실행을 위해 Service 계층을 호출한다.REST API 및 Mqtt 요청의 엔드포인트 역할을 담당한다.Consumer 영역외부 메시지 브로커에서 발행된 이..

백엔드와 안드로이드 구조, 그리고 기술 스펙 설계기획이 어느 정도 윤곽을 잡자, 바로 설계 단계에 들어갔다.이번 프로젝트는 안드로이드와 백엔드 모두를 아우르는 구조 설계가 필요했다.게다가 나는 두 영역에 모두 참여하기로 했으니, 처음부터 끝까지 전부 고민해야 했다. 안드로이드 쪽은 예전에 마감에 쫓겨 급하게 만들었던 MVVM 구조를 다시 꺼냈다. 그때는 그냥 "View, ViewModel, Model을 나눠놓으면 MVVM이겠지" 하고 넘어갔는데, 이번에는 데이터 흐름, 라이프사이클, 모듈화까지 꼼꼼히 고려해 설계했다.또한, Wear OS 환경에 맞춰 불필요한 의존성을 줄이고, 화면 전환이나 데이터 요청 시 배터리 소모를 최소화할 방법도 고민했다. 백엔드 쪽은 MSA 구조를 다시 한번 다뤄보기로 했다.이전..

배경2023년 10월 첫 출근 후 집으로 가는 길이었다. 애플 워치 화면에 찍힌 걸음 수는 "12,135" 원래라면 그냥 지나쳤을 숫자였지만, 그날은 유독 눈에 들어왔다. 그리고 문득 머릿속에 질문 하나가 떠올랐다."이 숫자를 어디에 활용해 볼 수 있을까?" 일상의 문제를 개발로 해결하는 사람이라면 한 번쯤 하는 생각일 것이다. 그 순간, 이전 SSAFY 에서 진행했던 다마고치 앱 개발 프로젝트가 떠올랐다.그때는 삼성 페이 결제 금액을 기반으로 캐릭터가 성장하는 시스템을 만들었고,사용자가 버튼을 누를 때마다 캐릭터가 반응하며 즉각적인 보상을 제공했다.비록 3개월 후 서비스를 종료했지만, 데이터를 행동으로 바꾸는 재미를 처음으로 느끼게 해준 경험이었다. 그리고 이번엔 이렇게 생각했다."걸음 수 데이터를 기..