지식그래프에 영향도 분석 얹기 - 시스템 하나 건드리면 어디까지 영향이 퍼질까?
"이 서버 내리면 어디가 죽을까?"
서버 점검이나 시스템 교체를 할 때, 항상 나오는 질문이 있거든요. "이거 내리면 어디까지 영향받아?" 보통은 담당자한테 물어보거나, 문서를 뒤져서 의존성을 하나하나 확인합니다.
그런데 지식그래프에 이미 시스템 간 연결 정보가 다 들어가 있잖아요. 이걸 활용하면 "이 노드에서 출발해서 N홉까지 연결된 모든 것"을 자동으로 보여줄 수 있겠다 싶었습니다. 영향도 분석 기능을 만들기로 한 거예요.
이전 글에서 N홉 탐색의 삽질을 정리했는데, 그 과정을 거치고 나니까 영향도 분석·최단 경로·중요도 시각화까지 세 가지 기능이 한꺼번에 나왔습니다.
영향도 분석 — depth별로 파급 범위를 보여준다
영향도 분석의 동작은 이렇습니다. System 노드를 선택하고 "영향도 분석" 버튼을 누르면, 해당 노드에서 1홉, 2홉, 3홉 거리까지 연결된 모든 노드를 BFS로 탐색해서 depth별로 색상을 다르게 표시합니다.
depth 0 (시작점) : 물류서버 ← 파란색
depth 1 (1홉) : 미들웨어, 서비스A ← 빨간색 (직접 연결)
depth 2 (2홉) : DB서버, 담당자 ← 주황색 (간접 영향)
depth 3 (3홉) : 더 먼 시스템들 ← 노란색 (파급 효과)비유하자면 연못에 돌을 던졌을 때 물결이 동심원으로 퍼져나가는 것과 같아요. 시작점에서 가까운 것부터 차례로 탐색하면서, 각 원(depth)에 다른 색을 입히는 거예요. "빨간색이면 직접 영향, 주황이면 간접 영향" 식으로 파급 범위가 시각적으로 한눈에 들어옵니다.
실무에서는 이런 상황에서 쓰게 되더라고요.
상황 | 질문 |
|---|---|
서버 점검 | "물류서버 내리면 어떤 서비스가 죽나?" |
장애 전파 | "DNS 장애나면 어디까지 영향받나?" |
변경 관리 | "이 시스템 수정하면 관련자가 누구?" |
마이그레이션 | "이 시스템 교체하려면 영향 범위가?" |
담당자한테 물어보면 "아마 이거랑 저거?" 식으로 기억에 의존하는데, 그래프에서 탐색하면 빠진 게 없이 전부 나옵니다. 특히 2~3홉 거리의 간접 영향은 사람이 놓치기 쉬운 부분이거든요.

탐색 방향도 제어할 수 있다
영향도 분석에 direction 파라미터를 넣었습니다. upstream(이 시스템에 의존하는 것), downstream(이 시스템이 의존하는 것), both(양방향) 세 가지예요.
"물류서버를 내리면 뭐가 죽나?"는 upstream이에요. 물류서버에 의존하고 있는 시스템을 찾는 거거든요. 반대로 "물류서버가 죽으면 원인이 뭘까?"는 downstream이에요. 물류서버가 의존하는 시스템 쪽을 보는 거죠.
기본값은 both로 잡았습니다. 실무에서는 영향 범위 전체를 먼저 파악하고, 필요하면 방향을 좁히는 패턴이 많더라고요.
최단 경로 — 두 노드 사이 연결을 찾는다
영향도 분석이 "한 노드에서 퍼져나가는 범위"를 보여준다면, 최단 경로는 "두 노드 사이가 어떻게 연결돼 있는지"를 보여주는 기능입니다.
동작은 직관적이에요. 시작 노드를 클릭하고, 도착 노드를 클릭하면 그 사이의 가장 짧은 연결 경로를 빨간색으로 하이라이트합니다. 상단에 "물류서버 → 미들웨어 → DB서버 (2홉)" 식으로 경로 정보도 표시되고요.
Neo4j의 shortestPath() 함수를 쓰면 됩니다. 양방향 BFS로 최적화되어 있어서 대규모 그래프에서도 빠르거든요.
MATCH (a:System {name: "물류서버"}), (b:System {name: "인증서버"})
MATCH path = shortestPath((a)-[*..10]-(b))
RETURN path이게 실무에서 유용한 건, "이 두 시스템이 연결돼 있긴 한데, 어떤 경로로?"를 보여주기 때문이에요. 장애가 A에서 발생해서 B까지 전파됐을 때, 중간 경로를 추적할 수 있습니다. 신규 담당자가 "내가 담당하는 시스템이 저 시스템이랑 관련이 있어?"를 확인할 때도 쓰더라고요.
PageRank — 중요한 노드를 크게 보여준다
마지막으로 추가한 건 노드 크기를 중요도에 따라 다르게 표시하는 기능이에요. 연결이 많은 노드가 더 크게 보이는 거죠.
원래 구글이 웹페이지 중요도를 측정하기 위해 만든 PageRank 알고리즘을 간소화해서 적용했습니다. GDS 라이브러리 없이 단순하게, 각 노드의 연결 수(degree)를 세서 크기에 반영하는 방식이에요.
MATCH (n)-[r]-()
WHERE n:Person OR n:System OR n:Service
RETURN n.name, labels(n)[0] AS type, count(r) AS score
ORDER BY score DESC LIMIT 100기존에는 현재 화면에 보이는 연결 수로 크기를 정했는데, 이러면 전체 그래프에서 50개 연결이 있는 노드라도 현재 뷰에 2개만 보이면 작게 표시됐거든요. PageRank 방식은 전체 그래프 기준으로 계산하니까, 뷰에 없는 연결도 반영돼서 실제 중요도에 가까운 크기가 됩니다.
항목 | 기존 | PageRank 적용 후 |
|---|---|---|
기준 | 현재 뷰의 연결 수 | 전체 그래프의 연결 수 |
의미 | 이 화면에서 많이 연결된 노드 | 전체에서 중요한 노드 |
다이어그램을 열었을 때 유독 큰 노드가 보이면, "이 시스템이 전체 인프라에서 허브 역할을 하는구나"라는 게 직관적으로 파악되더라고요.
세 기능이 합쳐지면 인프라 파악이 달라진다
세 기능을 각각 쓸 수도 있지만, 합쳐서 쓰면 더 강력합니다.
PageRank로 그래프를 열면 큰 노드(허브 시스템)가 먼저 눈에 들어옵니다. 그 노드를 클릭해서 영향도 분석을 돌리면, 이 허브가 죽었을 때 어디까지 영향이 퍼지는지가 depth별 색상으로 보여요. 특정 경로가 궁금하면 최단 경로로 두 노드 사이의 연결을 추적할 수 있습니다.
기존에는 이런 분석을 문서 뒤지고, 담당자한테 물어보고, 엑셀에 정리하는 방식으로 했거든요. 지식그래프에 시각화 기능을 얹으니까 클릭 몇 번으로 같은 결과를 얻을 수 있게 됐습니다.
쿼리보다 시각화가 설명을 대신한다
지식그래프를 만들고 나서 "이거 어디에 쓰냐?"는 질문을 종종 받았거든요. Cypher 쿼리 결과를 텍스트로 보여줘봐야 비개발자에게는 와닿지 않았습니다. 그런데 영향도 분석을 depth별 색상으로 보여주니까, "아 이 서버가 이렇게 많은 곳에 연결돼 있었어?"라는 반응이 바로 나오더라고요.
지식그래프의 가치는 데이터를 넣는 것보다 보여주는 방식에서 드러나는 경우가 많습니다. 그래프를 만들어놨는데 활용도가 낮다면, 시각화 기능부터 얹어보는 걸 추천합니다.