글

처음 읽는다면

설정의 시작부터 막힌 문제, 도구에 드는 비용까지.

최근 보완: 2026-09-23 · 위 핵심 글 4편. 점검 순서와 관련 글을 보완했습니다. 실측·코드 분석·가정 계산은 구분해 표시합니다.

Claude Code 비밀값 노출 원인과 로컬 설정 파일 점검법

이미지
Claude Code CLI에서 Bash 명령을 다시 묻지 않기로 승인하면 허용 규칙이 프로젝트의 .claude/settings.local.json 에 문자열로 저장된다. 규칙에 토큰이나 비밀번호가 평문으로 들어 있으면 값도 함께 남고, 이 파일을 공개 저장소에 커밋해 푸시하면 값도 공개된다. 공식 문서와 Apiiro 보고서는 2026-11-09 KST에 확인했고, Git 동작은 더미 파일로 직접 실행해 봤다. 영구 승인이 모든 명령을 덤프하지는 않지만, 비밀값이 든 정확한 명령을 승인하고 이 파일이 Git에 커밋되면 평문이 저장소에 남는다. Claude Code 비밀값 노출은 승인 규칙에서 어떻게 시작될까 다시 묻지 않기를 고른 승인은 어디에 남을까. Anthropic의 Configure permissions 공식 문서는 Bash 영구 승인이 저장소와 명령별로 지속된다고 설명한다. CLI 기준 저장 위치는 .claude/settings.local.json 이고, 규칙 형식은 Tool 또는 Tool(specifier) 다. Bash 규칙에 * 가 없으면 정확한 명령 전체를 허용한다. * 가 있으면 그 자리에 어떤 텍스트가 와도 허용한다. 그래서 아무 명령이나 한 번 승인하면 비밀값이 저장된다는 말은 과장이다. 반대로 헤더나 환경변수 할당에 실제 토큰을 넣은 명령을 정확한 규칙으로 승인하면, 그 문자열이 permissions.allow 에 평문으로 들어간다고 본다. 비밀값이 든 명령은 지속 승인을 거쳐 로컬 설정의 허용 규칙이 된다. 공개 저장소까지 이어지는 것은 Git 커밋과 공개 저장소 푸시가 겹칠 때뿐이다. 공개 저장소에서는 얼마나 발견됐을까 Apiiro의 보고서 Coding Agents Are Leaking Your Secrets to GitHub는 2026-11-01부터 03일까지 공개 GitHub 기본 브랜치를 읽기 전용으로 검색한 결과다. 아래 수치는 모두 Apiiro의 분류 결과이며, 이번에 다시 조사하지 않았다. 공개 .cl...
댓글 쓰기
자세한 내용 보기

제미나이 CLI 대신 agy 반복 실행: 대기열과 종료 판정 기준

이미지
제미나이 CLI에서 Antigravity CLI(agy)로 옮긴 뒤 스크립트로 원고를 반복 생성한다면, 본문 출력과 프로세스 종료를 따로 판정해야 한다. 한 번에 한 요청만 직렬로 돌리고 부모 프로세스에서 외부 시간 제한을 거는 조건에서 세운 기준이다. 근거는 2026-10-16 운영 기록과 2026-11-03 로컬 agy 1.4.12 실측이다. agy 1.3.6에서 겪은 출력 후 미종료는 이 환경의 과거 운영 기록이고 1.4.12 실측 3건은 스스로 종료했으므로, 버전을 가정하지 말고 외부 제한과 출력 검수를 함께 둔다. 제미나이 CLI 다음, agy 반복 실행이 막히는 지점 Gemini CLI와 agy는 다른 도구다. 명령어와 JSON 규격, 설정 경로를 섞으면 안 된다. Google 개발자 블로그 공지(2026-05-19 발표)는 2026년 6월 18일부터 Gemini CLI가 요청 처리를 멈춘다고 알렸다. 대상은 Google AI Pro·Ultra와 Gemini Code Assist for individuals 무료 이용자이며, 모든 이용자가 아니다. 터미널에서 한 번 응답을 받는 것과 스크립트가 요청을 차례로 처리하는 것은 조건이 다르다. 스크립트는 화면을 보는 사람 없이 종료 코드와 표준 출력만으로 다음 단계를 정한다. 2026-10-16 운영 메모에는 agy 1.3.6에서 본문이 다 나온 뒤에도 프로세스가 끝나지 않은 일이 적혀 있다. 여러 요청을 동시에 띄웠을 때 출력 없이 멈춘 일도 함께 기록돼 있다. 그래서 첫 호출에 성공했다면 다음에 세울 것은 호출 명령보다 실행 대기열과 종료 판정 규칙이다. 문서와 도움말, 그리고 1.4.12 실측 Antigravity CLI 공식 헤드리스 문서(2026-11-03 확인)에 따르면 -p 또는 --print 는 요청 하나를 실행하고 끝낸다. 응답은 stdout 으로, 오류·인증 안내·진행 상태는 stderr 로 나간다. 같은 문서는 --print-timeout 기본값을 5m 으로 적는다...
댓글 쓰기
자세한 내용 보기

MCP 서버 연결 확인법: 목록 표시와 실제 도구 호출 구별

이미지
코딩 에이전트 CLI에서 MCP 서버가 목록에 보여도 그것만으로 도구가 작동한다고 판정할 수는 없다. macOS의 로컬 stdio 서버 하나를 기준으로 하면 설정 읽기, 서버 초기화, 실제 도구 호출은 서로 다른 출력으로 확인해야 한다. 실측과 공식 문서 확인은 모두 2026-11-03에 했다. Codex에서는 없는 경로를 준 고장 설정도 enabled 로 표시됐다. 성공 여부는 mcp_tool_call 이벤트의 도구 이름과 반환값으로 판정해야 했다. MCP 서버가 목록에 있는데 왜 도구는 작동하지 않을까 MCP 공식 아키텍처·전송 문서에 따르면 로컬 stdio 연결에서 클라이언트는 서버를 자식 프로세스로 실행한다. 설정에 명령이 적혀 있는 것과 그 프로세스가 살아서 응답하는 것은 별개다. 그래서 이 글은 확인 과정을 등록·읽기, 시작·초기화, 실제 호출 세 단계로 나눈다. MCP 공식 명칭은 아니다. 실패 지점을 좁히려고 이 글에서 정한 진단 분류다. 설정 읽기가 통과해도 초기화나 도구 호출에서 멈출 수 있으므로 단계마다 다른 증거를 봐야 한다. 다른 폴더에서 서버가 보이지 않는 이유 Claude Code 공식 문서는 등록 범위를 local , project , user 로 나눈다. 기본값 local 은 현재 프로젝트에만 적용되며 ~/.claude.json 의 프로젝트 경로별 항목에 저장된다. Claude Code 2.1.274 와 codex-cli 0.161.0 으로 ~/workspace 에서 직접 실행해 봤다. claude mcp list 와 codex mcp list 모두 서버가 없다고 나왔다. ~/.claude.json 에서 프로젝트 키와 서버 이름만 뽑아 보니 홈 폴더( ~ ) 항목에는 chrome-devtools 가 있었고 ~/workspace 항목에는 서버가 없었다. local 범위에 등록한 서버를 전역 설정으로 오해하면 다른 폴더에서 서버가 사라진 것처럼 보인다. 설정 등록과 실제 도구 호출은 어떤 출력으로 구별하는가 ...
댓글 쓰기
자세한 내용 보기

Codex CLI 비대화형 실행: 스크립트에서 작업 맡기고 검증하는 법

이미지
대화창 없이 스크립트에서 Codex CLI에 파일 수정을 맡기려면 codex exec 에 작업 폴더와 -s workspace-write 를 지정하고, 신뢰된 폴더나 Git 저장소가 아니면 --skip-git-repo-check 를 더해야 한다. 이 결과는 설치와 인증을 마친 macOS arm64의 codex-cli 0.161.0 에서, 대상이 수정 가능한 로컬 파일일 때 성립한다. 공식 문서와 로컬 실행은 모두 2026-11-03에 확인했다. codex exec 의 종료 코드 0은 수정 성공이나 테스트 통과를 보증하지 않는다. diff와 테스트 종료 코드로 따로 검증해야 한다. Codex CLI 비대화형 실행은 왜 한 줄로 끝나지 않을까 OpenAI Codex 공식 문서는 codex exec 를 TUI를 열지 않는 스크립트용 실행으로 설명한다. 그런데 이 실행에는 폴더 신뢰 검사와 읽기 전용 기본값이 걸려 있다. 그래서 폴더 지정, 검사 통과, 쓰기 허용, 실행 후 검증을 따로 다뤄야 한다. 세 번 실행해서 확인한 것 재현용으로 Git 저장소가 아닌 새 폴더에 파일 두 개를 만들었다. calculator.py 는 고의로 뺄셈을 반환한다. def add(a: int, b: int) -> int: return a - b test_add.py 는 두 수의 합을 검사한다. from calculator import add # Given two positive integers, when adding, then return their sum. assert add(2, 3) == 5 print("PASS: add(2, 3) == 5") 처음 상태에서 /usr/bin/python3 -B test_add.py 는 AssertionError , 종료 코드 1로 실패했다. 첫 번째 실험은 비 Git 폴더에서 아무 옵션 없이 실행했다. /opt/homebrew/bin/codex exec -C <폴더> "Fix...
댓글 쓰기
자세한 내용 보기

서치콘솔 사이트맵 '가져올 수 없음', 주소는 멀쩡한데 왜?

2026년 10월 13일 GSC Sitemaps 화면에서 이 블로그의 블로그스팟 주소 속성에 있는 /sitemap-pages.xml 은 상태가 "가져올 수 없음"이었다. 같은 날 오후 3시 13분(KST)에 그 주소를 직접 요청하니 HTTP 200과 XML이 돌아왔다. 둘 중 하나가 틀린 것처럼 보이지만, GSC 행의 마지막 읽기 날짜는 2026년 4월 26일이었다. 두 기록은 서로 다른 시점의 기록이다. 대상은 Blogger 블로그를 운영하다 GSC에서 sitemap 오류를 보고, 지금 열어 보면 멀쩡한데 왜 실패로 남아 있는지 궁금한 개발자다. 목표는 URL, 문서 종류, 접근 시각, 마지막 읽기, 발견 페이지를 한 표에 놓고 현재 응답과 과거 처리 기록을 나눠 판정하는 것이다. 아래는 이 블로그 한 곳의 기록이며, 실패 원인은 확정하지 못했다. GSC Sitemaps 화면: 4행 10월 13일 Sitemaps 화면에 등록된 행은 4개였다. 경로 유형 제출 마지막 읽기 상태 발견 페이지 /sitemap.xml Sitemap 2026-06-10 2026-10-12 성공 90 /feeds/posts/default?orderby=updated Atom 2026-04-27 2026-05-02 성공 26 /feeds/posts/default Atom 2026-04-25 2026-10-09 성공 26 /sitemap-pages.xml Sitemap 2026-04-25 2026-04-26 가져올 수 없음 4 글 sitemap인 /sitemap.xml 은 10월 12일에 읽혀 성공이었다. 고정 페이지 sitemap인 /sitemap-pages.xml 은 4월 25일에 제출됐고, 마지막으로 읽힌 날은 그다음 날인 4월 26일이었다. 상태는 가져올 수 없음인데 발견 페이지 칸에는 4가 있었다. 같은 주소의 10월 13일 응답 공개 주소의 응답 헤더 중 판단에 쓴 줄은 다음과 같다. Date 헤더는 Tue, 13 Oct 2026 06:13:43 ...
댓글 쓰기
자세한 내용 보기

Blogger 조회수와 서치콘솔 클릭, 같은 독자가 아니다

2026년 10월 13일, 이 블로그의 Blogger 통계와 Google Search Console(GSC)을 읽기 전용으로 열어 봤다. Blogger의 지난 7일 조회는 1.51천, GSC의 최근 3개월 클릭은 4였다. 두 숫자를 한 줄에 놓으면 "천오백 명이 왔는데 검색으로 온 사람은 넷"처럼 읽힌다. 이 기록으로는 그렇게 읽을 수 없다. 대상은 블로그 발행을 자동화해 놓고 그 성과를 Blogger 조회수로 판단하려는 개발자다. 목표는 두 숫자를 기간과 측정 대상별로 나눠 적고, 국가·리퍼러 표만으로 사람의 검색 유입을 확정할 수 있는지 판정하는 것이다. 아래 값은 모두 이 블로그 한 곳의 2026년 10월 13일 화면 기록이다. 두 숫자는 기간도, 세는 대상도 다르다 지표 화면 기간 값 세는 것 조회 Blogger 통계 지난 7일(차트 2026-10-07~10-13) 1.51천(표시값) 페이지뷰 클릭 GSC 실적, 검색 유형 웹 최근 3개월(2026-07-11~10-10) 4 Google 웹 검색 결과 클릭 Blogger 쪽은 7일이고 GSC 쪽은 약 3개월이다. 날짜만 비교하면 두 기간이 겹치는 날은 10월 7일부터 10일까지다. 게다가 Blogger 통계 화면에는 블로그 시간대 GMT-07:00이 표시됐지만, GSC 화면의 날짜 기준 시간대는 기록하지 않았다. 그래서 "4 ÷ 1,511" 같은 비율은 계산하지 않는다. 분모와 분자가 같은 기간, 같은 대상을 세지 않기 때문이다. GSC 쪽도 기간을 바꾸면 값이 달라진다. 같은 날 읽은 최근 28일(2026-09-13~10-10)은 클릭 1, 노출 74였다. 최근 3개월은 클릭 4, 노출 798, 평균 CTR 0.5%, 평균 게재순위 2.3이었다. 1.51천도 정밀값이 아니다. 주간 조회 카드에는 "1.51천"으로만 표시됐고, 같은 주간 상세 화면의 검색 키워드 표, 국가 표, 추천 URL 표의 합계가 각각 1,511이었다. 카드의 정밀값을...
댓글 쓰기
자세한 내용 보기

3.4MB짜리 Blogger 프로필 사진을 36KB로 줄였다

2026년 10월 13일, 이 블로그의 공개 페이지를 점검하다가 모든 표본 페이지가 3,427,910바이트(약 3.43MB)짜리 프로필 이미지를 참조하고 있는 것을 확인했다. 같은 날 최대 400x400 WebP로 바꿔 올렸다. 교체 완료는 업로드한 파일 크기가 아니라 공개 페이지의 이미지 참조와 응답 상태로 판정했다. 대상은 Blogger를 운영하면서 프로필이나 사이드바처럼 모든 페이지에 붙는 이미지 용량을 줄이려는 개발자다. 목표는 원본과 교체 파일의 크기를 기록하고, 교체 완료는 공개 페이지가 실제로 새 이미지를 참조하는지로 확인하는 것이다. 아래 숫자는 내 블로그 한 번의 교체 기록이다. 이 교체로 페이지 속도가 얼마나 좋아졌는지는 재지 않았다. 1. 모든 페이지에 붙는 큰 이미지를 찾는다 교체 전 감사는 로그인이나 설정 변경 없이 공개 페이지를 GET으로 받아서만 했다. 표본 페이지는 모두 프로필 가젯의 같은 PNG( <img alt='내 사진'> )를 참조했고, 그 응답 본문이 3,427,910바이트였다. 압축을 푼 텍스트 크기가 아니라 PNG 응답 본문의 바이트 수다. 비교 대상도 함께 쟀다. 최신 5편의 본문 cover·diagram 이미지는 56,723~83,411바이트, 인기글 썸네일은 108,006바이트와 165,802바이트였다. 감사는 본문 대표 이미지 대다수가 56~138KB인 데 비해 공통 프로필이 더 큰 정적 부담이라고 정리했다. 다만 감사도 한계를 적어 두었다. 브라우저가 이 이미지를 실제로 언제 요청하는지, lazy loading·cache·srcset으로 어떤 변형을 고르는지는 HTTP 실측으로 확정하지 않았다. 페이지별 무게 합계도 HTML이 직접 참조한 자원만 더한 근사이며, 브라우저 전체 전송량이나 CWV가 아니다. 2. 작게 만들어 같은 자리에 올린다 감사가 제시한 수정 위치는 Blogger → 레이아웃 → 프로필 가젯이었다. 표시 크기에 맞춘 작은 이미지로 바꾸고, 목표는 수십 KB...
댓글 쓰기
자세한 내용 보기