5.4규제 요구를 설계 제약으로 옮기기

시험에서도 실무에서도 아키텍트에게 요구되는 것은 규정을 인용하는 능력이 아니라, 규정이 시스템 설계에 무엇을 강제하는지 아는 것입니다. 규정 이름이 무엇이든 설계에 도착하는 제약은 대체로 여섯 갈래로 수렴합니다.

1. 데이터 최소화 — 목적에 필요한 것만 수집하고 전달합니다.
2. 목적 제한 — 수집한 목적 외로 쓰지 않습니다. 운영 로그를 모델 개선에 재사용하는 것이 대표적 쟁점입니다.
3. 보관 기간 — 언제 지울지 정하고 실제로 지워지는지 확인합니다.
4. 소재지와 이동 — 데이터가 어느 지역에 머무는지, 국경을 넘는지.
5. 주체 권리 대응 — 열람·정정·삭제 요청에 답할 수 있는 구조.
6. 감사 추적 — 누가 무엇을 언제 했는지 재구성할 수 있는 기록.

이 여섯 가지는 규제마다 강조점과 세부 요건이 다르지만, 설계 산출물의 형태는 비슷합니다. 데이터 흐름도, 데이터 대장, 보관 정책, 접근 통제 매트릭스, 감사 로그 명세입니다. 특정 규제가 적용되는지, 어느 조항이 어떻게 적용되는지는 반드시 법무와 컴플라이언스의 판단을 거쳐야 하며, 아키텍트는 그 판단을 받아 설계로 옮기는 역할을 맡습니다.

시험에서는 "이 요구사항을 만족하려면 아키텍처를 어떻게 바꿔야 하는가"를 묻습니다. 조항 번호를 외우는 것은 출제 범위가 아닙니다.

LLM 시스템에서 개인정보가 새는 지점은 데이터베이스가 아니라 대체로 프롬프트와 그 파생물입니다. 프롬프트에 개인정보가 한 번 들어가면 다음으로 복제됩니다.

• 애플리케이션 로그와 요청 기록
• 관측성 도구의 트레이스와 스팬 속성
• 프롬프트 캐시
• 평가 데이터셋과 회귀 테스트 픽스처
• 오류 리포트와 재현용 덤프

원본 데이터베이스에는 접근 통제를 촘촘히 걸어 두고 정작 이 다섯 곳은 통제 밖인 경우가 많습니다. 설계 원칙은 저장 전 처리입니다.

# 로깅 전에 식별자를 치환하고, 원본은 별도 보관소에서 통제한다
def redact_for_log(prompt: str, subject_id: str) -> str:
    # 이름·연락처·계좌 등은 자리표시자로 바꾸고 매핑은 남기지 않는다
    return PII_PATTERN.sub("[redacted]", prompt)

log.info(
    "model_request",
    extra={
        "prompt": redact_for_log(prompt, subject_id),
        "subject_ref": pseudonymize(subject_id),  # 되돌릴 수 있는 키는 분리 보관
        "retention_class": "ops_30d",             # 보관 정책을 데이터에 붙인다
    },
)

마지막 줄의 retention_class가 실무에서 중요한 장치입니다. 보관 기간을 정책 문서가 아니라 데이터에 붙여 두면, 삭제 작업을 자동화할 수 있고 어떤 데이터가 언제 지워지는지 감사에서 보일 수 있습니다.

관측성 도구를 붙일 때도 같은 판단이 필요합니다. 도구가 프롬프트 본문과 도구 입출력을 그대로 수집하도록 켤 수 있는 경우가 많은데, 이는 진단 능력을 크게 높이는 대신 노출면을 넓힙니다. 기본은 끄고, 필요한 환경에서 기간을 정해 켜는 것이 안전한 기본값입니다.

삭제 요청 대응은 규제 준수 설계에서 가장 자주 실패하는 지점입니다. 이유는 단순합니다. 어떤 데이터가 어디에 있는지 추적하지 못하면 지울 수 없습니다.

필요한 것은 두 가지입니다.

소재 대장 — 개인 데이터가 저장되는 모든 위치를 목록으로 관리합니다. 데이터베이스뿐 아니라 앞 절에서 본 로그·트레이스·캐시·평가셋·백업이 모두 들어갑니다.

상관 식별자 — 한 주체의 데이터를 모든 저장소에서 찾을 수 있는 키입니다. 저장소마다 다른 식별자를 쓰면 삭제 요청 하나에 수작업 조사가 필요해집니다.

파생물 처리가 특히 까다롭습니다. 검색용 임베딩, 요약본, 캐시된 응답, 평가 데이터셋에 들어간 사례는 원본을 지워도 남습니다. 설계 단계에서 결정해야 할 것은 다음입니다.

• 파생물에 원본과의 연결 고리를 남길 것인가 (남기면 삭제가 가능하지만 연결 자체가 개인정보가 될 수 있습니다)
• 파생물을 아예 비식별 상태로 만들 것인가 (삭제 부담은 줄지만 품질과 추적성이 떨어집니다)
• 평가셋에는 실데이터 대신 합성 데이터를 쓸 것인가

정답이 하나로 정해져 있지 않고 시스템의 목적과 위험도에 따라 달라지는 트레이드오프라는 점이 이 영역의 특징입니다. 시험에서도 단일 정답보다는 주어진 제약에서 가장 합리적인 선택을 고르는 형태로 나옵니다.

감사 추적의 목적은 사후에 무슨 일이 있었는지 재구성하는 것입니다. LLM 시스템에서 재구성에 필요한 최소 항목은 다음과 같습니다.

• 누가 — 요청 주체와 실행 주체(사람인지 에이전트인지)
• 언제 — 요청과 응답의 시각
• 무엇을 근거로 — 사용된 모델, 프롬프트 버전, 검색된 문서 식별자
• 어떤 도구를 — 호출된 도구와 인자 요약, 결과 상태
• 누가 승인했는가 — 사람 개입이 있었다면 승인자와 승인 시각
• 결과 — 실행된 행동과 그 결과

여기서 자주 빠지는 것이 프롬프트 버전입니다. 시스템 프롬프트가 바뀌면 같은 입력이라도 다른 결과가 나오므로, 버전 없이는 과거 사례를 재현할 수 없습니다. 프롬프트를 코드처럼 버전 관리하고 요청 기록에 버전을 남기는 것이 기본입니다.

audit.record({
    "actor": {"kind": "agent", "id": agent_id, "on_behalf_of": user_id},
    "prompt_version": PROMPT_VERSION,      # 재현에 필수
    "model": model_name,
    "retrieved_doc_ids": [d.id for d in docs],
    "tools": [{"name": t.name, "status": t.status} for t in tool_calls],
    "approval": {"by": approver_id, "at": approved_at} if approver_id else None,
    "outcome": {"action": action_kind, "result": result_status},
})

주의할 점은 감사 로그 자체가 개인정보를 담는 저장소가 된다는 것입니다. 감사 로그에도 보관 기간과 접근 통제가 필요하며, 여기에 프롬프트 본문을 통째로 남기면 앞 절에서 다룬 노출면 문제가 그대로 재현됩니다. 재구성에 필요한 최소 항목만 남기고, 본문이 필요한 경우에는 별도 통제하에 짧은 기간만 보관하는 설계가 일반적입니다.