링크알파
경력근거: Act as the communication bridge across research, engineering, and GTM
링크알파는 2200만 달러 시리즈 A 를 마감하고 뉴욕·보스턴·서울·홍콩·싱가포르·런던 6개 오피스로 12개월마다 10배 성장을 노리는, 기관투자 금융에 특화된 AI 리서치·미팅 인텔리전스·대체 데이터 회사로 70곳 넘는 유료 기관 고객과 90% 이상 유지율을 가졌습니다. Forward Deployed Consultant 는 홍콩에 상주하며 시간 대부분을 고객사 현장에서 보내고, 거기서 받은 QA·베타 기능·커스텀 요청을 엔지니어링·AI 리서치와 조율하며 현장 의견을 Voice-of-Customer 로 제품에 되돌리는 사람입니다. 그 조율은 요청이 갖춰졌을 때만 한 번에 끝나는데, 현장에서 받는 자료는 대개 반쯤 비어 있는 엑셀과 손으로 적은 메모입니다. 이 도구는 그 자료를 받아 무엇이 빠졌는지 규칙으로 짚고 고객에게 보낼 확인 질문을 만들어, 되물음 왕복을 줄이는 지점을 정면으로 겨냥합니다. 다만 이 포트폴리오가 보여주는 것은 지저분한 문서 정규화·규칙 기반 결손 판정·인용 근거를 강제한 LLM 질문 생성 기술이며, 헤지펀드·자산운용사의 투자 워크플로 깊이나 알파 인텔리전스 도메인 전문성은 주장하지 않습니다. 딥리서치·미팅 인텔리전스·대체 데이터라는 링크알파 고유 제품 축과 홍콩·싱가포르·도쿄·서울 계정, 그리고 규제 환경에서 보유 종목을 함부로 옮기지 못하는 제약이 있어야만 이 접수 점검이 의미를 가집니다.
고객사에서 올라온 QA·베타 기능·커스텀 요청을 엔지니어링·AI 리서치와 조율하는 것이 주요업무입니다. 요청이 인계될 만큼 갖춰졌는지 규칙으로 점검하고 빠진 항목을 확인 질문으로 만드는 이 도구가 그 조율의 앞단을 맡습니다.
고객 의견을 Voice-of-Customer 로 제품팀에 전달하고 로드맵 우선순위를 협상합니다. 현장 노트에서 요청 항목을 뽑아 결손 없이 정리하면 협상 자리에 근거가 갖춰진 요청만 올라갑니다.
LLM·AI 에이전트·API·MCP 를 빠르게 이해해 고객에게 설명하고, Python·SQL 로 직접 데이터를 다룹니다. 엑셀 정규화와 결손 집계를 Python·DuckDB 로 처리하고 3주차에 요청 상태를 MCP 도구로 노출하는 이 도구와 정렬됩니다.
APAC 기관투자 고객사(헤지펀드·셀사이드·자산운용사)가 보내온 요청 트래커 엑셀과 현장 미팅 노트를 읽어, 요청 한 건이 엔지니어링·AI 리서치로 넘어갈 만큼 갖춰졌는지 규칙(요청자 계정 미매핑·보유 종목 반출 승인 없음·선행 요청과 중복·제품 기능 영역 미지정·재현 조건 없음·데이터 소스와 기간 없음·기대 결과 없음)으로 판정하고, 빠진 항목마다 고객 담당자에게 그대로 보낼 확인 질문을 만들어 계정별 마크다운 파일과 인계 대기 목록 CSV 로 내는 CLI입니다. 결손 판정과 중복 판정은 시트 값 규칙이 결정하고, LLM 은 자유서술 미팅 노트에서 요청 항목을 뽑고 확인 질문 문장을 쓰는 일만 맡습니다. 요청의 사업적 가치나 로드맵 우선순위를 대신 정해 주는 도구가 아니라, 넘기고 되물음을 받는 왕복을 한 번으로 줄이는 접수 점검 도구입니다.
링크알파 Forward Deployed Consultant(APAC, 홍콩 기반). 홍콩·싱가포르·도쿄·서울 고객사를 돌며 리서치팀에게 받은 요청 시트와 미팅 메모를 그대로 엔지니어링에 넘겼다가 어느 시각의 어떤 질의였는지, 기대한 결과가 무엇인지 되물음을 받고 다시 고객에게 물어보느라 사흘을 보내던 사람입니다. 넘기기 전에 무엇이 빠졌는지 한 번에 알고, 물어볼 질문을 계정별로 정리해 두고 싶어 합니다.
요청 시트와 미팅 노트를 한 스키마로 정규화하고 필수 항목 규칙을 붙이면, (a) 어느 요청이 왜 인계 불가인지 시트 값 인용으로 짚고, (b) 빠진 항목마다 고객에게 보낼 확인 질문을 계정별 문서로 묶으며, (c) 중복 요청과 계정 미매핑 요청을 사람 검토로 따로 뺍니다.
요청 트래커 엑셀과 미팅 노트를 명령 한 번으로 읽어 요청별 결손 유형을 규칙으로 판정하고, 계정별 확인 질문 마크다운과 인계 대기 목록 CSV 를 내놓는 동작하는 CLI입니다. 요청 시트와 노트는 합성 더미로 시작하고 계정 매핑표는 CSV 한 장으로 두어 사내 시스템 연동 없이 돌아갑니다.
결손 판정을 더미에 심은 정답 유형과 비교해 정확도를 내고, 상담사 2명이 같은 요청을 라벨링해 일치도를 재며, 만들어진 확인 질문이 실제로 답을 받아낼 문장인지 사람이 검수한 결과를 리포트 파일로 내는 단계입니다.
고객에게 받은 회신을 다시 넣으면 해소된 결손을 재판정해 인계 티켓 초안을 만들고, 요청·확인 질문·회신 상태를 MCP 도구로 노출해 터미널 에이전트에게 회신이 안 온 질문을 자연어로 묻는 단계입니다.
요청 42건이 담긴 트래커 엑셀 한 장과 미팅 노트 12건을 넣으면, 결손 유형 판정과 계정별 확인 질문 파일이 명령 한 번에 몇 초 안에 나오는 걸 시연합니다
일부러 지저분하게 만든 입력 30종(머리글 반복·소계 행·병합 셀·우선순위 표기 흔들림·빈 셀·계정 미매핑)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다
더미에 심은 정답 결손 유형 60건 중 규칙 판정이 일치한 게 56건(약 93%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 결손 판정 정확도와 확인 질문의 회신률은 링크알파의 실 요청 시트와 실 고객 담당자가 있어야 측정 가능합니다. 이 도구는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 같은 회사의 표기 흔들림·빈 셀·중복 요청·계정 미매핑 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 요청만 통과시키는 게 아님을 보여줍니다
이 포트폴리오가 보여주는 것은 지저분한 엑셀·노트 정규화, 규칙 기반 결손 판정, 인용 근거를 강제한 LLM 질문 생성 기술입니다. 실제 헤지펀드·자산운용사의 투자 워크플로 깊이나 알파 인텔리전스 도메인 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않으며, 그 깊이는 실제 바이사이드 실무자의 몫이고 면접에서 모르면 모른다고 말하는 편이 낫습니다. 데모는 합성 요청 시트로 기술만 보여줍니다
질문을 많이 만들수록 고객은 지칩니다. 요청 한 건당 질문을 3개로 제한하고, 이미 물어본 질문은 회신 대기로 묶어 다시 묻지 않게 하며, 답이 없어도 판정이 뒤집히지 않는 항목은 질문에서 뺍니다
고객사는 규제 환경 안에서 일하므로 보유 종목·포지션이 적힌 요청은 판정만 하고 본문을 확인 질문 파일에 옮기지 않고 가립니다. 실제 도입 시 고객사 컴플라이언스 규칙과 요청 시트 서식이 더미와 다르므로 필수 항목 목록과 마스킹 규칙을 다시 맞춰야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 리서치팀이 보내온 요청 트래커 엑셀에서 읽어 정규화한 요청 행. 결손 판정 규칙이 가장 먼저 훑는 표입니다. 빈 셀·우선순위 표기 흔들림·회사명 별칭·계정 미매핑·중복 요청을 일부러 섞고, label 로 정답 결손 유형을 심어 자가채점합니다.
| req_id | firm_name_raw | firm_id | requester_email | submitted_at | request_type | area_raw | body | priority_raw | expected_raw | repro_raw | contains_holdings | label |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| req_001 | Meridian Capital HK | firm_meridian | analyst@meridian-cap.hk | 2026-07-02 | bug | 미팅 인텔리전스 | 7월 1일 오전 리서치 미팅 녹취에서 화자 두 명이 한 사람으로 합쳐… | P1 | 화자별로 분리된 회의록 | 2026-07-01 09:30 HKT, 미팅 ID mtg_8842 | false | ready |
| req_002 | Meridian Capital HK | firm_meridian | ops@meridian-cap.hk | 2026-07-03 | feature | 결과물을 사내 양식으로 저장하고 싶습니다. | 높음 | 사내 양식으로 내보내기 | false | missing_area | ||
| req_003 | Nomura Sell-Side Desk | firm_nomura | desk@nomura-ss.jp | 2026-07-03 | data_coverage | 대체 데이터 | 일본 중소형주 커버리지가 부족합니다. | P2 | false | missing_source_window | ||
| req_004 | Lion City Asset Mgmt | firm_lioncity | ops@lioncity-am.sg | 2026-07-06 | bug | 딥리서치 | 질의 결과가 가끔 비어서 옵니다. | 질의마다 결과가 나와야 합니다 | false | missing_repro | ||
| req_005 | Han River Investments | firm_hanriver | pm@hanriver.co.kr | 2026-07-07 | feature | 딥리서치 | 현재 보유 중인 종목 목록 기준으로 리서치 결과를 정렬해 주면 좋겠습… | P1 | 보유 종목 기준 정렬 | true | compliance_unchecked |
아래 JSON Schema 에 맞는 고객사 요청 행 60건을 JSON 배열로 생성합니다. 계정은 홍콩·싱가포르·도쿄·서울에 고르게 두고, 요청 유형(bug·feature·data_coverage·training·integration)도 고르게 섞습니다. label 규칙(우선순위 순으로 하나만 고름): (1) firm_id=null 이거나 requester_email 도메인이 계정 매핑표에 없음 → unmapped_requester, (2) contains_holdings=true 인데 body 에 대외 공유 승인 표기가 없음 → compliance_unchecked, (3) 같은 firm_id 에서 request_type·area_raw·repro_raw 가 같은 선행 요청이 있음 → duplicate, (4) area_raw 가 빈 문자열이거나 제품 기능 영역(딥리서치·미팅 인텔리전스·대체 데이터·API·온보딩·리포트 내보내기) 어디에도 매칭되지 않음 → missing_area, (5) request_type=bug 인데 repro_raw 에 날짜·시각 또는 식별자가 없음 → missing_repro, (6) request_type=data_coverage 인데 body·expected_raw 에 데이터 소스나 기간이 없음 → missing_source_window, (7) expected_raw 가 빈 문자열 → missing_expected, (8) 그 외 → ready.
{"type":"object","properties":{"req_id":{"type":"string"},"firm_name_raw":{"type":"string"},"firm_id":{"type":["string","null"]},"requester_email":{"type":"string"},"submitted_at":{"type":"string"},"request_type":{"type":"string","enum":["bug","feature","data_coverage","training","integration"]},"area_raw":{"type":"string"},"body":{"type":"string"},"priority_raw":{"type":"string"},"expected_raw":{"type":"string"},"repro_raw":{"type":"string"},"contains_holdings":{"type":"boolean"},"label":{"type":"string","enum":["ready","missing_area","missing_repro","missing_expected","missing_source_window","unmapped_requester","compliance_unchecked","duplicate"]}},"required":["req_id","firm_name_raw","firm_id","requester_email","submitted_at","request_type","area_raw","body","priority_raw","expected_raw","repro_raw","contains_holdings","label"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(갖춰진 요청만 통과시키는 함정 회피): (1) 회사명 표기 흔들림: 같은 firm_id 인데 firm_name_raw 만 다른 별칭 3건 이상, (2) 우선순위 표기 흔들림: P1·높음·urgent·빈칸을 섞어 5건 이상, (3) 중복: 같은 계정에서 문구만 다른 같은 요청 3건, (4) 계정 미매핑: firm_id=null 이거나 사외 도메인 요청자 2건, (5) 보유 종목·포지션이 본문에 적힌 요청 2건, (6) expected_raw·repro_raw 가 모두 비었지만 규칙 우선순위 때문에 label 이 missing_repro 로 정해지는 경계 케이스 2건. label 은 위 규칙대로 정직하게. 진짜 스키마 위반(타입 깨짐)은 데이터가 아니라 별도 '형식 깨뜨리기 시도 3건' 지시로만 재현. JSON 배열만.{"type":"object","properties":{"req_id":{"type":"string"},"firm_name_raw":{"type":"string"},"firm_id":{"type":["string","null"]},"requester_email":{"type":"string"},"submitted_at":{"type":"string"},"request_type":{"type":"string","enum":["bug","feature","data_coverage","training","integration"]},"area_raw":{"type":"string"},"body":{"type":"string"},"priority_raw":{"type":"string"},"expected_raw":{"type":"string"},"repro_raw":{"type":"string"},"contains_holdings":{"type":"boolean"},"label":{"type":"string","enum":["ready","missing_area","missing_repro","missing_expected","missing_source_window","unmapped_requester","compliance_unchecked","duplicate"]}},"required":["req_id","firm_name_raw","firm_id","requester_email","submitted_at","request_type","area_raw","body","priority_raw","expected_raw","repro_raw","contains_holdings","label"]}현장 미팅에서 손으로 적어 온 고객 요청 메모. LLM 이 여기서 요청 항목을 뽑아 트래커 행과 합칩니다. 한 노트에 요청이 둘 이상 들어 있거나 계정이 불분명한 메모를 일부러 섞어, 깔끔한 메모만 처리되는 일이 없게 합니다.
회의록 화자 구분이 자주 틀린다는 이야기를 다시 들었습니다. 애널리스트가 매번 손으로 고치고 있어 불편해합니다.
일본 로컬 데이터 소스를 붙여 달라는 요청과 함께, 붙으면 좌석을 늘리겠다는 이야기를 같이 들었습니다. 어떤 소스인지 이름은 적어 두지 못했습니다.
아래 JSON Schema 에 맞는 현장 미팅 메모 40개를 JSON 배열로 생성합니다. title 은 'note_### · 계정/팀' 형식, body 는 2~3문장 한국어 존댓말입니다. 제품 기능 영역(딥리서치·미팅 인텔리전스·대체 데이터·API·온보딩·리포트 내보내기)과 요청 유형(버그·기능·데이터 커버리지·교육·연동)을 고르게 섞습니다.
{"type":"object","properties":{"title":{"type":"string"},"body":{"type":"string"}},"required":["title","body"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(깔끔한 메모만 처리되는 함정 회피): (1) 한 메모에 요청이 둘 이상 섞인 케이스 3건, (2) 계정을 특정할 수 없는 메모 2건, (3) 같은 회사의 다른 팀 요청으로 기능 영역이 갈리는 케이스 2건, (4) 이미 트래커에 있는 요청과 같은 내용을 문구만 바꿔 적은 케이스 2건, (5) 시각·수치가 없어 재현 조건이 서지 않는 버그 메모 3건, (6) 보유 종목이나 포지션을 입으로 언급한 케이스 2건. JSON 배열만.{"type":"object","properties":{"title":{"type":"string"},"body":{"type":"string"}},"required":["title","body"]}| Python | 엑셀·노트 파싱, 결손 판정 규칙 엔진, 확인 질문 생성, 채점 도구를 구현하는 언어입니다(pandas·openpyxl·typer) |
| SQL | 정규화한 요청을 DuckDB 테이블로 올려 계정·요청 유형별 결손 분포와 중복 후보를 뽑는 질의입니다 |
| LLM | 자유서술 미팅 노트에서 요청 항목을 뽑고 결손마다 고객에게 보낼 확인 질문 문장을 쓰는 엔진입니다 |
| Claude | 요청 항목 추출과 확인 질문 작성을 맡는 LLM 입니다(Claude Sonnet) |
| AI agents | 3주차에 상담사가 터미널에서 요청·회신 상태를 자연어로 묻는 에이전트입니다 |
| MCP | 3주차 에이전트에 요청·확인 질문·회신 상태를 도구로 노출해 질의에 답하게 잇는 규격입니다 |
| API | 요청을 파일 대신 사내 티켓 API 로 받을 때를 대비한 입력 어댑터와 인계 티켓 초안 내보내기입니다 |
| financial data platforms | 데이터 커버리지 요청에 소스(Bloomberg·Refinitiv·FactSet·S&P Global)와 기간이 적혔는지 확인하는 필수 항목 목록입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(판정이 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(회신 반영 재판정 + MCP 에이전트 질의)로 진행합니다.
요청 1건의 접수 점검 결과. 인계 가능 여부·결손 유형·인용 근거·고객에게 보낼 확인 질문을 한 스키마로 담아 계정별 확인 질문 파일과 인계 대기 목록에 씁니다. 요청의 가치 판단이 아니라 필수 항목이 채워졌는지에 대한 판정입니다.
{"type":"object","properties":{"req_id":{"type":"string"},"firm_id":{"type":["string","null"]},"status":{"type":"string","enum":["ready_for_handoff","needs_client_answer","duplicate","compliance_hold"]},"gaps":{"type":"array","items":{"type":"string","enum":["missing_area","missing_repro","missing_expected","missing_source_window","unmapped_requester","compliance_unchecked"]}},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"quote":{"type":"string"}},"required":["field","quote"]}},"questions":{"type":"array","items":{"type":"string"}},"duplicate_of":{"type":["string","null"]},"hedge":{"type":["string","null"]}},"required":["req_id","firm_id","status","gaps","evidence","questions","duplicate_of","hedge"]}[
{
"input_ref": "req_004 (버그인데 재현 조건 없음)",
"output": {
"req_id": "req_004",
"firm_id": "firm_lioncity",
"status": "needs_client_answer",
"gaps": [
"missing_repro"
],
"evidence": [
{
"field": "repro_raw",
"quote": ""
},
{
"field": "body",
"quote": "질의 결과가 가끔 비어서 옵니다."
}
],
"questions": [
"결과가 비어서 온 질의를 하나만 알려 주실 수 있을까요. 질의 문구와 실행한 날짜·시각(현지 기준)이면 충분합니다.",
"같은 질의를 다시 실행하면 항상 비어서 오는지, 가끔만 그런지 알려 주시면 좋겠습니다."
],
"duplicate_of": null,
"hedge": "재현 조건이 없어 엔지니어링 인계를 보류합니다"
}
},
{
"input_ref": "req_003 (커버리지 요청인데 소스·기간 없음)",
"output": {
"req_id": "req_003",
"firm_id": "firm_nomura",
"status": "needs_client_answer",
"gaps": [
"missing_source_window"
],
"evidence": [
{
"field": "body",
"quote": "일본 중소형주 커버리지가 부족합니다."
},
{
"field": "expected_raw",
"quote": ""
}
],
"questions": [
"어떤 데이터 소스 기준으로 부족하다고 보셨는지 알려 주실 수 있을까요(Bloomberg·Refinitiv·FactSet·S&P Global 중).",
"필요한 기간이 언제부터 언제까지인지, 우선 확인하고 싶은 종목 코드가 있다면 함께 알려 주시면 좋겠습니다."
],
"duplicate_of": null,
"hedge": "소스와 기간이 없으면 커버리지 범위를 산정하지 못합니다"
}
},
{
"input_ref": "req_005 (보유 종목이 본문에 포함)",
"output": {
"req_id": "req_005",
"firm_id": "firm_hanriver",
"status": "compliance_hold",
"gaps": [
"compliance_unchecked"
],
"evidence": [
{
"field": "contains_holdings",
"quote": "true"
},
{
"field": "body",
"quote": "목록은 첨부한 포지션 파일에 있습니다."
}
],
"questions": [
"첨부하신 포지션 파일을 저희 엔지니어링팀과 공유해도 되는지 확인 부탁드립니다.",
"공유가 어렵다면 종목명을 가린 형태로 같은 정렬 기능을 검토해도 될지 알려 주시면 좋겠습니다."
],
"duplicate_of": null,
"hedge": "반출 승인 표기가 없어 본문을 그대로 옮기지 않고 가린 채 보류합니다"
}
}
][자동 검증] 1. JSON Schema parse 로 출력 형식(필드·enum)이 스키마를 통과하는지 확인합니다. 2. status·gaps 가 결손 판정 규칙(계정 미매핑→needs_client_answer·반출 승인 없음→compliance_hold·선행 요청 일치→duplicate·필수 항목 결손→needs_client_answer·그 외→ready_for_handoff)과 일치하는지 봅니다. 3. evidence 의 field·quote 가 입력 요청 행의 실제 필드·값 인용인지 토큰 매칭으로 확인하고, 인용을 못 다는 질문은 걸러 냅니다. 4. 요청 한 건당 questions 가 3개를 넘지 않는지, ready_for_handoff 인데 questions 가 남아 있지 않은지 봅니다. 5. gaps 를 심은 정답 label 과 비교해 정확도를 계산합니다. [수동 검증] 1. 상담사 2명이 비동기로 결손 유형을 라벨링해 정확도와 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 만들어진 확인 질문을 사람이 읽고 고객에게 그대로 보낼 만한 문장인지 검수하며, 전체의 5% 를 직접 점검합니다.
포트폴리오가 “무엇을 만들지”라면, 시나리오 테스트는 “현장에서 어떻게 판단·소통할지” 입니다. 실제 이 채용공고 맥락의 대본을 읽고 무엇을 물어야 할지 직접 써봅니다.
근거: Act as the communication bridge across research, engineering, and GTM