내 개발 도구 두 곳에 구멍이 생겼다

요즘 AI 코딩 에이전트 없이 작업하는 날이 거의 없다. 터미널에 프롬프트 하나 던지고 "이 디렉터리 파악해서 리팩터링 후보 찾아줘" 같은 식으로 쓴다. 그게 습관이 됐다. 지난 주말에 BleepingComputer에서 읽은 내용이 그 습관을 다시 생각하게 만들었다.

다운로드 폴더 속 파일 하나로

보안 연구자들이 고객사 환경을 분석하다 다운로드 폴더 안에서 이상한 마크다운 파일을 발견했다. AI 코딩 에이전트가 실행할 지시를 담은 형태였고, 에이전트는 그 파일을 신뢰 있는 설정으로 읽어 결국 악성 npm 패키지를 설치했다. 파일 이름은 AGENTS.md.

이게 왜 무서운가 하면, 벡터가 너무 평범하기 때문이다. 다운로드 폴더. 피싱 첨부파일을 의심스럽게 열지 않아도, 저장소를 클론하지 않아도, 그냥 어디선가 파일 하나를 받아 거기 놔두면 된다. 그리고 AI 에이전트가 작업 컨텍스트를 수집하면서 그 파일을 읽는다.

AI 코딩 도구 상당수가 프로젝트 루트나 특정 이름의 파일에서 컨텍스트를 자동으로 읽는 구조다. 반복 지시를 매번 프롬프트에 넣지 않아도 되는 편의 기능이다. 문제는 에이전트가 그 파일의 출처를 검증하지 않는다는 것. 내가 직접 만든 파일이든 다운로드 폴더에서 흘러들어온 파일이든 같은 무게로 읽는다.

npm 패키지 설치가 이번 사례였지만, 에이전트가 파일 시스템에 쓰고 셸 명령을 실행할 수 있는 권한을 갖고 있다면 거기서 할 수 있는 일의 범위는 훨씬 넓다. 설정 파일을 덮어쓰거나, 환경 변수를 읽어 외부로 보내거나. 어디까지 되는지는 직접 실험해봐야 아는데, 이론적 지면은 꽤 넓다.

Tailscale에서도 비슷한 구조

같은 주에 Tailscale SSH 관련 보안 보도가 나왔다. The Hacker News에 따르면, Tailscale 네트워크 내 기기 하나가 이미 침해된 상태에서 포트 포워딩을 허용하는 SSH 설정이 있으면, 그 기기를 발판 삼아 ACL상 접근 가능한 다른 서버에 루트 권한으로 올라갈 수 있다는 내용이다.

이 패턴을 "신뢰 전이"라고 부를 수 있을 것 같다. Tailscale을 쓰는 이유 자체가 "같은 메시 안이면 믿어도 된다"는 전제인데, 메시 내부 기기 하나가 뚫리면 그 신뢰가 수평으로 번진다. 제로 트러스트라는 말을 달고 있으면서도 내부 신뢰 범위가 생각보다 넓게 펼쳐져 있는 셈이다.

내가 Tailscale을 쓰는 방식은 개발 서버 접근 용도다. 로컬 맥에서 원격 서버로 SSH 터널을 뚫거나, 서버 사이 내부 통신을 할 때. Tailscale SSH까지 쓰진 않고 기본 openssh 위에 Tailscale을 네트워크 레이어로만 얹어 쓰는데, 그나마 그게 이번 취약점 직접 영향에서 비껴가는 것 같다. 하지만 "포트 포워딩 열려 있는 기기가 메시 안에 하나라도 있으면"이라는 조건이 걸리면 얘기가 달라진다. 개발 환경에는 온갖 도구가 돌아가고, 그중 어떤 게 어떤 포트를 어떤 방식으로 여는지 전부 파악하고 있지 못할 때가 있다.

패치가 언제 나오는지, 어떤 버전이 영향을 받는지는 직접 Tailscale 릴리스 노트를 확인해야 한다. 보도 시점에서 미패치 상태였다는 것 외에 구체적인 버전 범위는 아직 내 쪽에서 확인이 끝나지 않았다.

내가 바꾸고 있는 것들

AGENTS.md 사례를 보고 나서 먼저 한 것은 AI 에이전트가 어떤 디렉터리 범위를 컨텍스트로 삼는지 다시 읽어본 것이다. 프로젝트 루트로 명시적으로 제한하는 설정이 있는지, 혹은 상위 디렉터리나 홈 디렉터리까지 훑는지. 에이전트마다 동작이 다르기 때문에 "설정이 어딘가 있겠지" 하고 넘어가면 안 된다.

다운로드 폴더에 파일을 오래 쌓아두는 습관도 문제다. 한 번 받고 방치한 파일들이 꽤 있고, 출처가 흐릿한 것도 섞여 있다. 이제 다운로드 폴더를 AI 에이전트 작업 경로와 교차시키지 않겠다는 게 가장 단순한 조치다. 별도 샌드박스 디렉터리를 두고 외부에서 받은 파일을 거기서만 열거나, 에이전트 호출 전에 작업 루트를 명시적으로 지정하는 방식.

Tailscale 쪽은 SSH 레이어를 Tailscale SSH로 전환하지 않기로 일단 유지한다. 네이티브 openssh에 Tailscale은 네트워크 레이어만. ACL은 "같은 메시 안이면 다 통한다"를 기본값으로 두지 않는 방향으로 서비스별 허용 목록을 다시 정리하고 있다. 귀찮은 작업이긴 한데 이번 계기로 미뤄둔 것을 처리하는 셈이다.

두 이슈가 닮은 구석이 있다. 편리함을 위해 열어둔 신뢰 범위가 예상보다 넓었다는 것. AI 에이전트는 "읽을 수 있는 곳이면 다 컨텍스트"라는 전제로 동작하고, Tailscale은 "메시 안이면 같은 편"이라는 전제로 라우팅한다. 두 전제 모두 틀린 건 아닌데, 그 경계가 어디까지인지 도구 쓰는 사람이 직접 파악하고 있어야 한다는 게 결론이다.

도구가 알아서 지켜주지 않는다.

참고한 글

• AI coding agents hijacked using AGENTS.md file in Downloads folder - https://www.bleepingcomputer.com/news/security/ai-coding-agents-hijacked-using-agentsmd-file-in-downloads-folder/
• Unpatched Tailscale SSH Flaws Could Let a Hacked Device Reach Root on Other Servers - https://thehackernews.com/2026/10/unpatched-tailscale-ssh-flaws-could-let.html

야망에 관한 짧은 메모

같은 날 Dan Luu의 글이 HN 상위에 올라왔다. "우리가 만드는 소프트웨어에 더 야망을 가져야 한다"는 주장이다. 기술적 제약이 아니라 상상력의 타협점에서 먼저 멈춘다는 비판.

동의하는 부분이 있다. 많은 내부 도구나 사이드 프로젝트가 "이 정도면 됐지"에서 끊긴다. 그 선이 기술 한계가 아니라 익숙한 해결 공간의 가장자리인 경우가 많다. 불편한 부분도 있다. 야망의 크기와 실제로 완성되는 확률 사이에 음의 상관관계가 있다는 것도 사실이기 때문이다. 내 로컬에 야망 있게 시작해서 중단된 프로젝트가 몇 개인지 생각하면.

글의 핵심은 "크게 생각하라"보다 "무엇이 가능한지의 범위를 더 넓게 봐라"에 가깝다. 익숙한 좁은 해결 공간에 갇히지 말라는 것. 그 프레이밍이면 동의한다.

AI 수익, 테크 밖에서는 아직

Apollo 분석: AI 투자 대비 테크 섹터 외부에서는 생산성 향상이나 이익 개선 신호가 약하다. 제목이 직접적이다. "No signs of AI payoff outside the tech sector."

내가 AI 도구를 쓰는 패턴을 돌아보면 납득된다. 반복적인 코드 생성, 문서 요약, 빠른 구문 탐색에서는 체감이 있다. 그 외의 영역은 "맡기면 되겠지"로 시작해서 결국 직접 하는 경우가 꽤 있다. 테크 워커의 특정 작업에서의 효과가 다른 산업으로 번지려면 워크플로우 통합 문제가 먼저 해결돼야 하는데, 그게 생각보다 느리게 가고 있다는 게 데이터의 메시지인 것 같다.

크리에이티브 직군 20만 명 감소 분석도 같은 날 나왔다. Apricitas가 미디어·영화·예술 분야 고용 감소를 다뤘는데, AI를 유일한 원인으로 보지 않으면서도 구조적 요인의 하나로 짚는다. 상관관계로 인과를 증명하기 어렵다는 방법론적 한계가 늘 붙지만, "증명 안 됐으니 무관하다"도 아니라는 게 균형 잡힌 읽기일 것 같다. AI 이미지·영상 도구가 실제로 쓰이기 시작한 시점과 곡선이 어느 정도 겹치는지가 핵심 논거인데, 그 부분은 원문을 직접 읽어야 한다.

10년 된 CNN이 최신 LLM보다 낫다

피부암 진단 비교 실험에서 2014년 구조의 CNN이 최신 프론티어 LLM보다 나은 결과를 냈다는 연구다. Lynch Lab에서 나왔다.

"LLM이 별로다"는 이야기가 아니다. 도메인 특화 좁은 모델이 범용 모델보다 특정 작업에서 여전히 우세할 수 있다는 이야기다. 당연해 보이는데 실제로 테스트해보는 경우가 드물어졌다. 최근 흐름이 "일단 가장 큰 범용 모델에 물어봐라"로 쏠렸기 때문이다. 진단처럼 틀리면 비용이 큰 작업에서는 범용 모델 기본 신뢰가 특히 위험하다. 이 결과를 보고 내가 AI 에이전트를 사용하는 방식에서도 비슷한 패턴이 있나 돌아봤다. 범용 모델 하나에 모든 걸 던지는 게 편하긴 한데, 특정 작업에서는 좁고 빠른 도구가 더 정확한 경우가 있다.

Google의 에이전트 인프라

Google 쪽에서 에이전트 관련 글이 두 편 나왔다. 하나는 Gemini Enterprise Agent Platform 기반으로 프로덕션 장애를 1.8초 안에 처리하는 자율 에이전트(Project Chrysalis), 다른 하나는 ADK 없이 LangChain 등 외부 프레임워크로도 배포·평가 워크플로우를 공유하는 CLI 확장 시스템.

LangChain 템플릿이 ADK 없이 동작한다는 부분이 실용적으로 관심이 갔다. 특정 플랫폼 SDK에 묶이지 않고 배포 레이어만 공유하는 방향이면 기존 스택에 붙이기가 훨씬 쉬워진다. 다만 "framework-agnostic"이 실제로 얼마나 깔끔하게 되는지는 직접 써봐야 안다. 이런 종류의 글은 아키텍처 다이어그램이 실제 코드보다 항상 단순하게 보이기 때문이다.

Project Chrysalis의 1.8초 수치는 마케팅 프레이밍인지 실측인지 판단 보류. 어떤 종류의 장애인지, 실패 시 어떻게 처리하는지가 중요한데 블로그 글에서 그 부분이 충분히 나오지 않는다. 에이전트가 틀렸을 때의 폭발 반경이 좁고 리커버리가 가능한 작업에서만 쓸 수 있다는 게 여전히 에이전트 자율화의 핵심 제약이다.

이번 주를 정리하면: 보안 두 건, AI 실효성 논쟁, 에이전트 인프라 방향, 그리고 범용 대 특화의 오래된 질문이 겹쳤다. 직접 손댈 것은 Tailscale ACL 정리와 에이전트 작업 경로 명시적 제한이다.

다음 주 체크: Tailscale 패치 릴리스 여부, AGENTS.md 관련 주요 에이전트 프레임워크 대응 현황.

• Dan Luu, We should be more ambitious with the software we build, https://danluu.com/ambitious/
• Apollo, No signs of AI payoff outside the tech sector, https://www.apollo.com/wealth/insights-news/insights/daily-spark/no-signs-of-ai-payoff-outside-the-tech-sector
• Apricitas, America has lost 200k of jobs in media, film and the arts, https://www.apricitas.io/p/ai-and-the-fall-of-the-creative-class
• Lynch Lab, A 10-year-old CNN outperforms frontier LLMs for skin cancer diagnosis, https://lynchlab.net/llm-skin-cancer
• Google Developers, Architecting Governed, Self-Evolving AI Agents on Google Cloud, https://developers.googleblog.com/architecting-governed-self-evolving-ai-agents-on-gemini-agent-platform/
• Google Developers, Powering the Agent Development Lifecycle with any framework, https://developers.googleblog.com/powering-the-agent-development-lifecycle-with-any-framework-from-adk-to-langchain-and-beyond/
• The Hacker News, Unpatched Tailscale SSH Flaws Could Let a Hacked Device Reach Root on Other Servers, https://thehackernews.com/2026/10/unpatched-tailscale-ssh-flaws-could-let.