데브옵스 아티스트 겸 AWS 컨테이너 히어로 송주영 님
개발자, 엔지니어는 늘 ‘일을 효율적이고 속도감 있게 잘하는 방법’이 무엇인지 고민하는 사람들인 것 같습니다. 송주영 데브옵스 아티스트 겸 AWS 컨테이너 히어로도 그렇습니다. 그가 처음 커리어를 시작했을 때 AWS 솔루션들을 사용하는 업무를 맡았는데요. 이때 일을 잘해보고 싶어서 깊이 파고들다 보니 해외에서 데브옵스(DevOps)라는 트렌드가 보였다고 해요.
데브옵스는 소프트웨어 개발 방법론의 하나로, 개발(development)과 운영(operation)의 합성어입니다. 개발 담당자와 운영 담당자가 연계하여 협력하는 개발 방법론을 말해요. 따라서 시스템 개발자와 운영을 담당하는 IT 전문가 사이의 소통, 협업, 통합 및 자동화를 강조합니다.
*출처: 『데이터 품질의 비밀』(디코딩, 2023)
원래 효율적으로 일하기를 좋아했던 송주영 엔지니어는 데브옵스를 다른 사람들과 함께 꼭 한번 적용해보고 싶었다고 해요. 그때부터 관련 스터디와 커뮤니티 모임에 참석했고, 강연도 나섰고요. 그렇게 ‘일을 잘하고 싶다’는 생각으로 시작한 것이 그를 AWS 컨테이너 히어로까지 이끌었고 데브옵스 아티스트가 되고 싶다는 열망을 가지게 만들었습니다. 그에게 개발 방법론 트렌드, 개발 철학, 국내에서 데브옵스를 하며 어려웠던 점 등을 들어 보았습니다.
Q_안녕하세요. 요즘 어떻게 지내시나요?
송주영_지금 몸담고 있는 기업에서 데브옵스 액셀러레이션 팀 소속으로, 퍼블릭 클라우드 위에 서버를 구축하고, 운영하며, 모니터링하는 업무를 맡았습니다. 또 독특하게도 다른 팀의 업무도 지원하고 있습니다. 각 팀에 데브옵스를 빠르게 정착시켜서 구성원들과 해당 팀 전체를 성장시키는 것이 저희의 목표입니다.
Q. 현업에서 데브옵스를 정착시키는 데 앞장서고 계시는군요. 지금 그 업무를 하시면서 가장 중요하게 고려하시는 것은 무엇인가요?
송주영_지금 하는 업무 뿐만 아니라, 프로덕트를 맡을 때마다 눈여겨 보는 부분은 조직의 관행입니다. 한국에서는 소프트웨어 산업이 발전한 지 비교적 얼마 되지 않았는데도 기술 부채와 개발문화에서의 관습이 남아 있는 조직들을 자주 봅니다. 그런 곳에서는 새로운 소프트웨어 엔지니어링 방법론을 받아들이기가 어려울 가능성이 높아요. 그래서 데브옵스를 잘 적용할 수 있으려면 조직의 기존 상황을 가장 중요하게 고려합니다.
Q. 주영님은 커리어를 시작할 때부터 데브옵스를 접했고, 이후 지속적으로 관련 업무를 하셨어요. AWS 본사에서 선정한 컨테이너 히어로로서도 국내에 데브옵스를 많이 알리셨고요. 그동안 어떤 변화를 발견하셨나요?
송주영_이제 해외에서 데브옵스는 당연해졌어요. 2012년에서 2016년 사이 전 세계에서 퍼블릭 클라우드를 잘 쓰는 방법이 트렌드였고 데브옵스는 그 중심에 있었어요. 그런데 지금은, 적어도 해외에서는, 이를 적용하고 있는 조직이 이미 많아졌습니다. 그래서 심지어 마케팅 용어로서도 힘을 많이 잃은 상황이에요. 한국에서도 곧 그럴 것이라고 봅니다.
Q. 그러면 지금은 어떤 개발 방법론이 주목 받고 있을까요?
송주영_데브옵스처럼 트렌드로 떠오르는 방법론은 없는 것 같아요. 다만 퍼포먼스 오리엔티드(Performance-oriented)라는 개념이 많이 들려요. ‘같은 결과에 빠르게 도달할 수 있는 방법’을 의미합니다. 그래서 데이터를 통해서 고객 니즈를 얼마나 빨리 포착하고 서비스 및 제품에 반영할 수 있는지를 측정하는 작업이 중요해졌어요.
그런데 말이 쉽지, 퍼포먼스 오리엔티드 방법론을 실제로 적용하려면 데이터를 얻기 위해 사용하는 기술 및 운영 방식에 관해 합의를 이루어야 하고요. 또 실패를 내재하고 있기 때문에 시도, 실패, 고객의 니즈를 반영해서 재시도, 다시 실패하는 과정을 무한히 반복해야 합니다. 그래서 조직문화 자체를 이 방법론 위주로 대대적으로 개편해야 한다는 주장도 있어요.
Q. 시도와 실패를 반복하는 것이 당연한데, 실제로 감당하기는 쉽지 않아보여요.
송주영_맞아요. 그래서 조직이 그만큼 빨리 대응해야 하기 때문에 구성원들의 번아웃이 이슈가 되고 있어요. 하지만 우리는 스티브 잡스가 아니기 때문에 실패를 하면서, 해당 실패 사례를 점차 줄여가자는 주장이에요. 물론 그 과정에서 비용 절감은 필수입니다.
Q. 결국 어떤 방법론이든 ‘일을 잘하자’는 것이 목표겠네요. 그럼에도 주영님은 데브옵스 전문가시니 특히 중요시하는 부분이 있으실 것 같아요. 예를 들어 프랑스의 하이엔드 명품 패션 브랜드 루이비통의 아카이빙에서 영감을 얻으신다고 들었습니다. IT 업계에서 일하시면서 패션 업계의 업무 방식을 벤치마킹하신 점이 특별하다고 생각했어요.
송주영_네. 루이비통은 160년 동안 패턴, 소재, 디자인, 컬렉션 등을 전부 아카이브했습니다. 우리는 헤리티지와 아카이빙이 중요하다는 사실을 알고 있지만 이를 전략적으로 관리해야 한다는 사실은 간과하고 ‘저절로 쌓일 것’이라고 간주합니다. 그러나 루이비통은 이를 잘 해서 100년 넘게 1등을 하고 있다고 생각합니다.
이를 IT에 적용하면 데브옵스와 자동화를 실시하고 업무 내용을 축적해서 자산화 해야한다는 사실을 의미합니다. 자산화를 하는 이유는 주위 동료가 편안하게 일을 하고 성장할 수 있게 만들기 위해서입니다. 한 팀으로서 개발 과정을 물 흐르듯 진행해서 속도를 높이고 퍼포먼스를 잘 내어, 서로 워라밸(Work and life balance, 일과 생활의 균형)을 챙겨주자는 게 목표입니다.
Q. 명쾌한 설명이네요. 그런데 정확히 ‘어떻게’ 빠르고 정확한 개발을 구현할 수 있을지, 구체적인 방법도 궁금합니다.
송주영_‘Infra-as-a-code(코드 기반 인프라)’라는 개념이 있습니다. 서버 인프라를 만드는 과정과 툴을 코드로 짜는 일이에요. 예를 들어 이메일을 보낸다고 가정해 봅시다. 그러면 로그인을 한 뒤 이메일을 작성하면 되겠지요. 이 시스템을 코드화 하는 작업은 다음과 같습니다. 언제, 누구에게, 어떤 내용을 보낸다고 명세서를 작성합니다. 그러면 자동으로 돌도록 구축된 시스템이 이 명세서를 읽어서 이메일을 보내게 만듭니다. 이것이 코드 기반 인프라예요. 데브옵스 엔지니어들은 여기서 명세서 등의 문서들에 의해 뒷단의 서비스가 자동으로 작동하도록 코드를 잘 작성하는 일을 맡습니다. 그러려면 뭘 하나를 만들더라도 넓고 깊게 보아야 해요.
그래서 데브옵스 엔지니어들은 소프트웨어를 하나 설치할 때도 완료했다고 끝나는 게 아니라 다음에 설치할 때를 고민해서 문서로 아카이브합니다. 즉 ‘다시 설치할 때 속도를 더 높이려면 프로세스를 어떻게 개선하는 것이 좋지?’, ‘이 설정을 더 낫게 만들려면 어떻게 하는 것이 좋지?’ 등을 재고해서, 도구를 사용해, 체계에 맞게 기록해 두어야 한다는 이야기입니다. 뿐만 아니라 이 소프트웨어를 설치한 이유 등 기본적인 내용을 모두 문서로 축적하고 공유합니다. 사실 소프트웨어 개발을 하는 사람들이면 다 관심있을 내용이에요.
Q. 이런 취지에도 불구하고 국내 조직에 데브옵스를 적용할 때 어려움이 있으셨을 것 같아요. 설득도 많이 하셨지요?
송주영_그렇죠. 모든 것이 설득이었습니다. 일단 조직 입장에서는 “왜 그렇게까지 하느냐”고 하기 쉽습니다. 매일 할 일도 많은데 일단 조직이 잘 굴러가고 있다고 생각하는 상황에서 새로운 개발 방법론을 제안하면, 일을 복잡하게 만든다고 할 수 있죠. 물론 데브옵스가 완벽하지는 않습니다. 그러나 장기적으로 보았을 때 기존 관행을 바꾸었을 때 효율성과 퍼포먼스를 높일 수 있다고 하면 시도할 가치가 있다고 생각합니다.
심지어 저는 데브옵스를 적용해서 일을 잘해낸 구체적인 사례들을 만든 바 있고 퍼포먼스를 높인 경험도 많은데, 그럼에도 조직들을 설득하기 쉽지 않았어요. 처음에 하도 고군분투하니, 아는 분이 이런 말씀을 하시더라고요.
“네가 아무리 데브옵스의 좋은 점을 이것저것 말해도, 어차피 사람들은 기억을 잘 못한다. 하지만 사람들을 감정적으로 괴롭히면, 그 일은 오래 기억에 남는다”
이후에는 이 격언을 마음에 품고 일을 하고 있습니다.
Q. 어떤 점이 특히 어려웠나요?
송주영_(특히 국내에서는) 조직에 변화를 주려면 위에서부터의 인식 변화가 필수예요. 그러려면 기본적으로 토론, 논쟁, 설득을 해야하는데 한국 조직들은 이를 무조건 제로섬(zero-sum)으로 받아들이거든요. 한쪽의 이득과 다른 쪽의 손실을 더하면 0이 되는 극단적인 상황으로 인식하는 것이에요. 하지만 이는 사실이 아닙니다. 다같이 ‘일을 잘하자’는 목표를 두고 개발 방식, 조직 문화를 개선하자고 논의하는 것 자체가 윈윈(win-win)이에요. 모두가 득을 보기 때문입니다.
그래서 단순히 개발 방법론을 도입하는 것이 아니라 이렇게 조직에서의 인식 변화도 일으켜야 하는 상황들이 어렵게 느껴졌습니다. 이제 와서 얘기지만 AWS 본사 컨테이너 히어로가 되려고 노력한 이유 중 하나도 설득력을 높이기 위함이었는데요. 그래도 어렵더라고요. 그래도 지금은 많은 분들이 데브옵스의 장점을 알아보고 조직에 도입하려고 노력하고 계세요. 그래서 적어도 사람들이 익숙하게 느끼시는 것 같고요.
Q. 그렇게 고생도 하고, 보람도 느끼면서 데브옵스 아티스트로서 일을 잘하는 방법을 찾는 여정을 지속해 오신 것 같아요. 마지막으로 데브옵스를 적용하려는 분들에게 한 마디 전해주시면 좋겠습니다.
송주영_개발은 사람 사이의 소통과 비슷하다고 생각합니다. 예를 들어 코드를 짜는 것은 효율화된 개발 언어로 ‘코드’라는 결과물을 만들어서 감정과 정보를 전달하는 과정이에요. 그래서 각자 하는 일이 명확한 상황에서, 팀들 간의 경계 없이 서로 룰을 인지하고 있으면 감정과 정보를 전달하는 과정이 원활해지므로 퍼포먼스가 훨씬 잘 납니다. 다시 말해 데브옵스든 퍼포먼스 오리엔티드든 모두 효율적으로 일을 잘하자는 목표를 두고 적용할 수 있는 개발 방법론이에요. 이를 명심하고 데브옵스, 자동화 등을 잘 도입해 봅시다. 저도 아직 해결하고 싶은 케이스들이 많아요!
