소프트웨어 팩토리가 실패하는 이유: 하네스 엔지니어링만으로는 부족함

 (github.com/humanlayer)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 사람이 코드를 읽고 쓰지 않는 무인(lights-off) 소프트웨어 팩토리는 생성 속도를 높이지만, 장기 유지보수성을 판단할 인간까지 제거해 복잡한 프로덕션 코드베이스에서 작동하기 어려움
  • 코딩 모델의 강화학습은 테스트 통과처럼 빠르고 명확한 보상을 최적화하며, 수개월 뒤 드러나는 나쁜 설계 비용에는 벌점을 주지 못함
  • SWE-bench 계열은 버그 수정과 기존 테스트 보존을 평가하지만, 무분별한 try/catch·타입 캐스트·shotgun surgery처럼 코드 품질을 서서히 악화시키는 변경은 걸러내지 못함
  • 현재는 인간이 코드 리뷰를 맡고 제품 요구사항·시스템 아키텍처·프로그램 설계·수직 슬라이스를 구현 전에 검토해야 재작업과 대규모 AI 생성 코드 리뷰를 줄일 수 있음
  • 모델의 제약을 인정하면 무리한 10~100배 자동화 대신 인간 수준에 가까운 품질을 유지하면서 2~3배 빠르게 개발할 수 있으며, 핵심 판단과 코드 읽기는 아직 외주화할 수 없음

루프 중심 소프트웨어 팩토리의 약속과 현실

  • AI 코딩의 프로덕션 도입 경쟁에서 하네스와 에이전트 루프를 늘리면 된다는 인식이 확산됨
  • 이 접근은 사람이 병목이고 모델은 충분히 좋으며, 코드 생성 비용이 사실상 낮으므로 더 많이 출시하면 된다는 전제를 둠
  • 목표는 10~100배 속도, 높은 품질, 인간 코드 리뷰 제거를 동시에 달성하는 것임
    • 린터를 더 구성하고 PR 리뷰 봇에 적대적 검토를 지시하면 소프트웨어를 스스로 안전하게 만들 수 있다고 봄
  • 실제 현장에서는 코딩 에이전트의 실수로 장애가 발생하고, 코드베이스가 빠르게 무너진다는 사례가 나타남
  • Faros AI 보고서는 AI 코딩 도구 도입 이후 다음 변화를 관찰함
    • 리뷰 댓글 수와 길이는 늘었지만, 리뷰 없이 병합되는 PR도 많아짐
    • 인시던트와 개발자당 버그가 증가함
    • 다만 검증된 인과관계가 아니라 상관관계 신호에 가까움
  • StrongDM의 결과를 보여주는 확정적 데이터는 찾기 어려우며, 2월부터 6월 사이 공개된 업데이트도 드문 편임

복잡한 코드베이스는 바이브 코딩과 다른 문제

  • 소수만 사용하는 사이드 프로젝트와 10년 된 엔터프라이즈 시스템을 유지하는 팀은 공유하는 제약이 거의 없음
  • 바이브 코딩 자체가 아니라 복잡한 코드베이스의 어려운 문제와 프로덕션 유지보수가 논의 대상임
  • 과거 brownfield는 오래된 Java 시스템 등을 뜻했지만, 에이전트가 만든 코드베이스도 빠른 개발 속도 때문에 약 3~6개월 뒤부터 변경하기 어려워질 수 있음
  • 결과가 나쁘면 토큰이나 기술이 부족한 탓이라는 조언이 많지만, 핵심 문제는 하네스보다 모델 훈련 방식에 있음

소프트웨어 팩토리의 진화

  • 1968년부터 AI 도입 이전까지

    • ‘소프트웨어 팩토리’라는 용어는 ‘소프트웨어 엔지니어링’이라는 표현이 등장한 1968년 NATO 회의까지 거슬러 올라감
    • 2022년 무렵의 전형적인 팩토리는 다음 순환 구조를 가짐
      • 사람이 무엇을 만들지 결정하고 Linear나 Jira 같은 추적기에 등록함
      • 담당자가 구현과 테스트를 수행함
      • 자동 검사와 인간 코드 리뷰를 거쳐 문제가 있으면 구현 단계로 돌아감
      • 프로덕션 배포 후 모니터링하며 장애와 사용자 피드백을 다시 추적기에 넣음
    • 구현과 리뷰에 각각 수시간 또는 수일이 걸리므로 팀은 계획·아키텍처 제안·스프린트 계획을 앞에 배치해 합의를 먼저 만듦
    • 구현 전 합의는 재작업을 줄이며, 결정된 방향에 가까운 완성도 높은 PR은 모든 줄을 읽더라도 빠르게 검토할 수 있음

  • 에이전트형 팩토리

    • Ramp, Stripe, WorkOS, Brex 등은 에이전트 팩토리가 코드의 약 75% 를 출하한다고 소개함
    • 기존 팩토리에서 사람이 구현하던 단계를 에이전트로 바꾸고 오케스트레이션·하네스·샌드박스·모델·컴퓨터 사용을 결합함
    • 구현 시간은 수시간·수일에서 수분·수시간으로 줄지만, 인간의 코드 읽기와 테스트는 그대로여서 리뷰가 병목이 됨
    • 이 병목을 줄이기 위해 여러 루프를 추가함
      • 스타일·버그·보안을 검사하는 에이전트 코드 리뷰
      • 브라우저와 컴퓨터 사용으로 외부 동작을 확인하는 회귀 테스트
      • 장애를 자동으로 PR에 연결해 담당자가 수정 후보를 받도록 하는 흐름
      • 사용자 피드백을 작업 큐로 직접 연결하는 흐름
    • 결국 운영 문제는 작업 큐에 얼마나 많이 넣을 수 있는지, 결과를 얼마나 빨리 검토하고 테스트할 수 있는지로 좁혀짐

  • 무인 팩토리

    • Dan Shapiro가 명명한 무인 팩토리는 인간이 모든 변경을 읽는 단계를 제거함
    • 코드 리뷰 대신 다음 영역에 투자함
      • 에이전트의 자체 테스트
      • 샌드박스와 오케스트레이션
      • 자동 리뷰와 모니터링
      • 점진적 출시와 사용자 피드백 신호 수집
    • 사람의 판단을 제거하면 에이전트에 얼마나 많은 작업을 요청할 수 있는지만 남지만, 이 방식은 복잡한 프로덕션 코드베이스에서 작동하지 않음

직접 적용한 무인 방식의 실패

  • 2025년 7월부터 명세와 티켓만 읽고 소·중규모 작업을 백그라운드 에이전트에 맡기는 완전한 무인 방식을 적용함
  • 몇 달이 지나자 고급 프롬프트와 워크플로로도 풀지 못하는 복잡한 문제가 발생함
    • 필요한 맥락을 수집해 모델에 제공함
    • 에이전트가 약 10가지 방식으로 문제 재현을 시도함
    • 결국 인간이 3개월 동안 읽지 않은 코드베이스에 직접 들어가 원인을 찾아야 했음
  • 그동안 사이트가 중단되고 사용자는 불편을 겪었으며, 인간은 누적된 저품질 코드를 읽어야 했음
  • 첫 실패에서는 속도를 위해 위험을 감수할 만하다고 판단했지만, 약 세 번째 문제가 발생한 11월에는 처음부터 다시 작성하는 편이 쉬웠음
    • 공동 창업자가 VS Code에서 2주 동안 패턴을 직접 다시 구현함

모델이 코드베이스 품질을 떨어뜨리는 이유

  • 현재 모델은 상당한 인간의 방향 조정 없이 코드베이스 품질을 장기간 유지하고 개선하지 못함
  • 여기서 유지보수성이란 한 부분을 바꾸면 다른 부분이 깨지고, 같은 변경을 여러 위치에 적용해야 하는 shotgun surgery 상태를 피하는 능력임
  • 모델은 일회성 문제 해결이나 새 마케팅 사이트 생성에서는 크게 발전했지만, 시간이 흐르며 코드 품질을 개선하는 능력은 뚜렷하게 나아졌다고 보기 어려움
  • 유지보수 능력을 측정하는 좋은 벤치마크가 없어 이 차이를 입증하거나 반박하기도 어려움
  • GPT-5.5 xhigh 같은 모델이 훌륭한 리팩터링을 수행하더라도, 인간이 코드베이스를 이해하고 필요한 작업을 구체적으로 지시해야 한다면 무인 팩토리의 문제는 해결되지 않음

Claude Code와 하네스 내부 강화학습

  • Claude Code 이전에도 aider, cline, codebuff 같은 CLI 에이전트가 읽기·쓰기·편집·검색·셸 도구와 맥락 엔지니어링을 제공했음
  • 기존 에이전트는 같은 편집을 반복해서 실패하는 등 도구 사용 안정성이 부족할 때가 있었음
  • SWE-Agent 논문은 ReadFile 결과에 줄 번호를 넣거나 Edit를 찾기/바꾸기에서 줄 범위 편집으로 바꾸는 작은 도구 설계 차이도 성능에 영향을 준다고 분석함
  • Claude Code가 빠르게 성장한 핵심 이유로 Anthropic이 실제 출시할 하네스 안에서 모델을 강화학습한 점을 꼽음
    • 모델이 정확한 도구 집합을 에이전트 루프 안에서 호출하도록 가중치를 조정함
    • 외부 개발자가 도구 정의와 평가를 모델 선호에 맞추는 것과 달리, 모델 소유자는 모델 자체를 도구에 맞게 변경할 수 있음
  • 하네스와 모델 가중치를 모두 가진 팀은 하네스만 만들고 가중치를 조정할 수 없는 팀보다 유리함

코딩 에이전트 강화학습의 보상 한계

  • 코딩 모델 강화학습은 대체로 다음 절차를 수백만 번 반복함
    1. 테스트 수정 같은 문제를 풀도록 에이전트 실행 추적을 생성함
    2. 검증기로 실행 추적을 평가함
    3. 좋은 실행 추적의 확률을 높이고 나쁜 실행 추적의 확률을 낮추도록 모델 가중치를 갱신함
  • 문제는 평가 점수가 지나치게 일차원적일 수 있다는 점임

  • SWE-bench Multilingual 사례

    • SWE-bench Multilingual은 Redis, jq, Django 같은 오픈소스 저장소에서 가져온 약 15분 규모의 작업을 사용함
    • 보상은 0 또는 1이며 두 조건을 검사함
      • FAIL_TO_PASS: 요청된 문제를 고쳤는지
      • PASS_TO_PASS: 기존 동작을 깨뜨리지 않았는지
    • fastlane__fastlane-19304 작업은 선택적 include, exclude 매개변수가 없을 때 nil에 .empty?를 호출해 실패하는 버그임
    • 실제 인간 수정은 nil을 빈 배열로 기본 설정하는 두 줄 변경이었음
    • 모델은 수정 직전 기본 커밋과 버그 보고서만 받고, 정답 패치와 채점용 테스트 패치는 보지 못함
    • 평가는 다음 순서로 진행됨
      1. 모델이 만든 패치를 보존함
      2. 모델이 테스트 파일에 가한 변경은 제거함
      3. 벤치마크의 비공개 테스트 패치를 적용함
      4. 기존 테스트와 새 테스트를 함께 실행함
    • 테스트 변경을 버리는 이유는 모델이 실패 테스트를 주석 처리하거나 무의미한 mock을 넣어 통과시키는 경우가 있기 때문임
    • 벤치마크와 강화학습 검증기는 동일하지 않고 서로 분리돼야 하지만, 둘 다 코딩 실행 추적의 품질을 판단하는 구조적 한계를 보여줌

  • 설계 악화에는 벌점이 없음

    • 테스트만 통과하면 해법에 도달한 과정과 구조적 품질은 점수에 반영되지 않음
    • 모든 곳을 try/catch로 감싸거나 타입 시스템의 이점을 무너뜨리는 느슨한 타입 캐스트도 정답이 될 수 있음
    • 유지보수성 훼손은 기존 테스트와 신규 테스트가 통과하는 한 벌점을 받지 않음

테스트 통과보다 어려운 품질 검증

  • 테스트는 수초 안에 명확한 성공·실패를 제공하므로 강화학습을 수백만 회 반복할 수 있음
  • 나쁜 아키텍처의 비용은 수주·수개월·수년 뒤 작은 변경을 여러 위치에 적용해야 할 때 드러남
  • 현재 벤치마크는 이런 장기 설계 비용을 평가하지 못함
  • 강화학습과 벤치마크가 같은 것은 아니지만, 유지보수성이 강화학습에서 해결됐다면 벤치마크 설계에도 그 능력이 나타날 가능성이 있음
  • 따라서 기존 벤치마크 점수 향상을 모델이 코드베이스를 더럽히지 않게 됐다는 근거로 볼 수 없음

유지보수성을 평가하려는 새 시도

  • 모델 품질의 최전선은 개선되고 있지만, 기술적 규율보다 기대와 홍보가 앞서고 있음
  • 유지보수성에 더 가까운 평가를 시도하는 사례는 다음과 같음
    • SWE-Marathon: Excel의 모든 기능 복제처럼 약 400시간 규모의 작업과 단일 성공·실패가 아닌 복합 보상 채널을 사용함
    • DeepSWE: 현실에서 실제 구현되지 않은 대규모 오픈소스 작업을 사용해 훈련 데이터 오염을 줄이지만, 품질 문제 자체는 해결하지 못함
    • Frontier Code: 여러 PR에 걸친 작업을 평가하고, 패치 전 코드에서도 실패하지 않는 테스트를 작성하면 벌점을 줌
      • 변이 테스트와 유사한 방식으로 테스트의 유효성을 결정론적으로 검사함
      • 코드 품질 규칙에 따라 diff를 검사하는 판정 모델도 실행함
  • 판정 모델이 품질을 안정적으로 구분할 수 있다면 처음부터 좋은 코드를 생성할 수도 있었을 것이라는 한계가 있음
  • 강화학습에는 빠르고 신뢰할 수 있는 오라클이 필요하지만, 유지보수성에는 그런 오라클이 없음
  • 리뷰 에이전트와 추가 토큰은 명백한 실수를 잡아 최저 품질을 높일 수 있지만, 강화학습으로 모델에 가르친 수준을 넘어 최고 품질을 끌어올리지는 못함
  • SWE-Marathon·DeepSWE·Frontier Code는 성공·실패 판정을 넘어 유지보수성을 평가하려는 초기 시도이지만, 아직 코드베이스 전체를 맡길 수준은 아님

인간을 다시 루프에 넣는 4단계

  • 현재 신뢰할 수 있는 품질 판정자는 인간이므로 코드 리뷰를 복원해야 함
  • AI 이전부터 사용한 선행 계획을 적용해 긴 리뷰와 재작업 가능성을 줄임
  • AI의 레버리지는 제품 요구사항, 시스템 아키텍처, 프로그램 설계, 수직 슬라이스의 네 단계에서 활용함

  • 1. 제품 검토

    • 짧은 문장이나 긴 음성 메모를 반구조화된 문서로 바꿔 무엇을 왜 만드는지 고정함
    • 먼저 사용자의 언어로 해결할 문제를 정의하고, 출시 후 성공 여부를 판단할 기준을 정함
      • 워크플로 수행 시간 단축
      • 온보딩 이정표 조기 달성
      • 오류율이나 지연 시간 개선
      • 특정 지원 티켓 감소
    • 기술 세부사항보다 사용자 경험에 집중하고, 기술 결정이 제품 결정을 막으면 현재 문서를 저장한 뒤 아키텍처 검토나 타당성 프로토타입으로 이동함
    • 화면 동작은 긴 설명보다 거친 HTML 모형으로 확인하는 편이 합의에 효과적임
    • 문구 수정, 일회성 스크립트, 재현 방법이 명확한 버그에는 이 절차를 적용하지 않고 에이전트에 바로 맡김
    • 에이전트가 의도를 오해했을 때 비용이 큰 변경만 제품 검토 대상으로 삼음
    • PR 검토자가 제품·기술 명세도 미리 검토하게 하며, 비동기 문서 댓글이나 GitHub·Notion 등을 사용할 수 있음

  • 2. 시스템 아키텍처

    • 서비스·엔드포인트·스키마·큐·저장소 사이의 통신 방식을 합의하되 프로그램 내부 구현까지 내려가지는 않음
    • 인간과 에이전트의 소통 대역폭을 높이기 위해 다음 표현을 사용함
      • UI, API, 서비스, 저장소 사이의 시퀀스 다이어그램
      • 요청·응답을 보여주는 API 계약
      • 새 테이블과 쿼리 형태를 나타내는 데이터 모델
    • Mermaid는 유용하지만 과도하게 사용하면 실제 합의가 이뤄졌다는 잘못된 확신을 줄 수 있음
    • 아키텍처 검토는 모델의 나쁜 습관을 조기에 막는 데 효과적이지만, 고품질 코드를 보장하기에는 부족함

  • 3. 프로그램 설계

    • 구현 전에 아키텍처보다 한 단계 아래인 코드의 형태를 결정함
      • 타입
      • 메서드 시그니처
      • 프로그램 배치
      • 호출 스택
    • 복잡한 Mermaid보다 가벼운 의사코드 시각화가 읽기 쉬움
    • 오케스트레이션이나 제어 흐름 변경에는 호출 스택 트리를 사용하고, 바뀌는 부분이 중요하면 diff 문법을 적용함
    • 파일 트리 diff로 새 파일과 수정 파일의 위치와 역할을 확인함
    • 핵심 함수의 타입과 메서드 시그니처를 미리 정해 에이전트가 내부 설계를 잘못 선택할 가능성을 줄임
    • 모델이 초안을 만들고 인간이 조정할 수 있으며, 코드 리뷰 중 암묵적으로 내릴 결정을 더 저렴한 시점으로 앞당기는 작업임

  • 4. 수직 슬라이스

    • 모델은 데이터베이스 마이그레이션→서비스 계층→API→프런트엔드 순서로 쌓는 수평 계획을 선호함
    • 수평 계획은 작업 도중 브라우저나 curl로 실제 해결책을 만져보고 검증하기 어려움
    • AI 이전 개발자는 500줄이나 2,000줄을 한꺼번에 작성하기보다 중간부터 바깥으로 확장하며 계속 확인했음
      1. API 계약과 mock 데이터를 만들고 curl로 검사함
      2. 프런트엔드에서 mock 데이터를 소비하며 브라우저로 다듬음
      3. API를 서비스 계층에 연결함
      4. 데이터베이스 마이그레이션과 저장소 연결을 추가함
      5. 비즈니스 로직을 추가함
      6. 오류 처리를 추가함
    • 수직 슬라이스 또는 tracer bullets는 각 단계에서 실제 동작을 테스트하고 개선할 수 있게 함
    • 품질이 특히 중요한 영역에서는 단계마다 100~200줄을 검토하고 방향을 다시 잡는 편이 2,000줄 이상을 뒤늦게 고치는 것보다 저렴함
    • 최신 모델도 인간의 방향 조정 없이 이런 계획을 세우기 어렵고, 코드베이스와 작업별 일반화도 힘들어 인간이 루프에 남아야 함

작업 크기에 따른 적용 방식

  • 30분의 선행 계획으로 구현 후 수시간의 리뷰를 줄일 수 있음
  • 인간 수준에 가까운 품질을 유지하려면 제품 설계·시스템 아키텍처·프로그램 설계·수직 슬라이스에 인간이 참여해야 함
  • 모든 작업에 전체 절차를 적용하지는 않음
    • 약 40% 는 한 번에 생성하거나 1~2회의 가벼운 피드백으로 마침
    • 중간 규모 작업은 제품·시스템 설계를 하나의 계획 문서로 합치고 구현 단계를 나누지 않음
    • 큰 작업은 네 단계를 모두 거치되, 대규모 리팩터링처럼 제품 검토가 맞지 않으면 해당 단계를 생략함
  • 보통 모델에 한 번에 1~3개 슬라이스를 맡기고 진행 중인 코드를 검토함
  • 초기에 내부 구조나 기능을 바로잡는 편이 대량 생성 후 무엇이 잘못됐는지 찾는 것보다 쉬움

병목은 PR 수가 아니라 PR 품질

  • PR이 너무 많은 게 아니라 나쁜 PR이 너무 많은 것이 병목임
  • 결정된 설계와 팀의 관례를 따르는 깨끗한 PR은 모든 파일을 읽어도 빠르게 검토할 수 있음
  • PR의 20%만 재작업해도 제출자와 검토자 모두에게 지적 부담과 감정적 부담이 생김
  • AI가 한 번에 생성한 PR은 재작업 비율이 50%에 가까운 경우가 많음
  • 제출자가 AI여도 누군가는 작업을 시작하고 결과를 다듬거나 책임져야 하므로 재작업 비용은 사라지지 않음

제약을 받아들인 개발 속도

  • 현재의 핵심 제약은 모델이 잘하는 일과 못하는 일이 분명하고, 당분간 인간이 코드를 읽어야 한다는 점임
  • 코드 품질이 중요하지 않다고 가정하며 10~100배 속도를 좇기보다 제약 안에서 시스템을 최적화하면 안전하게 2~3배 속도를 얻을 수 있음
  • 실무 원칙은 네 가지임
    1. 모델과 충분히 작업해 제약에 대한 직관을 기름
    2. 그 제약 안에서 개발 시스템을 최적화함
    3. 높은 레버리지가 있는 지점을 찾음
    4. 실제 코드를 읽음
  • 하네스와 루프는 명백한 오류를 줄이는 도구지만, 유지보수성 판단과 설계 사고를 대신하지 못함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이를 의도-구현-품질 문제라고 부름
    소프트웨어 공장은 한 줄짜리 요구사항만으로 앱, 기능, 버그 수정, 설계 변경, 리팩터링까지 구현할 수 있지만, 그 요구사항 뒤에 있는 인간의 의도와 제품의 발전 방향까지 정확히 만들어낼 수 있는지는 별개의 문제임
    구현 방법은 조합적으로 폭발하며, 시스템과 일관되고 확장 가능하며 이해하기 쉽고 수백만 사용자를 안전하게 지원하는 ‘올바른’ 방법은 사람과 문제에 따라 주관적임. 테스트와 작업 증거로 일부 품질은 높일 수 있어도 이런 주관적 품질을 검증하고 교정할 피드백 루프는 없음

    • 고객이 “X를 원한다”고 해도 실제로 X를 원할 수도, X가 필요 없을 수도, 표현하지 못했을 뿐 Y를 원할 수도 있음. 다른 고객들은 X를 원하지 않거나, 별 이유 없이 개발자를 흔드는 경우도 가능함
    • 사용자와 매출이 거의 없고 버그를 Claude 프롬프트 한 번으로 고칠 수 있는 개인·취미 소프트웨어나 제품-시장 적합성 이전 스타트업에는 소프트웨어 공장이 잘 맞음
      코드를 전혀 보지 않고 요구사항의 성공 여부만 피드백으로 삼는 균형도 가능하지만, 그 밖의 소프트웨어에서는 아직 의도와 주관적 품질 문제가 해결되지 않았음
    • 요구사항을 구현으로 옮기는 방법이 하나뿐이라는 전제부터 사실이 아님

  • 글에는 좋은 내용이 있지만, 2025년 7월 무인 운영 실험을 현재 에이전트의 한계로 일반화하기는 어려움
    모델의 유용성이 2025년 가을이나 2026년 봄쯤 크게 도약했고, 나도 그 이후부터 에이전트에 기능 전체를 맡길 수 있었음. 글은 모델 향상을 언급하고도 사실상 무시하는데 내 체감과 맞지 않음

    • 글과 제품 사이트 모두 2025년에 머물러 있는 듯함. 특히 “긴 컨텍스트는 답이 아니다”라는 글은 최신 모델에 과거 성능을 그대로 외삽한 것으로 보임
      Opus 4.6 이후 모델은 70만~90만 토큰에서도 지능 저하를 체감하기 어려울 만큼 안정적이었고, 비용 효율은 매우 낮지만 작동은 함
    • 지난주 Dex Horthy가 출연한 팟캐스트를 들었는데, 그의 회사 Humanlayer는 계속 에이전트의 한계를 밀어붙이며 적극적으로 활용 중임
      현재 모델의 역량을 잘 알고 있으므로, 지금 무인 소프트웨어 공장이 가능하다고 판단했다면 다시 시도하고 있을 것임
    • Opus 4.5는 확실히 큰 도약이었음. 이후 모델을 실험하지 않은 사람의 평가는 가치가 떨어지지만, 모델이 완벽하지 않아도 매우 유용함
    • 그렇다면 “2025년에 전면 도입했고 2026년에도 본질적으로 나아진 게 없다”고 쓰는 편이 명확했을 것임
      최신 프런티어 모델도 맥락 이탈이나 산탄총 수술(shotgun surgery)을 더 잘 처리하지 못한다고 봄. 반박하려면 단순히 무시하지 말고 구체적인 근거와 다른 사용 경험을 제시해야 함
    • 논쟁적일 수 있지만 복잡한 엔지니어링에서는 Opus 4.1이 4.5보다 영리했다고 느낌
      4.5는 더 빠르고 단순한 프롬프트와 암묵적 의도를 잘 읽어 신규 사용자를 빠르게 끌어들이는 데 유리했음

  • 내 소프트웨어 공장을 8개월간 구축·운영했으며, 작업 자동 수집과 PR 제출은 아직 없지만 요구사항을 정한 뒤 대부분 스스로 배포까지 진행함. 시스템 평가를 거친 후 지난 4개월 동안 코드 검토를 중단했음
    한 줄 프롬프트 대신 인터뷰 과정으로 미해결 질문과 모호성을 먼저 해소하며, 계획 검토, 브라우저 기반 품질 보증, 적대적 검토, 단위 테스트, 린터, 타입 검사기, 커밋 후 훅, 형식 기법 추적을 안전장치로 사용함
    반복 실수가 나타나면 코드를 보지 않아도 지저분해진 영역을 감지할 수 있음. 요구사항이 늘며 상태 변수가 겹쳐진 경우 하나의 합 타입으로 리팩터링하고, 복잡하면 Quint로 형식 모델과 추적을 만들어 단위 테스트로 실행함
    코드베이스는 1년 이상 된 프런트엔드와 백엔드로 구성됨. 에이전트는 기존 패턴을 그대로 복제하므로 명확한 원칙이 중요하며, 새로운 시스템 경계를 나눌 때 Sonnet급 모델은 자주 잘못 판단하고 Opus가 더 나았음

    • 완전한 공장은 아니지만 나도 성숙한 바이브 코딩 프로젝트 여러 개에서 비슷하게 느낌
      품질 저하는 대체로 감지할 수 있었고, 코드를 열어 문제를 찾은 뒤 에이전트로 정리하지 못한 적은 아직 없음. 평균적인 엔지니어가 코드베이스의 오염을 되돌릴 수 없는 상황도 보지 못했음
    • 코드 공장 자체가 아니라 무엇을 만들었는지가 궁금함. AI 코딩 도구 외의 제품도 만들 수 있음을 검증할 결과물이 필요함
    • 긴 글이나 저장소 형태로 구체적인 구성과 작업 흐름을 공개하면 보고 싶음

  • 코드베이스의 작동 방식을 이해해야 하거나, 이해할 필요가 없거나 둘 중 하나임
    Claude가 코드를 대신 작성할 수는 있어도 대신 이해해 주지는 못하며, 그 과정은 여전히 인간의 속도로 진행됨. 모든 것을 이해하지 않아도 되는 경우는 있지만 더 섬세한 구분이 필요하고, Claude가 완벽한 코드를 작성해도 이 사실은 변하지 않음

    • Claude는 인간보다 훨씬 빠르게 스파게티 코드베이스를 탐색할 수 있음. 프로젝트 이해를 Claude에 외주화하면 인간에게 이미 사용 불가능해진 뒤에도 계속 작업할 수 있다는 점이 오히려 문제임
    • 이해 여부를 이분법으로 보기보다 특정 코드베이스에서 효과적으로 일하는 데 얼마나 많은 이해가 필요한지로 볼 수도 있음
      LLM 이전에도 대형 코드베이스 전체를 아는 사람은 없었지만, 최소한 자신이 만든 PR과 담당 영역은 대체로 이해했음
    • 내 경험은 반대임. 대부분 직접 작성하고 개념도 설계했던 두 대형 코드베이스를 Claude가 나보다 훨씬 깊게 이해하게 만들었고, 오래전에 잊은 내용을 이제 Claude에게 설명받고 있음

  • 내 경험과 너무 비슷해 안도감이 듦. 최근 자주 거론되는 취향과 판단력이 떠오름
    아키텍처 품질은 패션처럼 객관적인 정답이 없을 수 있으며, 기계에 이성과 합리성을 넘긴 뒤 인간은 미학을 공부해야 할지도 모름
    구현 과정이 주던 휴식 없이 거의 동등한 선택지 사이의 절충을 계속 판단해야 하므로 지치며, Fable이나 GPT-5.6급 모델에서도 코드 검토는 여전히 필요함. 작은 결함은 기억해 두었다가 비슷한 문제가 충분히 쌓이면 한꺼번에 고침
    에이전트도 소수의 뛰어난 인력과 긴밀히 협업할지, 대규모 하위 에이전트를 돌리고 자동으로 옥석을 가릴지 선택해야 함. 내 취향은 소수의 고도로 조율된 팀이지만 정답인지는 시간이 알려줄 것임

    • Jake Nations가 Netflix 재직 당시 “나쁜 패턴은 새벽 2시에 디버깅해 본 적이 있어서 보는 순간 안다”고 표현했음
      취향이란 소프트웨어를 만들며 직접 터뜨려 본 모든 안티패턴과 지뢰에서 얻은 고생 끝의 직관임
      https://www.youtube.com/watch?v=eIoohUmYpGI

  • 이 사람은 과거에도 근거 없는 내용을 만들어 퍼뜨려 피해를 줬다고 인정한 전력이 있는데, 이번 생각이 좋다는 증거도 전혀 없음. 다시 신뢰해야 할 이유가 필요함

    • 결국 그의 제품 Humanlayer를 홍보하는 긴 광고에 불과함

  • 지금 상황에서 가장 눈에 띄는 문제는 PR 검토 사용자 경험임
    GitHub의 PR 화면을 늘 싫어해 브랜치를 내려받아 $EDITOR로 차이를 확인했는데, 이제는 이렇게 불편할 이유가 없음. 코드 검토 회사도 아닌 Linear가 작은 모델로 변경 파일을 주제별로 묶고 설명과 중요도 순서를 붙여 GitHub보다 나은 기본 기능을 제공함
    검토자와 요청자의 추가 작업 없이 인지 부하가 크게 줄며, 시각화 같은 후속 기능도 충분히 가능함. 이 접근이 틀렸는지, 널리 쓰이는 대안이 있는지 궁금함
    https://linear.app/docs/diffs#guides

    • 최고의 팀은 PR 검토를 하지 않음. 변경 중에 설계와 아키텍처를 함께 논의하고, 린팅·서식 같은 사소한 검사는 자동화하며, 많은 테스트와 검사로 빌드를 깨지 않는 규칙을 엄격히 지킴
      강력한 롤백 절차까지 갖추면 PR 관문은 유용한 문제를 잡지 못하는 불필요한 과정이 되고, 팀원끼리 바로 병합할 수 있음
    • 코드 검토를 통합의 관문으로 삼는 정책은 무의미함. 내 에이전트는 검토 요청에 나를 대신해 답하고 검토하며, 인간 검토를 강제하는 회사 정책도 우회 가능함
      실제로 작동하는 소프트웨어를 검토해야 하며, 변경안을 즉시 시연할 수 있는 시스템이 필요함. 코드와 명세의 비중은 줄어들고 미래의 소프트웨어 생산은 GitHub보다 Replit에 가까워질 것임
    • 에이전트 이전에도 PR 검토는 힘들었지만, 이제 검토할 PR까지 늘어 훨씬 악화됨
    • 파일 변경을 주제별로 묶고 설명하는 역할은 원래 커밋이 해야 하는 일 아닌가 싶음
    • LLM이 중요도를 판단하거나 코드를 요약하는 능력은 그다지 좋지 않다고 봄
      Tree-sitter 기반 접근인 https://github.com/0x007BA7/codebook을 실험해 마음에 들었음. 아직 운영 환경에 쓸 수준은 아니지만 비슷한 방식을 제품화할 여지가 있음

  • 소프트웨어 공장에는 양가적인 느낌이 있음
    핵심 제품은 규모가 커서 모든 변경에 인간 입력이 필요하지만, 가벼운 리팩터링·테스트 작성·UI 변경 자동화는 잘 작동함. 반면 작은 실험에서는 결과 코드가 특별하지 않아도 앞으로 확장될 가능성이 보였으며, 처음부터 에이전트가 작성할 것을 전제로 새로운 전략과 아키텍처를 설계할 수 있다고 봄
    방향을 전혀 개입하지 않는 공개 실험은 https://relentless.works/에 문서화했음. 거래 에이전트도 개입 없이 관찰 중인데 약 3% 손실이지만 전액을 잃지는 않았고 최근 새 포지션도 열었음
    소프트웨어 공장은 가능해 보이지만 새로운 개념과 사고방식의 변화, 그리고 AI를 기다리는 인내가 필요함

  • 소프트웨어를 만든다는 것이 무엇인지부터 근본적인 문제가 있음
    GitHub 티켓을 AI 에이전트에 배정하고 쉬기만 하면 추상화와 간접 계층이 계속 쌓일 가능성이 큼. 코딩 중에는 “여기 Redis를 쓰면?”, “API가 이미 필요한 데이터를 주는데?”, “지난 1년간 활동하지 않은 고객은 보고서에서 빼자” 같은 관점이 생기며, 어느 순간 인간이 이를 판단해야 함

    • 이는 에이전트 코딩에서 잃기 쉬운 프로그래밍은 이론 구축이다라는 관점과 이어짐
      https://gwern.net/doc/cs/algorithm/1985-naur.pdf
    • 전적으로 동의함. 널리 쓰이는 코딩 에이전트 작업 흐름과 기술 모음은 계획이나 코드 작성 과정에서 인간의 통찰과 직관을 끌어내도록 설계됨
      Claude Code의 계획 모드, mattpocock/skills, obra/superpowers, 조사-계획-구현 흐름 등이 이에 해당함
    • 그렇게 사고하는 상위 1% 개발자라면 맞겠지만, 수십 년간 만난 개발자 대부분과 비교하면 현재 모델이 최상위권을 제외한 인간보다 뛰어남
    • 기계는 아직 존재하지 않는 것까지 요청한 그대로 만들어 줌. 완전 무인화보다 정보 이론·의사결정 이론·창의성 이론을 활용해 올바르게 요청하는 능력이 중요함
      모델의 기억은 인간이 잠들며 가중치에 새기듯 통합되지 않고, 어제를 기억하지 못하는 사람에게 메모를 건네는 것에 가까움. 엔트로피가 높은 시스템이 시간이 지나며 프로젝트에 엔트로피를 더해도 놀랄 일이 아님
    • “API가 이미 필요한 데이터를 반환한다”는 문제가 특히 큼. 최상위 모델이 클라이언트에 이미 있는 데이터로 한 줄만 바꾸면 될 일을 기존 클라이언트-서버 패턴을 흉내 내며 엄청난 코드와 토큰으로 해결하는 모습을 여러 번 봤음
      바이브 코딩 프로젝트에는 이런 낭비가 가득하지만 프롬프트를 작성한 사람은 이를 모를 수 있음. 도구가 매일 시간을 절약해 주는 것은 좋지만 과잉 구현은 심각함

  • 무인 소프트웨어 공장을 논하면서 생산성을 PR이나 커밋 개수로 재는 모습이 우스움. 그 방향이라면 코드 단위를 이미 bos(bunch of shit)라고 불러야 할 정도임

    • 전체 처리량 대신 가동률을 최적화하는 오래된 실수를 반복하고 있음. Eli Goldratt가 1970년대부터 다룬 문제인데도 아직 배우지 못했음
      https://en.wikipedia.org/wiki/The_Goal_(novel)
    • 이 개념을 진지하게 운영하려면 허영 지표나 코드에 대한 무지를 허용할 수 없음. 자동화가 많을수록 기준은 낮아지는 게 아니라 더 높아지며, 훨씬 많은 수학과 노력이 필요함
      극단적인 스타트업처럼 자본을 아끼는 대신 삶의 수년을 투입하는 교환에 가까움
답변달기