채널톡 DevOps팀이 일하는 법

안녕하세요. 채널팀 Developer Relations 소마입니다.

오늘은 채널톡 DevOps팀을 이끌고 있는 씨에스(CS)를 만났습니다. 데브옵스라는 이름은 회사마다 다르게 불립니다. 인프라팀, SRE, 클라우드팀... 이름이 다른 이유는 간단합니다. DevOps는 직군이 아니라 문화이기 때문이죠. 그렇다면 채널톡의 데브옵스팀은 이 문화를 어떻게 정의하고 있을까요?

혼자 다 하던 사람에서, 팀을 만든 사람으로

Q. 간단한 자기소개와 채널톡 DevOps팀에 합류하게 된 계기를 들려주세요.

저는 채널의 전신인 조이 코퍼레이션 시절에 입사했어요. 워크인사이트라는 제품에서 센서 펌웨어를 만들었는데, 그 제품이 2020년에 문을 닫으면서 채널톡 백엔드 엔지니어로 합류했습니다.

그땐 지금보다 인원이 훨씬 적었고, 새로 합류한 사람이 빠르게 따라가기 어려운 환경이었어요. 저는 더 쉽고 빠르게 배포하고 실수를 줄일 수 있는 환경을 만드는 일에 관심이 갔고, 그 문제들을 하나씩 풀다 보니 제가 하던 일이 별도의 팀으로 분리됐습니다. 그렇게 DevOps팀이 생겼고, 동료가 하나둘 늘면서 3년째 함께 달려오고 있어요.

Q. 지금은 어떤 모습인가요?

처음엔 "이것 좀 도와주세요"에 대응하는 팀이었다면, 지금은 훨씬 주도적으로 일합니다. 예전엔 배포 스크립트를 하나씩 돌렸다면, 지금은 배포를 위한 '제품'을 만들어서 각 팀이 셀프서비스로 직접 배포할 수 있게 했어요.

예전엔 애플리케이션이 10개 정도라 다 파악할 수 있었지만, 지금은 800개가 넘어요. 이 정도 규모는 자동화와 규격화 없이는 따라갈 수 없습니다. 그런 준비를 해온 덕분에 AI 시대에도 빠르게 대응할 수 있는 기반이 마련됐다고 생각해요.

데이터 파이프라인 준비, 보안 팔로업, 문제 발생 시 함께 대응하는 SRE 역할, 플랫폼 관리, 클라우드 비용 관리까지. 지금 저까지 포함해 6명, 실질적으로는 5명이 이 모든 걸 하고 있어요. 힘들지만 재밌는 건, 어디에 집중해야 할지 계속 고민하고 우선순위를 다시 세울 수 있기 때문이에요.

기반을 만드는 일, 도시를 만드는 일과 같다

Q. 엔지니어링 전체에서 팀이 맡고 있는 역할을 한 문장으로 표현한다면요?

결국 기반을 만드는 팀입니다. 도시를 만들 때도 물, 전기, 하수도, 도로가 먼저 갖춰져야 하잖아요. 그게 없이 아파트를 지어봤자 전기 안 올라오는 아파트는 의미가 없죠. 저희가 하는 일이 그런 겁니다. 그리고 한 번 해놓는다고 끝나지 않아요. 계속 유지보수하고, 그걸 잘 하기 위한 도구까지 만들어야 합니다.

Q. 처음 채널팀 백엔드 엔지니어였을 때와 지금, 달라진 점은 무엇인가요?

예전엔 문제를 찾는 속도보다 문제가 다가오는 속도가 훨씬 빨랐어요. 지금은 버퍼가 생겨서 미래를 위한 투자를 할 수 있게 된 게 가장 큰 변화예요. Istio 도입이나 Platform 개발 같은 게 그런 투자죠.

Istio는 단순히 가져다 쓰는 데서 그치지 않고 동작 원리를 깊게 파고들었어요. 가져다 쓰는 게 많아질수록 어떻게 동작하는지 모르면 문제가 생겼을 때 더 크게 터지거든요. 저희 팀은 기술을 탑다운(Top-down)으로 정하지 않고, 팀 내 컨센서스(Consensus)를 맞추고 왜 그런지를 명확히 하고 진행합니다.

되돌릴 수 있는가, 그것이 기준이다

Q. 최근 가장 도전적이었던 기술 과제는 무엇인가요?

서비스가 커지면서 저희가 직접 짜지 않은 코드도 안정적으로 돌아가야 하는 상황이 늘고 있어요. AI가 생성한 코드일 수도, 고객이 올린 코드일 수도 있죠. 이런 신뢰할 수 없는(untrusted) 코드를 어떻게 안정적으로 운영할까, 이게 정말 흥미로운 문제예요. AI가 발전해도 결국 신뢰할 수 없는 코드를 실행시켜야 한다는 본질은 같거든요. 그래서 결국은 제로 트러스트(Zero Trust) 형태로 가야 한다고 봅니다.

솔직히 아직 부족한 부분도 있어요. 규격화는 갈 길이 멀고, 문제를 빠르게 감지하고 고칠 수 있는 모니터링 체계도 아직 부족합니다. 저희 팀만 잘한다고 되는 게 아니라 전사적인 규격이 필요한 일이라 계속 고민하고 있어요.

Q. 기술적인 의사결정을 할 때, 트레이드오프(Trade-off)는 어떤 기준으로 다루나요?

저는 항상 하나를 물어봐요. "이게 얼마나 쉽게 되돌릴 수 있는가." AI 덕분에 시도해보는 비용은 낮아졌지만, 한 번 정해지면 되돌리기 어려운 결정들은 전사적 비용, 심리적 비용이 크거든요.

쉽게 바꿀 수 있는 거라면 일단 빨리 해봅니다. 어려운 거라면 충분히 고민하고, 적어도 2, 3년은 갈 수 있는 기술을 택해요. 평생 가는 기술은 없으니까요. 인프라는 기초를 잘못 다지면 건물이 다 올라간 뒤에야 문제가 드러나요. 그러면 시간도 비용도 두 배로 들고, 결국 그 일을 하는 사람이 지쳐서 나가떨어집니다. 그 소모를 최대한 줄이고 싶어요.

성장, 그리고 오너십

Q. 리더로서 요즘 가장 깊게 고민하는 부분은 무엇인가요?

결국은 성장이에요. 개인도, 팀도, 회사도 성장해야 하고, 성장하지 않으면 사람들이 여기 남아 있을 이유가 없어요. 예전엔 성장을 개인의 몫이라 생각했는데, 요즘은 팀원들이 주도적으로 성장할 수 있는 환경을 만들어주는 게 제 역할이라고 생각해요. 책임질 수 있는 범위를 조금씩 넘겨주고, 팀원의 성과가 드러날 수 있는 무대를 의도적으로 만들어주려고 합니다.

Q. 그렇다면 잘하는 DevOps팀이란 어떤 팀일까요?

"잘한다"의 기준은 회사의 크기와 상황에 따라 달라요. 하지만 본질은 하나, 소프트웨어를 더 빠르고 안정적으로 배포하는 것이죠.

DevOps에는 유명한 무한 루프가 있어요. 이 루프를 얼마나 빠르게 돌릴 수 있느냐가 핵심입니다. 진짜 잘하는 팀은 이 루프가 개발 단계에서 끝나지 않고, 고객과 세일즈의 피드백까지 이어져 회사 전체가 빠르게 돌아가게 만드는 팀이에요. 결국 오너십을 가지고 회사 전체의 안전성과 속도를 높일 수 있는 것이 잘하는 DevOps팀이라고 생각해요.

우리 팀과 잘 맞는 사람

Q. 채널톡 DevOps팀과 가장 잘 맞는 엔지니어는 어떤 사람인가요?

반대로 안 맞는 사람부터 말씀드릴게요. 아무리 똑똑해도 혼자 일하는 사람은 어려워요. 저희는 기준과 표준을 함께 세워야 하는 팀인데, 한 사람의 생각만으로 정해지고 공감받지 못하면 문화로 퍼지질 못하거든요.

반대로 저희가 좋아하는 사람은 커뮤니케이션이 잘 되는 사람이에요. 자기 주장의 근거를 명확히 설명하고, 그걸 바탕으로 팀의 기준을 함께 세워가는 사람. 그리고 딥다이브를 좋아하되, 혼자만 파고들고 끝나지 않는 사람이요.

재밌는 지점은 자기만의 철학이 있는 것과 혼자 일하는 건 다르다는 거예요. 기준을 스스로에게 적용하는 건 좋지만, 그 잣대를 남에게 들이대는 사람과는 같이 일하기 어렵습니다. 팀 차원의 방향이 정해지면 거기에 맞추려는 태도가 중요해요. 다만 그 전까지는 최대한 많이 이야기하고 자기 생각을 말해줬으면 좋겠어요.

Q. 마지막으로, 미래에 합류할 팀원에게 한마디 부탁드립니다!

저희 팀은 논쟁하는 걸 즐기고, 자기만의 철학과 문제의식을 가지고 이슈를 제기하는 걸 두려워하지 않는 사람들이 모여있어요. 이런 성향과 잘 맞는 분이라면 정말 즐겁게 일할 수 있을 거예요.

그리고 채널 DevOps팀과의 커피챗은 언제나 열려 있으니 많이 신청해 주세요!

DevOps Engineer 커피챗 신청하기 ☕️