렛서Forward Deployed Engineer, Client Lead
0.0렛서
경력근거: 범위·기간·투입 공수를 산정해 제안하고, 조건을 합의해 수주합니다
어제 확인채용 공고 보기
렛서 AX Partners는 한 곳에서 검증한 솔루션을 재사용 자산과 제품으로 키워 다음 고객사로 이어가는 구조라서, 인바운드 문의의 기간·투입 공수 산정이 '이 자산이 얼마나 재사용되는가'로 결정됩니다. 자산 인벤토리라는 회사 고유 맥락 없이 다른 회사 데이터로는 이 스코핑 사슬을 만들 수 없습니다. 이 포트폴리오는 문의를 자산에 매칭해 공수를 산정하는 기술을 보여주며, 렛서의 산업별 딜 판단 전문성 자체를 제가 갖췄다고 주장하지 않습니다. 공수와 자산 매칭은 규칙 엔진으로 객관 채점합니다.
진짜 문제가 뭔지 정의하고 범위·기간·조건을 합의해 계약으로 만드는 일이 한 사람 안에서 이어지는 역할이라, 문의를 구조화된 제안으로 바꾸는 판단이 핵심 자산입니다.
한 곳에서 검증한 솔루션을 재사용 자산과 제품으로 키워 다음 고객사로 이어가기 때문에, 기간·투입 공수 산정이 어느 자산을 얼마나 재사용하는지로 결정됩니다.
여러 건의 기회를 동시에 굴리면서 각각을 PoC로 멈출지 본계약으로 키울지 스스로 판단하는 일이라, 딜 단계 추천이 제품의 출력이 됩니다.
제조·유통·헬스케어·미디어·공공 등 여러 산업에서 들어오는 모호한 인바운드 문의를 받아, 진짜 문제 정의·제안 범위·재사용 자산 매칭·투입 공수(사람이 며칠 붙어야 하는지) 산정 근거·딜 단계 추천을 한 장의 스코핑 카드로 만들어 주는 AX 딜 스코핑 데스크입니다. 공수와 자산 매칭은 재사용 자산 인벤토리 규칙으로 다시 계산해 모델 출력과 대조합니다.
여러 산업에서 동시에 들어오는 인바운드 문의를 하나하나 읽고 '이건 어느 자산으로 며칠이면 되고 어디까지 끌고 갈 딜인가'를 매번 머릿속으로 재던지던 상황을, 문의를 붙여넣으면 제안 범위와 공수 근거가 정리된 카드로 한 화면에서 보고 싶은 딜 리드입니다.
모호한 인바운드 문의도 진짜 문제 유형과 재사용 자산 인벤토리에 매칭하면, 제안 범위와 투입 공수를 규칙으로 재현 가능하게 산정하고 딜 단계를 일관되게 추천할 수 있다고 봅니다.
모호한 인바운드 문의 하나를 붙여넣으면 문제 정의·매칭 자산·제안 범위·투입 공수 산정 근거·딜 단계 추천이 담긴 스코핑 카드 한 장을 생성하고, 자산 인벤토리 규칙으로 공수와 매칭을 다시 계산해 대조하는 웹 앱입니다. 자산 인벤토리는 사내 데이터를 가정한 더미 테이블로 시작합니다.
여러 문의에 대해 모델의 딜 단계 추천과 매칭 자산이 규칙 정답과 얼마나 일치하는지, 공수 추정이 규칙 계산값과 얼마나 벌어지는지 대조하는 리포트입니다. 예산 결측·미등록 산업·표기 흔들림을 섞은 케이스에서도 카드가 깨지지 않는지 함께 봅니다.
여러 문의를 동시에 올려 딜별 단계·예상 공수 합계·자산 재사용률을 한 화면에서 보는 파이프라인 대시보드와, 수주 가정된 딜에서 새 재사용 자산 후보를 뽑아 인벤토리에 제안하는 자산화 루프입니다.
모호한 인바운드 문의 한 건을 붙여넣으면 문제 정의·매칭 자산·제안 범위·투입 공수 산정 근거·딜 단계 추천이 담긴 스코핑 카드 한 장을 생성해 보여줍니다.
모델이 추천한 매칭 자산과 공수 합계가 자산 인벤토리 규칙(자산별 기본 공수 곱하기 재사용률)으로 재계산한 값과 맞는지 전 건 대조합니다. 단, 정답과 자산 데이터를 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건 동작'입니다.
예산 결측·미등록 산업·표기 흔들림을 섞은 악성·결측 문의 30종을 넣어도 카드 출력 형식(JSON 스키마)이 깨지지 않고, 인벤토리에 없는 자산은 '미매핑'으로 표시합니다.
위 수치는 더미 인바운드와 합성 자산 인벤토리로 잰 자가채점이며, 실제 스코핑 정확도와 공수 산정 오차는 렛서 실제 딜 이력과 실제 스코핑 리드의 판정이 있어야 측정 가능합니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답과 자산 인벤토리를 제가 만들었으니 잘 맞는 게 당연합니다. 결측·미등록·표기 흔들림·극단 예산 같은 경계 케이스를 더미에 일부러 섞어 쉬운 문제만 푸는 함정을 피합니다.
공수 산정은 자산 재사용률 가정에 민감하고, 재사용률은 실제 현장 변수(고객 데이터 정합성·조직 저항)에 따라 크게 흔들립니다. 자산이 매칭됐다고 공수가 준다고 단정하지 않고, 매칭은 근거일 뿐 인과가 아니라고 카드에 표시합니다.
실제 도입 시에는 실데이터 분포(실제 인바운드 문체·산업 분포)와 실 스코핑 리드로 정답 기준이 달라집니다. 규칙 엔진의 자산 인벤토리를 실제 자산으로 갈아끼우는 것을 도입 1단계 과제로 둡니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
여러 산업에서 들어오는 모호한 인바운드 문의입니다. 예산 결측·미등록 산업·표기 흔들림을 섞어 스코핑 카드가 쉬운 문제만 푸는 함정을 피하게 합니다.
| inquiry_id | industry_raw | industry_id | body | stated_budget_krw | urgency | contact_role |
|---|---|---|---|---|---|---|
| INQ-001 | 제조 | MFG | 생산 라인 불량 사진을 검사자가 눈으로 보고 엑셀에 적는데 사람마다 … | 40,000,000 | high | 생산팀장 |
| INQ-002 | 유통 | RETAIL | 고객 문의가 하루에 수백 건인데 상담원이 매번 비슷한 답을 손으로 씁… | — | mid | CS팀 리더 |
| INQ-003 | 헬스케어 | HEALTH | 환자 상담 기록이 자유 서술로 쌓이는데 나중에 찾아보기가 어렵습니다.… | 30,000,000 | mid | 원무과장 |
| INQ-004 | 제조업 | MFG | 설비 점검 일지가 종이로 쌓여서 이상 징후를 놓칩니다. 텍스트로 바꿔… | 25,000,000 | high | 설비보전 담당 |
| INQ-005 | manufacturing | MFG | We keep line inspection notes in sprea… | 50,000,000 | mid | Plant Manager |
다음 JSON Schema에 맞는 인바운드 문의 행을 더 만들어라: {"type":"object","properties":{"inquiry_id":{"type":"string"},"industry_raw":{"type":"string"},"industry_id":{"type":["string","null"]},"body":{"type":"string"},"stated_budget_krw":{"type":["integer","null"]},"urgency":{"type":"string","enum":["low","mid","high"]},"contact_role":{"type":["string","null"]}},"required":["inquiry_id","industry_raw","body","urgency"]}. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) 결측 예산 stated_budget_krw=null과 담당자 미상 contact_role=null, (2) 경계값 예산 0(진심도 낮은 문의), (3) 미등록 산업 industry_id=null(인벤토리 매칭이 미매핑으로 나와야 함), (4) 같은 산업의 표기 흔들림(제조/제조업/manufacturing이 모두 MFG로 정규화되어야 함). body는 고객도 자기 문제를 정확히 모르는 모호한 서술로 쓴다.{"type":"object","properties":{"inquiry_id":{"type":"string"},"industry_raw":{"type":"string"},"industry_id":{"type":["string","null"]},"body":{"type":"string"},"stated_budget_krw":{"type":["integer","null"]},"urgency":{"type":"string","enum":["low","mid","high"]},"contact_role":{"type":["string","null"]}},"required":["inquiry_id","industry_raw","body","urgency"]}한 곳에서 검증해 재사용 자산으로 정리한 제품 인벤토리입니다. 자산별 기본 공수와 최대 재사용률로 스코핑 카드의 공수 합계를 규칙으로 다시 계산하는 정답 근거가 됩니다.
| asset_id | name | domain_tags | base_man_days | max_reuse_pct | maturity | notes_raw |
|---|---|---|---|---|---|---|
| AST-01 | 이미지 결함 분류 파이프라인 | ["MFG","vision"] | 12 | 70 | productized | 제조 라인 검사에서 검증 |
| AST-02 | 반복 문의 답변 초안 봇 | ["RETAIL","cs"] | 8 | 75 | productized | — |
| AST-03 | 자유 서술 기록 구조화·검색 | ["HEALTH","rag"] | 15 | 60 | piloted | 상담 기록 검색 |
| AST-04 | 점검 일지 위험 표현 탐지 | ["MFG","nlp"] | 10 | 65 | piloted | — |
| AST-05 | 영상 자막·메타데이터 자동 초안 | ["MEDIA","multimodal"] | 18 | 55 | poc | 멀티모달, 초기 검증만 |
다음 JSON Schema에 맞는 재사용 자산 행을 더 만들어라: {"type":"object","properties":{"asset_id":{"type":"string"},"name":{"type":"string"},"domain_tags":{"type":"array","items":{"type":"string"}},"base_man_days":{"type":"number"},"max_reuse_pct":{"type":"integer","minimum":0,"maximum":80},"maturity":{"type":"string","enum":["poc","piloted","productized"]},"notes_raw":{"type":["string","null"]}},"required":["asset_id","name","domain_tags","base_man_days","max_reuse_pct","maturity"]}. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) notes_raw=null 결측, (2) 경계값 max_reuse_pct=0(재사용 이력 없어 매번 새로 만듦, 공수 감면 없음)과 max_reuse_pct=80(거의 그대로 재사용), (3) 특정 산업 태그가 없는 도메인 무관 자산(domain_tags에 common만)이라 어느 문의에도 붙을 수 있음, (4) maturity=poc라 재사용률이 낮은 자산. base_man_days는 현실적인 사람 투입 일수로 둔다.{"type":"object","properties":{"asset_id":{"type":"string"},"name":{"type":"string"},"domain_tags":{"type":"array","items":{"type":"string"}},"base_man_days":{"type":"number"},"max_reuse_pct":{"type":"integer","minimum":0,"maximum":80},"maturity":{"type":"string","enum":["poc","piloted","productized"]},"notes_raw":{"type":["string","null"]}},"required":["asset_id","name","domain_tags","base_man_days","max_reuse_pct","maturity"]}| Claude | 인바운드 문의 본문에서 진짜 문제를 정의하고, 매칭 자산·제안 범위·딜 단계 추천을 정해진 JSON 스키마로 생성하는 스코핑 카드 작성기입니다. |
| LLM·RAG | 재사용 자산 인벤토리를 검색해 문의와 관련된 자산 후보를 컨텍스트로 주입하는 검색 계층입니다. 자산이 많아져도 매칭 근거를 문의 문장과 함께 인용합니다. |
| Next.js 웹 풀스택 | 문의 입력·스코핑 카드 표시·파이프라인 대시보드를 한 화면에서 쓰는 프론트와 카드 생성 API를 담는 실행 골조로, 1주차 기본 배포는 Vercel로 바로 돌립니다. |
| SQL 자산 인벤토리 DB | 자산별 기본 공수·최대 재사용률·성숙도를 담아 공수 합계를 규칙으로 다시 계산하고 매칭을 대조하는 정답 근거 저장소입니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 2주차에 여러 문의로 추천과 규칙 정답의 일치도·공수 오차를 재고 악성·결측 케이스 강건성을 확인합니다.
✓ pass → 여기서 멈춰도 검증까지 완결입니다. 더 키우려면 3주차에 여러 딜을 한 화면에서 보는 파이프라인 대시보드와 새 자산 후보를 뽑는 자산화 루프로 확장합니다.
모호한 인바운드 문의 하나에 대한 스코핑 제안 카드입니다. 문제 정의·매칭 자산·제안 범위·투입 공수 산정 근거·딜 단계 추천을 담고, 각 항목이 어느 문의 문장과 어느 자산을 근거로 했는지 evidence로 추적합니다.
{"type":"object","properties":{"inquiry_id":{"type":"string"},"problem_statement":{"type":"string"},"matched_assets":{"type":"array","items":{"type":"object","properties":{"asset_id":{"type":["string","null"]},"reuse_pct":{"type":"integer"},"evidence_quote":{"type":"string"}},"required":["asset_id","reuse_pct","evidence_quote"]}},"scope_items":{"type":"array","items":{"type":"string"}},"estimated_man_days":{"type":"object","properties":{"low":{"type":"number"},"high":{"type":"number"},"basis":{"type":"string"}},"required":["low","high","basis"]},"deal_stage":{"type":"string","enum":["poc","pilot","main_contract","maintenance","decline"]},"evidence":{"type":"array","items":{"type":"object","properties":{"axis":{"type":"string"},"source":{"type":"string"},"value":{"type":"string"}},"required":["axis","source","value"]}},"risks":{"type":"array","items":{"type":"string"}},"hedge":{"type":"string"}},"required":["inquiry_id","problem_statement","matched_assets","estimated_man_days","deal_stage","evidence","hedge"]}[
{
"inquiry_id": "INQ-001",
"problem_statement": "생산 라인 불량을 검사자가 눈으로 판정해 사람마다 결과가 다르고 엑셀 기록이 흩어져 있는 문제입니다.",
"matched_assets": [
{
"asset_id": "AST-01",
"reuse_pct": 70,
"evidence_quote": "생산 라인 불량 사진을 검사자가 눈으로 보고 엑셀에 적는데"
},
{
"asset_id": "AST-11",
"reuse_pct": 80,
"evidence_quote": "이걸 자동으로 걸러 주면 좋겠는데"
}
],
"scope_items": [
"불량 이미지 분류 모델 이식",
"판정 결과 기록 화면",
"검사자 검토 흐름"
],
"estimated_man_days": {
"low": 4.4,
"high": 6.6,
"basis": "AST-01 기본 12일에 재사용률 70% 적용해 3.6일, AST-11 기본 4일에 80% 적용해 0.8일, 합계 약 4.4일을 하한으로 두고 현장 변수로 1.5배까지 상한을 잡은 합성 기준 추정입니다."
},
"deal_stage": "pilot",
"evidence": [
{
"axis": "problem",
"source": "inquiry_quote",
"value": "사람마다 판정이 달라요"
},
{
"axis": "asset_match",
"source": "AST-01",
"value": "제조 이미지 결함 분류 자산과 도메인 태그 MFG 일치"
},
{
"axis": "man_days",
"source": "AST-01+AST-11",
"value": "기본 공수 곱하기 재사용률 규칙 합산"
}
],
"risks": [
"실제 불량 이미지 분포가 자산 검증 때와 다르면 재사용률이 낮아져 공수가 늘 수 있습니다."
],
"hedge": "공수와 재사용률은 합성 자산 인벤토리 기준 추정이며, 실제 딜 이력으로 재보정이 필요합니다."
},
{
"inquiry_id": "INQ-009",
"problem_statement": "구체 문제 없이 'AI를 해야 할 것 같다'는 낮은 진심도의 탐색 문의로, 예산이 0으로 표기돼 있습니다.",
"matched_assets": [
{
"asset_id": null,
"reuse_pct": 0,
"evidence_quote": "뭘 할 수 있는지 궁금합니다"
}
],
"scope_items": [
"무료 진단 미팅으로 문제 구체화 먼저"
],
"estimated_man_days": {
"low": 0.5,
"high": 1,
"basis": "구체 범위가 없어 자산 매칭이 미매핑이라 산정 불가에 가깝고, 진단 미팅 반나절만 잡은 합성 기준 추정입니다."
},
"deal_stage": "decline",
"evidence": [
{
"axis": "intent",
"source": "inquiry_quote",
"value": "우리도 뭔가 해야 할 것 같아서"
},
{
"axis": "budget",
"source": "inquiry_quote",
"value": "예산 0으로 진심도 낮음"
}
],
"risks": [
"지금은 보류로 두되 나중에 문제가 구체화되면 재접수할 수 있게 표시합니다."
],
"hedge": "딜 단계 판단은 합성 문의 기준이며 실제로는 대표 의사와 예산 확인이 더 필요합니다."
},
{
"inquiry_id": "INQ-012",
"problem_statement": "운송장·통관 서류에서 항목 누락을 사람이 못 잡아 사후 문제가 되는데, 산업이 인벤토리에 미등록입니다.",
"matched_assets": [
{
"asset_id": "AST-09",
"reuse_pct": 0,
"evidence_quote": "누락을 자동으로 짚어 주면 좋겠어요"
}
],
"scope_items": [
"서류 누락 탐지 로직 신규 구현",
"서식별 필수 항목 정의"
],
"estimated_man_days": {
"low": 11,
"high": 16.5,
"basis": "AST-09는 재사용률 0%라 기본 11일을 감면 없이 하한으로 두고, 서식 다양성으로 1.5배까지 상한을 잡은 합성 기준 추정입니다."
},
"deal_stage": "poc",
"evidence": [
{
"axis": "asset_match",
"source": "AST-09",
"value": "물류 서류 자산이나 재사용 이력 없어 공수 감면 없음"
},
{
"axis": "industry",
"source": "inquiry_quote",
"value": "산업 미등록이라 industry_id 미매핑으로 표시"
}
],
"risks": [
"재사용률 0 자산이라 공수가 크고, 서식이 화주마다 달라 범위가 넓어질 위험이 있습니다."
],
"hedge": "누락 탐지 정확도는 실제 서류가 있어야 재는 값이며, 여기 공수는 합성 기준 추정입니다."
}
][자동 검증 (규칙 엔진)] 1. JSON 스키마 통과: 필수 필드와 deal_stage enum(poc·pilot·main_contract·maintenance·decline)만 허용해 형식이 깨진 출력을 거릅니다. 2. 공수 재계산 대조: estimated_man_days를 자산 인벤토리의 base_man_days 곱하기 (1 빼기 max_reuse_pct)로 다시 계산해 모델 값과 벌어지는지 봅니다. 3. 매칭 근거 존재: matched_assets의 asset_id가 인벤토리에 실재하는지, 없으면 null(미매핑)로 왔는지 확인합니다. 4. evidence 인용 검증: evidence의 source가 inquiry_quote면 그 문장이 문의 body의 실제 부분 문자열인지, asset_id면 인벤토리에 있는지 대조합니다. [수동 검증 (사람)] 1. 문제 정의가 문의의 진짜 문제를 짚었는지 스코핑 리드가 읽고 판단합니다. 2. 딜 단계 추천(예: decline vs pilot)이 회사 서비스 범위와 과금 체계에 맞는지 확인합니다. 이 판단은 규칙으로 못 잡는 부분이라 도입 시 실제 리드 검수가 필요합니다.