스타트업부터 해서 대기업에 이르기까지 요즘은 보통 사내 클라우드 조직이 있다.
이런 사내 클라우드는 직접적으로 돈을 버는 조직이 아니고 돈을 버는 조직을 돕는 역할을 하게 되는데, 퍼블릭 클라우드를 이용해서 클라우드 서비스를 운영하는게 아니라 직접적으로 개발을 해야하는 조직에 가까운 경우 과연 어떠한 것을 만들것인가를 고민할 상황이 생긴다.
직접적으로 서비스 조직에서 요구사항을 전달받아 개발하는 경우도 있지만, 서비스 조직이 뭐가 필요한지를 모르는 경우도 있기도 하고, 더이상의 요구사항이 없는 경우도 있다.
이러한 상황에서 클라우드 조직은 불편한 것을 개선하거나 기존 서비스를 사용하는 사용자(서비스 개발자)가 문의하는 온콜 등을 통해 캐치해내 신규 서비스를 개발하기도(Bottom-Up) 하지만, 이렇게 되면 자칫 클라우드 조직의 방향성없이 개발이 이루어 지기도 한다.
조직이 커져갈수록 Bottom-up 방식은 한계를 보이고, 조직원들은 방향성을 잃고 헤매게 된다. 왜 이걸 개발하는거지, 이걸 잘쓰고 있는게 맞는건가. 그냥 예전부터 있어서 계속 이걸 유지보수하면 되는건가. 개발하고 났더니 우리 조직에서 만드는게 맞나. 그 다음은 뭘 개발해야하는거지 등등 여러가지 회의적인 고민거리들이 생기고 이탈하는 사람이 늘어나기 시작한다.
그러면 위와 같은 사내 클라우드 조직에서의 방향성은 어떻게 잡아야 하는 것일까? 최소한 이 업무가 왜 해야하는지를 이해하기 위해서 조직의 "비전"과 "미션" 의 정의는 매우 중요한 부분이다.
비전을 통해 조직의 존재 이유를 이해하고, 미션을 통해 구체적인 액션아이템을 도출해낼 수 있어야한다. 또한 이 비전과 미션은 바로 서비스 신규개발과 폐기 등의 기준을 제시하게 된다.
사내 클라우드 조직의 비전과 미션은 어떻게 잡아야할까?
필자가 오랫동안 고민해봤을때, 먼저 회사부터 생각해봐야한다. 회사는 왜 존재할까? 라는 철학적이면서도 거창해보이는 질문부터 고민해보자면, 결국 회사는 "돈"을 버는 것에 목적이 있다.
초기 구글의 모토인 "악해지지 말자(Don't Be Evil)" 같은 것이 결국 뻥이라는 걸 알게되기까지 오랜시간이 걸리지 않았다. 카카오가 초기 광고탑재 여부 논란이 일었을때 광고탑재할 일 없다고 한것도 같은 맥락이다. 회사는 결국 돈을 벌기위해 존재하는 것이다.
그렇다면 클라우드 조직은 돈을 벌기위해서 어떤걸 해야하는 걸까? 클라우드 조직은 돈을 직접적으로 버는 조직이 아니다. 재무적인 것만 보자면 돈을 쓰는 조직이다.
이렇게만 생각한다면 실제 서비스를 개발해서 사용자의 피드백을 얻고, 이를 통해 개선해나가면서 수익을 내는걸 뿌듯하게 생각하는 개발자인 경우 클라우드 조직에서 동기부여를 얻기 어려울 수 있다.
자, 그렇다면 이제는 한걸음 더 나아가 회사가 돈을 벌기 위한 클라우드 조직의 비전과 미션을 생각해보자.
첫번째, 방금 위에서 클라우드 조작은 "재무적인 것만 보자면 돈을 쓰는 조직" 이라는 언급을 했다. 여기서 힌트를 얻을 수 있다. 클라우드 조직은 쓰는 비용을 최대한 줄일 수 있는 방안을 고민해야한다는 사실을 말이다.
"클라우드 비용은 과도하게 쓰는데서 많이 나가는게 아니고 안쓰는데 그냥 놔두는데서 많이 나간다" 라는 말도 있다. 서비스는 정체되어 있는데 리소스 비용이 계속 증가하는 건 이상한 일이다. 이렇게 클라우드는 리소스를 효율화하지 않으면 쓸데없는 돈이 나가기 정말 쉽다. 또한 대체가능하거나 더 이상 수요가 없는 서비스는 과감히 종료해야한다. 그렇게 해서 클라우드 조직의 "비용 효율화" 로 회사의 비용을 줄일 수 있다.
두번째, 서비스들이 클라우드를 쓰는 이유는 직접 서버를 셋팅하지 않고도 편하게 사용할 수 있기 때문이다. 서버를 직접 셋팅하고 프로세스로 서비스를 띄우기보다는 컨테이너 이미지로 만들고 이를 컨테이너 플랫폼에 배포하는게 시간이 훨씬 절약된다. 거기에 CI/CD를 이용하고, Scale-In/Out 도 자동으로 지원된다면 더더욱 빨라지는 것은 자명하다.
이렇게 되면 서비스 개발자는 비즈니스로직에 집중할 수 있는 시간이 늘어난다. 바로 "개발 생산성"이 늘어나는 것이다.
5명이서 개발하고 운영해야하는 서비스를 2명이서도 할 수 있다면, 3명 분의 인력을 새로운 서비스 개발에 투입할 수도 있고 이것은 회사가 돈을 아끼면서 돈을 버는데 일조하는 것이다.
세번째, 서비스가 커가면서 부하가 생기고, 장애가 생기는건 자연스러운 현상이다. 지금 같이 클라우드로 서비스하지 않았을 때는 어떻게 했을지 상상이 가는가? 어마어마한 운영 노력이 필요했다. 하지만 클라우드를 이용한다면 이러한 장애상황에 더 유연하게 대응할 수 있다.
또한 서비스의 효율적인 장애 대응을 돕는 것을 넘어 클라우드 자체가 안정해야 한다. 아무리 서비스를 잘 개발해도 크리티컬한 클라우드 장애에는 속수무책이 된다. 그 여파는 수십~수백개 서비스에 고르란히 전파된다. 그렇기 때문에 클라우드 조직은 "장애를 최소화" 해야한다.
이렇게 회사가 돈을 잘~ 벌기 위해 클라우드 조직은 "비용 효율화", "개발 생산성 향상", "장애 최소화"를 주요 목적으로 삼고, 이를 위해서 어떤 리소스를 효율화하고, 어떤 새로운 기능을 개발하고, 장애를 어떻게 최소화할지 구체적인 액션아이템을 도출해야 한다.
위 목적을 달성하기 위해 어떤 "제품 또는 서비스"를 제공할 것인지가 바로 클라우드 조직의 비전이 된다. 이는 클라우드 하위 세부 조직에 따라 개발해야 하는 제품이 달라진다. 중요한 것은 위 3개를 기준으로 제품을 개발해야 한다는 것이다.
조직의 미션은 3개의 목적을 좀 더 구체적으로 상세화하는 것으로 도출할 수 있다.
가령, 컨테이너 플랫폼을 개발한다고 하자. 어떤 방향으로 개발해야할 것인가를 위 3개를 기준으로 고민해보면,
- 비용효율화: 리소스 효율이 낮은 컨테이너를 감지하고 이를 정리할 수 있어야 한다.
- 개발생산성 향상: 컨테이너 이미지를 자동으로 빌드해주고 배포해주는 CI/CD 기능이 필요하다.
- 장애 최소화: 컨테이너, 노드 부하를 모니터링하여 알람을 주는 기능이 필요하다.
여기서는 예를 들기위해 간단하게만 정리해보았다. 좀 더 고민해보면 다양한 액션아이템들을 도출할 수 있다.
또한 이러한 비전과 미션은 조직과 거리가 먼 서비스 개발을 지양할 수 있는 근거와 기준이 될 수 있다.
이렇게, 사내 클라우드 조직의 방향성에 대해서 개인적인 생각을 적어보았다. 사실 클라우드 조직 뿐만 아니라 일반적인 다른 조직이라도 위와 같은 방식으로 방향성을 도출할 수 있을 것이라 생각한다.
이미 아는 얘기 뭐 그렇게 혼자만 아는 것처럼 얘기하냐도 할 수도 있다. 일반 사원에서 조직장의 직책을 맡게됐을 때의 관점이라는 점을 감안해주면 좋겠다.
'Development' 카테고리의 다른 글
[ENG] Basic Understanding of Prometheus Query (PromQL) (0) | 2024.12.30 |
---|---|
지라(JIRA) 에픽(EPIC)과 KR(Key Results) (0) | 2024.11.30 |
재택근무의 장단점 (개인의견) : 업무 효율성과 팀 빌딩 사이에서 (0) | 2024.11.28 |
데이터 엔지니어링 로드맵 (0) | 2024.11.17 |
devops problem solving(이슈해결 역량 기르기 팁) (0) | 2024.11.14 |