brunch

브런치북 20년간 비정규직 개발자로 일하다 09화

라이킷 11 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 삶을 바라보는 관점 Sep 29. 2024

20년을 프리랜서로 일하면서 경험한 프로젝트 1

프리랜서로 성장할 수 있었던 S사의 개발센터 경험

저는 S사의 개발센터에서 일한 이야기를 빼먹을 수 없습니다.

제가 일하면서 개발센터에서 일한 경험과 기회는 20년간 비정규직으로 일할 수 있는 초석이었기 때문입니다.

Mizuno K님의 사진

KMS(Knowledge Management System:지식관리시스템)는 조직 내 인적자원이 가지고 있던 개인들의 Know-how를 조직 차원에서 관리하고자 구축하는 시스템이라고 할 수 있습니다.

초기에 구성된 개발센터 KM 팀원 중 프로젝트를 진행했던 개발자는 당시는 저뿐이었습니다. 제가 퇴사한 회사 직원들이 있었지만 들어와서 교육을 받으면서 개발을 하셨습니다.

물론 PM(Project Manager)과 PL(Project Leader) 분들이 함께 있으셨습니다. 하지만 개발을 진행해야 하는 사람으로는 제가 그나마 경험이 있었던 것입니다.

기존에 있던 시스템을 확장하고 더 나은 솔루션을 만드는 것이 목표이었습니다. 이에 기능을 어떻게 개선할 것인지 타사제품을 분석하였습니다.

추가로 개발해야 할 기능들도 모아서 설계하며 개발일정 등을 수립하였습니다.

너무 오래전의 이야기여서 지금 이 글을 읽으시는 IT(Information Technology)에서 일하는 분들은 ‘지식관리 시스템에 대해서 뭐지’라고 보실 수도 있을 거 같습니다.

당시는 지식을 저장하는 창고, 즉 게시판의 기능을 다양한 방식을 만들어 내는 것이 지식관리 시스템의 기본 기능이었고, 만들어 낸 저장 공간에 품질 좋은 지식을 축적하도록 유도하고 평가, 보상하는 게 지식관리 시스템의 중요 기능이었습니다.

지식관리 시스템을 도입하는 회사에선 무형의 자산인 직원들이 가지고 있는 Know-how를 어떻게 잘 정리하여 활용할 수 있게 만들어 주게 해 주느냐가 중요한 Point였습니다.

그러다 보니 기능은 게시물을 저장할 수 있도록 저장 공간을 만드는 엔진, 저장된 내용을 검색하는 엔진(지금의 포탈에서 사용하는 검색엔진 부분의 초석으로 보시면 됩니다), 등록된 내용을 보기 편하게 조회할 수 있는 기능, 지식에 대한 평가, 보상 등을 주 기능으로 개발하였습니다.

제품 개발을 위한 타사제품 검토 및 기능 파악, 제품을 위한 기능 설계, 개발 등을 진행하면서 저는 여러모로 성장하고 있었습니다.

일정 관리 시 저는 PM께서 알려주시기 전까지는 개발만 끝내면 끝났다고 개발하는데 걸리는 시간만을 일정으로 고려했습니다.

하지만 PM께서는 내가 소스를 개발하는 일자에 항상 추가 일정을 잡도록 알려주셨습니다.

왜냐면 개발을 진행하다가 보면 생각하지 못한 문제점이 발생할 수 있기 때문입니다.

생각하지 못했던 내용으로 개발 기간은 지연될 수 있습니다. 그걸 고려하지 못하면 저는 항상 개발일정을 못 맞추는 사람이 되기 때문에 이 부분은 개발일정 산출에 중요한 부분이었습니다.

일정한 실력이 되었을 때 어떤 업무 개발을 맡으면 며칠 정도 걸리겠다는 개인적인 의견이 나옵니다. 그 의견에 1~2일 정도의 여유를 잡아 혹시 모를 문제를 대비하는 것입니다.

이는 특히, 프로젝트를 진행할 때는 절대적으로 필요한 일정 산출이었습니다.

물론 프로젝트에선 이렇게 일정 산출을 하여도 막판에 잦은 야근과 문제가 발생하긴 합니다.

프로젝트에선 요구사항이 변경되어 전체적으로 다시 개발할 경우가 많이 발생하기 때문입니다.

그래도 기본적 개발일정을 수립할 때 이 여유일정을 고려해야 합니다.

지금의 구분으로 보면 전 외주 개발자였고, 계약직이었지만 신규로 투입되는 개발자들에게 교육 및 개발해야 할 내용 분담 및 검토하는 일도 하였습니다.

생각해 보면 당시 전 20대의 중반으로 사람들과 소통하는 기술, 사람들을 잘 이끌거나 다독거려 줄 그릇이 되지 못했습니다.

제가 아는 범위와 상대가 아는 범위가 다름으로 이해의 수준도 다른데, 그 당시는 이 차이도 제대로 몰라 상대를 사오정(말귀를 잘 못 알아듣는 사람) 취급하였습니다.

저의 의도와 달리 개발한 부분에 대한 질책 등도 하였습니다.

팀 프로젝트를 이끌어 가기에 당시엔 부족함이 많았던 저였습니다.

개발자 중엔 특히, 남자 개발자는 군대를 다녀와야 해서 저보다 나이가 많은 경우가 대부분이었습니다. 그런 분들께 제가 일을 설명하고, 업무 할당하고, 검토해야 하는 위치였습니다.

다행히 IT 일은 개발하는 기술직으로 누가 더 그 일을 잘 해내느냐로 평가를 받았을 수 있었습니다. 나이보다 실력이 우선 있었습니다. 저는 제가 교육하고 일을 시키는 분들보다 결과물을 빨리 내놓을 수 있었기에 그분들에게 일을 시켜 나갈 수 있었습니다.

솔루션을 알고 있는 지식과 결과물을 내놓을 수 있는 시간의 차이로 제가 일을 이끌어 갈 수 있었습니다.

프로그램을 개발하면서 초기 아니 어쩌면 지금으로 보면 베타 버전으로 보면 됩니다.

2000년 초 베타 버전 없이 그냥 납품이 진행되었습니다.

개발센터에 투입된 자금이 있어서 개발하는 부서 및 회사에선 뭐라도 성과가 나와야 하지 않았을까 합니다.

암튼, 개발된 프로그램은 첫 회사에 적용하게 되었습니다. 시스템을 처음으로 구축하는 곳이기에 PM께서는 제게 직접 가서 설치하고 문제점 등을 해결하고 오라고 하셨습니다.

초기 개발센터 조직은 개발팀만 주로 있었기 때문에 개발팀 내에서 설치 및 테스트, 보완 작업을 진행하였습니다.

개인적으로 버그도 많고 뭔가 모자란 제품을 납품하는 것에 불만이 있었습니다. 그때 PM께서는 제가 이런 불만과 의견을 전달했을 때 이야기해 주셨습니다.

‘상품은 항상 최상의 상품을 제공할 수 없어. 고객이 만족할 수 있는 제품이면 팔 수도 있는 거야. 즉, 고객이 흔쾌히 그 가격을 내고 그 제품을 사겠다고 하면 팔 수 있는 거야. 왜냐면 그만한 제품이 현재는 없기 때문이야. 이 솔루션도 국내에 이만한 솔루션이 없어. 그래서 우리 솔루션을 고객이 사는 거야.’

생각해 보니 고객마다 만족하는 제품의 수준은 있었던 것입니다. 물론 여유로운 사람의 경우는 최고의 가격을 주고 최상의 제품을 구매할 수 있습니다. 하지만, 그렇지 않고 그런 물건을 찾지 못하면 자신이 만족한 수준의 제품을 가격과 함께 고려하여 구매한다는 관점입니다.

제게 이 관점을 PM께서는 알려주셨습니다.

세상에 나와 있는 제품은 모두 완벽한 제품이 아닙니다. 완벽하지도 최고 혹은 최상이 아닐 수도 있지만, 자신의 주머니 사정을 고려하여 구매자가 만족할 수준이 있는 것입니다. 판매자 역시 고객층을 대상으로 제품을 생산하여 판매하는 것이라는 관점입니다. 전 이 관점이 부족했고 무조건 제대로 된 좋은 제품으로 만들어서 팔아야 한다는 생각을 하고 있었습니다. 이 관점을 바꿔주셨습니다.

솔루션에 다국어 지원을 위해 한국어를 할 수 있는 외국인도 불러서 화면에 보이는 메시지, 알림 등 보완 작업도 진행하였습니다. 이때 적용하면서 국내에서 번역하는 일이 얼마나 엉망인지도 알게 되었습니다.

영어를 아는 이들이 저희가 번역을 의뢰해 받은 내용을 봤을 땐 전혀 이해할 수 없다는 사실이었습니다.

사용자에게 보이는 메시지는 계속 고쳐져야 했으며 처음 개발할 때 화면 크기와 달라져 문제가 발생하기도 하였습니다.

솔루션은 초기엔 MS사를 바탕으로 하다가 결국에 Unix로 변경하였습니다.

지금은 그래도 MS Sever를 사용하는 대용량 시스템들이 있으나 당시는 MS사의 Server는 소규모 업체만 사용한다는 인식이 있었습니다. 사실 제 기억에도 문제가 많이 발생하기도 했습니다.

처음 제품 발표회를 코엑스에서 할 때 기억이 납니다.

저희는 솔루션 발표를 위해 전날 시현 할 서버 설정 및 프로그램 설치를 모두 끝내 놓았습니다.

근데 서버를 장소로 옮겨 놓고 최종 확인작업을 하고 있는데 갑자기 SQL DB Server가 작동하지 않았습니다. 준비하던 인원은 모두 비상사태가 되었습니다. DB Server를 처음부터 다시 설치하고 필요한 Data를 만들고 프로그램에 연결하였습니다. 무슨 문제였는지 기억나지 않지만 잘 안되어서 엄청 피를 말리던 시간이었습니다. 그 긴박함이 지금도 기억납니다. 어찌어찌 겨우 설치를 마무리하고 제품 발표회를 무사히 마쳤던 기억이 납니다.

추후, 솔루션 판매 확장을 위해 Unix의 Java로 변경 작업을 시작하였고 개발자들은 모두 Java 언어를 배우고 Unix를 기반으로 바꿨습니다. 이때부터 저 역시 Java 개발자로 일을 하게 되었습니다.

개발센터는 서울 남부터미널 근처에 있다가 분당으로 이전을 해서 더 크게 확장되었습니다.

개발센터 조직은 개발팀, 지원팀, 마케팅팀, 품질 관리팀 등 확장되어 솔루션은 전문적 제공 제품으로 포장되어 갔습니다. 제품이 점차 마케팅팀에 의해 포장되는 가는 모습을 보면서 사실 전 좀 놀랬습니다. ‘이렇게 제품이 바뀌어 가는구나’라는 사실을 알게 된 것입니다.

시간이 지나 솔루션은 점차 안정화되어갔고 신규 기능을 개발하는 부분이 줄어들었습니다. 개발센터 일이 점차 운영, 관리하는 부분에 치중하게 되었습니다. 제가 하는 일도 새로운 기술, 업무 적용보다 보완하는 일에 치중되어 갔습니다.

저는 PM께 프로젝트로 가게 해 달라고 요청했습니다. 일에 지루함이 느껴졌기에 새로운 곳에서 새롭게 일을 해보고 싶었습니다.

PM께서는 개발센터에서 좀 더 일하라고 하시며 신규로 진행되는 다른 모듈 일을 주셨습니다.

하지만 결국엔 저는 센터에서의 일에 대한 타성에 젖어드는 상태를 견디지 못하고 개발센터를 그만두고 다른 일을 하겠다고 하였습니다.

정확히 기간은 기억나지 않지만, 개발센터에서 한 3년간 일했던 거 같습니다.

전 개발센터에서 일하면서 성장하였고 그런 기회를 주신 PM께는 지금도 감사드리는 마음입니다.

모든 일은 결국 사람에게서 시작해서 사람으로 끝난다는 걸 프로젝트를 20년간 하면서 알게 되었습니다.

개발일이 실력을 기준으로 한다고 하더라도 제가 일을 할 수 있게 연결해 주는 누군가도 사람이고, 함께 일을 해 나가는 것도 사람입니다.

사람에 대한 이해가 기본적으로 필요하다는 소중한 결론을 얻었습니다.