2026년 들어 한국 헬스케어 스타트업 카테고리가 조용히, 그리고 강하게 회복되고 있어요. 코로나 시기 비대면 진료 규제 완화가 부분적으로 영구화됐고, 보건복지부가 디지털 헬스케어 상시 시범사업을 확대했고, OpenAI Privacy Filter·Gemma Medical 같은 의료 특화 LLM이 오픈웨이트로 풀리면서 "진료 데이터를 외부 클라우드에 보내지 않고도 AI를 쓰는 길"이 열렸어요. 그 사이 만성질환 관리·정신건강·EMR/EHR·임상시험 모집·간호 워크플로우 자동화 같은 버티컬에서 새 SaaS가 줄줄이 출시되고 있고요.
창업자 입장에서 헬스케어 앱은 매력적이지만 가장 무서운 카테고리이기도 해요. 의료기기법, 개인정보보호법(PIPA), 의료법 27조(원격의료), 보건복지부 비대면 진료 가이드라인, 건강보험 청구 시스템 연동, 식약처 SaMD 분류를 한꺼번에 다뤄야 하고, 한 번의 데이터 사고로 회사가 닫힐 수 있어요. 그래서 외주 파트너 선택이 다른 어떤 카테고리보다 중요해요. "앱을 잘 만드는 회사"가 아니라 "헬스케어 도메인의 함정을 아는 회사"여야 해요.
의료법 27조(영리 목적 환자 알선 금지), 23조(전자처방전), 보건복지부 비대면 진료 가이드라인은 매년 바뀌어요. 2026년만 해도 한약 비대면 처방 제한, AI 챗봇의 진료 행위 경계, EMR 데이터 2차 활용 동의서 양식이 갱신됐어요. 최소한 '계약 전에 의료법 리스크 보고서를 1페이지로 받을 수 있는 업체'가 안전해요. "법률 자문은 별도"라고 미루는 곳은 1순위 탈락이에요.
주민등록번호·여권번호·외국인등록번호는 고유식별정보로 분류돼 별도 동의·암호화·접근 통제·보관 기간 제한이 강제돼요. 처방전·진단명·검사 결과는 민감정보예요. 둘 다 PIPA 23조·24조의 대상이고, 단순 SHA256 해싱으로는 충분하지 않아요. AES-256 + 키 분리 + 접근 로그 + 정기 감사까지 한 세트로 굴려 본 팀인지 확인해 보세요.
한국 헬스케어 앱의 마지막 1마일은 EMR 연동(닥터스, e-OK, Visus, ezPlus 등), 건강보험 청구 시스템(요양급여비용 청구 EDI), 약국 ERP 연동(파마플러스, PharmIT 등)에서 무너져요. 표준 FHIR가 도입됐지만 실제 병원·약국은 자체 포맷이 많아요. 외주 업체가 최소 1개 이상의 EMR/청구 시스템과 실제 연동을 해 본 경험이 있는지가 핵심이에요.
증상 체크·진단 보조·치료 효과 예측 같은 기능을 넣으면 식약처 SaMD 등급 분류가 들어와요. Class I~IV로 나뉘고 Class II 이상은 임상시험 또는 임상평가 보고서가 필요해요. 처음부터 "이 기능은 일반 웰니스이고, 이 기능은 SaMD 트랙"이라고 분리해서 설계해야 출시 직전에 갈아엎는 일을 피해요. 외주 업체가 SaMD 분류 경험이 있는지 반드시 물어봐야 해요.
2026년 헬스케어 앱의 절반 이상이 AI 기능을 포함해요. 진단명 안내, 약물 상호작용 점검, 의료 상담 요약, 간호 기록 자동화, 음성-차트 변환 등이요. 외부 LLM 호출이면 환자 데이터의 미국 송신 동의 이슈가 터지고, 로컬 LLM이면 의료 도메인 fine-tuning + 할루시네이션 가드레일을 잡아야 해요. RAG 파이프라인으로 의약품 DB·진료 가이드라인을 인용 가능하게 묶을 수 있는 팀이 필요해요.
의료 데이터는 접근 로그를 의무 보관해야 하고, 사고 발생 시 누가 언제 어떤 환자 차트를 열어 봤는지 즉시 답할 수 있어야 해요. RBAC + 행 수준 보안(RLS) + 감사 로그 + 키 로테이션 + 외부 침투 테스트가 옵션이 아니라 기본 사양이어야 해요. 외주 업체에 "보안 항목은 별도 견적"이라는 답이 돌아오면 위험 신호예요.
헬스케어 앱은 출시가 끝이 아니라 시작이에요. 약물 DB 업데이트, 의료법 가이드라인 변경, 보험 수가 개정, EMR 버전 업그레이드를 즉시 반영해야 해요. "24시간 응답·48시간 핫픽스 SLA"가 계약서에 들어 있어야 하고, 출시 후 30/60/90일 인수인계와 운영 매뉴얼이 약속돼야 해요. 우리가 4-27 글에서 다룬 12가지 인수인계 자산이 헬스케어에선 더 엄격하게 적용돼야 해요.
포텐랩은 97%의 프로젝트 수행완수율을 유지하며 의료·헬스케어 도메인 프로젝트를 다수 진행해 왔어요. 일반적인 앱 개발사와 달리 다음을 기본 사양으로 제공해요.
헬스케어 앱은 한 번 잘못 짠 데이터 모델이 회사 전체를 닫게 만들 수 있어요. 시작 단계에서 도메인을 아는 파트너를 잡는 게 가장 비용 효율적인 보험이에요. 포텐랩은 무료 1차 진단 미팅에서 의료법 리스크·SaMD 분류·예상 일정·견적 범위를 한 번에 정리해 드려요.
위에서 본 기준을 실제 계약 체크리스트로 정리했어요. 헬스케어는 "나중에 붙이면 되는 것"과 "처음부터 없으면 다시 만들어야 하는 것"의 경계가 특히 뚜렷해요.
| 요건 | 근거는 어디에 있나요 | 계약 전에 확인할 것 | 빠지면 생기는 일 |
|---|---|---|---|
| 민감정보·고유식별정보 처리 | 개인정보보호법 제23조(민감정보의 처리 제한), 제24조(고유식별정보의 처리 제한) | 별도 동의 분리, 암호화와 키 분리, 보관 기간 정책이 설계 문서에 있는지 | 진단명·처방 이력이 일반 데이터처럼 쌓여, 사고 시 조사 범위가 회사 전체로 번져요 |
| 접근 로그·감사 추적 | 개인정보보호법 제29조(안전조치의무)와 개인정보보호위원회 고시 '개인정보의 안전성 확보조치 기준'(접속기록 보관·점검) | RBAC(역할 기반 접근 제어), 행 수준 보안(RLS), 감사 로그가 기본 견적에 포함됐는지 | "누가 언제 어떤 환자 차트를 열었나"에 답할 수 없어요 |
| 의사 자격 검증 | 의료법 제27조(무면허 의료행위 등 금지) | 면허번호 검증 또는 의사 인증 연동 방식이 정해져 있는지 | 일반 회원가입 폼으로 의사 계정이 열려 자격 없는 사람이 진료성 답변을 하게 돼요 |
| SaMD(소프트웨어 의료기기) 분류 | 의료기기법 및 식약처 의료기기 등급 분류 기준 | 웰니스 기능과 의료기기 트랙 기능을 설계 단계에서 분리했는지 | 출시 직전에 인허가 트랙에 걸려 기능을 통째로 재설계하게 돼요 |
| 비대면 진료 범위 | 의료법 및 보건복지부 비대면진료 관련 지침 | 지침 개정을 누가, 어떤 주기로 반영하는지 | 개정될 때마다 서비스 플로우 일부가 허용 범위 밖으로 밀려나요 |
| EMR·청구·약국 연동 | 법정 요건 아님 — 병·의원 EMR, 요양급여비용 청구(EDI), 약국 ERP 연동 대상 | 실제 연동 이력 1건 이상과 테스트 계정 확보 경로 | 마지막 1마일에서 일정이 통째로 밀려요 |
| 의료 AI 출력 관리 | 개인정보보호법상 국외 이전 규정, 의료법 제27조(무면허 의료행위 등 금지) | 인용 출처, 면책 문구, 의사 검토 게이트가 설계에 들어갔는지 | AI가 진단명을 단정해 무면허 의료행위 논란이 생겨요 |
| 출시 후 대응 | 법정 요건 아님 — 계약 사항 | 응답·핫픽스 SLA와 인수인계 문서 범위가 계약서에 적혀 있는지 | 약물 DB, 보험 수가, EMR 버전 변경이 방치돼요 |
법령명과 조문은 2026년 8월 기준이에요. '법정 요건 아님'이라고 적은 행은 법이 아니라 계약으로 정하는 항목이고, 나머지는 현행 법령·고시·지침을 요약한 거예요. 조문과 지침은 개정될 수 있고 우리 서비스에 어디까지 적용되는지는 기능 범위에 따라 달라지니, 계약 전 법률 검토로 확인하세요. 공표 통계가 아니라 현행 제도 요약이에요.
같은 "앱 개발"이라도 헬스케어에서는 업체 유형에 따라 걸리는 지점이 완전히 달라져요. 지금 우리 단계에 환자 실데이터가 들어가는지부터 보고 고르면 헷갈리지 않아요.
| 업체 유형 | 이럴 때 고르세요 | 강점 | 헬스케어에서 걸리는 지점 |
|---|---|---|---|
| 대형 SI | 병원·보험사 전사 시스템, 조달·입찰로 진행하는 건 | 규제 대응 조직과 감사 대응 경험을 갖춘 곳이 많아요 | 비용과 리드타임이 커서, 범위를 자주 바꾸는 초기 제품 실험에는 잘 안 맞아요 |
| 헬스케어 경험이 있는 전문 에이전시 | 비대면 진료·만성질환 관리·EMR 연동형 서비스를 MVP부터 정식 출시까지 가져갈 때 | 의료법·개인정보 요건과 SaMD 분리 설계를 초기에 잡아 주고, 연동 이력이 있어요 | "헬스케어 경험 있음"이 실제인지 검증이 필요해요. 연동해 본 시스템 이름과 레퍼런스를 직접 물어보세요 |
| 일반 앱 개발 에이전시 | 기록·습관·웰니스처럼 의료행위 경계 밖에 있는 서비스 | 화면 품질과 개발 속도가 좋고 견적도 합리적이에요 | 보안·감사 로그·인허가가 "별도 견적"으로 빠지기 쉬워요 |
| 프리랜서 팀 / 노코드 | 환자 실데이터를 아직 쓰지 않는 가설 검증용 프로토타입 | 짧은 기간에 적은 비용으로 화면과 플로우를 확인할 수 있어요 | 고유식별정보 처리, 접근 로그, 데이터 이관 요건을 감당하기 어려워요. 실데이터가 들어가는 순간 재구축이에요 |
| 사내 개발팀 직접 구성 | 규제 대응과 운영이 앞으로 상시 업무가 되는 단계 | 도메인 지식이 조직 안에 남아요 | 채용 리드타임이 길고, 인허가·EMR 연동 경험자는 특히 구하기 어려워요 |
업체 유형별 정성 비교예요. 가격과 기간은 기능 범위·연동 대상·인허가 트랙에 따라 편차가 커서 일부러 넣지 않았어요.
앱을 잘 만드는 회사인지보다, 헬스케어 도메인의 함정을 아는 회사인지가 먼저예요. 의료법·개인정보보호 실전 경험, EMR·청구·약국 연동 이력, SaMD 분류 경험, 의료 AI 가드레일, 보안과 감사 로그 기본 제공, 출시 후 SLA와 인수인계까지 계약 전에 확인해 보세요. "법률 자문은 별도", "보안은 별도 견적"이라는 답이 돌아오면 위험 신호예요.
기능에 따라 달라져요. 증상 체크, 진단 보조, 치료 효과 예측처럼 의학적 판단에 개입하는 기능이 들어가면 소프트웨어 의료기기(SaMD) 분류 대상이 되고, 등급이 올라가면 임상시험이나 임상평가 자료가 필요해져요. 그래서 설계 단계에서 "이건 일반 웰니스, 이건 의료기기 트랙"으로 미리 나눠 두는 게 중요해요. 출시 직전에 나누려고 하면 기능을 통째로 갈아엎게 돼요.
안 돼요. 주민등록번호·여권번호·외국인등록번호는 고유식별정보, 처방전·진단명·검사 결과는 민감정보로 분류돼서 별도 동의와 암호화, 접근 통제, 보관 기간 제한이 따라와요. 단순 해싱만으로는 부족하고 AES-256 암호화에 키 분리, 접근 로그, 정기 감사까지 한 세트로 봐야 해요. 일반 DB에 그대로 넣어 두면 사고가 났을 때 조사 범위가 회사 전체로 번져요.
환자 데이터가 국외로 나가는 구성으로 외부 LLM을 호출하면 국외 이전 동의 문제가 생기고, 로컬 LLM을 쓰면 의료 도메인 튜닝과 할루시네이션 가드레일을 직접 잡아야 해요. 그리고 AI가 진단명을 단정해서 답하는 순간 의료행위 경계 논란으로 넘어가니, 면책 문구와 인용 출처, 의사 검토 게이트를 반드시 넣어야 해요. 의약품 DB나 진료 가이드라인을 RAG로 묶어 근거를 인용할 수 있게 만드는 방식이 비교적 안전해요.
한국 헬스케어 앱은 마지막 1마일인 EMR·청구·약국 연동에서 무너지는 경우가 많아요. FHIR 같은 표준이 있지만 실제 병·의원과 약국은 자체 포맷을 쓰는 곳이 많아서, 문서만 보고 붙일 수가 없거든요. 그래서 외주 업체가 EMR이나 요양급여비용 청구 시스템 중 최소 하나는 실제로 연동해 본 경험이 있는지 확인하는 게 좋아요.
헬스케어는 출시가 끝이 아니라 시작이에요. 약물 DB 업데이트, 비대면 진료 지침 변경, 보험 수가 개정, EMR 버전 업그레이드를 계속 반영해야 하거든요. 계약서에 응답·핫픽스 SLA가 들어 있는지, 출시 후 30·60·90일 인수인계와 운영 매뉴얼이 약속돼 있는지 확인하세요.
두 팀은 같은 그룹이라 솔직하게 나눠 적을게요. 어느 쪽인지 가르는 질문은 하나예요 — 지금 어려운 게 제품인가요, AI인가요?
헬스케어·메디테크에 AI가 곁들여지는 정도면 포텐랩 하나로 충분해요. 반대로 AI가 서비스의 본체라면 트리숲 쪽이 빠릅니다. 애매하면 상담에서 나눠드려요 — 맞지 않는 쪽으로 보내는 게 서로에게 이득이거든요.