Go와 Neo4j로 Financial Times는 어떻게 속도를 낼 수 있었나

편집자 주: 이 프레젠테이션은 Financial Times의 Dan Murphy가 제공했습니다.그래프커넥트 유럽2016년 4월. 그가 다룬 내용을 간단히 요약하면 다음과 같아요.

• 특히 Financial Times의 경우 인쇄에서 디지털로의 미디어 전환
• FT 팀이 실패한 Semantic Linked Data Platform에서 벗어난 이유
• Go 및 Neo4j 그래프 기술을 사용하여 프로젝트를 전환한 방법
• Financial Times에서 Go 및 Neo4j를 사용하는 향후 계획

–

오늘 이야기할 내용은 파이낸셜 타임즈가 우리에게 맞지 않는 오래된 기술을 버리고 Neo4j와 Go를 통해 완전히 새로운 데이터베이스를 수용한 이야기예요.

저는 Financial Times에서 코드를 작성하고 있는데, 실패했던 프로젝트 중 하나에 대한 개요를 여러분에게 알려 드리려고 해요. 정말 열심히 노력했음에도 불구하고 프로젝트는 제대로 진행되지 않았거든요. 이 프로젝트는 Financial Times의 디지털 미래에 중요한 부분이었기 때문에, 거의 재앙이 될 뻔 했죠.

저는 IT 분야에서 꽤 오래 일해왔기 때문에, 성공할 조짐이 보이지 않더라도 프로젝트를 계속 진행해서 성공시키려는 경향이 있어요. 하지만 이번 프로젝트를 위해 우리는 우리가 달성하고자 하는 것이 무엇인지, 그리고 우리가 사용하고 있는 기술을 자세히 살펴보고 과감한 변화를 받아들이기로 어려운 결정을 내렸어요.

일반적으로 IT 세계에서 변화를 줄 때는, 문제가 발생하면 정확히 무슨 일이 일어났는지 알 수 있도록 한 번에 하나씩 변경하잖아요. 그런데 우리는 그걸 무시하고 1년이 넘는 작업을 버리고, 약 3개월에 걸쳐 다른 프로그래밍 언어로 다시 작성했어요. 그랬더니 실패했던 프로젝트가 제대로 작동하는 프로젝트로 바뀌었답니다.

The Financial Times: 인쇄에서 디지털로의 전환

파이낸셜 타임즈(Financial Times)에 대해 잘 모르시는 분들을 위해 설명하자면, 우리는 1888년 런던에서 창간된 신문이에요. 2010년에 파이낸셜 타임즈는 소비자들이 콘텐츠에 접근하는 방식에 변화가 있다는 것을 알아채기 시작했죠.

2012년에 그들은 무료 페이월과 HTML5 웹 앱을 출시하기로 결정했고, 그 결과 우리의 기본 수익이 종이 구독 기반에서 디지털 구독 기반으로 전환되었어요. 오늘날 우리는 종이 구독보다 디지털 구독을 통해 훨씬 더 많은 수익을 창출하고 있답니다.

디지털 구독을 이용하면 더 많은 일을 할 수 있어요. 이제 우리는 이전과는 완전히 다른 방식으로 콘텐츠를 표시해야 하는 대화형 그래픽, 팟캐스트 및 비디오를 가지고 있어요. 다음은 현재 웹사이트에서 가져온 몇 가지 샘플 페이지예요.

왜 이런 모델에서 벗어나려고 했을까요? 단일체였기 때문에 새로운 API를 통해 다른 제품을 추가하려고 할 때마다 어려움에 부딪혔거든요. 이는 현재 웹사이트와 그 아래 플랫폼이 앞으로는 제대로 작동하지 않을 거라는 의미였죠. 그래서 상황을 바꿔야 한다고 생각했어요.

실패로 끝난 Semantic Linked Data Platform

약 18개월 전에 용감한 개발자 그룹이 Java로 Semantic Linked Data Platform을 구축하기 위한 여정을 시작하기로 결정했어요. 이런 플랫폼을 선택한 이유는 컨셉, 콘텐츠, 조직, 사람 등 생각할 수 있는 모든 유형의 정보를 연결해서 정말 풍부한 경험을 제공하고 싶었기 때문이에요.

당시에는 이게 맞는 선택 같았죠. 하지만 슬프게도 모두가 여정의 끝까지 도달하지는 못했어요. 저는 지난 10월에 팀에 합류했는데, 도착한 지 얼마 지나지 않아 새로운 의미 플랫폼이 제대로 구현되지 않아서 프로젝트가 중요한 시점에 도달했다는 걸 알게 되었죠.

우리가 직면한 주요 문제는 플랫폼에 데이터를 로드하는 데 걸리는 시간이었고, 이는 주로 기본 기술 때문이었어요. 그래서 이 여정에서 무엇을 얻을 수 있을지 둘러봤을 때, 이 플랫폼을 구축하기 위해 의존했던 장비들이 오히려 우리의 속도를 늦추고 있다는 걸 깨달았어요.

예를 들어, 데이터 모델링은 일반적으로 프로젝트와 관련된 사람들이 수행했지만 프로젝트 내부에서 직접 하지는 않았어요. 데이터 모델링은 OWL(WC3 Web Ontology Language)에서도 수행되었는데, 이걸 제대로 사용하려면 많은 훈련과 시간이 필요한 어렵고 전문적인 기술이에요.

하지만 우리는 실제로 연결된 데이터 플랫폼을 구축하려는 게 아니라는 걸 깨달았어요. 대신, 이미 가지고 있는 데이터를 사용해서 콘텐츠를 연결하는 더 나은 방법을 찾아야 했죠. 여기에는 기사를 가져오고, 처리하고, 개념을 추출하고, 기사에 개념을 추가하고, 기사를 관련 개념과 연결하는 작업이 포함돼요. 연결된 데이터 플랫폼으로는 이걸 효과적으로 수행할 수 없었죠. 그래서 Graph Database가 필요했던 거예요.

우리가 구축한 프로젝트가 우리에게 적합하지 않더라도, 이미 아키텍처를 통해 견고한 기반을 구축해뒀어요. 여기에는 시스템의 다른 부분에 영향을 주지 않고 교체할 수 있는 독립적인 단위인 마이크로서비스라고 하는 유연한 개별 구성 요소 집합이 포함되었죠.

Neo4j 및 Graph 기술로 프로젝트 전환

시작하기 위해 우리는 본사에서 벗어나 일주일 동안 방에 틀어박혀 다양한 기술 조합을 시험해 봤어요. 우리는 RDF 저장소와 Java라는 도구를 테이블 위에 올려놓고, RDF 플랫폼을 변경해서 이게 우리를 방해하는 요소인지 확인했죠.

하지만 우리는 마이크로서비스를 사용하고 있었기 때문에 몇 가지 추가적인 옵션을 탐색하기로 결정했고, 그 결과 와 를 사용해보게 되었어요.

우리 중 누구도 Go나 Neo4j에 대한 사전 경험이 없었지만, 그 주 동안 우리에게 무엇이 도움이 되는지 알아보기 위해 다양한 트리플 스토어와 Graph Database에 코드를 작성해 봤고, Neo4j와 Go 모두에서 솔루션을 찾았어요. Go에 대해 우리가 좋아했던 점 중 하나는 Java보다 훨씬 적은 코드를 작성해도 되고 사용하기 매우 쉬워서 작업을 매우 빠르게 시작하고 실행할 수 있었다는 거예요.

또한 Neo4j에 Java를 작성할 때 사용할 드라이버 유형을 결정해야 했어요. JDBC 드라이버나 다른 유형의 라이브러리를 사용해야 할까요, 아니면 REST 인터페이스를 직접 사용해야 할까요? 우리는 JDBC와 REST를 모두 시도했지만 코딩 양이 너무 많았고 드라이버 제한 사항도 발견했어요. 결국 네오이즘 바둑 라이브러리를 선택했는데, 이건 본질적으로 Neo4j와 대화하기 위한 드라이버에요.

그 주 이후 우리는 기술을 연마하고, 기술을 연습하고, 개념 증명 작업을 프로덕션에 적용하는 데 시간을 보냈어요. 다음은 그래프의 매우 간단한 Node에요.

이건 Apple이라는 회사를 나타내는 건데요, 사물, 개념, 조직, 회사, 공개 회사 같은 몇 가지 레이블이 붙어있죠. UUID 같은 속성도 있고요. 하지만 Graph Database 안의 데이터가 정보의 유일한 소스는 아니에요. 다른 시스템에서 오는 데이터도 있는데, 그 중 하나가 TME랍니다.

처음에는 그래프에 다른 식별자를 간단한 속성으로 넣기 시작했어요. 그런데 이게 그래프의 객체 루트를 오염시키는 결과를 낳아서 좀 혼란스러웠죠. 모델을 통해 반복하는 기능은 Neo4j에서 정말 마음에 들었던 부분 중 하나였거든요.

다음으로 시도한 건 "식별자"라는 우산 아래 속성을 묶는 거였어요. 이렇게 하면 UUID에 추가로 포함할 수 있다고 생각했죠. 당시에는 좋은 생각 같았는데, 결과적으로는 아니었어요.

이런 식으로 속성을 그룹화하면 인덱스 생성 및 검색을 효과적으로 활용할 수 없었거든요. 우리가 알고 있는 식별자와 다른 시스템이 알고 있는 식별자를 매칭하고 싶었는데, 모든 걸 하나의 카테고리로 묶어버리니 그렇게 할 수가 없었어요.

새로운 Node를 그래프에 추가하는 게 망설여졌지만, 결국 그렇게 했을 때 많은 문제가 해결됐어요.

위 Node 중 일부는 "실제" 엔터티가 아니지만, 그래프의 Node로 해당 개념의 표현을 추가하면 Node 간의 Relationships를 구축할 수 있어요. 또한 Label을 적용해서 LEI(법인식별기호)와 TME 식별자를 모두 빠르게 요청할 수 있었죠.

이 다이어그램에는 Apple과 자회사, 관련 인물 또는 기사와 같은 다른 엔터티 사이에 존재하는 추가 Relationships는 표시되지 않았지만, 이제는 이런 유형의 링크를 생성할 수 있게 되었답니다.

아래는 Go에서 두 가지 구조를 표현한 거예요. Thing은 기본 표현 구조이고, Brand는 구조입니다:

Brand 구조는 몇 가지 추가적인 속성을 포함하는 복합 구조인데, 다른 곳에서도 사용하는 패턴이에요. API URL은 데이터가 직렬화되어 전송되는 방식이고, 이는 기본적으로 API에 사용하는 공개 인터페이스죠.

그리고 Graph Database의 데이터를 전송할 수 있는 구조로 내보내는 효율적인 방법을 찾아야 했어요. 저희 솔루션은 또 다른 Neo4j 스타일, 즉 드라이버 연결을 구축하고 쿼리를 실행하는 형태로 나왔답니다.

하지만 단순히 Node를 읽는 대신, Node에 직접 매핑되는 Brand 구조를 만들었어요. 이렇게 하면 직렬화하기도 훨씬 편하죠. 서로 다른 두 객체 간에 복사해야 하는 DTO 패턴을 거치지 않아도 되니까요.

또 하나 짚고 넘어가야 할 부분은 유형의 계층 구조인 labels에요:

그래서 공기업, 다른 회사, 조직들이 labels라는 하나의 끈으로 연결되는 거죠. 그리고 그 `labels`를 보내는 함수도 있고요.

만약 신주에서처럼 Node를 되찾았다면, Label을 검색하기 위해 데이터베이스를 다시 호출해야 했을 거예요. 성능을 높이기 위해 API 호출마다 3번의 추가 호출을 절약해서, 더 적은 코드로 고성능 데이터베이스를 만들 수 있었답니다.

하지만 이게 쉬웠다는 건 아니에요. 수정된 Neo4j에서 중복된 데이터 비트를 반환하는 버그를 발견하기도 했거든요.

이건 데이터베이스나 데이터 액세스 시스템을 만들 때 어려운 점 중 하나를 상기시켜 주는 유용한 정보인데요. 데이터베이스 기능뿐만 아니라, 어떤 결과를 반환해야 하는지도 알아야 한다는 거죠. 반환된 데이터의 무결성을 검증하는 건 정말 중요해요.

Neo4j에서 아쉬운 점 중 하나는 날짜 및 시간 지원이에요. 다들 정수나 일종의 긴 끝으로 내용을 작성하거나 날짜 트리를 구축한 다음 전후에 작업을 수행할 수 있는 것처럼 보이거든요. 이걸 1급 언어로 갖는다면 훨씬 편리할 텐데요.

결론

3개월 동안 정말 많은 걸 이뤄냈어요. 12개월 동안 작성한 코드를 버리고 15개 이상의 Microservice를 다시 작성했고, 새로운 API와 Microservice도 만들었죠. 저희는 4명 정도의 작은 개발팀인데, 데이터를 클라우드에 유연하게 배포하고 컨테이너에 첫 배포를 하는 것을 포함해서 매주 2개 이상의 결과물을 만들어냈어요.

Neo4j와 Go를 함께 사용하는 모험을 하지 않았다면 아직도 코드를 짜고 있었을 거라고 모두가 입을 모아 말해요. 그 조합이 저희에게 정말 잘 맞았던 거죠. 계산된 위험을 감수하고 모든 걸 버릴 각오가 되어 있었거든요.

만약 여러분이 어려운 프로젝트를 맡고 있거나 새로운 도전을 시작하고 있다면, 얼마나 과감해질 수 있는지, 얼마나 많은 변화를 받아들일 수 있는지 한번 확인해보시길 추천드려요. 저희에게는 효과가 있었고, 지금은 그 어느 때보다 더 힘이 나고 세상을 컨트롤할 수 있다는 느낌이 들어요.

Dan의 강연에서 영감을 받으셨나요? 등록하려면 아래를 클릭해서 GraphConnect San Francisco에서 세계 최고의 그래프 기술 전문가들이 진행하는 더 많은 프레젠테이션, 강연, 워크숍을 확인해보세요.

7월 31일까지 얼리버드 티켓 가격은 $99이에요!

• Data Modeling
• Graph Technology
• GraphConnect
• Microservice
• Neoism
• owl
• Semantic

---

에이치시스템즈의 LogTree는 Neo4j 기반 GraphRAG 플랫폼으로, 데이터를 자동으로 지식그래프화하고 자연어 질의로 즉시 답을 제공합니다.

👉 에이치시스템즈 홈페이지