DERMA:CODE

절대 점수만으로는 환자 간 차이를 설명하기 어려워 코호트 내 상대적 위치를 보여주는 방식으로 전환했습니다.

Q1/Q3 사분위 기반 산식을 운영진에게 제안했습니다. 보정식을 적용해 통계를 다시 산출하고, 점수 쏠림이 완화된 것을 확인한 뒤 최종 계산식에 반영했습니다.

평균 기준 정규화로는 대다수가 좁은 구간에 몰려 차이가 드러나지 않았습니다. p10~p90 마커 사이를 선형 보간해 코호트 내 위치를 산출하고, 25/50/75 사분위 컷오프로 심각도를 4단계로 분류했습니다. 표본이 부족한 연령대는 상위 코호트로, 성별 미상은 통합 코호트로 폴백했습니다.

정규화는 제품 내 표시를 위한 임시 보정이고, 근본 원인은 모델 성능 문제로 판단했습니다. 이 분석 결과를 공유해 회사 차원의 모델 문제 정의로 연결했습니다.

요청을 바로 기능으로 제안하기보다, 구현 가능성과 비용을 먼저 확인했습니다.

첫날에는 3D 파일을 어느 정도까지 변형할 수 있는지 확인해 구현 범위를 가늠했습니다. 이후 2주 동안 3D 얼굴 메시를 시술별로 변형하는 프로토타입을 만들고, 실제 화면에서 원하는 결과를 만들 수 있는지 검증했습니다.

시술 효과를 약 6개의 변형 파라미터로 모델링하고, 시술별 파라미터 값은 별도의 설정 페이지에서 관리할 수 있도록 백엔드 데이터로 분리했습니다.

이를 통해 엔진 로직과 시술 정의를 분리하고, 새로운 시술을 추가할 때 메인 3D 처리 엔진을 수정하지 않아도 되는 구조를 만들었습니다.

이벤트 데이터로 탭별 사용률을 계산하고, Hotjar Heatmap으로 실제 상담 흐름을 확인했습니다.

두 달간 측정한 결과, 메인 기능을 담당하는 탭 사용률은 84%인 반면 업셀링을 위해 분리한 탭은 4.5%에 그쳤습니다. Heatmap에서도 상담사가 별도 업셀링 탭으로 이동하기보다 솔루션 추천 흐름 안에서 상담을 이어가는 패턴을 확인했습니다.

업셀링 탭을 GNB에서 제거하고, 신규 기능을 새 탭으로 추가하는 대신, 솔루션 추천 과정에서 시너지 솔루션을 함께 노출하는 구조를 제안했습니다.

상담 흐름을 별도 탭으로 분리하지 않고, 기존 추천 과정 안에서 추가 솔루션까지 이어서 확인할 수 있도록 V2 GNB와 화면 구조를 재편했습니다.

먼저 동일한 효과를 Canvas 2D와 GPU로 각각 구현해 처리 시간을 비교했습니다. Canvas 2D는 1117ms, GPU는 50ms로 약 22배 차이가 났고, 결과의 동일성도 확인해 GPU 이관을 결정했습니다.

이후 실제 효과 하나를 GPU로 이관한 뒤 구간별 처리 시간을 다시 측정했습니다. 전체 243ms 중 GPU 연산은 0.3ms에 불과한 반면, CPU readback이 218.7ms를 차지했습니다. GPU의 계산 성능보다 GPU에서 CPU로 데이터를 되돌려 받는 과정이 실제 병목이었습니다.

효과를 하나씩 GPU로 처리하고 매번 readback하는 대신, 여러 효과를 GPU에서 연속 처리한 뒤 마지막에 한 번만 readback하도록 구조를 변경했습니다.

또한 계측 과정에서 applyRednessCorrection()에 vertexUVs 인자가 누락되어 얼굴 영역이 아닌 전체 영역을 처리하고 있던 CPU 버그를 발견했습니다. 이를 수정해 해당 처리 시간을 17.4초에서 5.1초로 단축했습니다.

한 번에 여러 요소를 변경하지 않고 원인별로 나눠 단계적으로 계측했습니다. 각 변경이 LCP에 미치는 영향을 확인한 뒤 다음 최적화를 진행했습니다.

1. 렌더 게이트 제거 → LCP 14.2초

2. 2,827ms가 걸리던 미사용 Geist 폰트 요청 제거 → 다른 리소스와 병렬로 로드되고 있어 LCP는 14.2초로 유지

3. 로딩 화면 추가 → LCP가 23.7초로 악화. 오버레이가 LCP 요소를 가리고 있음을 계측으로 확인하고 롤백

4. 2D 콘텐츠 우선 렌더링 + 3D 리소스 지연 로딩 → 7.9초

5. 서버에서 Sharp로 이미지 리사이즈 및 WebP 변환 → 리소스 3,506KB → 123KB, 최종 5.7초