브라에스 역설로 보는 '더하기'의 함정
(다시) 매일 글쓰기 (059/100)
공부하기 위한 글쓰기 002 : 브라에스 역설
1990년, 뉴욕시는 42번가의 한 도로를 폐쇄했습니다. 놀랍게도, 이로 인해 교통 흐름이 더 원활해졌습니다. 도로를 없앴는데도 교통이 좋아지다니, 이는 우리의 교통에 대한 일반적인 상식을 완전히 뒤집는 결과입니다. 어떻게 이런 일이 가능했을까요? 이것이 바로 오늘 이야기할 '브라에스 역설(Braess' Paradox)'의 시작입니다. 간단히 말하면, "더하면 더 좋을 것 같지만, 때로는 그렇지 않다"는 역설입니다.
어느 날, 출발지(S)에서 목적지(D)로 가는 두 개의 경로가 있던 도로 네트워크에 새로운 길이 추가되었습니다. 원래의 경로는 다음과 같았습니다.
첫 번째는 S → A → D, 두 번째는 S → B → D로 구성되어 있었죠.
각 구간의 소요 시간은 아래와 같았습니다:
• S → A: 45분 (고정)
• A → D: 차량 수를 100으로 나눈 값 (차량이 많을수록 시간이 늘어남)
• S → B: 차량 수를 100으로 나눈 값
• B → D: 45분 (고정)
이 네트워크를 통해 차량 4,000대가 이동한다고 가정해볼까요?
처음에는 각 경로에 차량이 균등하게 분산되어, S → A → D와 S → B → D 경로로 각각 2,000대씩 나뉘었습니다.
이때 두 경로의 소요 시간을 계산해 보면:
1. S → A → D:
• S → A: 45분
• A → D: 분
• 총 소요 시간 = 45 + 20 = 65분
2. S → B → D:
• S → B: 분
• B → D: 45분
• 총 소요 시간 = 20 + 45 = 65분
이렇게 차량이 고르게 나뉘어 다니는 상황에서는, 모든 운전자가 65분 만에 목적지에 도착할 수 있었습니다.
여기까지는 모두가 만족스러웠죠.
그러나, 새로운 도로가 등장했습니다.
어느 날, A와 B를 잇는 새로운 도로가 개통되었습니다.
이 도로는 놀랍게도 이동 시간이 0분인 아주 빠른 길이었죠. 당연히 운전자들은 더 빠른 길을 찾으려고 이 새로운 도로를 사용하기 시작했습니다. 이제 모든 차량이 S → A → B → D 경로를 선택하게 된 거죠.
그런데 이 선택이 모든 운전자들에게 어떤 영향을 미쳤을까요?
새로운 경로의 소요 시간을 계산해 봅시다:
1. S → A:
• 차량 4,000대가 이동하므로 소요 시간은 45분.
2. A → B:
• 이 구간은 새로 추가된 도로라서 소요 시간은 0분.
3. B → D:
• 차량 4,000대가 몰리므로 소요 시간은 45분.
총 소요 시간 = 45 + 0 + 45 = 90분
결과적으로, 모든 운전자가 90분이라는 더 긴 시간을 소요하게 된 겁니다.
새로운 도로가 생겼음에도 교통 상황이 더 나빠진 거죠.
이것이 바로 브라에스 역설입니다.
도로를 추가하면 교통이 더 좋아질 것 같다는 우리의 상식을 완전히 뒤집는 현상입니다.
모든 운전자가 자신의 시간을 줄이려는 선택을 했지만, 결국 모두가 손해를 보게 되었습니다. 이는 교통 흐름에서 개인 최적화와 전체 최적화가 반드시 일치하지 않을 수 있음을 보여줍니다.
이런 걸, 1968년 독일의 수학자 디트리히 브라에스가 발견했다고 합니다. 그래서 브라에스 역설이죠. 왜 이런 일이 일어날까? 예를 들어볼게요. 여러분도 경험해 보셨을 것 같은데, 내비게이션이 알려준 '지름길'로 차들이 한꺼번에 몰리면서 오히려 더 막히게 되는 경우요. 각자는 '이 길이 더 빠르겠다'라고 합리적으로 판단했지만, 결과적으로는 모두에게 나쁜 결과가 발생하는 거죠.
이 개념은 복잡한 상황에서 '더하기'가 항상 최선이 아님을 보여줍니다. 효율을 개선하려다 오히려 상황이 악화되는 경우도 있습니다. 처음에는 교통 체증과 관련된 이론이라고만 생각했지만, 자세히 들여다보니 우리 일상 곳곳에서 발견할 수 있는 통찰을 담고 있었습니다. 때로는 더 많이 추가하는 것이 상황을 더 복잡하게 만들 뿐이라는 것을 깨닫는 것이 중요합니다. '과유불급'이라는 말과도 일맥상통하죠.
소프트웨어 개발에서도 유사한 일이 발생합니다. 예를 들어, 특정 팀이 자신들의 모듈을 최적화하려고 노력했지만, 이로 인해 다른 팀이 해당 모듈과의 연계성을 유지하기 어려워지면서 전체 시스템의 성능이 저하되는 상황이 발생할 수 있습니다. 이는 단순히 각 팀이 자신의 최선을 다한다고 해서 전체적인 결과가 개선되지 않는다는 사실을 잘 보여줍니다.
브라에스 역설을 배웠으니, 이제 이걸 어떻게 써먹어 볼까?
브라에스 역설은 우리에게 더하는 것이 항상 해결책이 아님을 알려줍니다. 때로는 뺄 수 있는 만큼 빼는 것이 더 나은 결과를 가져오기도 합니다. 한 예로, 구글은 자사 홈페이지의 불필요한 요소들을 제거해 단순한 검색창만 남기면서 사용성을 극대화한 성공적인 사례가 있습니다. 디자인에서도 불필요한 요소를 덜어내는 것이 좋은 디자인이라 하잖아요. 복잡함을 줄이고 단순함을 유지하는 것이 더 큰 가치를 가져올 수 있습니다.
그러니 앞으로 무언가를 '추가'하려고 할 때 저는 이제 이런 질문들을 먼저 던지려 합니다:
정말 필요한가?
단순히 추가하는 것보다 없애는 것이 더 나은지 고민해봐야 합니다.
전체적인 관점에서 어떤 영향을 미칠까?
부분 최적화는 전체 시스템에 부정적 영향을 미칠 수 있으므로 항상 전체적인 그림을 고려해야 합니다.
단순화할 방법은 없을까?
복잡성을 줄임으로써 효율을 높일 수 있지 않을지 생각해봐야 합니다.
팀 전체의 목표와 일치하는가?
개별 최적화보다는 팀의 목표와 부합하는지 고민하는 것이 협업 효율을 높이는 데 중요합니다.
마무리하며 잠깐 생각해 보세요: 여러분의 일상에서도 '더하기'가 오히려 문제를 악화시킨 경험이 있나요?
예를 들어, 집안 정리를 위해 물건을 더 사거나 여러 앱을 관리하려다 오히려 더 복잡해진 경험이 있을 수 있습니다. 이번 주부터 매주 하나씩 불필요한 것을 제거해 보는 건 어떨까요? 간단한 시도지만, 큰 변화를 만들어낼 수 있을 것입니다.
브라에스 역설을 통해 배운 가장 큰 교훈은 '더하기'가 항상 정답이 아니라는 것입니다. 때로는 '빼기'가 더 나은 결과를 가져옵니다. 복잡성을 줄이는 것이 더 큰 성과를 낼 수 있다는 사실을 잊지 말아야겠습니다.
중요한 것은 더 많이 가지려는 욕심보다는 필요한 것만 남기고 불필요한 것을 덜어내는 용기입니다.
