Semantic Layer: DB에 모델만 붙였다 실패한 Franklin Templeton이 주식 리서치를 다시 짠 방법
Franklin Templeton은 주식 리서치부터 애널리스트의 1차 분석과 리서치·리스크·컴플라이언스·트레이딩 관점을 포트폴리오 매니저가 한 번에 비교하는 AI 워크플로를 만들고 있습니다. DB에 모델만 연결한 첫 시도는 데이터 관계를 몰라 실패했고 에이전트와 Semantic Layer를 더해 방향을 바꿨습니다. OpenAI 고객 사례이며 수치는 공개하지 않았습니다.
Franklin Templeton은 데이터를 DB에 모아 모델을 붙이는 것만으로는 투자 질문에 답할 수 없다는 것을 먼저 겪었습니다. 그래서 데이터의 뜻과 연결을 정의한 Semantic Layer와 에이전트를 더해 주식 리서치 워크플로를 다시 짜고 있습니다. 따라 하려면 모델을 고르기 전에 종목, 보유, 지표, 위험이 서로 어떻게 이어지는지부터 적어 두고 실험이 운영으로 넘어가는 관문을 정해야 합니다.
요약
Franklin Templeton은 미국의 대형 자산운용사입니다. 2026년 11월 5일 OpenAI가 고객 사례로 이 회사의 투자 리서치 AI 작업을 소개했고 다음 날 Unite.AI가 이를 보도했습니다. 이 노트는 OpenAI 원문을 직접 열 수 없어 Unite.AI 보도로 내용을 확인했습니다. 출발점은 주식 리서치입니다. 애널리스트는 아이디어를 내거나 기존 보유 종목을 포트폴리오 매니저(PM)에게 갱신하기 전에 1차 종목 분석을 하고 실적 콜을 검토하고 사업부마다 경쟁사를 살핍니다. 여기에 리서치, 리스크, 컴플라이언스, 트레이딩이 각자 다른 관점을 보탭니다. 회사는 이 관점들을 한데 모아 의사결정자가 아이디어의 논리와 위험을 함께 보게 하려 합니다. 상장시장 투자 담당 SVP인 Katrina Dudley는 연구 과정을 보조하는 단계에서 투자 리서치 워크플로 자체를 다시 설계하는 단계로 옮겨 갔다고 설명합니다.
첫 시도는 실패했습니다. 데이터를 데이터베이스에 넣고 모델을 연결했지만 필요한 답이 나오지 않았습니다. 모델이 데이터끼리 어떻게 맞물리는지 몰랐기 때문입니다. 회사는 에이전트와 Semantic Layer(회사 데이터가 무엇을 뜻하고 어떻게 연결되는지 정리한 구조화된 모델)를 더해 방향을 바꿨습니다. 지금은 Codex를 포함한 여러 도구로 Connected Intelligence Layer(데이터를 도구 안으로 가져와 사용자에게 통찰을 띄워 주는 층)를 만들고 있습니다. 목표는 신뢰할 수 있는 커넥터, 포트폴리오와 워크플로 문맥, 에이전트 기능을 묶은 통제된 재사용 기반입니다. 이 기반은 아직 만드는 중이며 사용자 수나 비용, 정확도 같은 수치는 공개하지 않았습니다. 아래에서는 이 구조를 다섯 가지 메커니즘으로 나누고 실제로 돌릴 때 필요한 기술·현업 디테일을 덧붙입니다.
핵심 메커니즘
Semantic Layer: 모델에게 데이터의 뜻과 연결을 먼저 알려 준다
Semantic Layer는 표와 열 이름 대신 업무 용어로 데이터를 설명하는 층입니다. “종목”, “발행사”, “펀드 보유 비중”, “컨센서스 대비 실적” 같은 개념을 정의하고 개념끼리 어떻게 이어지는지(종목은 발행사에 속하고 펀드는 종목을 일정 비중으로 보유한다)를 적어 둡니다. 질문이 들어오면 에이전트는 이 정의를 보고 어느 원천의 어느 값을 엮어야 하는지 정합니다. 그래서 모델이 표 구조를 추측하지 않아도 됩니다.
Franklin Templeton의 첫 시도가 바로 이 층이 없는 상태였습니다. 데이터는 한곳에 모였지만 모델은 관계를 몰랐고 회사는 답이 쓸 만하지 않았다고 밝혔습니다. 원천이 하나이고 질문이 단순하면 이 층 없이도 됩니다. 반대로 리서치, 보유, 리스크, 거래 데이터를 엮어야 하는 투자 질문에서는 이 층이 먼저 있어야 합니다.
작은 예시(가상): PM이 “우리 펀드에서 비중이 큰 반도체 종목 가운데 최근 실적 콜에서 수요 둔화를 언급한 곳은?”이라고 묻는다고 합시다. 답하려면 보유 데이터, 업종 분류, 실적 콜 요약을 이어야 합니다. Semantic Layer에 세 개념과 그 연결 키가 정의돼 있으면 에이전트는 한 번에 엮습니다. 없으면 모델은 열 이름이 비슷한 표를 골라 그럴듯하지만 틀린 답을 냅니다.
Connected Intelligence Layer: 커넥터·문맥·에이전트를 묶은 재사용 기반
Semantic Layer가 뜻을 정의한다면 Connected Intelligence Layer는 그 정의를 실제 도구에 꽂는 층입니다. 원문은 이 층이 데이터를 도구 안으로 가져오고 사용자에게 통찰을 띄워 준다고 설명합니다. 구성 요소로는 신뢰할 수 있는 커넥터(Trusted Connectors), 포트폴리오 문맥, 워크플로 문맥, 에이전트 기능을 듭니다. 핵심은 재사용입니다. 팀마다 따로 데이터를 붙이지 않고 한 번 승인된 연결과 정의를 여러 워크플로가 같이 씁니다.
이 층을 짓는 데 Franklin Templeton은 OpenAI의 코딩 에이전트 Codex와 다른 도구를 함께 씁니다. 주식 리서치에서 먼저 기반을 다지고 Dudley의 장기 목표는 애널리스트부터 투자 그룹 리더까지 같은 기반을 쓰게 하는 것입니다. 워크플로가 하나뿐이라면 이렇게 넓게 지을 필요가 없습니다. 같은 데이터를 여러 팀이 서로 다른 목적으로 쓸 때 효과가 큽니다.
네 관점 비교: 리서치·리스크·컴플라이언스·트레이딩을 PM 한 화면에
지금 투자 아이디어 하나에는 여러 부서의 판단이 따로 붙습니다. 리서치는 투자 논리를, 리스크는 하방 위험을, 컴플라이언스는 규정 저촉 여부를, 트레이딩은 실제로 사고팔 수 있는지를 봅니다. Franklin Templeton은 이 관점들을 결합해 의사결정자가 아이디어의 논리와 그 위험을 함께 평가하게 하려 합니다. Dudley는 위험을 미리 짚어 두는 일이 “makes for a more informed investment decision”이라고 말했습니다.
작동은 이렇게 그려 볼 수 있습니다. 애널리스트의 1차 분석이 입력으로 들어가면, 관점마다 같은 Semantic Layer를 읽는 에이전트가 자기 관점의 점검 결과를 냅니다. PM 화면에는 이 결과가 같은 틀로 나란히 놓입니다. 관점별 항목은 아래 표처럼 가상으로 잡았습니다. 원문은 네 관점을 결합한다는 목표만 밝혔고 각 관점이 무엇을 내는지는 공개하지 않았습니다.
다양성 우선 설계: 선호 학습이 만드는 쏠림을 막는다
많은 AI 도구는 사용자가 좋아하는 것을 학습해 비슷한 자료를 더 보여 줍니다. 원문은 한 리서치 제공사를 선호하는 투자자라면 그 제공사 리포트를 계속 더 받게 되는 경우를 예로 듭니다. Franklin Templeton은 이렇게 좁아지는 것을 편향의 위험으로 봅니다. 그래서 애널리스트와 PM이 다양한 리서치와 의견을 보게 하고 투자 논리 옆에 위험을 함께 띄우는 쪽으로 설계합니다.
이 원칙은 검색과 추천 단계에 규칙으로 들어가야 작동합니다. 사용자 클릭만으로 순위를 매기지 않고 답에 들어가는 근거가 몇 개 제공사·관점에서 왔는지를 따로 셉니다. 개인 생산성 도구라면 개인화가 편합니다. 투자 판단처럼 확증 편향이 비용이 되는 업무에서는 다양성을 기본값으로 둡니다.
실험에서 운영으로: 해커톤·실습 랩·AI 챔피언과 세 관문
사람 쪽 장치도 셋입니다. 해커톤에서는 전문가와 투자 실무자가 짝을 이뤄 Codex로 자기 도구를 직접 만듭니다. 새 기술이 나오면 곧바로 실습 랩을 열어 그 기술이 업무에 맞는지 팀이 시험합니다. 투자 AI 챔피언(Investment AI Champions)은 이렇게 나온 실험을 운영 수준의 워크플로로 옮기는 일을 맡습니다.
경영진은 정해진 위험 가드레일 안에서 실험을 권하고 모든 시도가 성공하지는 않는다고 받아들입니다. 대신 실패한 시도도 역량을 키우고 다음 결정에 쓸 통찰을 남겨야 한다는 것이 Dudley의 설명입니다. 실험이 운영 도구가 되려면 보안 검토, 전문가 지원, 데이터 계약(데이터 원천의 사용 조건과 책임을 정한 약속)을 거칩니다. 회사는 이렇게 아낀 시간으로 애널리스트가 현장에 더 나가 전문가, 실무자, 비상장 기업 경영진을 만나고 그 통찰을 팀에 가져오기를 바랍니다.
통념과 다른 주장
흔히 이렇게 봅니다데이터를 한곳에 모아 LLM을 연결하면 사내 데이터에 대한 질문에 답할 수 있다.
저자는 이렇게 봅니다데이터를 모으고 모델을 붙이는 것만으로는 부족합니다. 모델이 데이터의 뜻과 연결을 알아야 하므로, 에이전트와 Semantic Layer를 더해야 쓸 만한 답이 나옵니다.
근거Franklin Templeton의 첫 시도는 DB에 모델을 연결한 방식이었고 모델이 데이터 관계를 이해하지 못해 필요한 답을 내지 못했습니다.
흔히 이렇게 봅니다AI 도구는 사용자의 선호를 학습해 맞춤 자료를 보여 줄수록 좋다.
저자는 이렇게 봅니다투자 리서치에서는 선호 학습이 시야를 좁히는 편향이 됩니다. 다양한 리서치와 의견, 그리고 위험을 함께 보여 줘야 합니다.
근거한 제공사를 선호하는 투자자가 그 제공사 리포트만 더 받게 되는 예를 들어, 회사는 다양성과 위험 표시를 설계 원칙으로 삼았습니다.
저자가 든 사례
Franklin Templeton 주식 리서치: 연결에서 의미 정의로
- 상황: 애널리스트의 1차 분석, 실적 콜 검토, 경쟁사 조사와 리서치·리스크·컴플라이언스·트레이딩의 관점이 따로 흩어져 PM에게 전달됐습니다. 데이터를 DB에 넣고 모델을 붙인 첫 시도는 모델이 데이터 관계를 몰라 필요한 답을 내지 못했습니다.
- 한 일: 에이전트와 Semantic Layer를 더했고 Codex 등으로 커넥터·포트폴리오 문맥·워크플로 문맥·에이전트 기능을 묶은 Connected Intelligence Layer를 짓고 있습니다. 해커톤, 실습 랩, 투자 AI 챔피언으로 실험을 운영으로 옮기고 보안 검토, 전문가 지원, 데이터 계약을 관문으로 둡니다.
- 결과: 원문은 기반을 구축하는 중이라고 설명하며 사용자 수, 비용, 시간 절감 같은 수치는 밝히지 않았습니다. 효과에 대한 설명은 OpenAI 고객 사례에 실린 회사 측 설명입니다.
- 연결: Semantic Layer, Connected Intelligence Layer, 네 관점 비교, 다양성 우선 설계, 실험에서 운영으로까지 다섯 메커니즘 전부.
기술 디테일: 리서치용 Semantic Layer와 관점별 에이전트를 직접 만든다면
아래 필드명, 설정값, 기준은 실행 제안이자 가상 예시입니다. Franklin Templeton이 밝힌 구현이 아닙니다.
Semantic Layer를 정의하려면 개념을 YAML이나 JSON으로 적고 버전을 관리합니다. 시작은 30~50개 개념이면 충분합니다. 개념마다 업무 정의, 물리 원천(테이블·열), 연결 키, 계산식, 데이터 소유자, 갱신 주기를 둡니다. 정의가 두 개 이상인 지표(예: 순이익, 조정 순이익)는 이름을 나누고 어느 쪽을 기본으로 쓸지 적습니다. 모델은 질문을 받으면 먼저 이 정의에서 필요한 개념을 고르고 그다음 SQL이나 API 호출을 만듭니다.
{
"entity": "holding",
"definition": "펀드가 특정 기준일에 보유한 종목과 비중",
"source": {"table": "pm.positions_daily", "keys": ["fund_id", "security_id", "as_of"]},
"relations": [
{"to": "security", "via": "security_id"},
{"to": "fund", "via": "fund_id"}
],
"metrics": [{"name": "weight_pct", "formula": "market_value / fund_nav * 100"}],
"owner": "portfolio-analytics",
"refresh": "daily 07:00",
"version": 3
}관점별 에이전트는 같은 출력 스키마를 씁니다. 리서치, 리스크, 컴플라이언스, 트레이딩 에이전트 4개가 모두 perspective, stance(지지·중립·우려), points(근거 문장과 source_id), risks, open_questions를 채우게 합니다. 구조화 출력(JSON 스키마 강제)으로 받고 temperature는 0~0.2로 둡니다. 같은 입력으로 3회 돌려 stance가 갈리면 화면에 “판단 갈림”을 표시합니다. 근거 문장에 source_id가 없으면 답에서 뺍니다.
다양성 원칙을 숫자로 점검하려면 답에 쓰인 근거의 제공사 분포를 셉니다. 한 제공사 비중이 60%를 넘거나, 반대 의견(stance가 다른 근거)이 하나도 없으면 검색을 넓혀 다시 찾습니다. 사용자 클릭 이력은 순위에 쓰지 않거나, 쓰더라도 상위 5건 가운데 2건은 다른 제공사로 채웁니다.
에이전트 권한은 읽기 전용에서 시작합니다. 주문, 한도 변경처럼 되돌리기 어려운 행동은 넣지 않습니다. 컴플라이언스 에이전트는 제한 종목 목록을 조회만 하고 판정은 담당자가 합니다. 모든 호출은 질문, 사용한 개념, 쿼리, 응답, 모델 버전을 로그로 남깁니다.
| 막히는 경우 | 증상 | 대응 |
|---|---|---|
| 개념 정의가 부서마다 다름 | 같은 지표가 팀마다 다른 값 | 소유자 한 명을 정하고 별칭은 aliases로만 허용 |
| 모델이 정의에 없는 표를 씀 | 쿼리에 미등록 테이블 | Semantic Layer에 등록된 원천만 접근 권한 부여 |
| 관점별 답이 서로 모순 | 리서치 지지, 리스크 강한 우려 | 숨기지 않고 나란히 표시, PM이 판단 |
| 실적 콜 요약이 오래됨 | 기준일이 지난 분기 | 모든 근거에 as_of 표시, 90일 넘으면 경고 |
| 특정 제공사로 근거 쏠림 | 한 제공사 비중 60% 초과 | 검색 재실행, 다른 제공사 근거 강제 포함 |
| 해커톤 도구가 그대로 운영에 들어감 | 로그·권한 없음 | 보안 검토와 데이터 계약 전에는 운영 데이터 연결 금지 |
현업 실행 디테일: 누가, 언제, 무엇을
원문은 전문가와 투자 실무자가 함께 만드는 해커톤, 실습 랩, 투자 AI 챔피언, 그리고 보안 검토·전문가 지원·데이터 계약이라는 관문을 밝혔습니다. 아래 역할 표, 일정, 기준은 이를 바탕으로 새로 짠 가상 예시입니다.
| 역할 | 맡는 일 |
|---|---|
| 투자 부문 스폰서(CIO 또는 리서치 헤드) | 시범 범위 선정, 위험 가드레일 승인, 최종 판정 |
| 투자 AI 챔피언 1~2명 | 실험 발굴, 운영 전환 관리, 현업과 개발의 통역 |
| 애널리스트 3~5명, PM 2명 | 질문 목록 제공, 병행 운영, 답의 쓸모 평가 |
| 리스크·컴플라이언스·트레이딩 담당 각 1명 | 관점별 점검 항목 정의, 에이전트 출력 검토 |
| 데이터 엔지니어 1~2명, AI 엔지니어 1명 | Semantic Layer 정의, 커넥터, 에이전트와 로그 |
| 정보보안·데이터 거버넌스 | 보안 검토, 데이터 계약, 접근 권한 |
준비물. PM과 애널리스트가 실제로 자주 묻는 질문 30개, 그 질문에 답하려면 필요한 데이터 원천 목록, 부서마다 쓰는 지표 정의 문서, 제한 종목 목록과 컴플라이언스 규정, 외부 리서치 제공사별 사용 계약 조건, 지금 아이디어 하나를 PM에게 올리기까지 걸리는 시간 기록이 필요합니다. 질문 30개는 답을 이미 아는 것으로 고릅니다. 그래야 정답과 비교할 수 있습니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | 질문 30개 수집, 개념 30~50개와 연결 정의, 데이터 계약 확인 | Semantic Layer v1, 원천·소유자 목록 |
| 3~4주 | 관점별 에이전트 4개 구축, 보안 검토, PM 화면 시안 | 에이전트 출력 JSON, 보안 검토 결과 |
| 5~6주 | 병행 운영: 기존 방식과 같은 아이디어를 함께 처리, PM 평가 | 정답 일치율, 근거 누락률, 판정서 |
현업에 물을 것.
- 아이디어를 채택하거나 접을 때 PM이 마지막으로 확인하는 것은 무엇인가요?
- 리스크·컴플라이언스·트레이딩 의견이 늦게 와서 결정이 미뤄진 적이 있나요? 어느 단계였나요?
- 같은 지표를 부서마다 다르게 계산하는 경우는 무엇인가요? 누가 정의를 정하나요?
- 지금 가장 많이 읽는 외부 리서치는 몇 개 제공사에서 오나요? 한쪽으로 쏠려 있나요?
- AI가 절대 혼자 판단하면 안 되는 항목은 무엇인가요?
진행 판정 기준(예시). 질문 30개 가운데 정답과 맞는 답이 80% 이상이고 모든 답에 출처가 붙고 PM 2명이 “기존 메모보다 판단이 빨라졌다”고 평가하면 두 번째 자산군으로 넓힙니다. 정답률이 60~80%면 틀린 답의 원인이 정의 누락인지 데이터 누락인지 나눠 2주 더 봅니다. 60% 미만이면 에이전트가 아니라 Semantic Layer 정의부터 다시 봅니다.
AX 적용 제언. 이 사례는 금융 밖에서도 그대로 통하는 순서를 보여 줍니다. 여러 부서의 판단이 한 결정자에게 모이는 업무, 예를 들어 제조의 신제품 출시 승인, 유통의 상품 입점 결정, 보험의 대형 계약 심사가 같은 구조입니다. 먼저 결정자가 실제로 묻는 질문 30개를 모으고 그 질문에 필요한 개념과 연결을 정의한 뒤, 부서별 관점을 같은 틀로 내는 에이전트를 붙입니다. 모델 선택은 그다음입니다. 실험은 해커톤으로 넓게 열되, 운영으로 넘어가는 관문(보안 검토, 데이터 계약)은 처음부터 정해 둡니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 원문 | OpenAI 고객 사례 「Franklin Templeton uses OpenAI to support investment research」, 2026.11.5 |
| 확인 자료 | Unite.AI 「Franklin Templeton Develops AI Research Workflows to Highlight Risks」, 2026.11.6 |
| 회사·인물 | Franklin Templeton, Katrina Dudley(상장시장 투자 담당 SVP) |
| 범위 | 주식 리서치에서 시작, 투자 리서치 비교와 위험 점검 |
| 관점 | 애널리스트 1차 분석(종목 분석, 실적 콜, 사업부별 경쟁사) + 리서치·리스크·컴플라이언스·트레이딩 |
| 첫 시도 | 데이터를 DB에 넣고 모델 연결, 모델이 데이터 관계를 이해하지 못해 실패 |
| 바꾼 방식 | 에이전트 + Semantic Layer(데이터의 뜻과 연결을 정의한 구조화 모델) |
| 기반 | Connected Intelligence Layer: Trusted Connectors, 포트폴리오·워크플로 문맥, 에이전트 기능 |
| 도구 | Codex 외 여러 도구(이름 미공개) |
| 설계 원칙 | 선호 학습으로 인한 쏠림을 편향으로 보고 다양한 리서치·의견과 위험을 함께 표시 |
| 확산 | 해커톤(전문가 + 투자 실무자), 실습 랩, 투자 AI 챔피언 |
| 통제 | 위험 가드레일 안의 실험, 보안 검토, 전문가 지원, 데이터 계약 |
| 장기 목표 | 애널리스트부터 투자 그룹 리더까지 같은 기반 사용, 애널리스트의 현장 활동 확대 |
| 수치 | 사용자 수, 비용, 시간 절감 등 미공개 |
핵심 개념
- Portfolio manager (PM)
- 펀드의 종목 선택과 비중을 최종 결정하는 운용역입니다. 애널리스트 의견과 여러 부서 점검을 받아 판단합니다.
- Earnings call
- 상장사가 분기 실적 발표 뒤 투자자와 여는 설명회입니다. 경영진의 전망과 질의응답에서 수요·비용 신호를 읽습니다.
- Codex
- OpenAI의 코딩 에이전트입니다. 이 사례에서는 해커톤과 Connected Intelligence Layer 구축에 쓰였습니다.
- Trusted connector
- 승인된 데이터 원천만 정해진 권한으로 AI 도구에 잇는 연결입니다.
- Data agreement
- 데이터 원천을 어떤 목적으로 누가 쓰는지, 품질과 책임은 누구에게 있는지 정한 약속입니다. 실험이 운영으로 넘어갈 때 확인합니다.
- Confirmation bias
- 이미 믿는 것을 뒷받침하는 정보만 찾게 되는 경향입니다. 선호 학습형 추천이 이를 키울 수 있습니다.
내 메모
TODO: 내 생각 추가
원문은 OpenAI 고객 사례 「Franklin Templeton uses OpenAI to support investment research」(2026.11.5)입니다. openai.com 페이지를 직접 열 수 없어 이 사례를 다룬 Unite.AI 보도 「Franklin Templeton Develops AI Research Workflows to Highlight Risks」(2026.11.6)로 내용을 확인했습니다. 벤더(OpenAI)가 낸 고객 사례이므로 효과에 대한 설명은 벤더와 회사 측 설명이며 사용자 수·비용 같은 수치는 공개되지 않았습니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 원문 내용을 AX Review가 다시 정리했습니다. 각 메커니즘의 작은 예시, 기술 디테일, 현업 실행 디테일, 인포그래픽과 표의 역할·일정·기준·필드명은 실제로 돌릴 때 필요한 것을 새로 작성한 가상 예시입니다. 전체 내용은 원문에서 볼 수 있습니다.