대부분의 "업무용 AI"는 여전히 구석에 있는 챗봇(chatbot)에 불과합니다. 당신이 질문하면 답변을 내놓을 뿐, 실제 업무는 여전히 당신의 몫입니다. 나는 그 반대를 원했습니다. 제안을 받는 것이 아니라, 전체 작업을 넘겨주면 결과물을 돌려받을 수 있는 무언가를 말입니다.

그래서 자동화(automations)를 구축하는 대신, 나는 직원을 채용하기 시작했습니다. 이것이 실제로 실무에서 무엇을 의미하는지, 그리고 유용한 부분은 어디인지 소개합니다.

첫째: 어떤 API든 코드 없이 도구가 된다

직원이 유용해지기 위해서는 무언가를 할 수 있는 능력이 필요합니다. AI에게 새로운 능력을 부여하는 일반적인 방법은 통합(integration) 코드를 작성하는 것입니다. 문서를 읽고, 엔드포인트(endpoints)를 모델링하고, 인증(auth)을 연결하고, 에러를 처리하는 과정이죠. 각각 반나절씩 걸립니다.

대신 이렇게 해보세요: 도메인(domain)을 붙여넣으세요. 만약 모델이 이미 해당 API를 알고 있다면, 즉시 작동하는 도구를 얻게 됩니다. 만약 모른다면, 모델이 검색하고, 여러 페이지에 걸친 문서를 스크레이핑(scrapes)하며, 엔드포인트를 하나의 스키마(schema)로 조립합니다. 키(key)를 추가하고 활성화하면 끝입니다. 이제 해당 API는 당신의 직원들이 호출할 수 있는 네이티브 도구(native tool)가 됩니다. 직접 작성한 JSON도, 글루 코드(glue code)도 필요 없습니다.

이것만으로도 대부분의 잡무(busywork)가 제거되었습니다. 하지만 커넥터(connectors)는 그저 원재료일 뿐입니다. 흥미로운 부분은 그것을 누가 사용하는가입니다.

직원 채용하기

직원은 프롬프트(prompt)가 아닙니다. 다음과 같은 요소를 갖춘 채용 대상입니다:

• 역할 (A role). 무엇을 위한 것인지, 무엇이 "훌륭한" 결과인지, 그리고 그 경계가 어디인지 정의합니다. 이것은 인간을 채용할 때와 마찬가지로, 직원이 유용한지 아니면 쓸모없는지를 결정하는 부분입니다.
• 당신이 선택한 두뇌 (A brain you choose). 각 직원은 당신이 선택한 모델 — Claude, GPT, 또는 Gemini — 위에서 실행됩니다. 따라서 까다로운 역할에는 추론 능력이 뛰어난 모델을, 반복적인 역할에는 더 저렴하고 빠른 모델을 배치할 수 있습니다.
• 사용이 허용된 도구 (Tools it's allowed to use). 당신은 직원에게 업무에 꼭 필요한 능력만을 부여하며, 그 외의 것은 주지 않습니다.

직원에게 부여할 수 있는 도구 세트가 핵심입니다:

• Email (이메일) — 받은 편지함을 읽고, IMAP/SMTP를 통해 메시지를 보내거나 답장합니다.
• Webhooks (웹훅) — 외부 이벤트가 워커(worker)를 깨우고, 처리해야 할 페이로드(payload)를 전달할 수 있습니다.
• Memory (메모리) — 워커가 실행 간의 정보를 기억하므로, 동일한 작업을 반복하거나 프로젝트의 맥락을 놓치지 않습니다.
• File storage (파일 스토리지) — 워커가 생성하는 문서와 결과물(artifacts)을 위해, 재시작 후에도 유지되는 영구적인 저장소입니다.
• Site logins (사이트 로그인) — 제3자 사이트에 대한 워커의 자격 증명(credentials)을 저장합니다(암호화되어 저장되며, 쓰기 전용이므로 비밀번호를 다시 읽을 수 없음). 이를 통해 워커는 당신을 대신하여 해당 사이트에 로그인하고 실제 업무를 수행할 수 있습니다.

Tasks: 당신 없이 시작되는 업무

워커는 태스크(task)를 소유합니다. 태스크는 당신이 앉아 있는 상태가 아니라, 트리거(trigger)에 의해 실행됩니다:

• 스케줄 (schedule) (매일 아침, 이틀마다, 또는 cron 설정에 따라),
• 이메일 (email) 이 도착했을 때,
• 웹훅 (webhook) 이 발생했을 때.

따라서 콘텐츠 워커는 정해진 주기에 따라 초안을 작성하고 게시할 수 있으며, 편지함 워커는 메일이 도착하는 대로 분류(triage)할 수 있고, 모니터링 워커는 이벤트가 발생하는 즉시 반응할 수 있습니다. 당신은 결과물만 확인하면 됩니다.

The supervisor: 팀을 통제 상태로 유지하기

소프트웨어에 자율성을 부여하는 것은 그것을 제어할 수 있을 때에만 안심할 수 있는 일입니다. 그것이 바로 관리자(supervisor) 계층이며, 제가 이것 없이는 운영을 거부했을 핵심 요소입니다:

• 채용 및 해고 (Hire and fire). 특정 역할을 위해 새로운 워커를 생성하거나, 일시 중지하거나, 완전히 은퇴(retire)시킵니다.
• 태스크 할당 및 조정 (Assign and adjust tasks). 워커에게 태스크를 부여하고, 스케줄을 변경하며, 지침(instructions)을 수정하거나 비활성화합니다.
• 수행 내용 모니터링 (Watch what it does). 모든 실행은 로그(log)로 기록됩니다. 각 워커가 무엇을, 언제, 왜 했는지 확인할 수 있습니다.
• 위험한 작업 승인 (Approve the risky stuff). 외부 세계로 전달되는 모든 것(메일 발송, 게시, 포스팅 등)은 승인 게이트(approval gate)를 거칠 수 있습니다. 워커가 _제안(proposes)_하면 당신이 승인하고, 그 후에 실행되는 방식입니다. 각 워커에게 어느 정도의 재량권을 줄지는 당신이 결정하며, 신뢰가 쌓임에 따라 그 범위를 넓힐 수 있습니다.

마지막 부분이 바로 "불안한 에이전트"와 "명확한 직무를 가진 팀원"을 가르는 차이점입니다. 워커는 업무를 수행하고, 인간은 최종 승인권을 가진 존재로 남습니다.

이것이 솔직히 마법이 아닌 부분들

분명히 말해둘 가치가 있습니다:

• 워커(Worker)의 역량은 부여된 역할(Role)만큼만 발휘됩니다. 모호한 지시(Vague instructions) → 모호한 결과물(Vague output). 조직 설계(Org-design)에 대한 사고가 사라지는 것이 아니라, 그 책임이 당신에게로 옮겨옵니다.
• 노코드 커넥터(No-code connectors)는 대상 API의 문서(Docs)에 의존합니다. 깔끔한 문서 → 깔끔한 도구; 문서화되지 않은 이상한 엔드포인트(Endpoint) → 당신은 여전히 이를 계속 다듬어줘야 할 것입니다.
• 이것은 호스팅된 플랫폼이며 현재 클로즈 베타(Closed beta) 상태이므로, 민감한 데이터와 미흡한 부분들을 적절히 주의하여 다루어야 합니다.

이 중 어느 것도 제가 사용하는 방식에 있어 결정적인 결함은 아니지만, "워커를 채용한다"는 것이 "판단을 생략한다"는 의미는 아닙니다.

시도해 보세요

현재 클로즈 베타(Closed beta) 단계입니다. 첫 번째 빌더 그룹은 코어 기능에 대한 평생 액세스 권한과 함께 일부 프로바이더 크레딧(Provider credit)을 받게 됩니다. 당신이 잠든 동안 일하는 작은 팀을 구축하고 싶다면: (https://toolweave.dev/blog/en/build-a-team-of-ai-workers)

이미 에이전트(Agents)를 운영 중인 분들께 질문합니다: 실제로 가장 먼저 채용하고 싶은 역할은 무엇인가요? 받은 편지함 분류(Inbox triage), QA 봇, 콘텐츠 워커, 아니면 다른 무엇인가요? 그리고 승인 없이 절대로 시키지 않을 일은 무엇인가요?