개발자에게 좋은 직장 혹은 좋은 환경

Posted by on

직업이 뭐냐고 물어보면 “개발자”라고 서슴없이 이야기한다. 개발하는 직장인으로써 “행복하십니까?” 라고 질문한다면 나의 답은 “행복합니다.” 이다. 하지만 “행복”이라는 단어에 고민이 있다. 나는 직장인으로써 행복한 것인지 아니면 개발자로써 행복한 것인지. 혹은 둘다에서 모두 만족과 행복을 얻고 있는 것인지.

전 직장인 네이버에서 일할때도 초반에는 이런 행복이라는 단어를 이야기했다. 그때도 개발자로 시작을 했지만, 성과를 인정받고 일을 리딩하는 팀장이 됐다. 리더는 이럴 것이다라는 나의 자화상과 팀원들의 기대를 섞은 형상이 되기 위해 최선을 다했다. 결론적으로 행복하지 못했다. 팀장, 리더라는 직책을 가진 직장인으로 행복하지 못했고, 개발할 시간을 1도 갖지 못한 개발자로써 행복하지 못했다. 더욱 심각한 문제는 나만 행복하지 못한게 아니라 함께 일하는 팀원들도 행복하지 못했다. 그리고 3년 반전에 현재의 라이엇 게임즈로 이직했다.

이직 후 현재까지 개발자로써 행복하다. 물론 라이엇 게임즈에서도 개발 리더의 역할을 하고 있다. 그리고 앞서 이야기한 것처럼 행복하다. 이 나이에 실제 코딩을 하고 있고, 과정에서 미처 몰랐던 것들, 새로운 것들을 계속 배우는 즐거움이 있다. 그리고 나이먹었다고 굳이 봐주지 않는 까칠한 동료들이 있다. 나는 내 기술과 경험과 코딩으로 사용자들이 실제 사용하는 시스템을 만들고 있고, 좋은 동료들의 도움으로 발전하고 있다. 더구나 새로움에 도전한다고 뭐라하는 말도안되는 거버넌스 같은 것들이 없다. 개발자에게 이만큰 좋은 환경이 있을까? 이렇든 저렇든 코딩을 직접하는 회사에서 이만큼의 행복한 조건을 찾을 수 있을까? 내가 보기에 감히 개발자에게 최고의 환경이다.

라이엇이 좋다고는 했지만 그럼 개발자에게 행복한 직장 환경은 뭘까?

개발이라는 직군(Discipline) 관점에서 살펴보자.

  • 능력이 아닌 실제 코딩 – 어떤 직책(Role)에 있던 개발 직군에 있는 사람은 코딩을 해야한다. 중요한 점은 할줄 아는 능력이 아니다. 실제로 코딩을 해야한다. 자, 먼저 여러분들의 주변을 둘러보자. 코딩보다는 문서를 만들고 있거나, 회의를 하고 있는건 아닌가? 혹은 의미없는 이메일 놀이? 본인의 시간을 코딩하는데 쓸 수 있어야 코딩을 할 수 있다. 그리고 코드를 통해 본인의 존재감을 인정해줄 수 있는 조직 문화가 있어야 한다. 회의에서 한마디 말을 하거나 문서/이메일 쓰레드에 자신의 필력을 발휘해야만 존재감을 인정받는다는 생각을 하는 소위 관료주의적 문화가 있다. 이런 문화는 개발자가 코드로 기여하기보다는 정치질하기 쉽다. 코드짤 시간도 인정하지 않고, 회의에서 말 한마디 못한다고 갈구는 분위기이고, 본인은 개발자로 남길 원한다면 그 조직에 오래 남을 이유는 없을 것 같다.
  • 피드백 줄 수 있는 동료 – 코딩은 글쓰기랑 비슷하다. 글쓰기 능력을 높이는 좋은 방법은 2가지 다. 첫번째는 많이 써보는 것이고, 두번째는 쓴 글을 다른 사람들과 돌려 읽는 것이다. 다른 관점에서 살펴본 피드백은 좋든 안좋든 본인이 작성한 내용을 뒤돌아보게 만든다. 코딩도 마찬가지로 피드백이 있을 때 더 빠르게 발전할 수 있다. 코딩의 피드백을 가장 잘 줄 수 있는 사람은 같은 일을 하는 개발자다. 같은 일을 하고 있기 때문에 코드의 목적을 공유하고 있고, 다른 관점에서 제대로 코드의 문맥이 제대로 읽히는지 봐줄 수 있다. 개발 시간은 3개월이더라도 완성된 코드는 6개월, 1년 혹은 몇년 동안 운영된다. 과정에서 변경은 필수이고, 변경할려면 제대로 읽혀야 한다. 제대로 읽히는지 피드백을 주는 동료가 있다면 그만큼 읽힐 수 있는 코드, 품질 높은 코드를 작성할 기회가 더 많아진다. 자신보다 잘하든 못하든 상관없이 진심으로 읽고 주는 피드백은 충분히 값어치를 한다.
  • 도전 – IT 환경만큼 빠르게 변화하는 세상이 없다. 개발 환경 뿐만 아니라 사용자 환경도 마찬가지다. A 기능이면 만족하던 사용자들이 AAAAA 기능이 아니면 안된다고 하루 아침에 돌변한다. 바뀐 환경에 대응할려면, 본인이 가지고 있던 밥그릇을 버려야 할 때도 있다. 어떻게 해야할까? 개발자라면 도전해야한다. 밥그릇이 아닌 접시를 원한다면 이제 접시를 만들러 가자. 새로움에 도전하는 사람이 있다면 응원과 관심이 필요하다. 성공하든 깨지든 과정의 경험은 도전한 사람에게 값진 경험으로 남는다. 도전이 일상이 될 때 혁신이 이뤄지고, 조직은 더욱 발전한다. 개인의 도전을 장려하고, 그 과정 혹은 결과를 조직 발전의 밑거름으로 삼으려는 조직에 있어야 개발자로써 더 나아갈 수 있다.
  • 성장 – 개발이라는 분야만큼 빠르게 변하는 동네는 없다. 자고나면 새로운 기술과 언어 그리고 프레임웍이 등장한다. 한국에서는 자바(Java)랑 스프링만 해도 충분해… 라는 생각을 가진 개발자들이 현실적으로 많다. 사실 그닥 틀린 말은 아니다. 하지만 이런 마인드가 ActiveX를 욕하면서 아직도 걷어내지 못하고 있는 것이다. Frontend와 Backend의 분리, Microservice Architecture, Cloud 등등이 최신 기술이라고 이야기하던 때는 이미 1~2년 전에 지났다. 프로토콜 관점에서도 세상은 이미 HTTP/2를 향해 나아가고 있고, Serverless와 AI, Machine Learning을 현실과 어떻게 접목할 것인가를 고민하는 시점이다. Java 언어 자체도 Imperative feature보다는 lambda를 필두로 functional language 관점이 주요 발전 뱡향으로 자리잡았다. 또 9 버전 이후 module 방식의 packaging 방식의 변화를 가져오고 있다. 이것들을 종합해보면 Concurrent 환경의 안전한 코딩과 빠른 실행을 담보하기 위한 체계로 전환해야 한다고 이야기하고 있다. 그럼에도 불구하고 당신의 조직이 “이걸로도 충분해” 라고 안주하고 있나? 성장하는 조직이라면 새로움에 대한 탐색과 이를 도전적으로 적용해보고 그 값어치에 대해 논의할 수 있는 것을 장려해야 한다. 이런 논의가 없다면 고인물이 되고, 시간이 흐르면 썩어버린다. 썩은 물은 두말할 필요없이 주변을 오염시킨다.

팀장이나 아키텍트라는 타이틀을 가진 사람들이 흔히 “내가 옛날에 해봤는데 말이야…” 라는 말을 내뱉는다. 옛날 언제? CPU가 1 Core였던 호랑이 담배피던 시절에? 혹은 “오라클 DB면 다 되네..” 라고 감탄하던 시절에? 바뀐 환경과 바뀐 프로그래밍 패러다임을 이해하지 못하는 사람과 함께 일하는 건 불행이다. 넓은 식견과 경험을 변화된 환경에 최적화된 코딩으로 녹여내기 위해 노력해야한다.

우리는 이런 노력이 결실을 맺기 위해 피드백을 주고, 시간을 줄 수 있어야 한다. 이 과정을 통해 성장한 사람이 결국 조직 구성원들에 영감을 준다. 이런 한 사람 한 사람의 노력이 모여 개발자 조직의 성장을 이끈다.

개발자라는 직장인 관점에서 행복한 직장 환경은 뭘까?

Good

  • 실행 가능한 비전과 목표 – 뜬구름잡는 듯한 구호는 의미가 없다. 비전과 목표는 실행 가능한 아젠다를 도출할 수 있어야 하거나, 무엇을 실행할지에 대한 지침이 되어야 한다.
  • 공유 – 무언가를 실행할 때 기술적이든 업무적이든 정보가 필요하다. 이런 정보가 투명하게 공개되고, 원할 때 찾아볼 수 있는 형태로 존재해야 한다. 그리고 다른 사람들에게도 이런 정보가 있음을 알려줘야 한다. 그래야 혼선을 최소화할 수 있고, 빠른 업무 진행이 가능하다.
  • 성취와 축하(Celebration) – 어떤 일이 됐든 방점이 없는 일은 사람을 지치게 만든다. 반드시 우리가 이 목표를 달성했다라는 성취감을 느낄 수 있어야 한다. 이 성취감을 통해 다음번 고지를 향해 나아갈 수 있는 자신감을 얻을 수 있다. 그리고 그 성취를 모두가 함께 축해해줘야 한다. 개인의 성취보다는 우리 혹은 팀의 성취가 되어야 하고, 그 성취를 조직의 모든 사람들이 다 같이 축하해줄 수 있어야 한다. 이런 시점에 회식은 꿀맛이다.
  • 실패 – 2보 전진을 위한 1보 후퇴다. 누구나 실패할 수 있다. 하지만 실패를 통해 배운 교훈이 있고, 이 교훈이 다음번 일을 하는 발판이 되어야 한다. 가장 어이없는 건 실패를 실패 자체로 비난하는 것이다. 이러면 누구도 두려워 일을 못한다. 아마도 성공할만한 일만 골라서 하지 않을까? 실패에서 팀이 어떤 Lesson and Learn이 있었는지, 그리고 같은 실수를 두번 되풀이하지 않기 위해 어떤 방식으로 다음번 일을 준비하는지를 봐야한다.

Bad

  • 경쟁 혹은 사내 정치 – 누구를 위한 경쟁인가? 아이러니컬하게도 사람은 3명 이상만 모이면 정치질이라는 걸 하게 되있다. 성과 중심적인 직장내에서는 특히나 이런 정치질이 심각하다. 내가 남보다 잘해서 성과를 받기 보다는 남을 깍아내려 상대적인 우위를 점하기 위해 이런 짓을 하는 경우가 심심치않다. 일에 대한 값어치는 “고객, 동료”들에게 평가받아야 하지만, 의도적인 깍아내림은 조직을 좀먹는다.
  • 단기성 금전적 인센티브 – 성과에 대한 보상으로 인센티를 왕창주면 어떻게 될까? 그리고 다음번 평가시에 이만큼의 인센티브를 받지 못하게 되면 어떻게 생각할까? 그리고 왕창 인센티브를 받지 못한 다른 팀 혹은 구성원은 어떤 생각을 가지게 될까? 결국 인센티브를 받을만한 일들만 골라서 구성원들이 할려고 든다. 왕창받지 못한 사람은 저성과자라는 인식을 스스로 하게 되거나, 혹은 성과 불평등에 대해 이야기하기 시작한다. 그리고 자신만이 높은 성과를 받기 위해 인위적으로 정보를 숨기거나 협업을 말 그대로 방해한다.
  • 회의(Meeting) – 회의는 말 그대로 여러 사람이 같이 머리를 맞대고 논의하기 위한 자리이다. 그리고 그 자리에선 대부분 결론이 도출되야 한다. 하지만 본인의 존재감을 드러내기 위해 회의에 들어온다. 하지만 그닥 참여한 의미는 없다. 되려 회의 시간만 길어진다. 최악의 회의 결론은 다음번 회의를 하자라는 것이다. 이런 회의가 비일비재하다. 회의가 소집되었다면 회의록이 있어야 하고 결론이 도출되어야 한다. 그리고 관심있는 사람들에게 회의록이 공유되면 된다. 본인의 소중한 1시간을 허비할 필요는 없이, 관심있다면 회의록을 살펴보면 된다.

불행한 직장인은 누구일까? 아마도 매일 매순간을 성과에 얽매여 두려움에 사는게 아닐까 싶다. 성과라는 것을 아예 고민하지 않을 수는 없다. 개인적인 주관이지만 개발직군에 있는 직장인으로써 이런 성과에 직접적으로 연연하기보다는 본인의 성장이 성과와 자연스럽게 연결될 수 있는게 최선이 아닐까 싶다.

본인 성장을 이룬 다는건 주변의 협조없이는 불가능하다. 그리고 조직내에서 이런 협조는 조직의 문화와 직접적으로 관련되어 있다. 그리고 궁긍적으로 이런 문화가 유지되고 발전되는건 그만큼 조직장 혹은 리더의 역할이 중요하다. 다행스럽게도 라이엇게임즈 코리아에는 이를 강력하게 지원해주는 리더십이 있다. 물론 이런 리더십을 뒷배경으로 각 개인이 열심히 하는 부분들이 있기 때문에 문화가 유지 발전되는게 아닐까 싶다.

새로운 2019년이 시작되었고, 앞으로도 기술 및 개발 조직 문화가 발전될 수 있는 환경이 되도록 일조해야겠다.