코드를 모르는 사람은 하네스를 어떻게 만드는지에 답하는 챕터입니다. 개발자의 도구를 비개발자의 언어로 옮긴 표에서 출발해 지시 파일·규칙 체크리스트·생성-검증 루프·컨텍스트 관리라는 네 요소를 선언하고, 이를 실행할 세 도구의 지형도를 그린 뒤 '코드를 짜는 사람'에서 'AI 팀을 설계하는 사람'으로의 전환을 이야기합니다.
출전
『AI 하네스』 1부 · 챕터 3
시리즈
왜 하네스인가 — AI가 불안정한 이유와 하네스의 개념
구성
3부 8장
차례
PART I번역 — 개발자의 하네스를 비개발자의 언어로
01코드를 모르는 사람은 어떻게 합니까
02개발자의 하네스를 비개발자 언어로 번역하면
PART II선언 — 비개발자 하네스 4요소
03지시 파일 — AI에게 업무 매뉴얼을 줍니다
04규칙 체크리스트 — AI의 행동 범위를 제한합니다
05생성-검증 루프 — AI가 자기 일을 검증하게 합니다
06컨텍스트 관리 — AI가 멍청해지지 않게 합니다
PART III도구와 사람
07비개발자용 하네스 도구 지형도
08"코드를 짜는 사람"에서 "AI 팀을 설계하는 사람"으로
＋정리 체크리스트 · 토론 질문 · 편집자 주 · 사진 출처표
학습 목표
챕터 1의 랭체인 실험이 남긴 "코드를 모르는 사람은 어떻게 하는가"를 이 챕터의 출발점으로 짚기
개발자의 도구 네 가지가 각각 어떤 문제를 푸는지 보고, 비개발자 맥락의 같은 역할과 짝짓기
지시 파일·규칙 체크리스트·생성-검증 루프·컨텍스트 관리 네 요소를 한 줄씩 설명하기
규칙 체크리스트를 입력·출력·행동 규칙 세 갈래로 나누어 내 업무에 맞게 적어 보기
같은 AI가 자기 결과물을 검토하면 왜 편향이 남는지 말하고, 역할을 나누어 루프를 짜기
새 세션에 진행 파일을 첨부하는 이유를 교대 근무 인수인계 비유로 설명하기
클로드 코워크·챗GPT GPTs·재피어·메이크가 네 요소 가운데 어디를 맡는지 표로 구분하기
용어 뜻풀이
비개발자 하네스 4요소제1장
지시 파일·규칙 체크리스트·생성-검증 루프·컨텍스트 관리 — 코드 없이 AI 환경을 짜는 네 가지
린터(linter)제2장
코드 오류를 자동으로 잡아내는 프로그램. 개발자의 자동 규칙 검사 도구
자동화 파이프라인(pipeline)제2장
자동으로 연결된 실행 흐름. 랭체인 실험에서 생성과 검증을 잇던 개발자의 방식
지시 파일제3장
역할·금지 표현·출력 형식·말투·참고 자료를 한곳에 정리한, AI를 위한 업무 매뉴얼
온보딩(onboarding) 문서제3장
신입 직원에게 역할·금지 사항·형식 기준을 알려 주는 문서. 저자가 지시 파일에 견주는 것
규칙 체크리스트제4장
AI 출력을 검증하는 수동·반자동 체크포인트. 입력·출력·행동 규칙의 세 갈래
생성-검증 루프제5장
쓰는 역할과 검토하는 역할을 다른 AI나 다른 프롬프트로 나누어 잇는 흐름
컨텍스트 부패(Context Rot)제6장
대화가 길어질수록 AI가 앞의 지시를 잊어 성능이 최대 30%까지 떨어지는 현상
진행 파일제6장
진행 중인 작업의 상태를 적어 새 세션에 첨부하는 문서. 교대 근무의 인수인계 노트
스킬(Skills)제7장
클로드 코워크의 재사용 가능한 워크플로 패키지. 지시 파일 역할을 하는 기능
커스텀 지침(Custom Instructions)제7장
챗GPT GPTs에서 지시 파일에 해당하는 설정. 특정 업무에 특화된 AI를 만드는 바탕
노코드(no-code) 자동화제7장
코딩 없이 "초안 생성 → 검토 → 저장"의 흐름을 잇는 재피어·메이크 같은 도구
PART I
번역 — 개발자의 하네스를 비개발자의 언어로TRANSLATING THE DEVELOPER'S HARNESS
01QUESTION
챕터 1의 랭체인 실험 결과에서 출발합니다. 그 환경을 개발자는 코드로 만들었는데, 코드를 모르는 사람은 어떻게 하느냐가 이 챕터의 질문입니다.
코드를 모르는 사람은 어떻게 합니까
랭체인 실험의 점수52.8 → 66.5모델은 그대로였습니다. 바뀐 것은 환경이었습니다
바뀐 모델의 수0그 환경을 개발자들은 코드로 만들었습니다
비개발자 하네스의 요소4코드 없이 같은 문제를 푸는 네 가지 방법
점수는 52.8에서 66.5로 올랐습니다. 모델은 그대로였습니다. 바뀐 것은 환경이었습니다.
챕터 1에서 소개한 랭체인(LangChain)의 실험 결과입니다. 그 환경을 개발자들은 코드로 만들었습니다. 시스템 구성 파일, 자동 검증 도구, 실행 흐름 관리 스크립트입니다. 코드를 모르는 사람은 어떻게 해야 합니까? 이 질문이 챕터 3의 출발점입니다.
개발자와 비개발자는 쓰는 도구가 다릅니다. 그러나 해결해야 하는 문제는 같습니다. AI가 일관성 있게 작동하게 만드는 것, 실수를 방지하는 규칙을 쌓는 것, 같은 AI라도 더 나은 결과를 끌어내는 것입니다. 이 문제를 개발자는 코드로 풀고, 비개발자는 다른 방법으로 풉니다.
그 방법을 저는 네 가지로 정리했습니다. 비개발자 하네스 4요소입니다.
사진 1 · 서버 랙. 랭체인의 환경은 개발자들이 코드로 만든 것이었습니다. 코드를 모르는 사람의 길은 따로 있습니다.
Abigor · Wikimedia Commons · CC BY-SA 3.0
개발자와 비개발자는 쓰는 도구가 다릅니다. 그러나 해결해야 하는 문제는 같습니다.
제1장 · 저자
02TRANSLATION
오픈AI 코덱스 팀, 하시모토, 랭체인의 원천 자료에 나오는 개발자 도구를 비개발자 맥락의 같은 역할로 옮긴 표를 제시합니다.
개발자의 하네스를 비개발자 언어로 번역하면
하네스 엔지니어링의 원천 자료는 전부 코드 수준의 인프라를 다룹니다. 오픈AI(OpenAI) 코덱스 팀의 보고서에는 아키텍처 제약과 자동 검증 시스템이 나옵니다. 하시모토의 글에는 에이전트 전용 지시 파일(AGENTS.md)과 자동 규칙 검사 도구가 등장합니다. 린터(linter)라고 부르는, 코드 오류를 자동으로 잡아내는 프로그램입니다. 랭체인의 실험에는 자동화 파이프라인, 곧 자동으로 연결된 실행 흐름이 핵심이었습니다.
비개발자가 이것을 그대로 쓸 수는 없습니다. 그러나 각 도구가 해결하는 문제를 보면, 비개발자 맥락에서도 같은 역할을 하는 것들이 존재한다는 사실이 보입니다.
사진 2 · 책상 위의 노트북. 개발자의 도구를 그대로 쓸 수는 없지만, 같은 문제를 푸는 도구는 이 책상 위에도 있습니다.
Wikimedia Commons · CC0(저작자 표시 불필요)
이 네 가지가 비개발자 하네스를 구성하는 요소입니다. 각각이 개발자 도구와 1:1로 대응합니다. 코드 없이도 같은 문제를 풀 수 있습니다.
도해 1 · 개발자 도구와 비개발자 하네스의 1:1 대응 — 표 1을 그림으로 옮긴 것
PART II
선언 — 비개발자 하네스 4요소THE FOUR ELEMENTS
03ELEMENT ①
4요소의 첫째입니다. AI는 지시받지 않은 것을 모르므로, 역할·금지 표현·출력 형식·말투·참고 자료를 한곳에 모은 업무 매뉴얼을 준다는 선언입니다.
지시 파일 — AI에게 업무 매뉴얼을 줍니다
지시받지 않은 것을 AI는 알지 못합니다. 오픈AI 코덱스 팀의 원칙을 비개발자 맥락으로 바꾸면 이렇습니다. "에이전트가 접근할 수 없는 정보는, 에이전트에게 존재하지 않는 것이다."
새 대화를 열 때마다 AI는 백지 상태에서 시작합니다. 역할을 모르고, 금지 사항을 모르고, 형식 기준도 모릅니다. 지시 파일은 그 빈자리를 채우는 업무 매뉴얼입니다.
개발자의 AGENTS.md(에이전트 전용 지시 파일)에 해당하는 비개발자 버전입니다. 역할 정의, 금지 표현 목록, 출력 형식, 말투 기준, 참고해야 할 자료입니다. 이것들을 한곳에 정리해 두면, AI는 매번 새로 설명받지 않아도 그 기준에 맞춰 작동합니다.
사진 3 · 쌓인 용지. 지시 파일은 두꺼운 규정집이 아니라, 역할과 기준을 한곳에 정리한 한 벌의 업무 매뉴얼입니다.
Sage Ross (WMF), 2013 · Wikimedia Commons · CC BY-SA 3.0
지시 파일에 들어가는 다섯 가지
역할 정의 — 이 AI가 어떤 일을 맡는지
금지 표현 목록 — 쓰면 안 되는 말
출력 형식 — 결과물의 모양
말투 기준 — 어떤 어조로 쓸지
참고해야 할 자료 — 답을 만들 때 근거로 삼을 것
제3장 본문에서 저자가 든 항목 그대로입니다. 이 다섯 가지를 한곳에 정리해 두면 AI는 매번 새로 설명받지 않아도 기준에 맞춰 작동합니다.
비유하자면 신입 직원의 온보딩 문서입니다. 처음 출근한 직원에게 "눈치껏 해"라고 하는 것과, 역할·금지 사항·형식 기준이 담긴 온보딩 문서를 주는 것은 결과가 다릅니다. AI도 같습니다. 지시 파일이 없는 AI는 매번 눈치껏 작동하고, 있는 AI는 기준에 맞춰 작동합니다.
챕터 4에서 이것을 만드는 법을 상세히 다룹니다.
지시 파일이 없는 AI는 매번 눈치껏 작동하고, 있는 AI는 기준에 맞춰 작동합니다.
제3장 · 저자
04ELEMENT ②
제약이 많을수록 에이전트가 더 잘 작동했다는 코덱스 팀의 역설에서 출발해, 입력·출력·행동 규칙 세 갈래의 체크리스트를 선언합니다.
규칙 체크리스트 — AI의 행동 범위를 제한합니다
오픈AI 코덱스 팀의 핵심 발견 가운데 하나는 역설적입니다. 제약이 많을수록 에이전트가 더 잘 작동했습니다. 에이전트가 움직일 수 있는 공간을 좁게 설계하자 오히려 실수가 줄었습니다. 자유롭게 두면 엉뚱한 방향으로 향할 수 있습니다. 좁은 길 위에서는 그럴 수 없습니다.
비개발자의 규칙 체크리스트는 AI 출력을 검증하는 수동 또는 반자동 체크포인트입니다. 세 가지로 나뉩니다. 입력 규칙, 출력 규칙, 행동 규칙입니다.
사진 4 · 교차로의 신호등. 자유롭게 두면 엉뚱한 방향으로 갈 수 있지만, 좁은 길 위에서는 그럴 수 없습니다.
Famartin, 2014 · Wikimedia Commons · CC BY-SA 4.0
도해 2 · 규칙 체크리스트의 세 갈래 — 제4장의 입력·출력·행동 규칙
갈래
무엇을 정하는가
예시 (원문)
입력 규칙
AI에게 주는 정보의 범위
어떤 자료를 포함할지, 민감 정보는 무엇인지
출력 규칙
결과물의 형식과 기준
길이, 구조, 금지 표현, 필수 포함 항목
행동 규칙
AI가 하면 안 되는 것
파일 삭제 금지, 외부 전송 금지, 특정 주제 회피
표 2 · 세 갈래의 규칙 — 제4장의 목록을 표로 옮긴 것
챕터 5에서 이것을 설계하는 법을 다룹니다.
05ELEMENT ③
AI에게 "쓰고 검토해"라고 하면 대부분 "괜찮다"고 한다는 관찰에서 출발해, 쓰는 역할과 검토하는 역할을 분리하는 루프를 선언합니다.
생성-검증 루프 — AI가 자기 일을 검증하게 합니다
여러분이 AI에게 "쓰고 검토해"라고 하면, 대부분 "괜찮다"고 합니다. 랭체인의 실험에서 가장 흔한 실패 패턴이 이것이었습니다. 에이전트가 결과물을 만든 뒤 스스로 검토하고, "맞다"고 판단하고 멈추는 것입니다. 동일한 모델이 동일한 컨텍스트에서 자기 결과물을 판단하면, 편향은 사라지지 않습니다.
해결책은 분리입니다. 쓰는 역할과 검토하는 역할을 다른 AI, 또는 다른 프롬프트로 나누는 것입니다. 자동화 도구(예: 재피어, 메이크)를 쓰면 "생성 → 검토 → 수정"의 흐름을 노코드로 연결할 수 있습니다.
실제로 해 보면 직관적입니다. 클로드로 초안을 쓴 뒤, 별도의 챗GPT 대화창에 "이 글의 논리적 허점을 찾아 줘"라고 붙여 넣는 것입니다. 이것이 가장 단순한 형태의 생성-검증 루프입니다. 자동화 도구를 쓰면 이 흐름을 사람 개입 없이 연결할 수 있습니다.
사진 5 · 나란히 쟁기를 끄는 두 마리. 한 마리에게 끌고 검사하는 일을 다 맡기지 않듯, 쓰는 AI와 검토하는 AI를 나눕니다.
Amanda Slater, 2007 · Wikimedia Commons · CC BY-SA 2.0
도해 3 · 자기 검토와 분리된 검토 — 제5장의 실패 패턴과 해결책
챕터 6에서 이것을 구체적으로 설계하는 법을 다룹니다.
06ELEMENT ④
챕터 1의 컨텍스트 부패를 다시 불러와, 대화 분할·상태 요약·진행 파일로 맥락을 잇는 전략을 교대 근무 인수인계에 빗대어 선언합니다.
컨텍스트 관리 — AI가 멍청해지지 않게 합니다
챕터 1에서 컨텍스트 부패(Context Rot)를 설명했습니다. 크로마(Chroma)의 연구 결과, 대화가 길어질수록 AI 성능이 최대 30%까지 하락했습니다. 긴 대화 하나로 모든 것을 처리하려 하면, AI는 앞부분에서 받은 지시를 서서히 잊습니다.
컨텍스트 관리는 이 문제에 대응하는 전략입니다. 작업을 대화 단위로 분할하고, 세션마다 핵심 상태를 요약해서 이월하고, 진행 중인 작업을 문서로 기록해 두는 것입니다. 앤트로픽(Anthropic) 엔지니어링 팀이 "교대 근무 인수인계"에 비유한 패턴입니다. 이전 교대에서 무슨 일이 있었는지 모르는 새 팀원에게 인수인계 노트를 건네는 것처럼, AI의 새 세션에 진행 파일을 첨부합니다.
도해 4 · 컨텍스트 부패와 인수인계 — 제6장의 문제와 전략
비유가 직관적입니다. 교대 근무하는 편의점 직원이 인수인계 노트 없이 출근하면, 전날 밤에 무슨 일이 있었는지 모릅니다. 인수인계 노트가 있으면 5분 안에 파악합니다. AI의 새 세션에 진행 파일을 첨부하는 것이 그 노트 역할입니다.
컨텍스트 관리의 세 동작
분할 — 작업을 대화 단위로 나눕니다.
요약 이월 — 세션마다 핵심 상태를 요약해 다음 세션으로 넘깁니다.
기록 — 진행 중인 작업을 문서(진행 파일)로 남깁니다.
제6장 둘째 문단에 나온 세 동작을 순서대로 적은 것입니다. 챕터 1의 도해에서 본 '입력이 길어질수록 정확도가 떨어지는' 곡선을 세션 단위로 끊어 되돌리는 방법입니다.
챕터 7에서 이것을 실천하는 법을 다룹니다.
긴 대화 하나로 모든 것을 처리하려 하면, AI는 앞부분에서 받은 지시를 서서히 잊습니다.
제6장 · 저자
PART III
도구와 사람TOOLS AND PEOPLE
07TOOLS
4요소를 실행할 도구로 클로드 코워크, 챗GPT GPTs, 재피어·메이크를 소개하고 각 도구가 어느 요소를 맡는지 표로 보입니다. 도구보다 원리가 먼저라는 결론입니다.
비개발자용 하네스 도구 지형도
네 요소를 실행하려면 도구가 필요합니다. 비개발자가 쓸 수 있는 도구 세 가지를 소개합니다.
클로드 코워크(Claude Cowork) — 비개발자용 데스크톱 에이전트
2026년 초 연구 프리뷰로 공개됐습니다. 클로드 코드(Claude Code)의 에이전트 아키텍처를 코딩 없이 쓸 수 있는 데스크톱 경험으로 제공합니다. 로컬 파일에 직접 접근하고, 하위 에이전트를 병렬로 조정하고, 엑셀·파워포인트 등 실무 결과물을 생성합니다. 스킬(Skills), 곧 재사용 가능한 워크플로 패키지 기능이 지시 파일 역할을 합니다. 폴더 접근 범위 설정, 파일 삭제 전 승인 요청 등 행동 규칙 설정도 가능합니다. 4요소 중 지시 파일, 규칙(행동 범위), 컨텍스트 관리를 하나의 도구에서 다룰 수 있습니다.
챗GPT GPTs — 커스텀 챗봇 빌더
별도의 코딩 없이 특정 업무에 특화된 AI를 설계할 수 있습니다. 커스텀 지침(Custom Instructions)이 지시 파일에 해당합니다. 외부 서비스와 연결하는 기능도 있어 생성-검증 루프의 기반을 만들 수 있습니다.
재피어·메이크(Zapier·Make) — 노코드 자동화 플랫폼
생성-검증 루프를 자동화하는 데 특화된 도구입니다. 두 도구 모두 AI 호출 기능을 포함합니다. 그래서 "초안 생성 → 검토 AI 전달 → 검토 결과 수신 → 저장"의 흐름을 코딩 없이 연결할 수 있습니다. 재피어는 7,000개 이상의 앱과 연동됩니다.
사진 6 · 크기가 다른 렌치들. 하나의 도구로 4요소를 다 다루기는 어렵고, 조합하는 것이 현실적입니다.
J.C. Fields, 2014 · Wikimedia Commons · CC BY-SA 3.0
아래 표는 각 도구가 4요소 중 어느 역할을 담당하는지 보여 줍니다.
도구
지시 파일
규칙 체크리스트
생성-검증 루프
컨텍스트 관리
클로드 코워크
○스킬(Skills)
○폴더·행동 설정
부분 지원
○하위 에이전트
챗GPT GPTs
○커스텀 지침
부분 지원
부분 지원
—
재피어 · 메이크
—
—
○자동화 루프
—
포인트하나의 도구로 4요소를 전부 다루기는 어렵습니다. 도구를 조합하는 것이 현실적입니다.
표 3 · 비개발자용 도구별 4요소 지원 범위 — 원문 그림 3-1을 이 문서의 서체와 색으로 다시 그린 것. ○는 원문의 체크 표시
하나의 도구로 4요소를 전부 다루기는 어렵습니다. 도구를 조합하는 것이 현실적입니다. 지시 파일과 행동 제약은 클로드 프로젝트(Claude Projects)나 코워크에서 관리합니다. 생성-검증 루프는 재피어로 자동화합니다. 이것이 대표적인 조합입니다.
도구는 계속 바뀝니다. 가격도 바뀌고, 기능도 바뀝니다. 그러나 각 도구가 4요소 중 어느 역할을 하는지 파악하면, 도구가 바뀌어도 구조는 유지할 수 있습니다. 도구보다 원리가 먼저입니다.
편집자 주
세 도구에 관한 설명(코워크의 2026년 초 연구 프리뷰 공개, 재피어의 7,000개 이상 앱 연동 등)은 원문의 서술을 그대로 옮긴 것입니다. 저자의 말대로 도구는 계속 바뀌므로, 이 문서를 배포하는 시점에 각 도구의 기능을 다시 확인하시기 바랍니다.
도구가 바뀌어도 구조는 유지할 수 있습니다. 도구보다 원리가 먼저입니다.
제7장 · 저자
08SHIFT
하네스 엔지니어링이 개발자만의 영역이 아니게 되는 전환을 말합니다. 마케터·1인 사업자·교육자의 예를 들고, 한 번에 완성하려 하지 말고 시작해서 쌓으라는 당부로 챕터를 닫습니다.
"코드를 짜는 사람"에서 "AI 팀을 설계하는 사람"으로
하네스 엔지니어링은 지금까지 소프트웨어 개발자의 영역이었습니다. 코드를 짤 수 있어야 했습니다. 4요소 프레임워크가 바꾸는 것이 이것입니다. 코드 없이도 AI가 작동하는 환경을 설계할 수 있습니다. 지시 파일을 작성하고, 규칙을 정의하고, 검증 흐름을 만들고, 맥락을 유지하는 방법 — 이것이 비개발자가 할 수 있는 하네스 설계입니다.
마케터가 콘텐츠 AI 팀을 설계할 수 있습니다. 1인 사업자가 리서치 에이전트와 초안 에이전트를 나눠 운용할 수 있습니다. 교육자가 자료 분류 에이전트와 요약 에이전트를 직렬로 연결할 수 있습니다. 이런 구성을 가능하게 하는 것이 4요소입니다.
도해 5 · 코드 없이 설계하는 AI 팀 — 제8장이 든 세 가지 예
2부(챕터 4~7)부터는 각 요소를 하나씩 설계하는 법을 다룹니다. 3부(챕터 8~10)에서는 실제 업무에 4요소를 조합해 AI 팀을 구성하는 실습이 이어집니다.
한 가지만 기억하고 넘어가시면 됩니다. 하네스는 한 번에 완성하는 것이 아닙니다. 챕터 2에서 하시모토의 원칙을 소개했습니다. 실수가 발생할 때마다 규칙을 추가하는 것입니다. 처음에는 지시 파일 하나로 시작해도 됩니다. 규칙 체크리스트 3항목으로 시작해도 됩니다. 중요한 것은 시작하고, 쌓는 것입니다.
사진 7 · 쌓여 가는 동전. 지시 파일 하나, 규칙 3항목으로 시작해도 됩니다. 중요한 것은 시작하고, 쌓는 것입니다.
Wikimedia Commons · CC0(저작자 표시 불필요)
하네스는 한 번에 완성하는 것이 아닙니다. 중요한 것은 시작하고, 쌓는 것입니다.
제8장 · 저자
정리 체크리스트
비개발자 하네스는 네 가지 요소로 구성됩니다 — ① 지시 파일, ② 규칙 체크리스트, ③ 생성-검증 루프, ④ 컨텍스트 관리.
개발자 하네스(코드)와 비개발자 하네스(문서·설정·자동화)는 쓰는 도구가 다릅니다. 해결하는 문제는 같습니다.
