aslla77/company-scout

What does company-scout do?

회사명 하나를 입력받아 공개·검증 가능한 자료만으로 그 회사를 분석하고, 초심자도 읽고 이해할 수 있는 보고서를 만든다.

북극성 (가장 중요한 기준)

초심자가 이 보고서 하나로 그 회사를 이해할 수 있는가. 회사가 뭐 하는 곳인지 → 어떻게 돈 버는지 → 시장·경쟁은 어떤지 → 무슨 문제를 겪는지를, 전문지식 없이도 따라 읽을 수 있어야 한다. 출처 정합·포맷은 그 다음이다.

절대 규칙 (제0지침 — 어기면 보고서 폐기)

1. 공개·검증 가능한 자료만 근거로 쓴다. 기업 내부 비공개 정보, 확인 불가한 사적 경험, 출처 없는 숫자는 쓰지 않는다.
2. 모든 사실 주장에는 공개 URL 출처 + 출처 등급(A/B/C) + 확인일을 단다.
3. 출처를 댈 수 없으면 사실로 쓰지 말고 "근거 부족" 또는 **"가설"**로 강등한다.
4. 확정된 사실과 **이슈 예측(가설)**을 절대 섞지 않는다. 가설에는 "~일 가능성", "추정"을 명시한다.
5. 모르면 모른다고 쓴다. 추론은 "가정/가설"로 표시한다.
6. 비밀키·토큰·비밀번호를 검색창·로그에 입력하지 않는다.

출처 등급

• A = 공식·표준: 회사 공식 사이트·채용공고(JD)·기술블로그·보도자료·공식 SNS, DART 전자공시(감사보고서·사업보고서), 정부·표준 문서.
• B = 평판 있는 2차: 주요 경제·테크 매체 기사.
• C = 단서 전용: 커뮤니티·개인 블로그·유튜브·앱스토어 리뷰·위키. 사실 단정에 쓰지 말 것. 방향 잡는 단서로만.

입력

• 필수: 회사명 1개 (예: "마이리얼트립").
• 선택: 산업 힌트, 관심 축(예: 재무 중심).

절차

1) 회사 유형 판별 → 검색 전략 선택

회사 유형에 따라 출발점이 다르다:

• 커머스/플랫폼(무신사·마이리얼트립): 채용 JD, 기술블로그, 앱·플레이스토어 리뷰(C단서), 거래액·MAU 보도.
• 핀테크/금융(카카오페이증권): DART·금감원 공시, 규제·라이선스, 모회사 IR.
• 회계·컨설팅(삼일PwC): 산업 보고서·간행물, 채용 직무, 규제 동향.
• 비상장·정보 빈약(메디테라피·채널코퍼레이션): 채용 JD·보도자료·특허·대표 인터뷰·제품 페이지로 보완. 빈약하면 솔직히 "근거 부족".

2) 5축 수집 (회사 → 제품 → 고객 → 문제 → 관련회사)

각 축마다 공개 출처를 모으고 등급·확인일을 기록한다.

• 회사: 법인·연혁·규모·사업모델.
• 제품: 주요 제품/기능.
• 고객: 주 고객층·사용 맥락(B2C/B2B/공급측).
• 재무 신호(가능하면): **DART 감사보고서(A급)**로 매출·영업이익·순이익·주요 비용(판관비·지급수수료·운반비)·재고·현금흐름의 추세와 비율. 수치엔 반드시 출처·회계연도. 못 구하면 "근거 부족".
• 문제: 회사/산업/고객이 겪는 실제 문제. 출발점 — 채용 JD가 명시한 과제, 기술블로그의 엔지니어링 난제, 뉴스/IR의 사업 과제, 재무 신호가 가리키는 이상(예: 매출↑인데 영업이익↓), 앱 리뷰의 반복 불만(C단서).
• 관련 회사: 투자사·모/자회사·M&A·제휴·경쟁사·주요 고객/공급사. 관계 유형을 라벨로 달고 각각 출처.

3) 출처-주장 일치 점검 (경량)

핵심 사실(특히 숫자)은 (a) URL이 살아있고 (b) 본문이 그 주장을 실제로 뒷받침하는지 확인한다. 출처끼리 충돌하면 양쪽 병기 + "충돌, 재확인 필요". 죽은 링크·불일치는 강등.

4) 문제 후보 정리 + Codex 적합성 루브릭

문제 후보 최소 3건. 각 후보:

• 문제 한 줄 + [사실]/[가설] 라벨
• 공개 출처(등급)
• Codex 적합성 3축 점수(각 상/중/하):
  1. 입력 데이터 공개 가용성 (공개 API·더미로 대체 가능한가)
  2. 문제 경계 명확성 (플러그인 한 개로 다룰 만큼 좁은가)
  3. 플러그인 표현 가능성 (스킬/스크립트로 모델링 되는가)
• 본선 문제 제외: 유튜브 'AX 인재전쟁'에서 공개된 본선 예고 문제(예: 마이리얼트립 럭키글라이드형 가격탐색)는 그대로 쓰지 말고, 독립 공개 출처로 입증되는 인접 변형만 채택.

5) 보고서 조립 (아래 출력 스키마)

초심자 우선: 요약을 맨 앞에, 평이한 문장, 논리 흐름 유지.

6) 합격 자가 점검

보고서를 내기 전 아래를 모두 확인한다(하나라도 실패하면 보완):

• 맨 앞 요약(회사 한 줄 + 핵심 숫자 + 알 수 있는 것/없는 것)
• 사실 주장 100% 공개 출처(없으면 "근거 부족"/"가설"로 강등)
• 문제 후보 ≥3, 각 출처 + 적합성 3축 점수
• [사실]과 [가설] 분리 + "분석의 경계" 섹션 존재
• 각 섹션 끝 꼬리질문 3개
• 전문 용어 전부 용어 설명에 있음(또는 인라인)
• References(A/B/C·확인일), 근거 부족 모음
• 초심자가 읽다 막히는 곳 없음

출력 스키마 (보고서)

메인 축은 이 5축이다. 다른 사람의 보고서 양식·수치를 베끼지 않는다.

# <회사명> — 공개자료 기반 기업 이해 보고서
작성일 / 데이터 기준일 / 한 줄 정체

## 0. 요약
- 회사 한 줄 + 핵심 숫자 스냅샷(출처)
- 이 보고서로 알 수 있는 것 / 알 수 없는 것

## 1. 회사    ## 2. 제품    ## 3. 고객
(각 사실 [n] 출처)
### 꼬리질문 (3)

## 4. 재무 신호   ← DART 감사보고서 등 A급 있으면. 사실만.
### 꼬리질문 (3)

## 5. 시장·경쟁 / 관련 회사   ← 관계유형 라벨 + 경쟁사 수치
### 꼬리질문 (3)

## 6. 문제 신호 → 이슈 가설
- [확인된 사실] ... / [이슈 예측=가설] ...
- 문제 후보 1..N (문제 / 출처 / Codex 적합성 3축)
### 꼬리질문 (3)

## 7. 분석의 경계
- 공개자료로 말할 수 있는 것 / 없는 것

## (선택) 예선 5문항 초안
## References   (번호 → URL · 등급 A/B/C · 확인일)
## 용어 설명   (전문 용어 → 한 줄 정의 [+출처])
## 근거 부족 모음

저장

out/<회사명>-dossier-YYYYMMDD.md 로 저장(가능한 환경에서).

참고

• 좋은 출력 예시는 examples/myrealtrip-dossier.md (few-shot). 형식·깊이의 기준으로 삼되 내용은 대상 회사에 맞게 새로 조사한다.