OpenHands 리뷰: 2026년의 오픈 소스 자율 코딩 에이전트

OpenHands는 2024년에 화제가 되었던 폐쇄형 Devin 데모에 대한 커뮤니티의 응답으로 OpenDevin이라는 이름으로 시작되었습니다. 2년의 시간과 이름 변경을 거친 현재, 이 프로젝트는 MIT 라이선스 하에 All Hands AI가 관리하며 GitHub에서 가장 많이 주목받는 오픈 소스 자율 코딩 에이전트(autonomous coding agent)가 되었습니다. 우리는 이 에이전트가 사용자가 지켜보지 않을 때 실제로 무엇을 하는지 확인하기 위해 Python API 서비스, 작은 Astro 사이트, 그리고 의도적으로 망가뜨린 테스트 스위트(test suite) 등 실제 저장소(repositories)를 대상으로 일주일 동안 실행해 보았습니다.

이것은 단순한 데모 요약이 아닙니다. 에이전트에게 Docker 데몬(daemon), API 키, 그리고 엉망진창인 버그를 건네주었을 때 실제로 벌어지는 일에 대한 기록입니다.

OpenHands의 실체

브랜딩을 걷어내고 보면 OpenHands는 하나의 루프(loop)입니다. 에이전트는 사용자의 작업을 읽고, 행동을 결정하고, 샌드박스 런타임(sandboxed runtime) 내부에서 이를 실행하며, 결과를 읽고, 완료되었다고 판단할 때까지 이 과정을 반복합니다. 수행하는 행동들은 여러분이 사용하는 것과 동일합니다. 셸 명령(shell command) 실행, 파일 편집, Python 스니펫(snippet) 실행, 웹 페이지 브라우징 등이 그것입니다. 모델 자체에 특별한 처리가 되어 있는 것은 아니며, 지능은 여러분이 연결하는 LLM(Large Language Model)에 달려 있습니다.

마지막 부분이 가장 중요한 설계 결정입니다. OpenHands는 LiteLLM을 통해 모델 불가지론적(model-agnostic) 방식을 취하므로, 사용자가 직접 자신의 키를 가져와 사용할 수 있습니다. 우리는 Claude 및 GPT급 모델들을 대상으로 실행해 보았으며, 에이전트 코드는 변하지 않았습니다. 오직 비용과 성공률만 달라졌을 뿐입니다. 다음 분기에 더 나은 모델이 출시된다면, 설정 파일의 한 줄만 바꾸면 런타임, GitHub 통합, 그리고 숙련된 사용법을 그대로 유지할 수 있습니다. 폐쇄형 에이전트들은 이러한 탈출구를 제공하지 않습니다.

런타임(runtime)은 두 번째로 이해해야 할 요소입니다. 모든 행동은 호스트가 아닌 격리된 Docker 컨테이너 내부에서 실행됩니다. 에이전트가 문제를 해결하는 과정에서 rm -rf를 실행하더라도 그 피해 범위(blast radius)는 샌드박스 내에서 멈춥니다. 프로젝트를 마운트(mount)하면 에이전트는 복사본에서 작업하며, 사용자는 마지막에 차이점(diff)을 검토하면 됩니다. 가공되지 않은 터미널에서 자유롭게 실행되는 에이전트를 지켜본 적이 있는 사람이라면, 이러한 격리 기능이야말로 시도해 볼 것인가와 거부할 것인가를 가르는 결정적인 차이라는 점을 알 것입니다.

샌드박스(Sandbox)는 파일 시스템을 보호할 뿐, 사용자의 지갑이나 비밀 정보(Secrets)를 보호하지는 않습니다. 어려운 문제에 대해 루프(Loop)를 도는 에이전트는 모델을 계속 호출할 것입니다. 우리는 단 하나의 중간 정도 복잡한 버그를 해결하는 과정에서, 주의 깊은 인간의 세션보다 더 많은 토큰(Tokens)이 소모되는 것을 목격했습니다. 제공업체(Provider) 측에서 지출 한도를 설정하고, 운영 환경의 인증 정보(Credentials)나 실제 .env 파일이 포함된 디렉토리를 런타임(Runtime)에 절대 마운트(Mount)하지 마십시오.

실행 방법: 세 가지 진입로, 세 가지 다른 경험

세 가지 정문이 있으며, 이들은 서로 대체 가능하지 않습니다.

**CLI / 헤드리스 모드 (Headless mode)**는 개발자들이 주로 사용하는 방식입니다. 작업 문자열(Task string)을 입력하면 샌드박스 내에서 작동하며, 추론(Reasoning) 과정과 작업 내용을 터미널로 스트리밍(Streaming)합니다. OpenHands가 장난감처럼 느껴지지 않는 지점이 바로 여기입니다. GitHub 이슈(Issue)를 파이프(Pipe)로 넘겨주고 자리를 비울 수 있기 때문입니다. 또한 에이전트가 계획을 서술하고, 실행한 뒤, 테스트가 실패했을 때 얼마나 자주 되돌아가야(Backtrack) 하는지를 여실히 보여주는 모드이기도 합니다. 이러한 되돌아가기 루프(Backtrack loop)를 관찰하는 것이 여러분이 얻을 수 있는 가장 정직한 벤치마크(Benchmark)가 될 것입니다.

**웹 GUI (Web GUI)**는 Docker를 통해 로컬에서 실행되며, 에이전트의 터미널 및 에디터(Editor)의 실시간 뷰 옆에 채팅 패널을 제공합니다. 중단(Interrupt)이 가능하다는 점에서 시작하기에 가장 적합한 방식입니다. 에이전트가 잘못된 경로로 들어설 때(반드시 그런 일이 발생합니다), 동작을 멈추고 경로를 수정하여 다시 계속하게 할 수 있습니다. 에이전트를 자판기가 아닌 페어(Pair)로 대했을 때, 까다로운 작업에 대한 완료율(Completion rate)이 대략 두 배 정도 높아졌습니다.

**관리형 클라우드 (Managed cloud)**는 Docker 설정을 완전히 제거하고 GitHub에 직접 연결됩니다. 이슈(Issue)나 PR(Pull Request)에서 에이전트를 태그하면 브랜치(Branch)를 생성합니다. 편리하고 첫 번째 결과를 얻는 가장 빠른 경로이지만, 이제 여러분의 코드를 타인의 런타임(Runtime)으로 전송하게 됩니다. 공개 저장소(Public repo)라면 괜찮습니다. 하지만 회사의 모노레포(Monorepo)라면 데이터 정책(Data policy)을 먼저 확인하십시오.

이 프로젝트는 실제 GitHub 이슈를 해결하는 표준 벤치마크인 SWE-bench Verified의 결과를 공개하고 있으며, 그곳에서 가장 강력한 오픈 소스 에이전트(Open agents) 중 하나로 자리 잡고 있습니다. 이를 여러분의 코드베이스에 대한 약속이 아닌, 방향성을 나타내는 신호로 받아들이십시오. 벤치마크 이슈는 여러분의 실제 백로그(Backlog)와 달리 큐레이션되어 있고 독립적으로 구성되어 있습니다.

강점과 약점

OpenHands는 지루하지만 명확하게 정의된 작업에 강합니다. 스택을 통해 필드를 추가하거나, 기존 함수에 대한 테스트를 작성하거나, 스크립트를 포팅하거나, 실패하는 테스트의 원인을 추적하는 작업 등이 이에 해당합니다. 반드시 통과해야 하는 테스트와 같은 명확한 수락 기준(Acceptance check)을 제공하면, OpenHands는 진정으로 유용한 끈기로 이를 완수해 나갑니다. 샌드박스(Sandbox) 환경 덕분에 이러한 작업을 방치한 채로 실행할 수 있습니다.

반면, 모든 코딩 에이전트가 취약한 지점에서는 똑같이 취약합니다. 모호한 요구사항은 확신에 찬 잘못된 방향으로 이끕니다. 아키텍처적 가정을 건드리는 대규모 리팩터링(Refactor)은 갈피를 못 잡고 방황합니다. 또한, 에이전트의 내부적인 "완료(Done)\

OpenHands와 에디터 네이티브 어시스턴트(editor-native assistant)는 작업의 서로 다른 절반을 해결합니다. OpenHands는 전체 태스크(task)를 무인(unattended) 상태로 실행하도록 구축된 반면, 에디터 내 에이전트(in-editor agent)는 모든 코드 라인에 대해 사용자가 루프(loop) 안에 머물도록 설계되었습니다. 만약 당신의 워크플로가 "코드를 작성 중이며 빠르고 문맥에 맞는 도움이 필요하다"는 것이라면, 긴밀한 에디터 통합(editor integration) 방식이 더 적합하며, 이 둘은 행복하게 공존할 수 있습니다. 많은 개발자가 IDE에서 대화형으로 프로토타입을 제작한 뒤, 반복적이고 명확하게 규정된 후속 작업은 OpenHands에 헤드리스 모드(headless mode)로 맡깁니다.

어느 하나가 다른 하나를 대체하지는 않습니다. 2026년의 기술은 어떤 작업이 어느 차선에 속하는지를 파악하는 것, 그리고 자율 에이전트(autonomous agent)가 실제로 언제 완료되었는지를 알려주는 테스트를 작성하는 것입니다.