[Cloud]TossBank DevOps팀이 일하는 방식

서론

같이 공부했던 사람들과 이야기하며 토스 CNI를 검색해보게 되었다. 그 과정에서 토스 컨퍼런스와 기술 블로그를 봤는데 그 중 가볍게 본 컨퍼런스 영상에 대해 인사이트를 얻었다. 때마침 스터디 방향성도 조정되어 이를 기록하고 생각을 나눠보고자 한다.

---

영상

https://youtu.be/_pz3CxNdXEU?si=7Tp9a_XbovFFYPyj

TMC25 | Engineering - 작지만 강한 DevOps Team 운영하기

 

내용 정리

뭐 하는 팀인가?

Platform Division: 서비스 운영을 위한 플랫폼과 인프라를 책임지는 조직

Server Platform Department: Server Plaform 팀과 DevOps 팀

 

DevOps 팀이 하는 일

• Kubernetes 클러스터
• 여러 내부 시스템들을 운영 및 최적화

 

DevOps 팀은

• 지원 조직 (무언가를 달성하는 것이 아니라 어떤 변화에도 준비되어 있는 상태를 유지하는 것이 목표)
• 시스템 구조를 바꾸거나 새로운 기술을 도입할 때, 일상적인 업무들(빌드, 배포, 모니터링)의 생산성을 높이고 전체 시스템의 복잡성을 낮추는 것을 중요하게 생각한다.
• 새로운 오류에 대응하거나 트래픽이 늘어나는 것과 같은 예외 상황에도 안정적으로 동작하고, 문제 원인을 분석하기 쉬운 시스템을 만들기 위해 노력한다.
• 그 과정에서 보안이나 컨플라이언스를 준수한다.

 

작으면 좋은가?

N사(4백만명, 9명)와 T사(9억명, 60명) 등의 사례를 보았을 때, 서비스 규모와 개발자 수가 비례할 필요는 없는 거 같다. 

→ 인원 수보다는 일하는 방식이 중요하다!

 

 

무엇을 할 것인가? 

계획?

• 계획은 문제가 예측 가능할 수록 효과적이다.
• DevOps 업무는 예측하기 어려운 경우가 대부분이다.
  • 라이브 모니터링 시스템에 문제가 생겼다? → 오늘 바로 해결해야 한다
• 미리 세워둔 계획이 많으면 상황에 맞춰서 대응하기가 어려워진다.

→ 우선순위를 유연하게 판단하고 빠르게 실행하는 데 집중한다. (Like Greedy 알고리즘)

 

어떻게 할 것인가?

역할

• 개인 중심 R&R?
  • 인원이 적다보니 개인이 차지하는 비중이 커지게 된다.
  • 한 명이 자리를 비우게 되면 비는 부분이 크다.
• 팀 중심 R&R!
  • 팀원 모두가 서로 업무를 대체할 수 있도록 공유하는 방식

 

업무

• 장애 대응 당번은 나누지 않는다.
  • 빠르게 해결하는 게 제일 중요하다.
• 요청 대응 당번은 정한다.
  • 장애보다는 속도가 덜 중요하다.
  • 요일별 운영

 

소통

• 미팅을 거의 하지 않는다.
• 메신저 논의를 주로 한다.
  • 자리나 전화로 이야기를 나눌 수도 있지만, 이것도 메신저로 공유한다.
  • 모든 사람들이 확인 가능하며, 시간이 지나도 검색이 가능하다.
  • 개인 메시지보다는 공유되는 채널에 남겨 달라고 부탁을 하기도 한다.

 

정말로 사람이 부족한가?

일이 많다 != 사람이 부족하다

• 일을 떠올리는 속도 > 일을 처리하는 속도
• 할 일이 정해져 있고, 그걸 나눠서 할 사람을 찾는다 → 사람이 필요할 수 있다
• 사람이 정해져 있고, 각자 할 일을 판단한다 → 그만큼 필요한 일만 하게 된다

우리의 현실은 후자에 가깝다고 생각한다.

 

사람이 부족하다고 생각이 든다면, 일하는 방식에 대해서도 생각해봐야 한다.

일이 많다면 중요한 일에 집중해야 한다. 이에 대한 기준이 명확해야 한다. 

→  우리는 ROI (Return on investment) 비용 대비 효율을 중요하게 생각한다.

 

하면 좋은 일들 중에 해야 하는 일은 적다고 생각한다. 효용이 비용보다 커야 한다. 이 크기는 수치화가 안되기 때문에 팀원들과 논의를 하거나 기댓값과 비슷하게 생각하는 것이 도움이 된다.

 

• 효용: 네트워크 성능 향상
  • 얼마나 기대할 수 있는지, 우리에게 그것이 필요한지
• 비용
  • 여러 계층에서 진행되어야 한다. →  꽤 크다
• 네트워크 성능 문제가 명확해지고, 간단한 대안들이 시도된 이후가 아니라면 하면 좋은 일이라 판단

• 효용
  • 분산 부하가 얼마나 되는지, 얼마나 개선할 수 있을지
• 비용
  • 공통 설정을 바꿔서 서비스들을 배포 →  크진 않다
• 특정 노드에 몰려서 서비스에 영향이 있었다면 해야 하는 일이라 판단

 

하지 말아야 하는 일 != 하면 안 좋은 일

 

개발자는 고객인가?

• 잘못된 내용은 아니다. 
  • 개발자가 이런 기술을 써보고 싶다고 건의. 하지만 ROI가 별로인 상황  
  • ROI가 별로니까 하지 말아야 하나? 고객이 개발자라면 고객 중심으로 해야 하니 도입해야 하나? →  애매하다
• 우리 고객은 토스뱅크 고객이라 정의해보자.
  • 도입을 했을 때, 결과적으로 토스 뱅크 고객의 효용으로 이어질까?
  • 동료의 기술 선호도는 중요하지 않다.
    • 지원 조직의 역할은 동료를 섬기는 게 아니라 유능하게 만드는 것

 

고민해 봐야 할 것: 미리 해야 하는 일은 무엇일까?

 

정리

뭐하는 팀인가? 가상화 계층에서 코드보다 인프라와 가까운 일

작으면 좋은가? 계획보다는 대응에 집중

무엇을 할 것인가? 미팅보다 메신저로 소통

어떻게 할 것인가? 우선 순위는 ROI를 중심으로 판단

정말로 사람이 부족한가? 우리의 고객은 동료 개발자가 아닌 토스뱅크 고객

 

느낀 점

최근 인프라를 담당하며 직접 느끼고 배운 점을 관통하는 내용이 있었다.

계획적으로 처리할 수 없다는 것. 인프라 및 DevOps의 경우 정말 다양한 일들이 많다. 물론 나의 경우 대규모가 아니기에 충분히 고려하면 예방할 수 있는 부분이지만, 실무에서는 정말 많은 예외 상황들이 존재할 것이다. 이를 예방하고 대응하기 위해서는 평소 지식이 깊고 풍부해야 한다 생각한다. CS 지식이 정말 중요한 분야 중 하나가 아닐까.

 

그리고 새롭게 느낀 내용은 사람 수보다 일하는 방식이 중요하는 것이다. 혼자서 생각한 적은 있다. 사람을 교육시키고 가르치는 것보다 혼자서 일처리하는 게 속도가 더 빠르지 않을지, 그렇다면 신입은 왜 필요한지. 부정할 수 없다고 생각했다. 내가 아무리 취업 준비생이라 부정하고 싶어도 이성적으로 생각했을 때 사람을 늘리는 것보다 시스템을 바꾸는 게 더 나을지도 모르겠다고 생각했었다. 아직도 이에 대한 의문이 해결되진 않았다. 다음에 기회가 되면 찾아봐야겠다.

 

메신저 논의 좋다고 생각했다. 글로 정리한 내용을 서로 공유하는 것이 다시 찾아보기에도 좋고, 내 생각을 정리해서 전달하기에도 좋다는 생각을 했다. 또한 모든 사람이 내용을 공유할 수 있다는 것도 장점이다. 이러한 메신저 논의 문화가 자리만 잘 잡는다면 훨씬 더 효율적일 수 있다고 생각했다. 

 

결과적으로, 내 역량을 많이 키워서 혼자서도 일을 처리할 수 있는 사람이 되어야 한다는 생각이 많이 들었다.