링크알파는 방금 2200만 달러 시리즈 A 를 마감하고 뉴욕·보스턴·서울·홍콩·싱가포르·런던 6개 오피스로 12개월마다 10배 성장을 노리는, 기관투자 금융에 특화된 AI 리서치·미팅 인텔리전스·대체 데이터 회사로 70곳 넘는 유료 기관 고객과 90% 이상 유지율을 가졌습니다. Forward Deployed Consultant 는 홍콩 기반으로 APAC 핵심 계정 곁에서 워크플로를 진단하고 사용 패턴을 분석해 도입 로드맵을 실행까지 잇고, 현장 의견을 Voice-of-Customer 로 제품에 되돌리는 사람입니다. 계정별 사용 로그를 규칙으로 도입 단계·차단 요인으로 환산하고 현장 의견을 제품 영역으로 분류해 다음 실행안까지 뽑는 이 콘솔은 그 핵심(워크플로 진단·사용 패턴 분석·도입 로드맵·VoC 순환)을 정면으로 입증합니다. 실제 헤지펀드 투자 워크플로 깊이나 알파 인텔리전스 도메인 전문성은 포트폴리오로 증명되지 않으므로 합성 사용 로그로 기술만 보이고, 그 깊이는 면접에서 솔직히 다룹니다. 딥리서치·미팅 인텔리전스·대체 데이터라는 링크알파 고유 제품 축과 홍콩·싱가포르·도쿄·서울 계정 맥락이 있어야만 이 도입 진단 사슬이 의미를 가집니다.
고객 워크플로를 진단하고 사용 패턴을 분석해 실행까지 잇는 도입 로드맵을 짜는 것이 주요업무입니다. 계정별 사용 신호를 도입 단계·차단 요인으로 환산해 다음 실행안을 뽑는 이 콘솔이 정면으로 정렬됩니다.
고객 피드백을 Voice-of-Customer 로 제품팀에 전달하고 로드맵 우선순위를 협상합니다. 현장 의견을 제품 영역으로 분류해 우선순위·로드맵 반영안으로 잇는 이 콘솔과 정렬됩니다.
LLM·AI 에이전트·API·MCP 같은 신기술을 빠르게 이해해 고객에게 명확히 설명하고 제품 성과로 옮깁니다. LLM 으로 진단을 만들고 MCP 에이전트로 상담사가 계정 상태를 질의하는 이 콘솔과 정렬됩니다.
APAC 기관투자 고객사(헤지펀드·셀사이드·자산운용사)의 계정별 기능 사용 로그(딥리서치 질의·미팅 인텔리전스 세션·대체 데이터 조회 등)와 현장 고객 의견 노트를 받아, 규칙(핵심 기능 미활성·30일 이상 미접속·확장 기능 미사용·계정 미매핑)으로 각 계정의 도입 단계와 차단 요인을 정하고, 그 근거를 사용 신호 인용으로 풀어 다음 실행안과 로드맵 반영안을 만드는 콘솔입니다. 도입 단계는 사용 로그 수치 규칙이 결정하고 LLM 은 진단 서술·다음 실행안 생성·현장 의견 분류만 맡습니다. 고객의 투자 실력이나 알파를 판정하는 도구가 아니라, 계정의 사용 신호를 규칙으로 도입 단계로 환산해 컨설턴트의 다음 실행안을 근거와 함께 정리하는 도구입니다.
링크알파 Forward Deployed Consultant(APAC, 홍콩 기반). 홍콩·싱가포르·도쿄·서울 계정을 오가며 사용 로그를 스프레드시트로 훑고 현장에서 들은 고객 의견을 메모로 흩어 두었다가 감으로 다음 방문 계획을 세우던 일을, 한 콘솔에서 계정별 도입 단계·차단 요인·다음 실행안을 근거와 함께 보고 싶은 사람입니다.
계정 사용 로그를 한 스키마로 묶고 도입 단계 규칙과 현장 의견 분류를 붙이면, (a) 어느 계정이 어느 기능에서 막혔는지를 사용 신호 규칙으로 짚고, (b) 진단·다음 실행안을 사용 신호 인용으로 풀며, (c) 여러 계정을 끊김 없이 도입 진단 카드로 정리합니다.
계정별 사용 로그를 집계해 도입 단계와 차단 요인을 규칙으로 정하고, 근거와 함께 다음 실행안을 뽑아 현장 고객 의견을 제품 영역으로 분류까지 붙인 동작하는 콘솔입니다. 사용 로그와 의견 노트는 합성 더미로 시작하고, 입력은 사내 사용 로그 API 가정으로 두어 CSV·JSON 적재로 가볍게 둡니다.
도입 단계 판정을 심은 정답 단계·상담사 2명 라벨과 비교해 정확도와 일치도를 보여주고, 현장 의견 분류의 정밀도·재현율을 붙이는 화면입니다.
상담사가 자연어로 계정 상태를 묻는 MCP 기반 에이전트(예: 어느 홍콩 바이사이드 계정이 미팅 인텔리전스에서 이탈 위험인가)를 붙이고, 지역·펀드유형별 도입 단계 분포와 차단 요인 추이를 집계해 확장 기회 계정을 보여주는 화면입니다.
계정 시나리오 15종(정상 도입·핵심 기능 미활성·이탈 위험·계정 미매핑·확장 기회)을 넣으면, 도입 단계·차단 요인·다음 실행안·현장 의견 분류가 몇 초 안에 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(사용량 결측·최근 접속일 결측·좌석 0·미매핑 계정·펀드유형 표기 흔들림)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다
더미에 심은 정답 도입 단계 48건 중 규칙 판정이 일치한 게 44건(약 92%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 도입 단계 판정 정확도와 현장 의견 분류 성능은 링크알파의 실 계정 사용 로그와 실 상담사가 있어야 측정 가능합니다. 이 콘솔은 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명하는 게 오히려 신뢰를 줍니다
정답을 작성자가 만들었으니 잘 맞는 게 당연합니다. 그래서 사용량 결측·좌석 0 경계값·미매핑 계정·펀드유형 표기 흔들림 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 계정만 통과시키는 게 아님을 보여줍니다
이 포트폴리오가 입증하는 것은 사용 로그 집계 + 규칙 기반 도입 단계 판정 + LLM 진단·실행안 근거화 + 현장 의견 분류 기술입니다. 실제 헤지펀드·자산운용사의 투자 워크플로 깊이나 알파 인텔리전스 도메인 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않으며, 그 깊이는 실제 바이사이드 실무자와 상담사의 몫이고 면접에서 모르면 모른다고 말하는 편이 낫습니다. 데모는 합성 사용 로그로 기술만 입증합니다
사용 신호가 곧 도입 성공은 아닙니다. 사용량이 많아도 잘못 쓰고 있을 수 있어, 도입 단계는 규칙으로 정하되 상관과 인과를 섞지 않게 진단 서술에 단정 대신 사용 신호 인용만 답니다
계정명·기능명 표기가 제각각입니다(펀드 별칭·기능 구버전명). 원문 표기와 매핑 id 를 분리해 같은 개체로 묶고, 못 묶은 건 추측하지 말고 '미매핑'으로 알립니다. 실제 도입 시 사용 로그 스키마·기능 enum·지역 분포가 더미와 다르므로 규칙·enum 을 다시 맞춰야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
APAC 계정별 기능 사용 신호 로그. 도입 단계 규칙이 가장 먼저 질의하는 테이블입니다. 사용량 결측·좌석 0 경계값·미매핑 계정·펀드유형 표기 흔들림을 일부러 섞고, label 로 정답 도입 단계를 심어 자가채점합니다.
| account_id | firm_name_raw | firm_id | firm_type | region | seats | deep_research_queries | meeting_intel_sessions | alt_data_pulls | last_active_days | tier | label |
|---|---|---|---|---|---|---|---|---|---|---|---|
| acc_001 | Meridian Capital HK | firm_meridian | buy_side | HK | 12 | 340 | 88 | 51 | 2 | enterprise | adopting |
| acc_002 | Nomura Sell-Side Desk | firm_nomura | sell_side | Tokyo | 8 | 210 | 44 | 0 | 5 | growth | expanding |
| acc_003 | Lion City Asset Mgmt | firm_lioncity | asset_manager | SG | 6 | 120 | 0 | 3 | 9 | growth | activating |
| acc_004 | Han River Investments | firm_hanriver | buy_side | Seoul | 10 | 95 | 30 | 12 | 41 | enterprise | at_risk |
| acc_005 | MERIDIAN CAPITAL (HK) | firm_meridian | buy_side | HK | 4 | 0 | 0 | 0 | 3 | pilot | activating |
아래 JSON Schema 에 맞는 계정 사용 신호 60행 JSON 배열로 생성합니다. 지역·펀드유형 분포를 고르게, 정상 도입 위주에 이탈 위험·미활성·확장 기회를 섞습니다. label 규칙(우선순위 순): (1) firm_id=null(미매핑) 또는 deep_research_queries·meeting_intel_sessions·last_active_days 중 하나라도 null(계측 결측) → review, (2) last_active_days>30 → at_risk, (3) seats>0 이고 deep_research_queries=0 또는 meeting_intel_sessions=0(핵심 기능 미활성) → activating, (4) 핵심 기능은 쓰지만 alt_data_pulls=0(확장 기능 미사용) → expanding, (5) 그 외(핵심·확장 모두 활성, 최근 접속) → adopting.
{"type":"object","properties":{"account_id":{"type":"string"},"firm_name_raw":{"type":"string"},"firm_id":{"type":["string","null"]},"firm_type":{"type":"string","enum":["buy_side","sell_side","asset_manager","unknown"]},"region":{"type":"string","enum":["HK","SG","Tokyo","Seoul","unknown"]},"seats":{"type":"integer"},"deep_research_queries":{"type":["integer","null"]},"meeting_intel_sessions":{"type":["integer","null"]},"alt_data_pulls":{"type":["integer","null"]},"last_active_days":{"type":["integer","null"]},"tier":{"type":"string","enum":["enterprise","growth","pilot"]},"label":{"type":"string","enum":["activating","adopting","expanding","at_risk","review"]}},"required":["account_id","firm_name_raw","firm_id","firm_type","region","seats","deep_research_queries","meeting_intel_sessions","alt_data_pulls","last_active_days","tier","label"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 계정만 통과시키는 함정 회피): (1) 표기 흔들림: 같은 firm_id 를 가진 계정에 'Meridian Capital HK'/'MERIDIAN CAPITAL (HK)' 처럼 firm_name_raw 만 다른 별칭 3건 이상, (2) 결측: deep_research_queries·meeting_intel_sessions·last_active_days 중 하나가 null 인 review 케이스 3건 이상, (3) 미매핑: firm_id=null 인 orphan 계정 2건(review), (4) 경계값: seats=0·last_active_days=60 같은 극단 2건 이상, (5) 확장 기회: 핵심 기능은 활발하나 alt_data_pulls=0 인 expanding 2건. label 은 위 규칙대로 정직하게. 진짜 스키마 위반(타입 깨짐)은 데이터가 아니라 별도 '형식 깨뜨리기 시도 3건' 지시로만 재현. JSON 배열만.{"type":"object","properties":{"account_id":{"type":"string"},"firm_name_raw":{"type":"string"},"firm_id":{"type":["string","null"]},"firm_type":{"type":"string","enum":["buy_side","sell_side","asset_manager","unknown"]},"region":{"type":"string","enum":["HK","SG","Tokyo","Seoul","unknown"]},"seats":{"type":"integer"},"deep_research_queries":{"type":["integer","null"]},"meeting_intel_sessions":{"type":["integer","null"]},"alt_data_pulls":{"type":["integer","null"]},"last_active_days":{"type":["integer","null"]},"tier":{"type":"string","enum":["enterprise","growth","pilot"]},"label":{"type":"string","enum":["activating","adopting","expanding","at_risk","review"]}},"required":["account_id","firm_name_raw","firm_id","firm_type","region","seats","deep_research_queries","meeting_intel_sessions","alt_data_pulls","last_active_days","tier","label"]}현장 방문에서 받은 고객 의견 노트. 제품 영역 분류와 우선순위 매핑의 입력입니다. 칭찬·불만·기능 요청·버그를 섞고, 애매하거나 여러 영역이 걸친 노트를 일부러 넣어 분류가 쉬운 것만 맞추지 않게 합니다.
딥리서치 요약은 만족스러운데 미팅 인텔리전스에서 화자 구분이 자주 틀린다고 합니다. 애널리스트가 회의록을 다시 손봐야 해서 도입을 망설이는 상황입니다.
대체 데이터 커버리지에 일본 기업이 부족하다는 요청입니다. 로컬 데이터 소스 연동이 되면 좌석을 늘리겠다고 합니다.
아래 JSON Schema 에 맞는 현장 고객 의견 노트 40개를 JSON 배열로 생성합니다. title 은 'voc_### · 계정/팀' 형식, body 는 2~3문장 한국어 존댓말입니다. 제품 영역(meeting_intel·alt_data·onboarding·integration_api·export·pricing_ops 등)과 요청 유형(칭찬·불만·기능 요청·버그·이탈 신호)을 고르게 섞습니다.
{"type":"object","properties":{"title":{"type":"string"},"body":{"type":"string"}},"required":["title","body"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(분류가 쉬운 노트만 맞추는 함정 회피): (1) 여러 제품 영역이 한 노트에 걸친 케이스 3건 이상(예: 미팅 인텔리전스 불만 + 확장 의향 동시), (2) 계정 미상(명함만 확보처럼 어느 계정인지 특정 불가) 2건, (3) 같은 회사의 다른 팀 의견으로 제품 영역이 갈리는 케이스 2건, (4) 칭찬처럼 보이지만 이탈 신호가 숨은 케이스 2건, (5) 영역이 모호해 사람 검토가 필요한 경계 케이스 2건. JSON 배열만.{"type":"object","properties":{"title":{"type":"string"},"body":{"type":"string"}},"required":["title","body"]}| Python | 사용 로그 집계·도입 단계 규칙 엔진·LLM 진단 파이프라인·채점 도구를 구현하는 언어입니다(pandas·FastAPI) |
| SQL | 계정별 기능 사용 로그를 도입 신호(기능별 사용량·최근 접속일·좌석 대비 활성)로 집계하는 질의입니다 |
| LLM | 사용 신호·현장 의견을 받아 도입 진단 서술과 다음 실행안을 만들고 현장 의견을 제품 영역으로 분류하는 엔진입니다 |
| Claude | 진단 서술·다음 실행안 생성·현장 의견 분류를 맡는 LLM 입니다(Claude Sonnet) |
| AI agents | 3주차에 상담사가 자연어로 계정 상태를 질의하면 콘솔 데이터를 조회해 답하는 에이전트입니다 |
| MCP | 3주차 에이전트가 콘솔의 계정 데이터·진단 결과를 도구로 노출해 질의에 답하게 잇는 규격입니다 |
| API | 사내 사용 로그·현장 의견을 콘솔로 넣는 입력 API 가정과 진단 결과를 내보내는 API 입니다 |
| financial data platforms | 고객사가 쓰는 데이터 소스(Bloomberg·Refinitiv·FactSet·S&P Global) 맥락을 계정 도메인 라벨로 두어 도입 적합도 판단에 씁니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(진단이 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(MCP 에이전트 질의 + 지역별 도입 추이)로 진행합니다.
계정 1건의 도입 진단 카드. 도입 단계·차단 요인·근거·다음 실행안을 한 스키마로 담아 콘솔 카드에 씁니다. 투자 실력 판정이 아니라 사용 신호 규칙 기반 도입 진단입니다.
{"type":"object","properties":{"account_id":{"type":"string"},"stage":{"type":"string","enum":["activating","adopting","expanding","at_risk","review"]},"blockers":{"type":"array","items":{"type":"string","enum":["not_activated_core","dormant","no_expansion_feature","unmapped_account","metric_missing"]}},"evidence":{"type":"array","items":{"type":"object","properties":{"signal":{"type":"string"},"value":{"type":"string"}},"required":["signal","value"]}},"next_actions":{"type":"array","items":{"type":"string"}},"voc_refs":{"type":"array","items":{"type":"string"}},"hedge":{"type":["string","null"]}},"required":["account_id","stage","blockers","evidence","next_actions","voc_refs","hedge"]}[
{
"input_ref": "acc_003 (미팅 인텔리전스 미활성)",
"output": {
"account_id": "acc_003",
"stage": "activating",
"blockers": [
"not_activated_core"
],
"evidence": [
{
"signal": "meeting_intel_sessions",
"value": "0"
},
{
"signal": "seats",
"value": "6"
}
],
"next_actions": [
"온보딩 재교육 세션을 잡아 미팅 인텔리전스 첫 사용을 유도합니다(voc_003 반복 교육 요청 연계)",
"짧은 기능 가이드 영상을 공유해 새 팀원 진입 장벽을 낮춥니다"
],
"voc_refs": [
"voc_003"
],
"hedge": "핵심 기능 하나가 미활성이라 도입 초기 단계로 봅니다"
}
},
{
"input_ref": "acc_004 (30일 이상 미접속)",
"output": {
"account_id": "acc_004",
"stage": "at_risk",
"blockers": [
"dormant"
],
"evidence": [
{
"signal": "last_active_days",
"value": "41"
}
],
"next_actions": [
"이탈 위험 계정으로 분류해 현장 재방문을 우선 배정합니다(voc_004 Bloomberg 대체 이유 부재 반응 연계)",
"기존 Bloomberg 워크플로 대비 링크알파 활용 사례를 준비해 재도입 동기를 만듭니다"
],
"voc_refs": [
"voc_004"
],
"hedge": "30일 이상 미접속이라 이탈 위험으로 봅니다"
}
},
{
"input_ref": "acc_007 (미매핑 계정)",
"output": {
"account_id": "acc_007",
"stage": "review",
"blockers": [
"unmapped_account"
],
"evidence": [
{
"signal": "firm_id",
"value": "null"
}
],
"next_actions": [
"계정이 어느 회사에 매핑되는지 확인 전까지 자동 진단을 보류하고 사람 검토로 돌립니다"
],
"voc_refs": [],
"hedge": "회사 매핑이 없어 도입 단계를 확정하지 않고 검토로 둡니다"
}
}
][자동 검증] 1. JSON Schema parse 로 출력 형식(필드·enum)이 스키마를 통과하는지 확인합니다. 2. stage 가 사용 신호 규칙(firm_id null 또는 계측 결측→review·30일 초과 미접속→at_risk·핵심 기능 미활성→activating·확장 기능 미사용→expanding·그 외→adopting)과 일치하는지 봅니다. 3. evidence 의 signal·value 가 입력 계정의 실제 필드·값 인용인지 토큰 매칭으로 확인하고, 근거 없는 next_actions 는 걸러 냅니다. 4. stage 를 심은 정답 label 과 비교해 정확도를 계산합니다. [수동 검증] 1. 상담사 2명이 비동기로 도입 단계를 라벨링해 정확도와 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 현장 의견 분류(voc_notes 의 제품 영역)를 사람이 검수해 정밀도·재현율을 재고, 전체의 5% 를 직접 점검합니다.