점진적으로 확장하는 자율 개발 하네스 시연 정리

2026년 9월 5일·

점진적으로 확장하는 자율 개발 하네스 시연 정리

이 시연은 처음부터 완성형 하네스를 만드는 과정이 아니라,
에이전트가 하네스를 점진적으로 설계하고 확장해 가는 흐름을 보여준다.

핵심은 다음과 같다.

입력을 읽고 목표를 정리하는 단계
계획을 스스로 보완하는 단계
리서치/개발/검증이 서로 되돌아가며 완성도를 높이는 단계
배포까지 이어지는 실행 루프
중간중간 Harness Viewer로 구조를 확인하는 방식

전체 흐름 요약

flowchart TD USER["CLI 프롬프트 입력"] H1["하네스 골격 생성"] H2["계획 루프 강화"] H3["제작 루프 구성"] H4["배포 루프 추가"] H5["실행 규칙/게이트 강화"] VIEW["Harness Viewer로 확인"] RUN["실제 하네스 실행"] USER --> H1 --> VIEW VIEW --> H2 --> VIEW VIEW --> H3 --> VIEW VIEW --> H4 --> VIEW VIEW --> H5 --> VIEW H5 --> RUN

1. 하네스의 골격 만들기

첫 단계에서는 실제 구현보다 구조의 뼈대를 먼저 만든다.
입력 분석 에이전트가 제품 설명서를 읽고, 목표 정의와 리소스 저장소로 나누며, 오케스트레이터가 전체를 조율하는 형태다.

중요한 포인트는 다음과 같다.

오케스트레이터 중심 구조
상태 저장소를 통한 실행 기록
이후 확장될 에이전트들을 빈 슬롯처럼 남겨두기

flowchart TD INPUT["제품 설명서"] INTAKE{{입력 분석 에이전트}} GOAL["목표 정의"] RESOURCE[(("리소스 저장소"))] STATE[(("상태 저장소"))] ORCH{{오케스트레이터}} PLAN{{기획}} RESEARCH{{리서치}} DEV{{개발}} QA{{검증}} DEPLOY{{배포}} INPUT --> INTAKE --> GOAL --> ORCH INTAKE --> RESOURCE --> ORCH ORCH <--> STATE ORCH <--> PLAN ORCH <--> RESEARCH ORCH <--> DEV ORCH <--> QA ORCH <--> DEPLOY

2. 기획 에이전트를 오토 플랜 루프로 확장

다음 단계에서는 기획을 한 번에 끝내지 않고,
목표 정리 → 요구사항 분석 → 범위 설정 → 리스크 점검 → 작업 분해 → 계획 작성을 반복하게 만든다.

계획이 부족하면 다시 요구사항 분석으로 돌아간다.
이 구조 덕분에 기획이 “작성”이 아니라 “검토와 보완”의 흐름이 된다.

flowchart TD PLAN{{기획 에이전트}} REQ["요구사항 분석"] SCOPE["범위 설정"] RISK["리스크 점검"] TASK["작업 분해"] DOC["실행 계획"] CHECK{"계획 충분?"} PLAN --> REQ --> SCOPE --> RISK --> TASK --> DOC --> CHECK CHECK -- 보완 --> REQ CHECK -- 충분 --> ORCH["오케스트레이터 보고"]

3. 리서치/개발/검증 제작 루프 구성

기획이 끝나면 제작 루프가 시작된다.
오케스트레이터가 제작 컨텍스트를 전달하고, 개발 에이전트가 구현한 뒤, 검증 에이전트가 결과를 확인한다.

여기서 핵심은 분기다.

구현이 부족하면 개발로 되돌아감
정보가 부족하면 리서치로 되돌아감
충분하면 오케스트레이터에게 보고

flowchart TD CTX["제작 컨텍스트"] DEV{{개발}} QA{{검증}} RES{{리서치}} CHECK{"제작 충분?"} CTX --> DEV --> QA --> CHECK CHECK -- 구현 보완 --> DEV CHECK -- 정보 보완 --> RES --> DEV CHECK -- 충분 --> ORCH["오케스트레이터 보고"]

4. 배포 에이전트 추가

마지막으로 배포 루프를 붙인다.
검증을 통과한 결과를 바탕으로 배포 컨텍스트를 만들고, 배포 에이전트가 패키징, 설정 확인, 실행, 결과 확인까지 맡는다.

배포가 실패하면 다시 보완하고 재시도한다.
즉, 배포도 단발성이 아니라 닫힌 루프로 설계된다.

flowchart TD DCTX["배포 컨텍스트"] DEPLOY{{배포 에이전트}} PACKAGE["패키징"] CONFIG["설정 확인"] RELEASE["배포 실행"] HEALTH["결과 확인"] CHECK{"배포 성공?"} DCTX --> DEPLOY --> PACKAGE --> CONFIG --> RELEASE --> HEALTH --> CHECK CHECK -- 실패 --> DEPLOY CHECK -- 성공 --> ORCH["오케스트레이터 보고"]

5. 실행 규칙과 정책 게이트로 강화

이제 구조가 만들어졌다면, 그 다음은 실행을 강제하는 규칙이다.
이 단계에서는 대부분의 연결선을 훅으로 바꾸고, 중요한 판단 지점에는 정책 게이트를 둔다.

이렇게 하면 하네스는 단순 연결도가 아니라,
실제 실행 순서를 통제하는 운영 그래프가 된다.

flowchart TD ORCH{{오케스트레이터}} PLAN_GATE{"기획 실행 허용?"} BUILD_GATE{"제작 실행 허용?"} DEPLOY_GATE{"배포 실행 허용?"} ORCH --> PLAN_GATE --> PLAN{{기획}} ORCH --> BUILD_GATE --> BUILD_CTX["제작 컨텍스트"] ORCH --> DEPLOY_GATE --> DEPLOY_CTX["배포 컨텍스트"]

6. 마지막 시연: 실제 하네스 실행

최종 시연에서는 /harness 명령으로 하네스를 실제 실행한다.
입력 폴더에 들어 있는 자료를 바탕으로 서비스 구현, 테스트, 배포까지 이어지는 모습을 보여준다.

이때 중요한 메시지는 하나다.

하네스는 단순히 코드를 만드는 도구가 아니라,
목표를 이해하고, 계획을 세우고, 검증하고, 다시 고치고, 끝내 배포까지 밀어붙이는 자율 실행 체계다.

내가 이해한 핵심 포인트

하네스는 처음부터 완성형이 아니라 점진적으로 자란다.
오케스트레이터가 중심이고, 하위 에이전트는 역할별로 분리된다.
계획/제작/배포는 모두 루프로 설계되어 되돌아갈 수 있어야 한다.
Viewer는 구조를 설명하는 장치이자, 다음 확장의 기준점이다.
최종 목표는 “실행 가능한 자동화”이지 “예쁜 다이어그램”만은 아니다.

배운 점 / 다음에 더 볼 것

훅, 정책 게이트, 스크립트를 어디까지 강제할지
상태 저장소에 어떤 체크포인트를 남길지
실제 실행 중 실패를 어떻게 복구할지
배포 이후 운영 루프를 어디까지 포함할지