Fronmpt← 모든 글
블로그5분 읽기

실패한 에이전트가 버그 리포트를 스스로 쓰고, 사람은 승인 버튼만 누릅니다

클로드 코드가 실패 직후 버그 리포트 초안을 대신 쓰는 기능을 정리했습니다. 프록시 403으로 막힌 데모에서 에이전트는 미러로 우회하며 보고서를 먼저 써두고, 사람에게 남는 건 리뷰·전송·무시 세 선택지입니다.

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

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

실패가 작업을 멈추지도 않고, 보고 없이 증발하지도 않는 장면이에요. 이 장면이 왜 화제가 됐는지 뜯어보겠습니다.

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

공식 발표의 문장은 단순합니다. "클로드 코드가 이제 피드백 초안을 대신 써줍니다."

발동 조건은 셋이에요. 뭔가 실패했을 때, 클로드가 자기 실수를 알아챘을 때, 사용자가 뭔가 잘못됐다고 말했을 때. 그 순간의 상황을 클로드가 스스로 보고서로 정리합니다.

사람이 하는 일은 검토하고, 고치고, 승인해서 보내는 것까지입니다. 데모 화면의 선택지도 딱 세 개예요. 리뷰, 전송, 무시.

원치 않으면 /config에서 끄거나 동작을 바꿀 수 있다고 후속 트윗이 덧붙였고, 자세한 동작은 공식 문서의 sendfeedback 도구 항목으로 연결됩니다.

숫자의 낙차도 눈에 띕니다. 기능을 알린 첫 트윗이 하루도 안 돼 조회 24만 5천을 넘기는 동안, 설정 안내를 담은 후속 트윗의 반응은 그에 한참 못 미쳤어요. 사람들이 반응한 건 설정법이 아니라 에이전트가 버그 리포트를 대신 쓴다는 장면 그 자체였다는 뜻입니다.

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

이 기능의 영리함은 타이밍에 있습니다.

버그 신고가 안 오는 이유는 사용자가 게을러서가 아니라, 뭐가 어떻게 잘못됐는지 재구성하는 게 일이라서예요. 어떤 명령을 쳤고, 뭐가 나왔고, 뭘 기대했는지. 실패가 지나간 뒤에 그걸 복원하려면 기억을 뒤져야 합니다.

그 재구성을 실패 현장에 있던 당사자, 즉 클로드 본인에게 시킨 겁니다. 현장 검증인이 조서까지 쓰는 구조예요. 실패의 맥락을 가장 잘 아는 존재가 실패 직후에 기록하니, 사람이 나중에 기억을 복원할 때 생기는 유실이 원천적으로 없습니다.

데모의 프록시 403 사례가 정확히 그 그림입니다. 실패하고, 미러로 우회해 작업은 계속하고, 그 사이에 보고서 초안이 이미 만들어져 있어요.

주목할 건 보고의 품질이 아니라 보고가 생성되는 시점입니다. 사람에게 버그 리포트를 내달라고 부탁하는 순간 이미 절반은 진 게임이었는데, 이제는 부탁 자체가 없어졌어요. 초안이 먼저 와 있고 사람은 예·아니오만 고르면 됩니다.

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

답글창에 뼈 있는 질문이 두 개 달렸습니다.

하나는 이 피드백 기능이 실행 뒤에서 조용히 도는 거냐는 통제 우려, 다른 하나는 사용자가 초안을 검토해 보내게 할 게 아니라 그냥 자동화해야 하는 것 아니냐는 정반대 방향의 요구예요. 같은 기능을 놓고 한쪽은 너무 자동이라 걱정하고, 다른 쪽은 덜 자동이라 불평하는 장면입니다.

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

초안은 기계가 끝까지 만들되, 발송 단추는 사람이 누르는 것. 에이전트 설계의 표준 문법이 돼가는 승인선입니다.

전자의 통제 우려에 대한 답도 같은 곳에 있습니다. 승인 없이는 안 나가고, /config에서 끌 수 있으니까요. 자동화의 경계를 어디에 긋느냐는 질문에, 이 기능은 "작성까지, 전송 직전까지"라고 답한 셈이에요.

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

이 기능은 앤트로픽 입장에서 피드백 수집 파이프라인이기도 합니다.

실패 데이터가 구조화된 형태로 들어오기 시작합니다. 사용자 불만이 트위터에 흩어지는 대신 재현 가능한 보고서로 쌓이는 거예요.

아이러니하게도 이 발표 트윗의 답글창이 그 필요를 증명하고 있었습니다. 답글 다수가 기능과 무관한 사용량 한도·리셋 불만이었거든요. 그나마 반응이 붙은 답글도 기능 얘기가 아니라 50% 부스트를 상시화해달라는 요구였습니다.

불만은 이렇게 아무 데나 쏟아지지, 재현 가능한 리포트로는 안 옵니다. 그 흩어진 신호를 제품 안의 정돈된 채널로 끌어오는 장치인 셈이에요.

제품 개선 속도가 여기서 갈립니다. 사용자를 거쳐 필터링된 실패 데이터를 가장 많이 모으는 쪽이 가장 빨리 고칩니다. 모델 경쟁의 다음 판이 데이터 파이프라인 경쟁인 이유고요.

남는 생각

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

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

쓰는 일은 기계에게, 책임지는 일은 사람에게. 코드 작성에서 이미 일어난 이 분업선이 버그 리포트라는 주변부까지, 작업 종류를 가리지 않고 퍼져가는 중입니다.

에이전트가 일만 하는 게 아니라 자기 실패를 기록하고 보고하는 주체가 되는 것. 제 파이프라인의 워커들도 같은 원리로 돕니다. 실패하면 게이트 로그를 남기고, 저는 그걸 보고 고쳐요.

자기 실수를 숨기는 에이전트가 아니라 문서화하는 에이전트가, 결국 신뢰 곡선을 제일 빨리 올라갑니다.

원문·소스

FAQ

자주 묻는 질문

피드백 초안 기능은 어떻게 동작하나요?
뭔가 실패했을 때, 클로드가 자기 실수를 알아챘을 때, 사용자가 뭔가 잘못됐다고 말했을 때 발동합니다. 그 순간의 상황을 클로드가 스스로 보고서로 정리하고, 사람은 리뷰·전송·무시 세 선택지 중 하나를 고릅니다. 원치 않으면 /config에서 끄거나 동작을 바꿀 수 있어요.
왜 버그 신고는 잘 안 오나요?
사용자가 게을러서가 아니라, 뭐가 어떻게 잘못됐는지 재구성하는 게 일이라서예요. 실패가 지나간 뒤에 그걸 복원하려면 기억을 뒤져야 합니다. 이 기능은 그 재구성을 실패 현장에 있던 당사자인 클로드 본인에게 시킵니다.
전송까지 자동화하면 안 되나요?
피드백 전송은 내 세션의 정보가 밖으로 나가는 불가역 행동입니다. 초안은 기계가 끝까지 만들되 발송 단추는 사람이 누르는 것, 에이전트 설계의 표준 문법이 돼가는 승인선입니다.
앤트로픽은 이 기능으로 무엇을 얻나요?
실패 데이터가 재현 가능한 보고서 형태로 구조화돼 들어오는 피드백 수집 파이프라인입니다. 트위터에 흩어지던 불만을 제품 안의 정돈된 채널로 끌어오는 장치예요.