인공지능이 발달하여 자연어처리가 가능해진다면 인간이 의도하는 대로 컴퓨터가 처리해 줄 수 있을까? 라는 질문에 나는 절대 불가능하다고 생각한다. 현재의 사회 및 기업환경에서는‥
기술이 아직 발달하지 않아서가 아니다.복잡하고 세밀하게 변화 발전하고 있는 이 시대에서 문맥에 맞는 주제와 내용으로 다른 사람들을 공감하게 할 자신이 있는가? 그러려면 쏟아지는 수많은 정보들 중 현재 처한 환경과 적절한 관점에서 논지를 뽑아낼 수 있어야 하고 내 말을 듣는 사람들의 수준과 초점에 맞추어 표현할 수 있어야 한다.
여러분은 자신이 표현하려는 것이 정확히 전달되지 않는 것을 본적이 많을 것이다. 그렇다면 기업이 구사하려는 전략과 제품 및 서비스는 어떻게 정확히 만들어 제공하고 그 사업을 계속 관리할 수 있을까?
토요타에서는 process가 없으면 아무 일도 하지 않는다고 하는데, 모든 일은 2가지 관점에서 생각해볼 필요가 있다. 첫째는 시간이다. 기업과 개인이 일함에 있어서 시간이 흐를수록 지식이 축적되고 경험이 고도화되느냐가 관건이다. 둘째는 규모다. 현재의 규모가 2배, 5배, 10배, 100배로 커질수록 생산성이 그 배수만큼 늘어나거나 더 나아가서는 시너지를 일으켜 기하급수적으로 증가할 수 있을 것인가 이다.
시간과 규모가 늘어날수록 발전하려면 나 혼자 잘해선 절대 될 수 없다. 동료와 기업전체가 같은 문맥에서 움직일 수 있어야 한다. 기업의 사훈과 정서적 분위기도 물론 중요하지만, 지금은 이것을 얘기하는 것이 아니다.
기업의 의사소통은 엔지니어링 되어야 한다. 동료, 상사, 부하, 거래사간 의사소통이 정확해지고 시간이 흐르고 규모가 커질수록 생산성이 배가됨은 물론 지식이 축적되기 위한 엔지니어링의 출발점으로서 우리는 잊고 있는 기본을 뒤돌아봐야 하는데 언어소통은 무엇보다 중요하다. 규모가 작은 수공업체제에선 바로 옆 동료에게 말로 전화로 전달하면 소통이 되었다. 만나서 눈빛을 보므로 표현은 좀 애매하더라도 전체적인 문맥은 알 수 있었다.
하지만 이제는 그렇게 일할 수 있는 시대가 아니다. 내가 며칠 전에 작성한 문서를 보면서 `이게 어떤 관점과 문맥에서 작성 했었더라`는 의문을 가진 적이 없는가? 내가 원하는 것을 나 스스로도 정확히 표현하고 정의하지 못하는데 하물며 남에게는 더욱 정확히 전달하거나 남이 만들어 놓은 문서를 정확히 이해하는 것은 더욱 어렵다.
미실의 눈빛연기에 반하는 건 드라마일 뿐이다. 1400년이 지났다. 훨씬 정교하게 의사 소통할 수 있어야 하는데 항상 우리는 애매한 언어생활을 하고 있다.`아륀지는 색깔이 좋다’ ‘곰은 간이 좋다`. 이 두 문장의 공통점과 차이를 발견할 수 있는가? 사과와 아륀지는 틀린 것인가 다른 것인가?
다문화 가정 관련한 공익광고에서 2중 효과를 내는 좋은 문장을 발견하였다. "우리는 틀린 것이 아니라 다를 뿐입니다."
컴퓨터를 사용하지만 우리의 습관은 달라지지 않았다. 인공지능이 발달하여 컴퓨터가 자연어처리를 잘할 수 있고 간단한 문장을 처리할 수는 있어도 기업의 복잡하고 정밀한 문맥에선 쓰이지 않을 것이다. 상기에서 말한 예를 생각해본다면 인간이 말하는 그대로 수행했다가는 큰일이 날 것이란 것은 쉽게 추측할 수 있다. 문서화 되었어도 중복과 누락, 애매함은 문서에 그대로 존재하기 때문이다.
2차 대전을 치르면서 세계가 경험한 것 중 하나가 요구관리시스템이었다, 전투기 성능을 향상시키고 최신 전투기를 생산해내기 위해 단순히 공장기술자들만 동원되었을리는 없다. 조종사, 공군사령부참모, 기계설계자, 군수조달참모, 과학자, 관리자 등 많은 전문가들이 동원되어 하나의 목표를 이루기 위해 의사소통 했을 것이다.
다양한 기종을 몇 년 동안 동시에 다뤄야 하는데 참여자들이 전사하거나 다른 부서로 이동함에 따른 부작용까지 최소화해야 했다. 일선에서 요청하는 요구사항이 그 동안 변하지 않았을 리가 없다. 전장의 동적 상황변화에 따라 달라짐은 물론 여전히 애매모호함이 존재했다. 이를 해결하기 위해 비행장격납고를 축구장 몇 개만한 크기로 짓고 문서를 그 안에서 관리하면서 끈을 이용하여 문서의 변경 및 추적을 표시하였다.
그때와 지금을 비유하자면 몇 백개의 혹성에 쏘아 보낼 인공위성을 지금은 몇 십개씩 동시에 만드는 시대이다. 그리고 명령으로 일이 진행되는 시대가 아니라 대중, 직원들로부터 지식을 뽑아내는 수평적 문화를 전개하지 않으면 안 되는 시대이다. 즉 소비자와 생산자를 포함하는 이해당사자와 의견발제가능자의 계층이 폭발적으로 다양화한 웹2.0시대이다.
코끼리를 냉장고에 보관하기 위해 – 냉장고 문을 연다, 코끼리를 넣는다, 냉장고 문을 닫는다 - 이것은 Needs이지 Requirement가 아니다. Needs를 보다 더 문맥에 맞게 해석하고 분석하는 엔지니어링과정을 거쳐야 비로소 Requirement가 만들어진다. 이러한 엔지니어링은 의사소통의 표준과 도구를 필요로 한다. 엑셀과 같은 오피스 도구를 가지고 인공위성은 물론 탱크, 자동차, 휴대전화를 만들 수 없다.
몇 개월 전 어떤 최신 스마트폰을 구매하여 사용했는데 어떤 기능을 사용한 후에 그 메뉴에서 빠져나올 수 없어서 결국 전원을 끄고 다시 켜야만 했다. 어떤 자동차업체에선 설계자가 애매하게 써놓은 요건(기술과 제품명이 동일한 동음이의어로 인해 관점의 계층이 달랐음)을 구현 기술자가 나름대로 해석하여 만들었는데 그로 인한 고장으로 리콜을 해야만 했고 회사는 엄청난 손해를 입었다.
기업의 의사소통에는 표준이 있어야 한다. 이메일, 엑셀과 같은 오피스 도구는 직원들에겐 일견 편해 보인다. 직원 본인만의 형식으로 써버리면 그만이니 시간이 흘러서 그것을 다른 사람은 물론 작성자 본인도 해석할 수 없다. 그 파일이 어디로 흘러가서 누구에게 공유되고 수정되었는지는 알 길이 없다. 그 안에 적혀있는 정보들은 지식화되지 않는다.
여기서 잠깐 지식화를 논해보자. 책을 통해 선조의 지식이 공유되었기에 우리가 똑같은 시행착오를 거치지 않고 더 나은 지식을 쌓을 수 있었듯이 정보는 어느 그릇 안에 함께 담겨져 많은 사람들에 의해 분류되고 정련화되어야 비로소 의미 있는 지식이 될 수 있다.
요구사항을 관리하는 가장 중요한 이유는 품질뿐 아니라 생산성을 향상시키기 위한 것인데 그 과정에서 기대하지 않았던 부가가치가 발생하게 된다. 시간이 흐를수록 기업의 활동이 지식으로서 축적되는 것이다.
요구사항 자체가 지식으로서의 가치를 지니므로 이에 상응하는 관리체계를 필요로 한다. Philip Crosby는 요구관리를 잘하면 품질은 저절로 따라온다고 하였다. 요구사항을 잘 관리하면 전체 공정의 50%는 완성된 것이나 다름없다. 갈수록 기업활동의 앞 단계가 지식을 필요로 하는 활동이 되며 뒤로 갈수록 비용만 들이면 할 수 있는 저부가 가치로 넘어가고 있는 와중에서 정확한 요구관리는 예기치 못한 문제를 최대한 예방할 수 있는 기본이 됨은 물론 시간이 지날수록 기업이 필요로 하는 지식이 계속 쌓이게 되어 지식을 판매할 수 있는 토대가 만들어진다.
IT관련사안을 짚어보자. IT도 다른 생산산업의 공정에서와 마찬가지로 요건분석, 설계, 구현, 개발생산, 테스트와 유사한 단계를 거친다. 기업전략에 따른 요건이 정확히 기술되지 않고 이해 당사자들이 정밀하게 개별 요건들의 합의기준을 명시되지 않는다면 단계가 뒤로 갈수록 더 큰 위험성이 발생한다. 비용을 더 투자한다 더라도 시간은 되돌릴 수 없기 때문이다. 또한 앞서 언급한 바와 같이 요건 자체가 오피스도구에 담아져 있으면 기업이 관리할 수 있는 수준의 지식으로 발전하지도 않는다. 결국 1회용으로 쓰고 버리는 것을 되풀이해왔다. 그러니 투자하고 있는 시간과 비용을 재 동력화 하는 것은 요원하다.
최근 금융권에서 화두가 되고 있는 통합테스트를 보면 이제라도 그 필요성을 인지한 것이 다행이라고 생각한다. 하지만 테스트단계에 국한하여 문제를 해결하는 것은 부분최적화일 뿐이다. 폭포수(waterfall)처럼 시간을 되돌릴 수 없기에 앞 단계에서 이미 문제의 소지를 내포하고 시작한 결과물을 테스트단계에서 아무리 잘 검증한다고 해도 wrong things를 doing things rightly로 하는 것과 마찬가지이다. 테스트뿐 아니라 앞 단계를 포함한 전 공정에서 doing right things를 할 수 있도록 전체 프로세스를 감안하여야 제대로 된 목적을 이룰 수 있다. 요구사항과 품질관리는 V모델을 통해서 긴밀하게 시너지를 발휘하게 되며 각 계층의 이해당사자들이 프로세스의 각 단계의 문맥에서 품질을 담보할 수 있도록 해준다.
요구관리는 모든 조직활동의 기본이 되어야 하는데, 여기서 관리라 함은 정의, 변경, 추적, 공유, 조정, 통합이라는 활동을 포함한다. 예로 생산 및 설계활동에서 현재 따로 관리되고 있는 요구사항분석/설계문서작성/개발 생산은 요구관리단계부터 동기화해야 한다. 이렇게 되면 시간이 흐를수록 앞서 언급한 대로 당장의 어떤 제품을 생산하기 위한 목적뿐 아니라 지식으로서의 부가가치를 만들어낼 수 있게 된다.
IT관점에서 얘기한다면, 요구사항이 모델과 연결되어 물리적 환경(즉 코드와 하부시스템)에 구애 받지 않고 업무지식을 축적하고 조립할 수 있게 되는 것이다. 이 장점은 엄청난 경쟁력을 확보하게 해준다. 이미 유수기업(Nokia, Accenture, IBM등)에서는 이 가능성을 보고 요구관리를 일찍이 도입하였다. 추정컨대 시간이 흐를수록 지식이 축적되는 체계를 갖춘 IT기업이라면 앞으로 몇 년 후엔 K은행을 방문하여 이렇게 말할 것이다.
"지금까지는 귀행의 차세대 IT시스템을 구축하기 위해 SI사들이 2년간 2천억을 들여 400명이 상주하여 개발해주겠다는 제안을 해왔으나 우리는 지금 이렇게 제안합니다, 6개월간 600억 비용으로 전세계의 금융best practice중 귀행이 선택한 것을 바로 조립하여 제공하겠다".
우리나라의 IT교육 문제점 중의 하나가 programming위주의 교육이다. 지금까지 국내의 SW개발자는 자신이 컴퓨터 앞에 앉아 뭔가를 빠르게 개발하면 잘한다고 생각했다. 또한 H/W장비처럼 한번 만들면 계속 사용할 수 있다고 생각했다. 하지만 그것은 틀렸다.
그냥 혼자 그리고 개발만 하면 그 후에 있을 변경은 어떻게 수용할 것인가? 수명주기개념도 없었으니 당연히 사용한 후 버리는 H/W처럼 생각하게 되었고 따라서 유지보수조차 생각하기 어려웠으니 계속 새로 개발하는 것이 차라리 빠르다고 개발자나 발주자나 생각한다. 왜냐하면 S/W개발자는 다른 사람과의 의사소통이 아니라 그저 개발 언어만 잘 구사하면 되는 줄 알았던 것이다. 국내 IT 교육 체계의 가장 심각하고도 고질적인 병폐가 바로 개발언어 교육부터 시작하는 것이다.
그러니 모두 빌게이츠를 꿈꾸고 이찬진을 꿈꾸다가 결국 3D업종이라고 자조하는 개발자로 전락하고 만다. 그러니 architect를 아무리 강조해도 그 역할이 어떤 가치를 지니는지 알 수 없다. 개발언어는 일부 일뿐이고 오히려 부가가치는 요구분석, 아키텍처 설계, 컨설팅, 등등에 있으며 앞으로 개발이라는 단계는 자동화되어 도구에 의해 교체될 것이다.
사업부의 요구사항을 정확히 기술함은 물론 개발생산부서가 이해할 수 있는 표현으로 컴파일 할 수 있는 능력은 앞으로 훨씬 더 각광받을 것이다. IT속담 중의 하나가 "programming으로 불가능한 것은 없다" 이다. 어떠한 S/W이든 programming을 했기 때문에 만들어진 것은 맞다. 그런데 sourceforge.net에 들어가보라. 지천으로 널린 것이 오픈 소스이고 소프트웨어이다.
소프트웨어산업은 단순히 "저런 건 나도 시간만 주면 코딩해서 개발할 수 있어"라는 산업이 아니다. 개발 잘하는 몇 명의 개발자에 의존하는 것은 이미 지났고 고도화된 산업 즉 규모의 경제, 전세계적 개방형 표준공유시스템, 글로벌 베스트 프랙티스를 받아들일 수 있는 구조, Full life cycle통합 자동화, 정련된 지식의 축적가능구조로 급속도로 변모했다.
국내의 좁은 시장기회로 인한 어쩔 수 없는 중소벤쳐들의 반복되는 흥망으로 인해 기업이 손해를 무릅써서는 안될 것이다. 우리나라는 어쩔 수 없이 수출에 상당부분 의존할 수밖에 없다. 전세계에 우리 기업들이 제품을 팔려면 전세계가 사용하고 있는 platform에 얹어야 인정받을 것이다. "우리 것이 좋은 것이여"를 적용할 수 있는 분야와 전세계를 상대로 현실적이고 정교한 전략을 구사해야 하는 분야를 구별할 수 있어야 한다.
모든 분야를 다하겠다는 것은 전략이 없는 것이다. 우리의 IT개발수준을 진일보시킨다면 다양성과 꼼꼼함이 요구되는 전세계 application시장에 진출하여 성공할 수 있겠지만 우리만의 외침만으로 전세계에 나가봤자 인정받지 못한다.
체계는 도구 안에 채화되어 있어야 한다. 국내에 숙달된 IT전문가들이 없다는 얘기는 전부터 있었다, 그 이유 중 하나는 도구에 숙달될 시간이 없기 때문이다. 전문가는 자기가 사용하는 연장에 익숙해야 한다. 그런데 이런저런 도구를 계속 바꿔가며 사용할 수밖에 없으니(벤처기업의 흥망으로 인해) 계속 살아남는 도구에 숙달할 시간이 없는 것이다. 그럴 바에야 내가 직접 만들어 사용하지 라는 "programming으로 불가능 한 것은 없다" 정신에서부터 비극이 싹튼다. 우리는 수공업 mind를 경계해야 한다, 내가 직접 뭘 만들어 쓰겠다면 이미 자동화, 지식화는 물 건너간 셈이다.
국내 IT산업의 독특한 특성인 Big Band 방식에는 단점이 있으나 급속도로 정보화시킬 수 있는 장점도 있다. 하지만 우리는 그 장점을 살릴 수 없었다. 왜냐면 정보를 도구라는 그릇에 담지도 못했으니 축적할 수 없었다. 일부 담긴 했으나 전언한 바와 같이 그 그릇제조사들이 흥망을 반복하는 바람에 지속적으로 일관성 있게 담을 수 없었다.
그러나 지금이라도 시작하면 장점을 살려 글로벌경쟁력을 갖출 수 있을 것이다. 요구관리를 통해 지식화(모델과 통합)하고 글로벌업체와 손잡고 세계시장을 공략할 수 있을 것이다. 기업의 규모가 크면 클수록 더욱 효과를 볼 것이다. 원시인은 혼자 사냥하면 토끼도 잡기 어렵지만 함께 사냥하면 맘모스도 잡을 수 있다는 것을 깨달았다. 요구관리는 맘모스를 백발백중으로 잡을 수 있도록 모든 이해당사자들이 긴밀하게 협력하는 확실한 체계이다.
-한국IBM 소프트웨어그룹 래쇼날 사업부장 이승재