서론

AI 코딩 에이전트(AI Coding Agent)를 일상적으로 사용하다 보면, 운용 스타일이 조금씩 두 파벌로 나뉘는 것을 느낍니다.

하나는, 하네스(harness)를 정비하여 시스템으로 돌리는 파입니다. 스킬(skill), 후크(hook), 퍼미션(permission), 워크트리(worktree)와 같은 "발판"을 정교하게 만들어, 에이전트가 안정적으로 달릴 수 있는 레일을 까는 타입입니다.

다른 하나는, loop나 goal 커맨드로 힘으로 밀어붙이는 파입니다. 세세한 발판 만들기는 뒤로 미루고, "이 목표를 향해 계속 달려라"라고 커맨드로 밀어붙이는 타입입니다.

이 기사에서는 양자가 가리키는 것을 용어와 아키텍처(architecture) 레벨에서 정리한 후, 각각을 실제 설정 파일과 코드에 적용하면 어떻게 되는지를 보여주고, 저 자신이 도달한 "힘으로 탐색하고, 하네스로 양산한다"라는 하이브리드(hybrid) 운용 방식을 공유합니다. 예시는 주로 Claude Code를 사용하지만, 사고방식은 Codex나 다른 에이전트에서도 동일합니다.

결론부터 말씀드리면, 이 두 가지는 대립하는 종파가 아니라, **동일한 워크플로우(workflow)의 서로 다른 레이어(layer)**입니다. 어느 한 쪽을 선택하는 문제가 아니라, 언제 어느 쪽에 무게를 둘 것인가라는 배분의 문제라고 생각합니다.

우선 용어를 정리하자. 하네스와 루프는 "층"이 다르다

"하네스파 vs 커맨드파"라는 표현은 직관적이지만, 엄밀히 말하면 약간의 차이가 있습니다. 양자는 같은 운동장에서의 선택지가 아니라, 겹겹이 쌓인 별개의 층이기 때문입니다.

┌─────────────────────────────────────┐
│ 루프 층 (loop / goal 커맨드)        │ ← 목표를 향해 반복적으로 구동함
├─────────────────────────────────────┤
...

하네스(harness)란

하네스란, 언어 모델(LLM) 단체를 "행동할 수 있는 에이집트"로 바꾸기 위해 모델을 둘러싸는 인프라(infrastructure) 층을 말합니다. 구체적으로는 다음과 같은 요소로 구성됩니다.

에이전트 루프(Agent Loop): 모델이 추론하고, 도구(tool)를 호출하며, 결과를 반환하는 기본 사이클 -
도구 인터페이스(Tool Interface): 파일 읽기/쓰기, 셸(shell) 실행, 검색 등의 도구 세트 -
컨텍스트 관리(Context Management): 읽은 파일, 실행 로그, 차이점(diff) 등을 어떻게 유지 및 압축할 것인가 -
제어 기구(Control Mechanism): 퍼미션(permission), 후크(hook), 샌드박스(sandbox)와 같은 "실행하는 측"의 게이트 -

중요한 점은, 하네스가 다루는 것은 기본적으로 에이전트 1체가 달리는 환경 그 자체라는 점입니다. Claude Code의 경우, 하네스 층은 구체적인 파일로 다룰 수 있습니다.

// .claude/settings.json にパーミッションとフックを書く
{
"permissions": {
...

재사용하고 싶은 작업 절차는 .claude/skills/<name>/SKILL.md에, 프로젝트의 전제 지식은 CLAUDE.md에 둡니다. 이 모든 것이 "1회의 실행을 안정시키는" 하네스 층의 부품입니다.

루프(loop / goal 커맨드)란

반면 루프는 그 하네스의 한 단계 더 높은 층에 있습니다. "에이전트를 매 턴마다 손으로 재촉하는" 것이 아니라, 목표를 향해 에이전트를 반복적으로 구동하는 시스템을 가리킵니다.

2026년 6월경부터 "루프 엔지니어링(loop engineering)"이라는 용어로 이 사고방식이 퍼졌습니다. 골격은 단순하며, 다음 사이클을 계속해서 돌립니다.

목표를 정의한다 (재귀적으로 달성을 목표로 하는 목표) -
해야 할 일을 찾는다 (discovery / triage) -
직접 움직인다 (act) -
결과를 검증한다 (verify) -
무엇을 했는지 기록한다 (remember) -

최소한의 루프는 셸 스크립트(shell script)로 작성할 수 있습니다. 헤드리스 모드(headless mode, claude -p)를 기계적인 검증과 결합하기만 하면 됩니다.

#!/bin/bash
# 최소한의 루프: 테스트가 통과할 때까지 에이전트를 계속 돌린다
until npm test > /tmp/test.log 2>&1; do
...

포인트는, 종료 조건(npm test의 성패)이 LLM의 자기 보고가 아니라 기계적인 판정이라는 것입니다. Claude Code의 /loop

커맨드로 "10분마다 이 프롬프트를 계속 실행해"라고 돌리는 것도, Codex 등의 goal 모드에서 "이 목표에 도달할 때까지 자율 주행해"라고 던지는 것도, 구조는 모두 이 루프(loop) 계층의 이야기입니다.

"파벌"의 정체

즉, 세상에서 말하는 "커맨드파"란 엄밀히 말하면 루프 계층을 얇은 커맨드로 빠르게 돌리는 운용을 의미합니다. 하네스(Harness)를 만드는 데 시간을 들이지 않고, loop나 goal 커맨드로 "어쨌든 실행시켜 보고 상황을 지켜본다"는 접근 방식으로 바꿔 말할 수 있습니다. 본 기사에서는 이후부터 이 운용을 "힘 방식(커맨드/루프)"이라고도 부릅니다. 명칭은 달라도 가리키는 대상은 동일한 상위 계층입니다.

반대로 "하네스파"란, 루프를 돌리기 전에 발판(환경)을 확실히 정비하는 운용입니다. 스킬(skill)이나 후크(hook)로 판단 로직을 고정하여, 에이전트가 안정적으로 달릴 수 있는 레일을 먼저 깔아둡니다.

여기서 중요한 것은, 루프 엔지니어링(loop engineering) 그 자체도 본질적으로는 "시스템화"라는 점입니다. 따라서 "힘 방식 vs 시스템화"라는 대립 구도로 보면 약간의 오해가 생길 수 있습니다. 더 정확하게는,

커맨드파 = 상위 계층(루프)에서 얇고 빠르게 공략한다
하네스파 = 하위 계층(환경)에서 두껍고 단단하게 다진다

라는, 공략하는 계층과 투자 밀도의 차이인 것입니다.

각각의 강점과 약점

계층의 차이를 이해하면 적성과 부적합성도 명확히 보입니다.

커맨드(힘 방식 루프)의 강점·약점

힘 방식 루프의 최대 적은 기술적인 어려움 그 자체가 아니라 감시(oversight) 비용입니다. 검증 메커니즘이 얇은 상태로 자율 주행을 시키면, 결국 인간이 계속 붙어서 지켜봐야 하는 상황이 되어 자동화의 이점이 사라집니다.

하네스(시스템화)의 강점·약점

하네스의 강점은 안정성과 재현성이지만, 그 반대로 "아직 정답의 형태를 모르는 것"에는 약합니다. 탐색 페이즈(exploration phase)의 태스크를 처음부터 단단한 메커니즘에 밀어 넣으려 하면, 대개 잘못된 레일을 깔게 됩니다.

나의 입장은 "힘 방식으로 탐색하고, 하네스로 양산한다"

지금까지의 정리를 바탕으로 내린 나의 결론은 하이브리드입니다. 슬로건으로 만들면 다음과 같습니다.

힘 방식은 준비, 하네스는 양산.

미지의 태스크는 우선 커맨드의 힘 방식으로 1~2회 시도해 봅니다. 거기서 "잘 작동하는 절차"의 윤곽이 보이면, 그것을 하네스(스킬·후크·스크립트)로 고정하여 양산 체제로 돌립니다. 이 순서가 가장 낭비가 적다고 느낍니다.

이하, 이 리포지토리(Zenn의 기사 관리 리포지토리)에서 "기사 릴리스 작업"을 시스템화한다고 가정하고, 4가지 단계를 코드를 곁들여 살펴보겠습니다. 실제로 이대로 운용하고 있는 것은 아니며, 어디까지나 사고방식을 구체화하기 위한 예시로 읽어주시기 바랍니다.

단계 1: 힘 방식으로 탐색하기

해본 적 없는 태스크는 갑자기 시스템화하지 않습니다. 수동 프롬프트로 투박하게 1~2회 통과시켜 봅니다.

> articles/foo.md의 published를 true로 설정하고,
> zenn preview로 렌더링을 확인한 뒤 커밋하고 push해줘.
> 커밋 메시지는 "기사 공개: <제목>"으로.

여기서의 목적은 결과물 그 자체보다, "어떤 절차라면 성공하는가"라는 패턴의 발견입니다. 실제로 해보면 사전에 보이지 않았던 절차들이 떠오릅니다.

• preview 확인을 거치지 않으면, 강조 표기(**의 직후에 전각 기호가 오는 경우 등)의 렌더링 깨짐을 놓치게 된다.
• push 전에 기사 도입부의 설정란(---로 둘러싸인 front matter) 필수 항목을 확인하지 않으면 사고가 난다. 예를 들어 published가 false인 상태로 두면 공개한 줄 알았는데 초안 상태로 남게 되거나, type의 철자 오류 또는 topics가 6개 이상이면 배포(deploy)에서 거부된다.

이 리포지토리는 main으로의 push 시 자동 배포되므로, 이러한 front matter의 미비점은 그대로 공개 프로세스로 흘러가 버립니다. 그렇기에 "push 전의 체크"가 독립된 절차로서 필요하다는 것을 직접 손을 움직여보고 나서야 깨닫게 되는 것입니다.

단계 2: 공통 구조를 파악하기

몇 번 시도해 보면서 "매번 이 검증을 하고 있다", "항상 이 순서로 작업하고 있다"라는 반복이 보이기 시작했다면, 그것이 시스템화(仕組み化)의 신호입니다. 같은 판단을 3번 했다면, 그것은 하네스(Harness)로 옮길 후보라고 생각합니다.

릴리스(Release) 작업이라면, 매번 반복하게 될 것 같은 점은 다음 3가지입니다.

• front matter의 published를 true로 변경하기
• 강조 표기(** 직후의 전각 문장 부호)의 렌더링 오류가 없는지 확인하기
• 정해진 형식의 커밋 메시지로 커밋하고 push 하기

단계 3: 하네스(Harness)에 고정하기

파악한 공통 구조를 재사용할 수 있는 형태로 고정합니다. 반복되는 작업 절차는 스킬(Skill)로, 반드시 지켜야 할 금지 사항이나 검증은 훅(Hook)으로, 알고 있어야 할 전제 조건은 CLAUDE.md로 배분하는 방식입니다.

절차는 스킬로 만듭니다.

<!-- .claude/skills/release/SKILL.md -->
---
name: release
...

반면, "절대로 지켜야 할 것"은 프롬프트나 스킬의 지시가 아니라, 훅(Hook)으로 강제합니다. 지시는 잊힐 수 있지만, 훅은 코드이므로 반드시 실행되기 때문입니다.

#!/bin/bash
# .claude/hooks/guard.sh (PreToolUse 훅. Bash 실행 전에 매번 호출됨)
input=$(cat)
...

이렇게 하면 이후에는 매번 프롬프트로 다시 설명할 필요가 없어집니다. 판단 로직이 리포지토리(Repository)에 커밋되므로, 세션이 바뀌어도, 모델이 바뀌어도 동일한 품질로 동작한다는 것이 핵심입니다.

단계 4: 루프(Loop)에 태우고, 예외만 수동으로 확인하기

고정된 하네스 위에서 루프를 돌립니다.

> /loop 10m 미공개 기사 리뷰 지적이 남아 있으면 /release 절차로 대응해줘

이 단계에 도달하면, 루프는 단순한 "가벼운 커맨드(Command)"가 아니라 "단단한 발판 위를 달리는 신뢰할 수 있는 자동화"가 됩니다. 위험한 조작은 권한(Permission)과 훅으로 차단되고, 절차는 스킬로 고정되며, 검증은 기계적으로 실행됩니다. 인간의 업무는 전체 공정의 감시에서 예외 대응만 하는 것으로 축소됩니다.

이 리포지토리에서도 동일한 사고방식을 그대로 적용할 수 있습니다. 기사 작성, 리뷰, 릴리스와 같은 반복 작업을 스킬로 고정하고, 금지 사항을 훅으로 강제합니다. 처음에는 손으로 직접 하는 투박한 작업을 반복하면서 하네스로 옮겨가는 순서입니다.

보충: 기성 스킬도 "층(Layer)"으로 구분하기

스킬은 처음부터 직접 작성하지 않아도, 커뮤니티에 재사용 가능한 것들이 많이 공개되어 있습니다. 다만 같은 "스킬" 형태를 띠고 있더라도, 어떤 층을 겨냥한 도구인지는 제각각입니다. 자주 언급되는 두 가지를 비교해 보면 그 차이가 명확해집니다.

superpowers는 도입하는 순간부터 타인이 만들어 놓은 레일 위를 달릴 수 있는 "기성 발판 세트"입니다. 그야말로 양산 측면을 두텁게 쌓는 하네스의 전형이며, GitHub에서도 압도적인 스타 수를 기록할 정도로 정착되어 있습니다.

grill-me는 대조적으로, 같은 스킬의 형태를 취하면서도 목표는 상류(Upstream)에 있습니다. "아직 형태가 잡히지 않은 태스크를 탐색하는" 단계에서 요구사항을 구체화하기 위해 사용하는 도구입니다. 본문에서 말하는 "힘으로 탐색하는" 페이즈를 그대로 모델링한 것이라고 할 수 있습니다.

즉, 스킬이라는 형태는 같아도 작용하는 층은 다릅니다. 양산을 공고히 하는 스킬이 있는가 하면, 탐색을 돕는 스킬도 있습니다. 단순히 "스킬이니까 하네스파"라고 단정 지을 수는 없습니다.

어디에서 선을 그을 것인가에 대한 판단 기준

"언제 시스템화해야 하는가"는 현장에서 가장 고민되는 지점입니다. 제가 사용하는 기준을 몇 가지 제시하겠습니다.

• 동일한 판단을 3회 반복했다면 하네스(Harness)화를 검토한다. 1~2회라면 우연일 수 있지만, 3회 연속된다면 훌륭한 패턴입니다.
• 검증을 기계적으로 작성할 수 있다면, 망설임 없이 메커니즘에 심는다. 테스트(Test), 린트(Lint), 타입 체크(Type Check)와 같은 결정론적인(Deterministic) 체크는 LLM의 판단보다 하네스(Harness) 측에 먼저 배치할수록 효과적입니다.
• 형태가 아직 보이지 않는 것은 무리하게 시스템화하지 않는다. 탐색 비용이 높은 태스크까지 너무 이른 추상화(Abstraction)를 시도하면, 잘못된 레일(Rail)을 계속 유지보수해야 하는 상황에 빠지게 됩니다.
• 되돌릴 수 없는 조작은 루프(Loop)에 태우기 전에 반드시 게이트(Gate)를 설치한다. 프로덕션(Production)으로의 푸시(Push)나 리소스 삭제와 같은 조작은, 힘으로 자율 주행시키기 전에 후크(Hook)나 권한(Permission)으로 막아둡니다.

시그널별로 어느 계층에 둘지를 정리하면 다음과 같습니다.

요컨대, 반복성과 검증 가능성이 높을수록 하네스(Harness) 쪽으로, 불확실성이 높을수록 커맨드(Command) 쪽으로 기울이는 것뿐입니다.

자주 저지르는 안티 패턴 (Anti-pattern)

양극단으로 치우치면 각각 전형적인 실패가 기다리고 있습니다.

커맨드파의 함정: 「검증 없는 자율 주행」

목표만 주고 검증을 생략하면, 에이전트(Agent)는 잘못된 방향으로 끝없이 달려 나갑니다.

# NG: 종료 조건이 LLM의 자기 보고뿐임
while :; do
claude -p "리팩터링을 진행해줘. 끝났다고 생각되면 알려줘."
...

loop는 강력하지만, 「무엇을 성공으로 간주할 것인가」를 기계적으로 판정할 수 있는 메커니즘이 없으면, 그저 토큰과 시간만 낭비하는 장치가 됩니다. 자율 주행을 시키려면, until npm test와 같은 결정론적인 종료 조건을 반드시 세트로 구성해야 합니다.

하네스파의 함정: 「너무 이른 시스템화」

아직 한 번밖에 수행하지 않은 태스크를 갑자기 거창한 스킬(Skill)이나 후크(Hook)로 만들어 버리는 실수입니다. 정답의 형태를 모르는 채 깔아놓은 레일은 대개 현실과 맞지 않아, 결국 다시 작성하게 됩니다. 시스템화는 성공 패턴을 최소 몇 회 관측한 후에 해도 충분합니다.

공통의 함정: 「계층을 혼동함」

하네스(Harness)로 풀어야 할 문제를 커맨드(Command)로 힘으로 밀어붙이거나, 반대로 커맨드로 빠르게 시도해야 할 탐색을 처음부터 메커니즘에 밀어 넣는 경우입니다. 전형적인 예로, 프롬프트(Prompt)에서 매번 "force push 하지 마"라고 계속 강조하는 것이 있습니다. 그것은 후크(Hook, 하네스 계층)의 일이지, 프롬프트(Loop 계층)의 일이 아닙니다. 문제가 어느 계층의 것인지 오판하면 두 도구 모두 헛돌게 됩니다. 우선 "이것이 환경의 문제인가, 구동의 문제인가"를 파악하는 것이 먼저입니다.

키 퍼슨(Key Person)들의 말

이 "손으로 프롬프트를 쓰는 시대"에서 "루프를 설계하는 시대"로의 이행은, 최전선 개발자들의 말에서도 명확히 나타납니다.

Claude Code의 창시자인 엔지니어는 이렇게 말합니다.

이제 나는 Claude에게 프롬프트를 입력하지 않는다. Claude에게 프롬프트를 입력하고, 다음에 무엇을 해야 할지 생각하는 루프를 돌리고 있다. 나의 일은 루프를 작성하는 것이다.

이 엔지니어는 바쁜 날에는 수만 대 규모의 에이전트를 동시에 구동하고 있다고 알려져 있습니다. 이는 바로 "개별 프롬프트"에서 "루프 설계"로 업무의 무게 중심이 옮겨갔음을 보여주는 상징이라 할 수 있습니다.

코딩 에이전트 개발의 최전선에 있는 또 다른 저명한 엔지니어도 비슷한 취지의 말을 했습니다.

이제 코딩 에이전트에 프롬프트를 입력해서는 안 된다. 에이전트를 촉진하는 루프를 설계해야 한다.

그리고 이러한 발언들을 「루프 엔지니어링 (Loop Engineering)」이라는 용어로 체계화하여 퍼뜨린 인물은, 어느 대형 테크 기업의 클라우드 AI 부문 디렉터로 재직 중인 인물입니다. 이 인물은 루프를 구동하기 위한 구성 요소로 다음을 꼽았습니다.

• 스케줄링되어 실행되는 자동화
• 병렬 작업을 위한 worktree
• 프로젝트 지식을 기록하는 스킬
• 기존 도구와 연결하는 플러그인·커넥터
• 상호 체크를 위한 서브 에이전트 (Sub-agent)
• 그것들의 상태를 대화 외부에 유지하는 기억 (Markdown 파일 등)

여기서 주목해야 할 점은, 그들이 말하는 「루프」가 결코 가벼운 커맨드 한 줄의 이야기가 아니라는 것입니다. 스킬, 서브 에이전트, 영속적인 기억과 같은 발판(즉, 하네스)을 전제로 해야 비로소 루프는 안심하고 돌릴 수 있는 것이 됩니다. 최전선의 운용은 결국 힘(Brute force)과 하네스(Harness)의 하이브리드로 수렴하고 있습니다.

요약

"당신은 하네스(Harness)파인가요, 커맨드(Command)파인가요?"라는 질문에 저는 다음과 같이 답하겠습니다.

• 양자는 대립하는 종파가 아니라, **동일한 워크플로우의 서로 다른 레이어(Layer)**입니다.
• 기본은 **"힘(Brute force)으로 탐색하고, 하네스(Harness)로 양산한다"**는 순서입니다.
• 구분 기준은 **"동일한 판단을 3번 반복하면 하네스(Harness)를 도입한다"**입니다.

어느 한쪽에만 매몰될 필요는 없습니다. 태스크의 불확실성과 반복성을 살피며 두 계층을 오가는 것, 그것이 에이전트 시대의 현실적인 운용 방식이라고 생각합니다.

참고 기사 및 데이터

• 2025 Was Agents. 2026 Is Agent Harnesses. (Aakash Gupta, Medium)

• Loop Engineering Explained: How to Build Self-Running AI Coding Agents (Codersarts)

• What Is Loop Engineering? Beyond Prompt Engineering in 2026 (explainx.ai)

• Loop Engineering, designing systems that prompt your coding agents (i-scoop)

• Loop Engineering, Addy Osmani (Substack / Elevate)

• What Is an Agent Harness? The Architecture Behind Claude Code, Codex, and Cursor (MindStudio)

• How Claude Code works (Claude Code Docs)

• Claude Code settings (Claude Code Docs)

• Hooks reference (Claude Code Docs)

• Anthropic's Claude Code creator says there are days he manages tens of thousands of AI agents at once (Fortune)

• Who is OpenClaw creator Peter Steinberger? (Fortune)

• Peter Steinberger (programmer), Wikipedia

• Addy Osmani, Director, Google Cloud AI (LinkedIn 프로필)

• superpowers (GitHub: obra/superpowers)

• grill-me를 포함한 스킬 모음 (GitHub: mattpocock/skills)

Discussion