회사나 서비스의 ‘사용 설명서’를 인터넷에서 찾아보신 적 있으시죠? “이 앱은 이렇게 설치하세요”, “이 기능은 이렇게 쓰세요” 같은 안내 페이지 말이에요. 개발자와 스타트업, 특히 코인(가상자산) 프로젝트들이 이런 설명서를 만들고 올릴 때 많이 쓰는 서비스가 깃북(GitBook)입니다.
그 깃북이 한국시간 11월 3일 새벽 3시쯤 공격을 받았어요. 깃북은 공지에서 이번 일을 “AI 에이전트를 사용한 정교하고 매우 표적화된 공격”이라고 불렀습니다. 공격자는 깃북 내부 시스템의 ‘열쇠’ 일부를 손에 넣었고, 깃북은 서비스를 한동안 내린 뒤 모든 고객의 API 토큰을 한꺼번에 무효로 만들었어요. 한국시간 11월 4일 0시 21분 공지에서 앱·API·공개 문서가 다시 열렸다고 밝혔지만, 고객들에게는 “연결해 둔 열쇠를 전부 새로 바꾸라”는 숙제가 남았습니다.
오늘은 “깃북이 뭔지”, “무엇이 새어 나갔을 수 있는지”, “‘AI 에이전트 공격’이 정확히 무슨 뜻인지(그리고 아직 모르는 건 뭔지)”, “내가 깃북을 쓰거나, 깃북으로 만든 문서를 읽는 사람이라면 오늘 무엇을 하면 되는지”를 초보 눈높이로 하나씩 풀어 볼게요.
한눈에 보는 핵심 정리
| 항목 | 내용 |
|---|---|
| 어디가? | 깃북(GitBook) — 온라인 문서·설명서 제작/게시 플랫폼 |
| 언제? | 공격자 무단 접근: 11월 2일 19:00(중앙유럽시간) = 한국시간 11월 3일 03:00 |
| 무엇이 뚫렸나? | 깃북 인프라의 ‘자격 증명(로그인 열쇠)’ 일부 |
| 깃북 표현 | “AI 에이전트를 사용한 정교하고 매우 표적화된 공격” |
| 접근됐을 수 있는 것 | 연동(Integration) 토큰, Git Sync 비밀값, API 토큰, 문서 방문자가 깃북 어시스턴트(AI 비서)에 남긴 질문 |
| 문서 내용 변조? | “현 단계에서 콘텐츠가 수정된 증거는 찾지 못했다” |
| 깃북의 조치 | 공격자 차단·취약점 폐쇄, 인프라 비밀값 전부 교체, 고객 API 토큰 전면 무효화, 확인 후 서비스 재개 |
| 복구 | 한국시간 11월 4일 00:21 공지 기준 앱·API·공개 문서 다시 이용 가능(일부 기능은 성능 회복 중) |
| 고객 숙제 | API 토큰 새로 발급, 깃북에 연결한 외부 서비스 키 교체, 공개 통합의 비밀값 교체, 깃북 MCP 서버 재인증 |
| 아직 모르는 것 | 어떻게 들어왔는지, 어떤 AI가 쓰였는지, 피해 고객 수 — 깃북은 “상세 사후 보고서를 곧 공개”한다고 밝힘 |
먼저, 깃북이 뭐예요?
깃북은 쉽게 말해 ‘온라인 설명서 공장’이에요. 워드 문서처럼 글을 쓰면 그게 예쁜 웹사이트(문서 사이트)로 바로 올라가요. 개발자들은 여기에 프로그램 사용법, API 안내서, 회사 내부 위키 등을 올리죠. 코인 프로젝트들은 “지갑 연결은 이렇게”, “토큰 구조는 이렇게” 같은 공식 안내를 깃북으로 많이 만들어 왔어요.
문서 자체는 누구나 읽는 공개 글인 경우가 많아요. 그런데 문서를 만들고 관리하는 뒤편은 사정이 달라요. 깃허브 코드 저장소와 자동으로 맞추는 기능, 다른 서비스와 이어 붙이는 기능, AI 비서 기능이 있고, 이 연결들은 모두 비밀 열쇠(토큰)로 움직입니다. 이번에 문제가 된 것이 바로 이 ‘뒤편 열쇠’들이에요.
| 깃북 기능 | 쉬운 비유 | 이번 사고와의 관계 |
|---|---|---|
| 문서 편집기·공개 문서 사이트 | 설명서를 쓰는 책상 + 서점 진열대 | 공격 직후 편집기와 로그인 필요한 문서는 내려감, 공개 문서는 저장본(캐시)으로 최대한 유지 |
| Git Sync(깃 동기화) | 설명서와 코드 창고(깃허브 등)를 잇는 자동 배달 통로 | 이 통로용 비밀값이 접근됐을 수 있음 |
| Integrations(연동) | 다른 앱과 연결하는 플러그 | 연동 토큰이 접근됐을 수 있음 |
| GitBook API | 프로그램이 깃북에 자동으로 일을 시키는 창구 | 개인 API 토큰 전부 무효화됨 |
| GitBook Assistant | 문서 사이트에 붙은 AI 안내원 | 방문자가 물어본 질문이 접근됐을 수 있음 |
| MCP 서버 | AI 도우미(클로드 등)가 깃북 문서를 읽고 쓰게 해 주는 연결 단자 | 다시 로그인(재인증) 필요 |
한국시간으로 다시 보는 사고 흐름
해외 공지는 중앙유럽시간(CET) 기준이라 헷갈리기 쉬워요. 11월은 서머타임이 끝난 시기라 CET에 8시간을 더하면 한국시간이 됩니다.
| 한국시간(KST) | 현지 공지 시각 | 무슨 일이? |
|---|---|---|
| 11월 3일(화) 03:00 | 11월 2일 19:00 CET | 공격자가 깃북 인프라 자격 증명 일부에 무단 접근. 깃북은 “즉시 탐지하고 빠르게 차단했다”고 설명 |
| 11월 3일 새벽~오전 | 11월 2일 밤~3일 오전 | 깃북 앱과 로그인 필요한 문서 사이트를 내림. 공개 문서는 캐시로 최대한 유지했지만 상태 페이지에 문서·편집기 장애 표시 |
| 11월 3일 21:15 | 11월 3일 13:15 CET | “플랫폼 전체 문제로 여러 고객이 영향받고 있다”는 고객 공지. 이때는 “지금은 고객이 할 일 없음” |
| 11월 4일(수) 00:21 | 11월 3일 16:21 CET | 앱·API·공개 문서 복구 발표. 접근됐을 수 있는 4가지 항목과 고객이 할 일 4가지 공개 |
| 그 뒤 | — | 코인 탈중앙거래소 팬케이크스왑(PancakeSwap)은 예방 차원에서 문서를 내렸다가 자체 관리 인프라로 옮겨 재개 |
무엇이 새어 나갔을 수 있나요? 4가지 항목
깃북은 조사 결과 공격자가 아래 4가지에 접근했을 수 있다고 밝혔어요. “확실히 다 가져갔다”가 아니라 “손이 닿았을 수 있다”는 뜻이지만, 보안에서는 이런 경우 이미 샜다고 보고 바꾸는 것이 기본이에요.
| 항목 | 쉬운 비유 | 나쁜 사람 손에 들어가면? |
|---|---|---|
| 연동(Integrations) 토큰 | 깃북과 다른 앱을 잇는 ‘출입 카드’ | 연결된 앱에 깃북인 척 접근을 시도할 수 있음 |
| Git Sync 비밀값 | 설명서 ↔ 코드 창고 배달 통로의 ‘열쇠’ | 연결된 저장소 쪽을 엿보거나 건드리려 시도할 수 있음(권한 범위에 따라 다름) |
| API 토큰 | 프로그램용 ‘깃북 계정 비밀번호’ | 그 토큰을 만든 사용자와 같은 권한으로 문서를 읽고 바꿀 수 있음(깃북 개발 문서 설명) |
| 깃북 어시스턴트 질문 | 방문자가 AI 안내원에게 건넨 메모 | 누군가 질문 칸에 계정 정보·내부 사정을 적었다면 그 내용도 노출 가능 |
잠깐, ‘토큰’과 ‘API 키’는 비밀번호와 뭐가 달라요?
사람은 아이디와 비밀번호로 로그인하죠. 그런데 프로그램끼리 대화할 때는 매번 비밀번호를 칠 수가 없어요. 그래서 미리 발급받은 긴 문자열, 즉 토큰(token)이나 API 키를 들고 다녀요. 깃북 개발 문서에도 “토큰은 그것을 만든 사용자 계정과 똑같은 접근 권한을 가진다”고 적혀 있어요. 그러니까 토큰 하나가 새면 사실상 그 사람 계정의 복제 열쇠가 돌아다니는 셈이에요.
| 구분 | 누가 쓰나 | 특징 | 샜을 때 해결 |
|---|---|---|---|
| 비밀번호 | 사람 | 로그인 화면에서 직접 입력, 2단계 인증과 함께 쓰는 경우가 많음 | 비밀번호 변경 + 같은 비번 쓴 다른 사이트도 변경 |
| API 토큰(개인 액세스 토큰) | 프로그램·자동화 스크립트 | 2단계 인증 없이 바로 통하는 경우가 많아 더 위험 | 옛 토큰 삭제 + 새 토큰 발급 + 쓰던 곳에 교체 |
| 연동 토큰·비밀값(시크릿) | 서비스 ↔ 서비스 | 한 번 설정하면 잊고 지내기 쉬움 | 양쪽 서비스에서 새로 발급해 다시 연결 |
| OAuth 로그인(재인증) | 앱이 “이 계정으로 로그인 허용”을 받는 방식 | 허용 버튼 한 번으로 연결 | 연결 해제 후 다시 로그인 |
확인된 것 vs 아직 모르는 것
사고 초기에는 소문과 추측이 섞이기 쉬워요. 깃북이 직접 밝힌 것과, 아직 밝히지 않은 것을 나눠 볼게요.
| 확인된 것(깃북 공지) | 아직 모르는 것 |
|---|---|
| 공격 시각: 한국시간 11월 3일 03:00 | 공격자가 처음 어떤 구멍으로 들어왔는지 |
| 인프라 자격 증명 일부에 무단 접근 | 어떤 AI 모델·도구가 쓰였는지 |
| 접근 가능성이 있는 4가지 항목 | 실제로 몇 명의 고객 정보가 빠져나갔는지 |
| 문서 내용이 수정된 증거는 현재 없음 | 공격자가 누구인지(국가·조직) |
| 고객 개인 API 토큰 전부 무효화 | 훔친 토큰이 이미 다른 곳에서 쓰였는지 |
| 상세 사후 보고서(post mortem) 곧 공개 예정 | 깃북 자체 AI 기능이 공격 경로였는지 — 공지는 그렇게 말하지 않음 |
특히 마지막 줄이 중요해요. 제목만 보면 “깃북의 AI가 해킹당했다”처럼 읽힐 수 있지만, 깃북이 말한 건 공격하는 쪽이 AI 에이전트를 썼다는 것이에요. 깃북의 AI 비서가 뚫렸다는 뜻은 아닙니다.
‘AI 에이전트 공격’은 무슨 뜻일까요?
챗GPT 같은 챗봇은 질문하면 답을 해 주죠. AI 에이전트는 한 걸음 더 나가서, 목표를 주면 스스로 계획을 세우고 프로그램을 실행하고 결과를 보고 다음 행동을 정해요. 좋은 쪽으로 쓰면 “버그 찾아서 고쳐 줘”가 되지만, 나쁜 쪽으로 쓰면 “이 회사 서버를 뒤져서 열쇠를 찾아 줘”가 될 수 있어요.
| 비교 | 사람이 손으로 하는 공격 | AI 에이전트를 붙인 공격 |
|---|---|---|
| 정찰(약점 찾기) | 사람이 하나씩 주소·화면을 확인 | 여러 에이전트가 동시에 쉬지 않고 훑음 |
| 속도 | 며칠~몇 주 | 훨씬 빨라질 수 있음(보안 업계 보고에서 수 시간 사례도 언급) |
| 규모 | 한 번에 몇 곳 | 수십~수백 곳을 나란히 시도 가능 |
| 사람의 역할 | 모든 단계를 직접 | 목표를 정하고 중요한 순간에 지시·승인 |
| 방어 쪽 의미 | “설마 여기까지 오겠어?”가 통하기도 | 작은 노출(키·설정)도 금방 발견된다고 가정해야 함 |
다시 말하지만, 깃북은 이번 공격에서 AI가 구체적으로 무엇을 했는지는 아직 설명하지 않았어요. 위 표는 ‘AI 에이전트 공격’이라는 말이 일반적으로 어떤 모습을 뜻하는지 이해를 돕기 위한 비교예요.
같은 시기 비슷한 사고들, 한 줄로 이어 보기
이번 주 IT 업계에서는 “AI 에이전트로 자동화한 침입”을 언급한 공개가 연달아 나왔어요. 다만 깃북 사건이 이들과 같은 공격자·같은 도구인지는 확인되지 않았다는 점을 꼭 기억해 주세요.
| 회사 | 무슨 회사? | 공개된 내용 | AI 관련 언급 |
|---|---|---|---|
| 깃북(GitBook) | 문서 플랫폼 | 11/3 03:00 KST 인프라 자격 증명 무단 접근, 고객 API 토큰 전면 무효화 | “AI 에이전트를 사용한 공격”(도구 이름 미공개) |
| 워크OS(WorkOS) | 기업용 로그인·인증 개발 플랫폼 | 10/30 발견, 내부 영업·고객관리 시스템의 연락처·상담 요약 등 접근. 제품 데이터·운영 서비스는 영향 없음이라고 발표 | 창업자가 AI 자동 침투 도구 ‘ARTEX’를 지목 |
| 체인스택(Chainstack) | 블록체인 인프라 업체 | 10/26 개발 환경 침입 → 운영 환경 일부로 확대, 10/31 탐지·차단. 고객 이름·이메일·비밀번호 해시 등 접근 | 더해커뉴스는 지난주 드러난 대규모 AI 기반 공격 캠페인의 일부로 평가 |
| 체이널리시스(Chainalysis) | 블록체인 분석 업체 | 11/2 기준 일부 제품을 예방 차원에서 오프라인 | “공격형 에이전트 기법을 쓰는 외부 행위자”를 탐지했다고 밝힘 |
공통점은 세 가지예요. ① 개발자·IT 기업이 표적, ② 노린 것이 ‘데이터’보다 먼저 열쇠(자격 증명·토큰), ③ 피해 회사들이 고객에게 “키를 바꾸라”고 요청했다는 점이에요.
나는 해당될까? 유형별로 보기
| 나는… | 영향 | 오늘 할 일 |
|---|---|---|
| 깃북으로 회사·프로젝트 문서를 운영하는 관리자 | 높음 | 아래 5단계 체크리스트 전부 |
| 깃북 API로 자동화(CI, 동기화 스크립트, 문서 봇)를 돌리는 개발자 | 높음 | 토큰이 이미 무효라 자동화가 멈췄을 가능성 → 새 토큰 발급·교체 |
| 클로드 코드 등 AI 도우미에 깃북 MCP를 연결해 둔 사람 | 중간 | MCP 연결 다시 로그인(재인증) |
| 깃북 계정은 있지만 글만 쓰는 팀원 | 낮음~중간 | 관리자 안내 따르기, 같은 비밀번호를 다른 곳에 쓰고 있다면 바꿔 두기(습관 점검) |
| 깃북으로 만든 문서를 읽기만 하는 방문자 | 낮음 | 문서 AI 비서에 개인정보를 적은 적 있는지 떠올려 보기, 가짜 공지·피싱 주의 |
| 깃북을 전혀 쓰지 않는 일반 이용자 | 해당 없음 | 다만 ‘연결해 둔 앱 정리’ 습관은 누구에게나 도움 |
깃북 관리자·개발자를 위한 5단계 체크리스트
깃북이 안내한 4가지 할 일에, 실무에서 흔히 놓치는 ‘사용 흔적 확인’을 하나 더 붙였어요. 순서대로 따라 하시면 됩니다.
| 단계 | 무엇을 | 어디서·어떻게 |
|---|---|---|
| 1. 목록 만들기 | 깃북 토큰을 쓰는 곳 전부 적기 | CI 설정, 배포 스크립트, 문서 봇, 슬랙 연동 등. “어디에 붙여 놨더라?”를 먼저 정리 |
| 2. API 토큰 새로 발급 | 개인 액세스 토큰 교체 | 깃북 계정의 Developer settings에서 새 토큰 생성 → 쓰던 곳에 넣기 → 남은 옛 토큰은 옆의 “X”로 삭제 |
| 3. 외부 서비스 키 교체 | 깃북에 넘겨준 다른 서비스의 토큰·비밀값 | 깃허브 등 연결 대상 서비스에서 새 키 발급 → 깃북 연동에 다시 연결. Git Sync 연결도 이 범주로 보고 점검 |
| 4. 공개 통합·MCP 정리 | 직접 만든 통합의 비밀값, MCP 연결 | 통합 비밀값 교체, MCP는 다시 로그인. 로그인이 꼬이면 서버를 지웠다가 다시 추가 |
| 5. 흔적 확인 | 옛 키가 낯선 곳에서 쓰였는지 | 연결 서비스(깃허브 등)의 보안 로그·키 ‘마지막 사용 시각’을 보고, 11월 3일 전후 이상한 접근이 있었는지 확인 |
잘 모르겠다면 혼자 고민하지 말고 깃북 조직 관리자에게 먼저 물어보세요. 깃북도 공지에서 “조직 관리자에게 도움을 요청하라”고 안내했어요.
키 바꿀 때 흔히 하는 실수
| 실수 | 왜 문제? | 이렇게 하세요 |
|---|---|---|
| 깃북 토큰만 바꾸고 끝 | 깃북에 넘겨준 다른 서비스의 키가 그대로 살아 있음 | 연결 대상 쪽에서도 새로 발급 |
| 옛 키를 먼저 지우고 새 키는 나중에 | 그 사이 자동화가 줄줄이 멈춤 | 새 키 만들기 → 교체 → 동작 확인 → 옛 키 삭제 순서 |
| 새 토큰을 채팅·메일로 공유 | 또 다른 유출 통로가 됨 | 비밀값 저장소(시크릿 매니저)나 CI 비밀 설정에 직접 입력 |
| 권한 넓은 관리자 계정으로 토큰 발급 | 토큰은 만든 사람과 같은 권한을 가짐 | 필요한 만큼 권한 가진 계정으로 발급 |
| “문서 내용 안 바뀌었대” 하고 안심 | 내용 변조가 없어도 열쇠는 샜을 수 있음 | 내용 확인과 키 교체는 별개로 처리 |
문서를 읽는 사람이라면: ‘가짜 공지’ 조심
보안 사고 직후에는 그 틈을 노린 피싱이 따라오기 쉬워요. 특히 코인 프로젝트 문서는 “지갑 연결”이 걸린 곳이라 더 조심해야 해요. 팬케이크스왑은 이번 일로 문서를 잠시 내리면서 “문서는 절대 지갑 연결이나 토큰 승인을 요구하지 않는다”고 이용자들에게 다시 알렸어요. 이 말이 곧 구별법이에요.
| 이런 건 의심 | 이렇게 확인 |
|---|---|
| 설명서 페이지가 “지갑을 연결하세요”, “토큰을 승인하세요”라고 요구 | 설명서는 읽는 곳이지 서명하는 곳이 아님. 바로 창 닫기 |
| “보안 사고로 계정 재인증이 필요합니다” 메일 속 링크 | 메일 링크 대신 즐겨찾기·직접 입력한 공식 주소로 접속 |
| 평소와 다른 주소(철자 한 글자 다른 도메인)의 문서 사이트 | 프로젝트 공식 SNS·홈페이지에 적힌 문서 주소와 비교 |
| 문서 AI 비서가 비밀번호·인증번호를 물어봄 | 정상적인 안내 AI는 그런 걸 묻지 않음. 절대 입력 금지 |
그리고 하나 더. 문서 사이트의 AI 비서 질문 칸에는 계정 정보나 개인적인 내용을 적지 않는 습관을 들이세요. 이번처럼 그 질문 기록까지 ‘접근됐을 수 있는 정보’ 목록에 오를 수 있거든요.
자주 묻는 질문
| 질문 | 답 |
|---|---|
| 깃북에서 본 설명서 내용, 믿어도 되나요? | 깃북은 현재까지 콘텐츠가 수정된 증거는 없다고 밝혔어요. 다만 돈·지갑이 걸린 안내라면 공식 채널 공지와 한 번 더 대조해 보세요. |
| 제 깃북 비밀번호도 바꿔야 하나요? | 깃북이 공개한 접근 목록에 ‘사용자 비밀번호’는 없어요. 다만 같은 비밀번호를 여러 곳에 쓰고 있다면 이번 기회에 따로따로 바꾸는 게 좋아요. |
| CI가 갑자기 깃북 쪽에서 실패해요. | 개인 API 토큰이 전부 무효화됐기 때문일 가능성이 커요. 새 토큰을 발급해 비밀 설정에 넣으면 대부분 해결돼요. |
| AI가 혼자 해킹한 건가요? | 깃북은 “AI 에이전트를 사용한 공격”이라고만 했어요. 사람이 개입했는지, AI가 어떤 단계를 맡았는지는 사후 보고서를 기다려야 해요. |
| 한국 서비스도 영향이 있나요? | 깃북으로 문서를 운영하는 한국 회사·프로젝트라면 똑같이 키 교체 대상이에요. 깃북을 안 쓰면 직접 영향은 없어요. |
마무리: 이번 일에서 챙길 한 가지 습관
이번 사고의 핵심은 “문서가 털렸다”가 아니라 “문서 뒤에 꽂아 둔 열쇠들이 위험해졌다”는 데 있어요. 그리고 공격하는 쪽이 AI 에이전트로 더 빠르고 넓게 훑는 시대라면, 한 번 꽂아 두고 잊은 열쇠일수록 먼저 발견된다고 생각하는 게 안전해요.
그래서 오늘 챙길 습관은 단순해요. 내가 연결해 둔 토큰과 앱 목록을 한 번 적어 보고, 안 쓰는 건 지우고, 쓰는 건 주기적으로 새로 바꾸기. 깃북 관리자라면 오늘 체크리스트를, 문서 독자라면 “설명서는 지갑을 요구하지 않는다”는 한 줄을 기억해 두세요. 깃북이 사후 보고서를 내면 공격 경로가 더 분명해질 테니, 그때 우리 서비스에도 같은 틈이 없는지 다시 점검해 보면 좋겠습니다.