한우 IoT 모니터링 앱과 통합 API 구축

주요 기능

무엇을 만들었나요?

• SMS 인증번호(OTP) + JWT 로그인 — 인증번호 자동입력, 약관 동의, 자동 토큰 갱신
• 농장 홈 — 전체·발정·임신·분만예정 요약과 경고·주의·정상 개체 카드, 목장 현황 통계 차트
• 개체 목록 — 상태 아이콘·정렬·고급 필터(임신·경산·체온·활동)·검색
• 개체 등록·수정·삭제와 프로필 이미지 업로드, 임신·산차·우사 위치·품종 입력
• 개체 상세 AI 리포트 — 분석 요약·근거·권장 조치와 음성 안내
• 데이터 차트 — 체온 분포 히트맵, 24시간 활동량·반추량 차트
• 시세정보 — 등급별 경락가 조회 후 도체중·비용을 반영한 예상 매출 계산
• 알림 큐 워커 기반 FCM 푸시·SMS 동시 통지와 개체 상세 딥링크 이동

해결 과정

제약을 어떻게 풀었나요?

1. 제약 1

   기존 웹(PHP) 운영 시스템에 REST API가 없고, 운영 DB(MSSQL)는 실데이터가 쌓이는 곳이라 구조를 바꿀 수 없었습니다.

   의사결정: 운영 DB를 원칙적으로 읽기 전용으로 연동하고 DDL은 건드리지 않기로 정했습니다. 앱 전용 데이터는 서버가 소유한 별도 보조 테이블에만 저장하기로 했습니다.

   구현: Controller→Service→Model 계층의 통합 API 게이트웨이를 신규 구축해 운영 DB를 모바일용 /api/mobile/* 네임스페이스로 중계했습니다. 운영 DB 쓰기는 최종 로그인 시각과 알림 확인 정보 3개 컬럼으로만 제한했고, 인증번호·리프레시 토큰·푸시 토큰은 보조 테이블에 두었습니다.

2. 제약 2

   운영 DB는 한글 enum 값을 쓰고 농장별 데이터가 한 테이블에 섞여 있어, 그대로 앱에 내보내면 상태 표기가 흔들리고 다른 농장 데이터가 보일 위험이 있었습니다.

   의사결정: 게이트웨이에서 값과 권한을 정규화한 뒤 앱에 넘기기로 했습니다.

   구현: 한글 enum을 앱용 영문 enum으로 정규화하고, 농장 권한(adminid) 기준으로 데이터를 격리했습니다. AI 통합분석 결과도 게이트웨이에서 단일 소스로 가공해 상태 우선순위에 따라 대표 상태 하나를 고르도록 했습니다.

3. 제약 3

   이상 징후는 알림이 늦으면 의미가 없는데, 알림은 운영 시스템의 알림 큐에만 쌓이고 있었습니다.

   의사결정: 큐를 주기적으로 소비하는 워커를 게이트웨이에 두고, SMS와 푸시를 함께 보내기로 했습니다.

   구현: AlarmQueue의 PENDING 알림을 수집해 FCM으로 발송하고 이력을 기록하는 워커를 구현했습니다. 앱에서는 알림을 누르면 딥링크(livecare:// · App/Universal Links)로 해당 개체 상세 화면으로 이동합니다.

4. 제약 4

   스토어 심사자는 실제 휴대전화 SMS 인증과 실 농장 데이터가 없어 앱 전 기능을 확인할 수 없었고, 실데이터를 열어주면 개인정보가 노출됩니다.

   의사결정: 실 운영 데이터와 완전히 분리된 심사 전용 경로를 따로 만들기로 했습니다.

   구현: 지정된 심사용 번호로 로그인하면 SMS 발송 없이 심사 전용 데모 농장으로 들어가도록 서버에 분기를 넣었습니다. 데모 농장은 실 농장 한 곳의 구조를 복제하되 농장명·소유주·연락처·주소·개체식별번호를 모두 더미 값으로 치환했고, 전체 데모 데이터는 스크립트로 원복할 수 있게 구성했습니다.

화면

실제 화면과 구조

사용 기술