에이전트 스레드: Boris Cherny처럼 배포하는 방법 (Claude Code의 Ralph Wiggum)

IndyDevDan 구독자 43,800명

요약

이 영상에서는 에이전트를 활용한 소프트웨어 개발에서 ‘스레드’를 단위로 진척과 성과를 측정하는 thread-based engineering 프레임워크를 제시합니다. 기본 스레드부터 병렬(P), 체인(C), 융합(F), 대규모(B), 장시간(L) 스레드까지 총 여섯 가지 패턴을 체계적으로 설명하고, Boris Cherny의 Cloud Code 설정 사례로 구체화합니다. 이를 통해 개선 여부를 ‘에이전트 도구 호출 수’, ‘스레드 수·길이·두께’, ‘인간 검토 단계 축소’로 명확히 측정할 수 있음을 보여줍니다. 궁극적으로 검토 단계가 사라진 Z스레드(Zero-touch Thread)까지 도달하는 미래의 에이전트 공학을 전망합니다.

주요 키워드

thread-based engineering agentic engineering Base Thread P Thread C Thread F Thread B Thread L Thread Z Thread tool call

하이라이트

🔑 스레드(Thread)는 에이전트와 사용자가 함께 수행하는 시간 단위의 작업 단위로, 시작(prompt)과 종료(review) 사이에 에이전트의 도구 호출이 핵심입니다.
⚡️ Base Thread는 단일 프롬프트와 단일 검토로 이루어지며, 에이전트의 도구 호출 수가 곧 영향력으로 연결됩니다.
🚀 P Thread(병렬 스레드)는 여러 터미널에서 동시다발적으로 에이전트를 실행해 처리 속도와 처리량을 극대화합니다.
📌 C Thread(체인 스레드)는 대규모·고위험 작업을 단계별로 분할해 검토 및 유효성 검사를 반복하면서 안정성을 확보합니다.
🌟 F Thread(융합 스레드)는 동일하거나 유사한 프롬프트를 다수의 에이전트에 전송해 결과를 합성·집계함으로써 품질을 높입니다.
🎯 B Thread(대규모 스레드)는 한 에이전트가 서브 에이전트를 다시 호출해 복잡한 워크플로우를 블랙박스 형태로 처리합니다.
🔍 개선 지표는 ‘스레드 수·길이·두께’를 늘리고 ‘인간 검토 단계’를 줄이는 것이며, 이를 통해 에이전트와의 신뢰를 높입니다.

용어 설명

스레드(Thread)

프롬프트 실행부터 도구 호출, 검토까지 에이전트와 사용자가 함께 수행하는 작업 단위

Base Thread

시작(프롬프트)과 종료(검토) 두 노드로 구성된 가장 기본적인 스레드

P Thread

Parallel Thread의 약자로, 여러 터미널에서 에이전트를 병렬 실행해 처리량을 확장하는 스레드

C Thread

Chained Thread의 약자로, 대규모 작업을 의도적으로 단계별로 분할해 순차 진행 및 검토하는 스레드

F Thread

Fusion Thread의 약자로, 동일 프롬프트를 다수의 에이전트에 보내 실행 후 결과를 합성·집계하는 스레드

B Thread

Big Thread의 약자로, 한 에이전트가 서브 에이전트를 호출해 내부에서 여러 스레드를 운용하는 메타 구조

L Thread

Long Thread의 약자로, 수시간~수일 간격으로 도구 호출을 유지하며 높은 자율성을 가지는 장시간 스레드

Z Thread

Zero-touch Thread의 약자로, 인간 검토 단계 없이 에이전트가 전 과정을 완수하는 궁극의 스레드

도구 호출(Tool Call)

에이전트가 외부 도구나 API를 활용해 작업을 수행하는 개별 작업 단위

에이전트 샌드박스

격리된 환경에서 에이전트를 실행해 신뢰를 분리하고 복수 버전을 테스트하는 구조

에이전트 도입으로 개발 격차가 벌어지는 현상을 언급하며, Andrew Karpathy도 느끼는 ‘뒤처진 느낌’을 문제로 제시합니다. 스킬 갭을 해소하기 위해 새로운 진척 측정 프레임워크가 필요함을 강조합니다.

[00:00] 에이전트 시대에 바이브 코더에서 시니어 엔지니어로 성장하는 방법에 대한 핵심 질문을 제시하며, 앤드류 카파시 같은 최고 엔지니어들도 뒤처진다고 느끼는 현실을 언급합니다.

[00:27] 에이전트를 사용하는 엔지니어와 그렇지 않은 엔지니어 사이의 격차가 벌어지고 있으며, 클로드 코드 창시자의 설정 공유를 계기로 새로운 사고 프레임워크를 소개하겠다고 합니다.

[00:47] 2년 넘게 사용한 프레임워크로 에이전트를 운영화하여 지속적으로 개선하는 방법을 설명하며, 한 번의 단계로는 충분하지 않고 매일 향상시켜야 한다고 강조합니다.

[01:19] 최고 엔지니어들의 공통점인 자기인식을 언급하며, 에이전틱 엔지니어링이 새로운 스킬이므로 새로운 측정 프레임워크가 필요하다고 설명합니다.

[01:49] 측정하지 않으면 개선할 수 없다는 원칙을 제시하고 스레드 기반 엔지니어링이라는 새로운 개념을 소개합니다.

Thread-based Engineering이란 무엇인지 정의합니다. 시작(프롬프트)과 종료(검토) 시 사용자가 참여하고, 중간에 에이전트의 도구 호출이 이루어지는 ‘스레드’ 단위를 제시합니다.

[02:01] 스레드의 정의와 구조를 설명합니다. 스레드는 사용자와 에이전트가 이끄는 시간에 따른 작업 단위로, 프롬프트/계획, 에이전트 작업, 검토/검증의 세 단계로 구성됩니다.

기본 스레드의 구성 요소를 살펴봅니다. 사용자 프롬프트, 에이전트의 도구 호출 체인, 사용자 리뷰로 이루어지며, 이 단위를 반복 측정함으로써 개선 여부를 판단할 수 있습니다.

[02:34] 스레드의 실제 작동 방식을 구체적으로 설명하며, 에이전트 도구에서 프롬프트에 엔터를 칠 때마다 새로운 작업 스레드가 시작된다는 점을 강조합니다.

[03:02] 에이전트가 10개의 도구 호출을 통해 21K 토큰의 작업을 완료하는 과정을 보여주며, 사용자는 시작 시 프롬프트 입력과 끝에 결과 검토만 담당한다고 설명합니다.

[03:16] 베이스 스레드가 중요한 이유는 에이전트가 창출하는 가치를 도구 호출로 측정할 수 있게 해주기 때문이며, 2023년 이전에는 인간이 직접 했던 모든 작업을 이제 에이전트가 수행한다고 강조합니다.

[03:50] 베이스 스레드는 시간에 따른 엔지니어링 작업 단위를 나타내며, 하나의 스레드에서 여러 병렬 스레드로 확장할 수 있는 확장성을 제공한다고 설명합니다.

P Thread를 통해 여러 터미널 또는 샌드박스에서 동시다발적으로 에이전트를 실행해 처리량을 확장하는 방법을 설명합니다. 명령어 포크와 별도 프로세스를 활용한 Parallelism 구현 예시를 다룹니다.

[04:13] 터미널, git 작업 트리, 샌드박스에서 여러 작업 스레드를 동시에 실행할 수 있으며, 시간차를 두고 순차적으로 새로운 프롬프트를 작성하고 검토하는 워크플로우를 설명합니다.

[04:51] 클라우드 코드 창작자 보리스 처니의 실제 사례를 통해 업계 전반에서 병렬 스레드 작업이 일반화되고 있음을 보여주며, 그가 기본적으로 5개의 에이전트를 동시에 실행하는 효율적인 워크플로우를 소개합니다.

Boris Cherny가 클라우드 코드에서 5~10개의 에이전트를 병렬 실행하는 설정을 소개합니다. 터미널과 웹 인터페이스를 오가며 백그라운드 스레드를 관리하는 실전 사례를 확인합니다.

[05:37] 보리스는 터미널의 5개 클라우드 코드 외에도 웹 인터페이스에서 추가로 5-10개의 클라우드 코드를 더 실행하여 총 10-15개의 병렬 작업 환경을 구축한다고 설명합니다.

[05:48] Boris는 백그라운드에서 클라우드를 실행하며 @ 기호를 사용해 Cloud Code에서 Chrome 세션을 시작하고 자유롭게 이동합니다. 여러 작업 스레드를 추적하는 강력한 방법을 보여줍니다.

[06:03] 단일 작업 라인 실행 후 추가 작업 라인과 스레드를 시작할 수 있습니다. fork terminal 스킬 같은 도구로 새로운 터미널을 시작하고 분기를 만들 수 있습니다.

[06:20] pthread 도구를 사용해 Ralph Wiggum 구현을 검토합니다. 터미널을 포크하여 4개의 에이전트 인스턴스를 생성하고, 단일 프롬프트로 여러 작업 스레드를 병렬로 실행합니다.

[06:56] 4개 에이전트가 같은 프롬프트로 병렬 실행되며 코드베이스를 파악합니다. 일반 엔지니어보다 4배의 컴퓨트를 병렬화로 확보하여 리뷰 작업에 매우 유용한 P 스레드를 활용합니다.

C Thread는 대규모·고위험 작업(예: 마이그레이션)을 단계별로 의도적으로 분할해 검토·유효성 검사를 반복하는 패턴입니다. 시스템 알림과 사용자 입력 도구 활용 방안을 제시합니다.

[07:20] Boris의 클라우드 코드 방식 외에도, 같은 프롬프트를 실행하는 에이전트들로 응답 신뢰도를 높일 수 있습니다. 코드베이스 리뷰 실행이 좋은 활용 예시입니다.

[07:40] 반복 스레드는 병렬성으로 엔지니어링 아웃풋을 확장합니다. 프롬프팅 후 에이전트 작업 완료 후 검토하는 더 많은 스레드 실행 가능 여부가 발전의 지표입니다. 단일 에이전트 감시가 필요하다면 스레드를 줄여야 합니다.

[08:02] 6개 스레드 중 2개만 다뤘으며, 에이전트와 함께하는 엔지니어링과 능력 개선 방법을 보여드릴 예정입니다. 공통된 아이디어는 에이전트들이 대신 만드는 총 도구 호출 수를 증가시키는 것입니다. 기본 스레드와 P 스레드가 가장 일반적인 두 유형입니다.

[08:30] 스레드의 기본 개념을 설명하며, 전통적인 CPU 스레딩과 다른 새로운 에이전트 작업 방식을 소개합니다. 사용자가 시작과 끝에서 개입하는 작업 라인의 개념을 제시합니다.

[08:56] C스레드(체인 스레드)의 개념과 용도를 설명합니다. 대규모 다단계 계획을 의도적으로 청크 단위로 나누어 처리하는 방식으로, 에이전트 실수 때문이 아닌 전략적 선택임을 강조합니다.

[09:23] C스레드를 사용하는 두 가지 주요 이유를 제시합니다. 작업이 단일 에이전트 컨텍스트에 맞지 않거나, 고압적인 프로덕션 환경에서 각 단계의 정확성을 보장하기 위해 청크로 나누는 경우입니다.

[09:42] 50단계의 민감한 계획이나 마이그레이션 같은 고위험 프로덕션 작업의 예시를 들어 C스레드의 실용성을 설명합니다. 단계별로 계획하고 검토한 후 다음 단계로 진행하는 방식을 제시합니다.

F Thread는 동일하거나 유사한 프롬프트를 여러 에이전트에 보내 결과를 합성·집계하는 방법입니다. Rapid prototyping과 MROS 도구 활용 예시로, 품질과 신뢰도를 높이는 방식을 다룹니다.

[10:08] Claude 코드의 기능을 활용한 C스레드 구현 방법을 소개합니다. 사용자 질문 도구와 시스템 알림을 통해 워크플로우를 제어하는 Boris의 방식과 텍스트-투-스피치 훅을 활용한 개인적 경험을 공유합니다.

[10:44] C스레드의 장점과 한계를 균형있게 평가합니다. 프로덕션 민감 작업에 유용하지만, 에이전트 신뢰도 향상의 중요성과 시간-에너지 트레이드오프를 고려해야 한다고 조언합니다.

[11:15] C 스레드 사용 전 자기 점검 - 작업을 단계별로 나누어야 하는지 고민하고, 필요하다면 C 스레드를, 그렇지 않다면 기본 스레드를 사용하라고 조언합니다.

[11:28] F 스레드(퓨전 스레드) 소개 - 화자가 가장 좋아하는 스레드 유형으로, 퓨전 체인이라고도 불리며 2년 넘게 채널에서 다뤄온 패턴이라고 설명합니다.

[11:42] 퓨전 스레드 작동 원리 - 같은 프롬프트를 여러 에이전트에게 보내고, 모든 결과를 검토한 후 결합하고 융합하는 방식으로 작동합니다.

[11:55] 베스트 오브 엔드 패턴과의 연관성 - 이전에 다룬 여러 에이전트 중 최고를 선택하는 패턴을 전체 에이전트 작업 라인으로 확장한 개념입니다.

[12:08] 집계 방식의 다양성 - 항상 베스트 오브 엔드가 아니라 여러 에이전트에서 아이디어와 결과를 골라내어 우수한 결과를 만들 수 있다고 설명합니다.

[12:21] Pthread 도구 실습 - 터미널에서 Pthread를 세 개의 CC3 젬이나 코덱과 함께 사용하여 하나의 워크로드에서 여러 에이전트를 병렬처리하는 실제 예시를 보여줍니다.

B Thread는 에이전트가 다시 서브 에이전트를 호출하는 메타 구조입니다. Orchestrator 패턴을 활용해 팀 단위 워크플로우를 블랙박스로 운용하는 개념을 설명합니다.

[12:50] 빠른 프로토타이핑과 병렬화 - 화자가 현재 지속적으로 빠른 프로토타이핑을 하고 있으며, Pthread 기술이 이를 가능하게 해준다고 설명합니다.

[12:56] 퓨전 스레드의 프로세스 - P 스레드로 시작해서 베스트 이벤트 선택, 집계, 병합을 통해 융합시켜 최종 결과를 얻는 과정을 상세히 설명합니다.

[13:07] 9개 병렬 에이전트 실행 - 클라우드 코드 3개, 제미니 3개, 코덱 3개를 병렬로 실행하며 각각이 자체 에이전트 샌드박스를 가동하는 실제 구현을 보여줍니다.

[13:34] 에이전트 샌드박스의 장점 - 빠른 프로토타이핑, 여러 버전 실행, 솔루션의 다양한 분기를 통한 미래 전망이 가능하며, 더 많은 연산으로 빠른 실험을 할 수 있다고 강조합니다.

[13:48] 9개의 작업 라인이 동시에 실행되며, 완료 후 결과를 종합하고 결합하여 최적의 결과를 선택한다. 에이전트 샌드박스에서는 한두 개 버전을 선택해 조합한다.

[14:03] 퓨전 스레드의 핵심은 더 많은 에이전트가 작업을 시도할수록 성공 확률이 높아진다는 단순한 원리다. 더 많은 컴퓨팅 파워를 사용해 신뢰도를 높인다.

[14:23] 한 에이전트보다 다섯 에이전트에게 질문하면 훨씬 높은 신뢰도를 얻는다. 5개 중 4개가 같은 답을 주면 그 답변에 더 확신할 수 있다.

[14:35] 연구 에이전트들이 퓨전 스레드를 자주 사용하며, 서브 에이전트나 다중 웹 검색이 대표적인 예다. 이는 고급 에이전트 엔지니어링 영역으로, 대부분 엔지니어들이 경험하지 못한 분야다.

[15:08] 퓨전 스레드는 빠른 프로토타이핑의 최고봉이며, 미래의 빠른 프로토타이핑은 퓨전 스레드로 이루어질 것이라고 확신한다.

[15:25] B스레드(빅 스레드)는 메타 구조로, 프롬프트가 다른 프롬프트들을 실행한다. 서브 에이전트 실행이 가장 명확한 예시다.

[15:48] 에이전트가 다른 에이전트들에게 프롬프트를 보내면, 서브 에이전트들이 더 구체적이고 잘 정의된 작업을 수행한다. 계획-구축 워크플로우가 간단한 예시다.

[15:59] B스레드의 장점은 엔지니어 관점에서 단순히 프롬프트 실행 후 결과 검토만 하면 된다는 것이다. 내부 구조는 블랙박스로 숨겨져 있어 올바르게 엔지니어링되었다면 자동으로 실행된다.

L Thread는 수시간~수일에 걸친 장기간·고자율 스레드로, Stop Hook을 통해 중간 점검 및 재루프를 지원합니다. 프롬프트 고도화와 컨텍스트 관리가 핵심입니다.

[16:21] B 스레드의 핵심 개념을 설명합니다. 더 많은 컴퓨팅 파워를 배포하여 더 두꺼운 스레드를 만들고, 여러 스레드를 융합하여 특정 시간 내에 더 많은 작업을 처리할 수 있다고 합니다.

[16:40] 메타 구조에 대해 설명합니다. 큰 스레드가 여러 작은 스레드를 포함하는 구조이며, 핵심 패턴은 에이전트가 프롬프트를 작성해주는 것입니다. Claude Code에서 소개된 서브 에이전트 시스템을 예로 듭니다.

[16:57] 오케스트레이터 에이전트에 대해 설명합니다. 계획 에이전트, 정찰 에이전트, 빌드 에이전트, 리뷰 에이전트, 스테이징 에이전트 등으로 구성된 팀을 관리하는 개념을 소개합니다.

[17:20] B 스레드의 사용자 경험을 설명합니다. 사용자는 처음과 끝에만 관여하고, 내부적으로는 복잡한 에이전트 시스템이 작업을 처리한다고 합니다.

[17:48] B 스레드의 중요성과 강력함을 강조합니다. 단순한 에이전트 실행을 넘어서 코드와 에이전트를 결합하여 시간과 노력 대비 압도적인 수익을 얻을 수 있다고 설명합니다.

[18:07] Ralph Wiggum 패턴을 소개합니다. AI 엔지니어들이 에이전트와 코드의 조합이 에이전트 단독보다 뛰어나다는 것을 깨달았으며, 이는 특정 작업 수행을 위한 에이전트 루프라고 설명합니다.

[18:26] AI 개발자 워크플로우(ADW)에 대한 경험을 공유합니다. 1년 넘게 이 아이디어를 다뤄왔고, Jeff Huntley가 이를 대중화시킨 것에 대해 감사를 표합니다.

[18:49] 더 두꺼운 스레드를 만드는 방법을 제시합니다. 에이전트 팀 구축, 워크플로우 구축, 에이전트 워크플로우 생성, 다른 에이전트를 호출하는 프롬프트 작성 등을 언급합니다.

[18:58] 에이전트 전문화의 핵심은 기본 에이전트에게 올바른 도구 사용법을 가르치고 처음부터 끝까지 작업을 수행하도록 하는 것입니다.

[19:10] L 스레드는 인간 개입 없이 높은 자율성으로 장기간 실행되는 엔드투엔드 작업으로, 수백에서 수천 단계의 프롬프트를 몇 시간 또는 하루 이상 실행할 수 있습니다.

[19:41] Boris의 1일 2시간 실행 사례처럼, L 스레드는 Ralph Wiggum 플러그인을 활용하여 복잡한 프롬프팅 작업 대신 명확한 프롬프트와 적절한 도구로 장기 자율 워크플로우를 구현합니다.

[20:13] L 스레드는 기본 스레드와 같은 형태이지만 더 길고 많은 도구 호출을 통해 더 높은 자율성을 제공하며, 이는 더 나은 프롬프팅 기술과 모델, 컨텍스트 관리의 결과입니다.

개선 지표로 ‘스레드 수·길이·두께 증가’와 ‘인간 검토 단계 감소’를 제시하며, 총 여섯 가지 스레드를 활용해 측정과 개선을 반복하는 방법을 정리합니다.

[20:33] 핵심 4가지(컨텍스트, 모델, 프롬프트, 도구)를 이해하면 에이전트와 에이전틱 엔지니어링을 완전히 이해할 수 있으며, 더 긴 작업 스레드를 실행하는 엔지니어가 뛰어난 성과를 냅니다.

[21:01] Ralph Wiggum이 주목받는 이유는 에이전트가 문제에 대해 지속적으로 실행되어 더 많은 자율성과 긴 작업 체인을 구현할 수 있기 때문이며, 스톱 훅을 통해 이런 자율성을 조율할 수 있습니다.

[21:37] 스톱 훅은 매우 장기 실행 작업에서 Claude가 백그라운드 에이전트로 작업을 검증하거나, 여러 호출을 연결하여 작업 완료를 확인하는 중요한 메커니즘으로 앞으로 더 자세히 다룰 예정입니다.

궁극의 Z Thread는 인간 개입 없이 에이전트가 전 과정을 완수하는 개념입니다. 최종적으로 ‘스레드 기반 엔지니어링’이 미래의 소프트웨어 개발을 어떻게 이끌지 전망합니다.

[21:48] 스톱 훅(Stop Hook) 워크플로우에 대한 설명으로, 에이전트가 중단할 때 실행되는 결정론적 코드의 역할과 중요성을 강조합니다.

[22:12] 스톱 훅의 핵심 기능을 설명하며, 전통적인 코드와 에이전트를 연결하는 Claude Code 생태계의 강력함을 언급합니다.

[22:30] 스레드 기반 엔지니어링의 개념을 소개하며, 에이전트와 함께 작업하는 새로운 사고방식과 다양한 형태의 작업 스레드 연결에 대해 설명합니다.

[23:00] 에이전트 개선을 측정하는 핵심 지표로 도구 호출 수를 제시하고, 스레드 기반 엔지니어링 프레임워크의 4가지 개선 방법을 소개합니다.

[23:40] Boris의 실제 사례를 통해 병렬 스레드 실행의 효과를 보여주며, 5개의 Claude를 병렬로 실행하고 최대 10개의 스레드를 운영하는 강력한 확장성을 강조합니다.

[24:22] 보리스의 Claude 사용법과 에이전트 운영 방식을 소개합니다. 그는 Opus 4.5를 사용하고, 레포 크기를 적절히 관리하며, 터미널과 웹 인터페이스를 통한 인루프/아웃루프 에이전트 디코딩을 활용합니다.

[24:40] 보안 측면에서 그는 dangerously skip 대신 특정 권한 설정을 사용하며, 이는 단일 코드베이스 작업에 적합한 방법이라고 설명합니다. 병렬 스레드를 통한 다중 작업 실행이 핵심입니다.

[24:56] 클라우드 코드에서 좋은 결과를 얻는 가장 중요한 팁은 에이전트가 자신의 작업을 검증할 수 있는 방법을 제공하는 것입니다. 검증 루프나 폐쇄 루프 시스템을 만들어 피드백 루프를 구축해야 합니다.

[25:13] C스레드의 강점과 약점을 설명하며, 인간이 루프에 개입하는 횟수를 줄이는 것이 중요하다고 강조합니다. 중요한 시나리오에서는 개입이 필요하지만, 가능한 한 에이전트가 스스로 검증할 수 있는 도구를 제공해야 합니다.

[25:32] 에이전틱 엔지니어링 개선을 위한 네 가지 방법을 정리합니다: 더 많은 스레드 실행, 더 긴 스레드 실행, 더 굵은 스레드 실행, 인간 개입 체크포인트 감소. 구체적으로는 더 많은 터미널 창과 인루프/아웃루프 도구 활용을 제안합니다.

[26:02] 프로덕션 환경에서는 코드베이스 주변에 새로운 에이전틱 레이어를 구축하라고 권합니다. 특정 문제를 해결하기 위해 구축된 특별한 코드베이스를 운영하는 특별한 에이전트 세트가 필요하다고 설명합니다.

[26:33] 마지막 티저로 에이전틱 엔지니어링의 미래를 제시합니다. 에이전트에 대한 신뢰가 최대가 되면 검토 단계를 완전히 제거하는 숨겨진 일곱 번째 스레드인 'Z스레드(제로 터치 스레드)'의 개념을 소개합니다.

[27:02] 제로 터치 스레드(Z-thread)라는 개념을 소개합니다. 이는 에이전트에 대한 최대 신뢰를 의미하며, 엔지니어링의 미래를 보여주는 고급 개념입니다. 바이브 코딩이 아닌 매우 높은 수준의 에이전틱 코딩으로, 코드를 볼 필요가 없다는 것을 아는 최대 신뢰 단계입니다.

[27:41] Andrew Karpathy 같은 뛰어난 엔지니어들이 에이전트 시대에 적응하는 방법을 설명합니다. 모든 작업을 스레드로 생각하는 것이 핵심이며, 스레드는 시간에 걸쳐 엔지니어와 에이전트가 함께 수행하는 작업 단위입니다.

[27:56] 스레드 기반 엔지니어링의 작동 방식을 설명합니다. 처음에 프롬프트와 계획을 세우고, 중간에는 에이전트가 도구 호출을 통해 작업을 수행하며, 마지막에 검토하고 검증하는 구조입니다.

[28:06] 발전을 측정하는 방법들을 제시합니다. 스레드 추가, 더 긴 스레드 실행, 서로 다른 스레드 결과 결합, 그리고 스레드들을 조합하여 에이전트들이 자동으로 다른 에이전트들을 실행시켜 작업을 연결하도록 하는 것입니다.

[28:37] 모든 것이 네 가지 핵심 요소(컨텍스트, 모델, 프롬프트, 도구)로 귀결됨을 강조합니다. 발전을 위해서는 더 많고 긴 스레드를 실행하고, 중첩된 스레드로 두꺼운 스레드를 만들며, 사람의 개입 체크포인트를 줄여나가야 합니다.

[29:12] 에이전틱 엔지니어링이 새로운 기술임을 강조합니다. 처음에는 터미널에서 하나의 에이전트로 짧은 스레드를 실행하다가, 점차 Boris처럼 터미널과 클라우드에서 여러 에이전트를 동시에 실행하는 수준까지 발전하게 될 것입니다.

[29:34] 에이전트 엔지니어링의 한계까지 밀어붙이면 최종 스레드 레벨인 Z스레드에 접근할 수 있다고 설명합니다. 이는 택티컬 에이전틱 코딩의 핵심 개념이며 북극성 역할을 합니다.

[29:50] Z스레드는 제로 터치 스레드로, 더 이상 리뷰 노드가 없는 상태입니다. 화자는 에이전트의 작업을 검토할 필요 없이 그것을 넘어서서 확장하기를 원한다고 말합니다.

[30:08] 채널의 미션은 우리가 잠들어 있는 동안 작동하는 살아있는 소프트웨어를 구축하는 것입니다. 이는 수년간 변하지 않은 목표이며 매주 월요일마다 이를 향해 나아갈 것이라고 강조합니다.

[30:21] 소프트웨어 엔지니어링은 계속 변화해왔고 앞으로도 그럴 것이라고 말하며, 스레드로 생각함으로써 에이전트에게 더 많은 작업을 맡기고 계획과 검토에 집중할 수 있다고 설명합니다.

[00:00] 안녕하세요, 엔지니어 여러분! 앤디 데브단입니다.

[00:02] 간단한 핵심 질문이 하나 있습니다.

[00:05] 바이브 코더에서 실제 프로덕션에

[00:07] 배포하는 시니어 엔지니어로

[00:09] 발전하고 있다는 걸 어떻게 알 수 있을까요?

[00:11] 각 프롬프트마다, 에이전트로

[00:13] 배포할 수 있는 능력이 향상되고 있다는 걸

[00:16] 정말로 어떻게 알 수 있을까요? 심지어

[00:19] 우리 세대 최고의 엔지니어 중 한 명인

[00:21] 앤드류 카파시도 뒤처진다고 느끼고 있습니다.

[00:24] "프로그래머로서 이렇게 뒤처진다고 느낀 적이 없었다"고 말하죠.

[00:27] 이는 현재 일어나고 있는 더 큰 트렌드를 보여줍니다.

[00:29] 에이전트를 사용하는 엔지니어와

[00:31] 따라잡지 못한 엔지니어 사이의

[00:33] 격차가 점점 벌어지고 있다는 것이죠.

[00:36] 클로드 코드 창시자가 자신의

[00:38] 개인 설정을 공유하면서,

[00:41] 제가 2년 넘게 사용해온

[00:43] 새로운 사고 프레임워크에 대해

[00:45] 이야기하기 좋은 시기라고 생각했습니다.

[00:47] 이 프레임워크는 제가 에이전트를

[00:50] 운영화하여 지속적으로 개선할 수 있도록

[00:52] 도와주었습니다. 한 번의 단계로는 충분하지 않습니다.

[00:55] 어떻게 하면 매일매일

[00:57] 에이전트로 할 수 있는 일을

[01:00] 지속적으로 개선할지 생각해야 합니다.

[01:02] 한계가 계속 높아지고 있기 때문입니다.

[01:05] 여기서 공유할 이 프레임워크는

[01:06] 현재 에이전트 시대에 일어나고 있는

[01:09] 모든 것들 사이의 공통된 실마리를

[01:11] 제시합니다. 최고의 엔지니어들도

[01:13] 뒤처진다고 느끼고 있는 것부터 시작해서,

[01:15] 그런데 앤드류 카파시는

[01:17] 분명 문제없이 따라잡을 겁니다.

[01:19] 모든 최고의 엔지니어들은 한 가지

[01:21] 공통점이 있습니다. 바로 자기인식이 뛰어나다는 것입니다.

[01:24] 그가 이것을 스킬 문제라고 느낀다는 걸

[01:26] 알 수 있고, 그의 판단이 100% 맞습니다.

[01:29] 에이전틱 엔지니어링은 새로운 스킬입니다.

[01:32] 새로운 스킬에는 진전을 측정할

[01:34] 새로운 프레임워크가 필요합니다.

[01:37] 제가 공유할 이 사고 프레임워크는

[01:38] 랄프 위컴 기법과

[01:40] 보리스 처니 설정을 결합하여

[01:42] 여러분이 확실히 발전하고 있다는 걸 알 수 있는

[01:45] 구체적인 로드맵을 제공할 것입니다.

[01:47] 측정하지 않으면

[01:49] 개선할 수 없습니다. 그럼 이제

[01:51] 스레드 기반 엔지니어링을 소개해드리겠습니다.

[02:01] 그럼 스레드라고 할 때 무슨 뜻일까요?

[02:04] 여러분과 여러분의 에이전트가 이끄는

[02:06] 시간에 따른 작업 단위를 말합니다.

[02:09] 스레드에는 두 개의 필수 노드가 있습니다.

[02:12] 여러분이 프롬프트나 계획을 위해 나타나는 것과

[02:15] 검토나 검증을 하는 것입니다.

[02:17] 중간 부분은 여러분의 에이전트가

[02:20] 일을 하는 부분입니다. 이것들은

[02:22] 여러분의 에이전트가 만드는 개별 도구 호출들입니다.

[02:24] 시작은 여러분이 프롬프트하거나 계획하는 것입니다.

[02:26] 중간은 여러분의 에이전트가 일하는 것이고,

[02:28] 여기서 작업은 도구 호출의 연속입니다.

[02:30] 그리고 끝은 여러분이 검토하거나

[02:33] 검증하는 것입니다. 이건 매우

[02:34] 친숙해 보일 겁니다. 에이전트가 있는 도구에서

[02:37] 프롬프트에 엔터를 칠 때마다

[02:39] 작업의 스레드를 시작하는 것입니다.

[02:42] 여기서 매우 구체적으로 말씀드리겠습니다.

[02:44] 터미널을 열고 에이전틱

[02:46] 코딩 도구를 실행해서 프롬프트를 실행할 때마다,

[02:49] 이 코드베이스는 무엇에 관한 것인가요? 여러분은

[02:52] 새로운 작업 스레드를 시작하고 있는 것입니다.

[02:54] 방금 프롬프트를 실행했고 이제 제 에이전트가

[02:56] 작업을 수행하고 있습니다. 도구 호출 체인을

[02:58] 실행하고 있습니다. 이 경우에는 작업을 수행하기 위해

[03:00] 서브 에이전트를 실행하고 있습니다.

[03:02] 모든 도구 호출이 실행되고 있는 것을 볼 수 있습니다.

[03:03] 이것이 완료되면 작업을 검토해야 합니다.

[03:05] 그래서 당신과 제가 시작과 끝에 나타납니다.

[03:07] 10개의 도구, 21K 토큰입니다.

[03:09] 이제 요약을 제공할 것이고 이것이 우리가 작업을 검토하는 것입니다.

[03:12] 이 작업 라인, 이 스레드가 완료되었습니다.

[03:14] 이것이 제가 작업 스레드에 대해 말하는 것입니다.

[03:16] 그럼 왜 우리는 베이스 스레드에 관심을 가져야 할까요?

[03:19] 개선하는 데 필요한 모든 것을 제공하기 때문입니다.

[03:21] 여기서 핵심적인 통찰은

[03:23] 도구 호출에서 에이전트가 생성하는 가치를 측정할 수 있다는 사실입니다.

[03:25] 도구 호출은 대략 영향력과 같습니다.

[03:27] 유용한 것을 프롬프팅하고 있다고 가정할 때 말입니다.

[03:30] 2023년 이전에는 당신과 제가 도구 호출이었습니다.

[03:33] 우리가 코드를 업데이트하고 있었습니다.

[03:35] 우리가 읽고, 웹 요청을 수행하고 있었습니다.

[03:38] 모든 것을 우리가 하고 있었습니다.

[03:40] 하지만 모든 것이 바뀌었습니다.

[03:44] 이제 우리는 프롬프트로 시작에

[03:45] 검토로 끝에 나타납니다.

[03:47] 베이스 스레드는

[03:48] 시간에 따른 엔지니어링 작업의 단위를 나타냅니다.

[03:50] 당신과 에이전트에 의해 주도되는 것입니다.

[03:52] 베이스 스레드 자체는 그렇게 흥미롭지 않지만

[03:53] 여기서부터 하는 모든 것이 그 위에 구축됩니다.

[03:56] 하나의 스레드가 있으면 무엇을 할 수 있을까요?

[03:58] 맞습니다. 확장할 수 있습니다.

[04:00] 네. 확장할 수 있습니다.

[04:02] 병렬 실행입니다.

[04:04] 터미널에서

[04:07] 여러 작업 스레드를 동시에 실행하도록 설정할 수 있습니다.

[04:13] git 작업 트리에서, 샌드박스에서 말입니다.

[04:15] 보통 이것들은 시간에 걸쳐 분산됩니다.

[04:17] 이렇게 동기화해서 프롬프트를 시작할 수 있지만

[04:20] 종종 새로운 터미널이나 작업 트리

[04:22] 또는 어떤 프로세스를 시작하게 됩니다.

[04:24] 맞죠? 어떤 클라우드 아웃 오브 더 루프 에이전트

[04:26] 시간에 걸쳐 디코딩 도구를 사용하는 것입니다.

[04:28] 왜냐하면 모든 것을 동시에

[04:30] 검토하거나 프롬프팅할 수는 없기 때문입니다.

[04:35] 항상 시간에 따른 작은 변화가 있습니다.

[04:37] 여기 프롬프트가 있습니다.

[04:39] 그 작업 라인이 진행되면

[04:41] 다른 프롬프트를 작성할 수 있습니다.

[04:43] 그 작업 라인이 진행되면

[04:44] 또 다른 프롬프트를 작성할 자유가 생깁니다.

[04:45] 또는 계획하고 결국 검토합니다.

[04:47] 그리고 우리는 이것을 구체적으로

[04:48] 클라우드 코드의 창작자인 엔지니어 보리스 처니에게서 볼 수 있습니다.

[04:51] 이것이 지금 업계에서 일어나고 있는 모든 것과

[04:53] 어떻게 연결되는지 보죠.

[04:55] 모든 사람이 작업 스레드를 실행하고 있습니다.

[04:57] 보리스가 여기에 훌륭한 트윗을 올렸습니다.

[04:59] 그는 자신의 클라우드 코드의

[05:01] 바닐라 설정에 대해 이야기하고 있습니다.

[05:04] 비교적 간단하지만

[05:06] 여기에서 그가 P 스레드

[05:08] 병렬 스레드를 실행하고 있음을 볼 수 있습니다.

[05:10] 그는 터미널에서 5개의 클라우드 코드를 실행하고

[05:13] 탭을 1부터 5까지 번호를 매깁니다.

[05:16] 처음부터 보리스 처니는

[05:18] 여러 에이전트를 실행하는 것을 기대합니다.

[05:20] 의문의 여지가 없습니다.

[05:24] 그는 기본적으로 5개의 에이전트를 병렬로 실행합니다.

[05:26] 누가 더 많은 일을 하고 있을까요?

[05:27] 하나의 터미널에서 단일 에이전트를 시작하는 엔지니어

[05:30] 아니면 5개의 별도 터미널에서

[05:31] 5개의 에이전트를 실행하는 엔지니어일까요?

[05:34] 이것이 Pthread의 실제 모습입니다.

[05:37] 더 아래로 스크롤하면 그는 이것도 언급합니다.

[05:39] 그는 또한 클라우드 코드 웹 인터페이스에서

[05:41] 5개에서 10개의 추가 클라우드 코드를 실행합니다.

[05:43] 그래서 그는

[05:46] 백그라운드에서 클라우드가 실행되고 있고

[05:48] 백그라운드에서 클라우드가 실행되고 있고

[05:50] @ 기호를 사용해서 실행할 수 있어요

[05:52] Cloud Code에서 Chrome 세션을

[05:54] 시작하고 그 사이를 자유롭게 이동합니다

[05:56] 정말 멋지죠. 그리고 다시 한 번

[05:58] 여러 작업 스레드를 추적하고 있어요

[06:00] 이건 매우 강력한 방법입니다

[06:03] 단일 작업 라인이 실행된 후에는

[06:05] 추가 작업 라인을 시작할 수 있어요

[06:07] 맞죠? 작업 단위들을요

[06:09] 추가 스레드를 시작할 수 있습니다

[06:11] 저는 이걸 너무 자주 해서 fork terminal

[06:14] 스킬같은 도구들을 가지고 있어요

[06:16] 새로운 터미널을 시작하고

[06:18] 분기를 만들기 위해서요

[06:20] 그리고 이런 pthread 같은 도구도 있어요

[06:24] apps/star에 있는 Ralph Wiggum 구현을 검토하고

[06:27] 이걸 4개 실행하고 싶어요

[06:29] 터미널을 포크하고

[06:31] 새로운 프로세스를 시작할거예요

[06:34] Pthread 별칭이 있어요

[06:35] 여기서 할 일은

[06:38] 단일 프롬프트로 여러 작업 스레드를 시작하는 거예요

[06:40] 이걸 확인해보세요

[06:42] 터미널을 포크했고 이 에이전트의

[06:44] 4개 인스턴스가 생성되었어요

[06:46] 여러 다른 도구들과

[06:47] 여러 다른 스킬들을 결합해서 사용하고 있지만

[06:49] 아이디어는 간단해요. 에이전트들을 가지고

[06:51] 추가 에이전트들을 실행하는 명령을 실행할 수 있어요

[06:53] 여기서 하고 있는 건 4개 에이전트를

[06:56] 같은 프롬프트로 병렬로 실행하는 거예요

[06:58] 모두 이 코드베이스가

[07:00] 무엇을 하는지 파악하고 있어요

[07:02] 여기 위로 스크롤하면

[07:03] 이것들이 모두 개별 인스턴스라는 걸 볼 수 있어요

[07:05] apps에서 Ralph Wickham 구현을 검토하고 있어요

[07:07] 4개의 에이전트가 있어요, 맞죠?

[07:09] 일반 엔지니어가 하는 것보다 4배의

[07:11] 컴퓨트를 병렬화로 확보했어요

[07:12] 이게 P 스레드이고 더 많은

[07:15] 컴퓨트에 접근할 수 있게 해줘요

[07:18] 리뷰 같은 작업에 매우 유용해요

[07:20] Boris가 클라우드 코드를 사용하는 방식 외에도

[07:22] 1개에서 10개의 병렬 클라우드 코드를 실행해서

[07:24] 개별 작업 단위를 완성하는 것 외에도

[07:26] 정확히 같은 프롬프트를 실행하는

[07:28] 에이전트들을 실행해서

[07:31] 그들의 응답에 대한 신뢰도를 높일 수도 있어요

[07:33] 예를 들어, 제가 이런 도구를

[07:35] 사용하는 가장 좋아하는 방법 중 하나는

[07:37] 코드베이스 리뷰를 실행하는 거예요

[07:40] 반복 스레드는 병렬성을 통해

[07:42] 엔지니어링 아웃풋을 확장할 수 있게 해줘요

[07:44] 이게 여러분이 발전하고 있다는 걸

[07:47] 알 수 있는 구체적인 방법 중 하나예요

[07:49] 프롬프팅 후에 에이전트가

[07:51] 작업을 완료한 후 검토하는

[07:53] 더 많은 작업 스레드를 실행할 수 있나요?

[07:55] 만약 단일 에이전트를 계속 지켜봐야 한다면

[07:57] 아마 스레드를 줄이고

[07:59] 단일 작업 스레드에만 집중해야 할 거예요

[08:02] 이것은 이 영상에서 다룰 6개 스레드 중 2개에 불과해요

[08:06] 이것들을 살펴보면서

[08:07] 에이전트와 함께하는 엔지니어링에 대해

[08:09] 어떻게 생각할 수 있는지 보여드릴거예요

[08:11] 그리고 여러분이 할 수 있는 것들을 개선하는 방법도요

[08:13] 공통된 스레드가 있어요

[08:15] 이 모든 것들 사이에 공통된 아이디어가 있어요

[08:17] 맞죠? 결국 우리가 여기서 하고 있는 것은

[08:19] 에이전트들이 여러분을 대신해서 만드는

[08:21] 총 도구 호출 수를 증가시키는 거예요

[08:23] 기본 스레드와 P 스레드를 다뤘어요

[08:25] 가장 일반적인 두 가지 유형의 스레드죠

[08:30] 스레드는 에이전트와 함께 수행할 수 있는 가장 일반적인 두 가지 작업 라인입니다. 지금부터

[08:32] C, FB, L 스레드에 대해 다룰 예정입니다.

[08:33] 명확히 하자면, 우리가 얘기하는 것은

[08:36] 전통적인 CPU 프로세스 스레딩이 아닙니다.

[08:38] 이것들은 당신과 에이전트가

[08:41] 함께 수행하는 작업 라인으로, 프롬프트나 계획 단계에서는 당신이 시작하고

[08:44] 검토와 검증 단계에서는

[08:45] 당신이 마무리하는 방식입니다.

[08:47] 이는 에이전트와 함께

[08:49] 엔지니어링하는 새로운 사고방식입니다.

[08:51] 좋습니다. 이것은 에이전트와 함께

[08:53] 엔지니어링을 생각하는 새로운 방식입니다.

[08:56] 대규모 다단계 계획이 있다면 어떨까요?

[09:01] C스레드를 사용할 수 있습니다. C스레드는

[09:04] 이런 상황에 완벽합니다. 이는

[09:07] 연결 스레드입니다. 작업을

[09:08] 단계별로 연결할 수 있습니다. 이런 체크포인트들은

[09:11] 에이전트가 실수했기 때문이 아닙니다.

[09:14] 체인 스레드는 그런 게 아닙니다.

[09:16] 그건 잘못된 에이전트 코딩입니다.

[09:18] 제가 말하는 것은 의도적으로

[09:20] 작업을 청크 단위로 나누는 것입니다.

[09:22] 왜 C스레드를 사용할까요?

[09:23] 주요 이유가 두 가지 있습니다.

[09:25] 작업이 단일 에이전트의 컨텍스트 윈도우에

[09:28] 맞지 않을 수도 있고, 또는

[09:30] 고압적인 프로덕션 작업을 하면서

[09:32] 모든 단계가 정확하도록 청크로

[09:34] 나누고 싶을 수도 있습니다. 이는

[09:36] 큰 작업을 더 작은 조각들로

[09:38] 나누어야 할 때

[09:40] 주머니에서 꺼낼 수 있는 도구입니다.

[09:42] 매우 민감한 50단계 계획이 있고

[09:45] 한 가지라도 잘못되면 프로덕션에서

[09:47] 문제가 발생한다고 가정해보세요.

[09:49] 마이그레이션 같은 작업을 한다거나

[09:51] 고위험 프로덕션 레벨 작업을

[09:52] 수행한다고 하죠. 청크 단위로

[09:54] 실행할 수 있습니다. 하나의 작업 청크를

[09:57] 계획하고 검토한 다음, 검토 후에

[09:59] 해당 에이전트나 다른 에이전트와 함께

[10:01] 다음 단계 작업을 계속할 수 있고

[10:03] 3단계로 계속 진행할 수 있습니다.

[10:06] 이는 작업을 청크로 나누는 훌륭한 방법입니다.

[10:08] Claude 코드에는 사용자 질문하기

[10:11] 도구가 있어서 에이전트가 워크플로우 중간에

[10:12] 멈춰서 질문을 할 수 있습니다.

[10:15] 이는 C스레드에 훌륭합니다. 또한

[10:17] 시스템 알림을 사용할 수도 있는데

[10:19] Boris가 하는 방식입니다. 그는

[10:20] Claude 코드가 입력이 필요할 때

[10:23] 시스템 알림을 언급합니다. 방금 수행한

[10:25] 작업 청크를 완료했을 때

[10:27] 에이전트가 자연어를 사용해서

[10:29] 작업이 완료되었다고

[10:30] 소통하도록 할 수 있습니다. 제 코드베이스 일부에는

[10:33] 텍스트-투-스피치 훅이 실행되어서

[10:35] 에이전트가 작업을 요약하고

[10:37] 자연어로 다시

[10:39] 전달하도록 합니다. 다음 작업 단계를 위해

[10:41] 다시 루프에 들어가는 데 매우 유용합니다.

[10:44] C스레드가 이런 이유로 매우 강력합니다.

[10:46] 프로덕션 민감 작업에 훌륭합니다.

[10:48] 물론 이 채널에서는 항상

[10:50] 에이전트에 대한 신뢰를 높여서

[10:52] 인간이 루프에 개입하는

[10:54] 검토 단계를 줄이는 것에 대해 얘기합니다.

[10:57] 하지만 여전히 현실적이어야 합니다.

[10:59] 많은 프로덕션 작업들이 있고

[11:01] 이를 단일 단계로 분해해서

[11:04] 수행된 작업에 대한 신뢰를

[11:07] 높이고 싶습니다. 맞죠?

[11:09] 여기서 트레이드오프는 당신의

[11:10] 시간과 에너지입니다. C스레드는

[11:12] 정말로 신중하게 고려해야 할 첫 번째 스레드입니다.

[11:14] 이걸 사용하기 전에 스스로에게 질문해보세요.

[11:16] 이 작업을 단계별로 나누어야 할까요?

[11:18] 만약 그렇다면, C 스레드가 훌륭합니다.

[11:20] 그렇지 않다면, 기본 스레드만 사용하세요.

[11:27] 이제 F 스레드로 넘어가 봅시다.

[11:30] 이건 제가 가장 좋아하는 스레드 유형입니다.

[11:33] 이건 바로 퓨전 스레드입니다.

[11:34] 퓨전 체인이라고도 알려져 있죠.

[11:36] 이 패턴에 대해 2년 넘게

[11:38] 채널에서 다뤘는데, 지금보다

[11:39] 더 관련성이 높았던 적이 없었습니다.

[11:41] 아이디어는 간단합니다.

[11:43] 같은 프롬프트나 비슷한 프롬프트를

[11:46] 여러 에이전트에게 보냅니다.

[11:48] 그리고 모든 결과를 검토한 다음

[11:50] 그것들을 결합합니다.

[11:53] 집계하고 융합합니다.

[11:54] 이전 영상에서 우리는

[11:56] 베스트 오브 엔드 패턴에 대해

[11:58] 얘기했습니다. 여러 에이전트를 가동하고

[12:00] 가장 좋은 것을 선택하는 패턴이죠.

[12:02] 이것이 바로 그 패턴인데,

[12:04] 에이전트 작업의 전체 라인으로 확장한 것입니다.

[12:07] 이제 병렬처리뿐만 아니라

[12:08] 더 많은 연산을 사용해서 더 많은 에이전트를 가동하고

[12:10] 가장 마음에 드는 결과를 가져와서

[12:12] 결합시킵니다.

[12:14] 원하는 방식으로 집계할 수 있죠.

[12:16] 항상 베스트 오브 엔드가 아닙니다.

[12:18] 때로는 여러 다른 에이전트로부터

[12:21] 아이디어와 결과를 골라내어

[12:23] 우수한 결과를 얻고 싶을 때가 있습니다.

[12:24] 다시 말하지만, 저는

[12:25] 제 Pthread 도구로 이것을 항상 사용합니다.

[12:26] 터미널을 열어서 이런 식으로 프롬프트할 수 있습니다.

[12:30] 이미 준비해뒀으니까 그냥 붙여넣겠습니다.

[12:32] Pthread를 세 개의 CC3 젬이나

[12:35] 세 개의 코덱과 함께 사용하고

[12:38] 이 프롬프트를 사용합니다.

[12:40] 정확히 말하면,

[12:41] 하나의 워크로드 안에서 여러 에이전트를 실행하고

[12:43] 결과를 병렬처리합니다.

[12:46] 이것이 제가 에이전트를 사용하는 가장 좋아하는 방법 중 하나입니다.

[12:49] 그건 그렇고, 저는 지금

[12:51] 계속해서 빠른 프로토타이핑을 하고 있습니다.

[12:53] 그리고 제 Pthread 기술,

[12:54] 병렬화 기술이 이를 가능하게 해줍니다.

[12:56] 퓨전 스레드는 P 스레드로 시작해서

[12:58] 결과를 결합합니다.

[13:00] 베스트 이벤트를 선택하거나

[13:01] 집계하거나 결과를 병합하죠.

[13:03] 융합시켜서 마지막에

[13:05] 최종 결과를 얻습니다.

[13:07] 여기서 일어날 일은

[13:09] 제 에이전트가 9개의 에이전트를 병렬로 가동할 것입니다.

[13:11] 3개는 클라우드 코드를 실행하고,

[13:13] 3개는 제미니를 실행하고,

[13:15] 3개는 코덱을 실행합니다.

[13:18] 이 훌륭한 MROS 도구로

[13:19] 확인할 수 있습니다. 설명란에 링크 걸어드릴게요.

[13:21] 여러 에이전트를 가동했고

[13:24] 각각이 자체 에이전트 샌드박스를 가동할 것입니다.

[13:25] 과거에 채널에서 에이전트 샌드박스에 대해

[13:28] 얘기한 적이 있습니다.

[13:30] 관심 있으시면

[13:31] 그것들도 링크 걸어드릴게요.

[13:33] 에이전트 샌드박스는 훌륭합니다.

[13:35] 에이전트와의 신뢰를 위임할 수 있거든요.

[13:38] 이것이 빠른 프로토타이핑,

[13:40] 여러 버전을 실행하는 패턴입니다.

[13:42] 솔루션이 어떨 수 있는지에 대한

[13:44] 여러 분기로 미래를 내다보는 거죠.

[13:47] 다시 말하지만, 이건 제가 가장 좋아하는 스레드입니다.

[13:49] 정말 많은 것을 할 수 있고

[13:51] 더 많은 연산을 배치해서 빠르게 실험할 수 있거든요.

[13:53] 어쨌든, 이 에이전트들이

[13:54] 가동될 것입니다. 이건 제가 가동한 P 스레드입니다.

[13:56] 여러 작업 라인이 실행되고 있습니다.

[13:48] 기술적으로 지금 9개의 작업 라인이

[13:49] 실행되고 있습니다. 이들이 완료되면,

[13:51] 우리는 그것들을 종합하고, 결합하고,

[13:53] 최고의 것을 선택할 것입니다. 그리고

[13:55] 에이전트 샌드박스에서는 한두 개 버전을

[13:57] 가져와서 결합하여 우리가 찾고 있는

[14:00] 결과를 선택합니다. 여기서 핵심 통찰은

[14:03] 퓨전 스레드의 단순함입니다.

[14:05] 작업을 완료할 에이전트가 더 많으면

[14:06] 성공적으로 에이전트가 작업을 완료할

[14:08] 확률이 높아집니다, 맞죠? 단순히

[14:10] 문제에 더 많은 시도를 하는 것입니다.

[14:12] 퓨전 스레드는 통합을 통해 확장됩니다.

[14:14] 그리고 이 아이디어는 너무나 간단합니다.

[14:16] 여기서 우리는 더 많은 컴퓨팅을 사용해

[14:18] 더 많은 신뢰도를 얻습니다. 한 에이전트에게

[14:20] 질문을 하면, 뭔가 답변을 할 것입니다.

[14:23] 다섯 개에게 물어보면, 반환된 답변에

[14:24] 대해 훨씬 더 높은 신뢰도를 얻을 수 있습니다.

[14:27] 예를 들어, 5개 중 4개가

[14:29] 정확히 같은 답변을 주었다면, 당신은

[14:31] 그 답변에 더 확신을 가질 수 있습니다.

[14:33] 연구 에이전트들은 퓨전 스레드를

[14:35] 꽤 자주 사용합니다. 서브 에이전트를 사용하거나,

[14:37] 여러 버전을 스핀업하여

[14:39] 다중 웹 검색을 수행합니다.

[14:40] 이것이 가장 명백한 예입니다.

[14:42] 하지만 퓨전 스레드를 사용하는 다른

[14:44] 방법들이 많이 있습니다. 여기서

[14:46] 우리는 고급 에이전트 엔지니어링

[14:48] 영역으로 들어가기 시작합니다.

[14:50] 대부분의 엔지니어들은 여러 서브 에이전트를

[14:52] 스핀업하는 것 외에는 퓨전 스레드를

[14:54] 사용한 적이 없습니다. 이것은 절대적으로

[14:57] 퓨전 스레드의 예입니다. 거기서 큰 차이점은

[14:59] 당신의 주요 에이전트가 결과를

[15:02] 융합해 주는 것입니다. 따라서 그 작업이

[15:04] 어떻게 발생하는지 명확히 해야 합니다.

[15:05] 퓨전 스레드는 빠른 프로토타이핑의

[15:08] 최고봉입니다. 그리고 저는 이렇게

[15:10] 말씀드리겠습니다. 빠른 프로토타이핑의

[15:11] 미래는 퓨전 스레드로 수행될 것입니다.

[15:13] 제 말을 기억해 두세요. 저는 이 트렌드에

[15:15] 크게 베팅하고 있습니다. 이것이 F 스레드입니다.

[15:17] 이제 상황이 흥미로워지기 시작합니다.

[15:23] 이제 우리는 스레드로 확장하고

[15:25] 메타적으로 접근할 수 있습니다.

[15:27] 엔지니어링의 모든 것은 결국

[15:29] 자기 자신으로 돌아옵니다. 당신은

[15:32] 그것의 더 작은 조각들로

[15:34] 그것을 만듭니다. B스레드는, 빅 스레드라고도

[15:35] 알려져 있으며, 메타 구조입니다.

[15:37] 이제 당신의 프롬프트가 다른 프롬프트들을

[15:41] 실행합니다. 이것의 가장 명확한 예는

[15:43] 서브 에이전트를 실행하는 것입니다.

[15:45] 당신의 에이전트가 다른 에이전트들에게

[15:48] 프롬프트를 보낼 때, 그 서브 에이전트들은

[15:50] 더 구체적이고 잘 정의된 작업을

[15:53] 수행할 수 있습니다. 이것의 가장 간단한 예는

[15:55] 계획-구축 워크플로우입니다. 한 에이전트는

[15:57] 계획하고 다른 에이전트는 구축합니다.

[15:59] B스레드의 훌륭한 점은 엔지니어인

[16:01] 당신의 관점에서 보면 단순히

[16:03] 프롬프트를 실행하고 마지막에

[16:05] 검토하는 것입니다. 물론 당신은

[16:07] 내부에서 일어나는 모든 것을

[16:09] 에이전트 엔지니어링할 것입니다. 베이스 스레드,

[16:10] P 스레드, C 스레드, F 스레드 등

[16:12] 무엇을 하든 당신의 빅 스레드 내부에서

[16:14] 하는 모든 것은 당신에게 숨겨져 있습니다.

[16:16] 블랙박스입니다. 당신은 올바른 방법으로

[16:18] 엔지니어링했기 때문에 신경 쓰지 않고

[16:20] 그냥 실행될 것입니다

[16:21] 그래서 여기서 B 스레드의 핵심 아이디어는

[16:23] 여기에 더 많은 컴퓨팅 파워를 배포함으로써

[16:25] 더 두꺼운 스레드를 만드는 것입니다.

[16:27] 더 많은 스레드를 실행할 수 있고

[16:30] 스레드들을 융합하여

[16:32] 더 두꺼운 스레드를 만들 수 있습니다.

[16:35] 적절한 서브스레드를 배포하면

[16:37] 특정 시간 단위 내에서 더 많은 작업이 일어납니다.

[16:40] 이것이 메타 구조입니다.

[16:41] 큰 스레드가 여러 스레드를 포함하는 구조죠.

[16:44] 여기서 핵심 패턴은

[16:46] 프롬프트를 작성해주는 에이전트가 있다는 것입니다.

[16:48] Claude Code에서 소개된

[16:50] 첫 번째 버전이 바로 서브 에이전트입니다.

[16:52] 주 에이전트에게 서브 에이전트를 실행하도록 프롬프트하면

[16:55] 주 에이전트가 서브 에이전트들에게 프롬프트를 제공합니다.

[16:57] 우리 채널에서는

[16:58] 한 단계 더 높은 수준인

[17:01] 오케스트레이터 에이전트도 살펴봤습니다.

[17:03] 오케스트레이터 에이전트가 주 에이전트들을 시작시키는 구조죠.

[17:05] 더 많은 것들을 할 수 있지만

[17:07] 팀을 생각해보세요.

[17:08] 오케스트레이터 에이전트가

[17:10] 팀, 계획 에이전트, 정찰 에이전트를 시작시키고

[17:13] 그 다음 빌드 에이전트, 여러 리뷰 에이전트들

[17:15] 마지막으로

[17:17] 배포 전 스테이징 에이전트를 실행시킵니다.

[17:20] 그리고 마지막 단계에서 당신이 리뷰를 위해 들어와서

[17:22] 최종 실행을 시작하는 거죠.

[17:24] 이것이 B 스레드입니다.

[17:26] 내부에서는 많은 작업과 다른 작업 스레드들이 실행되지만

[17:28] 당신은 그것들에 신경 쓸 필요가 없습니다.

[17:29] 그것이 당신의 B 스레드가 관리할 부분이거든요.

[17:31] 당신의 관점에서는 프롬프트 하나로 한 스레드를 시작하고

[17:33] 끝에서 리뷰한 것뿐입니다.

[17:35] 처음과 끝에만 나타났지만

[17:36] 내부적으로는

[17:38] 당신의 에이전트 시스템이나

[17:40] 에이전트 팀들이 base P 실행을 조율했거나

[17:45] 아니면 물론 그 아래에 또 다른 B스레드를 실행했을 수도 있습니다.

[17:48] B스레드는 정말 중요하고

[17:49] 매우 강력합니다. 왜냐하면

[17:51] 단순히 에이전트를 실행하는 것을 넘어서

[17:53] 다른 차원으로 밀어내기 때문입니다.

[17:55] 코드와 에이전트를 결합하여

[17:58] 시간과 노력 대비 압도적인 수익을 얻는

[18:02] 아이디어로 이끌어갑니다.

[18:04] 그리고 정확히 그런 일을 하는

[18:06] 패턴이 나타나기 시작했습니다.

[18:07] 이제 우리에게는

[18:09] Ralph Wiggum 패턴이 있는데, 이는 사실상

[18:11] AI 엔지니어들이

[18:14] 에이전트와 코드의 조합이 에이전트 단독보다

[18:17] 뛰어난 성능을 낸다는 것을 깨닫기 시작한 것입니다.

[18:19] Ralph Wiggum은 말 그대로

[18:21] 특정 작업을 수행하기 위해

[18:22] 에이전트 위에서 실행되는 루프입니다.

[18:24] 좀 단순화한 설명이지만 그게 핵심 아이디어입니다.

[18:26] 우리는 이 아이디어를 1년 넘게 이야기해왔습니다.

[18:28] Principal AI 코딩과 Tactical 에이전트 코딩

[18:31] 두 강의 모두에 포함되어 있죠.

[18:33] 우리는 이것을 AI 개발자 워크플로우, ADW로 알고 있지만

[18:35] 이런 패턴이 정말로

[18:37] 주류로 떠오르는 것을 보니 정말 기쁩니다.

[18:39] 이 아이디어를 대중에게 전하고

[18:41] 정말로 확산시킨 Jeff Huntley에게 큰 박수를 보냅니다.

[18:44] 이것이 B 스레드입니다. 그런데 Ralph 이야기가 나온 김에

[18:46] 모든 것을 하나로 묶어주는

[18:49] 또 하나의 스레드가 있습니다. 그럼 어떻게 더 두꺼운

[18:51] 스레드를 만들 수 있을까요? 에이전트 팀을 구축하는 겁니다.

[18:53] 워크플로우를 구축하죠. 에이전트 워크플로우를 만드는 겁니다.

[18:55] 다른 에이전트를 호출하는 프롬프트를 만들고

[18:56] 서브 에이전트, 커스텀 에이전트를 구축합니다.

[18:58] 여기서 하는 일은 에이전트를 전문화하는 것입니다.

[19:00] 여러분의 기본 에이전트에게

[19:03] 올바른 도구 사용법을 가르치면

[19:04] 처음부터 끝까지 작업을 수행합니다.

[19:10] 이제 L 스레드로 다시 돌아갑니다.

[19:13] L 스레드는 높은 자율성을 가진

[19:16] 엔드투엔드 장기 작업입니다.

[19:19] 인간의 개입 없이

[19:21] 확장된 에이전트 자율성을 가집니다.

[19:23] 엄청나게 큰 프롬프트를 실행할 수 있고

[19:26] 수백, 수천 단계까지 이어질 수 있습니다.

[19:28] 몇 시간 동안 실행될 수도 있어요.

[19:30] Boris와 다른 엔지니어들이

[19:32] 몇 시간씩 프롬프트를 실행하는 것을 봤을 겁니다.

[19:34] 어떤 경우는 하루 이상도 걸려요.

[19:36] 그의 포스트 중 하나에서

[19:38] 장기 실행 사례를 보여줬는데

[19:41] 1일 2시간이었습니다.

[19:43] 정말 인상적인 장기 실행

[19:45] L 스레드였어요. 그는 여기서

[19:47] Ralph Wiggum 플러그인도 언급했는데

[19:49] 아이디어는 모두 동일합니다.

[19:52] 이전 단계들의 복잡한

[19:54] 프롬프팅 스레딩 작업은 모두 버리고

[19:56] 에이전트가 더 오래 실행될 수 있도록

[20:00] 적절한 도구를 갖춘 더 명확하고 나은 프롬프트를 작성하는 것입니다.

[20:02] 높은 자율성으로 매우 장기간

[20:04] 워크플로우를 실행하며

[20:06] 수많은 도구를 호출합니다.

[20:08] 수백, 수천 번의 도구 호출을 말하는 겁니다.

[20:10] 이것이 바로 L 스레드입니다.

[20:13] 이게 어떻게 생겼는지 보세요.

[20:15] L 스레드는 다시 원점인

[20:17] 기본 스레드로 돌아갑니다.

[20:19] 같은 형태지만 더 길고

[20:20] 더 많은 도구 호출을 합니다.

[20:22] 즉, 더 많은 자율성을 의미합니다.

[20:24] 여기서 특별한 것은 없어요.

[20:26] 우리가 프롬프팅을 더 잘하게 되고

[20:29] 더 나은 모델을 갖게 되었습니다.

[20:33] 컨텍스트를 더 잘 관리하고

[20:35] 우리의 도구가 그 노력을

[20:38] 앞으로 밀고 나가는 데 도움이 됩니다.

[20:40] 다시 한 번, 핵심 4가지인

[20:42] 컨텍스트, 모델, 프롬프트, 도구를

[20:45] 언급하고 있습니다.

[20:47] 핵심 4가지를 이해하면

[20:50] 에이전트와 에이전틱 엔지니어링을

[20:52] 이해하게 됩니다.

[20:54] 모든 것이 이것으로 돌아옵니다.

[20:57] 더 긴 스레드의 유용한 작업을 실행하는

[21:00] 엔지니어가

[21:01] 다른 사람들보다 뛰어난 성과를 냅니다.

[21:03] 에이전트가 더 오래 실행되도록

[21:06] 만드는 방법을 알아내는 데

[21:08] 엄청난 잠재력이 숨어있습니다.

[21:11] 여기서 훌륭한 계획이 효과를 발휘하는데

[21:13] 훌륭한 계획은 곧 훌륭한 프롬프팅이기 때문입니다.

[21:16] 그리고 물론 Ralph Wiggum이

[21:18] 지금 많은 관심을 받는 이유는

[21:20] 엔지니어들이 깨달았기 때문입니다.

[21:22] Boris도 이를 언급했어요.

[21:24] 에이전트가 해결하려는 문제에 대해

[21:26] 계속 실행되도록 할 수 있다면

[21:28] 더 많은 자율성으로

[21:30] 더 긴 작업 체인을 실행할 것입니다.

[21:33] 맞죠? 스톱 훅 같은 것으로

[21:35] 자율성을 어느 정도 조율하고 있더라도요.

[21:37] 이제 스톱 훅에 대해

[21:39] 좀 더 주목해보고 싶습니다.

[21:41] Ralph Wiggum이 다시 한번

[21:44] 훌륭한 아이디어라고 생각하고

[21:45] Boris도 이를 언급했습니다.

[21:47] 매우 장기 실행되는 작업을 위한 스톱 훅, L 스레드에서 Claude에게 백그라운드 에이전트로 작업을 검증하도록 프롬프트하거나 사실 이것은 C 스레드입니다. 작업을 완료한 후 작업을 검증하기 위해 다른 에이전트를 실행하거나 여러 호출을 연결하여 작업이 완료되었는지 확인하거나 에이전트 스톱 훅을 사용합니다. 이것은 매우 흥미로운 개념으로 에이전트 스톱 훅은 앞으로 더 자세히 다룰 예정입니다.

[21:48] 채널에서 더 자세히 다룰 예정입니다. 이 영상에는

[21:49] 넣고 싶지 않았지만, 워크플로우를

[21:51] 간략하게 보여드리고 싶었습니다.

[21:53] 에이전트가 중단하려고 하면 스톱 훅이

[21:55] 실행되고, 그다음에 여러분이

[21:57] 실행하는 결정 코드가 있습니다. 이것이

[21:58] 결정론적 코드입니다. 스톱 훅은

[22:01] 가로챌 수 있고, 코드를 실행할 수 있고,

[22:03] 진행 파일을 확인할 수 있고, 검증

[22:05] 명령을 실행할 수 있습니다. 그리고

[22:07] 다시 루프하거나 작업을 완료하는

[22:09] 워크플로우를 계속할 수 있습니다.

[22:11] 스톱 훅은 정말

[22:12] 중요합니다. 결정론적인 전통적 코드와

[22:14] 에이전트를 연결할 수 있게 해줍니다.

[22:17] 다시 말하지만, 만약 여러분이

[22:19] Tactical Agent Decoding 안에 있다면

[22:20] 이미 보셨을 것입니다. 이미

[22:22] 작업하고 계실 것입니다. 우리는 거기서

[22:24] 이것을 ADW라고 부릅니다.

[22:26] 스톱 훅은 Claude Code 생태계 안에서

[22:28] 이것에 접근할 수 있게 해줍니다.

[22:30] 매우 강력합니다. 이 모든 기법들이

[22:32] 우리에게 무엇을 제공하나요? 스레드 기반

[22:34] 엔지니어링은 에이전트와 함께

[22:36] 작업하는 방식에 대한 사고방법입니다.

[22:38] 프롬프트와 리뷰에 나타나지만, 이는

[22:41] 에이전트가 작업하는 엄청난

[22:42] 중간 시간이 있다는 것을 의미합니다.

[22:44] 이것은 추가적인 작업 스레드를

[22:46] 다양한 형태로 시작하고 다양한

[22:48] 방식으로 연결할 기회를 제공합니다.

[22:50] 여기에 6개의 스레드가 있습니다.

[22:52] 제가 본 것 중 가장 일반적이고

[22:54] 에이전트에서 빠르게 결과를 얻고

[22:57] 개선되고 있다는 것을 알기 위해

[22:58] 가장 중요한 것들입니다.

[23:00] 더 자세히 살펴보겠습니다. 우리는

[23:02] 이 모든 것을 시작했습니다. 어떻게

[23:03] 개선되고 있다는 것을 알 수 있는지

[23:05] 묻는 것으로 이 영상을 시작했습니다.

[23:06] 총 스레드 수, 스레드의 길이,

[23:08] 스레드의 크기 측면에서 개선을

[23:10] 생각할 수 있으며, 궁극적으로는

[23:12] 한 가지로 귀결됩니다. 에이전트와 함께

[23:14] 실행하는 도구 호출의 수입니다.

[23:19] 스레드 기반 엔지니어링 프레임워크를

[23:21] 염두에 두고 개선할 수 있는 구체적인

[23:23] 방법이 4가지 있습니다. 더 많은

[23:26] 스레드를 실행하거나, 더 긴 스레드를

[23:28] 실행하거나, 더 두꺼운 스레드를 실행하거나,

[23:32] 더 적은 휴먼-인-더-루프 체크포인트를

[23:34] 실행할 수 있습니다. 이렇게 하면

[23:36] 시스템에 대한 신뢰를 높이게 됩니다.

[23:38] 에이전트와 함께 엔지니어링할 때

[23:39] 개선할 수 있는 4가지 방법입니다.

[23:42] 에이전틱 엔지니어링에 대해 생각할 때

[23:44] 더 많은 스레드, 더 긴

[23:45] 스레드, 더 두꺼운 스레드, 또는

[23:47] 더 적은 체크포인트입니다. 그리고

[23:50] 이것을 볼 수 있습니다. 저에게

[23:52] Boris의 이 포스트는 그가 작업

[23:55] 스레드로 더 많은 것을 어떻게

[23:58] 하고 있는지 보여주기 때문에

[24:00] 매우 귀중합니다. 터미널에서 5개의

[24:03] Claude를 병렬로 실행하고 있습니다.

[24:05] 환상적입니다. 그리고 백그라운드에

[24:07] 두는데, 아마도 짧거나 중간에서 긴

[24:10] 실행 스레드일 것이지만, 더욱 더

[24:12] 확장하고 있습니다. 병렬로 돌아가면

[24:14] P 스레드, 여러 스레드를

[24:16] 실행하고 있습니다. 그의 포스트에

[24:18] 따르면 최대 10개의 스레드를 실행하고

[24:21] 있습니다. 매우 매우 강력하고

[24:22] 다른 주목할 점들이 있습니다. 그는 항상

[24:24] Opus 4.5를 사용합니다. 당연하죠. 레포에

[24:27] Claude를 두지만, 너무 크게 두지는

[24:28] 않습니다. 좋은 방법이죠. 그는

[24:30] 터미널 내부에서 인루프 에이전트 디코딩을

[24:32] 실행하고 있고, 클라우드 코드 웹

[24:34] 인터페이스로 아웃루프 에이전트

[24:36] 디코딩을 실행해서 자리를 비울 수 있습니다.

[24:38] 살펴보죠. 여기서 또 다른 점은? 흥미롭게도

[24:40] 그는 dangerously skip을 사용하지 않고

[24:42] 특정 권한을 설정합니다. 이게 맞다고

[24:44] 생각해요. 하나의 코드베이스에서

[24:46] 대부분의 작업을 한다면 말이죠.

[24:48] 전반적으로 보면 그는 여러 작업

[24:49] 스레드를 실행하고 있습니다. 특히 병렬

[24:51] 스레드들을 말이죠.

[24:53] 그리고 여기서 그의 마지막 팁이 클라우드

[24:56] 코드에서 좋은 결과를 얻는

[24:57] 가장 중요한 것입니다. 작업을 검증할 수 있는

[24:59] 방법을 제공하는 것이죠. 본질적으로

[25:01] 검증 루프나 폐쇄 루프 시스템을

[25:04] 만드는 것입니다. 피드백 루프를 만들어서

[25:05] 에이전트가 자신의 작업을 스스로 해결할 수 있게 하는 거죠.

[25:08] 이는 C스레드의 강점과

[25:10] 약점을 모두 보여줍니다. 루프에

[25:13] 뛰어들고 싶지는 않을 겁니다.

[25:14] 사실 이는 개선할 수 있는

[25:16] 네 가지 방법 중 하나입니다. 에이전트의

[25:18] 작업을 검토해야 하는 횟수를 줄이는 것이죠.

[25:20] 다시 말하지만, 루프에 개입해서

[25:22] 에이전트가 올바른 일을 했는지

[25:24] 확인해야 하는 중요한 시나리오들이

[25:25] 있지만, 가능한 한 에이전트에게

[25:27] 자신의 작업을 검증할 수 있는 도구를

[25:29] 제공하는 것이 좋습니다. 좋습니다.

[25:32] 다시 정리하면, 엔지니어링을 개선하는

[25:34] 네 가지 방법: 더 많은 스레드를 실행하고,

[25:37] 더 긴 스레드를 실행하고, 더 굵은 스레드를 실행하고,

[25:39] 인간 개입 체크포인트를 줄이는 것입니다.

[25:42] 이게 조금 추상적이라는 건 알고 있습니다.

[25:44] 어떻게 더 많이, 더 길게, 더 굵게, 또는 더 적게

[25:46] 실행하는지에 대한 자세한 내용이 부족하지만

[25:48] 아이디어는 명확합니다. 더 많은 터미널

[25:50] 창을 띄우세요. 인루프 에이전트 디코딩

[25:53] 도구와 아웃루프 에이전트 코딩 도구를

[25:56] 준비하세요. 물론 보리스는 클라우드 코드와

[25:59] 클라우드 코드 웹 인터페이스를 사용합니다.

[26:00] 원하는 것은 무엇이든 사용할 수 있습니다.

[26:02] 저는 항상 프로덕션 자산에 대해서는

[26:04] 코드베이스 주변에 새로운 에이전틱 레이어를

[26:07] 구축하라고 권합니다. 이것이 전술적

[26:09] 에이전틱 코딩의 핵심 주제 중 하나입니다.

[26:11] 왜 그렇게 말할까요? 특정 문제를 해결하기 위해

[26:14] 구축된 특별한 코드베이스를

[26:15] 운영하는 특별한 에이전트 세트가

[26:18] 필요하기 때문입니다. 이것들이

[26:20] 에이전틱 엔지니어링을 개선하는

[26:22] 네 가지 방법이며, 하는 모든 일을

[26:25] 작업 스레드로 보는 관점입니다.

[26:27]

[26:33] 마지막으로 하나의 스레드를 더 공유하고

[26:36] 싶습니다. 여러분을 위한 티저 스레드죠.

[26:38] 에이전틱 엔지니어링이 너무 높은 수준으로

[26:39] 발전해서 에이전트들을 멀리 밀어내고

[26:42] 그들이 모든 작업을 검토하고

[26:44] 엄청나게 많은 일을 해내게 될 때

[26:47] 무슨 일이 일어날까요? 엔지니어링의

[26:49] 미래는 무엇일까요? 에이전트에 대한

[26:50] 신뢰를 최대로 높이면

[26:52] 어떤 일이 일어날까요? 검토 단계를

[26:54] 완전히 날려버리는 거죠. 숨겨진

[26:56] 일곱 번째 스레드가 있습니다.

[26:59] 저는 이것을 Z스레드라고 부릅니다. 제로

[27:02] 터치 스레드입니다. 이것은

[27:03] 에이전트에 대한 최대 신뢰를 의미합니다.

[27:05] 지난주나 몇 주 전에 올린 특이점

[27:08] 비디오에서 이것을 살짝 언급했는데

[27:09] 엔지니어링의 미래에 대한 큰 아이디어입니다.

[27:11] 이 부분에 대해서는 자세히

[27:13] 다루지 않을 건데, 왜냐하면

[27:14] 전술적 에이전트 코딩의 고급 레슨

[27:16] 후반부에서 다루는 핵심 아이디어 중 하나이고

[27:19] 많은 엔지니어들이 이것이

[27:21] 가능하다는 것을 믿지 않기 때문입니다.

[27:23] 특히 신입 엔지니어들이

[27:24] 이것을 바이브 코딩이라고

[27:26] 혼동하는 것을 원하지 않습니다.

[27:28] 이것은 바이브 코딩이 아닙니다. 이것은 매우

[27:30] 높은 수준의 매우 고급 에이전틱

[27:32] 코딩입니다. 이것은 최대 신뢰이며

[27:35] 코드를 보지 않는다는 것이 아니라

[27:37] 볼 필요가 없다는 것을 아는 것입니다.

[27:39] 그것이 바로 엔드게임입니다. 이제 원점으로

[27:41] 돌아가 보겠습니다. Andrew Karpathy 같은

[27:44] 뛰어난 엔지니어들이 우리가 살고 있는

[27:47] 에이전트 시대에 어떻게 따라갈 수 있을까요?

[27:48] 모든 작업을 스레드로 생각할 수 있습니다.

[27:51] 스레드는 시간에 걸쳐 당신과

[27:54] 에이전트가 수행하는 엔지니어링 작업 단위입니다.

[27:56] 처음에는 프롬프트를 주고 계획을 세우고

[27:58] 에이전트가 완료하면 검토하고 검증합니다.

[27:59] 중간에는 에이전트가 도구 호출을 통해

[28:01] 작업을 수행합니다. 이것이

[28:03] 스레드 기반 엔지니어링입니다. 그렇다면

[28:06] 어떻게 발전하고 있다는 것을 알 수 있을까요?

[28:07] 다음 중 하나를 할 수 있기 때문에

[28:09] 발전하고 있다는 것을 알 수 있습니다. 스레드를 추가할 수 있고

[28:11] 더 긴 스레드를 실행할 수 있으며, 서로 다른

[28:14] 작업 스레드의 결과를 결합할 수 있습니다.

[28:16] 그리고 스레드들을 조합하여

[28:18] 프롬프트와 검토 단계에서만 나타나면서

[28:20] 에이전트 작업 사이에 추가 스레드가

[28:22] 실행되도록 할 수 있습니다. 즉, 에이전트들이

[28:24] 다른 에이전트들을 실행시켜서

[28:26] 작업을 완료하고 연결합니다.

[28:28] 그리고 마지막에는 더 긴 스레드를

[28:30] 실행합니다. 이는 뛰어난 에이전틱

[28:32] 프롬프트 엔지니어링과 뛰어난 컨텍스트

[28:35] 엔지니어링을 학습함으로써 가능합니다. 결국

[28:37] 모든 것은 네 가지 요소로

[28:40] 귀결된다는 것을 기억하세요. 핵심 네 가지는

[28:43] 컨텍스트, 모델, 프롬프트, 그리고 도구입니다.

[28:46] 이 여섯 가지 스레드를 기초로

[28:48] 사용할 수 있습니다. 하지만 핵심 아이디어는

[28:51] 발전하려면 더 많은 스레드를 실행하고

[28:53] 더 긴 스레드를 실행하며

[28:55] 중첩된 스레드가 있는 더 두꺼운

[28:57] 스레드를 실행하고, 사람이 개입하는

[28:59] 체크포인트를 줄여나가는 것입니다.

[29:01] 왜냐하면 신뢰할 수 있는 시스템을 구축했고

[29:03] 더 나은 모델, 더 나은 도구

[29:05] 더 나은 컨텍스트를 사용하며

[29:07] 더 나은 프롬프트를 작성하고 있기 때문입니다.

[29:10] 기억해야 할 가장 중요한 것은

[29:12] 에이전틱 엔지니어링 또는

[29:13] 에이전트를 활용한 엔지니어링이

[29:15] 새로운 기술이라는 것입니다. 처음에는

[29:17] 터미널에서 하나의 에이전트로 짧은 작업

[29:19] 스레드를 실행하게 될 것입니다. 그러다가 어느새

[29:21] Boris처럼 터미널에서 다섯 개의

[29:23] 에이전트를 실행하고 클라우드 어딘가에서

[29:25] 다섯 개를 더 백그라운드로 실행하게 될 것입니다.

[29:27] 더 많은 스레드를 추가하고

[29:29] 더 두껍게 만들고 더 오래

[29:30] 실행하도록 만들 것입니다. 그러다가

[29:32] 에이전틱 엔지니어링의 끝까지 밀어붙이면

[29:34] 에이전트 엔지니어링의 한계까지 밀어붙이면

[29:36] 마침내 최종 스레드 레벨에 접근하게 됩니다

[29:38] 바로 Z스레드입니다. 이것은

[29:41] 택티컬 에이전틱 코딩에서 우리가 말하는

[29:43] 거대한 아이디어의 북극성을 나타냅니다

[29:45] 관심 있으시면 설명란에 링크를 남겨두겠습니다

[29:47] 관심이 있으시다면요

[29:48] 하지만 결국 우리는

[29:50] Z스레드, 즉 제로 터치 스레드를 실행하는 것입니다

[29:52] 더 이상 리뷰 노드가 없습니다. 이것이

[29:55] 여러분이 추구해야 할 방향입니다. 이것이

[29:56] 저와 다른 최고 엔지니어들이

[29:58] 추구하는 방향입니다. 저는 더 이상

[30:01] 에이전트의 작업을 검토하고 싶지 않습니다. 저는

[30:03] 그것을 넘어서고, 그것을 뛰어넘어 확장하고 싶습니다

[30:05] 알겠죠? 저는 이 채널의 미션을

[30:08] 달성하고 싶습니다. 바로

[30:09] 우리가 잠들어 있는 동안 우리를 위해 작동하는

[30:12] 살아있는 소프트웨어를 구축하는 것입니다. 그것이

[30:14] 수년간의 미션이었습니다. 그것은 변하지 않았고, 우리는

[30:16] 매주 그 목표를 향해 나아갈 것입니다

[30:17] 여기서 매주 월요일마다요. 이것이

[30:19] 엔지니어링의 미래입니다. 그러니 그것을 향해 나아가세요

[30:21] 두려워하지 마세요. 도망가지 마세요

[30:23] 소프트웨어 엔지니어링은

[30:25] 계속해서 변화해왔고 앞으로도 계속 변화할 것입니다

[30:27] 하지만 스레드로 생각함으로써

[30:30] 여러분이 발전하고 있다는 것을 알 수 있습니다

[30:32] 왜냐하면 여러분은 에이전트에게 더 많은 일을 맡기고

[30:34] 가장 중요한 곳인 계획과

[30:36] 검토에서 여러분의 역할을 하고 있기 때문입니다. 만약

[30:38] 여러분의 영향력을 확장하고 싶다면

[30:40] 여러분의 컴퓨팅 파워를 확장해야 합니다. 만약

[30:43] 여러분이 할 수 있는 것을 더 멀리 밀어붙이고

[30:45] 에이전틱 엔지니어링이라는 새로운 역할로의

[30:47] 여정을 빠르게 추진하고 싶다면

[30:50] 택티컬 에이전틱 코딩을 확인해보세요. 설명란에 링크가 있습니다

[30:52] 항상 그렇듯이 다음 월요일에 뵙겠습니다

[30:54] 집중력을 유지하고 계속 만들어가세요

[30:57]