본문으로 건너뛰기

서비스 관리

경로: /services, /services/edit/:id

서비스 관리는 KIWI의 핵심 페이지입니다. 여러분의 Git 저장소에 있는 소스 코드를 컨테이너 이미지로 빌드하고, Kubernetes나 Docker 환경에 배포하며, 보안 취약점까지 한 곳에서 관리할 수 있습니다.

서비스 관리 화면

권한 안내

일부 기능에 접근할 수 없다면 기관 관리자에게 권한을 요청하세요. 권한 설정은 [권한 관리] 페이지에서 확인할 수 있습니다.

왜 서비스 관리가 필요한가요?​

현대의 소프트웨어 개발에서는 코드 작성만큼이나 빌드, 배포, 보안이 중요합니다. 서비스 관리 페이지는 이 모든 과정을 하나의 화면에서 처리할 수 있도록 도와줍니다.

  • Git 연동: 여러 저장소의 코드를 일일이 관리하기 번거로운 문제를 해결합니다. 한 곳에서 모든 저장소를 연결하고 관리할 수 있습니다.
  • 자동 빌드: 수동 빌드의 실수와 시간 낭비 문제를 해결합니다. 코드 푸시 시 자동으로 이미지가 생성됩니다.
  • 원클릭 배포: 복잡한 배포 명령어와 설정 문제를 해결합니다. 버튼 하나로 여러 환경에 배포할 수 있습니다.
  • 보안 스캔: 취약점을 뒤늦게 발견하는 문제를 해결합니다. 개발 단계부터 보안 문제를 사전에 탐지합니다.

주요 기능​

Git 저장소 연동​

GitLab 저장소를 토큰 기반으로 연결하고, 브랜치나 태그를 선택하여 작업할 수 있습니다. 자동 빌드 트리거를 설정하면 코드 변경 시 자동으로 빌드가 시작됩니다.

Git 토큰이란?

Git 토큰(Personal Access Token)은 GitLab API에 접근하기 위한 인증 수단입니다. 비밀번호 대신 사용하며, 필요한 권한만 선택적으로 부여할 수 있어 더 안전합니다. KIWI의 전체 기능을 사용하려면 api, read_repository 권한이 필요합니다.

소스 탭에서 확인할 수 있는 정보​

서비스 상세 페이지의 소스 탭에서 Git 저장소 정보를 확인할 수 있습니다:

  • 저장소 연결 상태: GitLab 토큰 유효성 및 연결 상태
  • 브랜치 목록: 저장소의 모든 브랜치와 현재 선택된 브랜치
  • 최근 커밋: 최근 커밋 내역, 커밋 메시지, 작성자
  • 기여자: 저장소에 기여한 개발자 목록
  • 언어 비율: 저장소에서 사용된 프로그래밍 언어 비율
  • 태그 목록: 생성된 Git 태그 (릴리스 버전)
Git 인증 테스트

소스 탭에서 연결 테스트 버튼을 클릭하면 GitLab 토큰이 유효한지 사전에 확인할 수 있습니다. 토큰 만료나 권한 문제를 빌드 전에 발견할 수 있어 유용합니다.

빌드 관리​

코드를 컨테이너 이미지로 변환하는 빌드 기능을 제공합니다.

  • Kaniko 빌드: Dockerfile을 기반으로 컨테이너 이미지를 생성합니다.
  • 빌드 로그: 실시간으로 빌드 진행 상황을 확인할 수 있습니다.
  • 빌드 이력: 과거 빌드 기록을 조회하고 비교할 수 있습니다.
  • 빌드 설정: Dockerfile 경로, 빌드 인자(ARG), 이미지 태그 규칙을 구성합니다.
Kaniko란?

Kaniko는 Docker 데몬 없이 컨테이너 내에서 이미지를 빌드하는 도구입니다. Kubernetes 환경에서 권한 상승 없이 안전하게 이미지를 빌드할 수 있어, 보안이 중요한 환경에서 널리 사용됩니다.

배포 관리​

빌드된 이미지를 실제 운영 환경에 배포하는 기능입니다.

  • K8s 배포: Kubernetes 클러스터에 Deployment, Service 등 리소스를 배포합니다.
  • Docker 배포: Docker 호스트에 컨테이너를 직접 배포합니다.
  • 롤백: 문제 발생 시 이전 버전으로 즉시 되돌릴 수 있습니다.
  • 배포 이력: 배포 기록을 확인하고 버전 간 비교가 가능합니다.

보안 분석​

DevSecOps 파이프라인의 핵심인 보안 스캔 기능을 제공합니다. 개발 초기부터 보안 취약점을 발견하고 조치할 수 있습니다.

  • SAST: 소스 코드를 분석합니다. CodeQL, Semgrep 도구를 사용하며, 코드 작성 직후 잠재적 보안 결함을 탐지할 때 사용합니다.
  • SCA: 오픈소스 의존성을 분석합니다. Trivy 도구를 사용하며, 외부 라이브러리의 알려진 취약점을 확인할 때 사용합니다.
  • SBOM: 소프트웨어 구성 요소를 분석합니다. 사용 중인 모든 컴포넌트 목록을 생성할 때 사용합니다.
  • DAST: 실행 중인 애플리케이션을 분석합니다. ZAP 도구를 사용하며, 배포 후 실제 공격을 시뮬레이션할 때 사용합니다.
DevSecOps란?

DevSecOps는 개발(Dev), 보안(Sec), 운영(Ops)을 통합하여 소프트웨어 개발 수명 주기 전체에 걸쳐 보안을 내장하는 접근 방식입니다. "보안은 나중에"가 아닌 "보안은 처음부터"를 실현합니다.

UI 구성​

서비스 목록​

서비스 목록 페이지에서는 등록된 모든 서비스를 한눈에 확인할 수 있습니다.

  • 이름: 서비스를 식별하는 고유한 이름입니다.
  • Git 저장소 URL: 연결된 GitLab 저장소 주소입니다.
  • 기본 브랜치: 주로 사용하는 브랜치입니다 (main, develop 등).
  • 빌드/배포 상태: 현재 빌드 및 배포 상태입니다 (성공/실패/진행중).
  • 보안 취약점 요약: Critical/High/Medium/Low 취약점 개수를 표시합니다.
빠른 작업 버튼

각 서비스 행에는 빌드, 배포, 설정 버튼이 있어 목록에서 바로 주요 작업을 수행할 수 있습니다.

서비스 상세 탭​

서비스를 클릭하면 상세 페이지로 이동합니다. 각 탭에서 다양한 기능을 사용할 수 있습니다.

  • 소스: Git 저장소 연결 상태, 브랜치/태그를 관리합니다. SAST(정적 분석) 스캔 결과도 이 탭에서 확인합니다.
  • 빌드: 빌드 설정, 로그 확인, 빌드 이력을 관리합니다. SCA(오픈소스 취약점) 스캔 및 이미지 분석 결과도 이 탭에서 확인합니다.
  • 배포: 배포 환경 설정, 배포 실행, 배포 이력을 확인합니다.
  • 운영: 배포된 서비스를 관리합니다. 런타임 환경에 따라 사용 가능한 탭이 다릅니다.
    • K8s: 개요, 파드 목록, 배포 관리, 리소스 현황, 로그 조회, 명령 실행, 도메인 설정, 도메인 분석(DAST)
    • Docker/Podman: 개요, 컨테이너 목록, 배포 관리, 운영 관리, 로그 조회, 명령 실행, 도메인 설정, 도메인 분석(DAST)
  • 실행 이력: 파이프라인 실행 기록 전체를 조회합니다.

소스 탭 화면​

소스 탭

빌드 탭 화면​

빌드 탭

배포 탭 화면​

배포 탭

실행 이력 탭 화면​

실행 이력 탭

사용 방법​

서비스 등록하기​

새로운 서비스를 KIWI에 등록하는 과정입니다.

  1. 서비스 추가 버튼 클릭

    • 서비스 관리 페이지 상단의 서비스 추가 버튼을 클릭합니다.

  2. 기본 정보 입력

    • 서비스명: 팀 내에서 쉽게 식별할 수 있는 고유한 이름을 입력합니다. (예: user-api, payment-service)
    • 설명: 서비스의 역할을 간단히 설명합니다.
    • 저장소 URL: GitLab 저장소의 전체 URL을 입력합니다. (예: https://gitlab.example.com/team/project.git)

  3. GitLab 토큰 입력

    • GitLab에서 발급받은 Personal Access Token을 입력합니다.
    • 토큰에는 api, read_repository 권한이 필요합니다.

  4. 브랜치 선택

    • 토큰 인증이 완료되면 브랜치 목록이 표시됩니다.
    • 기본으로 사용할 브랜치를 선택합니다. (보통 main 또는 develop)

  5. 저장

    • 모든 정보를 확인하고 저장 버튼을 클릭합니다.
GitLab 토큰 발급 방법

GitLab → 프로필 아이콘 → Settings → Access Tokens에서 발급할 수 있습니다. 만료일을 설정하고 api, read_repository 스코프를 선택하세요.

빌드 설정하기​

서비스의 빌드 환경을 구성합니다. 한 번 설정하면 이후 빌드 시 자동으로 적용됩니다.

  1. 빌드 탭 이동

    • 서비스 상세 페이지에서 빌드 탭을 선택합니다.

  2. 빌드 설정 열기

    • 빌드 설정 버튼을 클릭합니다.

  3. Dockerfile 설정

    • Dockerfile 경로: 프로젝트 루트 기준 경로 (기본값: ./Dockerfile)
    • 빌드 경로: Docker 빌드 시 사용할 파일들이 있는 폴더입니다 (기본값: . = 프로젝트 루트)

  4. 빌드 인자 설정 (선택사항)

    • Dockerfile의 ARG로 전달할 값을 key=value 형식으로 입력합니다.
    • 예: NODE_ENV=production, API_URL=https://api.example.com

  5. 이미지 태그 규칙 설정

    • 빌드된 이미지에 붙일 태그 규칙을 정의합니다.
    • 사용 가능한 변수: ${BRANCH}, ${SHORT_SHA}, ${TAG}, ${BUILD_NUMBER}
    • 예: ${BRANCH}-${SHORT_SHA} → main-a1b2c3d

  6. 레지스트리 설정

    • 이미지를 저장할 레지스트리를 선택합니다. (Harbor 등)

  7. 저장

빌드 경로란?

빌드 경로는 Docker 빌드 시 Dockerfile에서 COPY, ADD 명령어로 접근 가능한 파일 범위를 결정합니다. 보통 프로젝트 루트(.)를 사용하지만, 모노레포 구조에서는 특정 하위 폴더를 지정할 수 있습니다.

빌드 실행하기​

설정이 완료된 서비스의 빌드를 실행합니다.

  1. 빌드 탭 이동

    • 서비스 상세 페이지에서 빌드 탭을 선택합니다.

  2. 빌드 시작 클릭

    • 빌드 시작 버튼을 클릭합니다.

  3. 빌드 옵션 선택

    • 브랜치/태그: 빌드할 소스 코드 버전을 선택합니다.
    • 캐시 사용 여부: 이전 빌드의 레이어를 재사용할지 선택합니다. 캐시를 사용하면 빌드 시간이 단축됩니다.

  4. 시작 버튼 클릭

    • 빌드가 시작되고 실시간 로그가 표시됩니다.

  5. 결과 확인

    • 빌드가 완료되면 성공/실패 여부와 생성된 이미지 태그를 확인할 수 있습니다.
빌드 시간 단축하기
  • 캐시 활용: 변경되지 않은 레이어는 캐시를 재사용합니다.
  • 멀티스테이지 빌드: Dockerfile에서 불필요한 빌드 도구를 최종 이미지에서 제외합니다.
  • 작은 베이스 이미지: alpine 기반 이미지를 사용하면 빌드와 배포가 빨라집니다.

배포하기​

빌드된 이미지를 런타임 환경에 배포합니다.

  1. 배포 탭 이동

    • 서비스 상세 페이지에서 배포 탭을 선택합니다.

  2. 배포 환경 선택

    • Kubernetes 또는 Docker 중 대상 환경을 선택합니다.

  3. 배포 버튼 클릭

    • 배포 버튼을 클릭하면 배포 설정 모달이 열립니다.

  4. 배포 옵션 설정

    • 네임스페이스 (K8s): 배포할 Kubernetes 네임스페이스
    • 레플리카: 실행할 Pod 개수 (가용성을 위해 2개 이상 권장)
    • 리소스: CPU/메모리 요청량과 제한
    • 환경 변수: 컨테이너에 주입할 환경 변수

  5. 배포 실행

    • 설정을 확인하고 배포 실행 버튼을 클릭합니다.
레플리카(Replica)란?

레플리카는 동일한 Pod의 복제본 수입니다. 여러 개를 실행하면 하나가 실패해도 다른 복제본이 요청을 처리하여 서비스 가용성이 향상됩니다. 또한 부하를 여러 Pod에 분산시킬 수 있습니다.

보안 스캔 실행하기​

개발 중인 서비스의 보안 취약점을 분석합니다.

보안 분석 화면

  1. 보안 탭 이동

    • 서비스 상세 페이지에서 보안 탭을 선택합니다.

  2. 스캔 유형 선택

    • 목적에 맞는 스캔 유형을 선택합니다:

    • SAST 스캔: 코드 커밋 전, PR 생성 시 권장

    • SCA 스캔: 의존성 업데이트 시, 빌드 전 권장

    • SBOM 생성: 릴리스 전, 감사 준비 시 권장

    • DAST 스캔: 스테이징 환경 배포 후 권장

  3. 스캔 실행

    • 선택한 스캔 유형의 실행 버튼을 클릭합니다.

  4. 결과 확인

    • 스캔이 완료되면 발견된 취약점 목록이 표시됩니다.
    • 각 취약점의 심각도, 위치, 해결 방법을 확인할 수 있습니다.
DAST 스캔 주의사항

DAST는 실제 애플리케이션을 대상으로 공격을 시뮬레이션합니다. 반드시 테스트 환경에서만 실행하세요. 프로덕션 환경에서 실행하면 서비스 장애나 데이터 손상이 발생할 수 있습니다.

취약점 관리하기​

발견된 취약점을 검토하고 조치합니다.

  1. 취약점 목록 확인

    • 보안 탭에서 발견된 취약점 목록을 확인합니다.
    • 심각도별로 필터링하여 우선순위를 정할 수 있습니다.

  2. 상세 정보 확인

    • 취약점을 클릭하면 상세 정보가 표시됩니다:
      • 취약점 설명 및 CVE 정보
      • 영향받는 코드 위치
      • 권장 해결 방법

  3. 조치 수행

    • 수정: 코드를 수정하고 다시 스캔하여 해결을 확인합니다.
    • 무시: 해당 환경에서 악용 불가능한 경우 VEX 기반으로 무시 처리합니다.
    • 계획: 즉시 수정이 어려운 경우 수정 계획을 등록합니다.
VEX(Vulnerability Exploitability eXchange)란?

VEX는 취약점의 실제 영향도를 기술하는 표준 형식입니다. 예를 들어, 특정 함수를 사용하지 않아 취약점이 악용 불가능한 경우 "not_affected"로 표시하여 불필요한 경고를 줄일 수 있습니다.

자동 CI 설정​

코드 변경 시 자동으로 빌드와 배포가 실행되도록 설정합니다. 수동 작업을 줄이고 일관된 품질을 유지할 수 있습니다.

자동 빌드 트리거​

  • 브랜치 푸시: 특정 브랜치에 코드가 푸시되면 자동 빌드됩니다. 예를 들어 develop 브랜치 푸시 시 개발 환경 빌드를 실행합니다.
  • 태그 생성: Git 태그가 생성되면 자동 빌드됩니다. 예를 들어 v1.0.0 태그 생성 시 릴리스 빌드를 실행합니다.
  • 특정 파일 변경: 지정된 파일/경로가 변경되면 빌드됩니다. 예를 들어 src/** 변경 시만 빌드하고 문서 변경은 제외합니다.
CI(Continuous Integration)란?

CI는 개발자들이 코드 변경을 자주 통합하고, 자동화된 빌드와 테스트를 수행하는 개발 관행입니다. 문제를 조기에 발견하고, "내 컴퓨터에서는 되는데"라는 상황을 방지합니다.

설정 방법​

  1. 설정 탭 이동

    • 서비스 상세 페이지에서 설정 탭을 선택합니다.

  2. 자동 CI 설정 열기

    • 자동 CI 설정 버튼을 클릭합니다.

  3. 트리거 조건 설정

    • 원하는 트리거 조건을 선택하고 세부 값을 입력합니다.
    • 여러 조건을 조합할 수 있습니다.

  4. 저장

    • 설정을 저장하면 즉시 적용됩니다.
실무 권장 설정
  • develop 브랜치: 푸시 시 자동 빌드 + 개발 환경 배포
  • main 브랜치: 푸시 시 자동 빌드 + 스테이징 환경 배포
  • v* 태그: 태그 생성 시 자동 빌드 + 프로덕션 환경 배포

Webhook 환경 관리​

자동 CI를 설정하면 GitLab에서 코드 변경 이벤트를 KIWI에 전달하기 위한 Webhook이 필요합니다. KIWI는 환경별로 Webhook URL을 자동으로 생성하고 관리합니다.

Webhook 환경이란?​

각 서비스는 4개의 기본 환경을 가집니다:

  • 로컬 (local): 개발자 PC에서 로컬 터널링(ngrok 등)을 통해 테스트할 때 사용합니다.
  • 개발 (dev): 개발 서버 환경에서 사용합니다.
  • 스테이징 (staging): 운영 전 테스트 환경에서 사용합니다.
  • 운영 (production): 실제 서비스 환경에서 사용합니다.

Webhook URL 구성​

Webhook URL은 기관 Base URL + 서비스 경로로 구성됩니다:

  • 기관 Base URL: 기관 관리자가 설정하는 공통 URL입니다. 같은 기관의 모든 서비스가 공유합니다.
  • Webhook URL: Base URL에 서비스별 고유 경로가 추가된 전체 URL입니다.
Base URL이 설정되지 않은 경우

기관 Base URL이 아직 설정되지 않았다면 "미설정" 상태로 표시됩니다. 기관 관리자에게 Webhook Base URL 설정을 요청하세요.

Webhook 설정 확인 방법​

  1. 자동 CI 설정 모달을 엽니다.
  2. 설정 탭 하단의 Webhook 환경 테이블에서 각 환경의 상태를 확인합니다.
  3. 특정 환경을 클릭하면 Webhook URL과 Secret Token을 확인할 수 있습니다.

Secret Token 관리​

  • 각 환경마다 고유한 Secret Token이 자동 생성됩니다.
  • GitLab이 Webhook 요청을 보낼 때 이 토큰으로 인증합니다.
  • 보안 상 토큰을 변경해야 하면 재생성 버튼을 클릭합니다.
Secret Token 재생성 시 주의

토큰을 재생성하면 기존 토큰은 즉시 무효화됩니다. GitLab의 Webhook 설정에서도 새 토큰으로 업데이트해야 합니다.

Webhook 상태​

  • 활성: Webhook이 정상적으로 동작하고 있으며, 최근 이벤트를 수신한 상태입니다.
  • 준비됨: 설정은 완료되었지만 아직 이벤트를 수신하지 않은 상태입니다.
  • 미설정: 기관 Base URL이 설정되지 않아 Webhook을 사용할 수 없는 상태입니다.
  • 비활성: 수동으로 비활성화된 상태입니다.

실행 이력​

서비스의 모든 파이프라인 실행 기록을 한눈에 확인할 수 있는 페이지입니다. 문제 진단이나 성능 분석에 유용합니다.

접근 방법​

서비스 상세 페이지에서 실행 이력 탭을 클릭합니다.

확인할 수 있는 정보​

  • 실행 번호: 각 파이프라인 실행의 고유 식별자입니다 (#1, #2, ...).
  • 실행 단계: 소스, SAST, 빌드, SCA, 배포, 운영, DAST 등 각 단계의 상태를 색상으로 표시합니다.
  • 이미지 태그: 빌드된 컨테이너 이미지의 태그 정보입니다.
  • 상태: 전체 파이프라인의 실행 상태입니다 (성공/진행중/실패/대기).
  • 트리거: 실행을 시작한 방식입니다 (수동/웹훅/예약).
  • 실행 시간: 파이프라인이 시작된 시각입니다.
  • 소요 시간: 전체 파이프라인 실행에 걸린 시간입니다.
  • 브랜치: 빌드/배포에 사용된 Git 브랜치입니다.
  • 실행자: 파이프라인을 실행한 사용자입니다.

상세 보기​

각 실행 기록을 펼치면 개별 단계의 타임라인을 확인할 수 있습니다. 각 단계별 시작 시간, 종료 시간, 소요 시간, 상태를 세부적으로 파악할 수 있어 병목 구간을 찾거나 문제를 진단하는 데 유용합니다.

실행 이력 활용법
  • 빌드 시간 추이 분석: 빌드 시간이 점점 늘어나는지 확인
  • 실패 패턴 파악: 특정 단계에서 자주 실패하는지 분석
  • 배포 이력 추적: 언제, 누가, 어떤 버전을 배포했는지 감사

운영 기능 (OperateModal)​

배포된 서비스의 실시간 운영 작업을 수행합니다. 문제 발생 시 빠르게 대응할 수 있는 도구들을 제공합니다.

로그 조회​

  1. 운영 모달 열기

    • 서비스 목록에서 운영 버튼을 클릭합니다.

  2. 로그 탭 선택

    • 모달에서 로그 탭을 선택합니다.

  3. 로그 옵션 설정

    • 컨테이너: 조회할 컨테이너 선택 (여러 개인 경우)
    • 라인 수: 표시할 로그 라인 수 (100, 500, 1000 등)
    • 실시간: 새 로그가 추가되면 자동으로 표시
    • 필터: 특정 키워드가 포함된 로그만 표시

  4. 로그 다운로드

    • 필요시 로그 파일을 다운로드할 수 있습니다.

컨테이너 재시작​

  1. 운영 모달에서 재시작 탭 선택

  2. 재시작 대상 선택

    • 재시작할 컨테이너 또는 Pod를 선택합니다.

  3. 재시작 실행

    • 재시작 버튼을 클릭하고 진행 상황을 모니터링합니다.
재시작 시 주의사항

재시작 시 일시적인 서비스 중단이 발생할 수 있습니다. 무중단 재시작이 필요한 경우 레플리카를 2개 이상 유지하고 롤링 업데이트를 사용하세요.

리소스 모니터링​

실시간으로 컨테이너의 리소스 사용량을 확인합니다. (Metrics Server 설치 필요)

  • CPU: CPU 사용률(%)을 표시합니다. 지속적으로 80% 이상이면 주의가 필요합니다.
  • 메모리: 메모리 사용량을 표시합니다. 제한에 근접하면 OOM 위험이 있습니다.
Metrics Server 필요

리소스 모니터링 기능을 사용하려면 Kubernetes 클러스터에 Metrics Server가 설치되어 있어야 합니다. [런타임 환경] 페이지의 모니터링 탭에서 설치할 수 있습니다.

Shell 접속 (K8s)​

컨테이너 내부에 직접 접속하여 명령어를 실행할 수 있습니다.

  1. Shell 탭 선택
  2. Pod 및 컨테이너 선택
  3. 터미널 접속
  4. 명령어 실행
보안 주의

Shell 접속은 모든 작업이 감사 로그에 기록됩니다. 프로덕션 환경에서는 꼭 필요한 경우에만 사용하고, 가능하면 로그 조회나 모니터링 도구를 먼저 활용하세요.

롤백 (Rollout)​

배포 후 문제가 발생하면 이전 버전으로 롤백할 수 있습니다. (K8s 전용)

  1. 운영 모달에서 롤백 탭 선택
  2. Rollout 이력 확인: 이전 배포 버전 목록이 표시됩니다.
  3. 롤백 대상 선택: 되돌리고 싶은 버전을 선택합니다.
  4. 롤백 실행: 선택한 버전으로 롤백이 진행됩니다.
롤백 시 참고

롤백은 Kubernetes의 Deployment 리비전을 기반으로 동작합니다. 롤백 후에도 이전 버전으로 다시 돌아갈 수 있습니다.

HPA 관리 (자동 스케일링)​

트래픽에 따라 Pod 수를 자동으로 조절하는 HPA(Horizontal Pod Autoscaler)를 관리합니다. (K8s 전용)

  1. 운영 모달에서 HPA 탭 선택
  2. HPA 생성:
    • 최소 레플리카: 최소 유지할 Pod 수
    • 최대 레플리카: 최대 확장할 Pod 수
    • CPU 임계값: 스케일아웃 기준 CPU 사용률 (예: 80%)
    • 메모리 임계값: 스케일아웃 기준 메모리 사용률 (선택)
  3. HPA 수정/삭제: 기존 HPA 설정을 변경하거나 삭제합니다.
Metrics Server 필요

HPA가 정상 동작하려면 Metrics Server가 설치되어 있어야 합니다. HPA 탭에서 Metrics Server 상태를 확인하고, 미설치 시 설치 버튼이 표시됩니다.

빌드/저장소 통계​

서비스의 개발 및 빌드 현황을 한눈에 파악할 수 있습니다.

빌드 통계​

  • 총 빌드 수: 전체 빌드 실행 횟수입니다. 개발 활동량을 파악하는 데 활용합니다.
  • 빌드 성공률: 성공한 빌드의 비율입니다. 90% 미만이면 개선이 필요합니다.
  • 평균 빌드 시간: 빌드에 소요되는 평균 시간입니다. 5분 이상이면 최적화를 검토하세요.
  • 최근 빌드 이력: 최근 빌드 목록입니다. 최신 변경 사항을 확인하는 데 활용합니다.

저장소 통계​

  • 총 커밋 수: 전체 커밋 횟수입니다.
  • 활성 브랜치 수: 현재 활성화된 브랜치 개수입니다.
  • 기여자 목록: 저장소에 기여한 개발자 목록입니다.
  • 최근 커밋 이력: 최근 커밋 목록입니다.

용어 설명​

처음 접하는 용어가 있다면 여기서 확인하세요.

  • 마이크로서비스: 독립적으로 배포 가능한 작은 서비스 단위로 애플리케이션을 구성하는 아키텍처입니다.
  • 컨테이너 이미지: 애플리케이션과 실행 환경을 패키징한 불변의 파일 시스템입니다.
  • 레지스트리: 컨테이너 이미지를 저장하고 배포하는 저장소입니다 (Harbor, Docker Hub 등).
  • Dockerfile: 컨테이너 이미지를 빌드하기 위한 명령어가 담긴 텍스트 파일입니다.
  • 태그(Tag): Git에서 특정 커밋에 붙이는 라벨입니다. 주로 릴리스 버전 표시에 사용됩니다.
  • 롤링 업데이트: 서비스 중단 없이 점진적으로 새 버전을 배포하는 방식입니다.

주의사항​

보안 관련 주의사항
  • DAST 스캔은 반드시 테스트 환경에서만 실행하세요. 프로덕션 환경에서 실행 시 서비스에 영향을 줄 수 있습니다.
  • 운영 작업 (로그 조회, Shell 접속 등)은 모두 감사 로그에 기록됩니다.
데이터 보관 정책
  • Git 토큰은 암호화되어 안전하게 저장됩니다.
  • 빌드 로그는 일정 기간 후 자동으로 삭제됩니다.
  • 중요한 로그는 미리 다운로드해 보관하세요.