로앤FDE팀 Project Manager(팀장)
3.0 (84)로앤컴퍼니
경력근거: 온보딩·구축 프로젝트의 일정·리소스·SLA 관리 및 고객 단일 컨택 창구 수행
어제 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
로앤컴퍼니 FDE팀의 PM 은 대형로펌과 기업 법무팀이 슈퍼로이어를 실제 업무에 안착시키는 온보딩·구축 프로젝트에서 일정과 SLA 를 관리하며 고객 단일 컨택 창구를 수행하는 자리라서, 매주 고객에게 나가는 진행 보고가 곧 그 창구의 신뢰입니다. 방화벽 승인 대기 같은 구축 지연과 변호사 교육 일정 같은 온보딩 합의가 한 보고에 섞이는 모양은 슈퍼로이어 엔터프라이즈 도입이라는 맥락이 있어야 나옵니다. 고객에게 밀착해 직접 만드는 FDE 방식에서는 처음부터 여러 사람이 쓰는 제품이 아니라 담당자가 터미널에서 바로 돌려 보는 CLI로 기능을 검증하고 수요를 확인하는 편이 자연스러워, 이 포트폴리오도 그 형태로 끝까지 갑니다. 이 포트폴리오가 보여주는 것은 계획 대조 판정 규칙과 인용 검증과 문서 자동 생성 기술이며 법률 도메인 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
온보딩·구축 프로젝트의 일정과 SLA 를 관리하며 고객 단일 컨택 창구를 맡는 자리라서, 그 창구가 매주 손으로 만들던 진행 보고를 계획 대조 규칙으로 판정해 명령 한 번에 문서 파일로 뽑는 것을 제품의 골조로 둡니다.
요구사항을 계약조건의 SLA 와 수용기준으로 옮기는 일이 업무의 중심이라서, 고객 메시지의 수신 시각과 회신 시각을 대조해 응답 초과를 사람 기억이 아니라 날짜 계산으로 판정하고 근거를 함께 남깁니다.
고객에게 밀착해 문제를 풀고 직접 만드는 FDE 방식의 팀이라서, 처음부터 여러 사람이 쓰는 제품이 아니라 담당자 한 명이 터미널에서 바로 돌려 보는 CLI로 기능을 검증하고, 쌓인 판정 기록을 반복 요구의 환류 입력으로 만듭니다.
대형로펌과 기업 법무팀에 슈퍼로이어를 도입하는 프로젝트에서, 온보딩 계획 파일과 Jira 이슈 내보내기 형식의 진행 기록과 고객 메시지 기록 파일을 읽어 기한을 넘긴 작업과 회신이 밀린 고객 요청을 날짜 계산 규칙으로 판정하는 CLI입니다. 터미널에서 report build 명령에 기준일을 주면 이번 주 완료와 지연과 미회신과 다음 주 예정이 절 단위로 갖춰진 고객 공유용 주간 보고 Markdown 파일이 생기고, 표준출력에는 프로젝트별 요약 표가 찍힙니다. 판정마다 어느 기한과 어느 상태 기록을 근거로 삼았는지 함께 적어, 고객이 이유를 물으면 담당자가 바로 근거를 답하게 합니다.
금요일마다 Jira 보드와 메일함과 회의록을 오가며 어떤 작업이 늦었고 어느 고객 질문에 회신을 안 했는지 손으로 추려 주간 보고를 쓰다가, 답장을 빠뜨린 요청을 고객의 지적으로야 알게 되던 도입 프로젝트 담당자가, 터미널에서 명령 한 번을 치고 지연과 미회신과 그 근거가 정리된 보고 초안 파일을 받아 문장만 다듬어 보내고 싶은 사람입니다.
계획 기한과 이슈 상태와 메시지 회신 기록은 전부 날짜가 붙은 데이터라서, 지연과 응답 초과를 사람 기억이 아니라 날짜 계산 규칙으로 판정하면 주간 보고의 골격이 자동으로 서고, 담당자는 문장을 다듬는 일과 고객을 설득하는 일에만 시간을 쓰게 된다는 가정입니다.
온보딩 계획 파일과 Jira 이슈 내보내기 형식의 진행 기록 더미와 고객 메시지 더미를 놓고 터미널에서 report build 명령에 기준일을 주면, 기한을 넘긴 작업과 회신이 밀린 고객 요청을 날짜 근거로 판정해 이번 주 완료와 지연과 미회신과 다음 주 예정 절이 갖춰진 주간 보고 Markdown 파일을 쓰고 표준출력에 프로젝트별 요약 표를 찍는 CLI가 도는 완결품입니다. 만드는 덩어리는 날짜 대조 판정 규칙과 Markdown 문서 생성 둘뿐이고 서버와 배포가 없어 평일 5일에 혼자 끝나는 범위이며, 데이터는 실제 고객 자료 대신 작성자가 만든 더미를 씁니다.
1주차 보고를 입력으로, extract 하위 명령이 회의록과 메일 원문에서 결정사항과 액션아이템과 그 원문 인용을 뽑아 보고의 결정사항 절에 붙이고, 뽑힌 인용이 원문에 실재하는 문자열인지 기계로 대조해 실재하지 않는 항목을 확인 필요 절로 돌리는 추출 계층입니다.
매주 생성한 판정 결과를 PostgreSQL 에 스냅샷으로 쌓고, diff 하위 명령이 새로 늦어진 작업과 해소된 지연과 두 주 연속 밀린 항목을 계산해 보고 맨 앞 변화 요약 절로 붙이며, post 하위 명령이 그 요약 텍스트를 Slack 채널로 보내는 확장입니다. 두 주 연속 밀린 항목 목록은 반복 요구를 제품팀으로 되돌리는 환류 논의의 입력이 됩니다.
온보딩 작업 12건과 고객 메시지 12건을 놓고 터미널에서 report build 명령에 기준일을 주면, 지연 작업과 회신이 밀린 요청과 그 기한·수신 시각 근거가 실린 주간 보고 Markdown 파일이 생기고 표준출력에 프로젝트별 요약 표가 찍히는 흐름을 시연합니다.
기한이 비어 있는 작업과 이미 지난 기한과 별칭으로 적힌 작업 참조와 회신 기록이 없는 메시지를 섞은 입력 30종을 넣어도 도구가 죽지 않고 확인 필요 절로 분리하는 것을 보입니다. 다만 데이터와 정답을 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
기준일을 고정하면 같은 입력에서 언제나 같은 보고 파일이 나오는 결정론을 테스트로 보이고, 지연이나 미회신이 하나라도 있으면 종료 코드로 알려 다른 스크립트가 이어받게 합니다.
2주차에는 추출된 결정사항 전건을 원문 문자열 대조로 확인해 실재하지 않는 인용 0건을 통과 기준으로 삼습니다. 이 기준 역시 원문을 작성자가 만든 합성 조건에서의 동작입니다.
위 수치는 더미데이터 자가채점이며, 실제 보고 품질은 로앤컴퍼니의 실제 Jira 기록과 고객 메일과 도입 담당자의 검토가 있어야 측정 가능합니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모가 도는 상태와 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 기한이 빈 작업과 별칭으로만 적힌 참조와 회신이 필요 없는 인사 메시지와 이미 지난 기한을 더미에 일부러 섞어 두었습니다.
실제 현장의 합의는 회의록에 다 적히지 않고 말로 뒤집히는 경우가 많아, 문서화되지 않은 결정을 어떻게 잡을지는 도입 단계 과제로 따로 둡니다. 인사 메시지처럼 회신이 필요 없는 메시지를 응답 초과로 잡는 과탐도 실데이터에서 규칙을 다듬어야 합니다.
이 포트폴리오가 보여주는 것은 계획 대조 판정과 인용 검증과 문서 자동 생성 기술이며, 법률 문서 해석이나 로펌 업무 절차 같은 리걸테크 도메인 깊이는 주장하지 않습니다. 모르는 부분은 면접에서 모른다고 말합니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
슈퍼로이어 엔터프라이즈 도입 프로젝트의 온보딩 계획과 진행 상태 더미입니다. CLI가 계획 기한과 현재 상태를 대조해 지연을 판정하는 입력 파일이 됩니다.
| task_id | project | phase | task_name | planned_due | status | status_changed_at | owner | blocked_reason |
|---|---|---|---|---|---|---|---|---|
| T-101 | 가온합동법률사무소 도입 | contract | 계약 부속 SLA 조항 확정 | 2026-07-24 | done | 2026-07-23 | 김도입 | — |
| T-102 | 가온합동법률사무소 도입 | env_setup | SSO 연동 설정 | 2026-07-31 | in_progress | 2026-07-28 | 박엔지 | — |
| T-103 | 가온합동법률사무소 도입 | env_setup | 쿠버네티스 네임스페이스 준비와 헬름 배포 | 2026-07-29 | blocked | 2026-07-27 | 박엔지 | 고객 보안팀 방화벽 승인 대기 |
| T-104 | 가온합동법률사무소 도입 | integration | DMS 문서 수집 연동 개발 | — | in_progress | 2026-07-30 | 박엔지 | — |
| T-105 | 가온합동법률사무소 도입 | training | 변호사 대상 슈퍼로이어 교육 1회차 | 2026-08-20 | todo | 2026-07-20 | — | — |
아래 JSON Schema에 맞는 온보딩 작업 행을 25건 더 만들어 주세요. {"type":"object","properties":{"task_id":{"type":"string"},"project":{"type":"string"},"phase":{"type":"string","enum":["contract","env_setup","integration","data_migration","training","golive"]},"task_name":{"type":"string"},"planned_due":{"type":["string","null"]},"status":{"type":"string","enum":["todo","in_progress","blocked","done"]},"status_changed_at":{"type":"string"},"owner":{"type":["string","null"]},"blocked_reason":{"type":["string","null"]}},"required":["task_id","project","phase","task_name","status","status_changed_at"]} 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 planned_due 가 null 이라 기한이 정해지지 않은 행, 둘째 planned_due 가 이미 지났는데 status 가 in_progress 나 todo 인 행, 셋째 status 가 blocked 인데 blocked_reason 이 null 인 행, 넷째 done 인데 status_changed_at 이 planned_due 보다 늦은 행, 다섯째 owner 가 null 인 행, 여섯째 planned_due 가 반년 뒤처럼 극단으로 먼 행. 형식을 깨뜨리는 시도는 3건까지 별도로 만들어 주세요.{"type":"object","properties":{"task_id":{"type":"string"},"project":{"type":"string"},"phase":{"type":"string","enum":["contract","env_setup","integration","data_migration","training","golive"]},"task_name":{"type":"string"},"planned_due":{"type":["string","null"]},"status":{"type":"string","enum":["todo","in_progress","blocked","done"]},"status_changed_at":{"type":"string"},"owner":{"type":["string","null"]},"blocked_reason":{"type":["string","null"]}},"required":["task_id","project","phase","task_name","status","status_changed_at"]}고객 창구로 들어온 메일과 슬랙 메시지와 회의록 더미입니다. CLI가 수신과 회신 시각으로 응답 초과를 판정하고, 회의록 본문은 2주차 결정사항 추출의 입력이 됩니다.
| msg_id | project | channel | received_at | body | replied_at | sla_hours | related_task_raw | related_task_id |
|---|---|---|---|---|---|---|---|---|
| M-001 | 가온합동법률사무소 도입 | 2026-07-20T10:00:00 | SSO 설정에 필요한 인증서 파일을 어제 보내드렸는데 잘 받으셨는지 … | 2026-07-20T15:30:00 | 24 | 싱글사인온 | T-102 | |
| M-002 | 가온합동법률사무소 도입 | 2026-07-27T09:12:00 | 방화벽 승인이 언제 나는지 보안팀에 저희가 다시 문의해야 할까요? | — | 24 | 헬름 배포 | T-103 | |
| M-003 | 가온합동법률사무소 도입 | meeting_note | 2026-07-28T14:00:00 | 주간 회의에서 교육 일정을 논의했습니다. 변호사 교육은 8월 셋째 주… | — | — | — | — |
| M-004 | 누리제강 법무팀 도입 | 2026-07-21T11:00:00 | 계정 발급이 늦어지는 것 같은데 진행 상황을 알려 주세요. | 2026-07-24T09:00:00 | 24 | 계정 발급 | T-202 | |
| M-005 | 누리제강 법무팀 도입 | slack | 2026-07-29T16:40:00 | 저번에 말씀드린 그 건은 어떻게 되고 있나요? | — | 8 | — | — |
아래 JSON Schema에 맞는 고객 메시지 행을 25건 더 만들어 주세요. {"type":"object","properties":{"msg_id":{"type":"string"},"project":{"type":"string"},"channel":{"type":"string","enum":["email","slack","meeting_note"]},"received_at":{"type":"string"},"body":{"type":"string"},"replied_at":{"type":["string","null"]},"sla_hours":{"type":["number","null"]},"related_task_raw":{"type":["string","null"]},"related_task_id":{"type":["string","null"]}},"required":["msg_id","project","channel","received_at","body"]} 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 replied_at 이 null 인 채 sla_hours 가 지난 행, 둘째 sla_hours 가 null 이라 기준 시간이 정해지지 않은 행, 셋째 related_task_raw 가 작업 이름의 별칭이나 사내 용어로 적혀 related_task_id 가 null 인 행, 넷째 related_task_raw 와 related_task_id 가 모두 null 이고 body 도 무엇을 가리키는지 특정되지 않는 행, 다섯째 meeting_note 의 body 에 결정 문장과 잡담이 섞여 들어간 행, 여섯째 회신이 필요 없는 인사 메시지 행. 형식을 깨뜨리는 시도는 3건까지 별도로 만들어 주세요.{"type":"object","properties":{"msg_id":{"type":"string"},"project":{"type":"string"},"channel":{"type":"string","enum":["email","slack","meeting_note"]},"received_at":{"type":"string"},"body":{"type":"string"},"replied_at":{"type":["string","null"]},"sla_hours":{"type":["number","null"]},"related_task_raw":{"type":["string","null"]},"related_task_id":{"type":["string","null"]}},"required":["msg_id","project","channel","received_at","body"]}| Node.js / TypeScript | CLI를 구현하는 주 언어입니다. 판정 결과는 타입으로 고정한 값만 내도록 강제하고, 하위 명령과 옵션 해석도 여기서 처리합니다. |
| Jira | 진행 기록 입력을 Jira 이슈 내보내기 필드 형태로 맞춰, 실제 도입 프로젝트에서는 Jira 에서 받은 파일을 그대로 물릴 수 있게 합니다. |
| Notion | 생성된 주간 보고 Markdown 을 노션에 붙여 넣으면 그대로 고객 공유 문서가 되는 절 구조로 맞춥니다. |
| Slack | 3주차에 post 하위 명령이 변화 요약 텍스트를 프로젝트 채널로 보내 단일 컨택 창구의 공지 흐름을 재현합니다. |
| Github | 판정 규칙과 계획 파일과 생성된 보고 파일을 함께 버전 관리해 계획이 바뀌면 어느 주의 보고가 달라지는지 이력으로 남기고, 판정 규칙 테스트를 CI 로 돌립니다. |
| PostgreSQL | 3주차에 주차별 판정 스냅샷을 저장해 diff 하위 명령의 지난주 대비 변화 계산 입력으로 씁니다. |
| MongoDB | 이 도구의 범위에서는 쓰지 않습니다. 슈퍼로이어 제품 스택이라 진행 기록 더미에 컬렉션 인덱스 점검 같은 실제 구축 작업이 등장하므로, 엔지니어와 그 작업의 지연 사유를 논의할 스택 이해로 둡니다. |
| Redis | 이 도구의 범위에서는 쓰지 않습니다. 진행 기록 더미에 Redis 캐시 구성 점검 같은 작업이 등장하므로, 지연 판정이 엔지니어의 언어로 보고에 실리게 하는 어휘로 씁니다. |
| Kubernetes | 새로 구축하지 않습니다. 슈퍼로이어가 고객 환경에 올라가는 단위가 쿠버네티스라서, 진행 기록 더미의 네임스페이스 준비와 헬름 배포 항목을 실제 구축 어휘 그대로 두어 지연 판정이 엔지니어의 언어로 보고에 실리게 합니다. |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차에서 회의록과 메일의 결정사항과 그 인용을 보고에 붙입니다.
✓ pass → 여기까지도 완결입니다. 더 키우려면 3주차에서 주차별 스냅샷을 쌓아 지난주 대비 변화를 짚고 요약을 Slack 으로 보냅니다.
주간 보고를 이루는 항목 한 건입니다. 어느 규칙이나 어느 원문 인용을 근거로 그 항목이 보고에 실렸는지 담아, 고객이 이유를 물으면 담당자가 바로 근거를 답하게 합니다.
{"type":"object","properties":{"project":{"type":"string"},"section":{"type":"string","enum":["done","delayed","pending_reply","decision","next_week","needs_review"]},"task_id":{"type":["string","null"]},"msg_id":{"type":["string","null"]},"basis":{"type":"string","enum":["rule_due_date","rule_sla_clock","llm_extract"]},"headline":{"type":"string"},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"quote":{"type":"string"}},"required":["field","quote"]}},"needs_human_review":{"type":"boolean"},"hedge":{"type":["string","null"]}},"required":["project","section","basis","headline","evidence","needs_human_review"]}[
{
"project": "누리제강 법무팀 도입",
"section": "delayed",
"task_id": "T-202",
"msg_id": null,
"basis": "rule_due_date",
"headline": "계정 발급과 권한 매핑이 계획 기한을 지나 진행 중입니다",
"evidence": [
{
"field": "task.planned_due",
"quote": "2026-07-24"
},
{
"field": "task.status",
"quote": "in_progress"
}
],
"needs_human_review": false,
"hedge": null
},
{
"project": "가온합동법률사무소 도입",
"section": "pending_reply",
"task_id": "T-103",
"msg_id": "M-002",
"basis": "rule_sla_clock",
"headline": "방화벽 승인 문의에 기준 시간을 지나도록 회신하지 않았습니다",
"evidence": [
{
"field": "message.received_at",
"quote": "2026-07-27T09:12:00"
},
{
"field": "message.sla_hours",
"quote": "24"
}
],
"needs_human_review": false,
"hedge": null
},
{
"project": "가온합동법률사무소 도입",
"section": "decision",
"task_id": "T-105",
"msg_id": "M-003",
"basis": "llm_extract",
"headline": "변호사 교육을 8월 셋째 주부터 격주로 진행하기로 결정했습니다",
"evidence": [
{
"field": "message.body",
"quote": "변호사 교육은 8월 셋째 주부터 격주로 진행하기로 했고"
}
],
"needs_human_review": true,
"hedge": "회의록에 적힌 문장 기준이라 실제 합의 범위는 담당자가 확인해야 합니다."
},
{
"project": "가온합동법률사무소 도입",
"section": "done",
"task_id": "T-101",
"msg_id": null,
"basis": "rule_due_date",
"headline": "계약 부속 SLA 조항 확정이 기한 안에 끝났습니다",
"evidence": [
{
"field": "task.planned_due",
"quote": "2026-07-24"
},
{
"field": "task.status_changed_at",
"quote": "2026-07-23"
}
],
"needs_human_review": false,
"hedge": null
}
][자동 검증] 1. 항목 JSON 이 위 스키마를 통과하는지 확인합니다. section 이 정해진 여섯 값 밖이면 그 항목을 버립니다. 2. basis 가 rule_due_date 나 rule_sla_clock 인 항목은 evidence 의 quote 가 입력 데이터의 실제 필드 값과 일치하는지 대조합니다. 날짜 계산 판정에 지어낸 근거가 붙으면 보고 전체를 신뢰할 수 없기 때문입니다. 3. basis 가 llm_extract 인 항목은 quote 가 원문 body 에 실재하는 문자열인지 대조하고, 실재하지 않으면 needs_review 절로 돌립니다. 환각 인용이 고객 보고에 실리는 것을 여기서 막습니다. 4. basis 가 llm_extract 인 항목은 needs_human_review 가 true 인지 확인합니다. 결정사항은 사람이 최종 확인해야 고객에게 나갑니다. 5. task_id 와 msg_id 가 null 이 아니면 입력 데이터에 실재하는 식별자인지 확인합니다. 없는 식별자는 지어낸 것으로 보고 버립니다. 6. 같은 입력과 같은 기준일에서 두 번 실행한 보고 파일이 문자 그대로 같은지 비교합니다. 결정론이 깨지면 규칙에 시각 의존 버그가 들어간 것입니다. [수동 검증] 1. 생성된 보고 한 부를 도입 담당자 관점에서 읽고, 고객에게 그대로 보내도 되는 문장인지 봅니다. 2. 지연 판정 항목의 사유가 실제 진행 기록과 맞는지 원본 데이터와 대조합니다. 3. 회신이 필요 없는 인사 메시지가 응답 초과로 잡히지 않았는지 봅니다. 잡혔다면 규칙의 과탐 사례로 기록하고 다듬습니다.