Rimini Street
경력근거: separation of duties, audit evidence and rollback planning
※ 실제 산출물이 아닌 AI 예측 시안입니다.
Rimini Street의 이 자리는 고객사 기간계에 에이전트를 붙이면서 고객사의 릴리스 거버넌스 안에서 코드를 넘기는 일입니다. 공고가 변경 승인과 직무 분리, 감사 증거, 롤백 계획을 업무 문장 안에 직접 적어 두었는데, 이건 남의 회사 규정 안에서 배포하는 자리에서만 지켜야 하는 것들입니다. 자기 제품을 자기 파이프라인으로 내보내는 조직에는 이 대조가 필요 없습니다. 공고 업무는 아키텍처 설계부터 인수인계 후 에스컬레이션까지 걸쳐 있는데 1주 범위에서 고를 수 있는 것은 하나라 승인 증거 축을 골랐습니다. 이 포트폴리오는 규정을 데이터로 두고 규칙으로 집행해 근거를 보여주는 기술을 보여줍니다. SAP나 Oracle 기간계 업무 자체의 전문성은 주장하지 않습니다. 그 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
고객사 소스 관리와 배포 인프라 안에서 변경 승인과 직무 분리, 감사 증거, 롤백 계획을 지켜 개발한다고 업무에 적혀 있습니다. 그 증거가 갖춰졌는지 보는 일이 이 도구의 대상입니다.
기간계 시스템을 건드리는 에이전트 행위마다 권한 범위와 승인 게이트, 감사 추적, 롤백 경로를 구현하는 일이 업무입니다. 사람이 낸 배포에도 같은 증거가 필요합니다.
컷오버와 초기 운영을 지나 지원 조직으로 넘기는 구조화된 인수인계가 업무에 있습니다. 승인 증거 목록이 그 인계 문서의 핵심 자료입니다.
고객사 배포 이력과 변경 승인 기록을 대조해, 승인 없이 나갔거나 승인자와 실행자가 같거나 롤백 계획이 빠진 배포를 사유별로 나눠 보여주는 관리자 페이지입니다. 판정은 승인 존재와 승인 시각 순서, 승인자와 실행자의 분리를 규정과 견주는 대조로 정합니다.
고객사 기간계에 에이전트를 붙이고 인수인계를 준비하는 파견 엔지니어입니다. 감사 담당자가 지난 분기 배포의 승인 증거를 요구하면 배포 로그와 결재 시스템을 각각 내려받아 엑셀에서 맞춰 보는데, 건수가 쌓이면 어디까지 확인했는지 놓칩니다.
배포와 승인이 같은 변경 번호로 이어지면, 증거가 갖춰졌는지는 사람이 두 시스템을 오가지 않아도 대조로 갈라집니다.
배포 이력과 승인 기록을 올리면 배포별 판정을 사유별로 보여주는 관리자 페이지입니다. 고객사 시스템에 붙지 않고 내려받은 기록만 읽습니다.
기간을 지정하면 그 구간의 배포와 승인을 묶어 감사 제출용 목록으로 내보내는 화면입니다.
승인 규정을 파일로 분리해 고객사마다 다른 결재 단계를 같은 판정으로 돌리고, 판정 결과를 인계 문서에 붙일 수 있게 내보냅니다.
담당자가 배포 40건과 승인 기록을 올려 증거가 빈 배포가 사유별로 나뉜 화면을 보는 것을 시연합니다.
결측·중복·미등록 시스템이 섞인 입력 30종을 올려도 화면이 깨지지 않고, 판정하지 못한 배포는 사유가 붙어 남습니다.
승인 시각이 비어 있는 배포는 승인된 것으로 세지 않고 시각 누락으로 따로 답니다. 확인하지 못한 것을 통과로 만들지 않습니다.
판정과 손으로 만든 정답표를 맞춰 사유별로 어긋난 건을 셉니다. 단, 이력과 정답을 모두 작성자가 만든 합성 기준이라 성능 측정이 아니라 데모 조건 동작입니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 더미데이터 자가채점이며, 실제 준수율은 Rimini Street 고객사의 실제 배포 이력과 실제 결재 기록이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
증거가 다 갖춰진 배포만 모아 두면 감사 대응 연습이 되지 않습니다. 시스템 표기가 흔들린 건과 롤백 계획이 빈 건, 승인 기록이 없는 배포가 섞여 있어야 판정에 뜻이 생깁니다.
증거가 없다고 해서 규정을 어겼다고 단정할 수 없습니다. 긴급 배포는 사후 승인이 규정일 수 있으므로, 판정은 지금 기록에 증거가 없다는 사실까지만 읽어야 합니다.
실제 도입하면 고객사마다 결재 단계와 예외 절차가 다릅니다. 규정을 감사 담당자와 합의해 채우는 일이 도입 단계의 실제 과제입니다.
에이전트가 기간계에서 무엇을 했는지의 행위 추적은 이 도구의 범위 밖입니다. 사람이 낸 배포의 증거까지만 보므로, 에이전트 행위 감사는 따로 다룹니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 파이프라인에서 내려받은 배포 이력입니다. 대상 시스템 표기가 파일마다 대소문자로 흔들리고, 사전에 없는 신규 시스템과 같은 배포 번호가 두 번 들어온 건, 롤백 계획이 비어 있는 행을 일부러 섞었습니다.
| deploy_no | change_no | system_raw | deployed_by | deployed_at | rollback_plan |
|---|---|---|---|---|---|
| DP-001 | CHG-1001 | sap_ecc | 김도현 | 2026-08-05T14:00 | 이전 전송 요청 재적용 |
| DP-002 | CHG-1002 | SAP_ECC | 박서준 | 2026-08-06T10:00 | 스냅샷 복구 |
| DP-003 | — | sap_ecc | 김도현 | 2026-08-07T22:00 | 이전 전송 요청 재적용 |
| DP-004 | CHG-1004 | oracle_ebs | 이수민 | 2026-08-08T09:00 | — |
| DP-005 | CHG-1005 | Oracle_EBS | 최민서 | 2026-08-09T11:00 | 패치 되돌리기 |
아래 JSON Schema에 맞는 배포 이력 행을 더 만들어 주세요. {"type":"object","properties":{"deploy_no":{"type":"string"},"change_no":{"type":["string","null"]},"system_raw":{"type":"string"},"deployed_by":{"type":"string"},"deployed_at":{"type":"string"},"rollback_plan":{"type":["string","null"]}},"required":["deploy_no","change_no","system_raw","deployed_by","deployed_at","rollback_plan"]} deployed_by와 rollback_plan은 한글로 적어 주세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 미매핑으로 system_raw가 사전에 없어 system_id가 null인 행, 둘째 표기흔들림으로 같은 시스템을 sap_ecc와 SAP_ECC와 Sap_Ecc처럼 대소문자만 다르게 적은 행, 셋째 중복으로 같은 deploy_no가 두 행에 있는 재적재 건, 넷째 결측으로 change_no나 rollback_plan이 null인 행, 다섯째 경계극단으로 승인 시각과 배포 시각이 같은 분에 찍힌 행. 증거가 갖춰진 정상 배포가 전체의 절반쯤 되게 해 주세요. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 deployed_at을 빼거나 deploy_no에 숫자 타입을 넣어 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"deploy_no":{"type":"string"},"change_no":{"type":["string","null"]},"system_raw":{"type":"string"},"deployed_by":{"type":"string"},"deployed_at":{"type":"string"},"rollback_plan":{"type":["string","null"]}},"required":["deploy_no","change_no","system_raw","deployed_by","deployed_at","rollback_plan"]}고객사 결재 시스템에서 내려받은 변경 승인 기록입니다. 승인 시각이 비어 있는 건과 승인자가 실행자와 같은 건을 일부러 섞었습니다.
| change_no | approver | approved_at | approval_kind | requires_separation |
|---|---|---|---|---|
| CHG-1001 | 오세영 | 2026-08-05T11:00 | standard | true |
| CHG-1002 | 박서준 | 2026-08-06T09:00 | standard | true |
| CHG-1004 | 오세영 | 2026-08-08T08:00 | standard | true |
| CHG-1005 | 윤가람 | 2026-08-09T11:00 | emergency | false |
| CHG-1006 | 오세영 | 2026-08-10T13:00 | standard | true |
아래 JSON Schema에 맞는 변경 승인 행을 더 만들어 주세요. {"type":"object","properties":{"change_no":{"type":"string"},"approver":{"type":"string"},"approved_at":{"type":["string","null"]},"approval_kind":{"type":"string","enum":["standard","emergency","pre_approved"]},"requires_separation":{"type":"boolean"}},"required":["change_no","approver","approved_at","approval_kind","requires_separation"]} approver는 한글 이름으로 적어 주세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 결측으로 approved_at이 null인 승인 미완료 건, 둘째 approver가 배포 실행자와 같은 이름인 건, 셋째 approved_at이 배포 시각보다 늦은 사후 승인 건, 넷째 배포 이력에는 없는 change_no. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 approval_kind에 enum 밖 값을 넣거나 approver를 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"change_no":{"type":"string"},"approver":{"type":"string"},"approved_at":{"type":["string","null"]},"approval_kind":{"type":"string","enum":["standard","emergency","pre_approved"]},"requires_separation":{"type":"boolean"}},"required":["change_no","approver","approved_at","approval_kind","requires_separation"]}감사 범위에 들어가는 배포 대상 기간계 목록입니다. 규제 대상 여부를 함께 담았고, 목록에 없는 시스템의 배포를 판정에서 가르는 데 씁니다.
| system_id | system_label | vendor | is_regulated |
|---|---|---|---|
| oracle_ebs | 오라클 EBS | Oracle | true |
| sap_ecc | SAP ECC | SAP | true |
| servicenow | 서비스나우 | ServiceNow | false |
| peoplesoft | 피플소프트 | Oracle | true |
| jde_e1 | JD 에드워즈 E1 | Oracle | true |
아래 JSON Schema에 맞는 target_systems 행을 더 만들어 주세요. {"type":"object","properties":{"system_id":{"type":"string"},"system_label":{"type":"string"},"vendor":{"type":"string"},"is_regulated":{"type":"boolean"}},"required":["system_id","system_label","vendor","is_regulated"]} system_id는 영문 스네이크 표기이고 is_regulated는 그 시스템이 감사 대상인지를 나타냅니다.{"type":"object","properties":{"system_id":{"type":"string"},"system_label":{"type":"string"},"vendor":{"type":"string"},"is_regulated":{"type":"boolean"}},"required":["system_id","system_label","vendor","is_regulated"]}| Python | 배포 이력과 승인 기록을 읽어 대조 판정을 돌리는 본체입니다. |
| SQL | 고객사 결재 시스템에서 승인 기록을 기간으로 잘라 내려받는 질의를 씁니다. |
| TypeScript | 사유별 판정과 감사 제출용 목록을 담당자가 보는 화면입니다. |
| REST | 배포 이력을 고객사 파이프라인에서 받아 오는 입력 경로로 두되, 1주차에는 내려받은 파일만 읽습니다. |
| CI/CD | 판정을 배포 파이프라인 앞에 걸어 승인 없는 배포가 나가지 못하게 합니다. |
| 감사 추적 | 이 도구의 산출물이 곧 감사 증거 목록이라, 인계 문서에 그대로 붙습니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 감사 기간을 잘라 증거 묶음을 만듭니다.
✓ pass → 묶음까지가 한 덩어리입니다. 더 키우려면 승인 규정을 고객사별로 분리합니다.
위 예측 UI 는 3주차까지 완주했을 때의 화면입니다. 1주차에 실제로 만드는 것은 아래 표시된 화면 하나입니다.
verdict사유 라벨 · deploy_no + 한 줄 요약(근거 수치 포함)화면·코드·면접에서 이 단어를 그대로 씁니다. 키는 출력 스키마의 enum 과 같습니다.
evidence_complete증거 완비no_change_record변경 번호 없음approval_not_found승인 기록 없음approved_after_deploy사후 승인separation_violated직무 분리 위반approval_time_missing승인 시각 누락rollback_plan_missing롤백 계획 누락system_unmapped시스템 미매핑duplicate_deploy배포 번호 중복배포 한 건의 승인 증거가 규정대로 갖춰졌는지의 판정 결과입니다. 빠졌다면 무엇이 빠졌는지를 근거와 함께 담습니다.
{"type":"object","properties":{"deploy_no":{"type":"string"},"verdict":{"type":"string","enum":["evidence_complete","no_change_record","approval_not_found","approved_after_deploy","separation_violated","approval_time_missing","rollback_plan_missing","system_unmapped","duplicate_deploy"]},"approver":{"type":["string","null"]},"deployer":{"type":["string","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":["deploy_no","verdict","approver","deployer","evidence","next_action"]}[
{
"deploy_no": "DP-001",
"verdict": "evidence_complete",
"approver": "오세영",
"deployer": "김도현",
"evidence": [
{
"field": "approved_at",
"value": "2026-08-05T11:00"
},
{
"field": "deployed_at",
"value": "2026-08-05T14:00"
},
{
"field": "rollback_plan",
"value": "이전 전송 요청 재적용"
}
],
"next_action": "증거가 모두 갖춰졌습니다. 감사 제출 목록에 넣습니다."
},
{
"deploy_no": "DP-010",
"verdict": "evidence_complete",
"approver": "오세영",
"deployer": "정하늘",
"evidence": [
{
"field": "approved_at",
"value": "2026-08-14T10:00"
},
{
"field": "deployed_at",
"value": "2026-08-14T13:00"
},
{
"field": "rollback_plan",
"value": "업데이트 세트 회수"
}
],
"next_action": "증거가 모두 갖춰졌습니다. 감사 제출 목록에 넣습니다."
},
{
"deploy_no": "DP-003",
"verdict": "no_change_record",
"approver": null,
"deployer": "김도현",
"evidence": [
{
"field": "change_no",
"value": null
},
{
"field": "deployed_at",
"value": "2026-08-07T22:00"
}
],
"next_action": "변경 번호 없이 배포가 나갔습니다. 사후 변경 요청을 올릴지 감사 담당자와 정합니다."
},
{
"deploy_no": "DP-002",
"verdict": "separation_violated",
"approver": "박서준",
"deployer": "박서준",
"evidence": [
{
"field": "approver",
"value": "박서준"
},
{
"field": "deployed_by",
"value": "박서준"
},
{
"field": "requires_separation",
"value": true
}
],
"next_action": "승인자와 실행자가 같습니다. 직무 분리가 필요한 변경이므로 재승인 절차를 밟습니다."
},
{
"deploy_no": "DP-008",
"verdict": "approved_after_deploy",
"approver": "오세영",
"deployer": "이수민",
"evidence": [
{
"field": "approved_at",
"value": "2026-08-12T18:00"
},
{
"field": "deployed_at",
"value": "2026-08-12T16:00"
}
],
"next_action": "승인이 배포 뒤에 찍혔습니다. 긴급 절차로 처리된 것인지 결재 이력을 확인합니다."
},
{
"deploy_no": "DP-007",
"verdict": "approval_time_missing",
"approver": "윤가람",
"deployer": "한지우",
"evidence": [
{
"field": "approved_at",
"value": null
},
{
"field": "approval_kind",
"value": "standard"
}
],
"next_action": "승인 시각이 비어 있어 순서를 확인하지 못했습니다. 승인된 것으로 세지 않고 결재 기록을 다시 받습니다."
},
{
"deploy_no": "DP-004",
"verdict": "rollback_plan_missing",
"approver": "오세영",
"deployer": "이수민",
"evidence": [
{
"field": "rollback_plan",
"value": null
},
{
"field": "system_raw",
"value": "oracle_ebs",
"quote": "oracle_ebs"
}
],
"next_action": "롤백 계획이 비어 있습니다. 기간계 배포라 계획 없이는 인계 문서에 올리지 않습니다."
},
{
"deploy_no": "DP-007",
"verdict": "system_unmapped",
"approver": "윤가람",
"deployer": "한지우",
"evidence": [
{
"field": "system_raw",
"value": "workday",
"quote": "workday"
}
],
"next_action": "사전에 없는 대상 시스템입니다. 사전에 추가하기 전에는 시스템별 집계에서 빼 둡니다."
}
][자동 검증 · 1주차] 1. verdict가 enum 아홉 값 안에 있는지 확인합니다. 2. deploy_no·verdict·approver·deployer·evidence·next_action이 모두 있는지 확인합니다. 3. approval_kind가 세 값 안에 있는지 확인합니다. 4. approved_at이 null이면 verdict가 approval_time_missing인지 확인합니다. 5. evidence의 field가 두 입력 표의 컬럼에 실재하는지 확인합니다. 6. evidence의 quote가 그 행 system_raw의 일부인지 확인합니다. 7. next_action이 존댓말로 끝나는지 확인합니다. [판정 규칙] 1. 대상 시스템 표기은 대소문자와 띄어쓰기, 구분자를 없애 소문자로 모은 뒤 target_systems의 system_id와 맞춥니다. 맞는 것이 없으면 미매핑으로 남기고 그 행은 나머지 판정에서 뺍니다. 2. 같은 행 번호가 두 번 들어오면 앞 건만 남기고 뒤 건은 적재 단계에서 사유와 함께 뺍니다. [수동 검증] 1. 사후 승인 건이 긴급 절차로 정당한지 감사 담당자가 확인합니다. 2. DP-002·DP-005처럼 시스템 표기가 흔들렸지만 사전으로 맞춰진 배포는 미매핑 사유를 달지 않는 것이 맞는지 확인합니다. [평가 러너 · 2주차] 1. 기간을 잘라 묶었을 때 그 구간의 배포가 빠짐없이 들어오는지 셉니다. 2. 이력과 정답을 작성자가 만든 합성 기준이라 이 수치는 성능 측정이 아니라 데모 조건 동작입니다.
근거: separation of duties, audit evidence and rollback planning