Jan de Vries와 함께한 Dev Korea #9 현장: 카오스 몽키, 기술 부채, 그리고 서울을 가득 채운 참가자들

그날 밤 분위기가 궁금하신가요? 발표부터 네트워킹까지, Dev Korea #9 애프터무비를 확인해 보세요 🎥.

6월 17일, Dev Korea #9를 진행했습니다. 110명이 넘는 분들이 저녁 시간을 함께해 주셨습니다. 개발자, 플랫폼과 인프라 담당자, 창업자까지 서울 테크 씬 곳곳에서 모인 분들이 긴 발표 하나와 그 뒤로 이어진 대화를 함께했습니다.

네덜란드를 기반으로 활동하는 컨설턴트이자 트레이너, 코치이며 Antifragility.works와 BlueOceanRecon.com의 창업자인 Jan de Vries가 이번 발표를 맡았습니다. 2주 일정으로 한국을 처음 방문한 그는 그중 하루 저녁을 저희와 함께 보내기로 했습니다. 지난 3년 동안 벨기에, 스페인, 스위스, 룩셈부르크, 체코, 호주, 일본, 말레이시아, 캐나다의 컨퍼런스에서 안티프래질리티에 대해 발표해 왔고, 이제 그 목록에 서울이 추가됐습니다.

발표는 손을 들어 답하는 질문으로 시작했습니다. 안티프래질리티를 들어본 적 있는 사람은 네 명이었고, 리스크 관리 업무를 하는 사람은 없었습니다. 왜 이 두 질문을 함께 던졌는지는 한 시간 뒤에 분명해졌습니다.

리스크 관리는 리스크 시어터입니다

Jan은 알 수 없는 리스크에 대응하는 방법을 다룬 컨설팅 리포트로 이야기를 시작했습니다. 그 안에 적힌 전략을 하나씩 뜯어보면 거의 전부가 이미 알고 있는 리스크에 관한 것이라고 합니다. 결국 우리는 이름을 붙일 수 있는 실패에만 대비하고, 이름조차 없는 실패에는 대비하지 못합니다.

Nassim Nicholas Taleb가 리스크 관리를 리스크 시어터, 즉 일종의 연극이라고 부르는 이유가 여기에 있습니다. 그가 제시하는 대안은 더 정확한 예측이 아닙니다. 애초에 리스크에 덜 취약해지는 것, 나아가 리스크에서 이득을 얻는 것입니다.

2012년 전까지 취약하지 않은 상태를 가리키는 단어는 견고함(robust)과 회복탄력성(resilient) 두 가지뿐이었습니다. 《안티프래질》이 세 번째 단어를 더했습니다. Jan은 네 가지 상태를 각각의 이미지와 함께 설명했습니다.

• 프래질(fragile)은 유리입니다. 힘을 가하면 깨집니다.
• 로버스트(robust)는 철근 콘크리트, 또는 대통령 전용 차량입니다. 오래 버티지만 결국은 무너집니다.
• 리질리언트(resilient)는 불사조입니다. 되살아나지만 이전과 똑같은 새로 돌아올 뿐입니다. 소프트웨어로 치면 유압 계통이 고장 나면 백업으로 넘어가 계속 비행하는 에어버스 A380 조종석입니다. 설계된 수준보다 좋아지지는 않습니다.
• 안티프래질(antifragile)은 히드라입니다. 머리 하나를 자르면 둘이 자라납니다. 공격을 받을수록 강해집니다.

IT 세계의 히드라는 넷플릭스의 카오스 몽키입니다. 오전 9시부터 오후 3시 사이에 프로덕션 시스템을 무작위로 망가뜨려서, 엔지니어가 새벽 2시가 아니라 업무 시간에 문제를 고치도록 만듭니다. 인위적으로 지연을 주입하는 레이턴시 몽키도 있었고, 사용되지 않는 클라우드 리소스를 찾아 끄고 30분 뒤 다시 돌아오는 몽키도 있었습니다. 넷플릭스가 카오스 몽키에 완전히 면역이 되자, 더 큰 것을 망가뜨리는 카오스 고릴라를 만들었습니다. 시미안 아미 전체는 GitHub에 공개되어 있으니 직접 돌려볼 수 있습니다. 다만 테스트 환경부터 시작하시길 권합니다.

계층에 관한 이야기도 있었습니다. 항공기 한 대는 회복탄력적입니다. 하지만 항공 산업 전체는 안티프래질합니다. 모든 사고에서 배우기 때문입니다. 2018년과 2019년 737 MAX 사고 이후 전 세계의 동일 기종이 원인이 밝혀질 때까지 운항을 멈췄습니다.

IT에서 가장 취약한 것은 기술 부채입니다

소프트웨어에서 가장 취약한 것이 무엇이냐는 질문에 그가 기대한 답은 기술 부채였습니다.

이때 보여준 그래프는 가져다 쓸 만합니다. 소프트웨어가 오래될수록 변경 비용은 원래 올라가고, 그건 정상입니다. 기술 부채는 그 정상적인 선과 실제 변경 비용 사이의 격차입니다. 곡선이 하키 스틱처럼 꺾이는 순간부터 위험해집니다. 그 지점을 지나면 소프트웨어는 손을 쓸 수 없는 상태가 되고 고객 대응 속도도 사라집니다. 그는 Gene Kim의 정의를 인용했는데, 여전히 가장 좋은 정의입니다. 기술 부채란 다음에 무언가를 바꾸려 할 때 느끼게 되는 그 감각입니다.

이걸 걷어내는 방법이 Taleb가 말하는 비아 네가티바, 즉 덜어내는 힘입니다. 우리의 본능은 더하는 쪽입니다. 프로세스를 하나 더, 레이어를 하나 더, 도구를 하나 더 붙입니다. 비아 네가티바는 반대로 기능을 걷어내고, 의존성을 걷어내고, 레이어를 걷어내라고 말합니다.

실무적인 버전으로는 Project to Product에 나오는 네 가지 색 백로그를 소개했습니다. 초록은 기능, 빨강은 결함, 파랑은 부채 상환, 주황은 리스크 완화입니다. 고객이 요구하는 것은 언제나 초록과 빨강뿐입니다. 초록과 빨강만 처리하는 팀은 결함 수가 끝없이 늘어나는 걸 지켜보게 됩니다. 파랑과 주황에 계속 투자하는 팀만이 결국 결함 수가 줄어듭니다. 이 배분을 지키는 간단한 방법으로는 레이어를 나눈 칸반 보드를 추천했습니다.

이어서 각자의 회사는 어떤 배분에 가깝냐고 물었습니다. 한 분이 "초록이 아예 없는 열"이라고 답해 웃음이 터졌습니다. 그런 상태를 부르는 말이 있다고 Jan이 말했습니다. 리팩터링 스프린트입니다.

옵셔널리티, 그리고 벤더 락인이 아픈 이유

발표의 중반부는 세 가지 비대칭성을 중심으로 구성됐습니다. 첫 번째는 비선형성입니다. 무작위 사건에서 얻는 상방이 하방보다 큰 것은 안티프래질하고, 그 반대는 프래질합니다. 구분하는 요령은 그것이 고통 쪽으로 가속하는지 이득 쪽으로 가속하는지를 보는 것입니다. Jan은 프래질한 곡선은 찡그린 입, 안티프래질한 곡선은 웃는 입 모양이라고 기억하라고 했습니다.

월간 배포 횟수가 전형적인 웃는 입입니다. 0에서 몇 번으로 늘리는 구간은 조금 아픕니다. 계속 밀어붙여 CI/CD 파이프라인이 자리 잡고 나면, 하루 열 번을 배포하든 한 달에 세 번을 배포하든 상관없어집니다. 지속적 배포는 안티프래질합니다. 반대로 소프트웨어 프로젝트에서 조율해야 하는 작업의 수는 찡그린 입입니다. 처음에는 조율이 도움이 되지만, 의존성과 마감이 쌓이면서 고통 쪽으로 가속합니다. 소프트웨어 프로젝트는 프래질합니다.

두 번째는 옵셔널리티입니다. 옵션이라고 하면 대부분 금융 옵션을 떠올리고, 그건 비쌉니다. 하지만 정말 쓸모 있는 옵션 대부분은 금융과 무관하고 값이 싸거나 공짜입니다. 우리가 그것을 옵션으로 인식하지 못할 뿐입니다.

가장 명확한 안티패턴은 벤더 락인입니다. 그는 ERP 전략과 베스트 오브 브리드 전략을 나란히 놓고 항목별로 비교했습니다. 거의 모든 항목에서 베스트 오브 브리드 쪽이 우위입니다. ERP의 장점이라고 여겨지는 통합조차 실제로는 약속만큼 좋지 않은 반면, 단독 제품 벤더에게 통합은 통과하지 못하면 후보에서 탈락하는 기준이라 사활을 겁니다. 그의 결론은 ERP 시스템이 조직을 취약하게 만든다는 것이었습니다.

옵션을 늘리는 다른 방법들, 대부분 비용이 적게 드는 것들입니다.

• T자형 인재. 개인에게는 선택지가 늘고, 회사에는 교차 학습과 사일로 완화라는 이점이 생깁니다
• 최소 3 이상의 버스 팩터. 버스 팩터가 1이면 한 사람의 퇴사로 프로젝트가 끝납니다
• 진짜 중복성. 그의 비유로는, 항상 왼쪽으로만 잔다면 매트리스는 절반만 있어도 되지만 그건 중복성이 0인 상태라 작은 문제 하나에 잠을 망치게 됩니다
• 관측 가능성. 모니터링은 알려진 미지를 다루고, 관측 가능성은 알려지지 않은 미지를 다룹니다. 안티프래질리티가 관심을 두는 영역이 정확히 후자입니다
• 바벨 전략. 자원의 8090%는 지루하고 안전하며 예측 가능한 일에, 나머지 1020%는 진짜 투기적인 시도에 넣습니다. 중간은 피합니다
• 마이크로서비스. 되돌릴 수 없는 큰 결정 하나를 되돌릴 수 있는 작은 결정 여러 개로 바꿔줍니다. 하나가 잘못되면 그것만 다시 쓰면 되고, 제국 전체를 다시 쓸 필요가 없습니다

마지막 항목에는 많은 분들이 기억한 표현이 붙었습니다. 소프트웨어에는 규모의 비경제가 작동합니다. 우유는 큰 통에 담을수록 싸지만, 소프트웨어는 작은 통에 나눠 담을수록 쌉니다.

MTBF와 MTTR 중 무엇이 안티프래질한 지표냐는 질문도 던졌습니다. 답은 MTTR이고, 차이가 큽니다. 평균 고장 간격을 늘리는 데 집중해야 하는 경우는 두 가지뿐입니다. 우주로 쏘아 올린 하드웨어, 그리고 사람 몸에 이식된 의료기기입니다. 그 외의 모든 경우에는 복구를 최적화해야 합니다. 안티프래질한 시스템은 실패가 일어난다는 것을 전제로 하기 때문입니다. 그런 시스템은 늘 조금씩 망가지도록 되어 있고, 바로 그 점이 시스템을 강하게 만듭니다.

스킨 인 더 게임

세 번째 비대칭성은 취약성의 전가입니다. 한쪽이 하방을 떠안고 다른 쪽이 상방을 가져가는 구조입니다. 그 반대가 스킨 인 더 게임, 즉 잃을 것이 실제로 있는 상태입니다.

그의 예시는 3,700년 전으로 거슬러 올라갑니다. 함무라비 법전 229조는 건축가가 지은 집이 무너져 집주인이 사망하면 그 건축가를 사형에 처한다고 정했습니다. 그 뒤로 메소포타미아의 집들은 눈에 띄게 튼튼해졌습니다.

그리고 같은 관점을 소프트웨어 조직에 적용했습니다.

• 사일로는 조직을 취약하게 만듭니다. dev 사일로 안의 개발자는 ops 게임에 걸린 것이 없고, 반대도 마찬가지입니다. DevOps가 실제로 작동하는 이유가 여기 있습니다. 오전에 만든 것을 오후에 직접 운영하게 되니까요.
• 프로젝트도 조직을 취약하게 만듭니다. 프로젝트 매니저는 납기와 초기 비용을 책임지지만, 그 뒤 20년간 발생하는 운영 비용은 대개 책임지지 않습니다.
• 지휘 통제 구조도 마찬가지입니다. 정보가 권한을 향해 올라가고 결정이 다시 내려오는 동안 모든 것이 느려지고 나빠집니다. 해법은 권한을 정보가 있는 곳으로 내리는 것이고, 그러려면 기술적 역량과 조직적 명확성, 공유된 우선순위가 필요합니다.

이 절의 마무리는 조직 부채였습니다. Steve Blank는 이를 기술 부채와 비슷하지만 더 나쁜 것이라고 표현합니다. 조직의 위계가 실제 업무 흐름을 방해하는 상태입니다. 게다가 공정한 싸움이 아닙니다. 콘웨이의 법칙에 따르면 시스템은 결국 조직의 커뮤니케이션 구조를 그대로 닮게 되기 때문입니다. 1967년에 발표됐고 아직 깨지지 않았습니다. 다행인 점은 이 법칙을 의도적으로 이용할 수도 있다는 것입니다. 더 단순한 시스템을 원한다면 조직을 먼저 단순하게 만들면 됩니다.

이 부분에서 가장 날카로웠던 지적은 Frederick Taylor에 관한 것이었습니다. 그는 1911년에 과학적 관리법의 다섯 가지 원칙을 발표했고 1915년에 세상을 떠났습니다. 관리자가 결정하고 노동자가 실행한다는 구조입니다. 지금 회사가 여전히 그렇게 돌아간다면, 조립 라인을 위해 만들어진 115년 된 운영 모델로 소프트웨어를 만들고 있는 셈입니다.

조직이 디지털 전환에 준비되지 않은 이유는 대부분 기술적인 것이 아니라고 그는 말했습니다. 기술적으로는 풀 수 있습니다. 조직적으로는 여전히 문제로 남습니다.

프래질리스타가 되지 마세요

마지막 슬라이드는 그의 조언이었고, 의도적으로 직관에 어긋납니다.

파이프라인을 초록색으로 유지하려고 모든 작은 실패를 억누르는 CI/CD 엔지니어는 훨씬 큰 실패를 예약해 두는 것과 같습니다. 작은 실패는 숨기면 안 됩니다. 드러내고, 보이게 하고, 모두가 알게 해야 합니다. 에러 버짓을 쓰세요. 리스크가 크고 보상도 큰 기능을 배포하세요. 낡은 인프라를 업그레이드하세요. 재해 복구 훈련을 하세요.

블랙 스완을 피하는 것은 불가능합니다. 하지만 그것을 견디는 시스템을 만드는 건 가능합니다.

가득 찬 공간과 길게 이어진 Q&A

110명이 넘는 분들이 저녁 내내 자리를 지켰습니다. 6시 30분에 문을 열자 피자와 버거가 체크인 시간 동안 빠르게 사라졌습니다. 보통 첫 대화는 자리에 앉기 전 이 시간에 시작됩니다.

Q&A는 길게 이어졌고, 좋은 의미로 그랬습니다. 발표 중간에 시작해서 사실상 끝나지 않았습니다. 인프라를 코드로 관리할 때 클라우드 락인을 피하는 방법, AI를 활용한 개발이 기술 부채를 줄이는 속도보다 쌓는 속도가 빠른 것은 아닌지, 리스크를 꺼리는 회사 안에서 안티프래질리티를 어떻게 설득할지, 조직 측면에서는 무엇을 읽어야 할지, 그리고 안티프래질리티가 모든 팀에 들일 만한 비용인지에 대한 질문이 나왔습니다.

참석자 두 분 사이에서 좋은 장면도 나왔습니다. 한 분이 분산 인프라에 관한 질문을 던졌고 Jan이 자신의 기술적 범위를 넘어선다고 답하자, 다른 참석자가 이어받아 이상 탐지를 직접 구축했던 경험을 공유했습니다. Jan의 후속 질문은 그렇게 발견한 이상 징후를 조직 전체에 공유했느냐는 것이었습니다. 공유했다고 하자, 바로 그게 핵심이라고 했습니다. 잘못된 것을 찾아낸 일은 자랑스러워해도 되는 일입니다.

그리고 안티프래질이라는 제목의 K팝 노래가 있다는 걸 아느냐는 질문도 나왔습니다. 그는 몰랐지만, 안티프래질로 걸어둔 구글 알림에 음악 관련 결과가 대부분이라는 건 알고 있었습니다.

음식이 남았든 아니든, 많은 분들이 네트워킹 시간까지 남아 이야기를 이어갔습니다.

감사합니다

이번 행사는 아래 분들 덕분에 가능했습니다.

• 한국에 머문 2주 중 하루 저녁을 내어 한 시간을 채워 주고, 아직 답이 없는 부분은 없다고 솔직하게 말해 준 Jan de Vries
• 버거를 제공해 준 Cry Cheeseburger
• 그날 저녁을 굴러가게 해 준 자원봉사자 Sonali, Brian, Chanwu, Oscar, Rob
• 그리고 찾아와 주시고, 질문하고, 서로의 질문에 답하고, 끝까지 남아 이야기를 나눠 주신 모든 분들

발표 다시 보기

발표 영상은 아래에서 보실 수 있습니다.

• Beyond resilience: Architecting antifragile systems, by Jan de Vries

지금까지 공개된 Dev Korea의 모든 발표는 발표 페이지에서 확인하실 수 있습니다.