Go Live?

인도에서 사용한 숙소인 아파트, 베란다에서 내려다본 풍경

 

2005년 8월 1일.

새로 시스템이 오픈되는 인도의 노이다에서 시스템 오픈 준비로 밤을 꼴딱 새고, 아침이 되었을 때

출근을 한  담당 시스템의 테크니컬 리더였던 Amit이라는 친구가 나를 보며 한 말이 Go Live?였다.

 

나는 'Go Live'가 신규 시스템의 Open을 의미하는 말이라는 걸 그 때 처음 알았다.

그리고 Go Live?를 물어보던 Amit의 밝은 표정에서 그가 정말 '오픈하는지?'를 물어본게 아니라,

'시스템이 오픈하였으니 이젠 그간의 고생들은 끝났다.'라는 긍정적인 표현이었다는 것도,

그리고 내 생애 처음 참여했던 프로젝트를 통해 전산쟁이에게 시스템의 'Open'이라는 것이 가지는 그 절대적이고, 신성하기까지 한 의미를 깨닫게 되었다.

 

전산쟁이라면 매년 1월 1일을 집에서 쉴 수 있는 기회를 가지기가 쉽지 않다.

새해를 새롭게 시작하는 기분으로 전산용역을 발주하는 많은 회사들이 신규 시스템의 OPEN을 매년 새해로 잡는 경우가 많기도 하거니와 설령 SM(시스템 유지보수, System Maintenance)을 하더라도 많은 경우 연마감/월마감을 지원해야 하기 때문이다.

 

물론 모든 전산쟁이들이 그렇지는 않을 것이겠지만, 아직까지 나는 1월 1일의 휴일이 쉽게 찾아온건 아니었던 것 같다.

 

어쨌든 시스템 엔지니어로서 프로젝트 시장에 몸을 담그고, 4번째 Open을 맞이하게 되었다.

이번 프로젝트 역시 언제나 모든 프로젝트가 그랬듯, 피곤한 몸과 마음이 남게 되었지만,

1월 1일인 오늘을 집에서 쉬면서 오픈을 맞이할 수 있게 되었다는 측면에서는 상당히 성공적인 프로젝트인 것도 같다.

그리고 이번 프로젝트 역시 뭔가 내가 반성해야 할 꺼리, 생각할 꺼리를 남겨주었다.

 

첫째. 자신감이 부른 패착.

이번 프로젝트는 동일한 업무의 4번째 프로젝트였고, 그 대상 업무 역시 옛날 내가 유지보수를 하던 당시의 업무에 대한 프로젝트였다.

즉, 업무를 들으면 현재 프로그램이 어떻게 흘러가는지 머릿속에 현재의 로직이 분석될 정도였고, 그래서 남다른 자신감이 있기도 했다.

그래서 시스템 개발 초기에 내 목표는 단순히 '요구된 기능의 구현'이 아닌, '사용자에게 최적화된 개선된 기능의 구현'이었다.

문제는 이러한 목표가 일정과, 개발자의 역량과는 완전히 동떨어진 나만의 목표였다는 것이었다.

나에게는 '너무나도 뻔'한 프로젝트였지만, 개발자들에게는 신규 업무였고, 더더군다나 일정은 업무에 대한 익숙함이 이미 고려되어 빠듯하게 잡힌 터였다. 

결국 목표한 기능들은 모두 구현이 되었지만, 그 와중에 지속적인 야근과 휴일근무를 해야 했고, 아마 지금 눈에 보이지는 않지만, 생각할 여유가 있었다면 가능했을 혁신적인 요소들을 놓치고 말았다.

 

둘째. 프로그래밍이 아닌 미팅의 중요성.

나는 나 자신을 생각할 때, 절대 프로그래밍에서 손을 떼면 안된다는 생각을 한다.

이러한 생각은 전산쟁이로서 지켜야 할 최소한의 자질이기도 하지만, 문제는 이번 프로젝트에서 손을 뗄 수 없다는 인식의 수준이 아닌, 완전한 프로그래머가 되어 버렸다는 사실이다.

아마도 업무를 이미 알고 있다는 자만심 때문이었는지 모르겠지만, 내 머릿속에 있는 그림을 그려내기 위해 프로그래밍에 몰두하다보니, 정작 중요한 업무 협의를 소홀히 하게 되었다.

물론 고객들은 알아서 해주는 우리의 모습에 상당히 만족스러워 하긴 했지만, 결국 이런 사람들이 나중에 폭탄을 터뜨렸다는...

 

셋째. 여전히 어려운 문제, 개발자가 할일과 내가 해야 할 일.

이 바닥은 어느 하나의 Language, 하나의 기술로 이 프로젝트, 저 프로젝트 이합집산하는 '개발자'들에 의해 굴러가고 있다.

당연 프로젝트마다 새로운 개발자들을 만나게 되고, 이들과 함께 단시일에 호흡하며, 프로그램을 개발해야 한다.

문제는 이 사람들과의 기술적인 측면에서 혹은 인간적인 측면에서, 업무적인 측면에서 어떻게 선을 그어야 할까라는 고민이다.

나는 고객에게 업무를 청취하고 이를 시스템으로 구현되도록 설계하는 역할을, 그리고 개발자는 그 설계에 맞추어 프로그램을 만들어내는 역할을 맡고 있다. 

문제는, 말로는 무척 단순하고 합리적으로 보이는 이 관계에서 물리는 부분이 그렇게 단순하지 않다는 것에 있다.

내가 프로그램을 설계할 때, 그냥 업무만 기술하면 되는 걸까?, 아니면, ERD를 그려주고, 관련 컬러만 기술해주면 되는 걸까?

사용자의 프로그램 사용예시를 시나리오로 기술하면 되는 걸까?, 아니 차라리 SQL을 짜 줄까?  그럴바에 프로시저도? 패키지도?

개발자는 이 업무를 이해하고 있을까? - 사실 이점에서 요즘 만나는 개발자들에게 갖는 불만이 있다.

기본적으로 제대로 된 프로그램이 나오려면 개발자가 업무를 어느정도 이해하고 있어야 한다.

그런데 업무를 적극적으로 알려하고, 프로그램 개발시 이를 적극적으로 반영하려는 개발자를 만난게 어느 새 추억이 되어 가고 있다.

요즘 개발자들은 던져준 스펙대로 코딩을 하는 단순한 기계들이 대부분이다.

SI시장은 고객을 만나고 설계하고 개발까지 하는 말 그대로 불쌍한 3D업종의 전산쟁이가 있는가하면,

던져준 스펙 그대로 코딩만 하다가 칼퇴근의 행복한 개발자들이 있는 것 같다.

개발자들이 가지고 있는 기술적인 독창성, 우수성이 있다면 이를 프로젝트에서 활용할 방법은 무엇일까?

나는 간혹 스펙에 대한 개발자들의 이견제시를 들을 때, 이 사람들이 문제점을 제기한다기보다는 뭔가 핑계를 대는듯한 느낌을 받을 때가 많다.  

당연히 개발자 입장에서는 사용자 편의적인 시스템은 그만큼 안정성이 훼손될 수밖에 없다.

그런데 여기서 훼손되는 안정성의 내용에 중요성을 두는 개발자들이 있는가 하면,  훼손되는 안정성을 벌충할 방법에 중요성을 두는 개발자들이 있다. 

물론 전자가 대부분이고 항상 나를 괴롭게 만드는 문제이기도 하다.

 

이 문제는 여전히 진행형인 문제이다.

언제부턴가 모듈리더, 업무 분석가들은 밤늦게까지 남아서 문서를 뜯어고치고, 개발자들은 하루종일 스펙을 기다리며 웹서핑을 하다가 퇴근하는 모습들을 자주 보게 되는것 같다.      

더더군다나 개발 기간은 점점 단기간으로 줄어들고 비용도 줄어들다보니 개발자들이 OPEN을 함께하는 과거의 모습도  점점 사라져간다.

이건 프로젝트에 있어 정말 큰 문제가 아닐 수 없다.

 

나도 언젠간 프로그래밍에서 손을 놔야 할지 모르겠다.

벌써부터 간혹 그런 싸인이 들어오기도 한다.       

한편으로 프로그래밍에만 매몰되어 놓쳐버린 고객과의 관계가 정말 중요했다는 사실이 프로젝트 종료시한에 보이기도 한다.

 

과연 어떤 선택을 내가 해야 할까.

이번 프로젝트의 오픈 후 얼마만큼의 여유가 내게 주어질지 모르겠다.

어쨌든 여유가 주어지면 좀 쉬면서 생각해 봐야할 문제일 것 같다.