Scout
가능성이 있는 기술을 적극적으로 발굴합니다. 단순히 특이한 코드를 찾는 것이 아니라, 문제가 있고 그것을 해결하는 비자명한 메커니즘이 있고 기술적 효과가 있으며 재사용 가능한 아이디어로 보이는 형태를 찾습니다.
후보가 성립하려면 메커니즘을 구현한 실제 코드가 있어야 합니다. 문서나 Commit 메시지만 있는 경우에는 후보를 만들지 않습니다.
About
이 사이트의 분석 방법
이 도구의 최우선 원칙은 순서입니다. 파일을 모델에 넣어 아이디어를 얻는 방식이 아니라, 먼저 증거를 확보하고 그 증거에서 문제와 메커니즘과 효과를 읽어 낸 뒤에 후보를 만들고, 마지막으로 그 후보를 반박합니다.
Evidence
→ Problem / Mechanism / Effect
→ Candidate
→ Critic
→ Verified DiscoveryArchitecture
파이프라인 단계
- 01configconfig/sources.yaml 하나로 분석 대상과 예산을 관리합니다.
- 02Source ResolverOrganization 탐색 결과와 직접 지정 Repository를 합치고 중복을 제거합니다.
- 03GitHub CollectorRepository 메타데이터, Pull Request, Issue, Release를 수집합니다.
- 04Repository Scannershallow clone 후 tree-sitter로 심볼과 라인 범위를 추출합니다.
- 05Evidence Builder사실을 만들어 내는 유일한 단계입니다. 이후 단계는 새 사실을 추가할 수 없습니다.
- 06Technology ExtractorEvidence를 Component, Technology, Problem, Mechanism 계층으로 연결합니다.
- 07Idea Scout기술 영역과 메커니즘 계열 조합으로 Evidence를 묶어 후보를 만듭니다.
- 08Critic후보를 반박합니다. 치명적 지적이 하나라도 있으면 Rejected Ideas로 보냅니다.
- 09Candidate StoreSQLite에 저장하고, 직전 실행과 비교해 상태 변화를 결정합니다.
- 10JSON페이지별 JSON을 생성합니다. 사이트는 데이터베이스에 의존하지 않습니다.
- 11Astro정적 사이트를 빌드합니다.
- 12GitHub Pages빌드 결과를 배포합니다.
Scout와 Critic
후보 생성과 검증을 분리하는 이유
Critic
Scout의 후보를 적극적으로 반박합니다. 균형을 맞추려 하지 않고, 각 항목이 그 후보가 발명이나 연구 결과가 아니라 평범한 엔지니어링임을 보이려 시도합니다.
통과하지 못한 후보도 삭제하지 않습니다. 반박 사유와 재검토 조건을Rejected Ideas에 보존하여 같은 아이디어를 반복해서 발굴하지 않도록 합니다.
검토 항목
Critic 규칙
치명적 항목을 하나라도 위반하면 후보는 반박됩니다.
| 규칙 | 검토 내용 | 성격 |
|---|---|---|
| R1 | 사소한 변경이나 유지보수 작업이 아닌가 | 치명적 |
| R2 | 설정 변경만으로 이루어진 것이 아닌가 | 치명적 |
| R3 | 흔한 software design pattern이 아닌가 | 유보 |
| R4 | parameter tuning 수준이 아닌가 | 치명적 |
| R5 | 기존 Android, Linux, V4L2에서 일반적인 방법이 아닌가 | 유보 |
| R6 | Evidence가 충분한가 | 치명적 |
| R7 | 주장과 실제 코드가 일치하는가 | 치명적 |
| R8 | 효과가 주장에 그치지 않고 측정되었는가 | 유보 |
평가 값 읽는 방법
네 가지 점수
Patent 가능성
메커니즘의 구체성, 문제 서술의 존재, 효과의 정량화, 여러 Component와 Repository에 걸친 일반화 가능성을 더하고, 사소한 변경 표지를 뺍니다.
Paper 가능성
평가 어휘와 측정값의 존재, 알고리즘 계열 여부, test와 benchmark 경로의 증거, 설계 문서의 존재를 반영합니다.
증거 강도
증거의 종류 수, 총 건수, 심볼명과 라인 범위를 지목하는 정확도, 여러 Repository에 걸쳐 있는지를 반영합니다.
Novelty Confidence
이 값은 추가 조사의 우선순위를 뜻합니다. 특허 신규성 판단이 아니고, 특허 가능성에 대한 의견도 아닙니다. 선행기술 조사는 반드시 별도로 수행해야 합니다.
본 코퍼스 안에서 해당 조합이 얼마나 드문지, 메커니즘 계열이 설계된 기법을 시사하는지, 주변에 일반적인 설계 패턴이나 플랫폼 기본 코드가 지배적인지를 반영합니다.
모든 점수는 숫자만 보여주지 않고, 각 항목이 어떤 근거로 얼마만큼 가감되었는지 함께 표시합니다. 후보 상세 페이지에서 확인할 수 있습니다.
표기 규칙
근거가 부족할 때의 표시
근거가 부족한 항목을 그럴듯한 문장으로 채우지 않습니다. 대신 아래 표시를 붙여서 무엇이 확인되지 않았는지 드러냅니다.
| 표시 | 의미 |
|---|---|
| UNKNOWN | 해당 항목을 뒷받침하는 서술을 수집된 자료에서 전혀 찾지 못했습니다. |
| LOW_CONFIDENCE | 서술은 존재하지만 이를 뒷받침하는 측정값이 없습니다. |
| NEEDS_VERIFICATION | 확인이 필요합니다. 수집된 자료만으로는 판단할 수 없습니다. |
한계
이 도구가 하지 못하는 일
- 선행기술 조사를 대신하지 않습니다. 제공하는 것은 검색어이며, 조사 결과가 아닙니다.
- 특허 가능성이나 신규성에 대한 판단을 제공하지 않습니다. 법적 자문도 아닙니다.
- 어휘 사전에 없는 기술 영역은 찾지 못합니다. 사전은 pipeline/src/scout/lexicon/terms.py에서 확장합니다.
- 얕은 clone 범위를 벗어난 과거 이력은 읽지 못합니다. 이 경우 Timeline이 비어 있게 됩니다.
- Repository가 문제를 서술하지 않으면 문제 항목은 UNKNOWN으로 남습니다. 코드만으로 의도를 추정하지 않습니다.
실행 주기
주 1회 실행됩니다. 현재 구현 단계에서는 GitHub Actions에서 dry-run으로 파이프라인 전체를 검증할 수 있으며, dry-run은 데이터베이스와 data/를 건드리지 않습니다. 사내 운영에서는 동일한 스크립트를 cronjob으로 실행합니다.
이 사이트의 모든 후보는 공개 Repository에서 자동으로 수집한 증거에 근거합니다. Novelty Confidence는 추가 조사의 우선순위를 나타내는 값이며, 특허 신규성 판단이 아닙니다. UNKNOWN, LOW_CONFIDENCE, NEEDS_VERIFICATION 표시는 해당 항목을 뒷받침하는 증거가 부족하다는 뜻입니다.