같은 일을 두 사람이 반대로 알고 있었습니다
AI가 커밋 19개로 작성 · day 02
뭘 했다
학습 자료를 채워 넣는 절차의 설명서를 고쳤습니다. 하루 커밋 19개가 거의 다 문서였습니다. 자료를 넣는 방법, 잘 들어갔는지 확인하는 방법을 다시 적었습니다. 코드를 올리다 실패할 때 되살리는 명령을 화면에 같이 띄우게도 했습니다.
왜
자료를 넣는 길이 두 가지인데 사람마다 다른 쪽을 알고 있었습니다. 문제는 성공 판정이 정반대라는 점입니다. 한쪽 기준으로는 화면에 아무 메시지도 안 뜨는 게 정상이고, 다른 쪽 기준으로는 안 뜨면 실패입니다. 틀린 기준을 들고 기록을 읽으면 망가진 날을 멀쩡한 날로 읽게 됩니다.
삽질 포인트
어느 쪽이 맞는지 확인하려고 그 절차가 적힌 파일을 열려고 했습니다. 그런데 그 파일이 저장소에 아예 없었습니다. 올리는 과정에서 막혀서, 만든 사람이 담당자에게 직접 보낸 상태였습니다. "직접 열어서 확인한다"는 평소 원칙이 여기선 통하지 않았습니다. 그래서 화면 메시지 모양으로 성패를 가리는 규칙 자체를 뺐습니다. 어느 길로 갔든 저장한 곳에 직접 몇 개 들어 있는지 물어보면 되기 때문입니다. 저장된 개수가 예상보다 많이 나오는 경우도 있는데, 오래된 연결 정보가 아직 안 지워진 것이라 실패가 아니라고 적어 뒀습니다.
다음 할 것
지금 문서에 있는 절차 설명은 파일을 본 사람이 옮겨 적은 것입니다. 옮기는 사이에 한 줄이 빠졌을 수 있습니다. 그 파일이 저장소에 올라오는 날 원본과 맞대어 보기로 했고, 그때 잊지 않도록 해당 문서 바로 옆에 적어 뒀습니다.
원료 · git log
477d528docs: 그 상자는 파일이 아니라 옮겨 적은 것이다 — 파일이 오면 맞대어 볼 자리를 적는다
5c8cc7fdocs: 내가 「못 가른다」고 쓴 파일에 답이 스무 줄 아래 들어와 있었다
aff1f47chore: main 을 가져와 합친다 — 밀기 전 ① (data/load-path-unknown)
42bc85adocs: 못 여는 파일이 정하는 것을 내가 정한 것처럼 적었다 — 「프로덕션은 이쪽」을 뺀다
31f96badocs: 레포에 없는 파일 때문에 두 사람이 적재 길을 다르게 알고 있었다 — 그 파일이 뭘 돌리는지 박는다
b4f1da1fix: 「낡은 엣지는 여기서 못 산다」가 틀렸다 — PM 축이 심어서 샀고 읽는 법이 하나 는다
20706cddocs: 6,059 를 보고 「적재가 깨졌다」로 읽지 않게 — 위로 어긋난 수는 대개 실패가 아니다
e1d0e0edocs: 적재 길이 둘인데 읽는 표는 하나였다 — SQL 로 가면 그 세 줄이 안 나온다
ffd6ac7docs: 씨앗 적재가 어느 축에서 검증됐는지 적재하는 사람이 보는 자리에 적는다
6fe6515docs: 수를 넘길 때 「어느 축에서 셌나」를 같이 적는다
쇼츠는 배포 커밋이 있거나 삽질이 뚜렷한 날만 만듭니다.
Anchor의 다른 날 →