마키나락스 FDE 본부의 이 포지션은 AI 모델·에이전트를 감싼 애플리케이션 백엔드를 REST API·DB 로 구현하고 Kubernetes 플랫폼에서 배포·운영합니다. API 호출에서 실패·지연·이상 엔드포인트를 먼저 띄우는 이 대시보드는 그 백엔드 운영 엔지니어링을 정면으로 입증합니다. 실제 서비스 내부 구조 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않습니다. 호출 신호를 점검 진단과 배포 점검으로 잇는 사슬은 단순 로그 조회 맥락으로는 그대로 만들 수 없습니다.
다양한 AI 모델·에이전트를 쉽게 쓰게 하는 AI 애플리케이션 백엔드를 구현하고 REST API·DB 스키마를 설계·최적화합니다. API 운영 대시보드가 직접 정렬됩니다.
마키나락스 Kubernetes 기반 플랫폼에서 서비스 배포·운영을 지원합니다. 백엔드 운영 대시보드가 환경과 정렬됩니다.
LLM 실적용 성공 사례를 늘리고 전체 수행 효율을 개선하는 체계를 함께 만듭니다. API 운영이 비즈니스와 정렬됩니다.
AI 애플리케이션 API 호출 집계(엔드포인트·모델·메서드·호출 수·실패율·p95 지연·전일 대비 변화·이상 플래그)를 한 대시보드에 모아, 규칙(실패율 급증·지연 급증·이상 응답·결측)으로 점검이 필요한 엔드포인트를 잡고 원인을 LLM 이 호출 근거를 인용해 풀어줍니다. 엔드포인트·모델 마스터를 붙여 표기를 정규화합니다.
마키나락스 AI 애플리케이션 백엔드 엔지니어. 점검이 필요한 엔드포인트를 로그·APM 을 일일이 뒤져 찾던 일을, 한 대시보드에서 점검 엔드포인트와 원인을 함께 보고 싶은 사람입니다.
API 호출을 한 스키마로 묶고 엔드포인트·모델 마스터를 붙이면, (a) 실패율 급증·지연 급증·이상 응답을 규칙으로 잡고, (b) 원인을 LLM 이 호출 근거를 인용해 풀며, (c) 많은 엔드포인트를 모델별로 끊김 없이 보여줍니다.
API 호출 집계를 받아 점검이 필요한 엔드포인트를 규칙으로 잡고 원인을 LLM 이 푸는 동작하는 대시보드입니다. 데이터는 호출 텔레메트리를 가정한 더미로 시작합니다.
점검 엔드포인트 판정을 심은 정답·운영 검토자 2명 라벨과 비교해 정밀도·재현율과 일치도를 보여주는 화면입니다.
엔드포인트·모델별 안정성 지표와 점검 사유 분포를 누적 집계해 약점을 보여주는 대시보드입니다.
점검 엔드포인트 시나리오 12종(실패율·지연 급증)을 넣으면, 점검 카드와 원인이 몇 초 안에 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(지연 null·미등록 엔드포인트·표기 흔들림)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다
더미에 심은 정답 40건 중 점검 엔드포인트 판정이 일치한 게 36건(약 90%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 정밀도·재현율은 마키나락스의 실 호출 텔레메트리와 실 검토자가 있어야 측정 가능합니다. 이 도구는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명하는 게 오히려 신뢰를 줍니다
이 포트폴리오가 입증하는 것은 API 호출 텔레메트리를 모아 점검 규칙으로 잡고 근거를 붙이는 백엔드 운영 엔지니어링입니다. 실제 마키나락스 서비스 내부 구조 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않으며, 모르는 깊이는 면접에서 솔직히 말하는 편이 낫습니다
정답을 작성자가 만들었으니 잘 맞는 게 당연합니다. 그래서 지연 누락·미등록 엔드포인트·실패 경계 같은 결측·경계 케이스를 더미에 일부러 섞어, 쉬운 엔드포인트만 푸는 게 아님을 보여줍니다
점검 엔드포인트 원인은 외부 모델 지연·트래픽 급증 등 정당한 사유가 있을 수 있습니다. 점검은 규칙이 정하고 설명은 단정 대신 '확인·배포 점검 권고'로 표시합니다
엔드포인트·모델 표기가 제각각입니다. 정규화로 같은 엔드포인트로 묶고, 못 묶은 건 추측하지 말고 '미매핑'으로 알립니다. 실제 도입 시 호출 분포·서비스 구성이 더미와 다르므로 규칙 임계를 다시 맞춰야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
AI 애플리케이션 API 호출 집계 로그. 점검 규칙·원인 설명이 가장 먼저 질의하는 테이블입니다. 지연 결측·미등록 엔드포인트·표기 흔들림·실패 경계값을 일부러 섞고, label 로 정답을 심어 자가채점합니다.
| row_id | endpoint_raw | endpoint_id | model | method | calls | fail_rate | p95_ms | prev_p95_ms | label | ts |
|---|---|---|---|---|---|---|---|---|---|---|
| ac_001 | /infer | ep_infer | llm | POST | 5,000 | 0.01 | 800 | 800 | ok | 2026-03-04T09:00 |
| ac_002 | /infer | ep_infer | llm | POST | 4,800 | 0.35 | 5,200 | 820 | issue | 2026-03-05T09:00 |
| ac_003 | /vision | ep_vision | vlm | POST | 2,000 | 0.02 | 1,200 | 1,200 | ok | 2026-03-04T10:00 |
| ac_004 | /vision | ep_vision | vlm | POST | 1,000 | — | — | 1,200 | ok | 2026-03-04T11:00 |
| ac_005 | /newep | — | agent | POST | 600 | 0.01 | 900 | 880 | ok | 2026-03-04T12:00 |
아래 Zod 스키마에 맞는 AI API 호출 집계 60행 JSON 배열로 생성합니다. 엔드포인트 5~7개, 모델(llm/vlm/agent) 분포, 정상 위주에 이슈를 섞습니다. label 규칙: fail_rate>=0.2 또는 p95_ms 가 prev_p95_ms 의 3배 이상이면 issue, 결측이면 보류해 ok.
z.object({ row_id: z.string(), endpoint_raw: z.string(), endpoint_id: z.string().nullable(), model: z.enum(["llm","vlm","agent"]), method: z.enum(["GET","POST"]), calls: z.number().int(), fail_rate: z.number().nullable(), p95_ms: z.number().int().nullable(), prev_p95_ms: z.number().int().nullable(), label: z.enum(["ok","issue"]), ts: z.string() })
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 엔드포인트만 푸는 함정 회피): (1) 같은 엔드포인트의 표기 별칭('/infer'/'/infer '(공백)처럼 정규화돼야 함) 3건 이상, (2) 미등록 엔드포인트(endpoint_id=null) 2건, (3) 결측: fail_rate/p95_ms 가 null 인 행 각 1~2건, (4) 경계값 실패율 급증(0.2~0.35)·지연 급증(3~5배) 각 2건, (5) 같은 엔드포인트가 실패·지연 동반 악화 2~3건. label 은 위 규칙대로 정직하게. JSON 배열만.z.object({ row_id: z.string(), endpoint_raw: z.string(), endpoint_id: z.string().nullable(), model: z.enum(["llm","vlm","agent"]), method: z.enum(["GET","POST"]), calls: z.number().int(), fail_rate: z.number().nullable(), p95_ms: z.number().int().nullable(), prev_p95_ms: z.number().int().nullable(), label: z.enum(["ok","issue"]), ts: z.string() })| Python | 호출 파서·점검 규칙·출력 스키마의 구현 언어입니다 |
| REST | AI 애플리케이션 엔드포인트 호출 집계 기준입니다 |
| Kubernetes | 배포 서비스의 호출 텔레메트리 수집을 가정합니다 |
| Docker | 대시보드·수집기 컨테이너 패키징입니다 |
| Zod | 호출 입력과 LLM 출력의 런타임 형식 검증입니다 |
| CI/CD | 배포 파이프라인 연동 알림을 가정합니다 |
| Claude | 점검 엔드포인트 원인 설명 LLM 입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(판정이 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(엔드포인트별 안정성 추이)로 진행합니다.
엔드포인트 1건의 점검 카드. 등급·요인·근거를 한 스키마로 담아 대시보드 카드에 씁니다.
z.object({ endpoint_id: z.string().nullable(), model: z.enum(["llm","vlm","agent"]), severity: z.enum(["ok","watch","high","urgent"]), factors: z.array(z.enum(["fail_spike","latency_spike","unmapped_endpoint","missing_metric"])), reason: z.string().min(20), evidence: z.string().min(8), hedge: z.string().nullable() })[
{
"input_ref": "ac_002 (/infer 실패율·지연 급증)",
"output": {
"endpoint_id": "ep_infer",
"model": "llm",
"severity": "urgent",
"factors": [
"fail_spike",
"latency_spike"
],
"reason": "LLM 추론 엔드포인트 실패율이 35%로 치솟고 p95 가 820ms→5200ms 로 6배 급증했습니다. 사용자 장애 위험으로 배포·모델 연동 점검이 시급합니다.",
"evidence": "fail_rate=0.35, p95_ms=5200, prev_p95_ms=820",
"hedge": null
}
},
{
"input_ref": "ac_004 (/vision 지표 결측)",
"output": {
"endpoint_id": "ep_vision",
"model": "vlm",
"severity": "watch",
"factors": [
"missing_metric"
],
"reason": "비전 엔드포인트 실패율·지연 지표가 비어 있습니다. 단정 전 텔레메트리 점검과 지표 재수집이 필요합니다.",
"evidence": "fail_rate=null, p95_ms=null",
"hedge": "지표 결측이라 실패·지연은 단정하지 않습니다"
}
},
{
"input_ref": "ac_005 (미등록 엔드포인트)",
"output": {
"endpoint_id": null,
"model": "agent",
"severity": "watch",
"factors": [
"unmapped_endpoint"
],
"reason": "엔드포인트가 마스터에 없어 점검을 단정하지 않습니다. 실패·지연은 정상이라 엔드포인트 등록 후 집계 반영이 필요합니다.",
"evidence": "endpoint_id=null, fail_rate=0.01",
"hedge": "미등록 엔드포인트라 점검 등급은 추정하지 않습니다"
}
}
][자동 검증] 1. Zod parse 로 출력 형식(필드·enum)이 스키마를 통과하는지 확인합니다. 2. factors 가 점검 규칙(실패율 급증·지연 급증 임계)과 일치하는지 봅니다. 3. severity 를 심은 정답 label 과 비교해 정밀도·재현율을 계산합니다. 4. fail_rate/p95_ms 가 null 이면 fail_spike/latency_spike 단정을 보류합니다. [수동 검증] 1. 운영 검토자 2명이 비동기로 점검 엔드포인트를 라벨링해 정밀도·재현율과 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체의 5% 를 사람이 직접 점검합니다.