제논풀스택_FDE(Forward Deployed Engineer)
2.4 (5)제논
경력근거: 외부 API, 서비스 연동 기능 개발 및 유지보수
어제 확인채용 공고 보기
공고가 자격요건에 '불완전한 요구사항을 명확한 스펙(입력, 출력, 오류, 상태, 성능, 보안)으로 정리하고, 팀 및 이해관계자와 합의할 수 있는 커뮤니케이션 역량' 을 적었고, 주요 업무에는 '외부 서비스 및 고객사 환경과의 연동 요구를 정리하고' 가 나란히 있습니다. 문장으로 오는 요구를 여섯 항목으로 옮기는 일이 이 포지션의 자리이고, 이 포트폴리오는 그 옮김을 규칙표와 판정으로 만듭니다. 'AI가 만든 결과물을 검증하고 개선할 수 있는 역량' 을 앞세운 대목도 같은 지점을 가리켜, 판정은 규칙이 맡고 모델은 사유 문장만 씁니다. 이 포트폴리오가 보여주는 것은 요구 문장을 슬롯 규칙과 맞춰 확정 여부를 가르는 기술이며, Kubernetes 운영 경험이나 고객사 도메인 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
'불완전한 요구사항을 명확한 스펙(입력, 출력, 오류, 상태, 성능, 보안)으로 정리'. 여섯 항목이 그대로 판정 축입니다.
'외부 API, 서비스 연동 기능 개발 및 유지보수'. 연동에서 받는 자료가 문장입니다.
'테스트 코드 작성과 코드 리뷰를 통한 소스코드 품질 관리'. 판정은 규칙이 맡고 모델은 문장만 씁니다.
연동 요구 문장이 스펙으로 확정됐는지 가릅니다. 입력·출력·오류·상태·성능·보안 여섯 슬롯의 확정 규칙을 표로 두고 요구 문장을 맞춰, 확정된 줄은 정규화한 값을 붙이고 확정되지 않은 줄은 단위 누락·값 모호·값 충돌 중 어느 쪽인지 사유로 남깁니다. 본문이 비어 있는 줄은 슬롯에 걸지 않고 원본을 다시 받게 하며, 항목 열의 화제어가 슬롯 규칙표에 없는 줄은 미매핑으로 남겨 규칙을 먼저 늘리게 합니다. 요구 문장은 실 고객사 문서 대신 지원자가 공개 API 연동 안내와 이슈 본문에서 뽑아 만든 것을 가정합니다.
고객사 IT 담당과 현업이 각자 쓴 연동 요구 문장을 모아 스펙으로 옮기는 자리에 앉는 FDE 입니다. 어느 줄이 이미 스펙이고 어느 줄이 아직 물어봐야 할 말인지를 매번 문서를 처음부터 읽어 가려내던 사람입니다.
슬롯마다 무엇이 적혀 있어야 확정인지를 규칙표로 두고 요구 문장과 맞추면, 확정과 미확정이 규칙으로 정해지고 미확정 줄마다 무엇이 빠졌는지가 근거로 남는다는 가정입니다. 규칙에 없는 문장은 미매핑으로 빠지므로 아직 슬롯이 없는 요구가 그대로 드러납니다.
요구 문장과 슬롯 규칙표를 받아 슬롯마다 확정·미확정을 판정하고, 미확정이면 단위 누락·값 모호·값 충돌 중 어느 쪽인지 붙여 슬롯별로 묶은 판정 리포트를 터미널과 Markdown 파일로 내는 CLI 가 도는 완결품입니다.
공개 연동 안내에서 뽑은 요구 문장 60줄에 손으로 붙인 정답 판정과 대조해 일치율을 내고, 미매핑이 몰리는 문장 유형을 모아 슬롯 규칙이 없는 구간을 목록으로 냅니다.
확정된 슬롯을 모아 입력·출력·오류·상태·성능·보안 여섯 항목의 테스트 기준 초안을 조립하고, 미확정 줄은 물어볼 질문 목록으로 갈라 내는 단계입니다.
FDE 가 요구 문장과 슬롯 규칙표를 넣으면 슬롯마다 확정·미확정과 빠진 항목이 묶여 나오는 과정을 시연합니다.
공개 연동 안내에서 뽑은 요구 문장 60줄과 손으로 붙인 정답 판정을 대조해 일치율을 냅니다. 단, 정답과 요구 문장을 모두 작성자가 고른 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
본문이 비었거나 단위 표기가 흔들리거나 규칙에 없는 문장이 섞인 입력 30종을 넣어도 출력 형식이 안 깨지고 사유별로 빠지는 비율을 보여줍니다.
슬롯 규칙을 고쳤을 때 옛 판정이 어떻게 뒤집히는지 회귀로 확인합니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 작성자가 고른 문장의 자가채점이며, 실제 스펙 확정 판단은 제논 고객사의 실 요구 문서와 실 합의 기준이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아니므로, 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 붙였으니 잘 맞는 게 당연하므로, 단위 누락과 값 충돌을 일부러 섞어 쉬운 문장만 푸는 함정을 피합니다.
이 포트폴리오가 보여주는 것은 요구 문장을 슬롯 규칙과 맞춰 확정 여부를 가르는 기술이며, Kubernetes 운영 경험이나 고객사 도메인 전문성은 주장하지 않습니다. 판정은 규칙 대조가 하고 LLM 은 담당자가 읽을 사유 문장만 맡습니다.
규칙이 확정이라 판정해도 고객이 뜻한 바와 다를 수 있어서, 판정에 원문을 함께 실어 담당자가 한 번 더 읽게 둡니다.
실제 도입 때는 고객사마다 쓰는 말과 합의 절차가 다르므로, 슬롯 규칙표를 새로 채우는 일을 도입 단계 과제로 둡니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사가 보낸 연동 요구 문서에서 한 줄씩 뽑은 원문입니다. 문서와 항목 열에 적힌 화제어 원문, 쓴 사람, 받은 날짜를 함께 둡니다. 화제어는 고객사 담당이 손으로 적어 같은 화제가 '응답 속도'와 '응답속도'처럼 흔들립니다. 단위 표기가 흔들리는 줄(2s·5초·수치만), 수치가 아예 없는 줄, 본문이 비어 있는 줄, 담당자 이름이 비어 있는 줄, 슬롯 규칙표에 없는 화제어를 단 줄을 일부러 섞어 두어 사유가 갈리게 둡니다.
| line_no | source_doc | topic_raw | raw_text | author_role | assignee_name | received_at |
|---|---|---|---|---|---|---|
| RQ-1001 | 연동요구정리_A | 인증 방식 | 인증은 사내 SSO 를 거친 토큰만 받습니다. | 고객사 IT 담당 | 김세연 | 2026-08-03 |
| RQ-1002 | 연동요구정리_A | 입력 파일 | 주문 원장은 CSV 로 하루 한 번 올립니다. | 고객사 현업 | 박도윤 | 2026-08-03 |
| RQ-1003 | 연동요구정리_A | 응답 속도 | 조회 응답은 p95 기준 2s 이하로 부탁드립니다. | 고객사 IT 담당 | 김세연 | 2026-08-04 |
| RQ-1004 | 연동요구정리_A | 출력 형식 | 결과는 JSON 으로 내려주세요. | 고객사 IT 담당 | 김세연 | 2026-08-04 |
| RQ-1005 | 연동요구정리_B | 오류 처리 | 연동이 끊기면 알아서 다시 붙어야 합니다. | 고객사 현업 | — | 2026-08-05 |
아래 JSON Schema 를 그대로 만족하는 요구 문장 행을 60개 더 만들어 주세요. 화제어는 여섯 슬롯을 고루 섞되 같은 화제를 '응답 속도'와 '응답속도'처럼 띄어쓰기를 흔들어 적습니다. 2할은 수치가 없거나 단위가 빠지게 하고, 한두 줄은 본문과 담당자를 비우며, 몇 줄은 슬롯 규칙표에 없는 화제어를 답니다. 확정 여부나 빠진 항목은 넣지 마세요.
{"type": "object", "properties": {"line_no": {"type": "string"}, "source_doc": {"type": "string"}, "topic_raw": {"type": "string"}, "raw_text": {"type": ["string", "null"]}, "author_role": {"type": "string"}, "assignee_name": {"type": ["string", "null"]}, "received_at": {"type": "string"}}, "required": ["line_no", "source_doc", "topic_raw", "raw_text", "received_at"]}{"type": "object", "properties": {"line_no": {"type": "string"}, "source_doc": {"type": "string"}, "topic_raw": {"type": "string"}, "raw_text": {"type": ["string", "null"]}, "author_role": {"type": "string"}, "assignee_name": {"type": ["string", "null"]}, "received_at": {"type": "string"}}, "required": ["line_no", "source_doc", "topic_raw", "raw_text", "received_at"]}슬롯별 확정 규칙표입니다. 슬롯 이름과 그 슬롯이 받는 화제어 표준 표기, 확정에 필요한 근거 종류, 차단 여부, 담당을 한 행에 둡니다. 차단 규칙과 권장 규칙을 섞어 두어 미확정이 곧 중단인지 아닌지가 갈립니다. 요구 문장에 나오는 화제어 중 일정 조율처럼 슬롯이 없는 것은 일부러 넣지 않아 미매핑이 도출되게 둡니다.
| slot_no | slot_name | topic_raw | requirement | evidence_kind | blocking | owner |
|---|---|---|---|---|---|---|
| SL-1001 | 입력 형식 | 입력 파일 | 받는 파일이나 호출의 형식과 주기가 적혀 있어야 합니다. | keyword | true | 연동 담당 |
| SL-1002 | 입력 형식 | 입력 파일 | 보내는 쪽과 받는 쪽이 지목돼야 합니다. | keyword | false | 연동 담당 |
| SL-1003 | 출력 형식 | 출력 형식 | 돌려주는 형식이 적혀 있어야 합니다. | keyword | true | 연동 담당 |
| SL-1004 | 출력 형식 | 출력 형식 | 필드 이름이 하나라도 지목돼야 합니다. | keyword | false | 연동 담당 |
| SL-1005 | 오류 처리 | 오류 처리 | 실패했을 때 남길 것이 적혀 있어야 합니다. | keyword | true | 백엔드 |
아래 JSON Schema 를 그대로 만족하는 슬롯 규칙 행을 30개 더 만들어 주세요. 슬롯마다 차단 규칙과 권장 규칙을 섞고 근거 종류를 세 값으로 고루 씁니다. 요구 문장에 나오는 화제어 중 일부는 일부러 넣지 마세요 — 미매핑이 있어야 규칙의 구멍이 드러납니다.
{"type": "object", "properties": {"slot_no": {"type": "string"}, "slot_name": {"type": "string"}, "topic_raw": {"type": "string"}, "requirement": {"type": "string"}, "evidence_kind": {"type": "string", "enum": ["keyword", "enum_value", "number_with_unit"]}, "blocking": {"type": "boolean"}, "owner": {"type": "string"}}, "required": ["slot_no", "slot_name", "topic_raw", "requirement", "evidence_kind", "blocking"]}{"type": "object", "properties": {"slot_no": {"type": "string"}, "slot_name": {"type": "string"}, "topic_raw": {"type": "string"}, "requirement": {"type": "string"}, "evidence_kind": {"type": "string", "enum": ["keyword", "enum_value", "number_with_unit"]}, "blocking": {"type": "boolean"}, "owner": {"type": "string"}}, "required": ["slot_no", "slot_name", "topic_raw", "requirement", "evidence_kind", "blocking"]}| Python | 요구 문장을 슬롯 규칙과 맞춰 확정·미확정을 정하는 판정기를 맡습니다. |
| pytest | 규칙을 고쳤을 때 옛 판정이 어떻게 뒤집히는지 회귀로 잡습니다. |
| Markdown | 슬롯별로 묶은 판정 리포트와 물어볼 질문 목록을 파일로 냅니다. |
✗ fail → 미매핑이 절반을 넘으면 슬롯 규칙을 먼저 늘립니다.
✓ pass → 2주차 정답 대조로 넘어갑니다.
✗ fail → 어긋난 유형을 모아 근거 종류 정의를 다시 봅니다.
✓ pass → 3주차 테스트 기준 초안으로 넘어갑니다.
요구 문장 한 줄과 슬롯 규칙 한 행이 만나는 자리마다 확정·미확정을 정합니다. 미확정이면 단위 누락·값 모호·값 충돌 중 어느 쪽인지 싣고, 본문이 비면 슬롯에 걸지 않고 따로 뺍니다. 화면과 리포트는 이 사유 코드로 묶습니다.
{"type": "object", "properties": {"verdict_no": {"type": "string"}, "line_no": {"type": "string"}, "slot_no": {"type": ["string", "null"]}, "slot_name": {"type": ["string", "null"]}, "spec_code": {"type": "string", "enum": ["confirmed", "unit_missing", "value_ambiguous", "value_conflicting", "text_missing", "slot_unmapped"]}, "normalized_value": {"type": ["string", "null"]}, "blocking": {"type": ["boolean", "null"]}, "owner": {"type": ["string", "null"]}, "evidence": {"type": "array", "items": {"type": "object", "properties": {"field": {"type": "string"}, "agg": {"type": ["string", "null"]}, "value": {}}, "required": ["field", "value"]}}, "summary": {"type": "string"}, "hedge": {"type": ["string", "null"]}, "topic_raw": {"type": "string"}}, "required": ["verdict_no", "line_no", "topic_raw", "spec_code", "evidence", "summary"]}[
{
"verdict_no": "SV-001",
"line_no": "RQ-1003",
"topic_raw": "응답 속도",
"slot_no": "SL-1009",
"slot_name": "성능 목표",
"spec_code": "confirmed",
"normalized_value": "2000ms",
"blocking": true,
"owner": "플랫폼",
"evidence": [
{
"field": "raw_text",
"agg": null,
"value": "조회 응답은 p95 기준 2s 이하로 부탁드립니다."
},
{
"field": "evidence_kind",
"agg": null,
"value": "number_with_unit"
}
],
"summary": "지연 목표가 2s 로 적혀 있어 2000ms 로 읽었고 성능 슬롯이 확정됐습니다.",
"hedge": null
},
{
"verdict_no": "SV-002",
"line_no": "RQ-1001",
"topic_raw": "인증 방식",
"slot_no": "SL-1011",
"slot_name": "보안 요건",
"spec_code": "confirmed",
"normalized_value": "sso_token",
"blocking": true,
"owner": "보안 담당",
"evidence": [
{
"field": "raw_text",
"agg": null,
"value": "인증은 사내 SSO 를 거친 토큰만 받습니다."
},
{
"field": "requirement",
"agg": null,
"value": "인증 방식이 지목돼야 합니다."
}
],
"summary": "인증 방식이 사내 SSO 토큰으로 지목돼 보안 슬롯이 확정됐습니다.",
"hedge": null
},
{
"verdict_no": "SV-003",
"line_no": "RQ-1006",
"topic_raw": "응답속도",
"slot_no": "SL-1009",
"slot_name": "성능 목표",
"spec_code": "unit_missing",
"normalized_value": null,
"blocking": true,
"owner": "플랫폼",
"evidence": [
{
"field": "raw_text",
"agg": null,
"value": "응답은 2 이내였으면 합니다."
},
{
"field": "evidence_kind",
"agg": null,
"value": "number_with_unit"
}
],
"summary": "수치 2 는 있으나 단위가 없어 초인지 분인지 정해지지 않았습니다.",
"hedge": "단위를 물어 확정하기 전에는 이 줄을 성능 목표로 쓰지 않습니다."
},
{
"verdict_no": "SV-004",
"line_no": "RQ-1010",
"topic_raw": "응답 속도",
"slot_no": "SL-1009",
"slot_name": "성능 목표",
"spec_code": "value_ambiguous",
"normalized_value": null,
"blocking": true,
"owner": "플랫폼",
"evidence": [
{
"field": "raw_text",
"agg": null,
"value": "가능한 한 빠르게 처리되면 좋겠습니다."
},
{
"field": "evidence_kind",
"agg": null,
"value": "number_with_unit"
}
],
"summary": "빠르게라는 말만 있고 수치가 없어 성능 목표가 서지 않습니다.",
"hedge": null
},
{
"verdict_no": "SV-005",
"line_no": "RQ-1007",
"topic_raw": "응답 속도",
"slot_no": "SL-1009",
"slot_name": "성능 목표",
"spec_code": "value_conflicting",
"normalized_value": "5000ms",
"blocking": true,
"owner": "플랫폼",
"evidence": [
{
"field": "raw_text",
"agg": null,
"value": "조회 응답은 5초 안에 오면 됩니다."
},
{
"field": "line_no",
"agg": "count",
"value": 2
}
],
"summary": "같은 성능 슬롯에 2s 와 5초 두 값이 들어와 어느 쪽이 목표인지 갈립니다.",
"hedge": "두 문장을 쓴 담당이 달라 회의에서 한쪽으로 정해야 합니다."
},
{
"verdict_no": "SV-006",
"line_no": "RQ-1011",
"topic_raw": "출력 형식",
"slot_no": null,
"slot_name": null,
"spec_code": "text_missing",
"normalized_value": null,
"blocking": null,
"owner": null,
"evidence": [
{
"field": "raw_text",
"agg": null,
"value": null
},
{
"field": "assignee_name",
"agg": null,
"value": null
}
],
"summary": "본문과 담당자 이름이 모두 비어 있어 어느 슬롯에도 걸지 않고 원본을 다시 받습니다.",
"hedge": null
},
{
"verdict_no": "SV-007",
"line_no": "RQ-1012",
"topic_raw": "회의 일정",
"slot_no": null,
"slot_name": null,
"spec_code": "slot_unmapped",
"normalized_value": null,
"blocking": null,
"owner": null,
"evidence": [
{
"field": "topic_raw",
"agg": null,
"value": "회의 일정"
},
{
"field": "slot_no",
"agg": "count",
"value": 12
}
],
"summary": "화제어 회의 일정이 슬롯 규칙 열두 행 어디에도 없어 미매핑으로 남깁니다.",
"hedge": null
}
][자동 검증 · 코드가 판정합니다] 1. spec_code 가 enum 여섯 값 중 하나인지 확인합니다. 2. verdict_no·line_no·spec_code·evidence·summary 가 모두 채워졌는지 확인합니다. 3. line_no 가 요구 문장 원문에 실재하는 줄 번호인지 대조합니다. 4. slot_no 가 있으면 슬롯 규칙표에 실재하는 행 번호인지 대조합니다. 5. slot_no 가 있으면 slot_name·blocking·owner 가 그 규칙 행의 값과 같은지 대조합니다. 6. spec_code 가 confirmed 이면 그 슬롯이 요구하는 근거 종류가 원문에 실제로 있는지 다시 뽑아 확인합니다. 7. spec_code 가 unit_missing 이면 원문에 수치는 있고 단위가 없는지 다시 확인합니다. 8. spec_code 가 value_ambiguous 이면 원문에 수치가 없는지 다시 확인합니다. 9. spec_code 가 value_conflicting 이면 같은 슬롯에 서로 다른 정규화 값이 둘 이상인지 다시 셉니다. 10. raw_text 가 비어 있으면 spec_code 가 text_missing 인지 확인합니다. 10-1. topic_raw 를 공백·기호를 지워 접은 뒤 슬롯 규칙표의 화제어와 맞고, 맞는 행이 없으면 spec_code 가 slot_unmapped 인지 확인합니다. 11. normalized_value 가 있으면 단위 사전대로 원문에서 다시 환산되는지 확인합니다. 12. evidence 의 field 이름이 요구 문장 원문과 슬롯 규칙표에 실재하는 컬럼인지 대조합니다. 13. agg 가 없는 evidence 의 value 가 그 컬럼에 수록된 행 값과 같은지 확인합니다. 14. summary 가 존댓말로 끝나는지 확인합니다. [평가 러너 · 2주차] 공개 연동 안내에서 뽑은 요구 문장 60줄에 손으로 붙인 정답 판정과 대조해 일치율과 사유 코드별 분포를 내고, 미매핑이 몰리는 문장 유형을 모아 슬롯 규칙이 없는 구간을 목록으로 냅니다. [수동 검증 · 사람이 봅니다] 1. 값이 충돌한 슬롯을 어느 쪽으로 정할지 담당자가 회의에서 정합니다. 2. 규칙이 확정이라 본 줄이 고객이 뜻한 바와 같은지 담당자가 원문을 읽어 확인합니다.