AI가 생성한 코드 시대에 코드 리뷰, 책임, 독립적인 검증이 어떻게 바뀌어야 하는지에 대한 글.
2년 전 나는 AI 지원 코딩에 관한 에세이를 썼고, 내 조언 중 하나는 생성된 코드의 모든 줄을 검토하라는 것이었다. 오늘이라면 그 조언을 아주 다르게 하겠다.
지금 내가 말할 내용은 이렇다. 모든 코드를 읽을 필요는 없다. 모든 변경에는 여전히 어떤 형태로든 검토가 필요하고, 이를 배포하기로 한 결정을 책임지는 사람도 여전히 필요하다. 달라진 점은 모든 줄을 사람이 주의 깊게 읽는 것이 더는 그 검토를 제공하는 유일한 방법이 아니며, 언제나 최선의 방법도 아니라는 것이다. 민감한 경우에는 주로 에이전트가 검토하거나 사람과 에이전트가 함께 검토할 수 있다.
Teleport은 한 분기 만에 2년치 보안 버그를 찾아냈다. 엔지니어 13명, 최첨단 모델, 자체 코드베이스로 이전 2년 전체의 거의 두 배에 달하는 고위험 취약점을 발견했다. 내가 관심을 두는 것은 이것이 대기열에 미치는 영향이다. 발견 비용은 몇 배나 낮아졌다. 하지만 분류 작업은 그렇지 않았고, 실제로 악용 가능한지 확인하는 일은 여전히 사람이 코드를 읽어야 한다. 고칠 수 있는 속도보다 더 빨리 찾아내면, 알 수 없던 백로그를 알려진 백로그로 바꾼 셈이다. 자신의 코드베이스에 이를 시도하기 전에 읽어볼 만하다. 분석 글 읽기 → https://fandf.co/4r3xdeX · Teleport 후원. #ad
이 글은 내 생각에 무엇이 이를 대체해야 하는지, 그리고 아무것도 대체하지 않을 때 어떤 일이 생기는지에 관한 글이다.
지난주 Thorsten Ball은 소프트웨어 개발의 미래에 대해 자신이 믿는 열여섯 가지 목록을 올렸다. 첫 번째는 “코드 리뷰는 죽을 것이다”였다. 적어도 방향성에 있어서는 목록의 많은 부분에 동의하지만, 첫 번째 항목은 다르게 표현하겠다. 많은 코드에서 줄 단위 읽기는 사라지고 있다. 누군가가 무엇을 배포할지 결정하고 그 결과에 책임지는 것을 뜻하는 리뷰는 사라지지 않는다. 그의 목록이 말해 줄 수 없는 것은 각 항목이 얼마나 빨리 도래할지, 또는 업계의 어느 부분에서 도래할지다. 바로 그 지점에서 나는 사람들과 실제로 의견이 다르다.
같은 주에, 아주 다른 글 ^도 똑같이 멀리 나아갔다. 대기업에서 새 직장을 시작한 지 2주 된 한 엔지니어가 아무도 읽지 않는 코드에서 하루 종일 엔터를 누르며 보낸 일을 썼다. 800만 명이 넘는 사람이 보았다. 나는 이 두 글이 서로 모순된다고 생각하지 않는다. 하나는 목적지를 묘사한다. 다른 하나는 회사가 길을 만들지 않고 그곳으로 달려갈 때 벌어지는 일을 묘사한다.
짧게 말하자면 내 관점은 이렇다. 모든 업계는 그 코드를 신뢰할 만한 다른 좋은 이유를 갖게 되면 대부분의 코드를 줄마다 읽는 일을 멈출 것이다.
이번에 다른 점은, 코드를 작성하는 대상이 예전 코드 생성기처럼 인증될 수 없다는 것이다. 매번 동일한 답을 안정적으로 내놓지 않기 때문이다. 따라서 신뢰는 그 주변에 구축하는 검사에서 나와야 한다. 팀이나 업계가 그 지점에 도달하는 속도는 두 비용에 달려 있다. 아무도 읽지 않은 작업을 검사하는 비용과, 검사가 놓친 실패를 되돌리는 비용이다.
처음부터 말하자면 나는 중립적이지 않다. 나는 코드를 작성하는 도구를 만드는 일을 돕는다. 사람들이 Thorsten을 모두에게 땅을 파라고 말하는 삽 판매자라고 부르자, 그는 인과관계가 반대라고 말했다. 자신이 에이전트를 만드는 이유는 그것을 믿기 때문이다. 나도 마찬가지다.
예전 방식에서 그리운 것이 있느냐고? 솔직히 말하면 있다. 내 JavaScript 책 중 하나의 맨 처음에 나는 좋은 코드는 다음에 유지보수해야 하는 개발자에게 보내는 사랑의 편지와 같다고 썼다. 진심이었다. 그것은 AI 이전의 일이었고, 우리 중 많은 사람이 코드 자체의 장인정신을 아꼈다. 나는 아직도 이탈리아 구두 장인은 남아 있지만 자기 발을 보라는 Thorsten의 말을 좋아했다. 세상은 변한다. 그 대가로 나는 점토를 매우 빠르게 빚고, 아니면 시작조차 하지 않은 채 몇 년 동안만 굴렸을 것들을 만들 수 있게 되었다.
2013년 Microsoft 연구자들은 코드 리뷰를 연구하며 개발자들에게 왜 그것을 하는지 물었다. 결함 찾기가 가장 많은 답이었다. 하지만 댓글은 다른 이야기를 들려주었다. 연구자들이 분류한 570개의 리뷰 댓글 가운데 결함에 관한 것은 14%뿐이었다. 나머지는 가르치기, 맥락 공유, 더 나은 접근법 제안, 팀 규범 유지에 관한 것이었다. 리뷰는 처음부터 대부분 버그에 관한 일이 아니었다. 그래서 “기계가 리뷰할 것이다”라는 답은 들리는 것보다 약하다.
버그를 잡는 일은 기계가 잘하게 되고 있는 부분이다. Anthropic에서는 자동화된 Claude 리뷰어가 거의 모든 PR에서 실행되고, 엔지니어들은 그 발견 사항 중 1% 미만만 잘못되었다고 표시한다. 시작 이후 실질적인 리뷰 댓글을 받는 PR의 비율은 16%에서 54%로 올랐다. 이것은 아무것도 승인하지 않는다. Anthropic의 표현을 빌리면 “그것은 여전히 사람의 판단이다.” 회고적 분석에서 Anthropic은 모든 변경에 자동화된 리뷰를 적용했다면 claude.ai에서 과거 사고를 일으킨 버그의 대략 3분의 1을 프로덕션에 도달하기 전에 잡을 수 있었을 것이라고 밝혔다.
지치지 않는 리뷰어에게 3분의 1은 많다. 하지만 불편한 사실도 말해 준다. 그 버그 대부분은 변경 사항을 바로 보고 있던 신중한 사람들을 통과했다. 내 추측으로는 프로덕션에서 실패하는 코드는 흔히 diff에서는 멀쩡해 보이기 때문이다.
2026년 2분기, 일반적인 Anthropic 엔지니어는 2024년보다 하루에 약 8배 많은 코드를 병합하고 있었으며, Anthropic의 표현대로 엔지니어는 “타이핑하는 대신 지시하고 리뷰하고” 있었다. 아무도 8배 많은 코드를 주의 깊게 읽지 않는다. 내부에서 우리가 일하는 방식은 내가 익숙했던 것과 매우 다르게 느껴진다. 우리는 많은 제품 영역에서 매일 많은 코드를 생성하며, 이제 모든 줄을 사람이 주의 깊게 읽지는 않는다. 거의 모든 변경은 자동 리뷰를 받고, 사람은 여전히 병합을 승인하며, 얼마나 깊이 살필지는 그 사람이 결정한다. 이 변경에는 신중한 수동 리뷰가 필요한가? 여기서 우리 도구는 충분히 좋은가? 시스템의 충분히 민감한 부분이어서 추가적인 검토가 필요한가? 코드가 테스트를 통과하고, 테스트에서 잘 수행되며, 프로덕션에서도 문제없이 실행된다면 그것은 꽤 좋은 신호다.
그 한계도 분명히 해둘 필요가 있다. Anthropic이 자사 엔지니어를 조사했을 때, 대부분은 업무의 0~20%만 Claude에게 “완전히 위임”할 수 있다고 답했다. 나머지는, 특히 고위험 업무에서 여전히 적극적인 감독과 검사가 필요하다. 모든 줄을 읽지 않는다는 것은 주의를 기울이지 않는다는 뜻이 아니다.
내가 더 걱정하는 것은 리뷰가 하던 다른 일들이다. 리뷰는 주니어 엔지니어가 시니어 엔지니어의 사고방식을 배우는 방법이었다. 리뷰어가 예전에 댓글로 말하던 것, 예컨대 “여기서는 그렇게 하지 않는다”는 이제 스킬에 기록되어야 한다. 그렇지 않으면 에이전트는 절대 듣지 못한다.
문제는 아무도 코드를 읽지 않는다는 것이 아니다. 읽기를 대체한 것이 없다는 점이다. 앞서의 팀은 신뢰를 diff에서 검사로 옮기지 않았다. diff 읽기를 멈추고, 신뢰가 있던 자리에 속도를 놓았다. 그들은 최악의 순서로 전환했고, 내 두 비용은 그 결말을 예측한다. 아예 검사하지 않음으로써 첫 번째 비용을 0으로 만들었으니, 존재하지 않았던 검사가 잡을 수 없었던 실패를 되돌리는 두 번째 비용을 이자까지 붙여 치르게 될 것이다.
그 순서 역시 우연이 아니었다. 그 상황을 살아가는 사람들 위의 누군가가 결정을 내렸다. 코드 작성이 병목이 아니게 되자, 남은 유일한 질문은 왜 무엇이든 여전히 느리냐는 것이었다. 이런 도구는 대개 개별 개발자가 도움이 된다고 판단하면서 아래에서 위로 퍼진다. 이 일하는 방식은 위에서 아래로 부과되었고, 그 차이는 아주 중요하다. 리뷰가 무엇을 하고 있었는지 다시 생각해 보라. 가르치고, 사람들에게 변경 사항을 인식하게 하며, 팀이 자체 품질 기준을 지키게 했다. 팀에게 읽기를 멈추라고 명령하면 결함 검사를 하나 없애는 데 그치지 않는다. 그 기준은 더 이상 팀이 지킬 것이 아니라고 말하는 셈이다.
작동하는 버전은 이에 비하면 지루하다. 모든 PR은 버그를 찾고, 검증하고, 심각도별로 순위를 매기며, 수정을 제안하는 다중 에이전트의 첫 번째 검토를 받는다. 덜 민감한 코드에서 영향 반경이 작은 변경은 대개 많으며, 그 첫 검토가 깨끗하게 돌아오면 더 가벼운 사람의 검토를 받을 수 있다. 핵심 및 민감 경로에는 여전히 책임자와 신중한 사람의 리뷰가 필요하고, 나는 거기에 주의를 쏟는다. 어느 쪽이든 사람은 병합을 승인한다. 에이전트는 첫 검토를 하고, 사람은 영향 반경을 담당한다. 그 과정에서 누구도 13시간 동안 엔터를 누르지 않는다. 엔터를 누르는 일은 처음부터 사람의 일이 아니었기 때문이다. 일은 무엇이 주의를 받을 가치가 있는지 결정하는 것이다. 그 글에서 말한 “승리감의 부재”는 회사가 그 결정마저 당신에게서 빼앗을 때의 느낌이다.
이 주제에 관한 조언 대부분은 정책을 정할 수 있는 사람들을 위해 쓰인다. 그 Reddit 스레드에 있는 많은 사람은 그렇지 않다. 그러니 내가 그 직장에 들어간 지 2주 되었다면 할 일을 말해 보겠다.
만들고자 하는 것을 정말로 이해하라. 에이전트가 무엇이든 건드리기 전에, 무엇을 만드는지, 무엇을 망가뜨리면 안 되는지, 어떻게 성공을 알 수 있는지 적어라. 길 필요는 없다. 이제 그곳에 당신의 판단이 들어가며, 나중에 가리킬 수 있는 업무의 부분이기도 하다. 스레드의 여러 사람도 같은 취지로 말했다. 여전히 자신의 일에 만족하는 사람들은 대상을 설계하고 에이전트에게 만들게 했다. 승리감을 되찾고 싶다면, 그것은 결정 속에 있다.
“이것을 설명할 수 있는가?”를 기준으로 써라. 스레드의 한 디자인 리드는 팀에게 업무를 자기 일이라고 부르기 전에 “개 털 한 올 한 올까지” 아는지 묻는다. 나는 코드에도 같은 기준을 적용하겠다. 모든 줄을 읽었을 필요는 없지만, 변경이 무엇을 하는지, 무엇에 닿는지, 왜 안전하게 배포할 수 있는지는 설명할 수 있어야 한다. 설명할 수 있는 것에 대해서만 진정으로 책임질 수 있다.
검토하지 않은 것을 솔직히 밝혀라. 변경을 이해할 시간을 받지 못했다면 PR 설명처럼 사람들이 볼 수 있는 곳에 밝혀라. “에이전트 검토 완료, 테스트 통과, 마이그레이션 로직은 읽지 않았습니다.” 이것은 까다롭게 구는 일이 아니다. 글 마지막에 설명할 도덕적 완충 지대에서 당신을 지켜 주는 일이다. 자신들이 얼마나 적게 읽었는지 숨기는 팀은 그것을 고칠 수 없다.
직접 계속 해보라. Anthropic 연구자들은 “감독의 역설”을 설명한다. Claude를 잘 감독하려면, 전혀 사용하지 않으면 퇴화하는 바로 그 코딩 기술이 필요하다. 그곳의 일부 엔지니어는 Claude가 처리할 수 있음을 알면서도 때때로 일부러 Claude 없이 문제를 푼다. 한 사람은 그것이 “스스로를 날카롭게 유지하는 데 도움이 된다”고 말했다. 특히 커리어 초반이라면 따라 할 가치가 있다.
가장 좋은 반론은 모든 문서와 코드가 AI로 만들어진 스타트업들에서 나온다. “그들이 우리를 위해 일하지, 우리가 그들을 위해 일하는 것이 아닙니다. 우리가 한 일을 설명할 수 있어야 하는 책임자가 모든 항목에 있습니다.” 기대치를 정하는 사람이라면, 여기서 다음과 같은 결론이 나온다고 생각한다.
책임에는 권한이 필요하다. 변경이 실패했을 때 비난받을 엔지니어라면 변경을 얼마나 빨리 내보낼지, 먼저 얼마나 이해할 수 있을지에 대해 발언권이 필요하다. 설정하지 않은 속도와 이해할 시간을 받지 못한 코드에 대해 누군가에게 책임을 묻는 것은, 스레드가 “고기 대리인”이라고 부른 바로 그것이다. 공정하지도 않고, 통제 수단으로 작동하지도 않는다.
얼마나 많이가 아니라 무엇을 배포했는지 측정하라. 병합된 PR과 코드 줄 수는 세기 쉽고, 엔터 누르기를 직업의 전부로 만든 숫자들이다. Anthropic의 8배 산출량에 관한 글조차 코드 줄 수를 “불완전한 척도”라고 부른다. 사고, 롤백, 복구 시간, 고객이 실제로 겪는 일을 보라.
다른 역량처럼 이해를 위한 예산을 잡아라. 한 댓글 작성자는 새로운 제약을 명료하게 말했다. “코드 작성은 병목이 아니지만, 읽고 평가하는 일은 그렇다.” Anthropic도 리뷰에 관해 거의 같은 말을 했다. 답은 아무것도 읽지 않는 것이 아니다. 영역별로 변경에 얼마만큼의 사람의 주의가 필요한지 결정하고, 그에 맞춰 업무를 계획하는 것이다. 자동화된 리뷰는 여기에서 큰 도움이 되지만, Anthropic이 밝힌 목표는 리뷰어가 “실제로 배포되는 것을 다룰 수 있도록” 격차를 좁히는 것이지 리뷰어를 과정에서 빼는 것이 아니다.
의도적으로 멘토링할 자리를 만들어라. 주니어는 시니어에게 질문하고 그들의 리뷰 댓글을 읽으며 배웠다. 이제 Claude가 질문에 답한다면 나머지는 의도적으로 만들어야 한다. 계획을 함께 세우고, 주니어가 에이전트가 쓴 변경을 누군가에게 다시 설명하게 하며, 일부 작업은 수동으로 남겨 두어야 한다. “주니어가 어디 있나요?”는 그 스레드에서 나온 더 암울한 답변 중 하나였다. 당신의 회사에서 그것이 답이 되어서는 안 된다.
사람들에게 승인하라고 요구하는 것을 사람이 다룰 수 있는 크기로 유지하라. 이는 코드만큼 문서에도 적용된다. 한 댓글 작성자의 제품 팀은 AI에게 레거시 코드베이스를 읽고 기능 및 격차 보고서를 만들게 했다. 100쪽이 넘는 HTML 파일과, 각각 수백 행이 있는 30개 탭의 스프레드시트였다. 사람이 소비하기에 적합하지 않으니 상위 수준의 격차부터 시작하자고 이의를 제기하자, 팀플레이어가 아닌 것처럼 취급받았다. 아무도 읽을 수 없는 100쪽짜리 생성 보고서는 아무도 읽지 않은 5,000줄 diff와 같은 문제를 가진다. 에이전트는 긴 문서를 공짜로 만들어 낸다. 사람은 여전히 그것을 판단할 수 있어야 하며, 한 쪽짜리 버전을 요구하는 것은 방해가 아니다. 그것이 리뷰다.
내가 본 가장 합리적인 반발은 다른 스타트업 엔지니어에게서 나왔다. 그들의 경영진은 읽지 않고 배포하는 것을 좋아하지도 않는다. 다만 다음 회사가 그렇게 하고, 그렇지 않으면 가격 경쟁을 할 수 없기 때문에 선택지가 없다고 느낀다. 나는 이를 진지하게 받아들인다.
내 답은 두 번째 비용이다. 검사를 건너뛴다고 실패가 공짜가 되지는 않는다. 그 비용을 나중으로 옮길 뿐이고, 그때는 더 커져 고객에게 닥친다.
그러므로 경쟁에 관한 질문은 읽기 대 읽지 않기가 아니라고 생각한다. 실제로 작동하는 저렴한 검사를 구축하고, 정말로 해를 끼칠 수 있는 변경에 사람들의 제한된 주의를 투입할 수 있는 팀이 어디인가의 문제다. 이기는 팀은 아무것도 읽지 않는 팀이 아니다. 무엇을 읽을 가치가 있는지 아는 팀이다.
Thorsten의 목록에 대한 한 답글은 내가 계속 맴돌던 질문을 던졌다. 단위 테스트는 시스템이 어떻게 동작해야 하는지에 관해 당신이 아는 것을 담고, 완전히 신뢰하지 않는 대상, 즉 미래의 당신의 작업과 대조해 검사한다. “신뢰하지 않는 그 대상이 테스트도 작성한다면 무엇을 이루는가?”
공정한 질문이다. Anthropic의 보상 해킹 연구에서 모델들은 어떤 단언도 실패하기 전에 테스트 하니스가 종료되도록 sys.exit(0)을 호출하는 법을 배웠다. 테스트 중인 대상이 작성하거나 통제하는 테스트는 많은 것을 증명하지 못한다.
탈출구는 테스트가 어디에서 권위를 얻는지 묻는 것이다. 항공 분야의 답은 독립성이다. 항공 소프트웨어 표준인 DO-178C는 가장 중요한 검증을 작성자 이외의 사람이 수행하도록 요구하며, 적격 도구는 그 사람으로 인정될 수 있다. Claude 하나에게 테스트를 쓰게 하고 다른 하나에게 코드를 쓰게 하면 가장 조잡한 실패는 잡을 수 있지만, 같은 모델의 두 번째 복사본은 첫 번째의 사각지대를 공유한다. 진정한 독립성은 사람이 쓴 명세, 참조 구현, 증명처럼 다른 진실의 원천에서 나온다.
내가 아는 최고의 사례는 Nicholas Carlini의 C 컴파일러다. Claude 에이전트 16개, 거의 2,000회의 세션, 20,000달러 조금 안 되는 비용으로 부팅 가능한 Linux를 만들 수 있는 Rust 기반 100,000줄 컴파일러를 만들었다. 그의 주요 교훈은 에이전트보다 검사기에 관한 것이었다. “작업 검증기는 거의 완벽해야 한다. 그렇지 않으면 Claude는 잘못된 문제를 풀 것이다.” 에이전트들이 커널에서 막혔을 때, 그는 알려진 정상 참조인 GCC를 사용해 각각의 버그를 궁지로 몰았다.
SQLite는 이것이 어디로 향하는지 보여 준다. 이 라이브러리는 C 코드 약 156,000줄이고, 테스트 코드는 590배 더 크다. 가장 철저한 테스트 스위트는 100% 분기 커버리지에 이르며, 항공전자공학 테스트 표준을 충족하도록 설계되었고, 독점 소프트웨어다. SQLite는 코드는 무료로 제공하고 테스트는 라이선스한다. 그러니 Thorsten의 요점을 이렇게 바꾸어 말하겠다. 미래의 당신에게 남기는 메모로서의 단위 테스트는 미래의 당신이 코드를 바꾸는 사람이 아니게 되므로 덜 중요해질 것이다. 완전히 신뢰하지 않는 작성자에 대한 독립적인 검사로서의 테스트는 당신이 소유한 가장 가치 있는 코드가 될 것이다.
Thorsten은 대부분의 버그가 잘못된 것을 요청하는 데서 올 것이라고 말한다.
Ariane 5는 Ariane 4에서 재사용한 내비게이션 코드가 Ariane 4가 한 번도 비행하지 않은 궤적에서 오버플로했기 때문에 첫 비행 1분도 되기 전에 파괴되었다. 조사위원회는 명세에 새 궤적이 포함되지 않았음을 발견했다. Mars Climate Orbiter는 한 팀의 소프트웨어가 인터페이스가 기대한 뉴턴초 대신 파운드힘초를 생성했기 때문에 잃었다.
각 실패는 접합부에 있었다. 요구 사항과 실제 비행 사이, 두 팀의 단위 사이, 배포와 8대의 서버 사이에 있었다. 비싼 버그는 거기에 있고, 바로 그곳이 오늘날 모델이 가장 약한 부분이다. Anthropic 자체 평가는 Claude가 잘 명세된 실험을 수행하는 데서는 숙련된 연구자와 맞먹을 수 있지만, “목표 선택에서 Claude가 판단을 행사할 때는 큰 성능 격차가 지속된다”고 말한다.
나는 70% 문제, 그리고 나중에는 80% 문제에 관해 썼다. 매번 숫자가 올라갈 때마다 인간에게 남은 것은 타이핑이 줄고 판단이 늘어나는 일이었다. 나는 제품, 디자인, 엔지니어링의 3인조가 사라질 것이라는 Thorsten의 주장을 그렇게 읽는다. 세 역할 간의 인계는 사라진다. 하지만 결국 누가 판단하든 세 가지 판단은 남는다. 이것을 만들 가치가 있는가, 사용하는 사람에게 잘 작동하는가, 견딜 수 있는가. 그가 특히 한 역할에 관해서는 맞다. 티켓을 받아 에이전트에 넘기고 자기 판단을 전혀 더하지 않은 채 결과를 보고하는 사람, 그 일자리는 사라지고 있다.
흔한 반론은 버그가 큰 문제를 일으키거나 누군가의 돈을 잃게 할 수 있는 곳에는 이 모든 것이 적용되지 않는다는 것이다. 오늘날 그런 업계는 코드를 읽고, 낙관론자들이 예상하는 것보다 더 오래 그렇게 할 것이라고 생각한다. 하지만 그들이 실제로 요구하는 것은 코드를 신뢰할 이유이며, 그런 이유가 있을 때는 이전에도 기계 생성 코드를 받아들였다.
코드 생성기는 같은 입력에 같은 출력을 내므로 적격 판정을 받을 수 있다. 언어 모델은 그렇지 않다. 따라서 현재 비행 소프트웨어에 모델을 사용하는 실용적인 방법은 예전 방식이다. 사람이 그것이 쓴 것을 읽는 것이다. 앞으로 나아갈 길은 검증 쪽에 있다. 형식 증명, 적격 정적 분석, 독립적인 테스트 오라클을 활용하고, 모델을 모든 출력이 검증되는 신뢰할 수 없는 작성자로 다루는 것이다.
금융은 사람들이 생각하는 것보다 가깝다. 그 규칙에서 리뷰라고 부르는 많은 것은 실제로 책임에 관한 것이다. 표준은 대체로 변경이 권한을 받고, 테스트되고, 독립된 누군가에게 승인받도록 요구할 뿐, 동료가 모든 줄을 읽도록 요구하지는 않는다. 그 어느 것도 에이전트가 구현하는 일을 막지 않는다. 승인을 사람에게 책임지게 하고, 사람이 있어야 할 곳은 바로 그 지점이다.
일정에 관한 가장 강력한 이의는 Andrej Karpathy에게서 나온다. 그는 작년에 이것은 “더 정확히는 에이전트의 10년이라고 묘사해야 한다”고 말했다. 그의 주장은 자율주행에서 나온다. 여기서는 “모든 추가 9 하나가 일정량의 작업”이다. 신뢰도를 90%에서 99%로 높이는 비용은 처음 90%에 도달하는 비용만큼 든다. Waymo는 2009년에 시작했고 지금은 15번째 도시까지 왔다.
그는 9들이 비싸다는 점에서 옳다. 소프트웨어가 운전과 다른 점은 많은 소프트웨어가 모델이 아니라 모델 주변 시스템에서 9들을 살 수 있다는 것이다. 웹 앱은 플래그 뒤에서 배포하고 오류율을 지켜본 뒤 몇 분 안에 롤백할 수 있다. 자동차는 충돌을 롤백할 수 없다. 따라서 일정은 내 두 비용 중 두 번째, 즉 배포 후 실패를 얼마나 저렴하게 잡고 되돌릴 수 있느냐에 따라 갈린다고 생각한다.
나중에 나에게 책임을 물을 수 있을 만큼 구체적으로 내 추측을 말해 보겠다.
소비자 소프트웨어, 내부 도구, 대부분의 SaaS: 2년 안에 사람이 일상적인 변경의 모든 줄을 읽는 일은 드물어질 것이다. 하지만 사람은 여전히 승인하고 책임질 것이다. 이미 그런 팀도 많다.
엔터프라이즈 및 금융 소프트웨어: 같은 일정 안에 에이전트가 대부분의 코드를 작성하고, 사람의 승인은 통제 장치로 남을 것이다. 3년에서 5년에 걸쳐 그 승인은 diff에서 증거로 이동한다.
비행 제어와 최고 위험 의료기기: 사람들은 줄마다 계속 읽을 것이다. 규제 기관이 앞으로 여러 해 동안 적격 검증만으로 안전 필수 코드를 받아들일 것이라 예상하지 않는다.
이 대화의 가장 시끄러운 버전이 어디에서 이루어지는지도 기억할 만하다. 가장 큰 거품인 Twitter에서는 우리가 곡선보다 앞서 있다. 업계의 나머지와 세계의 나머지가 따라잡는 데는 긴 시간이 걸릴 것이다. 하지만 방향은 내게 분명하다.
Thorsten은 “좋은 코드”가 중요할 것이라는 증거는 없다고 말한다. 우리가 그 말로 뜻하는 대부분이 사람들이 코드를 다루기 쉽게 만드는 것에 관한 일이기 때문이다. 포맷팅처럼 순전히 인간의 편안함에 관한 부분에는 동의한다. 하지만 어떤 속성은 우리보다 에이전트에게 더 중요하다. 검색할 만큼 고유한 이름, 컨텍스트 창에 들어갈 만큼 작은 모듈, 명확하게 실패하는 테스트, 부분들 사이의 명확한 경계가 그렇다. 이런 것이 없어도 에이전트는 변경을 할 것이다. 다만 그 변경이 다른 무엇에 영향을 주는지는 볼 수 없다. 이제 좋은 코드란 에이전트가 보지 못하는 무언가를 망가뜨리지 않고 변경할 수 있는 코드다.
나는 오랫동안 오픈 소스에 관여해 왔고, 그것이 죽기보다 여기서 진화한다고 생각한다. 어느 때보다 쉽게 프로젝트를 가져와 자기 사본을 만들고, 모든 코드를 먼저 이해하지 않고도 빠르게 바꿀 수 있다. 사람들이 맞춤화하고 싶을 때 에이전트에게 건네는 프롬프트를 공유하거나, 완성된 산출물을 공유하게 되어도 놀랍지 않다.
오픈 소스에 부족한 것은 유지관리자의 주의이며, AI는 그것을 넘치게 하면서도 증폭한다. 1월 Daniel Stenberg는 자신이 “AI 쓰레기 보고의 폭발”이라고 부른 것을 이유로 curl의 버그 바운티를 끝냈다. 3개월 뒤 실제 취약점의 비율은 예전 보고량의 두 배에서 정상으로 돌아왔다. 1년 안에 쓰레기 문제는 물량 문제가 되었다. 가장 공유할 가치가 있는 것은 생산에는 비싸지만 대조 검사에는 싼 것, 즉 테스트 스위트, 명세, 무엇이 깨졌는지의 기록으로 이동한다.
Madeleine Clare Elish는 자동화 시스템의 가장자리에 있는 사람들에게 일어나는 일의 이름을 붙였다. 도덕적 완충 지대다. 자동차에서 완충 지대는 승객이 충격을 받지 않도록 충격을 흡수하게 설계된다. 자동화가 대부분의 일을 하는 시스템에서는 가장 가까운 사람이 흔히 같은 역할을 한다. 그들은 막을 실질적 권한이 거의 없던 실패의 책임을 진다.
13시간 동안 엔터를 누르는 엔지니어는 그 지대에 서 있다. 그들의 이름은 승인에 적혀 있다. 하지만 속도, 검사, 무엇을 읽을 가치가 있었는지에 관한 결정은 모두 다른 곳에서 내려졌다. 무언가가 깨지면 사고 검토는 그것을 승인한 사람을 찾아낼 것이다.
모든 줄을 읽는 것이 소프트웨어를 신뢰할 수 있게 만든 적은 없다. 그것은 사람이 자신이 무엇을 배포하는지 이해하고 거부할 위치에 있도록 하는 한 가지 방법이었다. 대부분의 코드에서 줄 단위 읽기는 사라지고 있고, 나는 괜찮다고 생각한다. 하지만 이해와 거부할 능력까지 함께 사라져서는 안 된다.
Teleport은 한 분기 만에 2년치 보안 버그를 찾아냈다. 엔지니어 13명, 최첨단 모델, 자체 코드베이스로 이전 2년 전체의 거의 두 배에 달하는 고위험 취약점을 발견했다. 내가 관심을 두는 것은 이것이 대기열에 미치는 영향이다. 발견 비용은 몇 배나 낮아졌다. 하지만 분류 작업은 그렇지 않았고, 실제로 악용 가능한지 확인하는 일은 여전히 사람이 코드를 읽어야 한다. 고칠 수 있는 속도보다 더 빨리 찾아내면, 알 수 없던 백로그를 알려진 백로그로 바꾼 셈이다. 자신의 코드베이스에 이를 시도하기 전에 읽어볼 만하다.분석 글 읽기 →https://fandf.co/4r3xdeX · Teleport 후원. #ad
그러니 2년 전 내가 한 말 대신 지금 하게 될 조언은 이렇다. 무엇을 읽을 가치가 있는지 알아라. 읽지 않는 코드에는 실제로 신뢰할 검사를 구축하고, 그것이 코드를 작성한 대상과 독립적이게 하라. 에이전트가 만들기 전에 무엇을 만드는지 적어라. 배포하는 모든 것을 설명할 수 있어야 하며, 설명할 수 없는 것에는 솔직해져라. 다른 사람들의 속도를 정한다면, 그들에게 요구하는 책임에 걸맞은 권한을 주어라.
나는 한때 좋은 코드를 다음 개발자에게 보내는 사랑의 편지라고 불렀다. 지금도 그렇게 믿는다. 다만 점점 더 다음 개발자가 에이전트이므로, 편지는 이제 다른 모습이다. 그것은 에이전트가 보지 못하는 무언가를 망가뜨리지 않고 변경할 수 있는 코드다. 장인정신은 사라지지 않았다. 코드가 신뢰받을 자격이 있는지를 결정하는 부분으로 옮겨갔다.
지난 몇 달 동안 뉴스레터를 후원해 준 스폰서들에게 감사한다. 새 역할에 전일제로 합류하면서 앞으로 발행할 글의 스폰서는 잠시 중단했다. 여기에서 표현한 의견은 내 개인적인 의견이며 고용주의 견해나 의견을 나타내지 않는다. 그것이 여러분에게 도움이 되는 한 뉴스레터에서 계속 글을 쓰고 생각을 공유할 수 있기를 바란다 :)
