Introducing Open SWE: An Open-Source Asynchronous Coding Agent
Quick Summary
Open SWE는 GitHub와 직접 연동되어 장시간 비동기로 코드베이스 조사, 계획 수립, 구현, 테스트, 자체 리뷰, PR 생성을 수행하는 오픈소스 클라우드 기반 코딩 에이전트입니다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
Open SWE는 GitHub와 직접 연동되어 장시간 비동기로 코드베이스 조사, 계획 수립, 구현, 테스트, 자체 리뷰, PR 생성을 수행하는 오픈소스 클라우드 기반 코딩 에이전트입니다.
📌 핵심 요약
- 본문은 소프트웨어 엔지니어링에서 AI 사용이 자동완성, IDE 코파일럿을 넘어 클라우드에서 비동기로 오래 실행되는 엔드투엔드 에이전트로 진화하고 있다고 설명하며, Open SWE를 그 흐름을 구현한 오픈소스 프로젝트로 소개합니다.
- Open SWE는 GitHub 저장소와 연결되어 이슈나 전용 UI에서 작업을 위임받고, 코드베이스 조사, 실행 계획 작성, 코드 작성, 테스트 실행, 자체 리뷰, 풀 리퀘스트 생성까지 수행합니다.
- 저자는 Open SWE의 차별점으로 단순한 프롬프트나 도구보다 전체 작업 흐름과 UX를 강조하며, 실행 중 계획 검토·수정이 가능한 human-in-the-loop와 진행 중 추가 메시지를 반영하는 double texting을 핵심 제어 기능으로 제시합니다.
- Open SWE는 GitHub 이슈·라벨·PR 흐름에 깊게 통합되고, 각 작업을 Daytona의 격리 샌드박스에서 실행하며, 클라우드에서 여러 작업을 병렬로 처리할 수 있도록 설계되었습니다.
- 아키텍처는 Manager, Planner, Programmer, Reviewer가 순차적·반복적으로 협력하는 구조이며, LangGraph와 LangGraph Platform으로 워크플로·상태·장시간 실행을 관리하고 LangSmith로 관찰과 평가를 수행했다고 설명합니다.
🧩 주요 포인트
- 본문은 소프트웨어 엔지니어링에서 AI 사용이 자동완성, IDE 코파일럿을 넘어 클라우드에서 비동기로 오래 실행되는 엔드투엔드 에이전트로 진화하고 있다고 설명하며, Open SWE를 그 흐름을 구현한 오픈소스 프로젝트로 소개합니다.
- Open SWE는 GitHub 저장소와 연결되어 이슈나 전용 UI에서 작업을 위임받고, 코드베이스 조사, 실행 계획 작성, 코드 작성, 테스트 실행, 자체 리뷰, 풀 리퀘스트 생성까지 수행합니다.
- 저자는 Open SWE의 차별점으로 단순한 프롬프트나 도구보다 전체 작업 흐름과 UX를 강조하며, 실행 중 계획 검토·수정이 가능한 human-in-the-loop와 진행 중 추가 메시지를 반영하는 double texting을 핵심 제어 기능으로 제시합니다.
- Open SWE는 GitHub 이슈·라벨·PR 흐름에 깊게 통합되고, 각 작업을 Daytona의 격리 샌드박스에서 실행하며, 클라우드에서 여러 작업을 병렬로 처리할 수 있도록 설계되었습니다.
- 아키텍처는 Manager, Planner, Programmer, Reviewer가 순차적·반복적으로 협력하는 구조이며, LangGraph와 LangGraph Platform으로 워크플로·상태·장시간 실행을 관리하고 LangSmith로 관찰과 평가를 수행했다고 설명합니다.
🧠 상세 정리
1. AI 코딩 도구의 진화와 Open SWE의 문제의식
본문은 지난 2년 동안 소프트웨어 엔지니어링에서 AI의 역할이 빠르게 바뀌었다는 진단으로 시작합니다. 처음에는 자동완성 수준이었고, 이후 IDE 안의 코파일럿 형태로 발전했으며, 최근에는 클라우드에서 비동기로 오래 실행되는 더 엔드투엔드한 에이전트로 이동하고 있다고 설명합니다. 저자는 앞으로의 에이전트가 장시간 실행되고, 비동기적이며, 더 자율적인 형태가 될 것이라고 봅니다. 구체적으로는 클라우드에서 실행되고, 개발자가 이미 쓰는 도구와 직접 통합되며, 환경에 대한 충분한 맥락을 바탕으로 장기 작업을 계획하고, 완료 전 자기 작업을 검토해 문제를 고치는 방식이 중요하다고 정리합니다. 이 비전이 가장 먼저 현실화될 분야로 소프트웨어 엔지니어링을 지목하지만, 이런 특성을 온전히 담은 오픈소스 프로젝트가 없었다는 점을 Open SWE 개발의 출발점으로 제시합니다.
2. Open SWE의 기본 정의와 역할
Open SWE는 본문에서 첫 번째 오픈소스 비동기 클라우드 호스팅 코딩 에이전트로 소개됩니다. 사용자의 GitHub 저장소에 직접 연결되고, GitHub 이슈나 자체 UI를 통해 작업을 위임받을 수 있도록 설계되어 있습니다. 저자는 Open SWE가 팀의 다른 엔지니어처럼 작동한다고 설명하며, 코드베이스를 조사하고, 세부 실행 계획을 만들고, 코드를 작성하고, 테스트를 실행하고, 오류를 찾기 위해 자기 작업을 검토한 뒤, 완료되면 풀 리퀘스트를 연다고 말합니다. 내부적으로는 LangGraph 같은 프로젝트와 Open SWE 저장소 자체에서 개발 속도를 높이는 데 사용해 왔고, 해당 저장소들에서 이미 주요 기여자 역할을 하고 있다고 밝힙니다. 이 설명은 Open SWE를 단순 코드 생성기가 아니라 작업 단위 전체를 맡는 비동기 개발 협업자로 위치시키는 데 초점이 있습니다.
3. 사용 시작 방식과 기본 실행 흐름
본문은 Open SWE의 호스팅 버전을 몇 분 안에 시작할 수 있다고 설명하며, 필요한 준비물로 Anthropic API 키를 제시합니다. 사용자는 swe.langchain.com에 방문해 GitHub 계정을 연결하고, Open SWE가 접근할 저장소를 선택한 뒤, 설정에서 Anthropic API 키를 제공하면 새 작업을 시작할 수 있습니다. 이후 사용자는 작업이 진행되는 과정을 볼 수 있고, 시작 지점이 필요한 경우 문서의 예제 페이지를 참고할 수 있다고 안내합니다. 이 부분은 설치나 자체 배포보다 호스팅 환경에서 빠르게 체험하는 절차에 초점을 둡니다. 또한 Open SWE가 GitHub 저장소와 직접 연결되는 전제를 강조함으로써, 사용자가 별도의 독립적 개발 환경을 먼저 구성하기보다 기존 저장소와 작업 흐름 안에서 에이전트를 사용하도록 설계되었음을 보여줍니다.
4. 왜 새로운 오픈소스 코딩 에이전트를 만들었는가
저자는 이미 여러 오픈소스 코딩 프로젝트가 있는데도 Open SWE를 만든 이유를, 프롬프트와 도구 자체보다 전체 흐름과 UX에 더 많은 관심을 모으기 위해서라고 설명합니다. 에이전트를 안정적으로 상호작용할 수 있는 수준까지 끌어올리려면 단순히 어떤 프롬프트를 쓰고 어떤 도구를 연결하는지뿐 아니라, 사람이 에이전트와 어떻게 소통하고 제어하는지가 중요하다는 관점입니다. 특히 UI와 UX는 에이전트 구축에서 상대적으로 덜 탐구된 영역이라고 지적합니다. 애플리케이션의 전체 상호작용 패턴은 실제 사용량에 큰 영향을 줄 수 있고, 비동기 에이전트는 아직 새로운 개념이기 때문에 실험할 만한 패턴이 많다고 봅니다. 이 맥락에서 Open SWE가 강조하는 두 축은 더 많은 제어권과 기존 개발 도구와의 깊은 통합입니다.
5. 제어 기능: human-in-the-loop와 double texting
Open SWE는 실행 중인 코딩 에이전트를 더 잘 통제할 수 있도록 두 가지 주요 기능을 제공합니다. 첫 번째는 human-in-the-loop로, Open SWE가 계획을 생성하면 중단 지점을 만들고 사용자가 그 계획을 승인하거나, 편집하거나, 삭제하거나, 변경 요청을 할 수 있게 합니다. 계획이 놓친 부분이 있으면 사용자가 더 조사하라고 말할 수 있고, 그러면 에이전트는 해당 작업의 계획 과정을 다시 시작합니다. 두 번째는 double texting으로, 대부분의 코딩 에이전트가 실행 중에는 새 요청이나 피드백을 받지 못하는 제약을 지닌 것과 달리, Open SWE는 진행 중에도 사용자의 추가 메시지를 활성 세션에 반영할 수 있다고 설명합니다. 제품 사양이 바뀌거나 새 기능을 추가하고 싶거나 에이전트가 잘못된 방향으로 가는 것처럼 보일 때, 사용자는 메시지를 보내 현재 작업 흐름에 자연스럽게 반영시킬 수 있습니다.
6. GitHub 통합, 샌드박스, 클라우드 비동기 실행
Open SWE는 개발자가 이미 일하는 GitHub 안에 깊게 통합되는 것을 중요한 설계 원칙으로 삼습니다. 새 작업마다 추적 이슈가 생성되고, 이 이슈에는 세션이 진행되는 동안 상태 업데이트, 실행 계획 등이 기록되며, 작업이 끝나면 풀 리퀘스트가 자동으로 열리고 추적 이슈와 연결됩니다. GitHub에서 직접 실행을 트리거할 수도 있는데, 예를 들어 특정 라벨을 이슈에 추가하면 Open SWE가 작업을 시작하고 완료 후 리뷰 가능한 풀 리퀘스트를 엽니다. 실행 환경 측면에서는 각 작업이 안전하게 격리된 Daytona 샌드박스에서 수행되므로, 각 세션이 별도 샌드박스를 갖고 셸 명령 실행에 대한 부담을 줄일 수 있다고 설명합니다. 또한 클라우드 네이티브 구조 덕분에 로컬 자원을 소비하지 않고 여러 작업을 병렬로 처리할 수 있으며, 아침에 여러 작업을 맡기고 오후에 PR들을 확인하는 사용 방식을 제시합니다.
7. 계획과 리뷰를 앞세운 에이전트 아키텍처
본문은 많은 에이전트가 바로 코드 작성으로 뛰어들어 CI 파이프라인을 깨뜨리는 실수를 낳을 수 있다고 지적하며, Open SWE는 계획과 리뷰를 먼저 중시한다고 설명합니다. Open SWE는 Manager, Planner, Programmer, Reviewer가 참여하는 구조로 작동하며, 앞부분에서는 Manager, Planner, Programmer가 순차적으로 일하고 Programmer 안에 Reviewer 하위 에이전트가 있다고 설명하고, 기술 설명에서는 네 에이전트가 각각 상태와 입력·출력을 가진다고 말합니다. Manager는 진입점으로 사용자 상호작용과 작업 라우팅을 맡고, 작업이 생성되면 상태를 초기화한 뒤 Planner로 제어를 넘깁니다. Planner는 코드 한 줄을 쓰기 전에 요청을 분석하고, 파일을 보고 검색을 실행하며, 단계별 실행 계획을 만듭니다. 계획이 승인되면 Programmer가 샌드박스에서 코드 작성, 테스트 실행, 문서 검색 등을 수행하고, Reviewer가 품질·정확성·완전성을 검토해 문제가 있으면 다시 Programmer에게 피드백을 보내는 반복 루프를 거칩니다.
8. 기술 기반, 관찰·평가, 오픈소스 확장성
Open SWE는 LangGraph 위에 구축되어 각 워크플로 단계에 대한 제어권을 확보하고, 여러 에이전트 호출과 상태 관리를 조율하며, 오류 상황을 처리할 수 있도록 만들어졌다고 설명됩니다. 배포에는 LangGraph Platform이 사용되며, 장시간 실행되는 에이전트를 위해 설계된 플랫폼으로서 지속성, human-in-the-loop 기능의 기반, 자동 확장 기능을 제공한다고 소개합니다. 저자는 Open SWE 같은 복잡한 멀티 에이전트 시스템에서 유용한 결과를 얻기 위한 핵심 과제가 정확도였고, 그중에서도 도구 사용 지침과 필요한 맥락을 제대로 가져오는 context engineering이 중요했다고 말합니다. 이를 디버깅하고 변경 효과를 평가하기 위해 LangSmith를 사용했다고 밝힙니다. 마지막으로 Open SWE는 오픈소스이며 LangGraph 기반으로 확장 가능하게 설계되어, 사용자가 저장소를 포크하고 프롬프트를 바꾸거나 내부 API용 도구를 추가하거나 핵심 로직을 팀 상황에 맞게 수정할 수 있다고 설명합니다.
🧾 핵심 주장 / 시사점
- 본문의 핵심은 Open SWE를 단순한 코드 작성 도구가 아니라, GitHub 이슈에서 PR까지 이어지는 실제 개발 업무 흐름에 들어가는 비동기 협업 주체로 설계했다는 점입니다.
- 저자는 코딩 에이전트의 성능을 프롬프트나 도구만의 문제가 아니라, 계획 검토, 중간 피드백 반영, 상태 업데이트, GitHub 통합 같은 상호작용 구조의 문제로 보고 있습니다.
- Open SWE는 복잡하고 오래 걸리는 작업에는 적합하지만, 짧은 한 줄 수정이나 단순 스타일 변경에는 현재 구조가 최적이 아니며, 이를 위해 계획·리뷰 단계를 선택적으로 건너뛸 수 있는 로컬 CLI 버전을 개발 중이라고 설명합니다.
✅ 액션 아이템
- Open SWE의 이슈·PR 연동형 비동기 작업흐름을 기준으로 자체 도입 가능 범위와 적용 우선순위를 정한다.
- Manager, Planner, Programmer, Reviewer 순환 구조를 반영해 각 단계의 책임 경계와 검증 지점을 정합성 있게 정의한다.
- Daytona 격리 샌드박스, LangGraph 상태 관리, LangSmith 관측을 결합해 장시간 실행 과제의 실행·테스트·리뷰 체계를 설계한다.
❓ 열린 질문
- human-in-the-loop 개입은 어떤 시점과 빈도로 운영해야 작업 지연을 최소화할 것인가?
- double texting으로 유입되는 중간 메시지는 어떤 기준으로 우선순위를 매겨 반영할 것인가?
- GitHub 이슈·라벨·PR 흐름에서 병렬 처리 시 충돌 가능성은 무엇이고, 어떻게 판별할 것인가?