한국영업비밀보호협회는 기업이 생성형 AI를 쓰면서도 자기 기술과 정보를 지킬 수 있도록 「10대 가이드라인」을 순차 공개하고 있습니다. 앞선 세 편에서 무엇을 지킬지 정하고(①), 규정과 교육으로 알리고(②), 쓸 도구를 고르는 절차(③)를 다뤘습니다. 오늘은 그 도구가 사람의 손을 거치지 않고 회사 시스템에 직접 접속하기 시작할 때 무엇이 달라지는지를 다룹니다.
1. 지난 회에서 이어서 ― 도구를 골랐는데, 그 도구가 스스로 움직인다면
요즘 기업이 도입하는 AI는 사내 파일서버와 기간계 시스템에 직접 접속하고, 문서를 스스로 찾아 읽고, 결과를 만들어 메일로 내보냅니다. 사람은 시작 버튼만 누릅니다.
직원 180명 규모의 정밀가공업체를 가정해 보겠습니다. 견적 회신이 늦다는 지적이 이어지자 회사는 견적 자동화 에이전트를 도입했습니다. 도면 서버와 원가 데이터베이스를 읽고 회신 메일까지 쓰게 하려면 각각의 접속 권한이 필요한데, 계정을 따로 만들고 권한을 나누는 일이 번거로웠습니다. 그래서 생산관리부장 계정의 인증정보를 그대로 넣었습니다.
넉 달 뒤, 신규 거래를 타진하던 업체 담당자가 “비슷한 사양으로 견적을 받은 적이 있는데 단가 산출 기준을 알려 달라”는 메일을 보냈습니다. 에이전트는 지시대로 유사 사례를 검색했고, 다른 고객사의 가공단가 산출표가 들어 있는 문단을 그대로 인용해 회신했습니다. 회사가 이를 알게 된 것은 두 달이나 지난 뒤였습니다.
2. 왜 에이전트는 다른 문제인가
위 사례를 통해 에이전트가 들어오면 세 가지가 바뀐다는 점을 알 수 있습니다.
첫째, 권한이 사람에서 기계로 옮겨갑니다. 기업의 정보관리는 “누구에게 무엇까지 열어 줄 것인가”를 사람 단위로 설계해 왔는데, 에이전트는 이 설계의 바깥에 있습니다. 사람 계정을 빌려 쓰면 권한 체계상으로는 아무 일도 없는 것처럼 보이지만, 실제로는 한 사람 몫의 권한이 24시간 자동으로 행사되는 상태가 됩니다.
둘째, 반출이 예외가 아니라 기본 동작이 됩니다. 종래의 반출통제는 사람이 파일을 첨부해 보내거나 저장매체에 담는 순간을 잡는 방식이었습니다. 그러나 에이전트는 이메일 발송과 외부 시스템 호출이 업무 흐름의 기본으로 설계되어 있습니다. 막아야 할 행위와 시켜야 할 행위가 같은 모양을 하고 있다는 뜻입니다.
셋째, 회사 외부에서 들어온 이메일이나 첨부문서에 지시문에 해당하는 문장이 있을 경우에도, 언어모델은 이를 회사 내부의 명령으로 읽을 수 있습니다.
3. 법적·기술적 쟁점
먼저 개인정보 층위입니다. 「개인정보의 안전성 확보조치 기준」은 개인정보처리시스템의 접근권한을 업무상 필요한 최소한의 범위로 부여하고 그 부여·변경·말소 내역을 최소 3년간 보관하도록(제5조 제1항, 동조 제3항), 접속기록은 최소 1년 이상(5만 명 이상 정보주체의 개인정보를 처리하거나 고유식별정보·민감정보를 처리하는 시스템은 2년 이상) 보관·점검하도록 정합니다(제8조 제1항). 에이전트가 그 시스템에 접속한다면 이 의무는 에이전트에게도 그대로 미칩니다. 사람 계정을 빌려 쓰는 구성은 이 기록의 의미를 사실상 무력화합니다.
영업비밀 층위입니다. 부정경쟁방지법상 영업비밀은 “공공연히 알려져 있지 아니하고 독립된 경제적 가치를 가지는 것으로서 비밀로 관리된”정보이고, 비밀관리성은 회사가 실제로 접근을 통제해 왔는지를 묻습니다. 사람이든 기계든 마찬가지입니다(다만, 아직 에이전트에 부여한 권한이 비밀관리성 판단에서 어떻게 평가되는지를 정면으로 판시한 국내 판례는 아직 확인되지 않습니다).
마지막으로 에이전트를 도입하면 프롬프트, 모델 출력, 도구 호출 내역이 로그로 남는데, 그 안에는 도면 수치와 공정 조건과 단가표가 들어 있을 수 있습니다. 우리가 지켜야 할 자료가 ‘로그’라는 이름으로 한 벌 더 복제될 수 있다는 뜻입니다. 접근 통제를 엄격히 걸어 둔 원본 파일의 내용이 정작 로그 저장소에서는 느슨하게 놓여 있는 경우를 드물지 않게 봅니다. <가이드라인 ① 입력금지 정보 분류>에서 정한 입력금지 정보 분류는 입력 단계뿐 아니라 로그 저장소에도 똑같이 적용되어야 합니다.
4. 기업은 무엇을 갖춰야 하는가
가. 에이전트에 사람 계정을 물리지 않습니다
에이전트 전용 계정을 따로 만들고, 그 계정에 업무 수행에 필요한 최소한의 권한만 부여하세요. 사람 계정을 빌려 쓰면 사고가 났을 때 누가 한 일인지 특정할 수 없고, 아무 잘못이 없는 직원이 의심을 받으며, 회사는 접근을 통제해 왔다고 설명할 근거를 잃게 됩니다.
나. 승인 지점을 ‘경계를 넘는 행위’에 둡니다
사람이 모든 단계를 확인하면 에이전트를 쓸 이유가 없어집니다. 읽고 정리하는 단계는 자동으로 두되, 어떠한 ‘경계’를 넘는 행위에만 승인을 걸어 실효성과 효율을 확보해야 합니다. 외부로 나가는 메일과 파일, 회사 밖 시스템 호출, 기준정보나 원가 데이터의 변경, 대량 조회·다운로드가 그 지점이 될 수 있습니다.
다. 에이전트가 호출할 수 있는 도구를 특정하고, 검색 대상은 미리 나눕니다
에이전트가 호출할 수 있는 도구와 접근할 수 있는 시스템 목록을 만들어 명시적으로 한정하세요. 메일 본문이나 첨부문서처럼 외부에서 들어온 내용은 처리 대상 자료일 뿐 지시가 아니라는 점도 시스템 설계와 운영 규정 양쪽에 못 박아야 합니다.
검색 색인에도 <가이드라인 ① 입력금지 정보 분류>의 입력금지 정보 분류를 적용하세요. 넣을 자료와 넣지 않을 자료를 먼저 나누고, 질의하는 사람의 권한에 따라 검색 범위가 달라지도록 구성하는 것이 원칙입니다. “일단 전자 문서를 다 집어넣고 나중에 정리하자”로 시작하게 되면 나중에 정리할 방법이 없습니다.
5. 실무에서 자주 나오는 질문
Q. 로그가 그 자체로 위험하다면, 덜 남기는 것이 낫습니까?
그렇지 않습니다. 남기지 않으면 사고가 났을 때 아무것도 설명하지 못하고, 개인정보처리시스템과 연결된 경우에는 법정 의무 위반이 될 수 있습니다. 방향은 ‘덜 남기기’가 아니라 ‘남기되 지키기’입니다. 로그 저장소에 원본 문서와 같은 등급의 접근 통제를 걸고, 열람 사실을 기록하며, 보존기간을 정해 두십시오.
Q. 에이전트가 잘못 보낸 자료도 회사가 책임집니까?
민형사상 책임은 사안마다 달라 일반화하기 어렵습니다. 다만 금융 분야에서는 외부 사업자가 제공하는 AI 모델이나 오픈소스 기반 AI를 활용하더라도 책임은 그것을 활용하는 금융회사에 귀속된다는 취지가 감독당국 가이드라인에 담겼습니다. 금융 분야에 한정된 가이드라인이라 제조업에 그대로 적용되는 규범은 아니지만, “도구를 빌려 썼다”는 사정만으로 책임이 옮겨가지는 않는다는 규제당국의 시각은 참고할 만합니다.
6. 맺으며
에이전트를 도입하는 일은 새로운 직원을 뽑는 일과 같습니다. 다만 이 직원은 쉬지 않고, 판단 근거를 스스로 설명하지 않으며, 외부에서 들어온 메일을 회사 지시로 오인할 수 있습니다. 그런 직원에게 어느 문을 열어 줄 것인지, 무엇을 혼자 내보내게 할 것인지, 무슨 일을 했는지, 어떻게 남길 것인지는 에이전트를 도입함에 있어 필수적인 검토 요소입니다.
