다음 회사에서는 이렇게 해봐야지

2020.02.25

메인이미지

퇴사한지 2개월여.

개인적으로 휴식하고 준비하고 싶은 것들이 있어서 시간을 좀 보냈다.
이젠 다시 세상으로 나와야 할 때. (feat. 잔고 텅텅)

미뤘던 이전 회사에 대한 회고를 오늘에야 마쳤고, 여러 생각들을 정리했다.
거기서 나는 무엇을 배웠고, 나는 무엇을 잘했고 못했는지.

회고 과정에서 들었던 다양한 감정들. 기쁨, 절망, 자괴감... 하지만 이미 지나간 일.
다음 회사에서는 이렇게 해보고 싶다는 것들이 생겼다.

이것은 스스로에 대한 다짐의 글이다.
또한 다음 회사 출근을 앞 둔 이들게도 도움이 되었으면 하는 마음이다.

이야기 꼭지의 순서는 우선순위와 상관없다.

회사에서 겪는 경험들을 그때그때 정리하기

회사 생활을 하다보면 기억할 만한 일들이 생긴다.
이것들을 퇴사 후 한 번에 정리하며 회고를 하려니 에너지도 엄청나게 소모하게될 뿐더러, 놓치는 것들이 생긴다.
처음부터 포맷을 마련해서 정리할 만한 이벤트나 생각거리가 생길때 그때그때 정리하도록 하자.

회사 내부의 사람들과 더 깊은 교류를 해보기

사업은 성공할 수도 있고 실패할 수도 있다.
(더욱이 스타트업이라면 실패 확률이 압도적으로 높다는 것은 냉정한 사실)

결국 남는 건 사람이다.
전에는 같은 (개발)팀끼리만 밥을 먹거나, 혼자 회사안에서 간단히 떼우거나 했는데 이젠 회사 내의 다양한 사람들과 점심 약속을 잡아서 먹고 그러자.
동료는 소중한 사람. 업무 분담자 그 이상의 존재다.

사내 스터디를 적극적으로 주도하기

우리는 알고 있다.
혼자서 공부하기 어렵다는 사실을.

지금까지는 만들어진 스터디그룹에 참여하거나, 새로운 스터디가 필요하더라도 개발일정이 바쁘다는 이유로 만들지 않았었다.
이제는 내가 하고 싶고 필요한 스터디를 적극적으로 추진 해볼 생각이다

코드리뷰와 함께 사내 스터디는 함께 성장할 수 있는 (내가 아는)유일한 방법이다.

내 밥그릇은 내가 챙기기

이건 커리어에 관한 이야기다.
진부한 말이지만, 사회에서 내 밥그릇은 내가 챙겨야한다.

하고싶지 않은 업무를 해야할 때는 거절하거나 보상을 요구하기

회사 일을 하다보면 Legacy프로젝트때문에, 인력부족때문에, 잘못된 의사결정때문에
커리어에 도움 안 될 일을 할 것을 요구받을 때가 생긴다.

인기없는 개발언어로 구축된 프로젝트를 유지보수해야한다든지, 새 프로젝트를 시작하는데 트렌드에서 벗어난 기술로 만들라든지(실제로 있다).

아니면 내가 전문성을 쌓아 가고 싶은 분야(ex. Back End냐 Front End냐)나 언어(ex. Python이냐 JavaScript냐 Java냐)랑은 상관없는 일을 해야될 때도 있다.

그럴 때는 확실히 얘기해야한다.
잘못된 결정이라면 반대의견을 얘기하고, 가능하다면 그 업무를 거절하고, 불가피하게 해야한다면 적절한 보상을 요구해야한다.

이런 것 없이 아무 일이나 다 해놓고

"나는 회사가 하라는 것을 다 해줬어, 내 커리어까지 손해보면서."

"나는 회사를 위해 희생했는데, 회사는 내 희생을 몰라봐줘"

라는 식의 푸념은 무책임하다.

확고한 전문성을 키우기

하지만 위의 이야기는 내가 어떤 커리어를 원하는지 스스로 알고 있다라고 전제하고 있다
과연 그런가?

난 아니었다.
그냥 분야 관계없이 개발이라면 재밌었다.
새로운 건 새로워서 해보고 싶었고, 해봤던 건 더 잘 할 수 있겠거니 해서 좋았다.
백엔드건 프론트엔드건 가리지 않고 했다. 언어도 C#이든 Ruby든 JS든 가리지 않았다. 프레임워크도 React든, Vue.js든 Angular든 가리지 않았다.
그러나, 결과적으로 나는 모두 다 잘하는 슈퍼 닌자(ninja) 개발자가 아니라, 다 어느 정도만 할 줄 아는 개발자가 되어 있었다.

좀 늦었지만 1년전 쯤부터 나는 Front End와 JavaScript, React.js에 집중하기로 했다.
백엔드도 하지만, Node.js일 경우에 한정해서 했다.
지금 쓰는 기술들이 자신있어 질때까지, 그래서 나 이거 진짜 잘한다는 '확고한 전문분야'가 생기기 전까지는 그러기로 했다.

규모가 크고 대우가 괜찮은 회사일 수록 하나를 확실하게 잘하는 사람을 뽑는다.
다른 영역의 개발경험을 우대하는 경우도 꽤 있지만, 이것은 주 영역을 잘한다는 것을 전제로 하는 우대사항일 뿐이다.
물론 새로운 영역에 대한 관심은 개발자로서 좋은 것이지만, 먼저 나의 확실한 주특기가 있어야 한다.

문제가 있을때 '비판'을 넘어 실제 '해결'을 위한 최선을 다 하기.

어느 회사를 가든 문제 없는 완벽한 회사는 없고, 완벽한 리더도 없다.
그래서 어디를 가도 불만이 생긴다.

불만이 생길때 지금까지 나의 반응은 이랬다.

flow before

먼저 다른 사람도 그렇게 생각하는지 확인했고, 짚고 넘어가야 하는 문제라면 공론화했다.
사안에 따라 문제제기를 당사자들이 있는 데서 하기도 했고, 없는 데서 해야 하는 경우도 있었다.
부끄럽지만 비슷하게 생각하는 동료들끼리 모여 뒷담화로 끝내버리는 경우도 종종 있었다.

공론화 과정과 그 문제의 해결과정에서 내가 한 것들이 최선이었던가.

공론화 과정에서 문제 원인 제공자를 '문제' or '악'으로 규정해버리진 않았나?

문제 관계자들에게 직접적으로 얘기는 해봤나? 함께 해결방법 찾으려 충분히 노력은 했나?

비판은 했지만, 그것이 수용할 수 있는 형태였는가?

부족한 점이 많았다.

이제는 이렇게 해보고 싶다.

flow after

(아무도 공감 안 해줄때 혼자 욕 하는 건 계속 할 듯...)

달라진건 누구를 비난 하거나 탓하지 않고,
그 전에 먼저 이야기를 충분히 듣고 함께 해결책을 찾는다 것이다.
그 과정에서 나는 할 수 있는 최선을 다해볼 것이다.

그래서 해결된다면 좋고,
해결이 되지 않았고, 그것이 굉장히 중요한(critical)한 문제라면 미련없이 떠날 생각이다.
그때는 떠나야 한다는 것을 배웠다. (해결 할 수 없는 문제도 분명히 있다)

그리고 시스템(ex. 회사, 팀)을 비판할때, 나도 그 시스템의 일부라는 사실을 잊지 말자.
특히 나도 합류한지 수개월 이상이 지났다면, 나도 그 시스템이 공고화되는데 일조한 사람이다.
마땅히 나도 비판의 대상이다.
남탓, 뒷담화가 아니라 실제 해결하가위해 최선의 시도를 하자.

토론시 신중한 단어와 적절한 톤으로 얘기하기

발언에 감정을 싣지 않기

나는 그럴 의도가 아니었지만, 내가 토론에서 발언할때 감정이 격양되는 것처럼 느껴질때가 있다는 피드백을 받았다.
원래 목소리가 크기도하고, 얘기할 때 얼굴이 빨개지는 버릇이 있고 해서 그런것 같긴 하지만, 이유가 어쨋건 부적절한 발언 태도였다.
이 부분은 스피치훈련같은, 전문가를 통한 훈련을 받아볼 생각이다.

신중하게 말하기

상대가 느리게 말하는 걸 별로 안 좋아해서, 나도 말을 가능한 한 빨리 말하려는 버릇이 있다.
떠오르는 것을 바로 바로 말 하다보니 정제되지 않은 말을 하게되고, 뱉고 바로 후회하게 되는 부적절한 용어들을 쓰는 경우도 종종 있었다.

티비에서 보면 똑똑한 정치인들이나 유명인사들이 천천히 말하는데는 이유가 있었다.
공적인 커뮤니케이션은 반드시 천천히 생각을 거친 정제된 언어를 가지고 하도록 노력할것이다.

글쓴이쿠스, Qus
직업은 소프트웨어 개발자.
기술로 사회문제를 해결하는 시빅해킹(Civic Hacking)에 관심이 많고,
이것저것 생각나는 것들을 글로 정리하는 것을 좋아합니다.