9일, NDC22 행사에서 데브캣의 김한수 로직 3팀 팀장이 주니어 프로그래머를 위한 강연을 진행했다. 회사 생활 9년차까지 오며, 오래 전부터 받았던 조언들을 모아 공유했다. 시니어 프로그래머가 되어야 하는 이유부터, 회사 생활을 헤쳐나가는 데 유용할 구체적인 실무 팁까지 강연에서 소개됐다.
강연자 : 김한수
소속 : 데브캣 기술본부 로직 3팀 팀장
발표자 소개
현재 데브캣에서 <마비노기M> 프로젝트의 툴 프로그래밍을 담당하고 있으며, 주로 저작공정 개선과 관련한 업무를 수행하고 있습니다. 이전에는 <다함께 나이샷>, <Nice Shot Golf>, <이데아>, <MARVEL 배틀라인> 프로젝트에 참여한 바 있습니다.
# 시니어가 되어야 하는 이유
"프로그래머는 (기획을)구현만 잘하면 되지 않을까?"
하지만 이상적인 시니어 프로그래머란 "요구사항을 읽고 스스로 사양을 파악해, 꼼꼼히 구현할 수 있는 사람"을 의미한다. 질문에 대한 답을 말하기 전에 한 회사의 구조를 가정해 보자. 사람이 혼자 모든 일을 할 수는 없고, 모든 것을 다 잘할 수도 없다.
다른 사람이 각자의 장점을 살리고, 모여서 일하는 것이 '팀워크'다. 그렇기에 회사는 휘하에 본부와 팀, 팀원으로 조직을 분화한다. 그리고 조직장을 두고 '위임'을 하며 대표는 본인만 할 수 있는 업무를 수행한다.
그러나 조직장(팀장)의 업무는 말처럼 쉽지 않다. 하루에도 몇 번씩 인터럽트가 발생하기 때문이다. 가령 게임을 열심히 하고 있는데, 누군가 옆에서 말을 걸면 집중력이 어그러지는 것과 같다. 업무에 집중하고 있다가 갑자기 다른 업무를 봐야 한다면, 사람인 이상 일처리가 느려질 수밖에 없다.
적당히 실무자의 이야기를 듣고 문제를 위임하기에도 어려움이 있다. 책임은 확인했다는 사인을 보낸 팀장이 져야 하기 때문이다.
다른 업무도 있기에 매니저가 이전에 했던 이야기와 맥락을 일일이 기억하기는 어렵다. 하지만 책임의 문제가 있어 문제를 단순하게만 파악하고 확인했다는 사인을 보낼 수는 없다. 이 말은 즉, 프로그래머가 맥락을 스스로 정리해서 들고 가야 좋다는 의미다. 요구사항을 읽고 스스로 사양을 파악하고 정제하는 것은 매니저에게만 필요한 능력이 아닌 셈이다.
다행히 처음부터 이런 능력이 프로그래머에게 요구되는 것은 아니다. 그러나, 생각보다 이런 능력이 요구되는 시기는 빨리 찾아온다. 관리자의 입장에서 해당 문제가 중요하게 다가오는 이유는 밀려오는 이슈 정리에 대한 어려움 때문이다. 5분이면 해결할 수 있는 문제를 위해 몇 시간 동안 문서 정리를 해야 할 때도 있다.
문서 정리 없이, 곧바로 실무 선에서 빠르게 해결하면 될 문제라고 생각될 수도 있지만 이 경우에도 어려움이 발생한다. 요구 사항에 대한 분석이나 설계 없이 곧바로 코드부터 고친다면, 결국 코드가 어그러질 확률이 높고, 결국에는 코드를 처음 짠 사람이 "처음부터 다시 설계하는 게 빠르겠네"하는 상황이 온다. 프로그래머라면 익숙할 상황이다.
그렇기에 요구사항을 읽고 스스로 사양을 파악하는 능력이 요구된다. 힘든 일이지만, 꼭 필요한 업무 능력이다. 좋은 시니어 프로그래머가 하루 아침에 완성되는 것은 아니지만, 평소에도 이를 염두에 두고 업무를 진행하다 어느 순간 좋은 시니어 프로그래머로 성장할 수 있다고 김한수 강연자는 전했다.
# 구체적인 실전 팁
다음은 구체적인 실전 팁과, 회사 생활에 유용할 조언이다.
먼저 타 직군과의 커뮤니케이션에서 단순히 "이런 기술적 문제로 안됩니다" 라는 답변을 지양해야 한다.
다른 직군에서 "무엇을 하려 하는데, 이거 가능한가요?"라고 문의가 왔는데 기술적으로 어려운 상황이라고 가정하자.
김현수 프로그래머도 처음에는 "안돼요"라고 답변한 후 기술적인 설명을 덧붙였다. 하지만 이는 실수임을 알게 됐다.
나쁜 상황의 예시
타 직군은 기술적인 이야기에 관심이 적다. 설명할 때는 가능하면 기술적인 이야기가 없어도 최대한 풀어서 이야기하는 것이 좋다. 그리고 업무상 연락이 왔다는 것은 대체로 '문제'가 있었다는 것을 의미한다. 이야기 후에도 상황에 대한 변화가 없다면 담당자에겐 곤혹스러운 상황이다.
무엇 때문에 질문이 온 것인지, 다른 방법으로 도와드릴 수는 없는지 체크하는 것이 더 좋다. 이야기가 마무리됐을 때는 결과값이 있어야 한다. 최소한, 더 이상 신경을 쓰지 않아도 되는 상태가 되어야 한다. 그렇다고 진짜 불가능한 상황에서도 "된다"라는 답변을 해도 됨을 의미하는 것이 아니다.
조금 완곡한 표현과 듣는 쪽에서도 판단할 수 있는 '명확한 사유'가 필요하다. "가능하지만, 비용이 한 달 이상 걸립니다"라고 답변하는 방법 등이 있다. 아래 사진을 참고하자.
혼날 때의 멘탈 관리를 위한 비법도 언급됐다. 쓴 소리를 말하길 좋아하는 사람은 없다. 쓴 소리를 하는 입장에서도 많은 에너지가 소비된다. 그럼에도 상급자가 쓴 소리를 하는 이유는 앞으로도 대상자와 계속해서 일을 할 것이라 생각하기 때문이다. 따라서 코드나 설계 리뷰를 받는 상황에서는 허락이나 검사가 아니라 서비스를 제공받는다고 생각하면 받아들이는 입장에서 한결 나을 수 있다.
사고가 발생했을 때의 멘탈 관리는 일단 문제부터 해결하자는 마음가짐으로 접근하는 것이 좋다. 그리고 두 번 이상 재발하지 않도록 해야 한다. 한 번은 사람이니까 발생할 수 있는 실수지만, 두 번째부터는 시스템의 미비가 되기 때문이다. 시스템의 미비는 담당자가 시스템을 갖추려 하지 않았음을 의미한다.
다음은 매니저의 업무다. 매니저 업무에서는 지나가듯 들리는 이야기도 흘려 듣지 않는 것이 추천된다. "에이, 꼭 하지 않아도 되는데"라는 말도 다시 한번 생각해 봐야 한다. 정말로 하지 않아도 되는 일이라면 이야기조차 나오지 않았다. 이런 경우는 '보통 필요한 것이 있고 당장은 큰 문제가 없지만, 불필요한 리소스가 소모되고 있어 언젠가는 고쳐줬으면 좋겠다'의 의미로 해석할 수 있다.
문제 상황에 대한 시그널 캐치도 중요하다. "무슨 일 있나요?"라고 물어보는 것도 매니저의 업무다.
평소에 특정한 일감이 어느 정도의 리소스가 소모되는지, 일감에는 무엇이 있는지 리스트로 파악하고 있는 것도 중요하다. 그래야 모든 일이 언제 끝나는지 예측할 수 있다. 예상치가 있어야 마일스톤마다 정상적으로 리소스가 소모되고 있는지, 문제가 있다면 어떤 조치를 취해야 하는지 파악할 수 있다.
다만, 주의해야 할 점은 매니저의 역할을 대신해야 한다는 것이 아니란 점이다. 김한수 프로그래머는 이런 일들은 상급자와 일을 할 때 상급자의 니즈가 무엇인지, 향후 시니어급으로 올라갔을 때 어떤 능력이 필요한지 설명하기 위해 강연에서 언급했다고 설명했다.
# 회사 문서 작성 팁
구체적인 회사 문서 작성에 대한 팁도 공유됐다.
먼저 문서 작성을 할 때는 앞으로 어떤 이야기를 할지 제목부터 서술형으로 적는 것이 좋다. 남은 이야기는 개요에서 설명하면 된다. 그리고 어떠한 맥락에서 나온 이야기인지, 구체적으로 어떤 '문제 상황'인지, 그래서 최소한 어떤 것이 해결되었으면 하는지 작성하는 것이 추천된다.
해결 방안은 구체적으로 어떻게 하자는 건지, 고민되는 포인트를 포함해 적어 두면 좋다. 토론을 할 수 있도록 넘버링은 꼭 해 둬야 한다. 명시적으로 지정을 해야 논의할 때 한결 편리하다. 마무리에는 다 읽어보지 않아도 판단할 수 있도록 결론을 함께 남겨야 좋다.
보통 조직구조를 따라 위로 갈수록 정보를 압축해서 전달하는 방식이기에 문서는 두괄식으로 적고, 글머리와 들여쓰기를 적절히 활용하길 권장된다. 이야기는 단락으로 나누고, 엔터는 필요할 때마다 쳐 주는 것이 좋다. 종이보다 중요한 것은 깔끔한 문서 정리다. 최근에는 메신저와 같은 프로그램이 적극 활용되고 있기에 이 경우에는 종이를 걱정할 필요가 없기도 하다.
다음은 회의에 관한 팁이다.
회의 전에는 반드시 아젠다를 미리 정리해 가야 한다. 회의는 아이디어를 내는 자리가 아닌, 준비한 아이디어로 결정을 하는 자리다. 또한, 결정하는 자리이기에 반드시 현안에 대한 권리가 있는 결정권자가 회의에 배석해야 한다.
회의가 끝나면 회의록을 정리해 서로 다르게 이해하진 않았는지 확인하는 절차가 요구된다. 구두 논의라도 간단하게 정리해 메신저에 올려 두는 것이 추천된다.
