서버 프로그래머? 클라이언트 프로그래머?

현재 있는 조직에서는 서버팀, 클라이언트팀 딱딱 구분지어져 있어서 서버를 하는 사람은 서버만, 클라이언트를 하는 사람은 클라이언트 코드만 보고 작업합니다. 서로 다른 파트의 코드를 참고삼아 보는 경우는 있지만 작업 영역은 칼같이 나뉘어져 있습니다.

이렇게 칼 같이 나뉘어진 조직의 장점으로는 자신의 코드 영역에만 집중할 수 있다는 점 입니다.

한가지를 깊이 파기 좋아하는 사람들한테는 이렇게 구분되어진 조직이 잘 맞을 겁니다.

반면 비효율적인 부분도 있습니다.

대부분의 컨텐츠는 서버, 클라이언트 코드가 같이 어우러져 돌아갑니다. 따라서 서버는 클라이언트를, 클라이언트는 서버를 이해하고 있어야 원활한 협업이 가능하죠.

하지만 모든 프로그래머들이 상대 분야를 잘 이해하고 있는 것은 아닙니다. 서버 프로그래머들 중에 언리얼이나 유니티 엔진을 다뤄본적이 없는 사람들도 많습니다. 클라이언트 프로그래머 역시 서버쪽에서 쓰이는 IOCP코드나 멀티스레드 환경, 다중 사용자에 대한 로직을 구현해 본 적이 없는 분들도 많죠.

따라서 각 팀에서는 원활한 작업을 위해 여러가지 방법을 고안해 내는데요, 저희 팀에서는 한쪽에서 조금 더 주도를 하는 방식으로 개발을 진행합니다.

먼저 서버 프로그래머들이 데이터 설계, 패킷 설계, 컨텐츠 로직 흐름 등을 디자인 하고 선 작업 후 클라이언트 프로그래머한테 전달하죠. 그 뒤 클라이언트 프로그래머는 전달받은 내용에 따라 클라이언트쪽 코딩을 합니다. 서버쪽에서 한발 앞서 나가는 방식 입니다.

간혹 의견 충돌도 생깁니다. 서버쪽에서는 이런 방식이 효율적이라 이렇게 디자인 했는데 클라이언트쪽에서는 납득하지 못하는 경우가 있을 수 있죠.

그리고 항상 다른 파트의 작업이 끝나기만을 기다려야 한다는 단점이 있습니다. 서버 작업이 끝나면 클라이언트가 작업하고, 클라이언트가 끝나면 서버랑 다시 맞춰보고 해야하는 것이죠.

중간에 디자인을 바꾸려면 이것도 쉬운일이 아닙니다. 나만 다시 작업하는게 아니라 상대방까지 관련있기 때문이죠. 패킷 파라미터 하나만 추가하려고 해도 최소한 두 명의 일정과 작업 시간을 고려해야 하기 때문에 개발 속도가 더디게 느껴질때도 있습니다.

그래서 처음 작업 시작할 때 최대한 신중하게 생각한 후 실제 작업에 들어가는 편이고 웬만해서는 중간에 바꾸지 않으려는 분위기가 큽니다.

개인적으로 게임을 만드는데 있어서 서버와 클라이언트로 칼 같이 구분 짓는것을 선호하지는 않습니다. 어차피 다 같은 프로그래밍 영역이고 논리적 사고 측면에서 본다면 못할 것도 없기 때문이죠. 서버쪽에서 로우레벨 네트워크 코드를 작성했던 사람이라고 컨텐츠 로직이나, 클라이언트 로직, UI코드를 못 짜는건 아닙니다. 반대로 클라이언트 컨텐츠를 담당했던 사람이라고 네트워크 코드를 이해하지 못하거나 작성할 수 없는 것은 아니죠. 회사 차원에서는 작업의 효율성을 위해 팀을 나눠놓은 것이지만 결국 소프트웨어 개발이라는 목적을 바라본다면 일부러 나 자신을 특정 영역에 가둬놓을 필요는 없다고 생각합니다.

완전히 로우한 영역(서버쪽이라면 네트워크 IO처리, 클라이언트 쪽이라면 렌더링이나 엔진 영역)만 아니라면 서로 다른 영역에 도전해 보는 것도 좋다고 봅니다. 그래야 더 시야도 넓어지고 상대방 작업에 대한 이해도 높아질 수 있기 때문이죠.

물론 저는 로우한 영역일지라 하더라도 접해볼 가치가 충분히 있다고 생각합니다. 클라이언트 프로그래머라면 네트워크 디바이스로 들어온 패킷이 어떻게 내가 만든 프로그램까지 전달 되는지, 조각 조각 들어온 TCP패킷을 어떻게 하나로 조합할 수 있는지, 네트워크가 끊겼다 붙을 때 어떤 로직이 필요한지 등을 직접 구현해 보면 좋습니다. 또한 멀티스레드 서버는 어떻게 구현 하는지, 로직에 멀티스레드를 쓰는게 좋을지, 멀티스레드를 쓴다면 락을 어떻게 잡을지, 안쓴다면 로직 구조를 어떻게 설계할지등등에 대한 부분도 프로그래머로서 고민해볼 만한 영역이라고 생각합니다.

서버 프로그래머라면 렌더링 엔진이 어떤 구조로 이루어져 있는지, 3D 폴리곤이 어떻게 2D윈도우에 렌더링 되는지등에 대해 깊이 파볼 수 있습니다. 유니티나 언리얼을 이용하여 로직을 구현해 보면서 서버와 어떻게 연동하는게 효율적인지, 어떻게 하면 클라이언트 프로그래머가 쓰기 쉽게 만들어줄 수 있는지 등을 고민해 볼 수 있죠.

이렇게 내가 맡은 분야 외의 기술들을 깊게 연구해보면 여기서 또 얻어갈 것들이 많이 생깁니다. 서버쪽 네트워크 영역은 대량의 트래픽과 데이터를 어떻게 효율적으로 분배하고 저장할까에 대한 고민을 하는 것이고,

클라이언트쪽 렌더링 영역은 수많은 픽셀 연산을 어떻게 효율적으로 해서 프레임을 잘 나오게 할까에 대한 고민을 하는 것이죠. 이 둘은 따지고 보면 비슷합니다. 둘 다 대량의 무언가를 효율적으로 처리하는 것에 대한 문제이기 때문입니다.

로직 부분도 마찬가지 입니다. 서버쪽에서 다중 사용자를 고려한 로직을 작성하다 보면 클라이언트쪽 코드에서 조금 더 안정성을 높일 수 있는 코드를 작성하는데 영감을 얻을 수 있습니다. 반대로 클라이언트에서 쓰는 여러가지 기법들이나 엔진 코드를 살펴보다 보면 서버쪽 로직 코드에도 적용할 수 있는 부분이 많이 있습니다.

저는 어느 한 분야의 지식을 어느정도 쌓아온 후에는 다른 분야로 넘어가서 또 그걸 연구하는 걸 즐겨했습니다. 사람에 따라서 깊이있다고 느끼는 정도는 다를 수 있지만 저는 최소한 상용 소프트웨어를 개발하고 서비스할 수 있는 수준까지는 두루두루 익혀왔던것 같습니다.

그래서 그런지 처음 부터 끝 까지 게임 하나를 만들어라 하면 자신 있지만, 구글과 같이 엄청나게 많은 사용자의 트래픽을 안정적으로 처리해 봐라 라고 하면 솔직히 머릿속에 확신있게 떠오르는 디자인은 없습니다. 또 2D, 3D 렌더링 원리에 대해서도 이해하고 있고 셰이더 코드도 다룰 줄 알지만 언리얼 엔진의 렌더링 시스템을 개선해 봐라 라고 하면 자신있게 코드를 짤 수는 없습니다. 이정도 까지 가려면 더 연구할 시간이 필요하고 어떻게 보면 제 능력으로는 불가능한 영역일 수도 있습니다.

결론은 자신이 현재 하는 주요 분야는 있겠지만 그 영역 안에서만 머무는 것 보다 더 넓게 바라보자 입니다.