▲

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

 (benshoemaker.us)
1P by GN⁺ 4시간전 | ★ favorite | 댓글과 토론
  • "코드를 읽지 않는다"는 의미는 라인별 리뷰 대신 스펙, 테스트, 정적 분석, 프로덕션 시그널에 의존한다는 것이며, 특정 리스크 영역에서는 코드 리뷰로 에스컬레이션 가능
  • 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로 재작성한 사례가 대표적
  • 당시에는 느려질 것, 하드웨어 제어를 잃을 것, 복잡성이 유지보수를 어렵게 할 것이라는 비판이 있었지만, C의 추상화는 Unix를 높은 이식성과 영향력을 가진 운영체제로 확장
  • 반복되는 패턴은, 추상화되는 계층에 전문성을 가진 사람들이 그 계층 이해의 중요성을 강조하며, 일부 상황에서는 타당하지만 대부분의 시간은 더 높은 추상화 계층에서 사고하고 설계하는 데 쓰이는 경향
  • 코드를 읽지 않는다는 선택은 도구가 완벽하다는 선언이 아니라, 많은 사용 사례에서 이미 충분히 유효하며 빠르게 개선되고 있다는 흐름에 대한 판단
  • 코드가 사라지는 것이 아니라 점점 구현의 세부사항으로 이동하고 있으며, 대신 스펙, 아키텍처, 검증 레이어가 핵심 산출물로 부상