로앤FDE팀 Frontend Engineer (3년 이상)
3.0 (84)로앤컴퍼니
경력근거: 계약 전 단계에서 UI 요구 구체화 및 실현가능성 검토
13일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
로앤컴퍼니 FDE팀은 영업이 성숙해 계약을 앞둔 시점부터 결합해 고객 요구를 딜리버리로 잇는다고 공고에 적었습니다. 그 시점에 답해야 하는 질문이 '이 명세가 커스터마이징 범위 안이냐'인데, 슈퍼로이어처럼 로펌마다 문서 화면이 다른 제품에서는 그 답이 항목 단위로 갈립니다. 이 도구는 그 판정을 목록으로 관리합니다. 공고 업무는 커스터마이징 개발부터 피드백 반영까지 걸쳐 있는데 1주 범위에서 계약 전 범위 판정 축을 골랐습니다. 이 포트폴리오는 명세를 제품 범위표와 대조해 가려내고 화면을 설정으로 그리는 기술을 보여줍니다. 법률 실무나 로펌 업무 흐름의 전문성은 주장하지 않습니다. 그 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
주요 업무 마지막 줄이 계약 전 단계의 UI 요구 구체화와 실현가능성 검토입니다. 고객이 건넨 명세 한 줄씩이 제품의 커스터마이징 범위 안인지 밖인지 가려내는 것이 그 검토의 실물입니다.
PoC와 데모 프로토타입 신속 제작이 영업 지원 업무로 적혀 있습니다. 명세를 설정으로 받아 화면을 즉시 그려 보이면 데모를 매번 새로 만들지 않아도 됩니다.
개발 환경이 React와 TypeScript이고 REST API 연동과 상태 관리를 요구합니다. 화면 구성을 설정 값으로 두면 고객이 바뀌어도 같은 코드로 다른 화면이 나옵니다.
고객이 계약 전에 건넨 명세를 제품의 커스터마이징 범위표와 대조해, 설정으로 되는 항목과 범위를 넘어 개발이 필요한 항목을 나눠 보여주는 관리자 페이지입니다. 범위 안 항목은 바뀐 화면을 미리보기로 그립니다.
계약을 앞둔 고객사에서 명세를 받아 오는 담당자입니다. 로펌마다 '이 항목은 빼고 저 라벨은 바꿔 달라'는 명세가 스무 줄씩 오는데, 어디까지가 설정으로 되는 커스터마이징 범위이고 어디부터 개발이 필요한지를 매번 개발팀에 물어보고 답을 기다립니다.
제품이 설정으로 지원하는 커스터마이징 범위가 목록으로 적혀 있으면, 명세 한 줄이 그 범위 안인지 밖인지는 그 자리에서 갈라집니다.
고객 명세 목록과 제품 커스터마이징 범위표를 올리면 사유별로 나눠 보여주고, 범위 안 항목은 바뀐 화면을 미리보기로 그리는 관리자 페이지입니다. 실제 제품 코드에는 붙지 않고 범위표에 적힌 항목만 그립니다.
고객이 엑셀이나 문서로 보낸 명세서를 읽어 같은 판정을 돌리는 변환기입니다.
개발이 필요한 명세 항목을 모아 화면별로 묶고 확인 질문을 붙인 검토 문서 생성기입니다.
명세 20건과 범위표를 올려 사유별로 갈라진 화면이 나오고, 범위 안 항목의 미리보기가 그려지는 것을 시연합니다.
결측·중복·범위표에 없는 항목이 섞인 입력 30종을 넣어도 화면 형식이 깨지지 않고, 판정하지 못한 명세는 사유가 붙어 남습니다.
범위표에 없는 항목은 범위 안이라고 단정하지 않고 항목 미상으로 남깁니다. 계약 전에 되는 것처럼 답하지 않습니다.
판정과 개발팀이 표시한 정답표를 맞춰 사유별로 어긋난 건을 셉니다. 단, 명세와 정답을 모두 작성자가 만든 합성 기준이라 성능 측정이 아니라 데모 조건 동작입니다.
진짜 성능 확인은 여기서 멈춥니다. 위 수치는 더미데이터 자가채점이며, 실제 판정 정확도는 슈퍼로이어의 실제 커스터마이징 범위와 실제 고객 명세서가 있어야 측정됩니다. 이 포트폴리오는 그 측정을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실측 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 결측·중복·범위표에 없는 항목을 더미에 일부러 섞어 쉬운 문제만 푸는 것을 피합니다.
범위 안이라고 해서 공수가 없다고 단정할 수 없습니다. 항목이 많아지면 화면 확인이 따로 필요하므로, 이 도구는 범위 안팎만 답하고 일정 판단은 사람이 합니다.
실제 도입하면 제품 범위표를 최신으로 유지하는 일이 남습니다. 범위표가 낡으면 판정이 통째로 틀리므로, 그 갱신 절차를 정하는 것이 도입 단계의 실제 과제입니다.
미리보기는 범위표에 적힌 항목만 그립니다. 실제 제품 화면과 픽셀 단위로 같지 않으므로 고객에게 보일 때 그 점을 함께 말해야 합니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
계약을 앞둔 고객사가 건넨 명세 목록입니다. 화면과 항목마다 무엇을 어떻게 바꿔 달라고 적었는지가 한 줄씩 들어 있습니다. 같은 항목을 두 번 적은 중복과 항목 이름을 다르게 쓴 흔들림을 일부러 섞었습니다.
| spec_no | client_no | target_screen | change_type | target_field_raw | target_field_id | new_label | priority |
|---|---|---|---|---|---|---|---|
| R-001 | CL-01 | document_list | hide_field | 작성자 | author | — | 1 |
| R-002 | CL-01 | document_list | relabel | 사건번호 | case_no | 사건 관리번호 | 1 |
| R-003 | CL-01 | document_list | reorder | 등록일 | created_at | — | 2 |
| R-004 | CL-01 | document_detail | add_field | 의뢰인 등급 | — | 의뢰인 등급 | 3 |
| R-005 | CL-02 | document_list | hide_field | 작성자명 | author | — | 1 |
아래 JSON Schema에 맞는 고객 명세 줄을 더 만들어 주세요. {"type":"object","properties":{"spec_no":{"type":"string"},"client_no":{"type":"string"},"target_screen":{"type":"string"},"change_type":{"type":"string","enum":["hide_field","relabel","reorder","add_field","new_view"]},"target_field_raw":{"type":"string"},"target_field_id":{"type":["string","null"]},"new_label":{"type":["string","null"]},"priority":{"type":"integer"}},"required":["spec_no","client_no","target_screen","change_type","target_field_raw","target_field_id","new_label","priority"]} 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 미매핑으로 target_field_raw가 범위표에 없어 target_field_id가 null인 행, 둘째 표기흔들림으로 같은 항목을 작성자와 작성자명처럼 다르게 적은 행, 셋째 중복으로 같은 spec_no가 두 행에 있는 재제출 건, 넷째 충돌로 같은 고객이 같은 항목을 숨기라고도 하고 라벨을 바꾸라고도 적은 명세 쌍, 다섯째 결측으로 relabel인데 new_label이 null인 행. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 change_type에 enum 밖 값을 넣어 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"spec_no":{"type":"string"},"client_no":{"type":"string"},"target_screen":{"type":"string"},"change_type":{"type":"string","enum":["hide_field","relabel","reorder","add_field","new_view"]},"target_field_raw":{"type":"string"},"target_field_id":{"type":["string","null"]},"new_label":{"type":["string","null"]},"priority":{"type":"integer"}},"required":["spec_no","client_no","target_screen","change_type","target_field_raw","target_field_id","new_label","priority"]}제품이 설정으로 지원하는 커스터마이징 범위표입니다. 화면과 항목마다 어떤 변경이 범위 안인지가 적혀 있습니다.
| screen | field_id | field_label_default | can_hide | can_relabel | can_reorder |
|---|---|---|---|---|---|
| document_list | author | 작성자 | true | true | true |
| document_list | case_no | 사건번호 | false | true | true |
| document_list | created_at | 등록일 | true | true | true |
| document_list | security_level | 보안등급 | false | false | false |
| document_list | summary | 요약 | true | true | true |
아래 JSON Schema에 맞는 제품 커스터마이징 범위표 행을 더 만들어 주세요. {"type":"object","properties":{"screen":{"type":"string"},"field_id":{"type":"string"},"field_label_default":{"type":"string"},"can_hide":{"type":"boolean"},"can_relabel":{"type":"boolean"},"can_reorder":{"type":"boolean"}},"required":["screen","field_id","field_label_default","can_hide","can_relabel","can_reorder"]} 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라. 첫째 경계극단으로 세 가지 변경이 모두 불가한 항목(보안·감사 관련), 둘째 같은 field_id가 화면마다 다른 지원 범위를 갖는 행 쌍. 또한 형식 깨뜨리기 시도 3건을 별도 파일로 만들어 can_hide에 문자열을 넣어 스키마 검증이 걸러내는지 확인하게 해 주세요.{"type":"object","properties":{"screen":{"type":"string"},"field_id":{"type":"string"},"field_label_default":{"type":"string"},"can_hide":{"type":"boolean"},"can_relabel":{"type":"boolean"},"can_reorder":{"type":"boolean"}},"required":["screen","field_id","field_label_default","can_hide","can_relabel","can_reorder"]}| React | 판정 결과와 화면 미리보기를 그리는 관리자 페이지입니다. |
| TypeScript | 명세와 범위표의 형태를 타입으로 고정해 잘못된 조합이 화면까지 가지 않게 막습니다. |
| REST API | 명세 목록과 범위표를 주고받는 경로이며, 1주차에는 올린 파일을 그대로 씁니다. |
| 상태 관리 | 명세를 사유별로 나눠 둔 목록과 선택한 항목의 미리보기를 함께 유지합니다. |
| Kubernetes | 3주차에 검토 문서 생성기를 컨테이너로 묶어 사내에서 같은 방식으로 돌릴 때 씁니다. |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 고객이 보낸 명세서 원본을 그대로 읽습니다.
✓ pass → 명세서 변환까지가 한 덩어리입니다. 더 키우려면 범위를 넘는 명세를 개발 검토 문서로 넘깁니다.
위 예측 UI 는 3주차까지 완주했을 때의 화면입니다. 1주차에 실제로 만드는 것은 아래 표시된 화면 하나입니다.
verdict사유 라벨 · spec_no + 한 줄 요약(근거 수치 포함)화면·코드·면접에서 이 단어를 그대로 씁니다. 키는 출력 스키마의 enum 과 같습니다.
in_scope범위 안field_unknown항목 미상out_of_scope범위 밖spec_conflict명세 충돌duplicate_spec중복 명세명세 한 줄의 판정 결과입니다. 커스터마이징 범위 안인지, 범위를 넘으면 무엇 때문인지를 근거와 함께 담습니다.
{"type":"object","properties":{"spec_no":{"type":"string"},"verdict":{"type":"string","enum":["in_scope","field_unknown","out_of_scope","spec_conflict","duplicate_spec"]},"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":["spec_no","verdict","evidence","next_action"]}[
{
"spec_no": "R-001",
"verdict": "in_scope",
"evidence": [
{
"field": "change_type",
"value": "hide_field"
},
{
"field": "target_field_id",
"value": "author"
},
{
"field": "can_hide",
"value": true
}
],
"next_action": "설정으로 바로 되는 범위입니다. 미리보기를 고객에게 보이고 계약 범위에 넣습니다."
},
{
"spec_no": "R-002",
"verdict": "in_scope",
"evidence": [
{
"field": "change_type",
"value": "relabel"
},
{
"field": "target_field_id",
"value": "case_no"
},
{
"field": "can_relabel",
"value": true
}
],
"next_action": "라벨 변경은 범위 안입니다. 미리보기를 고객에게 보입니다."
},
{
"spec_no": "R-011",
"verdict": "in_scope",
"evidence": [
{
"field": "change_type",
"value": "relabel"
},
{
"field": "target_field_id",
"value": "attachments"
},
{
"field": "can_relabel",
"value": true
}
],
"next_action": "라벨 변경은 범위 안입니다. 미리보기를 고객에게 보입니다."
},
{
"spec_no": "R-004",
"verdict": "field_unknown",
"evidence": [
{
"field": "target_field_raw",
"value": "의뢰인 등급",
"quote": "의뢰인 등급"
},
{
"field": "target_field_id",
"value": null
}
],
"next_action": "범위표에 없는 항목입니다. 제품에 있는 항목인지 개발팀에 먼저 확인합니다."
},
{
"spec_no": "R-009",
"verdict": "out_of_scope",
"evidence": [
{
"field": "change_type",
"value": "hide_field"
},
{
"field": "target_field_id",
"value": "security_level"
},
{
"field": "can_hide",
"value": false
}
],
"next_action": "보안등급은 숨기는 설정이 없어 범위 밖입니다. 감사 추적과 엮여 있어 계약 전에 대안을 합의합니다."
},
{
"spec_no": "R-006",
"verdict": "spec_conflict",
"evidence": [
{
"field": "target_field_id",
"value": "author"
},
{
"field": "change_type",
"value": "relabel"
},
{
"field": "spec_no",
"agg": "count",
"value": 2
}
],
"next_action": "같은 고객이 같은 항목을 숨기라고도 하고 라벨을 바꾸라고도 적었습니다. 어느 쪽인지 되묻습니다."
},
{
"spec_no": "R-005",
"verdict": "duplicate_spec",
"evidence": [
{
"field": "spec_no",
"agg": "count",
"value": 2
}
],
"next_action": "같은 명세 번호가 두 번 올라왔습니다. 앞 줄로만 판정하고 목록에서 뒤 줄을 뺍니다."
},
{
"spec_no": "R-007",
"verdict": "out_of_scope",
"evidence": [
{
"field": "change_type",
"value": "new_view"
},
{
"field": "target_field_raw",
"value": "판례 비교 화면",
"quote": "판례 비교 화면"
},
{
"field": "target_field_id",
"value": null
}
],
"next_action": "범위표에 없는 화면을 새로 만드는 명세라 설정 범위 밖입니다. 개발 검토 문서로 넘깁니다."
}
][자동 검증 · 1주차] 1. verdict가 enum 다섯 값 안에 있는지 확인합니다. 2. spec_no·verdict·evidence·next_action이 모두 있는지 확인합니다. 3. change_type이 new_view이면 verdict가 out_of_scope인지 확인합니다. 범위표에 없는 화면을 새로 만드는 명세라 설정으로 되지 않습니다. 4. change_type이 new_view가 아니고 target_field_id가 null이면 verdict가 field_unknown인지 확인합니다. 5. verdict가 in_scope이면 명세가 적은 변경에 해당하는 범위표 허용 값이 참인지 확인합니다. 6. verdict가 out_of_scope이고 target_field_id가 있으면 그 항목의 허용 값이 거짓인지 확인합니다. 7. evidence의 field가 두 입력 표의 컬럼에 실재하는지 확인합니다. 8. evidence의 quote가 그 줄 target_field_raw의 일부인지 확인합니다. 9. next_action이 존댓말로 끝나는지 확인합니다. [수동 검증] 1. 범위 밖이라고 판정한 명세에 대안이 실제로 있는지 개발팀이 확인합니다. 2. R-003·R-010처럼 순서 변경이 범위 안인 명세는 사유를 달지 않는 것이 맞는지 확인합니다. [평가 러너 · 2주차] 1. 개발팀이 표시한 정답표와 verdict를 맞춰 사유별로 어긋난 건을 셉니다. 2. 명세와 정답을 작성자가 만든 합성 기준이라 이 수치는 성능 측정이 아니라 데모 조건 동작입니다.