애틀랜타와 둘루스·귀넷 카운티(Gwinnett County) 일대의 한인 의사·치과의사분들에게서 자주 보는 패턴이 있습니다. 원장님 한 분, 프런트데스크의 EHR용 PC 한 대, 그리고 서버와 영상 장비가 함께 놓인 복도 창고로 시작해서, 지점 두 번째, 협진 의사나 치과의사, 늘어나는 환자 목록까지 성장해 오셨습니다. 그런데 병원과 함께 자라지 못한 것이 있습니다 — 환자 건강정보가 실제로 어디에 있고, 누가 접근할 수 있고, 노트북이 도난당하거나 하드디스크가 고장 나면 무슨 일이 벌어지는지에 대한 문서화된 답입니다. 의료·치과 병원에게 이 간극은 단순한 운영 리스크가 아니라 HIPAA 컴플라이언스 간극이고, 어떤 사고든 발생한 뒤 OCR(민권국) 조사관이나 의료소송 변호사가 가장 먼저 찾는 부분입니다.
'HIPAA 준수'는 한 번 체크하고 끝나는 항목이 아닙니다
HIPAA라는 단어를 알고, 개원할 때 뭔가에 서명했다는 것도 아는 한인 원장님이 대부분입니다. 하지만 환자 데이터가 실제로 어디에 있는지, 누가 접근할 수 있는지, 어떤 안전장치가 보호하고 있는지를 서면으로 정확히 정리해 본 분은 많지 않습니다 — 이게 바로 HIPAA 보안 규칙(Security Rule)이 실무적으로 요구하는 것입니다. 행정적 안전장치(정책, 교육, 담당자 지정), 물리적 안전장치(서버나 기기에 물리적으로 접근할 수 있는 사람), 기술적 안전장치(암호화, 접근 통제, 감사 로그)죠. 서랍 속 "우리는 HIPAA를 준수합니다"라는 바인더 한 권과, 실제로 매일 이 세 가지를 집행하는 인프라는 전혀 다른 것입니다. 그 둘 사이의 간극이 바로 실제 감사나 실제 유출 사고에서 가장 큰 피해가 나는 지점입니다.
작은 병원에서 PHI가 실제로 있는 곳 — EHR 하나만은 절대 아닙니다
성장 중인 한인 병원에서 가장 자주 발견하는, 관리되지 않는 PHI 위치들:
- 영상·PACS 파일 — 치과 엑스레이, 초음파, 스캔 이미지가 로컬 서버나 외장 드라이브에 암호화도 접근 로그도 없이 저장된 경우가 흔합니다.
- 백업 드라이브 — USB나 NAS 백업이 백업 대상 서버와 같은 방에 놓여 있어서, 사무실에 물난리·화재·도난이 나면 아무 보호 역할도 못 합니다.
- 프런트데스크 스프레드시트 — 청구, 보험, 예약 목록이 엑셀이나 구글 시트로 관리되고, 개인 이메일이나 소비자용 클라우드 계정으로 공유되는 경우가 많습니다.
- 이메일 첨부파일 — 전문의나 검사실에 보내는 의뢰서, 검사 결과, 이미지가 암호화 없이 일반 이메일로 오가고, 누가 무엇을 받았는지 기록도 없습니다.
- 환자 알림 문자와 공용 사무실 폰·태블릿 — 예약·치료 정보가 감사 기록이 전혀 없는 소비자용 메신저 앱으로 오갑니다.
- 퇴사 직원의 접근 권한 — 예전 위생사, 협진의, 프런트데스크 직원의 예약·영상 시스템 로그인이 회수되지 않은 채 남아 있습니다.
HIPAA를 준수하는 AWS 설정이 실제로 포함하는 것
AWS는 서명된 업무제휴 계약(BAA)과, 그 계약이 체결되면 PHI를 다룰 수 있는 정해진 서비스 목록을 제공합니다. "HIPAA 준수 AWS"는 사서 쓰는 제품이 아니라, 그 틀 안에서 병원이 실제로 운영되는 방식에 맞춰 구축하는 구체적인 아키텍처입니다. 실제로 어떤 모습인지 정리했습니다.
HIPAA에 맞는 AWS 설정의 구체적인 요소들과, 각각이 해결하는 문제:
- AWS와의 업무제휴 계약(BAA) — PHI가 AWS 서비스에 닿기 전에 반드시 필요한 법적 기반. 이게 없으면 나머지 어떤 조치도 보안 규칙을 충족하지 못합니다.
- 저장·전송 시 암호화 — 영상 파일, 기록, 백업이 저장 중이든 사무실과 클라우드 사이를 이동 중이든 올바른 키 없이는 읽을 수 없게 됩니다.
- 최소 권한 원칙의 IAM(접근 권한 관리) — 직원마다 역할에 필요한 시스템에만 접근하고, 퇴사 즉시 한 곳에서 접근이 차단됩니다.
- CloudTrail 감사 로그 — 누가 언제 어떤 환자 데이터에 접근했는지 타임스탬프가 찍힌 기록. 사고가 나면 OCR 조사관이나 원고 측 변호사가 가장 먼저 요구하는 바로 그것입니다.
- 테스트를 거친 자동 암호화 백업 — 영상과 기록이 일정에 따라 별도의 암호화된 위치에 백업되고, "백업이 있을 것"이라는 가정이 아니라 실제 복구 테스트 기록이 남아 있습니다.
- 멀티 지점을 위한 Site-to-Site 또는 Client VPN — 영상·예약 데이터가 소비자용 파일 공유 도구가 아니라 암호화된 터널로 사무실 간에 이동합니다.
- 문서화된 재해복구·유출통보 계획 — 기기 분실, 서버 고장, 유출 의심 상황이 발생했을 때 순서대로 무엇을 할지, 필요해지기 전에 미리 문서화해 둡니다.
오늘 당장 답할 수 있어야 할 단 하나의 질문
왜 애틀랜타·둘루스 지역에서 특히 더 중요한가
귀넷 카운티와 애틀랜타 광역권은 둘루스, 수와니, 존스크릭을 중심으로 미국에서 가장 크고 빠르게 성장하는 한인 의료·치과 병원 밀집 지역 중 하나입니다. 이런 밀집도는 진짜 장점을 만듭니다 — 소개 네트워크, 이중언어 직원, 한국어를 쓰는 의료진을 신뢰하는 환자들. 하지만 동시에 이 지역 병원들이 두 번째 지점으로 성장하거나, 협진의를 채용하거나, 긴밀한 전문가 네트워크 안에서 영상과 의뢰서를 주고받을 가능성이 더 높다는 뜻이기도 합니다 — 이 모든 것이 PHI가 관리되지 않은 채 흘러갈 수 있는 지점을 늘립니다. 서버 한 대를 쓰는 1인 병원의 노출은 작지만 실재합니다. 두 지점이 예약·영상 데이터를 공유하고, 거쳐 간 직원들이 있는 병원의 노출은 훨씬 큽니다 — 그리고 전문의처럼 한국어로든 영어로든 이 문제를 함께 짚어줄 수 있는 이중언어에 HIPAA를 아는 파트너는, 비교할 한인 병원이 적은 시장보다 이 지역에서 더 중요한 경향이 있습니다.
감사와 마이그레이션은 실제로 어떻게 진행되나
저희는 영업 제안이 아니라 쉬운 말로 하는 감사(audit)로 시작합니다 — PHI가 모든 기기와 계정에 걸쳐 지금 실제로 어디에 있는지, 누가 접근할 수 있는지, 퇴사한 직원이 아직 접근 가능한 것은 없는지, 병원의 솔직한 리스크 프로필이 무엇인지(노트북 분실, 랜섬웨어 시도, OCR 민원, 두 번째 지점 오픈) 파악합니다. 여기서부터 그 구체적인 리스크에 맞춰 AWS 아키텍처를 설계하고 단계적으로 마이그레이션합니다. 기존 시스템을 그대로 둔 채 새 환경을 병행 구축·테스트하고, 조각을 하나씩 옮깁니다 — 가장 위험하고 가장 자주 지적되는 구멍을 가장 빨리 막아주는 접근 권한 관리와 백업부터 시작해서, 영상 자료와 멀티 지점 연결로 마무리합니다. 그 기간 대부분 동안 직원들은 기존 시스템으로 계속 일하고, 전환 작업은 진료 시간 외로 예약됩니다. 마이그레이션이 끝났다고 관계도 끝나는 게 아닙니다 — 모니터링, 패치, 정기적인 접근 권한 점검이 지속 서비스로 이어집니다. 저희가 장기 클라이언트의 웹사이트와 인프라를 관리하는 방식과 똑같습니다.