짧지만 길게도 느껴지는 IT에 진입하여 개발자로 일한지가.. 언 7년이 다되어 가는 듯 싶다.
나는 진입때부터 창업을 목표로 하였으며, 지금도 꾸준히 정진하고 있다. 해서 어느덧 결과에 다다르고 있음을
보니 기쁘고 뿌듯하기도 하다.
내가 감히 이런 말을 할 입장은 아니지만 그 동안에 생각을 정리해 보자면.. 느낀게 많다. 주로 쓴소리 위주로
생각을 정리하자니 내 손과 입이 쓰긴합니다.
일반적으로 분야는 기획 / 디자인 / 개발 / 마케팅(영업) / 운영 등으로 나누어져 있다.
먼저 기획. 아이디어가 창의적이지 못하고, 기본적인 문서작성능력이 너무 떨어진다.
문서작성능력은 배려라고 생각한다. 나 또는 다른 누군가가 기획함을 같이 협업하는 동료들이 잘 이해할 수
있도록 배려하는 마음이 제일 중요하다는 것이다. 본인만 알아볼 수 있는 기획서. 이런건 암호화라고 해야한다.
본인만 알고 이해한 다음 그 문서를 받은 타 공정(기획/개발/마케팅/운영) 담당자들이 이해를 하지 못해,
기획자를 찾아 문서들고 뛰어다녀야 하는 바보같은 일들이 빈번하게 발생하는 것을 볼 수 있다.
해서 기획자는 최대한 많은 문서 샘플과 양식을 연구하고, 기획하는 프로젝트와 회사에 맞게 양식을 구상하여,
타 공정 담당자들에게 제안하여 동의를 구하여 회사에 기획 양식을 만들어 내야한다.
물론 이 능력은 공부로 얻어진다. 이러한 부분에서 기획자의 역량이 판가름 난다.
디자인에서는 보다 창의적이고 많은 벤치마킹과 디자인 데이터베이스가 필요하다.
하여 인터페이스 구성에도 기획에 기여하며, 제안할 수 있어야 한다. 그리고 무엇보다 기획의도를 명확하게
이해하고 디자인 작업에 임해야 한다. 자신이 디자인함을 설명할 수 있어야 한다는 것이다.
허무맹랑하고 뜬금없다 할 지라도 설명이 되어야 한다. 그리고 타공정은 이러한 설명이나 의견을 듣고,
무시하지 말거나 딴청을 피워서는 안된다. 어느 공정이 위고 밑이고는 없기 때문이다. "협업" 이다.
이런걸 무시하는 개발자 치고 잘하는 개발자 본적 없고, 기획자는 발기획 하는 기획자 아닌 기획자 없드라.
내가 보기엔 ( ^^;; )
위와 같은 과정을 진행해야 인터페이스, 아이콘, 폰트, 이미지 등에도 세심을 기하여 품질을
디자인 역시 문서작성 능력이 중요하다.
물론 자신이 몸담고 있는 디자인 업무의 공정을 정확하게 파악하고, 동료들에게 제안하고
질의하여 디자인 명세서등 이 역시 타 공정과 원활한 의사소통이 될 수 있도록 포맷을 구축할 수 있어야 한다.
물론 이 부분은 문서작성능력이 뛰어난 기획자와 개발자가 도와주어야 하는 부분이다.
아무래도 디자이너들은 생각의 기반이 텍스트보다는 이미지에 가깝기 때문에 위 과정에서 불만과 불편이
다반사로 생기기 마련이기 때문이다. 그리고 디자이너들의 아이디어에 타 공정에서는 관심을 가지고
귀 기울여주어야 하며, 의견제시도 있으면 더욱 좋다.
개발 물론 모든 직군이 마찬가지 이곘지만 정말로 좋아해야 할 수 있는 거라 생각한다. 그리고 적성이 엄청나게 영향을
미치는 직군이라 생각한다.
개발방법론에 대해서는 따로 언급하지 않겠다. 내가 아직 많이 부족하거니와
많은 경험/패턴/사례/개발방법론들 역시 "목적" 에 맞게 방향을 설정하기에 이 걸 논하자면 숲을 보고 얘기하는게 아니라,
나무만 보며 얘기하게 될 우려이기 때문이다. 내가 프로젝트 PM 교육 받을 당시 강사님이 (이름이 기억안남;;) 했던 말씀 중
소프트웨어 프로젝트 라는 학문이나 산업이 철학에 의해서, 계획에 의해서 생겨난 산업이 아닌 경험에 의해서 생겨난
산업이기 때문에 공개되지도 않고 공개되어도 너무나 다양한 방법들이 존재한다고 했다.
이 말은... 결국은 답은 "사용자 정의" 인가? ㅋㅋㅋ
암튼...
먼저 목적이 뚜렷해야 한다. 먼저 "프로젝트" 를 목적이라고 본다면,
해당 프로젝트에 적재적소의 언어가 있을 것이다.
조엘 온 소프트웨어 에서도 보면 처음에 언어선택에 대하여 언급하고 있다. 개인적으로는 매우 공감이 간다능;;
먼저 방향적으로 경험기반하에 개발에 대해서 이야기하자면 먼저 "프로젝트" 목적부터 분명이 파악하고 기간(일정)과
인력 / 인력들의 기술수준 / 인력들의 기술 접근성 / 인프라 등 자원등을 확인한 후 적절한 언어를 선택해야 한다고
생각한다. 그리고 "프로젝트" 의 가능성과 성공여부를 판단하며 고도화와 안정화를 준비를 해야한다.
일단 만들어놓고 오픈이 땡이 아닌것이다.
그리고 일정산정. IT 엔지니어들을 압박하는 일정. 이 부분에 대해서는 정말로 기획과 개발. 영업의 서포트 등이
굉장히 필요하다.
기획과정중 기능명세와 서비스 시나리오 등에 대해서 정말로 중요하게 여겼으면 한다. 이 문서작업과 회의가
없이 일정을 산정한다는 것은 거짓말이다. 위와 같이 기능명세와 서비스 시나리오를 기반하에 예상일정과 소요일정이
존재하는 건데, 그 과정을 무시하고 귀찮아하다 보면 일정이 어겨지는 일들이 빈번하며 엔지니어들의 건강을 헤쳐가는
살인일정이 탄생하기 마련이기 때문이다. 나 역시 수시로 경험했다. 월요일에 출근해서 일요일에 퇴근.
1월달에 출근해서 3월달에 퇴근하는 미친 경우등등;;;
내가 기능명세와 시나리오 샘플문서를 작성해다가 관리자급 팀장에게 요청을 하니까 씹히기가 다반사였다. 해서 목적이
불분명하고, 비즈니스 로직이 불분명한 개발을 하다보니 당연히 심신이 지칠 수 밖에 없었다. 기획 담당자들은 이 부분을
고맙게 받아들이고 친절하게 작성해서 주는 사람도 있는 반면 이걸 왜 기획이 해야하나며 도리어 내게 화를 내는 사람도
있었다. 어휴우;;
다음은 내가 종사하고 있는 웹개발 직군에서 바라보는 관점에서 경험을 설명을 하자면..
답답하기 짝이 없는 현실을 많이 볼수 있다. 제일 먼저 관리자급을 언급을 한다. 안할 수 가 없다. IT 업계 자체를 개선하기
위해서 제일 핵심적인 역할과 권력을 지니고 있는 라인이기 때문이다. 이 때부터는 주로 개발이나 업무에 대해서보다
정치에 대해서 더 민감할 시기이다. 이 구조를 깨트릴 수 있는 회사가 대한민국에 몇이나 될까..?
제일 먼저 창의적이고 아이디어를 적극 수용하려하며 팀원 및 부서원들간에 폐쇄적인 소통을 주도하는 관리자들이 있다.
이들은 관리자급이 되면서 부터 자기 밥통지키려 소스난독화를 능력으로 착각하고 사내 정치에 충분히 활용하는
멍청한 관리자들을 수시로 볼 수 있다.
본인보다 직급이 낮은 하위 팀원들이나 부서원들의 본인 지식이상 성장을 매우 경계한다. "윗사람" 들과 "나이/연봉" 등을
의식하는 것이다. 이 부분은 인간적으로 보면 이해할 수도 있겠지만 그 부분에 대해 공존과 동반성장을 꾀하지 못하는 걸
보면 역시 그 조그만 조직내에서조차 권력에 길들여진 것도 있을 것이다.
나 역시 중간중간 이 일을 해가며 팀장에게 한 아이디어를 가지고 현상태와 적용시 장/단점과 같이 제시했을때도 제대로
들으려 하는 양반들을 못봤다. 바로 확인할 수 있는 거부반응이다. 일반적으로 적용되지 않아도 되고 활용되지 않아도
되지만 해당 설명을 듣고 접해본 후 거절을 해도 되는 것인데 말이다. 그리고 퇴사후에 들은 얘기지만 나중에 내가 제시한
아이디어를 본인이 제시한 아이디어로 회사에 제출한 경우도 보았다. ㅋㅋ 매우 열받았지만,
머 곰곰히 생각해보면 그 사람도 살아보려 발버둥 치는건데 뭐라하기 싫어 그냥 모른채로 지나갔다. 이런 경험들은 비단
나만 겪은 것이 아닐것이다. "꽤" 많은 사람들이 경험해봤을 것이다.
그리고 너무나 공부를 안하고, 코드등을 직접 개발하는 것을 비효율이라 생각하는 사람들이 꽤 많다.
물론 요새는 훌륭한 오픈소스들과 훌륭하게 구성되어 있는 프레임워크등이 즐비하다 보니 개발을 할 생각을 안한다.
단발성으로 간단한 UI 기능 구현마저도 덩치큰 프레임워크를 사용하려 들때 비효율 논하면 화가 나기 일쑤다.
그 프레임워크나 오픈소스등, 구글링에 나도는 코드들을 본인이 스스로 사용하고 경험하여 테스트하지 않고 검증되지 않은 코드를 프로젝트에 남발하며, 부비트랩처럼 심어놓은 경우도 매우 자주 볼수 있다.
일전에 간단하게 목록형태의 UI 를 만들일이 있었는데 jQuery GRID(그리드) 플러그인 중 jqGrid 를 사용하려 하길래
왜 그걸 사용하냐고 물어보니 기능이 많고 jqGrid 영업사원 마냥 기능을 늘어놓는다.
해서 다시 그 기능이 지금 만드는 목록에 필요한 거냐고 물었더니, 언젠간 사용하지 않겠냐란 대답이 왔다.
하아.... 뭔가 오픈소스를 도입을 하고 프레임워크를 도입했을 때 생긴 목적이라든가 사용예제, 경험등에 대해 좀 꼼꼼히
알아보고 진행중인 프로젝트 성격에 맞는지 검증조차도 거치지 않는 다는 얘기였다.
또한 기능명세나 시나리오에 대해서 고민조차 해보지 않는다. 기획서나 오거나 간단하게 기능요청이 오더라도 작동되는
시나리오에 대해서도 질문도 하지 않을 뿐더러 요구하지 않는다. 그리고 그런 사항 물어보는 자체를 실례로 여기는 멍청한
배려를 일삼는 양반들도 있다. 그럼 그 프로그램이 작동하는 거에 대해서 본인 스스로가 아니면 기획자들도 신뢰하고
설명이 가능하겠는가? 그러니 기획서를 밥먹듯이 수정하고 코드도 밥먹듯이 수정하며 서로들 싸우는 일들도 다반사다.
개발자와 기획자는 서로 앙금이 많은것을 IT회사에서 수시로 볼 수 있다.
이러한 구조를 깨나가고 보다 창의적이고 기발한 아이디어를 실용화 되기 위해서는 관리자급의 생각이 많이
바뀌어야 한다. 또한 IT 직군의 종사하려 하는 사람들에게 한마디 조언아닌 조언을 하자면... 취업하여 직장인이 되려
하는게 목표인지 창업이 목표인지 소프트웨어 학자가 목표인지 명확하게 하는 것이 좋을것입니다.
IT 에 진입하는 방법이나 관점이 많이 달라질 수 있기 때문입니다.
저 역시 첫번째 창업 실패를 계기로 부족함을 느끼고 웹개발을 공부하게 되었습니다. 어디까지나
실용주의적으로 공부하게 되더군요. 그렇다고 제가 성공한 것도 아니지만.. 설명하기 힘들지만.. "중요" 하다는
생각이 들어 주저리주저리 푸념을 늘어보았습니다.
이 푸념도 현재 IT에 종사하시는 분들에게나 진입을 준비하시는 분들에게 도움이
될수 도 있겠죠? ^^;
/********************************************************************************
* 끝으로
* 어디까지나 개인적인 견해입니다. 특정한 직군이나 사람들을 비판한 건 아니니,
* 좋은 의견이나 경험들을 공유하자는 차원입니다. ^^;;
********************************************************************************/
댓글