DevOps 원칙에서 배우는 자기관리법

요 며칠간은 모든 것이 정리가 되지 않는 기분이었다. 일은 일대로 의욕이 나지 않았고 뭔가 인생 전체가 정리가 되지 않은 찜찜한 기분이었다. 해야 하는 것들에 진척이 없었고 온 몸이 찌뿌둥했다. 뭐라도 일어나라, 될대로 되라지 하고 포기하고 있자니 며칠 전에는 수해가 우리 집을 덮쳤다. 천장에서 내려온 물 때문에 우리 집 현관부터 욕실, 화장실, 부엌까지 모든 것이 다 젖었고 우리는 임시주택으로 거처를 옮겨야 했다. 일이 내 마음대로 진행되지 않아서 짜증이 났고 새로운 거처에 적응하자니 피곤했다. 그럼에도 루틴을 지키자는 마음으로 일요일 아침 책을 집어들었다. DevOps 책이었다.

개발자나 IT 부서에서 일하지 않는다면 DevOps라는 용어가 생소할 수 있다. 간단히 설명하자면 DevOps는 조직의 기능별로 움직이기보다는 조직이 목적 달성을 위해 분야를 나누지 않고 움직이는 방법론이라고 할 수 있다. 전통적인 회사에서 개발자 (Developer) 는 새로운 기능을 구현하거나 버그를 고쳐서 소프트웨어를 개발하고, 운영자 (Operation) 는 소프트웨어가 돌아갈 수 있도록 인프라를 운영하고 감시하는 역할을 한다. 즉 두 팀은 다른 부서로 나뉘어 자신의 역할을 하게 되는데, 여기서 개발자가 빠르게 새로운 기능을 배포하고 싶어하는 반면 운영자는 안정적인 운영이 제 1 목표이므로 변화를 꺼리게 되니 개발자와 상충되는 목표를 가질 수 밖에 없게 된다. 하지만 궁극적으로 두 팀은 모두 프로덕트가 시장에서 독점적인 위치를 차지하여 많은 유저가 이용할 수 있도록 하는 공통적인 목표를 가지고 있기 때문에, 두 팀을 같은 방향으로 움직이는 것이 필요하다. 이 지점에서 DevOps에 관한 논의가 시작된다.

DevOps는 2000년 이후 Lean development나 agile 등의 논의와 더불어 비교적 최근에 나온 개념이라고 할 수 있으나, 기반으로 삼고 있는 운영방식과 철학은 1980년대의 일본 제조업에서 사용되었던 개념들이 중심이 된다. 당시 일본의 제조업 회사들이 생산한 제품들은 미국에서 불티나게 팔리고 있었던 일본의 호황기였고, 해외 기업들은 어떻게 일본이 제조업에서 혁신을 이루었는가 연구하기 시작했다. 이 때 Kanban 이나 Toyota kata (지속적인 개선을 위한 방법론) 와 같이 일본 제조업이 실행했던 방법들은 DevOps 에서도 그대로 사용되는데, 책을 읽으면 읽을 수록 이 원칙들은 일 뿐만 아니라 나 자신에게도 도입할 수 있을 것이라는 생각이 들었다.

먼저 앞서 말했던 Kanban이다. Kanban 은 看板, 즉 한국어로는 간판이라고 말할 수 있는데 한 눈에 볼 수 있는 판이라는 뜻이다. Kanban 보드라고 불리는 판 위의 X 축은 일의 진행상태에 따른 단계로 구성되어 있다. 예를 들어 아직 시작되지 않음, 외부 부서에 의해 진행이 어려움, 진행 중, 품질 검사 중, 완료 등의 단계가 있다. 각 단계의 아래에는 그 단계에 속하는 여러 작업들이 위치해있다. 이렇게 한번에 어떤 일이 현재 보드 위에 있고 어떤 상태에 있는지 관리함으로써 일 전체가 어떤 흐름에 있는지 확인하기 쉬워진다.

개발 부서에서 흔히 사용하는 Kanban board

지난 며칠 간을 돌아보니 내가 무슨 일을 해야하는지 파악도 하고 있지 않았고 그나마 해야하는 일들이 어떤 진행 상태에 있는지도 몰랐던 것이 떠올랐다. 그러니 일을 하기는 해야할 것 같은데 무엇부터 시작해야 할 지도 몰랐고 일이 안되면 무엇 때문에 안되는지, 일을 되게 하기 위해 어떤 것을 해야 하는지 순서도 생각할 수 없었다. 막연하게 시간은 흘러가는데 일을 끝내지 못했던 것이 생각났다. 뭔가 일을 해야할 것 같기는 한데 끝내지 못해서 계속 질질 끌었던 것도 생각났다.

DevOps에서는 이렇게 막연하게 일을 끌지 않기 위해 진행하는 일의 숫자를 한정하고, 또한 가장 최소의 단위로 쪼개서 하라는 원칙이 있다. 일을 할 때 중요한 것은 어쨌든 그 일을 시작하는 것이 아니라 일을 끝내는 것이라는 의미에서이다. '시작이 반이다' 라는 말을 가슴에 품고 살아온 나의 입장과는 정반대의 주장이었다. 사실 나를 포함한 많은 사람들은 무언가 열심히 하고 있다는 감각에 안심이 된다. 그래서 지금 진행하고 있는 일이 얼마나 있는가와 상관없이 새로운 일을 벌이기도 한다. 하지만 결국 성과를 이루었다는 것은 어떤 일을 끝까지 완수했다는 의미이므로, 시작하는 것이 중요한 것이 아니라 끝내는 것이 중요하다는 말은 결과적으로 타당하다. 또한 일의 크기를 쪼개서 하라는 것은 제조업에서 batch size를 줄여서 효율을 높이는 방법론에서 온 것인데, 어떤 일이 해야하는 업무의 수가 많고 들이는 시간이 많아지면 그 일을 하는 동안 외부에서 다른 개입이 올 때마다 중간에 일이 진행이 느려질 수 있고, 그럴 때마다 업무의 질이 떨어질 수 있다. 반면 업무의 크기가 작다면 그만큼 적은 시간에 집중해서 일을 끝낼 수 있기 때문에 결과물의 질이 높아진다.

회사에서 일을 하다보면 내가 맡은 업무에 압도되는 일이 종종 있다. 처음에는 작은 좌절로 시작된다. 내가 생각한 대로 일이 흘러가지 않는구나 하고 느끼는 순간, 시간이 지나면 점점 정말 내가 이 일을 끝낼 수 있을 것인가 의문이 들기 시작한다. 조금씩 의욕은 떨어지고 그 일에 손을 대고 싶은 마음이 점점 사라진다. 그럴 때일수록 내 손 위에 많은 일이 있다면 가짓수를 줄여서 지금 당장 해야 하는 일을 고르고, 그 일을 끝내기 위해 어떤 일이 필요한지 생각해 본 다음 짧은 시간 안에 끝낼 수 있도록 일을 쪼개서 시작해야 한다. 그러고보니 이 말은 정신건강의학과 의사가 우울증 환자들에게 했던 말이다. DevOps 책에서 배운 원칙이 일 뿐만 아니라 우리 삶에도 적용이 된다. 도는 하나로 통한다더니, 좋은 원칙들은 분야를 넘어 다양하게 적용할 수 있는 것 같다.