왜 IT부서는 스스로 혁신해야 하는가, 2부

* 이 글은 WORKSPACES & INNOVATION 책임자인 Swapnil Deshpande가 ThoughtWorks 블로그에 올린  Why IT departments must reinvent themselves 시리즈 2부를 번역한 글입니다.

지난 글에서 나는 현재 사업 시나리오에 적합하게 유지하기 위해 IT 부서가 취해야 하는 방향에 영향을 미치는 요소들을 설명했다. 이번에는 IT 부서 작업 문화 변화에 대한 생각을 공유하고자 한다.

소트웍스사 CIO인 데이브 웰리Dave Walley가 말한 바 있다. "우리는 IT 부서 역시 우리 회사가 클라이언트에게 하듯 똑같은 방식으로 결과를 전달해야 한다". 전통적으로 조직내에서 IT 부서의 운영 방법은 딜리버리delivery 팀^[1]과는 차이가 있다. 이런 차이는 이들 작업의  속성이 대개는 지원과 유지보수 형태를 띄기 때문이다. 이런 이유로 IT부서를 딜리버리 팀을 대하듯 바라보지 않게 했다.

그러나 더 이상 합당한 이유로 받아들 수 없다. 지난 몇 달 동안 우리는 우리 팀 구조를 바꿔나가며 사업 운영과 부합하게 맞춰왔다. '가치 우선'에 중점을 두고 현실을 대하면, 여타 다른 생산 조직과 다르게 운영하던 식은 더 이상 용납되지 않는다.

우리의 기대는 바로 IT 부서가 스스로 제품 납품^[2]에 중점을 둔 팀으로 변신하는 것이다.

그렇다면 더 이상 지원/운영 팀이 아니란 말인가? 그렇다. 이상하게 들릴지 모르지만, IT 부서는 스스로 혁신을 이끌어서 제품 납품을 지향하는 조직이 되어야 한다는 것이 내 주장이다.

비록 IT 부서의 첫 번째 중점 업무가 운영이고, 업무 시스템의 안정적 실행을 보장하는 일이더라도 우리가 일하는 방식에 지속적으로 의문을 품어야 한다. 적절한 시스템 운영이란 중책 수행과 동시에 IT 부서는 비즈니스 직관을 떠올려서 이해관계자에게 전달해야지, 단순히 지시를 받아 수행하는 것만으로는 안된다.

여기에 몇 가지 간단한 행동 지침이 있다.

• 이해관계자와 공동 작업으로 우선순위 선정을 할 수 있게 돕는확고한 관리 체계를 구비한다. 핵심 이해관계자들에게 당신의 모든 작업을 볼 수 있게 해서 우선순위 선정이 올바로 끝나게 하자.
• 사용자에게 주는 가치 위주로 작업을 끌어가자. 이해관계자나 팀에 가치를 제공하지 않는 작업이라면 그 일을 하는 이유를 반문한다.
• 내부 회의를 열어 주마다 우선순위를 계획하고 진척을 추적한다. 명확한 이정표를 정하고 이를 따른다.
• 지속적 개선을 위한 회고 모임을 주기적으로 갖는다.
• 적합한 소통 채널을 수립해서 여러분의 작업을 공유하고 이해관계자와 교류한다. 빠른 피드백을 받을 수 있는 방법을 마련해놓고 필요하면 우선순위를 수정할 수 있고 방향을 절충할 수 있게 하라.
• 당신의 작업에 대해 IT 부서 밖의 팀에 주기적으로 노출하는 행사를 열고, 이해관계자 피드백을 받아라.
• 가치 생산에 집중하며 효율, 자동화, 사용자 셀프서비스 통로 발굴을 위한 질문을 계속하라.
• 가장 중요한 것은 이해관계자와 파트너에게 공감하여, 그들이 필요로 하는 것을 이해하고, 그들이 들을 수 있는 말로 대화를 하는 일이다

내부 IT팀들이 조직내 유일한 조직으로 갖는 강점은 내부 비즈니스 프로세스와 동시에 시스템 작동 방식을 이해하고 있으며, 인프라를 관리한다는 점이다. 바로 이점때문에 조직의 그 어떤 위치에 있는 이들보다 비즈니스 시나리오 변화가 가져오는 영향을 이해하는데 가장 유리한 위치에 있다.

수직 비즈니스 business vertical를 고려하거나, 조직 내에서 어떤 기술이나 혁신적 아이디어를 고려하더라도 IT 팀은 중요한 역할을 해야 한다는 사실을 발견할 것이다. 이런 점에서 올바른 초점을 갖는다면 IT부서가 조직 운영과 사업 수행에 있어 진정한 차이를 만들어낼 수 있다고 확신한다.

IT팀의 중요성을 생각한다면 딜리버리 팀들처럼 움직이며, 일의 속성과 팀 문화를 크게 혁신해야 할 부분이 있다. 소트웍스를 포함해 여러 조직에서 팀을 주도한 내 경험에 따르면, 팀 문화를 바꾸는 것이 쉽지 않다는 것을 발견했다.

하지만, 변화를 시작하기 위해 할 수 있는 것들이 있다:

• 스스로에게 오늘 가장 중요한 일을 하고 있는지 물어볼 수 있다.
• 당신 일과 결과가 주는 가치를 습관적으로 확인한다.
• 당신의 계획을 다른 그룹에 공유하고 소통한다.
• 반복 작업 대상에 대해 대안을 묻는다. 반복을 정당화할 수 있는 충분한 가치가 있는가? 자동화 할 수 있나? 사용자 스스로가 할 수는 없을까? 그만둬도 되는 일은 아닌가?
• 자신의 작업공간이나 사무실 개선을 돕고 더 많은 스킬을 익힐 수 있는 아이디어를 낸다.
• 사무실, 지역, 팀을 넘나 들며, 함께 만들고 협업하는 방법을 익히자.
• 항상 팀을 우선시하라.
• 자신의 아이디어 한계를 줄여서 자신의 납품 능력에 맞추지 말라. 다른 스킬을 가진 사람들과 합류하여 협업하는 힘을 길러보라.
• 스스로와 팀에게 이른 실패나 빠른 실패는 아무 문제가 없고, 도전하는 과정이 때늦은 실패보다 낫다는 점을 이야기하라.
• 조직을 끊임없이 배우는 조직으로 바꾸라.

팀 문화 변화를 목적으로 할 때, IT 팀들은 인프라와 소프트웨어products의 '생성Create / 구축Build / 구성Configure / 구현Implement^[3] /출시Roll out / 담당Own / 지원Support'를 아우르는 전 범위의 스펙트럼을 다뤄야 한다.

일상 업무와 유지보수에서 혁신과 가치 창출로 초점을 옮기면 작업은 더욱 흥미롭고 도전적이 된다. 이로써 IT 팀들은 그들이 지금까지 해온 것에 비해 훨씬 큰 차이를 만들 수 있다.

역자 주석

[1] 저자에게 추가 질문으로 얻은 설명:

In the context of my article, when I say delivery team I mean of a team that delivers projects. Typically operations and IT teams are business as usual heavy and has a lot of on going work. My recommendation is to work like how a development and delivery team delivers agile projects. The IT teams should look at every work as a project and start working like a delivery team.

기업내부 IT팀이 기존에는 직접 개발하지 않았다는 점에서 딜리버리 팀은 직접 개발을 하고 애자일 프로젝트 형태로 결과를 전달한다는 특징을 갖는다고 설명한다.

역자 보충 설명:

내앞에 있는 사람에게 구두로 설명한다면, delivery team을 직접 번역하는 대신에 '인터넷 서비스 회사 처럼'과 같은 식으로 조직 문화를 우리나라 맥락에 맞춰 말했을 것이다. 번역하는 글이라 단호한 소신을 실천하기보다는 원저자의 의도를 지키려고 망설였다. delivery team에 대한 보편적인 우리말 대안은 아직 없다고 생각한다. 그래서, 역자와 지식과 검색 결과에 기초해 두 가지 중요한 특징을 여기 설명한다. 정확한 번역 자체보다는 독자의 상황에 맞춰 배경 지식을 넓히는 편을 결정했다.  하나는 비즈니스 가치에 맞춰 개발과 운영을 한 호흡으로 소화하는 조직을 지향한다. 이때문에 '인터넷 서비스 회사처럼'이라고 쓰고 싶은 충동이 있었다. 두번째는 IT가 형태가 주로 소프트웨어 형태(혹은 형태가 모호한 모습)로 제품으로 전달되기 때문에 보편적인 제품생산 조직처럼 시장과 고객에 책임감있고 기민하게 반응해야 한다는 점이다. 이럴 때는 delivery team이 '일선 생산 조직' 이나 '현장 서비스 조직' 의미로 볼 수도 있다.

[2] 딜리버리 팀과 달리 delivery는 제품 납품이라고 풀었다. 제품이란 표현이 어색하긴 하지만 IT가 점차 상품과 서비스의 일부를 위치를 차지하고 있다. 그런 변화에 맞춰 '지원'이란 태도가 아니라 '제품 생산과 전달'을 책임지는 태도를 지향해야 한다. 소프트웨어 개발과 운영이라는 일이 보편화 되면서 어떤 면에서는 과거 생산 조직이나 서비스 조직이 축적한 노하우를 흡수해 응용해야 한다. 한편, 영어권에서는 Product란 표현이 이미 보편적으로 쓰이고 있기도 하다.

[3] 구축과 구현은 Build와 Implement를 각각 번역한 것인데, 그 의미가 모호해 저자에게 문의한 결과 Build는 없는 것을 만드는(구매와 구축 중에 택일) 것이고, Implement는 구입할 솔루션과 함께 통합하여 원하는 소프트웨어로 만드는 과정이다. 아래는 저자의 답변이다.

In my mind, the difference is as follows, Implementation - Taking a COTS product (i.e., commercially available) and implementing it for your needs. This involves configuration, deployment and modification of the product as needed. Building - This involves building a product from scratch. i.e., ideation, prototyping, programming & developing, testing and developing as a product and deploying.