에러 없이 실패하는 배포가 있다 — 운영·거버넌스 17문답

에이전트가 돌기 시작하면 질문의 성격이 바뀐다. "어떻게 만드나"에서 "무슨 일이 있었는지 어떻게 아나"로 옮겨 간다. 그리고 이 구간의 질문들은 대체로 한 번 겪고 나서 떠오른다 — 청구서를 보고, 로그가 없다는 걸 알고, 조용히 멈춰 있던 자동화를 며칠 뒤에 발견하고 나서다.

이 글은 운영·권한·비용·장애에 걸린 열일곱 문항에 결론부터 답한다. 답의 상당수가 "미리 정해 둔다"로 수렴한다 — 롤백 조건도, 한도도, 합격선도 사고가 난 다음에 정하면 늦거나 자기 합리화가 된다.

도입 순서와 규약 파일은 도입과 표준화 Q&A, 확장 메커니즘은 확장 메커니즘 Q&A, 에이전트 설계와 멀티에이전트는 에이전트 설계 Q&A에 있다. 수치마다 그 값의 출처 성격을 먼저 밝히는 규칙은 도입과 표준화 Q&A의 마지막 문항에 있다.

핵심 판정 기준 정리

운영 구간에서 반복해 등장하는 갈림길들이다. 값이 아니라 무엇으로 가르는가가 요점이다. 아래 분류는 이 글이 열일곱 문항을 배열하며 정리한 것이다.

Q. AI가 만든 코드를 무엇으로 신뢰하나

신뢰하지 않는다. 사전과 사후 두 시점에 게이트를 건다.

규칙 계층으로 나누는 관점은 도입과 표준화 Q&A에서 다뤘고, 여기서는 시점 축이다. 두 축은 직교한다 — 같은 강제 수단이라도 실행 전에 거는지 후에 거는지에 따라 잡히는 것이 다르다.

오른쪽 열이 둘 다 필요한 이유다. 원 자료의 배포 전 검증은 자동 실행되는 항목 묶음이고, 저장 시 자동 포맷은 사람이 라인 단위로 읽지 않아도 형식 편차를 없앤다.

세 수단의 강제력 차이는 Rules·Hooks·Skills 3계층, 선언형 차단은 deny가 항상 이긴다, 배포 전 점검 항목 전체는 재현 없이 가설 없다에 있다.

Q. 에이전트 권한은 무엇을 기준으로 좁히나

기본 거부 + 필요한 것만 허용이다. 넓게 열어 두고 사고가 난 뒤에 좁히는 순서가 아니다.

상한을 정하는 것은 신뢰가 아니라 복구 가능성이다. 되돌릴 지점이 촘촘할수록 넓은 권한을 줄 수 있고, 그래서 커밋 습관이 사실상 자동화 정책이 된다. 그 위에 역할별 등급을 얹는다.

정의서 쪽에서도 같은 방향이 적용된다 — 검색이 필요 없는 에이전트에서 웹 검색을 빼고, 파일 탐색이 불필요하면 그것도 뺀다. 기본값으로 전체 권한을 주지 않는다. 권한 계층 사이에 충돌이 나면 상위의 거부가 하위의 허용을 무시한다.

평가 순서와 설정 계층은 deny가 항상 이긴다, 4단 등급표와 등급 운영은 잠재 경로는 개수의 제곱으로 는다, 복구 가능성 원칙은 되돌릴 수 있어야 권한을 넓힌다, 도구 변형의 실물 분포는 30개 에이전트 카탈로그에 있다.

Q. 시크릿은 어떻게 관리하나

단일 원천에 두고, 나가는 경로를 전부 막는다. 나가는 경로가 네 갈래다.

네 번째가 자주 빠진다. 값이 맞는지 보려고 한 번 찍어 보는 동작인데, 그 출력이 그대로 로그와 컨텍스트에 남는다. 원 자료가 위험 명령 차단 규칙에 시크릿 평문 출력을 넣어 둔 이유다.

시크릿 스캔이 배포 절차의 어느 단계인지는 재현 없이 가설 없다, 데이터 계층의 경계 설정은 자물쇠를 먼저 달고 출입증을 발급한다에 있다.

Q. 사용자 입력을 프롬프트에 넣을 때 무엇을 막나

구조와 지시 두 겹으로 막는다.

첫 겹은 입력이 들어가는 자리를 태그로 구획하는 것이고, 둘째 겹은 그 안을 데이터로만 읽으라고 시스템 쪽에 못 박는 것이다.

한 겹만으로 왜 부족한지와 AI 기능을 붙인 뒤에 나타나는 공격면 전반은 자물쇠를 먼저 달고 출입증을 발급한다에 있다.

Q. 관측성은 무엇으로 확보하나

첫날부터 도구 호출 전량을 구조화 로그로 남긴다. 나중에 붙이면 정작 필요한 시점의 기록이 없다.

핵심은 한 요청이 여러 에이전트를 거쳐도 하나로 묶이는 식별자다. 그것이 없으면 로그가 남아 있어도 "어디서 틀어졌나"가 나오지 않는다.

로그 형식과 필드 구성, 보존 정책, 그리고 로그가 없을 때 복구 시간이 얼마나 벌어지는지와 확장 구간별 운영은 잠재 경로는 개수의 제곱으로 는다, 트리거와 체크인 사이클은 JD 5필드에서 하루가 도는 데까지, 진단 순서는 3계층으로 좁히고 4단으로 분해한다에 있다.

Q. 장애가 나면 어떤 순서로 대응하나

먼저 되돌리고, 그다음에 좁힌다. 고치는 것보다 되돌리는 게 빠르다.

되돌릴지 말지를 그 자리에서 판단하지 않는 것이 핵심이다. 즉시 롤백 조건을 사전에 합의해 두고, 해당하면 원인 분석 전에 되돌린다. 원 자료의 목표는 5분 내 롤백이다.

되돌린 다음이 진단이다. 외부 의존 → 자원 한도 → 내부 설정 순으로 좁히고, 좁힌 뒤에는 증상-원인-해결-예방 네 단으로 분해한다. 예방 칸이 비어 있으면 대응이 끝난 것이 아니다 — 원인을 다섯 번 되물어 규칙·게이트의 부재까지 내려가고, 그 결론을 규칙 문서에 반영해야 같은 장애가 닫힌다. 사후에는 인시던트 리포트를 남긴다.

세 계층이 각각 무엇을 보고 왜 그 순서인지, 현장 장애 사례는 3계층으로 좁히고 4단으로 분해한다, 롤백 절차와 배포 후 점검은 재현 없이 가설 없다에 있다.

Q. 디버깅은 어떤 절차로 시키나

원 자료가 절대 원칙으로 둔 한 줄이 있다 — "재현 없이 가설 없다. 가설 없이 수정 없다. 수정 후 회귀 테스트 없이 완료 없다."

에이전트에게 디버깅을 맡길 때 가장 흔한 실패는 재현을 건너뛰고 바로 고치는 것이다. 그러면 무엇이 고쳐졌는지 확인할 방법이 없고, 고쳐졌는지조차 모른 채 다음 수정으로 넘어간다. 그래서 절차는 재현 → 가설 → 검증 → 회귀방지 네 단계로 고정한다. 가설 단계에서 한 번에 한 변수만 바꾸기로 정하고, 검증 단계에서 최소 재현 케이스를 줄일 수 있는 데까지 줄인다.

그리고 시도 횟수를 센다. 같은 방향으로 몇 번 실패하면 코드가 아니라 구조를 의심하도록 상한을 정해 둔다.

최소 재현 케이스의 목표 크기와 방향 전환 임계 횟수, 4 Phase의 단계별 점검 항목과 함정 카탈로그는 재현 없이 가설 없다에 있다.

Q. 가장 흔한 실패는 무엇인가

조용히 실패하는 자동화다. 개발 환경에서는 되는데 스케줄러에서만 깨진다.

원인은 대개 개발 환경과 스케줄러 환경의 차이다. 파일은 있는데 없다고 나오고, 에러는 아무도 보지 않는 곳으로 나간다.

그래서 예방책이 두 개다 — 스케줄 등록 시 절대 경로와 로그 리다이렉션을 필수로 하고, 실행 로그를 사람이 한 번 열어 본다. 두 번째가 없으면 첫 번째를 지켰는지도 알 수 없다.

실제 장애 사례와 그 실패가 발견되기까지 걸린 기간, 확인 시한을 포함한 예방 절차, 같은 틀의 다른 분석은 3계층으로 좁히고 4단으로 분해한다에 있다.

Q. 잘못된 변경이 배포되는 것을 무엇이 막나

커밋은 허용하되 푸시는 거부하고, 원격 쪽 브랜치 보호로 한 겹 더 건다.

승인 게이트를 사람의 주의력이 아니라 구조로 강제하는 것이다. 다만 전략이 문제 유형에 따라 갈린다는 점을 원 자료가 짚는다 — 미완성 코드가 나가는 것이 문제면 푸시 쪽을 막고, 검토를 거치지 않은 커밋 자체가 문제면 커밋 쪽을 막는다.

그리고 통제 위치가 중요하다. 커밋 훅은 우회 옵션으로 무력화될 수 있으므로 근본 통제는 권한 계층에서 한다.

세 번째가 문서 쪽이다. "배포 준비해줘" 같은 지시가 푸시까지 자의적으로 해석되는 것을 막으려면 "배포 준비"의 정의를 규칙 문서에 적어야 한다 — 어디까지가 준비이고 어디부터가 배포인지를 문장으로 고정한다.

두 전략의 실제 장애 사례와 「배포 준비」 정의를 규칙 문서에 적는 처방은 3계층으로 좁히고 4단으로 분해한다, 거부 규칙의 문법과 평가 순서는 deny가 항상 이긴다, 배포 단계별 점검은 재현 없이 가설 없다에 있다.

Q. 배포 성공은 무엇으로 판정하나

에러율만으로는 안 된다. 24시간 뒤 핵심 지표를 비교한다.

에러 없이 실패하는 배포가 존재하기 때문이다. 예외도 안 나고 응답도 정상인데 전환이 떨어지거나 처리량이 줄어드는 경우가 있고, 이건 에러 로그를 아무리 봐도 안 나온다. 원 자료의 기준은 전일 대비 20% 이상 하락 시 롤백 검토다.

배포 직후에는 별도로 핵심 경로가 살아 있는지 짧게 확인하는 최소 검증을 돌린다. 즉 판정은 두 시점이다 — 직후의 생존 확인과 24시간 뒤의 지표 비교다.

배포 전·중·후·롤백 각 섹션의 점검 항목과 주기는 재현 없이 가설 없다에 있다.

Q. 무인 파이프라인에서 인증은 어떻게 처리하나

키 기반 인증으로 바꾼다. 사람이 매번 비밀번호를 넣어야 하면 무인 실행이 성립하지 않는다.

구조는 단순하다. 키 쌍을 만들어 공개키만 원격 서비스에 등록하고, 개인키는 로컬에 두고 인증 에이전트에 올린다. 서버가 서명을 검증하므로 비밀번호 입력 없이 인증이 끝난다.

경계가 한 곳이다. 등록하고 공유하는 것은 공개키뿐이고, 개인키는 어떤 경우에도 외부로 나가면 안 된다. 확장자가 붙은 쪽이 공개키다. 둘을 혼동하면 사고가 나고, 이건 되돌릴 수 없는 종류의 사고다. 재부팅으로 키가 인증 에이전트에서 내려가면 자동화가 조용히 멈추므로 세션 간 유지 옵션도 함께 본다.

설치·인증 구간과 자격증명 경계는 자율성 3세대, 스케줄 실행의 트리거 설계는 JD 5필드에서 하루가 도는 데까지에 있다.

Q. 비용 폭주는 어디서 끊나

청구서가 아니라 사전 한도에서 끊는다. 그리고 1순위 원인은 사용량 증가가 아니라 무한 루프다.

루프는 요금이 아니라 사고에 가깝다. 종료 훅이 파일 쓰기를 유발하고 그 쓰기가 다시 훅을 부르는 식으로 연쇄하면 분당 수천 토큰이 나간다. 그래서 예방이 코드 쪽에 있다 — 훅 첫 줄의 재진입 플래그 확인, 타임아웃, 그리고 "동일 에러 3회면 중단" 같은 반복 상한이다.

그 위에 세 겹의 한도를 얹는다.

구조적 절감은 두 가지다. 작업 난이도별로 모델을 나누는 것과 반복 입력을 캐싱하는 것이다. 히트율이 오르면 같은 작업량에서도 비용이 눈에 띄게 갈린다.

모델 배율과 히트율별 비용 시나리오, 비용을 축별로 나누는 방법은 잠재 경로는 개수의 제곱으로 는다, 자동화 대상 선정 단계의 회수 계산은 합격선 5축과 자동화 대상 선정, 인증 경로가 과금 경로가 되는 구조는 자율성 3세대, 애플리케이션 층 방어선은 자물쇠를 먼저 달고 출입증을 발급한다에 있다.

Q. 운영 루틴은 어떤 주기로 도나

하루 사이클은 스케줄러에 고정하고, 점검 루틴은 사람이 따로 돈다. 둘은 다른 것이다.

하루 사이클은 자동이다. 아침 체크인이 미완료 작업을 요약하고, 저녁 체크아웃이 세션을 정리해 다음 날 준비를 남긴다. 주간 리포트도 같은 방식으로 스케줄에 건다.

점검 쪽은 사람이 시간을 떼어 둔다. 원 자료가 일·주·월 세 주기로 분 단위까지 배분해 둔 루틴이 따로 있다. 앞서 나온 조용히 실패한 자동화가 정확히 이 루틴의 부재로 생긴 일이다.

주기별 소요 시간과 점검 항목은 3계층으로 좁히고 4단으로 분해한다, 체크인·체크아웃 트리거 구성은 JD 5필드에서 하루가 도는 데까지에 있다.

Q. 도입 성공은 무엇으로 판정하나

착수 전에 합격선을 숫자로 고정한다. 사후에 정하면 자기 합리화가 된다.

축은 다섯이고 각각 등급 기준을 갖는다. 그중 둘의 정의가 직관과 다르다 — 확장성은 개수가 아니라 증설 소요 시간이고, 문서화는 제3자 실행 성공 여부다.

확장성을 개수로 재면 설계 품질이 잡히지 않는다. 하나 더 붙이는 데 전면 재설계가 필요하면 그것은 설계 실패다. 문서화도 마찬가지로 자기 검증은 기준이 되지 못한다.

다섯 축의 이름과 각 축의 등급 기준 전체는 합격선 5축과 자동화 대상 선정에 있다.

Q. 효과는 무엇으로 보고하나

Before/After 실측 → 월 환산 → 금액 환산 → ROI 백분율이다. 시간 절감만 세지 않는다.

보고에서 자주 빠지는 것이 시간 외 지표다. 그리고 원 자료가 강조하는 것은 정밀도가 아니라 측정 여부다.

효과의 정의를 어디에 두는지도 갈린다. 원 자료의 한 갈래는 이것을 편의가 아니라 편차 제거로 본다 — 빨라졌다가 아니라 누가 해도 같은 품질이 나온다는 쪽이다. 이 정의를 쓰면 산출물 일관성과 신규 인원의 학습 비용이 지표가 된다.

앞 문항의 5축이 착수 전 합격선이라면 이 문항은 착수 후 산출 지표다. 시점이 달라 둘 다 필요하다.

시간 외에 무엇을 지표로 세는지와 증명 3종은 잠재 경로는 개수의 제곱으로 는다, 측정과 조직 지표의 간극은 개인은 빨라졌는데 조직 지표는 안 움직인다에 있다.

Q. 리뷰와 피드백은 어떻게 요청하나

범위를 좁히고 자기 판단 근거를 먼저 밝힌 뒤 두 선택지를 놓고 묻는다.

범위가 없는 질문은 답을 산만하게 만들거나 예/아니오만 유도한다.

나쁜 질문과 좋은 질문을 세 쌍으로 대비한 표와 그 원문 맥락은 잠재 경로는 개수의 제곱으로 는다에 있다.

Q. 퍼미션 모드는 정확히 몇 개인가

개수는 버전에 묶인다. 키 이름과 개수가 릴리스에 따라 달라진다.

그래서 실무에서 필요한 것은 이름의 개수가 아니라 "이 프로젝트를 전면 허용과 전면 차단 사이 어디에 둘 것인가" 라는 판단이다.

같은 이유로 기본 모드는 값 하나로 고정하기보다 거부·허용 규칙과 함께 설계한다 — 평가 순서상 기본 모드는 마지막에 적용되므로, 거부 규칙이 있으면 기본 모드가 무엇이든 그쪽이 먼저 이긴다.

그 스펙트럼 위의 모드 구분과 기본 모드·거부·허용의 평가 순서는 deny가 항상 이긴다에 있다.

용어 정리

여기까지가 "무엇을 남기고 어디서 끊나"의 판단이다. 이 시리즈의 앞 세 편은 도입과 표준화 · 확장 메커니즘 · 에이전트 설계에 있다.