편집이 곧 실행인 파일

파일 수정을 일일이 승인하기 번거로워 자동으로 넘기는 모드를 켜두신 분들 계실 겁니다. 편해지는 대신 무엇이 고쳐지는지 안 보게 되죠. 공식 변경점을 보니 그 모드에서도 멈춰 서는 파일 목록이 생겼습니다. 기준이 흥미로웠는데, 중요한 파일이라서가 아니라 "고치면 다음에 실행되는 파일"이라서였습니다.

📌 30초 요약

① 편집을 자동 승인해두는 모드에서도 일부 파일은 물어봅니다.

② 기준은 "코드를 실행할 수 있는 파일이냐"입니다.

③ 터미널 시작 파일, 버전 관리 설정, 빌드 도구 설정 세 갈래가 대상입니다.

④ 전부 건너뛰는 모드 하나를 빼면 어떤 모드에서도 자동 승인되지 않습니다.

⑤ 같은 주에 연결 설정을 볼 때 비밀값이 안 찍히게 바뀌었습니다.

⑥ 자동완성에서 명령을 눌러도 바로 실행되지 않습니다. 입력창에 채워집니다.

고치는 순간이 아니라 다음 순간이 문제

보통 파일을 고치면 그 파일 내용이 바뀌는 것으로 끝입니다. 잘못됐으면 되돌리면 되죠. 그런데 어떤 파일은 다릅니다. 터미널을 열 때마다, 명령을 돌릴 때마다 그 안에 적힌 것이 자동으로 실행됩니다.

그러니까 이런 파일에 대한 편집은 내용 수정이 아니라 실행 예약에 가깝습니다. 고치는 순간에는 아무 일도 안 일어나고, 다음에 무언가를 시작할 때 그 결과가 나타납니다. 자동 승인 모드에서 조용히 지나가면 내가 승인했다는 사실조차 모른 채 그 예약이 걸립니다.

💡 왜 이 기준이 잘 잡혔나

"중요한 파일을 보호한다"고 하면 무엇이 중요한지 사람마다 다릅니다. 그런데 "고치면 나중에 실행되는가"는 파일의 성질로 판정할 수 있습니다. 주관이 안 들어가고, 실제 위험의 성격과도 맞습니다 — 조용히 심어두고 나중에 터지는 게 가장 알아채기 어려우니까요.

보호되는 세 갈래

갈래	언제 실행되나
터미널 시작 파일	창을 열 때마다
버전 관리 설정	관련 명령을 쓸 때
빌드·설치 도구 설정	설치하거나 빌드할 때

세 갈래 모두 내가 직접 부르지 않아도 도는 자리입니다. 터미널을 열기만 해도, 프로젝트를 설치하기만 해도 읽히는 파일들이죠. 그래서 한 번 심어두면 계속 반복됩니다. 여기에 패키지를 받아오는 경로를 적는 설정도 포함돼 있는데, 그건 어디서 코드를 내려받을지를 바꾸는 것이라 성격이 같습니다.

어떤 모드에서도 예외 없이

문서가 못 박아둔 문장이 하나 있습니다. 이 파일들에 대한 쓰기는 어떤 모드에서도 자동 승인되지 않는다는 것입니다. 딱 하나 예외가 모든 확인을 건너뛰는 모드인데, 그건 애초에 "다 알아서 하라"고 켜는 것이니 별개입니다.

# 모드별 동작

일반 편집 승인 모드      물어봄
편집 자동 승인 모드      물어봄   ← 이번에 바뀐 지점
자동 모드                물어봄
모든 확인 건너뛰기       안 물어봄  ← 유일한 예외

# 뒤집어 읽으면
편의를 위해 켜둔 자동 승인이
이 자리에서는 무효가 됩니다

편의 설정보다 위쪽에 놓았다는 게 이 변경의 성격입니다. 내가 "편집은 알아서 해"라고 켜뒀어도 이 자리에서는 그 설정이 무시됩니다. 목표만 주고 자리를 비우는 끝까지 맡기는 방식을 쓰신다면, 돌아왔을 때 여기서 멈춰 기다리고 있을 수 있다는 것도 알아두시면 좋습니다.

비밀값을 화면에 안 찍습니다

같은 주 부록에 결이 같은 변화가 있었습니다. 연결 설정을 목록으로 보거나 확인할 때 예전에는 인증 정보가 그대로 화면에 나왔습니다. 이제는 환경 변수 참조를 풀지 않고, 자격 증명이 담긴 항목과 주소 안의 비밀값을 가립니다.

사소해 보이지만 화면을 캡처해 공유하거나 기록을 남길 때 차이가 큽니다. 설정을 확인하려고 목록을 띄운 것뿐인데 인증 정보까지 같이 찍히는 일이 흔했거든요. 외부 서비스를 연결해 배포하는 방식을 쓰신다면 특히 해당됩니다.

자잘하지만 반가운 것도 있습니다. 자동완성 목록에서 명령을 눌렀을 때 바로 실행되던 게 이제 입력창에 채워지기만 합니다. 실행하려면 한 번 더 눌러야 하죠. 그리고 여러 명령을 한꺼번에 돌릴 때 하나가 실패해도 나머지가 취소되지 않습니다.

🔁 셸로 봤다고 잠금이 풀리는 건 아닙니다

보호해 둔 경로를 다룰 때 헷갈리기 쉬운 지점이 하나 있습니다. 파일을 읽는 규칙을 보면 셸로 파일을 훑어본 것도 「읽었다」로 쳐줍니다 — 단 파일 하나를 대상으로, 파이프나 방향 전환 없이 쓴 경우만요. 그런데 이건 편집 자격에만 해당하고 권한 규칙과는 완전히 별개입니다. 셸로 봤으니 잠금이 느슨해진 게 아니라, 읽기·편집 거부 규칙은 그대로 살아 있습니다. 「봤으니 고칠 수 있다」와 「고쳐도 된다」를 갈라서 보셔야 합니다.

자주 묻는 질문

Q. 자동 승인 모드를 쓰면 안 되는 건가요?

그런 뜻은 아닙니다. 오히려 위험한 자리만 골라 막아뒀으니 나머지는 마음 편히 쓰라는 쪽에 가깝습니다. 편집을 하나하나 승인하는 건 번거롭고, 대부분의 편집은 되돌리면 그만이니까요. 되돌려도 안 되는 자리에만 확인을 남긴 구조로 보시면 됩니다.

Q. 목록에 없는 위험한 파일은요?

문서가 든 것은 예시이고 전부라고 적혀 있지 않습니다. 제 컴퓨터에만 있는 자동 실행 설정이 있다면 그건 별도로 막아두셔야 합니다. 권한 설정에서 경로를 지정해 막는 방법이 있으니, 자동 승인을 자주 쓰신다면 내 환경에서 "열기만 해도 도는 파일"이 뭔지 한 번 떠올려보시는 게 좋습니다.

Q. 자리를 비운 사이 멈춰 있으면 손해 아닌가요?

기다리게 되는 건 맞습니다. 다만 여기서 멈춘다는 건 그만큼 확인이 필요한 편집이라는 뜻입니다. 자리를 오래 비우실 거라면 맡기기 전에 이런 파일을 건드릴 일이 있는 작업인지 한 번 보시는 편이 낫습니다. 대체로는 없습니다 — 평범한 코드 작업이라면 마주칠 일이 드뭅니다.

🧾 솔직하게 밝혀둘 것

① 공식 변경점을 읽고 정리한 것이고 직접 시험해보지 않았습니다.

② 보호 대상은 문서가 든 예시이고 전체 목록인지는 확인하지 못했습니다. 본문에서 갈래로 묶어 적었으니 정확한 파일명은 원문을 보세요.

③ "기준이 잘 잡혔다"는 제 평가입니다. 문서는 대상만 나열하고 이유를 설명하지 않습니다.

④ 실제 악용 사례를 확인한 것은 아닙니다. 이런 파일의 성격을 설명한 것이지 사고가 있었다는 뜻이 아닙니다.

⑤ 한 주치(6월 1~5일) 변경점이고 버전 조건이 붙습니다. 이후 대상이 늘거나 줄었을 수 있습니다.

✨ 정리하면

자동 승인이 편한 건 대부분의 편집이 되돌릴 수 있기 때문입니다. 그런데 고치는 순간이 아니라 다음에 실행되는 순간이 문제인 파일은 성격이 다릅니다. 이번 변경은 그 차이를 기준으로 삼아 편의 설정보다 위에 확인을 놓았습니다. 같은 주에 비밀값을 화면에 안 찍게 한 것도, 명령을 눌러도 바로 안 돌게 한 것도 "모르는 사이에 벌어지는 일"을 줄이는 쪽이라 결이 같습니다.

맡겨두고 자리를 비우는 방식은 목표만 주는 명령 정리, 외부 서비스를 연결해 배포하는 쪽은 CLI 배포 가이드에 있고, 최근 주간 변경점은 대신 갈 모델 세 개에 이어집니다. AI에 쓰는 돈 전체는 AI 지출 허브에서 순서대로 보실 수 있습니다.

※ 출처: 제조사 공식 문서의 주간 변경점 페이지(2026년 6월 1~5일 구간) 원문. 2026년 8월 25일 확인 기준이며, 보호 대상과 모드별 동작은 이후 버전에서 바뀔 수 있습니다.