클로드 코드의 다이나믹 워크플로우는 딥리서치와 울트라코드를 같은 계열의 기능으로 묶지만, 목적과 실행 방식은 꽤 다르다. 이 영상은 일반 채팅, 스킬, 서브에이전트, 배치, 딥리서치, 울트라코드, 골까지 한 줄로 세워 놓고 각각이 어떤 문제를 풀 때 맞는지 개발 실무 관점에서 정리한다.
flowchart LR A[클로드 코드 기능이 많아져 헷갈림] --> B[딥리서치와 울트라코드의 포지셔닝 정리 필요] B --> C[다이나믹 워크플로우와 Goal까지 구조 비교] C --> D[작업 성격에 맞는 기능 선택 기준 정리]
핵심 요약
- 딥리서치는 리서치용, 울트라코드는 코드 생성용으로 설명되며 둘 다 요청을 받은 뒤 메인 에이전트가 계획과 페이즈를 동적으로 만든다.
- 일반 채팅은 첫 응답에서 끝나기 쉬운 반면, 다이나믹 워크플로우는 조사·검증·재조사·수정의 루프를 돌며 결과물을 만든다.
- 딥리서치 데모에서는 검색 목표를 나눈 뒤 병렬 에이전트 5개를 생성해 자료를 모으고, 이후 더 많은 검증 단계를 거쳐 마지막 리포트를 만든다.
- 울트라코드는 빠른 병렬 실행과 반복 수정에 초점을 두고, Goal은 실패하더라도 최대한 오래 붙들고 해결하려는 쪽에 가깝다고 설명한다.
- 리팩터링이나 프레임워크 전환은 울트라코드, 복잡한 Redis 캐싱 레이어처럼 성공 조건을 정확히 걸 수 있는 작업은 Goal이 더 어울린다고 예시를 든다.
왜 지금 중요한가
영상의 핵심은 기능 이름을 외우는 게 아니라, 어떤 작업에 어떤 실행 구조를 붙일지 결정하는 기준을 세우는 데 있다. 특히 소프트웨어 엔지니어라면 작업 난이도와 검증 가능성을 알고 있기 때문에, 일반 채팅으로 끝낼지 다이나믹 워크플로우나 Goal로 올릴지 빠르게 판단할 수 있다는 점을 강조한다.
주요 내용
1. 다이나믹 워크플로우는 정적인 하네스 대신 실행 중에 구조를 만든다
[00:32]부터 설명하는 핵심은 워크플로우가 미리 고정돼 있지 않다는 점이다. 사용자가 리서치 요청이나 코드 변경 요청을 넣으면, [01:19] 메인 에이전트가 먼저 목적을 듣고 [01:23] 작업 방법을 리서치하고 계획을 세운다. 그리고 [01:28] 페이즈별로 나눈 뒤 각 페이즈에서 무엇을 조사하고, 무엇을 만들고, 어떤 결과물을 내야 하는지 정의한다. 영상은 이 구조를 기존의 정적인 하네스와 대비한다. 정적인 하네스는 계속 손으로 바꿔야 해서 [01:01] 프로젝트보다 하네스를 만지는 일이 더 커질 수 있다는 문제를 짚는다.
2. 딥리서치는 병렬 수집과 검증 루프를 중심으로 돈다
[01:52] 이후 설명하는 딥리서치 흐름은 꽤 명확하다. 먼저 조사하고, 검증하고, 더 조사할 게 있으면 다시 돌아가고, 끝나면 리포트를 낸다. 영상은 일반 채팅이 [02:09] 사실상 첫 단계에서 끝나는 것과 대비하면서, 딥리서치는 검증과 재탐색이 포함된다고 말한다. 데모 구간에서는 [03:09] 병렬 에이전트 5개를 생성해 하나의 검색 페이즈를 처리하고, 각 에이전트가 무엇을 했는지와 아웃컴까지 확인할 수 있다고 보여준다. 이후 [03:49] 검증 단계에서는 더 많은 에이전트가 필요하다고 설명하며, [04:09] 소스별로 너무 많은 정보를 세 개씩 쪼개 독립 검증한 뒤 [04:17] 다시 모아 리포트를 만든다고 정리한다. 리포트 생성은 [04:24] 컨텍스트 때문에 혼자 한다는 설명도 붙는다.
3. 울트라코드는 빠른 전진, Goal은 집요한 완수에 가깝다
영상 후반부는 울트라코드와 Goal의 차이를 가장 길게 다룬다. [15:02] 울트라코드는 워크플로우를 만들고 병렬 실행을 돌려 “굉장히 빠르게 목적을 이룰 수 있도록” 움직이는 쪽으로 설명된다. 반대로 Goal은 [13:45] 일반 채팅보다 더 정직하게 답하고, 실패해도 쉽게 포기하지 않으며, [14:01] “최대한 내가 해결해 보려고 계속 노력”하는 구조라고 말한다. [15:31] 메인 에이전트 하나가 집착에 가까울 정도로 명령을 붙드는 이미지로 설명하면서, [15:39] 성공하거나 “죽을 때까지” 하는 느낌이라고 비유한다. 즉, 울트라코드는 속도와 병렬성, Goal은 완수 집착과 지속성 쪽에 무게가 있다.
4. 기능 선택 기준은 작업의 검증 방식과 실패 허용도다
실전 선택 기준도 꽤 구체적이다. [15:52] 기본적으로는 울트라코드를 추천하는데, 이유는 [15:55] 작업 완료 속도에 더 포커스가 맞춰져 있기 때문이다. 예시로 [16:28] 리팩터링이나 프레임워크 변경은 울트라코드가 어울린다고 한다. 약간의 에러가 있더라도 [16:39] 일단 빨리 전환하고 앞으로 나가는 것이 중요하다는 맥락이다. 반대로 Goal은 [16:46] 새로운 소스 통합, [16:49] Redis를 사용한 캐싱 레이어처럼 연동 포인트, 검증 방식, 배포 후 동작, 알고리즘까지 함께 따져야 하는 복잡한 작업에 더 적합하다고 설명한다. [17:04] 성공 조건을 정확히 넣어 두고 될 때까지 밀어붙이는 방식이 유용하다는 것이다.
원문 발화 하이라이트
- [00:38] “딥리서치는 당연히 리서치를 하는 형태고 울트라 코드는 당연히 코드를 생성하는 목적을 갖고 있다라고 보시면은 돼요.”
- [01:23] “이거를 어떻게 작업을 해야 될지 리서치하고 계획을 세웁니다.”
- [03:09] “병렬로 다섯 개 에이전트를 생성해 가지고 작업을 한 거를 볼 수가 있어요.”
- [14:01] “골 같은 경우에는 최대한 내가 해결해 보려고 계속 노력을 하고요.”
- [16:28] “예제로 들면은 울트라코드는 저 같으면 뭐 리팩터링이라든가 아니면은 뭐 진짜 아까처럼 프레임워크로 뭐 변경을 한다거나 그런 거는 저는 무조건 울트라 코드를 쓸 것 같고요.”
바로 실행해 보기
- 지금 진행 중인 일 하나를 적고, 그 일이 리서치 중심인지 코드 생성 중심인지 먼저 나눠 본다. 영상 기준대로 조사와 검증 루프가 핵심이면 딥리서치 후보로, 빠른 구현과 수정 반복이 핵심이면 울트라코드 후보로 분류해 본다.
- 작업을 바로 던지지 말고 페이즈를 먼저 써 본다. 예를 들어 조사 → 자료 수집 → 검증 → 결과물 생성처럼 나눈 뒤, 각 페이즈에서 어떤 결과물이 나와야 하는지 한 줄씩 적어 보면 다이나믹 워크플로우에 태울 준비가 된다.
- 복잡한 통합 작업에서는 성공 조건을 먼저 써 본다. 영상의 Redis 캐싱 레이어 예시처럼 연동할 대상, 검증 방법, 배포 후 기대 동작, 알고리즘 판단 포인트를 적은 다음, 이 조건을 끝까지 밀어붙여야 하는 작업인지 보고 Goal 사용 여부를 정한다.
참고
영상 메타
- 채널: 코드팩토리 Code Factory
- 제목: 클로드 코드 Dynamic Workflow 기능 비교 총정리!
- 게시 시각(원문): 2026-06-03T10:45:06+00:00
- 영상: https://www.youtube.com/watch?v=9fx2_1aTzq8
- 썸네일: https://i2.ytimg.com/vi/9fx2_1aTzq8/hqdefault.jpg
수집 품질
- 자막 세그먼트: 564개
- 자막 문자수: 10299자
- 챕터 추출: 6개
- 콘텐츠 생성: Subagent 기반
AI 생성 도구를 활용해 초안을 구성했고, 원영상 발화와 공개 자료를 교차 확인해 정리했습니다.