‘행동 편향’은 실제 피드백을 만드는 최소한의 책임 있는 한 걸음을 기본값으로 삼되, 틀려도 치명적이지 않고 빠르게 바로잡을 수 있도록 가드레일을 미리 약속해 두는 태도다.
URL: https://addyosmani.com/blog/bias-towards-action/
Title: Bias Toward Action
HomeGitHubPressBiographyLinkedInTwitterNewsletterBlog
행동 편향은 실제 피드백을 만들어내는 최소한의 책임 있는 한 걸음을 기본값으로 삼되, 틀려도 살아남을 수 있고 빠르게 수정 가능하도록 가드레일을 미리 약속해 두는 것이다.
“행동 편향(bias toward action)”이라는 말은 스타트업 창업자가 무모한 일을 하기 직전에 외치는 구호처럼 들릴 수 있다. 하지만 그렇지 않다. 제대로 하면, 이건 사실 틀렸을 때도 당신을 죽이지 않게 하면서 더 빠르게 학습하는 방법에 가깝다.
이게 실제로 의미하는 바는 이렇다: 실제 피드백을 만들어내는 가장 작은 한 걸음을 내딛되, 깨졌을 때 정확히 어떻게 복구할지 알고 있어라.
그게 전부다. 나머지는 그게 가능하도록 만드는 엔지니어링 규율이다.
Stripe는 운영 원칙인 “Move with urgency and focus(긴급함과 집중으로 움직여라)”에서 이를 잘 설명한다. 이는 무모함이 아니라, 내일 더 빨라지게 해 주는 기반에 투자하면서 학습 속도를 최적화하는 것이다.
빠른 팀은 느린 팀보다 정보가 적어서가 아니라, 더 많은 정보를 활용한다. 다만 완벽한 정보를 기다리지 않을 뿐이다.
실제로 빠르게 출시하는 팀들을 보면 흥미로운 점이 있다. 이들은 생각을 건너뛰지 않는다. 카우보이처럼 막 밀어붙이지도 않는다. 대신 피드백 루프가 아주 촘촘하다.
연구도 이를 뒷받침한다. 고속(high-velocity) 환경에서의 빠른 의사결정을 연구한 Kathleen Eisenhardt의 연구는 직관과 다른 결론을 보여준다. 빠른 의사결정자는 느린 팀보다 정보를 덜 쓰는 게 아니라 더 썼다. 더 많은 대안을 만들고, 더 나은 조언(자문) 프로세스를 사용했다. 다만 완벽한 정보를 기다리지 않았다. 알고 싶은 것의 약 70% 정도만 확보되면 결정을 내리고, 작은 것을 출시한 뒤, 결과로부터 학습했다.
빠른 팀과 느린 팀의 차이는 용기가 아니다. 인프라다.
속도는 위험한 일을 용감하게 하는 데서가 아니라, 안전한 일을 쉽게 만드는 데서 나온다.
빠른 팀에는 이런 것들이 있다:
느린 팀은 매 배포가 위험하게 느껴져서 갇힌다. 그리고 실제로 위험하다. 안전망이 없기 때문이다.
대부분의 결정은 그렇게 설계하면 되돌릴 수 있다. 종종 가장 레버리지가 큰 움직임은 단방향 문을 양방향 문으로 바꾸는 것이다.
Jeff Bezos는 2015년 주주서한에서 이 프레임워크를 설명했다. 어떤 결정은 다시 돌아올 수 없는 문을 통과하는 것과 같아서 신중한 사고가 필요하다. 하지만 대부분의 결정은 양방향 문이다. 해보고 별로면 다시 돌아오면 된다.
문제는 우리가 너무 많은 결정을 단방향 문처럼 취급한다는 점이다.
숙고를 위해 속도를 늦추기 전에 스스로에게 물어봐라: 이걸 되돌릴 수 있게 만들 수 있을까?
어떤 때는 답이 “기능 플래그를 추가한다”일 수 있다. 어떤 때는 “트래픽 1%부터 시작한다”일 수 있다. 어떤 때는 “두 시스템에 듀얼 라이트(dual-write)해서 되돌아갈 수 있게 한다”일 수 있다.
되돌릴 수 있게 만드는 일은 종종 당신이 할 수 있는 가장 레버리지 높은 일이다. 무서운 단방향 문을 안전한 양방향 문으로 바꿔 준다.
에러 버짓은 속도 vs 신뢰성에 대한 철학적 논쟁을 객관적 임계값으로 대체한다. 변화에 쓸 ‘예산’이 있거나, 없거나 둘 중 하나다.
Google의 SRE 에러 버짓 정책에서 유용한 구체적 사례가 있다. “에러 버짓(error budget)”이라는 개념이다.
당신의 서비스에는 SLO가 있다. 예를 들어 가동률 99.9%라면, 남는 0.1%가 에러 버짓이다. 허용되는 ‘깨짐’의 양이다.
규칙은 간단하다:
이건 대화를 완전히 바꾼다. 제품팀과 엔지니어링팀이 속도를 늦출지 두고 싸우는 대신 숫자를 본다. 버짓 안인가? 그럼 출시. 버짓을 다 썼는가? 그럼 먼저 고쳐야 한다.
장애의 약 70%는 변경(change)에서 온다. 그래서 변경을 더 안전하게 만드는 메커니즘이 필요하다.
점점 비율을 올리며 여러 번 프로덕션에 배포하는 것이, 한 번의 신중한 빅뱅 배포보다 더 안전하다. 틀렸을 때의 폭발 반경(blast radius)이 아주 작게 유지되기 때문이다.
실제로 “행동 편향”이 현장에서 어떤 모습인지 구체적으로 예를 들어보자. 참고로 기존 사용자가 많지 않은 고속 스타트업이라면 훨씬 단순할 수 있다: 배포하고, 모니터링하고, 문제가 있으면 되돌린다.
그 외의 경우, 예를 들어 지연 시간(latency)에 영향을 줄 수 있는 요청 경로(request path)를 바꾼다고 해보자. “행동 편향” 버전은 이렇게 보인다:
1단계: 시작하기 전에 무엇이 “깨짐”인지 정의한다. SLI를 고른다—예: 에러율과 p99 지연 시간. 중단할 임계값을 정한다.
2단계: 변경을 기능 플래그 뒤에 둔다. 재배포 없이 끌 수 있게 된다.
3단계: 플래그를 끈 상태로 프로덕션에 배포한다. 코드는 있지만 아직 실행되지 않는다.
4단계: 트래픽 1%에 대해 플래그를 켠다. 메트릭을 관찰한다.
5단계: 메트릭이 좋으면 5%, 25%, 50%, 100%로 점진적으로 올린다. 어떤 지점에서든 이상이 보이면 플래그를 끈다.
6단계: 완전히 롤아웃되고 안정화되면 플래그를 제거한다.
여기서 중요한 점: 프로덕션 배포를 여러 번 하고 있지만, 틀렸을 때의 폭발 반경이 매우 작다. 트래픽 1%라면, 틀렸을 때도 일부 사용자만 몇 분 정도 문제를 본다.
이 접근은 Google SRE의 카나리(canary) 배포 가이던스에서 온 것이다. 테스트로 모든 결함을 잡을 수 없기 때문에, 프로덕션 트래픽의 작은 일부를 노출하고, 카나리를 컨트롤(control)과 비교 평가한다.
이를 “신중한” 접근과 비교해보자: 스테이징에서 3주 테스트하고, 프로덕션 100%에 빅뱅 배포한다. 뭔가 깨지면 모두가 본다. 롤백은 또 하나의 프로덕션 작업이 된다.
실제로 어느 쪽이 더 안전한가?
Google의 릴리스 엔지니어링 프랙티스도 이를 명확히 한다. 높은 속도는 버전 사이 변경량이 더 적은 잦은 릴리스에서 나오며, 테스트와 트러블슈팅을 쉽게 만든다. 어떤 팀은 “push on green”을 한다—모든 테스트를 통과한 모든 빌드를 배포한다.
카나리는 인프라 메트릭이 아니라 사용자가 실제로 중요하게 여기는 것을 측정해야 한다.
카나리는 훌륭하지만, 올바른 것을 봐야 한다.
나는 카나리가 사용자 가치와 몇 단계 떨어진 기술 메트릭만 보는 팀을 본 적이 있다. 카나리는 통과하고, 모두에게 롤아웃한 뒤, 특정 조건에서만 드러나는 미묘한 버그 때문에 에러율이 급등한다.
카나리는 사용자가 실제로 중요하게 여기는 것을 측정해야 한다.
Google SRE 가이드는 이를 명시한다. CPU 같은 메트릭은 노이즈가 많고 서비스 영향과 직접 매핑되지 않을 수 있다. 카나리는 사용자 경험을 대표하는 SLI에 연결되어야 한다.
또 하나의 미묘한 포인트: 실패 모드를 볼 수 있을 만큼 카나리를 충분히 오래 돌려야 한다. 어떤 버그는 캐시가 워밍업된 뒤, 특정 트래픽 패턴이 나타난 뒤, 메모리 압력이 쌓인 뒤에야 나타난다.
가능하면 한 번에 하나의 카나리를 실행하라. 여러 카나리를 동시에 돌리면 무엇이 문제를 일으켰는지 파악하기 매우 어렵다.
고위험 시스템에서의 “행동 편향”은 통제와 안전망을 건너뛰는 것이 아니라, 최악의 결과를 경계(bound)하는 통제와 안전망에 투자하는 것을 의미한다.
가드레일 없는 “빠르게 움직여라”가 어떤 모습인지 보자.
2012년 Knight Capital은 거래 소프트웨어를 배포했다. 배포 오류가 있었고—일부 서버에서는 오래된 코드가 계속 실행되고 있었다. 45분 만에 시스템은 수백만 건의 잘못된 주문을 전송했다. 회사는 4억 6천만 달러 이상을 잃었고, 거의 파산할 뻔했다.
SEC의 명령과 보도자료는 가혹하다. 적절한 배포 절차가 없었다. 킬 스위치(kill switch)가 없었다. 출혈을 멈췄을 사전 거래 한도(pre-trade limits)가 없었다. SEC는 특히 “각 구성 요소가 오작동하면 어떤 일이 일어나는지, 어떤 안전망이 피해를 제한하는지”를 묻는 것을 강조했다.
이건 “최소한의 책임 있는 한 걸음” 없는 “행동 편향”이 낳는 결과다. 빨리 움직인다. 맞다. 벽을 향해 아주 빠르게.
교훈은 “느리게 움직여라”가 아니다. “틀렸을 때 죽지 않게 하면서도 빠르게 움직일 수 있는 안전망에 투자하라”다.
결제, 트레이딩, 인증 같은 고위험 시스템에서도 행동 편향은 유효하다. 다만 그 ‘행동’은 “먼저 섀도 모드(shadow mode)로 돌린다”거나 “테스트한 킬 스위치 뒤에 배포한다”거나 “합성 트래픽(synthetic traffic)부터 시작한다”가 된다.
규제 환경에서는 NIST의 사고 대응 라이프사이클(준비, 탐지 & 분석, 봉쇄/근절/복구, 사후 활동)이 유용한 프레임워크를 제공한다. 핵심 통찰은 봉쇄 과정 동안에도 탐지와 분석으로 되돌아간다는 점이다—즉, 진행하면서 학습한다.
기능 플래그는 조합 폭발 수준의 상태 복잡도를 도입한다. 오너, 만료일, 제거 작업을 가진 ‘재고’로 취급하라.
기능 플래그는 되돌리기(reversibility)를 만드는 데 매우 유용하다. 하지만 비용이 있다.
각 플래그는 시스템이 가질 수 있는 상태 조합을 하나 늘린다. 플래그 2개면 4가지 상태. 3개면 8가지. 10개면 1,024가지.
그 모든 조합을 테스트할 수 없다. 아마 어떤 조합이 무엇을 하는지도 모를 것이다.
Martin Fowler의 feature toggle 가이드는 이 점을 이례적으로 직설적으로 말한다. 토글은 검증 복잡도를 도입하고, 조합적 상태 공간을 만들며, 적극적으로 관리해야 하는 재고 비용을 가진다.
그러니 플래그를 재고처럼 다뤄라. 각각에 다음을 부여하라:
플래그가 만료되면, 누군가가 연장하거나 제거할 때까지 테스트가 실패하게 만들어라.
2019년에 추가된 플래그가 절반이고 아무도 그 의미를 모르는 코드베이스를 본 적이 있다. 그렇게 되게 두지 마라.
빠르게 움직이는 팀은 무모하지 않다. 잦고 안전한 배포를 지루할 정도로 평범하게 만드는 인프라를 구축했다.
실제 사례로 성공이 어떤 모습인지 보자.
Etsy는 하루 최대 50회까지 배포하고 있었다. 그들은 모든 배포를 추적하고 메트릭과 상관관계를 분석했다. 문제가 생기면 어떤 배포가 원인이었는지 즉시 알 수 있었다. 평균 해결 시간(MTTR)은 시간이 아니라 분 단위였다.
Lowe’s는 SRE 프랙티스를 채택해 평균 복구 시간(MTTR/MTTRc)을 80% 이상 개선했다. 어떤 지표는 2시간에서 17분으로 줄었다. 그들은 모니터링, 명확한 사고 절차, 그리고 비난 없는 포스트모템(blameless postmortems)에 투자함으로써 이를 달성했다.
이 회사들이 빠르게 움직일 수 있었던 이유는, 빠르게 움직여도 안전하도록 만드는 인프라를 구축했기 때문이다.
조직을 변혁할 필요는 없다. 배포가 무섭지 않고 지루해지는 서비스를 하나 고르는 것부터 시작하라.
실용적인 30일 플랜은 이렇다:
1주차: 파일럿으로 한 서비스를 고른다. SLO와 에러 버짓을 정의한다. 규칙에 합의한다: 버짓 안이면 배포 가능. 아니면 신뢰성부터 고친다.
2주차: PR 체크리스트와 롤아웃 체크리스트를 만든다. 거창할 필요 없다—“기능 플래그를 추가했나?” “어떤 메트릭을 보고 있나?” 정도로 시작하고, 실제로 사용하라.
3주차: 가장 시끄러운 알림을 고친다. 사람을 호출(page)하는 모든 알림은 실행 가능해야 하고 사용자 영향과 연결되어야 한다. 아니면 삭제하거나 중요도를 낮춰라.
4주차: 롤백을 ‘진짜’로 만든다. 가장 무서운 배포를 하나 골라 롤백을 연습해 보라. 무엇이 깨지는지 확인하고, 그걸 고쳐라.
이게 전부다. 바다를 끓일 필요는 없다. 배포가 무섭지 않고 지루해지는 서비스 하나만 있으면 된다.
“행동 편향”은 용감함이 아니다. 도망로를 만들어 주는 ‘유용한 편집증’이다.
아무도 말해주지 않는 사실이 있다. “행동 편향”은 용감함이 아니다. 유용한 방식의 편집증(paranoia)이다.
나는 위험한 것을 배포할 때, 무엇이 잘못될 수 있는지에 대해 많은 시간을 쓴다. 배포를 포기하려고가 아니라, 도망로가 있는지 확인하려고다.
재배포 없이 끌 수 있는가? 깨졌는지 감지할 수 있는가? 문제가 생기면 몇 분 안에 알 수 있는가, 아니면 월요일 아침 화난 Slack 메시지로 알게 되는가?
목표는 두려움 없이 배포하는 게 아니다. 틀려도 치명적이지 않다는 근거 있는 확신을 가지고 배포하는 것이다.
분석 마비는 대개 근본 원인이 아니다. 진짜 살인자는 큰 변경, 불안정한 테스트, 빈약한 관측 가능성, 복잡한 롤백, 알림 노이즈다.
분석 마비는 실제로 존재한다. 하지만 내 경험상, 느림의 근본 원인인 경우는 드물다.
진짜 ‘킬러’는 이런 것들이다:
이걸 고치면 속도는 자연스럽게 따라온다. 배포가 무섭지 않게 되면 팀은 더 이상 망설이지 않는다.
특히 모니터링은 강조할 가치가 있다. Google SRE의 “4대 골든 시그널(four golden signals)”—지연 시간, 트래픽, 에러, 포화(saturation)—은 반드시 관측해야 하는 것들의 간결한 스키마를 제공한다. 그리고 알림 노이즈에 대해서도 단호하다. 사람을 호출하는 것은 비싸고, 노이즈는 알림을 무시하게 만들며 장애 시간을 늘린다.
에러 버짓은 신뢰성 목표를 명시적이고 공유된 것으로 만들어, 철학적 논쟁을 객관적 측정으로 바꾼다.
에러 버짓이 이걸 구체화하는 데 얼마나 유용한지 다시 강조하고 싶다.
에러 버짓이 없으면, 속도 vs 품질에 대한 끝없는 철학적 논쟁이 벌어진다. 제품팀은 더 빨리 움직이고 싶고, 엔지니어링팀은 안정성 작업 시간이 더 필요하다. 공유된 프레임워크가 없다.
에러 버짓이 있으면 대화가 바뀐다:
제품: “다음 주에 이 기능 출시할 수 있어요?”
엔지니어링: “에러 버짓을 볼게요… 이번 달 버짓의 85% 수준이네요. 네, 출시할 수 있어요.”
또는:
엔지니어링: “이번 달 에러 버짓을 110% 태웠어요. 기능을 동결하고 신뢰성 이슈를 고쳐야 해요.”
제품: “알겠어요. 버짓 안으로 돌아오기 위한 계획은 뭐죠?”
개인 감정의 문제가 아니다. 평가도 아니다. 그저 신뢰성 목표 안에 있는가, 예/아니오다.
문화 변화는 한 팀의 성공이 가시화될 때 일어난다. 파일럿으로 시작해 잘하게 만든 뒤, 유기적으로 퍼지게 하라.
조직 전체를 바꿀 필요는 없다. 한 팀, 한 서비스, 한 프로젝트에서 시작하라.
작은 변경을 안전하게 자주 배포하는 데 아주 능숙해져라. 근육 기억을 만들어라. 그런 다음 확장하라.
내가 본 성공 사례들은 “지속적 배포로 전환합니다”나 “SRE 프랙티스를 채택합니다” 같은 큰 공지를 하지 않았다. 그저 더 자주 배포하고, 메트릭을 더 주의 깊게 보고, 롤백을 더 쉽게 만들었다.
몇 달 뒤 누군가가 알아차린다: “저 팀은 다른 팀보다 훨씬 더 많이 배포하는데, 더 많이 깨뜨리지도 않네. 어떻게 하는 거지?”
그때 퍼진다.
가장 빠른 팀은 테스트와 배포를 настолько 일상화해서 아무도 의식하지 않는다. 그게 진짜 행동 편향이다.
다른 글에서도 이렇게 시작했지만, 반복할 가치가 있다: 당신의 일은 코드를 배포하는 것이 아니다. 작동하는 코드를 배포하는 것이다.
“행동 편향”은 테스트되지 않은 변경을 동료들에게 떠넘길 수 있는 면허가 아니다. 실험 비용을 낮춰 더 빠르게 학습하기 위한 규율이다.
가장 빠른 팀은 테스트를 건너뛰는 팀이 아니다. 테스트가 너무 빠르고 자동화되어 있어서 속도를 늦추지 않는 팀이다.
배포가 настолько 일상적이라 아무도 신경 쓰지 않는 팀이다.
롤백이 настолько 신뢰할 수 있어서 시도하는 것을 두려워하지 않는 팀이다.
그게 진짜 행동 편향이다.
실제로 더 빨라지고 있는지 측정하고 싶다면, DORA 메트릭(배포 빈도, 변경 리드 타임, 변경 실패율, 실패한 배포의 복구 시간)이 좋은 출발점이다.
Addy Osmani은(는) Google에서 Google Cloud와 Gemini를 다루는 소프트웨어 엔지니어다.TweetBlueskyMastodonThreadsLinkedInShare
더 많은 글이 필요하신가요? 무료 뉴스레터를 구독하세요:
