행동 편향

"행동 편향"이라는 말은 스타트업 창업자가 무모한 일을 저지르기 직전에 외치는 구호처럼 들린다. 하지만 실제로는 그렇지 않다. 제대로 실천한다면, 이는 오히려 잘못되더라도 치명적이지 않도록 안전장치를 갖추면서 더 빠르게 배우는 방식이다.

핵심은 이것이다: 실질적인 피드백을 얻을 수 있는 가장 작은 한 걸음을 내딛되, 무언가 잘못됐을 때 어떻게 복구할지를 미리 명확히 알아두는 것.

그게 전부다. 나머지는 이를 가능하게 만드는 엔지니어링 규율의 문제다.

Stripe는 이를 잘 표현하고 있다 — "긴박함과 집중력을 갖추고 움직여라"라는 운영 원칙에서, 이는 무모함이 아니라 학습 속도를 최적화하면서 동시에 내일의 속도를 높여줄 토대에 투자하는 것임을 강조한다.

"빠르게 움직인다"는 것의 진짜 의미

빠른 팀은 느린 팀보다 더 적은 정보가 아니라 더 많은 정보를 활용한다 — 다만 완벽한 정보가 갖춰질 때까지 기다리지 않을 뿐이다.

실제로 빠르게 출시하는 팀을 관찰하면 흥미로운 공통점이 있다. 그들은 생각을 건너뛰지 않는다. 무모한 카우보이도 아니다. 단지 피드백 루프가 촘촘할 뿐이다.

연구 결과도 이를 뒷받침한다. Kathleen Eisenhardt의 고속 의사결정 연구는 고속 환경에서 반직관적인 사실을 발견했다. 빠른 의사결정자들은 느린 팀보다 더 많은 정보를 활용했다. 더 많은 대안을 검토하고, 더 나은 조언 과정을 거쳤다. 완벽한 정보를 기다리지 않았을 뿐이다. 원하는 정보의 약 70% 수준에서 결정을 내리고, 작은 무언가를 출시한 뒤, 그 결과에서 배웠다.

빠른 팀과 느린 팀의 차이는 용기가 아니다. 인프라다.

속도는 위험한 일을 용감하게 감행하는 데서 나오는 게 아니라, 안전한 방식을 쉽게 만드는 데서 나온다.

빠른 팀이 갖추고 있는 것:

즉시 비활성화할 수 있는 피처 플래그
문제 발생 시 실제로 알려주는 모니터링
평소에 연습해둔 롤백 절차
문제가 생겨도 원인 파악이 쉬운 작은 단위의 변경

느린 팀은 매번 배포가 부담스럽다. 실제로 위험하기 때문이다 — 안전망이 없으니까.

양방향 문 vs. 단방향 문

대부분의 결정은 설계하기에 따라 되돌릴 수 있다 — 가장 큰 레버리지를 발휘하는 행동은, 단방향 문을 양방향 문으로 바꾸는 것인 경우가 많다.

Jeff Bezos는 2015년 주주 서한에서 이 프레임워크를 설명했다. 어떤 결정은 한번 통과하면 되돌아올 수 없는 문과 같아서 신중한 검토가 필요하다. 하지만 대부분의 결정은 양방향 문이다. 한번 시도해보고 마음에 들지 않으면 그냥 되돌아오면 된다.

문제는 우리가 너무 많은 결정을 단방향 문처럼 다룬다는 것이다.

신중하게 검토하느라 속도를 늦추기 전에, 먼저 자문해보자: 이것을 되돌릴 수 있게 만들 수 있을까?

때로는 "피처 플래그를 추가한다"가 답이다. 때로는 "트래픽의 1%부터 시작한다"일 수도 있다. 또는 "두 시스템 모두에 동시 쓰기를 해서 언제든 전환 가능하게 한다"일 수도 있다.

되돌릴 수 있게 만드는 것이 가장 높은 레버리지를 발휘하는 행동인 경우가 많다. 두려운 단방향 문을 안전한 양방향 문으로 바꿔주기 때문이다.

에러 예산: 속도 논쟁 없이 속도 문제를 해결하는 법

에러 예산은 속도 대 안정성에 관한 철학적 논쟁을 객관적인 기준으로 대체한다 — 변경에 쓸 예산이 있으면 진행하고, 없으면 멈추는 것이다.

Google의 SRE 에러 예산 정책에서 가져온 구체적인 예시를 소개한다. 정말 유용하게 쓰이는 개념인데, 바로 "에러 예산"이다.

서비스에는 SLO가 있다 — 예를 들어 99.9% 업타임이라고 하자. 그러면 나머지 0.1%가 에러 예산이다. 허용되는 장애의 한도다.

규칙은 단순하다:

예산 내에 있으면 계속 출시한다
예산을 초과했으면 출시를 멈추고 안정성을 먼저 고친다

이러면 대화가 완전히 달라진다. 제품팀과 엔지니어링팀이 속도를 늦춰야 하느냐 마느냐로 싸울 필요 없이, 숫자를 보면 된다. 예산 안에 있는가? 그러면 출시한다. 예산을 다 썼는가? 그러면 먼저 고쳐야 한다.

장애의 약 70%는 변경에서 비롯된다. 그래서 변경을 더 안전하게 만드는 메커니즘이 필요하다.

가장 작은 책임 있는 한 걸음

점진적으로 비율을 높여가며 프로덕션에 여러 차례 배포하는 방식은 한 번에 전체를 배포하는 것보다 훨씬 안전하다 — 잘못됐을 때의 피해 반경이 작게 유지되기 때문이다.

"행동 편향"이 실제로 어떤 모습인지 구체적인 예를 들어보자. 기존 사용자가 많지 않은 고속 스타트업이라면 훨씬 단순하게 적용할 수 있다: 출시하고, 모니터링하고, 문제가 생기면 롤백하면 된다.

그렇지 않은 경우라면, 요청 경로에 레이턴시에 영향을 줄 수 있는 변경을 가한다고 가정해보자. "행동 편향" 방식으로 접근하면 이렇게 된다:

1단계: 시작 전에 "망가졌다"의 기준을 정한다. SLI를 정하자 — 에러율과 p99 레이턴시를 기준으로 삼는다면, 어느 임계값에서 중단할지 미리 합의해둔다.

2단계: 변경 사항을 피처 플래그 뒤에 넣는다. 재배포 없이도 언제든 끌 수 있다.

3단계: 플래그를 끈 상태로 프로덕션에 배포한다. 코드는 올라가 있지만 아직 실행되지 않는다.

4단계: 트래픽의 1%에만 플래그를 켠다. 지표를 살핀다.

5단계: 지표가 양호하면 5%, 25%, 50%, 100% 순으로 점진적으로 확대한다. 어느 단계에서든 이상 징후가 보이면 플래그를 즉시 끈다.

6단계: 전체 롤아웃이 완료되고 안정적으로 운영되면 플래그를 제거한다.

여기서 일어나는 일을 보라. 프로덕션에 여러 차례 배포하지만, 잘못됐을 때의 피해 반경은 극히 작다. 트래픽 1% 단계에서 문제가 생겨도 영향받는 사용자는 1%뿐이고, 그것도 몇 분 안에 해결된다.

이 접근법은 Google의 SRE 카나리 배포 가이드에서 직접 가져온 것이다 — 테스트로는 모든 결함을 잡을 수 없기에, 프로덕션 트래픽의 일부를 카나리에 노출시키고 컨트롤과 비교 평가한다.

이를 "신중한" 방식과 비교해보자: 스테이징에서 세 주 동안 테스트한 뒤 프로덕션 전체에 한꺼번에 배포한다. 뭔가 깨지면 모든 사용자가 영향을 받고, 롤백 자체가 또 하나의 대형 작업이 된다.

어느 쪽이 실제로 더 안전한가?

Google의 릴리즈 엔지니어링 사례는 이 점을 명확히 한다: 고속 배포는 버전 간 변경 사항을 줄여 자주 릴리즈하는 방식에서 나온다. 테스트와 문제 해결이 쉬워지기 때문이다. 일부 팀은 "그린에서 바로 푸시"한다 — 모든 테스트를 통과한 빌드는 즉시 배포한다.

카나리가 거짓말을 할 때

카나리는 인프라 지표가 아닌 사용자가 실제로 체감하는 것을 측정해야 한다.

카나리 배포는 훌륭한 방법이지만, 올바른 것을 관찰해야 한다.

사용자가 실제로 겪는 경험과 몇 단계 떨어진 기술적 지표만 들여다보는 카나리를 운영하는 팀을 본 적이 있다. 카나리는 통과했지만 전체 롤아웃 후 에러율이 치솟았다. 특정 조건에서만 드러나는 미묘한 버그가 있었던 것이다.

카나리는 사용자가 실제로 중요하게 여기는 것을 측정해야 한다.

Google의 SRE 가이드는 이 점을 명시한다: CPU 같은 지표는 노이즈가 많고 서비스 영향과 직결되지 않을 수 있다. 카나리는 사용자 경험을 대변하는 SLI에 연결되어야 한다.

한 가지 더 짚어둘 점이 있다. 카나리는 장애 유형이 드러날 만큼 충분히 오래 실행되어야 한다. 어떤 버그는 캐시가 워밍업된 후, 특정 트래픽 패턴이 나타난 후, 또는 메모리 압박이 쌓인 후에야 발생한다.

가능하면 카나리는 한 번에 하나만 실행하라. 여러 카나리가 동시에 돌아가면 어느 것이 문제를 일으켰는지 파악하기가 매우 어려워진다.

Knight Capital 사태

위험도가 높은 시스템에서 "행동 편향"이란 최악의 결과를 제한하는 통제 수단과 안전망에 투자하는 것을 의미한다 — 이를 건너뛰는 게 아니라.

가드레일 없이 "빠르게 움직인다"는 것이 어떤 결과를 낳는지 보여주는 사례가 있다.

2012년, Knight Capital은 트레이딩 소프트웨어를 배포했다. 배포 과정에서 실수가 있었고 — 일부 서버에 이전 코드가 그대로 남아 실행됐다. 45분 만에 시스템은 수백만 건의 잘못된 주문을 전송했다. 회사는 4억 6천만 달러 이상을 잃었고 사실상 파산 직전까지 몰렸다.

SEC의 명령서와 보도자료는 가혹하다. 적절한 배포 절차가 없었다. 킬 스위치가 없었다. 피해를 막았을 사전 거래 한도도 없었다. SEC는 "각 구성 요소가 오작동할 경우 어떤 일이 발생하는지, 그리고 피해를 제한하는 안전망은 무엇인지"를 항상 자문해야 한다고 명시적으로 강조했다.

이것이 바로 "행동 편향"에서 "가장 작고 책임 있는 한 걸음" 부분을 빠뜨렸을 때 벌어지는 일이다. 빠르게 움직이긴 했다. 벽을 향해 빠르게.

교훈은 "느리게 움직여라"가 아니다. "잘못되더라도 죽지 않고 빠르게 움직일 수 있게 해주는 안전망에 투자하라"는 것이다.

위험도가 높은 시스템 — 결제, 트레이딩, 인증 — 에서도 여전히 행동 편향을 적용한다. 다만 그 행동이 "먼저 섀도 모드로 실행한다", "테스트를 마친 킬 스위치 뒤에 배포한다", "합성 트래픽부터 시작한다"의 형태를 띨 뿐이다.

규제 환경이라면 NIST의 사고 대응 생애주기가 유용한 프레임워크를 제공한다: 준비, 탐지 및 분석, 격리·제거·복구, 사후 활동. 핵심은 격리 과정에서 다시 탐지와 분석 단계를 순환한다는 것이다 — 진행하면서 계속 배운다.

피처 플래그는 재고다

피처 플래그는 조합 폭발적인 상태 복잡성을 만들어낸다 — 소유자, 만료일, 제거 작업을 붙여 재고처럼 관리해야 한다.

피처 플래그는 되돌릴 수 있게 만드는 데 매우 유용하다. 하지만 비용이 따른다.

플래그 하나하나가 시스템이 처할 수 있는 상태 조합을 늘린다. 플래그 두 개면 네 가지 상태, 세 개면 여덟 가지, 열 개면 1,024가지다.

그 모든 조합을 테스트할 수 없다. 각 조합이 어떤 동작을 하는지조차 파악하지 못할 수도 있다.

Martin Fowler의 피처 토글 가이드는 이 점을 직설적으로 지적한다: 토글은 검증 복잡성을 높이고, 조합론적 상태 공간을 만들며, 능동적으로 관리해야 할 재고 비용을 발생시킨다.

그러니 플래그를 재고처럼 다뤄라. 각 플래그에 다음을 붙여라:

담당자
만료일
명확한 목적 (릴리즈 플래그? 실험? 운영 토글?)
제거 작업 티켓

플래그가 만료되면, 누군가 기한을 연장하거나 제거하기 전까지 테스트가 실패해야 한다.

플래그의 절반이 2019년 것인데 아무도 그게 무슨 역할인지 모르는 코드베이스를 본 적이 있다. 그런 상황을 만들지 말자.

잘하는 팀의 모습

빠르게 움직이는 팀은 무모한 게 아니다 — 잦고 안전한 배포를 일상으로 만드는 인프라를 구축한 것이다.

실제 사례로 성공의 모습을 보여주겠다.

Etsy는 하루 최대 50회 배포를 했다. 모든 배포를 추적하고 지표와 연관지었다. 문제가 생기면 어느 배포가 원인인지 즉시 파악할 수 있었다. 평균 해결 시간은 시간 단위가 아닌 분 단위였다.

Lowe's는 SRE 사례를 도입해 평균 복구 시간을 80% 이상 단축했다. 한 지표는 2시간에서 17분으로 줄었다. 모니터링, 명확한 사고 대응 절차, 비난 없는 사후 회고(blameless postmortem)에 투자한 결과였다.

이 회사들은 빠르게 움직일 수 있는 인프라를 갖췄기 때문에 빠르게 움직일 수 있었다.

실제로 어떻게 시작할까

조직 전체를 바꾸려 하지 않아도 된다 — 배포가 두렵지 않고 일상이 되는 서비스 하나부터 시작하면 된다.

30일 실행 계획을 소개한다:

1주차: 파일럿 서비스 하나를 고른다. SLO와 에러 예산을 정의한다. 규칙에 합의한다: 예산 안에 있으면 출시할 수 있고, 초과했으면 안정성부터 고친다.

2주차: PR 체크리스트와 롤아웃 체크리스트를 만든다. 거창할 필요 없다 — "피처 플래그를 추가했나?", "어떤 지표를 지켜볼 건가?" 정도면 충분하다. 바로 사용하기 시작한다.

3주차: 가장 시끄러운 알림부터 고친다. 누군가를 호출하는 모든 알림은 실행 가능하고 사용자 영향과 연결되어야 한다. 그렇지 않다면 삭제하거나 등급을 낮춘다.

4주차: 롤백을 실전처럼 만든다. 가장 두려운 배포를 골라 실제로 롤백을 연습해본다. 어디서 문제가 생기는지 찾아내고 고친다.

그게 전부다. 모든 걸 한꺼번에 바꾸려 할 필요 없다. 배포가 두렵지 않고 일상이 되는 서비스 하나면 충분하다.

사람의 문제

"행동 편향"은 용감해지는 것이 아니라, 탈출구를 만드는 방식으로 유익하게 집착하는 것이다.

아무도 말해주지 않는 사실이 있다: "행동 편향"은 용기의 문제가 아니다. 유익한 방식으로 걱정하는 것이다.

위험한 것을 출시할 때 나는 무엇이 잘못될 수 있는지 많은 시간을 들여 생각한다. 출시를 포기하려는 게 아니라, 탈출구를 미리 확보해두기 위해서다.

재배포 없이 끌 수 있는가? 망가졌을 때 탐지할 수 있는가? 문제가 생기면 몇 분 안에 알 수 있는가, 아니면 월요일 아침 화가 난 슬랙 메시지로 뒤늦게 알게 되는가?

목표는 두려움 없이 출시하는 것이 아니다. 잘못되더라도 치명적이지 않다는 근거 있는 확신을 가지고 출시하는 것이다.

팀을 실제로 느리게 만드는 것들

분석 마비는 좀처럼 진짜 원인이 아니다 — 진짜 주범은 큰 변경 단위, 불안정한 테스트, 낮은 관찰 가능성, 복잡한 롤백, 알림 노이즈다.

분석 마비는 실재한다. 하지만 내 경험상 그게 속도 저하의 근본 원인인 경우는 드물다.

진짜 주범은 이것들이다:

큰 변경 단위 — 리뷰하기 어렵고, 테스트하기 어려우며, 문제가 생겼을 때 디버깅하기 어렵다
불안정한 테스트 — 게이트를 믿을 수 없으니 출시가 두려워진다
낮은 관찰 가능성(observability) — 뭔가 망가졌는지 파악하기 어렵다
복잡한 롤백 절차 — 되돌리는 것이 그냥 버티는 것보다 더 무섭다
알림 노이즈 — 알림을 무시하는 습관을 만들어낸다

이것들을 고치면 속도는 자연스럽게 따라온다. 출시가 더 이상 무섭지 않으니 팀이 망설이지 않게 된다.

모니터링은 따로 언급할 가치가 있다. Google SRE의 "네 가지 황금 신호(four golden signals)" — 레이턴시, 트래픽, 에러, 포화도 — 는 반드시 관찰해야 할 것들을 간결하게 정리한 체계다. 알림 노이즈에 대해서도 단호하다: 사람을 호출하는 것은 비용이 크고, 노이즈는 알림을 무시하게 만들어 장애를 길어지게 한다.

에러 예산 대화

에러 예산은 안정성 목표를 명확하고 공유된 기준으로 만든다 — 철학적 논쟁을 객관적인 측정값으로 바꿔준다.

에러 예산 이야기로 다시 돌아오고 싶다. 이 개념을 구체화하는 데 정말 유용한 도구이기 때문이다.

에러 예산이 없으면 속도 대 품질을 둘러싼 끝없는 철학 논쟁이 펼쳐진다. 제품팀은 더 빠르게 움직이고 싶어 하고, 엔지니어링팀은 안정성 작업에 더 많은 시간을 원한다. 공유된 기준이 없다.

에러 예산이 있으면 대화가 이렇게 바뀐다:

제품팀: "다음 주에 이 기능 출시할 수 있을까요?"

엔지니어링팀: "에러 예산 확인해볼게요… 이번 달 예산의 85%를 쓴 상태예요. 네, 출시할 수 있어요."

또는:

엔지니어링팀: "이번 달 에러 예산을 110% 소진했어요. 기능 추가를 동결하고 안정성 문제를 먼저 해결해야 합니다."

제품팀: "알겠어요, 예산을 회복할 계획이 뭔가요?"

감정이 개입되지 않는다. 판단도 없다. 그저 안정성 목표 안에 있는지 없는지의 문제다.

작게 시작하기

문화적 변화는 한 팀의 성공이 가시화될 때 일어난다 — 파일럿으로 시작해 능숙해진 뒤, 자연스럽게 퍼지게 두어라.

조직 전체를 바꿀 필요 없다. 팀 하나, 서비스 하나, 프로젝트 하나에서 시작하라.

작은 변경을 안전하게 출시하는 데 능숙해져라. 근육 기억을 만들어라. 그다음 확장하라.

이 방식으로 성공한 팀들을 보면, "지속적 배포 전환"이나 "SRE 사례 도입"을 거창하게 선언하지 않는다. 그냥 더 자주 출시하고, 지표를 더 꼼꼼히 살피고, 롤백을 더 쉽게 만들기 시작한다.

몇 달이 지나면 누군가 알아챈다. "저 팀, 다른 팀들보다 훨씬 많이 출시하는데 장애는 더 많지도 않네. 어떻게 하는 거지?"

그때부터 퍼진다.

여전히 당신의 일은 작동하는 코드를 만드는 것이다

가장 빠르게 움직이는 팀은 테스트와 배포를 너무 당연한 일상으로 만들어서 아무도 거기에 신경 쓰지 않는다 — 그게 진짜 행동 편향이다.

다른 글에서도 언급했지만 반복할 가치가 있다: 당신의 일은 코드를 출시하는 게 아니다. 작동하는 코드를 출시하는 것이다.

"행동 편향"은 테스트도 거치지 않은 변경을 동료에게 던져도 된다는 허가증이 아니다. 실험의 비용을 낮춰 더 빠르게 배우는 규율이다.

가장 빠르게 움직이는 팀은 테스트를 건너뛰는 팀이 아니다. 테스트를 너무 빠르고 자동화해서 속도를 전혀 늦추지 않는 팀이다.

배포가 너무 일상적이어서 아무도 특별히 신경 쓰지 않는 팀이다.

롤백이 너무 믿음직해서 새로운 것을 시도하는 게 두렵지 않은 팀이다.

그게 진짜 행동 편향이다.

실제로 빨라지고 있는지 측정하고 싶다면, DORA 지표(배포 빈도, 변경 리드 타임, 변경 실패율, 실패한 배포 복구 시간)가 좋은 출발점이다.