PUNCHBLOG / SERVER NOTES
서버 연결부터 배포와 복구까지, 실험과 근거로 읽습니다.
Python 표준 라이브러리 재현 · 2026.10.23
| 원본 입력 | 직접 연결 후 파싱 | urlencode 후 파싱 |
|---|---|---|
| C++ | C␠␠ | C++ |
| A␠B | A␠B | A␠B |
| 서울&부산 | 서울 | 서울&부산 |
여섯 입력의 왕복 검사를 실행한 기록 중 세 사례입니다. ␠는 공백입니다. 브라우저나 실제 검색 서버의 시험 결과는 아닙니다.
이 표의 계산 기록 JSON 보기 ↗HTTP
Python 표준 라이브러리로 여섯 검색어를 직접 연결한 쿼리와 urlencode 결과를 대조했습니다. +·&·=·빈값·중복 키를 구분하고 원본 입력이 돌아오는지 검증하는 코드를 공개합니다.
발행
Nginx
네 서비스의 화면 이전 뒤 설치 앱의 데이터 주소까지 410이 된 문제를 확인했습니다. 화면 종료와 데이터 호환 경로를 나눈 복구 및 공개 GET 12건을 기록합니다.
발행
HTTP
같은 네 경로에 HEAD와 GET을 보내 상태·본문·릴리스 문자열을 비교했다. 200 응답만으로 배포 완료를 판단할 수 없는 경우를 격리 실험으로 확인한다.
발행
배포
실제 DNS 변경 전후 기록에서 406과 2406의 차이를 확인했다. 주소 형식 검사만으로 놓치는 문제, IPv4·IPv6를 따로 검사한 결과와 수정 범위를 검증한 방법을 정리한다.
발행
HTTP
Python HTTP 서버·대기 스레드·의존성 변수를 사용한 격리 실험입니다. 응답 가능 여부와 준비 상태를 나누며 실제 작업 완료를 시험한 것과 구분합니다.
발행
데이터·자동화
WAL 모드에서도 writer는 하나뿐이었다. timeout 0초·0.2초·1.5초를 비교해 즉시 실패, 대기 후 실패, 잠금 해제 뒤 성공을 실제로 측정한다.
발행
데이터·자동화
서비스를 stop해도 타이머가 다시 실행했고, disable된 타이머도 active 상태로 남았다. 실제 systemd 사용자 유닛 실험으로 중지·등록 해제·완료 조건의 차이를 확인한다.
발행
데이터·자동화
같은 Python 스크립트도 실행 위치와 환경변수가 달라지면 실패했다. 여덟 가지 격리 실험으로 상대 경로, 필수 설정, PATH 문제를 구분하고 예약 작업에서 확인할 조건을 정리한다.
발행
데이터·자동화
8 MiB 임시 로그를 지운 뒤에도 할당 공간이 남고 추가 기록이 가능했다. 같은 이름의 새 파일과 기존 파일 디스크립터를 비교해, 삭제 뒤 용량이 줄지 않는 원인을 좁힌다.
발행
Nginx
같은 합성 문장을 identity와 gzip으로 요청했다. 6,160바이트가 317바이트로 전송된 조건과 짧은 파일이 압축되지 않은 조건을 구분한다.
발행
데이터·자동화
파일을 절반만 쓴 순간을 고정해 읽었다. 직접 덮어쓰기의 JSON 오류와 임시 파일 검증 후 교체의 결과를 비교한다.
발행
HTTP
같은 루프백 서버에 네 가지 방식으로 접속했다. SNI, 인증서 이름, CA 신뢰를 구분하고 검증을 유지한 원본 확인 방법을 살핀다.
발행
HTTP
응답을 받지 못해도 서버에는 메모가 남아 있었다. 단순 재시도와 같은 요청 키로 기존 결과를 돌려주는 처리를 비교했다.
발행
HTTP
없는 글뿐 아니라 없는 CSS도 홈 HTML과 200으로 돌아올 수 있었다. 정상 글·없는 글·없는 자산을 비교해 정적 사이트의 잘못된 fallback을 찾는다.
발행
HTTP
첫 요청의 ETag를 다음 요청에 돌려보냈다. 같은 파일이 200에서 304로 바뀌었을 때 무엇을 다시 쓰는지 정리한다.
발행
Nginx
MISS → HIT → STALE을 순서대로 재현했다. 장애 중 저장본을 내보내는 설정과 모니터링의 사각지대를 함께 살핀다.
발행
Nginx
location에 헤더 하나를 추가하자 상위 헤더가 빠졌다. 정상 응답과 404를 나눠 확인하고, 문법 검사가 놓치는 설정 동작을 살핀다.
발행
Nginx
잘못된 후보는 검사에서 걸렸지만, 올바른 후보도 검사만으로는 실행 중인 응답을 바꾸지 못했다. 후보 파일, 반영 대상, 실제 응답을 차례로 확인하는 절차를 정리한다.
발행
배포
두 완성된 디렉터리 사이에서 current 링크를 교체했다. 재시작 없이 바뀐 응답과, 이것만으로 해결되지 않는 배포 문제.
발행
배포
Lightsail에 도메인이 보여도 실제 DNS는 Cloudflare가 담당했다. DNS, 서버의 도메인 설정, HTTPS 인증서를 나눠 확인하고 연결한 과정과 공개 응답을 기록한다.
발행
데이터·자동화
무결성 검사는 통과했지만 16개 중 12개만 남은 복사본을 만들었다. WAL 상태, backup API, 별도 경로 복구를 비교한다.
발행
데이터·자동화
첫 작업이 끝나기 전에 두 번째 작업을 시작했다. 잠금 유무, 건너뛰기, 비정상 종료 후 다음 실행을 임시 프로세스로 확인한다.
발행
