IT 회사가 아닌 회사에도 IT 부서가 있고 나는 그곳에서 일한다.
요즘 문득 드는 생각이 하나 있다. 왜 회사에서 진행하는 IT 프로젝트는 대부분 어영부영하다가 마무리되는 걸까.
미리 밝혀두면 이건 팀장이나 본부장급 위치에서 내려다본 이야기가 아니다. 과차장쯤 되는 허리에서, 그러니까 현업에 전화를 돌리고 미팅 일정을 잡고 요구사항을 받아 적는 자리에서 본 풍경이다. 결정 권한은 없고 실행 책임만 있는 위치라고 하면 대충 맞을 것 같다.
프로젝트는 대체로 이런 순서로 무너진다
요즘은 어딜 가나 AI 얘기다. 세미나도 IT 뉴스도 AX로 가득하고 AI가 무엇이든 해결해줄 것처럼 보인다. 십 년 전 3D 프린터를 두고 사람들이 하던 이야기와 비슷하다.
그런 분위기 속에서 이런저런 세미나를 다녀온 경영진은 마치 새로운 통찰이라도 얻은 듯, “이런 거 우리도 한번 해보면 어떨까?”라며 아이디어를 꺼내놓기 시작한다.
처음에는 그럴싸해 보인다. 머릿속으로 그려보면 안 될 것이 없기 때문에 밀어붙이듯 지시가 나온다. IT 부서도 실적을 만들기 위해서라도 그걸 굴려야 하니 일단 받게 되는 상황이 만들어진다.
요구사항을 받으러 다니는 사이에 방향은 조금씩 어긋난다. 정작 그 시스템을 쓸 사람들이 필요를 느끼지 못하니 무엇을 만들어야 하는지부터 흐려진다.
그렇게 만든 시스템이 배포되면 현업은 처음 몇 번 써보는 것 같다가 곧 원래 하던 방식으로 돌아간다. 이때라도 경영진이 강하게 밀어붙이면 정착 가능성이 남는데 대개는 한 발 뺀다.
그러면 프로젝트는 이도 저도 아닌 채로 끝난다.
미팅 일정 잡는 것부터가 고비다
현업이 먼저 문제를 들고 IT 부서를 찾아오는 프로젝트는 확실히 다르게 굴러간다. 어떤 기능이 왜 필요한지, 지금 무엇이 부족하고 어떤 위험이 있는지를 본인들이 설명할 수 있기 때문이다. 바텀업(Bottom-up)으로 올라온 프로젝트는 대체로 이렇게 시작한다.
하지만 문제는 위에서만 내려온 프로젝트다.
오해를 줄이려고 덧붙이면 탑다운(Top-down) 자체가 잘못이라는 얘기가 아니다. 조직이 큰 방향을 위에서 정하는 건 당연하고 아래에서 올라온 문제 제기와 위에서 내려온 지시가 만나는 프로젝트는 오히려 힘이 붙는다. 어긋나기 시작하는 건 아래쪽이 비어 있을 때다.
현업 입장에서는 쓸 일이 없을 것 같은 시스템이다. 그 요구사항을 정의하려고 자기 시간을 쪼개서 나를 만나줘야 하는 상황이 된다. 나는 임원이 정해놓은 기한을 맞춰야 하니 계속 현업을 귀찮게 할 수밖에 없다.
여기서부터 요청하는 쪽과 협조하는 쪽의 위치가 뒤집힌다.
업무 편의를 지원하러 간 IT 부서가 아쉬운 소리를 하고 정작 시스템을 쓸 현업은 협조해주는 쪽이 된다. 한 번 이렇게 자리가 잡히면 이후 회의의 밀도도 달라진다.
막상 자리에 앉으면 모든 일이 교과서처럼 흘러가지는 않기 때문에 이상과 현실이 다르다는 걸 알게 된다.
어떤 부서는 바쁘다는 이유로 입사한 지 갓 1년 된 사원을 대신 내보내기도 하는데, 이 사원은 현장 경험이 얕으니 무엇이 문제인지부터 정의하기 어렵고 결국 회의는 계속 산으로 간다.
이런 자리를 몇 번 거치고 나면 이 시스템이 결국 쓰이지 않겠다는 감이 온다. 지금 방식으로도 업무가 돌아가는데 새로 만든 게 더 편할지 현업 스스로도 확신하지 못하기 때문이다.
잘못되면 IT 부서가 뒤집어쓴다
더 무서운 건 책임 모델이다.
현업이 아니라 IT 부서를 거쳐 하달된 프로젝트는 잘못됐을 때 대체로 IT 부서가 책임을 진다. 시스템을 안 쓰는 건 현업인데 활용률이 낮다는 지적은 만든 쪽으로 온다.
프로젝트가 클수록 이 비대칭도 커진다. 현업과 IT 부서 중 한쪽에만 KPI가 걸려 있으면 빠진 쪽은 소극적으로 참여할 수밖에 없고 그게 완성도에 그대로 드러난다.
한 발 빼고 싶어 하는 실무자들?!
제대로 시동이 걸리지 않은 프로젝트를 맡으면 실무자 머릿속에는 두 가지 질문이 남는다.
이 프로젝트를 진행하면 내가 리소스를 쏟아부은 만큼 평가를 제대로 받을 수 있을까? 어렵게 구축해뒀는데 결국 쓰이지 않고 사장되는 건 아닐까?
나 역시도 그랬다. 이런 생각이 드는 순간 한 발 빼고 싶어지는 건 누구나 마찬가지다.
현업 쪽도 사정이 비슷하다. 당장 닥친 업무만으로도 바쁜데 이 프로젝트가 내 일을 편하게 해준다는 판단이 서기 전까지는 굳이 참여하고 싶지 않을 것이다. 내 리소스를 넣었는데 성과는 IT 부서가 가져가는 구조라면 더더욱 그렇다.
그래서 아무도 이걸 자기 일이라고 여기지 않는 상태에서 양쪽 다 한 발씩만 걸친 채로 프로젝트가 굴러간다.
우리 회사에서만 유독 그런 것인가
이건 지금 회사만의 문제가 아니다. 예전 회사에서도 겪었고 지금 회사에서도 똑같이 반복된다.
한 번이면 그 조직의 문화 문제라고 넘길 수 있는데 두 번이면 구조 자체가 문제로 보인다. 회사가 달라도 IT 부서가 놓이는 위치가 대개 비슷하기 때문일 것이다.
다만 모두 내가 IT 부서의 위치에서 본 것이기 때문에 현업 쪽에서 보면 다른 그림이 나올 것이다. 인터뷰와 사전분석을 통해 요구사항을 제대로 뽑아내지 못한 IT가 문제였다고 말할 수도 있고 그 말이 틀렸다고 하기도 어렵다.
얼렁뚱땅 진행되는 IT프로젝트 소재는 시대마다 바뀌어서 예전에는 다른 것이었고 지금은 ’AI’다. 그런데 그 뒤에 벌어지는 일은 소재와 상관없이 매번 비슷하다.
반대로 하면 되지 않을까?
여기까지 서술한 걸 전부 반대로 뒤집으면 그게 직관적으로 잘 굴러가는 프로젝트의 모습이다.
시작이 아래에서 올라온다. 현업이 자기 문제를 먼저 들고 오고 경영진의 지시가 거기에 얹히는데 순서가 이것만 바뀌어도 요구사항 회의의 성격이 달라진다.
그 자리에 실제로 그 업무를 하는 사람이 나온다. 현장 경험이 있어야 무엇이 문제인지부터 정의가 되고 회의가 산으로 가지 않는데 바쁘다는 이유로 아무나 대신 내보내면 그 시간은 양쪽 모두에게 낭비가 된다.
KPI가 양쪽에 걸린다. 현업의 참여가 호의가 아니라 본래 업무가 되고 IT 부서에 몰리던 책임도 실제 업무 주체와 나뉜다. 작은 프로젝트라도 TF를 공식화해야 하는 이유가 생기게 된다.
경영진의 후원이 시작이 아니라 정착까지 간다. 배포하고 끝이 아니라 실제로 잘 사용하는지 모니터링 추적 관찰하여 지속적인 개선점을 도출한다.
성패를 가르는 건 기술이 아니다. 수요와 책임과 성과가 같은 곳에 있느냐다.
실무자로서 할 수 있는 것은 해보아야 한다
이 조건들을 의사결정권자가 아닌 허리급이 모두 직접 결정할 수는 없다.
그렇다고 아주 손 놓고 있을 순 없다. 이 구조가 아니라는 걸 위로 올려 설득해보거나 요구사항 회의에 실제로 그 업무를 하는 사람이 나오게 요청할 수는 있고 작게라도 TF를 공식화하자고 제안하는 것도 그 자리에서 실무자로서는 할 수 있는 일이다.
물론 매번 통하지는 않는다. 그래도 이 얘기를 꺼내는 자리가 있는 것과 없는 것은 다르다.
이런 깨달음을 얻은 후에는 위에서 프로젝트가 내려오면 먼저 이 구조인지 본다. 현업으로부터 이슈 제기가 먼저 되어 올라온 건인지, 공동으로 책임지는 구조가 잡혀 있는지, 안 되면 최소한 TF라도 공식화할 수 있는지. 여기서 답이 안 나오면 그 프로젝트가 어떻게 흘러갈지는 대체로 짐작이 된다.
짐작이 된다고 안 할 수 있는 건 아니라서 결국 하기는 한다. 다만 시작할 때 알고 시작하는 것과 모르고 시작하는 것은 다른데 어디서 무너질지 알면 최소한 그 지점에서 한 번은 붙잡아볼 수 있다.
