조코FDE (고객사 서비스 구축 · 제품 개발)
5.0 (1)조코딩에이엑스파트너스
경력근거: 테넌트 셋업, SSO/조직도 연동, 권한 설계, 초기 앱 구축까지
41일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
조코딩AX파트너스의 FDE 는 AXHub 를 들고 고객사에 들어가 테넌트 셋업·SSO/조직도 연동·권한 설계·초기 앱 구축까지 리드합니다. 말로 주어지는 접근 요구를 조직도대로 권한으로 바꿔 앱을 배포하는 이 사슬은, AXHub 처럼 앱 배포·기업 SSO·권한을 한데 묶은 플랫폼을 고객사 현장에서 세팅하는 맥락이 있어야 의미가 있습니다. 이 포트폴리오가 보여주는 것은 요구를 동작하는 소프트웨어로 옮기는 TypeScript 풀스택 구현과 조직도 기반 권한을 결정론으로 다루는 능력이며, 특정 산업의 도메인 전문성이나 실제 엔터프라이즈 보안 컴플라이언스 깊이는 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
FDE 는 고객의 요구를 듣고 동작하는 소프트웨어로 빠르게 전환하는 사람입니다. 교육 뒤에 남는 것은 결국 실제로 돌아가는 앱이라, 요구가 배포된 앱으로 닫혀야 가치가 완결됩니다.
AXHub 도입 리드는 테넌트 셋업·SSO/조직도 연동·권한 설계·초기 앱 구축입니다. 조직도 기반으로 누가 무엇을 볼·할 수 있는지를 정확히 세팅하는 것이 배포의 핵심입니다.
반복되는 패턴은 템플릿·가이드로 만들어 다음 고객사에서 재사용하고, 일부는 AXHub 제품 개선에 직접 기여합니다. 한 회사용 일회성이 아니라 재사용 엔진이어야 합니다.
고객사 담당자가 '회계팀만 경비를 조회하고, 팀장만 승인하게 해주세요'처럼 말로 준 접근 요구를 받습니다. 클로드가 그 요구를 권한 명세(누구에게·무엇을·허용/거부)로 바꾸고, 조직도(부서·직급·고용형태)와 대조해 사용자별 접근 매트릭스를 규칙으로 계산합니다. 계산된 권한이 실제로 강제되는 사내 AI 앱(경비 승인)을 테넌트에 올려, 로그인하면 회계팀 팀장에게는 승인 버튼이 뜨고 사원에게는 조회 화면만 뜹니다. 조직도는 SSO 조직도 메타를 CSV 로 가정해 시작하고, 요구가 맞게 반영됐는지 결정론 채점과 다음 고객사 재사용으로 이어집니다. 근거는 채용공고 정렬이고, 데이터는 작성자가 만든 더미입니다.
조코딩AX파트너스 FDE. 고객사에 상주하며 '이 팀만, 이 사람만' 같은 접근 요구를 말로 듣고 매번 손으로 권한을 세팅하던 상황을 끝내고, 요구가 조직도대로 정확히 반영됐는지 확인한 뒤 앱을 배포하고 싶은 사람입니다.
자연어 접근 요구를 권한 명세로 바꾸고 조직도(부서·직급·고용형태)와 대조하면, (a) 사용자별 접근 매트릭스를 규칙으로 결정론 계산하고, (b) 그 권한이 강제된 사내 AI 앱을 테넌트에 배포하며, (c) 요구별 의도 매트릭스와 대조해 반영이 맞았는지 객관 채점할 수 있습니다.
자연어 접근 요구를 권한 명세로 바꾸고 조직도와 대조해 접근 매트릭스를 계산한 뒤, 그 권한이 강제된 경비 승인 앱을 테넌트에 배포해 로그인하면 역할별로 화면이 다르게 뜨는 동작하는 도구입니다. 조직도는 실 SSO 연동 대신 SSO 조직도 메타를 CSV 로 가정해 시작하고, 실 SSO 연동은 3주차로 분리합니다.
요구별 의도 매트릭스와 규칙 계산 매트릭스를 사용자 단위로 대조해 반영이 맞았는지 객관 채점하고, 상충·부정·모호 요구를 충돌 해소하며, 배포 전 권한 변경분(diff)을 사람이 승인해야 반영되는 게이트와 감사 로그를 붙인 대시보드입니다.
반복되는 앱과 조직 매핑을 템플릿·프로파일로 만들어 다음 고객사 온보딩을 단축하고, GCP Cloud Run 과 GKE 네임스페이스로 테넌트를 격리해 여러 고객사를 함께 운영하는 단계입니다.
자연어 접근 요구 20건을 넣으면, 권한 명세와 조직도 기반 접근 매트릭스, 그리고 로그인하면 역할별로 다르게 뜨는 배포된 사내 앱이 몇 분 안에 나오는 걸 시연합니다.
요구별로 직접 만든 의도 매트릭스 20건과 규칙 계산 매트릭스를 사용자 단위로 대조해 18건이 정확히 일치했습니다(오탐·누락 사용자 0~1명). 단 조직도·정답을 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'입니다.
일부러 만든 상충·부정·별칭·미등록 부서 요구 30종을 넣어도 권한 명세 형식(JSON Schema)이 한 번도 안 깨지고, 모호한 요구는 임의 부여 대신 needs_human_review 로 사람에게 넘깁니다.
위 수치는 전부 작성자가 만든 더미 조직도·정답 자가채점이며, 실제 권한 정확도는 조코딩AX 실 고객사 조직도(SSO 조직도) + 실제 담당자 승인이 있어야 측정 가능합니다. 이 도구는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다.
이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 조직도 자가채점이라 '성능 증명'이 아닙니다. 면접에서는 '데모 조건 동작 + 실검증 준비 상태'로 솔직히 설명합니다
정답 매트릭스를 제가 만들었으니 잘 맞는 게 당연합니다. 상충·부정·별칭·미등록 부서·휴직/파견 경계 같은 헷갈리는 케이스를 조직도와 요구에 일부러 섞어, 쉬운 문제만 푸는 게 아님을 보여줘야 합니다.
권한은 틀리면 곧 사고입니다(과다 부여는 정보 유출, 과소 부여는 업무 마비). LLM 에 권한 결정을 맡기지 않고 자연어→규칙 변환만 시키며, 실제 매트릭스는 규칙으로 계산하고 배포 전 사람 승인 게이트를 반드시 거칩니다.
자연어 요구는 본질적으로 모호합니다. '관련자만' 같은 요구는 조직도만으로 특정할 수 없어 임의 부여 대신 사람에게 에스컬레이션하고, 조직도 별칭·미등록 부서는 추측하지 않고 미매핑으로 알립니다.
실제 도입 시 달라지는 것을 명시합니다. 실 SSO(조직도 연동)·실 조직도 규모·고객사별 정책이 더미와 달라 규칙 기본값(휴직·파견 포함 여부)과 별칭 사전을 다시 맞춰야 하고, 자가 승인도 실제 담당자 승인으로 교체해야 합니다(도입 단계 과제로 분리).
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 조직도입니다. SSO 조직도 연동으로 들어오는 사용자·부서·직급·고용형태로, 권한 엔진이 selector 를 대조하는 대상입니다. 부서 별칭(재무회계팀=회계팀)·미등록 부서(dept_id=null)·휴직/퇴사예정 상태·인턴/파견 고용형태·최상단 manager 결측을 일부러 섞어, 쉬운 조직도만 푸는 게 아님을 보여줍니다.
| user_id | name | dept_raw | dept_id | title | employment_type | manager_id | status |
|---|---|---|---|---|---|---|---|
| u01 | 김서준 | 회계팀 | d_acct | 팀장 | 정규직 | — | active |
| u02 | 이하은 | 회계팀 | d_acct | 대리 | 정규직 | u01 | active |
| u03 | 박도윤 | 재무회계팀 | d_acct | 사원 | 정규직 | u01 | active |
| u04 | 최유나 | 회계팀 | d_acct | 인턴 | 인턴 | u01 | active |
| u05 | 정시우 | 영업팀 | d_sales | 팀장 | 정규직 | — | active |
아래 JSON Schema 에 맞는 한국 중견기업 조직도 40행을 JSON 배열로 생성하세요. 부서 4~6개(회계팀·영업팀·인사팀·개발팀 등), 직급(팀장·대리·사원·인턴·엔지니어) 분포 자연스럽게.
{"type":"object","properties":{"user_id":{"type":"string"},"name":{"type":"string"},"dept_raw":{"type":"string"},"dept_id":{"type":["string","null"]},"title":{"type":"string"},"employment_type":{"type":"string","enum":["정규직","계약직","인턴","파견"]},"manager_id":{"type":["string","null"]},"status":{"type":"string","enum":["active","leave","offboarding"]}},"required":["user_id","name","dept_raw","title","employment_type","status"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞으세요: (1) 부서 별칭 표기 — 같은 부서를 dept_raw '재무회계팀'/'회계팀' 처럼 다르게 쓰되 dept_id 는 같게(정규화 대상), (2) 미등록 부서 — dept_id=null 인 행 1~2건(dept_master 에 없는 orphan, '미매핑'으로 알려야 함), (3) 팀장 등 최상단은 manager_id=null, (4) 고용형태 경계 — 인턴·파견·계약직 각 1~2건, (5) status 경계 — leave(휴직)·offboarding(퇴사예정) 각 1~2건(권한 기본 필터 대상). JSON 배열만.{"type":"object","properties":{"user_id":{"type":"string"},"name":{"type":"string"},"dept_raw":{"type":"string"},"dept_id":{"type":["string","null"]},"title":{"type":"string"},"employment_type":{"type":"string","enum":["정규직","계약직","인턴","파견"]},"manager_id":{"type":["string","null"]},"status":{"type":"string","enum":["active","leave","offboarding"]}},"required":["user_id","name","dept_raw","title","employment_type","status"]}고객사 담당자가 자연어로 준 접근 요구와, 그 요구가 의도한 정답 접근 집합(intended_allow_user_ids)입니다. 결정론 채점의 정답 라벨로, org_directory 의 user_id 를 참조합니다. 상충·부정·별칭·미등록 부서·모호 요구를 일부러 섞어, 규칙 엔진이 쉬운 요구만 푸는 게 아님을 보여줍니다.
| req_id | app | action | raw_text | intended_allow_user_ids | ambiguity |
|---|---|---|---|---|---|
| r01 | 경비승인앱 | view | 회계팀은 전부 경비 내역을 조회할 수 있게 해주세요. | ["u01","u02","u03","u04"] | — |
| r02 | 경비승인앱 | approve | 경비 승인은 회계팀 팀장만 할 수 있어야 합니다. | ["u01"] | — |
| r03 | 급여조회앱 | view | 급여는 인사팀만 조회하되, 휴직자는 제외합니다. | ["u07"] | — |
| r04 | 경비승인앱 | view | 회계팀 전원 조회, 단 인턴은 제외해주세요. | ["u01","u02","u03"] | — |
| r05 | 채용현황앱 | view | 채용 관련자만 볼 수 있게 해주세요. | [] | '관련자'가 조직도의 어느 부서·직급인지 특정 불가 — 사람 확인 필요 |
아래 JSON Schema 에 맞는 자연어 접근 요구 30건을 JSON 배열로 생성하세요. app 은 경비승인앱·급여조회앱·채용현황앱 등, action 은 view·approve·edit·admin. intended_allow_user_ids 는 org_directory 를 규칙대로 적용한 정답(부서·직급·고용형태·status 반영, 기본적으로 status=active 만 포함하고 offboarding 제외)이어야 합니다.
{"type":"object","properties":{"req_id":{"type":"string"},"app":{"type":"string"},"action":{"type":"string","enum":["view","approve","edit","admin"]},"raw_text":{"type":"string"},"intended_allow_user_ids":{"type":"array","items":{"type":"string"}},"ambiguity":{"type":["string","null"]}},"required":["req_id","app","action","raw_text","intended_allow_user_ids"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞으세요: (1) 부정 조건 — '단 인턴/파견 제외', '휴직자 제외'(allow 와 deny 상충, deny 우선), (2) 별칭 부서명 — '재무회계팀' 처럼 조직도 정규화가 필요한 표기, (3) 미등록 부서 요구 — 조직도에 없는 부서(intended 는 빈 배열, ambiguity 에 '미매핑' 사유), (4) 모호 요구 — '관련자만'·'윗사람만' 처럼 조직도만으로 특정 불가(intended 빈 배열, ambiguity 채움), (5) 직급 필터 — '대리 이상'·'팀장만', (6) 다중 부서 — '영업팀 팀장과 회계팀 팀장'. JSON 배열만.{"type":"object","properties":{"req_id":{"type":"string"},"app":{"type":"string"},"action":{"type":"string","enum":["view","approve","edit","admin"]},"raw_text":{"type":"string"},"intended_allow_user_ids":{"type":"array","items":{"type":"string"}},"ambiguity":{"type":["string","null"]}},"required":["req_id","app","action","raw_text","intended_allow_user_ids"]}| TypeScript | 대표 언어입니다. 권한 규칙 엔진(selector 매칭·deny 우선), 요구→명세 변환 클라이언트, 배포되는 사내 앱, 결정론 채점기까지 전 계층을 한 언어로 구현합니다. |
| React | 역할별로 다르게 렌더되는 사내 앱 화면(팀장에게는 승인 버튼, 사원에게는 조회 화면)과 배포 전 권한 diff 승인 콘솔을 만듭니다. |
| LLM | 자연어 접근 요구를 구조화된 권한 명세(rules)로 변환합니다. 변환만 맡고 권한 강제·채점은 결정론 규칙 엔진이 합니다. |
| Claude | 요구→명세 변환 모델은 Claude Sonnet 을 씁니다. 앱 골격과 배포 스크립트는 Claude Code·Cursor 로 빠르게 생성합니다. |
| Next.js | 테넌트별 앱 배포 단위입니다. App Router 로 멀티테넌트 라우팅을 나누고 권한 API 와 RBAC 훅을 제공합니다. |
| PostgreSQL | org_directory·access_requests·계산된 접근 매트릭스·감사 로그의 단일 진실원입니다. |
| Go | (우대) 권한 결정 서비스(PDP)를 별도 마이크로서비스로 분리할 때 씁니다. 3주차 GKE 배포에서 여러 테넌트의 접근 판정을 담당합니다. |
| GCP | (우대) 3주차 멀티테넌트 배포입니다. Cloud Run 으로 테넌트별 앱을, Cloud SQL 로 조직·권한 저장소를 운영합니다. |
| Kubernetes | (우대) 3주차 GKE 로 여러 고객사 테넌트를 네임스페이스로 격리해 운영합니다. |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우고 싶으면 2주차(요구가 맞게 반영됐는지 결정론 채점)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(재사용 템플릿 + GCP 멀티테넌트 배포)로 진행합니다.
자연어 접근 요구를 구조화된 권한 명세(rules)로 변환하고, evidence_phrase 로 각 규칙이 요구의 어느 구절에서 나왔는지 추적합니다. resolved_allow_user_ids 는 LLM 이 자유 생성하지 않고 rules 를 조직도에 결정론적으로 적용해 계산한 값으로, 이걸 intended_allow_user_ids 와 대조해 채점합니다. 모호하면 needs_human_review 로 에스컬레이션합니다.
{"type":"object","properties":{"req_id":{"type":"string"},"app":{"type":"string"},"rules":{"type":"array","items":{"type":"object","properties":{"effect":{"type":"string","enum":["allow","deny"]},"selector":{"type":"object","properties":{"dept":{"type":["string","null"]},"title_min":{"type":["string","null"]},"employment_type":{"type":["string","null"]}}},"action":{"type":"string","enum":["view","approve","edit","admin"]},"evidence_phrase":{"type":"string"}},"required":["effect","selector","action","evidence_phrase"]}},"conflicts":{"type":"array","items":{"type":"string"}},"resolved_allow_user_ids":{"type":"array","items":{"type":"string"}},"needs_human_review":{"type":"boolean"},"review_reason":{"type":["string","null"]},"confidence":{"type":"number"}},"required":["req_id","app","rules","resolved_allow_user_ids","needs_human_review"]}[
{
"req_id": "r01",
"app": "경비승인앱",
"rules": [
{
"effect": "allow",
"selector": {
"dept": "회계팀",
"title_min": null,
"employment_type": null
},
"action": "view",
"evidence_phrase": "회계팀은 전부 경비 내역을 조회"
}
],
"conflicts": [],
"resolved_allow_user_ids": [
"u01",
"u02",
"u03",
"u04"
],
"needs_human_review": false,
"review_reason": null,
"confidence": 0.92
},
{
"req_id": "r04",
"app": "경비승인앱",
"rules": [
{
"effect": "allow",
"selector": {
"dept": "회계팀",
"title_min": null,
"employment_type": null
},
"action": "view",
"evidence_phrase": "회계팀 전원 조회"
},
{
"effect": "deny",
"selector": {
"dept": "회계팀",
"title_min": null,
"employment_type": "인턴"
},
"action": "view",
"evidence_phrase": "단 인턴은 제외"
}
],
"conflicts": [
"allow(회계팀) 와 deny(회계팀·인턴) 가 u04 에서 상충 → deny 우선 적용"
],
"resolved_allow_user_ids": [
"u01",
"u02",
"u03"
],
"needs_human_review": false,
"review_reason": null,
"confidence": 0.86
},
{
"req_id": "r05",
"app": "채용현황앱",
"rules": [],
"conflicts": [],
"resolved_allow_user_ids": [],
"needs_human_review": true,
"review_reason": "'관련자'가 조직도의 어느 부서·직급을 뜻하는지 특정 불가. 임의 부여 대신 담당자 확인 필요.",
"confidence": 0.28
}
][자동 검증 — 규칙·결정론으로 채점] 1. JSON Schema 통과: 권한 명세가 형식(effect·selector·action·evidence_phrase)을 지키는지. 깨지면 배포 차단. 2. evidence_phrase 실재: 각 규칙의 evidence_phrase 가 요구 원문(raw_text)의 실제 부분 문자열인지(공백 정규화 후). LLM 이 없는 근거를 지어내면 탈락. 3. 결정론 매트릭스 일치: resolved_allow_user_ids 를 rules × org_directory 로 재계산(selector 매칭 + deny 우선 + status=active 만·offboarding 제외·별칭 정규화)해 intended_allow_user_ids 와 대조. 오탐(잘못 허용)·누락(빠뜨림)을 사용자 단위로 집계. 4. 미매핑 처리: 조직도에 없는 부서를 참조한 규칙은 자동으로 미매핑 표시 후 needs_human_review=true. [수동 검증 — 사람이 판단] 1. 모호 요구(needs_human_review=true)는 담당자가 의도 부서·직급을 확정해야 배포. 자동 부여 금지. 2. 배포 전 권한 diff(현재 vs 새 권한)를 사람이 승인해야 반영.