시스템은 우리가 샀는데, 서버는 공급 업체의 클라우드(Cloud)에 있습니다. 그렇다면 데이터가 잘못됐을 때 규제기관은 누구를 부를까요? 이 질문 하나로 공급자 관리(Supplier Management)의 무게가 결정됩니다. 앞서 다룬 EU GMP Annex 11 개정 소식에서 “공급자·클라우드 책임이 계약으로 내려온다”고 짧게 언급했는데, 이번 포스팅에서는 그 항목만 따로 떼어 정의, 왜 지금 더 중요해졌는지, 계약에 담아야 할 요소, 실무와 취업 관점의 착지까지 정리해 보겠습니다.
공급자 관리의 정의
공급자 관리는 회사가 직접 만들지 않고 외부에서 들여오는 시스템·서비스·원자재의 공급 주체가 우리 품질 요구 수준을 충족하는지 평가하고 지속 관리하는 활동입니다. 여기서 공급 주체는 컴퓨터화 시스템(Computerised System) 개발사, 소프트웨어를 클라우드로 제공하는 서비스 사업자, 시험을 대신 수행하는 외부업체(Third Party)까지 넓게 포함됩니다.
핵심은 관점의 전환입니다. “좋은 제품을 파는 회사인가”가 아니라 “우리 GMP 책임을 함께 질 수 있는 파트너인가”를 봐야 한다는 것이죠. 이렇게 회사 밖에서 이루어지는 업무를 규제에서는 아웃소싱 활동(Outsourced Activities)이라 부르며, 위탁을 준다고 해서 책임까지 넘어가지 않는다는 원칙이 오래전부터 명문화돼 있습니다.
왜 지금 더 중요해졌을까요
2011년에 만들어진 옛 Annex 11은 회사 서버실에 놓인 컴퓨터를 전제로 쓰였습니다. 그런데 그사이 실험실과 제조 현장은 SaaS·클라우드로 빠르게 옮겨갔는데요. 시험 데이터가 어디에 저장되는지, 점검 기록(Audit Trail)을 우리가 언제든 볼 수 있는지, 서비스가 끊기면 데이터를 어떻게 되찾을지 — 이런 질문에 옛 규정은 답을 주지 못했습니다.
2026년 최종화가 임박한 Annex 11 개정본은 바로 이 공백을 메웁니다. 특히 “공급자·클라우드로 책임이 이전되지 않는다”는 원칙을 분명히 하고, 서비스 계약에 담아야 할 필수 항목을 구체적으로 요구합니다. 규제 문서를 인용할 때는 반드시 원문을 확인해야 하므로, 세부 조항은 아래 규제기관 원문 링크에서 최신본을 확인하시기 바랍니다.
계약에 담아야 할 핵심 요소
개정본은 클라우드·서비스 제공자와의 계약에 담아야 할 내용을 약 9개 항목 수준으로 명시하는 방향입니다. 실무에서 계약서·품질 협약서(Quality Agreement)를 검토할 때 빠지면 안 되는 대표 요소를 정리하면 다음과 같습니다.
- 제공 서비스의 활동 범위와 책임 분계: 무엇을 공급자가, 무엇을 회사가 책임지는지 경계를 명확히 합니다.
- 규제 준수 의무: 공급자도 관련 GMP 요구사항을 따른다는 약속.
- 보고 체계: 장애·보안 사고·데이터 이상 발생 시 회사에 알리는 통로와 기한.
- 실사(Inspection) 협조 조건: 규제기관 또는 회사의 공급자 감사(Audit)에 응할 의무.
- 데이터 반출·이관 전략: 계약 종료 시 우리 데이터를 원본성·가독성을 유지한 채 되돌려받는 방법.
- 점검 기록·접근권한의 관리 책임과 보존 조건.
이 요소들은 표준작업지침서(SOP)와 품질 협약서에 흩어져 있기 쉬운데, “누가 무엇을 책임지는가”를 한 장의 책임 분계표(Responsibility Matrix)로 정리해 두면 실사나 공급자 감사에서 훨씬 안정적으로 대응할 수 있습니다.
실무에서는 어떻게 돌아갈까요
실무의 출발점은 공급자 적격성평가(Qualification)입니다. 신규 시스템을 도입할 때 QA/QC는 공급자에게 품질 시스템·개발 방식·데이터 완전성(Data Integrity) 통제 수준을 묻는 평가서(설문 또는 현장 감사)를 보냅니다. 위험도가 높은 시스템일수록 서면 평가에 그치지 않고 직접 방문 감사로 이어집니다.
▶ 그런데 “클라우드 회사가 알아서 백업하니 우리는 신경 안 써도 되지 않나요?”라는 질문을 자주 받습니다. 답은 단호하게 “아니오”입니다. 규제 책임은 제조·품질 승인을 받은 회사에 잔존합니다. 서버가 남의 것이어도, 데이터가 신뢰할 수 있는지 보증하는 의무는 우리에게 남습니다.
또 하나 놓치기 쉬운 점은 공급자 관리가 도입 시점의 일회성 활동이 아니라는 것입니다. 계약 이후에도 서비스 수준(SLA) 준수 여부를 주기적으로 확인하고, 위험도에 따라 정해진 주기로 재평가·감사를 반복해야 합니다. 공급자가 시스템을 업데이트하면 우리 쪽 밸리데이션 상태에 영향이 없는지도 함께 살펴야 하죠. 즉 공급자 관리는 품질 시스템 안에서 계속 돌아가는 순환 활동입니다.
구체적인 예를 들어 보겠습니다. 어떤 시험실이 클라우드형 실험실 정보 관리 시스템(LIMS)을 쓰는데, 함량 시험 결과의 점검 기록을 회사 담당자가 직접 조회할 권한이 계약에 없다고 가정해 봅시다. 실사에서 조사관이 “결과가 수정된 이력을 보여 달라”고 요청했을 때 “공급자에게 문의해야 한다”고 답한다면, 이는 곧 데이터 완전성 통제가 회사 손을 벗어나 있다는 지적으로 이어집니다. 계약 단계에서 접근권한과 점검 기록 조회 조건을 확보해 두는 일이 그래서 중요합니다.
취업과 실무, 어디에 쓰일까요
공급자 관리는 컴퓨터화 시스템 밸리데이션(Validation), 아웃소싱, 데이터 완전성이 만나는 지점이라 QC/QA 직무에서 점점 비중이 커지고 있습니다. 면접에서 “클라우드 시스템을 GMP 환경에서 쓸 때 무엇을 확인하겠느냐”는 질문을 받는다면, 공급자 적격성평가 → 계약(품질 협약서)의 필수 요소 → 책임 분계 → 데이터 반출 전략 순으로 답의 뼈대를 세우면 논리가 흐트러지지 않습니다.
정리하면, 공급자 관리의 본질은 “위탁은 하되 책임은 남긴다”입니다. 시스템 밸리데이션의 앞뒤 맥락이 궁금하시다면 컴퓨터화 시스템 밸리데이션(CSV) 글과 접근권한 관리 글을 함께 참고하시면 개념이 한결 또렷해집니다. Annex 11 개정 원문은 EMA GMP 가이드라인 페이지에서 최신본을 확인하실 수 있습니다.