TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 25 READS

AI 답변을 그대로 나르기만 하고 있나요? '고기 프록시'가 되지 마세요

AI한테 물어보면 1분 만에 나올 답을, 사람이 중간에서 복사해 나르기만 한다면 그 사람의 역할은 뭘까요? 최근 한 개발자가 블로그에 올린 '고기 프록시(meat proxy)가 되지 말라'는 글이 바로 이 질문을 정면으로 던지고 있는데요. 표현이 좀 과격하게 들리지만, AI 도구를 매일 쓰는 요즘 개발자라면 한 번쯤 뜨끔할 만한 이야기라 소개해 드릴게요.

'고기 프록시'가 대체 뭔가요

먼저 프록시(proxy)부터 짚고 갈게요. 이게 뭐냐면, 네트워크에서 요청을 대신 전달해주는 중계 서버예요. 클라이언트와 서버 사이에 앉아서 요청을 받아 그대로 넘기고, 응답을 받아 그대로 돌려주죠. 중요한 건 프록시 자체는 아무 판단도 하지 않는다는 거예요. 그냥 통로거든요.

'고기 프록시'는 여기에 사람을 대입한 표현이에요. AI가 만들어준 결과물을 이해도, 검증도 없이 다른 사람에게 그대로 전달하는 사람. 살과 뼈로 만들어진 프록시 서버라는 거죠. 예를 들면 이런 상황들이에요.

셋 다 공통점이 있어요. 전달하는 사람이 중간에서 아무 가치도 더하지 않았다는 것.

왜 문제가 될까요

첫째, 가치의 문제예요. 상대방도 AI를 쓸 줄 알거든요. 당신이 프롬프트 한 줄 넣고 받은 답이라면, 상대방이 직접 물어보는 것과 뭐가 다를까요? 굳이 당신을 거칠 이유가 없어요. 사람을 거쳐서 온 답변에는 '이 사람이 검토했겠지'라는 암묵적인 신뢰가 실리는데, 검토 없이 전달하면 그 신뢰를 무단으로 빌려 쓰는 셈이 되는 거예요.

둘째, 책임의 문제예요. PR에 올라간 코드는 AI 이름이 아니라 당신 이름으로 남아요. 나중에 그 코드가 장애를 내면 'AI가 짰는데요'라는 말은 변명이 안 되거든요. 결과물에 이름을 올리는 순간 책임도 함께 가져가는 건데, 이해하지 못한 결과물에 책임을 질 수는 없잖아요.

셋째, 비용의 비대칭 문제예요. AI로 코드를 생성하는 데는 1분이면 되지만, 그걸 검증하는 데는 리뷰어의 한 시간이 들 수 있어요. 검증 없이 전달한다는 건 그 비용을 몽땅 상대방에게 떠넘긴다는 뜻이에요. 실제로 오픈소스 쪽에서는 이게 이미 심각한 문제가 됐는데요. curl 프로젝트의 메인테이너는 AI가 생성한, 그럴듯하지만 가짜인 취약점 리포트가 쏟아져 들어와서 검토 시간을 잡아먹는다고 공개적으로 호소한 적도 있어요.

그럼 AI를 쓰지 말라는 걸까요? 아니에요

요지는 AI를 쓰지 말자는 게 아니에요. 프록시가 아니라 필터이자 증폭기가 되자는 거죠. 기준은 간단해요. '이 결과물에 내가 서명할 수 있는가'를 스스로에게 묻는 거예요.

AI가 짜준 코드라면 한 줄씩 읽으면서 왜 이렇게 동작하는지 설명할 수 있어야 하고, 이상한 부분은 고치거나 다시 시켜야 해요. AI가 써준 답변이라면 내 상황에 맞는지 확인하고, 내 언어로 다시 소화해서 전달해야 하고요. 이 과정을 거치면 AI는 나를 대체하는 게 아니라 내 생산성을 몇 배로 늘려주는 도구가 되는 거거든요.

한국 개발자에게 주는 시사점

특히 주니어 개발자분들에게 해당되는 이야기인데요. AI가 짜준 코드를 이해 없이 넘기는 습관이 들면, 당장은 업무가 빨라 보여도 실력이 쌓이지 않아요. 몇 년 뒤에 남는 건 '프롬프트 넣고 복사하는 능력'뿐인데, 그건 누구나 할 수 있는 일이라 대체되기도 제일 쉽거든요.

팀 차원에서는 규칙을 만들어볼 만해요. 예를 들어 'AI로 생성한 코드도 본인이 설명할 수 있어야 머지한다', '리뷰 요청 전에 셀프 리뷰를 먼저 한다' 같은 것들이요. AI 사용 자체를 막는 게 아니라, 검증 책임이 누구에게 있는지를 분명히 하는 방향이 현실적이에요.

정리하면

AI 시대에 개발자의 가치는 '생성'이 아니라 '판단과 검증'에서 나온다는 이야기예요. 여러분 팀에서는 AI가 만든 결과물의 검증 책임을 어떻게 정리하고 있나요? 이해하지 못한 AI 코드를 PR로 받아본 경험, 혹은 올려본 경험이 있다면 어떻게 대처하셨는지 궁금해요.


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://gruhn.me/blog/2026-08-03/
SHARE
처리 중...