지난 글에서는 기업이 축적한 Market Intelligence, 고객 패턴, 경쟁사 변화, 자사 역량을 매번 Context Window에 다시 밀어 넣는 대신, 지속적으로 LINT되는 Enterprise Wiki와 Canonical Market Lens Skill로 관리하는 방법을 다뤘다.
그 Lens가 준비되면 다음 질문이 생긴다.
RFP에 적힌 단어를 검색할 것인가, 아니면 그 RFP가 우리의 기존 전략에서 무엇을 의심하게 만드는지 검색할 것인가?
나는 후자가 Enterprise Web Search에 더 가까운 질문이라고 생각한다.
새로운 RFP에는 수많은 기술과 운영 요구가 등장한다. AI, Cloud, Network, Security, Robot, WCS, PLC, Monitoring 같은 단어가 한 문서에 함께 등장하는 것은 이상하지 않다. 하지만 그 단어를 그대로 검색어로 확장하면 Agent는 금방 시장조사 보고서를 하나 더 만드는 쪽으로 흐른다.
문제는 대부분의 Deal에서 우리가 필요한 것이 ‘이 시장에 무엇이 있는가’에 대한 설명이 아니라는 점이다.
이미 시장을 어느 정도 알고 있다면 더 중요한 질문은 무엇이 기존 판단을 바꿀 만큼 달라졌는가다.
RFP를 검색어 목록으로 바꾸지 않는다
가상의 사례를 하나 두고 끝까지 따라가 보자.
한 대형 유통기업이 신규 Fulfillment Center 자동화 RFP를 발행했다고 하자. 문서에는 높은 처리량, 낮은 reject와 mis-sort, WCS·PLC integration, commissioning, UAT, monitoring, downtime visibility, 짧은 납기, 가격 경쟁, OEM dependency가 등장한다. AI, Cloud, Robotics 같은 용어도 일부 포함돼 있다.
여기서 모든 requirement가 같은 의미를 갖는 것은 아니다.
Requirement ≠ Mention ≠ Integration Dependency ≠ Scope Ownership ≠ Strategic Signal ≠ Research Question
Security가 mandatory requirement라고 해서 Security 시장이 이번 MI Research의 독립 scope라는 뜻은 아니다. Cloud가 future-readiness 문맥에서 언급됐다고 해서 Cloud competitor landscape를 새로 열어야 하는 것도 아니다.
반대로 commissioning, UAT, stabilization, downtime visibility처럼 고객의 평가 기준과 운영 리스크에 직접 연결되는 항목은 단순 requirement를 넘어 Strategic Signal이 될 수 있다.
따라서 Web Search 이전에 필요한 첫 번째 변환은 다음과 같다.
Raw RFP → Document Authority / Role → MI Relevance Gate → Strategic Signal → Deal MI Context
이 단계에서 중요한 것은 RFP를 완벽하게 요약하는 것이 아니다. Web Research가 필요한 signal만 남기는 것이다.
Signal은 Lens와 만나야 질문이 된다
Strategic Signal만으로도 아직 검색을 시작하기에는 이르다.
예를 들어 RFP가 짧은 commissioning 일정과 강한 UAT 성능 검증을 요구한다고 해보자.
이 정보만 보면 ‘commissioning trend’를 검색할 수도 있다. 하지만 Part 1에서 만든 Market Lens가 다음을 이미 알고 있다고 가정해보자.
- 고객의 주요 Buying Criteria에는 운영 안정성과 ramp-up risk가 포함돼 있다.
- 경쟁은 장비 peak performance만이 아니라 integration과 operational certainty에서도 벌어진다.
- 우리 회사가 반복적으로 증명한 강점 중 하나가 integration과 commissioning이다.
- 반대로 경쟁사의 최근 software control과 lifecycle capability 확장은 기존 차별화를 좁힐 수 있다.
이제 RFP Signal은 단순 keyword가 아니라 기존 Lens와 충돌하거나 강화되는 Strategic Tension이 된다.
Deal Signal × Canonical Market Lens → Strategic Tension → Research Question / Hypothesis
예를 들면 이런 가설을 만들 수 있다.
이번 Deal에서는 peak throughput 자체보다 빠르고 안정적인 ramp-up을 증명하는 capability가 더 material한 차별화 요소일 수 있다.
여기서 중요한 것은 이 문장이 결론이 아니라는 점이다.
Hypothesis는 Fact가 아니다.
좋은 Web Search Agent는 이 문장을 그럴듯하게 확장하는 것이 아니라, 이 가설이 맞는지 틀리는지 확인할 evidence를 찾기 시작해야 한다.
Search Query보다 Evidence Requirement를 먼저 만든다
일반적인 Web Search 흐름은 질문을 받자마자 query를 만든다.
“warehouse automation trends”, “AI logistics”, “robotics market” 같은 검색어를 빠르게 생성하고 결과를 모은다.
이 방식은 정보수집에는 유용하다. 하지만 전략 검증에는 한 단계가 빠져 있다.
내가 더 중요하게 보는 순서는 다음과 같다.
RFP → Strategic Signal → Hypothesis → Evidence Requirement → Query → Search
앞의 가설을 검증하려면 어떤 evidence가 필요한지 먼저 정의해야 한다.
예를 들어:
- 경쟁사들이 최근 대형 reference에서 commissioning 기간이나 ramp-up 안정성을 실제 차별화 요소로 제시했는가?
- 고객의 최근 procurement/reference에서 UAT, recovery, downtime visibility 같은 운영 기준이 강화됐는가?
- 경쟁사가 단순 장비 공급을 넘어 WCS·control integration과 lifecycle operation까지 production capability를 확장했는가?
- 공개된 delivery evidence가 실제 납기 경쟁력을 보여주는가, 아니면 roadmap이나 marketing claim에 그치는가?
- 공개 KPI가 존재하는가, 아니면 qualitative claim뿐인가?
이렇게 보면 query는 시작점이 아니다.
Query Expansion보다 먼저 Evidence Contract를 만든다.
무엇을 증명해야 하는지가 정해져야 검색어도 좁아진다.
이미 아는 시장을 다시 조사하지 않는다
Part 1에서 Canonical Market Lens를 time-bounded baseline이라고 정의했다.
그렇다면 Part 2에서 Web Search의 시간축은 더 명확해진다.
Canonical Baseline at t0 + Deal-specific Signal → Strategic Question → Current Web Evidence at t1
Agent가 물어야 할 것은 “현재 물류 자동화 시장의 트렌드는 무엇인가?”가 아니다.
대신 이런 질문이 더 가치 있다.
- 경쟁사 A는 기존 equipment 중심 capability에서 WCS와 robot orchestration까지 실제로 확장했는가?
- 경쟁사 B는 autonomous recovery나 optimization을 production reference로 증명했는가?
- 최근 대형 물류 프로젝트에서 observability나 lifecycle operation이 더 중요한 evaluation axis로 나타나고 있는가?
- delivery lead time이 기술 차별화만큼 procurement decision에 material해졌다는 evidence가 있는가?
이 질문들은 모두 같은 시장을 다룬다. 하지만 검색 목적은 완전히 다르다.
시장 설명이 아니라 기존 전략의 stress test다.
검색 결과는 relevance보다 materiality로 본다
Web Search가 좋은 문서를 찾았다고 해서 그 문서가 현재 Deal에 중요한 것은 아니다.
Semantic relevance와 Strategy Materiality는 다른 문제다.
나는 evidence를 최소한 다음처럼 나누는 편이 유용하다고 본다.
- MATERIAL — 현재 전략 가설을 바꿀 정도로 중요하다.
- CONTEXT_ONLY — 주제와 관련은 있지만 현재 Deal 판단에는 영향이 제한적이다.
- CONFLICT — 기존 Canon과 충돌한다.
- INSUFFICIENT — claim을 지지하기에는 근거가 부족하다.
- HOLD — 중요하지만 다른 internal·delivery·commercial evidence가 없어 전략 승격이 불가능하다.
Materiality를 판단할 때는 이런 질문을 던질 수 있다.
- Customer Buying Criteria를 바꾸는가?
- Competitor Position을 바꾸는가?
- 우리의 Differentiation을 좁히거나 강화하는가?
- Delivery Risk를 바꾸는가?
- Commercial Constraint를 바꾸는가?
- Scope Ownership에 대한 판단을 바꾸는가?
어느 질문에도 영향을 주지 않는다면 최신 기사라도 이번 Deal에서는 CONTEXT_ONLY일 수 있다.
반대로 겉보기에는 좁은 competitor reference 하나라도 기존 차별화 논리를 직접 흔든다면 MATERIAL할 수 있다.
하나의 검색 결과가 Strategy Delta가 되는 과정
예를 들어 Canon에 이런 baseline이 있다고 하자.
Competitor A는 robotics에는 강하지만 integrated WCS/control capability의 대형 reference는 제한적이다.
그런데 현재 Web Research에서 최근 대형 deployment reference, WCS integration capability, robot orchestration 확대 evidence가 함께 확인됐다고 해보자.
여기서 Agent가 바로 이렇게 말하면 안 된다.
“Competitor A가 이제 우리보다 강하다.”
그건 evidence에서 strategy verdict로 너무 빨리 점프한 것이다.
보다 안전한 구조는 다음과 같다.
Baseline → New Evidence → Validated Capability Delta → Deal-specific Strategic Impact
예를 들어 Delta는 이렇게 표현할 수 있다.
기존 integration differentiation이 일부 경쟁축에서 좁아지고 있을 가능성이 있다.
그리고 기존 hypothesis의 상태를 갱신한다.
- STRENGTHEN — 기존 가설을 더 강하게 지지한다.
- WEAKEN — 가설의 일부 전제가 약해진다.
- INVALIDATE — 핵심 전제가 더 이상 유지되지 않는다.
- UNRESOLVED — 현재 evidence만으로는 판단할 수 없다.
이 구조에서 Web Search Agent의 가치는 정보를 많이 모으는 데 있지 않다.
기존 판단 중 어떤 것을 다시 열어야 하는지 알려주는 데 있다.
Public Evidence는 내부 사실이 아니다
Enterprise Research에서는 evidence의 내용만큼 provenance가 중요하다.
예를 들어 고객이 기술 내재화를 강화하고 있다는 공개 evidence를 발견했다고 하자.
그 사실만으로:
“이 고객은 automation capability를 모두 내부에서 구축한다.”
라고 결론내릴 수 없다.
마찬가지다.
strong internal technology ownership ≠ all automation capability built internally
public investment signal ≠ current procurement boundary
competitor product announcement ≠ proven production capability
그래서 evidence를 최소한 다음 provenance class로 분리할 필요가 있다.
- DEAL_FACT
- MI_BASELINE
- EXTERNAL_FACT
- INTERNAL_FACT
- ACCOUNT_FACT
- COMMERCIAL_FACT
- STRATEGIC_HYPOTHESIS
그리고 몇 가지 승격은 금지해야 한다.
Public inference → ACCOUNT_FACT는 안 된다.
Hypothesis → FACT도 안 된다.
과거 보고서의 position을 current installed-base fact로 자동 승격해서도 안 된다.
이 경계를 지키지 않으면 Search Agent는 조사 도구가 아니라 근거 없는 certainty generator가 된다.
External MI의 output은 Strategy가 아니다
여기서 또 하나의 경계가 필요하다.
Web Search Agent가 충분한 external evidence를 모았다고 해서 final strategy를 결정할 수 있는 것은 아니다.
실제 전략에는 웹에서 알 수 없는 정보가 필요하다.
- Company Capability
- Account / Relationship
- Historical Win / Loss
- Delivery Reality
- Commercial Constraint
따라서 출력 boundary는 이렇게 두는 편이 낫다.
Deal Context + Canonical Lens + Current External Evidence → Validated Delta → Strategy-ready Hypotheses → Strategy Synthesis
External MI alone은 informative하다.
하지만 External MI × Deal × Internal Reality가 되어야 strategy-relevant해진다.
이 차이는 작아 보이지만 Agent architecture에서는 크다.
Web Search Agent가 final Win Theme을 만들기 시작하면, 자신이 알 수 없는 내부 정보까지 추정해서 narrative를 완성하려는 유혹이 생긴다.
그 책임은 상위 Strategy Synthesis에 남겨두는 편이 안전하다.
좋은 Agent는 HOLD할 수 있어야 한다
가장 실용적인 예가 delivery다.
Web Research에서 빠른 납기가 최근 Deal에서 material한 경쟁 요소라는 evidence를 충분히 찾았다고 해보자.
Market Lens에서도 delivery assurance가 기존 경쟁축과 잘 맞는다.
그러면 “Fast Delivery”를 전략 메시지로 만들고 싶어진다.
하지만 내부 manufacturing slot이나 critical component capacity가 확인되지 않았다면 상황은 달라진다.
External Evidence = STRONG
Strategic Relevance = HIGH
Internal Feasibility = UNKNOWN
결과는 HOLD여야 한다.
이것이 중요한 이유는 단순하다.
좋은 Agent는 좋은 이야기를 많이 만드는 Agent가 아니라, 아직 말해서는 안 되는 이야기를 멈출 수 있는 Agent다.
HOLD는 실패가 아니다. evidence boundary를 보존한 정상 상태다.
필요하다면 다음 액션은 더 많은 Web Search가 아니라 internal Evidence Request가 된다.
Scope, Lens, Delta
이제 세 편의 흐름을 하나로 정리할 수 있다.
첫 번째 문제는 Scope였다.
무엇을 검색할 자격이 있는가?
두 번째는 Lens였다.
기업은 그 시장을 어떤 좌표계로 보는가?
그리고 마지막이 Delta다.
무엇이 기존 전략을 바꿀 만큼 달라졌는가?
이 세 가지를 분리하면 Web Search의 역할도 달라진다.
RFP의 모든 키워드를 인터넷에 던지고 많은 결과를 모으는 방식에서 벗어나, Deal이 실제로 제기한 전략적 tension을 찾고, Canonical Lens와 비교하고, 필요한 evidence만 좁혀서 검증할 수 있다.
그래서 Enterprise Web Search Agent의 성능을 단순히 검색 결과의 양이나 최신성으로 평가하는 것은 부족하다.
더 중요한 질문은 이것이다.
이 Agent가 우리 회사의 기존 전략에서 무엇을 다시 검증해야 하는지를 정확히 좁혀냈는가?
그 지점에서 Web Search는 시장조사 도구를 넘어 전략 검증의 일부가 된다.