회사생활 세번째 일기 ( 프론트 시니어와 마찰 )

아니 쓰다보니까 왜 마찰 얘기가 이렇게 많은거지?
근데 사실 마찰이 없는게 더 문제라고 생각한다.

뭐랄까.. 특히 요즘 동료들에게 제발 좀 싸워라 라고 얘기를 한다.

마냥 싸우는게 안좋다 라고 얘기한다면 그건 좋은걸까?

싸움에 대한 생각

우리 회사는 수평적 구조다.

그럴수록 토론도 많이하고 서로 안맞는 구석이 있으면 말 싸움을 해서라도 끝까지 가서 결국에는 하나로 통일을 해야한다.

그렇지 않다면 누군가 나서서 이거해! 이걸로 정해! 가 되지가 않으니 서로 각자의 스타일대로 개발하고 기획하고 디자인한다.

 

특히 지금은 프론트가 많이 고달픈 상황인데 백엔드 개발자들이 초반에는 토론을 많이 했지만 결국에는 각자 스타일대로 코딩하고 있으며 당연히 키값은 각각 따로 온다.

하나하나 프론트가 지적하면 그나마 나랑 친한 사람을 설득해서 키값을 겨우겨우 맞추고 있다.

진짜 쉽지않다..

 

이 얘기는 나한테도 해당이 되는 얘기다.

 

시니어 프론트엔드의 등장

앞서 말했듯이 나는 경력이 좀 있는 프론트엔드 개발자를 굉장히 원하고있다.

그 상황에서 다행이 이사님이 최소 7 ~ 8년차의 프론트엔드 개발자를 뽑을것이라고 얘기했고 드디어 사수가 생기는구나 싶었다. 수평적 구조지만 정말 많이 배우고 잘 따를 생각이었다.
들뜬 마음에 시니어님이 오시기전에 프로젝트를 전반적으로 리팩터링하고 스토리북으로 문서화도 해놨으며 폴더구조, 간단한 폴더규칙, 네이밍 규칙을 문서로 정리해놨다.

 

그리고 기다리고 기다리던 시니어님이 드디어 입사하셨다.

그리고 간단하게 2주정도 코드를 훑으시고 실무에 투입이 되었다.

코드 파악도 하셨을테니 커스텀훅을 만드는데 고민이 있어 같이 코딩하면서 생각을 배우려고 질문을 했다.

 

나는 onChange 같은 간단한 함수는 그냥 any 를 박는다.

이건.. 뭐랄까 타입스크립트에서 타입을 쓰는건 복잡한 프로젝트나 데이터 설계단에서 타입을 명시해서 빠르게 버그를 잡는 용도라고 생각하는게 평소 내 생각이기에 any를 사용하면 안된다고 말씀하시길래 흠.. 보면 약간 찝찝하기는 하지만 어차피 맨 끝단에서 사용하고 e.target.value 만 사용하는건데 어떤 문제가 있을까요?

라는 질문을 했고 보안에 문제가 생긴다고 답을 하셨다.

시니어 개발자분에게 첫 질문이었고 첫 엥? 하는 순간이었다.

아니 이게 무슨..?

 

사실 같이 일을 하면서 너무 많은 헤프닝이 있어서 간략하게..

풀스토리를 적을 수는 없다.

 

시니어 프론트엔드의 문제점(?)

여태까지 기술스택이!! NextJS와 Typescript를 주로 사용했다면서!!

 

1. 타입스크립트 쓰는 이유를 보안때문이라고 생각함. 근데 제네릭, Omit, Pick 타입을 모름

 

2. 리액트를 사용하면서 컴포넌트를 왜 사용 해야하는지 모름..

  - 컴포넌트를 만들어야 하는 이유를 설명했지만 이해를 못하셔서 인터넷 검색으로 왜 사용해야 하는지 설득 하는 과정에서 인터넷에서 말한는건 탁상공론을 하는 사람들얘기다 발언. 

 

3. CSS는 테일윈드, 이모션, 스타일드 컴포넌트 scss 중 선택하는 과정에서 테일윈드 끔찍해 했으면서 모든 코드를 인라인 코드로 작성함.

 

4. 업체 프로젝트와 어드민 프로젝트를 담당하여 들어오셨고 UI와 기능은 완전히 같고 색깔만 다른데 모노레포 사용하거나 사내 라이브러리 적용 할 생각 X 애초에 뭔지를 모름

 

5. 10월에 투입한 프로젝트 3월에 오픈 예정인데 2월에 결과물 보니까 회원가입 로그인 페이지 끝.

( 이 때부터 내가 모든 프로젝트를 관리하면서 야근 하기 시작 ) 근데 시니어는 야근을 안함. 책임감 부족.

 

6. 탭 UI에서 방문한 페이지의 데이터를 저장하고 싶은 기획의 요청이 있었어서 다 같이 회의 후 indexDB 사용 한 번 해보면 될 것 같아요 라고 힌트를 줬지만 무지성 한 페이지에서 useState에 모든 상태를 때려박음. 당연히 모든 페이지가 느려짐..

 

7. 이전 회사에서 팀장 역할을 하셨다길래 문서화를 부탁드렸으나 page 별로 uri 만 적음

 

8. 이미 진행 된 프로젝트에서 사용하는 라이브러리를 사용 안하고 독단적으로 기술스택을 정함.

대표적으로 이미 진행 된 프로젝트에서는 useQuery를 사용하는데 혼자 SWR 을 사용한다는둥..

 

9. GIT 사용법을 몰라서 다른 팀원 git을 밀어버림 ( 엄청 많이!!! ). 복구해주는건 나의 몫

10. 커스텀훅이 뭔지 모름

11. 디자이너 개무시

  - 디자인시안대로 하지 않고 본인이 이쁘다고 생각한걸로 개발함. 디자이너에게 괜찮냐 의견 안물어보고 독단 진행

 

11. 3명이서 코드리뷰 하자고 회의 결정 할 때 너무 좋다고 해놓고 한번도 안하시길래 이유를 물어보니

"코드리뷰 하는법 몰라요", "코드 스타일이 달라서.." 

 

12. 우리는 아직 수익창출이 안되는 상황인데 돈 벌어다 주는 본사 회식에서 처음보는 물류팀에게

열심히 하지말고 받은만큼만 해요 발언 ( 이게 진짜 너무 열받았다 )

 

개인적인 생각

위와 같은 내용은 사실 그냥 신입이라고 치고 백번양보해서!! 그냥 넘어갈 수 있다.

그런데 자존심이 너무나 강한 사람이라서 토론을 쌩떼를 부리고 막상 회의 할 때 알겠다고 하면서 그냥 본인 마음대로 해버리는 경우가 너무 많아서 진짜 인간적으로까지 싫어진 첫 동료다.

 

당연히 이런 말을 하는 내가 부정적인 사람이거나 잘 못 어울리는 사람으로 보일 수 있다. 내 얼굴에 침 뱉기는 하는게 아닐까 위 글을 적으면서 100번 생각했다. 

근데.. 솔직히.. 같은 프론트엔드 개발자로써 위와 같은 사람과 처음부터 잘 지낼 수 있는 사람이 몇이나 있을까..?

당신은 그럴 수 있는가? 그럼 진짜 존경할게요.. 

 

이사님도 개발자 출신이다 그래서 위 내용을 이사님한테 보고했다.

하지만 이사님은 경력에 대한 믿음이 굉장히 크신분이다. 왜그러냐 팀원들끼리 잘 지내라 라는 답변만 듣게 되었다..

 

그 당시에는 모든것을 체념하고 혼자 개발 해야겠다 라는 마음 가짐으로 전체프로젝트를 매니징하기 시작했다.

 

이건 먼 훗날 얘기지만 이사님이랑 같이 술 마실 기회가 있었는데 술이 떡이 되셔서는

"이미 나도 알고 있다. 하지만 어떡하냐 이미 뽑았다. 우리 회사는 사람을 짜를 수 없다.

미안하다. 인천에서는 사람 구하기 쉽지 않았다." 라는 얘기를 들었다.

그래서 부탁했다. 제발 컬쳐핏 면접이라도 실무자들이 면접에 참여 할 수 있게 해달라고..

이후에 실무자 면접이 도입되었다.

 

오케이. 그럼 이사님이 알아주면 됐어.

라는 마음가짐으로 시니어와 친해지기 위한 개인적인 프로젝트를 시작했다.

 

당연히 모든 회사원들이 받은 만큼만 일하는 시니어들을 싫어했고 팀워크는 당연히 박살 난 상태였다.

개인적으로는 성공했고 이제 박살난 팀워크를 회복하는 개인 프로젝트를 진행중이다.

 

다음글에서는 박살난 팀워크와 개인적으로 어떻게 해결해나갔는지 포스팅 할 예정이다.