기록 / 검증
무엇으로 확인했는가.
바꾼 판단과, 그 판단을 지지하는 근거를 나란히 읽습니다. 테스트가 확인하지 못한 범위도 함께 남겼습니다.
실행했는가?
실제 요청 경로에브리톡단위 테스트가 실행하지 않는 앞단은 없었을까?
- 바꾼 판단
- 정상 설치본의 요청을 서버에서 받을 수 있게 고쳤습니다. 전역 검증을 느슨하게 만드는 대신 등록 라우트의 검증 앞에서 선택 기기 정보를 정리했습니다. 너무 긴 기기 식별자는 잘라 저장하면 다른 기기와 겹칠 수 있어 버리고, 진단용 앱 버전만 길이를 제한했습니다. 사용자 ID는 요청 body가 아닌 인증 정보에서 가져오도록 유지했습니다.
- 확인한 근거
- 실제 interceptor·ValidationPipe·DTO를 연결한 HTTP 테스트와, 컨트롤러가 정규화한 값을 저장 서비스에 넘기는 테스트를 분리했습니다. 결함을 되돌렸을 때 정상 앱 요청이 다시 실패하는지도 확인했습니다. 당시 복구 기록에서는 토큰 등록·기기 정보 저장과 사용자 수신 확인을 각각 남겼습니다.
토큰 등록 성공과 실기기 전달 성공은 다릅니다. HTTP 파이프라인 테스트가 인증·DB·Firestore·FCM을 전부 검증하는 것도 아니므로, 각 연결 구간과 실제 수신을 별도로 확인했습니다.
최종 산출물안심사인화면에서 받은 값이 완성된 결과에도 남아 있을까?
- 바꾼 판단
- 기존 한 줄 필드는 유지하고 긴 글 필드는 줄바꿈하도록 나눴습니다. 그래도 넘치는 필드는 잔여 부분이 아닌 전문을 별지에 싣고, 원래 쪽 번호와 필드 이름을 함께 표시했습니다. 첫 장의 종이 규격을 따르며, 넘친 내용이 없을 때는 별지를 만들지 않습니다.
- 확인한 근거
- 렌더 함수만 시험하면 실제 DB 조회에서 필드 이름이 빠져도 통과했습니다. 조회부터 출력까지 이어지는 통합 검증을 추가했습니다. 이후 빈 줄 정리용 AI 초안의 정규식이 긴 입력에서 워커를 오래 점유하는 반례가 나와 줄 단위 처리로 바꿨습니다. 페이지 수뿐 아니라 문단 보존·공백 처리 결과·긴 입력의 시간 상한도 검사하도록 보강했습니다.
별지에는 페이지 상한이 있고, 초과 시 미수록 안내를 남깁니다. 모든 길이의 글이 항상 PDF에 담긴다는 보장은 하지 않습니다. 표시를 정리해도 원문은 필드 데이터에 남기며, 원문 전체를 감사 이벤트에 저장하는 구조는 아닙니다.
반례와 음성 대조배포 검증 워처결함을 다시 넣었을 때도 검사는 통과할까?
- 바꾼 판단
- 넓은 감사, 구조화된 리뷰, 특정 명제를 반증하도록 요청하는 방식을 비교했습니다. 의견의 수보다 직접 작성한 실행 프로브와 반례를 우선하고, 수정 전 코드에서도 검사가 실패하는지 확인했습니다.
- 확인한 근거
- 넓은 감사가 놓친 목표를 구조화 리뷰와 반증 요청이 찾은 기록을 남겼습니다. 한 시험에서 사라진 오탐도 여러 시드에서 다시 나타나자, 검출 한계와 제품 설명을 함께 수정했습니다.
대상은 알려진 결함 두 개이며 일부 조합은 미실행입니다. 제공 정보량도 같지 않아 특정 프롬프트가 항상 우월하다거나 모델의 일반 정확도를 측정했다고 말하지 않습니다.
거래·상태 대조의류 쇼핑몰 운영 개선같은 환불을 여러 화면이 같은 의미로 읽을까?
- 바꾼 판단
- 클라이언트의 종결 값을 없애고 서버가 결제 잔액·취소액·공제액으로 다시 판단하도록 바꿨습니다. 누적 환불액을 기록하고 관련 집계는 원 결제액에서 환불액을 빼도록 맞췄습니다.
- 확인한 근거
- 정정 전 미리보기, 당시 PG와 주문 DB의 거래 대조, 종결 규칙의 경우별 검사를 사용했습니다. 새 검사가 이전 로직에서는 실패하는지도 확인한 기록을 남겨 수정 효과를 구분했습니다.
PG 취소 후 내부 DB 기록에 실패할 수 있는 경계가 남아 있습니다. 고객 등급은 후속 주문 처리에서 금액을 읽는 구조로, 환불 직후 모든 등급이 자동 재계산되는 것은 아닙니다.
전환 이후의 관측에브리톡이전 버전을 꺼도 새 버전이 요청을 받을까?
- 바꾼 판단
- 유휴 슬롯을 먼저 띄우고 nginx 설정 검사 후 upstream을 바꾸도록 배포를 구성했습니다. 전환 직후뿐 아니라 구 슬롯을 드레인·정지한 뒤에도 응답을 다시 확인합니다. 실패 단계에 맞춰 upstream·유휴 슬롯·이미지 태그를 복구하고, 구 슬롯 정지가 실패하면 정상 완료 대신 수동 확인 상태를 남깁니다.
- 확인한 근거
- 정방향과 역방향 스왑, 없는 이미지와 부팅 실패를 나누어 시험했습니다. 내부·외부 프로브로 당시 관측창의 응답을 기록하고 실패 시 기존 슬롯 유지와 정리를 확인했습니다. 이후 DB·캐시와 분산 상태를 먼저 정리한 뒤 ALB·ASG 운영으로 전환했으며, 그 단계는 별도로 노드 상태·의존 서비스·배포 이미지 일치를 확인했습니다.
슬롯 스왑은 단일 호스트 시절의 배포 방식이며 현재의 ALB·ASG 롤링과 다릅니다. DB 변경은 구·신 버전이 함께 쓰는 구간의 호환성을 따로 검토해야 합니다. 후속 ASG 구성에서도 이전 이미지로 재롤링하는 복구와 AWS의 자동 롤백 지원을 같은 것으로 취급하지 않았습니다.
실험과 출력 비교Noosphere학습 수치가 좋아진 방법이 화면에도 더 적합할까?
- 바꾼 판단
- 최종 배치는 PCA로 차원을 줄인 뒤 GPU에서 유사한 앵커를 찾아 그 좌표를 가중 결합하는 방식을 택했습니다. 모델을 더 크게 만드는 방향보다, 탐색 화면에 필요한 결과를 내는 경로를 선택했습니다.
- 확인한 근거
- 학습 스크립트·저장 모델·투영 플롯이 남아 있고, 최종 배치 스크립트가 회귀 모델이 아닌 앵커 경로를 사용함을 대조했습니다. 선택 이유를 실험의 수치와 시각 관측으로 나눠 기록했습니다.
서로 다른 후보의 시각 비교를 동등 조건의 일반 성능 벤치마크로 제시하지 않습니다. 지도 좌표가 논문 간 의미 관계를 정확히 보존한다거나 새로운 임베딩 모델을 학습했다는 주장도 하지 않습니다.
기록을 남기는 이유
다음 판단에 쓸 수 있도록.
나중에 다시 볼 때 필요한 것은 완료 표시만이 아니었습니다. 처음의 가설, 버린 대안, 결함이 나타나는 입력과 순서, 실제 반영한 버전이 있어야 같은 문제인지 다른 문제인지 구분할 수 있었습니다.
그래서 후속 확인이 이전 진단을 뒤집으면 설명도 고칩니다. 푸시 장애의 원인을 앱 버전 차이에서 서버 요청 처리 순서로 정정한 일처럼, 처음부터 정답을 알았던 이야기로 다시 쓰지 않으려 합니다.
고객 정보와 운영 접속 정보가 포함될 수 있는 원문 일지·로그는 공개하지 않습니다. 이 사이트에는 맥락과 담당 범위, 공개 가능한 검증 결과만 옮겼습니다.
문제 유형별로 다시 읽기