1분반-ODISS

프로젝트 개요

기술개발 과제

국문 : OCR 모델에 기초한 시니어 복약지도 에이전트 시스템

영문 : OCR based DUR Instruction Senior Service

과제 팀명

ODISS

지도교수

최혁 교수님

개발기간

2026년 3월 ~ 2026년 6월 (총 4개월)

구성원 소개

서울시립대학교 자유전공학부·과 2023890052 이재석(팀장)

서울시립대학교 컴퓨터과학부·과 2021920055 정현기

서울시립대학교 컴퓨터과학부·과 2022920042 유재휘

서울시립대학교 컴퓨터과학부·과 2023920058 주현우

서론

개발 과제의 개요

개발 과제 요약

본 개발 과제는 OCR 모델에 기초한 시니어 복약지도 에이전트 시스템인 ODISS를 구축하는 것을 목표로 한다. ODISS는 처방전 또는 복약 관련 정보를 자동으로 인식하고, 사용자가 이해하기 쉬운 방식으로 복약 안내를 제공하는 AI 기반 복약지도 서비스이다.

사용자는 처방전 사진, 복약 관련 질문, 음성 명령 등을 웹 또는 음성 인터페이스를 통해 입력할 수 있다. 시스템은 OCR을 이용하여 처방전 이미지에서 약품명, 용량, 복용 횟수, 투약 일수 등 핵심 정보를 추출하고, 이를 구조화하여 데이터베이스에 저장한다. 이후 DUR API와 LLM 기반 추론 엔진을 활용하여 병용금기, 중복 복용, 복용 주의사항 등 복약 안전성과 관련된 정보를 검토한다.

ODISS는 단순한 챗봇이 아니라, OCR 인식, 복약 정보 구조화, DUR API 연동, LLM 추론, 복용 기록 저장, 문서화, 음성 응답 기능을 하나의 서비스 흐름으로 연결하는 복약 중심 AI 에이전트 시스템이다. 최종적으로 시니어와 만성질환자가 자신의 복약 정보를 보다 쉽게 이해하고 관리할 수 있도록 돕고, 보호자 또는 가족이 복용기록과 안내 내용을 체계적으로 확인할 수 있는 복약관리 서비스를 구현하는 것을 목표로 한다.

초기 설계에서는 AI 스피커 형태의 하드웨어 기반 서비스를 고려하였다. 로컬 에이전트는 STT, OCR, TTS 기능을 담당하고, 서버 에이전트는 복약 정보 추론, 도구 호출, 기록 관리, 응답 생성을 담당하는 구조로 설계하였다. 하지만, 실제 사용자 테스트와 시연 가능성을 높이기 위해 웹 인터페이스와 모바일 앱 인터페이스를 함께 활용하는 방향으로 확장하였다.

개발 과제의 배경

우리 사회는 빠르게 고령화되고 있으며, 고령자와 만성질환자의 장기 복약 관리 문제는 점점 중요해지고 있다. 고혈압, 당뇨, 심혈관 질환 등 만성질환을 가진 사용자는 여러 약을 장기간 복용하는 경우가 많으며, 복용 시간이나 복용 방법을 놓치거나 헷갈리는 문제가 발생할 수 있다. 특히 시니어 사용자의 경우 처방전이나 약봉투에 적힌 정보를 직접 이해하기 어렵고, 여러 병원이나 약국에서 받은 약을 함께 복용하면서 중복 복용이나 병용금기 위험이 발생할 가능성도 존재한다.

기존 복약관리 방식은 보호자, 가족, 의료진의 지속적인 개입에 의존하는 경우가 많다. 그러나 보호자나 의료 인력이 항상 사용자의 복약 상황을 확인하기는 어렵고, 사용자의 기억에만 의존하는 방식은 누락이나 오복용 문제를 완전히 방지하기 어렵다. 또한 일반적인 생성형 AI 서비스는 복약 분야에서 정확한 근거 없이 답변을 생성할 수 있으며, 의료적 판단과 정보 제공의 경계가 불명확해질 위험이 있다.

ODISS는 이러한 문제를 해결하기 위해 처방전 OCR, DUR API 기반 사실 검증, LLM 기반 자연어 응답을 결합한다. 사용자는 복잡한 약물 정보를 직접 입력하지 않고도 처방전 사진이나 음성 질문을 통해 복약 정보를 등록하고 확인할 수 있다. 시스템은 OCR 결과를 구조화하고, DUR API를 통해 복약 안전성과 관련된 근거를 확인한 뒤, 시니어가 이해하기 쉬운 문장으로 안내한다.

또한 본 프로젝트는 단순히 AI가 답변을 생성하는 것을 넘어, 복용기록 저장과 문서화 기능을 포함한다. 이를 통해 일회성 질의응답에 그치지 않고, 사용자별 복약 이력을 지속적으로 관리하는 서비스로 확장될 수 있다. 이러한 구조는 시니어의 복약 안전성을 높이고, 보호자의 돌봄 부담을 줄이며, 향후 의료·헬스케어 서비스와 연계될 수 있는 기반이 된다.

개발 과제의 목표 및 내용

본 개발 과제의 목표는 OCR과 AI 에이전트 기술을 활용하여 실제 활용 가능한 시니어 복약지도 서비스를 구현하는 것이다. 이를 위해 시스템은 처방전 이미지 인식, 복약 정보 구조화, DUR API 연동, LLM 기반 추론, 음성 대화, 기록 저장, 문서화 기능을 포함하도록 설계하였다.

첫째, 처방전 이미지를 입력받아 약품명, 용량, 복용 횟수, 투약 일수 등 복약지도에 필요한 핵심 정보를 정확하게 추출하는 OCR 기반 인식 기능을 구현한다. OCR 결과는 단순 텍스트가 아니라 이후 DUR 조회와 복약 상담에 활용될 수 있도록 구조화된 데이터 형태로 저장한다.

둘째, OCR로 수집된 약물 정보와 사용자의 복약 관련 질문을 바탕으로 DUR API를 연동한다. 이를 통해 병용금기, 중복 복용, 복용 주의사항 등 복약 안전성과 관련된 정보를 확인하고, LLM이 임의로 추측하지 않고 공신력 있는 데이터에 기반하여 응답하도록 한다.

셋째, LLM 기반 에이전트를 통해 시니어가 이해하기 쉬운 복약지도 문장을 제공한다. 의료적 진단이나 처방을 직접 수행하는 것이 아니라, 복약 정보 전달과 주의 환기, 필요 시 전문가 상담 권고를 제공하는 방식으로 안전성을 확보한다.

넷째, 복용기록 저장과 문서화 기능을 구현한다. 사용자의 복약 정보, 질의응답 내용, 복약 안내 결과를 저장하고, 필요 시 PDF 또는 보고서 형태로 정리하여 보호자나 사용자에게 제공할 수 있도록 한다. 이를 통해 ODISS는 단순한 질의응답 도구가 아니라 지속적인 복약관리 체계로 동작할 수 있다.

다섯째, 웹, 음성인식 스피커, 모바일 환경에서 사용할 수 있는 프로토타입을 구현한다. FastAPI 기반 서버와 로컬 에이전트 구조를 통해 OCR, STT, TTS, LLM 추론, DUR Tool 호출이 연결되도록 하며, 사용자가 실제로 말하고 확인할 수 있는 서비스 흐름을 구성한다.

4월에는 DUR API Wrapper 개발, MCP 서버 및 LLM 에이전트 시스템 설계, OCR 모델 테스트, 프롬프트 엔지니어링, LLM 데이터셋 개발을 진행한다. 이 단계에서는 OCR 결과가 약품 정보로 구조화될 수 있는지 확인하고, LLM이 DUR API를 올바르게 호출할 수 있도록 도구 호출 구조를 설계한다. 또한 로컬 에이전트와 AI 서버 사이의 JSON 기반 통신 구조를 구체화한다.

5월에는 Docker 서버 시스템 배포 준비, LLM 에이전트 시스템 배포화, 프롬프트 엔지니어링 테스트, 데이터 추론 훈련, 프로젝트 통합 및 연결 작업을 수행한다. 이 단계에서는 개별 모듈을 하나의 서비스 흐름으로 연결하고, 처방전 입력부터 복약 질의응답, 기록 저장까지 이어지는 시나리오를 테스트한다. 또한 제한된 GPU와 메모리 환경에서 시스템이 안정적으로 동작할 수 있도록 양자화와 메모리 최적화 가능성을 검토한다.

6월에는 기능 구현 테스트, 알파 테스트 출시, 기능 보완 및 유지보수, 논문 집필, 사용자 테스트 반복, 프로젝트 및 데이터셋 공개를 진행한다. 최종 단계에서는 웹 및 모바일 인터페이스를 통해 실제 사용 흐름을 시연하고, 복약지도 AI 엔진의 정확성, 안정성, 사용성, 개인정보 보호 수준을 종합적으로 점검한다.

구성원 및 추진체계

ODISS 팀은 서버 및 에이전트 설계, OCR 테스트, DUR API 개발, 프롬프트 엔지니어링, 데이터셋 개발, 배포 및 테스트 업무를 나누어 수행한다. 전체 추진체계는 로컬 에이전트와 AI 서버를 병렬적으로 개발한 뒤, JSON 기반 입출력 프로토콜을 통해 통합하는 방식으로 구성된다.

팀장은 전체 일정 수립과 진행 상황 점검을 담당하며, MCP 서버 및 LLM 에이전트 시스템 설계, LLM 데이터셋 개발, 추론 훈련, 시스템 배포화, 프로젝트 통합 및 연결을 총괄한다. 또한 알파 테스트와 사용자 테스트, 논문 집필 과정에도 참여하여 전체 산출물의 방향성을 관리한다.

OCR 및 배포·테스트 담당자는 처방전 OCR 모델이 약품명, 용량, 복용 횟수, 투약 일수 등 핵심 정보를 정확히 추출하는지 테스트한다. 이후 Docker 서버 시스템 배포 준비와 기능 구현 테스트를 수행하고, 사용자 테스트 반복 및 최종 산출물 정리에 참여한다.

DUR API 및 프롬프트 담당자는 DUR API Wrapper 개발을 수행하고, LLM 에이전트가 복약 관련 질의에서 적절한 도구를 호출할 수 있도록 프롬프트 엔지니어링을 진행한다. 이후 프롬프트 테스트와 알파 테스트 출시, 기능 보완 및 유지보수에 참여한다.

데이터셋 및 추론 담당자는 LLM 에이전트 데이터셋 개발과 데이터 추론 훈련을 담당한다. 또한 DUR API Wrapper 개발과 유지보수 업무에도 참여하여 시스템이 실제 복약 시나리오에서 안정적으로 동작할 수 있도록 지원한다.

추진체계 측면에서 ODISS는 기능별 모듈 개발 후 통합하는 방식으로 진행된다. OCR 모듈은 처방전 이미지에서 약물 정보를 추출하고, DUR Tool은 복약 안전성 검증을 수행하며, 추론 엔진은 사용자 질의를 분석하고 필요한 도구 호출을 계획한다. 대화 엔진은 최종 응답을 시니어가 이해하기 쉬운 형태로 정리하고, 로컬 에이전트는 STT와 TTS를 통해 사용자와 상호작용한다. 이와 같은 역할 분담을 통해 각 구성요소가 독립적으로 개발되면서도 최종적으로 하나의 복약지도 서비스로 통합될 수 있도록 한다.

설계

설계사양

제품의 요구사항

ODISS는 시니어와 만성질환자가 복약 정보를 쉽게 등록하고, 안전한 복약 안내를 받을 수 있도록 하는 OCR 기반 복약지도 AI 에이전트 시스템이다. 따라서 제품의 요구사항은 단순한 챗봇 응답을 제공하는 수준이 아니라, 처방전 인식, 복약 정보 구조화, DUR API 연동, 음성 대화, 기록 저장, 안전성 검증, 실시간 응답성까지 함께 만족해야 한다.

처방전 및 약봉투 이미지 인식

ODISS는 사용자가 촬영한 처방전 또는 약봉투 이미지에서 약품명, 용량, 복용 횟수, 투약 일수 등 복약지도에 필요한 핵심 정보를 자동으로 추출할 수 있어야 한다. OCR 결과는 단순 텍스트로만 남는 것이 아니라, 이후 복약 안내와 DUR API 연동에 활용할 수 있는 구조화된 데이터 형태로 저장되어야 한다.

약물 정보 구조화

OCR로 추출한 정보는 약품명, 성분명, 용량, 복용 횟수, 복용 기간, 투약 일수 등으로 분리되어야 한다. 약품명은 OCR 과정에서 오인식될 수 있으므로 공백, 괄호, 특수문자, 유사 문자열 등을 정리하는 정규화 과정이 필요하다. 이후 의약품 정보 데이터와 비교하여 실제 약물 항목과 매칭하고, DUR API 조회에 사용할 수 있는 형태로 변환해야 한다.

DUR API 기반 복약 안전성 확인

시스템은 병용금기, 중복 복용, 복용 주의사항과 같은 복약 안전성 정보를 확인할 수 있어야 한다. 이를 위해 공신력 있는 DUR API를 연동하여 단순 생성형 AI의 추측이 아니라 근거 기반의 복약 안내를 제공해야 한다. 사용자가 “이 약 같이 먹어도 돼?” 또는 “아까 먹은 약 또 먹어도 돼?”와 같이 질문하면, 시스템은 저장된 약물 정보와 사용자의 질문을 바탕으로 필요한 안전성 검증 절차를 수행해야 한다.

음성 기반 상호작용

사용자는 복잡한 입력 과정 없이 음성으로 질문하고 답변을 들을 수 있어야 한다. 따라서 STT와 TTS 기능을 포함하여 “오늘 약 뭐 먹어?”, “이 약 같이 먹어도 돼?”, “처방전 사진 찍을게”와 같은 자연스러운 발화를 처리할 수 있어야 한다. 특히 시니어 사용자는 문장을 완전하게 말하지 않거나 맥락을 생략할 수 있으므로, 짧고 불완전한 발화도 대화 맥락에 따라 처리할 수 있어야 한다.

의료행위 방지

ODISS는 직접적인 진단이나 처방을 수행하지 않고, 복약 보조와 정보 제공의 범위 안에서 동작해야 한다. 즉, 의료행위를 대체하는 것이 아니라 사용자의 복약 이해를 돕고, 필요할 경우 약사나 의료진 상담을 권고하는 방식으로 안전성을 확보해야 한다. 복약 관련 질문에 대해 단정적인 치료 지시를 내리지 않고, 근거 기반 정보 제공과 주의 안내 중심으로 응답해야 한다.

복약 기록 저장

사용자의 약물 정보, 질의응답 결과, 복약 관련 기록은 장기적으로 관리될 수 있어야 한다. 복약 기록은 단순히 한 번 답변하고 끝나는 것이 아니라, 이후 사용자가 다시 질문하거나 보호자가 확인할 수 있도록 저장되어야 한다. 또한 필요 시 문서화하여 사용자 또는 보호자가 복약 상담 내용과 복약 이력을 확인할 수 있도록 설계해야 한다.

실시간 응답성

사용자가 음성 질의나 처방전 촬영을 입력한 뒤 지나치게 오래 기다리지 않도록, 시스템은 첫 응답과 최종 응답을 가능한 한 빠르게 제공해야 한다. OCR 처리, DUR API 호출, LLM 추론, TTS 출력은 각각 시간이 소요될 수 있으므로, 응답이 지연되는 경우 고정멘트 엔진을 통해 “약 정보를 확인하고 있어요”와 같은 안내를 먼저 제공할 수 있어야 한다.

제한된 하드웨어 환경 대응

초기 설계에서는 Jetson 계열 보드 기반 AI 스피커형 환경을 고려하였으므로, 제한된 GPU 및 메모리 환경에서도 OCR, STT, TTS, 추론 기능이 과도한 지연 없이 수행될 수 있어야 한다. 이를 위해 경량 모델 사용, 모델 양자화, 메모리 최적화, 서버 연동 구조가 필요하다.

개인정보 보호

처방전, 사용자 복약 기록, 상담 이력은 민감한 건강정보에 해당하므로, 저장과 전송 과정에서 불필요한 개인정보 노출을 줄이고 안전하게 관리할 수 있어야 한다. 사용자의 이름, 나이, 복약 정보, 처방전 정보는 접근 권한이 있는 사용자 또는 보호자만 확인할 수 있어야 하며, 외부 API 호출 시에도 필요한 정보만 최소한으로 전달해야 한다.

웹 및 모바일 인터페이스 지원

하드웨어 데모만으로는 서비스 흐름이 시각적으로 잘 보이지 않는 한계가 있으므로, 사용자의 발화, AI 응답, 카메라 촬영, 기록 조회 흐름을 확인할 수 있는 웹 및 모바일 인터페이스가 필요하다. 웹 인터페이스는 기능 검증과 사용자 테스트를 위한 환경으로 사용하고, 모바일 앱은 실제 사용자가 스마트폰에서 복약지도 서비스를 이용할 수 있도록 하는 확장 방향으로 설계한다.

설계 사양

ODISS의 전체 설계는 로컬 에이전트, AI 서버, 외부 도구, 사용자 인터페이스, 기록 저장 계층으로 구성된다. 로컬 에이전트는 사용자의 입력과 출력을 담당하고, AI 서버는 질의 분석, 추론, 도구 호출, 기록 관리와 같은 핵심 처리를 담당한다. 두 계층은 JSON 기반의 프로토콜로 통신하도록 설계한다.

로컬 에이전트

로컬 에이전트는 Wake-a-word, STT, OCR, TTS 기능을 포함한다. Wake-a-word 모듈은 사용자의 호출어를 감지하여 시스템을 활성화하고, STT 모듈은 사용자의 음성 발화를 텍스트로 변환한다. OCR 모듈은 처방전 또는 약봉투 이미지에서 약품명, 용량, 복용 횟수, 투약 일수 등의 정보를 추출한다. TTS 모듈은 최종 응답을 음성으로 출력하여 사용자가 화면을 보지 않고도 안내를 받을 수 있도록 한다.

AI 서버

AI 서버는 FastAPI 기반으로 구성하며, 추론 엔진, 대화 엔진, 메모리 엔진, 도구 호출 모듈을 포함한다. 추론 엔진은 사용자의 질의 의도를 파악하고, OCR 결과와 복약 정보를 분석하여 필요한 작업을 판단한다. 대화 엔진은 이를 사용자가 이해하기 쉬운 문장으로 정리하여 최종 응답을 생성한다. 메모리 엔진은 사용자의 복약 기록, 상담 이력, 현재 대화 흐름을 관리한다.

DUR API 연동

복약 안전성 검증을 위해 DUR API Wrapper를 포함한 도구 호출 구조를 설계한다. 사용자의 질문이 병용금기, 중복 복용, 복용 주의사항과 관련될 경우, LLM은 필요한 약물 정보를 정리한 뒤 DUR API를 호출하고 그 결과를 바탕으로 응답을 생성한다. 이 구조를 통해 LLM의 환각 가능성을 줄이고 근거 기반 복약 안내를 제공할 수 있다.

메모리 엔진

메모리 엔진은 사용자의 장기 복약 기록과 현재 대화 맥락을 분리하여 관리한다. 영구 기억에는 등록된 약물 정보, 복약 기록, 과거 상담 이력, 사용자 기본 정보가 저장된다. 휘발성 메모리에는 현재 대화에서 필요한 임시 정보, 직전 질문, 현재 진행 중인 작업 상태가 저장된다. 이를 통해 ODISS는 사용자의 이전 복약 정보를 참고하면서도 현재 대화 흐름을 유지할 수 있다.

대화 엔진

대화 엔진은 추론 결과를 시니어가 이해하기 쉬운 자연어 응답으로 변환한다. 복약 관련 정보는 전문용어가 많기 때문에, 대화 엔진은 긴 설명보다 짧고 명확한 안내 문장을 생성해야 한다. 예를 들어 “이 약은 함께 복용하면 위험할 수 있으니 약사에게 확인하세요”처럼 행동 지향적인 안내를 제공하는 것이 적절하다.

프론티어 LLM 검증 엔진

프론티어 LLM 검증 엔진은 내부 추론 모델의 판단 결과를 재검토하는 역할을 수행한다. 복약 안전성과 관련된 응답은 잘못될 경우 위험할 수 있으므로, 고위험 질문이나 불확실성이 높은 질문에 대해서는 외부 고성능 LLM 또는 검증 모듈을 통해 응답을 다시 확인할 수 있도록 한다. 다만 개인정보 보호를 위해 외부 검증 단계에서는 필요한 정보만 최소화하여 전달한다.

기록 저장 및 문서화

시스템은 복약 기록 저장 및 문서화 기능을 포함한다. 사용자가 등록한 약물 정보, 복약 관련 질의응답, 복용 이력, OCR 추출 결과를 데이터베이스에 저장하고, 필요 시 이를 요약하여 문서 형태로 출력할 수 있도록 설계한다. 이는 ODISS가 일회성 질의응답에 그치지 않고 지속적인 복약관리 서비스로 확장될 수 있도록 하는 핵심 요소이다.

사용자 인터페이스

사용자 인터페이스는 웹, 모바일 앱, 음성 스피커 환경을 모두 고려한다. 웹 인터페이스는 사용자 발화와 AI 응답, 카메라 촬영, OCR 등록 흐름을 시각적으로 확인할 수 있는 테스트 및 시연 환경으로 사용한다. 모바일 앱은 실제 사용자가 스마트폰을 통해 복약지도 서비스를 이용할 수 있도록 하는 확장 방향이며, 음성 스피커 환경은 초기 하드웨어 기반 프로토타입 구현을 위한 인터페이스로 활용한다.

평가 기준

완료작품의 평가는 OCR 인식 정확도, 약물 정보 구조화 정확도, 복약 안전성 판단 정확도, 응답 품질, 처리 속도, GPU 메모리 압축 효과, 시스템 안정성, 기록 저장 및 문서화 기능, 사용자 시나리오 수행도, 개인정보 보호 수준을 중심으로 수행한다. OCR 정확도는 약품명, 용량, 횟수, 일수 등 핵심 필드 추출 기준으로 평가하며, 복약 안전성 판단은 DUR API 결과와 시스템 응답의 일치 여부를 바탕으로 검증한다. 처리 속도는 처방전 입력부터 결과 출력까지의 End-to-End 시간을 기준으로 측정하고, 시스템 안정성은 반복 실행과 예외 상황 테스트를 통해 확인한다.

개념설계안

ODISS의 개념설계안은 사용자의 음성 및 이미지 입력을 로컬 에이전트가 수집하고, AI 서버가 이를 분석하여 복약지도 응답을 생성한 뒤 다시 사용자에게 전달하는 구조이다. 전체 시스템은 로컬 에이전트, AI 서버, 외부 도구, 메모리 저장소, 사용자 인터페이스로 구성된다.

로컬 에이전트는 AI 스피커 또는 모바일 환경에서 사용자와 직접 상호작용하는 계층이다. 평상시에는 Wake-a-word 엔진이 음성을 대기 상태로 감지하고, 호출어가 인식되면 STT 모듈이 사용자의 발화를 텍스트로 변환한다. 사용자가 처방전이나 약봉투를 촬영하면 OCR 모듈이 이미지에서 약품명, 용량, 복용 횟수, 투약 일수 등의 정보를 추출한다. 최종 응답은 TTS 모듈을 통해 음성으로 출력되거나, 웹·앱 화면에 텍스트로 표시된다.

AI 서버는 ODISS의 핵심 판단을 담당한다. 서버는 로컬 에이전트 또는 웹·앱 인터페이스에서 전달받은 OCR 결과와 사용자 질의를 분석한다. 이후 추론 엔진이 사용자의 의도를 분류하고, DUR 조회가 필요한지, OCR 재촬영이 필요한지, 복약 기록을 저장해야 하는지, 단순 대화 응답으로 처리할 수 있는지를 판단한다.

고정멘트 엔진은 서버가 최종 응답을 준비하는 동안 사용자에게 짧은 안내 문구를 제공하는 역할을 한다. 예를 들어 복잡한 복약 안전성 판단이나 외부 API 호출이 필요한 경우, 사용자가 아무 반응 없이 기다리지 않도록 “확인하고 있어요”, “약 정보를 찾아보고 있어요”와 같은 안내를 먼저 출력한다. 이를 통해 시스템의 실시간 응답성을 보완하고 사용자 불편을 줄인다.

DUR Tool은 복약 안전성 검증을 위해 사용된다. LLM은 사용자의 자연어 질문을 바로 답변하지 않고, 필요한 경우 DUR API가 이해할 수 있는 입력 형식으로 변환한다. 이후 병용금기, 중복 복용, 복용 주의사항 등 외부 근거 데이터를 조회하고, 그 결과를 바탕으로 응답을 생성한다. 이를 통해 LLM의 환각 가능성을 줄이고, 근거 기반 복약 안내를 제공한다.

메모리 엔진은 사용자의 장기 복약 기록과 현재 대화 맥락을 분리하여 관리한다. 영구 기억에는 사용자 정보, 복용 약물, 과거 복약 상담 기록, 복용기록이 저장된다. 휘발성 메모리에는 현재 대화에서 사용자가 방금 말한 내용, 직전 질문, 현재 진행 중인 작업 상태가 저장된다. 이러한 구조를 통해 ODISS는 이전 복약 기록을 참고하면서도 현재 대화의 흐름을 유지할 수 있다.

추론 엔진은 현재 사용자의 요청을 분석하고 필요한 작업을 설계한다. 예를 들어 사용자가 “이 약 같이 먹어도 돼?”라고 말하면, 추론 엔진은 해당 질문이 복약 안전성 판단에 해당한다고 분류하고, 현재 저장된 약물 정보와 질문 속 약물 정보를 비교한 뒤 DUR Tool 호출 여부를 결정한다. 사용자가 “처방전 사진 찍을게”라고 말하면 OCR 촬영 workflow로 연결한다.

대화 엔진은 최종 응답을 사용자에게 전달하기 쉬운 문장으로 변환한다. ODISS의 사용자는 시니어일 수 있으므로, 응답은 길고 복잡한 의학 설명보다 짧고 명확한 복약 안내 문장으로 제공되어야 한다. 또한 시스템은 직접적인 진단이나 처방을 하지 않고, 필요할 경우 약사 또는 의료진 상담을 권고하는 방식으로 응답한다.

프론티어 LLM 검증 엔진은 내부 추론 결과를 재검토하는 역할을 수행한다. 내부 모델이 생성한 판단 결과와 근거를 외부 고성능 LLM 또는 검증 모듈이 다시 확인하여, 복약 관련 응답의 신뢰성을 높인다. 단, 이 과정에서도 개인정보 보호와 의료행위 방지 원칙을 지키도록 프롬프트와 출력 형식을 제한한다.

ODISS의 개념적 처리 흐름은 다음과 같다.

1단계: 사용자가 음성 또는 웹·앱 화면을 통해 질의한다.
2단계: 로컬 에이전트 또는 웹·앱 인터페이스가 음성, 텍스트, 이미지 입력을 수집한다.
3단계: OCR 또는 STT 모듈이 입력을 구조화한다.
4단계: AI 서버가 사용자 의도와 복약 정보를 분석한다.
5단계: 추론 엔진이 필요한 도구 호출을 계획한다.
6단계: DUR API, 기록 저장소, 외부 검증 엔진을 호출한다.
7단계: 대화 엔진이 시니어 친화형 응답을 생성한다.
8단계: 사용자는 음성 또는 화면으로 복약 안내를 확인한다.
9단계: 필요한 경우 복용기록 또는 상담기록이 저장된다.

이론적 계산 및 시뮬레이션

ODISS는 여러 AI 모델과 외부 API를 연결하는 시스템이므로, 실제 구현 전에 메모리 사용량, 추론 시간, OCR 성능, LLM 성능, 안전성 판단 정확도 등을 이론적으로 비교하고 시뮬레이션해야 한다. 특히 제한된 하드웨어 환경에서 OCR, STT, TTS, LLM 추론이 동시에 동작해야 하므로, 단순히 모델 성능만 보는 것이 아니라 실행 가능성과 응답 시간을 함께 고려해야 한다.

KV cache 양자화 및 메모리 압축 검토

LLM은 대화가 길어질수록 KV cache 사용량이 증가하고, 제한된 GPU 메모리 환경에서는 OOM 문제가 발생할 수 있다. 따라서 TurboQuant와 같은 KV cache 양자화 기법을 적용하여 메모리 사용량을 줄이고 추론 속도를 개선할 수 있는지 비교한다. 이론적 계산에서는 양자화 전후의 메모리 사용량, 토큰 처리 속도, 응답 품질 저하 여부를 함께 평가한다.

OCR 모델 성능 검토

ODISS는 처방전 이미지에서 약품명과 복용 정보를 인식해야 하므로, 일반적인 OCR보다 문서 구조 파싱과 한국어 약학 용어 인식이 중요하다. 경량 OCR 모델 후보는 파라미터 수, 문서 파싱 벤치마크 성능, 한국어 인식 가능성, 로컬 실행 가능성을 기준으로 비교한다. OCR 성능은 단순 문자 인식률뿐 아니라 약품명, 용량, 복용 횟수, 투약 일수 등 실제 복약지도에 필요한 필드가 정확히 추출되는지를 기준으로 평가한다.

추론용 LLM 적합성 검토

ODISS는 단순 대화보다 복약 질의 분석, 도구 호출 계획, DUR API 결과 해석, 시니어 친화형 응답 생성이 중요하다. 따라서 추론용 모델은 도구 사용 능력, 긴 문맥 처리 능력, 로컬 실행 가능성, 응답 속도, 복약 관련 질문 처리 성능을 기준으로 비교한다. Qwen 계열과 같은 경량 모델은 제한된 환경에서 실행 가능하다는 장점이 있으나, 의료·복약 영역에서 정확성을 보장하기 위해 외부 검증 엔진과 DUR API 연동이 필요하다.

프론티어 LLM 검증 가능성

내부 추론 모델의 응답을 그대로 사용자에게 전달하면 환각이나 과도한 단정이 발생할 수 있다. 따라서 고성능 외부 LLM을 검증용으로 활용하여 내부 판단 결과가 적절한지 재검토할 수 있다. 단, 모든 요청을 외부 API에 의존하면 비용과 개인정보 문제가 발생할 수 있으므로, 외부 검증은 고위험 복약 질문이나 불확실성이 높은 경우에 제한적으로 사용하는 방향이 적절하다.

단계별 inference time 분석

ODISS의 전체 응답 시간은 STT, OCR, 약품명 정규화, DUR API 호출, LLM 추론, 검증 엔진 호출, TTS 출력 시간을 모두 합친 결과이다. 따라서 각 단계를 분리하여 시간을 측정하고, 병목 구간을 확인해야 한다. 예를 들어 OCR 처리 시간이 길면 이미지 전처리나 모델 경량화가 필요하고, LLM 추론 시간이 길면 양자화, 캐시 최적화, 프롬프트 길이 제한이 필요하다.

평가 항목별 목표

OCR 인식 정확도는 처방전 이미지에서 약품명, 용량, 복용 횟수, 투약 일수 등 핵심 필드가 정확히 추출되는지를 기준으로 평가한다. 목표는 핵심 항목 기준 95% 이상이다.

약물 정보 구조화 정확도는 OCR 결과가 데이터베이스 필드에 올바르게 저장되는지를 기준으로 평가한다. 필수 항목 누락, 오분류, 잘못된 필드 매핑 여부를 점검하며, 목표는 99% 이상이다.

복약 안전성 판단 정확도는 DUR 기준 정보와 시스템 판단 결과를 비교하여 평가한다. 병용금기, 중복 복용, 복용 주의 사례를 기준으로 판단 정확도 95% 이상과 치명적 오판 0건을 목표로 한다.

응답 품질 및 이해용이성은 전문가와 일반 사용자 평가를 통해 확인한다. 복약지도 문장의 명확성, 쉬운 표현 사용 여부, 환각 여부를 점검하며, 평균 만족도 4.3점 이상을 목표로 한다.

처리 속도는 처방전 입력부터 결과 출력까지의 End-to-End 시간을 측정한다. OCR 처리, API 검증, 응답 생성 전체 구간을 포함하여 평균 응답시간 15초 이내를 목표로 한다.

GPU 메모리 압축 효과는 TurboQuant와 같은 양자화 알고리즘 적용 전후의 응답시간 단축과 메모리 감축 효과를 비교한다. 제한된 하드웨어 환경에서 모델이 안정적으로 동작할 수 있는지를 확인한다.

시스템 안정성은 반복 실행과 예외 입력 테스트를 통해 확인한다. 잘못된 입력, 누락 입력, 서버 지연 상황을 포함하여 전체 성공률 99% 이상을 목표로 한다.

기록 저장 및 문서화 기능은 복용기록 저장, 조회, 문서 생성 기능의 정상 동작 여부를 확인한다. 저장, 조회, PDF 생성 성공 여부를 평가하며 기능 성공률 99% 이상을 목표로 한다.

사용자 시나리오 수행도는 처방전 입력, 질문, 결과 확인, 기록 조회까지 이어지는 실제 사용 흐름을 기준으로 평가한다. 전체 시나리오 성공률 99% 이상을 목표로 한다.

개인정보 보호 수준은 저장 데이터와 외부 전송 데이터의 민감정보 처리 여부를 점검한다. 식별정보 분리, 불필요한 개인정보 노출 방지, 접근 권한 관리를 기준으로 개인정보 노출 0건을 목표로 한다.

이러한 계산과 시뮬레이션은 단순히 모델 성능을 비교하기 위한 것이 아니라, 실제 사용자 환경에서 ODISS가 안정적으로 동작할 수 있는지를 확인하기 위한 과정이다. 특히 복약 관련 시스템은 응답 속도뿐 아니라 안전성, 신뢰성, 개인정보 보호가 중요하므로, 각 요소를 동시에 고려하여 최종 설계안을 선택한다.

상세설계 내용

ODISS의 상세설계는 로컬 에이전트, AI 서버, 도구 호출 계층, 메모리 저장 계층, 사용자 인터페이스, 하드웨어 구성으로 나누어 설명할 수 있다.

로컬 에이전트 설계

로컬 에이전트는 사용자와 직접 연결되는 입출력 계층이다. 로컬 에이전트는 Wake-a-word 감지 모듈, STT 모듈, OCR 처리 모듈, TTS 출력 모듈로 구성된다. 평상시에는 Wake-a-word 모듈이 음성을 대기 상태로 감시하고, 호출어가 감지되면 STT 모듈이 사용자의 발화를 텍스트로 변환한다. 사용자가 처방전이나 약봉투를 촬영하면 OCR 모듈이 이미지에서 약품명, 용량, 복용 횟수, 투약 일수 등의 정보를 추출한다. 최종 응답은 TTS 모듈을 통해 음성으로 출력되거나, 웹·앱 화면에 텍스트로 표시된다.

AI 서버 설계

AI 서버는 질의 해석, 추론, 도구 호출, 기록 관리를 담당한다. 서버는 FastAPI 기반으로 구성하며, 로컬 에이전트 또는 웹·앱 클라이언트로부터 JSON 형식의 요청을 받는다. 요청에는 사용자 발화, OCR 결과, 현재 대화 상태, 사용자 식별 정보, 필요한 경우 이미지 처리 결과가 포함된다. AI 서버는 이를 바탕으로 현재 요청이 OCR 촬영인지, 복약 질의인지, 복용기록 저장인지, 단순 대화인지 분류한다.

메모리 엔진 설계

메모리 엔진은 영구 기억과 휘발성 메모리로 분리한다. 영구 기억에는 사용자의 장기 복약 기록, 등록된 약물 정보, 복용 일정, 과거 상담 이력이 저장된다. 휘발성 메모리에는 현재 대화에서 필요한 임시 정보, 직전 질문, 진행 중인 workflow 상태가 저장된다. 예를 들어 사용자가 “아까 그 약 같이 먹어도 돼?”라고 질문했을 때, 시스템은 휘발성 메모리에서 직전 대화의 약물 정보를 확인하고, 영구 기억에서 현재 복용 중인 약물 목록을 불러와 판단에 활용한다.

추론 엔진 설계

추론 엔진은 사용자의 의도를 분류하고 필요한 작업을 계획한다. 추론 엔진의 기본 흐름은 의도 분류, 약물 정보 식별, 도구 호출 계획, 근거 수집, 응답 생성이다. 먼저 STT 또는 텍스트 입력을 바탕으로 사용자의 의도를 분류한다. 이후 현재 복용 약물 정보와 질문 대상 약물을 식별하고, DUR API 조회 또는 기록 저장이 필요한지 판단한다. 필요한 도구 호출 결과가 수집되면, 대화 엔진으로 전달하여 최종 응답을 생성한다.

DUR Tool 및 MCP 도구 호출 설계

DUR Tool과 MCP 도구 호출 모듈은 외부 정보를 조회하고 시스템 기능을 실행하는 중간 계층이다. DUR Tool은 병용금기, 중복 복용, 복용 주의사항을 확인하기 위해 사용된다. MCP 도구 호출 모듈은 LLM이 상황에 맞는 도구와 파라미터를 선택할 수 있도록 하며, DUR API, OpenAI API, 기록 저장 기능, OCR 재요청 기능 등을 연결한다. 이를 통해 ODISS는 단순 생성형 응답이 아니라 도구 기반 복약지도 응답을 제공할 수 있다.

대화 엔진 설계

대화 엔진은 사용자에게 전달되는 최종 문장을 생성한다. 대화 엔진은 복잡한 약물 정보를 시니어가 이해하기 쉬운 문장으로 정리한다. 예를 들어 “이 약은 같이 먹으면 안 됩니다”처럼 단정적인 표현이 필요한 경우와 “정확한 판단을 위해 약사나 의사에게 확인하세요”처럼 상담 권고가 필요한 경우를 구분한다. 또한 응답은 가능한 한 짧고 명확하게 유지하여 고령 사용자가 쉽게 이해할 수 있도록 한다.

프론티어 LLM 검증 엔진 설계

프론티어 LLM 검증 엔진은 내부 추론 결과의 안전성을 높이기 위해 사용된다. 복약 안전성과 관련된 질문은 잘못된 답변이 위험할 수 있으므로, 내부 모델의 판단을 외부 고성능 LLM 또는 검증 모듈이 재검토할 수 있도록 한다. 단, 이 과정에서 개인정보가 불필요하게 외부로 전달되지 않도록 입력 정보를 최소화하고, 민감정보 필터링을 적용한다.

사용자 인터페이스 설계

사용자 인터페이스는 웹, 모바일 앱, 음성 스피커 환경으로 구성한다. 웹 인터페이스는 사용자의 음성 발화와 AI 응답, 카메라 촬영 흐름을 화면에서 직접 확인할 수 있는 테스트 및 시연 환경으로 사용한다. 모바일 앱은 실제 사용자가 스마트폰에서 복약지도 기능을 사용할 수 있도록 하는 서비스 확장 방향이다. 음성 스피커 환경은 하드웨어 기반 복약 비서 형태를 실험하기 위한 로컬 에이전트 환경이다.

하드웨어 구성

하드웨어 구성은 Jetson 계열 개발 보드, Jabra Speak 510, ipTIME Home Camera, ipTIME 무선공유기를 중심으로 한다. Jetson 개발 보드는 로컬 에이전트의 OCR, STT, TTS 및 경량 추론 기능을 시연하기 위한 핵심 장치로 사용한다. Jabra Speak 510은 사용자 음성 입력과 시스템 음성 출력을 담당한다. ipTIME Home Camera는 처방전 촬영 및 객체 인식을 위한 영상 입력 장치로 사용하고, ipTIME 무선공유기는 IP 홈캠과 로컬 에이전트 간 RTSP 통신을 지원한다.

소프트웨어 통신 구조

로컬 에이전트와 AI 서버는 JSON 기반 입출력 프로토콜을 사용한다. 로컬 에이전트는 STT 결과, OCR 결과, 사용자 입력 상태, 장치 상태를 JSON 형태로 서버에 전송한다. 서버는 추론 결과, 다음 동작 명령, 사용자 응답 문장, TTS 출력 내용, 카메라 실행 여부, 기록 저장 여부 등을 다시 로컬 에이전트 또는 웹·앱 클라이언트에 전달한다.

전체 동작 흐름

ODISS의 전체 동작 흐름은 다음과 같다.

1단계: 사용자가 웹, 앱, 또는 음성 스피커를 통해 ODISS를 호출한다.

2단계: 사용자의 음성은 STT를 통해 텍스트로 변환된다.

3단계: 사용자가 처방전 촬영을 요청하면 카메라가 실행되고 OCR 모듈이 약물 정보를 추출한다.

4단계: OCR 결과와 사용자 발화는 JSON 형식으로 AI 서버에 전달된다.

5단계: AI 서버의 추론 엔진이 의도를 분석하고 필요한 도구 호출을 계획한다.

6단계: DUR Tool 또는 기록 저장 모듈이 호출된다.

7단계: 필요 시 프론티어 LLM 검증 엔진이 내부 판단을 재검토한다.

8단계: 대화 엔진이 시니어 친화형 응답을 생성한다.

9단계: 응답은 웹·앱 화면 또는 TTS 음성으로 사용자에게 전달된다.

10단계: 복용기록, 상담 결과, OCR 등록 정보는 메모리 엔진과 저장소에 기록된다.

안전성 설계

ODISS는 의료적 판단을 직접 수행하는 시스템이 아니라 복약 보조와 정보 제공을 위한 시스템이다. 따라서 응답 생성 시 직접적인 진단, 처방 변경, 복용 중단 지시를 하지 않도록 제한한다. 사용자가 위험 증상이나 과량 복용, 중복 복용 가능성을 언급하는 경우에는 일반 대화가 아니라 안전 응답으로 라우팅하고, 필요한 경우 의료진 또는 119 등 긴급 도움을 권고하는 방식으로 설계한다.

개인정보 보호 설계

처방전 이미지와 복약 기록은 민감한 건강정보이므로, 저장과 전송 과정에서 개인정보 보호가 중요하다. 시스템은 필요한 데이터만 저장하고, 외부 API 호출 시에는 불필요한 식별정보를 제거해야 한다. 또한 사용자 정보, 복약 기록, 상담 기록에 대한 접근 권한을 분리하여 보호자와 사용자, 관리자 권한을 구분해야 한다.

이와 같은 상세설계를 통해 ODISS는 처방전 OCR, DUR API 기반 검증, LLM 추론, 음성 대화, 복약 기록 저장, 웹·앱 인터페이스를 하나의 통합 서비스로 연결한다. 또한 의료행위를 직접 수행하지 않고, 복약 보조와 정보 제공을 중심으로 동작하도록 설계하여 안전성과 실용성을 함께 확보한다.

결과 및 평가

완료 작품의 소개

프로토타입 사진 혹은 작동 장면

내용

포스터

내용

완료작품의 평가

내용

향후계획

내용

특허 출원 내용

내용