엘리님의 하네스 엔지니어링을 활용한 논문 작성 자동화 글을 읽고, 핵심 아이디어 두 개만 빌려와 제 맥락(HAT Lab 연구 글쓰기)에 맞춰 1주차 실험으로 쪼갠 기획안입니다. 실제 실험은 이번 주말에 진행하고, 결과는 후속 글로 채울 예정입니다.
시도하고자 했던 것과 그 이유
저는 다오랩의 HAT Lab(Human-Agent Teaming Lab) 연구팀에서 "인간-AI 협업 패턴"을 다루는 플레이북을 쓰고 있습니다. AI가 팀원이 될 때 사람은 무엇을 맡아야 하는가?에 대한 질문으로 시작해서, <Siloed 실험에서 공동 플레이북까지: 우리가 경험한 오케스트레이션>이 주제예요. 지금은 이 결과물을 출판물 형태로 다듬는 작업을 하고 있는데, 여기서 고민이 하나 생겼습니다. 플레이북은 한 명이 쓰는 글이 아니라 여러 공동 저자가 함께 만드는 글입니다. 그러다 보니 글을 쓰기 전에 저자들끼리 합의한 원칙들 — 어떤 톤으로 쓸지, 사례를 어디까지 구체적으로 넣을지, 무엇은 피할지 — 이 있는데, 정작 AI와 글을 다듬을 때는 이 원칙들이 잘 반영되지 않았습니다. 매번 채팅창에서 "이런 톤으로 써줘", "이건 빼줘"라고 일일이 다시 말해야 했고, 대화가 길어지면 그마저 흐려졌습니다.
요컨대 공동 저자들이 합의한 원칙을 AI 글쓰기에 어떻게 안정적으로 반영할 것인가가 제 출발점이었습니다.
그래서 '하네스'가 뭔지 찾아봤습니다
이 고민을 안고 있다가 엘리님의 하네스 엔지니어링 글을 만났고, "하네스(Harness)"라는 개념을 처음 찾아봤습니다.
하네스는 원래 말이나 사람의 몸에 채우는 마구·안전벨트를 뜻하는 말입니다. 소프트웨어 쪽에서는 "테스트 하네스"처럼, 무언가를 정해진 틀 안에서만 동작하도록 잡아주는 장치를 가리키기도 합니다. 엘리님 글에서 빌려온 "하네스 엔지니어링"의 핵심은 한 문장으로 요약됩니다.
AI에게 "이렇게 써줘"라고 하는 것은 제안(Suggestion) 일 뿐이고, AI는 그 제안을 언제든 흘려보낼 수 있다. 진짜로 지키게 하려면 통과하지 못하면 다음으로 넘어갈 수 없는 관문(Mechanical Enforcement) 이 필요하다.
비유하자면, "안전벨트 매세요"라고 부탁하는 게 아니라 매지 않으면 시동이 안 걸리게 만드는 것입니다.
'하네스를 건다'는 게 제 작업에선 무슨 뜻일까
그렇다면 HAT 플레이북 글쓰기에 "하네스를 건다"는 건 구체적으로 무슨 뜻일까요? 저에게는 이렇게 번역됩니다.
공동 저자들이 합의한 원칙을 매번 "부탁"하는 대신, 글이 그 원칙을 통과해야만 출력되도록 관문으로 바꾸는 것입니다. 예를 들어 "사례 없이 일반론부터 쓰지 말자"가 우리 팀의 합의 원칙이라면, 그걸 부탁으로 남겨두는 대신 — AI가 사례를 먼저 확인하지 않으면 본문 자체를 쓰지 못하게 막는 게이트로 만드는 거죠. 합의된 원칙이 권고에서 통과 조건으로 바뀌는 셈입니다.
여기에 한 가지가 더 마음에 들었습니다. 제가 쓰는 글의 주제가 하필 "인간-AI 협업" 입니다. 그러니 이 실험은 결국 협업에 관한 글을 쓰면서, 그 글쓰기 자체에 협업의 원칙을 하네스로 걸어보는 메타적인 시도가 됩니다. 실험 대상과 실험 도구가 같은 주제라는 점이 흥미로웠습니다.
그래서 이번 주 실험의 가설을 이렇게 잡았습니다.
공동 저자들이 합의한 원칙을 '부탁'으로 전할 때(Before) vs '게이트'로 강제할 때(After), 결과물이 그 원칙을 실제로 더 잘 지키는가?
엘리님처럼 Skills 4종 + CLAUDE.md 풀세팅까지 가면 1주차 실험으로는 무거울 것 같았습니다. 그래서 몇 가지 실험해 보고자 합니다.
첫째, 맥락 게이트 — 글을 쓰기 전에 독자·핵심 주장·사례 등 저자들이 합의한 항목부터 확인하도록 강제합니다.
둘째, 집필 순서 강제 — 엘리님이 논문을 Methods부터 쓰게 한 것처럼, 저는 구체적 사례 → 패턴 일반화 → 실무 시사점 순서로 쓰게 강제합니다. 합의 원칙 중 "사례를 먼저"를 순서로 박아두는 거죠.
진행 방법 (도구·프롬프트)
도구는 단순합니다. Claude Code나 별도 Skills 세팅 없이, claude.ai 채팅창 하나로 진행합니다. 엘리님도 "지킬 수 있는 길이가 완벽한 길이보다 중요하다"고 했으니, 1주차에는 CLAUDE.md 대신 채팅 맨 앞에 붙이는 게이트 프롬프트 블록으로 같은 효과를 냅니다.
실험 A. 게이트 없을 때 있을 때 글 차이 보 기
Step 1. Before 만들기 (대조군 확보)
게이트 없이, 평소처럼 부탁합니다. 결과물을 그대로 저장해 둡니다. 이게 비교의 기준선입니다.
HAT Lab 플레이북의 한 꼭지를 써줘.
주제: "사일로형 AI 사용 vs 오케스트레이션형 AI 사용의 차이"
분량: 400자 내외Step 2. 게이트 프롬프트 블록 작성
아래 블록을 그대로 복사해 사용합니다. 이것이 이번 실험의 '안전벨트'입니다.
# HAT Lab 연구 글쓰기 하네스 (제안 아님, 강제 규율)
## 게이트 1: 맥락 확인 (글쓰기 전 필수)
아래 4개를 내가 답하기 전에는 본문을 쓰지 마. 누락 시 질문만 던져.
1. 이 꼭지의 독자는 누구인가? (HAT Lab 팀? 외부 실무자?)
2. 이 꼭지가 전달할 핵심 주장 1문장은?
3. 근거가 될 구체적 관찰/사례가 최소 1개 있는가?
4. 톤: 연구노트형 / 실무 플레이북형 / 학술형 중 무엇인가?
## 게이트 2: 집필 순서 강제
반드시 이 순서로 쓴다. 순서를 어기면 다시 쓴다.
1. 구체적 관찰·사례 먼저 (우리 팀에서 실제로 본 것)
2. 그 사례에서 끌어낸 패턴 일반화
3. 그래서 실무자가 뭘 해야 하는가 (so what)
→ "협업은 중요하다" 같은 사례 없는 일반론으로 시작 금지.
## 게이트 3: 문체 차단
- 연속 불릿 3개 이상 금지 → 산문으로 풀어쓴다
- "또한/따라서/결론적으로" 같은 상투적 연결어 차단
- 저자 입장(stance) 없는 "균형 잡힌" 묘사 금지
- 대신 헷지(~로 보인다)·자기언급(우리 팀은/본 연구는)을 적극 배치
## 게이트 4: 자가 점검 (출력 직전)
글 끝에 체크리스트를 붙여라:
[ ] 사례가 주장보다 먼저 나왔는가
[ ] 사례 없는 일반론 문장이 있는가 (있으면 표시)
[ ] 저자 입장이 드러난 문장이 최소 2개 있는가Step 3. After 만들기 (실험군)
위 블록을 붙인 뒤, Step 1과 똑같은 주제를 다시 요청합니다.
[위 게이트 프롬프트 블록 전체를 먼저 붙임]
하네스 모드로 진행해줘.
주제는 동일하게 "사일로형 AI 사용 vs 오케스트레이션형 AI 사용의 차이"야.
먼저 게이트 1(맥락 확인)부터 실행하고, 누락된 정보가 있으면 질문만 던져줘.여기서 AI는 본문을 바로 쓰지 않고, 게이트 1의 네 가지 질문부터 던질 것입니다. 그 질문에 답하는 과정 자체가 실험의 핵심 관찰 지점입니다. (그냥 부탁했을 땐 묻지 않던 걸 묻게 되니까요.)
Step 4. 게이트 1 질문에 답하고 본문 받기
AI가 던진 질문에 실제 우리 팀 맥락으로 답합니다. 예:
1. 독자: HAT Lab 외부의 실무자(AI를 막 도입하는 팀 리더)
2. 핵심 주장: "에이전트를 여러 개 쓴다고 오케스트레이션이 아니다. 조율자가 없으면 그냥 silo가 늘어날 뿐이다."
3. 사례: 우리 팀에서 각자 따로 쓰다가 겪은 실제 장면 하나
4. 톤: 실무 플레이북형이 입력을 받은 뒤 나오는 본문이 After 결과물입니다.
Step 5. Before vs After 비교
두 결과물을 나란히 놓고, 저자들이 합의한 원칙이 각각 얼마나 지켜졌는지를 봅니다. 사례가 주장보다 먼저 나왔는지, 사례 없는 일반론 문장이 줄었는지, 저자 입장이 드러난 문장이 있는지 — 이 비교표가 사례글의 핵심 근거가 됩니다.
실험 B. 여러 저자의 초고를 '통합'할 때 게이트 걸기
사실 지금 제 진짜 숙제는 한 꼭지를 잘 쓰는 게 아니라, 다섯 저자가 따로 쓴 꼭지들을 하나로 합치는 것입니다. 각자 목차를 쪼개 초고를 썼더니 용어도, 톤도, 깊이도 제각각입니다. 그래서 통합 단계에도 하네스를 걸어보기로 했습니다.
여기서 깨달은 점이 하나 있습니다. 통합 단계에서 AI에게 절대 "통합해줘"라고 하면 안 된다는 것입니다. 그렇게 말하는 순간 AI는 신나서 합치기 시작하면서, 중복을 임의로 지우고 저자 간 의견 충돌을 자기 마음대로 한쪽으로 정해버립니다. 정작 원저자들은 합의한 적이 없는데 말이죠. AI가 효율적이라는 이유로 판단까지 넘겨받으면, 공동 저자들의 합의 과정 자체가 사라집니다.
그래서 이 단계 하네스의 본질은 "AI는 진단만 하고, 결정은 사람이 한다" 를 강제하는 것입니다. 의사가 진단서는 쓰되 수술 여부는 환자가 정하는 것처럼요. 안전벨트는 "고치지 마라, 표로 드러내기만 해라"가 됩니다.
# 플레이북 통합 전 충돌 진단 하네스 (제안 아님, 강제 규율)
## 절대 규칙
너는 통합하지 않는다. 합치지 않는다. 고쳐 쓰지 않는다.
너의 임무는 충돌을 '진단'해서 표로 드러내는 것뿐이다.
어떤 내용을 지울지/남길지는 공동 저자들이 결정한다.
→ 임의로 문장을 합치거나 삭제하면 규칙 위반이다. 다시 한다.
## 게이트 1: 입력 확인
시작 전 확인한다:
1. 통합 대상 꼭지가 모두 제공되었는가? (각 꼭지의 저자/제목 명시)
2. 누락된 꼭지가 있으면 진단을 시작하지 말고 물어본다.
## 게이트 2: 4종 충돌만 진단 (각각 표로)
다음 네 가지만 찾아내 표로 만든다. 해석·평가·해결책 제시 금지.
[표 A: 용어 충돌]
| 개념 | 꼭지별 표기 | 출현 위치 |
같은 것을 다르게 부르는 경우만. (예: 'AI 에이전트' vs '에이전트' vs '봇')
[표 B: 내용 중복]
| 중복된 주제 | 등장 꼭지(저자) | 각각의 서술 차이 |
같은 내용을 두 곳 이상에서 다루는 경우.
→ "어느 걸 지워라"가 아니라 "여기와 여기가 겹친다"까지만.
[표 C: 입장·주장 충돌]
| 쟁점 | 꼭지 A의 입장(저자) | 꼭지 B의 입장(저자) |
서로 모순되거나 긴장 관계인 주장. 가장 중요. 절대 한쪽으로 정리하지 마라.
[표 D: 형식 불일치]
| 항목 | 꼭지별 차이 |
제목 단계, 인용 형식, 높임/평어, 영어 병기 방식 등 표면 규칙.
## 게이트 3: 보존 확인 (진단 후)
각 표 끝에 명시한다:
- 이 진단 과정에서 원문은 한 글자도 수정되지 않았음
- 판단이 필요한 항목은 "[저자 협의 필요]" 태그를 단다쓰는 법은 간단합니다. 위 블록을 붙이고, 그 아래에 각 꼭지를 저자 표시와 함께 붙여넣습니다.
[위 충돌 진단 하네스 블록 붙임]
진단 모드로 진행해줘. 아래는 통합 대상 꼭지 5개야.
=== 꼭지 1 (저자: OOO) ===
[본문 붙여넣기]
=== 꼭지 2 (저자: OOO) ===
[본문 붙여넣기]
... (이하 동일)
먼저 게이트 1(입력 확인)부터 실행하고, 그다음 4종 충돌 표를 만들어줘.결과물로 나오는 충돌 지도 4종 표 중에서 특히 표 C(입장 충돌) 가 핵심입니다. 여기 잡힌 항목들을 공동 저자 회의 안건으로 그대로 올리면 — "저자 A는 silo를 부정적으로, 저자 B는 과도기적 필요악으로 봤네, 어느 쪽으로 갈지 정하자" — 같은 협의가 바로 시작됩니 다. AI가 통합을 대신 해주는 게 아니라, 사람이 협의할 거리를 정확히 짚어주는 역할을 하는 셈입니다.
결과와 배운 점 (예상 / 검증할 가설)
아직 실험 전이라, 여기서는 미리 세운 예상과 검증 포인트를 적어둡니다. 주말 실험 후 실제 결과로 이 단락을 교체할 계획입니다.
예상 1. 게이트가 합의 원칙을 '권고'에서 '통과 조건'으로 바꿔줄 것이다. Before에서는 합의 원칙(예: "사례를 먼저")을 부탁으로만 전하므로 AI가 슬그머니 일반론부터 시작할 것으로 보입니다. After에서는 사례를 먼저 확인하지 않으면 본문을 못 쓰게 막으므로, 같은 분량 안에서도 원칙이 더 일관되게 지켜질 가능성이 높습니다. 진짜 비교 포인트는 "문장이 예뻐졌나"가 아니라 "저자들이 합의한 원칙이 실제로 더 잘 지켜졌나" 입니다.
예상 2. 집필 순서 강제가 결정적일 것이다. 엘리님이 "서론부터 쓰면 결과를 모른 채 공허한 문장만 양산된다"고 한 것과 같은 원리라고 봅니다. 합의 원칙 중 "사례를 먼저"를 순서로 박아두면, 뒤따르는 주장이 그 사례를 가리키게 될 것으로 기대합니다.
앞으로의 계획 / 도움이 필요한 부분
우선 이번 주말에 위 단계를 그대로 돌려보고, Before/After를 나란히 붙여보려 합니다. :)
그리고 지금 진행 중인 공동 플레이북 집필에 AI를 어떻게 붙여 효율화할지 — 특히 여러 저자의 초고를 합치는 단계를 더 깊이 탐색해보고 싶습니다.
