워크플로

워크플로는 이름이 있고 재사용 가능한 절차입니다. 당신의 팀이 특정 종류의 일을 어떻게 하는지 Okou에 알려 주므로, 다음에 필요한 사람이 프롬프트를 다시 작성하지 않아도 됩니다.

처음 Okou에게 무언가를 시킬 때는 프롬프트를 작성합니다. 두 번째에는 같은 프롬프트에 약간의 수정을 더해 붙여 넣습니다. 세 번째쯤 되면 누군가가 "팀 프롬프트 라이브러리"라고 부르는 Notion 문서에서 긴 프롬프트를 복사해 오게 됩니다. 그때가 워크플로를 저장할 순간입니다.

워크플로가 해결하는 문제

일회성 채팅은 일회성 작업에는 괜찮습니다. 하지만 거의 모든 팀에는 반복되는 일감이 쌓여 있습니다. 입력은 달라도 형식은 같습니다:

• 고객이 문의를 보내면 → 이력을 확인한 다음 → 해당 언어로 답장을 초안 작성 → 티켓 기록
• 버그 리포트가 들어오면 → 재현 단계를 추출 → 심각도 분류 → 구조화된 이슈 생성
• 월요일 아침이 되면 → 지난주 수치를 가져와 → 그전 주와 비교 → 요약본 게시

워크플로가 없으면, 이런 것들은 모두 everyone이 외워야 하는 200단어짜리 프롬프트입니다. 워크플로가 있으면 각각은 이름이 됩니다: triage-bug-report, weekly-metrics, customer-reply.

워크플로 자체에는 일정도 트리거도 없습니다. 그것은 절차일 뿐입니다. 자동으로 실행되게 하려면 자동화를 연결하세요.

워크플로에 포함되는 것

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

좋은 설명은 워크플로가 필요할 때 실행되는지, 아니면 전혀 실행되지 않는지를 가르는 차이입니다: "triage a customer-facing bug report and file it to GitHub with severity"이 "do bug stuff."보다 낫습니다

소유권과 표시 범위

My Okou: 워크플로는 현재 워크스페이스에 존재합니다. Private Workflow는 현재 사용자에게 속합니다. Public Workflow는 워크스페이스 멤버들과 공유되며, Public이 인터넷 공개를 의미하지는 않습니다. 각 실행은 실행하는 사용자의 개인 지침(Instructions), 메모리, 연결된 계정, 권한을 사용합니다. 절차를 공유한다고 해서 이러한 개인 리소스나 비공개 결과까지 공유되는 것은 아닙니다.

같은 이름의 Private Workflow는 Public Workflow보다 우선합니다. 특정 공유 정의를 식별해야 할 때는 명시적인 Workflow ID를 사용하세요. 사본 만들기는 수정할 수 있는 별도의 버전을 제공합니다. 이후 변경 사항은 원본과 동기화되지 않습니다. 다른 멤버의 자동화는 복사되지 않습니다. Private Workflow를 만든다고 해서 Public Workflow를 게시하거나 유지할 권한이 생기는 것은 아닙니다. 기존 워크스페이스 게시 규칙은 그대로 적용됩니다.

Legacy Agents: 각 워크플로는 하나의 에이전트에 속합니다. 팀원도 해당 워크플로의 소유 에이전트에 접근할 수 있어야 합니다. 워크플로 복사는 대상 에이전트를 선택하고 개인 포크를 생성합니다. 에이전트는 자신의 프로필과 개인 지침(Instructions)을 제공하며, 실행은 여전히 실행 중인 멤버의 승인된 계정 접근을 사용합니다.

상시 개인 지침(Instructions)은 My Okou 및 legacy Agents를 참조하세요.

어떤 경험을 사용하고 있나요?

이 문서는 두 가지 경험을 모두 다룹니다. Settings → Personal → My Okou가 보이면 My Okou 단계를 따르세요. New agent가 있는 Agents 페이지를 사용한다면 Legacy Agents 단계를 따르세요. 사용 가능 여부는 멤버마다 다를 수 있으며, 이 문서가 여러분의 경험을 바꾸지는 않습니다.

어느 경험이든 여러 채팅이나 작업을 동시에 실행하고, 워크플로를 재사용하며, 검토된 작업을 팀과 공유할 수 있습니다. 런타임 하위 에이전트는 실행 도구일 뿐, 따로 생성해야 하는 별도의 제품 프로필이 아닙니다.

워크플로 만들기

워크플로 페이지에서 시작하기

1. 워크플로를 엽니다. My Okou: 채팅에서 만들기를 선택합니다. Legacy Agents: 표시되는 곳에서 새 워크플로를 선택합니다.
2. My Okou: 자신의 채팅에서 계속합니다. 에이전트 선택은 필요하지 않습니다. Legacy Agents: 워크플로를 소유할 에이전트를 선택합니다.
3. Okou가 안내된 워크플로 생성 프롬프트가 있는 채팅을 엽니다. 결과, 예상 입력, 도구, 출력, 그리고 필요한 승인 경계를 설명하세요.
4. Okou가 생성하기 전에 제안된 이름, 설명, 지침, 파일, 가시성을 검토하세요.

이미 있는 채팅에서 시작해, 이미 잘 작동한 작업을 워크플로로 바꿔 달라고 Okou에게 요청할 수도 있습니다. 첫 성공 실행을 같은 채팅에 두면 Okou가 캡처할 구체적인 입력, 수정 사항, 출력을 제공할 수 있습니다.

My Okou 예시: 워크플로의 지침은 반복 가능한 작업을 설명합니다.

지침에 넣을 내용

자격 증명은 지침과 파일에 넣지 마세요. 서비스를 커넥터를 통해 연결한 다음 연결된 계정을 검토하고, 워크플로에 필요한 권한만 부여하세요. Legacy Agents에서는 해당 워크플로의 소유 에이전트도 승인해야 합니다.

자동화하기 전에 테스트

1. 대표 입력으로 워크플로를 수동 실행합니다.
2. 실행하는 멤버가 필요한 계정 접근 권한과 권한을 가지고 있는지 확인합니다. Legacy Agents에서는 소유 에이전트의 승인도 확인합니다.
3. 결과 채팅에서 누락된 맥락, 예상치 못한 쓰기 작업, 최종 출력 형식을 점검합니다.
4. 결과가 반복 가능해질 때까지 개인 지침(Instructions) 또는 첨부 파일을 수정하고 다시 실행합니다.
5. 수동 실행이 올바를 때만 자동화를 추가하세요. 좁은 이벤트 필터나 낮은 빈도의 일정으로 시작한 다음, 처음 몇 번의 실행을 점검하세요.

수동 검증은 워크플로 문제와 트리거 문제를 분리합니다. 지금 실행이 실패하면 먼저 워크플로나 접근 권한을 수정하세요. 지금 실행은 성공하지만 이벤트가 전혀 실행되지 않으면 자동화 구성을 점검하세요.

Okou가 워크플로를 선택하는 방법

워크플로를 이름으로 호출할 필요는 없습니다. 들어오는 요청이 설명과 일치하면 Okou가 자동으로 불러옵니다. customer-reply-draft라는 이름의 워크플로가 *"우리의 말투와 문서를 사용해 고객 이메일에 답장을 초안 작성"*이라고 설명되어 있다면, 고객 이메일을 전달할 때 실행됩니다. 이름은 필요하지 않습니다.

특정 워크플로를 강제로 사용하려면 그렇게 말하면 됩니다: "이 이메일에는 customer-reply-draft 워크플로를 사용하세요."

내장 워크플로

Okou에는 Okou가 유지 관리하는 여러 부서 간 워크플로가 포함되어 있습니다. 연구 및 분석, 재무 및 회계, 법률 및 컴플라이언스, 제품, 마케팅, 고객 지원, 팀 커뮤니케이션이 이에 해당합니다. 이들은 커넥터 인프라가 아니라 도메인 절차입니다. 각각은 Okou가 반복되는 종류의 일을 처리하는 방법을 가르칩니다.

예시를 들면:

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

여러분의 워크플로는 이들과 나란히 존재하며, 설명이 더 잘 맞으면 우선합니다.

언제 만들어야 하나요

솔직한 규칙은 이렇습니다. 본질적으로 같은 프롬프트를 두 번 넘게 썼다면, 또는 팀원이 그렇게 쓸 것 같다면 저장하세요.

구체적인 신호:

• 그 작업에는 팀이 이미 쓰는 이름이 있음("아침 브리핑", "경쟁사 스캔")
• 프롬프트가 매 실행마다 바뀌면 안 되는 특정 도구, 채널, 템플릿을 언급함
• 출력 형식이 고정되어 있음(요약본, 초안, 생성된 이슈)
• 둘 이상의 사람이 트리거해야 함
• 일정이나 이벤트로 실행되길 원함 — 자동화 참조

일반적인 패턴

• 인테이크 폼. 입력 조각(이메일, 버그 리포트, 스레드)을 받아 구조화된 산출물(이슈, 초안, 행)을 만듭니다.
• 주기 브리프. 매일 또는 매주 실행되고 눈에 보이는 곳에 게시하는 예약 자동화와 짝지은 워크플로입니다.
• 대화 중 도우미. 채널에서 @Okou에 의해 트리거되어 한 가지 집중된 하위 작업(찾기, 요약, 분류)을 수행합니다.
• 컴포저. 한 번의 실행으로 블로그 초안, 소셜 게시물, 카드 등 여러 형식의 번들을 만듭니다.
• 이벤트 응답기. 이벤트 자동화와 짝지어집니다. 새 이메일, 병합된 PR, 새 Notion 페이지가 실행을 시작합니다. 자동화를 참조하세요.

피해야 할 함정

• 너무 좁음. 특정 입력 하나에만 맞는 워크플로는 취약합니다. 한 예시의 세부사항이 아니라 작업의 형식 자체를 겨냥하세요.
• 너무 모호함. *"마케팅을 도와줘"*는 너무 광범위해서 Okou가 언제 적용해야 할지 알 수 없습니다. 설명을 구체적으로 작성하세요.
• 하드코딩된 자격 증명. API 키를 지침에 절대 붙여 넣지 마세요. 대신 맞춤형 커넥터를 사용하세요. 자격 증명은 플랫폼에 남아 모델의 접근 범위 밖에 있습니다.
• 묻힌 출력 형식. 산출물이 어떤 모습이어야 하는지 명시하세요. 예: "세 항목의 번호 매긴 목록" 또는 "150단어 미만의 답장 초안."
• 접근 권한을 잊음. 공유 워크플로가 커넥터 접근 권한을 부여하는 것은 아닙니다. 연결된 계정, 요청된 권한, 그리고 사용할 수 있는 채팅 계정 제어를 확인하세요. Legacy Agents에서는 해당 워크플로의 소유 에이전트의 승인 설정도 확인하세요.

다음 단계

• 자동화로 트리거를 연결해 워크플로가 사용자의 개입 없이 실행되게 하세요.
• 워크플로를 누가 어떤 권한으로 실행하는지 에이전트에서 확인하세요.
• 워크플로가 접근할 수 있는 대상을 제한하는 방법은 권한에서 확인하세요.
• 끝까지 작성된 다섯 가지 예시는 예시 워크플로에서 확인하세요.