# 코드를 읽지 않는 것에 대한 옹호 > Clean Markdown view of GeekNews topic #26966. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26966](https://news.hada.io/topic?id=26966) - GeekNews Markdown: [https://news.hada.io/topic/26966.md](https://news.hada.io/topic/26966.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-02-25T00:12:57+09:00 - Updated: 2026-02-25T00:12:57+09:00 - Original source: [benshoemaker.us](https://www.benshoemaker.us/writing/in-defense-of-not-reading-the-code/) - Points: 38 - Comments: 3 ## Summary **“코드를 읽지 않는다”는 것은 코드 품질 검증의 중심을 라인별 리뷰에서 ** 스펙·테스트·자동 검증 인프라**로 옮기자는 것이라고 설명합니다. OpenAI의 Harness Engineering과 OpenClaw 사례는 코드보다 하네스 설계와 피드백 루프 구축에 집중한 접근을 보여줍니다. 이는 코드 읽기를 배제하자는 극단이 아니라, ** 안전·보안·아키텍처 결정 시 직접 검토**를 남겨두되 대부분의 품질 보증을 자동화 계층에 위임하자는 균형적 관점입니다. 코드가 점점 구현 세부사항으로 이동하는 흐름 속에서, 개발자의 핵심 역량은 아키텍처와 검증 설계로 재편되고 있습니다. ## Topic Body - "코드를 읽지 않는다"는 의미는 라인별 리뷰 대신 **스펙, 테스트, 정적 분석, 프로덕션 시그널**에 의존한다는 것이며, 특정 리스크 영역에서는 코드 리뷰로 에스컬레이션 가능 - OpenAI의 **Harness Engineering**과 OpenClaw 사례는 코드 대신 **테스트·관찰·자동 검증 인프라**에 집중한 접근을 보여줌 - 블랙박스, 보안, 버그 누적 등 **회의론에 대한 반론**으로 추상화 계층의 역사적 패턴과 자동화 검증 도구의 중요성을 강조 - 코드 읽기를 완전히 배제하는 것이 아니라, **안전·보안·아키텍처 결정 시에는 직접 검토가 필요**하다는 균형적 입장을 제시 - 코드는 점점 **구현 세부사항**이 되고 있으며, 스펙·아키텍처·검증 레이어가 핵심 산출물로 부상하는 궤적에 베팅해야 함 --- ### "코드를 읽지 않는다"의 정확한 의미 - 이전 글의 “나는 더 이상 코드를 읽지 않는다”라는 문장이 [Hacker News에서 **200개 이상의 열띤 댓글**을 촉발](https://news.ycombinator.com/item?id=46891131) - 정확한 의미는 대부분의 프로덕트 코드에 대해 **라인별 리뷰를 기본 검증 방식으로 삼지 않는다**는 뜻 - 스펙과 테스트, 변경된 diff의 선별 검토, 프로덕션 시그널은 여전히 확인하며, 특정 리스크 영역에서는 코드 리딩으로 에스컬레이션 가능 - 코드를 읽지 않는 이유는 코드가 덜 중요해서가 아니라, 특히 대규모 환경에서 **라인별 독해가 정확성을 보장하는 가장 효과적인 방법이 아니기 때문** ### 근거가 되는 사례들 - ## OpenAI의 Harness Engineering - OpenAI가 **[Harness Engineering](https://openai.com/ko-KR/index/harness-engineering/)** 블로그 포스트를 통해, 소프트웨어 엔지니어링 팀의 중심 역할이 코드 작성에서 **환경 설계, 의도 명세, 피드백 루프 구축**으로 이동했음을 설명 - 3명의 엔지니어가 **Codex 에이전트**만으로 100만 줄의 코드를 생성해 수백 명의 내부 사용자가 사용하는 제품 구축 - 코드 자체보다 그 주변의 **하네스(harness)**—문서, 의존성 규칙, 린터, 테스트 인프라, 관측 체계—에 집중 투자 - 라인 단위 코드 리뷰에는 별도 투자하지 않음 - ## OpenClaw - 단 한 명이 팀 없이 만든 **OpenClaw**, 최근 몇 달 사이 가장 빠르게 성장한 오픈소스 프로젝트 중 하나로 **10만 개 이상의 GitHub 스타** 확보 - 5~10개의 에이전트를 병렬로 운영하는 구조, 초보가 아닌 **경험 많은 엔지니어**가 설계·운영 - “[나는 읽지 않는 코드를 배포한다](https://news.hada.io/topic?id=26222)”라는 제목의 인터뷰에서 리팩토링, 아키텍처, 테스트, 그리고 AI 코딩을 둘러싼 하네스에 집중 투자한다고 언급 - ## Coder에서 Orchestrator로 - ESLint를 만들고 **O'Reilly 서적을 여러 권 집필한 경력 엔지니어**가 [최근 글](https://humanwhocodes.com/blog/2026/01/coder-orchestrator-future-software-engineering/)에서, 미래의 소프트웨어 엔지니어링은 코드 작성이 아니라 **AI 에이전트 오케스트레이션**이 중심이 될 것이라 전망 - 핵심 역량이 문법과 구현에서 **아키텍처 설계, 명세 작성, 피드백 루프 설계**로 이동 중 ### 회의론에 대한 반론 - ## 블랙박스 비판 - "블랙박스 접근법을 자발적으로 선택하는 사례가 있느냐"는 비판에 대해, **[코드의 결과물은 코드 자체가 아니라 제품](https://news.ycombinator.com/item?id=46892590)** 이라는 점을 강조 - 사진가가 사진을 보지 않는 것이 아니라, 사진을 만들어내는 **카메라 내부 구조를 들여다보지 않는 것**에 더 가까운 비유 - 우리가 직접 들여다보지 않는 **추상화 계층 위에서 시스템을 구축하는 방식**은 소프트웨어를 포함한 다양한 엔지니어링 영역에서 이미 일반적인 관행 - ## 보안 우려 - AI가 생성한 코드에 **백도어가 삽입될 수 있다는 우려**에 대해, 이는 “모든 줄을 사람이 읽어야 한다”의 문제가 아니라 **도구(tooling)와 검증 체계의 문제** - 정적 분석, 의존성 스캐닝, 보안 린터는 인간 역시 취약한 코드를 작성하기 때문에 존재하며, 해법은 **더 강력한 자동화 검증 체계**, 즉 하네스 중심 접근과 동일한 방향 - 다만 **보안에 특히 민감한 영역**에서는 여전히 인간 리뷰가 필요 - ## 버그 누적 문제 - “코드가 실패하면 사람들의 돈이 사라지고, 비행기가 멈추고, 자동차가 고장 난다. 코드를 읽어라”는 비판이 가장 빈번 - CodeRabbit 데이터에 따르면 AI 생성 코드는 **[소프트웨어 품질 전반에서 1.7배 더 많은 결함](https://www.coderabbit.ai/whitepapers/state-of-AI-vs-human-code-generation-report)** 발생 - 그러나 AI 코딩 방식은 다양하며, **스펙·계층적 테스트·아키텍처 제약을 갖춘 하네스 중심 개발**은 단순한 바이브 코딩과 근본적으로 다름 - 한 댓글에서 제시된 접근: 스펙·테스트·정적 분석에 의존하고 **85% 이상 테스트 커버리지** 유지, 점진적으로 범위를 넓히는 통합 테스트인 **테스팅 래더(testing ladders)** 구축, 벤치마킹과 강도 높은 도그푸딩(dogfooding)으로 오류를 조기에 노출 - 핵심 질문은 “AI 코드가 평균적으로 버그가 더 많은가?”가 아니라, **“잘 설계된 하네스 안에서 동일한 속도로 개발했을 때 대안보다 더 많은 버그를 내는가?”** - Greg Brockman(OpenAI 공동 창업자) 역시 **[인간이 작성한 코드와 동일한 기준을 적용해야 한다](https://x.com/gdb/status/2019566641491963946)** 는 입장 ### 실제 시스템 구성 - 커리어 대부분 동안 코드를 작성해 왔고, 주로 내부 도구였지만 실제 사용자가 의존하는 시스템들 - 코드의 형태와 구조를 이해하고 있지만 **직접 읽지 않기로 선택** - ## 스펙 기반 워크플로우 - 에이전트가 코드를 작성하기 전에 AI와의 대화를 통해 **매우 구체적이고 상세한 스펙**을 먼저 작성 - **요구사항 ID**를 통해 제품 스펙에서 실행 계획까지 추적 가능하도록 구조화 - 실행 계획의 모든 태스크에 검증 방식이 명시된 수용 기준 포함 - 자동 테스트는 **(TEST)** - 시각적 확인은 **(BROWSER:DOM)** - 다른 방법이 없을 때만 **(MANUAL)** 사용하며, 그 경우에도 가능한 한 curl이나 bash 기반 자동 체크를 먼저 생성 시도 - 구체적인 검증 메타데이터가 없는 태스크는 **감사(audit) 스킬이 작업 시작 전에 차단** - ## AI Coding Toolkit (하네스) - 프롬프트, 스킬, 훅, 스크립트로 구성된 툴킷이 에이전트의 작업 방식을 제약하며, **35개 이상의 스킬**, 구조화된 에이전트 지침, 계층적 검증 인프라 포함 - **에이전트 지침을 인프라로 관리** - AGENTS.md는 주요 규칙집 역할: 보수적 수정, 기존 인터페이스 유지, TDD 준수, 추측 금지, git 히스토리 재작성 금지 - VISION.md는 전략적 경계를 정의 - **계층적 검증 시스템**을 운영 - 각 단계 종료 후 체크포인트 스킬이 타입 체킹, 린팅, 테스트, 빌드, 뮤테이션 테스트, 보안 스캔을 포함한 다층 게이트 실행 - 브라우저 도구가 가능할 경우 자동 브라우저 검증 수행 - 변경된 diff를 **다른 AI 모델(Codex CLI)** 에 전달해 세컨드 오피니언 리뷰 수행 - **크로스 모델 검증**으로 단일 모델의 사각지대 보완 - 코드를 직접 읽는 경우도 있으나 **예외적인 상황에 한정** - 모든 테스트가 통과했지만 제품 동작이 어색하게 느껴질 때 - 중대한 아키텍처 결정을 내려야 할 때 - 여러 에이전트가 해결하지 못한 장애를 디버깅할 때 - 이런 경우에도 목적은 코드 자체 분석이 아니라, **하네스의 어떤 공백이 문제를 허용했는지 파악해 재발을 막는 것** ### 코드를 읽어야 할 때 - **안전이 직접적으로 걸린 시스템**, **보안에 민감한 서비스**, **중대한 아키텍처 결정**에서는 소프트웨어 엔지니어링이 곧 공학이며, 지금처럼 코드가 대량 생성되는 시대에는 **그 중요성이 오히려 더 커짐** - 항공 분야의 **"[Children of the Magenta](https://www.childrenofthemagenta.com/p/what-are-children-of-the-magenta)"** 비유는 조종사가 내비게이션 화면의 마젠타색 비행 경로에 과도하게 의존하게 된 현상을 가리킴 - 교훈은 “오토파일럿을 쓰지 말라”가 아니라, **필요할 때 개입할 수 있는 능력을 유지하라**는 것 - 문제가 생기면 **자동화 수준을 낮춰 기본기로 돌아갈 수 있어야** 하지만, 모든 비행을 항상 수동으로 하라는 요구는 비효율적이고 더 위험 - 자동화를 활용하되 개입 능력을 잃지 않는 균형이 핵심 ### 궤적에 베팅하라 - 컴퓨팅의 모든 추상화 계층은 등장할 때마다 저항을 받았고, **1973년 Dennis Ritchie와 Ken Thompson이 Unix를 C로 재작성한 사례**가 대표적 - Cline의 글도 참고 [어셈블리에서 AI로: '바이브 코딩'이 우리 추상화에서 또 다른 챕터인 이유](https://cline.bot/blog/from-assembly-to-ai-why-vibe-coding-is-just-another-chapter-in-our-abstraction-story) - 당시에는 느려질 것, 하드웨어 제어를 잃을 것, 복잡성이 유지보수를 어렵게 할 것이라는 비판이 있었지만, C의 추상화는 Unix를 **높은 이식성과 영향력을 가진 운영체제**로 확장 - 반복되는 패턴은, **추상화되는 계층에 전문성을 가진 사람들**이 그 계층 이해의 중요성을 강조하며, 일부 상황에서는 타당하지만 대부분의 시간은 **더 높은 추상화 계층에서 사고하고 설계하는 데 쓰이는 경향** - 코드를 읽지 않는다는 선택은 도구가 완벽하다는 선언이 아니라, **많은 사용 사례에서 이미 충분히 유효하며 빠르게 개선되고 있다는 흐름에 대한 판단** - 코드가 사라지는 것이 아니라 점점 **구현의 세부사항**으로 이동하고 있으며, 대신 **스펙, 아키텍처, 검증 레이어**가 핵심 산출물로 부상 ## Comments ### Comment 51890 - Author: foriequal0 - Created: 2026-02-25T18:33:19+09:00 - Points: 2 AI 프로그래밍이 추상화나 자동화라기보다 오히려 외부화/외주화에 가까운 것 같습니다. 설계 및 검증이 고도화와 정밀화를 위한 요소라기보다 저신뢰사회를 간신히 붙들어매는 규제같은 요소로 도입되는 느낌이구요. ### Comment 51898 - Author: sang459 - Created: 2026-02-25T20:32:09+09:00 - Points: 1 - Parent comment: 51890 - Depth: 1 정확한 분석이네요 AI 프로그래밍은 근본적으로 확률적이라는 점이 중요한 것 같습니다 ### Comment 52257 - Author: chamchi - Created: 2026-03-03T13:09:15+09:00 - Points: 1 AI로 라이브러리 만들고 있는데 리팩토링 및 코드퀄리티 증가, 결점 체크도 AI로 돌려야 되는 것 같습니다