MCP를 프로젝트마다 다르게
이날은 두 가지 큰 작업을 한 날이다.
하나는 MCP 서버를 프로젝트마다 다르게 로드하는 거였다.
다른 하나는 괴담 소설 생성 파이프라인을 개편하는 거였다.
전혀 다른 작업 같지만 둘 다
“스코핑”에 대한 것이었다.
기본적으로 MCP 서버는 전역에 등록된다.
피그마, 노션, 지라, 서비스 전부. 근데 피그마는 회사 프로젝트에서만 필요하다.
노션도 마찬가지다.
개인 프로젝트에서 피그마 서버가 뜨면 메모리 낭비고 컨텍스트 오염이다.
세 번의 설계 변화를 거쳤다.
첫째, 도구 호출을 차단하는 확장을 만들었다.
프로젝트 경로가 안 맞으면 MCP 호출을 막는 거다.
근데 서버 이름이 시스템 프롬프트에 여전히 보인다.
“호출은 안 되는데 존재는 보인다”는 거다.
둘째, 프로젝트 설정 파일을 수동으로 관리했다.
각 프로젝트에 MCP 설정 파일을 둔다.
근데 관리 포인트가 흩어진다.
셋째, 세션 시작 시 주입하는 방식으로 최종 결정했다.
중앙 설정에서 선언하고 세션이 시작할 때 프로젝트 설정 파일로 합친다.
중앙 관리랑 로드 시점 스코핑을 둘 다
잡은 거다.
핵심 발견: 게으른 서버는 한 번 연결되면 영구 캐싱
가장 중요한 발견은 게으른 서버의 캐싱 동작이었다.
게으른 서버는 처음 호출될 때 연결된다.
근데 한 번 연결되면 캐시에 영구 남는다.
이후 세션에서 프로젝트 경로가 달라도 계속 보인다.
호출을 막아도 존재를 숨길 수는 없다.
이건 pi 코어의 한계다.
근본 해결을 하려면 코어에서 로드 시점 훅을 제공해야 한다.
현재는 없다.
괴담 소설 파이프라인 개편
소설 생성 파이프라인을 4개 에이전트로 개편했다.
첫째, 선별 에이전트가 수확된 괴담 중 소설화할 만한 것을 고른다.
만 글자 이상 소설로 쓸 수 있는지 판단한다.
둘째, 계획 에이전트가 이야기 방향을 잡는다.
줄거리 씨앗을 조작하고 길이랑 제약을 정한다.
셋째, 작성 에이전트가 본문을 쓴다.
코딩 에이전트처럼 “이어서 쓰기”를 반복한다.
목표 길이에 도달하거나 정지 조건이 발동하면 끝난다.
넷째, 검토 에이전트가 일관성을 검증한다.
엔티티를 추출하고 과거 원문에서 충돌이랑 누락을 찾는다.
승인하면 다음으로, 거부하면 충돌 지점부터 다시 쓴다.
작성자랑 검토자가 메모리를 공유한다
작성자랑 검토자가 같은 메모리 세션을 공유한다.
검토자의 피드백이 다음 작성자 호출에 자동 포함된다.
이전에는 모든 텍스트랑 피드백을 문자열로 누적 주입했다.
메모리 공유가 훨씬 효율적이다.
워크플로 독립 로딩
세 개 워크플로(수확, 소설, 각색)를 독립적으로 로드하게 만들었다.
하나의 로드 실패가 전체를 막지 않게. 크롤링 도구의 네이티브 빌드가 환경마다 실패할 수 있으니까, 하나가 실패해도 다른 건 돌아가야 한다.
숨겨진 단일 섹터 집중
틈틈이 포트폴리오 위험도 분석했다.
“분산했다”고 믿었던 ETF가 전부 같은 지수를 추종하고 있었다.
겉으로는 다른 이름인데, 기저 자산은 같다.
전체 노출을 계산해보니 89.3%가 반도체였다.
직접 56%에 ETF 경유 24%. ISA 계좌랑 MAIN 계정에서 같은 지수를 다른 이름으로 가지고 있었다.
눈에 보이는 다양성이 실제 다양성이 아니었다.
이건 “위장된 분산”이다.
하나의 요소가 40%를 넘으면 과집중 경고를 내야 한다.
근데 이름이 달라서 눈에 안 보인다.
기저 자산을 봐야 진짜 노출이 보인다.
마무리
이날의 핵심은 “스코핑”이었다.
MCP는 프로젝트마다 필요한 서버만 로드한다.
전역에 올려놓고 다
쓰는 게 아니라, 프로젝트에 맞게 스코핑한다.
소설 파이프라인도 역할을 스코핑했다.
선별, 계획, 작성, 검토가 각자 자기 역할만 한다.
전부 하나가 하는 게 아니라, 역할마다 전문화한다.
포트폴리오도 스코핑이 필요했다.
“분산했다”는 겉모습 뒤에 숨겨진 집중을 찾아야 한다.
이름이 아니라 기저 자산을 봐야 진짜 노출이 보인다.
스코핑은 “뭘 볼지”를 결정하는 거다.
전부 보는 게 아니라, 필요한 것만 본다.
전부 쓰는 게 아니라, 역할에 맞는 것만 쓴다.
스코핑이 정확해야 낭비가 없고 위험이 안 보이지 않는다.