[서평] 나는 네이버 프론트엔드 개발자입니다 책 리뷰

안녕하세요 저는 어느덧 개발자로 4년차 현재는 프리랜서로 살고 있는 동구 입니다.  

 

여러분들은 개발자로 일하면서  서비스를 혼자 만들어볼수있으면 좋겠다  라는 생각이 문득문득 드시지 않으신가요 ? 

 

백엔드로써 저의 커리어 대부분을 보내다 보니  항상 제 발목을 잡는건 프론트엔드였습니다 !!

 

후... 왜 내 주변엔 백엔드 밖에 없는걸까 ㅋㅋㅋㅋ 하지만 탓만 하고 가만히 있을순없어서 제가 그냥 제가 배워서 하기로했습니다 ㅋㅋ

 

자고로 개발자는 문제를 발견했으니 문제를 해결해야죠 ㅎ

 

 

 

 

항상 새로움을 동반한 성장은 늘 재미있잖아요 ! 제 선택을 한번 믿어보기로 했습니다. 

 

 

 

 

주저리주저리 떠들었지만, 제가 이번에 읽은 책인 "나는 네이버 프런트엔드 개발자입니다" 를
리뷰 해보겠습니다. 

이 책에 대해서 간략하게 소개를 드리자면, 

 

네이버에서 일하는 프론트엔드 개발자들이 자신들의 이야기를  풀어서 쓴 책들입니다.

 

저와 같은 프론트엔드로 커리어를 전환하고싶어하거나 프론트엔드 주니어로써 시작하는 사람들에게  프론트엔드 개발자들은 어떻게 살고있을까 궁금할때 간접적으로 알아볼수있는 좋은 책이라고 생각해서 구매해서 한번 읽어봤습니다.

 

 

결론은 완전 추천 합니다 !! 

 

 

 

 

이 책을 읽으면서 가장 공감이 갔던 몇 부분 같이 나눠 보도록 할게요!

 

1. 개발자는 항상 '왜' 가 중요해 !  ( Why? )

요즘 개발을 배우려는 사람들도 많고 기술의 접근성도 쉬워지다보니 너도나도 개발자나 되어볼까 하는 시대가 되었습니다. 

 

개발자에 대한 접근성이 높아진거에대해서는 긍정적이지만,

 

개발자가 왜 되야할까에 대한 고민을 하기도전에 개발자가 되는 방법을 먼저 찾다보니 실제로 일하고나서 자신이랑 안맞는 사람도 많고 지속하는게 힘드신분들도 많은것 같습니다. 

 

개발자가 된다는 것은 많은 것에 대해 '왜?' 를 생각해야 한다는 뜻이다. 

대단한 이유를, 그럴싸한 문장을 찾으라는 뜻이 아닙니다.

다만 언젠가 미래의 내가 '이걸 왜 하고 있지?' 라는 순간이 올 때 이 맛에 내가 프런트 엔드 개발을 하지 라는 위안받을 수 있는 답을 생각해놓기를 권하는 것입니다. 

 

제 이야기를 들려드릴게요.  한 스타트업에서 근무했을때 제 사수였던 CTO 분의 의사결정하는 방법이 굉장히 흥미로웠습니다.

어떤 기능을 개발하기 위해서 기술을 선택할때 항상 이유와 근거가 필요했습니다. 그리고 모든 개발자에게 왜를 요구했죠.

 

주니어 개발자들은 항상 신기술을 써보고 싶어하고 경험하면서 성장하고 싶어합니다.

 

저도 마찬가지였기 때문에 개발자로써 제 역량을 키우고 싶은 마음에 새로운 신기술 이런거 저런거 써보고싶었지만 항상 왜 그 기술을 써야하는지 이유를 설명하고 납득 시켰어야 했습니다. 

 

더 중요한건 어떻게 개발하는지보다는 왜 개발하는지가 중요했었습니다. 그 왜는 바로 해당 비지니스의 고객의 문제를 해결하는 것이였죠. 

 

이때 저한테 생각이 든건 '내가 왜 백엔드 개발자로 일하고 있을까?'  뒤돌아 봤을때 백엔드 개발자도 하나의 기술의 선택에 불과 한데말이 에요.

 

 

저에게 왜 개발을 하는지 물어봤습니다.

사람들에게 도움이 되고 재미난 서비스를 만들어주고 싶었습니다. 

어느새 방법에 갇혀서 '왜?'를 생각해보지 않았죠. 이게 바로 제가 커리어를 바꿔서 프론트개발을 공부하고 더 나아가고 싶은 이유입니다.

 

우리는 컴퓨터랑 일합니다. 하지만 궁극적으로는 사람의 문제를 해결합니다. 컴퓨터는 단지 해결의 도구일 뿐이죠.

 

여러분들도 기술을 선택할때 왜에 대한 고민을 해보시길 그리고 꼭 해야된다는걸 잊지 마세요!  그리고 그 물음에 대한 답이 지쳤을때나 힘들때 계속 지속가능하게 도와줄거에요. 

 

 

 

2. 프론트엔드의 주무기는 커뮤니케이션 스킬 ?

 

기획요구사항, 디자인 시안에서 설계 의도를 파악할 수 있어야 유연한 개발이 가능하다.
일반적으로 컴포넌트 단위 개발 프레임워크와 상태 관리 라이브러리를 조합해 사용한다. 페이지에서 고정된 부분, 변경될 부분, 재사용되는 부분을 먼저 나눈 후 단위 요소를 채워나가는 방식이다. 이런 컴포넌트 단위의 설계는 기획 및 디자인 단계부터 함께 고려해야 수월하게 진행 할 수 있다. 

전반적인 기획 및 디자인은 당연히 각 영역 전문가가 할 일이다. 하지만 한 사람의 사용자로서 생각하고 구현하기 전 설계를 이해하고 가능한 기술적 대안을 제시할 수 있을 때 더 나은 제품을 만들 수 있다.

 

기획자 및 디자이너와 서로 사고방식이 다르기 때문에 오해와 갈등은 필연적으로 발생한다. 수없이 많은 대화를 하며 상대의 생각을 듣고 이해하려고 노력하는 수밖에 없다.

 

프런트엔드 개발은 사람이 직접 보고 조작하고 경험하는 영역을 다룬다. 기술과 사람의 경계에서 상상을 현실에 만들어 내는 사람들이다. 

눈에 보이지 않는 기술적인 아름다움을 추구하는 것도 필요하지만 눈에 보이는 부분을 아름답게 만들어내는 것이 먼저 요구된다.

 

타 직군 동료에게 기술 용어와 구조를 설명하는 것보다 '가이드에 따라 만들면 대략 이런 모양이 될 겁니다' 처럼 실제 눈으로 볼 수 있는 예제나 프로토타입을 보여주는 것이 훨씬 이해가 빠르다. 

 

프런트엔드 개발자는 자신이 만들어낸 결과물을 사용자 시각에서 사용자의 언어로 풀어서 설명할 수 있어야 한다. 첫번째 대상이 바로 옆에 있는 당신의 동료들이다. 

 

 

 

 

3.  오류에 대한 시각

 

오류를 무조건 나쁘다고 생각하는 것이 아니라 언제든 발생할 수 있는 사건이며 발생했다는 것 자체보다는 왜 발생했고 동일한 오류가 반복적으로 발생하지 않으려면 어떤 부분을 개선해야 하는지 배울 수 있는 존재로 인식했다.
이와 같은 조직 문화 덕분에 어떻게 하면 오류를 빠르게 발견하고 잘 처리할 수 있는지 많은 논의가 이뤄지고 있었다. 또한 다양한 의견을 바탕으로 오류를 처리하는 과정이 다음과 같이 잘 정리돼 있었다.


1. 오류 발생을 감지한 시점에 최대한 빠르게 동료와 공유하기
2. 오류가 더 이상 발생하지 않는 방향으로 최대한 빠르게 수정하기
3. 오류 원인 파악 및 수정하기
4. 오류 내용 공유 및 재발 방지 대책 수립 또는 논의 하기

 

프리랜서로 일하면서 다양한 조직문화를 경험해보다보니 어떤 조직에서는 오류가 발생하면 오류원인파악이나 해결보다는 담당자에게 책임전가하기 바쁜 회사도 있었고, 정말 위에 처럼 오류에대한 재발방지를 위해 노력하는 회사도 있었다. 

 

내가 생각하면서 무엇보다 중요한건 4번째 오류 내용 공유 및 논의 하기였다. 백엔드 개발자로 일할때 언제 한번 서버에 문제가 생겨서 서비스가 중단된 사건이 있었는데 오류 원인을 파악해보니 DB 서버의 용량 부족으로 DB가 종료되면서 일어난 문제였다. 해당 서버의 크기를 빠르게 올리고 DB를 재시동해서 급하게 불을 껐지만, 거기서 내 문제 해결은 끝났다고 생각했다. 

 

하지만, 한달을 못가서 똑같은 일이 발생했고 공교롭게도 내 휴가때 일어났다. 동료들은 내가 그 문제를 해결했던걸 기억하고 있지만 내가 공유를 못했기때문에 빠른 대처 및 원인 파악부터 다시 시작해야했던 것이다. 

 

그 이후로는 해당 문제에대해서 미리 알수있는 알림을 만들기도하고 좀 더 견고한 서비스를 만들기위해 동료들이랑 공유하고 논의를 하면서 좀 더 나은 개발문화를 만들어 나갔다.  

 

이때 배운건 우리는 개발자로 일할때 팀으로 일한다. 동료의 성장이 곧 내 성장이다. 많이 나누고 같이 성장해야겠다는 생각을 했다.

 

 

 

 

 

마지막으로 프런트엔드에 관심있고 주니어 개발자들에게 같이 나누고 싶은 문장이 있다.  모두 화이팅!

 

새로운것을 익힐때 필요성을 느껴서 학습하는 것과 아닌 것은 큰 차이가 있다. 논리적 사고를 끊임없이 연습하는 개발자는 본인이 납득하지 않으면 동기부여가 확 떨어진다. 학습도 마찬가지다.