미트 프록시 (Meat Proxy)

동료에게 물었더니 AI가 답을 보내왔다. 읽어 보지도 않고 AI 답변을 옮겨 나르기만 하는 사람을 요즘은 미트 프록시라고 부른다. 그렇게 아낀 시간이 어쩌다 동료 앞으로 날아간 청구서가 되는지, 이 이름을 피하는 네 가지 습관까지 담았다.

AIAI 활용개발 문화협업
--
미트 프록시 (Meat Proxy)

답장을 쓴 건 동료가 아니었다

동료에게 메신저로 질문을 하나 보냈다고 해 보자. 몇 분 뒤 "~에 대해 정리해 드리면 다음과 같습니다"로 시작하는 긴 답장이 오는데 그중 한 줄을 짚어 되물으면 정작 동료는 대답을 못 한다. 요즘 개발자들은 이런 사람을 미트 프록시(Meat Proxy)라고 부른다.

질문은 사람에게 했는데 대답은 AI가 했다.

이 말이 무슨 뜻인지, AI를 쓰는 사람에게 왜 남의 일이 아닌지, 미트 프록시가 되지 않기 위해서는 어떻게 해야 하는지 적어 본다.

'프록시'는 원래 컴퓨터 용어다. 중간에서 요청을 받아 다른 곳으로 넘기고 돌아온 답을 다시 전해 준다. 말하자면 중계 역할이다.

우체국 창구 직원을 떠올리면 된다. 편지를 받아 부치고 답장이 오면 건네줄 뿐, 봉투를 뜯어 읽지는 않는다.

미트 프록시는 직역하면 '고기로 된 중계기'다. 살과 피가 있는 중계기라는 뜻이니 칭찬은 아니다. AI와 동료 사이에서 질문과 답을 옮겨 나르기만 하는 사람을 비꼬는 말이다. 이런 사람은 AI가 만든 코드나 보고서, 메신저 답변을 이해하지도 검토하지도 않고 그대로 전한다.

동료의 질문은 그대로 AI에게 건너가고 AI의 답은 그대로 동료에게 돌아온다. 가운데 선 사람은 손만 빌려줄 뿐 아무것도 보태지 않는다. 동료로서는 AI에게 직접 물은 것과 다를 바가 없다. 아니, 더 나쁘다. "이 사람이 확인한 답이겠지" 하는 믿음까지 덤으로 붙어 오니까.

개발 현장에서는 이미 낯익은 풍경이다. PR 메세지를 작성하거나, 특정 현상에 대한 브리핑 문서를 확인할 때 그렇다.

남의 코드에 다는 검토 의견에 AI 답변이 그대로 붙어 있어 맥락과 어긋난 지적이 섞이기도 한다. 누구나 참여하도록 공개된 프로젝트(오픈 소스)에는 AI로 만든 버그 제보가 올라오는데 재현되는지 확인조차 안 된 것들이다.

미트 프록시가 남기는 청구서

AI 답변을 확인 없이 넘기면 내 시간은 아낀다. 하지만 답이 맞는지 따져 보는 수고까지 사라지지는 않는다. 청구서가 받는 사람 앞으로 넘어갈 뿐이다.

받는 쪽은 모든 줄을 의심하며 읽어야 한다. 실수는 늦게 드러난다. 운이 나쁘면 실제 서비스가 돌아가는 중에야 얼굴을 내민다. 그사이 팀 안의 신뢰가 조금씩 깎여 나간다.

검토를 거쳐 넘기면 이야기가 달라진다. 내 시간이 그만큼 더 드는 대신 실수가 생긴 자리에서 바로 잡힌다. 받는 쪽은 평소처럼 읽으면 그만이니 신뢰도 그대로이거나 오히려 쌓인다.

확인 안 된 결과물을 한두 번 받고 나면 동료는 같은 사람이 보내는 것이라면 무엇이든 의심부터 하게 된다. 신뢰는 깎이기는 쉬워도 다시 채우기는 더디다. 그러다 "이 사람 것은 돌려보내고 내가 다시 하는 게 빠르다"는 판단에 이른다. 검토할 사람이 한두 명뿐인 작은 팀이라면 짐은 남은 사람 어깨에 고스란히 얹힌다.

이 청구서가 가장 크게 쌓이는 곳은 오픈 소스다. 관리자 대부분이 자원봉사에 가깝게 프로젝트를 돌보는데 그런 곳에 AI가 만든 제보와 변경 요청이 쏟아지고 있다. 재현되지 않는 '보안 취약점' 제보가 들어오고 프로젝트 규칙은 아랑곳없는 대량 수정이 올라온다. 검토 의견에 다시 AI 답변으로 응수하는 참여자도 있다.

이런 기여는 하나하나 확인하고 닫는 데만 상당한 시간이 든다. 관리자의 시간은 프로젝트에서 가장 귀한 자원인데 그게 가장 값어치 없는 일에 쓰이는 셈이다. 일부 프로젝트가 AI로 만든 기여를 어떻게 다룰지 규칙을 따로 내걸기 시작한 것도 그래서다.

멀쩡해 보이는 코드가 더 위험한 이유

AI 결과물이 까다로운 건 늘 그럴듯해 보여서다. 문장은 매끈하고 자신만만하다. 코드는 오류 표시 하나 없이 돌아간다. 사람이 대충 쓴 코드는 대충 쓴 티가 나는데 AI가 대충 쓴 코드는 티조차 나지 않는다.

AI에게 "사용자를 바꾸면 그 사람의 프로필을 불러오는 기능을 만들어 줘"라고 부탁하면 대개 겉보기에 멀쩡한 코드를 받는다. 한 번 실행해 보면 잘 돌아간다.

탈은 사용자를 빠르게 연달아 바꿀 때 난다. 먼저 보낸 요청의 답이 나중 요청의 답보다 늦게 도착하면 늦게 온 옛 정보가 최신 정보를 덮어쓴다. 개발자들은 이런 상황을 경쟁 상태(race condition)라고 부른다. 요청이 실패했을 때 어떻게 할지도 코드에 빠져 있다.

택배로 치면 이렇다. A를 주문했다가 마음을 바꿔 B를 주문했다. B가 먼저 와서 문 앞에 놓였는데 한참 뒤에 도착한 A가 그 자리를 차지한다. 화면에서는 분명 B를 골랐는데 A의 프로필이 떠 있다.

꼼꼼히 읽는 사람이라면 이 지점을 잡아낸다. 새 요청을 보낼 때 이전 요청은 취소하고 실패하면 오류를 따로 알리게 고치면 된다. 아예 도구에 맡기는 편이 나을 수도 있다.

어느 쪽을 고르든 왜 골랐는지는 말할 줄 알아야 한다. 동료가 "여기서 늦게 온 응답은 괜찮나요?" 하고 물을 때 대답이 나와야 코드에 내 이름을 붙일 수 있다.

붙여 넣는 순간 내 것이 된다

AI는 확률적으로 그럴듯한 답을 만드는 도구라서 틀리기도 한다. 이제 다들 아는 이야기다.

틀릴 수 있다는 걸 알면서 확인 없이 내 이름으로 내보냈다면 책임은 그렇게 결정한 사람이 진다. 개발자들이 자주 찾는 질문 게시판, Stack Overflow에서 베낀 코드가 틀렸다고 해 보자. "게시판이 틀렸어요"라고 하는 사람은 없다.

붙여 넣는 순간, 그 코드는 내 것이 된다.

다만 개인에게만 돌을 던지기는 어렵다. 어떤 기업은 AI 도입을 장려한다며 AI 사용량(토큰 사용량. AI가 처리한 글의 양쯤으로 이해하면 된다)이나 활용 빈도를 성과 지표로 삼는다. 그러면 잘 확인한 사람보다 많이 쓴 사람이 보상을 받는다.

사람은 재는 대로 움직인다. 사용량을 목표로 걸면 다들 많이 쓰는 쪽으로 기운다. 검토에 들인 시간은 숫자 위에서 낭비로 찍힌다.

개인적으로는 AI 도입을 고민하는 팀이라면 사용량 말고 결과의 질을 보여 주는 지표를 함께 봐야 한다고 생각한다. 일이 끝나기까지 걸린 시간, 검토에서 돌려보낸 비율, 장애가 난 횟수 같은 것들 말이다.

미트 프록시가 되지 않는 4가지 습관

AI를 부지런히 쓰면서도 미트 프록시가 되지 않는 길은 생각보다 단순하다. 네 가지 습관이면 된다.

먼저 보내기 전에 끝까지 읽는다. 가장 기본인데 가장 자주 건너뛰는 단계다. 읽으면서 스스로 묻는다. 이게 왜 이렇게 동작하는지 설명할 수 있나. 내가 부탁하지 않은 변경이 끼어 있지는 않나. 빈 값이나 오류 같은 예외 상황은 챙겼나.

다음은 내 말로 다시 쓰기다. AI 답변을 그대로 붙이지 말고 핵심만 추려 내 말로 옮긴다. 변경 요청서나 메신저 답장에서 특히 효과가 크다.

"안정성과 유지보수성을 획기적으로 향상시키는 포괄적 개선"이라는 문구에 이모지 달린 항목 몇 줄을 붙이는 대신, "사용자를 빠르게 바꾸면 옛 프로필이 최신 프로필을 덮어쓰는 문제가 있어서 이전 요청을 취소하게 고쳤다. 빠르게 바꿔도 마지막 사용자만 보이는 걸 확인했다"처럼 쓰는 식이다. 다시 쓰는 일이 곧 시험이다. 내 말로 요약되지 않는다면 아직 이해하지 못했다는 뜻이다.

내 이름이 걸려 있다는 사실도 잊지 않는다. "AI가 그렇게 짜 줬어요"는 변명이 되지 못한다. 작업 기록에도, 변경 요청서에도, 메시지 발신자 칸에도 찍히는 건 내 이름이다. 이걸 떠올리기만 해도 '일단 보내고 보자'는 손버릇이 꽤 줄어든다.

마지막으로 내보내기 전에 직접 확인한다. 검토하는 동료가 테스트까지 대신해 주지는 않는다.

손수 실행해 바뀐 화면을 보고 정상적인 경우뿐 아니라 오류나 빈 값인 경우도 하나 이상 확인한다. 바뀐 부분을 처음부터 끝까지 읽고 자동 검사가 통과하는지 본다. 동료가 물을 만한 질문에 답할 수 있는지도 떠올려 본다.

AI에게 검토를 맡겨도 좋다. 그 검토 역시 AI가 내놓은 결과물이라 맞는지 가리는 일은 다시 사람 몫이다.

AI를 쓰는 사람과 AI가 지나가는 통로

AI를 쓰지 말자는 이야기는 아니다. 나도 혼자서는 엄두를 못 냈을 일들을 AI 덕분에 해내고 있다. 앞으로는 더 많이 쓰게 될 것이다. 다만 AI를 쓰는 사람과 AI가 지나가는 통로는 다르다.

동료의 질문에 AI 답변만 돌아온다면 다음부터 동료는 나를 건너뛰고 AI에게 바로 물을 것이다. 합리적인 선택이다. 미트 프록시는 그렇게 "나는 AI로 대체할 수 있다"고 제 손으로 증명하는 꼴이 된다.

개발자의 가치는 맥락을 이해하고 무엇을 얻고 잃을지 저울질한 뒤 결과에 책임지는 데서 나온다. 타자 속도와는 거리가 멀다.

검토 없이 넘긴 결과물은 확인하는 수고를 동료에게 떠넘기지만 책임만은 보낸 사람 곁에 남는다. 개인적으로는 AI가 초안을 쓰는 일이 흔해질수록 초안을 판단하고 책임지는 능력이 경쟁력이 될 거라고 본다. 미트 프록시가 되지 않으려면 AI 답변을 복사하기 직전에 한 번만 스스로 물어보면 된다.

"이걸 내가 설명할 수 있나?"

참고 자료

관련 글

댓글

0/2000
Newsletter

이 글이 도움이 되셨나요?

새로운 글이 발행되면 이메일로 알려드립니다.

뉴스레터 구독하기