엔지니어의 회사 생활 101
1. Introducction
엔지니어로서 회사 생활을 하면서 격게 되는 많은 어려움들이 존재합니다.
여기 페이지는 개인적으로 회사생활을 엔지니어로서 잘하기 위해서 갖추어야 할 소양을 적었습니다.
물론 모든 사람들이 제가 써놓은 글에 대해서 동의하지는 않을거라 생각되고, 그 의견도 매우 존중합니다.
의견이 있다면 저도 생각해 볼 수 있도록 남겨 주시면 참 좋을거 같습니다.
이런 문제는 1+1=2 처럼 답이 없다고 생각되는 문제이기 때문입니다.
2. 엔지니어의 회사 생활 101
2.1 다른 엔지니어가 공격해 올때
PR을 올렸고, 리뷰를 받는 도중, 누군가 나에게 공격을 해 온다면 그것처럼 참 불편한 일도 없을 겁니다.
먼저 개인적으로 이런 문제를 구체적으로 어떻게 해결하는지에 앞서서.. 저의 기본적인 생각을 말씀드리면..
“모든 의견이든 공격이든 모두 좋은 방향으로 가고자 하는 의도가 있다” 라고 생각을 합니다.
솔직히.. 쥬니어일수록 감정적이 되는 모습을 많이 봤습니다.
자신의 코드와 자신을 일치 시키는 경향이 꽤 크거나, 너무 열정적이거나.. (항상 지나친건 안좋다고 생각합니다.)
기술적인 공격이든 뭐든 중요한건 “좋은 의도가 있다” 라는 것입니다.
일단 이런 가정을 깔고 가는게 매우 중요합니다.
그 다음으로 할 것은.. 왜 동의를 하지 않는지 기술적인 논의가 필요합니다.
단순 기술적인 논의 정도가 아니라.. 그 사람이 왜 그렇게 말하는지 정말 깊게 이해를 충분히 해야 합니다c.
단순히 stylish 해서 좋은건지, performance가 좋은건지, 아니면 개인적 취향의 문제인지, 등등..
그리고 이런 contribution을 통해서 어떤 이익을 낼수 있는지, 팀과 회사에 도움이 되는 것인지..
장기적으로 좋은 것인지, 단기적으로 좋은 것인지.. 등등..
중요한건 서로간의 의견에 대해서 서로 충분히 인지하고 있어야 합니다. (계속 같은말 반복인데.. 이게 중요하기 때문입니다.)
그리고 마지막으로 좋든 싫든.. 또는 정말로 그게 아니라고 생각할수도 있지만..
일단 결정이 내려지면, 마치 내가 내린 결정처럼 일단 따라가는게 중요합니다.
이미 내려진 결정에.. 두고두고 과거 이야기를 꺼내면서 문제를 제기하거나..
봐봐 내 말이 맞았잖아.. 이런 태도는 프로페셔널 해보이지 않습니다.
(만약 생각대로 안되었다면.. 같은 배에 탄거잖아요. 어떻게 하면 도와줄수 있을지부터 생각하는게 맞는듯 합니다. )
회사는 민주주의가 아닙니다.
되도록 그런 방향으로 가는게 좋다고 생각하지만, 어떤 리더가 중요한 결정을 내리고 끌고 갈때도 있습니다.
침묵하고 있으라는 뜻이 아닙니다.
다만 노를 저을때 앞으로 가자고 했을때 혼자서 뒤로 노를 젓고 비난하는건.. 이건 팀웍이 아니라고 생각합니다.
처음에 이야기 했듯이 모두 공감하지는 않을거라고 말씀 드렸습니다. ㅎㅎ
저는 개인적으로 팀으로 일하는 것을 중요하게 생각하기 때문에 이렇게 말씀드리는 것입니다.
2.2 퍼포먼스가 낮은 엔지니어를 봤을때
팀장으로 일했을때의 경험을 공유할께요.
퍼포먼스가 낮은 사람들은 분명히 있죠..
지속적으로 버그를 생산하거나, 결과물을 내는데 느리거나, 지나치게 복잡하거나 메인터넌스가 불가능한 코드를 지속적으로 내거나, 등등..
정말 다양한 이유로 결과물이 안좋은 사람들이 있습니다.
제 기본적인 생각을 먼저 말씀드리면 ..
단순히 한두개의 버그를 프로뎍션에서 냈다고 성과가 낮은 사람은 아닙니다.
오히려 여러 사람들이 종종 그런 문제를 야기 하고 있다면, 이건 특정 누군가의 문제가 아닌 시스템 전체의 문제로 봐야 할 가능성이 높습니다.
오히려 제가 중요하게 보는 것은 “문제의 원인” 입니다.
그리고 경험상 말씀드리면.. 퍼포먼스가 낮은 사람들로 취급되는 회사의 사람들의 그 원인을 깊게 관찰하면..
보통의 경우는 그런 엔지니어들의 문제가 아닌 케이스가 더 많습니다.
급박한 일정, 주말을 낀 배포, 개발자의 피로가 누적이 된 상태에서 시스템에 크리티컬한 업무를 하다가 실수를 하거나 ..
보통 이런 케이스들이지.. 정말로 그 특정 사람이 정말 문제가 있어서 생기는 케이스는 드물다고 생각합니다.
따라서 보통은 이런 문제들을 해결할수 있는 시스템 또는 문화를 정착시키는 것이 중요합니다.
특이 케이스 경험을 하나 공유하면, 누군가 항상 일 처리를 할때 “못하겠다” 라는 말을 입에 달고 살았습니다.
그리고 실제로도 이상한 API를 만들어내거나, 상당한 버그를 만들어내거나..
다만.. 그때 제 생각은.. 그 친구의 문제라고 생각하지는 않았습니다.
그 친구는 아직 쥬니어급인데, 시니어급의 문제를 받았고 -> 여기에서 지속적으로 퀄리티 있는 코드를 딜리버 하는데 실패했겠죠.
따라서 이건 그 사람의 문제가 아니라, 그냥 레벨에 맞지 않는 업무를 받았기 때문에 생긴 문제입니다.
단순히 넌 결과를 못냈으니까 저성과자야 이게 아니라.. 이유를 정확하게 파악하고, 개개인마다의 능력에 맞는 업무까지도 고려하는게 중요합니다.
정말로 문제가 있는 사람이 있을 수 있습니다.
이걸을 해결하는 방법은.. 따로 있지 않고.. ㅎㅎ
방법이라기 보다는 리더의 태도인데..
“어떻게 하면 도와줄수 있을까?” 가 중요합니다.
단순히 도와줄수 있을까?가 아니라.. 연구수준 정도로 왜 그런 문제가 발생하는지 파악해야 합니다.
“헤이~ 김대리~ (블라블라 안부~묻고 친근친근~)
요즘 결과물이 좀 늦어지고 있는거 같은데, 혹시 뭐가 문제인지 알 수 있을까요?
어떤 기술적인 문제가 있는지.. 아니면.. 요즘 많이 달렸던데.. 건강이 문제인지.. :)
솔직하게 말씀해주시면.. 제가 뭘 도와드릴수 있는지 찾아볼수 있을거 같아요!
그 다음도 중요한데.. 이건 많이 안하는거 같습니다.
실적이 안좋았던 이유에 대해서 문서화 시키는 것입니다.
향후 새로운 개발자가 들어와서 비슷한 문제가 발생했을때.. 참고할수 있게 되는데. .예를 들어서
“아.. 이런 문제는 전에도 있었는데 A라는 친구가 기간내에 딜리버 못했어요.”
“유사한 이유인데 B dependency 이슈였었고 여기서 나중에 알아보니 이렇게 이렇게 해결했어요~ 참고하시면 좋을거 같아요~”
여튼.. 이런식의 기록도 개인적으로 중요하다고 생각합니다.
(아.. 근데.. 스타트업에서 이정도록 체계적으로 하기는 좀 어려울거 같습니다. 회사마다 달라요)
2.3 실수로 부터 배우기
실수를 인정하는건 쉽지가 않습니다.
특히 내 실수를 인정하고 다른 사람들에게 이야기 할수 있다는건 한국 사회에서 더욱 어려운 일이고요.
누구나 실수를 할 수 있지만, 중요한건 여기에서 무엇을 배웠고, 어떻게 진보했는지가 더 중요하다고 생각합니다.
저도 많은 실수를 저질렀습니다.
한밤중에 production 배포하다가 실수 내기도 하고, 데이터 날려먹기도 해보고, 상상할수 있는 온갖 실수는 다 해본거 같습니다.
중요한건 이런 문제가 발생한 원인을 파악하고.. 배우는 것이 중요합니다.
한가지 최근의 제 실수를 공유하면 다음과 같습니다.
개인적으로 퍼포먼스를 중요시 했고, 팀안에서 어떻게 우리가 일해야 하는지 그리고 온보딩의 중요성에 대해서 크게 생각하지 않았습니다.
한번은 인턴이 왔었고, 그 친구는 매우 기술적으로 뛰어난 친구였습니다.
실제로도 들어온지 얼마 안되서 페이퍼에 있는 내용을 실제 구현하기도 했습니다.
(물론 실제 production으로 가기 위해서는 연구 수준이 아니라 프로덕션 수준이 필요하고, 이 정도 수준은 인턴에게 기대하지도 않습니다.)
문제는 다른곳에서 발생했습니다.
회사내 다른 부서의 팀장님이 오시더니.. 그 친구가 자신에게 화를 내고 갔다고 했습니다.
그리고 몇일뒤에는 다른 분도 저에게 와서 어처구니 없는 일을 겪었다면서 그 친구와 관련된 이야기를 해주었습니다.
과연 그게 그 친구의 진짜 문제였을까요?
물론 그 친구의 인성도 문제가 있지만, 부족한 온보딩 그리고 퍼포먼스를 강조했던 문화를 만든 저에게 문제가 있다고 생각합니다.
인턴이었고 이제 막 사회생활 하는 친구한테.. 연구나 일에 관해서만 이야기 했지..
좋은 문화를 만드는데 많이 부족했다고 생각이 듭니다.
그 이후 부터는 좋은 문화를 만드는데 매우 신경을 썼습니다.
우리가 어떻게 서로간에 대해야 하고, 말은 어떻게 해야 하고, 퍼포먼스도 중요하지만..
그 이전에 어떻게 하면 좀 더 재미있게 일할수 있을지, 모두 행복하게 일할수 있을지 등등을 정말 사소한 것부터 써내려가고 그런 문화를 만들수 있도록 노력했습니다.
뭔가 극적인 변화가 있었을까요?
그렇다고 크게 퍼포먼스가 좋아지거나 그런건 아니지만..
그냥 팀원들과 이야기해서 느껴봤을때는 서로 좀 더 협력적이고 도와주는 문화가 형성이 되는 것 같다는 익명 조사에서 나왔습니다.
또한 익명조사에서는 몇개월 사이안에 회사안에서의 만족감이 높아졌습니다.
실제로 팀원들이 느끼기에 기술적 도움을 주고 받는 것도 더 많아졌다고 생각하고요. (아.. 바빠서.. 이것까지 추적하거나.. 그러지는 못했습니다.)
또한 온보딩은 처음에 그렇게 신경쓰지 않았지만, 지나칠 정도로 도와주는 문화를 만드는데 많은 할애를 하였습니다.
그냥 10초만 한번 설명해주면 되는 일을, 새로운 사람이 어떻게 돌아가는지 몰라서.. 하루종일 보고 있다면 문제가 있다고 생각합니다.
또한 문화안에서도 우리가 어떻게 행동해야 하는지도 좀 더 자세하고 명확하게 만들었습니다.
자.. 제 말의 포인트는.. 제 실수가 중요한게 아니라..
개발자는 어떤 실수이던지 그것에서 배우는게 더 중요하다고 생각합니다.