• 주제: 언젠가 시니어가 될 주니어를 위하여
  • 강연자 : 김한수 - 데브캣 / devCAT
  • 발표분야 : 커리어
  • 권장 대상 : 주니어, 프로그래머
  • 난이도 : 사전지식 불필요 : 관련 전공이나 경력이 전혀 없더라도 이해할 수 있는 내용

    • [강연 주제] 어떻게 하면 주니어가 시니어 프로그래머로 성장할 수 있을까요? 회사생활 9년차. 회사 공인의 시니어 프로그래머가 되기까지 겪어보니 정말로 유용했던 조언들을 이제는 여러분에게도 공유 드리고자 합니다. 시니어 프로그래머가 되어야 하는 이유부터 회사 생활을 헤쳐나가는 데 유용할 구체적인 실천 팁까지 준비 해보았습니다.


    채용이라는 게 항상 그렇지만 시니어급을 뽑는다는 건 일반 채용보다 조심스러운 면이 있다. 더 높은 파급력을 지닌 사람을 채용하는 것이기 때문이다. 그만큼 게임 업계에서 시니어급 인사를 외부에서 수혈하기란 생각보다 쉬운 일이 아니다.

    이에 데브캣 기술본부 로직 3팀 김한수 팀장은 외부에서 사람을 뽑기 힘들다면 내부에서 인재를 성장시킬 순 없을까라는 생각을 했다. 과연 어떻게 하면 주니어 프로그래머가 이상적인 시니어 프로그래머로 성장할 수 있을까.

    그는 이번 NDC 강연을 통해 실제 9년간 회사 생활을 하며 디딤돌이 되었던 조언들을 공유했다. 단순히 뜬구름 잡는 두루뭉술한 이야기보다는, 주니어 프로그래머들이 시니어로 성장하는 데 도움이 될 만한 구체적인 팁을 전달했다.


    시니어가 되어야 하는 이유

    언뜻 프로그래머는 구현만 잘하면 되는 게 아닐까 생각하곤 한다. 하지만 아니라는 걸 다들 알 테다. 이상적인 시니어 프로그래머란 요구사항을 읽고 스스로 사양을 파악해서 꼼꼼히 구현할 수 있는 사람이라 정의할 수 있다.


    여기서 요구사항을 읽고 스스로 사양을 파악한다는 건 무엇을 의미하는 걸까. 실제 채용 공고에서도 예상과는 다른 항목을 강조하고 있다. 사양, 설계의 오류를 찾아낼 수 있을 뿐 아니라 토론을 통해 개선을 이끌어 낼 수 있는 사람, 복잡한 문제에 대해 간결한 해결책을 찾아낼 수 있는 사람 등의 항목 등이 있다.

    왜 이런 능력을 필요로 하는 건지, 프로그래머는 구현만 잘하면 되는 게 아닌가라고 생각할 수 있다. 하지만 이는 회사가 일하는 방식과 관련이 있다. 사람이 혼자 모든 일을 하거나 다 잘할 수는 없다. 서로 다른 사람이 각자의 장점을 살려 모여서 일하는 만큼 팀워크가 필요하며, 그 관리를 팀장이나 조직장 등이 권한을 위임받아 하게 된다. 다만 이론상 그럴 뿐, 말처럼 쉽지는 않다.


    가장 힘든 건, 이야기를 듣는 것이다. 이벤트가 비정기적으로 발생하기 때문이다. 꼭 팀원들이 아니더라도 팀내외에서 하루에도 몇 번씩 인터럽트가 발생한다. 일은 평소보다 더 집중한 상태에서 하게 된다. 그런데 그 상태에서 한 번에 전환한다는 게 여러 가지 면에서 힘든 편이다. 책임을 져야하는 일이기에 대충 듣고 OK를 할 수도 없다.

    그 밖에도 매니저의 업무는 참 많다. 굉장히 많은 일들이 있지만 짧게 정리를 하자면 팀 내외로 레이더를 돌리고 있다가 시그널이 발생하면 적절히 처리하는 일을 한다. 더해서 누구 주기 좀 애매한 일들은 직접 담당하기도 한다. 일을 정리해서 주는 것 자체가 일이기도 하고, 팀장 레벨에서는 어느 정도 실무를 진행해야 업무를 파악하기 편해서 그런 것도 있다.

    그렇기에 매니저 쪽에서 이전 이야기를 일일이 기억하는 건 거의 불가능하다. 그럼에도 책임을 매니저가 지니까 대충 OK할 수도 없다. 결국 맥락을 스스로 정리해서 들고 가야 한다. 물론 요구사항을 읽고 스스로 사양을 파악하고 정제하는 건 꼭 매니저에게만 필요한 능력이 아니다.


    처음부터 이런 능력을 요구하는 건 아니지만, 생각보다 이 시기가 빨리 온다. 그렇게 처음 벽에 막히는 때가 오면 뭘 더 잘해야 되나 싶을 것이다. 그만큼 이슈 정리하는 게 정말 힘들다. 코드는 5분이면 고칠 것 같은데, 문서 정리를 두 시간 째 하고 있으면 '문서 정리를 안 하고, 코드를 고치면 될 일 아닌가'라는 생각이 든다. 하지만 요구사항에 대한 분석이나 설계 없이 코드부터 고치기 시작한다면 어떻게 될까. 당연히 엉망이 된다.

    요사항을 읽고 스스로 사양을 파악하는 게 힘든 일인 것은 맞다. 그럼에도 반드시 필요한 일이다. 또한 좋은 시니어 프로그래머는 하루아침에 완성되지 않는다. 충분한 트레이닝이 필요하고, 평소 업무에서 하루 이틀 경험을 쌓아가는 것이 필요하다.


    그래서 구체적으로 뭘 어떻게 하면 되나요?

    구체적으로 주니어 프로그래머가 시니어 프로그래머가 되려면 어떤 점이 달라져야 할까. 전체적인 키워드는 '눈치'다.


    그 중 가장 중요한 건 타 직군과의 소통이다. 주의해야 할 부분들이 몇 가지 있는데, 설명 시 가능하면 기술적인 이야기를 최대한 줄이고, 어떤 문제로 연락을 해왔는지에 대해 판단해야 한다. 마지막으로는 이야기가 끝났을 때 결과가 보여야 한다. 최소한 일을 했다고 말을 하려면 문제가 해결되었거나, 해결할 계획이 생겼거나, 더 이상 신경 안 써도 되는 상태가 되어야 한다.

    그래서 한때는 '안돼요'라는 말 자체를 쓰지 말자는 이야기가 있을 정도였다. 그렇다고 안되는 것을 무조건 된다고 하는 건 거짓말이지 않나. '안돼요' 대신 쓸 수 있는 표현이 몇 가지 있다. 가능하지만 그에 들어가는 코스트를 전달하거나, 가능할지 잘 모르겠다고 하거나, 대안을 제안하는 방법 등이다. 제일 중요한 건 불가능한 사유를 설명하는 것이다. 굳이 따지자면 똑같이 안된다는 이야기지만, 분명 차이가 있다. 일을 이어나갈 수 있게 좀 더 디테일한 정보를 제공하기 때문이다.


    업무 시 멘탈 관리도 매우 중요하다. 싫은 소리 하는 걸 좋아하는 사람은 아무도 없다. 그럼에도 매니저 급이 싫은 소리를 하는 건 앞으로도 계속 함께 일을 할 것이라 생각해서다. 그러니 결과물에 대해 평가를 받을 때는 허락이나 검사가 아니라 서비스를 받는다고 생각하는 게 좋다.

    뭔가 사고를 쳤을 경우에는 일단 문제부터 해결하자는 마인드로 접근해야 한다. 허둥지둥하는 건 수습하는 데 아무런 도움이 되지 않는다. 한 번은 사람이니까 할 수 있는 실수고, 두 번부터는 시스템이 없어서 그런 것이다. 다만, 문제가 두 번 이상 재발하지 않도록 해야 한다.


    매니저는 어떤 업무를 해야 하는지에 대해서도 짚고 넘어가려 한다. 가장 중요한 건 맥락 파악 및 요구사항 정제다. 지나가듯 하는 이야기를 흘려 들으면 안 된다. 진짜 하지 않아도 되는 일을 굳이 비지니스 관계에서 언급하는 경우는 없다.

    문제 상황에 대한 시그널 캐치도 해야 한다. 누구나 열심히 건의사항을 올리는 게 아니기에 먼저 무슨 일이 있는지 파악하는 것도 매니저의 업무다. 기존에 이런 일을 서로 간의 인간적인 관계하에 해왔다면, 매니저가 되면 업무의 일환으로서 이런 것들을 먼저 나서서 챙길 필요가 있다.

    일감에 대한 현황 파악 역시 중요하다. 평소에 이 정도의 일감은 이 정도가 걸린다는 것을 항상 감을 잡고 있어야 한다. 또한 모든 일을 리스트로 파악하고 있어야 한다. 그래야 모든 일이 언제 끝나는지를 알 수 있다. 예측이 정확할 수는 없지만, 예상치라는 게 있어야 플랜을 세울 수 있다.


    이외에도 멋진 시니어가 되려면 문서 작성 능력도 반드시 키워야 한다. 개요 부분에서는 앞으로 어떤 이야기를 할지에 대해 보여줘야 하며, 문제상황을 나열할 때는 반드시 어떤 맥락에서 나온 이야기인지 구체적인 지점과 '누구' 의 이야기인지 적어줘야 한다. 목표에 대해 이야기할 때는 최소한 어떤 것이 해결되었으면 좋겠는지, 개선 제안 시에는 구체적으로 어떻게 하자는 것인지를 언급해야 한다. 그리고 토론을 위해 넘버링을 해야 하고, 다 읽지 않더라도 판단할 수 있도록 결론을 함께 남기는 것이 좋다.

    다음은 회의 관련 팁이다. 회의 전에는 아젠다를 미리 정리해 가야 시간을 낭비하지 않는다. 또한 회의는 아이디어를 내는 자리가 아니라, 준비한 아이디어로 결정을 하는 자리기에 반드시 결정권자가 함께해야 한다. 마지막으로 회의가 끝나면 회의록을 정리해야 하는데, 이는 서로 다르게 이해하지 않았는지 확인하는 절차로써 필요하다.