프록시 403으로 막힌 에이전트가 미러로 우회하면서 버그 리포트까지 써놨습니다

에이전트가 샌드박스 이미지를 받으려다 프록시 뒤에서 403에 막힙니다. 에이전트는 미러로 전환해 작업을 이어가고, 화면에 한 줄을 띄웁니다. "Bug report drafted: Sandbox image pull fails behind proxy."

8월 26일 @ClaudeDevs 계정이 이 데모 이미지와 함께 클로드 코드의 피드백 초안 기능을 발표했습니다.

에이전트는 실패해도 작업을 이어 가고, 그 사이 보고서 초안까지 써 둡니다. 어떻게 동작하고 사람은 어디서 개입하는지 정리했습니다.

피드백 초안 기능은 어떻게 동작하나요?

앤트로픽은 공식 발표에서 한 문장으로 소개했습니다. "클로드 코드가 이제 피드백 초안을 대신 써줍니다."

클로드는 세 가지 상황에서 초안을 씁니다. 뭔가 실패했을 때, 클로드가 자기 실수를 알아챘을 때, 사용자가 뭔가 잘못됐다고 말했을 때. 그때마다 클로드가 그 순간의 상황을 스스로 보고서로 정리해요.

사람은 검토하고, 고치고, 승인해서 보내기만 합니다. 데모 화면에도 선택지는 딱 세 개예요. 리뷰, 전송, 무시.

앤트로픽은 후속 트윗에서, 원치 않으면 /config에서 끄거나 동작을 바꿀 수 있다고 덧붙였습니다. 자세한 동작은 공식 문서의 sendfeedback 도구 항목에서 확인할 수 있어요.

반응 숫자도 눈여겨볼 만합니다. @ClaudeDevs는 기능을 알린 첫 트윗으로 하루도 안 돼 조회 24만 5천을 넘겼지만, 설정 안내를 담은 후속 트윗에는 사람들이 그만큼 반응하지 않았어요. 사람들은 설정법보다 에이전트가 버그 리포트를 대신 쓰는 장면 그 자체에 반응한 거예요.

왜 버그 신고는 잘 안 오나요?

앤트로픽은 초안을 쓰는 시점을 영리하게 골랐습니다.

사용자는 뭐가 어떻게 잘못됐는지 다시 떠올리는 일부터 번거로워서 신고를 미룹니다. 어떤 명령을 쳤고, 뭐가 나왔고, 뭘 기대했는지. 실패를 겪고 한참 지나서 그걸 복원하려면 기억을 뒤져야 합니다.

앤트로픽은 그 재구성을 실패 현장에 있던 당사자, 즉 클로드 본인에게 맡겼습니다. 현장 검증인이 조서까지 쓰는 구조예요. 실패의 맥락을 가장 잘 아는 클로드가 실패 직후에 기록하니, 사람이 나중에 기억을 되살리다 정보를 빠뜨릴 걱정도 없습니다.

데모의 프록시 403 사례에서도 에이전트는 실패하고, 미러로 우회해 작업을 계속하고, 그 사이에 보고서 초안을 이미 만들어 둡니다.

눈여겨볼 건 초안을 만드는 시점입니다. 예전에는 사람에게 버그 리포트를 부탁하는 순간 이미 절반은 진 게임이었는데, 이제는 부탁할 필요가 없어요. 클로드가 초안을 먼저 써 두고, 사람은 예·아니오만 고르면 됩니다.

전송까지 자동화하면 안 되나요?

사용자들은 답글창에 뼈 있는 질문을 두 개 남겼습니다.

하나는 이 피드백 기능이 실행 뒤에서 조용히 도는 거냐는 통제 우려, 다른 하나는 사용자가 초안을 검토해 보낼 필요 없이 그냥 자동화해야 하는 것 아니냐는 정반대 방향의 요구예요. 같은 기능을 두고 사용자들이 정반대 방향으로 걱정하는 장면입니다.

저는 후자에 반대합니다. 이 설계가 맞아요. 피드백 전송은 내 세션의 정보가 밖으로 나가는 불가역 행동입니다.

기계가 초안을 끝까지 만들고, 사람이 발송 단추를 누르는 방식이에요. 요즘 에이전트 설계에서 표준처럼 쓰는 승인선입니다.

전자의 통제 우려에도 같은 답을 할 수 있습니다. 사람이 승인하지 않으면 클로드는 초안을 보내지 않고, 사용자가 /config에서 끌 수도 있으니까요. 자동화의 경계를 어디에 긋느냐는 질문에, 앤트로픽은 "작성까지, 전송 직전까지"라고 답한 셈이에요.

앤트로픽은 이 기능으로 무엇을 얻나요?

앤트로픽은 이 기능을 피드백 수집 파이프라인으로도 씁니다.

앤트로픽은 트위터에 흩어진 불만 대신 재현 가능한 보고서를 받기 시작합니다.

발표 트윗 답글만 봐도 이런 장치가 왜 필요한지 보입니다. 사용자들은 답글 대부분에 기능과 무관한 사용량 한도·리셋 불만을 적었거든요. 그나마 반응을 많이 받은 답글도 기능 얘기보다 50% 부스트를 상시화해달라는 요구였습니다.

사용자는 불만을 이렇게 아무 데나 쏟아낼 뿐, 재현 가능한 리포트로 보내지는 않습니다. 앤트로픽은 이 기능으로 흩어진 신호를 제품 안의 정돈된 채널로 끌어옵니다.

사용자를 거쳐 필터링된 실패 데이터를 가장 많이 모으는 회사가 제품을 가장 빨리 고칩니다. 모델 경쟁이 데이터 파이프라인 경쟁으로 번지는 이유고요.

남는 생각

저는 이 작은 기능을 사람 개입 지점의 이동으로 읽습니다.

지금까지 사람은 버그 리포트의 작성자였습니다. 이제는 승인자예요. 문서를 만드는 노동은 실패를 직접 겪은 에이전트가 하고, 사람은 그 문서가 나가도 되는지만 판단합니다. 사람은 판단이 가장 필요한 한 지점에서만 개입합니다.

쓰는 일은 기계가 맡고 책임은 사람이 지는 분업을 저는 코드 작성에서 먼저 봤습니다. 이제 버그 리포트라는 주변부에서도 보고, 앞으로는 작업 종류를 가리지 않고 보게 될 거예요.

에이전트는 이제 일하면서 자기 실패까지 기록하고 보고합니다. 제 파이프라인의 워커들도 같은 원리로 돕니다. 실패하면 게이트 로그를 남기고, 저는 그걸 보고 고쳐요.

사람은 자기 실수를 문서로 남기는 에이전트를 가장 빨리 믿게 됩니다.

---