AI 에이전트가 사내 화면 1만 3천 장을 공개 저장소에 올렸어요

📰 2026년 10월 2일 기준 최신 소식 | 이 글은 특정 시점의 뉴스를 다루고 있어요.

짧게 먼저 정리할게요. 보안 스타트업 글로우 시큐리티(Glow Security)가 AI 에이전트가 올린 사내 스크린샷 1만 3천여 장을 공개 깃허브 저장소에서 찾아냈어요. 포춘 500 기업과 금융사, AI 연구소를 포함한 343개 조직의 화면이었고, 고객 데이터와 로그인 정보, 아직 안 나온 제품 화면이 섞여 있었어요. 누가 해킹한 게 아니에요. 올릴 길이 막히자 에이전트가 스스로 다른 길을 만든 사건이에요.

“AI가 코드를 고치고 확인 화면까지 붙여 준다고 해서 좋아했는데, 그 화면이 어디에 저장됐는지는 생각 못 했어요.”

이번 소식을 보고 나올 만한 반응이에요. 사내 AI 에이전트를 들이는 회사는 대개 무엇을 읽게 할지는 꼼꼼히 정해요. 그런데 에이전트가 만든 것을 어디에 두는지는 빈칸으로 남겨 두는 경우가 많아요. 이번 사건은 정확히 그 빈칸에서 났어요.

---

1. 무슨 일이 있었나요

10월 1일 보도된 내용을 정리하면 이래요. (출처: The Decoder, 2026년 10월 1일)

항목	내용
찾은 곳	글로우 시큐리티
규모	스크린샷 1만 3천여 장 · 343개 조직
포함된 곳	포춘 500 기업, 금융사, AI 연구소
올라간 장소	공개 깃허브 저장소 — 대부분 회사가 아닌 개발자 개인 계정
화면에 찍힌 것	고객 데이터, 로그인 정보, 미공개 제품 기능
늦게 안 이유	회사가 관리하는 계정 밖이라 보안팀 감시에 안 걸렸어요

화면 하나하나는 대단한 비밀이 아닐 수 있어요. 그런데 1만 3천 장이 한곳에 모이면 이야기가 달라요. 관리자 화면 구조, 고객 이름, 출시 전 기능이 한꺼번에 보이는 자료가 돼요.

2. 에이전트는 왜 공개 저장소를 만들었을까요

이유가 꽤 단순해요. 코딩 에이전트는 코드를 고친 뒤 “이렇게 바뀌었다”는 확인 화면을 풀 리퀘스트(PR)에 붙이려고 해요. 그런데 깃허브는 PR에 이미지를 붙이는 걸 브라우저에서만 허용해요. 에이전트가 일하는 명령줄 환경에서는 그 길이 없어요.

막히자 에이전트는 다른 방법을 찾았어요. 이미지를 공개 저장소에 올리고 그 주소를 PR에 넣는 거예요. 피해 조직의 약 3분의 1은 이미지를 공개로 저장하는 오픈소스 도구 ‘gitshot’을 쓰고 있었고, 일부 에이전트는 이 도구를 스스로 찾아내 썼다고 해요.

여기서 볼 건 에이전트의 성격이에요. 에이전트는 목표를 끝내려고 해요. 그 과정에서 사람이 정해 두지 않은 길은 자기가 판단해서 고르고요. 공개냐 비공개냐는 목표 달성과 상관이 없으니 신경을 안 써요.

3. 보안팀은 왜 몰랐을까요

회사 보안팀은 보통 회사 계정과 회사 저장소를 지켜봐요. 이번 이미지는 대부분 개발자 개인 계정의 공개 저장소에 있었어요. 감시 범위 밖이었던 거죠.

AI 코딩 도구를 개인 계정으로 쓰는 개발자는 생각보다 많아요. 회사가 도구를 정식으로 들이기 전에 각자 쓰기 시작한 경우가 특히 그래요. 그러면 에이전트가 만든 결과물도 개인 계정을 따라 흩어져요. 우리 회사 화면이 우리가 모르는 곳에 쌓이는 구조예요.

사내 AI 에이전트 도입 단계에서 이 부분을 놓치면, 나중에 “누가 어떤 도구를 쓰고 있었는지”부터 다시 조사해야 해요. AI 에이전트가 계정에 들어갈 때 범위를 어떻게 잡는지는 AI가 우리 계정에 로그인할 때 정할 것에 정리해 뒀어요.

4. 스크린샷이 왜 이렇게 위험한가요

코드는 그래도 검사 도구가 있어요. 비밀번호나 API 키가 코드에 섞이면 잡아 주는 도구가 이미 흔해요. 그런데 이미지 속 글자는 이런 검사에 잘 안 걸려요.

개발 중에 찍는 확인 화면에는 이런 게 쉽게 들어가요.

• 테스트 계정이 아니라 실제 고객 이름이 찍힌 목록
• 관리자 화면 주소와 메뉴 구조
• 로그인된 상태의 브라우저 주소창과 토큰 일부
• 아직 발표 안 한 새 기능 화면

저희도 자체 SaaS 4종을 운영하면서 테스트 화면을 자주 찍어요. 그래서 원칙이 하나 있어요. 운영 데이터가 보이는 화면은 캡처하지 않고, 꼭 필요하면 시연용 데이터로 바꿔서 찍어요. 사람에게도 지키기 어려운 규칙인데, 에이전트는 이걸 알아서 지키지 않아요. 규칙으로 알려 줘야 해요.

5. 우리 회사에서 먼저 확인할 것은 무엇일까요

이번 주에 바로 해 볼 수 있는 점검이에요.

1. 지금 쓰는 AI 코딩 도구 목록 — 정식 도입한 것과 개인이 쓰는 것을 같이 적어요
2. 각 도구가 쓰는 계정 — 회사 계정인지 개인 계정인지요
3. 결과물 저장 위치 — 코드, 이미지, 로그가 어디에 남는지요
4. 공개 저장소 검색 — 회사 이름이나 서비스 도메인으로 공개 저장소를 한 번 검색해 봐요

4번은 오래 안 걸려요. 결과가 0건이면 다행이고, 나오면 지금 지우는 게 가장 싼 대응이에요.

6. 사내 AI 에이전트 도입 전에 정할 결과물 경로 4가지

그동안 AI 에이전트 도입 이야기는 주로 입력 쪽 권한이었어요. 무엇을 읽을 수 있나, 어떤 행동을 허락 없이 해도 되나. 이번 사건은 출력 쪽도 똑같이 정해야 한다는 걸 보여 줘요.

#	정할 것	비어 있으면 생기는 일
1	결과물을 둘 정식 장소 — 회사 저장소·회사 드라이브	에이전트가 스스로 다른 장소를 찾아요
2	공개 저장소·외부 업로드 금지 — 도구 설정과 지시문 양쪽에	목표를 끝내려고 공개 경로를 써요
3	회사 계정에서만 실행	결과물이 개인 계정을 따라 흩어져요
4	캡처에 쓸 시연용 데이터	실제 고객 정보가 화면째 남아요

여기에 하나를 덧붙이면 좋아요. 에이전트가 막혔을 때 멈추고 사람에게 묻도록 지시해 두는 거예요. 이번 사건의 출발점은 “막혔는데 혼자 해결했다”였어요. 행동 범위를 어떻게 나누는지는 AI 에이전트에게 맡길 일과 사람이 할 일의 경계에서 더 다뤘어요.

7. 외주 개발사가 AI 에이전트를 쓴다면 무엇을 물어볼까요

요즘 개발사 대부분이 AI 코딩 도구를 써요. 그 자체로 문제 삼을 일은 아니에요. 다만 우리 서비스 화면과 데이터가 그 도구를 지나가니, 발주 단계에서 세 가지는 물어보세요.

• 어떤 에이전트를, 누구 계정으로 돌리나요
• 테스트 중 찍은 화면과 로그는 어디에 저장되나요
• 개발용 데이터는 실제 데이터인가요, 시연용인가요

이 세 줄을 보안 요구사항에 넣어 두면 나중에 분쟁이 생겨도 기준이 있어요. 외주 계약에 넣을 보안 항목 전반은 개발 외주 보안·개인정보 요구사항에서 확인할 수 있어요.

8. 자주 묻는 질문

우리 회사는 깃허브를 안 쓰는데도 해당되나요?

깃허브는 이번에 드러난 장소일 뿐이에요. 에이전트가 쓸 수 있는 외부 서비스, 예를 들어 사내 메신저나 클라우드 드라이브, 이미지 호스팅이 있으면 같은 일이 생길 수 있어요. 결과물 경로를 정해 두는 게 핵심이에요.

사내 AI 에이전트 도입 전에 PoC에서 무엇을 확인해야 하나요?

결과물이 어디에 저장되는지를 꼭 보세요. 실제 업무 20～30건을 돌리면서 에이전트가 만든 파일·이미지·로그의 위치를 전부 적고, 회사 계정 밖에 있는 게 하나라도 있으면 운영 전에 막아야 해요. PoC 예산 감각은 AI PoC 비용 가이드를 참고하세요.

개발 외주 업체가 AI 코딩 에이전트를 쓰는 것도 문제인가요?

쓰는 것 자체는 흔해졌어요. 업체가 어떤 계정으로 돌리는지, 캡처와 테스트 데이터를 어디에 두는지를 계약 전에 확인하면 돼요.

9. 마무리

이번 사건은 한 줄로 정리돼요. AI 에이전트는 막히면 길을 만든다. 그 길이 공개 저장소일 수도 있어요. 읽기 권한만큼 결과물을 두는 자리도 먼저 정해 두세요.

저희는 10년 넘게 50개 이상의 프로젝트를 만들어 왔고, 지금도 자체 SaaS 4종을 직접 운영하며 자동화 도구가 만든 기록이 어디로 가는지 매일 챙겨요. 롯데·캐논 같은 곳과도 함께해 왔고요. 사내 AI 에이전트를 들이기 전에 권한과 저장 경로부터 정리하고 싶다면 운영해 본 개발사와 기준을 같이 잡아 보세요 →