최근에 웹 프론트엔드 개발자에 필요한 역량은 무엇인지 고민을 하고 있습니다. 개인적으로는 웹프론트엔드 교육의 방향을 정하기 위해서인데, 제 생각을 나누면 도움이 될 것 같아 글을 씁니다.
이글이 웹프론트엔드 개발자를 준비하는 분들에게 기존과 다른 학습방법에 대해서 고민하는 기회가 되길 바랍니다.
먼저 참고로 이 글에서 정의하고 있는 ‘웹 프론트엔드 개발자’ 는 “주로 브라우저에서 동작하는 JavaScript 개발을 하고 가끔은 HTML, CSS까지 해야하는 개발자” 임을 참고하고 읽으시길 바랍니다.
쑥쑥 크고 있는 WEB
웹이 가진 훌륭한 접근성, 공유능력, 편리성 등은 여전히 매력적 입니다. 많은 서비스가 웹을 다양하게 활용하고 있죠. 웹의 활용이 많다보니 웹 기술도 빠르게 발전하고 있죠. 더구나 인터넷 속도가 빨라지고 기기가 좋아지면서 웹이 가진 한계가 다양한 방법으로 극복되고 있습니다.
실제로 웹은 HTML5, SPA(Single Page Application)등과 함께 더 많은 능력을 추가하는 중입니다. JavaScript 표준이 계속 업데이트 중이고, 다양한 도구도 쏟아지고 있습니다.
“개발자 추천 좀 해주세요!”
웹이 기술적으로 빠르게 발전하다보니 그 모든 걸 다 이해하는 웹프론트엔드 개발자는 없다고 봐야 하는 수준입니다. 현장의 웹프론트엔드 개발자들조차 기술을 따라가기 힘들다는 이야기를 자주 합니다. 그런데 스타트업에서 대기업까지 웹 프론트 개발자는 많이 필요합니다. 아직도 데스크탑 환경을 무시할 수는 없는 상태고, 모바일웹 뿐아니라 모바일앱도 웹기반 기술 사용이 계속 시도되고 있습니다. 최근에 다녀온 2016년 Deview 행사에서도 웹기반 기술을 이용한 모바일 앱 제작사례를 몇 개 들을 수 있었습니다.
그런데 많은 기업들이 괜찮은 웹프론트엔드 개발자를 찾는 건 어렵다고 말합니다.
제 생각에 가장 큰 이유는 정말 필요한(또는 필요한 경험을 가진) 사람이 부족하기 때문이라고 생각합니다. 물론 이외에도 웹프론트엔드 개발자의 상대적인 낮은 처우문제나 지나치게 높은 스펙만을 찾는 것도 원인일 수 있겠죠.
“웹 프론트엔드 개발자가 되려고요!”
웹프론트엔드 개발자를 많이 찾는 시장의 상황에 맞춰, 많은 분들이 웹프론트엔드 개발자를 준비하고 있습니다.
어떻게 시작해야 할까요? 학습을 위한 선택지는 나름 다양합니다. 책 독학, HTML,CSS,JavaScript를 배우는 학원, Codecademy, Udacity, Udemy와 같은 온라인 학습 사이트, 프로젝트 방식의 학원, 커뮤니티, 스터디 등 많은 점점 더 좋은 선택지가 생기고 있긴 합니다. 선택지가 많은 만큼 교육 콘텐츠도 참 다양합니다. 약간 아쉬운건 인기있고 트렌디한 기술부터 가르치려는 경우가 많다는 점입니다. 숙련자들에게는 꽤 좋은 효과이지만 시작하는 분들에게는 이건 좋은 방법이 아닙니다. 그럼에도 시작단계에서 단편적인 기술만을 배우고 가르치려 합니다.
예를들어 jQuery나 React 와 같은 라이브러리의 사용법을 익히는 것에만 집중하거나, JavaScript 문법을 마스터하는 것에만 집중하는 것은 당연히 좋은 방법이 아니겠죠.
그럼 무엇을 더, 어떻게 학습하고 준비를 해야 할까요? 답을 알기 위해서는 현장의 상황을 알아볼 필요가 있습니다.
현장의 웹 프론트엔드 개발
현장의 프로젝트 과정에서 무엇이 중요한 지 부터 살펴보겠습니다. 서비스 개발에서 중요한 특징 세 가지를 뽑았습니다. 이 세 가지는 많은 문제를 일으키기도 하고 현장 프로젝트를 어렵게 만드는 이유이기도 합니다. 현장마다 다른 특징과 문제가 존재하지만 일반적인 웹 서비스를 하는 곳이라고 생각하면 됩니다.
Collaboration & Communication
Code Quality
Maintenance
Collaboration & Communication
같은 직군, 다른 직군 할 것 없이 매일매일 생기는 이슈 입니다. 같은 직군끼리는 브랜치, 버전관리, 형상관리, 이슈관리, 코드리뷰, 컨벤션, 업무나누기 등 상당히 많은 협업활동이 온라인 오프라인에서 일어납니다. 이어폰은 끼고 있지만 많은 커뮤니케이션이 일어나고 있는 셈이죠. 그런데 사람들의 커뮤니케이션은 항상 많은 문제를 발생하기도 하죠. 이런 이유로 git, github, bitbucket, jira, redmine, slack 등 협업도구와 Agile, scrum 등의 방법론을 빌려 이를 해결하고 싶어 합니다. 자바스크립트 개발자도 당연히 많은 협업 과정이 필요로 하고 위 도구를 잘 활용해야 하죠.
특히나 웹프론트엔드 개발자는 샌드위치처럼 디자인,기획 그리고 백엔드 개발이라는 다른 직군 사이에 끼어 있는 편이라 협업과정이 더 어렵고 힘듭니다.
Code Quality
개발자들은 프로젝트 개발기간의 절반 가까이 버그를 해결하는데 힘을 쏟기도 합니다. 원래 프로그래밍이 버그를 해결하는 연속적인 과정이죠. 다만 웹 프론트엔드 개발에서는 그 상황이 더 좋지 않습니다. 백엔드 개발자들이 프론트엔드 개발을 좋아하진 않는 편인데 대부분 브라우저 버그 해결에 힘을 쏟는 것이 끔찍해 보이기 때문이죠. 하지만 이건 현실이고 웹프론트엔드 개발자가 되려면 알고 있어야 하는 사실입니다. 고백하건데 NEXT라는 기관에서 학생들을 가르치면서 이런 부분을 감춰서 가르쳤던 것을 나중에서야 반성했습니다. 진실을 알려주면 흥미가 조금 떨어졌을 것 같았죠..
아무튼 좀더 나은 품질을 유지하기 위해서 웹프론트엔드 개발자는 많은 시간을 버그와 싸워야 하고 그건 분명 피곤한 일입니다. 버그 없는 코드를 만들면 좋겠지만 그것에 앞서 빨리 해결하는 방법을 공부해두는 것이 더 좋을 거 같다고 생각합니다.
품질이야기를 하면 일정 이야기를 안 할 수가 없습니다. 대부분 현장에서의 개발 완료 일정은 확정되어 있습니다.(다행히 그렇지 않은 회사가 많이 늘어나고 있지만) 때문에 개발자는 코드의 품질과 일정사이에서 많은 고민을 합니다. 늘 있는 일입니다. 현실적인 일정에 적절한 코드품질과 어색하지 않은 인터랙션 개발등을 매일 고민해야 하죠.
Maintenance
현장의 서비스는 출시가 또 다른 시작이죠. 계속 업데이트를 하면서 새로운 기능을 추가하고 문제를 해결해야 합니다. 여기서 상당히 많은 어려운 문제들이 생깁니다. 본격적으로 소스관리와 자잘한 리팩토링이 시작되면서 적당히 뜯어고치는 것과 많이 뜯어고치고 싶은 마음에서의 갈등이 생기고, 상사를 설득해야 하는 일들이 있죠. 그 사이에 새로운 기능을 넣어달라는 기획자와 우선순위를 두고 말다툼도 해야합니다. 대부분의 기획자는 눈에 보이는 UI, UX 변경이 의미가 있다고 보는 편이라 아무래도 웹프론트엔드 개발자가 할일이 많습니다. 유지보수 가능한 코드, 읽기 좋은 코드, 테스트 가능한 코드가 필요하다는 건 다 그런 이유죠.
이렇게 현장의 중요한 특징 세가지를 알아봤습니다.
이런 현장 상황에서 어떤 웹프론트엔드 개발자를 뽑고 싶을까요?
아마도 위와 같은 ‘현장의 문제를 잘 해결할 수 있는 사람들’ 일 것이라 생각합니다.
물론 신입사원이나 개발자로 입문을 하는 분들에게 이런 것을 준비 하라는 건 무리일 겁니다. 하지만 그런 신입사원이 준비되어 있다면 기업 입장에서는 채용 안할 이유가 없습니다. 그냥 그런 사원이 없기 때문이지 신입답지 않다고 채용안하진 않겠죠. 더구나 스타트업 같은 상황에서는 신입이건 경력이건 바로 일할 수 있는 개발자를 찾는 것이 급하기만 합니다. 큰 소프트웨어 기업들도 요즘 들여다보면 변해가고 있습니다. 조직을 가볍게 유지하기 위해 랩,실,센터 단위로 나누다보니, 해당 부서에서 필요한 사람을 부서별로 알아서 채용하는 분위기 입니다. 해당부서에서 딱 적합한 인물을 뽑는 것이죠. 그렇다보니 현장을 잘 이해하고 함께 빨리 일할 수 있는 사람인지 판단해서 채용합니다. 신입을 채용하는 것이지만 사실은 실무 능력을 갖춘 신입을 원하고 있습니다.
이렇게 이해하고보면 jQuery와 JavaScript 만 겉핥기로 이해하고 웹프론트엔드 개발자로 취업을 바라는 건 좋은 전략은 아닌 듯 합니다.
그럼, 어떻게 대응해야 할까요? 현장의 문제를 떠올리면서 몇가지 방법을 제안합니다.
Project ! Project!
현장의 상황을 잘 경험하는 것이 중요합니다. 학교, 학원, 스터디모임에서 프로젝트 중심으로 현장의 경험을 많이 해야겠죠. 훌륭한 멘토가 없다고 하여도 못할 건 없습니다. 주변의 문제를 찾아서 서비스를 배포까지 하는 경험을 만들어야 합니다. 그게 현장을 경험하는 것이죠.
프로젝트 이야기를 하다보니 웹프론트엔드개발에만 국한된 이야기는 아닌 듯 하네요.사실 프로젝트방식의 경험은 모든 개발자들이 전쟁터에 싸우기 전에 경험해야 하는 훈련입니다. 협업에서 어렵고 불편함을 느끼고 그걸 어떤 도구들이 해결할 수 있는지 스스로 찾고 경험하는 것이 중요합니다. 현장에서 인기있는 Agile과 같은 방법론 중 일부개념이라 이해하고 있다면 그건 아주 의미있는 경험을 한 것이라고 생각합니다. 현장에서도 애자일의 다양한 활동을 하지만 왜 하는지 모르는 경우가 놀랍게도 많습니다. 도구를 이해하는 것보다 프로젝트 과정에서 이런 방법론의 개념을 하나씩 도입 하면서 직접 경험하고 느끼는 것이 중요합니다. 그것이 정말 어떤 도움을 주는지, 필요해 보이는지 말이죠.
친구들이 쓰는 브라우저에서도 동작 되나요?
개발한 코드가 다양한 브라우저에서 동작가능하게 변경해보세요. 이런 문제를 해결하다보면 디버깅 능력도 생기고 브라우저 호환성이 무엇인지 이해하게 됩니다. 이걸 해결하는 전략은 사실 쉬운 건 아닙니다. 라이브러리의 소중함도 깨닫게 되고, polyfill이 무엇인지 이해하게 되고, transpiler의 존재의 이유도 알게 됩니다. 물론 매번 개발단계에서 이런문제까지 고민하면 재미도 없고 더 중요한 학습꺼리를 놓칠 수도 있습니다. 그럼에도 가끔은 다양한 기기와 브라우저에서 동작가능한 코드를 만들어보길 바랍니다. 이후에 이런 경험을 정리해두는 것만으로도 여러분들의 현장성 있는 실무 능력을 쏠쏠히 인정받을 수 있습니다.
뜯어고치기
개발이 완료되고 새로운 기능을 추가하고 기존기능을 대폭 수정해보세요. 이 과정은 의외로 많은 것을 배울 수 있습니다. 하다보면 전체 JavaScript코드를 다시 구현하고 싶은 마음도 들 수 있고, 사용중인 프레임워크의 철학도 뒤늦게 깨닫게 되고, 반대로 한계나 갈증을 느낄 수도 있습니다. 수정을 하다보면 이전의 코드가 잘 동작하지 않는 문제도 경험하게 됩니다. 테스트코드를 구현하면서 쓸모 없어보였던 테스트코드가 얼마나 중요한지 깨닫게 됩니다. 또한 Clean코드에도 관심을 갖게 될 겁니다. 코딩컨벤션의 중요성을 알게 되고, 좀더 읽기 좋은 코드가 필요함을 알게 됩니다. 리팩토링이 어렵고 대단한 것만은 아닙니다. 더 읽기 좋은 코드를 만드는 행위도 리팩토링 활동 중 하나 입니다.
또한 잦은 수정과 배포를 하다보면 자연스레 빌드 단계를 자동화하는 것에 관심이 이어집니다. 안정적인 코드 검사와 빠른 배포 방식을 배워서 실험하는 경험도 시도해 볼만 합니다. 현장에서 멋진 새로운 프로젝트를 하고 싶겠지만, 아마도 선배와 함께 낡은 코드를 수정할 가망성이 더 높습니다. 그것이 팩트입니다.(?)
나만의 라이브러리 만들기
라이브러리를 직접 만들어가는 경험은 두 가지 큰 의미가 있습니다.
첫째, 자바스크립트를 깊이 있게 이해할 수 있는 계기가 됩니다. 실무에서 순수한 JavaScript 코드를 구현할 기회가 의외로 별로 없습니다. 그러다보면 JavaScript의 이해도가 점점 떨어질 수 있고 근본적인 문제해결에서 어려움을 겪을 수 있습니다. 라이브러리를 제작하면서 기억된 JavaScript의 closure, prototype, callback 과 같은 언어적인 특징에 대한 이해는 오랫동안 기억될 겁니다.
둘째, 범용성있는 재사용 코드 제작을 이해하게 됩니다. 실무개발에서는 기존 라이브러리의 API를 재정의하거나 손을 봐야 하는 경우가 생깁니다. 또는 최적화라는 이유로 우리만의 라이브러리를 만들어야 하는 경우도 많죠. 이것은 대부분 선배개발자의 몫이지만, 미리 준비된 주니어 개발자도 충분히 할 수 있는 일입니다. 또한 이런 연습이 된 개발자는 서비스 코드라 하더라도 좀더 재사용 가능한 범용성 있는 코드 구현을 할 줄 압니다. 그런 코드는 당연히 변경에 잘 대응가능한 칭찬 받아 마땅한 것입니다.
추가로 의미를 더 찾고자 하면, 수 많은 CSS, JavaScript 라이브러리중에 어떤 것이 더 좋고 우리 상황에 적합한지 판단할 수 있는 능력도 길러진다는 사실일 것 같네요.현장에서는 필요한 도구를 고르는 것이 이제 중요한 능력이 돼 버렸습니다.
Debugging
각종 브라우저의 개발자 도구기능을 잘 알아두는 게 좋습니다. 이런 자료는 많습니다. 대부분의 책에서 이것의 중요성과 방법을 언급하지 않습니다. 그런데 웹 프론트엔드 개발의 대부분은 개발자도구라는 친구와 함께 내가 저지른 버그를 해결하는데 보내게 됩니다. 그러니 디버깅을 잘 하느냐 못하느냐는 생산성과 나의 여가시간 확보에 큰 영향을 미치는 것이죠.
chrome developer tools
더불어 디버깅 툴을 잘 쓰면 아직도 헷갈릴 수 있는 자바스크립트의 비동기콜백의 이해나 클로저 개념을 더 정확하게 이해하게 됩니다. 혹시 ‘난 좀 알아’ 라고 생각하는 분들이라면 모바일웹 디버깅까지 해보시기 바랍니다.
UX 를 고민해보자
웹프론트엔드 개발자에게 요구되는 능력 중 하나는 UX입니다. (살짝 희망입니다) 기획자나 디자이너는 부드럽게 동작가능한 UX를 어떻게 구현해야 할지 방법을 모릅니다. 어디까지 되는지 어떤 브라우저에서 되는지 성능에 어떤 문제가 있는지를 모릅니다. 가끔 우리가 웹서핑중에 경험하게 되는 편리하고 엣지 있는 UX사이트는, 대부분 UX설계가 잘 된 것보다는, 웹프론트 개발이 훌륭하기 때문일 수 있습니다. (물론 전문UX분들과 훌륭한 협업이 필요) 개발자가 적극적으로 다양한 테스트와 실험을 통해서 혁신적이고 편리한 UX를 얻을 수 있습니다. 내가 UX전문가라고 생각하고 좀더 나은 경험을 제공하기 위한 자바스크립트 인터랙션 개발을 고민하는 것이 꽤 중요한 일입니다. 저는 개인적으로 현장에서 이런 개발자를 만나는 걸 굉장한 행운이라고 생각하고 있습니다. 그만큼 찾기 힘듭니다.
Code Review
JavaScript는 상대적으로 다른 언어보다 다양한 패턴의 코드로 구현이 가능합니다. 언어의 자유도로 인해서 JavaScript 객체 그 자체로만 표현할 수도 있고, OOP언어를 흉내내서 클래스처럼 구현할 수도 있고, 함수형 프로그래밍처럼 구현할 수도 있습니다. 잘 구현되고 괜찮은지 알기가 좀 어려울 수 있습니다. 많은 사람들의 조언이 필요한 셈이죠. 내 코드에 대해서 내 기준이 아닌 다름사람의 의견을 듣는 경험이 필요합니다.
일반적인 코드리뷰의 장점은 사고를 폭넓게 하게 되고, 생각지 못한 부분에서 더 좋은 코드구현 방법을 알게 된다는 점이죠. 실제로 현장에서도 이런식으로 품질을 올리기도 하고요. 코드리뷰의 장점은 많은데 이미 다른 사람들에게 공유된 코드이기 때문에 문제가 생겼을 때 동료와 함께 더 빠르게 해결할 수도 있습니다.
끝으로,
나열하고 보니 할 일이 많아진 것 같네요. 아마 이만큼 훈련이 된, 준비된 개발자가 있다면 대부분 회사에서 채용하고 싶어질 것 같네요. 이것 말고도 사실 더 연습해야 할 것이 많지만, 이것만으로도 양적으로 너무 많군요; 모두 다 경험 할 수가 없다면 몇 가지라도 깊이있게 경험하는게 좋다고 생각합니다.
개인적으로 이렇게 준비된 주니어 분들이 생각보다 큰 일을 할 수 있다고 생각합니다. 웹프론트엔드 개발문화가 아직 성숙하지 않은 곳이 많습니다. 그런 곳에서는 오히려 훌륭한 웹 프론트엔드 주니어 개발자가 주인공이 되어 맹활약을 할 수 있지 않을까요?
코드스쿼드 마스터 윤지수 입니다 웹 프론트엔드를 담당하고 있습니다. http://codesquad.kr/ https://www.facebook.com/codesquad.kr/
가입하기
