김정은이 군인과 함께 컴퓨터를 살펴보는 장면 — 김수키 AI 딸깍 칼럼 썸네일

2026년 9월, 북한 해킹 조직 김수키(Kimsuky)가 오픈소스 AI 코딩 도구 '오픈코드(opencode)'로 미끼 문서를 만들어 실제 공격에 사용한 정황이 공개됐다. 해킹 조직이 AI 코딩 에이전트를 실전 공격 파일 제작에 쓴 것이 확인된 첫 사례다.

그런데 이 사건에서 정작 눈에 띄는 건 공격의 정교함이 아니다. AI가 뽑아준 문서를 아무도 읽지 않았다는 것이다. 국가가 뒤를 봐주는 해킹 부대조차 AI 산출물을 검토하지 않고 그대로 발송했던 것이다. 그 부주의 덕분에 우리는 그들이 무슨 도구와 오픈웨이트 인공지능을 쓰는지 알게 됐다.

문제는 이게 북한만의 실수가 아니라는 점이다. 국내 대형 OTT 티빙에서 3,954만 개 계정이 털린 사고의 원인도, 수많은 스타트업이 매일 반복하는 실수도, 뿌리는 같다.

첫째, AI가 만든 문서를 검수하지 않았다

김수키가 뿌린 미끼 PDF에는 (임시값)이라는 표시가 한 문서에 최대 9번 그대로 남아 있었다.

납부 주기: 매월 납입일(임시값) 연 2.0% 고정금리(임시값)

AI가 문서를 만들면서 "여기 실제 숫자를 채워 넣으세요"라고 붙여 놓은 자리다. 그걸 아무도 채우지 않고 해킹할 표적의 메일함으로 보냈다.

더 황당한 건 재사용 비율이다.

  • 미끼 문서 29건 중 내용이 실제로 다른 건 11종뿐이었다. 나머지 18건은 파일명만 바꾼 것이다.
  • PDF 4개의 생성 시각이 초 단위까지 똑같았다. 한 번에 일괄로 뽑아낸 뒤 개별 손질을 전혀 하지 않았다는 뜻이다.
  • 문서 제목 칸에는 이모지가 남아 있었다. 보험료 납부 안내, 정책자금 지원 안내 같은 금융 문서에서 좀처럼 볼 수 없는 공공 문서 양식이다.
  • 문서 속성(메타데이터)에는 제작 도구 이름 opencode가 그대로 박혀 있었다. 파일 정보 창을 한 번도 열어보지 않았다는 증거이다.

정리하면, 북한 해킹 조직은 AI로 대량 생산에는 성공했지만 품질 관리는 통째로 건너뛰었다. 생산성과 품질, 두 마리 토끼를 다 놓친 것이다.

둘째, 악성코드에 이모티콘을 남겼다

문서만 그런 게 아니었다.

카스퍼스키는 2026년 5월, 김수키가 처음 만든 러스트(Rust) 기반 백도어 'HelloDoor'를 분석하다가 코드 주석 안에서 이모지와 문법 오류, 어색한 문장을 발견했다. 악성코드 개발에 LLM(대규모 언어모델)이 관여했다는 결정적 정황이었다.

여기서 짚어야 할 게 두 가지다.

하나, 이모지 주석은 사람이 쓰지 않는다. 최소한 국가 배후 조직의 백도어 소스코드에는 쓰지 않는다. AI가 기본 스타일로 붙인 주석이다.

둘, 그게 컴파일되어 실전 배포됐다. 누구도 소스코드를 한 번 훑어보지 않았다는 뜻이다. 사람이 리뷰했다면 "왜 백도어에 웃는 얼굴이 있지?"라고 물었을 것이다.

문서에서는 지니언스가, 코드에서는 카스퍼스키가, 서로 다른 산출물에서 같은 종류의 부주의를 발견했다. 이건 우연한 실수가 아니라 일하는 방식 자체의 특징이다.

셋째, GitHub 접속 열쇠까지 노출했다

가장 심각한 건 공격 인프라 쪽이다. 이번 캠페인에서 확인된 김수키의 보안 실패 목록은 이렇다.

실수 유형 노출된 정보
테스트 IP 잔존 링크로컬 주소 169.254.33.137이 악성코드 안에 남음
한국 소재 C2 사용 112.216.9.171
PAT 하드코딩 GitHub 액세스 토큰 노출 (현재는 폐기됨)
C2 서버 로그 노출 개발·테스트·AI 연구 환경 전체가 관측됨
테스트 데이터 잔존 내부 IP 172.16.11.141이 포함된 감염정보 파일 업로드 기록
계정 정보 노출 저장소 소유자명, 커밋 작성자 이메일
AI 산출물 미검토 opencode 메타데이터, (임시값) 잔존

용어를 조금 풀어보자.

  • C2(명령제어 서버): 해커가 감염된 PC에 명령을 내리고 훔친 자료를 받는 본부다. 김수키는 이 본부 중 하나를 한국 안에 두었다. 추적을 피하려던 선택이 오히려 꼬리를 밟히는 빌미가 됐다.

  • PAT(개인 액세스 토큰): GitHub 계정에 프로그램이 대신 로그인할 때 쓰는 열쇠다. 이걸 코드 안에 그대로 적어놓는 걸 '하드코딩'이라고 한다. 집 열쇠를 대문에 테이프로 붙여놓는 것과 같다. 토큰이 폐기되기 전까지는 누구든 김수키의 저장소에 접근할 수 있었다는 뜻이기도 하다. 티빙도 실수한 것을 북한 해커들도 한 것이다.

  • 링크로컬 주소(169.254.x.x): 개발자가 자기 노트북에서 시험할 때 쓰이는 주소다. 실제 공격에는 아무 쓸모가 없다. 테스트 코드를 지우지 않고 그대로 배포했다는 흔적이다.

세 줄로 요약하면 이렇다. 개발용 찌꺼기를 지우지 않았고, 열쇠를 코드에 박아뒀고, 자기 로그를 남의 눈앞에 열어뒀다.

이건 북한 해커만의 문제가 아니다

'바이브 코딩(Vibe Coding)' — AI에게 코드를 맡기고 결과물은 대충 훑고 넘어가는 개발 방식이 빠르게 퍼지고 있다. 그리고 같은 유형의 사고가 전 세계에서 반복되고 있다.

미국 조지아공대 보안 연구팀은 공개된 보안 권고문 4만 3,000건 이상을 훑어, AI 코딩 도구가 직접 밀어 넣은 취약점 74건을 확인했다. 이 중 14건이 '치명적(critical)', 25건이 '높음(high)'등급이었다. 명령어 주입, 인증 우회, 서버 측 요청 위조 같은 교과서적인 취약점이 그대로 들어 있었다. 2026년 1월 6건, 2월 15건, 3월 35건으로증가 속도도 가파르다.

연구팀이 던진 경고가 특히 무섭다. AI 모델은 같은 실수를 반복하는 경향이 있어서, 공격자는 버그를 한 번만 찾으면 된다는 것이다. 수백만 명이 같은 모델을 쓰면 같은 버그가 수천 개 저장소에 복사된다. 하나의 패턴을 찾아내면 그걸로 전 세계 저장소를 훑을 수 있다.

국내에서도 위험 신호는 뚜렷하다.

  • AI는 학습 시점 기준으로 코드를 추천한다. 그래서 구버전 라이브러리가 프로젝트에 그대로 남기 쉽고, 이미 패치가 나온 취약점을 노리는 '원데이(1-day)' 공격의 먹잇감이 된다.
  • 테스트용 DB 접속 정보나 고정 API 키가 AI 생성 과정에 슬며시 섞여 들어가는 경우도 잦다.
  • '슬롭스쿼팅(slopsquatting)'이라는 신종 수법도 있다. AI가 존재하지 않는 라이브러리 이름을 지어내면, 공격자가 그 이름을 먼저 등록해 악성 패키지를 심어두는 것이다. 개발자는 AI가 시킨 대로 설치할 뿐이다.

티빙 개발자도 저지른 실수

2026년 5월 발생하고 9월 3일 조사 결과가 발표된 티빙 침해사고는, 이 이야기의 국내판이다.

민관합동조사단에 따르면 유출된 계정은 3,954만 개. 활성 계정뿐 아니라 휴면·탈퇴 계정, 심지어 테스트 계정까지 포함됐다. 콘텐츠 추천 알고리즘 등 개발 프로젝트 361건도 함께 빠져나갔다.

핵심 원인으로 지목된 건 딱 하나다. 개발자 접속키 관리 부실.

공격자는 티빙 개발자의 개발환경 접속키를 훔쳐 내부에 들어온 뒤, 운영환경과 데이터베이스 접속 정보를 손에 넣고 이용자 정보와 소스코드를 꺼내 갔다. 접속키는 암호화조차 되어 있지 않았다.

가장 아픈 대목은 따로 있다. 티빙은 2024년 모의해킹에서 "접속키를 소스코드에 그대로 저장하고 있다"는 취약점을 이미 지적받고도 고치지 않았다. 2년 전에 발견된 구멍을 그대로 두고 있었던 것이다. 여기에 로그 보관 기간 부족, 비정상 행위 모니터링 부재, 정보보호 전담인력 부족이 겹쳤다. 신고도 법정 기한(24시간)을 넘겨 29시간 만에 이뤄졌다.

티빙 사고 자체는 바이브 코딩과 직접 관련이 없다. 하지만 관리 실패의 문법은 똑같다.

김수키가 한 일 티빙에서 벌어진 일
GitHub 토큰을 코드에 하드코딩 개발자 접속키를 소스코드에 평문 저장
AI 산출물을 아무도 읽지 않음 2024년 모의해킹 지적 사항을 아무도 처리하지 않음
테스트 IP·데이터 방치 테스트 계정 11만 개까지 함께 유출
자기 C2 로그가 노출된 줄 모름 비정상 행위 모니터링 부재

편의를 위해 열쇠를 코드에 박아두고, 검증 절차를 건너뛰고, 감시를 소홀히 한다. 국가 해킹 부대나 대형 OTT나, 3인 스타트업이나 다르지 않다.

그래서 무엇을 해야 하나? — 세 겹의 안전장치

1. 커밋 전에 열쇠를 걸러낸다 (프리커밋 검증)

가장 싸고 가장 효과가 큰 방어다. Git에는 코드를 저장소에 올리기 직전에 자동으로 실행되는 pre-commit(프리커밋) 훅이라는 장치가 있다. 여기에 검사 도구를 물려두면 API 키, 토큰, 개인키, DB 접속 정보가 섞여 있을 때 커밋 자체를 막아준다.

대표적인 오픈소스 도구는 세 가지다.

도구 특징
gitleaks 설정이 간단하고 CI에도 붙이기 쉽다. 입문용으로 무난
truffleHog 발견한 키가 실제로 살아 있는지까지 검증해준다
git-secrets AWS 자격증명 탐지에 특화. 가볍다

김수키가 GitHub 토큰을 코드에 박아둔 것도, 티빙 개발자가 접속키를 소스에 남긴 것도, 이 한 겹만 있었으면 상당 부분 막혔을 가능성이 높다. 도입 비용은 불과 몇 시간 정도이다.

여기에 하나 더. 이미 커밋된 과거 이력도 한 번 훑어야 한다. 커밋에서 지웠어도 Git 히스토리에는 남아 있고, 노출된 키는 지우는 게 아니라 폐기하고 새로 발급해야 한다.

2. AI 코드를 검증하는 별도의 눈을 둔다 (로컬 LLM 보안 검사)

AI가 만든 코드를 같은 AI에게 "이거 괜찮아?"라고 묻는 건 위험하다. 같은 편향을 가진 모델은 자기가 만든 실수를 잘 보지 못한다. 영국 국가사이버보안센터(NCSC)도 AI가 AI를 검사하게 두지 말고, 기계적으로 판정되는 보안 통제를 따로 세우라는 취지의 권고를 내놓은 바 있다.

현실적인 답은 두 가지 조합이다.

  • 정적 분석 도구(Semgrep, CodeQL 등) — AI가 아니라 규칙으로 판정한다. 결과가 일관적이다.
  • 로컬에서 돌리는 LLM 보안 검사 — 소스코드를 외부 서비스에 올리지 않고 사내에서만 점검한다. 클라우드 AI에 코드를 업로드하는 행위 자체가 유출 경로가 될 수 있기 때문이다.

김수키가 로컬 LLM(Ollama, GPT4All 등)을 깔아 쓴 이유도 바로 이것이었다. 외부에 프롬프트를 남기지 않기 위해서다. 공격자가 자기 보안을 위해 쓰는 방법이라면, 방어자에게도 유효하다.

3. 사람이 마지막에 한 번 더 읽는다

조지아공대 연구팀의 조언은 명확하다. 바이브 코딩의 본질은 "나중에 코드를 읽지 않는 것"이지만, 그 결과물을 실제 서비스에 올릴 거라면 신입 개발자의 풀 리퀘스트를 보듯 검토해야 한다는 것이다. 특히 입력값 처리와 인증 부분은 반드시.

배포 전에 물어야 할 질문은 길지 않다.

  • 테스트용 IP나 임시 주소가 남아 있지 않은가?
  • API 키·토큰·비밀번호가 코드 안에 박혀 있지 않은가?
  • TODO, TBD, (임시값), [회사명] 같은 자리표시자가 남아 있지 않은가?
  • 문서 속성에 도구 이름이나 이전 담당자 이름이 남아 있지 않은가?
  • 쓰지도 않는 주석과 이모지가 붙어 있지 않은가?

그리고 조직 차원에서는 딱 한 가지를 정해야 한다. AI 산출물을 검토할 책임자가 누구인가? '누군가 보겠지'는 아무도 보지 않는다는 뜻이다. 김수키의 미끼 문서에 (임시값)이 아홉 번 남은 것도, HelloDoor에 이모지 주석이 컴파일된 것도, 티빙이 2년 전 지적을 방치한 것도, 전부 그 자리가 비어 있었기 때문이다.

AI는 도구다. 책임은 사람에게 있다

왜 다들 같은 실수를 할까. 이유는 단순하다.

AI는 만드는 비용을 0으로 만들었지만, 읽고 검토하는 비용은 전혀 줄이지 못했다.

문서 10건을 만드는 데 30초, 읽고 검토하는 데 40분이라면, 조직의 어느 지점에서든 검토는 반드시 생략된다. 김수키가 29건 중 18건을 파일명만 바꿔 재사용한 건 게으름이 아니라 이 불균형의 필연적 결과다. 우리 회사에서 AI 초안이 그대로 결재 라인을 타고 올라가는 것도 원인이 같다.

여기에 하나 더 겹친다. LLM이 만든 결과물은 틀렸을 때조차 잘 쓰여 있다. 사람은 문장이 매끄러우면 내용도 맞다고 착각하도록 훈련돼 있다. 매끄러운 문장은 이미 검토가 끝난 문장처럼 보인다. 그래서 (임시값)이 아홉 번 남아 있어도 읽는 사람이 없다. 잘 구조화된 러스트 코드도 마찬가지다. 리뷰가 끝난 코드처럼 보인다.

LLM은 엑셀이지 오라클이 아니다. 엑셀은 계산을 대신해줄 뿐, 그 숫자가 맞는지는 보증하지 않는다. 아무도 엑셀 수식 결과를 검산 없이 이사회에 올리지 않는다. 그런데 유독 LLM 결과물에 대해서만 그 검산 단계를 통째로 생략한다.

마지막으로 한 가지 덧붙이면, 지금 우리가 김수키를 잡아낼 수 있는 단서에는 유통기한이 있다. 플레이스홀더 잔존, 메타데이터 지문, 이모지 주석은 지금은 강력한 탐지 신호다. 하지만 공격자가 파이프라인 끝에 검수 단계 하나 — 혹은 그 검수를 대신할 AI 에이전트 하나 — 만 붙이면 전부 사라진다. 메타데이터 제거는 명령어 한 줄, 플레이스홀더 검사는 정규식 한 줄이다.

동시에 반대 방향으로도 무너지고 있다. "어색한 한국어면 의심하라"는 20년 된 피싱 예방 교육은 이미 유통기한을 지났다. 이제는 완성도가 높을수록 출처를 확인해야 한다.

AI 딸깍은 편리하다. 하지만 그 편리함 뒤에는 반드시 사람의 검증이라는 안전장치가 있어야 한다.

김수키가 우리에게 알려준 건 AI가 얼마나 무서운 무기인가가 아니다. AI를 검토 없이 쓰는 조직이 얼마나 많은 흔적을 남기는가다. 지금은 그 흔적이 그들의 것이지만, 검토를 생략하는 습관이 우리에게 남아 있는 한, 다음 흔적은 우리 것이 된다.

AI를 가장 잘 쓰는 방법은, AI를 가장 의심하는 것이다.

원문 상세 분석: 북한 해킹 팀 김수키(Kimsuky)도 AI 딸깍 — AI 무기화 종합 분석

Dennis Kim (김호광) · [email protected]