소개
학회 검색·해석·렌더링이 하나의 스킬을 만들었지만, 여러 스킬들이 뒤섞여 있어 관리가 어렵다는 문제를 인식하고, 이를 명확히 분리된 파이프라인으로 재설계함
기존에는
conference-intelligence-briefing스킬 하나가 검색·해석·렌더링을 모두 담당하고 있었음스킬 간 역할 경계가 모호해 결과물 품질이 일정하지 않았고, 수정 시 어디를 고쳐야 할지 파악하기 어려웠음
실제 학회 2026 raw 결과 파일이 존재했지만, 이를 해석하는 레이어가 없어 데이터가 충분히 활용되지 못하고 있었음
내 약에 대한 경쟁 인텔 기준선이 없어, 무리하게 확정 분석을 내리기보다 provisional 단계를 먼저 구축하는 것을 목표로 설정했음
최종 목표는 수집 → 해석 → 렌더링이 명확히 분리된 재현 가능한 파이프라인을 만드는 것이었음
진행 방법
Claude: 경쟁 인텔 파이프라인 초안 설계 및 각 단계별 실현 가능성 확인에 활용함
Safari Developer Tools (Network → XHR/Fetch): 학회 검색 페이지가 JavaScript 렌더링 방식임을 확인하고, 숨겨진 GraphQL API 엔드포인트를 직접 캡처하는 데 활용함
Hermes: 캡처한 GraphQL API 기반 데이터 수집부터 해석·렌더링까지 전체 파이프라인을 실제로 구현하고 실행하는 데 활용함
1️⃣ 스킬 구조 분리 및 재설계함
기존
conference-intelligence-briefing스킬을 삭제하고, 수집(asco-graphql-search) / 해석(competitive-intel-analysis) / 렌더링(abstract-card-format) 세 가지로 역할을 명확히 분리함역할이 섞인 단일 스킬은 어느 단계에서 문제가 생겼는지 추적이 어렵기 때문에, 단계별 책임을 분리하는 방식을 선택함
#basic채널에서 스킬명 없이도 학회/초록/포스터 요청이 들어오면 세 스킬이 순서대로 실행되도록 AGENTS 규칙을 설정함
2️⃣ 경쟁 인텔 해석 레이어를 신규 구축함
competitive-intel-analysis스킬은 raw 학회 결과를 입력으로 받아 presentation format 분포, track 분포, high-priority abstract 선별, competitor positioning 초안 네 가지를 산출하도록 설계함범용 스킬로 설계한 이유는, 내 약 외 다른 파이프라인에도 동일한 해석 구조를 재사용할 수 있도록 하기 위함이었음
실제 raw 파일에 바로 적용하여 해석 레이어가 실제 데이터에서 작동하는지 검증함
3️⃣ Wiki에 raw → synthesis → output 구조로 결과를 저장함 (다음 스킬 정교화를 위한 기초 단계)
raw 검색 결과(
.hermes/outputs/)와 해석 결과(wiki/output/briefings/)를 물리적으로 분리하여 저장함. 원자료는 원자료대로 보존하고, 어디서 판단이 들어갔는지 나중에 추적할 수 있도록 하기 위한 선택이었음Provisional briefing을 저장하고, 본문 파일·브리핑 인덱스·상위 output 인덱스 세 곳에 모두 등록하여 누락 없이 추적되도록 했음
내 약 기준(direct/adjacent/excluded competitor)이 아직 확정되지 않은 상태였지만, raw 결과에서 이미 활용 가능한 정보가 존재했기 때문에 "최종판"이 아닌 "임시 해석본"으로 저장하는 방식을 선택함
이 구조의 핵심 목적은 "검색 결과를 한 번 보고 끝내는 것"이 아니라 "재사용 가능한 분석 메모로 승격"시키는 것임. 구체적인 장점은 아래와 같음:
재사용 가능성: 내 약 규칙이 확정되면 이 provisional note를 바탕으로 바로 확장할 수 있음
반복 작업 제거: 같은 분포 계산, 같은 상위 후보 선정을 매번 다시 하지 않아도 됨
위키화 가능성: provisional note는 나중에 comparison page → topic page → final briefing 순으로 승격할 수 있음
가독성: "왜 이 abstract가 상위였는지", "어떤 track이 밀집했는지"를 사람이 바로 읽을 수 있는 형태로 남김
결과와 배운 점
시행착오 ⚠️
"카드 느낌이 다르다"는 증상의 원인을 잘못 짚었음: 처음에는 렌더링 템플릿 문제라고 가정하고
abstract-card-format만 수정하려 했음. 그러나 템플릿과 실제 결과물을 직접 비교하면서, 문제의 핵심이 검색 결과의 폭이 아니라 해석 레이어 자체가 없었다는 것임을 확인하고, 진단 방향을 전환하여 해석 스킬 신규 구축으로 해결함기준선 없이 확정 분석을 강행하려는 흐름을 제어함: 내 약에 대한 source name, modality, direct competitor 기준이 없는 상태에서 완성된 competitor map을 만들려는 방향으로 흐를 위험이 있었음. 정보 부족 상태에서 확정 판단을 내리면 이후 수정 비용이 크다는 점을 인식하고, provisional 분석 단계에서 멈추는 방식으로 리스크를 통제했음
배운 점 📚
단일 스킬에 역할이 혼재하면 디버깅 시 어느 단계가 문제인지 파악할 수 없어, 수집/해석/렌더링을 분리하는 것이 유지보수 효율의 핵심임을 확인함
증상을 보고 원인을 가정하기 전 에 raw artifact와 출력물을 직접 비교하는 과정이 선행되어야 함을 경험함
기준선이 없을 때 확정 판단을 유보하고 provisional 단계를 명시적으로 두는 것이, 이후 수정 비용을 줄이는 실질적인 방법임을 깨달음
raw → synthesis → output 디렉토리 구조는 데이터 재해석 가능성을 높이며, 지식 자산의 수명을 연장하는 설계임을 확인함
파이프라인 설계는 기능 구현과 동시에 "무엇을 아직 모르는가"를 질문 노트로 남기는 것이 중요함을 깨달음
향후 계획 🧭
내 약의 최소 기준(source name, modality, direct/adjacent/excluded competitor, high-priority 기준) 4개를 확정할 계획임
해당 기준을 바탕으로
competitive-intel-analysis를 provisional에서 확정 룰로 전환할 예정임확정된 분석 결과를
abstract-card-format으로 넘겨 최종 HTML 시각화 버전을 생성할 예정임
