주간 요약이 실패한 이유

월요일 스탠드업 미팅에 앉아 있는데 팀원이 주간 요약본이 이상하게 공백인 이유를 묻습니다. 봇은 제시간에 게시되었고, 제목은 온전하며, 본문에는 기록할 만한 승리가 없다고 주장합니다. 당신은 페이지가 잘못되었다는 것을 알고 있습니다. 왜냐하면 목요일의 풀 리퀘스트(pull request)들이 여전히 저장소 히스토리(repository history)에 남아있기 때문입니다. 채널은 사람들이 페이지에 맞추어 한 주를 다시 쓰고 있다는 의미로 특정한 방식으로 조용해집니다.

당신은 캘린더를 열기 전에 작업 로그(job log)를 엽니다. 왜냐하면 녹색 체크 표시가 진정한 보고서와 같지 않기 때문입니다. 워크플로우(workflow)는 깨끗하게 완료되었고, 이것이 아무도 당신에게 전화를 걸지 않았고 공백의 한 주가 스탠드업까지 살아남은 이유입니다. 자세히 읽어보면 모델 호출(model call)이 결제(billing)에서 실패했고, 캐치 블록(catch block)이 이를 삼켜버렸으며, 렌더러(renderer)가 당신에게 정중한 대체 문구(fallback)를 전송했습니다. 접근 가능해야 할 프로세스가 노트북의 터미널에 있었고, 그 노트북은 18:40에 잠들었습니다.

타임라인은 슬라이드 없이 다시 이야기할 만큼 짧으며, 바로 이 짧음이 놓친 이유 중 일부입니다. 17:02에 예약된 작업(scheduled job)이 노트북 터널을 통해 시작되어 일주일 내내 사용하던 유료 모델 엔드포인트(paid model endpoint)를 호출했습니다. 17:02에 그 엔드포인트가 키(key)를 거부했고, 당신의 클라이언트(client)는 이 거부를 빈 결과로 처리했으며, 렌더러는 '조용한 주' 문구를 작성했습니다. 18:40에 덮개가 닫히고 터널이 끊겼으며, 월요일은 놓친 게시물 대신 잘못된 기록을 물려받았습니다.

세 가지 기여 요인이 서비스 중단(outage)을 팀이 제품의 진실로 착각할 수 있는 무언가로 만들었습니다. 첫째, 언어 생성과 호스트 도달 가능성 모두가 필요했지만, 코드는 각각을 선택 사항으로 처리했습니다. 둘째, 대체 문구는 정중하게 작성되어 있어서 서비스 중단과 실제로 조용한 한 주가 같은 결과를 냈습니다. 셋째, 호스트는 절전 정책(sleep policy)이 있는 기계였는데, 이는 섬세한 스케치북이자 약속을 지키기에는 좋지 않은 장소였습니다.

사람들은 월요일 아침에 깨끗한 제목과 빈 본문으로 예상되는 행동을 했습니다. 스탠드업 미팅은 공백의 주를 일종의 사회적 사실로 취급했고, 대화는 일어나지 않은 느린 한 주를 설명하는 쪽으로 흘러갔습니다. 이것이 바로 실패 오픈(failed-open) 보고서가 비싼 이유입니다. 왜냐하면 장애(outage)가 로그를 읽기 전에 인간의 기억을 편집하기 때문입니다. 만약 레드 잡(red job)이었다면 더 저렴했을 텐데, 왜냐하면 레드 잡은 팀에 대한 논쟁이 아니라 봇에 대한 논쟁으로 시작하기 때문입니다.

할당량(quota)을 늘리는 것은 이 월요일의 실패를 나중 월요일로 옮길 뿐일 것입니다. 더 긴 슬립 타이머도 같은 방식으로 실패합니다. 왜냐하면 통근, 배터리 방전, 또는 시스템 업데이트가 여전히 터널을 끊을 수 있기 때문입니다. 채널이 어떤 종속성(dependency)이 실패했는지 말해주어야 하고, 스케줄러는 당신의 슬립 정책을 공유하지 않는 곳에 존재해야 합니다. 이 두 가지가 모두 참일 때까지, 더 큰 허용량은 같은 정중한 문장으로 나중 깜짝 놀랄 일만을 사들일 뿐입니다.

이 설정을 화재 경보기가 방 안에서만 작동하는 램프를 통해 연결된 것으로 상상해 보세요. 램프가 어두워지면, 불이 없었는지 아니면 경비원이 집에 갔는지를 알 수 없습니다. 따라서 첫 번째 수리는 두 종속성 중 어느 하나를 저렴하게 만들려고 하기 전에 실패를 크게(loud) 만드는 것입니다. 당신은 별도의 호스트 및 모델 프로브(probe)를 원하며, 그 두 결과가 채널에서 분리되어 유지되기를 바랍니다.

아래 스케치는 실행되지 않은 예시이며, 실제로 제어하는 엔드포인트에만 맞게 조정해야 합니다. 이는 벤더 SDK를 호출하지 않으며, 할당량(quota), 모델 이름, 리전, 또는 하드웨어 모양을 가정하지 않습니다. 두 URL을 교체하고, 종료 코드(exit code)를 안정적으로 유지하며, 어떤 시간 초과도 빈 주가 아니라 다운된 종속성으로 취급해야 합니다. 만약 한 문장으로 종료 코드를 설명할 수 없다면, 그 코드가 잡을 녹색으로 만들지 마십시오.

# 실행되지 않은 예시: 호스트 상태와 모델 상태를 분리합니다.
# 두 URL 모두 제어하는 엔드포인트로 교체하십시오. 토큰은 절대 에코하지 마십시오.
set -u
...

그런 다음 렌더러를 변경하여 성공하지 못한 경우(non-success)가 빈 주에 할당된 문장이 되는 것을 막습니다. 다운된 호스트는 다이제스트가 호스트 문제로 건너뛰어졌다고 말해야 하며, 그 외의 내용은 언급해서는 안 됩니다. 거부된 모델은 모델이 거부했기 때문에 다이제스트가 건너뛰어졌다고 말하며, 온콜(on-call) 담당자가 페이지를 라우팅할 수 있도록 다른 문장을 사용해야 합니다. 아이템을 반환하지 않는 성공적인 호출만이 '조용한 주(quiet-week)' 문장을 사용해야 하며, 그 문장에는 적용한 필터 이름이 명시되어야 합니다.

# 실행되지 않은 예제: 렌더러와 로컬 자체 점검. 라이브 벤더를 대상으로 실행하지 않음.
def render_digest(status: str, items: list[str]) -> str:
    if status == "host_down":
...

작은 테스트 계획을 유지하여 누군가 렌더러를 리팩토링할 때 그 문구가 망가지지 않도록 합니다. 호스트 프로세스를 중단하고, 프로브(probe)를 실행한 다음, 드라이-런 채널에서 종료 코드 2와 함께 '호스트 다운' 문장이 출력되는 것을 예상합니다. 모델 프로브를 잘못된 토큰에 지정하고, 종료 코드 제로가 아닌 실패 폐쇄(failing closed)와 함께 종료 코드 3이 나오는 것을 예상합니다. 렌더러를 render_digest.py로 저장하고, python3 render_digest.py를 실행한 다음, 'WORDING_OK'가 출력될 때만 문구 변경을 수용합니다.

로컬 검사가 통과한 후에는 노트북 덮개를 닫고 슬립 정책이 터널을 종료할 때까지 기다립니다. 다음 예약된 실행은 호스트 프로브에서 실패해야 하며, '조용한 주' 문장을 게시해서는 안 됩니다. 만약 스케줄러가 여전히 그 노트북에 살아 있다면, 문제를 해결한 것이 아니라 재현했을 뿐입니다. 이 네 가지 관찰 내용이 다음 온콜 담당자가 볼 수 있는 런북(runbook)에 기록된 후에만 스케줄러를 이동시키십시오.

영구적인 해결책은 슬립이 허용되는 장치에 예약된 약속을 주차하는 것을 중단하는 것입니다. 이 간극을 메우는 두 가지 운영자 제공 MonkeyCode 옵션이 있습니다: 무료 모델 액세스, 그리고 호스트를 위한 무료 서버입니다. 공개 고지: 본 문서는 MonkeyCode의 제품 아웃리치(product outreach)의 일환으로 작성되었습니다. 이 초안은 토큰 할당량, 기간, 모델 이름 또는 하드웨어 형태를 검증된 사실로 취급하지 않습니다.

프로브(probes)를 통과한 후에도 희귀하고 중요한 요약은 유료 프론티어 모델(frontier model)로 보낼 수 있습니다. 공백의 월요일에서 얻은 교훈은 쇼핑 비교보다 좁습니다. 왜냐하면 도달 가능성(reachability)과 생성(generation)이 개별적으로 실패했기 때문입니다. 정중한 대체 방안은 결과처럼 보이고 사람들이 신뢰하는 채널에 도착할 때 두 번째 사고가 됩니다. 녹색 체크 표시가 여전히 어느 한 가지 실패를 숨길 수 있다면, 어떤 호스트를 선택하든 실행 계획(runbook)은 완성되지 않은 것입니다.

이러한 접근 방식은 요약본이 고객 데이터, 비밀 정보 또는 제3자 로그에 붙여넣지 않을 텍스트를 볼 수 있을 때는 적합하지 않습니다. 또한 계약상의 가동 시간 약속(contractual uptime promise), 고정된 할당량(fixed quota) 또는 귀하의 통제 하에서 변경되어서는 안 되는 명명된 모델이 필요할 때도 적합하지 않습니다. 무료 액세스는 이동하거나, 속도를 제한하거나, 사라질 수 있으며, 주말 봇은 꾸며낸 조용한 한 주를 보내기보다는 명시적인 건너뛰기로 저하되어야 합니다. 만약 채널에서 실패 원인을 한 문장으로 설명할 수 없다면, 요약을 자동화할 준비가 된 것이 아닙니다.

다른 요약본을 자동화하기 전에, 스텁(stub)에 대해 네 가지 점검을 실행하고 각 실패가 어떤 문장을 생성해야 하는지 적어보십시오. 그 메모가 지속 가능한 아티팩트이며, 외부 호스트를 절대 채택하지 않더라도 유용하게 유지됩니다. 실제로 필요한 소수의 요약본은 유료 경로로 남겨두고, 저렴한 경로는 동일한 프로브 뒤에 두십시오. 나중에 노트북이 아닌 호스트를 원한다면, 현재 프로젝트 문서를 시작점으로 삼아 다른 녹색 체크 표시를 신뢰하기 전에 프로브를 연결하십시오.