팀장이 AI Agent를 직접 만들 줄 알아야 하는가

리드하려면 직접 만들 수 있어야 한다. 이 문장에 동의하는 사람과 동의하지 않는 사람이 같은 조직 안에 함께 있습니다. 특정 회사의 사정도 아닙니다. 여러 고객사에서 비슷한 이야기를 듣습니다. 한쪽은 팀의 생성형 AI 과제를 리드하려면 직접 만들어본 경험이 있어야 한다고 봅니다. 무엇이 될 일이고 무엇이 안 될 일인지 가르는 감각은 만들어보지 않으면 생기지 않는다는 것입니다. 다른 쪽은 그럴 필요가 없다고 봅니다. 과제를 이해하고 방향을 잡아줄 수 있으면 되고, 구현은 실무자의 몫이라는 것입니다.

양쪽 모두 나름의 근거가 있어서 논쟁은 좁혀지지 않습니다. 그 사이 현장에서는 다른 일이 진행되고 있습니다. 생성형 AI를 쓸 수 있는 실무자는 눈에 띄게 늘었는데, 팀이 일하는 방식은 크게 달라지지 않았습니다. 이 글은 두 주장 중 하나를 고르는 대신, 관리자가 실제로 무엇을 하는 사람인지에서 다시 출발합니다.

팀장 교육의 방향, 소개에서 판정으로 옮겨가고 있다

팀장 대상 교육 요청은 꾸준히 있었습니다. 달라진 것은 그 안에서 생성형 AI를 다루는 방식입니다. 얼마 전까지는 생성형 AI가 무엇이고 조직에 어떤 변화를 가져오는지 알려달라는 요청이 많았습니다. 지금 들어오는 요청은 팀장이 직접 손을 움직여보는 실습을 포함해달라고 합니다.

요청이 달라진 배경에는 실무자 쪽의 변화가 있습니다. 생성형 AI로 자기 업무를 처리할 수 있는 사람이 조직 안에 분명히 늘었고, 업무 적용 사례도 여기저기서 나오고 있습니다. 다만 그 사례들이 개인 단위에서 멈춥니다. 무엇이 잘 된 사례인지 판단하는 기준이 조직에 없고, 그 기준을 들고 팀의 일을 배분하는 사람의 모습도 아직 그려지지 않았습니다.

기준이 없는 팀에서 반복적으로 관찰되는 장면이 있습니다. 생성형 AI를 잘 쓰는 한두 명에게 관련 업무가 몰립니다. 팀장이 어떤 일을 도구로 만들 수 있는지 가늠하지 못하면 일을 배분할 근거가 없으니, 결국 잘하는 사람에게 맡기는 선택을 하게 됩니다. 교육으로 올라간 역량이 그 한두 명의 개인 역량에 머무릅니다.

그래서 요청의 내용도 대개 비슷합니다. 팀장이 팀의 과제를 스스로 가려낼 수 있게 해달라는 것입니다. 그러려면 무엇이 도구로 만들 수 있는 일인지에 대한 기준이 먼저 필요합니다.

좋은 AI 과제, 세 가지 질문으로 가려진다

팀원이 이 업무를 생성형 AI로 만들어보겠다고 들고 왔을 때, 팀장이 던져야 하는 질문은 세 가지입니다. 기능이 단계로 구분되는가, 판단 기준을 글로 적을 수 있는가, 실제 데이터가 있는가. 이 세 가지는 업무의 중요도나 절감 시간과는 상관이 없습니다. 생성형 AI가 일을 처리하는 방식 자체에서 나온 조건입니다.

첫 번째 질문은 일이 기능 단위로 쪼개지는지를 봅니다. 업무를 도구로 만드는 과제는 대부분 생성형 AI가 코드를 만들고 그 코드가 실제 처리를 담당하는 형태로 해결됩니다. 코드가 만들어지고 작동하려면 무엇을 먼저 하고 그다음에 무엇을 하는지가 기능 단위로 나뉘어 있어야 합니다. 팀 보고 업무를 자동화하고 싶다는 제안은 그 상태로는 쪼개지지 않습니다. 어떤 파일을 열어 어떤 항목을 뽑고 어떤 형식으로 정리해 어디에 넣는지까지 나뉘어야 착수가 가능합니다. 이 단계를 건너뛰고 시작하면 팀원은 실습 시간을 다 쓰고도 작동하는 결과물을 갖지 못합니다.

두 번째 질문은 AI에게 판단을 맡기려는 과제에서 갈립니다. 담당자 머릿속에 있는 판단 기준이 글로 옮겨질 수 있어야 AI가 그 판단을 대신할 수 있습니다. 일반적인 예를 들어보면 이렇습니다. 협력업체가 보낸 견적서를 검토해 그대로 받을지 되돌려 보낼지 정하는 업무가 있습니다. 담당자는 몇 년 하다 보면 보면 안다고 말합니다. 그런데 그 안다는 것이 어떤 항목을 어떤 값과 비교해 어떤 선을 넘으면 되돌려 보낸다는 문장으로 옮겨지지 않으면, AI에게 넘길 판단이 존재하지 않는 상태입니다. 보면 안다에 머물러 있는 동안 그 업무는 도구로 만들 대상이 되지 못합니다.

세 번째 질문은 넣을 데이터가 실제로 있는지를 봅니다. 코드가 처리하든 AI가 판단하든 재료가 있어야 결과가 나옵니다. 데이터가 담당자 개인 컴퓨터에 흩어져 있거나, 매번 다른 형식으로 정리돼 왔거나, 아예 기록이 남지 않는 업무라면 도구는 시연 자리에서만 작동합니다. 실제 업무에 붙이는 순간 멈춥니다.

이 세 질문이 팀장에게 필요한 이유는 판정이 생각보다 어렵기 때문입니다. 포텐스닷 교육에서 참여자가 제출한 주제를 검토했을 때, 주제 선정 양식만 주고 받은 경우 제출 주제의 22%가 12시간의 실습 시간 안에 구현이 불가능한 수준이었습니다. 자기 업무를 가장 잘 아는 사람이 자기 업무를 놓고 판단한 결과입니다. 팀원 여러 명의 제안을 받아 우선순위를 정해야 하는 팀장에게 기준이 없다면, 오판의 폭은 더 커집니다.

관리자가 개입해야 하는 세 시점, 착수 전과 제작 중과 완성 후

세 질문을 손에 들었다고 팀장의 일이 끝나지는 않습니다. 팀장이 개입해야 하는 시점은 세 번 있습니다. 팀원이 과제를 들고 왔을 때, 만드는 중일 때, 결과물이 나왔을 때입니다.

착수 전에 하는 일은 판정입니다. 앞의 세 질문 중 두 번째와 세 번째는 팀원이 답을 갖고 있는 질문입니다. 자기 업무의 판단 기준과 데이터 상태를 아는 사람은 팀원이니까요. 팀장이 하는 일은 그 답이 충분한지 되묻는 것입니다. 판단 기준을 글로 적을 수 있다고 했으면 실제로 한번 적어보게 하고, 데이터가 있다고 했으면 어떤 형식으로 어디에 있는지 확인하는 정도로 충분합니다. 이 확인 없이 착수하면 팀원은 실습 기간을 다 쓰고 나서야 안 되는 과제였다는 결론에 도달합니다. 그리고 그 경험은 다음 시도를 막습니다.

만드는 중에 하는 일은 기준 확정입니다. 앞서 든 견적서 검토 업무로 이어보겠습니다. 팀원이 도구를 만들면서 어떤 견적을 되돌려 보낼지의 기준을 글로 적었다고 해봅시다. 특정 항목의 단가가 기준값보다 일정 비율 이상 높으면 되돌려 보낸다는 식의 문장이 나옵니다. 그 비율이 그 팀원 개인의 경험에서 나온 숫자인지, 팀이 함께 쓸 숫자인지는 다른 문제입니다. 팀장이 이 기준을 보고 우리 팀은 이렇게 판단한다고 확정해주지 않으면, 옆자리 동료에게는 그 도구가 내놓은 결과를 믿을 근거가 없습니다. 각자 자기 방식으로 다시 검토하게 되고, 도구는 만든 사람 혼자 쓰는 상태로 남습니다. 실무자가 자기 머릿속 기준을 글로 옮기는 것까지는 혼자 할 수 있지만, 그 글을 팀의 기준으로 만드는 일은 혼자 할 수 없습니다.

결과물이 나온 뒤에 하는 일은 검증입니다. 팀장이 매번 산출물을 전부 들여다보라는 뜻은 아닙니다. 처음에 한 번, 과거에 사람이 처리했던 사례 수십 건을 도구에 넣어보고 사람의 판단과 얼마나 일치하는지 확인하는 것입니다. 어긋난 건이 나오면 기준 문장의 어느 부분이 부족했는지 드러나고, 그 부분을 고치면 됩니다. 이 확인을 한 번 거치면 그다음부터는 예외로 걸러진 건만 보면 됩니다. 이 과정을 건너뛴 팀은 도구를 쓰면서도 결과를 믿지 못해 사람이 다시 전수 검토하게 되고, 도구를 쓴 만큼 일이 늘어납니다.

세 시점에서 팀장이 하는 일 중 직접 코드를 쓰는 일은 없습니다. 그렇다고 생성형 AI가 어떻게 작동하는지 설명을 듣는 것으로 되는 일도 없습니다. 판정도 기준 확정도 검증도, 실제 과제를 놓고 해봐야 감이 생깁니다.

관리자의 실습, 도구를 완성하는 훈련과 다르다

이제 처음의 질문으로 돌아가 보겠습니다. 리드하려면 직접 만들 수 있어야 하는가.

직접 만들어본 경험이 있어야 한다는 쪽이 짚은 부분은 정확합니다. 판정은 설명을 들어서 생기는 감각이 아닙니다. 다만 그 결론이 팀장도 코드를 다룰 수 있어야 한다는 요구로 이어지면 과잉입니다. 팀장이 세 시점에서 하는 일 중 코드를 읽어야 하는 일은 없습니다.

그럴 필요가 없다는 쪽이 짚은 부분도 정확합니다. 구현은 실무자의 몫입니다. 다만 그 결론이 팀장에게는 과제를 이해할 정도의 강의면 충분하다는 설계로 이어지면, 판정 감각을 강의로 대체하려는 시도가 됩니다.

이 대체가 왜 어려운지는 앞에서 본 수치가 말해줍니다. 주제 선정 기준을 양식으로 받아 스스로 작성한 상태에서도 판정은 틀렸습니다. 기준을 아는 것과 그 기준으로 실제 과제를 가려내는 것 사이에는 그만큼의 간격이 있습니다.

그래서 팀장 대상 실습은 실무자 실습과 목표가 달라야 합니다. 실무자는 작동하는 도구를 손에 들고 나오는 것이 목표입니다. 팀장에게 필요한 것은 팀원이 들고 온 과제를 세 질문으로 가려내보고, 팀원이 적어온 판단 기준 문장을 읽으며 어느 부분이 비어 있는지 짚어보고, 완성된 도구를 과거 사례로 검증해보는 경험입니다. 손을 움직여 만드는 시간보다 판정하고 되묻는 시간이 길어야 합니다.

이 차이는 교육 재료에서 먼저 갈립니다. 팀장 실습을 설계한다면 재료로 쓸 것은 팀원이 실제로 하고 있는 업무입니다. 남의 사례를 놓고 판정을 연습하면 자기 팀 앞에서는 다시 막힙니다.

결론

팀장이 착수 전에 판정하고, 만드는 중에 기준을 확정하고, 완성 후에 검증하기 시작하면 팀에서 눈에 보이는 변화가 하나 생깁니다. 잘 쓰는 팀원 한 명이 만든 도구를 다른 팀원이 쓰기 시작합니다. 그 도구가 담고 있는 판단 기준이 팀장의 확인을 거친 문장이라, 처음 쓰는 사람도 결과를 어디까지 믿어야 하는지 알 수 있습니다. 업무를 배분할 때도 잘하는 사람에게 몰아주는 대신 어떤 일이 도구로 만들 수 있는 일인지를 근거로 삼을 수 있습니다.

물론 팀장마다 판정 기준이 조금씩 다를 때 그 차이를 조직 차원에서 어떻게 맞출지는 또 다른 문제입니다. 다만 그 질문은 팀장들이 판정을 시작한 다음에 옵니다. 그 전에 확인해볼 것이 있습니다. 지난 교육에서 나온 도구가 지금 몇 개 남아 있고, 그중 몇 개가 팀장의 확인을 거쳐 팀의 기준이 되었는지입니다. 이 숫자가 다음 교육에서 팀장에게 무엇을 훈련시켜야 하는지 알려줍니다.