코드를 읽지 않는 것에 대한 옹호

(benshoemaker.us)

38P by GN⁺ 3달전 | ★ favorite | 댓글 3개

"코드를 읽지 않는다"는 의미는 라인별 리뷰 대신 스펙, 테스트, 정적 분석, 프로덕션 시그널에 의존한다는 것이며, 특정 리스크 영역에서는 코드 리뷰로 에스컬레이션 가능
OpenAI의 Harness Engineering과 OpenClaw 사례는 코드 대신 테스트·관찰·자동 검증 인프라에 집중한 접근을 보여줌
블랙박스, 보안, 버그 누적 등 회의론에 대한 반론으로 추상화 계층의 역사적 패턴과 자동화 검증 도구의 중요성을 강조
코드 읽기를 완전히 배제하는 것이 아니라, 안전·보안·아키텍처 결정 시에는 직접 검토가 필요하다는 균형적 입장을 제시
코드는 점점 구현 세부사항이 되고 있으며, 스펙·아키텍처·검증 레이어가 핵심 산출물로 부상하는 궤적에 베팅해야 함

"코드를 읽지 않는다"의 정확한 의미

이전 글의 “나는 더 이상 코드를 읽지 않는다”라는 문장이 Hacker News에서 200개 이상의 열띤 댓글을 촉발
정확한 의미는 대부분의 프로덕트 코드에 대해 라인별 리뷰를 기본 검증 방식으로 삼지 않는다는 뜻
스펙과 테스트, 변경된 diff의 선별 검토, 프로덕션 시그널은 여전히 확인하며, 특정 리스크 영역에서는 코드 리딩으로 에스컬레이션 가능
코드를 읽지 않는 이유는 코드가 덜 중요해서가 아니라, 특히 대규모 환경에서 라인별 독해가 정확성을 보장하는 가장 효과적인 방법이 아니기 때문

근거가 되는 사례들

OpenAI의 Harness Engineering
- OpenAI가 Harness Engineering 블로그 포스트를 통해, 소프트웨어 엔지니어링 팀의 중심 역할이 코드 작성에서 환경 설계, 의도 명세, 피드백 루프 구축으로 이동했음을 설명
- 3명의 엔지니어가 Codex 에이전트만으로 100만 줄의 코드를 생성해 수백 명의 내부 사용자가 사용하는 제품 구축
- 코드 자체보다 그 주변의 하네스(harness)—문서, 의존성 규칙, 린터, 테스트 인프라, 관측 체계—에 집중 투자
- 라인 단위 코드 리뷰에는 별도 투자하지 않음
OpenClaw
- 단 한 명이 팀 없이 만든 OpenClaw, 최근 몇 달 사이 가장 빠르게 성장한 오픈소스 프로젝트 중 하나로 10만 개 이상의 GitHub 스타 확보
- 5~10개의 에이전트를 병렬로 운영하는 구조, 초보가 아닌 경험 많은 엔지니어가 설계·운영
- “나는 읽지 않는 코드를 배포한다”라는 제목의 인터뷰에서 리팩토링, 아키텍처, 테스트, 그리고 AI 코딩을 둘러싼 하네스에 집중 투자한다고 언급
Coder에서 Orchestrator로
- ESLint를 만들고 O'Reilly 서적을 여러 권 집필한 경력 엔지니어가 최근 글에서, 미래의 소프트웨어 엔지니어링은 코드 작성이 아니라 AI 에이전트 오케스트레이션이 중심이 될 것이라 전망
- 핵심 역량이 문법과 구현에서 아키텍처 설계, 명세 작성, 피드백 루프 설계로 이동 중

회의론에 대한 반론

블랙박스 비판
- "블랙박스 접근법을 자발적으로 선택하는 사례가 있느냐"는 비판에 대해, 코드의 결과물은 코드 자체가 아니라 제품 이라는 점을 강조
- 사진가가 사진을 보지 않는 것이 아니라, 사진을 만들어내는 카메라 내부 구조를 들여다보지 않는 것에 더 가까운 비유
- 우리가 직접 들여다보지 않는 추상화 계층 위에서 시스템을 구축하는 방식은 소프트웨어를 포함한 다양한 엔지니어링 영역에서 이미 일반적인 관행
보안 우려
- AI가 생성한 코드에 백도어가 삽입될 수 있다는 우려에 대해, 이는 “모든 줄을 사람이 읽어야 한다”의 문제가 아니라 도구(tooling)와 검증 체계의 문제
- 정적 분석, 의존성 스캐닝, 보안 린터는 인간 역시 취약한 코드를 작성하기 때문에 존재하며, 해법은 더 강력한 자동화 검증 체계, 즉 하네스 중심 접근과 동일한 방향
- 다만 보안에 특히 민감한 영역에서는 여전히 인간 리뷰가 필요
버그 누적 문제
- “코드가 실패하면 사람들의 돈이 사라지고, 비행기가 멈추고, 자동차가 고장 난다. 코드를 읽어라”는 비판이 가장 빈번
- CodeRabbit 데이터에 따르면 AI 생성 코드는 소프트웨어 품질 전반에서 1.7배 더 많은 결함 발생
- 그러나 AI 코딩 방식은 다양하며, 스펙·계층적 테스트·아키텍처 제약을 갖춘 하네스 중심 개발은 단순한 바이브 코딩과 근본적으로 다름
- 한 댓글에서 제시된 접근: 스펙·테스트·정적 분석에 의존하고 85% 이상 테스트 커버리지 유지, 점진적으로 범위를 넓히는 통합 테스트인 테스팅 래더(testing ladders) 구축, 벤치마킹과 강도 높은 도그푸딩(dogfooding)으로 오류를 조기에 노출
- 핵심 질문은 “AI 코드가 평균적으로 버그가 더 많은가?”가 아니라, “잘 설계된 하네스 안에서 동일한 속도로 개발했을 때 대안보다 더 많은 버그를 내는가?”
- Greg Brockman(OpenAI 공동 창업자) 역시 인간이 작성한 코드와 동일한 기준을 적용해야 한다 는 입장

실제 시스템 구성

커리어 대부분 동안 코드를 작성해 왔고, 주로 내부 도구였지만 실제 사용자가 의존하는 시스템들
코드의 형태와 구조를 이해하고 있지만 직접 읽지 않기로 선택
스펙 기반 워크플로우
- 에이전트가 코드를 작성하기 전에 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" 비유는 조종사가 내비게이션 화면의 마젠타색 비행 경로에 과도하게 의존하게 된 현상을 가리킴
- 교훈은 “오토파일럿을 쓰지 말라”가 아니라, 필요할 때 개입할 수 있는 능력을 유지하라는 것
- 문제가 생기면 자동화 수준을 낮춰 기본기로 돌아갈 수 있어야 하지만, 모든 비행을 항상 수동으로 하라는 요구는 비효율적이고 더 위험
- 자동화를 활용하되 개입 능력을 잃지 않는 균형이 핵심

궤적에 베팅하라

컴퓨팅의 모든 추상화 계층은 등장할 때마다 저항을 받았고, 1973년 Dennis Ritchie와 Ken Thompson이 Unix를 C로 재작성한 사례가 대표적
- Cline의 글도 참고 어셈블리에서 AI로: '바이브 코딩'이 우리 추상화에서 또 다른 챕터인 이유
당시에는 느려질 것, 하드웨어 제어를 잃을 것, 복잡성이 유지보수를 어렵게 할 것이라는 비판이 있었지만, C의 추상화는 Unix를 높은 이식성과 영향력을 가진 운영체제로 확장
반복되는 패턴은, 추상화되는 계층에 전문성을 가진 사람들이 그 계층 이해의 중요성을 강조하며, 일부 상황에서는 타당하지만 대부분의 시간은 더 높은 추상화 계층에서 사고하고 설계하는 데 쓰이는 경향
코드를 읽지 않는다는 선택은 도구가 완벽하다는 선언이 아니라, 많은 사용 사례에서 이미 충분히 유효하며 빠르게 개선되고 있다는 흐름에 대한 판단
코드가 사라지는 것이 아니라 점점 구현의 세부사항으로 이동하고 있으며, 대신 스펙, 아키텍처, 검증 레이어가 핵심 산출물로 부상