외주에 맡긴 일의 보안은 누가 챙기나: 위탁·공급망 관리의 구조
개발을 맡기고, 운영을 위탁하고, 만들어진 소프트웨어를 들여오는 순간 보안의 경계는 회사 담장 밖으로 넓어집니다. 그 넓어진 경계를 관리하는 틀을 정리합니다.
사고는 담장 밖에서도 들어온다
보안을 처음 공부할 때는 자연스럽게 우리 회사의 서버, 우리 직원의 계정, 우리 사무실의 출입문을 떠올리게 됩니다. 그런데 요즘 조직의 일은 상당 부분 담장 밖에서 이뤄집니다. 홈페이지 개발은 외주 업체가 맡고, 고객 상담은 위탁 콜센터가 받고, 급여 계산은 외부 서비스가 처리하고, 업무 시스템은 다른 회사가 만든 소프트웨어를 들여와 씁니다. 편리하고 효율적인 방식이고, 앞으로도 더 늘어날 흐름입니다.
문제는 보안의 경계가 그만큼 넓어진다는 점입니다. 우리 시스템이 아무리 잘 관리되어도, 우리 데이터에 접근할 수 있는 협력사의 계정이 뚫리면 결과는 우리 사고가 됩니다. 실제로 침해사고 소식을 따라가 보면 공격이 대상 조직을 직접 두드리는 대신, 그 조직과 연결된 협력사나 공급된 소프트웨어를 거쳐 들어오는 구조가 자주 등장합니다. 다행인 것은 이 위험이 관리 불가능한 종류가 아니라는 점입니다. 경계가 어디까지 넓어졌는지 파악하고 단계별로 확인할 것을 정해 두면, 담장 밖의 위험도 충분히 다룰 수 있는 대상이 됩니다.
위탁과 공급망, 비슷해 보이지만 성격이 다르다
바깥과 연결되는 방식은 크게 세 갈래로 나눠 보면 정리가 쉽습니다. 첫째는 업무 위탁입니다. 고객 상담, 배송, 마케팅 대행처럼 우리 업무의 일부를 다른 회사가 대신 수행하는 형태로, 개인정보가 함께 넘어가는 경우가 많아 개인정보보호 법령도 위탁 관계에 대한 요구사항을 별도로 두고 있습니다. 세부 의무는 법령 개정에 따라 달라질 수 있으니 개인정보보호위원회의 공식 안내에서 현재 기준을 확인하는 편이 정확합니다.
둘째는 IT 외주입니다. 시스템 개발·운영·유지보수를 외부 인력이 맡는 형태로, 이들은 우리 시스템 내부에 접근 권한을 가진 채 일합니다. 권한의 깊이가 깊은 만큼 계정과 접근 통제가 관리의 중심이 됩니다. 셋째가 좁은 의미의 공급망입니다. 우리가 들여와 쓰는 소프트웨어, 그 소프트웨어가 내려받는 업데이트, 개발에 쓰이는 외부 라이브러리처럼 '만들어진 것'이 흘러 들어오는 경로입니다. 이쪽은 계약서보다 도입 검토와 업데이트 경로 관리가 핵심이 됩니다. 세 갈래 모두 '바깥과 연결되어 있다'는 공통점이 있지만 위험의 성격과 챙길 지점이 다르다는 것을 구분하는 순간, 관리가 한결 구체적으로 보이기 시작합니다.
선정에서 종료까지: 관리의 네 단계
위탁 관리는 계약서에 도장을 찍는 순간이 아니라 상대를 고르는 순간부터 시작됩니다. 선정 단계에서는 맡기려는 일의 민감도에 맞춰 상대의 보안 수준을 확인합니다. 중요한 데이터를 다루는 위탁이라면 보안 조직이 있는지, 관리체계 인증을 운영하는지, 사고 이력에 어떻게 대응했는지 같은 질문이 선정 기준에 들어가는 것이 자연스럽습니다. 계약 단계에서는 확인한 내용을 문서로 고정합니다. 보안 요구사항, 사고 발생 시 통지 의무, 재위탁을 할 때의 조건, 종료 시 자료 처리 방식이 계약서에 적혀 있어야 나중에 기댈 근거가 생깁니다.
운영 단계는 가장 길고 가장 느슨해지기 쉬운 구간입니다. 외주 인력의 계정에 필요한 만큼만 권한을 주고, 인력이 바뀌면 계정도 함께 정리하고, 약속한 보안 수준이 지켜지는지 주기적으로 점검하는 일이 여기에 들어갑니다. 마지막이 종료 단계입니다. 계약이 끝나면 발급했던 계정과 접근 권한을 회수하고, 넘겨줬던 자료가 반환되거나 파기되었는지 확인합니다. 네 단계를 한 번에 완벽하게 갖출 필요는 없습니다. 우리 조직이 지금 어느 단계를 비워 두고 있는지 아는 것만으로도 방향이 잡히고, 하나씩 채워 갈 때마다 확실히 든든해지는 것을 느낄 수 있습니다.
현장에서 자주 비는 칸
일반적으로 가장 자주 비어 있는 칸은 재위탁 파악입니다. 우리가 일을 맡긴 회사가 그 일의 일부를 다시 다른 회사에 맡기는 경우가 드물지 않은데, 두 번째 회사부터는 우리 시야에서 사라지기 쉽습니다. 계약서에 재위탁 시 사전 동의나 통지를 조건으로 넣어 두면, 보이지 않던 연결 고리가 문서 위로 올라옵니다. 다음으로 자주 비는 칸은 종료 후 계정입니다. 프로젝트가 끝났는데 외주 인력의 계정이 살아 있는 상황은 현장에서 흔히 발견되는 패턴입니다. 계약 종료 절차에 계정 회수를 항목으로 넣어 두는 것만으로 예방이 되는, 비용이 거의 들지 않는 개선입니다.
점검이 형식이 되는 경우도 있습니다. 협력사에 점검표를 보내고 서명을 받아 보관하는 것으로 점검을 마쳤다고 여기는 방식인데, 문서 왕복만으로는 실제 운영을 보기 어렵습니다. 모든 협력사를 깊이 점검할 수는 없으니, 다루는 데이터의 민감도와 접근 권한의 깊이에 따라 등급을 나눠 중요한 곳에 확인의 깊이를 더하는 방식이 현실적입니다. 이렇게 우선순위를 정해 두면 한정된 시간으로도 의미 있는 점검이 가능해지고, 담당자 입장에서도 '다 못 봤다'는 부담 대신 '중요한 곳은 확실히 봤다'는 안심을 얻을 수 있습니다.
작은 조직이 시작하는 법: 목록 한 장부터
전담 조직이 없는 작은 회사라면 이 모든 이야기가 부담스럽게 들릴 수 있습니다. 그럴수록 시작을 작게 잡는 것이 좋습니다. 첫걸음은 목록 한 장입니다. 우리가 어떤 회사에 어떤 일을 맡기고 있는지, 어떤 외부 서비스와 소프트웨어를 쓰고 있는지, 각각이 우리 데이터에 어디까지 접근하는지를 표로 적어 봅니다. 직접 만들어 보면 생각보다 연결이 많다는 사실에 놀라게 되고, 동시에 무엇부터 챙겨야 할지가 자연스럽게 보이기 시작합니다.
목록이 생기면 그다음은 순서대로입니다. 민감한 데이터를 다루는 위탁부터 계약서에 보안 조항이 있는지 확인하고, 외부 인력 계정의 권한과 생존 여부를 점검하고, 계약 종료 시 확인할 항목을 짧은 절차로 만들어 둡니다. 하나하나는 반나절이면 할 수 있는 일이지만, 쌓이면 조직의 보안 수준을 실질적으로 끌어올립니다. 위탁·공급망 관리는 협력사를 의심하는 일이 아니라, 함께 일하는 관계를 오래 건강하게 유지하는 장치에 가깝습니다. 경계가 넓어진 만큼 관리의 틀도 함께 넓혀 두면, 바깥과 연결된 편리함을 훨씬 가벼운 마음으로 누릴 수 있습니다.
초보자가 자주 하는 실수
- 위탁 목록 없이 관리하기 — 누구에게 무엇을 맡겼는지 모르면 점검도 계정 회수도 시작할 수 없어, 관리 전체가 공중에 뜹니다.
- 계약서에 보안 조항 없이 일 시작하기 — 사고 통지·재위탁 조건·종료 시 자료 처리가 문서에 없으면 문제가 생겼을 때 기댈 근거가 없습니다.
- 계약 종료를 업무 종료로만 처리하기 — 계정과 권한, 넘겨준 자료의 회수를 확인하지 않으면 관계가 끝난 뒤에도 접근 경로가 남습니다.
읽고 나서 체크리스트
- 우리 조직의 위탁·외주·도입 소프트웨어 목록을 적어 볼 수 있다
- 업무 위탁·IT 외주·공급망의 위험 성격이 어떻게 다른지 설명할 수 있다
- 선정·계약·운영·종료 네 단계에서 각각 무엇을 확인하는지 말할 수 있다
- 재위탁과 종료 후 계정 회수가 왜 자주 비는 칸인지 이해하고 있다
- 협력사를 데이터 민감도에 따라 등급으로 나눠 점검 깊이를 조절할 수 있다
자주 묻는 질문
개인정보 처리를 위탁하면 법적 책임도 함께 넘어가나요?
위탁을 했다고 해서 맡긴 쪽의 관리 책임이 사라지는 구조는 아닙니다. 개인정보보호 법령은 위탁하는 쪽에도 문서화·관리·감독 같은 역할을 요구합니다. 다만 구체적인 의무의 범위와 요건은 법령 해석과 개정에 따라 달라질 수 있으므로, 개별 사안의 판단은 개인정보보호위원회의 공식 안내나 전문가 상담으로 확인하는 것이 정확합니다.
협력사가 보안 점검을 부담스러워하면 어떻게 하나요?
점검을 감사나 추궁의 틀로 가져가면 관계가 경직되기 쉽습니다. 계약 단계에서 점검의 범위와 방식을 미리 합의해 두고, 운영 중에는 상대가 이미 갖춘 인증이나 자체 점검 결과를 활용하면 부담을 크게 줄일 수 있습니다. 서로의 보안 수준을 확인하는 일은 양쪽 모두를 지키는 장치라는 공감대가 만들어지면 협조는 자연스럽게 따라옵니다.
오픈소스 라이브러리도 공급망 관리 대상인가요?
맞습니다. 개발에 쓰이는 외부 라이브러리는 계약서가 없을 뿐 만들어진 코드가 흘러 들어오는 공급망 경로입니다. 어떤 라이브러리를 쓰고 있는지 목록을 유지하고, 알려진 취약점 정보가 나왔을 때 우리가 영향을 받는지 확인할 수 있는 상태를 만드는 것이 관리의 출발점입니다. 도구와 방법은 개발 환경마다 다르니, 우리 팀의 빌드 과정에서 자연스럽게 확인되는 방식을 찾는 것이 오래갑니다.
이 글은 입문자 기준으로 이해하기 쉽게 정리한 일반 정보이며, 내용은 운영 과정에서 순차적으로 점검·보완될 수 있습니다. 구체적인 절차나 수치는 해당 기관의 공식 안내를 기준으로 확인해주세요.