Karpathy가 말한 포인트 중 가장 중요한 문장은 마지막입니다.
“이건 해키한 스크립트 모음이 아니라, 새로운 제품이 될 여지가 있다.”
많은 사람이 여기서 멈춥니다. “좋은 아이디어네” 하고 끝납니다.
이 글은 그 다음을 다룹니다. LLM Knowledge Base를 실제 제품으로 만들려면 무엇이 필요한지, 기능 단위로 정리합니다.
기존 내부 위키가 실패하는 이유는 구조보다 유지보수 비용입니다.
사람이 직접 유지하는 방식은 팀이 바빠질수록 무너집니다. 반면 LLM은 반복 유지보수 비용을 크게 줄여줍니다.
즉 시장 문제는 이미 있었고, 이제 해결 수단이 생긴 상태입니다.
소스가 들어오면 자동으로 요약/링크/분류/갱신이 되어야 합니다.
모든 결론에 근거 링크와 변경 이력이 붙어야 합니다.
문서가 끝이 아니라 액션 아이템/담당자/기한으로 이어져야 합니다.
이 3개가 없으면 그냥 노트 앱 확장판에 머뭅니다.
2주 MVP 기준으로 기능을 최소화하면 아래가 적절합니다.
여기까지면 “써볼 만한 제품”이 됩니다.
가장 현실적인 건 B2B 구독입니다.
핵심은 “AI 토큰” 자체보다 “지식 운영 기능”에 과금 포인트를 두는 겁니다. 그래야 가격 저항이 줄어듭니다.
문장 단위 출처 링크가 없으면 팀에서 신뢰를 못 얻습니다.
“누가/언제/왜 바꿨는지”가 안 보이면 운영팀이 불안해합니다.
민감 문서를 어떤 모델에 보낼 수 있는지 제어가 필요합니다.
자동 업데이트가 잘못됐을 때 롤백이 쉬워야 합니다.
이 네 가지는 데모에서는 안 보이지만, 실제 도입에서 승패를 가릅니다.
메시지를 이렇게 잡으면 약합니다.
이렇게 잡아야 강합니다.
고객이 사는 건 예쁜 에디터가 아니라, 문서 품질이 시간이 지나도 유지되는 확실성입니다.
예: SaaS 개발팀 온콜/장애 대응 지식
CS 대응 지식, 보안 운영 지식, 제품 의사결정 지식
연동 생태계 확장 + 리포트 자동화 + 정책 엔진
처음부터 범용 지식 플랫폼을 노리면 실패 확률이 높습니다. 좁은 문제를 확실히 해결하는 게 먼저입니다.
LLM Knowledge Base는 “지식을 잘 정리하는 방법”을 넘어서, “지식 유지보수 비용을 줄이는 제품 기회”입니다.
성공 조건은 명확합니다.
이 세 가지를 제품에 녹이면, 단순 AI 기능을 넘는 실사용 가치를 만들 수 있습니다.
지금 단계에서 가장 좋은 출발은 거창한 플랫폼이 아닙니다. 특정 팀의 반복 지식 작업 하나를 골라, 2주 MVP로 자동화해보는 것입니다. 그게 제품의 진짜 시작입니다.
