AI에 작업을 시킬 때 지시서를 자기완결로 쓰는 법

에러도 없이 아무것도 안 만들어졌습니다

별도 환경에서 도는 AI 워커에 작업을 하나 맡겼습니다. 로그를 보니 실패한 곳이 없었습니다. 예외도 없고, 빨간 줄도 없고, 워커는 얌전히 결과를 하나 돌려줬습니다. 그런데 그 결과가 산출물이 아니었습니다. “이런 걸 쓰면 될 것 같습니다” 하는 설명문이었습니다. 만들어야 할 물건 대신, 그 물건을 어떻게 만들면 좋을지에 대한 감상이 돌아온 셈입니다.

뒷단은 그 결과를 형식 검증에서 걸러 버렸습니다. 기대한 형식이 아니었으니까요. 검증이 그걸 버리면서 결과적으로 아무것도 만들어지지 않았습니다. 에러 하나 없이, 산출물도 없이. 저는 한참을 로그만 들여다봤습니다. 어디서 터졌는지 찾으려고 했는데, 애초에 터진 데가 없었으니 찾을 수가 없었습니다.

원인은 워커가 볼 수 없는 경로였습니다

원인은 시시할 만큼 단순했습니다. 지시서가 외부 경로를 참조하고 있었습니다. “저 폴더의 그 문서를 참고하라”는 식으로요. 문제는 워커가 도는 자리가 샌드박스라는 점입니다. 제 손 안에서는 멀쩡히 보이는 그 경로가, 워커가 서 있는 자리에서는 아예 존재하지 않았습니다.

여기서 사람과 모델이 갈립니다. 사람에게 “저기 그 문서 보고 하세요”라고 했는데 그 문서가 안 보이면, 사람은 되묻습니다. “그 문서가 어디 있죠? 안 보이는데요.” 되물음이 곧 안전장치입니다. 그런데 모델은 되묻지 않았습니다. 접근에 실패했다고 에러를 올리는 대신, 추론으로 빈칸을 메웠습니다. 참고 문서가 대충 이런 내용이겠거니 상상하고, 그 상상을 바탕으로 “이렇게 하면 될 것 같습니다”를 써 내려간 겁니다.

그래서 실패가 조용했습니다. 모델은 자기가 자료를 못 봤다는 사실조차 결과에 담지 않았습니다. 겉보기엔 성실하게 답을 한 것처럼 보이는 게 오히려 함정이었습니다.

지시서를 자기완결로 만드는 네 가지

같은 실수를 반복하지 않으려고 지시서 쓰는 방식을 네 가지로 정리했습니다.

첫째, 참고 자료는 경로로 넘기지 않고 지시서 본문에 인라인으로 붙여넣습니다. “저 문서 참고”가 아니라, 그 문서 내용을 지시서 안에 그대로 옮겨 담습니다. 워커가 볼 수 없는 곳을 가리키지 않는 게 핵심입니다.

둘째, 출력 형식을 첫 글자 단위까지 못박습니다. 예를 들어 “첫 글자는 반드시 이 기호로 시작한다, 서두 설명을 붙이면 안 된다”처럼 여지를 남기지 않습니다. 모델이 친절을 부려 앞에 인사말이나 해설을 덧붙이는 순간, 뒷단 검증에서 통째로 버려지기 때문입니다.

셋째, “외부 파일·저장소에 접근할 수 없다, 아래 내용만 사용하라”는 조건을 지시서 안에 대놓고 적습니다. 모델이 추론으로 빈칸을 메우는 걸 막으려면, 빈칸이 있으면 메우지 말라고 미리 말해 두는 게 낫습니다.

넷째, 뒷단을 고쳤습니다. 형식이 안 맞는 결과가 오면 조용히 폐기하지 않고, 실패로 기록하고 알림을 냅니다. 조용한 폐기가 이 사고의 마지막 공범이었습니다. 검증이 결과를 버리면서 아무 소리도 내지 않았으니, 저는 뭔가 잘못됐다는 사실조차 늦게 알았습니다.

기준은 하나입니다

지시서 품질을 보는 기준을 하나로 줄이면 이렇게 됩니다. 이 문서 하나만 들고, 아무 맥락 없는 사람이 결과를 만들 수 있는가. 만들 수 있으면 자기완결인 지시서입니다. 못 만들면 모델도 못 만듭니다.

다만 사람과 모델의 결정적인 차이가 여기 있습니다. 사람은 못 만들겠으면 못 만들겠다고 말합니다. 모델은 못 만들어도 못 만들었다고 말하지 않습니다. 그럴듯한 무언가를 대신 내놓습니다. 그러니 지시서를 쓸 때는 언제나 사람 기준으로 검사해 두는 편이 안전합니다. 사람이 통과하는 문서는 모델도 통과하고, 사람이 걸리는 문서는 모델이 조용히 사고를 냅니다.

이번 일로 저는 “참고하라”는 말을 지시서에서 거의 지웠습니다. 참고할 것이 있으면 지시서 안으로 가져오고, 가져올 수 없으면 그 작업은 애초에 워커에게 안 맡깁니다.

---

혼자 서비스를 만들며 이런 조용한 실패들을 어떻게 막았는지, 회고와 함께 뉴스레터로도 정리해 보내고 있습니다. 비슷한 문제를 겪고 계신다면 구독으로 남겨 두셔도 좋겠습니다.