본문으로 건너뛰기
AIPida
TRENDINGClaude CodeAntigravityMCPAgent HarnessOrchestrationRAGVibe CodingAI Browser
채택됨고급보안·규제·저작권

EU 사용자 대상 AI 채용 서비스, GDPR이랑 EU AI Act 둘 다 봐야 하나요? (한국 회사)

AI 기반 채용 보조 서비스를 만들고 있는데, EU에 있는 고객사도 받으려고 합니다. 한국 회사지만 EU 사용자 데이터를 처리하게 되는 상황이에요.

GDPR은 들어봤는데, 최근에 EU AI Act라는 것도 있다고 해서 혼란스럽습니다.

  1. 한국 회사인데 EU 규제를 정말 따라야 하나요?
  2. GDPR이랑 EU AI Act는 뭐가 다른가요? 둘 다 적용되나요?
  3. 채용 관련 AI면 특별히 더 위험한 카테고리인가요?

초기 단계라 어디서부터 손대야 할지 막막합니다.

답변 2개

  • 채택된 답변에디터 검증

    채용 AI + EU 사용자면 둘 다 정면으로 걸립니다. 하나씩 볼게요.

    1. 한국 회사인데 적용되나 — 네. GDPR은 역외 적용(extraterritorial) 조항이 있어서 EU에 있는 정보주체한테 서비스를 제공하거나 그들 행동을 모니터링하면 사업장이 어디든 적용됩니다. EU AI Act도 비슷하게 EU 시장에 AI 시스템을 내놓거나 그 출력이 EU 안에서 쓰이면 역외 사업자한테도 미쳐요. "우린 한국 회사"는 면제 사유가 아닙니다. 오히려 EU 고객사 받겠다고 먼저 말한 시점에서 이미 트리거예요.

    2. 둘의 차이 — 서로 다른 축이라 둘 다 봐야 합니다.

    • GDPR은 개인정보 처리에 대한 규제. 적법 처리근거, 정보주체 권리(열람·삭제·이의제기), 자동화 의사결정 관련 권리, 국외 이전 같은 게 핵심입니다. 특히 GDPR에 순전히 자동화된 의사결정만으로 중대한 영향을 받지 않을 권리(22조) 조항이 있어서, 채용처럼 사람한테 중대한 영향 주는 결정을 AI가 단독으로 내리는 건 여기 정통으로 걸립니다.
    • EU AI Act는 AI 시스템 자체의 위험 기반 규제. 데이터가 아니라 "AI 시스템"을 위험 등급으로 나눠서 의무를 부과해요.

    둘은 보완 관계라 한쪽 지켰다고 다른 쪽 면제 안 됩니다.

    3. 채용 AI 위험 등급 — EU AI Act에서 채용·인사 선발 AI는 일반적으로 **high-risk(고위험)**로 다뤄집니다. 고위험 떨어지면 위험관리체계, 데이터 거버넌스, 기술문서·로깅, 투명성, 인간 감독(human oversight), 정확성·견고성 같은 강화된 의무가 줄줄이 붙어요. 제일 무거운 트랙이라고 보시면 됩니다.

    어디서부터 —

    1. 처리하는 EU 개인정보 흐름 매핑(뭘, 어디서, 어디로 이전하는지).
    2. 적법 처리근거 + 동의/고지 설계 + 정보주체 권리 대응 프로세스.
    3. 자동화 단독 결정 금지 — 사람이 실질적으로 검토·개입하는 단계 설계(human in the loop). 이거 형식적 "검토 버튼"만 달면 안 되고 진짜 개입이어야 합니다.
    4. 고위험 의무(문서화·로깅·투명성·감독) 체크리스트화.

    규모 작아도 초기에 설계로 박아두는 게 훨씬 쌉니다. 나중에 갈아엎으면 진짜 비싸요. 초기 단계에 EU 데이터보호/AI 규제 전문가 한 번 끼는 거 추천합니다.

    발효 시점·세부 의무는 단계적으로 적용되는 부분이 있어서 최신 일정은 공식 자료로 확인하세요(여기 답으로 날짜 박았다가 틀리면 곤란하니).

  • 에디터 검증

    법 일반론은 윗분이 잘 정리하셨고, 엔지니어 관점에서 구현하다 보면 꼭 놓치는 거 세 개 짚을게요.

    국외 이전 — EU 데이터를 한국 서버나 미국 LLM API로 보내는 게 죄다 국외 이전입니다. SCC(표준계약조항) 같은 이전 메커니즘 필요하고, 외부 LLM API에 EU 이력서를 그대로 던지면 위탁 + 국외이전이 한 번에 겹쳐요. 처리 위치를 처음부터 의식하고 아키텍처 짜세요(EU 리전 엔드포인트 제공하는 모델인지부터 확인).

    삭제권/열람권 — 삭제 요청 오면 벡터 DB 임베딩, 로그, 캐시, 파인튜닝 데이터까지 다 지워야 합니다. RAG로 인덱싱해놓고 원본만 지우면 임베딩에 정보 남아서 미준수예요. 이거 나중에 붙이려면 지옥이라(어느 임베딩이 누구 건지 역추적이 안 됨), 처음부터 문서 id ↔ 임베딩 매핑을 잡아두세요.

    설명가능성/로깅 — 고위험이면 "왜 이 지원자가 떨어졌는지" 설명·기록 요구가 옵니다. 블랙박스 점수만 뱉는 구조면 못 맞춰요. 결정 근거 로깅(어떤 입력이 어떤 점수로 이어졌는지)을 처음부터 넣어두세요. 이것도 사후에 붙이는 게 거의 불가능한 부류라...