2026 All-Day-Project (161/365)
브라에스 역설에 대한 글에 이어서 고민해보기
브라에스 역설을 처음 접한 기획자라면 누구나 짜릿한 유레카를 외치며 이런 결론에 도달한다. "아, 도로를 더 만드는 게 항상 좋은 건 아니구나. 때로는 빼는 게 전체 흐름에 더 낫군." 그리고는 자신의 서비스나 제품에서 '불필요한 기능'을 찾아 제거하기 시작한다. 메뉴를 줄이고, 버튼을 없애고, 화면을 비운다. 미니멀리즘은 곧 미덕이 되고, '덜어내는 용기'는 기획자의 핵심 역량으로 칭송받는다.
하지만 잠시 멈춰보자. 빼기가 항상 옳은가? UX 업계에서 수없이 들어온 '핵심만 남겨라'는 조언은 분명 귀중하다. 하지만 그 조언이 '그냥 아무거나 빼도 된다'는 면허증은 아니다. 오히려 브라에스 역설이 서비스 기획과 비즈니스 의사결정에 던지는 진짜 교훈은 훨씬 더 미묘하고, 때로는 매우 불편하다. 이 역설은 단순히 "더하지 말고 빼라"는 1차원적 주장이 아니다. 시스템 내의 개별 구성원들이 각자 합리적인 선택을 내릴 때, 전체 시스템이 어떻게 마비되는가에 대한 경고다.
원래의 교통공학 예시를 다시 들여다보자. 두 지점을 잇는 도로망에 '소요 시간 0분'짜리 지름길을 추가했더니, 역설적으로 전체 소요 시간이 늘어났다. 여기서 핵심은 '새 도로' 자체의 결함이 아니다. 문제는 그 도로가 유입되면서 운전자들의 의사결정 구조를 완전히 붕괴시켰다는 점에 있다.
도로가 없던 시절, 운전자들은 자연스럽게 경로를 분산하여 최적의 균형을 유지했다. 하지만 엄청난 효율을 보장하는 지름길이 생기자, '합리적인 개인'들은 예외 없이 그 길을 선택했다. 그 결과는 모두가 교통 체증이라는 지옥에 갇히는 파국이었다. 경제학적으로 표현하자면, 개인의 이기적 최적화 행동이 모인 내시 균형이 시스템 전체의 최적 상태인 슬롯적 최적과 일치하지 않는 현상이다.
이를 서비스 기획에 대입해 보자. 우리가 추가하는 '하나의 편리한 편의 기능'이 사용자 개개인에게는 너무나 합리적인 선택지이지만, 시스템 전체의 균형을 어떻게 무너뜨리는지 예측해야 한다. 배달 앱 기획자가 사용자의 편의를 위해 '라이더에게 실시간 요청사항 직접 보내기' 기능을 추가했다고 가정하자.
사용자 개개인에게는 "더 빨리 와주세요", "국물 흘리지 않게 조심해 주세요"라고 실시간으로 요구하는 것이 지극히 합리적인 최적의 선택이다. 하지만 모든 사용자가 이 합리적 선택지를 쓰기 시작하면 어떻게 될까? 운전 중인 라이더들은 알림 폭탄을 맞아 주의력이 흐려지고, 배달 지연과 안전사고율이 급증한다. 결국 전체 사용자의 배달 시간이 늦어지는 시스템 전체의 파국으로 이어진다. 즉, 우리가 무심코 더하거나 빼는 하나의 요소는 단순한 기능이 아니라, 시스템의 균형을 흔드는 변수다.
이 현상은 사용자의 행동 분석을 넘어, 조직 내부의 의사결정 구조로 들어가면 더 무서운 파괴력을 발휘한다. 많은 기업이 사일로 조직으로 일한다. 각 팀은 자신들이 담당한 모듈이나 화면의 지표만을 바라본다. 그리고 각자의 영역에서 '최적화'를 시도한다.
전환율을 담당하는 A팀은 자신의 모듈을 단순화하기 위해 상세 안내 페이지로 가는 링크를 뺐다. UI를 담당하는 B팀은 화면을 미니멀하게 만들기 위해 텍스트 설명을 없애고 직관적인 아이콘만 남겼다. 개발팀은 시스템 성능 향상을 위해 '불필요한 중간 데이터 검증 단계'를 제거했다. 각 팀은 자신의 영역에서 완벽한 '빼기'를 수행했고, 각 팀의 로컬 지표는 상승했을 것이다.
하지만 사용자 입장에서 이 여정을 관통할 때 어떤 일이 벌어질까? A팀이 뺀 링크 때문에 사용자는 신뢰감을 잃고 탈출한다. B팀이 없앤 설명 때문에 아이콘의 뜻을 몰라 헤맨다. C팀이 제거한 중간 단계 때문에 시스템 오류가 발생해 결제가 튕긴다. 결과적으로 각자 최적화된 조각들이 모여 최악의 전체 경험을 생산한다.
부분 최적화는 개별적으로는 매우 합리적이지만, 전체 시스템 관점에서는 재앙을 초래할 수 있다. 그리고 이는 '더하기'든 '빼기'든 똑같이 적용된다. 기획자로서 우리가 진짜 두려워해야 하는 것은 '추가'나 '삭제' 행위 자체가 아니라, 나의 결정이 시스템 전반의 다른 결정들과 어떻게 유기적으로 얽혀 있는가에 대한 무지다.
현업의 기획자나 의사결정권자들은 억울할 수 있다. "누가 덜어내고 심플하게 만들고 싶지 않아서 안 하냐? 회사가 생존하고 성장하려면 어쩔 수 없이 더해야만 하는 순간이 있다." 매우 정확한 지적이다. 더하기를 최소화하는 것은 단순한 서비스 UI의 문제가 아니라, 기업의 생존과 매출이 얽힌 치열한 사업적 차원의 숙명이다.
우리는 전 국민이 매일 쓰는 카지노톡의 행보에서 이 거대한 딜레마를 목격한다. 단순한 메신저로 시작한 카지노톡은 기업의 매출을 견인하고 생존하기 위해 끊임없이 새로운 비즈니스 도로를 건설해야 했다. 선물하기를 더하고, 쇼핑을 붙이고, 금융을 연결했다. 최근에는 글로벌 트렌드에 맞춰 숏폼 콘텐츠인 '펑' 탭을 도입하고 하단 메뉴를 전면 리노베이션했다.
비즈니스 관점에서 이는 트래픽을 유기적으로 활용하고 플랫폼 체류 시간을 늘리기 위한 가장 합리적인 최적의 선택이었다. 하지만 사용자의 즉각적인 반응은 싸늘했다. "메신저가 너무 무겁고 복잡해졌다", "소통이라는 본질이 흐려지고 광고와 쓸데없는 영상만 가득하다"라는 피로감과 불만이 쏟아졌다. 여기서 비즈니스 기획의 진짜 난제가 등장한다. 생존과 성장을 위한 가장 합리적인 사업적 '더하기'가, 사용자의 이용 흐름을 훼손하여 시스템 전체를 마비시키는 독이 될 수 있다는 점이다.
게임 기획에서도 마찬가지다. 기존 유저의 이탈을 막고 단기 매출을 올리기 위해 끊임없이 새로운 캐릭터와 강력한 장비를 출시해야 하지만, 이는 결국 '콘텐츠 인플레이션'을 낳는다. 시스템의 복잡도와 진입 장벽이 임계점을 넘는 순간, 신규 유저의 진입 도로가 완전히 폐쇄되며 게임은 서서히 고사한다. 결국 "더할 것인가, 뺄 것인가"는 단순한 미니멀리즘 철학의 영역이 아니다. 비즈니스의 생존 요구와 사용자 경험의 항상성 사이에서 균형을 잡는 고도의 시스템 제어 문제다.
만약 비즈니스의 성장과 생존을 위해 무언가를 '더해야만 하는 상황'이 필연적이라면, 우리는 브라에스 역설의 덫을 피해 어떻게 지혜롭게 더할 수 있을까? 시스템의 전체 균형을 깨뜨리지 않으면서 새로운 비즈니스 가치를 추가하는 기획의 기술은 크게 세 가지로 요약된다.
첫째, 격벽 디자인이다. 새로 추가되는 기능이 기존 핵심 경험의 동선을 침범하거나 오염시키지 않도록 시스템 내부에 방화벽을 세우는 것이다. 실패 사례로는 카지노톡 친구 목록 한가운데나 대화방 진입 직전에 원치 않는 콘텐츠를 강제로 노출하는 방식이 있다. 이는 기존의 소통 균형을 파괴하여 강한 심리적 피로감을 유발한다. 반면 성공 사례는 핵심 동선을 완벽히 보존하되, 사용자가 명확한 목적을 가지고 선택해서 진입할 수 있는 별도의 전용 탭이나 공간으로 새로운 기능을 완전히 격리하는 방식이다.
둘째, 비용과 넛지 디자인이다. 교통 체증을 막기 위해 새 도로를 건설할 때 '혼잡 통행료'라는 게임의 룰을 도입하면 트래픽이 통제된다. 마찬가지로 서비스에 기능을 더할 때, 사용자가 무분별하게 그 기능을 남용해 시스템을 망가뜨리지 않도록 행동적·심리적 비용이나 규칙을 함께 설계해야 한다. 토스는 송금이라는 핵심 흐름 사이에 '사기 의심 계좌 경고'나 '받는 사람 확인'이라는 의도적인 마찰을 더했다. 이는 사용자에게 아주 미세한 불편함을 주지만, 금융 사고 예방이라는 시스템 전체의 신뢰와 안전을 지탱하는 버팀목이 된다.
셋째, 플러그인 구조 설계다. 새 기능을 서비스의 중심 뼈대와 강하게 결합해 버리면, 나중에 유저 반응이 나쁘거나 시스템 과부하가 걸려도 쉽게 도려낼 수 없다. 가장 훌륭한 더하기는 언제든 상처 없이 쉽게 뺄 수 있는 형태로 붙이는 것이다. 마치 브라우저의 확장 프로그램처럼 새로운 기능이 메인 엔진에 언제든 붙었다 떨어질 수 있는 구조여야 한다. 그래야 전체 시스템에 무리를 주지 않고 일부 사용자를 대상으로 한 카나리아 테스트가 가능하며, 실패 시 즉각적인 롤백이 가능해진다.
우리는 종종 '단순함'과 '미니멀리즘'을 동일시하며 무조건 빼는 것을 최고의 기획이라 오해한다. 하지만 맥락 없는 빼기는 더하기만큼이나 위험한 지옥을 부른다. 동시에, 눈앞의 지표만을 쫓는 무분별한 비즈니스적 더하기 역시 전체 시스템을 붕괴시키는 파국을 부른다.
진정한 단순함은 많이 빼는 행위에서 오는 것이 아니다. 비즈니스의 필연적인 복잡성과 사용자의 상호작용을 완벽히 이해한 후, 최적의 게임의 룰을 설계하여 도달하는 최종 결과물이다.
기획자이자 사업적 의사결정권자로서, 새로운 기능을 논의하는 테이블 위에서 매번 다음의 세 가지 질문을 스스로에게 던져보자.
첫째, 동적 균형의 질문이다. 우리가 지금 더하거나 빼려는 이 기능은 현재 시스템 내에서 어떤 보이지 않는 균형을 유지하고 있는가?
둘째, 대체 경로의 질문이다. 이 기능을 더하거나 뺐을 때, 사용자가 취할 최악의 '우회 행동'은 무엇이며, 그것이 전체 생태계에 어떤 트래픽 과부하를 줄 것인가?
셋째, 격벽과 비용의 질문이다. 이 더하기가 사업적으로 정말 필연적이라면, 기존 핵심 경험을 방해하지 않도록 어떻게 격리하고 어떤 행동적 규칙을 함께 설계할 것인가?
단순함은 결과이지, 방법이 아니다. 당신의 다음 '더하기와 빼기'가 단순한 유행의 추종이 아닌, 시스템 전체를 관통하는 정교한 통찰의 결과이기를 바란다.