TRENDSHIFT #24 · 2026.05.24 · WALKINGLABS

Learn Harness Engineering — Codex·Claude Code를
"제대로 끝까지" 일하게 만드는
환경 공학 수업

28 스타짜리 신생 코스가 트렌딩 24위에 진입한 이유. OpenAI "Harness Engineering" 블로그와 Anthropic "Effective Harnesses for Long-Running Agents"를 종합해 만든 12강 + 6 프로젝트 커리큘럼. 핵심 주장: 모델이 강해도 환경이 엉터리면 끝까지 못 간다. 같은 Opus 4.5에 "2D 레트로 게임 에디터 만들어"를 시켰을 때, harness 없으면 20분 $9에 안 돌아가는 결과, harness 있으면 6시간 $200에 진짜 플레이되는 게임을 만든다. 모델은 그대로다 — harness만 바뀌었다. 13개 언어로 번역된 한국어 자료도 있다.

12강 + 6프로젝트
L01~L12 강의 · P01~P06 캡스톤 빌드업
13개 언어
EN/中/日/한국어/ES/FR/RU/DE/AR/VI/UZ/TR
TS 92.8%
+ Shell 4.3% + JS 1.5% + HTML 1.4%
MIT · 19 commits
28 stars · walkinglabs · VitePress 문서

0먼저, 이게 도대체 뭘 가르치는 코스인가

"프롬프트 잘 쓰는 법"이 아니라 "AI 에이전트가 살아 일하는 환경을 짓는 법"을 가르치는 수업.

대부분의 "AI 코딩" 콘텐츠는 두 갈래다. ① 프롬프트 잘 쓰기 — "이런 식으로 시키면 결과가 좋아진다", ② 에이전트 내부 구조 — "ReAct, Tool-use, Agent loop, MCP가 어떻게 작동하는가". learn-harness-engineering완전히 다른 세 번째 갈래를 판다.

이 코스의 주장은 명료하다. Codex·Claude Code 같은 코딩 에이전트는 모델 자체보다 "에이전트를 둘러싼 작업 환경"이 결과를 더 크게 좌우한다. 같은 모델이 어떤 레포에서는 5분 만에 멋대로 망쳐 놓고, 옆 레포에서는 6시간 동안 차분히 한 기능씩 끝낸다. 차이는 모델이 아니라 그 레포 안에 깔린 "harness"다.

용어
Harness (하니스)
원래 말이나 소를 마차에 매는 "마구"라는 뜻. AI 업계에서는 모델 자체와 분리된, 모델을 일하게 만드는 외부 장치 전체를 가리킨다. 명령서(AGENTS.md), 진행 로그(progress.md), 검증 스크립트(test+lint), 기능 목록(feature_list.json), 세션 초기화 스크립트(init.sh) 등이 모두 harness의 일부. 모델을 "더 똑똑하게" 만드는 게 아니라, 모델의 출력을 "끝까지 믿을 만하게" 만드는 게 harness의 일.
비유

F1 드라이버를 떠올려 보자. 같은 드라이버를 평범한 도로용 세단에 태우면 사고만 친다. 그 드라이버에게 필요한 건 더 좋은 운전 실력이 아니라 — F1 머신, 피트 크루, 무전 시스템, 코스 가드레일이다. 모델은 드라이버, harness는 차+크루+가드레일. 코스에서는 "드라이버를 어떻게 키우나"가 아니라 "어떤 머신·크루·가드레일을 짜야 드라이버가 끝까지 완주하나"를 가르친다.

왜 지금 이 주제가 갑자기 뜨는가

2025년 4분기~2026년 1분기 사이, OpenAI("Harness engineering: leveraging Codex in an agent-first world")와 Anthropic("Effective harnesses for long-running agents" 2025-11, "Harness design for long-running application development" 2026-03) 두 곳이 같은 메시지의 엔지니어링 블로그를 냈다. Cursor, LangChain, Thoughtworks(Martin Fowler) 도 곧이어 자신들의 harness 글을 올렸다. 업계가 "모델은 충분히 똑똑하다, 문제는 환경"으로 합의한 것이다. 그 합의를 가장 빨리 정리해 코스로 만든 게 이 레포다.

1왜 트렌딩에 진입했는가

28 스타짜리 신생 레포가 1만 스타 이상의 거대 프로젝트들과 어깨 나란히 한 이유.

① "스타 수"가 아니라 "급격한 모멘텀"을 잡는 트렌딩 알고리즘

Trendshift는 GitHub Trending과 달리 절대 스타 수가 아니라 24시간/주 단위의 멘션·스타 증가율을 본다. 28 스타지만 그게 며칠 사이에 모인 거라면 1만 스타 레포보다 더 위에 뜬다. Anthropic·OpenAI 공식 블로그가 동시에 화제가 된 직후 등장했고, 트위터·해커뉴스에서 "이 두 글을 코스로 정리해 둔 레포"로 입소문이 났다.

② "이론 → 손으로 짜는 프로젝트" 구조

강의(L01~L12)는 개념을, 프로젝트(P01~P06)는 같은 Electron 지식 베이스 앱을 6단계에 걸쳐 점점 더 진짜 harness 위로 옮긴다. 매 프로젝트의 결과물이 다음 프로젝트의 시작점이 된다. "읽기만 해도 되는 책"이 아니라 "매 챕터마다 같은 앱이 더 잘 작동하도록 코드를 짜는 코스"다.

③ "복붙 가능한 4파일 미니멈"이라는 미끼

12강을 다 안 읽어도 README의 "Quick Start" 한 섹션만 보고 AGENTS.md + init.sh + feature_list.json + claude-progress.md 4개를 내 레포에 떨궈도 효과가 즉시 보인다. 이 "오늘 당장 써먹을 수 있는 최소 구성" 미끼가 트래픽 진입점이 된다.

④ 13개 언어 — 한국어 포함

대부분의 신생 영문 코스가 못 따라가는 게 i18n인데, 이 레포는 처음부터 한국어·중국어(간/번)·일본어·스페인어·프랑스어·러시아어·독일어·아랍어·베트남어·우즈벡어·튀르키예어까지 번역본을 깔고 시작했다. 한국·중국·일본 개발자 트위터에서 빠르게 공유된 이유.

경쟁 프로젝트 대비 자리

비교 대상주력이 레포의 차이
obra/superpowersClaude Code 스킬 모음"바로 쓸 스킬" vs "왜·어떻게 환경을 짜야 하나"의 이론+실습
hesreallyhim/awesome-claude-code큐레이션 링크 리스트리스트가 아니라 12강짜리 강의식 커리큘럼
shareAI-lab/learn-claude-codeClaude Code 자체 사용법"클로드 코드 쓰는 법"이 아니라 "어떤 코딩 에이전트에서도 통하는 환경 설계 원리"
OpenAI / Anthropic 공식 블로그1편짜리 사례 글흩어진 사례들을 12강 + Electron 캡스톤으로 묶음

2"Harness"의 5개 서브시스템 — 코스의 뼈대

강의 L02가 정의하는 5개 부품. 이게 코스 전체의 어휘이자 측정 단위다.

코스 전체에서 가장 중요한 한 장이 L02다. 여기서 정의한 5개 서브시스템을 가지고 나머지 11강과 6 프로젝트가 돌아간다.

┌──────────────────────────────────────────────────────────────┐ │ THE HARNESS │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌─────────────────────┐ │ │ │ Instructions │ │ State │ │ Verification │ │ │ │ │ │ │ │ │ │ │ │ AGENTS.md │ │ progress.md │ │ tests + lint │ │ │ │ CLAUDE.md │ │ feature_list │ │ type-check │ │ │ │ feature_list │ │ git log │ │ smoke runs │ │ │ │ docs/ │ │ session hand │ │ e2e pipeline │ │ │ └──────────────┘ └──────────────┘ └─────────────────────┘ │ │ │ │ ┌──────────────┐ ┌────────────────────────────────────┐ │ │ │ Scope │ │ Session Lifecycle │ │ │ │ │ │ │ │ │ │ one feature │ │ init.sh at start │ │ │ │ at a time │ │ clean-state checklist at end │ │ │ │ definition │ │ handoff note for next session │ │ │ │ of done │ │ commit only when safe to resume │ │ │ └──────────────┘ └────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────┘ 모델 = 어떤 코드를 쓸지 결정한다 Harness = 언제·어디서·어떻게 쓸지를 통제한다

① Instructions — 명령서

"무엇을, 어떤 순서로, 시작 전 무엇을 읽어야 하는지"를 알려주는 파일들. 핵심 원칙은 한 거대한 파일이 아니라, 에이전트가 필요할 때 골라 읽을 수 있는 작은 파일들의 트리로 쪼개는 것. L04가 이 원칙을 다룬다.

용어
Progressive Disclosure (점진적 공개)
한 번에 모든 걸 다 던지지 말고, 필요한 순간에 필요한 정보만 노출하는 설계 패턴. UI에서 처음 가져온 개념인데 LLM 명령서 설계에도 그대로 적용된다. 100KB짜리 CLAUDE.md를 던지면 모델이 다 못 읽고 핵심을 놓치지만, "지도(목차)" + "필요할 때 펼치는 작은 문서들"로 나누면 에이전트가 그때그때 골라 읽는다.

② State — 상태 저장소

이번 세션에서 무엇이 됐고, 무엇이 안 됐고, 다음에 뭘 해야 하는지를 디스크에 적어 두는 파일들. 컨텍스트 윈도우는 휘발성이지만 디스크는 영속적이다. 다음 세션의 첫 줄이 "이 파일들을 다시 읽어라"가 되는 순간, 에이전트가 며칠 전 작업을 이어 받는다. L05·L06이 이 부분.

③ Verification — 검증

"내가 다 했어요"라는 에이전트의 말을 그대로 믿지 않는 장치. 테스트·린트·타입체크·스모크 실행이 통과해야만 "끝났다"고 인정. L09는 "에이전트가 너무 일찍 끝났다고 선언하는" 문제를 다룬다.

비유

학생이 "공부 다 했어요"라고 말한다고 부모가 그대로 믿어 주지 않는다. 모의고사 점수를 봐야 한다. 모델도 똑같다 — "구현 끝났다"는 자기 평가는 자신감일 뿐, 정답이 아니다. 통과한 테스트만이 증거다.

④ Scope — 작업 범위 제한

에이전트가 한 번에 한 기능만 잡게 가두는 장치. feature_list.json에 "지금 작업 가능한 기능"을 못박아 두면, 에이전트가 갑자기 옆 폴더까지 리팩토링하거나 3개를 반쯤 하다 도망가는 걸 막을 수 있다. L07·L08이 이 부분.

⑤ Session Lifecycle — 세션 라이프사이클

세션 시작 시 init.sh로 환경을 점검하고, 끝날 때는 clean-state-checklist로 정리한 다음, 다음 세션이 이어받을 수 있게 핸드오프 노트를 남기고 git commit. "세션은 자유분방한 작업이 아니라, 정해진 라이프사이클을 따른다"가 L12의 메시지.

3오늘 당장 써먹는 4파일 미니멈 — Quick Start 해부

12강을 다 듣지 않아도, 이 4개 파일을 내 레포에 떨구는 것만으로 세션 안정성이 즉시 올라간다.

YOUR PROJECT ROOT ├── AGENTS.md ← 에이전트의 운영 매뉴얼 ├── CLAUDE.md ← (Claude Code 전용이면 대신 사용) ├── init.sh ← 의존성 설치 + 검증 + 시작을 한 방에 ├── feature_list.json ← 어떤 기능이 있고, 어디까지 했는지 ├── claude-progress.md ← 매 세션 무슨 일이 있었나 └── src/ ← 실제 코드

파일별 역할

① AGENTS.md / CLAUDE.md

에이전트가 시작 전에 반드시 읽는 한 장짜리 헌법

이 레포의 명령 규칙·금지 사항·세션 시작 시 해야 할 것·끝낼 때 해야 할 것을 적은 파일. 단, 100KB짜리 위키가 되어선 안 된다. "이 파일은 지도다, 자세한 건 docs/ 아래에서 골라 읽어라" 식으로 점진적 공개를 의도해야 한다.

② init.sh

세션 시작 직후 자동 실행되는 헬스 체크 + 부팅

의존성 설치(INSTALL_CMD) → 검증(VERIFY_CMD) → 시작(START_CMD)을 차례로 돌린다. 검증이 깨져 있으면 "환경이 망가져 있으니 작업하지 마라"를 에이전트가 즉시 알게 된다. L06이 "초기화가 별도 단계여야 하는 이유"를 다룬다.

③ feature_list.json

기계가 읽는 기능 목록 — 작업 범위의 경계선

각 기능에 status(todo/in_progress/done), verification(어떻게 검증할지), evidence(검증 통과 증거)를 박아둔다. 에이전트는 이 파일을 보고 딱 하나의 미완료 기능을 골라 작업한다. "이번 한 시간 동안 너는 이 1개만 한다, 끝나면 status를 done으로 바꿔라"가 가능해진다.

④ claude-progress.md

세션 간 기억을 디스크에 적어두는 일기장

매 세션 끝에 "오늘 뭘 했고, 무엇이 검증됐고, 무엇이 깨져 있는지"를 적는다. 다음 세션이 시작할 때 가장 먼저 이 파일을 읽으면, 며칠 전의 작업을 정확히 이어 받는다. 컨텍스트 윈도우가 비어도 디스크는 안 빈다가 핵심.

이게 왜 효과가 있는가

WITHOUT HARNESS WITH HARNESS =============== ============ 세션 1: 에이전트가 코드 쓴다 세션 1: 에이전트가 명령서 읽음 테스트 깨진다 init.sh 돌림 "다 했어요" 선언 기능 1개만 작업 사람이 손으로 수정 검증 통과 후에만 "끝" progress 기록 세션 2: 에이전트 기억 리셋 세션 2: progress 다시 읽음 같은 작업 다시 함 어제 작업 이어 받음 또는 엉뚱한 곳 건드림 다음 기능으로 자연스럽게 또 손으로 수정 넘어감 결과: 사람이 더 많이 일한다 결과: 에이전트가 일한다, 사람은 검토만 한다

412강 커리큘럼 한눈에 — 무엇을 가르치나

강의는 "왜 모델이 실패하나?" 질문 12개를, 프로젝트는 같은 Electron 앱을 6단계로 진화시킨다.

강의 — 12개의 "왜?" 질문

강의핵심 질문핵심 아이디어
L01왜 강한 모델이 진짜 작업에선 실패하나?벤치마크와 진짜 엔지니어링 사이의 능력 갭
L02"Harness"는 도대체 뭔가?5개 서브시스템 — 명령·상태·검증·범위·라이프사이클
L03왜 레포가 유일한 진실의 원천이어야 하나?에이전트가 볼 수 없는 건 존재하지 않는다
L04왜 하나의 거대한 명령 파일은 실패하나?점진적 공개 — 백과사전이 아니라 지도
L05왜 긴 작업에서 연속성이 끊기나?진행 상황을 디스크에 영속화하라
L06왜 초기화가 별도 단계여야 하나?작업 전 환경 헬스 체크
L07왜 에이전트는 넘치게 하고 모자라게 끝내나?한 번에 한 기능 + 명시적 "끝의 정의"
L08왜 feature list가 하니스의 원시 구성요소인가?기계가 읽는 범위 경계 — 에이전트가 무시 못함
L09왜 에이전트는 너무 일찍 "끝!"이라 하나?검증 갭 — 자신감 ≠ 정확함
L10왜 E2E 테스트가 결과를 바꾸나?전체 파이프라인 통과만이 진짜 검증
L11왜 관측성이 harness 안에 있어야 하나?못 본 것은 못 고친다
L12왜 모든 세션은 깨끗한 상태로 끝나야 하나?다음 세션의 성공은 이번 세션의 정리에 달려 있다

프로젝트 — Electron 지식 베이스 앱을 6단계로 진화

프로젝트하는 일도입 메커니즘
P01같은 작업을 프롬프트만 vs 규칙 우선, 둘 다 돌려보고 비교최소 하니스 (AGENTS.md + init.sh + feature_list.json)
P02에이전트가 읽을 수 있게 레포 재구조화agent-readable workspace + 영속 상태 파일
P03에이전트가 이전 세션 이어받게 만들기progress 로그 + 세션 핸드오프
P04에이전트가 넘치거나 모자라지 않게 막기런타임 피드백 + 범위 통제 + 증분 인덱싱
P05에이전트가 자기 작업을 스스로 검증하게 만들기self-verification + grounded Q&A + 증거 기반 완료
P06밑바닥부터 완전한 harness 짓기 (캡스톤)풀 하니스 + 관측성 + 어블레이션 스터디

핵심 미덕은 P(N+1)의 시작점이 P(N)의 결과물이라는 것. 그래서 같은 앱이 1개의 문서도 없던 P01에서 풀 하니스가 깔린 P06까지 점진적으로 진화한다.

5캡스톤: Electron 지식 베이스 앱

왜 굳이 Electron 데스크탑 앱을 캡스톤으로 골랐는가.

┌───────────────────────────────────────────────────┐ │ Knowledge Base Desktop App │ │ │ │ ┌──────────────┐ ┌──────────────────────────┐ │ │ │ Document List│ │ Q&A Panel │ │ │ │ │ │ │ │ │ │ doc-001.md │ │ Q: Harness가 뭔가요? │ │ │ │ doc-002.md │ │ A: 에이전트 모델 주변에 │ │ │ │ doc-003.md │ │ 깔린 환경 전체... │ │ │ │ ... │ │ [출처: doc-002.md] │ │ │ └──────────────┘ └──────────────────────────┘ │ │ │ │ ┌────────────────────────────────────────────┐ │ │ │ Status: 42 docs | 38 indexed | 동기화 3분전│ │ │ └────────────────────────────────────────────┘ │ └───────────────────────────────────────────────────┘ 핵심 기능: ├── 로컬 문서 import ├── 문서 라이브러리 관리 ├── 문서 처리 + 인덱싱 ├── AI 기반 Q&A └── 출처가 박힌 답변 반환

왜 굳이 Electron? 코스가 의도적으로 고른 이유는 "실제 제품 같은 복잡성"이다. 메인 프로세스 / 렌더러 프로세스 분리, IPC, 파일 시스템 권한, 패키징 빌드 등 — 단일 파일 스크립트로는 안 잡히는 복잡한 다층 구조를 가진 앱. 이 정도 복잡도가 있어야 "harness 있을 때 / 없을 때" 차이가 진짜로 드러난다.

잘 만든 장치
starter / solution 페어 구조

각 프로젝트 폴더는 starter/(작업 시작 시점의 코드)와 solution/(완료 시점의 코드)을 모두 가진다. 진도가 막히면 solution을 보면 되고, 다음 프로젝트는 이 solution을 시작점으로 받는다. "내 진도가 코스 의도와 어긋났는지"를 매 단계 자가 진단할 수 있다.

6기술 스택 전체 지도

코스 사이트 + 캡스톤 앱이 어떤 기술로 짜였는지.

① 코스 사이트 (문서)

레이어기술역할
SSG 엔진VitePressVite + Vue 기반 정적 사이트 생성기. docs/ 안의 마크다운을 페이지로 뽑는다
호스팅GitHub Pageswalkinglabs.github.io/learn-harness-engineering/
i18nVitePress localesdocs/en/, docs/zh/, docs/ko/ ... 13개 디렉토리
PDF 빌드npm 스크립트 + Actionsnpm run pdf:buildartifacts/pdfs/ → Releases 자동 업로드
스크린샷screenshots:readmeREADME 미리보기 이미지 자동 재생성

② 캡스톤 앱 (Electron 지식 베이스)

레이어기술왜 이 조합인가
데스크탑 셸ElectronMac·Windows·Linux 멀티플랫폼 + 파일시스템 접근 + 로컬 LLM 가능
UIReact + TypeScript현대 프론트엔드 표준 — 학생이 이미 알 가능성 높음
빌드Vite (추정)VitePress와 같은 생태계, 핫리로드 빠름
인덱싱로컬 임베딩 + RAG (프로젝트별)P04에서 증분 인덱싱이 등장
Q&A로컬 목(mock) 키워드 매칭 (shared 기준)공통 스타터에는 mock Q&A; P04~P05에서 학생이 실제 LLM API로 교체하는 것이 학습 목표

③ Harness 도구 자체

파일포맷역할
AGENTS.md / CLAUDE.mdMarkdown에이전트의 운영 매뉴얼
init.shShell (Bash)install + verify + start, 1회용 부팅 스크립트
feature_list.jsonJSON기계 가독 작업 범위, status/verification/evidence
claude-progress.mdMarkdown세션 간 핸드오프 일기
session-handoff.mdMarkdown축약형 세션 종료 노트 — 다음 세션 첫 줄에 읽힘
clean-state-checklist.mdMarkdown세션 끝나기 전 체크박스 리스트 (커밋 안전한가?)
evaluator-rubric.mdMarkdown에이전트 작업물 채점 루브릭

주목할 점: harness 자체는 새 프로그래밍 언어도, 새 라이브러리도 아니다. 그냥 잘 정의된 약속의 마크다운/JSON/셸 스크립트 묶음이다. 이 단순함이 의도된 것 — 어떤 코딩 에이전트(Claude Code, Codex, Cursor, Aider, Roo Code…)에서도 그대로 동작한다.

7디렉토리 구조 해부

레포를 클론하면 만나는 파일들이 각각 무슨 역할인지.

learn-harness-engineering/ ├── docs/ ← VitePress 문서 사이트 본체 │ ├── en/ ← 영어 (언어 디렉토리 중 하나) │ │ ├── lectures/ ← 12개 강의 │ │ │ ├── lecture-01-why-capable-agents-still-fail/ │ │ │ │ ├── index.md ← 본문 │ │ │ │ └── code/ ← 강의 안에서 보여주는 예시 코드 │ │ │ ├── lecture-02-what-a-harness-actually-is/ │ │ │ └── ... (12개) │ │ ├── projects/ ← 6개 프로젝트 설명서 │ │ │ ├── project-01-baseline-vs-minimal-harness/ │ │ │ └── ... (6개) │ │ └── resources/ ← 다국어 템플릿 + 참고문헌 │ │ └── templates/ ← AGENTS.md, init.sh, feature_list.json... │ ├── ko/ ← 한국어 (언어 디렉토리) │ │ └── resources/templates/ ← 한국어 템플릿 │ ├── zh/ ← 중국어 등 나머지 13개 언어 디렉토리 │ └── public/screenshots/ ← README 미리보기 이미지 ├── projects/ │ ├── shared/ ← Electron + TS + React 공통 토대 │ └── project-NN/ ← 프로젝트별 starter/ + solution/ │ ├── starter/ ← 시작 코드 │ └── solution/ ← 완성 코드 ├── skills/ │ └── harness-creator/ ← 재사용 가능한 Claude Code 스킬 │ (내 레포에 harness를 자동으로 깔아주는 도구) ├── docs-readme/ ← README의 13개 언어 번역 │ ├── ko-KR/README.md ← 한국어 README │ └── ... ├── .github/workflows/ ← GitHub Actions │ └── release-course-pdfs.yml ← PDF 빌드 + Releases 자동 게시 ├── package.json ← VitePress + 빌드 스크립트 └── CLAUDE.md ← 이 레포 자체의 Claude Code 운영 매뉴얼 (메타: harness 코스가 자기 자신을 harness로 운영)
메타 관찰

이 레포의 루트에 CLAUDE.md가 있다. 즉 "harness 코스를 짜는 작업 자체도 harness로 운영된다". 이건 "스스로 짜는 컴파일러"처럼 일종의 자기 적용(self-application). 메인테이너 본인이 자기가 가르치는 방법으로 자기 코스를 만들었다는 신호 — 신뢰도 있는 코스의 흔한 마크.

8학습 포인트 — 기술별로 무엇을 배울 수 있나

이 레포를 한 번 훑으면 인범님이 얻게 되는 구체적인 역량들.

① 에이전트 환경 설계 자체

② Claude Code / Codex 실전 운영

③ Electron 데스크탑 앱 풀스택

④ DevOps / 자동화

실습 아이디어 (코스를 다 안 보고도 즉시 적용 가능)

바로 해보기
현재 진행 중인 한 프로젝트에 4파일만 깔아보기

한성크린텍 업무 자동화 스크립트든 작업일보 앱이든, 손에 잡히는 레포 한 곳을 정해서 AGENTS.md + init.sh + feature_list.json + claude-progress.md 4개를 1시간 만에 깔아 보고, 다음 주 1주일 동안 Claude Code 세션을 그 위에서 돌려본다. 1주일 후 "수정 횟수"가 얼마나 줄었는지를 직접 측정해 본다.

9하드웨어 / 시스템 요구사항

코스를 따라가려면 무엇이 필요한가.

항목요구비고
OSmacOS / Linux / WindowsElectron이 동작하는 모든 OS
Node.js최신 LTS (v20+ 권장)VitePress + Electron 빌드용
npm10+npm install 시점에 확인
코딩 에이전트Claude Code · Codex · 유사 IDE/CLI 중 최소 하나파일 편집 + 명령 실행 + 멀티스텝 작업 가능해야
LLM APIOpenAI · Anthropic · Gemini 중 하나의 API 키캡스톤 Q&A 동작용
디스크~2GBnode_modules + Electron 바이너리
RAM8GB+ 권장VitePress dev + Electron + IDE 동시 사용
네트워크안정적인 인터넷npm 설치 + LLM API 호출

비싼 GPU도, 로컬 LLM도 필요 없다 — 코스의 초점은 "모델 자체"가 아니라 "모델 주변 환경"이기 때문이다. 노트북 한 대면 끝까지 갈 수 있다.

10직접 해볼 수 있는 실습 과제 — 난이도별

코스 자체와 별개로 인범님이 손에 잡힐 만한 과제 5개.

난이도 ★ — 1시간

가장 만만한 내 레포 하나에 AGENTS.md 깔기

현재 다루고 있는 작은 레포 하나에 docs/en/resources/templates/AGENTS.md 템플릿을 복사해 떨궈본다. 거기 적힌 INSTALL_CMD·VERIFY_CMD·START_CMD 세 자리만 내 프로젝트에 맞게 바꾼다. 그날 저녁 Claude Code 세션이 어떻게 달라지는지 관찰. 한 줄 평을 메모리에 남기기.

난이도 ★★ — 반나절

스마트작업일보 앱에 feature_list.json 도입

smart-work-report-20251226 같은 진짜 일하는 앱에 feature_list.json을 짜본다. "WIR_JOINTS 조회 탭", "FMCS 엑셀 생성", "출역 동기화" 등을 항목으로 분해하고 각각의 verification(어떻게 됐다고 판단할지)을 적는다. 이 작업 자체가 "내 프로젝트의 정의를 다시 보는 일"이 된다.

난이도 ★★★ — 주말 1박 2일

P01 따라하기 — 같은 작업을 프롬프트 vs 하니스로 비교

projects/project-01-baseline-vs-minimal-harness/starter/를 클론해서 같은 기능을 두 번 짠다 — 첫 번째는 그냥 프롬프트로, 두 번째는 4파일 하니스를 깔고. 끝난 후 각각 ① 사람이 손댄 횟수, ② 테스트 통과 비율, ③ 소요 시간을 표로 비교한다. 이 차이를 본 사람과 안 본 사람은 다른 멘탈 모델을 가진다.

난이도 ★★★★ — 1주일

P03·P05 따라하기 — 다세션 연속성 + 자가 검증

P03을 따라 "세션 1에서 절반 짜다 일부러 중단 → 세션 2에서 무에서 이어 받기"를 성공시킨다. 그 다음 P05를 따라 에이전트가 자기 결과물을 verification 기록 없이는 "끝났다" 못 외치게 막는 패턴을 구현한다. harness 작동의 두 번째 단계 — 단순한 4파일을 넘어서 "에이전트 행동을 강제하는 구조"로 진입.

난이도 ★★★★★ — 2~3주

내 진짜 업무 자동화에 풀 하니스 이식

daily-reportsup-bom-sync처럼 인범님이 매주 돌리는 스킬 중 하나를 골라, 코스의 6 프로젝트 패턴을 그대로 자기 자신에게 적용한다. P01(비교) → P02(워크스페이스) → P03(연속성) → P04(범위) → P05(자가검증) → P06(관측성)을 한 단계씩. 다 끝나면 이 스킬은 사람이 한 번 시작 명령 내리면 다음 주까지 알아서 돌아간다.

11관련 기술 심화 학습 로드맵 — 주차별

이 코스를 끝낸 후 인범님이 자연스럽게 갈 만한 다음 단계.

1주차 — 코스 본체 따라가기

2주차 — 후반부 + 작은 실전

3주차 — 캡스톤 진입

4주차 — 캡스톤 + 본인 프로젝트로 이식

5주차 이후 — 인접 분야로 확장

12핵심 키워드 사전

코스 안에서 반복적으로 나오는 용어들 — 한 번에 정리.

개념
Harness Engineering
모델 자체가 아니라, 모델을 둘러싼 환경(명령서·상태·검증·범위·라이프사이클)을 설계해 결과를 신뢰할 수 있게 만드는 공학. 2025년 4분기~2026년 1분기 사이 OpenAI/Anthropic이 공식화한 용어.
개념
Agent Loop / Agent Harness
에이전트 루프 = 모델이 도구를 부르고 결과를 받아 다시 추론하는 내부 반복. 에이전트 하니스 = 그 루프를 둘러싸고 "어디까지 가게 둘지·언제 멈출지·뭘 읽고 시작할지"를 통제하는 외부 구조. 코스는 후자에 집중한다.
파일 / 컨벤션
AGENTS.md / CLAUDE.md
에이전트가 세션 시작 시 반드시 읽는 운영 매뉴얼 파일. AGENTS.md는 도구 무관한 일반형, CLAUDE.md는 Claude Code 전용 변형. 둘은 같은 자리에 공존 가능.
파일 / 컨벤션
feature_list.json
기능 단위의 작업 범위 + 검증 방법 + 완료 증거를 기계가 읽을 수 있게 JSON으로 박은 파일. 에이전트가 "이번 세션엔 이 하나만 한다"의 근거가 된다.
파일 / 컨벤션
claude-progress.md
매 세션이 끝날 때 "오늘 무엇이 됐고 무엇이 안 됐는가"를 적는 일기. 다음 세션의 첫 줄에 다시 읽혀, 컨텍스트 윈도우 리셋과 무관하게 작업이 이어진다.
패턴
Progressive Disclosure (점진적 공개)
큰 문서를 한 번에 던지지 말고, 필요한 순간에 필요한 부분만 노출. AGENTS.md를 100KB로 만들지 말고 "지도 + 작은 문서들"로 쪼개는 원칙.
패턴
Definition of Done (DoD)
"이 기능이 끝났다"고 부를 수 있는 조건의 명시. 단순히 "코드가 컴파일됨"이 아니라 "유닛테스트 통과 + 린트 통과 + E2E 시나리오 1번 통과" 같은 명시적 체크리스트.
패턴
Self-verification (자가 검증)
에이전트가 "끝났다" 선언 전에 자기 스스로 검증을 돌리고, 그 결과를 증거로 남기게 강제하는 패턴. L09·P05의 주제.
패턴
Session Handoff
한 세션의 작업이 다음 세션으로 깨끗하게 넘어가도록, 세션이 끝나는 시점에 영속 파일(progress.md, handoff.md)을 정돈하고 git commit으로 안전 지점을 박는 행위.
패턴
Grounded Answers (출처 기반 답변)
캡스톤 Q&A 앱이 만드는 답변의 표준. "AI가 자유 작문한 답"이 아니라 "어떤 문서의 어느 부분에서 가져왔다"가 인용으로 박힌 답변. P05의 검증 대상.
측정
Ablation Study (어블레이션 스터디)
"어떤 부품을 빼면 성능이 얼마나 떨어지나"를 측정하는 실험. P06에서는 하니스의 5개 서브시스템 중 하나씩 빼 가며 결과 차이를 본다. "AGENTS.md 빼면 작업 성공률이 얼마나 떨어지나?" 같은 식으로 자기 환경을 정량적으로 평가하게 된다.
관련 도구
VitePress
Vite + Vue 기반 정적 문서 사이트 생성기. 마크다운 파일들을 빠르게 사이트로 컴파일. npm run docs:dev로 핫리로드 개발 모드, npm run docs:build로 정적 사이트 빌드.

13한 줄 요약 + 실천 제안

코스 전체를 한 문장으로 압축하면.

한 줄 요약

"AI 코딩 에이전트가 끝까지 일하느냐 마느냐는, 모델이 아니라 그 모델을 둘러싼 4~10개 파일이 결정한다."

코스를 다 듣지 않아도, README의 Quick Start에 적힌 4파일(AGENTS.md·init.sh·feature_list.json·claude-progress.md)을 진짜 일하는 레포 한 군데에 떨궈 보면 메시지가 손에 잡힌다. 이게 코스 전체의 "MVP 증명"이고, 그래서 28 스타짜리 신생 레포가 트렌딩 24위에 진입했다.

이번 주 실천 — 3단계

오늘 1시간으로 끝낼 수 있는 가장 작은 실험

  1. 레포 한 군데 고르기 — 자주 작업하지만 자꾸 망가지는 손에 익은 레포 하나. 5min-ai-newssmart-work-report-20251226 같은 거.
  2. 4파일만 떨구기docs/en/resources/templates/에서 4개 템플릿 다운로드 → 내 레포 루트에 복사 → INSTALL_CMD·VERIFY_CMD·START_CMD 자리만 내 프로젝트에 맞게 변경. 끝.
  3. 1주일 관찰 — 평소처럼 Claude Code 세션을 그 레포에서 돌린다. 일주일 후, "내가 손으로 고친 횟수"와 "에이전트가 처음에 잘못 끝낸 횟수"를 평소와 비교한다. 차이가 보이면 P02로 진입.

14참고 링크

코스 본체 + 코스가 인용하는 원본 블로그들.

레포 본체

코스가 인용하는 원본 글들 (필수 읽기)

관련 코스 (같은 팀)

분석 일시: 2026-05-24 · TrendShift Daily 24위 (28 stars · 19 commits · MIT)
분석 대상: walkinglabs/learn-harness-engineering · 작성자 walkinglabs · TS 92.8% + Shell 4.3% + JS 1.5% + HTML 1.4%