인간 프록시가 되지 마라

Slack에서 질문하거나, merge/pull request에 피드백을 남기거나, WhatsApp 그룹에서 친구들과 논쟁하다 보면 너무 자주 이런 답을 받는다.

Claude의 답변: [엄청나게 긴 답변을 그대로 붙여 넣음]

제발 이러지 말자. 물론 나도 해본 적이 있다. 하지만 이제는 이런 답을 너무 많이 받아봤다. 여기에는 아무런 부가가치도 없다. Claude와는 내가 직접 대화할 수 있다. 그게 더 빠르고, 맥락도 내가 통제할 수 있다. 중간에 인간 프록시를 둘 필요가 없다.

AI가 내놓은 결과를 읽는 데는 추가로 노력이 든다. 장황하고, 그럴듯한 헛소리가 자주 섞여 있으며, 갈수록 전문용어까지 빽빽해지고 있다. 최근에는 Claude에게서 이런 문장을 받았다.

NATS 컨트롤 플레인 이벤트: pod churn 중 stream leader election / R3 quorum 재구성.

세상에. 뜻을 이해하려고 거의 모든 단어를 찾아봐야 했다.

물론 AI에 프롬프트를 입력해도 된다. 하지만 결과를 그대로 전달하기만 해서는 안 된다. 읽고, 이해하고, 검증한 다음 자기 말로 답변을 작성해야 한다. 자기 말로 쓴 답변은 앞의 과정을 거쳤다는 제법 괜찮은 증거이기도 하다. 그 노력이야말로 직접 더할 수 있는 가치다.

특히 코드 리뷰를 생각해 보자. 이제는 거의 아무 노력 없이도 어떤 코드를 내보낼 수 있다. 티켓 설명을 Claude Code에 복사해 붙여 넣는다. 코드는 살펴보지 않고 Claude가 작성한 내용도 읽지 않는다. 리뷰어가 피드백을 남기면 그것 역시 Claude Code에 복사해 붙여 넣는다. 필요하면 이 과정을 반복한다.

이 방법은 통한다. 하지만 실제로 구현한 사람은 누구인가? Claude Code를 사용한 리뷰어들이다. 당신은 그 사이에서 인간 프록시 역할만 했을 뿐이다.

^{source https://gruhn.me/blog/2026-08-03/}

HN에서는 AI를 쓰는 행위보다 검토와 설명의 책임을 동료에게 넘기는 태도를 더 큰 문제로 봤다. 질문을 모델에 넣어 받은 수백 줄의 답변을 그대로 전달하면 보낸 사람은 시간을 아끼지만, 사실 확인과 맥락 해석은 받는 사람의 몫이 된다. 특히 담당 업무에 관한 답변조차 읽지 않은 채 동료에게 검증을 요구하는 개발자를 향한 비판이 거셌다.

이런 관행은 검색 상위 링크나 Stack Overflow 내용을 이해하지 않고 전달하던 모습과 닮았다. 차이는 AI가 긴 문서와 요구사항, PR 피드백을 순식간에 만들어 부담을 크게 키운다는 점이다. 반복되거나 서로 충돌하는 요구사항을 작성해 놓고도 회의에서 아무도 그 뜻을 설명하지 못한 사례처럼, 그럴듯한 분량과 형식이 이해를 대신하면 협업 비용뿐 아니라 신뢰도 함께 무너진다.

그렇다고 조사나 학습에 AI를 활용하는 것까지 부정한 것은 아니다. 질문에 필요한 맥락을 보완하고, 답을 비교·수정하며, 관련 부분만 추려 전달했다면 사람이 이미 가치를 더한 셈이다. 일반 지식을 묻는 상대에게 AI로 확인할 지점을 안내할 수도 있다. 다만 도메인 판단을 요청받았다면 답변자가 결과를 이해하고 검증한 뒤 자기 언어로 결론을 내야 한다. 후속 질문에도 스스로 답할 수 있어야 한다.

실무에서 따져야 할 것은 AI 사용을 밝혔는지가 아니다. 다른 사람의 주의를 요구하기 전에 자신도 충분한 시간과 판단을 들였는지, 답변이 조직 전체의 검토 부담을 줄이는지 확인해야 한다. 문장을 짧게 고치는 데서 그쳐서는 안 된다. 근거와 현업 맥락을 직접 확인하고 최종 판단을 자신의 책임으로 제시할 때 AI는 보조 도구가 된다.