"HIPAA 준수"는 모든 헬스텍 (healthtech) 랜딩 페이지에는 등장하지만, 실제 코드베이스에서는 거의 찾아볼 수 없는 문구 중 하나입니다. 그 이유는 HIPAA가 npm install로 설치할 수 있는 라이브러리로 제공되는 것이 아니라, 여러분의 아키텍처가 충족하거나 충족하지 못해야 하는 일련의 의무 사항(보안 규칙 (Security Rule), 개인정보 보호 규칙 (Privacy Rule), 침해 통지 (breach notification))이기 때문입니다. 이 포스트는 이러한 의무 사항을 실제 엔지니어링 결정 사항으로 변환합니다. 즉, 원격 의료 API를 어떻게 구조화할지, 코드는 어떤 모습인지, 그리고 "준수" 시스템을 조용히 침해 보고서로 바꿔버리는 주의사항(pitfalls)은 무엇인지 다룹니다.

예시를 위해 Node.js/Express와 PostgreSQL을 사용하지만, 여기에 나오는 모든 패턴은 Django, Spring Boot 또는 Go에 직접적으로 적용됩니다.

코드에 실제로 요구되는 HIPAA 사항

법률 용어를 걷어내고 보면, 보안 규칙 (Security Rule)은 시스템에 네 가지를 요구합니다:

• 접근 제어 (Access control) — 권한이 있는 사람만이 보호 대상 건강 정보 (PHI, Protected Health Information)를 볼 수 있으며, 필요한 최소한의 정보만 접근할 수 있어야 합니다.
• 암호화 (Encryption) — PHI는 전송 중 (in transit) 및 저장 시 (at rest) 읽을 수 없는 상태여야 합니다.
• 감사 추적 (Audit trails) — PHI에 대한 모든 접근은 누가, 무엇을, 언제 했는지 로그로 기록되어야 합니다.
• 무결성 및 가용성 (Integrity and availability) — 데이터는 몰래 변경될 수 없어야 하며, 장애 상황에서도 생존해야 합니다.

아래의 모든 내용은 이 네 가지 중 하나를 아키텍처로 표현한 것입니다.

아키텍처 개요

원격 의료 API는 PHI 노출 정도가 매우 다른 서비스들로 분해됩니다:

┌──────────────┐ ┌──────────────────────────────────┐
│ Mobile/Web │────▶│ API Gateway (TLS termination, │
│ Clients │ │ rate limiting, JWT validation) │
└──────────────┘ └───────────┬──────────────────────┘
│
┌────────────┬───────────┼────────────┬─────────────┐
▼ ▼ ▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌─────────┐ ┌──────────┐ ┌───────────┐
│ Auth │ │ Patient │ │ Consult │ │ Video │ │ Audit │
│ Service │ │ Records │ │ Booking │ │ Session │ │ Logger │
│ (no PHI)│ │ (PHI!) │ │ (PHI) │ │ (PHI) │ │ (append- │
└─────────┘ └──────────┘ └─────────┘ └──────────┘ │ only) │
└───────────┘

설계 원칙: PHI(Protected Health Information, 보호 대상 건강 정보)에 접근하는 서비스를 최소화하십시오. 인증 (Auth) 서비스는 사용자가 존재한다는 사실은 알아야 하지만, 사용자의 건강 상태에 대해서는 아무것도 몰라야 합니다. 알림 (Notification) 서비스는 "내일 예약이 있습니다"라고 보내야 하며, 절대 "부정맥 관련 심장학 진료 예약이 내일입니다"라고 보내서는 안 됩니다. PHI를 피하는 모든 서비스는 감사 (Audit) 시 방어할 필요가 없는 서비스입니다.

액세스 제어 (Access Control): 컨텍스트를 포함한 RBAC

역할 기반 액세스 제어 (RBAC, Role-based access control)는 기본 사항이지만, 의료 분야에는 컨텍스트를 포함한 RBAC가 필요합니다. 즉, 의사가 모든 환자를 볼 수 있어서는 안 되며, 현재 활성화된 진료 관계 (Care relationship)가 있는 환자만 볼 수 있어야 합니다.

// middleware/authorize.js
async function canAccessPatientRecord(req, res, next) {
const { userId, role } = req.auth; // 검증된 JWT로부터 가져옴
const { patientId } = req.params;

if (role === 'patient') {
if (userId !== patientId) {
await audit.log({ actor: userId, action: 'ACCESS_DENIED',
resource: `patient:${patientId}` });
return res.status(403).json({ error: 'Forbidden' });
}
return next();
}

if (role === 'doctor') {
// 진료 관계 확인 — 대부분의 구현에서 생략하는 부분
const relationship = await db.query(
`SELECT 1 FROM care_relationships   WHERE doctor_id = $1 AND patient_id = $2   AND status = 'active'`,
[userId, patientId]
);
if (relationship.rowCount === 0) {
await audit.log({ actor: userId, action: 'ACCESS_DENIED',
resource: `patient:${patientId}` });
return res.status(403).json({ error: 'Forbidden' });
}
return next();
}

return res.status(403).json({ error: 'Forbidden' });
}

거부된 시도 또한 로그에 기록된다는 점에 유의하십시오. HIPAA 하에서 액세스 시도는 감사 가능한 이벤트이며, 액세스 거부 패턴은 데이터 탐색을 시도하는 탈취된 계정을 감지하는 정확한 방법입니다.

암호화 (Encryption): 전송 중 (In Transit), 저장 시 (At Rest), 그리고 컬럼 단위 (In the Column)

모든 곳에서 TLS 1.2+ 사용을 전제로 합니다 (게이트웨이에서 종료하고, 내부 서비스 간에도 TLS를 사용하십시오 — HIPAA는 "내부 네트워크"를 보안 경계로 인정하지 않습니다). 디스크 수준의 암호화 (예: AWS RDS 암호화) 또한 전제로 합니다. 개발 팀들이 놓치는 계층은 가장 민감한 필드에 대한 컬럼 단위 암호화 (column-level encryption)입니다. 이를 통해 데이터베이스 덤프가 유출되거나 읽기 복제본 (read replica) 설정이 잘못되더라도 진단 정보가 노출되지 않도록 합니다.

// crypto/phi.js — 레코드별 IV를 사용하는 AES-256-GCM
const crypto = require('crypto');
const KEY = Buffer.from(process.env.PHI_ENCRYPTION_KEY, 'hex'); // KMS에서 가져오며, 절대 하드코딩하지 않음

function encryptPHI(plaintext) {
  const iv = crypto.randomBytes(12);
  const cipher = crypto.createCipheriv('aes-256-gcm', KEY, iv);
  const enc = Buffer.concat([cipher.update(plaintext, 'utf8'), cipher.final()]);
  return {
    ciphertext: enc.toString('base64'),
    iv: iv.toString('base64'),
    tag: cipher.getAuthTag().toString('base64'),
  };
}

function decryptPHI({ ciphertext, iv, tag }) {
  const decipher = crypto.createDecipheriv('aes-256-gcm', KEY, 
    Buffer.from(iv, 'base64'));
  decipher.setAuthTag(Buffer.from(tag, 'base64'));
  return Buffer.concat([
    decipher.update(Buffer.from(ciphertext, 'base64')),
    decipher.final(),
  ]).toString('utf8');
}

두 가지 운영 규칙: 키는 KMS (AWS KMS, GCP Cloud KMS, Vault)에 저장되어 정해진 일정에 따라 순환 (rotation)되어야 하며, GCM의 인증 태그 (auth tag)는 무상으로 무결성 검증 (integrity verification)을 제공합니다. 즉, 암호문이 변조되었다면 조용히 손상된 의료 데이터를 반환하는 대신 복호화 과정에서 오류를 발생시킵니다.

감사 추적 (Audit Trail): 추가 전용 (Append-Only)이 아니면 인정되지 않습니다

애플리케이션이 수정 (UPDATE)하거나 삭제 (DELETE)할 수 있는 감사 로그는 감사 로그가 아닙니다. 데이터베이스 자체에서 불변성 (immutability)을 강제하십시오:

CREATE TABLE audit_log (
  id BIGSERIAL PRIMARY KEY,
  actor_id UUID NOT NULL,
  actor_role TEXT NOT NULL,
  action TEXT NOT NULL, -- VIEW, CREATE, UPDATE, EXPORT, ACCESS_DENIED
  resource TEXT NOT NULL, -- 예: 'patient:uuid', 'consultation:uuid'
  ip_address INET,
  occurred_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- 앱 역할(app role)은 INSERT 및 SELECT만 가능합니다. 그 무엇도 UPDATE 또는 DELETE할 수 없습니다.
REVOKE UPDATE, DELETE ON audit_log FROM app_role;

쓰기(writes)뿐만 아니라 모든 PHI(개인 건강 정보) 읽기(read)를 기록하십시오. "누가 이 기록을 언제 조회했는가"는 민권국(Office for Civil Rights) 조사에서 정확히 묻는 질문이며, 대부분의 시스템이 답변하지 못하는 질문입니다. 왜냐하면 대부분의 시스템은 데이터 변형(mutations)만을 기록하기 때문입니다.

화상 상담: 미디어 데이터를 서버에 보관하지 마십시오

화상 통화 자체에 PHI(대화 내용은 건강 정보임)가 포함되지만, 미디어가 귀하의 인프라에 전혀 닿지 않도록 아키텍처를 설계할 수 있습니다. HIPAA 워크플로우를 지원하고 비즈니스 파트너 계약(Business Associate Agreement, BAA)을 체결할 수 있는 WebRTC 제공업체를 사용하십시오. 이는 타협할 수 없는 사항이며, PHI에 접근할 수 있는 스택 내의 모든 벤더(비디오, 클라우드 호스팅, 이메일, SMS, 에러 트래킹, 분석 도구 등)에 적용됩니다. 귀하의 API 역할은 오직 세션 중개(session brokering)뿐입니다:

// POST /consultations/:id/video-token
// API는 수명이 짧은 룸 토큰을 발행합니다. 미디어는 우리를 거치지 않고 피어(peer)에서 제공업체(provider)로 직접 흐릅니다.
router.post('/consultations/:id/video-token',
canAccessConsultation,
async (req, res) => {
const token = videoProvider.createToken({
room: `consult-${req.params.id}`,
identity: req.auth.userId,
ttl: 900, // 15분 — 설계상 짧은 수명
});
await audit.log({ actor: req.auth.userId, action: 'VIDEO_JOIN',
resource: `consultation:${req.params.id}` });
res.json({ token });
});

녹화 기능을 활성화하는 경우, 해당 녹화본은 저장 시(at rest) PHI에 해당합니다. 따라서 의료 기록과 동일한 암호화, 접근 제어 및 감사 처리가 필요합니다. 이는 비디오 SDK가 녹화를 단 한 줄의 설정 플래그로 만들어버릴 때 쉽게 놓치기 쉬운 세부 사항입니다.

실제로 침해 사고를 유발하는 함정들

로그 내의 PHI (Protected Health Information, 보호 대상 건강 정보). 증상 엔드포인트(endpoint)에서 console.log(req.body)를 실행하는 것은 진단 데이터를 로깅 파이프라인(logging pipeline)에 그대로 기록하는 행위이며, 귀하의 로그 플랫폼은 아마도 BAA (Business Associate Agreement, 비즈니스 파트너 계약)를 체결하지 않았을 가능성이 높습니다. 개발자의 주의력에 의존하지 말고, 로거(logger) 레벨에서 PHI 필드를 제거(scrub)하세요.

URL 내의 PHI. GET /patients?name=John+Smith와 같은 요청은 PHI를 서버 액세스 로그(access logs), 브라우저 히스토리(browser history), 그리고 프록시(proxies)에 노출시킵니다. 식별자(Identifiers)는 경로(path)나 본문(body)에 포함해야 하며, 건강 데이터는 절대 쿼리 스트링(query strings)에 포함해서는 안 됩니다.

수명이 너무 긴 토큰. 가족이 공유하는 태블릿에 30일짜리 JWT (JSON Web Token)가 남아 있는 것은 무단 접근 사고가 발생하기를 기다리는 것과 같습니다. 수명이 짧은 액세스 토큰(access tokens, 약 15분)과 순환하는 리프레시 토큰(refresh tokens)을 사용하고, 서버 측 무효화(revocation) 기능을 구현하세요.

정보를 유출하는 에러 메시지.