홍드로이드의 야매코딩

안 쓰는데 값은 나가는 것들 본문

AI & Vibe Coding

안 쓰는데 값은 나가는 것들

홍드로이드 2026. 8. 25. 14:29
반응형

쓰다 보면 이것저것 붙이게 됩니다. 편해 보여서 설치한 확장, 한 번 써보고 만 연결, 처음에 길게 써둔 설명서. 그런데 이것들은 안 쓰는 동안에도 매번 값을 치릅니다. 대화를 시작할 때마다 목록이 실리니까요. 설정을 점검하는 명령이 이번에 그 낭비를 찾아서 정리까지 해주는 쪽으로 바뀌었습니다.

📌 30초 요약

보고서만 뽑던 명령이 고치는 것까지 하게 됐습니다.

안 쓰는 확장·연결·기능을 매번 드는 비용과 대조해 알려줍니다.

설명서 파일이 겹쳐 있으면 중복을 걷어냅니다. 개인용과 공유용이 따로 있을 때요.

코드를 보면 알 수 있는 내용은 빼자고 제안합니다. 이게 제일 흥미로웠습니다.

느리게 도는 자동 실행 항목도 짚어줍니다.

먼저 찾은 것을 보여주고 바꾸기 전에 물어봅니다. 알아서 지우지 않습니다.

안 쓰는 것에도 값이 붙습니다

확장이나 연결을 하나 붙이면 그게 무엇이고 무엇을 할 수 있는지가 대화 시작 시점에 함께 실립니다. 실제로 부르지 않아도요. 하나둘일 때는 티가 안 나는데, 쓰지도 않는 것들이 쌓이면 매 대화마다 그만큼을 먼저 채우고 시작하게 됩니다.

이번 변경의 핵심이 여기입니다. 점검 명령이 설치된 것들을 훑으면서 "실제로 쓰였는지"와 "매번 얼마를 차지하는지"를 나란히 놓고 비교합니다. 안 쓰는데 자리는 크게 차지하는 것부터 눈에 띄게 되는 구조입니다.

점검하는 것 무엇을 찾나
설치 상태 제대로 깔렸는지
확장·연결·기능 안 쓰는데 매번 실리는 것
설명서 파일 개인용과 공유용의 겹치는 내용
설명서 내용 코드를 보면 알 수 있는 부분
자동 실행 항목 느리게 도는 것

"코드를 보면 아는 건 빼자"

표의 네 번째 줄이 이번 변경에서 가장 눈에 띈 대목입니다. 설명서에 적어둔 내용 중 코드베이스를 읽으면 알아낼 수 있는 부분을 덜어내자고 제안합니다.

📝 왜 이게 흥미로운가

설명서를 쓸 때 우리는 보통 "많이 알려줄수록 좋다"고 생각합니다. 폴더 구조, 쓰는 라이브러리, 파일이 어디 있는지까지 적어두죠. 그런데 그건 코드를 열어보면 그대로 나와 있는 것들입니다.

적어두면 매 대화마다 그만큼이 실리고, 게다가 코드가 바뀌면 설명서가 틀린 말이 됩니다. 스스로 찾을 수 있는 것을 굳이 앞에 놓아 비용과 오류 가능성을 같이 늘리는 셈입니다. 설명서에 남길 것은 "코드를 봐도 모르는 것" — 왜 이렇게 했는지, 무엇을 하지 말아야 하는지 쪽입니다.

같은 맥락에서 설명서 파일이 두 벌 있을 때 겹치는 내용도 정리 대상입니다. 저장소에 함께 올린 공용 파일과 내 컴퓨터에만 있는 개인 파일이 같은 말을 두 번 하고 있으면 두 번 실립니다. 설명서를 쓰는 법을 정리한 적이 있는데, 여기에 "무엇을 빼야 하는가"라는 반대편이 붙은 셈입니다.

고치기 전에 물어봅니다

읽기만 하던 명령이 이제 손을 대는 명령이 됐다는 게 이번 변경의 성격입니다. 그런데 순서가 정해져 있습니다 — 찾은 것을 먼저 보고하고, 무엇이든 바꾸기 전에 확인을 구합니다.

# 실행
/doctor        아무 세션에서나
/checkup       같은 명령의 다른 이름

# 순서
1. 점검             설치·확장·설명서·자동실행
2. 찾은 것 보고     먼저 보여줌
3. 확인 요청        바꾸기 전에 물어봄
4. 정리             허락한 것만

# 알아서 지우지 않습니다

설정을 알아서 정리해주는 도구는 편한 만큼 무섭습니다. 필요해서 둔 것을 "안 쓰는 것"으로 판정해 지워버리면 곤란하니까요. 보고와 실행 사이에 사람 확인을 끼워둔 구조가 그래서 필요합니다. 이름이 진단검진 두 가지인 것도 성격을 잘 보여줍니다.

🔁 안 쓰는 좌석을 줄이는 쪽 말고, 쓰게 만드는 쪽

이 글은 안 쓰는데 값이 나가는 자리를 찾아 줄이는 이야기입니다. 반대쪽 접근을 정리한 공식 안내서가 있어 덧붙입니다 — 팀에서 먼저 잘 쓰는 한 사람이 무엇을 해야 하는지를 적어 둔 문서입니다. 재미있는 건 품이 거의 안 든다는 점입니다. 잘된 사례 올리기 15분, 공개 채널 답변 20분, 주간 스레드 5분 — 주당 40분을 넘기면 잘못된 것이라고 문서가 못 박아 뒀습니다. 그리고 「채널 질문에 나 아닌 사람이 답하면 역할이 끝난 것」이라는 종료 신호까지 있습니다. 좌석을 줄일지 말지 판단하기 전에 이 40분을 한 달 써 보는 쪽이 값싼 실험일 수 있습니다.

🔁 반대로, 쓰려는데 못 쓰게 된 몫도 있습니다

안 쓰는데 값이 나가는 쪽을 점검했으니 반대편도 챙겨 둡니다. 9월 14일 바뀐 주간 한도는 공지 제목이 「기본 대비 25% 인상」이었는데, 5월부터 걸려 있던 50% 임시 증량이 하루 전 끝나면서 실제로 쓰던 양 기준으로는 약 17% 줄었습니다. 둘 다 사실이고 기준선이 다를 뿐입니다. 새는 곳을 막는 점검을 마치셨다면, 쓸 수 있는 양 자체가 줄지 않았는지도 한 번 재 보세요.

🔁 안 쓰는 것이 남기는 건 값만이 아닙니다

안 쓰는데 값이 나가는 것들을 훑었는데, 같은 목록이 보안 쪽에서도 그대로 걸립니다. 확장 묶음 갱신을 노린 공격깔려만 있어도 성립하고, 세션을 켜는 것만으로 훅 이벤트가 일어납니다. 게다가 실험에서 상용 백신 탐지율이 0%로 나왔고 모델도 그 명령을 보지 못합니다. 쓰지 않는 묶음은 값만 먹는 게 아니라 확인되지 않는 자리를 하나씩 남기는 셈이니, 점검표를 돌리실 때 「안 쓰면 지운다」를 같은 칸에 적어 두세요.

자주 묻는 질문

Q. 언제 돌려보면 좋을까요?

이것저것 붙인 게 쌓였다 싶을 때가 적기입니다. 확장을 여러 개 깔았거나, 연결을 이것저것 시험해봤거나, 설명서를 계속 늘려온 경우요. 반대로 막 시작해서 붙인 게 거의 없다면 나올 게 없습니다. 정기적으로 돌릴 성격이라기보다 "뭔가 무거워졌다" 싶을 때 쓰는 쪽에 가깝습니다.

Q. 설명서를 얼마나 줄여야 하나요?

기준은 "코드를 봐도 모르는 것만"입니다. 폴더 구조나 쓰는 도구 목록은 빼도 되고, 왜 그렇게 했는지, 무엇을 건드리면 안 되는지는 남겨야 합니다. 짧게 유지하는 실제 사례로 65줄짜리로 관리하는 방식을 정리한 적이 있습니다.

Q. 지우라는 걸 다 지워도 되나요?

"안 쓴다"는 판정은 지금까지의 기록을 근거로 한 것입니다. 계절마다 한 번 쓰는 도구, 특정 작업에서만 부르는 연결은 안 쓰는 것처럼 보일 수 있습니다. 확인을 구하는 단계가 있는 이유가 그것이니, 목록을 훑으면서 하나씩 판단하시는 게 맞습니다.

🧾 솔직하게 밝혀둘 것

공식 변경점을 읽고 정리한 것이고 직접 돌려본 결과가 아닙니다. 실제로 무엇을 얼마나 찾아주는지는 확인하지 못했습니다.

"안 쓰는 것을 어떤 기준으로 판정하는지" 문서에 없습니다. 사용 기록을 본다는 것은 제 추정이니 결과는 직접 확인하세요.

"코드를 보면 아는 건 빼자"에 대한 해설은 제 정리입니다. 문서에는 그런 제안을 한다는 사실만 적혀 있습니다.

한 주치(7월 6~10일) 변경점이고 버전 조건이 붙습니다. 이후 판본에서 달라졌을 수 있습니다.

절약 효과를 숫자로 재보지 않았습니다. 얼마나 가벼워지는지는 붙여둔 양에 따라 크게 다를 겁니다.

✨ 정리하면

도구를 오래 쓰면 붙이기만 하고 떼지는 않게 됩니다. 안 쓰는 것에도 값이 붙는다는 걸 평소엔 못 느끼니까요. 이번 변경은 그 안 보이는 비용을 목록으로 보여주고 정리까지 도와주는 쪽입니다. 개인적으로 가장 인상적인 건 "코드를 보면 알 수 있는 건 설명서에서 빼라"는 제안이었습니다 — 많이 적어둘수록 좋다는 통념의 반대편이라서요.

설명서를 쓰는 쪽은 작성법 정리짧게 유지하는 사례에 있고, 최근 주간 변경점은 예쁜 화면이 막고 있던 것에 이어집니다. AI에 쓰는 돈 전체는 AI 지출 허브에서 순서대로 보실 수 있습니다.

※ 출처: 제조사 공식 문서의 주간 변경점 페이지(2026년 7월 6~10일 구간) 원문. 2026년 8월 25일 확인 기준이며, 명령 동작과 점검 항목은 이후 버전에서 바뀔 수 있습니다.

반응형
Comments