메라Product Engineer(FE)
3.9 (16)메라키플레이스
경력근거: 서비스의 Frontend를 이루는 다양한 App, Web, Desktop 제품들을 개발/운영
어제 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
나만의닥터는 비대면 진료에서 시작해 진료·복약·건강 마이데이터를 App·Web·Desktop으로 잇는 헬스케어 슈퍼앱이라, 진료 기록 결측·권한 없음 같은 화면 상태와 멀티플랫폼 일관성 문제가 메라키플레이스의 제품 구성에서만 현실적으로 나옵니다. 이 포트폴리오는 React·React Native·Electron으로 화면 상태를 일관되게 렌더하고 기능 플래그로 안전하게 배포하는 프론트엔드 기술을 보여주며, 진료·복약 의료 도메인 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
나만의닥터의 진료·복약·건강 화면을 App·Web·Desktop 여러 플랫폼에서 같은 컴포넌트와 상태 규칙으로 일관되게 렌더합니다.
진료 기록 결측·조회 오류·권한 없음 같은 경우를 데이터에서 규칙으로 판정해 정해진 화면 상태로만 렌더합니다.
새 화면을 기능 플래그로 일부 사용자에게만 켜고 문제가 생기면 되돌려, 대규모 사용자에게 안전하게 기능을 내보냅니다.
메라키플레이스의 헬스케어 슈퍼앱 나만의닥터 화면을 디자인 시스템 컴포넌트와 상태 규칙으로 조립하고 기능 플래그로 안전하게 내보내는 멀티플랫폼 프론트엔드입니다. 진료·복약·건강 데이터를 한 컴포넌트로 받아 로딩·결측·오류·권한 없음 같은 경우마다 정해진 화면 상태로 App·Web·Desktop에서 일관되게 렌더하고, 새 화면은 기능 플래그로 일부에게만 켜고 문제가 생기면 되돌립니다. 데이터는 사내 API 대신 더미를 가정합니다.
진료·복약·건강 화면을 App·Web·Desktop마다 따로 손보다 보니 결측·오류 화면이 플랫폼마다 제각각이고, 새 기능을 전체에 한 번에 켰다가 문제가 나면 되돌리기 어려워 조마조마하던 프론트엔드 개발자가, 한 컴포넌트로 일관성을 잡고 기능 플래그로 안전하게 배포하고 싶은 사람입니다.
데이터에서 화면 상태로 가는 판정을 규칙으로 고정하고 디자인 시스템 컴포넌트가 그 상태만 렌더하게 하며 새 화면을 기능 플래그로 감싸면, 플랫폼이 늘어도 UI 일관성이 유지되고 문제가 생긴 기능만 골라 되돌릴 수 있다는 가정입니다.
진료·복약·건강 데이터 더미(결측·오류·권한 없음 포함)를 넣으면 디자인 시스템 컴포넌트가 로딩 중·데이터 없음·조회 오류·권한 없음 같은 정해진 상태로 렌더하는 스토리북과, 데이터에서 상태로 가는 규칙을 정답으로 둔 상태 스냅샷 자동 검사가 도는 완결품입니다. 데이터는 사내 API 대신 더미를 가정합니다.
1주차 컴포넌트를 기능 플래그로 감싸 일부 사용자에게만 새 화면을 켜고 문제가 생기면 되돌리는 흐름을 붙이고, GCP·AWS로 배포·운영하면서 오류 발생 화면을 오류 추적으로 잡아 상태별로 보여줍니다.
React Native 기반 iOS·Android와 Electron 기반 Desktop에서 같은 화면 상태가 깨지지 않는지 측정하고, 플랫폼별 렌더 차이와 성능을 함께 보여줍니다.
결측·오류·권한 없음을 섞은 데이터 더미를 넣으면 로딩·데이터 없음·조회 오류·권한 없음 같은 정해진 화면 상태로 렌더되는 과정을 시연합니다.
데이터에서 상태로 가는 규칙으로 만든 정답과 컴포넌트가 만든 상태의 일치율을 보여주며, 단 정답과 데이터를 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
일부러 만든 결측·오류·권한 없음·표기 흔들림 30종을 넣어도 컴포넌트가 빈 화면이나 깨진 레이아웃 없이 정해진 상태로만 렌더되는 강건성을 보여줍니다.
위 수치는 더미데이터 자가채점이며, 실제 화면 상태 일치율과 멀티플랫폼 안정성은 메라키플레이스 실 데이터와 실 사용자 트래픽이 있어야 측정 가능합니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아니므로, 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 만들었으니 잘 맞는 게 당연하므로, 결측·오류·권한 없음·표기 흔들림 같은 경계 케이스를 더미에 일부러 섞어 쉬운 문제만 푸는 함정을 피합니다.
이 포트폴리오는 멀티플랫폼 프론트엔드 렌더 일관성과 기능 플래그 배포 기술을 보여주며, 진료·복약 의료 도메인 전문성은 주장하지 않습니다. 화면 상태는 규칙으로 채점하고 LLM 은 안내 문구 보조만 맡으며 의료 판단은 하지 않습니다.
실제 도입 때는 사내 디자인 시스템과 실 진료·복약 데이터 분포, 실 사용자 트래픽으로 상태 규칙과 배포 기준이 달라지므로, 규칙 테이블과 플래그 정책 교체를 도입 단계 과제로 둡니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
나만의닥터의 진료·복약·건강 항목 데이터로, 값 결측·조회 오류·권한 없음·표기 흔들림 같은 하드 케이스를 일부러 섞어 컴포넌트가 정해진 화면 상태로만 렌더되는지 확인합니다.
| record_id | kind | title | value | fetch_status | access | updated_at |
|---|---|---|---|---|---|---|
| R-6001 | 진료 | 내과 비대면 진료 | 고혈압 경과 관찰 | ok | granted | 2026-06-30 |
| R-6002 | 복약 | 암로디핀 5mg | 1일 1정 아침 | ok | granted | 2026-07-01 |
| R-6003 | 건강지표 | 혈압 | — | loading | granted | — |
| R-6004 | 진료 | 피부과 진료 기록 | — | error | granted | — |
| R-6005 | 복약 | 타 병원 처방 내역 | — | ok | denied | 2026-06-28 |
다음 JSON Schema 에 맞는 진료·복약·건강 항목 행을 더 생성하세요: {"type":"object","properties":{"record_id":{"type":"string"},"kind":{"type":"string","enum":["진료","복약","건강지표"]},"title":{"type":"string"},"value":{"type":["string","null"]},"fetch_status":{"type":"string","enum":["ok","error","loading"]},"access":{"type":"string","enum":["granted","denied"]},"updated_at":{"type":["string","null"]}},"required":["record_id","kind","title","fetch_status","access"]} 쉬운 데이터만 만들지 말 것 — 다음 하드 케이스를 의도적으로 섞어라: value 를 null 로 둔 값 결측, fetch_status 가 error 인 조회 오류, access 가 denied 인 권한 없음, fetch_status 가 loading 인 로딩 중, 혈압을 120/80mmHg 와 120/80 mmHg 처럼 단위 표기가 흔들리는 표기 불일치, value 가 0 인 경계값. 각 kind 마다 정상 1건과 하드 케이스 1건 이상이 섞이게 하고, 형식 깨뜨리기 시도(스키마 타입 위반) 3건은 데이터가 아니라 별도 목록으로 표시하세요.{"type":"object","properties":{"record_id":{"type":"string"},"kind":{"type":"string","enum":["진료","복약","건강지표"]},"title":{"type":"string"},"value":{"type":["string","null"]},"fetch_status":{"type":"string","enum":["ok","error","loading"]},"access":{"type":"string","enum":["granted","denied"]},"updated_at":{"type":["string","null"]}},"required":["record_id","kind","title","fetch_status","access"]}| TypeScript | 진료·복약 데이터와 화면 상태 enum 을 타입으로 묶어, 상태 분기 누락을 컴파일 단계에서 막습니다. |
| React | Web 화면을 화면 상태별로 렌더하는 디자인 시스템 컴포넌트를 구현합니다. |
| React Native | 같은 상태 규칙으로 iOS·Android App 화면을 렌더해 플랫폼 간 일관성을 유지합니다. |
| Electron | Desktop 제품에서 같은 컴포넌트로 화면 상태를 렌더합니다. |
| React Query | 진료·복약 데이터의 로딩·오류 상태를 받아 화면 상태 판정의 입력으로 씁니다. |
| Zustand | 기능 플래그와 화면 상태를 담아 컴포넌트가 같은 상태만 렌더하게 합니다. |
| Feature Flag | 새 화면을 일부 사용자에게만 켜고 문제가 생기면 되돌리는 안전 배포를 구현합니다. |
| Sentry | 배포된 화면에서 나는 오류를 잡아 어떤 상태에서 깨졌는지 추적합니다. |
| GCP·AWS | 2주차부터 Web과 배포 산출물을 GCP·AWS로 배포·운영합니다. |
| Claude Sonnet | 진료·복약 원문에서 화면에 들어갈 한 줄 안내 문구만 생성하고, 화면 상태 판정은 규칙이 결정합니다. |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차에서 기능 플래그 안전 배포와 GCP·AWS 운영을 붙입니다.
✓ pass → 여기서 멈춰도 검증된 완결입니다. 더 키우려면 3주차에서 App·Desktop 멀티플랫폼 일관성을 다룹니다.
진료·복약 항목 한 건을 받아 어떤 화면 상태로 렌더할지와 그 판정의 근거가 된 데이터 필드를 함께 내보내, 컴포넌트 출력을 규칙 정답과 자동으로 대조할 수 있게 합니다.
{"type":"object","properties":{"record_id":{"type":"string"},"state":{"type":"string","enum":["정상","로딩중","데이터_없음","조회_오류","권한_없음"]},"evidence":{"type":"array","items":{"type":"object","properties":{"field":{"type":"string"},"value":{"type":["string","null"]}},"required":["field","value"]}},"notice":{"type":["string","null"]},"hedge":{"type":["string","null"]}},"required":["record_id","state","evidence"]}[
{
"record_id": "R-6005",
"state": "권한_없음",
"evidence": [
{
"field": "access",
"value": "denied"
}
],
"notice": "이 기록은 접근 권한이 필요합니다",
"hedge": "access 가 denied 라 권한 없음을 다른 상태보다 앞세웠습니다."
},
{
"record_id": "R-6004",
"state": "조회_오류",
"evidence": [
{
"field": "fetch_status",
"value": "error"
}
],
"notice": "기록을 불러오지 못했습니다",
"hedge": "fetch_status 가 error 라 조회 오류 상태로 표시했습니다."
},
{
"record_id": "R-6003",
"state": "로딩중",
"evidence": [
{
"field": "fetch_status",
"value": "loading"
}
],
"notice": null,
"hedge": "fetch_status 가 loading 이라 로딩 상태로 렌더했습니다."
},
{
"record_id": "R-6008",
"state": "권한_없음",
"evidence": [
{
"field": "access",
"value": "denied"
},
{
"field": "fetch_status",
"value": "error"
}
],
"notice": "이 기록은 접근 권한이 필요합니다",
"hedge": "권한 없음과 조회 오류가 겹쳐 권한 없음을 우선했습니다(합성 기준)."
},
{
"record_id": "R-6001",
"state": "정상",
"evidence": [
{
"field": "fetch_status",
"value": "ok"
},
{
"field": "access",
"value": "granted"
}
],
"notice": null,
"hedge": null
}
][자동 검증] 1. state 가 규칙 정답(access denied 면 권한_없음, fetch_status error 면 조회_오류, loading 이면 로딩중, value 결측이면 데이터_없음)과 일치하는지 대조합니다. 2. evidence 의 field 와 value 가 입력 항목의 실제 값과 같은지 확인해, 근거 없는 상태 판정을 거릅니다. 3. 상태 우선순위(권한 없음이 조회 오류보다 앞)가 규칙과 일치하는지 확인합니다. [수동 검증] 1. 권한 없음과 조회 오류가 겹치는 경우 어떤 상태를 앞세웠는지 hedge 설명이 정책과 맞는지 사람이 봅니다. 2. notice 문구가 의료 맥락에서 오해를 주지 않는지 스팟체크합니다.