Cloud Visualizer
← 전체 목록
🌍

BGP

프로토콜자율 시스템 간 경로를 교환하는 인터넷의 라우팅 프로토콜

아키텍처 다이어그램

점선 애니메이션은 데이터 또는 요청의 흐름 방향을 나타냅니다

왜 필요한가요?

한 조직 안의 라우팅은 내부 라우팅 프로토콜로 해결할 수 있습니다. 하지만 인터넷은 수만 개의 독립된 네트워크가 모인 구조이고, 각 네트워크는 서로 다른 조직이 서로 다른 정책으로 운영합니다. ISP A의 라우터가 ISP B의 내부 경로를 모두 알 필요도 없고, 알아서도 안 됩니다. 문제는 이렇게 독립적인 네트워크들이 서로의 목적지에 도달하는 경로를 어떻게 교환하느냐입니다. 내부용 라우팅은 같은 관리 권한 아래에서 최단 경로를 찾으면 되지만, 조직 간 경로는 기술적 최적 경로뿐 아니라 비용, 계약, 정책까지 반영해야 합니다. 이 문제를 풀지 않으면 인터넷 전체의 연결 자체가 성립하지 않습니다.

왜 이런 방식이 등장했나요?

인터넷 초기에는 네트워크 수가 적었고, 경로 정보를 정적으로 설정하거나 단순한 프로토콜로 교환해도 충분했습니다. 하지만 인터넷이 상업화되면서 ISP, 대학, 기업이 각각 독립적으로 네트워크를 운영하기 시작했고, 수천 개의 네트워크가 수만 개의 경로를 주고받아야 하는 규모가 됐습니다. 기존의 EGP(Exterior Gateway Protocol)는 정책 기반 경로 선택을 지원하지 못했고, 경로 루프 감지도 취약했습니다. BGP가 필요해진 이유는 단순히 규모가 커져서가 아니라, 경로 선택이 더 이상 기술적 최적 경로만의 문제가 아니게 됐기 때문입니다. ISP 간 계약 관계에 따라 특정 트래픽을 특정 경로로 보내야 하고, 비용이 싼 경로와 빠른 경로가 다를 수 있으며, 장애 시 자동으로 우회 경로를 찾아야 합니다. BGP는 이런 정책적 요구를 경로 속성으로 표현할 수 있게 설계됐고, 그 결과 오늘날 인터넷 전체의 AS 간 경로 교환을 사실상 독점하고 있습니다.

안에서 어떻게 동작하나요?

BGP는 먼저 두 라우터가 TCP 179번 포트로 세션을 수립합니다. 이 세션을 피어링이라고 부르며, 같은 AS 안의 라우터끼리 맺으면 iBGP, 서로 다른 AS 사이에서 맺으면 eBGP입니다. 세션이 열리면 UPDATE 메시지를 통해 '이 네트워크 prefix에 도달하려면 이런 AS들을 거쳐야 한다'는 경로 정보를 교환합니다. 각 경로에는 AS-PATH라는 속성이 붙어서 그 경로가 어떤 AS를 거쳐 왔는지를 순서대로 기록합니다. 라우터는 이 AS-PATH를 보고 경로 루프를 감지하고, 경로의 길이도 비교합니다. 하지만 BGP에서 경로를 고르는 기준은 단순한 홉 수가 아닙니다. Local Preference로 내부적으로 선호하는 경로를 지정하고, MED로 외부에 자기 네트워크로 들어올 때의 선호 입구를 알릴 수 있으며, Community 태그로 경로 그룹에 정책을 일괄 적용할 수도 있습니다. 이렇게 경로 선택이 정책적이라는 점이 내부 라우팅 프로토콜과 가장 다른 부분입니다.

무엇과 헷갈리나요?

BGP와 OSPF 같은 내부 라우팅 프로토콜(IGP)은 둘 다 경로를 교환한다는 공통점이 있지만, 동작 범위와 설계 목표가 다릅니다. IGP는 하나의 조직 내부에서 최단 경로를 빠르게 수렴하는 데 최적화되어 있고, 네트워크 토폴로지 전체를 공유합니다. BGP는 서로 다른 조직 사이에서 동작하며, 내부 구조를 숨기면서 prefix 단위로 도달 가능성만 알려줍니다. 또한 IGP는 링크 비용 같은 기술적 메트릭으로 최적 경로를 계산하지만, BGP는 AS-PATH 길이, Local Preference, 계약 관계 같은 정책 기반으로 경로를 선택합니다. 내부 네트워크의 경로 최적화는 IGP의 문제이고, 조직 간 연결과 트래픽 정책은 BGP의 문제입니다. 실제 운영에서는 둘이 함께 동작하며, BGP가 외부에서 받은 경로를 IGP가 내부에 배포하거나 그 반대가 일어납니다.

언제 쓰나요?

BGP는 ISP가 서로의 네트워크를 연결할 때, 기업이 여러 ISP에 동시 연결(멀티호밍)해서 한쪽 장애 시 자동으로 다른 경로를 쓸 때, 클라우드 전용 회선(Direct Connect, Cloud Interconnect)으로 온프레미스와 클라우드를 연결할 때 사용됩니다. 대규모 서비스를 운영하는 기업이라면 BGP 정책으로 인바운드/아웃바운드 트래픽 경로를 세밀하게 제어할 수 있습니다. 반대로 같은 조직 내부의 서브넷 간 경로 계산에는 BGP가 과합니다. BGP는 수렴 속도보다 정책 유연성에 무게를 둔 프로토콜이라 내부 경로가 바뀔 때 반영이 느릴 수 있고, 설정 복잡도도 높습니다. 또한 BGP 설정 실수는 자기 네트워크뿐 아니라 인터넷 전체에 영향을 줄 수 있어서, 경로 필터링과 prefix 검증을 반드시 함께 운영해야 합니다. BGP를 쓸지 판단할 때는 '조직 경계를 넘는 경로 교환이 필요한가'를 먼저 따지는 것이 핵심입니다.

ISP 간 인터넷 연결멀티호밍클라우드 전용 회선대규모 네트워크 정책 제어