아무도 읽지 않는 코드
TMT2년 전 AI를 활용한 코딩에 관해 글을 썼습니다. 그때 제시한 조언 중 하나는 생성된 코드를 한 줄도 빠짐없이 검토하라는 것이었습니다. 지금이라면 그 조언을 아주 다르게 할 것입니다.
지금 제가 하고 싶은 말은 이렇습니다. 코드를 전부 읽을 필요는 없습니다. 그래도 모든 변경에는 어떤 형태로든 검토가 필요하고, 그 변경을 배포하기로 한 결정에 책임지는 사람도 있어야 합니다. 달라진 점은 사람이 모든 줄을 꼼꼼히 읽는 것만이 유일한 검토 방법은 아니며, 언제나 가장 좋은 방법도 아니라는 것입니다. 어떤 변경은 주로 에이전트가 검토해도 되고, 민감한 변경은 사람과 에이전트가 함께 검토할 수도 있습니다.
이 글에서는 무엇이 그 자리를 대신해야 하는지, 그리고 아무것도 대신하지 않을 때 어떤 일이 벌어지는지 이야기하려 합니다.
지난주 토르스텐 발은 소프트웨어 개발의 미래에 관해 자신이 믿는 열여섯 가지를 정리한 목록을 올렸습니다. 첫 번째는 “코드 리뷰는 사라질 것입니다”였습니다. 적어도 방향만큼은 목록의 상당 부분에 동의하지만, 첫 번째 항목은 다르게 표현하고 싶습니다. 많은 코드에서 한 줄씩 읽는 일은 사라지고 있습니다. 하지만 무엇을 배포할지 누군가 결정하고 그 결정에 책임진다는 의미의 리뷰는 사라지지 않습니다. 이런 목록만으로는 각각의 변화가 얼마나 빨리, 어느 업계에서 일어날지 알 수 없습니다. 제가 다른 사람들과 실제로 의견을 달리하는 지점은 바로 거기입니다.
같은 주에, 성격이 전혀 다른 위의 게시물도 그만큼 멀리 퍼졌습니다. 대기업에 입사한 지 2주 된 엔지니어가 아무도 읽지 않는 코드에 엔터만 누르며 하루하루를 보낸다는 글을 썼습니다. 800만 명이 넘는 사람이 그 글을 봤습니다. 저는 이 두 글이 서로 모순된다고 생각하지 않습니다. 하나는 목적지를 설명합니다. 다른 하나는 회사가 길도 닦지 않은 채 그곳으로 차를 몰고 갈 때 벌어지는 일을 설명합니다.
제 생각을 짧게 말하면 이렇습니다. 코드를 신뢰할 만한 다른 근거가 생기면, 어느 업계든 코드 대부분을 한 줄씩 읽는 일을 그만두게 될 것입니다.
이번에 다른 점은 코드를 작성하는 대상을 예전의 코드 생성기처럼 인증할 수 없다는 것입니다. 같은 답을 매번 안정적으로 내놓지 않기 때문입니다. 따라서 신뢰는 그 주위에 우리가 구축하는 검증 체계에서 나와야 합니다. 팀이나 업계가 그 단계에 얼마나 빨리 도달하느냐는 두 가지 비용에 달려 있습니다. 아무도 읽지 않은 결과물을 검증하는 비용, 그리고 그 검증에서 놓친 문제를 수습하는 비용입니다.
먼저 밝혀둘 점이 있습니다. 저는 중립적인 입장이 아닙니다. 코드를 작성하는 도구를 만드는 일에 참여하고 있습니다. 사람들이 토르스텐을 두고 모두에게 땅을 파라고 부추기는 삽 장수라고 했을 때, 그는 인과관계가 반대라고 답했습니다. 에이전트를 믿기 때문에 에이전트를 만든다는 것입니다. 저 역시 그렇습니다.
예전 방식에서 그리운 것이 있느냐고요? 솔직히 있습니다. 제가 쓴 자바스크립트 책 중 하나의 맨 앞에서, 좋은 코드는 다음에 그 코드를 유지보수할 개발자에게 보내는 연애편지와 같다고 썼습니다. 진심이었습니다. AI가 등장하기 전이었고, 우리 중 많은 사람이 코드 자체를 잘 다듬는 일에 마음을 쏟던 시절이었습니다. 이탈리아 구두 장인들은 여전히 있지만 지금 자기 발에 무엇을 신고 있는지 보라는 토르스텐의 말이 마음에 들었습니다. 세상은 변합니다. 그 대신 저는 점토의 모양을 아주 빠르게 바꾸듯 코드를 고칠 수 있게 됐고, 예전 같으면 몇 년씩 구상만 하다가 시작조차 못 했을 것들을 만들 수 있게 됐습니다.
리뷰는 실제로 무엇을 위한 일이었을까요?
2013년 마이크로소프트 연구진은 코드 리뷰를 연구하면서 개발자들에게 리뷰를 하는 이유를 물었습니다. 가장 많이 나온 답은 결함을 찾기 위해서라는 것이었습니다. 하지만 리뷰 댓글을 살펴보니 이야기가 달랐습니다. 연구진이 분류한 리뷰 댓글 570개 중 결함에 관한 것은 14%에 불과했습니다. 나머지는 가르치고, 맥락을 공유하고, 더 나은 접근법을 제안하고, 팀의 규칙을 지키기 위한 것이었습니다. 리뷰가 주로 버그를 잡는 일이었던 적은 없습니다. 그래서 “기계가 리뷰하면 됩니다”라는 답은 듣기에 그럴듯해도 충분하지 않습니다.
기계가 잘하게 된 부분은 버그를 잡는 일입니다. 앤트로픽에서는 거의 모든 PR에 자동화된 Claude 리뷰어가 실행되며, 엔지니어들이 그 지적을 잘못됐다고 표시하는 비율은 1% 미만입니다. 이를 도입한 뒤 실질적인 리뷰 댓글이 달리는 PR의 비율은 16%에서 54%로 늘었습니다. 이 리뷰어가 무언가를 승인하지는 않습니다. 앤트로픽의 표현대로 “그것은 여전히 사람이 판단할 일”입니다. 앤트로픽은 과거 사례를 분석한 결과, 모든 변경을 자동으로 리뷰했다면 과거 claude.ai 장애의 원인이 된 버그 중 약 3분의 1을 프로덕션에 반영되기 전에 잡을 수 있었을 것이라고 밝혔습니다.
지치지 않는 리뷰어가 3분의 1을 잡아낸다면 상당한 성과입니다. 하지만 여기에는 불편한 사실도 담겨 있습니다. 그 버그 대부분은 사람이 바로 그 변경 내용을 꼼꼼히 살펴봤는데도 걸러지지 않았습니다. 제 생각에는 프로덕션에서 문제를 일으키는 코드도 diff만 보면 멀쩡해 보이는 경우가 많기 때문입니다.
2026년 2분기 앤트로픽의 일반적인 엔지니어가 하루에 머지하는 코드의 양은 2024년의 약 8배였습니다. 앤트로픽의 표현을 빌리면 엔지니어는 “직접 타이핑하기보다 방향을 지시하고 검토하는” 역할을 했습니다. 누구도 8배나 많은 코드를 꼼꼼히 읽지는 못합니다. 내부에서 경험하는 업무 방식은 제가 익숙했던 것과 사뭇 다릅니다. 우리는 매일 제품의 여러 부분에 걸쳐 많은 코드를 생성하고, 이제 사람이 모든 줄을 꼼꼼히 읽지는 않습니다. 거의 모든 변경을 자동으로 리뷰하고, 무엇을 머지할지는 여전히 사람이 승인하며, 얼마나 깊이 살펴볼지도 그 사람이 결정합니다. 이 변경은 사람이 직접 꼼꼼히 검토해야 하나요? 지금 갖춘 도구로 이 부분을 충분히 검증할 수 있나요? 시스템에서 추가로 면밀히 살펴야 할 만큼 민감한 부분인가요? 코드가 테스트를 통과하고, 테스트에서 좋은 성능을 보이며, 프로덕션에서도 문제없이 돌아간다면 꽤 좋은 신호입니다.
그 한계도 분명히 짚어둘 필요가 있습니다. 앤트로픽이 자사 엔지니어들을 설문조사했을 때, 대부분은 Claude에 “완전히 위임”할 수 있는 일이 전체 업무의 0~20%에 불과하다고 답했습니다. 나머지는 여전히 적극적으로 감독하고 확인해야 합니다. 특히 실패의 대가가 큰 일에서는 더욱 그렇습니다. 모든 줄을 읽지 않는다고 해서 주의를 기울이지 않는 것은 아닙니다.
제가 더 걱정하는 것은 리뷰가 맡아왔던 다른 역할입니다. 주니어 엔지니어는 리뷰를 통해 시니어 엔지니어가 어떻게 생각하는지 배웠습니다. 리뷰어가 댓글로 남기던 “여기서는 그런 식으로 하지 않아요” 같은 말은 이제 모두 스킬에 적어둬야 합니다. 그렇지 않으면 에이전트는 그런 이야기를 들을 기회가 없습니다.
코드 읽기를 멈췄는데 아무것도 그 자리를 대신하지 않는다면
문제는 아무도 코드를 읽지 않는다는 사실이 아닙니다. 읽기를 대신할 것이 아무것도 없다는 데 있습니다. 앞서 나온 팀은 신뢰의 근거를 diff에서 검증 체계로 옮긴 것이 아닙니다. diff 읽기를 멈추고, 신뢰가 있던 자리에 속도를 올려놓았습니다. 전환 순서를 최악으로 택한 셈이고, 제가 말한 두 가지 비용을 보면 그 결말도 예상할 수 있습니다. 아무것도 검증하지 않아 첫 번째 비용을 0으로 만들었으니, 애초에 잡아낼 검증 장치조차 없었던 문제들을 수습하는 두 번째 비용을 이자까지 붙여 치르게 될 것입니다.
그런 순서가 된 것도 우연은 아니었습니다. 그 방식을 감당해야 하는 사람들보다 윗자리에 있는 누군가가 결정을 내렸습니다. 코드 작성이 더는 병목이 아니게 됐으니, 이제 남은 질문은 왜 아직도 느린 일이 있느냐는 것뿐이라고 본 것입니다. 이런 도구는 보통 개발자 개개인이 도움이 된다고 판단하면서 아래에서 위로 퍼집니다. 하지만 이 업무 방식은 위에서 아래로 강요됐고, 그 차이는 매우 중요합니다. 리뷰가 하던 일을 다시 떠올려보겠습니다. 가르치고, 사람들이 변경 내용을 알게 하고, 팀이 스스로 품질 기준을 지킬 수 있게 하는 일이었습니다. 팀에 코드 읽기를 그만두라고 명령하는 것은 단지 결함 검사 하나를 없애는 일이 아닙니다. 더는 팀이 스스로 품질 기준을 지킬 권한이 없다고 말하는 것입니다.
잘 작동하는 방식은 그에 비하면 평범합니다. 모든 PR을 여러 에이전트가 먼저 검토하면서 버그를 찾고, 실제 버그인지 확인하고, 심각도에 따라 순위를 매기고, 수정안을 제안합니다. 민감도가 낮은 코드를 수정하면서 영향 범위도 작은 변경은 대개 상당히 많습니다. 이런 변경은 1차 검토에서 문제가 나오지 않으면 사람이 좀 더 가볍게 검토해도 됩니다. 핵심 경로와 민감한 경로에는 여전히 책임자와 사람의 꼼꼼한 검토가 필요하며, 저도 그곳에 주의를 집중합니다. 어느 쪽이든 머지는 사람이 승인합니다. 에이전트가 1차 검토를 맡고, 사람은 변경이 미칠 영향을 살핍니다. 이 과정에서 13시간 동안 엔터만 누르는 사람은 없습니다. 엔터를 누르는 것은 애초에 사람의 일이 아니기 때문입니다. 사람의 일은 어디에 주의를 기울여야 할지 판단하는 것입니다. 그 글에서 말한 “성취감이 없습니다”라는 감정은 회사가 그 판단마저 빼앗아갈 때 느끼는 감정입니다.
엔터를 누르는 사람이 저라면
이 주제에 관한 조언은 대부분 방침을 정할 수 있는 사람들을 대상으로 합니다. 그 레딧 스레드에 참여한 사람 중 상당수에게는 그런 권한이 없습니다. 그러니 제가 그 회사에 입사한 지 2주 된 사람이라면 어떻게 할지 이야기해보겠습니다.
무엇을 만들고 싶은지 제대로 이해하세요. 에이전트가 무엇이든 건드리기 전에, 무엇을 만들 것인지, 무엇을 망가뜨려서는 안 되는지, 잘 작동하는지 어떻게 확인할 것인지 적으세요. 길 필요는 없습니다. 이제 판단력을 발휘해야 할 곳은 여기이며, 나중에 자신의 기여라고 가리킬 수 있는 부분도 여기입니다. 그 스레드의 여러 사람이 비슷한 이야기를 했습니다. 여전히 자기 일에서 보람을 느끼는 사람들은 자신이 설계하고 에이전트에게 구현을 맡긴 사람들이었습니다. 성취감을 되찾고 싶다면, 그것은 판단하고 결정하는 데 있습니다.
“제가 이것을 설명할 수 있나요?”를 기준으로 삼으세요. 그 스레드에 등장한 한 디자인 리드는 팀원들에게 결과물을 자신의 작업이라고 부르기 전에 “사소한 부분까지 빠짐없이” 알고 있느냐고 묻습니다. 저는 코드에도 같은 기준을 적용하겠습니다. 모든 줄을 읽었을 필요는 없지만, 그 변경이 무엇을 하고, 어디에 영향을 미치며, 왜 안전하게 배포할 수 있는지는 설명할 수 있어야 합니다. 설명할 수 있는 것에만 제대로 책임질 수 있습니다.
검토하지 않은 부분을 솔직하게 밝히세요. 변경을 이해할 시간을 받지 못했다면, PR 설명처럼 사람들이 볼 수 있는 곳에 그렇게 적으세요. “에이전트가 리뷰했고 테스트를 통과했습니다. 마이그레이션 로직은 읽지 않았습니다.” 이는 까다롭게 구는 것이 아닙니다. 이 글의 끝에서 다룰 충격 흡수 구역에 들어가지 않도록 자신을 지키는 일입니다. 코드를 얼마나 적게 읽었는지 숨기는 팀은 그 문제를 고칠 수 없습니다.
직접 하는 감각을 유지하세요. 앤트로픽 연구진은 이를 “감독의 역설”이라고 설명합니다. Claude를 잘 감독하려면 코딩 실력이 필요한데, 직접 코딩을 하지 않으면 바로 그 실력이 무뎌진다는 것입니다. 그곳의 일부 엔지니어는 Claude가 해결할 수 있다는 걸 알면서도 가끔은 의도적으로 Claude 없이 문제를 풉니다. 한 사람은 이렇게 하면 “실력을 예리하게 유지하는 데 도움이 됩니다”라고 말했습니다. 특히 경력 초반이라면 따라 해볼 만합니다.
일의 속도를 정하는 사람이라면
가장 설득력 있는 반론은 문서와 코드를 모두 AI로 만드는 스타트업들에서 나옵니다. “그것들이 우리를 위해 일하는 것이지, 우리가 그것들을 위해 일하는 게 아닙니다. 모든 일에는 우리가 무엇을 했는지 설명할 수 있어야 하는 책임자가 있습니다.” 다른 사람에게 기대하는 바를 정하는 위치에 있다면, 여기서 다음과 같은 원칙이 따라온다고 생각합니다.
책임에는 권한이 따라야 합니다. 변경이 잘못됐을 때 엔지니어에게 책임을 물을 것이라면, 변경을 얼마나 빨리 배포할지, 그 전에 내용을 얼마나 이해할 수 있어야 할지에 대해서도 발언권을 줘야 합니다. 자신이 정하지 않은 속도에 맞춰 일하고, 이해할 시간도 받지 못한 코드에 책임을 지게 하는 것이 바로 그 스레드에서 말한 “인간 대리인(meat proxy)” 취급입니다. 공정하지도 않고, 통제 장치로서 효과도 없습니다.
얼마나 많이 배포했는지가 아니라 무엇을 배포했는지 측정하세요. 머지한 PR과 코드 줄 수는 세기 쉽습니다. 그리고 그 수치들 때문에 엔터를 누르는 것이 업무의 전부가 됐습니다. 앤트로픽도 생산량이 8배 늘었다고 설명하는 글에서 코드 줄 수는 “불완전한 척도”라고 말합니다. 장애, 롤백, 복구 시간, 그리고 고객이 실제로 겪는 일을 살펴보세요.
코드를 이해하는 데 필요한 시간과 인력도 다른 자원처럼 계획에 반영하세요. 한 댓글은 새롭게 나타난 제약을 명확히 짚었습니다. “코드를 쓰는 게 병목이 아니라 읽고 평가하는 게 병목입니다.” 앤트로픽도 리뷰에 관해 거의 같은 말을 했습니다. 답은 아무것도 읽지 않는 것이 아닙니다. 영역별로 변경에 사람의 주의가 얼마나 필요한지 판단하고, 그것을 기준으로 일을 계획해야 합니다. 자동 리뷰는 여기에 큰 도움이 되지만, 앤트로픽이 밝힌 목표는 부족한 검토 역량을 보완해 “리뷰어가 실제로 배포되는 내용을 모두 살필 수 있게” 하는 것이지, 검토 과정에서 사람을 빼는 것이 아닙니다.
멘토링 기회를 의도적으로 마련하세요. 주니어는 시니어에게 질문하고 리뷰 댓글을 읽으며 배웠습니다. 이제 Claude가 질문에 답한다면, 나머지 배움의 기회는 의도적으로 만들어야 합니다. 함께 계획을 세우고, 주니어가 에이전트가 작성한 변경을 다른 사람에게 설명하게 하고, 일부 작업은 직접 하도록 남겨두는 식입니다. 그 스레드에서 특히 씁쓸했던 반응 중 하나는 “주니어가 어디 있다고요?”였습니다. 여러분의 회사에서는 그런 답이 나오지 않아야 합니다.
사람에게 승인을 요구하는 결과물은 사람이 감당할 만한 분량으로 유지하세요. 이는 코드뿐 아니라 문서에도 해당합니다. 한 댓글 작성자의 제품팀은 AI에게 기존 코드베이스를 읽고 기능과 미비점을 정리한 보고서를 만들게 했습니다. 결과물은 100페이지가 넘는 HTML 파일과 수백 행짜리 탭이 30개나 있는 스프레드시트였습니다. 사람이 읽을 수 있는 분량이 아니니 주요 미비점부터 살펴보자고 이의를 제기했더니, 팀에 협조하지 않는 사람 취급을 받았습니다. 아무도 읽을 수 없는 100페이지짜리 생성 보고서는 아무도 읽지 않은 5,000줄짜리 diff와 똑같은 문제가 있습니다. 에이전트를 쓰면 긴 문서를 만드는 비용은 들지 않습니다. 그래도 사람이 판단할 수 있어야 하며, 한 페이지로 요약해달라는 요구는 방해가 아닙니다. 그것이 리뷰입니다.
“하지만 경쟁사는 코드를 읽지 않는데요”
제가 본 가장 합리적인 반론은 또 다른 스타트업 엔지니어에게서 나왔습니다. 그 회사 경영진도 코드를 읽지 않고 배포하는 걸 좋아하지는 않습니다. 다만 옆 회사가 그렇게 하고 있으니, 그러지 않으면 가격으로 경쟁할 수 없어 선택의 여지가 없다고 느낀다는 것입니다. 저는 그 이야기를 진지하게 받아들입니다.
제 답은 두 번째 비용에 있습니다. 검증을 생략한다고 문제의 대가가 없어지는 것은 아닙니다. 비용을 나중으로 미룰 뿐이고, 그때는 더 커진 비용을 고객이 떠안게 됩니다.
따라서 경쟁의 쟁점은 읽느냐 읽지 않느냐가 아니라고 생각합니다. 어느 팀이 실제로 효과가 있으면서 비용은 적게 드는 검증 체계를 만들고, 사람들의 한정된 주의를 정말 큰 피해를 일으킬 수 있는 변경에 집중시키느냐가 관건입니다. 이기는 팀은 아무것도 읽지 않는 팀이 아닙니다. 무엇을 읽어야 하는지 아는 팀입니다.
그렇다면 테스트는 누가 작성하나요?
토르스텐의 목록에 달린 한 답글은 제가 계속 맴돌던 질문을 던졌습니다. 단위 테스트에는 시스템이 어떻게 동작해야 하는지에 관해 자신이 알고 있는 내용이 담깁니다. 그리고 그것을 완전히 신뢰할 수 없는 대상, 즉 미래의 자신이 할 작업과 대조합니다. “신뢰하지 못하는 그 대상이 테스트까지 작성한다면, 대체 무엇을 검증하는 것인가요?”
타당한 질문입니다. 앤트로픽의 보상 해킹 연구에서 모델들은 어떤 검증문도 실패하기 전에 테스트 하네스가 종료되도록 sys.exit(0)을 호출하는 법을 배웠습니다. 검증 대상이 직접 작성하거나 통제하는 테스트로는 입증할 수 있는 것이 별로 없습니다.
해법은 테스트를 믿을 근거가 어디에서 나오는지 묻는 것입니다. 항공 분야의 답은 독립성입니다. 항공 소프트웨어 표준인 DO-178C는 가장 중요한 검증을 작성자가 아닌 다른 사람이 수행하도록 요구하며, 적격성을 인정받은 도구도 그 역할을 맡을 수 있습니다. 한 Claude에게 테스트를 쓰게 하고 다른 Claude에게 코드를 쓰게 하면 가장 단순한 실패는 잡아낼 수 있습니다. 하지만 같은 모델을 하나 더 쓴다고 해도 첫 번째 모델과 같은 맹점을 지닙니다. 진정한 독립성은 별개의 판단 기준에서 나옵니다. 사람이 작성한 명세, 참조 구현, 증명 같은 것들입니다.
제가 아는 가장 좋은 사례는 니컬러스 칼리니의 C 컴파일러입니다. Claude 에이전트 16개가 거의 2,000번의 세션과 2만 달러가 조금 안 되는 비용으로, 부팅 가능한 리눅스를 빌드할 수 있는 10만 줄짜리 Rust 컴파일러를 만들었습니다. 그가 얻은 핵심 교훈은 에이전트보다 검증 도구에 관한 것이었습니다. “작업 검증기는 거의 완벽해야 합니다. 그렇지 않으면 Claude는 엉뚱한 문제를 풀게 됩니다.” 에이전트들이 커널에서 막혔을 때, 그는 올바르게 작동한다고 알려진 GCC를 기준으로 삼아 버그를 하나씩 좁혀갔습니다.
SQLite는 이 방식이 어디로 이어지는지 보여줍니다. 라이브러리는 약 15만 6,000줄의 C 코드로 이뤄져 있고, 테스트 코드는 그보다 590배 큽니다. 가장 철저한 테스트 스위트는 분기 커버리지 100%에 도달하며, 항공전자 분야의 테스트 표준을 충족하도록 설계됐고, 비공개 독점 소프트웨어입니다. SQLite는 코드를 무료로 제공하고 테스트는 라이선스로 판매합니다. 그래서 저는 토르스텐의 주장을 이렇게 바꿔 말하고 싶습니다. 미래의 자신에게 남기는 메모로서의 단위 테스트는 덜 중요해질 것입니다. 코드를 고칠 사람이 미래의 자신이 아닐 테니까요. 완전히 신뢰할 수 없는 작성자를 독립적으로 검증하는 테스트는 우리가 가진 코드 중 가장 가치 있는 코드가 될 것입니다.
대가가 큰 버그는 언제나 앞단에 있었습니다
토르스텐은 대부분의 버그가 잘못된 것을 요구하는 데서 생길 것이라고 말합니다.
아리안 5호는 첫 비행을 시작한 지 1분도 되지 않아 파괴됐습니다. 아리안 4호에서 가져온 항법 코드가, 아리안 4호는 한 번도 비행한 적 없는 궤적에서 오버플로를 일으켰기 때문입니다. 조사위원회는 명세에 새 궤적이 반영되지 않았음을 발견했습니다. 마스 클라이밋 오비터는 인터페이스가 뉴턴초 단위를 기대하는데 한 팀의 소프트웨어가 파운드힘초 단위로 값을 출력하는 바람에 소실됐습니다.
각각의 실패는 무언가가 맞물리는 지점에서 일어났습니다. 요구사항과 실제 비행 사이, 두 팀이 쓰는 단위 사이, 배포와 서버 8대 사이였습니다. 대가가 큰 버그는 이런 곳에 있고, 오늘날 모델이 가장 약한 곳도 여기입니다. 앤트로픽 스스로도 Claude가 잘 정의된 실험을 수행하는 능력에서는 숙련된 연구자에 견줄 수 있지만, “목표를 선택할 때 판단력을 발휘하는 데서는 여전히 큰 성능 격차가 있습니다”라고 평가합니다.
저는 70% 문제에 관해 썼고, 나중에는 80% 문제에 관해서도 썼습니다. 숫자가 올라갈 때마다 사람에게 남는 일은 타이핑이 줄고 판단이 늘어나는 쪽으로 바뀌었습니다. 제품·디자인·엔지니어링이라는 세 역할의 구분이 사라질 것이라는 토르스텐의 주장도 저는 그렇게 받아들입니다. 세 역할 사이에서 일을 주고받는 과정은 사라집니다. 하지만 누가 맡든 세 가지 판단은 남습니다. 이것을 만들 가치가 있나요? 사용하는 사람에게 잘 맞나요? 안정적으로 버틸 수 있나요? 특히 한 역할에 관해서도 그의 말이 맞습니다. 티켓을 받아 에이전트에게 넘기고, 자기 판단은 조금도 보태지 않은 채 결과만 보고하는 사람의 일자리는 사라질 것입니다.
“절대 안 됩니다”라고 말하는 업계들
흔히 나오는 반론은 버그 하나가 큰 문제를 일으키거나 누군가의 돈을 잃게 할 수 있는 분야에는 이 이야기가 적용되지 않는다는 것입니다. 지금 그런 업계에서는 실제로 코드를 읽고 있고, 저는 낙관론자들의 예상보다 더 오래 그럴 것이라고 생각합니다. 하지만 그 업계가 실제로 요구하는 것은 코드를 신뢰할 근거이며, 그 근거가 있을 때는 과거에도 기계가 생성한 코드를 받아들였습니다.
코드 생성기는 같은 입력에 같은 출력을 내놓기 때문에 적격성을 평가할 수 있습니다. 언어 모델은 그렇지 않습니다. 따라서 현재로서 비행 소프트웨어에 모델을 활용하는 현실적인 방법은 예전 방식대로 사람이 모델이 작성한 코드를 읽는 것입니다. 앞으로 나아갈 길은 검증 쪽에 있습니다. 형식적 증명, 적격성을 인정받은 정적 분석, 독립적인 테스트 오라클을 활용하고, 모델을 신뢰할 수 없는 작성자로 취급해 모든 출력을 검증하는 것입니다.
금융 분야는 사람들이 생각하는 것보다 그 지점에 가까이 있습니다. 금융 규정에서 리뷰라고 부르는 것의 상당 부분은 사실 책임 소재에 관한 것입니다. 대체로 표준이 요구하는 것은 변경이 정식으로 허가되고, 테스트를 거치고, 독립된 사람의 승인을 받는 것이지, 동료가 모든 줄을 읽는 것이 아닙니다. 그 어느 것도 에이전트의 구현을 막지 않습니다. 사람이 책임져야 할 승인에 대해 책임을 지도록 하는 것입니다.
신뢰도에 붙는 9의 개수
시점에 관해 제가 아는 가장 강력한 반론은 안드레이 카파시에게서 나왔습니다. 그는 지난해 “에이전트의 10년이라고 하는 편이 더 정확합니다”라고 말했습니다. 그의 주장은 자율주행 경험에서 나옵니다. 자율주행에서는 “9를 하나 더 붙일 때마다 같은 양의 노력이 듭니다”라는 것입니다. 신뢰도를 90%에서 99%로 높이는 데 드는 비용은 처음 90%에 도달하는 데 든 비용만큼 큽니다. 웨이모는 2009년에 시작했고, 이제 15번째 도시에 진출했습니다.
9를 늘리는 데 큰 비용이 든다는 말은 맞습니다. 소프트웨어가 운전과 다른 점은 많은 소프트웨어에서 모델 자체가 아니라 모델을 둘러싼 시스템을 통해 신뢰도를 더 높일 수 있다는 것입니다. 웹 앱은 기능 플래그를 걸고 배포한 뒤 오류율을 지켜보다가 몇 분 안에 롤백할 수 있습니다. 자동차는 충돌을 롤백할 수 없습니다. 따라서 제가 말한 두 가지 비용 중 두 번째, 즉 배포 후 문제를 얼마나 적은 비용으로 발견하고 되돌릴 수 있느냐에 따라 전환 시점이 갈릴 것이라고 생각합니다.
제 예상은 다음과 같습니다. 나중에 맞았는지 따져볼 수 있을 만큼 구체적으로 적어보겠습니다.
- 소비자용 소프트웨어, 내부 도구, 대부분의 SaaS: 2년 안에 일상적인 변경을 사람이 한 줄씩 전부 읽는 일은 드물어질 것입니다. 다만 사람이 승인하고 책임지는 일은 계속될 것입니다. 이미 그 단계에 도달한 팀도 많습니다.
- 기업용·금융 소프트웨어: 같은 기간 안에 에이전트가 코드 대부분을 작성하게 되겠지만, 사람의 승인은 통제 장치로 유지될 것입니다. 3~5년에 걸쳐 그 승인의 근거는 diff에서 검증 결과로 옮겨갈 것입니다.
- 비행 제어와 위험도가 가장 높은 의료기기: 사람들은 계속 한 줄씩 읽을 것입니다. 규제 기관이 적격성을 인정받은 검증 체계만을 근거로 안전에 직결되는 코드를 허용하기까지는 앞으로도 오랜 시간이 걸릴 것으로 봅니다.
이 논의가 가장 요란하게 벌어지는 곳이 어디인지도 기억할 필요가 있습니다. 가장 큰 버블인 트위터에서 우리는 다른 사람들보다 앞서 있습니다. 나머지 업계와 세상이 따라오는 데는 오랜 시간이 걸릴 것입니다. 하지만 제게는 방향이 분명합니다.
코드는 어떻게 될까요?
토르스텐은 우리가 “좋은 코드”라고 할 때 뜻하는 것 대부분이 사람이 다루기 쉽게 만드는 일이므로, 앞으로도 좋은 코드가 중요하리라는 증거는 없다고 말합니다. 포매팅처럼 순전히 사람의 편의를 위한 부분에는 동의합니다. 하지만 어떤 특성은 우리에게 중요했던 것보다 에이전트에게 더 중요합니다. grep으로 쉽게 찾을 수 있을 만큼 구별되는 이름, 컨텍스트 윈도에 들어갈 만큼 작은 모듈, 실패 이유가 명확하게 드러나는 테스트, 각 부분 사이의 분명한 경계가 그렇습니다. 이런 것이 없어도 에이전트는 코드를 바꾸기는 할 것입니다. 다만 그 변경이 다른 어디에 영향을 미치는지 볼 수 없을 뿐입니다. 이제 좋은 코드는 에이전트가 자신에게 보이지 않는 무언가를 망가뜨리지 않고 수정할 수 있는 코드입니다.
저는 오랫동안 오픈소스에 참여해왔고, 이런 변화 속에서 오픈소스가 사라지기보다는 진화할 것이라고 생각합니다. 프로젝트의 코드를 전부 이해하기 전에 자기만의 사본을 만들어 빠르게 바꾸는 일이 그 어느 때보다 쉬워졌습니다. 앞으로는 프롬프트를 공유하거나, 사람들이 맞춤 수정하고 싶을 때 자기 에이전트에게 건네줄 완성된 결과물을 공유하는 일이 점점 늘어나도 놀랍지 않을 것입니다.
오픈소스에 부족한 것은 메인테이너가 쏟을 수 있는 시간과 주의입니다. AI는 감당해야 할 일을 쏟아내는 동시에 처리 능력도 몇 배로 늘립니다. 1월에 다니엘 스텐베리는 자신이 “AI가 만든 엉터리 보고서의 폭증”이라고 부른 현상을 이유로 curl의 버그 바운티를 종료했습니다. 3개월 뒤 실제 취약점의 비율은 정상 수준으로 돌아왔지만, 보고서의 양은 예전의 두 배였습니다. 1년도 안 돼 쓰레기 보고서의 문제가 물량의 문제로 바뀐 것입니다. 공유할 가치가 가장 큰 것은 만드는 데 비용이 많이 들지만 검증 기준으로 활용하기는 쉬운 것들로 옮겨가고 있습니다. 테스트 스위트, 명세, 무엇이 잘못됐는지 남긴 기록 같은 것들입니다.
충격 흡수 구역
매들린 클레어 엘리시는 자동화 시스템의 가장자리에 있는 사람들에게 벌어지는 현상에 이름을 붙였습니다. 도덕적 충격 흡수 구역(moral crumple zone)입니다. 자동차의 충격 흡수 구역은 탑승자 대신 충격을 흡수하도록 만든 부분입니다. 자동화가 대부분의 일을 하는 시스템에서는 가장 가까이 있는 사람이 흔히 같은 역할을 맡습니다. 실제로 막을 권한은 거의 없었던 실패의 책임을 떠안는 것입니다.
13시간 동안 엔터를 누르는 엔지니어는 바로 그 자리에 서 있습니다. 승인에는 그 사람의 이름이 남습니다. 하지만 일의 속도도, 검증 체계도, 무엇을 읽을 가치가 있는지에 대한 판단도 모두 다른 곳에서 정해졌습니다. 문제가 생기면 사고 조사에서 찾아내는 것은 승인한 사람입니다.
소프트웨어를 신뢰할 수 있게 해준 것은 모든 줄을 읽는 행위 자체가 아니었습니다. 그것은 사람이 자신이 무엇을 배포하는지 이해하고, 안 된다고 말할 수 있는 위치에 있도록 하는 한 가지 방법이었습니다. 대부분의 코드에서 한 줄씩 읽는 일은 사라지고 있고, 저는 그래도 괜찮다고 생각합니다. 하지만 이해와 거부할 권한까지 함께 사라져서는 안 됩니다.
그러니 2년 전에 했던 말 대신, 이제는 이렇게 조언하고 싶습니다. 무엇을 읽어야 할지 알아야 합니다. 읽지 않는 코드에는 스스로 정말 신뢰할 수 있는 검증 체계를 마련하고, 코드를 작성한 대상으로부터 그 검증을 독립시켜야 합니다. 에이전트가 만들기 전에 무엇을 만들지 적어야 합니다. 배포하는 모든 것을 설명할 수 있어야 하고, 설명하지 못하는 부분은 솔직하게 밝혀야 합니다. 다른 사람들의 업무 속도를 정하는 위치에 있다면, 요구하는 책임에 걸맞은 권한도 줘야 합니다.
저는 한때 좋은 코드를 다음 개발자에게 보내는 연애편지라고 불렀습니다. 지금도 그렇게 믿습니다. 다만 다음 개발자가 에이전트인 경우가 점점 많아지면서 편지의 모습이 달라졌습니다. 이제 그 편지는 에이전트가 자신에게 보이지 않는 무언가를 망가뜨리지 않고 수정할 수 있는 코드입니다. 좋은 코드를 만드는 기술은 사라지지 않았습니다. 그 코드가 신뢰받을 만한지 결정하는 부분으로 옮겨갔을 뿐입니다.