코드를 읽지 않는 것에 대한 변론
Ben Shoemaker의 글 심층 분석: 하네스 엔지니어링과 AI 시대의 개발자 역할 전환
들어가며: 논쟁에 불을 붙인 한 마디
소프트웨어 엔지니어 Ben Shoemaker는 원래 AI 보조 코딩의 미래를 논하는 글을 쓰려 했다. 그런데 막상 200개 이상의 열띤 댓글을 불러일으킨 것은 글의 논지가 아니었다. 단 한 줄의 문장, “I don’t read the code anymore(나는 더 이상 코드를 읽지 않는다)”가 개발자 커뮤니티를 두 쪽으로 갈랐다.
이 글은 단순한 도발이 아니다. 저자는 그 문장이 오해를 낳았다는 것을 인정하면서도, 자신의 입장을 철회하지 않는다. 오히려 한 발짝 더 나아가, 왜 더 많은 개발자들이 코드를 직접 읽는 것을 주된 검증 방식으로 삼아서는 안 되는지를 조목조목 논증한다. 이 분석은 그 논증의 흐름을 따라가면서, 관련된 최신 사례들과 산업 전반의 맥락을 함께 살펴보는 것을 목적으로 한다.
1. “코드를 읽지 않는다”는 말의 진짜 의미
저자가 “코드를 읽지 않는다”고 말할 때, 이것은 코드가 존재하지 않거나, 코드가 중요하지 않다는 뜻이 아니다. 그가 말하는 것은 훨씬 더 구체적이고 미묘한 개념이다.
저자의 정의에 따르면, “코드를 읽지 않는다”는 것은 대부분의 프로덕션 코드에 대해 줄 단위(line-by-line) 리뷰를 주된 검증 방법으로 삼지 않는다는 의미다. 대신 그가 집중하는 것은 스펙(spec), 테스트, diff, 그리고 프로덕션 신호들이다. 코드 자체는 여전히 중요하지만, 그것을 확인하는 방법이 근본적으로 달라졌다는 것이 핵심이다.
이 구분은 매우 중요하다. 코드를 직접 읽는 것이 코드의 정확성을 보장하는 최선의 방법이었던 시대가 있었다. 하지만 AI 에이전트가 하루에도 수천 줄의 코드를 생성하는 오늘날, 그 접근법은 물리적으로도, 경제적으로도 지속 가능하지 않다는 것이 저자의 주장이다. 검증의 방법론 자체가 진화해야 한다는 것이다.
2. 증거들: “나만 이런 게 아니다”
저자는 자신의 방식이 단지 개인적 기벽이 아님을 보여주기 위해 세 가지 강력한 사례를 제시한다. 이 사례들은 2025년 말에서 2026년 초에 걸쳐 실제로 일어난 일들이며, AI 보조 개발의 새로운 패러다임을 구체적으로 보여준다.
2-1. OpenAI의 하네스 엔지니어링(Harness Engineering)
2025년 8월, OpenAI 내부의 소규모 팀이 전례 없는 실험에 착수했다. 단 세 명의 엔지니어로 구성된 팀이 단 하나의 규칙을 세웠다. 인간이 직접 작성한 코드는 단 한 줄도 없어야 한다는 것이었다. 이 강제적 제약은 의도적이었다. 속도를 수십 배 향상시키는 데 반드시 필요한 것이 무엇인지를 찾아내기 위해서였다.
그 결과는 놀라웠다. 5개월 만에 그들은 100만 줄이 넘는 코드로 이루어진 실제 프로덕션 제품을 출시했고, 수백 명의 내부 사용자가 그것을 사용하게 되었다. 1,500개 이상의 Pull Request가 처리되었으며, 팀이 투자한 것은 코드의 품질 자체가 아니라 코드를 둘러싼 환경, 즉 문서화, 의존성 규칙, 린터(linter), 테스트 인프라, 관찰 가능성(observability)이었다.
OpenAI가 이 접근법에서 발견한 핵심 교훈은 다음과 같다. 에이전트의 능력이 병목이 아니었다. 병목은 에이전트를 둘러싼 구조와 피드백 메커니즘의 부재였다. 에이전트가 막히면, 팀은 “더 열심히 해봐”가 아닌 “무엇이 부족한가?”를 물었다. 개발 환경 자체를 개선하는 것이 해결책이었다.
특히 주목할 만한 것은 OpenAI가 채택한 엄격한 계층형 아키텍처였다. 각 비즈니스 도메인 내의 코드는 Types → Config → Repo → Service → Runtime → UI라는 고정된 순서로만 의존성을 가질 수 있었고, 이 규칙은 AI가 자동 생성한 커스텀 린터와 구조적 테스트로 기계적으로 강제되었다. 인간이 중심인 워크플로에서라면 답답하게 느껴질 이 규칙들이, AI 에이전트 환경에서는 오히려 생산성의 배율기(multiplier)가 되었다.
2-2. OpenClaw의 Peter Steinberger: 1인 개발팀의 신화
오스트리아 개발자 Peter Steinberger의 이야기는 또 다른 차원의 사례다. PSPDFKit이라는 PDF 프레임워크 회사를 약 1억 달러에 매각하고 3년간의 휴식 후 복귀한 그는, 이번에는 전통적인 소프트웨어 엔지니어링 방식을 완전히 내던지고 AI 에이전트를 중심에 두었다.
그의 개인 취미 프로젝트였던 OpenClaw(처음에는 Clawd로 시작해 여러 차례 이름이 바뀌었다)는 2026년 1월, GitHub 역사상 가장 빠른 속도로 성장하는 오픈소스 프로젝트가 되었다. Claude Code나 Codex보다 Google에서 더 많이 검색되었다는 사실은 그 인기를 단적으로 보여준다.
Steinberger는 1월 한 달에만 6,600개 이상의 commit을 올렸다. 그는 동시에 5~10개의 에이전트를 병렬로 돌리면서, 코드를 읽지 않고 출시한다고 공개적으로 밝혔다. 그의 말을 빌리자면, “커밋 기록만 보면 회사 같지만, 실제로는 집에서 혼자 재미로 하는 한 사람”이다. 그가 투자하는 것은 코드 줄을 읽는 것이 아니라, 리팩토링, 아키텍처, 테스트, 그리고 AI 코딩을 감싸는 하네스다.
단, 이 성공 이야기에는 중요한 경고가 뒤따른다. OpenClaw가 100,000개의 GitHub 스타를 돌파한 직후, 보안 연구자들이 ClawHub 마켓플레이스의 11.3%에 해당하는 341개의 악성 “스킬”을 발견했다. 이것들은 암호화폐, 자격 증명, 시스템 접근 권한을 탈취하도록 설계되어 있었다. 이 사건은 저자가 직접 인정하는 바와 같이, 코드를 읽지 않는 접근법이 안보에 취약할 수 있다는 비판을 현실로 보여주는 사례가 되었다.
2-3. Nicholas C. Zakas: 코더에서 오케스트레이터로
세 번째 사례는 ESLint를 만들고 O’Reilly 출판사에서 여러 권의 자바스크립트 책을 저술한 베테랑 소프트웨어 엔지니어 Nicholas C. Zakas가 2026년 1월에 발표한 글이다. 그의 논지는 명확하다. 미래의 소프트웨어 엔지니어링은 코드를 작성하는 일이 아니라, AI 에이전트를 오케스트레이팅(orchestrating)하는 일이 될 것이라는 것이다.
Zakas는 이 변화의 세 단계를 설명한다. 2024년 초에는 AI가 발전된 자동완성 수준이었고, 개발자는 코더(coder)였다. 그 후 AI가 복잡한 멀티파일 솔루션을 만들 수 있게 되자, 개발자는 컨덕터(conductor), 즉 오케스트라를 지휘하는 역할로 올라섰다. 그리고 2025년 말에 완전 자율적인 백그라운드 에이전트가 등장하면서, 개발자는 이제 여러 에이전트를 병렬로 조율하는 오케스트레이터(orchestrator)가 되었다. 중요한 기술이 문법과 구현에서 아키텍처, 명세(specification), 그리고 피드백 루프 설계로 이동했다는 것이다.
이 이미지는 2022년부터 2025년까지의 코드 언어 모델들의 HumanEval 벤치마크 성능 변화에서 시각적으로도 확인된다. 2022년에 10% 수준이었던 점수는 2025년에 90%를 넘어서며, 그 궤적은 기하급수적인 상승 곡선을 그린다. GPT-4에서 시작해 Claude 4.5, Gemini 2.5 Pro, Kimi-K2, DeepSeek-R1까지, 최신 모델들은 모두 이 벤치마크에서 90점을 넘어섰다. 이는 AI가 단순한 보조 도구를 넘어 코딩 작업의 핵심 실행자가 될 수 있음을 보여주는 객관적 데이터다.
3. 회의론자들의 반론과 저자의 응답
저자는 자신의 주장에 대한 반발을 진지하게 다룬다. 세 가지 주요 비판을 검토해보자.
3-1. 블랙박스 문제
한 댓글 작성자는 이렇게 썼다. “자동 촬영 모드로 사진을 찍고 결과를 보지 않는 것은 상상도 할 수 없다.” 코드를 읽지 않는 것은 블랙박스를 신뢰하는 것이나 마찬가지 아닌가라는 비판이다.
저자의 반론은 비유의 틀을 바꾸는 것에서 출발한다. 올바른 비유는 사진작가가 결과물(사진)을 보지 않는 것이 아니라, 사진기의 내부 메커니즘을 보지 않는 것이다. 우리는 이미 수십 년 전부터 자신이 들여다보지 않는 추상화 층위 위에서 코딩해왔다. 운영체제의 내부 구현, 언어 런타임, 표준 라이브러리, 프레임워크. 코드를 읽지 않는 것은 새로운 블랙박스를 채택하는 것이 아니라, 추상화의 층위를 한 단계 더 높이는 것이다.
3-2. 보안 문제
또 다른 댓글은 이렇게 걱정했다. “AI 회사들이 생성된 코드에 악성 백도어를 심는데 아무도 읽지 않는 상황을 상상하니 무섭다.”
저자는 이 우려를 진지하게 받아들인다. 하지만 그의 답은 이것이 “모든 줄을 읽어야 하는” 문제가 아니라 도구(tooling)의 문제라는 것이다. 정적 분석, 의존성 스캐닝, 보안 린터는 인간이 쓴 코드도 불안전하기 때문에 이미 존재한다. 해결책은 더 나은 자동화된 검증이다. 그리고 이것이 바로 하네스 우선 접근법이 강조하는 것이기도 하다. 물론, 보안에 민감한 영역에서는 인간 리뷰가 여전히 필수적이라는 점도 저자는 명시한다.
3-3. 버그가 쌓인다는 문제
이것이 가장 많이 제기된 비판이었다. “내 코드가 실패하면 사람들이 돈을 잃고, 비행기가 멈추고, 자동차가 고장난다. 코드를 읽어라”라는 주장이다.
저자도 이 비판의 데이터를 인용한다. CodeRabbit의 연구에 따르면, AI가 생성한 코드는 주요 소프트웨어 품질 범주 전반에 걸쳐 일반 코드보다 1.7배 더 많은 결함을 도입한다. 이것은 무시할 수 없는 수치다.
그러나 저자의 반론은 질문 자체를 바꾼다. “AI 코드가 평균적으로 버그가 더 많은가?”가 아니라, “잘 설계된 하네스 안에서 AI 코드가 동일한 속도에서 대안보다 더 많은 버그를 만드는가?”를 물어야 한다는 것이다. 그리고 그보다 더 중요한 질문은, “어느 쪽이 더 빨리 개선될 것인가?”다. 모델은 계속 나아지고 있다. 그 궤적에 베팅하는 것이 합리적이라는 것이 저자의 최종 입장이다.
4. 저자의 시스템: 하네스가 실제로 어떻게 작동하는가
저자는 자신의 구체적인 방법론을 공개한다. 이것은 단순히 “코드를 안 읽는다”는 게으른 실천이 아니라, 매우 구조화되고 엄격한 시스템이다.
모든 것은 스펙에서 시작된다. AI와의 대화를 통해 작성된 매우 상세한 스펙은, 요구사항 ID를 통해 프로덕트 스펙에서 실행 계획까지 추적이 가능하도록 구조화되어 있다. 실행 계획의 모든 태스크는 어떻게 검증될지를 명시하는 수락 기준(acceptance criteria)을 가진다. (TEST)는 자동화 테스트, (BROWSER:DOM)은 시각적 확인, (MANUAL)은 다른 방법이 없을 때의 최후 수단이며, 이마저도 시스템이 먼저 curl이나 bash 스크립트로 자동 검사를 시도한다.
그가 구축한 하네스는 35개 이상의 스킬, 구조화된 에이전트 지침, 그리고 계층적 검증 인프라로 이루어져 있다. 핵심 구성요소들을 살펴보면 다음과 같다.
첫째, 인프라로서의 에이전트 지침이다. AGENTS.md 파일은 주요 규칙집 역할을 한다. 보수적인 편집, 기존 인터페이스 파괴 금지, TDD(테스트 주도 개발), 추측하지 말고 질문하라는 원칙들이 담겨 있다. VISION.md는 전략적 경계를 정의한다.
둘째, 줄 단위 리뷰 대신 계층적 검증이다. 각 단계 후에는 타입 체킹, 린팅, 테스트, 빌드, 뮤테이션 테스트, 보안 스캔을 포함하는 멀티레이어 게이트가 실행된다. 브라우저 도구가 있으면 자동화된 브라우저 체크도 진행된다. 그리고 저자가 가장 좋아한다고 말하는 부분은, diff를 다른 AI 모델(Codex CLI)에게 보내 “두 번째 의견”을 구하는 것이다. 교차 모델 검증은 단일 모델의 맹점을 잡아낸다.
이 시스템에서 코드는 관리의 대상이 아니라 프로세스의 출력물이다. 저자의 주의는 코드 자체가 아닌, 스펙 층위와 하네스와 아키텍처에 향한다.
5. 언제 코드를 읽어야 하는가: 필요한 예외들
저자는 자신이 절대 코드를 읽지 않는다고 주장하지 않는다. 오히려 그는 코드를 읽어야 하는 구체적인 상황들을 명시한다. 그것은 예외이지 규칙이 아니다.
모든 것이 테스트를 통과하지만 제품이 뭔가 이상하게 느껴질 때, 중요한 아키텍처 결정을 내릴 때, 여러 에이전트가 해결하지 못한 실패를 디버깅할 때, 저자는 코드를 직접 읽는다. 단, 그때도 그의 목적은 코드 자체의 문제를 해결하는 것이 아니라, 하네스의 어느 부분에 구멍이 있는지를 파악하는 것이다. 같은 문제가 반복되지 않도록 하는 것이 목표다.
그리고 보다 근본적인 예외들도 있다. 안전에 중요한 시스템, 보안에 민감한 서비스, 중요한 아키텍처 결정이 그것들이다. 이런 경우에는 소프트웨어 엔지니어링이 전통적인 의미의 엔지니어링이며, 인간의 주의와 판단이 그 어느 때보다 중요하다. 오히려 AI가 생성하는 코드의 양이 많아질수록, 이런 영역에서의 인간 리뷰는 더 중요해진다.
6. 마젠타의 아이들: 자동화와 판단력의 딜레마
저자가 인용하는 항공 분야의 비유는 이 논의에 깊이를 더한다. “마젠타의 아이들(Children of the Magenta)”이라는 개념은, 조종사들이 내비게이션 화면에 마젠타색으로 표시되는 프로그래밍된 비행 경로를 맹목적으로 따르는 경향을 지칭한다.
전 항공 기장 Vanderburgh는 자동화 의존성이 단순히 기술의 문제가 아님을 누구보다 먼저 이해했다. 그것은 언제 자동화를 사용해야 하는지에 대한 판단력을 잃는 문제였다. 자동화 수준이 높아야 할 상황에서 조종사들은 기본기로 내려올 줄 알아야 했지만, 자동화에 길들여진 채 그 능력을 잃어가고 있었다.
교훈은 자동 조종 장치를 사용하지 말라는 것이 아니다. 자동 조종 장치는 훌륭하고, 오늘날 비행기가 이토록 안전한 이유 중 하나다. 교훈은 그것을 사용하되, 개입할 능력을 유지하라는 것이다. 무언가 잘못되면, 자동화 수준을 낮춘다. 모든 비행을 수동으로 조종하라고 하지는 않는다. 그것은 더 비효율적이고 더 위험하다. 저자가 말하는 균형이 바로 이것이다.
AI 시대의 개발자에게도 같은 논리가 적용된다. AI가 생성한 코드를 하네스를 통해 신뢰하되, 개입할 능력은 잃지 말아야 한다. 그리고 언제 직접 내려와야 하는지를 판단할 줄 알아야 한다.
7. 역사적 맥락: 추상화는 항상 저항을 만났다
저자는 현재의 논쟁을 역사의 반복으로 본다. 모든 컴퓨팅의 새로운 추상화 층위는 저항을 만났다.
가장 적절한 역사적 유사점은 1973년에 찾을 수 있다. Dennis Ritchie와 Ken Thompson이 Unix를 C 언어로 재작성하기로 결정했을 때, 고수준 언어로 운영체제 전체를 작성한다는 발상은 터무니없는 것으로 여겨졌다. 당시 비판의 목소리는 지금과 놀라울 만큼 비슷했다. 너무 느릴 것이다. 하드웨어에 대한 통제권을 잃을 것이다. 복잡성이 증가해 유지보수가 불가능할 것이다. 하지만 C의 추상화는 Unix를 역사상 가장 이식성 높고 영향력 있는 운영체제로 만들었다.
패턴은 반복된다. 추상화되고 있는 층위에서 전문성을 가진 사람들은, 그 층위를 이해해야 한다고 주장한다. 그들이 옳다. 어떤 사람들에게는, 어떤 경우에는. 하지만 대부분의 사람들의 시간과 대부분의 경우는, 더 높은 추상화 층위에서 일하는 것이 더 잘 맞는다.
어셈블리에서 C로, C에서 고수준 언어로, 이제는 자연어 명세에서 AI 생성 코드로. 매번 “이 층위는 너무 중요해서 포기할 수 없다”는 목소리가 있었고, 매번 새로운 추상화가 결국 승리했다.
8. 궤적에 베팅하기
저자의 최종 입장은 명확하다. 코드를 읽지 않는 것은 도구가 완벽하다는 주장이 아니다. 도구가 많은 사용 사례에 충분히 좋고, 믿을 수 없을 만큼 빠르게 개선되고 있다는 것에 베팅하는 것이다.
Greg Brockman의 말처럼, AI 생성 코드에 대해서도 인간이 작성한 코드와 동일한 기준을 유지해야 한다. 그 기준을 충족시키는 방법이 줄 단위 리뷰에서 하네스 기반 검증으로 바뀌고 있을 뿐이다.
저자가 촉구하는 것은 무책임한 방관이 아니다. 개발자들이 자신의 인식(priors)을 업데이트하라는 것이다. 코드는 점점 구현 세부사항이 되어가고 있다. 중요한 산출물(artifact)은 스펙, 아키텍처, 검증 층위다. 코드가 중요하지 않다는 게 아니라, 코드를 직접 읽고 상호작용하는 것이 그것이 올바른지 확인하는 방법이 아니게 되어가고 있다는 것이다.
9. 비판적 시각: 이 관점의 한계와 보완점
이 글이 제시하는 관점은 설득력 있지만, 몇 가지 중요한 한계와 전제조건도 함께 고려해야 한다.
첫째, 이 접근법은 경험 있는 엔지니어를 전제로 한다. 저자 자신이 인정하듯이, 그는 오랜 세월 코드를 직접 작성해왔다. “코드가 어떻게 생겨야 하는지 안다. 그것을 보지 않기로 선택하는 것이다.” 코드가 어떻게 생겨야 하는지도 모르는 사람이 같은 방식으로 임한다면, 이것은 매우 다른 위험을 초래한다. 즉, 기초 없는 레버리지는 인지적 부채(cognitive debt)를 쌓는다.
둘째, OpenClaw의 보안 사고가 보여주듯이, 하네스 우선 접근법은 생태계 전반의 신뢰 문제를 해결하지 못한다. 당신의 코드 자체는 자동화된 검증을 통과할지라도, 그것이 의존하는 외부 구성요소나 마켓플레이스의 컨텐츠는 또 다른 위험 벡터가 된다.
셋째, 기업 환경, 특히 금융, 의료, 안전 시스템과 같은 규제 산업에서는 이 접근법이 그대로 적용되기 어렵다. 감사 추적, 컴플라이언스 요구사항, 법적 책임 등이 인간 리뷰를 요구한다.
그럼에도 불구하고, 이 글이 던지는 핵심 질문은 여전히 유효하다. 당신의 검증 방법이 당신이 확인해야 할 코드의 속도와 양을 따라잡을 수 있는가? 그 질문에 대한 정직한 대답이 방법론의 진화를 이끌 것이다.
결론: 코드에서 하네스로, 구현에서 명세로
Ben Shoemaker의 글은 단순한 도발이 아니라, AI 시대의 소프트웨어 개발에 대한 심층적인 철학적 입장이다. 그의 주장을 요약하면 이렇다.
코드는 수단이지 목적이 아니다. 그것의 정확성을 보장하는 방법은 직접 읽는 것에서 잘 설계된 환경과 자동화된 검증으로 이동하고 있다. 스펙, 아키텍처, 테스트 인프라, 관찰 가능성이 새로운 중요한 산출물이다. 코드는 그 과정의 출력물이 되었다.
OpenAI의 하네스 엔지니어링, Peter Steinberger의 1인 에이전트 오케스트레이션, Nicholas Zakas의 코더에서 오케스트레이터로의 진화 논의가 모두 같은 방향을 가리키고 있다. 개발자의 핵심 역량은 코드를 쓰는 것에서, 올바른 것을 만들 환경을 설계하고, 그것이 올바른지 검증하는 능력으로 이동하고 있다.
항상 그랬듯이, 추상화의 새로운 층위는 저항을 만났다. 그리고 항상 그랬듯이, 그것은 결국 새로운 방식의 전문성을 요구하게 될 것이다. 코드를 어떻게 쓰는지가 아니라, 무엇을 만들어야 하는지와 그것이 제대로 작동하는지를 판단하는 능력. 이것이 AI 에이전트 시대의 개발자가 키워야 할 근본적인 역량이다.
원문: In defense of not reading the code — Ben Shoemaker
참고: OpenAI Harness Engineering 블로그, The Pragmatic Engineer: The creator of Clawd, Nicholas Zakas: From Coder to Orchestrator
작성일: 2026-03-05