배경 (Why)
현재 Hedwig는 "내가 보고 싶은 정보를 선별"하는 personal information curation에 특화되어 있음.
하지만 이미 Hedwig가 가지고 있는 자산 — algorithm.yaml(추천 정책 DSL), nl-editor(자연어로 알고리즘 조작), meta-evolution 루프 — 는 본질적으로 도메인 무관한 control plane.
이 control plane을 분리해서 모듈화하면, 같은 엔진으로 다음이 가능해짐:
- 정보 큐레이션 (현재 Hedwig)
- 음악 추천
- 읽을거리 / 콘텐츠 추천
- (장기) 사람간 추천
차별화 (What's the moat)
SOTA 베이스라인은 분리해서 보면 다 존재:
- 프레임워크: RecBole, Microsoft Recommenders
- Generative rec: Meta HSTU, Google TIGER, Pinterest PinnerSAGE
- LLM-based: P5, RecSys-LLM, instruction-tuned rec
- 대화형 rec: CRSLab
하지만 "자연어로 알고리즘을 조종 + 셀프 진화 + 도메인 플러그인" 세 축을 동시에 묶은 건 메인스트림에 없음.
경쟁축은 "더 나은 ranker"가 아니라 "비전문가가 텍스트로 추천 정책을 빚을 수 있는 OS".
제안 아키텍처
┌─────────────────────────────────────────────┐
│ recommender-core (분리 대상) │
│ ┌─────────────────────────────────────┐ │
│ │ algorithm.yaml DSL (정책 표현) │ │
│ │ nl-editor (자연어 → DSL) │ │
│ │ meta-evolve (정책 자체의 진화) │ │
│ │ domain adapter interface │ │
│ └─────────────────────────────────────┘ │
│ ↑ plug-in ↑ │
│ ┌──────────┐ ┌─────────┐ ┌────────────┐ │
│ │ hedwig │ │ music │ │ articles │ │
│ │ (info) │ │ adapter │ │ adapter │ │
│ └──────────┘ └─────────┘ └────────────┘ │
└─────────────────────────────────────────────┘
핵심 원칙: embedding/ranker 같은 무거운 모델은 도메인 SOTA를 plug-in으로 받아쓰고, 우리는 control + evolve 레이어만 소유.
리스크 / 트레이드오프
- 일반화하면 도메인 특화 모델 대비 quality gap 생김 → adapter 패턴으로 mitigate
- "사람간 추천"은 양면시장 + 윤리 이슈가 무거움 → 첫 generalization 타겟에서 제외, 음악/읽을거리부터
- generic하게 만들수록 Hedwig 본체와의 결합도가 약해질 수 있음 → reference impl로 Hedwig를 유지하며 추출
다음 한 걸음 (Spike)
성공 기준
- Hedwig 본체가
recommender-core 위에서 동일하게 동작 (regression 없음)
- 두 번째 도메인 어댑터가 algorithm.yaml 한 파일 + 어댑터 구현만으로 붙음
- 자연어 명령("주말엔 새로운 장르 더 보여줘")이 도메인 무관하게 동작
배경 (Why)
현재 Hedwig는 "내가 보고 싶은 정보를 선별"하는 personal information curation에 특화되어 있음.
하지만 이미 Hedwig가 가지고 있는 자산 —
algorithm.yaml(추천 정책 DSL),nl-editor(자연어로 알고리즘 조작), meta-evolution 루프 — 는 본질적으로 도메인 무관한 control plane.이 control plane을 분리해서 모듈화하면, 같은 엔진으로 다음이 가능해짐:
차별화 (What's the moat)
SOTA 베이스라인은 분리해서 보면 다 존재:
하지만 "자연어로 알고리즘을 조종 + 셀프 진화 + 도메인 플러그인" 세 축을 동시에 묶은 건 메인스트림에 없음.
경쟁축은 "더 나은 ranker"가 아니라 "비전문가가 텍스트로 추천 정책을 빚을 수 있는 OS".
제안 아키텍처
핵심 원칙: embedding/ranker 같은 무거운 모델은 도메인 SOTA를 plug-in으로 받아쓰고, 우리는 control + evolve 레이어만 소유.
리스크 / 트레이드오프
다음 한 걸음 (Spike)
ooo interview로 5~7개 질문 돌려서 generalization 범위 / 차별화 축 / 첫 도메인 확정algorithm.yaml+nl-editor+meta-evolve)이 어디까지 도메인 비종속인지 audit성공 기준
recommender-core위에서 동일하게 동작 (regression 없음)