데브옵스(DevOps)는 더욱 빠르고 안정적인 서비스를 제공할 수 있도록 개발 환경과 운영 역량을 향상시키는 문화 또는 방법론을 말합니다. 특히 패스트뷰에서 데브옵스 엔지니어는 개발자들이 서비스 개발에만 집중할 수 있는 환경을 만듦으로써 생산성을 높이는 동시에 인프라 관리를 효율화하는 역할에 집중하고 있는데요.
데브옵스 엔지니어가 패스트뷰에 왜 필요하고, 현재 어떤 변화들을 만들어 가고 있는지,
패스트뷰의 데브옵스 엔지니어로 일하고 있는 지성님과 이야기를 나눠보았습니다
안녕하세요! 간략한 자기소개 부탁드려요.
안녕하세요. 패스트뷰 해외유통사업팀에서 데브옵스 엔지니어로 근무 중인 7년 차 엔지니어 박지성입니다. 저는 클라우드 솔루션 기업에서 인프라 엔지니어, 특히 네트워크(통신) 엔지니어링을 주력으로 커리어를 시작했고, 인프라 자동화 업무 비중이 커지면서 자연스럽게 데브옵스 엔지니어로 전향하게 됐습니다. 패스트뷰에는 올해 4월에 합류했는데요, 다양한 역할과 기회가 열려있는 만큼 하루하루 성장한다는 느낌이 들어서 정말 즐겁게 일하고 있습니다.
패스트뷰에서 하고 계신 역할에 대해 설명해 주세요.
패스트뷰에서 제가 하는 역할은 개발자의 개발 환경과 서비스 안정성을 개선해, 결과적으로 파트너사에게 더 나은 서비스 경험을 제공할 수 있도록 도움을 주는 역할입니다. 구체적으로는 서비스 안정성 개선, 인프라 작업 자동화, 장애 예방 및 대응, 오픈소스 및 솔루션 PoC 진행, 비용 최적화, 개발자를 위한 데이터 분석 및 서비스 운영도구 제공 등의 업무를 담당하고 있습니다.
그동안 패스트뷰는 뷰어스 서비스를 확장시키는 데 집중해왔고 실제로 글로벌 시장을 확대하면서 많은 성과를 거두기도 했는데요. 성장에 주력해온 만큼 이제는 안정성과 효율성에 대해 고민이 필요한 시기가 왔고, 그 고민을 해결하는 것이 제 일이라고 생각합니다.
뷰어스 서비스가 트래픽 급증에도 안정적으로 작동하면서 동시에 빠르게 콘텐츠를 유통할 수 있도록 어떻게 인프라를 구성할지, 현재 구성에서 불필요하게 낭비되고 있는 인프라 비용을 어떻게 또는 얼마나 절감할 수 있을지, 어떻게 하면 개발자들의 서비스 개발 시간과 장애 대응 시간을 줄여줄 수 있을지. 이런 고민에 대한 답을 찾기 위해 데브옵스적인 역할과 SRE(Site Reliability Engineer)의 역할을 전반적으로 함께 수행하고 있습니다.
지성님이 생각하는 패스트뷰에 데브옵스 엔지니어가 필요한 이유, 무엇일까요?
서비스 개발자와 데브옵스 엔지니어 모두 서비스 경험을 개선한다는 궁극적인 지향점은 같지만, 이를 위해 각자 집중하는 문제점과 바라보는 관점, 방향성은 차이가 있어요. 그동안 패스트뷰의 서비스 개발자들이 개발 성과와 확장성에 주로 포커싱을 해왔다면 데브옵스 엔지니어는 개발자 편의도 고려하면서 좀 더 운영적인 측면에서 안정성과 효율성, 지속 가능성에 대한 서비스 개선을 이뤄나갈 수 있기에 필요한 포지션이라고 생각합니다. 뷰어스의 글로벌 성장과 장기적인 서비스 품질 향상을 위해서는 최대한 다양한 관점에서 의견을 공유하고 솔루션을 찾는 게 중요하다고 생각해요.
현재 가장 집중하고 있는 업무는 어떤 건가요?
현재는 한정적인 예산에서 낭비되고 있는 비용을 줄여 필요한 곳에 리소스가 투입될 수 있도록 비용 효율화 작업에 가장 집중하고 있습니다. 이를 위해 먼저 AWS 자원 사용량과 비용 분석을 진행했는데요. 약 4000개 정도의 많은 리소스를 사용하고 있기 때문에 Python과 Tag를 활용한 분류 자동화를 개발해 지속적인 관리가 가능하도록 했습니다. 분류를 통해 사용하지 않는 리소스를 정리하고, 의미가 없거나 의도하지 않은 부분의 구조를 변경했으며, 과도하게 비용이 발생하는 구성 요소는 변경하거나 대체재를 찾고 있습니다. 이외에도 개발 서버의 경우 사용하는 시간에만 가동되도록 Instance Scheduler를 구축했고, 적은 사용량을 기록하는 시간대에 성능을 낮추도록 하는 Lambda 함수를 개발하는 등 다양한 부분에서 비용을 줄이도록 노력하고 있습니다.
가장 기억에 남는 프로젝트가 있을까요?
분류 자동화를 통해 얻은 리소스 데이터를 MSP 솔루션의 API를 활용해서 저장하고, 보고 싶은 데이터를 정제해서 대시보드에서 보여줄 수 있도록 하는 프로젝트를 진행했었어요. 리소스 분류가 진행되니 여러 목적대로 비용을 산정할 수 있겠다 싶었거든요. 계산식을 통해 대략적인 사업부별, 서비스별 비용 현황 등의 데이터를 확인할 수 있는 대시보드를 만들어서 공유드렸는데 내부적으로 만족도가 되게 높았죠. 지금 집중하고 있는 업무가 마무리되면 좀 더 정확하고 각 사용자에 맞춤화된 도구를 만들어 볼 계획이에요.
업무하면서 가장 보람 있을 때는 언제인가요?
문제점을 파악해 도입했던 여러 가지 요소들이 유기적으로 맞물리면서 비용과 사용성이 동시에 개선됐을 때가 가장 뿌듯한 경험이었던 것 같아요. 많으면 하루에 10건이 넘게 오던 장애 알림이 이제는 한 달에 한 두건으로 줄었고, 응답 속도 또한 100배 가량 개선되었습니다. 또한 비용 절감도 지속적으로 이루어지고 있어, 이번 달에는 상반기 대비 30% 이상 비용이 줄어들 것으로 기대하고 있어요. 다양한 도전 과제를 놓치지 않고 성공적으로 해결해 나가고 있다는 점에서 가장 큰 보람을 느끼고 있습니다.
반대로 가장 어려웠던 점은 무엇인가요?
실시간으로 콘텐츠 트래픽, 유통 현황, 매출 등의 통계를 제공하는 뷰어스 솔루션의 특성상, 실시간 데이터에 영향을 주지 않고 개선해야 한다는 점이 가장 큰 부담으로 작용했습니다. 충분한 테스트를 거쳤다고 생각했는데 실제 서비스에 반영되었을 때 예상치 못한 부분이 발견될 수도 있고, 같은 결과가 나오지 않는 경우도 있으니까요. 실패했을 때 비즈니스에 미칠 영향이 무섭기도 했어요.
하지만 기존보다 더 나은 서비스를 위해서 리스크 테이킹은 반드시 필요한 부분이기 때문에 리스크를 최소화하여 지속적으로 서비스 개선을 이뤄나갈 수 있도록 노력하고 있습니다.
개발과 운영을 아우르는 데브옵스 엔지니어 직무 특성상 다양한 팀과 협업하고 조율하는 과정이 필요할 것 같습니다. 평소 어떻게 커뮤니케이션 하시나요?
개발자 팀원들과 대화할 때는 제 의견에 대한 논리, 방식, 이유, 예상 결과를 미리 정리해 놨다가 최대한 일목요연하게 이야기하려고 노력하는 편이고요, 그랬을 때 오히려 제가 생각하지 못했던 다른 문제점이나 의견을 주시기도 하고, 빠른 설득과 호응을 얻기도 합니다. 반면 비개발자 팀원들과 소통할 때는 최대한 쉽게 이해하실 수 있도록 기술적인 개념보다는 수치나 비용, 시간 등 구체적인 숫자나 기준점을 가지고 설명하려고 노력하고 있습니다.
자랑하고 싶은 패스트뷰 개발팀만의 문화가 있다면 소개해 주세요.
패스트뷰 개발팀은 자유로운 소통과 아이디어 제안을 추구하는 조직이에요. 누구나 자신의 의견을 자유롭게 이야기할 수 있고, 타당한 제안이라면 이를 실제로 실험하고 실행에 옮길 수 있는 기회가 열려 있죠. 꼭 자신이 속한 분야가 아니더라도 다양한 아이디어를 제시할 수 있고, 팀원 모두가 이를 존중하며 적극적으로 검토하는 분위기가 잘 갖춰져 있습니다. 이런 열린 환경 덕분에 함께 성장할 수 있는 팀 문화가 만들어지고 있다고 생각해요.
패스트뷰에서 이루고 싶은 목표, 계획이 있을까요?
최근 서비스 구성 요소를 컨테이너화하는 작업들을 진행하고 있는데요. 이후 오케스트레이션 도구를 도입해 보다 생산적이고 효율적으로 리소스를 사용할 수 있는 환경으로 전환을 계획 중에 있습니다.
장기적인 목표는 플랫폼 엔지니어링을 통해 우리 회사만의 툴을 개발하는 것인데요. 개발팀에게만 국한된 도구가 아닌 서비스를 운영하거나 데이터에 기반한 의사 결정을 도울 수 있는 도구를 만들고 싶습니다.
