문제가 생기면 데이터와 인프라 흐름부터 확인합니다.

문제

카카오톡에서 geonu.site 링크를 누르면 보안상의 이유로 열리지 않았습니다. 데스크톱 브라우저에서는 경고를 넘기면 접속돼서 바로 드러나지 않았습니다.

확인 순서

1. DNS부터 확인했습니다. apex A 레코드는 GitHub Pages IP 4개(185.199.108~111.153)를 정확히 가리켰고, www CNAME도 정상이었습니다. 리졸버 두 곳에서 같은 값이 나왔습니다.
2. CAA 레코드가 발급을 막는 경우가 있어 조회했지만 레코드 자체가 없었습니다. apex에 CNAME이 잘못 들어간 것도 아니었습니다.
3. 인증서를 직접 받아봤습니다. openssl s_client로 확인한 subject가 CN=*.github.io였고, SAN 목록에 geonu.site가 없었습니다.
4. GitHub Pages API를 조회하니 https_certificate 객체 자체가 없었습니다.

원인

DNS 문제가 아니라 GitHub 쪽에서 커스텀 도메인 인증서 발급이 끝나지 않은 상태였습니다. 그래서 기본 와일드카드 인증서가 그대로 제시됐고, 호스트명이 맞지 않아 TLS 연결이 실패했습니다. 카카오톡 인앱 브라우저는 이 경우 우회 선택지 없이 차단합니다.

조치

DNS는 손대지 않았습니다. GitHub Pages 설정에서 커스텀 도메인을 지웠다가 다시 등록해 인증서 발급을 새로 걸었고, 발급이 끝난 뒤 Enforce HTTPS를 켰습니다.

결과

https://geonu.site가 HTTP/2 200으로 응답하고, Pages API의 인증서 상태가 approved, https_enforced가 true로 바뀌었습니다. 저장소 전체에 http:// 참조는 0건이라 혼합 콘텐츠 문제는 없었습니다.

문제

추천이 화면에 노출된 기록은 쌓이는데, 개인화 랭킹 학습에 필요한 긍정 label이 한 건도 만들어지지 않았습니다.

확인 순서

1. 모델을 다시 학습시키기 전에 학습 SQL의 join 조건과 실제 저장된 이벤트를 대조했습니다.
2. 노출과 행동을 잇는 키 값을 조회하니 44건이 전부 비어 있었습니다. label이 0건이면 재학습해도 결과가 같으므로 모델이 아니라 값의 경로를 봤습니다.
3. Frontend의 세션 생성 → API 요청 본문 → 이벤트 저장 → 학습 데이터 순서로 각 구간에서 값이 실려 있는지 확인했습니다.

원인

백엔드 요청 모델에는 필드가 있었지만 Frontend가 요청 본문에 값을 싣지 않아 저장 시점부터 비어 있었습니다. 학습 SQL은 그 키로 조인하므로 한쪽이 비어 있으면 조인되지 않습니다.

조치

전달 경로를 수정하고, 수정 후 이벤트가 실제로 값을 갖고 저장되는지와 학습 데이터가 연결되는지를 다시 확인했습니다.

결과

끊겨 있던 노출과 행동의 연결이 복구돼, 이후 쌓이는 데이터부터는 label이 생성될 수 있는 상태가 됐습니다.

문제

응답 내용은 문제가 없는데 검증 단계에서 막히는 경우가 반복됐습니다. 막히면 템플릿 답변으로 대체되므로 사용자가 보는 답의 품질이 떨어졌습니다.

확인 순서

1. 모델을 바꾸자는 판단으로 가기 전에 실패한 케이스를 모아 다시 봤습니다.
2. 상당수가 환각이 아니라 사용자가 질문에 쓴 재료와 금액을 그대로 되풀이한 것이었고, 검증 로직이 그것을 근거 없는 내용으로 오판하고 있었습니다.

원인

근거로 인정하는 범위에 사용자 질문이 빠져 있었습니다. 「8천원」 같은 한글 수사 표현도 숫자와 이어지지 않았습니다.

조치

근거 문자열에 사용자 질문 원문과 한글 수사를 숫자로 편 정규화 결과를 함께 넣도록 처리 방식을 바꿨습니다. 모델은 교체하지 않았습니다.

결과

같은 275건 평가 세트를 다시 돌려 통과가 166건에서 247건으로 늘었습니다(약 60% → 90%). 문자열 구성만 바꾼 변경이라 LLM 호출은 늘지 않았습니다.

문제

워크로드는 정상으로 보이는데 새 배포만 실패했습니다. 파드 상태와 재시작 횟수만 보면 이상이 없었습니다.

확인 순서

1. 기존 파드가 왜 멀쩡한지부터 봤습니다. 노드에 남아 있던 이미지로 계속 실행되고 있었고 재시작도 0이었습니다.
2. 실패가 언제 드러나는지 좁혔습니다. 레지스트리 접근이 필요한 순간, 즉 새 배포나 재스케줄링에서만 실패했습니다.
3. 주기적으로 도는 점검이 이미 실패 신호를 만들고 있었는데, 그 실패 자체에는 알림이 걸려 있지 않아 아무도 모르고 있었습니다.

원인

레지스트리에 닿지 못하는 상태였고, 캐시된 이미지 덕분에 겉으로는 정상처럼 보였습니다.

결과 / 배운 점

파드가 Running인 것과 새 배포가 가능한 것은 다릅니다. 현재 상태가 정상인 것과 다음 변경을 수행할 수 있는 것은 별개이고, 둘 다 운영 상태의 일부입니다. 점검 실패를 대응으로 연결하려면 알림 경로도 함께 확인해야 합니다.

문제

매일 새벽 3시 30분에 도는 수집 작업에서 첫 카테고리 하나만 사흘 연속 아무것도 못 가져왔습니다. 그런데 작업 자체는 실패 건수 0으로 기록돼 성공처럼 보였습니다.

확인 순서

1. 실패한 실행의 소요 시간 15.4초를 성분으로 나눴습니다. 대기 루프가 구조상 최소 15초를 차지하므로, 페이지를 여는 데 쓴 시간은 아무리 커도 0.4초 미만이었습니다.
2. 정상일 때와 비교했습니다. 같은 클러스터의 정상 파드는 0.62초, 프로덕션과 같은 브라우저로 로컬에서 35회 재보니 전부 0.49~0.95초였습니다. 페이지가 무거워 그 아래로 내려갈 수 없는 구조였습니다.
3. 총 소요가 정상 셸의 대기 루프 단독보다도 짧았습니다. 매 폴링마다 도는 요소 개수 조회가 훨씬 쌌다는 뜻이고, 곧 받은 문서가 작았다는 뜻입니다.

원인 범위

그 시각 첫 요청이 받은 것이 평소의 카테고리 페이지가 아니라 앱 번들이 붙지 않은 작은 문서였다는 정황까지 좁혔습니다. 다만 그 응답의 실제 HTTP 상태와 종류는 확보하지 못해 무엇이었는지는 확정하지 않았습니다. 차단·오류 페이지가 유력한 후보였습니다. 네트워크 지연이나 파드 축출, DNS 재시작 같은 후보는 근거가 맞지 않아 기각 목록에 남겼습니다.

조치

응답의 종류를 구분하지 못하게 한 관측 공백은 코드에 있었습니다. 페이지 이동의 응답 객체를 버려서 HTTP 상태코드가 로그에 남지 않았고(브라우저 자동화는 4xx·5xx에 예외를 던지지 않습니다), 렌더 대기 함수의 반환값도 버려서 「한 장도 렌더되지 않음」과 「렌더는 됐지만 파싱이 0」이 구분되지 않았습니다. 이 관측 공백을 조사 기록으로 남겼습니다.

결과 / 배운 점

부분 실패를 성공으로 적으면 다음 사람이 같은 조사를 처음부터 다시 합니다. 실패 건수만 보지 않고 기대 수량 대비 실제 수집량을 함께 보는 편이 안전합니다. 조사 내내 클러스터는 읽기만 했고 변경은 로컬에서만 재현했습니다.

문제

영수증을 찍어 품목과 금액을 자동으로 넣으려면 감열지 인쇄와 구겨진 종이에서도 구조화된 결과가 나와야 했습니다. 어떤 방식이 맞는지 미리 알 수 없었습니다.

확인 순서

1. 무엇을 성공으로 셀지부터 정했습니다. 합계 정합 — 추출한 품목 금액의 합이 영수증 총액과 맞으면 성공입니다.
2. 같은 지표의 한계도 같이 적었습니다. 품목이 한두 개인 영수증은 쉽게 통과하고, 총액을 못 읽으면 품목이 맞아도 실패로 처리됩니다. 즉 절대 수치는 무르고 방식 간 상대 순위만 견고합니다.
3. 실물 13장을 5개 방식에 통과시켰습니다. 다운스케일, 재시도, 타임아웃을 모두 고정했습니다.

결과

경량 비전 모델이 합계 정합 기준 13장 중 12장이었고 실행 오류가 없었습니다. 추론 옵션을 켠 상위 모델은 더 낫지 않으면서 비용이 수십 배였고, 로컬 엔진은 구조화 출력 자체가 나오지 않았습니다.

조치

경량 비전 모델을 채택하고, 사용자가 결과를 확인·수정하는 단계를 앞에 둬서 인식 오류를 사람이 보정할 수 있게 했습니다.