새벽 3시반 페이블이 멈추자, '오르카 불신'과 'MD파일은 권고사항'론까지 터졌다

새벽 3시 27분, 방은 한동안 조용했다. 그 정적을 깬 건 짧은 질문 하나였다.

"Fable 모델 claude code에서 호출되시나요?"

1분 뒤 답이 붙었다.

"페이블이 안돼염"

곧이어 다른 참여자가 같은 증상을 확인해 주었고, 뒤이어 한 참여자가 장애로 결론지었다. 한창 밤 작업을 돌리던 참여자는 "지금 작업하고있던거 끊겼어요;;"라며 당혹감을 감추지 못했다. 클로드(Claude) 계열 모델을 이 방에서는 흔히 '페이블(Fable)'이라 부르는데, 그 페이블이 갑자기 반응을 멈춘 것이다.

장애를 계기로 터진 오케스트레이션 불신

단순한 접속 오류로 끝날 법한 소동은 곧 더 근본적인 대화로 번졌다. 방에서는 이번 기회에 '오르카' 방식의 오케스트레이션 구조 자체를 믿기 어렵다는 이야기가 나왔다. 한 참여자가 관련 해커뉴스 기사 링크를 공유했고, 뒤이어 다른 참여자가 md파일에 적힌 지침이 실제로 얼마나 지켜지는지에 회의적인 견해를 보탰다.

"md파일에 적혀있는건 정말 말그대로 권고사항정도로만 인지 됩니다, 예를들어서 여태까지 작성했던 md파일 무시하고 이거해 라고 하면 싹다 무시되는것처럼 언제든 무시될 수있어요."

에이전트 워크플로우를 md 파일에 규칙으로 박아두고 운영하는 이들이 많은 커뮤니티 특성상, 이 지적은 단순한 장애 넋두리를 넘어 '내가 짜둔 규칙이 실제로는 얼마나 신뢰할 수 있는가'라는 질문으로 옮겨간 셈이다.

우연의 일치일 확률과 저마다의 대응

장애 원인을 둘러싼 추측도 다양했다. 페이블 서비스의 종료 예정일이 하필 하루 뒤인 19일이라는 점을 들어, 그 날짜가 서버 설정 어딘가에 잘못 반영돼 오작동을 일으킨 것 아니냐는 가설도 나왔다. 확인된 사실은 아니지만, 시점의 공교로움이 대화를 더 키운 모양새다.

대응은 갈렸다. 일부는 오푸스(Opus) 4.8로 작업을 옮겨 급한 불을 껐고, 다른 일부는 이미 페이블로 기획 단계를 끝내둔 덕분에 큰 타격이 없었다며 안도했다. 장애가 시작된 지 20여 분이 지난 3시 49분, 다시 정상화된 것 같다는 확인이 올라오며 소동은 일단락됐다.

"다시 되는거 같습니다!"

왜 주목할 만한가

이날 새벽의 20분 남짓은 단순한 서버 장애 그 이상을 남겼다. 특정 모델 하나가 멈췄을 뿐인데, 대화는 곧바로 '내가 의존하는 오케스트레이션 구조를 얼마나 믿을 수 있는가', '내가 써둔 규칙 파일이 실제로 지켜지는가'라는 더 근본적인 질문으로 번졌다. 실제 원인이 무엇이었는지는 끝내 확인되지 않았지만, 장애 자체보다 그 여진으로 나온 신뢰 문제 제기가 이 커뮤니티의 체질을 잘 보여준다.

특히 md파일을 둘러싼 지적은 곱씹어볼 만하다. 이 방의 많은 참여자가 md파일에 코딩 규칙·작업 지침을 적어두고 에이전트가 그걸 그대로 따르리라 전제한 채 자동화를 짜는데, "언제든 무시될 수 있다"는 지적은 그 전제 자체를 흔든다. 장애가 나기 전까지는 누구도 이 문제를 굳이 꺼내지 않았지만, 페이블이 멈추자 눌러뒀던 의구심이 한꺼번에 터져 나온 셈이다.

도구 하나에만 기대지 않고 대안(코덱스)을 늘 준비해두거나, 중요한 작업은 장애 위험이 적은 시간에 미리 끝내두는 습관이 이번에도 실제로 방패 역할을 했다는 점도 눈여겨볼 대목이다. 서비스 종료일과 장애 시점이 하루 차이라는 우연이 음모론에 가까운 추측까지 낳았다는 사실은, 반대로 이 커뮤니티가 공지 하나하나를 얼마나 예민하게 주시하고 있는지를 보여주는 방증이기도 하다. 20분 남짓이면 복구되는 장애라도, 그 사이 터져 나온 불신은 쉽게 가라앉지 않는 법이다.