Antigravity CLI 출력이 비어 있을 때 transcript 로그를 확인하는 노트북 작업 화면
| |

Antigravity CLI 출력이 비어 있을 때 transcript 로그로 확인하는 법

ByFMNOTE Editorial
Antigravity CLI 출력이 비어 있을 때 transcript 로그를 확인하는 노트북 작업 화면

Antigravity CLI를 자동화에 붙여 두면 가끔 가장 난감한 증상이 나온다. 명령은 끝났고 에러도 크게 보이지 않는데, 터미널 표준 출력이 비어 있다. 이때 바로 “모델이 답을 안 했다”고 결론 내리면 확인 순서가 꼬인다. 실제로는 답변이 저장돼 있는데 stdout만 비어 있거나, 로그인·권한·타임아웃 문제로 응답을 끝까지 못 받은 경우가 섞인다.

이런 종류의 CLI를 크론이나 블로그 자동화 말투 검수에 붙일 때는 먼저 결과 파일과 transcript 로그를 갈라서 본다. 화면에 아무것도 안 찍혔다는 사실보다 “모델 응답이 로그에 남았는지”가 더 중요하다. 여기서는 Antigravity CLI에서 출력이 비어 보일 때 실제로 원인을 좁히는 순서를 정리한다.

stdout이 비었다고 같은 장애는 아니다

처음 확인할 것은 종료 코드와 저장된 transcript다. CLI가 정상 종료했는데 stdout만 비어 있으면, 모델 응답은 내부 로그에 남아 있을 가능성이 있다. 반대로 종료 코드가 실패이고 stderr에 인증 문구가 있다면, 글을 다시 다듬기보다 로그인/OAuth 상태를 먼저 봐야 한다. 둘을 섞어 보면 불필요하게 프롬프트만 바꾸게 된다.

  • stdout만 비어 있음: transcript에 MODEL 응답이 있는지 확인한다.
  • stderr에 auth, login, quota, eligibility 문구: 자동 발행을 멈추고 로그인·권한 문제로 분리한다.
  • 타임아웃: 프롬프트 길이, 네트워크, CLI 실행 시간 제한을 따로 본다.
  • 응답은 있는데 구조가 깨짐: 자동 적용하지 말고 수동 검수 대상으로 돌린다.

이 구분은 단순하지만 효과가 크다. 특히 WordPress 글을 자동으로 다듬는 흐름에서는 “출력이 안 보인다”와 “검수 결과가 없다”를 같은 말로 취급하면 안 된다. 후자는 공개 게이트를 막아야 하지만, 전자는 로그에서 응답을 회수할 수 있다.

transcript.jsonl에서 마지막 MODEL 응답 찾기

Antigravity CLI는 세션별로 transcript 로그를 남긴다. Windows 기준으로는 사용자 홈 아래의 Antigravity/Gemini 계열 CLI 저장소에서 transcript.jsonl을 찾는 식이다. 정확한 절대 경로는 환경마다 다르므로, 자동화 스크립트에는 사용자명이나 토큰 값을 박지 않는 편이 안전하다.

brain_dir = Path.home() / ".gemini" / "antigravity-cli" / "brain"
for transcript in brain_dir.glob("*/.system_generated/logs/transcript.jsonl"):
    # 실행 marker가 들어 있는 최신 transcript를 찾고,
    # source == "MODEL" 인 마지막 content만 추출한다.

핵심은 실행마다 marker를 심어 두는 것이다. 단순히 가장 최신 파일만 읽으면 다른 세션의 응답을 가져올 수 있다. 프롬프트 앞에 임시 marker를 넣고, transcript 안에서 그 marker가 들어 있는 파일만 고르면 자동화 로그와 실제 응답을 비교하기 쉬워진다.

실제 캡처 순서

CLI를 직접 호출한 뒤 stdout, stderr, transcript를 각각 파일로 남긴다. stdout에 내용이 있으면 그대로 사용한다. 비어 있으면 marker가 들어 있는 transcript를 찾아 마지막 MODEL 응답만 꺼낸다. 여기서도 응답이 없으면 자동화 문제로 확정하고 공개 작업을 멈춘다.

  • 1단계: 명령 실행 전 marker 생성.
  • 2단계: stdout과 stderr를 별도 파일로 저장.
  • 3단계: stdout이 비었을 때만 transcript를 검색.
  • 4단계: 마지막 MODEL content를 추출하되, 비밀값이나 계정 정보는 출력하지 않음.
  • 5단계: 응답이 글 구조·링크·사실을 바꿨는지 diff로 확인.

이 방식은 CLI 출력 문제를 “프롬프트가 나쁜가?”가 아니라 “응답 회수 경로가 어디에서 끊겼나?”로 바꿔 준다. 운영 중에는 이 차이가 꽤 크다. 프롬프트를 계속 고치는 것보다, stdout·stderr·transcript를 나눠 보는 쪽이 훨씬 빨리 끝난다.

자동 적용 전에는 diff를 본다

transcript에서 응답을 찾았다고 해서 바로 본문에 적용하면 안 된다. 말투 보정용으로 호출한 모델이 링크를 지우거나, HTML 블록을 단순 문단으로 바꾸거나, 없던 설명을 덧붙이는 경우가 있다. 특히 블로그 글에서는 이미지 URL, 내부 링크, 가격·스펙 같은 사실 정보가 바뀌면 작은 문장 수정이 아니라 발행 사고가 된다.

그래서 Antigravity 응답은 최종본이 아니라 검수 초안으로 본다. 원문과 비교해서 링크 수, 이미지 수, 제목 구조, 코드 블록, 금지 문구를 확인한 뒤에만 반영한다. 조금이라도 구조가 흔들리면 rewrite 결과를 버리고, “이 글이 자연스러운지 판정만 해 달라”는 식의 검수 요청으로 낮춘다.

로그를 남기는 위치도 결과물의 일부다

크론에서 실행하는 작업이라면 “성공했다”는 말보다 확인 가능한 파일이 먼저다. stdout, stderr, transcript 추출 결과, 공개 반영 여부를 분리해 두면 다음 날 같은 문제가 나와도 처음부터 다시 의심하지 않아도 된다. 이 흐름은 AI 에이전트 크론 작업은 결과 파일부터 남겨야 덜 꼬인다에서 정리한 기준과도 맞닿아 있다.

Gemini CLI OAuth 쪽 문제는 Gemini CLI OAuth 크론 오류 체크리스트처럼 별도로 봐야 한다. stdout이 비었다고 해서 무조건 OAuth 문제는 아니지만, stderr에 로그인·권한 문구가 보이면 자동화 복구보다 사용자 로그인 확인이 먼저다.

짧은 판단 기준

  • stdout이 비어도 transcript에 MODEL 응답이 있으면 회수 가능성이 있다.
  • transcript에도 응답이 없으면 프롬프트보다 실행·인증·타임아웃을 먼저 본다.
  • 응답을 회수해도 자동 적용 전 diff 확인은 필수다.
  • 비밀값, 계정명, 토큰은 stdout·stderr·블로그 본문 어디에도 남기지 않는다.

결국 이 문제는 “AI가 답했나?”보다 “답변을 안전하게 회수하고 검증할 수 있나?”에 가깝다. 자동화가 길어질수록 화면 출력 하나에 기대는 방식은 불안하다. transcript를 결과 확인 경로에 넣어 두면, 조용히 실패한 것처럼 보이는 실행도 훨씬 차분하게 분리할 수 있다.

Similar Posts