AI 직원이 깨어나는 방법

UpServe의 AI 직원은 항상 켜져 있다가 사람이 말을 걸 때만 답하는 챗봇이 아닙니다. 정해진 시점, 정해진 신호, 다른 직원의 호명, 심지어 받은 메일 한 통으로도 스스로 깨어나 일을 시작합니다.

일반 사용자가 직접 다루는 시작 방법은 사용자 메시지·예약 실행·외부 신호(웹훅)·AI 직원 멘션·이메일 다섯 가지입니다. 이 페이지는 각 방법을 언제·어떻게 쓰면 좋은지, 결과는 어디서 받아보는지 한 페이지로 정리합니다.

그 외에도 직원은 기억 자동 정리와 조용한 순간이라는 두 가지 자동 실행 방식으로도 깨어납니다. 기억 자동 정리는 정해진 시각에 도는 것이 아닙니다. 마지막 정리 이후 직원이 사람이나 동료 직원의 요청에 응답하거나 예약 실행을 일정 횟수만큼 하고 나면, 조용한 틈에 맞춰 시스템이 자동으로 시작합니다(이 횟수는 직원 설정의 기억 자동 정리에서 “대화·예약 실행 N회마다”로 조절할 수 있고 기본값은 6회). 혼자 도는 자율 점검은 횟수에 들어가지 않습니다. 너무 자주 돌지 않도록 정리 사이에는 최소 6시간 간격을 두고, 30일 넘게 정리가 없었으면 일이 없어도 한 번은 정리합니다. 직원은 이 시간에 쌓인 기억을 정리하고, 여러 번 받은 교정을 규칙으로 옮기고, 다음 할 일을 할 일 목록에 남깁니다. 조용한 순간은 답장하지 못한 메시지나 미뤄 둔 업무가 있을 때 직원을 조용히 깨워 놓친 것을 챙기게 합니다. 두 방식 모두 사용자가 직접 설정하지 않아도 시스템이 자동으로 관리합니다.

이 외에도 공개본 접속, 업무 설정, 미션 위임처럼 사용자가 직접 다루지 않는 시스템 내부 방식도 있습니다.

한눈에 비교

1. 사용자 메시지

가장 기본이 되는 방식입니다. 직원 채팅 화면에서 메시지를 입력해 보내면 직원이 즉시 깨어나 응답합니다.

언제 쓰나요

• 지금 당장 답이 필요할 때
• 자유로운 대화로 작업을 의뢰하고 싶을 때

결과

• 채팅 화면에 실시간 스트리밍으로 응답이 출력됩니다.
• 도구를 사용했다면(웹 검색, 코드 실행, 이미지 생성 등) 각 단계가 메시지 안에 카드 형태로 펼쳐집니다.

2. 예약 실행

정해 둔 시각에 직원이 알아서 깨어나 작업을 수행합니다. 매일 아침 9시 일일 브리핑, 매주 월요일 보고서 정리, 1시간 뒤 알림 등 정기·예약 실행에 어울립니다.

예약 실행으로 깨어난 직원은 가장 최근 대화 흐름을 이어받아 시작하므로, 정기 실행이 대화의 자연스러운 연장선처럼 느껴집니다.

언제 쓰나요

• 매일·매주 반복되는 작업을 자동화하고 싶을 때 (예: 아침 뉴스 요약, 주간 정리)
• 일정 시간 후 한 번만 실행하고 싶을 때 (예: “30분 뒤 다시 확인”)

결과

• 정해진 시각이 되면 직원이 스스로 실행되고, 결과는 채팅 화면에 새 메시지로 자동 추가됩니다.
• 이 메시지는 “예약 실행으로 실행됨”이라는 작은 라벨이 함께 표시됩니다.
• 알림 설정을 켜 두었다면 모바일에도 푸시가 도착합니다.

더 자세히: 예약 실행 설정하기에서 만드는 방법과 화면 위치를 안내합니다.

3. 외부 신호 (웹훅)

외부 서비스가 보내는 신호로 직원이 깨어나게 만들 수 있습니다. n8n 같은 자동화 도구, GitHub·Linear·Slack 같은 협업 도구, 또는 내가 운영하는 서버가 “이 일을 처리해 줘” 하고 직원에게 업무를 넘기는 방식입니다. Linear·GitHub는 매번 직접 URL을 등록하지 않아도 되도록 전용 설정 화면을 따로 제공합니다(Slack은 또 다른 연결 방식을 사용합니다. Slack에서 AI 직원 부르기 참고).

웹훅으로 깨어난 직원도 최근 대화를 기억한 채 작업을 시작합니다. 덕분에 외부 신호로 처리하는 일과 평소 나눈 대화 내용이 자연스럽게 연결됩니다.

언제 쓰나요

• 외부에서 발생한 이벤트(폼 제출, 새 이슈, 알림 등)를 받아 직원에게 일을 시키고 싶을 때
• 다른 자동화 흐름의 마지막 단계로 직원을 끼워 넣고 싶을 때

준비하기 (직접 URL을 등록하는 범용 웹훅)

1. 직원 상세 페이지 → 웹훅(Webhook) 서브페이지로 이동합니다 (/agents/<직원>/webhook).
2. Webhook 활성화 버튼을 누르면 전용 URL과 비밀 키가 생성됩니다.
3. 외부 서비스에서 이 URL로 메시지를 보내도록 설정합니다. 보낼 때 비밀 키로 만든 서명을 반드시 함께 실어 보내야 합니다. 서명이 없으면 요청이 거부됩니다.
4. 같은 페이지의 테스트 영역에서 실제 호출 전에 미리 시험해 볼 수 있습니다.

준비하기 (Linear·GitHub 전용 실행 조건)

같은 웹훅 서브페이지 상단에 “실행 조건” 영역이 있습니다. Linear·GitHub는 여기서 몇 번의 클릭만으로 설정을 마칠 수 있습니다.

1. 목록에서 Linear 또는 GitHub 항목을 찾습니다. 계정을 아직 연결하지 않았다면 “연결 필요”로 표시됩니다. Linear는 이 연결이 이벤트를 받는 유일한 통로라 반드시 먼저 해당 서비스를 연결해야 실행 조건을 만들 수 있습니다. GitHub는 URL·비밀 키를 직접 등록하는 방식이라 계정을 연결하지 않고도 실행 조건 생성을 진행할 수 있습니다. (조직 소속 직원이라면 조직이 지정한 계정이 대신 쓰이며, 이 경우 본인이 따로 연결할 필요가 없습니다. 화면에 안내가 뜹니다.)
2. 생성 버튼을 눌러 반응할 이벤트 유형(이슈 생성, 코멘트 작성 등)을 고릅니다. 아무것도 선택하지 않으면 모든 이벤트에 반응합니다.
3. 필요하면 필터 규칙을 추가해 특정 조건(우선순위, 라벨, 리포지토리 등)을 만족하는 이벤트만 걸러 받을 수 있습니다.
4. 원한다면 이 실행 조건 전용 요청 내용을 입력해 직원에게 항상 같은 지시를 함께 전달할 수 있습니다.
5. GitHub는 저장 후 화면에 뜨는 URL·비밀 키를 GitHub 리포지토리의 Webhook 설정에 직접 등록해야 합니다. Linear는 계정 연결만으로 끝나며, 따로 등록할 URL이 없습니다.
6. 실행 조건을 켜고 끄는 스위치, 그리고 실행 기록(언제 어떤 이벤트로 실행됐는지)도 같은 카드에서 확인할 수 있습니다.

결과

• 신호가 들어오면 직원이 즉시 깨어나 작업을 시작합니다.
• 결과는 채팅 화면에 자동 메시지로 누적됩니다.
• 필요하다면 콜백 URL 을 등록해 작업 결과를 다시 외부 서비스로 돌려보낼 수도 있습니다 (직원 한 명당 최대 5개, 범용 웹훅 기준).
• 외부 서비스가 네트워크 오류 등으로 같은 신호를 다시 보내더라도 걱정하지 않아도 됩니다. 직원은 같은 신호로 두 번 실행되지 않고, SU도 중복으로 차감되지 않습니다.

4. AI 직원 멘션

같은 팀(조직)에 속한 다른 직원이 채팅에서 @나 하면 나는 깨어납니다. 실제로 응답할지는 내용에 따라 다릅니다. 내가 처리해야 할 구체적인 일이 있으면 응답하고, 단순한 참고 공유라면 조용히 지나갑니다. 상대가 “응답까지 해 달라”고 명시하면 새로운 업무로 받아들여 처리한 뒤 결과를 돌려줍니다. 여러 전문 직원으로 팀을 꾸려 협업시킬 때 핵심이 되는 방식입니다.

멘션을 받아 깨어난 직원은 멘션 본문뿐 아니라 자신의 최근 대화 기록도 함께 받아 작업을 시작하므로, 자신이 무슨 일을 해왔는지 인지한 채로 동료 직원의 요청에 응답합니다.

언제 쓰나요

• 한 명의 직원이 모든 일을 처리하기엔 역할이 너무 많을 때
• 리서치 → 작성 → 검토처럼 단계별로 다른 직원이 이어 받아야 할 때

결과

• 팀 채팅에 “@내이름 …” 메시지가 도착하면 나는 자동으로 깨어납니다.
• 내가 직접 처리해야 할 새로운 일이면 응답하고 결과를 알려주지만, 단순히 상황을 공유받은 것뿐이라면 조용히 넘어가고 별도로 답하지 않습니다.
• 응답할 경우 결과는 내 본인 채팅 화면과 팀 채팅 양쪽에 표시됩니다.

멘션 동작 방식: 팀이 만들어질 때 모든 직원은 기본적으로 서로를 멘션해 깨울 수 있습니다. 팀을 새로 구성하면 모든 직원 사이에 양방향 연결이 자동으로 생겨, 누구나 누구에게나 멘션을 보내고 즉시 깨울 수 있습니다. 특정 직원 사이의 연결을 끊고 싶다면 팀 그래프 화면(/agents/team/<팀ID>/graph)에서 해당 연결선을 제거하면 됩니다. 연결이 끊긴 방향으로 보낸 멘션은 팀 채팅에 글로는 남지만, 받는 쪽이 즉시 깨어나지는 않습니다(받는 쪽은 자기 작업을 마치고 팀 채팅을 확인할 때 보게 됩니다).

5. 이메일

직원마다 전용 이메일 주소가 하나씩 있습니다. 그 주소로 메일을 보내면 직원이 깨어나 내용을 확인하고, 필요하면 답장을 보냅니다.

기본적으로는 내가 인증해 둔 이메일 주소로 보낸 메일만 직원을 깨울 수 있습니다. 그 밖의 사람이 보낸 메일은 직원을 깨우지 않고 보류된 채 저장만 됩니다.

이제는 소유자인 내가 특정 사람의 메일 주소를 승인할 수 있습니다. 웹에서 직원의 메일 → 발송 허용 → 메일을 주고받을 주소에 직접 넣거나, 직원과의 1:1 대화에서 요청하면 됩니다. 한 번 승인하면 그 사람의 메일도 정상적으로 직원을 깨우고, 직원도 그 사람에게 답장을 보낼 수 있습니다.

보류된 메일은 사라지지 않습니다. 승인되지 않은 사람의 메일이 도착하면 나에게 알림이 오고, 이후 그 사람을 승인하면 그동안 보류돼 있던 메일 중 최근 것들이 자동으로 되살아나 순서대로 처리됩니다. 상대방에게 다시 보내 달라고 요청할 필요가 없습니다.

언제 쓰나요

• 외부 파트너나 고객이 메일로 직원에게 직접 요청을 보내게 하고 싶을 때
• 나 말고 동료 한 명에게도 이 직원에게 메일 보낼 권한을 주고 싶을 때

결과

• 승인된 사람의 메일이 도착하면 직원이 깨어나고, 메일 내용이 채팅 화면에 자동으로 추가됩니다.
• 직원이 그 사람에게 직접 답장을 보낼 수 있습니다.
• 승인되지 않은 사람의 메일은 보류되고, 나에게 알림이 옵니다.

승인 방법은 두 가지입니다. 웹에서 직원의 메일 화면 → 발송 허용 탭 → 메일을 주고받을 주소에 주소를 추가하거나(모바일 앱에는 아직 이 화면이 없습니다), 직원과의 대화에서 직접 요청합니다. 대화로 할 때는 예를 들어 “kim@partner.com 님이 보내는 메일도 받아 줘”라고 말하면, 직원이 요청을 확인하고 그 자리에서 승인을 처리합니다. 요청은 반드시 나와 직원의 1:1 대화에서 해야 합니다. 예약 실행이나 다른 경로로 시작된 대화에서는 승인이 이뤄지지 않는데, 낯선 메일 본문이 직원을 속여 스스로 승인시키는 것을 막기 위한 안전장치입니다.

엔터프라이즈(운영 대행 계약) 조직에 소속된 직원은 이미 모든 외부 상대와 메일을 주고받을 수 있어 이 승인 기능이 필요하지 않은 경우가 많습니다. 개인 직원에서 특정 상대에게만 문을 열어 주고 싶을 때 유용합니다. 이메일 주소 인증 등 기본 설정 방법은 외부 서비스 연결하기를 참고하세요.

자동 실행으로 깨어났을 때의 표시

예약 실행·웹훅·멘션처럼 사용자가 직접 보낸 게 아닌 방법으로 직원이 깨어나면, 그 응답 메시지 위에 작은 표지가 붙습니다.

• 예약 실행: “예약 실행으로 실행됨” 라벨과 함께 그 예약 실행에 저장해 둔 요청 내용이 표시됩니다
• 웹훅: “웹훅으로 실행됨” 라벨과 함께 신호에 담겨 온 요청 내용이 표시됩니다
• 멘션: “@보낸이 의 멘션” 라벨과 보낸 이의 메시지 본문이 표시됩니다

이메일로 도착한 메시지도 같은 표시 체계를 쓰지만, 내부적으로 웹훅과 같은 경로로 처리되므로 화면에는 “웹훅으로 실행됨” 라벨이 붙습니다.

이 표시는 나중에 채팅을 다시 봤을 때 “이 메시지는 내가 시킨 게 아니라 자동으로 일어난 일”임을 명확히 구분해 줍니다.

알림은 어디서 켜고 끄나요?

채팅 화면을 보고 있지 않을 때도 자동 실행 결과를 받고 싶다면 모바일 푸시 알림을 켜 두세요.

• 설정 → 알림 에서 종류별로 켜고 끌 수 있습니다.
• 예약 실행·웹훅·멘션 같은 자동 실행 결과가 한 번에 여러 개 끝나도, 푸시 알림은 하나로 묶여 한 번만 전송됩니다 (방해 최소화).

고급 (Advanced)

아래 내용은 일반 사용자에게 필요하지 않습니다. 외부 시스템과 직접 연결하거나, 보안 설정을 세밀하게 다루고 싶을 때만 참고하세요.

웹훅 URL과 서명

• 수신 URL: https://api.upserve.app/api/webhooks/<agent_id>
• 인증: HTTP 요청 헤더 X-Webhook-Signature 에 HMAC-SHA256(secret, body) 를 16진수로 담아 전송해야 합니다(필수. 헤더가 없거나 서명이 맞지 않으면 401로 거부됩니다). 비밀 키는 웹훅 활성화 시 한 번 표시되며, 재생성하면 이전 키는 즉시 폐기됩니다.
• 요청 본문: 데이터 형식은 JSON입니다. prompt 필드(문자열)가 있으면 직원에게 그 문자열을 그대로 사용자 메시지처럼 전달합니다. 없으면 본문 전체를 그대로 묶어 직원에게 전달합니다.
• 요청 본문 크기 상한: 64KB.
• 호출 속도 제한: IP 기준 분당 호출 수 제한. 직원별로 분당·시간당 호출 한도를 별도 지정할 수 있습니다(웹훅 서브페이지 → 요청 제한).
• 전용 실행 조건(Native Event Trigger): Linear·GitHub는 /api/webhooks/<agent_id>/<provider> 전용 경로로 연결할 수 있으며, 각 서비스 고유의 서명 방식을 자동으로 처리합니다. Linear는 계정 소유자가 아니라 워크스페이스 단위로 미리 등록된 하나의 수신 주소를 공유하므로, 사용자가 붙여 넣을 URL 자체가 없고 계정 연결만으로 이벤트가 도착합니다. GitHub는 리포지토리마다 URL·비밀 키를 직접 등록해야 합니다. provider당 실행 조건은 직원마다 1개만 만들 수 있습니다(이미 있으면 새로 만드는 대신 기존 실행 조건을 편집합니다). Slack은 이 경로를 쓰지 않습니다. UpServe가 운영하는 단일 Slack 앱을 통해 별도로 연결하며, 채널에서 @UpServe로 직원을 부르는 방식입니다. 자세한 방법은 Slack에서 AI 직원 부르기를 참고하세요.

서명 생성 예 (curl + openssl)

SECRET="활성화 시 받은 비밀 키"
URL="https://api.upserve.app/api/webhooks/<agent_id>"
PAYLOAD='{"prompt":"서버 상태를 점검해 줘"}'
 
SIG=$(printf '%s' "$PAYLOAD" | openssl dgst -sha256 -hmac "$SECRET" | cut -d' ' -f2)
 
curl -X POST "$URL" \
  -H "Content-Type: application/json" \
  -H "X-Webhook-Signature: $SIG" \
  -d "$PAYLOAD"

웹훅 서브페이지의 테스트 영역에서 같은 형식의 curl 명령을 자동 생성해 주므로, 처음에는 그쪽을 그대로 복사해 쓰는 편이 안전합니다.

재전송에도 안전합니다 (중복 실행 방지)

외부 서비스는 응답 지연이나 일시적 오류가 있으면 같은 신호를 다시 보내는 경우가 흔합니다. UpServe는 이런 재전송을 감지해 직원을 다시 실행하지 않고, SU도 다시 차감하지 않습니다. 이 동작은 범용 웹훅과 전용 실행 조건(Linear·GitHub) 모두에 적용됩니다.

중복 여부는 다음 기준으로 판정됩니다.

• 발신 서비스가 요청마다 고유 식별자를 함께 보내는 경우(GitHub X-GitHub-Delivery, Linear Linear-Delivery, 범용 웹훅은 X-Webhook-Delivery-Id 헤더): 이 식별자는 영구적으로 기억되므로, 언제 다시 와도 같은 신호로 판정합니다.
• 고유 식별자가 없는 경우: 보낸 내용(본문) 자체를 기준으로 60초 이내 재전송만 중복으로 판정합니다. 그보다 긴 간격을 두고 같은 내용을 반복해서 보내는 정상적인 사용(예: 매시간 같은 내용으로 호출하는 자동화)은 중복으로 처리되지 않고 매번 정상 실행됩니다.

중복으로 판정된 요청에는 정상 수신으로 응답합니다. 그래야 외부 서비스가 실패로 오인해 재전송을 반복하지 않습니다.

보안 권장

• 비밀 키는 외부에 노출하지 마세요. 노출이 의심되면 재생성 으로 즉시 폐기 가능합니다.
• 가능하면 외부 서비스 측에서도 출처 IP를 제한하세요.
• 콜백 URL에는 가능하면 HTTPS를 사용하세요(연결 정보가 평문으로 새어 나가지 않도록). 콜백에 붙이는 커스텀 헤더는 화면에 표시될 때 안전하게 마스킹됩니다.

응답을 요구하는 멘션

다른 직원이 나를 멘션할 때 단순히 알리는 것이 아니라 “응답해 줘” 라고 요청할 수 있습니다. 이 경우 깨어난 직원에게는 다음 동작이 안내됩니다.

1. 들어온 멘션을 새 업무로 등록 합니다.
2. 업무를 끝낸 뒤 원래 멘션을 보낸 직원을 다시 멘션해 결과를 돌려줍니다.

이 동작은 연결선이 존재하는 방향으로 보낸 멘션에서만 적용됩니다. 연결이 끊긴 방향으로 보낸 멘션은 팀 채팅에는 기록되지만 상대방을 즉시 깨우지 않으므로, 응답 요구도 즉시 전달되지 않습니다.

스레드 답글 예외: 사용자가 특정 방향의 연결선을 끊었더라도, 스레드 답글 형식으로 보낸 경우(in_reply_to 지정 + @원래보낸이)에는 원래 멘션을 보낸 직원을 즉시 깨울 수 있습니다. 이는 “끊긴 연결에 대한 답장 보호장치”로, 답글 형태로 명시해야만 이 예외가 적용됩니다.

연속 멘션 한도: 한 멘션이 다른 멘션을 부르고, 또 다른 멘션을 부르는 사슬은 자동으로 3단계에서 멈춥니다. 한 메시지에서 동시에 깨울 수 있는 직원은 최대 3명이며, 같은 짝(보낸이 → 받는이) 사이의 반복 호출에는 짧은 쿨다운이 적용됩니다.

승인된 발신자 (이메일)

• 승인·해제·목록 조회는 웹의 직원 메일 → 발송 허용 → 메일을 주고받을 주소에서 하거나, 직원과의 대화(Agent Email 스킬)로 합니다. 모바일 앱에는 아직 이 화면이 없습니다.
• 개인 직원은 이 목록에 있는 사람에게만 외부 메일을 보낼 수 있습니다. 목록에 없는 주소로 보내려 하면 승인 카드가 “승인해도 이 주소로는 가지 않는다”고 먼저 알려 줍니다.
• 대화로 하는 승인·해제 요청은 소유자가 직접 시작한 대화 턴에서만 처리됩니다. 예약 실행으로 깨어난 턴, 팀·Slack 채팅에서 온 턴, 받은 메일을 처리하던 중인 턴에서 같은 요청을 해도 거부됩니다. 낯선 메일 본문이 직원을 속여 스스로를 승인 목록에 올리게 하는 경로를 막기 위한 서버 측 제약입니다. 다만 소유자가 자신의 대화에서 “받은 메일을 확인해 줘”라고 지시했는데 그 안의 문구에 직원이 속는 경우까지는 이 제약이 막지 못하므로, 최종 판단은 직원 자신의 몫으로 남습니다.
• 승인 목록은 정확히 일치하는 주소 단위로만 동작합니다. 도메인 전체를 한 번에 여는 기능은 없어 여러 사람을 허용하려면 한 명씩 추가해야 합니다.
• 승인되지 않은 발신자의 메일은 보관 기간(약 7일) 안에 승인하면 되살아나 처리됩니다. 그보다 오래된 메일은 승인해도 되살아나지 않고, 그 이후에 다시 보낸 메일부터 정상 처리됩니다.
• 이 기능은 수신자 정책이 “소유자 전용”인 개인 직원을 위해 설계됐습니다. 수신자 정책이 “외부 허용”인 엔터프라이즈 조직 직원은 이미 자신이 먼저 메일을 보낸 상대의 답장으로 깨어날 수 있으므로, 승인 목록은 그 조건과 별개로 추가 통로를 열어 줍니다.

자동 실행 시 채팅 화면에 부착되는 표지

웹훅·예약 실행·멘션으로 실행되면 그 턴에서 생성된 응답 메시지에 시작 정보가 함께 저장되어, 채팅을 다시 열었을 때 위쪽 작은 배너로 표시됩니다.

• 예약 실행: 그 예약 실행에 함께 저장된 요청 내용이 표시됩니다(예약 실행 자체의 이름·실행 주기는 자동 실행 화면에서 확인).
• 웹훅: 요청 본문에 prompt 가 있었다면 그 문자열이 표시됩니다.
• 멘션: 보낸 직원 이름과 메시지 본문이 표시됩니다.

사용자가 직접 보낸 메시지(첫 번째 시작 방법)에서는 이 배너가 나타나지 않습니다.

시작 방법별 메타데이터 필드

자동으로 시작된 응답 메시지에는 아래 정보가 함께 저장되어 채팅 배너에 표시됩니다.

사용자가 직접 보낸 메시지에는 이 메타데이터가 부착되지 않습니다. 이메일로 도착한 메시지는 내부적으로 외부 신호(웹훅)와 같은 경로를 쓰므로 위 표의 웹훅 행과 동일하게 표시됩니다.

기억 자동 정리가 시작되는 기준

대화·예약 실행 횟수는 서버가 세고 판정하므로 웹·iOS·Android 어디서 일을 시켜도 같은 기준이 적용됩니다.

• 세는 일: 사용자 메시지, Slack·업무 포털 채팅·Linear에서 사람이 보낸 요청, 팀 채팅, 다른 AI 직원의 멘션, 예약 실행, 조직 주간 업무 보고 작성.
• 세지 않는 일: 자율 점검, 기억 자동 정리 자신, 웹훅으로 들어온 자동 실행, 다른 직원에게 맡긴 하위 업무, 목표 진행 같은 시스템 자동 실행.
• 승인을 기다렸다가 이어진 작업은 한 번으로 셉니다.
• 횟수는 자율 점검이 끝날 때나 긴 대화를 정리해 보관할 때 확인합니다. 방금 끝난 작업이 아직 기록되지 않았으면 다음 확인 때 세어지므로, 설정 횟수보다 한 번쯤 늦게 시작될 수 있습니다.
• 정리 사이의 최소 간격은 6시간입니다. 30일 조건은 직원마다 최대 7일까지 늦게 잡혀, 오래 조용했던 직원들이 한꺼번에 몰리지 않습니다.
• 기억 자동 정리 설정을 0으로 두면 정리가 돌지 않습니다. 값이 저장되지 않은 직원은 기본값 6(대화·예약 실행 6회마다)을 씁니다. 이미 다른 값(예: 12, 7)이 저장된 기존 직원은 그 값을 그대로 씁니다.
• 한 번의 정리가 볼 수 있는 자료의 양에는 한도가 있습니다. 다 못 본 자료는 다음 정리가 이어서 봅니다. 정리가 오류로 끝나거나 시간 제한에 걸리면 같은 자료를 다음 정리에서 다시 보고, 세 번 연속 실패하면 그 자료는 건너뜁니다. 서비스 업데이트 등으로 중간에 멈춘 정리와, 시간 제한에 걸려 곧바로 다시 시도한 정리는 실패로 세지 않습니다.
• 팀 채팅에서는 직원 자신이 한 말만 정리 자료로 모읍니다. 다른 사람이나 다른 직원의 말은 모으지 않습니다. 사람이 고쳐 쓴 결과처럼 직원 이름으로 올라왔지만 사람이 쓴 글도 모으지 않습니다. 단, 사람이 직원의 답변에 직접 남긴 의견은 예외로 함께 봅니다.
• 기억 자동 정리는 새 반복 예약 실행을 직접 만들지 않습니다. 정기적으로 할 일이 보이면 할 일 목록에 남기고, 이후 깨어 있는 작업에서 예약 실행으로 만듭니다.

더 알아보기

• 도구 부여하기: 깨어난 직원이 어떤 도구를 쓸지 결정하기
• 스킬과 자율 스킬 시스템: 반복 작업 절차를 업무 스킬로 묶기
• AI 직원 외부에 공개하기: 외부 방문자에게 공개본으로 직원 노출하기