되돌릴 수 있는 결정
Two-way Door
개념
틀렸을 때 쉽게 되돌릴 수 있는 결정과 그렇지 않은 결정을 나눠, 앞쪽은 빠르게 정하고 뒤쪽에 시간을 쓰는 판단 기준입니다.
등장 배경
결정을 신중하게 내리는 것은 좋은 태도로 여겨집니다. 문제는 그 신중함이 모든 결정에 같은 무게로 적용될 때 생깁니다.
민서가 문서 목록의 기본 정렬을 이름순에서 최근 수정순으로 바꾸자고 제안했을 때가 그랬습니다. 근거가 있었고 반대도 없었는데 결정이 나기까지 3주가 걸렸습니다. 회의 두 번, 의견 수집, 승인 절차를 거쳤습니다. 그런데 이 설정을 되돌리는 데 걸리는 시간은 10분이었습니다.
같은 팀에서 데이터베이스를 고르는 결정은 반대로 흘렀습니다. 급하다는 이유로 이틀 만에 정했고, 1년 뒤에 옮기려고 보니 이전 작업만 두 달이었습니다. 3주를 쓸 자리와 이틀을 쓸 자리가 정확히 뒤바뀐 셈입니다.
여기서 나온 기준이 문에 비유됩니다. 지나간 뒤에 돌아 나올 수 있는 문이 있고, 한 번 지나면 닫히는 문이 있습니다. 결정의 중요도가 아니라 되돌리는 비용으로 나누는 것이 이 기준의 핵심이고, 판단해야 하는 것은 그 결정이 어느 쪽 문인지입니다.
작동 방식
되돌리기 비용을 먼저 재고, 그 값에 따라 다른 절차를 붙입니다.
비용을 재는 질문은 셋입니다.
- 원래대로 돌리는 데 얼마나 걸립니까. 설정 하나를 바꾸는 일이면 10분이고, 데이터 구조를 옮기는 일이면 두 달입니다.
- 밖으로 나갔습니까. 고객에게 공지한 가격, 계약서에 적은 조항, 외부에 공개한 API는 우리끼리 되돌릴 수 없습니다.
- 무엇이 쌓입니까. 데이터가 쌓이는 결정은 시간이 갈수록 되돌리기가 비싸집니다. 오늘 바꾸면 하루면 되는 일이 반년 뒤에는 두 주가 됩니다.
세 답으로 결정을 두 갈래로 나눕니다.
되돌릴 수 있는 쪽에는 가벼운 절차를 붙입니다. 가장 가까운 사람이 그 자리에서 정하고, 무엇을 왜 정했는지 한 줄만 남깁니다. 회의를 열지 않고 승인을 받지 않습니다. 기록을 남기는 이유는 승인이 아니라, 나중에 되돌릴 때 무엇을 되돌리는지 알아야 하기 때문입니다.
되돌릴 수 없는 쪽에는 무거운 절차를 붙입니다. 대안을 셋 이상 적고, 각 대안의 위험을 쓰고, 관련된 사람들이 읽고, 명시적으로 승인합니다. 아키텍처 의사결정 기록처럼 배경과 대안을 남기는 문서를 쓰는 것이 이 자리입니다.
한 가지 더 있습니다. 결정을 한쪽 문에서 양쪽 문으로 옮기는 장치를 쓰는 것입니다. 피처 플래그로 기능을 켜고 끌 수 있게 만들어 두면, 새 화면을 내보내는 결정이 되돌릴 수 있는 쪽으로 넘어옵니다. 피처 플래그는 코드를 배포한 채 기능만 켜고 끄는 스위치입니다. 카나리 릴리스로 소수에게 먼저 내보내는 것도 같은 성질입니다. 문의 종류가 고정된 것이 아니라, 준비에 따라 바꿀 수 있습니다.
쓰이는 곳
되돌릴 수 있는 쪽에 들어가는 것이 실제로는 대부분입니다.
- 화면 문안과 배치 — 바꿔 보고 반응이 나쁘면 되돌립니다.
- 기본값 — 정렬 순서, 알림 켜짐 여부처럼 설정으로 되돌릴 수 있는 값입니다.
- 내부 도구 선택 — 팀이 쓰는 문서 도구나 일정 관리 도구는 옮기는 비용이 크지 않습니다.
- 실험 — A/B 테스트는 애초에 되돌리는 것을 전제로 돌립니다. 두 안을 무작위로 나눠 보여 주고 결과를 비교하는 실험입니다.
되돌릴 수 없는 쪽은 수가 적지만 무겁습니다. 외부에 공개한 API의 모양, 데이터 스키마, 가격 책정의 인상 결정, 브랜드 이름, 채용과 해고가 여기 들어갑니다. 가격은 내릴 때와 올릴 때가 다릅니다. 올렸다가 되돌리면 숫자는 제자리로 오지만 고객이 기억한 것은 되돌아오지 않습니다.
애매한 자리도 있습니다. 기술 선택이 대표적입니다. 프로젝트 첫 주에 고르는 프레임워크는 코드가 얼마 없으니 양쪽 문에 가깝지만, 1년을 쓴 뒤에는 한쪽 문이 됩니다. 같은 결정이 시간이 지나면서 성질이 바뀌므로, 지금 어느 쪽인지를 그때그때 다시 봅니다.
팀에서 쓰려면 목록을 적어 두는 편이 낫습니다. 어떤 종류의 결정이 어느 쪽인지를 미리 정해 두면, 매번 "이건 회의를 열어야 하나" 를 논의하지 않게 됩니다. 목록에 없는 종류가 나오면 그때 한 번 정하고 목록에 더합니다.
실무 용례
"이건 되돌릴 수 있는 결정이니까 오늘 정하고 넘어가죠."
절차를 붙이는 값이 결정 자체보다 크다는 판단입니다.
"스키마 변경은 한쪽 문이에요. 문서 쓰고 리뷰 받읍시다."
되돌리기 비용이 커서 무거운 절차를 붙이자는 말입니다.
"플래그로 감싸면 되돌릴 수 있는 쪽이 되니까 일단 내보내죠."
장치를 써서 결정의 성질을 바꾸자는 제안입니다.
페이지덱은 결정 유형 목록을 한 장으로 만들어 두고 있습니다. 규원이 처음 제안했을 때는 반대가 있었습니다. 되돌릴 수 있는 쪽을 혼자 정하게 하면 방향이 갈라진다는 우려였습니다.
그래서 조건을 하나 붙였습니다. 혼자 정해도 되지만 정한 것을 팀 채널에 한 줄로 남기는 것입니다. 승인을 받는 절차가 아니라 알리는 절차입니다. 지현이 이 기록을 매주 훑어 방향이 어긋난 것이 있으면 그때 되돌립니다. 되돌리는 비용이 작은 결정이니 나중에 되돌려도 늦지 않다는 것이 이 방식의 전제입니다.
흔한 오해
되돌릴 수 있으면 아무렇게나 정해도 된다고 읽는 경우가 가장 많습니다. 틀려도 되돌리면 된다니 판단의 질이 덜 중요해 보입니다. 하지만 되돌리려면 무엇을 바꿨는지 알아야 하고, 기록이 없으면 되돌릴 수 있다는 성질 자체가 사라집니다. 반년 동안 서른 개의 작은 결정을 아무 기록 없이 내린 팀은 지금 화면이 왜 이런지 아무도 설명하지 못하게 됩니다. 빨라지는 것은 절차이고 기록은 줄이지 않습니다.
빠르게 정한 결정은 덜 생각한 결정이라고 보는 것도 흔합니다. 시간을 많이 들인 쪽이 더 나은 판단일 것 같습니다. 하지만 3주를 들인다고 10분이면 되돌릴 수 있는 결정의 정확도가 올라가지는 않습니다. 대개 늘어나는 것은 같은 논의의 반복이고, 그동안 다른 결정들이 줄을 서 있습니다. 시간을 아끼려는 것이 아니라, 아낀 시간을 되돌릴 수 없는 결정 쪽으로 옮기려는 것입니다.
같이 보면 좋은 페이지
마지막 업데이트 2026-09-16