VPS에서 AI 에이전트를 밤새 실행하도록 예약하는 방법

새벽 2시, 한 번도 잠들지 않은 VPS에서 예약된 작업이 시작됩니다. 헤드리스 claude -p 실행은 복제된 저장소에서 대기 중인 작업을 아무에게도 묻지 않고 처리한 뒤 종료됩니다. 아침에 확인해 보면 커밋이나 보고서, 또는 어디서 왜 멈췄는지 정확히 보여주는 로그가 기다리고 있습니다. 아무도 지켜보지 않았습니다.

이는 터미널을 밤새 열어 두고 SSH 연결이 끊기지 않기를 바라는 방식과는 다릅니다. 야간 에이전트 실행에서 흔한 실패 지점은 호스트입니다. 노트북이 절전 모드로 들어가고, 덮개가 닫히고, 네트워크가 끊기고, OS 업데이트가 작업 도중 재부팅을 겁니다. 인증 실패, API 오류, 권한 대기는 여전히 작업을 중단시킬 수 있지만, 항상 켜져 있는 호스트는 가장 쉬운 실패 요인을 없앱니다.

이 가이드는 실제 동작 방식을 다룹니다. 주요 코딩 에이전트 CLI가 제공하는 헤드리스 플래그, 예약 실행을 트리거하는 두 가지 방법과 어느 쪽을 골라야 하는지, 그 아래 호스트에 필요한 것, 그리고 무인 실행이 나중에 설명하고 싶지 않을 만큼 비용을 쓰거나 망가뜨리지 않도록 막아 주는 안전장치입니다.

요약

• 주요 코딩 에이전트 CLI는 모두 프롬프트 하나를 끝까지 실행하고 종료하는 비대화형 모드를 문서화해 제공합니다. Claude Code는 claude -p, Codex CLI는 codex exec, Gemini CLI는 gemini -p. 이는 우회 방법이 아니라 공식 기능입니다.
• Claude Code에는 자체 예약 기능도 있습니다. Routines, Desktop 예약 작업, 그리고 /loop. 어떤 독자에게는 이것으로 충분하며, VPS보다 관리할 것도 적습니다.
• 야간 작업이라면 cron으로 충분합니다. 재부팅될 수 있는 서버라면 systemd 타이머가 더 나은 기본값입니다. Persistent=true Persistent=true는 cron이라면 조용히 건너뛰었을 실행을 붙잡아 줍니다.
• 추론은 제공업체 API에서 이뤄지므로 CLI 자체는 가볍습니다. VPS는 모델이 아니라 그 위에서 실행할 명령(테스트, 빌드, 컨테이너, 병렬 작업)에 맞춰 사양을 정하세요.
• 예약을 그대로 두어도 안전하게 만드는 것은 안전장치입니다. 범위를 좁힌 도구, 턴 상한, 종료 코드 분기가 그것입니다. 예약 자체는 안전장치가 아닙니다.

필요한 것

crontab 한 줄이나 유닛 파일을 작성하기 전에 다음 다섯 가지를 준비하세요.

• SSH로 접속할 수 있고 systemd 기반 리눅스 배포판이 설치된 VPS.
• 해당 VPS에 설치된 에이전트 CLI: Claude Code, Codex CLI 또는 Gemini CLI.
• 선택한 CLI를 위한 비대화형 자격 증명. Claude Code의 bare 모드는 계정 로그인을 읽지 않으므로 환경 변수 ANTHROPIC_API_KEY 를 환경에 두거나, apiKeyHelper 설정에 지정해야 합니다. 일반 print 모드 실행과 Codex, Gemini는 문서화된 계정 로그인 자격 증명도 사용할 수 있습니다.
• 에이전트가 작업할 저장소 또는 작업 디렉터리.
• crontab을 편집하거나 systemd 유닛 파일을 작성할 권한이 있는 셸 접근.

세션 없이 에이전트 실행하기

주요 코딩 에이전트 CLI는 모두 정확히 이런 용도로 만들어진 비대화형 모드를 제공합니다. Claude Code는 -p를 받으며, 길게 쓰면 --print. Codex CLI는 codex exec. Gemini CLI는 -p를 받으며, 길게 쓰면 --prompt를 받습니다. 각각 프롬프트를 받아 끝까지 실행한 뒤 종료합니다. 채팅 루프도, 열어 둘 터미널도, 다시 붙을 대상도 없습니다.

Claude Code는 활성 세션 없이 실행할 수 있나요? 가능합니다. 다음을 전달하면 -p 프롬프트가 비대화형 모드로 실행됩니다. Claude Code가 끝까지 수행하고 결과를 출력한 뒤 종료합니다. 채팅 루프도, 계속 살려 둘 것도 없으며, 대화형 CLI를 움직이는 것과 같은 Agent SDK 위에서 동작합니다. 출처는 Anthropic의 헤드리스 모드 공식 문서.

여기서 가장 중요한 것은 Claude Code 자체의 플래그입니다. 실제로 스크립트를 작성할 대상이기 때문입니다. 그중 둘은, 아무도 깨어 있지 않아 승인해 줄 수 없는 권한 요청 앞에서 멈추지 않고 실행이 계속되게 해 줍니다. --allowedTools는 특정 도구를 미리 승인하고, --permission-mode는 실행 전체의 기준선을 정합니다. --max-turns 는 실행이 오류로 종료되기 전까지 수행할 수 있는 에이전트 턴 수를 제한합니다.

--bare 는 훅, 스킬, 플러그인, MCP 서버, 그리고 다음과 같은 프로젝트 지시문을 건너뜁니다: CLAUDE.md더 빠르고 결정적인 스크립트 실행을 위해서입니다. 그만큼 작업이 의존하는 모든 지시는 프롬프트나 명령에 담겨 있어야 합니다. bare 모드는 계정 로그인도 읽지 않으므로, Anthropic 문서는 환경에 API 키를 설정하라고 안내합니다 . 실행 전에 설정하세요. Claude Code는 --bg 를 다음과 함께 쓰면 곧바로 거부합니다: -p, 그리고 다음도 마찬가지로 거부합니다: --cloud 작업 설명과 함께 넘길 때도 똑같습니다. 무엇이 충돌하는지 알려 주고, 애매한 동작을 하는 대신 멈춥니다.

실제 호출 예시입니다. 프롬프트와 도구 목록은 작업에 맞게 수정하세요.

claude --bare -p "Review open PRs in this repo and summarize any blockers in NOTES.md" \
  --allowedTools "Bash(gh pr list *),Bash(gh pr view *),Bash(gh pr diff *),Read,Edit" \
  --permission-mode dontAsk \
  --max-turns 8 \
  --max-budget-usd 5.00 \
  --output-format json

예산과 명령 패턴은 작업에 맞게 조정하세요. 이 예시는 실행 계정에 GitHub CLI 인증이 이미 설정되어 있다고 가정합니다.

새 VPS에 Claude Code를 설치하면서 브라우저가 없는 서버에서 인증하는 방법이 궁금하다면, 그 내용은 별도로 다음 글에서 다룹니다: 헤드리스 서버에서 Claude Code 인증하는 방법. 위의 짧은 설명만으로도 예약 실행을 돌리기에는 충분합니다.

Codex CLI의 exec 모드는 다음 문서에 설명되어 있습니다: OpenAI의 비대화형 모드 문서. 이 모드는 --sandbox 를 받아 정책을 고릅니다. read-only 가 기본값이고, workspace-write 는 에이전트가 작업 공간 안에 쓰도록 허용하며, --json 는 stdout을 일반 텍스트 대신 기계가 파싱할 수 있는 이벤트 스트림으로 바꿉니다. 무인 작업에서는 danger-full-access 이 옵션을 피하세요. 프로세스가 격리되어 있고 그 위험을 의도적으로 감수하는 경우가 아니라면 말입니다.

Gemini CLI의 헤드리스 모드는 다음 문서에 설명되어 있으며, 프로젝트의 공식 헤드리스 문서TTY가 없는 환경에서는 자동으로, 또는 다음 옵션으로 명시적으로 활성화됩니다: -p. 일반 오류, 입력 오류, 턴 제한 도달 각각에 대해 서로 다른 0이 아닌 종료 코드를 반환하며, 하나의 일반적인 실패 코드로 뭉뚱그리지 않습니다.

예약은 어디에 두어야 할까

이 모든 설정 작업에 들어가기 전에: 에이전트 제공업체가 이미 대신 예약해 줄 수도 있습니다. Claude Code에는 내장 옵션이 세 가지 있고, 그중 하나가 직접 운영하는 VPS보다 정말로 더 잘 맞을 수 있습니다.

Anthropic의 예약 작업 공식 문서 은 이를 VPS를 정점에 둔 위계가 아니라 진짜 세 갈래 선택지로 제시합니다. 작업에 로컬 상태가 필요 없고 1시간이라는 하한을 견딜 수 있으며 Claude Code만 쓴다면, Routines는 아래에서 설명할 방식보다 관리할 것이 적습니다. 내 컴퓨터가 꺼져 있어도 Anthropic이 새로 클론한 사본으로 클라우드에서 실행해 줍니다.

/loop 은 알아 둘 가치는 있지만 이 용도에는 맞지 않습니다. 열려 있고 유휴 상태인 세션을 요구하는데, 그것이야말로 없애려는 제약이기 때문입니다. 같은 문서는 네 번째 선택지로 GitHub Actions도 제시합니다. 트리거가 특정 머신에 묶인 일정이 아니라 이미 CI에 있는 팀을 위한 것입니다.

직접 운영하는 VPS는 작업에 로컬 파일 시스템과 도구에 대한 전체 접근이 필요할 때, Claude Code와 Codex CLI, Gemini CLI에서 같은 방식이 똑같이 동작하기를 원할 때, 또는 Routines가 허용하는 간격이 너무 성길 때 제값을 합니다. 일반적인 서버리스 함수는 여기서 대체로 어색합니다. 자격 증명을 복원하고 저장소를 클론한 뒤 플랫폼의 실행 시간 제한 안에 끝내야 하기 때문입니다. GitHub Actions 같은 일회성 CI 러너는 실행마다 새로 체크아웃해도 괜찮다면 여전히 유효한 세 번째 길입니다. 이미 놀고 있는 상시 가동 하드웨어가 있다면 홈랩 장비도 됩니다. 대신 사업자 대신 집 네트워크의 안정성과 원격 접속이 변수로 들어옵니다.

cron이냐, systemd 타이머냐

두 도구 모두 같은 명령을 같은 일정으로 실행할 수 있지만, 서버가 재부팅될 때 어떻게 되는지와 설정 부담이 얼마나 되는지에서 갈립니다.

거의 재부팅되지 않는 서버의 야간 작업이라면 평범한 cron으로 충분합니다. 함정은 실행 환경입니다. cron은 최소한의 PATH값으로 시작하고, 저장소로 알아서 이동해 주지도 않으며, 첫 번째가 아직 돌고 있어도 태연히 두 번째 사본을 띄웁니다. 저장소 경로와 범위를 좁힌 에이전트 명령, 자격 증명 로딩을 보호된 래퍼 스크립트에 넣고, flock 를 써서 실행이 겹치지 않게 하세요.

# /usr/local/bin/agent-nightly
#!/usr/bin/env bash
set -euo pipefail
export PATH=/usr/local/bin:/usr/bin:/bin
export ANTHROPIC_API_KEY="$(
  cat "$HOME/.config/agent-nightly/anthropic_api_key"
)"
cd /srv/myrepo
exec /usr/local/bin/claude --bare -p \
  "Run the nightly dependency audit and write the findings to NOTES.md" \
  --allowedTools "Bash(npm audit *),Read,Edit" \
  --permission-mode dontAsk \
  --max-turns 8 \
  --max-budget-usd 5.00 \
  --output-format json

# crontab -e
0 2 * * * /usr/bin/flock -n "$HOME/.local/state/agent-runs/nightly.lock" /usr/local/bin/agent-nightly >> "$HOME/.local/state/agent-runs/nightly.log" 2>&1

자격 증명과 로그 디렉터리를 한 번 만들고, 래퍼에 실행 권한을 주세요.

install -d -m 700 \
  "$HOME/.config/agent-nightly" \
  "$HOME/.local/state/agent-runs"
touch "$HOME/.config/agent-nightly/anthropic_api_key"
chmod 600 "$HOME/.config/agent-nightly/anthropic_api_key"
"${EDITOR:-nano}" \
  "$HOME/.config/agent-nightly/anthropic_api_key"
sudo chmod 755 /usr/local/bin/agent-nightly

자격 증명 파일에는 API 키만 붙여 넣으세요. crontab에 직접 넣지 마세요.

systemd 타이머는 설정 부담이 더 크지만, cron에는 없는 두 가지를 줍니다. 직접 리디렉션하지 않아도 되는 journald 로깅, 그리고 Persistent=true. 아래 예시는 전용 agent-runner 계정이 /srv/myrepo를 소유한다고 가정합니다. API 키는 유닛에 박아 넣지 말고 root만 읽을 수 있는 자격 증명 파일에 두세요.

에 따라 systemd.timer 매뉴얼에 따르면, Persistent=true 설정은 "타이머가 비활성 상태였던 동안 한 번이라도 트리거되었어야 했다면 서비스 유닛이 즉시 트리거된다"는 뜻입니다. 즉, 커널 업데이트로 VPS가 재부팅되는 사이에 실행되었어야 할 작업이 다음 예약 시각까지 조용히 사라지는 대신, 시스템이 돌아오는 즉시 실행됩니다.

서비스가 사용할, root만 읽을 수 있는 자격 증명 파일을 만드세요.

sudo install -d -m 700 /etc/agent-nightly
sudo touch /etc/agent-nightly/anthropic_api_key
sudo chmod 600 /etc/agent-nightly/anthropic_api_key
sudoedit /etc/agent-nightly/anthropic_api_key

파일에는 API 키만 붙여 넣으세요.

# /etc/systemd/system/agent-nightly.service
[Unit]
Description=Nightly scoped agent run
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=agent-runner
Group=agent-runner
WorkingDirectory=/srv/myrepo
Environment=HOME=/home/agent-runner
Environment=PATH=/usr/local/bin:/usr/bin:/bin
LoadCredential=anthropic_api_key:/etc/agent-nightly/anthropic_api_key
ExecStart=/bin/sh -c 'export ANTHROPIC_API_KEY="$(cat "$CREDENTIALS_DIRECTORY/anthropic_api_key")"; exec /usr/local/bin/claude --bare -p "Run the nightly dependency audit and write the findings to NOTES.md" --allowedTools "Bash(npm audit *),Read,Edit" --permission-mode dontAsk --max-turns 8 --max-budget-usd 5.00 --output-format json'
StandardOutput=journal
StandardError=journal
UMask=0077

# /etc/systemd/system/agent-nightly.timer
[Unit]
Description=Run agent-nightly.service at 2am daily, catching up missed runs

[Timer]
# Uses the VPS's configured local timezone
OnCalendar=*-*-* 02:00:00
Persistent=true
Unit=agent-nightly.service

[Install]
WantedBy=timers.target

systemd를 다시 읽어들이고, 타이머를 활성화한 뒤, 서비스를 한 번 즉시 실행해 보세요. 자격 증명, 권한, 경로 문제가 새벽 2시가 아니라 지금 드러나게 됩니다.

sudo systemctl daemon-reload
sudo systemctl enable --now agent-nightly.timer
sudo systemctl start agent-nightly.service
systemctl list-timers agent-nightly.timer
sudo journalctl \
  -u agent-nightly.service \
  -n 100 \
  --no-pager

Persistent=true 가 결정적인 차이입니다. 타이머는 놓친 캘린더 실행을 조용히 버리지 않고 기억합니다.

VPS에 실제로 필요한 것

이 부분이 처음 사양을 잡는 사람을 놀라게 합니다. 추론은 제공업체 API에서 이뤄지므로 CLI 자체는 가볍습니다. 하지만 에이전트는 여전히 빌드, 테스트, 패키지 매니저, 언어 서버, 컨테이너를 로컬에서 띄울 수 있으므로, 실제 하한선은 저장소의 작업 부하가 정합니다.

가벼운 예약 작업 하나라면 vCPU 1~2개와 RAM 2~4GB에 NVMe 스토리지를 출발점으로 삼으세요. 큰 저장소, 컴파일러, Docker 빌드, 테스트 스위트, 동시 실행은 훨씬 더 많이 필요할 수 있습니다. 사양을 끌어올리는 것은 API 뒤의 모델이 아니라, 에이전트가 실행할 가장 무거운 로컬 명령입니다. 이 VPS에서 이미 Docker 워크로드를 돌리고 있고 예산에 대한 더 완전한 그림을 원한다면, 빌드 서버 사양 산정과 보안 은 다른 무인 워크로드를 예로 같은 트레이드오프를 짚어 줍니다.

한 가지 더 계획해 둘 것이 있습니다. 무인 실행은 문제가 있든 없든 매일 밤 로그를 남깁니다. cron이 파일에 기록한다면 logrotate 를 추가하고, journald의 보존 한도가 기본값 그대로 VPS 디스크에 맞을 거라 넘겨짚지 말고 직접 확인하세요.

이 접근법 전체는 새벽 2시에 깨어 있고, 내 노트북이 무엇을 하든 계속 켜져 있는 호스트에 달려 있습니다. 그것이 바로 루트 권한이 있는 Linux VPS Linux VPS가 하는 일입니다. 아무것도 이 서버를 잠재우지 않고, 남의 cron 작업과 공유하지도 않습니다.

무인 실행이 잘못되지 않게 하기

잘 도는 예약 실행과 그렇지 않은 실행의 가장 큰 차이는, 도중에 사람이 질문에 답하지 않아도 끝날 만큼 작업 범위가 좁은가입니다. 야심 찬 프롬프트는 아무도 내려 줄 수 없는 결정을 기다리며 멈춥니다. 좁고 자족적인 작업은 깔끔하게 끝나고 종료됩니다.

권한 관련 두 플래그는 실행이 새벽 2시에 승인 요청 앞에서 멈추지 않도록 존재합니다. 하지만 아무 조건 없는 Bash 접근 권한은 좁은 안전장치가 아닙니다. 서비스 계정이 할 수 있는 거의 모든 일을 할 수 있습니다. 다음처럼 명령 단위로 규칙을 좁히고, Bash(git status *)와 짝을 지어 --permission-mode dontAsk서비스는 root가 아닌 전용 계정으로 실행하세요. 턴 수와 지출에는 각각의 상한이 있습니다. --max-turns 는 에이전트가 얼마나 오래 헤맬 수 있는지를 제한하고, --max-budget-usd 는 한 번의 실행이 API 호출에 쓸 수 있는 금액에 상한을 둡니다.

실전 팁: 다음 옵션으로 실행하고, --output-format json 각 호출의 total_cost_usd 필드를 로그로 남기세요. 예약 실행이 하룻밤에 실제로 얼마나 드는지 추적하고, 어느 한 번의 실행이 눈에 띄게 더 비쌀 때 알림을 받기에 가장 깔끔한 방법입니다. 배선하는 데 드는 5분은 충분히 값어치를 합니다. 추적하는 대상이 추상적인 무언가가 아니라 당신의 청구서니까요.

무인 실행의 비용 초과는 가상의 이야기가 아닙니다. Hacker News의 한 게시물에서한 사용자가 매일 도는 코딩 에이전트 워크플로에서 프롬프트 캐싱이 일부만 작동해 약 64억 7천만 입력 토큰이 캐시되지 않은 채 남았고, 그 결과 총 37,901.73달러의 AWS Bedrock 청구서를 받았다고 밝혔습니다. 이는 Claude Code 헤드리스 모드가 아니라 다른 스택에서 벌어진 일이지만, 비용 로깅과 실행당 강제 예산이 왜 예약 설계에 포함되어야 하는지 보여 줍니다.

실전 팁: Claude Code는 성공하면 종료 코드 0, 실패하면 0이 아닌 코드를 반환합니다. 종료 상태를 확인하는 래퍼 스크립트를 두면 실패했을 때 알림을 보낼 수 있어서, 문제가 있었던 밤이 사흘 뒤 우연히 들여다볼 때가 아니라 다음 날 아침에 드러납니다.

최소한 각 작업을 전용 브랜치나 일회용 worktree에서 실행하고, 병합 전에 사람의 검토를 거치게 하세요. 범위를 좁힌 자격 증명, 파일 시스템 격리, 서버 수준의 피해 반경 통제는 예약 가이드 끝에 붙인 문단 하나가 아니라 별도의 글로 다뤄야 할 더 큰 주제입니다.

예약을 그대로 두어도 안전하게 만드는 것은 안전장치입니다. 예약 자체는 안전장치가 아닙니다.

cron으로는 부족해지는 순간

타이머에 물린 프롬프트 하나라면 여기까지 다룬 것으로 충분합니다. 조건 분기와 재시도, Slack 알림이 붙은 세 단계짜리 체인은 다른 이야기입니다.

알아 둘 만한 선택지가 셋 있습니다. 각각 다른 이유로 한 단계 위입니다.

• Dagu 는 가장 가벼운 단계입니다. YAML로 정의하는 자족적인 작업, DAG 의존성, 재시도, 그리고 무엇이 돌았는지 볼 수 있는 웹 UI를 제공합니다.
• n8n 는 에이전트 실행이 워크플로 전체가 아니라 여러 연동과 알림 사이의 한 노드일 때 가장 잘 맞습니다.
• Kestra 는 셋 중 가장 무겁습니다. 데이터와 인프라 파이프라인을 오케스트레이션하기 위해 만들어졌고, 에이전트 예약이 목적 그 자체가 아니라 더 큰 파이프라인의 일부일 때 정답입니다.

매일 밤 프롬프트 하나만 돌리는 독자에게는 셋 다 과합니다. 필요 이상으로 무거운 구성을 권하기보다 이 사실을 분명히 말해 두는 편이 낫습니다. 언젠가 단계의 연쇄가 정말로 하나를 정당화한다면, Dagu, n8n, 그리고 Kestra 모두 원클릭 배포가 가능합니다. 설정 비용을 감수할 가치가 있는지 저울질하는 바로 그 순간에 이는 실질적인 편의입니다.

LangChain이나 CrewAI 같은 멀티 에이전트 오케스트레이션 프레임워크는 완전히 다른 주제입니다. 이미 존재하는 CLI를 예약 실행하는 것이 아니라, 에이전트 시스템 자체를 만드는 이야기니까요.

자주 묻는 질문

Claude Code는 활성 세션 없이 실행할 수 있나요?

가능합니다. 다음을 전달하면 -p 프롬프트가 비대화형 모드로 실행됩니다. Claude Code가 끝까지 수행하고 결과를 출력한 뒤 종료하며, 채팅 루프도 열어 둘 세션도 없습니다.

Claude Code에 이미 Routines가 있는데 VPS가 필요할까요?

항상 그렇지는 않습니다. Routines는 내 컴퓨터가 꺼져 있어도 Anthropic 클라우드에서 새로 클론한 사본으로 실행되지만, 내 컴퓨터에만 있는 파일에는 접근할 수 없고 최소 실행 간격이 1시간입니다. 직접 운영하는 VPS는 작업에 로컬 파일이 필요하거나, 임의의 간격이 필요하거나, 여러 벤더의 CLI에서 동일하게 동작하는 방식이 필요할 때 제값을 합니다.

예약 에이전트에는 cron과 systemd 타이머 중 무엇을 써야 하나요?

VPS가 유지보수로 재부팅될 일이 있다면 systemd 타이머입니다. Persistent=true 는 다운타임 동안 실행되었어야 할 작업을 시스템이 복귀하는 즉시 돌려 줍니다. cron에는 이에 상응하는 기능이 없습니다. 계속 켜져 있는 서버의 야간 작업이라면 cron으로 충분합니다.

VPS에서 예약 실행하는 AI 에이전트에는 RAM이 얼마나 필요한가요?

가벼운 예약 작업 하나라면 vCPU 1~2개와 RAM 2~4GB에서 시작한 뒤, 에이전트가 실행할 가장 무거운 로컬 명령에 맞춰 사양을 잡으세요. 빌드, 테스트, Docker, 큰 저장소, 동시 실행이 원격 모델 추론보다 훨씬 큰 변수입니다.

에이전트를 예약 실행하면 과금 방식이 달라지나요?

예약 실행이 별도의 과금 방식을 만들지는 않습니다. Claude Code의 -p 는 구독 자격 증명이나 API 키를 쓸 수 있지만, --bare 는 구독 로그인을 무시하므로 환경 변수 ANTHROPIC_API_KEY 를 환경에 두거나, apiKeyHelper 를 설정에 지정해야 합니다. Codex와 Gemini는 각자의 CLI에 설정해 둔 인증 방식을 따릅니다. 가격과 이용 약관은 빠르게 바뀌므로, 설정할 때 현재 제공업체 요금과 본인의 사용량 데이터를 확인하세요. API를 쓰는 Claude Code 실행이라면 total_cost_usd JSON 출력의 해당 필드를 로그로 남길 수도 있습니다.