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

고객이 “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급 모델에서도 코드 검토는 여전히 필요함. 작은 결함은 기억해 두었다가 비슷한 문제가 충분히 쌓이면 한꺼번에 고침
에이전트도 소수의 뛰어난 인력과 긴밀히 협업할지, 대규모 하위 에이전트를 돌리고 자동으로 옥석을 가릴지 선택해야 함. 내 취향은 소수의 고도로 조율된 팀이지만 정답인지는 시간이 알려줄 것임

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

결국 그의 제품 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년간 활동하지 않은 고객은 보고서에서 빼자” 같은 관점이 생기며, 어느 순간 인간이 이를 판단해야 함

전적으로 동의함. 널리 쓰이는 코딩 에이전트 작업 흐름과 기술 모음은 계획이나 코드 작성 과정에서 인간의 통찰과 직관을 끌어내도록 설계됨
Claude Code의 계획 모드, mattpocock/skills, obra/superpowers, 조사-계획-구현 흐름 등이 이에 해당함

그렇게 사고하는 상위 1% 개발자라면 맞겠지만, 수십 년간 만난 개발자 대부분과 비교하면 현재 모델이 최상위권을 제외한 인간보다 뛰어남

기계는 아직 존재하지 않는 것까지 요청한 그대로 만들어 줌. 완전 무인화보다 정보 이론·의사결정 이론·창의성 이론을 활용해 올바르게 요청하는 능력이 중요함
모델의 기억은 인간이 잠들며 가중치에 새기듯 통합되지 않고, 어제를 기억하지 못하는 사람에게 메모를 건네는 것에 가까움. 엔트로피가 높은 시스템이 시간이 지나며 프로젝트에 엔트로피를 더해도 놀랄 일이 아님

“API가 이미 필요한 데이터를 반환한다”는 문제가 특히 큼. 최상위 모델이 클라이언트에 이미 있는 데이터로 한 줄만 바꾸면 될 일을 기존 클라이언트-서버 패턴을 흉내 내며 엄청난 코드와 토큰으로 해결하는 모습을 여러 번 봤음
바이브 코딩 프로젝트에는 이런 낭비가 가득하지만 프롬프트를 작성한 사람은 이를 모를 수 있음. 도구가 매일 시간을 절약해 주는 것은 좋지만 과잉 구현은 심각함

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