사이드 프로젝트와 데브옵스
야심한 밤에 또 글 한 번 작성해봅니다...
*주의: 데브옵스라는 용어를 두루뭉술하게 와일드카드처럼 사용하였습니다. 데브옵스(엔지니어)란 무엇인가, 어떤 역할을 수행하는가, SRE는 그럼 또 뭐냐, 클라우드 엔지니어랑 다른 거냐, 우리 회사에선 이 작업은 안하던데, 우리 회사에선 이 영역까지 다루던데 등... 용어 자체의 모호함이 이미 여기저기 퍼져있고 데브옵스 엔지니어들끼리도 데브옵스라는 용어에 대한 정의가 제각각인 면이 있습니다. 그냥 개발 그 자체는 아닌데 또 인사팀에 시킬 수 없는 애매한 개발 언저리의 일 또는 그런 일을 전문적으로 하는 사람, 그리고 그 일을 수행하기 위한 전반적인 문화나 개발 방법론이 포함된 용어로 생각해주시면 되겠습니다...
오키 커뮤니티를 보다보면 사이드 프로젝트 팀원 모집글이 꽤 많이 보입니다.
저는 스터디나 단체작업 같은 건 별로 좋아하지 않아 개발을 할 줄 알았어도 참가하진 않겠지만... 가끔 팀원 모집글을 보면서 이런 생각을 합니다.
'결국 데브옵스 엔지니어(또는 SRE, 아니면 그냥 클라우드 엔지니어든 인프라 엔지니어든, 용어야 어쨌든 간에.)는 필요로 하지 않는구나.'
사실 그게 맞긴 합니다.
컨설팅을 할 때 규모가 작은 팀이나 이제 막 개시한 스타트업의 경우는 "데브옵스 팀을 구성하지 말라."라고 합니다.
데브옵스가 없는, 혹은 그에 준하는 지식이 없는 개발자들끼리 모여서 서비스를 릴리즈하면 보통 개판이 납니다.(자존심 싸움 하지 맙시다...) 데브옵스 입장에서는 고쳐야할 것들이 한 두 가지가 아니죠.
하지만 그럼에도 불구하고 데브옵스를 굳이 뽑을 필요가 없는 이유는, 어차피 작은 서비스, 이제 막 사업을 시작한 스타트업 입장에서는 그 개판인 구조로도 서비스를 충분히 유지할 수 있기 때문입니다.
초당 리퀘스트 100개...? 튜닝 같은 것도 필요 없고 설정도 막 아무렇게나 해도 다 돌아갑니다. 안 터져요.
그러다 갑자기 요청이 몰려서 서비스가 터지면? 그럼 스타트업 입장에선 오히려 대박입니다. 잠깐 당황은 하겠지만 서버 수 좀 늘리고(돈 좀 부어넣으면) 어떻게든 됩니다.
클라우드가 대중화되면서 더 이상 서버를 어떻게 임대하고 네트워크를 어떻게 구성하고... 그런 것들도 필요가 없어졌습니다. 기본적으로 클라우드 벤더가 어느 정도 잘 해주니까요.
그러다 조직이 커지고 개발자가 늘어나고 서비스가 늘어나기 시작하면 개발자들만으로는 감당이 안되는 순간이 옵니다.
그리고 결국 데브옵스 팀을 구성하게 되죠. 기존에 데브옵스 업무를 잘 수행하고 데브옵스에 흥미가 있는 개발자가 팀 리더가 되어 거기서부터 시작하거나, 외부에서 경력직 데브옵스 엔지니어를 데려옵니다.
데브옵스가 없던 팀에 첫 데브옵스 엔지니어로 들어가면 고생이 많습니다. 위에 적은대로 고쳐야할 게 산더미라서요...
그나마 고쳐야할 것만 있으면 다행입니다. 보통은 히스토리 누락, 시크릿 누락, 누가 관리하는지 모름, 구축 후 그 누구도 관리한 적 없음 등의 문제가 같이 딸려옵니다. 결국 여기저기 찔러보고 위키를 샅샅이 뒤지고 퇴직자한테 연락해서 누락된 정보도 획득하고...
인프라 구조 자체를 바꿔야하지만 당장 냅다 바꿔버릴 수는 없으니까 기존 상태에서 어떻게든 생명 연장을 시키고 그걸 유지시키면서 V2 인프라를 구축해 트래픽을 넘겨버립니다.
엄청난 시간이 소요됩니다. 단순 작업도 많지만 조직에 따라서는 변화에 민감한 개발자들을 설득하는 것도 일이 됩니다. 인프라의 변화로 인한 작업 프로세스의 변경과 그걸 개발자들에게 주입하고 개발/운영 사이의 추상화, 표준화, 약속을 정하는 것까지 다 포함됩니다.
데브옵스 엔지니어가 뛰어나고 개발자들도 곧잘 적응해서 온전히 데브옵스 문화가 개발팀에 정착하게 되면 그때부턴 일이 쉬워집니다.
개발자는 개발에만 집중하고 데브옵스는 운영에만 집중합니다. 사전에 약속한 부분만 지킨다면 각각의 영역에서 서로를 간섭할 일이 극도로 줄어들게 됩니다.
표준화와 자동화로 인해 운영 업무는 더 적은 인원으로 더 빠르게 더 자주 처리됩니다.(데브옵스의 딜레마입니다. 초기 구성에는 많은 인력을 필요로 하지만 구성이 마무리되면 이제 그 인력의 과반이 필요가 없어집니다. 데브옵스 인력 충원을 쉽게 할 수 없는 이유죠.)
물론 이상은 이상이고 그 과정은 험난하기에 그 과정에서 계획했던 많은 것들을 포기하고 결국 원했던 형상에 도달하지 못할 때도 있습니다.
하지만 서비스 운영의 전문가로서 개발팀을 지원하고 함께 협력하며 같은 목표를 향해 나아가다보면 그 과정의 부스러기만으로도 많은 것을 얻고, 또 개발자들에게 제공하게 되면서 인정을 받게 됩니다.
"너가 있어서 다행이야. 역시 너가 필요해."라고요.
*여기서부터 깔깔유머 타임.
최초로 투입된 외부 데브옵스 인력이 겪는 어려움에 대해 개발자분들이 이해하도록 설명드리겠읍니다.
스타트업을 차린다.
데브옵스 엔지니어도 굳이 시키면 개발은 할 줄 아니까 데브옵스 엔지니어만 뽑는다.
데브옵스 엔지니어에게 서비스 개발을 시킨다.
서비스가 커지며 데브옵스 엔지니어들의 어중간한 개발실력이 발목을 잡는다.
이제 이 문제를 해결하기 위해 개발 전문가를 뽑아보자...
개발자가 코드베이스를 살펴보며 말했다.
"동일한 역할을 수행하는 5개의 메소드를 3개의 클래스에 걸쳐 각각 2개의 앱에 작성하셨군요... 잘하셨습니다..."
