1. 광고 지면 수익화와 운영 자동화 (파워링크 연동 → 슬롯 스케줄 결함 수정 → 부킹 시트 자동 동기화)

• 메타: 2025.07 ~ 2026.06 · FE 단독(에픽·요구사항 PO, 계약·운영은 광고사업 담당, 판매 정책은 BD 협업), 2026.Q2 동기화 루틴은 직접 발의 · Next.js(유저웹), React Native(유저앱), 네이버 파워링크 API, Google AdSense, AdExchange·AdControl, Claude Code 스케줄 루틴, Google Sheets
• 2025.Q3 — 네이버 파워링크·구글 애드센스 지면:
  • 문제/배경: 무물보(QnA) 상세에 네이버 파워링크와 애드센스 지면을 추가하는 과제(에픽 PO). 도중에 네이버가 병의원 광고를 함께 내기로 해 의료심의번호·소재 규격을 맞추는 추가 개발과 재검수가 필요했음.
  • 기여:
    • NaverAdComponent·GoogleAdSense 컴포넌트로 네이버 파워링크 API를 연동하고, 병의원 광고 규격(의료심의번호 위치, 태그·이미지·파비콘)을 맞춰 네이버 외부 QA 두 차례를 통과시킨 뒤 라이브함.
    • 애드센스 소유권 연동과 네이버·애드센스 지면 교체(2025-08-22).
  • 성과: (광고사업 담당 관측, 외부 광고 콘솔 값이라 재측정 불가) 파워링크 라이브 직후 일 수익 4,200 → 48,000원, 지면 교체 첫 주(2025-08-25~31) 광고 매출 전주 대비 약 +10만 원(파워링크 +31만, 애드센스 −21만).
• 2026.Q1 — 상단 띠배너 슬롯 스케줄 결함 수정:
  • 문제/배경: 유저웹 광고 스케줄이 코드에 있어 BD가 부킹하면 개발자가 반영하는 구조였고, 질문 상세 모바일 상단 띠배너(TopCommonBanner)는 슬롯 가중치 컴포넌트가 아닌 레거시 컴포넌트를 쓰고 있었음.
  • 기여: 광고 업무 인수 첫 달, 배포 후 운영 화면을 직접 보다가 상단 띠배너가 스케줄(직광고 1/4)을 무시하고 직광고를 100% 노출하던 결함을 찾아 슬롯 가중치 컴포넌트로 교체. “직광고 100%” 요청은 롤백 대신 판매 단위(4슬롯 전체 구매 = 스케줄 4개)를 데이터로 표현해 풀고, 데브존 직광고 미리보기를 붙임.
• 2026.Q2 — 부킹 시트 자동 동기화 루틴 (직접 발의):
  • 문제/배경: 광고 스케줄 수정 요청마다 개발자가 수동 반영했고, 직광고 50:50 랜덤 노출 구조는 운영 장부와 코드의 동기화가 불가능했음.
  • 기여:
    • SlotAd 일원화: 운영 시트 정리가 끝난 뒤 레거시 50:50 랜덤 컴포넌트(배너 8곳·네이티브 3곳·prefetch 5곳)를 4슬롯 가중치 구조로 교체하고, 빈 슬롯은 다른 슬롯 광고 또는 AdSense fallback. 구좌당 1/4 판매 정책은 BD와 합의(2026-04-30).
    • 자동 동기화: 구글 시트 광고 장부에서 FE 관리 구좌만 구독하는 시트를 분리하고, Claude 루틴이 매일 밤 diff 감지 시 자동 수정·PR 생성·슬랙 알림(신규/종료/수정 요약) 수행.
  • 성과: 루틴 PR 머지 24건(2026-04-28 ~ 06-30). 누락·오삭제·중복·슬롯 축소 사고마다 원인을 가려 결정형 게이트(행 감사·체크섬·diff 계획 대조, 종료일 불변식)로 막음. 실제로 매핑에 없는 슬롯명에서 abort·알림이 발동함(2026-05-20). 2026.Q3부터는 야간 AI 루틴 4종 중 하나로 운영(기술 과제 #10).

2. 약사웹 도매몰 구매 퍼널 개편 (자사몰 전환기)

• 메타: 2025.04–05 · FE 단독(기획 PM, 디자인·BE 협업) · React(CRA), GraphQL
• 문제/배경: 2025-03-17 약사웹 도매몰이 외부 몰에서 자사몰로 옮겨졌지만, 도매 제휴 약국이 아니면 도매 메뉴를 쓸 수 없었고 상세를 거쳐야만 담을 수 있었음. 약품 도매 이용 허들을 낮추는 것이 목표(릴리즈노트).
• 기여:
  • 가입 관문을 결제 시점 약관 동의로 옮겨 비제휴 약국도 둘러보고 담게 함(동의 후 곧바로 주문하는 원룩 흐름 제안).
  • 리스트·랭킹·주문 상세에서 바로 담기 모달, 최근 구매·관련 상품·함께 주문하기 좋은 상품, 검색바 고정과 최근·추천 검색어를 FE 단독으로 냄(2025-05-07).
  • 재고 수량을 응답에서 빼고 수량 변경마다 재고 확인 API로 검사해 재고 크롤링을 막음(2025-05-14).
• 성과:
  • 월 도매 매출 9.4억 → 12.1억 (+28%, 2025년 4월 → 5월). 같은 시기 자사몰 전환으로 구매 약국 수도 375 → 506곳으로 늘어(약국당 결제액은 −9%), 퍼널 개편 단독 효과로 분리하지는 않음.
• 한계: 2025-04-21 첫 배포에서 필수 약관 설정 때문에 전 약사에게 약관 동의 모달이 떠 두 번 롤백하고 같은 날 재배포함.

3. 약사웹 조제 흐름 안 도매 유도와 의사웹 툴팁 이식 (운영이 켜고 끄는 툴팁 관리)

• 메타: 2025.08 ~ 2025.11 · FE 단독 구현(기획 PM, 디자인·BE API 협업) · React(Vite) 약사웹, Next.js 의사웹, React + antd CS 어드민, GraphQL, GA4 클릭 로그
• 2025.Q3 — 약사웹 조제 흐름 안 도매 진입점:
  • 문제/배경: 약국이 도매몰에 잘 들어오지 않아, 약사가 매일 쓰는 조제 흐름 안에 도매 진입점을 넣는 과제(에픽 PM).
  • 기여: 조제 수락·거절 직후 결과 페이지의 도매 추천 상품(거절은 비대면 처방 상위, 수락은 최저가 상품에서 4개), 조제리스트 노출 뱃지, LNB 도매 메뉴 툴팁을 붙이고, 운영이 문구와 노출을 직접 바꾸는 CS 어드민 약국 도매 툴팁 관리 화면을 만듦. 결과 페이지 클릭 로그 6종은 배포 전에 기획·디자인과 맞춤.
  • 성과: (PM·디자이너 집계, 배포 후 약 2개월) 조제 수락 결과 페이지 진입 세션 대비 장바구니 약 5%, 바로구매 약 8%. 디자이너 요약은 “전환율 자체는 정체”였고 대조군이 없어 효과는 주장하지 않음.
• 2025.Q4 — 의사웹 LNB 툴팁 이식:
  • 문제/배경: 의사 회원의 도매 서비스 인지도가 낮고 구매 전환율이 정체됨.
  • 기여: 약사웹 LNB 도매 툴팁(2025.Q3 본인 구현)을 의사웹 LNB 도매 메뉴 옆에 이식하고, CS 어드민에 의사 도매 툴팁 관리를 붙여 운영팀이 문구를 직접 켜고 끄게 함.
  • 성과: 툴팁 배포(2025-11-24) 전후 15일 의사 도매 주문 7 → 23건(3.3배), 일평균 결제액 34.8만 → 222.8만 원(6.4배). 같은 기간 약사 도매(대조)는 −2.4%. LNB 클릭 로그가 없고 배포 전 표본이 7건이라 툴팁 효과로 귀속하지 않음.

4. 결제 시스템 개편 (토스 PG 전환 FE · 토스페이 간편결제)

• 문제/배경: 기존 PG사의 높은 수수료 문제 해결을 위해 토스페이먼츠로의 전환이 필요했으나, 카드 재등록 과정에서 유저 이탈이 우려됨.
• 기여:
  • 토스 PG 전환 2단계의 FE를 맡아 카드 등록을 BFF 뮤테이션으로 바꾸고 첫 등록 500P 혜택·카드 재등록 안내를 진료 신청서에 붙임. 앱 선배포가 필요하다는 배포 순서 리스크를 짚어 이벤트 시작을 하루 늦춤.
  • BroadcastChannel API를 활용하여 웹뷰(카드등록)와 웹뷰(결제 또는 카드관리) 간의 실시간 데이터 동기화 구현, 카드 등록 이벤트 포인트 지급 안내.
• 성과: 회사 차원 결과(본인 FE 효과로 쓰지 않음): 토스 PG 건수 비중(도매 제외) 2월 9.2% → 4월 28.5%, PM 계산 수수료율 약 2.5%(2024-12) → 2.16%(2025-03-31). PG 전환 본체·기존 PG 제거와 겹쳐 FE 기여는 분리하지 않음.
• 한계: 이벤트 당일 내 유저앱 딥링크가 보내는 화면 스택에 카드 등록 화면이 빠져 있어 팝업의 카드 등록이 먹통이 됐고, 스크린을 추가해 당일 앱 배포로 고침.
• 2026.Q3 — 토스페이 간편결제 + 예산형 프로모션:
  • 메타: 2026.07–09 · FE 단독(파트너사·BE·디자인·경영진 협의) · Next.js, React Native, GrowthBook
  • 핵심 판단: 파트너사와의 정책 협의(할인 주체·예산 소진·대상 식별)를 직접 열어 설계 전제를 먼저 확정. 결제사 이름을 UI 에 박지 않는 중립 명명과 차원 1개짜리 로그로 다음 결제수단 추가 비용을 낮춤. 예산 주체가 다른 두 프로모션을 플래그 2개로 나눠 각각 킬스위치로 운영.
  • 기여: 가맹점 번호 발급 지연으로 3주 멈춘 브랜치를 규칙이 바뀐 메인 위로 재적재(로직 변경 0), 중복 혜택 합산 표기, 결제·등록·점유율·실패 사유를 한 화면에 묶은 대시보드.
  • 성과: 출시 후 17일(9/7~9/23) 결제 11,421건 · 1억 5,571만 원, 간편결제 3사 중 주별 점유율 7.1% → 9.3%. 프로모션 효과는 신호가 약해(표본 작음, 바이럴과 겹침) 주장하지 않음.

5. O2O 유입 확장 및 유저 획득/리텐션 장치 개편 (UA/CRO)

• 문제/배경: 웹 방문자 및 오프라인 약국 방문객을 앱 설치 유저로 전환하는 연결 고리가 부족했으며, 리텐션 장치(만보기 등)를 다시 설계할 필요가 있었음.
• 기여:
  • [O2O] 약사 명함 QR → 앱 설치 → 단골 자동 등록 흐름에서 유저앱 단골 약국 랜딩, iOS PID 유실 시 fallback 화면, 에어브릿지 커스텀 도메인을 맡음(2025.10).
  • [Web-to-App] 의료상담·매거진 웹에 앱 설치 유도 장치(진료과목별 CTA, 상담 상세 중간 배너, 하단 배너, 전면 설치 모달)를 붙이고, 고정 Airbridge 링크를 콘텐츠·캠페인 파라미터를 붙이는 동적 링크 함수로 바꿔 페이지별 설치 성과를 나눠 보게 함(2025.02). 전역 모달에 의료상담 캠페인명이 들어가 다른 페이지 성과가 의료상담으로 잡히던 내 결함은 팀원이 고침.
  • [리텐션] 건강 룰렛을 랜덤박스로 바꾸는 화면(2024.12)과, 만보기 보상을 3단계 포인트(하루 60P)에서 5단계 랜덤박스 티켓으로 바꿔 단계마다 붙는 전면 광고를 하루 최대 3회에서 5회로 늘린 개편(2025.01)의 FE를 맡음. 같은 시기 확률표 개편(기획 PO, 세팅 BE)으로 뽑기 1회당 지급 포인트는 16.1P → 3.05P(−81%).
  • [리뷰] 리뷰 작성 시 영수증 인증을 선택 사항으로 변경하여 작성 허들 완화.
• 성과:
  • (PM 중간 집계, 에어브릿지) 약사 명함 배송 1주 47개 약국에서 클릭 88 · 설치 22 · 진료 19건. 에어브릿지 귀속 수치라 명함이 없었어도 생겼을 진료와 구분되지 않음.
  • 약국 리뷰 일평균 약 106건 → 정착 약 300~340건(약 3배), 내용 있는 리뷰는 약 48 → 300~340건(약 6~7배). 같은 기간 의사 리뷰(대조)는 소폭 감소. 초기 3주(일 약 620~670건)는 84~86%가 빈 리뷰여서 최소 15자 규칙을 넣은 뒤 정착.

6. 의사 온보딩 풀퍼널 개편 (제휴 반자동화 → 가입·제휴 UX와 퍼널 로그 복구 → 진료 세팅 ON 튜토리얼)

• 메타: 2025.06 ~ 2026.03 · 의사웹·CS 어드민 FE 단독(기획·스펙 PO, 디자인·BE·운영 협업) · Next.js(의사웹), React(CS 어드민), GraphQL, React Hook Form·Zod, Firebase Analytics(GA4)
• 2025.Q2 — 의사 제휴 반자동화 (가입과 제휴 신청 분리, 셀프 신청·반려 사유 안내):
  • 문제/배경: 가입과 제휴가 한 단계로 묶여 있고 서류 확인·반려 안내를 운영이 수동으로 처리했음(운영 경험치 “최소 1주 + 반려 시 최대 1주 더”).
  • 기여:
    • 회원가입과 제휴 신청 단계를 분리하고, 필수 서류 제출 및 반려 사유 안내 기능을 시스템화.
    • 제휴 신청 페이지에 단계별 진행 카드와 신청 완료 카드를 두고, CS 어드민에서 사유를 골라 반려하면 의사웹에 반려 사유가 보이게 함.
  • 성과: 출시 후 5주(첫 신청 2025-06-24~07-31, n=69) 신청 완료 → 첫 승인 평균 9.8일·중앙값 1.8일. 반려 없이 승인된 의사는 평균 2.8일, 반려 후 승인은 15.4일이라 평균은 반려가 끌어올림. 반자동화 이전 값은 로그가 없어 개선폭은 주장하지 않음.
  • 한계: 2025-06-19 배포에서 내 경로 이동이 다른 PR과 충돌해 빌드 실패·revert 2회, 같은 날 밤 새 제휴 상태 때문에 간호사 계정이 의사웹을 못 쓰는 장애가 남.
• 2026.Q1 — 가입·제휴 UX, 퍼널 로그 복구, 진료 세팅 ON 튜토리얼:
  • 문제/배경: 의사 회원가입 후 실제로 진료 가능한(Accessible) 상태로 전환되는 비율이 PO 기준 25~33%에 머물렀고, 샘플 처방전 양식 문제를 등록 때 알 수 없어 운영팀이 따로 연락해야 했음.
  • 기여:
    • 가입·제휴·튜토리얼 스펙(PO)의 의사웹 FE를 단독 구현(PR 20건): 가입 순서 변경, 제휴 4단계 검증, 모바일 반응형·LNB 재구성, 네이버 플레이스·OCR 프리필.
    • 먼저 로그인 전 퍼널 로그가 1년 가까이 비어 있던 원인이 내 코드임을 찾아 공개하고, 알림을 깨뜨리지 않도록 Analytics와 FCM 초기화를 나눠 복구. 튜토리얼은 단계별 URL로 설계해 이벤트 없이도 퍼널이 나오게 함.
    • 샘플 처방전 결과를 필수 미통과(실패) / 선택 미통과(경고) / 전체 통과로 나눠, 선택 조건만 못 맞춘 의사는 바로 다음 단계로 가게 함(조건 변경 PO, 상태값 BE).
  • 성과:
    • 배포 후 약 1주 튜토리얼 진입 21명 중 시작 20명(95%), 진료 세팅 완료 17명(81%) (PO 집계).
    • 가입 월 코호트의 가입 → 진료 가능(Accessible) 전환율 개편 전(11~2월) 27~36% → 개편 후(4~6월) 50~54%. 대조군이 없고 3월부터 가입 코호트 구성과 동시 변경(OCR 프리필·재승인)이 겹쳐 개편 효과만 분리하지는 않음. PO 목표 55%(내 제안으로 60 → 55 조정)에는 못 미침.
    • 월 Active 의사(그 달 진료 완료) 1~2월 573·583명 → 5월 828명. 2025-10 부터 오르던 추세이고 기존 의사를 포함한 총량이라 개편 효과로 귀속하지 않음.

7. 의약품몰 입점몰 전환 (셀러 도메인 → 3섹션 재편 → 입점사 상품 벌크 등록) (FE+BE)

• 메타: 2026.05 ~ 2026.08 · FE+BE 단독 구현(기획 PO, BE 리뷰·디자인·운영 협업) · Kotlin/Spring(general·pharmacy·cs·bff GraphQL), Postgres jsonb, Kafka, S3, React(약사웹·의사웹·CS 어드민)
• 2026.Q2 — 1단계: 입점사(셀러) 도메인 도입:
  • 문제/배경: 직영몰 구조 + Fancy UI가 약사의 실사용 맥락과 불일치했고, 닥터나우방지법 대응 차원에서 의약품 도매업이 독립적으로 매출을 낼 기반이 필요. 직영몰 → 입점몰 전환의 1단계.
  • 기여:
    • FE: 상품 리스트·상세·장바구니·주문서에 입점사 로고/이름 노출, 전체상품 페이지 입점사별 필터 구현 (URL query 기반, 전체 선택 시 필터 미적용 처리).
    • BE(Kotlin/Spring): wholesaleSellers 쿼리 및 sellerIds 검색 필터 추가, 셀러 로고 S3 이미지 노출, BFF GraphQL 스키마 반영.
  • 성과: 셀러 지정 05-19 · 입점사 노출·필터 06-02 · 랭킹 06-04 운영 배포, 착수 약 3주 만에 1단계 완료. 입점사 필터 사용자의 결제 버튼 클릭 비율 42%(미사용자 4.5%, 배포 직후 14일, 당시 대시보드 확인).
• 2026.Q3 — 2단계: 3섹션 입점몰 재편 (FE+BE):
  • 메타: 2026.07 · FE+BE 단독 구현(BE 리뷰·디자인 협업) · Kotlin/Spring(general·pharmacy·bff GraphQL), Postgres jsonb, React
  • 문제/배경: 규제로 직매입 도매가 종료 수순에 들어가 입점 생태계로 전환해야 했음. 기존 화면은 직영몰 전제의 목록이라 같은 약을 여러 입점사가 팔아도 비교할 수 없었음.
  • 핵심 판단: 검색 인덱스는 공용 커머스 서비스에 도메인을 모르는 제네릭 테이블로 두고, 약품 판단(단품은 여러 입점사를 한 행으로 묶고 세트·비약품은 상품 단위)은 약국 도메인 서비스가 소유. 초기 설계가 도메인 누출 구조라 리뷰 후 전면 폐기하고 다시 짬. 기존 장바구니 스펙을 쓰는 화면을 깨지 않으려고 장바구니 V2 를 신설하고 FE 는 한 번에 V2 로 이관.
  • 기여: 검색 · 입점사별 비교 · 장바구니 상시 임베드의 3섹션 화면, 제네릭 검색 인덱스와 이벤트·전량 리빌드 동기화, 1섹션 기본 할인가 노출(특가 누출을 막는 additive 조회), 이관 중 유실된 최소주문 불변식 복원.
  • 성과: 착수 약 3주 만에 FE·BE 동시 출시. 재편 후 4주 약사웹 주문 +9.3% · GMV +35.6% 였지만 재편하지 않은 의사웹도 +28.4% · +56.9% 늘어 재편 효과로 주장하지 않음. 이 작업의 가치는 규제 대응 구조 전환을 짧게 낸 데 있음.
• 2026.Q3 — 입점사 상품 엑셀 벌크 등록 (FE+BE):
  • 메타: 2026.07 · FE+BE 단독(운영팀과 요구사항 합의) · Kotlin/Spring, Kafka, S3 presigned URL, React(CS 어드민)
  • 문제/배경: 입점몰 전환으로 도매상·제약사 상품을 대량으로 받아야 했음(종합도매 취급 상품 2~3만 개). 단건 등록으로는 입점사 온보딩이 막혔음.
  • 핵심 판단: 개발 전에 운영팀과 범위를 합의(추가 전용, 입점사별 파일, 1회 1,000행으로 시작, 실패 행만 재등록). 기존에 운영 중인 약품 일괄등록 패턴을 미러링해 리스크를 낮춤.
  • 기여: S3 직접 업로드 → 결과 테이블 → Kafka 비동기 → 행별 독립 트랜잭션으로 단건 등록 재사용 → 상태 조회 화면. 출시 직후 운영 QA 피드백(배송소요일·노출여부 컬럼)과 벌크 상품만 결제에 실패하던 결함(썸네일 저장 방식)을 수정.
  • 성과: 착수 약 2주 만에 출시. 업로드 36행 중 32행 성공(실패 행만 재등록). 같은 기간 약사웹 신규 도매 상품 32개가 전부 벌크로 들어와 입점사 상품 등록 경로가 됨.

8. 도매 재입고 알림 (FE+BE)

• 문제/배경: 품절 상품에 대한 잠재 수요를 데이터로 축적할 수 없고, 재입고 시 타이밍 기반 판매 촉진이 불가능했음.
• 기여:
  • BE: RestockAlert aggregate 설계 (한도 20개·미노출 상품 차단 invariant), 재고 0→1+ 변경 시 Kafka 발행(AFTER_COMMIT), 컨슈머에서 카카오 알림톡 발송, 결제 완료 시 자동 해제, 60일 만료 배치.
  • FE: 의사웹·약사웹 신청/해제/재신청 퍼널 + 알림 내역 페이지 구현, 알림 내역 리스트의 상품 정보를 단일 쿼리로 통합, Suspense 스켈레톤 적용.
  • 트러블슈팅: 데브존 정상·운영 미발송 이슈에서 Redis dedupe 가설을 검증·기각한 끝에 notification_template의 content가 운영 DB에서 NULL임을 발견·해결.
• 성과:
  • 분기 말(2026-06-30) 누적 신청 157건(신청 약국·병원 103곳), 알림 발송 62건. 알림 후 구매 전환은 조인 키 마스킹으로 측정하지 못함.

9. 도매 구매 정책: 수량 조건 할인 + 최소/최대 구매 수량 (FE+BE)

• 문제/배경: 낱개 판매 시 적자인 의약품 존재. 최소구매금액(7만 원)을 1개씩 다양한 상품으로 채우면 적자 주문이 발생 → n개 이상 구매를 유도할 장치 필요.
• 기여:
  • BE: ConditionType(수량 조건) enum 도입, 체크아웃/주문 시 실제 수량 기반 할인 필터링, 최소/최대 invariant 검증, 전 레이어 DTO/GraphQL 반영.
  • FE: 어드민 정책 설정 UI, 수량할인 뱃지·할인 혜택 섹션, 장바구니 수량 조건 충족 시 할인가 자동 반영, 최소/최대 stepper clamp + 주문 차단 alert.
• 성과:
  • 적용 상품(트레인연질캡슐) 전후 4주 6개 이상 주문 88 → 266건(주문 중 24% → 81%), 5개 주문 162 → 19건, 판매 개수 +9.1%. 주로 5개 → 6개 구성 이동이며 단일 상품·대조군 없음, 목적이던 마진은 재지 못함.

10. 다이어트 원외처방 지도: 총액 표기와 가격 근거 A/B 연작

• 메타: 2026.08–09 · FE 단독(실험 설계·구현·판정·정리), PO·디자인·BE·법무 협업 · Next.js, GrowthBook(Bayesian), GA4/BigQuery
• 문제/배경: 원외처방은 결제 전까지 진료비와 약제비를 합친 총액을 알 수 없어 이탈한다는 가설이 있었음. 지도에는 진료비만 보였고, “원외가 최저가”라는 전제도 실측과 반대였음(위고비는 원내가 17~46만 원 저렴).
• 핵심 판단:
  • 법무 검토(“추천이 아니라 단순 가격 표기”, 조제비 → 약제비 용어)를 표기 규칙으로 삼음. 클러스터마다 중앙값을 보여 주는 안은 서버 비용이 커서, 클러스터 제거를 제안해 BE 작업을 0으로 만듦.
  • “처치를 본 사람만 분모에 넣는다”: 노출 시점을 카드 오픈 → 지도 진입으로 옮기고, 대조군까지 바뀐 구간은 seed 를 유지한 채 봉인·재시작.
  • 판정 근거를 숨기지 않음: 처치 이전 단계 지표가 오른 결과는 집계 아티팩트로 판정해 성과에서 제외하고, goal 이 아닌 보조 지표로 채택한 경우 그 한계를 결과 기록에 명시.
• 기여:
  • 한 달간 A/B 5건(총액 표기 · 가격 위계 · 인근 약국 가격 근거 · 마커 표기 단위 · 근거 상시 노출)과 약국찾기 → 원외 지도 유입 배너를 설계·구현·판정하고 실험마다 코드 정리 PR 을 분리.
  • 카드 총액과 약국 가격 리스트가 같은 값을 쓰도록 이상치 하한 가드를 공용 모듈로 추출.
  • 유입원 파라미터를 필수 인자로 만든 순수 함수로 계측 누락을 컴파일 단계에서 차단.
• 성과:
  • 인근 약국 가격 근거 노출 A/B: 진료신청 완료율 12.12% → 13.36% (상대 +10.2%, B안이 나을 확률 97%, n=11,349 · 보조 지표 기준 채택).
  • 같은 기제의 상시 노출 A/B 에서 +4.46% 로 방향 재현, 반대로 한 걸음 더 나간 “기본 펼침”은 지도 탐색을 잠식해 기각. 세 실험을 이어 읽어 “보여 주기와 펼쳐 두기는 다르다”는 결론.
  • 후킹 배너 배포 3시간 유저 CTR 22.6%, 배너 클릭 → 원외 지도 도달 98.4%.
  • 같은 원칙으로 설계한 탈모약 용량 기본 선택 A/B 는 goal(선택 완료율)에서 B안이 나을 확률이 99.97% 였지만, 설계 시점에 “탭 1회 제거로 기계적으로 오른다”고 적어 둔 대로 하류 전달이 없었고 가드레일(저용량 선택 비중 −45%)이 훼손돼 기각. 이긴 것처럼 보이는 실험을 기각한 사례.

11. 의사웹 진료보드 30초 자동 갱신 (직접 발의)

• 메타: 2026.08–09 · FE 단독(제안·구현·측정) · React Query v4, Datadog APM
• 문제/배경: 의사 피드백 “PC 를 양쪽에서 사용하면 새로고침이 안 돼서 불편해요”. 진료보드는 첫 진입 때만 조회했고 창 포커스·푸시 알림에도 갱신되지 않았음.
• 핵심 판단:
  • 페이지 새로고침 대신 보드 쿼리만 주기 재조회. 주기는 레퍼런스 조사(칸반·모니터링 30초, 읽기용 대시보드 60초)에서 무응답 취소 마감이 있는 “작업 큐”에 맞춰 30초.
  • 폴링은 실패 빈도를 30초에 한 번으로 올리므로, 캐시가 있으면 에러 화면으로 던지지 않도록 경계 정책을 먼저 바꿈(폴링 영구 정지 방지).
• 기여: 활성 탭 한정 폴링, 상태 칩, 에러 경계 정책 변경. 배포 후 부하를 실측해 켜둔 채 떠난 탭의 야간 폴링을 발견하고, 진료시간 밖 정지 + 조회 실패 시 fail-open 으로 후속 수정.
• 성과: 보드 쿼리 평일 총량 약 4.3배 증가에도 해당 BFF p95 103 → 84ms. 야간(00~06시) 보드 쿼리 12,512 → 약 4,200건/밤(−66%).

12. 도매 전용 비즈머니 신설 (BE)

• 메타: 2026.09 · BE 구현(PO·CTO·운영·회계·법무 합의) · Kotlin/Spring Boot(payment·pharmacy·hospital·bff), Aurora MySQL, OpenAPI 생성 클라이언트
• 문제/배경: 도매몰 전용 선불 지갑이 필요했음(충전 보너스로 구매자 추가 할인, 정산예정금 환전분으로 현금 없이 구매). 기존 비즈머니는 광고용 하나였고 “도매 비즈머니는 절대 광고에 쓰이면 안 된다”가 하드 제약.
• 핵심 판단:
  • 충전 한도는 호출자가 싣지 않고 서버가 지갑 종류로 정책을 고르며, 모르는 종류는 거절.
  • “안내한 보너스를 그대로 준다”는 약속을 지키려고 발급 시점에 보너스 금액과 만료일수를 스냅샷.
  • 배포 순서는 “구버전이 새 상태를 만나면 깨지는가”로 결정: DDL 선행, producer-first, 새 enum 값만 먼저 운영 배포.
• 기여: 종류별 충전 정책, 전용 PG 가맹점 분리, 발급 시점 스냅샷과 유효기한 NOT NULL 전환, 원 충전분으로 되돌리는 사용 반환·사용 삭제, 약국 충전·환전 진입점(런타임 킬스위치, 조회 실패 시 열림).
• 성과: 3주간 서비스별 운영 배포에서 매 릴리스 10분 관찰 5xx 0%, 롤백 0. 도입 과정의 틀린 가설 2건(빌드 타임 스펙 차이, Aurora reader 의 온라인 DDL 구간)을 스스로 정정·기록.

13. 비제휴 약국의 도매 전용 가입 (FE+BE)

• 메타: 2026.06–08 · FE+BE 단독 · Kotlin/Spring(pharmacy·bff·cs), React
• 문제/배경: 의약품몰은 비대면 진료 제휴 약국만 쓸 수 있었음. 제휴 없이 도매만 쓰는 약국을 받아야 했음.
• 핵심 판단: 1차로 가입 타입 컬럼을 두고 화면에서 막았으나, 컬럼은 인가를 강제하지 못해 API 직접 호출을 막을 수 없었음 → 이틀 만에 서버 Role 기반 인가로 전환.
• 기여: 신규 계정 Role 과 리졸버 단위 인가, 가입 신호 배선, CS 대리 로그인 토큰의 역할 오류 수정, 이미 동의한 약관을 다시 묻던 재동의 흐름 정리, 가입 약국 대시보드를 주문 중심에서 회원 중심으로 재편.
• 성과: 분기 도매 전용 가입 15곳(전원 당월 승인). 가입 퍼널 수치(8월 가입 버튼 클릭 20명 → 실가입 1명)를 드러내 다음 병목이 가입 과정임을 보임.

1. 정산 예정금 활용 유도 및 현금 흐름 개선

• 문제/배경: 정산예정금을 도매 결제에 쓸 수 있게 된(2025-05-19) 뒤 사용을 늘릴 필요가 있었음(릴리즈노트 기대효과 “PG 수수료 절감”, 절감액 계산은 없음).
• 기여:
  • 정산예정금 결제가 열린 뒤 도매 주문서·GNB·대시보드·정산 내역에 안내와 [항상 전액 사용] 토글을 붙이고, PM이 효과를 볼 수 있게 노출·클릭 로그 7종을 심음(FE 단독, 약 2주).
• 성과:
  • 넛지 전후 3주 첫 구매 약국 중 정산예정금 사용 42.0% → 60.0%(69곳 → 70곳 기준), 도매 결제 주문 중 사용 비중 주 24.5~28.8% → 29.4~31.9%. 대조군이 없고 주 20곳 안팎의 소표본이며, 목표였던 신규 구매 약국 수는 늘지 않음(PM 판단).

2. 약국 CRM 웹푸시와 약품 가격 입력 개선

• 문제/배경: CS 어드민에서 약국에 도매 마케팅 웹푸시를 보낼 화면이 필요했고(외부 CRM 도구 연동 대신 자체 웹푸시로 전환), 약국은 약품 규격마다 가격을 따로 입력하고 있었음.
• 기여:
  • CS 어드민 약국 CRM 웹푸시 발송 화면(대상 4종 선택 + 상품 ID, 제목·본문·CTA)과 약사웹 수신 처리.
  • 2024.12 약사웹 약품관리: 약사 인터뷰를 바탕으로 약품 개별 등록 때 최소 규격 단가 하나만 넣으면 모든 규격 가격이 배수로 채워지게 하고, 규격별 판매/판매중지·첫 진입 튜토리얼·엑셀 업로드 가이드를 붙임.

3. 배포 워크플로 Slack 시작·완료 알림 (직접 제안)

• 문제/배경: 배포 시작 후 GitHub Actions 워크플로우 화면을 직접 확인해야 완료 시점을 알 수 있었고, 장애 발생 시 어떤 배포가 언제 완료되었는지 파악하기 어려웠음.
• 기여:
  • 5개 운영 배포 워크플로에 시작·완료 알림을 한 쓰레드로 붙임(쓰레드용 봇 토큰은 CTO의 기존 봇 것을 받음).
  • PR 정보, 서비스명, 리포지토리 정보를 알림에 포함하여 컨텍스트 즉시 파악 가능.
  • 알림 스텝 오류가 배포를 막아 동료가 세 번 되돌린 원인(따옴표 JSON 깨짐, 멀티라인)을 차례로 고치고 payload 테스트·CI·dry-run으로 막음. 2026.Q3 데브존 배포 알림도 워크플로 안으로 옮김.
• 성과:
  • 배포 1건이 채널 메시지 1개(시작과 결과를 한 쓰레드)가 되고 배포 시각이 디버깅 기준으로 남음. 시간 단축 효과는 재지 않음.

4. Jira 미완료 버그 Slack 리마인더 (Vitamin, Spring Boot/Kotlin)

• 문제/배경: Jira에 등록된 버그 이슈가 해결되지 않은 채 방치되는 경우가 발생하여, 팀 내 버그 해소 속도가 느려지는 문제가 있었음.
• 기여:
  • Spring Boot/Kotlin 기반의 내부 도구(Vitamin) 프로젝트에서 Jira API와 Slack API를 연동한 자동 리마인더 기능 개발.
  • 평일 09시 미완료 Bug·Sus 티켓을 조회해 개발자가 많이 보는 공용 채널에 게시. 발권은 Slack 워크플로(/버그버그·/서스서스)로 Slack 안에서 닫음.
• 성과:
  • 서비스 계정 인증·상태 필터·총 건수 고정(100건) 버그를 직접 풀어 Kotlin 봇으로 운영.

5. CS API 앱 버전 관리 어드민 메뉴 구축

• 문제/배경: 앱 버전별 호환성 관리와 강제 업데이트 정책을 수동으로 처리하고 있어 운영 비효율이 존재.
• 기여:
  • 운영 DB를 직접 고쳐 관리하던 앱 최소·최신 버전을 CS 어드민 메뉴(개발자 권한)로 옮김. 앱 버전 도메인은 FE 그룹 BE 스터디 공동 작업을 마무리해 운영 배포했고, cs-api 메뉴·조회 API와 어드민 화면은 단독.
  • 이어 온콜로 반복되던 유저 결제수단 삭제를 cs-api·payment-api부터 화면까지 FE+BE로 냄(2026.03).
• 성과:
  • 앱 버전 등록과 결제수단 삭제 사용 횟수는 재지 않음.

6. 제품개발 위클리 인사이트 루틴 (직접 발의)

• 메타: 2026.07– · 단독 발의·운영 · Claude 스킬, Redash, 사내 위키(지표 정의), Slack
• 문제/배경: 사내 지표·알림은 많았지만 “지난주 무엇이 움직였고 무엇을 해야 하나”를 매주 정리하는 사람이 없었음.
• 핵심 판단: 일간으로 시작했다가 신호가 약해 일주일 만에 주간으로 전환. 해석만이 아니라 실행 규모와 검증 기준(A/B 설계·승격 조건·기간)까지 붙여 바로 티켓으로 옮길 수 있게 하고, 확정되지 않은 지표 정의는 잠정치로 표기.
• 기여: 조직 Q&A 에 데이터로 답하고, 지표 변화 해석·VoC·외부 시그널을 매주 발행. 데이터 품질 결함(유입 유형 enum 오작동, 광고 쿼리 보존 구조 문제)도 리포트로 드러냄.
• 성과: 8주 연속 발행(누락 0). 리포트를 근거로 PO 가 홈 광고 지면 비용 분석과 광고 리포트 개선에 착수.

1. 도메인 주도 Micro FSD, 컨벤션 설계부터 약사웹·의사웹 전환 완료까지

• 메타: 2025.10 ~ 2026.01 · 직접 발의, 컨벤션 설계·이관 단독(리뷰와 규칙 논의는 FE 리드·CTO) · React(Vite)·Next.js, TypeScript, FSD 변형, madge, Biome, GraphQL codegen
• 2025.Q4 — 컨벤션 정의와 약사웹 전환:
  • 문제/배경: 초기 FSD 도입 후에도 서비스 복잡도가 증가하면서 도메인 간 결합도가 높아지고, 서버 스키마 변경이 UI에 직접 영향을 주는 문제 발생.
  • 기여:
    • Micro FSD 정립: 기존 FSD를 도메인 중심으로 재해석하여 Slice 간 직접 참조를 금지하고 index.ts를 통한 Public API 사용을 강제.
    • ACL(Anti-Corruption Layer) 도입: entities 레이어에서 서버 데이터를 UI 전용 모델로 변환하여 서버 변경의 여파를 차단.
    • 순환 참조 방지: 도메인별 entities와 도메인 간 entities 조합의 순환 참조를 madge로 검사해 CI를 실패시키는 스크립트(pnpm check:circular). views·widgets·features 규칙은 문서로만 둠.
  • 성과: 약사웹 src 최상위 폴더 21개 → 3개(PR 5건, 2025-12-12 완료), 의사웹은 도메인 13개를 2~3개씩 끊어 1차 이관. 이관으로 낸 부작용 3건(본인 PR 원인)은 모두 당일 수정. 유저웹 이관은 내 제안으로 팀원에게 인계.
• 2026.Q1 — 의사웹 최종 이관:
  • 문제/배경: Micro FSD 아키텍처 전환이 약사웹에서 먼저 완료되었으나, 의사웹은 규모가 더 크고 레거시 코드가 많아 마이그레이션이 지연되고 있었음.
  • 기여: 레거시 폴더 18개를 app·domains·shared 3개로 옮기는 1,186개 파일 변경(이름 변경·삭제 포함) 단일 PR을 segment 규칙 합의, 데브존 CUJ QA, 즉시 revert 준비, 배포 후 30분 관찰을 거쳐 롤백 없이 반영(2026-01-13).
  • 성과: 의사웹 src 최상위 폴더 18개 → 3개로 약사웹·의사웹 100% 전환. 온보딩·리뷰 효율 변화는 재지 않음.

2. FE 모노레포 NX·yarn → pnpm workspace 전환 (직접 발의)

• 문제/배경: 2024-09에 만든 NX 모노레포가 호환 문제로 5개 앱 빌드를 제대로 받치지 못해(“지금은 가짜 모노”), 패키지 매니저만으로 모노레포를 다시 세우자고 제안(2025-01-06).
• 기여:
  • yarn workspaces의 hoisting 충돌을 확인한 뒤 pnpm으로 옮기고, RN 앱 때문에 node-linker=hoisted를 쓰면서 약사웹 React 17/18 충돌은 빌드 설정으로 격리해 5개 앱 빌드를 복구.
  • CI/CD를 pnpm·lock 해시 캐싱으로 바꿈(전환 PR 작업 커밋 147개 중 본인 76개, 코드푸시 CLI 전환·release 머지는 팀원).
• 성과:
  • 5개 앱(유저앱 iOS·Android, 유저웹, 약사웹, 의사웹, CS) 빌드 green. CI 시간 전후는 실행 기록 만료로 재지 못함.
• 한계: 전환 직후 내 커밋에 섞인 로컬 설정이 유저앱 스플래시 멈춤 장애를 냄(2025-02-27).
• 2026.Q3 — 패키지 경계 규칙 (libs 6개 → packages 3개):
  • 메타: 2026.08–09 · 단독 · pnpm workspace, biome, Vitest
  • 핵심 판단: “새 패키지는 기존 패키지에 없는 의존이 있을 때만”이라는, package.json 두 줄로 판정되는 규칙을 세우고, 관심사는 패키지가 아니라 exports 서브패스로 엶. 전용 검사 스크립트 없이 기존 게이트(pnpm-workspace 목록, biome)에 얹음.
  • 기여: 순환 참조 사고의 통로였던 배럴 re-export 금지 규칙 수립(에이전트가 규칙 정본을 읽도록 강제하고 실제 서브에이전트로 준수율 검증), libs 통합, 첫 적용으로 공용 QueryBoundary 를 core 서브패스로 열어 의사웹 경계 30곳 이관.
  • 성과: 의사웹 “다시 시도”가 요청을 만들지 않던 결함 해소(클릭 후 요청 발생 비율 46% → 100%, 표본 19). 재사용 가치가 큰 함정 3건(biome override 가 같은 룰을 통째로 덮음 등)을 프로브로 확인해 문서화.

3. 유저웹 SSR 의 BFF 호출 DNS 캐싱과 ECS private subnet 전환 (CTO 과제 자원)

• 문제/배경: AWS ECS 환경에서 Next.js 서버가 BFF를 호출할 때 매 요청 DNS 조회가 SSR 응답 지연의 변동 요인으로 지목된 CTO 긴급 과제에 자원.
• 기여:
  • Node.js 프로세스 레벨에서 cacheable-lookup를 활용한 인메모리 캐싱 레이어 구현 (TTL 준수).
  • Axios/Fetch 레이어에 커스텀 리졸버를 주입하여 캐시 우선 조회 로직 적용.
  • 유저웹 ECS 태스크의 private subnet 전환은 별도 검증 환경을 먼저 세워 Datadog 수집 영향을 확인한 뒤, 운영은 기존 LB를 그대로 두고 서브넷·퍼블릭 IP 설정만 바꿈.
• 성과:
  • 데브존 24시간 캐시 히트율 91.76%(279건, 히트 평균 0.457ms · 미스 평균 9.31ms). 개발 환경(로컬 개발 서버 로그)에서는 DNS 조회 44ms → 0~1ms. 운영 DNS 로그는 비용 문제로 제거돼 운영 효과는 재지 못함.

4. 약사웹 CI 테스트 9분 → 약 12초 (CI 실행 중앙값 645 → 92초)

• 문제/배경: 모노레포 내 테스트 코드 증가로 CI 실행 시간이 9분을 초과하여 배포 병목 발생.
• 기여:
  • 테스트마다 dayjs를 무겁게 초기화하던 날짜 유틸을 찾아 전역 mock으로 바꿈(하루 작업, jest 설정·mock 3파일).
  • 같은 날 CRA → Vite 전환을 기술과제로 등록.
• 성과:
  • 테스트 단계 약 9분 → 약 12초(PR 실행 1건, 팀원이 Actions 화면으로 확인). CI 실행 시간 중앙값 645초 → 92초(설치·린트 포함 전체, 전 19회 · 후 52회, 재측정).

5. 디자인 시스템(DDS): Tailwind 기반부터 공통 패키지화, 오너십까지

• 메타: 2024.11 ~ 2026.09 · 2024.12 킥오프 참여, 2025 공통 모듈화·라이브러리화·운영 적용 담당, 2026.Q3 DS 오너 · React, Tailwind CSS, Radix UI, Storybook, pnpm workspace
• 2024.Q4 — Tailwind 토큰과 킥오프:
  • 문제/배경: 앱마다 styled-components 테마와 초벌 컴포넌트가 따로 있어 같은 UI를 여러 번 만들고 있었음.
  • 기여: 2024.12 킥오프에 참여하고, 입사 첫 주 약사웹 Tailwind 토큰·cn 유틸 기반을 깔아 이후 의사웹·DDS 패키지가 같은 토큰을 쓰게 함.
  • 한계: 2024-12-19 유저웹 Tailwind 도입 때 preflight를 끄지 않아 전역 스타일 변동(본인 원인, 다음 날 복구).
• 2025.Q2 — libs/ui 라이브러리화:
  • 기여: 유저웹 초벌 컴포넌트를 모노레포 공통 패키지(libs/ui)로 분리·라이브러리화하고 배포 파이프라인에 올려 유저웹·약사웹 운영에 적용, 본인 담당 컴포넌트 9종(버튼·토글·라디오·입력·드롭다운·체크박스·바텀시트·액션시트 등).
  • 성과: 분기 말 DDS import 파일 유저웹 66 · 약사웹 39 · 의사웹 17(의사웹 적용은 팀원).
• 2025.Q3~Q4 — 스토리북 호스팅 이관과 Tabs·Chip: 스토리북 호스팅을 고정 도메인으로 이관(2025.Q3), Tabs·Chip 컴포넌트 구현(2025.Q4).
• 2026.Q3 — DS 오너십: 신규 컴포넌트 5종과 발굴·측정 체계:
  • 메타: 2026.07–09 · DS 오너(FE 리드로부터 이관), 디자이너 협업 · React, Radix UI, Storybook
  • 핵심 판단: API 는 실사용 분포에서 결정(Skeleton size 5단계, Modal size 3단계, 소수 사례는 Rule of Three 로 배제). Modal(제목 필수) / Overlay(라벨 필수) 경계로 이중 카드를 구조적으로 차단. 채택률은 계열 편입·오집계 수정 때마다 기준선을 의도적으로 끊어 부풀림을 없앰.
  • 기여: Accordion · Skeleton · SideNavigation · Modal/Overlay · Tooltip 신설, 에이전트용 기계가독 매니페스트 + drift 게이트(유령 컴포넌트 3건 제거), 반복 구현을 찾는 발굴 스킬, 소비 앱 CI 트리거와 쌓임 순서 e2e 단언.
  • 성과: 아코디언 중복 구현 7종 → 1종. 8월 DS 신설 4건이 전부 발굴 스킬의 제안 티켓에서 출발. styled-components → Tailwind 전환율 75% → 95%(야간 루틴 포함).

6. TanStack Query v4 단일화와 QueryClient 설정 통일

• 메타: 2025.03 ~ 2026.05 · 유저앱 통합과 QueryClient 팩토리는 단독, 약사웹 CS 대응은 FE 팀 협업 · TanStack Query v4, React Native, React(CRA), pnpm 모노레포 libs/query, Datadog
• 2025.Q1 — 유저앱 v3·v4 QueryClient 통합:
  • 기여: 유저앱에 겹쳐 있던 v3·v4 QueryClient를 통합(import 95줄·103파일). 통합 배포 당일 내 PR이 낸 의사 리스트 로딩 무한 회귀(팀원 선롤백)의 원인을 v4의 isLoading 의미 변화로 찾아, 로딩 판정 규칙(keepPreviousData는 isInitialLoading, 그 외 isLoading과 isFetching을 함께)을 정해 당일 재배포.
• 2025.Q2 — 약사웹 ‘로그인 안 됨’ CS와 v4 단일화:
  • 문제/배경: React Query v3/v4 혼용으로 인한 컨텍스트 충돌 및 네트워크 불안정 시 데이터 동기화 오류 발생.
  • 트러블슈팅(발단): CS로 접수된 약사웹 ‘로그인 안 됨’이 로컬에서 재현되지 않아 FE 팀이 약국 PC 원격 점검에 나서 함께 원인을 파악했고, 나는 재현 스텝과 Datadog 실패 이력을 맡음. 로그인 뮤테이션만 codegen 생성 v4, 수기 훅 20개는 v3인 혼용을 확인. v4 기본값(online)에서는 네트워크가 끊겼다고 판단하면 요청을 보내지 않아 사용자도 개발자도 피드백을 받지 못함. 실제 원인은 약사 PC 네트워크였고(재부팅으로 해결) 혼용이 추적을 헷갈리게 함.
  • 기여:
    • 즉시 조치: 로그인 실패가 화면에 보이도록 에러 토스트를 붙임. 운영 첫 networkMode: 'always' 핫픽스는 팀원이 먼저 배포.
    • 장기 후속: 약사웹 v3를 걷고 networkMode: 'always'로 통일(2025.Q2). 유저앱(2025.Q1)과 함께 혼용이 남은 앱을 v4 하나로 합쳤고, CS 어드민은 이후에도 v3.
  • 성과: 약사웹 v3 제거 뒤 같은 CS 스레드 추가 인입 없음(이후 재발 조사는 안 함).
• 2026.Q2 — QueryClient 설정 통일:
  • 기여: QueryClient 글로벌 설정 통일: libs/query 팩토리 패키지 신설, suspense/useErrorBoundary를 타입 레벨(Omit)에서 글로벌 설정 차단, staleTime 30초 글로벌 기본값과 티어드 상수 도입. 3안(Infinity 캐시 / 30초 / 30초 + 티어) 비교로 refetchOnMount 유지안 채택.
  • 성과: BFF 호출량은 평일 기준 지속 감소 신호가 없어(트래픽 미통제) 효과를 주장하지 않음.

7. 서버 요청 디바운스(Debounce) 인스턴스 초기화와 참조 불안정 해결

• 문제/배경:
  • 즉각적인 반응을 위해 lodash.debounce에 { leading: true, trailing: false } 옵션을 적용했으나, 의도(첫 요청 후 대기)와 달리 매 입력마다 서버 요청이 발생하는 문제가 발생.
  • 원인: React 컴포넌트가 리렌더링될 때마다 핸들러 함수가 새로 생성되면서, 디바운스 인스턴스도 함께 초기화되어 내부 타이머가 유지되지 않고 매번 ‘새로운 첫 요청’으로 인식됨.
• 기여:
  • 참조 무결성 확보: useCallback으로 디바운스 인스턴스가 리렌더 사이에 유지되게 함.
  • Stale State 방지: 최신 상태값을 클로저가 아닌 함수 인자로 전달받도록 구조를 개선하여 참조 안정성과 데이터 최신성을 동시에 확보.
• 성과:
  • leading: true가 의도대로 첫 클릭 후 차단하게 고침(약사웹·의사웹 2025.06, 유저웹 6곳·유저앱 2025.07~08). 요청 감소량은 재지 못함.
• 한계: 유저웹 첫 배포가 랜덤박스 미오픈 장애(CS 5건)를 내 당일 롤백하고 재수정함. 발단은 2025.Q1 따닥 대응 때 내가 컴포넌트 본문에 만든 debounce였음.

8. 검색 노출(SEO) 구조 개선

• 문제/배경: 비대면 의사 리스트가 쿼리 파라미터 URL이라 증상·과목별 페이지로 색인되지 않았고, 유저웹 랜딩은 정적 에셋 캐싱이 없어 Lighthouse 점수가 낮았음.
• 기여:
  • 비대면 의사 리스트의 쿼리 URL(?type=&id=)을 증상·과목별 경로 URL(/telemedicine/doctors/[type]/[id])로 바꾸고 기존 URL은 영구 리다이렉트로 보존. 카테고리 API 기반 동적 사이트맵을 만들어 서치콘솔에 제출(2025.09).
  • 의사 상세 페이지에 H1 태그 적용 및 메타태그(Title, Description) 동적 생성 로직 개선.
• 성과:
  • 정적 에셋 7일 캐시·mp4 지연 로드·preconnect/preload를 단계별로 적용해 Lighthouse 모바일 점수 34 → 53(lab 측정, 2025.11). 검색 노출·유입 변화는 재지 못함.

9. 알림이 안 온다는 문의에서 PWA 데스크톱 앱까지 (약사웹·의사웹)

• 메타: 2025.10 ~ 2026.02 · FE 단독(PWA 방식 제안·당일 프로토타입, 기획·QA는 PO, 디자인·테스트 알림 API는 디자이너·BE) · vite-plugin-pwa(Workbox), Firebase Cloud Messaging, Next.js(의사웹)·Vite(약사웹), GA4 로그
• 2025.Q4 — 약사웹 셀프 알림 테스트와 기본 알림음:
  • 기여: 약사 알림 미수신 문의에 셀프 알림 테스트·설정 가이드를 붙이고, 처방전 외 알림(테스트·CRM 등)에 알림음이 없다는 점을 직접 제기해 기본 알림음을 적용. 이후 VOC에서 “비활성 탭이면 OS 알림만 뜬다”는 브라우저 제약을 먼저 확인함.
• 2026.Q1 — PWA 데스크톱 앱 (방식 제안과 당일 프로토타입):
  • 문제/배경: 약국·병원이 조제·진료 접수 알림을 받지 못한다는 VOC가 이어졌음. 크롬 탭이 비활성·최소화 상태면 알림음이 나지 않고, PWA 앱은 백그라운드에서도 울리지만 앱을 켠 뒤 첫 클릭이 있어야 소리가 난다는 제약을 디자인·PO와 테스트로 확인. 경쟁사 PC 앱 공유 스레드(PO)에서 PWA 방식을 제안하고 당일 프로토타입을 올림.
  • 기여:
    • 약사웹·의사웹에 PWA(Progressive Web App) 설치 배너 및 데스크톱 앱 제공 기능 구현.
    • 알림 설정 가이드 UI 구축으로 사용자의 알림 권한 설정 유도.
    • 기존 FCM 서비스 워커를 PWA 서비스 워커에 합치고 레거시 워커 정리·중복 등록을 막음. 앱 재실행 뒤 첫 클릭 제약은 매일 알림 테스트 배너로 루틴화.
    • 설치·나중에 설치·알림 테스트 버튼 클릭 로그.
  • 성과: 약사웹(2026-01-22)·의사웹(2026-02-12) 출시. 약사웹 설치 버튼을 누른 약국 53.5%(2,143/4,005, 배포 후 직접 측정, 로그는 버튼 클릭만 잡아 실제 설치 여부는 아님). 약사 알림 미수신 문의(사내 CS·피드백 채널 기준)는 배포 전후 12주 23 → 15건이었지만 배포 전 안내 조치 때부터 줄기 시작했고 2026-08에 Edge·크롬 병용 문제로 다시 늘어 PWA 효과로 분리하지 않음.
  • 한계: 의사웹 설치 배너 로깅 작업이 2026-02 의사웹 접속 장애의 원인이 됨(기술 과제 #14).

10. 야간 AI 코드 품질 루틴 (스멜 리포트 봇 → 야간 무인 수정 → 루틴 4종과 팀 분담)

• 메타: 2026.01 ~ 2026.09 · 발의·설계·운영 단독(프록시 방식은 CTO 제안, 앱별 루틴 운영은 FE 팀원 분담) · SonarQube, GitHub Actions, Claude Code 스케줄 에이전트·스킬, AWS API Gateway + Lambda, Slack
• 2026.Q1 — 코드 스멜 리포트 봇과 수동 정리:
  • 문제/배경: 프론트엔드 모노레포의 코드 스멜을 정기적으로 확인하는 장치가 없어, 잠재적 버그(Code Smell)가 쌓이고 있었음.
  • 기여:
    • SonarQube 정적 분석 결과를 기반으로 BLOCKER/CRITICAL 이슈를 우선 해소하는 개선 작업 수행.
    • Daily Code Smell Report Slack 봇을 발의·구현해(우선순위 Top 10 + 소스 스니펫) 매일 팀에 공유.
    • Cognitive Complexity가 높은 함수들을 리팩토링함.
  • 성과: 봇 리포트 기준 FE 코드 스멜 1,812 → 1,731건(2026-02-10 → 03-20), BLOCKER 4 → 0(02-12), CRITICAL 200 → 122(03-20). 분기 말 1,331은 팀원 배치가 섞여 본인 몫으로 쓰지 않음.
• 2026.Q2 — sonar-fix 야간 무인 루틴:
  • 문제/배경: 코드 스멜 개선을 수동으로 반복하는 데 한계가 있어 무인 운영으로 전환이 필요했음.
  • 기여:
    • sonar-fix auto 모드 구현: safe 카테고리 룰만 자동 선정, 룰 5개/diff 1,500줄 상한, 브랜치 네이밍·PR 생성 자동화.
    • SonarQube 프록시 Lambda 구축으로 클라우드 실행 환경의 egress 제약 우회.
    • Claude 루틴 기반 야간 자동 실행, 사람 개입은 PR 확인·머지만 남김.
  • 성과: 분기 야간 루틴 PR 44건 머지(2026.Q2). 같은 분기 FE 코드 스멜 1,334 → 907은 팀 수동 정리·신규 유입이 섞여 루틴 효과로 쓰지 않음.
• 2026.Q3 — 루틴 4종 운영과 팀 분담:
  • 핵심 판단: 리뷰 적체를 속도 조절 장치로 씀(앱당 열린 PR 1건 상한, 열린 PR 이 있는 앱은 배출 스킵). “PR 이 한 사람에게 몰린다”를 사람 배분이 아니라 구조로 해결: 앱별 루틴을 앱 담당자 계정에서 돌려 리뷰 책임이 따라가게 함. 목적이 다른 두 루틴은 규칙도 반대(DS 수렴은 외형 차이가 SKIP 사유가 아님 / 스타일 전환은 시각 동일성 유지).
  • 기여: 구조적 리팩토링 리미터 해제(e2e 보유 앱), 오프라인 스키마 스냅샷, 가짜 마이그레이션 차단, “타겟 소진”이 사실은 원장이 큐를 먹고 있던 것임을 규명(배출 가능 잔량 2 → 185). 루틴이 낸 운영 회귀 3건(포털 마운트 시점, 접근성 이름, 쌓임 맥락)을 라이브러리 생명주기 수준에서 규명해 당일~익일 수정하고, 기존 e2e 가드가 못 잡던 사각지대까지 테스트로 막음.
  • 성과: 제 계정으로 머지된 분기 PR 352건 중 136건(38.6%)이 루틴 산출. MAJOR 이상 FE 코드 스멜은 첫 리포트 1,812건(2026-02) → 262건(2026-09-03, 분석 범위 변경 전 같은 기준, 팀 수동 정리 포함). 앱별 분담 후 팀원 2명이 각자 루틴을 운영(실행 보고 15회). 결제 차단 회귀는 제보 후 1시간 52분 만에 운영 배포.
• 2026.Q3 — 측정 정상화 (커버리지 0% 의 정체):
  • 핵심 판단: “0%“는 품질이 아니라 측정 문제였음. lcov 를 아무도 올리지 않았고 테스트 코드가 제품 코드로 인덱싱되고 있었음. 헤드라인 지표는 추세가 끊기지 않게 기존 기준(MAJOR+)을 유지.
  • 기여: 5개 앱 커버리지 업로드와 테스트 스코프 분리, 일간 리포트를 게이트 실패·버그·보안 핫스팟·모듈별 커버리지 중심으로 개편(쓰기 권한과 클라우드 자격증명을 다른 잡으로 분리), 자동 수정 루틴이 설정 누락 시 “고칠 것 없음”으로 조용히 멈추던 경로 제거.
  • 성과: 커버리지 0.0% → 16.2%(첫 실측), 커버 대상 라인 162,402 → 126,513. 0% 파일이 커버 대상의 83.5% 임을 드러내 다음 우선순위를 정함.

11. AI 개발 환경과 검증 하네스 (Cursor 규칙 → CLAUDE.md 개편 → cross-review → 재적재 스킬)

• 메타: 2025.07 ~ 2026.09 · 발의·설계·구현 단독(리뷰는 FE 동료) · Cursor, Claude Code(CLAUDE.md, 경로 조건부 규칙·커맨드·스킬·서브에이전트), git worktree, Playwright
• 2025.Q3 — Cursor 규칙 통합과 사내 발표:
  • 기여: 팀원마다 흩어진 Cursor 규칙을 루트 규칙 하나로 모으고 사내 발표 “Why Vibe Coding? (With Cursor)“를 엶(2025.07).
• 2026.Q1 — Claude Code 전환과 CLAUDE.md 개편:
  • 문제/배경: AI 코딩 어시스턴트(Claude, Cursor)를 팀에서 활용하기 시작했으나, 프로젝트의 컨텍스트(아키텍처, 컨벤션, 도메인 지식)를 에이전트에 전달하는 구조가 없었음.
  • 기여:
    • CLAUDE.md 를 에이전트 친화적 구조로 개편하여 프로젝트 컨텍스트를 AI가 즉시 파악 가능하도록 구성.
    • /refactor command 및 code-quality skill을 추가하여 AI 기반 코드 리팩토링 워크플로우 구축.
    • Cursor IDE 설정을 프로젝트에 통합하여 팀 전체가 동일한 AI 개발 환경을 사용하도록 표준화.
  • 성과: 루트 CLAUDE.md 351 → 116줄(한국어 → 영어), 앱별 CLAUDE.md 6개 707 → 287줄, 상세 규칙은 경로 조건부 규칙 8개로 분리(2026.03). 에이전트 품질·토큰 효과는 재지 않음.
• 2026.Q2 — cross-review 멀티 에이전트 교차검증 코드 리뷰:
  • 문제/배경: AI 도입으로 PR 생산 속도는 빨라졌지만 리뷰가 병목이 됨. AI가 자기 작업에 대해 자기편향으로 객관적 재검토를 하지 않는 문제를, 새 컨텍스트의 여러 에이전트 교차검증으로 극복하자는 가설에서 출발.
  • 기여:
    • 7개 전문 리뷰 에이전트(Convention/Side Effect/Resilience/Architecture/Security/Performance/Adversarial) + Judge 통합 스코어링(교차검증 보너스, 중복 제거, severity/confidence 역할 분리) 설계·구현.
    • 커밋 자동 감지 백그라운드 트리거, Quick/Full 이원화 토큰 효율화, pre-push 훅 통합.
    • SonarQube BLOCKER/CRITICAL/MAJOR 회귀를 차단하는 code-smell 리뷰어 추가.
    • 앞서 계획·생성·평가 3에이전트 하네스(Planner → Generator → Evaluator)를 작업 수행 모델로 도입하려 했으나 큰 작업이 아니면 무겁다고 판단해, 에이전트가 만든 코드가 일관된 의도와 컨벤션을 갖도록 여러 관점에서 검토하는 cross-review 로 방향을 바꿈(2026.04). cross-review는 이후 계속 쓰고 있음.
  • 성과: 도입 PR 실전 테스트(약사웹 PR 10파일·110줄)에서 원시 지적 27건 → Judge 통합 19건, 약 5.5분. 레포 CLAUDE.md에 push 전 리뷰 규칙으로 넣음(팀원 사용 빈도는 재지 않음). 2026.Q3 리뷰어 9개로 확장.
• 2026.Q3 — 거짓 초록을 막는 하네스:
  • 핵심 판단: AI 가 코드를 쓰는 팀의 병목은 검증. “검사가 실제로 돌았는가”를 따로 확인하는 장치(일부러 에러를 심은 프로브, base 대조)를 스킬마다 넣음.
  • 기여: cross-review 에 디자인 패턴 리뷰어(과잉 추상화 양방향 검출, 기본 침묵) 추가, QA 브랜치 재적재·체리픽 스킬(정적 검사 통과 ↔ 배포 빌드 실패 간극을 메우는 구문·바인딩·스키마 게이트), E2E 에서 GA·RUM 로그 발화 검증, 사내 공용 스킬 레포에 절차 스킬 등록(서브에이전트 6회 실측 검증).
  • 성과: 재적재 시 배포 빌드 실패 5개 앱 중 4개 → 스킬 적용 후 5개 전부 성공. 공용 스킬은 스킬 없이 도구 호출 63회 → 5회로 수렴. 공용 스킬 레포가 FE·BE 공용 저장소로 확장.

12. Datadog 관측성(Observability): RUM 비용 원인 규명과 알림 노이즈 재설계

• 문제/배경: Datadog RUM 요금이 2025.08 말부터 급증했고, RUM/Logs 에 노이즈 에러가 많아 실제 문제를 가려 보기 어려웠음.
• 기여:
  • 약사웹·유저웹 RUM/Logs beforeSend 에 SDK·서드파티발 노이즈 에러 필터를 넣고, 페이지 이동으로 취소된 요청은 AbortSignal 연결과 context.isAborted 판정으로 로그에서 뺌.
  • 약사웹 세션 리플레이는 초기화 옵션이 아니라 녹화 시작 호출에 서버 피처 플래그와 조건(요청 약품 3개 이상인 조제, 조제 수락부터 결제 요청까지)을 걸어 녹화한 세션에만 리플레이 과금이 붙게 함.
• 성과:
  • RUM 요금 급증의 원인을 RN SDK 업그레이드 뒤 앱 웹뷰 view가 잡히기 시작한 것으로 좁혀 Datadog 지원 문의에 근거를 대고, 유저앱 세션 샘플링을 100 → 10%로 낮춤(샘플링 수치는 CTO 제안). 유저앱 RUM 세션 주평균 29.5만 → 6.4만(−78%, Datadog 사용량 메트릭, 2025.10).
  • 과금 단위가 세션임을 확인해 리소스 필터 안을 버리고 리텐션을 앱 3%·웹 1%로 낮추며, 노이즈 에러가 “에러 세션 100% 보관” 필터로 되살아나던 원인(리텐션 필터 OR 평가)을 찾아 막음(2026.03). 청구액 절감은 재지 못함.
• 2026.Q3 — 알림 노이즈를 “관측 분류 문제”로 재정의:
  • 메타: 2026.08–09 · FE 단독(FE·BE·CTO 협업) · Datadog RUM/Logs/APM, axios, React Query
  • 핵심 판단: 주 19.4회 울리던 의사웹 장애 알림을 다시 설계하면서, 8/19 배포 뒤 7일치 에러 로그 9.2만 건의 출처를 나눠 보니 75% 가 한 번의 잘못된 배포(무한 리로드), 18% 가 자동화 클라이언트 1대, 실사용자 신호는 7% 였음. BFF p99 443ms 로 “우리가 느린 게 아니다”를 확정해 타임아웃 상향을 기각. 회선 실패는 지우지 않고 warn 으로 내리고(진짜 장애를 영영 못 보게 되므로), 자사/서드파티는 호스트로 판정.
  • 기여: 전송 계층 실패 등급 분리, 요청 시점 네트워크 상태 계측 후 4앱 AbortSignal 연결, 필터가 도달조차 못 하던 약사웹 beforeSend 정합화, 에러를 정체별 5버킷으로 분류(광고차단기 스텁 치환 판별), 중복 로그 제거, 뮤테이션 연타 차단.
  • 성과: “의사웹이 아파요” 모니터 발화 주평균 19.4회 → 4회(−79%), 약사웹 모니터 첫 주 85회 → 6~7회. 약사웹 레이트리밋 에러 158 → 11건(같은 길이 창). 단, 약사웹 에러 로그 총량은 줄지 않아(서버 거절 비즈니스 에러가 상위) 다음 과제로 남음.

13. Recoil → Jotai/Zustand 이관 (약사웹·의사웹·유저웹 Recoil 제거)

• 문제/배경: Recoil이 공식 아카이빙되어 유지보수가 중단되었고, React 18 → 19 업그레이드 경로의 직접적 걸림돌이 됨.
• 기여:
  • Jotai(도메인 격리 상태) / Zustand(전역·persist 상태) 적용 기준 결정 트리 수립 및 전역 상태 관리 전략 문서화.
  • AI 마이그레이션 스킬(6-Phase 워크플로우, /migrate-recoil 커맨드) 작성으로 반복 마이그레이션 작업 표준화.
  • 어댑터 패턴과 레포 규칙(.claude/rules), grep gate로 라이브러리 직접 import를 막고, recoil-persist 블롭 호환 마이그레이션-aware 스토리지 구현.
  • 규모: 약사웹 atom 9개 + store 7개, 의사웹 atom 9개 + 사용처 30+ 파일 일괄 전환 및 Recoil 완전 제거, 유저웹은 6단계로 나눠 2026-06-10 제거 완료. 회귀 테스트 60+ 케이스 추가, grep gate로 잔존 의존 0건 검증.
• 성과:
  • 기존 사용자 세션은 recoil-persist 블롭 호환 스토리지로 유지. 운영 사이드 이펙트 2건을 냄: 약사웹 로그아웃 후 새로고침 시 자동 재로그인(2026-04-30 배포 → 05-04 수정, 운영에서 발견), 유저웹 5단계 웹뷰 첫 진입 빈 데이터(배포 22분 만에 롤백, 원인을 hydration 타이밍 차이로 규명해 당일 재배포).

14. 내가 낸 장애를 시스템으로 닫기 (의사웹 접속 장애와 E2E 확장·3중 가드레일)

• 문제/배경: 의사웹 PWA 설치 배너 로깅에 넣은 Suspense 옵션 쿼리를 Suspense 경계 밖에서 호출해 접속 시 무한 로딩·재시도가 났음(2026-02-12, 배포 17:11 → 롤백 17:21). “로깅 추가에 방심했다”는 5 whys 회고 후 재발 방지를 시스템으로 닫기로 함.
• 기여: 3중 가드레일 구축
  • CUJ 단위 E2E: CTO가 만든 Playwright 뼈대 위에 인증·도메인 fixture, 헬퍼 분리, 의사웹·약사웹 spec(직접 추가 test() 154개: 의사 89 · 약사 65), data-testid 체계, 로그 검증, CI 안정화.
  • Suspense 바운더리 안전 검사 CI 스크립트 추가.
  • QueryClient 글로벌 설정 통일(기술 과제 #6 참고).
• 성과:
  • 5 whys 회고로 정한 재발 방지 5항목을 2026.04까지 이행.
  • “아무리 단순한 작업도 로컬 검증 후 배포”, “재발 방지는 시스템으로 닫는다”는 개인 원칙 정립.

15. 바텀시트 라이브러리 이관 + 오픈소스 수정 기여 (mui/base-ui#5658)

• 메타: 2026.08–09 · 단독 · Next.js, Base UI Drawer, Android Chrome + adb/CDP, pnpm patch
• 문제/배경: 스냅 바텀시트 라이브러리(vaul)에서 결함 4건이 연달아 나왔고 라이브러리는 공식적으로 유지보수 중단 상태였음.
• 핵심 판단: 다섯 번째 땜질 대신 이관하되, 스파이크로 실기기에서 흉터 해소를 먼저 확인하고 DS 공개 props 를 고정해 소비처 40곳을 건드리지 않음. 이관 후 결함은 사내 패치로 막고(제거 조건 명시) 같은 수정을 업스트림에 올림. 업스트림에서는 구현보다 원인·재현·테스트에 공을 들임.
• 기여: 시트 13개 전량 전환과 포팅 함정 7건 문서화. 마지막 남은 세 번째 스택(alpha 고정 라이브러리)도 포팅 전 상태 10개 항목을 기준선으로 떠 두고 “포팅 전과 동일”을 계약으로 걷어냄. 이관 후 “안드로이드에서만 짧은 플릭이 안 먹는” 결함을 실기기 CDP 포인터 계측으로 규명: 안드로이드 크롬이 손을 떼기 직전 정지 샘플을 한 번 더 보내고 라이브러리가 마지막 두 샘플로만 속도를 계산하던 것. 가설 3개를 실측으로 폐기.
• 성과: 패치 전 21제스처 중 10건 되돌아감 → 16~61px 플릭으로 단계 전환. 업스트림 PR 머지(진단·회귀 테스트 596줄 반영, 구현 코어는 메인테이너가 더 단순한 방식으로 교체).

16. 성능: 고치기 전에 재서 병목을 가르기 (약사웹 Web Vitals · 지도 마커 지연)

• 메타: 2026.06–08 · 단독 · React, Datadog RUM(web-vitals attribution, 버전 컷), react-scan, Profiler
• 핵심 판단: 트래픽 × 지표로 대상을 고르고, attribution 으로 단계를 쪼갠 뒤 표적 단계만 비교. 개선 신호가 노이즈 안에 있으면 수치로 주장하지 않음(대시보드 LCP 는 before 기준선 편차가 커 성과에서 제외).
• 기여:
  • 약품 관리 화면: 상호작용 지연의 대부분이 핸들러가 아니라 렌더 커밋(presentation 128ms)임을 확인하고, 토글 한 번에 테이블 전체가 리렌더되던 것을 memo 체인으로 차단.
  • 영업시간 관리 화면: 로딩 중 화면을 비워 두던 게이트가 약 790px 점프를 만들던 것을 스켈레톤 공간 예약으로 제거.
  • 다이어트 지도: “약값 쿼리가 느리다”는 전제를 RUM 으로 반박(BFF p50 84~148ms). 지연의 87% 는 티켓에 없던 1.2초 디바운스를 포함한 3중 디바운스. 드래그 간격 중앙값(2초)으로 호출량 영향을 검증한 뒤 단축.
• 성과: 상호작용 지연 INP p75 206 → 48ms, 레이아웃 이동 CLS p75 0.379 → 0 (배포 후 30일 RUM 유지). 지도 연속 탐색 시 마커 표기 1,760ms → 83ms(동일 스크립트 lab 측정).

17. 원인 규명 사례: 웹뷰·네이티브·캐시 경계

• 안드로이드 신청서 키보드가 CTA 를 가림: 실기기 CDP 계측으로 같은 URL 이 진입로에 따라 웹뷰 컨테이너 타입이 갈리는 것(파라미터 누락)을 찾음. 제보자의 “다른 과목은 된다”는 진술과 내 측정이 충돌했을 때, 내 대조군 재현이 틀렸음을 인정하고 다시 잼. 1줄 수정 + 누락을 테스트로 고정. 뷰포트 942 → 622 축소, CTA 가 키보드 위로.
• 안드로이드 서류 다운로드: “에러 0건”인 결함(파일은 저장되지만 시스템 미디어 색인에 없어 검색·카테고리에 안 보임)을 실기기 MediaStore 조회로 확정. 조사가 막힌 진짜 이유(로그 payload 의 error 키가 안드로이드 모니터링 SDK 예약 키와 충돌해 원인 필드가 통째로 버려지던 것)도 함께 고침(원인 필드 0/46 공란 → 배포 후 전부 기록). 반증된 가설과 개선으로 보이지만 코호트가 달라 쓸 수 없는 수치는 그렇게 기록.
• 빈 카테고리로 나가던 서버 요청: 1차 원인 추정이 빗나간 뒤, 첫 렌더에 생긴 빈 키 캐시 엔트리가 관측자 없이 남아 다른 화면의 캐시 리셋에 되살아나던 것을 특정. 가드를 더하지 않고 비어 있지 않은 튜플 타입으로 그 상태 자체를 없앰. 서버 예외 일 최대 1,061건 → 0건.

1. 티오더 유저 (모바일 NFC+QR 주문)

• 메타: 2024.07 ~ 2024.11 · FE + 팀장(전체 설계는 팀과 공동, 번역 제외 구현) · TanStack Query, Feature-Sliced Design, Sentry

문제/배경

• 티오더의 B2C 모바일 서비스 확장을 위해 NFC+QR 기반의 주문 기능이 필요했음.
• 경쟁사 대비 차별화된 사용자 경험 제공과, 해외 진출 시 태블릿 대신 모바일을 활용한 저비용 서비스 제공 전략이 필요했음. 해외 매장은 계획 단계였음.

기여

• QR 공유 어뷰징 방지를 위해 서버 토큰 기반 리다이렉트 처리 및 접속 유효시간 제한 기능 구현.
• Tanstack Query 설정으로 네트워크 단절 시에도 일관된 사용자 경험 제공.
• 다양한 브라우저 및 기기에서 발생하는 UI 이슈를 해결하고 반응형으로 대응함.
• 번역은 정적 문구를 스프레드시트 JSON, 동적 데이터를 백엔드 언어팩으로 나눠 처리함(번역 구현은 팀원 담당).
• Feature-Sliced Design 구조 도입.
• Sentry 연동 및 Source Map 업로드로 운영 에러를 원본 소스 위치로 추적하게 함.

성과

• 재직 중 출시 전: 2024.11 퇴사 때 출시 마무리 단계였고 출시 후 결과는 보지 못함.

2. Vue에서 React·Micro Frontend로: 보일러플레이트, 호스피탈리티 PoC, 사장님 앱 출시

• 메타: 2023.06 ~ 2024.05 · React 전환 공동 발의, 호스피탈리티 플랫폼 리드, 사장님 앱은 팀장으로 거의 전 과정 관여 · React, Webpack Module Federation, Zustand, React Query, pnpm, GitHub Actions, Flutter, Firebase Remote Config
• 2023.Q2~Q3 — React 전환 제안과 보일러플레이트:
  • 문제/배경: 기존 Vue 기반 서비스에서 향후 신사업 개발을 React로 전환할 필요 발생(React 개발자 공급·수요가 많아 채용에 유리하고, 라이브러리 생태계가 넓음). Vue CLI 기반에서 벗어나 React 기반의 프로젝트 뼈대와 구조를 미리 정의해야 했음. 전환은 본인이 제안했고 채용에 유리하다는 이유로 회사도 같은 방향으로 결정함.
  • 기여:
    • React 기반 보일러플레이트를 구성하여 향후 프로젝트를 빠르게 시작할 수 있는 개발 환경 구축.
    • Emotion + Zustand + React Query 조합을 통해 프론트 상태/서버 상태를 명확히 분리한 아키텍처 적용.
    • OpenTelemetry로 API 통신을 추적할 수 있게 함.
    • yarn berry 기반 PnP 환경 및 monorepo 구조 도입.
    • 에러 핸들링을 위한 선언적 오류 처리(ErrorBoundary)와 Dynamic import 라우팅 설계.
  • 성과: 신사업 React 전환의 뼈대가 되었고, 다음 단계인 MFA 보일러플레이트로 이어짐.
• 2023.Q2~Q3 — MFA 보일러플레이트 (yarn berry → pnpm 전환):
  • 문제/배경: 기능이 누적되며 모놀리식 구조의 유지보수 및 배포 리스크가 커졌고, 서비스 업데이트 중 오류 시 전체에 영향이 갔음.
  • 기여:
    • Micro Frontend 구조 도입: Webpack Module Federation 기반 Run-time 통합 방식 채택, 각각의 도메인을 독립적 앱으로 나눠 배포 가능하게 구조 설계.
    • Zustand, React Query 등 공유 상태 관리의 Best Practice 정립 및 예제 구현.
    • 패키지 관리를 단순하게 하려고 yarn berry에서 pnpm으로 전환함.
  • 성과: 독립 배포 및 업데이트가 가능한 구조를 보일러플레이트로 제공. MFA 도입, PnP와 Yarn Berry 등 관련 글을 기술 블로그에 공개함.
• 호스피탈리티 플랫폼 기술 설계 (MFE·CI/CD, PoC 뒤 종료):
  • 문제/배경: 호텔 객실 내 태블릿 주문, 외부 배달 주문을 아우르는 신사업 추진. 인수를 검토하던 ISTAY(호스피탈리티 기업)의 기존 서비스와 통합 필요. 신규 서비스 통합, 확장성 확보, 테스트 자동화 등을 위한 기술 기반 정립이 요구됨.
  • 기여:
    • 리드로 참여해 Webpack Module Federation 기반 MFE 구조(도메인별 독립 배포)와 GitHub Actions 워크플로를 직접 작성함. 아키텍처 기획과 사용자 흐름 설계는 팀 작업.
    • GitHub Actions 기반 CI/CD: PR 라벨 기반으로 테스트, 배포, 캐시 무효화, 릴리즈 노트 생성을 자동화하고, Jest 단위 테스트와 Cypress E2E 테스트를 PR마다 자동 수행.
    • 인수 검토 대상 서비스의 기능 분석 및 PoC 테스트: 배달 기능 간이 구현 → 트래픽 측정 및 데이터 기반 사업성 분석.
  • 성과:
    • 통합 플랫폼 구조와 MVP 기능 로드맵을 설계·PoC 단계까지 진행함.
    • PR 라벨 기반 테스트·배포·캐시 무효화·릴리즈 노트 자동화를 구축함.
    • 인수 검토 대상 서비스 분석 및 문서화 완료, 기능 이관에 대한 기획 기반 마련.
    • 재무적 타당성 검토의 결과를 바탕으로 사업 ROI 불충분 판단 → 프로젝트 종료 결정.
• 2024.Q1~Q2 — 사장님 앱 출시:
  • 메타: 2024.02 ~ 2024.05(2024.05 양대 마켓 출시) · 팀장, 거의 전 과정 관여·유관부서 정기회의 주관 · Webpack Module Federation, Flutter, Firebase Remote Config
  • 문제/배경: 점주의 메뉴/운영 요청이 콜센터에 집중되며 비효율적 운영이 지속됨. 점주 전용 앱 출시로 유료 서비스 사용 확대 및 광고 구좌 활용 필요성이 대두됨.
  • 기여:
    • MFA 보일러플레이트(2023)에서 익힌 Webpack Module Federation 구조를 적용해 도메인을 붙일 수 있는 구조를 마련함.
    • Flutter 기반 웹앱으로 앱 마켓 출시, 네이티브 기능은 브릿지 핸들러로 구현.
    • 앱 업데이트 안내 문제를 Firebase Remote Config 기반 버전 관리로 해결.
    • 다양한 OS/기기 대응 이슈 해결, 권한 처리 및 브라우저 특이점 대응.
    • 유관부서 정기 회의를 주관해 요구사항을 조율하고 우선순위를 정함.
  • 성과: 2024.05 앱스토어·플레이스토어 동시 출시. 출시 후 활성 매장 1,400여 곳(2024.09 경, DB 기준 직접 집계).

3. 티오더2: 태블릿 주문 서비스 Vue3 재작성, 고도화, v1/v2 전환

• 메타: 2022.05 ~ 2023.10 · FE 메인(서버 쪽은 BE 담당), 고도화 단계는 구현과 측정 모두 본인 · Vue3 Composition API, 아토믹 디자인, Storybook, Cypress, Sentry, Lambda@Edge, CloudFront
• 2022.Q2~Q4 — MVP 개발 (Vue3 재작성):
  • 문제/배경:
    • 기존 티오더 레거시 서비스는 스타일, 기능, 구조가 정돈되지 않아 유지보수에 어려움이 있었음. 전역 스타일의 꼬임, 비대하고 복잡한 JSON 통신 구조, 웹뷰 내 JS 메모리 초과로 인한 다운 현상 등 복합적 문제 발생.
    • 구형 라이브러리(Node v12 이하 등)에 의존하여 최신 개발 환경으로 마이그레이션 필요.
    • 매장 확대 및 다양한 테마 적용을 위한 확장 가능 구조 필요.
  • 기여:
    • 전체 UI/UX 재설계 및 Vue3 Composition API 기반으로 마이그레이션.
    • 디자인 시스템 및 아토믹 디자인 기반 구조 설계.
    • 주문 로직, 테마, 스타일 구조 분리: 서비스 초기 로딩 시 매장 조건에 따른 테마 적용, 컬러 및 레이아웃 정보를 전역 상태에 저장해 동적으로 처리.
    • 웹뷰 부담을 줄이려 대용량 JSON 연산을 서버 처리로 옮김(서버 쪽 구현은 BE 담당).
    • 스타일은 scoped로 적용해 컴포넌트 간 스타일 충돌 제거.
    • 공통 컴포넌트 및 기능 단위는 유틸 및 훅으로 추상화.
    • Storybook으로 컴포넌트를 명세화하고, MVP 단계(2022.08)에 팀원과 함께 Cypress E2E를 붙여 주요 페이지 7개를 자동 테스트함. 배포 자동화·E2E CI는 기술 과제 #1.
    • IntersectionObserver로 이미지 Lazy Load 적용.
    • Node v12 이하 의존을 벗어나 Node 16+ 환경으로 이전함.
  • 성과: MVP를 몇 매장에 먼저 깔고 하얏트 프로젝트를 거쳐 고도화(2023.07~09) 뒤 본격 전환함. 퇴사 무렵(2024.11) 어드민 기준 v2 전환 매장 3,000개 이상(직접 집계).
• 2023.Q3 — 티오더2 고도화(서비스 안정화):
  • 문제/배경: 초기 로딩 지연, 이미지 지연 로딩, 네트워크 이슈 등 UX 저하 문제 다수 발생. 기존 Vue 기반 코드에서 오류 추적 및 유지보수에 한계가 있었고, JS 번들 크기 비대화로 브라우저 렌더링 성능이 떨어졌음.
  • 기여:
    • Vue의 ErrorCapture 활용하여 React의 ErrorBoundary 유사 로직 구현, 사용자 영향 최소화.
    • Sentry 도입으로 실시간 에러 트래킹 및 로그 수집.
    • 초기 로딩: JS 코드 스플리팅 및 Dynamic Import로 번들 사이즈 감소, Font preload, Image lazy loading 구현.
    • 네트워크 오류/지연 시 fallback 이미지 및 로딩 UX 개선 구현.
  • 성과:
    • 메인 화면 첫 표시 시간 15초 → 3초(로컬·태블릿 실기기, 직접 측정).
    • 메인 화면 Lighthouse 성능 55 → 97(로컬·태블릿 실기기, 직접 측정한 lab 값).
    • 주요 에러 발생 시 서비스 전체 중단 없이 fallback 처리.
    • 네트워크 오류·지연 때 fallback 이미지와 로딩 UX를 보여 줌.
• 2023.Q3~Q4 — v1/v2 분리 서빙 (Lambda@Edge):
  • 문제/배경:
    • 동일한 도메인 내에서 /v1, /v2 등 URL path에 따라 서로 다른 버전의 정적 웹 앱을 서빙해야 하는 요구 발생. 티오더 v1을 계속 쓰려는 매장과 v2로 옮기는 매장을 나눠 서빙해야 했고, v1 → v2 마이그레이션에도 필요했음.
    • S3 단독으로는 버전별 폴더 내 index.html을 자동으로 매핑해주는 서브라우팅 기능이 제한됨.
    • CloudFront 사용 시에도 path 기반 서브라우팅이 제대로 작동하지 않음.
  • 기여:
    • Lambda@Edge를 활용하여 CloudFront에서 발생하는 request를 가로채 처리: /xxx/ 형태의 요청을 감지하면 해당 요청 뒤에 /index.html을 자동으로 붙여서 처리되도록 정규식 기반으로 구현.
    • vite 설정 변경: JS/CSS 리소스 경로가 index.html 기준 상대경로를 참조하도록 baseUrl 설정 수정.
    • CloudFront 동작(behavior) 분리: HTML 외 정적 리소스 요청은 Lambda 를 거치지 않도록 동작 우선순위를 설정.
  • 성과:
    • 버전별 정적 웹 서비스 운영이 동일 도메인 내에서 가능해짐.
    • /xxx/ 주소로 접속 시에도 정상적인 SPA 라우팅 및 index.html 서빙 구현.
    • 같은 도메인 아래 경로별로 버전을 추가할 수 있는 URL 구조.

🔗 관련글: AWS Lambda CloudFront SubRouting

4. 하얏트 호텔 주문 시스템 커스터마이징

• 메타: 2023.02 ~ 2023.06 · FE 대부분 직접 · 그랜드 하얏트 제주 호텔 내 식당(객실 미포함) · Vue3, i18n

문제/배경

• 기존 티오더 시스템에는 호텔 특화 요구사항이 반영되지 않았음:
  • 호텔 매장 UI 테마와 어울리는 맞춤형 디자인 필요.
  • 세트 상품 및 2단 옵션, 프리셋, 커스텀 스타일 등 기존보다 깊은 상품 구성 요구.
  • 각 매장마다 다른 인테리어, 언어, 메뉴 구성을 지원해야 하는 복잡한 서비스 모델이 요구됨.
• 특히 세트 상품과 옵션 조합, 주문 구조의 깊이 확장 등 기존 구조의 재설계 필요.

기여

• Vue3 기반으로 커스터마이징 가능한 UI 및 주문 구조 전반을 새로 설계 및 구현.
• 세트/옵션 상품을 트리로 파싱하고 장바구니·주문서에 맞게 트리를 재구축함. 옵션 깊이를 임의로 두는 설계를 버리고 세트/상품/옵션 3단계로 고정함.
• JSON 기반 주문 포맷으로 기존의 Form 기반 통신 구조를 교체.
• 사용자 커스텀 테마(배경, 버튼, 색상 등 8개 영역)에 따라 UI 동적으로 렌더링되도록 전역 상태 기반 스타일 시스템 설계.
• 프리셋 기능 구현: 옵션 선택 없이도 사전 설정된 추천 구성이 자동 선택되어 UX 개선.
• 장바구니 내 기존 옵션을 불러와 재수정 가능한 기능 추가.
• 다국어 지원을 위한 i18n 기반 4개국어 번역 제공.

성과

• 그랜드 하얏트 제주 호텔 내 식당 10곳에 적용함(2023.11 언론 보도 기준 태블릿 약 480대).
• 기존 단순 상품/옵션 2단계 구조에서 세트/상품/옵션 3단계 구조로 확장 가능 구조 제공.
• 8개 영역 UI 커스터마이징으로 매장마다 테마를 설정할 수 있게 함.

1. 티오더 CRM 시스템 구축

• 메타: 2022.11 ~ 2023.01 · 구현 담당(스키마·권한 모델 설계는 본인 아님), 오픈 전 하얏트 프로젝트로 이동

문제/배경

• 고객관리 및 응대, 영업 등 부서별로 다양한 형태의 데이터를 수기로 관리하거나 별도 시스템으로 분산되어 있어 업무 통합이 어려웠음.
• 각 부서별 요구사항을 만족하면서도 하나의 플랫폼 안에서 고객 정보를 함께 관리할 내부 시스템이 필요해짐.
• 폼 입력 형식과 권한에 따라 다양한 UI 구성 및 권한 제어가 필요했고, 이력 조회와 변경 추적 기능도 요구됨.

기여

• 부서별 커스텀 입력폼을 만드는 동적 폼 시스템 구현:
  • 사용자 선택에 따라 텍스트, 이메일, 전화번호, 날짜 등 다양한 타입의 입력 요소가 반응형으로 제공되도록 구현.
• 등록된 폼에 데이터를 입력하고, 저장하며, 버전 별로 관리되도록 폼 등록 및 수정 시스템 개발.
• 각 항목별로 읽기/쓰기/수정 권한을 분리하여 접근 권한에 따라 UI 제어.
• 상담 기록, 방문 이력 등 고객 접점 활동의 타임라인형 이력 조회 UI 구현 (무한 스크롤 및 페이지네이션 포함).
• 각 문서 변경 이력 추적 기능 추가 및 이력 클릭 시 해당 시점 문서 상세로 이동 기능 개발.

구현 범위

• 부서별 커스텀 문서 입력폼 생성 및 사용 가능:
  • 총 10종의 입력 타입 제공.
• 문서 권한 기반의 역할 제어 시스템 구현:
  • 읽기/쓰기/수정 권한에 따라 UI 및 기능 제어.
• 문서 변경 이력 관리 기능 구현:
  • 히스토리 기반 비교 및 복구 기능 포함.
• 다양한 고객 응대 활동(전화, 방문, 문의 등)에 대한 기록 및 추적 시스템 구현.
• 오픈 전에 하얏트 프로젝트로 옮겨 운영 결과는 확인하지 못함.

1. 프론트엔드 배포 자동화, E2E CI, 모노레포 패키지별 배포

• 메타: 2022.05 ~ 2023.12 · 배포 파이프라인과 모노레포 조건부 배포는 직접 작성, Cypress E2E는 팀원과 공동 · GitHub Actions, AWS CLI, S3, CloudFront, Cypress, Cypress Cloud, yarn berry workspaces
• 2022.Q2~Q4 — 배포 파이프라인 (S3·CloudFront):
  • 문제/배경: 수동 배포 과정에서 인적 오류가 발생하거나 시간이 오래 걸리는 문제가 반복됐고, 배포 프로세스의 일관성과 재현성 확보가 필요했음.
  • 기여:
    • GitHub Actions 기반 CI/CD 파이프라인 구성: main 브랜치에 push 발생 시 자동으로 빌드 및 배포 실행, AWS CLI를 이용해 S3 버킷에 파일 업로드 및 CloudFront 캐시 무효화 자동화.
    • GitHub Secrets를 통해 AWS 키 등 민감한 정보 관리.
    • 각 단계별 실패 시 즉시 프로세스 중단되도록 설정.
  • 성과: 티오더2 MVP부터 적용해 팀 배포 표준으로 확산함. 배포마다 CloudFront 캐시 무효화까지 자동으로 실행됨.
  • 🔗 관련글: 프론트 배포 자동화 git action편
• 2022.Q3 — Cypress E2E 테스트와 GitHub Actions CI (팀원과 공동):
  • 메타: 2022.08(티오더2 MVP) · 팀원과 공동 작성·구현 · Cypress, Cypress Cloud, GitHub Actions
  • 문제/배경: 프론트엔드 코드의 품질을 보장하고 테스트를 자동화된 방식으로 돌릴 필요가 생김.
  • 기여:
    • Cypress 기반의 E2E 테스트 환경 구축: 로그인 기능 등 핵심 기능에 대한 테스트 시나리오 작성, 병렬 실행 설정.
    • GitHub Actions 기반 CI 파이프라인 구축: PR 및 push 시점에 자동 테스트가 실행되도록 워크플로우 구성, 테스트 결과를 Cypress Cloud에 업로드.
  • 성과: PR·push마다 로그인 등 핵심 흐름 E2E가 자동으로 돌고, 결과는 Cypress Cloud에 모임.
  • 🔗 관련글: Cypress 적용 및 github actions CI 붙히기
• 2023.Q3~Q4 — 티오더2 모노레포와 패키지별 조건부 배포·릴리즈 노트:
  • 메타: 2023 하반기(하얏트 이후, 월 미상) · 모노레포 구조와 조건부 배포 직접 작성 · yarn berry workspaces, GitHub Actions
  • 문제/배경: 클라이언트 요구로 기존 단일 인프라 외 별도 도메인/인프라에서 서비스 운영이 필요해짐. 티오더2 프로젝트 내에서 유사한 서비스(예: 하얏트 등)를 별도 도메인으로 나누어 배포해야 했고, 기존 단일 프로젝트 구조로는 유지보수성과 확장성에 한계가 있었음.
  • 기여:
    • 기존 단일 프로젝트를 yarn berry 기반 monorepo 구조로 전환, 프로젝트 루트 하위에 torder, hyatt 등의 패키지 분리 배치.
    • 공통 코드(common)를 별도 디렉토리로 추출해 공통 기능을 추상화하고 각 패키지에서 재사용 가능하게 구성. 공통 의존성은 루트의 package.json에서 통합 관리.
    • 각 하위 프로젝트의 빌드/배포는 루트 스크립트로 통합 관리되도록 설정.
    • GitHub Actions에서 브랜치와 라벨 조건에 따라 해당 하위 패키지만 빌드/배포되도록 세팅.
    • 배포 간 자동으로 하위 package.json의 버전을 기준으로 태그 생성 및 릴리즈 노트 자동화 구현.
  • 성과:
    • 하나의 레포 내에서 다중 도메인 서비스 배포 가능 구조 확보.
    • 공통 코드(common)를 패키지 간에 공유하고, 브랜치·라벨 조건으로 바뀐 패키지만 빌드·배포함.
    • 추가 도메인을 예상해 패키지 단위로 나눈 구조(전환 당시 torder·hyatt 2개).