Databricks
경력근거: custom applications and data ingestion and ML/AI model integration
※ 실제 산출물이 아닌 AI 예측 시안입니다.
Databricks의 이 자리는 고객사에 데이터 적재를 포함한 운영 시스템을 만들어 넘기고, 그 과정에서 나온 패턴을 여러 고객사에 쓰이는 액셀러레이터로 남기는 일입니다. 고객사마다 테이블과 적재 주기가 달라도 적재량이 갑자기 줄면 문제라는 규칙은 같아서, 기준표만 갈아끼우면 같은 판정기가 다음 고객사에서 그대로 돕니다. 그 재사용 구조가 공고가 말하는 액셀러레이터의 최소 형태입니다. 공고 업무는 아키텍처 설계부터 이해관계자 조율까지 걸쳐 있는데 1주 범위에서 고를 수 있는 것은 하나라 적재 점검 축을 골랐습니다. 이 포트폴리오는 원문 테이블 표기를 표준으로 맞추고 기준과 견줘 근거를 남기는 기술을 보여줍니다. Spark 런타임 내부나 고객사 업무 도메인 자체의 전문성은 주장하지 않습니다. 그 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
데이터 적재와 모델 통합을 포함한 운영급 시스템을 만들어 고객에게 넘기는 일이 주요 업무입니다. 넘긴 뒤 적재가 계속 도는지 보는 일이 인계의 마지막 조각입니다.
여러 고객사에 걸쳐 쓰이는 액셀러레이터와 프레임워크를 만들어 기여하는 일이 업무에 있습니다. 테이블 기준만 갈아끼우면 도는 판정기가 그 자산의 최소 형태입니다.
Apache Spark 기반 분산 처리 경험과 운영 배포용 CI/CD를 요구합니다. 적재 결과를 기준과 견주는 일은 그 파이프라인 끝에 붙는 검사입니다.
일자별 적재 실행 기록과 테이블별 기대 기준을 대조해, 어느 테이블이 최소 기준에 못 미쳤거나 전일 대비 급감했는지 사유별로 나눠 출력하고 고객 보고용 리포트를 남기는 CLI입니다. 판정은 적재 행 수를 최소 기준과 감소 허용치에 견주는 계산으로 정합니다.
고객사에 데이터 파이프라인을 넘기고 안정화를 돕는 파견 엔지니어입니다. 아침마다 적재 결과를 열어 어제와 비슷하게 들어왔는지 테이블을 하나씩 눈으로 훑는데, 테이블 이름이 소스마다 다르게 찍혀 어느 줄이 같은 테이블인지부터 맞춥니다.
테이블마다 최소 적재량과 감소 허용치가 정해져 있으면, 이번 적재가 정상인지는 사람이 훑지 않아도 계산으로 갈라집니다.
적재 실행 기록과 기대 기준 파일을 인자로 받아 테이블별 판정을 터미널에 출력하고 고객 보고용 리포트를 떨구는 CLI입니다. 실제 클러스터에 붙지 않고 내려받은 기록만 읽습니다.
최근 일곱 번의 적재를 함께 읽어 중앙값 대비 얼마나 줄었는지로 판정해, 하루치만 볼 때 놓치던 완만한 감소를 잡는 구성입니다.
테이블 사전과 기대 기준을 파일로 분리해 고객사마다 다른 테이블 묶음을 같은 판정으로 돌리고, 파이프라인에서 매일 자동으로 실행합니다.
담당자가 적재 기록 50행과 기준표를 넣어 이상한 테이블이 사유별로 나뉜 판정표와 고객 보고용 리포트가 나오는 것을 시연합니다.
결측·중복·미등록 테이블이 섞인 입력 30종을 넣어도 출력 형식이 깨지지 않고, 판정하지 못한 테이블은 사유가 붙어 남습니다.
행 수가 비어 있는 실행은 정상으로 세지 않고 실측 누락으로 따로 답니다. 재지 못한 것을 통과로 만들지 않습니다.
판정과 손으로 만든 정답표를 맞춰 사유별로 어긋난 건을 셉니다. 단, 기록과 정답을 모두 작성자가 만든 합성 기준이라 성능 측정이 아니라 데모 조건 동작입니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 더미데이터 자가채점이며, 실제 이상 탐지 정확도는 Databricks 고객사의 실제 적재 이력과 실제 기준이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
쉬운 건만 넣으면 어제와 비슷하게 들어왔는지 맞히는 일은 어렵지 않습니다. 테이블 표기가 소스마다 다른 건, 행 수가 빈 실패 실행, 기준표에 없는 테이블을 적재 기록에 섞어 둔 이유입니다.
적게 들어왔다고 해서 장애라고 단정할 수 없습니다. 연휴나 프로모션 종료로 실제 거래가 줄었을 수 있으므로, 판정은 평소와 다르다는 사실까지만 읽어야 합니다.
실제 도입하면 고객사마다 업무 주기와 정상 범위가 다릅니다. 기준표를 데이터 담당자와 합의해 채우는 일이 도입 단계의 실제 과제입니다.
적재가 왜 줄었는지의 원인 추적은 이 도구의 범위 밖입니다. 어느 테이블이 이상한지까지만 보여주므로, 소스 시스템 조사는 담당자가 이어서 합니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
일자별 적재 실행 기록입니다. 테이블 표기가 소스마다 대소문자·구분자로 흔들리고, 사전에 없는 신규 테이블과 같은 실행 번호가 두 번 들어온 건, 행 수가 비어 있는 실패 실행을 일부러 섞었습니다.
| run_no | table_raw | load_date | row_count | bytes_written | status |
|---|---|---|---|---|---|
| IG-001 | sales.orders | 2026-08-17 | 128,000 | 41,000,000 | success |
| IG-002 | sales.orders | 2026-08-18 | 131,500 | 42,200,000 | success |
| IG-003 | Sales.Orders | 2026-08-19 | 12,800 | 4,100,000 | success |
| IG-004 | sales.payments | 2026-08-18 | 64,000 | 18,000,000 | success |
| IG-005 | sales.payments | 2026-08-19 | 62,800 | 17,600,000 | success |
아래 JSON Schema에 맞는 적재 실행 기록 행을 더 만들어 주세요. {"type":"object","properties":{"run_no":{"type":"string"},"table_raw":{"type":"string"},"load_date":{"type":"string"},"row_count":{"type":["integer","null"]},"bytes_written":{"type":"integer"},"status":{"type":"string","enum":["success","failed","partial"]}},"required":["run_no","table_raw","load_date","row_count","bytes_written","status"]} 한 table_id에 날짜가 다른 행이 두 건 이상 쌓이도록 만들어 주세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 미매핑으로 table_raw가 사전에 없어 table_id가 null인 행, 둘째 표기흔들림으로 같은 테이블을 sales.orders와 Sales.Orders와 SALES.ORDERS처럼 대소문자만 다르게 적은 행, 셋째 중복으로 같은 run_no가 두 행에 있는 재적재 건, 넷째 결측으로 row_count가 null이고 status가 failed인 행, 다섯째 경계극단으로 row_count가 최소 기준과 정확히 같은 행. 평소만큼 들어온 정상 실행이 전체의 절반쯤 되게 해 주세요. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 status에 enum 밖 값을 넣거나 load_date를 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"run_no":{"type":"string"},"table_raw":{"type":"string"},"load_date":{"type":"string"},"row_count":{"type":["integer","null"]},"bytes_written":{"type":"integer"},"status":{"type":"string","enum":["success","failed","partial"]}},"required":["run_no","table_raw","load_date","row_count","bytes_written","status"]}테이블별 최소 적재량과 감소 허용치입니다. 기준이 아직 정해지지 않은 테이블을 일부러 섞었습니다.
| table_id | table_label | min_daily_rows | max_drop_pct | owner_team |
|---|---|---|---|---|
| sales_orders | 주문 | 100,000 | 20 | 커머스 |
| sales_payments | 결제 | 50,000 | 20 | 커머스 |
| sales_customers | 고객 | 100 | 50 | 커머스 |
| ops_shipments | 출고 | 8,000 | 30 | 물류 |
| ops_inventory | 재고 | 20,000 | 15 | 물류 |
아래 JSON Schema에 맞는 테이블 기대 기준 행을 더 만들어 주세요. {"type":"object","properties":{"table_id":{"type":"string"},"table_label":{"type":"string"},"min_daily_rows":{"type":["integer","null"]},"max_drop_pct":{"type":"integer"},"owner_team":{"type":"string"}},"required":["table_id","table_label","min_daily_rows","max_drop_pct","owner_team"]} table_label은 한글로 적어 주세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 결측으로 min_daily_rows가 null인 기준 미정 테이블, 둘째 경계극단으로 max_drop_pct가 0인 감소를 전혀 허용하지 않는 테이블과 90인 매우 느슨한 테이블. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 max_drop_pct에 문자열을 넣거나 table_id를 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"table_id":{"type":"string"},"table_label":{"type":"string"},"min_daily_rows":{"type":["integer","null"]},"max_drop_pct":{"type":"integer"},"owner_team":{"type":"string"}},"required":["table_id","table_label","min_daily_rows","max_drop_pct","owner_team"]}| Python | 적재 기록과 기준을 읽어 판정을 돌리고 리포트를 만드는 본체입니다. |
| Apache Spark | 적재 기록이 하루 수천만 행으로 커질 때 테이블별 집계를 분산으로 돌리는 3주차 경로입니다. |
| CI/CD | 판정 규칙을 고칠 때마다 더미 기록으로 회귀 테스트를 돌리고, 매일 정해진 시각에 판정을 자동 실행합니다. |
| 데이터 파이프라인 | 판정 대상이 되는 적재 작업이며, 그 실행 결과가 이 도구의 입력입니다. |
| 클라우드 | 고객사가 쓰는 클라우드의 저장소 경로를 입력 위치로 받습니다. 계정 연결은 고객사 자격으로 합니다. |
| MLOps | 적재가 흔들리면 그 위에 올린 모델 학습도 흔들린다는 연결 지점이며, 판정 결과를 학습 실행 전 관문으로 씁니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 최근 일곱 번의 흐름과 견줘 완만한 감소도 잡습니다.
✓ pass → 흐름 판정까지가 한 덩어리입니다. 더 키우려면 기준표를 고객사별로 분리하고 매일 자동 실행합니다.
적재 실행 한 건이 평소만큼 들어왔는지의 판정 결과입니다. 아니라면 왜인지를 근거와 함께 담습니다.
{"type":"object","properties":{"run_no":{"type":"string"},"verdict":{"type":"string","enum":["normal","below_minimum","sharp_drop","row_count_missing","expectation_missing","table_unmapped","duplicate_run"]},"today_rows":{"type":["integer","null"]},"previous_rows":{"type":["integer","null"]},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"agg":{"type":["string","null"]},"value":{},"quote":{"type":["string","null"]}},"required":["field","value"]}},"next_action":{"type":"string"}},"required":["run_no","verdict","today_rows","previous_rows","evidence","next_action"]}[
{
"run_no": "IG-005",
"verdict": "normal",
"today_rows": 62800,
"previous_rows": 64000,
"evidence": [
{
"field": "row_count",
"value": 62800
},
{
"field": "min_daily_rows",
"value": 50000
},
{
"field": "max_drop_pct",
"value": 20
}
],
"next_action": "기준 안이고 감소도 허용치 안입니다. 그대로 둡니다."
},
{
"run_no": "IG-013",
"verdict": "normal",
"today_rows": 8100,
"previous_rows": 8200,
"evidence": [
{
"field": "row_count",
"value": 8100
},
{
"field": "min_daily_rows",
"value": 8000
},
{
"field": "max_drop_pct",
"value": 10
}
],
"next_action": "최소 기준을 겨우 넘겼습니다. 내일 한 번 더 지켜봅니다."
},
{
"run_no": "IG-003",
"verdict": "below_minimum",
"today_rows": 12800,
"previous_rows": 131500,
"evidence": [
{
"field": "row_count",
"value": 12800
},
{
"field": "min_daily_rows",
"value": 100000
}
],
"next_action": "최소 기준의 십분의 일만 들어왔습니다. 소스 시스템 연결부터 확인합니다."
},
{
"run_no": "IG-007",
"verdict": "sharp_drop",
"today_rows": 40,
"previous_rows": 900,
"evidence": [
{
"field": "row_count",
"value": 40
},
{
"field": "max_drop_pct",
"value": 50
},
{
"field": "load_date",
"value": "2026-08-19"
}
],
"next_action": "최소 기준은 넘겼지만 전일 대비 허용치를 크게 넘겨 줄었습니다. 신규 가입 경로를 확인합니다."
},
{
"run_no": "IG-008",
"verdict": "row_count_missing",
"today_rows": null,
"previous_rows": null,
"evidence": [
{
"field": "row_count",
"value": null
},
{
"field": "status",
"value": "failed"
}
],
"next_action": "실행이 실패해 행 수가 없습니다. 정상으로 세지 않고 재실행합니다."
},
{
"run_no": "IG-014",
"verdict": "expectation_missing",
"today_rows": 300,
"previous_rows": null,
"evidence": [
{
"field": "row_count",
"value": 300
},
{
"field": "min_daily_rows",
"value": null
}
],
"next_action": "이 테이블의 최소 기준이 정해져 있지 않습니다. 기준을 먼저 채웁니다."
},
{
"run_no": "IG-011",
"verdict": "table_unmapped",
"today_rows": 5400,
"previous_rows": null,
"evidence": [
{
"field": "table_raw",
"value": "mkt.campaign_events",
"quote": "mkt.campaign_events"
}
],
"next_action": "사전에 없는 테이블입니다. 사전에 추가하기 전에는 집계에서 빼 둡니다."
},
{
"run_no": "IG-003",
"verdict": "duplicate_run",
"today_rows": 12800,
"previous_rows": 131500,
"evidence": [
{
"field": "run_no",
"agg": "count",
"value": 2
}
],
"next_action": "같은 실행 번호가 두 번 적재됐습니다. 앞 건으로만 판정하고 뒤 건을 기록에서 뺍니다."
}
][자동 검증 · 1주차] 1. verdict가 enum 일곱 값 안에 있는지 확인합니다. 2. run_no·verdict·today_rows·previous_rows·evidence·next_action이 모두 있는지 확인합니다. 3. max_drop_pct가 0 이상 100 이하인지 확인합니다. 4. row_count가 null이면 verdict가 row_count_missing인지 확인합니다. 5. evidence의 field가 두 입력 표의 컬럼에 실재하는지 확인합니다. 6. evidence의 quote가 그 행 table_raw의 일부인지 확인합니다. 7. next_action이 존댓말로 끝나는지 확인합니다. [판정 규칙] 1. 테이블 표기은 대소문자와 띄어쓰기, 구분자를 없애 소문자로 모은 뒤 table_expectations의 table_id와 맞춥니다. 맞는 것이 없으면 미매핑으로 남기고 그 행은 나머지 판정에서 뺍니다. 2. 같은 행 번호가 두 번 들어오면 앞 건만 남기고 뒤 건은 적재 단계에서 사유와 함께 뺍니다. [수동 검증] 1. 급감으로 판정된 테이블이 연휴나 프로모션 종료 때문인지 업무 담당자가 확인합니다. 2. IG-003·IG-006처럼 테이블 표기가 흔들렸지만 사전으로 맞춰진 행은 미매핑 사유를 달지 않는 것이 맞는지 확인합니다. [평가 러너 · 2주차] 1. 최근 일곱 번의 중앙값 대비 판정과 하루치 판정을 맞춰 어느 쪽이 더 많이 잡는지 셉니다. 2. 기록과 정답을 작성자가 만든 합성 기준이라 이 수치는 성능 측정이 아니라 데모 조건 동작입니다.
근거: custom applications and data ingestion and ML/AI model integration