HelixHarness
English | 简体中文
적응하도록 구축되고, 진화하도록 설계되었습니다.
팀의 엔지니어링 DNA를 AI 개발까지 계승합니다.
HelixHarness는 팀이 Codex와 Claude Code를 사용하여 자체 AI 코딩 하네스(coding harness)를 구축하도록 돕습니다. 요구사항부터 구현, 테스트, 검토 및 아카이브에 이르기까지 비즈니스 지식, 엔지니어링 규칙, 개발 워크플로우를 에이전트의 작업에 통합합니다. 검증된 교훈은 프로젝트와 함께 남아 다음 기능을 준비시킵니다.
플러그인으로 시작하세요. 하네스 자체를 개선하고 싶을 때는, 선택적 기능인 helixharness-platform을 사용하여 유지 관리자가 사용량을 관찰하고, 프레임워크 버전을 비교하며, 후보 개선 사항을 채택하기 전에 평가할 수 있습니다.
9개의 명령어 · Codex / Claude Code · 단일 레포지토리/다중 레포지토리 워크스페이스 · Apache-2.0
빠른 시작 · 이름의 유래 · 왜 HelixHarness인가 · HelixHarness 반복 플랫폼 · 사용자 가이드
이름의 유래
모든 팀은 소프트웨어를 구축하는 자신만의 방식을 가지고 있습니다. 그것이 보호하는 비즈니스 규칙, 작동하는 아키텍처, 신뢰하는 검사 항목, 그리고 배운 교훈들입니다. 이 모든 것이 모여 그 팀의 엔지니어링 DNA를 형성합니다.
**Helix(헬릭스)**는 DNA 이중 나선을 연상시키며: 지식이 시간이 지나면서 전달되고 정제됨을 의미합니다. **Harness(하네스)**는 그러한 지식에 실행에서의 역할을 부여합니다—코딩 에이전트가 실제 프로젝트 작업을 수행하는 동안 안내하는 맥락, 제약 조건 및 워크플로우입니다.
Didi의 금융 기술 팀 엔지니어링 관행에서 탄생한 HelixHarness는 이 아이디어들을 하나로 모았습니다. 프로젝트 지식과 규칙은 팀에 적응하도록 돕고; 아카이브(Archive)에 보존된 검증된 교훈들은 나중 작업에 더 강력한 출발점을 제공합니다. 프레임워크 유지 관리자의 경우, 관찰 및 통제된 평가는 다음 변경 사항을 알려주며, 채택은 인간의 손에 맡겨집니다.
코드는 배포됩니다. 지식은 남아있습니다. 하네스는 진화합니다.
왜 HelixHarness인가
Capability
| Capability | What it means in your project |
|---|
| 프로젝트에 기반한 Harness | 리포지토리 명령어와 인덱싱된 프로젝트 제약 조건은 에이전트가 계획 및 구현 과정에서 따라야 할 구체적인 엔지니어링 규칙을 제공합니다. |
| ... | |
| 여기서 Harness는 에이전트를 안내하는 프로젝트 제약 조건 및 실행 규칙을 의미합니다: 무엇을 읽어야 하는지, 어떤 경계를 존중해야 하는지, 그리고 작업을 완료하는 데 필요한 증거가 무엇인지에 대한 것입니다. context loading protocol를 참조하십시오. | |
Development workflow: project constraints and knowledge guide Propose and Apply; Archive retains verified knowledge after confirmation
엔지니어링 DNA를 실행 가능한 형태로 만듭니다
팀 경험을 에이전트가 사용할 수 있는 컨텍스트로 전환합니다. HelixHarness는 프로젝트 지식, 엔지니어링 제약 조건, 요구 사항 및 검사 항목들을 코드와 함께 정리하여, 프로젝트가 진화함에 따라 검토, 재사용 및 업데이트될 수 있도록 합니다.
| Part | The question it answers | Where it lives in your project |
|---|
| 지식 · 프로젝트 이해 | 이 시스템은 어떻게 작동하나요? 어떤 비즈니스 규칙과 과거 결정이 중요한가요? | docs/knowledge/ |
| ... | | |
| Knowledge 및 Harness 인덱스는 컨텍스트 로딩을 안내합니다. Specs는 각 작업의 범위, 계획 및 검증 증거를 담고 있습니다. Hooks는 호스트 런타임 후크(host runtime hooks), 워크플로우 게이트(workflow gates), 검토 체크리스트를 결합하며; 이들의 실행은 호스트 및 워크플로우 구성에 따라 달라집니다. context loading protocol와 hook setup를 참조하십시오. | | |
지식 재사용의 모습
환불 기능이 상태 전이 규칙(state transition rule)과 서비스 간 인터페이스 경계(cross-service interface boundary)를 설정한다고 가정해 봅시다. 구현 및 검증 후, Archive는 유지할 안정적인 지식을 제안하고 사용자는 업데이트를 확인합니다. 다음 환불 관련 기능이 시작될 때, Propose와 Apply는 인덱스를 통해 해당 지식을 로드하여 에이전트가 작업할 기존 프로젝트 참조(project reference)를 제공할 수 있습니다.
지식은 **검토 가능한 리포지토리 문서(repository documents)**로 축적됩니다. 무엇이 공유 프로젝트 지식이 될지는 사용자가 통제합니다.
플러그인만으로 시작합니다. 이는 플랫폼과 독립적으로 작동합니다. task-filter 예제에는 스타터 프로젝트, 요구사항 및 독립적인 승인 검사가 포함되어 있습니다.
빠른 시작 (Quick start)
1. 플러그인 설치하기 (Install the plugin)
요구 사항: Python 3.10 이상, Git, 그리고 플러그인 사용이 가능한 Codex 또는 Claude Code 설치가 필요합니다. 호스트에 로그인했거나 모델 구성이 설정되어 정상적으로 작동하는지 확인하십시오.
저장소가 공개되면 터미널에서 사용 중인 호스트에 맞는 명령어를 실행합니다. 수동으로 소스를 클론할 필요는 없습니다:
codex plugin marketplace add https://github.com/didi/helixharness.git
codex plugin add helix@helixharness-marketplace
claude plugin marketplace add https://github.com/didi/helixharness.git
claude plugin install helix@helixharness-marketplace
루트 마켓플레이스는 플랫폼이 아닌 helixharness/ 플러그인을 설치합니다. 게시 전 테스트하거나 플러그인을 수정하려면 로컬 소스에서 개발자 설치를 사용하십시오. 후크 검증, 업데이트 및 제거를 참조하십시오.
2. 작은 기능 실행하기 (Run a small feature)
제품명은 HelixHarness이며, 플러그인 ID와 명령어 네임스페이스는 **helix**입니다.
개발하려는 애플리케이션 저장소에서 새로운 에이전트 세션을 엽니다. 호스트의 네이티브 인터페이스를 통해 플러그인 후크(hooks)를 검토한 다음, 대화창에 다음 명령어를 입력합니다:
/helix:init
/helix:propose task-filter ./requirements/task-filter.md --loop
자체 포함된 task-filter 예제를 사용하여 스타터 프로젝트, 요구사항 및 승인 검사를 받으십시오. --loop는 Propose → Apply → Archive 순서로 실행되며, 결정이나 차단 요소가 발생하면 일시 중지됩니다. 이 명령어는 코드를 게시하거나 배포하지 않습니다.
또한 /helix:propose, /helix:apply, /helix:archive를 개별적으로 실행할 수도 있습니다. 모든 아홉 가지 명령어를 참조하십시오.
진행 상황과 블로커(blockers)를 검사하려면 /helix:status를 사용하고, 원격 측정 동의 및 보고 주소를 확인하거나 변경하려면 /helix:config를 사용합니다.
Superpowers와 OpenSpec과의 관계
이러한 프로젝트들은 에이전트 지원 개발에 유용한, 중첩되는 접근 방식을 제공합니다. 이 비교는 각 프로젝트가 강조하는 바를 보여줍니다:
| 프로젝트 | 강조점 |
|---|
| Superpowers | 조합 가능한 개발 기술 및 관행: 브레인스토밍, 계획 수립, TDD(Test-Driven Development), 서브 에이전트 실행 및 코드 검토. |
| ... | |
출처 표기 및 관련 작업은 third-party notices를 참조하십시오.
HelixHarness 반복 개선을 위한 플랫폼
helixharness-platform은 HelixHarness의 명령어, 워크플로우 규칙, 스킬, 컨텍스트 로딩 전략을 변경하는 유지 관리자들을 위해 존재합니다. 이는 사용 증거(usage evidence), 제어된 버전 비교, 그리고 후보 개선 사항들을 프레임워크 반복 프로세스에 연결합니다.
| 기능 | 이 기능이 답변하는 질문 | 검사할 수 있는 항목 |
|---|
| 관측 가능성 (Observability) | HelixHarness가 실제 사용에서 어느 부분에서 마찰을 겪는가? | 워크플로우 실행 기록, 단계 상태, 시간 및 토큰(Token) 사용량, 재작업 및 증거 품질. |
| ... | | |
평가 대상은 HelixHarness 프레임워크 버전 또는 변경 사항입니다. 개발 시나리오는 해당 프레임워크를 활용하며, 그 결과는 이 프레임워크의 동작에 대한 증거를 제공합니다. 이 플랫폼은 프레임워크 반복을 지원하는 것이며, HelixHarness가 생성한 비즈니스 코드를 평가하기 위한 일반적인 서비스는 아닙니다.
Framework iteration: observe, hypothesize, build a candidate, evaluate, review and adopt, then observe again
프레임워크 반복 개선의 세 가지 관점
<table
<tr>
<th width="33%">관측 가능성 (Observability)</th>
<th width="33%">평가 (Evaluation)</th>
<th width="33%">진화 (Evolution)</th>
</tr>
<tr>
<td><a href="docs/assets/platform-observability.png"><img src="https://raw.githubusercontent.com/didi/helixharness/HEAD/docs/assets/platform-observability.png" alt="합성 데모: HelixHarness 사용 및 단계 관측" width="100%"></a></td>
<td><a href="docs/assets/platform-evaluation.png"><img src="https://raw.githubusercontent.com/didi/helixharness/HEAD/docs/assets/platform-evaluation.png" alt="합성 데모: 프레임워크 버전 평가 및 Mock 결과" width="100%"></a></td>
<td><a href="docs/assets/platform-evolution.png"><img src="https://raw.githubusercontent.com/didi/helixharness/HEAD/docs/assets/platform-evolution.png" alt="합성 데모: 프레임워크 증거 루프 및 진화 개요" width="100%"></a></td>
</tr>
<tr>
<td>워크플로우의 마찰 지점과 리소스 사용량을 파악합니다.</td>
<td>제어된 프레임워크 버전 비교를 검사합니다.</td>
<td>증거 루프와 진화 개요를 검사합니다.</td>
</tr>
</table>
모든 스크린샷을 클릭하면 확대됩니다. 세 가지 모두 합성 데모 데이터가 적용된 실제 플랫폼 UI를 보여줍니다. 평가는 Mock 실행을 사용하며, 진화 뷰는 증거 루프와 합성 증거 요약을 보여줍니다. 이들은 측정된 개선 사항이나 실제 모델 결과가 아닌 인터페이스 예시입니다.
실제 평가는 사용자의 모델 서비스와 보정(calibrated) 케이스가 필요합니다. 진화 제안 및 후보 변경 사항은 검토 가능하며, 프레임워크 변경을 채택하고 게시하려면 인간의 결정이 필요합니다.
플랫폼 데모 사용해보기
먼저 소스를 다운로드하거나 클론한 후, 통합된 리포지토리 루트에서 다음 명령어를 실행하세요:
macOS / Linux (Bash / Zsh):
cd helixharness-platform
python3 -m venv .venv
source .venv/bin/activate
...
Windows (PowerShell):
cd helixharness-platform
py -m venv .venv
.\.venv\Scripts\Activate.ps1
...
Windows CMD의 경우, PowerShell 활성화 명령어 대신 .venv\Scripts\activate.bat을 사용하십시오. 다른 Windows 명령어들은 동일합니다.
localhost:7860을 엽니다. 데모는 임시 런타임 디렉터리에 포함된 소스 예제로부터 합성 케이스(Case), 모의 실행(Mock Run), 그리고 원격 측정 데이터(telemetry data)를 생성합니다. 생성된 데이터베이스, 인수 테스트 실행(acceptance-test Runs), 후보 작업 공간(candidate workspaces)은 소스 또는 휠에 포함되지 않습니다. 백그라운드 진화 및 모델 분석 기능은 비활성화되어 있습니다. 내장 데모는 진화 가설을 생성하지 않으며, 진화 스크린샷은 생성된 가설이나 후보 없이 개요를 보여줍니다.
리포지토리 맵 (Repository map)
버전 평가를 위해서는 플랫폼을 소스 Git 체크아웃 또는 그 내부 디렉터리에 지정하십시오. 이는 각 고정 커밋(frozen commit)에서 플러그인을 독립적으로 찾아내며, 독립형(standalone), 결합형(combined), 중첩된 모노레포 레이아웃(nested monorepo layouts)을 지원합니다. 여러 개의 플러그인 사본에는 명시적인 Git 상대 경로가 필요하며, 중첩된 Git 리포지토리는 요구되지 않습니다. 평가 설정.
데이터 및 피드백 (Data and feedback)
원격 측정(Telemetry)은 사용자가 명시적으로 활성화하기 전까지는 꺼져 있습니다. 비동기 보고(Async reporting) 및 선택적 피드백 스킬(feedback skill)에는 기본 플랫폼 주소가 없습니다. 목적지가 구성되지 않으면 피드백을 보낼 수 없으며, 진입점(entrypoint)은 사용 가능합니다. 엔드포인트를 구성한다고 해서 피드백 전송 권한이 부여되는 것은 아닙니다: 콘텐츠와 목적지는 여전히 승인이 필요합니다.
출판 후 커뮤니티 버그는 GitHub Issues를 통해 보고하십시오. 플랫폼 배포는 필요하지 않습니다. 취약점(vulnerabilities)에 대해서는 SECURITY.md를 따르십시오. 데이터 및 피드백 세부 정보.
로드맵 (Roadmap)
계획된 두 가지 방향은 더 많은 팀이 자신들의 개발 관행에 맞춰 HelixHarness를 구축하는 데 도움을 줄 것입니다:
- 더 많은 코딩 에이전트 지원. 팀들이 선호하는 더 많은 도구와 함께 HelixHarness를 사용할 수 있도록 Codex 및 Claude Code를 넘어 지원을 확장합니다.
- 구성 가능한 워크플로우. 팀들이 개발 프로세스에 맞게 워크플로우 단계와 순서를 구성할 수 있도록 합니다.
이것들은 계획된 기능입니다. 현재 버전은 Propose → Apply → Archive 워크플로우를 통해 Codex와 Claude Code를 지원합니다. 이러한 방향을 구체화하는 데 도움을 주기 위해 기여 가이드를 통해 구체적인 사용 사례를 공유해 주세요.
문서 및 기여