*해당 콘텐츠는 2017년 7월 5일에 발행한 내용으로, 독자분들께 다시 한번 소개합니다.
‘풀스택 개발자‘ 한동안 인터넷을 강타했던 용어입니다. 지금은 많이 사그라들었지요. 하지만, 아직도 일부 학생들 사이에서 이상적인 개발자처럼 인식되고 있습니다. 그래서, 이 실상에 대해 한번 짚고 넘어가고자 정리를 했습니다.
1. 사장님들이 생각하는 풀스택 개발자
한국 채용시장에서는 단말, 서버, 웹, DB 등 모든 것을 다 할 줄 아는 개발자를 말합니다. 얼추 맞는 말인 것 같은데 종종 2명을 뽑지않고 1명을 뽑아도 되는 것처럼 인식되고 있습니다. 이상하지만 실제로 이렇게 알고 계시는 분들이 많습니다. 간혹 높은 연봉에 이끌려 지원했다가 마음 고생 후 이직을 하는 개발자들도 있었습니다.
2. 풀스택의 유래
그러면 풀스택이란 말은 어떻게 유행이 되었을까요? 테크크런치에 실린 자료를 바탕으로 정리해 보았습니다.
- 참고 글 : The Rise And Fall Of The Full Stack Developer (2014. 테크크런치)
1980년대: 어셈블러나 C 로 컴퓨터 프로그램을 만들던 시절에는 1인이 모두 다 개발했습니다. 컴퓨터 자원이 한정되어 있기도 하고, 프로그램 구조도 단순했습니다.
1990년대: 클라이언트 서버, 인터넷이 등장하자 기술구조가 매우 복잡해지면서 많은 전문가가 필요하게 되었습니다. 그리고 이를 튜닝하는 일도 매우 복잡했습니다.
2000년대: 그래서 뭐 하나 만드는게 매우 비쌌습니다. 통신이 늘어날수록 계층이 추가되었습니다. 유지보수도 작은 인력으로 할 수 없게 되었습니다. 그래서 Java Enterprise Version + Oracle 로 작업할 수 밖에 없었습니다.
그런데, Web2.0 으로 웹기술이 뜨면서 통신계층을 단순화 시켰습니다. 그러자 꽤 많은 부분이 LAMP 스택으로 대체되었습니다.
2000년대 후반. LAMP 스택을 지원하는 클라우드 환경이 생겼고, 새로운 기술들을 스택형태로 제공되기 시작했습니다. 그래서, 이 당시 실리콘밸리에서는 Full Stack Developer를 많이 찾게 되었습니다.
3. 풀스택 개발자란?
즉, 풀스택 개발자는 서버가 지속적으로 확장해야 하는 환경에서 기술의 동질성을 확보하기 위한 기술팀의 선택이었습니다. 그래서 채용의 주체가 인사팀이 아니라 개발팀이었습니다. 또 모든 스택을 잘 다룰 줄 안다는 전제도 없었습니다. 다만, 기술경험이 유사한 동료들을 뽑고 싶었던 것입니다.
참고로, 이것은 실리콘밸리의 사업환경과도 밀접한 관계가 있습니다. 빠르게 성과를 보여 투자를 받아야 하고, 글로벌하게 증가하는 트래픽과 데이터에도 능동적으로 대처할 수 있어야 하기 때문입니다. 반면 그런 사업적 환경이 낮은 나라에서는 풀스택 개발자의 필요성을 적게 느꼈습니다.
4. 그럼 풀스택 개발자가 어떻게 해야 될 수 있을까?
결론부터 이야기 하자면, 취업준비생이 국비과정을 거쳐서 풀스택 개발자가 되는 경우는 존재하지 않습니다. LAMP 를 배웠다고 하더도 트러블슈팅이나 응용능력이 없기 때문에 채용 목적을 충족시킬 수 없습니다. 그래서 많은 개발팀이 오히려 열려 있고 적극적인 친구를 찾아서 팀에 맞는 개발자로 키워내고 싶어 합니다.
풀스택 개발자는 일반적으로 중급 이상의 개발자가 그런 프로젝트를 하면서 다양한 문제해결능력과 서비스 구축능력을 갖추게 된 경우를 말합니다. 하지만, 풀스택 개발자라고 하더라도 1인이 2인분의 일을 해낼 수 있다는 것은 아닙니다. 그리고, 모든 계층에서 전문가가 된다는 것도 아닙니다.
5. 풀스택 개발자, 아직도 인기인가?
이미 실리콘밸리에서는 Full Stack Developer에서 Full Stack Integrator 로 옮겨 갔습니다. 이미 충분히 복잡한 기술들이 패키징 되어서 클라우드 위에 올라가고, SaaS 형태로 제공되고 있기 때문입니다. 즉, 기술 환경의 변화에 따라서 채용시장도 변했다는 뜻입니다.
6. 조직의 입장에서 생각
문제는 현업의 트렌드가 채용시장으로 흘러 나올 때 잡음들이 많이 생깁니다. 또는 용어가 바다를 건너면서 잘못 이해되는 경우도 많습니다.
새로운 용어가 등장하면 왜 나왔을까 한 번쯤 깊이 고민하면 좋겠습니다. 트렌드의 출발점이 우리가 풀려는 문제점과 유사할 때 선택했으면 합니다. 아무런 문제의식 없이 수용하면 다양한 거부반응들이 일어납니다. 특히 실제 일을 해야 할 개발팀이 마비되어 버리는 경우가 적지 않습니다.
7. 취준생 입장에서 생각
취업을 목표로 한다면, 현실적인 채용상황들에 맞출 필요가 있습니다. 한국의 IT 상황이 많이 변하긴 했지만, 여전히 Java Spring 이 강세라는 건 부정할 수 없을 것 같습니다. 다만 Oracle 은 이미 MySQL 로 많이 대체되었습니다.
8. 개발팀 입장에서 생각
새로운 용어나 기술환경이 등장하면 꼭 현황 진단을 먼저 했으면 좋겠습니다. 일반적으로 새로운 기술은 새로운 문제를 해결하고자 합니다. 그리고, 그 문제는 대부분 사업환경의 변화 때문에 일어납니다. 아직 우리 조직이 새로운 사업을 시도하지 않는다면 새로운 기술이 필요없을 수도 있습니다.
새로운 기술은 결코 ‘새 기술 덕후’들이 만들어 내지 않습니다. 현재의 기술로 해결할 수 없는 문제를 고렙의 개발자들이 해결하고자 시도한 것입니다. 그래서 반드시 기술이 만들어진 이유가 있습니다. 시장에서 핫한 기술이라고 스타와 팬처럼 따라가서는 곤란합니다. 문제가 존재하지 않는 곳에 솔루션이 존재할 이유가 없기 때문입니다.
소프트웨어 개발자 김수보님의 글을 모비인사이드에서 소개합니다.
[fbcomments url=“http://ec2-13-125-22-250.ap-northeast-2.compute.amazonaws.com/2018/12/19/resubokim-fullstack/” width=“100%” count=“off” num=“5″ countmsg=“wonderful comments!“]
