- 네트워크 및 IT 운영
회사에 Graph Database를 둘 공간이 없다고 생각하시나요? 아니면 Graph Database를 제품에 통합하는 데 엄청난 노력이 필요할까요?
꼭 말씀드리고 싶은 점은 다음과 같은 Graph Database를 사용할 수 있다는 거예요. 제품을 건드리지 않고도 회사의 지식을 관리하고 소프트웨어 개발 프로세스를 개선하는 데 사용할 수 있다는 거죠. 따라서 비즈니스 문제가 본질적으로 그래픽(2018년 기준으로는 믿기 어려움)이 아니더라도 환경을 그래프로 생각해야 하는 몇 가지 이유가 있어요.
여러분의 핵심 비즈니스를 알지 못하더라도 가장 중요한 연결된 데이터 세트는 여러분의 조직이라고 확신해요. 여러분이 IT 부문에 종사하고 있다면 여러분은 이미 연결되어 있으며 여러분의 가장 중요한 회사 가치는 이미 그래프로 인코딩되어 있어요.
우리는 그래프가 세상을 삼키고 있다는 사실을 배웠어요. 이 블로그에서는 그래프가 이미 전체 소프트웨어 개발 프로세스를 잠식한 이유와 Graph Database 사용을 시작해야 하는 이유(아직 시작하지 않은 경우)를 보여 드릴게요.
소프트웨어 아키텍처 및 마이크로서비스로의 전환
아키텍처부터 시작해 보죠. 저는 여러분이 몇 년 이상 사업을 운영해 왔다면 매 시즌마다 조직 내에서 전형적인 과대광고 주기를 경험했을 거라고 확신해요. 여러분은 모놀리스에서 서버리스로 나아가는 중이며 시스템에서 무엇이 더 좋을지에 대한 철학적 논쟁이 있죠.
느슨하게 결합된 마이크로서비스에 대해 작업하고 있을 가능성이 있어요. 이 마이크로서비스는 종종 종속성(개발 및 배포 종속성 모두를 의미함)을 갖고 있어 설계자와 서비스 소유자조차도 이를 식별하고 분석하기 위한 적절한 도구가 필요할 정도로 복잡해요.
마이크로서비스를 아주 잘 수행하더라도 소프트웨어 아키텍처를 종속성 지옥 또는 분산형 단일체로 설명하는 회사 직원이 항상 있을 거예요.
어쨌든 콘웨이의 법칙을 무시할 수는 없어요. 여러분의 아키텍처는 항상 조직 구조의 복사본이 되죠. 이것은 항상 복잡한 네트워크/그래프예요. 단, 대학 절친과 함께 1인 쇼를 진행하거나 자금이 부족한 스타트업을 운영하는 경우는 예외예요.
결국 우리는 수많은 타사 소프트웨어 컴포넌트에 의존하는 복잡한 아키텍처, 즉 소프트웨어 컴포넌트들의 네트워크를 갖게 되는 거죠.
혹시 "left-pad 사건" 기억하시나요? 2년 전에 발생했던 JavaScript 라이브러리의 젠가 타워 같은 사건이었는데요. 이름 충돌 문제로 Kik 패키지를 구현한 사람이 npm에서 모든 패키지를 제거해버리면서 인터넷의 절반이 마비되었어요. 전 세계적으로 수천 개의 빌드가 실패하고, 수많은 JavaScript 개발자들이 좌절했죠. 패키지 의존성이 이렇게까지 큰 혼란을 초래할 수 있다고 생각한 사람은 아무도 없었을 거예요. IT 업계에선 정말 슬픈 날이었죠.
이 사건을 통해 우리는 몇 가지 교훈을 얻은 것 같아요. 오픈 소스든 비공개 소스든 소프트웨어를 개발한다면 다음 사항들을 꼭 알아야 해요.
- 애플리케이션의 평균 80%는 대부분 오픈 소스인 타사 컴포넌트로 구성돼요.
- 이러한 애플리케이션의 타사 소프트웨어 컴포넌트 중 거의 50%는 오래되었고, 심지어 몇 년이나 된 것도 많아요.
이 점을 깨닫기 위해 작년에 재밌는 프로젝트를 진행했었는데요. 저는 Libraries.io의 다양한 패키지 관리자의 오픈 소스 패키지에 대한 데이터 셋을 Neo4j 인스턴스로 옮겼어요. 우리의 레거시 소프트웨어가 전 세계의 익명의 사람들이 작성한 수천 개의 다른 라이브러리에 의존하고 있다는 사실을 알게 되었죠. 적절한 비즈니스 연속성을 확보하려면 소프트웨어 제품의 종속성에 대한 가시성과 제어 능력이 필수적이에요. 그리고 이건 바로 Graph Database의 완벽한 사용 사례라고 할 수 있죠.
과제: 전달 종속성의 혼란
아키텍처와 타사 소프트웨어 종속성을 파악하고, 이제 자체 소프트웨어를 출시할 준비가 되었다면, 자체 제공 종속성을 처리해야 하는 과제가 남아있어요. 프로젝트에는 그래프로 추적할 수 있고 또 추적해야 하는 배포 혼란이 있다는 것을 알게 될 거예요. 사용자에게 제공해야 하는 단계별 배포 계획이 무엇인지 아무도 제대로 이해하지 못하기 때문이죠. 그래프를 사용해서 프로젝트 배포의 혼란을 줄여보세요.
개발 프로세스 중에 소프트웨어 엔지니어를 지원(하기도 하고 좌절시키기도 하는)하기 위해 이슈 트래킹 시스템을 사용할 가능성이 높아요. 모든 버그 추적 및 프로젝트 관리 정보를 저장하기 위해 JIRA 또는 유사한 이슈 트래킹 시스템을 사용할 수도 있고요.
제대로 사용하지 않으면 금방 엉망이 될 수 있지만, 예상대로 사용한다면 진행 상황, 버그, 중요 영역 등에 대한 유용한 정보를 많이 얻을 수 있고, 이를 통해 의미 있는 통계를 얻을 수 있죠.
하지만 이슈 트래킹은 단순히 버그를 수정하는 것 이상이에요. 연결된 거대한 데이터 셋이고, Graph Database는 티켓 관계에서 귀중한 통찰력을 발견하는 데 도움을 줄 수 있어요. 이슈 트래킹 시스템에서 직접 식별하기가 거의 불가능한 숨겨진 가치가 있다는 거죠.
만약 규모가 큰 회사라면 매일 소프트웨어 엔지니어의 문제 해결 기술이 문서화되고 버그 티켓에 대한 의견으로 기록된다는 것을 알게 될 거예요. 티켓과 티켓의 관계에는 엄청난 가치가 숨어있죠. 또한 누군가가 코드 저장소에 변경 사항을 커밋하면, 이상적으로는 개발자가 해당 티켓에 대한 정보도 함께 제공해야 해요.
자신의 소프트웨어를 더 잘 이해하기 위해 이 정보를 재사용하지 않을 이유가 있을까요?
좀 더 자세히 살펴보면 제품 페이지나 블로그 게시물의 사용자 의견/피드백, 개발자 커뮤니티나 Stack Overflow의 대화 및 Q&A 등과 같이 더 유용한 텍스트 정보가 있는 다른 장소도 많아요. 아니면 회사가 대중에게 평가받는 인터넷을 한번 둘러보세요. 제품이나 서비스에 관한 많은 관련 "측정 항목"을 찾을 수 있을 거예요.
이 모든 정보를 Graph Database에 저장할 수 있고, 벌써 절반이나 왔네요! Neo4j에 이미 데이터가 있다면, 가장 흔한 첫 번째 활용 사례는 데이터를 검색 가능하게 만들고 사용자에게 딱 맞는 검색 결과를 제공하는 거예요.
여기서 멈추지 않고, 사용자 니즈에 맞춰 검색 결과를 계속 개선하는 긍정적인 피드백 루프를 만들 수 있죠. 사용자가 소프트웨어 개발자라면 관련 문서를 찾거나, 문서와 버그 리포트 간의 관계, 요구 사항과 실제 코드 간의 차이점을 찾아야 할 때가 있을 거예요. 이걸 도와줄 복잡한 쿼리들이 정말 많답니다.
해결책: Knowledge Graph
이제는 단순히 관련성 있는 결과를 보여주는 것만으로는 부족해요. 사용자가 정보를 제대로 활용할 수 있도록 의미 있는 지식을 제공해야 하죠.
회사는 이미 100년이 넘는 시간 동안 지식을 쌓아왔고, 앞으로도 계속 성장할 거예요. 미래에 회사를 더 성공적으로 운영하려면 이 지식과 경험을 재사용해야 해요. 소프트웨어 개발 중에 똑같은 실수를 반복할 필요 없이, 새로운 실수를 통해 배울 수 있죠. 이게 바로 학습의 방식이고, 최고의 회사들이 일하는 방식이에요. 그래서 Knowledge Graph가 중요한 거예요.
이제 학습하는 조직이라면 Knowledge Graph는 필수예요. 예전에는 NASA처럼 전문적인 기관만 Knowledge Graph를 활용할 수 있었지만, 이제는 모든 소프트웨어 개발 회사들이 곧 갖게 될 거라고 생각해요.
마치 지금의 티켓팅 시스템처럼 Knowledge Graph는 필수가 될 거예요!
저는 기술 회사들이 Graph Database, NLP/NLU 도구, 그리고 요즘 핫한 Machine Learning 알고리즘 간의 시너지 효과를 이용해서 경쟁 우위를 만들고 강화할 수 있는 미래가 곧 올 거라고 믿어요.
모든 조직이 실행 가능한 통찰력을 얻을 수 있는 그래프라는 건 분명하죠. Neo4j를 기반으로 Knowledge Graph를 구축하고 데이터를 지혜로 바꾸는 데 관심 있다면, 기업 지식을 활용하는 데 필요한 모든 요소를 제공하는 GraphAware의 새로운 Hume 플랫폼을 꼭 확인해 보세요. 왜냐하면 지혜는 효율성을 높이는 능력이니까요!
- Hume
- 문제 추적 시스템
- 자바스크립트
- 지식 그래프
- 마이크로서비스
에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.
'GraphRAG' 카테고리의 다른 글
| 연결된 데이터, 지속 가능한 경쟁 우위: Neo4j와 GraphRAG 활용법 (0) | 2026.06.03 |
|---|---|
| Structr, 차세대 Data-CMS 전격 공개! (0) | 2026.06.03 |
| RAG 애플리케이션에서 텍스트 임베딩의 한계 (0) | 2026.05.31 |
| GraphQL API에 Retrieval-Augmented Generation (RAG)을 더하는 방법 (0) | 2026.05.31 |
| LlamaIndex에서 Property Graph Index를 내 입맛대로 커스터마이징하기 (0) | 2026.05.29 |