회사에서 살아남기

문득 "나는 성장한 것일까?" 라는 생각이 들었다. '내가 성장한 것이면 좋겠다'는 기대감과 '내가 성장하지 못한건 아닐까?'라는 불안감이 섞이면서 이와 같은 의문들이 생기게 되었다. 대부분의 주니어 개발자들이 성장에 민감하여, 나와 같은 고민을 할 것이라고 생각한다. 무기력하게 차에 타는 개발자보다는 멋진 곳에서 일하고 싶을 테니까 말이다.

부정적으로만 나아가게 된다면, 흔히 말하는 가면 증후군에 빠지거나 현재 자신에 대한 긍정적인 측면은 보지 못할 수 있다. 이럴때는 회고글을 작성하면서, 생각을 정리하고 쉬어가는 시간을 가지는 것도 좋은 방법일 수 있다.

평범한 개발자의 늦은 회고글을 작성하고 나서, 6개월이라는 시간이 지났다. 회사일과 개인 공부를 둘 다 잡겠다는 포부를 마무리 멘트로 작성하며 글을 마쳤었는데, 지켜진 부분도 있고 그렇지 못한 부분도 있었다. 그래서 지금 돌이켜 보면, 아쉬운 점도 있고 나름대로 뿌듯한 점도 많은 기간이었다.

주니어 개발자가 가져야할 스킬들에 대한 개인적인 생각을 기반으로 회고를 작성했다. 이 글에서는 필자가 회사에서 어떤 방식으로 업무를 하며 성장하고 있는지도 볼 수 있다.

개발자적인 사고 방식

작은 규모의 스타트업이었던 이전 직장에서 React(Next)로 프로젝트 셋팅부터 서비스 개발까지 담당했는데, 현 직장에서는 이미 Vue로 만들어진 커다란 서비스가 존재하고 있었다. 처음에는 사용하는 SPA의 프레임워크(혹은 라이브러리)가 바뀐다는 것에 많은 걱정이 있었다. 빠른 시간 내에 적응을 해서 실무에 투입되어도 문제가 없을지에 대한 걱정도 있었지만, 대세를 따라가지 못해 뒤쳐질 수 있다는 생각 때문이었다. 하지만 이런 생각은 좋은 직장 동료를 만나며 다시 생각하게 되었다.

아직도 대세를 따라가는 것이 옳다는 생각은 유효하다. 그만큼 커다란 생태계가 있어 좋은 레퍼런스들도 많고, 실제로 많은 회사에서 사용하고 있어 이직에도 더 수월하기 때문이다. 그런데 공고들을 살펴보면 재밌는 사실을 하나 알 수 있다. 앵귤러, 뷰, 리엑트와 같은 SPA ~~ 와 같은 멘트들이 많이 보인다는 것이다. Front를 개발하기 위한 도구 보다 더 중요한 것이 있다는 의미이다. 나는 그것 중 하나가 개발자적인 사고 방식이라고 생각한다.

도구를 낮춰 말하는 것이 아니다. 회사와 동일한 스택을 사용하는 개발자를 좋아하는 것은 당연하다. 기술마다 노하우가 다르기 때문이라고 생각한다. 하지만 이런 부분은 회사를 다니면서, 개인적으로 충분히 채워 나갈 수 있는 부분이라고 생각한다.

사실 개발자스러운 사고 방식의 개념은 굉장히 방대하다고 생각한다. 컴퓨팅 사고 능력(테오)이 뛰어난 사람도 개발자 사고 방식이 특출난 사람이며, 기획이 나오면 해당 기능만 보는 것이 아닌 기능의 허점, 보안적인 이슈, 사이드 이펙트를 생각하며 논의하는 개발자도 훌륭한 사고 방식을 가진 사람이다. 또한, 버그나 이슈가 올라온 경우 문제점을 빠르게 파악하는 능력도 포함된다. 예를 들면, 하나의 서비스에 다수의 백엔드, 프론트엔드, sdk 등이 있는데 대충 어디에 문제가 생겨 발생한 에러인지 바로바로 파악하는 경지에 이른 것이다.

최근에 팀장님께서 좋은 코드란 무엇인거 같아요?라고 물어보신 적이 있다. 함께 소통을 하면서 내린 결론은 가독성이 좋은 코드가 좋은 코드였다. 사실 이것도 매우 어려운 문제다. 가독성이 좋다는 것은 로직이나 컴포넌트가 적절한 추상화가 되어 있고, 모두가 납득할만한 패턴을 사용하고 있다는 의미이기 때문이다. 이와 같이 기능을 구현할 때, 좋은 코드를 생각하며 개발에 임하는 사람도 개발자적인 사고 방식을 가지고 있는 것이다. (과하지만 않다면..)

즉, 개발자적인 사고 방식은 그냥 개발을 잘하기 위한 사고 방식이다. 위의 능력들이 갖춰져 있을 경우, 새로운 프레임워크나 라이브러리를 사용 하더라도 공식 문서를 보며 효율적인 패턴을 금방 찾고 익숙해진다. 물론, 하나의 기술을 깊게 공부하며 단련하는 것은 훌륭한 방법이지만, 가끔은 그 외에 개발 실력을 늘릴 수 있는 방법을 찾아보는 것도 좋다. (개발자도구만 잘써도 이쁨 받는다)

좋은 동료들과 함께 근무하면서 이와 같은 능력들을 기르고 있다. 무작정 코드부터 작성하는 것이 아니라, 위에서 소개한 것과 같은 사고 방식을 먼저 빗대어, 여러 측면으로 문제를 바라본다. 그 후에 동료 개발자와 방향성에 대해 이야기 해본다. 내가 생각도 못한 곳에서 좋은 지적이 나오는 경우에는 "~~님은 어떤식으로 접근해서 그런 생각에 도달하셨나요?" 라고 조금 엉뚱한 같은 질문을 하기도 한다. 아직 내가 가지지 못한 좋은 사고 방식을 닮고 싶기 때문인 것 같다.

항상 좋은 코드를 작성할 수는 없어도, 현재 코드의 어떤 부분이 문제이고 어떻게 개선하면 좋을지에 대해서 소통하자. 나는 동료 개발자와 소통하면서 개발하거나, 코드 리뷰를 통해 개선해나가고 있다.

안된다고만 하지 말자

기획이나 디자인이 나오면, '아 이거는 안될 것 같은데..' 라는 부분이 분명히 있다. 현재 서비스의 상황에서 정말 불가능한 것들도 있겠지만, 대부분은 '이 기간까지는 안될 것 같은데..' 혹은 사용하고 있는 '서드 파티에서 거기 까지 커스텀은 안되는데..' 이다. 그렇다면 이런 상황에 우리는 어떤식으로 의사소통을 해야할까?

먼저 어떤 이유에서 안될 것 같다고 생각했는지가 중요하다. 설계된 서비스의 구조상 불가능하다면, 기획이나 디자인 회의에서 확실하게 말하는게 좋다. 정말 안되는 것인지 팩트 체크는 꼭 하자. 비개발 직무는 이해하기 어려운 내용이더라도, 어떤 이유에서 불가능한지 최대한 쉬운 비유를 들며 공유하는 것도 하나의 방법이기 때문이다.

그렇다면, 기간 혹은 오버 엔지니어링이 필요한 까다로운 조건들이 이유인 경우에는 어떻게 소통을 하면 될까? 여기서 부터는 의사소통 능력이 매우 중요하다. 그냥 안된다고만 말하는 것이 아니라 새로운 방법을 제안하는 것이다.

생각해보면 무작정 안된다고 하는 것은, 기획자나 디자이너 입장에서는 대화 단절이다. 말하고 있는데, 조용히 하라는 것과 다른게 없다.

이번에 개발해야 할 Feature 에서 여러 기능 중에 A라는 기능이 있다. 기간 안에 안될 것 같은 기능을 A라고 해보자. 소통하기 전에 A가 정말 필요한 기능인지 판단해보자. 모두 개발하면 좋지만, 시간은 한정적이기 때문에 더 중요한 부분에 힘쓰는 것도 방법이다. 만약 정말 필요한 기능이라면, 현재 상황에서 A기능을 더 간단하게 구현할 수 있는 방법 혹은 A기능과 유사한 효과를 내는 기능을 생각해야 한다. 그 후 고민한 부분들을 토대로 소통을 하면 설득이 될 수도 있고, 더 좋은 방안이 나올 수도 있다.

A 기능을 무조건 해야한다고 하면, 기간을 늘리거나 야근하자!

주도적으로 일하기

현 회사같은 경우에는 메인 Feature마다 PM이 따로 부여된다. 새로운 주제를 해결하기 위해 기획, 프론트, 백엔드 등 여러 직무팀에서 한 명의 PM이 각각 나오는 것이다. 일정 산출 및 관리부터 여러 직무와 커뮤니케이션하며 개발을 진행하게 된다.

미들급 혹은 시니어 백엔드 개발자가 있는 팀과 주로 일하기 때문에, 내가 프론트의 PM을 부여받게 되는 경우에는, 나보다 높은 연차의 백엔드 PM과 일하는 구도가 된다. 그러다 보면, 모델 회의 같은 백엔드와 소통해야 하는 과정에서, 무조건 수긍하는 자세가 될 수 있다. 그리고 개발 중 에러가 발생하더라도, 내가 어디를 잘못 작성했나보다 라는 생각부터 들 수 있다. 나보다 회사의 서비스에 대해 깊은 이해가 있고, 실력있는 개발자가 그렇다면 그런거지 라는 생각 때문이다.

에러가 발생했을 때, 내 코드부터 살펴보는 것은 좋지만 위처럼 과하게 수동적인 태도는 좋지 않다. 일의 효율을 떨어뜨릴 뿐더러 소통이 아닌 일방적인 상황이 된다. 내가 생각하고 있는 논리와 상황을 상대방에게 잘 전달하도록 하자. 합리적이라면 받아들여 지고, 아니라고 한다면 나의 논리에 반박하는 대답이 돌아올 것이다. 이 과정속에서 성장하고 있는 자신을 발견할 것이다.

나도 아직은 주변 동료들에게 물어보며 판단하고 있는 것들이 많지만, 더 성장하여 혼자서 판단할 수 있는 것들을 늘려야겠다.

그래서.. 뭐 개발해?

안 궁금하겠지만, 어떤 것들을 개발하고 있는지 간단하게 소개하겠다. 나는 Full Stack SaaS CDP(B2B) 서비스를 제공하고 있는 팀에 합류하고 있다. 데이터를 기반한 분석부터 고객을 관리할 수 있는 기능까지 제공한다. 많은 기능들 중에 하나만 예시로 들자면.. A라는 쇼핑몰앱에서 한 번 이상의 구매를 수행한 24세 이상의 남성 유저에게 오후 3시에 앱/웹 푸시를 보내는 등의 디테일한 메시지를 만들 수 있다. 추후에는 어떤 기능들을 개발했는지 소개하는 시간도 가져보겠다.

개인적으로 하고 있는 공부

요즘은 난이도가 낮은 코딩 테스트 문제를 풀면서, 알고리즘에 재미를 붙이기 위해 노력하고 있다. 그리고 회사에서 성장하면서 느낀 것들을 토대로 뷰가 아닌 리엑트에 접목시켜보고 있다. 두 기술의 차이점이 명확해서 이것도 응근 재밌는 것 같다.

마무리

마무리는 아쉬웠던 점을 언급하는 것으로 마치겠다. 요즘 책을 너무 안읽고 있다. 운동에 맛이 들려서, 열심히 운동하고 나면 졸리기 때문이다. 핑계다. 책을 읽자!