가격 단계를 깜빡했다
이날은 “순서를 설정이 아니라 코드에 명시해야 한다”는 교훈을 정리한 날이다.
스케줄러 설정에 순서를 숨겨놓으니까 단계가 빠졌다.
코드에 명시하니까 빠질 수가 없다.
그리고 위키에 적어놓고도 반복되는 실수의 원인이 템플릿이라는 것도 깨달았다.
법원경매 배치 파이프라인이 있었다.
크롤링하고 부동산 정보 보강하고 시세 매칭하고 분석한다.
근데 어느 날 분석 결과가 이상하게 나왔다.
원인을 추적하니까 시세 매칭 단계가 빠져 있었다.
크롤링하고 바로 분석으로 넘어간 거다.
시세 없이 분석하니까 당연히 결과가 이상하다.
왜 빠졌는가
파이프라인 순서가 스케줄러 설정에 들어 있었다.
근데 설정에서 시세 매칭 단계가 빠진 거다.
“설정을 깜빡했다.” 코드가 아니라 설정이니까, 검증도 안 된다.
컴파일 에러도 안 난다.
그냥 조용히 빠진다.
파이프라인을 코드로 명시한다
해결은 파이프라인 순서를 코드에 명시하는 거였다.
각 단계를 순수 함수로 만들고 워크플로 파일에서 순서를 조립한다.
순서가 코드에 적혀 있다.
설정을 깜빡할 수 없다.
이게 핵심이다.
“설정에 의존하는 단계”는 까먹을 수 있다.
“코드에 명시된 단계”는 까먹을 수 없다.
컴파일이 순서를 검증한다.
함수 호출이 순서를 보장한다.
부가: 의존성 역전도 수정했다
기존에는 핵심 모듈이 표현 계층을 import하고 있었다.
의존성 방향이 거꾸로였다.
핵심이 CLI를 의존하니까, CLI가 바뀌면 핵심이 깨진다.
이걸 바로잡았다.
핵심은 순수 함수로 만들고 워크플로가 핵심을 조립한다.
의존성이 올바른 방향으로 흐른다.
에이전트 3개를 1개로 통합했다
법원경매 분석 에이전트를 3개에서 1개로 통합했다.
권리 분석, 리스크 평가, 조언이 각각 따로 있었다.
근데 리스크 에이전트가 권리 맥락을 못 봤다.
구조적 맹점이었다.
권리를 분석한 결과를 리스크 에이전트가 못 보니까, 리스크 평가가 정확할 수가 없다.
권리를 모르는데 리스크를 어떻게 평가하는가.
통합의 원칙
에이전트를 분할하려면 정당성이 필요하다.
“역할이 다르니까 분할한다”가 아니라, “분할하지 않으면 구조적 맹점이 생긴다”는 증거가 있어야 한다.
이 경우에는 분할 자체가 맹점의 원인이었다.
권리랑 리스크가 서로를 필요로 하는데, 분리하니까 맥락이 단절됐다.
통합하니까 권리-리스크가 자연스럽게 통합됐다.
호출도 3분의 1로 줄었다.
중복 채점도 사라졌다.
10건 중 10건 분석 성공.
위키에 적었는데도 반복되는 실수
깃 커밋할 때 --no-pager 플래그를 잘못된 위치에 넣는 실수가 반복됐다.
7번째 발견이었다.
위키에 원인과 해결책을 적어놨다.
모델도 매번 올바르게 복구한다.
근데 매 세션마다 반복된다.
원인은 템플릿이다
원인이 모델이 아니라 스킬 템플릿이었다.
템플릿이 “모든 깃 명령에 —no-pager를 붙여라”라고 mechanically 적용하고 있었다.
--no-pager는 읽기 전용 하위 명령에만 의미가 있다.
커밋이나 푸시에는 페이지가 안 나오니까 의미가 없다.
근데 템플릿이 전부에 붙이고 있었다.
위키에 적어놓는 건 “모델이 알아차리면 고친다”는 거다.
근데 템플릿 자체가 원인이면, 모델이 위키를 읽고 고쳐도 다음 세션에서 템플릿이 다시 잘못된 지시를 준다.
해결은 템플릿을 고치는 거다.
“읽기 전용 하위 명령에만 —no-pager를 붙여라”로 좁혔다.
근본 원인을 고치니까 반복이 멈춘다.
마무리
내가 이날 배운 핵심은 다음과 같다.
이날의 핵심은 “근본 원인을 코드로 고쳐라”였다.
파이프라인 순서를 설정이 아니라 코드에 명시했다.
설정을 깜빡하는 사고가 구조적으로 불가능해졌다.
“설정에 의존하는” 건 까먹을 수 있지만 “코드에 명시된” 건 까먹을 수 없다.
깃 실수도 같은 원리다.
모델이 매번 올바르게 복구하는데도 반복된다.
원인이 모델이 아니라 템플릿이니까, 모델을 고치는 게 아니라 템플릿을 고쳐야 한다.
“근본 원인이 어디 있는가”를 정확히 찾아야, 같은 실수가 반복되지 않는다.
에이전트 통합도 마찬가지다.
“역할이 다르니까 분할”이 아니라, “분할하면 맥락이 단절되는가”를 먼저 물어야 한다.
맥락이 단절되는 분할은 통합이 해결책이다.