지난주 한 에이전트(Agent)가 우리 서비스에 풀 리퀘스트(Pull Request)를 올렸습니다. 600줄 분량이었습니다. 그것은 우리가 웹훅(Webhook) 재시도와 중복 제거(Deduplication)를 처리하는 방식을 재작성했는데, 이는 까다롭고 미묘하게 틀리기 쉬운 영역입니다. 차이점(Diff)은 깔끔했습니다. 테스트는 통과(Green)되었습니다. 커밋 메시지(Commit messages)는 평소 제 것보다 더 나았습니다.

그리고 저는 2026년에 많은 엔지니어들이 느끼기 시작할 것 같은 특유의 공포를 느꼈습니다. 제가 검토자(Reviewer)였습니다. 저는 이 코드 중 그 어떤 것도 작성하지 않았습니다. 왜 이런 구조로 만들어졌는지 전혀 알 수 없었습니다. 제 코드가 검토되기를 바라는 방식대로 제대로 검토하려면, 코드 자체로부터 의도를 신중하게 재구성하는 데 거의 한 시간 가까운 시간을 써야 했습니다. 저에게는 그럴 시간이 없었습니다. 그래서 저는 그런 상황에서 거의 모든 사람이 하는 행동을 했습니다. 대충 훑어보고, 합리적으로 보인다고 판단한 뒤, 승인(Approve)하는 것이었습니다.

그 순간이 바로 AI가 작성한 코드의 실제 문제이며, 사람들이 논쟁하는 것과는 다른 문제입니다.

병목 현상은 이동했고, 대부분의 팀은 적응하지 못했다

에이전트가 좋은 코드를 작성하느냐에 대한 지루한 논쟁이 있습니다. 2026년에 그 논쟁은 거의 끝났습니다. 그들은 잘 작성합니다. 그들은 계획을 세우고, 코드베이스(Codebase)를 읽고, 테스트를 실행하며, 막다른 길에서 물러나고, 대부분의 검토 기준을 통과하는 풀 리퀘스트(Pull Request)를 생성합니다. 만약 당신이 여전히 코드가 좋은지 아닌지를 두고 다투고 있다면, 당신은 한동안 최신 에이전트를 사용하지 않은 것입니다.

하지만 여기서 파생되는 결과가 있으며, 이것이 바로 팀들이 아직 흡수하지 못한 부분입니다. 코드를 작성하는 것이 더 이상 느린 단계가 아니라면, 그것을 검토하는 것이 느린 단계가 됩니다. 그리고 검토는 생성(Generation)이 확장되는 방식만큼 확장되지 않습니다. 에이전트는 점심 식사 전에 다섯 개의 잘 테스트된 풀 리퀘스트(Pull Request)를 만들어낼 수 있습니다. 당신의 시니어 엔지니어들은 자신의 업무 외에 점심 식사 전까지 다섯 개의 풀 리퀘스트를 깊이 있게 검토할 수 없습니다. 볼륨은 늘어났지만 검토 능력은 늘어나지 않았고, 결국 무언가는 감내해야만 합니다.

문제는 검토의 깊이가 무너진다는 점입니다. 검토는 조용히 훑어보기(skim)로 퇴보합니다. 사람들은 제대로 읽는 데 드는 시간이 누구에게나 부족하기 때문에, 실제로 읽지 않은 유창한 디프(diff)를 승인해 버립니다. 초록색 체크 표시(green check)는 여전히 나타납니다. 다만 그것이 예전만큼의 의미를 갖지 못할 뿐입니다. 이는 통과된 검토의 탈을 쓴 거버넌스(governance)의 실패이며, 현재 많은 팀에서 아무도 문제라고 결정하지 않은 채 일어나고 있는 현상입니다.

에이전트 PR이 인간의 PR보다 검토하기 어려운 이유

이 문제가 인간이 저지르는 동일한 문제보다 왜 더 심각한지 정확히 짚고 넘어갈 가치가 있습니다.

팀 동료가 풀 리퀘스트(pull request)를 보내면, 보통 여러분은 그와 맥락(context)을 공유하고 있습니다. 스탠드업(standup) 미팅에 함께 있었고, 스레드(thread)를 보았을 것입니다. 그들이 왜 이 작업을 하는지, 어떤 제약 조건 하에 있는지 대략적으로 알고 있습니다. 여러분은 이미 머릿속에 가지고 있는 의도(intent)에 비추어 디프(diff)를 검토합니다.

하지만 에이전트 PR의 경우, 그러한 공유된 맥락이 사라집니다. 여러분은 상당한 양의, 자신감 넘치고, 잘 구조화된 디프(diff)를 건네받지만, 그것이 왜 그런 형태로 구성되었는지에 대한 설명(narrative)은 받지 못합니다. 복도에서 에이전트에게 물어볼 수도 없습니다. 따라서 이를 제대로 검토한다는 것은 순수하게 코드로부터 의도를 재구성해야 함을 의미하며, 이는 느리고 오류가 발생하기 쉬우며, 시간 압박 속에서 정확히 생략되기 쉬운 작업입니다. 코드의 유창함은 상황을 더 악화시킵니다. 유창한 코드는 그 이면의 사고 과정 또한 똑같이 건전할 것이라고 가정하게 만들기 때문입니다.

이 과정을 통과해 살아남는 실수들은 구문(syntax) 오류가 아닙니다. 그것들은 맥락적(contextual)입니다. 에이전트는 일반적인 상황에서는 참이지만, 여러분의 시스템에서는 거짓인 가정에 의존했습니다. 저희의 경우, 중복 제거(dedup) 재작성 작업은 웹훅(webhook)이 페이로드(payload)를 기준으로 중복 제거될 수 있다고 조용히 가정했습니다. 하지만 저희가 별도의 멱등성(idempotency) 필드를 키(key)로 사용했던 전체 이유는, 상위 시스템(upstream) 중 하나가 실제로 서로 다른 이벤트에 대해 바이트 단위로 동일한 페이로드를 보내기 때문이었습니다. 완벽하게 합리적인 코드입니다. 하지만 저희에게는 틀린 코드였으며, 그 이유는 저희의 이력(history)에 존재할 뿐 디프(diff) 어디에도 나타나지 않습니다.

더 열심히 검토한다고 해서 해결할 수 있는 문제가 아니다

본능적인 대응책들은 통하지 않습니다.

"이전처럼 모든 것을 주의 깊게 검토하라"는 방식은 급증하는 작업량이라는 현실과 마주하면 살아남지 못합니다. 수학적으로 불가능합니다. "에이전트(Agent)를 신뢰하라"는 것은 거버넌스(Governance) 태세가 아니라, 거버넌스의 부재를 의미합니다. "CI 규칙을 더 추가하라"는 방식은 이미 대부분 해결된 구문론적(Syntactic) 범주의 문제에는 도움이 되지만, 아키텍처(Architectural) 오류에는 거의 도움이 되지 않습니다. 맥락적 위반(Contextual violation)은 린트(Lint) 규칙의 문제가 아니라, 어떤 체크 도구도 알지 못하는 팀의 결정과 충돌하는 문제이기 때문입니다.

방정식을 실제로 바꾸는 것은 더 열심히 검토하는 것이 아닙니다. 검토가 소비하는 대상을 바꾸는 것입니다.

차이점(Diff)보다 추론(Reasoning)을 먼저 읽으세요

여기 변화의 핵심이 있습니다. 검토자에게 가공되지 않은 차이점(Raw diff)을 건네주며 의도를 역공학(Reverse-engineer)해달라고 요청하는 대신, 작업이 어떻게 이루어졌는지에 대한 이야기(Story)를 먼저 건네주는 것입니다. 그 작업이 의존했던 결정들, 작업이 수행된 제약 조건들, 시작 전 주어진 맥락, 부딪혔던 질문들과 그에 대한 답변, 시도했다가 되돌린 접근 방식들, 그리고 인간이 개입하여 방향을 잡았던 지점들을 전달하는 것입니다.

그러면 검토자는 그 서사(Narrative)를 먼저 읽고, 이미 의도가 확립된 상태에서 두 번째로 차이점(Diff)을 읽게 됩니다. 코드를 뚫어지게 쳐다볼 때는 보이지 않던 맥락적 오류가, 그 이면의 추론을 보는 순간 명확해집니다. 만약 에이전트의 계획이 페이로드(Payload)를 기준으로 중복을 제거하는 것에 기반하고 있다는 것을 미리 알았더라면, 저는 왜 그것이 여기서 잘못되었는지 알고 있었기에 5초 만에 잡아냈을 것입니다. 하지만 600줄의 코드 속에 파묻혀 있었기에 완전히 놓치고 말았습니다.

이것이 바로 제가 Branch Story로서 구축하고 있는 것입니다. 어떤 브랜치(Branch)나 풀 리퀘스트(Pull Request)에 대해서든, Branch Story는 차이점(Diff)을 통해 추측하는 것이 아니라 팀이 실제로 기록한 결정들에 근거하여 그 서사를 재구성합니다. 이는 단순한 로그 덤프(Log dump)가 아니라 작업이 어떻게 진행되었는지에 대한 이야기로 읽힙니다. 로그 덤프는 그저 대충 훑어봐야 할 또 다른 자료일 뿐이며, 우리의 궁극적인 목적은 대충 훑어보는 행위 자체를 멈추는 것이기 때문입니다.

이것은 사람이 작성한 브랜치(branch)에도 작동하며, 이는 생각보다 더 중요한 의미를 갖습니다. 동료가 동료의 코드를 검토할 때도 동일한 서사(narrative)를 얻게 되므로, 리뷰는 인간의 작업과 에이전트(agent)의 작업이 서로 다른 두 가지 활동이 되는 대신 일관성을 유지하게 됩니다. 그리고 솔직히 말해서, 그러한 일관성은 팀이 에이전트에게 풀 리퀘스트(Pull Request)를 열도록 기꺼이 허용하게 만드는 핵심 요소 중 하나입니다. 에이전트 자율성의 걸림돌은 에이전트가 코드를 작성할 수 있느냐의 문제가 아니었습니다. 그것은 인간이 책임지고 승인(sign off)할 수 있느냐의 문제였습니다. 신뢰가 바로 그 잠금 해제 열쇠이며, 신뢰는 '왜(why)'를 빠르게 파악할 수 있는 능력에서 나옵니다.

이것이 하지 않는 것

한계를 솔직하게 말씀드리고 싶습니다. 과장해서 홍보하는 것 자체가 일종의 피해를 줄 수 있기 때문입니다. Branch Story는 여러분의 판단을 대체하지 않으며, 코드가 정확하다는 것을 인증하지도 않습니다. 대신 '왜'를 읽기 쉽게 만들어, 여러분의 판단이 느리고 추측에 의존하는 대신 빠르고 정확해지도록 돕습니다. 또한 이 도구의 성능은 그 뒤에 있는 컨텍스트(context)에 달려 있습니다. 만약 팀의 결정 사항이 어디에도 기록되어 있지 않다면, 재구성할 서사가 존재하지 않으며, 이것이 바로 기록(capture)하는 측면이 어려운 부분이자 제 작업의 대부분이 투입되는 지점입니다.

하지만 저는 이 방향이 옳다고 느낍니다. 스스로 복도에서 설명할 수 없는 무언가에 의해 작성되는 코드가 많아질수록, 희소한 자원은 코드가 아니며 리뷰 시간도 아닙니다. 그것은 바로 '읽기 쉬운 의도(legible intent)'입니다. 그것이 바로 구축할 가치가 있는 것입니다.

에이전트의 풀 리퀘스트를 검토할 때, 여러분은 그것을 읽고 있습니까, 아니면 단순히 승인하고 있습니까? 솔직해지십시오. 그 간극이 바로 문제의 핵심입니다.

decispher.com
VS code extension