AI에게 일을 맡기는 순서 — 여섯 단계로 만드는 AI 오케스트레이션

여기서 설명하는 것

AI에게 일을 맡기고 그대로 이어가다 보면 두 가지 문제가 생긴다.

하나 — 잊는다. 대화가 길어지면 앞에서 정한 규칙이 요약되면서 휘발된다. 말하자면 앞부분의 규칙이 쌓이고 접히면서 처음의 규칙이 희미해지는 것이다. 더 중요한 것은 그런 상태를 AI는 스스로 확인할 수 없다는 것이다. AI는 자기가 잊었다는 것도 모르고, 그냥 계속 열심히 결과물을 만들어낸다.

둘 — 통과만 맞춘다. AI가 내놓는 정답은 확률적으로 고른 것이다. 가장 그럴듯한 쪽을 골라 표준이 되는 일반화에 맞춘다. 정확한 확인 요청과 검증을 요구하지 않으면 통과만 맞춘다. 만약 아무런 규약이 없으면 검사는 AI가 정하는 기준 하나뿐이고 결과는 그 검사를 통과하는 쪽으로 기운다. 목표가 희미해지면 자동으로 정확성을 비켜간 표준적인 답을 향해 간다.

그럼 프롬프트를 더 정확하고 정교하게 쓰면 되지 않을까. 실제로 그렇게 해 봤다. 요구사항을 더 촘촘히 적고, 확인할 것을 미리 나열하고, 형식까지 지정해서 넘겼다. 처음 몇 번은 잘 실행된다. 그러다 어느 순간 패턴화되고 다시 어긋난다. 형식은 그대로인데 내용이 표준적인 답으로 돌아가기 때문이다.

그래서 필요한 것은 더 좋은 프롬프트가 아니다. 프롬프트를 규격으로 만들고 대화 밖에 두는 것이다. 대화 안에 적으면 점점 패턴화되면서 규칙을 잊어 간다. 하지만 파일에 적어 필요할 때마다 규칙을 재정의해 주면 AI는 다시 기억을 회복한다. 규칙을 어디에 두고 언제 다시 사용하느냐가 결과의 정확성과 품질을 가른다.

그 순서를 넷으로 나눴다. 용어는 이미 통용되는 것을 그대로 썼다 — 하네스 · 스킬 · RAG · CI. 말은 생소해도 하는 일은 단순하다.

4단계

하네스, 스킬, RAG까지 넣어도 AI는 잊을 때가 있다. 규약을 읽고 시작한 세션에서도 뒤로 갈수록 앞의 규칙이 접힌다. 세 가지 다 AI가 읽고 따르는 쪽에 서 있기 때문이다.

그래서 마지막에 AI에게 달려 있지 않은 것을 하나 추가한다. 그게 CI다. 규칙을 한 번 더 적는 것이 아니다. 규칙을 어겼는지 기계가 확인하고, 어겼으면 통과시키지 않는 검사다. AI가 규칙을 읽었든 잊었든 검사는 실행된다. 앞의 세 가지가 「지켜라」라면 CI는 「지켰는지 본다」다.

1. 하네스 — 어디서 일하나

AI에게 일을 시키려면 먼저 일할 곳을 정해 줘야 한다. 어디까지 들어가도 되고 무엇을 만져도 되는지, 그 경계가 하네스다.

여기서는 저장소 하나로 묶었다. AI는 그 폴더 안에서만 움직이고, 밖으로는 나가지 않는다. 명령줄로 파일을 읽고 고치고 검사를 실행한다. 화면을 클릭하지는 못한다.

경계를 좁게 잡는 이유는 따로 있다. 넓게 열어 두면 AI가 잘못 건드렸을 때 무엇이 바뀌었는지 찾기가 어렵다. 좁혀 두면 바뀐 것이 그 안에만 있다. 되돌릴 수 있는 범위가 곧 맡길 수 있는 범위다.

그리고 경계가 있어야 판단이 갈린다. 폴더 안의 일은 스스로 하고, 밖으로 나가야 하는 일은 물어 온다. 이 선이 없으면 매번 묻거나 아무것도 안 묻거나 둘 중 하나가 된다.

바로 해 볼 것 — 지금 시키려는 일이 폴더 하나 안에서 끝나는지 본다. 안 끝나면 그 일부터 더 작은 일로 나눈다.

2. 스킬 — 반복하는 절차를 파일로

같은 설명을 두 번 하고 있으면 그것은 절차다. 절차는 말로 두지 않고 파일로 만든다(업계 말로 문서화).

① 회차 지시서. 한 회차에 AI에게 넘기는 문서다. 다섯 칸으로 고정해 두었다.

■ 무엇을      바꿀 파일과 값
■ 하지 말 것  손대면 안 되는 경로
■ 완료 판정   기대 숫자 — 하나라도 다르면 멈추고 보고
■ 되돌리는 법 실패했을 때 어디로
■ 보고 형식   [변경] / [근거] / [확인] / [재요청]

셋째 칸이 이 양식에서 가장 중요하다. 완료를 종료 코드로 판정하지 않는다. 스크립트가 실패해도 도구는 오류를 보고하고 정상 종료할 수 있다. 그래서 「됩니다」는 증거가 아니고, 숫자와 명령 출력이 증거다.

이 칸에는 쓰임이 하나 더 있다. 숫자를 못 적으면 그 일은 아직 시킬 준비가 안 된 것이다. 칸이 안 채워지는 것이 첫 신호다. 지시서를 못 쓰겠으면 일이 아직 안 정해진 것이지 AI가 부족한 것이 아니다.

② 3패스 검증. 푸시하기 전에 서로 다른 오류를 잡는 세 번을 실행한다.

1패스  사양 대조   요구사항을 다시 읽고 의도 vs 구현
2패스  기계 검증   빌드(build — 소스를 결과물로 조립)·타입·테스트를 실제로 실행한다
3패스  산출물 회귀  렌더된 결과를 보고, 다른 데가 안 깨졌는지

같은 것을 세 번 보는 것이 아니라 다른 것을 세 번 본다. 같은 눈으로 세 번 보면 세 번 다 통과한다.

바로 해 볼 것 — 지시서 양식은 다섯 칸부터. 「완료 판정」에 숫자를 적을 수 없으면 그 일은 아직 지시할 준비가 안 된 것이다. 그 칸을 못 채우는 것이 첫 신호다.

3. RAG — 매번 먼저 읽히는 것

상용 AI는 학습이 안 된다. 대신 일을 시작하기 전에 읽히는 것은 된다. 새 직원에게 사규를 먼저 읽히는 것과 같다. 그게 RAG다.

앞에서 규칙이 휘발된다고 했는데, 파일에 적는 것이 그 대응이다. 대화 안에 적으면 접히면서 사라지지만, 파일에 적어 두면 매 세션 앞에서 다시 읽힌다.

여기서 읽히는 것은 둘이다.

① 규약 한 장. 저장소 뿌리에 두고 세션마다 자동으로 읽힌다. 담는 것은 다섯이다.

목표      무엇을 위한 프로젝트인가
분기선    무엇을 자율로, 무엇을 물어보고
금지      건드리면 안 되는 것
교훈 로그  같은 실수를 두 번 하지 않기 위한 줄
요약 대응  대화가 요약된 뒤에는 이 파일을 다시 읽어라. 기억이 아니라 이 파일이 규칙이다

분기선을 가르는 기준은 되돌릴 수 있는가가 아니라 뭔가 어긋나고 틀렸을 때 드러나는가다.

기술적인 것은 틀리면 안 돌아간다. 파일 개수가 안 맞거나, 빌드가 멈추거나, 링크가 깨진다. 틀리면 스스로 신호를 내니 여기는 맡겨도 된다.

반대로 「이 작업이 내가 시킨 뜻대로 가고 있는가」는 틀려도 바로 안 드러난다. 예를 들어 글에 출처를 붙이라고 시켰다고 하자. AI는 그럴듯한 문서를 찾아 링크를 단다. 링크는 열린다. 그런데 그 문서를 열어 보면 글에서 인용한 문장이 없다. 비슷한 말이 있어서 AI가 그것을 원문인 것처럼 옮긴 것이다. 또 다른 경우로, 두 절이 겹친다고 판단해 하나로 합쳤는데 실은 세기가 다른 두 단계였던 일도 있다. 어느 쪽이든 파일은 저장되고 빌드는 통과하고 화면도 멀쩡하다.

이때 이 과정을 판단할 수 있는 사람은 작업 지시자뿐이다. 작업이 맞는 방향으로 가고 있는지는 일을 계획하고 시킨 사람만 안다. AI는 자기가 뜻을 벗어났는지 확인할 방법이 없다. 이 부분은 AI에게 맡기지 않는다.

교훈 로그가 이 한 장에서 가장 값을 하는 칸이다. 사고가 났을 때 「다음부터 조심한다」로 끝내지 않고 여기에 한 줄을 남긴다. 그 줄이 다음 세션에서 먼저 읽힌다.

② 결정 기록 폴더. 뒤집힌 결정부터 한 건에 한 장씩 남긴다. 왜 그렇게 정했는지가 적혀 있으면 다음 세션이 같은 것을 다시 논의하지 않는다.

바로 해 볼 것 — 먼저 규약 한 장을 만든다. 한 장이다. AI는 긴 글을 요약해서 읽기 때문이다. 짧고 단정적인 문장 몇 개면 충분하다. 왜 그 규칙을 정했는지 이유와 경위는 결정 기록을 따로 만들어 거기로 넘긴다. 규약은 매번 읽히니 짧아야 하고, 결정 기록은 필요할 때만 찾으니 길어도 된다.

4. CI — 잊어도 작동되는 검사

앞의 세 가지는 AI가 지키기로 한 것을 지키는 동안만 작동한다. 규약은 안 읽으면 효력이 없고, 지시서는 안 따르면 효력이 없다. 여기까지는 전부 AI의 협조에 기대고 있다.

CI는 다르다. AI가 기억하든 기억을 못하든, 읽어도 읽지 않아도 작동된다.

이 글에서 검사는 기계가 자동으로 실행해 통과·실패로 답하는 것을 말한다. 업계에서 체크(check)라 부르는 것이고, 코드가 기대한 값을 내는지 보는 테스트(test)와 실패하면 병합을 막는 게이트(gate)를 함께 이른다. 사람이 눈으로 보는 것은 확인이라고 쓰고, 검사를 하는 프로그램은 검사기라고 쓴다.

여기까지 오는 데 시간이 걸렸다. 처음에는 규칙을 대화에 적었다. 몇 번은 지켜지다가 대화가 길어지면 사라졌다. 그래서 파일에 적었다. 세션마다 읽히니 잊는 일은 줄었다. 그런데 읽고도 안 지키는 일이 남았다. 「지어내지 마라」고 적어 두었는데 지어냈다. 데이터를 검사하는 프로그램을 만들라고 했더니, 답안지를 그 프로그램 안에 넣어 두고 자기 출력을 자기 답안지와 대조했다. 그 검사를 다시 검사하는 프로그램은 검사 대상의 코드를 그대로 가져다 써서, 대상이 놓친 것을 똑같이 놓쳤다. 규칙이 약해서가 아니라, 규칙이 AI의 손에 있었기 때문이다.

그때 알았다. 문장은 AI가 읽고 지켜야 효력이 난다. 안 읽었거나 읽고도 안 지키면 아무 일도 안 일어난다. 오류도 없고 멈추지도 않는다. 결과물만 보면 그 줄을 안 적은 것과 같다. 필요한 것은 더 좋은 문장이 아니라, AI가 무엇을 하든 실행되는 것이었다.

그래서 검사로 바꿨다. 회차가 시작될 때 커밋(commit — 저장소에 남기는 변경 한 묶음) 번호를 적어 두고, 끝날 때 검사 파일이 든 폴더가 그 커밋과 달라졌는지 비교하는 명령을 추가했다. 이 명령은 AI가 무엇을 했든 실행된다. 결과는 통과 아니면 실패다. 지키라고 부탁하는 것과 어겼는지 자동으로 드러나게 만드는 것의 차이가 여기서 갈린다.

처음 추가한 검사가 이 한 줄이었다. 성능이 좋아서가 아니라 가장 만들기 쌌기 때문이다. 명령 한 줄이면 되고, 파일 안에 무엇이 적혔는지 알 필요도 없다. 바뀌었는지만 본다. 그리고 이 한 줄이 뒤에 생길 검사를 전부 지킨다. 검사를 고쳐서 통과시키는 길을 먼저 막아 두지 않으면, 그 뒤에 쌓는 검사는 언제든 무를 수 있다.

정교한 검사부터 만들려다 보면 아무것도 못 만든다. 한 줄짜리라도 먼저 실행되는 것이 낫다. 나머지 검사는 미리 세우지 않았다. 사고가 나면 교훈 로그에 한 줄 남기고, 같은 사고가 또 나거나 기계로 잴 수 있는 것이면 그때 검사로 내렸다. 검사는 규칙에서 나온 것이 아니라 실패에서 나왔다.

① 감시자 무결성. 회차 전후로 검사 폴더가 바뀌었는지 본다. 검사 폴더에는 테스트, 게이트, 결정 기록이 들어 있다. 세 가지 다 「무엇이 맞는가」를 정해 둔 파일이라, 이것이 바뀌면 기준이 바뀐 것이다.

git diff --quiet <시작커밋> -- tests/ checks/ decisions/  ||  실패

한 줄이다. 회차가 시작될 때 커밋 번호를 적어 두고, 끝날 때 그 커밋과 지금의 검사 폴더를 비교한다. 파일 하나라도 달라졌으면 실패다. 이 한 줄이 가장 위험한 일을 막는다 — 검사를 고쳐서 통과시키는 것. 그건 통과가 아니다. 대상이 아니라 기준을 바꾼 것이다.

그래서 AI에게는 이렇게 지시한다. 「게이트를 고쳐야 한다고 판단되면 고치지 말고, 보고의 [재요청] 칸에 적고 그 일은 그대로 둔 채 다음 작업으로 가라.」 이러면 AI는 검사를 고치는 대신 사람에게 물어 온다.

② 기준선. 새 검사를 만들면 기존 글과 파일이 무더기로 걸린다. 검사를 만든 사람은 대개 여기서 포기한다. 걸린 것을 다 고치기 전에는 검사를 못 켜기 때문이다.

이때 검사를 고치지 않는다. 지금 걸린 개수를 세어 기준선 파일 하나에 적어 두고, 검사는 「그 수보다 늘었는가」만 본다. 지금 걸린 것은 아는 문제로 두고, 새로 생기는 것만 막는 것이다.

걸린 개수는 저절로 줄지 않는다. 하나 고칠 때마다 하나 준다. 늘지만 않으면 방향은 맞다.

이때 걸린 것을 「3번째 항목」처럼 번호로 적으면 안 된다. 항목 하나만 앞에 끼워 넣어도 뒤 번호가 전부 밀려 목록 전체가 어긋난다. 대신 걸린 문장 자체나 그 문장으로 만든 해시값처럼, 순서가 바뀌어도 같은 것을 가리키는 표시로 적는다.

③ 음성 시험. 마지막이자 가장 자주 빠지는 것이다.

이름이 오해를 부르기 쉬우니 먼저 밝힌다. 음성 시험은 AI가 스스로 실행하는 자체 검사다. 사람이 시험지를 만들어 주는 것이 아니다. 「음성(陰性)」은 의학 검사에서 쓰는 그 말로 — 이상 없음이다. 고장을 일부러 심어 놓았는데도 검사가 「이상 없음」이라고 하면 그 검사는 사용해선 안 된다. 고장 난 것을 고장이라고 하는지를 보는 것이 음성 시험이다.

고장을 일부러 심고 검사가 실패하는지 확인한다.
고장 다섯을 심었는데 넷만 잡히면 그 검사는 못 쓴다.

검사를 새로 넣을 때마다 음성 시험을 실행했다. 그리고 두 번 뚫렸다.

한 번은 검사 항목 하나를 통째로 빼 놓았는데도 검사가 통과시켰다. 항목이 빠져도 문항 수 19가 앞뒤로 맞아떨어졌기 때문이다. 다른 한 번은 변형 100개 중 무작위로 다섯 번만 뽑아 본 검사가, 뽑히지 않은 변형에 심은 오류를 두고 「이상 없음」이라고 했다. 일부만 보는 검사는 자기가 무엇을 안 봤는지 말하지 않으면 뚫린다.

그래서 방식을 바꿨다. 전부 한 번씩 보게 하고, 못 본 것이 남으면 그것 자체를 실패로 보고하게 했다. 직접 망가뜨려 보지 않았으면 이 구멍을 몰랐을 것이다.

바로 해 볼 것 — 회차를 시작할 때 커밋 번호를 적어 둔다. 회차가 끝나면 위의 한 줄을 실행한다. 자동으로 하려면 커밋마다 실행되도록 설정한다. 그다음 음성 시험 한 번 — 검사 폴더의 파일 하나를 일부러 고치고 그 한 줄이 실패로 나오는지 본다. 실패로 안 나오면 검사가 잘못 설정된 것이다.

작동되면 무슨 일이 벌어지나

넷이 다 설정된 상태에서 이 프로젝트의 한 회차가 실제로 진행된 순서다.

1. 회차 지시서를 준다. 스킬 절의 ①에서 말한 그 문서다. 기대 숫자가 적혀 있다.

2. AI가 받고 먼저 센다. 파일이 몇 개인지, 지시서가 말한 수와 맞는지. 다르면 여기서 멈추고 보고한다. 이 단계에서 멈춘 적이 실제로 있다. 지시서에 적은 수가 틀렸던 것이고, AI가 세지 않았으면 틀린 숫자를 기준으로 작업이 진행됐을 것이다.

3. 3패스를 실행한다. 사양 대조 → 빌드·테스트 → 산출물 확인.

4. 완료 판정을 대조한다. 지시서의 기대 숫자와 실측을 나란히 적는다. 하나라도 다르면 멈춘다.

5. 화면은 사람이 확인한다. 이 단계는 AI가 못 한다. 명령줄 도구는 페이지를 클릭할 수 없다. 그래서 지시서에 「이 단계는 사람이 한다」를 적어 둔다. 적어 두지 않으면 AI가 그것을 자기 일로 받고 헛돈다. 실제로 한 번 그랬다.

6. 커밋하고 푸시한다. 병합은 사람이 한다. 푸시(push)는 내 커밋을 공용 저장소에 올리는 것이고, 브랜치(branch)는 본줄기와 따로 두는 작업 줄기다. 브랜치에 있는 동안은 아직 공개되지 않은 것이다. 그것이 이 체계의 안전망이다.

그래서 무엇이 잡히고 무엇이 안 잡히나

가장 정직한 결과부터 적는다. 게이트가 잡은 것은 여러 구간에서 0건이었다. 잡은 것은 명령줄 AI 도구와 사람이었다. 도구가 잡은 것은 위의 2번 같은 숫자 불일치였고, 사람이 잡은 것은 아래 같은 것들이다.

그 0을 처음 깬 것도 게이트가 아니었다. AI가 옮겨 적는 과정에서 한글을 깨뜨렸는데, 그것을 드러낸 것은 되읽기가 아니라 편집 도구였다. 고칠 대상 문장이 한 글자라도 다르면 편집을 거부하는 도구여서, 깨진 글자 때문에 편집이 실패하면서 손상이 드러났다. 엄격한 일치를 요구하는 인터페이스는 공짜 검사다. 다만 우연히 그렇게 된 것이라 새로 만드는 글에서는 대조할 원본이 없어 그대로 통과한다. 우연에 기댄 검사는 검사가 아니다.

기계가 못 잡는 것은 대체로 같은 모양이다 — 형식은 정상인데 내용이 틀린 것. 「무수정 원문」이라 표시된 글이 실제로는 요약본이었거나, 링크는 열리는데 엉뚱한 곳으로 가거나, 검사는 통과하는데 화면에서는 기능이 죽어 있거나.

그렇다고 게이트가 쓸모없는 것은 아니다. 게이트는 숫자와 형식을 지키고, 사람은 내용을 본다. 게이트가 없으면 사람이 숫자와 형식까지 봐야 하고, 그러면 내용을 볼 시간이 없어진다.

검사를 통과했다는 것은 최소한을 넘겼다는 뜻이지 잘 됐다는 증거가 아니다. 그래서 「검사가 무엇을 보지 않는지」를 적어 두지 않으면 통과가 보증으로 잘못 읽힌다.

사용해 볼 수 있는 순서

한 번에 다 만들 필요는 없다. 파일 3개와 검사 1개로 시작할 수 있다.

프로젝트/
├── 규약.md              한 장. 목표 · 자율/호출 분기선 · 금지 · 교훈
├── 결정/                뒤집힌 결정부터 한 건에 한 장
├── 검사/                게이트. AI는 여기를 고치지 않는다
└── 지시서-이번회차.md   다섯 칸. 완료 판정에 숫자

처음에 할 것 넷.

1. 규약 한 장. 분기선 한 문단이면 시작된다 — 무엇을 맡기고 무엇을 물을 것인가.
2. 감시자 무결성 한 줄. 검사 폴더가 바뀌었는지 보는 것.
3. 지시서 다섯 칸. 「완료 판정」에 숫자를 적어 본다. 못 적으면 그 일은 아직 지시할 준비가 안 된 것이다.
4. 음성 시험 한 번. 고장을 하나 심고 검사가 실패로 나오는지 본다.

하지 말 것 세 가지.

• 규칙을 대화에만 남기는 것 — 사라진다.
• 검사에 걸렸을 때 검사 쪽을 고쳐 통과시키는 것 — 대상이 아니라 기준을 바꾼 것이다.
• 「됩니다」를 완료로 받는 것 — 증거는 숫자로 요구한다.

이 프로젝트에서는

하네스 (harness). 모델을 감싸는 실행 계층이다. 모델 자체는 텍스트를 생성할 뿐이고, 파일 입출력·셸 실행·검색 같은 도구 호출, 어떤 도구를 자율로 쓰고 어떤 것은 승인을 받는지 정하는 권한 정책, 컨텍스트와 상태 관리, 계획→실행→검증으로 도는 실행 루프, 오류 처리를 하네스가 맡는다. 명령줄에서 도는 AI 에이전트 도구가 곧 하네스다. 여기서는 — 작업 폴더를 저장소 하나로 고정했다. 상위 폴더의 옛 사본은 접근이 안 되게 막았다. 파일 삭제와 강제 푸시는 실행 전에 사람에게 묻게 했다. 잘못 고쳐도 회차 시작 커밋으로 되돌아간다.

스킬 (skill). 특정 작업 유형에 대한 재사용 가능한 절차 패키지다. 입력 규칙, 처리 순서, 쓸 도구, 출력 형식, 검증 규칙을 한 파일로 묶어 두고, 그 유형의 일이 올 때만 컨텍스트에 읽어 들인다. 프롬프트가 「이것을 해라」라면 스킬은 「이 유형의 일은 이 절차로」다. 매번 읽히지 않으므로 길어도 된다. 여기서는 — 회차 지시서 양식과 3패스 검증이 파일로 있다. 이번 회차가 「글 5편의 related 칸 채우기」라면 완료 판정에 「빈 related 0건, 글마다 2개 이상」처럼 숫자를 적는다. AI는 끝나고 grep -c 결과를 붙여 보고한다. 「됐습니다」는 보고가 아니다.

RAG (Retrieval-Augmented Generation, 검색 증강 생성). 생성 앞에 검색 단계를 두는 파이프라인이다. 문서를 조각으로 분할하고, 각 조각을 임베딩해 벡터 저장소에 넣고, 질문이 오면 유사도가 높은 조각을 검색해 컨텍스트에 넣은 뒤 생성한다. 모델이 학습한 것이 아니라 지정한 자료를 근거로 답하게 하는 방법이다. 여기서는 검색기 없이 좁게 썼다 — 저장소 뿌리의 규약 한 장은 세션마다 자동으로 컨텍스트에 들어가고, 결정 기록 폴더는 필요할 때 파일 이름으로 찾아 읽는다. 규약에 「자율: 되돌릴 수 있고 검증 가능하고 합의 범위 안 / 호출: 판단·취향·범위 변경」 분기선이 있어서, AI가 글 제목을 바꾸고 싶어지면 범위 변경이라 사람에게 묻고, 파일 개수 맞추기는 검증 가능하니 그냥 한다.

스크립팅 (scripting). 반복하는 작업을 스크립트로 만들어 두고 필요할 때 실행하는 것이다. 세는 것, 규칙 위반을 찾는 것, 일괄로 고치는 것, 절차를 건너뛰지 못하게 막는 것 네 가지가 여기 들어간다. 실행하는 주체는 사람이고, 그 점이 다음 단계와 갈린다. 여기서는 — 사람이 명령으로 실행하는 것만 여기 두었다. RVP 리터러시 검사기가 문항 100변형을 순서대로 전부 한 번씩 훑고, 훑지 못한 변형이 남으면 그 사실 자체를 실패로 보고한다. 회차마다 필요한 것은 그때 만들어 한 번 쓴다 — 폐기하기로 한 표현이 다섯 편에 몇 군데 남았는지 세는 스크립트, 글끼리 문장이 얼마나 겹치는지 재는 스크립트가 그것이다. 자동으로 실행돼야 하는 것만 다음 단계로 넘겼다.

CI (Continuous Integration, 지속적 통합). 소프트웨어 개발에서 온 말이다. 저장소에 변경이 들어올 때마다 빌드와 테스트가 자동으로 실행되고 통과/실패로 판정되는 파이프라인이다. AI 시스템에서는 프롬프트나 규칙을 바꿀 때마다 정해 둔 시험 세트를 돌리는 평가 파이프라인으로 이어진다. CI가 하는 일을 여기서는 AI의 작업을 검사하는 데 썼다 — 커밋이 올라올 때마다 검사가 자동으로 실행된다. 감시자 무결성은 검사 폴더가 바뀌면 실패. 기준선은 새 검사에 기존 글 40편이 걸렸다면 「40」을 적어 두고 41이 되면 실패. 음성 시험은 이 자동 실행에 들어 있지 않다. 검사를 새로 만들 때 사람이 고장을 일부러 심어 직접 돌려 보는 것이고, 그렇게 해서 검사기 자체의 구멍이 드러났다.

파인튜닝 (fine-tuning). 이미 학습된 모델에 사례를 더 학습시켜 판단 방향을 바꾸는 것이다. 문장으로 적기 어려운 문체나 판단 기준을 다루는 데 쓰고, 사실을 넣는 용도가 아니다. 사실은 매번 먼저 읽히는 파일에 둔다. 여기서는 — 한 번 실행했고 학습되지 않았다. 20억 개 규모의 공개 모델에 사례 20쌍을 붙여 15단계를 돌렸다. 학습이 진행되고 있음을 보여 주는 수치는 내려갔지만, 학습에 넣은 질문을 그대로 물어도 원래 모델이 하던 말이 나왔고, 모델은 RVP라는 약어를 제멋대로 다른 뜻으로 풀어 냈다. 원인은 세 가지였다 — 사례가 20쌍뿐이었고, 학습 강도를 권장값의 4분의 1로 잡았고, 반복 횟수가 모자랐다. 지금은 학습을 멈추고 사례만 모으고 있다. 5호가 데이터셋을 만드는 데까지만 다루는 이유가 이것이다.

AI 오케스트레이션 (orchestration). 여러 AI와 도구를 하나의 흐름으로 엮어 조율하는 것이다. 위 여섯을 다 쌓으면 그 흐름이 만들어진다 — 어디서 일하고, 무엇을 먼저 읽고, 무엇을 실행하고, 어디서 막히고, 무엇을 배우는지가 이어진다. 여기서는 — 지금 구축하고 있다. 1호부터 5호까지가 그 다섯 단계이고, 다섯을 다 쌓은 것이 이 흐름이다. 이 글들이 그 과정에서 나온 순서와 양식이다.

이 체계가 못 하는 것

이 체계는 AI가 알면서 어기는 것을 막지 못한다. 모르고 어기는 것은 더더욱 막지 못한다.

하는 일은 하나다 — 어겼을 때 눈에 보이게 하는 것. 분모 없는 숫자, 조회 없는 단정, 근거 없는 번복. 전부 눈으로 잡을 수 있는 형태다.

음성 시험도 내가 상상한 고장만 잡는다. 사람이 화면을 보는 절차는 대체되지 않는다. 아직 다른 방법을 알지 못하기 때문이다. 여기까지가 이 체계의 전부이고, 그 이상은 나도 아직 찾는 중이다.

이 글의 범위

• 개인이 개인의 한정된 저장소에서 실행한 결과다. 다른 규모·다른 도구에서도 서는지는 재지 않았다.
• 「게이트가 잡은 것 0건」은 여러 구간의 실측이지 전 구간의 집계가 아니다.
• 검사 항목의 구체값(개수·임계·판정 기준)은 프로젝트마다 다르다. 이 과정은 각 상황에 따라 다시 달라진다. 여기서 가져갈 것은 어디에 무엇이 왜 필요한지뿐이다.