DGM-H 사용법과 핵심 설정 포인트 2026 — generate_loop, staged eval, parent 선택은 어디서 만지나

Posted on by

DGM-H를 쓰려면

모델 하나만 갈아끼우면 될까.

보통은 그렇게 상상한다.

논문을 읽고 나면

더 강한 모델,

더 좋은 프롬프트,

더 긴 컨텍스트만 떠오르기 쉽다.

근데 레포를 열어보면

첫인상은 좀 다르다.

진짜 먼저 보이는 건

모델 이름이 아니라

generate_loop.py,

run_meta_agent.py,

select_next_parent.py,

그리고 Docker,

평가,

출력 폴더다.

즉 DGM-H는

그럴싸한 논문 이름보다

실제로는

반복 생성 -> 평가 -> 부모 선택 -> 다시 생성

루프를 어떻게 굴리느냐가 더 중요하다.

2026년 4월 13일 기준

arXiv 2603.19461 초록은

HyperAgents를

task agent와 meta agent를

하나의 editable program으로 통합한

self-referential agent framework라고 설명한다.

그리고 그 구현체로

DGM-Hyperagents,

즉 DGM-H를 제시한다.

GitHub README는

이 프로젝트를

any computable task에 최적화할 수 있는

self-referential self-improving agents라고 소개한다.

하지만 같은 README를 보면

setup 단계부터

API key,

Python 3.12,

graphviz,

cmake,

ninja,

Docker build,

setup_initial.sh

순서가 나온다.

이 말은 곧

DGM-H는

완성된 앱을 켜는 사용법보다,

실험 러너를 세팅하고

탐색 루프를 굴리는 사용법이 더 중요하다는 뜻이다.

그래서 이 글은

HyperAgents 개론의 후속편이지만,

논문 요약을 또 하지 않는다.

대신

처음 레포를 열었을 때

정말 어디부터 만져야 하는지,

어떤 옵션이

탐색 폭과 비용과 위험을 같이 바꾸는지,

레포 기준으로 정리한다.

한 줄 답

  • DGM-H를 처음 볼 때 가장 먼저 건드릴 파일은 generate_loop.py다.
  • 핵심 설정은 run_baseline, optimize_option, skip_staged_eval, edit_select_parent, parent_selection 다섯 개라고 봐도 된다.
  • run_meta_agent.py는 meta agent를 돌린 뒤 domains/ 변경을 base commit으로 되돌리고 model_patch.diff를 저장하는 래퍼 역할을 한다.
  • select_next_parent.py는 유효한 부모만 남기고 도메인별 점수를 평균낸 뒤, 최종 후보 중 하나를 랜덤 선택해 탐색 공간을 열어두는 쪽으로 구현돼 있다.
  • 즉 DGM-H 사용법의 핵심은 모델보다 루프를 얼마나 공격적으로 돌릴지, 평가를 어디까지 생략할지, 부모 선택을 얼마나 열어둘지를 정하는 일이다.

먼저 이것부터 알아야 한다

DGM-H는

사용자용 제품이 아니다.

이 말이 괜히 중요하다.

README가 맨 처음 설명하는 것도

대시보드나 웹 UI가 아니라

환경 세팅이다.

공식 README 기준으로

먼저 필요한 건 이렇다.

  • .env에 OPENAI_API_KEY, ANTHROPIC_API_KEY, GEMINI_API_KEY
  • Python 3.12 개발 헤더
  • graphviz와 graphviz-devel
  • cmake, ninja-build, 각종 빌드 의존성
  • 가상환경 생성과 requirements 설치
  • docker build --network=host -t hyperagents .
  • bash ./setup_initial.sh

그리고 실행 예시는

정말 짧다.

python generate_loop.py --domains <domain>

README는

기본 출력이

outputs/ 폴더에 저장된다고 적는다.

이 간단한 설명이

오히려 중요하다.

왜냐하면 여기서 이미

이 프로젝트의 사용 단위가

대화창이 아니라

출력 폴더를 남기는 실험 루프

라는 게 드러나기 때문이다.

즉

처음부터

무슨 질문을 던지지

보다

어떤 도메인으로 몇 세대를 돌릴지

를 생각해야 한다.

내 해석으로는

이 레포를 처음 만지는 사람의 첫 실수는

논문에서 느낀 감탄을

바로 제품 기대치로 옮기는 거다.

실제로는

연구 코드에 가깝고,

사용법도

채팅형 인터페이스가 아니라

하네스형 실행 흐름에 가깝다.

이걸 먼저 받아들이면

나머지 설정도 훨씬 덜 헷갈린다.

진짜 시작점은 generate_loop.py다

레포 기준으로

DGM-H의 메인 엔트리포인트는

generate_loop.py다.

README도

entry point for running the algorithm

라고 직접 적어둔다.

코드를 보면

generate_loop( 함수 시그니처가

바로 이 프로젝트의 조종간이다.

기본값은 이렇게 잡혀 있다.

  • max_generation=3
  • eval_samples=-1
  • eval_workers=5
  • parent_selection="score_prop"
  • run_baseline=None
  • optimize_option="only_agent"
  • eval_test=False
  • skip_staged_eval=False
  • edit_select_parent=False

이 조합을 한 줄로 읽으면

처음 기본 모드는

세대 수는 보수적으로,

평가는 켠 상태로,

부모 선택 메커니즘 수정은 끈 상태로,

에이전트 최적화만 우선

쪽에 가깝다.

중요한 건

이 옵션들이 서로 독립처럼 보여도

실제로는 묶여서 움직인다는 점이다.

예를 들어

skip_staged_eval을 켜면

실험 속도는 빨라질 수 있지만,

안 좋은 변형이

더 빨리 다음 단계까지 올라갈 수 있다.

edit_select_parent를 켜면

탐색 자유도는 커지지만,

부모 선택 메커니즘 자체를

에이전트가 건드릴 수 있게 되므로

실험 해석 난이도도 같이 올라간다.

즉

DGM-H에서 설정은

토글 모음이 아니다.

실험 철학을 고르는 버튼들에 가깝다.

처음 만져야 할 설정 1번은 run_baseline이다

내가 보기엔

초심자가 가장 먼저 고정해야 하는 건

run_baseline이다.

이유는 단순하다.

이 옵션이

지금 내가 HyperAgents를 돌리는 건지,

아니면 비교군을 돌리는 건지

를 결정하기 때문이다.

generate_loop.py의 CLI는

run_baseline에 대해

이 선택지를 둔다.

  • no_selfimprove
  • no_archive
  • dgm
  • dgm_custom
  • dgm+no_selfimprove
  • dgm_custom+no_selfimprove

즉

이 레포는

처음부터

하나의 절대 정답 실행만 상정하지 않는다.

비교군과 변형 실험을

같은 엔트리포인트에서 돌리게 설계돼 있다.

그리고 함수 내부를 보면

run_baseline == "no_archive"일 때는

parent_selection을 강제로 latest로 바꾼다.

이건 매우 실전적인 디테일이다.

왜냐하면

baseline이 바뀌면

부모 선택 규칙도 같이 바뀐다는 뜻이기 때문이다.

즉

baseline은

그냥 실험 이름표가 아니라

탐색 구조 자체를 바꾸는 레버다.

처음 레포를 읽는 사람은

종종 이걸 놓친다.

baseline도 어차피 비슷하겠지

라고 보면

이후 결과 차이를

제대로 해석하기 어려워진다.

그래서 첫 단계는

항상 이거다.

나는 지금 진짜 하이퍼에이전트 루프를 보려는 건가

아니면 비교군을 보려는 건가

이 질문을 먼저 잠근다.

두 번째는 optimize_option이다

두 번째로 중요한 설정은

optimize_option이다.

코드에서 기본값은

only_agent다.

CLI 선택지는

이렇게 나온다.

  • both_agent_ensemble
  • only_agent
  • only_ensemble

그리고 코드에는

--optimize_option=only_ensemble일 때

--agent_archive_path가 반드시 필요하다는

검증도 들어 있다.

이건 그냥 친절한 에러 메시지가 아니다.

레포가 무엇을 최적화 단위로 보는지

드러내는 힌트다.

즉

이 프로젝트는

항상 하나의 단일 에이전트만 고치는 게 아니라,

에이전트와 앙상블을

분리해서 최적화할 수 있게 설계돼 있다.

여기서 초심자 판단 기준은 꽤 명확하다.

  • 레포 구조를 이해하려는 첫 실행이면 only_agent
  • 앙상블 효과까지 보려면 both_agent_ensemble
  • 이미 있는 agent archive를 기반으로 ensemble만 만지려면 only_ensemble

내 해석으로는

처음부터 both_agent_ensemble로 가면

실험 해석 복잡도가 꽤 빨리 올라간다.

왜냐하면

성능 변화가

에이전트 개선에서 왔는지,

앙상블 전략에서 왔는지,

두 개가 섞여서 왔는지

구분하기가 어려워지기 때문이다.

그래서

첫 삽은 only_agent,

그다음에

앙상블을 붙이는 순서가

훨씬 읽기 쉽다.

연구 코드도

처음부터 모든 손잡이를 다 잡으면

손이 아니라 머리가 미끄러진다.

세 번째는 staged eval을 끌지 말지다

실행 속도를 고민할 때

사람이 제일 먼저 건드리고 싶어지는 옵션이

skip_staged_eval이다.

이건 이해할 만하다.

평가가 제일 비싸고,

제일 오래 걸리고,

제일 답답해 보이기 때문이다.

그런데 코드 흐름을 보면

이 옵션은 생각보다 중요하다.

generate_loop.py는

staged evaluation이 켜져 있으면

먼저 작은 샘플 평가를 돌리고,

stagedeval_scores를 모은 뒤,

모든 도메인 점수가 0보다 큰 경우에만

run_next_eval = True로 두고

full evaluation으로 넘어간다.

즉

staged eval은

단순한 시간 낭비가 아니라

초기 필터 역할을 한다.

말 그대로

이 후보를 다음 라운드까지 데려갈 가치가 있나

를 거르는 문지기다.

그래서

skip_staged_eval=False 기본값은

꽤 설득력 있다.

초반에는

느려 보여도

쓰레기 후보를 일찍 걸러줘서

오히려 전체 루프를 덜 망가뜨릴 수 있기 때문이다.

반대로

실험을 아주 공격적으로 돌리고 싶고,

이미 도메인과 평가 구조를 충분히 이해했고,

빠른 탐색을 일부러 우선하는 상황이면

그때 skip_staged_eval=True를 고민할 수 있다.

내가 보기엔

이 옵션은

속도 옵션이 아니라

리스크 허용치 옵션에 가깝다.

네 번째는 parent selection이다

DGM-H를 읽다가

사람들이 자꾸 모델 쪽만 보는데,

실제로 재미있는 건

부모를 어떻게 뽑느냐다.

generate_loop.py CLI를 보면

parent_selection 선택지는

다섯 개다.

  • random
  • latest
  • best
  • score_prop
  • score_child_prop

그리고 기본값은

score_child_prop다.

하지만 함수 generate_loop(의 기본 인자는

parent_selection="score_prop"로 되어 있다.

즉

실행 경로를 어떻게 타느냐에 따라

기본 체감이 달라질 수 있고,

CLI가 실제 권장 진입점 역할을 한다고 읽는 편이 자연스럽다.

여기서 더 중요한 건

edit_select_parent다.

코드를 보면

edit_select_parent가 꺼져 있거나

run_baseline == "no_archive"면

기존 select_parent(...)를 쓴다.

반대로

edit_select_parent가 켜져 있으면

select_next_parent_container(...) 경로로 간다.

즉

부모 선택 메커니즘 자체를

에이전트가 건드릴 여지를 열어주는 거다.

그리고 select_next_parent.py를 보면

이 로직은

유효한 부모만 남긴 뒤,

도메인별 점수를 모으고,

val split이 있으면 val,

없으면 train의 max score를 써서

평균 점수를 만든다.

그 다음

child count도 계산하지만,

최종 선택은

후보 집합 안에서

랜덤으로 하나를 뽑는 방식이다.

코드 주석도

탐색 공간을 열어두기 위해

랜덤 선택을 한다는 취지다.

이 포인트가 재밌다.

왜냐하면

겉으로 보면

굉장히 똑똑한 selection policy를 기대하게 되는데,

실제 구현은

후보 정제까지는 점수 기반으로 하고,

마지막은 의도적으로

열어둔다는 철학이 보이기 때문이다.

즉

DGM-H의 parent selection은

제일 점수 높은 놈만 고집한다

보다

탐색을 너무 빨리 닫지 않는다

에 더 가깝다.

다섯 번째는 run_meta_agent.py다

이 레포를 실전적으로 읽을 때

제일 좋은 파일 중 하나는

run_meta_agent.py다.

왜냐하면

meta agent가

결과를 어떻게 남기고,

어떤 변경을 버리고,

무슨 patch를 저장하는지

가장 압축적으로 보여주기 때문이다.

CLI 인자를 보면

여기서 챙기는 건 이렇다.

  • --model
  • --chat_history_file
  • --repo_path
  • --evals_folder
  • --iterations_left
  • --git_dir
  • --base_commit
  • --outdir

실행 순서는 더 중요하다.

  1. MetaAgent(...)를 생성한다.
  2. meta_agent.forward(...)로 repo와 eval path를 넣고 돈다.
  3. 그 뒤 reset_paths_to_commit(... paths=["domains/"])를 호출한다.
  4. 마지막으로 base commit 대비 diff를 떠서 model_patch.diff로 저장한다.

이 흐름은

실무적으로 꽤 큰 힌트다.

즉

meta agent를 한 번 돌린 다음

아무 diff나 그대로 받는 게 아니라,

적어도 domains/ 쪽 변경은

base commit 기준으로 리셋하고,

남는 변경만 patch로 남긴다.

내 해석으로는

이건

무엇을 메타 수준 개선 대상으로 볼지

경계를 정하는 장치다.

모든 걸 다 바꾸게 두면

결과 해석이 너무 어려워질 수 있으니,

도메인 정의 변경 같은 부분은

걷어내고 보는 거다.

이런 경계선이 있어야

자기개선이

그냥 난장 diff가 아니라

실험 가능한 patch로 남는다.

즉

run_meta_agent.py는

단순한 실행 래퍼가 아니라

자기개선 결과를

관리 가능한 diff로 정리하는 파일이다.

로그와 출력은 어떻게 읽어야 하나

README는

기본 출력이 outputs/로 간다고만 짧게 말하지만,

generate_loop.py를 보면

출력 구조가 꽤 일관되다.

generate_loop(는

새 실행이면

outputs/generate_<run_id>/

형태의 폴더를 만들고,

그 아래에

gen_<generation>/

단위로 세대별 결과를 저장한다.

각 generation 폴더에는

generate.log,

agent_output/,

그리고 마지막에 저장되는

metadata.json

같은 흔적이 남는다.

코드를 보면

metadata에는

gen_output_dir,

run_eval,

valid_parent

같은 값이 포함된다.

그리고 generation이 끝나면

archive를 갱신한다.

이 구조가 좋은 이유는

실험이 실패해도

어느 세대에서

무슨 patch가 나왔고

평가를 탔는지

를 뒤에서 읽어낼 수 있기 때문이다.

즉

DGM-H 사용법에서

중요한 건

화려한 성공 캡처보다

출력 폴더를 읽는 습관이다.

로그를 안 보면

자기개선은 신비주의가 되고,

로그를 보면

하네스가 된다.

처음 돌릴 때 나는 이 순서를 추천한다

여기부터는

공식 문서와 코드 구조를 바탕으로 한

내 운영 추천이다.

즉

직접적 사실 인용이 아니라

실행 순서에 대한 해석이다.

1단계. 기본 모드로 구조부터 확인

  • run_baseline=None
  • optimize_option=only_agent
  • skip_staged_eval=False
  • edit_select_parent=False
  • 세대 수는 기본 max_generation=3 또는 더 작게

이렇게 가면

루프 구조를 읽기 좋다.

무슨 세대에서

무슨 patch가 나오고,

언제 평가가 붙고,

어떻게 archive가 갱신되는지

파악하기 쉽다.

2단계. baseline을 바꿔 비교군 감 잡기

그 다음에

run_baseline만 바꿔서

비교군을 본다.

이때는

모든 옵션을 같이 흔들지 않는 편이 좋다.

그래야

차이가 baseline 때문인지

평가/선택 옵션 때문인지

섞이지 않는다.

3단계. staged eval을 줄일지 판단

속도가 너무 느리다고 느껴질 때

그제서야

skip_staged_eval을 건드린다.

이걸 너무 빨리 건드리면

빠르긴 한데

왜 망했는지를 읽기 어려워진다.

4단계. parent selection을 연다

마지막에

edit_select_parent=True

같은 옵션을 붙여서

선택 메커니즘 자체를 열어본다.

이건 탐색 자유도를 올리는 대신

실험 해석 난이도도 같이 올린다.

그래서 처음부터 켜는 것보다

루프를 이해한 뒤 여는 편이 낫다.

흔히 잘못 읽는 포인트

1. DGM-H를 그냥 모델 오케스트레이터로 읽는 것

아니다.

코드 구조를 보면

이건

실험 러너와 평가 하네스에 더 가깝다.

모델 호출은 중요하지만,

핵심은

수정 -> 평가 -> 선택 -> 기록

루프다.

2. parent selection이 완전히 점수 최적화라고 생각하는 것

select_next_parent.py를 보면

후보 정제는 점수 기반이지만

최종 선택은 랜덤이다.

즉

탐색을 일부러 닫지 않는 철학이 들어 있다.

3. staged eval을 단순한 속도 저하로만 보는 것

코드상으론

초기 필터 역할이 있다.

좋지 않은 후보를

full evaluation 전에 거르는 장치다.

4. meta agent가 만든 diff를 전부 그대로 채택한다고 생각하는 것

run_meta_agent.py는

domains/ 변경을 base commit으로 되돌린 다음

diff를 저장한다.

즉

변경 경계가 있다.

5. 이 레포를 안전한 샌드박스라고 착각하는 것

README는

모델이 생성한 신뢰할 수 없는 코드를 실행하므로

안전 리스크를 인지하라고 경고한다.

이건 장식 문구가 아니다.

연구 코드에서 제일 위험한 건

성능보다도

안전 경계를 과신하는 태도다.

제일 먼저 확인할 체크리스트

DGM-H를 처음 만질 때

나는 이 체크리스트를 먼저 본다.

체크 항목 왜 먼저 보나
.env API key 준비 모델 호출이 막히면 나머지가 다 멈춤
Docker build 성공 여부 루프가 컨테이너 기반으로 돌기 때문
setup_initial.sh 완료 여부 초기 agent 뼈대가 없으면 이후 흐름이 불안정
run_baseline 선택 지금이 본 실험인지 비교군인지 정해짐
optimize_option 선택 에이전트만 볼지 앙상블까지 볼지 결정
skip_staged_eval 유지 여부 속도와 리스크 허용치가 바뀜
edit_select_parent 여부 부모 선택 메커니즘 자체를 열지 결정
outputs/ 읽기 습관 결과를 신비주의가 아니라 로그로 읽게 됨

이 표에서 중요한 건

설정을 다 외우는 게 아니다.

실험이 흔들릴 때

어디를 먼저 의심해야 하는지

순서를 잡는 것이다.

연구 레포는

정답을 주는 앱이 아니라

오답이 왜 났는지 스스로 읽어야 하는 도구에 가깝다.

그래서 순서가 중요하다.

이 글을 읽고 바로 할 수 있는 최소 실험

실제로 바로 해볼 수 있는

가장 작은 실험도 정리해보자.

여기부터는

공식 문서의 직접 지시가 아니라

내가 추천하는 최소 실험 단위다.

최소 실험 A

  • 한 개 도메인만 선택
  • only_agent
  • skip_staged_eval=False
  • edit_select_parent=False
  • generation 수는 작게

이건

레포의 기본 숨결을 느끼는 실험이다.

무엇이 생성되고

어디에 저장되고

무슨 로그가 남는지만 봐도

학습이 된다.

최소 실험 B

  • 같은 조건에서 baseline만 변경

이건

자기개선 루프와 비교군 차이를

해석하는 실험이다.

최소 실험 C

  • staged eval만 끄고 속도 차이 확인

이건

비용과 리스크를

어떻게 교환하는지 보는 실험이다.

최소 실험 D

  • parent selection 관련 옵션 열기

이건 제일 마지막이다.

왜냐하면

탐색 메커니즘이 바뀌면

결과가 재밌어지는 대신

무엇 때문인지 설명이 어려워지기 때문이다.

결국 DGM-H 사용법은 어디를 읽느냐의 문제다

논문만 읽으면

HyperAgents는

굉장히 큰 개념처럼 보인다.

맞다.

실제로 큰 개념이다.

하지만 레포를 열면

DGM-H 사용법은

상당히 구체적인 파일 몇 개로 내려온다.

  • README.md에서 환경과 진입점 확인
  • generate_loop.py에서 실험 철학 확인
  • run_meta_agent.py에서 patch 경계 확인
  • select_next_parent.py에서 탐색 철학 확인

이 네 개를 읽으면

DGM-H는 뭘 만져야 하는가

라는 질문은 훨씬 덜 추상적이 된다.

그리고 내 결론은 이거다.

DGM-H의 핵심 설정 포인트는

모델 이름보다

baseline,

최적화 범위,

평가 단계,

부모 선택 자유도

에 있다.

즉

이 레포를 잘 쓰는 법은

더 센 모델을 찾는 일보다

실험 루프를 얼마나 이해한 상태에서 옵션을 여느냐에 가깝다.

이걸 모르고 만지면

자기개선이 아니라

자기혼란이 된다.

반대로

이걸 알고 만지면

논문이 말한 자기개선 구조를

조금 더 하네스 언어로 읽게 된다.

연구 레포는

원래 약간 무섭다.

근데 무서운 이유를 알고 건드리면

그 순간부터는

도구가 된다.

FAQ

DGM-H는 HyperAgents랑 같은 말인가

완전히 같은 말은 아니다.

arXiv 초록은

HyperAgents를 프레임워크로 설명하고,

DGM-Hyperagents,

즉 DGM-H를

그 프레임워크의 구현체로 제시한다.

그러니까 HyperAgents가 큰 개념이고,

DGM-H는 그 개념을 실제 루프로 돌리는 구체 구현으로 이해하는 쪽이 자연스럽다.

DGM-H를 처음 돌릴 때 제일 먼저 볼 옵션은 뭐냐

내 기준으로는

run_baseline,

optimize_option,

skip_staged_eval

세 개다.

이 셋이

실험 성격,

최적화 범위,

속도와 리스크 균형을

제일 크게 바꾼다.

parent selection은 결국 최고 점수만 따라가는 구조냐

레포 기준으로는

그렇게 단순하지 않다.

select_next_parent.py는

유효한 부모만 남기고

도메인별 점수를 평균낸 뒤,

최종 후보 중 하나를 랜덤으로 선택해

탐색 공간을 열어두는 방향을 취한다.

즉

무조건 top-1만 고집하는 구조라고 읽으면 안 된다.

staged eval은 꺼도 되나

기술적으로는 가능하다.

CLI에 --skip_staged_eval 옵션이 있다.

하지만 코드 흐름상

staged eval은

작은 샘플 평가 뒤

full evaluation로 갈지 말지 거르는 문지기 역할을 한다.

그래서 초반 이해 단계에서는

끄지 않는 편이 더 안전하다.

왜 run_meta_agent.py가 domains 변경을 되돌리냐

코드 기준으로

run_meta_agent.py는

meta agent를 실행한 뒤

paths=["domains/"]를 base commit으로 reset하고,

그 다음 diff를 model_patch.diff로 저장한다.

내 해석으로는

메타 수준 개선 결과를

해석 가능한 patch로 남기기 위한 경계 설정에 가깝다.

공식 출처

관련 글