병원 AI 도입 가이드

"AI를 도입하면 뭐가 달라지나요?"

이 질문을 많이 받습니다. AI가 카카오톡 문의에 대신 답변하고, 예약을 자동으로 잡아주고, 시술 후 안내를 알아서 보내준다 — 이런 이야기는 들어보셨을 겁니다. 주변 병원들도 하나둘 도입하고 있다는 이야기도요.

그런데 막상 알아보면 막막합니다. AI가 똑똑하다는 건 알겠는데, 우리 병원에 어떻게 적용되는 건지. 도입하면 당장 뭐가 바뀌는 건지. 직원들이 할 일이 줄어드는 건지, 아니면 새로운 일이 생기는 건지.

결론부터 말씀드리면, AI 도입의 핵심은 AI 기술 자체가 아닙니다. 병원의 데이터를 어떻게 정리하느냐가 전부입니다. AI는 정리된 데이터 위에서 작동하는 도구일 뿐입니다.

이 글에서는 그게 구체적으로 무슨 뜻인지, 병원 에피소드를 하나씩 따라가면서 설명드리겠습니다.

---

먼저, 업무의 구조를 한번 살펴보겠습니다

병원에서 매일 일어나는 일들을 떠올려 보세요.

"내일 예약 있는 고객한테 리마인드 보내야지." "시술 끝난 분한테 사후 안내 문자 보내야지." "오랜만에 연락 온 고객, 지난 시술 이력 확인해야지."

전부 다른 업무 같지만, 자세히 보면 공통점이 있습니다.

데이터를 보고 → 기준에 따라 → 행동한다.

예약 날짜를 보고, 내일이면, 카톡을 보낸다. 시술 기록을 보고, 오늘 완료됐으면, 안내 문자를 보낸다. 고객 이력을 보고, 3개월 이상 미방문이면, 연락한다.

모든 업무의 구조는 동일합니다. 데이터가 있고, 그 데이터를 처리하는 규칙이 있습니다.

사람이 이 과정을 하면 "업무" 라고 부릅니다. 시스템이 이 과정을 하면 "자동화" 라고 부릅니다.

차이는 누가 하느냐뿐입니다. 구조는 완전히 같습니다.

---

예시를 하나 들어볼게요

매일 퇴근 전, 데스크 직원이 하는 일이 있습니다.

"내일 예약 있는 분들한테 리마인드 카톡 보내기."

노트를 꺼내고, 내일 예약을 하나씩 확인하고, 카카오톡을 열어서 메시지를 보냅니다. 5명이면 5분, 20명이면 20분. 매일 반복입니다.

이 업무를 시스템이 이해할 수 있는 형태로 바꿔보면 어떻게 될까요?

기존 문장:

"내일 예약 있는 고객한테 리마인드 카톡 보내기"

시스템이 이해하는 형태:

이게 전부입니다. 필드 2개, 규칙 1개. 시스템이 이 데이터를 알고 있으면 사람이 할 필요가 없습니다. 매일 오후 6시에 자동으로 실행됩니다. 빠뜨리는 일도, 퇴근이 늦어지는 일도 없습니다.

시스템이 데이터를 알면, 자동화할 수 있습니다.

이 개념을 컴퓨터공학에서는 이벤트 기반 처리(Event-Driven Processing) 라고 합니다. 레이니에서는 워크플로우가 이 역할을 합니다. 자세한 내용은 Entity 데이터로 작동하는 기능들에서 다룹니다.

---

조금만 더 복잡한 상황을 보겠습니다

리마인드까지는 단순합니다. 그런데 실제 병원에선 이런 요청이 생깁니다.

"시술별로 사후 안내가 달라야 해요. 보톡스 맞은 분한테는 '24시간 눕지 마세요', 필러 맞은 분한테는 '사우나 1주일 금지'를 보내야 해요."

같은 고객인데, 이제 시술 종류에 따라 다른 메시지를 보내야 합니다. 데이터가 늘어납니다.

구조는 아까와 똑같습니다. 데이터를 보고, 기준에 따라, 행동한다. 달라진 건 데이터가 더 세세해졌다는 것뿐입니다.

여기서 패턴이 보입니다.

데이터를 더 세세하게 나눌수록, 더 정밀한 자동화가 가능합니다.

시술 종류만 기록하면 시술별 안내를 자동화할 수 있고, 시술 부위까지 기록하면 부위별 안내도 가능해지고, 시술 횟수까지 기록하면 "3회차부터는 이런 점을 주의하세요" 같은 안내도 보낼 수 있습니다.

데이터를 의미 단위로 쪼개서 저장하는 것을 컴퓨터공학에서는 데이터 정규화(Normalization) 라고 합니다. 레이니에서는 Entity와 Custom Fields가 이 역할을 합니다. 자세한 내용은 Entity 시스템에서 다룹니다.

---

그런데 "보톡스"라는 글자만으로 충분할까요?

위 예시에서 시술 종류에 "보톡스"라고 적었습니다. 그런데 현실에서는 이런 일이 생깁니다.

보톡스 사후 안내 문구를 "24시간 눕지 마세요"에서 "6시간 동안 눕지 마세요"로 바꿔야 합니다. 그런데 예약 기록마다 "보톡스"라는 글자가 각각 적혀 있습니다. 어떤 건 "보톡스", 어떤 건 "BTX", 어떤 건 "보톡스(이마)". 전부 찾아서 하나하나 바꿔야 할까요?

문제의 원인은, 예약마다 시술 정보를 글자로 직접 적었기 때문입니다. 시술 이름, 가격, 사후 안내가 예약 기록 곳곳에 흩어져 있습니다.

해결 방법은 간단합니다. 시술 정보를 한 곳에 정리해두고, 예약에서는 그것을 가리키기만 하면 됩니다.

예약 기록에 "보톡스"라는 글자를 적는 대신, 시술 목록의 P001을 가리킵니다. 이렇게 하면:

• 사후 안내를 바꾸고 싶으면 → 시술 목록에서 P001 한 줄만 수정하면 됩니다. 모든 예약이 바뀐 내용을 참조합니다.
• "보톡스 맞은 고객 전체"를 찾고 싶으면 → P001을 가리키는 예약을 찾으면 됩니다. 오타나 표기 차이 걱정이 없습니다.
• 시술 가격이 바뀌어도 → 시술 목록 한 곳만 수정하면 됩니다.

이 구조는 고객에게도 똑같이 적용됩니다. 예약마다 고객 이름과 연락처를 직접 적는 대신, 고객 목록에서 해당 고객을 가리킵니다. 고객이 전화번호를 바꾸면 고객 목록 한 곳만 수정하면 되고, 모든 예약과 상담 기록이 새 번호를 참조합니다.

데이터끼리 연결되어 있으면, 수정은 한 번이면 충분합니다.

데이터를 복사하지 않고 가리키는 이 구조를 컴퓨터공학에서는 관계형 모델(Relational Model) 과 참조 무결성(Referential Integrity) 이라고 합니다. 레이니에서는 Entity 간 관계와 Entity 연결 필드가 이 역할을 합니다. 자세한 내용은 Entity 시스템에서 다룹니다.

---

그런데 규칙으로 안 되는 업무가 있습니다

여기까지는 규칙이 명확합니다. "보톡스면 이거, 필러면 저거." 조건이 딱딱 떨어집니다.

그런데 이런 상황은 어떨까요?

카카오톡으로 문의가 옵니다. "안녕하세요, 보톡스 맞고 싶은데요. 근데 저 알레르기가 좀 있어서... 괜찮을까요? 아 그리고 가격이랑 시간도 알려주세요."

이 질문에 대답하려면 상담 직원은 이런 과정을 거칩니다.

1. 고객 이력 확인 — 이전 시술이 있었나? 알레르기 이력은?
2. 시술 정보 확인 — 보톡스 가격, 소요 시간, 알레르기 관련 주의사항
3. 예약 가능 시간 확인 — 오늘/내일 빈 시간대
4. 종합 판단 — 알레르기 때문에 상담 후 시술이 나을지, 바로 예약을 잡아도 될지

이건 "보톡스면 이거"처럼 딱 떨어지지 않습니다. 상황을 종합적으로 판단해야 합니다.

이때 필요한 데이터를 보면:

AI도 마법이 아닙니다. AI가 정확하게 답변하려면 형식화된 데이터가 필요합니다.

가격 정보가 시스템에 없으면 AI는 가격을 안내할 수 없습니다. 알레르기 주의사항이 기록되어 있지 않으면 AI는 주의사항을 말할 수 없습니다. 예약 가능 시간이 형식화되어 있지 않으면 AI는 시간을 안내할 수 없습니다.

AI도 형식화된 데이터가 있어야 작동합니다. 데이터가 많을수록 AI는 더 정확해집니다.

형식화된 데이터를 AI가 직접 조회해서 판단하는 방식을 도구 기반 AI(Tool-augmented LLM) 라고 합니다. AI가 데이터베이스에서 필요한 정보를 직접 검색하고, 그 결과를 기반으로 답변을 생성합니다. 레이니의 AI 상담이 이 방식으로 작동합니다. 자세한 내용은 Entity 데이터로 작동하는 기능들에서 다룹니다.

---

자동화가 늘어나면 생기는 문제

자동화가 하나둘 늘어나면, 새로운 문제가 생깁니다.

원장님이 보톡스 가격을 15만원에서 12만원으로 바꿨습니다. 그런데 AI 챗봇은 여전히 "15만원입니다"라고 안내하고, 홈페이지에도 15만원이 그대로 있고, 카톡 자동 응답에도 15만원이 적혀 있습니다.

왜 이런 일이 생길까요? 같은 정보가 여러 곳에 따로따로 저장되어 있기 때문입니다.

데이터가 흩어져 있을 때:

데이터가 한곳에 있을 때:

이것을 SSOT(Single Source of Truth) — 단일 진실 공급원이라고 합니다. 어려운 개념이 아닙니다.

"같은 정보는 한 곳에만 저장하고, 나머지는 거기를 참조한다."

자동화가 1~2개일 때는 데이터가 흩어져 있어도 사람이 수동으로 맞출 수 있습니다. 하지만 자동화가 10개, 20개로 늘어나면 흩어진 데이터는 재앙이 됩니다. 잘못된 가격으로 자동 발송된 메시지를 하나하나 정정하는 상황을 상상해보세요.

SSOT(Single Source of Truth) 는 소프트웨어 공학의 핵심 원칙 중 하나입니다. 자세한 내용은 이 구조이기 때문에 가능한 것들에서 다룹니다.

---

여러 사람이 함께 쓰면 생기는 문제

데이터가 한곳에 모이면 좋은데, 그러면 또 다른 걱정이 생깁니다.

"간호사가 실수로 보톡스 가격을 0원으로 바꿔버리면 어떡해요?" "신입 직원이 예약 규칙을 건드리면?"

데이터가 한곳에 있으니까, 잘못 건드리면 모든 곳에 영향이 갑니다. 그래서 누가 무엇을 할 수 있는지 정해야 합니다.

이것을 RBAC(Role-Based Access Control) — 역할 기반 접근 제어라고 합니다.

SSOT가 "하나의 원본"을 만드는 것이라면, RBAC는 "그 원본을 안전하게 지키는 것"입니다. 둘은 항상 함께 갑니다. 한곳에 모아놓고 아무나 수정할 수 있으면, 안 모아놓은 것보다 더 위험합니다.

RBAC(Role-Based Access Control) 는 NIST(미국 국립표준기술연구소)가 정의한 접근 제어 모델입니다. 자세한 내용은 이 구조이기 때문에 가능한 것들에서 다룹니다.

---

이걸 직접 하려면 어떻게 될까요?

지금까지 살펴본 것들을 정리해보면:

• 고객, 시술, 의료진, 예약 데이터를 각각 의미 단위로 쪼개서 구조화해야 합니다.
• 데이터끼리 참조 관계로 연결해서, 중복 없이 일관성을 유지해야 합니다.
• 확정적 규칙은 이벤트 기반으로 자동 실행되도록 설계해야 합니다.
• 판단이 필요한 업무는 AI가 데이터를 참조해서 응답할 수 있도록 연결해야 합니다.
• 모든 데이터를 한곳에서 관리하되, 역할별로 접근 권한을 나눠야 합니다.

이걸 직접 하려면 어떻게 될까요?

데이터 구조를 설계하는 것부터 쉽지 않습니다. 시술과 의료진은 어떻게 연결할지, 고객 필드는 뭘 넣을지, 예약과 시술의 관계는 어떻게 잡을지. 데이터베이스 설계 경험이 없으면 시작조차 막막합니다. 설계를 했다 해도, 나중에 "이 필드도 필요했는데" 싶으면 전체 구조를 뜯어고쳐야 할 수 있습니다.

규칙을 자동으로 실행하는 시스템을 만드는 것도 어렵습니다. "예약 확정되면 카톡 보내기"가 말로는 간단하지만, 이벤트 감지, 조건 평가, 메시지 발송, 실패 시 재시도까지 직접 구현하려면 개발 리소스가 상당합니다.

그리고 가장 어려운 부분 — 기존 시스템과의 연동입니다. 이미 쓰고 있는 EMR, 카카오 채널, 예약 시스템, 홈페이지. 이것들과 새 시스템을 연결해서 데이터가 자연스럽게 흘러가게 만드는 작업은, 각 시스템의 API를 이해하고, 데이터 형식을 맞추고, 오류 처리까지 고려해야 합니다.

결국 병원이 직접 이 모든 걸 설계하고 구축하는 건 현실적이지 않습니다. 그렇다고 단순한 자동화 도구 하나를 도입한다고 해결되는 것도 아닙니다. 데이터 구조, 관계 설계, 이벤트 처리, AI 연결, 권한 관리 — 이것들이 처음부터 하나의 시스템 안에서 설계되어 있어야 합니다.

---

그래서 레이니를 만들었습니다

레이니는 이 글에서 다룬 모든 요소를 처음부터 하나의 시스템으로 설계한 병원 운영 자동화 플랫폼입니다.

데이터를 더 세세하게 형식화할수록, 더 많은 업무를 자동화할 수 있습니다. 레이니는 그 형식화를 병원 현장에 맞게, 가능한 한 쉽게 할 수 있도록 만들었습니다.

---

레이니 도입 단계

레이니를 우리 병원에 도입하는 과정은 다음과 같습니다.

---

더 깊이 알아보기

이 글에서 다룬 각 개념의 기술적 원칙과 레이니에서의 구현을 자세히 설명하는 문서입니다.