The posts on this blog are written in Korean. There is no English version. Open the Korean page
체계에 자리가 없던 재료와 스킬 13종의 빈칸
도구에는 값이 없어야 하고 작품 저장소는 작품만 담는다. 여러 작품이 다시 쓰는 재료가 갈 자리가 없어서 쓰는 사람이 체계 밖에 폴더를 만들었고, 그 폴더는 어느 검사도 보지 않았다.
Published 1 view
TL;DR
- 도구는 값을 안 갖고 작품 저장소는 작품만 담는다. 여러 작품이 다시 쓰는 재료가 갈 자리가 없었다
- 자리가 없으니 쓰는 사람이 밖에 폴더를 만들었다. 그 폴더는 v1.22.0 까지 어느 문서에도 없었다
- 스킬을 13종에서 14종으로 늘리고 세 번째 저장소 층을 규정했다. 경로도 형식도 안 정했다
- 쓰는 사람이 체계 밖에 만든 폴더는 규약의 한 층으로 올리고, 위치가 아니라 찾는 순서를 적는다
증상
체계에 자리가 없는 것은 사라지지 않는다. 쓰는 사람이 밖에 만들고 그때부터 아무도 검사하지 않는다.
웹소설 집필용 플러그인을 만들고 있다. 이 도구가 관리하는 저장소는 둘이었다. 도구 자신과 작품이다. 도구에는 값이 없어야 하고 작품 저장소에는 그 작품만 들어간다. 경계가 분명해 보였다.
그런데 쓰는 사람이 따로 관리하던 폴더가 하나 더 있었다. 여러 작품에서 다시 쓰는 것들이다. 클리셰, 통념, 성격 표현, 말투 예시. 그 폴더는 어느 문서에도 안 적혀 있었다.
적혀 있지 않으니 규칙도 없었다. 작품을 하나 기획할 때 그 폴더를 열고 다른 작품을 시작할 때 또 연다. 어느 쪽이 정본인지 정해 둔 적이 없다. 같은 클리셰를 두 작품이 따로 모았고, 그 사실을 한참 뒤에 알았다.
검사도 그 폴더를 안 봤다. 이 저장소에는 파일 계약을 보는 검사가 여럿 있는데, 전부 도구와 작품 두 층만 안다. 규약에 없는 층은 검사 대상 목록에도 없다.
반전
처음에는 이것을 모델이 모르는 지식의 문제로 봤다. 재료를 주면 되는 일이라고 생각했다.
체계가 자리를 안 만든 것이 원인이었다. 빠진 자리는 셋이었다.
저장소 층이 셋인데 규약은 둘만 알았다. 문서 첫 장이 저장소를 분리하라고 말하는 동안, 정본으로 인정한 것은 도구와 작품뿐이었다. 사람이 만든 저장소는 목록에 없었다. 위치도 없고 합의도 없었다.
재료가 없을 때 무엇을 할지가 없었다. 그래서 두 갈래로 갈렸다. 조용히 새로 만들어 버리거나, 아무 말 없이 지나가거나. 앞엣것은 작가 모르게 창작을 시작한다. 뒤엣것은 재료가 있는 줄 모르고 진행한다. 둘 다 나쁜데 둘 다 규약 밖이었다.
같은 말이 두 층을 가리켰다. 이 도구 안에서 소재는 이야기의 소재다. 사람이 만든 폴더의 이름도 소재였는데 그 안에는 인물 부품이 들어 있었다. 이름이 겹쳐서 어느 쪽을 말하는지 문장만으로는 못 갈랐다.
근거
쓰는 사람이 체계 밖에 폴더를 만들었다면, 그 폴더가 체계의 빈칸을 가리킨다. 사람이 게을러서 밖에 둔 것이 아니다. 안에 둘 자리가 없어서 밖에 둔 것이다.
이 경우 증거는 폴더 자체였다. 이름이 이미 있었고 내용이 이미 쌓여 있었고 여러 작품이 이미 그곳을 보고 있었다. 규약만 그것을 몰랐다.
처리
세 번째 저장소를 공식으로 올렸다. 경계는 이렇게 적었다.
도구 이 플러그인. 값을 하나도 갖지 않는다
작품 회차 원고와 작품 바이블. 여러 개가 된다
재료 여러 작품이 다시 쓰는 것. 보통 하나다
스킬을 하나 더해 13종에서 14종이 됐다. 이야기 소재와 인물 부품을 찾는 자리다. 층의 경계를 적은 문서를 따로 두고 그것을 정본으로 삼았다. 기존 스킬 둘에는 포인터만 넣고 내용을 복제하지 않았다.
경로를 정하지 않는 것이 이 판의 중심이었다. 다른 사람 기기에 그 경로가 있을 이유가 없다. 경로를 고정하면 없는 기기에서 빈 곳을 읽고 그 빈 곳을 재료가 없다는 뜻으로 보고한다. 그래서 위치 대신 찾는 순서를 정했다.
- 지금 작업하는 저장소의 형제 저장소를 본다
- 환경변수를 본다
- git 이 알고 있는 저장소 목록을 본다
- 못 찾으면 작가에게 한 번 묻는다
2번과 3번은 읽기만 한다. 없는 경로를 만들어 넣지 않는다.
형식도 정하지 않았다. 값 파일과 규칙 파일이 나뉘어 있든, 문서 하나에 절로 나뉘어 있든, 데이터베이스든 읽는다. 형식을 정의하면 그 정의가 두 번째 정본이 되고 그때부터 재료와 규격이 따로 낡는다.
값은 하나도 넣지 않았다. 이 저장소에 값이 들어오는 순간 도구가 아니라 보관소가 된다. 공개하면 남의 작품 재료가 함께 나간다.
커맨드를 더하지 않았다. 스킬 하나에 커맨드 하나를 짝지으면 관리할 것이 두 배가 된다. 커맨드가 할 일은 스킬 첫 절에 넣었다.
기존 스킬 둘에 붙인 것은 포인터 한 줄씩이다. 재료를 찾는 방법을 그 스킬 본문에 옮겨 적지 않았다. 옮겨 적으면 같은 설명이 세 곳에 살고 한 곳만 고쳐지는 날이 온다. 이 저장소는 그런 사본으로 이미 한 번 갈라진 적이 있다.
검증
검사를 돌렸더니 이번 변경과 상관없는 것이 먼저 걸렸다.
스킬 수를 문장에 박아 둔 자리가 12개 파일 18줄이었다. 13종이라고 적힌 곳이 그만큼 있었고 전부 고쳐야 했다. 그중 한 곳은 이미 틀려 있었다. 스킬이 13종이던 시절에 12개라고 적힌 제목이다. 개수를 세는 문장을 잡는 검사가 있고 이 파일도 그 대상이다. 목록도 제목 바로 아래 같은 파일에 있었다. 그런데 안 걸렸다.
숫자가 제목 맨 앞에 있어서다. 그 검사는 제목 맨 앞의 수를 개수가 아니라 절 번호로 읽고 선언째로 버린다. '14개 스킬 한 줄 요약' 을 '스킬 14개 한 줄 요약' 으로 낱말 둘만 바꾸면 같은 제목이 잡힌다. 세는 쪽은 정확한데 무엇을 세라는 선언인지 가리는 어림이 자리로 되어 있었다.
설명문이 서로를 가로채는지도 다시 쟀다. 스킬이 늘면 기존 발화가 새 스킬로 넘어갈 수 있다. 실제로 그랬다. 성격이 갑자기 바뀐 것 같다는 발화는 인물 진단으로 가야 하는데 새 스킬이 받았다. 발화 다섯 개를 더 넣고 가로채기를 당한 기존 둘은 문구를 비켜 써서, 발화 118개에서 기준선(6)이 안 올라가는 것을 확인했고 실제 모델로 스킬이 뜨는지 보는 케이스도 하나 더했다.
개선
| 전 | 후 | |
|---|---|---|
| 규약이 아는 저장소 층 | 2 | 3 |
| 스킬 | 13종 | 14종 |
| 재료가 없을 때의 처리 | 규약에 없음 | 없는 것은 실패가 아니라고 명시 |
| 스킬 수가 박힌 낡은 문장 | 18줄 | 3줄 (검사가 안 보는 자리) |
남은 것
- 재료 저장소가 있는 집과 없는 집이 갈린다. 없는 쪽이 정상이고 그 상태를 규약에 적었다. 적지 않으면 없는 작가에게 같은 것을 두 번 묻는다
- 작품은 열 개가 될 수 있고 재료 저장소는 보통 하나다. 작품마다 따로 두는 쪽도 막지 않았다. 어느 쪽을 기본값으로 할지는 정하지 않았다
- 형식을 안 정했으니 읽는 쪽이 매번 구조를 추측한다. 그 비용이 얼마인지는 아직 안 쟀다
- 낡은 숫자가 세 줄 남았다. 스킬 본문의 '12개 스킬 전부 유효', 스크립트 설명문의 '13개 스킬', 그리고 목록이 12행인데 제목만 14로 올린 자리다. 셋 다 지금 검사가 안 보는 형태라 손으로 세야 하고, 손으로 세는 것은 다음에 또 빠진다. 검사를 고치는 쪽이 먼저다
다음부터
쓰는 사람이 체계 밖에 폴더를 만들어 쓰고 있으면, 그 폴더를 규약의 한 층으로 올리고 위치가 아니라 찾는 순서를 적는다. 규약이 모르는 층은 검사 대상 목록을 만들 때 아무도 후보로 올리지 않는다.
선언을 알아보는 규칙이 자리나 꼴로 되어 있으면 그 자리를 비켜 쓴 선언은 검사 밖에 있다. 통과는 그 사실을 안 알려 준다.