2022년 11월 16일 8층 세미나실에서 "구글 엔지니어는 이렇게 일한다"( http://www.yes24.com/Product/Goods/109182479 ) 의 역자 개앞맵시(이복연)님의 세미나가 있었습니다.
(발표자료: https://docs.google.com/presentation/d/1xEPcs1-q10QMy8WbBpzS-kdBCGH6d3RooKvHouCX7sE/edit#slide=id.p )
개발자뿐만 아니라 PM, QA 분들을 포함해서 많은 분이 참석하셨고, 경청하셨고, 다양한 질문도 많았습니다.
생각해보니, 이런 세미나를 그동안 많이 가지지 못했습니다.
외부 인사의 세미나는 우리의 목마름을 정확하게 해갈 시켜주지는 못하지만,
우리를 돌아보게 하고, 환기해주고, 운이 좋으면 영감도 주는 것 같습니다.
앞으로 좀 자주 외부 세미나를 어떤 형태가 되었든 가져보도록 하겠습니다.
청중을 좀 더 타깃팅해서 깊이도 더하도록 하겠습니다.
"구글 엔지니어는 이렇게 일한다"는 100명 정도의 공동 저자와 저술에 기여한 사람들이 구글의 소프트웨어 엔지니어링 전 분야에 대해 다루고 있어서 질의 응답 포함 2시간 진행된 세미나가 턱없이 부족했습니다.
발표 자료와 개앞맵시님의 한 마디 한 마디, 그리고 행간에 숨어 있는 거대한 내용들을 생각하며 들으니 발표자도 아닌데, 발표 후에 기진맥진했습니다.
방대한 내용 중에 몇 가지 감상을 기재해봅니다.
솔루션 운용사들의 공통적인 문제
최근에 기회가 되어 쏘카 서비스 엔지니어링 본부장인 지두현님의 '좋은 개발 문화'라는 주제의 세미나를 들었습니다.
쏘카는 10년간 운용해온 거대한 Monolithic의 쏘카 서비스를 "지속 가능한 서비스"로 만들어야 할 상황이 요구되어졌습니다.
그들이 그 과업의 선행으로 결정한 것은 Elastic 한 MSA 구조의 서비스를 만들기 위한 "조직 (프로세스 포함) 개편"이었습니다.
제가 세미나를 들었을 때는 그 결정 이후 1년이 지난 시점이었습니다.
그들은 배포 서비스를 정비했고, Micro service를 Bucket이라고 명했으며 그 Bucket을 위한 팀 (그룹)도 Bucket이라고 불렀습니다.
직군별로 팀을 구성하고 Bucket 팀은 직군 팀에서 필요한 인력을 데려와 구성합니다. 직군 팀은 팀장을 제외하고는 하나 이상의 Bucket 팀에 속합니다.
요즘 말하는 애자일 협업 스쿼드 (Agile Collaboration Squad)와도 공통점을 찾을 수 있습니다.
우리도 이나모리 가즈오 회장의 아메바 경영 방식에서 나온 "Silo"로 시작해서 Tailoring 후에 "사업팀"으로 Dev/PM/QA 분들을 모았습니다.
구글의 YouTube는 초기에 한 덩어리의 거대한 Python 프로그램이었다고 합니다. 배포할 때마다 장시간의 Full Regression Test를 했고, 서비스가 뜨지 않아 갖은 고생을 했다고 합니다. 배포할 때마다 퇴사자가 늘어났다고도 합니다. 그래서 그들은 YouTube를 새로 만드는 수준으로 대규모 변경을 했습니다.
우리도 감사하게 기존 솔루션으로 밥을 먹고 살고 있지만, "지속 가능한 솔루션을 위해"라는 표제어로 '대규모 변경/변혁'을 항상 고민하고 있습니다.
'시간 위를 걷는 프로그래밍'의 그 시간의 길이만큼 발생하는 '오래전 설계되어 개발된 것과 그것의 확장으로 생기는 수많은 양가적 문제들'을 우리뿐만 아니라 많은 회사가 공통으로 마주하고 비슷한 수준으로 고민하고 고통스러워하는 것 같습니다.
그래서 이번 세미나에서도 그 공통의 문제에 '공감'했고 '동병상련'했습니다.
CRScube가 가지고 있는 풀어야할 문제들이 CRScube의 섬에서만 있는 문제가 아님을 말씀드리고 싶습니다.
"코딩"과 "주변부"의 역전이
Software Engineering에서 "코딩 coding"을 제외한 나머지 DevOps, QA를 "주변부"나 "Staff"라고 부르기는 점점 더 어려워진 것 같습니다.
Cloud Computing으로 Environment 패러다임이 급격하게 변화했습니다. Cloud를 PaaS (Platform as a server)로만 쓰는 것도 구시대의 유물이 되었고, Cloud의 서비스들이 서비스의 완전한 Micro Service로 자리 잡아가고 있습니다. 그래서 DevOps Engineer는 자신이 '개발자인가?'라는 정체성의 질문을 스스로 던지기도 합니다.
MS가 지금 구글의 자리에서 위상을 떨칠 때, MS Window의 배포 프로세스와 그 속에 있는 정적분석과 테스트 시스템에 놀랐었습니다.
구글은 굉장히 분산된 컴포넌트와 Micro Service 들을 '자유롭게' 만들어 굉장히 유기적으로 Seamless 하게 그들의 서비스도 코드도 움직일 것 같지만, 그들의 20억 소스 코드는 하나의 Repository (Monorepo)에 담겨있습니다.
Monorepo는 구글의 최고 자산인 코드를 더 확실히 엄격하게 지키고, 그것을 위해 엔지니어는 잘 훈련되어야 하고 각종 도구가 올바르게 orchestration 되어서 동작해야 합니다. (Ref. Why Go Monorepo? https://blog.bitsrc.io/why-go-monorepo-413dac00ce7d)
그것을 위해 개앞맵시님이 말씀하신 것처럼 구글은 필요한 도구 (정적분석 도구)를 사서 자신들만 쓰고, 우리가 익히 알고 있듯이 IDC와 컴퓨터를 직접 만들어 쓰고 있습니다.
그리고 그들은 모든 것을 새롭게 재정의합니다. Git이라고 말하지 않고 Monorepo의 버전 관리를 Piper라고 하듯이요.
그래서 테스트도 Unit/Integration/System, Black/Gray/Whitebox 등으로 부르지 않습니다. 경계와 목적이명백한 Small/Medium/Large 테스트라고 부릅니다.
(Ref. Test Sizes https://testing.googleblog.com/2010/12/test-sizes.html , 이미 2010년에 이렇게 부르고 있네요)
다시 '시간 위를 걷는 프로그래밍' Programming Over Time으로 돌아와서 생각해봅니다.
'시간 위를 걷는 프로그래밍'을 설명할 때, 코딩된 소프트웨어는 시간이라는 X축 한 지점에 있는 막대 하나였고, 그것이 시간이 지나면서 변화하며 지속 가능하게 하는 것이 소프트웨어 엔지니어링이라고 했습니다.
우리는 그 '시간'을 '공간'으로 바꿔 볼 수 있습니다.
우리의 지금 시간을 멈추고 스냅샷을 찍어보면 '코딩'이라는 하나의 막대는 'Cloud Computing' 속의 수많은 막대와, '테스트'라는 막대, '프로세스'라는 막대, '디자인'이라는 막대, '요구 사항 분석'이라는 막대 등 수많은 막대와 함께 공존합니다.
그리고 그들은 점점 더 같은 키의 중요도와 난이도를 가져야 합니다.
제가 처음에 CRScube에 2016년 12월에 왔을 때는 PM 팀도 DevOps 팀도 Design 팀도 QA 팀도 없었습니다. 지금은요? 그 팀들을 배제하고 우리는 CRScube를 생각할 수 없습니다.
말씀드리고 싶은 것은 '코딩'만이 '주연'으로 무대에 오르는 시대가 가고, 모두가 무대에서 똑같이 중요한 역할을 해야 하는 시대로 빠르게 변화하고 있다는 것입니다.
그래서 슬랙의 #general-dev 채널에 개발자분들뿐만 아니라 DevOps와 QA 분들도 모셨습니다.
코드 리뷰 - 개발자의 대화 방법
회사에서도 코드 리뷰에 대해 고민하고 있었는데, 세미나에서도 절묘하게 코드 리뷰를 다루어주었습니다.
코드 리뷰의 목적과 방법에 대해서는 사람마다 상황에 따라 다양하게 이야기합니다.
한 사람이 프로그래밍한 것처럼 만들기 위한 것, 잠재적 오류를 선제적으로 방지하는 것, 지식을 나누는 것, Submitter의 역량을 점검하는 것.
모두 중요하고 필요한 것들입니다.
우리는 견고한 프로세스 내에 Gitlab의 Merge Request로 Code Review를 하고 각 Merge 들은 Jira Task에 연계되어 기록됩니다.
하지만, 아직 우리는 코드 리뷰를 '잘'하는 것에 대해서는 고민하지 못했습니다. Coding Standard도 명확하게 지정되어 관리되지 않고 있고, 코드 리뷰 절차도 명확하지 않습니다.
다행스러운 것은 그럼에도 불구하고 열심히 그리고 매우 인상적으로 코드 리뷰를 하시는 분들이 많습니다.
개앞맵시님이 말한 것처럼 개발자가 가장 자연스럽게 코드로 대화할 수 있는 '코드 리뷰'를 더 제대로 할 수 있게 개발자분들과 머리를 맞대고 고민하고 행해보려고합니다.
주어진 Task에서 시간을 짜내서 열심히 하는 코드 리뷰에 마찰을 일으키지는 않을 것이고, 그런 방향으로 흘러가면 꼭 말씀해주십시오.
혼자가 아니다
개앞맵시님은 변화를 꾀하였으나, 시간이 지나도 그 변화가 보이지 않아 포기했는데, 시간이 더 지나서 다시 보니 결국은 변화되어있었다고 합니다.
또한, 본인뿐만 아니라 같은 시간과 장소에 똑같은 고민으로 고군분투하는 사람들이 있었다고 합니다.
그래서 결국은 변하고 그 변화를 위해 노력하는 사람이 혼자가 아니니 포기하지 말고, 또 그런 사람들과 연결이 될 수 있으면 좋겠다고 하셨습니다.
그래서 소통과 공유가 중요한가 봅니다.
회사는 소통을 위해서 여러 가지를 시도하고 있습니다. 역효과를 내기도 하고 공감을 못 받기도 하지만, 나름의 효과를 얻은 것도 있습니다.
개발팀과 PM팀을 하나의 사업팀으로 합칠 때, 우려의 목소리가 많았습니다. 하지만 시간이 지나서 서로가 서로를 더 잘 이해/공감하게 되었고, 업무도 조금 더 투명하게 진행되고 있습니다.
그리고 그 '소통'을 위해 슬랙 #general-dev 채널을 만들기도 한 것입니다.
지속 가능한 솔루션
개앞맵시님의 발표 자료 서두에 '지속 가능한'이라는 말이 있어 반갑기도 하고 심박이 올라가기도 했습니다.
최근 리더 모임에서 '지속 가능한 솔루션을 위해 우리가 해야 할 일'에 대해 논하는 자리를 가졌었습니다.
발표에서 "구글의 워크플로"뿐만 아니라 "구글 엔지니어는 이렇게 일한다" 전체를 볼 때 "시간"과 "확장"이라는 두 키워드를 생각하며 구글이 왜 이런 활동을 하는지 생각해보라고 했습니다.
시간.
소프트웨어이든 그 소프트웨어와 관계하는 사람이든 "시간"을 통해서 변화할 것입니다. 이론 물리학에서는 시간이 흐른다는 것은 엔트로피가 증가하는 것이라고 합니다. 엔트로피는 복잡도이니, 시간이 흐를수록 소프트웨어와 사람이 점점 복잡해진다는 것입니다.
이익을 추가하는 회사는 생존과 성장을 위해 더 많은 외부 요인과 접촉하게 됩니다. 기존 고객이 이탈하지 않게 또 새로운 고객을 확보하기 위해 꾸준한 업데이트를 해야 합니다.
개발 언어, 프레임워크, 플랫폼, 환경, 심지어 사람들의 가치관과 문화의 패러다임 변화에 따라 '대규모 변경'이 요구되어지기도합니다.
확장.
짐 콜린스 Jim Collins의 Good to Great에서 수십 년 또는 세대를 거쳐 존속하는 회사는 좋은 회사가 아니고 위대한 회사입니다.
그런 위대한 회사는 조직의 크기가 점점 더 커질 것입니다. 창업 멤버만으로 수십 년 또는 세대를 거쳐 존속하는 이익집단은 일본의 라면집 정도겠지요.
2016년 12월 40여 명이었던 CRScube는 2022년 100여 명이 되었습니다. 매출도 두 배를 훌쩍 넘깁니다.
CRScube가 "지속 가능한" 이라는 말은 오랜 시간이 지나도 존속하는 회사이고, 존속 가능한 회사는 위대한 기업이 되어야 합니다. 당연히 매출도 늘어날 것이고 조직도 더 커질 것입니다.
그리고 그것에 걸맞게 솔루션도 더 커지거나 (복잡해지거나) 늘어날 것입니다.
꼬리에 꼬리를 무는 논리 놀이 같지만, 결국 이익집단인 회사의 솔루션은 "지속 가능"하려면 질이든 양이든 더 커져야 하고 그것을 위한 엔지니어는 당연히 더 많아질 것입니다.
혼자 개발하면 백업을 위해 드랍박스나 구글드라이브에 하드디스크를 연동하고 혼자 버전 관리하고 빌드하고 배포하면 되지만, 두 명만 되어도 협업을 위한 도구들이 순식간에 늘어납니다.
2014년 구글은 53,600명의 풀타임 근로자가 있었고, 그중 연구개발직이 20,832명이었다고 합니다.
전체 직원 수는 2015년 55,419명에서 2020년 1월에 105,000명이 되었다고 합니다.
2014년 2만 명이 (모두 SW Engineer는 아니겠지만) Monorepo로 개발한다면? 저는 상상이 가지 않습니다.
'구글 엔지니어는 이렇게 일한다'는 천재적인 엔지니어들이 크리에이티브하고 근사하고 멋지게 일하는 모습을 담은 것이 아니고,
시간에 따라 복잡도가 높아지고, 이익집단의 생리로 조직이 확장되는 구글이 '지속 가능'하기 위해서 야생에서 생존하기 위해서 고군분투하는 스냅샷을 담은 것일지 모릅니다.
마치며
책이 방대한 만큼 여러 가지 생각이 많았습니다.
"상용 소프트웨어의 비기능 (Non-functionality)은 기능 (Functionality)을 만든 후에 고도화라는 타이틀로 하는 것이 아닌 필수 요소인 것처럼,
코딩뿐만 아니라 소프트웨어 엔지니어링의 다른 모든 분야도 소프트웨어가 '지속 가능'하기 위한 필수 요소이다"가 한 줄 감상으로 남습니다.
그리고 그것은 혼자가 아니라 모두가 함께해야겠지요.
2022년 11월 18일
상암에서
여기대