소프트웨어 경력증명 신청과 후기

소프트웨어 경력증명을 마쳤다. 어딘가 창고에 박아둔 내 경험들과 교육 그리고 활동들 다 기입하기 어려워 항상 아는사람만 내가 뭘 해왔는지 안다. 주장도 강하고 그만큼 공부도 많이했다고 생각했다. 그러나 국가사업등 기술평가 등등을 위해서는 국가가 요구하는 서류를 제출해야한다. 바로 소프트웨어 경력증명 서류 제출이 요구에 들어가 있다. 거의 다 프로젝트 사업이다. 

 

프로덕트 개발자 생태계와 프로젝트 분야의 개발자 생태계는 많이 다른 느낌으로 돌아가는 것 같다. 

 

뭐 아직 내가 기술사도 아니지만 국책과제나 NIPA 과제 등등 진행 및 보고 및 비지니스로직을 건드리려면 국책기관등에 필수로 제출해야하는 암묵적인 문서가있다. 개인이 쓴 이력서가 아닌 "소프트웨어 경력증명서" 를 가지고 판단하고, 국방부도 이걸 가지고오라고하더라..  

소프트웨어 경력증명

 

 

그래서 소프트웨어 경력증명신청을 하게 되었다 .

 

해온걸 다정리하는데만 한 3일이 걸렸고, 국가 프로젝트 진행한것들은 내가 직접 프로그래밍이나 IT 를 했다느 서류가 없으면 받아주지않는다고 해서 여차저차 아래있는것들만 승인이 났다. 

 

 

프로덕트 업계에서는 거의 모른는 사람들이 많다. 그냥 회사에서 직무별로뽑아서 이력서나 깃허브로 주로 대체했고 

나또한 이업계에서는 깃허브 및 포토폴리오 및 개발 포폴과 내가 프로젝트 매니징할때 사용한 msproject나 지라 사용하는걸 눈으로 보여주거나하여 회사랑 일했던 것 같다. 

 

프로젝트성으로 진행하고 관리가 주요한 프로젝트는 주로 탑다운이며 이때는 주로소프트웨어경력증명서를 요청받았다. 

근데 대체적으로 근무하고 느낀건 진성개발자와 사업부의 전쟁이 일어나느 곳이며 각자의 역할이 명확하여 프로그래밍도 최대한 보수적으로 하고 탑다운 구조에서 내부에서 애자일조직을 구축해봤자 스터디 이상으로 업무에 쓰일수는 없었다. 

 

 

나는 근무하면서 애자일 프로세스가 맞긴 하지만 진성개발자랑 일하고 싶었고, 그래서 둘다 일하고 동시에 2곳이상에서 일하려고 거의 몸이 가루가 되게 움직였고, 어떤 곳에서는 고용계약서를 이미 다른 쪽과 작성했는데 알고보니 이후 사업에 있어서 경쟁사 가 될 가능성때문에 결국 한쪽에서만 일하기도하고 했다. 여러 경험들을 통해서 자기가 일한 경력을 채워나가는것이 난 좋았고, AI 시대와 함께 많은 부분에서 도움을 많이 받았다. 

 

프로젝트성 개발 사업단에서는.. 

프로젝트성 사업에서는 납기 뿐만 아니라 개발 유지보수도 정말 중요하며 이를 위해서 개발자의 이력과 활동등에 있어 정량적 평가를 하기위해서 많은 노력을 한다. 

정부 24도 이 경력증명이라는제도와 함께 크게 성장한 국가단위 프로그램들이다. 나야 아쉽게(?) 능력부족과 경력부족 등학력 부족 등등..으로 [농담입니다.] 이런 큰 프로젝트를 대규모 사업을 해볼 수 있는 기회는 없었고, 언젠간 오겟죠? 이런 프로젝트에서 가장 어려운 점은 개발보다 통제와 유지보수와 시스템 규모에따른 위험관리와 사후관리영역이다. 따라서 대체적으로 검토와 입찰 등등에 함께 보면서 사업을 내가 이어나가지 않더라도 다른사람이 맡을 수있도록 특별함이 아니라 정확하게 누가 날 이어서라도 이걸 정확하게 매뉴얼대로 시행해야하는 과정을 지켜야한다. 

답답하기도 하지만 국책프로젝트를 진행하면서 데이터 베이스와 비지니스사업단의 복잡함을 DA와 데이터구조분석 등을 통해서도메인별로 전문가의 존재를 크게느끼기도 했고 정말 세상 넓은경험을 할 수 있었다. 나는 백앤드와 인프라를 계속한다면 프로젝트성 사업단에서 일하고 싶다. 

 

주로 이런 분야에서는 정말 인력이 필요해서 소프트웨어 증명서를 받기도 하지만 기술사 및 감리 분야 그리고 개인정보전문가, 시스템인프라 계약서 전담 변호사 분들 등등의 많은 조합을통해 점점 백지에서 데이터모델링과 데이터 아키텍처링 등을 경험할 수있고, SAP 프로젝트만큼 이런 ERP 시스템등등을 경험해보고 나의 부족함을 매일 느낀 적이 없었다. 

물론 과거 레거시 시스템을 만질 사람을구하기 위해서 단가표로 개발자를 데려다가쓰지만,, 대부분 일수 단가로 끊어서 들어오는 경우가 많고 그렇게 원가관리도 진행되기에 중요 시스템 엔지니어링을 하는게 아니라면 겉에서 욕만하다가 끝날 수있는 구조이기도 하다. 

 

이분야에서는 개발보다는 개발의 핵심가치와 개발과 연계되는 수많은 비지니스의 요구사항에 대한 정확한 분석등을 진행하고 발전해가는게 좋아보인다. 감리사 기술사 분들도 많은 시장이고, 국가의 현재 IT 의 과거 현재 미래를 함께 하시는 분들이다. 

 

프로덕트성 개발 사업단에서는.. 

프로덕트성 사업들은 대부분 그 프로덕트가 주사업이다. 프로덕트를 잘살리기 위해서 돈을 투자하는 과정을 거치지만, 개발자에 측정도 어려울뿐만 아니라 고객들의 니즈에 따라 시장이 변화하다보니 이는 이분야에서는 투입관리와 일정 등등에 대한 다양한 통합관리 프로세스보다, 돈이 들어도 좋으니 일단 성과를 뭐로 측정할지 그리고 무엇으로 그걸 시장에 증명 혹은 투자자에게 증명하는지가 주 과제인것으로 보인다. 

 

그래서 정말 다양한 사람들로 구성되며 일도 자기가 만들어서 하기도하고 누군가의 입김에 따라 그 가치가 평가절하당하기도 쉽다. 정치질이 시작되면 일은 저멀리 넘어가고 6개월간 누가 못했는가 누가 책임인가 를 논하는 뮤지컬과 회사시간에도 원오원 한다고 카페에 가서 3시간을 수다떨다 들어오는 그런 구조가 조직적으로 잘잡히지 않는 구조이기도 하다. 

 

조직원에 대한 신뢰와 팀 자체에 대한 신뢰 그리고 서로의 시너지를 위해서달려나갈떄는 누구보다 프로덕트를 넘어서 같이 일하는사람들과 함께일하고 싶다는 생각이 들 수 있는 구조이나. 위에처럼 정치질과 친목질 그리고 개발자 스스로가 자기가 회사의 중심이라고생각하는 그런 경우까지 생기고 대외비가 회사 밖 기술컨퍼런스에가서 발표되어 논란이 되기도하고, 비지니스와 시장가치가 프로젝트성 사업들과는 달리 릴리즈가 증분형으로밖에 나올 수 없는 시장이다. 

 

근래 IT기업들의 부상과 함께 정말 많은 팀들이 팁스 투자등등을 통해서 릴리즈단위와 마케팅 지표등을 통해서 사업지표와 맞춰서 시리즈 투자를 받기위해서많은 노력을 기울이고 개발자에게 돈을 아끼지 않는다 어찌보면 개발자가 결국 상품을 만드는 기계이므로, 그러나 사업이 사라지면 그렇게 큰소리를 내던개발자들은 아주 조용해지고 재무파트와 다른 파트들의 중요성이 커지면 개발자들은 이직을 선택하거나 개인의 성과를 밝히고 노래해야하는 상황이 올 수도 있다. 그리고 가장 중요한 점은 경력을 인정한것이지 회사에서 그정도의 성과를 내면 스톡이나 파트너 등의 권한을 가지는것이 일반적이지만 대부분의 개발자들은 그 지위까지 가지 않는다. 

 

이분야의 개발자들은 신기술이나 새로나온 오픈소스에 민감하게 반응해가는 것이 기본 스킬인것같다. 

어느 알고리즘이 왜 이런 부분에 쓰여야하는지 보다 새로우면 일단 MVC 패턴등을 그냥 유명하면 사용하고 공식문서를 따라하고 만들어서올린다. 안되는것은 구글링과 함께 챗지피티와 함께 해결만 하면 되는 친구들도 있고, 그 안에서 자기가 갈 가치를 찾는 개발자들도 많다. 

 

중요한 핵심가치에 개발자들이 말을 더하고 열정있게 업무를 진행할때는 좋다. 그러나 항상 프로덕트 업계에서는 회사의 재무 와 비전보다 그 구성원들의 자아강도를 보고 회사를 선택했다. 

 

프로덕트 개발자들은 자기 스스로가 프로덕트를 이해하고 고객과  함께하는 사람들이 많다. 프로젝트 개발자들처럼 일의 일부로 여기는것보다 이 프로덕트를 만든 창조자로 스스로를인식하는 것 같아 보인다. 

 

그 개발자들과 더불어 PM의 역량을 가지고 있던 사람들중 일부는 PO 라는 직업군을 가지고 프로덕트 오너라는 단어를 통해서 스스로 프로덕트의 방향성을 결정하고 개발자들은 개발 자체에 있어 개발이 아니라 이 기획 자체에도 참여하여 말을 내면서 각자 주장을 무척 깊게 피력할 수 있는 구조다. 

 

 프로덕트의 구성원이 정말 프로덕트를 위해 모였는지, 아니면 프로덕트를 만드는 자신의 모습에 취해 있는지 확인해야하는 어려움이 있지만. 최고의 팀원과 일해서 팀원때문에 이직을 못 가기도 하는 소프트파워가 발휘될 수도, 정치질만 하다가끝나서 이직할때가 되어서 자기 이력서에 한줄 쓰기 힘든 구조의 가족 같은 프로덕트 팀일 수도 있다. 

 

결론

소프트웨어 경력증명 제도는 오래된 제도이고, 국가 단위와 행정학적 영향력등을 고려하여 프로젝트를 진행함에 있어서는 중요하게 작용하는 제도이다. 

과거에는 많이 쓰고 전국민을 대상으로 전기세를 측정하고 수집한다고 하였을때 SELECT * 하는 순간 사망할 수 있음을 알고 쿼리 하나조차 돌리기 무서운 것을 경험할 일이 많지는 않을 것이나 이런분야에서 일한다면 이 증명서는 마주치게 된다. 

새로운 사업부를 만들때 제출하라 하는경우들이 있기 때문이다. 

즉 국가 혹은 지역 단위의 일을 진행하여 도메인에 있다면 이 증명서류는 많이 쓰이고 많이 제출한다. 

 

 

그러나 소프트웨어경력증명은 새로운 프로덕트나 새로운 사업을 시작하는 곳에 제출해도 크게영향력은 없다. 새로운 프로덕트를 개발할 사람을 찾는 것이지 , 나의 경력자체를 증명해야하는 선이 없기 때문이다. 정말 아무도 모른다고 해도 문제가 없다.. 그냥 깃허브 제출하는게 최고다.. 리트코드 제출과 함께.. 어차피 일하는 방식도 다르고 정말 다 다르다. 시킨다고 하는 사람들이 거의 없는 곳이다. ... 

 

 

주변에 아는지 물어보면 반반 있는 것 같다 . 이걸 아는사람과 저게뭐야 하는 친구들,, 

 

나는 경제학 전공부터 대학원 과정 그리고 개발 회사 를 동시에 나가서 일하고 하던 사람이었던지라 이력서 를 통합으로 쓰면 6장이 넘는다. IT 에 관련된 내용만 저렇게 딱 빼놓고 관리하면 경력증명에 등록되는건 IT 나 이런 쪽에 주로 넣고 나머지는 따로 이력서를 쓴다. 

 - 뭐 이력을 매때 내는것보다이거 하나뽑아서 제출하는 값으로는 아주 편하다. 

 

 

끝!