Naver Tech Concert 리뷰

2019년 4월 11일, 네이버의 사옥 그린팩토리에서 네이버 테크 콘서트가 열렸다. 주제는 프론트 엔드 개발 전반적인 기술과 경험, 그리고 개발 문화에 대한 공유였다. 일단은 컨퍼런스의 대상은 대학생 대상으로 주최된 행사였으나, 막상 가서 보니 실무자들 참여율이 높은 편이었다. 아무래도 대학생을 대상으로 하는 컨퍼런스이기 때문에 실무자들에게는 이미 익숙해져 있는 이야기도 있었지만, 개인적으로 컨퍼런스의 전체적인 내용에 아주 만족스러웠다. 그 중 인상 깊었던 내용들에 대한 리뷰를 남기고자 한다.

플랫폼 UI 개발 전략

첫번째는 이주용님의 플랫폼 UI 개발 전략의 모든 것 이라는 주제의 세션이었다.

내용은 스마트에디터의 UI를 개발하면서 생겼던 이슈 및 해결 과정에 대한 것들을 풀어나가는 시간이었다. 모든 개발의 시작은 좋은 설계에서 시작한다고 생각한다. 개인적으로 생각했을 때, 중요한 것은 새로운 비지니스가 추가될 때, 그러한 요구 사항을 수용할 수 있느냐와 두번째는 유지 운영의 용이성이라고 생각한다.

스마트 에디터의 설계를 하면서 가장 중요하게 생각했던 것의 첫번째는 UI 컴포넌트의 공통화는 디자인 중심이 아닌 기능 중심으로 설계를 했다는 점이다. 디자인은 템플릿 요소의 관점에서 접근하며, 실제 UI 컴포넌트를 공통화를 고민할 때는 기능 중심의 분석을 거쳐 설계를 했다고 한다.

두번째는 조건 및 상태에 따라 다른 스타일 적용했다는 점이다. 우리가 생각하는 CSS는 Javascript와 같이 동적인 언어가 아닌 정적인 언어이다. 하지만 비지니스의 니즈에 따라 조건이나 상태에 따라 UI의 화면이 수도없이 바뀐다. 마치 아래와 같은 스타일을 작성하는 이유이다.

.button {
  // ...
  .has-text {
    // ...
  }
  .has-icon {
    // ...
  }
}

이러한 상황을 고려하여 CSS는 정적인 언어이지만 설계는 동적으로 이뤄져야 한다는 것이다.

이와 동시에 중요한 것은 모듈화와 공통 요서 분리 작업이다. 위와 같이 상태나 조건에 따라 컴포넌트의 스타일이 동적으로 변경될 수 있으려면 제일 먼저 비지니스의 니즈를 분석한 후, 공통 분모를 도출 해야한다. 무엇보다 이러한 공통점을 찾을 때는 단순하게 디자인만 고려하는 것이 아니라 꼭 기능도 함께 고려를 해야 한다. 디자인이 비슷하다고 해도 기능이 다른 경우가 존재하기 때문이다.

이러한 고민들을 해결해나가는 과정에서 스마트 에디터의 팀은 개발 방법론과 CSS Preprocessor도입했다고 한다. 개발 방법론은 BEM, SMASS, OOCSS 등과 너무도 유명한 3가지 방법이 있다. 이 중에서는 대표적으로 BEM 방식이 가장 인기 있는 방법이지만, OOCSS를 선택했다고 한다. 혹시나 스마트 에디터 팀에서 OOCSS를 선택했다고 꼭 OOCSS 방법만 선택할 필요는 없다. 위의 3가지 방법은 각각의 장단점이 있기 때문에 꼭 하나의 방법을 고수하는 것보다는 상황에 따라 선택하면 될 것 같다.

첫번째 세션에서 제일 인상 깊었던 말은 플랫폼은 만능이 아니다라는 말이었다. 내가 만든 코드가 모든 요구사항을 다 소화할 수 없으며, 플랫폼은 지속적으로 발전하기 때문에 코드 역시 변화해야 한다. 소프트웨어 장인 이라는 책에서는 개발자는 건축가와 같이 설계하고 끝나버리는 직업이 아니라, 정원사와 같이 꾸준히 관리를 해줘야하는 직업이다 라고 한다. 그렇기 때문에 개발자로서 살아가는 우리들이 꾸준히 리펙토링과 클린코드에 관심을 갖는 게 아닐까?

회사에서 성장하기

두번째로 인상 깊었던 내용은 한재엽님의 주니어 개발자의 성장에 대한 뻔하지만 뻔하지않은 이야기 였다.

개발자라면 한번쯤 스스로의 위치와 앞으로 내가 얼마나 나아갈 수 있을지에 대한 고민을 한번쯤을 해보았을 것이다. 이러한 고민을 재엽님의 경험기에 빗대자면, 많은 시간을 투자하여 다음의 것들을 공부하면 된다.

1. 출근 전후 그리고 주말 내내 시간을 투자해서 공부를 한다.
2. 사이드 프로젝트를 진행한다.
3. 개발 관련 뉴스레터를 통해 꾸준하게 개발에 관심을 놓지 않는다.
4. 개발 관련 서적을 독파하여 기본기에 충실한 공부를 한다.
5. 블로그를 운영한다.
6. 알고리즘을 하루에 한 문제씩 풀어 논리적인 사고 방식에 대한 감을 잃지 않는다.

만약 이런 것들을 하루에 한다고 하면 우리는 누구나 노력형 천재 개발자가 될 수 있다. 하지만 안타깝게도 우리의 인생은 개발자로서의 성장만 꿈꾸기에는 너무나 많은 이벤트들이 있다. 가족 혹은 애인과 시간도 보내야 하고, 가끔 번아웃된 나 자신을 위해 스스로르 보듬어줘야하기도 하며, 회사를 다닌다면 야근과 같이 불가피한 상황에 놓일 수도 있을 것이다. 그렇다면 빠른 성장을 포기해야 할까?

재엽님의 주제가 제일 마음에 와닿는 것은 이러한 현실적, 물리적 제약을 해결해나간 방법에 있다. 바로 회사에서 성장하기이다. 언젠가 누군가에게 했던 말 중 제일 와닿는 말이 하나가 있다. 개발자의 실력이 궁금하다면 그 사람의 비지니스의 코드를 보면 알 수 있다. 회사는 나와 함께 동반 성장을 해나가야할 파트너이다. 개인은 정체되어 있지만 회사만 성장을 하거나 혹은 개인은 성장을 하지만 회사가 정체되어 있는 불균형은 일하고 있는 환경이 좋지 않은 상황일 가능성이 크다. 그러한 의미에서 우리는 회사라는 환경을 잘 이용하여 동반 성장을 꿈꿔야 한다.

물론 사이드 프로젝트를 통해 회사에서 채우지 못한 개발적 욕구를 채울 수도 있다. 하지만 사이드 프로젝트를 진행하다보면 모든 욕구를 다 채울 수 없다는 것을 느낄 수 있다.

재엽님이 말씀하신 간헐적 버그에 대한 무시, 버그 제보에 대한 무시, 디바이스 이슈를 제외하고도 가장 큰 것은 유저풀이다. 하루에도 수십개의 사이드 프로젝트가 탄생하며 사라진다. 정말 성공한 사이드 프로젝트를 제외하고는 유저풀이 1000명 넘는 플랫폼이 있을까? 물론 적은 수더라도 내가 사이드 프로젝트로 만든 플랫폼을 이용해준다는 것은 정말 고마운 일이지만 개발적 욕구를 모두 채우기엔 유저풀이 적은 것은 사실이다. 많은 유저풀이 있다는 것은 내가 만든 플랫폼에 대한 자부심을 갖기에도 충분하지만, 더 많은 사용자의 데이터를 통해 사용자들의 플랫폼에 대한 니즈가 점점 더 커져 플랫폼을 발전시키는 계기가 되기도 한다. 그러한 점에서 개인적으로는 유저풀 역시 꾸준한 플랫폼의 발전에 없어서는 안되는 요소라고 생각한다. 사이드 프로젝트를 통한 플랫폼에서는 이러한 것을 채울 수 없지만, 회사에서 만드는 플랫폼의 경우에는 상황이 다르다.

일단은 회사의 플랫폼의 경우, 작은 스타트업의 경우 회사의 사활이 걸려 있을 수도 있고, 큰 회사더라도 플랫폼 사업 하나에 걸려있는 비용이 천문학적인 비용인 경우가 많다. 그런 만큼 회사에서는 더 많은 관심을 가질 수 밖에 없으며, 간헐적 버그, 디바이스 이슈 등의 사소한 것 하나하나도 전문적인 QA 검증 과정을 거쳐 완벽하게 만들고자 노력한다. 이러한 환경은 개발자가 성장을 하기에 좋은 환경이라고 생각한다. 우리에게 주어진 환경 안에서 이러한 환경을 잘 이용하여 설장하는 계기가 되었으면 한다.

똑똑한 질문하기

일을 하다보면 스스로 혹은 동료에게 수없이 많은 질문을 하게 된다. 하다못해, 스택오버플로우만 가도 수없이 많은 개발자들의 질문과 답변이 존재한다. 커뮤니티의 수많은 질문과 답변을 통해 우리는 스스로 성장하기도 하지만 때때로 성의없는 질문들도 있다. 질문의 내용만 살펴봐도 질문을 하기에 충분한 고민을 하지 않았다는 것을 유추할 수 있다. 스스로 해결하려 하는 것이 아니라 질문을 남의 시간을 통해 해결하려고 하는 아주 괘씸한 질문들이다.

반대로 회사에서 동료에게 이러한 질문을 던지게 된다면, 나의 시간 뿐만 아니라 동료의 시간까지도 빼앗는 상황이 되기도 한다. 그리고 이렇게 몇번 성의 없는 질문을 하다보면 동료에게서 미움을 살수도 있다. 그렇다면 성의 없는 질문은 무엇일까?

일단 먼저 질문을 하기 전에 충분하게 검색을 해보자. 우리에게는 구글이라는 훌륭한 플랫폼과 스택오버플로우라는 훌륭한 선배 개발자들이 많다. 뿐만 아니라 체계가 잡혀있는 회사 내에는 트러블 슈팅을 다룬 문서가 존재하기도 하다. 대부분의 질문들은 다 그안에서 찾을 수 있다. 하지만 가끔 어떠한 키워드로 찾아야 할지 조차 감을 못 잡을 때가 있다. 그러한 경우에는 동료에게 어떠한 질문을 해야 하는지, 사전 준비를 거쳐야 한다.

일단 첫번째로 발생 상황을 정리를 한다. 예를 들어 ‘하위 IE 브라우저에서 특정 컴포넌트에서 문제가 발생한다.’ 와 같을 것이다. 물론 조금 더 상세하면 좋다. ‘하위 IE 브라우저 중 IE8에서만 유저의 데이터를 노출시켜주는 UserInformation 컴포넌트에서 x라는 문구와 함께 랜더되지 않는다’ 와 같을 것이다. 다음으로 그러한 문제를 해결하기 위해 어떠한 시도를 했는지도 함께 전달을 해주면 좋다. 상대방 역시 내가 했던 삽질을 그대로 반복해서 시간을 낭비할 수 있기 때문이다. 물론 동료 역시 나의 질문에 답변을 못할 수도 있다. 그런 경우는 차라리 덕 디버깅과 같이 내가 생각하고 있는 바를 논리적으로 토론해보는 것도 좋다. 이러한 방식 역시 상대방과 이야기를 하다보면 스스로 논리에 구멍이 있는 것을 찾기도 혹은 동료가 찾아주기도 한다. 고로 현명한 질문을 통해 서로 발전하는 계기가 되어야 할 것이다.

성능 최적화

최근에 회사에서 오픈한 마이티몬의 프로젝트가 안정화 단계에 들어선 후, 플랫폼의 성능에 대한 고민을 하고 있었다. TTI(Time to interaction) 수치 라던지 초기 화면이 그려지는 로딩의 속도 혹은 리소스 절감 등이 포함이 될 것이다. 그러던 중 손찬욱님의 강연이 그러한 고민을 해결할 수 있는 하나의 빛과 같았다.

일단 클라이언트에서 성능을 개선한다고 하면 우리가 흔히 생각하는 것들이 있다. 일단 제일 간단한 것은 css는 head 안에, js는 body태그가 끝나는 바로 상단에 넣어 준다던지, 혹은 레이지 로딩 적용, 요청수 줄이기 등이 있을 것이다. 하지만 제일 중요한 것은 현재의 상태를 분석하는 것이다. 현재의 상태를 알아야 분석을 통해 어떠한 부분을 개선할 수 있는지, 어떻게 개선하면 좋을지 등에 대한 해답을 찾을 수 있기 때문이다. 그러한 성능 분석은 아래와 같이 Chrome devtools의 Network 안에 있는 Waterfall 그래프를 통해 확인할 수 있다.

이렇게 나온 그래프를 높이는 낮게, 오른쪽에 가깝게, 그래프 하나당 길이는 짧게 줄이는 것이 성능을 최적화할 수 있는 방법이다. 조금 더 풀어서 설명을 하면, 일단 그래프의 높이가 낮으려면 요청하는 리소스의 갯수가 적어야 한다. 그 말인즉, 모든 리소스를 청킹(Chunking)한다고 성능이 좋아진다는 것은 아니라는 말이다. 두번째로 오른쪽에 가깝다는 것은 리소스 간의 다운로드 수를 줄인다는 것이다. 이러한 두번째의 경우에는 브라우저의 랜더링에 대한 배경이 있어야 한다. 이 부분에 대해서는 추후 다른 포스팅에서 깊이 다루도록 하겠다. 마지막으로 세번째는 사실 클라이언트의 이슈보다는 서버쪽의 이슈에 가까운 경우가 많다. 그래프가 길다는 것은 서버에서 비지니스 로직을 처리하는데 시간이 오래 걸리기 때문이다.