하네스 엔지니어링: 에이전트 우선 세계에서 Codex 활용하기

처리량이 말도 안 되는 수준임. 기준선을 뭘로 잡아야 할지 궁금함. 에이전트 코딩 이전에는 엔지니어가 보통 PR을 얼마나 올릴 것으로 기대됐나? 하루 2~10개 정도였을까?
지난 6개월 동안 소프트웨어가 더 좋아졌다고 느끼는지도 궁금함. 엔지니어 수가 비슷하다면 주요 소프트웨어 앱의 반복 주기가 5배쯤 빨라져야 할 텐데, 그렇게 보이지는 않음. AI 앱은 매우 빨리 바뀌지만 워낙 새 분야라 그 정도는 예상 가능하고, 그 밖에서는 체감이 잘 안 됨

재미있는 비교가 있음. Firefox는 현재 약 250만 줄이고, 그동안 대략 100만 커밋이 쌓였다고 나옴. 그러면 커밋당 추가된 줄은 약 3줄인데, 대부분이 완전한 추가가 아니라 수정이라는 점을 생각하면 이상하지 않음
여기서는 1,500개 PR에 100만 줄이니 PR당 순증가가 약 650줄임. PR 전체가 650줄이라는 뜻이 아니라, 추가분에서 삭제분을 뺀 순증가가 +650줄이라는 뜻임
꼼꼼한 독자를 위한 질문들이 있음. 1년에 Firefox 코드베이스 하나만큼 줄 수가 늘어나는 프로젝트는 10년 뒤 어떤 모습일까? 줄 수는 도구의 장황함에 대해 무엇을 말해주며, 프로젝트의 목적이 명확히 공개되지 않았다는 점은 결과에 대해 무엇을 말해줄까? 사람이 직접 코드를 쓰지 않는 세상에서 줄 수를 신경 쓸 이유가 있을까? 코드베이스가 훨씬 커지면 토큰 사용량은 어떻게 될까? LLM 사용이 줄 수를 폭증시킨다는 것이 확인된다면, 몇 달간 사용한 뒤 비용 때문에 다시 수동 코딩으로 돌아가려는 코드베이스에는 어떤 의미가 있을까?

일일 코드 줄 수 같은 산출량 지표가 소프트웨어의 실제 생산성을 재는 데 매우 나쁜 척도라는 건 수십 년 전부터 알고 있었음. 그런데 AI 시대에 다시 유행하는 듯함. AI가 이런 쓸모없는 지표를 극대화하는 데 매우 뛰어나고, AI가 얼마나 대단한지와 우리가 AI를 얼마나 대단하게 쓰는지 보여줘야 하기 때문임

정작 제품이 정확히 무엇인지 말하지 않았고, 그게 없으면 글을 판단하기가 불가능함
이상하게도 “에이전트”의 대부분 용도는 또 다른 AI 제품을 만드는 데 쓰임. 끝없이 거북이가 받치고 있는 구조임. 어쩌면 이는 “에이전트”의 힘보다는 하네스 분야에 대해 더 많은 걸 말해주는지도 모름

업데이트 주기는 실제로 빨라진 느낌임. 하지만 품질이 꼭 좋아진 건 아님
MS Office를 보면 최근 작은 변경이 많이 보이는데 대부분 짜증남. Word 댓글에서 동료를 @태그하면 포커스가 사라진다거나, Outlook 검색창에 입력하려면 두 번 클릭해야 한다거나, Outlook 모바일 날짜 선택기가 내 가용 시간과 참석자 가용 시간을 보여주던 기능을 잃어버린 것 같은 것들임
그래서 처리량은 많아 보이지만, 안타깝게도 잘 작동하던 기능을 망가뜨리고 있음. 또는 OneDrive 검색 상태 표시줄이 입력창 주변을 빙글빙글 도는 것처럼 중요하지 않은 데 시간을 쓰고 있음

지난 1년쯤 바이브 코딩을 많이 해왔는데, 이제 그만둘 생각임. 예전 Copilot 자동완성 흐름으로 갈림길을 되돌아가서 그걸 최대한 활용할 수 있는지 스스로 시험해보고 싶음
작성되는 코드의 대부분은 내가 운전석에 앉아 통제하되, AI는 몰입 상태를 강화하고 막힌 부분을 없애는 데 쓰는 방식임. 도구는 실제 코드 생성은 최소한만 하게 두고 싶음

지난 5개월 동안 tsz[1]에서 같은 실험을 해왔고, 매우 비슷한 결론에 도달함. 좋은 아키텍처 분리를 강제하기 위한 하네스가 많이 필요하고, 테스트와 CI도 많이 필요함
tsz를 만드는 목적은 AI로 매우 큰 프로젝트를 하는 법을 배우는 것임. 결국 같은 워크플로와 태도는 UI가 있는 고객용 제품 앱을 만드는 데도 활용될 수 있음. OpenAI가 자동화된 브라우저 테스트와 동영상까지 워크플로 일부로 활용하는 것으로 보임. 모델이 좋아질수록 이런 소프트웨어 제작 방향은 결국 말이 될 것 같지만, 아직 거기까지는 아니라고 봄. 그래도 OpenAI의 모호한 주장과 달리 결과물을 공유해서 직접 볼 수는 있음
Lovable처럼 매우 높은 수준의 자동화를 제공하는 솔루션들은 조금 지나치게 낙관적이고, 많은 자동화 테스트와 긴밀히 결합되어 있지 않음
[1] https://github.com/tsz-org/tsz

내가 해온 방식과 정확히 겹침. Claude/Codex가 자기 작업을 검증할 수단을 줌. 브라우저, 스모크 테스트, 종단 간 테스트, 충실도 높은 로컬 환경 같은 것들임
모든 맥락, 즉 이슈 추적, 문서, 아이디어, 계획, 작업 로그를 저장소 안에 둠(https://github.com/shepherdjerred/monorepo/tree/main/package...)
Claude/Codex에 Grafana, Prometheus, Tempo, PagerDuty 같은 관측성 도구 접근 권한을 주고, 빠른 실패, 타입 안전성, 경계에서의 파싱 같은 좋은 엔지니어링 지침을 따르게 함
다만 홈랩에서 비용과 CI 부하 때문에 아직 완전 자율성까지는 달성하지 못했음

결과가 잘 나오나? 문서 대신 AI에게 그냥 코드를 읽으라고 하는 편이 더 쉽다고 느꼈음. 코드 주석과 비슷해서 문서는 금방 낡아버림

수행한 작업을 파일로 저장하는 아이디어가 좋음. LLM이 같은 작업을 다시 하는 걸 막는 데 도움이 됨. 언젠가는 저장소의 코드 대신 프롬프트 목록만 남을지도 모름

얼마 전 전자담배 공장 노동자 영상을 봤음. 컨베이어 벨트에서 전자담배 묶음을 집어 들고, 입에 물고 5초 정도 힘차게 피운 다음 다음 묶음을 테스트함. AI가 작성한 PR에서 수백 줄 변경을 사람이 검토하는 것도 크게 다르지 않음

전자담배 라인은 통계적 검사가 가능함. 샘플별로 정의할 수 있는 구체적 기준과 명확한 허용 오차가 있고, 공장이 허용 가능한 신뢰도 수준을 충족하기 때문임
PR은 그렇지 않음. 나쁜 PR 하나가 사업에 치명적일 수 있지만, 나쁜 전자담배 하나는 보통 그렇지 않기 때문임
또한 소프트웨어 엔지니어가 AI 출력물을 샘플링해보면 현재 품질이 제품에 원하는 기준을 꾸준히 충족하지 못한다고 봄. 그래서 모든 PR을 리뷰하고 상당수를 고쳐야 함
변경 영향 범위를 제한할 수 있고, 출력물이 대체로 감독 없이도 받아들일 만해져서 공장에서 회귀가 없는지만 이중 확인하면 되는 수준이 되면 샘플링 접근이 작동할 수 있음

맞는 말임. PR이 1,000줄이면 몇 줄만 확인하고 나머지는 테스트 스위트에 맡기게 될 것 같음

이 글을 쓴 세 엔지니어 중 한 명임. 질문이 있으면 답할 수 있음

훌륭한 작업임. 프로젝트가 어떤 종류였는지 공유할 수 있나? 데이터베이스 엔진부터 고양이 사진 공유 웹사이트까지, 즉 정확성이 매우 중요한 쪽과 매우 느슨한 쪽 사이에서 어디쯤인지 궁금함

멋진 글임. 다른 팀들도 이 접근을 도입하고 있나? 아니라면 막는 요인은 무엇인가? 모델만으로 디버깅하기 부족해서 개발자가 직접 고쳐야 했던 문제가 있었나? 개발자가 늘면서 변경 속도가 빨라졌을 때, 동시 작성자와 병합 충돌은 어떻게 처리했나? 처음 접근 방식에서 하나 바꿀 수 있다면 무엇을 바꾸겠나?

모델이 생성한 코드 품질에 만족했나? 개선하려고 규칙 파일이나 스킬을 조정해야 했나? 아니면 이제 사람이 읽기 쉬운 코드는 목표도 아닌가?

그 긴 대시들은 직접 쓴 건가, GPT가 쓴 건가

AI 회의론자는 아니지만 이 글의 의도는 의심스러움. 실제 제품, 실제 사용자, 성장 중인 실제 팀을 근거로 에이전트 우선 엔지니어링에 대해 큰 주장을 하고 실제 사례처럼 보이게 만들지만, 무엇을 만들었는지 말하거나 보여주지도 않음. 다른 모든 AI 과장 글과 똑같음

글을 썼을 당시에는 제품을 출시하지 않았고 이야기할 준비가 되어 있지 않았음. 현재 Codex 앱과 매우 비슷하게 생긴 내부 프로토타입이었음

이 스레드도 “나도 이런저런 걸 해봤다”는 글로 가득한데, 한 명을 제외하면 아무도 어떤 링크도 뒤따라 제시하지 않음

이건 무한한 컴퓨팅 자원과 무한한 토큰이 있을 때만 작동할 수 있음
$20 플랜을 써본 입장에서는 이런 순수 에이전트식 접근은 불가능함. 금방 한도에 걸리고 결과는 더 적어짐
아주 잘 먹힌 방식은 사람이 작성한 코드를 참조로 제공하고 그것을 확장하라고 시키는 것이었음. 전체 구조를 잡고, 아키텍처를 설계하고, 컨트롤러, 서비스, 모델, 컴포넌트, 데이터베이스 스키마, 인증 방식 같은 샘플 코드를 몇 개 작성해서 LLM이 주의 집중을 시작할 발판을 갖게 함
보통 구현 방법을 자세히 적은 스텁을 작성함. 더 높은 추상화 수준의 의사코드 같은 형태임. 그런 다음 LLM에게 구현을 요청함
실패하면 전체 변경을 되돌리고, 이전 실패를 잡아낼 수 있도록 스텁을 조정한 뒤 다시 시도하는 편이 더 나을 때가 많음
또는 변경을 커밋한 뒤 새 맥락에서 잘못된 부분만 다루게 함
처음부터 에이전트식으로 접근해보면 결과와 한도 양쪽에서 늘 실망하게 됨. 한 시간도 지나기 전에 한도에 걸리기도 함

$20 플랜으로는 어디에도 못 감
월 $200로 업그레이드하면 더 많이 쓸 수 있지만, 나처럼 강하게 쓰는 사람에게도 사용량은 항상 부족함
OpenAI 파티에 RSVP했다는 이유만으로 200배 사용량을 받은 사람들이 아직도 부러움

또 하나의 숨 가쁜 영업용 글임. 광부에게 곡괭이를 파는 식인데, 금은 어디 있나? Git 위에서 서로 대화하는 챗봇들이 코드 줄 더미를 만들어서 실제로 창조한 놀라운 제품은 어디 있나? 전혀 보이지 않음

이런 들뜬 블로그 글들이 좀 더 교육적이었으면 좋겠음
예를 들어, 그렇게 강력하다고 주장하는 워크플로를 실제로 어떻게 설정하는지 단계별로 보여주고 구체적으로 시연해줬으면 함
AI 회의론자는 아님. 오히려 실제 초능력이 있다면 놓치고 싶지 않음

꽤 큰 프로젝트에서 이 글이 설명하는 방식 상당수를 쓰고 있음. 내게 잘 맞는 방식은 이렇음
새 기능에는 Gherkin 기능 명세를 쓰고, 개선에는 그것을 갱신하며, 리팩터링에는 건드리지 않음. PR에는 이 명사들로 라벨을 붙임
푸시 전 훅으로 타입 검사, 린팅, 단위 테스트, 기타 빠르고 스크립트화 가능한 검증을 돌림
저장소 안에 VitePress 하위 사이트를 만들고 에이전트가 유지하게 함. 중요한 원칙과 아키텍처 등을 문서화함
모든 페이지와 YAML 프런트매터 설명을 나열하는 CLI 명령을 만들어, 에이전트가 맥락 창을 터뜨리지 않고 읽을 것을 고르게 함 도메인 주도 설계와 모노레포를 사용함. 로직은 헤드리스 계층에 작성하고, 계층을 앱으로 조합함. 에이전트는 계층을 매우 잘 탐색함
zod 또는 해당 언어의 동등한 도구와 계약 우선 API 개발을 사용함. 개인적으로 이 부분이 가장 마음에 들고, orpc를 씀
“code”라는 단일 스킬만 만들고 생명주기를 설명함. 작업 트리를 열고, 다른 에이전트와 충돌하지 않도록 .env를 설정하고, 쓰지 않는 포트 등을 고르며, Docker가 여기에 좋음. 기능 파일을 작성하거나 갱신하고, 여기서 명세를 조율한 뒤 구현하고, playwright mcp 같은 것으로 검증하고, 푸시 전 검사를 실행하고, 푸시 후 리뷰를 기다리고, 정리한 뒤 main을 빠른 전진 병합함
여러 에이전트가 충돌 없이 테스트를 돌리도록 보장하는 데 testcontainers가 좋음
진지하게 스킬은 하나뿐임. 나머지는 전부 문서에 있음. 코드 줄 수가 아니라 “좋은 소프트웨어를 만든다”는 의미에서 매우 생산적으로 느껴짐

이런 블로그 글 상당수는 다음 유행어인 하네스를 잡으려는 것 같음. 10~15년 전에 봤던 생산성 포르노 사고방식과 거의 비슷함. 일상 작업에 시스템을 쓰는 것보다 복잡한 시스템을 만드는 일이 더 흥미로워지는 식임

동의함. 작업 중인 저장소에 이 글을 따라 적용해봤는데, “프로바이더”를 구체적으로 어떻게 구현했고 가져오기 계층을 어떻게 강제했는지 추론하기가 매우 어려웠음. 샘플 저장소가 있었으면 좋았을 것 같음

초기에 이걸 시도해봤음. 코드를 쓰기 전에 ChatGPT를 “프로젝트 관리자”로 써서 전체 하네스를 세팅하게 했음. 일주일 뒤 규칙, 아키텍처, 프레임워크 문서가 140개 넘게 나왔고 코드 줄은 0줄이었음
나중에 다른 도구로 검토하게 하자 판정은 “완벽하게 안전한 빈 금고”였음. 하네스는 흠잡을 데 없었지만, 안에는 아무것도 없었음
하네스는 중요하지만, 코드 출시와 병행하지 않으면 그냥 허구를 쓰는 것뿐임