Full Stack Engineer에 대하여

최근 Full Stack Engineer에 대한 부정적인 트위터 탐라나 페북에서 볼 수 있었다. Full Stack Engineer이란 무얼까부터 다시 고민해 봤다.

먼저 Quora에서 올라온 Full Stack Engineer에 대한 정의는 아래와 같다.

It means a person who can work with databases, servers, systems engineering, and client work. Depending on what kind of client is needed that can mean a mobile stack, web stack, or native applications.

Basically when people are asking for a full-stack programmer they’re looking for the all-singing, all-dancing technical wizard. Or at least someone who won’t complain too much when asked to do some work outside their normal comfort zone.

DB도 하고, Server, System Engineering 작업도 하면서 클라이언트도 가능한 개발자. 이 때 Client라 함은 모바일 일 수도, 웹일 수도, Native Application일 수도 있고. 그리고 추가적인 덧붙임을 하고 있는 코멘트에선, 대게 혼자 노래 부르고, 춤추고 다하는 테크니컬 마법사 같은 존재이거나 아무거나 시켜도 불평 불만 없이 잘 해내는 사람 정도이다 라고 정의한다.

사실 Full Stack Engineer란 단어는 게임의 영역보다는 Web 개발 영역에서 많이 사용하는 말이다.  StackOverflow Careers 에서 Full Stack 으로만 찾아 봐도 360여개의 구인 광고가 나온다.

 

 

Full Stack Engineer는 그야말로 하나의 Product 혹은 Service가 고객과 접점을 이루기 위해서, 혹은 성공적인 Launching 을 위해서 필요한 기술적인 바닥부터 최상위 단 까지 다 할 수 있는 개발자를 말한다. 대게 서비스를 하기 위해서는 Backend가 필요하므로 서버를 IDC에 놓느냐, Cloud를 사용하는가 부터 시작해서, 서버의 사양과 OS를 결정하고, 적당한 서버의 갯수를 설정하는 것부터 시작한다. Database를 선택하고 사양을 셋팅하여 서버와 붙이는 일도 필요할 것이고, 적절한 서버의 Language를 선택해서 Client와 Server, Server와 DB 간 통신도 하고 데이터도 주고 받을 수 있도록 해줘야 한다. 그리고 고객과의 접점인 Client를 만들어서 서비스가 잘 될 수 있도록 해주는 것까지의 작업을 모두 할 수 있는 기술자를 Full Stack Engineer라고 부르는 것이다.

나의 경우를 원래 Client 개발자였다. 그런데, 출출할 때 전사원 떡복이 사다리를 탈 수 있었던 작은 벤쳐에서 일할 수 있는 기회가 있었었다. 그런데 그 회사에선 System Admin이 아예 없었다. 서버 개발자 혹은 서버 팀? 없었다. 그냥 Client 개발자가 모든 것을 알하서 하고 게임을 출시해야하는 상황에 놓인 것이다. 그 회사 입사 이전에 Web Server인 Apache, Nginx나, DB로는 Mysql, 서버 언어로는 Php 정도 써 본 경험이 있던터라 그나마 빠르게 적응할 수 있었는데 쌩판 iOS, Android 게임만 한두개만 졸업 작품으로 겨우 개발 해본 신입들에겐 얼마나 큰 부담이었을까 생각된다.

다행히 그 회사는 IDC를 쓰지는 않고, 선견지명이 있던 리더분들로 인해 호랑이 담배피던 그 시절 이미 Amazone AWS를 썼었고, 후에 유클라우드가 안정화가 된 다음엔 유클라우드도 썼었다.

게임을 출시하기 위해서는 사용하고 있던 도메인 업체에 접속해서 게임 이름의 서브 도메인을 하나 만든다. 그리고는 AWS나 유클라우드에 들어가서 정해진 사양과 OS의 웹서버를 게임의 사이즈에 맞는 기본 갯수를 생성하고, DB로는 유지 관리가 용이한 RDS로 선택하여 연결했다. 웹서버 앞단에 Load Balance를 붙여서 부하를 분산시켜 주고 도메인과 연결한다. 필요하면 S3에 추가 다운로드 파일을 올려서 다운 속도를 높였고, 로그 데이터를 수집하도록 셋팅했었다. AWS에 적절한 이미지가 없을 때에는 서버 이미지부터 만들어야 했었는데, fdisk로 파티션부터 나눠서 기본 셋팅을 다한 다음 APM도 소스 컴파일을 해서 설치했는데 이것도 만만치 않은 작업이었다. (이 때 친해진 명령어가 df -lh 이다. 이건 System Admin 필수 명령어!!! ㅎㅎㅎ)

Client, DB와 주고 받는 서버 언어로는 PHP를 썼었는데 게임의 특성에 맞춰서 적절한 EndPoint들을 만들어 주고 서버 단에서 해야할 작업들을 프로그래밍하고 Client와 무리 없이 통신하도록 해줬었다. Query를 대량으로 던져도 문제 없도록 Indexing을 주의해서 줘가며 DB 테이블을 설계했었고, DB의 부하를 줄이기 위해서 웹서버와 로직을 잘 분리 했었다. Heavy Query들은  long_query_time 셋팅으로 로깅하여 찾아내고 튜닝하기도 했다. Nagios나 In-House 모니터링 툴을 만들거나 셋팅하여 서버 상황을 대응할 수 있도록 하고, Google Analytics나 Flurry, TapJoy 같은 3rd Party 툴들도 붙여서 유저 통계들을 볼 수 있도록 했었다.

동시에 Client도 작업했다. 기획을 받고, 디자이너로부터 리소스를 받고, 게임의 개선점에 대해서 논하고 방향을 협의하고 개발을 진행하고 Break Through들을 이뤄내고. UI, 게임 시스템 및 Play, 그래픽 관련 개발 할 것 없이 혼자 다 해야했다. 또한 기간의 압박까지 있어서 서버와 클라이언트 단의 모든 작업들을 하고 게임을 출시하기까지 3~4개월 정도 밖에 걸리지 않았다. 카카오 게임도 그 정도 기간 안에 뽑아 냈었다. 그렇게 만들고 서비스한 게임들이 무리없이 잘 돌아가고 그 중 드물게 몇몇은 성공하는 것들을 지켜보았었다. 서비스에 갑자기 유저가 몰리게 되면 점검 공지를 띄우고 새벽에 출근하여 시간에 맞춰 초분을 다퉈가면 서버를 늘리고 다시 유저가 유입되는 것을 지켜보기도 많이 했었다. (이건 Auto-Scaling을 사용하기 전의 이야기다.)

지금 생각하면 그 모든 것들을 한, 두명의 개발자가 다 감당해 내는 것이 결코 쉬운 일이 아니었음을 뼈저리게 느낀다. 그러나 그렇게 몇 년간을 지내고 나니 나는 그냥 초보 티 정도는 벗어난 Full Stack Engineer가 되어 있더라. 이제는 게임의 앞단을 만지는 작업 뿐 아니라, BackEnd를 만지는 작업에도 어느정도 자신이 생긴 것이다.

생각해보면 벤쳐나 작은 회사는 Full Stack Engineer를 찾을 수 밖에 없다. 그것이 유리하다. 서비스나 Product의 방향이 자주 그리고 완전히 바뀔 수도 있고, 많은 사람들을 고용하기도 힘들기 때문에 더욱 그렇다. 믿을 만한 사람이 다양한 분야의 개발을 다 할 수 있다면 금상첨화. 다만 연봉나 Stock을 많이 주고 데려와야 제대로 된 Full Stack Engineer를 구할 수 있다.

반면, 큰 회사로 갈 수록 Full Stack Engineer가 필요 없다. 서버팀이 있고, 시스템 인프라 팀이 있고, 클라이언트가 따로 있다. 디자인도 마찬가지다. 회사가 커지고 자금력이 많을 수록 디자인 직군도 세분화 하여 채용한다. 게임의 경우 클라이언트는 정말 클라이언트만 개발해도 되고, 이 클라이언트 마져도, Graphics, Game Play, Game UI, Network 등으로 개발 직군이 세분화 되어 있다. 조금 더 깊이 있는 개발들을 진행할 수 있는 것이다.

그래서 그런지 사람들은 Full Stack Engineer가 되기를 그렇게 바라지 않는다. 웹 개발자로써 Full Stack Engineer가 꿈인 분을 별로 만나본 적이 없고, 게임 개발자로써는 더더욱 그렇다. 메이져 회사들에 채용되기 위해서 굳이 불필요한 일이고, 경력 또한 외길을 팠다는 느낌보다는 지져분해졌다는 느낌도 들기 때문이다. 산업 혁명 이후 일의 효율은 모든 것을 정당화 한다. 그러므로 효율적이기 위해서는 한 사람은 하나의 작업만을 가장 빨리 가장 잘 해야하는 것이 현대 사회이고, 우리는 그렇게 길들여져 왔다.

무엇보다 Full Stack Engineer에 대한 가장 큰 부정적인 시각은 하나도 제대로 못하는 개발자가 아닌가 라는 점이다.  사실 하나도 제대로 하기 쉽지 않다. 하물며 경력이 5년도 채 안된 개발자들이 백단에서 앞단까지 모두를 잘 한다고 떠벌리는 개발자들이 있으니 한 분야들을 깊게 파온 사람들이 보기엔 헛웃음만 나오는 경우가 얼마나 많을까?

사실 나도 서버 분야를 서버 분야를 이전 회사에서 조금 더 파고 싶었다. Chef나 Puppet을 써서 서버 생성을 자동화 해보고 싶었고, Memory DB인 Redis를 RDB 앞단에 놓고 부하가 획기적으로 줄어드는 것을 보고 싶었다. Nosql인 MongoDB를 써서 로깅을 구현하고 싶었으며 NodeJS로 실시간 채팅이나 기능들을 서비스에 넣어주고도 싶었다.  그렇다. 한 분야를 깊이 있게 아는 데도 많은 시간과 노력이 든다. 그리고 한 분야도 해가 지나면 새로운 기술들이 마구마구 쏟아져 나오므로 그 기술들을 습득하여 본인의 것으로 채득하는 것도 상당한 경지의 개발자라고 본다.

그러나 조심스레 반문해 본다. 정말 깊이와 넓이를 고루 갖추는 것이 불가능할까? 본인의 전문 분야를 깊이 있게 잘 알고 있고, 동시에 서비스의 Technical Stack의 전반적인 기술을 모두 잘 알고 있으며 심지어 다룰 줄 알기까지 하는 것 불가능할까? 공부에 빗대기는 그렇지만, 수학도 잘하고 영어도 잘하고 국어도 잘 하는 것이 불가능할까? 라는 질문과 비슷하지 않나 싶다.

개인적으로 게임을 예술 작품의 수준으로 끌어올린 게임을 몇개 알고 있는데 그 중 하나가 Tiny Wings 이다.

그런데 이 Tiny Wings를 개발한 Andreas Illiger는 82년생 독일 개발자인데, 기획부터 디자인, 개발, 사운드까지 혼자 이 게임을 만들었다. 음악으로 치면 그야말로 One-Man Band이고 Full Stack Engineer 다.  더욱 놀라운 건 이 사람의 각 분야별 기술 수준인데, Andreas가 Tiny Wings을 만들 때 적용한 기술 중에 맵을 동적으로 랜덤하게 생성하는 로직은 Trigonometry와 Graphics에 대한 상당히 깊이 있는 지식이 있어야만 구현할 수 있는 수준으로 고급 개발자들이 해내는 수준이다. 디자인의 완성도와 사운드 또한 감히 어떤 다른 게임과 비교해도 눈에 띌만큼 완성도가 좋다.  거기다 상업적인 대성공까지 거두었으니 기획까지 아주 좋았던 것을 사람들이 인정하고 박수쳐 주었다.

Full Stack Engineer가 되기 쉽지 않다. 어려운 길이고 또한 기회가 주어져야 가능한 일이다.  그냥 큰 기업에 앉아 주어진 일에 월급만 받고 있는 상황에서는 좀처럼 해내기 어려운 개발자의 모습일 것이다. 그럼에도 불구하고  어떤 경우에든 본인의 영역을 제한해 두는 것보다 제한하지 않는 것이 좋다.

반면, 모든 기술 스택을 다 이해하고 있고 개발할 줄도 안다고 하더라도, Full Stack Engineer라고 본인을 과시하는 짓은 그만둬야 한다. 왜냐하면 하나의 분야는 끊임없이 새로운 기술들과 트랜드로 변화하고 발전하고 있으며 그 깊이 또한 쉽게 잡아 내기 어려운 경우가 많기 때문이다.  이건 Hidden Card 정도로만 활용하되, 본인의 기본 분야의 깊이를 항상 무게감 있게 가져 가야 한다. 말하고 보니 이건 Valve의 인재상인 T-Shape Model 과 흡사하다. (Valve Employee Manual 참고)

Full Stack Engineer는 장점이 엄연히 존재한다. 첫째는 기술적인 이해도가 높아서 협업 시에 커뮤니케이션 하기가 쉽다. 둘째는 본인 파트 만의 문제가 아닌 연계성이 있는 문제, 다리가 걸쳐져 있는 문제 발생 시에 해결 능력이 뛰어나다. 벤쳐나 소규모 회사에서는 추가 인력의 고용 없이 Product 혹은 Service를 만들어 낼 수 있고 큰 회사일 경우 기술적인 Head, 혹은 Product Director들은 Full Stack Engineer일 경우 좋은 Service나 Product을 만들어내기 수월하다.

사실 Full Stack Engineer가 개발자의 궁극적인 목표가 될 수는 없다. 그것이 국내 취업만 생각한다면 인력 시장에서 그렇게 매력적이지도 않다. 더 중요한 것은 Learning Skill이 아닌가 한다. 항상 자신을 제한하지 않고 겁없이 새로운 분야를 배우고 계속 성장하는 엔진을 가슴 속에 가지고 있는 개발자가 되는 것이 더 중요할 것으로 본다. 그럼에도 불구하고 Full Stack Engineer는 좋은 성장의 티핑 포인트가 될 수 있다. 이건 마치 음악으로 치면 오케스트라의 지휘자가 되는 것과 비슷하다. 하나의 음악을 관객에게 시연하기 위해서 다양한 악기들과 연주자들이 연주를 하지만 지휘자는 그 모든 악기들의 특성과 악기들이 자기의 소리를 내야할 시점과 소리를 어떻게 내야하는지를 서로 조율하고 지휘한다. 또한 지휘자는 모든 악기의 소리를 알아야 하고 심지어 연주할 수도 있어야 하며, 악보와 그 곡을 완벽하게 이해해야 한다. 그러므로 Full Stack Engineer는 개발의 지휘자라고 할 수 있다. 우리는 늘 좋은 연주자가 되어야 한다고 강요받는 좁은 사회에 살고 있지만, 누군가는 좋은 지휘자가 되어야 한다. 따라서 Full Stack Engineer는 개발자들의 좋은 지향점이 될 수 있다.

출처 : http://rapapa.net/?p=2514