대기업 개발팀에서 개발자로 남기
https://brunch.co.kr/@startupbongbong/6
대기업 개발팀, 정확히는 내가 속해 있던 팀에서 내개 필요한 능력, 그리고 키워 나갔던 능력은 영어, 메일을 잘 쓰는 능력 등이었습니다. 물론, 업무 영역에는 디버깅도 어느 정도 포함되어 있었기 때문에 남이 만들어 둔 소프트웨어를 분석하는 능력도 키울 수 있었습니다. 하지만 어디까지나 업무의 일부분일 뿐이었기 때문에 나만의 무엇가를 만들면서 배우고 고쳐나가는 경험은 할 수 없었습니다.
정체성이란 개발자로서의 정체성인데 앞서 말했던 새로운 기술을 배우고 지속적으로 발전하여 성장하는 개발자가 되는 것 입니다.
대기업 개발자의 업무
첫번째는 외부 개발팀과의 협업이었습니다. 주로 그들에게 그 프로젝트에 대한 문서를 요구하고 검토했고 그들이 만든 소스코드를 분석하기도 했습니다 .또한 그들이 어떤 의사결정이 필요한 것을 물어오면 나는 나의 상사와 협의하여 의사결정을 내려주기도 했습니다.
두 번째는 디버깅입니다. 대기업은 굉장히 큰 프로젝트를 굉장히 작은 단위로 나누어서 굉장히 많은 사람에게 작게 작게 조각을 나누어 줍니다. QA팀에서는 내가 맡은 프로젝트에 대해 지속적으로 문제점이 되는 것을 알려왔고, 나는 그 문제점을 해결해야하는 위치에 있었습니다. 어떤 한 프로젝트가 처음 만들어질 때는 문제의 종류가 굉장히 많고 매번 다른 문제점이 나오는 경우가 많았습니다. 따라서 지속적으로 코드 분석을 해야했고 그에 따른 디버깅을 해야만 했습니다.
세 번째는 메일입니다. 외부 업체 혹은 다른 부서의 질문에 답하기도 하고 상사가 지시하는 다른 부가적인 업무를 하기도 합니다.
대기업에서의 개발
개발을 하고 새로운 기술들을 배우고 남는 시간엔 다른 취미들을 즐기는 모습을 상상하며 즐거워 했습니다. 게다가 대기업이 주는 네임밸류로 인해 한껏 추켜올려진 나의 어깨는 덤이었습니다. 적어도 내가 생각하는 개발자란 문제 해결을 위해 알고리즘을 생각하고 구현을 하며 잘못된 부분은 찾아서 고쳐나가야 했습니다. HQ는 프로젝트의 큰 방향을 정해주고, 디버깅 그리고 외부 개발업체와의 협업 시 중재하는 역할 등 실제 개발과는 거리가 좀 떨어진 일들이 주였습니다.
명칭은 분명 개발자이지만 실제 개발에 가깝다고 말할 수 있는 일은 남이 만들어 둔 소스에 대한 분석 및 디버깅이었고 나머진 외부 개발팀과의 협업에서 방향 제시 및 의사결정과 외부 부서와의 협업 정도라고 볼 수 있었다. 적어도 10년에서 15년 사이 정도의 기간 동안은 안정적이라고 생각했다. 내 주변을 봐도 그 정도의 나이까진 대부분 무난히 근무하는 분위기였기 때문이다.
그 업무는 내가 있던 그곳에서만 통하는 업무였고 이대로 계속해서 전문성을 잃어가면 나는 결국 회사에 종속될 것이라는 생각이 들었습니다. 회사에서 나오면 할 수 있게 없어서 결국 회사에서 버티는 것을 최우선으로 삼게 될 것 같았습니다. 소프트웨어 엔지니어, 개발자라고 생각해왔다. 개발자는 지속적으로 새로운 기술을 배우고 연마하여 요구사항에 맞춰서 최선의 결과물을 만들어내야 한다. 뛰어난 실력을 가지고 회사에서 언제 나오든 자신 있어하는 모습이 오히려 더 안정적이라고 생각했다.
취업 어려운 대기업 출신 개발자들
https://brunch.co.kr/@sbroh/3
40대 중반, 괜찮은 학교 공대 나와서 삼성전자에서 10년 넘게 근무한 개발자. 요새 가장 취업시키기 어려운 엔지니어의 모습 중 하나입니다. 연봉이 높다. 낮춘다고 해도 높다. 그 정도 경력이면 본봉과 인센티브 합쳐서 1.4정도 찍느다. 한참 잘 나갈 때 PS 충분히 챙긴 개발자 기준이긴 합니다. 중소기업은 0.7만 해도 부담스러워 하는 회사가 많습니다. 본인 당사자의 문제가 아니라 가족의 생활수준이 거기에 맞춰져 있어서 낮추는 데에 한계가 있습니다. 대기업에서는 큰 회사의 작은 부분을 맡아서 해서 작은 회사에서 할 수 있는 일이 그리 많지 않습니다. 삼성에서 서버 개발을 하지는 않았을 것 아닌가.
사실 작은 회사 출신들이 오히려 갈 곳, 할 일들은 더 많다. 잡다한 일을 많이 해봤으니까. 오래 일할 호가율이 더 높아 보인다. 큰 회사에서 6-7년 이상 있는 것. 개발자로서 절대 좋은 일이 아니다. 경쟁력 정말 없어진다. 몇십명 안되는 회사에서 가족같이 잘먹고 잘사는 경우는 예외입니다. 회사를 보지 말고 산업을 봐야 합니다. 내가 이 회사를 그만두고 나가서 할 일이 또 있을 수 있는 일을 나는 하고 있는가. 당연히 기술도 포함.
풀 스택 개발자
https://brunch.co.kr/@mobiinside/688
한국 채용시장에서는 단말, 서버, 웹, DB 등 모든 것을 다 할 줄 아는 개발자를 말합니다. 풀 스택의 유래. 1980년대 어셈블러나 C로 컴퓨터 프로그램을 만들던 시절에는 1인이 모두 다 개발했습니다. 컴퓨터 자원이 한정되어 있기도 하고, 프로그램 구조도 단순했습니다. 1990년대 클라이언트 서버, 인터넷이 등장하자 기술구조가 매우 복잡해지면서 많은 전문가가 필요하게 되었습니다. 그리고 이를 튜닝하는 일도 매우 복잡했습니다. 2000년대 통신이 늘어날수록 계층이 추가되었습니다. 유지보수도 작은 인력으로 할 수 없게 되었습니다. 2000년대 후반, LAMP 스택을 지원하는 클라우드 환경이 생겼고, 새로운 기술들을 스택형태로 제공되기 시작했습니다. 그래서, 이 당시 실리콘밸리에성는 Full Stack Developer를 많이 찾게 되었습니다.
풀스택 개발자는 서버가 지속적으로 확장해야 하는 환경에서 기술의 동질성을 확보하기 위한 기술팀의 선택이었습니다. 그래서 채용의 주체가 인사팀이 아니라 개발팀이었습니다. 기술경험이 유사한 동료들을 뽑고 싶었던 것입니다. 국비과정을 거쳐서 풀스택 개발자가 되는 경우는 존재하지 않습니다. 많은 개발팀ㄴ이 오히려 열려 있고 적극적인 친구를 찾아내서 팀에 맞는 개발자로 키워내고 싶어 합니다. 풀스택 개발자는 일반적으로 중급 이상의 개발자가 그런 프로젝트를 하면서 다양한 문제해결능력과 서비스 구축능력을 갖추게 된 경우를 말합니다.
슈퍼 개발자 네임드?
https://brunch.co.kr/@supims/163
그 당시 그런 일이 가능했던 것은 현대의 개발처럼 프레임웍이나 개발도구, 분석도구, 스크립트 기반의 환경 등등의 고속화 개발이 가능한 도구와 프레임웍을 만드는 기술을 구사하는 것이 매우 어렵던 시절의 이야기 입니다. 수십 명이 10년 넘게 개발해온 소프트웨어를 프로파일링 분석도구를 만들고, 패턴화 한 다음 프레임웍과 컴포넌트 형태로 재구성하고, 자동 번역 프로그램을 만들어서 컨버팅 하는 구조로 단지 몇 주만에 전체적인 소프트웨어의 문제를 처리해준 경험이 있습니다.
기반기술과 오버 엔지니어링이 아닌 적절한 선택, 클린 코드와 쉬운 개발 방법을 통해서, 서비스 품질이 높은 소프트웨어를 개발하면서 이런 관점을 개발자 동료들과 호흡하고 공유하며, 소통할 수 있게 하는 시니어개발자와 이런 철학을 이야기하는 구루급 개발자들은 분명 존재합니다.
보통의 개발자들은 시니어 개발자나 구루급 개발자를 지향하지 않습니다. 대부분은 오픈소스나 시니어 개발자들이 만들어 놓은 환경 위에 손쉽게 소프트웨어를 만들어서 품질 지향의 서비스를 구현하는 것이 대부분 하는 일이니까요.
많은 개발자가 부족한 연봉을 스톡옵션으로 메꿀 수 있다는 희망을 품습니다. 매우 소수의 스타트업만이 스톡옵션을 돈으로 환전할 수 있기 때문입니다. 샘 알트만이 작성한 Employee Equiry에 따르면 스타트업은 초기 10명의 직원에게 총 10%의 스톡옵션을, 다음 20명에게 5%, 다음 50명에게 5%의 스톡옵션을 할당하 것을 권장합니다. 여기에 지분 희석과 세급 납부 등을 추가로 고려해야 합니다.
위의 내용을 종합해 보았으 때 물론 스톡옵션은 위의 내용 외에도 다양한 경우의 수를 고려해야 합니다. 스타트업 초기 10명의 직원이 수도권에 집을 사기 위해서는 회사가 적어도 1,000억까지는 성장해야 하는 것 같습니다. 아니면 1조가 넘어가는 유니콘 클럽(쿠팡, 카카오)에 회사를 매각하는 방법이 있는데 이 역시 초기 구성원이 큰돈을 만지는 건 어렵습니다.
무조건 대마에 들어가라. 상장을 목표로 하는 매우 크게 성공할 스타트업에 합류해라. 100억 ~ 300억에 회사를 매각하는게 목표인 회사에서 초기 구성원은 큰돈을 만지지 못합니다. 회사가 성공했음에도 개발자들에게 좋은 대우를 해주지 않는 회사들이 분명 존재하며, 스타트업에 들어가기 전에 이를 염두에 둬야 합니다.
로켓에 자리가 나면 일단 올라타는 것도 좋은 전략입니다. 하지만 로켓에 올라타기 전, 본인이 로켓 안에서 최선을 다한다는 가정하에, 어느 좌석까지 올라갈 수 있는지 고려해야 합니다. 회사에서 여러분의 개발 실력에 대해 카페 24 쇼핑몰 빌더 이상의 가치를 느끼지 못한다면, 여러본은 절대로 이코노미석을 벗어날 수 없습니다.
협상 테이블에 들어가기 전 반드시 사전 지식을 공부하세요. 스톡옵션 x%를 제안받았을 때 이 옵션의 가치를 빠르게 계산하지 못하면 협상을 유리하게 이끌 수 없습니다. 또한, 스톡옵션에는 퍼센티지나 주당 가격 외에도 많은 조건이 있습니다. 적어도 베스팅과 클리프, 그리고 태그 얼롱은 반드시 숙자하고 들어가세요.
나는 업계 표준보다 더 뛰어난 개발자이므로 특별한 대우를 받고 싶다고 강조하세요. 가장 중요한 건 가능한 많은 스타트업과 만나는 겁니다. 가능한 많은 협상 테이블을 열고 탐욕스럽게 협상하세요. 마치 스타트업이 자금 조달을 하는 것처럼 최대한 많은 계약서를 받으세요.
지표가 나오는 스타트업은 어떨까요? 다소 구분할 수 있지만, 개발자의 얕은 지식으로는 한계가 있습니다. 가장 확실한 방법은 전문가에게 물어보는 겁니다. 이 분야의 전문가는 단연 벤처 투자자입니다. 지표의 업계 기준치, 시장의 크기와 변화, 경쟁자를 상대로 승리할 가능성, 회사가 잘 안 되었을 경우 매각 전략 등, 이 몯느 것을 직업적으로 분석하는 것이 벤처 투자자입니다. 개발자가 돈을 버는 정도는 높은 연봉과 정년, 9 to 6가 보장되는 기업에 들어가서 퇴근 후의 저녁을 유용하게 활용하는 것입니다.
저녁에 개발 스킬을 키우거나, 주식과 부동산을 공부하거나, 아니면 고수익의 개발 아르바이트를 한다면 스타트업으로 이직하는 것보다 더 쉽고 안전하게 내 집 마련을 할 수 있습니다. 시스템이 갖춰진 대기업은 안정적으로 대응할 수 있지만, 인원도 예산도 부족한 스타트업은 그럴 수 없습니다.
한 가지 확실한 건, 스타트업은 대기업과 비교하면 월등히 좋지 않은 근무 환경을 갖고 있습니다. 그럼에도 불구하고 저는 개발을 사랑하는 사람이라면 적어도 한 번은 스타트업에서 일해볼 만한 가치가 있다고 생각합니다. 스타트업은 레거시 코드에 대한 부담이 덜 하므로 새로운 기술들을 마음껏 체험해 볼 수 있고, 복잡한 과정을 거칠 필요 없이 IRC나 Slack으로 빠르게 의사결정을 내릴 수 있습니다. 스타트업에서는 좋은 개발자 문화를 유지하는 것이 무엇보다 중요한데, 뛰어난 케미컬을 갖춘 A급 엔지니어들은 검수 과정을 생략하고 실시간으로 기능을 배포해도 제품의 퀄리티를 떨어뜨리지 않기 떄문입니다.
스타트업에서 시니어 개발자를 구하기 어려운 이유
https://medium.com/happyprogrammer-in-jeju/%EC%8A%A4%ED%83%80%ED%8A%B8%EC%97%85%EC%97%90%EC%84%9C-%EC%8B%9C%EB%8B%88%EC%96%B4-%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%A5%BC-%EA%B5%AC%ED%95%98%EA%B8%B0-%EC%96%B4%EB%A0%A4%EC%9A%B4-%EC%9D%B4%EC%9C%A0-cd123f779052
좋은 시니어 개발자란 이런 사람이 아닐까 하는 생각을 합니다. 번듯한 IT기업에서 나름 인정받을 만큼 실력을 보유한, 검증된 개발자. 데기업의 프로세스를 체화하고 있어서, 스타트업에서도 바로 적용해 줄 수 있는자. 10년 정도의 숙련된 경험으로, 갑자기 문제가 생겨도 침착하게 대응할 수 있는 사람, 나아가 문제가 생기지 않게끔 빠르고 안정적으로 개발하는 사람. 오랜 경력에 걸맞게 대인관계나 커뮤니케이션에 뛰어난 사람. 경력이 있으니 깊이 있는 기술이 있을 테고, 또 스타트업에서 일해야 하는만큼 다양한 기술 스펙트럼을 보유하고 있는 사람. 소위 풀스택 개발자인데, 각 분야도 부족하지 않은 깊이가 있는 사람. 우리의 멋진 비전과 일치해서, 급여가 적더라도 미래의 폭발적 가능성을 보고 동기부여가 충만할 사람.
오랜 경력으로 문제 상황에 침착하게 대처한다. 이런 자질은 어느 정도 기대를 걸어볼 만합니다. 장애 대응 능력 같은 것은 어디에서 책이나 구전으로 배울 수 없고, 실제 경험으로만 배울 수 있는 부분이 크기에, 그런 면에서 경력자를 우대하는 것은 인정할 만합니다. 아무리 유능한 신입도, 프로덕션에서 발생하는 문제들을 즉각 해결해야 하는 긴장된 상황 같은 영역에서는 메꿀 수 없는 넘사벽의 틈새가 있으니까요.
https://brunch.co.kr/@supims/150
https://medium.com/happyprogrammer-in-jeju/%EC%8A%A4%ED%83%80%ED%8A%B8%EC%97%85%EC%97%90%EC%84%9C-%EC%8B%9C%EB%8B%88%EC%96%B4-%EA%B0%9C%EB%B0%9C%EC%9E%90%EB%A5%BC-%EA%B5%AC%ED%95%98%EA%B8%B0-%EC%96%B4%EB%A0%A4%EC%9A%B4-%EC%9D%B4%EC%9C%A0-cd123f779052