내 일을 줄이는 하네스 만들기

핵심: 결과물이 아니라 생성 장치를 만든다

에이전트에게 일을 시킬 때 대화로 결과물을 바로 받아 내면, 다음에 같은 일을 할 때 처음부터 다시 해야 한다. 대신 그 일을 해 주는 장치(하네스) 를 만든다. 말로 코딩하되, 코딩하는 대상이 최종 결과물이 아니라 코딩하는 에이전트다.

결과물에 직접 손대지 않는다. 고치고 싶은 곳이 보이면 결과물이 아니라 장치를 고친다.
고치는 일(iteration)도 직접 하지 않고 「여러 각도에서 스스로 비판하고 장치를 고쳐라」라고 시킨다.
남이 만든 스킬·플러그인을 잔뜩 받는 것으로는 내 일이 줄지 않는다. 그것은 그 사람의 일에 맞춘 가속 장치다. 지금 내가 하는 일을 하나씩 위탁하는 장치를 직접 만들 때 가속이 시작된다.
협업에 필요한 공용 하네스(팀 작업 흐름 통일 등)는 따로 두되, 출발점은 언제나 내 일을 덜어 주는 것이다.

일반론으로서의 하네스 엔지니어링은 프롬프트에서 하네스로, 장치가 스스로 도는 구조는 루프 엔지니어링에 정리했다. 이 노트는 한 사람이 자기 일을 위한 장치를 쌓아 가는 실전 절차를 다룬다.

장치를 만드는 순서

예: 뉴스레터와 이벤트 안내 메일을 쓰는 장치.

1. 탐색 질문으로 맥락 쌓기   "이 채널은 무엇을 다루나", "안내 메일에 고려할 것은?"
2. 목적 선언                 "이걸 지금 쓰려는 게 아니라, 이런 일을 자동화할 프로젝트를 셋업하려 한다"
3. CLAUDE.md 작성            대화 내용을 바탕으로 프로젝트의 기본 문서(soul document)를 만든다
4. 진행 기록 규칙            PLAN.md·PROGRESS.md에 할 일과 진행 상황을 남기고, 새로 시작하면 둘을 먼저 읽게 한다
5. 구성 요소 제안받기         필요한 에이전트·명령·스킬 아이디어만 먼저 받는다
6. 형식대로 만들기            Claude Code의 구조와 형식을 조사한 뒤 .claude/ 아래에 정확한 형식으로 만든다
7. 참고 자료 캐시             조사한 내용을 reference/ 폴더에 저장하고 에이전트·스킬이 읽어 쓰게 한다
8. 다듬기                    초안을 보고 비판·수정을 시킨다. 예전에 직접 쓴 글을 주고 말투·구성·방향을 뽑아 장치에 반영한다

단계	요령	이유
맥락 쌓기	원하는 것을 한 번에 시키지 않고 질문부터 몇 턴 깐다	모델이 탐색할 공간은 맥락으로 정해진다. 처음 몇 턴의 정렬(alignment)이 세션이 옆길로 새지 않게 한다
구성 요소	「만들어라」 전에 「무엇이 필요할지 제안해라」	바로 만들게 하면 Claude Code 형식을 모른 채 프로젝트 루트에 아무 폴더나 만든다. 하네스와 통합하려면 `.claude/` 아래 정해진 형식(YAML frontmatter + 마크다운)을 지켜야 한다
진행 기록	「다른 에이전트에게 넘길 자료」라고 표현한다	「네가 잊어버릴 테니」 같은 표현은 모델을 방어적으로 만든다. 프런티어 모델이 평가 상황을 상당 부분 알아챈다는 연구(Needham 외, 2025)도 있어, 평가와 실제에서 행동이 달라질 수 있다. 의인화가 아니라 토큰 생성 방식에 맞춘 표현이다
참고 자료	조사 결과를 파일로 저장	매번 웹을 다시 조사하는 시간을 줄인다. 새 내용을 찾아 갱신하는 명령을 따로 둘 수 있다
새로 만든 구성 요소	세션을 나갔다 다시 들어온다	새로 만든 명령·스킬은 실행 중인 세션에 바로 잡히지 않을 수 있다

장치를 세우는 시간보다 비판과 수정을 시키는 시간이 더 길다. 스펙을 먼저 길게 쓰는 대신 문답으로 맥락을 함께 쌓으면서 스펙을 만든다.

입력 습관

모국어로, 말로 입력한다. 품질 차이는 크지 않고, 외국어로 타이핑하는 사람이 오히려 병목이다. 다만 스킬·명령 같은 장치 파일은 영어로 만들게 하면 토큰이 절약된다.
권한 확인을 모두 끄고 돌릴 때는 VM 안에서만 돌린다.

서브에이전트와 병렬 작업

같은 작업을 잘게 나눌 수 있으면 서브에이전트로 병렬 처리한다.

한 에이전트가 맡을 양을 정해 준다. 「문서 100개를 번역해라」라고만 하면 맥락이 넘쳐 터진다. 「한 에이전트당 4개씩」이라고 하면 25개가 동시에 뜬다.
코딩은 파일 단위로 나누는 식으로 분할 규칙을 정해 둔다.
명령(command)은 여러 서브에이전트를 병렬로 띄우거나 이어 붙일 수 있고, 에이전트가 명령을 부를 수도 있어 조합의 바깥 틀로 쓴다. 서브에이전트의 중첩 실행도 지원된다(공식 문서).
사람이 병렬 세션을 욕심내서 여러 창을 동시에 보면 인지 부하가 급격히 커진다. 토큰 생성이 빨라지면 창을 여러 개 띄울 이유도 줄어든다.

사람이 코드를 쓰지 않는 개발 파이프라인

장치를 끝까지 밀면 사람의 일은 이슈 등록, 피드백, 보고서 읽기로 줄어든다. 파이프라인은 복잡한 도구가 아니라 cron과 claude -p다.

flowchart TB
  n1["사람·AI가 GitHub 이슈 등록"] -->|"15분마다 cron"| n2["claude -p #quot;/새-이슈-처리#quot;<br/>새 이슈를 검증하고 현재 코드 기준 구현 계획을 짜서 큐에 넣는다"]
  n2 --> n3["다른 에이전트가 큐에서 꺼내 구현"]
  n3 --> n4["테스트"]
  n4 -->|"실패하면"| n5["다른 에이전트가 고친다"]
  n5 --> n4
  n4 --> n6["PR"] --> n7["머지"]
  n7 --> n8["이슈마다 사람이 읽을 기술 보고서(tech report) 작성"]

장치가 자기 일을 만든다. 예를 들어 모든 화면의 스크린샷을 찍는 기능을 먼저 만들게 한 뒤, 스크린샷을 보고 개선할 점을 각각 이슈로 발행하게 한다.
기술 보고서는 사람에게 공부 과제를 낸다. 보안 평가, 성능, 품질, 내린 기술적 결정, 바뀐 코드에 더해 「이 결정을 따라가려면 무엇을 공부해야 하는지」를 적게 한다. AI의 선택이 사람이 모르는 채로 쌓이지 않게 하는 장치다.
장치는 하루 한두 번 스스로를 업데이트한다. 여러 각도의 자기 비판 결과로 결과물이 아니라 장치를 고친다.

비슷한 흐름의 일반 원칙은 루프 엔지니어링, claude -p 사용법은 Claude Code 활용 가이드의 「자동화」에 있다.

같은 방식은 비개발 직군에도 통한다. 빈 폴더에 CLAUDE.md를 만들고 30분 정도 스스로 장치를 키우게 하면 문서 작성·자료 정리 같은 반복 업무가 크게 준다. 조직 차원의 확산 방법은 조직 AX에 따로 정리했다.

2개월 규칙

지금 AI로 안 되는 일은 당장 해야 하는 게 아니면 미룬다. 모델은 두어 달 주기로 크게 바뀌므로, 미뤄 둔 일이 다음 모델에서는 되는 경우가 많다.

병목은 계속 옮겨 간다

단계	병목	해법
1	쓸 수 있는 토큰의 양	토큰 사용량이 곧 경쟁력이 된다
2	머지 큐(에이전트끼리 만든 코드가 충돌)	충돌 해결도 에이전트에게 맡긴다
3	생각(thinking) 토큰	thinking 예산을 늘리면 결과는 좋아지지만 느려진다. 어려운 곳만 많이 생각하게 하는 적응형 thinking 예산과 그걸 조절하는 하네스가 필요하다
4	추론 속도	더 빠른 고속 추론으로 반복 횟수를 늘리는 쪽이 경쟁력이 된다

사람의 비용: 인지 부하와 의존

AI에 맡겨도 인지 부하는 줄지 않는다. 피드백이 쉼 없이 들어오기 때문이다. 사용량 한도가 리필될 때마다 돌리려는 압박이 생활 리듬을 깨기 쉽다.
에이전트 코딩은 가챠 게임처럼 즉각적인 보상을 준다. 잘되니 더 하고, 더 하면 또 잘된다. 그만큼 의존적이 되기 쉽다.

소프트웨어의 가치가 옮겨 간다

관점	내용
버려지는 소프트웨어	쉽게 만든 소프트웨어는 유지 의지가 약하고, 비슷한 것이 수십 개씩 생긴다. 관리되지 않는 오픈소스가 크게 늘지만, 많이 쓰이는 소프트웨어의 수는 비슷하게 유지된다
SaaS	직접 만들 수 있어도 직접 안 해도 되는 일은 사는 편이 낫다. SaaS 시장은 남되, 승자는 빠르게 바뀔 수 있다
코드의 가치	코드는 목적이 아니라 로직을 구현한 수단이다. 사람이 코드를 쓰지 않는 속도로 생산되면 코드 자체의 가치는 0에 가까워지고, 가치는 로직과 검증으로 옮겨 간다
소프트웨어의 새 정의	어림으로 보면 로직을 처리하는 모델 약 80% + 모델을 감싸 결정론적으로 동작하게 하는 로직 코드(하네스) 약 10% + 사람·AI와의 인터페이스 약 10%다
하네스가 경쟁력	코딩 에이전트의 경쟁력은 모델만이 아니라 하네스 자체에 있다. 같은 하네스에 다른 회사 모델을 붙여도 잘 돈다
AI를 위한 인터페이스	도구의 사용자는 사람이 아니라 사람에게 일을 위임받은 에이전트가 된다. 스킬을 함께 배포하고, 출력을 AI가 읽기 쉽게 하고, CLI를 몰라도 유추할 수 있는 형식으로 맞춘다

이 전환은 펀치 카드 → 키보드 코딩, 패키지 소프트웨어 → 웹·모바일 서비스에 이은 변혁으로, 「키보드로 코딩」에서 「의미를 전달하는 코딩」으로 바뀐다. 플랫폼 전환이라는 관점은 AI 플랫폼 전환과 일의 재편과 이어진다.

논쟁적인 관점

주제	관점
에이전트의 성격	사람과 선택지를 주고받으며 맞춰 가는 쪽과 「알아서 해 줄게」 쪽으로 도구가 갈린다. 최고치와 편안함 사이의 교환이다
컴퓨터공학	무용론과 반대로 중요성이 커진다. 배우는 것은 프로그램이 아니라 단순한 게이트에서 복잡한 로직을 세우는 사고 구조다. 도메인 전문가가 AI를 배우는 것보다 AI를 아는 사람이 도메인을 배우는 편이 빠르다
스타트업	가장 큰 위험은 복제가 너무 쉽다는 점이다. 기회는 AI가 맥락을 해석하게 되면서 새로 IT의 영역에 들어오는 분야에 있다
회사의 해자	판이 안정되면 원가가 투명해져 다시 브랜드와 트랙 레코드가 경쟁력이 된다. 수많은 예외(edge case)를 밟아 온 암묵지는 쉽게 복제되지 않는다

정리

결과물이 아니라 결과물을 만드는 장치를 만들고, 장치를 고친다.
대화로 맥락을 쌓고 → CLAUDE.md·PLAN/PROGRESS → 구성 요소 제안 → 정확한 형식으로 생성 → 참고 자료 캐시 → 비판과 수정 순서로 키운다.
남의 스킬을 모으기보다 지금 내 일을 하나씩 위탁하는 장치부터 만든다.
자동화는 cron과 claude -p로 충분하다. 사람이 따라갈 수 있게 보고서와 공부 과제를 남기게 한다.
병목은 토큰 → 머지 → thinking → 추론 속도로 옮겨 간다. 안 되는 일은 두 달 미룬다.

버그 제보