[칼럼]IT프로세스에 대한 불편한 진실

2000년 대 중반을 넘어서면서 국내 IT조직들은 IT프로세스를 갖추기 위한 여러 가지 노력을 해오고 있다. IT조직간의 높낮이는 있지만, 과거에 비해 IT프로세스의 필요성을 인정하고 프로세스 도입을 위해 적지 않은 비용 투자를 해 오고 있다.

그렇지만 IT프로세스를 ‘장착’한다고 해서 IT프로세스가 ‘완성’되는 것은 아니라는 것을 아직도 잘 이해 못하는 IT조직이 많다. 이것은 마치 값비싼 보안 장비를 도입하면 보안 사고가 나지 않을 것이라고 철석같이 믿는 우매한 경영진들의 모습과 유사하다.

IT프로세스를 형식적으로 도입한 IT조직이 IT프로세스의 혜택을 얻기는커녕, IT프로세스에 치어서 허덕이거나 괴로워하는 모습을 자주 목격한다. IT프로세스를 없던 시절을 동경하기까지 한다.

도대체 무엇이 문제일까?

■짧은 역사의 IT프로세스

프로세스는 IT뿐만 아니라 모든 비즈니스 군에서 통용되는 도구다. 제조업에서는 제품을 중심으로 마케팅, 영업, 구매, 생산, 출하 등의 과정을 대단위 프로세스라 부르고, 이것을 잘게 쪼개 세분화된 소단위 프로세스들을 정의하고 관리한다. 제조업이 활발하게 일어난 산업혁명 시대를 거쳐 지금까지 제조업 프로세스는 발전을 거듭해오고 있다.

IT분야의 프로세스는 제조업에 비해 역사가 짧고 비가시적(invisible)이다. 이것은 IT프로세스를 대단위 프로세스와 소단위 프로세스로 구분해내는 디테일이 아직 명확하지 않다는 것을 의미한다. 따라서 IT프로세스를 도입하는 것이 녹록하지 않았던 것은 당연하다.

하지만 인터넷이 활성화되고 모든 비즈니스 영역이 IT의 놀라운 능력과 혜택을 누리기 시작한 1990년대 이후로는 IT프로세스에 대한 표준과 가이드도 모습을 드러내게 된다. 이러한 표준과 가이드들 덕분에 IT프로세스는, 그 출발은 늦었어도, 상당히 빠른 속도로 발전해오고 있다.

■여전히 불안정한 IT업무방식

IT의 역사가 짧은 것은 IT의 일하는 방식이 정형화돼 있지 않을 가능성이 높다는 것을 의미한다. 국내 IT조직이 IT서비스를 제공하는 것만을 전문으로 하는 독립 기능의 모습을 갖추기 시작한 것도 사실 그리 오래된 이야기가 아니다. 현재도 비즈니스에 속해서 일회성 IT 기능을 제공하고 있는 경우가 있다.

프로세스는 안정된 업무 방식을 가진 조직에게 최상의 성과를 제공한다. 만약 IT사용자에게 IT를 제공하는 방식이 불안정한 IT조직에게 IT프로세스를 덧씌우면 어떤 결과가 나올까?

IT담당자는 IT프로세스 때문에 일을 못하겠다고 아우성치면서, 마치 IT프로세스를 따르고 있는 흉내와 가짜 정보만 전달하고 ‘음지’에서는 끊임없이 프로세스를 우회하는 방법을 통해 예전처럼 일하게 된다.

이런 상황을 알리 없는 순진한 IT경영진은 IT프로세스가 잘 지켜지고 있다는 보고만 받고는 IT사용자나 비즈니스가 제기하는 불만들이 왜 생기는지를 도대체 이해할 수 없으며, 심지어는 이것을 IT사용자나 비즈니스의 ‘오해’에서 비롯된 것이라고 편하게 생각하기도 한다.

국내 IT조직에서 가장 흔히 볼 수 있는 IT프로세스 붕괴의 모습이다.

■자동화 툴과 IT프로세스

프로세스를 도입하는 것을 자동화된 툴을 도입하는 것이라고 오해하는 경우가 많다. 프로세스는 수동적인 방식으로 도입할 수도 있고, 자동화된 툴이 존재한다면 이 툴을 이용해서 좀더 자동화된 프로세스를 적용할 수도 있다.

국내 IT조직들은 대부분 자동화된 툴을 통해 IT프로세스를 도입하고 있다. 따라서 국내 IT조직이 오해하는 것 중의 하나가 ‘IT프로세스를 자동화시키면 IT프로세스 도입의 목적이 더 쉽게 달성된다’고 믿는다는 것이다.

국내 제조업의 경우, 과거에 주먹구구식 제조 공정에 ERP라는 자동화툴을 도입했을 때 현장부서와 도입을 추진한 부서 양 쪽이 엄청난 고통을 겪었다. 제조 공정의 업무가 안정되지 않은 상태에서 정형화된 프로세스가 얹혀진 자동화 툴의 도입은 혼란을 초래할 수 밖에 없다.

IT조직도 마찬가지다. IT의 일하는 방식이 불안정하거나 정리되지 않은 상태에서 IT프로세스의 개념이 장착된 자동화 툴을 도입하게 되면, 이를 받아들이지 못하는 대다수의 IT직원들은 불평과 불만을 쏟아낼 수 밖에 없다. 이러한 상황이 해결되지 않으면 IT프로세스 도입 목적은 지연되거나 좌절될 수 밖에 없다.

■부실한 기록과 IT프로세스

자동화된 IT프로세스 툴을 도입하면, 프로세스를 우회하거나 잘못된 방법으로 처리하는 것을 원천적으로 차단할 수 있다. 하지만 여기에도 근본적인 문제점이 존재할 수 있다. 이것은 기록에 대한 문제다.

프로세스가 몸통이라면 기록은 심장이다. 프로세스에 따라 업무를 처리하는 데만 그치는 게 아니라 업무 처리의 이유와 결과를 기록해야만 프로세스가 완성된다.

예를 들어 프로그램을 개발하는 일반적인 IT프로세스에는 프로그램에 대한 테스트가 포함되어 있다. 프로그램 테스트 결과에 언제나 ‘이상 없음’으로 기록되어 있다면, 이를 어떻게 받아들여야 할까?

IT프로세스가 없던 시절 개발자가 알아서 다 처리하던 때에는 가끔씩 IT부서장이 “테스트 했지?” 라고 물어보면 개발자가 그렇다고 대답하는 과거 IT조직의 모습과, IT프로세스가 자동화되어 있으나 테스트기록에 ‘이상 없음’이라고 기록되어 있는 현재 IT조직의 모습과는 별반 나아진 점이 없다.

■기록에 대한 저항들

기록에 대한 저항은 제조업이나 다른 산업들에 비해 IT조직이 특히 유별나다. ‘일이 우선, 기록은 차선’이라는 신조로 내세우는 IT조직들이 많다. 사용자가 원하는 IT화면을 빨리 만들어 주는 것이 당장 해야 할 일이지 IT프로세스를 지키면서 미주알 고주알 상세한 기록까지 남길 필요성을 못 느낀다는 것이다.

이렇게 만들어진 IT프로그램은 저질의 짝퉁 제품과 다를 바 없다. 겉은 비슷할 지 몰라도 조그만 사용해보면 조악하다는 것을 사용자들은 알 수 있다. 프로그램의 버튼을 누르면 기본 기능은 작동되지만 조금만 다른 방법이나 다른 값들을 입력하면 작동하지 않거나 엉뚱한 결과를 보여준다.

꼼꼼한 사용자들은 이런 IT프로그램을 IT조직에 신고한다. 하지만 이를 접수 받은 IT조직은 어디부터 손을 대야 할 지 모른다. 프로그램을 테스트할 당시의 기록이 전혀 없거나, 있더라도 형식적이기 때문에 왜 이런 오류가 발생했는지를 되짚어 볼 방법이 없다.

IT조직이 할 수 있는 것이라고는, 꼼꼼한 사용자가 지적한 내용들을 바탕으로 다시 프로그램을 만드는 수 밖에 없다. IT프로세스내의 부실한 기록은 이러한 상황의 무한 반복을 초래하고 IT사용자들은 등을 돌리게 된다.

기록의 디테일은 IT서비스 품질 수준에 비례해서 깊어진다. 최고의 IT를 제공하고 싶으면 IT프로세스상의 기록도 최고 수준으로 디테일해야 한다. 상세하면서도 농축된 기록 없이는 최고 수준의 IT가 탄생할 수가 없다.

■IT프로세스는 완성이 아니라 여정

IT조직은 IT프로세스를 통해 무엇을 기대하고 있을까? 세계 또는 국내 최고 수준의 IT서비스 제공을 꿈꾸는가? 아니면 IT조직 내부를 투명하게 들여다 보고 비용에 대한 성과를 확인해보고 싶어서 일까? 또는 다른 IT조직에 뒤처지는 모습을 보이고 싶지 않아서 일까?

IT프로세스 도입 목적에 따라 IT프로세스의 모습과 수준은 달라질 수 있다. 그러나 IT프로세스에 공통적으로 적용되는 원칙은 동일하다. 안정된 IT 업무 방식이 준비되어 있어야 하고 IT프로세스 도입 목적에 걸맞은 기록이 유지되어야 한다. 이러한 원칙을 지키지 못할 때 도입된 IT프로세스는 혼란과 자원낭비의 부작용을 불러올 가능성이 크다.

가끔 잘못 도입된 IT프로세스로 인한 부작용을 빌미로 IT프로세스 무용론을 설파하는 IT조직을 만난다. 심지어 IT프로세스는 서양의 제도이므로 국내 정서에 맞지 않는다고 국수주의적인 주장을 하기도 한다.

또 자동화된 툴을 가지고 있어서 IT프로세스가 완벽하게 적용되고 있다고 자랑하는 IT조직들을 만나게 된다. 그러나 내부를 들여다보면 다들 ‘하고 있는 척’을 할 뿐이다.