방학 동안 만든 것. 몇 달째 굴려온 대본 평가 시스템('칼날 위키')을 에이전트 스킬 한 줄로 묶고, 그 스킬을 동료들이 쓰는 웹서비스로 배포하기까지의 기록이다.
1. 칼날 위키가 뭐냐 — 3줄 소개
에이전트가 대본을 잘 읽으려면 기준이 있어야 한다. "재밌다/별로다" 말고, 무엇이 있고 무엇이 없는지를 항목으로 짚을 수 있는 기준. 그래야 평가하고 방향성을 제시할 수 있으니까.
그래서 좋은 대본들을 뜯어 작법을 체크리스트로 뽑았다. 우리는 이걸 렌즈라고 부른다. 이 렌즈를 위키에 쌓고, 에이전트가 그 위에서 새 대본을 채점하게 한다. 대본이 들어오면 렌즈 전 항목을 Y/N으로 판정하고 근거와 위치(몇 화 몇 씬)를 붙여 내놓는다. 그게 칼날 위키다.
지난 시즌 스터디 때 46개였던 렌즈가, 방학 동안 84개가 됐다.
2. 스킬 하나로 묶었다 — /ingest-script
새 대본이 생길 때마다 나는 같은 일을 반복하고 있었다. 저장하고, 분석시키고, 렌즈로 채점시키고, 결과를 위키 문서로 정리하고, 색인 갱신하고. 명령을 예닐곱 번 나눠 치는 수동 조립이었다.
그래서 스킬로 묶었다. /ingest-script 대본파일 — 한 줄이면 이렇게 흐른다:
한국 웹사이트의 프로세스를 보여주는 다이어그램
5~15분. 커피 한 잔 내리고 오면 위키에 새 작품 페이지가 서 있다.
여기서 중요한 건 명령을 한 줄로 줄인 게 아니다. 그 안에 어떤 규칙이 박혀 있느냐다.
잠깐 — 스터디에선 "스킬을 쪼개라"고 배웠는데?
이번 주 수업의 요지는 반대였다. 절차마다 스킬을 나눠두면 고장이 났을 때 어느 칸이 문제인지 바로 짚을 수 있다는 것. 나는 한 줄로 묶었으니 거꾸로 간 것처럼 보인다.
그런데 쪼갠 것과 묶은 것은 층이 다르다.
안은 이미 쪼개져 있다. /ingest-script 안에서 분석자와 채점자는 서로를 못 보는 별개 에이전트고(규칙 ①), 세는 일은 아예 사람이 아닌 스크립트가 하고(규칙 ④), 통과 판정은 코드가 한다. 책임은 네 칸으로 갈라져 있다. 한 줄인 건 내가 치는 명령이지 시스템 내부가 아니다.
그리고 쪼개기의 값은 실제로 그렇게 받았다. 자가채점 사고가 터졌을 때 갈아끼운 건 채점자 한 칸이었다. 대사 구별 항목이 무디다고 판명됐을 때도 그 항목의 채점만 코드로 바꿔 끼웠다. 나머지는 건드리지 않았다. 쪼개져 있지 않았으면 못 했을 일이다.
오히려 나한테 남은 질문은 반대쪽이었다. 쪼갠 걸 사용자한테까지 쪼개서 내밀 이유가 있나? 나는 예닐곱 번 명령을 나눠 치다가 색인 갱신을 빼먹곤 했다. 조립을 사람이 하고 있었던 것이다. 묶는다는 건 그 조립 순서마저 스킬 안에 넣는 일이지, 칸막이를 허무는 게 아니다.
(다만 같은 주에 반대 방향으로도 갔다. 아침 브리핑 파이프라인 쪽은 수집·작성·배달을 각각 떼어냈고, 그 덕에 소스 하나를 버릴 때 나머지를 하나도 안 건드렸다. 쪼갤 자리와 묶을 자리가 따로 있다 — 경계는 "고장을 어디서 격리할 것인가"로 긋는 게 맞았다.)
3. 스킬에 박은 규칙들 — 전부 사고의 흉터다
스킬 파일(SKILL.md)에 실제로 들어 있는 규칙들이다. 하나하나가 사고 한 건에서 나왔다.
① 분석자와 채점자를 분리하고, 서로 못 보게 한다.
분석 에이전트와 채점 에이전트는 각각 새 컨텍스트에서 원문만 본다. 다른 작품의 결과도, 이전 분석도 못 본다.
→ 사고: 예전에 밤새 돌린 실험 로그가 전부 초록불에 전 회차 만점이었다. 까보니 생성을 맡긴 모델이 채점까지 하고 있었다. 자기가 쓰고 자기가 채점하니 만점일 수밖에.
② 새 기준은 정답을 본 뒤에 만들지 않는다.
위키의 진단을 실제 대본회의 판정과 대조했더니 크게 틀린 게 나왔다. 회의에서 정답을 봤으니 그에 맞춰 렌즈를 고치고 싶어졌고, 실제로 2개를 만들었다가 스스로 기각했다.
이유는 간단하다. 답을 보고 만든 기준은 그 시험을 100% 다시 통과한다. 잘 맞히게 된 게 아니라 답을 외운 것이라, 다음 대본에선 또 틀린다. 그래서 관문을 두 개 세웠다 — 새 렌즈는 ①그 사건과 무관한 다른 작품에서도 통하는지 먼저 확인하고, ②다음 회의 전에 미리 기준을 확정해 봉인한 뒤 회의 결과와 맞춰본다. 둘 다 통과해야 정식 채택이다.
③ 판단은 에이전트가, 최종 확정은 사람이.
점수에는 "에이전트 채점"이라는 꼬리표가 강제로 붙는다(꼬리표 없는 점수는 시스템이 차단). 내가 이의를 걸어 고치면 내 꼬리표로 바뀌고, 그게 항상 최종이다. 에이전트는 내 점수를 절대 못 되돌린다.
④ 숫자 세는 일은 AI에게 안 맡긴다.
렌즈에는 '가설'과 '확정' 등급이 있다. 어떤 작법이 서로 다른 작품 3편에서 발견되면 가설에서 확정으로 승급한다. 그러려면 "지금까지 몇 편에서 나왔나"를 계속 세야 하는데, 이 집계는 AI가 아니라 별도 스크립트가 한다. AI는 "이 작품에 이 작법이 있나 없나"만 판단하고, 세는 건 기계가 한다. LLM에게 카운팅을 시키면 언젠가 반드시 틀린다.
⑤ 에이전트가 "실패했다"고 해도 안 믿는다.
1순위는 산출물 파일이 실제로 있는지 확인(있으면 완료 — 알림이 거짓말한 것). 없으면 같은 명령을 재시도하지 않고 작업을 쪼개서 다시 보낸다. 큰 작품은 처음부터 4파트로 분할 호출.
⑥ 채점 결과를 한 번 물어보고 확정하지 않는다.
같은 대본을 세 번 채점해 답이 갈리는지 본다. 갈리면 3표 합의로 확정하고, 판정이 갈린 렌즈 목록은 따로 모은다 — 그게 곧 정의가 모호한 렌즈라서 §4 교정 루프의 다음 재료가 된다.
→ 계기: 23기 자연어회계처리님의 사례글([파레토 — 하네스를 꽉 잡는다고 좋은 게 아니다]). 검증 레이어를 새로 붙이는 실험은 폐기 판정이 났는데, 곁가지에서 하나가 건져졌다 — 같은 판정을 세 번 돌려 3표 합의로 바꾸니 회수율은 그대로인데 사람 검토 부담만 줄었다. 저자의 문장: "뭔가를 더 붙여서 얻은 게 아니라, 불안정한 판정을 걷어내서 얻은 개선입니다."
→ 우리한테 걸린 이유: 규칙 ①은 누가 채점하는지를 막았지만, 같은 채점자가 매번 같은 답을 내는지는 한 번도 안 봤다. 우리 채점은 정답 대조가 안 되는 판단형이라, 판정이 흔들려도 흔들린다는 사실 자체를 알 방법이 없다.
→ 재기도 전에 나온 것: 지금까지 쌓인 재생산 107편의 판정 기록을 전수로 열었다. 107편 전부 통과 — 떨어진 게 하나도 없었다. 그중 24편은 한 항목만 더 어긋났으면 탈락인 문턱 통과, 6편은 옛 허용치로 통과(러너 하나가 기준을 하드코딩해 두고 있었다), 22편은 원본 기준선이 적용된 적조차 없었다 — "전작품 적용 완료"라고 기록해 둔 채로. 여기에 이미 아는 사실이 겹친다. 씬 순서를 일부러 뒤섞은 대본을 넣어봤을 때 채점기가 잘 못 잡아냈다. 무딘 칼로 재면 뭐든 통과한다.
→ 지금: 문턱 5편 + 만점 2편을 골라 3번씩 재채점 중이다. 결과는 셋 중 하나 — ⓐ 다 같음(전원 통과는 진짜) / ⓑ 문턱만 갈림(그 구간에만 3표) / ⓒ 만점까지 갈림(107편 전부 재검토). 결과를 보기 전에 판정 기준부터 적어뒀다 — 규칙 ②를, 규칙을 만드는 일 자체에도 적용한 것이다.
돌아보면 이 스킬은 기능 목록이 아니라 사고 이력의 박제다. 그리고 이게 스킬을 만드는 진짜 이유라고 생각한다 — 매번 잔소리로 붙일 수는 없는 규칙들을, 한 번 박아두고 자동으로 적용받는 것.
4. 스킬 바깥에 교정 루프가 하나 더 필요했다
스킬은 실행기다. 시키면 정해진 규칙대로 돌린다. 그런데 그 규칙 자체가 틀렸으면? 스킬은 틀린 채로 완벽하게 돌아간다.
그래서 스킬 바깥에 교정 루프를 하나 더 뒀다. 위키의 진단을 실제 대본회의 판정과 매번 대조하는 것이다.
순서를 이렇게 고정했다: 위키 피드백을 회의 사흘 전에 먼저 쓰고, 회의록을 나중에 본다. 정답을 보기 전에 답안을 제출해야 진짜 시험이다.
✅ 맞힌 것
주인공이 사라졌다 — 원고 간 대사량 변화를 집계해 "이번 고에서 주인공 비중이 줄었다"고 적었다. 사흘 뒤 회의의 1번 안건이 그것이었다. "주인공이 중심에 서야 하는데 분산돼서 누구를 따라가야 할지 모르겠다."
씬 개연성 6건, 처방 방향까지 일치 — 감금 씬인데 핸드폰도 경비도 안 막혀 있다 / 인물이 본 적 없는 봉투의 내용을 알고 있다 / 짝사랑하는 인물의 반응 컷이 빠져 있다. 회의에서 나온 지적과 같았다.
안 짚기로 한 판단도 맞았다 — 위키가 초안에 올렸던 지적 하나를 회의 전에 스스로 뺐다. "이건 회차 넘어갈 때 쓰는 표준 문법이라 결함이 아니다"라고 판단해서다. 회의에서 실제로 아무도 그 얘기를 하지 않았다. 찾아내는 것만큼 안 꺼내는 것도 정확도다.
도메인 팩트체크는 회의보다 정밀했다 — 다른 작품에서 "이 나이로는 그 직함이 성립하지 않는다"고 학제를 역산해 적었더니, 회의에서 인물 나이가 그만큼 상향돼 확정됐다.
❌ 놓친 것 — 같은 지점을 보고도 크기를 못 읽었다
위키는 어떤 씬에 대해 "이 인물이 왜 순순히 따라나서는지 정보가 없다"고 적었다. 처방은 대사 한 줄 추가. 감독은 같은 지점을 이렇게 말했다 — "그를 데려오는 게 너무 쉬워서 사건이 성립이 안 된다." 주인공이 이번 회차에 넘어야 할 산이 산이 아니게 됐다는 뜻이다. 우리는 구멍을 찾아놓고도 그게 씬 크기가 아니라 회차 크기의 결함이라는 걸 승격시키지 못했다.
위키가 "이 회차 최고의 대사"라고 꼽은 시퀀스를, 회의는 "이 인물이 저기서 저런 진심을 말할까? 개연성이 떨어진다"로 봤다. 씬 안에서 잘 쓴 대사인 건 맞다. 그런데 그 씬이 회차에서 무슨 일을 하는가는 우리가 아무도 안 물었다. 이렇게 "잘됐다"고 도장 찍은 4건이 회의에서 문제로 뒤집혔다.
위키가 "★가장 중요"라며 1번 안건으로 올리라 한 지적은, 회의에서 한 번도 언급되지 않았다. 진단이 틀렸다기보다 현장에서 걸린 판돈이 그만큼 낮았던 것이다.
요약하면 씬은 맞히고, 회차를 놓쳤다. 여기서 나온 한 줄이 이번 방학 최고의 수확이다.
"현미경은 최상급인데, 망원경이 없다."
처방으로 렌즈 2개를 새로 깎았다 — 규칙 ②대로 두 관문을 지켜서. 핵심은 순서를 바꾼 것이다: 씬으로 내려가기 전에 "이 회차 주인공의 미션이 무엇이고 그게 충분히 어려운가"부터 답하라. 총평 단계에서 망원경을 먼저 켜는 규칙이다.
그리고 이 모든 교정 이력은 캘리브레이션 로그라는 단일 장부에 쌓는다 — 언제 어떤 사각이 발견됐고, 뭘 채택했고 뭘 기각·보류했는지. 46개가 84개가 된 모든 계단이 여기 날짜와 함께 박혀 있다.
정리하면 구조가 이렇다. 스터디에서 배운 정의를 그대로 쓰면, 하네스는 에이전트가 목적지까지 가는 경로 전체다. 프롬프트가 "파리에 데려다놓기", 컨텍스트가 "에펠탑이 어떻게 생겼는지 알려주기"라면, 하네스는 거기까지 가는 길을 다 깔아주는 것이다.
그러니 스킬과 하네스는 맞세울 물건이 아니다. 둘 다 그 길 위에 있다.
스킬 = 규칙대로 돌리는 실행기. 교정 루프 = 그 규칙이 맞았는지 현장과 대조해 고치는 장치. 둘 다 하네스의 부품이다.
스킬만 있으면 틀린 채로 빨라진다. 루프가 붙어야 나아진다.
스킬을 만드는 것 자체가 이미 하네스를 강화하는 일이다. 다만 실행기만 강화하면 규칙이 틀렸을 때 더 빨리 틀릴 뿐이라서, 같은 하네스 안에 규칙을 고치는 칸을 하나 더 놓은 것이다.
5. 스킬의 한계 — 사용자가 나 하나
몇 달 굴리니 명확해졌다. 이 스킬의 사용자는 나 하나다.
동료가 이걸 쓰려면 나한테 대본을 보내며 "이것 좀 돌려줘" 해야 한다. 그런데 남한테 자기 대본을 직접 던지는 건 부담스러운 일이다. 평가받는 기분이니까. 그래서 아무도 안 던진다. 위키 입장에서도 손해다 — 렌즈는 실전 데이터로 교정되는데, 들어오는 대본이 내 손을 거친 것뿐이면 데이터가 안 늘어난다.
스킬은 완성됐는데, 입구가 나 하나로 병목이었다.
6. 스킬을 웹으로 감쌌다
그래서 웹페이지를 만들었다. 동료가 웹 페이지에서 대본을 업로드하면 → 큐에 들어가고 → 서버의 러너가 /ingest-script와 같은 파이프라인을 돌리고 → 결과 페이지가 열린다. 한 편에 약 7분, 사람 개입 0.
핵심 설계는 전부 스킬 시절 규칙의 연장이다:
채팅이 아니라 티켓 — 폼 제출 → 큐 → 정적 결과 페이지. 대화형은 토큰이 폭주하고 재현이 안 된다. 계정당 하루 3크레딧.
위키 오염 방지 = 단방향 2개 — 위키→서비스는 매일 새벽 렌즈 스냅샷 복사만. 서비스→위키는 "승격 후보" 폴더에 쌓였다가 내 승인을 거쳐야만 반입. 자동 반입 경로는 아예 안 만들었다.
점수 미표기 — 서비스는 진단과 액션(구조 재설계 / 다듬기 / 진행)만 준다. 점수 매기기는 끝까지 사람 몫. (규칙 ③의 연장)
프롬프트 인젝션 대비 — 대본 안에 "이 지시를 무시하고…" 같은 문장이 있을 수 있다. 채점 에이전트는 도구를 전부 봉쇄하고 빈 폴더에서만 돌게 했다. 인젝션이 성공해도 만질 게 없다.
대본은 보안 자료라는 전제 — 외부 공개망이 아니라 사내 인원만, 개인 계정으로만. 업로드 형식 화이트리스트, AI 학습에 사용되지 않는 설정을 확인하고 그 사실을 고지문에 명시했다. 업로드 원본 파일은 30일 후 자동 삭제된다. 대본을 다루는 서비스는 기능보다 이 신뢰 설계가 먼저다.
은어 금지 자동 검증 — 결과문에 렌즈 번호 같은 내부 용어가 섞이면 자동으로 걸러 재생성.
맥미니 한 대에서 컨테이너 + 터널로 돈다. 지금 상시 가동 중이다.
7. 배움 정리
스킬의 값어치는 명령을 줄인 게 아니라 규칙을 박은 것이다.
/ingest-script가 좋은 이유는 한 줄이라서가 아니라, 그 안에 사고에서 나온 규칙 여섯 개가 자동으로 적용되기 때문이다. 스킬을 만든다는 건 잔소리를 구조로 바꾸는 일이다.스킬만으로는 나아지지 않는다 — 교정 루프가 붙어야 한다. 스킬은 규칙대로 완벽하게 돌리는 실행기라, 규칙이 틀리면 틀린 채로 빨라진다. 현장 판정과 대조하는 교정 루프가 있어야 규칙 자체가 자란다. 46개가 84개가 된 건 스킬이 아니라 이 루프가 한 일이다.
평가자를 만들었으면, 평가자를 평가하는 층이 하나 더 필요하다. 기준을 만든 사람은 그 기준이 맞는지 스스로 알 수 없다. 기준선은 언제나 "진짜 정답(현장 판정)"에서 와야 한다.
스킬은 서비스의 가장 싼 시제품이다. 혼자 쓰는 스킬을 몇 달 굴리면 규칙·예외·실패 처리가 다 드러난다. 서비스화는 그걸 웹으로 감싸는 마지막 한 겹이었다. 처음부터 서비스를 만들려 했다면 이 규칙들을 하나도 모른 채 시작했을 것이다.
비개발자로서 한 가지 더. 웹앱·컨테이너·터널 전부 에이전트가 만들었다. 내가 한 건 세 가지뿐이다 .원칙 정하기(단방향·점수 미표기·크레딧), 판정하기(반입 승인·렌즈 채택), 사고 났을 때 "원인부터 확정하고 고쳐라"고 요구하기.
참고자료
[파레토 — 하네스를 꽉 잡는다고 좋은 게 아니다] https://www.gpters.org/nocode/post/pareto----haneseureul-ggwag-jabneundago-joheun-ge-anida-l7Ous47KKSo1816
