Stripe·OpenAI의 하네스 엔지니어링: 주당 1,300개 PR을 버티는 AI 코딩 에이전트 인프라

2026년 기준, AI 에이전트가 작성한 코드가 수천 개의 PR로 매주 프로덕션에 머지되는 시대가 열렸다. Stripe는 내부 시스템 "Minions"을 통해 주당 1,300개의 AI 작성 PR을 처리하고 있으며, OpenAI의 Codex 팀은 불과 5개월 만에 100만 줄 이상의 프로덕션 코드를 AI 에이전트만으로 배포했다. 이 두 사례는 단순한 실험이 아니라, 엔터프라이즈 규모에서 AI 에이전트 코딩을 안정적으로 운용하기 위한 하네스 엔지니어링(Harness Engineering)의 현실적 청사진을 제시한다.

모델이 아니라 인프라가 성패를 가른다

하네스 엔지니어링은 "어떤 모델을 쓰느냐"가 아니라 "어떤 인프라로 감싸느냐"의 문제다. 같은 LLM이라도 하네스 설계에 따라 프로덕션 투입 가능 여부가 갈린다. Stripe와 OpenAI의 사례 모두 공통적으로 세 가지 축을 강조한다. 바로 태스크 스코핑, 샌드박스 격리, 인간 리뷰 게이트다. 이 세 축이 얼마나 정교하게 설계되느냐에 따라 에이전트의 머지율과 조직 신뢰도가 결정된다.

Stripe의 경우 약 70%의 AI 작성 PR이 인간 수정 없이 머지되고 있다. OpenAI의 경우에는 아예 인간이 직접 코드를 기여하지 않는다는 철학을 채택했다. 두 조직 모두 모델의 능력보다 거버넌스 인프라의 완성도가 핵심이라는 결론에 도달했다.

Stripe Minions: 결정론적 게이트와 에이전트 노드의 교차

Stripe는 2025년 중반 "Minions"이라는 이름의 내부 AI 코딩 에이전트 시스템을 공개했다. "Minions"이라는 명칭은 좁고 명확한 단위 작업을 처리하는 소형 자율 에이전트라는 개념에서 비롯됐다. 엔지니어가 Slack에서 특정 반응(이모지)을 남기면 Minion이 태스크를 자동으로 픽업하고 PR까지 자동 생성한다.

Stripe의 핵심 설계 철학은 에이전트에게 넓은 자율권을 주는 것이 아니라 명확하게 좁은 범위의 태스크를 부여하는 것이다. 이를 위해 "블루프린트(Blueprint)"라는 워크플로우 템플릿을 쓴다. 블루프린트는 두 종류의 노드로 구성된다. 결정론적 노드는 린팅 실행·CI 트리거·diff 추출 같은 고정된 코드 실행 단계로, 에이전트가 이 단계를 "선택"하는 것이 아니라 시스템이 강제한다. 에이전트 노드는 LLM이 추론하고 코드를 생성하는 열린 단계로, 이 단계에서만 창의적 판단이 허용된다.

이 하이브리드 패턴은 열린 LLM 단계와 경직된 결정론적 게이트를 교차 배치해 에이전트의 창의성과 예측 가능성을 동시에 확보한다. 예컨대 코드 생성(에이전트) → 린팅(결정론적) → 테스트 실행(결정론적) → 실패 수정 시도(에이전트) → PR 생성(결정론적) 순서로 진행된다.

⤢✕

각 Minion은 독립된 컨테이너 환경에서 실행된다. 신선한 코드베이스 체크아웃을 받아 격리된 상태에서 작업하므로, 한 에이전트의 실패나 오동작이 다른 에이전트에 영향을 미치지 않는다. 태스크 스코핑이 독립적이기 때문에 수백 개의 에이전트를 조율 오버헤드 없이 병렬로 실행할 수 있다 — 주당 1,300개라는 처리량의 핵심 비결이다. 격리 설계의 또 다른 측면은 보안이다. 에이전트가 외부 네트워크나 다른 서비스에 접근하지 못하도록 제한해, AI 에이전트가 의도치 않은 사이드 이펙트를 만들어내는 위험을 최소화한다.

Stripe는 에이전트에 대한 무조건적 신뢰를 택하지 않았다. 모든 Minion 생성 PR은 인간 엔지니어의 코드 리뷰를 거친다. 다만 리뷰 방식은 일반적인 인간 PR 리뷰와 동일하다. AI가 작성했다는 이유로 특별한 절차를 추가하지 않고, 기존 리뷰 문화 안에서 통합된 것이다. 자동 에스컬레이션 로직도 중요하다. CI 실패를 2회 시도 내에 자체 수정하지 못하면 에이전트는 스스로 멈추고 인간에게 에스컬레이션한다. 이는 "컴퓨트 낭비 방지"와 "인간 감독 유지"를 동시에 달성하는 실용적 설계다.

OpenAI Codex 팀: 인간이 코드를 한 줄도 안 쓰는 5개월

OpenAI Codex 팀은 2025년 8월 말 빈 저장소에서 시작해 5개월 후 약 100만 줄의 프로덕션 코드를 배포하는 데 성공했다. 애플리케이션 로직, 인프라, 툴링, 문서, 내부 개발자 유틸리티 등 전 영역을 포함한다. 초기 3명이었던 팀은 7명으로 증가했고, 엔지니어당 하루 평균 3.5개의 PR을 머지하는 처리량을 달성했다. 가장 주목할 점은 이 기간 동안 인간이 직접 코드를 한 줄도 작성하지 않았다는 것이다. 단순한 "AI 보조" 수준을 훨씬 뛰어넘는, 진정한 AI 에이전트 주도 개발 모델이다.

OpenAI Codex 팀이 이 과정에서 도출한 하네스 엔지니어링의 5가지 핵심 원칙은 다음과 같다. 컨텍스트 엔지니어링은 에이전트가 런타임에 접근할 수 없는 정보는 존재하지 않는 것과 같다는 전제로, 올바른 정보를 올바른 시점에 에이전트 컨텍스트에 제공하는 설계가 전체 품질의 기반이 된다는 원칙이다. 구조화된 문서화는 docs/ 디렉토리를 시스템 오브 레코드로 취급하는 것으로, 약 100줄짜리 AGENTS.md 파일이 컨텍스트에 주입되며 이는 주로 더 깊은 정보 소스로의 포인터 역할을 한다. 아키텍처 제약은 Types → Config → Repo → Service → Runtime → UI라는 단방향 의존성 레이어를 강제해, 에이전트가 이 레이어 경계를 넘는 코드를 생성하면 자동으로 거부되도록 한다. 제약이 클수록 에이전트의 안정성이 높아진다. 관찰 가능성 통합은 Chrome DevTools Protocol을 에이전트 런타임에 연결해 DOM 스냅샷·스크린샷·내비게이션 정보를 에이전트가 직접 활용할 수 있게 한 것으로, 태스크 전후 스냅샷을 비교해 에이전트가 자체 수정 루프를 실행한다. 환경 설계 중심은 인간 엔지니어의 역할이 코드 구현에서 환경 설계·의도 명세·구조화된 피드백 제공으로 전환된다는 원칙이다 — 코드를 쓰는 사람이 아니라 에이전트가 잘 작동할 수 있는 환경을 만드는 사람이 되는 것이다.

⤢✕

OpenAI 팀이 "인간이 코드를 직접 작성하지 않는다"는 원칙을 고수한 이유는 단순히 자동화 효율 때문이 아니다. 이 제약이 하네스 설계를 더 강하게 만들기 때문이다. 인간이 직접 수정할 수 없다면, 에이전트가 스스로 해결할 수 있도록 환경을 정교하게 설계해야 한다. 이 압박이 오히려 더 견고한 시스템을 만들어낸다는 것이 팀의 핵심 학습이다.

에이전트가 쓴 코드의 품질을 어떻게 보증하는가

두 사례 모두 에이전트가 생성한 코드에 기존 CI/CD 파이프라인을 그대로 적용한다. 특별히 "AI용 CI"를 따로 만들지 않는다. 이는 중요한 설계 원칙이다. 에이전트 작성 코드가 인간 작성 코드와 동일한 품질 기준을 통과해야 한다는 신호를 조직 전체에 보내기 때문이다. Stripe의 경우 블루프린트 내 결정론적 노드가 린팅과 정적 분석을 자동 실행하도록 강제한다. 에이전트가 이 단계를 건너뛸 수 없다. OpenAI의 경우 아키텍처 제약 레이어가 설계 수준에서 코드 품질을 제어한다. 레이어 위반 코드는 생성 단계에서 이미 거부된다.

⤢✕

Stripe 에이전트의 약 70% PR 무수정 머지율은 자연스럽게 에이전트 신뢰도 지표로 기능한다. 특정 유형의 태스크에서 머지율이 떨어지거나 에스컬레이션 빈도가 높아지면, 해당 블루프린트의 설계를 개선하는 피드백으로 활용한다. 신뢰도 관리의 또 다른 축은 에스컬레이션 임계값 설정이다. CI 실패 2회 초과 시 자동 에스컬레이션이라는 규칙은 단순해 보이지만, 에이전트가 풀기 어려운 문제에 컴퓨트를 낭비하지 않도록 막는 중요한 안전장치다. 이 임계값을 너무 낮게 설정하면 에이전트 효용이 떨어지고, 너무 높게 설정하면 인간 감독이 약해진다. 조직마다 최적값을 실험적으로 찾아야 한다.

대규모 AI 코딩 조직은 어떻게 통합되는가

주당 1,300개의 PR은 리뷰어에게 상당한 부하가 될 수 있다. Stripe가 이를 해결하는 방법은 두 가지다. 첫째, 태스크 스코핑을 통해 각 PR의 변경 범위를 최소화한다. 좁은 범위의 PR은 리뷰 시간이 짧다. 둘째, 70%의 PR이 무수정 머지될 만큼 품질이 높기 때문에 리뷰 자체가 빠르게 진행된다. 인간 리뷰어의 역할도 변화한다. 구현 세부사항을 검토하는 것에서 에이전트의 의도가 올바른 방향인지, 아키텍처 원칙을 잘 따르는지를 검증하는 방향으로 초점이 이동한다.

하네스 엔지니어링은 한 번 설계하면 끝이 아니다. 에이전트 동작 데이터를 분석해 블루프린트를 지속적으로 개선하는 루프가 필수적이다. 어떤 유형의 태스크에서 에스컬레이션이 자주 발생하는지, 어떤 컨텍스트 정보가 부족한지, 어떤 아키텍처 제약이 더 필요한지를 데이터 기반으로 식별하고 개선한다. OpenAI 팀이 팀 규모를 3명에서 7명으로 늘리면서도 에이전트 처리량을 함께 높일 수 있었던 것은, 추가된 엔지니어들이 코드 작성이 아니라 하네스 개선에 집중할 수 있었기 때문이다. 이것이 AI 에이전트 시대에 엔지니어링 조직이 스케일하는 방식의 핵심 변화다.

6개 레이어로 정리한 하네스 아키텍처

Stripe와 OpenAI 두 사례를 종합하면, 엔터프라이즈 AI 코딩 에이전트를 위한 6레이어 하네스 아키텍처가 도출된다.

⤢✕

이 아키텍처에서 핵심은 레이어 간 역할 분리다. 에이전트는 레이어 4에서만 창의적 판단을 행사하고, 나머지 레이어는 모두 결정론적이거나 인간이 통제한다. 이 경계가 흐려질수록 시스템의 예측 가능성이 낮아지고 프로덕션 리스크가 높아진다.

Stripe의 주당 1,300개 PR과 OpenAI Codex 팀의 5개월 100만 줄 배포는 AI 에이전트 코딩이 실험적 단계를 넘어 엔터프라이즈 표준으로 진입하고 있음을 보여준다. 두 사례의 공통된 교훈은 명확하다. 최고의 모델이 아니라 최고의 하네스가 성패를 가른다. 하네스 엔지니어링은 앞으로 소프트웨어 조직이 갖춰야 할 핵심 역량이 되고 있으며, 인간 엔지니어의 역할은 코드 작성자에서 에이전트 환경 설계자로 빠르게 이동하고 있다.