휴가 뒤 AI R&D 접근권한을 전수 점검해봤더니

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

8월 말, 휴가에서 돌아온 연구원이 실험 서버에 접속하지 못하는 일이 생겼습니다. 처음에는 비밀번호 오류로 여겼지만 확인해보니 퇴사자의 API 키는 살아 있고, 외부 협력사 계정에는 관리자 권한이 남아 있었습니다. AI R&D 접근권한은 평소보다 사람이 자주 바뀌는 여름휴가 직후에 허점이 선명하게 드러납니다.

연구 속도를 이유로 임시 권한을 넓혀주고 회수는 나중으로 미룬 적이 있나요? 모델 저장소, 학습 데이터, GPU 서버, 상용 AI API가 연결된 환경에서는 계정 하나의 과도한 권한이 비용 유출과 기술자료 반출로 이어질 수 있습니다. 실제 점검에서는 보안 솔루션을 새로 사는 것보다 누가 무엇에 왜 접근하는지를 다시 적는 작업이 먼저였습니다.

휴가철이 지나자 임시 권한이 한꺼번에 보였습니다

사람보다 오래 남는 계정과 토큰

AI 연구 조직은 일반 사무 조직보다 권한 구조가 복잡합니다. 연구원은 Git 저장소와 데이터 스토리지에 접근하고, 개발자는 배포 환경과 컨테이너 레지스트리를 사용하며, 외부 파트너는 특정 데이터셋이나 데모 서버를 함께 봅니다. 여기에 실험 자동화용 서비스 계정과 API 토큰까지 더해지면 인원 명단만 확인해서는 실제 접근 범위를 알기 어렵습니다.

점검 첫날에는 인사 명부와 시스템 계정 목록을 대조했습니다. 그 결과 휴가 대체 근무를 위해 부여한 권한, 종료된 PoC의 공유 계정, 담당자가 기억하지 못하는 장기 토큰이 발견됐습니다. 특히 개인 계정은 삭제됐지만 그 사람이 만든 액세스 키가 CI 파이프라인에서 계속 사용되는 사례가 까다로웠습니다.

• 휴면 계정: 최근 60~90일 동안 로그인 기록이 없지만 활성 상태인 계정
• 임시 관리자 권한: 장애 대응이나 휴가 대체를 위해 높였다가 되돌리지 않은 권한
• 소유자 불명 토큰: 발급 목적과 만료일, 담당 부서가 기록되지 않은 API 키
• 종료 프로젝트 계정: 실험은 끝났지만 저장소와 클라우드 역할이 남아 있는 계정

권한 점검의 출발점은 계정을 바로 삭제하는 것이 아니라 업무 목적과 현재 소유자를 확인하는 것입니다. 소유자를 찾지 못한 권한은 유지 사유도 입증하기 어렵습니다.

기술연구 조직의 역할과 책임 범위를 살펴볼 때는 한국과학기술연구원 관련 지식백과처럼 연구기관의 기능을 설명한 자료도 참고할 수 있습니다. 조직 형태는 달라도 연구, 운영, 기술지원의 책임을 분리해 보는 관점은 권한 설계에 유용합니다.

AI R&D 자산을 네 묶음으로 나누니 점검이 빨라졌습니다

코드·데이터·연산·외부 API를 따로 보기

모든 시스템을 한 장의 계정표에 넣으면 빠진 항목을 알아채기 어렵습니다. 그래서 자산을 소스코드, 연구 데이터, 연산 인프라, 외부 AI 서비스의 네 묶음으로 나눴습니다. 같은 연구원이라도 코드 열람은 필요하지만 원본 개인정보 데이터의 다운로드 권한까지 필요한 것은 아닙니다.

각 묶음에는 ‘조회, 생성, 변경, 삭제, 권한 부여’ 다섯 단계의 행동을 붙였습니다. 예를 들어 모델 평가 담당자는 결과 테이블을 조회하고 새 평가 기록을 생성할 수 있지만, 원본 데이터를 삭제하거나 다른 사용자에게 권한을 줄 필요는 없습니다. 이렇게 행동 단위로 쪼개자 직책명만으로 권한을 부여할 때 생기던 과잉 허용이 줄었습니다.

점검표에 반드시 들어갈 항목

1. 자산 이름과 보관 위치를 기록합니다. 클라우드 프로젝트명과 저장소 주소도 함께 적습니다.
2. 계정 유형을 개인, 공용, 서비스 계정으로 구분하고 실사용자를 연결합니다.
3. 현재 권한과 업무상 필요한 최소 권한을 나란히 표시합니다.
4. 마지막 사용 시점과 최근 권한 변경일을 확인합니다.
5. 승인자, 재검토일, 회수 조건을 정해 다음 점검의 근거를 남깁니다.

기업 기술 조직의 자산과 사업 구조를 이해하는 참고 자료로는 우리기술 기업 정보도 활용할 수 있습니다. 특정 기업의 권한 체계를 그대로 따르기보다, 연구 결과가 제품과 사업 시스템으로 이동할 때 관리 대상이 어떻게 넓어지는지 살펴보는 용도입니다.

권한을 줄이기 전에 사용 기록부터 확인했습니다

즉시 차단과 단계적 회수를 구분하기

점검에서 가장 위험한 선택은 과도한 권한을 발견하자마자 전부 끊는 것입니다. 학습 파이프라인이 공용 토큰에 의존하고 있다면 토큰 폐기와 동시에 야간 학습, 모델 평가, 결과 업로드가 멈출 수 있습니다. 반대로 유출 정황이 있거나 퇴사자가 쓰던 개인 키라면 영향 분석만 하며 기다릴 사안도 아닙니다.

저희는 위험도와 운영 의존성을 기준으로 회수 순서를 정했습니다. 외부 접속이 가능하고 관리자 수준이며 소유자가 불명확한 권한은 최우선으로 중지했습니다. 정상 파이프라인에서 사용 중인 장기 키는 새 서비스 계정을 만들고 비밀 저장소로 옮긴 뒤 기존 키를 폐기했습니다.

• 즉시 중지: 퇴사자 계정, 공개 저장소에 노출된 키, 사용 주체를 확인할 수 없는 관리자 토큰
• 당일 교체: 여러 사람이 공유하는 클라우드 키, 메신저로 전달된 비밀번호, 만료일 없는 외부 API 키
• 전환 후 회수: 자동 학습과 배포 작업이 참조하는 서비스 계정, 레거시 장비의 고정 계정
• 관찰 후 조정: 사용 빈도는 낮지만 규제 대응이나 장애 복구에 필요한 읽기 전용 권한

로그에서 확인한 세 가지 신호

로그는 단순히 로그인 성공 여부만 보지 않았습니다. 평소와 다른 국가나 시간대의 접속, 대량 다운로드, 짧은 시간에 반복된 권한 변경을 함께 확인했습니다. 8월 휴가 기간에는 본인이 아닌 대체 담당자가 업무를 처리할 수 있으므로 이상 행동처럼 보여도 정당한 사유가 있을 수 있습니다. 따라서 자동 경고와 담당자 확인을 묶어 오탐으로 인한 업무 중단을 줄였습니다.

접속 기록이 없다는 사실은 안전하다는 뜻이 아닙니다. 로깅이 꺼져 있거나 보존 기간이 지나 기록 자체가 사라졌는지도 반드시 확인해야 합니다.

9월 프로젝트 시작 전에 승인 방식을 바꿨습니다

상시 권한보다 기간제 권한이 관리하기 쉬웠습니다

가을에는 신규 과제와 하반기 PoC가 동시에 시작되기 쉽습니다. 이때 급하게 만든 공유 폴더와 클라우드 역할이 연말까지 남지 않도록, 권한 신청 단계에서 종료일을 필수로 받았습니다. 2주짜리 데이터 검수 업무라면 권한도 2주 뒤 자동 만료되게 설정하고, 연장이 필요할 때 다시 업무 사유를 확인했습니다.

관리자 권한은 상시 부여 대신 필요한 시간에만 활성화하는 방식을 적용했습니다. 접근 요청자가 대상 시스템, 필요한 행동, 사용 기간을 적고 자산 책임자가 승인하도록 했습니다. 승인 기록이 티켓이나 협업 도구에 남으니 나중에 ‘왜 이 권한이 있었는가’를 사람의 기억에 의존하지 않아도 됐습니다.

• 원본 데이터 다운로드는 데이터 책임자의 별도 승인을 받습니다.
• 운영 모델 교체 권한과 연구 모델 등록 권한을 분리합니다.
• 외부 협력사 계정에는 접속 가능 시간과 네트워크 범위를 제한합니다.
• 공용 계정이 불가피하면 비밀번호 보관 위치와 사용 기록 책임자를 정합니다.
• 프로젝트 종료일 7일 전에 소유자에게 연장 또는 회수 알림을 보냅니다.

도구 비용보다 먼저 계산할 운영 항목

소규모 팀은 별도 권한관리 제품 없이도 클라우드 IAM, Git 조직 기능, 비밀 저장소와 스프레드시트를 조합해 시작할 수 있습니다. 다만 계정이 수십 개를 넘고 여러 클라우드를 함께 쓰면 수작업 대조 시간이 빠르게 늘어납니다. 유료 도구의 가격만 볼 것이 아니라 월별 검토 인력, 감사 로그 보존, 자동 만료와 승인 연동에 드는 시간을 함께 계산해야 합니다.

도구를 도입해도 자산 소유자가 정해지지 않으면 알림만 늘어납니다. 먼저 시스템별 책임자와 검토 주기를 확정하고, 반복 작업이 확인된 뒤 자동화를 붙이는 편이 효과적이었습니다. (주)천조기술연구원처럼 AI R&D 과제를 운영하는 조직이라면 연구 속도와 통제를 반대 개념으로 두기보다, 승인 대기 없이도 안전하게 쓸 수 있는 기본 역할을 미리 설계하는 것이 좋습니다.

연구원이 불편해하지 않게 최소 권한을 적용할 수 있을까요?

업무가 막혔을 때 빠르게 되돌릴 길을 함께 만듭니다

가장 자주 나온 질문은 “권한을 줄이면 실험 속도가 느려지지 않느냐”였습니다. 답은 최소 권한만 적용해서는 느려질 수 있지만, 신속한 임시 승격 절차를 함께 만들면 오히려 요청 시간이 짧아진다입니다. 연구원에게 무조건 안 된다고 하기보다 기본 역할로 가능한 작업과 추가 승인이 필요한 작업을 명확히 보여줘야 합니다.

예를 들어 일반 연구 역할에는 개발 데이터 조회, 실험 실행, 개인 작업 공간 쓰기를 허용합니다. 원본 데이터 반출, 고가 GPU 대량 할당, 운영 모델 변경은 별도 권한으로 분리하되 긴급 요청은 30분 또는 2시간 동안만 자동 활성화할 수 있습니다. 만료 후에는 사용 로그와 변경 내역을 남겨 다음 역할 설계에 반영합니다.

1. 요청 전: 필요한 명령이나 작업 화면을 확인해 권한 범위를 구체화합니다.
2. 승인 시: 기간, 대상 자산, 허용 행동을 지정하고 포괄적 관리자 권한은 피합니다.
3. 사용 중: 대량 다운로드와 권한 재부여 같은 고위험 행동을 기록합니다.
4. 만료 후: 작업 성공 여부와 추가로 필요했던 권한을 검토해 기본 역할을 개선합니다.

처음부터 완벽한 역할 체계를 만들 필요는 없습니다. 이번 주에는 퇴사자 계정과 소유자 없는 토큰을 처리하고, 다음 주에는 외부 협력사와 관리자 권한을 살피는 식으로 범위를 나누면 됩니다. 마지막에는 연구원 한 명을 선정해 실제 실험 준비부터 결과 저장까지 수행하게 해보세요. 막히는 지점이 발견되면 권한을 무작정 넓히는 대신 해당 행동만 기간제로 추가하는 것이 보안과 AI 연구 생산성을 함께 지키는 방법입니다.