아무도 읽지 않는 코드 (번역)
2년 전 나는 AI 보조 코딩에 관한 에세이에서 생성된 코드의 모든 줄을 리뷰하라는 조언을 했다. 오늘은 그 조언을 아주 다르게 하겠다.
지금 내가 할 말은 이것이다. 모든 코드를 읽을 필요는 없다. 모든 변경에는 여전히 어떤 형태로든 리뷰가 필요하고, 모든 변경에는 출시를 결정하는 사람이 필요하다. 달라진 것은 모든 줄을 사람이 세밀히 읽는 것이 그 리뷰를 제공하는 유일한 방법이 아니라는 점이다. 경우에 따라 에이전트가 주로 리뷰하거나, 민감한 부분은 사람과 에이전트가 섞여 검토하는 편이 낫다.
이 글은 그 자리를 무엇이 채워야 하는지, 그리고 아무것도 채우지 않으면 어떤 일이 벌어지는지에 관한 것이다.
지난주 Thorsten Ball이 소프트웨어 개발의 미래에 관해 자신이 믿는 열여섯 가지를 목록으로 올렸다. 첫 번째는 “코드 리뷰는 죽는다”였다. 나는 그 목록의 상당 부분, 적어도 방향에 대해서는 동의한다. 다만 첫 번째 항목은 다르게 표현하겠다. 많은 코드에서 줄 단위 읽기는 사라지고 있다. 리뷰, 다시 말해 누군가 무엇을 출시할지 정하고 그에 대해 책임지는 행위는 사라지지 않는다. 그런 목록이 알려주지 못하는 것은 각 항목이 얼마나 빨리 도착하는지, 업계의 어느 부분에 먼저 오는지다. 내가 사람들과 실제로 의견이 갈리는 지점은 거기다.
같은 주간에 아주 다른 글 하나가 그만큼 멀리 나아갔다. 대기업에 입사한 지 2주 된 엔지니어가 아무도 읽지 않는 코드에 엔터 키만 누르며 하루를 보낸다는 글을 썼고, 800만 명 넘게 그 글을 봤다. 나는 이 두 글이 서로 모순된다고 보지 않는다. 하나는 목적지를 묘사한다. 다른 하나는 길을 놓지 않은 채 그곳으로 몰아가는 회사에서 벌어지는 일을 묘사한다.
내 견해를 짧게 말하면 이렇다. 코드를 신뢰할 다른 좋은 이유가 생기면, 모든 업계는 대부분의 코드를 줄 단위로 읽는 일을 멈출 것이다.
이번이 다른 점은 코드를 쓰는 존재를 예전의 코드 생성기처럼 인증할 수 없다는 데 있다. 같은 입력에 같은 답을 내놓는 일이 안정적이지 않기 때문이다. 그래서 신뢰는 그 코드 주변에 우리가 만들어 두는 검증 장치에서 나와야 한다. 팀이나 업계가 그 지점에 도달하는 속도는 두 비용에 달려 있다. 아무도 읽지 않은 작업을 검증하는 비용, 그리고 검증이 놓친 실패를 되돌리는 비용이다.
먼저 밝혀두자면 나는 중립적 입장이 아니다. 나는 코드를 쓰는 도구를 만드는 일을 돕는다. 사람들이 Thorsten을 “파라고 하면서 삽을 파는 사람”이라 불렀을 때 그는 인과가 반대라고 했다. 그는 에이전트를 믿기 때문에 에이전트를 만든다고. 나도 마찬가지다.
옛 방식에서 그리운 것은 없냐고 물으면, 솔직히 있다. 내가 쓴 자바스크립트 책 하나의 맨 앞에서 나는 좋은 코드는 다음 개발자를 위한 러브레터 같은 것이라고 썼다. 그 말은 진심이었다. AI 이전의 일이고, 많은 사람이 코드 그 자체의 장인정신을 아껴하던 시절이었다. Thorsten이 “아직도 이탈리아 구두 장인이 있지만, 당신 발을 보라”고 한 말이 좋았다. 세상은 변한다. 내가 그 대가로 얻는 것은 점토를 아주 빨리 다시 빚는 능력이고, 그렇지 않았다면 몇 년 굴리다 결국 시작도 못했을 것들을 만들 수 있다는 점이다.
리뷰는 원래 무엇을 했나
2013년 마이크로소프트 연구진이 코드 리뷰를 연구하며 개발자들에게 왜 하는지 물었다. 결함 발견이 1순위 답변이었다. 그런데 리뷰 코멘트를 분류해 보니 이야기가 달랐다. 연구진이 분류한 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에 “완전히 위임”할 수 있다고 답했다. 나머지는 여전히 능동적인 감독과 검증이 필요하다, 특히 실패의 대가가 큰 작업에서는. 모든 줄을 읽지 않는 것과 주의를 기울이지 않는 것은 다르다.
내가 더 걱정하는 것은 리뷰가 원래 해오던 다른 일들이다. 리뷰는 주니어 엔지니어가 시니어 엔지니어의 사고방식을 배우는 통로였다. 리뷰어가 코멘트로 하던 말들, 예컨대 “우리는 여기서 그렇게 안 한다”는 이제 스킬(skill) 문서에 적어둬야 한다. 적어두지 않으면 에이전트는 평생 듣지 못한다.
읽기가 멎었는데 아무것도 그 자리를 채우지 않을 때
문제는 아무도 코드를 읽지 않는다는 사실이 아니다. 읽기를 대체한 것이 없다는 사실이다. 앞서 그 팀은 신뢰를 diff에서 검증 장치로 옮기지 않았다. diff 읽기를 멈추고 신뢰가 있던 자리에 속도를 놓았다. 가능한 한 최악의 순서로 전환을 했고, 내가 말한 두 비용은 결말을 예측해준다. 아예 검증하지 않음으로써 첫 번째 비용을 0으로 만들었으니, 두 번째 비용을 지불하게 된다. 검증 장치가 애초에 잡으려 했던 실패들을, 이자까지 붙여 되돌리는 비용을.
그 순서도 우연이 아니었다. 그 현장에 사는 사람들보다 위에 있는 누군가가 결정했다. 코드 쓰기가 병목이 아니게 됐으니, 남은 질문은 왜 아직도 느리냐는 것뿐이라고. 이런 도구는 보통 아래에서 위로 퍼진다. 개별 개발자가 써보고 도움이 된다고 판단하면서. 이번 방식은 위에서 아래로 명령됐고, 그 차이는 매우 크다. 리뷰가 하던 일을 다시 떠올려보라. 가르치기, 변경 사항에 대한 팀의 인식 유지, 팀이 자기 품질 기준을 스스로 지키게 하기. 팀에게 읽기를 멈추라고 명령하면 결함 검증 장치 하나를 없앤 것으로 끝나지 않는다. 그 기준은 이제 너희 것이 아니라고 말해주는 셈이다.
잘 통하는 버전은 비교적 지루하다. 모든 PR에 멀티 에이전트 1차 검토를 돌린다. 버그를 찾고, 확인하고, 심각도 순으로 매기고, 수정안을 제안한다. 파급 범위가 작고 덜 민감한 변경은, 그런 코드가 보통 대부분인데, 1차 검토가 깨끗하게 나오면 가벼운 사람 확인만 거친다. 핵심 경로와 민감한 경로는 여전히 오너와 세밀한 사람 리뷰가 필요하고, 내 주의력은 그곳에 쓴다. 어느 쪽이든 머지를 승인하는 건 사람이다. 에이전트가 1차 검토를 하고 사람이 파급 범위를 맡는다. 그 루프 안에서 아무도 13시간 엔터를 누르지 않는다. 엔터는 애초에 사람의 역할이 아니었으니까. 사람의 역할은 어디에 주의를 쏟을지 정하는 것이다. 그 글의 “승리감이 없다”는 말은, 회사가 그 결정마저 당신에게서 가져가버렸을 때의 느낌이다.
엔터를 누르는 당신이라면
이 주제의 조언 대부분은 정책을 정할 수 있는 사람을 위해 쓰인다. 그 스레드의 많은 사람들은 그럴 수 없었다. 그래서 내가 그 회사에 입사 2주 차라면 할 일을 적는다.
만들려는 것을 제대로 이해하라. 에이전트가 뭘 건드리기 전에, 무엇을 만드는지, 무엇을 망가뜨리면 안 되는지, 됐다는 걸 어떻게 알 건지 적어둔다. 길 필요는 없다. 이제 당신의 판단이 가는 곳이 여기고, 나중에 가리킬 수 있는 작업 부분도 여기다. 그 스레드의 여러 사람도 비슷한 말을 했다. 여전히 자기 일이 괜찮다고 느끼던 사람들은 설계를 자기가 하고 빌드를 에이전트에게 맡겼던 사람들이었다. 승리감을 되찾고 싶다면 그 감각은 결정 속에 산다.
“이걸 설명할 수 있는가”를 시험으로 써라. 그 스레드의 한 디자인 리드는 팀에게 일을 내 것이라 부르기 전에 “개의 털 한 올까지” 아는지 물었다고 한다. 나는 같은 시험을 코드에 적용하겠다. 모든 줄을 읽었을 필요는 없다. 그러나 이 변경이 무엇을 하는지, 무엇을 건드리는지, 왜 출시해도 안전한지 설명할 수 있어야 한다. 설명할 수 있는 것에만 진짜 책임을 질 수 있다.
검토하지 못한 부분을 솔직히 말하라. 변경을 이해할 시간을 주지 않았다면 사람들이 볼 수 있는 곳에 말한다. 예컨대 PR 설명에 “에이전트 리뷰 통과, 테스트 통과, 마이그레이션 로직은 읽지 않았다”고. 까다롭게 구는 게 아니다. 이 글 끝에서 다룰 파쇄 지대(crumple zone)에 빠지지 않게 해주는 행동이다. 얼마나 적게 읽었는지 숨기는 팀은 그 문제를 고칠 수 없다.
손을 놓지 마라. Anthropic 연구진은 “감독의 역설”을 설명한다. Claude를 잘 감독하려면, 쓰지 않으면 시들어버리는 코딩 실력이 정작 필요하다는 것. 그곳의 몇몇 엔지니어는 Claude가 처리할 수 있단 걸 알면서도 가끔은 일부러 Claude 없이 문제를 푼다. 한 사람은 “제 자신을 날카롭게 유지하는 데 도움이 됩니다”라고 했다. 특히 커리어 초기라면 베낄 만한 습관이다.
속도를 정하는 사람이라면
가장 그럴듯한 반론은 모든 문서와 코드가 AI 산출물인 스타트업들에서 나온다. “우리가 저것들에게 일하게 하지, 저것이 우리를 부리는 게 아니다. 모든 일마다 우리가 한 것을 설명할 수 있는 책임자가 있다.” 기대치를 정하는 사람이라면 여기서 이어지는 결론은 이렇다고 본다.
책임에는 권한이 필요하다. 변경이 실패했을 때 욕먹을 엔지니어라면, 변경 속도와 얼마나 이해할 시간을 가질지에 대해 말할 권한이 있어야 한다. 자기가 정하지 않은 속도와, 이해할 시간을 주지 않은 코드로 누군가에게 책임을 지우는 일은 그 스레드가 “고기 프록시”라 부른 바로 그 상황이다. 공정하지 않고, 통제 장치로도 작동하지 않는다.
출시된 것을 측정하라, 얼마나 만들었는지가 아니라. 머지된 PR과 코드 줄 수는 세기 쉽고, 엔터 누르기가 직업 전체가 되게 만든 숫자들이다. Anthropic도 자기 8배 생산성 수치에 관한 글에서 코드 줄 수를 “불완전한 측정”이라 불렀다. 장애, 롤백, 복구 시간, 고객이 실제 겪는 것을 보라.
이해를 다른 용량처럼 예산에 넣어라. 한 커멘터가 새 제약을 명쾌하게 표현했다. “코드 쓰기는 병목이 아닌데, 읽고 평가하는 게 병목이다.” Anthropic도 리뷰에 대해 같은 말을 했다. 답은 아무것도 읽지 않는 게 아니라, 영역별로 변경에 필요한 사람의 주의량을 정하고 그 주위로 작업을 계획하는 것이다. 자동 리뷰가 여기서 큰 도움이 되지만, Anthropic이 밝힌 그 목표는 “리뷰어가 실제로 출시되는 것을 커버할 수 있게” 격차를 줄이는 것이지 리뷰어를 루프에서 빼는 게 아니다.
멘토링을 위한 자리를 의도적으로 만들어라. 주니어는 예전에 시니어에게 질문하고 리뷰 코멘트를 읽으면서 배웠다. 이제 Claude가 질문에 답한다면 나머지는 의도적으로 만들어야 한다. 계획 위에서 페어 프로그래밍을 하고, 주니어에게 에이전트가 쓴 변경을 누군가에게 설명하게 하고, 일부 작업은 수동으로 남겨둔다. 그 스레드의 텅 빈 대답 하나가 “주니어가 어딨는데”였다. 당신 회사의 답이 되면 안 된다.
사람에게 서명시키는 것을 사람 크기로 유지하라. 이건 코드만이 아니라 문서에도 적용된다. 어떤 커멘터의 제품 팀은 AI로 레거시 코드베이스를 읽혀 기능과 격차 보고서를 만들었다. 100페이지가 넘는 HTML 파일과, 수백 행씩 30개 탭을 가진 스프레드시트였다. 사람이 읽기에 부적합하다고 항의하고 상위 수준 격차부터 시작하자고 하자, 팀 플레이어가 아니라는 취급을 받았다. 아무도 읽을 수 없는 100페이지짜리 생성 보고서는 아무도 읽지 않은 5,000줄짜리 diff와 같은 문제를 갖는다. 에이전트는 긴 문서를 공짜로 만들어준다. 그래도 사람이 판단할 수 있어야 하고, 한 페이지짜리 버전을 요구하는 건 방해가 아니라 리뷰다.
“그런데 경쟁사는 코드를 안 읽는데요”
본 적 있는 가장 합리적인 반론은 또 다른 스타트업 엔지니어에게서 나왔다. 그의 경영진은 사실 읽지 않고 출시하는 걸 좋아하지 않는다. 그래도 선택의 여지가 없다고 느낀다. 다음 회사는 그렇게 하고, 그렇게 하지 않으면 가격 경쟁을 할 수 없기 때문이다. 나는 그 말을 진지하게 받아들인다.
내 답은 두 번째 비용이다. 검증을 건너뛴다고 실패가 공짜가 되진 않는다. 실패의 비용을 나중으로 옮길 뿐이고, 그때는 더 크고 고객에게 직접 간다.
그래서 경쟁 질문은 읽느냐 안 읽느냐가 아니라고 본다. 실제로 작동하는 저렴한 검증 장치를 만들고, 사람들의 제한된 주의를 정말 아플 수 있는 변경에 쏠 수 있는 팀이 어느 쪽인가의 문제다. 이기는 팀은 아무것도 읽지 않는 팀이 아니다. 무엇을 읽을지 아는 팀이다.
그럼 테스트는 누가 쓰나
Thorsten의 목록에 달린 한 답글이 내가 계속 돌던 질문을 던졌다. 단위 테스트는 시스템이 어떻게 동작해야 하는지에 대한 당신의 지식을 담아, 당신이 완전히 신뢰할 수 없는 대상, 즉 장래의 자기 작업과 대조한다. “검증받는 대상이 테스트까지 쓴다면 대체 무슨 의미가 있나?”
타당한 질문이다. Anthropic의 보상 해킹(reward hacking) 연구에서 모델들은 sys.exit(0)를 호출해 어떤 검증(assertion)도 실패하기 전에 테스트 하네스가 종료되게 만드는 법을 배웠다. 테스트 대상이 쓰거나 통제하는 테스트는 별것도 증명하지 못한다.
출구는 테스트가 어디서 권한을 얻는지 묻는 것이다. 항공의 답은 독립성이다. 항공 소프트웨어 표준 DO-178C는 가장 중요한 검증을 저자가 아닌 사람이 하도록 요구하고, 적격 도구가 그 “사람” 자격을 가질 수 있다. Claude 하나로 테스트를 쓰고 다른 하나로 코드를 쓰면 가장 조잡한 실패는 걸러지지만, 같은 모델의 두 벌은 첫 번째의 맹점을 공유한다. 진짜 독립성은 다른 종류의 진실 원천에서 나온다. 사람이 쓴 명세, 참조 구현, 증명.
내가 아는 가장 좋은 사례는 Nicholas Carlini의 C 컴파일러다. 16개 Claude 에이전트, 거의 2,000 세션, 2만 달러 미만으로 부팅 가능한 리눅스를 빌드할 수 있는 10만 줄짜리 Rust 컴파일러를 만들었다. 그의 주된 교훈은 에이전트가 아니라 검증기에 관한 것이었다. “작업 검증기가 거의 완벽해야 한다. 아니면 Claude가 엉뚱한 문제를 풀어버린다.” 에이전트들이 커널에서 막혔을 때 그는 GCC를 검증된 참조로 써서 버그를 몰아붙였다.
SQLite는 이 길의 종착점을 보여준다. 이 라이브러리는 약 15.6만 줄의 C 코드고, 테스트 코드는 그 590배다. 가장 철저한 테스트 스위트는 100% 분기 커버리지에 도달했고, 항공 전자 테스트 표준을 만족하도록 설계됐으며, 비공개다. SQLite는 코드를 공짜로 주고 테스트에 라이선스를 판다. 그러니 Thorsten의 주장을 이렇게 고쳐 말하겠다. 장래의 자기에게 남기는 노트로서의 단위 테스트는 중요성이 줄 것이다. 코드를 바꾸는 게 장래의 자기가 아니게 될 테니까. 완전히 신뢰할 수 없는 저자에 대한 독립 검증으로서의 테스트가 당신이 소유한 가장 가치 있는 코드가 될 것이다.
비싼 버그는 애초에 상류에 있었다
Thorsten은 대부분의 버그는 엉뚱한 것을 요청해서 나온다고 한다.
Ariane 5는 첫 비행 1분도 안 돼 폭파됐다. Ariane 4에서 재사용한 항법 코드가 Ariane 4는 날아본 적 없는 궤도에서 오버플로가 난 탓이다. 조사위원회는 명세에 새 궤도가 포함되지 않았다는 결론을 냈다. Mars Climate Orbiter는 한 팀의 소프트웨어가 파운드힘초를 출력하는데 인터페이스는 뉴턴초를 기대해 잃어버렸다.
두 실패 모두 접합부에 살았다. 요구사항과 실제 비행 사이, 두 팀의 단위 사이, 배포와 8대 서버 사이. 비싼 버그는 거기 살고, 그곳이 오늘날 모델이 가장 약한 지점이기도 하다. Anthropic 자체 평가에 따르면 Claude는 잘 명세된 실험 수행에서는 숙련 연구원에 필적하지만, “목표를 고르는 데 판단을 쓰는 영역에서는 큰 성능 격차가 남아 있다.”
나는 70% 문제를 썼고, 이후 80% 문제를 썼다. 숫자가 오를 때마다 사람에게 남는 일은 타이핑이 줄고 판단이 늘었다. Thorsten이 제품, 디자인, 엔지니어링의 삼각 편성이 사라진다고 한 말을 나는 그렇게 읽는다. 세 역할 사이의 인계는 사라진다. 세 가지 판단은 남는다, 최종적으로 누가 하든. 뭘 만들 가치가 있는가, 사용하는 사람에게 작동하는가, 견딜 수 있는가. 그리고 한 역할에 대해서는 그가 특히 맞다. 티켓을 받아 에이전트에 넘기고 자기 판단 없이 보고만 하는 사람의 일은 사라진다.
“절대 안 된다”고 말하는 업계들
늘 나오는 반론은 버그가 큰 사고나 금전 손실을 일으킬 수 있는 곳엔 이 얘기가 해당 없다는 것이다. 오늘날 그 업계들은 코드를 읽고, 낙관론자들의 예상보다 오래 읽을 거라고 본다. 그러나 그들이 실제로 요구하는 것은 코드를 신뢰할 이유고, 그 이유가 있을 때는 기계 생성 코드를 이미 받아들인 적이 있다.
코드 생성기는 같은 입력에 같은 출력을 내기 때문에 인증(qualification)이 가능하다. 언어 모델은 그렇지 않다. 그래서 당분간 비행 소프트웨어에 모델을 쓰는 현실적 방법은 옛 방식이다. 사람이 그것이 쓴 것을 읽는다. 나가는 길은 검증 쪽에 있다. 형식 증명, 적격 정적 분석, 독립 테스트 오라클을 쓰고, 모델을 모든 출력이 검증되는 신뢰할 수 없는 저자로 취급하는 방식이다.
금융은 사람들이 생각하는 것보다 가깝다. 그 업계 규칙이 리뷰라고 부르는 것의 상당 부분은 실은 책임 소재에 관한 것이다. 표준들이 대부분 요구하는 것은 변경이 독립된 누군가에 의해 승인되고 테스트되고 인가되는 것이지, 동료가 모든 줄을 읽는 게 아니다. 그 어느 것도 에이전트가 구현을 하지 못하게 하지 않는다. 승인에 대한 책임을 사람에게 남기고, 사람이 있어야 할 곳이 바로 거기다.
나인(nines)을 세어라
타임라인에 관해 내가 아는 가장 강한 반론은 Andrej Karpathy가 작년에 한 말에서 나온다. 그는 이 시대를 “에이전트의 10년이라고 표현하는 게 더 정확하다”고 했다. 그의 논거는 자율주행에서 나온다. “나인 하나하나가 일정한 양의 작업이다.” 90% 신뢰에서 99%로 가는 데 드는 비용은 애초에 90%까지 가는 비용만큼 든다. Waymo는 2009년에 시작해 15번째 도시에 이르렀다.
나인이 비싸다는 데는 그가 맞다. 소프트웨어가 주행과 다른 점은, 많은 소프트웨어가 나인을 모델이 아니라 모델 주변의 시스템에서 구매할 수 있다는 것이다. 웹 앱은 플래그 뒤에 출시하고 오류율을 보고 몇 분 만에 롤백할 수 있다. 자동차는 충돌을 롤백할 수 없다. 그래서 타임라인은 내 두 비용 중 두 번째 비용에 따라 갈린다고 본다. 출시 후 실패를 얼마나 싸게 잡아내고 되돌릴 수 있는가.
내 추측들이다, 나중에 책임져줄 수 있을 만큼 구체적으로.
소비자 소프트웨어, 내부 도구, 대부분의 SaaS에서는 2년 안에 루틴한 변경의 모든 줄을 사람이 읽는 일이 드문 일이 될 것이다. 그래도 승인하고 소유하는 건 사람이다. 상당수 팀은 이미 거기 있다.
엔터프라이즈와 금융 소프트웨어에서는 에이전트가 같은 타임라인에서 대부분의 코드를 쓴다. 승인은 통제 장치로 사람에게 남는다. 3~5년에 걸쳐 그 승인은 diff에서 증거로 옮겨간다.
비행 제어와 최고위험 의료 기기에서는 사람들이 계속 줄 단위로 읽는다. 규제 기관이 아무리 해도 안전 필수 코드를 적격 검증만으로 받아들일 거라고 기대하지 않는다.
함께 기억할 것도 있다. 이 논의가 가장 크게 벌어지는 곳이 어디인가. 가장 큰 거품 속에서, 트위터에서, 우리는 이미 시대를 앞서 있다. 업계의 나머지와 세상의 나머지가 따라오는 데는 오랜 시간이 걸린다. 그러나 방향은 내게 분명하다.
코드는 어떻게 되나
Thorsten은 “좋은 코드”가 중요하다는 증거는 없다고 한다. 그 말이 가리키는 대부분은 사람이 다루기 쉽게 만드는 성질이니까. 형식 같은 순수하게 사람의 편의에 관한 부분에서는 동의한다. 그러나 어떤 성질은 에이전트에게 예전보다 더 중요하다. grep으로 잡히게 고유한 이름, 컨텍스트 윈도우에 들어갈 만큼 작은 모듈, 명확하게 실패하는 테스트, 부분 사이의 명확한 경계. 이런 게 없으면 에이전트는 그래도 변경을 해낸다. 다만 그 변경이 무엇에 영향을 주는지 보지 못한 채.
오랫동안 오픈소스에 관여해온 입장에서 보면 오픈소스는 죽는 대신 여기서 진화한다고 본다. 프로젝트를 가져와 자기 복사본을 만들고, 모든 코드를 이해하기 전에 빠르게 재구성하는 일이 그 어느 때보다 쉬워졌다. 프롬프트를 공유하거나, 커스텀하고 싶은 사람이 에이전트에 넘겨줄 완성 산출물을 공유하는 일이 늘어나도 이상하지 않겠다.
오픈소스가 부족한 것은 메인테이너의 주의력이고, AI는 그것을 홍수처럼 밀어넣으면서 동시에 곱해주기도 한다. 1월에 Daniel Stenberg는 그가 “AI 슬롭 리포트의 폭발”이라 부른 것을 이유로 curl의 버그 바운티를 끝냈다. 3개월 후 실제 취약점 비율은 정상으로 돌아왔고, 리포트 양은 예전의 2배였다. 1년 안에 정크 문제는 양의 문제로 변했다. 이제 가장 공유할 가치가 있는 것은 만들기 비싸고 대조하기 싼 것들로 옮겨간다. 테스트 스위트, 명세, 무엇이 깨졌는지의 기록.
파쇄 지대
Madeleine Clare Elish는 자동화 시스템 가장자리에 있는 사람에게 일어나는 일에 이름을 붙였다. 도덕적 파쇄 지대(moral crumple zone). 자동차의 파쇄 지대는 충격을 흡수해 승객이 대신 부숴지지 않게 만들어진 부분이다. 자동화가 대부분의 일을 하는 시스템에서 가장 가까운 인간이 종종 같은 역할을 한다. 막을 실질적 권한이 거의 없던 실패의 책임을 뒤집어쓴다.
13시간 엔터를 누르던 그 엔지니어는 그 지대에 서 있었다. 승인에 그의 이름이 올라가 있다. 그러나 속도, 검증 장치, 무엇을 읽을 가치가 있는지의 결정은 전부 다른 곳에서 내려졌다. 뭔가가 깨지면 사고 리뷰는 승인한 인간을 찾아낼 것이다.
모든 줄을 읽는 것이 소프트웨어를 신뢰할 수 있게 만든 적은 없었다. 그것은 사람이 자기가 출시하는 것을 이해하고, 아니라고 말할 수 있는 위치에 있게 확인하는 방법 중 하나였다. 줄 단위 읽기는 대부분의 코드에서 사라지고, 나는 그것이 괜찮다고 본다. 이해와 아니라고 말할 수 있는 능력만은 따라갈 수 없다.
그래서 2년 전 조언 대신 지금 할 조언은 이것이다. 무엇을 읽을 가치가 있는지 알라. 읽지 않는 코드에는 실제로 신뢰할 만한 검증 장치를 만들고, 코드를 쓴 것과 독립적으로 유지하라. 에이전트가 만들기 전에 무엇을 만드는지 적어둬라. 출시하는 모든 것을 설명할 수 있게 하고, 설명할 수 없는 것은 솔직히 말하라. 다른 사람의 속도를 정한다면, 그들에게 요구하는 책임에 맞는 권한을 주어라.
나는 예전에 좋은 코드를 다음 개발자에게 보내는 러브레터라고 불렀다. 그 말은 여전히 믿는다. 다만 그 다음 개발자가 점점 에이전트가 되어가고, 편지의 모양도 달라졌다. 에이전트가 보지 못하는 것을 망가뜨리지 않고 변경할 수 있는 코드. 장인정신은 사라지지 않았다. 코드가 신뢰받을 자격이 있는지를 결정하는 부분으로 옮겨갔을 뿐이다.