왜 AI 도입 검토는 전산실에서 멈출까

작년부터 전산 조직이 있는 제조사에 AI를 제안하면서 저희가 처음 세운 계획은 단순했습니다. 전산실을 설득하자. 그쪽이 기술을 아는 사람들이니 설명이 제일 잘 통할 거라고 봤습니다.

틀렸습니다.

가장 오래 걸린 자리가 거기였습니다. 기술을 몰라서가 아닙니다. 오히려 잘 알아서였습니다.

그리고 부딪힌 것은 거절이 아니라 자체 대응이었습니다. 우리도 할 수 있다는 쪽으로 이야기가 흐르는 것입니다.

이 글은 그 판단이 회사 안에서 어떻게 굴러가는지를 저희가 본 대로 적은 것입니다.

먼저 분명히 해 둘 것이 있습니다. 표본이 작습니다. 저희가 이 자리에서 만난 회사는 손에 꼽습니다. 통계로 확인한 것이 아니라 그 몇 건에서 보고 내린 판단이고, 반대 사례도 저희 안에 있습니다. 그래서 "대부분의 전산실이 이렇다"고는 적지 않겠습니다. 어느 회사 이야기인지도 적지 않습니다.

자체 대응은 대체로 할 수 있는 일이 맞습니다

먼저 짚어 둘 것이 있습니다. 그 판단은 대개 근거가 있습니다.

전산실 사람들은 대개 이런 일을 이미 하고 있습니다.

• 사내 시스템을 붙여 본 경험 — ERP와 MES 사이에서 데이터를 옮기는 일을 몇 년씩 해 왔습니다

• 현업 요구를 받아 화면으로 만드는 일 — 어느 부서가 무엇을 원하는지 가장 정확히 아는 자리입니다

• 외부 업체를 관리한 경험 — 여러 벤더를 겪어 봤고, 무엇이 말만 앞선 제안인지 판별합니다

이 세 가지를 갖춘 조직이 자체로 해 보겠다고 판단하면, 그건 무리한 판단이 아닙니다. 실제로 파이썬으로 예측 모델을 돌려 본 팀도 있습니다. 사내 문서를 붙여 챗봇을 만들어 본 팀도 있습니다.

저희가 만난 전산실 중에 무능한 곳은 거의 없었습니다. 그러니 이 글은 그 사람들이 틀렸다는 이야기가 아닙니다.

이 말은 다른 문장으로 옵니다

그런데 이것이 "안 하겠다"로 나오지는 않습니다. 순연으로 나옵니다. 저희가 본 형태는 이렇습니다.

• 시범으로 먼저 해 보고 판단하겠다

• 데이터부터 정리하고 나서 보는 것이 순서다

• 비슷한 것을 알아보는 중이니 같이 놓고 보겠다

• 내년 예산에 반영해서 제대로 하겠다

• 지금 밀린 과제가 있으니 그것부터 끝내고 보겠다

다섯 가지 모두 반대가 아닙니다. 어느 것도 "하지 말자"가 아니고, 회의록에 적으면 전부 건설적으로 읽힙니다.

그래서 위에서는 진행 중으로 보입니다. 거절은 기록에 남지만 순연은 기록에 남지 않습니다.

문제는 그 말이 검증되지 않는다는 것입니다

이 말의 진짜 문제는 내용이 아니라 자리입니다.

할 수 있다고 말한 조직이, 그 말이 지켜졌는지를 판정하는 조직입니다.

보통의 회사 일은 이렇게 굴러가지 않습니다. 생산이 목표를 말하면 품질과 재무가 결과를 잽니다. 영업이 예측을 내면 다음 분기 숫자가 답을 줍니다. 말한 사람과 재는 사람이 다릅니다.

그런데 사내 AI 개발은 다릅니다. 진척을 보고하는 사람도 전산실이고, 그 보고가 맞는지 판단할 지식을 가진 사람도 전산실뿐입니다. 경영진에게는 대조할 기준이 없습니다.

그러니 "진행 중입니다"라는 보고는 반박되지 않습니다. 1년이 지나도 반박되지 않습니다.

경영진에게는 가장 합리적인 답으로 들립니다

검증이 안 되는 데다, 이 답은 위에서 볼 때 매력적이기까지 합니다.

같은 안건을 두고 두 가지 답이 올라온다고 해 보겠습니다.

경영진이 자체 개발 쪽으로 기우는 것은 판단력이 부족해서가 아닙니다. 적힌 것만 보면 그쪽이 낫기 때문입니다.

빠진 것은 시간입니다. 그리고 시간은 견적서에 줄로 잡히지 않습니다.

그래서 이렇게 지나갑니다

저희가 본 흐름은 대체로 이런 모양이었습니다.

3년차에 이르면 나오는 말이 있습니다. 그때 시작했어야 했다는 것입니다.

이 흐름에서 누구도 거짓말을 하지 않았다는 점이 중요합니다. 전산실은 실제로 시도했고, 경영진은 실제로 기다렸습니다. 다만 기한이 없었습니다. 언제까지 무엇이 되면 성공이고, 안 되면 어떻게 하는지가 처음부터 정해지지 않았습니다.

기한 없는 자체 개발은 실패하지 않습니다. 끝나지 않을 뿐입니다.

막히는 곳은 모델이 아니라 그다음이었습니다

여기서 한 가지는 전산실 편을 들어야 맞습니다. 자체 개발이 늦어지는 이유는 대개 실력이 아닙니다.

저희가 본 바로는 모델을 만드는 데까지는 대체로 갑니다. 막히는 곳은 그 뒤였습니다.

• 현장 데이터가 학습에 못 쓰는 상태 — 값은 쌓여 있는데 설비마다 이름이 다르고 빈 칸이 많습니다

• 정확도가 90%를 넘긴 다음 — 틀린 10%를 현장에서 어떻게 걸러낼지가 안 정해지면 아무도 손대지 않습니다

• 새벽에 멈췄을 때 — 만든 사람이 자고 있으면 그날 라인이 섭니다. 운영은 개발과 다른 일입니다

• 만든 사람이 나갔을 때 — 인수인계 문서가 코드보다 짧으면 그 시스템은 그때 끝납니다

이 넷은 사내 조직이라서 겪는 어려움이 아닙니다. 저희 같은 회사도 똑같이 겪습니다. 다만 저희는 그것만 하고, 전산실은 그것 말고도 할 일이 많습니다.

그러니 자체 대응에서 흔들리는 것은 '할 수 있는가'가 아니라 생략된 '언제까지'입니다.

전산실 잘못이 아니라 자리를 잘못 앉힌 것입니다

여기서 오해를 하나 풀어야 합니다. 이건 그 사람들의 태도 문제가 아닙니다.

전산실 임원이 AI 도입에 신중한 데에는 그 자리에서 보면 타당한 이유가 있습니다. 그런데 그 이유를 흔히 잘못 짚습니다. AI가 들어오면 전산실 일이 줄어들 거라고 보는 것입니다. 저희가 본 바로는 반대입니다.

• 일이 늘어납니다 — 계정·권한·망 분리·연동·장애 대응이 전부 그쪽으로 갑니다. 시스템이 하나 늘면 지켜볼 것이 하나 늘어납니다

• 사고가 나면 그 자리가 답합니다 — 도입을 결정한 사람이 아니라 운영하는 사람이 불려 갑니다

• 잘되면 공은 밖으로 갑니다 — 성과 보고에는 업체 이름이 남습니다

• 안 되면 책임은 안에 남습니다 — 업체를 고른 것도, 관리한 것도 전산실입니다

이 넷을 합치면 이렇게 됩니다. 일은 늘고, 위험은 커지고, 공은 남에게 갑니다. 도입에 적극적일수록 그 사람에게 손해입니다. 그런데 회사는 그 사람에게 검토를 맡깁니다.

판단이 기울어 있는 것이 아니라 자리가 기울어 있습니다. 그 자리에 누가 앉아도 비슷하게 답할 겁니다.

갈리는 지점은 능력이 아니었습니다

비슷한 조건의 두 회사를 나란히 볼 기회가 있었습니다. 한쪽은 빠르게 밀어붙였고 한쪽은 아직 검토 중입니다. 두 건이니 법칙이라고는 못 하고, 저희가 본 것만 적습니다.

차이가 기술력이었을까요. 아니었습니다. 예산도 아니었습니다.

달랐던 것은 누가 이 안건을 들고 있었는가입니다.

• 빠르게 간 쪽에서는 대표나 오너가 안건을 직접 들고 기한을 걸었습니다

• 멈춘 쪽에서는 검토가 전산실로 내려갔고, 그 뒤로 위에서 다시 묻지 않았습니다

내려보내는 순간 결정은 끝난 것처럼 보입니다. 그런데 실제로는 결정이 시작되지도 않았습니다. 안건이 검토라는 이름으로 한 부서 안에 머물게 되고, 그 부서에는 서두를 이유가 없기 때문입니다.

한 사람의 판단으로 회사가 몇 년을 잃는 일은 이렇게 일어납니다. 누가 반대해서가 아니라, 아무도 다시 묻지 않아서입니다.

경영진이 물어볼 세 가지

이 자리를 확인하는 데 기술 지식은 필요하지 않습니다. 세 가지면 됩니다.

1. 언제까지 무엇이 되면 성공입니까

"AI 도입"이 아니라 "몇 월까지 어느 공정에서 무엇이 자동으로 판정된다"로 답이 나와야 합니다. 답이 안 나오면 그건 계획이 아니라 의사 표시입니다.

2. 안 되면 그다음은 무엇입니까

자체 개발이 기한 안에 안 됐을 때 무엇을 하는지가 정해져 있어야 합니다. 이게 없으면 기한은 기한이 아닙니다.

3. 이 판단이 맞는지 누가 봅니까

전산실이 아닌 사람이 결과를 확인하는 자리가 있어야 합니다. 외부 검토여도 되고 현업 부서여도 됩니다. 중요한 것은 보고하는 쪽과 재는 쪽을 나누는 것입니다.

세 질문 모두 전산실을 의심하는 질문이 아닙니다. 어느 부서에 맡겨도 똑같이 물어야 하는 것들입니다.

답이 이렇게 오면 한 번 더 물어보시는 것이 좋습니다.

세 답이 모두 위험한 쪽이면, 그 안건은 지금 멈춰 있습니다.

회의록 세 번만 세어 보셔도 됩니다

밖에서 진단받을 필요도 없습니다. 회사 안에 이미 자료가 있습니다.

작년 이후 임원 회의록에서 AI나 자동화가 안건으로 오른 날을 찾아, 그날 결론이 무엇이었는지만 나란히 놓아 보십시오.

• 같은 안건이 세 번 이상 올라왔는데 결론이 매번 "검토 후 보고"라면 그건 검토가 아닙니다

• 각 회차 사이에 실제로 무엇이 달라졌는지 한 줄로 못 적으면 그 사이 기간은 지나간 것이 아니라 비어 있습니다

• 회의록에 담당 부서는 있는데 완료일이 없다면, 그 안건에는 처음부터 기한이 없었던 것입니다

세 줄로 끝나는 확인입니다. 그런데 이걸 해 보시면 몇 년이 어디로 갔는지가 대체로 보입니다.

전산실을 빼는 것은 답이 아닙니다

그렇다고 전산실을 건너뛰는 방식은 더 나쁩니다. 저희도 몇 번 그렇게 해 봤고, 결과가 좋지 않았습니다.

시스템은 결국 그 조직이 운영합니다. 계정도 그쪽이 만들고, 장애가 나면 그쪽이 새벽에 나옵니다. 도입 과정에서 빠져 있던 조직이 운영을 맡으면 그 시스템은 오래 못 갑니다.

저희가 지금 하는 방식은 이렇습니다.

• 평가와 이행을 나눕니다 — 자체로 할 부분과 밖에서 가져올 부분을 처음에 갈라 놓고 시작합니다

• 기한을 안건에 붙입니다 — 검토 자체에 종료일을 둡니다. 연장은 위에서 다시 결정하게 합니다

• 전산실의 몫을 먼저 정합니다 — 운영·보안·계정 관리는 그쪽 일로 명시하고, 그 일이 늘어난다는 것도 같이 적습니다. 늘어난 만큼 무엇이 따라오는지가 문서에 있어야 합니다

세 번째가 실제로 제일 잘 통했습니다. 반대가 줄어든 이유는 저희 설명이 좋아져서가 아니라, 그 사람이 잃는 것이 무엇인지가 명확해졌기 때문이라고 봅니다.

전산실에 계신 분이라면

이 글이 그쪽을 겨냥한 글로 읽힐 수 있어서 한 절을 더 답니다. 저희가 보기에 지금 구조에서 제일 불리한 자리가 거기입니다.

일은 늘고, 사고가 나면 그 자리가 답하고, 잘되면 공은 밖으로 가고, 안 되면 책임은 안에 남습니다. 그러면서 판단은 그 자리에서 하라고 합니다. 이건 어느 부서에 붙여 놓아도 잘 안 굴러가는 조건입니다.

그래서 요구하실 만한 것이 세 가지 있다고 봅니다.

• 성과의 이름을 나눠 달라고 — 도입 성과 보고에 운영·연동을 맡은 조직이 함께 적히게 하는 것입니다. 이게 없으면 협조할 이유가 실제로 없습니다

• 늘어나는 일을 인원과 예산으로 — 연동과 운영이 그쪽 일이 되는데 사람이 그대로면 그건 도입이 아니라 전가입니다. 구두 약속은 인사이동 한 번이면 사라지니 문서로 남기십시오

• 기한을 위에서 걸어 달라고 — 기한이 없으면 늦어진 책임이 결국 검토한 부서로 옵니다. 기한은 압박이 아니라 방패이기도 합니다

셋 다 도입에 찬성해야 요구할 수 있는 것이 아닙니다. 반대하시더라도 이 셋은 먼저 정해 두는 편이 낫습니다.

다시 묻지 않으면 결정은 없던 일이 됩니다

정리하면 이렇습니다.

자체로 해 보겠다는 판단은 대체로 근거가 있습니다. 문제는 그 판단을 내린 조직이 그 판단이 지켜졌는지를 판정하는 조직이라는 것이고, 위에서 기한을 걸지 않으면 그 판정은 영원히 미뤄집니다.

그래서 이 안건은 내려보내면 멈춥니다. 반대해서가 아니라 서두를 이유가 없어서입니다.

한 번 물어보실 만합니다. 작년에 검토하라고 내려보낸 그 안건은 지금 어디에 있습니까.

그래도 저희는 계속 두드립니다

여기서 글을 닫으면 남는 것이 체념뿐이라 한 절을 더 답니다. 그리고 이 절은 저희 이야기입니다.

먼저 솔직하게 적겠습니다. 저희가 해 온 일은 대부분 이 문을 지나지 않았습니다. 구매팀으로 들어온 건, 대표가 직접 앉은 건, 원수급 회사를 거쳐 들어온 건이 대부분이었습니다. 전산 조직이 검토 창구였던 건은 최근에야 생겼습니다.

그러니 저희가 빨랐던 것이 실력만은 아닙니다. 벽이 낮은 문으로 들어갔던 것이 큽니다. 이걸 실력으로 착각하면 다음 문에서 그대로 막힙니다.

그리고 벽이 있는 쪽에서도 되는 곳이 있었습니다. 전산부장과 IT 담당 임원이 나란히 있는 제조사에서 대규모 구축이 실제로 돌아갔습니다. 조직이 있어서 못 하는 것이 아니라는 뜻입니다. 저희가 확인할 수 있는 차이는 하나였습니다. 접점이 처음부터 위쪽 라인이었습니다.

다른 회사에서 본 장면도 하나 적어 둡니다. 시스템을 임원이 직접 설명했습니다. 그게 이례적이라는 말을 들었습니다. 이례적이어야 하는 일이 아닌데 이례적이었습니다.

못 하는 것도 적어 둡니다. 전산 조직이 창구인 건에서 저희는 아직 끝을 못 봤습니다. 진행 중인 것이 있고 놓친 것이 있습니다. 그래서 이 글은 성공담이 아니라 아직 넘는 중인 벽을 적은 기록입니다.

그럼에도 저희는 이 문 때문에 시장을 좁히지 않기로 했습니다. 이유는 단순합니다. 그 문 뒤에 있는 회사들이 이게 제일 필요한 회사들입니다. 데이터가 쌓여 있고, 설비가 이미 들어가 있고, 사람이 그 판단을 매일 손으로 하고 있는 곳입니다.

방법은 설득이 아니라고 봅니다. 저희가 지금 하는 것은 셋입니다. 범위를 작게 잘라 먼저 돌려 보여 드리고, 검토 자체에 종료일을 붙이고, 전산 조직의 몫을 줄이는 것이 아니라 늘어나는 몫을 문서로 먼저 정하는 것입니다.

셋 다 화려하지 않습니다. 그런데 이 벽은 화려한 방법으로 넘는 벽이 아니라고 배웠습니다.

그리고 이 셋으로는 아직 부족하다고 봅니다. 셋 다 벽에 맞춰 저희 쪽을 줄인 것에 가깝지, 벽 자체를 없앤 것이 아닙니다. 그래서 지금도 붙들고 있는 질문이 몇 개 있습니다.

• 검토가 시작되기 전에 기한이 붙게 하려면 — 기한은 위에서만 걸 수 있는데, 저희는 그 자리에 없습니다. 제안서 안에 종료일을 써 넣는 것으로는 부족합니다

• 성과 보고에 운영 조직 이름이 함께 남게 하려면 — 이건 고객사 내부 규칙이라 저희가 정할 수 없습니다. 그런데 이게 없으면 협조할 이유가 실제로 없습니다

• 넘긴 뒤에 그 조직이 스스로 굴릴 수 있게 하려면 — 저희 계획의 마지막 해 목표가 그것입니다. 다만 아직 그 지점까지 가 본 건이 없습니다

셋 다 저희 혼자 못 푸는 것들입니다. 그래서 방법을 찾는 중이고, 이 글을 적는 것도 그 방법입니다. 같은 벽 앞에 있는 분들이 어떻게 넘었는지 듣고 싶습니다.

한 가지는 분명해졌습니다. 이건 한 회사의 사정이 아닙니다. 결정 하나가 미뤄지면서 몇 년이 지나가는 일이 여러 곳에서 같은 모양으로 벌어지고 있습니다. 그 몇 년을 줄이는 것이 저희가 파는 것보다 앞에 있는 문제라고 봅니다.

그래서 문은 계속 두드리겠습니다.