입력할 수 있는 글이라면, 완성된 계약서에서도 읽혀야 합니다.
증상과 배경
수신자가 긴 내용을 입력해도 최종 PDF의 작은 칸에서는 글이 줄어들거나 뒤가 잘렸습니다. 화면에서 받은 내용과 실제로 전달하는 문서가 달랐습니다.
기록 / 문제 유형
증상 너머의 공통점.
문서는 달랐고, 화면도 달랐지만 끊기는 지점은 닮아 있었습니다. 서로 다른 제품의 문제를 같은 질문으로 다시 읽습니다.
운영 중 겪은 장애와 개발 과정에서 찾은 결함을 함께 담았습니다. 각 사례에서 원인·수정·확인 결과를 볼 수 있습니다.
사용자가 준 값은 어디에서 끊겼을까?
입력은 있었는데, 결과에는 없었습니다.
입력 화면과 저장, 처리 요청, 최종 출력의 값을 비교했습니다. 누락을 모델의 추측이나 새 입력 제한으로 메우기보다, 이미 저장된 값이 다음 단계로 전달되는지 확인했습니다.
조사·선택·검증 과정 읽기
수동 생성은 되는데, 결제 직후에는 안 되는 이유
증상과 배경
결제 후 자동 생성은 실패했지만 추가 입력 폼에서 다시 요청하면 정상 진행됐습니다. 결제는 끝났는데 사용자는 구매한 리포트를 받지 못하는 상태였습니다.
무엇이 기준이고, 누가 어떤 범위를 바꿀 수 있을까?
같은 데이터가, 화면마다 다른 뜻이 됐습니다.
환불과 주문 종료, 사람과 회사별 소속, 조회 권한과 승인 권한을 나눴습니다. 특정 화면을 고친 뒤에는 같은 값을 읽거나 변경하는 다른 경로도 검색해 함께 검토했습니다.
PG의 부분취소와 주문의 종료는 다른 판단이다
증상과 배경
일부 금액만 환불했는데 주문 전체가 종료되고 매출에서도 전액이 빠졌습니다. 반대로 배송비를 공제한 전체 반품은 PG에서 부분취소로 보여도 업무상 주문은 끝나야 했습니다.
한 회사에서 나가도, 다른 회사의 로그인은 남아야 합니다.
증상과 배경
한 사람과 한 회사의 계정을 같은 축으로 다루던 구조에 여러 회사 공간이 필요해졌습니다. 회사에서 나가는 행동이 사람의 로그인 정보까지 지우거나, 강퇴 직전에 시작한 수정 요청이 정리한 정보를 다시 쓰는 문제가 생길 수 있었습니다.
화면을 간단하게 만들어도, 승인까지 건너뛸 수는 없다
증상과 배경
홈에 빠른 행동과 정산 신호를 추가하면서, 읽기만 가능한 역할에게 실행 버튼이 보이거나 편의 기능이 돈 관련 쓰기 권한을 우회할 여지가 생겼습니다.
동시에 바뀌거나 늦게 끝나도 같은 상태일까?
각 단계는 정상이지만, 순서가 바뀌면 깨졌습니다.
시작할 때의 상태만 믿지 않고 결과를 저장할 때 다시 확인했습니다. 캐시 만료, 늦은 조회, 작업 점유, 구·신 버전이 공존하는 배포를 나누어 보고 각각의 복구 조건을 정했습니다.
서버가 늘어나면, 어느 서버의 캐시가 맞는지도 정해야 합니다.
증상과 배경
관리자가 권한이나 앱 버전 정책을 바꿔도 다른 서버의 로컬 캐시는 이전 값을 가지고 있었습니다. 그렇다고 로컬 캐시를 모두 없애면 Redis 장애 때 인증 요청이 DB 조회로 몰릴 수 있었습니다.
서명을 다 받았다는 것과, 최종 파일이 준비됐다는 것은 다릅니다.
증상과 배경
모든 사람이 서명한 뒤에도 PDF 합성, 저장소 쓰기, 외부 타임스탬프 발급이 남습니다. 이를 하나의 완료 상태로 다루면 아직 준비되지 않은 파일을 안내하거나, 외부 서비스 지연을 계약 제출 실패로 오해하게 됩니다.
새 버전이 뜨기 전에, 쓰던 서버부터 내리지 않도록.
증상과 배경
기존 컨테이너를 내리고 새 컨테이너를 올리는 배포 방식에서는 그 사이 요청을 받을 프로세스가 없었습니다. 앱을 쓰고 있는 사용자가 매 배포의 영향을 받는 문제였습니다.
이 검사는 무엇을 실행하지 않고 있었을까?
테스트의 초록불과 실제 성공은 달랐습니다.
테스트가 건너뛴 프레임워크 처리와 외부 연결을 찾고, 수정 전 결함에서도 검사가 실패하는지 확인했습니다. 지적의 개수나 성공 로그보다 실제 목표를 확인하는 증거를 우선했습니다.
알림이 안 온다는 신고를, 실제 HTTP 요청 순서로 다시 풀었습니다.
증상과 배경
신규 회원의 알림이 오지 않았습니다. 푸시를 보내는 함수만 볼 문제가 아니라, 알림을 받을 기기의 토큰 등록부터 실패하는 상황이었습니다. 이미 배포된 앱을 고치려면 스토어 심사와 사용자 업데이트를 기다려야 했습니다.
많이 지적한 리뷰가, 찾으려던 결함은 놓쳤다
증상과 배경
광범위한 AI 감사가 여러 실제 문제를 찾아도 목표 결함을 놓치는 경우가 있었습니다. 리뷰를 더 많이 돌렸다는 사실만으로 충분히 확인했다고 말할 수 없었습니다.
송장 API의 성공 응답만으로는 배송 업무가 끝나지 않았다
증상과 배경
송장 발급이 실패하거나 발급 후 DB에 남지 않았고, 저장한 출력 링크를 다시 열면 사용할 수 없는 문제가 이어졌습니다.
처리 장소나 계산 순서를 바꾸면 어떨까?
같은 일을 더 크게 돌리는 것으로는 풀리지 않았습니다.
반복 재시도와 자원 증설에 앞서 병목이 생기는 단위를 확인했습니다. 긴 리포트는 웹 요청과 분리하고, 큰 지도는 표본과 타일 계층으로 나누어 최종 사용 방식에 맞췄습니다.
재시도해도 잘리는 리포트: 실행 장소를 바꿨다
증상과 배경
긴 유료 리포트가 생성 도중 끊겼습니다. 같은 요청을 다시 보내도 HTTP 실행 제한을 넘기면 결과는 달라지지 않았고, 일부 상품은 생성 분기 자체가 빠져 있었습니다.
메모리를 늘리는 대신, 부모 타일의 계산 순서를 바꿨다
증상과 배경
좌표를 확대 수준별 타일로 만드는 SQL 윈도 연산이 메모리 부족으로 중단됐습니다. 원본을 나눠 수집했어도 가시화 단계에서 다시 전체 데이터를 크게 묶으면 같은 병목이 생겼습니다.