반복하는 일을 도구로, 그 도구는 AI가 만들게

이번 단계에서는

앞 단계에서 절차를 파일로 만들고 규칙을 먼저 읽혔다(절차를 파일로, 규칙을 먼저 읽히게). 그래도 안 되는 것이 하나 남는다. 세는 일(count)이다.

세는 일이란 이런 것이다. 글이 몇 편인지, 그중 related 칸이 빈 것이 몇 편인지, 링크가 몇 개고 그중에서 깨진 것이 몇 개인지, 테스트가 몇 개 통과하고 몇 개 실패했는지. 판단의 근거가 되는 숫자를 확인하는 일이다.

숫자를 세려면 먼저 어디에 있는지 찾아야 한다(find). 세는 것은 개수를 내고, 찾는 것은 위치를 낸다. 「빈 칸이 12개」가 세기라면, 「12개가 이 파일들의 이 줄에 있다」가 찾기다. 도구도 따로 만든다.

그리고 고치는 일(fix)이 있다. 찾아낸 것을 일괄로 바꾸는 작업이다. 글 40편의 같은 칸을 한 번에 채우거나, 잘못 들어간 값 열 곳을 한 번에 되돌리는 것.

3단계는 이 세 가지를 실행되는 스크립트로 작성하는 것이다(자동화, automation — 사람이 반복하던 작업을 기계가 실행하게 만드는 것).

이 글에서 도구는 AI에게 만들게 한 스크립트 하나를 말한다. 명령 한 줄로 실행되고, 데이터를 읽어 숫자나 목록이나 통과·실패를 내놓는다. 사람이 매번 다르게 하던 판단 기준을 코드에 적어 고정하는 것이 이 스크립트가 하는 일이다. 앞 글에서 말한 하네스(AI를 감싸는 실행 환경)와는 다른 것이다.

코드를 쓸 줄 몰라도 된다. 구체적인 문장만 만들 수 있다면 도구를 만드는 것도 AI를 통해 바로 만들 수 있다.

차례로 지시문 4개를 만들었다. 각 조건에 맞게 사용하는 AI에 넣어 보면 된다. 사용 시 상황과 작업에 맞게 내용을 직접 고쳐 사용한다. 내용을 작업에 맞게 수정 보완하면서 어떤 조건이 왜 붙어 있는지, 또 조건을 빼 보면 무엇이 작동되지 않는지도 바로 보일 것이다. 그렇게 하고 있는 작업 상황과 원하는 작업 스타일대로 고쳐 가면 된다.

언제 필요한가

같은 숫자를 반복해서 세고 있는데, 셀 때마다 값이 다를 때.

손으로 센다는 것은 폴더를 열어 파일 개수를 눈으로 헤아리거나, 편집기의 찾기 기능으로 걸린 줄 수를 읽거나, AI에게 「빈 칸이 몇 개인지 봐 줘」라고 물어 답을 받는 것이다. 세 가지 다 세는 기준이 그때그때 정해진다. 빈 문자열만 셀 것인지 칸 자체가 없는 것도 셀 것인지, 초안 폴더도 포함할 것인지가 매번 다르다. 그래서 같은 데이터인데 값이 달라진다.

앞 단계까지는 문서로 해결된다. 세는 일은 안 된다. 같은 값이 나와야 하는 것은 도구로 만든다. 도구는 기준이 코드에 적혀 있어서 다음에도 같은 기준으로 센다. 한 번 만들어 두면 그 뒤로는 작업량도 준다.

3단계부터는 시간이 든다. 그래서 1·2단계로 해결되는 일을 여기로 가져오지 않는 것이 이 순서의 절반이다. 위 신호가 안 보이면 아직 여기가 아니다.

도구는 4가지뿐이다

만들다 보면 도구가 늘어나는데, 하는 일은 4가지로 나뉜다.

만드는 순서도 이 순서다. 집계부터 만든다. 현황 숫자가 흔들리면 다른 판단이 전부 그 위에 얹히기 때문이다.

지시문 1 — 집계 스크립트 (count)

아래 조건으로 스크립트를 하나 만들어라. 언어는 이 폴더에서 이미 쓰는 것으로 골라라.

■ 무엇을   이 폴더의 데이터에서 다음 숫자를 세어 출력한다
           (셀 항목을 여기에 나열한다)
■ 출력     한 줄에 하나. 「이름 = 숫자」 형식. 표나 설명 없이 숫자만
■ 하지 말 것
           원본 파일을 고치지 마라. 읽기만 해라
           못 세는 항목을 0으로 채우지 마라. 「미상」으로 표시해라
■ 완료 판정
           같은 데이터로 두 번 실행해 출력이 글자 하나까지 같아야 한다

만들고 나서 두 번 실행해 결과를 붙여라.

마지막 두 줄이 이 지시문에서 가장 중요하다. 집계 스크립트의 값은 정확함이 아니라 매번 같은 값이 나오는 것이다. 손으로 셀 때 값이 흔들리는 것이 여기로 올라온 신호였으므로, 흔들리지 않는지를 완료 판정에 넣는다.

「0으로 채우지 마라」도 빼면 안 된다. 못 센 것이 0으로 들어가면 그 0이 다음 판단의 근거가 된다. 미상은 미상으로 남아야 눈에 걸린다.

바로 해 볼 것 — 지금 손으로 세고 있는 숫자 하나를 고른다. 이 지시문의 「셀 항목」에 그 하나만 적어 던진다. 두 번 실행해 값이 같은지 본다.

지시문 2 — 린터 (find)

아래 조건으로 검사 스크립트를 하나 만들어라.

■ 무엇을   이 데이터에서 다음 규칙을 어긴 것으로 「보이는」 것을 찾는다
           (규칙을 한 줄에 하나씩. 한 줄로 안 써지면 두 줄로 나눈다)
■ 출력     후보 목록만. 어느 규칙에 걸렸는지 규칙 번호를 함께 적는다
■ 하지 말 것
           ★ 고치지 마라. 판정하지 마라. 후보를 올리기만 해라
           확실한 것만 올리려고 걸러내지 마라. 애매한 것도 올려라
■ 완료 판정
           일부러 규칙을 어긴 줄을 하나 넣고 실행해서 그 줄이 잡히는지 본다

지시문 안의 ★ 줄이 가장 중요하다. 나머지는 요구사항이고, ★는 빼면 도구가 다른 것이 되는 조건이다. 린터가 판정까지 하면 잘못 판정한 것을 찾아내는 데 시간이 더 든다. 목록을 훑는 것보다 판정을 뒤집는 것이 오래 걸리기 때문이다. 린터는 후보를 내고, 그 후보를 고칠 것인지는 사람이 정한다.

「애매한 것도 올려라」는 반대로 보이지만 필요하다. 도구가 알아서 걸러내기 시작하면 무엇이 걸러졌는지 사람이 모른다.

지시문 3 — 마이그레이션 스크립트 (fix)

원본을 고치는 것은 되돌리기 어렵다. 백업·적용·검증 세 단계로 고정한다.

아래 조건으로 일회용 수정 스크립트를 만들어라.

■ 무엇을   아래 목록의 대상만 지정한 값으로 바꾼다
           (대상을 고유한 키로 지정해 나열한다. 「~인 것 전부」로 적지 않는다)
■ 반드시 세 단계로 만들어라
   백업  원본을 날짜 붙은 사본으로 복사한다
   적용  키로 찍은 대상만 바꾼다
   검증  바꾼 줄을 다시 읽어 출력한다. 못 찾은 키는 「없음」으로 표시한다
■ 하지 말 것
           문자열을 찾아 바꾸지 마라. 반드시 키로 지정해라
           못 찾은 키를 조용히 건너뛰지 마라
■ 완료 판정
           바꾼 줄 수 = 목록의 개수. 「없음」이 하나라도 있으면 멈추고 보고

「문자열을 찾아 바꾸지 마라」를 빼면 되돌릴 수 없는 손상이 난다. 키(key — 설정 파일에서 값에 붙은 이름)로 지정하지 않고 글자로 찾아 바꾸면, 같은 글자가 본문이나 예시 코드에 들어 있는 곳까지 함께 바뀐다. 그리고 몇 군데를 바꿨는지 스크립트가 세지 않으므로 어디가 바뀌었는지 나중에 알 수 없다. 키로 지정하면 그 키가 없는 파일에서 「해당 키 없음」이 바로 나온다.

검증 단계가 없으면 스크립트는 아무것도 변경하지 않아도 종료 코드 0으로 끝난다. 앞 단계의 「완료는 종료 코드가 아니라 숫자로 판정한다」가 여기서도 같다.

지시문 4 — 게이트 (gate)

게이트는 앞의 세 가지와 하는 일이 다르다. 세지도 고치지도 않고, 정해진 절차를 마치기 전에는 다음으로 못 넘어가게 막는다.

아래 조건으로 표시 도구를 하나 만들어라.

■ 무엇을   대상 하나를 지정하면, 그 대상에 대해 판단에 필요한 것을
           한 화면에 전부 띄운다
           (띄울 것을 나열한다 — 원문 · 근거 전부 · 지난 판정 · 미확인 기록)
■ 출력     잘라내지 마라. 요약하지 마라. 있는 그대로
■ 하지 말 것
           앞부분만 보여 주고 「이하 생략」 하지 마라
■ 완료 판정
           가장 긴 대상 하나로 실행해서 끝까지 나오는지 본다

만든 뒤 규약 파일에 한 줄을 넣어라 —
「판단을 시작하기 전에 이 도구를 먼저 실행한다.」

이 도구는 사고에서 나왔다. 원문이 손 닿는 곳에 있는데 요약본으로 판단한 것이다. 한 회차에 원문 6건을 옮기면서, 원래 말한 곳에서 글자까지 확인한 것은 1건뿐이었다. 나머지는 앞 회차의 마감 보고에 인용된 문장을 그대로 가져왔다. 그 과정에서 AI가 쓴 표현이 사람의 인용부호 안으로 들어온 것이 1건, 인용 범위가 옮겨진 것이 1건 있었다. 글자는 맞는데 누가 한 말인지가 바뀐다. 글자를 대조하는 검사로는 이것이 안 잡힌다.

적용된 사례가 중요하다. 「다음부터 조심한다」가 아니라, 이 과정을 실행하지 않으면 다음 작업을 진행할 수 없게 만들었다. 그러면 규칙은 회차가 지나면 사라지고 도구는 남는다.

도구는 실패에서 태어난다

미리 설계하지 않는다. 사고가 나면 그 사고를 막는 도구를 하나 만든다.

설계한 도구는 안 쓰이고, 사고에서 나온 도구는 매번 쓰인다. 그래서 도구 목록을 먼저 만들지 않는다.

도구가 작동하는지 확인하는 법

만든 도구가 실제로 잡아내는지 시험한다. 앞 글의 음성 시험과 같다 — 일부러 고장을 심는다.

고장을 미리 섞는다. 그러면 도구는 문제점을 드러낸다. 이렇게 새 도구를 만들 때마다 이 과정을 실행한다.

3단계가 못 하는 것

도구는 내가 경험하고 상상한 범위에서만 고장을 잡을 수 있다. 내가 상상 못 한 결함은 애초에 도구로 구현하기 어렵다. 하지만 상상은 작업을 계속 하다 보면 커진다. 감이 생기고 검증을 계속 하다 보면 뭐가 문제인지 금방 발견한다.

AI는 많은 일을 줄여 주고 도와주지만 검증이나 확인을 스스로 생각해서 하지 않는다. 시키면 실행하지만 먼저 실행하지는 않는다. 그래서 도구를 실행시키는 주체는 언제나 사람이다. 그리고 이런 도구를 만들어 두는 것과 실행하는 것은 다르다. 만들었으면 실제 작업에서 써 봐야 하고, 자주 써 봐야 어떤 일에 어떤 도구를 꺼내는지 감이 생긴다. 만들어 놓고 바쁘다고, 이 정도는 안 봐도 안다고 건너뛰면 꼭 건너뛴 회차에서 사고가 난다. 그러니 도구가 있어도 실행되지 않으면 없는 회차와 같다.

다음 단계로 가는 신호가 여기서 나온다.

• 도구는 있는데 실행하는 것을 잊어서 사고가 났다 → 4단계. 검사가 사람 없이 실행되게 만든다

이 글의 범위

• 개인이 자기 저장소에서 실행한 결과다. 팀이나 다른 규모에서 어떻게 작동되는지는 확인하지 못했다
• 지시문의 조건은 일마다 다르다. 이 과정은 각 상황에 따라 다시 달라진다. 여기서 얻을 정보는 어디에 무엇이 어떻게 필요한지를 아는 것뿐이다
• 언어와 실행 환경을 적지 않았다. 그 선택은 이미 쓰고 있는 것을 따르는 편이 낫고, 도구는 이 글보다 빨리 바뀐다