로앤FDE팀 Backend / DevOps Engineer (5년 이상)
3.0 (84)로앤컴퍼니
경력근거: 보안·데이터 거버넌스·컴플라이언스 요구 대응
24일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
로앤컴퍼니 FDE팀은 대형로펌과 기업 법무팀 환경에 슈퍼로이어를 올리면서 데이터 격리와 감사 추적을 계약 조건으로 대응합니다. 로펌은 같은 회사 안에서도 사건마다 볼 수 있는 사람이 갈리는 곳이라 접근 통제가 기능이 아니라 규정이고, 그 준수를 증명하는 자료를 정기적으로 내야 합니다. 이 도구는 그 증명을 자동으로 만듭니다. 공고 업무는 배포·구축부터 연동 개발까지 걸쳐 있는데 1주 범위에서 감사 대조 축을 골랐습니다. 이 포트폴리오는 두 명부를 기간까지 포함해 대조하는 기술을 보여줍니다. 법률 실무나 ISMS·SOC 2 심사 대응의 전문성은 주장하지 않습니다. 규제 심사의 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
주요 업무에 보안·데이터 거버넌스·컴플라이언스 대응이 있고 괄호로 데이터 격리와 감사 추적이 명시돼 있습니다. 대형로펌은 사건별 접근 차단이 계약 조건이라 이 대조가 실제로 필요합니다.
고객별 커스터마이징·자동화 백엔드 개발과 데이터 파이프라인 구축이 업무입니다. 접근 로그를 모아 판정하는 배치가 그 파이프라인의 한 갈래입니다.
엔터프라이즈 배포·구축과 운영이 첫 업무이고 온프렘 환경이 포함됩니다. 감사 자료는 밖으로 내보낼 수 없어 고객 환경 안에서 돌아가는 형태여야 합니다.
로펌의 문서 접근 로그를 사건별 배정 명부와 대조해, 배정되지 않은 사람이 열람한 건과 배정이 끝난 뒤 열람한 건을 판단하는 CLI입니다. 판정은 배정 기간과 명부 대조로 정합니다.
로펌에 들어간 FDE입니다. 감사 때 '이 사건 문서를 누가 봤느냐'는 질문이 오면 로그를 받아 엑셀로 정렬해 눈으로 맞춰 보는데, 사건이 수백 건이라 배정 기간까지 대조하다 보면 하루가 갑니다.
접근 로그와 배정 명부에 사건 번호와 기간이 같이 남아 있으면, 권한을 벗어난 열람은 사람이 눈으로 맞추지 않아도 대조로 판단됩니다.
접근 로그와 배정 명부를 인자로 받아 사유별 판정표를 출력하고 감사 리포트를 떨구는 CLI입니다. 실제 문서 내용은 읽지 않고 접근 기록만 대조합니다.
직전 감사 결과를 함께 받아 이번에 새로 생긴 위반과 해소된 건을 가려내는 비교기입니다.
컨테이너로 묶어 고객 클러스터에서 주기 실행하고 결과만 담당자에게 남기는 배치 구성입니다.
접근 로그 20건과 배정 명부를 넣어 사유별 판정표와 감사 리포트가 나오는 것을 시연합니다.
결측·중복·미등록 사건 번호가 섞인 입력 30종을 넣어도 출력 형식이 깨지지 않고, 판정하지 못한 접근은 사유가 붙어 남습니다.
배정 종료일이 비어 있으면 만료로 단정하지 않고 확인 필요로 따로 답니다. 규정 위반으로 잘못 몰지 않습니다.
판정과 손으로 만든 정답표를 맞춰 사유별로 어긋난 건을 셉니다. 단, 로그와 정답을 모두 작성자가 만든 합성 기준이라 성능 측정이 아니라 데모 조건 동작입니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 더미데이터 자가채점이며, 실제 판정 정확도는 로앤컴퍼니가 들어가는 실제 로펌의 접근 로그와 실제 배정 규정이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 결측·중복·미등록 사건 번호·기간 경계를 더미에 일부러 섞어 쉬운 문제만 푸는 것을 피합니다.
명부에 없다고 해서 규정 위반이라고 단정할 수 없습니다. 명부 갱신이 늦었거나 임시 지원 인력일 수 있어, 이 도구는 확인 대상으로 올리고 판단은 컴플라이언스 담당자가 합니다.
실제 도입하면 로펌마다 사건 번호 체계와 배정 절차가 다릅니다. 명부를 어디서 받을지 정하는 일이 도입 단계의 실제 과제입니다.
더미는 실제 접근 로그가 아닙니다. 실제 로그에는 의뢰인 정보가 들어 있어 반출이 막히므로, 이 도구는 고객 환경 안에서 돌리는 것을 전제로 설계했습니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
슈퍼로이어에서 남은 문서 접근 기록입니다. 누가 언제 어느 사건 문서를 어떻게 열람했는지가 담깁니다. 결측과 중복, 명부에 없는 사건 번호를 일부러 섞었습니다.
| access_no | user_key | matter_raw | doc_no | accessed_on | action |
|---|---|---|---|---|---|
| AC-001 | U-101 | 2026-형사-0042 | D-9001 | 2026-07-10 | view |
| AC-002 | U-101 | 2026-형사-0042 | D-9002 | 2026-07-11 | download |
| AC-003 | U-102 | 2026-민사-0117 | D-9101 | 2026-07-12 | view |
| AC-004 | U-103 | 2026-형사-0042 | D-9003 | 2026-07-13 | view |
| AC-005 | U-104 | 2026형사0042 | D-9004 | 2026-07-14 |
아래 JSON Schema에 맞는 문서 접근 기록을 더 만들어 주세요. {"type":"object","properties":{"access_no":{"type":"string"},"user_key":{"type":"string"},"matter_raw":{"type":"string"},"doc_no":{"type":"string"},"accessed_on":{"type":"string"},"action":{"type":"string","enum":["view","download","print"]}},"required":["access_no","user_key","matter_raw","doc_no","accessed_on","action"]} 실제 인물이나 사건을 쓰지 말고 가짜 식별자만 쓰세요. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 중복으로 같은 access_no가 두 행에 있는 재전송 건, 둘째 미매핑으로 matter_raw가 명부에 없어 matter_id가 null인 행, 셋째 표기흔들림으로 같은 사건을 2026-형사-0042와 2026형사0042처럼 다르게 적은 행, 넷째 경계극단으로 배정 종료 바로 다음 날 열람한 행, 다섯째 명부에 아예 배정되지 않은 사번이 열람한 행. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 action에 enum 밖 값을 넣거나 required 필드를 빼서 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"access_no":{"type":"string"},"user_key":{"type":"string"},"matter_raw":{"type":"string"},"doc_no":{"type":"string"},"accessed_on":{"type":"string"},"action":{"type":"string","enum":["view","download","print"]}},"required":["access_no","user_key","matter_raw","doc_no","accessed_on","action"]}사건별 배정 명부입니다. 누가 어느 사건에 언제부터 언제까지 배정됐는지가 판정 기준이 됩니다. 종료일이 비어 있는 진행 중 배정도 함께 담습니다.
| matter_raw | matter_id | user_key | role | assigned_from | assigned_until |
|---|---|---|---|---|---|
| 2026-형사-0042 | M-2026-0042 | U-101 | lead | 2026-06-01 | — |
| 2026형사0042 | M-2026-0042 | U-104 | paralegal | 2026-06-15 | — |
| 2026-민사-0117 | M-2026-0117 | U-102 | lead | 2026-05-01 | 2026-08-15 |
| 2026-민사-0117 | M-2026-0117 | U-101 | associate | 2026-05-01 | — |
| 2026-민사-0205 | M-2026-0205 | U-106 | lead | 2026-07-01 | — |
아래 JSON Schema에 맞는 사건 배정 명부 행을 더 만들어 주세요. {"type":"object","properties":{"matter_raw":{"type":"string"},"matter_id":{"type":"string"},"user_key":{"type":"string"},"role":{"type":"string","enum":["lead","associate","paralegal"]},"assigned_from":{"type":"string"},"assigned_until":{"type":["string","null"]}},"required":["matter_raw","matter_id","user_key","role","assigned_from","assigned_until"]} 실제 인물이나 사건을 쓰지 말고 가짜 식별자만 쓰세요. 같은 matter_id에 하이픈이 있는 표기와 없는 표기를 함께 두어 흔들림을 흡수하게 하고, assigned_until이 null인 진행 중 배정과 이미 끝난 배정을 섞어 주세요. 접근 로그에는 나오지만 명부에는 없는 사건이 남도록 일부는 일부러 등록하지 말아 주세요. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 role에 enum 밖 값을 넣어 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"matter_raw":{"type":"string"},"matter_id":{"type":"string"},"user_key":{"type":"string"},"role":{"type":"string","enum":["lead","associate","paralegal"]},"assigned_from":{"type":"string"},"assigned_until":{"type":["string","null"]}},"required":["matter_raw","matter_id","user_key","role","assigned_from","assigned_until"]}| TypeScript | 로그와 명부를 읽어 대조 규칙을 돌리고 리포트를 만드는 CLI 본체입니다. |
| Node.js | CLI 실행 환경이며 대용량 로그를 스트림으로 읽어 메모리를 아낍니다. |
| PostgreSQL | 접근 로그와 배정 명부, 감사 이력을 담는 저장소입니다. |
| Kubernetes | 3주차에 주기 배치로 고객 클러스터 안에서 돌릴 때 씁니다. |
| 감사 추적 | 누가 언제 무엇을 봤는지가 남아 있어야 이 대조가 성립하며, 그 로그 형식이 이 도구의 입력입니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 직전 감사와 비교해 새로 생긴 건만 봅니다.
✓ pass → 비교까지가 한 덩어리입니다. 더 키우려면 고객 환경 안에서 주기 실행합니다.
접근 기록 한 건의 판정 결과입니다. 배정 범위 안의 열람인지, 아니면 무엇을 벗어났는지를 근거와 함께 담습니다.
{"type":"object","properties":{"access_no":{"type":"string"},"verdict":{"type":"string","enum":["authorized","not_assigned","assignment_expired","matter_unmapped","duplicate_access"]},"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":["access_no","verdict","evidence","next_action"]}[
{
"access_no": "AC-001",
"verdict": "authorized",
"evidence": [
{
"field": "user_key",
"value": "U-101"
},
{
"field": "matter_raw",
"value": "2026-형사-0042"
},
{
"field": "assigned_until",
"value": null
}
],
"next_action": "배정된 사건이고 기간도 유효합니다. 감사 대상에서 제외합니다."
},
{
"access_no": "AC-009",
"verdict": "authorized",
"evidence": [
{
"field": "user_key",
"value": "U-106"
},
{
"field": "matter_raw",
"value": "2026-민사-0205"
},
{
"field": "role",
"value": "lead"
}
],
"next_action": "배정된 사건이고 기간도 유효합니다. 감사 대상에서 제외합니다."
},
{
"access_no": "AC-005",
"verdict": "authorized",
"evidence": [
{
"field": "matter_raw",
"value": "2026형사0042",
"quote": "2026형사0042"
},
{
"field": "matter_raw",
"value": "2026형사0042"
},
{
"field": "user_key",
"value": "U-104"
}
],
"next_action": "표기가 달랐지만 명부 별칭으로 정규화됐고 배정도 유효합니다. 감사 대상에서 제외합니다."
},
{
"access_no": "AC-004",
"verdict": "not_assigned",
"evidence": [
{
"field": "user_key",
"value": "U-103"
},
{
"field": "matter_raw",
"value": "2026-형사-0042"
},
{
"field": "action",
"value": "view"
}
],
"next_action": "명부에 없는 사람이 열람했습니다. 임시 지원인지 명부 누락인지 컴플라이언스 담당자가 확인합니다."
},
{
"access_no": "AC-012",
"verdict": "not_assigned",
"evidence": [
{
"field": "user_key",
"value": "U-103"
},
{
"field": "matter_raw",
"value": "2026-형사-0042"
},
{
"field": "action",
"value": "print"
}
],
"next_action": "명부에 없는 사람이 인쇄까지 했습니다. 위험이 큰 행위라 먼저 확인합니다."
},
{
"access_no": "AC-006",
"verdict": "assignment_expired",
"evidence": [
{
"field": "assigned_until",
"value": "2026-08-15"
},
{
"field": "accessed_on",
"value": "2026-08-20"
},
{
"field": "user_key",
"value": "U-102"
}
],
"next_action": "배정이 끝난 뒤 열람했습니다. 계정 권한 회수가 늦었는지 확인합니다."
},
{
"access_no": "AC-007",
"verdict": "matter_unmapped",
"evidence": [
{
"field": "matter_raw",
"value": "2026-자문-0009",
"quote": "2026-자문-0009"
},
{
"field": "matter_raw",
"value": "2026-자문-0009"
}
],
"next_action": "명부에 없는 사건 번호입니다. 명부를 최신으로 받은 뒤 다시 판정합니다."
},
{
"access_no": "AC-005",
"verdict": "duplicate_access",
"evidence": [
{
"field": "access_no",
"agg": "count",
"value": 2
}
],
"next_action": "같은 접근 번호가 두 번 들어왔습니다. 앞 건으로만 판정하고 재전송분을 뺍니다."
}
][자동 검증 · 1주차] 1. verdict가 enum 다섯 값 안에 있는지 확인합니다. 2. access_no·verdict·evidence·next_action이 모두 있는지 확인합니다. 3. matter_id가 null이면 verdict가 matter_unmapped인지 확인합니다. 4. verdict가 assignment_expired이면 accessed_on이 assigned_until보다 뒤인지 다시 계산합니다. 5. evidence의 field가 두 입력 표의 컬럼에 실재하는지 확인합니다. 6. evidence의 quote가 그 행 matter_raw의 일부인지 확인합니다. 7. next_action이 존댓말로 끝나는지 확인합니다. [판정 규칙] 1. 사건 표기은 대소문자와 띄어쓰기, 구분자를 없애 소문자로 모은 뒤 matter_assignments의 matter_id와 맞춥니다. 맞는 것이 없으면 미매핑으로 남기고 그 행은 나머지 판정에서 뺍니다. [수동 검증] 1. 명부에 없는 열람이 실제 위반인지 임시 지원인지 컴플라이언스 담당자가 판단합니다. 2. AC-011·AC-014처럼 배정과 기간이 모두 맞는 열람은 사유를 달지 않는 것이 맞는지 확인합니다. [평가 러너 · 2주차] 1. 직전 감사 결과와 비교해 새로 생긴 위반과 해소된 건을 셉니다. 2. 로그와 정답을 작성자가 만든 합성 기준이라 이 수치는 성능 측정이 아니라 데모 조건 동작입니다.