AI 스킬만으로는 팀의 공용 도구가 되지 않는다

Claude Code나 Codex 같은 AI 에이전트 도구가 개발 조직을 넘어 다른 부서로 넘어오고 있습니다. 채팅창에 질문을 넣고 답을 받아 쓰는 방식과는 다릅니다. 지시 한 줄을 받으면 사내 파일을 직접 열고 필요한 코드를 짜서 실행하고, 결과까지 내놓습니다.

이 도구가 들어온 팀에서는 질문이 한 번 옮겨갑니다. 처음에는 누가 이걸 잘 쓰게 만들 것인가를 묻다가, 쓰는 사람이 어느 정도 늘어나면 다른 질문으로 바뀝니다. 개인이 잘 쓰는 것으로 끝내지 않으려면 조직에 무엇을 남겨야 하느냐는 질문입니다. 교육 산출물로 무엇을 받을지 정해야 하는 HRD 담당자에게는 이 질문이 가장 먼저 옵니다.

요즘 제시되는 답은 하나입니다. 잘 되는 작업 방식을 파일로 적어 AI에게 넘기는 것, 이런 파일을 스킬이라고 부릅니다. 프롬프트를 매번 새로 쓰는 대신 팀이 합의한 방식을 파일로 고정해두는 셈이라, 교육 산출물로 남기기에 알맞아 보입니다.

그런데 조직 자산이라는 말에는 조건이 하나 붙습니다. 만든 사람이 아닌 사람도 그 결과를 믿고 쓸 수 있어야 한다는 것입니다. 열 번 돌려 일곱 번은 맥락에 맞는 답이 나오는 도구를, 팀의 공용 도구로 쓸 수 있을까요. 받은 사람이 어느 답이 그 세 번에 속하는지 가려내지 못하면 결과를 전부 다시 확인해야 하고, 그러면 도구를 쓴 만큼 일이 늘어납니다.

열 번 중 일곱 번이라는 숫자가 스킬을 더 잘 써서 올라가는 숫자인지, 이 글에서 확인해보려 합니다.

스킬, AI가 읽는다는 이유로 자산으로 오해받는다

스킬이 자산처럼 보이는 건 읽는 쪽이 사람이 아니기 때문입니다. 사내 위키의 업무 매뉴얼은 사람이 찾아 읽고 각자 해석해야 작동하지만, 스킬은 AI가 직접 읽고 그대로 수행하니 해석이 끼어들 자리가 없어 보입니다. 한 명이 잘 써두면 팀 전체가 같은 방식으로 일하게 될 것 같습니다.

그런데 AI가 읽는 것과 지키는 것은 다른 문제입니다. 스킬은 반드시 이행되는 명령이 아니라, AI가 작업을 시작할 때 함께 참고하는 문서에 가깝습니다. 어떻게 진행할지는 AI가 매번 새로 정하고, 스킬은 그 판단이 특정 방향으로 기울도록 도울 뿐입니다. 잘 쓴 스킬일수록 그 방향으로 갈 확률은 높아지지만, 어느 시도가 빗나갈지는 미리 알 수 없습니다.

재무팀에서 월간 보고서 작성 방식을 스킬로 적어둔 적이 있습니다. 어떤 파일에서 어떤 항목을 뽑고 순서를 어떻게 배치할지, 단위는 무엇으로 맞추고 전월 대비 증감은 어디에 넣을지까지 구체적으로 담겨 있어 만든 사람도 꽤 만족했던 스킬입니다. 석 달째 되던 어느 날, 보고서를 넘겨보던 팀장이 물었습니다. "이번 달은 항목 순서가 왜 이래요?" 확인해보니 원본 파일의 열 순서가 지난달과 달라져 있었고, 스킬은 그 변화를 눈치채지 못한 채 그대로 밀어붙인 것이었습니다.

같은 석 달 동안 비슷한 일이 두 번 더 있었습니다. 한 번은 요청을 주고받는 대화가 길어지면서 중간 지시가 반영되지 않았고, 한 번은 스킬에 없는 상황이 나오자 AI가 그 자리에서 알아서 판단해버렸습니다. 열 번 중 세 번, AI가 스킬을 무시한 것은 아닙니다. 스킬로 답이 서지 않는 지점에서 스스로 답을 낸 것뿐입니다.

그럼 스킬을 더 자세히 쓰면 되지 않을까 싶지만, 여기엔 함정이 있습니다. 예외 상황을 하나씩 적어 넣을수록 스킬은 길어지고, AI가 참고해야 할 문장도 그만큼 늘어납니다. 늘어난 문장 중 무엇을 우선할지가 다시 확률의 문제로 돌아갑니다. 정확도를 올리려던 시도가 어느 지점부터는 오히려 정확도를 깎아먹습니다. 스킬을 다듬는 일에는 이렇게 상한이 있습니다.

그렇다고 스킬이 쓸모없다는 뜻은 아닙니다. 스킬이 없으면 애초에 확률이 올라갈 계기조차 없고, 작업 방식을 글로 옮기는 과정에서 담당자 머릿속에만 있던 판단이 처음으로 밖으로 나오기도 합니다. 다만 스킬을 남긴 시점에 조직 자산이 완성됐다고 보긴 이릅니다. 그 시점에 생긴 건 확률이 올라간 상태이지, 만든 사람이 아닌 사람도 결과를 믿고 쓸 수 있는 상태는 아직 아닙니다.

코드와 hook, 매번 같은 결과는 여기서 나온다

이 보고서 스킬을 다시 들여다보면, 적힌 문장의 성격이 둘로 갈립니다. 매출 항목을 어느 열에서 뽑고 단위를 백만원으로 맞추라는 문장에는 정답이 하나뿐입니다. 반면 증감이 큰 항목에 어떤 설명을 붙일지는 그달의 사정을 봐야 정해지는 문장입니다.

정답이 하나인 일을 매번 새로 시키는 대신, 그 부분만 코드로 옮겨두면 됩니다. 매출 항목을 뽑아 단위를 맞추고 전월과 비교하는 코드를 한 번 만들어두면 AI는 그 코드를 실행하고 결과만 받으면 됩니다. 파일의 열 순서가 바뀌어도 코드가 열 이름으로 항목을 찾으니 값은 똑같이 나옵니다. 앞서 세 번 중 첫 번째로 어긋났던 원인이 이 지점에서 없어집니다. 반대로 증감에 붙일 설명처럼 코드로 옮길 수 없는 부분은 스킬에 그대로 남깁니다. 매달 달라야 할 부분을 코드로 고정하면 오히려 틀린 보고서가 나오기 때문입니다.

코드를 만들어두는 것으로 끝나지 않습니다. 그 코드를 실행할지 말지는 여전히 AI의 몫이기 때문입니다. 실제로 이런 일이 있었습니다. 계산 코드를 다 만들어놓았는데, AI가 그 코드를 부르지 않고 원본 파일을 직접 읽어 스스로 계산해버렸습니다. 결과는 그럴듯했고 형식도 맞았습니다. 이상한 낌새를 챈 건 나중에 합계를 손으로 다시 맞춰보고 나서였습니다. 값이 코드로 계산한 것과 달랐습니다. 코드를 실행하라는 지시도 결국 스킬에 적힌 한 문장이었을 뿐이라, 지켜질 확률만 올라가 있던 셈입니다.

그래서 하나가 더 필요합니다. hook입니다. 정해진 자리에서 무조건 실행되는 코드를 말합니다. 보고서가 완성되면 밖으로 나가기 전에 항목 수와 단위, 그리고 합계가 코드로 계산한 값과 일치하는지를 검사하도록 걸어둡니다. AI가 계산 코드를 건너뛰고 직접 계산한 경우는 합계가 어긋나므로 이 검사에서 걸리고, 걸린 보고서는 밖으로 나가지 않고 되돌아옵니다. hook이 좋은 보고서를 만들어주는 것은 아닙니다. 잘못된 보고서가 팀에 넘어가는 일을 막아줄 뿐입니다.

이렇게 되면 받는 사람의 일도 달라집니다. hook이 없을 때는 어느 보고서가 어긋났는지 알 수 없어 전부 다시 계산해야 했지만, hook이 걸러주는 상태에서는 통과했다는 표시 하나만 확인하면 됩니다. 그리고 이 hook을 얼마나 믿어도 되는지도 숫자로 확인할 수 있습니다. 지난 몇 달치 보고서를 도구에 다시 넣어 돌려보면, hook에 걸리는 것과 통과하는 것이 갈리고 통과한 것 중 사람이 만든 값과 다른 건이 몇 건인지도 드러납니다. 그 숫자가 팀이 이 도구를 어디까지 믿어도 되는지 알려줍니다. 열 번 중 열 번 맞는 도구가 되는 건 아니지만, 적어도 틀린 것이 어디서 걸리는지는 아는 도구가 됩니다.

데이터 체계, 여기가 흔들리면 hook도 소용없다

앞에서 코드가 열 이름으로 항목을 찾는다고 했습니다. 그런데 이 코드가 작동하려면 조건이 하나 있습니다. 열 이름이 매달 같아야 합니다. 지난달까지 매출액이라고 적혀 있던 열이 이번 달에 총매출로 바뀌면, 코드는 그 열을 찾지 못하고 멈춥니다.

현장의 원본 파일은 대부분 이렇게 깔끔하지 않습니다. 담당자가 매달 손으로 파일을 채우다 보니 항목이 늘거나 줄고, 이름도 조금씩 바뀝니다. 지금까지는 사람이 보고 알아서 맞춰왔기 때문에 별문제가 안 됐을 뿐입니다.

이번 달 보고서를 만들 때도 코드는 멈췄습니다. 그런데 AI는 거기서 멈추지 않았습니다. 총매출이라는 새 이름의 열을 찾다가 실패하자, 파일을 처음부터 다시 훑어 그럴듯해 보이는 열을 스스로 골라 계산해버린 것입니다. 결과물은 지난달과 똑같은 모양으로 나왔습니다.

이때 hook은 절반만 일을 했습니다. 항목 수와 단위는 확인해줬습니다. 이 둘은 AI가 직접 계산해도 크게 어긋나지 않기 때문입니다. 정작 걸러야 했던 건 합계였는데, 이 검사는 원래 코드가 계산한 값과 비교하는 방식이었습니다. 코드가 애초에 돌지 않았으니 비교할 값 자체가 없었고, hook은 틀린 합계를 그냥 통과시켰습니다.

여기서 사슬이 하나로 이어집니다. 열 이름이 바뀌자 코드가 멈췄고, 코드가 멈추자 hook에서 가장 중요한 검사가 무력해졌습니다. 코드와 hook을 먼저 만들고 데이터는 나중에 정돈해도 된다는 생각이 통하지 않는 이유입니다. 데이터부터 정리돼 있어야 코드도, hook도 제 역할을 합니다.

데이터 체계라고 하면 거창하게 들리지만 실제로는 간단합니다. 항목 이름과 단위와 저장 위치를 정해두고, 매달 같은 형태로 쌓는 것입니다.

스킬은 실습 시간 안에 쓸 수 있습니다. 코드와 hook도 그 안에서 만들 수 있습니다. 데이터 체계는 다릅니다. 한 사람의 업무 범위를 넘어섭니다. 여러 부서가 같은 형식으로 쌓기로 합의해야 합니다. 그래서 며칠짜리 실습으로는 만들어지지 않습니다. 교육 산출물 목록에 데이터 체계가 들어갈 수 없는 이유이자, 교육이 시작되기 전에 이미 갖춰져 있어야 하는 이유입니다.

교육을 기획할 때는 커리큘럼보다 먼저 봐야 할 것이 있습니다. 참여자가 실습에서 다룰 데이터가 지금 어떤 상태인지입니다. 항목 이름이 매달 바뀌는 파일을 실습 재료로 쓰면 무슨 일이 생길까요. 실습에서는 멀쩡히 작동하는 도구가 나옵니다. 다음 달이면 멈춥니다. 참여자는 이것을 자기 실력 문제로 받아들이고 다음 시도를 접습니다.

데이터 체계가 셋 중 가장 눈에 띄지 않는 이유도 여기 있습니다. 스킬은 파일로 남습니다. 코드와 hook도 만든 흔적이 남습니다. 데이터 체계는 잘 갖춰져 있을 때 아무 일도 일어나지 않습니다. 티가 나는 건 무너질 때뿐입니다.

갖추는 일은 조직의 몫입니다. 다만 지금 상태가 어떤지 알아보는 일은 담당자도 할 수 있습니다. 매달 오는 파일의 항목 이름이 그대로인지, 단위가 섞이지 않았는지, 같은 자리에 쌓이고 있는지를 보는 눈입니다. 데이터가 좋은지 나쁜지를 따지는 것과는 다른 질문입니다. 값이 아무리 정확해도 이름이 매달 바뀌면 코드는 붙지 않습니다. 이 눈이 없으면 결과가 어긋날 때마다 손댈 곳이 스킬밖에 보이지 않습니다. 그러면 실습은 계속 스킬을 다듬는 쪽으로만 돌아갑니다.

결론

조직에 지금 남아 있는 AI 자산을 한번 세어보면 좋겠습니다. 스킬 파일이 몇 건인지, 그중 정답이 하나인 일을 코드로 옮겨둔 것이 몇 건인지, 그 코드를 반드시 지나가게 걸어둔 것이 몇 건인지입니다. 스킬 건수만 채워져 있다면 지난 교육이 조직에 남긴 건 올라간 확률뿐입니다. 옆자리 동료가 그 결과를 믿고 쓰기까지는 아직 몇 단계가 남아 있는 셈입니다.

여기에 하나 더 확인할 게 있습니다. 그 위에 얹을 데이터가 지금 어떤 상태인지 알아보는 사람이 팀에 있는지입니다. 이 사람이 없으면 결과가 어긋날 때마다 스킬을 다시 고치게 되고, 다음 교육도 결국 스킬을 다듬는 시간으로 채워집니다.

물론 여러 부서가 데이터 형식을 하나로 맞추는 일은 한 팀의 의지만으로 되지 않습니다. 그 합의를 어떻게 끌어낼지는 또 다른 문제입니다.

다만 그 문제에 앞서 분명히 해둘 것이 있습니다. 조직 자산은 스킬 파일만을 뜻하지 않습니다. 그 판단이 옮겨간 코드, 그 코드를 반드시 지나가게 만든 hook, 그리고 그 위에서 실제로 쌓이고 있는 데이터 체계까지 함께 자산으로 봐야 합니다. 넷 중 하나만 세고 나머지를 빠뜨리면, 다음 교육에서도 같은 자리를 맴돌게 됩니다.