개발자의 자세

문제를 해결하는데 그치지말고 어떻게 동작하는 지 파악하라

너무 많은 사람들이 무언가 동작하게 만들기 위해 CSS나 JavaScript를 어설프게(tinker) 손댄다. 나는 항상 코드 리뷰를 할 때마다 이런일이 일어나는 것을 종종 봐왔다.

나는 종종 그들에게 “왜 여기에 float: left를 추가한 겁니까?” 혹은 “여기에 overflow: hidden은 정말로 필요한 건가요?”라고 묻는다. 그럼 그들은 대부분 “몰라요. 하지만 제가 그걸 지우면 제대로 동작하지 않습니다.”라고 대답한다.

JavaScript에서도 마찬가지였다. setTimeout을 그저 경쟁 상태(race condition)를 막기 위해 사용하는 사람도 있었고, 다른 이벤트 핸들러에 어떤 영향을 미칠지에 대한 고려도 없이 event propagation을 멈추는 사람도 있었다.

이것이 당장 동작하는 구현을 필요로 할 때 일어나는 일인 것을 알고있다. 하지만 문제의 원인을 이해하려하지 않는다면 항상 같은 문제를 마주하게 될 것이다.

당신의 해결법이 어떻게 동작하는 지를 이해하는 것은 당장은 시간이 많이 들 수도 있지만 결과적으로 시간을 아끼게 될 것이다. 작업하는 시스템에 대해 완벽히 이해하게 되면 앞으로 불필요한 추측이나 체크하는 작업이 적어질 것이기 때문이다.

명세(Spec)를 읽어라

브라우저에는 항상 버그가 존재하지만, 두 개의 브라우저가 같은 코드를 다르게 렌더링 할 때 사람들은 종종 스스로 점검하기 보다는 소위 “좋은” 브라우저가 옳고, “나쁜” 브라우저가 틀리다고 생각한다. 하지만 항상 그런 것은 아니다. 그리고 그 생각이 틀렸을 때, 선택한 해결방법이 무엇이든 미래에는 거의 확실히 동작하지 않는다.

flex 요소의 디폴트 최소 크기가 이것의 적절한 예이다. 명세에 따르면, flex 요소의 min-width 와 min-height 초기 값은 0이 아니라 auto이다. 이것은 기본적으로 flex 요소가 요소 내부의 콘텐츠보다 작을 수 없다는 것을 의미한다. 지난 8개월 간, 파이어폭스가 이것을 맞게 구현한 유일한 브라우저였다.

만약 크로스 브라우저 호환성 문제에 직면해서 웹사이트가 크롬, IE, 오페라, 사파리에서는 동일하게 렌더링되지만 파이어폭스에서만 다르게 보인다면, 아마 파이어폭스가 잘못되었다고 생각할 것이다. 사실 나는 이런 경우를 많이 목격했다. 나의 Flexbugs 프로젝트에 보고된 많은 이슈들과 제안된 임시 방편들(Workaround)이 실제로 이 호환성에 기인한 것이었다. 제시된 임시 방편대로 구현했다면 2주 전에 크롬 44 버전이 나오면서 동작하지 않게 되었을 것이다. 그들은 명세를 따른 이 임시방편 대신에, 잘 모르는 채로 좋은 해결법을 비난했다.

2개 이상의 브라우저가 같은 코드를 다르게 렌더링 할 떄, 어떤 브라우저가 코드에 맞는 동작을 하는지 시간을 내서 파악해야 한다. 그럼 그 해결방법은 결과적으로 더 미래 친화적인 해결방법이 될 것이다.

덧붙여, 소위 “탁월한” 프론트엔드 엔지니어들은 대부분 변화의 최전선에 있는 사람들이다. 새로운 기술을 채택하는 걸 넘어 그 기술의 주류이거나 심지어는 해당 기술의 발전에 기여한다. 명세를 보면서 스스로 능력을 기르고 브라우저에서 실행해보기 전에 기술이 어떻게 동작할 수 있는지 생각하면 명세에 대해 이야기하고 명세의 개발에 영향을 끼칠 수 있는 그룹의 구성원이 될 수 있을 것이다.

있는 걸 다시 만들어라

있는 걸 다시 만드는 것은 사업관점에서 보면 나쁘지만, 배움의 관점으로 보면 좋은 방법이다. 아마도 종종 자동완성 기능 혹은 이벤트 위임(event delegation)을 구현한 npm 라이브러리를 쓰고 싶은 유혹이 있을 것이다. 하지만 그걸 스스로 만들면 얼마나 더 많은 것을 배울 수 있을지 상상해 봐라.

나는 이 글을 읽고 있는 당신이 이 의견에 강력히 반대할 거라고 확신한다. 오해하지마라. 써드 파티 코드를 절대 사용하지 말라는 의미가 아니다. 많은 테스트 케이스와 버그 리포팅으로 몇 년간 테스트가 잘 된 라이브러리를 사용하면 거의 항상 일을 쉽게 할 수 있다.

하지만 이 글은 그냥 좋은 수준이 아니라 탁월한 수준으로 나아가는 것에 대해서 말하고 있다. 내가 탁월하다고 여기는 사람들의 대부분은 내가 항상 쓰는 인기 많은 라이브러리를 만든 사람이거나 혹은 그 라이브러리의 메인테이너이다.

아마도 당신은 지금까지 자바스크립트 라이브러리를 만들지 않았어도 성공적인 경력을 얻었을 것이다. 하지만 물론 하드웨어(저레벨)에 가까운 일도 전혀 하지 않았을 것이다.

개발자들은 “다음에 뭘 만들어 볼까?” 같은 생각을 종종한다. 이런 상황이 되었을 때, 새로운 툴을 배우거나 새로운 어플리케이션을 만드는 것보다는 가장 좋아하는 자바스크립트 라이브러리 혹은 CSS 프레임워크를 재작성해보는 것이 어떨까? 이렇게 하면 구현이 막혔을 때에도 이미 존재하는 라이브러리의 소스 코드가 해답이 되기 때문에 좋다.