자바스크립트를 활성화 해주세요

d041 '무인화 시스템'을 구축하는 조직의 관리방식과 이에 대처하는 엔지니어

 ·  ☕ 28 min read
  • 이 글은 번역글입니다.
  • 읽어보고 재밌어서 소개하려고 생각이 들었습니다.
  • 우선 무인화라는 것은 완전 자동화 라는 의미가 아닙니다. 관리하는 사람이 없는 시스템입니다.
  • 원래 제목은 “‘무인화 시스템’을 구축하는 조직 매니지먼트와 엔지니어링” 입니다만, 약간 오해할 수 있어서 알기쉽게 변경했습니다.
  • 꽤 긴 글입니다.
  • 꽤 솔직한 글입니다. (엔지니어 입장에서), 또 곤혹스러운 글입니다. (관리자 입장에서)
  • 번역이 부족하거나 오류가 있으면, 용서해 주세요.
  • 길지만, 긴 만큼 재미있습니다.
  • 맞춤법 검사를 하는 툴이 있으면 교정하는 데 도움이 될 것 같습니다.

자 이야기 시작합니다.

저희 회사에서는 2019년 3월경부터 무인화시스템의 구축이 진행되고 있었습니다. 본기사에서는 이 대처를, 조직 매니지먼트와 엔지니어링의 측면에서 소개합니다.

공포의 무인화 시스템

무인화 시스템은 사내의 독자 용어이므로, 우선은 말의 의미부터 설명합니다.

무인화란 무엇인가?

무인화 전 속인화에 대해 언급하세요. weblio 사전에서 속인화에 대해 인용합니다.

어떤 업무를 특정인이 맡아 그 사람만 하는 법을 알 수 있는 상태가 됨을 뜻하는 표현.

무인화는 속인화의 진화 계통입니다. 무인화란 속인화되었던 업무의 담당자가 없어져, 아무도 방법을 모르는 상태가 되는 것이라고 정의할 수 있습니다. 누가 봐도 안 되는 상태죠.

무인화 시스템이란 무엇인가?

시스템 운용이 속인화되고 그 운용자가 퇴직하면 시스템이 무인화됩니다. 우리 회사에서는 이런 시스템을 무인화 시스템이라고 부릅니다.

무인화 시스템은 아무도 자세한 것은 모르지만, 어째서인지 움직이고 있는 시스템입니다. 남몰래 마음대로 움직여 준다면 아무도 곤란해하지 않겠지만, 실제로는 다음과 같은 상황에서 문제가 됩니다.

  • 장애나 에러가 발생하여 정상적으로 시스템이 작동하지 않게 되다
  • 주변 상황의 변화에 따라 사양 변경이 발생하는 경우
    아무도 자세한 내용을 모르기 때문에 이런 문제가 발생해도 어쩔 도리가 없습니다. 왜냐면 모르잖아.

무인화 시스템의 기술적인 문제점

안타깝게도 당사에서는 무인화 시스템이 몇 개나 발생해 버려 엔지니어를 크게 괴롭혀 왔습니다. 시스템에 따라 기술적인 과제는 다르지만 몇 가지 예를 들어보겠습니다.

  • 응용 프로그램의 소스 코드는 전혀 버전 관리가 되지 않는다
  • 비전의 타레가 계속 추가되어 재구축 불가능한 서버
  • 서버 하나에 책무가 다른 애플리케이션이 함께 돌고 있다
  • 시스템의 목적이 불분명하여 현재 올바르게 작동하고 있는지 판별 불능
  • 버전업되지 않은 운영 체제·미들웨어
  • 테스트 없음, CI 없음, 감시 없음, 문서 없음, 디플로이 방법 불명, 시스템 구성 불명
  • 시스템을 구축한 사람은 퇴직한 후로, 일체의 진화가 멈추어 있다.

안티 패턴의 견본시장처럼 되어 있습니다만 시스템에 따라서는 정말로 무서운 상황이었습니다. 물론 구축 당시에는 최선을 다했겠죠. 그러나 실제로 이러한 시스템을 보면, 솔직히 관여하고 싶지 않아집니다.

또 우리의 무인화 시스템은 대부분 Amazon Linux에서 작동했습니다. Amazon Linux는 2020년 12월 31일에 EOL을 맞이합니다. 따라서 EOL인 채로 계속 움직일지, migration 할지를 선택하지 않으면 안 됩니다.

관여하고 싶지 않습니다만, 내버려 두기에는 상당히 곤란한 상황에 몰렸습니다. 힘듭니다. 그러나 ‘기술적으로 힘들다’는 문제는 무인화 시스템의 한 측면일 뿐입니다.

무인화 시스템은 조직을 부패시킨다

무인화시스템은 기술적인 과제에 그치지 않습니다. 사실은 조직의 과제이기도 하고, 방치하면 조직을 썩게 됩니다. 어떻게 조직이 썩어가는지 생각해봅시다.

식견의 소실

시스템이 무인화되면, 시스템에 관한 모든 지견이 소실됩니다. 왜 존재하는가? 멈추면 누가 곤란할까? 바른 거동은 무엇인가? 를 모두 알 수 없게 됩니다.

이것은 시스템의 무인화에 의해 직접 발생이 되는 인지하기 쉬운 문제입니다. 식견의 소실 자체도 괴롭습니다만, 그것보다 귀찮은 것은 이것이 모든 재앙의 원흉이 된다는 것입니다.

조직적 무관심

지견이 소실되어 우선 일어나는 것이 조직적 무관심입니다. 조직에 소속된 모든 사람이 그 시스템과 나는 관계없다라고 생각하기 시작합니다. 자신에게는 관계없다고 모두가 생각하기 때문에 무인화 시스템은 결코 개선되지 않습니다.

오히려 무인화 시스템에 문제가 생겨도 자신에게는 관계없다며 무시하는 사람이 생깁니다. 이것은 조직을 급속히 썩게 만들어요. 왜냐하면 문제를 무시하는 태도가 만연하기 때문입니다.

이 태도에 대해 나쁘게 얘기하고 싶진 않아요. 그게 나한테는 상관없는 이야기니까 당연하지요? 우리가 상관없는 일에 관여할 만큼 한가하지는 않죠.

선의의 사람에 대한 의존

무인화 시스템은 일반 시스템과 비슷한 정도는 문제가 발생합니다. 그리고 문제를 무시하는 태도가 만연한 조직에서는, 문제를 마주보는 선의의 사람이 손해를 봅니다.

선의의 사람에게 의존해 무인화 시스템의 담당을 강요하면, 선의의 사람의 조직에 대한 결속력이 폭락합니다. 자신 말고는 아무도 문제를 마주하지 않고 어쩔 수 없이 문제에 대처해도 별로 평가받지 못하는 상황을 상상해봅시다. 동기부여 저하와 퇴직을 유발해도 별로 이상하지 않습니다.

문제해결 능력의 저하

선의의 사람에게의 의존에는 새로운 부작용이 있습니다. 단기적으로는 문제가 해결된 것처럼 보이는 거에요. 하지만 그 문제 해결은 ‘대처 요법’이 됩니다. 왜냐하면 선의의 사람에게 무인화 시스템은 본래 자신의 문제가 아니기 때문입니다. 그래서 근본적으로 해결되지 않습니다. 그러면 어떻게 되느냐 하면 물밑에서 문제가 더 악화됩니다.

또한 대처 요법을 반복하게 되면 근본적인 문제 해결이 늦어지는 것이 일상화 됩니다. 그리고 머지않아 조직의 문제 해결 능력을 넘는 레벨까지 문제가 커져, 손을 댈 수 없게 됩니다.

선의라는 것은 아름답고, 거기에 의문을 품거나 비판을 하거나 하는 사람은 보통 없습니다. 자칫하면 월경이라는 미려자구로 인기가 되기도 합니다. 선의란 개인의 행동으로서는 훌륭합니다. 그렇기 때문에 기분 좋게 방심하게 되면 저도 모르게 의존하게 됩니다. 하지만 조직의 지속성이라는 관점에서 위험한 신호입니다.

불가능한 의사결정

조직의 문제해결 능력을 넘어서는 수준까지 문제가 악화되면 더 이상 개선이 불가능합니다. 영향범위도 불분명하고 누가 곤란할지 모르기 때문에 시스템을 버리는 결단조차 할 수 없습니다.

이렇게 되면 **‘모든 의사결정을 할 수 없는 상태’**에 빠집니다. 시스템의 개선도 폐지도 할 수 없고, 대처 요법에 의한 현상 유지가 유일한 선택사항입니다.

이 상태까지 가면 직함이 훌륭한 사람들도 ‘어떻게 하면 좋을까…’ 라든지 말을 꺼내면서 생각이 정지됩니다. 의사결정자가 의사결정을 하지 않게 되기 때문에 점점 해결의 전망이 어려워집니다.

이렇게 조직내의 적지 않은 사람들이, 둔한 아픔을 안는다는 말이 됩니다. 하지만 그게 치유되는 일은 결코 없습니다

불가지의 인과관계

대처 요법만이 유일한 선택지가 된 시스템은 대체 무엇을 일으키는 것입니까. 예를 들어 무인화 시스템에서 수수께끼의 장해가 발생해, 제휴처의 시스템이 에러가 났다고 칩시다. 그러면 거의 아무것도 모르는 상태에서 장해조사가 시작이 됩니다. 물론 그동안 원래 하려던 일은 한 발짝도 나아가지 않습니다. 최종 사용자 전용의 멋진 기능 실장도, 사내의 업무개선도 모두 스톱합니다.

더 나쁜 것은 무인화 시스템에 관련된 일은 난이도가 높습니다. 그렇기 때문에 하이스킬의 사람이 동원됩니다. 본래라면 더 나은 미래를 만드는 일에 주력했으면 하는 인재가 과거의 망령과의 싸움에 시간을 소비합니다.

그러면 기능 실장의 스피드가 느리다든가, 대담한 액션을 취할 수 없다든가, 생산성이 오르지 않는다고 하는 문제들이 표출됩니다. 그러나 문제의 근간이 어디에 있는지, 이해되는 것은 거의 없습니다.

원인으로부터 결과가 나올 때까지 시간적 지연이 발생하기 때문에, 원래 관계가 있는 것처럼 보이지 않습니다.

내 시체를 넘어서 가라

저희 회사에서는 이전부터 무인화 시스템이 문제가 되고 있어, 여러 번 개선을 시도했습니다. 하지만 매번 실패했어요. 여기에서는 실패 사례를 하나 소개하겠습니다.

2017년 경에 무인화 시스템에 엔지니어 팀을 할당한다라고 하는 대책을 실시했습니다. 무인화 되어 있다면 엔지니어를 할당하면 되잖아, 라고 하는 소박한 발상입니다. 이 방침의 끈은 2가지입니다.

  • 장해 대응을 포함한 운용을 그 팀이 담당하고, 오너십을 갖게 한다.
  • 엔지니어팀 내에서 자율적으로 시스템 개선 사이클을 돌리다.

누가 봐도 완벽한 솔루션입니다. 하지만 실패했습니다. 무엇이 나빴을까요? 깊이 살펴보겠습니다.

왜 우리들이야?

어느 날 갑자기 ‘너희들 이 시스템 담당이구나’라고 했던 장면을 상상해봅시다. 첫 반응은 ‘왜 우리들이야?’ 입니다. 전혀 자기 일이 되지 않아요. 우리가 쓰는 것도 아니고 팀 미션과도 별 연관성이 없으면 더더욱 그렇죠.

엔지니어팀 할당 작전에는 암묵적인 전제로서 운용이 힘든 시스템의 담당이 되면, 개선에 움직일 것이다! 라고 하는 아련한 기대가 있었습니다. 물론 그렇지 않았습니다.

건드리지 않으면 재앙을 입지 않는다.

담당이 되었다고 해서 엔지니어 팀이 갑자기 그 시스템을 잘 알게 되는 건 아닙니다. 인수인계나 문서는 없고, 읽기 어려운 코드와 왠지 움직이고 있는 시스템을 전달 받습니다. 그런 시스템을 넘겨받으면 문제가 일어날 때까지 방치를 하기 마련입니다.

이것은 누구의 문제냐?

무인화 시스템의 개선은 기본적으로 아무도 하고 싶어 하지 않는 일입니다. 우선 관리층에서는 엔지니어 팀을 배정한 후에는 아무런 지원도 하지 않고 앞으로 잘 부탁한다고 전달했지만, 다음에 엔지니어 팀은 그냥 시스템을 방치했어요.

누구에게도 악의는 없었지만, 아무도 진지하게 문제를 마주하지 않았어요. 이 문제를 어떻게든 하지 않으면 안돼! 라고 당시 여러 사람이 말했지만 실제로는 아무도 행동하지 않았습니다.

문제를 낳는 구조

실패사례의 근본적인 오류는 담당자가 없으니 담당자를 붙이자! 라고 단락적으로 생각한 점에 있습니다. 그러나 무인화 시스템과 같은 문제를 해결하려면, 문제를 낳는 구조에 주목해야 합니다.

그럼 무인화 시스템에서 문제를 만들어 내는 구조는 과연 무엇인 것일까요. 바로 오너십과 문제의 왜소화입니다.

오너십과 무인화 레벨

무인화시스템을 잘관찰하면 사실 무인화레벨이 두 개인 것을 알게됩니다.

  • 오너
  • 운용팀

실패 사례로는 ‘운용할사람이없는것’을 문제로 보고, 운용팀을 배정하였습니다. 하지만 오너십을 가진 사람(=오너)이 없다는 문제를 해결하지 않는 바람에 꼬였죠.

오너십을 가진 사람이 없으면 만든 시스템을 유지할 지 버릴 지 아무도 판단하지 않게 됩니다. 운영팀이 구단주를 겸임하면 문제가 없으나 그렇지 않으면 운영팀이 없어지는 순간 무인화됩니다.

아무도 오너십을 가지고 있지 않기 때문에, 인수 인계 등은 실시하지 않습니다. 단순하게 버려집니다. 주인이 없는 시스템의 미래는 아무도 모르는, 생각도 없는, 관계없는 일입니다.

문제의 왜소화로 인한 당사자 의식 결여

폐사에서는 엔지니어 이외에도 기술적 부채라는 말이 침투되어 있습니다. 이 때문에 무인화 시스템도 기술적 부채 중 하나로 간주되었습니다. 즉 무인화 시스템은 **‘엔지니어의 문제’**라고 인지되고 있었던 것입니다. 워낙에 기술적 부채에요.

확실히 시스템 운용의 기술적인 경영은 전문지식이 필요하기 때문에 엔지니어의 문제라고 할 수 있습니다. 그러나 시스템에 의해 혜택을 받거나 시스템이 이상해져 곤란한 것은 엔지니어 이외의 사람도 포함됩니다.

또 하나 잊어서는 안 되는 것은 시스템 운용에는 엔지니어의 시간과 기술이 필요하다는 점입니다. 시스템 운용에 시간이 걸릴수록, 혹은 기술적 난이도가 높으면 높을수록, 신기능 개발등의 사업 활동은 정체합니다. 즉 시스템 운용은 사업 활동의 제약 조건이며, 사업 활동에 종사하는 모든 사람이 영향을 받습니다.

바람직한 모습을 그리다

이제야 문제의 윤곽이 드러났어요. 여기까지 읽은 사람도 슬슬 싫증나기 시작했을 거에요. 하지만 이 상황을 바꾸기 위해 가장 중요한 것은 짜증나는 문제들을 직시하는 것입니다. 전진하기 위해서는 아무리 힘들어도 한번 현상을 받아들이고, 그 후에 지혜를 모을 필요가 있습니다.

문제를 직시하고 나면 앞으로 나아가죠. 먼저 ‘현재으 모습’을 그려야 해요. 무인화 시스템은 복잡한 문제에요. 솔루션을 임기응변적으로 실행해서는 안됩니다. 바람직한 모습부터 역산해서 전략적으로 임하는 거죠. 우리가 그려야 할 모습은 다음과 같습니다.

조직으로서의 지속가능성

한 개인의 선의에 의존하지 않고, 조직으로서 시스템을 지속 가능하게 합니다. 조직으로서 지속 가능은 다음과 같은 상태입니다.

  • 시스템의 가치를 계속적으로 모니터링하다
  • 가치 있는 시스템은 비용을 들여 제대로 운용된다
  • 자원 봉사자가 아닌 팀의 임무로서 시스템을 운용하다

누군가가 어떻게든 해 줄 것이다, 라고 하는 태도는 고칩니다. 문제의 투명성을 높여 모두가 문제와 마주합니다. 엔지니어 뿐만이 아니라 사업 활동에 종사하는 모든 사람의 헌신이 요구됩니다.

비즈니스 가치에 대한 포커스

저희의 미션은 어디까지나 세상을 위한 가치 제공입니다. 시스템 운용은 그 수단입니다. 그래서 막연하게 시스템을 운용하는 것이 아니라 비즈니스적으로 가치 있는 것에 초점을 맞춥니다.

이것은 동시에 모든 것을 100점으로 실행하는 것은 불가능하다라고 하는 현실의 수용을 의미합니다. 우리에게는 한정된 인력과 시간, 예산밖에 없기 때문에 모든 시스템에 동일한 수준으로 투자 할 수 없습니다. 거기서 시스템 운용에의 마주보는 방법을 바꿉니다.

  • 가치가 낮은 시스템은 버린다 = 사업 활동의 제약 조건을 철거하다
  • 가치가 높은 시스템의 운용 부하를 낮추다 = 사업 활동의 제약 조건을 경감하다

지금까지와 같이 시스템을 계속 만들어 두는 것은 허용하지 않습니다. 제대로 운용하느냐 버리느냐의 둘 중 하나입니다.

오너십과 권한

시스템을 계속 올바르게 운용하기 위해 명시적으로 오너를 둡니다. 아무도 주인이 되지 않을 경우, 그 시스템은 버리게 됩니다.

무인화 시스템은 존재만으로도 해악을 퍼뜨리기 때문에 주인이 없다면 깨끗이 솎아냅니다. 그리고 소유주는 시스템을 유지하기 위해 필요한 모든 활동에 책임을 집니다. 예를 들어 다음과 같은 활동이 포함됩니다.

  • 시스템 비즈니스 가치와 비용 가시화
  • 신기능 개발 등 다른 사업활동과의 균형추세
  • 시스템 운용에 필요한 체제 구축 및 예산 획득

당연히 모든 것을 혼자서 조달할 필요는 없지만, 이러한 실행에는 책임이 있습니다. 막중한 책임입니다만, 동시에 시스템을 유지할지 결단할권한도 가집니다. 시스템을 유지할지의 결단은 매니저나 사업책임자에게는 행해지지 않습니다.

얼마나 비즈니스 영향이 클지라도 시스템 오너가 버리는 결정을 하면 버립니다. 만일 이 결단에 이의가 있을 경우는, 스스로가 오너가 되어 책임을 맡겠습니다.책임지지 않는 사람이 개입하면 오너십이 단번에 없어지기 때문에 아무리 직함이 훌륭해도 간섭시키지 않습니다.

무인화 체계와 싸우는 조직 관리

바람직한 모습을 그렸다면 구체적인 활동으로 넘어가는 거예요. 무인화 시스템을 혼자서 해결하기란 어렵습니다. 거기서 우선은 조직 전체를 움직이기 위해 준비를 해 나갑니다.

대략적으로는 다음의 5개의 스텝으로 진행합니다.

  1. 전모 파악
  2. 이해관계자의 특정
  3. 비즈니스 가치의 언어화
  4. 유지대상시스템및소유주선출
  5. 체제 구축

전모 파악

어쨌든 가장 먼저 전모를 파악합니다. 무인화 시스템은 무인화되어 있는 만큼 스텔스능력이 높고 인지되지 않는 시스템이 많이 있습니다. 그 때문에 무인화 시스템을 밝혀내, 일람화 합니다.

방법은 매우 단순하고 제대로 관리되지 않는 서버에 SSH를 해서 조사를 합니다. 필요한 건 기합과 근성뿐이에요. 그냥 힘쓰는 기술이라 누구나 할 수 있지만 혼자 하면 멘탈적으로 소모됩니다. 거기서 자기 팀의 멤버를 끌어들여, 떼지어서 조사합니다.

폐사에서는 필자가 소속된 SRE 팀에서 실시했습니다. “뭔가 서버상에서 직접 코드가 편집되고 있어.” “왜 심볼릭 링크를 매일 백업하는 거야?” “질서도 양심도 없는 이 서버” 등으로 투코미를 넣으면서 시끌벅적합니다. 다소 입이 험해지는 것은 애교입니다. 혼자 하면 갑자기 필연적인 사안도 투코미 구동으로 즐겁게 해냅니다. 잘 모르는 것도 많이 발굴됩니다만, 어쨌든 힌트가 될 만한 것은 닥치는 대로 메모합니다.

이해관계자의 특정

무인화 시스템의 목록이 생기면 관계가 있을 것 같은 사람에게 문의하고 돌아갑니다. 누가 스테이크홀더인지 모르기 때문에, 소박하게 발품팔아 해결합니댜. 여기서도 필요한 것은 기합과 근성입니다.

사람이 많은 Slack채널에서 질문을 하거나 경력이 많은 사람에게 핀포인트로 물어보는 등 우직하게 갑니다. 이것을 반복하면, 어느 정도 스테이크홀더를 좁힐 수 있습니다. 참고로 여기서 발견한 이해관계자는 시스템의 오너 후보가 됩니다.

또한 누구에게 물어봐도 정말 아무것도 모르는 수수께끼와 같은 시스템도 나옵니다. 그런 시스템은 조용히 멈춰 보고, 어디선가 비명이 지르는지 관찰합니다.비명이 지르면 그 사람이 이해관계자예요. 반대로 무반응일 경우 그 시점에서 시스템의 폐지가 확정됩니다.

비즈니스 가치의 언어화

스테이크홀더에게는 시스템의 비즈니스 가치의 언어화를 의뢰합니다. 시스템 운용에는 비용을 신경 쓰는 사람이 많습니다만, 그건 우선 잊어 봅시다. 어디까지나 시스템이 현재도 가치를 낳고 있는가를 명확하게 해야합니다..

시스템의 비즈니스 가치는 대개 아무도 모니터링하지 않습니다. 재차 언어화해 보면, 유지할 가치가 없다고 판단할 수 있는 케이스가 나옵니다.

가치를 창출하고 있는 경우는 얼마나 가치를 창출하고 있는지 가능한 구체적으로 표현합니다. 시스템의 비즈니스 가치는 지속 여부 판단의 인풋이 됩니다.

유지대상시스템및 소유주선출

비즈니스 가치를 언어화하여 앞으로도 필요할 것 같은 시스템을 알아낸 후 소유주를 선출합니다. 오너는 원칙적으로 운용하는 엔지니어가 아니라 시스템의 혜택을 받고 있는 사람이 담당합니다.

시스템 운용의 지속 여부는 기술 관점이 아니라 어디까지나 비즈니스 관점으로 판단합니다. 이것에 의해 시스템 운용에 직접 종사하지 않는 사람이 자사화할 수 있도록 유도합니다. 이 근처까지 나아가면 무인화 시스템은 ‘조직적인 문제’라는 공통인식이 자라게 됩니다.

체제 구축

일반적으로 체제구축은 매니저의 일입니다. 그래서 시스템의 오너는 비즈니스 가치를 매니저에게 설명하고 함께 체제를 검토합니다. 체제 검토는 시스템 운용 이외에도 대량의 파라미터가 존재하기 때문에, 이것은 지혜를 짜내는 부분입니다.

다음으로 소유주는 운영팀에게도 시스템의 비즈니스 가치를 설명하고 공감을 얻어야 합니다. 단순히 포기하면 동작하지 않기 때문에 동기부여는 필수입니다.

반대로 운용팀을 납득할 수 없는 경우 시스템운용을 맡으면 안됩니다. 운용할 가치가 없다고 느낀다면 No를 들이대는 것이 운용팀의 책임입니다.

이 과정은 매우 중요하고, 운용팀이 오너십을 가지기 때문에 빠질 수 없습니다. 잘하기는 어렵지만 오너십은 열쇠가 되기 때문에 타협할 수 없습니다.

무인화 시스템과 싸우는 엔지니어링

오너와 운용팀이 정해지면 드디어 엔지니어링에 나갈 차례예요. 무인화 시스템은 이미 노하우가 없어져 제대로 운용할 수 없습니다. 그래서 당면은 시스템을 운용 가능한 상태로 만드는 것을 엔지니어링의 목표로 합니다.

운용 가능한 상태란 무엇인가?

그런데 시스템이 운용 가능한 상태라는 것은 어떤 상태일까요. 예를 들어 다음과 같은 상태일 것입니다.

  • 시스템의 존재 이유가 명확한 것
  • 비즈니스 가치가 명확할 것
  • 오너와 이해관계자가 명확한 점
  • 비즈니스적인 영향 범위와 시스템적인 영향 범위가 명확한 것
  • 시스템 구성이 명확할 것
  • 시스템의 올바른 거동이 명확할 것
  • 누구나 디플로이 가능한 일
  • 코드 변경 시에 디그레임을 검지할 수 있을 것
  • 스테이지링 환경이 있을 것
  • 언제라도 재구축할 수 있는 것
  • 장해를 감지할 수 있을 것
  • 트러블 슈팅이 가능할 것
  • 잔존 리스크가 명확한 것

무인화 시스템의 경우, 이것들은 대체로 충족이 되어 있지 않습니다. 난감하네요.

현재 위치를 알기

우리가 안고 있는 무인화 시스템을 다시 보니 이런 특징이 있었습니다.

  • 대부분의 OS는 아마존 리눅스이며 미들웨어를 포함하여 버전업되지 않음
  • Infrastructure as Code라는 개념은 없으며 재구축 불가능
  • 대부분의 시스템은 배치 어플리케이션
  • 단일 서버에 복수의 애플리케이션이 합승
  • 실제 환경만을 위한 무대라는 것은 사치를 용납할 수 없다

여러가지 문제가 있지만 당장 Amazon Linux의 EOL이 있습니다. OS가 EOL로 되어 있는 시스템을 운용 가능한 상태라고 우기는 것은 조금 어려울 것입니다. 거기서 시스템 이행을 실시합니다. 그리고 시스템 이행을 통해 시스템을 운용 가능한 상태로 만들어 갈 것입니다.

시스템 이행 전략

이론상으로는 각 운용팀이 원하는 대로 시스템 이행을 실시해도 상관없습니다. 하지만 조각조각 움직이면 비효율적입니다. 그래서 전체의 이행전략을 세웁니다. 그리고 그것을 근거로 하여, 각 시스템을 개별적으로 이행합니다.

우선 향후의 계속적인 운용을 생각하면, 원래의 EC2를 운용하는 것은 힘듭니다. 원래 서버를 운용하고 싶지 않습니다. 또 스테이지 환경도 갖고 싶습니다.이에 다음과 같은 방침으로 이행처를 구축합니다.

  • 응용 프로그램 모두 Docker화
  • Docker 컨테이너의 실행 환경은 ECS Fargate
  • 인프라는 모두 Terraform으로 구현하여 스테이지 환경도 구축

애플리케이션 개발자 중에 인프라를 잘 못하는 구성원도 있기 때문에 SRE팀이 전폭적으로 지원합니다. 시스템 이행에 앞서 SRE 팀이 ECS 클러스터를 구축해, 작업 스케줄의 세세한 조정을 해 둡니다.

한편으로는 애플리케이션 개발자는 각각의 시스템에 대한 조사를 진행하고 Docker file보다 위의 레이어 구현에 주력합니다. 덧붙여 SRE 팀의 역할에 대해서는 다른 멤버가 기사로 하고 있기 때문에, 그쪽도 봐 주세요.

Amazon Linux의 EOL에 따라 뱃지를 서버리스화하여 Fargate로 이행한 이야기

시스템 이행 안내서

ECS 클러스터가 준비되어 있다고는 해도, 시스템 이행에 수반해 해야 할 일은 많이 있습니다. 또 팀에 따라서도 스킬셋이 다릅니다. 그래서 간단한 시스템 이행 안내를 준비했습니다. 너무 길어서 자세한 것은 쓰지 않겠지만 이왕이면 개요만 소개하겠습니다.

  • 현상 파악
    • 시스템의 존재이유, 비즈니스 가치, 이해관계자를 명확히 한다.
    • 시스템의 유스케이스·영향범위·시스템 구성을 명확히 한다.
  • 시스템의 요건 정리
    • 시스템의 올바른 거동을 파악하다
    • 통신요건·다루는 데이터의 기밀수준·사용하고 있는 데이터 스토어 등을 파악한다.
  • 인프라 구축
    • 통신 요건 등을 근거로 하여 인프라를 미세 조정하다
    • Terraform으로 실전 환경 및 스테이지 환경을 구축하다
  • 응용 프로그램 수정
    • Docker file 을 생성하여 Docker 이미지를 빌드할 수 있게 한다.
    • OS(운영 체제)와 미들웨어 버전이 너무 오래 되어 빌드할 수 없는 경우에는 버전업을 한다
    • 버전 업에 따라 애플리케이션이 작동하지 않게 되면 작동하도록 수정하다
  • CI / CD
    • GitHub Actions 및 Circle CI로 도커 이미지의 빌드를 자동화하다
    • 필요하면 디플로이 기능을 자동화하다
  • 이행
    • 이행 순서·반복 순서를 작성한다
    • 영향을 최소화하기 위해 이행 전에 이해관계자로 인식을 맞추다
    • 이행 작업을 실시하다

물론 가이드가 있어도 곤란한 일이 발생하기 때문에, 그 때는 그때마다 상담을 받습니다. 특히 인프라 주변 조정은 SRE팀과 상의하면서 진행됩니다.

시스템 이행 실시

막연히 시스템 이행을 합시다!라는 방침을 세워도 좀처럼 진척되지 않습니다. 거기서 외압을 이용하죠. 저희같은 경우에는 AmazonLinux의 EOL이라는 큰무기가 있습니다. 여기에 전력으로 승차하여, EOL과 같은 2020년 12월을 데드라인으로 정했습니다.

또 확실히 하기 위해 EOL 이후에는 Amazon Linux의 서버는 그만둡니다 라는 소멸의 어나운스도 잊지 않습니다. 이것으로 시스템 이행을 하거나 버리거나 두 가지 선택이 됩니다.

이제 여기까지 가면 나머지는 관념해 줄 뿐이에요. 각각의 시스템 이행에 대해서는 특별한 아이디어는 없습니다. 하나하나 우직하게 실시하겠습니다. 또한 시스템 이행에 대한 고생이야기는 다른 멤버가 기사를 쓰고 있기 때문에 그쪽도 봐 주십시오.

  • 주인 없는 들배지를 EC2에서 Docker 환경으로 옮겨 놓은 이야기
  • 실록: 에, 이 시스템은 뭔가요? 로부터 시작되는 작은 인수인계의 이야기.

성과와 앞으로의 과제

개개의 시스템 이행도 여러번 있었습니다만, 2020년 11월 말에는 대체로 완료했습니다. 또 시스템 이행과 병행해서 시스템 폐지도 했습니다. 처음에는 크고 작은 30개 정도의 시스템이 있었습니다만, 4분의 1정도는 버려졌습니다.

개선점

시스템 이행으로 인해 개선된 포인트를 몇 가지 드리겠습니다.

  • 모든 어플리케이션의 소스 코드 버전 관리
  • Docker나 Terraform에 의한 Infrastructure as Code를 철저히 하여 재구축이 불가능한 EC2를 거의 구축
  • 애플리케이션 Docker화에 따라 애플리케이션 간의 의존 관계를 최소화
  • GitHub Actions 및 CircleCI에 의한 CI/CD를 많은 시스템에서 도입
  • 시스템 도입 배경, 시스템 구성, 운용에서의 주의점 등을 형식지화

상당히 모던한 시스템이 됐어요. 그 밖에도 Dependabot을 통한 자동 버전 업의 도입이나, 경보 알림의 정비도 조금씩 진행되고 있습니다. 이렇게 쓰다 보면 당연한 것들만 나열되어 있지만, 당연함을 실천할 수 있는 것은 정말 귀합니다.

또 조직 관리의 관점에서는 다음과 같은 상태가 되었습니다.

  • 각 시스템에 명시적으로 오너와 운용팀 배치
  • 오너와 운용팀의 미션에 시스템 운용을 포함
  • 시스템 비즈니스 가치 언어화
  • 사업전략 파라미터에 시스템 운용을 고려 포인트로 추가

활동을 시작하기 전에 비하면 훨씬 정상적인 상태라고 할 수 있습니다.

남겨진 것

시스템에 의해서 남은 과제의 레벨은 제각각이지만, 할 수 있는 것은 아직 있습니다.

  • 테스트 코드가 없기 때문에 캐주얼하게 운영 체제 미들웨어를 버전 업 할 수 없다.
  • 시스템 시스템 구성에 따라 감시 수준이 불균형을 이루고 있다
  • 유비누 기반 시스템 중 몇 개가 남아 있다

하지만 기술적인 과제는 상당히 구체적이고 어떻게 보면 그냥 하면 되는 것이기 때문에 쉬운 부류입니다. 한편 조직 관리는 이제부터가 승부입니다.

  • 지속적으로 시스템 비지너스 가치 확인
  • 오너 부재의 시스템이 생성되지 않았는지
  • 오너나 운용팀에 대한 지속적인 동기부여부
  • 운용팀이 과부하에 빠지지 않도록 업무 균형

조직적인 과제를 검출하는 구조는 거의 자동화 되어 있지 않기 때문에 편하게 운용하는 방법을 모색해야 할 것입니다.

대기실 뒷코너: 하면서 생각했던 거

본 기사도 일단락되었으니 이제부터는 개인적으로 생각했던 것을 대충 나열해 두겠습니다.

상향 조정으로 조직을 움직이다

무인화 시스템을 구축하는 활동은 문제의 강대함과 달리, 거의 무기가 없는 상태로 스타트했습니다. 활동 개시 시점에서의 상황은 다음과 같습니다.

  • 무인화 시스템의 수, 난이도, 비즈니스 가치, 이해관계자는 모두 불명
  • 무인화 시스템을 실장한 사람의 대부분은 퇴직한 상태이며, 지식은 깨끗하게 로스트 완료.
  • 이 활동을 추진하기 위해 필요한 체제·예산·권한은 제로
  • 개선에 필요한 비용 및 개선 시의 효과는 예측 불가
  • 관리층이나 경영층에 과제의식은 있어도 구체적인 액션은 없음
  • 타인이 만든 시스템을 어떻게든 한다고 하는 활동의 특성상, 타인에게의 동기 부여는 지극히 곤란.
  • 개선 시도는 이미 여러 번 실패했으며 성공률은 낮다.

냉정하게 적어놓고 보니 당기네요. 부정적인 요소는 얼마든지 나올 수 있지만 긍정적인 요소는 거의 없습니다. 유일한 긍정적인 요소는 실패해야 마땅한 활동이므로 성공에 대한 부담이 전혀 없다는 것 정도입니다. 지금 돌이켜 보면 이런 문제에 손을 댄다는 것은 제정신이 아니었지만, 뭐 제정신이 아니었겠지요.

정신 나간 시작이지만 실제 활동은 상당히 전략적으로 진행했습니다. 혼자서 싸울 마음이 사라지지 않았기 때문에 어떻게 조직 전체를 말려들게 할지는 주의 깊게 설계했습니다.

  • 사업책임자나 부문장·매니저 등 조직의 의사결정자를 처음부터 엮어놓는다
  • 체제 검토 및 예산 검토 시점에 무인화 시스템 대응을 모르는 척 태연하게 틀어넣는다
  • 제품 소유자가 관리하고 있는 시책 일정에 무인화 시스템 대응을 삽입하다
  • 필자 및 매니저를 단계별로 하여 고충을 상담할 수 있는 체제를 확립하다
  • 엔지니어가 불안해하지 않도록 엔지니어에게 설명하기 전에 대략적인 기술전략을 세워둔다.

활동이 본격화하고 나서 뒤집히면 100% 좌절하므로, 사업 운영·조직 운영의 의사결정자→비즈니스 측의 멤버→엔지니어의 차례로 커뮤니케이션 했습니다. “또한, 그림의 떡이 되지 않도록 체제 검토와 예산 검토에도 적절히 개입해 실행 가능한 환경 조성에 고심했습니다”

이 근처의 활동은 예산이나 권한이 있는 입장의 사람(CTO라든지)이 주도하면, 스피디하게 실행할 수 있을 가능성도 있습니다만, 필자 자신은 현장의 한 엔지니어이므로 시간을 들여 천천히 진행했습니다.

덧붙여서 엮어놓는다 라거나 틀어넣는다 라고 써 썼습니다만, 실천은 아무래도 힘듭니다. 실천 요령은 그다지 능숙하게 설명하기 어렵습니다만, 촌스러운 부분은 전부 스스로 맡고, 나머지는 지금까지 쌓아둔 신뢰저축을 사용해 어떻게든 해나갔습니다.

경험적으로는 보텀업(bottom-up)으로 조직을 움직이는 경우, 먼저 자신이 가장 힘든 부분을 맡으면 잘 돌아갈 가능성이 비교적 높습니다.

동기부여 제어

이 활동을 시작할 때 자신이 불태우지 않도록 단단히 주의를 기울였습니다. 이러한 종류의 활동은 왜 내가 하지 않으면 안되는걸까, 내 탓이 아니잖아, 하기 싫어 와 같은 부정적인 감정을 몇 번이나 안게 됩니다.

선인에 대한 경의는 중요합니다만, 그런 정론만으로 부정적인 감정은 소멸하지 않습니다. 무인화 시스템과의 전쟁만으로는 쿠사삭해져, 업무시간의 20%이상을 이 활동에 사용하지 않도록 배려했습니다. 어차피 조직을 움직이는 데에 시간이 걸리기 때문에 서두르지 않고 가기로 처음부터 결정하고 있었습니다.

또 최초의 반년 정도는 주위에의 말려드는 것을 최소한으로 억제해 거의 혼자서 진행했습니다. 서버의 조사나 공청회에는 다른 사람도 관여하고 있습니다만, 문제 분석·조직 전략 입안·기술 전략 입안은 대체로 혼자서 했습니다. 이건 의도적이에요.

이 활동은 주제가 주제라서 별로 재미는 없어요. 그러니까 언제 포기하고 싶을지 몰라요. 그러다 너무 힘들어지면 아무 일도 없었다는 듯이 시원하게 던질 수 있도록 해놓았던 것입니다.

최악의 경우 나는 도망가면 괜찮지만, 성대하게 처음부터 주위 사람들을 말려들게 하면 만일의 경우에는 죄송한 일이 됩니다. 그래서 만약 자신이 내던졌을 경우에도, 주위에의 영향이 최소한이 되도록 주의를 기울였습니다. 반대로 조직으로 확대하는 타이밍에는 자신이 없어도 갈 수 있도록 준비를 모두 마쳐두었습니다. 결과적으로는 던지지 않았지만 자신의 도망을 전제로 진행한 것은 정신건강상 좋았습니다.

버리는 문화

무인화 시스템 구축의 목적은 표면상 시스템을 운용 가능한 상태로 만드는 것이었습니다. 그러나 그 이면에는 숨겨진 테마로서 조직 문화의 변혁도 시야에 넣고 있었습니다.

저희는 좋게 말하면 새로운 것에 도전하기 쉬운 회사이지만, 한편으로는 ‘한 번했으면 계속 그것만 하는’ 나쁜 버릇을 겸비하고 있습니다. 그리고 이 같은 방식의 문화에서 제일 뒤처진 사람이 엔지니어입니다. 그래서 개인적으로 어떻게 해서든 뿌리를 내리고 싶었던 것은 버리는 문화입니다.

가치있는 제품을 만들기 위해 시행착오를 많이 겪는 것은 좋은 일입니다. 한편으로 시행착오의 속도를 유지하기 위해서는, 가치가 낮은 것을 버릴 필요가 있습니다.

그런데 우리에게는 만든 것을 버리는 문화가 없었습니다. 오히려 어디에 영향이 나올지 모르기 때문에 버리는 것이 무섭다는 상황이었습니다. 그래서 이 활동에서는 사사건건 버립시다! 라고 하는 메세지를 발신해, 필요 없는 시스템은 서슴없이 버렸습니다.
물론 문화가 그렇게 쉽게 바뀔리는 없고 지금도 한창 노력중입니다. 정말 버리는 문화를 정착시키려면 몇 년 더 있어야 할 것 같아요. 그러나 체감상으로는 점점 기능삭감이나 시스템 폐지가 쉬운 분위기로 되어가고 있습니다.

전략은 크게, 행동은 작게

무인화 시스템과 같은 복잡한 문제는, 이해를 깊게 하면 할수록 이거 뭐야? 라며 어찌해야할 지 모르는 경우가 발생합니다. 맹목적으로 돌격하면 즉사하기 때문에 문제분석과 전략수립에는 많은 시간을 써야 했습니다.

단지 생각만 하고 행동이 따르지 않으면 아무것도 진행되지 않습니다. 그 때문에 전략수립과 병행하고, 팀에서는 개선 활동을 차츰 진행했습니다. 팀과 함께 진행함으로써 탁상에서는 알 수 없는 문제의 파악과 해결책을 모색하는데 도움이 되었습니다.

조직을 크게 움직이면 궤도 수정이 힘들어요. 그래서 사전에 작게 검증해, 그 지견을 투입해 전략의 정도를 높였습니다. 이 근처는 아키텍처 설계 전의 PoC와 가깝습니다. 절대 한 방에 잘 될 리가 없기 때문에 나중에 바꾸기 어려운 점을 중점적으로 확인합니다.

이름이 없으면 볼 수 없다

‘조슈아 트리의 법칙’을 아시나요? 논디자이너스 디자인북에 나오는 이야기입니다. 상세한 내용은 책을 읽거나 구글에 검색해 주셨으면 합니다만, 간추려서 쓰면 **“사람은 이름이 없는 개념을 인지할 수 없다”**라는 아이디어입니다. 반대로 이름을 알아버리면 그것이 보이게 되는 겁니다.

이것은 조직을 움직이는 데 상당한 도움이 됩니다. 문제가 보이면 이제 공략법을 함께 고민하는 것만으로 끝납니다.

거기서 이 활동을 시작할 때, 적극적으로 무인화 무인화 시스템이라고 하는 키워드를 사용했습니다. 이 말은 필자의 조어가 아니라, 원래 일부 엔지니어가 사용하던 사내 밈입니다. 사내의 사람에게의 설명이나 문서의 집필에서는, 일관되게 이 용어를 사용했습니다. 그러자 점차 인지도가 올라가면서 완전히 조직 내 유비쿼터스 언어가 되었습니다.

지금은 엔지니어 뿐만이 아니라, 프로덕트 오너나 사업 책임자도 대부분 사용하는 말이 되고 있습니다. 최근에는 킥오프등에서 사용하는 사업 전략의 자료에도 등장하기 시작했습니다. 그냥 밈에서 상당히 출세한 거에요.

정리

본 기사에서는 무인화 시스템의 구축활동에 대해 소개했습니다.

  • 아무도 모르지만 왠지 작동하고 있는 시스템을 무인화 시스템이라고 부른다
  • 무인화 시스템에는 조직을 썩게 하는 골치아픈 특성이 있다
  • 무인화 시스템을 구축하기 위해서는 조직 관리와 엔지니어링 합치기가 필요
  • 무인화 시스템의 문제는 복잡하고 강력하므로 전략적으로 공략한다
  • 무인화 시스템과 싸우는 것은 정말 힘들다

싸워보고 나서 느낀 감상은, 정말로 정말로 너무 힘듭니다.

아무리 생각해도 속인화되어 있을 때 손을 쓰는 편이 100 배 편합니다. 오히려 속인화만세입니다. 또는 기술로 처리해 둘 수 있는 크기일 때 기술로 처리해 두는 것도 효과적일 것입니다. 문제가 너무 많다는 건 그것만으로 의욕이 꺽입니다. 기술적으로는 가능해도 정신적으로 불가능한 문제가 이 세상에는 있습니다.

한편으로 이미 비슷한 상황에 몰린 사람도 있을 것입니다. 만약 그런 사람이 있으면, 이 기사가 뭔가의 힌트가 되면 기쁘겠습니다. 조급해하시면 안 돼요.그 상황은 당신 탓이 아닌 겁니다. 힘 빼고 싸웁시다.

아무리 해도 지쳐 버린다면 도망가 버려도 상관 없습니다. 중요한 것은 자신의 인생입니다.

추신

혼자서 시작한 활동이지만, 이전보다 양호한 상태가 된 것은 협력해 준 사람들 덕분입니다. 특히 시스템 이행이 본격화되고 나서는 거의 필자가 움직이지 않아도 주변에서 자율적으로 진행해 주었습니다. 시스템 이행을 담당한 엔지니어는 고생이 많았을 것입니다. 수고하셨습니다.

마지막으로 모두에게 압도적 감사를 전하며 본 기사의 매듭으로 삼겠습니다. 정말 감사했습니다. 운용은 앞으로도 계속 되지만!

Ref

공유하기

tkim
글쓴이
tkim
Software Engineer