Statewright, 에이전트 신뢰성을 상태기계로 묶다

Statewright는 Agents are suggestions, states are laws라는 문장으로 자신을 소개한다. AI 코딩 에이전트에게 30개, 40개의 도구를 한꺼번에 주고 긴 프롬프트로 조심하라고 말하는 대신, 작업 단계를 상태기계로 나누고 각 상태에서 쓸 수 있는 도구와 명령을 제한하겠다는 프로젝트다. Claude Code, Codex, Cursor, opencode, Pi를 지원 대상으로 제시하며, MCP와 훅을 이용해 계획, 구현, 테스트 같은 단계별 권한을 강제한다.

이 접근은 최근 에이전트 개발의 피로감을 정확히 찌른다. 모델은 점점 좋아지지만, 실제 코딩 작업에서는 같은 파일을 반복해서 읽거나, 불필요한 명령을 실행하거나, 테스트 전 수정 범위를 키우는 문제가 계속된다. Statewright는 더 큰 모델을 기다리는 대신 문제 공간을 줄이는 쪽을 택한다.

상태기계는 왜 에이전트에 맞는가

소프트웨어 개발은 원래 단계적이다. 버그를 고칠 때도 먼저 읽고, 가설을 세우고, 작은 수정을 하고, 테스트하고, 실패하면 돌아간다. 사람은 이 흐름을 암묵적으로 지키지만 에이전트는 도구 목록이 열려 있으면 쉽게 샛길로 빠진다. Statewright는 planning 상태에서는 Read, Grep, Glob만 허용하고, implementing 상태에서 Edit와 Write를 열며, testing 상태에서는 지정된 테스트 명령만 허용하는 식으로 흐름을 구조화한다.

에이전트 하네스는 샌드박스 밖에 있어야 할까에서 다뤘듯, 에이전트 시대의 핵심 질문은 모델이 아니라 실행 환경이다. Statewright는 이 실행 환경에 상태와 전이, 가드, 승인 게이트를 넣는다. 이는 프롬프트 보강보다 소프트웨어 엔지니어링에 가까운 해법이다.

연구 결과는 작지만 방향은 크다

Statewright README는 5개 SWE-bench 하위 과제와 26라인 버그 수정 실험을 공개한다. 특히 13.8GB gpt-oss:20b와 19.9GB gemma4:31b가 statewright 제약을 적용했을 때 5개 SWE-bench 작업을 통과했고, 두 모델이 2/10에서 10/10으로 개선됐다고 주장한다. 표본이 작고 전체 2,294개 SWE-bench 인스턴스를 대표하지는 않는다. 프로젝트도 이 한계를 명시한다.

그럼에도 메시지는 중요하다. 로컬 모델이나 중형 모델의 약점은 종종 지식 부족보다 작업 공간 과부하다. 파일을 너무 많이 읽고, 도구를 너무 많이 보고, 다음 행동 후보가 너무 많으면 모델은 제대로 편집하지 못한다. 상태기계는 이 문제를 구조적으로 줄인다. DeepClaude가 Claude Code 루프의 두뇌를 바꾸는 실험이 모델 교체로 비용과 성능을 조정했다면, Statewright는 모델 바깥의 제어면을 조정한다.

보안 가드레일로서의 가치

Statewright는 Bash 리디렉션, destructive ops, 스크립팅 인터프리터, 파일 수정 라인 수, 상태별 허용 명령, 환경 변수 차단 같은 가드레일을 언급한다. 이는 코딩 에이전트 보안에서 매우 현실적인 목록이다. 에이전트가 rm, curl | sh, 비밀키 출력, 대규모 diff를 실수로 실행하는 문제는 프롬프트만으로 완전히 막기 어렵다.

MCP가 도구 연결의 표준 인터페이스로 커질수록, 도구 권한을 어떻게 제한할지도 함께 중요해진다. Statewright의 문서와 workflow schema는 이 권한을 선언적으로 관리하려는 시도다. Cursor는 advisory, Claude Code와 Codex, opencode는 hard enforcement로 구분한 점도 정직하다. 모든 개발 환경에서 같은 강제력을 얻을 수는 없기 때문이다.

한국 개발 조직에 맞는 활용법

한국 기업에서 코딩 에이전트를 도입할 때 가장 흔한 걱정은 보안과 품질이다. 내부망, 레거시 저장소, 결제 시스템, 개인정보 처리 코드에 에이전트를 붙이려면 무엇을 못 하게 할 것인가가 먼저 정해져야 한다. Statewright식 접근은 이 질문을 팀 규칙이 아니라 워크플로 파일로 바꾼다.

예를 들어 장애 대응 워크플로에서는 planning 상태에서 로그 조회와 read-only 명령만 허용하고, mitigation 상태에서는 feature flag 변경만 허용하며, postmortem 상태에서는 문서 작성만 허용할 수 있다. 금융권이나 게임 서버처럼 실수 비용이 큰 조직은 approval gate를 고위험 전이에 넣을 수 있다. 이는 Mythos와 Firefox가 AI 보안 감사의 속도를 바꾼다는 흐름과 같은 방향이다. AI를 보안 업무에 쓰려면 AI 자체도 보안 경계 안에서 움직여야 한다.

경쟁 구도와 한계

Statewright의 경쟁자는 Devin류 자율 개발 에이전트만이 아니다. GitHub Copilot workspace, Cursor rules, Claude Code hooks, OpenAI Codex 샌드박스, 사내 CI 정책, OPA 같은 정책 엔진이 모두 인접 영역이다. Statewright의 차별점은 개발자가 이해하기 쉬운 상태기계와 시각 편집기를 전면에 내세운다는 점이다.

한계도 분명하다. 워크플로를 너무 엄격하게 만들면 에이전트가 막힌다. 너무 느슨하면 효과가 없다. 또한 연구 결과가 작은 벤치마크에 머물러 있어 일반화는 검증이 필요하다. 하지만 이 한계는 제품 실패라기보다 에이전트 엔지니어링의 본질을 보여준다. 신뢰성은 한 번에 주어지는 속성이 아니라 팀의 작업 방식에 맞춰 설계해야 하는 시스템 속성이다.

FAQ

Statewright는 모델을 대체하나?

아니다. 모델 위에 놓이는 제어 계층이다. 어떤 모델이 어떤 상태에서 어떤 도구를 쓸 수 있는지 제한해 작업을 더 작게 만든다.

가장 큰 장점은 무엇인가?

에이전트가 현재 단계에 필요한 도구만 보게 하여 반복 읽기, 무분별한 명령 실행, 과도한 수정 같은 실패를 줄일 수 있다는 점이다.

Cursor에서도 같은 수준으로 막을 수 있나?

프로젝트 설명에 따르면 Cursor는 advisory enforcement다. 규칙을 주입할 수는 있지만 프로토콜 수준의 hard block과는 다르다.

프로덕션에 바로 써도 되나?

민감한 저장소에는 단계적으로 적용하는 편이 안전하다. read-only 워크플로, 테스트 명령 제한, 승인 게이트부터 시작해 효과를 측정해야 한다.

한국 팀이 먼저 만들 워크플로는 무엇인가?

버그 수정 워크플로가 가장 좋다. planning, implementing, testing, review 단계를 나누고 각 단계의 허용 도구와 명령을 작게 시작하면 도입 효과를 측정하기 쉽다.