Stripe, Ramp, Coinbase와 같은 선도적인 엔지니어링 조직들은 자체 내부 코딩 에이전트(Slackbot, CLI, 웹 앱 등)를 구축하고 있습니다. 이 에이전트들은 개발자들이 이미 작업하는 환경에 맞춰 작동하며, 적절한 컨텍스트, 권한 부여 및 안전 경계와 연결되어 최소한의 인간 감독만으로 운영됩니다.

Open SWE는 이러한 패턴을 구현한 오픈 소스 버전입니다. LangGraph와 Deep Agents를 기반으로 구축되었으며, 해당 기업들이 내부적으로 구축한 것과 동일한 아키텍처(클라우드 샌드박스, Slack 및 Linear 호출, 서브에이전트 오케스트레이션, 자동 PR 생성 등)를 제공합니다. 이는 사용자의 코드베이스와 워크플로우에 맞춰 커스터마이징할 준비가 되어 있습니다.

Open SWE는 최고의 내부 코딩 에이전트들이 내리는 핵심 아키텍처 결정과 동일한 것을 구현합니다. 이는 Stripe의 Minions, Ramp의 Inspect, Coinbase의 Cloudbot에서 설명된 패턴들과 다음과 같이 매핑됩니다:

기존 에이전트를 포크하거나 처음부터 구축하는 대신, Open SWE는 Deep Agents 프레임워크를 **조합(composes)**하여 사용합니다. 이는 Ramp가 OpenCode 위에 구축한 방식과 유사합니다. 이를 통해 업스트림 개선 사항을 가져올 수 있는 업그레이드 경로를 확보하면서도, 조직에 맞는 오케스트레이션, 도구 및 미들웨어를 커스터마이징할 수 있습니다.

create_deep_agent(
model="openai:gpt-5.6-sol",
system_prompt=construct_system_prompt(...),
...

모든 작업은 자체 격리된 클라우드 샌드박스에서 실행됩니다. 이는 전체 셸 액세스가 가능한 원격 Linux 환경입니다. 저장소가 복제되고, 에이전트는 완전한 권한을 얻으며, 실수로 인한 파급 효과(blast radius)는 완전히 격리됩니다. 프로덕션 접근은 없으며, 확인 프롬프트도 없습니다.

Open SWE는 Modal, Daytona, Runloop, E2B, LangSmith 등 여러 샌드박스 제공업체를 기본적으로 지원하며, 사용자가 자체 제공업체로 플러그인 할 수 있습니다. 자세한 내용은 커스터마이징 가이드(Customization Guide)를 참조하십시오.

이는 세 회사 모두가 수렴하는 원칙을 따릅니다: 먼저 격리하고, 그 경계 내부에서 완전한 권한을 부여한다.

• 각 스레드는 영구적인 샌드박스 (sandbox)를 할당받습니다 (후속 메시지 간에 재사용됨)
• 샌드박스는 접근 불가능해질 경우 자동으로 재생성됩니다
• 여러 작업이 병렬로 실행됩니다 — 각 작업은 자체 샌드박스에서 실행되며, 대기열 (queuing)이 없습니다

Stripe의 핵심 통찰: 도구의 양보다 도구의 큐레이션 (curation)이 더 중요하다.
Open SWE는 작고 집중된 도구 세트를 통해 이 원칙을 따릅니다:

GitHub 작업은 LangSmith 프록시 (proxy)의 지원을 받아 샌드박스 내부에서 GH_TOKEN=dummy gh를 사용하여 수행됩니다. 또한 내장된 Deep Agents 도구들이 포함됩니다: read_file, write_file, edit_file, delete, ls, glob, grep, execute, 그리고 task (하위 에이전트 (subagent) 생성).

선택적 관찰 가능성 (observability) 도구 (서버 측): 관리자는 팀 설정 (Admin → Observability credentials)에서 Datadog 및 LangSmith를 연결할 수 있습니다. 연결되면 에이전트는 Datadog 도구 (Datadog의 호스팅된 MCP 서버를 통해, 기본값 toolsets=core)와 읽기 전용 LangSmith 도구 (langsmith_get_trace, langsmith_list_runs)를 갖게 됩니다. 이 도구들은 저장 시 암호화된 자격 증명을 사용하여 LangGraph 서버 프로세스 내에서 실행됩니다 — 샌드박스는 Datadog 또는 LangSmith 키를 절대 보유하지 않습니다. 이들은 권한이 있는 사용자에 의해 트리거된 실행에 대해서만 로드됩니다 (관리자 및 OBSERVABILITY_AUTHORIZED_EMAILS에 포함된 모든 이메일; ALLOWED_GITHUB_ORGS의 활성 멤버도 LangSmith 도구를 받음). 따라서 신뢰할 수 없는 기여자의 프롬프트 주입 (prompt-injected) 실행은 팀의 관찰 가능성 데이터에 접근할 수 없습니다. 그럼에도 불구하고 범위가 제한된 읽기 전용 키를 사용하십시오: 관찰 가능성 데이터 (로그, 트레이스 (traces))는 프롬프트 주입을 포함할 수 있는 공격자 영향 콘텐츠이며, 에이전트는 네트워크 외부 유출 (egress) 권한을 가지고 있습니다 — 이는 web_search / fetch_url과 동일한 잔류 위험 (residual-risk) 범주에 속합니다.

선택적 Corridor 가드레일 (server-side MCP): 각 에이전트 실행 시 Corridor의 호스팅된 MCP 서버를 로드하려면 CORRIDOR_API_TOKEN (또는 CORRIDOR_MCP_TOKEN / CORRIDOR_TOKEN)을 설정하세요. Open SWE는 Corridor의 analyzePlan 도구만 노출합니다. CORRIDOR_MCP_URL은 https://app.corridor.dev/api/mcp가 기본값이며, 명시적으로 설정할 경우 Open SWE는 동일한 HTTPS 호스트와 /api/mcp 경로만 허용합니다. 토큰은 LangGraph 서버 프로세스로부터 Authorization: Bearer ...를 통해 전송되며, 샌드박스(sandbox)에는 절대 배치되지 않습니다. 레거시 방식인 ?token=... URL도 허용되며 헤더 형식으로 정규화됩니다.

Open SWE는 두 가지 소스에서 컨텍스트(context)를 수집합니다:

— 루트 디렉토리에 AGENTS.md 파일이 포함되어 있는 경우, 샌드박스에서 이를 읽어 시스템 프롬프트(system prompt)에 주입합니다. 이는 Stripe의 규칙 파일(rule files)과 유사한 리포지토리 수준의 기능으로, 모든 에이전트 실행이 따라야 하는 인코딩 컨벤션(encoding conventions), 테스트 요구 사항 및 아키텍처 결정 사항을 포함합니다. 소스 컨텍스트 (Source context) — 전체 Linear 이슈(제목, 설명, 댓글) 또는 Slack 스레드 히스토리가 조립되어 에이전트에게 전달되므로, 에이전트는 도구 호출(tool calls)을 통해 모든 것을 새로 발견하는 대신 풍부한 컨텍스트를 가진 상태에서 시작할 수 있습니다.

Open SWE의 오케스트레이션(orchestration)은 두 개의 레이어로 구성됩니다:

하위 에이전트 (Subagents): Deep Agents 프레임워크는 task 도구를 통해 자식 에이전트(child agents)를 생성하는 것을 네이티브로 지원합니다. 메인 에이전트는 독립적인 하위 작업(subtasks)을 격리된 하위 에이전트들에게 분산(fan out)시킬 수 있으며, 각 하위 에이전트는 자체적인 미들웨어 스택(middleware stack)과 파일 작업을 가집니다. 이는 병렬 작업을 위한 Ramp의 자식 세션(child sessions)과 유사합니다.

미들웨어 (Middleware): 결정론적(Deterministic) 미들웨어 훅(hooks)이 에이전트 루프 주변에서 실행됩니다:

— 다음 모델 호출(model call) 전에 후속 메시지(실행 도중 도착한 Linear 댓글 또는 Slack 메시지)를 주입합니다. 에이전트가 작업하는 동안 메시지를 보내면 에이전트가 다음 단계에서 해당 입력을 가져옵니다. check_message_queue_before_model

— 에이전트가 모델 호출 제한에 도달했을 때 Slack 답장을 게시하는 에이전트 이후(after-agent) 훅으로, 사용자가 침묵 대신 명확한 신호를 받을 수 있게 합니다. notify_step_limit_reached

— 도구 오류를 우아하게 포착하고 처리합니다. ToolErrorMiddleware

기사에서 언급된 세 회사 모두 **Slack을 주요 호출 인터페이스 (invocation surface)**로 수렴합니다. Open SWE도 동일한 방식을 따릅니다:

Slack— 어떤 스레드에서든 봇을 언급하세요. 작업할 저장소 (repo)를 지정하기 위해 repo:owner/name 구문을 지원합니다. 에이전트는 스레드 내에서 상태 업데이트와 PR 링크로 응답합니다. Linear— 이슈(issue)에 @openswe를 댓글로 남기세요. 에이전트는 전체 이슈 컨텍스트를 읽고, 인지했다는 의미로 👀 이모지로 반응하며, 결과를 댓글로 다시 게시합니다. GitHub— 에이전트가 생성한 PR의 PR 댓글에서 @openswe를 태그하여 리뷰 피드백을 처리하고 동일한 브랜치에 수정 사항을 푸시하도록 합니다.

각 호출은 결정론적인 스레드 ID (deterministic thread ID)를 생성하므로, 동일한 이슈나 스레드에 대한 후속 메시지는 동일하게 실행 중인 에이전트로 전달됩니다.

에이전트는 커밋하기 전에 린터 (linter), 포매터 (formatter), 테스트를 실행하도록 지시받으며, 커밋, 푸시, 초안 PR (draft PR) 생성/업데이트, 그리고 소스 채널에서의 응답까지 엔드 투 엔드 (end-to-end)로 책임을 집니다. 이 부분은 조직을 위해 Open SWE를 확장할 수 있는 영역입니다. 추가적인 미들웨어 (middleware)로서 결정론적인 CI 체크, 시각적 검증 (visual verification), 또는 리뷰 게이트 (review gates)를 추가할 수 있습니다. 방법은 커스터마이징 가이드 (Customization Guide)를 참조하세요.

Linear, Slack 또는 GitHub에서 트리거— @openswe 언급하여 작업 시작
즉각적인 확인(Instant acknowledgement)— 메시지를 감지하는 순간 👀 이모티콘으로 반응
작동 중인 상태에서 메시지 전송— 작업 중간에 후속 메시지를 보내면 다음 단계 전에 이를 포착함
여러 작업을 병렬로 실행— 각 작업은 독립적인 클라우드 샌드박스에서 실행됨
GitHub OAuth 내장 기능— GitHub 계정으로 자동 인증됨
PR을 자동으로 열기— 변경 사항을 커밋하고 완료 시 초안 PR을 열어 티켓과 연결함
서브 에이전트 지원— 에이전트가 병렬 서브 작업을 위해 자식 에이전트를 생성할 수 있음
웹 대시보드(Web dashboard)— GitHub 로그인, 사용자별 모델/프로필 설정, 팀 기본값, 활성화된 레포 및 검토 스타일 관리, 사용자 매핑, 그리고 에이전트 채팅 UI를 위한 보조 앱 (inui/)
데스크톱 앱 (실험적)— 동일한 대시보드를 기반으로 한 Electron 래퍼 (indesktop/)입니다. 웹 UI가 Open SWE 사용을 권장하는 방식입니다.

설치 가이드 (Installation Guide)— 로컬 개발 (backend + dashboard), GitHub App 생성, LangSmith, Linear/Slack/GitHub 트리거, 그리고 프로덕션 배포 (production deployment)

커스터마이징 가이드 (Customization Guide)— 조직 (org)의 요구에 맞춰 샌드박스 (sandbox), 모델 (model), 도구 (tools), 트리거 (triggers), 시스템 프롬프트 (system prompt), 그리고 미들웨어 (middleware) 교체

MIT