제목 그대로 입니다. 제가 이제 곧 군대가야대서 군대가기전에 진로를 확실히 정해놓고 갈려고 여러 분야를 찾던 도중에 서버 프로그래머라는 직종을 발견 햇습니다. 사람인에 들어가서 키워드 그대로 쳐봣더니 거의 게임이 더군요 하도 게임이 박봉이니 야근 제일 많다니 이런 소리를 많이 들어서,..게임은 이상하게 기피 하게 되서요
90년대, 2000년대는 업무 환경이 Client-Server 환경이 주류였고, 이를 위한 Client, Server 프로그램 개발을 했기 때문에 Server Programmer가 필요했습니다. 프로그래밍 잡지에서는 이들을 빨리 만들기 위한 비베, 델파이 같은 RAD툴 소개가 넘쳐났던 시기입니다.
그런데, 웹이 퍼지면서 이게 다 웹으로 바뀌어 버립니다. 사무실의 작업들은 대부분 컴퓨터에 높은 부하를 주지 않고 결과만 정확하면 끝이고 웹은 이전과 비교할 수 없을 정도로 UI를 쉽게 바꿔버릴 수 있고 서버는 기존에 만들어진 웹서버 있고, DB 넣는곳만 좀 손보면 되니 기존의 Client-Server 환경보다 개발 속도가 훨씬 빨라졌습니다. Server-Client 환경에서는 특히 Client쪽에서 OS버전이나 같이 깔린 프로그램들 때문에 호환성 문제도 꽤나 많았는데 웹이면 그거 걱정할 필요도 없고요. 웹도 처음에는 웹으로 구현 불가능한것을 구현 가능하게 할려고 activex로 도배해버려서 욕 듬뿍 먹었는데, 최근 추세는 웹을 표준화하고 다양한 기능을 집어넣어서 어느 브라우저를 실행시키는 일반 프로그램과 구별이 안갈 정도로 만들 수 있도록 하고 있습니다.
근데 게임은 이거 안됩니다.
일단 게임은 서버든 클라이언트든 시스템 부하 많이 잡아 먹습니다. 서버도 한두명 들어와서 노는거면 처리할거 얼마 안되는데, 서버당 접속자수 최대한 많이 밀어넣는게 게임업체 노하우입니다. 서버가 많아질수록 게임업체 입장에서는 매달 나가는 돈이 많아지고 관리해야 할 포인트도 많아지니까요.
게임 아닌 다른 서버 프로그래밍 원한다면 SI 보시면 되실겁니다. 과거 서버프로그래머의 자리 자바에 전자정부프레임워크 등등 머시기 올리고 DB설계하고 화면 찍고, 과거 Server-Client 개발자리가 다 이걸로 엎어졌습니다.
아마 지금 Server Programmer가 있는 자리는 대충 이정도 일겁니다.
- 시뮬레이션 (ex: 기상청 등)
- 영상분야 (제가 있는 CCTV 분야도 그렇죠. 실시간 카메라 여러대의 영상은 웹으로 감당 안됩니다.)
- 임베디드 (요건 최대한 저사양으로 많은 기능 뽑아내는게 관건이라.)
server-client 환경일때는 client가 말썽 많이 일으켰죠. client를 돌리는 컴퓨터들이 환경이 제각각이라 업데이트하면 내자리는 문제없는데 쓰는곳에서는 뭔 이슈 터지고 이거 해결하느라 밤새고 (안드로이드 앱 만들어보면 아실겁니다) 기능 업데이트나 ui 수정에도 손봐야 할 코드들 정말 많고, client 업데이트 내놨더라도 기존 업데이트 안한 유저가 있다보면 이들까지 감안해야 하기 때문에 server 쪽도 복잡도가 올라갔습니다.
web이면 이 문제 없습니다. 브라우저만 있으면 어디서든지 똑같은 화면을 다 쓸 수 있는데다가 프레임워크, 라이브러리들이 많이 발전하면서 수정이 쉬워져서 업무처리는 다 web 입니다.
게임은 반응시간이 최대한 빨라야 해서 어쩔 수 없이 server-client 구조 유지하는거고요.
임베디드쪽은 rs232 rs485 다루는 곳은 web protocol 올리기에는 통신하는 장비들의 사양이 떨어져서(감당 안되는 경우 많음) 임의로 정한 수byte~수십byte 크기의 바이너리로 통신하는 경우가 많은데 이때도 직접 코드 짜야죠.
안드로이드 앱 연동 개발할때도 서버 따로 만드는 경우 드뭅니다. 안드로이드 환경에서 json, xml과 http 통신 라이브러리 제공하고 있어서 이걸 활용하고 서버는 웹서버 하나 세팅해서 앱용 데이터 올려버리면 서버프로그램까지 따로 만들 필요 없으니 요새는 다 이방식으로 하더군요. 다만 게임 앱이면 반응시간 때문에 서버도 개발하고, 앱도 소켓 직접 다룹니다.
크... 5년전 글을 지금은 제대하고 편입을 했습니다.. 백엔드쪽으로 진로를 잡았구용 대학 가기전에는 임베디드도 생각해 보고 게임서버도 생각해 봤는데 조금씩 경험을 해보니 전 백엔드쪽이 좀 더 맞았습니다. 포폴도 준비중이니 나중에 한번 웹 오픈하면 여기에 검증 부탁드려 볼게용
전 게임 서버 프로그래머로도 일해보고, 다양한 서버 프로그래머로 일해왔는데, 약간 다른 의견을 갖고 있습니다.
"브라우저만 있으면 어디서든지 똑같은 화면을 만드는", 혹은 "안드로이드용 앱 연동시 따라 서버 프로그램까지 따로 만들 필요도 없다" 들의 경우는 너무 web frontend에 집중된 의견이거나, 작은 scale의 게임을 생각하시는것 같습니다.
웹서버라고 해서, 정말 php나 asp로 HTML생성하는 로직같은 단순한 프로그램을 짜는 경우는 드물고, 뒤에서 다양한 backend가 돌아갑니다. 여기서도, message passing, load-balancing, pub/sub, sync, fault-tolerant, strong-consistency vs eventual consistency 같은 전형적인(?) distributed system 주제들이 많이 나오고, 대형 웹사이트에서 다뤄지는 기술들은 결코 게임서버보다 단순하지 않습니다.
compiled binary를 배포해야하는 대부분의 게임보다는 웹페이지를 제공하는 서비스들이 클라이언트 업데이트를 좀 더 쉽게 할 수 있는것은 사실이지만, 여기도 나름의 애로사항들이 있습니다. 가령, 특정 javascript 라이브러리들을 업데이트 하는것도 골치아프거든요. 클라이언트에서 페이지 로딩시 필요한 데이터의 양을 줄이기 위해, 다양한 caching 전략들이 사용되고 있고, 요즘같이 javascript에서 많은 비지니스 로직을 구현하는 기술동향에선, 골치아픈 문제들이 많습니다. 웹사이트들은 페이지로딩 스피드에 목숨거는 경우들이 많은데, 게임서버들은 게임서버의 업데이트 binary size를 줄이는데 신경을 덜 쓰거든요.
또한, 게임서비스들은 backward-compatibility문제를 크게 신경안써도 되는 경우가 많은데 웹사이트는 그렇지 않습니다. 게임패치 release되면, 이용중인 유저들 전부 재시작하게 만들거나, 바로 전 version과의 backward-compatibility를 유지하는 경우가 대부분입니다. 근데, 웹사이트는 안그렇죠. 클라이언트에서 쓰이는 javascript 모듈들이 다양한 버젼들이 있을수 있기때문에...뭐 암튼 여기도 나름의 문제가 많습니다. :)
해당 서비스의 scale이 서버의 복잡도에 영향을 주는 큰 요소라고 생각합니다. 웹서버이냐 게임서버이냐는 큰 의미가 없을것 같네요.
웹사이트도 공통으로 쓰는 frontend는 물론 backend library 바꾸면 말씀하신대로 애로사항 꽂피죠. 내보내기 전에 테스트해야 할 화면의 수에 비례해서 테스트해야 할 양이 화면수에 비례해서 늘어나니 대형 web이면 그거 테스트하는것만 해도 겁나죠. backword-compability 문제 됩니다. 근데 web이니까 그정도로 끝나는겁니다. 그 web과 똑같은 기능을 server-client로 구현하면 어떻게 되는지 생각해 보십시오.
web에서 공통 라이브러리 바꿨다면 화면 수만큼 테스트하고 한번 서버 올리면 끝입니다. 서버에 올리는 것만으로도 일괄적용됩니다.
근데 이것을 server-client로 만들면 공통 라이브러리 바뀐 후 화면 수만큼 테스트 + 바뀐 서버에 기존 클라이언트가 문제없이 돌아가는지 테스트 + 업데이트 파일 만든 다음 그걸 쓰는 사람이 다 받아서 설치하고 설치했는지 확인 까지 해야 합니다. 실제로 쓰는 유저들은 프로그램 잘만들었는지 아닌지 신경 안씁니다. 자기에게 떨어진 일만 잘되면 끝. web으로 만들면 1만큼의 작업분량이 나오는 기능을 server-client로 동일하게 만들면 최소 3의 작업분량이 나오는거죠.
web이든 server-client든 업무용이면 backword-compability는 무조건 필요합니다. 정확한 데이터가 들어와야 업무가 제대로 처리되니까요.
게임이면 즐기면 끝이고 저장할꺼 없으니 backword-compability 신경 덜 써도(저장할꺼 없으면 아예 안써도)됩니다. 업데이트 안해서 튕기면 업데이트하고 재접속하라고 하면 끝입니다.
그리고 웹사이트 로딩속도 경쟁한다고 해도 0.5초~1초 내, 느려도 2초내로 뜨면 상관 없습니다.
근데 게임은 이 단위가 millisec, microsec 단위입니다.
게임 업데이트 큰거는 별로 문제되지 않습니다. 업데이트중에는 빠른 응답 필요없거든요.
게임이 어찌어찌 해서 업데이트 용량 줄였어도 실행할때 지연시간이 10~20ms 이상 늘어났다면 그 게임 망한겁니다.
추가로 데이터 용량 말씀하신것은 만들어진 프로그램이 앞으로 사용될 환경에 따라 문제가 별로 안될 수도 있고 굉장히 중요해질 수도 있습니다. 고속 사내망에서만 쓸꺼면 신경 안써도 그만이지만, 모뎀 정도 속도밖에 안나오는 환경(고속인터넷망 없는 외국 등지)에서 쓰는 경우가 많다면 말씀하신대로 전송량이 중요해지죠.
서버 프로그래머가 아니라, 게임서버 프로그래머를
서버 프로그래머가 아니라, 게임서버 프로그래머를 보신것 같은데요?
서버 프로그래머라는 용어는 너무 포괄적입니다. 요즘은 잘 안쓰이는 용어입니다.
클라이언트 프로그래머라는 직업도 요즘쓰이나 궁금하네요.
- 리눅스서버 프로그래머
- 게임서버 프로그래머
- 윈도우서버 프로그래머
- 웹서버 프로그래머
이렇게 여러가지 검색해보세요.
댓글 감사합니다.
감사합니다!
90년대, 2000년대는 업무 환경이
90년대, 2000년대는 업무 환경이 Client-Server 환경이 주류였고, 이를 위한 Client, Server 프로그램 개발을 했기 때문에 Server Programmer가 필요했습니다. 프로그래밍 잡지에서는 이들을 빨리 만들기 위한 비베, 델파이 같은 RAD툴 소개가 넘쳐났던 시기입니다.
그런데, 웹이 퍼지면서 이게 다 웹으로 바뀌어 버립니다. 사무실의 작업들은 대부분 컴퓨터에 높은 부하를 주지 않고 결과만 정확하면 끝이고 웹은 이전과 비교할 수 없을 정도로 UI를 쉽게 바꿔버릴 수 있고 서버는 기존에 만들어진 웹서버 있고, DB 넣는곳만 좀 손보면 되니 기존의 Client-Server 환경보다 개발 속도가 훨씬 빨라졌습니다. Server-Client 환경에서는 특히 Client쪽에서 OS버전이나 같이 깔린 프로그램들 때문에 호환성 문제도 꽤나 많았는데 웹이면 그거 걱정할 필요도 없고요. 웹도 처음에는 웹으로 구현 불가능한것을 구현 가능하게 할려고 activex로 도배해버려서 욕 듬뿍 먹었는데, 최근 추세는 웹을 표준화하고 다양한 기능을 집어넣어서 어느 브라우저를 실행시키는 일반 프로그램과 구별이 안갈 정도로 만들 수 있도록 하고 있습니다.
근데 게임은 이거 안됩니다.
일단 게임은 서버든 클라이언트든 시스템 부하 많이 잡아 먹습니다. 서버도 한두명 들어와서 노는거면 처리할거 얼마 안되는데, 서버당 접속자수 최대한 많이 밀어넣는게 게임업체 노하우입니다. 서버가 많아질수록 게임업체 입장에서는 매달 나가는 돈이 많아지고 관리해야 할 포인트도 많아지니까요.
게임 아닌 다른 서버 프로그래밍 원한다면 SI 보시면 되실겁니다. 과거 서버프로그래머의 자리 자바에 전자정부프레임워크 등등 머시기 올리고 DB설계하고 화면 찍고, 과거 Server-Client 개발자리가 다 이걸로 엎어졌습니다.
아마 지금 Server Programmer가 있는 자리는 대충 이정도 일겁니다.
- 시뮬레이션 (ex: 기상청 등)
- 영상분야 (제가 있는 CCTV 분야도 그렇죠. 실시간 카메라 여러대의 영상은 웹으로 감당 안됩니다.)
- 임베디드 (요건 최대한 저사양으로 많은 기능 뽑아내는게 관건이라.)
Written By the Black Knight of Destruction
댓글 감사합니다.
감사합니다.!
server-client 환경일때는 client가
server-client 환경일때는 client가 말썽 많이 일으켰죠. client를 돌리는 컴퓨터들이 환경이 제각각이라 업데이트하면 내자리는 문제없는데 쓰는곳에서는 뭔 이슈 터지고 이거 해결하느라 밤새고 (안드로이드 앱 만들어보면 아실겁니다) 기능 업데이트나 ui 수정에도 손봐야 할 코드들 정말 많고, client 업데이트 내놨더라도 기존 업데이트 안한 유저가 있다보면 이들까지 감안해야 하기 때문에 server 쪽도 복잡도가 올라갔습니다.
web이면 이 문제 없습니다. 브라우저만 있으면 어디서든지 똑같은 화면을 다 쓸 수 있는데다가 프레임워크, 라이브러리들이 많이 발전하면서 수정이 쉬워져서 업무처리는 다 web 입니다.
게임은 반응시간이 최대한 빨라야 해서 어쩔 수 없이 server-client 구조 유지하는거고요.
임베디드쪽은 rs232 rs485 다루는 곳은 web protocol 올리기에는 통신하는 장비들의 사양이 떨어져서(감당 안되는 경우 많음) 임의로 정한 수byte~수십byte 크기의 바이너리로 통신하는 경우가 많은데 이때도 직접 코드 짜야죠.
안드로이드 앱 연동 개발할때도 서버 따로 만드는 경우 드뭅니다. 안드로이드 환경에서 json, xml과 http 통신 라이브러리 제공하고 있어서 이걸 활용하고 서버는 웹서버 하나 세팅해서 앱용 데이터 올려버리면 서버프로그램까지 따로 만들 필요 없으니 요새는 다 이방식으로 하더군요. 다만 게임 앱이면 반응시간 때문에 서버도 개발하고, 앱도 소켓 직접 다룹니다.
Written By the Black Knight of Destruction
5년전 글...
크... 5년전 글을 지금은 제대하고 편입을 했습니다.. 백엔드쪽으로 진로를 잡았구용 대학 가기전에는 임베디드도 생각해 보고 게임서버도 생각해 봤는데 조금씩 경험을 해보니 전 백엔드쪽이 좀 더 맞았습니다. 포폴도 준비중이니 나중에 한번 웹 오픈하면 여기에 검증 부탁드려 볼게용
다시보니 윗글이 제가 쓴거였네요.... 정신이 없어서
다시보니 윗글이 제가 쓴거였네요.... 정신이 없어서 ㅠㅠ
Written By the Black Knight of Destruction
조금 다른의견
전 게임 서버 프로그래머로도 일해보고, 다양한 서버 프로그래머로 일해왔는데, 약간 다른 의견을 갖고 있습니다.
"브라우저만 있으면 어디서든지 똑같은 화면을 만드는", 혹은 "안드로이드용 앱 연동시 따라 서버 프로그램까지 따로 만들 필요도 없다" 들의 경우는 너무 web frontend에 집중된 의견이거나, 작은 scale의 게임을 생각하시는것 같습니다.
웹서버라고 해서, 정말 php나 asp로 HTML생성하는 로직같은 단순한 프로그램을 짜는 경우는 드물고, 뒤에서 다양한 backend가 돌아갑니다. 여기서도, message passing, load-balancing, pub/sub, sync, fault-tolerant, strong-consistency vs eventual consistency 같은 전형적인(?) distributed system 주제들이 많이 나오고, 대형 웹사이트에서 다뤄지는 기술들은 결코 게임서버보다 단순하지 않습니다.
compiled binary를 배포해야하는 대부분의 게임보다는 웹페이지를 제공하는 서비스들이 클라이언트 업데이트를 좀 더 쉽게 할 수 있는것은 사실이지만, 여기도 나름의 애로사항들이 있습니다. 가령, 특정 javascript 라이브러리들을 업데이트 하는것도 골치아프거든요. 클라이언트에서 페이지 로딩시 필요한 데이터의 양을 줄이기 위해, 다양한 caching 전략들이 사용되고 있고, 요즘같이 javascript에서 많은 비지니스 로직을 구현하는 기술동향에선, 골치아픈 문제들이 많습니다. 웹사이트들은 페이지로딩 스피드에 목숨거는 경우들이 많은데, 게임서버들은 게임서버의 업데이트 binary size를 줄이는데 신경을 덜 쓰거든요.
또한, 게임서비스들은 backward-compatibility문제를 크게 신경안써도 되는 경우가 많은데 웹사이트는 그렇지 않습니다. 게임패치 release되면, 이용중인 유저들 전부 재시작하게 만들거나, 바로 전 version과의 backward-compatibility를 유지하는 경우가 대부분입니다. 근데, 웹사이트는 안그렇죠. 클라이언트에서 쓰이는 javascript 모듈들이 다양한 버젼들이 있을수 있기때문에...뭐 암튼 여기도 나름의 문제가 많습니다. :)
해당 서비스의 scale이 서버의 복잡도에 영향을 주는 큰 요소라고 생각합니다. 웹서버이냐 게임서버이냐는 큰 의미가 없을것 같네요.
웹사이트도 공통으로 쓰는 javascript
웹사이트도 공통으로 쓰는 frontend는 물론 backend library 바꾸면 말씀하신대로 애로사항 꽂피죠. 내보내기 전에 테스트해야 할 화면의 수에 비례해서 테스트해야 할 양이 화면수에 비례해서 늘어나니 대형 web이면 그거 테스트하는것만 해도 겁나죠. backword-compability 문제 됩니다. 근데 web이니까 그정도로 끝나는겁니다. 그 web과 똑같은 기능을 server-client로 구현하면 어떻게 되는지 생각해 보십시오.
web에서 공통 라이브러리 바꿨다면 화면 수만큼 테스트하고 한번 서버 올리면 끝입니다. 서버에 올리는 것만으로도 일괄적용됩니다.
근데 이것을 server-client로 만들면 공통 라이브러리 바뀐 후 화면 수만큼 테스트 + 바뀐 서버에 기존 클라이언트가 문제없이 돌아가는지 테스트 + 업데이트 파일 만든 다음 그걸 쓰는 사람이 다 받아서 설치하고 설치했는지 확인 까지 해야 합니다. 실제로 쓰는 유저들은 프로그램 잘만들었는지 아닌지 신경 안씁니다. 자기에게 떨어진 일만 잘되면 끝. web으로 만들면 1만큼의 작업분량이 나오는 기능을 server-client로 동일하게 만들면 최소 3의 작업분량이 나오는거죠.
web이든 server-client든 업무용이면 backword-compability는 무조건 필요합니다. 정확한 데이터가 들어와야 업무가 제대로 처리되니까요.
게임이면 즐기면 끝이고 저장할꺼 없으니 backword-compability 신경 덜 써도(저장할꺼 없으면 아예 안써도)됩니다. 업데이트 안해서 튕기면 업데이트하고 재접속하라고 하면 끝입니다.
그리고 웹사이트 로딩속도 경쟁한다고 해도 0.5초~1초 내, 느려도 2초내로 뜨면 상관 없습니다.
근데 게임은 이 단위가 millisec, microsec 단위입니다.
게임 업데이트 큰거는 별로 문제되지 않습니다. 업데이트중에는 빠른 응답 필요없거든요.
게임이 어찌어찌 해서 업데이트 용량 줄였어도 실행할때 지연시간이 10~20ms 이상 늘어났다면 그 게임 망한겁니다.
추가로 데이터 용량 말씀하신것은 만들어진 프로그램이 앞으로 사용될 환경에 따라 문제가 별로 안될 수도 있고 굉장히 중요해질 수도 있습니다. 고속 사내망에서만 쓸꺼면 신경 안써도 그만이지만, 모뎀 정도 속도밖에 안나오는 환경(고속인터넷망 없는 외국 등지)에서 쓰는 경우가 많다면 말씀하신대로 전송량이 중요해지죠.
Written By the Black Knight of Destruction