인포[인포그랩] AI 워크플로 자동화 개발자
0.0인포그랩
경력근거: 반복 업무 진단·발굴부터 자동화 파이프라인 구축 및 운영 이관까지 전 과정 수행
어제 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
공고가 하는 일에 '반복 업무 진단·발굴부터 자동화 파이프라인 구축 및 운영 이관까지 전 과정 수행' 을 적었고, 자체 제품으로 'n8n 운영 및 워크플로를 조직에서 직접 통제하게 돕는 툴' 을 들었습니다. 넘긴 뒤 고객이 스스로 통제하려면 먼저 빠진 건을 스스로 알아야 하고, 그것은 실행 로그가 아니라 원천 업무와 맞춰 봐야 나옵니다. 이 포트폴리오는 그 대조를 업무별 규칙표로 만들어 개발자가 아닌 담당자가 보는 화면에 올립니다. 'DevOps 영역과 엔터프라이즈 비즈니스 프로세스 전반의 반복 업무를 자동화하는 에이전트를 만듭니다' 라 업무마다 원천 시스템이 따로 있는 것도 이 설계와 맞습니다. 이 포트폴리오가 보여주는 것은 대조 기준을 데이터로 두고 양쪽 기록을 맞춰 빠진 건을 찾는 기술이며, 고객사 업무 도메인 지식이나 회계 처리 실무는 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
'반복 업무 진단·발굴부터 자동화 파이프라인 구축 및 운영 이관까지 전 과정 수행'. 넘긴 뒤 고객이 스스로 확인할 자리가 이 화면입니다.
'Nelper: n8n 운영 및 워크플로를 조직에서 직접 통제하게 돕는 툴'. 통제의 첫 조건은 빠진 건을 스스로 아는 것입니다.
'DevOps 영역과 엔터프라이즈 비즈니스 프로세스 전반의 반복 업무를 자동화하는 에이전트를 만듭니다'. 그 업무마다 원천 시스템이 따로 있습니다.
원천 시스템에 남은 업무 건과 자동화가 처리했다고 남긴 건을 업무 키로 맞춰 어긋난 자리를 화면에 사유별로 묶어 보여줍니다. 업무별 대조 규칙에 맞출 키와 허용 지연, 금액을 견줄지, 대조에서 뺄 번호 접두를 두고 양쪽 기록과 맞춰, 짝이 맞고 지연도 금액도 기준 안이면 맞음으로 넘기고 그렇지 않으면 처리 빠짐·원천에 없음·기한 넘김·금액 다름 중 어느 쪽인지 남깁니다. 규칙에 없는 업무는 미등록으로 남겨 무엇을 키로 맞출지 먼저 정하게 합니다. 양쪽 기록은 실 고객사 자료 대신 지원자가 만든 예제 업무 시스템과 워크플로에서 내려받은 것을 가정합니다.
자동화를 넘겨받은 고객사의 업무 담당자입니다. 개발자가 아니라 실행 로그를 열어 볼 줄 모르고, 월말에 원천 시스템 건수와 처리 건수가 안 맞는 것을 발견하면 어느 건이 빠졌는지 엑셀 두 장을 눈으로 맞춰 보던 자리에 있습니다.
업무마다 맞출 키와 허용 지연, 금액 비교 여부를 규칙으로 두고 원천과 처리 기록을 맞추면, 빠진 건이 마감 전에 목록으로 나오고 어긋난 이유가 근거로 남는다는 가정입니다. 규칙에 없는 업무는 미등록으로 빠지므로 아직 대조 기준을 정하지 않은 업무가 그대로 드러납니다.
원천과 처리 기록, 업무별 대조 규칙을 넣으면 건마다 맞음·어긋남을 판정하고, 어긋나면 처리 빠짐·원천에 없음·기한 넘김·금액 다름·업무 미등록 중 어느 쪽인지 붙여 사유별로 묶어 보여주는 화면이 도는 완결품입니다. 건을 펼치면 양쪽 기록의 시각과 금액이 나옵니다.
작은 업무 시스템과 워크플로를 만들어 일부러 몇 건을 빠뜨린 채 기록 2000건을 쌓고, 손으로 붙인 정답 대조와 견줘 일치율을 내며 빠진 건을 놓치지 않았는지 확인합니다.
처리 빠짐으로 걸린 건을 담당 조직별로 갈라 다시 태울 목록을 내고, 다시 태운 뒤 같은 화면에서 맞음으로 바뀌는지 확인하는 단계입니다.
고객사 담당자가 원천과 처리 기록, 규칙표를 넣으면 건마다 맞음 여부와 어긋난 사유가 사유별로 묶여 화면에 뜨는 과정을 시연합니다.
예제 시스템에서 쌓은 기록 2000건과 손으로 붙인 정답 대조를 견줘 일치율을 냅니다. 단, 정답과 기록을 모두 작성자가 만든 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
금액이 비었거나 업무 표기가 흔들리거나 규칙에 없는 업무가 섞인 입력 30종을 넣어도 화면이 안 깨지고 사유별로 빠지는 비율을 보여줍니다.
허용 지연과 금액 비교 여부를 바꿨을 때 옛 판정이 어떻게 뒤집히는지 회귀로 확인합니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 작성자가 만든 기록의 자가채점이며, 실제 누락 적발률은 인포그랩 고객사의 실 원천 시스템과 실 워크플로가 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아니므로, 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 붙였으니 잘 맞는 게 당연하므로, 한쪽에만 있는 건과 금액이 뒤집힌 건, 규칙에 없는 업무를 일부러 섞어 쉬운 건만 푸는 함정을 피합니다.
이 포트폴리오가 보여주는 것은 대조 기준을 데이터로 두고 양쪽 기록을 맞춰 빠진 건을 찾는 기술이며, 고객사 업무 도메인 지식이나 회계 처리 실무는 주장하지 않습니다. 판정은 키 대조와 시각·금액 비교가 하고 LLM 은 담당자가 읽을 사유 문장만 맡습니다.
업무 키가 양쪽에서 다르게 적히면 짝이 안 맞아 빠진 것처럼 보일 수 있어서, 미등록과 누락을 다른 사유로 갈라 두고 키 정의를 먼저 확인하게 합니다.
실제 도입 때는 고객사마다 원천 시스템과 업무 키가 다르므로, 규칙표를 업무 담당과 함께 채우는 일을 도입 단계 과제로 둡니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
원천 시스템이 남긴 업무 건과 자동화가 처리했다고 남긴 건을 한 표에 모은 것입니다. 기록 번호와 업무 이름, 어느 쪽 기록인지, 업무 키, 금액, 일어난 시각, 남긴 주체를 한 행에 둡니다. 같은 업무 키가 양쪽에 하나씩 있어야 짝이 맞습니다. 한쪽에만 있는 건, 금액이 뒤집혀 들어간 건, 사흘 뒤에 처리된 건, 시험용 번호, 규칙표에 없는 업무를 일부러 섞어 두어 사유가 갈리게 둡니다.
| rec_no | task_raw | side_raw | biz_key | amount | occurred_at | actor_raw |
|---|---|---|---|---|---|---|
| WR-001 | 세금계산서 발행 | source | INV-2041 | 1,240,000 | 2026-08-24T09:00:00 | ERP |
| WR-002 | 세금계산서 발행 | flow | INV-2041 | 1,240,000 | 2026-08-24T09:12:00 | n8n |
| WR-003 | 세금계산서 발행 | source | INV-2043 | 880,000 | 2026-08-24T09:05:00 | ERP |
| WR-004 | 세금계산서 발행 | source | INV-2050 | 1,240,000 | 2026-08-24T10:00:00 | ERP |
| WR-005 | 세금계산서 발행 | flow | INV-2050 | 1,204,000 | 2026-08-24T10:08:00 | n8n |
아래 JSON Schema 를 그대로 만족하는 업무 기록 행을 2000개 더 만들어 주세요. 업무를 예닐곱 종 두고 업무 키를 접두와 일련번호로 짓습니다. 대부분은 원천과 처리가 짝을 이루게 두되, 5% 는 처리 기록을 빼고 2% 는 원천 기록을 빼세요. 몇 건은 금액의 숫자 자리를 바꿔 넣고, 몇 건은 처리 시각을 며칠 뒤로 두며, 몇 건은 업무 키를 'TEST-' 로 시작하게 합니다. 규칙표에 없는 업무도 몇 종 넣으세요. 판정 결과나 지연 시간은 넣지 마세요.
{"type": "object", "properties": {"rec_no": {"type": "string"}, "task_raw": {"type": "string"}, "side_raw": {"type": "string", "enum": ["source", "flow"]}, "biz_key": {"type": "string"}, "amount": {"type": ["number", "null"]}, "occurred_at": {"type": "string"}, "actor_raw": {"type": ["string", "null"]}}, "required": ["rec_no", "task_raw", "side_raw", "biz_key", "amount", "occurred_at", "actor_raw"]}{"type": "object", "properties": {"rec_no": {"type": "string"}, "task_raw": {"type": "string"}, "side_raw": {"type": "string", "enum": ["source", "flow"]}, "biz_key": {"type": "string"}, "amount": {"type": ["number", "null"]}, "occurred_at": {"type": "string"}, "actor_raw": {"type": ["string", "null"]}}, "required": ["rec_no", "task_raw", "side_raw", "biz_key", "amount", "occurred_at", "actor_raw"]}업무별 대조 규칙표입니다. 규칙 번호와 업무 이름, 맞출 키 이름, 허용 지연, 금액을 견줄지, 대조에서 뺄 번호 접두, 담당을 한 행에 둡니다. 업무마다 허용 지연이 달라 같은 시간차도 어떤 업무는 정상이고 어떤 업무는 기한 초과입니다. 금액이 없는 업무는 금액 비교를 끕니다. 기록에 나오는 업무 중 일부는 일부러 넣지 않아 미등록이 도출되게 둡니다.
| rule_no | task_raw | key_label | allow_delay_hours | compare_amount | skip_prefix | owner_name |
|---|---|---|---|---|---|---|
| RR-01 | 세금계산서 발행 | 계산서 번호 | 1 | true | TEST- | 재무 |
| RR-02 | 거래처 등록 | 거래처 코드 | 4 | false | — | 영업지원 |
| RR-03 | 견적 승인 | 견적 번호 | 24 | true | — | 영업 |
| RR-04 | 입금 대사 | 입금 번호 | 2 | true | — | 재무 |
| RR-05 | 발주 생성 | 발주 번호 | 4 | true | — | 구매 |
아래 JSON Schema 를 그대로 만족하는 대조 규칙 행을 30개 더 만들어 주세요. 업무마다 허용 지연을 1시간에서 48시간 사이로 다르게 두고, 금액이 오가는 업무만 금액 비교를 참으로 둡니다. 시험 데이터가 섞이는 업무 몇 개에만 뺄 번호 접두를 적고 나머지는 비웁니다. 기록에 나오는 업무 중 일부는 일부러 넣지 마세요 — 미등록이 있어야 대조 기준이 없는 업무가 드러납니다. 판정 결과는 넣지 마세요.
{"type": "object", "properties": {"rule_no": {"type": "string"}, "task_raw": {"type": "string"}, "key_label": {"type": "string"}, "allow_delay_hours": {"type": "number"}, "compare_amount": {"type": "boolean"}, "skip_prefix": {"type": ["string", "null"]}, "owner_name": {"type": "string"}}, "required": ["rule_no", "task_raw", "key_label", "allow_delay_hours", "compare_amount", "skip_prefix", "owner_name"]}{"type": "object", "properties": {"rule_no": {"type": "string"}, "task_raw": {"type": "string"}, "key_label": {"type": "string"}, "allow_delay_hours": {"type": "number"}, "compare_amount": {"type": "boolean"}, "skip_prefix": {"type": ["string", "null"]}, "owner_name": {"type": "string"}}, "required": ["rule_no", "task_raw", "key_label", "allow_delay_hours", "compare_amount", "skip_prefix", "owner_name"]}| TypeScript | 양쪽 기록을 업무 키로 맞추고 지연과 금액을 견주는 대조기를 맡습니다. |
| PostgreSQL | 원천과 처리 기록, 대조 규칙, 판정 결과를 담습니다. |
| Next.js | 고객사 담당자가 여는 관리자 페이지를 맡습니다. |
| Docker | 고객사 환경에서 같은 결과가 나오도록 대조기를 컨테이너로 싸 둡니다. |
✗ fail → 미등록이 절반을 넘으면 규칙표를 먼저 채웁니다.
✓ pass → 2주차 예제 시스템 대조로 넘어갑니다.
✗ fail → 놓친 건을 모아 키 정의와 허용 지연을 다시 봅니다.
✓ pass → 3주차 다시 태우기로 넘어갑니다.
위 예측 UI 는 3주차까지 완주했을 때의 화면입니다. 1주차에 실제로 만드는 것은 아래 표시된 화면 하나입니다.
reconcile_code사유 라벨 · biz_key + 한 줄 요약(근거 수치 포함)화면·코드·면접에서 이 단어를 그대로 씁니다. 키는 출력 스키마의 enum 과 같습니다.
missing_in_flow처리 빠짐amount_mismatch금액 다름late_beyond_window기한 넘김missing_in_source원천에 없음task_unregistered업무 미등록matched맞음업무 키 하나마다 원천과 처리가 맞는지 정합니다. 어긋나면 처리 빠짐·원천에 없음·기한 넘김·금액 다름·업무 미등록 중 어느 쪽인지 싣습니다. 화면은 이 사유 코드로 묶습니다.
{"type": "object", "properties": {"verdict_no": {"type": "string"}, "biz_key": {"type": "string"}, "task_raw": {"type": "string"}, "rule_no": {"type": ["string", "null"]}, "reconcile_code": {"type": "string", "enum": ["matched", "missing_in_flow", "missing_in_source", "late_beyond_window", "amount_mismatch", "task_unregistered"]}, "delay_hours": {"type": ["number", "null"], "description": "처리 기록의 occurred_at 에서 원천 기록의 occurred_at 을 뺀 시간입니다. 양쪽이 다 있는 건에만 채웁니다."}, "allow_delay_hours": {"type": ["number", "null"]}, "owner_name": {"type": ["string", "null"]}, "evidence": {"type": "array", "items": {"type": "object", "properties": {"field": {"type": "string"}, "agg": {"type": ["string", "null"]}, "value": {}}, "required": ["field", "value"]}}, "summary": {"type": "string"}, "hedge": {"type": ["string", "null"]}}, "required": ["verdict_no", "biz_key", "task_raw", "reconcile_code", "evidence", "summary"]}[
{
"verdict_no": "RC-001",
"biz_key": "INV-2041",
"task_raw": "세금계산서 발행",
"rule_no": "RR-01",
"reconcile_code": "matched",
"delay_hours": 0.2,
"allow_delay_hours": 1,
"owner_name": "재무",
"evidence": [
{
"field": "amount",
"agg": null,
"value": 1240000
},
{
"field": "allow_delay_hours",
"agg": null,
"value": 1
}
],
"summary": "원천과 처리가 같은 금액으로 12분 만에 이어졌습니다.",
"hedge": null
},
{
"verdict_no": "RC-002",
"biz_key": "INV-2043",
"task_raw": "세금계산서 발행",
"rule_no": "RR-01",
"reconcile_code": "missing_in_flow",
"delay_hours": null,
"allow_delay_hours": 1,
"owner_name": "재무",
"evidence": [
{
"field": "biz_key",
"agg": null,
"value": "INV-2043"
},
{
"field": "side_raw",
"agg": "count",
"value": 1
}
],
"summary": "원천에는 있는데 자동화가 건드리지 않아 아직 발행되지 않았습니다.",
"hedge": null
},
{
"verdict_no": "RC-003",
"biz_key": "INV-2050",
"task_raw": "세금계산서 발행",
"rule_no": "RR-01",
"reconcile_code": "amount_mismatch",
"delay_hours": 0.13,
"allow_delay_hours": 1,
"owner_name": "재무",
"evidence": [
{
"field": "amount",
"agg": null,
"value": 1204000
},
{
"field": "compare_amount",
"agg": null,
"value": true
}
],
"summary": "원천 1,240,000원인데 처리는 1,204,000원으로 나가 숫자가 뒤집혀 들어갔습니다.",
"hedge": null
},
{
"verdict_no": "RC-004",
"biz_key": "CU-118",
"task_raw": "거래처 등록",
"rule_no": "RR-02",
"reconcile_code": "missing_in_source",
"delay_hours": null,
"allow_delay_hours": 4,
"owner_name": "영업지원",
"evidence": [
{
"field": "biz_key",
"agg": null,
"value": "CU-118"
},
{
"field": "actor_raw",
"agg": null,
"value": "n8n"
}
],
"summary": "자동화만 처리해 원천에 근거가 없어 어디서 왔는지 확인해야 합니다.",
"hedge": null
},
{
"verdict_no": "RC-005",
"biz_key": "CU-119",
"task_raw": "거래처 등록",
"rule_no": "RR-02",
"reconcile_code": "matched",
"delay_hours": 0.2,
"allow_delay_hours": 4,
"owner_name": "영업지원",
"evidence": [
{
"field": "occurred_at",
"agg": null,
"value": "2026-08-24T11:22:00"
},
{
"field": "allow_delay_hours",
"agg": null,
"value": 4
}
],
"summary": "요청 12분 뒤에 등록돼 허용 네 시간 안입니다.",
"hedge": null
},
{
"verdict_no": "RC-006",
"biz_key": "QT-77",
"task_raw": "견적 승인",
"rule_no": "RR-03",
"reconcile_code": "late_beyond_window",
"delay_hours": 73.5,
"allow_delay_hours": 24,
"owner_name": "영업",
"evidence": [
{
"field": "occurred_at",
"agg": null,
"value": "2026-08-21T14:00:00"
},
{
"field": "allow_delay_hours",
"agg": null,
"value": 24
}
],
"summary": "사흘 뒤에야 처리돼 허용 하루를 한참 넘겼습니다.",
"hedge": "승인자가 자리를 비운 기간일 수 있어 담당자가 사유를 확인합니다."
},
{
"verdict_no": "RC-007",
"biz_key": "PY-08",
"task_raw": "급여 자료 취합",
"rule_no": null,
"reconcile_code": "task_unregistered",
"delay_hours": null,
"allow_delay_hours": null,
"owner_name": null,
"evidence": [
{
"field": "task_raw",
"agg": null,
"value": "급여 자료 취합"
},
{
"field": "rule_no",
"agg": "count",
"value": 12
}
],
"summary": "대조 규칙 열두 행에 없는 업무라 무엇을 키로 맞출지 정해 두지 않았습니다.",
"hedge": null
},
{
"verdict_no": "RC-008",
"biz_key": "TEST-9001",
"task_raw": "세금계산서 발행",
"rule_no": "RR-01",
"reconcile_code": "matched",
"delay_hours": null,
"allow_delay_hours": 1,
"owner_name": "재무",
"evidence": [
{
"field": "skip_prefix",
"agg": null,
"value": "TEST-"
},
{
"field": "biz_key",
"agg": null,
"value": "TEST-9001"
}
],
"summary": "시험용 번호라 대조에서 빼기로 정해 둔 건입니다.",
"hedge": null
}
][자동 검증 · 코드가 판정합니다] 1. reconcile_code 가 enum 여섯 값 중 하나인지 확인합니다. 2. verdict_no·biz_key·task_raw·reconcile_code·evidence·summary 가 모두 채워졌는지 확인합니다. 3. biz_key 가 기록에 실재하는 값인지 대조합니다. 4. rule_no 가 있으면 규칙표에 실재하는 행 번호인지 대조합니다. 5. rule_no 가 있으면 allow_delay_hours·owner_name 이 그 규칙 행의 값과 같은지 대조합니다. 6. task_raw 를 띄어쓰기를 접어 규칙표와 맞추고, 맞는 행이 없으면 reconcile_code 가 task_unregistered 인지 확인합니다. 7. skip_prefix 가 있고 biz_key 가 그 접두로 시작하면 대조에서 빼고 reconcile_code 가 matched 인지 확인합니다. 8. 같은 task_raw·biz_key 에 side_raw 가 flow 인 행이 없으면 reconcile_code 가 missing_in_flow 인지 다시 셉니다. 9. side_raw 가 source 인 행이 없으면 reconcile_code 가 missing_in_source 인지 다시 셉니다. 10. delay_hours 를 처리 기록의 occurred_at 에서 원천 기록의 occurred_at 을 빼 시간으로 다시 계산합니다. 11. delay_hours 가 allow_delay_hours 를 넘으면 reconcile_code 가 late_beyond_window 인지 다시 계산합니다. 12. compare_amount 가 참이고 양쪽 amount 가 다르면 reconcile_code 가 amount_mismatch 인지 확인합니다. 13. reconcile_code 가 matched 이면 짝이 맞고 지연과 금액이 모두 기준 안인지 다시 확인합니다. 14. evidence 의 field 이름이 기록과 규칙표에 실재하는 컬럼인지 대조합니다. 15. agg 가 없는 evidence 의 value 가 그 컬럼에 수록된 행 값과 같은지 확인합니다. 16. summary 가 존댓말로 끝나는지 확인합니다. [평가 러너 · 2주차] 예제 시스템에서 일부러 몇 건을 빠뜨린 채 쌓은 기록 2000건에 손으로 붙인 정답 대조와 견줘 일치율과 사유 코드별 분포를 내고, 빠뜨린 건을 놓치지 않았는지 함께 확인합니다. [수동 검증 · 사람이 봅니다] 1. 규칙에 없는 업무의 대조 키와 허용 지연을 업무 담당이 정합니다. 2. 처리 빠짐으로 걸린 건을 다시 태울지 손으로 처리할지 담당자가 정합니다.