문제의 시작: 봇들의 무질서한 경쟁
드림팀은 4개의 봇으로 구성되어 있다. 각 봇은 다른 업무를 담당하지만, 모두 같은 공유 파일에 접근해야 했다. 처음에는 문제가 없었다. 하지만 작은 실수들이 쌓이기 시작했다.
정각마다 4개 봇이 동시에 같은 시트를 열고, 마지막에 저장한 봇의 데이터만 남는다. 다른 봇들의 작업은 사라진다.
이 현상은 주 5회, 때론 더 자주 일어났다. 복구하느라 든 시간만 해도 상당했다.
원인 분석: 타이밍의 운
비개발자 입장에서는 원인을 파악하기 어려웠다. 봇들에게 명확한 지시는 했지만, "먼저 작업하는 봇이 우선이다"라는 규칙이 없었다. 모두가 동시에 출발선에서 기다렸다가 신호음에 달려드는 꼴이었다.
Clause Code와 소통하며 깨달은 점은 단순했다. 봇들도 예의바르게 기다릴 수 있다는 것이다.
해결책: 3줄의 순서 규칙
시작 분(minute)을 각 봇마다 7분씩 밀었다.
봇 A: 정각 정확하게 (0분)
봇 B: 정각 + 7분
봇 C: 정각 + 14분
봇 D: 정각 + 21분
이 규칙을 프롬프트 맨 앞에 박아 넣었다. 단 3줄이었다.
결과: 완전한 조용함
규칙 도입 후 1주일, 덮어쓰기 사고는 0번이었다. 2주, 3주를 거쳐도 마찬가지였다.
더 놀라운 점은 다른 부작용도 줄었다는 것이다.
• **한도 초과 오류**: 같은 시간에 여러 요청이 몰리며 발생하던 API 한도 오류가 거의 없어졌다.
• **복구 시간**: 매일 아침 10~15분 소요되던 파일 검증 시간이 사라졌다.
• **데이터 신뢰도**: 최종본이 항상 유일하고 명확해졌다.
배운 점: 규칙은 작을수록 강하다
비개발자가 할 수 있는 최고의 자동화는 "AI와 대화하는 것"이 아니라, "봇들이 대화하게 만드는 것"이다. 7분의 시간차는 기술적으로는 미미하지만, 운영상으로는 혁신이었다.
더 많은 지시를 넣으면 봇들도 혼란해한다. 3줄, 아주 명확한 규칙. 이것만으로 충분했다.
지금 드림팀은 같은 파일을 열면서도 아무도 밟힐 염려가 없다. 봇들도 자기 차례를 정확히 안다.