실습 노트

Open SWE를 코드 생성기가 아니라 격리된 소프트웨어 공장으로 읽는 법

LangChain의 Open SWE가 이슈·PR·일정에서 작업을 받아 격리된 샌드박스와 검증·리뷰 루프로 보내는 구조를 정리합니다.

보일러플레이트Open SWE · LangChain · AI 코딩 · AI 에이전트

코딩 에이전트를 도입할 때 가장 먼저 보이는 것은 코드를 생성하는 능력입니다. LangChain의 Open SWE는 그보다 넓은 문제를 다룹니다. 이슈·대화·PR·일정에서 작업을 받아 코드를 조사하고, 격리된 환경에서 수정·검증한 뒤, 사람이 검토할 수 있는 PR로 전달하는 비동기 소프트웨어 공장을 표방합니다.

작업의 단위가 프롬프트가 아니다

공식 README의 흐름은 작업 입력 → 계획·조사 → 격리된 샌드박스 구현 → 검증·PR 전달 → 리뷰·CI·피드백입니다. 사용자는 한 번의 답변을 받는 대신 작업 스레드를 열고, 같은 스레드에서 후속 지시와 결과를 이어 갑니다. 독립적인 작업은 병렬로 실행할 수 있습니다.

이 구조에서는 “좋은 코드가 나왔는가”만큼 다음 상태가 중요합니다.

  • 어떤 저장소와 이슈를 기준으로 계획했는가
  • 어떤 파일과 도구에 접근했는가
  • 어떤 테스트와 정적 검사를 통과했는가
  • 어떤 변경이 PR에 들어갔고 무엇이 사람 승인을 기다리는가

결과적으로 Open SWE는 채팅창에 코드를 붙여 넣는 도구보다, 작업·검증·전달을 하나의 실행 단위로 묶는 운영면에 가깝습니다.

LangGraph와 Deep Agents의 역할 분리

Open SWE는 Deep Agents를 파일·셸·스킬·상태·서브에이전트의 하네스로 사용하고, LangGraph를 내구성 있는 실행과 스레드 상태의 런타임으로 사용한다고 설명합니다. 그 위에 소프트웨어 엔지니어링 도구와 GitHub·Linear·Slack·웹 조사·브라우저 검증 같은 제품 결합부를 올립니다.

README에는 다섯 그래프 진입점이 나옵니다.

  1. Agent: 계획·구현·검증·전달
  2. Reviewer: 읽기 전용 PR 리뷰
  3. Analyzer: 저장소의 리뷰 스타일 분석
  4. Chat: 변경 없이 PR 질문에 답변
  5. Scheduler: 반복 작업과 CI 모니터링 디스패치

이 분리는 한 에이전트가 작성과 승인을 모두 독점하지 않도록 하는 데 의미가 있습니다. 특히 리뷰·질문 전용 모드를 별도로 두면 “수정할 권한이 있는 도구”와 “변경을 평가하는 도구”를 구분할 수 있습니다.

샌드박스는 편의 기능이 아니라 안전 경계다

클라우드 작업 스레드는 각자의 지속 샌드박스에 묶입니다. Open SWE는 저장소·조직 허용 목록, 행위자 권한 확인, 서버 프로세스 또는 샌드박스 프록시를 통한 자격 증명 주입, workflow 파일 변경 전 사람 승인, 읽기 전용 리뷰어를 안전 요소로 제시합니다.

하지만 샌드박스가 자동으로 안전을 보장하지는 않습니다. 공식 README도 샌드박스가 네트워크 접근과 강력한 도구를 가질 수 있으므로 최소 권한 자격 증명, 저장소·연결 허용 목록, 환경별 승인 규칙이 필요하다고 경고합니다. 배포 전에 다음 경계를 실제로 시험해야 합니다.

  • 읽을 수 있는 저장소·디렉터리
  • 네트워크로 나갈 수 있는 호스트
  • 생성·수정·삭제할 수 있는 자원
  • 비밀값이 프롬프트와 로그에 노출되는 경로
  • workflow·배포·결제처럼 되돌리기 어려운 변경

시작할 때의 작은 실험

공식 설치 안내는 GitHub App, LangSmith와 샌드박스 설정을 먼저 마친 뒤 uv sync --all-extraspnpm install로 의존성을 설치하고 make dev, make web로 서비스를 실행하는 흐름을 제시합니다. 다만 프로젝트가 활발히 개발 중이라 API와 화면이 바뀔 수 있다고 명시합니다.

처음부터 운영 저장소에 연결하기보다 테스트 저장소의 작은 이슈 하나로 다음을 기록하는 편이 낫습니다.

  1. 계획 단계가 실제 요구와 맞는지 확인합니다.
  2. 수정 단계에서 허용되지 않은 파일·네트워크 접근이 차단되는지 봅니다.
  3. 테스트·린트·타입 검사의 증거를 PR에 남깁니다.
  4. workflow 변경은 사람이 승인해야만 다음 단계로 가는지 확인합니다.
  5. 실패한 작업의 샌드박스와 미커밋 변경을 복구할 수 있는지 검토합니다.

적용 판단

Open SWE의 실용적 포인트는 “에이전트가 코드를 잘 쓴다”가 아니라 비동기 작업을 샌드박스·검증·리뷰·CI 피드백으로 둘러싼다는 데 있습니다. 반복적인 이슈 처리나 코드베이스 유지보수를 자동화하고 싶지만, 곧바로 병합하는 자율성을 원하지 않는 팀이라면 구조를 참고할 가치가 있습니다.

반대로 클라우드 샌드박스, GitHub App, 모델·추적 서비스가 함께 얽히므로 설치 비용과 권한 설계가 작지 않습니다. Open SWE는 MIT 라이선스의 오픈소스 프로젝트지만 현재 개발 중인 상태입니다. “오픈소스이므로 바로 내부 시스템에 투입 가능하다”가 아니라, 허용 목록·비밀값·승인·복구 실험을 먼저 통과하는 도구로 보는 편이 정확합니다.