Meat proxy일 것인가, 아닐 것인가

요즘 제가 일하는 방식이 meat proxy가 아닌가 하는 생각을 자주 합니다. 글을 AI에게 맡겨 보고, 마음에 안 들어 고치고, 고친 것을 규칙으로 만들어 다시 맡기는 일을 반복하던 중이었거든요. 그러다 이 단어를 만났고, 한 번 떠오른 질문은 잘 가라앉지 않았습니다. '나는 지금 읽고 있는 사람인가, 아니면 그저 옮기고 있는 사람인가.'

Meat proxy는 올해 8월 초에 Niklas Gruhn이 Don't be a meat proxy라는 짧은 글에서 쓴 말입니다. Simon Willison이 같은 날 받아 적으면서 빠르게 퍼졌죠. 뜻은 단순합니다. AI가 낸 답을 읽지도 않고 Slack이나 PR 댓글에 그대로 옮기는 사람. 검증 비용을 자기 이름을 달아 다음 사람에게 떠넘기는 사람. Gruhn의 처방도 단순합니다. "Read it, understand it, validate it, and then write a response in your own words."

단순해서 좋은 기준인데, 막상 저 자신에게 대 보니 잘 안 맞았습니다. 저는 AI 출력을 읽습니다. 많이 고칩니다. 그런데도 질문이 사라지지 않는 이유가 있었어요. 제가 고치는 방식 자체가 결국 '덜 고치기 위한 것'이었거든요. 고친 것을 규칙으로 만들어 이식하면 다음 초안은 덜 고치게 됩니다. 하지만 AI는 계속 발전하고, 그 AI를 제가 계속 깎아나간다면 결국 손 하나 대지 않고 그대로 통과시키는 날이 오지 않을까요? 그날의 저는 meat proxy인가요, 아닌가요. 그래서 기준부터 찾아보기로 했습니다. meat proxy인지 아닌지를 가르는 명확한 선이 어딘가에 있을 것 같았으니까요.

예전에는 오픈소스가 제 기준이었습니다

제가 개발자로 제대로 자라고 있는지 스스로 판단해야 했던 시절이 있습니다. 그때 제 기준은 오픈소스였어요. 남의 코드를 많이 읽었고, 마음에 드는 스타일을 만나면 스니펫으로 잘라 GitHub Gist에 모았습니다. 간단하게는 getOwnPropertyDescriptor를 써 본 기록부터, Broder의 근접 중복 문서 탐지 논문과 simhash를 다룬 같은 주제의 MIT 석사 논문까지 한 곳에 있어요. 함수 하나와 논문 두 편이 나란히 있는 게 이상해 보이지만, 제게는 같은 일이었습니다. 마음에 드는 생각을 만나면 잘라서 모아 두는 것.

나만의 검색 엔진, 그러니까 유연하게 검색되는 작은 데이터센터를 만들어 보겠다고 저장할 때 중복을 어떻게 걸러내는지, 메타데이터를 어떻게 엮는지 생각하던 시절이라 그런 게 모였죠. 지난주에 쓴 '인생 전체의 거대한 아카이브'와 결국 같은 욕구예요. 그때부터 지금까지 저는 꾸준히 그 필요를 느껴 왔어요. 파일 포맷을 직접 만들어 보고, DICOM 같은 표준을 개선한다면 어떻게 해야 할지 시뮬레이션도 돌려 봤어요. 의료 영상 일을 한 것도 아니었는데, 관심 가는 건 다 해 보던 때라 그랬죠. 게임도 만들고 음악도 코드로 만들어 보던, 지금과 크게 다르지 않은 시절이었어요. 그때 공부한 건 나중에 실제 제품에서 파일과 이미지와 데이터베이스를 다룰 때 쓸모를 보였어요.

그렇게 모은 것들이 쌓이면서 "내가 바르게 생각하고 있는가"를 가늠하는 자가 되었습니다. 코드만 그런 게 아니었어요. 서비스 아키텍처도 마찬가지였습니다. 예전에는 서비스 레이어 자체가 오픈소스인 경우가 많아서, 사람들이 어떤 구조를 고르고 어디서 선을 긋는지 눈으로 볼 수 있었거든요.

그 기준은 주관적이었습니다. 누군가에게는 틀린 스타일이고 누군가에게는 맞는 스타일이었겠죠. 하지만 상관없었어요. 제가 왜 그 형태가 되고 싶은지는 제가 설명할 수 있었으니까요. 기준의 객관성이 아니라 기준을 고른 이유가 저를 지탱했습니다. 그리고 그 이유를 만들어 준 것은 눈에 보이는 결과물이었어요. 남이 쓴 코드, 남이 그린 구조. 보고 따라 하고, 따라 하다 보니 제 것이 된 것들.

AI 시대에는 잡을 기준이 없었습니다

같은 방법을 AI 시대에 써 보려고 했습니다. 남들은 Claude를 어떻게 쓰는지, 어디까지 맡기고 어디서부터 직접 하는지, 그걸 보고 제 위치를 재려고요. 그런데 잡히는 게 없었습니다. Gist에 모을 스니펫이 없었어요. 결과물은 있는데, 결과물만 봐서는 그 사람이 AI 출력을 얼마나 읽고 무엇을 버렸는지가 보이지 않았거든요. 사람이 고친 것과 AI가 낸 것이 같은 파일에 섞여 나오니까요.

주관적인 기준이어도 괜찮다는 건 예전과 같습니다. 문제는 주관적인 기준조차 세울 재료가 없다는 것이었어요. 예전의 기준은 결과물에 과정이 새겨져 있어서 가능했는데, 지금은 과정이 결과물 바깥에 있습니다. 어떤 프롬프트를 넣었는지, 어떤 답을 기각했는지는 어디에도 안 남아요. 그래서 오픈소스 쪽으로 한 번 더 갔습니다. 프로젝트들이 AI 기여를 어떻게 다루는지, 거기에 기준이 있는지 보려고요.

오픈소스에는 규칙은 있고 모범은 없었습니다

규칙은 있었습니다. 생각보다 많이요. Linux 커널의 AI 코딩 어시스턴트 문서는 AI가 도운 패치에 Assisted-by: 트레일러를 달게 하고, 대신 Signed-off-by는 사람만 달 수 있다고 못 박습니다. "AI agents MUST NOT add Signed-off-by tags." 서명은 법적 책임이고, 책임은 사람만 질 수 있다는 거죠. Ghostty의 AI 정책은 더 직설적입니다. "If you can't explain what your changes do without the aid of AI tools, do not contribute." 그러면서도 메인테이너들은 AI를 매일 쓴다고 덧붙여요. 도구가 아니라 사람이 문제라는 겁니다.

정책을 모아 둔 목록을 훑어보면 금지하는 쪽(Zig, Gentoo, GIMP, Servo), 공개를 요구하는 쪽(커널, LLVM, curl, Django, Kubernetes), 자유에 맡기는 쪽(CPython, Rust, uv, Ghostty)으로 갈립니다. 그런데 허용하는 쪽의 기준을 읽어 보면 전부 같은 문장으로 수렴해요. '네가 설명할 수 있어야 한다, 네가 책임져야 한다, 리뷰하는 시간보다 가치가 커야 한다.' 1,000개 인기 저장소를 조사한 논문에 따르면 AI 정책이 있는 곳은 118개, 그중 74%가 사람이 루프 안에 있어야 한다고 적었지만, "얼마나"가 어느 정도인지는 대부분 정하지 않았습니다. 측정 가능한 기준은 없었어요. 모두가 Gruhn과 같은 자리에 서 있었습니다. 읽었는가, 책임지는가.

그러니까 제가 찾던 건 거기 없었습니다. 오픈소스가 준 건 문턱이었지 모범이 아니었어요. '이렇게 쓰지 말라'는 선은 있는데, '이렇게 쓴다'는 형태는 없었습니다. 예전에 제가 Gist에 모은 건 금지선이 아니라 따라 할 형태였잖아요. 커널의 Assisted-by:조차 누가 AI를 썼는지는 보여 주지만 어떻게 썼는지는 보여 주지 않아요.

거의 유일한 예외를 하나 봤습니다. Cloudflare의 workers-oauth-provider는 Claude에게 넣은 프롬프트를 커밋 메시지에 전부 남겼어요. "Have Claude write an OAuth provider implementation"으로 시작해서 "Ask Claude to fix its bugs", "Ask Claude not to store clients_list"로 이어지는 기록이죠. 그리고 그 커밋을 전부 읽은 사람이 거기서 배운 것을 글로 썼습니다. 예시 코드로 프롬프트하는 법, 마흔 번째 커밋쯤부터 사람 개입이 늘어나는 지점. 제가 예전에 오픈소스를 보며 했던 일이 거기서 한 번 일어났어요. 그런데 그건 규칙이 만든 게 아니라 한 사람의 선택이었습니다. 과정을 공개하는 것은 누구의 의무도 아니니까요.

그러다 질문이 뒤집혔습니다

기준을 못 찾은 채로 제 방식을 다시 봤습니다. 처음 글 한두 편은 전부 맡겼어요. 뜻은 제 것이었는데 톤이, 섹션이, 흐름이 제 것이 아니었습니다. 그래서 직접 고쳤고, 고친 것과 원래 초안의 차이를 규칙으로 적어 스킬로 만들었습니다. 대시를 쓰지 마라, 볼드를 쓰지 마라, 은유는 생활적인 것 하나만. 스킬은 제 입맛대로 계속 고쳐 나가고 있고, 문장 취향 다음에는 사고 방식도 넣을 생각이에요. 저는 문제가 생기면 근원이 무엇인지에 집착하는 편인데, 그런 식으로 일하게 하고 싶거든요.

그런데 그 순간 질문이 뒤집혔습니다. 스킬이 좋아질수록 고칠 게 줄어듭니다. 고칠 게 줄면 덜 읽게 되고, 안 읽는 사람이 meat proxy라면, 저는 지금 meat proxy가 되려고 AI를 다듬고 있는 게 아닌가. 처음 질문은 "나는 meat proxy인가"였는데, 끝에 남은 질문은 "나는 meat proxy가 되려고 노력하는 중인가"였습니다. 그리고 그 뒤에 하나가 더 따라왔어요. 그게 꼭 나쁜 건가.

커널은 proxy를 쫓아내지 않고 서명란을 붙였습니다

다시 보니 답의 절반은 아까 읽은 커널 문서에 있었습니다. 커널은 사람이 코드를 다 쓰지 않았어도, 심지어 AI가 썼어도, 사람이 서명하고 책임지라고 합니다. 그건 사실상 책임지는 meat proxy가 되라는 말이에요. 커널은 사람을 proxy 자리에서 치우지 않았습니다. proxy 자리에 서명란을 붙였죠. Gruhn이 욕하는 meat proxy는 책임 없이 통과시키는 사람이고, 커널이 요구하는 건 책임지고 통과시키는 사람입니다. 둘은 같은 자리에 서 있어요.

그래서 질문을 한 번 더 바꿔야 했습니다. meat proxy가 될 것인가 아닐 것인가가 아니라, '어떤 proxy가 될 것인가'. 개발자에게 proxy는 원래 나쁜 말이 아니잖아요. 투명 프록시는 들어온 것을 그대로 내보냅니다. 리버스 프록시는 TLS를 끊고, 헤더를 보고, 속도를 제한하고, 잘못된 요청은 거절해요. 본문을 한 바이트씩 읽지는 않습니다. 자기 정책이 사는 층에서만 검사하죠. 그런데도 리버스 프록시를 아무것도 안 하는 것이라고 부르는 사람은 없습니다.

이 그림으로 보면 제 불안의 인과가 끊어졌습니다. 덜 읽는 게 문제가 아니었어요. 어느 층에서 읽는가, 그리고 거절할 수 있는가가 문제였습니다. 문장 층은 스킬이 검사하고, 저는 테제와 서사와 진단의 층에서 검사합니다. 거기서 기각이 나오면 그건 정책이 있는 proxy예요. 모든 층을 그대로 통과시키면 투명 프록시고, 그게 Gruhn의 meat proxy입니다. 이건 지난번 hejbro 글에서 쓴 "우리가 AI를 믿는 게 아니라 구조가 실수의 비용을 낮춘다"의 거울상이기도 해요. 그때는 구조가 AI의 실수를 받아 주는 이야기였고, 이번에는 구조가 사람을 읽는 자리에 붙잡아 두는 이야기입니다.

그래서 기각 기록을 만들었습니다

그 자리에 저를 붙잡아 두려고 오늘 작은 장치를 하나 만들었습니다. AI의 진단이나 서사나 제안을 제가 기각할 때마다, 무엇을 제안했고 왜 기각했는지를 한 항목으로 적는 기록이에요. 스킬이 제 취향을 흉내 내게 만든다면, 이 기록은 제가 계속 읽게 만듭니다. 수정량은 지표가 못 돼요. 스킬이 좋아지면 수정은 줄어드는 게 정상이니까요. 대신 기각이 있는가, 기각한 이유를 말할 수 있는가는 지표가 됩니다. 이게 제가 찾던 기준선에 가장 가까운 것이었습니다. 여전히 주관적이지만, 예전 Gist처럼 제가 왜 그렇게 하는지 설명할 수 있는 기준이요.

이건 글에서만 하는 일이 아니었습니다. hejbro를 만들면서도 같은 일이 있었어요. AI가 짠 코드와 설계를 읽다가 질문을 던지고 기각한 것이 실제 버그를 여러 번 잡아냈습니다. 그때는 이름이 없었지만, 그것도 기각이었습니다.

이 글을 쓰는 오늘 하루에만 기각이 여러 번 있었습니다. 스킬에 대한 것도 있었고, 이 글의 제목에 대한 것도 있었어요. 무엇을 기각했는지는 여기 적지 않겠습니다. 중요한 건 내용이 아니라 기록이 남았다는 사실이니까요. 그 몇 줄이 제가 오늘 투명 프록시가 아니었다는 기록이에요. diff가 없는 사람이 meat proxy라면, 저는 오늘 diff가 있었습니다.

다시 정리해보자면

Meat proxy일 것인가, 아닐 것인가. 제목을 그렇게 달아 놓고 끝에 와서 하는 말이 이상하지만, 질문 자체가 틀려 있었습니다. 저는 proxy가 될 겁니다. AI가 만들고 제가 서명해서 내보내는 자리에 서 있을 테니까요. 진짜 문제는 '어떤 proxy가 될 것인가'입니다. 그저 통과시키는 proxy인가, 아니면 자기 정책이 사는 층에서 읽고 거절하는 proxy인가.

정직하게 덧붙이면, 이 생각에도 두 가지 허점이 있습니다.

첫째는 AI에 입력해 둔 규칙은 결국 '과거의 내 취향'일 뿐이라는 점입니다. 사람의 생각과 입맛은 계속 변하는데, AI의 제안을 받아 적기만 하고 그냥 넘어가기 시작하면 AI는 계속 예전의 내 스타일만 복제해 낼 겁니다. 결국 내가 AI를 발전시키는 게 아니라, AI가 나를 '과거의 나'에 가둬두게 되는 거죠.

둘째는 형식이 아니라 '생각의 오류'를 잡아내는 건 훨씬 어렵다는 점입니다. 오타나 말투, 문장 길이를 고치는 건 눈에 금방 띄지만, AI가 그럴듯한 논리로 써 내려간 '틀린 생각'이나 '주제의 오류'는 대충 읽으면 그냥 넘어가기 십상입니다. AI가 내 스타일을 완벽하게 흉내 낼수록, 역설적으로 그 글이 진짜 맞는지 검증하는 일은 몇 배나 더 피곤하고 까다로워지는 셈입니다.

그래서 "거절하는 proxy"는 한 번 되면 끝나는 상태가 아니라 계속 유지해야 하는 습관이라고 생각해요. 기각 기록이 한동안 비어 있으면 둘 중 하나입니다. AI가 계속 옳았거나, 제가 읽기를 멈췄거나. 앞의 것이기를 바라면서도 늘 뒤의 것일 가능성을 의심하는 것. 그게 제가 잡은 기준선입니다. 예전 기준처럼 누구에게나 정답은 아니겠지만, 적어도 왜 이렇게 일하려 하는지는 이제 스스로에게 설명할 수 있게 됐습니다.