대표 글
웹 보안
고객 문의 폼 로그에 개인정보를 남기지 않고 장애 찾기
고객 문의가 실패했을 때 원인을 찾으려고 요청 본문 전체를 로그에 남기면 이름, 전화번호, 이메일, 상담 내용이 오래 보관될 수 있습니다. 장애 분석에 필요한 정보와 고객이 맡긴 내용을 분리하는 로그 설계가 필요합니다.
NOTES
현장에서 배운 것들
모델을 만들고, 웹과 앱을 짓고, 업무를 자동화하며 확인한 것을 기록합니다. 통한 방법만이 아니라 통하지 않았던 시도까지 남깁니다.
TOTAL 288
검색 유입을 돕는 내부 링크, 메뉴보다 본문 맥락이 중요하다
사이트의 모든 글이 메뉴에서 두세 번 안에 열리더라도 관련 글이 서로 연결되지 않으면 독자와 검색 엔진은 주제의 맥락을 따라가기 어렵습니다. 내부 링크는 페이지 수를 늘리는 수단이 아니라 다음 질문으로 길을 만들어 주는 정보 설계입니다.
서비스를 멈추지 않는 DB 스키마 변경: 확장 후 축소
운영 중인 DB에 새 컬럼을 만들고 앱 코드를 동시에 바꾸면 잠깐 다른 버전의 앱이 공존하는 동안 오류가 날 수 있습니다. 무중단 스키마 변경은 한 번에 바꾸는 일이 아니라 옛 코드와 새 코드가 함께 살아도 되는 기간을 설계하는 일입니다.
백그라운드 작업의 '정확히 한 번 실행'이 어려운 이유
백그라운드 작업을 큐에 넣었으니 한 번만 실행될 것이라고 믿으면 결제, 이메일, 재고 차감에서 중복이 생길 수 있습니다. 메시지는 중복 전달될 수 있고, 작업 완료 뒤 확인 응답이 사라질 수도 있습니다. '정확히 한 번'보다 중복이 와도 결과가 같도록 설계하는 편이 현
기능 플래그로 출시해도 안전하지 않은 순간들
기능 플래그를 넣으면 언제든 기능을 끌 수 있으니 출시가 안전하다고 생각하기 쉽습니다. 하지만 새 코드가 이미 데이터를 바꾸거나 외부 메시지를 보냈다면 플래그를 꺼도 되돌릴 수 없습니다. 안전한 출시에는 플래그의 범위와 되돌릴 수 없는 부작용을 구분하는 일이 필요합니다
최적화 결과가 '해 없음'일 때 운영자에게 보여 줄 것
스케줄 최적화가 '해 없음'이라고 답하면 현장에서는 어떤 조건을 풀어야 할지 알 수 없습니다. 솔버의 상태 코드를 운영자의 의사결정 정보로 번역해야 합니다. 해가 없는 이유와 선택 가능한 완화 방안을 설명하는 것이 최적화 제품의 핵심 기능입니다.
배송 중 주문이 취소되면 경로를 어디부터 다시 계산할까
배송 차량이 이미 출발한 뒤 고객이 주문을 취소했습니다. 남은 모든 차량의 경로를 다시 계산하면 이론상 거리는 줄 수 있지만 기사에게 전달된 약속과 적재 순서가 뒤집힐 수 있습니다. 실시간 재최적화는 바꿀 수 있는 범위를 먼저 정해야 합니다.
창고 슬롯팅, 피킹 거리만 줄이면 왜 실패할까
잘 팔리는 상품을 출입구 가까이에 두면 피커의 이동거리는 줄어듭니다. 그러나 그 위치가 너무 작아 하루에도 여러 번 보충해야 한다면 전체 작업은 느려질 수 있습니다. 창고 슬롯팅은 피킹과 보충을 함께 보는 배치 문제입니다.
잔업을 공평하게 나누는 스케줄은 어떻게 계산할까
잔업을 '가장 시간이 되는 사람'에게만 맡기면 같은 직원에게 야간과 주말 부담이 쌓일 수 있습니다. 그렇다고 모두에게 정확히 같은 시간을 배분하면 자격이나 개인 사정을 무시하게 됩니다. 잔업 공정성은 어떤 부담을 얼마나 나누려는지 정의하는 문제입니다.