문서로 돌아가기핵심 개념

워크플로

팀이 일하는 방식을 Okou에게 가르치는 재사용 가능한 이름 지정 절차.

최종 업데이트 2026년 8월 17일 · 6 min read

워크플로는 에이전트에 저장된 이름 지정된 재사용 가능한 절차입니다. 당신의 팀이 특정 유형의 작업을 어떻게 하는지 Okou에 가르쳐, 다음에 그게 필요한 사람이 프롬프트를 다시 쓰지 않아도 됩니다.

처음 Okou에 무언가를 요청할 때 프롬프트를 씁니다. 두 번째에는 같은 프롬프트를 약간 수정해 붙여넣습니다. 세 번째에는 누군가 "팀 프롬프트 라이브러리"라고 부른 Notion 문서에서 긴 프롬프트를 복사하고 있습니다. 그때가 워크플로를 저장할 순간입니다.

워크플로가 해결하는 문제

일회성 채팅은 일회성 태스크에 적합합니다. 하지만 거의 모든 팀에는 반복되는 작업 백로그가 있습니다. 입력은 다르고 형태는 같습니다:

  • 고객이 문의 → 이력을 확인 → 그 언어로 답장 초안 → 티켓 기록
  • 버그 보고가 나타남 → 재현 단계 추출 → 심각도 분류 → 구조화된 Issue 생성
  • 월요일 아침 → 지난주 수치 가져오기 → 그 전 주와 비교 → 요약 게시

워크플로가 없으면 각각은 모두가 기억해야 하는 200단어 프롬프트입니다. 워크플로가 있으면 각각은 이름입니다. triage-bug-report, weekly-metrics, customer-reply.

워크플로 자체에는 일정도 트리거도 없습니다. 그것은 절차입니다. 스스로 실행되게 하려면 Automation을 붙이세요.

워크플로에 들어 있는 것

필드역할
Name문자, 숫자, 내부 하이픈을 사용한 2~64자 소문자 슬러그 — triage-bug-report. 소유 에이전트의 채팅에서 명시적으로 호출하려면 /triage-bug-report를 사용합니다.
Display name워크스페이스에 표시되는 사람이 읽을 수 있는 라벨.
Description이 워크플로가 언제 적용되는지 Okou에 알려주는 한 줄. Okou는 수신 요청을 설명과 대조하므로 표현이 중요합니다.
Instruction절차 자체. 평이한 문장이면 충분합니다. 사용할 도구, 출력 형태, 제약 사항을 언급하세요.
Files선택적 보조 파일 — 템플릿, 체크리스트, 브랜드 가이드라인, 참조 데이터 — 워크플로와 함께 묶임.
Visibilityprivate(나만) 또는 public(워크스페이스의 모든 사람).

노드 그래프도, YAML 설정도, 트리거 섹션도 없습니다. 인스트럭션은 보통 처음에 잘 작동했던 채팅 프롬프트와 매우 비슷합니다.

좋은 설명은 발화해야 할 때 발화하는 워크플로와 절대 발화하지 않는 워크플로의 차이입니다. *"triage a customer-facing bug report and file it to GitHub with severity"*가 *"do bug stuff."*보다 낫습니다.

워크플로는 에이전트에 속함

모든 워크플로는 정확히 하나의 에이전트에 속합니다. 그것이 동작을 예측 가능하게 만듭니다. 워크플로는 그 에이전트의 톤, 기본값, 커넥터 부여로 실행됩니다.

  • 비공개 워크플로 — 나만 볼 수 있음. 개인 Gmail이나 개인 CRM 자리에 연결된 개인 자동화에 적합.
  • 공개 워크플로 — 워크스페이스의 모든 사람이 볼 수 있음. 팀이 도달할 수 있는 에이전트에 둠.

같은 절차가 두 에이전트에 존재하며 서로 다른 결과를 낼 수 있습니다. 각 에이전트가 자신의 목소리와 권한을 가져오기 때문입니다. 워크플로를 다른 에이전트에 넘기려면 복사하세요. 그러면 분기되어 둘이 이후 달라질 수 있습니다.

에이전트 소유권이 워크플로가 건드릴 수 있는 범위를 어떻게 정하는지는 Agents 참조.

워크플로 만들기

Workflows 페이지에서 시작

  1. Workflows를 열고 New workflow를 선택합니다.
  2. 워크플로를 소유할 에이전트를 선택합니다.
  3. Okou가 안내형 워크플로 생성 프롬프트로 채팅을 엽니다. 결과, 예상 입력, 도구, 출력, 승인 경계를 설명하세요.
  4. Okou가 만들기 전에 제안된 이름, 설명, 인스트럭션, 파일, 가시성을 검토합니다.

기존 에이전트 채팅에서 시작해 이미 잘 작동한 태스크를 워크플로로 바꿔달라고 Okou에 요청할 수도 있습니다. 첫 성공 Run을 같은 채팅에 두면 Okou가 잡아낼 구체적인 입력, 수정, 출력이 생깁니다.

인스트럭션에 넣을 것

부분포함
Goal워크플로가 만들어야 할 결과.
Inputs호출자나 자동화가 제공하는 것과 필수 입력.
Procedure읽거나 업데이트할 연결된 서비스를 포함한 순서 있는 단계.
Output필요한 형식, 대상, 이름 규칙.
Boundaries피할 작업, 확인이 필요한 경우, 멈출 때.
References워크플로 파일로 첨부된 선택적 템플릿, 체크리스트, 예시.

자격 증명을 인스트럭션과 파일 밖에 두세요. Connectors로 서비스를 연결하고 소유 에이전트에 워크플로에 필요한 권한만 부여하세요.

자동화 전에 테스트

  1. 대표적인 입력으로 워크플로를 수동 실행합니다.
  2. 소유 에이전트가 필요한 모든 커넥터와 권한에 접근할 수 있는지 확인합니다.
  3. 결과 채팅에서 빠진 컨텍스트, 예상치 못한 쓰기, 최종 출력 형태를 검사합니다.
  4. Instructions나 첨부 파일을 편집하고 결과가 반복 가능해질 때까지 다시 실행합니다.
  5. 수동 실행이 올바른 뒤에만 자동화를 추가합니다. 좁은 이벤트 필터나 낮은 빈도 일정으로 시작한 다음 처음 몇 번의 발화를 검사합니다.

수동 검증은 워크플로 문제와 트리거 문제를 구분합니다. Run now가 실패하면 먼저 워크플로나 그 액세스를 고치고, Run now는 성공하는데 이벤트가 발화하지 않으면 자동화 구성을 검사합니다.

Okou가 워크플로를 고르는 방식

워크플로를 이름으로 호출할 필요가 없습니다. 수신 요청이 설명과 일치하면 Okou가 자동으로 하나를 로드합니다. *"draft a reply to a customer email using our voice and docs"*로 설명된 customer-reply-draft 워크플로는 고객 이메일을 전달하면 발화합니다. 이름이 필요 없습니다.

특정 워크플로를 강제하려면 말하세요: "Use the customer-reply-draft workflow on this email."

내장 워크플로

모든 Okou 에이전트에는 Okou이 유지 관리하는 교차 기능 워크플로가 포함됩니다. 리서치와 분석, 재무와 회계, 법률과 컴플라이언스, 제품, 마케팅, 고객 지원, 팀 커뮤니케이션. 커넥터 배선이 아니라 도메인 절차로, 각각이 반복되는 작업 유형을 다루는 법을 Okou에 가르칩니다.

일부 예:

  • deep-dive — 구조화된 리서치와 솔루션 설계. 사실을 모은 뒤 옵션 탐색
  • prd-writing — 구조화된 문제 정의와 수용 기준을 갖춘 제품 요구사항
  • copywriting — 채널 전반의 마케팅 카피(블로그, 이메일, 소셜, 랜딩 페이지)
  • competitor-matrix — 기능 비교 매트릭스, 포지셔닝 분석, 승패 분석
  • customer-reply — 채널과 긴급도에 맞춘 공감적이고 브랜드에 맞는 답장
  • nda-screening — 수신 NDA를 GREEN / YELLOW / RED로 분류하고 라우팅
  • status-updates — 모든 대상에 맞춘 진행 보고와 이해관계자 업데이트

내 워크플로는 이들과 나란히 있으며 설명이 더 정확히 일치하면 우선합니다.

만들 시점

정직한 규칙: 실질적으로 같은 프롬프트를 두 번 넘게 썼다면, 또는 팀 동료가 그걸 쓸 것이라고 상상된다면 저장하세요.

구체적인 신호:

  • 팀이 이미 쓰는 이름이 있다(«morning brief», «competitor scan»)
  • 프롬프트가 매 Run마다 바뀌지 않아야 할 특정 도구, 채널, 템플릿을 지목한다
  • 출력이 고정된 형태다(요약, 초안, 생성된 Issue)
  • 한 명 이상이 트리거해야 한다
  • 일정이나 이벤트로 실행되길 원한다 — Automations 참조

일반적인 패턴

  • 인테이크 폼. 입력(이메일, 버그 보고, 스레드)을 받아 구조화된 산출물(Issue, 초안, 행)을 만듭니다.
  • 주기 브리프. 매일 또는 매주 실행되어 눈에 띄는 곳에 게시하는 예약 자동화와 짝을 이룬 워크플로.
  • 대화 중 헬퍼. 채널에서 Okou로 트리거되어 하나의 집중된 하위 작업(조회, 요약, 분류)을 수행합니다.
  • 컴포저. 한 Run에서 블로그 초안 + 소셜 게시물 + 카드 같은 다중 형식 묶음을 만듭니다.
  • 이벤트 응답자. 이벤트 자동화와 짝을 이룹니다. 새 이메일, 병합된 PR, 새 Notion 페이지가 Run을 시작합니다. Automations 참조.

피해야 할 함정

  • 너무 좁음. 특정 입력 하나에만 맞는 워크플로는 취약합니다. 한 예의 세부가 아니라 작업의 형태를 겨냥하세요.
  • 너무 모호함. *"Help with marketing"*은 너무 넓어 Okou가 언제 적용할지 모릅니다. 설명을 구체적으로 쓰세요.
  • 하드코딩된 자격 증명. API 키를 인스트럭션에 붙여넣지 마세요. Custom connectors를 사용하세요. 자격 증명은 플랫폼에 남아 모델의 손이 닿지 않는 곳에 있습니다.
  • 묻힌 출력 형태. 산출물이 어떻게 생겨야 하는지 명시하세요. "a numbered list of three items" 또는 "a draft reply under 150 words."
  • 에이전트 잊기. 워크플로는 호스트 에이전트가 승인된 커넥터만 사용할 수 있습니다. 워크플로가 Gmail에 도달하지 못하면 인스트럭션이 아니라 에이전트의 Authorization 탭을 확인하세요.

다음

  • Automations로 트리거를 붙이면 워크플로가 당신 없이 실행됩니다.
  • 누가 어떤 권한으로 워크플로를 실행하는지는 Agents 참조.
  • 워크플로가 건드릴 수 있는 것을 제한하려면 Permissions 참조.
  • 처음부터 끝까지 쓰인 5가지는 Example workflows 참조.