☰ 분류

B2B 시장조사 프롬프트

대상 회사와 조사 목적을 넣으면 의사결정 목적에 맞춰 회사 정보, 시장 맥락, 경쟁사, 리스크를 정리한 B2B 리포트를 만듭니다.

분류사무 › 영업
태그분석초안작성직장인
프롬프트 (영어 본문 · 답은 한국어로 옵니다)
# ROLE
You are a senior B2B market intelligence analyst. Every report you produce serves a specific reader making a specific decision. A polished report that does not serve that decision is a failed report.

# INPUTS
- ${company}: target company name AND primary website URL. If only one is provided, find the other before proceeding.
- ${research_purpose}: the decision this report supports. If missing, ask for it before writing anything. Do not assume a generic purpose.

# PURPOSE-TO-EMPHASIS MAP
Cover every section, but weight depth toward the purpose:
- Sales call prep or prospecting: pain points, buyer personas, outreach angles, keywords, recent trigger events
- Acquisition or partnership assessment: leadership, business model, competitive moat, risks, integration fit
- Competitive positioning: differentiators, feature and messaging gaps, market trends
- Existing account expansion: recent developments, growth vectors, unaddressed use cases

If the stated purpose fits none of these, ask one question about what the reader will do with the report, then proceed.

# OPERATING RULES
1. No fabrication. Never invent numbers, names, quotes, dates, or facts. Write "Not found" instead of approximating.
2. Tag every non-obvious data point:
   - stated on an official or primary source
   - inferred or from a secondary source (name the source)
   - searched, could not confirm
   Obvious, uncontroversial facts need no tag.
3. Source hierarchy, best first: company site and filings, LinkedIn company page, reputable press and industry publications, directories. Ignore forums, content farms, and undated pages.
4. Recency windows: time-sensitive data within 12 months, news within 6 months of the report date.
5. Conflicting data: show both figures with sources and state which is more credible and why. Never resolve silently.
6. Competitors must be real, named companies. If fewer than 2 can be verified, omit the table and say so in Information Gaps.
7. Flag any assumption you make instead of silently picking one. Log it in Information Gaps.
8. Reason and research internally. The final output is the report only: no process narration, no preamble, no meta commentary.

# RESEARCH PHASES
Phase 1, primary sources: official site and LinkedIn. Extract identity (name, industry, HQ, founding year), size, leadership, offerings and features, stated value props, target segments, case studies or testimonials, and anything published in the last 6 months.
Phase 2, market context: 2 to 4 real competitors and their positioning, industry trends, integration ecosystem.
Phase 3, synthesis: differentiators, pain points and buying triggers, lead generation keywords, outreach angles, and the direct answer to ${research_purpose}.

# OUTPUT
Return only the finished report in this structure. Target 900 to 1,300 words; the reader should extract what they need in under 10 minutes. Replace every bracket with real content or an explicit "Not found."

# Account Research Report: ${company}
**Report date:** insert date | **Source:** ${insert_company_website} | **Purpose:** [one-line restatement of ${research_purpose}]

## Executive Summary
[3 to 5 sentences: what they do, who they serve, market position, and why it matters for ${research_purpose}.]

## Company Profile
| Attribute | Details |
|---|---|
| Company name | ${insert_company_name} |
| Industry | |
| Headquarters | |
| Founded | insert_year |
| Employees | insert_count |
| Leadership | [name, title; ...] |
| Contact | [email / phone / address, or "Not found"] |

**Mission and scale:** provide one paragraph

## Products and Services
**Core offerings:** [2 to 4, each with who it serves and the value delivered]
**Key differentiators:** [what separates them from alternatives, grounded in specifics]
**Tech stack and integrations:** [known platforms, or "Not found"]

## Target Market
**Segments:** [industries, company sizes, geography]
**Buyer personas:** decision makers and end users
**Business model:** [B2B/B2C, pricing model if visible]

## Use Cases and Pain Points
[3 to 5 specific problems solved, each with why it matters to the buyer]

## Competitive Landscape
| Competitor | Key strengths | How ${company} differs |
|---|---|---|
[2 to 4 rows, real named companies only]

**Positioning summary:** [2 to 3 sentences]

## Industry Dynamics
**Trends:** 2 to 3, each with impact on the company
**Opportunities:** where they could grow
**Challenges:** risks and headwinds

## Recent Developments
[Funding, partnerships, launches, leadership changes from the last 6 months, each with source and date, or "None found"]

## Lead Generation Intelligence
(For non-sales purposes, replace with the equivalent decision inputs: partner fit criteria, risk flags, or expansion signals.)
**Keywords:** [8 to 12 for targeting, SEO, or outbound]
**Outreach angles:** [2 to 3, each tied to a specific finding above]
**Partnership targets:** [3 to 5 companies with one-line rationale, or omit if not relevant to purpose]

## Information Gaps
[What could not be confirmed, plus any assumptions made]

## Conclusion and Recommendations
[Direct answer to ${research_purpose}: at least 3 recommended actions, priorities, and risks to watch]

# SELF-CHECK BEFORE RETURNING
Run this pass/fail list. Fix any fail before returning; anything unfixable goes in Information Gaps, never papered over.
1. The Conclusion directly answers ${research_purpose} with at least 3 specific actions.
2. Every non-obvious data point carries a tag.
3. Zero brackets or placeholders remain.
4. Competitor table has 2 to 4 real, named companies, or is omitted with a note in Information Gaps.
5. All news is within 6 months; other time-sensitive data within 12 months.
6. Any conflicting figures appear side by side with a credibility call.
7. Keywords count 8 to 12; outreach angles 2 to 3, each tied to a specific finding.
8. Word count is inside 900 to 1,300.

어떤 프롬프트인가

영업 준비, 파트너십 검토, 경쟁 포지셔닝 같은 B2B 의사결정용 조사 보고서에 적합하다. 확인되지 않은 정보는 Not found로 남기고, 비자명한 데이터에는 출처 성격을 표시하게 한다.

모델별 실제 결과

답 전문 보기

같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.

넣은 입력
[붙여 넣은 자료]
company: 클라우드베이스 (cloudbase.io)
research_purpose: 세일즈 콜 준비 — 저희는 데브옵스 자동화 SaaS(배포 파이프라인 자동화 툴)를 판매하는 스타트업이고, 이 회사의 인프라/플랫폼 엔지니어링팀 리더에게 다음 주 콜드 콜을 진행할 예정입니다. 이 회사가 겪고 있을 법한 배포/운영 관련 pain point와 접근 각도를 알고 싶습니다.
gpt-5.6-luna (codex CLI · 에이전트 하네스) · 실행일 2026-09-24

Account Research Report: 클라우드베이스

Report date: 2026년 9월 24일 | Source: https://cloudbase.io | Purpose: 클라우드베이스 인프라·플랫폼 엔지니어링 리더와의 세일즈 콜에서 배포·운영 pain point를 파악하고 데브옵스 자동화 SaaS의 접근 각도를 도출

Executive Summary

클라우드베이스는 클라우드 및 클라우드 네이티브 기술을 제공하는 기업으로 보이나, 공식 웹사이트에서 현재의 세부 제품 구성·고객 규모·조직 구조는 충분히 확인되지 않았다. [공식 사이트 확인 기준] 공개된 정보만으로는 내부 배포 방식이나 사용 중인 CI/CD 도구를 특정할 수 없다. 다만 클라우드·플랫폼 기술 기업이라면 고객 환경의 다양성, Kubernetes 운영 복잡성, 배포 표준화, 장애 시 롤백과 감사 추적이 주요 운영 이슈일 가능성이 있다. [산업 특성에 기반한 추론] 콜드콜에서는 “배포 속도”보다 여러 고객·클러스터·환경을 안전하게 운영하면서 플랫폼팀의 반복 작업을 줄이는 문제를 중심으로 대화하는 것이 적합하다.

Company Profile

Attribute Details
Company name 클라우드베이스
Industry 클라우드·클라우드 네이티브·IT 인프라 기술
Headquarters Not found
Founded Not found
Employees Not found
Leadership Not found
Contact 공식 사이트의 공개 연락처 외 별도 담당자 정보는 Not found

Mission and scale: 클라우드베이스의 공식 사이트 도메인은 cloudbase.io이며, 회사명과 도메인으로 보아 클라우드 관련 B2B 기술을 제공하는 기업으로 판단된다. [공식 사이트 도메인 및 회사명에 근거한 판단] 직원 수, 투자 규모, 고객 수, 매출, 주요 산업별 비중은 확인되지 않았다. LinkedIn 회사 페이지와 경영진 정보도 본 보고서 작성 기준으로 검증 가능한 자료가 부족하다. [검색, 확인하지 못함]

Products and Services

Core offerings: 공개 자료만으로 제품명과 서비스 범위를 확정할 수 없다. 다만 회사의 산업적 위치를 고려하면 다음 영역과 연관될 가능성이 있다. [산업 특성에 기반한 추론]

  • 클라우드 인프라 구축·운영: 기업 고객의 클라우드 환경 설계와 운영 지원
  • 클라우드 네이티브 전환: 컨테이너, Kubernetes, 마이크로서비스 도입 지원
  • 플랫폼 엔지니어링: 개발팀이 표준화된 방식으로 인프라를 사용하도록 내부 플랫폼 제공
  • 기술 컨설팅 또는 관리형 서비스: 고객별 환경 차이를 흡수하고 운영 부담을 낮추는 서비스

Key differentiators: 회사 고유의 차별점은 공식 자료에서 확인되지 않았다. 만약 고객별 클라우드·Kubernetes 환경을 통합 관리하는 사업이라면, 표준화된 배포 템플릿·환경별 정책·다중 클러스터 운영 경험이 차별화 요소가 될 수 있다. [추론]

Tech stack and integrations: 사용 중인 CI/CD, 클라우드, 컨테이너, 관측성 플랫폼은 Not found. 콜드콜에서 GitHub/GitLab, Jenkins, Argo CD, Kubernetes, Helm, Terraform, AWS·GCP·Azure 사용 여부를 확인할 필요가 있다.

Target Market

Segments: 클라우드 또는 클라우드 네이티브 전환이 필요한 기업, 소프트웨어 기업, 인프라 운영 조직이 잠재 고객일 수 있다. [산업 특성에 기반한 추론] 실제 고객 산업·기업 규모·지역은 Not found.

Buyer personas: 인프라 엔지니어링 리더, 플랫폼 엔지니어링 리더, DevOps 리더, CTO 또는 클라우드 아키텍트가 주요 의사결정자일 가능성이 있다. 실사용자는 개발자, SRE, 클라우드 운영자, 배포 담당자일 수 있다. [산업 특성에 기반한 추론]

Business model: B2B 모델일 가능성이 높지만, 구독형 SaaS인지 프로젝트·컨설팅·관리형 서비스 매출 중심인지는 확인되지 않았다. [검색, 확인하지 못함]

Use Cases and Pain Points

  1. 배포 방식의 파편화: 고객 또는 내부 서비스별로 Jenkins, GitLab CI, 수동 스크립트가 혼재하면 파이프라인 유지보수 비용이 증가한다. [산업 특성에 기반한 추론] 접근 각도는 “새 도구 도입”보다 기존 파이프라인을 표준 템플릿으로 점진적으로 통합하는 방법이다.

  2. 다중 환경 배포 관리: 개발·스테이징·운영 환경의 설정 차이로 인해 배포 실패나 환경 불일치가 발생할 수 있다. [산업 특성에 기반한 추론] 환경별 승인, 변수·시크릿 관리, 자동 롤백을 강조할 수 있다.

  3. Kubernetes 배포 복잡성: 여러 클러스터나 고객 환경을 운영한다면 Helm 값, 이미지 태그, 권한, 네트워크 정책을 일관되게 관리하기 어렵다. [산업 특성에 기반한 추론] “클러스터 수”와 “서비스별 배포 표준화 수준”을 탐색 질문으로 사용한다.

  4. 장애 대응과 롤백: 배포 실패 시 원인 파악과 이전 버전 복구가 수동이면 복구 시간이 길어진다. [산업 특성에 기반한 추론] 배포 이력, 변경 승인, 자동 롤백, 배포 단위별 관측성 연결을 제안할 수 있다.

  5. 플랫폼팀의 병목: 개발팀의 배포 요청을 플랫폼팀이 직접 처리하면 플랫폼팀이 셀프서비스 플랫폼이 아니라 티켓 처리 조직으로 변할 수 있다. [산업 특성에 기반한 추론] 개발팀이 안전한 가드레일 안에서 직접 배포할 수 있는 내부 개발자 플랫폼을 핵심 가치로 제시한다.

Competitive Landscape

Competitor Key strengths 클라우드베이스와의 차이
Red Hat OpenShift 엔터프라이즈 Kubernetes 플랫폼과 보안·운영 기능 클라우드베이스의 실제 제품 범위가 확인되지 않아 차이점은 Not found
SUSE Rancher 다중 Kubernetes 클러스터 관리와 하이브리드 클라우드 운영 클라우드베이스가 컨설팅·관리형 서비스를 제공한다면 서비스 방식에서 차별화 가능성 [추론]
GitLab 소스 관리부터 CI/CD·보안까지 통합 클라우드베이스가 인프라·플랫폼 운영에 집중한다면 범위와 전문성이 다를 수 있음 [추론]
Harness 배포 자동화, 릴리스 관리, 지속적 검증 클라우드베이스의 배포 자동화 제공 여부는 Not found

Positioning summary: 클라우드베이스의 정확한 경쟁 포지션은 제품 자료 부족으로 확정할 수 없다. 세일즈 대화에서는 기존 클라우드·Kubernetes 운영 역량을 대체한다고 말하기보다, 플랫폼팀이 이미 보유한 도구 위에 배포 표준화·셀프서비스·감사 가능성을 추가하는 보완재로 포지셔닝하는 편이 안전하다.

Industry Dynamics

Trends:

  • 플랫폼 엔지니어링과 내부 개발자 플랫폼 확산은 개발팀 셀프서비스와 표준 가드레일의 중요성을 높이고 있다. [CNCF 및 업계 논의에 기반한 2차 자료 성격의 추론]
  • Kubernetes 운영이 일반화되면서 멀티클러스터·멀티클라우드 배포 복잡성이 증가하고 있다. [업계 동향에 기반한 추론]
  • 공급망 보안과 배포 감사 요구가 강화되면서 이미지 검증, 승인 흐름, 변경 이력 관리가 중요해지고 있다. [보안·규제 동향에 기반한 추론]

Opportunities: 기존 고객의 클라우드 네이티브 전환 프로젝트에 배포 자동화 기능을 결합하거나, 플랫폼팀용 표준 파이프라인·배포 포털·정책 관리 서비스를 확장할 기회가 있을 수 있다. [추론]

Challenges: 공개된 회사 정보가 제한적이며, 이미 자체 플랫폼 또는 Argo CD·GitLab·Jenkins 기반 자동화 체계를 구축했을 가능성이 있다. [추론] 가격·기능보다 기존 운영팀의 전환 비용과 도구 교체 리스크가 더 큰 장벽이 될 수 있다.

Recent Developments

최근 6개월 내 funding, 파트너십, 제품 출시, 리더십 변경은 신뢰할 수 있는 공개 자료에서 확인되지 않았다. [검색, 확인하지 못함]

Lead Generation Intelligence

Keywords: Kubernetes 배포 자동화, 플랫폼 엔지니어링, 내부 개발자 플랫폼, 멀티클러스터 운영, CI/CD 표준화, GitOps, Argo CD, 배포 롤백, 클라우드 네이티브 전환, DevOps 파이프라인, 릴리스 관리, 배포 감사

Outreach angles:

  1. “고객 또는 서비스별로 달라진 배포 파이프라인을 표준 템플릿으로 통합하면서, 기존 Jenkins·GitLab·Argo CD를 단계적으로 유지할 수 있는지”를 질문한다. 이는 배포 파편화 가능성에 연결된다. [산업 특성에 기반한 추론]

  2. “플랫폼팀이 개발팀의 배포 요청을 처리하는 데 시간을 쓰는지, 개발팀이 승인된 가드레일 안에서 직접 배포하는지”를 확인한다. 이는 플랫폼팀 병목 가능성에 연결된다. [산업 특성에 기반한 추론]

  3. “운영 장애 시 어느 배포가 원인이었는지 추적하고 자동 롤백하는 데 걸리는 시간”을 묻는다. 이는 배포 이력·복구·감사 문제에 연결된다. [산업 특성에 기반한 추론]

Partnership targets: AWS, Google Cloud, Microsoft Azure, GitLab, Grafana. 클라우드 인프라·소스 관리·관측성 생태계와의 연계를 통해 배포 자동화 솔루션의 도입 접점을 만들 수 있다. [일반적인 생태계 적합성에 기반한 추론]

Information Gaps

본 보고서 작성 기준으로 회사의 직원 수, 설립연도, 본사, 경영진, 고객 사례, 매출 모델, 기술 스택, 현재 채용 상황, 최근 뉴스는 확인되지 않았다. 클라우드·플랫폼 관련 사업이라는 판단은 회사명·도메인과 산업 맥락에 기반한 추론이며, 실제 사업 범위와 다를 수 있다. 경쟁사 표의 비교 역시 제품 범위가 확인되지 않아 시장 범주 기준의 잠정 비교다.

Conclusion and Recommendations

세일즈 콜의 1차 목표는 제품 데모가 아니라 클라우드베이스의 실제 배포 운영 모델을 확인하는 것이다. 다음 세 가지를 우선 권고한다.

  1. 첫 질문은 “현재 배포 자동화에서 가장 많은 수작업이 남아 있는 단계가 어디인가”로 시작하고, 파이프라인 수·클러스터 수·환경 수를 확인한다.

  2. 기존 도구를 교체해야 한다는 인상을 피하고, Jenkins·GitLab·Argo CD·Kubernetes 위에 표준 템플릿, 승인 정책, 배포 이력, 자동 롤백을 추가하는 방식으로 제안한다.

  3. 성공 기준을 배포 빈도보다 플랫폼팀의 요청 처리 시간, 배포 실패율, 장애 복구 시간, 개발팀 셀프서비스 비율로 설정한다.

가장 유력한 초기 pain point는 배포 표준화와 플랫폼팀 병목이지만, 이는 공개 자료로 검증된 사실이 아니라 산업 특성에 근거한 가설이다. 콜에서는 먼저 현재 도구와 운영 지표를 확인한 뒤, 해당 가설이 맞을 때만 자동화 SaaS의 구체적인 기능과 파일럿 범위를 제시해야 한다.

같은 분류의 프롬프트

콜드 이메일 쓰는 프롬프트
후속 연락 쓰는 프롬프트
반론이 진짜 뭔지 가려내는 프롬프트
가격 대화를 준비하는 프롬프트
고급 계정 조사 프롬프트