‘태스크(task)’라는 단어는 매우 다른 두 가지 대상을 지칭하는 데 사용되며, 이 혼동 때문에 사람들은 몇 주를 낭비합니다.
스크립트는 결정론적입니다. 같은 입력에는 항상 같은 출력이 나오고, 판단이나 놀라움이 없습니다. 반면, 태스크는 작은 위임(delegation)입니다. 무언가가 세상을 살펴보고, 결정하고, 행동해야 합니다. 스크립트는 크고 즉시 실패하는 경향이 있습니다. 하지만 태스크는 3단계 후에 조용히 실패합니다.
제가 에이전트(agent)와 관련하여 보는 실망감의 대부분은 이 둘을 혼동하여 다루기 때문에 발생합니다.
스크립트여야 할 때
‘확인하다’나 ‘알아내다’라는 단어를 사용하지 않고 단계들을 글로 적을 수 있다면, 그것은 스크립트입니다. 파일 이름 변경, 테스트 스위트 실행, 알려진 브랜치 배포 등 모든 것이 스크립트입니다. 에이전트를 여기에 투입해서는 안 됩니다. 더 느리고, 비용이 들며, 존재하지 않던 실패 모드를 도입합니다.
저의 규칙은 이렇습니다. 만약 제가 동료에게 그 태스크를 두 번 설명해야 하고, 두 번 모두 같은 단어를 사용한다면, 그것은 아직 아무도 작성하지 않은 스크립트입니다.
진정한 태스크일 때
단계들이 현재 세상의 모습에 따라 달라질 때가 있습니다. ‘실패하는 테스트를 찾아 고치기’는 태스크입니다. ‘배포가 실제로 효과가 있었는지 확인하기’, 그리고 ‘이 세 가지 의존성 변경 중 어떤 것이 문제를 일으키는지 알아내기’ 역시 마찬가지입니다.
여기서 주목할 점은 이 모든 것들이 암묵적인 결정(implicit decision)을 포함한다는 것입니다. 이것이 신호입니다. 태스크에는 갈림길이 있으며, 어느 방향으로 가야 할지는 누군가 살펴보기 전까지는 알 수 없습니다.
사람들을 혼란에 빠뜨리는 혼합된 경우
위험한 중간 지대는 하나의 미지 단계(unknown step)를 가진 스크립트입니다. 그것은 태스크처럼 보이기 때문에 사람들이 전체 것을 에이전트에 맡기곤 합니다. 그러면 원래 결정론적이었던 10단계의 순서가 판단력을 가진 무언가에 의해 즉흥적으로 수행되며, 비용은 10배로 들고, 단계마다 새로운 실패 모드가 생깁니다.
해결책은 스크립트를 유지하고 미지 단계만 위임하는 것입니다. 스크립트가 태스크를 호출하고, 그 태스크가 결정을 반환하면, 스크립트가 계속 진행합니다. 제가 신뢰할 수 있는 자동화의 대부분은 정확히 이러한 형태를 가지고 있습니다: 지루하지만 결정론적인 척추(spine)와 중간에 위치한 하나의 지능형 노드입니다.
이 구분이 유효한 이유
스크립트는 감사(auditable)가 가능합니다. 저는 파일을 읽고 무슨 일이 일어날지 알 수 있습니다. 반면, 태스크는 결과로 검증해야 하므로 종료 조건(finish condition)이 매우 중요합니다.
이 둘이 섞이면 두 가지 속성 모두를 잃게 됩니다. 감사할 수도 없고, 완전히 검증할 수도 없습니다. 이것이 최악의 상황이며, 놀라울 정도로 흔하게 빠지는 함정입니다.
만약 스크립트인 척 위장한 태스크를 발견하신 적이 있다면 듣고 싶습니다. 저의 경우, 한 달 동안 '위임'해왔던 주간 보고서가 매번 같은 세 개의 쿼리에서 나온 숫자들로 채워진 것을 깨달았을 때였습니다.