프론트엔드 개발자로서 커리어를 본격적으로 시작하고나서야, 개인적으로 깨닫게 되었던 점들을 소개한다. 개인적으로 남이 주는 돈을 받고 개발하는 그 시점부터를 커리어의 시작이라고 본다. 이 글에 추가될 이야기들은 개발적인 이야기일 수도 있고, 사람 냄새 나는 이야기일 수도 있다 😇

프론트엔드 진영은 급변해서 힘들다?

커리어를 시작하기 전, 갓 공부를 시작했을 때에는 힘들다는 말이 잘 이해가 되지 않았다. 오히려 더 좋다고 생각했다. 공부할 게 많을 수록, 심심하지는 않을 테니까. 늘 새로워! 짜릿해! 요런 느낌이었었다.

그리고 지금은 왜 수많은 선배 개발자들이 ‘힘들다’고 했었는지 완벽하게 이해해버렸다. 매일매일 쏟아지는 새로운 기술을 습득하는 것이 재미없다는 이야기는 결코 아니다. 다만, 수박 겉핥기 식으로 공부하는게 의미가 없다는 이야기이다. 회사에서 제일 중요한 것은 생산성이고, 그 생산성은 개발자가 사용하는 도구의 숙련도로부터 나온다. 즉, 하나의 도구를 ‘나 숙련자요’ 라고 말할 수 있을 정도로 공부하기도 전에 새로운 것이 나오고 그걸 또 찍어 먹어봐야 하고 만약에 더 좋으면 공부하던 것 버리고 갈아타야 하고, 이렇게 매번 새로운 비용이 들어가야 한다는 것이 ‘힘들다’는 것이다.

무엇보다도 급변하는 프론트엔드 생태계가 개발자들을 힘들게 하는 가장 큰 이유는 아무것도 확실한 것이 없다는 점인 것 같다. 너무나도 빠르게 변화하다보니 어떤 패러다임이나 철학이 자리잡기가 쉽지 않은 환경이다. 백엔드가 자바 공화국이 된 것처럼, 스프링 프레임워크가 10년 넘게 굳건히 자리를 지킬 수 있는 것처럼, 굳이 설득하지 않아도 어떤 패러다임들에 대해 이미 공감대가 형성되어있는 것처럼. 이런 일들은 프론트엔드 진영에서 기대하기 쉽지 않다.

리액트가 1강으로 자리를 잡은 것도 그렇게 오래되지 않았다. 하물며 그건 SPA에서만의 이야기이고 (그마저도 불안불안 하지만) SSR 쪽은 아직도 전쟁중이라고 생각한다. next.js가 자리를 잡나 싶더니 remix가 부상하고 갑자기 리액트에서 자체적으로 SSR을 지원하는 버전 18을 발표하고… 그야 말로 혼란의 중심지이다.

요즈음 프론트엔드 진영에서 관심도는 굉장히 높지만 정립이 되어있지 않다고 느껴지는 부분은 딱 두 가지인 것 같다.

1. 리액트에서의 FP? OOP? FP+OOP?
2. 프론트엔드에서의 실용적인 테스트란? 테스트의 효용성과 가치란?

커뮤니케이션 역량이란 뭘까?

개발직군 뿐만 아니라 거의 모든 직군의 채용 공고에서 요구하는 역량 1티어, ‘커뮤니케이션’. 말만 잘 하면 커뮤니케이션 역량이 높은걸까? 커뮤니케이션 역량이란 대체 뭘까? 하는 생각은 누구나 해봤을 거라고 생각한다.

이 글을 쓰고 있는 시점으로 일한지 10개월이 되어가는 현 상황에서 내가 생각하는 커뮤니케이션 역량이란 ’내 마음대로 생각하지 않는 것‘이다. 엥 그거 너무 당연한 거 아니냐 라고 생각할 수도 있겠지만 이게 의외로 쉽지 않다. 아마 많은 사람들이 자기도 모르게 악의 없이 이렇게 하고 있을거라고 생각한다.

프론트엔드 개발자는 개발지식 만큼이나 커뮤니케이션 역량도 많이 필요로 한다. 개발파트와 비개발파트를 잇는 어떤 연결점의 역할을 하기 때문이다. 기획 (PO, PM) 직군과 디자이너 직군 뿐만 아니라 운영파트와도 굉장히 자주 소통한다.

이 과정에서 실수하기 딱 좋은 지점이 ‘내가 쓰는 용어를 저 사람도 같은 의미로 알고 있을 것’이라고 착각하는 거다. 대부분은 그저 문맥이나 감, 혹은 본인의 배경지식으로 의미를 파악하기 마련이다. 절대 나와 상대방의 생각이 같음이 보장되지 않는다. 예를 들어 ‘스타일의 커스터마이징’이라고 했을 때 커스터마이징이라는 게 굳이 설명하지 않아도 의미가 통일된 단어라고 생각할 수 있겠지만 사실은 그렇지 않다. 디자인 파트에서 생각하는 커스터마이징과 프론트엔드 파트에서 생각하는 커스터마이징은 충분히 다를 수 있다. 실제로 디자인 시스템의 버튼과 똑같이 생겼는데 애니메이션만 추가되어있어 디자인 시스템의 옵션만으로 구현이 불가능한 경우 프론트엔드 파트에서는 디자인 시스템 버튼을 커스터마이징한 것이라고 생각했지만 디자인 파트에서는 커스터마이징이 아닌 새로운 버튼이라고 생각한 사례가 있다.

그래서 항상 내가 생각한 것이 상대방이 이해한 것과 같은지 확인해야 한다. 두 번 일하지 않고, 커뮤니케이션에 미스가 발생하지 않으려면 무조건이다.

그리고 언제나 감정을 가장 신경써야 한다. 각자의 성향에 따라 같은 말이라도 다 다르게 받아들일 수 있다. 이 말이 상대방에게 어떤 감정을 불러일으킬지, 부담이 되지는 않을지, 어떤 생각을 하게 만들지 충분히 고려하고 말투를 신경써서 이야기해야 한다. 함께 일하는 동료의 감정을 상하게 만들고도 잘 협업할 수 있는 방법은 없다.

개발자는 언제 필요없어질까?

커리어를 시작하기 전부터 (= 돈 받고 일하는 개발자가 되기 전부터) 항상 ‘서비스를 완성하고 나면, 프론트엔드 개발자의 역할은 어떻게 되는거지?’ 하는 의문이 있었다. 그 의문을 처음 가졌을 때 들었던 말은 ‘개발했다고 끝이 아니고, 유지보수 해야 하고, AB테스트 해야 하고, 개선해야 하고, 신규 서비스 개발해야 하니 할 일은 많다’ 였다.

그래서 그런줄로만 알았는데 최근 CTO님의 이야기를 듣고 그게 다가 아님을 알게 되었다. 어떤 유명한 컨퍼런스의 최대 후원사일 정도로 규모가 크고 유망했던 개발 조직이, 다른 조직 (MD, 마케팅)이 회사의 매출에 기여하는만큼 기여할 수 없어 없어진 사례를 들었다. 특히나 콘텐츠 회사에서 운영 파트의 운영만으로 수천억 수조원의 가치를 인정받는 경우가 있고, 그런 회사에는 개발팀이 필요없을 수 밖에 없다는 사례도 들었다.

이 이야기가 시사하는 바는 그래서 개발자가 살아남기 위해서는 운영파트가 일을 못해야 한다가 절대 아니다. 그런 상황속에서도 개발 조직이 존재해야 하는 이유와 그 가치를 어떻게 증명할 것인지를 항상 생각하며 일을 해야 한다는 것이다.

어떤 개발자가 되고 싶은 걸까?

일을 시작하기 전에 막연히 생각하는 것과 일을 하면서 ‘어떤 개발자가 되어야 겠다‘라고 느끼는 것은 확연히 달랐다. 여러가지 생각을 하고 있긴 하지만 요즘들어 주변을 보면, 특히 여러 상황들을 보면 대부분 크게 두 가지로 나뉘게 되는 것 같다.

• 프로덕트를 만들기 위한 개발자
• 개발을 위한 개발자

둘 중 무엇이 맞다라고 단정지을 수는 없다. 하지만 분명한 것은 회사와 채용시장에서 원하는 개발자는 전자일 거라는 생각을 했다.

실수

사람은 무조건! 누구나! 언제나! 실수를 할 수 있다. 우리가 해야할 것은 누가 실수를 했는지 찾아내어 망신 주는 것이 아니라 실수에서 사람을 배제하고 생각하는 것이다. 왜 이 실수가 일어났는지, 앞으로 어떻게 예방할 수 있을 것인지를 모색해야 한다.

타 직군 및 동료와의 협업

• 동료가 놓친 일은 내가 하고, 내가 놓친 일은 동료가 한다.

• 협업 과정에서 어느 누구도 갑이 되어서는 안된다. 갑과 을의 관계가 형성되면 상대방의 전문성을 쉽게 폄하할 수 있다. 그렇게 되면 신뢰가 생기지 않고, 상호간의 신뢰가 없는 조직은 빠르게 망한다.

  주변에서 들었던 사례만 보더라도 열심히 개발해서 오픈한 서비스가 시장 반응을 얻지 못했을 때, C레벨에서부터 나서서 기획자와 디자이너의 전문성을 폄하했을 때 모두 퇴사했다. 그 모습을 지켜보며 남은 개발자는 계속 그 회사에 남아있겠다라고 생각했을까? 빠른 시일내에 이직할 생각만 하고 있었다.