Level Up 개발자
1.커밋 제대로 안할거면 내가 하게 해주지
eslint+prettier를 기반으로 lint-staged를 통해 올린 파일들을 기준으로 husky를 이용한 커밋 전 커밋 형식 및 eslint 검사로 프로젝트 기록 관리하는 내용입니다.
2.XSS 공격 대응 프론트엔드 가이드
요즘은 가장 이슈가 되고 있고, 실제 사례도 발생되고 있는 Fake Verification Phishing + Click Fix 를 인트로로 XSS 공격에 대한 이야기를 시작하려고 한다.
3.관리자 엑셀 다운로드를 안정적으로 만드는 법: 조회 조건과 표시값을 하나의 계약으로 관리한 방법
관리자 주문 엑셀의 필터·정렬·표시 금액을 목록과 같은 계약으로 유지한 구현. 현재 writeBuffer 방식과 향후 스트리밍 검토를 구분한다.
4.분산된 문의 채널을 하나의 인박스로 통합하는 설계: 어댑터·공통 인덱스·보안
문의 채널별 원본은 유지하고 공통 색인·어댑터로 인박스를 구성한 설계. 페이지별 상세 조회, 상태 이력, 권한·동시성 경계를 설명한다.
5.결제 SDK 직접 로더를 지우고 공식 SDK로 전환한 이유: 유지보수할 코드 줄이기
두 앱의 커스텀 결제 스크립트 로더를 공식 SDK로 통일한 리팩토링. SDK 로딩과 위젯 생명주기·주문 검증의 책임을 분리한다.
6.대시보드 성능 최적화: 여러 기간의 지표를 한 번에 집계하는 설계
기간별 매출 SELECT를 UNION ALL 한 SQL 요청으로 묶고 두 DB 결과를 합산한 리팩토링. KST 누적 기간 계약과 왕복·스캔 비용을 구분한다.
7.자동 일정이 기획과 어긋나는 이유: 규칙 기반 시스템을 다시 신뢰하게 만든 과정
자동 일정의 원천·분류·기간 상태를 명시하고 규칙 fixture로 확인한 개선. 잔존 데이터와 구현·기대값 동시 변경의 위험을 다룬다.
8.리팩토링의 화면 변화를 찾는 법: 픽셀 단위 시각 회귀 테스트 CLI
기준·변경 서버를 같은 viewport에서 캡처해 canvas로 비교하는 시각 회귀 CLI. DOM 안정화 휴리스틱과 실제 렌더 비교의 한계를 설명한다.
9.이미지 최적화는 압축이 아니다: 원본과 WebP를 함께 관리한 제품 설계
프로필 원본과 표시용 WebP의 역할을 분리한 이미지 파이프라인. 픽셀 수 제한·깨진 파일·부분 업로드 실패의 처리를 구분한다.
10.모바일 첫 화면에서 전환을 설계하는 법: 배너 카피와 콘텐츠 운영을 분리한 이유
모바일·PC 배너 문구를 분리하고 공통값 호환성을 유지한 콘텐츠 모델. nullish fallback과 빈 문자열의 차이, 측정할 전환 지표를 설명한다.
11.데이터를 더 보여주는 대신, 더 빠르게 행동하게 만들기: 이탈 분석 UX 개선
긴 이탈 분석 목록을 앞의 3개와 외 N건으로 축약한 UX. 입력 순서 보존과 위험도 정렬을 구분하고 경계값을 테스트한다.
12.운영 자동화가 신뢰를 얻는 조건: 일정 생성 결과를 설명 가능하게 만들기
자동 생성 일정에서 원본 수정 화면으로 되돌아갈 수 있게 만든 운영 UX. sourceUuid와 sourcePath의 역할 및 식별자 계약을 정리한다.
13.결제 만료를 새 주문 없이 복구한 이유: CS·주문 이력·이중 결제를 함께 지키는 설계
만료 주문을 새 주문으로 복제하지 않고 결제 시도를 다시 연결한 설계. 주문 금액·이력을 유지하고 동시 요청 보장의 한계를 구분한다.
14.알림톡 운영 도구 설계: 템플릿·변수·버튼 링크 검증으로 발송 실수를 줄이는 법
알림톡 템플릿의 선언 변수와 본문·버튼 URL의 사용 변수를 양방향 검증해 발송 전 오류를 발견하는 운영 도구 설계.
15.학사 일정 운영 플랫폼 구축기: 기획표·캘린더·자동 생성 규칙을 하나의 시스템으로 묶는 법
학사 기획표·캘린더·일정 생성 규칙을 연결한 플랫폼 구조. 원천 식별자와 역할을 명시하고 스키마·API·화면의 계약을 함께 관리했다.
16.개발·운영 환경이 섞여도 로그인 세션을 지키는 법: 쿠키 네임스페이스와 same-origin 보안
환경별 쿠키 네임스페이스와 BFF Origin 정책을 공유 함수로 분리한 과정. 로컬 host·port 예외와 인증·출처 검증의 차이도 설명한다.
17.학습 중단 시 답안 손실 위험을 줄이기: 퀴즈 타이머·임시 저장·자동 제출 UX
학습 중단·저장·제출·만료를 다른 상태로 다루고, 서버 종료 시각 기반 타이머와 화면의 중복 실행 방어가 보장하는 범위를 정리한 회고.
18.공유 스킬도 운영해야 한다: 같은 규칙이 반복해서 낡은 뒤 CI를 넣기까지
공유 스킬 안내를 실제 스키마와 맞춘 다음 날 다시 깨졌다. 반복된 문서 드리프트를 구조·버전·규칙 검사로 다루면서 원천과 사본, CI가 보호할 수 있는 범위를 정리했다.
19.결제는 실패만 있는 게 아니다: 취소·세션 만료·승인 확인을 복구 가능한 흐름으로
결제 취소 후 남은 PENDING 주문부터 세션 만료와 CONFIRMING 재조회까지. 조건부 상태 전이로 이전 시도를 정리하고 승인 여부가 불확실한 주문을 보호하면서, 로그인 복귀와 서버 복구 경로를 연결한 과정과 검증 범위를 정리했다.
20.이 응답은 누구의 데이터인가: 계정·자녀 전환에서 비동기와 캐시 경계 지키기
자녀 전환 뒤 늦게 도착한 응답과 계정 변경 뒤 남은 개인 데이터를 분리했다. 계정·자녀별 query key, 캐시 정리, 요청 세대 검사와 로그인 확인 실패 구분을 조합해 현재 화면에 반영할 데이터의 경계를 정한 과정을 돌아본다.
21.업데이트와 적용은 다르다: 긴 AI 세션에서 최신 스킬을 읽게 만든 과정
공유 스킬을 자동 업데이트해도 긴 세션은 이전 규칙을 사용했다. 디스크 파일과 설치 메타데이터, 현재 컨텍스트를 구분하고 프롬프트 훅으로 최신 파일 경로를 연결했다. 동기 네트워크 제거와 재시작이 필요한 범위, 다중 세션의 한계까지 정리했다.
22.마이페이지 요청 3회→1회: 동시 요청을 합쳐도 한 번이 더 남았던 이유
마이페이지의 세션 요청을 3회에서 1회로 줄였다. 진행 중 Promise 공유만으로는 2회가 남아 마운트 순서를 추적했고, 부모가 가진 loginId를 자식에 전달해 순차 조회를 제거했다. 네 화면의 로컬 모의 API 반복 측정과 계정 변경의 경계를 함께 설명한다.
23.227명은 사실 0명이었다 — 운영 대시보드의 숫자를 DB에서 직접 세어본 날
경영진이 매일 보는 대시보드를 만들었다. 카드마다 숫자가 큼직하게 박혀 있고, 그 숫자를 보고 사람이 움직인다. "반 배정 대기 227명"이면 누군가는 오늘 227명을 배정해야 한다. 그런데 그 227명을 실제로 배정하려던 담당자가 물었다. "이 사람들 명단은 어디서 봐요?" 명단을 뽑아봤다. 조건에 맞는 사람은 0명이었다. 이 글은 그 뒤로 카드를 ...
24.334명을 되살리며 내가 쓴 분석을 스스로 뒤집었다
지난 글에서 대시보드 숫자가 왜 틀렸는지를 썼다. 집계를 고치다 보니 더 불편한 걸 발견했다. 집계가 틀린 게 아니라 데이터 자체가 틀어진 계정이 쌓여 있었다. 334명. 2년 반 동안. 되돌릴 수 없는 되돌리기 서비스에는 학생 계정 번호가 두 종류 있다. 결제 전의 임시 번호와 결제 후의 정식 번호. 수강권 결제가 완료되면 임시 → 정식으로 바뀌고,...
25.빈도 1위 문구가 올해는 0건이었다 — 운영 답변 10,953건으로 상용구 만들기
고객 문의에 답을 쓰는 담당자들이 같은 문장을 매번 다시 타이핑하고 있었다. "자주 쓰는 문구를 골라 넣는 기능"을 만들기로 했다. 기능 자체는 간단하다. 문구 테이블 하나, 관리 화면 하나, 에디터에 삽입 버튼 하나. 진짜 문제는 그 문구를 무엇으로 채울 것인가였다. 기획에서 받은 초기 문구는 없었다. 대신 운영 DB 에 지난 답변이 10,953건 쌓...
26.같은 이름의 함수 두 개가 실패할 때 서로 다르게 동작했다
다른 회사가 운영하던 서비스를 우리 모노레포로 넘겨받았다. 코드는 멀쩡히 돌아가고 있었고, 사용자도 쓰고 있었다. 넘겨받은 쪽 입장에서 제일 먼저 하는 일은 "이 코드가 뭘 하는지" 가 아니라 "이 코드를 어떻게 안전하게 고칠 수 있는지" 를 아는 것이다. API 요청부터 봤다. 네 갈래였다. 네 갈래 새 화면을 만들려는 사람이 "요청은 뭘로 하지?"...
27.10,401줄을 지웠다 — 같은 화면이 두 벌씩 있던 관리자 정리하기
관리자에 학생 상세 화면이 두 개 있었다. 경로가 다르고, 들어가는 메뉴가 다르고, 화면은 거의 같았다. 조직이 커지면서 두 팀이 각자 필요한 화면을 만들었고, 둘 다 "학생 한 명의 모든 것"을 보여줘야 했으니 자연스럽게 같은 걸 두 번 만들었다. 누구의 잘못도 아니다. 다만 이제는 탭 하나를 고치려면 두 군데를 고쳐야 하고, 한쪽만 고치면 두 화면이 ...
28.만들 수 없는 위젯 3개의 이유를 표로 적어 냈다
CS 실시간 대시보드 요청서가 왔다. 위젯 5종. 전체 미처리 건수 경로별 미답변 문의 유형별 분포 담당자별 처리 부하(%) SLA 경보 데이터를 뒤져보고 2종만 만들었다. 나머지 3종은 "왜 못 만드는지"를 PR 본문에 표로 적어서 냈다. 이 글은 그 표에 대한 이야기다. 먼저 데이터를 본다 요청서를 받으면 바로 화면부터 그리고 싶어진다. 위젯 ...
29.동의를 참/거짓 한 칸에 저장하면 분쟁에서 진다
광고성 정보 수신 동의가 이렇게 저장돼 있었다. 참이면 보내고 거짓이면 안 보낸다. 동작은 맞다. 문제는 이 칸이 "동의하셨습니까"에만 답할 수 있다는 것이다. 실제로 들어온 질문들은 이랬다. 이 사람은 언제 동의했나? 어느 화면에서 받은 동의인가? 동의했다가 철회한 적이 있나? 거짓인 사람은 거절한 것인가, 물어본 적이 없는 것인가? 한 칸으로는 ...
30.검색엔진에 우리 사이트는 로딩 화면이었다
"커리큘럼 페이지가 검색에 잘 안 나와요." 마케팅 쪽에서 온 말이었다. 보통 이런 요청은 "순위를 올려 달라"는 뜻이고, 그럼 메타 태그를 다듬거나 콘텐츠를 보강하는 일이 된다. 그런데 확인해보니 순위 문제가 아니었다. 그 페이지의 내용이 색인돼 있지 않았다. JS 를 끄고 열어보면 안다 가장 빠른 확인 방법이다. 브라우저에서 JavaScript ...