Molayo

© 2026 Molayo

Zenn헤드라인2026. 06. 02. 22:57

Codex와 GitHub를 이용한 인간 승인 기반의 반자율 개선 루프 실험

요약

Codex와 GitHub를 활용하여 인간의 승인을 거치는 반자율적 AI 개발 루프의 실효성을 검증한 실험 보고서입니다. 작은 규모의 Next.js 앱을 대상으로 AI가 제안, 구현, PR 생성까지 수행하는 워크플로우를 구축하고 그 과정에서의 한계와 성과를 분석했습니다.

핵심 포인트

  • Codex와 무료 티어 도구만으로 반자율 개발 루프 구현 가능
  • AGENTS.md, WORKFLOW.md 등 명확한 가이드 문서의 중요성
  • 인간의 승인 경계를 규칙만으로 완벽히 자동화하기는 어려움
  • CI/CD 및 테스트 자동화를 통한 AI 구현 결과 검증 필수

서론

AI가 스스로 재미있을 법한 앱을 구상하고, 인간이 채택안을 선택하면, AI가 구현한 뒤 리뷰를 거쳐 다시 개선안을 내놓는 과정.

이러한 AI 주도 개발 (AI-driven development)을 개인 개발 범위 내에서 어디까지 현실적으로 시도할 수 있는지 검증했습니다.

이번 검증의 전제 조건은 Codex에는 과금하였으나, 그 외에는 가능한 한 무료 티어 (Free tier)를 사용하는 것입니다. 처음부터 완전 자동화를 목표로 하지 않고, 다음과 같은 반자율 루프 (Semi-autonomous loop)를 안정적으로 돌릴 수 있는지 확인했습니다.

Codex가 개선 후보를 제안
↓
인간이 1건을 승인
...

결론적으로, 작은 기능이라면 이 루프를 추가 유료 서비스 없이 여러 번 재현할 수 있었습니다.

반면, 반복하는 과정에서 규칙을 작성하는 것만으로는 의도한 승인 경계 (Approval boundary)를 충분히 자동화할 수 없다는 과제도 드러났습니다.

이 기사에서는 실제로 구축한 메커니즘, 확인된 사항, 남아있는 과제, 그리고 다음에 나아가고자 하는 구성에 대해 정리합니다.

검증용 앱

검증을 위해 Next.js + TypeScript 기반의 작은 Web 앱을 만들었습니다.

목록, 상세 화면, 상태 표시를 가진 작은 구성입니다. 여기서 중요했던 점은 화면 내의 상태와 인간이 구현을 승인했는지 여부를 분리하여 다루는 것이었습니다.

초기 구현에서는 이 경계가 모호해지는 문제가 있었습니다. 그래서 표시 문구, 데이터 구조, 테스트, 운영 문서를 수정했습니다.

기능을 작게 유지함으로써 AI 주도 개발의 운영 그 자체에 집중할 수 있었습니다.

처음에 정비한 리포지토리 (Repository)

Codex에게 구현을 맡기기 전에, 리포지토리 내에 다음과 같은 문서들을 배치했습니다.

AGENTS.md
WORKFLOW.md
EVALS.md
...

AGENTS.md

Codex가 따라야 할 규칙입니다.

  • 현재 페이즈 (Phase)
  • 사용하는 기술
  • 준수해야 할 스코프 (Scope)
  • 필수 검증 커맨드 (Command)
  • 인간의 승인이 필요한 경계
  • PR 완료 시 보고할 내용

특히 중요했던 점은, 인간의 승인 없이 외부 API, 인증, 데이터베이스, 유료 인프라를 추가하지 않도록 명시한 부분입니다.

WORKFLOW.md

AI가 제안하고, 인간이 승인하며, Codex가 구현하고, 인간이 merge를 판단하는 흐름을 기록했습니다.

실험이 진행될 때마다 어느 페이즈에서 무엇을 검증했는지도 추가했습니다.

EVALS.md

주관적인 느낌만으로 "AI가 대단했다"라고 판단하지 않기 위해 평가 항목을 정의했습니다.

  • 인간이 코드를 직접 편집했는가
  • lint, typecheck, test, build가 통과했는가
  • GitHub Actions가 성공했는가
  • 리뷰 지적 사항이 있었는가
  • 승인부터 리뷰 가능 상태가 되기까지의 시간
  • 추가 비용이 발생했는가

확인되지 않은 항목은 추측으로 채우지 않고 미확인 또는 미측정으로 남겨두었습니다.

실제로 돌려본 개선 루프

초기 앱을 만든 후, 다음과 같은 개선을 진행했습니다.

페이즈내용
Phase 1검증용 앱의 초기 구현
...

Phase 7, Phase 8, Phase 11에서는 Codex가 다음 작업을 수행했습니다.

  • 개선 후보를 제안한다
  • 인간이 선택한 1건만 구현 대상으로 삼는다
  • feature 브랜치를 만든다
  • 코드와 테스트를 변경한다
  • lint, typecheck, test, build를 실행한다
  • commit 한다
  • feature 브랜치를 push 한다
  • gh CLI로 PR을 생성한다
  • GitHub Actions의 완료를 확인한다

merge는 인간이 판단했습니다.

실제로 진행된 흐름을 도식화하면 다음과 같습니다.

CI와 로컬 검증

동작에 영향을 주는 코드를 변경했을 경우, PR 전에 다음을 실행했습니다.

npm run lint
npm run typecheck
npm test
...

GitHub Actions에서도 동일한 관점으로 검증했습니다.

Phase 11에서는 테스트가 2개 파일, 13개까지 늘어났습니다. GitHub Actions의 Validate는 39초 만에 성공했습니다.

다만, 초기 페이즈에서는 GitHub Actions의 결과나 리뷰 시간을 충분히 기록하지 못했습니다. 나중에 평가하려고 하면 데이터가 빠져 있기 때문에, 기록 항목과 타이밍을 중간에 재검토했습니다.

Codex의 권한을 조정함

도중에 문서 업데이트가 PR을 거치지 않고 리포지토리에 반영되는 일이 발생했습니다.

그래서 Codex의 default.rules를 정리했습니다.

방침은 다음과 같습니다.

작업처리 방식
git status, git diff, git log자동 허가
lint, typecheck, test, build자동 허가
로컬 브랜치 생성자동 허가
git add, git commit자동 허가
feature 브랜치 push매번 확인
main, master로의 직접 push금지
PR 생성매번 확인
merge매번 확인

완전 자동화보다는 외부로 영향을 미치는 작업만을 인간의 확인 단계로 남겨두는 것이 다루기 쉽다고 느꼈습니다.

default.rules는 개선 루프(improvement loop) 그 자체가 아니라, Codex가 명령어를 실행할 때의 판정 규칙입니다.

남아있는 과제

default.rules를 정비하더라도, 의도한 승인 경계(approval boundary)를 완전히 표현하지는 못하고 있습니다.

예를 들어, 로컬 작업은 자동 허가하고, feature 브랜치로의 push와 PR 생성은 확인을 거치며, main으로의 직접 push는 금지하고 싶습니다.

한편, 실제로는 명령어의 인자(argument)나 실행 경로에 따라 판정이 달라질 수 있습니다. 안전성을 유지하면서 확인 횟수를 줄이려면, 실행 결과를 보면서 규칙(rules)을 지속적으로 조정해야 합니다.

현 시점에서 확인된 사항

추가적인 유료 서비스 없이, 다음과 같은 반자율 루프(semi-autonomous loop)를 재현할 수 있었습니다.

개선 제안
↓
인간 승인
...

반면, 아직 확인하지 못한 부분도 있습니다.

  • Deep Research를 사용한 신규 앱 탐색
  • GitHub Issue를 사용한 채택 판단
  • 채택된 앱을 별도 리포지토리에서 육성하는 운영
  • 여러 리포지토리에 공통 규칙을 반영하는 방법
  • 정기 실행
  • 리뷰 코멘트의 정기적 탐지 및 자동 수정
  • 인간이 일반적인 방식으로 구현했을 때와의 속도 비교

완전 자동화를 달성한 것은 아닙니다.

하지만 인간이 승인 경계를 가지고 Codex가 실무 작업을 진행하는 형태라면, 개인 개발에서도 현실적으로 운영할 수 있다는 감각을 얻었습니다.

다음은 리포지토리를 분리한다

앞으로는 idea-orbit을 개별 앱이 아닌 사령탑(command center)으로 사용합니다.

idea-orbit
# 신규 앱 탐색, 채택 판단, 공통 규칙 관리
idea-orbit-app-template
...

Issue의 위치도 분리합니다.

Issue 유형생성 위치
새로운 앱 안(案)idea-orbit
...

여러 리포지토리에서 어려운 점은 Issue나 PR이 나뉘는 것이 아닙니다.

주의해야 할 점은 공통의 개선 루프를 각 앱에서 개별적으로 수정하기 시작하는 것입니다. 우선 템플릿을 중앙에서 관리하고, 필요해지는 단계에서 동기화 PR(sync PR)이나 재사용 가능한 워크플로우(reusable workflow)를 검토합니다.

앞으로는 신규 앱을 탐색하는 루프와, 채택된 앱을 개선하는 루프를 분리합니다.

아이디어 탐색도 단계적으로 개선한다

신규 앱 안(案)의 탐색 방법은 다음 순서로 발전시킵니다.

  • 탐색용 배경 메모로부터 제안
  • 인간이 전달한 기사나 조사 자료를 읽음
  • Deep Research로 지역 과제, 취미 영역, 기술 트렌드, 기존 서비스를 조사
  • 주간 또는 월간 단위로 후보를 Issue화

처음부터 완전 자동화를 하지는 않습니다.

후보의 질과 인간이 정말로 선택하고 싶어 하는지를 확인한 후에, 정기 실행을 고려합니다.

요약

이번 검증을 통해, Codex를 사용한 AI 주도 개발(AI-driven development)은 완전 자동화보다는 "인간 승인이 포함된 반자율 루프"부터 시작하는 것이 다루기 쉽다고 느꼈습니다.

중요했던 것은 모델에게 긴 지시를 한 번에 전달하는 것보다, 리포지토리 내에 규칙, 평가 기준, CI, 승인 경계를 두는 것이었습니다.

다음으로는 default.rules의 승인 경계가 의도한 대로 더 잘 작동하도록 정비 작업을 진행하겠습니다. 그 후에 Deep Research를 포함한 아이디어 탐색과, 채택된 앱을 별도 리포지토리에서 육성하는 운영을 시도하겠습니다.

Discussion

AI 자동 생성 콘텐츠

본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0