Open SWE는 이슈를 받아 원격 샌드박스에서 수정, 테스트, 리뷰 후 PR을 만드는 장기 작업에 맞지만, 빌드가 통과했다는 이유로 사람의 최종 검토까지 대신할 수는 없습니다. 반복적인 저장소 작업을 비동기로 넘기는 도구와 자동 병합 시스템을 구분해야 합니다.
Open SWE가 PR을 대신 만들게 할 때: 샌드박스, 자체 리뷰의 경계
코파일럿보다 긴 작업 단위를 맡는다
IDE 자동 완성은 개발자가 편집하는 순간에 코드 조각을 제안합니다. Open SWE 저장소가 겨냥하는 단위는 이슈 전체입니다. 저장소를 조사하고 여러 파일을 고치며 의존성을 설치하고 테스트한 뒤 PR을 준비하는 동안 사용자는 다른 일을 할 수 있습니다.
짧은 오타 수정처럼 사람이 몇 분 만에 끝낼 작업에는 샌드박스 준비와 여러 모델 호출이 더 비쌀 수 있습니다. 반대로 라이브러리 버전 변경, 반복되는 마이그레이션, 명확한 재현 절차가 있는 버그처럼 범위가 분명하고 테스트 가능한 작업이 후보입니다. “장기 작업”과 “모호한 작업”은 같은 말이 아닙니다.
작업 후보를 어떻게 점수화할까
이슈마다 요구 명확성, 자동 검증 가능성, 변경 폭, 비밀 접근, 외부 부작용과 되돌리기 가능성을 적습니다. 요구가 명확하고 테스트가 빠르며 PR만 만드는 작업은 좋은 후보입니다. 반대로 운영 데이터 마이그레이션, 결제, 권한 로직과 새 아키텍처 결정은 에이전트가 탐색을 도울 수 있어도 자동 완료 대상으로 두기 어렵습니다.
예상 사람 시간과 샌드박스 준비, 모델 호출 시간도 비교합니다. 수정 자체가 매우 짧다면 위임 설명과 리뷰가 더 비쌀 수 있습니다. 여러 저장소에서 같은 보일러플레이트를 반복하거나 긴 테스트를 기다리는 작업은 비동기 방식의 이점이 큽니다. 완료 가능한가보다 전체 대기와 검토 비용이 줄어드는가로 우선순위를 정합니다.
첫 시험에는 실패 시나리오도 포함합니다. 재현 명령이 틀렸거나 의존성 설치가 실패했을 때 요구를 임의로 바꾸지 않는지, 정해진 호출 상한에서 멈추는지 봅니다. 성공하기 쉬운 이슈만으로는 장기 작업의 통제력을 알 수 없습니다.
네 역할이 하나의 상태를 이어받는다
Manager는 요청과 상태를 초기화하고 흐름을 배분합니다. Planner는 읽기 중심으로 저장소를 조사해 변경 계획을 만들며, Programmer가 실제 코드와 환경을 다룹니다. Reviewer는 결과와 테스트를 확인하고 문제가 있으면 Programmer에게 되돌립니다. LangGraph 상태가 이 전달과 반복을 관리합니다.
역할을 나누면 어느 단계에서 판단이 틀렸는지 볼 수 있지만, 같은 모델과 잘못된 요구 사항을 공유하면 자체 리뷰도 같은 오류를 놓칠 수 있습니다. Reviewer의 승인과 독립적인 인간 리뷰를 동일시하면 안 됩니다. 계획, diff, 실행한 테스트와 남은 불확실성을 PR에 함께 남겨야 합니다.
계획과 자체 리뷰는 어떤 증거를 남겨야 하나
Planner의 결과에는 읽은 파일, 변경할 파일, 배제한 영역, 테스트와 되돌리기 방법이 있어야 합니다. Programmer가 계획 밖의 파일을 바꿨다면 이유를 표시하고 다시 승인을 받아야 합니다. Reviewer는 “좋아 보인다”는 결론보다 요구 사항별 통과 근거, 실행한 명령과 실패한 검사를 구조적으로 남기는 편이 낫습니다.
테스트 로그도 선택적으로 제시하면 안 됩니다. 성공한 마지막 실행뿐 아니라 어떤 검사가 없어서 확인하지 못했는지 적어야 합니다. 보안, 성능, 호환성처럼 저장소 테스트가 다루지 않는 항목은 남은 위험으로 사람에게 넘깁니다. 자체 리뷰의 가치는 인간 승인을 없애는 데 있지 않고 검토할 증거를 정리하는 데 있습니다.
같은 모델이 Planner와 Reviewer 역할을 모두 맡는다면 독립성은 이름만으로 생기지 않습니다. 요구를 오해한 계획이 이후 모든 단계에 전파되는 대조 실패를 일부러 넣어 보고, Reviewer가 계획 자체를 의심하는지 확인해야 합니다.
샌드박스는 폭발 반경을 줄일 뿐이다
원문은 Daytona, Modal, Runloop 같은 일회성 클라우드 샌드박스에 저장소를 복제하고, 내부에서는 패키지 설치와 서버 실행에 넓은 권한을 주는 구조를 설명합니다. 로컬 개발 환경을 건드리지 않으면서 에이전트가 끝까지 실행할 수 있다는 장점이 있습니다.
격리된 VM도 저장소 토큰, 패키지 공급망, 외부 네트워크와 연결되면 영향이 컨테이너 안에만 머문다고 장담할 수 없습니다. 작업별 최소 권한 자격 증명, 허용 저장소, 네트워크 대상, 수명과 종료 뒤 폐기를 확인해야 합니다. 운영 데이터와 배포 키를 넣지 않은 샌드박스에서 먼저 실패 동작을 시험하는 편이 맞습니다.
샌드박스 밖으로 나가는 경로는 무엇인가
에이전트가 설치하는 패키지는 외부 코드를 실행할 수 있고, 테스트는 네트워크나 클라우드 계정을 호출할 수 있습니다. 저장소 내용과 환경 변수가 로그나 모델 요청으로 전달될 가능성도 점검해야 합니다. 샌드박스라는 단어만 보고 비밀과 네트워크 정책을 생략하면 격리의 범위를 과대평가하게 됩니다.
작업별 토큰은 필요한 저장소의 브랜치와 PR 생성 정도로 제한하고 병합, 릴리스, 조직 설정 권한은 빼는 것이 좋습니다. 외부 네트워크는 필요한 패키지와 서비스만 허용하며, 종료 뒤 VM과 볼륨이 실제로 폐기되는지 확인합니다. 로그에서 비밀을 가리되 어떤 명령과 네트워크 요청이 있었는지는 감사할 수 있어야 합니다.
공급망 실패를 보기 위해 존재하지 않는 패키지 이름이나 변조된 설치 지시가 들어간 테스트 이슈를 별도 환경에서 시험할 수 있습니다. 에이전트가 가장 비슷한 패키지를 임의 설치하지 않고 멈춰 묻는지가 중요합니다. 편리한 자율 설치와 안전한 의존성 변경 사이에는 명시적인 승인선이 필요합니다.
작업 중 지시와 프로젝트 규칙을 전달한다
Open SWE는 AGENTS.md에서 코딩 규칙과 테스트 요구 사항을 읽고, 이슈와 Slack, Linear 맥락을 함께 가져오는 패턴을 사용합니다. check_message_queue_before_model 같은 미들웨어는 다음 모델 호출 전에 새 메시지를 확인해 진행 중인 작업을 수정하는 “더블 텍스팅”을 가능하게 합니다. 독립적인 하위 작업을 서브에이전트에 나누는 구조도 원문에 소개됩니다.
새 지시가 기존 계획과 충돌하면 어느 쪽이 우선하는지, 이미 만든 변경을 되돌릴지 규칙이 필요합니다. AGENTS.md도 오래되거나 지나치게 넓으면 잘못된 팀 규칙을 자동 반복합니다. 문서의 소유자와 적용 범위를 코드처럼 관리해야 합니다.
중간 개입이 충돌하면 어떻게 복구할까
사용자가 작업 도중 요구를 바꾸면 에이전트는 기존 변경 중 재사용할 부분과 버릴 부분을 구분해야 합니다. 새 메시지를 단순히 맨 뒤에 붙이면 서로 모순된 목표를 동시에 만족하려고 할 수 있습니다. 현재 계획, 완료된 단계와 새 요구의 차이를 먼저 요약하고 변경 범위를 다시 승인받는 절차가 필요합니다.
여러 서브에이전트가 같은 파일을 고치면 성공한 결과끼리도 충돌할 수 있습니다. 하위 작업을 파일이나 모듈 경계로 나누고, 통합 단계에서 테스트와 의미 충돌을 다시 확인해야 합니다. 단순 Git 병합 성공은 두 변경의 의도가 함께 맞는다는 뜻이 아닙니다.
중단과 재개도 시험합니다. 샌드박스가 사라지거나 모델 호출이 끊겼을 때 어떤 상태가 남는지, 새 실행이 이미 완료한 외부 행동을 반복하지 않는지 확인합니다. 비동기 작업은 오래 실행되는 만큼 정상 성공보다 중간 실패 후 재개 설계가 중요합니다.
도입 성공은 PR 수보다 검토 비용으로 잰다
작은 저장소에서 수정 성공률, 테스트 누락, 사람의 추가 변경량, API, 샌드박스 비용과 완료 시간을 기록합니다. 에이전트가 무한 반복할 때의 호출 상한과 종료 조건도 반드시 둡니다. 외부 API나 클라우드 실행이 금지된 망분리 환경에는 원문의 기본 구조가 맞지 않을 수 있습니다.
자체 Reviewer를 통과한 PR도 아키텍처 원칙, 보안, 성능과 보이지 않는 운영 가정을 사람이 확인해야 합니다. Open SWE의 성과는 PR을 많이 만드는 데 있지 않고, 사람이 최종 책임을 유지하면서 명확하고 검증 가능한 반복 작업의 대기 시간을 줄이는 데 있습니다.
함께 읽으면 이해가 이어지는 글
- Cloudflare Computer: AI 에이전트에게 컨테이너 대신 전용 컴퓨터를 부여하는 하이브리드 런타임 — Cloudflare Computer는 AI 에이전트에게 가상 파일시스템과 하이브리드 실행 환경을 제공하는 오픈소스 런타임입니다. V8 아이솔레이트 기반의 빠른 실행과 풀 스택 리눅스 컨테이너 샌드박스를 유기적으로 결합하고…
- Nanoclaw는 가벼운 개인 AI 에이전트인가: 구조, 격리, 도입 가이드 — Nanoclaw가 작은 코드베이스와 컨테이너 격리로 개인용 에이전트를 구성하는 방식, 설치 흐름과 권한, 업데이트 검증 기준을 정리합니다.
- Multica로 코딩 Agent를 비동기 운영해도 될까: daemon, 작업 큐, 권한 — Multica가 로컬 AI CLI를 daemon과 작업 보드에 연결하는 구조를 살펴보고, 비동기 실행의 격리, 중단, 로그, Skill 검증 비용을 기준으로 도입 범위를 정합니다.
자주 묻는 질문
Open SWE에 어떤 이슈를 먼저 맡기는 것이 좋나요?
재현 절차와 테스트가 있고 변경 범위가 분명하며 실패해도 쉽게 되돌릴 수 있는 반복 작업부터 맡기고, 모호한 설계나 운영 변경은 조사와 계획까지만 맡기는 편이 좋습니다.
클라우드 샌드박스면 저장소 토큰도 안전한가요?
격리는 로컬 피해를 줄일 뿐 자격 증명 오용을 막지 못하므로 작업별 최소 권한 토큰, 네트워크 허용 목록, 짧은 수명과 폐기 확인이 필요합니다.
에이전트 Reviewer가 승인하면 바로 병합해도 되나요?
아닙니다. 같은 요구와 모델 편향을 공유해 같은 오류를 놓칠 수 있으므로 계획, diff, 테스트, 남은 위험을 독립적인 사람 리뷰가 확인해야 합니다.
표지 1 —
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.