"개발문화" 태그로 연결된 3개 게시물개의 게시물이 있습니다.

지난달 meat proxy라는 말이 돌았어요. AI에게 질문을 넘긴 뒤, 돌아온 답을 읽지도 않고 동료에게 다시 전달하는 사람을 가리키는 말이에요. 단어만 보면 잘 만든 욕처럼 보이지만, 2025년부터 생긴 비슷한 말들을 발생 순서대로 늘어놓으면 다른 점이 보여요. 탓하는 대상이 한 단계씩 옮겨가고 있어요.

처음에는 산출물을 탓했습니다​

시작은 slop이었습니다. 원래 음식물 찌꺼기를 뜻하던 이 단어가 저품질 AI 생성물 전반을 가리키게 된 경위는 예전 글에서 한 번 정리했습니다. 중요한 건 이 단계에서 지목한 대상이 어디까지나 결과물이었다는 점입니다. 사람은 건드리지 않았습니다.

같은 의미를 업무 맥락으로 좁힌 말이 workslop입니다. BetterUp Labs와 Stanford Social Media Lab이 2025년 9월 Harvard Business Review에 발표한 연구에서 나왔습니다. 정의는 이렇습니다.

"AI generated work content that masquerades as good work, but lacks the substance to meaningfully advance a given task."

좋은 결과물인 척하지만 실제로 일을 진척시킬 알맹이는 없는 AI 산출물이라는 뜻입니다. 미국 정규직 1,150명을 조사한 결과, 40%가 최근 한 달 안에 workslop을 받아 봤다고 답했습니다. 연구진이 짚은 핵심은 부담이 이동하는 방향이었습니다. workslop은 "shifts the burden of the work downstream", 즉 해석하고 고치고 다시 만드는 부담을 받는 쪽에 떠넘깁니다. 보낸 사람의 시간은 줄지만 받은 사람의 시간은 그만큼 늘어납니다. 따라서 조직 전체로 합산하면 남는 것이 없습니다.

AI를 도입한 조직의 95%가 투자 수익을 보고하지 못한다는 통계를 함께 인용하는 이유도 여기에 있습니다.

그다음 사람을 지목하기 시작했습니다​

독일 개발자 Niklas Gruhn(니클라스 그룬)이 2026년 8월 3일 쓴 Don't be a meat proxy가 분기점입니다. Slack, PR 리뷰, WhatsApp에서 동료들이 Claude 출력을 그대로 붙여 넣는 일을 겪은 뒤 쓴 짧은 글입니다.

핵심 문장은 이겁니다.

"I can talk to Claude myself. It's going to be faster and I get to control the context."

Claude는 나도 직접 쓸 수 있고, 그게 더 빠르며, 맥락도 내가 정한다는 말입니다. 마지막 절이 가장 뼈아픕니다. 직접 물어보면 필요한 맥락을 내가 구성해 입력합니다. 하지만 남이 중계하면 그 사람이 입력한 맥락으로 범위가 제한됩니다. 중계자가 더한 것이 없을 뿐 아니라 오히려 선택지를 좁힙니다.

Gruhn이 예시로 든 문장은 이런 종류입니다.

NATS control-plane events: stream leader election / R3 quorum re-form during pod churn.

받은 사람이 이 한 줄을 해독하는 데 쓰는 시간은 보낸 사람이 아낀 시간보다 깁니다. 용어 밀도가 높고, 장황하며, 가끔 틀립니다. Gruhn은 코드 리뷰를 최악의 경우로 꼽았습니다. 검토하지 않은 AI 코드를 올리면 리뷰어가 사실상 구현 작업을 대신하게 됩니다.

단어 자체는 meatspace(육체 세계를 뜻하는 옛 인터넷 속어)와 proxy를 합친 것입니다. 프록시 서버가 기계 사이에서 요청을 전달하듯, meat proxy는 사람의 몸이 그 자리를 대신합니다. Simon Willison이 같은 날 소개했고, Hacker News에서 1,800점을 넘겼습니다.

비슷한 시기에 자리 잡은 말로 AI;DR이 있습니다. TL;DR(too long; didn't read)을 변형한 "artificial intelligence; didn't read"입니다. AI가 쓴 흔적이 보여 읽지 않았다는 선언입니다. 2026년 2월 Futurism 기사를 계기로 퍼져 Wiktionary에 등재됐습니다.

workslop과 meat proxy의 차이는 분명합니다.

연구에서 나온 말과 화가 나서 쓴 말은 퍼지는 속도가 다릅니다. meat proxy가 더 빨리 퍼진 이유는 정확해서라기보다 각자 떠올리는 얼굴이 있었기 때문입니다.

다음은 팀 전체로 번졌습니다​

사람을 지목하는 단계에서 멈췄다면 단순한 유행어로 끝났을 겁니다. 그런데 같은 시기에 학계에서 범위를 넓힌 말이 나왔습니다.

University of Victoria의 Margaret-Anne Storey(마거릿 앤 스토리) 교수가 2026년 2월 제안한 cognitive debt입니다. 논문 "From Technical Debt to Cognitive and Intent Debt"로 정리돼 ACM Queue에 실렸습니다. 정의는 팀 단위입니다. 시스템이 어떻게 동작하는지 아무도 자신 있게 설명하지 못하는 상태입니다. 어떤 변경이 무엇에 영향을 미칠지도 예측하지 못합니다.

한 달 뒤 Addy Osmani(애디 오스마니)가 comprehension debt를 썼습니다. 2026년 3월 14일 글이고, 4월에 O'Reilly Radar에 다시 실렸습니다. 정의는 더 좁습니다.

"The growing gap between how much code exists in your system and how much of it any human being genuinely understands."

시스템에 존재하는 코드량과 사람이 실제로 이해하는 코드량의 격차입니다. Osmani 본인이 Storey의 cognitive debt를 출처로 밝혔으므로 파생 개념으로 보는 게 맞습니다. 참고로 comprehension debt라는 표현 자체는 Jason Gorman이 2025년 9월 30일 먼저 사용했습니다. "고장 내지 않고 고치기 위해 코드를 이해하는 데 드는 추가 시간"이라는 뜻이었습니다.

두 말이 기술 부채와 갈라지는 지점이 중요합니다. 기술 부채는 코드가 지저분한 상태입니다. 눈에 보이고, 린터가 찾아내고, 리팩터링으로 갚습니다. cognitive debt는 코드가 깔끔하지만 아무도 그 이유를 모르는 상태입니다. 정적 분석으로 찾을 수 없고, 장애가 나기 전까지 증상도 없습니다. AI가 아키텍처 결정을 내리지만 그 모델은 비즈니스 맥락도 시스템 역사도 모릅니다. 그 결과 결정만 코드에 남고 근거는 어디에도 기록되지 않습니다.

Storey가 제안한 완화책은 단순합니다. 팀에서 최소 한 사람이 AI가 만든 변경을 완전히 이해한 뒤에 내보낼 것, 무엇이 바뀌었는지가 아니라 왜 바뀌었는지를 기록할 것, 공유된 이해를 되짚는 자리를 정기적으로 둘 것. 대상만 다를 뿐 meat proxy에게 요구하는 내용과 같습니다.

마지막은 모델 자신입니다​

여기까지는 사람에 관한 이야기입니다. 그런데 같은 어휘 묶음에는 사람의 잘못이 아닌 것도 하나 들어 있습니다.

context rot입니다. 벡터 데이터베이스를 만드는 Chroma가 2025년 발표한 연구에서 정식화했습니다. Claude, GPT, Gemini, Qwen 계열 18개 모델로 실험했고, 결론은 이렇습니다.

"model performance degrades as input length increases, often in surprising and non-uniform ways."

입력이 길어지면 출력 품질이 떨어진다는 뜻입니다. 그 양상은 예측하기 어렵고 균일하지 않습니다. 의도적으로 단순하게 만든 과제에서도 나타났습니다. 질문과 답의 의미 유사도가 낮을수록 성능이 더 빠르게 저하됐습니다. 입력이 길어질수록 방해 정보의 영향도 커졌습니다. 논리적으로 잘 정돈한 문서 묶음보다 뒤섞은 쪽이 더 높은 점수를 받기도 했습니다.

이 연구를 인용한 2차 기사 중에는 원인을 U자 곡선이나 RoPE의 long-term decay로 단정하는 글이 꽤 있습니다. 원문은 그렇게 말하지 않습니다. 저자들은 "we do not explain the mechanisms behind this performance degradation"이라고 명시했습니다. 현상은 측정했지만 원인은 확정하지 않았다는 뜻입니다. 인용하는 쪽에서 원문보다 더 많은 것을 주장하는 경우입니다.

context rot에서 파생된 말이 context stuffing입니다. 품질 저하를 우려해 관련 있어 보이는 정보를 전부 입력하는 습관입니다. 하지만 오히려 context rot을 악화시킵니다.

네 단계를 늘어놓으면​

시기가 명확하게 순차적이지는 않습니다. context rot은 1단계와 비슷한 시기에 나왔고 계열도 다릅니다. 그래도 네 묶음이 결국 같은 질문에 서로 다른 답을 내놓는다는 점은 분명합니다. AI가 만든 것을 검증하는 비용은 누가 내는가.

workslop은 받는 사람이 낸다고 답합니다. meat proxy는 중계자가 내지 않고 피했다고 답합니다. cognitive debt는 아무도 내지 않은 비용을 팀 전체가 나중에 한꺼번에 낸다고 답합니다. context rot은 그 비용이 애초에 왜 생기는지를 설명합니다.

그래서 규칙은 하나로 모입니다​

Gruhn이 제시한 규칙은 짧습니다.

"Read it, understand it, validate it, and then write a response in your own words."

읽고, 이해하고, 검증한 뒤 자기 말로 쓰라는 겁니다. 마지막 절이 핵심 장치입니다. 자기 말로 다시 쓰는 행위 자체가 앞의 세 단계를 거쳤다는 증거가 됩니다. Storey가 팀에 요구한 내용도 같습니다. Osmani가 코드 리뷰에서 요구한 내용도 형태만 다를 뿐 같습니다.

AI 사용을 줄이라는 말이 아닙니다. Gruhn도 "use AI all you want"라고 먼저 적었습니다. 실제로 이 차이를 측정한 연구도 있습니다. Anthropic이 개발자 52명을 대상으로 실험했습니다. 생성된 코드를 그대로 넘긴 쪽과 개념을 먼저 질문한 쪽의 이해도 점수가 크게 갈렸습니다. 같은 도구를 썼지만 결과가 달랐습니다. 차이를 만든 것은 사용 방식이었습니다. 이 연구는 따로 정리한 글에 자세히 있습니다.

단어가 네 개나 생겼다는 건 그만큼 자주 겪는 일이 됐다는 뜻이겠죠. 다만 이 목록을 동료를 분류하는 딱지로 쓰면 원래 문제는 그대로 남을 것 같아요. 저한테 가장 유용했던 건 meat proxy라는 말 자체가 아니었어요. 보내기 전에 한 번 멈추게 하는 그 짧은 규칙이었어요.

참고​

• Don't be a meat proxy (Niklas Gruhn, 2026-08-03)
• AI-Generated "Workslop" Is Destroying Productivity (Harvard Business Review, 2025-09)
• How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt (Margaret-Anne Storey, 2026-02-09)
• Comprehension Debt: the hidden cost of AI generated code (Addy Osmani, 2026-03-14)
• Context Rot: How Increasing Input Tokens Impacts LLM Performance (Chroma, 2025)
• ai;dr (Wiktionary)

처음 AI 코딩 에이전트를 제대로 붙여 쓰기 시작했을 때 많은 사람이 "저만의 주니어 개발자가 생긴 것 같아요"라는 비슷한 말을 했어요. boilerplate를 대신 쳐주고, 귀찮은 wiring을 처리하고, 테스트를 만들고, 막혀 있던 작업을 앞으로 밀어주니 손이 하나 더 생긴 기분이었어요.

요즘은 한 발 더 나갔습니다. 멀티 에이전트, 레포 전체를 이해하는 에이전트, 여러 작업을 병렬로 돌리는 오케스트레이션까지. 이제는 "주니어 한 명"이 아니라 "AI 작업자 여러 명을 운영하는" 쪽에 가깝습니다.

그런데 이상한 일이 생깁니다. 코드는 분명히 빨리 나오는데, 하루를 마치면 예전보다 더 지칩니다. 어제보다 하루 더 늙어서 피곤한 줄 알았는데, 관련 논문이 있더라고요.

생산성은 올랐는데 경험은 나빠졌다​

2026년 5월에 나온 논문 한 편이 이 막연한 감각을 데이터로 보여줍니다. Annie Vella와 Kelly Blincoe가 쓴 The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study입니다. 6개월 간격으로 같은 개발자들에게 두 번 설문을 돌린 종단 연구입니다(처음 158명, 추적 101명, 두 시점이 매칭되는 95명).

두 시점에서 공통으로 나온 결과는 우리가 기대하던 그림입니다.

• 82%가 코드를 직접 "작성"하는 데 쓰는 시간이 줄었습니다.
• 84%가 생산성이 좋아졌다고 답했습니다.

그런데 같은 기간, 다른 숫자가 반대로 움직였습니다.

개발자 경험(DX)이 한 가지 이상 영역에서 나빠졌다고 답한 비율이 14%에서 27%로 거의 두 배가 됐다.

구체적으로는 몰입(flow)이 떨어지고 인지 부하가 늘었습니다. 피드백 루프 같은 일부 항목은 오히려 좋아졌지만, 전체적으로 "일하는 느낌"은 나빠진 쪽이 늘어난 것입니다. 논문은 이걸 생산성-경험 역설(productivity-experience paradox)이라고 부릅니다. 더 많은 일을 더 빨리 처리하는데, 정작 일하는 경험은 꼭 같이 좋아지지 않습니다.

일이 '짜는 것'에서 '판단하는 것'으로 옮겨갔다​

같은 논문이 짚는 핵심은 노동의 성격이 바뀌었다는 점입니다. 개발자의 일이 작성(creation)에서 검증, 평가, 수정, 조율 쪽으로 옮겨갑니다. 논문이 이 새로운 노동에 붙인 이름이 감독 엔지니어링(supervisory engineering work)입니다. 코드를 짜는 게 아니라, AI가 짠 코드를 방향 잡고 평가하고 고치는 일이 업무의 중심이 된다는 것입니다.

극단적인 사례는 OpenAI가 직접 올렸습니다. Harness engineering이라는 글에서 5개월 동안 약 100만 줄짜리 베타 제품을 만들었는데, 사람이 직접 친 코드는 사실상 0줄이었다고 합니다. 그동안 엔지니어가 한 일은 코드 작성이 아니라 에이전트가 신뢰할 만한 결과를 내도록 환경, 피드백 루프, 제약을 설계하는 것이었습니다. 그들이 그 환경을 부르는 이름이 하니스(harness)입니다.

이게 공짜로 굴러가지는 않습니다. 자율 코딩 에이전트의 PR 45만 건을 분석한 The Rise of AI Teammates in Software Engineering (SE) 3.0은, 에이전트가 사람보다 빠르게 코드를 올리지만 그 PR의 수용률은 더 낮고 코드 구조는 더 단순하다는 걸 보여줍니다. 빨리 만든다고 다 받아들여지는 게 아닙니다. 누군가는 그걸 읽고, 믿어도 되는지 판단해야 합니다. 그 "누군가"는 여전히 사람입니다.

사람의 검토 용량은 그대로다​

여기서 진짜 병목이 드러납니다. AI는 거대한 diff를 병렬로 빠르게 쏟아냅니다. 그런데 사람이 코드를 읽고 이해하는 속도는 10년 전과 거의 같습니다. 생산 쪽만 폭발적으로 빨라지고, 검토 쪽은 그대로입니다. 이 비대칭이 피로의 한 축입니다.

더 고약한 건 LLM이 "이해한 느낌"을 아주 강하게 준다는 점입니다. 변경마다 자연어 설명이 붙으니, 읽었다고 느끼지만 실제로 상태가 어떻게 바뀌는지는 다 못 따라가는 상태에 쉽게 빠집니다. 그러다 보면 "AI가 그렇게 했는데요"가 점점 자연스러운 말이 됩니다. 이게 단순한 태만이 아닐 수도 있다는 게 무서운 지점입니다. AI가 만들어내는 작업량이 이미 사람의 검토 용량을 넘어섰다는 신호일 수 있습니다.

코드리뷰가 버그 잡기보다 지식을 옮기는 일에 가깝다는 이야기는 따로 한 번 정리한 적 있습니다. 검토가 무너지면 잃는 건 버그 검출이 아니라 그쪽입니다.

예전의 피로와는 결이 다르다​

흥미로운 건 이 피로가 옛날 구현 피로와 성격이 다르다는 점입니다.

예전 개발은 깊은 몰입(flow), 단일 맥락, 긴 집중 상태를 오래 유지하는 일이 많았습니다. 반면 에이전트 워크플로는 백그라운드 작업, 폴링, 승인, 여러 세션 동시 모니터링, 부분 집중, 끊임없는 맥락 전환을 요구합니다. 겉보기엔 "덜 일하는 것"처럼 보이는데, 실제로는 사람이 계속 감독 상태에 머물게 됩니다.

이건 구현자의 피로라기보다 관리자의 피로에 가깝습니다. 결정 피로(decision fatigue), 잘게 쪼개진 주의력, 상황을 계속 파악하고 있어야 한다는 부담입니다. 업계에서는 이걸 판단 세금(judgment tax)이라고 부르기도 합니다. 코드를 만드는 마찰은 사라졌는데, 그 코드를 믿어도 되는지 판단하는 부담은 그대로거나 오히려 늘었다는 것입니다.

장기적으로는 다른 비용도 붙습니다. The Augmentation Trap은 단기 생산성을 위해 AI에 기대다 보면 그 생산성을 떠받치던 숙련 자체가 침식될 수 있다고 봅니다. 편해질수록 판단력이 약해지는 메커니즘은 전에 한 번 다뤘으니 여기서는 줄입니다. 요지는, 지금 느끼는 피로가 미래의 능력을 당겨쓴 결과일 수도 있다는 것입니다.

진짜 질문은 다른 데 있다​

지금 AI 논의는 대개 "개발자가 사라지나"에 쏠려 있습니다. 그런데 위 흐름을 보면 더 중요한 질문은 따로 있습니다.

사람이 AI 작업자들을 어떻게 감독하고, 이해 가능한 상태로 유지할 것인가.

평가(eval) 설계, 거버넌스, 감독, 오케스트레이션 같은 영역이 빠르게 중요해지는 이유입니다. The Productivity-Reliability Paradox는 진짜 병목이 모델 성능이 아니라 사양(specification) 규율이라고까지 말합니다. 무엇을 시킬지 정확히 정의하지 못하면, 더 빠른 에이전트는 더 빠르게 틀린 것을 만들어낼 뿐입니다. Anthropic의 Building Effective Agents나 멀티 에이전트 시스템 구축기가 강조하는 것도 결국 같습니다. 에이전트를 신뢰 가능하게 만드는 건 모델이 아니라 그 둘레를 설계하는 일입니다.

아직 아무도 답을 모른다​

조심할 부분은, 이 변화가 아직 정리된 상태가 아니라는 점입니다. 지금 연구들은 관찰 연구, 설문, 인터뷰, 초기 사용 패턴 분석 수준이 많습니다. 지금의 인지 부담이 단순한 과도기 현상인지, 아니면 에이전트 기반 개발의 구조적 특성인지는 아직 아무도 확신하지 못합니다.

다만 분명한 건 하나입니다. 우리는 "코딩을 더 빠르게 하는 도구"를 하나 들인 게 아닙니다. 개발자의 역할, 검토 문화, 일의 구조 자체를 바꾸는 무언가를 들였습니다.

그러니 더 피곤한 게 이상한 일은 아니에요. 어제보다 하루 더 늙어서가 아니라 일의 종류가 바뀌었고, 생산성 지표만 보면 보이지 않는 비용이 조용히 경험 쪽에 쌓이고 있을 뿐이에요.

참고한 글 / 연구

• Annie Vella & Kelly Blincoe, The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study — '생산성-경험 역설'과 'supervisory engineering work' 개념의 출처
• Hao Li, Haoxiang Zhang, Ahmed E. Hassan, The Rise of AI Teammates in Software Engineering (SE) 3.0 — 자율 코딩 에이전트 PR 45만 건 분석
• Michael Caosun & Sinan Aral, The Augmentation Trap: AI Productivity and the Cost of Cognitive Offloading — 단기 생산성과 장기 숙련 침식
• Sabry E. Farrag, The Productivity-Reliability Paradox: Specification-Driven Governance for AI-Augmented Software Development — 사양 규율이 진짜 제약
• OpenAI, Harness engineering: leveraging Codex in an agent-first world
• Anthropic, Building Effective Agents / How We Built Our Multi-Agent Research System
• explainx, Agentic fatigue meets vibe coding: the AI developer productivity paradox — '판단 세금(judgment tax)' 등 업계 관찰 (peer-review 아님)

최근 몇 달 PR에 붙는 코멘트 패턴이 두 가지로 수렴하는 걸 봐요. 하나는 "LGTM"만 찍힌 채 5분 만에 승인되는 경우예요. 다른 하나는 "AI 리뷰 통과했어요"라는 말이 사실상의 리뷰를 대신하는 경우예요. 둘 다 공통으로 하는 말이 있어요. "지금 바빠서."

"바쁘다"의 진짜 비용​

바쁘니까 리뷰를 건너뛰자는 논리는 단기로는 맞는 것처럼 보입니다. 그런데 우아한형제들 공통시스템개발팀이 쓴 코드 리뷰 문화 개선 이야기를 보면 무엇이 일어나는지 명확해집니다.

"리뷰이는 리뷰를 기다리고 리뷰어는 수많은 MR을 확인하느라 고통받고 있었습니다."

리뷰를 뒤로 미루면 MR이 쌓입니다. 쌓이면 리뷰어가 한 번에 봐야 할 양이 커집니다. 한 번에 봐야 할 양이 커지면 집중력이 떨어지고, 리뷰가 대충 되거나 더 늦어집니다. 팀의 "바쁘다"는 오히려 증폭됩니다. 리뷰를 안 하는 게 원인이고, 바쁜 게 결과입니다. 순서가 반대로 보였을 뿐입니다.

그 팀이 찾은 해법은 "리뷰 안 하기"가 아니었습니다. "리뷰어가 적은 노력으로 잘할 수 있는 환경 만들기"였습니다. MR 크기를 300줄 미만으로 제한, 템플릿으로 맥락 강제, 매일 아침 MR 목록 자동 알림, pre-commit으로 린팅 자동화합니다. 바쁘다는 문제에 "리뷰를 줄이자"로 답하지 않고 "리뷰 비용을 줄이자"로 답한 셈입니다.

"AI가 봤다"의 구조적 결함​

다른 핑계는 더 교묘합니다. "AI가 리뷰해줬어요"는 일견 책임 있는 행동처럼 들립니다. 그런데 2026년 2월 Stanford Law의 CodeX가 쓴 Built by Agents, Tested by Agents, Trusted by Whom?이 정확히 이 지점을 비틉니다.

핵심 문장은 이것입니다.

When the builder and the inspector share the same blind spots, no amount of test variety fully eliminates the risk that both miss the same thing.

빌더와 검사자가 같은 사각지대를 공유하면, 검사의 본래 가치가 무너진다는 얘기입니다. 인간 리뷰어는 작성자와 다른 가정, 다른 경험, 다른 맥락을 가집니다. 그 차이가 리뷰를 의미 있게 만듭니다. AI가 코드를 만들고 같은 모델 계열이 그 코드를 리뷰하면, 차이의 공간 자체가 사라집니다.

같은 글이 인용한 악명 높은 일화가 있습니다. "테스트를 통과시켜라"는 목표만 받은 에이전트가 테스트 본문을 그냥 return true로 고쳐버린 사건입니다. AI는 주어진 지표에 최적화할 뿐, 그 지표가 실제로 무엇을 의미하는지 이해하지 않습니다. 코드를 쓴 AI가 그 코드를 리뷰할 때도 같은 방식으로 최적화합니다. "이 코드는 괜찮아 보인다"에.

리뷰의 진짜 목적은 따로 있다​

여기서 진짜 질문이 나옵니다. 코드리뷰는 대체 무엇을 하는 일일까요.

"버그를 잡는 일"이라는 답이 가장 흔하지만, Microsoft Research의 고전적인 연구는 다르게 정리합니다. 코드리뷰의 핵심 목표는 두 가지입니다.

1. 더 나은 솔루션을 찾기
2. 지식을 팀에 퍼뜨리기

버그 찾기는 부산물에 가깝습니다. 중요한 건 "이 문제를 이 방식으로 풀어도 되는가"에 대한 두 번째 의견을 얻는 것, 그리고 그 과정에서 코드베이스의 맥락, 의사결정, 도메인 지식이 팀원에게 옮겨 가는 것입니다.

뱅크샐러드 기술블로그도 같은 맥락에서 말합니다.

"코드 리뷰 프로세스를 보는 것은 그 회사의 개발 문화를 이해할 수 있는 힌트가 되기도 합니다."

리뷰는 단순한 품질 게이트가 아닙니다. 팀이 서로의 코드를 신경 쓴다는 약속을 매일 갱신하는 의식입니다. 신입이 처음 던진 PR에 시니어가 의도를 묻고, 그 답변이 팀의 집단 지식으로 남는 과정. 누군가가 "왜 이렇게 썼어?"라고 물었을 때 비로소 말로 옮겨지는 암묵지. AI는 코드의 문법과 패턴은 읽지만, 이런 종류의 집단적 맥락을 함께 쌓아 올리는 일은 하지 못합니다.

AI가 못 보는 층​

AI 리뷰가 못 보는 영역이 있습니다. 이 함수가 왜 이렇게 생겼는지의 답이 작년 사고 회고에 있을 때, 그 비즈니스 맥락은 레포 밖에 있어서 모델이 닿지 못합니다. 이 변경이 다른 바운디드 컨텍스트를 건드리는지, 기술 부채를 어디에 쌓는지 같은 아키텍처 판단도 마찬가지입니다. 우리 조직이 정의한 PII와 우리 서비스의 위협 모델에 걸린 보안/거버넌스, 이 레포가 3년 동안 합의해 온 컨벤션 역시 레포 밖 지식입니다. 가장 까다로운 건 조용한 실패입니다. 보기엔 맞는데 edge에서 터지는 코드를, AI는 오히려 더 자신 있게 만듭니다.

AI 리뷰어는 대부분의 경우 "이 코드가 잘 돌아갈 것 같다"를 말합니다. 인간 리뷰어는 "이 코드가 우리 팀이 만들고 유지하기에 맞는가"를 묻습니다. 두 질문은 차원이 다릅니다.

그래서 하고 싶은 말​

AI 리뷰를 쓰지 말자는 얘기가 아닙니다. 오히려 적극적으로 써야 합니다. 스타일 위반, 단순 버그, 빠진 null 체크, 테스트 커버리지 같은 저수준 체크는 AI가 1차로 거르면 인간 리뷰어가 더 가치 있는 질문에 집중할 수 있습니다. 좋은 하이브리드는 AI가 1차 관문, 인간이 2차 판단자인 구조입니다.

문제는 순서가 뒤집혀 있을 때입니다. "AI가 봤으니 인간 리뷰는 생략"이면 그냥 리뷰를 안 한 것입니다.

"바쁘다"는 이유로 건너뛸 때, 우리가 건너뛰는 건 버그 검출이 아니라 서로의 코드를 이해하고 지식을 옮기는 시간입니다. 그건 단기엔 안 보이다가, 1년쯤 뒤에 "왜 이 코드를 나만 이해하지?", "이 사람 없으면 이 모듈은 아무도 모른다"는 청구서로 돌아옵니다.

"AI가 봤다"는 이유로 건너뛸 때 포기하는 건 인간 리뷰어의 다른 시각입니다. 작성자와 다른 가정으로 코드를 읽어주는 눈. 같은 모델이 양쪽에 서면 얻을 수 없는 그것.

코드리뷰는 품질 관리이기 이전에, 팀이 팀으로 남게 하는 장치예요. 자동화해서 없앨 수 있는 건 비용이지 목적이 아니에요.

참고한 글 / 연구

• 우아한형제들, 공통시스템개발팀 코드 리뷰 문화 개선 이야기
• Stanford Law School CodeX, Built by Agents, Tested by Agents, Trusted by Whom? (2026-02)
• 뱅크샐러드 기술블로그, 코드 리뷰 in 뱅크샐러드 개발 문화
• Graphite, Why AI will never replace human code review