Monithub 소개

Monithub는 대시보드, 회의 기록, 문서와 대화방에 흩어진 운영 맥락을 하나로 연결하는 관측 및 인시던트 대응 플랫폼입니다. 문제가 발생할 때마다 여러 화면에서 데이터를 찾고, 흩어진 기록을 모아 상황을 다시 설명하는 반복을 줄이기 위해 만들었습니다. 시스템에서 발생하는 신호와 대응 기록을 연결해, “지금 어디에 문제가 있고, 무엇이 영향을 받았으며, 우리 팀은 다음에 무엇을 해야 하는가?”라는 질문에 팀이 함께 답하도록 돕습니다. 대응 과정에서 남은 근거와 판단, 해결 결과는 다음 대응과 탐지 기준 개선에 다시 쓰여 운영 지식이 담당자의 기억에만 머물지 않게 합니다.

메트릭, 로그, 트레이스와 네트워크 연결 정보는 시스템 상태를 이해하는 핵심 자료입니다. 그러나 데이터가 서로 다른 화면에 있고 판단과 논의가 별도의 회의록이나 대화방에 남으면, 문제를 발견할 때마다 맥락을 처음부터 다시 구성해야 합니다. 이상 징후가 나타난 시점과 영향 대상을 찾고, 근거를 모아 담당자와 대응 과정을 공유하는 일까지 하나의 흐름으로 이어져야 문제를 빠르게 해결할 수 있습니다. Monithub는 관측, 판단, 협업과 기록이 도구 사이에서 끊기지 않도록 연결합니다.

이 문서에서 알 수 있는 것

이 문서는 화면 조작 순서보다 Monithub가 해결하는 문제, 기능 간 연결과 팀의 시작 지점을 설명합니다. 실제 화면 사용 방법은 제품 사용 가이드에서 확인할 수 있습니다.

1. Monithub가 해결하려는 문제

운영 중인 시스템에서는 하나의 문제가 여러 신호로 나타납니다. 응답 시간이 느려지고 오류 로그가 늘어나며, 특정 서비스의 호출이 실패하거나 Kubernetes 리소스 상태가 달라질 수 있습니다. 신호를 따로 보면 중요한 변화인지 일시적인 흔들림인지 판단하기 어렵습니다.

문제를 발견한 뒤에도 담당자는 여러 화면에서 근거를 모으고, 메신저에서 상황을 다시 설명하며, 누가 무엇을 확인했는지 기록해야 합니다. 대응이 끝나면 흩어진 기록을 다시 정리하고, 같은 유형의 신호가 반복될 때는 탐지 기준도 조정해야 합니다.

이 과정이 개인의 경험과 기억에만 남으면 담당자가 바뀔 때마다 같은 조사와 설명을 반복하게 됩니다. 대응 중 확인한 근거와 판단, 조치 결과가 다음 문제 해결과 탐지 개선에 다시 쓰일 수 있어야 장애 대응과 운영 노하우가 조직 전체의 자산이 됩니다.

Monithub는 이 과정에서 반복되는 네 가지 어려움을 줄이는 데 초점을 둡니다.

운영 중 겪는 어려움	Monithub가 돕는 방식
데이터는 많지만 현재 상태를 한눈에 파악하기 어렵습니다.	홈, 대시보드와 서비스 맵에서 조직의 상태와 변화 흐름을 여러 관점으로 확인합니다.
여러 이상 신호 중 무엇부터 확인해야 할지 판단하기 어렵습니다.	Sentinel의 이상탐지 결과와 인시던트의 심각도, 영향 범위, 관련 근거를 함께 살펴봅니다.
분석 화면과 대응 대화가 분리되어 맥락이 끊깁니다.	인시던트에서 확인한 문제를 워룸으로 이어 담당자, 대화, 요약과 대응 기록을 같은 맥락에서 관리합니다.
대응 경험이 다음 탐지와 운영 개선으로 이어지지 않습니다.	인시던트 해결 기록과 탐지 결과 라벨을 함께 남기고, 이를 모델 학습·검토와 후속 개선에 연결해 운영 경험을 조직의 자산으로 축적합니다.

2. 관측에서 대응까지 이어지는 하나의 흐름

Monithub는 개별 기능의 모음이 아니라, 데이터를 연결하고 상태를 관측한 뒤 문제에 대응하며 그 경험을 다음 운영에 활용하는 하나의 흐름으로 이해할 수 있습니다.

2.1. 운영 데이터를 연결합니다

먼저 조직의 시스템에서 Monithub로 관측 데이터가 들어오도록 연결합니다. Connect에서는 OpenTelemetry Collector, Linux 호스트, Docker, Java 애플리케이션, Kubernetes와 Custom OTLP 같은 수집 대상을 선택하고 연결 계획을 세울 수 있습니다. Kubernetes 환경에서는 Monithub K8S Operator가 수집 컴포넌트를 설치하고 관리하도록 구성합니다.

연결한 뒤에는 설치 여부뿐 아니라 실제 데이터가 수집되는지, 어떤 서비스가 관찰되는지 확인해야 합니다. 연결 목록, 대시보드와 서비스 맵을 함께 살펴보면 수집 상태를 더 정확하게 검증할 수 있습니다.

2.2. 현재 상태와 변화 흐름을 관측합니다

홈은 로그인 직후 현재 조직의 열린 인시던트, 최근 활동과 시스템 상태를 요약해 보여 줍니다. 더 자세한 분석이 필요하면 대시보드에서 시간 범위와 변수를 조정하고, 메트릭·로그·트레이스·이벤트를 목적에 맞는 패널로 살펴봅니다.

서비스 맵은 서비스 간 호출 관계를 토폴로지로 보여 줍니다. 느리거나 실패한 연결을 중심으로 upstream과 downstream을 좁혀 보면 문제가 시작된 지점과 영향이 퍼지는 방향을 파악할 수 있습니다.

2.3. 평소와 다른 신호를 찾고 판단합니다

Monithub Sentinel은 관측 데이터에서 평소 패턴과 다른 구간을 찾습니다. 원본 데이터와 탐지 결과를 같은 시간축에 표시하므로 값의 변화와 이상 구간을 함께 비교할 수 있습니다.

이상 신호가 곧 확정된 장애를 의미하지는 않습니다. 운영자는 해당 시점의 시스템 상태와 관련 근거를 확인하고 정탐·오탐·미탐 같은 라벨을 남길 수 있습니다. 운영팀은 이 판단 기록과 실제 해결 결과를 바탕으로 새 후보 모델을 학습하고 품질을 검토한 뒤, 운영에 적합한 버전만 활성화합니다. 탐지 성향과 학습 조건을 조정하고 모델을 승격하는 일은 운영 근거에 따라 사람이 결정합니다.

2.4. 관련 신호를 인시던트의 맥락으로 확인합니다

인시던트는 문제 대응의 시작점입니다. 개별 경고를 나열하는 대신, 함께 살펴봐야 할 이상 신호와 영향 대상, 심각도, 상태, 담당자와 시간 흐름을 한 공간에 모아 보여 줍니다.

운영자는 인시던트가 실제로 진행 중인지, 어떤 서비스나 리소스가 영향을 받았는지, 무엇을 먼저 확인해야 하는지 판단합니다. 메트릭, 로그, 트레이스와 Kubernetes 맥락을 함께 살펴보면 화면을 옮길 때마다 문제를 다시 설명하는 일을 줄일 수 있습니다. 발견 당시의 근거부터 최종 해결 결과까지 같은 인시던트에 남아 이후 유사한 문제를 검토할 때 다시 활용할 수 있습니다.

2.5. 워룸에서 함께 대응하고 기록합니다

워룸은 인시던트별 대화와 대응 기록을 관리하는 협업 공간입니다. 담당자를 부르고 확인한 사실과 가설을 공유하며, 누가 무엇을 확인했는지, 어떤 근거로 다음 행동을 정했는지, 조치 결과가 어땠는지를 한 흐름으로 남길 수 있습니다.

Monithub AI는 워룸 대화와 인시던트 맥락을 바탕으로 요약과 브리프 작성을 돕습니다. 긴 대화에서 확인된 내용과 남은 질문을 빠르게 파악하는 데 유용하지만, 최종 판단과 실행은 실제 시스템 상태를 확인한 담당자가 결정합니다.

이렇게 남은 기록은 종료 후 회고를 위한 자료에 그치지 않습니다. 새 담당자가 과거의 판단 근거를 파악하고, 같은 유형의 문제가 반복될 때 이전 조치와 결과를 재사용하는 조직의 운영 지식이 됩니다.

2.6. 대응 결과를 다음 운영에 반영합니다

문제를 해결한 뒤에는 원인, 영향 범위, 확인한 근거, 실행한 조치와 결과를 인시던트와 워룸의 맥락 안에서 정리합니다. 탐지 결과가 실제 상황과 달랐다면 운영팀은 해결 기록과 정탐·오탐·미탐 라벨을 바탕으로 새 모델 후보를 학습하고, 기존 모델과 비교·검토해 탐지 기준을 조정합니다.

관측, 판단, 대응과 피드백이 이렇게 연결되면 유사한 문제가 생겼을 때 과거의 근거와 해결 방법을 바로 찾아 더 일관된 기준으로 대응할 수 있습니다. 장애 대응과 운영 노하우가 조직 전체의 운영 자산으로 축적되어 특정 사람의 기억에 의존하지 않는 운영 관리를 돕는 것이 이 흐름의 목적입니다.

3. 누구를 위한 제품인가요?

Monithub는 운영 데이터를 직접 분석하는 사람뿐 아니라, 문제 상황에서 같은 맥락을 공유해야 하는 팀 전체를 위한 제품입니다.

사용자	Monithub에서 주로 하는 일
SRE·DevOps·운영 담당자	홈과 대시보드에서 상태를 확인하고, 서비스 맵과 인시던트 근거를 바탕으로 문제 범위를 좁힙니다.
개발자	담당 서비스의 메트릭, 로그와 트레이스를 확인하고, 워룸에서 원인 가설과 수정 결과를 공유합니다.
인시던트 리드	심각도와 영향 범위를 판단하고, 담당자와 다음 행동을 정하며, 대응 상황을 요약하고 종료 조건을 확인합니다.
플랫폼·조직 관리자	조직과 멤버, 데이터 연결, 수집 상태, 알림 채널, 사용량과 요금제를 관리합니다.
기술 책임자·팀 리더	현재 위험과 반복되는 문제, 대응 진행 상황을 파악하고 우선순위와 후속 개선 작업을 결정합니다.

한 사람이 여러 역할을 맡을 수도 있습니다. 소규모 팀에서는 관리자가 데이터 연결과 인시던트 대응을 함께 담당하고, 규모가 커지면 관측, 분석, 대응과 조직 관리 역할을 나눌 수 있습니다.

역할이나 담당자가 바뀌더라도 같은 인시던트 맥락과 해결 기록을 이어서 볼 수 있으므로, 팀은 개인의 경험을 조직의 공통된 운영 기준으로 발전시킬 수 있습니다.

4. 먼저 알아두면 좋은 핵심 개념

처음에는 메뉴 이름보다 아래 개념이 어떻게 이어지는지 이해하는 것이 중요합니다.

개념	쉽게 말하면
조직	사용자, 권한, 연결과 운영 데이터를 구분하는 작업 공간입니다. 상단에서 조직을 바꾸면 화면에 보이는 데이터 범위도 달라집니다.
관측 데이터	시스템 상태를 이해하기 위해 수집하는 메트릭, 로그, 트레이스, 이벤트와 네트워크 관계 정보입니다.
Connect	어떤 환경과 수집 대상을 Monithub에 연결할지 선택하고 설정 계획을 만드는 기능입니다.
대시보드	여러 관측 데이터를 목적에 맞는 패널로 배치해 함께 보는 화면입니다.
패널	숫자, 시계열, 표, 로그, 트레이스 등 하나의 질문에 답하도록 데이터를 표현하는 대시보드 구성 단위입니다.
서비스 맵	서비스 간 호출 방향과 연결 상태를 그래프로 보여 주는 화면입니다.
이상 신호	평소 패턴과 달라 추가 확인이 필요한 데이터 구간입니다. 이상 신호가 항상 실제 장애를 뜻하는 것은 아닙니다.
Sentinel 모델	이상 신호를 찾는 기준입니다. 운영자가 해결 기록과 탐지 결과 라벨을 바탕으로 새 후보를 학습·검토한 뒤 활성 버전을 운영에 사용합니다.
인시던트	관련 신호와 영향 대상을 묶어 문제의 근거, 판단, 조치와 해결 결과를 관리하는 작업 단위입니다.
워룸	인시던트 참여자가 누가 무엇을 확인하고 결정했는지 대화, 행동과 결과를 함께 남기는 협업 공간입니다.
알림	새 인시던트, Connect 수집 상태와 워룸 메시지처럼 사용자가 확인해야 할 변화를 전달하는 기능입니다.
Gateway	AI Gateway의 상태, 등록된 서비스와 모델, 라우팅 및 요청 테스트를 확인하는 운영 화면입니다.

5. 주요 기능을 사용자 관점에서 살펴보기

5.1. 홈: 어디에서부터 확인할지 정합니다

홈은 여러 운영 화면 중 첫 번째 확인 지점입니다. 열린 인시던트 수, 최근 활동, 영향 대상과 시스템 상태를 함께 보며 지금 확인해야 할 문제가 있는지 판단할 수 있습니다.

정상 여부를 단정하기보다 오늘의 운영 상태에서 어디를 먼저 볼지 정하는 화면입니다. 위험 또는 주의 상태가 보이거나 특정 대상이 반복해서 영향을 받았다면 대시보드나 인시던트로 이동해 근거를 확인합니다.

홈과 기본 탐색 방법 알아보기 →

5.2. 대시보드와 패널: 질문에 맞게 데이터를 구성합니다

대시보드는 Kubernetes 리소스, 애플리케이션, 로그, 트레이스, Gateway, 비용과 수집량 등 서로 다른 운영 주제를 패널 단위로 구성합니다. 시간 범위와 Namespace, Node, Pod 같은 변수를 사용하면 같은 대시보드에서도 분석 대상을 빠르게 좁힐 수 있습니다.

운영자는 큰 숫자로 현재 상태를 확인하고, 시계열로 변화 시점을 찾으며, 표와 로그에서 구체적인 근거를 살펴봅니다. 필요한 권한이 있으면 데이터 쿼리, 필드 표현, 시각화 방식과 패널 배치를 업무에 맞게 편집할 수 있습니다.

• 대시보드 사용 방법 →
• 패널 편집과 시각화 유형 →

5.3. 서비스 맵: 영향이 퍼지는 방향을 이해합니다

서비스 맵은 선택한 서비스를 중심으로 직접 연결된 upstream과 downstream을 보여 줍니다. 서비스 상태, 호출 방향과 지연 시간을 함께 비교하면 “어느 서비스가 느린가?”뿐 아니라 “어느 연결에서 문제가 시작되었고 다음에 무엇이 영향을 받는가?”까지 살펴볼 수 있습니다.

연결이 복잡한 환경에서는 1-hop부터 확인하고 필요할 때 2-hop으로 넓히는 것이 좋습니다. 전체 토폴로지로 큰 흐름을 비교하되, 실제 문제는 영향받은 서비스를 중심으로 범위를 좁혀 분석합니다.

서비스 맵에서는 왼쪽에서 네임스페이스와 서비스를 선택하고, 가운데에서 연결 흐름을 살펴보며, 오른쪽에서 연결 수와 지연 시간 같은 핵심 정보를 확인할 수 있습니다.

서비스 맵 사용 방법 알아보기 →

5.4. Sentinel: 이상탐지를 운영 경험에 맞게 관리합니다

Sentinel은 관측 데이터에서 이상 징후를 찾고 모델 버전을 관리하는 기능입니다. 운영자는 Sentinel이 제시한 탐지 결과를 실제 인시던트 해결 기록과 비교하고 라벨을 남긴 뒤, 이를 근거로 새 모델 후보를 학습·검토해 탐지 기준을 운영 환경에 맞게 다듬습니다.

모델 튜닝 화면에서는 활성·후보 버전, 다음 학습 시각과 라벨의 재학습 반영 여부를 한눈에 확인할 수 있습니다. 주기 분석 일정과 최근 실행 결과도 같은 화면에서 살펴보며 학습과 탐지가 계획대로 이어지는지 점검합니다. 탐지가 지나치게 민감하거나 중요한 변화를 놓친다면 운영자가 라벨과 해결 결과를 근거로 학습 조건과 분석 주기를 조정한 뒤 새 후보를 다시 검증합니다.

대시보드에서는 탐지된 이상 구간을 원본 시계열 위에 표시합니다. 구간을 선택하면 대상 시계열, 시작·종료 시각과 지속 시간을 확인할 수 있어 값의 변화와 탐지 결과를 같은 맥락에서 판단하기 쉽습니다.

Monithub Sentinel 이해하고 사용하기 →

5.5. 인시던트: 신호를 실제 문제의 맥락으로 정리합니다

인시던트에서는 문제의 상태와 심각도, 영향 대상, 담당자와 관련 근거를 함께 확인합니다. 목록에서 우선순위를 판단하고 상세 화면에서 시간 흐름과 텔레메트리 맥락을 살펴본 뒤, 필요하면 문제를 분리하거나 관련 항목을 함께 다룰 수 있습니다.

목표는 단순히 경고 개수를 줄이는 것이 아닙니다. 팀이 같은 근거를 바탕으로 지금 대응해야 하는 문제인지, 누가 무엇을 확인할지, 언제 해결되었다고 볼지 합의하고 그 판단과 결과를 다음 대응에 남기는 것이 중요합니다.

인시던트와 워룸의 전체 흐름 알아보기 →

5.6. 워룸과 Monithub AI: 대응 맥락을 공유합니다

워룸에서는 인시던트별로 대화를 나누고 조직 멤버를 부르며, 확인한 사실과 다음 행동을 기록합니다. 단순한 대화방이 아니라 담당자, 판단 근거, 조치와 결과를 인시던트에 연결해 대응 과정을 조직이 다시 활용할 수 있는 기록으로 남기는 공간입니다.

Monithub AI의 요약과 브리프는 새로 참여한 사람이 긴 대화를 모두 읽지 않고도 현재 상황을 파악하도록 돕습니다. 관찰된 문제, 지금까지 확인한 내용과 남은 질문을 정리한 뒤 실제 근거와 비교해 활용합니다.

대응이 끝난 뒤에도 이 기록을 통해 새 담당자는 당시 상황을 다시 설명받지 않고 원인과 해결 과정을 파악할 수 있습니다. 반복되는 문제에서는 과거에 효과가 있었던 조치와 남은 후속 작업을 바로 찾아볼 수 있습니다.

워룸에서 협업하는 방법 알아보기 →

5.7. 알림: 필요한 변화를 놓치지 않게 합니다

알림함은 새 인시던트, Connect 수집 상태와 워룸 메시지를 한곳에서 확인하는 기본 채널입니다. 읽음 상태, 유형, 심각도, 기간과 키워드로 항목을 좁혀 보고 해당 인시던트나 워룸으로 바로 이동할 수 있습니다.

사용 환경에 따라 Web Push, Telegram과 앱 알림음을 설정할 수 있습니다. 인시던트는 항상 받되, 워룸 메시지는 멘션만 받을지, 모든 메시지를 받을지, 받지 않을지 선택해 불필요한 알림을 줄일 수 있습니다.

• 알림 확인과 설정 →
• Telegram 연결과 전송 →

5.8. Connect와 Monithub K8S Operator: 관측 기반을 마련합니다

Connect에서는 수집 환경과 대상을 구분해 연결 계획을 만듭니다. Bare Metal과 Kubernetes 중 환경을 선택하고, OpenTelemetry Collector, Linux, Docker, Java 애플리케이션이나 Custom OTLP 등 필요한 대상을 고를 수 있습니다.

Kubernetes 환경에서는 Monithub K8S Operator가 Collector와 Agent를 설치하고 관리합니다. 처음에는 수집 범위를 작게 설정하고 데이터가 정상적으로 들어오는지 확인한 뒤, 필요한 신호와 범위를 점진적으로 넓히는 것이 좋습니다.

• Connect와 Gateway 화면 알아보기 →
• Monithub K8S Operator 설치하기 →
• Telemetry 필터링하기 →

5.9. 조직과 설정: 운영 범위와 사용 환경을 관리합니다

Monithub의 데이터와 권한은 조직을 기준으로 나뉩니다. 사용자는 새 조직을 만들거나 기존 조직에 참여하고, 관리자는 멤버를 초대하거나 참여 요청을 처리합니다. 화면 상단에서 현재 조직을 바꾸면 대시보드, 인시던트, 워룸과 요금·구독의 데이터 범위도 함께 달라집니다.

Settings에서는 프로필, 인시던트, 데이터소스, 조직과 Sentinel 관련 설정을 관리합니다.

• 가입과 조직 참여 →
• 멤버 초대와 참여 요청 →
• 설정 →

5.10. 요금과 구독: 사용 현황과 청구 상태를 관리합니다

요금과 구독에서는 현재 요금제와 갱신일, 사용량과 한도를 확인합니다. 운영자는 요금제와 부가 기능을 조정하고, 수동 청구 요약을 생성·확정·내보내거나 구독 상태를 관리할 수 있습니다.

• 요금과 구독 →

6. 실제 상황에서는 어떻게 사용하나요?

6.1. 서비스 응답이 갑자기 느려진 경우

1. 홈에서 열린 인시던트와 영향 대상, 최근 활동을 확인합니다.
2. 관련 대시보드에서 시간 범위를 문제 발생 시점으로 맞추고 응답 시간, 오류와 리소스 변화를 비교합니다.
3. 서비스 맵에서 느린 서비스를 선택해 직접 연결된 upstream과 downstream 상태를 확인합니다.
4. 인시던트 상세에서 관련 메트릭, 로그, 트레이스와 Kubernetes 맥락을 함께 살펴봅니다.
5. 워룸을 열어 담당자를 부르고, 확인된 사실과 원인 가설, 다음 행동을 기록합니다.
6. 대응 대화가 길어지면 AI 요약이나 브리프로 현재 상황을 정리하고 실제 근거와 비교합니다.
7. 복구 후 원인, 영향 범위, 확인 근거, 조치 결과와 반복 방지 작업을 정리하고, 탐지 결과 라벨과 모델 학습·검토 필요 여부를 남깁니다.

이 흐름의 목적은 모든 분석을 자동화하는 것이 아니라, 사람이 판단하는 데 필요한 근거와 협업 맥락을 끊김 없이 연결하는 것입니다. 축적된 해결 기록은 다음 담당자와 다음 인시던트가 다시 사용할 수 있는 조직의 운영 자산이 됩니다.

6.2. 이상탐지 알림이 너무 자주 발생하는 경우

1. 이상 구간이 실제 운영 문제였는지 대시보드와 인시던트 근거로 확인합니다.
2. 정탐, 오탐 또는 무시됨 라벨을 남겨 판단 결과를 구분합니다.
3. 같은 유형의 오탐이 반복되는지 기간과 데이터 소스별로 살펴봅니다.
4. 반복된 오탐의 해결 기록과 라벨을 근거로 운영자가 Sentinel의 탐지 성향이나 학습 조건을 조정해 새 후보 버전을 학습합니다.
5. 후보의 품질과 소스 커버리지를 검토한 뒤, 기존 활성 버전보다 적합할 때만 승격합니다.
6. 변경 후 대시보드의 이상 구간과 새 인시던트 흐름을 관찰해 개선 여부를 확인합니다.

6.3. 새 Kubernetes 클러스터를 연결하는 경우

1. 올바른 조직을 선택하고 Connect에서 Kubernetes 연결 계획을 만듭니다.
2. 발급된 식별 정보와 토큰, OTLP endpoint와 registry 인증 정보를 안전하게 준비합니다.
3. 클러스터에 Monithub K8S Operator와 기본 수집 컴포넌트를 설치합니다.
4. Monithub K8S Operator, Collector와 Agent 상태가 정상인지 확인합니다.
5. Monithub 연결 목록과 서비스 맵에서 실제 데이터가 들어오는지 검증합니다.
6. 기본 수집이 안정된 뒤 필요한 telemetry preset과 필터를 조정합니다.

7. 사용할 때 기억할 점

• 현재 조직을 먼저 확인합니다. 조직이 다르면 같은 메뉴에서도 보이는 데이터와 권한이 달라집니다.
• 시간 범위와 필터를 함께 확인합니다. 데이터가 없거나 평소와 다르게 보일 때는 수집 문제로 단정하기 전에 조회 범위를 확인합니다.
• 이상 신호와 AI 결과는 판단을 돕는 근거입니다. 실제 장애 여부와 실행할 조치는 시스템 상태와 팀의 운영 기준을 바탕으로 결정합니다.
• 대응 기록은 다음 대응에서 다시 쓸 수 있게 남깁니다. 확인 근거, 판단 이유, 조치 결과와 후속 작업을 인시던트와 워룸의 같은 맥락에 정리하면 특정 사람의 기억에 의존하지 않고 운영 경험을 이어갈 수 있습니다.
• 보이는 기능은 권한과 연결 상태에 따라 달라질 수 있습니다. 필요한 메뉴가 없거나 데이터를 볼 수 없다면 조직 관리자에게 권한과 데이터소스 상태를 확인합니다.
• 민감한 연결 정보는 안전하게 관리합니다. Connect token과 registry token은 문서, 이슈나 메신저에 남기지 않고 Secret으로 주입합니다.

8. 역할에 맞게 시작하기

지금 하려는 일	추천 시작 문서
처음 가입하고 화면을 익히고 싶습니다.	가입과 조직 참여 → 홈과 기본 탐색
우리 시스템의 상태를 관측하고 싶습니다.	대시보드 → 서비스 맵
인시던트 대응 흐름을 준비하고 싶습니다.	인시던트 및 워룸 개요 → 알림 확인과 설정
이상탐지 모델을 운영하고 싶습니다.	Monithub Sentinel → 실습 가이드 → 학습과 튜닝
Kubernetes 데이터를 처음 연결하고 싶습니다.	Connect와 Gateway → Monithub K8S Operator 설치
프로필, 데이터소스와 조직 설정을 관리하고 싶습니다.	설정
요금제, 사용량, 청구 요약과 구독 상태를 확인하고 싶습니다.	요금과 구독

제품의 역할과 전체 흐름을 이해했다면 제품 사용 가이드에서 필요한 작업을 골라 시작해 보세요.