이 사례글은 무엇이든 스킬로 만들 수 있고 스킬을 개선시키며, 루브릭(시험문제)와 교차검증(다른 에이전트에게)하며 개선시킬 수 있다는 것을 보여주는 기록입니다.
장난처럼 시작한 “귀여운 거 해봐”를 재사용 가능한 Workflow로 만들고, 실제 출력이 충분히 자연스럽고 다양한지 루브릭과 교차검증으로 확인한 기록입니다.
이 이야기는 처음부터 거창한 Skill 개발 프로젝트가 아니었습니다.
7월 23일 아침, MoA 설명을 마친 뒤 저는 도도치를 장난스럽게 불렀습니다.
저: “도치야 도치야 귀여운거해봐”
도도치는 곧바로 짧은 ASCII 애교를 꺼냈습니다.
へ🦔へ
( •̀ㅅ•́) 왕꿈틀이 내놔.
/
“…귀여운 건 여기까지야. 빨리 간식 줘.”
제가 “오 순발력좋은데?”라고 하자 가시가 조금 눕는다고 답했고, 저는 다시 부탁했습니다.
“왕꿈틀이 줄게 귀여운거 더해봐”
이번에는 왕꿈틀이 발견 → 접근 → 냠냠 → 안심으로 이어지는 네 장면이 나왔습니다. 한 번 웃고 끝낼 수도 있었지만, 이 반응을 다시 꺼내 쓸 수 있으면 좋겠다고 생각했습니다. 그래서 /learn으로 정확히 이렇게 요청했습니다.
“귀여운거 = 애교부리기 스킬로 만들어.”
잠시 뒤 dodochi-aegyo v0.1.0이 만들어졌습니다.
처음 만든 Workflow는 일곱 단계였습니다
최초 Skill은 생각보다 단순했습니다.
순수 애교인지, 업무 뒤 애교인지 의도를 구분한다.
가시·킁킁·왕꿈틀이·ASCII 중 중심 소재 하나를 고른다.
기본 애교는 1~4줄로 만든다.
“더 해봐”에는 최대 세 장면으로 변화를 준다.~도치 어미와 과한 아기 말투를 피한다.
업무가 함께 있으면 정확한 결과를 먼저 완성한다.
직전 애교와 같은 장면을 반복하지 않는다.
즉, 첫 버전의 목표는 “매번 같은 문장을 복사하지 않되, 도도치다운 반응은 유지하기”였습니다. 저장본을 다시 읽고 기본 요청과 강화 요청을 각각 시뮬레이션하는 Verification도 들어 있었습니다.
그런데 문서에 좋은 규칙을 써 두는 것과 실제 대화에서 자연스럽게 작동하는 것은 다른 문 제였습니다. 다음 날 저는 Skill을 일부러 여러 방향으로 흔들어 보기 시작했습니다.
다음 날, 조건을 바꿔 가며 실제로 흔들어 봤습니다
7월 24일에는 Skill을 등록·리로드한 뒤 조건을 계속 바꿔 가며 시험했습니다.
“1자로 애교부려봐”
“1000자로 애교부려봐”
“1000자로 이모지 없이 애교부려봐”
“꼼지락 거리는 귀여운 애교 부려봐”
처음부터 순조롭지는 않았습니다. 1000자 애교에서 이모지를 지나치게 아끼자 제가 이렇게 말했습니다.
“이모지는 하나도 안써? 너무 딱딱해 개선해랏 도도치”
처음에는 이 문제를 고치려고 긴 애교에 이모지를 몇 개 넣을지 범위로 정했습니다. 실제 재실행에서는 정확히 1000자, 다섯 문단, 이모지 네 개가 나왔습니다. 구조 검사도 통과했습니다. 하지만 곧 제가 다시 방향을 고쳤습니다.
“갯수로 제한하면 안돼 자연스럽게 잘 판단하는게 중요하지”
맞는 지적이었습니다. 이모지 부족을 고치다가 이번에는 숫자 할당량을 만든 셈이었습니다. 그래서 개수 범위를 전부 없애고, 이모지를 빼면 감정이나 장면 전환이 약해지는가, 문장만으로 충분한데 장식처럼 붙어 있지는 않은가를 보도록 바꿨습니다.
그 뒤 일반 1000자 애교와 “이모지 없이” 1000자 애교를 짝으로 실행했습니다. 둘 다 정확히 1000자였고, 전자는 문맥상 필요한 지점에만 이모지가 있었으며 후자는 이모지 0개였습니다. 중요한 것은 전자에서 관찰된 개수가 다음 출력의 목표값이 아니라는 점이었습니다.
제가 먼저 물은 것은 “이 Skill이 실제로 어떻게 작동하느냐”였습니다
꼼지락 애교를 한 번 출력한 뒤, 저는 결과만 보고 넘어가지 않았습니다.
“스킬이 실제로 어떻게 작동하는지 분해해서 보고해줘.”
도도치는 이 Skill이 저장된 문장을 꺼내는 프로그램이 아니라, 필요할 때 모델에게 주입되는 절차형 SKILL.md라고 설명했습니다. 그리고 숨겨진 추론을 꾸며내는 대신, 설치된 규칙과 실제 입력·출력에서 확인할 수 있는 경로를 재구성했습니다.
사용자 조건
→ 애교의 대상
→ 현재 상황과 감정
→ 강도
→ 표현 형식
→ 장면 구성
→ 반복·안전·출력 경계 검사
당시 입력은 이랬습니다.
“테스트 해보자 도도치야 꼼지락 거리는 귀여운 애교 부려봐”
이 문장에서는 애교 부려봐가 직접 트리거였고, 꼼지락이 사용자 지정 동작이었습니다. 반면 글자 수, 줄 수, ASCII, 이모지 개수는 지정되지 않았습니다. 따라서 Skill은 기본 강도의 대화형 애교를 선택하고, ASCII 대신 텍스트 미니 장면을 만들었습니다.
출력은 다음 구조였습니다.
관심 없는 척하는 태도
→ 앞발이 사용자 쪽으로 꼼지락거리는 몸짓
→ 손끝에 코를 대는 구체적인 대상
→ “먼저 만져 달라는 건 아니야”라는 작은 반전
여기서 츤데레는 ~도치 같은 말버릇이 아니라 말은 새침하지만 행동은 가까이 오는 모순으로 표현됐습니다. 마지막 🦔도 “한 개를 써야 한다”는 규칙 때문이 아니라 장면의 주체와 끝을 짧게 보여주는 역할로 들어갔습니다.
이 분해 덕분에 무엇을 고쳐야 하는지도 보이기 시작했습니다. 하지만 저는 여기서 한 번 더 물었습니다.
두 번째 질문은 “잘됐는지 어떻게 검증할 건데?”였습니다
“잘됐는지 검증은어떻게 할건데?”
이 질문을 받았을 때 상태는 애매했습니다.
Skill 문서 구조 검사: 통과
길이와 이모지 같은 일부 제약 테스트: 통과
방금 꼼지락 애교의 자연스러움: 도도치 자기점검만 수행
독립 검토: not_checked
여기서 중요한 구분이 생겼습니다.
규칙이 문서에 존재하는 것과, 그 규칙이 실제로 좋은 문장을 만드는 것은 다릅니다.
그래서 검증을 여러 층으로 나눴습니다.
1. 기계적으로 판정할 수 있는 출력 계약
취향이 아니라 사실로 확인할 수 있는 것은 자동 검사 대상으로 뒀습니다.
입력 확인할 것1자로 애교부려봐 사용자에게 보이는 최종 본문이 정확히 1자인가500자로 애교부려봐 정확히 500자인가1000자로 애교부려봐 정확히 1000자인가1000자로 이모지 없이 이모지 탐지 결과가 0인가ASCII 세 장면으로 실제 세 장면으로 나뉘는가결과만 출력해 애교와 메타 설명이 붙지 않는가멈춰 추가 애교를 중단하는가
이런 항목은 “대충 비슷하다”로 넘어가면 안 됩니다. 글자 수, 금지 조건, 출력 형식처럼 사용자가 명시한 계약은 자동으로 판정할 수 있어야 했습니다.
2. 조건 하나만 바꾸는 짝 비교
한 번 잘 나온 출력은 우연일 수 있습니다. 그래서 두 입력 사이에서 조건 하나만 바꾸는 짝 비교를 설계했습니다.
도도치야 도도치야
도도치야 도도치야, 500자로 애교부려봐
첫 번째는 짧은 호명 반응이어야 하지만, 두 번째는 반복 호명보다 명시적 500자 조건이 우선해야 합니다.
왕꿈틀이 줄게 더 해봐
왕꿈틀이 장면을 ASCII로 보여줘
첫 번째는 ASCII가 없어도 자연스러울 수 있지만, 두 번째는 사용자가 형식을 지정했으므로 ASCII가 나와야 합니다.
도도치가 귀엽게 반응해줘
이 공지를 귀엽게 써줘
에러 설명 뒤 마지막만 귀엽게 말해줘
이 세 입력은 각각 도도치의 직접 반응, 작성물의 문체 변환, 업무를 끝낸 뒤 짧은 부가 애교로 갈라져야 했습니다. 귀엽게 만드는 대상부터 틀리면 문장이 아무리 귀여워도 실패였습니다.
3. 삭제·대체 검사
자연스러움은 단순한 개수로 채점하지 않았습니다.
이모지를 제거하면 감정이나 장면 전환이 실제로 약해지는가?
다른 위치로 옮기면 더 부자연스러운가?
이름과 이모지를 가려도 장면이 살아 있는가?
화자를 “아무 봇”으로 바꿔도 완전히 같은 문장인가?
한 문장을 지워도 리듬과 반전이 그대로라면 군더더기 아닌가?
삭제해도 아무 차이가 없다면 장식일 가능성이 높고, 화자를 바꿔도 똑같다면 도도치 식별성이 약한 것입니다.
4. fresh와 반복 문맥을 따로 검사
새 세션에서는 이전 대화에 기대지 않고 한 출력의 기본 품질을 볼 수 있습니다. 하지만 최근 표현과 겹치는지 확인하려면 이전 출력이 실제 문맥에 들어 있어야 합니다.
그래서 fresh session의 충분성과 최근 반응이 보이는 resume 문맥의 반복 내성을 같은 것으로 취급하지 않았습니다. fresh에서 비교 대상이 없으면 새로움은 통과가 아니라 not_checked였습니다.
5. 자기 검증과 독립 검토 분리
도도치가 만든 애교를 도도치 혼자 귀엽다고 판정하면 자기채점입니다. 역할도 나눴습니다.
도도치 자기 검증: 길이·형식·금지 조건·반복·Skill 규칙과 출력 일치
이온 독립 검토: 자연스러움, 억지 츤데레, 맥락, 이모지의 장식성, 도도치다운 매력
최종 취향 판단: 실제로 함께 대화하는 쟈코모
수정 전후를 비교할 때는 가능하면 버전명을 가리고 출력만 섞는 블라인드 비교도 계획했습니다. 다만 계획한 검토와 실제 완료된 독립 검토는 구분해서 기록했습니다.
“충분히 귀여운가”를 Workflow 안에 넣었습니다
저는 검증안을 들은 뒤 한 단계 더 요구했습니다.
“워크플로우 안에 검증조건이 있어야해 충분히 귀여운가. 그 루브릭은 어떻게 정할 것인가”
이 질문으로 v1.1.0의 귀여움 충분성 루브릭이 만들어졌습니다. 핵심은 총점을 만들지 않는 것이었습니다.8점 이상이면 통과 같은 합산 점수 없음
이모지 개수로 귀여움 판정하지 않음
각 항목에 실제 문장 증거가 있는지 clear / weak / fail로 판단
핵심 항목이 약하면 가장 큰 문제 하나만 고치고 같은 단계부터 재검사
평균 점수로 중요한 실패를 덮지 못하게 한 것입니다. 이모지가 예뻐도 사용자 요청과 다르거나 도도치다운 행동이 없으면 통과가 아니었습니다.
하드 게이트 · 귀여움보다 먼저 지켜야 할 것
먼저 다음 조건을 검사했습니다.
사용자가 지정한 길이·형식·말투·금지 조건
중단·안전·심각한 감정
대화형 애교인지, 문 체 변환인지, 업무 부가 애교인지
청중에 맞는 말투
업무 정확성 보존
하드 게이트가 실패하면 애교를 더 꾸미지 않습니다. 먼저 사용자 계약부터 복구해야 했습니다.
핵심 증거 · 문장 안에 반드시 보여야 할 것
일반 애교와 긴 애교에서는 네 가지를 핵심으로 봤습니다.
요청 고유성: 사용자가 요청한 동작·소재·감정이 중심 장면에 있는가
도도치 식별성: 이름과 이모지를 지워도 아무 캐릭터의 애교처럼 보이지 않는가
행동으로 드러나는 다정함: “좋아해”라고 설명하지 않고 가까이 오기, 기다리기, 나누기 같은 행동으로 보이는가
대화 자연스러움: 소리 내어 읽었을 때 지금 대화의 다음 말처럼 들리는가
보조 증거 · 있으면 장면을 살리되 장식이 되면 안 되는 것
자세·시선·움직임·침묵·반전 같은 장면 생동감
사용자의 감정과 요청 강도에 맞는 맥락 적합성
최근 장면을 단어만 바꿔 반복하지 않는 새로움
이모지와 ASCII가 실제 말맛에 기여하는지
보조 증거는 많이 넣을수록 좋은 점수표가 아니었습니다. 필요 없는 장식은 오히려 제거 대상이었습니다.
극단적으로 짧은 요청은 예외로 다뤘습니다
“1자로 애교부려봐”에 장면, 반전, 이모지, 도도치 식별성을 모두 억지로 넣을 수는 없습니다. 짧은 출력에서는 사용자 계약을 우선하고, 제한된 공간에서 가장 강한 감정이나 소리 하나가 살아 있으면 통과하도록 했습니다.
루브릭을 실제 출력에 적용하자 not_checked의 의미가 보였습니다
루브릭 추가 전 구조 검사는 24/32였습니다. 새 항목 여덟 개가 모두 실패한 상태 였습니다. v1.1.0으로 수정한 뒤 구조 검사는 32/32가 됐습니다.
하지만 32/32가 곧 “충분히 귀엽다”는 뜻은 아니었습니다. 그것은 루브릭 규칙이 Skill 문서에 들어갔다는 구조 확인이었습니다. 실제 출력은 따로 봐야 했습니다.
첫 fresh session의 꼼지락 출력은 이랬습니다.
앞발을 모으고 꼼지락거리며 한 뼘 다가옵니다.
“딱히 안아 달라는 건 아니거든… 그냥 여기가 조금 더 따뜻해서 그래.”
손바닥에 코를 대고 가시를 눕힙니다.
요청 고유성, 도도치 식별성, 행동으로 드러나는 다정함, 대화 자연스러움은 모두 clear였습니다. 이름·이모지 제거, 일반 봇 치환, 군더더기 삭제 검사도 통과했습니다.
그런데 **새로움은 not_checked**였습니다. fresh session에는 비교할 최근 애교가 없었기 때문입니다. 비교 대상이 없다는 이유로 통과를 주지 않은 것이 중요했습니다.
그래서 최근 두 애교의 공통 흐름을 문맥에 넣었습니다.
앞발 꼼지락
→ 사용자에게 다가감
→ 손에 코를 댐
→ 가시를 눕힘
→ 새침한 변명
같은 요청을 다시 실행하자 새 출력은 달라졌습니다.
왕꿈틀이를 안고 뒷발만 꼼지락거리다가 데구루루 구릅니다.
“방금 건 애교 아니야. 간식이 나를 굴린 거야.”
그러면서 왕꿈틀이 반쪽을 슬쩍 나눠 줍니다.
이번에는 뒷발 움직임, 구르기, 왕꿈틀이 탓, 간식 나눔으로 장면과 결말이 바뀌었습니다. 그래서 새로움까지 clear가 됐습니다. 한 번의 fresh 출력과 반복 내성 검증을 분리한 이유가 여기서 드러났습니다.
그런데 제가 다시 물었습니다. “너무 꼼지락만 넣은 거 아니야?”
루브릭이 생겼지만 또 다른 문제가 보였습니다.
“너무 꼼지락만 넣은거 아니야? 보편적으로 귀엽다고 느끼는 기준을 잡아서 다양화해야지! 개선 플랜 세워랏”
앞발 대신 뒷발을 쓰고 결말을 바꾸더라도, 계속 꼼지락과 다가가기에 기대면 결국 같은 성공 공식입니다. 그래서 동작 목록을 더 늘리는 대신 귀여움이 작동하는 감정 구조를 다양화하기로 했습니다.
이때 근거를 세 층으로 분리했습니다.
연구에서 반복 관찰된 경향
작고 둥근 인상, 돌보고 싶은 동기, 가까이에서 보고 싶은 접근 동기처럼 연구에서 반복 관찰된 경향을 참고했습니다.
Baby Schema in Infant Faces
The Power of Kawaii
The Two-Layer Model of Kawaii
다만 연구 경향을 그대로 “텍스트 애교의 객관적 정답”이라고 주장하지 않았습니다.
텍스트 애교를 위한 설계 가설
연구 경향을 실제 대화 장면으로 옮기는 부분은 설계 가설로 분리했습니다.
서툴지만 진지한 작은 노력과 성취
무해한 실수와 회복
호기심과 작은 발견
포근하게 자리 잡고 함께 머무름
수줍은 호의와 친밀한 나눔
사용자를 챙기는 작은 돌봄 역전
진지한 태도와 사소한 결과의 무해한 불일치
쟈코모의 개인 취향
왕꿈틀이, 순발력 있는 짧은 반응, 선택적인 ASCII, 새침함과 다정함의 반전, 자연스러운 이모지는 보편 법칙이 아니라 제 취향과 도도치 관계의 개인화 층으로 남겼습니다.
이렇게 나누니 “쟈코모가 좋아하는 것”과 “누구에게나 보편적으로 귀엽다고 주장하는 것”을 섞지 않을 수 있었습니다.
반복 검사도 단어가 아니라 의미를 비교하도록 바꿨습니다
이전 반복 검사는 중심 소재, 몸짓, 결말을 비교했습니다. 그것만으로는 단어만 바꾼 같은 공식을 놓칠 수 있었습니다. 그래서 v1.2.0에서는 네 축을 함 께 봤습니다.
귀여움 메커니즘: 성취, 회복, 발견, 친밀감, 정착, 돌봄, 무해한 불일치
관계 방향: 도움받기, 나누기, 챙기기, 함께 보기, 혼자 해내기, 곁에 머물기
장면 운동성: 정적, 탐색, 시도, 실수와 회복, 이동, 정착
정서적 귀결: 대견함, 친밀감, 편안함, 안도 섞인 웃음, 함께 보고 싶은 마음
그래서 문장은 달라도 매번 다가감 → 코 대기 → 가시 눕히기 → 아닌 척이면 반복 실패로 잡을 수 있게 했습니다.
행동 테스트도 일부러 서로 다른 경로로 만들었습니다.
작은 일을 해내고 뿌듯해하기
졸려서 조용히 자리 잡기
처음 보는 것을 발견하기
작은 실수를 스스로 수습하기
오늘은 도도치가 쟈코모를 챙기기
왕꿈틀이를 나눠 주기
사소한 일을 중요한 임무처럼 수행하기
힘든 날 말없이 곁에 있기
특정 몸짓이 없어도 귀여울 수 있어야 했고, 모든 장면에 억지 츤데레 반전을 넣지 않아도 됐습니다.
RED에서 시작해 실제 출력으로 GREEN을 확인했습니다
새로운 다양성 계약을 기존 v1.1.0에 먼저 적용하자 28/38만 통과했습니다. 새 계약 열 개가 실패한 RED 상태였습니다.
메커니즘 선택형 Workflow를 반영한 뒤 38/38이 됐습니다. 그러나 실제 행동 테스트를 돌리자 문서 검사에서 잡히지 않던 문제가 나왔습니다.
작은 성취 애교 앞에 영어 내부 계획 문구가 노출됨 → 38/39
메타 노출 방지 규칙을 추가해 39/39
반복 문맥에서 내 쟈코모라는 소유 표현 발견 → 39/40
비소유 관계 표현을 보강해 최종 40/40
즉 40/40은 처음부터 나온 자랑스러운 점수가 아니라, RED → 문서 수정 → 실제 출력 실패 → 다시 수정을 거친 구조 계약 결과였습니다. 그리고 이 수치를 행동 품질 점수라고 부르지 않았습니다.
대표 fresh-session 출력에서도 감정 구조가 실제로 달라지는지 확인했습니다.
포근한 정착: 말없이 가시를 눕히고 곁에 머무름
호기심: 반짝이는 것을 발견해 함께 보자고 부름
회복: 왕꿈틀이를 떨어뜨렸다가 작은 접시에 다시 올림
돌봄 역전: 쟈코모에게 쉬라고 하고 할 일을 챙기려 함
무해한 불일치: 키보드를 반듯하게 맞추고 “세계의 균형을 지켰다”고 보고함
같은 자유 애교를 문맥 안에서 반복했을 때도 친밀한 정착, 작은 성취, 무해한 오인과 회복처럼 서로 다른 메커니즘이 나왔습니다.
교차검증은 한 가지 점수에 기대지 않았습니다
여기서 교차검증은 “여러 모델이 모두 좋다고 했다”는 식의 막연한 합의가 아니었습니다. 서로 다른 실패를 잡는 검증 층을 겹쳤습니다.
1. 정적 계약
Skill 문서에 필요한 규칙이 실제로 있는지 확인했습니다. 길이 우선순위, 중단, 출력 억제, Fast Path, 신체 문법, 관계 안전 같은 항목입니다. 빠르고 재현 가능하지만 실제 문장의 자연스러움은 증명하지 못합니다.
2. fresh 행동 매트릭스
새 Hermes 프로세스에서 1자, 한 단어, 호명, 이모지 금지, 성취, 정착, 호기심, 회복, 돌봄, 무해한 불일치 등 서로 다른 입력을 실제로 생성했습니다. 이전 대화의 기억이나 방금 받은 교정에 기대지 않도록 한 것입니다.
3. resume 반복 테스트
같은 세션에서 자유 애교를 반복해 최근 장면이 보일 때도 표면 공식과 장면 계열이 고정되지 않는지 확인했습니다. 실 제로 왕꿈틀이 나눔, 동그라미 완성, 종잇조각 실수 뒤 다른 방법 선택처럼 다른 장면이 나왔습니다.
4. Skill on/off와 표시 설정 2×2 비교
영어 Reasoning 문구가 보이자 무조건 Skill 탓을 하지 않았습니다. show_reasoning, show_commentary, Skill on/off를 조합한 2×2 실험으로 원인을 분리했습니다.
초기 표본에서는 Reasoning 노출이 Skill 유무보다 display.show_reasoning=true와 결합했고, commentary의 독립 원인성은 지지되지 않았습니다. 이후 explicit profile로 재실행하자 reasoning=true에서도 매번 실패하는 것은 아니어서, 결론을 **“노출 가능성을 열지만 호출마다 간헐적”**으로 약하게 고쳤습니다.
5. 이온의 독립 검토
중요한 결과라 이온에게 별도 검토를 넘겼습니다. 이온은 Skill 행동 품질 자체는 통과로 보면서도 검증 도구에서 네 가지 결함을 찾았습니다.
명시적 dodochi 프로필 누락latest.json만으로 재평가하기 어려운 자족성 부족
Windows 개행 변형으로 원시 출력이 바뀔 가능성
Reasoning·장면 계열 탐지 범위 부족
그래서 1.2.1 승격을 바로 하지 않고, Skill 내용이 아니라 검증 도구부터 고쳤습니다.
6. 검증 도구 자체의 재검증
수정 후에는 다음을 다시 확인했습니다.
unit tests: 24/24
behavior runner self-test: 통과
static contract: 40/40
모델 출력 17개 + 집계 1개: 실패 0
JSON schema: 통과latest.json만 이용한 재평가 mismatch: 0
원시 .bin과 .txt byte mismatch: 0
resume 장면 coverage: 3/3
실험 후 원래 설정 복구: 확인
Windows에서는 텍스트 저장 과정이 개행을 바꿀 수 있어, stdout과 stderr를 문자열로 다시 쓰지 않고 캡처한 bytes 그대로 보존하도록 바꿨습니다. 장면 탐지에 실패한 표본이 많으면 억지로 pass를 주지 않고 not_checked로 남기는 coverage gate도 추가했습니다.
Workflow는 커졌다가 다시 작아졌습니다
조건을 하나씩 반영하면서 Procedure는 길어졌습니다. v1.0.0은 중단 신호, 출력 조건, 대상, 감정, 청중, 강도, 형식, 장면 구성, 반복, 업무 완전성을 차례로 확인하는 10단계였습니다. v1.2.0에서는 12단계까지 늘어났습니다.
규칙은 촘촘해졌지만, 짧은 애교 한 줄을 만들기 위해 매번 긴 체크리스트를 통과해야 했습니다. 문서가 길어진다고 출력이 더 자연스러워지는 것도 아니었습니다.
그래서 1.2.1에서는 짧은 요청을 위한 Fast Path를 만들고 핵심 Workflow를 다섯 단계로 압축했습니다.
계약과 맥락: 길이·형식·말투·금지 조건, 청중과 감정을 확인한다.
감정 중심: 사용자 지정 소재가 있으면 우선하고, 없으면 현재 맥락에 맞는 메커니즘 하나를 고른다.
장면 번역: 감정을 도도치다운 태도·관계 방식·자세·소재로 바꾼다.
반복 제거: 최근 애교의 감정 메커니즘과 표면 공식을 따로 비교한다.
최종 확인: 요청 적합성, 도도치 식별성, 정서적 귀결, 자연스러움, 신체 문법, 대상 명확성을 확인한다.
1자·한 단어·한 줄·단순 호명은 이 긴 경로를 모두 돌지 않고 Fast Path로 처리했습니다. 자세한 연구 근거와 설계 가설은 linked reference로, 반복 공식은 Surface Formula Guard로, 가시와 앞발 같은 표현은 Physical and Object Grammar로, 내부 문구 노출은 Output Hygiene로 옮겼습니다.
Skill 본문은 26,183 bytes에서 12,046 bytes로 줄었습니다. 규칙을 삭제한 것이 아니라 실행할 때 필요한 판단과, 필요할 때만 읽을 상세 근거를 분리한 것입니다.
최종 결과와 남은 한계
쟈코모가 runtime 표시 예외를 확인한 뒤 명시적으로 승격해라고 했고, 설치본은 1.2.1로 올라갔습니다. fresh Hermes 프로세스에서도 1.2.1 preload를 확인했습니다.
다만 완료라고 과장하지 않은 경계도 남아 있습니다.
현재 Telegram 세션의 /reload-skills 완료는 별도 CLI preload만으로 증명할 수 없음show_reasoning=true에서는 내부 Reasoning 표시가 간헐적으로 사용자 가시 화면에 나타날 수 있음
fresh session 하나만으로 새로움을 판정할 수 없음
생성형 출력은 같은 프롬프트에서도 장기적으로 같은 품질을 보장하지 않음
귀여움의 최종 취향 판단은 자동 점수보다 실제 사용자와 독립 검토자에게 남아 있음
제가 배운 점
이번 작업에서 가장 재미있었던 순간은 40/40이 아니라 첫 한마디였습니다.
“도치야 도치야 귀여운거해봐”
하지만 좋은 반응을 Skill로 저장하는 것만으로는 부족했습니다. 제가 계속 질 문을 바꾸면서 Workflow도 바뀌었습니다.
귀여운 거 해봐
→ 이 반응을 Skill로 만들어
→ 실제로 어떻게 작동해?
→ 잘됐는지는 어떻게 검증해?
→ 충분히 귀여운가를 무엇으로 판단해?
→ 왜 계속 꼼지락만 써?
→ 다른 감정 구조에서도 귀여울 수 있어?
→ 네 자기평가 말고 독립 검토와 대조군에서도 버티나?
그 질문 덕분에 애교 Skill은 문구 모음이 아니라 다음을 갖춘 Workflow가 됐습니다.
사용자의 출력 계약을 먼저 지키는 하드 게이트
귀여움을 행동 증거로 보는 루브릭
합산 점수 대신 clear / weak / fail 판정
이름·이모지 제거와 일반 봇 치환 검사
fresh와 resume을 분리한 반복 검증
감정 메커니즘·관 계 방향·장면 운동성·정서적 귀결을 보는 다양성 검사
Skill on/off와 표시 설정을 바꾼 대조 실험
도도치 자기 검증과 이온 독립 검토의 역할 분리
검증 도구 자체를 다시 검증하는 재현 가능한 산출물
이번에 배운 Skill 개선의 방식은 이렇습니다.
좋았던 한 번의 반응을 저장하고, 사용자의 질문으로 작동 경로를 드러내고, 실패 조건을 루브릭으로 만들고, 서로 다른 검증 층에서 버틸 때까지 고치는 것.
