1. 하려던 일
기본과제에서는 이미 나뉘어 있던 지출결의 파이프라인과 콘텐츠 파이프라 인에 명찰(인터페이스 카드)을 붙였습니다. 이번에는 확장으로, 이 기준을 제 스킬 서랍 전체에 대봤습니다. 설치된 스킬은 33개지만 대부분은 외부 스킬팩(문서 변환, TDD, 다이어그램 등)이고, 제가 직접 만든 건 7개입니다:
스킬
한 줄 책임
태어난 계기
지결셋업
월말 지출결의 산출물을 프로젝트별로 조립·교차검증
매달 반복되는 25일 셋업
증빙대사
"증빙 안 왔다" 알림의 진위를 메일 실물과 대조, 누락이면 소급 복구
알림이 거짓말한 사고
kt-bill
통신 명세서 1개 채널의 자동수취 점검·재처리
매달 오는 암호 PDF
n8n-debug
자동화 워크플로우가 깨졌을 때 추측 금지·실증 5단계
"추측→땜빵→재실패" 루프
다시보기
스터디 강의 영상 → 녹취록 → 요약 자동화
매주 반복되는 복붙
사례글발행
md 정본 → 발행용 변환 + 익명화 점검 + 발행 검증
워드 복사가 서식을 깨뜨린 사고
ingest-script
새 대본을 위키에 분석·평가·저장 (라우터 + 에이전트 2)
대본 들어올 때마다 같은 8단계
2. 쪼갤 게 없었다
훑어보니 7개 중에 쪼갤 만한 게 없었습니다.
처음엔 좀 이상했는데, 기준을 다시 읽어보니 이해가 갔습니다. 분해가 필요한 건 이런 구조입니다 — "지결 써줘" 한 마디에 스킬 하나가 메일함에 들어가서 증빙을 가져오고, 그걸로 초안을 쓰고, 증빙을 분류하고, 묶고, 저장까지 다 해먹는, 말하자면 딸깍하면 원맨쇼하는 스킬. 이러면 증빙이 안 왔을 때 메일 문제인지 분류 문제인지 조립 문제인지 알 수가 없고, 하나를 고치면 나머지가 같이 흔들립니다.
그런데 제 시스템엔 그 딸깍쇼가 애초에 없습니다. 증빙 수취·복호화·초안 생성·번들링 같은 반복 노동은 전부 n8n(자동화 도구)이 하고, 분류는 코드의 룰이 하고, 스킬한테는 판단만 남겨놨습니다. 지결셋업 스킬이 85줄밖에 안 되는 건 덜 쪼개서가 아니라, 쪼개고 남은 알맹이만 스킬이라서입니다. 판단이라는 책임 하나만 남았으니 더 자를 데가 없는 겁니다.
지결 계열 3개가 그렇게 이미 경계가 서 있었고,
ingest-script는 라우터 + 분석 에이전트 + 채점 에이전트로 나뉘어 있었고,
나머지는 전부 100줄 이하 단일 절차라, 쪼개면 오히려 레시피를 토막 내는 꼴이었습니다.
설계를 잘해서라기보다, 위 표의 "태어난 계기" 열을 보면 알 수 있듯이 사고를 겪을 때마다 그 자리에서 하나씩 만들다 보니 처음부터 작게 만들어진 겁니다. 배달이 안 와서 배달 확인이 생겼고, 알림이 거짓말을 해서 대조 절차가 생겼으니, 실패 단위로 생긴 스킬은 이미 실패 단위로 나뉘어 있을 수밖에요.
대신 서랍을 뒤지는 동안 다른 게 눈에 들어왔습니다. 스킬 표준에 "같은 설명을 세 번째 하고 있으면 스킬로 만들라"는 승격 신호를 적어둔 게 있는데, 쪼갤 스킬은 없는 반면 이 신호에 걸리는 절차가 세 덩어리 있었습니다. 전부 스킬이 아니라 에이전트의 메모리 파일 열다섯 개쯤에 흩어져 있어서, 세션이 바뀔 때마다 다시 조립해야 하고, 가끔은 예전에 밟은 함정을 또 밟는 것들이었습니다.
3. 쪼개는 대신 만들었다 — 신설 3종
① 렌즈 깎기 창구. 저는 대본을 채점하는 기준(렌즈라고 부릅니다)을 위키로 관리하는데, "기준으로 평가하기"는 스킬이 있으면서 "기준 자체를 만들고 고치기"는 스킬이 없었습니다. 이 둘은 실패하는 방식이 다릅니다. 평가가 틀리면 그 작품 하나가 틀리고 끝인데, 기준이 틀리면 이후 모든 평가가 같이 틀립니다. 그래서 후보 검증 관문 4개(기존 기준 조합으로 잡히는 건 아닌지 / 작품 2편 이상에서 실측됐는지 / 정답을 보기 전에 기준을 고정했는지 / 수치를 박아도 되는 맥락인지)를 통과/실패로만 판정하게 박고, 기준을 고칠 때 과거 판정이 소급으로 바뀌지 않는지를 diff 0으로 확인하는 절차까지 넣었습니다.
② 재생산 운영. 밤새 돌아가는 대본 재생산(만든 렌즈를 시험하는) 파이프라인이 있는데, 캐시 파일에 에러 메시지가 대신 저장돼서 회차 하나가 이틀을 헛돌았고, 프로세스가 죽었다고 잘못 판정해서 멀쩡히 돌던 러너를 제 손으로 죽인 적도 있습니다. 이런 사고 6건을 "작품 띄우기 전 체크리스트 5개 + 실패했을 때의 진단 분기표"로 굳혔습니다. 막상 만들고 보니 절차 부분보다 이 사고 기록 부분이 분량도 많고 값도 나갑니다.
③ 인시던트 접수창구. "서버가 이상해요"라는 신고는 원인이 네 갈래(파일시스템 / 인증 / 권한 / 자동화 도구)로 갈리고, 갈래마다 진단 명령과 처방이 다릅니다. 기본과제에서 배운 엄브렐라 패턴을 여기 썼습니다. 접수창구만 새로 만들고, 갈래 하나(자동화 도구 진단)는 이미 있던 스킬을 그대로 잎사귀로 매달았습니다. 새 소스를 붙일 때 배달을 새로 안 만들고 기존 배달에 합류만 시켰던 것과 같은 패턴입니다.
신설 3종을 표로 정리하면:
신설 스킬
한 줄 책임
흡수한 것
렌즈 깎기 창구
채점 기준을 만들고 고침 (평가와 분리) — 후보 관문 4종 + 소급 금지
메모리 파일 ~9개의 기준·교훈
재생산 운영
야간 파이프라인의 사전점검 → 가동 → 판정 → 진단 → 편입
밤을 날린 사고 기록 6건
인시던트 접수창구
장애 신고를 실측으로 4갈래 분기 (수리는 갈래 문서·하위 스킬)
복구 절차 4계통 + 기존 스킬 1개 재사용
4. 다 스킬로 만들진 않았다
만드는 중에 욕심이 두 번 생겼습니다.
렌즈 후보를 검증해서 유효하면 편입까지 해주는 것도 스킬로 만들까?
재생산이 끝나면 결과를 바로 위키에 편입하는 것도 스킬로 만들까?
둘 다 새 스킬로는 안 만들었습니다. 첫 번째는 어차피 렌즈 깎기 창구가 할 일이라 그 안에 규칙으로 넣었고, 두 번째는 재생산 운영의 마지막 단계라 거기에 절차로 붙였습니다.
이유는 단순합니다. 실패 원인이 다르면 나누는 게 맞지만, 책임이 같은 걸 스킬만 늘리면 에이전트가 요청을 어디로 보낼지 헷갈릴 표면만 하나 더 생깁니다. 2주차 과제를 하기 전이었다면 아마 신나서 스킬 5개를 만들었을 텐데, 기준이 생기니 "이건 만들 게 아니라 넣을 거네"가 보였습니다.
5. 지아코모님 시스템과 비교해보니
마침 모각때에 지아코모님이 제작 시스템에 2주차 개념을 적용한 사례 자료를 공유해주셨습니다. 읽으면서 잠깐 헷갈렸습니다. 그분은 디자인 총괄 아래 매체별 전문 디렉터를 아홉으로 나누고, 승인도 "기술 통과 / 화면 검증 / 미감 승인 / 발행 결정" 네 겹으로 쪼갭니다. 저는 오늘 하루 종일 안 만들고 합치는 결정만 했는데, 지아코모님은 이렇게 잘게 나누네? 내가 덜 분해한 건가?
한참 보다가 내린 결론은, 기준이 다른 게 아니라 만드는 물건의 모양이 다르다는 거였습니다.
지아코모님 시스템은 아이디어 하나가 영상·발표자료·웹·스토리·게임으로 나갑니다. 매체가 다르면 깨지는 지점도 다릅니다(발표자료는 레이아웃에서, 웹은 화면 크기에서, 영상은 호흡에서 깨집니다). 가로로 넓으니 쪼갤 자리가 많은 겁니다.
제 시스템은 산출 매체가 좁은 대신(문서·표·위키) 파이프라인이 세로로 깁니다. 이런 쪽은 쪼갤 자리가 매체 사이가 아니라 단계와 관문 사이에 있는데, 그건 사고를 겪으면서 이미 나뉘어 있었습니다.
재밌는 건, 그렇게 잘게 나누는 분도 입구는 하나로 받는다는 점입니다. 아홉 디렉터를 전부 부르는 게 아니라 라우터가 접수해서 필요한 것만 고릅니다. 제가 편입 스킬을 따로 안 만든 것과 같은 층의 결정이었습니다. 여기서 §2의 딸깍쇼 얘기가 한 번 더 정리됩니다 — 사용자 입장에서 딸깍 한 번인 건 좋은 겁니다. 위험한 건 입구가 딸깍인 게 아니라 내부가 한 덩어리인 것이고, 그래서 공식은 "입구는 딸깍, 내부는 분해"가 됩니다. 여기는 두 시스템이 똑같았습니다.
6. 덤 — 승인 클릭이 줄었다
편입을 자동화하면서 위임 방식도 손봤습니다. 전에는 렌즈 후보가 나올 때마다 제가 yes/no를 눌러줬는데, 어차피 거의 다 yes였습니다. 그래서 바꿨습니다.
검증 관문을 통과하면 에이전트가 편입까지 마치고 한 줄로 알려줍니다. 백업이 있어서 마음에 안 들면 되돌리면 됩니다.
저한테 물어보는 건 세 경우만 남겼습니다. 수치 기준을 새로 박을 때(작품 반례는 제가 더 잘 아니까), 기존 패턴과 정면으로 모순일 때, 증거가 진짜 반반일 때.
돌아보면 2주차 과제 덕에 가능해진 변화입니다. 경계가 문서로 서 있으니까, 그 경계 안쪽은 맡겨도 불안하지 않게 된 겁니다.
7. 배운 점
쪼개는 기준("실패 원인이 다른가")과 스킬로 승격하는 기준("같은 설명을 반복하고 있는가")은 결국 같은 질문이었다. 분해 과제를 하다가 신설 3개가 나온 이유.
분해가 필요한 신호는 "딸깍쇼"다. 입구가 딸깍인 건 좋은 거고, 내부가 한 덩어리인 게 문제다. 그리고 쪼갠 조각이 꼭 스킬일 필요도 없다 — 반복 노동은 자동화 도구로 내려보내고 스킬엔 판단만 남기는 게 더 좋은 분해였다.
안 만드는 것도 판단이다. 책임이 같은데 스킬 수만 늘리면 라우팅만 흐려진다.
남의 시스템이 잘게 나뉘어 있다고 부러워할 일이 아니다. 매체가 여러 개면 많이 나뉘고, 파이프라인이 길면 관문 사이에서 나뉜다. 내 도메인의 결을 보는 게 먼저다.
스킬에서 제일 값나가는 건 절차가 아니라 사고 기록이다. 절차는 검색하면 나오지만, "에러 메시지가 캐시로 저장돼 이틀을 날렸다"는 내 시스템에만 있다.
덧붙이자면, 오늘 만든 스킬 3종은 아직 실전을 안 겪었습니다. 다음 작품 온보딩과 다음 장애가 각각 첫 시험대가 될 거고, 거기서 깨지는 게 나오면 함정 기록에 한 줄씩 추가하는 것까지가 이 스킬들의 완성입니다.
