인핸스
경력근거: 고객사별 계약 SLA와 영향도를 고려해 대응하고, 진행 상황과 우회 방법, 예상 일정을 고객에게 설명해요.
※ 실제 산출물이 아닌 AI 예측 시안입니다.
인핸스는 기업의 데이터와 업무 맥락, 의사결정 기준을 온톨로지로 구조화하고, AI 에이전트가 그 위에서 판단해 업무를 끝까지 수행하게 하는 AgentOS 를 만들어요. 대기업·금융·공공·국방 고객의 온프레미스·프라이빗 클라우드 환경에 AgentOS 를 구축하고, 구축이 끝난 뒤의 운영까지 맡아요.
공고는 이 자리가 '전달받은 기술 티켓의 분석, 대응, 고객 확인, 종결까지 관리해요'라고 적고, '고객사별 계약 SLA와 영향도를 고려해 대응하고'라고 덧붙여요. 고객사마다 계약한 응답·복구 시간이 다르면 같은 등급의 티켓이라도 기한이 달라지고, 티켓이 구축 FDE나 Product팀, Infra팀에 넘어가 있는 동안에도 고객이 기다리는 시간은 늘어나요. 그래서 열린 티켓이 여럿이면 티켓마다 기한을 따로 따져 봐야 어느 티켓부터 잡을지 정할 수 있어요.
공고는 전달받은 기술 티켓을 분석부터 고객 확인, 종결까지 관리하는 일을 이 자리에 맡겨요. 대응할 때는 고객사별 계약 SLA와 영향도를 고려하고, 진행 상황과 우회 방법, 예상 일정을 고객에게 설명한다고 적었어요.
공고는 데이터 구조와 커스텀 로직은 구축 FDE, 제품 결함은 Product팀, 인프라 계층 문제는 Infra팀, 고객사 자체 인프라는 고객사 IT 담당자와 함께 푼다고 적어요. 다른 조직이 해결에 참여하더라도 고객에게 진행 상황을 설명하고 업무가 정상화됐는지 확인하는 일은 이 자리가 맡아요.
공고는 운영 체계가 만들어지는 단계에 참여해 인수인계, 장애 대응, 점검과 문서화의 기준을 정립하고 자동화한다고 적어요. 반복 점검과 진단 업무의 자동화 기회를 찾아 개선하는 일도 이 자리에 맡겨요.
운영 팀이 열린 장애 티켓을 함께 볼 때 여는 관리자 페이지예요. 점검하는 시각에 아직 복구되지 않은 티켓과 그날 복구된 티켓마다, 고객사가 계약한 첫 응답 시간과 복구 시간을 지켜 복구됐는지, 이미 넘겼는지, 아직 기한 안에서 처리 중인지 알려 줘요. 운영 엔지니어는 이걸 보고 어느 티켓부터 잡을지 정해요. 받은 데이터를 담을 DB 설계와 기술·구조는 지원자가 정해요.
인핸스에서 여러 고객사의 AgentOS 장애 티켓을 맡는 Operation Engineer 예요. 고객사마다 계약한 첫 응답·복구 시간이 다르고 티켓이 구축 FDE·Product팀·Infra팀·고객사 IT 사이를 오가면, 열린 티켓마다 기한이 얼마 남았는지 한눈에 보기 어려워 급한 티켓을 늦게 잡게 돼요.
고객사마다 장애 등급별로 계약한 첫 응답 시간과 복구 시간이에요. 한 행이 고객사 하나의 등급 하나이고, customer_id 와 severity 묶음이 키예요. 고객사는 10곳(CU-01~CU-10)이고 등급은 P1~P4 네 가지라 모두 40행이에요. response_minutes 는 티켓이 열린 때부터 고객에게 처음 진행 상황을 알릴 때까지, restore_minutes 는 티켓이 열린 때부터 서비스가 복구될 때까지 계약으로 허용한 분이에요. 두 시간 모두 밤과 주말을 빼지 않고 이어서 세요. 이 계약에서 첫 응답은 ticket_events 의 첫 customer_update 이고, 복구는 restored 예요. 복구 뒤 다시 열린 티켓은 다시 복구될 때까지 복구되지 않은 것으로 쳐요. 같은 등급이라도 고객사마다 계약한 시간이 달라요. 시작용과 큰 데이터 모두 40행 전부예요.
전체 40행 가운데 앞 5행이에요.
| customer_id | severity | response_minutes | restore_minutes |
|---|---|---|---|
| CU-01 | P1 | 15 | 240 |
| CU-01 | P2 | 30 | 480 |
| CU-01 | P3 | 120 | 1,440 |
| CU-01 | P4 | 480 | 4,320 |
| CU-02 | P1 | 30 | 480 |
40행 전부를 JSON 파일 하나로 받을 수 있어요.
같은 형식으로 만든 40행이에요. 위 데이터가 이 안에 그대로 들어 있어요(한 줄에 한 행, gzip 압축).
미리보기와 내려받는 데이터 모두 이 형식(JSON Schema)을 따라요.
{
"type": "object",
"description": "고객사 하나의 장애 등급 하나에 대한 계약 시간. 키는 (customer_id, severity) 묶음.",
"additionalProperties": false,
"required": [
"customer_id",
"severity",
"response_minutes",
"restore_minutes"
],
"properties": {
"customer_id": {
"type": "string",
"pattern": "^CU-[0-9]{2}$",
"description": "고객사 코드(CU-01~CU-10)."
},
"severity": {
"type": "string",
"enum": [
"P1",
"P2",
"P3",
"P4"
],
"description": "장애 등급. P1 은 고객 업무가 멈춘 장애, P2 는 주요 기능 일부가 안 되는 장애, P3 는 우회할 수 있는 오류, P4 는 업무 영향이 작은 오류예요."
},
"response_minutes": {
"type": "integer",
"minimum": 1,
"description": "티켓이 열린 때부터 고객에게 처음 진행 상황을 알릴 때까지 계약으로 허용한 시간(분). 밤과 주말도 빼지 않고 이어서 세요."
},
"restore_minutes": {
"type": "integer",
"minimum": 1,
"description": "티켓이 열린 때부터 서비스가 복구될 때까지 계약으로 허용한 시간(분). 밤과 주말도 빼지 않고 이어서 세요."
}
}
}고객사가 접수한 AgentOS 장애 티켓이에요. 한 행이 티켓 하나이고 ticket_id 가 키예요. customer_id 와 severity 묶음은 sla_terms 의 (customer_id, severity) 를 가리키고, 한 티켓은 한 고객사에만 속해요. severity 는 접수 때 정한 장애 등급이고 처리하는 동안 바뀌지 않아요. affected_layer 는 문제가 나타난 구간으로 데이터 파이프라인·온톨로지·Agent·Workflow·연동 구간 가운데 하나예요. opened_at 은 티켓 시스템에 티켓이 열린 시각이고, 계약한 시간은 이 시각부터 세요. 밤이나 주말에 열린 티켓, 하루를 넘겨 열려 있는 티켓, 같은 등급인데 고객사마다 계약한 시간이 다른 티켓이 섞여 있어요. 큰 데이터는 2025년 10월 28일부터 2026년 10월 27일까지 열린 티켓 1,927건이고, 시작용은 마지막 날 15시 점검 때 본 티켓 16건(그 시각에 아직 복구되지 않은 티켓과 그날 0시부터 15시 사이에 복구된 티켓)을 같은 ID·같은 값으로 잘라 낸 것이에요.
전체 16행 가운데 앞 5행이에요.
| ticket_id | customer_id | severity | affected_layer | opened_at |
|---|---|---|---|---|
| TK-11903 | CU-03 | P3 | workflow | 2026-10-26T10:59:45+09:00 |
| TK-11904 | CU-01 | P3 | pipeline | 2026-10-26T12:27:28+09:00 |
| TK-11906 | CU-02 | P4 | integration | 2026-10-26T15:25:26+09:00 |
| TK-11907 | CU-08 | P4 | integration | 2026-10-26T15:35:01+09:00 |
| TK-11908 | CU-05 | P2 | agent | 2026-10-26T16:20:47+09:00 |
16행 전부를 JSON 파일 하나로 받을 수 있어요.
같은 형식으로 만든 1,927행이에요. 위 데이터가 이 안에 그대로 들어 있어요(한 줄에 한 행, gzip 압축).
미리보기와 내려받는 데이터 모두 이 형식(JSON Schema)을 따라요.
{
"type": "object",
"description": "장애 티켓 하나. 키는 ticket_id.",
"additionalProperties": false,
"required": [
"ticket_id",
"customer_id",
"severity",
"affected_layer",
"opened_at"
],
"properties": {
"ticket_id": {
"type": "string",
"pattern": "^TK-[0-9]{5}$",
"description": "티켓 번호. 이 표의 키예요."
},
"customer_id": {
"type": "string",
"pattern": "^CU-[0-9]{2}$",
"description": "티켓을 접수한 고객사 코드. severity 와 묶어 sla_terms 의 (customer_id, severity) 를 가리켜요."
},
"severity": {
"type": "string",
"enum": [
"P1",
"P2",
"P3",
"P4"
],
"description": "접수 때 정한 장애 등급. 처리하는 동안 바뀌지 않아요."
},
"affected_layer": {
"type": "string",
"enum": [
"pipeline",
"ontology",
"agent",
"workflow",
"integration"
],
"description": "문제가 나타난 구간. pipeline 은 데이터 파이프라인, ontology 는 온톨로지, agent 는 Agent, workflow 는 Workflow, integration 은 고객사 시스템과의 연동 구간이에요."
},
"opened_at": {
"type": "string",
"format": "date-time",
"description": "티켓 시스템에 티켓이 열린 시각. 티켓 시스템 서버 시계의 한국 시간(+09:00) ISO 8601, 초 단위. 계약한 시간은 이 시각부터 세요."
}
}
}티켓마다 처리하는 동안 티켓 시스템에 남은 기록이에요. 한 행이 기록 하나이고 event_id 가 키예요. ticket_id 는 tickets.ticket_id 를 가리켜요. event_type 은 여섯 가지예요. assigned 는 티켓이 열리면서 운영 팀에 배정된 기록, customer_update 는 고객에게 진행 상황을 알린 기록, transferred 는 다른 팀에 넘긴 기록, restored 는 서비스가 정상으로 돌아온 기록, reopened 는 복구 뒤 같은 문제가 다시 나타나 티켓을 다시 연 기록, closed 는 고객이 정상 사용을 확인해 티켓을 닫은 기록이에요. assigned_team 은 assigned·transferred 기록에만 있고 그 기록으로 티켓을 맡게 된 팀(운영 팀·구축 FDE·Product팀·Infra팀·고객사 IT)이에요. 다른 기록에서는 null 이에요. event_at 은 티켓 시스템 서버 시계로 기록이 남은 시각이고, tickets.opened_at 과 같은 시계예요. 배정 기록만 있고 아직 고객 안내가 없는 티켓, 다른 팀에 넘어가 있는 동안 복구 기한이 지난 티켓, 복구 뒤 다시 열린 티켓, 기한 안에 복구했지만 닫힌 것은 기한 뒤인 티켓, 점검 시각 몇 분 뒤에 남은 기록이 들어 있어요. 큰 데이터에는 2026년 10월 27일 23시 59분 59초까지 남은 기록 11,695건이 모두 있고, 시작용은 시작용 티켓 16건의 기록 80건 전부예요(15시 점검 뒤에 남은 기록도 들어 있어요).
전체 80행 가운데 앞 5행이에요.
| event_id | ticket_id | event_type | assigned_team | event_at |
|---|---|---|---|---|
| EV-011581 | TK-11903 | assigned | operation | 2026-10-26T11:02:06+09:00 |
| EV-011582 | TK-11903 | customer_update | — | 2026-10-26T11:24:33+09:00 |
| EV-011583 | TK-11904 | assigned | operation | 2026-10-26T12:28:35+09:00 |
| EV-011585 | TK-11904 | customer_update | — | 2026-10-26T12:55:46+09:00 |
| EV-011588 | TK-11906 | assigned | operation | 2026-10-26T15:26:56+09:00 |
80행 전부를 JSON 파일 하나로 받을 수 있어요.
같은 형식으로 만든 11,695행이에요. 위 데이터가 이 안에 그대로 들어 있어요(한 줄에 한 행, gzip 압축).
미리보기와 내려받는 데이터 모두 이 형식(JSON Schema)을 따라요.
{
"type": "object",
"description": "티켓 처리 기록 하나. 키는 event_id.",
"additionalProperties": false,
"required": [
"event_id",
"ticket_id",
"event_type",
"assigned_team",
"event_at"
],
"properties": {
"event_id": {
"type": "string",
"pattern": "^EV-[0-9]{6}$",
"description": "기록 번호. 이 표의 키예요."
},
"ticket_id": {
"type": "string",
"pattern": "^TK-[0-9]{5}$",
"description": "이 기록이 남은 티켓. tickets.ticket_id 를 가리켜요."
},
"event_type": {
"type": "string",
"enum": [
"assigned",
"customer_update",
"transferred",
"restored",
"reopened",
"closed"
],
"description": "assigned 는 티켓이 열리면서 운영 팀에 배정됨, customer_update 는 고객에게 진행 상황을 알림, transferred 는 다른 팀에 넘김, restored 는 서비스가 정상으로 돌아옴, reopened 는 복구 뒤 같은 문제가 다시 나타나 티켓을 다시 엶, closed 는 고객이 정상 사용을 확인해 티켓을 닫음이에요."
},
"assigned_team": {
"type": [
"string",
"null"
],
"enum": [
"operation",
"build_fde",
"product",
"infra",
"customer_it",
null
],
"description": "assigned·transferred 기록으로 티켓을 맡게 된 팀. operation 은 운영 팀, build_fde 는 구축 FDE, product 는 Product팀, infra 는 Infra팀, customer_it 는 고객사 IT 담당자예요. 다른 종류의 기록에서는 null 이에요."
},
"event_at": {
"type": "string",
"format": "date-time",
"description": "기록이 남은 시각. 티켓 시스템 서버 시계의 한국 시간(+09:00) ISO 8601, 초 단위. tickets.opened_at 과 같은 시계예요."
}
}
}운영 팀이 열린 티켓을 함께 본 점검 회차예요. 한 행이 점검 한 번이고 review_id 가 키예요. 이 데이터에는 평일(월~금) 10시와 15시에 한 번씩 점검한 기록이 있어요. reviewed_at 은 점검한 시각이고, 이 기능이 '지금'으로 삼는 시각이에요. 다른 표를 가리키는 칸은 없어요. 큰 데이터는 2025년 10월 28일부터 2026년 10월 27일까지 점검 522번 전부이고, 시작용은 마지막 날(10월 27일 화요일)의 점검 두 번이에요.
전체 2행 가운데 앞 2행이에요.
| review_id | reviewed_at |
|---|---|
| RV-0521 | 2026-10-27T10:00:00+09:00 |
| RV-0522 | 2026-10-27T15:00:00+09:00 |
2행 전부를 JSON 파일 하나로 받을 수 있어요.
같은 형식으로 만든 522행이에요. 위 데이터가 이 안에 그대로 들어 있어요(한 줄에 한 행, gzip 압축).
미리보기와 내려받는 데이터 모두 이 형식(JSON Schema)을 따라요.
{
"type": "object",
"description": "운영 팀 점검 한 번. 키는 review_id.",
"additionalProperties": false,
"required": [
"review_id",
"reviewed_at"
],
"properties": {
"review_id": {
"type": "string",
"pattern": "^RV-[0-9]{4}$",
"description": "점검 번호. 이 표의 키예요."
},
"reviewed_at": {
"type": "string",
"format": "date-time",
"description": "점검한 시각. 티켓 시스템과 같은 시계의 한국 시간(+09:00) ISO 8601, 초 단위. 이 기능이 '지금'으로 삼는 시각이에요."
}
}
}