위임하는 법
품앗이가 AI와 함께 일하며 남긴 실패 기록을 다른 조직이 다시 쓸 수 있게 옮긴 글입니다. 묶음 전체는 AI와 일하는 원칙에서 볼 수 있습니다.
요지
AI가 다른 AI에게, 또는 사람이 AI에게 일을 맡기는 일이 잦아졌습니다. 맡긴 일이 틀어질 때 원인은 맡은 쪽보다 맡긴 쪽에 있는 경우가 많았습니다. 원본을 보지 않고 쓴 지시문, 앞 단계를 확인하지 않고 보낸 다음 단계, 맡겨 놓고 고친 원본이 그랬습니다. 이 노드는 맡기기 전, 맡기는 동안, 맡긴 뒤에 볼 것을 적습니다. 맡기기 전에 「왜」를 적는 법은 왜부터 적는다에 있습니다.
1. 이미 돌아가는 모양을 그대로 옮긴다
새 기계에 접속 문을 내야 했을 때, 우리가 이미 매일 쓰는 구조가 있었는데도, 그것을 두고 컨테이너와 네트워크를 새로 엮는 설계를 따로 짰습니다. 돌아가고 있는 구조는 이미 실증된 설계입니다. 함정도 다 밟아 봤고 문서도 있습니다. 「이 환경은 다르니까」라는 말은 대개 그 환경을 덜 조사했다는 뜻입니다. 새로 설계하는 것은 기존 모양이 그 자리에서 왜 안 되는지가 실제로 재서 막혔을 때만입니다.
이 원칙을 코드에만 적용하고 절차에는 적용하지 않은 일도 있었습니다. 서버 코드는 해시까지 같게 옮겼는데, 로그인 토큰을 넘겨주는 절차는 새로 짰습니다. 이미 있던 스크립트와 기록을 읽지 않은 탓입니다. 절차, 로그인 방식, 안내문도 같은 칸입니다. 정본이 있으면 정본을 먼저 읽고, 막혔을 때도 새 길을 만들기보다 정본으로 돌아갑니다.
다만 「모양을 옮겨라」가 「쓰는 사람을 다시 보지 마라」는 뜻은 아닙니다. 옮긴 뒤에는 그 자리에서 쓰는 사람이 열었을 때 원하는 것이 보이는지 확인합니다. 이 이야기는 「끝났다」를 무엇으로 판정하나의 「되는가만 재면 빈 화면이 통과한다」에 있습니다.
2. 지시문은 원본을 보고 쓴다
매출 엑셀이 가로형(상품이 행, 날짜가 열)이었는데, 지시문은 세로형이라고 전제하고 썼습니다. 지시문을 받은 AI는 지시문에 없는 가장 큰 작업을 스스로 만들어 내다가 결함을 남겼습니다. 헤맨 결과는 맡은 쪽 잘못으로 보이지만, 원인은 지시문입니다. 그 지시문은 받는 쪽에게 「파일 구조를 추측하지 마라」고 시키고 있었습니다.
원격 기계에 보내는 지시문은 그 기계에 붙어 상태를 재 본 뒤에 씁니다. 「아직 없다」고 전제하고 「가장 작은 판부터 띄워라」를 시킨 적이 있습니다. 실제로는 완성판이 이미 돌면서 답을 하고 있었습니다. 받은 AI는 지시대로 잘 돌던 봇을 내렸습니다.
백업을 떴다면 지시문을 쓰기 전에 그 백업을 읽습니다. 백업을 뜨는 것은 손이 하는 일이고, 읽는 것은 눈이 하는 일입니다. 어느 파일을 원본으로 삼을지는 파일 이름이 아니라 지금 돌고 있는 본문과 대조해서 정합니다. 개수는 기억이 아니라 백업에서 셉니다.
3. 나눠 보내는 지시는 앞 단계를 확인하고 보낸다
사무실 PC에서 저장소를 만드는 「가」 단계와 노트북에서 그것을 받는 「나」 단계로 나눈 지시 가운데 「나」만 보내진 일이 있었습니다. 「가」는 한 번도 실행된 적이 없었습니다. 다음 단계를 보내기 전에 앞 단계의 산출물이 실제로 있는지 잽니다. 「관리자가 먼저 할 일」이라는 절도 체크리스트로 다룹니다.
맡은 쪽이 막혀서 물어 오면 그 사람이 말한 증상만 풀지 않습니다. 그 뒤 단계에서 걸릴 자리까지 미리 짚어 줍니다.
4. 맡겨 놓고 원본을 고치면 지시가 거짓말이 된다
배포와 화면 검증을 동시에 맡긴 사이에 원본을 네 번 고쳤습니다. 검증을 맡은 쪽은 그 시점 파일을 따로 떠서 고정해 놓고 검증하며 「편집이 끝났다고 알려 주시면 최종본으로 다시 보겠다」고 했습니다. 배포를 맡은 쪽은 「CSS만 고쳤다」는 지시와 달리 본문 한 줄이 지워진 것을 찾아내고 배포를 멈췄습니다.
위임 지시는 그 순간의 파일 상태에 대한 진술입니다. 그러니 맡기기 전에 편집을 끝내고, 맡긴 뒤에 바뀌면 바로 알립니다. 확정본을 넘길 때는 파일 크기나 해시를 같이 줍니다.
여러 조직이 함께 보는 문서나 바깥으로 나가는 문서는, 맡기기 전에 담을 뼈대를 서너 줄에서 여섯 줄로 먼저 보여 주고 방향을 잠급니다. 방향이 잠기기 전에 긴 작업을 맡겨 버리면, 지켜보던 사람이 보탤 수 있는 방법은 중간에 끊는 것밖에 남지 않습니다.
5. 맡은 쪽의 보고를 믿지 말고 실물로 닫는다
무거운 작업을 맡은 하위 AI가 그 일을 다시 또 다른 하위 AI에게 넘기고, 36초 만에 「진행 중」이라고 보고했습니다. 맡긴 쪽은 파일이 없는 것을 보고 「아무것도 안 했다」고 잘못 판단해 직접 편집에 들어갔습니다. 아직 살아서 일하던 하위 AI와 같은 파일을 동시에 고칠 뻔했습니다. 완료 알림을 받으면 파일을 확인하고, 아직 돌고 있는 하위 작업이 있는지도 같이 확인합니다. 구조적으로 할 수 없는 단계, 예를 들어 화면이 없는 환경에서 눈으로 보는 검증을 일정에 넣고 기다리지 않습니다.
반대로 보고가 「대기 중」 한 줄로 비어 있었는데, 직접 재 보니 작업은 정확히 되어 있었습니다. 보고가 비었다고 작업이 실패한 것은 아니니, 다시 시키기 전에 실물을 잽니다. 위임을 닫는 것은 맡긴 쪽의 일입니다. 지시에 「백그라운드 작업 금지, 마지막 메시지에 실제 검증 결과를 붙일 것」을 넣었더니 보고가 제대로 돌아오기 시작했습니다.
맡겨 놓고 내버려 두지도 않습니다. 오래 걸릴 일은 맡겨 두고 그사이 다음 일을 준비합니다. 시작할 때 걸릴 시간을 알리고, 큰 제작물은 쪼개서 맡깁니다. 「완료」 알림이 온 뒤에도 그 AI가 띄운 프로세스가 남아 바깥 서버를 계속 두드리고 있을 수 있습니다.
저장하는 순간 바로 라이브가 되는 앱도 있습니다. 디스크의 파일을 그대로 읽어 화면에 내는 자체 호스팅 앱이 그렇습니다. 이런 앱에서는 「배포는 안 했다」는 보고를 믿지 말고, 서비스가 실제로 읽는 경로와 실제 주소로 확인합니다. 이런 앱의 일을 맡길 때는 「저장하면 바로 라이브」라는 사실을 지시에 적습니다.
6. 지시문 자체를 시험한다
같은 지시문을 서로의 결과를 못 보게 한 채 두 AI에게 동시에 줘 봤습니다. 두 결과가 같은 실패를 하면 그것은 지시문 탓입니다. 한쪽만 봤다면 그 AI 탓으로 돌렸을 것입니다. 지시문을 지나치게 충실하게 따른 쪽에서 원본 문서의 구멍이 드러나기도 했습니다. 원본에 있던 내부 참조 표현을 글자 그대로 옮겨 온 것입니다. 같은 결과물을 두 개 얻으려는 것이 아니라 지시문을 검사하려고 하는 일입니다.
정의를 고쳤다고 AI가 그것을 읽고 일한다는 보장은 없습니다. 하위 AI의 역할 정의에 특정 도구를 쓰라는 줄을 넣고, 고친 시각을 기준으로 그 전과 후의 실행을 나눠 그 도구를 쓴 비율을 셌습니다. 0%에서 80%로 정확히 그 시각에 갈렸습니다. 정의가 먹히는지는 이렇게 비율로 증명합니다. 같은 AI를 부르는 통로가 여럿이면 통로마다 따로 확인합니다. 이미 돌고 있던 작업은 옛 정의로 끝까지 갑니다.
7. 역할을 나눴으면 나눠 맡기고, 검증은 남이 한다
여러 AI에게 역할을 나눠 맡겨 놓고 「간단하니까 내가 하지」 하며 혼자 처리한 일이 있습니다. 비용을 아끼는 것 같지만 나눈 역할을 죽이는 일입니다. 한두 줄 고치기나 조회는 직접 하고, 새 페이지, 긴 코드, 문서, 기획, 검증은 담당에게 맡깁니다.
만든 쪽이 검증하면 늘 「잘했다」가 나옵니다. 그래서 계획, 실행, 검증, 되먹임을 서로 다른 담당이 맡게 했습니다. 일의 크기에 따라 가볍게, 보통으로, 깊게 형식을 조절해서 형식만 남는 일을 막습니다.
패키지 교체나 API 버전 변경 같은 기술 전환은 본 코드에 바로 넣지 않습니다. 따로 마련한 환경에서 기본 호출, 시스템 지시, 여러 차례 주고받기, 핵심 기능의 네 단계를 통과한 뒤에 넣습니다. 코딩 규칙은 매번 작업 지시에 싣지 않고, 코드를 짤 때만 읽는 파일로 따로 둡니다. 단순하게, 필요한 곳만 고치고, 목표에 맞춰서가 그 내용입니다.
8. 자기가 들어 있는 시스템은 밖에서 고친다
AI가 들어 있는 컨테이너의 운영체제를 그 안에서 업그레이드하면, 업그레이드 과정이 AI 작업의 부모 프로세스를 다시 시작합니다. 손이 중간에 끊기고 설정이 반쯤 된 상태가 남습니다. 이럴 때는 실행 위치를 밖으로 뺍니다. 바깥 기계의 임시 서비스에서 컨테이너의 내부 공간만 빌려 업그레이드를 돌립니다. 이것은 일을 남에게 넘기는 것과 다릅니다. 같은 AI가 서 있는 자리만 바꾸는 것입니다.
이때 끝난 작업의 기록을 자동으로 지우는 옵션은 쓰지 않습니다. 기록이 지워지면 판정 명령이 기본값인 「성공」을 돌려주는데, 실제로는 실패했을 때도 그렇습니다. 되돌릴 수 없는 단계일수록 판정의 근거를 남겨 둡니다.
처방 정리
- 새로 설계하기 전에 이미 돌아가는 모양을 옮깁니다. 코드뿐 아니라 절차와 안내문도 그렇습니다.
- 지시문은 원본 파일과 그 기계의 현재 상태를 직접 본 뒤에 씁니다.
- 나눠 보내는 지시는 앞 단계 산출물이 있는지 확인하고 다음 단계를 보냅니다.
- 맡기기 전에 편집을 끝내고, 확정본에는 크기나 해시를 붙입니다.
- 바깥으로 나가는 문서는 뼈대를 먼저 보여 주고 방향을 잠근 뒤 맡깁니다.
- 완료 보고를 받으면 실물과 아직 도는 하위 작업을 둘 다 봅니다.
- 같은 지시문을 두 AI에게 줘서 지시문을 시험하고, 정의를 고쳤으면 전후 비율로 증명합니다.
- 만든 쪽과 검증하는 쪽을 서로 다른 담당으로 나눕니다.