문서를 고친 뒤 새로 생긴 결함을 찾는 법저희 개정 78건에서 5건이 나왔습니다
공정에는 불량률이 있고, 누구나 그 숫자를 관리합니다. 그런데 고치는 작업의 불량률은 잘 따지지 않습니다. 결함을 찾는 일에는 검사와 판정과 기록이 붙는데, 찾아낸 것을 반영하는 일은 "처리 완료" 한 줄로 넘어갑니다. 지적 78건을 반영했으면 78건이 없어진 것으로 칩니다.
#엔지니어링
이 태그가 붙은 글 · 모두 13편
자동화가 막히는 자리는 대개 브라우저 밖입니다
이틀 동안 브라우저 자동화가 세 번 멈췄습니다. 셋 다 코드가 틀려서가 아니었고, 셋 다 브라우저 안이 아니라 밖에서 막혔습니다. 막힌 자리를 정리해 두면 다음에 같은 곳에서 시간을 안 들입니다. 그리고 셋을 나란히 놓으니 처리 방법이 세 가지뿐이라는 것도 보였습니다.
운반은 한 대를 빠르게 해서 빨라지지 않습니다AMR과 설비를 군집으로 제어해야 하는 이유
공장에서 설비 한 대의 성능을 올리는 일은 대개 그 설비 안에서 끝납니다. 프레스를 빠르게 하면 프레스가 빨라집니다. 옆 설비에 물어볼 것이 없습니다. 운반은 그렇지 않습니다. AMR 한 대를 빠르게 해도 라인은 그만큼 빨라지지 않습니다.
저희 공장 시뮬레이터가 2ms마다 무엇을 계산하는지 적었습니다
저희가 만드는 공장 시뮬레이터를 462초 돌렸습니다. 생산 지시가 26번 나갔고, 10개가 라인에 들어갔고, 4개는 로봇이 집어 AMR에 싣고 건너편 로봇이 내려놓는 데까지 갔습니다. 접촉을 9,243번 재는 동안 AMR이 벽이나 다른 AMR에 닿은 횟수는 0이었습니다.
저희 블로그 태그 226개 중 163개가 글 한 편짜리였습니다
저희 기술블로그의 태그를 전부 세어 봤습니다. 글 106편에 태그가 226개였고, 그중 163개(72%)가 글 한 편에만 붙어 있었습니다. 태그 하나에 글 한 편. 독자가 그 태그를 누르면 글 한 편이 나옵니다. 방금 읽고 있던 그 글입니다.
검사 결과가 0건일 때, 없는 것과 검사가 고장 난 것을 어떻게 가릅니까
검사를 돌렸는데 결과가 0건으로 나왔습니다. 이때 우리는 보통 안심합니다. 걸린 게 없다는 뜻이니까요. 그런데 0은 두 가지를 동시에 뜻합니다. 정말 없거나, 검사가 고장 났거나. 이 둘은 화면에서 똑같이 생겼습니다. 오류 메시지도, 빨간 글자도, 종료 코드 1도 없습니다. 그냥 조용히 0입니다.
저희 검사 스크립트가 자기 성적을 잘못 보고하고 있었습니다
AI에게 일을 맡기기 시작하면 검사 장치가 따라 늘어납니다. 사람이 결과물을 일일이 다 볼 수 없으니 자동으로 훑는 스크립트를 만들어 붙이고, 그 스크립트가 통과를 내면 다음 단계로 넘깁니다. 코드 린터, 테스트, 배포 전 점검, 문서 검사 — 형태는 달라도 하는 일은 같습니다. 사람 대신 봐 주는 것입니다.
원본과 사본을 구분하지 않아, 고칠 자리를 3개월 동안 잘못 봤습니다
데이터를 보고 결정하는 일에는 잘 안 보이는 단계가 하나 있습니다. 그 데이터가 원본인지, 원본을 요약한 사본인지는 화면에 적혀 있지 않습니다. 두 화면은 대개 똑같이 생겼습니다. 같은 항목이 같은 자리에 있고 숫자만 다릅니다.
저희 사이트맵의 날짜를 구글은 무시하고 있었습니다
밖으로 신호를 보내는 일에는 공통된 약점이 하나 있습니다. 그 신호가 상대에게 어떻게 읽혔는지는 우리 쪽에 안 남는다는 것입니다. 메일을 보내면 보낸편지함에는 남지만 상대가 스팸으로 걸렀는지는 모릅니다. API를 호출하면 200이 돌아오지만 상대 시스템이 그 값을 버렸는지는 모릅니다.
같은 AI를 사용하는데 왜 결과가 이렇게 벌어집니까
같은 도구를 사용합니다. 같은 모델이고 요금제도 같습니다. 하루에 들이는 시간도 비슷합니다. 그런데 몇 달 지나면 나오는 양이 몇 배 차이 납니다. 프롬프트를 잘 쓰는 요령의 문제가 아닙니다. 도구에 무엇을 시키고 있는지가 다릅니다.
저희 시뮬레이터를 밤새 15번 스스로 고치게 했습니다무엇이 되돌릴 수 있게 했나
설비 수십 대가 맞물려 돌아가는 생산 라인을 3D로 재현하는 시뮬레이터를, 밤새 사람 없이 15라운드 돌렸습니다. 빌드 → 검증 → 수정 → 릴리스를 한 묶음으로 두고 그 묶음을 반복하게 한 것입니다. 아침에 결과를 열어 봤습니다.
저희가 배포한 규칙은 정말 팀에 도착했을까
팀이 사용하는 도구에 규칙을 하나 넣었다고 해 봅시다. 위험한 명령을 실행하기 전에 한 번 물어보는 확인, 파일을 고치기 전에 사본을 떠 두는 백업, 작업을 끝낼 때 빠뜨린 것이 없는지 훑는 점검 같은 것들입니다. 코드를 쓰고, 테스트를 돌리고, 초록불을 확인하고, 팀에 공지합니다.
테스트가 전부 초록인데 왜 사용자가 먼저 발견했을까
전에 저희는 이 블로그에 합의는 검증이 아니다라고 썼습니다. 같은 모델을 쓰는 에이전트 스무 개는 같은 오류에 만장일치로 동의하므로, 검증은 언제나 시스템 밖의 증거가 한다는 이야기였습니다.
