모두의포트폴리오
PE · FDE 직군을 위한 포트폴리오 밀키트
예전 판입니다 (1판)이 문서는 2026-08-01 에 새 판으로 개정됐습니다. 산출물을 진단 콘솔에서 CLI로 좁히고, 사용 로그 대시보드 대신 고객사가 보내온 요청 시트의 결손을 짚어 확인 질문 목록 파일을 내도록 다시 썼습니다.최신 판 보기 →
경력링크알파 · Forward Deployed Consultant, APAC

헤지펀드·자산운용사 계정별 사용 로그와 현장 고객 의견을 받아 어떤 워크플로에서 도입이 막혔는지 진단하고 다음 실행안과 로드맵 반영안을 근거와 함께 뽑아 콘솔에 띄우는 APAC 계정 도입 진단 콘솔

링크알파 공고에서 뽑은 세 가지 시그널.

링크알파는 방금 2200만 달러 시리즈 A 를 마감하고 뉴욕·보스턴·서울·홍콩·싱가포르·런던 6개 오피스로 12개월마다 10배 성장을 노리는, 기관투자 금융에 특화된 AI 리서치·미팅 인텔리전스·대체 데이터 회사로 70곳 넘는 유료 기관 고객과 90% 이상 유지율을 가졌습니다. Forward Deployed Consultant 는 홍콩 기반으로 APAC 핵심 계정 곁에서 워크플로를 진단하고 사용 패턴을 분석해 도입 로드맵을 실행까지 잇고, 현장 의견을 Voice-of-Customer 로 제품에 되돌리는 사람입니다. 계정별 사용 로그를 규칙으로 도입 단계·차단 요인으로 환산하고 현장 의견을 제품 영역으로 분류해 다음 실행안까지 뽑는 이 콘솔은 그 핵심(워크플로 진단·사용 패턴 분석·도입 로드맵·VoC 순환)을 정면으로 입증합니다. 실제 헤지펀드 투자 워크플로 깊이나 알파 인텔리전스 도메인 전문성은 포트폴리오로 증명되지 않으므로 합성 사용 로그로 기술만 보이고, 그 깊이는 면접에서 솔직히 다룹니다. 딥리서치·미팅 인텔리전스·대체 데이터라는 링크알파 고유 제품 축과 홍콩·싱가포르·도쿄·서울 계정 맥락이 있어야만 이 도입 진단 사슬이 의미를 가집니다.

01

고객 워크플로 진단·도입 로드맵

고객 워크플로를 진단하고 사용 패턴을 분석해 실행까지 잇는 도입 로드맵을 짜는 것이 주요업무입니다. 계정별 사용 신호를 도입 단계·차단 요인으로 환산해 다음 실행안을 뽑는 이 콘솔이 정면으로 정렬됩니다.

Diagnose client workflows, analyze usage patterns, and build the adoption roadmap through to executionlead the adoption, expansion, and success of LinqAlpha across our most important APAC accountstranslating their needs into product outcomes
02

현장 고객 의견을 제품 로드맵으로

고객 피드백을 Voice-of-Customer 로 제품팀에 전달하고 로드맵 우선순위를 협상합니다. 현장 의견을 제품 영역으로 분류해 우선순위·로드맵 반영안으로 잇는 이 콘솔과 정렬됩니다.

Bring client feedback back into the product team as Voice-of-Customer, and negotiate priorities with the roadmapCoordinate QA, beta features, and custom requests with engineering and AI research
03

LLM·에이전트·MCP 를 고객에게

LLM·AI 에이전트·API·MCP 같은 신기술을 빠르게 이해해 고객에게 명확히 설명하고 제품 성과로 옮깁니다. LLM 으로 진단을 만들고 MCP 에이전트로 상담사가 계정 상태를 질의하는 이 콘솔과 정렬됩니다.

Ability to quickly grasp new technology (LLMs, AI agents, APIs, MCP) and explain it clearly to clientsWorking knowledge of Python, SQL, or APIsNext is API and MCP-based agent delivery

포트폴리오 요약

APAC 기관투자 고객사(헤지펀드·셀사이드·자산운용사)의 계정별 기능 사용 로그(딥리서치 질의·미팅 인텔리전스 세션·대체 데이터 조회 등)와 현장 고객 의견 노트를 받아, 규칙(핵심 기능 미활성·30일 이상 미접속·확장 기능 미사용·계정 미매핑)으로 각 계정의 도입 단계와 차단 요인을 정하고, 그 근거를 사용 신호 인용으로 풀어 다음 실행안과 로드맵 반영안을 만드는 콘솔입니다. 도입 단계는 사용 로그 수치 규칙이 결정하고 LLM 은 진단 서술·다음 실행안 생성·현장 의견 분류만 맡습니다. 고객의 투자 실력이나 알파를 판정하는 도구가 아니라, 계정의 사용 신호를 규칙으로 도입 단계로 환산해 컨설턴트의 다음 실행안을 근거와 함께 정리하는 도구입니다.

고객 정의

링크알파 Forward Deployed Consultant(APAC, 홍콩 기반). 홍콩·싱가포르·도쿄·서울 계정을 오가며 사용 로그를 스프레드시트로 훑고 현장에서 들은 고객 의견을 메모로 흩어 두었다가 감으로 다음 방문 계획을 세우던 일을, 한 콘솔에서 계정별 도입 단계·차단 요인·다음 실행안을 근거와 함께 보고 싶은 사람입니다.

고민 지점

계정 사용 로그를 한 스키마로 묶고 도입 단계 규칙과 현장 의견 분류를 붙이면, (a) 어느 계정이 어느 기능에서 막혔는지를 사용 신호 규칙으로 짚고, (b) 진단·다음 실행안을 사용 신호 인용으로 풀며, (c) 여러 계정을 끊김 없이 도입 진단 카드로 정리합니다.

주차별 일정

1주차여기까지로 완성

사용 로그 집계 + 도입 단계 진단 + 다음 실행안 + 현장 의견 분류

계정별 사용 로그를 집계해 도입 단계와 차단 요인을 규칙으로 정하고, 근거와 함께 다음 실행안을 뽑아 현장 고객 의견을 제품 영역으로 분류까지 붙인 동작하는 콘솔입니다. 사용 로그와 의견 노트는 합성 더미로 시작하고, 입력은 사내 사용 로그 API 가정으로 두어 CSV·JSON 적재로 가볍게 둡니다.

  1. 1일 · 계정·사용 로그·현장 의견 스키마를 정의기능별 사용량·최근 접속일·좌석·펀드유형·지역·도입 단계·차단 요인·현장 의견 제품 영역 스키마(JSON Schema) 정의
  2. 2-3일 · 사용 신호 집계 + 도입 단계 규칙SQL 로 계정별 기능 사용 신호를 집계하고, 핵심 기능 미활성·30일 이상 미접속·확장 기능 미사용·계정 미매핑 규칙으로 도입 단계·차단 요인 결정
  3. 4-5일 · 근거를 들어 진단·다음 실행안 생성프롬프트 v1(규칙 결과 입력 + 사용 신호 인용 강제) + JSON Schema 로 출력 검증 + 현장 의견을 제품 영역으로 분류
  4. 6일 · 계정 도입 진단 콘솔 화면계정 카드(도입 단계·차단 요인·다음 실행안·현장 의견) 그리드 + 근거 사용 신호 + CSV·JSON 적재
  5. 7일 · 7일치 시연 영상 + 심은 정답과 비교한 기준선여기까지가 1주차 완성품입니다
2주차선택 성장

진단이 맞았는지 확인

도입 단계 판정을 심은 정답 단계·상담사 2명 라벨과 비교해 정확도와 일치도를 보여주고, 현장 의견 분류의 정밀도·재현율을 붙이는 화면입니다.

  1. 8-9일 · 상담사 2명이 도입 단계 라벨링심은 정답 단계 대비 정확도 + 현장 의견 분류 정밀도·재현율 + 라벨 가이드
  2. 10-11일 · 진단 신뢰도 보강일치도 측정(Cohen's κ: 두 사람 답이 우연 이상으로 일치하는 정도, 0~1) + 오진단 사례 정리
  3. 12일 · 근거 없는 실행안 자동 차단사용 신호 인용 매칭 + 별도 LLM 검사 + 5% 사람 점검
3주차선택 성장

MCP 에이전트 질의 + 지역별 도입 추이

상담사가 자연어로 계정 상태를 묻는 MCP 기반 에이전트(예: 어느 홍콩 바이사이드 계정이 미팅 인텔리전스에서 이탈 위험인가)를 붙이고, 지역·펀드유형별 도입 단계 분포와 차단 요인 추이를 집계해 확장 기회 계정을 보여주는 화면입니다.

  1. 15-17일 · MCP 에이전트 질의 붙이기상담사가 자연어로 계정 상태를 묻고 콘솔 데이터를 조회해 답하는 MCP 기반 에이전트
  2. 18-21일 · 지역별 도입 추이 + 통합 시연 영상지역·펀드유형별 도입 단계 분포·차단 요인 추이 집계 + 확장 기회 계정 + 실제 도입 계획(실 사용 로그·실 상담사 교체) 포함

데모 · 측정 지표

01

계정 시나리오 15종(정상 도입·핵심 기능 미활성·이탈 위험·계정 미매핑·확장 기회)을 넣으면, 도입 단계·차단 요인·다음 실행안·현장 의견 분류가 몇 초 안에 나오는 걸 시연합니다

02

일부러 만든 악성·결측 입력 30종(사용량 결측·최근 접속일 결측·좌석 0·미매핑 계정·펀드유형 표기 흔들림)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다

03

더미에 심은 정답 도입 단계 48건 중 규칙 판정이 일치한 게 44건(약 92%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다

정직 경계선

진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 도입 단계 판정 정확도와 현장 의견 분류 성능은 링크알파의 실 계정 사용 로그와 실 상담사가 있어야 측정 가능합니다. 이 콘솔은 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다

미리 알아둬야 할 것들

이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명하는 게 오히려 신뢰를 줍니다

정답을 작성자가 만들었으니 잘 맞는 게 당연합니다. 그래서 사용량 결측·좌석 0 경계값·미매핑 계정·펀드유형 표기 흔들림 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 계정만 통과시키는 게 아님을 보여줍니다

이 포트폴리오가 입증하는 것은 사용 로그 집계 + 규칙 기반 도입 단계 판정 + LLM 진단·실행안 근거화 + 현장 의견 분류 기술입니다. 실제 헤지펀드·자산운용사의 투자 워크플로 깊이나 알파 인텔리전스 도메인 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않으며, 그 깊이는 실제 바이사이드 실무자와 상담사의 몫이고 면접에서 모르면 모른다고 말하는 편이 낫습니다. 데모는 합성 사용 로그로 기술만 입증합니다

사용 신호가 곧 도입 성공은 아닙니다. 사용량이 많아도 잘못 쓰고 있을 수 있어, 도입 단계는 규칙으로 정하되 상관과 인과를 섞지 않게 진단 서술에 단정 대신 사용 신호 인용만 답니다

계정명·기능명 표기가 제각각입니다(펀드 별칭·기능 구버전명). 원문 표기와 매핑 id 를 분리해 같은 개체로 묶고, 못 묶은 건 추측하지 말고 '미매핑'으로 알립니다. 실제 도입 시 사용 로그 스키마·기능 enum·지역 분포가 더미와 다르므로 규칙·enum 을 다시 맞춰야 합니다(도입 단계 과제로 분리)

더미 데이터

① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.

account_usageTABLE· 12 rows

APAC 계정별 기능 사용 신호 로그. 도입 단계 규칙이 가장 먼저 질의하는 테이블입니다. 사용량 결측·좌석 0 경계값·미매핑 계정·펀드유형 표기 흔들림을 일부러 섞고, label 로 정답 도입 단계를 심어 자가채점합니다.

② account_usage.seed.json 다운로드
① 인라인 샘플 (프리뷰 5 / 12)
account_idfirm_name_rawfirm_idfirm_typeregionseatsdeep_research_queriesmeeting_intel_sessionsalt_data_pullslast_active_daystierlabel
acc_001Meridian Capital HKfirm_meridianbuy_sideHK1234088512enterpriseadopting
acc_002Nomura Sell-Side Deskfirm_nomurasell_sideTokyo82104405growthexpanding
acc_003Lion City Asset Mgmtfirm_lioncityasset_managerSG6120039growthactivating
acc_004Han River Investmentsfirm_hanriverbuy_sideSeoul1095301241enterpriseat_risk
acc_005MERIDIAN CAPITAL (HK)firm_meridianbuy_sideHK40003pilotactivating
③ 증강 프롬프트 (본인 LLM 에 붙여서 N 배 늘리기)
아래 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 배열만.
schema (3 층의 단일 출처)
{"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"]}
voc_notesDOCS· 12 docs

현장 방문에서 받은 고객 의견 노트. 제품 영역 분류와 우선순위 매핑의 입력입니다. 칭찬·불만·기능 요청·버그를 섞고, 애매하거나 여러 영역이 걸친 노트를 일부러 넣어 분류가 쉬운 것만 맞추지 않게 합니다.

② voc_notes.seed.json 다운로드
① 인라인 샘플 (프리뷰 2 / 12)
voc_001 · Meridian Capital 리서치팀
딥리서치 요약은 만족스러운데 미팅 인텔리전스에서 화자 구분이 자주 틀린다고 합니다. 애널리스트가 회의록을 다시 손봐야 해서 도입을 망설이는 상황입니다.
voc_002 · Nomura 셀사이드 데스크
대체 데이터 커버리지에 일본 기업이 부족하다는 요청입니다. 로컬 데이터 소스 연동이 되면 좌석을 늘리겠다고 합니다.
③ 증강 프롬프트 (본인 LLM 에 붙여서 N 배 늘리기)
아래 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 배열만.
schema (3 층의 단일 출처)
{"type":"object","properties":{"title":{"type":"string"},"body":{"type":"string"}},"required":["title","body"]}

기술 상세 · 아키텍처·운영·출력 스키마

기술 스택 매핑
Python사용 로그 집계·도입 단계 규칙 엔진·LLM 진단 파이프라인·채점 도구를 구현하는 언어입니다(pandas·FastAPI)
SQL계정별 기능 사용 로그를 도입 신호(기능별 사용량·최근 접속일·좌석 대비 활성)로 집계하는 질의입니다
LLM사용 신호·현장 의견을 받아 도입 진단 서술과 다음 실행안을 만들고 현장 의견을 제품 영역으로 분류하는 엔진입니다
Claude진단 서술·다음 실행안 생성·현장 의견 분류를 맡는 LLM 입니다(Claude Sonnet)
AI agents3주차에 상담사가 자연어로 계정 상태를 질의하면 콘솔 데이터를 조회해 답하는 에이전트입니다
MCP3주차 에이전트가 콘솔의 계정 데이터·진단 결과를 도구로 노출해 질의에 답하게 잇는 규격입니다
API사내 사용 로그·현장 의견을 콘솔로 넣는 입력 API 가정과 진단 결과를 내보내는 API 입니다
financial data platforms고객사가 쓰는 데이터 소스(Bloomberg·Refinitiv·FactSet·S&P Global) 맥락을 계정 도메인 라벨로 두어 도입 적합도 판단에 씁니다
LLM 선택
model
Claude Sonnet (도입 진단 서술·다음 실행안 생성·현장 의견 분류) + GPT-4o-mini (LLM-as-judge 근거 없는 실행안 검출)
prompt
few-shot 3 예시 + 출력 스키마(JSON Schema) 강제 + 진단마다 사용 신호 인용 강제 + 도입 단계는 규칙 결과를 입력으로 받아 서술만 하게 제한 + 근거 없는 실행안 거름 가드 + 후행 judge
rationale
도입 단계와 차단 요인은 사용 로그 수치 규칙이 결정하므로 LLM 환각이 진단을 왜곡하지 못합니다. 서술·실행안 생성에 Sonnet 을, judge 는 비용·속도 우선으로 mini 를 씁니다. 계정 데이터가 구조화돼 프롬프트에 직접 담기므로 별도 지식 검색은 필요 없어 RAG 는 쓰지 않습니다.
결정 게이트
1주차 끝콘솔이 계정 사용 로그를 집계해 도입 단계·차단 요인을 규칙으로 정하고 근거와 함께 다음 실행안을 뽑아 현장 의견을 제품 영역으로 분류하는가. 여기까지가 그 자체로 제출 가능한 완성품입니다.

✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(진단이 맞았는지 확인)로 진행합니다.

2주차 끝도입 단계 판정이 심은 정답 단계·상담사 라벨로 맞다고 확인되고 정확도·일치도와 현장 의견 분류의 정밀도·재현율이 붙는가.

✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(MCP 에이전트 질의 + 지역별 도입 추이)로 진행합니다.

재사용 레이어 · 코어 70% / 도메인 30%
core (재사용 가능)
  • 계정별 사용 로그 집계 + 출력 스키마(JSON Schema) 강제
  • 사용 신호를 도입 단계·차단 요인으로 환산하는 규칙 엔진
  • 진단·다음 실행안에 사용 신호 인용을 강제하는 LLM 프롬프트 가드
  • 계정 카드·차단 요인 배지·다음 실행안 컴포넌트로 된 콘솔
  • 근거 없는 실행안 차단 가드 + LLM-as-judge 근거 매칭
  • 5% 사람 spot-check 샘플러 + 도입 추이·이탈 위험 리포트 봇
domain (교체 대상)
  • 기능 enum(deep_research·meeting_intel·alt_data)과 기능별 활성 임계값은 도메인별로 갈아끼웁니다
  • 펀드유형·지역 enum(buy_side·sell_side·asset_manager / HK·SG·Tokyo·Seoul)
  • 현장 의견 제품 영역 enum과 상담사 라벨 가이드
출력 스키마 · account_diagnosis

계정 1건의 도입 진단 카드. 도입 단계·차단 요인·근거·다음 실행안을 한 스키마로 담아 콘솔 카드에 씁니다. 투자 실력 판정이 아니라 사용 신호 규칙 기반 도입 진단입니다.

schema (JSON Schema)
{"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"]}
모범 출력 (3)
[
  {
    "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": "회사 매핑이 없어 도입 단계를 확정하지 않고 검토로 둡니다"
    }
  }
]
검증 노트 (자동 vs 수동)

[자동 검증] 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% 를 직접 점검합니다.