환자 및 직원 데이터를 AI에게 한 번도 노출하지 않고, AI를 활용해 병원 시스템 3가지 구축하기

※이 기사는 Zenn의 글을 전재한 것입니다.

저는 의료기관에서 사무직을 하고 있습니다. 엔지니어는 아닙니다.

AI와 함께 병원의 업무 시스템 3가지를 만들었습니다. 모두 1주일 이내에, 전문 개발자로 활동하는 것이 아니라, 평소의 사무 업무를 하면서 말입니다.

'데이터를 보여주지 않는다'고 들으면, 과정이 복잡해지고 늦어질 것 같다고 생각할 수 있습니다. 하지만 실제로는, 업무 중간중간에도 각각 1주일 이내에 완성했습니다.

'AI를 사용하고 싶지만 개인정보가 있어서 불가능하다'라고 생각하는 분들을 위해 제가 했던 방법을 적습니다.

가장 간단하면서도 가장 효과적인 원칙이 있습니다.

• 실제 명부/환자 번호 파일은, 병원 내부 PC와 공유 폴더에만 보관한다 - AI가 작업하는 폴더, 클라우드, AI가 연결되는 장소에는 두지 않는다

AI에게 '보여주지 않도록 주의한다'는 것이 아니라, 물리적으로 닿을 수 없게 만듭니다. 주의만 하는 규칙은 바쁜 날에 깨지기 마련입니다.

실제 데이터를 보여주지 않을 거라면, 테스트는 가짜(dummy)로 진행합니다. 여기서 제가 고안한 것은 가짜 데이터의 만드는 방법입니다.

제복 지급은 직종・부서・성별・연도에 따라 내용이 달라집니다. 간호와 재활은 매년 3벌, 간호사는 격년으로, 신발은 부서와 성별에 따라 선택할 수 있는 것이 다릅니다 같은 경우입니다.

그래서 테스트 환경에 부문 × 부서 × 직종 × 성별 조합마다 1명씩 가짜 직원을 배치했습니다.

이미지는 이렇습니다 (값은 모두 가상입니다).

• 실제 명부를 가져오지 않아도, 판정 규칙을 모든 패턴으로 시험할 수 있습니다 - 가짜 데이터이기 때문에 AI에게 화면 조작을 시키거나 스크린샷을 찍어도 문제가 없습니다.

담당자용 매뉴얼의 화면 사진도 이 테스트 환경에서 브라우저를 자동 조작하여 찍고 있습니다. 화면을 수정하면 다시 찍기만 하면 됩니다.

곤란한 것은, 테스트에서는 작동하는데 실제 현장(본방)에서만 작동하지 않을 때입니다. 실제 값을 보여주고 싶은 충동이 생깁니다.

여기서는 규칙으로 미리 정해두었습니다. 값은 가리고 증상(증세)만 AI에게 전달하는 것입니다. 예를 들어 접수 창구의 전표에서는,

• 몇 바이트가 도착했는지
• 마지막으로 받은 시각
• 구분 문자(줄 바꿈 등)가 16진수로 무엇이었는지

을 알면, 번호 자체는 없더라도 '도착하지 않았는지' 아니면 '구분자가 맞지 않는지'를 구별할 수 있습니다. 이를 위해 번호를 남기지 않고, 건수・시각・에러 종류만 출력하는 조사용 화면을 처음부터 만들었습니다.

제복 신청에서는 한 단계 더 나아갔습니다 (현재 시험 중).

• 직원의 이름은, **처음과 마지막 글자만 남긴 가림 처리(伏せ字)**로 저장하고, 읽기 발음은 버립니다 (읽기 발음이 남아 있으면 한자를 가려도 이름이 알 수 있기 때문에) - 업무상 전체 이름이 필요한 경우를 위해, 이름은 암호화된 값으로도 보관합니다. 키는 시트와 다른 장소와 관리자의 머릿속에 분산시킵니다.

시트의 내용은 이렇게 보입니다 (이미지・값은 가상입니다).

이렇게 하면, 설령 AI 연결이나 공유 설정 실수로 시트가 읽히더라도 보이는 것은 가림 처리된 것과 읽을 수 없는 문자열뿐입니다. '보여주지 않는다'는 것을 운영상의 주의에서 시스템의 속성으로 바꾼 것입니다.

저는 설계・검토・본방 반영을 담당하는 AI와, 코드를 작성하는 AI를 분리하고 있습니다. 요청은 문서로 전달합니다.

이것이 효과를 발휘한 경우가 있었습니다. 관리 화면 비밀번호에 '5회 실패 시 잠금' 기능을 추가했는데, 검토를 맡는 AI가,

잠금 기능은 로그인 화면에만 적용되어 있습니다. 관리용 다른 처리를 직접 호출하면 횟수 제한 없이 시도할 수 있다는 지적을 받았습니다. GAS의 Web 앱은 이름이 “”로 끝나지 않는 함수는 화면에서 누구나 호출할 수 있습니다. 따라서 잠금 기능을 공통 인증 처리로 옮겨서 막았습니다.

직접 작성한 사람(AI)은 자신이 만든 것의 허점을 알아차리기 어렵습니다. 인간 팀과도 같았습니다.

유니폼 신청 시스템은 처음 만들었던 버전을 검토하여 다시 만들었습니다. 이때 가장 먼저 한 일은, 손으로 기록한 자료가 아니라 실제 운영 중인 시스템 자체를 읽어보는 것이었습니다.

읽어보니,

• 신청 데이터에 회계 연도(年度) 정보가 없고, 다음 연도로 재신청하면 전년도 기록까지 취소되는 문제 - 모든 데이터를 지우는 함수가 화면에서 누구나 호출할 수 있는 곳에 남아있음 - 파일이 개인 계정의 소유물이 되어 (퇴직 시 인계 불가) 하는 문제가 발견되었습니다. 게다가, 손으로 기록한 자료에는 실제 운영 시스템에 반영하지 않은 작업 내용들이 섞여 있었습니다. 기록을 믿고 수정하다가 미완성 기능을 운영 시스템에 합치려 할 뻔했습니다.

• 'AI에게 보여주지 않는다'는 것은 주의할 점이 아니라, 보관 장소의 문제입니다. 도달하기 어려운 곳에 두면 신경 쓸 필요가 없습니다.

• 더미(Dummy)를 만드는 방법으로 테스트의 질이 결정됩니다. '조합별로 1명씩'이라면 적은 인원으로 모든 패턴을 시도할 수 있습니다. - 값이 없어도 결함 분리가 가능합니다. 이를 위해 조사 화면을 미리 만들어 두는 것입니다.

• 검토(Review)를 나누면, 스스로는 알아차릴 수 없는 허점이 발견됩니다. AI끼리도 마찬가지입니다.

세 가지 시스템 중 현재 운영 중인 것은 유니폼 신청만입니다. 접수 전표와 명찰 QR 코드는 시험 단계여서 '얼마나 편리해졌는지'에 대한 숫자는 아직 없습니다. 운영하게 되면 성과를 수치로 추가하겠습니다.

각 시스템의 기술적인 내용은 다른 글에 나누어 작성했습니다.

• 자릿수가 적은 번호를 해시가 아닌 HMAC으로 대조하는 내용(