개발자는 비즈니스 로직을 알아야 한다.

우선 나의 회사에서의 입지에 대해서 팀장은 이제야 사장의 신의를 받게 된 것에 대해 다행으로 여기고 있었다. 음, 나는 그동안 못한 것은 없다고 생각했는데 무슨이유에서 이제 와서 신의를 받게 된 것이랄까? 역시 내가 간과하고 있었던 것은 최근에 내가 단독으로 진행하고 있는 작업이 있다는 것이다. 아 물론 사실 다른 유지보수 건들도 대부분 나 단독으로 진행하고 있긴 하지만 그건 역시 말그대로 유지보수인지라 크게 인정을 못받는가 보다. 이번 단독 프로젝트는 사실 회사에 딱히 닷넷 개발자가 있는 것도 아니고 그렇다고 또 이 사업이 돈이 되는 것도 아니다. 단지, 추후에 프로젝트를 따기 위해서 우리 회사에서 무료로 해주는 일종의 봉사이다.

이런 업무를 하게 되서 부끄러운점은 전혀 없다. 다만 나는 내가 좋아하는 것이 아니면 사실 하는게 하는 것 같이 안느껴져서 크게 흥미를 못느끼고 조금 일을 분배해 가면서 약간의 열정만 첨가해서 작업을 해 나가고 있었는데 그게 참 다른 사람들의 눈에는 좋게 보였나 보다. 하물며 내가 비즈니스 로직을 이해하려고 팀장에게 계속 질문을 해가면서 겨우 1차적으로 기능을 만들어 놓긴 했는데 그렇게 해서 결과적으로는 고객을 만족시켜줄 수 있어서 좋게 보였나 보다.

무엇보다 오늘 대화의 요점은 내가 컨설턴트를 희망한다고 일전부터 팀장에게 몇 번씩 말한 것에서 비롯되었다. 기술 컨설팅과 영업 컨설팅. 이 둘의 차이점은 무엇인가? 기술컨설팅은 말그대로 기술을 다루는데 이는 충분한 기술에 대한 정말이지 개발자적인 이해를 토대로 고객이 문제삼고 있는 부분을 기술적으로 요목조목 해결할 수 있도록 도와주는 것이다. 반면에 영업 컨설팅은 우리가 가지고 있는 기술을 말과 어느정도 시청각을 활용해서 어필을 하고 계약을 따는 것이다. 이 과정에서는 분명 우리가 아는 말그대로의 영업 단계가 충분히 들어갈 수 있지만 기술 컨설팅은 그게 아니다. 정말 충분히 그 기술에 대해 인지하고 접한다는 점에서 영업과는 확연히 다르다.

그래서 이 두분의 상사는 내게 강조한다. “비즈니스 로직“을 이해하라는 것이다. 왜? 프로그래밍을 하다 보면 누구나 그러겠지만 작은 부분에서 쾌감을 느끼는 경우가 많다. 한 예로 프로그램 전체 구동 속도를 몇초 단축시킨다던지, 릴리즈 된 파일을 1kb 줄였다던지, DB query result속도를 0.001sec 단축했다던지. 그런 것에서 상당한 희열을 느낀다. 왜? 우리가 그렇게 프로그래밍 기술을 닦아왔기 때문이다. 공학적으로 접근해서 그런지 숫자가 상당히 와닿고 내부 로직 구현에 있어서 알고리즘을 멋드러지게 짜면 프로그래머들 사이에서는 “저 친구는 어떻게 저런 생각을 하지?” 라는 일종의 존엄성까지 기대하는 바램에서 이다.

하지만 실제로 고객들의 입장에서 바라보면 속도도 그렇지만 결과가 우선이다. 눈으로 보는 것으로 모든 것을 평가한다. 그래서 사실 디자이너들의 작품은 척 봐도 노고를 쉽게 알 수 있지만 프로그래머들이 속도를 1~2초 단축했다고 해서 이게 고객한테 확 와닿는가? 천만의 말씀. 차라리 그것보다 100장의 페이지가 있으면 10장이라도 더 만들어서 보여주는 것이 낳다. 개발자가 생각하는 질보단 양이라는 말이다. 기술적인 구현이 없어도 일단 보이는 완성도를 높히는 것이 그들에게는 훨씬 와닿기 때문이다.

개발자들은 사실 부분적인 모듈을 만들다 보면 그 욕심에서 잘 헤어나오질 못한다. 그래서 딜레이 현상이 계속되는 것도 있다. 물론 내가 SI쪽을 해본 것은 아니지만 어느정도 업계 이야기를 들어보면 그렇다. 그리고 이러한 개발자들의 해결책에는 다름아닌 “비즈니스 로직”이 있다.

비즈니스 로직이란, 고객이 원하는 프로그램에 대해 원하는 것이 무엇인지 파악하고 이를 전체적으로 로직화 하는 것을 말한다. 한마디로 말하면 프로그램 전체 모듈이라고도 할 수 있겠다.

왜 개발자들은 이런 비즈니스 로직을 명확히 알아야 하는가? 위에서 언급했듯이 부분만 보고 그쪽에 너무 욕심내는 과욕을 범하지 않기 위해서가 아마 가장 근접한 정답이 아닐까 싶다. 비즈니스 로직을 알고 내가 어떤 것이 중요하고 이것을 위해 어떻게 개발해 나갈 것인지를 알면 기능에 있어서 우선순위가 정해진다. 그리고 우선순위대로 한다면 분명 보이는 부분이나 고객이 최우선적으로 원하는 부분을 먼저 작업해 놓는다면 그것은 고객들에게 있어서 “아 이친구 내 요구대로 정확히 하고 있구나.” 라는 신뢰감과 안심을 줄 수 있다. 반대로 큰 그림을 못보고 쓸때없는 부분모듈에만 집중한다면? 불보듯 뻔하게 그 개발자는 말그대로 삽질하는 것과 다를 바가 없다.

개발이든 뭐든간에 고객이 생명이다. 그래서 더더욱 고객의 말에 경청하고 고객 입장에서 생각해야 한다는 것이다. 더 이상 회사는 학교가 아니고 돈을 주고 다니는 곳이 아닌, pay를 받고 다니는 곳이기 때문이다.

그런데 그러한 비즈니스 로직을 제대로 익히려면 SI업체에서 일해야 한다고 한다. 아직 이 부분은 나로썬 잘 이해가 안 가지만 특히나 난 SI쪽은 가기 정말 싫다. 내가 들어온 바도 그렇고 평도 그렇고 정말 우리나라 개발쪽은 조금 아니라는 생각이 깊이 든다.

그렇다면 어떻게 해야 하나? 라는 생각을 해 보았을 때 일단 지금 회사를 다니며 다양한 기술을 접하고 한 두개의 프로젝트를 진행하는 것. 대학다니면서 학력과 수상, 그리고 여럿 재택/상주 프로젝트를 진행하는 것. 그리고 계속 영어를 익히고 익혀서 30세 이전에 해외에 나가는 것. 그리고 30대 초중반에 컨설팅을 밑바닥부터 시작하는 것. 이것이 나의 간단한 로드맵일 것이다.

컨설팅 얘기를 들으면서 DBA컨설턴트라는 것이 있는 것도, 그리고 SAP(국제적인 최강의 ERP)컨설턴트가 엄청난 대우를 받음과 동시에 엄청나게 공부를 해야 한다는 사실도 알았다. 역시 SAP다. 오라클도 비슷하겠지..? 그리고 오늘 나는 오라클의 사이트를 돌아다니며 기술 문서를 찾으며 또 한번 영어의 엄청난 중요성을 알았다. 개발과 영어는 정말이지 떼어낼 수 없는 관계인 듯 하다. 하긴 프로그래밍이라는 용어 자체가 영어인데 말야..?

컨설팅을 꿈꾸는 나, 그리고 이제야 막 사장에게 인정받은 나. 아직 갈길은 정말 엄청나게 멀지만 내게는 큰 자신감과 열정이 함께하고 지금 내 눈앞에 손에 잡힐듯 훤히 보이는 이 로드맵이 나와 함께한다. 우선 최선을 다해서 먼저 어려운 한 걸음 할 수 있도록 최선을 다해야 하겠다.. !!