인프런 심야 FE 네트워킹 후기
본 포스트는 인프런 심야 FE 네트워킹에 대한 후기이다. 주로 필자가 받았던 질문과 이에 대한 답변을 추려서 작성할 것이다.
진행 과정
오프라인 행사였고, 네트워킹 전에 인프런 CTO 이동욱님이 행사의 포문을 열고, 인프런의 FE 개발자인 빠삐코님이 어떻게 랠릿을 만들었을까?에 대한 내용을 발표하고, 카카오 엔터테인먼트의 FE 리드 개발자인 김성호님이 뽑히는 주니어의 조건 이라는 주제로 발표를 해주셨다.
세션에 대한 내용은 상세하게 작성해주신 분들이 많기 때문에 여기서는 크게 다루진 않을 것이다.
어떻게 랠릿을 만들었을까?
주로 랠릿을 만들면서 어려웠던 부분들에 대해 발표해주셨다. 조금 아쉬운 점을 이야기해보자면, 의사결정 과정에서 왜? 에 대한 부분을 저 자세히 다뤄줬으면 좋았을 것 같다. 랠릿 서비스에 대한 내용은 인프런 기술블로그에 자세히 공유될 예정이라고 한다.
- 어떤 기술 스택을 사용했는지
- 프로젝트를 진행하면서 어려웠던 점들
- 그리고 이걸 어떤 방식으로 해결했는지
- 그래서 지금은 괜찮은지
- 앞으로는 어떤 방식으로 진행할 것인지
아마 이런 내용들 위주일 것 같다.
되도록 빨리 볼 수 있었으면 좋겠다. 보고 있나요 빠삐고님!?
뽑히는 주니어의 조건
필자도 리더의 역할을 수행하며 채용을 경험해본 입장에서 나만의 생각을 곁들여 이야기해볼 것이다.
(1) 개발자의 능력치
김성호님은 개발자의 능력치를 게임 캐릭터의 스탯으로 비유했다.
스탯창이 전부 기억나는건 아닌데..
- 리더쉽
- 커뮤니케이션
- 엔지니어링(개발)
일단 이렇게 세 개가 있었고 한 가지는 기억나질 않는다.
리더쉽과 대비되는 능력으로는 팔로우쉽이 있다고 생각한다.
내가 생각하는 팔로우쉽은
- 우리 조직과 리더가 생각하는 것, 의도하는 것들을 잘 인지하는지
- 인지하고 있다면, 이에 대해 적절한 방향으로 행동하고 있는지
이렇게 두 가지 이다.
처음부터 리드하는 사람이 떡밥을 잘 던져주면 좋겠지만(?) 누군가는 리딩하는 능력치가 낮을 수도 있고, 또 리더가 잘 신경쓰지 못하는 부분도 있다.
그렇기 때문에 내가 리더의 입장에서 내 역할을 잘 인지하고 잘 따라줄 수 있는 능력도 꼭 필요하다고 생각한다.
필자는 페이스북을 많이 한다. 페이스북의 콘텐츠를 소비하는 입장이랄까? 제일 유익하게 느끼는 것은 신수정님이 작성해주신 글들이다. 주옥같은 글이 무척 많이 있다. 링크드인에도 자주 올려주신다.
각설하고, 무척 인상 깊었던 내용 중 하나를 간략하게 소개해보자면, 스스로 뛰어난 리더가 되기 위해선 무능력한 리더 밑에서도 일을 해봐야 한다 는 내용이다.
커뮤니케이션 능력이 안 좋을 수도 있고, 개발자라면 개발 능력 자체가 미스일 수도 있을 것이다. 중요한 것은 이런 상황을 극복하고 성과를 내는 것이다. 이를 극복하는 능력치 중 하나가 팔로우쉽이라고 생각한다.
(2) 이력서
이력서 부분을 무척 길게 이야기 해주셨는데, 기억나는건 다음과 같다.
- 단순 기술스택 나열을 최악이다.
- 해당 기술로 어떤 문제를 해결했는지 작성하면 좋다.
- 길이도 중요하다.
- 해당 회사에서 권장하는 양식을 사용하는게 좋다.
- 가끔 첨부파일로만 이력서를 제출하는 사람이 있는데..
- 이럴 때 무심코 넘어갈 수 있다.
- 스펙은 중요하지 않다.
- 프로젝트에 대한 성과를 이력서에 드러내야한다.
- 보통 신입 개발자는 무엇이 성과인지 모르는 경우가 많다.
- 객관적인 지표가 필요하다.
- 이건 필자의 생각인데,
사용성이 좋은 서비스를 만들었다고 한다면, 어떻게 사용성이 좋다는 것을 증명할 것인가? 이에 대한 고민이 필요하다.
여기에 필자의 생각을 곁들이자면,
1) 문제 해결 과정에 대한 내용이 드러나야 한다.
현재 시장에 있는 FE 개발자의 경우 전공자를 찾기가 무척 드물다. 필자도 1년 이라는 시간 동안 1000개 가까이 되는 이력서를 봤는데 그 중에 전공자를 찾기가 무척 드물었다.
일단 전공자를 찾는 이유는 컴퓨터 공학적인 사고를 가지고 있을 확률이 높기 때문이다. 단순히 전공과목(운영체제, 컴퓨터구조, 자료구조, 알고리즘, 객체지향 프로그래밍 등)을 공부했기 때문이 아니라 전공과목을 학습하는 과정에서 왜 이런 이론들이 등장했는지, 이런 해결 방법을 사용했는지 배우기 때문이다. 즉, 비전공자보다 문제 해결 과정에 대해 시간 투자를 했다고 생각하기 때문이다.
중요한 포인트를 다시 짚어보자면 필자는 문제 해결을 했다 가 아니라 문제 해결을 위해 어떤 방식으로 접근 했는지를 더 중요하게 생각한다. 이럴 경우, 답을 모르거나 답이 없는 상황에서도 크게 당황하지 않고 침착하게 문제 해결을 위한 사고를 할 수 있기 때문이다.
그래서 굳이 전공자가 아니더라도, 문제 해결을 위해 접근하는 과정에 대한 연습이 잘 되어 있거나 그게 자연스러운 사람이라면 어떤 문제가 발생하더라도 이를 해결할 수 있으리라고 생각한다.
2) 차별점이 있어야 한다.
앞서 언급했던 것 처럼 1000개 정도의 이력서를 보면서 느낀 점은, 너무 획일화 되었다는 것이다. 현재 대부분의 FE 취준생은 부트캠프를 거친다.
- 프로그래머스 데브코스
- 코드스테이츠
- 위코드
- 원티드
- 바닐라 코딩
- 우아한테크코스
- 우아한테크캠프
- 부스트캠프
- 코드스쿼드
- 서울 42
- 싸피
- 소프트웨어마에스트로
- 패스트캠퍼스
- 항해99
- 멋쟁이사자들
굉장히 많지 않은가? 오히려 독학으로 공부하는 경우는 정말 드물다.
부트캠프에 대한 고찰
사실 요즘 들어 드는 생각은 독학으로 FE를 공부 했다고 한다면 기술적인 문제보단 커뮤니케이션에 대한 문제 때문에 같이 일하기가 힘들 수 있다는 생각을 하고 있다. 필자가 생각하는 부트캠프의 제일 큰 의의는 커뮤니케이션이다. 공부는 혼자서도 충분히 할 수 있다. 하지만 프로젝트를 하면서 다른 사람과 의견을 나누고 맞춰가는 과정은 혼자서 습득할 수 없기 때문이다.
대부분의 FE 취준생이 부트캠프 출신이고, 대부분의 사람이 똑같은 기술을 익히는 이 상황에서(Javascript, Typescript, React, Redux, …) 어떻게 내가 다른 사람보다 같이 일하기에 더 좋은 사람이라는 것을 어필할 수 있을까?
필자가 생각하는 수단은 다음과 같다.
블로그
- 단순히 기술을 정리하는 것은 불필요하다.
- 내가 어떤 사람인지를 블로그를 통해서 드러내야 한다.
- 개발을 할 때 어떤 생각을 하는지
- 어떤 방식으로 공부했는지
- 어떤 것들을 공부하고 있는지
- 실패 혹은 성공에 대한 회고를 하는지
- 예시
- 단순 ES6 스펙 나열 → X
- ES6가
왜등장했고, 스펙은 어떻게 되고, 어떤 장단점이 있는지 → O
- 필자는 항상
왜(why)에 대한 키워드가 필요하다고 생각한다.
스스로를 표현하는 내용이 많을 수록 좋다.
- 결국 같이 일하고 싶은 사람을 뽑는 것이다.
- 나에 대해 더욱더 궁금하게 해야한다.
- 내가 어떤 가치관을 가지고 있는지
- 어떤 철학을 가지고 있는지
- 개발을 배워서 뭘 하고 싶은지, 뭘 하고 있는지
github
- github의 잔디가 없는 것 보단 있는게 낫다.
- 꾸준히 하는 것도 장점이도
- 특별한 것을 하는 것도 장점이다
- 결국 개발자이기 때문에 코드로 표현하는 것이 아닐까?
하고 싶은 이야기는.. 무척 많지만 일단 이정도에서 마무리해야할 것 같다. 나중에 아예 내가 같이 일하고 싶은 개발자에 대한 주제로 글을 쓰면 될듯..?
(3) 채용 과제
과제에 대한 내용도 다뤄주셨다.
- 필수 기능을 구현할 것
- 구조를 신경쓸 것
- 네이밍 신경쓸 것
- 완성도 높일 것
- node_modules 제거
요약하자면 이정도?
필자도 채용 과제를 출제했던 입장에서 무척 공감되는 내용이었다. 다만 조금 다른 시야를 가지고 있는데, 필수 기능 구현 보단 코드의 퀄리티나 구조에 대해 더 높이 평가한다.
똑같은 기능을 구현하더라도 난이도가 천차만별이기 때문이다. 그래서 과제에서 스스로가 보여줄 수 있는 모든 역량을 보여주는 것이 좋다고 생각한다.
(4) 기술 면접
기술 면접에 대한 이야기는 사실 후기도 많고, 인터뷰 질문도 많기 때문에 대부분의 개발자가 아는 내용이었으리라고 생각한다.
다만, 채용을 했던 입장에서 고민해보자면 김성호님도 이야기 하셨지만, 면접을 보면 볼수록 사람을 판단하기가 어려워진다. 일정 수준 이상을 만족하는 개발자는 많지만 정말 주옥 같은 분을 모셔오는 것은 다른 차원의 문제라고 생각하기 때문이다.
우리 조직에서 수용할 수 있는 제일 좋은 인력을 뽑는 것이 채용 담당자의 제일 큰 성과가 아닐까?
그리고 그런 성과를 내기 위해서 더욱 더 주도면밀하게 사람을 파악해야 하는데.. 1~2시간을 통해서 사람을 파악하는 것 자체가 모순적이기 때문이다.
특히, 필자가 김성호님께 드렸던 질문이 성장성을 높게 평가해서 채용했던 적이 있는가 였는데, 이게 제일 어렵다고 이야기 주셨다.
신입 개발자의 경우, 취준 과정에서 공부했던 내용들은 사실 실무를 접하게 되면 여태까지 했던 것들은 티끌에 불과했구나 깨닿게 된다. 일단 필자는 그랬다. 내가 아는 것은 정말 티끌에 불과하구나..를 절실하게 깨달았다.
그래서 1년차였던 2020년에 정말 죽어라 공부했다.
다만, 내가 입사할 당시에 꽤 매력적인 사람이었는가? 를 봤을 때는.. 잘 모르겠다. 내가 채용 담당자였다면 나를 안 뽑았을 것이다. 그렇기 때문에, 스스로 부족한 점을 인지하고 이를 매꾸기 위해서 무던히 노력했던 것이다.
그렇기 때문에 나는 내가 어떤 사람인지 면접 전에 다양한 방법으로 채용 담당자에게 전달 하는 것이 무척 중요하다고 생각한다. 지금 당장은 부족하더라도 내가 잘 성장할 수 있음을, 포텐셜이 있음을 보여주는 것이다.
그리고 기술 면접에서 모르는 내용이 있더라도, 외웠던 내용을 뒤적거리며 답변하기 보단, 유추하려고 노력하는 것이 중요하다고 생각한다.
사실 모르면 그냥 검색해서 적용하면 된다. 그런데 내가 겪고 있는 문제가 검색해서 안나오면 어떻게 할 것인가? 그런 상황에서 어떻게 대처할 수 있는지를 보여줘야 하지 않을까?
(5) 마지막으로, 나의 생각
마지막으로 필자가 다룰 내용은 먼저 연락이 오게 만드는 것 이다.
필자는 스스로가 많이 부족한 개발자라고 생각한다. 세상엔 잘하는 사람이 너무 너무 많기 때문이고, 나는 그들에 비하면 티끌에 불과하다.
다만 내가 가진 지식을 잘 표현하고, 전달하고, 공유하는 것은 또 다른 문제다.
필자는 의도했던, 의도하지 않았던 내가 가진 것들을 잘 활용했다고 생각한다.
그 수단 중 하나가 블로그 였다.
필자의 경우 Vanilla Javascript로 상태관리 시스템 만들기 라는 글을 작성 했을 때, 이번에 행사에 연사로 참여해주신 김성호 님이 제일 먼저 같이 이야기해보면 좋겠다고 이야기를 주셨는데.. 필자가 김칫국 한 사발 드링킹 하고 지금은 줌인터넷에서 할 일이 있으니 현재 하는 일에 집중하겠다며 거절 의사를 밝혔다. 그 때로 다시 돌아간다면 성호님을 만나뵙고 다양한 이야기를 나눠보면 더 좋았을 것 같다는 생각이 든다.
패기 넘치던 후회 가득한 답장
어쨌든 그 다음에 더 잘써보자는 생각으로 Vanilla Javascript로 가상돔(VirtualDOM) 만들기와 주니어 프론트엔드 개발자의 채용 프로세스 참여 후기를 작성했다.
이런 글을 보고 네이버, 우아한형제들, 토스 등 정말 내가 갈 수 있을까? 싶은 기업의 리쿠르터 분들과 여러 스타트업의 리쿠르터 분들이 연락을 주셨다.
그 당시에는 줌인터넷 프론트엔드 파트를 빌딩한지 얼마 안 된 시점이었기 때문에 눈물을 머금고(?) 지금 당장은 지원하지 않겠다는 의사를 각 기업의 담당자분들께 전달드렸다.
각설하고, 필자가 괜찮은 방향으로 나아가고 있다는 생각을 가지게 된 계기가 김성호님 덕분이었다.
그래서 이번 행사에 무척 참여하고 싶었고, 또 직접 인사드리고 싶었는데.. 발표가 끝나자 마자 칼퇴근을 하셔서 인사를 드리지 못한게 제일 아쉬웠다.
사실 필자는 글을 작성하고 나서 방치한게 아니라 꽤 다양한 방식으로 여러 플랫폼에 홍보했다.
- 페이스북 페이지
- 생활코딩
- 프론트엔드 개발자 그룹
- VueJS 개발자 그룹
- React 개발자 그룹
- Javascript 개발자 그룹
- 오픈채팅방
- 출퇴근길 개발 읽기
- 슬랙, 디스코드 채널
- 블랙커피 스터디
- 부스트캠프
- 에브리타임(대학교 커뮤니티)
- 링크드인
그리고 작성한 글이 정말 퀄리티가 좋을 때는 필자가 아닌 독자 분들이 다양한 플랫폼을 통해 공유를 해주는 경우도 많았다.
먼저 글의 퀄리티를 높여야 하고, 스스로 작성한 글에 자신이 있다면 이를 제대로 홍보할 줄 알아야 한다. 그렇게 여기 이런 사람이 있다 고 알릴 수록 기회가 많아지는 것이다.
그리고 필자가 선택한 또 다른 수단은 스터디 형태의 강의 플랫폼이다. 사실 대부분의 부트캠프가 스터디 형태의 강의 라고 할 수 있는데, 부트캠프 외에도
- 코드숨
- 넥스트스텝
- 프로그래머스
등을 통해 참여할 수 있다.
강의형 스터디에서 미션이 주어질 때 마다 제일 빨리 끝내자 리뷰를 제일 많이 하자 같은 목표를 정해서 미션이 임했다. 이런 과정을 통해서 내가 꽤 개발을 괜찮게 한다 라는 점을 어필하는 것이다.
강의를 하는 사람도, 강의에 리뷰어로 참여하는 사람도 기업에 근무하는 경우가 대부분이며, 대부분의 기업은 채용을 한다.
열심히 하는 사람일수록 기억에 강렬하게 남을 수 밖에 없는 것이다. 그래서 필자는 어떤 과정을 참여하든 최대한 적극적으로, 최대한 많은 시간을 투자했다.
마찬가지로, 이런 경험을 토대로 부스트캠프, 넥스트스텝, 항해99 같은 교육 과정(혹은 플랫폼)에 리뷰어나 멘토로 참여할 수 있었고, 또 이에 대한 회고를 쓰고, 다시 내가 이런 사람이라고 필자의 글을 읽는 사람에게 알릴 수 있었다.
그리고 이 글 또한 필자는 수단이라고 생각한다.
- 나는 이런 생각을 가지고 있다.
- 나는 이런 자세로 개발을 하고 있다.
- 나는 이런 사람과 일하고 싶다.
- 나는 이런 역량을 가지고 있다.
라고 직접적이 아닌 간접적으로 전달하는 것이다.
물론, 필자가 이야기 하는 것이 정답이 될 순 없다. 어떻게 보면 속 빈 강정이 될 수도 있고, 빈 수레가 요란하다는 말의 표본이 될 수도 있다.
그럼에도 불구하고 하지 않는 것 보단 하는 게 더 좋다고 생각한다.
네트워킹
원래 네트워킹에 대한 내용을 제일 길게 작성할 생각이었는데 급발진(?)을 해서 앞의 내용이 길어졌다.. 갑자기 쓰기 귀찮아지기 시작하네
(1) 어떤 일을 얼마나 했나요?
라는 질문을 제일 많이 들었다.
필자는 대학교 1학년이 끝나고 휴학한 다음에 군대에 가기 전까지 서울디지텍고등학교 라는 곳에서 웹 개발 강사를 했었다.
필자는 웹 개발을 고등학교 2학년 때 처음 접했다. 구구절절 이야기하면 너무 길어지기 때문에 궁금하다면 이 글들을 읽어주시길..
어쨌든 21살에 PHP, MySQL, 포토샵(?), javascript, jQuery 등을 고등학생들을 대상으로 교육했다. 약 10개월 정도 했었다. 더불어서 프리랜서를 하면서 다양한 외주를 맡아서 했었는데.. 덕분에 입대하는 날 아침까지 개발을 했었다.
우여곡절 끝에(?) 전역을 하고 복학하기 전까지 일이나 해보자 라는 생각으로 집앞에 있는 에이전시 회사에 지원했는데, 면접을 보고 내일부터 출근하라고 해서 감사합니다! 하고 일했다.
당시에는 월급을 150만원 받으면서 일했는데, 첫날 9시까지 야근했다. 첫 날 부터 너무 열심히해서 준일씨 때문에 퇴근하는게 눈치보이잖아요! 라는 이야기를 들었던 기억이 난다(진심은 아니고 장난으로 한 이야기였다 ㅋㅋ)
그렇게 6개월 정도 일하다가 복학할 때가 되어서 그만두겠다고 이야기 했더니 회사는 안 나와도 좋으니 원격근무로 일하자고 제안주셔서 덮썩 물었고, 1년을 더 일했다.
에이전시마다 다르겠지만.. 내가 맡았던 업무는 그누보드 + 워드프레스로 쇼핑몰이나 회사사이트를 만들고 반응형으로 구축하는게 대부분이었다. 어쩌다 한 번 스프링으로 된 프로젝트도 진행해보고, Vue.js 같은 프레임워크를 써보기도 했는데 어쨌든 쉽게 말해서 재미도 없고 의욕도 없었다. 그래서 그만 뒀다.
그렇게 학업에 집중 아닌 집중을 했고, 우여곡절 끝에 막학기에 줌인터넷에 합류하여 2년 6개월을 근무했다.
사실 프론트엔드를 전문으로 하기 시작한 것은 1년이 안 된다. 줌인터넷에 입사할 때는 서비스 개발자였고, 백엔드 API를 만드는 일을 더 많이 했다. 그래서 Java와 관련된 학습을 꽤 많이 했다.
그러다 갑자기 프론트엔드 파트가 생겼고, 갑자기 리딩을 하게 되면서 프론트엔드 개발자로 전향하게 된 것이다.
어쨋든 위와 같은 과정을 통해서 하고 싶은 이야기는, 대학교를 다니면서 굳이 일을 하지 않아도 된다는 점이다. 같은 조에 대학교를 다니면서 일을 하시는 분이 있었는데 내 과거와 겹쳐졌다. 물론 일했던 경험 자체는 도움이 되지만, 이게 학업의 경험보다 도움이 된다고 이야기 한다면 아니라고 생각한다. (관점의 차이가 있다)
제일 큰 이유 중 하나는, 일은 평생 하게 될 것이다. 그렇기 때문에 여건만 된다면 그냥 학교 생활 자체를 즐기는게 인생을 길게 놓고 봤을 때 더 큰 활력이 되리라 생각한다.
필자는 대학교를 다닐 때가 제일 힘들었다.
일은 일대로 하고, 수업은 수업대로 듣고, 과제도 하고 시험도 보고, 시험 끝나면 다시 일하고를 반복했다. 대학교 복학 후 3년 동안 평균 수면 시간이 4시간~5시간 사이였다.
차라리 그 시간에 마음 맞는 친구들과 프로젝트를 했다면, 동아리를 했다면, 혹은 부스트캠프 같은 교육 과정을 알아보고 준비해서 참여할 수 있었다면 지금보다 더 많은 분들을 뵙고 개발이라는 것의 본질에 더 일찍 다가갈 수 있지 않을까? 하는 생각이 든다.
후회를 한다고 해도.. 사실 필자에게는 별다른 선택지가 없었다. 스스로 학비와 생활비를 벌어야 했기 때문이다. 공부를 해서 시험을 잘 보고 장학금을 받는다고 해도 생활비까지 나오는건 아니기 때문에.. 울며 겨자먹기로 일을 했다. 어떤 날은 내가 왜 이렇게 살아야하지? 하는 생각에 서러움에 북받쳐서 눈물을 쏟아낸적도 있었다. 정말 필자 처럼 어쩔 수 없는 상황이 아니라면, 굳이 일할 필요는 없다고 생각한다. 대학교에서 할 수 있는 값진 경험이 너무 많기 때문이다.
(2) Vanilla Javascript에 대한 글을 왜 쓰게 되었나요?
필자는 프레임워크 라는 것은 내가 아닌 다른 사람이 내 자리를 대체하기 쉽게 만드는 도구라고 생각했다. 즉, 내가 React를 해다가 퇴사했을 때 다른 React 개발자를 구하면 된다. 그런데 내가 React 외적으로 무엇인가 더 중요한 일을 할 수 있다면, 내가 퇴사한다고 했을 때 사측에서는 한 번 이상의 고민을 하게 되지 않을까?
이 사람을 대체 할 수 있다 가 아니라 이 사람을 대체할 수 있을까? 로 생각할 수 있게 만들어야 한다고 생각했다.
그래서 쉽게 대체할 수 없는 개발자가 되어야 한다고 생각했다. 그 수단으로 필자는 프레임워크의 기저에 깔린 개념들을 학습해보자는 생각으로 공부를 했다. 내가 프레임워크를 만들 수준이 된다면, 프레임워크에 얽매이는 개발자가 아니라 더 난이도가 높은 일도 할 수 있으리라고 생각했다.
(3) 사용성이 좋다는 것을 어떻게 판단할 것인가?
이건 필자가 다른 분들에게 질문드린 내용이다. 김성호 님이 UX를 더 신경쓰는 개발자가 되어라 라고 이야기해주셨는데, 그렇다면 UX가 더 좋다는 것을 어떻게 알 수 있을까? 에 대한 질문도 필요하다고 생각했다.
내가 만든 서비스가 사용성이 좋다는 것을 객관적으로 알 수 있는 방법이 있을까?
객관적인 지표를 도출해내는 방법을 생각해보자.
- 사용자가 브라우저 내에서 발생시키는 이벤트가 존재할 것이다.
- 어떤 페이지를 조회하는지
- 어디를 많이 클릭을 하는지
- 어떤 영역에서 많이 머무르는지
이에 대한 정보를 수집할 수 있지 않을까? 그리고 이를 수치화 하면 어떨까?
그럼 이런 생각도 있을 것이다.
- A라는 UI와 B라는 UI 중에 어떤 UI를 더 많이 쓸까?
이를 동시에 측정하기 위한 방법도 있지 않을까?
이에 대해 여기서 자세히 다루진 않겠다. 스스로 한 번 고민해보고, 찾아보는 것을 권유드린다.
(4) 개발자의 역할은 무엇일까?
결국 IT 서비스는 인력 사업이다. 가령, 스마트폰을 만든다고 했을 때 스마트폰에 대한 설계도 필요하고 스마트폰에 들어가는 부품도 필요할 것이다.
그런데 소프트웨어는 어떠한가?
누구나 컴퓨터만 있다면, 스마트폰만 있다면 웹서비스를 이용할 수 있다. 혹은 앱을 다운받아 사용할 수도 있을 것이다.
개발자는 현실세계에는 없는, 손에 잡히지 않는 무형의 것을 만드는 직업이다.
거의 모든 것이 인력사업이라는 것이다.
이에 대해 자세한 내용은 구멍가게 개발사의 이야기를 통해 보면 더욱 좋다.
필자가 하고 싶은 이야기는, 개발자라는 직업 자체가 돈먹는 하마라는 것이다.
앞서 언급한 프레임워크에 대한 이야기도 여기서 출발한다. 개발자를 채용하고 교육하고 투입하는 것 자체가 돈이다. 그래서 프레임워크를 통해서 획일화 하는 것이다. 최소한의 시간으로 최대의 퍼포먼스를 내려고 하는 것이다.
그렇다면, 개발자가 시간을 낭비하지 않기 위해서 해야 하는 것은 무엇이 있을까?
대표적인 수단이 코드리뷰 클린코드 리팩토링 같은 것들이다. 우리는 왜 좋은 코드를 작성해야 하는가? 그건 나를 대체할 수단을 만들기 위함이라고 생각한다.
내가 없더라고 회사가 굴러갈 수 있도록, 내가 없더라도 지장이 없도록, 내가 아닌 누군가가 들어오더라도 이 조직에 금방 적용할 수 있도록 하는 것이다.
이런 수단이 잘 작성된 코드와 이를 검증하기 위한 코드리뷰 등으로 드러나는게 아닐까?
그리고 최소한의 돈(인력/인프라)으로 서비스를 굴리는 것 이라고 생각한다. 똑같은 서비스를 만들어도, 확장하더라도, 유지하더라도 어떤 기술 스택을 사용하냐에 따라 유지비용이 달라진다.
가령, 요즘 프론트엔드 개발자는 대부분 웹뷰를 만든다. 그런데 왜 웹뷰를 쓰는걸까?
네이티브 앱을 만들면 속도도 훨씬 빠르고 사용성도 좋다.
앞서 언급한 것 처럼 사용성이 프론트엔드 개발자에게 중요한 비중을 가진다면, 어째서 앱을 만들 때 네이티브로 모든 기능을 구현하는게 아니라 웹뷰를 활용하는 것일까?
이유는 돈과 시간 때문이라고 생각한다.
네이티브로 앱을 만들 경우 안드로이드와 iOS 개발자를 각각 채용해야 한다. 기능 하나를 수정할 때 양쪽 개발자와 커뮤니케이션을 해야 하고, QA를 해야 한다. 무엇보다 앱을 업데이트 하려면 검수과정도 거쳐야 하고, 바로 반영되지도 않는다.
무언가 문제가 발생했을 때 즉각적으로 대처할 수 있을까? 그렇지 않은 경우가 대부분일 것이다. 변화에 취약한 것이다.
그러나 웹뷰를 사용한다면 이런 문제 대부분을 해결할 수 있다. 그래서 많은 IT 회사들이 소수의 앱 개발자를 채용하고, 다수의 프론트엔드 개발자를 채용하면서 최소한의 인력으로 최대한의 효과를 보려고 하는 것이다.
그리고 웹이 많은 플랫폼에서 사용될 수록 웹의 스펙 또한 추가 되는 것이고, 그럴 수록 프론트엔드 개발자가 공부할 것들이 많아지는 것이다.
우리가 회사에서 일한다는 것은 결국 수익 창출을 위함이다. 최소한의 자본으로 최대한의 이윤을 보기 위함이다. 스스로 이윤을 추구하는 개발자라고 할 수 있을까? 한 번 고민해볼 필요가 있다.
마치며
코로나 때문에 대부분의 대외 활동을 온라인으로만 해서 아쉬웠는데, 이렇게 오프라인 행사를 참여할 수 있어서 무척 재밌고 즐거웠습니다. 특히 제가 작성한 글을 생각보다 더 많은 분들이 읽어주셨고, 덕분에 별다른 소개를 하지 않아도 알아봐주고 인사해주시는 분들도 무척 많습니다. 저는 한 인간으로서 나는 그렇게 잘난 사람도 뛰어난 사람도 아니기 때문에 이런 관심 자체는 무척 부끄럽고 부담스럽지만 동시에 더 많이 노력하고, 더 열심히 하자는 생각도 할 수 있게 되었습니다.
그래도 더 많은 분들과 이야기 할 수 있었는데, 제가 조금 더 적극적이였다면 어땠을까 하는 아쉬움도 있습니다 😭
그리고 이야기 하고 싶었으나 다 이야기 하지 못했던 것들도 있었고, 다시 한 번 이야기 하고 싶었던 것들도 있었습니다. 그렇게 글을 작성했는데 아쉬운 점도 있지만 어쨌든 제가 전달하고 싶은 이야기는 글에 대부분 담은 것 같습니다 😁
다음에 이런 자리에 참여하게 된다면 더 많은 분들과 소통하고 싶네요!
긴 글 읽어주셔서 감사합니다 🙇♂️