돈받고 일한지 벌써 8년여가 되었습니다.
그리고 현 직장에서 지낸지 5년이 되어갑니다.
지금하는 업무는 계속 게임서버를 개발하고 관련하여 필요한 전반적인 서버파트 업무를 수행합니다.
아키텍처 설계에 참여하고 API 개발을 하고 배치프로그램을 만들어 랭킹,추천 정산같은 것을 하고.
이렇게 5년정도 일을 하다보니 여러 사람들과 일을 하며 게임이라는 도메인에 대한 이해도가 꽤 생겼습니다.
어떤 것은 실시간 처리로 진행해야하는지,
어떤 것은 배치로 처리해야하는지,
어떤 것은 부하를 분산하기 위해 사용자의 화면에 연출등을 통해 서버의 API 를 분리해야하는지.
어느정도 도메인에 대한 이해가 생기다보면 업무 자체를 추상화하여 고도화하는데까지 신경을 쓰게 됩니다.
게임내 미션, 퀘스트, 업적... 다양한데 추상화해서 업무를 보면 해야할 것은 단순합니다.
1. 사용자가 어떤 액션을 취하고.
2. 그 액션이 어떤 목표를 도달하고.
3. 그에 따른 보상을 받을 수 있게.
각각의 API 는 달라질 수 있지만 서비스는 단순해질 수 있고, 모델을 설계할때도 염두에 두면 재사용성이 좋은 코드를 작성할 수 있습니다.
하지만 각각의 컨텐츠를 담당하는 기획자는 다를 수 있고 그에 따라 각기의 요구를 할 수 있습니다.
각자의 의견을 함께 고민하고 역으로 추상화할 수 있는 부분에 대해 설득하고 제안한다면 충분히 유관 동료들은 이를 이해해줍니다.
의도와 부합하기 때문입니다.
예전에 있었던 일 중에는 게임내 친구간에 쪽지를 주고받는 것에 일일 횟수 제한을 두고 싶다는 기획내용이 있었습니다.
개인적으로는 게임 내에서 커뮤니케이션은 매우 중요하다고 생각을 했고, 이를 제한을 두는 것에 대해서 회의적이었습니다.
해당 기획자에게 혹시 특정 사용자가 폭탄 쪽지 같은 것을 쏘는 것에 대해 막기 위함인지를 물었습니다.
정확하게 해당 의도로 제한을 두고 싶다 하였고,
이를 그러면 일일 횟수로 제한을 할 것이 아니라, 마지막 쪽지를 보낸 시간을 기준하여 시간 제한을 두면 어떻겠냐는 역제안을 하였습니다.
해당 기획자는 이를 수용해주었습니다.
사실 게임내 사용자 커뮤니케이션 도모라는 의도는 설득용이었고
개발자 입장에서는 매번 쪽지 발송 API 에 대해 하루 동안의 쪽지 수 count 를 체크하기도 번거로웠어서
(동시성 이슈등으로 번거로운 코딩을 할 수 있기도 하며, 매 번 각 사용자의 하루 동안의 쪽지 수를 count 하기엔 해당 테이블에 부하를 주지 않을까란 걱정도..)
이를 단순히 마지막 생성된 쪽지의 발행 시간만 체크하기가 상대적으로 코딩하기가 쉬웠기 때문이기도 합니다.
때문에 저는 코딩을 하기 전에 유관 동료들과 많은 대화를 나눕니다. 클라이언트 개발팀, 기획팀, 사업팀, 때론 디자이너팀까지.
소위 주니어 때에는 유관 동료들이 이해하기 힘든 프로그래밍 용어로 어려운 상황을 그대로 어렵게 표현하였다면
이제는 조금 더 그들이 이해할 수 있는 상황을 예로 그들과 함께 문제를 해결할 수 있는 부분을 찾아봅니다.
개발자는 무언가 자신만의 공간에서 자신만의 문제 해결을 위해 집중한다라는 얘길 듣기도 했는데,
엔지니어가 아닌 프로그래머는 문제 해결을 위해 유관 동료와 정말 많은 대화를 해야하는 직업이 아닐까, 생각해봅니다.