https://github.com/Team-ReMind/Android/tree/dev/app/release
정신 질환 환자의 일상적인 무드 차트와 약 복용 기록이 환자 담당자에게 공유되어 지속적 관리를 도와주는 서비스, RE:MIND
| 분야 | 이름 | 포지션 |
|---|---|---|
| 기획 | 배예진 | 📈서비스 기획 - PM, 데스크리서치, 유저 리서치, 비즈니스 모델 구축, 와이어프레임 작성 |
| 기획 | 김서연 | 📊서비스 기획 - 유저 리서치, 비즈니스 모델 구축, 와이어프레임 작성 |
| 기획 | 김채진 | 📋 서비스 기획 - 유저 리서치, 비즈니스 모델 구축, 와이어프레임 작성 |
| 디자인 | 김규리 | 🔐 서비스 디자인 - 로고 제작, 서비스 세부 디자인 |
| 디자인 | 박정환 | 📢 서비스 디자인-포스터 제작, 서비스 세부 디자인 |
| 개발 | 송승희 | 🔦 AOS 개발 UI 구현, 서버 연동 |
| 개발 | 이상민 | 💻 백엔드 리드, DB 및 API 구축, 서버 배포 |
| 개발 | 박진우 | 🖥️ DB 및 API 구축, 서버 배포 |
어릴 때부터 성인이 된 지금까지 항상 언급되는 대한민국의 대표적인 사회적 문제가 있습니다.
바로 우리나라의 높은 자살률 문제입니다.
한국은 OECD 국가 중 자살률이 10만명당 22명으로 가장 높습니다. 그리고 자살자들의 95% 가 실행 당시 정신 질환 이 있었을 것으로 판단되어집니다. 따라서 정신 질환에 대한 적절한 치료가 자살률을 크게 줄일 수 있습니다.
저희는 더욱 효과적으로 정신 질환 치료가 이루어질 수 있도록 돕고자 하였고, 이를 위해 전문가 심층 인터뷰와 설문조사를 진행하였습니다.
1️⃣ 전문가 심층 인터뷰
- 정신건강의학과 의사와의 인터뷰
[Pain Point & Solution]
- 짧은 진료시간으로 인한 진료왜곡현상 발생
⇒ 진료 외 시간의 환자 기록을 요약하여 진료 시 참고
- 시각적으로 보이는 회복도의 부재
⇒ 무드 차트를 통한 환자의 감정 변화 및 회복 추이 시각화
- 환자의 약 복용을 정확히 파악하거나 지원하기 어려움
⇒ 약 복용 여부 입력을 통한 환자의 치료 순응도 파악
- 정신건강복지센터와의 인터뷰
[Pain Point & Solution]
- 환자의 이용률이 낮은 자기 관리 수첩을 사례 관리에 활용하기 어려움
⇒ 환자의 작업을 최소화하여 서비스 이용률을 높이고, 센터가 수집된 기록을 활용하도록 지원함
- 사례관리 대상의 상태를 비대면으로 모니터링하기 어려움
⇒ 무드차트 월별 기록을 통해 환자의 기분 변화 추이를 제공
- 비효율적인 약 복용 여부 검사
⇒ 환자의 약 복용 여부를 실시간으로 비대면 조회 지원
2️⃣ 설문- 정신과 진료 유경험자 대상
- 진료
⇒ 짧은 진료 및 상담 시간으로 인해 깊이 있는 상담이 어렵고 의사에게 자신의 이야기를 전달하는 것에 어려움을 느끼고 있다.
- 약복용
⇒ 약 복용 시간을 자주 잊어 제시간 복용이 어렵고 복용 시 나타나는 부작용으로 인해 어려움을 느끼고 있다.
위와 같은 조사를 바탕으로 정신질환의 효과적인 치료 및 회복의 Pain Point가 크게 두 가지 존재한다고 판단하였습니다
1️⃣ 정신과 외래 진료 시간이 짧다.
현재 대부분의 정신과 진료 시간은 한 환자 당 약 5~10분 사이입니다(초진 제외). 저희는 앞서 진행한 유저 리서치에서 이러한 짧은 시간 동안 효과적인 진료를 진행하는 것이 어렵다는 점을 파악할 수 있었습니다. 외래 환자의 경우 자신이 겪은 감정과 상황을 짧은 시간 내에 의사에게 전달해야 하기 때문에 진료 및 상담의 어려움을 느끼고 있습니다. 의사 역시 환자의 기억에 의존한 진료 과정에서 진료 왜곡을 경험한다는 고민 지점이 존재합니다.
2️⃣ 치료 중단 이후 회복기에 극단적 선택을 하는 경우가 많으나, 효과적인 사례관리가 어렵다.
정신 질환으로 입원 치료를 받고 퇴원한 후 30일 내 자살률은 퇴원 환자 10만 명당 우울증 364명, 조현병 168명, 양극성 정동장애 158명으로 일반 인구 집단에서 자살한 사람의 66.8배 많습니다.
이를 방지하기 위해 정신건강복지센터는 환자들에게 퇴원 이후 지속적 관리를 도와주는 사례 관리를 제공하고 있습니다. 그러나 한 명의 사례관리자가 35-40명의 환자를 담당하여 대상자의 집에 직접 찾아가 약 봉투를 검사하고 환자의 상태를 체크하는 방식의 사례 관리 방식으로 업무 부담이 상당한 상황입니다. 이러한 시간 및 비용적 제약으로 인해 사례관리자가 환자의 일상을 효과적으로 관리하고 긴급 상황에 대처하기는 어렵다는 페인 포인트를 가지고 있습니다.
따라서 팀 말랑말랑은 환자가 진료 외 시간에 입력한 상태 정보를 의사와 사례관리자가 참고하여 진료 왜곡 현상 문제를 해결하고 사례 관리 업무의 효율성과 효과성을 강화하는 서비스, RE:MIND를 제안합니다.
저희 서비스의 ‘전체적으로 유사한’ 경쟁 서비스들을 조사하였고,
서비스의 주요 기능들을 가지고 있는 ‘기능별’ 경쟁 서비스들을 심층적으로 분석하였습니다.
- 환자의 서비스 이용 내역이 의사 및 사례관리자의 의사 결정 지원에 활용된다
- 무드 차트 기록 결과를 통해 관련 진료를 받을 수 있다
- 약 복용 여부에 따라 적절한 대처를 받을 수 있다
- Tam-Sam-Som
| TAM | SAM | SOM |
|---|---|---|
| 정신과 질환 치료 센터 | 정신과 질환 환자의 진료 만족도를 높이기에 관심이 있는 곳 | 환자 관리를 효율적으로 하여 환자의 질환을 적극적으로 치료하고자 하는 곳 |
| 9,802 명 | 239개소 | 131개소 |
저희 서비스 타겟층은 ‘정신 질환 치료 센터’와 ‘정신질환자’입니다.
그 중, 상세한 타겟층은 아래와 같은 대상으로 설정하였습니다.
-
환자 관리를 효율적으로 하여 환자의 질환을 적극적으로 치료하고자 하는 정신질환 센터/병원 (사례 관리자/의사)
-
일상에 치료 행위에 관심을 갖고 치료 기록에 적극적으로 참여하는 정신질환자
| 분류 | 1차 타겟 유저 🏥 | 2차 타겟 유저 💊 |
|---|---|---|
| 타겟 설정 | 1. 내원하는 대상자들을 효율적으로 관리하고, 적절한 대처를 즉각적으로 하고자 하는 정신복지센터 (사례관리자) 2. 내원하는 환자들의 진료를 유용한 정보들을 근거로 효율적이게 내리고자 하는 정신과 병원 (정신건강의학과 의사) |
1. 앓고 있는 정신 질환을 극복해내기 위해 정신과 진료 및 약 복용을 꾸준히 하는 정신질환자 2. 정신 질환 극복에 위해 정신복지센터 사례관리자의 도움을 받고 있는 정신질환자 |
| 관련 기능 | 관리 중인 환자의 증상을 나타내는 ‘무드 차트’와 ‘약복용 여부’를 파악하기 쉬운 ‘대시보드 형태’로 제공 → 특정 기간의 환자 상태와 주요 이슈 파악 지원 → 효율적인 환자 관리 및 의사 결정 |
자신의 증상을 ‘무드 차트’와 ‘약복용 여부’로 매일 기록할 수 있는 기능 → 증상을 즉각적으로 담당 센터/병원(사례관리자/의사)에게 전달하여 환자가 효율적인 진단을 받을 수 있게 도움 → 사용자의 상태를 즉각적으로 전달하여 사례 관리자의 빠른 대처 행동을 받을 수 있게 도움 |
"Re:Mind"서비스는 환자 담당 전문의 및 사례관리자에게 환자의 무드 차트 기록과 약 복용률 등의 데일리 라이프 정보를 압축적으로 제공합니다. 이를 통해 환자의 상태를 정확하게 파악할 수 있고 더욱 효과적인 관리가 이루어지도록 도와줍니다.
| 타겟층 | 설명 | 예상 효과 |
|---|---|---|
| 정신질환자 | ✅무드 차트 기록 ) 환자가 본인의 감정을 회고하고 치료 시 참고할 수 있도록 하루의 전체 평균 기분 점수와 활동 별 기분, 추가 메모 등을 기록함. ✅ 약 복용 기록) 환자가 약 복용 정보 추이를 확인하고 치료 시 참고할 수 있도록 처방된 약의 복용 여부를 기록함. 리마인드 알림 설정으로 지속적인 복용을 지원함. ✅ 무드차트 및 약 복용 대시보드) 환자의 상태 추이를 파악할 수 있는 무드차트와 약 복용 대시보드 조회 기능. 무드 차트 점수 그래프와 약 복용률 통계, 선택일 상세 기록 등의 내용을 조회할 수 있음. ✅ 긴급 도움 요청 ) 자살예방상담센터 전화 연결 및 환자의 담당 의사와 사례 관리자에게 알림 전달 |
1. 지속적인 상태 기록으로 사용자의 치료 및 예방을 지원*한다. 2. 알림 등의 기능으로 꾸준한 약 복용을 지원한다 |
| 정신건강의학과 의사 & 정신건강복지센터 사례관리자 |
✅ 담당 환자 관리) 등록된 담당 환자의 기록을 조회하거나 추가 치료 지원 기능을 제공함. 코드를 이용하여 담당 환자를 추가하거나 해제할 수 있음. ✅무드차트 및 약 복용 대시보드) 단시간 내 담당 환자의 상태를 효율적으로 파악할 수 있도록 환자의 기록을 압축적으로 제시함. 환자의 상태 추이를 파악할 수 있는 무드 차트와 약 복용 대시 보드 조회 기능. 요약된 정보를 우선 제공하되, 별도의 상세 기록도 확인할 수 있음. 무드 차트 점수로 회복 추이를 평가하거나 약 처방 통계로 치료 순응도를 파악하는 업무를 지원함 ✅긴급 도움 요청에 대한 대처 ) 긴급 도움을 요청한 담당 환자에 대한 즉각적 대응을 지원함. 요청 정보를 전달하고 환자 기록 조회나 전화 연결 등. (향후 보호자 연락 기능 추가 예정) |
1. 짧은 진료 시간 내 환자의 상태를 효과적으로 파악하고 정확한 의사 결정을 내린다. 2. 환자의 상태에 따른 즉각적인 대처를 지원한다. |
| 정신건강의학과 의사 | ✅ 환자 약 처방 정보 업데이트 ) 환자에게 약을 처방할 시간대와 중요도를 입력할 수 있음. | 1. 환자의 약 복용률과 미복용 사유 등을 바탕으로 진료 시간에 부작용 유무 등을 상의하고 다음 처방을 진행한다. |
| 정신건강복지센터 사례관리자 | ✅ 위험도 높은 환자 관리 ) 특히 주의할 필요가 있는 환자 리스트를 제공하여 관리 편의성을 강화함. 약 복용과 무드 차트 점수에 따라 위험도에 차등을 두어 사례 관리자의 의사 결정을 지원함. | 1. 사례관리자의 우선순위 의사 결정과 정보 조회를 지원한다. |
*송가영, 이세정, 윤운, 김창윤, 전명욱, 주연호, 이중선. (2018). 양극성장애 환자용 한국어판 기분 기록 스마트폰어플리케이션의 개발 및 임상적 적용. 신경정신의학, 57(3), 244-251.
| 개발 환경/ 기술스택 | 사용 이유 |
|---|---|
| Android OS | 안드로이드는 가장 널리 사용되는 모바일 운영체제 중 하나로 보다 많은 사용자에게 편리한 서비스를 제공하고자 선택했습니다. |
| Clean Architecture | • App: 어플리케이션의 진입점을 포함하며 종속성 주입, 애플리케이션 수명주기 관리, 전역 설정을 담당합니다. • Core: 앱의 중심적 기능과 로직을 포함하여 재사용 가능한 모듈 또는 컴포넌트를 제공합니다. • Domain Layer: 비즈니스 로직을 포함하고 있으며, 이에 필요한 와 Usecase, Repository 를 포함합니다.• Data Layer: Data Layer는 Domain Layer에 의존성을 지니고, Repository의 구현체, 데이터의 입출력을 진행하는 Data Source, Entity를 포함합니다.• Presentation Layer: 내부적으로 프레임워크 의존성을 처리하기 위해 MVI 패턴을 사용합니다. MVI 패턴에서 이 레이어는 사용자의 의도(Intent)를 처리하고, 이를 모델로 전달하여 필요한 상태 변화를 요청합니다. 변화된 상태를 반영하여 사용자에게 보여주는 역할을 합니다. • ui: 사용자에게 보여지는 화면을 정의합니다. |
| Jetpack Compose | Android ui를 선언적으로 구현하여 효율적으로 ui를 설계 및 구현할 수 있도록 하였습니다. 또한 compose에 적합한 MVI 패턴으로 개발을 진행하였습니다. |
| Dagger-Hilt | Clean Architecture의 각 계층에서 필요한 싱글톤 객체 생성과 다른 계층에 접근하기 위한 의존성 주입에 Dagger Hilt를 사용합니다. |
| Android Jetpack | Android Application 개발 시 구글에서 권장하는 Jetpack 라이브러리 viewmodel, flow, datastore를 적극 활용했습니다. |
| Retrofit | Restful API 호출을 보다 쉽게 구현하고자 사용하였습니다. |
| CICD | Github Action을 활용한 CI/CD를 구축하여 코드 변경사항이 dev 브랜치에 push될때마다 자동으로 테스트 되게하여 코드의 안정성을 보장하였고 빌드가 완료되면 팀 Slack에 apk 파일을 자동으로 업로드 하여 배포 자동화를 구축하였습니다. |
| 개발 환경/ 기술스택 | 사용 이유 |
|---|---|
| Spring Boot | 백엔드 팀원 2명의 이해도가 가장 높은 개발 언어는 자바입니다. 자바를 기반으로 한 프레임워크 중 안정적이고 레퍼런스가 잘 되어 있는 프레임워크는 스프링 프레임워크입니다. 저희는 이러한 이유로 스프링 프레임워크를 선택하였습니다. |
| Spring Security | 토큰과 함께 백엔드 서버에 대해 빠르고 손쉽게 인증 / 인가 기능을 구현할 수 있어 Spring Security를 사용하였습니다. 여러 SecurityFilterChain을 만들어 API마다 인증 / 인가를 커스텀마이징 할 수 있고 확장 할 수 있습니다. |
| JWT | JWT토큰을 사용하면 토큰 내에 사용자 아이디, 권한, 만료시간을 저장하고 쉽게 암호화/복호화할 수 있습니다. |
| Spring-Data-JPA | 저희 팀은 개발 언어로 자바를 사용함에 따라 자바 기반 orm 인터페이스인 JPA를 사용하였습니다. 스프링 환경에서 Spring-Data-JPA는 JPA를 추상화하여 JPA를 조금 더 쉽고 간단히 사용하는 방법을 제공해줍니다. 메소드 이름으로 쉽고 빠르게 쿼리문을 작성할 수 있는 장점이 있어 해당 기술을 사용하였습니다. |
| Github-Actions | Github Actions에 관해 풍부한 레퍼런스가 있어 손쉽고 빠르게 CICD 파이프라인 구축이 가능했습니다. 레포지토리를 public으로 하면 기술에 대한 이용 요금이 없기 때문에 해당 기술을 선택했습니다. |
| Swagger | 프론트 개발자가 한 명이라는 단점을 보완하기 위해, API문서화를 자세히 하기로 하였습니다. 짧은 개발 기간 동안 Rest API 환경에서 테스트 코드 작성 없이 springdoc-openapi 라이브러리를 사용하여 손쉽고 빠르게 API 문서화가 가능하여 해당 기술을 사용했습니다. 또한 api테스팅을 제공하는 것이 큰 장점입니다. |
| Redis | 휘발성 데이터인 리프레시 토큰을 저장하기 위해 선택한 Redis는 빠른 I/O 처리와 TTL(Time-To-Live) 기능을 제공하였고 TTL 기능을 제공하는 기술에 대해 팀원들의 Redis에 대한 이해도가 가장 높았기에 해당 기술을 사용했습니다. |
| NCP Server | NCP와의 협업을 통해 크레딧을 제공받아서 좋은 사양의 클라우드 서버를 무료로 사용할 수 있어서 선택했습니다. 팀원 모두 AWS EC2 서버만 구축 해 보았어서, 타 플랫폼의 서버를 구축하는 것이 좋은 경험이 될 것이라 생각했습니다. |
| NCP Container Registry | NCP Server와 같이 사용하여 도커 컨테이너 이미지를 쉽게 관리할 수 있습니다. GIthub-Action과 함께 사용하여 쉽게 CI/CD를 구축할 수 있습니다. |
| NCP Object Storage | NCP Container Register의 도커 이미지를 포함하여, 각종 파일을 저장할 수 있습니다. |
| AWS RDS | NCP에서 제공하는 NCP CloudDB를 사용하려고 했으나, 다소 비싼 가격으로 인해 크레딧을 절약하고자 프리티어를 통해 사용할 수 있는 AWS RDS를 선택했습니다. |
| MySQL | 백엔드 팀원 2명의 이해도가 가장 높은 RDBMS는 MySQL입니다. 인터넷에 MySQL 레퍼런스가 풍부하고 Aws RDS에서 MySQL를 지원해주는 것도 해당 기술의 선택 이유입니다. |
개발부터 배포까지의 워크플로우
- 깃허브의 master branch에 코드를 push한다.
- github secret에 등록된 변수를 서버 루트 디렉터리의 .env 파일로 생성한다.
- 스프링부트 프로그램을 빌드하여 .jar파일로 변환한다.
- NCP Container Registry에 로그인한다.
- docker image로 빌드한다.
- NCP Container Registry에 push한다.
- docker-compose.yml 파일을 서버 루트 디렉터리로 옮긴다.
- NCP Container Registry에서 이미지를 pull한다.
- 도커 컴포즈를 실행하여 스프링부트 어플리케이션을 띄운다.
🖥️Frontend
- 파일 : CamelCase + SnakeCase
- 클래스명 : PascalCase
- 함수/변수명 : CamelCase
💻Backend
- Packages
- 항상 소문자로 생성하기
- Classes
- 명사여야 한다.
- 복합 단어의 경우 각 단어의 첫글자는 대문자.
- 완전한 단어를 사용하고, 두 문자어와 약어는 피한다.
- Interfaces
- 인터페이스 이름도 클래스 이름과 같은 대문자 규칙을 적용한다.
- Methods
- 동사여야 한다.
- 복합 단어의 경우 첫 단어는 소문자로 시작한다.
- Constants
- 클래스 상수로 선언된 변수들과 상수들의 이름은 모두 대문자로 쓰고 각 단어는 언더바 ("_")로 분리한다. -** Variables**
- 변수 이름의 첫번째 문자는 소문자여야 한다.
- 언더바 또는 달러 표시 문자로 시작하는 것이 허용 되기는 하지만, 사용하지 말자.
- 짧지만 의미있게 짓는다.
- 변수의 사용 의도를 알 수 있도록 의미적으로 짓는다.
- 한문자로만 이루어진 변수는 암시적으로만 사용하고 버릴 변수를 제외하고는 피한다.
- 임시 변수의 이름은 integer는 i,j,k,m,n 을 사용하고 character는 c,d,e를 사용한다.
- ETC
- DB 테이블: lower_snake_case
- ENUM, 상수: Upper_snake_case
- 컬렉션(Collection): 복수형을 사용하거나 컬렉션을 명시한다. (Ex. userList, users, userMap)
- LocalDateTime: 접미사에 Date를 붙인다.
git commit -m "feat(#8) : 앱 설치 플로팅 배너 추가"
feat: 새로운 기능 추가fix: 버그 수정chore: 빌드 업무, 패키지 매니저, 라이브러리, dependencies 설정docs: 문서 수정 - README.md, .github, ..etcdesign: 사용자 UI 디자인 변경 - CSSstyle: 기능 수정 없는 코드 스타일 변경refactor: 코드 리팩터링test: 테스트 코드, 리펙토링 테스트 코드 추가ci: ci 설정 파일 수정perf: 성능 개선rename: 파일 혹은 폴더명 변경
-
master: 출시 가능한 프로덕션 코드의 브랜치 -
feature: 기능을 개발하는 브랜치 -
hotfix: 출시 버전에서 발생한 버그를 수정하는 브랜치브랜치 네이밍 :
feat/이슈번호