포스트

OpenHands는 Docker 안이면 안전할까? Event Stream, 위임, 권한 점검

OpenHands가 Docker에서 작업해도 자동으로 안전해지는 것은 아니며, 마운트한 디렉터리와 Docker 소켓, 네트워크 권한까지 제한해야 합니다. 샌드박스는 실행을 격리하는 기반이지 잘못된 명령과 비용 폭주를 대신 판단하는 장치가 아닙니다.

OpenHands 저장소는 이슈를 읽고 코드를 수정하며 테스트까지 수행하는 오픈소스 소프트웨어 에이전트를 지향합니다. 원문이 주목한 세 축은 행동 기록을 모으는 Event Stream, 명령을 격리하는 Docker Sandbox, 전문 작업을 넘기는 Agent Delegation입니다.

Event Stream은 행동과 관찰을 한 흐름으로 남긴다

에이전트가 파일을 열거나 셸 명령을 요청하면 action 이벤트가 생기고, 실행 결과와 표준 출력, 오류는 observation으로 돌아옵니다. 이 기록을 시간순으로 보관하면 모델이 왜 다음 행동을 골랐는지 추적하고, 실패한 단계에서 사람에게 제어권을 넘기기 쉬워집니다.

이 구조의 실용적인 가치는 멋진 대시보드보다 재현성에 있습니다. 최종 diff만 보면 잘못된 탐색과 반복 호출을 놓칩니다. 운영 시에는 어떤 이벤트를 저장할지, 로그에 비밀값이 섞였을 때 어떻게 가릴지, 세션을 얼마나 오래 보존할지까지 결정해야 합니다.

Docker는 경계를 만들지만 마운트가 그 경계를 다시 연다

에이전트가 임시 컨테이너에서 명령을 실행하면 호스트 패키지와 파일을 직접 훼손할 가능성을 줄일 수 있습니다. 그러나 프로젝트 전체를 쓰기 가능으로 마운트하거나 Docker 소켓을 노출하면 컨테이너가 가진 권한은 훨씬 커집니다. 호스트의 비밀키와 클라우드 자격 증명까지 마운트하면 격리의 이점도 사라집니다.

처음에는 복제한 저장소 하나만 연결하고, 네트워크와 환경 변수를 최소화하며, 생성물은 diff로 검토하는 편이 좋습니다. 원문에 소개된 한 줄 실행법은 Python 버전과 Docker 준비, 볼륨, 모델 설정을 모두 설명하지 않는 시점별 스냅샷이므로 완전한 설치 절차로 취급하면 안 됩니다. 현재 전제는 공식 문서에서 확인해야 합니다.

위임은 전문화를 돕지만 책임을 나누지는 못한다

OpenHands는 CodeActAgent가 탐색 같은 작업을 BrowsingAgent에 넘기는 AgentDelegateAction 구조를 소개합니다. 한 모델이 모든 도구 설명을 들고 있는 것보다 문맥을 줄이고 역할을 분리할 수 있습니다. 반면 위임 과정에서 원래 요구 사항이나 보안 조건이 빠지면, 하위 에이전트가 부분 목표만 정확히 수행하는 문제가 생깁니다.

위임할 때는 입력 범위, 허용 도구, 완료 조건, 반환 형식을 함께 넘겨야 합니다. 최종 에이전트는 결과를 그대로 믿지 말고 테스트와 파일 변경을 다시 확인해야 합니다. 멀티 에이전트라는 이름이 검증 책임까지 분산해 주지는 않습니다.

도입 여부는 해결률과 함께 반복 비용을 본다

작은 공개 저장소에서 이슈 하나를 골라 성공 여부, 사람 개입 횟수, 모델 호출량, 불필요한 파일 접근, 총 소요 시간을 기록하는 것이 현실적인 평가입니다. OpenHands 논문의 벤치마크는 출발점일 뿐, 사내 빌드 시스템과 비공개 의존성에서 같은 결과를 보장하지 않습니다.

에이전트는 막힐 때 같은 탐색과 테스트를 반복해 API 비용을 키울 수 있습니다. 최대 단계와 예산, 네트워크 사용, 쓰기 가능한 경로, 반드시 승인받을 행동을 미리 정해야 합니다. OpenHands의 장점은 개발 과정을 자동화 가능한 이벤트로 드러내는 데 있고, 안전과 경제성은 그 이벤트에 어떤 제한과 중단 조건을 거느냐에 달려 있습니다.

Docker 경계는 어떤 설정에서 약해지나

호스트의 넓은 디렉터리를 쓰기 가능으로 마운트하면 에이전트가 요청과 무관한 파일까지 바꿀 수 있습니다. Docker 소켓을 연결하면 다른 컨테이너나 호스트 수준 작업으로 영향이 확대될 수 있습니다. 운영 자격 증명과 홈 디렉터리를 환경 변수, 볼륨으로 넘기는 것도 격리의 이점을 줄입니다.

PoC에서는 복제한 저장소 하나와 임시 출력 경로만 연결하고 네트워크를 필요한 호스트로 제한합니다. 이미지 내부 사용자를 비권한 계정으로 두고 CPU, 메모리, 시간을 제한합니다. 컨테이너 삭제 뒤에도 남는 볼륨과 캐시, 생성 파일의 소유권을 확인해야 합니다.

Event Stream에는 무엇을 남겨야 할까

각 action과 observation 외에 작업 목표, 모델, 프롬프트, 도구 버전, 작업 디렉터리와 명령 종료 상태를 연결합니다. 파일 변경은 당시 diff와 연결하고 하위 에이전트 위임의 입력, 출력도 부모 실행에서 찾을 수 있어야 합니다. 외부 서비스 응답처럼 나중에 달라질 상태는 최소한 식별자와 시점을 남깁니다.

로그에는 소스, 사용자 데이터와 비밀이 섞일 수 있습니다. 저장 전 마스킹과 접근 권한, 보존 기간을 정하고 문제 조사에 필요한 정보까지 지워지지 않는지 시험합니다. 로그 저장 실패가 에이전트 실행을 조용히 계속하게 할지, 고위험 작업을 중단하게 할지도 정책으로 둡니다.

위임 계약은 어떻게 써야 할까

하위 에이전트에 원래 목표 전체를 던지기보다 담당할 질문, 읽을 수 있는 경로, 사용할 도구, 금지 행동, 완료 조건과 반환 형식을 줍니다. 상위 작업의 보안 조건과 보존할 사용자 변경도 함께 전달합니다. 불필요한 문맥은 줄이되 중요한 제약이 빠지지 않게 해야 합니다.

결과에는 확인한 근거, 바꾼 파일, 실행한 테스트와 불확실성을 포함합니다. 상위 에이전트는 하위 답을 그대로 합치지 않고 실제 파일과 로그를 확인합니다. 둘 이상의 하위 작업이 같은 파일을 바꿀 때 충돌 순서와 소유권을 미리 정해야 합니다.

반복 비용은 어떤 신호로 제어할까

최대 단계와 토큰 예산 외에 동일 명령, 오류의 반복 횟수, 변경 파일 수와 테스트 개선 여부를 봅니다. 같은 탐색을 되풀이하거나 수정과 되돌리기를 반복하면 자동 실행을 멈추고 사람에게 인계합니다. 중단 시 시도한 가설과 마지막 상태를 Event Stream에서 요약할 수 있어야 합니다.

저렴한 모델로 바꾸는 것만으로 잘못된 루프가 해결되지는 않습니다. 작은 이슈와 명확한 테스트, 제외 경로를 제공하면 불필요한 탐색을 줄일 수 있습니다. 작업당 해결 시간, 사람 개입, 호출 비용과 재작업률을 함께 측정해야 자동화의 실제 이득이 보입니다.

설치 예시는 어떻게 검증 가능한 절차로 바꿀까

현재 공식 문서에서 지원 버전과 실행 방식을 확인하고 이미지, 의존성 버전을 고정합니다. 작업용 볼륨, 모델 자격 증명, 네트워크와 로그 위치를 명시한 뒤 테스트 저장소에서 시작합니다. 한 줄 명령이 실행된다는 사실과 안전한 운영 구성이 완성됐다는 것은 다릅니다.

정상 파일 수정과 테스트 실행, 프로젝트 밖 접근, 네트워크 차단, 시간 초과와 컨테이너 재시작을 모두 시험합니다. 업그레이드 전후에 같은 사례를 회귀 실행하고 Event Stream 스키마와 권한 기본값이 바뀌지 않았는지 확인합니다.

작은 도입 평가는 어떤 표로 만들까

재현 가능한 이슈를 여러 난이도로 고르고 성공률, 테스트 통과, 불필요한 변경, 사람 개입, 단계, 비용과 총 시간을 기록합니다. 정답 diff만 비교하지 말고 기존 사용자 변경 보존과 실패 시 안전한 종료를 포함합니다. 공개 벤치마크와 사내 저장소 결과를 분리해 봅니다.

첫 PoC는 읽기, 조사와 작은 패치로 제한하고 외부 시스템 쓰기는 제외합니다. 성공이 반복되고 로그, 중단, 복구가 검증된 뒤에만 도구 범위를 넓힙니다. 더 넓은 자율성보다 검증 가능한 작업을 안정적으로 끝내는지가 도입 기준입니다.

실패한 PoC도 삭제하지 말고 분류해야 합니다. 환경 준비 실패, 요구 해석 오류, 코드 수정 오류, 테스트 누락과 비용 초과를 나누면 OpenHands의 한계와 저장소의 준비 부족을 구분할 수 있습니다. 같은 유형이 반복되면 더 많은 호출보다 입력 계약, 컨테이너 설정이나 중단 규칙을 먼저 고치는 것이 맞습니다.

원문과 버전 확인

함께 읽으면 이해가 이어지는 글

자주 묻는 질문

OpenHands를 Docker에서 실행하면 호스트가 자동으로 안전한가요?

아닙니다. 쓰기 가능한 볼륨, Docker 소켓, 네트워크와 환경 변수를 넓게 제공하면 컨테이너 경계가 약해지므로 실제 마운트와 권한을 제한해야 합니다.

Event Stream이 있으면 에이전트 작업을 완전히 재현할 수 있나요?

항상 그렇지는 않습니다. 모델, 도구, 환경 버전과 외부 상태, 비밀 마스킹과 보존 범위가 함께 기록되어야 하며 로그가 있다는 사실만으로 같은 결과가 보장되지는 않습니다.

여러 에이전트에게 위임하면 결과 검증도 나눠지나요?

아닙니다. 하위 결과의 요구 사항과 권한, 테스트를 최종 에이전트나 사람이 다시 확인해야 하며 위임은 검증 책임을 없애지 않습니다.

THE END / OPSOAI

여기까지 읽었습니다

핵심 장면을 한 번 더 떠올려 보세요. 이해가 남았다면 이 책은 제 역할을 다했습니다.

다른 책 고르기
표지 1

키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.

CONTENTS

이 책의 목차

    13개 장 17 분읽는 시간