7,568줄을 710줄로
이날은 “올바른 질문”이 90% 절감을 만든 날이다.
위키 로거가 30개 스킬을 전부 인라인하고 있었다.
어떻게 줄일지 고민하다가, “실제로 몇 개가 필요한가”를 물으니 2개뿐이었다.
그리고 배포 정밀도랑 매도 원칙도 정립했다.
위키 로거 확장이 세션 종료 시 위키 사서 에이전트를 띄운다.
이때 사서가 참고할 스킬을 프롬프트에 인라인으로 넣는다.
근데 30개 스킬 전부를 디렉토리 스캔으로 읽어서 넣고 있었다.
7,568줄. 사서가 실제로 필요한 스킬은 2개뿐인데.
티어링 접근의 함정
처음에는 “어떻게 줄일까”를 물었다.
30개를 핵심 7개, 지원 13개, 선택 7개, 중복 3개로 나눴다.
약 22% 절감이 나왔다.
근데 더 나은 질문이 있었다.
“사서가 실제로 참조하는 스킬이 몇 개인가?” 답은 2개였다.
수집이랑 빠른 캡처. 나머지 28개는 사서가 안 쓴다.
“어떻게 줄일까”가 아니라 “실제로 몇 개가 필요한가”를 물으니, 22%가 아니라 90% 절감이 나왔다.
올바른 질문이 최적화보다 낫다
티어링은 “전체를 어떻게 줄일까”라는 질문이다.
근데 더 근본적인 질문은 “이 경로에서 실제로 몇 개가 필요한가”다.
경로별 허용 목록이 일반적인 최소화보다 낫다.
이건 일반적인 원칙이다.
“전체를 최적화하는 방법”을 찾기 전에, “이 특정 경로에서 실제로 필요한 것이 무엇인가”를 먼저 물어야 한다.
전체 최적화는 보통 부분 최적화보다 덜 효과적이다.
배포 정밀도
교육 플랫폼에서 증분 배포를 했다.
근데 배포 추론이 너무 많은 앱을 잡았다.
누적 diff 기준이라, 이전 배포의 변경까지 포함된 거다.
해결은 심볼 역추적이었다.
변경된 심볼이 실제로 어느 앱에서 import되는지 추적한다.
패키지 의존성 기준이 아니라, 실제 코드에서 import하는지를 확인한다.
4개 앱에서 2개 앱으로 줄었다.
핵심은 “코드가 변경됐는가”가 아니라 “런타임 동작이 변경됐는가”다.
죽은 코드를 지운 건 번들에 영향을 안 준다.
실제로 동작하는 코드를 바꾼 것만 배포하면 된다.
매도 원칙 정립
KOSPI가 또 7.61% 하락했다.
리스크 관리 에이전트가 “현금 0%니까 팔아라”고 경고했다.
근데 나는 샀다.
삼성전자 83주, SK하이닉스 13주를 샀다.
그리고 매도 원칙을 정립했다.
매도는 두 가지 조건에서만 한다.
첫째, 주식의 고유 가치가 훼손됐을 때. 경쟁 우위가 사라졌거나 펀더멘털이 악화됐을 때.
둘째, 확실한 하락이 예상될 때. 기술적 붕괴나 명확한 매크로 충격.
“현금이 부족하니까 팔아라”는 매도 사유가 아니다.
가치가 훼손되지 않은 주식은 현금이 0%여도 들고 있거나 산다.
가치 손상 없는 폭락은 매수 기회다.
위키 스킬 게이트웨이 패턴
위키 스킬 30개 전부에 모델 호출 비활성화 플래그: true를 걸었다.
메인 에이전트가 위키 스킬을 직접 못 부르게 하는 거다.
오직 위키 사서 에이전트만 스킬에 접근할 수 있다.
이게 없으면, 메인 에이전트가 위키 스킬을 자동으로 발동한다.
각 스킬이 각자의 기준으로 분류하고 링크하고 태그를 붙인다.
30개 스킬이 30가지 방식으로 위키를 해석하는 거다.
위키 일관성이 붕괴한다.
게이트웨이 패턴은 하나의 권위를 만든다.
오직 사서만 위키를 쓴다.
사서는 일관된 기준으로 작동한다.
30개 스킬이 같은 룰을 따르게 하는 게 아니라, 하나의 에이전트가 모든 위키 작업을 하는 거다.
마무리
이날의 핵심은 “올바른 질문”이었다.
위키 로거에서 “어떻게 줄일까”가 아니라 “몇 개가 필요한가”를 물었다.
90% 절감이 나왔다.
배포에서 “코드가 바뀌었는가”가 아니라 “런타임 동작이 바뀌었는가”를 물었다.
정확한 배포 범위가 나왔다.
올바른 질문은 최적화보다 낫다.
전체를 최적화하는 방법을 찾기 전에, 특정 경로에서 실제로 필요한 것을 물어야 한다.
답이 예상보다 작으면, 최적화할 게 별로 없다.
답이 예상보다 크면, 최적화의 한계가 명확해진다.