소개

워크플로는 순서대로 실행되는 단계의 목록입니다. 어떤 단계는 무언가를 가져오거나 읽고, 어떤 단계는 모델에 처리를 맡기고, 어떤 단계는 결과를 저장하거나 알려 줍니다. 각 단계는 앞선 단계가 만든 결과를 사용할 수 있으며, 목록 전체를 직접 실행하거나, 일정에 따라 실행하거나, 피드나 폴더에 새로운 것이 생길 때마다 실행할 수 있습니다.

이 튜토리얼에서는 자신이 의존하는 도구의 릴리스를 지켜보는 워크플로를 만듭니다. 예제로는 Python 패키지 관리자 uv를 씁니다. 릴리스가 잦고 릴리스 노트도 자세하기 때문입니다. 새 릴리스가 나올 때마다 워크플로가 릴리스 노트를 읽고, 저렴한 모델에 짧은 요약을 요청하고, 요약을 저장하며, 호환성이 깨지는 변경이 있을 때만 데스크톱 알림을 보냅니다. 안전하게 테스트하고, 각 단계가 무엇을 했는지 읽어 보고, 전체를 다시 실행하지 않고 한 단계만 고친 다음, 혼자 실행되도록 승인하게 됩니다.

GitHub의 어떤 프로젝트로든 따라 할 수 있으며, 바뀌는 것은 피드 주소뿐입니다.

핵심 요약

• 워크플로는 직접 시작하거나, 일정에 따라(매일, 평일, 몇 시간마다) 시작하거나, RSS 또는 Atom 피드에 새 게시물이 올라오거나 폴더에 새 파일이 생길 때 시작할 수 있습니다.
• 단계끼리는 메뉴에서 삽입하는 값으로 결과를 주고받습니다. 게시물의 링크나 이전 단계가 만든 텍스트 같은 것입니다.
• 모델을 쓰는 각 단계는 자신의 모델을 따로 고를 수 있으므로, 반복 작업은 빠르고 저렴한 모델에 맡길 수 있습니다.
• …인 경우에만 계속 단계는 주의를 기울일 만한 것이 없을 때 실행을 조용히 끝냅니다.
• 워크플로가 혼자 실행되기 전에, 허용될 모든 작업의 목록을 보여 주며 사용자가 그 목록을 승인합니다. 그 이상의 작업이 필요하면 실행이 멈추고 묻습니다.
• 모든 실행은 각 단계가 한 일을 기록하며, 앞선 단계를 반복하지 않고 어느 단계에서든 다시 실행할 수 있습니다.
• 같은 워크플로를 캔버스로 그려 볼 수 있고, 조건에 따라 분기하고 단계를 나란히 실행할 수 있으며, 행동하기 전에 묻는 에이전트에게 일을 넘길 수 있습니다.

준비 사항

이 튜토리얼을 따라 하려면 다음이 필요합니다.

• Conduit 설치 (Windows, macOS, Linux). 릴리스 페이지에서 최신 릴리스를 내려받으세요.
• Conduit에 설정된 모델 제공업체와 사용자의 API 키. 이 튜토리얼은 요약에 OpenRouter를 통한 GLM 5.3 Flash를 사용하지만, 로컬 모델을 포함해 어떤 제공업체든 쓸 수 있습니다. 설정하려면 제공업체 가이드(영어) 중 하나를 따라 하세요. 예를 들어 데스크톱 앱에서 OpenRouter 사용하기(영어)가 있습니다.
• 데스크톱 알림 허용. 워크플로가 보내는 알림을 볼 수 있도록 운영체제 설정에서 Conduit의 알림을 허용하세요.
• (선택) 관심 있는 피드의 주소. 모든 GitHub 저장소는 릴리스를 Atom 피드로 https://github.com/<owner>/<repo>/releases.atom 주소에 공개합니다.

1단계 — 기성 워크플로에서 시작하기

Conduit에는 그대로 쓰거나 고쳐 쓸 수 있는 기성 워크플로가 들어 있습니다. 이 단계에서는 이미 피드를 지켜보는 워크플로를 하나 만들고, 이를 릴리스 감시기의 바탕으로 삼습니다.

사이드 레일에서 워크플로를 선택하거나 Ctrl+6 (macOS에서는 ⌘6)을 누르세요. 아직 워크플로가 없다면 페이지의 아직 워크플로가 없습니다 아래에 기성 워크플로 목록이 나타납니다. 이미 있다면 새 워크플로를 선택해 목록을 볼 수 있습니다.

목록에는 다음이 들어 있습니다.

• 아침 브리핑 — 사이트 두 곳을 읽고 각각의 주요 기사를 하나의 브리핑으로 저장합니다.
• 페이지 지켜보기 — 페이지를 확인하고 바뀌었을 때만 알려 줍니다.
• 주제 모니터링과 주간 조사 요약 — 주제를 검색하거나 조사하고 요약을 최신 상태로 유지합니다.
• 주간 수치 프레젠테이션과 월간 보고서 섹션 — 사용자가 고른 슬라이드 프레젠테이션이나 글쓰기 초안을 업데이트합니다.
• 새 게시물 요약과 받은 폴더 — 피드의 새 게시물마다, 또는 폴더의 새 파일마다 한 번씩 실행됩니다.
• 메모를 내 문서와 대조 — 메모 파일을 문서 컬렉션의 구절과 비교합니다.
• 처음부터 시작 — 단계를 하나씩 쌓아 가며 만드는 빈 워크플로입니다.

새 게시물 요약을 찾아 이 템플릿 사용을 선택하세요. Conduit가 워크플로를 만들고 그 페이지를 엽니다.

— 확대 확대

새 워크플로에는 이미 네 단계가 있습니다. 게시물을 가져오고, 모델에 요약을 요청하고, 요약을 저장하고, 알림을 표시합니다. 아직 아무것도 실행되지 않습니다. 피드를 지켜보는 워크플로는 자동으로 실행을 켜야 비로소 지켜보기 시작하며, 이는 9단계에서 하게 됩니다. 다음으로 이 워크플로가 uv 릴리스를 가리키게 합니다.

2단계 — 워크플로가 릴리스 피드를 가리키게 하기

워크플로가 무엇으로 시작되는지는 시작 조건 섹션에서 정합니다. 이 단계에서는 이 워크플로가 지켜보는 피드를 Rust 블로그에서 uv의 릴리스로 바꿉니다.

워크플로 페이지에서 편집을 선택하세요. 머리글에는 워크플로 이름과 함께 JSON으로 편집, 취소, 저장이 있습니다. 왼쪽에는 단계가 있고, 오른쪽 사이드 패널에는 시작(시작 조건 선택지 포함), 실행마다 입력, 도우미, 워크플로 설정이 있으며, 이름, 설명, 모델 제공자, 폴더는 여기서 정합니다.

다음과 같이 바꾸세요.

1. 워크플로 설정에서 이름을 uv releases로 바꿉니다.
2. 시작 조건에서 피드에 새 게시물이 올라올 때를 선택한 채로 두고, 피드 주소를 https://github.com/astral-sh/uv/releases.atom으로 설정합니다.
3. 확인 간격을 360분으로 설정합니다. 릴리스 감시기는 30분마다 확인할 필요가 없습니다. 하루 네 번이면 충분합니다.

시작 조건의 다른 선택지로는 직접 실행하거나 정해진 시각에 실행하는 워크플로를 위한 내가 실행할 때만 또는 일정에 따라, 먼저 워크플로 설정에서 폴더를 골라야 하는 워크플로 폴더에 새 파일이 생길 때, 그리고 커넥터에서 새로운 것이 나타날 때가 있습니다.

— 확대 확대

이제 워크플로가 올바른 피드를 지켜봅니다. 다음으로 첫 단계가 실행을 시작시킨 게시물을 어떻게 사용하는지 살펴봅니다.

3단계 — 릴리스 노트 가져오기

피드 워크플로의 각 실행은 게시물 하나에 대한 것이며, 그 게시물의 정보는 모든 단계에서 값으로 쓸 수 있습니다. 이 단계에서는 첫 단계가 그중 하나를 사용해 릴리스 노트를 가져오는 방식을 살펴봅니다.

단계로 스크롤하세요. 각 단계는 번호와 유형이 제목으로 붙은 카드이며 (예: 1. 페이지 가져오기), 옆에 짧은 id가 있습니다. 여기서는 fetch입니다. 이후 단계는 이 id로 이 단계를 가리킵니다.

가져오기 단계의 페이지 1 칸에는 게시물의 링크를 나타내는 칩이 들어 있습니다. 이런 값은 각 칸 옆의 값 삽입… 메뉴로 넣으며, 이 메뉴에는 워크플로의 그 지점에서 쓸 수 있는 값이 나열됩니다.

• 트리거에서 — 게시물의 제목, 링크, 요약, 날짜, id.
• 이전 단계 — 위쪽 단계가 만든 결과. 예: fetch · 첫 페이지의 본문.
• 실행마다 입력 — 추가했다면, 워크플로를 실행할 때 직접 채우는 값.

가져오기 단계는 그대로 두세요. uv의 경우 각 게시물의 링크가 해당 릴리스의 GitHub 페이지이므로 이 단계가 릴리스 노트를 가져옵니다. 가져오기 단계는 최대 열 페이지를 읽고, 페이지마다 최대 50,000자를 유지하며, 공개 https 주소만 가져옵니다.

카드의 실패 시 재시도 설정도 눈여겨보세요. 가져오기는 기본적으로 두 번 재시도하므로 잠깐의 네트워크 문제는 넘어갑니다. 모든 단계에는 이 단계가 실패해도 계속 진행도 있습니다. 여기서는 꺼 두세요. 릴리스 노트가 없으면 요약할 것도 없습니다.

이제 워크플로가 새 릴리스를 읽을 수 있습니다. 다음으로 모델에게 그것으로 무엇을 할지 알려 줍니다.

4단계 — 요약 단계 작성하고 모델 고르기

모델에 요청 단계는 지시 하나와 텍스트를 모델에 보내고 그 답을 보관합니다. 이 단계에서는 릴리스 노트에 맞는 지시를 작성하고, 이 단계에만 쓸 저렴한 모델을 고릅니다.

id가 summary인 2번 단계 모델에 요청을 찾으세요. 지시를 다음 내용으로 바꿉니다.

Summarize these release notes for a developer who uses this tool every day.
List new features and fixes in at most five bullet points.
Then add a section titled "Breaking changes" that lists anything that could break
an existing project, such as removed options, changed defaults or new minimum versions.
If there are none, write exactly: No breaking changes.

처리할 텍스트 칸에는 이미 게시물의 제목과 그 뒤에 가져온 텍스트가 들어 있어서, 모델이 어떤 릴리스를 읽는지 알 수 있습니다. 그대로 두세요.

지시의 마지막 줄이 중요합니다. 6단계에서 바로 그 문장으로 알림을 보낼지 판단하므로, 모델이 매번 똑같이 쓰도록 요청한 것입니다.

이제 모델을 고릅니다. 이 단계의 모델의 기본값은 워크플로 모델 사용이고, 편집기 맨 위의 워크플로 자체 모델 설정은 기본적으로 채팅 모델 따르기입니다. 즉 채팅에서 마지막으로 고른 모델을 씁니다. 반복적인 요약에는 대신 빠르고 저렴한 모델을 고르세요. 이 튜토리얼에서는 OpenRouter를 통한 GLM 5.3 Flash를 사용합니다.

— 확대 확대

이제 워크플로가 예측 가능한 마지막 섹션을 가진 요약을 만듭니다. 다음으로 모든 요약이 보관되도록 합니다.

5단계 — 모든 요약 저장하기

문서 저장 단계는 텍스트를 나중에 열어 볼 수 있는 문서로 저장합니다. 이 단계에서는 릴리스마다 문서 하나씩 보관하도록 설정합니다.

3번 단계 문서 저장을 찾아 다음과 같이 설정하세요.

• 제목 — uv 뒤에 게시물 제목 칩을 붙여, 각 문서가 해당 릴리스 이름으로 저장되게 합니다.
• 내용 — 요약 칩과, 게시물 링크가 붙은 Source: 줄을 그대로 둡니다.
• 저장 형식 — 문서.
• 실행마다 — 새 문서를 추가합니다.

실행마다의 다른 선택지인 같은 문서를 대체합니다는 최신 결과가 담긴 문서 하나만 유지하며, 페이지 감시나 일일 브리핑에 알맞습니다. 릴리스 이력을 남기려면 릴리스마다 문서 하나가 필요합니다.

저장은 다음에 추가할 확인 단계보다 앞에 두었는데, 일부러 그렇게 한 것입니다. 오늘 주의를 기울일 필요가 없는 릴리스까지 모든 릴리스가 기록됩니다.

다음으로 알림을 보낼지 판단하는 단계를 추가합니다.

6단계 — 호환성이 깨지는 변경만 알리기

…인 경우에만 계속 단계는 값을 확인하고, 확인에 통과하지 못하면 실행을 조용히 끝냅니다. 이 단계에서는 저장과 알림 사이에 이 단계를 하나 추가해, 호환성이 깨지는 변경이 있는 릴리스에 대해서만 알림을 받게 합니다.

단계 맨 아래에서 단계 추가…를 열고 …인 경우에만 계속을 선택하세요. 새 단계는 맨 끝에 추가되므로 ↑ 버튼으로 알림 표시 위로 옮깁니다. 그런 다음 다음과 같이 설정합니다.

• 확인할 값 — 이전 단계에서 summary · 텍스트를 삽입합니다.
• 다음일 때만 계속 — 포함하지 않는다.
• 텍스트 — No breaking changes.

비교는 대소문자와 불필요한 공백을 무시합니다. 다른 조건으로는 지난 실행 이후 바뀌었다, 비어 있지 않다, 비어 있다, 포함한다, 와 같다가 있습니다. 이 중 첫 번째는 페이지 지켜보기 스타터가 페이지가 바뀔 때만 알려 주는 데 쓰는 조건입니다.

마지막으로 5번 단계 알림 표시를 수정하세요. 제목은 Breaking changes in uv로, 메시지는 게시물 제목 칩으로 설정합니다.

모델이 정확한 문장을 잊어버리면 확인을 통과해 알림이 나갑니다. 따라서 최악의 경우에도 필요 없는 알림이 한 번 오는 것일 뿐, 놓치는 호환성 변경은 없습니다.

저장을 선택하세요. 아직 존재하지 않는 값을 읽는 단계처럼 앞뒤가 맞지 않는 부분이 있으면 편집기가 저장하기 전에 다음을 수정하십시오: 아래에 그 목록을 보여 주고, 고칠 때까지 저장을 비활성화한 채로 둡니다. 저장하고 나면 워크플로 페이지에 다섯 단계가 쉬운 말로 나열됩니다.

— 확대 확대

워크플로가 완성되었습니다. 혼자 실행되게 하기 전에 먼저 테스트합니다.

7단계 — 지금 실행으로 워크플로 테스트하기

테스트 실행은 실제 데이터로 워크플로가 정확히 무엇을 할지 보여 줍니다. 이 단계에서는 직접 한 번 실행해 봅니다.

워크플로 페이지에서 지금 실행을 선택하세요. 피드를 지켜보는 워크플로를 직접 실행하면 피드의 가장 최신 게시물을 테스트용으로 사용하므로, 다음 릴리스를 기다릴 필요가 없습니다. 버튼이 실행 중…으로 바뀌고 중지 버튼이 나타나며, 실행은 최근 실행에 테스트 실행: 뒤에 릴리스 이름이 붙은 항목으로 표시됩니다.

실행 시간의 거의 전부는 모델 단계가 차지합니다. GLM 5.3 Flash로는 여기에 보이는 테스트 실행이 1분 안에 끝났습니다. 실행이 끝나면 릴리스에 호환성이 깨지는 변경이 있어 알림을 받았을 때는 상태가 완료로, 요약을 저장한 뒤 확인 단계가 실행을 끝냈을 때는 새로운 내용 없음으로 표시됩니다. 어느 쪽이든 저장됨:이 저장된 요약으로 연결됩니다.

— 확대 확대

경계선에 있는 릴리스는 모델이 실행마다 다르게 판단할 수 있다는 점을 염두에 두세요. uv 0.12.24는 대부분 버그 수정이었고, 그중 몇 가지는 해시 확인이 꺼져 있어도 제공된 해시를 검사하는 것처럼 uv를 더 엄격하게 만듭니다. 이 릴리스로 두 번 테스트했을 때 GLM 5.3 Flash는 한 번은 그 수정들을 호환성이 깨지는 변경으로 나열했고, 한 번은 No breaking changes.라고 썼습니다. 이런 변경도 알림으로 받고 싶다면 지시에 그렇게 적으세요. 예: Count bug fixes that make uv stricter as breaking changes.

이런 단계에는 바로 답하는 모델을 고르세요. 답하기 전에 오래 추론하는 모델은 긴 페이지에서 수 분이 걸릴 수 있고, 실행은 30분 한도에 닿으면 멈춥니다.

다음으로 실행을 열어 각 단계가 무엇을 했는지 살펴봅니다.

8단계 — 실행 읽고 한 단계만 다시 실행하기

모든 실행은 단계마다 기록을 남깁니다. 무엇이 들어갔고, 무엇이 나왔고, 어떤 모델을 썼고, 시간이 얼마나 걸렸는지입니다. 이 단계에서는 그 기록을 읽고, 요약을 바꾸고, 필요한 단계만 다시 실행합니다.

최근 실행에서 테스트 실행을 선택하세요. 이 실행이 한 작업 섹션에 단계가 나열되고, 각각 완료, 실패, 건너뜀, 재사용됨 중 하나의 상태를 가집니다. 확인 단계가 실행을 끝냈다면 새로운 내용 없음 — check에서 중단됨처럼 단계의 id와 함께 표시됩니다.

summary 단계를 펼치세요. 사용됨으로 끝나는 줄이 실행에 쓴 모델과 제공업체를 알려 주고, 그 아래에 단계의 입력과 출력이 있습니다. 저장됨: 아래의 문서 이름을 선택하면 요약 자체를 열 수 있습니다.

요약이 원하는 것보다 길다고 해 봅시다. 편집을 선택하고 at most five bullet points를 at most three bullet points로 바꿔 저장하세요. 그런 다음 테스트 실행을 다시 열고 summary 단계를 찾아 이 단계부터 다시 실행을 선택합니다.

새 실행은 가져오기 단계를 재사용됨으로 표시합니다. 페이지를 다시 가져오지 않고 이전 실행의 릴리스 노트를 가져다 쓰며, 요약, 저장, 확인, 알림 단계를 새 지시로 실행합니다. 아래에 보이는 실행에서는 페이지를 다시 가져오지 않았기 때문에 다시 실행이 10초 만에 끝났고, 전체 실행은 16초였습니다. 더 긴 워크플로에서는 시간과 모델 호출을 모두 아낄 수 있습니다.

— 확대 확대

실행이 실패하면 같은 화면에서 어느 단계가 왜 실패했는지 쉬운 말로 볼 수 있습니다. 그 단계를 고친 다음 그 단계부터 다시 실행하세요.

워크플로가 원하는 대로 동작합니다. 다음으로 혼자 실행되게 합니다.

9단계 — 자동 실행 켜기

혼자 실행되는 워크플로는 먼저 승인을 받아야 합니다. 이 단계에서는 릴리스 감시기가 무엇을 해도 되는지 검토하고 켭니다.

워크플로 페이지에서 설명 아래의 시작 칩을 선택하세요(캔버스 보기에서는 대신 시작 단계를 선택합니다). 시작 패널이 열리고 예약 섹션이 나타납니다. 자동으로 실행을 체크하세요(패널의 ← 뒤로를 누르면 워크플로로 돌아갑니다). Conduit가 혼자 실행하게 허용할까요?라는 제목의 패널을 보여 주며, 워크플로가 묻지 않고 해도 되는 모든 작업을 나열합니다. 릴리스 감시기의 목록은 다음과 같습니다.

• github.com의 페이지 읽기 — 피드를 읽기 위한 것입니다.
• 단계 “fetch”이(가) 실행 시 가져오는 주소의 페이지 읽기 — 가져오기 단계의 주소는 피드에서 오므로 Conduit가 사이트를 미리 특정할 수 없습니다.
• 온라인으로 OpenRouter에 텍스트 전송 — 요약 단계를 위한 것입니다.
• 문서 저장.

알림과 확인 단계는 승인이 필요 없습니다. 허용하고 켜기를 선택하세요. 이제 섹션에 github.com을(를) 360분마다 감시 중이 표시되고, 혼자 실행할 때 다음을 할 수 있습니다:로 시작하는 줄이 승인한 목록을 계속 보여 줍니다.

— 확대 확대

나중에 워크플로를 편집해 새 사이트나 다른 제공업체처럼 더 많은 것이 필요해지면, 페이지에 추가로 확인이 필요합니다와 승인 버튼이 나타납니다. 승인하기 전까지는 자동 실행이 그 단계에 이르렀을 때 멈추고 묻습니다. 알림이 오고, 실행에 확인 필요가 표시되며, 홈의 확인 필요 아래에 나열됩니다. 한 번만 허용, 항상 허용, 허용 안 함 중에서 고를 수 있으며, 하루 안에 아무도 응답하지 않으면 그 단계는 진행되지 않습니다.

자동 실행을 처음 켤 때 Conduit는 알림 영역에서 계속 실행도 제안합니다. 자동 실행은 Conduit가 실행 중일 때만 진행되므로, 창을 자주 닫는다면 수락하세요. 나중에 같은 섹션에서 바꿀 수 있으며, 로그인할 때 Conduit을(를) 알림 영역에서 시작도 함께 설정할 수 있습니다.

— 확대 확대

이제 릴리스 감시기가 혼자 실행됩니다. 마지막 단계에서는 다음 워크플로를 더 빠르게 시작하는 방법을 살펴봅니다.

10단계 — 직접 만드는 대신 설명해서 워크플로 만들기

모든 워크플로를 단계별로 직접 만들 필요는 없습니다. 이 단계에서는 Conduit가 한 문장으로 워크플로 초안을 만들게 합니다.

워크플로 페이지에서 새 워크플로를 선택하세요. 워크플로 설명하기에 다음을 입력합니다.

평일 9:00마다 Hacker News 첫 페이지와 Lobsters 첫 페이지를 읽고, Rust나 Python에 관한 기사를 하나의 목록으로 저장하기.

초안 만들기를 선택하세요. 채팅 모델이 워크플로를 작성하고, Conduit는 사용자가 저장하는 워크플로를 확인할 때와 같은 방식으로 이를 확인하며, 문제가 있으면 모델에 돌려보내 고치게 합니다. 초안은 저장되지 않은 상태로 편집기에 열립니다. 사용자가 저장을 선택하고 직접 켜기 전까지는 아무것도 저장되거나 예약되지 않습니다.

모델은 폴더, 프레젠테이션, 문서 컬렉션처럼 사용자만 고를 수 있는 것을 절대 고르지 않으며, 일정도 켜지 않습니다. 초안에 이런 것이 필요하면 편집기가 짧은 목록과 함께 저장하기 전에 채워야 할 항목을 보여 줍니다. 위의 설명에 대해서는 목록에 예약 켜기: 평일 9:00마다.가 나오는데, 저장한 뒤 워크플로 페이지에서 일정을 설정하라는 안내입니다.

— 확대 확대

말로 워크플로를 시작하는 방법이 두 가지 더 있습니다.

• 홈에서. 질문 입력창에 원하는 것을 입력하고 자동화 칩을 선택하면, Conduit가 워크플로를 열고 초안을 만듭니다.
• 채팅에서. 채팅에서 직접 무언가를 해 본 뒤 Ctrl+K(macOS에서는 ⌘K)로 명령 팔레트를 열고 채팅을 워크플로로 저장…을 선택하세요. 초안은 사용자가 요청한 내용과 사용된 도구를 바탕으로 만들어지며, 모델은 페이지나 문서 자체를 보지 않습니다.

어느 쪽이든 초안을 검토하고, 지금 실행으로 테스트한 다음에야 자동으로 실행을 켜세요.

더 나아가기: 캔버스, 분기, 에이전트

릴리스 감시기는 일직선이지만 워크플로가 꼭 그래야 하는 것은 아닙니다. 방금 해 본 것을 바탕으로 네 가지를 더할 수 있습니다.

• 캔버스. 단계 보기에서 캔버스를 선택하면 시작, 각 단계, 반복, 그 사이를 잇는 선이 보입니다. 실행 중에는 각 단계가 실행 중인지, 끝났는지, 실패했는지, 건너뛰었는지, 내 답을 기다리는지 표시되고, 단계를 선택하면 입력과 출력을 볼 수 있습니다. 편집기에서는 팔레트에서 단계를 추가하고, 끌어서 순서를 바꾸고, 한 단계에서 다른 단계로 선을 끌어 어떤 출력이 어떤 필드로 들어갈지 직접 입력하는 대신 정할 수 있습니다.
• 분기와 나란히 실행되는 단계. 만약… 아니면 단계는 실행을 ‘예’ 쪽이나 ‘아니요’ 쪽으로 보내며, 가지 않은 쪽은 지나지 않음으로 기록됩니다. 한 단계가 앞의 여러 단계를 기다릴 수 있으므로, 서로 의존하지 않는 단계는 최대 네 개까지 나란히 실행되고 이후 단계가 그 결과를 모을 수 있습니다. 예를 들어 릴리스 감시기의 …인 경우에만 계속 단계를 분기로 바꾸면, 한쪽에서는 알리고 다른 쪽에서는 저장만 하게 할 수 있습니다.
• 결과. 끝난 실행이 저장한 것은 모두 미리 보기와 함께 보관됩니다. 워크플로의 결과 탭이나 모든 워크플로를 모아 보여 주는 워크플로 사이드바의 결과 목록을 열고 열기로 읽으세요.
• 에이전트. 모델에 도구 사용 허용 단계는 커넥터 도구를 최대 열 개까지 쓰고, 직접 정의한 도우미에게 작업을 넘길 수 있습니다. 도우미는 각각 자체 지침, 모델, 토큰 한도를 가집니다. 무언가를 보내거나 게시하거나 편집하는 커넥터 도구는 실행을 멈추고 묻고, 받은 편지함에는 워크플로가 기다리는 모든 것이 모입니다. 설정 → 컴퓨터를 켜면 에이전트는 지정한 폴더에서 명령을 실행하고 파일을 바꿀 수도 있으며, 허용한 규칙이 포함하지 않는 모든 명령은 먼저 묻습니다. 한계는 워크플로 문서에 정리되어 있습니다.

모든 단계 유형 한눈에 보기

릴리스 감시기는 다섯 종류의 단계를 사용합니다. 다음은 단계 추가… 메뉴에 나오는 대로 정리한 전체 목록입니다.

워크플로 하나에는 최대 50개의 단계를 둘 수 있습니다. 모든 단계의 모든 텍스트 칸에는 삽입한 값을 넣을 수 있으며, 정의 전체는 편집기의 JSON으로 편집으로 직접 고칠 수 있습니다. 그 보기에서 삽입한 값은 {{steps.summary.text}}나 {{trigger.link}}처럼 쓰이며, 중괄호 자체를 쓰려면 앞에 백슬래시를 붙입니다. \{{.

참고로, 다음은 지금까지 만든 릴리스 감시기를 JSON 보기에서 본 모습입니다.

{
  "steps": [
    {
      "id": "fetch",
      "type": "fetch_page",
      "urls": [
        "{{trigger.link}}"
      ]
    },
    {
      "id": "summary",
      "input": "{{trigger.title}}\n\n{{steps.fetch.text}}",
      "model": {
        "model": "z-ai/glm-5.3-flash",
        "provider": "openrouter"
      },
      "prompt": "Summarize these release notes for a developer who uses this tool every day.\n…",
      "type": "summarize"
    },
    {
      "content": "{{steps.summary.text}}\n\nSource: {{trigger.link}}",
      "id": "save",
      "mode": "create",
      "title": "uv {{trigger.title}}",
      "type": "save_artifact"
    },
    {
      "id": "check",
      "is": "not_contains",
      "text": "No breaking changes",
      "type": "condition",
      "value": "{{steps.summary.text}}"
    },
    {
      "body": "{{trigger.title}}",
      "id": "notify",
      "title": "Breaking changes in uv",
      "type": "notify"
    }
  ],
  "trigger": {
    "everyMinutes": 360,
    "kind": "feed",
    "url": "https://github.com/astral-sh/uv/releases.atom"
  }
}

자주 묻는 질문

마치며

이 튜토리얼에서는 uv의 릴리스를 지켜보는 워크플로를 만들었습니다. 새 릴리스마다 노트를 가져오고, 저렴한 모델로 요약하고, 모든 요약을 저장하며, 호환성이 깨지는 변경이 있을 때만 알려 줍니다. 실제 릴리스로 테스트하고, 각 단계가 한 일을 읽어 보고, 고친 단계부터 다시 실행하고, 혼자 실행될 때 해도 되는 일을 정확히 승인했습니다.

무언가를 가져오고, 모델에 묻고, 결과를 보관하고, 중요할 때만 알려 주는 이 패턴은 많은 루틴에 들어맞습니다. 프로젝트가 의존하는 모든 도구의 릴리스에 복사본을 하나씩 연결해 보거나, 요금제나 상태 페이지에 페이지 지켜보기를 써 보거나, 받은 폴더로 폴더에 넣는 파일을 하나씩 요약해 보세요. 더 알아보려면 다음 가이드를 참고하세요.

• 워크플로 문서: 모든 설정과 한도를 다룹니다.
• Conduit와 Exa로 딥 리서치하는 방법: 워크플로의 주제 조사하기 단계가 사용하는 리서치 실행을 알아봅니다.
• 제공업체 가이드(영어): 워크플로가 사용할 모델을 고르고 설정합니다.

Conduit 내려받기

Conduit 관련 내용은 최신 릴리스와 일치하며 문서와 소스에서 확인할 수 있습니다. 오류를 발견하셨나요? 알려 주세요. 바로잡겠습니다.

관련 콘텐츠

• Conduit와 Exa로 딥 리서치하는 방법 — Conduit에서 Exa 검색을 켜고 리서치 개요를 작성해 출처가 달린 보고서를 읽습니다. 태양전지 연구 예제, Exa 키 불필요.
• MCP 서버를 고객에게 시연하는 방법 — MCP 서버 호스팅은 고객 시연이 아닙니다. 호스팅형 챗, Claude Desktop과 확장, 자체 데스크톱 클라이언트를 비교합니다.