원격 Vault 요청 제한과 비용 판단 - Codex 대화

여러 세션의 Vault 사용에서 429가 발생한다는 이야기를 계기로, DanzzaN은 로그 확인과 요청 제한 상향을 요청했다. Codex는 현재 AWS 설정과 최근 호출량을 확인해 초당 10회·버스트 20회로 조정했다. 이후 묶음 처리의 효과와 비용 증가 여부를 검토했으며, DanzzaN이 이번 변경과 의사결정의 증류를 요청했다. 현재 운영값은 원격 Vault 운영 전환에서 관리하고, 이 노트는 결정 당시의 근거와 해석 범위를 보존한다.

병행 사용을 위한 요청 제한 조정

기존 설정은 API Gateway의 $default 단계에서 초당 1회·버스트 2회였다. 같은 경로를 사용하는 여러 세션의 요청이 이 한도를 공유하므로, 각 세션이 독립적으로 호출 간격을 지키는 것만으로 충돌을 피할 수 있다고 보지 않았다.

2026-09-11 09:31:55부터 9월 12일 09:31:55 KST까지 API 요청은 978건, 4xx는 328건, 5xx는 0건이었다. Lambda 호출은 847건, 함수 오류와 동시 실행 제한 거절은 각각 0건이었고, 평균 실행 시간은 약 606 ms, 최대 동시 실행은 7개였다. 이를 근거로 세션들이 잠깐 겹치는 요청을 수용할 여유를 늘리기로 했다. 10회/초·버스트 20회는 Codex가 이 관측량을 바탕으로 선택해 적용한 값이며 부하 시험으로 산출한 최적값은 아니다.

설정 상향은 2026-09-12 09:36:04 KST에 반영됐고 독립 재조회로 확인했다. AWS 계정 자체의 할당량이나 상시 실행 용량을 구매한 변경은 아니다.

묶음의 단위와 관측 시점

최다 요청인 분당 78건은 9월 12일 09:05에 기록됐다. 이는 원격 Vault 묶음 저장 계약의 9월 10일 도입 이후이므로, 묶음 저장 도입 전의 부하를 나타내는 수치로 해석하지 않는다. 이 한 분의 평균은 약 1.3회/초이며 순간 최대 요청률까지 보여주지는 않는다.

한 사용자 작업을 한 GitHub commit으로 확정하는 것은 검토와 이력의 단위를 묶는 것이다. 검색·읽기·초안 저장·검토·확정은 각각 API 요청으로 집계된다. 여러 문서를 한 읽기나 stage 호출에 넣으면 해당 호출 수를 줄일 수 있지만, commit 수의 감소율을 HTTP 호출이나 요금의 감소율로 그대로 옮기지는 않는다.

비용 판단

한도 상향은 허용할 처리량을 바꾸며, 사용량 기반 API Gateway와 Lambda의 비용은 실제 요청·실행 시간·전송량 등에 따라 발생한다. 거절되던 요청이 더 처리되면 실행량은 증가할 수 있으나 한도를 10배로 올렸다는 사실만으로 실제 비용이 10배가 되는 것은 아니다.

9월 12일 AWS 공개 서울 리전 요금표를 확인하고 위 하루를 30일로 단순 환산했다. HTTP API는 100만 과금 요청당 1.23, Lambda 요청은 100만 건당 0.20, 계산에는 x86 일반 실행 첫 구간의 GB-second당 $0.0000166667을 사용했다. 메모리는 256 MiB로 계산했다.

가정API Gateway와 Lambda의 월 추정 합계
관측한 하루의 요청량·실행량 유지약 $0.11
실제 요청량·실행량도 각각 10배약 $1.05

첫 행은 HTTP 요청 29,340건, Lambda 실행 25,410건과 약 3,849 GB-seconds의 합산 약 $0.1053을 반올림한 값이다. HTTP 요청당 512 KiB 이하, 관측된 평균 실행 시간 유지, 무료 혜택 적용 전을 가정했다. 초기화 등 지표 밖의 과금 실행 시간, 저장소·Secrets Manager·로그·데이터 전송·세금은 포함하지 않았다. x86 요금 가정의 추정이며 실제 청구액이나 Vault 전체 운영비, 비용 상한을 뜻하지 않는다. 현재 관측량에서 이번 한도 상향의 호출·실행 비용 부담은 작다고 판단했다.

검증으로 확인한 범위

4xx에는 인증 거절 등이 포함된다. API 요청과 Lambda 호출 수의 차이도 429 건수로 확정할 수 없다. API Gateway 접근 로그가 꺼져 있어 과거 429를 건별로 확인하지 못했고, 조사한 Lambda 로그와 로컬 Codex의 Vault 관련 도구 출력에서도 이를 확증하는 표본을 찾지 못했다. 로그에서 ERROR로 분류된 표본은 YAML 키 변환 경고였으며 함수 실패와 구분했다.

변경 전후 각각 인증 없는 동시 요청 6건은 모두 401이었다. 이는 인증 단계까지 전달된 결과이며 Vault 읽기 성공이 아니다. 변경 전 인증된 읽기 4건은 성공했다. 변경 후 첫 읽기 검증은 3건 성공·1건 MCP 내부 오류(-32603)였고, 같은 입력을 다시 병렬 호출한 4건은 모두 성공했다. 그 내부 오류의 원인과 장기적인 429 해소는 미확정이다.

따라서 이번에 확정한 결과는 제한값 상향과 재조회, 해당 읽기 재시험의 성공이다. 과거 오류의 근본 원인이나 재발 방지 전체를 입증한 것으로 확대하지 않는다.

추가 확인에서 CloudTrail의 해당 UpdateStage 요청은 요청 제한값 조정만 담고 있었고, Lambda 코드 해시·설정 버전·마지막 수정 시각은 변경 전과 같았다. 증류 중 Codex에 묶음 도구가 한때 노출되지 않아 Codex가 재연결을 요청했으나, 이후 같은 대화에서 정본 읽기와 묶음 목록 조회가 성공했다. 재연결 필요성을 단정한 안내는 근거가 부족했다. 도구 노출 변화의 원인과 요청 제한 변경의 인과관계는 확인하지 못했다.

원천

연결