이미 너무 잘하고 있는 티오더의 소방관들
티오더 DevOps 팀을 소개합니다.
티오더 DevOps 팀은
오늘 인터뷰의 주인공은 티오더 DevOps 팀입니다. ‘DevOps(Development Operations)’가 뭐 하는 팀이야? 하고 아마 DevOps 팀의 역할에 대해 생소하게 생각하는 분들이 많을 것 같은데요. 따라서 본격적인 인터뷰 시작에 앞서, 팀장 태환님께 간단한 팀 소개를 부탁드렸습니다.
태환: 쉽게 말해 문제를 정의하고 해결하는 팀, 서버 관리자라고 생각하시면 됩니다. 프로덕트에서 발생하는 문제점들을 트레킹하고 어떻게 해결할지를 고민하는 ‘소방관’과 같은 역할을 하는 팀이라고 보시면 될 것 같네요.
일정 규모의 IT기업들은 모두 DevOps 팀을 두고 있어요. 팀에서 발생한 문제를 각 팀 단위로 해결할 때 보통 자기 팀의 시야에서 자기 문제만을 해결을 하지만 DevOps 팀이 있으면 회사 전체의 시야에서 문제를 해결할 수 있어 화재(장애)예방에 보다 용이하기 때문입니다.
태환: 안녕하세요 저는 네이버 클라우드와 밀리의 서재에서 시스템 엔지니어나 솔루션 아키텍트 같은 직무로 일 했었고, 지금은 티오더 DevOps 팀 팀장을 맡고 있습니다. 이전 회사들에선 나타나는 시스템적 문제를 해결하기 위해 아키텍팅을 하거나, 각종 서비스 장애들을 해결했었고, 지금은 티오더 서비스에서 발생하는 각종 장애들을 해결하는 ‘소방관’ 역할을 하고 있습니다.
테이: 저는 완전한 DevOps는 아니고 처음엔 시스템 엔지니어를 3년 정도 하다가 DBA로(DataBase Administrator) 전향해서 지금까지 DB 업무를 해오고 있는, 18년 차 DBRE(Database Reliability Engineer) 입니다. DBRE는 기존의 DBA 업무와 DA(Data Architect)업무인 데이모델 설계, DB안정화와 성능을 위한 튜닝업무, 추가로 DevOps와 비슷한 롤로 자동화 및 플랫폼 개발 등의 업무까지 진행하고 운영하는 포지션이에요.
엘: 저는 티오더가 두 번째 회사예요. 이전에는 쿠버네티스(Kubernetes: 컨테이너화된 애플리케이션에 대한 자동화된 설정, 관리, 제어체계
)엔지니어로 일하면서 주로 금융권 회사들의 컨테이너 환경을 구축하고 운영하는 업무를 했었어요.
루미: 저는 티오더에서 백엔드 개발자로 커리어를 처음 시작했어요. 이전에는 주문 서비스 쪽 개발 유지보수, 웨이팅 서비스 쪽에서 조금씩 개발을 했었고, 티오더 DevOps 팀이 생긴 지금은 인프라 영역에 좀 더 집중하고 있습니다.
제이크: 저는 6년 차 백엔드 개발자로 일하다 티오더에서 DevOps 엔지니어로 전향한 케이스예요. 이전에는 커머스 관련 회사에서 B2C 결제 관련 시스템, 라이브 커머스와 관련된 개발 업무를 했었어요. 티오더에 처음 왔을 때는 태블릿 서비스 개발 업무를 하다가, 인프라 자원을 따로 관리하는 사람이 없어 이걸 관리하다 보니 자연스럽게 DevOps 개발자로 전향한 것 같아요.
태환: ‘온 콜 247’이라고 하는 게 있어요. 24시간 7일 365일. DevOps 팀은 항시 대기를 하면서 문제를 감지하고 빠르게 행동할 수 있는 역량이 중요해요. 그러다 보니 아무래도 책임감이 뛰어나신 분들이 주로 DevOps 직무를 하는 것 같습니다.
루미: 일단 수용력이 있어야 한다고 생각해요. DevOps는 자기 서비스가 아닌 다른 서비스들에 대해서도 봐야 해서 알야야 하는 것도 많은 편이에요. 따라서 사전 지식이 없더라도, 기본적인 지식만으로도 파악할 수 있는 능력이 필요해요.
태환: 저희는 서비스를 만드는 팀이 잘될 수 있게 도와주는 팀이에요. 그들의 고통도 저희의 고통이고 저희 고통도 저희의 고통이에요. 그래서 저희는 항상 두 배로 고통을 받다 보니 이런 스트레스의 역치 조절 또한 중요하다고 생각합니다.
테이: DB는 일종의 꼼꼼함, 체계적으로 업무를 하는 역량이 많이 요구됩니다. 특히 다른 영역보다 전문 지식이 깊게 필요한 영역이에요. 데이터 모델링이나, 일반적인 이론 영역들과 실제 서비스의 갭 간에서 중간 점을 찾는 능력도 중요하고요.
하지만 무엇보다 특히 스타트업 DB 담당자라면 자기 서비스를 애정할 줄 알아야 한다고 생각합니다. 개발 단계나 기획 단계에서 적극적으로 참여해, 처음부터 최적화된 데이터 모델을 뽑아내고 시작하는 게 가장 좋은 업무 방법이라고 생각하기 때문이에요. 그렇기에 좀 더 적극적으로 서비스에 대해 관심을 갖고, 오지랖도 부리면서 동료들하고 친해지려고 노력하는 것 또한 중요하다고 생각합니다.
태환: 요즘은 주로 컨테이너 기반 서비스를 빌드 하는 일을 많이 하고 있습니다. 그냥 단순히 컨테이너 하나를 만드는 것이 아닌 티오더 서비스 전체를 패키징 하는 일을 하고 있어요. 쉽게 말씀드리자면 티오더는 계속 플랫폼화하고 있는데, 서비스 자체가 너무 커다랗다 보니까 이것을 틀처럼 찍어내기가 힘든 상황입니다.
패키징이 잘 돼 있으면 티오더 미국 법인에서 이것을 그대로 가져가도 문제없이 서비스가 동작합니다. 이전에는 이 패키징이 제대로 이뤄지지 않았다 보니, 서비스 간 문제를 파악하는데도 어렵고 시간이 많이 걸렸었어요.
따라서 저희는 현재 티오더 서비스 글로벌 대응을 보다 빠르게 해내기 위한 틀을 만들고 있습니다. 패키징이 잘돼있으면 아무리 사용자가 늘어나도 자동으로 대응할 수 있고, 개발자들은 꼭 신경 써야 할 부분만 신경 쓰며 개발할 수 있어요. 저희 또한 인프라 등 꼭 관리해야 되는 부분만 신경 쓰며 관리할 수 있어 훨씬 효율적이죠.
이러한 패키징화 정리는 어느 정도 다 끝난 상태고, 지금은 좀 더 ‘예쁘게’ 찍어내는 방법에 대한 고민을 하고 있는 단계입니다.
티오더 데브옵스팀, 글로벌 GenAI Hackathon에서 글로벌 3위(국내 1위) 달성
태환: GenAI Hackathon은 AWS코리아 오피스에서 아시아태평양 및 일본(이하 ‘APJ’) 지역 기반 30여개의 스타트업들을 대상으로 개최한 대회입니다. 저와 루미, 엘, 제이크님 네 명이 “팀 매너티”로 참여해 1시간 29분만에 가장 빠르게 모든 문제를 다 풀었어요. 대회에서는 글로벌 3위 달성(국내 1위)를 했는데, 1번 문제를 5분만 더 빨리 풀었어도 글로벌 1등을 하지 않았을까 하는 아쉬움이 있네요.
제이크: 압도적으로 빨리 풀었기 때문에 대회장 리더보드에 저희 팀이 계속 1등으로 떠 있었어요. 그러다가 막판 5분 즈음에 따라 잡힌 거다 보니 특히나 더 아쉬웠던 것 같아요.
태환: 우선 저희 팀은 각각의 백그라운드가 조금씩 다릅니다. 그래서 처음 문제를 접했을 때, 각자의 성향에 맞게끔 문제를 배분했어요. 대회 당시에 딱 본인 성향에 맞게끔 문제를 해결할 수 있도록 배분했고, 막힌 부분이 생기면 빠르게 공유해 누군가는 풀 수 있도록 빠르게 도움을 드릴 수 있도록 한 것이 아무래도 큰 도움이 됐다 생각합니다.
태환: 네! 그럼요. 지금의 DevOps 팀이 이 구성이 된 게 올해 4월 즈음인데요. 얼마 되지 않은 시점 팀워크를 증명할 수 있어서 좋았습니다! 이건 여담이지만 우승 상품이 에어팟이라는 것이 특히 저에게는 중요한 포인트였어요. 루미님이 구형 에어팟을 사용하고 계셨어서 기회가 되면 바꿔드리고 싶었는데 딱 기회가 온거죠. ‘꼭 이겨서 바꿔드리자!’ 가 목표였는데 바꿔드리게 돼서 정말 기쁩니다.
제이크: 다음에는 꼭 테이님도 함께, 다 같이 나가서 1등을!
루미: 글로벌 1등!
테이: 다음엔 저도 같이 가서 에어팟 받고 싶네요….
엘: 같이할 수 있다면 또 나가고 싶습니다. 너무 좋은 동료들과 좋은 결과를 낸 것 같아 영광입니다!
그런데 사실 이게 평소에 습관화돼있지 않았다면 대회에서 바로 적용하긴 힘들었을 것 같은데요. 이쯤 되니 DevOps 팀의 평소 분위기와 업무 스타일이 궁금해집니다.
태환: 저희 DevOps 팀의 전체적인 분위기는 호기심을 충족하려는 욕구, 목표를 향해 나아가려는 목적의식이 강한 팀입니다. 어떤 일이든 할 수 있고, 항상 일을 높은 효율로 처리하기 위해 고민합니다. 또 DevOps 팀에는 문제 상황에서 자신이 주장하고 싶은 바는 모두 자유롭게 말할 수 있는 토론 문화가 있습니다.
태환: 각 잡고 정해진 일정을 두고 하진 않아요, 업무하다가도 잠깐씩 멈추고 자리에서 모여 토론하고 방향성을 다시 잡고 그래요. 저희 같은 경우에는 업무하다가 스스로 만족하지 못하는 것들이 있는데, 엔지니어링에 대한 기준점이라든지, 어느 정도까지 해야 한다라는 게 사람마다 다르기도 하다 보니, 그럴 때마다 이게 옳은가에 대해 치고받고 합니다. 저는 엔지니어가 고집이 있게 자신의 주장을 할 수 있어야 된다고 생각해요.
태환: 보통은 제가 정리를 해요. 그러면서 ‘이거에 대해서 이 만큼까지 납득할 수 있냐’ 물어보고, 납득할 수 있는 범위까지 조율 합니다. 베스트는 아니더라도 서로가 효율성이나 형태에 대해서 납득을 할 수 있는 것을 취하고자합니다.
일과 자격증공부 두 마리 토끼를 모두 잡는 DevOps 팀
AWS의 골든재킷 &Kubernetes의 블루재킷을 아시나요?
태환: AWS의 공인인증자격증이 매 해마다 생겼다가 없어졌다가 합니다. 아마 지금은 12개의 자격증을 따야 할 것이고, 저는 총 14개의 자격증을 취득했어요. 전부 취득하기까지는 2년 정도 걸렸고, 꾸준히 갱신 해 와서 현재 4년 가량을 올서티(13개 자격증 보유)를 유지 중입니다. 골든 재킷은 이러한 AWS의 모든 자격증을 취득하면 얻을 수 있다고 전설처럼 전해졌던 이야긴데, 이번에 수령하고 나서 전설이 아니라 실존한다는 것을 알 수 있었죠.
AWS에서 이렇게 재킷을 받는 분들이 좀 있는 편인가요? 아무래도 13개의 자격증을 모두 따는 것은 쉽지 않아 보여서요.
제이크:엄청 귀하죠.
태환: 올스타라고 하는데 이거는 좀 난이도가 있긴 해요.다 따려면 보통 한 2년씩은 걸리는 것 같아요.
엘: 제가 딴 자격증 같은 Kubernetes라는 컨테이너 오케스트레이션 툴에 대한 운영과 구성에 대한 능력을 시험하는 실습 위주의 자격증입니다. 총 5개의 자격증을 모두 취득하면 블루재킷을 줍니다. 제가 처음으로 자격증은 취득한게 21년도 말이었으니, 모두 취득하기까지는 총 2년 반 정도의 시간이 걸렸네요.
태환: 저는 워낙 그 분야를 즐기기도 하고 오랜 기간 해왔기 때문에 그렇게까지 힘든 건 없었어요. 굳이 꼽자면 틈틈이 공부할 시간을 내는 게 가장 어려웠죠.
퇴근 후 매일 2시간씩 공부하셨다 들었는데, 그 자체만으로 쉽지 않은 일 같아 보여요.
태환: 결국 그만큼 끈기가 중요하지 않나 싶기도 하지만, 또 이 분야를 얼마큼 재미있게 느끼냐도 중요한 것 같아요. 아무래도 자기와의 싸움을 매일같이 해야 하니깐요. 티오더 임직원들 중 AWS 자격증 취득이나 공부 관련해 도움이 필요하면 언제든지 연락 주세요!
엘: kubernetes 자격증은 다른 자격증 시험과 달리 실제로 환경이 주어지고 그 안에서 문제를 풀어가는 방식이에요. 그렇기 때문에 실무에 직접 적용할 수 있는 부분도 많아서 실무 하다가 바로 시험을 봐도 괜찮다 생각했어요. 사실 저는 공부를 좀 닥쳐야 하는 스타일이어서 시험료 먼저 결제한 것이 공부의 큰 원동력이 되지 않았나 싶습니다. (웃음)
앞으로의 DevOps 팀은,
엘: 우선 저희 과제 중에 제일 큰 게 컨테이너 전환이기 때문에 이걸 완수하고 안정적으로 운영하는 것이 목표입니다.
루미: 주문 서비스 개발 쪽에서 제가 맡았던 부분들이 더 완벽한 프로덕트로 만들어지는 것을 보고 싶습니다.
제이크: 앞으로는 좀 더 방대한 트래픽에서 안정적으로 구성하고 지원할 수 있는 지에 대해 고민하고, 아키텍트로서 시스템 구성과 안정성을 가질 수 있는 솔루션과 아이디어를 내줄 수 있는 사람이 되고 싶습니다.
테이: 일단은 티오더에서는 근본적인 데이터 모델을 개선하는 게 큰 목표예요. 그 이외에는 데이터 분석 쪽이나 그다음에 ML이나 AI 쪽 데이터 쪽을 기회가 있다면 더 다뤄보고 싶기는 합니다.
태환: 저는 현재 티오더에서 한 2년 정도까지의 계획을 세워놨습니다. 티오더 내 아키텍처의 변경을 Event Driven 형태라고 해서 이벤트가 발생하면 그것들을 백엔드에서 처리하기 위한 형태로 만들고자 합니다. 그리고 그 아키텍처를 티오더에 정착시키고 잘 운영되는 형태로까지 가는 걸 2년 정도로 판단하고 있습니다.
마치며
한창 인터뷰 진행 중에 CTO이신 태욱님이 인터뷰 자리에 들렸습니다.
태욱 님이 나가고 바로 이어서 태환 님이 이어 말했습니다.
태환: 늘 하는 말인데, 열심히 하지 않고 잘해야 합니다.
태욱 님이 오신 김에 여쭤보고 싶어요. DevOps 팀과 태욱 님은 어떤 방식으로 일을 하나요. 별도로 만나는 위클리 같은 미팅 시간 같은 게 정해져 있나요?
태환: 별도의 미팅이 정해져 있지는 않고, 저희가 궁지에 몰리고 선택지만이 남아 있을 때, 찾아가 판단을 요청하고 있습니다. 저희는 다들 목적지만 보이면 달릴 수 있는 원동력은 가지고 있어요. 그런데 그 목적지로 갈 때 어느 게 더 중요한지 비중을 나눠 판단하기가 어려울 때가 있습니다.
그럴 때 이런 고민을 태욱 님께 맡기면 정말로 날카로운 결정을 해주십니다. 문제 정의와 해결책, 해결되지 않았을 때는 또 어떻게 해야 하는 지까지도 함께 고민해 주십니다. 태욱 님이 이렇게 딱 정해주면 저희는 이제 경주마처럼 달릴 수 있어서 너무 좋습니다.
태욱 님은 이전부터 투명하고 예측 가능한 의사소통을 강조하셨는데, 실제 R&D그룹과 업무할 때도 그런 성향이시군요. 좋은 말씀 감사합니다 태환님. 이제 정말 마지막으로 남길 말씀이 있으신가요?
태환: 저희가 서로 간의 신뢰에 기대서 일하는 것도 매우 멋진 형태라고 생각하지만, 신뢰 다음에도 가져와야 될 영역이 바로 기술력이라 생각합니다. 시스템화되고 우리가 이것들을 다룰 때 문제가 없어야 하는데, 이건 다시 말하지만 ‘잘’ 해야지만 가능한 영역이라 생각해요.
이제 이걸 위해 우리가 무엇을 만들어 가야 할지 잘 생각해 봐야겠죠. 과연 잘할 수 있을까, 이건 저 스스로에 대한 고민이기는 합니다. 그런데 잘할 수 있을 거라 생각합니다. 제가 어려워해도 팀원들이 잘해 주실 거라고 믿습니다.