링크드인에서 온 꿈의 채용 제안, 그런데 첨부파일이 백도어였다

링크드인 메시지함에 솔깃한 제안이 하나 도착합니다. “당신의 프로필을 봤습니다. 우리 회사 시니어 자리에 딱 맞아요.” 연봉도 좋고, 회사도 그럴듯합니다. 그런데 면접 과정에서 건네받은 “코딩 과제"를 로컬에서 실행하는 순간, 당신의 노트북은 이미 공격자의 손에 넘어갑니다. 요즘 개발자를 노리는 공격 중 가장 교묘한 방식입니다.

오늘은 이 “가짜 면접” 사회공학 공격이 어떻게 작동하는지 뜯어보겠습니다. 솔직히 말씀드리면 최근 30일치 커뮤니티 토론 데이터는 많지 않았습니다. 그래서 이 글은 그동안 보안 업계에 누적된 사례와 패턴을 중심으로 정리했다는 점을 먼저 밝혀둡니다.

왜 하필 개발자를 노릴까요

보이스피싱이 노년층을 노리듯, 이 공격은 명확히 개발자를 겨냥합니다. 이유가 꽤 합리적입니다.

첫째, 개발자는 코드를 실행하는 게 일상입니다. 낯선 깃허브 저장소를 클론하고, npm install을 돌리고, 남이 준 프로젝트를 빌드하는 행위에 거부감이 없습니다. 일반 사용자라면 “실행 파일을 받으세요"라는 말에 경계하지만, 개발자에게 “이 레포 클론해서 면접 과제 풀어보세요"는 너무나 자연스러운 요청입니다.

둘째, 개발자의 노트북은 보물창고입니다. 사내 시스템 접근 키, 클라우드 자격증명, 암호화폐 지갑, 소스코드 저장소 권한이 한자리에 모여 있습니다. 한 명만 뚫으면 회사 전체로 번질 수 있는 교두보가 됩니다.

셋째, 이직을 고민하는 개발자는 심리적으로 무방비 상태입니다. 좋은 제안 앞에서는 누구나 판단력이 흐려지기 마련이니까요.

공격은 이렇게 굴러갑니다

전형적인 시나리오를 단계별로 풀어보겠습니다.

먼저 그럴듯한 헤드헌터 계정이 접근합니다. 실제 회사 로고, 진짜 같은 경력, 적당히 채워진 인맥. 링크드인에서 이 정도 위장은 어렵지 않습니다.

다음으로 면접이 진행됩니다. 몇 차례 화상 대화를 나누며 신뢰를 쌓습니다. 사람을 한 번이라도 “만나고” 나면 경계심이 확 줄어듭니다.

그리고 핵심 단계, 코딩 과제가 등장합니다. “우리 실무 환경과 비슷한 프로젝트예요. 이 깃허브 레포 클론해서 버그를 고쳐주세요.” 또는 “이 npm 패키지를 설치하고 데모를 실행해보세요.” 이 순간이 함정입니다.

악성코드는 프로젝트 깊숙이 숨어 있습니다. 화려한 메인 코드가 아니라, 빌드 스크립트나 의존성 패키지 한 줄에 난독화된 채 박혀 있습니다. npm install 한 번이면 설치 과정에서 자동 실행되는 경우도 많습니다. 피해자는 자기가 뭘 실행했는지조차 모릅니다.

npm 생태계가 주요 무대가 된 이유

이 공격이 특히 자바스크립트 진영에서 활발한 데 이유가 있습니다. 한 보안 분석에 따르면 북한 연계로 추정되는 공격 그룹이 악성 npm 패키지를 무려 197개나 뿌렸고, 누적 다운로드가 3만 1천 건을 넘겼다는 보고가 있었습니다.

npm은 패키지 설치 시 postinstall 같은 자동 실행 스크립트를 허용합니다. 원래는 편의 기능이지만, 공격자에게는 완벽한 실행 트리거입니다. 의존성 트리는 또 얼마나 깊은가요. 내가 설치한 패키지가 끌고 오는 수십, 수백 개의 하위 의존성을 사람이 일일이 검수하기란 불가능에 가깝습니다.

여기에 ‘OtterCookie’ 같은 정보 탈취형 악성코드가 결합합니다. 브라우저에 저장된 비밀번호, 암호화폐 지갑 정보, 시스템 자격증명을 긁어모아 외부로 빼돌리는 식입니다. “면접 과제"라는 명분으로 이 모든 게 한 번에 진행됩니다.

그래서 어떻게 막을까요

거창한 보안 솔루션이 필요한 게 아닙니다. 습관 몇 가지면 대부분 막을 수 있습니다.

가장 확실한 방법은 격리된 환경에서 실행하는 것입니다. 출처가 100% 확실하지 않은 면접 과제는 절대 메인 작업 노트북에서 돌리지 마세요. 일회용 가상머신이나 컨테이너, 또는 별도 클라우드 인스턴스에서 실행하는 게 기본입니다.

npm install 시에는 --ignore-scripts 옵션으로 자동 실행 스크립트를 막을 수 있습니다. 의심스러운 프로젝트라면 빌드 전에 package.json의 스크립트 항목부터 눈으로 확인하세요.

채용 담당자의 신원도 검증하세요. 회사 공식 채용 페이지에 그 자리가 실제로 열려 있는지, 헤드헌터의 이메일 도메인이 진짜 회사 도메인인지 확인하는 데는 5분이면 충분합니다. 정상적인 채용 절차라면 “지금 당장 이 코드를 로컬에서 실행하라"고 재촉하지 않습니다.

마지막으로 의심하세요. 면접 과제가 유난히 “특정 프로젝트를 그대로 실행"하라고 요구한다면, 그것 자체가 신호입니다. 진짜 면접 과제는 보통 백지에서 직접 작성하게 하지, 남의 코드를 통째로 돌려보라고 하지 않습니다.

마무리

이 공격이 무서운 건 기술적으로 정교해서가 아닙니다. 개발자의 가장 자연스러운 행동, 즉 “남이 준 코드를 실행하는 일"을 무기로 삼기 때문입니다. 좋은 채용 제안일수록 잠시 멈춰 서서 출처를 따져보는 습관, 그게 가장 강력한 방어선입니다.

여러분은 면접 과제를 받으면 어디서 실행하시나요. 혹시 지금도 메인 노트북에서 낯선 레포를 아무렇지 않게 클론하고 계신 건 아닌지, 한 번쯤 돌아볼 때입니다.