What Will You Build With Coding Agents That Don''t Quit?

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

What Will You Build With Coding Agents That Don’t Quit를 중심으로, Codex와 Astra를 활용한 사례는 Ferrari 3D 모델과 탐색 웹사이트, Nürburgring 주행 경로 영상까지 이어졌를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. Codex와 Astra를 활용한 사례는 Ferrari 3D 모델과 탐색 웹사이트, Nürburgring 주행 경로 영상까지 이어졌다. 렌더링 도중 자원 문제가 발생해도 저장된 프레임에서 작업을 재개했다.
2. 발표자는 상세 구현 절차를 지시하던 방식에서 목표·트레이드오프·완료 기준을 전달하는 방식으로 전환했다고 설명한다. CI 에이전트는 약 200단어의 시작 프롬프트로 6주간 운영됐다.
3. CI 사례에서는 메인 에이전트가 테스트 실행·실패 정보 수집·협업을 맡고, 서브에이전트가 개별 오류를 조사하고 수정하도록 역할을 나눈 것이 생산성 전환점이었다.
4. 발표된 성과는 주당 100건 넘는 PR, 1,000건 넘는 커밋, Slack 메시지 600건 이상, 자체 수정 213건 초과 병합이다. 이는 발표자가 소개한 내부 운영 사례의 수치다.
5. 장기 실행을 뒷받침하는 요소로 목표별 스레드, AGENTS.md와 작업 기록, 컨텍스트 압축, 원격·클라우드 환경, 플러그인, 작업 위임, Ultra, 예약 후속 작업이 소개됐다. 비용과 CI 자원 한도도 함께 정해야 한다.

🧩 배경과 문제 정의

발표는 ‘중간에 멈추지 않고 계속 일하는 코딩 에이전트로 무엇을 만들고 맡길 수 있는가’를 다룬다. OpenAI의 엔지니어링 가속과 개발자 경험 업무를 소개한 뒤, 개인적인 F1 관심사에서 시작한 3D 제작과 조직 전체의 CI 유지보수라는 두 가지 사례를 연결한다.

핵심 문제는 사람이 계속 지시하고 기다리며 다시 확인해야 하는 업무의 부담이다. 특히 CI에서는 실제 코드 결함과 간헐적으로 실패하는 테스트를 구분해야 하며, 어려운 오류 하나를 조사하는 동안에도 새로운 실패가 계속 들어온다. 발표는 목표와 검증 기준을 정한 에이전트가 이러한 업무를 장기간 반복 처리하도록 구성하는 방법을 설명한다.

🕒 시간순 섹션별 상세정리

1. 사진 일곱 장에서 시작한 Ferrari 탐색 프로젝트

• 발표자들은 OpenAI에서 엔지니어링 가속과 개발자 경험을 담당한다고 보여준다. Vivi는 Codex와 Astra로 3D 세계를 만드는 실험을 해왔다고 드러낸다. [00:40]
• F1 차량의 구성 요소를 알아보기 위해 원격 머신에서 Ferrari 모델과 탐색용 웹사이트를 만드는 목표를 부여했다. 참고 사진 일곱 장을 바탕으로 며칠 동안 함께 다듬었다. [01:37]
• 발표자는 Astra가 별도 요청 없이 일반적인 3D 표현 외에 클레이와 와이어프레임 버전까지 만들었다고 보여준다. [01:52]

2. 서킷 이름으로 만든 Nürburgring 영상

• 다음 프로젝트에서는 트랙 이름만 주고 Nürburgring을 따라 이동하는 영상을 만들도록 했다. Codex가 온라인 참고 자료를 찾아 새로 생성한 결과라고 보여준다. [02:32]
• Codex는 짧은 코스 대신 긴 Nordschleife를 선택했다. 발표자가 설명한 재현 범위는 약 21km와 70개 코너다. [03:04]
• 작업에는 이틀이 조금 넘게 걸렸고 대부분은 Blender 렌더링 대기였다. 서브에이전트는 트랙 조사, 형상 확인, 렌더링 계획을 도왔다. [03:24]

3. 자원 문제 이후에도 이어지는 작업

• 연산량이 큰 렌더링 과정에서 RAM 문제와 CPU 과열 등으로 작업이 몇 차례 중단됐다. [03:37]
• Codex는 저장된 프레임을 기준으로 작업을 재개하며 이틀 동안 제작을 이어갔다. 발표자는 이를 적절한 결과를 지정받은 에이전트가 장시간 일할 수 있다는 사례로 연결한다. [04:06]

4. 상세 절차 지시에서 목표와 판단 기준 전달로

• 지난해에는 어려운 문제를 7시간 동안 처리하게 하는 것도 큰 성과였으며, 긴 프롬프트에 코드 예시와 라이브러리, 구현 방향을 넣고 계획을 검토했다고 회고한다. [04:57]
• 이제는 원하는 목표와 결과, 중요한 트레이드오프, 좋은 결과를 판별하는 기준을 전달하고 실행 단계는 모델이 정하도록 맡기는 데 더 편안함을 느낀다고 드러낸다. [05:31]
• 이 변화는 계속 수동으로 감독하느라 시간을 쓰는 업무를 얼마나 오래 맡길 수 있는지 시험하는 계기가 됐다. [05:43]

5. 6주간 이어진 CI 유지보수 실험

• 발표자는 에이전트가 6주 이상, 누적 1,000시간 넘게 일했다고 보여준다. 대상 업무는 OpenAI 전반의 CI 상태를 유지하는 일이었다. [05:57]
• CI 실패에는 실제 결함뿐 아니라 실행할 때마다 결과가 달라지는 불안정한 테스트도 있다. 원인 조사에 몇 시간이나 며칠이 걸리는 동안 새로운 실패가 반복해서 들어온다. [06:32]
• 약 200단어의 시작 프롬프트에 기본 규칙, 동료와의 소통 방식, CI 자원 사용 원칙을 담고 테스트 실행법과 수정법은 에이전트가 찾게 했다. 6주 뒤 종료한 이유는 동료들도 같은 업무에 자체 에이전트를 운영하기 시작했기 때문이라고 보여준다. [07:22]

6. 메인 에이전트와 서브에이전트의 역할 분담

• 처음에는 5.6 Soul이 한 스레드에서 실패 조사와 수정을 모두 맡았다. 어려운 문제 하나에 오래 붙잡히면 다른 실패가 쌓이는 병목이 나타났다. [07:42]
• 약 나흘 뒤 서브에이전트에 개별 작업을 맡기도록 바꿨다. 메인 스레드는 테스트 실행, 실패 정보 수집, 하위 작업 조직과 사람들과의 소통을 담당했다. [08:00]
• 서브에이전트는 코드를 내려받아 특정 실패를 조사하고, 수정 후 CI에 올려 검증과 재시도를 반복했다. 발표자는 자신의 역할을 에이전트 팀을 관리하는 에이전트에게 일을 주는 것으로 표현한다. [08:28]

7. 수정 성과와 대기를 포함한 실행 규모

• 6주 동안 주당 100건 넘는 PR을 열고, 1,000건 넘는 커밋과 Slack 메시지 600건 이상을 만들었으며, 자체 수정 213건을 넘게 병합했다고 보고한다. 다른 사람이 유사한 수정을 준비했다면 그 작업을 우선하기도 했다. [08:59]
• 회고에서는 사람이 한 번도 메시지를 보내지 않았던 닷새가 가장 생산적이었다는 응답도 보여준다. 전체 실행은 도구 호출 약 50만 회 미만, 서브에이전트 세션 5,800개 이상이었고, 67,000회 넘는 호출은 대기였다. [09:34]
• 에이전트는 대기 후 다음 단계로 넘어가는 일을 반복했다. 발표자는 처리한 오류들이 다른 사람과 에이전트가 이미 살펴보고도 남겨둔 어려운 문제였다고 강조한다. [10:12]

8. 간헐적 GPU 오류 조사와 추가 검토

• 사례로 GPU 테스트의 비결정적 부동소수점 오류를 보여준다. 에이전트는 여러 주에 걸친 로그를 연관 지어 특정 노드를 찾아내고, 그 노드에서 테스트를 반복 실행해 간헐적 재현에 성공했다. [10:59]
• 이어 담당 연구자들에게 재현 방법을 설명하고, 저장소 밖의 소프트웨어 최적화나 GPU 결함 가능성을 질문하며 협업했다. 문제를 해결했다고 설명하지만 최종 원인은 밝히지 않는다. [11:28]
• 실패한 테스트 삭제가 적절한지 확신이 없을 때는 다른 에이전트가 먼저 코드를 검토한 뒤 사람에게 리뷰를 요청했다. 발표자는 이 자동화로 수백 시간을 돌려받아 인프라 확장에 집중했다고 드러낸다. [12:04]

9. 결과별 스레드와 명확한 검증 순환

• 장기 실행 방법을 소개하며 원하는 결과 하나마다 스레드 하나를 사용하라고 권한다. 같은 스레드에서 계획을 다듬고 진행을 확인하며 방향을 바꿀 수 있다. [13:22]
• /goal은 작업이 완료될 때까지 목표를 계속 추구하도록 지정하는 방식으로 묶인다. [13:37]
• CI 예시의 지시는 실패 감시, 재현, 수정 제안, 리뷰용 PR 생성이다. 테스트가 작업을 확인하는 수단이 되어 변경과 재검증의 순환을 구성한다. [14:14]

10. AGENTS.md와 작업 기록, 컨텍스트 압축

• AGENTS.md에는 테스트 위치와 작업 규칙, 금지 사항을 담고 프로젝트 진행에 맞춰 계속 관리하라고 권한다. [14:45]
• 완료한 일과 남은 조사 내용을 기록하게 하면 중단 후 작업 기록을 읽고 이어갈 수 있다고 보여준다. [15:09]
• 긴 스레드의 맥락 유지에는 기본 내장된 컨텍스트 압축을 제시한다. 발표자는 석 달간 이어지는 스레드를 예로 들며 장기 작업을 지원한다고 주장한다. [16:03]

11. 원격 머신과 Codex Cloud 실행 환경

• 노트북을 계속 켜두는 부담을 줄이기 위해 SSH로 원격 머신에 연결하고, 데스크톱·모바일·웹에서 해당 환경의 파일과 저장소, 도구를 활용하는 방식을 보여준다. [16:42]
• 서킷 프로젝트의 개발 서버에는 Blender, 프로젝트 파일, 웹 검색 접근이 준비돼 있었다. 이어 발표 당일부터 개선된 Codex Cloud에서 직접 머신을 관리하지 않고 에이전트와 가상 머신을 사용할 수 있다고 보여준다. [17:12]
• 클라우드 환경의 스냅샷, 체크아웃한 코드와 의존성의 주기적 갱신, 여러 접속 화면과 플러그인 지원을 보여준다. 발표자는 행사 무대 뒤에서도 이를 통해 PR을 병합했다고 덧붙인다. [17:53]

12. 플러그인으로 조직의 작업 맥락 연결

• 테스트 실패와 관련된 GitHub 이슈나 동료들의 Slack 논의를 모르면 에이전트가 이미 진행 중인 상황을 파악하지 못한 채 움직일 수 있다고 지적한다. [18:31]
• GitHub와 Linear 같은 플러그인을 연결해 이슈, 논의, PR을 검색하도록 하며, 평소 사용하는 도구의 맥락을 제공하는 것이 활용도를 높인다고 보여준다. [18:52]

13. 하위 스레드와 워크트리, 별도 질문 공간

• Ferrari의 Blender 모델과 웹사이트처럼 독립적으로 진행할 수 있는 일은 하위 스레드로 나눈다. 메인 스레드는 전체 목표를 관리하고 사람은 개별 스레드에 방향을 주거나 중단시킬 수 있다. [19:48]
• Git 저장소에서는 각 하위 스레드가 별도 체크아웃인 워크트리를 사용해 동일한 코드 사본에서 작업이 뒤섞이는 문제를 줄일 수 있다고 보여준다. [20:22]
• /side는 메인 스레드의 전체 맥락을 분기해 별도로 질문하는 기능으로 묶인다. 발표자는 워크트리와 이러한 분기 기능을 여러 프로젝트와 기능 작업에 자주 사용한다고 드러낸다. [21:04]

14. 하나의 어려운 문제에 시간을 쓰는 Ultra

• 여러 접근을 시도해도 막히는 문제에는 Ultra를 보여준다. 모델이 더 오래 추론하고, 내부 서브에이전트가 조사·수정 시도·다른 접근 탐색을 나눠 수행할 수 있다고 보여준다. [21:55]
• 분리하기 쉬운 작업은 하위 스레드로 병렬 처리하고, GPU 부동소수점 오류처럼 하나의 어려운 문제를 깊게 다뤄야 할 때는 Ultra를 선택한다는 기준을 제시한다. [22:24]

15. 외부 응답 대기를 처리하는 예약 후속 작업

• PR 리뷰처럼 외부 응답을 기다려야 한다면 예약 작업을 사용할 수 있다. 예시로 30분마다 리뷰 피드백을 확인하고 대응할 내용이 있으면 처리하도록 지시한다. [23:09]
• 같은 스레드의 맥락을 이어받아 다시 확인하는 예약 후속 작업을 heartbeat라고 보여준다. 이전 작업과 변경 사항을 바탕으로 다음 행동을 정한다. [23:27]
• 매번 새 작업을 만드는 예약도 가능하다. 야간 프로젝트 변화나 주간 진행 상황 요약을 예로 들며 앱의 일정 탭에서 확인할 수 있다고 보여준다. [23:59]

16. 비용 계산과 실제 도입의 기준

• 발표자는 기존 6주 CI 운영을 가격 기준으로 환산하면 시간당 약 32달러였고, GPT-6 Soul에서는 약 16달러로 낮아졌다고 보여준다. 6.1 Soul의 토큰 효율도 언급하지만 코드 리뷰와 CI 자원 등 추가 비용이 있음을 인정한다. [25:16]
• 시작점으로 시간을 많이 빼앗는 백로그, 로그·예외, CI 업무를 제안한다. 에이전트가 결과를 검증하며 반복할 테스트와 원하는 결과·완료 기준을 제공하고, 위임과 Ultra를 활용하라고 권한다. [26:09]
• 사람에게 주의가 필요한 일을 알리게 하고 에스컬레이션 조건, 지출 한도, 동시 CI 작업 수를 정하라고 강조한다. 마지막에는 Codex에 무엇을 맡기고 돌려받은 시간으로 무엇을 할지 생각해보라는 질문으로 마무리한다. [26:54]

🧾 결론

• 장기 실행의 가치는 단순히 오래 작동하는 데서 끝나지 않는다. 실패를 재현하고 수정한 뒤 검증하는 순환을 반복하며 실제 결과를 만들어야 한다.
• 사람은 목표와 제약, 검토·보고 기준을 정하고, 에이전트는 실행 절차와 하위 작업을 조직하는 역할 분담이 제시된다.
• 자동화할 업무에는 스스로 결과를 확인할 테스트와 재개에 필요한 기록이 있어야 한다. 불확실한 수정에는 추가 에이전트 검토와 사람의 리뷰가 활용됐다.

📈 투자·시사 포인트

• 개발 도구를 평가할 때 응답 속도 외에 장기간의 작업 완수율, 재개 능력, 검증 가능한 수정 성과를 살펴볼 필요가 있다.
• 발표 사례에서 플러그인과 원격 실행 환경은 조직의 이슈·대화·코드·도구를 연결하는 기반이다. 모델 성능과 함께 이러한 연결 기능의 실무 가치도 커진다.
• 경제성은 에이전트 사용료와 절약한 시간을 함께 비교해야 한다. 발표자는 시간당 약 32달러에서 GPT-6 Soul 기준 약 16달러로 낮아졌다고 설명하지만, 코드 리뷰와 CI 자원 등 추가 비용도 인정한다.
• CI 유지보수처럼 반복 발생하고 결과를 테스트할 수 있는 업무는 도입 후보로 제시된다. 다만 한 조직의 성과만으로 다른 조직의 비용 절감이나 투자 수익률을 확정할 수는 없다.

⚠️ 불확실하거나 확인이 필요한 부분

• 6주 운영 성과와 절약한 수백 시간은 발표자의 내부 사례 보고다. 비교 대상, 사람의 총 검토 시간, 수정의 장기 품질을 확인할 자료는 제공되지 않는다.
• 시간당 약 32달러와 16달러는 해당 작업과 모델 가격을 바탕으로 설명한 수치다. 일반적인 정액 요금이나 모든 작업의 실행 비용으로 해석하면 안 되며, CI 자원과 리뷰 비용을 포함한 총비용도 제시되지 않았다.
• 컨텍스트 압축으로 장기 대화의 품질을 걱정할 필요가 없다는 설명은 발표자의 주장이다. 압축 과정의 정보 손실이나 작업별 정확도를 측정한 결과는 소개되지 않는다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복적으로 시간을 빼앗는 업무 중 테스트로 결과를 확인할 수 있는 후보 하나를 고른다. 발표에서 제시한 예시는 CI 오류, 로그·예외 대응, 백로그 기능 구현이다.
• 목표별 스레드에 원하는 결과, 중요한 트레이드오프, 검증 방법, 완료 또는 지속 감시 조건을 적는다.
• AGENTS.md에 테스트 위치, 작업 규칙, 금지 사항을 정리하고, 완료한 일과 남은 조사 내용을 작업 기록에 남기도록 한다.
• 장기 실행에 필요한 원격 환경과 도구를 준비하고, 관련 이슈·논의를 확인할 수 있는 플러그인을 연결한다.

❓ 열린 질문

• 에이전트 비용에 CI 자원과 사람의 검토 시간을 더했을 때, 우리 업무에서는 어느 정도의 시간 절감과 수정 성과가 나와야 도입 가치가 있는가?
• 메인 에이전트가 직접 처리할 일과 서브에이전트에 위임할 일을 어떤 기준으로 구분해야 병목을 줄일 수 있는가?
• 테스트 삭제처럼 통과 여부만으로 적절성을 판단하기 어려운 변경은 어떤 추가 검토를 거쳐야 하는가?