OpenCode를 활용한 자율형 Slack 에이전트 구축하기

OpenCode에서 실행되며 Slack에 상주하는 저의 운영 에이전트인 Pipa는 지루한 문제로부터 탄생했습니다.

코딩 업무가 아닌 작업들을 코딩 에이전트 (coding agents)에게 맡기면 맡길수록, 그들이 여전히 저의 노트북과 터미널, 그리고 저의 주의력을 필요로 한다는 점이 점점 더 번거로워졌습니다.

저는 계획 수립, 작성, 조사, 리뷰, 리포지토리 정리 (repo cleanup), 콘텐츠 워크플로우 (content workflows), 그리고 스튜디오 운영에 이르기까지 로컬 작업을 OpenCode에 맡기고 있었습니다. 그 작업 중 일부는 크론 잡 (cron jobs)과 반복적인 에이전트 루프 (agent loops)가 되었습니다.

그래서 Pipa는 Slack으로 이동했습니다.

Slack은 주제별 채널, 작업별 스레드 (threads), 그리고 무슨 일이 일어났는지 확인할 수 있는 공유 공간을 제공합니다. Pipa는 자율적으로(autonomously) 일할 수 있지만, 저는 여전히 그녀를 팀원처럼 대화할 수 있습니다.

다른 팀들도 같은 움직임을 보이고 있습니다. Duolingo는 180개 이상의 MCP 도구를 갖춘 AI Slackbot을 구축하여 주간 활성 사용자(weekly active users) 250명을 달성했습니다. Shopify는 병합된 풀 리퀘스트 (pull requests) 8개 중 1개를 공동 작성한 Slack 네이티브 에이전트인 River를 공유했습니다. Mintlify는 자사의 문서 에이전트가 샌드박스 (sandboxes) 내에서 OpenCode와 Daytona 위에서 실행된다고 밝혔습니다.

작동 방식

Pipa의 이면에 있는 아키텍처 (architecture)는 다음과 같습니다:

각 도구는 고유한 역할을 수행합니다.

• Slack은 대부분의 업무가 시작되고 답변이 도달하는 곳입니다. Slack은 Pipa에게 메시지, 요청자, 워크스페이스 (workspace), 스레드 (thread), 그리고 전달 대상을 제공합니다.

• 게이트웨이 (gateway)는 요청을 받는 웹 서비스입니다. 저는 이를 Fly에 호스팅합니다. 게이트웨이는 Slack 이벤트, 자동화 API 호출, 트리거 (trigger) 요청, Composio 웹훅 (webhook), Inngest 호출, 그리고 런타임 (runtime) 호출을 수락합니다.

• Inngest는 작업을 깨웁니다. 이는 스케줄링 (scheduling), 재시도 (retries), 취소 (cancellation), 동시성 (concurrency), 그리고 실행 핸드오프 (execution handoff)를 처리합니다.

• E2B는 샌드박스 (sandbox)입니다. 에이전트에게 작업을 수행할 수 있는 자체 컴퓨터를 제공합니다.

• OpenCode는 에이전트 하네스 (agent harness)입니다. 파일을 편집하고, 명령어를 실행하며, 도구를 호출하고, 리포지토리 (repos)에서 작업하며, 구조화된 출력 (structured output)을 반환하는 두뇌 역할을 합니다.

• Composio는 외부 트리거 (external triggers)와 도구 통합 (tool integrations)을 처리합니다. 다른 앱에서 무언가 발생했을 때 게이트웨이를 깨울 수 있으며, Slack에서 도구 연결을 쉽게 추가할 수 있게 해줍니다.

자율성 (autonomy) 구성 요소가 필요하지 않다면, Slack, 샌드박스, 그리고 에이전트 하네스만으로도 상당히 많은 일을 해낼 수 있습니다.

"자율성" 구축하기

Slack 메시지가 샌드박스 내에서 OpenCode를 시작하는 설정까지만 구축해도 충분한 이점을 얻을 수 있습니다. 이미 Slack을 주로 사용하고 있다면, 이는 귀하와 팀의 마찰 (friction)을 줄여줍니다. 스레드 (threads)가 워크스페이스 (workspaces)가 됩니다. 터미널 (terminal)이나 다른 에이전트 UI 안에 머물지 않고도 여러 작업을 동시에 진행할 수 있습니다.

조금 더 다듬으면, 에이전트가 스스로 더 많은 일을 수행하기 시작할 수 있습니다.

기본 샌드박스 루프 (sandbox loop) 이후에 제가 추가하는 구성 요소들은 다음과 같습니다:

• 캐릭터 및 지침 파일 (Character and instruction files). OpenClaw는 soul.md, heartbeat.md, character.md와 같은 파일들을 대중화했습니다. OpenCode 설정에도 동일한 종류의 파일들을 넣을 수 있습니다. 이 파일들은 행동 양식을 형성하고, 표준을 설정하며, 에이전트에게 더 많은 개성을 부여합니다.

• 자동화, 워크플로우 및 트리거 (Automations, workflows, and triggers). 이 부분에서 저는 가장 큰 이점을 얻습니다. Inngest는 정해진 시간에 에이전트와 샌드박스 (sandbox)를 깨웁니다. 때로는 프롬프트가 구체적입니다: 매일 아침 이 대상에 대해 이 기술 (skill)을 실행하라. 때로는 하트비트 (heartbeat)에 더 가깝습니다: 현재 상태를 살펴보고, 판단을 내린 뒤, 무엇에 주의를 기울여야 할지 결정하라. 모든 실행이 시간 기반으로 시작되는 것은 아닙니다. 많은 SaaS 도구들이 이벤트를 전송합니다. 만약 어떤 일이 발생했을 때 에이전트가 깨어나서 기술을 실행하기를 원한다면, 트리거 (trigger)를 생성하세요.

• 도구 액세스 (Tool access). 저는 광범위한 도구 액세스를 쉽게 만들어주는 Composio를 사용합니다. 에이전트에게 무언가를 제공해야 할 때, 저는 링크를 클릭합니다. 만약 에이전트가 차단된다면, Slack에 무엇이 필요한지 게시할 수 있고, 저는 그것을 연결해 줄 수 있습니다. 에이전트가 제가 사용하는 것과 동일한 일상적인 도구들에 접근할 수 있게 되면 많은 일이 일어납니다.

• 기술 (Skills). 에이전트 기술은 에이전트에게 무언가를 쓰고 수행하는 방법을 가르칩니다. 이는 자동화에서 더 중요하게 작용하는데, 저의 예약된 프롬프트 중 상당수가 "이 대상에 대해 이 기술을 실행하라"와 같은 형태이기 때문입니다. 기술이 로직 (logic)을 보유합니다. 공개된 Pipa 기술들은 Pipa skills repo에 있습니다.

• 메모리 (Memory). 저는 이를 위해 Supermemory를 사용합니다. 이전에는 Pipa가 컨텍스트 (context) 파일들을 로드하고 이를 업데이트해야 함을 인지했습니다. 메모리 도구는 목표, 선호도, 최신 비즈니스 상태, 그리고 실행 간에 유지되어야 하는 세부 사항들과 같이 팀원과 같은 회상 능력을 추가해 줍니다. 좋은 메모리 도구는 에이전트가 더 많은 자율성을 갖게 되었을 때 중요한, 메모리를 대체하거나 삭제하는 방법도 알고 있습니다.

제가 현재 가장 좋아하는 패턴은 Linear를 사용하는 것입니다. 저는 그곳에 작업 목록을 유지하며, 그러면 Pipa가 깨어나서 작업을 선택하고, 수행하고, 완료한 뒤, 제가 검토할 수 있도록 남겨둡니다.

왜 OpenCode인가

Claude SDK, OpenAI SDK, LangChain, OpenClaw, Hermes, Codex 또는 다른 에이전트 시스템 (agent system)을 사용하더라도 이 글에서 설명하는 패턴을 그대로 적용할 수 있습니다.

제가 OpenCode를 선호하는 데에는 몇 가지 이유가 있습니다.

1. 추론(reasoning)하기 쉽습니다.

저는 OpenClaw와 Hermes로 실험을 진행해 보았고, 매우 재미있었습니다. 이들은 또한 더 강력한 자율성 패턴 (autonomy patterns)을 중심으로 구축되어 있습니다. 하지만 코딩 에이전트 (coding agent)만큼 결정론적 (deterministically)으로 실행되도록 만드는 데에는 더 많은 어려움을 겪었습니다. 제 실력 문제라고 할 수도 있겠지만, OpenCode는 작동할 때와 고장 날 때의 이유를 이해하기가 저에게 더 쉽습니다.

2. 로컬 동기식 작업과 "자율적인" Slack 작업 모두에 적합합니다.

현재 저의 업무는 두 가지 범주로 나뉩니다. 로컬에서 깊게 몰입해야 하는 작업과, 적은 감독 하에 Slack에서 실행될 수 있는 작업입니다. OpenCode는 이 두 가지 모두를 위한 하나의 하네스 (harness)를 제공합니다. 저는 서로 다른 두 시스템의 경계(edges)를 익힐 필요가 없습니다.

3. 오픈 소스이며 교체가 가능합니다.

다른 제공업체(provider)를 위해 런타임 (runtime)을 다시 구축하지 않고도 모델을 변경할 수 있습니다. 전체 시스템을 하나의 에이전트 생태계 (agent ecosystem)에 종속시키지 않고도 모델, 플러그인 (plugins), 메모리 도구 (memory tools), 샌드박스 (sandboxes)를 교체할 수 있습니다.

결론

이것이 제가 오늘날 Pipa를 운영하는 방식입니다. 인터페이스로는 Slack을, 요청을 위한 게이트웨이 (gateway)로는 gateway를, 워크플로우 (workflows)로는 Inngest를, 샌드박스 (sandboxes)로는 E2B를, 그리고 에이전트 작업에는 OpenCode를 사용합니다.

저는 핵심 게이트웨이 패턴을 공개하는 것을 고민하고 있습니다. 클라우드에서 OpenCode를 활용하면 많은 것을 할 수 있으며, 이 사용 사례(use case)에 대해 OpenCode가 과소평가되어 있다고 생각합니다.

이를 확인하고 싶으시다면, 메시지를 남겨주세요.

이러한 구성 요소들을 직접 걱정할 필요 없이 스튜디오를 위한 관리형 에이전트 (managed agent)를 원하신다면, Pipa를 고용할 수 있습니다.

--
이 게시물은 원래 Lunch Pail Labs 블로그에 게시되었습니다.