개발자도 업무를 알아야 한다는 말의 위험성

개발자가 현업 사용자의 업무를 알아야 할까?

두 가지 상반된 관점에서 얘기할 수 있다. 나 자신도 개발자이지만, 개발자의 입장에서는 알아야 한다. 아는 게 좋다. 하지만 개발자가 현업 사용자의 업무를 알아야만(!) 하는 상황이라면 이미 그 프로젝트 내지 시스템은 막장이란 얘기에 가깝다. (개발자가 초천재인 경우는 빼자. :-p)

왜 그러한가?

공사장의 노가다 인부가 건물주의 요구사항을 알고, 또 설계된 내용을 기억하고 있다면 하다못해 벽돌 하나를 쌓아도 좀 더 고객지향적으로 쌓을 수 있다. 그러나 설계한 사람도, 감리하는 사람도, 작업반장도 없이 일용직 노가다 아저씨가 건물주와 협의하고 그 내용대로 건물을 지어나간다고 하면, 도대체 어느 정신나간 건물주가 그것을 납득하겠는가?

시스템을 구축한다는 것, 업무를 전산화한다는 것은 단지 종이에 쓰는 내용을 하드디스크에 이진수로 기록하겠다는 의미만은 아니다. 전산화는 전략으로서 취급되어져야 하며, 업무의 재구축을 필연적으로 전제한다. 그것은 As-Is 뿐만이 아니라 To-Be도 동시에 고려되어야 함을 말한다. 우리가 이 시스템을 통해 진정으로 달성하고자 하는 목적은 무엇인가? 이것은 시스템 구축에 있어서 가장 핵심적인 질문이다.

그런데, 이러한 시스템이 다루고 있는 업무 도메인에 관한 지식은, As-Is를 파악하기만도 만만치는 않다. 수많은 현업의 현상 속에서, 그것이 가지는 본질적인 목표와 현실과의 타협을 분간할 수 있어야 하고, 그 속에서 버릴 것과 극대화시켜야 할 것을 찾아내어 선진 사례 및 전략과 더불어 To-Be를 설정해야 한다. 뿐만 아니라 To-Be에 이르기 위해 필요한 모든 '유효한' 장치들을 강구해야 한다. 즉, 이 두 가지를 모두 할 수 있다는 것은 이미 현업 업무에 대한 이해가 최상급에 도달하였음을 의미한다.

개발자는 개발의 구체적인 구현을 위해서도 알아야 할 것들이 수없이 많다. 거기에 이러한 컨설턴트적 역할까지 훌륭하게 수행해낼 수 있으면 '천재급'인력에 속한다. (이런 종류의 사람들은 대체로 개발도 상당히 잘한다. 젠장) 그러나 이런 인력만 가지고 프로젝트를 수행하는 경우는 없다. 심지어는 단 한명만이라도 있다면 그것은 행운이다. 그러나 천재의 존재여부에 프로젝트의 명운을 맏기는 건, 로또다. 그러므로 그러한 역할을 개발자에게 맡기는 것은 적절치 않다. 설사 그러한 재능을 보이는 개발자가 있다 하더라도 두 역할을 동시에 수행하게 하는 것은 이도저도 안 될 가능성을 높일 뿐이다.

한편, '갑' (이라고 불리는 협의 담당자) 도 대부분 이 경지에 도달하지 못한 게 절대 다수이다. 거기다 갑은 대부분 자신이 진짜로 무엇을 원하는지 알지 못한다. 특히 To-Be에 대한 막연한 원칙적 인식은 있어도, 여기에 도달하기 위한 '유효한'장치들을 생각해내는 갑을 만나는 일이란 참으로 드물다. 실컷 만들어주니 몇 번 써보더니 불편하다고 접어버리는 갑은 개발자들 술자리의 단골 안주다. 그러나 이건 그의 잘못도, 개발자의 잘못도 아니다. 그 둘 사이에 있어야 할 무엇이 없는 것이다.

가끔 갑들은 어처구니 없이 어려운 요구를 한다. 혹은 종종 임시방편적인 내용을 영속적인 부분에 넣어달라고 한다. 그런데 사실은 이러한 경우 거의 대부분 더 나은 방법들이 존재한다. 그래서 '이렇게이렇게 해서 이렇게 하면 어떨까요?' 라고 하면 적잖은 경우 '아, 그렇게도 되나요? 그럼 정말 좋죠!' 라고 반응을 한다. 여기에는 상상력과 직관 뿐만 아니라 업무에 대한 깊은 이해와 전산화의 본질에 대한 이해가 동시에 수반되어야 한다. (내가 그걸 이해하고 있단 얘긴 아니다. 난 암것도 몰라요.. -,.-;;)

이것은 컨설팅의 영역이다. 또한 전사적 전략의 영역이다. 컨설턴트라는 게 비싼 돈 받고 와서 커피로 몸 축내가며 빡세게 문서작업 하라고 있는 게 아니다. 그러나 우리 사회에서는 아직까지 컨설팅의 가치를 제대로 인정하지 않는다. 절차상의 요식행위로 여기는 경우도 빈번하다. 컨설팅에 들어가는 직접적인 비용은 눈에 보이지만, 그 효과를 얻지 못해 간접적으로 깨지는 비용은 눈에 보이지 않으므로 아까워하지 않는다. 그 결과는 바로 눈앞의 문제만 해결하는 시스템, 심지어는 눈앞의 문제조차 해결하지 못한 채 일거리만 늘리는 시스템으로 나타난다.

그러나 잊어서는 안된다. 그 시스템이 주는 진정한 가치는 빵빵한 병렬 CPU에서 나오는 것이 아니라 유효하게 설계된 시스템의 비즈니스 아키텍처에서 나온다. 설계자는 신이 되어 자신들의 신도(시스템 사용자)들이 교의(설계의 이상)를 성취할 수 있도록 유효한 여러 수단을 시스템을 통해 제공해야 한다. 마치 신이 천사를 보내 그들의 신도들을 권면하듯이. 구현된 비즈니스 아키텍처가 가브리엘이 될 것인가, 아니면 루시퍼가 될 것인가?

대체 고객사는 무엇을 위해 돈을 지불하고 있는가?