헤일메리가 만드는, 방법과 도구

헤일메리 프로젝트는 48개 서비스(공개 36 + 운영용 12)를 실제로 운영하면서, 그 과정에서 다듬은 방법론과 도구를 팀 표준으로 정리합니다. 아래 네 가지는 모두 지금 팀이 매일 쓰고 있는 것들입니다. 이 도구들이 서비스에 실제로 어떻게 물려 있는지는 공장 내부 — 배선에서 코드 경로까지 볼 수 있습니다.

Loop Engineering

자체검증을 자동화하는 다중 루프 표준. — 실행 루프·전략 루프·측정 루프를 분리해, 사람이 매번 붙어 있지 않아도 품질이 무너지지 않는 구조를 만듭니다.

AI 에이전트에게 작업을 맡기면 속도는 오르지만, 검증을 사람이 계속 따라다니면 그 속도는 다시 병목이 됩니다. Loop Engineering은 검증 책임을 세 개의 루프로 나눠 배치하는 표준입니다.

  • 루프1 — 실행 루프: 개별 작업 단위에서 자체검증을 자동화합니다. 사람 승인 없이도 스스로 완료 기준을 확인합니다.
  • 루프2 — 전략 루프: 여러 실행 루프를 묶어 방향을 조정하는 상위 루프입니다.
  • 루프3 — 측정 루프: 루프 자체가 잘 작동하는지 측정하고 개선하는 루프로, 측정 리드가 별도로 소유합니다.

모든 작업은 Spec + Evaluator가 갖춰져야 착수할 수 있습니다 — 무엇을 만들지와 어떻게 검증할지를 시작 전에 명시하는 게이트입니다. 정본은 팀 표준 문서(STANDARD_loop-engineering)로 관리됩니다.

이런 곳에 씁니다

  • AI 에이전트에게 반복 작업을 맡기되 품질 저하가 걱정되는 팀
  • 사람이 매 결과물을 검토해야 하는 병목을 줄이고 싶은 조직
  • 실행·전략·측정이 한 사람에게 몰려 루프가 겉도는 팀

멀티에이전트 오케스트레이션

한 사람이 아니라 한 팀처럼 위임한다. — oh-my-claudecode(OMC) 기반으로 역할별 전문 에이전트를 병렬로 위임·조율하는 방식.

모든 작업을 하나의 에이전트에게 맡기면 계획·구현·리뷰·검증이 뒤섞여 품질이 흔들립니다. 헤일메리는 oh-my-claudecode(OMC)를 기반으로, 역할이 분리된 전문 에이전트들에게 작업을 나눠 병렬로 위임하고 결과를 조율합니다.

  • 역할 분리: 계획·구현·리뷰·검증을 서로 다른 에이전트가 맡습니다. 현재 이 저장소에 역할별 팀 문서 30개와 에이전트 정의 30개가 있습니다.
  • 병렬 위임: 독립적인 작업은 동시에 여러 에이전트에게 맡겨 처리 시간을 줄입니다.
  • 지휘 계통: 창구 → PM → 팀원 순으로 요청이 구체화되고 실행됩니다.

이런 곳에 씁니다

  • 여러 파일·여러 서비스를 동시에 손대야 하는 작업
  • 계획과 실행, 실행과 검토를 같은 컨텍스트에서 뒤섞고 싶지 않은 팀
  • 사람 한 명이 모든 요청의 병목이 되는 조직

자체검증 게이트

작성한 사람이 스스로 승인하지 않는다. — 작성 패스와 검토 패스를 물리적으로 분리하는 원칙.

같은 컨텍스트에서 코드를 쓰고 바로 그 자리에서 통과 판정을 내리면, 검증은 형식만 남습니다. 헤일메리는 작성 패스와 검토 패스를 분리해, code-reviewer·verifier 같은 별도 에이전트가 완료 여부를 판정하게 합니다.

  • self-approve 금지: 작성한 주체는 자신의 결과물을 최종 승인할 수 없습니다.
  • 별도 패스: 리뷰와 검증은 시간과 컨텍스트를 분리한 별도 실행으로 진행됩니다.
  • 증거 기반 완료: “완료"를 선언하기 전에 테스트 결과·빌드 로그 등 근거를 먼저 수집합니다.

이런 곳에 씁니다

  • “작동하는 것 같다"는 감으로 완료를 선언해 온 팀
  • AI가 작성한 코드를 AI가 그대로 승인하는 구조를 걷어내고 싶은 조직
  • 완료 기준이 사람마다 다르게 판단되는 팀

graphify 지식그래프

grep으로 구조를 찾지 않는다. — 코드와 문서를 지속되는 지식그래프로 유지하고, query·explain·path로 탐색하는 도구.

프로젝트가 커질수록 “이 기능이 어디서 어디로 연결되는지"를 grep만으로 추적하는 비용이 커집니다. graphify는 코드와 문서를 입력받아 노드와 관계로 이뤄진 지식그래프를 만들고, 이후에도 코드가 바뀔 때마다 그 그래프를 계속 갱신해 씁니다. 현재 이 저장소의 그래프는 노드 3,549개 · 링크 6,029개입니다(2026-07-13 빌드).

  • 구조 탐색: grep 대신 query / explain / path 명령으로 관계를 직접 조회합니다.
  • 지속성: 한 번 만들고 끝나는 문서가 아니라, 코드 변경에 맞춰 갱신되는 그래프입니다.
  • 서비스 조회는 별도: 운영 중인 서비스에 대한 질문은 그래프가 아니라 SERVICES.md 단일 런북으로 답합니다 — 용도가 다른 질문을 같은 도구로 풀지 않습니다.

이런 곳에 씁니다

  • 기능·모듈 간 관계를 grep으로 짜맞추다 지친 팀
  • 코드베이스가 커지면서 온보딩·탐색 비용이 급격히 늘어난 조직
  • 여러 서비스를 운영하며 “이거 어디 있더라"를 반복해서 묻는 팀

운영 원장

위 방법과 도구는 모두 헤일메리 프로젝트 팀이 실제 운영 중에 쓰면서 다듬은 것들입니다. 지금 어떻게 쓰이고 있는지는 라이브 포털에서 직접 확인할 수 있습니다.