Ralph Loop가 바꾼 개발 패러다임: 프롬프트는 끝났다 AI가 끝까지 만든다

 

Codex CLI 최신 버전에 /goal 실제 추가됨이 확인됩니다.

• /goal = Codex 내부에 Ralph loop를 내장한 기능
• 한 번 목표 주면 완료될 때까지 자동 반복
• 종료 조건
  • 목표 달성
  • 또는 token budget 초과

300x250

→ Codex CLI 0.128.0부터 /goal 도입
→ “goal을 설정하면 완료될 때까지 loop를 계속 수행”

Ralph loop = 이제 “Codex 내부 기능”이 됨

기존 (과거 구조)

• 사람이 계속 지시
• step-by-step prompt
• 상태 유지 어려움

현재 (goal 기반)

Codex 내부에서 자동으로 이 구조 수행

[Goal]
  ↓
[Plan]
  ↓
[Implement]
  ↓
[Test / Execute]
  ↓
[Evaluate]
  ↓
[Fix / Improve]
  ↺ 반복

핵심 변화
👉 “prompt 기반 실행” → “목표 기반 수렴 시스템”

Ralph loop vs 기존 Codex loop (중요 차이)

구분	기존 Codex	Ralph loop (/goal)
실행 방식	단일 turn	지속 실행
반복	수동	자동
종료	사용자 판단	목표 조건
상태 관리	약함	지속 유지
실패 처리	재지시 필요	자체 수정

👉 Codex가 “도구” → “작업 수행자”로 바뀐 지점

내부 동작 (실제 구조 해부)

이건 영상 + 구조 분석 기준으로 정리한 실제 작동 방식입니다.

Goal 정의

/goal "로그인 기능 만들고 테스트 95% 이상"

내부적으로 변환

Goal:
- 기능 구현
- 테스트 통과율 >= 95%
Constraints:
- 기존 코드 유지
- lint 통과
Done when:
- 테스트 성공률 >= 95%

👉 Best Practice에서도 “Done when” 명시가 핵심 (OpenAI Developers)

자동 계획 생성

Codex 내부에서

• 파일 분석
• dependency 확인
• 작업 순서 생성

예

1. auth module 생성
2. DB schema 추가
3. API 작성
4. 테스트 코드 작성

실행 단계 (핵심)

Codex가 직접 수행

• 파일 수정
• shell command 실행
• git diff 관리

CLI는 실제로

• 코드 수정
• 명령 실행
• repo 분석 가능 (ComputingForGeeks)

평가 루프 (Ralph 핵심)

여기가 “진짜 변화”입니다.

Codex가 내부적으로 판단

테스트 실패 → 왜 실패?
→ 코드 수정
→ 다시 실행

👉 과거

• 같은 시도 반복

👉 현재

• 실패 원인 추론 후 전략 변경

종료 조건

상태 머신 형태

• pursuing → 진행 중
• achieved → 성공
• unmet → 실패
• budget-limited → 비용 초과

👉 이게 사실상 작업 큐 + 상태 머신 구조

실제 사용 흐름 (실무 기준)

기본 사용

codex

/goal "Flask 로그인 시스템 만들고 pytest 90% 이상 통과"

👉 이후

• Codex가 자동으로 계속 실행

제어 명령 (중요)

/goal pause
/goal resume
/goal clear
/status

자동 실행 모드 (완전 자율)

codex exec --full-auto "Fix failing tests"

👉 특징

• 승인 없이 계속 실행
• 완전 자동 에이전트

보안 관점 (실무 핵심)

당신 역할 기준에서 핵심입니다.

위험 요소

① 무한 루프 비용 폭발

• 잘못된 goal → 수천 iteration
• API 비용 폭증

② 잘못된 수정 반복

• 잘못된 가정 고집
• 코드 품질 저하

③ 시스템 권한 문제

• danger-full-access 사용 시
  → OS 전체 접근 가능 (ComputingForGeeks)

반드시 필요한 통제

Budget 제한

--config max_tokens
--timeout

Sandbox 제한

codex -s workspace-write

모드	설명
read-only	안전
workspace-write	일반
danger-full-access	위험

승인 정책

-a on-request

→ 중요한 명령만 승인

Goal 설계 가이드 (중요)

❌ 나쁜 예

"로그인 기능 만들어줘"

✅ 좋은 예

"Flask 기반 로그인 API 구현,
bcrypt 사용,
pytest 90% 이상 통과,
lint 에러 0"

실무 활용 시나리오 (보안/AI 기준)

취약점 자동 수정 루프

/goal "SQL Injection 취약점 제거 + 테스트 통과"

Codex

• 코드 수정
• 테스트 생성
• 재검증 반복

침투 테스트 자동화

• fuzzing 반복 실행
• 실패 케이스 분석
• payload 자동 개선

Kubernetes 튜닝

/goal "CPU throttling 제거 + latency < 100ms"

→ 반복 실험 자동화

CI/CD 자동 리팩토링

• 테스트 실패 → 자동 수정
• 성능 기준 만족까지 반복

현실적인 한계

Goal Drift

• 목표를 잘못 이해하면 계속 이상한 방향

잘못된 수렴

• “틀린 해답으로 수렴”

비용 폭탄

• 장시간 실행 (11~20시간 가능)

디버깅 어려움

• 내부 reasoning 투명하지 않음

핵심 인사이트

이건 단순 기능 추가가 아닙니다.

변화의 본질

👉 이전

Human → AI (단발성)

👉 지금

Human → Goal → AI Loop → Result

한 줄 핵심

“코드를 생성하는 AI” → “작업을 완료하는 AI”로 전환

✔ /goal = Codex에 Ralph loop 공식 내장
✔ 목표 기반 자동 반복 실행
✔ 테스트/평가 기반 “수렴형 개선”
✔ CLI가 사실상 “자율 개발 에이전트”로 진화

 

👉 Claude Code = 사고 중심 (Senior Engineer)
👉 Codex = 실행 중심 (Autonomous Worker)
👉 Devin = 시스템 자체 (Full-stack AI Developer)

전체 구조 비교

Claude Code 구조

Human ↔ Claude
        ↓
   Agent Loop (while-loop)
        ↓
  Tool 실행 (shell / edit / MCP)
        ↓
  다시 reasoning → 반복

✔ 특징

• 단일 루프 (while-loop)
• 인간과 협업 중심
• reasoning 품질 최우선

실제 구조
→ Claude Code는 “model → tool → 반복” 구조의 간단한 루프 기반 (arXiv)

Codex 구조 (Ralph loop 포함)

Goal 입력
   ↓
Planner
   ↓
Executor (코드 수정 + 실행)
   ↓
Evaluator (테스트/결과 분석)
   ↓
Refiner (수정)
   ↺ 반복 (Ralph loop)

✔ 특징

• 상태 머신 기반
• 목표 달성까지 자동 반복
• CLI + sandbox 중심

핵심
→ “agent loop를 orchestration하는 구조” (Beam)

Devin 구조 (완전 다름)

User Goal
   ↓
Task Decomposition Engine
   ↓
Multi-Agent System
   ↓
Cloud Workspace (IDE + Browser + Shell)
   ↓
Long-running Execution (hours~days)
   ↓
PR 생성 / 결과 제출

✔ 특징

• 완전 클라우드 기반
• 멀티 에이전트
• 장시간 작업 수행

핵심
→ Devin은 CLI 도구가 아니라 “개발 환경 자체” (Artificial Analysis)

구조 철학 차이

Claude Code → “사람 중심”

• 인간이 의사결정
• AI는 reasoning 보조
• 코드 품질 / 구조 설계 강함

느낌: “시니어 개발자와 페어 프로그래밍”

Codex → “목표 중심”

• 목표만 주면 끝까지 수행
• Ralph loop로 수렴
• 실행 + 테스트 자동화

느낌: “야근 대신 일하는 엔지니어”

Devin → “시스템 중심”

• 인간 개입 최소화
• 전체 프로젝트 수행
• 작업을 “위임”하는 구조

느낌: “외주 개발자 한 명”

에이전트 레벨 비교

레벨	Claude Code	Codex	Devin
Level 1	보조	부분 자율	완전 자율
Level 2	reasoning	실행	전체 수행
Level 3	대화 기반	목표 기반	프로젝트 기반

실제 성능/특성 비교

Claude Code

✔ 강점

• 구조 설계 (아키텍처)
• 버그 분석
• 코드 설명

✔ 약점

• 장시간 작업 약함
• 자동 반복 제한

실제 평가
→ “architect 역할에 강함” (Tom's Guide)

Codex

✔ 강점

• 자동 실행 루프
• 테스트 기반 개선
• 빠른 기능 구현

✔ 약점

• 잘못된 방향 고집 가능
• 비용 관리 필요

특징
→ “production-ready 코드 생성에 강함” (Tom's Guide)

Devin

✔ 강점

• end-to-end 개발
• PR 생성
• 장시간 작업

✔ 약점

• 비용 매우 높음
• 제어 어려움
• 실패 시 디버깅 어려움

보안 관점 비교

Claude Code

• 로컬 실행
• 권한 제어 강함
• human-in-the-loop

가장 안전

Codex

• sandbox 기반 실행
• CLI에서 시스템 접근 가능

리스크

• 잘못된 명령 실행
• 무한 loop 비용

Devin

• 클라우드 환경 전체 제어
• 코드 + 인터넷 + 시스템 접근

리스크

• 데이터 유출
• 공급망 공격
• 장시간 autonomous 행동

실무 사용 기준 추천

보안 / 분석 / 설계

👉 Claude Code

• 취약점 분석
• 코드 리뷰
• 정책 설계

자동화 / 반복 작업

👉 Codex

• 취약점 수정 루프
• 테스트 자동화
• CI/CD 개선

프로젝트 위임

👉 Devin

• 서비스 개발
• 프로토타이핑
• 대규모 작업

진짜 중요한 인사이트

이 3개는 경쟁 관계가 아니라

Claude → 생각
Codex → 실행
Devin → 전체 시스템

즉, “AI 개발 스택이 계층화됨”

가장 현실적인 운영 전략 (추천)

실무에서 제일 좋은 방식

Claude Code → 설계
       ↓
Codex → 구현 & 반복 개선
       ↓
Devin → 대규모 작업 자동화

이게 지금 실제 상위 엔지니어들이 쓰는 패턴입니다 (Beam)

한 줄 요약

👉 Claude Code = “생각하는 개발자”
👉 Codex = “일하는 개발자”
👉 Devin = “개발 조직 자체”