안녕하세요 정이태입니다.
근 몇주간 현생에서는 제품 분석, 기획 그리고 세미나하며, 주말에는 데이터 엔지니어링 및 Graph 트렌드 팔로업하며 정신없이 지냈네요. 아직도 갈길이 멀긴하지만 얼추 감을 잡아가고 있는거 같아서, 그간 여러 시행착오 겪으며 떠오른 lesson learned 를 작성해보려고합니다. 다소 두서가 없이 작성되었더라도 양해 부탁드립니다 ...^^
(오늘 아침에서야 비로소 kestra 와 neo4j,duckdb 를 붙인 docker-compose 가 정상작동한 것도 한 몫한거 같습니다. 한 숨 돌렸습니다. 이 구성 내용들은 세미나 세션을 따로 열어서 모든분들이 가져다 활용할 수 있게 오픈소스 형태로 공개할 예정이니, 기대해주세요!)
1.현생에서 느낀 그래프 internal & application
GraphRAG를 적용해보려고 Neo4j 를 활용하는 유저들이 예전대비 많이 늘었다. 하지만, 적용하며 겪는 여러 문제들이 있음. 1.느리다 2.가격이 부담된다 3.문제보다 기술에 집중
1) 느리다
다들 이제 초기 지식그래프는 업체와 계약하지 않고도 자체적으로 구축을 잘 하시는편 같습니다. Entity extraction & linking 프롬프트 , 알고리즘들이 학산업계 전반적으로 잘 설명되어있고 활용하기에 간편하게 되어 있기 때문입니다. 하지만, 지식그래프 구축 후 langchain integration 까지 완료한 후에는 Text2Cypher 결과까지 잘 나왔다하더라도, Cypher 결과물 응답 속도가 늦어서 어디서부터 개선해야할지 막막한거죠. Neo4j document에 performance tuning 이라는 제목으로 친절하게 작성되었지만, 이를 모두 고려하며 튜닝하기에 부담되기 마련인데요.
때문에, memory를 업그레이드하고 configuration 에서 memory heap size를 늘리는 방식을 택하시곤 합니다. 하지만 이 방식은 일시적으로는 문제가 해결되겠지만, 결국 한계를 마주하게 됩니다. 좋은 하드웨어가 있다하더라도 그 하드웨어 성능을 최적화하기위한 소프트웨어 이해도가 결국엔 병행되야 한다는거죠. 예를 들자면, Neo4j 조회가 발생할때 그 조회에서 발생하는 bottleneck 들이 차곡차곡 모여 어디에서 bottleneck 발생하는지를 해석할 수 있는 execution plan 해석 역량 등이 필요해집니다.
이를 해석한 뒤에 어느 부분에서 bottleneck 이 발생하니 해당 부분을 parallel thread 기능을 활용해서 search를 한다던지, 해당 search 구문에 특별하게 USING index 를 넣어줌으로써 DAG 설계시 internal statistics 놓친 부분을 보완해준다던지요. 이외에도 무작정 담은 node property 가 문제가 된다던지 적절치 않은 indexing 을 넣었다던지, 내 워크로드가 OLAP 향이기 때문에 INDEXING에 집중해야하는데, OLTP 향을 위한 CONSTRAINT에 집중했다던지 혹은 반대로 진행했다던지요. GraphRAG는 결국 Graph Retrieval (검색) 부터 시작됩니다. 그래프 검색을 어떻게 효율화하려는지 Neo4j internal book을 한 번 공부해보는게 가장 좋은 접근 방법같습니다.
2) 가격이 부담된다
1과 이어지는 내용입니다. on-prem 으로 구축해서 특정 인원이 이를 전담해서 DBA & engineer 관점으로 튜닝해야하는 상황이 부담되기에, 완전 관리형인 cloud 를 고려하실텐데요. 아시는분들은 아시겠지만 가격이 상당합니다. enterprise 급으로 계약을하면 license , hardware 그리고 maintenance 등 부수적인 비용까지 고려해야할텐데요.
과연 GraphRAG를 도입했을때 얻게될때 얻게되는 이익이 이 비용들을 모두 감수할만할까요? 때문에, 이제 오픈소스(kuzudb, graphx, redisgraph, graphscope, duckdb ...등)나 상대적으로 저렴하다라고 홍보하는 memgraph 와 같은 제품들을 살펴보게 되는데요. memgraph 는 상대적으로 비용이 저렴하긴하지만, maintenance 비용이 상당했습니다. 그러면 결국 오픈소스로 돌아오게 되는거죠. 오픈소스를 활용하려면 이제 제품 활용시 발생하는 문제들의 책임 소지가 본인에게 있기에 해당 제품들이 어떤 특성들을 가지고 있는지 스터디하기 시작합니다.
하지만, 여기에서 또 알쏭달쏭합니다. 그래프라는데 테이블로 그래프 조회를한다? 어디를 보면 Adjacency matrix로 데이터를 구성하다그러고.. 어디를 보면 뜬금없이 groupby & join 의 조합으로 진행한다고하는등.. 이렇게 된다면 결국 본래 GraphRAG 를 도입하기 위한 목적을 잃어버리고, 제품 스터디만하다보니 지치게 됩니다. 결국 Graph 도입에 대한 의지가 꺾이고 GraphRAG를 포기하게 되는거죠. 이렇게되면 결국 상대적으로 익숙한 Vector RAG로 돌아가서 엔지니어링을 하실텐데, 이것또한 여러 고려요소가 많기에... 이 부분은 다음에 또 기회될 때 글로 작성해보겠습니다.
비용 산정하기에 좋은 레퍼런스 LDBC BMT
3) 문제보다 기술에 집중
2와 연관되는 내용이 많습니다. GraphRAG, 온톨로지, 팔란티어 등 휘황찬란한 단어들에 매료되어 도입을 시작하는거죠. 본질은 데이터 통합 및 light join (traverse) 이지만, 모든 데이터들을 통합할 필요가 없지만 무작정 데이터들을 모두 연결하려다보니, 거기에서부터 지치는거죠. 그래프가 잘 하는 부분을 인지한 상태에서 그래프 기획을 하고 접근하면 필수적인 노드,엣지들이 보일텐데, 그 부분을 간과하고 모두 연결하기 위해 여러 툴들을 살펴보고 결국 온톨로지까지 들어가게되는 상황이 발생합니다.
2.주말에 트렌드 팔로업 & 필드의 감을 익히기 위한 시도들
현생에서 코딩을 거의 하지않고 논문과 문서들 보며 기획하고 PPT만들고 특허 작성하고 세미나만 하는 등... 기획과 이론쪽으로만 너무 치우쳐져 있다라고 판단해서 주말엔 일부러 시간을 내서 코딩과 트렌드를 익히려고 합니다.
1) Kestra
Kestra라는 툴이 다소 생소하게 느껴질 수도 있습니다. Airflow처럼 데이터 오케스트레이션을 수행하는 도구이지만, 단순한 대체제가 아니라 그래프 기반 설계에서 핵심이 되는 데이터 통합과 메타데이터 정리에 특화된 플랫폼입니다. "Airflow로도 가능하지 않을까?"라는 질문이 들 수 있지만, Kestra를 주목하는 이유는 단순한 스케줄링을 넘어서 도메인 전문가의 암묵지를 메타데이터로 추출해내고, 이를 정형화하는 과정에서의 커뮤니케이션 비용을 획기적으로 줄여준다는 점에 있습니다.
Kestra는 복잡한 플로우 구성이나 재배포 없이 간단한 YAML 설정만으로 비즈니스 로직을 정의할 수 있으며, GUI 기반의 코드 편집기와 직관적인 No-code 폼 제공으로 비IT 전문가도 손쉽게 플로우를 수정하고 실행할 수 있도록 설계되어 있습니다. 특히, 데이터 통합 과정에서 필연적으로 발생하는 다양한 이기종 스크립트나 환경 설정 문제도 컨테이너 기반의 격리된 실행 환경으로 해결하여, 팀 간 라이브러리 충돌이나 의존성 문제에서 자유롭습니다.
또한, Kestra는 비즈니스 로직과 오케스트레이션 로직을 명확히 분리하여 기존 스크립트를 그대로 사용할 수 있도록 하고, 개발자와 비개발자 간의 협업 경계를 자연스럽게 허물 수 있는 구조를 갖추고 있습니다. 즉, 도메인 전문가가 정의한 메타 정보를 그대로 IT 시스템에 반영할 수 있도록 함으로써, 그래프 설계의 출발점인 "의미 기반 메타데이터 정리"를 보다 민첩하고 효과적으로 실현할 수 있는 기반을 제공하는 것입니다.
https://kestra.io/docs/why-kestra#_5-separation-of-orchestration-and-business-logic
2) 그래프를 활용하는 대표적인 기업들 트렌드
기업에서 그래프를 활용하는 테크닉을 익혀야 '쓸 수 있는' 그래프에 대한 감을 익히게 됩니다. 기획을 하다보면 현실성과 동떨어진 아이디어가 나오기 마련인데, 이 아이디어가 과연 필드에서 쓰일지에 대한 고민을
ㄱ. Network science
Linkedin https://economicgraph.linkedin.com/blog
그래프가 구성된다면, 다음 단계는 각 그래프마다 특성을 정량화하고 이를 비즈니스에 연계짓는 작업이 필요합니다. 이 과정들과 논리들을 익히기 위해 저는 주로 Linkedin 블로그보곤합니다. 첫 회사에서 Network science 를 혹독하게 훈련받았던게 여기에서 빛을 발휘하네요.. 아직도 많이 어렵긴하지만, 겨우 따라갈 수 있는거 같습니다.
ㄴ. Graph Engineering
X(formly Twitter) https://blog.x.com/engineering/en_us/topics/open-source/2023/twitter-recommendation-algorithm
두말하면 입이 아플거 같은데요. 안에 코드를 보면 scala 가 있습니다.. 때문에, 엔진 구현 방식을 익히기위해 scala 스터디도 조금씩 하는 중이네요.. 하하.. 보다보면, 결국 분산처리까지 고민하게 되다보니 제가 모르는게 정말 많구나 라는걸 여지없이 깨닫고 스터디하는 편입니다. 이전에 pyspark 와 GraphFrames를 활용했을때가 좋았었네요. ^^...
ㄷ. System architecture & Graph Design
substack Vu Trinh , bytebytego
여러 채널들을 보긴하지만, 그중에서도 으뜸은 다음 두 채널 같네요. 특히 첨부한 Vu Trinh 글은 meta 에서 데이터 처리를 위해 OLAP , Graph 등을 어떻게 구성했는지에 대한 내용입니다. 그래프를 바로 적재하는 경우는 드물기 때문에 datalake 측면에서 어떻게 데이터를 처리하고 그 데이터 처리하는 파이프라인 중 Graph가 어디에 속해있는지 각 기업들마다 모두 디자인과 엔지니어링 방식이 다릅니다. 때문에, 다양한 디자인 패턴을 익히는게 중요하다라고 생각하여 자주 살펴보는 편입니다.
https://blog.bytebytego.com/about?utm_source=subscribe_email&utm_content=learn_more
주절주절 적다보니 또 글이 길어졌네요. 무튼 저는 요새 이렇게 지내고 있습니다. 저와 비슷한 고민을 하고 계시는 분들에게 이 글들이 도움이 되었으면하네요. 디테일과 트렌드 이 모든 방대한 것들을 모두 다 다루려다보니, 디테일한 글을 작성하지 못하고 있는데요. 연휴가 있는 기간때 글로 작성한다거나 외부 세미나에서 발표하는 형태 혹은 멘토링을 하는등의 형태로 최대한 지식들을 전달해보려고 노력하고 있습니다.
많이들 관심가져주시고 연락주심에 감사드립니다. 참고로 6월 말에는 GUG 세미나를 개최할 예정입니다. 한달 전 정도에 홍보는 하겠지만, 중간중간 내용이 궁금하거나 미리 신청을 원하시는 분들은 graphusergroup@gmail.com 으로 메일 부탁주시면 연락드리겠습니다. 이번에도 모시기 힘든 연사진분들을 여러분들을 기다리고 있습니다. 많은 기대 부탁드립니다!
