심링크(symlink)가 뭐야 — 40년 된 유닉스 기능이 왜 지금 AI 코딩 보안 문제가 됐나

낯선 깃허브 저장소를 클론하고 AI 코딩 도구에게 "이거 설정해줘"라고 시켰을 뿐인데, 내 SSH 키에 모르는 사람의 접속 권한이 슬쩍 추가될 수 있습니다.

2026년 7월 기준, 40년 넘은 유닉스 기능인 심링크(symlink)가 AI 코딩 보안의 새 화두로 떠올랐습니다.

이 글에서는 심링크가 정확히 뭔지, 왜 하필 지금 문제가 됐는지, 초보자는 뭘 조심하면 되는지를 하나씩 풀어봅니다.

심링크는 다른 파일을 가리키는 "바로가기"입니다. 심링크 자체는 위험한 기능이 아니라, 신뢰할 수 없는 저장소가 이 바로가기를 몰래 심어놨을 때가 문제입니다.

심링크가 뭐야? 윈도우 바로가기와 거의 같다

심링크는 심볼릭 링크(symbolic link)의 줄임말입니다.

쉽게 말해 다른 파일이나 폴더를 가리키는 특수한 파일입니다.

안에 실제 데이터가 들어 있는 게 아니라, "진짜 파일이 어디 있는지" 경로만 담고 있습니다.

그래서 심링크를 열면 시스템이 알아서 진짜 파일로 넘겨줍니다.

가장 가까운 비유는 윈도우의 "바로가기"입니다.

다만 윈도우 바로가기(.lnk)는 탐색기에서만 작동하는 껍데기에 가깝습니다.

반면 심링크는 운영체제 파일시스템 수준에서 투명하게 동작합니다.

그래서 프로그램은 이걸 "진짜 파일"인 줄 알고 그대로 읽고 씁니다.

이 투명함이 편리함인 동시에, 이번 보안 문제의 핵심이기도 합니다.

만드는 방법도 간단합니다.

반응형

유닉스·맥·리눅스 터미널에서 아래 한 줄이면 됩니다.

ln -s /진짜/파일/경로 /링크이름
# -s 는 symbolic(심볼릭)의 s. 40년 넘은 유닉스 표준 명령입니다.

참고로 심링크와 자주 헷갈리는 개념이 하드링크입니다.

심링크는 "이름(경로)"을 가리키고, 하드링크는 파일 실체 자체를 가리킵니다.

그래서 원본을 지우면 심링크는 깨지지만, 하드링크는 멀쩡합니다.

대신 심링크는 다른 디스크나 폴더도 가리킬 수 있어 훨씬 유연합니다.

그럼 심링크는 나쁜 기능인가?

결론부터 말하면 아닙니다.

심링크는 개발 현장에서 아주 흔하게 쓰이는 정상적이고 유용한 도구입니다.

대표적인 예가 패키지 매니저 pnpm입니다.

pnpm은 라이브러리 폴더(node_modules)를 심링크로 구성해 같은 라이브러리를 여러 프로젝트가 공유하게 합니다.

덕분에 디스크 용량을 아끼고 설치 속도도 빨라집니다.

개발자들이 설정 파일을 관리하는 dotfiles 방식도 심링크에 크게 기댑니다.

공통 설정을 한 곳에 두고 여기저기서 심링크로 연결하거나, current 같은 심링크 하나로 런타임 버전을 갈아끼우는 식입니다.

그러니 심링크를 봤다고 무조건 겁먹을 필요는 없습니다.

문제는 심링크라는 기능이 아니라, 신뢰할 수 없는 저장소가 이걸 몰래 심어두는 상황입니다.

왜 지금 화제인가 — GhostApproval 사례

이 오래된 기능이 다시 주목받은 계기는 보안기업 Wiz가 2026년 7월 8일 공식 블로그에 공개한 "GhostApproval"입니다.

Wiz는 실제로 악용된 사례가 발견된 것은 아니라고 명시했습니다.

즉 실제 피해 보고가 아니라, 여러 AI 코딩 도구에서 공통으로 나타난 구조적 약점에 대한 지적입니다.

메커니즘은 개념만 잡으면 충분합니다.

악성 저장소에 무해해 보이는 설정 파일(예: project_settings.json)이 하나 들어 있다고 해봅시다.

그런데 이 파일이 사실은 심링크라서, 실제로는 홈 폴더의 SSH 인증키 파일(~/.ssh/authorized_keys)을 가리키고 있습니다.

사용자가 AI 에이전트에게 "설정해줘"라고 시키면, 에이전트는 그 링크를 따라가 진짜 인증키 파일에 내용을 씁니다.

여기에 공격자의 SSH 공개키가 들어가면, 비밀번호 없이 원격 접속이 열릴 수 있습니다.

핵심 결함은 승인창과 실제 동작의 불일치입니다.

승인창에는 무해한 파일 이름이 보이는데, 정작 화면 밖 민감한 파일이 수정되는 것입니다.

Wiz는 이를 고지된 동의 우회(informed consent bypass)라고 불렀습니다.

개발자 입장에서는 "자기가 볼 수 없는 편집을 승인"한 셈이 됩니다.

더 까다로운 경우도 있었습니다.

일부 도구는 사용자가 승인 버튼을 누르기 전에 이미 파일이 쓰였습니다.

Wiz의 테스트 버전 기준으로 이 문제의 영향을 받은 도구는 여섯 종이었습니다.

Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity, Windsurf가 여기 포함됩니다.

버그인가 설계인가 — 각사 대응이 갈렸다

흥미로운 지점은 같은 지적을 두고 회사들의 반응이 꽤 달랐다는 것입니다.

일부는 취약점으로 인정하고 수정했고, 일부는 관점 자체가 다르다고 봤습니다.

벤더 (도구)	대응
AWS (Amazon Q)	인정·수정 (CVE-2026-12958)
Cursor	인정·수정 (CVE-2026-50549)
Google (Antigravity)	협조 대응, 수정됨
Augment	인지, 발행 시점 미수정
Windsurf	인지, 발행 시점 미수정
Anthropic (Claude Code)	"취약점 아님" 이견, 다만 심링크 경고는 추가

728x90

여기서 가장 눈에 띈 쪽은 Claude Code를 만드는 Anthropic이었습니다.

Anthropic은 이 사안을 취약점으로 보지 않는다는 취지의 입장을 냈습니다.

악성 심링크가 든 디렉토리에서 사용자가 편집을 명시적으로 승인한 상황은 애초에 위협 모델 밖이라는 논리입니다.

쉽게 말해 "폴더를 믿고 편집을 승인했다면, 그 신뢰 결정은 사용자 책임"이라는 쪽입니다.

다만 Anthropic도 제품에 심링크 경고를 추가하는 보완은 진행했습니다.

이 경고가 언제 추가됐는지는 소스마다 조금씩 달라, 정확한 버전은 발행 전 공식 문서 확인이 필요합니다. 여기서는 2026년 상반기에 추가됐다고만 정리합니다.

반대편에서 Wiz는 이렇게 반문합니다.

승인창이 실제로 수정될 대상 경로를 보여주지 않는데, 그걸 온전한 신뢰 결정이라 부를 수 있느냐는 것입니다.

이 논쟁의 본질은 결국 "AI 에이전트가 화면에 뭘 보여주고, 실제로 뭘 하는가"라는 신뢰 경계(trust boundary)의 문제입니다.

개인적으로는 어느 한쪽이 틀렸다기보다, 승인창이 무엇을 보여줘야 하는가에 대한 기준이 아직 업계에 정착되지 않은 과도기라고 봅니다.

각 도구의 벤더별 상세 대응은 별도 글에서 더 다룰 예정입니다.

초보자는 뭘 조심하면 될까

겁먹기보다 습관 하나만 들이면 대부분 걸러집니다.

낯선 저장소를 클론한 뒤, AI에게 "설정해줘"라고 시키기 전에 심링크가 있는지 먼저 확인하는 것입니다.

터미널에서 프로젝트 폴더에 들어가 아래 명령을 실행하면 됩니다.

find . -type l
# 현재 폴더 아래의 심링크를 전부 찾아 보여줍니다.
# 결과가 '-> /Users/.../.ssh/...' 처럼 프로젝트 밖이나
# 홈 폴더를 가리키면 위험 신호입니다.

프로젝트 안쪽을 가리키는 심링크는 대체로 정상입니다.

하지만 SSH 키, 셸 설정 파일(.zshrc), AI 설정 파일처럼 프로젝트 바깥을 가리키면 한 번 의심해봐야 합니다.

가능하다면 AI 에이전트를 파일 접근이 제한된 샌드박스 환경에서 실행하는 것도 좋습니다.

낯선 저장소를 만진 뒤에는 SSH 키나 셸 시작 파일의 수정 시각을 ls -la로 한 번 확인해두면 안심입니다.

자주 묻는 질문

심링크는 위험한 기능인가요?

아닙니다. 심링크는 pnpm이나 dotfiles처럼 개발에서 흔히 쓰이는 정상 기능입니다.

문제는 기능 자체가 아니라, 신뢰할 수 없는 저장소가 심링크를 몰래 심어 민감한 파일을 가리키게 만든 경우입니다.

Claude Code 같은 AI 도구를 계속 써도 되나요?

신뢰하는 폴더에서 쓰는 한 큰 문제는 없습니다.

다만 낯선 저장소를 클론한 직후 바로 "설정해줘"를 시키기 전에 find . -type l로 심링크를 한 번 점검하는 습관을 권합니다.

혹시 이미 당했는지 어떻게 확인하나요?

홈 폴더의 ~/.ssh/authorized_keys 파일과 셸 시작 파일을 열어 모르는 내용이 추가됐는지 확인하면 됩니다.

파일들의 수정 시각을 ls -la로 보고, 낯선 저장소를 만진 시점과 겹치는지 대조하는 것도 방법입니다.

결론

심링크는 40년 된 유닉스 기능일 뿐, 그 자체로 나쁜 것이 아닙니다.

달라진 것은 이제 사람이 아니라 AI 에이전트가 파일을 읽고 쓰기 시작했다는 점입니다.

에이전트가 "무해한 이름"만 보고 판단할 때, 오래된 바로가기 기능이 새로운 사각지대가 됩니다.

개인적으로는 이번 GhostApproval 논쟁이 특정 도구의 흠집이라기보다, AI 코딩 도구 전반이 "승인창을 어디까지 정직하게 보여줄 것인가"를 다시 설계하는 계기가 될 것이라고 봅니다.

지금 당장은 낯선 저장소에서 find . -type l 한 줄을 습관으로 삼는 것만으로 충분합니다.

 

 

참고한 자료

보안기업 Wiz의 "GhostApproval" 공식 블로그(2026-07-08)와 The Hacker News, SecurityWeek, Infosecurity Magazine의 보도, 심링크와 하드링크 차이는 How-To Geek, 심링크의 정상 쓸모는 pnpm 공식 문서를 참고했습니다. CVE 번호와 벤더별 수정 버전, Claude Code 심링크 경고 추가 시점은 발행 전 공식 문서 재확인이 필요합니다.