Handler

소개

Handler는 터미널형 코딩 에이전트가 거대한 diff를 만든 뒤에야 불안해지는 순간보다 조금 앞에 서는 제품입니다. 실행마다 격리 환경과 시각적인 제어 면을 주고, 에이전트가 작업하는 중간부터 무슨 일이 벌어지는지 볼 수 있게 합니다.

지금 주목받는 이유

지금 주목받는 이유는 새로운 코딩 에이전트 하나를 더 내놓아서가 아니라, 현재 agentic coding의 병목이 생성보다 리뷰에 있다는 점을 정면으로 건드렸기 때문입니다. Product Hunt에서도 이번 주 출시작으로 노출되면서, 이미 Codex나 Claude Code 같은 도구를 쓰는 팀에게 다음 단계의 문제를 잘 설명해 주고 있습니다.

핵심 기능

• 각 에이전트를 별도 샌드박스에서 실행하며 Docker와 Firecracker 기반 microVM을 활용할 수 있다.
• 터미널, 실시간 출력, 리소스 상태, 에이전트 진행 상황을 한 화면에서 보는 command centre를 제공한다.
• 환경을 fork해서 여러 접근을 병렬로 시험한 뒤 사람이 최종 경로를 고를 수 있다.

실제 활용 사례

• 마지막에 거대한 PR을 보는 대신 변경이 만들어지는 과정에서 점진적으로 리뷰한다.
• 같은 작업에 여러 구현 방향을 병렬 실행해 더 나은 결과를 고른다.
• 밤새 도는 에이전트 세션도 중간에 사람이 개입할 수 있을 만큼 투명하게 유지한다.

커뮤니티 반응

공개 반응에서는 생성 중인 변경을 바로 리뷰할 수 있다는 점이 가장 좋은 평가를 받습니다. 변경 단위 설명과 side chat 같은 기능은 실무적이라는 반응이 많습니다. 반면 이미 승인 창과 대시보드가 많은 팀에서는 또 다른 제어 층이 오히려 복잡성을 키우지 않을까 걱정하기도 합니다.

제한 및 위험

Handler가 높여 주는 것은 가시성이지 에이전트의 판단력 자체는 아닙니다. 기반 에이전트가 약한 설계 결정을 내리면 더 빨리 발견할 수 있을 뿐입니다. 비밀 정보, 샌드박스 이미지, 언제 fork할지 같은 운영 판단은 여전히 팀 몫입니다.

대안

대안으로는 Replicas, Grass, SuperHQ, OpenCode와 수동 git worktree 조합, 혹은 Stage CLI 같은 가벼운 리뷰 도구와 일반 PR 흐름이 있습니다.

자주 묻는 질문

• 누가 먼저 써보면 좋나요? 이미 코딩 에이전트를 쓰고 있고, 문제의 핵심이 생성보다 리뷰와 조정에 있다고 느끼는 팀입니다.
• 초기에 무엇을 검증해야 하나요? 샌드박스 시작 비용, 실제 저장소에서의 리뷰 가독성, 그리고 이 제어 층이 merge 시간 단축으로 이어지는지입니다.