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

• 내부 베타 소프트웨어 제품은 수동 작성 코드 0줄을 고정 제약으로 삼아 Codex가 애플리케이션 로직, 테스트, CI 설정, 문서, 관측성, 내부 도구까지 작성한 실험 사례
• 빈 git 저장소에서 시작한 코드베이스는 약 5개월 뒤 약 100만 줄 규모가 되었고, 세 명의 엔지니어가 Codex를 구동해 약 1,500개 PR을 열고 병합한 PR 처리량
• 엔지니어의 주된 일은 코드 작성이 아니라 환경 설계, 의도 명세, 에이전트가 신뢰할 수 있게 일하도록 만드는 피드백 루프 구축으로 이동
• 저장소 지식은 짧은 AGENTS.md, 구조화된 docs/, 실행 계획, 린터와 CI로 관리되고, UI·로그·메트릭·추적은 Codex가 직접 읽고 검증할 수 있는 애플리케이션 가독성으로 전환
• 처리량 증가로 병합 게이트 최소화와 후속 실행 기반 수정이 실용적 선택이 되었지만, 장기적 아키텍처 일관성과 인간 판단의 인코딩은 아직 학습 과제

---

수동 작성 코드 0줄로 만든 내부 베타

• 지난 5개월 동안 내부 베타 소프트웨어 제품을 수동 작성 코드 0줄로 구축하고 출시하는 실험 진행
• 제품은 내부 일일 사용자와 외부 알파 테스터를 보유하고 있으며, 출시·배포·장애·수정 흐름을 실제로 겪는 상태
• 애플리케이션 로직, 테스트, CI 설정, 문서, 관측성, 내부 도구까지 모든 코드 라인을 Codex가 작성했고, 손으로 코드를 쓸 때보다 약 1/10의 시간에 구축했다는 추정
• 인간은 조종하고, 에이전트는 실행
• 몇 주 안에 최종적으로 100만 줄 규모가 된 결과물을 출시해야 했고, 이를 위해 엔지니어링 팀의 주 업무가 코드 작성에서 환경 설계, 의도 명세, 피드백 루프 구축으로 이동

빈 git 저장소에서 시작

• 빈 저장소의 첫 커밋은 2025년 8월 말에 발생
• 초기 스캐폴드인 저장소 구조, CI 설정, 포매팅 규칙, 패키지 매니저 설정, 애플리케이션 프레임워크는 GPT-5를 사용하는 Codex CLI가 기존 템플릿 일부의 안내를 받아 생성
• 에이전트가 저장소에서 일하는 방식을 안내하는 초기 AGENTS.md 파일도 Codex가 작성
• 시스템을 지탱하는 기존 인간 작성 코드는 없었고, 저장소는 처음부터 에이전트에 의해 형성
• 5개월 뒤 저장소는 애플리케이션 로직, 인프라, 도구, 문서, 내부 개발자 유틸리티 전반에서 약 100만 줄 규모
• 세 명의 엔지니어가 Codex를 구동해 약 1,500개 PR을 열고 병합했으며, 이는 엔지니어 1인당 하루 평균 3.5개 PR 처리량
• 팀이 현재 일곱 명의 엔지니어로 커진 뒤에도 처리량은 증가
• 결과물은 출력 자체를 위한 출력이 아니며, 제품은 내부 파워 유저를 포함한 수백 명의 내부 사용자가 사용
• 개발 과정 전반에서 인간은 코드를 직접 기여하지 않았고, 수동 작성 코드 없음이 팀의 핵심 철학

엔지니어 역할 재정의

• 인간이 직접 코딩하지 않는 제약은 시스템, 스캐폴딩, 레버리지에 집중하는 다른 종류의 엔지니어링 작업을 도입
• 초기 진척은 예상보다 느렸지만 Codex의 역량 부족 때문이 아니라 환경이 충분히 명세되지 않았기 때문
• 에이전트는 높은 수준의 목표를 향해 진척하는 데 필요한 도구, 추상화, 내부 구조가 부족한 상태
• 엔지니어링 팀의 주 업무는 에이전트가 유용한 일을 할 수 있도록 만드는 것
• 실제 작업은 큰 목표를 설계, 코드, 리뷰, 테스트 같은 더 작은 빌딩 블록으로 나누고, 에이전트가 그 블록을 만들도록 프롬프트를 주며, 이를 더 복잡한 작업의 발판으로 삼는 깊이 우선 방식
• 실패 시 해결책은 “더 열심히 시도”가 아니라, Codex가 일을 하도록 만드는 데 빠진 역량이 무엇인지 찾고 이를 에이전트가 읽고 따를 수 있게 만드는 방식
• 인간은 대부분 프롬프트로 시스템과 상호작용하며, 엔지니어가 작업을 설명하고 에이전트를 실행한 뒤 PR을 열게 하는 흐름
• PR 완료 과정에서 Codex는 로컬에서 자체 변경을 리뷰하고, 로컬과 클라우드에서 추가 에이전트 리뷰를 요청하며, 인간 또는 에이전트 피드백에 응답하고, 모든 에이전트 리뷰어가 만족할 때까지 반복하는 Ralph Wiggum Loop에 가까운 방식
• Codex는 gh, 로컬 스크립트, 저장소 내장 스킬 같은 표준 개발 도구를 직접 사용해 인간의 복사·붙여넣기 없이 맥락을 수집
• 인간은 PR을 리뷰할 수 있지만 필수는 아니며, 시간이 지나면서 거의 모든 리뷰 작업은 에이전트 간 처리로 이동

애플리케이션 가독성 높이기

• 코드 처리량이 증가하면서 병목은 인간 QA 역량으로 이동
• 고정 제약이 인간의 시간과 주의였기 때문에, 애플리케이션 UI, 로그, 앱 메트릭 자체를 Codex가 직접 읽을 수 있게 만들어 에이전트 역량을 확장
• 애플리케이션은 git worktree별로 부팅 가능하게 구성해 Codex가 변경마다 인스턴스 하나를 실행하고 조작할 수 있는 구조
• Chrome DevTools Protocol을 에이전트 런타임에 연결하고 DOM 스냅샷, 스크린샷, 내비게이션 작업용 스킬을 생성
• Codex는 이를 통해 버그를 재현하고, 수정 사항을 검증하며, UI 동작을 직접 추론 가능
• 로그, 메트릭, 추적은 특정 worktree에 대해 일시적으로 존재하는 로컬 관측성 스택을 통해 Codex에 노출
• Codex는 로그와 메트릭까지 포함한 완전히 격리된 앱 버전에서 작업하며, 해당 작업이 끝나면 관련 로그와 메트릭도 제거
• 에이전트는 LogQL로 로그를 질의하고 PromQL로 메트릭을 질의
• “서비스 시작이 800ms 미만에 완료되도록 보장” 또는 “네 가지 핵심 사용자 여정의 어떤 span도 2초를 넘지 않도록 보장” 같은 프롬프트가 실행 가능한 작업으로 전환
• 단일 Codex 실행이 하나의 작업을 6시간 이상 수행하는 경우가 자주 있으며, 그 시간은 종종 인간이 자는 동안

저장소 지식을 시스템 기록으로 만들기

• 대규모·복잡 작업에서 에이전트를 효과적으로 만드는 핵심 난제 중 하나는 맥락 관리
• Codex에는 1,000쪽짜리 지침서가 아니라 지도가 필요
  • 맥락은 희소 자원이며, 거대한 지침 파일은 작업, 코드, 관련 문서를 밀어내 에이전트가 핵심 제약을 놓치거나 잘못된 제약을 최적화하게 만드는 구조
  • 과도한 안내는 안내가 아니게 됨이며, 모든 것이 중요해지면 아무것도 중요하지 않아 에이전트가 의도적으로 탐색하기보다 지역적 패턴 매칭에 머무는 결과
  • 단일 거대 매뉴얼은 즉시 낡으며, 오래된 규칙의 무덤이 되고 인간이 유지보수하지 않는 매력적인 방해물로 변하는 위험
  • 단일 덩어리 파일은 커버리지, 최신성, 소유권, 교차 링크 같은 기계적 검증이 어렵기 때문에 드리프트가 불가피한 구조
• AGENTS.md는 백과사전이 아니라 목차로 취급
• 저장소 지식 기반은 시스템 기록으로 취급되는 구조화된 docs/ 디렉터리에 위치
• 약 100줄짜리 짧은 AGENTS.md가 맥락에 주입되며, 더 깊은 진실의 원천을 가리키는 지도 역할
• 설계 문서는 검증 상태와 에이전트 우선 운영 원칙을 정의하는 핵심 믿음 집합과 함께 카탈로그화·색인화
• 아키텍처 문서는 도메인과 패키지 계층의 최상위 지도를 제공
• 품질 문서는 각 제품 도메인과 아키텍처 계층을 등급화하고 시간에 따른 격차를 추적
• 계획은 1급 산출물로 취급되며, 작은 변경에는 일시적 경량 계획을 사용하고 복잡한 작업은 진행 상황과 의사결정 로그를 포함한 실행 계획으로 저장소에 커밋
• 활성 계획, 완료 계획, 알려진 기술 부채가 모두 버전 관리되고 함께 배치되며, 에이전트는 외부 맥락에 의존하지 않고 작업 가능
• 이 구조는 점진적 공개를 가능하게 하며, 에이전트는 처음부터 압도되는 대신 작고 안정적인 진입점에서 시작해 다음에 볼 곳을 학습
• 전용 린터와 CI 작업은 지식 기반의 최신성, 교차 링크, 구조 정확성을 검증
• 반복 실행되는 문서 정원 관리 에이전트는 실제 코드 동작을 반영하지 않는 낡거나 obsolete 문서를 찾아 수정 PR을 생성

에이전트 가독성이 목표

• 코드베이스 전체가 에이전트 생성물이기 때문에 최우선 최적화 대상은 Codex의 가독성
• 새 엔지니어가 코드를 탐색하기 쉽게 만드는 것처럼, 인간 엔지니어의 목표는 에이전트가 전체 비즈니스 도메인을 저장소 자체에서 직접 추론하게 만드는 것
• 에이전트 관점에서 실행 중 맥락 안에서 접근할 수 없는 것은 사실상 존재하지 않는 것
• Google Docs, 채팅 스레드, 사람의 머릿속에 있는 지식은 시스템 접근 대상이 아니며, 저장소 로컬의 버전 관리 산출물인 코드, 마크다운, 스키마, 실행 계획만 에이전트가 볼 수 있는 대상
• Slack 논의로 팀이 아키텍처 패턴에 합의했더라도 에이전트가 발견할 수 없다면, 3개월 뒤 합류한 신입에게 알려지지 않은 지식과 같은 상태
• Codex에 더 많은 맥락을 준다는 것은 임의 지침을 쏟아붓는 일이 아니라, 에이전트가 추론할 수 있도록 올바른 정보를 조직하고 노출하는 일
• 새 팀원에게 제품 원칙, 엔지니어링 규범, 팀 문화, 이모지 선호까지 온보딩하듯 에이전트에도 이 정보를 제공하면 더 정렬된 출력으로 연결
• 의존성과 추상화는 저장소 안에서 완전히 내재화되고 추론 가능한 쪽을 선호
• 흔히 “지루한” 기술은 조합성, API 안정성, 학습 데이터 내 표현 때문에 에이전트가 모델링하기 쉬운 경향
• 일부 경우에는 공개 라이브러리의 불투명한 상위 동작을 우회하는 것보다 에이전트가 기능 일부를 다시 구현하는 편이 더 저렴
• 범용 p-limit 스타일 패키지를 가져오는 대신 자체 map-with-concurrency 헬퍼를 구현했으며, 이는 OpenTelemetry 계측과 긴밀히 통합되고 100% 테스트 커버리지를 가지며 런타임 기대와 정확히 일치하는 동작
• 에이전트가 직접 검사, 검증, 수정할 수 있는 형태로 시스템을 더 많이 끌어들이면 Codex뿐 아니라 같은 코드베이스에서 작업하는 Aardvark 같은 다른 에이전트의 레버리지도 증가

아키텍처와 취향 강제

• 문서만으로는 완전한 에이전트 생성 코드베이스의 일관성을 유지하기에 부족
• 구현을 세세하게 관리하지 않고 불변 조건을 강제함으로써 에이전트가 기반을 약화시키지 않고 빠르게 출시할 수 있는 구조
• Codex에는 경계에서 데이터 형태를 파싱하도록 요구하지만, 그 방법까지 규정하지는 않는 방식
• 에이전트는 엄격한 경계와 예측 가능한 구조를 가진 환경에서 가장 효과적이므로, 애플리케이션은 견고한 아키텍처 모델 중심으로 구성
• 각 비즈니스 도메인은 고정된 계층 집합으로 나뉘며, 의존 방향과 허용 가능한 연결은 엄격하게 검증
• 이 제약은 Codex가 생성한 커스텀 린터와 구조 테스트로 기계적으로 강제
• 각 비즈니스 도메인에서는 코드가 Types → Config → Repo → Service → Runtime → UI의 고정 계층을 따라 앞으로만 의존 가능
• 인증, 커넥터, 텔레메트리, 기능 플래그 같은 횡단 관심사는 Providers라는 단일 명시 인터페이스를 통해서만 진입 가능
• 그 외 의존은 허용되지 않으며 기계적으로 차단
• 이런 아키텍처는 보통 수백 명의 엔지니어가 생길 때까지 미루는 종류지만, 코딩 에이전트 환경에서는 속도를 유지하면서 부패와 아키텍처 드리프트를 막기 위한 초기 전제조건
• 실제 운영에서는 커스텀 린터, 구조 테스트, 작은 “취향 불변 조건” 집합으로 규칙을 강제
• 구조화 로깅, 스키마와 타입 이름 규칙, 파일 크기 제한, 플랫폼별 신뢰성 요구사항을 커스텀 린트로 정적 강제
• 커스텀 린트의 오류 메시지는 에이전트 맥락에 수정 지침을 주입하도록 작성
• 인간 우선 워크플로에서는 이런 규칙이 지나치게 꼼꼼하거나 제약적으로 느껴질 수 있지만, 에이전트 환경에서는 한 번 인코딩한 규칙이 전체에 동시에 적용되는 승수
• 중앙에서는 경계, 정확성, 재현성을 강하게 관리하고, 그 안에서는 팀 또는 에이전트가 해결 표현 방식에서 큰 자유를 갖는 구조
• 결과 코드가 인간의 스타일 선호와 항상 맞지는 않지만, 정확하고 유지보수 가능하며 향후 에이전트 실행이 읽을 수 있다면 기준 충족
• 인간의 취향은 리뷰 코멘트, 리팩터링 PR, 사용자 대면 버그를 통해 문서 업데이트나 도구로 계속 환류
• 문서가 부족하면 규칙은 코드로 승격

처리량이 바꾼 병합 철학

• Codex 처리량이 증가하면서 기존 엔지니어링 규범 중 상당수가 역효과를 내는 상태
• 저장소는 최소한의 블로킹 병합 게이트로 운영
• PR은 짧게 유지
• 테스트 플래이크는 진행을 무기한 막기보다 후속 실행으로 처리하는 경우가 많음
• 에이전트 처리량이 인간 주의를 크게 초과하는 시스템에서는 수정 비용이 낮고 대기 비용이 높은 구조
• 낮은 처리량 환경에서는 무책임할 수 있는 방식이지만, 이 환경에서는 자주 올바른 트레이드오프

“에이전트 생성”의 실제 범위

• 코드베이스가 Codex 에이전트로 생성된다는 말은 코드베이스 안의 모든 것을 뜻함
• 에이전트가 만드는 대상
  • 제품 코드와 테스트
  • CI 설정과 릴리스 도구
  • 내부 개발자 도구
  • 문서와 설계 이력
  • 평가 하네스
  • 리뷰 코멘트와 응답
  • 저장소 자체를 관리하는 스크립트
  • 프로덕션 대시보드 정의 파일
• 인간은 항상 루프 안에 있지만, 이전보다 더 높은 추상화 계층에서 작업
• 인간은 작업 우선순위를 정하고, 사용자 피드백을 인수 기준으로 번역하며, 결과를 검증
• 에이전트가 어려움을 겪으면 도구, 가드레일, 문서 중 무엇이 빠졌는지 찾는 신호로 취급하고, 그 수정 역시 Codex가 작성하도록 저장소에 환류
• 에이전트는 표준 개발 도구를 직접 사용하며, 리뷰 피드백을 가져오고, 인라인으로 응답하고, 업데이트를 푸시하며, 자체 PR을 squash 후 병합하는 경우도 많음

자율성 수준 높이기

• 테스트, 검증, 리뷰, 피드백 처리, 복구가 시스템 안에 더 많이 인코딩되면서 Codex가 새 기능을 처음부터 끝까지 추진할 수 있는 임계점을 최근 통과
• 단일 프롬프트만으로 에이전트가 수행할 수 있는 작업
  • 현재 코드베이스 상태 검증
  • 보고된 버그 재현
  • 실패를 보여주는 동영상 기록
  • 수정 구현
  • 애플리케이션을 직접 조작해 수정 검증
  • 해결을 보여주는 두 번째 동영상 기록
  • PR 열기
  • 에이전트와 인간 피드백에 응답
  • 빌드 실패 감지와 수정
  • 판단이 필요할 때만 인간에게 에스컬레이션
  • 변경 병합
• 이 동작은 해당 저장소의 구체적인 구조와 도구에 크게 의존하며, 비슷한 투자가 없으면 일반화된다고 가정해서는 안 되는 상태

엔트로피와 가비지 컬렉션

• 완전한 에이전트 자율성은 새로운 문제도 도입
• Codex는 저장소에 이미 존재하는 패턴을 복제하며, 그 패턴이 고르지 않거나 최적이 아니어도 반복
• 시간이 지나면 이런 반복은 드리프트로 이어짐
• 초기에는 인간이 이를 수동으로 처리했고, 팀은 매주 금요일, 즉 주당 20%를 “AI slop” 정리에 사용
• 이 방식은 확장되지 않았기 때문에 “골든 원칙”을 저장소에 직접 인코딩하고 반복 정리 프로세스를 구축
• 골든 원칙은 향후 에이전트 실행을 위해 코드베이스를 읽기 쉽고 일관되게 유지하는 의견 강한 기계적 규칙
• 예시 원칙은 불변 조건을 중앙화하기 위해 손으로 만든 헬퍼보다 공유 유틸리티 패키지를 선호하는 것
• 또 다른 예시는 데이터를 “YOLO식”으로 탐색하지 않고, 에이전트가 추측한 형태 위에 우연히 구축하지 못하도록 경계를 검증하거나 타입 SDK에 의존하는 것
• 정기적으로 백그라운드 Codex 작업이 편차를 스캔하고, 품질 등급을 업데이트하며, 대상 리팩터링 PR을 생성
• 대부분의 리팩터링 PR은 1분 이내에 리뷰 가능하고 자동 병합 가능
• 이 과정은 가비지 컬렉션처럼 동작
• 기술 부채는 고금리 대출과 같으며, 쌓이게 두었다가 고통스럽게 한꺼번에 처리하는 것보다 작은 단위로 계속 갚는 편이 거의 항상 더 나은 방식
• 인간 취향은 한 번 포착된 뒤 모든 코드 라인에 지속적으로 강제
• 나쁜 패턴은 코드베이스에서 며칠 또는 몇 주 퍼지기 전에 매일 포착하고 해결 가능

아직 배우는 중

• 이 전략은 지금까지 OpenAI 내부 출시와 도입 단계까지 잘 작동
• 실제 사용자를 위한 실제 제품 구축은 투자를 현실에 고정하고 장기 유지보수성 쪽으로 이끄는 역할
• 완전한 에이전트 생성 시스템에서 아키텍처 일관성이 수년에 걸쳐 어떻게 변하는지는 아직 미지수
• 인간 판단이 어디에서 가장 큰 레버리지를 더하는지, 그 판단을 어떻게 인코딩해 누적 효과를 만들 수 있는지도 계속 학습 중
• 모델이 시간이 지나며 더 유능해질 때 이 시스템이 어떻게 진화할지도 아직 알 수 없는 영역
• 분명해진 점은 소프트웨어 구축이 여전히 규율을 요구하지만, 그 규율이 코드보다 스캐폴딩에서 더 크게 드러난다는 것
• 코드베이스 일관성을 유지하는 도구, 추상화, 피드백 루프의 중요성은 계속 증가
• 현재 가장 어려운 과제는 에이전트가 복잡하고 신뢰할 수 있는 소프트웨어를 대규모로 만들고 유지하도록 돕는 환경, 피드백 루프, 제어 시스템 설계
• Codex 같은 에이전트가 소프트웨어 생애주기의 더 큰 부분을 맡을수록 이런 질문의 중요성은 더 커지는 흐름
• 초기 학습은 어디에 노력을 투자해야 무언가를 그냥 만들 수 있는지 판단하는 데 도움을 주는 자료

[GN⁺]

Hacker News 의견들

• 처리량이 말도 안 되는 수준임. 기준선을 뭘로 잡아야 할지 궁금함. 에이전트 코딩 이전에는 엔지니어가 보통 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가 좋음
    진지하게 스킬은 하나뿐임. 나머지는 전부 문서에 있음. 코드 줄 수가 아니라 “좋은 소프트웨어를 만든다”는 의미에서 매우 생산적으로 느껴짐
  • 사이드 프로젝트 예시[1]가 있는데, 이 글에서 말한 모범 사례를 자연스럽게 적용했다고 봄. 목표는 단일 에이전트(Claude)만으로 전체 프로젝트를 코딩할 수 있는지 확인하는 것이었음
    이를 위해 에이전트가 문제를 만날 때마다 검증 도구나 스크립트를 써서 어떻게 해결할지 물었음. 감사 과정에서 이런 도구도 직접 코딩하게 했음. 그 결과 지금은 커밋 검증용 규칙이 30개 넘게 생겼고[2], 꽤 잘 작동함
    [1] https://github.com/gildas-lormeau/rebuild-and-ruin (“데모” 모드를 보려면 타이머가 끝날 때까지 두면 됨)
    [2] https://github.com/gildas-lormeau/rebuild-and-ruin/blob/a4c3...
  • 이런 블로그 글 상당수는 다음 유행어인 하네스를 잡으려는 것 같음. 10~15년 전에 봤던 생산성 포르노 사고방식과 거의 비슷함. 일상 작업에 시스템을 쓰는 것보다 복잡한 시스템을 만드는 일이 더 흥미로워지는 식임
  • 동의함. 작업 중인 저장소에 이 글을 따라 적용해봤는데, “프로바이더”를 구체적으로 어떻게 구현했고 가져오기 계층을 어떻게 강제했는지 추론하기가 매우 어려웠음. 샘플 저장소가 있었으면 좋았을 것 같음

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