글

처음 읽는다면

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

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

Aside CLI 맥 설치, 앱 버전만 보면 놓치는 것

Aside를 맥에 설치했다면 확인할 것이 두 가지다. 하나는 /Applications 에 들어가는 앱이고, 다른 하나는 터미널에서 부르는 aside 명령이다. 2026년 9월 8일 Apple Silicon(darwin arm64) Mac에 설치할 때 이 둘은 위치도, 버전도, 설치 방법도 달랐다. 앱이 열린다고 해서 셸에서 명령이 잡힌다는 보장은 없다. 이 글은 맥에서 Aside를 터미널 도구로도 쓰려는 개발자를 위한 확인 순서다. 목표는 앱과 CLI가 각각 어디에 있는지 확인하고, 새 로그인 셸에서 aside --version 과 aside --help 가 실행되는 상태까지 가는 것이다. 범위를 먼저 밝힌다. 아래 버전과 경로는 9월 8일 설치 당시 값이다. 버전은 이후 바뀔 수 있다. 계정 로그인과 MCP 연결은 당시 설치 검증에 포함하지 않았기 때문에 이 글에서도 다루지 않는다. 설치 대상은 두 개였다 구분 설치 위치 설치 방법 설치 당시 버전 앱 /Applications/Aside.app Homebrew cask aside (공식 배포 DMG를 Homebrew가 내려받음) 1.0.825.1 CLI ~/.local/bin/aside (심볼릭 링크) 공식 개발자 문서의 설치 스크립트 1.26.906.1630 두 버전 번호는 형식부터 다르다. 앱 버전을 확인했다고 CLI 버전까지 확인한 것이 아니라는 점을 여기서 알 수 있다. 1단계: 앱 설치를 확인한다 앱은 Homebrew cask aside 로 설치했다. 기록에는 cask 이름만 있고 실행한 명령 원문은 없다. cask 이름으로 쓰면 설치 명령은 다음과 같다. brew install --cask aside 이 cask는 Aside 공식 배포 서버의 DMG를 내려받아 /Applications/Aside.app 에 설치했다. 당시 기록에는 앱 설치 명령, 코드서명 검증 명령, 실행 확인 명령이 모두 종료 코드 0으로 끝났다고 남아 있다. 코드서명 확인에 쓴 정확한 명령은 기록에 없다....
댓글 쓰기
자세한 내용 보기

Claude Code v2.1.300 업데이트 전에 볼 것: 훅 updatedInput 검증, 종료 시 백그라운드 강제 종료

Claude Code v2.1.300이 2026-10-15 03:24 KST(2026-10-14T18:24:25Z)에 공개되었다. 직전 릴리스는 v2.1.299(2026-10-14T02:49:42Z)와 v2.1.296(2026-10-09T19:28:59Z)이었다. 매일 이 도구를 사용하는 개발자라면 훅의 updatedInput 입력 검증 강화, 세션 종료 시 백그라운드 프로세스 강제 종료, 로컬 기록(transcript)에 시스템 프롬프트가 남는 변경 사항을 먼저 확인해야 한다. 무엇이 나왔나 GitHub anthropics/claude-code 릴리스 노트 v2.1.300(2026-10-15 확인)에 따르면 이번 버전의 변경 항목은 전체 88개다. 줄머리 첫 단어 기준으로 분류하면 Fixed 41개, [VSCode] 12개, Changed 11개, Added 8개, [Claude Tag] 5개, Improved 4개, 그 외 7개(Removed 1개, Self-hosted runner 1개, [Cloud sessions] 2개, [Remote Control] 1개, [Code Review] 2개)다. 줄머리가 Fixed인 항목이 41개로 전체의 절반에 조금 못 미친다. 훅을 쓰는 사람이 볼 것 이번 릴리스에서 훅 동작에 여러 변경과 수정이 포함되었다. PreToolUse와 PermissionRequest 훅이 돌려주는 updatedInput 을 Claude 자신의 입력처럼 검증하도록 바뀌었다. 알 수 없는 키는 버려지고, 도구가 거부하는 입력이면 호출 자체를 거부(deny)한다. 이전 글인 Claude Code 훅이 안 막는 이유 — 로컬 적용 범위와 deny 점검 에서 다룬 훅 점검 흐름에 이어, 훅 스크립트가 반환하는 인자 형태를 다시 점검할 필요가 있다. 또한 agent 훅이 model 을 무시하던 문제가 수정되었다. 이제 haiku 같은 별칭이 정상 해석되고 서브에이전트 모델이 이를 덮어쓰지 않으며, 사용할 수 없는 모델일 경우 동작 허...
댓글 쓰기
자세한 내용 보기

Gemini CLI 로그인이 막혔다, 결국 agy로 넘어간 이유

2026년 10월 4일, 블로그 원고 작성을 Gemini에게 맡기려고 Gemini CLI를 열었다가 개인 Google 계정 로그인에서 막혔다. 같은 날 Antigravity CLI( agy )를 Homebrew로 설치하고 OAuth로 로그인한 뒤, 신뢰 폴더에서 -p 비대화형 실행으로 첫 문장을 받았다. 그 순서를 기록한다. 대상은 개인 계정으로 Gemini 계열 CLI를 처음 붙이려는 개발자다. 목표는 모델 품질 비교가 아니라 설치, 로그인, 첫 출력까지 한 번 통과하는 것이다. 아래 내용은 10월 4일 당시 내 환경의 기록이다. 일반 Gemini CLI가 서비스를 끝냈다는 뜻이 아니며, 지금 모든 개인 계정에서 같은 오류가 난다고 확인한 것도 아니다. 무엇이 막혔나 당시 설치돼 있던 것은 Homebrew로 받은 gemini 0.46.0이었다. 개인 Google 계정으로 로그인하려 하자 개인용 Gemini Code Assist 로그인이 더는 지원되지 않는다는 안내가 나왔다. 기록에 남긴 문구 일부는 다음과 같고, 안내는 Antigravity 쪽으로 이어졌다. no longer supported for Gemini Code Assist for individuals 이 문구는 기록에 옮겨 둔 일부라 전체 원문은 아니다. 같은 오류를 만났다면 화면의 전체 문구와 안내 대상이 무엇인지 직접 확인하자. 나는 이 안내를 따라 Gemini CLI 로그인을 더 붙잡지 않고 Antigravity CLI로 옮겼다. 1. Homebrew로 agy 설치 설치는 cask 한 줄이었다. brew install --cask antigravity-cli 설치 결과 실행 파일은 /opt/homebrew/bin/agy 였고 버전은 1.2.16이었다. 같은 문제를 겪는다면 설치 직후 실행 파일 위치와 버전부터 기록해 두자. 나중에 동작이 바뀌었을 때 어느 버전 기준의 경험인지 구분할 수 있다. 2. Google OAuth로 로그인 로그인은 Google OAuth였다. 내...
댓글 쓰기
자세한 내용 보기

Claude Code 'No credential slots' 오류, 한도인 줄 알았는데 아니었다

Claude 호출이 실패하면 요금제부터 올리고 싶어진다. 그 전에 실패가 정말 모델 사용량 문제인지, 내 컴퓨터의 하네스가 쥐고 있는 인증 슬롯이 모두 막힌 것인지 먼저 확인해야 한다. 2026년 9월 15일과 16일, Claude를 쓰는 에이전트 하네스 omo에서 겪은 실패는 로컬 인증 슬롯 단계에서 먼저 드러났다. 15일에는 두 슬롯이 모두 rate-limit로 차단돼 있었고, 16일에는 한 슬롯이 응답하는데도 여러 세션이 슬롯을 나눠 잡아 추가 요청이 막혔다. 이 글은 여러 세션에서 Claude를 돌리다 호출이 막힌 개발자를 위한 확인 순서다. 목표는 결제 여부를 판단하기 전에 오류 문자열, 로컬 슬롯 상태, 실패·성공 시각, 동시 호출 수를 차례로 보고 다음 행동을 고르는 것이다. 먼저 범위를 밝힌다. 아래 오류는 omo 런타임의 인증 슬롯 장애 조치에서 나온 것이다. Claude Code 공식 /usage 화면이나 공식 한도 안내와 같은 오류가 아니고, 9월 기록의 일회성 사례다. 지금 모든 계정에서 같은 일이 생긴다는 뜻도 아니다. 무슨 일이 있었나 2026년 9월 15일, 텔레그램으로 보낸 요청 세 건이 작업 세션에 정상적으로 들어갔다. 그런데 회신은 세 건 모두 요청 처리가 끝났지만 최종 답변을 확인하지 못했습니다 였다. 처음에는 텔레그램 연결 문제처럼 보였다. 같은 시각의 인증 상태를 보니 원인은 다른 곳에 있었다. omo의 credential pool에서 Claude용 claude-sdk-oauth 슬롯 두 개가 모두 rate-limit 상태였다. default 슬롯은 15:42:46 KST까지 차단돼 있었고 failureCount는 5였다. account-2 슬롯은 15:31:28까지 차단, failureCount 3이었다. 런타임(Senpi)의 장애 조치 함수 runCredentialFailover 는 사용할 수 있는 후보 슬롯이 0개면 No credential slots available 을 던진다. 결국 그 폴백 문구...
댓글 쓰기
자세한 내용 보기

Gemini 4 Argon 출시, API로 쓰기 전에 볼 것: 유료 등급 전용, 12월 가격 2배, 명시 캐시 없음

출시 개요 Google이 2026년 10월 13일 플래그십 AI 모델인 Gemini 4 Argon(모델 코드 gemini-4-argon )을 정식 출시(GA)했다. 개발자가 API나 개발 환경에 적용하기 전에 확인해야 할 핵심은 세 가지다. 무료 등급(Free tier) 없이 유료 등급(Paid Tier)에서만 제공된다는 점, 2026년 11월 30일까지만 소개 가격이 적용되고 12월 1일부터는 가격이 2배로 오른다는 점, 그리고 명시적 컨텍스트 캐싱이 지원되지 않아 이를 쓰던 코드는 고쳐야 한다는 점이다. 제공 대상과 사용 환경 구분 공식 안내 문서(What's new 및 가격 안내 문서, 확인일 2026-10-15)에 따르면 Gemini 4 Argon의 제공 범위는 서비스 형태에 따라 차이가 있다. 일반 사용자는 Gemini 앱과 검색 AI 모드에서 Google AI Ultra 또는 Google AI Pro 구독을 통해 이용할 수 있다. 하지만 개발자용 API 환경에서는 정책이 다르다. Gemini API와 Google AI Studio에서는 무료 등급과 Google AI Pro 플랜으로 Gemini 4 Argon을 사용할 수 없다. 개발자가 API나 Google AI Studio에서 이 모델을 쓰려면 Gemini API 유료 등급(Paid Tier)을 이용해야 하며, Google AI Ultra 구독자는 Google AI Studio와 Google Antigravity에서 사용할 수 있다. 기업 사용자는 Gemini for business, API, Google Antigravity를 통해 접근 가능하다. 한편 과학자와 연구자는 Google Antigravity 최고 사용 등급을 6개월 무료로 쓰는 프로그램에 신청할 수 있고(1만 명, 자격·용량·선정 조건, 순차 온보딩), 보안 방어자는 Fairwind Program 신청 시 사이버 가드레일이 없는 Argon 접근을 순차적으로 제공받는다. API 가격과 캐싱 정책 Gemini API 유...
댓글 쓰기
자세한 내용 보기

브라우저 자동화 대기: 90초 타임아웃이 나도 화면부터 확인하는 이유

브라우저 자동화는 몇 초가 지났는지가 아니라 필요한 상태가 생겼는지를 기다려야 한다. 감시를 행동보다 먼저 등록하고, 완료 조건을 만족하면 진행하되 제한 시간을 넘으면 현재 화면을 확인한다. 이 방식은 글 작성·예약 발행을 자동화하는 개발자가 입력 반영과 저장 결과를 구분하는 데 쓸 수 있다. 2026년 10월 13일 실행 로그에는 NavigationReadinessTimeoutError 가 30초 대기에서, 이어 90초로 늘린 대기에서도 남아 있다. 그 뒤 현재 화면 스냅숏을 읽고 진행해 8편을 예약했고, 각 글을 다시 열어 확인했다. 같은 실행 안에서도 30초 준비 대기 타임아웃은 여덟 번 더 났지만, 매번 화면을 읽고 다음 단계로 갔다. 30초를 90초로 바꾸면 해결될까? 준비 완료를 기다리다가 타임아웃이 나면 제한 시간부터 늘리고 싶어진다. 그런데 대기 시간이 부족한지, 기다리는 신호가 작업의 완료 조건과 다른지 먼저 나눠야 한다. 같은 종류의 대기가 90초에서도 끝나지 않았다는 보고만으로 브라우저 내부 원인을 단정할 수는 없다. 오류 이름이 말해 주는 것은 준비 상태 대기가 제한 시간 안에 끝나지 않았다는 사실이다. 입력이 실패했다거나 저장이 취소됐다는 뜻까지 담고 있지는 않다. 타임아웃 뒤 화면을 읽지 않고 클릭을 반복하면 현재 상태와 다른 행동을 할 수 있다. 붙여넣기에서도 비슷한 구분이 필요했다. 9월 27일 SmartEditor 조사에서는 합성 paste 이벤트가 처리됐지만 직후 본문은 한 문단으로 보였다. 나중에는 시험용 두 문단이 들어왔다. 이벤트 반환과 본문 반영을 같은 순간으로 취급한 검사가 잘못된 실패 판정을 만든 것이다. 최소 재현은 단순하다. 시험용 편집기에서 붙여넣기 직후 본문을 한 번 읽고, 변경 감시가 확인한 본문과 비교한다. 앞의 읽기만으로 실패를 판정하는 순서와, 감시를 먼저 붙이는 순서를 대조하면 된다. 실제 글을 발행할 필요는 없다. 먼저 구독하고 나서 행동한다 완료 조건은 행동 전에 정한다. 붙여넣기...
댓글 쓰기
자세한 내용 보기

사실 검증 조건: AI 검수자가 제안한 두 문장, 왜 다시 반려됐나

AI가 제안한 수정 문장도 원문과 다시 대조해야 한다. 출처가 존재하는지보다 그 출처의 조건이 실제 문장에 남아 있는지가 승인 기준이다. 2026년 10월 13일 검수 기록에는 이전 검수자가 제안한 문장 두 곳을 다시 FAIL로 돌린 사례가 남아 있다. AI의 설명을 문서나 안내문에 옮기는 개발자라면 이 차이가 중요하다. 검수 요청에 “사실을 확인해”만 적지 말고, 주장·출처·문장과 반려 조건을 같이 넘겨야 한다. 검수자의 문장도 왜 틀렸을까 해당 기록에서 형식 검사와 가독성 검사는 통과했다. 그런데 원고 A의 첫 답과 원고 B의 결론은 각 원고가 보관한 근거와 맞지 않았다. 두 문장 모두 앞선 검수자가 직접 제안했던 표현이었다. 한 문장은 적용 대상을 넓혔다. 다른 문장은 특정 선택지의 기한을 모든 선택지의 소멸로 바꿨다. 문장은 매끈했지만 출처가 허용한 범위보다 강했다. 이를 특정 모델의 우열로 해석하지 않는다. 확인된 것은 두 문장의 오류와 반려 이유다. 모델별 누락률이나 검수 정확도를 비교한 실험은 이 기록에 없다. 사례 A: 처음 계약의 조건이 빠졌다 원고 A는 계약을 중간에 끝낼 수 있는 조건을 설명했다. 검수 기록에 남은 전·후 문장은 다음과 같다. > 전: “해지 특약이 없다면 세입자 혼자 계약을 끝낼 수 없어서, 합의하지 못하면 만료일까지 월세를 내야 합니다.” > > 후: “처음 정한 계약기간 중이고 해지 특약이 없다면, 합의하지 못하는 한 만료일까지 월세를 내야 합니다.” ‘후’는 그다음 검수자가 새로 제시한 수정안이다. 이 기록만으로 수정 적용이나 최종 PASS까지 확인한 것은 아니다. 빠진 부분은 “처음 정한 계약기간 중”이다. 저장된 법령의 제6조의2는 묵시적으로 갱신된 계약에서 임차인이 언제든 해지를 통지할 수 있다고 정한다. 효력은 임대인이 통지를 받은 날부터 3개월이 지나면 생긴다. 제6조의3 제4항은 갱신요구권으로 갱신된 계약의 해지에도 제6조의2를 준용한다. 그래서 ‘특약이 없다’는 조건만으...
댓글 쓰기
자세한 내용 보기