Discover
장비와 상태가 먼저 보이는가
운영 대상이 무엇인지 빠르게 파악할 수 있어야 다음 단계 설명이 쉬워집니다.
Insights
장비 자동 발견 다음에 토폴로지와 진단이 왜 한 흐름이어야 하는가
장비를 찾는 단계와 연결 관계를 해석하는 단계, 그리고 진단과 다음 조치를 정리하는 단계가 서로 분리돼 있으면 운영자는 계속 화면을 옮겨 다녀야 합니다. 좋은 운영 제품은 발견 이후의 흐름이 자연스럽게 이어져야 합니다.
Discovery
Topology
Diagnosis
How It Works CTA
Operating Problem
발견 이후 흐름이 끊기면 결국 운영자는 여러 화면을 짜깁기해서 설명해야 합니다.
한 흐름인지 아닌지는 기능 수보다 운영자의 설명 비용과 브리핑 시간에서 먼저 드러납니다.
| 상황 | 흐름이 분리된 경우 | 한 흐름으로 이어진 경우 |
|---|---|---|
| 장비 목록 확인 | 인벤토리만 보고 다음 질문이 생기면 다른 도구로 이동해야 합니다. | 장비를 본 뒤 바로 연결 관계와 상태로 이어집니다. |
| 연결 관계 설명 | 토폴로지를 띄워도 인벤토리 맥락이 끊겨 다시 설명해야 합니다. | 발견된 대상과 맵이 같은 문맥에 있어 설명이 짧아집니다. |
| 진단과 next action | 토폴로지에서 또 다른 진단 화면으로 넘어가며 브리핑이 끊깁니다. | 경로 맥락과 진단, 다음 조치가 한 흐름으로 이어집니다. |
| 내부 공유 자료 | 스크린샷을 여러 장 조합해야 해서 공유 자료 준비가 느립니다. | 한 흐름 안의 화면만으로도 회의 자료를 빠르게 만들 수 있습니다. |
Three Flow Checks
발견 이후 흐름을 볼 때는 아래 세 장면이 자연스럽게 이어지는지 먼저 보면 됩니다.
기능 목록보다 화면 전환과 질문 해소 순서가 더 중요합니다.
Map
관계와 경로가 같은 문맥에서 이어지는가
토폴로지로 넘어갈 때 장비 목록과 상태 맥락이 사라지지 않아야 합니다.
Diagnose
다음 조치까지 연결되는가
진단 결과가 별도 보고서가 아니라 실제 운영 판단으로 이어져야 합니다.
Product Evidence
발견 단계가 좋으려면 그 다음 질문으로 자연스럽게 이어질 수 있어야 합니다.
아래 화면은 장비 발견이 단독 기능이 아니라 이후 흐름의 시작점으로 작동하는 실제 장면입니다.
Auto Discovery
장비를 찾는 순간부터 운영 대상 목록과 상태를 같은 문맥으로 정리
발견된 장비, reachability, vendor 상태가 정리되면 그 다음 단계인 토폴로지와 진단으로 자연스럽게 이어질 수 있습니다.
Best Fit Teams
특히 데모를 운영 흐름 기준으로 검토하는 팀이라면 이 질문이 더 중요합니다.
한 화면의 품질보다 단계 간 연결성이 중요한 팀에게 맞는 글입니다.
Operations
실환경 검증을 준비하는 운영팀
기능이 아니라 실제 운영 질문이 어떤 순서로 해결되는지 보고 싶은 팀에 적합합니다.
Technical Review
제품 검토를 맡은 기술 리드
발견에서 끝나지 않고 토폴로지와 진단까지 이어지는지 확인하고 싶은 경우에 유용합니다.
Pre-Sales
내부 설득 자료를 만들어야 하는 담당자
글의 흐름을 그대로 설명 자료의 골격으로 재활용할 수 있습니다.
Pilot
파일럿 범위를 좁혀야 하는 팀
발견만 볼지, 관계와 진단까지 볼지 빠르게 판단하는 기준이 됩니다.
Main CTA
발견 이후 흐름이 중요한 이유가 정리됐다면, 이제 실제 데모 순서를 보면 됩니다.
How It Works 페이지에서 Setup, Discovery, Topology, Diagnosis 흐름이 실제 화면 기준으로 어떻게 이어지는지 확인할 수 있습니다.