Sim — OnePageDaily

AGENT WORKFLOW CANVAS

Sim
캔버스 위의 에이전트 운영

노드를 끌어 붙이고, Copilot이 고치고, 자체 호스트에서 돌리는 에이전트 오케스트레이션 플랫폼

노드를 잇고 실행을 누르면 에이전트 한 무리가 일을 시작한다. Sim은 그 흐름을 캔버스에 박제하고, Copilot으로 고치고, 내 PostgreSQL과 Ollama 위에서 돌게 한다.

28.2k

GitHub Stars

3.5k

Forks

1,000+

Integrations & LLMs

Apache 2.0

License

▼ SCROLL

핵심 장면 6가지

VISUAL CANVAS

노드를 잇는다, 그게 워크플로우다

에이전트·툴·블록을 캔버스에서 직접 연결
워크플로우 그대로 즉시 실행 가능
apps/sim 본체와 apps/realtime 소켓이 분리

COPILOT INSIDE

자연어로 노드를 만들고 고친다

Copilot이 노드를 생성하고 에러를 수리
프롬프트로 플로우를 점진 개선
워크플로우 파괴 없이 부분 수정

RAG WITH PGVECTOR

내 문서에 에이전트가 답한다

Vector store에 문서 업로드
PostgreSQL + pgvector로 임베딩 저장
회사 자료 기반 질의응답을 그라운딩

DEPLOY ANYWHERE

클라우드도, 내 서버도

sim.ai 클라우드 호스팅 즉시 사용
npx simstudio 한 줄로 로컬 부팅
docker-compose.prod.yml로 프로덕션 배포

LOCAL MODELS

Ollama와 vLLM이 옆자리에 산다

docker-compose.ollama.yml로 로컬 LLM 부팅
vLLM 백엔드도 공식 지원
기밀 데이터를 외부로 보내지 않는 옵션

MONOREPO RIGOR

에이전트 도구가 계약으로 잠긴다

TypeScript 모노레포 + Bun 워크스페이스
ts-sdk와 python-sdk를 둘 다 패키징
mship/trace 컨트랙트 generate·check 스크립트가 경계 검증

Sim을 도입하기 전에 짚어야 할 4가지

쟁점	Sim의 답	도입 전 확인
클라우드 SaaS인가, 자체 호스팅인가	둘 다. sim.ai 호스팅과 Docker/NPM 자체 호스팅을 동일 코드베이스로 제공	12GB+ RAM, PostgreSQL 12+ 가용성, 3000/3002/5432 포트 사용 가능 여부
벡터 DB는 외부에 의존하나	pgvector를 PostgreSQL에 얹어 별도 벡터 인프라 없이 RAG 구성	기존 Postgres 운영 중이라면 pgvector 확장 설치 권한·백업 정책
오픈소스 라이선스 리스크	Apache 2.0. 상업 사용·수정·재배포 가능, 특허 면책 포함	내부 변경분의 NOTICE 갱신과 포크 운영 책임은 자체 부담
외부 LLM 호출이 부담되는 환경	Ollama·vLLM 프로필로 로컬 모델만으로도 워크플로우 실행 가능	GPU/메모리 자원, 모델 라이선스, 응답 지연 SLA를 별도 산정

이런 일을 캔버스 위에 올린다

📨

슬랙 인바운드 분류

Triage

📚

사내 위키 Q&A

RAG

📞

고객 지원 1차 응대

Support

🧾

인보이스 추출·검증

OCR + Rules

📝

PR 코드 리뷰 요약

DevOps

📈

주간 매출 리포트

Analytics

🔍

리드 리서치 자동화

Sales

🛒

이커머스 주문 라우팅

Ops

✉️

마케팅 카피 다국어 변형

Content

🔐

보안 알림 1차 분석

SecOps

프롬프트만으로 에이전트를 굴리던 단계가 끝나면, 결국 “이 에이전트가 어디서 멈추고 무엇을 호출했는지”를 그림으로 봐야 하는 순간이 온다. Sim은 그 그림을 코드 옆에 캔버스로 둔다. 노드를 끌어다 붙이고, 실행을 누르면, 같은 화면에서 흐름이 살아 움직인다.

Sim의 핵심 주장은 단순하다. 에이전트 운영은 결국 워크플로우 운영이고, 워크플로우는 캔버스·Copilot·자체 호스팅이라는 세 축으로만 잡으면 된다는 것이다. 시각적 빌더로 의도를 박제하고, Copilot이 자연어로 노드를 만들고 고치고, 같은 코드를 sim.ai 클라우드든 내 Docker든 동일하게 돌린다.

근거는 레포 구조에서 그대로 보인다. apps/sim 본체와 apps/realtime 소켓 서버가 분리되어 워크플로우 실행과 실시간 협업이 따로 스케일된다. 패키지 레이어에는 ts-sdk·python-sdk가 같이 있어 외부 시스템에서 워크플로우를 호출하는 길이 두 언어로 열려 있다. mship-contracts·trace-contracts·check:boundaries 같은 generate/check 스크립트가 빌드마다 도구 계약과 모듈 경계를 검증한다 — 에이전트 플랫폼 치고 드물게 정적인 안전망이다.

다만 무겁다. Docker Compose 가이드는 12GB+ RAM과 3000·3002·5432 포트를 요구하고, RAG는 PostgreSQL에 pgvector 확장을 얹는 방식이라 기존 DB 운영 정책과 맞물린다. 1,000개 통합·LLM을 광고하지만 결국 각 통합의 자격증명·레이트리밋·실패 모드를 책임지는 건 도입자 쪽이다. Apache 2.0이라 라이선스는 깨끗하지만, 포크해서 운영할 의사가 없다면 sim.ai 호스팅이 합리적인 출발점이다.

대신 보상은 분명하다. 한 캔버스에 워크플로우와 지식, 로컬 모델까지 묶이고, 같은 정의가 클라우드와 자체 서버를 오간다. PoC를 sim.ai에서 그리고, 본 운영을 docker-compose.prod.yml로 옮기고, 민감 데이터만 Ollama로 끌어내리는 식의 “단계적 자체 호스팅”이 자연스럽게 가능해진다. 28k 스타가 가리키는 건 결국 그 동선이다.

에이전트는
캔버스 위에서 자란다

프롬프트에서 시작해 인프라로 내려오는 길, Sim은 그 사이를 한 화면으로 잇는다.

원문 보기 · GitHub

Sim캔버스 위의 에이전트 운영

핵심 장면 6가지

Sim을 도입하기 전에 짚어야 할 4가지

이런 일을 캔버스 위에 올린다

에이전트는캔버스 위에서 자란다

Sim
캔버스 위의 에이전트 운영

에이전트는
캔버스 위에서 자란다

Sim — 캔버스 위의 에이전트 운영

Reference Links

Comments (0)