이메일로 IT 인프라 지식그래프를 만들어봤는데, 이메일만으로는 부족했던 이유

이메일에서 엔티티를 뽑아봤다

IT 인프라 관련 이메일이 수천 건 쌓여 있었거든요. 서버 점검 알림, 인증서 갱신 요청, 장애 대응 스레드 같은 것들이요. "이걸 지식그래프로 만들면 어떤 서버에 어떤 이슈가 있었는지, 누가 담당했는지 한눈에 보이겠다"는 생각으로 시작했습니다.

파이프라인은 PST에서 이메일을 추출하고, LLM으로 엔티티를 뽑아서, Neo4j에 넣는 구조였어요. LLM이 이메일 본문에서 서버명, 시스템명, 사람 이름, 이슈 키워드를 추출하고, 규칙 기반으로 발신자/수신자/참조자 관계를 잡는 하이브리드 방식이었습니다.

엔티티 추출 결과를 보니까, 뽑히는 게 한정적이더라고요.

잘 뽑히는 건 이런 것들이었어요. 누가 누구에게 보냈는지, 어떤 이슈에 대해 커뮤니케이션했는지, 시간 순서는 어떻게 되는지. "물류서버 인증서 갱신 완료했습니다"라는 이메일에서 발신자-물류서버-인증서갱신 관계는 잘 잡혔습니다.

문제는 인프라 속성이었어요. 물류서버의 IP가 뭔지, OS가 뭔지, 어떤 시스템과 연결돼 있는지는 이메일에 안 써 있거든요. 이메일은 "물류서버 점검합니다"라고 쓰지, "물류서버 IP는 10.0.1.5이고 OS는 Ubuntu 22.04입니다"라고 쓰지 않아요.

LLM이 아무리 잘 추출해도 원본에 없는 정보는 못 뽑습니다. 이메일만으로는 "누가 어떤 이슈를 처리했다"는 커뮤니케이션 그래프는 만들 수 있지만, "서버가 어떻게 구성돼 있고 뭐랑 연결돼 있다"는 인프라 그래프는 만들 수 없었어요.

이메일만으로 안 되니까 다른 소스를 찾아봤어요. 이미 정리돼 있는 자료가 두 종류 있었거든요.

하나는 서버·시스템 목록이 정리된 엑셀이었습니다. 호스트명, IP, OS, 담당자, 용도 같은 정형 데이터가 행 단위로 깔끔하게 들어 있었어요. 이메일에서 못 뽑던 인프라 속성이 여기에 다 있었습니다.

다른 하나는 시스템 구성도나 운영 절차가 정리된 Docs였어요. "이 시스템이 어떤 시스템을 호출하는지", "장애 시 어떤 순서로 대응하는지" 같은 구조와 의존성 정보가 여기 있었거든요.

정리하니까 역할이 깔끔하게 나뉘더라고요.

이메일은 "살아 있는 맥락"을 주고, 엑셀은 "정확한 팩트"를 주고, Docs는 "전체 그림"을 주는 거예요. 하나만으로는 반쪽짜리인데, 합치니까 인프라 그래프가 완성됐습니다.

세 소스를 Neo4j에 넣는 건 어렵지 않았어요. 각 소스별로 추출 파이프라인을 돌리고, 같은 엔티티를 매칭해서 하나의 노드로 합치면 되거든요.

문제는 "같은 엔티티"를 판별하는 과정이었습니다. 이메일에서는 "SMTP서버", 엑셀에서는 "smtp서버", Docs에서는 "Smtp서버"로 적혀 있는 경우가 있었거든요. 사람이 보면 같은 건데, 문자열 비교로는 세 개의 다른 노드가 됩니다.

이걸 처리 안 하면 같은 서버가 3개의 노드로 뻥튀기돼요. 이메일에서 온 "SMTP서버" 노드에는 담당자 정보만 붙어 있고, 엑셀에서 온 "smtp서버" 노드에는 IP만 붙어 있고, 서로 연결이 안 되는 겁니다. 소스를 합친 의미가 없어지는 거죠.

해결 방법은 임포트 단계에서 normalize를 적용하는 거였어요. 엔티티 이름을 소문자로 통일하고, 공백·특수문자를 정리한 뒤에 매칭하는 규칙을 넣었습니다. 이렇게 하니까 소스가 달라도 같은 엔티티는 하나의 노드로 합쳐졌어요.

엔티티 추출 방식도 소스에 따라 다르게 가져갔습니다.

이메일은 LLM 의존도가 높아요. 본문이 비정형이라 "이 메일에서 서버명, 이슈, 사람을 뽑아줘" 식으로 LLM에 맡기고, 발신자/수신자/참조자 관계는 헤더에서 규칙 기반으로 잡습니다.

엑셀은 반대로 규칙 기반이 주력이에요. 열 이름이 곧 속성 이름이고, 행 하나가 엔티티 하나거든요. LLM이 개입할 필요가 거의 없습니다.

Docs는 중간이에요. 정형화된 표는 규칙으로 파싱하고, 자연어로 된 설명 부분은 LLM으로 의존성 관계를 추출합니다.

소스의 정형화 정도에 따라 LLM 비중을 조절하는 게 핵심이에요. 정형 데이터에 LLM을 돌리면 비용만 나가고, 비정형 데이터를 규칙으로만 잡으려면 커버리지가 떨어지거든요.

돌이켜보면, 처음에 "이메일로 지식그래프 만들기"라고 접근한 것 자체가 소스를 하나로 한정한 실수였어요.

이메일은 "살아 있는 맥락"을 제공하는 소스이지, 인프라 팩트를 정리해놓은 소스가 아니거든요. 서버 IP가 뭔지, 어떤 시스템이 어떤 시스템을 호출하는지는 이메일에 안 써 있습니다.

엑셀이 정확한 속성을 주고, Docs가 구조를 주고, 이메일이 그 위에 시간축과 사람 관계를 얹어줍니다. 세 레이어가 합쳐져야 "이 서버가 뭐고, 누가 관리하고, 언제 무슨 일이 있었는지"가 하나의 그래프에 담기거든요.

지식그래프를 만들 때 소스 하나에 기대하면 반쪽짜리가 됩니다. 어떤 소스가 어떤 역할을 하는지 먼저 정리하고, 합치는 설계를 먼저 하는 걸 추천합니다.