하네스 엔지니어링 1

[원문]  https://openai.com/ko-KR/index/harness-engineering/

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

 

배경

Open AI의 한 개발팀이 5개월 동안 Codex를 활용해서 소프트웨어 제품의 내부 베타를 구축하고 출시하는 실험을 진행

실제 수행 과정

빈 git 리포지터리로 시작함

• 5개월, 3명의 엔지니어, 1,500개 Pull Request
• 1인당 하루 평균 3.5개 PRs
• 7명으로 늘어나면서 오히려 처리량이 증가
• 수동 작성한 코드 0

내부 일일 사용자와 외부 알파 테스터가 배정되어 있었음 

내부 일일 사용자 : 회사 내부에서 실제로 그 제품을 매일 실제 업무나 검증에 사용하는 사람들
알파 테스터 : 회사 외부의 사용자들이 초기 버전(Alpha)를 시험 사용하면서 피드백을 주는 사람들

“이미 실제 사용자들이 붙어서 매일 써보고 있는 살아 있는 서비스 상태”

• 애플리케이션 로직, 테스트, CI 구성, 문서화, 관측 가능성, 내부 툴링 등 모든 코드 라인이 Codex에 의해 작성
• 수작업 시간의 1/10로 단축

사람이 조정하고, 에이전트가 수행

• 엔지니어링 속도의 향상을 위해 의도적으로 이 제약을 선택
• 백만 개 코드 라인 작성에 몇 주 소요(획기적인 성능)

소프트웨어 엔지니어링팀의 주된 업무가 코드 작성에서 
AI 에이전트가 안정적인 작업을 수행할 수 있도록 구축하는 것으로 변화"

엔지니어링 팀의 역할

AI 에이전트가 안정적인 작업을 수행할 수 있도록 환경을 구축/개선하는 것

• 환경을 설계
• 의도를 명시
• 피드백 루프를 구축 : Agent가 오동작 또는 구현에 실패할 때 원인을 찾고 개선하는 과정

 

엔지니어의 역할 재정의하기

스캐폴딩(Scaffolding, (건축)작업용 구조물) : 최종 결과물을 만들기 위해 (결과물의) 주변에서 작업을 가능하게 해주는 구조

• 건물을 짓기위해 건물 외부에 설치하는 구조물로 작업자/자재의 이동 및 실제 작업을 하기 위한 환경으로 쓰이는 구조물
• SW 개발에서 스캐폴드는 작업 효율을 높이기 위한 환경, 전략을 의미하며 스캐폴딩은 실제로 만들어진 환경 자체를 의미
• 건물을 짓고 나서는 스캐폴드를 제거하지만, AI 작업에서는 스캐폴딩을 지속적으로 개선하며 작업 효율을 높이기 위한 레버지지로 활용함

레버리지(Leverage, 지렛대) : 적은 노력이나 자원으로 더 큰 결과를 내게 하는 힘

 

엔지니어의 역할

• 큰 목표를 더 작은 빌딩 블록(설계, 코드, 검토, 테스트 등)으로 세분화하고 에이전트가 이러한 블록을 구성하도록 프롬프팅
• 이렇게 구성된 스캐폴딩를 사용하여 더 복잡한 작업을 수행한다.
• 에이전트가 작업에 실패하면, 엔지니어는 그 실패한 작업에 들어가서 질문한다.
  "(스캐폴딩에) 어떤 역량(정책, 정보, 처리 방법 등)이 부족한가? 에이전트가 이를 쉽게 이해하고 수행 할 수 있도록 하려면 어떻게 해야 하는지?"

사람(엔지니어)는 프롬프트를 통해 AI시스템과 상호작용하며, AI시스템은 모든 에이전트 검토자가 만족할 때까지 반복하도록 지시합니다.

(사실상 랄프 위검 루프(Ralph Wiggum Loop)⁠임)

https://ghuntley.com/loop/

everything is a ralph loop

 

한 번의 Codex 실행으로 6시간 이상(종종 사람이 잠자는 동안) 한 가지 작업을 수행하는 경우가 많습니다.

 

리포지터리 지식을 기록 시스템으로 만듦

교훈 : Codex에 1,000페이지의 설명서가 아닌 맵을 제공해야 한다.

 

• 하나의 큰 AGENTS.md는 실패했다.
  • 거대한 지침 파일로 인해 작업, 코드 및 관련 문서가 복잡해져서 에이전트가 제약 조건을 놓치거나, 잘못된 제약 조건에 맞게 작업너무 많은 지침은 지침이 없는 것이 된다. 모든 것이 "중요"하다면 중요한 것은 아무것도 없다.
  • 너무 많은 가이드는 가이드가 없는 것이다. 거대한 가이드는 관리하기 어렵고, 엔지니어들이 관리를 포기하게 되며, 낡은 규칙들의 무덤으로 변해 골칫거리로 변한다.
  • 검증하기 어렵다. 단일블롭(Binary Large Object)은 기계적 검사에 적합하지 않고, 조금씩 틀어지는 경향이 있다.
• 따라서 Agents.md를 백과사전으로 취급하는 대신 목차로 취급한다.
• 리포지터리의 지식 베이스는 기록시스템(형상관리시스템-git)으로 관리되는 구조화된 docs/ 디렉터리에 있다.

AGENTS.md

• AGENTS.md는 "100줄 정도의 짧은 안내판"역할을 한다. 스캐폴딩 구조물의 구조도 역할.
  • 에이전트가 작업할 때, 이 짧은 AGENTS.md 내용이 프롬프트 컨텍스트(문맥)에 기본으로 들어간다.
  • 역할은 설명서 전체가 아니라 지도(map)이다.
  • 즉, "무엇이 어디에 있는지", "어떤 문서를 참고해야 하는지"를 안내한다.
• 상세 규칙과 최신 기준은 각 전문 문서에서 관리한다.

ARCHITECTURE.md

세부 구현 설명서가 아니라, 도메인이 어떻게 나뉘는지, 패키지 계층이 어떻게 쌓이는지를 한눈에 보여주는 상위 지도입니다.
즉, “이 기능은 어느 도메인 소속인지”, “프론트/서비스/인프라가 어떤 경계로 나뉘는지”를 빠르게 파악하게 해주는 문서이다.

AGENTS.md  = 전체 지도
ARCHITECTURE.md = 시스템 구조 설명
docs/
├── design-docs/ = 설계 배경과 원칙
│   ├── index.md
│   ├── core-beliefs.md
│   └── ...
├── exec-plans/  = 실행 계획
│   ├── active/  = 진행중인 계획
│   ├── completed/ = 완료된 계획
│   └── tech-debt-tracker.md  = 알려진 기술 부채 추적
├── generated/
│   └── db-schema.md
├── product-specs/ = 기능 요구사항
│   ├── index.md
│   ├── new-user-onboarding.md
│   └── ...
├── references/  = 외부 도구/참고자료
│   ├── design-system-reference-llms.txt
│   ├── nixpacks-llms.txt
│   ├── uv-llms.txt
│   └── ...
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md = 품질 대시보드
├── RELIABILITY.md
└── SECURITY.md

 

QUALITY_SCORE.md

품질 문서는 각 제품 도메인과 아키텍처 레이어에 등급을 매기며, 시간이 지남에 따라 격차를 추척합니다.

계획 : Agent가 생성한 작업 계획

계획은 일급 아티팩트로 간주됩니다. 아티팩트(가공물 = 산출물)

즉, 설계, 코드, 테스트 자동화 코드, 테스트 문서 뿐 아니라 Agent가 생성한 계획도 산출물로 인식하며, 일급 산출물로 소스 코드와 동급으로 취급한다.

 

전용 린터와 CI

전용 린터(코드 컨벤션 : 형식 구조, 규칙 위반 자동 검사)와 CI 작업이 문서 체계가 최신인지, 서로 잘 연결돼 있는지, 구조가 규칙에 맞는지 자동으로 검사한다.

 

doc-gardening agent  문서의 정원사 역할을 하는 에이전트

실제 코드 동작을 반영하지 않는 오래되거나 더 이상 유효하지 않는 문서를 검토하여 수정용 pull request를 엽니다.

• 잡초 뽑기 : 오래되거나 폐기된 문서 찾아 정리 
• 가치지기 : 중복, 장황한 설명 정리
• 표지판 정비 : 깨진 링크, 잘못된 경로 수정
• 새로 심기 : 빠진 설명이나 인덱스 보강

Agent의 작업 결과는 코스 또는 문서의 변화이며, 이를 사람이 검토하기 쉽게 pull request를 생성하는 것으로 에이전트 작업이 끝나는 것을 알 수 있음

 

 

에이전트의 가독성이 목표

• 에이전트가 실행되는 동안 바로 참고할 수 없는 정보는, 사실상 없는 것이나 마찬가지다.
• Google Docs, 채팅 스레드, 사람들의 머릿속에 있는 지식은 Agent는 접근할 수 없다.
• 리포지토리 내의 버전 관리되는 아티팩트(예: 코드, 마크다운, 스키마, 실행 계획)에만 접근할 수 있다.

 

컨텍스트의 추가 관리

시간이 지나면 점점 더 많은 컨텍스트를 리포지터리에 추가해야 한다.

에이전트가 검색할 수 없다면 판독이 불가능한 것이다.

• 더 많은 컨텍스트를 제공한다는 것은 너무 많은 부담을 주는 것이 아니라 올바른 정보를 정리하고 노출하여 에이전트가 추론할 수 있도록 한다는 의미이다.
• 제품 원칙, 엔지니어링 규칙, 팀 문화(이모지 선호도 포함)에 대해 에이전트에게 정보를 제공하면 더 나은 결과물을 얻을 수 있다.

절충점

• 잘 알려진 기술(Technologies often described as “boring”)은 에이전트가 모델링을 잘 한다. 즉, 구현을 잘한다.
• 공개 라이브러리의 업스트림에 맞춰 작업을 시키는 것보다 에이전트가 기능의 하위 집합을 다시 구현하는 것이 더 저렴했다. 
  => 업스트림은 메서드의 결과 값으로 에이전트가 내부 로직을 유추해서 작업을 하는 것보다 요구사항에 맞는 하위 라이브러리를 직접 구현하는 것이 더 저렴(정확히 동작시키기 쉽고, 유지보수하기 좋은)했다.
  => 이 경우 테스트 커버리지를 100%로 만들기 쉽고, 런타임에 기대하는 방식대로 정확히 동작한다.
• 에이전트가 검사하고 검증하고 직접 수정할 수 있는 형태로 시스템을 더 많이 끌어오면 Codex뿐 아니라 코드베이스에서 작업하는 다른 에이전트(예: Aardvark : 소프트웨어 취약점을 자동으로 찾고, 검증하고, 수정하는 연구용 AI 에이전트)에서도 레버리지를 높일 수 있다.
  => 테스트 자동화 또는 실행 결과 검증(log, Metrics 등)이 가능한 환경에서 레버리지가 터짐

아키텍처 및 취향 강제 적용

• 문서화만으로는 에이전트가 생성한 코드베이스의 완전히 일관되게 유지할 수 없습니다.
• 구현을 세세하게 관리하는 대신 불변 조건을 강제 적용함으로써 기초를 튼튼히 유지하면서 에이전트가 빠르게 출시할 수 있도록 한다.
• 에이전트는 엄격한 경계와 예측 가능한 구조⁠(https://bits.logic.inc/p/ai-is-forcing-us-to-write-good-code)를 갖춘 환경에서 가장 효과적이므로, 우리는 엄격한 아키텍처 모델을 중심으로 애플리케이션을 구축했습니다.
• 이러한 제약은 Codex가 생성한 맞춤형 린터와 구조적 테스트를 통해 기계적으로 적용됩니다.

아래 다이어그램은 다음 규칙을 보여줍니다. 각 비즈니스 도메인 내에서(예: 앱 설정) 코드는 고정된 레이어 집합(Types → Config → Repo → Service → Runtime → UI)을 통해서만 “전달”할 수 있습니다. 교차되는 문제(인증, 커넥터, 텔레메트, 기능 플래그)는 하나의 명시적인 인터페이스인 Providers를 통해 유입됩니다. 그 외의 모든 것은 허용되지 않으며 기계적으로 강제 적용됩니다.

 

 

• 예)맞춤형 린트를 사용하여 구조화된 로깅, 스키마 및 유형의 명명 규칙, 파일 크기 제한, 플랫폼별 안정성 요구 사항을 정적으로 적용
• 사람 중심의 워크플로에서는 이러한 규칙들이 지나치게 세세하거나 제한적으로 느껴질 수 있지만,
• 에이전트를 사용하면 효과를 몇 배로 늘릴 수 있습니다. 일단 인코딩되면 한 번에 어디에나 적용됩니다.
• 동시에 제약 조건이 중요한 부분과 그렇지 않은 부분을 명확히 구분합니다. 중앙에서 경계를 설정하고 로컬에서는 자율성을 허용
• 결과로 생성된 코드가 항상 인간의 문체 선호도와 일치하지 않을 수 있지만, 문제가 되지 않습니다. 출력이 정확하고, 유지관리 가능하며, 앞으로 에이전트 실행 시 읽기 쉽다면 기준을 충족하는 것

 

"agent-generated"의 실제 의미 

코드베이스가 에이전트에 의해 생성된다는 것은, 모든 것이 코드베이스라는 의미

에이전트가 생성하는 것:

• 제품 코드 및 테스트
• 내부 개발자 도구
• 문서화 및 설계 내역
• 평가 하네스(evaluation harness) : 에이전트나 코드가 제대로 동작하는지 자동으로 시험해보는 평가용 실행 환경/검사. 로직 테스트보다 범위가 넒음
  • test code : 개별 테스트 코드 
  • evaluation harness : 테스트들(test set) 을 특정 조건에서 돌리고(테스트 실행 환경), 결과를 수집/채점(채점)하는 평가(리포트) 프레임워크
  • 즉, 테스트 세트 + 테스트 실행 환경 + 채점/평가 로직 + 리포트 방식까지 묶은 개념
  • 에이전트가 자기 결과물을 계속 검증할 수 있는 평가 장치까지 함께 만든다는 뜻에 가깝다.
• 리뷰 코멘트 및 응답
• 리포지터리 자체를 관리하는 스크립트
• 생산 대시보드 정의 파일 : 서비스 운영 대시보드를 수동으로 구성하는 것이 아닌 파일(코드)로 관리하는 것(IaC : Infra as Code)
  • Grafana 같은 운영 대시보드의 설정을 코드처럼 파일로 저장한 것
  • 대시보드도 git으로 버전관리
  • 누가 뭘 바꿨는지 추적 가능
  • 환경마다 동일하게 재현 가능
  • 에이전트가 읽고 수정하기 쉬움
  • 즉, 사람이 콘솔에서 클릭으로만 만드는 대시보드보다, 파일로 선언된 대시보드가 에이전트 친화적이라는 맥락
  • 로그, 메트릭, 추적을 에이전트가 직접 읽고 활용할 수 있게 만드는 방향을 강조
• 사람(엔지니어)은?
  • 에이전트가 어려움을 겪으면 이를 신호로 간주하여 도구, 가드레일, 문서화 등 무엇이 누락되었는지 파악하고 항상 Codex 자체에서 수정사항을 작성하여 리포지터리에 다시 제공
  • PR을 리뷰하고, 피드백을 작성. 에이전트를 리뷰 피드백을 가져오고, 인라인으로 응답하고, 업데이트를 푸시하며, 종종 자체 PR을 스쿼시/병합하기도 합니다.

 

"에이전트"의 자율성 수준의 증가

테스트, 검증, 검토, 피드백 처리 및 복구 등 개발 과정의 많은 부분이 시스템에 직접 통합됨에 따라, 최근 Codex가 새로운 기능의 엔드투엔드 개발을 주도할 수 있는 중요한 전환점을 맞이했습니다.

이제 에이전트는 한 번의 프롬프트를 통해 다음을 수행할 수 있습니다.

• 코드베이스의 현재 상태 검증
• 보고된 버그 재현
• 실패 상황을 시연하는 동영상 녹화
• 오류 수정 
• 애플리케이션을 실행하여 수정사항 검증
• 해결책을 보여 주는 두 번째 동영상 녹화
• pull request 열기
• 에이전트 및 사람 피드백에 응답하기
• 빌드 실패 감지 및 수정
• 판단이 필요한 경우에만 사람에게 에스컬레이션
• 변경사항 병합

단, 이러한 동작은 (Harness팀)저장소의 특정 구조와 도구에 크게 의존하며, 
적어도 아직은 Harness팀과 유사한 수준의 투자(지식, 기술, 환경, 시간)가 없이는 일반화될 수 있다고 가정해서는 안된다.

 

엔트로피 및 가비지 컬렉션

 

에이전트의 완전한 자율성은 새로운 문제를 야기하기도 합니다.

 Codex는 리포지터리에 이미 존재하는 패턴, 심지어 불균일하거나 최적 상태가 아닌 패턴도 복제합니다. 따라서 시간이 지나면 필연적으로 드리프트(흔들림, 오차)가 발생합니다.

처음에는 사람들이 이를 수동으로 처리했습니다. 예전에는 우리 팀이 매주 금요일(일주일의 20%)마다 “AI 슬로프(찌거기)”를 정리하느라 시간을 보냈습니다. 예상대로(놀랍지도 않게) 그 방식으로는 규모(코드)가 커지니 버틸 수 없었습니다.

대신, “황금 원칙”이라는 것을 리포지터리에 직접 인코딩하고 정기적인 정리 프로세스를 구축하기 시작했습니다.

 

안티 패턴의 정리를 위해 핵심 원칙을 저장소 구조와 규칙에 녹여 넣었고, 반복적으로 결과물을 정리·교정하는 운영 절차도 구축했다.

 

• encoding ... directly into the repository
  • 원칙을 repository 안의 문서, 규칙, 설정, 검사 로직, 템플릿 같은 형태로 아예 반영했다는 뜻
• golden principles
  • 팀이 꼭 지키고 싶은 핵심 원칙, 운영 원칙, 베스트 프랙티스
• built a recurring cleanup process
  • 한 번만 이 작업을 한 것이 아닌
  • 정리 프로세스를 주기적으로 계속 만들어나갔다

 

 

실행에서도 코드베이스의 가독성과 일관성을 유지하도록 설계된 규칙입니다.
예를 들어,
(1) 불변 조건을 중앙에서 관리하기 위해 직접 만든 헬퍼보다 공유 유틸리티 패키지를 선호하며
=> 공통 규칙은 여기저기 제각각 만들지 말고 공용 유틸/공용 패키지에 모아두고

(2) “YOLO-style”로 데이터를 탐색하지 않고, 경계를 검증하거나 유형 지정된 SDK에 의존하여 추측한 형태를 바탕으로 에이전트가 실수로 구축하지 못하도록 합니다.
  => YOLO : You Only Live Once - 인생 한 번뿐 고민하지 말고 해보자. 한 번 사는 인생인데 질러보자. 결과는 나중에 보고 일단 하자.
   => 여기서 YOLO-style은 진지한 기술 용어라기보다 “일단 해보고 아니면 말지” 식의 막무가내 접근을 비꼬는 표현
   => 데이터를 대충 감으로 찔러보는 식으로 작성하는 것

  스키마 정보를 Agent가 인식하도록 구성하거나, 타입 정보를 제공하는 SDK를 사용

정기적으로 편차를 검사하고, 품질 등급을 업데이트하며, 대상 리팩터링 pull request를 생성하는 Codex 백그라운드 작업을 운영합니다. 대부분은 1분 이내에 검토할 수 있으며 자동으로 병합됩니다.

이것은 가비지 컬렉션처럼 작동합니다. 기술 부채는 고금리 대출과 같아서, 이자가 쌓여 고통스럽게 한꺼번에 갚는 것보다 조금씩 꾸준히 갚아나가는 편이 훨씬 낫습니다. 사람의 취향은 한 번 포착되면 코드의 모든 라인에 지속적으로 반영됩니다. 이렇게 하면 나쁜 패턴이 코드베이스에 며칠 또는 몇 주 동안 퍼지지 않도록 매일 포착하고 해결할 수 있습니다.

 

 

우리가 여전히 배우고 있는 점

• 완전한 에이전트 생성 시스템에서 아키텍처 일관성이 수년에 걸쳐 어떻게 진화하는지에 대한 것
• 우리는 사람의 판단이 가장 큰 영향력을 발휘하는 부분과 그 판단을 인코딩(코드화, 텍스트화)하여 복합적으로 활용하는 방법을 여전히 배우고 있다.
• 모델의 기능이 계속 향상됨에 따라 이 시스템이 어떻게 발전할지 알 수 없습니다.
• 분명해진 것은 소프트웨어를 구축하는 데는 여전히 규율이 필요하지만, 규율은 코드보다는 스캐폴딩에서 더 많이 드러난다는 점입니다.
• 코드베이스의 일관성을 유지하는 툴링, 추상화, 피드백 루프는 점점 더 중요해지고 있습니다.

현재 가장 어려운 과제는 에이전트가 우리의 목표인 복잡하고 안정적인 소프트웨어를 대규모로 구축하고 유지관리하는 데 도움이 되는 환경, 피드백 루프, 제어 시스템을 설계하는 것입니다.

Codex와 같은 에이전트가 소프트웨어 라이프사이클에서 더 많은 부분을 차지함에 따라 이러한 질문은 더욱 중요해질 것입니다. 몇 가지 초기 교훈을 공유하여 직접 구축할 수 있도록 어디에 노력을 투입해야 할지 판단하는 데 도움이 되길 바랍니다.

 

 

 

추가 학습

AI는 우리에게 좋은 코드를 작성하도록 강요하고 있다.

https://bits.logic.inc/p/ai-is-forcing-us-to-write-good-code

AI Is Forcing Us To Write Good Code

AI 코딩 시대에는 “좋은 코드”가 있으면 좋은 수준이 아니라, AI가 제대로 일하려면 필수 조건이 된다는 주장입니다.

쉽게 풀면:

예전에는

• 테스트 조금 부족해도 넘어가고
• 파일 구조가 좀 지저분해도 참고
• 타입이 약해도 사람이 감으로 메우는 경우가 많았죠.

그런데 AI 에이전트는 이런 지저분한 환경에서 훨씬 더 쉽게 헷갈리고, 잘못된 방향으로 작업을 확대해버립니다. 글에서는 이런 상황을 “로봇청소기가 개똥을 집안 전체에 끌고 다니는 것”에 비유합니다. 즉, 코드베이스가 엉망이면 AI가 그 문제를 더 크게 증폭시킨다는 뜻입니다.

글에서 특히 강조하는 핵심은 4가지예요.

1. 테스트는 더 중요해졌다
특히 저자는 100% 코드 커버리지를 강하게 주장합니다. 이유는 “버그가 0이 된다”가 아니라, AI가 바꾼 모든 코드가 실제로 어떻게 동작하는지 반드시 실행 가능한 예시로 검증하게 만들 수 있기 때문입니다. 그러면 커버리지 리포트가 곧바로 “아직 테스트 안 된 부분” 목록이 되어, AI가 해야 할 일을 더 명확히 알 수 있습니다.

2. 파일 구조와 이름을 잘 지어야 한다
AI는 코드를 이해할 때 파일시스템, 폴더 구조, 파일명을 많이 활용합니다. 그래서 utils/helpers.ts 같은 모호한 이름보다, 역할이 분명한 경로와 파일명이 AI에게 훨씬 큰 도움이 됩니다. 또 큰 파일 몇 개보다 작고 역할이 분명한 파일 여러 개가 AI가 문맥을 잃지 않게 도와준다고 말합니다.

3. 개발환경도 빨라야 한다
AI는 한 번 고치고, 테스트하고, 다시 고치고를 자주 반복합니다. 그래서 테스트, DB 생성, 마이그레이션, 환경 구성이 느리면 생산성이 크게 떨어집니다. 이 글은 빠르고, 쉽게 새로 만들 수 있고, 동시에 여러 개 띄울 수 있는 개발환경이 중요하다고 봅니다.

4. 타입이 강할수록 좋다
정적 타입은 AI가 할 수 있는 잘못된 선택의 범위를 줄여줍니다. 글에서는 TypeScript, OpenAPI, Postgres 제약 등을 이용해 프론트엔드, 백엔드, DB까지 타입과 규칙을 일관되게 맞추는 방식을 강조합니다. 즉, 사람을 위한 좋은 설계가 곧 AI를 위한 가드레일이 된다는 이야기입니다.

한 줄 요약하면:

AI가 코딩을 대신해줄수록, 인간이 대충 넘어가던 좋은 개발 습관들—테스트, 구조화, 타입, 자동 검증—이 오히려 더 중요해진다는 글입니다.

앞선 loop 글과 연결해서 보면 차이는 이렇습니다.

• loop 글: AI가 일하는 반복 구조를 설계하자
• 이 글: 그 반복 구조가 잘 돌게 하려면 코드베이스 자체를 좋게 만들어야 한다

 

모든 것이 랄프 루프다 https://ghuntley.com/loop/

everything is a ralph loop

이 글의 핵심은 이거예요.

기존 개발이 벽돌을 하나씩 쌓듯이 기능을 만들어가는 방식이었다면, 이제는 AI에게 일을 시키는 반복 루프(loop) 자체를 설계하는 쪽으로 개발 방식이 바뀌고 있다는 주장입니다. 저자는 이걸 “Ralph loop”라고 부릅니다.

쉽게 말하면:

• 예전 방식: 사람이 직접 기능을 하나씩 만든다.
• 이 글의 방식: AI에게 목표를 주고, 실행 → 검증 → 수정 → 다시 실행을 반복하게 만든다. 사람은 그 반복 구조를 설계하고 고친다.

저자가 특히 강조하는 포인트는 3가지예요.

첫째, 멀티에이전트보다 단순한 단일 루프가 더 낫다는 점입니다. 여러 AI가 복잡하게 통신하는 구조는 오히려 통제가 어려워질 수 있으니, 하나의 프로세스가 한 번에 한 작업을 반복 수행하는 방식이 현실적이라고 봅니다.

둘째, 엔지니어의 역할이 사라지는 게 아니라 바뀐다는 점입니다. 이제 엔지니어는 직접 모든 코드를 쓰는 사람이라기보다, AI가 실패하는 지점을 보고 그 실패가 다시는 안 나오게 루프를 개선하는 사람이라는 뜻입니다.

셋째, 소프트웨어가 점점 “자동 진화”할 수 있다는 전망입니다. 저자는 자신의 “Loom”이라는 작업을 예로 들면서, AI가 문제를 찾고, 코드를 고치고, 배포하고, 다시 검증하는 흐름까지 자동화하는 방향을 이야기합니다.

한 줄로 요약하면:

“앞으로 개발 경쟁력은 코드를 직접 얼마나 빨리 짜느냐보다, AI가 스스로 만들고 고치게 하는 반복 시스템을 얼마나 잘 설계하느냐에 달려 있다”는 글입니다.

 

 

[추가 학습 자료]
Codex 사용법 및 검증된 활용법으로 더 나은 결과를 얻는 방법

https://developers.openai.com/codex/learn/best-practices

Best practices – Codex | OpenAI Developers

 

코딩 에이전트를 만드를 방법 https://ghuntley.com/agent/

how to build a coding agent: free workshop

 

엔지니어링 활용: AI 지원 개발을 위한 구조화된 워크플로우

https://developers.redhat.com/articles/2026/04/07/harness-engineering-structured-workflows-ai-assisted-development#

Harness engineering: Structured workflows for AI-assisted development | Red Hat Developer

 

코딩 에이전트를 위한 엔지니어링 활용

https://www.humanlayer.dev/blog/skill-issue-harness-engineering-for-coding-agents

Skill Issue: Harness Engineering for Coding Agents