로그인

회원가입 | ID/PW 찾기

취재

[NDC 17] 없어서 못 뽑는다는 데브옵스(DevOps) 개발자, 어떤 일을 할까?

김태현 엔지니어가 넥슨 아메리카에서 보낸 6년의 이야기

반세이(세이야) 2017-04-27 15:14:05

소프트웨어 엔지니어로 넥슨 아메리카에 입사해 지금은 DevOps and Technology 조직을 이끌고 있는 김태현 엔지니어. DevOps(이하 데브옵스)는 국내 게임 업계에서는 아직 생소한 개념일 수 있으나, 국내 IT업계 전반을 비롯해 북미에서는 최근 센세이셔널한 포지션이다. 

 

김태현 엔지니어는 27일, 지난 6년간 넥슨 아메리카에서 느낀 데브옵스 엔지니어링의 가치와 개념, 좋은 데브옵스 엔지니어가 되는 길에 대해 강연했다. 

* DevOps란? 소프트웨어 개발 방법론의 하나로, 개발(development)과 운영(operation)을 결합한 혼성어이다. 개발 담당자와 운영 담당자가 연계하여 협력하는 개발 방법론을 말한다. (by. 네이버 지식백과)

 

 넥슨 아메리카 DevOps and Technology​ 김태현 엔지니어



개발과 운영의 경계를 넘어, 데브옵스 엔지니어의 등장 

김태현 엔지니어는 ‘출산 장려 운동’의 모순을 지적하며 강연을 열었다. 사람들이 출산을 기피하는 이유는 아이를 낳는 것이 두렵기 보다는 키우는 과정이 너무 힘들기 때문이라는 것이다. 김 엔지니어 역시 10년 간의 육아 전쟁을 치르며 마치 기나긴 암흑 속을 걸어 온 것 같다고 했다. 

개발 역시 마찬가지다. 서비스를 출시하는 것이 가장 힘들 것 같지만 그 뒤에는 ‘운영’이라는 산이 버티고 있다. 서비스를 만든 엔지니어가 직접 운영까지 하면 가장 좋겠지만, 엔지니어는 출시 이후에도 새로운 문제들을 계속 해결해야 한다. 콘텐츠 업데이트, 보안 이슈 점검은 물론 버그 수정 요청이 물 밀듯 밀려온다.





그렇다면 서비스는 누가 할까? 보통은 네트워크 엔지니어와 시스템 엔지니어가 맡는다. 이 영역들이 서비스 운영에서 가장 중요한 두 축이기 때문이다. 여기서 문제가 발생한다. 

개발은 문제가 발생했을 때 빠르게 수정하고 싶어 한다. 그러나 운영은 안정적인 서비스가 목적이기 때문에 변화를 기피한다. 변화로 인해 서버에 장애가 생기면 운영은 곤란해진다. 마치 개와 고양이처럼 개발과 운영은 숙명적으로 항상 충돌하게 돼 있다.​ ​





이 구도에 변화를 준 것은 ‘클라우드’의 등장이다. 누구나 손 쉽게 서버를 만들고 관리하기 쉬워지자 소프트웨어 엔지니어도 서버와 운영에 관심을 갖기 시작했다. 기존에는 서버 구축과 관리가 어려웠다. 일단 서버를 구입해야 했고, OS를 설치해 IDC에 가져가 세팅까지 해야 했다. 그러나 클라우드는 달랐다. 서버 세팅과 관리가 편해지자 개발과 운영의 경계가 허물어졌다. 


난관, 또 난관. 그리고 그들이 문제를 해결하는 방식

소프트웨어 엔지니어들이 막상 운영에 들어와서 보니, 문제점이 보였다. 일단, 트러블 슛(trouble shoot, 고장 또는 기능 불량의 원인을 찾아내는 데 필요한 진단 또는 검사​)을 하기가 번거롭고 어려웠다. 느낌상 항상 같은 문제 때문에 서버가 죽는 것 같은데 까 보기 전에는 문제를 확신할 수 없었다. 항상 비슷한 문제와 같은 과정이 반복됐다. 





서비스 배포에 시간이 너무 오래 걸리고 실수가 많았던 것도 골치였다. 개발한 서비스를 유저가 이용할 수 있도록 배포하기 위해 매번 밤샘 점검이 이어졌다. 점검이 끝난 뒤에도 계속해서 크고 작은 점검을 해야 했다. 체력은 물론, 정신적으로도 고된 일이었다. 김태현 엔지니어는 해당 문제가 해결되기 전까지 <메이플스토리> 북미 서버 이슈로 매일 밤 평균 두 통 이상의 전화를 받아야 했던 때를 회상했다. 그 때는 서버가 죽어도 알 방법이 없었다. 유저들의 불만으로 커뮤니티에 불이 난 것을 보고 알아챈 적도 있었다. 

수 많은 서버의 설정을 일일이 관리하기도 어려웠다. 다 같은 OS를 사용하는데도 설정이 조금씩 달랐다. 보통의 프로그래머들은 ‘반복’하는 것을 참을 수 없어 한다.





문제를 해결하기 위해 소프트웨어 엔지니어들은 그들 식의 해결법인 ‘프로그램 개발’을 택했다. 반복 작업을 피하기 위해 자동화 툴을 만들고, 장애의 정확한 증상과 원인을 찾아내기 위해 모니터링 시스템도 개발했다. 모니터링 단에서 해결할 수 있는 장애는 자동 해결이 가능하도록 한 것은 덤이었다. 

배포 과정에서의 스트레스도 줄이고 싶었다. 관점을 바꿔 생각해보면 배포는 엔지니어를 떠나 유저에게 닿기까지의 모든 과정이었다. 파이프 라인을 재설계하고 과정이 원활하도록 시스템을 다듬었다. 서버 설정을 편하게 관리하기 위해 ‘스크립트를 실행해서 설정을 바꾸는 방식’에서​ ‘원래 그 서버의 설정은 그랬던 것’으로 정의를 바꾸는 방법을 택했다. 





그러자 이번에는 ‘툴을 쓰는 반복’이 다시 찾아왔다. 위에서도 말했듯 프로그래머는 ‘반복’하는 것을 참을 수 없는 종족이다. 

김태현 엔지니어와 그의 조직은 툴과 사용자를 분리하기로 한다. 이를 위해서는 툴을 사용자 관점에 맞게 만들어 줄 필요가 있었다. 사용자가 코드를 입력할 필요가 없도록 라디오 버튼이나 드롭 다운을 이용해 명령을 쉽게 선택할 수 있도록 했고, 실행 과정도 단순 명료하게 보여줬다. 사용자 관점에서 디자인 된 툴을 이용하니 엔지니어가 아니라도 서비스를 운영할 수 있었다. 엔지니어는 뒷단 개발만 맡으면 됐다.





어느새 각광받고 있던 데브옵스. 그리고 천정부지로 치솟는 몸값

김태현 엔지니어가 몸으로 부딪히며 깨달은 가치는 고스란히 넥슨 아메리카 데브옵스 조직의 뿌리가 됐다. 하지만 그런 그도 처음부터 데브옵스 엔지니어는 아니었다. 

넥슨 아메리카에서 바쁜 나날을 보내던 당시, 그는 정체성에 혼란을 겪기도 했다. 지인들을 만나면 무슨 일을 하는지 정확히 설명할 수 없었다. 그만큼 업무의 범위가 넓었고, 그동안은 없던 종류의 일이었다. 그러나 그는 이내 데브옵스 엔지니어링의 가치를 깨달았다. 그가 속한 조직을 통해 회사의 누군가는 일을 쉽게 할 수 있었다. 개발과 운영의 충돌을 엔지니어링으로 완화하는 뼈와 뼈 사이 연골같은 일. 데브옵스 엔지니어링은 보람찬 일이었다. 





장점만 있는 것은 아니었다. 숱한 장애와 24시간 싸워야 했으며, 조직의 저항도 있었다. 사람들은 변화를 달가워하지 않았다. 불확실한 장애와 반복되는 문제로 엔지니어는 힘들었지만 어떻게든 문제는 해결됐다. ‘효율적으로 운영, 개발하기 위해 툴을 만들 시간이 필요하다‘라고 하면 ‘그냥 하던대로 하면 안 되냐’라는 답변이 돌아오기도 했다. 사람들의 이해가 부족한 탓이었다.

그렇게 고군분투하던 새 주위를 둘러보니 데브옵스라는 말이 유행하고 있었다. 누군가는 그것이 문화라고, 또는 혁명이라고, 개념이라고 했지만 핵심 가치는 같았다. 거창한 기획이나 개발 과정보다는 빠르게 수렴하고 재깍 반영해 고치는 것이 더 낫다는 것. 당시 나온 애자일의 개념과도 비슷했다.  

시장은 빠른 속도로 진화하며 점점 더 많은 것을 요구했다. 속도는 필수였다. 수많은 회사가 데브옵스 엔지니어를 찾았다. 5년차 엔지니어는 실리콘 밸리에서 12만 불의 연봉을 받았고, 넥슨 아메리카가 있는 LA에서는 반경 40km 내에 데브옵스 엔지니어의 일자리가 수백 개를 넘었다. 당연한 일이었다. 기존의 방식은 비용이 너무 많이 들었다.  ​







데브옵스 엔지니어가 되는 법. 그리고 데브옵스의 핵심 가치

여기까지만 보면 데브옵스 엔지니어는 선망의 직종이다. 그러나 데브옵스 엔지니어가 되려면 어떻게 해야 하는지 말해주는 사람이 많지 않다. 김태현 엔지니어가 조사한 바에 의하면 아래 이미지에서 왼쪽(빨간색)에 가까울수록 더 많은 회사에서 요구하는 스킬이다. 





더불어 일반 소프트웨어 엔지니어가 데브옵스 엔지니어링을 하기 위해서는 리눅스에 익숙해 지는 것, 개발 PC에서 완성된 시스템을 직접 돌리며 계속 테스트 해 보는 노력 등이 필요하다. AWS를 많이 사용해 보면 네트워크에 대해서도 많이 알 수 있다. 

이 기술들이 던지는 메시지는 하나다. 헤테로지니어스(heterogeneous)다. 호모지니어스의 반댓말로 ‘불균일함’을 뜻한다. 같은 것들을 쓰는 것이 아니라 서로 다른 것들을 섞어 유연함을 만들어 내는 것이 데브옵스의 가치다. 클라우드를 기반으로 한 기술들이기에 그에 대한 열린 자세도 중요하다. 핵심 자세는 ‘똑같은 것을 반복하지 않고 자동화 하는 것을 즐겨야 한다’는 것이다.





끝으로 김태현 엔지니어는 게임 퍼블리셔 데브옵스로 일하며 느낀 점을 공유했다. 김 엔지니어에 따르면 이 분야는 데브옵스의 미개척지다. 개발사에도 데브옵스가 있고 퍼블리셔에도 데브옵스가 있으면 중복이 아니냐라고 생각할 수 있는데, 다르다. 개발사는 빨리 빌드하고 배포하는 것이 중요하고, 퍼블리셔는 배포한 것을 라이브로 보내는 것이 중요하다. 김태현 엔지니어는 “게임 퍼블리셔에서 데브옵스의 가치는 더욱 커질 것”이라고 전망했다.