AI는 "했습니다"라고 말한다

배포본에서 특정 폴더를 빼야 할 일이 있었다. 시키면 금방 된다. 파일 한 줄을 고치고, "제외했습니다"라는 답이 돌아온다. 실제로 고쳐진다. 여기까지는 아무 문제가 없다.

문제는 그 다음이다. 삼 주 뒤에 다른 작업을 하다가 그 줄을 건드릴 수 있다. 다음 판을 빌드하면서 설정을 되돌릴 수도 있다. 새 세션의 AI는 그 결정을 모른다 — 대화는 세션이 끝나면 사라지니까. 그리고 나도 잊는다.

def test_original_music_never_ships():
    assert 'MUSIC' not in B.RUNTIME_DIRS

두 줄이다. 이게 하는 일은 버그를 잡는 것이 아니다. 내가 내린 결정이 아직 그대로인지를 묻는 것이다. 누가 되돌리면 — 내가 되돌려도, AI가 되돌려도 — 시험이 깨진다. 조용히 넘어가지 않는다.

문서는 낡고, 시험은 깨진다

"그러면 문서에 적어 두면 되지 않나" 싶다. 나도 그렇게 했다. 별도 점검 문서를 만들어 무엇을 왜 그렇게 두었는지 적었다.

그 문서의 머리글과 본문이 서로 어긋난 적이 있다. 머리글에는 "아직 하나가 남았다"고 적혀 있었고, 정작 본문의 항목표는 전부 완료로 바뀌어 있었다. 작업이 진행되는 동안 표만 고치고 머리글을 안 고쳤기 때문이다.

문서는 사실과 어긋나도 아무 일이 일어나지 않는다. 시험은 어긋나면 빨간불이 켜진다. 이 차이가 전부다.

결정을 붙잡는 시험 다섯

1. 배포에 무엇이 실리는가

들어가면 안 되는 폴더가 배포 목록에 없는지, 들어가야 하는 고지 파일은 실려 있는지를 시험이 확인한다. 빌드 스크립트는 앞으로도 계속 손보게 되는 파일이라, 여기가 제일 먼저 흐트러진다.

2. 걷어낸 것이 돌아오지 못하게

쓰지 않는 자료를 attic/ 으로 옮기고, 옮긴 목록을 moved.json 에 남겼다. 그리고 그것들이 다시 배포에 실리면 깨지는 시험을 붙였다. 옮기는 것은 한 번이지만, 돌아오지 않게 하는 것은 계속이다.

3. 소리를 잊으면 깨진다

효과음을 새로 만들어 넣으면서, 코드가 부를 수 있는 소리 이름을 소스에서 긁어내 실제 음원과 대조하는 시험을 썼다. 새 장면을 붙이고 소리를 빼먹으면 시험이 깨진다.

쓰다 보니 뜻밖의 것이 잡혔다. 코드가 부르는데 애초에 파일이 없던 소리가 하나 있었다. 특정 조건을 만족하면 울려야 하는 효과음이 여태 무음이었던 것이다. 찾으려고 만든 시험이 아닌데 찾아졌다.

4. 눈금을 숫자로 정해 둔다

게임 안의 설명 문안을 전부 새로 썼다. 문제는 "충분히 다르게 썼는가"를 어떻게 확인하느냐다. "괜찮아 보인다"는 판정 기준이 될 수 없다. 그래서 숫자로 정했다 — 최장 공통 부분문자열과 4-그램 자카드 유사도에 각각 눈금을 두고, 그 아래인지를 시험이 재게 했다.

이렇게 두면 AI에게 "좀 더 다르게 써 줘" 같은 애매한 부탁을 할 필요가 없다. 판정은 시험이 한다. 나는 눈금만 정한다.

5. 산출물의 계약

배포 파일이 어떤 형식이어야 하고 어떤 것이 들어 있어야 하는지를 시험으로 못박았다. 빌드는 성공했는데 결과물이 틀린 경우가 가장 잡기 어렵다. 빌드가 스스로 "성공"이라고 말하기 때문이다.

기능을 묻는 시험, 약속을 묻는 시험

지금 이 프로젝트에는 자동 시험이 1,202개 있다. 대부분은 흔한 시험이다 — 값이 맞게 나오는가, 경계에서 안 터지는가.

그런데 적잖은 수가 성격이 다르다. 그것들은 코드가 맞게 도는지를 묻지 않는다. 내가 정한 것이 아직 그대로인지를 묻는다. 앞의 다섯 가지가 다 그렇다.

AI와 일할 때 이 종류가 특히 필요해진다. 사람과 일하면 "그건 지난번에 정했잖아"가 통하지만, 매번 새로 시작하는 상대에게는 통하지 않는다. 남는 것은 코드와 시험뿐이다. 그러니 기억해야 할 것을 시험에 적어 두는 편이 낫다.

말하자면 시험은 나와 AI 사이의 계약서가 아니라, 미래의 나와 미래의 AI를 향해 써 둔 각서다. 지키지 않으면 즉시 알려 주는 각서.