AI로 만드는 소프트웨어: 수동 코딩 없이 완성한 제품 개발 사례

핵심 요약

• 제로 핸드코딩(Zero Handwritten Code) 프로젝트: 5개월간 100만 줄의 코드를 작성했으나, 수동으로 작성된 코드는 단 한 줄도 없음
• 엔지니어 역할의 재정의: 개발자들이 코드 작성 대신 환경 설계, 의도 명시, 피드백 루프 구축에 집중
• 처리량의 혁신: 3명의 엔지니어 팀으로 1,500개의 풀 리퀘스트 병합 (1인당 일 3.5개 PR)
• 컨텍스트 관리의 중요성: 1,000페이지 매뉴얼보다는 구조화된 문서와 기록 시스템으로 AI 가독성 최적화
• 아키텍처 제약의 힘: 엄격한 의존성 규칙과 계층화 구조가 속도와 안정성의 곱셈기 역할

AI 에이전트와 함께하는 소프트웨어 개발의 미래

지난 5개월간 우리 팀이 수행한 실험은 소프트웨어 엔지니어링의 패러다임을 근본적으로 전환했습니다. 빈 Git 저장소에서 시작하여, 한 줄의 수동 코드도 작성하지 않고 100만 줄 규모의 완전한 소프트웨어 제품을 완성했습니다. 이는 단순한 자동화 프로젝트가 아니라, AI 에이전트가 소프트웨어 개발의 주체가 되는 미래의 개발 방식을 보여주는 실제 사례입니다.

이 성과는 무에서 유를 창조한 것이 아닙니다. 우리는 AI 에이전트(Codex)가 신뢰할 수 있는 작업을 수행할 수 있도록 체계적으로 환경을 설계하고, 피드백 루프를 구축했으며, 명확한 지침을 제공했습니다. 인간 엔지니어가 직접 코드를 작성하지 않았다는 것은, 그들의 역할이 축소되었다는 의미가 아니라, 오히려 더 전략적이고 영향력 있는 수준으로 진화했다 는 의미입니다.

빈 저장소에서 시작한 여정: 완전한 제로 핸드코딩의 실현

우리 프로젝트의 첫 번째 커밋은 2025년 8월 말에 이루어졌습니다. 놀랍게도, 초기 스캐폴드(저장소 구조, CI 구성, 포맷팅 규칙, 패키지 관리자 설정, 애플리케이션 프레임워크)도 모두 Codex가 생성했습니다. 저장소의 구조와 규칙을 지시하는 초기 AGENTS.md 파일조차 AI가 직접 작성했습니다.

이 접근 방식은 혁신적이었습니다. 보통의 프로젝트는 기초 코드를 먼저 손으로 작성한 후 그 위에 자동화 도구를 올립니다. 하지만 우리는 처음부터 에이전트가 리포지토리를 형성하고 관리하도록 설계했습니다. 이는 단순한 선택이 아니라, AI와 인간이 협력하는 새로운 방식을 실험하기 위한 의도적인 결정이었습니다.

5개월이 지난 후, 저장소는 다음을 포함한 약 100만 줄의 코드로 성장했습니다:

• 애플리케이션 로직 및 비즈니스 기능
• 종합적인 테스트 스위트
• CI/CD 파이프라인 및 배포 자동화
• 내부 개발 도구 및 유틸리티
• 상세한 문서화 및 설계 이력
• 프로덕션 모니터링 및 관측성 도구

이 기간 동안, 초기 3명의 엔지니어 팀으로 1,500개의 풀 리퀘스트 를 성공적으로 병합했습니다. 이는 엔지니어 1명당 일일 평균 3.5개의 PR 처리량 을 의미합니다. 팀이 7명으로 확장되었을 때도 이 처리량은 계속 증가했습니다.

더욱 중요한 것은, 이 코드가 단순한 이론적 산물이 아니라는 점입니다. 매일 수백 명의 내부 사용자들이 이 소프트웨어를 실제로 사용하고 있으며, 일부는 핵심 파워 유저로서 매일의 업무에 의존하고 있습니다. 제품은 지속적으로 배포되고, 버그가 발견되고, 수정되는 실제 생산 환경에서 운영되고 있습니다.

이 모든 것이 수동으로 작성된 코드 없이 이루어졌다는 점은 우리 팀의 핵심 철학이 되었습니다: "수동으로 작성된 코드는 없다(Zero Handwritten Code)". 하지만 이것이 인간의 개입이 없다는 의미는 절대 아닙니다.

엔지니어의 역할이 근본적으로 재정의되다

초기 단계에서 우리가 마주친 가장 큰 도전은 처리량이 아니라 방향성 이었습니다. 많은 사람들이 AI 에이전트의 주요 문제가 "능력 부족"이라고 생각하지만, 우리가 경험한 것은 달랐습니다. 초기 진행이 느렸던 이유는 Codex의 역량이 부족해서가 아니라, 환경이 충분히 명확하게 정의되지 않았기 때문 이었습니다.

에이전트는 광범위한 목표를 달성하기 위한 도구, 추상화, 내부 구조 가 필요합니다. 우리 엔지니어링 팀의 주요 업무는 Codex가 정확히 어떤 작업을 수행할 수 있는지 정의하고, 그 작업을 수행하기 위한 조건을 명확히 하는 것이었습니다.

이는 실제로는 깊이 우선 방식(depth-first approach) 으로 작업하는 것을 의미했습니다:

1. 더 큰 목표 분해: "새로운 결제 시스템 구축"과 같은 큰 작업을 설계, 코드 작성, 코드 리뷰, 테스트 등의 작은 구성 요소로 분해합니다.

2. 에이전트 지시: 각 구성 요소에 대해 명확한 요청으로 Codex에게 작업을 수행하도록 지시합니다.

3. 결과 활용: 완성된 구성 요소를 다음 단계의 기반으로 사용하여 더 복잡한 작업을 해결합니다.

4. 피드백 루프: 무언가 실패했을 때, 단순히 "더 열심히 노력하라"고 말하지 않습니다. 대신, "** 무엇이 부족한가(도구, 가이드라인, 문서)?" 그리고 " 에이전트가 이를 이해하고 실행할 수 있도록 어떻게 만들까?**"를 질문합니다.

결과적으로, 인간 엔지니어의 역할은 근본적으로 변했습니다. 이제 개발자들이 하는 일은:

• 프롬프트를 통한 상호작용: 작업을 설명하고, 에이전트를 실행하며, 결과를 검증합니다.
• 환경 설계: AI가 작업을 수행할 수 있도록 도구, 라이브러리, 추상화를 설계합니다.
• 의도 명시: 비즈니스 규칙, 설계 원칙, 품질 기준을 명확히 문서화합니다.
• 피드백 루프 구축: 에이전트가 자신의 작업을 검증하고, 문제를 감지하고, 자동으로 개선할 수 있는 메커니즘을 만듭니다.

더 구체적으로, Ralph Wiggum 루프(Langchain의 에이전트 검증 패턴) 라고 부르는 프로세스를 도입했습니다:

1. Codex가 PR을 제출합니다.
2. 에이전트가 자신의 변경 사항을 로컬에서 검증합니다 (코드 리뷰, 테스트 실행, 빌드 확인).
3. 추가 에이전트 검토자들이 클라우드 환경에서 검증합니다.
4. 모든 검토가 완료될 때까지 피드백에 대응하고 반복합니다.
5. 모든 에이전트 검토자가 만족하면 자동으로 병합됩니다.

이 과정에서 인간은 필요할 때만 개입합니다. 즉, 최종 승인이 필요할 때 나 판단 능력이 필요한 경우 입니다. 시간이 지남에 따라, 우리는 거의 모든 검토 작업을 에이전트 간 처리 방식으로 전환했습니다. 이는 역설적이게도 품질을 향상 시켰습니다. 에이전트는 일관성 있게 적용되는 명확한 규칙을 선호하기 때문입니다.

애플리케이션 가독성 향상: 에이전트가 직접 검증할 수 있도록

처리량이 증가하면서, 새로운 병목 현상이 나타났습니다: 인간의 QA 역량. 코드가 빠르게 생성되고 있었지만, 그 코드가 실제로 제대로 작동하는지 검증하는 것이 어려워졌습니다.

우리가 깨달은 핵심 인사이트는 간단했습니다: 에이전트가 직접 검증할 수 있도록 시스템을 만들어야 한다 는 것입니다. 이는 애플리케이션 UI, 로그, 메트릭 같은 것들을 Codex가 직접 읽고 이해할 수 있도록 설계하는 것을 의미합니다.

구체적인 구현 방식은 다음과 같습니다:

Git 워크트리별 부팅 가능한 애플리케이션

우리는 애플리케이션을 설계하여, 각각의 PR마다 별도의 애플리케이션 인스턴스를 실행할 수 있도록 했습니다. 이는 Codex가 변경 사항이 실제로 어떻게 작동하는지 직접 확인할 수 있다는 의미입니다. 단순히 코드를 읽는 것이 아니라, 실제로 실행하고 테스트 합니다.

Chrome DevTools Protocol 통합

Chrome DevTools Protocol을 에이전트 런타임에 연결하여, 다음과 같은 기능을 추가했습니다:

• DOM 스냅샷: UI 구조를 프로그래매틱하게 검사
• 스크린샷: 시각적 결과 확인
• 네비게이션 작업: UI 상호작용 자동화

이를 통해 Codex는 버그를 재현하고, 수정 사항을 검증하며, UI 동작에 대해 직접 추론할 수 있게 되었습니다. 예를 들어, "로그인 버튼이 비활성화되면 회색으로 변해야 한다"는 요구사항을 확인할 때, 에이전트는 실제로 UI를 렌더링하고 스크린샷을 비교하여 검증합니다.

관측성 도구의 에이전트 친화적 설계

우리는 로그, 메트릭, 트레이스 를 각 PR마다 생성되는 임시적인 로컬 관측성 스택을 통해 Codex에 노출했습니다. 이는 놀라운 결과를 가져왔습니다:

• Codex는 LogQL 로 로그를 쿼리할 수 있습니다.
• PromQL 을 사용하여 메트릭을 분석할 수 있습니다.
• 이 컨텍스트를 활용하여 성능 최적화 작업을 수행합니다.

예를 들어, 다음과 같은 프롬프트가 이제 처리 가능합니다:

• "서비스 시작이 800ms 이내에 완료되도록 보장하세요"
• "이 네 가지 중요한 사용자 여정에서 어떤 스팬도 2초를 초과하지 않도록 최적화하세요"
• "메모리 누수를 감지하고 해결하세요"

우리는 단일 Codex 실행이 6시간 이상 지속되면서 이러한 검증과 최적화를 자동으로 수행 하는 경우를 정기적으로 목격합니다. 종종 개발자들이 밤새 자는 동안에 이 모든 작업이 진행됩니다.

저장소를 기록 시스템으로 설계하기: AI 가독성의 최적화

컨텍스트 관리는 AI 에이전트가 큰 규모의 복잡한 작업을 효과적으로 수행하도록 만드는 데 있어 가장 중요한 과제 중 하나입니다. 우리가 배운 초기 교훈은 매우 단순했지만 강력했습니다:

"Codex에게 1,000페이지짜리 사용 설명서가 아닌 지도를 제공하세요"

과도한 지침의 문제점

초기에 우리는 모든 규칙, 가이드라인, 패턴을 거대한 AGENTS.md 파일에 넣으려고 했습니다. 이는 여러 심각한 문제를 야기했습니다:

1. 컨텍스트 압박: 거대한 지시 파일이 실제 작업, 코드, 관련 문서를 압도합니다. 에이전트는 핵심 제약 조건을 놓치거나 잘못된 제약 조건에 최적화하기 시작합니다.

2. 중요도 상실: 모든 것이 "중요"할 때, 중요한 것은 아무것도 없습니다. 에이전트는 의도적으로 탐색하는 대신 표면적인 패턴 매칭만 수행합니다.

3. 빠른 부패: 거대한 매뉴얼은 오래된 규칙들의 무덤이 됩니다. 에이전트는 무엇이 여전히 유효한지 알 수 없고, 인간은 유지 보수를 중단하며, 파일은 조용히 사용 불가능해집니다.

4. 검증 불가능: 단일 덩어리 형태의 문서는 기계적 검사(커버리지, 최신성, 소유권, 상호 연결)에 적합하지 않습니다. 따라서 불일치는 불가피합니다.

기록 시스템으로의 전환

우리는 AGENTS.md를 백과사전이 아닌 목차 로 취급하기로 결정했습니다. 짧은 AGENTS.md (약 100줄)는 다음 역할만 수행합니다:

• 개요 제공
• 다른 곳의 더 깊은 정보로 안내

실제 지식 기반은 구조화된 docs/ 디렉터리에 기록 시스템으로 저장 됩니다:

설계 문서 (Design Documents)

• 검증 상태 추적
• 에이전트 우선 운영 원칙 정의
• 팀의 핵심 신념 명시

아키텍처 문서 (Architecture Documentation)

• 도메인 및 패키지 계층화에 대한 최상위 지도
• 의존성 흐름과 제약 조건

품질 문서 (Quality Standards)

• 각 제품 도메인 및 아키텍처 계층별 평가 기준
• 시간 경과에 따른 격차 추적

실행 계획 (Execution Plans)

• 임시 경량 계획: 작은 변경 사항용
• 복잡한 실행 계획: 진행 상황, 의사 결정 로그, 완료 기준 포함
• Git에 커밋: 에이전트가 외부 컨텍스트에 의존하지 않고 모든 정보를 저장소에서 찾을 수 있도록

기술 부채 추적 (Technical Debt Registry)

• 활성 작업, 완료된 작업, 알려진 문제 모두 버전 관리
• 함께 배치되어 에이전트가 우선순위를 명확히 이해

점진적 공개와 기계적 강제

이 구조화된 접근의 장점은 점진적 공개(Progressive Disclosure) 를 가능하게 한다는 것입니다. 에이전트는 작고 안정적인 진입점(예: 목차)에서 시작하여, 필요에 따라 더 깊은 정보를 발견합니다. 처음부터 압도되지 않습니다.

더 중요하게, 우리는 이를 기계적으로 강제 합니다:

• 전용 린터: 지식 기반이 최신 상태이고, 상호 연결되어 있으며, 올바르게 구조화되어 있는지 검증합니다.
• CI 작업: 문서 일관성을 자동으로 확인합니다.
• "문서 관리" 에이전트: 정기적으로 실행되어 실제 코드 동작을 반영하지 않는 오래된 문서를 스캔하고, 수정 PR을 자동으로 엽니다.

이는 우리가 예를 들어, 사용자 인터페이스가 변경되면 문서도 자동으로 일치하도록 업데이트되도록 보장한다는 의미입니다. 수동 유지보수가 아니라 시스템이 자동으로 일관성을 유지 합니다.

에이전트 가독성 우선: 코드 스타일의 근본적 재정의

전통적인 소프트웨어 엔지니어링에서, 우리는 인간 개발자의 가독성 을 위해 코드를 작성합니다. 변수 이름, 함수 구조, 주석, 패턴 선택 등 모든 것이 인간이 이해하기 쉽도록 최적화됩니다.

그런데 우리의 저장소는 전적으로 에이전트에 의해 생성 되었습니다. 따라서 우리는 설계 결정의 우선순위를 근본적으로 변경했습니다:

"인간 가독성이 아니라 에이전트 가독성이 일차 목표다"

이는 단순한 철학적 변화가 아닙니다. 실제 구현상의 차이를 만듭니다:

에이전트 관점의 컨텍스트 존재

에이전트는 실행 중 컨텍스트 내에서 접근할 수 없는 것은 사실상 존재하지 않는 것처럼 작동 합니다. 이는 매우 중요한 의미입니다:

• Google Docs에 있는 정보: 에이전트가 접근할 수 없음 → 에이전트는 그것을 알지 못함
• Slack 토론: 동일하게 접근 불가능 → 존재하지 않는 것과 같음
• 개발자의 머릿속 지식: 명시되지 않는 한 활용 불가능

따라서 저장소 내부에 버전 관리된 아티팩트(코드, 마크다운, 스키마, 실행 가능한 계획) 만이 에이전트가 볼 수 있고 학습할 수 있습니다.

모든 지식을 저장소로

이 깨달음은 우리의 접근 방식을 완전히 바꿨습니다. 팀이 Slack에서 아키텍처 패턴에 대해 논의했나요? 그것을 발견할 수 없다면, 3개월 후 새로 합류한 인턴에게 알려지지 않는 것과 마찬가지로 에이전트에게도 이해 불가능 합니다.

따라서 우리는 다음을 저장소에 직접 인코딩합니다:

• 설계 결정: 언제, 왜 이렇게 했는지
• 아키텍처 패턴: 반복되는 구조와 규칙
• 팀 문화: 코딩 규칙, 이모지 선호도, 커뮤니케이션 스타일
• 기술 선택 이유: 왜 라이브러리 A를 선택했고 B는 선택하지 않았는지

이는 또한 신입 인간 개발자의 온보딩을 놀랍게도 더 쉽게 만듭니다. 에이전트처럼 새로운 팀원도 같은 문서에서 학습할 수 있습니다.

코드 구현의 재정의

에이전트 가독성이 목표가 되면서, 전통적인 "좋은 코드" 관행의 일부가 재평가되었습니다:

의존성과 추상화 선택: 우리는 저장소 내에서 완전히 내재화되고 추론될 수 있는 의존성을 선호합니다. 예를 들어:

• 공개 라이브러리의 불투명한 동작을 우회하는 것이 더 저렴할 수 있습니다. 예: 일반적인 p-limit 스타일의 동시성 제어 패키지를 가져오는 대신, 자체 동시성 맵 헬퍼를 구현했습니다. 이것은:
  • OpenTelemetry 계측과 긴밀하게 통합됨
  • 100% 테스트 커버리지를 가짐
  • 우리 런타임이 기대하는 방식대로 정확히 작동함
  • 에이전트가 완전히 이해할 수 있음

"지루한" 기술의 선호: 공개 라이브러리보다는 우리가 작성한 코드를 선호합니다. 왜냐하면:

• 구성 가능성이 높음 (매직이 적음)
• API 안정성을 우리가 보장
• 훈련 세트에서의 표현이 명확 (일반적인 패턴)

인간 개발자도 함께 이점을 얻음

역설적이게도, 에이전트 가독성을 우선시하면 인간 개발자도 이점 을 얻습니다:

• 더 예측 가능한 코드: 명확한 패턴이 반복됨
• 더 쉬운 유지보수: "마법"이 적고 명시적임
• 더 강한 타입 안정성: "YOLO 스타일"로 데이터를 탐색하는 대신, 경계에서 파싱하고 검증
• 더 나은 테스트: 모든 동작이 테스트 가능하고 명시적

아키텍처 제약과 엄격한 규칙: 자유를 가능하게 하는 제약

코드베이스가 전적으로 에이전트에 의해 생성되면서, 아키텍처 설계의 철학도 근본적으로 바뀌었습니다. 보통 아키텍처 제약은 조직이 수백 명 규모로 성장할 때까지 미루는 종류의 일입니다. 하지만 ** AI 에이전트의 경우 초기 전제 조건**입니다.

엄격한 계층화와 의존성 규칙

우리의 아키텍처는 다음과 같은 불변 규칙 을 기반으로 합니다:

각 비즈니스 도메인(예: 앱 설정, 사용자 관리)은 다음의 고정된 계층 집합 으로 구성됩니다:

1. Types: 데이터 타입 정의
2. Config: 설정 관리
3. Repo: 데이터 접근
4. Service: 비즈니스 로직
5. Runtime: 실행 상태 관리
6. UI: 사용자 인터페이스

핵심 규칙: 코드는 이 계층을 오직 "앞으로"만 의존할 수 있습니다. 즉:

• UI는 Runtime, Service, Repo, Config, Types에 의존할 수 있음
• Service는 Repo, Config, Types에만 의존할 수 있음
• Repo는 Config, Types에만 의존할 수 있음
• Config와 Types는 다른 것에 의존할 수 없음

교차 관심사의 명시적 진입

인증, 커넥터, 원격 측정, 기능 플래그 같은 교차 관심사(cross-cutting concerns)는 단 하나의 명시적 인터페이스인 Providers 를 통해서만 진입합니다. 이는:

• 의존성이 명확함
• 테스트가 쉬움
• 에이전트가 제약을 이해하고 추론하기 쉬움

기계적 강제

이 규칙들은 단순한 "가이드라인"이 아니라, 자동화된 도구로 강제 됩니다:

사용자 지정 린터: 다음을 정적으로 검사합니다:

• 구조화된 로깅 사용
• 명명 규칙 준수 (Types, Config 등의 구분)
• 파일 크기 제한 (너무 큰 파일 방지)
• 계층 간 의존성 위반 감지

중요: 린터 오류 메시지에는 ** 에이전트가 이를 이해하고 수정할 수 있도록 명확한 지시**가 포함됩니다. 예:

❌ Error: Service should not depend on UI layer
💡 Fix: Move the authorization check to the Repo layer

구조 테스트: 의존성 그래프를 자동으로 분석하여, 금지된 의존성이 도입되지 않았는지 확인합니다.

제약이 역설적으로 속도를 증가시킴

이것이 핵심 통찰입니다: 명확한 제약 조건은 속도를 감소시키지 않고, 오히려 증폭시킵니다.

왜냐하면:

1. 일관성: 모든 곳에 같은 패턴이 반복되므로, 에이전트가 패턴을 빠르게 학습하고 확대할 수 있음
2. 자동 강제: 제약이 코드화되면, 수동 리뷰가 필요 없음
3. 버그 방지: 부패와 아키텍처적 드리프트가 자동으로 방지됨
4. 새로운 기능: 새로운 기능을 추가할 때도 같은 계층 구조를 따르면 되므로, 학습 곡선이 없음

제약과 자유의 균형

동시에 우리는 제약이 중요한 곳과 중요하지 않은 곳을 명확히 합니다. 이는 ** 대규모 엔지니어링 조직을 이끄는 것과 유사**합니다:

• 중앙에서 강제하는 것: 경계, 계층 간 의존성, 데이터 검증
• 로컬에서 허용하는 것: 구현 세부사항, 언어 스타일, 알고리즘 선택

결과 코드가 항상 인간의 "좋은 스타일"과 일치하지는 않을 수 있습니다. 하지만 출력이 다음을 만족한다면, 우리는 기준을 만족했습니다:

• ✅ 정확함
• ✅ 유지보수 가능함
• ✅ 향후 에이전트 실행에 읽기 쉬움

인간의 피드백 지속적 학습

우리는 시스템이 일관되게 개선되도록 보장합니다:

• 검토 댓글: 에이전트가 하지 말아야 할 것들이 명시됨
• 리팩토링 PR: 개선해야 할 패턴들이 자동으로 수정됨
• 사용자 피드백: 버그나 문제가 문서로 캡처됨
• 도구 강화: 문서가 부족하면, 그 규칙을 린터로 승격시킴

이는 피드백 → 문서 → 자동화 → 강제 의 선순환을 만듭니다.

처리량의 급증: 전통적인 병합 철학의 재평가

Codex의 처리량이 기하급수적으로 증가하면서, 우리는 전통적인 소프트웨어 엔지니어링 규범 중 많은 것이 역효과를 내기 시작 했음을 깨달았습니다.

기존 규범의 문제점

전통적인 "Best Practices"는 일반적으로 다음을 권장합니다:

• 완벽한 병합 게이트: 모든 테스트가 통과할 때까지 대기
• 엄격한 검토 프로세스: 모든 PR이 인간 리뷰 필수
• 테스트 플래그 제로 허용: 불안정한 테스트는 즉시 수정
• 보수적인 배포: 변경 사항은 매우 신중하게 병합

이 규범들은 처리량이 낮은 환경(1명의 개발자, 주당 5~10개의 PR) 에서 개발되었습니다. 하지만 우리의 상황은 근본적으로 다릅니다.

새로운 역학: 처리량이 높을 때

우리의 현실:

• 일일 처리량: 엔지니어 1명당 3.5개 PR (약 850개/달)
• 에이전트 속도: 인간 검토 속도의 100배 이상
• 고정된 제약 조건: 인간의 시간과 주의력

이 상황에서 전통적인 규범은 "빠르게 움직이되, 과도하게 신중하지 말 것" 이라는 새로운 철학으로 재평가되어야 합니다:

최소한의 블로킹 병합 게이트

우리의 저장소는 최소한의 블로킹 조건 으로 운영됩니다:

1. 자동 테스트는 통과해야 함 (당연)
2. 아키텍처 린트를 통과해야 함 (위에서 설명한 강제 규칙)
3. 마지막 에이전트 검토자가 만족해야 함 (자동화된 검토)

그 이상의 것은 선택사항:

• 테스트가 "불안정한(flaky)" 상태? → 이후 실행에서 수정
• 일부 엣지 케이스가 놓였다? → 다음 PR에서 처리
• 완벽하지 않은가? → Good is better than perfect when throughput is king

이것이 품질을 해치지 않는 이유

직관적으로 이는 "무책임하다"고 들릴 수 있습니다. 하지만 실제로는 다음 이유로 품질을 유지하거나 향상 시킵니다:

1. 자동 수정: Codex는 불안정한 테스트를 발견하면 즉시 이를 추적하고 수정하는 PR을 자동으로 엽니다. 인간의 개입 없이.

2. 지속적인 개선: 한 번에 완벽하게 하려는 대신, 매일 작은 개선들이 누적됩니다.

3. 빠른 피드백: 사용자가 문제를 발견하면, Codex가 동일한 날에 수정 사항을 배포할 수 있습니다.

4. 규모의 경제: 100개의 작은 개선이 1개의 대형 완벽한 개선보다 낫습니다. (롤백, 분석, 재배포의 리스크 감소)

경제학적 관점

이는 경제학적 의사결정 입니다:

환경	수정 비용	대기 비용	최적 전략
인간 개발자	낮음	높음	신중하게 → 수정 비용 최소화
에이전트 + 인간 리뷰	낮음	매우 높음	빠르게 → 리뷰 지연 최소화

우리는 수정 비용이 대기 비용보다 훨씬 낮은 환경에 있습니다.

"에이전트 생성"의 실제 의미: 코드를 넘어선 완전한 자동화

코드베이스가 "Codex 에이전트에 의해 생성되었다"고 말할 때, 이는 단순히 애플리케이션 로직을 의미하지 않습니다. 코드베이스의 모든 것 입니다:

에이전트가 생성하는 것

✅ 제품 코드 및 테스트

• 비즈니스 로직
• 단위 테스트, 통합 테스트, E2E 테스트

✅ 인프라 및 배포

• CI/CD 파이프라인 구성
• 릴리스 자동화 스크립트
• 클라우드 리소스 정의

✅ 개발자 도구

• 내부 CLI 도구
• 로컬 개발 환경 설정
• 디버깅 유틸리티

✅ 문서 및 설계

• 설계 문서
• API 문서
• 사용자 가이드

✅ 평가 및 모니터링

• 성능 벤치마크 도구
• 모니터링 대시보드 정의
• 알림 규칙

✅ 코드 리뷰 및 검증

• PR에 대한 검토 댓글
• 오류 지적 및 개선 제안
• 이전 피드백에 대한 응답

✅ 리포지토리 자체 관리

• 저장소 구조 정리
• 오래된 코드 제거
• 문서 유지보수

✅ 프로덕션 운영

• 프로덕션 대시보드 정의 파일
• 모니터링 알림 규칙
• 재해 복구 프로세스

인간의 역할: 진화된 형태의 가치 제공

이 모든 것이 자동화되었지만, 인간은 프로세스에서 제거되지 않았습니다. 오히려 ** 더 전략적인 수준**으로 활동합니다:

1. 의도 명시: "우리는 로그인 시간을 2초 이내로 유지하고 싶습니다"
2. 우선순위 지정: "이 버그가 저 기능보다 중요합니다"
3. 사용자 피드백 번역: "사용자들이 이 기능을 찾기 어려워합니다"
4. 결과 검증: "이 수정이 실제로 문제를 해결했나요?"
5. 에스컬레이션 판단: "이건 사람의 판단이 필요합니다"

표준 개발 도구의 직접 사용

중요한 점은, Codex가 특별한 API나 커스텀 인터페이스를 통하지 않고, ** 표준 개발 도구를 직접 사용**한다는 것입니다:

• git: 버전 관리
• gh: GitHub CLI로 PR 관리
• npm/yarn: 패키지 관리
• 로컬 스크립트: 저장소 자체에 정의된 스킬
• 표준 IDE API: 코드 분석 및 수정

이는 인간 개발자가 코드베이스에서 사용하는 것과 정확히 같은 도구 입니다. 따라서 에이전트와 인간이 원활하게 협력할 수 있습니다.

자율성의 새로운 수준: 풀 사이클 개발

개발 루프의 더 많은 부분이 시스템에 직접 인코딩 되면서(테스트, 검증, 검토, 피드백 처리, 자동 수정), 우리의 저장소는 최근 중요한 임계점을 넘었습니다:

Codex가 새로운 기능을 처음부터 끝까지 완전히 독립적으로 주도할 수 있는 능력

자동화된 풀 사이클의 예

단일 프롬프트가 주어지면, 에이전트는 이제 다음을 자동으로 수행합니다:

1. 현재 상태 검증

   • 코드베이스의 최신 버전 확인
   • 관련 설정 및 의존성 검토

2. 문제 이해

   • 보고된 버그 재현
   • 오류 로그 분석

3. 영상 증거 수집

   • 문제를 보여주는 스크린샷 또는 비디오 녹화
   • 실패 메트릭 기록

4. 수정 구현

   • 코드 작성
   • 테스트 작성
   • 문서 업데이트

5. 검증

   • 애플리케이션 구동
   • 수정 사항 작동 확인
   • 성능 메트릭 확인

6. 증거 문서화

   • 수정 후 스크린샷/비디오 녹화
   • 개선된 메트릭 보고

7. PR 제출 및 반복

   • Pull Request 자동 생성
   • 에이전트 검토자들의 피드백 기다림
   • 제안된 변경사항에 응답
   • 필요에 따라 코드 수정

8. 문제 해결

   • 빌드 실패 감지
   • 테스트 실패 분석
   • 자동으로 수정 또는 원인 보고

9. 판단 필요 시 에스컬레이션

   • "이 요구사항을 명확히 해주세요"
   • "이것은 디자인 결정이 필요합니다"

10. 자동 병합

    • 모든 조건이 만족되면 PR 자동 병합

이 능력이 맥락과 도구에 의존하는 이유

중요한 전제: 이러한 능력은 특정 저장소의 구조와 도구에 매우 의존합니다.

유사한 투자(문서화, 자동화된 검증, 명확한 아키텍처, 도구 통합) 없이는 일반화될 수 없습니다. 적어도 현재는.

우리가 수행한 엔지니어링 작업:

• ✅ 구조화된 문서 시스템
• ✅ 자동화된 린터와 검증
• ✅ 에이전트 친화적 아키텍처
• ✅ 관측성 도구 통합
• ✅ 자동 수정 메커니즘

이 모든 것이 있어야만 에이전트가 이러한 수준의 자율성을 달성할 수 있습니다.

엔트로피와 가비지 컬렉션: 코드 부패의 자동 방지

완전한 에이전트 자율성은 새로운 문제를 야기합니다: 코드 엔트로피(무질서)의 증가.

Codex는 리포지토리에 이미 존재하는 패턴을 복제합니다. 심지어 불균일하거나 최적화되지 않은 패턴도. 시간이 지남에 따라 이는 필연적으로 ** 코드 스타일의 편차(drift)**를 초래합니다.

초기 접근: 수동 정리 (확장 불가능)

처음에는 우리 팀이 매주 금요일(주간 시간의 20%)을 "AI 찌꺼기" 정리 에 보냈습니다.

예상하는 대로, 이는 확장 불가능했습니다:

• 코드베이스가 성장할수록 엔트로피도 증가
• 점점 더 많은 수동 정리가 필요
• 팀의 시간이 낭비됨

해결책: "황금 원칙"과 자동화된 가비지 컬렉션

우리는 "황금 원칙(Golden Rules)" 이라고 부르는 것을 리포지토리에 직접 인코딩했습니다:

원칙 1: 불변성 중앙화

• 직접 작성한 헬퍼 대신 공유 유틸리티 패키지 선호
• 중복을 방지하고 일관성 유지

원칙 2: 경계 검증

• 데이터 형태를 경계에서 직접 파싱
• "YOLO 스타일"로 타입을 가정하지 않음
• 유형화된 SDK에 의존

원칙 3: 로깅 표준화

• 구조화된 로깅만 사용
• 자유형 로그 금지

원칙 4: 명명 규칙

• 같은 관심사는 같은 이름 규칙 사용
• Types, Config, Repo, Service 계층의 명확한 구분

자동화된 정리 프로세스

정기적으로(주 1회), 우리는 백그라운드 Codex 작업을 수행 합니다:

1. 편차 스캔: 황금 원칙을 위반하는 코드 찾기
2. 품질 등급 업데이트: 어느 부분이 정리가 필요한지 기록
3. 자동 PR 생성: 리팩토링을 위한 PR 자동 생성

중요: 이러한 PR 대부분은 ** 1분 이내에 검토되고 자동으로 병합**될 수 있습니다. 왜냐하면:

• 변경 내용이 명확하고 기계적임
• 테스트가 이미 통과함
• 위험이 매우 낮음

가비지 컬렉션의 경제학

이는 가비지 컬렉션 처럼 작동합니다:

기술 부채 = 고금리 대출

vs.

나쁜 선택:

• 부채가 쌓일 때까지 기다렸다가
• 한 번의 거대한, 고통스러운 "리팩토링" 프로젝트 진행
• 몇 달을 투자

좋은 선택:

• 매일 작은 단위로 부채 상환
• 자동화된 도구가 처리
• 인간은 검토만 함

결과

이 접근의 결과:

• ✅ 나쁜 패턴이 코드베이스에 며칠 또는 몇 주 동안 퍼지지 않음
• ✅ 매일 일관성 개선
• ✅ 인간의 개입 최소화
• ✅ 기술 부채가 적립되지 않음

우리가 여전히 배우고 있는 것: 장기적 질문들

지금까지 우리의 전략은 OpenAI의 내부 출시와 도입 에 이르기까지 성공적으로 작동했습니다. 실제 사용자를 위한 실제 제품을 구축하는 것은 우리의 투자를 현실에 기반을 두고, 장기적인 유지보수성으로 이끌었습니다.

그러나 여전히 많은 미지의 영역이 있습니다:

미지의 영역들

아키텍처 일관성의 장기적 진화

• 완전히 에이전트가 생성한 시스템에서 아키텍처의 일관성이 수년에 걸쳐 어떻게 발전할까?
• 처음에는 일관되지만, 시간이 지남에 따라 부패할까?
• 자동 가비지 컬렉션이 영원히 충분할까?

인간 판단의 증폭

• 인간의 판단이 가장 큰 영향력을 발휘하는 정확한 지점 은 어디인가?
• 그 판단을 어떻게 인코딩하여 효과가 증폭 되도록 할까?
• 판단 오류의 비용은 무엇인가?

모델 개선에 따른 시스템 진화

• 모델이 시간이 지남에 따라 계속 더 유능해짐에 따라, 이 시스템이 어떻게 변할까?
• 현재 우리가 자동화한 것들이 더 이상 필요 없어질까?
• 새로운 자동화 기회가 나타날까?

스케일의 문제

• 100만 줄에서 1,000만 줄로 성장할 때 어떻게 될까?
• 컨텍스트 윈도우가 제한될 때는?
• 에이전트가 리포지토리를 "이해"하는 데 걸리는 시간은?

분명해진 것들

모든 불확실성에도 불구하고, 명확해진 핵심 진실 이 있습니다:

소프트웨어 구축에는 여전히 규율이 필요하다. 하지만 그 규율은 코드 자체보다는 스캐폴딩에서 나온다.

구체적으로:

• ✅ 도구 의 중요성 증가
• ✅ 추상화 의 중요성 증가
• ✅ 피드백 루프 의 중요성 증가
• ✅ 순수 "코딩 능력"의 중요성 감소

현재의 가장 어려운 과제

우리의 가장 어려운 과제는 더 이상 "코드를 더 빠르게 생성하는 것"이 아닙니다.

대신, 우리는 다음을 설계하는 데 집중합니다:

1. 환경: 에이전트가 작업할 수 있는 기반
2. 피드백 루프: 에이전트가 학습할 수 있는 메커니즘
3. 제어 시스템: 에이전트가 우리의 목표(복잡하고 신뢰할 수 있는 소프트웨어를 대규모로 구축하고 유지보수)를 향해 정렬되도록 하는 메커니즘

이는 소프트웨어 엔지니어링을 제조, 컨트롤 시스템, 조직 설계 로 변환합니다.

결론: 소프트웨어 엔지니어링의 미래

Codex와 같은 에이전트가 소프트웨어 수명 주기의 더 많은 부분을 담당하게 되면서, 위의 질문들은 더욱 중요해질 것 입니다.

우리가 이 여정을 통해 배운 가장 중요한 교훈은 다음과 같습니다:

핵심 인사이트

1. AI 에이전트는 코드를 빠르게 작성할 수 있다 - 이건 이미 증명됨
2. 하지만 속도만으로는 부족하다 - 품질, 일관성, 유지보수성이 필수
3. 이를 달성하려면 의도적인 설계가 필요하다 - 우연에 의존할 수 없음
4. 인간의 역할은 축소가 아니라 진화한다 - 더 전략적이고 영향력 있어짐
5. 규칙과 제약이 자유를 가능하게 한다 - 특히 AI 시스템에서

향후 투자의 방향

이 경험을 통해 우리는 다음 분야에 집중해야 한다는 것을 알게 되었습니다:

• 아키텍처와 설계: 명확한 의존성 규칙과 계층화
• 문서와 기록: 구조화되고 유지보수되는 지식 기반
• 자동화 도구: 린터, 검증, 자동 수정
• 피드백 시스템: 개선 사항을 감지하고 구현하는 메커니즘
• 관측성: 에이전트가 결과를 검증할 수 있도록

이러한 투자는 인간 개발자에게도 도움이 됩니다. 코드 품질 향상, 일관성 증진, 버그 감소로 이어지기 때문입니다.

마지막 메시지

우리는 몇 가지 초기 교훈을 공유했습니다. 우리의

---

Original source: Harness engineering: leveraging Codex in an agent-first world

powered by osmu.app