개발 인원: BE 3인, AOS 3인
개발 기간: 2025. 04. ~ 2025. 05. (6주)
Github 바로가기 →
🩺️ 서비스 소개
요양보호사들의 아날로그 방식 수기 기록과 비표준화된 커뮤니케이션 문제를 해결하기 위해 개발된 디지털 요양 기록 비서 서비스입니다.
음성 인식, OCR, 건강 상태 측정, AI 리포트 등의 기능을 통해 요양 기록 과정을 디지털화하여 보다 효율적이고 신뢰할 수 있는 요양 환경을 조성하는 것을 목표로 합니다.
👤 담당 역할
- 팀장
- 백엔드 개발 (기여도 52%)
- JPA를 활용한 도메인 모델링
- PostgreSQL 데이터베이스 연동
- Spring Boot 기반 REST API 설계 및 개발
- OCR 시스템 구축 (기여도 100%)
- FastAPI 기반 OCR 서버 개발
- Naver CLOVA API 연동을 통한 일정표 텍스트 추출 기능 구현
- AI 데이터 수집 및 전처리 (기여도 90%)
- AI 리포트 생성을 위한 데이터 생성 및 전처리
- 프로젝트 최종 발표
⚙️ 개발 환경
| 언어 | Java 17, Kotlin |
| 서버 | Ubuntu 22.04.5, Docker 26.1.3, Jenkins 2.501 |
| 프레임워크 | Spring Boot 3.2.5, Spring Security, JPA, Android SDK, ... |
| DB | PostgreSQL 15.x, Redis |
| IDE | IntelliJ IDEA Ultimate 24.3.8, Android Studio 2024.3.1 |
| API, 라이브러리 | RESTful API, JWT, Retrofit/OkHttp, Firebase, AWS S3, ... |
아키텍처 구성도

주요 기술 선정 이유
Spring Boot
- RESTful API 개발에 검증된 프레임워크로, JPA를 통한 복잡한 도메인 모델링과 PostgreSQL 연동이 용이. 또한 팀원들의 기술 숙련도와 풍부한 생태계를 고려해 안정적인 백엔드 구축이 가능.
FastAPI
- OCR과 AI 데이터 처리를 위한 Python 기반 서비스가 필요했고, FastAPI는 높은 성능과 자동 API 문서화 기능을 제공해 Spring Boot 메인 서버와의 연동을 효율적으로 구현할 수 있음.
PostgreSQL
- 건강 데이터의 복잡한 집계 쿼리와 시계열 분석에 MySQL보다 적합하고, 다중 사용자 환경에서의 동시성 처리가 우수. 추후 요양원 확장과 대용량 건강 데이터 처리를 고려해 선택.
Redis
- 건강 데이터 수치 계산 후 사애적인 상태(높음/보통/낮음)를 화면에 진입할 때마다 일일이 계산하지 않도록, 측정 시에만 캐싱해 두고 이용.
주요 기능 및 목업



성과
팀 성과
- 요양보호사 현직자 인터뷰를 통해 수기 작업의 비효율성과 소통 문제 파악
- STT(음성 인식) 기반 일지 작성 기능 안정화
- 실시간 스트리밍 음성 인식에 캐싱 매커니즘과 비속어 필터링을 적용
- 중복 발화 방지 처리로 데이터 신뢰성 확보
- AI 주간 리포트 자동화 성공
- Mistral 7B, LoRA 기반 최적화와 프롬프트 설계를 통해 건강 데이터 및 활동 내역의 요약 보고서를 자동 생성
개인 기여
- AI 모델 학습용 건강 데이터 직접 생성 및 전처리
- 건강 지표별 정상 범위 정의 및 변화 패턴 감지 로직 개발
- FastAPI 기반 OCR 시스템 구축 및 Spring Boot와의 연동 아키텍처 설계
- OCR 기능 인식 정확도 약 84% 향상 (Google Vision → Naver CLOVA)
- JPA N+1 문제를 로그 분석으로 발견하고 @BatchSize로 해결 (쿼리 21개→3개)
- Spring Boot 기반 REST API 설계 및 구현 (일정표, 일지, 측정 기능 중심)
- AWS S3 이미지 업로드 구현 (모바일 서비스에 맞춘 리사이징 로직으로 스토리지 비용 절약 및 전송 속도 향상)
회고
- 전체적인 일정 관리를 위해서는 팀원 개개인의 현황 공유가 정확해야 한다는 것을 느꼈습니다. 팀장으로서 전반적인 진행 상황을 파악하고 역할 조정을 결정할 필요를 느꼈습니다. (업무 재분배 및 우선순위 부여 등)
- 백엔드 개발자로서 Spring 서버 위주로만 구현해 왔는데, FastAPI 및 외부 서비스와 연동하는 등의 새로운 시도를 해 볼 수 있었습니다. 이 과정에서 생긴 인프라 문제를 직접 포착하여 해결하기도 했습니다. (docker-compose port값 이슈)
- AI 영역의 경우, 모델 학습에 필요한 데이터를 직접 생성하고 그 유효성을 위해 전처리를 담당함으로써 다양한 상황적 요소를 고려할 수 있는 기회가 되었습니다.
- ResponseCode, ResponseDTO, ApiResult를 통해 예외처리와 응답 구조를 통일한 결과, 이후 수정이 수월해졌고 프론트엔드에서도 다양한 상황에 대응할 수 있게 되어 유지보수 가능한 코드의 중요성을 깨달았습니다.
Detail
1. AI 건강 리포트 생성 모델을 학습시키기 위한 데이터 생성
초기에는 건강 데이터 학습용 샘플을 단순한 랜덤 값으로 생성했으나, 실제 건강 지표의 변화 패턴과 차이가 커서 모델 성능이 저하되는 문제가 발생했습니다. 이에 건강 지표의 일반적인 변동 특성을 고려하여 지표별 정상 변동 범위를 정의하고, 확률 기반 패턴 생성 로직을 구현했습니다. 체지방률은 정상 변동의 2.5배, 심박수는 2.0배 이상 차이 시 특이점으로 감지하는 임계값을 설정하였고, 급변(30%), 추세(50%), 변동성(20%) 패턴을 현실적인 확률로 분배하여 적용한 결과, 생성된 데이터의 의학적 타당성이 크게 향상되어 보다 정확한 건강 리포트 기능 구현이 가능해졌습니다.

2. OCR 기능 인식 정확도 향상
초기에는 Google Vision OCR 기술을 활용하여 선과 칸, 텍스트를 위치에 기반하여 인식하는 로직을 일일이 생성했습니다. 그러나 시간 및 클라이언트(요양 대상)의 이름을 잘못 인식하는 문제, 스케줄을 다수 누락시키는 문제가 발생하였고, 50개 중 5개 일정만이 정상적으로 등록되었습니다. 이에 Naver CLOVA OCR을 적용하여 표를 먼저 인식하도록 하였고, 이후 인식된 텍스트를 파싱하여 JSON으로 구조화한 결과, 50개 중 47개 일정이 정상적으로 등록되어 정확도가 약 84% 상승했습니다. 미인식된 소수의 일정 또한 사진상의 빛반사나 흔들림 등에 의한 것으로, 일반적인 촬영 상태로는 인식률이 100%에 달하는 결과를 보였습니다.

'project' 카테고리의 다른 글
| 전북잇다 (JB eat-da) (0) | 2025.09.05 |
|---|---|
| 러너스 (LEARNAUTH) (0) | 2025.09.05 |
| 레퍼 (REPER) (0) | 2025.09.05 |