요약
Claude Code 팀은 코드 리뷰 대부분을 AI에 맡기고, 사람은 위험한 변경만 직접 승인합니다.
앤트로픽의 애디 오스마니 등 세 사람이 쓴 글입니다. 지금은 Claude Code 코드의 약 90%를 Claude가 씁니다. 사내 모노레포(여러 프로젝트를 한 저장소에 모은 구조)의 변경도 5월 하루 2,500건에서 9월 3만 건 넘게 늘었습니다. 그래서 리뷰 방식을 다시 짰다고 밝혔습니다.
왜 중요한가
- 에이전트가 쏟아내는 코드를 사람이 다 읽을 수 없다는 문제에, 리뷰를 없애지 않고 사람의 몫을 좁히는 답을 내놓았습니다.
- 목표는 되돌림(revert)과 장애가 늘지 않는 선에서 사람의 리뷰 시간을 가장 적게 쓰는 것입니다.
- 6~9월 병합된 PR은 두 배 넘게 늘었지만 되돌린 비율은 40% 넘게 줄었다며 이 방식의 근거로 들었습니다.
핵심 내용
- 분류기가 작성자가 아닌 변경 내용으로 위험도를 매기고, 그에 따라 사람 승인 수를 0명, 1명, 2명으로 정합니다.
- 문서나 플래그 뒤에 숨긴 기능은 자동 리뷰와 보안 검사만 통과하면 사람 승인 없이 병합합니다.
- AI 리뷰어의 지적은 별도 에이전트들이 투표로 검증하며, 실질적인 지적이 달린 사내 PR은 16%에서 54%로 늘었습니다.
- 과거에 장애나 되돌림을 일으킨 PR로 평가 세트를 만들어 리뷰어를 매일 채점합니다.
- 에이전트의 승인은 사람 승인으로 치지 않으며, 방향 결정과 결과에 대한 책임은 사람이 집니다.
HN 반응
- 하루 3만 건을 제대로 리뷰할 수 있느냐는 회의에, 대형 레거시 시스템도 원래 아무도 전체를 모른다는 반론이 맞섰습니다.
- 사람 확인 없는 병합이 SOC 2(보안 인증 기준) 요건과 맞느냐는 지적과, 글을 AI가 쓴 것 같다는 말도 나왔습니다.
앤트로픽 직원 대부분이 자기 일자리가 위태롭다고 믿는 것도 이상할 게 없네요. 기계가 직원들을 애완동물 취급하는 시스템을 이미 만들어 놨으니까요.
앤트로픽이 왜 이런 걸 굳이 설명하려 드는지 이해가 안 갑니다. 아마 그냥 갈아엎기(churn)를 반복하는 걸 텐데요? while 루프 하나 감싸는 TUI에 하루에 엄청난 양의 변경/PR이 몰린다고요? 환원주의적으로 굴고 싶지는 않으니 이쯤에서 접겠습니다. 여러 터미널 에뮬레이터를 다루는 건 분명 손이 가는 복잡한 일이라고 확신합니다(자체 렌더링 엔진을 만든 건 스스로 만든 문제라 해도요). 저도 하네스를 처음부터 바이브 코딩으로 만들어 봤습니다. 코드는 한 줄도 직접 안 썼지만 어떻게 돌아가는지는 압니다.
그리고 2번 항목을 실제로 다루기나 했는지도 잘 모르겠습니다. "시스템이 스스로 검증한다"는 말은 멋지지만, 자동화 테스트가 수십 년 전부터 해 온 일이잖아요. 게다가 시스템 전체가 어떻게 돌아가는지에 대한 멘탈 모델은 내팽개치고, 알아야 하거나 물어볼 일이 생길 때 LLM이 시스템의 일부만 골라 요약해 주는 쪽을 택했다고 합니다. 그런데... 그건 지식이 아니지 않나요? 그냥 구글식 검색이잖아요. 그러면 검색의 질이 곧 그때그때 끌어올릴 수 있는 지식의 질을 좌우한다는, 똑같은 문제에 걸리는 것 같은데요?
추신: 기사가 CC가 겪는 규모에 대해 모호하게 말하고 있어서, 저도 모호하게 쓰려고 "1000 PRs"를 "엄청난 양"으로 바꿨습니다.
이게 핵심입니다. 잠깐 멈춰서 생각해 보세요. 여기에는 소프트웨어에 대한 우리의 근본적인 신뢰 모델이 통째로 바뀌고 있다는 사실이 숨어 있습니다.
이 시스템이 망가졌을 때, 예를 들어 아무도 원인을 못 찾는 치명적인 버그가 생겼을 때 찾아갈 사람이 더는 없습니다. 천천히 체계적으로 디버깅할 때 기댈 수 있는 인과 모델이 누구의 머릿속에도 없습니다. 설계상 시스템이 그러기에는 너무 크고, 모든 것이 Claude 자신이 어떤 상황에서든 시스템의 알맞은 부분을 찾아내 이해할 수 있느냐에 달려 있으니까요. 이 아주 새로운 불변 조건이 유지되는 한 모든 게 괜찮을 겁니다. 이게 치명적으로 무너지면 복구할 방법이 없습니다. 이해할 가망이 전혀 없는 기술이 담긴, 회수한 외계 우주선을 가진 주인이 되는 겁니다.
새로운 신뢰 모델은 이렇습니다. Claude가 어떤 것이든 디버깅하고 우리가 원할 만한 합리적인 변경은 무엇이든 해낼 수 있을 만큼 언제나 시스템을 이해하리라고 믿는 것입니다. 얻는 것에 비하면 감수할 만한 위험일 수도 있습니다. 다만 우리가 어떤 거래를 하고 있는지는 분명하게 짚고 넘어갈 가치가 있습니다.
물론 대규모 레거시 시스템 중에는 이미 이런 식으로 돌아가는 것들이 많다(어느 정도는)는 점도 짚어야겠네요. "Claude"가 "올해 우연히 유지보수를 맡은 사람"으로 바뀐 것뿐이죠.
"물론 대규모 레거시 시스템 중에는 이미 이런 식으로 돌아가는 것들이 많다(어느 정도는)는 점도 짚어야겠네요. 'Claude'가 '올해 우연히 유지보수를 맡은 사람'으로 바뀐 것뿐이죠."
제가 보기에 진짜 차이는, 사람이 유지보수하던 옛날 방식의 시스템에서는 사람이 천천히 움직이면서 변경 사항을 제대로 이해했는지 확인한다는 점입니다. 풀어놓은 Claude는 "네, 어떻게 하는지 압니다"라고 말하고는 시스템을 망가뜨려 놓을 겁니다. 복잡함 앞에서 겸손해야 한다는 개념이 없으니까요!
그뿐만이 아닙니다. 사람이 설계하고 구현한 시스템이라면 적어도 누군가가 어느 시점에 책임질 수 있을 만큼 이해했을 정도로는 일관성이 있다는 걸 알 수 있습니다. LLM에는 그런 보장이 없습니다.
스타트업에서만 일해 보신 거죠?
대기업 코드베이스는 전혀 안 그렇습니다. 저는 60년 동안 쌓인 코드가 아직도 돌아가는 시스템(예: 은행)을 다뤄 봤어요. 어떻게 돌아가는지 아는 사람이 없습니다. 전체가 어떻게 돌아가는지 이해한 사람은 애초에 한 명도 없었고, 부품 상당수는 처음부터 함께 동작하도록 만든 것도 아니었습니다.
그런데 이게 정말 문제일까요? 테스트가 있고 Git으로 버전 관리를 한다면 변경 사항을 되돌리고 조사할 수 있잖아요.
애초에 그 말이 정말 맞는지도 모르겠습니다. 사람이 이해할 만큼 일관성이 없을 수는 있어요. 하지만 LLM이 썼다면 그 LLM이 이해할 거라고 (제 경험상) 99% 정도는 확신할 수 있고, 그것도 보통 코드를 쓰는 데 걸린 시간보다 짧게 걸립니다. 게다가 사람과 달리 LLM은 죽으면서 지식을 가져가지도, 회사를 옮기지도 않고, 설명해 달라고 해도 심술을 부리지 않습니다.
또 제 경험상 Claude는 부모 댓글이 말하는 것처럼 복잡한 문제에 무작정 뛰어들어 코드를 망가뜨리지 않습니다. 복잡함 앞에서 꽤 겸손해요. 큰 문제를 이해하기 쉬운 작은 문제로 쪼개자고 계속 권합니다.
그리고 무엇보다, 어느 정도 실력 있는 소프트웨어 엔지니어가 LLM으로 코드를 쓴다면 신중하게 쓸 겁니다. 중요한 코드를 쓸 때는 특히 그렇고요. LLM이 할 수 있는 일의 한계를 밀어붙이는 AI 연구자라면 모를까, 솔직히 대다수 프로그래머는 그렇지 않으니, LLM이 사람이 이해할 수 있는 코드를 쓰게 하고 그 설명도 어렵지 않게 들을 수 있는 경우가 거의 대부분입니다.
이건 정의에 기댄 주장인가요? 신중하지 않다면 실력 있는 엔지니어가 아닌 게 틀림없다는 식으로요? 저는 사람들이 LLM이 만든 코드에 신중할 거라고 믿을 이유를 못 찾겠습니다. 오히려 정반대예요. LGTM을 눌러 버리고 싶은 유혹이 엄청나거든요.
되돌릴 수야 있죠. 하지만 그 전에 이미 돌이킬 수 없는 피해가 생겼을 수도 있습니다. 제품이 LLM 래퍼라면 그럴 가능성이 낮겠지만, 데이터베이스 같은 거라면 치명적일 수 있습니다.
"누군가가 책임질 수 있을 만큼 이해했다"가 무슨 뜻인지 제대로 이해하고 계신지 잘 모르겠습니다. 저는 여기저기에 애드온이 하도 덕지덕지 붙어서 시스템 전체의 동작을 예측할 수 없고 겨우 대충 돌아가는 오래된 시스템을 분명 여러 번 봤습니다.
대부분의 대형 소프트웨어 회사는 이미 너무 커서 누구도 전체 멘탈 모델을 갖출 수 없습니다.
구글 같은 곳에서 누군가가 시스템 아키텍처의 절반이라도 머릿속에 담을 수 있다는 생각은 현실적이지 않아요. 어떤 상황에서든 시스템의 알맞은 부분을 찾아내 이해해야 한다는 점도 마찬가지고요.
하지만 그걸 쉽게 해 주는 온갖 안전장치가 우리에게 있습니다. 로그, 트레이스 같은 것들이요.
맞아요, 제가 마지막 문장에서 넌지시 말한 게 그겁니다.
말씀하신 형태의 도박이 수년 동안 있어 온 건 사실입니다. 그래도 저는 규모와 신뢰를 대하는 태도, 양쪽 모두에서 뭔가 새로운 걸 느낍니다. 그리고 사람이 만든 그 거대하고 이해할 수 없는 시스템들도 저는 똑같이 무섭습니다.
이번 10년 내내 현실 세계의 상황과 긴밀하게 맞물리는, 엄청나게 복잡한 소비자용 앱 하나를 계속 맡아 온 입장에서 말씀드리면, 응집성 문제는 에이전트 혁명 이전에도 이미 있었습니다. 좋은 설계 결정을 내릴 만큼 시스템(온라인과 오프라인, 현실 세계에서의 상호작용 전부)을 충분히 이해하지 못한 근시안적인 팀들이 만든 기능이 엄청나게 많았죠. AI는 어떤 사람보다 깊이 읽고 분석할 수 있어서 여기서 실제로 도움이 됩니다. 하지만 그만큼 응집성 없는 기능을 제멋대로 훨씬 많이 만들어 낼 위험도 있습니다.
지금까지는 결국 의사 결정자의 좋은 판단력이 병목이라는 점에서 똑같은 결론이 난다고 느낍니다. 그러면 이렇게 말씀하실 수도 있어요. 아니다, 경영진은 할 수 있다는 이유만으로, 그리고 빠르게 움직이는 것처럼 보인다는 이유로 복잡성을 더 늘리라고 점점 더 압박할 거라고요. 하지만 현실 세계의 앱에는 최후의 방어선이 있습니다. 너무 복잡하고 알아보기 힘든 것은 결국 사람의 문제를 풀기에 맞지 않게 된다는 거죠.
Claude Code 같은 범용 AI 도구는 그렇지 않습니다. 사실상 무제한의 자원으로 그때그때 가장 먹음직스러운 다음 먹잇감을 쫓는 것 말고는, 사용 사례나 대상 사용자에 아무 제약도 두지 않고 모든 종류의 지식 노동에 맞춰 최적화하려는 도구니까요. 소프트웨어의 99%는 그렇지 않고, 먼지가 가라앉고 나면 소프트웨어는 지금 종말론자나 맹신론자(maxxer)들이 예측하는 것만큼 달라지지는 않을 거라고 봅니다.
고맙습니다! 저도 이 부분에서 크게 걸렸습니다. 코드를 직접 겪어 보지 않고는 코드를 안다고 할 수 없어요. 하다못해 테스트가 정말 생각한 대로 검증하는지 알려면 테스트를 읽어 봐야 합니다. 그렇게 해도 원하는 대로 동작한다는 건 알 수 있을지 몰라도, 하지 말아야 할 짓을 하지 않는다는 건 알 수 없습니다.
진짜 이해에는 지름길이 없습니다.
또 그 말이냐고 한숨 쉬실 분들도 있겠지만, "역(逆)켄타우로스"입니다. 켄타우로스는 두 존재가 시너지를 내며 결합한 것인데, 이제는 그 둘이 엉뚱한 자리에 있는 겁니다. 사람이 컴퓨터의 도구가 된 거죠.
물론 이게 얼마나 "잘못"인지는 실제로 일을 다 하는 사람에게 묻느냐, 컴퓨터 자본을 다 가진 사람에게 묻느냐에 따라 달라지기 마련입니다.
며칠 전에 어떤 사람이 (다른 블로그 글이 잘 쓰였다는 얘기에 답하면서) 앤트로픽 직원들은 글쓰기나 대외 커뮤니케이션에 AI를 쓰지 못하게 하는 규칙이 있다고 하더군요. 이 글은 분명 그렇지 않아 보입니다. 보통 사람은 이렇게 안 써요.
백 퍼센트 동감입니다. 다만 사람이 상호작용의 90%를 로봇과 하게 되면 기계 세계의 말버릇과 관용 표현이 슬슬 옮을 수도 있겠죠. 일종의 로봇 피진 같은 거요.
맞아요. 그러면 뭐가 AI가 쓴 글이고 뭐가 아닌지 가려내기가 더 어려워지겠네요.
읽는 내내 묘한 기분이었습니다. 가끔 잘 쓴 문장과 논리가 이어지는 문단이 나오다가, 다시 Claude 특유의 말투로 돌아가더라고요.
언어를 읽고 쓰는 일에 그 정도로 계속 노출되고 푹 빠져 있으면 자기도 물들게 된다고 생각합니다. 그래서 앤트로픽 사람이 직접 썼다는 말도 충분히 믿을 수 있어요.
앤트로픽의 모델은 놀랍습니다. 하지만 소프트웨어 관행에 대해서는 이제 그만 떠들었으면 좋겠어요. 이들이 하는 말 대부분이 실제 소프트웨어 현장에서 벌어지는 일과 동떨어져 보입니다. 상당 부분이 과대광고에 끌려가는 얘기 같고요. 게다가 글 전체가 AI가 쓴 것처럼 보입니다.
비율은 그렇게 계산하는 게 아니죠.
하루 PR 3만 개를 사람이 따라갈 수는 없습니다... 무슨 일이 벌어지는지 통제하지 못하고 AI 자체에 일을 맡길 수밖에 없죠.
추신: 여기서 코드 갈아엎기(churn) 비율과 (코드 한 줄당 비용이) 어느 정도인지 정말 알고 싶습니다. 제 감으로는 LOC당 비용이 어마어마하고, 사실상 같은 코드를 계속 다시 쓰고 있을 것 같아요.
그런데 PR 3만 개라는 수치는 의미가 없어서 거기서 뭘 읽어낼 수가 없어요. 그 저장소에 뭐가 들어 있느냐에 전적으로 달렸으니까요. 현지화 문자열이나 설정처럼 자주 바뀌는 걸 추가하면 이런 숫자쯤은 자릿수 단위로 쉽게 움직입니다. PR 크기는 얼마나 되나요? 어쩌면 코드베이스를 돌아다니며 하루에 수천 건씩 한 줄짜리 수정을 하는 버그 자동 수정 에이전트가 있을지도 모르죠. 누가 알겠어요. 그 숫자만 따로 떼어 놓으면 아무 의미도 없습니다. 예전에는 엔지니어의 성과를 코드 줄 수로 재는 나쁜 관리자들을 비웃었는데, 이제 같은 수치로 AI를 평가하고 있네요. 우리가 나쁜 관리자가 된 겁니다.
기사에 "작성자일 수도 있는 사람 한 명 이하만 루프에 두고 머지한다"는 말이 있습니다. 이게 기업 컴플라이언스 요건과 내부자 위협을 어떻게 감당하는지 궁금하네요?
이게 어떻게 SOC2 컴플라이언스 승인을 받았을까요? 저희 SOC2 심사관은 모든 코드가 프로덕션에 나가기 전에 최소한 다른 사람 한 명이 리뷰해야 한다고 분명히 말했습니다. Claude Code는 SOC2를 준수한다고 하고요( https://code.claude.com/docs/en/security ).
이건 모든 엔지니어가 악의적인 짓을 하지 않는다고 가정하는 구조입니다. Claude 엔지니어가 악성 코드를 밀어 넣어서 전 애인이나 다른 회사의 Claude 검색 내용을 몰래 들여다보는 걸 뭐가 막나요? 얼마 전에는 OpenAI 엔지니어가 자기 사무실에 녹음 장치를 설치하다 붙잡히기도 했잖아요.
분명 준수하지 않을 겁니다. 저희도 SOC2에서 똑같은 요건이 있거든요. 하지만 감사는 꽤 느슨하고, 충분히 큰 회사라면 그런 건 눈감아 주는 감사인을 둘 여력이 있습니다.
LLM이 문서를 쓰게 하고 읽어보지도 않는다니, 어떻게 그럴 수가 있는지 정말 제정신이 아닙니다.
하루 커밋이 3만 개라면, 그걸 의미 있게 리뷰라고 부를 수 있는 게 있기는 한가요?
저는 여기서 대량 생산 제조업을 예로 떠올립니다. "How it is made" 같은 유튜브 영상을 좋아하거든요. 생산 라인에 카메라와 자동화 시스템이 빠른 속도로 표본 검사를 하고, 엄청난 액추에이터들이 불량품을 쳐내는 식의 QA 과정이 있죠. 이런 과정에는 통계적 표본을 뽑아 꼼꼼히 들여다보는 표본 검사도 함께 들어가는 경우가 많고요.
코드에서는 아직 그 정도로 신뢰할 만한 리뷰에 도달하지 못했다고 생각하지만, 그 방향으로 계속 나아가지 못할 이유는 안 보입니다.
저도 그런 영상을 정말 좋아하지만, 아주 큰 차이가 있습니다. 제조업 QA에서는 시스템이 극히 적은 종류의 제품을 아주 많은 수로 찍어냅니다. 그래서 출력의 분산에 알려진 상한이 있으니 운용 과학 관점에서 표본 검사가 잘 통하죠.
코드는 반대 방향으로 간다고 생각합니다. 시스템이 내놓는 산출물이 전부 서로 다릅니다(이제는 소프트웨어를 물리적인 복제본으로 배포하지 않으니 더욱 그렇죠. 물론 비트도 늘 물리적이긴 하지만, 플로피나 CD, DVD에 담아 출하하지 않는다는 뜻입니다).
그렇긴 해도 제 경험상 코드 리뷰가 공장 라인식 QA의 직접적인 일부였던 적은 없습니다. 그런 QA는 보통 소프트웨어를 블랙박스로 취급해서 스펙(흔히 아주 느슨한 의미의 "스펙"이죠...)을 만족하는지만 확인하고, 이는 사람이 썼든 기계가 썼든 똑같이 잘 통합니다. 코드 리뷰가 (다른 것들과 함께) 하는 QA는 예를 들어 소프트웨어의 설계가 유지보수와 확장을 경제적으로 감당할 수 있는 구조인지를 보는 것입니다.
코드 리뷰가 맡는 부분 가운데 (오류가 전혀 없는 건 결코 아니지만) 블랙박스 테스트로는 할 수 없거나 훨씬 어려운 게 백도어 같은 것을 찾는 일입니다. 우리 업계가 "에이전트가 소프트웨어를 쓰고 테스트가 그게 동작하는지 검증한다"는 쪽으로 더 나아갈수록, 저는 "Reflections on Trusting Trust"와, 사람들이 자기 대신 출하되는 코드를 더는 읽지 않아서 새로 생기는 넓은 공격 표면을 자주 생각합니다.
그건 범주 오류입니다. 소프트웨어는 같은 부품을 계속 찍어내는 게 아니에요. 그랬다면 리뷰는 간단했겠죠. 비유는 종종 오해를 부릅니다.
물론 앤트로픽은 여러분이 그런 미래로 가고 있다고 생각해 주길 바랄 겁니다. 이들의 생계가 LLM이 노동의 미래이고 하루 3만 건의 변경이 정상이라는 데 달려 있다는 점을 염두에 둬야 합니다.
그런데 하나의 제품에 하루 3만 건의 변경을 왜 원해야 하죠? 그럴 만한 정당한 이유가 도대체 뭐가 있을 수 있나요?