Claude Code에서 느껴지는 '작업 완료'의 환상

어느 정도 동의함. 사용자 입력이 나쁘거나 불분명하면 결과물이 부실해지는 건 확실함. 하지만 더 큰 문제는 입력이 좋아도 에이전트가 코드베이스를 오해하거나, 숨겨진 전제를 놓치거나, 잘못된 부분을 검증할 수 있다는 거임. 그래서 검토 영역이 매우 중요하다고 생각함. 더 나은 프롬프트는 에이전트가 올바른 방향으로 시작하게 돕고, 더 나은 검토 환경은 사람이 결과물을 병합해도 안전한지 판단하는 데 도움을 줌.

맞아, '외부 영수증'이라는 표현이 딱이네. 에이전트가 작성한 요약본은 유용하지만, 그게 최종적인 진실의 근거가 되어서는 안 돼. 작업 내용, 변경된 파일, 실행한 명령어, 테스트, 실패 내역, 복구 경로가 포함된 로컬 실행 기록이 있어야 작업을 실제로 신뢰하기 훨씬 쉬워질 거야. Armorer는 주로 그런 로컬 감사 추적/복구 계층에 집중하는 거야, 아니면 그걸 검토하기 위한 UI에도 집중하는 거야?

맞아, 내가 딱 하려던 말이 이거야. Claude Code는 그냥 코드만 짜는 게 아니라, 코드 주변에 '작업 스토리'를 만들어내거든. 그 스토리가 유용할 수도 있지만, 실제보다 더 검증된 것처럼 느끼게 만들기도 해. 깔끔한 요약, 몇 개의 통과된 테스트, 그럴듯한 diff만으로도 엄청난 확신을 주는데, 정작 중요한 가정들은 제대로 확인되지 않았을 때가 많거든. 이런 도구들의 다음 단계는 더 똑똑한 에이전트가 아니라, 더 나은 리뷰 환경이라고 생각해. 나한테...

맞아, '다 된 것처럼 보임'이랑 '내가 작성하지 않은 테스트를 통과함'은 완전히 다른 상태지. 난 이제 무조건 실패하는 케이스부터 먼저 돌리게 해.

좋은 습관이네. 테스트까지 같은 에이전트가 짠 거라면 '테스트 통과'라는 말을 예전만큼 신뢰하지 않게 됐어. 실패하는 케이스를 먼저 돌려보는 게 에이전트가 그냥 그럴듯한 해결책만 내놓는 게 아니라, 진짜 문제를 이해했는지 확인하는 가장 간단한 방법인 것 같아.

절대 diff만 보면 안 됨. 내가 겪은 가장 무서운 오류들은 에이전트가 건드리지 않은 부분에서 발생했어. 업데이트됐어야 할 함수가 그대로 있거나, 적절한 컨텍스트 파일을 읽지 않아서 아예 고려조차 안 된 엣지 케이스 같은 것들 말이야. 내 리뷰 방식은 diff 외에 두 가지를 더 확인하는 거야. 에이전트가 실제로 어떤 파일을 읽었는지(관련 코드를 제대로 찾았는지, 아니면 일부 정보만 가지고 작업했는지) 확인하고, 테스트뿐만 아니라 실제 동작을 직접 실행해보는 거지. 에이전트가 짠 테스트 스위트는 결국 에이전트 자신을 검증하는 경향이 있거든.

중요한 점을 짚었네. diff는 뭐가 바뀌었는지만 보여주지, 뭐가 바뀌었어야 했는지는 안 보여주거든. 에이전트 쓰면서 겪은 가장 골치 아픈 버그들은 구현을 잘못해서가 아니라 누락 때문에 발생했어. 에이전트는 로컬 문제는 제대로 해결했는데, 그게 의존하는 다른 곳들을 전혀 파악하지 못한 거지. 그래서 내가 최종 결과물뿐만 아니라 에이전트가 거쳐온 경로를 보는 데 점점 더 관심이 가는 거야. 어떤 파일을 읽었는지? 어떤 가정을 했는지? 어떤 대안을...