- 1테크 노트
재시도 횟수로는 실행을 설명할 수 없었습니다(1편)
도구를 세 번 쓴 실행과 품질 검증에 세 번 실패한 실행이 같은 '재시도 3회'로 남았습니다. 생성·검증·도구 실행·재시도를 하나의 반복문에서 꺼내 명시적인 상태와 전이로 나눈 과정입니다.
- 2테크 노트
저장소를 나눴는데 의존성은 그대로였습니다(2편)
엔진을 별도 모듈로 옮겼지만 실행하려면 제품의 설정 객체와 데이터베이스 세션, 캔버스 노드를 먼저 불러와야 했습니다. 독립을 선언한 사흘 뒤부터 누수를 잡으며 배운, 경계가 닫혔는지 확인하는 방법입니다.
- 3테크 노트
설치는 됐는데 같은 실행이라고 부를 수 없었습니다(3편)
워크플로우를 wheel로 묶어 다른 환경에 설치했습니다. 도구를 호출하자 제품 안에서만 성립하던 전제가 드러났습니다. 포장 형식을 두 번 갈아엎으며 무엇을 고정해야 실행이 옮겨가는지 확인한 과정입니다.
- 4테크 노트
답을 만든 모델에게 채점까지 맡기고 있었습니다(4편)
같은 모델이 답을 만들고 이어서 자기 답이 규칙을 지켰는지 판단하면 생성 방법과 합격 기준이 한 컨텍스트에 섞입니다. 업무를 수행하는 책임과 결과를 채택하는 책임을 나누고, 나눈 뒤에도 남은 한계를 정리합니다.
- 5테크 노트
제출 도구를 부르고도 실행이 멈추지 않았습니다(5편)
종착 도구가 성공했는데 실행이 계속됐고, 반대로 이전 회차의 기록만 보고 현재 회차를 일찍 끝내기도 했습니다. 다시 호출하는 이유와 종료를 소유하는 위치를 나눈 과정입니다.
- 6테크 노트
검증셋을 떼어뒀다고 믿었는데 아니었습니다(6편)
설정을 자동으로 탐색하게 만들면서 승격 문턱과 검증셋을 뒀습니다. 구현을 다시 읽어보니 후보를 제안하는 쪽이 그 검증 기록을 보고 있었습니다. 자동 탐색기에 무엇을 맡길 수 있고 무엇을 맡길 수 없는지 정리합니다.
- 7테크 노트
30배 차이가 모델의 차이가 아니었습니다(7편)
같은 워크플로우에 두 모델을 연결하니 2,488초와 84초가 나왔습니다. 반복 횟수와 출력 상한을 맞추자 2,488초가 100초가 됐습니다. 모델을 비교하기 전에 무엇을 고정해야 하는지 정리합니다.
- 8테크 노트
가까운 기억이 항상 이기게 두면 안 됐습니다(8편)
세션 요청이 플랫폼 정책보다 구체적이니 우선해야 할 것 같았습니다. 그렇게 두면 사용자가 정책을 덮어쓸 수 있었습니다. 실행 간 기억의 범위와 종류를 나누고 충돌을 푼 과정입니다.
- 9테크 노트
도구가 목록에는 보이는데 부를 수는 없었습니다(9편)
검색 범위를 좁히려고 허용 목록을 걸었더니 사용자가 직접 연결한 도구까지 함께 빠졌습니다. 이름 공개와 스키마 공개와 실행 권한을 각각 다른 시점에 두게 된 과정입니다.
- 10테크 노트
재시도를 다 썼는데 같은 답을 계속 채점하고 있었습니다(10편)
품질 재시도가 상한을 전부 쓰고 끝났습니다. 기록을 따라가니 모델은 도구를 부르며 진행 중이었고 판정기는 직전 실패 답을 다시 채점하고 있었습니다. 점수와 후보의 수명을 한 회차로 묶은 과정입니다.
