AI 프롬프트는 점점 소프트웨어와 매우 유사해지고 있습니다.

단순히 채팅창에 입력하는 일회성 프롬프트뿐만 아니라, 재사용 가능한 요소들 말입니다.

슬래시 명령어 (slash commands).

에이전트 정의 (agent definitions).

규칙 파일 (rule files).

시스템 프롬프트 (system prompts).

프로젝트별 워크플로우 (project-specific workflows).

“매번 정확히 이 순서대로, 이러한 제약 조건 하에 정확히 이 일을 수행해 주세요”라고 적힌 파일들.

어느 시점이 되면, 그것들은 더 이상 메모처럼 느껴지지 않습니다.

소스 코드 (source code)처럼 느껴지기 시작합니다.

그래서 저는 Stim을 만들었습니다.

Stim은 AI 프롬프트, 명령어, 에이전트, 그리고 오케스트레이션 워크플로우 (orchestration workflows)를 실제 소스 파일로 작성하기 위한 작은 DSL (Domain Specific Language, 도메인 특화 언어)입니다.

하나의 .stim 파일을 작성하면, 사용하고자 하는 AI 도구로 컴파일할 수 있습니다.

현재는 Claude Code.

ChatGPT.

Cursor.

그리고 시간이 지나면서 더 많은 도구들이 지원되기를 희망합니다.

Repo:

문제점

대부분의 AI 워크플로우 파일은 그저 마크다운 (Markdown)일 뿐입니다.

그리고 마크다운은 훌륭합니다.

하지만 한계가 오는 순간이 있습니다.

단순한 프롬프트는 마크다운으로도 충분합니다:

당신은 시니어 엔지니어입니다.
이 코드의 버그를 검토하세요.
가장 중요한 이슈를 먼저 설명하세요.

여기까지는 문제가 없습니다.

하지만 실제 워크플로우가 침투하기 시작하면 상황이 달라집니다.

프롬프트가 질문을 던지기를 원할 수도 있습니다.

답변에 따라 분기 (branch)하기를 원할 수도 있습니다.

재사용 가능한 에이전트 (reusable agents)를 원할 수도 있습니다.

도구마다 다른 출력 형식을 원할 수도 있습니다.

Claude Code, Cursor, 또는 ChatGPT에서 작동하는 하나의 워크플로우 버전을 원할 수도 있습니다.

리뷰 에이전트, 계획 명령어, 보안 워크플로우, 글쓰기 어시스턴트, 그리고 어쩌면 함께 협업할 수 있는 작은 에이전트 팀을 원할 수도 있습니다.

결국 마크다운은 기술적으로는 여전히 마크다운이지만, 정신적으로는 가짜 콧수염을 붙인 프로그래밍 언어처럼 행동하기 시작합니다.

그 지점에서 Stim이 등장합니다.

Stim이란 무엇인가

Stim은 AI 워크플로우를 작성하기 위한 DSL입니다.

Stim을 통해 다음과 같은 것들을 정의할 수 있습니다:

• 명령어 (commands)
• 에이전트 (agents)
• 재사용 가능한 오케스트레이션 하네스 (reusable orchestration harnesses)
• 변수 (variables)
• 임포트 (imports)
• 루프 (loops)
• 조건문 (conditionals)
• 병렬 작업 (parallel tasks)
• 팬아웃 및 개더 흐름 (fan-out and gather flows)
• 패키지 기반 프롬프트 라이브러리 (package-based prompt libraries)

그다음 Stim은 해당 파일들을 대상 도구(target tool)가 요구하는 형식으로 컴파일합니다.

예를 들어:

stim install reviewer.stim

Claude Code 에이전트 (agent)를 설치할 수 있습니다.

stim install reviewer.stim --target cursor

동일한 소스를 Cursor 규칙 (rule)으로 컴파일할 수 있습니다.

stim compile reviewer.stim --target chatgpt

ChatGPT나 커스텀 GPT (Custom GPT)에 붙여넣을 수 있는 마크다운 (Markdown)을 생성할 수 있습니다.

이것이 핵심 아이디어입니다:

워크플로우 (workflow)를 한 번만 작성하세요. 대상 도구는 나중에 지정하면 됩니다.

간단한 명령어

여기 아주 작은 Stim 명령어가 있습니다:

command greet {
  ask("What's your name?")
  wait_for_response()
...

이것은 Claude Code 슬래시 명령어 (slash command)로 컴파일될 수 있습니다.

그리 대단한 것은 아닙니다.

하지만 명령어가 더 복잡해지면 구조가 중요해지기 시작합니다.

더 유용한 예시는 다음과 같습니다:

command brainstorm {
  ask("What problem are you trying to solve?")
  wait_for_response()
...

이것이 바로 제가 계속 원했던 종류의 것입니다.

단순한 프롬프트 (prompt)가 아니라,

워크플로우 (workflow) 말입니다.

AI 도구가 반복 가능한 프로세스 (repeatable process)를 수행하도록 안내할 수 있는 무언가 말이죠.

에이전트 또한 일급 시민 (first-class)입니다

Stim은 명령어만을 위한 것이 아닙니다.

에이전트 (agents)를 정의할 수도 있습니다:

agent security_reviewer {
  description "Reviews code for security vulnerabilities"
  tools [Read, Grep, Bash]
...

이것은 Claude Code 에이전트가 될 수 있습니다.

또는 일부 필드가 다르게 처리되는 다른 대상 (target)으로 컴파일될 수도 있습니다.

예를 들어, 대상 도구가 tools나 model 같은 필드를 지원하지 않는 경우, Stim은 사용자가 완전히 별개의 버전을 유지하도록 만드는 대신 경고를 보내고 해당 필드를 제외할 수 있습니다.

이것은 매우 중요한데, 모든 AI 도구는 저마다의 형식을 가지고 있기 때문입니다.

Claude Code는 한 가지 방식을 원하고,

Cursor는 다른 방식을 원하며,

ChatGPT는 또 다른 것을 원합니다.

Stim은 이러한 도구들보다 상위 단계의 소스 형식 (source format)을 제공합니다.

명령어, 에이전트, 그리고 하네스 (harnesses)

Stim에는 세 가지 큰 빌딩 블록 (building blocks)이 있습니다.

명령어 (Commands)는 대화형 워크플로우 (interactive workflows)입니다:

command plan_feature {
  ask("What feature are we planning?")
  wait_for_response()
...

에이전트 (Agents)는 메타데이터 (metadata)를 가진 재사용 가능한 페르소나 (personas)입니다:

agent doc_writer {
  description "명확한 기술 문서를 작성합니다"
}

Harnesses (하네스)는 재사용 가능한 오케스트레이션 (orchestration) 템플릿입니다:

harness find_verify {
  param finders
  param votes 3
}

세 번째 항목이 중요합니다.

Stim은 단순히 더 보기 좋은 프롬프트 파일을 만들려는 것이 아닙니다.

Stim은 에이전트 워크플로우 (agentic workflows)를 재사용, 공유 및 컴파일 (compile)할 수 있는 방식으로 기술하려고 합니다.

멀티 에이전트 워크플로우 (Multi-agent workflows)

제가 가장 기대하는 것 중 하나는 오케스트레이션 (orchestration)입니다.

예를 들어, 다음과 같이 더 심층적인 리뷰 워크플로우를 기술할 수 있습니다:

command deep_review {
  ask("어떤 코드를 리뷰해야 할까요?")
  wait_for_response()
}

이 지점에서 Stim은 단순히 프롬프트를 작성하는 것과는 다르다는 느낌을 주기 시작합니다.

이 파일은 워크플로우의 형태 (workflow shape)를 기술하고 있습니다.

이것을 묻고.

그다음 이 작업들을 병렬로 실행합니다.

그다음 결과를 수집합니다.

그다음 최종 출력을 작성합니다.

AI 도구가 여전히 워크플로우를 실행하지만, Stim은 이를 정의할 수 있는 더 깔끔한 방법을 제공합니다.

이것이 중요한 이유

저는 프롬프트 파일이 코드와 점점 더 비슷해질 것이라고 생각합니다.

모든 프롬프트가 그렇지는 않겠지만 말입니다.

"이 에러를 설명해줘"와 같은 간단한 요청에는 DSL (도메인 특화 언어)이 필요하지 않습니다.

하지만 우리가 재사용하는 프롬프트는 어떨까요?

우리가 리포지토리 (repo)에 커밋하는 프롬프트는요?

우리 에이전트의 동작 방식을 정의하는 프롬프트는요?

팀의 워크플로우를 제어하는 프롬프트는요?

그러한 것들은 더 나은 툴링 (tooling)을 누릴 자격이 있습니다.

파싱 (parseable)이 가능해야 합니다.

검증 (validated)이 가능해야 합니다.

컴파일 (compiled)이 가능해야 합니다.

공유 (shared)가 가능해야 합니다.

버전 관리 (versioned)가 되어야 합니다.

패키지 (packages)를 가져야 합니다.

에디터 지원 (editor support)이 있어야 합니다.

그리고 궁극적으로는 테스트 (tests)가 가능해야 합니다.

그것이 바로 Stim이 탐구하고 있는 방향입니다.

다양한 AI 도구 타겟팅

현재 Stim은 여러 타겟 (targets)을 지원합니다.

핵심 아이디어는 .stim 파일이 신뢰할 수 있는 단일 원천 (source of truth)이 되어야 하며, 각 타겟 어댑터 (target adapter)가 최종 출력을 어떻게 내보낼지 결정하는 것입니다.

예를 들어:

stim install security_reviewer.stim

기본적으로 Claude용으로 설치됩니다.

stim install security_reviewer.stim --target cursor

Cursor 규칙 (rule)으로 설치됩니다.

stim compile security_reviewer.stim --target chatgpt

ChatGPT용 Markdown으로 컴파일합니다.

이것이 제가 Stim의 존재를 원했던 큰 이유 중 하나입니다.

모든 AI 도구가 조금씩 다른 파일 형식을 가지고 있다는 이유만으로, 동일한 에이전트 (agent)나 워크플로우 (workflow)를 세 가지 다른 방식으로 다시 작성하고 싶지 않습니다.

그런 일은 금방 지치게 만듭니다.

패키지 관리 (Package management)

Stim은 또한 분산형 패키지 (decentralized package) 개념을 가지고 있습니다.

stim.yaml 매니페스트 (manifest)가 포함된 모든 GitHub 리포지토리 (repo)는 패키지가 될 수 있습니다.

따라서 다음과 같이 공유된 명령 (commands), 에이전트 (agents), 워크플로우 (workflows)를 설치할 수 있습니다:

stim add github/wess/stim/packages/reviews
stim add github/wess/stim/packages/gitflow
stim add github/wess/stim/packages/planning
...

이는 재사용 가능한 AI 워크플로우 라이브러리 (libraries)를 위한 문을 열어줍니다.

팀은 자체적인 내부 Stim 패키지를 가질 수 있습니다.

오픈 소스 프로젝트는 리뷰 에이전트 (review agents)를 게시할 수 있습니다.

누군가는 계획 (planning), 리팩토링 (refactoring), 테스트 (testing), 문서화 (documentation) 워크플로우의 전체 세트를 게시할 수도 있습니다.

이것은 저에게 매우 유용하게 느껴집니다.

모든 워크플로우가 패키지로부터 설치되어야 하기 때문이 아닙니다.

좋은 워크플로우는 공유 가능해야 하기 때문입니다.

에디터 지원 (Editor support)

Stim은 LSP (Language Server Protocol)도 갖추고 있습니다.

이는 에디터 통합 (editor integrations)이 동일한 언어 서버 (language server)를 공유할 수 있음을 의미합니다.

해당 리포지토리에는 다음을 위한 플러그인 (plugin) 작업이 포함되어 있습니다:

• VS Code
• Neovim
• Zed

목표는 AI 워크플로우를 작성하는 것이 코드를 작성하는 것과 더 비슷하게 느껴지도록 만드는 것입니다.

구문 강조 (Syntax highlighting).

진단 (Diagnostics).

스니펫 (Snippets).

컴파일 명령 (Compile commands).

결국, 저는 프롬프트 워크플로우 (prompt workflow)를 편집하는 것이 거대한 마법 같은 텍스트 덩어리를 편집하는 것처럼 느껴지지 않을 정도로 경험이 자연스러워지기를 바랍니다.

TypeScript와 Bun으로 구축됨

Stim은 TypeScript로 작성되었으며 Bun으로 구축되었습니다.

사용해 보려면:

git clone https://github.com/wess/stim.git
cd stim
bun install
...

그 다음:

./dist/stim version

파일을 컴파일할 수 있습니다:

stim compile examples/brainstorm.stim

또는 하나를 설치할 수 있습니다:

stim install examples/reviewer.stim

또한 토큰 (token) 명령어가 있습니다:

stim tokens examples/deepreview.stim

이 명령어는 컴파일된 토큰 수를 추정하며, 이는 워크플로우가 커지기 시작할 때 유용합니다.

내가 Stim이 되고자 하는 모습

더 큰 아이디어는 이것입니다:

AI 워크플로우 (workflows)가 특정 도구의 포맷 안에 갇혀 있어서는 안 됩니다.

나는 워크플로우를 한 번 작성하여 어디든 가지고 다니고 싶습니다.

리뷰어 에이전트 (reviewer agent)를 한 번만 정의하고 싶습니다.

플래닝 커맨드 (planning command)를 한 번만 정의하고 싶습니다.

멀티 에이전트 리뷰 프로세스 (multi-agent review process)를 한 번만 정의하고 싶습니다.

그런 다음 이를 Claude Code, ChatGPT, Cursor 또는 다음에 등장할 어떤 도구로든 연결하고 싶습니다.

도구들은 계속 변할 것입니다.

프롬프트 포맷 (Prompt formats)도 계속 변할 것입니다.

에이전트 시스템 (Agent systems)도 계속 변할 것입니다.

하지만 워크플로우 그 자체는 이식성 (portable)을 가져야 합니다.

그것이 바로 Stim이 목표로 하는 바입니다.

다음에 탐구하고 싶은 몇 가지 흥미로운 것들

아직 개선하고 싶은 점이 많습니다.

몇 가지 아이디어는 다음과 같습니다:

• 더 많은 타겟 어댑터 (target adapters)
• 더 나은 패키지 발견 (package discovery)
• 더 풍부한 검증 (validation)
• 더 강력한 에디터 통합 (editor integrations)
• 더 많은 퍼스트 파티 워크플로우 패키지 (first-party workflow packages)
• 더 나은 예시 (examples)
• 워크플로우 테스트 (workflow testing)
• 고급 오케스트레이션 (advanced orchestration)에 관한 더 깔끔한 문서

특히 다른 사람들이 이것으로 어떤 종류의 워크플로우를 구축할지 보고 싶습니다.

왜냐하면 사람마다 AI 도구를 사용하는 방식이 조금씩 다르기 때문입니다.

어떤 사람들은 코드 리뷰 에이전트 (code review agents)를 원합니다.

어떤 사람들은 플래닝 시스템 (planning systems)을 원합니다.

어떤 사람들은 글쓰기 도우미 (writing helpers)를 원합니다.

어떤 사람들은 프로젝트별 규칙 파일 (project-specific rule files)을 원합니다.

어떤 사람들은 작업에 대해 협업할 수 있는 작은 에이전트 팀을 원합니다.

Stim은 이러한 아이디어들에 소스 포맷 (source format)을 제공하기 위해 만들어졌습니다.

직접 사용해 보세요

Stim은 초기 단계이지만, 이미 공유하고 싶을 만큼 충분히 유용합니다.

여기서 확인하실 수 있습니다:

만약 여러분이 이미 커스텀 AI 커맨드, 에이전트, 규칙 또는 프롬프트를 구축하고 있다면, 꼭 사용해 보시길 권합니다.

그리고 아이디어나 이슈, 또는 지원하고 싶은 독특한 워크플로우가 있다면 이슈를 생성하거나 PR (Pull Request)을 보내주세요.

개발자들이 AI 워크플로우를 어떻게 구성해야 하는지에 대해 우리는 여전히 초기 단계에 있다고 생각합니다.

Stim은 그에 대한 하나의 해답을 찾으려는 저의 시도입니다:

프롬프트를 소스 코드 (source code)처럼 다루십시오.

그런 다음 그것들이 필요한 곳 어디에서든 컴파일 (compile)하십시오.