What Comes After Loops?: Deep Dive Into Agentic Architecture

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

What Comes After Loops?: Deep Dive Into Agentic Architecture를 중심으로, 에이전트의 출발점은 추론·도구 실행·결과 확인의 반복이다. Codex는 모델이 컴퓨터에서 직접 행동하고 수정하도록 모델과 하네스를를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 에이전트의 출발점은 추론·도구 실행·결과 확인의 반복이다. Codex는 모델이 컴퓨터에서 직접 행동하고 수정하도록 모델과 하네스를 함께 설계한 사례로 소개된다.
2. 긴 작업에는 문맥 압축과 목표 보존이 필요하다. 발표는 네이티브 압축, 대화 문맥 밖에 목표를 저장하는 goal 방식, 모델 자체의 지속성 학습으로 이어지는 발전 과정을 설명한다.
3. 기본 전략은 명확한 과제와 검증 방법을 가진 단일 에이전트다. 여러 에이전트는 독립적인 작업 분해나 조사 병렬화가 실제로 도움이 될 때 추가한다.
4. 협업 구조는 작업에 맞춰 선택한다. 모델별 추론 노력 배분, 서로 소통하는 에이전트 쌍, 여러 대화를 관리하는 스레드 관리자 등이 제시되지만, 토큰 증가와 승인 대기 비용도 함께 고려해야 한다.
5. 대규모 에이전트 팀의 핵심은 공통 목표, 접근법의 다양성, 팀 간 정보 공유와 중복 작업 방지다. 후반부의 수학 연구 성과와 규모 수치는 발표자의 주장으로 구분해 읽어야 한다.

🧩 배경과 문제 정의

초기 ChatGPT 사용에서는 사람이 생성된 코드를 복사하고 실행 결과를 확인해야 했다. 발표는 이 수동 연결을 모델의 추론·도구 사용·결과 확인으로 바꾸는 에이전트 루프에서 출발한다. 이후의 문제는 더 오래 작업하면서도 목표를 잊지 않고, 필요할 때 일을 나누며, 협업 비용을 통제하는 것이다.

발표 전반부는 모델과 하네스의 공동 설계, 문맥 압축, 외부 루프에서 모델 자체의 지속성으로 이어지는 변화를 설명한다. 중반부는 단일 에이전트와 여러 협업 패턴의 선택 기준을 제시하고, 후반부는 공통 목표 아래 대규모 연구 팀을 운영한 사례를 소개한다. 연구 성과는 제공된 전사에서 검증된 사실이 아니라 발표자의 설명으로 다룬다.

🕒 시간순 섹션별 상세정리

1. 코드 생성에서 행동하는 에이전트로

• Raj는 모델이 발전하면 에이전트를 만드는 방식도 바뀐다는 전제로, OpenAI의 설계 과정과 현재 활용법, 다음 단계를 보여준다. [00:59]
• 초기 ChatGPT의 FizzBuzz 코드는 실행됐지만, 코드를 편집기로 옮기고 실행하는 역할은 여전히 사람이 맡았다. [01:53]
• 추론과 도구 사용을 결합하면 모델이 행동 결과를 확인하고 다음 단계를 정할 수 있다. 발표는 이를 에이전트 루프라고 정의한다. [02:32]

2. Codex를 구성하는 모델과 하네스

• Codex는 컴퓨터에 접근해 시도하고 결과를 보며 방향을 바꾸는 에이전트로 묶인다. 모델은 하네스의 도구와 피드백을 활용하도록 학습되며, 학습과 하네스 설계는 서로 영향을 준다. [03:23]
• 과제 전체를 넘기면 Codex가 코드 작성, 실행, 출력 확인과 오류 수정까지 수행하는 방식으로 작업 범위가 확장된다. [03:46]
• 하네스는 지시, 도구, 모델이 보는 정보, 실행 환경과 문맥을 관리한다. 발표는 셸·파일 시스템·컴퓨터 사용처럼 일반적인 도구를 제공하는 최소한의 설계를 강조한다. [04:41]

3. Responses API와 실행 제어

• 발표에서 Responses API는 모델에 도구 정의를 전달하고 에이전트 루프를 연결하는 중심 구성으로 드러난다. [04:52]
• 요청된 도구는 샌드박스에서 실행되고, 결과는 대화 문맥에 추가된다. 하네스는 작업을 이어갈지 다음 턴으로 넘어갈지 결정한다. [05:05]
• 하네스 운영에서 얻은 경험은 모델 학습으로 이어지며, 하나의 문맥 창으로 부족한 작업을 처리하는 압축이 그 대표 사례로 드러난다. [05:25]

4. 네이티브 압축으로 긴 작업 이어가기

• 지시, 작업 이력, 파일 읽기와 도구 결과가 쌓이면 문맥 창의 한계에 도달한다. 장기 작업에는 이전 작업을 잊지 않으면서 새 작업을 위한 공간을 확보하는 방식이 필요하다. [05:57]
• 문맥이 차면 Responses API를 통해 압축을 요청해 대화 이력을 줄인다. Codex 모델 자체도 압축된 상태에서 작업을 재개하도록 학습됐다고 보여준다. [06:38]
• 여러 문맥 창과 압축을 거쳐 작업할 수 있게 되자, 다음 과제는 모델이 완료할 때까지 계속 일하도록 만드는 것으로 이동한다. [06:58]

5. 조기 종료를 보완한 외부 루프

• 초기 모델은 진척이 있어도 턴을 일찍 끝내곤 했다. OpenClaw 제작자 Peter Steinberger의 반복적인 계속 지시가 외부 루프의 사례로 나온다. [07:29]
• Geoffrey Huntley가 대중화한 Ralph loop는 셸 반복문으로 프롬프트를 재실행하고, 새 문맥에서 이전 실행이 남긴 파일을 이어받는 방식으로 드러난다. [07:58]
• 반복은 작업을 지속시키지만 진척 판단, 실행 관리와 종료 시점은 외부에서 다뤄야 했다. 발표는 이런 반복 설계를 loop engineering이라고 부른다. [08:20]

6. 별도 목표 저장에서 모델 자체의 지속성으로

• GPT-5.5와 연결해 소개된 goal 방식은 목표를 핵심 대화 문맥 밖에 저장하고 상태를 추적한다. 목표가 압축이나 턴 종료 뒤에도 남아 작업 지속을 유도하는 구조다. [08:58]
• 하네스는 계속 작업할지 확인하고, 실제 장애물이 있으면 중단을 요청할 수 있게 한다. 이런 운영 경험이 지속성을 학습시키는 신호가 됐다고 보여준다. [09:27]
• 발표는 GPT-5.6에서 지속성을 모델에 학습시켜 반복적인 계속 지시 없이 유용한 단계를 수행하고 자기 작업을 확인하도록 했다고 주장하며, 사용자 평가와 약 5시간의 게임 실행 일화를 덧붙인다. [09:58]

7. 병렬화의 등장과 단일 에이전트 우선 원칙

• 긴 시간 일할 수 있게 된 뒤에는 속도와 병렬화가 과제가 된다. 발표는 GPT-6에서 문제를 나누고 스스로 협업을 조정하는 능력이 크게 발전했다고 보여준다. [10:29]
• Eric은 현재 Codex 활용법을 소개하며, 긴 과제라고 곧바로 에이전트 팀을 만들기보다 명확한 과제와 검증 방법을 갖춘 한 에이전트로 시작하라고 권한다. [11:29]
• 문맥 압축과 실패 극복을 포함한 단일 에이전트의 지속성만으로 충분한 과제가 많으며, 작업 자체가 필요성을 보여줄 때 추가 에이전트를 투입하라고 강조한다. [11:44]

8. 분해 가능한 작업과 협업 비용

• 대규모 리팩터링이나 게임 제작에서는 독립적인 부분으로 문제를 나눌 수 있다. Ultra에서는 Codex가 스스로 복사본을 만들어 협업하는 방식이 묶인다. [12:12]
• 에이전트를 추가하면 토큰 사용량이 크게 늘 수 있지만 작업이 반드시 빨라지거나 좋아지는 것은 아니다. 추가 지원이 필요한지 판단해야 한다. [12:26]
• PR 다섯 개에 각각 하위 에이전트를 배정하거나, 경쟁 상태 조사에 몇 개의 에이전트를 투입하는 예시가 드러난다. 복잡한 구조 자체가 가치를 보장하지는 않는다. [13:07]

9. 난도에 따라 모델과 추론 노력 배분하기

• Effort scaling은 과제의 중요도와 난도에 따라 투입할 모델과 추론 노력을 조정하는 방식으로 묶인다. [13:28]
• Sol이 통합을 맡고, 어려운 문제는 Astra에, 단순한 지원 작업은 Luna에 나누는 구성이 드러난다. 다만 어떤 모델이 가장 저렴하게 해결할지 완벽히 예측할 수 없어 비용 절감을 보장하지는 않는다. [14:01]
• Coordinate라는 스킬 예시는 Sol Medium을 기본으로 사용하고, 막히는 문제는 Astra High에, 단순 작업은 Luna High 에이전트에 맡기도록 구성된다. [14:23]

10. 서로 영향을 주는 작업을 위한 에이전트 쌍

• Eric은 오래된 게임의 실행 장면을 Blender에서 재현해 새 게임 엔진으로 옮기려던 프로젝트를 보여준다. [14:52]
• 한 에이전트는 기존 엔진의 캡처 기술을, 다른 에이전트는 장면을 풀어 Blender에서 시각화하는 작업을 담당했다. 출력 형식과 캡처 방식이 서로 영향을 주므로 지속적인 소통이 필요했다. [15:18]
• 이런 쌍을 구성할 때는 통신 경계를 명시해야 하며, 각자의 발견에 맞춰 상대 작업을 조정할 수 있게 설계해야 한다. [15:34]

11. 스레드 관리와 과도한 관리 계층의 비용

• 발표는 ChatGPT 앱에서 Codex가 새 대화를 만들고 실행 중인 다른 대화에 메시지와 방향을 전달하는 스레드 관리자 역할을 보여준다. 각 대화는 자체적으로 하위 에이전트를 사용할 수 있어 두 개념은 구분된다. [16:16]
• PR마다 별도 대화를 만들거나 장기 게임 프로젝트를 미술·설계·프로그래밍·플레이 테스트로 나눠 운영할 수 있다. 사용자는 각 대화에 직접 개입하면서 전체 조정도 맡길 수 있다. [17:32]
• 이런 운영이 토큰 측면에서 가장 효율적이지 않을 수 있다. 특히 협업 규칙과 승인 계층을 늘리면 에이전트가 승인을 기다리며 지체하는 middle management tax가 생긴다고 경고한다. [17:58]

12. 반복 압축과 추가 지시를 견디는 작업 로그

• 작업 중 작은 추가 지시가 계속 들어오고 압축이 여러 번 일어나면, 최초 프롬프트의 목표와 중요한 문맥에서 벗어날 수 있다. [18:38]
• 전체 목표, 진행 중인 작업, 최근 지시의 관계를 담은 간결한 작업 로그를 유지하라고 권한다. 모든 실패를 기록하는 끝없는 일지가 되지 않도록 짧게 관리하는 것이 핵심이다. [19:19]
• 모범 사례에도 유효기간이 있으므로 기존 워크플로에 집착하지 말라는 조언으로 실전 활용 설명을 마무리한다. [19:35]

13. 대규모 연구 팀의 목표와 정보 공유

• Raj는 수천 개 에이전트가 하나의 목표를 향해 일관되게 움직이는 문제를 제기한다. Navier–Stokes 연구에서 내부 모델과 Codex, 1만 에이전트를 활용해 해법을 찾았다고 주장하며, 전체 과정에 270만 메시지와 출력 토큰 약 1,300억 개가 쓰였다고 드러낸다. [20:37]
• Agent teams는 여러 팀이 공통 목표를 공유하되 서로 다른 문제 표현과 접근법으로 출발하는 구조다. 깊은 탐구와 폭넓은 연구를 함께 유도하려는 설계다. [21:26]
• 팀 내부뿐 아니라 팀 사이에도 발견, 질문과 진행 상황을 공유한다. 이는 접근법의 다양성을 확보하면서 모든 에이전트가 같은 시도를 반복하는 비용을 줄이기 위한 장치다. [22:04]

14. 발견에 따라 팀을 재편하고 더 어려운 문제로 확장

• 팀들은 가설 탐색, 전제 검토와 실험 등 서로 다른 접근을 맡고, 새 질문이 나오면 팀을 추가하거나 유망한 방향으로 유도한다. 작업 분담이 바뀌어도 목표는 유지한다. [22:40]
• 발표자는 비강제 Euler 결과를 얻은 뒤 팀들을 재배치해 문제를 해결했으며, GPT-6보다 강력한 내부 모델로 수학의 장기 미해결 문제 100개 이상을 해결했다고 주장한다. 전사에는 이를 검증할 증명이나 상세 자료가 포함되지 않는다. [23:11]
• 모델 발전에 맞춰 더 야심찬 과제를 시도할 수 있다는 메시지로 마무리한다. 미뤄둔 문제나 이전 모델이 해결하지 못한 문제에 소개된 접근법을 적용하고, 언급된 연구 상세 자료를 살펴보라고 권한다. [23:46]

🧾 결론

• 루프는 사라지는 것이 아니라, 외부에서 계속 재촉하던 기능 일부가 모델의 지속성과 하네스의 문맥 관리로 이동한다.
• 좋은 아키텍처의 기준은 에이전트 수보다 과제의 명확성, 결과 검증 가능성, 작업 간 독립성과 소통 필요성이다.
• 장기 작업에서는 압축 이후에도 전체 목표와 현재 작업을 이어갈 수 있도록 간결한 작업 로그를 유지중요하다.
• 모델이 발전하면 유효한 작업 방식도 달라진다. 발표는 기존 워크플로에 집착하지 말고 이전에 해결하지 못한 과제를 다시 시도하라고 권한다.

📈 투자·시사 포인트

• 에이전트 도입의 경제성은 병렬화 효과와 추가 토큰·조정 비용을 함께 비교해야 한다. 발표도 에이전트 추가가 속도나 품질 향상을 보장하지 않는다고 명시한다.
• 제품과 도구를 평가할 때 모델 성능뿐 아니라 실행 환경, 문맥 압축, 목표 보존, 작업 검증을 연결하는 하네스의 역할을 살펴볼 필요가 있다.
• 여러 모델에 업무를 나누는 effort scaling은 모델 선택 부담을 줄일 수 있지만, 항상 비용을 절감한다는 근거로 해석해서는 안 된다.
• 대규모 연구 사례는 에이전트 활용 범위의 확장 가능성을 보여주려는 발표다. 투자 판단에 연결하려면 성과 검증과 전체 비용 자료가 추가로 필요하다.

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

• Navier–Stokes 문제 해결, 비강제 Euler 결과, 수학의 장기 미해결 문제 100개 이상 해결은 발표자의 주장이다. 제공된 전사에는 증명, 문제별 범위, 독립 검증 자료가 없어 성과의 정확한 의미를 확인할 수 없다.
• 1만 에이전트, 270만 메시지, 출력 토큰 약 1,300억 개는 발표에 제시된 수치다. 실행 기간, 총비용, 실패한 시도와 비교 기준은 제시되지 않는다.
• GPT-5.5·GPT-5.6·GPT-6, Ultra, goal, 스레드 관리 기능의 설명만으로 실제 제공 범위나 사용 조건을 확정할 수 없다. 전사의 일부 인명과 기술 표현도 원문 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 먼저 단일 에이전트에 명확한 목표와 결과 확인 방법을 주고, 실제로 완료할 수 있는지 확인한다.
• 병렬화하려는 작업을 독립적인 단위로 나누고, 여러 PR 검토나 조사 분담처럼 분리 이익이 분명한 부분부터 적용한다.
• 전체 목표, 현재 진행 중인 작업, 최근 추가 지시와 목표의 관계를 담은 짧은 작업 로그를 유지하게 한다.
• 여러 에이전트를 사용할 때 단일 에이전트 대비 완료 시간, 결과 품질, 토큰 사용량을 비교한다.

❓ 열린 질문

• 어떤 작업 규모와 의존 관계에서 여러 에이전트의 병렬화 이익이 토큰·소통 비용을 넘어서는가?
• 반복 압축과 추가 지시가 이어질 때 최초 목표와 중요한 제약을 얼마나 안정적으로 보존할 수 있는가?
• 대규모 팀에서 접근법의 다양성을 유지하면서 중복 연구를 줄이는 소통 방식은 무엇인가?