Benchhand

자신의 도구가 하던 일을 기억할 것을 기대하는 사람들을 위한 영속적인 크로스 플랫폼 개발 MCP

Benchhand는 *“연결이 잠깐 끊기기 전까지는 작동했다”*라는 말이 더 이상 재미있는 개발 일화가 아닐 때 필요한 것입니다.

이 플랫폼은 지속성 있는 상태, 정확한 변경, 프로세스 소유권, 복구, 그리고 지루할 정도로 명시적인 계약을 중심으로 구축된 개발 MCP 플랫폼입니다.

장기 목표는 말하기는 쉽지만 달성하기는 어렵습니다. 실제 작업이 시작될 때 더 안정적이고, 더 이식성이 뛰어나며, 더 신뢰하기 쉬운 실용적인 DevSpace 대안이 되는 것입니다.

마법의 가루는 없습니다. 셸 스크립트를 덮는 “AI 기반” 스티커도 없습니다. 함수가 예외를 던지지 않았다는 이유만으로 성공 메시지를 표시하지 않습니다.

Benchhand는 아직 프리알파입니다. 기반이 먼저 구축되고 있습니다. 사용자가 도착한 후에 기반을 다시 구축하는 것은 새로운 욕을 배우는 아주 좋은 방법이기 때문입니다.

30초 버전

Benchhand는 MCP 클라이언트에 다음과 같은 개발 제어 평면을 제공하도록 설계되었습니다:

• MCP 엣지가 재시작되어도 살아남는 지속성 있는 워크스페이스;

• 더티 메인 체크아웃을 건드리지 않는 관리형 Git 워크트리;

• 제한된 파일 읽기, 목록, 검색 작업;

• SHA-256 사전 조건을 사용한 원자적 쓰기;

• 모호할 때 추측하는 대신 실패하는 결정적 변경;

• 지속성 있는 작업 상태 및 크래시 조정;

• 지속성 있는 로컬 데몬 앞에 있는 무상태 MCP 엣지;

• 일급 Windows, macOS, Linux 의미론;

• 향후 영구 프로세스, 터미널, 플러그인, 외부 MCP, 아티팩트, CLI 계층.

철학은 “도구가 무엇이든 하게 두는 것”이 아닙니다.

그것은 다음과 같습니다: 도구가 강력한 일을 하게 하되, 그 일의 의미를 정확하게 만드는 것입니다.

Benchhand가 존재하는 이유

개발 MCP가 워크스페이스를 잊어버리거나, 오래 실행되는 프로세스를 잃거나, 근처의 패치를 조용히 적용하거나, 부작용의 절반을 남겨둔 채 “성공”이라고 말하면 훨씬 덜 흥미로워집니다.

Benchhand는 그러한 문제들을 성격 특성이 아니라 아키텍처 문제로 취급합니다.

이 프로젝트는 몇 가지 고집스러운 아이디어를 중심으로 구축되었습니다:

1. 전송 상태는 애플리케이션 상태가 아닙니다. MCP 연결은 사라질 수 있습니다. 워크스페이스도 함께 기억상실에 걸려서는 안 됩니다.

2. 변경은 계약입니다. 쓰기나 패치가 사전 조건을 증명할 수 없다면 즉흥적으로 처리하는 대신 증거와 함께 실패해야 합니다.

3. 복구는 행복 경로의 일부입니다. 재시작, 오래된 상태, 부분적 부작용, 타임아웃, 재시도는 평범한 엔지니어링 조건입니다.

4. 크로스 플랫폼은 컴파일이 아니라 의미론입니다. “Windows에서 빌드된다”는 “Windows에서 같은 의미를 가진다”와 다릅니다.

5. 테스트는 증거이지 장식이 아닙니다. 내부 테스트가 중요합니다. 독립적인 클라이언트, 적합성 도구, 블랙박스 검사, 감사, 장애 주입도 중요합니다.

마지막 요점이 중요합니다. 동작을 정의하는 동일한 코드베이스가 작성한 녹색 테스트 스위트는 유용합니다. 그것은 인격 보증서가 아닙니다.

현재 아키텍처

MCP client
   |
   v
+------------------------+
| Benchhand MCP edge     |   disposable / protocol-facing
+------------------------+
   |
   | OS-local RPC
   v
+------------------------+
| Benchhand daemon       |   durable ownership / orchestration
+------------------------+
   |             |
   |             +--------------------+
   v                                  v
+------------------------+   +------------------------+
| Workspace/filesystem   |   | Operation journal      |
+------------------------+   +------------------------+
   |                                  |
   +----------------+-----------------+
                    v
             +--------------+
             | SQLite state |
             | WAL + FULL   |
             +--------------+

MCP 엣지는 의도적으로 지속성 있는 개발 상태의 소유자가 아닙니다. 사라졌다가 돌아올 수 있습니다. 그것은 기능이지 사고 보고서가 아닙니다.

현재 작동하는 것

현재 로컬 개발 라인에는 다음과 같은 작동 기반이 있습니다:

중요: “구현됨”은 현재 개발 브랜치에 구현되었고 프로젝트의 로컬 게이트를 통과했음을 의미합니다. “안정적인 공개 API” 또는 “프로덕션 준비 릴리스”를 의미하지 않습니다.

분위기에 기반한 변경은 없음

Benchhand는 소스 트리 주변에서 영리하게 굴기를 원하지 않습니다.

상태 변경 작업의 경우 의도된 계약은 다음과 같습니다:

• 정확한 사전 조건;

• 적절한 경우 해시 또는 버전;

• 결정적 대상;

• 원자적 커밋 지점;

• 명시적 충돌;

• 조용한 폴백 없음;

• 인접 줄 추측 없음;

• “대충 비슷하면” 식의 퍼지 패치 없음;

• 명시적이지 않고 암시되지 않는 재생 및 재시도 의미론;

• 작업을 재생할 수 있는 경우 중복 변경 방지.

Benchhand가 변경이 사용자가 요청한 것임을 증명할 수 없다면, 올바른 결과는 창의성이 아닙니다.

올바른 결과는 충돌입니다.

안전하되 수갑은 없음

Benchhand는 개발 도구입니다. 개발 도구에는 권한이 필요합니다.

따라서 보안 모델은 의도적으로 실용적입니다. 모든 유용한 작업을 권한 부여 의식으로 만들지 않으면서 워크스페이스 경계, 소유권, 변경 무결성, 자격 증명, 외부 노출 표면을 보호합니다.

프로젝트가 선호하는 것은:

• 전면 거부보다 정확한 대상 검증;

• 임의 기능 제거보다 역량 경계;

• 숨겨진 승격보다 명시적인 고권한 작업;

• 가능한 경우 되돌릴 수 있는 작업;

• 거부될 때 구조화된 증거.

다시 말해: 차고에서 나가기를 거부하는 자동차가 아니라 안전벨트입니다.

크로스 플랫폼은 계약입니다

Windows, macOS, Linux는 일급 대상입니다.

코어는 Bash, tmux, systemd, launchd, Homebrew, POSIX 신호, Unix 권한, Unix 경로, Unix PTY를 함부로 가정할 수 없습니다. 필요할 때는 플랫폼 어댑터 뒤에 있어야 합니다.

규칙은 다음과 같습니다:

동일한 Benchhand 작업은 Windows, macOS, Linux에서 동일한 의미를 가져야 하며, 플랫폼이 필요한 보장을 제공할 수 없을 때는 명시적으로 실패해야 합니다.

현재 개발 증거는 macOS에서 가장 강력합니다. Benchhand는 TypeScript가 CI에서 세 번 컴파일되었다고 해서 크로스 플랫폼 준비가 되었다고 자칭하지 않습니다. 플랫폼 네이티브 동작은 지원한다고 주장하는 플랫폼에서 테스트되어야 합니다.

테스트 철학

Benchhand는 동작 변경에 대해 테스트 우선 개발을 사용합니다.

하나의 행복 경로 단위 테스트가 통과했다고 해서 기능이 완료된 것으로 간주되지 않습니다.

관련 작업은 오래된 상태, 충돌, 동시성, 타임아웃, 데몬 재시작, 하드 크래시, 재시도, 재생, 중복 변경, 부분 부작용, 정리 실패, 경로 경계 사례, 심링크/정션, 플랫폼 차이와 같은 실패 모드를 다루어야 합니다.

해당되는 경우 완료에는 다음과 같은 독립적 증거도 필요합니다:

• 공식 MCP SDK 클라이언트;

• MCP Inspector;

• MCP 적합성 도구;

• 블랙박스 프로세스 테스트;

• 의존성 감사 및 취약점 스캐닝;

• SBOM 생성;

• 라이선스 검사;

• 플랫폼 네이티브 검증.

릴리스 정책은 의도적으로 *“내 컴퓨터에서는 작동해”*라는 말에 우호적이지 않습니다.

설치

아직 공개 설치 프로그램이 없습니다.

누군가 오늘 npm install -g benchhand를 실행하라고 말한다면, 그들은 미래에서 왔거나 무언가를 팔려는 사람입니다.

Benchhand는 공개 계약, 패키징, 복구 동작, 크로스 플랫폼 게이트가 안정 버전을 받을 자격을 갖출 때까지 0.x 릴리스 라인을 유지합니다.

소스에서 작업하는 기여자를 위해:

npm ci
npm run quality

그것은 포맷팅/린트 규칙, 엄격한 TypeScript 검사, 저장소 테스트 스위트를 검증합니다. 런타임 패키징과 최종 benchhand CLI는 이후 마일스톤입니다.

Benchhand는 다음이 아닙니다

• Git 대체품;

• MCP 배지를 단 터미널 멀티플렉서;

• DevSpace의 포크;

• 신뢰도 문제가 있는 퍼지 패치 엔진;

• 검토 없이 생성된 변경을 신뢰하기 위한 변명;

• 완성된 제품.

이 프로젝트는 기존 개발 도구, MCP 구현, 운영 체제, 오픈소스 라이브러리에서 유용한 아이디어를 연구합니다. 아키텍처와 계약은 Benchhand 고유의 것입니다.

로드맵

공개 로드맵은 ROADMAP.md에 있습니다.

요약 버전:

로드맵 순서: 안정적인 기반 → 파일시스템 → 영구 런타임 → 구조화된 Git → 플러그인 → 외부 MCP 브리지 → CLI/아티팩트 → UI/게이트웨이 → 크로스 플랫폼 패키징 → 장기 번인

기능 수가 목표가 아닙니다. 실패를 견디는 작은 기능이 재시작 때마다 동기 부여 연설이 필요한 큰 기능보다 가치가 있습니다.

기여

공개 저장소가 열리면 기여를 환영합니다.

코드를 보내기 전에 CONTRIBUTING.md를 읽어 주세요.

이 프로젝트는 작고 검토 가능한 변경, 수정 전에 실패하는 테스트, 재현 가능한 버그 보고서, 명시적 계약, 작성자의 노트북을 넘어서도 유효한 증거를 중요하게 생각합니다.

풀 리퀘스트에 영리한 지름길이 포함되어 있어도 괜찮습니다.

그 지름길이 실패 시 변경의 의미를 바꾼다면, 리뷰에 간식을 가져오세요.

보안

공개 이슈에 보안 취약점을 보고하지 마십시오.

공개 절차와 프로젝트의 현재 지원 상태는 SECURITY.md를 참조하십시오.

라이선스

Benchhand는 Apache License 2.0에 따라 라이선스가 부여됩니다. LICENSE를 참조하십시오.

타사 구성 요소는 각자의 라이선스 아래에 있습니다. 공개 릴리스 프로세스는 기계로 확인된 의존성 및 고지 목록을 유지 관리합니다.

이름

벤치 핸드(bench hand)는 작업대 곁에 있는 사람입니다. 작업에 대해 기조 연설을 하는 사람이 아니라 작업이 실제로 완료되도록 돕는 사람입니다.

그것이 여기서의 직무 설명입니다.

Benchhand는 워크플로에 자연스럽게 녹아들 만큼 유용하고, 복구에 대해 생각하지 않아도 될 만큼 안정적이며, 무언가를 거부할 때 정확히 그 이유를 이해할 수 있을 만큼 예측 가능해야 합니다.

그것이 기준입니다.