링크알파는 기관투자자용 에이전트 제품에서 한 번의 대화가 웹 클라이언트에서 다수 백엔드, 세션 격리 에이전트 런타임, 도구 계층(MCP), 실시간 스트리밍(SSE)까지 흐르고, 이 경로 전체를 그려 어디서 지연·병목·실패가 생기는지 짚어낼 사람을 찾습니다. 또한 여러 서비스와 두 데이터 저장소(비즈니스 레이어와 런타임 레이어)를 가로질러 한 요청을 끝까지 추적·디버깅하는 능력을 명시적으로 요구합니다. 이 포트폴리오는 바로 그 요청 경로를 구간 로그로 받아 규칙으로 정상·지연·실패를 가르고 병목 구간을 짚는 사슬을 그대로 재현합니다. 이 hop 구성(web·backend·agent_runtime·mcp_tool·sse_stream)과 두 계층 저장소 추적은 링크알파의 실제 요청 흐름이 있어야 의미가 있어, 단순 로그 대시보드 맥락으로는 그대로 만들 수 없습니다. 다만 이 포트폴리오가 입증하는 것은 분산 요청 추적·구간 분류·병목 지목이라는 엔지니어링 기술이며, buy/sell-side 리서치의 금융 도메인 전문성은 주장하지 않습니다.
한 번의 대화가 웹 클라이언트에서 다수 백엔드, 세션 격리 에이전트 런타임, 도구 계층(MCP), 실시간 스트리밍(SSE)으로 흐릅니다. 이 경로 전체를 그리고 어디서 지연·병목·실패가 생기는지 짚어내는 능력이 이 포트폴리오의 골조입니다.
여러 서비스와 두 개의 데이터 저장소(비즈니스 레이어와 런타임 레이어)를 가로질러 한 번의 요청을 끝까지 따라가고, 로그·트레이스·메트릭으로 프로덕션 문제를 진단합니다. 요청 경로 추적 게이트가 이 업무와 정면으로 정렬됩니다.
백그라운드 태스크는 계속 돌리면서 부분 결과를 SSE 로 스트리밍해 레이턴시를 최소화하는 구조를 다룹니다. SSE 첫 조각 지연·스톨을 구간 지연으로 잡아 병목을 짚는 것이 이 제품의 핵심 각도입니다.
기관투자자용 에이전트 런타임의 요청 경로 추적 게이트입니다. 한 번의 요청이 남긴 구간 로그(web_client·backend·agent_runtime·mcp_tool·sse_stream span)를 한 스키마로 받아, hop 별 지연 예산(SLO)과 실패·타임아웃·계측 유실 규칙으로 각 구간을 정상·지연·실패로 가르고, 요청 전체를 정상·점검(지연)·실패로 롤업합니다. 병목이 어느 구간인지 지목하고 반복되는 장애 패턴을 서비스·고객사별로 묶어 우선순위로 알립니다. 정상·실패 여부는 지연 예산·상태 규칙이 결정하고, LLM 은 장애 사유 설명·태깅 보조만 맡습니다. 근거는 채용공고 정렬이고, 데이터는 작성자가 만든 더미입니다.
링크알파 FDE. 고객사에서 에이전트 응답이 느리거나 끊길 때 웹·백엔드·런타임·도구·스트리밍 로그를 흩어진 채로 뒤져 병목 구간을 매번 손으로 찾던 일을, 한 게이트에서 구간 판정·병목 지목·반복 장애 묶음을 함께 보고 싶은 사람입니다.
요청의 구간 로그를 한 스키마로 묶으면, (a) hop 별 지연 예산과 실패·타임아웃·계측 유실 규칙으로 각 구간을 결정론적으로 정상·지연·실패로 가르고, (b) 요청 전체 판정과 병목 구간을 근거 스팬 인용으로 풀며, (c) 여러 서비스·고객사의 요청을 끊김 없이 분류하고 반복 장애 패턴을 묶어 우선순위로 알릴 수 있습니다.
요청의 구간 로그를 받아 규칙으로 정상·지연·실패를 가르고 병목 구간을 지목하며 반복 장애를 서비스·고객사별로 묶어 알리는 동작하는 게이트입니다. 스팬은 요청 경로를 가정한 합성 트레이스 더미로 시작하고, 실 OpenTelemetry·Datadog 연동과 세션 격리 런타임은 2·3주차로 둡니다.
구간·요청 판정과 병목 지목을 심은 정답·검토자 2명 라벨과 비교해 정밀도·재현율과 일치도를 보여주는 화면입니다. SSE 첫 조각 지연 스톨 재현 케이스를 더해 스트리밍 병목까지 잡습니다.
OpenTelemetry·Datadog 스팬을 입력에 연결하고, 게이트를 K8s(Helm/ArgoCD)로 올려 세션 격리 런타임·오토스케일(KEDA/HPA)·warm pool 가정과 잇습니다. 고객사별 SLO 를 설정으로 분기합니다.
요청 시나리오 12종(정상·런타임 지연·도구 타임아웃·백엔드 오류·스트리밍 스톨)을 넣으면, 각 구간 판정과 요청 전체 판정·병목 구간이 몇 초 안에 나오는 걸 시연합니다.
일부러 만든 악성·결측 입력 30종(지연 값 null·미등록 서비스·서비스 표기 흔들림·SLO 경계값)을 넣어도 출력 형식(JSON Schema)이 한 번도 안 깨지고, 확인 불가한 구간은 정상으로 넘기지 않고 점검(지연)으로 빠집니다.
더미에 심은 정답 40건 중 요청 판정(정상·점검·실패)이 일치한 게 36건(약 90%)이고 병목 hop 지목이 맞은 게 34건(약 85%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 합성 트레이스 자가채점이며, 실제 정밀도·재현율은 링크알파의 실 요청 트레이스와 실 SRE·검토자가 있어야 측정 가능합니다. 이 게이트는 그 연동을 바로 붙일 수 있는 상태까지 만듭니다.
이건 실 트레이스·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실연동 준비 상태로 솔직히 설명하는 게 오히려 신뢰를 줍니다.
정답을 작성자가 만들었으니 잘 맞는 게 당연합니다. 그래서 지연 값 결측·미등록 서비스·서비스 표기 흔들림·SLO 경계값 같은 하드 케이스를 더미에 일부러 섞어, 쉬운 분류만 통과시키는 게 아님을 보여줍니다.
병목 지목에는 상류 대기가 하류 구간의 지연으로 보이는 착시(상관과 인과가 다른 문제)가 있습니다. 그래서 지연을 구간별로 분리해 보고, 애매하면 실패로 단정하지 않고 점검으로 돌립니다. 상관과 인과 판단은 실 트레이스 spot check 로 분리해 봅니다.
이 포트폴리오가 입증하는 것은 구간 로그 분류 규칙·병목 지목·반복 장애 묶음·요청 경로 추적이라는 엔지니어링 기술입니다. buy/sell-side 리서치의 금융 도메인 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않으며, 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다.
실제 도입 시 달라지는 것을 분리해 둡니다. hop 별 지연 예산(SLO)과 서비스 구성은 실 아키텍처에 맞춰 다시 맞춰야 하고, 합성 트레이스는 실 OpenTelemetry·Datadog 분포로, 단일 프로세스 가정은 세션 격리 K8s 런타임으로, 시뮬 검토자는 실 SRE 로 교체해야 합니다(도입 단계 과제로 분리).
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
에이전트 한 요청이 경로를 지나며 남긴 구간(span) 로그. 분류 규칙이 가장 먼저 질의하는 테이블입니다. 지연 값 결측·미등록 서비스·서비스 표기 흔들림·SLO 경계값을 일부러 섞고, label 로 구간 정답을 심어 자가채점합니다.
| span_id | request_id | customer_id | service_raw | service_id | hop | status | latency_ms | model | error_code | label | ts |
|---|---|---|---|---|---|---|---|---|---|---|---|
| sp_0001 | req_1001 | cust_hedge_a | web | svc_web | web_client | ok | 120 | — | — | ok | 2026-05-11T09:00:01 |
| sp_0002 | req_1001 | cust_hedge_a | gateway-api | svc_backend | backend | ok | 210 | — | — | ok | 2026-05-11T09:00:01 |
| sp_0003 | req_1001 | cust_hedge_a | agent-runtime | svc_runtime | agent_runtime | ok | 3,200 | claude-sonnet-4.5 | — | ok | 2026-05-11T09:00:02 |
| sp_0004 | req_1001 | cust_hedge_a | mcp-doc-search | svc_mcp | mcp_tool | ok | 900 | — | — | ok | 2026-05-11T09:00:03 |
| sp_0005 | req_1001 | cust_hedge_a | sse | svc_sse | sse_stream | ok | 800 | — | — | ok | 2026-05-11T09:00:04 |
아래 JSON Schema 에 맞는 요청 경로 구간(span) 로그 48행 JSON 배열로 생성. 한 request_id 아래 web_client → backend → agent_runtime → mcp_tool → sse_stream 순서의 스팬을 묶고, 요청 8~12건 분량으로.
{"type":"object","properties":{"span_id":{"type":"string"},"request_id":{"type":"string"},"customer_id":{"type":["string","null"]},"service_raw":{"type":"string"},"service_id":{"type":["string","null"]},"hop":{"type":"string","enum":["web_client","backend","agent_runtime","mcp_tool","sse_stream"]},"status":{"type":"string","enum":["ok","error","timeout"]},"latency_ms":{"type":["number","null"]},"model":{"type":["string","null"]},"error_code":{"type":["string","null"]},"label":{"type":"string","enum":["ok","slow","failed"]},"ts":{"type":"string"}},"required":["span_id","request_id","service_raw","hop","status","label","ts"]}
hop 별 지연 예산(SLO, latency_ms 상한): web_client 300, backend 500, agent_runtime 4000, mcp_tool 2000, sse_stream 1500. label 규칙: status 가 error 또는 timeout 이면 failed, latency_ms 가 null(계측 유실)이면 slow, latency_ms 가 그 hop 의 SLO 를 넘으면 slow, 그 외 정상이면 ok.
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 문제만 푸는 함정 회피): (1) 같은 서비스의 표기 별칭(같은 hop 이 'agent-runtime'/'런타임'/'agent_runtime-pod-3' 처럼 들어와 service_id 로 정규화돼야 함) 3종 이상, (2) service_id=null 인 미등록 서비스(서비스 마스터에 없어 '미매핑'으로 알려야 함) 1~2건, (3) latency_ms=null 계측 유실 1~2건, (4) 경계값: SLO 를 근소하게 넘긴 slow 와 SLO 바로 아래 ok 각 1건, timeout·error 각 1건, (5) sse_stream 에서 첫 조각까지 지연이 큰 스톨 케이스 1건. label 은 위 규칙대로 정직하게. JSON 배열만.{"type":"object","properties":{"span_id":{"type":"string"},"request_id":{"type":"string"},"customer_id":{"type":["string","null"]},"service_raw":{"type":"string"},"service_id":{"type":["string","null"]},"hop":{"type":"string","enum":["web_client","backend","agent_runtime","mcp_tool","sse_stream"]},"status":{"type":"string","enum":["ok","error","timeout"]},"latency_ms":{"type":["number","null"]},"model":{"type":["string","null"]},"error_code":{"type":["string","null"]},"label":{"type":"string","enum":["ok","slow","failed"]},"ts":{"type":"string"}},"required":["span_id","request_id","service_raw","hop","status","label","ts"]}| Python | 구간 로그 파서·hop 별 SLO 분류 규칙·병목 지목·반복 장애 클러스터링의 구현 언어입니다 |
| TypeScript | Next.js 콘솔(요청 경로 워터폴 뷰·구간 판정 카드·장애 묶음 대시보드) 프런트 로직과 런타임 스키마 검증입니다 |
| FastAPI | 게이트를 노출하는 백엔드 + 스팬 수집(ingest) 엔드포인트입니다 |
| SSE | 스트리밍 구간의 첫 조각 지연·스톨을 지연 예산으로 잡아 병목을 짚는 대상 hop 입니다 |
| MCP | 에이전트가 호출하는 도구 계층 hop 으로, 도구 호출 타임아웃·지연을 병목으로 분류합니다 |
| LangGraph | 파싱 → 구간 분류 → 요청 롤업 → 장애 묶음 노드를 잇는 처리 그래프입니다 |
| Claude Code SDK | 장애 사유 설명·태깅 보조 호출을 감싸는 골격입니다(판정은 규칙) |
| PostgreSQL | 두 계층 저장소를 가정합니다. 비즈니스 레이어(서비스 마스터·고객 SLO) vs 런타임 레이어(스팬·트레이스)를 나눠 담습니다 |
| Kubernetes | 3주차에 게이트와 에이전트 런타임을 Helm/ArgoCD(GitOps)로 배포하고 오토스케일(KEDA/HPA)·warm pool 가정을 잇습니다 |
| Terraform | 3주차에 런타임 인프라를 코드로 정의(IaC)해 배포와 함께 올립니다 |
| Datadog | 3주차에 실 관측성 스팬을 입력으로 연결해 합성 트레이스를 실 트레이스로 교체합니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(판정이 맞았는지 정답·검토자와 비교)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(실 트레이스 연동과 K8s 런타임 배포)로 진행합니다.
요청 1건의 경로 추적 카드. 요청 전체 판정(verdict)·병목 구간(root_hop)·원인(factors)·사유·근거를 한 스키마로 담아 화면 카드에 씁니다. 에이전트 답의 옳고 그름이 아니라 요청 경로의 정상·병목·실패 게이트입니다.
{"type":"object","properties":{"request_id":{"type":"string"},"verdict":{"type":"string","enum":["healthy","degraded","failed"]},"root_hop":{"type":["string","null"],"enum":["web_client","backend","agent_runtime","mcp_tool","sse_stream",null]},"factors":{"type":"array","items":{"type":"string","enum":["hop_timeout","hop_error","over_slo","missing_metric","unmapped_service"]}},"reason":{"type":"string","minLength":20},"evidence":{"type":"string","minLength":8},"hedge":{"type":["string","null"]}},"required":["request_id","verdict","factors","reason","evidence"]}[
{
"input_ref": "req_1002 (mcp_tool 구간 timeout, latency 유실)",
"output": {
"request_id": "req_1002",
"verdict": "failed",
"root_hop": "mcp_tool",
"factors": [
"hop_timeout"
],
"reason": "도구 계층(MCP)의 ttsql 호출이 타임아웃으로 끊겨 응답이 완결되지 못했습니다. 병목은 mcp_tool 구간이며 상위 백엔드·런타임은 정상 범위였습니다.",
"evidence": "sp_0008 status=timeout, error_code=TOOL_TIMEOUT",
"hedge": "타임아웃 구간이라 지연 원인이 도구 자체인지 상류 대기인지는 재현 확인이 필요합니다"
}
},
{
"input_ref": "req_1003 (agent_runtime 구간이 SLO 4000ms 초과)",
"output": {
"request_id": "req_1003",
"verdict": "degraded",
"root_hop": "agent_runtime",
"factors": [
"over_slo"
],
"reason": "에이전트 런타임 구간이 5200ms 로 지연 예산 4000ms 를 넘겨 느려졌습니다. 실패는 아니지만 이 구간이 응답 지연을 끌고 있어 점검 대상입니다.",
"evidence": "sp_0009 hop=agent_runtime, latency_ms=5200 (SLO 4000)",
"hedge": "단발 초과인지 반복 패턴인지는 서비스별 추이로 확인해야 합니다"
}
},
{
"input_ref": "req_1005 (미등록 서비스 + 계측 유실)",
"output": {
"request_id": "req_1005",
"verdict": "degraded",
"root_hop": "backend",
"factors": [
"unmapped_service",
"missing_metric"
],
"reason": "legacy-gw-x 서비스가 서비스 마스터에 없어 정상을 단정할 수 없고, 지연 값도 유실돼 성능을 확인할 수 없습니다. 정상으로 넘기지 않고 점검으로 둡니다.",
"evidence": "sp_0012 service_id=null, latency_ms=null",
"hedge": "미등록 서비스라 서비스 등록·계측 연결 후 재판단이 필요합니다"
}
}
][자동 검증: 규칙·결정론으로 객관 채점] 1. JSON Schema parse 통과(출력 형식이 안 깨지는지). 2. verdict 가 스팬 롤업 규칙과 일치하는지 확인합니다. 요청의 스팬 중 하나라도 failed 면 failed, failed 는 없고 slow 가 있으면 degraded, 전부 ok 면 healthy. 3. root_hop 이 규칙과 맞는지 봅니다. failed 요청은 failed 스팬의 hop, degraded 요청은 지연 예산(SLO) 초과폭이 가장 큰 hop. 4. factors 가 스팬 원인과 일치하는지 봅니다. status=timeout→hop_timeout, status=error→hop_error, latency_ms>SLO→over_slo, latency_ms=null→missing_metric, service_id=null→unmapped_service. 5. evidence 가 입력 스팬의 실제 필드 값(status·latency_ms·error_code) 인용인지 토큰 매칭으로 확인합니다. 6. verdict 를 심은 정답 label 롤업과 비교해 정밀도·재현율을 계산합니다. [수동 검증: 사람·LLM 보조] 1. 검토자 2명이 비동기로 요청별 verdict·root_hop 을 라벨링해, 두 사람 답이 우연 이상으로 일치하는 정도(Cohen's κ, 0~1)의 bootstrap 하한 0.6 이상을 봅니다. 2. 병목 hop 지목이 실제 원인과 맞는지(상류 대기가 하류로 보이는 착시 포함) 전체의 5% 를 사람이 직접 트레이스로 점검합니다.