이 포스트는 구글의 엔지니어인 Philip Walton의 허락을 받고 How to Become a Great Front-End Engineer를 번역한 것입니다. 첫 영문 포스트 번역이라 오역이 난무할 수 있으니 댓글로 따끔한 지적 부탁드립니다. 의역을 많이 하고 있으니 가급적 원문도 참고하시는 게 좋습니다.
얼마 전에 내 블로그의 독자로부터 이메일을 하나 받았다. 이유가 뭐든 간에, 많은 생각을 하게되는 이메일이었다. 그 내용은 이랬다.
Philip님 안녕하세요. 어떻게 하면 탁월한 프론트엔드 엔지니어가 되셨는지 여쭤봐도 될까요? 조언 부탁합니다.
나는 지금까지 스스로 “탁월한” 프론트엔드 엔지니어라고 생각한 적이 없었기 때문에 무척 놀랐다. 사실, 내가 이 업계에 발을 들여놓은지 얼마 안되던 시절, 솔직히 어떤 일자리도 가질 자격이 없다고 생각했다. 나는 내가 얼마나 모르는지 깨닫지도 못했기 때문에 그냥 지원만 했을 뿐이다. 그리고 날 면접본 사람이 질문을 제대로 하지 못했기 때문에 직업을 얻은 것 뿐이다.
그럼에도 나는 결국 내 역할을 꽤 잘했고 팀에서 가치있는 구성원이 되었다. 내가 팀에서 빠지게 되었을 때(그럴 자격이 없었지만, 다음 도전을 위해서) 나의 대체자를 고용하는 업무를 했었다. 입사 면접 때 내가 어떻게 했었는지 지금 돌아보면, 처음에는 이 분야에 대해 부족했음에도 불구하고 지식에 대해 많은 강조를 했던 것에 충격받았다. 현재의 나는 아마 경험적으로 내가 성공할 가능성이 있다고 알고 있음에도 과거의 나를 고용하지 않았을 것이다.
웹 분야에서 오래 일하면서 그냥 잘하는 사람과 진짜로 잘하는 사람을 구분하는 기준은 “무엇을 아느냐”가 아니라 “어떻게 생각하느냐”라는 사실을 깨닫고 있다.
확실히 지식은 중요하고 어떤 때에는 치명적이다. 하지만 환경은 정말 빠르게 변화하기 때문에 지식을 얻는 방법은 이미 알고 있는 지식보다 항상 더욱 중요하다. 아마도 매일 문제를 해결하기 위해 지식을 활용하는 방법보다도 중요할 것이다.
직업을 얻기 위해 필요한 언어, 프레임워크, 도구들에 대해 말하는 글은 널려있다. 나는 조금 다른 접근을 하고자 했다. 이 포스팅에서는 프론트엔드 엔지니어로서의 마음가짐에 대해서 말할 것이며, 탁월한 프론트엔드 엔지니어가 되는 법 에 대해 조금 더 영구적인 해법이 되었으면 한다.
문제를 해결하는데 그치지말고 어떻게 동작하는 지 파악하라
너무 많은 사람들이 무언가 동작하게 만들기 위해 CSS나 JavaScript를 어설프게(tinker) 손댄다. 나는 항상 코드 리뷰를 할 때마다 이런일이 일어나는 것을 종종 봐왔다.
나는 종종 그들에게 “왜 여기에 float: left를 추가한 겁니까?” 혹은 “여기에 overflow: hidden은 정말로 필요한 건가요?”라고 묻는다. 그럼 그들은 대부분 “몰라요. 하지만 제가 그걸 지우면 제대로 동작하지 않습니다.”라고 대답한다.
JavaScript에서도 마찬가지였다. setTimeout을 그저 경쟁 상태(race condition)를 막기 위해 사용하는 사람도 있었고, 다른 이벤트 핸들러에 어떤 영향을 미칠지에 대한 고려도 없이 event propagation을 멈추는 사람도 있었다.
이것이 당장 동작하는 구현을 필요로 할 때 일어나는 일인 것을 알고있다. 하지만 문제의 원인을 이해하려하지 않는다면 항상 같은 문제를 마주하게 될 것이다.
당신의 해결법이 어떻게 동작하는 지를 이해하는 것은 당장은 시간이 많이 들 수도 있지만 결과적으로 시간을 아끼게 될 것이다. 작업하는 시스템에 대해 완벽히 이해하게 되면 앞으로 불필요한 추측이나 체크하는 작업이 적어질 것이기 때문이다.
브라우저의 변화를 예측할 수 있게 학습하라
프론트엔드 개발과 백엔드 개발의 가장 큰 차이점은 백엔드 코드가 제어할 수 있는 환경에서 돌아가는 반면에, 프론트엔드의 환경은 완전히 제어 밖에 있다는 것이다. 사용자가 사용하는 플랫폼이나 기기는 계속 변하며, 코드는 이것을 모두 지원할 수 있어야 한다.
2011년에 어떤 유명한 자바스크립트 프레임워크가 있어서 한 번 읽어본 적이 있다. 거기에 있던 코드 중 일부분을 소개한다. (단순화한 버전이다.)
1 | var isIE6 = !isIE7 && !isIE8 && !isIE9; |
아마도 IE6와 그보다 오래된 버전의 IE를 핸들링 하기 위한 코드로 짐작된다. 그러나 IE10이 등장하자 이 프레임워크의 많은 부분이 못쓰게 되어버렸다.
나는 Feature detection)이 실제로 항상 100% 동작할 수 없다는 것을 알고있다. 그래서 가끔은 특정 브라우저의 잘못된 Feature detection이나 버그 투성이의 동작에 의존해야 할 것이다. 하지만 그럴 때는 미래에 그 버그가 존재하지 않는 특정한 때를 예측하는 것이 절대적으로 중요하다.
오늘날 우리가 쓴 코드는 우리가 재직하는 기간보다 오래 살아남는다. 내가 쓴 코드 중 어떤 것들은 8년 넘게 실제 서비스하는 웹 사이트에서 대규모로 돌아가고 있다. 나는 만족스럽지만 두렵기도 하다.
명세(Spec)를 읽어라
브라우저에는 항상 버그가 존재하지만, 두 개의 브라우저가 같은 코드를 다르게 렌더링 할 때 사람들은 종종 스스로 점검하기 보다는 소위 “좋은” 브라우저가 옳고, “나쁜” 브라우저가 틀리다고 생각한다. 하지만 항상 그런 것은 아니다. 그리고 그 생각이 틀렸을 때, 선택한 해결방법이 무엇이든 미래에는 거의 확실히 동작하지 않는다.
flex 요소의 디폴트 최소 크기가 이것의 적절한 예이다. 명세에 따르면, flex 요소의 min-width 와 min-height 초기 값은 0이 아니라 auto이다. 이것은 기본적으로 flex 요소가 요소 내부의 콘텐츠보다 작을 수 없다는 것을 의미한다. 지난 8개월 간, 파이어폭스가 이것을 맞게 구현한 유일한 브라우저였다.
만약 크로스 브라우저 호환성 문제에 직면해서 웹사이트가 크롬, IE, 오페라, 사파리에서는 동일하게 렌더링되지만 파이어폭스에서만 다르게 보인다면, 아마 파이어폭스가 잘못되었다고 생각할 것이다. 사실 나는 이런 경우를 많이 목격했다. 나의 Flexbugs 프로젝트에 보고된 많은 이슈들과 제안된 임시 방편들(Workaround)이 실제로 이 호환성에 기인한 것이었다. 제시된 임시 방편대로 구현했다면 2주 전에 크롬 44 버전이 나오면서 동작하지 않게 되었을 것이다. 그들은 명세를 따른 이 임시방편 대신에, 잘 모르는 채로 좋은 해결법을 비난했다.
2개 이상의 브라우저가 같은 코드를 다르게 렌더링 할 떄, 어떤 브라우저가 코드에 맞는 동작을 하는지 시간을 내서 파악해야 한다. 그럼 그 해결방법은 결과적으로 더 미래 친화적인 해결방법이 될 것이다.
덧붙여, 소위 “탁월한” 프론트엔드 엔지니어들은 대부분 변화의 최전선에 있는 사람들이다. 새로운 기술을 채택하는 걸 넘어 그 기술의 주류이거나 심지어는 해당 기술의 발전에 기여한다. 명세를 보면서 스스로 능력을 기르고 브라우저에서 실행해보기 전에 기술이 어떻게 동작할 수 있는지 생각하면 명세에 대해 이야기하고 명세의 개발에 영향을 끼칠 수 있는 그룹의 구성원이 될 수 있을 것이다.
다른 사람의 코드를 읽어라
아마 신나는 불토에 재미로 다른 사람의 코드를 읽고 싶은 생각은 없을 것이다. 하지만 이것은 의심의 여지없이 더 나은 개발자가 되는 최고의 방법이다.
스스로의 방식대로 문제를 푸는 것은 배우기에 탁월한 방법이지만, 그 방법이 끝이라면 꽤 빨리 한계에 도달할 것이다. 다른 사람들의 코드를 읽는 것은 무언가를 해결하는 데에 있어서 새로운 방법을 제시해 준다. 그리고 직접 작성하지 않은 코드를 읽고 이해하는 능력은 어떤 팀에서 일하거나 오픈 소스 프로젝트에 공헌하는데 있어서 필수적이다.
나는 실제로 새로운 엔지니어를 채용하는 면접 때, 그냥 완전히 새로운 코드를 작성하도록 시키는 것이 회사들의 가장 큰 실수 중 하나라고 생각한다. 내가 지금까지 면접을 보면서, 기존의 코드를 보여주면서 문제점을 찾고 그 문제를 해결하라고 요청받은 적이 없다는 사실이 안타깝다. 왜냐하면 엔지니어로서 대부분의 시간은 기존의 코드베이스를 유지보수하는데 쓰기 때문이다. 완전히 새로운 것을 구축할 일은 별로 없다.
나보다 똑똑한 사람들과 일하라
나는 프리랜서로 일하고 싶어하는(혹은 개인 프로젝트로 일하고 싶어하는) 많은 프론트엔드 개발자들이 프리랜서로 일하고 싶어하는 백엔드 개발자보다 많다는 사실에 놀랐다. 아마도 프론트엔드 개발자가 독학으로 된 사람이 많고, 백엔드 개발자는 정규 교육을 받은 사람이 많기 때문일 것이다.
독학과 혼자 일하는 것은 대체로 자신보다 똑똑한 사람들로부터 배울 수 없다는 문제가 있다. 의견을 제시해 줄 사람이나 코드를 리뷰해 줄 사람이 없다는 것이다.
나는 최소한 커리어의 처음은 팀의 일원으로서 시작하기를 강력하게 추천한다. 구체적으로 자신보다 똑똑하고 경험 많은 사람들이 있는 팀이 좋다.
그리고 만약 언젠가 개인 프로젝트 하던 것을 관두게 된다면, 그 프로젝트를 오픈 소스로 만드는 것이 좋다. 오픈 소스 프로젝트에 활동적으로 공헌하는 것은 팀에서 일하는 것 이상으로 많은 이점을 준다.
있는 걸 다시 만들어라
있는 걸 다시 만드는 것은 사업관점에서 보면 나쁘지만, 배움의 관점으로 보면 좋은 방법이다. 아마도 종종 자동완성 기능 혹은 이벤트 위임(event delegation)을 구현한 npm 라이브러리를 쓰고 싶은 유혹이 있을 것이다. 하지만 그걸 스스로 만들면 얼마나 더 많은 것을 배울 수 있을지 상상해 봐라.
나는 이 글을 읽고 있는 당신이 이 의견에 강력히 반대할 거라고 확신한다. 오해하지마라. 써드 파티 코드를 절대 사용하지 말라는 의미가 아니다. 많은 테스트 케이스와 버그 리포팅으로 몇 년간 테스트가 잘 된 라이브러리를 사용하면 거의 항상 일을 쉽게 할 수 있다.
하지만 이 글은 그냥 좋은 수준이 아니라 탁월한 수준으로 나아가는 것에 대해서 말하고 있다. 내가 탁월하다고 여기는 사람들의 대부분은 내가 항상 쓰는 인기 많은 라이브러리를 만든 사람이거나 혹은 그 라이브러리의 메인테이너이다.
아마도 당신은 지금까지 자바스크립트 라이브러리를 만들지 않았어도 성공적인 경력을 얻었을 것이다. 하지만 물론 하드웨어(저레벨)에 가까운 일도 전혀 하지 않았을 것이다.
개발자들은 “다음에 뭘 만들어 볼까?” 같은 생각을 종종한다. 이런 상황이 되었을 때, 새로운 툴을 배우거나 새로운 어플리케이션을 만드는 것보다는 가장 좋아하는 자바스크립트 라이브러리 혹은 CSS 프레임워크를 재작성해보는 것이 어떨까? 이렇게 하면 구현이 막혔을 때에도 이미 존재하는 라이브러리의 소스 코드가 해답이 되기 때문에 좋다.
배운 것을 기록하라
마지막이지만 정말 중요한 건, 배운 것에 대해 기록할 필요가 있다는 것이다. 배운 걸 기록해야 하는 데에는 정말 많은 이유들이 있지만, 아마도 해당 주제에 대해 더 많이 이해할 수밖에 없다는 것이 가장 중요한 이유일 것이다. 만약 무언가 어떻게 동작하는지 설명하지 못한다면, 실제로 그걸 스스로 이해하지 못한 것이다. 그리고 종종 기록하기 전까지는 이해하지 못했다는 사실을 깨닫지도 못한다.
경험에 의하면 기록하고, 이야기하고, 데모를 만드는 것은 어떤 주제에 대해 빠져들게 하고 그걸 완전히 이해하는데 있어서 최고의 방법이다. 비록 쓴 글을 아무도 읽지 않더라도, 기록하는 과정 자체가 기록의 가치 그 이상이다.
