매번 “대화 찾아줘”부터 “여기에 써줘”까지 지시하던 사례글 작성을 하네스로 묶었습니다

저에게는 이미 지피터스 사례글을 쓰기 위한 Skill이 있었습니다.

voice-calibrated-case-study-writing은 과거 글에서 제 문체를 분석하고, 실제 사건을 찾고, 글의 구조를 잡고, 이미지와 검증 방법까지 계획하는 꽤 큰 Skill이었습니다.

이번 하네스를 설계하면서 저는 이전 작업을 네 문장으로 정리했습니다.

“대화섹션 찾아줘~”

“글 구조랑 핵심문장 짜줘~”

“이미지 만들어줘~”

“md는 복붙이 잘 안되니까 대화창에 직접 싸줘~”

이 표현은 이번에 정리한 회고입니다. 과거 세션에는 각각 “그 대화섹션 좀 찾아줘”, “글의 컨셉과 구조 짜줘”, “이미지… 하나씩 보여주는 걸로 하자”, “결과 여기에도 싸줘”라는 실제 요청이 남아 있었습니다.

AI가 일을 한 것은 맞았습니다. 다만 어떤 일을 언제 시킬지는 제가 계속 정했습니다.

돌이켜보니 저는 사례글을 쓰는 사용자가 아니라, 근거 조사원과 작가와 디자이너를 차례로 호출하는 편집국 라우터에 가까웠습니다. (직원은 AI 한 명이었지만 호출명은 꽤 많았습니다.)

🛠️ 순서

1. 글쓰기 Skill 하나가 너무 많은 반품을 받고 있었습니다

2. 작업 순서가 아니라 실패 Owner로 나눴습니다

3. 첫 번째 실패는 사례글 Writer의 잘못이 아니었습니다

4. 파일이 생겼다는 말도 완료로 인정하지 않았습니다

5. 이 글이 하네스 v1.0의 첫 Run입니다

1. 글쓰기 Skill 하나가 너무 많은 반품을 받고 있었습니다

기존 Skill에는 다음 역할이 함께 들어 있었습니다.

• 과거 대화와 파일에서 실제 사건 찾기

• 사건의 순서와 완료 상태 구분하기

• 글의 중심 사건과 목차 정하기

• 제 문체로 초안 쓰기

• 이미지 후보와 캡션 정하기

• 게시 전에 사실·형식·개인정보 확인하기

• 최종 게시본을 보고 다음 글의 문체 갱신하기

처음에는 “사례글 작성”이라는 하나의 목적이 있으니 한 Skill에 있어도 자연스럽다고 생각했습니다.

문제는 결과가 마음에 들지 않을 때였습니다.

사건의 순서가 틀렸는데 문장만 다시 써도 해결되지 않습니다. 중심 사건이 엉뚱한데 이미지만 예쁘게 만들어도 소용없습니다. 반대로 제목의 띄어쓰기 하나가 틀렸다고 과거 대화부터 다시 찾을 필요도 없습니다.

기능이 많아서가 아니라, 실패했을 때 반품할 주소가 하나뿐인 것이 문제였습니다.

2. 작업 순서가 아니라 실패 Owner로 나눴습니다

그래서 사례글 작성 하네스 v1.0은 일을 몇 단계로 자르는 대신, 결과가 잘못됐을 때 누가 고칠지를 기준으로 나눴습니다.

여기서 Owner는 이른바 반품 담당자에 가깝습니다.

Workbench
→ Evidence Reconstructor
→ Story Architect
→ Voice Writer
→ Humanizer
→ Visual Curator
→ Release Evaluator
→ 제가 확인하는 Taste Gate

각 담당은 다음 실패를 맡습니다.

가장 앞 단계의 전제가 바뀌면 그 뒤 결과도 다시 만듭니다. 하지만 지역적인 오탈자라면 그 부분과 최종 검사만 다시 돌립니다.

이렇게 나누고 나니 “Skill을 쪼갠다”는 말도 조금 다르게 이해됐습니다.

긴 설명서를 여러 파일로 자르는 일이 아니라, 실패가 생겼을 때 어디로 돌아갈지를 정하는 일이었습니다.

ALT

수동 사례글 작성과 Owner 기반 하네스의 Before·After

전용 Skill 하나에 일을 몰아넣던 방식과, 실패가 생겼을 때 돌아갈 Owner를 나눈 하네스 v1.0의 비교입니다.

3. 첫 번째 실패는 사례글 Writer의 잘못이 아니었습니다

하네스의 첫 사례는 이 하네스를 만드는 과정 자체로 정했습니다.

Workbench와 근거·구조·이미지·검증·게시 후 학습을 맡는 신규 Skill을 만들고, 기존 Writer에는 “하네스 안에서는 검증된 근거와 구조를 받아 글만 쓴다”는 경계를 추가했습니다. 기존 Skill을 지우거나 전부 다시 쓰지는 않았습니다. 단독으로 쓸 때의 기능은 남기고, 하네스 안에서의 책임만 좁혔습니다.

그리고 신규 Skill 여섯 개를 처음 생성하자마자 모두 거절됐습니다.

이유는 Skill 설명 길이였습니다.

제가 참고한 작성 가이드에는 설명을 1024자까지 쓸 수 있다고 되어 있었는데, 현재 생성기는 신규 Skill의 설명을 60자로 제한하고 있었습니다.

작성 가이드: description 최대 1024자
현재 생성기: description 최대 60자
결과: 신규 Skill 생성 실패

예전 방식이라면 “하네스 생성이 실패했다”는 큰 문제로 뭉뚱그렸을 수도 있습니다. 이번에는 고칠 Owner가 분명했습니다.

사례글 Writer도, 글 구조도, 이미지도 문제가 아니었습니다. 낡은 Skill 작성 가이드가 실패 Owner였습니다.

가이드의 제한을 현재 생성기 기준으로 수정하고, 각 Skill의 설명을 “언제 사용하는가”만 남긴 60자 이내 문장으로 줄였습니다. 이후 Workbench와 다섯 개 Owner Skill이 모두 생성되고 현재 프로필에서 다시 열리는 것을 확인했습니다.

첫 Hard Gate에서는 다른 계약 충돌도 하나 나왔습니다.

Workbench에서 run_mode는 scaffold, draft, release, learn처럼 글을 어디까지 만들지 정하는 값이었습니다. 그런데 validator는 같은 이름을 retrospective, prospective처럼 과거 기록을 복원하는지 미래 계획을 다루는지 구분하는 값으로 사용하고 있었습니다.

release 상태로 검사를 돌리자 validator는 “과거형이나 미래형이 아니므로 실패”라고 답했습니다. 한 필드가 서로 다른 질문 두 개를 받고 있었던 겁니다.

그래서 작성 강도는 run_mode, 증거의 방향은 evidence_mode로 분리했습니다. 테스트, validator, Workbench 템플릿, 이번 Run의 상태표도 함께 수정했습니다. 계약을 바꾼 뒤에는 다섯 테스트가 구 validator에서 실패했고, 두 필드를 지원하도록 고친 뒤 모두 통과했습니다.

하네스가 첫 글을 쓰기도 전에 자기 존재 이유를 두 번 설명해준 셈입니다. (실패 사례 확보만큼은 엄청 잘함😄 )

4. 파일이 생겼다는 말도 완료로 인정하지 않았습니다

하네스가 Skill 파일과 초안 파일을 만들었다고 해서 바로 성공으로 처리하면, 이름만 편집국이고 판정은 여전히 느슨합니다.

그래서 첫 Run에는 구조를 검사하는 작은 validator를 함께 만들었습니다.

먼저 다음 경우에 실패하는 테스트를 작성했습니다.

• 필수 Owner 산출물이 하나라도 없음

• 산출물은 있지만 Owner 상태가 VERIFIED가 아님

• 파일이 비어 있음

• AI가 희주의 Taste Gate까지 APPROVED로 적어버림

처음에는 validator가 없어서 테스트가 실제로 실패했습니다. 그 뒤 필요한 검사만 구현했고 테스트가 통과했습니다.

이 과정에서 배운 RED와 GREEN은 거창하지 않았습니다.

RED는 “이 상태를 성공이라고 부르면 안 된다”를 먼저 실패로 보여주는 것이고, GREEN은 그 실패를 막는 최소한의 검사를 만든 상태였습니다.

하지만 이 검사가 글의 완성도를 전부 판정하는 것은 아닙니다. 자동 Hard Gate는 근거, 완료 상태, 필수 산출물, 개인정보, 링크와 형식처럼 객관적으로 틀릴 수 있는 부분을 확인합니다.

반면, 글의 무게중심이 맞는지, 제가 쓴 말처럼 느껴지는지, 실제로 게시하고 싶은지는 제가 확인합니다.

AI의 Hard Gate
= 틀린 글과 공개하면 안 되는 글을 차단

저의 Taste Gate
= 이 글이 정말 제 글인지 판정

사례글 작성에서 마지막 검증만 제가 하게 하고 싶다는 목표도 이 경계로 정리됐습니다. AI가 제 취향까지 알아서 PASS했다고 적으면 자동화가 아니라 대리 서명에 가깝기 때문입니다.

5. 이 글이 하네스 v1.0의 첫 Run입니다

이번 글을 만들면서 하네스는 다음 산출물을 실제로 나눠 만들었습니다.

• evidence-ledger.md: 과거 대화의 직접 인용과 현재 회고를 구분

• story-brief.md: “전용 Skill이 있는데 사용자가 계속 라우팅했다”는 모순을 중심 사건으로 선택

• draft.md: 제 기존 게시글 문체 기준을 적용한 전체 초안

• visual-plan.md: 수동 네 번 호출과 Owner 하네스를 비교하는 이미지

• release-audit.md: 근거·형식·이미지·개인정보의 객관적 검사

• status.json: 자동 Hard Gate와 제 Taste Gate를 분리한 상태표

설치와 현재 프로필의 Skill 로드, 첫 Run 묶음의 구조 검사를 확인한 뒤 새 대화창도 열어봤습니다.

Skill 이름을 미리 지정하지 않고 “이 일을 지피터스 사례글로 만들기 시작해줘”라고만 요청했습니다. 새 세션은 Workbench와 Evidence Reconstructor를 스스로 불러오고, 전체 글을 쓰지 말라는 요청에 맞춰 scaffold 모드를 골랐습니다. 첫 산출물인 근거 장부도 별도 Run 폴더에 만들었습니다.

한 번의 실험이 모든 표현에서 100% 발동한다는 보증은 아닙니다. 그래도 하네스를 만든 현재 세션 안에서만 흉내 낸 것이 아니라, Skill 이름을 알려주지 않은 새 세션에서 자연어 Trigger와 첫 Owner 라우팅이 실제로 작동한 것까지 확인했습니다.

아직 남은 검증도 있습니다. 이 초안의 Taste Gate는 제가 통과시키지 않았습니다. (그래도 읽어보니 사소한 표현 몇부분만 고치면 될 것 같아 만족스럽긴 합니다.)

게시 후에는 마지막 Owner가 한 번 더 일을 합니다.

제가 수정해 올린 최종 게시글 링크를 보내면 case-study-style-calibrator가 이 초안과 게시본을 비교합니다. 한 번만 나타난 수정은 이번 글의 사례로 남기고, 제가 명시적으로 말했거나 여러 글에서 반복된 수정만 앞으로의 문체 규칙으로 올립니다.

모든 수정이 곧바로 영구 취향이 되면, 한 번 지운 결론 때문에 앞으로 모든 글에 결론이 사라질 수도 있습니다. 학습도 많이 하는 것보다 무엇을 일반화하지 않을지 정하는 것이 더 중요했습니다.

사례글 전용 Skill은 원래도 있었습니다.

달라진 것은 글쓰기 능력보다 제가 매번 직접 맡았던 편집국 라우팅입니다.

이제 마지막으로 남긴 제 일은 네 줄의 작업 지시를 다시 적는 것이 아니라, 완성된 글을 읽고 이것이 정말 제 글처럼 느껴지는지 판단하는 일입니다.

적어도 저는 쓰는 사람으로 돌아왔습니다. 이제야 편집국 호출벨을 하네스에 넘겼습니다.