헬스테크·디지털헬스케어 앱이 일반 앱보다 어려운 건 기능이 많아서가 아니라, 기능 하나하나가 서로 다른 제도에 걸리기 때문이에요. 크게 세 갈래예요. ① 디지털 치료기기(DTx)처럼 치료 효과를 표방하는 소프트웨어가 보험 급여 체계 안으로 들어오면, 그 앱은 의료기기 요건과 급여 청구 요건을 동시에 만족해야 해요. 둘 중 하나만 맞춰 놓으면 출시가 막히거나 정산이 막혀요. ② 비대면 진료의 전자처방은 누가 어떤 절차로 발행하느냐가 법으로 규율되는 영역이에요. 화면을 그리기 전에 현행 규정부터 확인해야 하고, 규정이 바뀌면 발행 흐름 전체가 영향을 받아요. ③ 웨어러블이 측정한 심박·심전도 같은 데이터를 단순 기록이 아니라 진단이나 판단에 쓰기 시작하면, 그 순간 의료기기 해당 여부 판정이 개발 일정 안으로 들어와요. 그래서 헬스테크 앱 하나에 의료법·의료기기법·개인정보보호법·전자서명법·약사법·국민건강보험법까지 6축이 한꺼번에 걸려요.
"앱 개발만 하는 외주 업체"에 맡겼다가 의료법·인허가·청구·웨어러블·원격진료 환자 모니터링이 따로 노는 상태로 시간을 잃는 패턴이 반복해서 관찰돼요. 개발과 인허가·청구를 각각 다른 곳에 따로 발주하면 두 축이 어긋난 채로 몇 달이 흘러가요. 인허가 요건이나 청구 요건이 개발이 끝난 뒤에 발견되면 화면 몇 개를 고치는 수준으로 끝나지 않고 데이터 구조부터 다시 짜야 해요. 그 재작업은 출시만 미루는 게 아니라 다음 투자 라운드 일정까지 밀어내요. 개발 착수 시점에 인허가 담당자와 청구 담당자가 같은 문서를 보고 있는지가 첫 번째 갈림길이에요.
일반 앱 개발사와 헬스테크 전문 파트너의 결정적 차이는 단순히 "의료에 대한 경험"이 아니에요. 다음 7가지 기준을 한 표에 묶어 평가해 보세요. 일곱 개 가운데 여러 항목이 견적서에서 확인되지 않으면 계약을 서두르지 마세요. 확인되지 않은 항목은 대부분 계약 뒤에 추가 비용이나 일정 지연이라는 형태로 다시 나타나요.
환자(개인정보)·의사(자격)·약사(약국 코드)·처방전(전자서명)·청구(공단 EDI)·웨어러블(센서 데이터)이 한 ERD에 들어가야 해요. 견적서에 "환자 테이블", "처방 테이블"만 있고 청구 EDI·약국 응답 ACK·요양급여 코드 매핑이 없으면 1차 컷이에요. 자가 체크: "환자 1명이 비대면 진료 → 전자처방 → 약국 픽업 → 공단 청구까지 한 흐름에서 어떤 테이블 몇 개가 움직이나요?" 답이 6개 미만이면 경험 부족이에요. 이 질문이 걸러내는 건 지식이 아니라 설계 순서예요. 청구와 약국 응답을 나중에 얹을 수 있다고 보는 팀은 이미 데이터 모델을 화면 기준으로 짜고 있는 거예요.
전자처방은 발행 주체·발행 시점·발행 내용이 나중에 증명돼야 하는 문서예요. 그래서 의사 본인의 전자서명, 발행자 본인확인, 발행 시점 기록, 내용 무결성 검증이 설계 단계에서 들어가 있어야 해요. 어떤 인증 수단을 쓸지, 보관은 얼마나 할지는 현행 법령과 고시가 정하는 범위 안에서 결정되니, 견적서에는 특정 서비스 이름이 아니라 "무엇을 어떻게 증명하는가"가 적혀 있어야 해요. 여기서 끝나지 않고 약국 측 수신 확인(ACK)·재발행 차단·법정 보관 기간 운영·통계용 비식별 보관까지 한 흐름으로 이어져요. 자가 체크: "전자처방 위변조 방지를 어떻게 했나요?" 단답이 "JWT"면 컷이에요. 로그인 토큰은 지금 접속한 사람을 확인하는 수단이지, 그 문서가 언제 누구에 의해 어떤 내용으로 발행됐는지를 증명하는 수단이 아니거든요.
혈압·혈당·수면·정신건강처럼 측정·진단·처방에 영향을 주는 기능은 의료기기 소프트웨어 해당 여부와 등급 판정이 걸려요. 등급은 제품 이름으로 정해지는 게 아니라 그 소프트웨어가 무엇을 하겠다고 표방하는지, 어떤 기능을 담는지에 따라 개별적으로 결정돼요. 그래서 같은 심전도 데이터를 써도 기록만 보여주는 앱과 이상 여부를 알려주는 앱은 판정이 갈릴 수 있어요. 판정이 붙으면 품질관리, 위험관리(ISO 14971), 소프트웨어 생명주기(IEC 62304), 형상관리 이력, 임상 근거 자료까지 외주사가 따라와야 출시까지 가요. 자가 체크: 포트폴리오에 의료기기 소프트웨어 출시 이력이 실제로 있는지 문서로 확인하세요. 위험관리·생명주기 문서와 형상관리 이력을 개발 중에 쌓아두지 않은 팀은 심사 단계에 가서 이미 끝난 코드를 놓고 문서를 소급 작성하게 되고, 그 소급 작업만큼 출시가 통째로 밀려요.
웨어러블은 백그라운드 동기화 권한·심박/ECG/SpO2/걸음수 단위 처리·플랫폼 데이터 정책 변경에 매우 약해요. 견적서에 "HealthKit 연동"만 1줄로 적혀 있으면 실제 난이도가 통째로 가려져 있는 거예요. 어떤 데이터를 어떤 주기로 받아 어떤 단위로 저장하는지, 사용자가 권한을 끊었을 때 무엇을 하는지, 플랫폼 정책이 바뀌면 누가 대응하는지까지 적혀 있어야 견적을 비교할 수 있어요. 그리고 웨어러블 API 경험은 EHR 연동 경험을 대체하지 못해요. 두 가지는 인증 방식도, 데이터 모델도, 협의 상대도 달라요. 포트폴리오에서 이 둘을 각각 확인하세요.
건강에 관한 정보는 일반 개인정보보다 한 단계 위의 취급을 받아요. 주민등록번호 분리 보관·암호화·키 관리·접근 로그 보존을 진료기록 법정 보존 기간과 함께 운영해야 하고, 회원 탈퇴와 기록 보존 의무가 충돌하는 지점을 설계로 풀어야 해요. 건강정보 비식별화, 그리고 증상 검색·요약처럼 외부 LLM에 데이터를 보내는 처리는 각각 별도 기준과 위탁 고지 요건이 걸려요. 이 영역은 지침이 개정되면 요건 자체가 바뀌니, 계약 전에 담당 부처가 현재 배포 중인 지침을 직접 확인하고 그 판을 견적 범위에 넣으세요. 견적서에 "개인정보 처리방침 작성" 한 줄만 있고 위탁 구조가 없으면 외부 모델을 붙이는 순간 처음부터 다시 협의해야 해요.
건강보험 청구는 단순 결제가 아니에요. 청구 코드 체계, DUR(의약품 안전 사용 정보) 점검, 진료 형태(외래·입원·약국)에 따라 달라지는 본인부담률, 요양급여 적용 여부 자동 계산이 들어와야 해요. 1건만 어긋나도 약국·환자·플랫폼 3축에서 동시에 컴플레인이 들어와요. 본인부담금 자동 계산이 틀리면 요양급여 청구가 반려되고, 정정 청구와 환자 환불이 동시에 발생해요. 환자는 더 낸 돈을 돌려받아야 하고, 약국은 정산이 밀리고, 플랫폼은 그 사이 앱 리뷰와 고객센터로 항의를 받아요. 계산 로직이 견적서에 한 줄로만 있으면 이 세 갈래를 누가 언제 처리하는지가 통째로 비어 있는 거예요.
의료 앱은 SLA를 하나로 뭉뚱그리면 안 돼요. 서비스 가용성, 응답 시간, 청구·정산, 처방 발행을 각각 별도 조항으로 나눠 계약서에 적으세요. 처방 발행이 실패하면 사용자는 약을 못 받고, 청구가 실패하면 돈이 안 도니까 이 두 축은 일반 화면 장애와 같은 기준으로 묶일 수 없어요. 목표치는 서비스 성격에 맞춰 협의해서 정하되, 일반 서비스용 운영 조건을 그대로 가져오지 말고 의료 앱 기준으로 한 단계 강화한 형태를 요구하세요. 인계 후 30일 무상 hot-patch + 60일 신규 critical 무상 + 90일 비상 SLA(시간당 ₩180~220K, 4h 캡)가 계약서에 없으면 출시 후 사고가 곧 추가 비용이에요.
같은 "앱 개발"이라도 의료 데이터가 끼면 맞는 파트너가 달라져요. 지금 만들려는 서비스가 어디에 해당하는지부터 맞춰 보세요.
| 업체·발주 유형 | 잘 맞는 경우 | 강점 | 리스크 | 이럴 때 고르세요 |
|---|---|---|---|---|
| 일반 앱 개발 외주 | 의료 데이터를 다루지 않는 건강 기록·습관 관리 앱 | 화면·회원·결제 같은 일반 기능을 빠르게 구현 | 전자처방·청구·인허가 요건을 견적 범위 밖에 두기 쉬움 | 진료·처방·급여 청구가 전혀 없고 웰니스 기록만 다룰 때 |
| 헬스테크 전문 파트너 | 비대면 진료·전자처방·청구가 한 흐름으로 엮인 서비스 | 데이터 모델과 인허가 일정을 개발 일정 안에 넣고 시작 | 일반 앱 외주보다 견적이 높게 잡힘 | 출시 전에 인허가와 청구 검증까지 같이 통과해야 할 때 |
| 개발사 + 인허가 컨설팅 분리 발주 | 인허가는 이미 별도로 진행 중이고 개발만 필요한 경우 | 인허가 전문성을 따로 확보, 컨설팅 교체가 쉬움 | 위험관리·생명주기 문서와 실제 코드가 어긋나면 심사에서 재작업 | 사내에 인허가(RA) 담당자가 있어 두 축을 조율할 수 있을 때 |
| 프리랜서 팀 | 개념검증(PoC)이나 사내 시연용 시제품 | 착수가 빠르고 초기 비용이 낮음 | 운영·인계와 의료 데이터 보관 의무를 이어받을 주체가 불명확 | 실제 환자 데이터를 넣지 않는 PoC 단계일 때 |
| 노코드·기성 솔루션 커스터마이징 | 예약·문진·상담 기록처럼 표준화된 기능 | 짧은 기간에 운영을 시작할 수 있음 | 전자서명, 청구 연계, 의료기기 소프트웨어 요건 대응에 한계 | 의료기기 판정 대상이 아닌 내부 운영 도구가 필요할 때 |
아래 항목은 일반 앱에는 없고 헬스테크에만 붙어요. 견적서와 제안서에서 이 표의 항목이 몇 개나 언급되는지 세어 보면 경험 유무가 빠르게 드러나요.
| 확인할 요건 | 근거가 되는 제도·표준 | 왜 필요한가요 | 빠지면 생기는 일 |
|---|---|---|---|
| 건강정보(민감정보) 처리 근거와 별도 동의 | 개인정보보호법 제23조(민감정보) | 건강에 관한 정보는 일반 개인정보와 다른 동의·안전조치를 요구해요 | 동의 설계가 어긋나면 기능 중단이나 시정 요구로 이어질 수 있어요 |
| 진료기록 보존 체계 | 의료법 및 의료법 시행규칙(진료기록부 보존 기간) | 기록은 회원이 탈퇴한 뒤에도 정해진 기간 동안 남아 있어야 해요 | "탈퇴 시 즉시 전부 삭제"로 설계하면 보존 의무와 정면으로 부딪혀요 |
| 전자처방 위변조 방지 | 전자서명법, 의료법(처방전 작성·교부) | 처방은 발행 주체·시점·내용이 나중에 증명돼야 해요 | 로그인 토큰만으로 처리하면 재발행·위조 분쟁에서 방어가 안 돼요 |
| 의료기기 소프트웨어(SaMD) 해당 여부 판단 | 의료기기법, 식약처 의료기기 소프트웨어 허가·심사 가이드라인 | 측정·진단·치료에 영향을 주는 기능은 허가 대상이 될 수 있어요 | 개발을 마친 뒤 판정을 받으면 구조를 다시 짜야 할 수 있어요 |
| 소프트웨어 생명주기·위험관리 문서 | IEC 62304, ISO 14971 | 허가 심사는 코드가 아니라 문서와 이력으로 확인해요 | 개발이 끝난 뒤 문서를 소급 작성하면 형상관리 이력이 비어 재작업이 생겨요 |
| 요양급여 청구·DUR 연계 | 국민건강보험법, 건강보험심사평가원 청구 및 DUR 체계 | 청구는 일반 결제와 달리 코드와 점검 절차를 통과해야 정산돼요 | 청구가 어긋나면 환자·약국·플랫폼 세 곳에서 동시에 문제가 돼요 |
| 약국·의약품 취급 범위 | 약사법 | 조제와 복약 안내의 허용 범위가 법으로 정해져 있어요 | 앱 기능이 허용 범위를 넘으면 그 기능을 통째로 걷어내야 할 수 있어요 |
| 웨어러블 데이터 수집 동의와 연동 방식 | 개인정보보호법(민감정보), 각 헬스 플랫폼의 데이터 이용 정책 | 심박·ECG 같은 데이터는 법 요건과 플랫폼 정책을 동시에 만족해야 해요 | 수집 목적 고지가 부족하면 앱 심사 단계에서 배포가 반려될 수 있어요 |
표에 적은 것은 현행 법령과 국제 표준, 식약처 발간 자료의 명칭이에요. 실제 적용 범위와 조문 단위 해석은 서비스가 어떤 기능을 담는지에 따라 달라지니, 인허가 담당자나 관계 기관 문의로 확인하세요.
본문 기준으로 비대면 진료·전자처방·결제가 들어간 MVP는 9,000만원~1억 8천만원에 5~7개월, EHR 연동과 청구 EDI·웨어러블까지 붙는 풀 패키지는 2억~4억원에 7~10개월을 잡아요. 의료기기 소프트웨어 인허가 동행이나 디지털 치료기기 보험 수가 신청이 붙으면 비용과 기간이 더 추가돼요. 이 범위는 국내 외주 시장의 현장 견적 기준이고 공표 통계가 아니에요. 범위 하단을 크게 밑도는 견적은 인허가·전자처방·청구 중 하나가 빠져 있을 가능성이 커요.
의료 데이터를 다루지 않는 건강 기록 앱이라면 일반 개발사로도 충분해요. 다만 비대면 진료, 전자처방, 요양급여 청구가 한 흐름으로 엮이면 이야기가 달라져요. 이때는 개발과 인허가·청구가 따로 노는 상태로 시간을 잃기 쉬워서, 처음부터 환자·의사·약사·처방·청구·웨어러블을 하나의 데이터 모델로 설계하는 파트너가 안전해요.
혈압·혈당·수면·정신건강처럼 측정이나 진단, 처방에 영향을 주는 기능은 의료기기 소프트웨어 등급이 걸릴 수 있어요. 이 경우 외주사가 위험관리(ISO 14971)와 소프트웨어 생명주기(IEC 62304) 문서, 형상관리 이력까지 함께 만들어야 출시까지 갈 수 있어요. 포트폴리오에 의료기기 소프트웨어 출시 경험이 없으면 인허가 단계에서 일정이 크게 밀리기 쉬우니, 계약 전에 실제 출시 이력을 문서로 확인하세요.
의사 전자서명, 본인확인, 발행 시점 기록, 내용 무결성 검증이 명문화돼 있는지 보세요. 약국 쪽 수신 확인과 재발행 차단, 법정 보관 기간 운영까지 한 흐름으로 적혀 있어야 해요. "위변조를 어떻게 막나요"라는 질문에 답이 로그인 토큰 한 줄이면 그 업체는 넘기는 편이 좋아요.
Apple HealthKit, Samsung Health, Fitbit, Garmin 같은 웨어러블 API 경험과 국내 병의원 EHR 제품 연동 경험을 함께 봐야 해요. 웨어러블 API 경험만으로는 EHR 연동 경험을 대체하지 못하거든요. 견적서에 "HealthKit 연동" 한 줄만 있으면 백그라운드 동기화 권한이나 심박·ECG 데이터 단위 처리 같은 실제 난이도가 빠져 있는 거예요. 어떤 데이터를 어떤 주기로 어떻게 받아 저장하는지까지 적혀 있는지 확인하세요.
본문의 7질문 체크리스트가 그 용도예요. 진료부터 청구까지 한 흐름의 데이터 설계, 전자처방 위변조 방지 명문화, 의료기기 소프트웨어 출시 이력, 웨어러블·EHR 연동 경험, 개인정보와 기록 보존 매트릭스, 청구와 본인부담금 자동 계산, 운영 SLA와 인계 보장까지 일곱 개를 견적서에서 찾아보면 돼요. 일곱 개 가운데 여러 항목이 견적서에서 확인되지 않으면 계약을 서두르지 않는 편이 좋아요.
2026년 헬스테크 MVP 기준 견적 범위는 다음과 같아요(인허가·전자처방·웨어러블 1종 포함). 아래는 국내 외주 시장에서 통용되는 현장 견적 범위이지 공표된 통계가 아니에요.
범위 하단을 크게 밑도는 견적은 인허가·전자처방·청구 중 하나가 빠져 있는 경우가 대부분이에요. 빠진 항목은 사라지는 게 아니라 출시 뒤에 추가 비용으로 돌아와요. 견적을 비교할 때는 총액이 아니라 어떤 항목이 범위에 들어 있는지를 먼저 맞춰 놓고 보세요.
통과 개수를 세는 것보다, 통과하지 못한 항목이 무엇인지 짚고 그 항목을 누가 언제 책임지는지 되묻는 쪽이 실제로는 더 빨라요. 답이 "나중에 협의"로 돌아오는 항목이 계약 후 분쟁이 시작되는 자리예요.
포텐랩은 MVP·플랫폼 개발을 주력으로 하면서 헬스테크·의료기기 소프트웨어 도메인의 개발과 인계를 경험해 왔어요. 비대면 진료 → 전자처방 → 약국 픽업 → 공단 청구까지 6축 ERD를 표준 템플릿으로 갖고 있어서, 데이터 모델을 매번 처음부터 그리는 대신 서비스 범위에 맞춰 덜어내는 방식으로 시작해요. 의료기기 소프트웨어나 전자처방처럼 인허가·급여 체계가 걸리는 영역은 개발 일정과 규제 요건을 같은 표에 올려 두고 착수해요. 규제 요건을 개발이 끝난 뒤에 확인하면 그 시점부터가 전부 재작업이니까요. 97% 프로젝트 수행 완수율과 Notion 일일 진행 공유, 분기 1회 의료법·의료기기법 변경사항 무상 반영을 인계 표준으로 운영해요.
헬스테크·디지털헬스케어 앱 개발 파트너를 찾고 있다면 포텐랩에 30분 무료 진단을 요청하세요. 인허가 일정·전자처방 모듈·청구 EDI까지 한 표로 정리한 RFP 응답 템플릿을 무료로 보내드려요. AI 기반 증상 분석·RAG 의료 챗봇이 필요하다면 트리숲(TreeSoop)과의 협업도 권해 드려요.
두 팀은 같은 그룹이라 솔직하게 나눠 적을게요. 어느 쪽인지 가르는 질문은 하나예요 — 지금 어려운 게 제품인가요, AI인가요?
헬스테크·디지털헬스케어에 AI가 곁들여지는 정도면 포텐랩 하나로 충분해요. 반대로 AI가 서비스의 본체라면 트리숲 쪽이 빠릅니다. 애매하면 상담에서 나눠드려요 — 맞지 않는 쪽으로 보내는 게 서로에게 이득이거든요.