AI 산출물은 한 건씩 보지 말고 스무 개를 한 줄로 세워라

오전에 저장소 하나를 열어서 산출물 열여덟 개의 제목만 뽑아 세로로 늘어놨다.

A가 아니라 B였다
A했고 B였다
기대한 것과 결과가 어긋났다

열여덟 개 중 열다섯 개가 이 셋 중 하나였다. 종결 어미까지 세어보니 열일곱 개가 같은 형태였다. 질문형도 명사구도 인용도 없었다.

한 건씩 볼 때는 아무 문제가 없었다. 각각은 검사를 통과했고, 통과 기록도 남아 있다. 검사기가 제목을 안 읽고 있었을 뿐이다.

이 글은 그날 하루 동안 같은 저장소에서 연달아 나온 여섯 가지를 순서대로 적은 것이다. 여섯 개가 다 다른 사고처럼 보이는데, 다시 보면 전부 한 자리에서 나왔다. 설계와 구현과 검증을 다 맡기고 나서 사람이 무엇을 안 봤는가 하는 자리다.

검사기는 본문만 읽고 있었다

이 저장소에는 산출물 문체를 훑는 검사기가 있다. 금지 표현 목록이 열 개 항목으로 나뉘어 있고, 각 항목마다 걸러낼 패턴이 나열돼 있다. 그중 일곱 번째 항목이 이렇게 적혀 있다.

AI 결론형 정형구: 가 아니라 ~다 · 데 있다 · 한 셈이다 · 결국 ~것이다
→ 사실만 쓰고 결론 라벨을 떼면 대개 좋아진다.

그러니까 가 아니라 ~다 는 명시적으로 금지된 문형이다. 문서에 적혀 있고, 이유도 적혀 있고, 대안도 적혀 있다.

발행된 제목 중 셋이 정확히 그 문형이었다.

AX 는 도구를 사는 일이 아니라 권한을 자르는 일이다
깨진 유리창 이론은 마음가짐이 아니라 순찰 인력에서 시작했다
네 번째 리팩토링에서 AI가 아니라 내가 문제였다

검사기가 고장 난 게 아니다. 검사기는 본문 파일을 훑는다. 제목은 파일 맨 위 메타데이터에 있고, 그 영역은 훑는 범위 밖이었다. 규칙은 있었고 실행도 됐는데 산출물의 한 조각이 검사 밖에 있었다.

검사기를 만들 때는 본문이 산출물의 전부처럼 보였을 것이다. 제목은 나중에 붙는 짧은 문자열이니까 검사할 게 없어 보인다. 실제로는 제목이 열여덟 개 중 열여덟 개에 붙고, 목록 화면에서는 제목만 보인다. 읽는 사람이 제일 먼저 만나는 부분이 검사에서 제일 먼저 빠졌다.

여기서 한 가지가 분명해진다. 검사기가 무엇을 훑는지는 만들 때 정해지고, 그 뒤로는 아무도 다시 확인하지 않는다. 산출물의 모양이 바뀌어도 검사 범위는 처음 그대로 남는다.

한쪽이 금지한 걸 다른 쪽이 필수로 요구했다

더 나쁜 게 뒤에 있었다.

같은 저장소의 다른 문서에 제목 작성 규칙이 있다. 제목은 소재와 키워드와 클릭 유인 장치를 조립해서 만들라고 돼 있고, 그 장치의 목록이 다섯 개다. 두 번째가 이렇다.

기존 상식 반박 — ~가 아니다, ~는 필요 없을까, ~보다 더 중요한 것

그리고 그 아래에 이 장치를 하나 이상 필수로 넣으라고 적혀 있다.

한 문서는 가 아니라 ~다 를 금지하고, 다른 문서는 같은 문형을 필수로 요구한다. 두 문서 다 이 저장소 안에 있고, 둘 다 같은 작업에서 읽힌다.

이런 모순이 생기면 사람은 대개 알아챈다. 두 규칙을 같이 읽을 일이 있기 때문이다. 그런데 이 두 문서를 같이 읽은 사람이 없었다. 각각 작성됐고, 각각 그럴듯했고, 각각 검토를 통과했다. 한 번에 하나씩 만들어졌고 한 번에 하나씩 승인됐다.

AI는 두 문서를 다 읽는다. 그리고 둘 다 성실하게 따르려고 한다. 모순이 있으면 어느 쪽이 이기는가.

검사받지 않는 쪽이 이긴다. 제목 규칙은 산출물을 만들 때 적용되고 금지 목록은 만든 뒤에 적용되는데, 그 적용이 제목에는 안 닿았다. 그래서 열여덟 개 중 열다섯 개가 같은 모양으로 나왔다.

여기서 배울 건 문서를 잘 쓰자는 얘기가 아니다. 문서를 늘리면 모순도 같이 는다. 규칙이 다섯 개일 때는 다섯 개를 한 화면에서 볼 수 있지만 스무 개가 되면 못 본다. 문서 두 개가 서로 반대를 말하는 걸 발견하는 방법은 결국 하나뿐이다. 산출물을 보는 것이다. 산출물에는 두 규칙이 부딪힌 결과가 이미 나와 있다.

설계 단계에서 값이 비면 구현이 알아서 정한다

지금까지는 검증 쪽 얘기다. 그런데 이 저장소에서 그날 확인한 것 중 가장 앞단에 있는 건 설계 쪽이었다.

도입부를 어떻게 쓸지에 대한 규칙이 있었다. 네 박자로 잡으라는 것이다.

왜 하려 했는지 → 무엇을 했는지 → 됐다 → 그런데 다른 게 깨졌다

이 구조 자체는 좋다. 실제로 일이 그렇게 벌어지고, 읽는 사람이 따라오기도 좋다. 문제는 이게 필수 조항으로 박혀 있었다는 것이다.

같은 문서의 조금 위에는 "구조를 매번 다르게" 하라는 항목이 있고, 쓸 수 있는 구조가 다섯 가지 예시로 나열돼 있다. 그중 하나가 "결론부터 던지고 왜 그런지 풀어가기"다. 그런데 아래의 필수 조항이 "결과나 결론으로 시작하지 않는다"고 못 박는다. 다섯 개 중 하나가 그 자리에서 죽는다. 나머지 넷도 네 박자 도입을 달고 나면 서로 구분이 안 된다.

설계 문서 안에서 두 항목이 부딪혔고, 강한 쪽이 이겼다. 필수라고 적힌 쪽이다.

값이 비어 있어서 생기는 문제와 값이 하나로 고정돼서 생기는 문제는 방향이 반대인데 결과는 같다. 어느 쪽이든 구현이 매번 같은 답을 낸다. 설계서에 크기가 안 적혀 있으면 구현이 알아서 하나를 고르고, 설계서가 크기를 하나로 못 박으면 구현이 그것만 쓴다. 값이 없어서 생긴 사고는 기획서에 "작게"만 적혀 있었던 건 따로 적었고, 이번 건 반대쪽이다.

설계 단계에서 사람이 봐야 하는 건 항목이 다 채워졌는지가 아니다. 어느 항목이 출력을 하나로 고정하는지다. 그건 문서를 읽어서는 잘 안 보이고 산출물을 열 개쯤 쌓아놓고 봐야 보인다.

통과 신호가 계속 켜져 있으면 사람은 안 본다

왜 이 지경이 될 때까지 아무도 안 봤나. 이게 진짜 질문이다.

설계부터 검증까지 맡기면 각 단계에서 통과 신호가 나온다. 설계 단계에서 문서가 나온다. 읽어보면 말이 된다. 구조가 잡혀 있고 항목이 빠짐없이 채워져 있다. 구현 단계에서 코드가 나온다. 빌드가 통과한다. 검증 단계에서 검사가 돈다. 걸린 항목이 목록으로 나오고, 고치면 목록이 비워진다.

세 단계 전부 초록불이다. 사람이 볼 이유가 사라진다.

이건 게으름이 아니다. 초록불을 보고도 매번 열어보는 사람은 없다. 신호를 만든 이유가 매번 안 열어보려는 것이기 때문이다. 문제는 그 신호가 무엇을 보증하는지를 아무도 다시 확인하지 않는다는 데 있다.

빌드 통과가 보증하는 건 컴파일이다. 검사 통과가 보증하는 건 그 검사가 훑은 범위다. 훑지 않은 범위에 대해서는 아무것도 보증하지 않는데, 초록불은 똑같이 초록색이다. 범위가 좁아도 초록이고 넓어도 초록이다. 신호의 색깔에는 범위가 안 실린다.

그래서 사람이 봐야 하는 건 산출물이 아니라 검사의 범위다. 산출물을 매번 다 읽을 수는 없다. 검사가 무엇을 안 보고 있는지는 한 번 확인하면 되고, 그 한 번이 산출물 스무 개를 읽는 것보다 싸다. 그리고 그 한 번을 아무도 안 한다.

같은 저장소에 다른 규칙도 있었다. 자기 참조를 금지하는 규칙이다. 이 저장소의 자동화 구성 자체를 산출물의 소재로 쓰지 말라고, 이유까지 붙여서 적혀 있었다. 그런데 소개 페이지에는 이 저장소의 자동화 구성을 다루는 항목이 목록으로 걸려 있었고, 본문 한 곳에는 에이전트가 호출한 도구 이름과 횟수가 그대로 나열돼 있었다.

세션 6개, 도구 호출 551회
Bash 207, Edit 168, Write 59, Read 48, WebFetch 33, WebSearch 23

쓸 때는 이게 실측 데이터로 보였을 것이다. 실제로 측정된 값이기도 하다. 그런데 읽는 쪽에서는 에이전트 로그다. 금지 규칙이 있었고 위반이 있었고 그 사이에 아무 검사도 없었다.

검사되지 않는 규칙은 주석이다. 코드에 영향을 주지 않는다.

한 건 검사와 집합 검사는 다른 축이다

여기까지는 검사 범위 얘기다. 범위를 넓히면 해결되는 것처럼 보인다. 제목도 훑고 메타데이터도 훑고 자기 참조도 훑으면 된다.

그런데 범위를 다 넓혀도 안 잡히는 게 하나 남는다.

산출물 하나가 좋은 것과 산출물 스무 개가 서로 다른 것은 다른 문제다.

제목 열여덟 개를 다시 보자. 하나씩 떼어놓고 보면 나쁘지 않다. 깨진 유리창 이론은 마음가짐이 아니라 순찰 인력에서 시작했다 는 읽을 만한 제목이다. 구체적이고, 무엇을 다루는지 알 수 있고, 읽고 싶어진다. 한 건 검사에서 이걸 걸러낼 근거가 없다. 걸러내면 오히려 나쁜 검사다.

열여덟 개를 세로로 세우면 얘기가 달라진다. 열다섯 개가 같은 수사를 쓴다. 그러면 그건 한 사람이 쓴 글의 개성이 아니라 한 틀에서 찍혀 나온 것으로 읽힌다. 개별 품질과 무관하게 그렇게 읽힌다.

도입부도 같았다. 스무 개 중 열 개가 앞에서 말한 그 네 박자였다. 본문에서 전환어 하나만 세어봐도 여든네 번이 나왔다.

좋은 규칙을 필수로 걸면 출력이 하나로 수렴한다. 규칙이 나쁘면 나쁜 게 스무 개 나오고 규칙이 좋으면 좋은 게 스무 개 나오는데, 스무 개가 같다는 사실 자체가 문제가 되는 영역이 있다.

한 건 검사로는 이걸 절대 못 잡는다. 검사기가 보는 입력에 나머지 열아홉 개가 없기 때문이다. 잡으려면 검사가 이전 산출물을 같이 읽어야 한다.

속도도 같이 봐야 한다. 이 저장소의 첫 산출물이 8월 4일이고 오늘이 8월 25일이다. 3주에 스무 개가 나왔다. 손으로 만들면 이 속도가 안 나오고, 속도가 안 나오면 균질해지기 전에 사람이 먼저 질린다. 열 번째쯤에서 "또 같은 걸 쓰고 있네" 하고 스스로 방향을 튼다. 스무 개가 3주 만에 나오면 그 지겨움이 도착하기 전에 스무 개가 이미 나가 있다. 검사 밖에 있는 자리는 산출 속도에 정확히 비례해서 쌓인다.

그리고 여기에 AI 특유의 사정이 하나 더 붙는다. 사람 리뷰어는 지난주에 본 걸 기억한다. 같은 사람이 비슷한 걸 세 번 연속 올리면 세 번째에 "또 이 모양이네" 소리가 나온다. 기억이 집합 검사를 대신 해준다. AI 세션은 매번 새로 시작한다. 이전 산출물이 입력에 없으면 없는 것이고, 열아홉 번을 같은 모양으로 만들고도 스무 번째에서 똑같이 만든다. 사람 팀에서 자연히 생기던 견제가 구조적으로 빠져 있다.

그래서 검사를 하나 새로 만들었다. 산출물의 형태만 세는 것이다. 제목이 무슨 어미로 끝나는가, 특정 수사가 들어 있는가, 도입 세 문단 안에 전환어가 몇 개인가. 그리고 새 산출물을 직전 다섯 개와 대조해서 세 축이 겹치면 반려한다.

돌려보니 이렇게 나왔다.

제목 형태(굵게)   평서문 17편(94%)
제목 반전장치     있음 15편(83%)
[경고] 제목이 '평서문' 하나로 17/18편 쏠려 있다
[경고] 제목 반전·대비 장치가 15/18편. 이게 지문이 된다

이 두 줄은 한 건씩 검사할 때는 나올 수가 없는 문장이다.

그리고 이 검사를 검사기의 맨 앞에 뒀다. 문체 항목을 훑기 전에 먼저 돌린다. 여기서 반려되면 뒤를 볼 이유가 없기 때문이다. 한 건을 아무리 다듬어도 집합이 균질하면 그대로다.

설계 쪽도 같이 되돌렸다. 도입 네 박자를 필수에서 빼고 여섯 유형 중 하나로 내렸다. 장면으로 시작하거나, 결론을 먼저 놓거나, 질문을 던지거나, 남의 문장을 옮기거나, 순서대로 기록하거나. 그리고 직전 다섯 개가 쓴 유형은 못 고르게 했다. 되돌린 뒤 분포는 이렇게 바뀌었다.

제목 형태   명사구 7 · 평서문 7 · 질문형 5 · 명령형 1
반전 장치   3/20   (전 15/18)
도입 전환어 2/20   (전 10/20)

로컬 기록이 진실이라고 가정했다

같은 날 다른 것도 하나 나왔다.

배포 대상 목록을 원격에서 받아 로컬 파일과 대조해봤다. 원격에 스무 개가 있는데 로컬에는 열여덟 개만 기록이 있었다.

두 개가 붕 떠 있었다. 하나는 로컬에 파일은 있는데 배포 식별자가 비어 있었다. 다른 하나는 파일 자체가 없었다. 다른 머신에서 배포됐고 그 결과가 이 저장소로 안 돌아온 것이다.

배포 식별자가 비어 있는 쪽이 특히 나빴다. 이 저장소의 배포 스크립트는 식별자가 있으면 갱신하고 없으면 새로 만든다. 그러니 그 상태에서 배포 명령을 한 번 돌리면 같은 산출물이 하나 더 생긴다. 원격에는 이미 있는데 로컬은 없다고 알고 있으니까. 그리고 새로 만들어진 쪽에 식별자가 기록되니까, 그다음부터는 원본이 영영 갱신되지 않는다.

이건 AI에게 맡겨서 생긴 문제가 아니다. 여러 머신에서 같은 파이프라인을 돌리면 언제든 생긴다. 다만 AI에게 배포까지 맡기면 이 어긋남을 아무도 눈치채지 못하는 기간이 길어진다. 사람이 손으로 배포하면 목록을 보게 되고, 목록을 보면 개수가 안 맞는 게 눈에 들어온다. 명령 한 줄로 끝나면 목록을 볼 일이 없다.

대조는 어렵지 않았다. 원격 목록을 받아서 로컬 식별자 집합과 차집합을 내면 된다. 열 줄이 안 된다. 그 열 줄을 아무도 안 쓴 이유는 쓸 이유가 없었기 때문이다. 어긋난 적이 없다고 알고 있었으니까. 어긋난 적이 없다는 것도 확인한 게 아니라 그냥 그렇게 알고 있었던 것이다.

일괄 수정은 가정 위에서 돈다

제목 열여덟 개를 고치기로 하고 정규식으로 일괄 치환을 돌렸다. 메타데이터의 특정 줄을 찾아서 새 값으로 바꾸는 스크립트다.

열여덟 개 파일이 전부 깨졌다.

메타데이터의 그 항목은 값이 길면 여러 줄에 걸쳐 이어진다. 정규식은 첫 줄만 바꿨고, 이어지던 나머지 줄은 그대로 남았다. 남은 줄들은 갈 곳이 없어져서 파일 전체가 파싱되지 않았다.

발행 전에 파서로 한 번 읽어봐서 잡았다. 잡은 방법이 중요하다. 파일을 열어서 눈으로 본 게 아니라 실제 파서에 넣고 예외가 나는지 봤다. 눈으로 봤으면 못 잡았을 가능성이 높다. 깨진 파일도 화면에서는 멀쩡해 보인다. 줄이 하나 더 있을 뿐이니까.

고친 방법은 정규식을 정교하게 다듬는 게 아니었다. 파서로 읽고, 값을 바꾸고, 파서로 다시 쓰는 것으로 바꿨다. 형식을 문자열로 다루는 걸 그만두면 여러 줄이든 한 줄이든 상관이 없어진다.

AI에게 일괄 수정을 시키면 거의 항상 문자열 치환으로 온다. 빠르고 짧고 대개 맞기 때문이다. 대개 맞는다는 건 가끔 틀린다는 뜻이고, 일괄 수정에서 가끔 틀리면 전부 틀린다. 한 건 고칠 때 문자열 치환은 합리적인 선택인데 열여덟 건을 한 번에 고칠 때는 아니다. 같은 도구가 개수에 따라 위험도가 바뀐다.

고쳤는데 다음 세션에 돌아온다

검사기를 고치고 설계 문서를 고쳤는데 그걸로 끝이 아니었다.

이 저장소에는 규칙이 두 군데 있다. 하나는 작업할 때 읽는 문서고, 다른 하나는 세션이 시작할 때 자동으로 주입되는 메모리다. 도입 네 박자는 양쪽에 다 적혀 있었다. 작업 문서에서 필수 조항을 빼도 메모리에는 그대로 남는다. 그리고 메모리는 다음 세션 첫 줄에서 다시 들어온다.

그러니까 고친 다음 날 같은 규칙이 돌아온다. 산출물은 다시 같은 모양으로 나오고, 왜 그런지는 알기 어렵다. 문서를 고친 기록이 커밋에 남아 있으니 고쳤다고 믿게 된다.

같은 사실이 두 군데 적혀 있으면 하나만 고쳐도 고쳐진 것처럼 보인다. 여기가 사람이 관리하던 시절보다 나빠지는 지점이다. 사람은 규칙을 기억으로 들고 다니니까 원본이 하나다. AI는 매 세션 문서를 다시 읽고, 문서가 여러 개면 여러 개를 다 읽는다. 오래된 사본이 최신 사본을 이길 수 있고, 어느 쪽이 이겼는지는 어디에도 안 남는다.

그래서 메모리 쪽도 같이 고쳤다. 세 파일이었다. 규칙을 고칠 때는 그 규칙이 몇 군데 적혀 있는지부터 세는 게 먼저다.

검사기는 모델이 못 뒤집는 것만 셀 수 있다

이 저장소에는 예전에 문체를 점수로 매기는 게이트가 있었다. 패턴마다 점수를 더해서 백 점 만점을 내고, 기준선을 넘으면 발행을 막는 구조였다.

그 게이트를 없앤 이유가 기록에 남아 있다. 점수와 판정 문자열을 검사받는 쪽이 직접 써서 파일에 남겼기 때문이다. 발행 스크립트는 그 파일에서 "합격"이라는 글자를 찾아서 통과 여부를 정했다. 검문소와 통행증 발급처가 같았다.

이건 AI에게 일을 맡길 때 계속 나오는 모양이다. 검증을 시키면 검증 결과도 같이 만들어 온다. 결과가 그럴듯해서 대개 맞고, 틀렸을 때 티가 안 난다. 테스트를 짜라고 시키면 통과하는 테스트를 짜 오는 것과 같은 일이다.

그래서 새로 만든 검사기는 판단을 안 한다. 어미가 무엇인지 세고, 특정 문자열이 몇 번 나오는지 세고, 분포를 출력한다. 좋은지 나쁜지는 말하지 않는다. 사람이 보고 정한다.

세는 건 모델이 뭐라고 주장해도 안 바뀐다. 평서문 17/18 은 모델이 "충분히 다양합니다"라고 말해도 17/18이다. 이게 게이트로 쓸 수 있는 유일한 종류의 사실이다. 판단이 들어가는 순간 그 판단을 누가 하느냐는 질문이 따라붙고, 답이 "검사받는 쪽"이면 게이트가 아니다.

같은 원리를 그날 한 번 더 썼다. 원격에만 있던 산출물 하나를 회수해서 로컬 형식으로 되돌려야 했는데, 변환이 제대로 됐는지 눈으로 확인하지 않았다. 되돌린 결과를 같은 저장소의 렌더러에 다시 넣어서 원본과 대조했다. 12,692자가 정확히 일치했다.

중간에 표가 한 덩어리로 안 묶여서 깨진 것도 그 대조에서 나왔다. 표의 각 줄이 따로 떨어져서 본문 문단으로 렌더링되고 있었다. 눈으로 봤으면 표가 좀 이상하다고만 생각하고 넘어갔을 것이다. 왕복시켜서 원본과 글자 수까지 맞춰보니 어디서 어긋났는지가 바로 나왔다.

되돌리는 비용은 나중에 청구된다

되돌리는 데 실제로 든 것을 적어둔다.

제목 열여덟 개를 새로 뽑았다. 형태를 명사구와 질문형과 명령형으로 흩고, 메타 설명 열여덟 개도 다시 썼다. 도입은 스무 개 중 열 개를 다시 썼다. 나머지 열 개는 이미 서로 달라서 건드리지 않았다. 그리고 전부 다시 배포했다.

이 정도로 끝난 건 운이 좋았기 때문이다. 이 플랫폼은 주소를 처음 배포할 때 고정하고 제목이 바뀌어도 주소를 안 바꾼다. 만약 주소가 제목에서 파생되는 구조였으면 제목 열여덟 개를 고치는 순간 주소 열여덟 개가 죽는다. 산출물끼리 서로를 가리키는 링크도 같이 죽는다. 세어보니 그런 링크가 여덟 개 있었다.

관찰을 안 한 대가는 만들 때 청구되지 않는다. 만들 때는 오히려 빠르다. 청구는 되돌릴 때 오고, 그때 금액은 산출물 개수에 비례한다. 열여덟 개에서 알아채면 열여덟 개를 고치면 되고, 백 개에서 알아채면 백 개를 고쳐야 한다. 그 사이에 주소나 참조 구조가 제목에 묶여 있으면 개수만큼 곱해진다.

빨리 만드는 이득은 앞에서 받고 안 본 비용은 뒤에서 낸다. 이 둘이 같은 장부에 안 적히니까 앞쪽만 보인다.

세 단계에서 각각 무엇을 안 보고 있나

설계와 구현과 검증을 다 맡기더라도 사람이 봐야 하는 자리는 있다. 산출물 전체가 아니라 각 단계의 덮이지 않은 면적이다.

설계 단계에서는 두 가지를 찾는다. 값이 없는 말과, 값을 하나로 고정하는 말이다. "작게"나 "빠르게"처럼 값이 비어 있으면 구현이 알아서 정하고, 그 값은 나중에 왜 그런지 아무도 모른다. 반대로 "항상 이 구조로"처럼 필수가 붙으면 구현이 그것만 낸다. 설계 문서를 읽을 때 이 두 종류에만 표시를 해도 절반은 잡힌다.

구현 단계에서는 검사기가 훑는 파일 범위를 확인한다. 훑지 않는 확장자, 훑지 않는 디렉터리, 훑지 않는 메타데이터 영역이 어디인지 한 번 적어본다. 이건 검사기 코드를 열면 십 분이면 나온다. 오늘 제목이 걸린 자리가 정확히 거기였다.

검증 단계에서는 통과 조건이 산출물의 어느 부분에 대한 것인지 본다. 빌드 통과는 컴파일에 대한 것이고 검사 통과는 훑은 범위에 대한 것이다. 이 둘을 "괜찮다"로 뭉치는 순간 범위가 사라진다. 그리고 검증 결과를 누가 썼는지 확인한다. 만든 쪽이 썼으면 그건 결과가 아니라 주장이다.

마지막으로 산출물이 열 개쯤 쌓이면 세로로 세운다. 제목만, 첫 문장만, 함수 이름만 뽑아서 한 화면에 놓는다. 한 건씩 볼 때 안 보이던 게 거기서 보인다. 오늘 나온 두 줄짜리 경고는 열여덟 개를 세로로 세우기 전에는 존재하지 않는 문장이었다.

세우는 데 든 시간은 스크립트 한 개와 몇 분이었다. 그 스크립트는 판단을 안 하니까 길지도 않다. 어미를 세고 문자열을 세고 표로 뱉는 게 전부다.

세우지 않은 시간은 3주였고, 그 3주 동안 스무 개가 나갔다.