비전문가를 위한 Harness·Loop·Graph Engineering 통합 가이드

0. 용어보다 먼저: 월간 행사 안내문을 만드는 장면

문화센터 담당자가 네 협력기관에서 받은 자료로 다음 달 행사 안내문을 만든다고 해보자. 자료는 이메일, PDF, 회의 메모, 기존 안내문에 흩어져 있다. 담당자는 보통 다음 일을 직접 반복한다.

1. 네 자료에서 날짜·장소·신청 조건을 찾는다.

2. 서로 다른 표기를 하나로 맞춘다.

3. 빠진 정보와 충돌하는 날짜를 다시 확인한다.

4. 안내문 초안을 쓴다.

5. 팀장에게 보내기 전 오탈자와 근거를 검사한다.

6. 반려되면 고치고, 승인되면 메일로 발송한다.

AI에게 “안내문을 써줘”라고 한 번 말하면 초안은 빨리 나올 수 있다. 하지만 이것만으로는 실제 업무가 끝나지 않는다. AI가 어떤 자료를 읽어도 되는지, 충돌하는 날짜는 어떻게 처리할지, 수정은 몇 번까지 할지, 승인 전에 메일을 보내면 안 된다는 규칙을 누군가 정해야 한다. 네 기관의 자료를 동시에 읽었다면 결과를 누가 합칠지도 필요하다. 무엇보다 “작성 완료”와 “검증·승인·발송 완료”는 서로 다른 상태다.

이 장면을 안정적인 작업 시스템으로 바꾸면 세 가지 관점이 보인다.

• 하네스(Harness)는 AI가 일할 책상과 안전 규칙이다. 읽을 자료, 쓸 수 있는 폴더, 사용할 도구, 검증 기준, 승인 경계를 미리 갖춘다.

• 루프(Loop)는 초안 작성 → 검사 → 수정 → 상태 기록 → 종료 또는 사람 인계를 반복하는 움직임이다.

• 그래프(Graph)는 네 기관 자료를 나눠 읽고, 다시 합치고, 검증 관문을 통과하고, 승인 여부에 따라 발송 또는 보류로 갈라지는 길을 눈에 보이게 만든 구조다.

한 문장으로 기억하면 된다.

하네스가 바닥을 깔고, 루프가 움직이며, 그래프가 복잡한 길을 보이게 한다.

이 셋은 초급·중급·고급처럼 순서대로 교체되는 단계가 아니다. 단순한 일에도 좋은 하네스가 필요할 수 있고, 복잡한 그래프의 한 노드 안에서 짧은 루프가 돌 수 있다. 하나의 시스템을 서로 다른 질문으로 보는 세 관점이다.

1. 세 개념을 정확히 정의하기

1.1 Harness Engineering: 모델을 실제 일에 연결하는 반복 가능한 작업 환경과 안전장치

하네스는 모델 자체가 아니다. 모델 바깥에서 다음을 정리하는 실행 환경이다.

• 맥락: 목표, 프로젝트 규칙, 용어, 참고할 정본

• 도구와 권한: 무엇을 읽고, 만들고, 수정하고, 전송할 수 있는가

• 검증: 결과가 맞는지 어떤 검사와 증거로 판단하는가

• 상태와 기억: 세션이 바뀌어도 무엇을 이어받는가

• 안전 경계: 금지 작업, 승인 지점, 격리된 작업 공간, readback과 rollback

비전문가에게는 “유능한 조수에게 사무실, 자료함, 업무 매뉴얼, 결재 규정, 검수표를 함께 제공하는 것”이라고 설명할 수 있다. 같은 모델도 하네스가 달라지면 읽는 정보, 가능한 행동, 완료 판정이 달라진다.

1.2 Loop Engineering: 실행·검증·상태·멈춤·사람 인계를 포함한 반복

루프는 단순히 같은 명령을 여러 번 실행하는 것이 아니다. 최소한 다음 흐름이 있어야 한다.

목표와 현재 상태 읽기
→ 한 번 실행하기
→ 결과 검증하기
→ 상태 기록하기
→ 계속 / 성공 종료 / 실패 종료 / 사람 인계 결정하기

핵심은 반복 횟수가 아니라 진전의 증거다. 검증이 없으면 잘못된 결과가 다음 반복의 입력이 될 수 있다. 상태가 없으면 매번 처음부터 시작한다. 성공·실패 멈춤 규칙이 없으면 너무 일찍 “완료”하거나 끝없이 비용을 쓴다. 사람이 판단해야 할 불확실성이나 되돌리기 어려운 행동이 나오면 자동 반복을 멈추고 인계해야 한다.

1.3 Graph Engineering: 복잡한 실행 길을 보이는 구조로 외부화하기

이 가이드에서 Graph Engineering은 에이전트의 실행·제어 흐름을 다음 부품으로 명시하는 실무 관점이다.

• 노드(node): 자료 읽기, 비교, 초안 작성, 검증, 승인 요청처럼 책임이 분명한 작업

• 실제 데이터 edge: 앞 노드의 어떤 출력이 뒤 노드의 입력으로 흐르는지 표시한 연결

• 제어 edge: 데이터가 없어도 승인, 자원 잠금, 안전 순서 때문에 먼저 실행되어야 하는 관계

• 분기(branch): 자료별 조사, 위험도별 경로처럼 갈라지는 길

• 병합(join/fan-in): 여러 결과를 모아 누락·충돌·중복을 판단하는 지점

• 검증 gate: 통과하지 못한 결과가 다음 단계로 가지 못하게 하는 관문

• bounded cycle: 수정처럼 반복되지만 횟수·시간·비용·진전 없음 조건으로 반드시 끝나는 순환

Graph Engineering은 신흥 실무 용어이며, 표준화된 학문 분야·공식 규격·인증 체계가 아니다. 따라서 특정 프레임워크의 기능이나 제품 명령을 일반 법칙으로 확대하지 않는다. 유용한 핵심은 “복잡한 제어 흐름과 상태, 실패 처리를 모델의 암묵적 판단 안에 숨기지 말고 사람이 읽고 시험할 수 있게 꺼낸다”는 데 있다.

2. Harness·Loop·Graph 비교표

세 관점의 관계를 단계적 우열로 읽으면 안 된다.

• 좋은 하네스 안에서 단순 prompt나 chain만 실행할 수 있다.

• 하나의 루프가 충분한 업무도 많다.

• 그래프의 각 노드 안에 짧은 loop가 들어갈 수 있다.

• 그래프를 그렸어도 권한·검증·상태가 약하면 신뢰성은 생기지 않는다.

• 하네스와 루프가 좋아도 branch·join이 많은 일을 한 줄로 숨기면 누락과 충돌을 찾기 어렵다.

3. Prompt·Chain·Loop·Graph 중 무엇을 고를까

가장 단순한 구조로 요구를 충족하는 것이 좋은 설계다. 복잡한 이름을 쓰는 것이 목적이 아니다.

빠른 선택 질문

1. 사람이 결과를 한 번 읽고 끝내도 되는가? 그렇다면 Prompt를 먼저 본다.

2. 모든 단계를 미리 알고 있고 경로가 고정됐는가? 그렇다면 Chain이 맞다.

3. 결과에 따라 다시 시도하고, 진행 상태와 멈춤 조건을 남겨야 하는가? Loop를 쓴다.

4. 서로 독립인 일이 여러 개이고, 다시 합치거나 승인·보류로 갈라져야 하는가? Graph를 검토한다.

5. Graph의 유지비가 실패 비용보다 큰가? 그렇다면 Loop나 Chain으로 되돌린다.

4. “Graph”라는 말의 세 가지 뜻

같은 단어를 쓰지만 서로 다른 문제를 푼다.

Obsidian의 wikilink가 많다고 실행 graph가 안전해지는 것은 아니다. 실행 trace가 있다고 문서의 주장이 참이 되는 것도 아니다. ML computational graph를 최적화한다고 사람 승인이나 파일 충돌 문제가 해결되지도 않는다.

5. AKM은 어디에 들어가는가

5.1 한 문장 경계

AKM은 여러 에이전트가 함께 참조하는 shared knowledge-operating control plane이고, 실제 모델·도구·권한·채널·스케줄러 실행은 각 native runtime의 경계에 남는다.

AKM은 Markdown과 규칙만으로 메일을 보내거나 모델을 호출하지 않는다. Hermes, Claude Code, Codex, Aside 같은 네이티브 런타임이 자신의 도구·권한·세션·채널·스케줄러를 사용해 실제 행동을 수행한다. 얇은 adapter나 시작 지시는 런타임에게 AKM의 정본과 절차를 어디서 읽고, 결과와 실패를 어디에 되돌릴지 알려준다.

5.2 Answer-reference knowledge와 agent-operating knowledge

AKM에는 “답을 만들 때 참고하는 지식”과 “에이전트가 일하는 방식을 바꾸는 지식”이 모두 필요하다.

둘은 완전히 분리된 세계가 아니다. 예를 들어 “공개 글에는 확인되지 않은 수치를 쓰지 않는다”는 지식은 출처 평가 기준으로는 answer-reference이고, 출판 검사표에 들어가면 agent-operating knowledge가 된다. 핵심은 같은 내용을 여러 사본으로 복제하는 것이 아니라, 정본을 두고 필요한 절차가 그 정본을 참조하게 하는 것이다.

5.3 Harness·Loop·Graph를 AKM에 매핑하기

6. 마지막 기억법

• Harness는 반복 사용 가능한 작업 환경과 안전장치다. 모델이 무엇을 읽고 어떤 도구와 권한으로 일하며 어떻게 검증·기억·차단되는지를 정한다.

• Loop는 실행만의 반복이 아니다. 실행 + 검증 + 상태 + 성공·실패 stop + 사람 인계가 한 묶음이다.

• Graph는 복잡한 길을 보이게 한다. 노드와 실제 data/control edge, 분기, 병합, gate, bounded cycle을 명시한다.

• 셋은 단계적 우열이 아니다. 하네스 위에서 루프가 돌고, 복잡한 루프와 여러 역할은 그래프로 표현할 수 있다.

• AKM은 shared knowledge-operating control plane이다. 실제 모델·도구·권한·채널·스케줄러 실행은 native runtime에 남는다.

• 지식 graph, 실행 graph, ML computational graph를 섞지 않는다.

• 검증과 single writer가 완료를 지킨다. 여러 branch는 조사할 수 있지만 canonical 정본은 한 writer가 쓰고, auditor는 증거로 통과·보류를 판정한다.

• 좋은 자동화는 오래 도는 시스템이 아니다. 올바른 이유로 다시 시도하고, 올바른 이유로 멈추며, 불확실할 때 사람에게 넘기는 시스템이다.