연구 데스크의 메모리 문제

I’m happy to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line exactly as you provided and preserve all formatting, markdown, and code blocks.

왜 증권사는 또 다른 대시보드가 아니라 뇌가 필요했는가

분석가가 책상 너머로 몸을 기울이며 묻는다: “XYZ Inc에 대한 현재 입장은 뭐죠? — 지난 분기에 뭔가를 제출한 그 회사 말이에요.” 이 질문에 답하는 데는 30초, 최대해도 1분 정도면 충분해야 한다. 그런데 그 이름을 담당하던 사람이 회사를 떠났다. 대신 이어지는 일은 작고 고통스러운 탐색이다. 누군가 블룸버그 터미널을 켜고, 또 다른 사람은 분명히 이메일로 보냈던 커버리지 노트를 찾기 위해 받은 편지함을 뒤진다. 세 번째 사람은 실적 발표 콜에서 나눈 대화를 기억하지만 전사본을 찾지 못한다. 열두 개의 브라우저 탭을 열고 25분이 지난 뒤, 파편들로부터 그림이 서서히 맞춰진다.

답은 언제나 존재했다. 단지 네 개의 시스템, 두 개의 메일함, 그리고 점점 신뢰가 떨어지는 한 분석가의 기억에 흩어져 있었을 뿐이다. 바로 그 순간 — 그 불필요한 탐색 — 이 프로젝트가 시작되는 지점이다.

시작

나는 전체 경력을 연구 분석가로 일해 왔습니다. 파이썬 코드를 한 줄도 써 본 적은 없지만, 일상 업무의 마찰을 해소하기 위한 인프라 구축에 항상 집중했습니다.

• Peer comps are cumbersome – Bloomberg와 우리 자체 추정 데이터베이스에서 데이터를 끌어오는 스프레드시트를 구축합니다.
• Updating PowerPoints sucks – 자동으로 새로 고칠 수 있는 차트 팩을 만들지만, Excel과 PowerPoint가 성경적인 수준으로 서로를 싫어하기 때문에 외부 서드‑파티 EXPENSIVE 플러그인을 사용해야 합니다.

컨텍스트 수집, 컨텍스트 전환, 그리고 언제나 완전한 정보 혼란 속에서 작업하는 것이 업무의 일부분처럼 보였습니다. 나는 원하는 모든 것을 원하는 시점에 제공해 줄 범용 연구 도구를 만들 시간도 지식도 없었습니다. 바로 그때, 최신 AI 코딩 도구가 등장했습니다.

현재 상황

이 글은 증권 회사를 위한 연구‑인텔리전스 플랫폼을 구축하는 일곱 부분 시리즈의 첫 번째 파트입니다. 저는 79개의 파일과 40 000줄이 넘는 코드가 한 번에 커밋되는 거대한 작업이 진행되는 시점에 이 글을 씁니다—그래프 스키마 정의부터 실시간 데이터 커넥터, 첫 번째 세대 AI 에이전트까지 모두 포함됩니다.

가능한 한 솔직하게 결정을 기록하려 합니다: 아키텍처 선택, 잘못된 방향 전환, 깔끔한 아이디어가 복잡한 현실과 충돌한 순간들. 이 첫 번째 장은 코드를 많이 다루지는 않습니다. 문제 자체와, 그 문제가 처음 예상했던 것보다 더 흥미롭고—그리고 더 고집스러웠던 이유에 대해 이야기합니다.

Source:

문제

증권사의 리서치 애널리스트들은 거의 눈에 보이지 않는 특정한 인지 부하 하에서 작업합니다. 그들은 머릿속에 커버리지 유니버스를 가지고 있습니다. 어느 기업이 실적 발표 시즌에 접어들고 있는지 알고 있습니다. 특정 발행사의 CFO가 6개월 전 통화에서 조심스럽게 말한 내용을 기억합니다. 주니어 동료가 팀에 합류하기 전 발생한 신용등급 변동을 떠올립니다.

이 지식은 실제이며 가치가 있습니다. 하지만 거의 전부가 비정형입니다.

물론 회사에는 도구가 있었습니다: 시장 데이터를 위한 터미널 접근, 외부 리서치 노트를 배포하는 플랫폼, 다양한 사이트(Bloomberg, FactSet 등)에서 제공되는 주식 알림. 데이터는 존재했고 우리는 모두 가지고 있었습니다. 그러나 그 사이를 연결해 주는 조직적 연결 고리는 없었습니다 — 시스템 경계를 넘는 질문을 할 방법도, 특정 시점에 회사에 대해 회사 전체가 알고 있는 내용을 끌어올리는 방법도 없었습니다.

보이지 않는 비용은 단일 조회가 낭비되는 것이 아니라, 매번, 모든 질문마다 애널리스트가 처음부터 맥락을 재구성해야 하는 누적적인 부담입니다.

• 이 애널리스트가 지난 6개월 동안 발표한 신용등급 변동은 무엇인가요?
• 우리 마지막 노트 이후 이 발행사가 제출한 주요 사건은 무엇인가요?
• 최근 실적 사이클에 들어가기 전 핵심 추정치 수정은 무엇이었나요?

이 질문들 각각에 대한 답은 존재했습니다. 하지만 빠르게 도달할 수 있는 경로는 없었고, 존재하는 경로는 길고 고통스러웠습니다.

이 시점에서 가장 흔히 떠오르는 해결책은 SaaS 도구를 도입하는 것입니다: Notion, Confluence, 더 나은 인트라넷, 기존 시스템 위에 얹은 고급 검색 레이어 등. 저는 그 방안을 진지하게 검토했습니다. 문제는 지식‑관리 도구가 문서와 페이지 — 이미 누군가가 합성해 놓은 인간이 만든 산출물 — 을 중심으로 설계된다는 점입니다. 우리가 다루고 있던 것은 전혀 다른 것이었습니다: 기업, 애널리스트, 등급, 사건, 제출서류, 노트, 채권 등 엔터티 간의 복잡한 관계망. 의미는 단일 문서에 있지 않고, 사물들 사이의 연결에 있었습니다.

검색 인덱스는 어떤 문서가 특정 회사를 언급하는지만 알려줍니다. 하지만 이 회사의 커버리지 애널리스트가 8개월 전에 교체됐고, 교체 이후 커버리지 강도가 감소했으며, 최근 세 개의 노트가 모두 실적 제출 일주일 이내에 발표됐고, 아직 공식적인 반응이 없는 중요한 사건이 지난 화요일에 발생했다는 사실은 알려주지 못합니다. 이것은 검색 문제가 아니라 그래프 문제입니다.

Into the unknown

나는 이 순간의 어지러움을 솔직히 말하고 싶다. 기존 부품을 조합하는 대신 맞춤형 그래프‑백엔드 플랫폼을 구축하기로 결정하는 것은 겸손한 약속이 아니다. 이는 스키마, 데이터 수집 파이프라인, 쿼리 레이어, 에이전트 레이어, API, 인터페이스를 모두 소유한다는 의미다. 시장 개장 전인 오전 7시 45분에 무언가가 고장 나면, 호출을 받는 사람은 바로 당신이다. 이 프로젝트가 실제로 프로덕션에까지 이르게 된다면 내가 떠안게 될 책임을 생각하면 몸이 아프다.

나는 이것이 올바른 선택인지, 아니면 단순히 범위 확장의 변명인지 증거를 찾으러 나섰다. 팔란티어가 기관 지식 관리에 어떻게 활용했는지 공부했고, 코그니트가 에너지 부문에서 산업 지식 그래프에 어떻게 접근하는지도 살펴보았다. Databricks의 어떤 점이 천재적이었는가? 나는 이들 기업이 그래프‑기반(및 기타) 접근 방식을 사용해 데이터를 이해하고, 더 중요한 연결을 파악한 방법에 대해 찾을 수 있는 모든 것을 읽었다.

To be continued…

나는 구조적인 관찰에 계속 돌아섰다: 재무 연구 지식은 근본적으로 관계적이며, 관계 지식은 평면 구조에 저장될 때 퇴화한다. 연구 노트는 단순히 문서가 아니다. 분석가, 기업, 등급, 날짜, 추정치 집합, 그리고 시장 상황 사이의 관계다. 그 관계를 없애면 PDF가 된다. 관계를 유지하면 우리가 추론할 수 있는 무언가가 된다.

Early schema sketches were humbling

도메인을 모델링하려는 첫 시도는 깔끔해 보였다 — 기업, 분석가, 노트, 이벤트 — 하지만 실제 질문에 답하려고 시도하면서 한계가 드러났다. 스키마는 분석가가 기업을 담당하고 있는지와 이미 담당했던지를 구분하지 못했다. 현재 유효한 등급과 대체된 등급을 구분할 수도 없었다. 시간적 유효성을 모델링하는 것은 정말 어렵고, 나는 이를 과소평가했다.

또한 데이터 커넥터가 도메인에 대해 가르쳐 줄 양을 과소평가했다. 규제‑제출 피드와의 통합을 구축하면서 *“중요 사건”*이 이론적으로는 무엇이고 실제로는 무엇인지 이해해야 했다. 제출물 통합은 이벤트가 분류되는 방식과 분석가가 실제로 사용하는 방식 사이의 격차를 드러냈다.

Early naive approach — the code that never shipped

# Flattening event data into a document store
def store_event(event: dict) -> None:
    doc = {
        "company": event["issuer_name"],
        "date": event["published"],
        "type": event["category"],
        "text": event["body"]
    }
    search_index.add(doc)

# The problem: we've lost the relationship between the event
# and the company's coverage record, analyst assignment,
# and any notes published in response to it.
# Querying "what did we do after this event?" becomes impossible.

그 코드는 실제 시스템에 들어가지 못했지만, 작성하면서 왜 안 되는지 정확히 알 수 있었다.

What worked

모든 것을 열어준 결정은 처음부터 그래프‑네이티브 모델링을 고수한 것이었다. 그래프를 관계형 데이터 위에 얹는 레이어로 취급하지 않았다.

궁극적으로 안정된 노드 타입 — Company, Analyst, Sector, CoverageRecord, ResearchNote, MaterialEvent, Filing, BondIssue, EstimateSnapshot — 은 상향식으로 설계된 것이 아니다. “분석가들이 실제로 어떤 질문을 하는가?” 라는 질문을 던지고 역으로 도출해냈다. 각 노드 타입은 분석가가 사고하는 대상을 나타낸다. 각 엣지 타입은 질문에 대한 답을 바꾸는 관계를 나타낸다.

# Excerpt from graph/schema/nodes.py — illustrating the principle
# A CoverageRecord isn't just a link between Analyst and Company.
# It carries its own temporal properties and state.

@dataclass
class CoverageRecord:
    analyst_id: str
    company_id: str
    rating: str
    target_price: float | None
    currency: str
    coverage_start: date

Source: …

overage_end: date | None      # None = currently active
    is_primary: bool
    last_note_date: date | None

coverage_end 필드는 겉보기엔 사소해 보이지만, 이를 구현하기 위해 세 번의 스키마 반복 작업이 필요했습니다. 이 필드가 없으면 다음 질문에 답할 수 없습니다:

• “현재 애널리스트 이전에 누가 이 회사를 담당했나요?”
• “커버리지는 얼마나 연속적인가요?”
• “우리 데이터베이스에 있는 회사가 90일 동안 언급되지 않은 적이 있나요?”

스키마는 무엇이 중요한가에 대한 논쟁입니다. 각 필드는 해당 정보가 앞으로도 유지될 가치가 있음을 주장하는 것입니다. 스키마를 진정으로 올바르게 설계하는 것이 기초 단계에서 가장 지적 부담이 큰 작업임이 밝혀졌습니다.

에이전트 아키텍처도 유사한 원칙을 따랐습니다. 하나의 범용 어시스턴트 대신, 시스템은 전문화된 에이전트들을 필요로 했습니다:

• 회사 스냅샷 에이전트 – 현재 상황을 완전하게 조합합니다.
• 실적 준비 에이전트 – 콜 전에 필요한 모든 정보를 모읍니다.
• 중요 이벤트 모니터 – 규제 서류를 감시하고 적절한 애널리스트에게 전달합니다.

각 에이전트는 좁은 역할을 수행하지만, 그래프가 각 좁은 에이전트에게 전체 관계 컨텍스트에 대한 접근을 제공하므로, 집중된 질문에도 풍부한 답변을 얻을 수 있습니다.

이것이 바뀐 점

이 기반을 마련한 커밋—79개의 파일, 40 000줄 이상—은 이 프로젝트가 앞으로 보게 될 가장 밀집된 단일 푸시일 가능성이 높습니다. 보통은 경고 신호이지만, 여기서는 지식 그래프의 절반만 만들 수 없다는 현실을 반영합니다. 스키마, 커넥터, 라이터, 쿼리 레이어가 하나의 시스템을 이루며 함께 작동합니다.

제가 다르게 할 점은 데이터‑커넥터 작업을 더 일찍 시작하고 이를 도메인 연구로 취급하는 것이었습니다. 각 커넥터는 다루는 데이터에 대해 무언가를 가르쳐 줍니다. 예를 들어, 채권 데이터 통합은 커버리지 유니버스의 고정수익 측면을 어떻게 모델링해야 하는지에 대한 이해를 바꾸어 놓았습니다. 먼저 이 통합을 수행했다면 더 나은 초기 스키마를 설계했을 것입니다.

깊은 교훈: 지식 인프라는 결코 순수한 기술 문제만은 아닙니다. 사람들의 사고 방식, 그들이 언제 어떤 정보를 필요로 하는지에 관한 문제입니다. 올바른 아키텍처는 실제 인지 작업을 반영합니다—고립된 채로 기술적으로 우아한 것이 아니라.

대시보드, 에이전트, API—이들은 연구 데스크가 될 수 있는 아이디어의 표현입니다. 그래프 자체가 그 아이디어입니다.

다음 내용: 그래프‑데이터베이스 선택 과정은 기술적 결정처럼 보였지만, 실제 운영 현실에 관한 질문이었으며 그 답은 저를 놀라게 했습니다.

조직 내에서 현재 누군가의 머리 속에만 존재하는 가장 가치 있는 지식은 무엇이며, 이를 바꾸기 위해 무엇이 필요할까요?

Follow along — Part 2 drops soon

Part 1 of 7 in the series “Building a research hive”