개발자 경력으로 남는 것(소프트웨어, 소스, 문서)
개발자의 생각#81
by
Sep 15. 2023
개발자의 경력을 평가할 수 있는 것은
소스
소프트웨어
문서
뿐이다. 다녔던 회사나 프로젝트도 중요한 외적요소이지만 개발자의 품질(인간성 및 조직 내 네트워킹 스킬은 제외)을 알 수 있는 방법은 위의 3개 외에는 없다고 보아도 무방하다.
이 세상의 변화에서 IT만큼 빠른 것을 찾기 쉽지않다. 단 몇 년 사이에 개발기술의 판도가 달라지는 것은 일상이다. 그런 이유로 개발자는 주기적으로 자신의 업무분야를 학습하고 기록해야 한다. 생존하려면 그 방법 외에는 없다. 몸에 체화되면 문제가 없을까? 그것도 아니다. 기술은 세상을 변화시키며 탄생, 생존, 소멸을 하기 때문이다. 결국 다시 배우면서 체화해야 한다. 그리고 기술이 달라지는 것과 별개로 시장에서 요구하는 소프트웨어도 빠르게 소멸된다.
이러한 이유로
”10년이상의 경력 개발자가
자신의 프로젝트와 포트폴리오의 이력을
설명할 때 에로사항이 발생”
한다.
영원한 소프트웨어는 없다
카카오톡이 없으면 세상이 망할 것 같지만, 십수년 전에도 ICQ, MSN이나 Nate On이 없으면 세상의 모든 비지니스가 멈출 것 처럼 느낀 사람들이 많다. 그러나 그들은 우리의 일상에서 사라졌고 기억 속에서조차 찾기 힘든 존재가 되었다.
MDIR 개발자 최정한씨의 현재 근황?
Borland Turbo C 2.x
시대를 대표했던 소프트웨어도 시간이 지나면 한순간에 사라진다. 하물며 일반 개발자들의 포트폴리오가 5년안에 대부분 사라진 것은 당연지사일 것이다.
Software로 설명하기 곤란하다
소프트웨어를 개발하고 런칭하면 영원하게 운영될 것이라고 생각하면 안된다. 유지하는 것 조차 돈(하드웨어, 소프트웨어, 인건비, 등등)이기에 수익이 없는 소프트웨어를 방치할 수 없다. 그리고 StandAlone(네트워크 프로그램이 아닌 것)이라고 할 지라도 OS 업그레이드와 보안정책으로 “하위호환”이 안되는 경우가 많다. 결론적으로 소프트웨어 개발을 하고 10년간 생존하는 소프트웨어는 1%도 되지않는다. 그렇기에 대부분의 사람들에 머리 속에는 포털사이트 2~3개 정도와 메신저 1~2개 정도 외에는 기억나지 않는 것이 정상일 것이다.
결국 개발자가 자신의 포트폴리오를 설명할 수 없는 이유는 많아지게 된다. 대표적으로 포트폴리오가 뭘 하는 소프트웨어인지 이해하지 못할 때가 많다(충원 면접 시 마음 속으로 자주 하는 말. 저게 뭐하는 프로그램이라는 것이지?). 필자 역시 경력의 70% 이상의 포트폴리오를 설명할 수 없다. 이유는 다음과 같다.
포트폴리오를 설명하다가 강의가 되어버린다.
만들었을 때 구조가 수 년이 지나며 교체되었다.
nda(비밀유지계약)라 공개할 수 없다.
개발자들의 포트폴리오는 개발자들도 이해하기 힘들 때가 많다. 그러다보니 포트폴리오로 자신을 어필해야 할 경우, 어떤 시점에서는 “산업과 기술에 대한 강의”가 되어버릴 때가 있다. 초면에 부정적인 인상을 줄 수 있다. 일 예로 우리나라 모바일 플랫폼의 역사로 불리는 모바일 플렛폼의 WIPI에서 Clet의 표준 안의 일부를 담당했다라는 말을 했을 때, 이것의 가치를 아는 사람은 20년 이상된 개발자 뿐이다. 그것도 희미하게 기억할 것이다.
결국 특정 프로젝트나 업체에서 개발자들에게 포트폴리오를 요청 시 최근 3년간이라는 단서가 붙게 된다. 3년간 천지개벽이 일어나는 업종이 “개발업종”이기 때문이다. 그러다보니 수십년된 개발자가 자신의 포트폴리오를 설명할 때, 허무함을 느끼는 경우가 발생한다.
개발자에게 무엇이 남는 것일까?
개발자는 글못쓰는 것으로 유명한 업종 중에 하나이다. 그러나 반대로 개발자가 문서를 잘 만들 수록 경쟁력과 생명력이 향상된다. 결과적으로 개발자는 “글은 못쓰지만 문서는 잘써야 하는 사람”일 수 밖에 없다. 여기서 글이라고 함은 닝겐이 읽는 글을 말한다. 문서는 말그대로 “사고방식과 논리”의 집합체이다. 표준규격이 존재하며 그것을 벗어날 시 댓가를 치루어야 한다.
블로그
포트폴리오
github
블로그: 개발자가 블로그를 운영하지 않는다? 2가지 단점이 발생한다. 첫 번째는 “자신의 기술”을 검증 및 저장할 공간을 잃는 것이다. 개발자의 머리에는 자신이 경험한 모든 데이터가 존재하지 않는다. 어딘가에 저장하고 찾아야 하는 데, 실시간 검색 시 블로그만큼 좋은 것이 없다. 두번 째는 “브랜딩”과 “기회”를 상실한다는 것이다. 개발업종은 누군가의 블로그로 도움받는 경우가 많다. 그러다보니 블로그가 주는 가치는 비지니스적으로도 무시할 수 없다. 용역, 기술자문, 강의에 대한 의뢰가 심심치 않게 발생한다.
포트폴리오: “포트폴리오”는 무조건 필요하다. 문제는 꾸준히 유지보수 및 업그레이드를 해야 한다는 점이다. 그러나 사람들은 “눈에 보이는 것”부터 찾기 때문에 가장 접근성이 쉬운 방법으로 서비스되어야 한다. 필자의 경우 App 개발자이기 때문에 Google play에 앱들을 꾸준히 런칭, 업그레이드, 삭제를 반복하며 유지보수 하고 있다.
Google Play의 Vintage appMaker 개발자 Android 앱
github: 다른 것은 몰라도 개발자라면 github은 하나의 명함처럼 따라다니는 git 서비스가 되었다. 구인을 하더라도 resume에 github 주소를 요구하는 곳이 보일 정도이다(지인들의 HR을 지원해주다보니 시장의 분위기를 알게되었다). 그런 점에서 개발자라면 MS가 인수한 Github으로 가서 계정부터 파는 일을 해야 한다. 그리고 그 곳에서 자신을 성장시키는 소스와 문서를 관리한다면 Blog 이상의 효과를 얻을 수 있다.
Github은 개발자 세상에서 공인된 프로필 장소이기 때문이다.
오픈가능한 소스가 있다면
수준과 관계없이 공개가능한 기록을 꾸준히 남겨야 한다. 그리고 그런 정보는 공유가 되면서 누군가에게는 도움이 되고 개발자 자신에게는 가치의 평가대상이 된다. 그런 점에서 github은 필수, 블로그는 옵션이다.
...
세월이 흐르면 기억도 가치도 희미해진다. 결국 남는 것은 “소스”와 “문서”이다. 아쉬운 점이라면 시간이 오래 될 수록 가치는 사라지고 당시의 사고방식을 평가하는 문서로 사용될 뿐이다.
https://github.com/VintageAppMaker/long_ago_applet