AI 답변을 그대로 전달하는 ‘인간 프록시’가 되지 말자는 이야기

• 글쓴이가 말하는 ‘meat proxy’는 AI 답변을 그대로 복붙해서 사람 사이에 전달하는 인간 중계기를 뜻함

  • Slack 질문, PR 피드백, WhatsApp 논쟁에서 “Claude가 이렇게 말함” 뒤에 긴 답변을 통째로 붙이는 상황을 예로 듦
  • 문제는 상대도 Claude를 직접 쓸 수 있다는 점임. 직접 물어보면 더 빠르고, 맥락도 자기가 통제할 수 있음

• AI 출력물을 읽는 건 공짜가 아님. 오히려 추가 노동임

  • LLM 답변은 길고, 그럴듯한 헛소리가 섞이고, 요즘은 전문용어 밀도도 점점 높아지는 편임
  • 글쓴이는 Claude에게서 “NATS control-plane events: stream leader election / R3 quorum re-form during pod churn” 같은 문장을 받았다고 함
  • 거의 모든 단어를 찾아봐야 이해되는 답변이면, 그걸 받은 사람 입장에선 생산성이 올라간 게 아니라 숙제가 생긴 셈임

• 글쓴이가 요구하는 최소한의 기준은 꽤 단순함

  • AI에게 물어보는 건 괜찮음
  • 다만 결과를 읽고, 이해하고, 검증하고, 그다음 자기 말로 답해야 함
  • 자기 문장으로 설명할 수 있다는 건 앞의 과정을 실제로 했다는 꽤 괜찮은 증명서가 됨

• 특히 코드 리뷰에서는 이 문제가 더 심각해짐

  • 이제 티켓 설명을 Claude Code에 붙여넣으면 코드 작성 자체는 거의 effort 없이 가능함
  • 구현자가 코드를 안 읽고, Claude가 만든 설명도 안 보고, 리뷰어 피드백까지 다시 Claude Code에 붙여넣으며 반복할 수도 있음
  • 겉으로는 작업자가 구현한 것처럼 보이지만, 실제로는 리뷰어들이 Claude Code를 통해 구현을 끌고 가는 구조가 됨

• 이 글의 핵심은 “AI 사용 여부”가 아니라 “협업에서 누가 책임지고 생각했는가”임

  • AI 답변을 전달하는 것만으로는 판단, 압축, 검증, 맥락화가 빠져 있음
  • 동료가 기대하는 건 거대한 LLM 응답 덤프가 아니라, 사람이 이해한 결론과 그 근거임
  • 개발 조직에서 이 차이를 못 잡으면 코드 리뷰가 점점 ‘AI 출력물 검수 공장’처럼 변할 수 있음

---

기술 맥락

• LLM을 협업에 붙일 때 중요한 건 생성 속도가 아니라 검증 책임이에요. 모델은 답을 빠르게 만들지만, 그 답이 현재 코드베이스나 팀의 의사결정 맥락에 맞는지는 사람이 확인해야 하거든요.

• 코드 리뷰에서 Claude Code 같은 도구를 쓰는 선택 자체는 자연스러워요. 반복 구현이나 초안 작성에는 도움이 되니까요. 다만 구현자가 결과를 이해하지 못하면 리뷰어가 설계 판단, 버그 추적, 요구사항 해석까지 떠안게 돼요.

• 그래서 이 글의 실무 포인트는 “AI 답변을 공유하지 말라”가 아니라 “AI 답변을 내 판단으로 소화해서 공유하라”에 가까워요. 팀 커뮤니케이션에서 가치 있는 산출물은 원문 출력이 아니라, 맥락에 맞게 줄이고 확인한 결론이에요.

• 결국 LLM 도입 이후 코드 리뷰의 기준도 조금 바뀌어야 해요. 코드를 누가 타이핑했는지보다, 변경 내용을 누가 이해하고 책임질 수 있는지가 더 중요한 체크포인트가 되거든요.