최신이야기 | 브레인즈컴퍼니

주메뉴 바로가기 본문 바로가기

메인 페이지로 이동
블로그
최신이야기

블로그

최신이야기

기술이야기 서버 모니터링, 서버 관리, 서버 관리자 기술이야기 서버 모니터링, 서버 관리, 서버 관리자 서버는 기업의 IT 인프라를 구성하는 필수 요소입니다. 서버는 클라이언트에게 네트워크를 통해 정보나 서비스를 제공하는 컴퓨터 시스템으로, ▲파일 저장 및 공유 ▲웹사이트 및 애플리케이션 호스팅 ▲프린터 및 스캐너와 같은 네트워크 리소스 관리 ▲이메일 서비스 제공 등 다양한 기능을 수행합니다. 일반적으로 Microsoft Windows Server, Linux 또는 Unix와 같은 다양한 운영 체제를 실행하며, 가동 중지 시간을 최소화하면서 지속적으로 실행되도록 설계됐습니다. 오늘날과 같이 급변하는 비즈니스 환경에서의 서버 중단은 상당한 수익 손실과 평판 손상으로 이어질 수 있습니다. 이에 따라 기업은 서버 모니터링 및 관리를 위해 문제를 신속하게 식별하고 해결할 수 있는 강력한 서버 모니터링 시스템을 필수적으로 갖춰야합니다. 서버 모니터링과 서버 관리는 서버의 성능을 최적화하고 가용성을 보장하는데 중요한 관련이 있습니다. 이 블로그에서는 서버 모니터링과 서버 관리에 대해서 알아보고, 마지막으로 서버관리자가 어떤 일을 하는지 논의해 보고자 합니다. 먼저, 서버 모니터링과 서버 관리의 차이점은 다음과 같습니다. ------------------------------------------ 서버 모니터링이란? 서버 모니터링에는 도구와 소프트웨어를 사용해 서버의 성능, 상태 및 가용성을 추적하는 작업이 포함됩니다. 여기에는 CPU 사용량, 메모리 사용량, 디스크 공간, 네트워크 트래픽 및 애플리케이션 성능과 같은 모니터링 지표가 포함됩니다. 서버 모니터링의 목표는 문제가 발생하기 전에 잠재적인 문제를 감지하고, 문제가 발생할 때 문제 해결을 위한 데이터를 제공하는 것입니다. 서버 모니터링은 일반적으로 특수 도구를 사용해 자동화되는 프로세스입니다. 서버 관리란? 서버 관리는 서버가 최적으로 작동하도록 서버를 능동적으로 유지∙관리하고 구성하는 프로세스입니다. 여기에는 운영 체제, 소프트웨어 및 응용 프로그램의 설치 및 구성, 사용자 계정 및 사용 권한 관리, 백업 및 복원 수행, 서버 환경의 보안 및 규정 준수 보장 등의 작업이 포함됩니다. 서버 관리의 목표는 서버가 최고의 효율성으로 실행되고 안전하며, 사용자에게 필요한 서비스를 제공할 수 있도록 하는 것입니다. 요약하면, 서버 모니터링은 관찰 및 경고에 중점을 두는 반면, 서버 관리는 성능을 최적화하고 가용성을 보장하기 위해 서버를 능동적으로 구성하고 유지∙관리하는데 중점을 둡니다. 서버 모니터링은기업의 서버 관리자가 담당합니다. 서버 관리자는 기업의 비전과 전략을 달성하기 위해 서버를 비롯한 IT 시스템의 방향을 수립하는 IT 전문가입니다. 서버 관리자는 높은 수준의 가동 시간과 가용성을 보장하고 서버, 시스템 및 애플리케이션의 소프트웨어 및 하드웨어 기능과 같은 구성 요소를 평가합니다. 서버 관리자의 주요 업무는 조직의 규모와 특정 요구 사항에 따라 다를 수 있지만, 일반적으로 아래와 같습니다. 서버 관리자의 주요 업무 1. 서버 설치 및 구성 서버 설치 및 구성은 서버 관리자의 필수 업무로, 서버 하드웨어, 소프트웨어 및 네트워크 인프라에 대한 기술적 전문 지식, 세부 사항에 대한 주의 및 철저한 이해가 필요한 복잡한 작업입니다. 서버 관리자는 최적의 성능, 보안 및 안정성을 제공하는 동시에 서버가 조직의 요구사항을 충족하도록 올바르게 설치 및 구성됐는지 확인해야 합니다. 2. 서버 모니터링 및 유지보수 서버의 안정성과 성능을 유지하기 위한 핵심 업무입니다. 서버 관리자는 서버 하드웨어 및 소프트웨어를 유지∙관리해, 서버가 효율적이고 안전하게 실행되도록 하고 시스템 성능을 모니터링해 잠재적인 문제를 식별합니다. 3. 서버 보안 서버 보안 관리는 서버에 저장된 데이터의 기밀성, 무결성 및 가용성을 손상시킬 수 있는 잠재적인 보안 위협으로부터 서버를 보호하는 것과 관련된 업무입니다. 서버 관리자는 서버가 잠재적인 보안 위협으로부터 보호되고 서버가 관련 규정 및 표준을 준수하는지 확인하기 위해 적극적으로 노력합니다. 4. 서비스 제공 및 지원 서비스 제공 및 지원은 서버 서비스 및 응용 프로그램의 배포, 유지 및 지원 관리와 관련 있습니다. 이 업무는 서버 가용성을 유지하고 사용자 요구 사항을 충족하는데 중요하며, 서버 관리자는 사용자가 필요할 때 시기 적절하고 효과적인 지원을 받을 수 있도록 합니다. ------------------------------------------ 이처럼 서버 관리자는 서버가 원활하고 안전하며 효율적으로 실행되도록 하는데 중요한 역할을 합니다. 서버 관리자는 복잡한 기술적 지식을 보유해야 하고 빠른 대처 능력을 요구받으며, 보안 대응 및 최적화 작업 등에서 많은 어려움을 겪습니다. 더욱이 서버가 기능에 따라 세분화돼 일반 서버, 웹 어플리케이션 서버, 데이터베이스 서버 등으로 나뉘게 되면 각 기능별로 웹 애플리케이션 서버관리자나 데이터베이스 서버관리자 등으로 관리자의 역할이 세분화되기도 합니다. 서버의 수나 종류가 많아지고 구성이 복잡해지면 모니터링과 관리가 어려워집니다. 이를 돕기 위해 브레인즈컴퍼니의 Zenius(제니우스)와 같은 통합 서버 모니터링 및 관리 소프트웨어가 필요하게 됩니다. 2023.05.09
기술이야기 옵저버빌리티 향상을 위한 제니우스 대표 기능들 기술이야기 옵저버빌리티 향상을 위한 제니우스 대표 기능들 이번 블로그에서는 지난 블로그에서 다루었던 옵저버빌리티를 구현하기 위한 오픈 소스들은 어떤 것들이 있는지 간략히 알아보고, 제니우스(Zenius-EMS)에서는 옵저버빌리티 향상을 위해서 어떤 제품들을 제공하고 있는 지 살펴보겠습니다. 옵저버빌리티 구현을 위해 널리 활용되는 대표적인 오픈소스로는 아래 네 가지 정도를 들 수 있습니다. l Prometheus: 메트릭 수집 및 저장을 전문으로 하는 도구입니다. Prometheus는 강력한 쿼리 기능을 가지고 있으며, 다양한 기본 메트릭을 제공하며 데이터 시각화를 위해 Grafana와 같은 도구와 통합될 수 있습니다. 또한 이메일, Slack 및 PagerDuty와 같은 다양한 채널을 통해 알림을 보낼 수 있습니다. l OpenTelemetry: 에이전트 추가 없이 원격으로 클라우드 기반의 애플리케이션이나 인프라에서 측정한 데이터, 트레이스와 로그를 백엔드에 전달하는 기술을 제공합니다. Java, Go, Python 및 .NET을 포함한 다양한 언어를 지원하며 추적 및 로그에 대한 통합 API를 제공합니다. l Jaeger: 분산 서비스 환경에서는 한번의 요청으로 서로 다른 마이크로서비스가 실행될 수 있습니다. Jaeger는 서비스 간 트랜잭션을 추적하는 기능을 가지고 있는 오픈 소스 소프트웨어입니다. 이 기능을 통해 애플리케이션 속도를 저해하는 병목지점을 찾을 수 있으며 동작에 문제가 있는 애플리케이션에서 문제의 시작점을 찾는데 유용합니다. l Grafana: 시계열 메트릭 데이터를 시각화 하는데 필요한 도구를 제공하는 툴킷입니다. 다양한 DB를 연결하여 데이터를 가져와 시각화 할 수 있으며, 그래프를 그릴 수도 있습니다. 시각화한 그래프에서 특정 수치 이상일 때 알람 기능을 제공하며 다양한 플러그인으로 기능확장이 가능합니다. ------------------------------------------------- 오픈 기술을 이용해 Do It Yourself 방식으로 옵저버빌리티를 구현한다면 어떨까요? 직접 옵저버빌리티를 구현하기 위해서는 먼저 필요한 데이터를 수집해야 합니다. 필요한 데이터가 무엇인지, 어떤 방식으로 수집할지 결정하고 Prometheus, OpenTelemetry 같은 도구들을 이용해 설치 및 설정합니다. 이 단계는 시간이 가장 오래 걸리고, 나중에 잘못된 구성이나 누락이 발견되기도 합니다. 다음 단계는 데이터 저장입니다. 이 단계에서 주의할 점은 예전처럼 여러 소스에서 수집한 데이터를 단순하게 저장하는 것이 아니라, 전체적인 관점에서 어떤 이벤트가 일어나는지를 추적이 가능하도록 데이터 간의 연결과 선후 관계를 설정하는 것입니다. 어려운 점은 새로운 클라우드 기술을 도입하거나 기존의 인프라나 애플리케이션에서 변경이 발생할 때마다 데이터를 계속해서 정리를 해야 하는데, 이를 위해 플랫폼을 지속적으로 수정하고 구성을 추가해야 한다는 것입니다. 마지막으로 부정확한 경고들은 제거해야 합니다. 비즈니스 상황과 데이터는 계속해서 변화하기 때문에 이에 맞게 베이스 라인을 지속적으로 확인하고, 임계치를 조정해서 불필요한 알람이나 노이즈 데이터가 생기는 것을 방지해야 합니다. 결론적으로 직접 옵저버빌리티를 구현하는 것은 처음에는 쉬워 보여도 고급 인력과 많은 시간을 확보해야 하며, 별개로 시간이 지남에 따라서 효율성과 확장성이 떨어진다는 점을 감안하면 대부분의 기업은 감당하기 어렵다고 할 수 있습니다. 그렇다면, Zenius(제니우스) EMS는 옵저버빌리티를 어떻게 확보하고 있을까요? 옵저버빌리티 향상을 위한 가장 기본적인 기능은 토폴로지맵 또는 대시보드입니다. 다양한 인프라의 물리적 논리적 연결구조들을 한 눈에 시각적으로 파악할 수 있도록 해야 합니다. Zenius는 각 인프라별 상황을 한 눈에 볼 수 있는 오버뷰와 시스템 전체를 조망할 수 있는 토폴로지맵, 그리고 서비스 별 상황들을 감시할 수 있는 대시보드 등 크게 세가지의 뷰어(Viewer)를 제공합니다. 인프라의 구성 상황에 따라 다층적으로 구성되어 고객들이 인프라에서 일어나는 상황을 즉각 알 수 있도록 해 줍니다. 이러한 뷰어들은 기존 ‘모니터링’의 개념에서 ‘옵저버빌리티’ 개념으로 진화화면서 좀 더 다층적, 다양화되는 형태로 진화하고 있습니다. 또한, Zenius는 기존의 각 인프라별로 단순히 감시를 설정하는 방식이 아닌 다양한 인프라로부터의 로그와 메트릭 정보를 이용해 어떤 상관관계가 있는지 분석하는 ‘복합감시’라는 서비스가 기본적으로 탑재돼 있습니다. 복합감시를 대표 기능에는 ERMS(Event Relation Management System), 스냅샷 그리고 조치 자동화 등을 들 수 있습니다. l ERMS 기능은 로깅, 메트릭 정보와 장비의 상태를 이용해 새로운 감시 기준을 만들어, 의미있는 이벤트를 생성해 사용자에게 개별 장비 수준이 아닌 서비스 관점에서 정확한 상황 정 보를 제공합니다. l 스냅샷은 서비스 동작에서 이벤트가 발생했을 때, 당시 상황을 Rawdata 기반으로 그대로 재현하는 기능으로 SMS, DBMS, APM, NMS 등 모든 인프라를 동시에 볼 수 있습니다. l 조치 자동화는 ERMS를 자동운영시스템과 연동해, 특정 상황에서 자동으로 스크립트를 실행해 제어하는 기능입니다. 트레이싱 기능은 APM에서 제공하는 기능으로, WAS(Web Application Server)에 인입되고 처리되는 모든 트랜잭션들을 실시간으로 모니터링하고 지연되고 있는 상황을 토폴로지 뷰를 통해 가시적으로 분석할 수 있습니다. 사용자는 토폴로지 뷰를 통해 수행 중인 액티브 트랜잭션의 상세정보와 WAS와 연결된 DB, 네트워크 등 여러 노드들 간의 응답속도 및 시간들을 직관적으로 파악할 수 있습니다. 제니우스의 또 다른 옵저버빌리티는 인공지능 기반의 미래 예측 기능으로 미래 상황을 시각적으로 보여줍니다. 인프라 종류에 상관없이 인공신경망 등 다양한 알고리즘을 통해 미래 데이터를 생성하고, 장애발생 가능성을 빠르게 파악해 서비스 다운타임이 없도록 도와줍니다. 또한 이상 탐지 기능은 보안 침해 또는 기타 비정상적인 활동을 나타낼 수 있는 시스템 로그, 메트릭 및 네트워크 트래픽의 비정상적인 패턴을 식별할 수 있습니다. 이상탐지 알고리즘은 시간이 지남에 따라 시스템 동작의 변화에 적응하고 새로운 유형의 위협을 식별하는 방법을 학습할 수 있습니다. 이상과 같이 Zenius(제니우스) EMS는 최고의 옵저버빌리티를 제공하기 위해서 연구개발에 매진하고 있습니다. 옵저버빌리티 향상을 위한 다양한 기능/제품들은 고객의 시스템과 조직 상황에 맞게 선별적으로 사용될 수 있습니다. 2023.04.19
기술이야기 옵저버빌리티 확보를 위한 대표 정보 소스 3가지 기술이야기 옵저버빌리티 확보를 위한 대표 정보 소스 3가지 지난 블로그에서는 옵저버빌리티가 기존 모니터링과 어떻게 다른지 비교해봤습니다. 간략히 되짚어보면, 옵저버빌리티란 IT 환경이 다양해지고 기업의 서비스가 점점 복잡해짐에 따라 빠르게 문제를 찾아 해결하기 위해 서비스의 내부 상태와 동작을 이해하는 능력입니다. 옵저버빌리티는 IT 인프라별로 어떤 것이 문제라는 기준을 중심으로 모니터링하는 기존 방식에서 벗어나 모든 데이터를 실시간으로 수집하고 분석하여 IT시스템의 근본 원인에 접근하고, IT 운영 전문가의 노하우를 바탕으로 각 메트릭별 상관관계를 분석해 미래의 장애를 예측하는 인사이트를 강조합니다. 이번 블로그에서는 옵저버빌리티 확보에 가장 기본이자 중요한 정보 소스인 로깅, 메트릭, 트레이싱을 중심으로 알아보겠습니다. 이 세가지 소스는 시스템의 정확한 모니터링을 보장하고, 문제가 발생할 때 무엇이 잘못됐는지 근본원인을 추적하고, 전체 기능을 개선하는 데 도움이 되는 방법들입니다. 물론 이 세가지 방법만으로 옵저버빌리티가 확보됐다고 할 수는 없습니다. 옵저버빌리티 확보를 위해서는 로깅, 메트릭, 트레이싱을 통합해 이벤트의 상관관계를 분석하고, 데이터 시각화로 사용자에게 인사이트를 제공하는 능력이 추가돼야 합니다. l Logging : 시스템 내에서 발생하는 이벤트를 인지하고 향후 분석을 위해 저장하는 프로세스 l Metric : 응답 시간 또는 오류율과 같은 시스템 성능을 설명하는 숫자 값 l Tracing: 개발자가 병목 현상과 성능 문제를 식별할 수 있도록 서비스 호출 경로와 시간을 추적하는 프로세스 Logging 로깅은 로그를 남기는 것으로 로그를 수집하고, 저장하는 프로세스입니다. 로깅은 시스템 동작을 이해하고 문제를 진단하는 데 필요한 것으로, 향후 분석을 위해 저장하는 데이터인 만큼 올바른 세부 기준에 따라 의미가 있는 로그를 추출하는 것이 필요합니다. 그리고 예를 들어 웹 애플리케이션에 문제가 발생한 경우 로그를 남기는데, 메트릭을 통해서는 이 문제를 발견할 수 없으므로 그래서 로그는 중요합니다. 로그의 수집은 간단한 텍스트 파일에서 ELK(Elasticsearch, Logstash, Kibana)처럼 정교한 프레임워크에 이르기까지 다양한 형태를 취할 수 있습니다. 그래서 로그는 정형화하기 어렵고 그 양이 방대함으로 로그를 수집, 저장하고 분석할 때 다음과 같은 사항을 유의해야 합니다. l 과도한 로깅은 스토리지 비용을 증가시키고 로그의 검색 효율을 떨어뜨릴 수 있습니다. 따라서 어떤 데이터를 기록하고, 어떤 데이터를 기록하지 않을지 필터링하는 것이 중요합니다. l 장기간 보관할 필요가 없는 로그 효율적인 로깅 시스템을 위한 로그 보관 정책이 필요합니다. l 로그에는 인사이트를 제공할 수 있는 모든 컨텍스트 정보가 포함돼야 합니다. l 로깅은 다른 프로세스에 영향을 미치지 않도록 비동기 방식이어야 합니다. l 민감한 데이터가 로그에 남겨지지 않도록 마스킹을 해야 합니다. 그럼 로그 분석을 통해 알 수 있는 정보는 무엇이 있을까요? l 시스템의 상태: 로그에는 어떤 액션을 수행했는지, 어떤 데이터가 처리됐는지, 또 어떤 오류가 발생했는지 등의 정보가 담겨 있으므로 이러한 정보를 분석해 시스템의 상태를 파악할 수 있습니다. l 이슈 파악: 로그에는 어떤 오류가 발생했고, 어떤 요청이 실패했는지, 어떤 리소스가 부족한지 등의 정보가 담겨 있으므로 이러한 정보를 분석해 이슈를 파악하고, 빠르게 대응할 수 있습니다. l 보안성 강화: 로그에는 로그인 시도, 권한 부여, 보안 이벤트 발생 등의 정보가 담겨 있으므로 이러한 정보를 분석해 보안 이슈를 파악하고, 보안성을 강화할 수 있습니다. Metric 로그가 텍스트라면 메트릭은 단순한 수치입니다. 메트릭은 시스템의 상태를 측정하고, 모니터링하는데 사용되는 숫자 측정값입니다. 조금 더 자세히 설명하면, 메트릭은 측정 항목을 정의하고 해당 항목을 수치로 측정해, 그 결과를 보고하고 시스템이 정상적으로 동작하는지 확인하거나 장애를 빠르게 감지하기 위한 소스입니다. 메트릭의 측정 대상은 CPU 사용률, 메모리 사용률, 네트워크 트래픽 등 인프라의 성능이나 초당 수신하는 요청수, 응답에 걸린 시간, 사용자에게 오류를 다시 보낸 응답 수 등 애플리케이션의 상태와 관련돼 있습니다. 메트릭을 통한 수집 가능한 범위는 모니터링 도구 사용 여부에 따라 달라집니다. 일반적인 방식은 에이전트를 이용해 모니터링 대상으로부터 데이터를 수집하는 것으로, 수집할 메트릭을 정의하기가 유연하고 성능이나 안정성 등의 이슈에 대한 정보도 수집할 수 있는 장점이 있습니다. 에이전트를 사용하지 않고 운영 체제나 애플리케이션에서 제공하는 메트릭 수집 API를 사용하는 방식도 있는데, 수집하는 메트릭이 비교적 제한적입니다. 단순히 메트릭을 수집하는 것만으로 시스템을 모니터링하기에 충분하지 않습니다. 메트릭 데이터를 잘 활용하기 위해서는 분석 방법이 중요한데, 분석을 위해서는 몇가지 단계를 거쳐야 합니다. l 먼저, 데이터를 시각화하여 쉽게 이해할 수 있는 형태로 변환해야 합니다. 차트나 그래프, 대시보드 등을 통해 데이터의 패턴과 추세를 파악할 수 있으며, 시스템의 상태를 실시간으로 모니터링할 수 있습니다. l 다음으로, 데이터를 분석하여 시스템의 문제를 식별합니다. 예를 들어, 응답 시간이 지연되는 경우, 이를 발생시키는 주요 요인을 파악하여 시스템을 개선해야 합니다. 이를 위해 데이터를 세분화하여 요소를 파악하고, 문제를 식별하는 데 도움이 되는 경향성을 찾아야 합니다. l 마지막으로 이전 데이터와 비교하고 평가에 활용합니다. Metric 데이터를 분석할 때는 이전 데이터와 비교하여 시스템의 개선 정도를 파악하는 것이 중요하고, 이를 통해 시스템의 성능 개선 여부를 판단하고, 추가적인 개선 방안을 모색할 수 있습니다. Tracing 트레이싱은 분산 시스템에서의 서비스 호출 경로와 시간을 추적하는 기술입니다. 즉, 서비스 간의 호출 관계와 시간 정보를 추적해 각 서비스의 응답 시간을 파악하고, 이를 시각화해 병목 현상을 파악할 수 있습니다. 트레이싱은 크게 세 가지 구성 요소로 이뤄져 있습니다. l Trace: Trace는 서비스 간의 호출 경로와 시간 정보를 담고 있는 데이터 레코드입니다. Trace는 Span과 Trace ID, Parent Span ID 등의 정보를 가지며, 각 Span은 서비스 내부에서의 호출 관계와 시간 정보를 담고 있습니다. l Span: 분산 추적에서 가장 기본이 되는 논리 단위로 여러 개의 span 이 모여 trace를 완성한다는 개념입니다. 각각의 Span은 작업이름, 시작 시간과 종료 시간, key value 형태의 tags 와 Logs, span contexts를 가지고 있습니다. Span contexts는 분산추적을 하기위해 Trace 구간에서 종속된 Span을 구별할 수 있는 Span id와 Trace id를 말합니다. l Collector: Collector는 Trace 정보를 수집하고 저장하는 역할로, Trace 정보를 수집하기 위한 에이전트와 수집된 Trace 정보를 저장하고 분석하기 위한 Backend로 이뤄져 있습니다. (출처: [MSA] OpenTracing, 분산추적(Distributed Tracing) 과 Span context, KSR의 저장소) 이렇게 옵저버빌리티를 구현하기 위한 로깅, 매트릭, 트레이싱 등 세 가지의 중요한 정보 소스들을 다루기 위해서는 여러가지 기술들이 조합되어야 합니다. 다음 블로그에서는 그와 같은 정보 소스들을 다루어 옵저버빌리티를 구현하기 위해서 널리 사용되는 대표적인 오픈 소스들을 알아보고 Zenius-EMS에서는 옵저버빌리티 향상을 위해서 어떤 기능들을 제공하고 있는지 살펴보겠습니다. 2023.04.19
회사이야기 통합보안관리 솔루션 'Zenius SIEM' 국내 CC인증 획득 회사이야기 통합보안관리 솔루션 'Zenius SIEM' 국내 CC인증 획득 브레인즈컴퍼니(099390)는 차세대 통합보안관리 솔루션 'Zenius(제니우스) SIEM v2.0’이 국내 CC(Common Criteria)인증 EAL(Evaluation Assurance Level) 2등급을 획득했다고 19일 밝혔다. 국내 CC인증은 IT보안인증사무국이 IT 제품의 보안성, 안정성, 신뢰성을 검증하고 이를 인증하는 제도다. 'Zenius SIEM v2.0'은 이기종의 다양한 장비에서 발생되는 대용량 로그를 수집 및 분석하고, 개인정보보호, 개인정보처리스템의 접속기록관리 등 각종 컴플라이언스에서 로그를 안전하게 저장하고 관리하는 소프트웨어다. 제품은 162만 EPS(Event Per Second)의 인덱싱과 1TB에 0.02초 이내 검색 성능을 바탕으로 로그 수집 현황을 실시간으로 모니터링하고, 수집된 로그에 대한 위/변조 감시 기능을 제공한다. 특히 HTML5 기반 반응형 웹 환경 지원, 26종의 차트 및 컴포넌트 등 사용자 중심의 대시보드와 편리한 보고서 기능을 제공한다. 또, 'Zenius SIEM v2.0'은 SQL(Structured Query Language)에서 제공하는 함수를 이용해 이상 탐지가 가능하고, 서버 증설 시 서비스 중단없이 병렬확장 할 수 있다. 브레인즈컴퍼니는 2020년에 'Zenius SIEM v1.0'을 처음 개발한 후, 이번 업그레이드로 빅데이터 기반의 다양한 로그 수집 및 연관분석을 통해 관리 효율을 증대하고, 국내 네트워크 환경의 규제를 준수하기 위해 CC인증을 획득했다. 강선근 브레인즈컴퍼니 대표는 "향후 ChatGPT와 같은 LLM(Large Language Model)기술을 활용해 고객에게 보다 편리한 인터페이스를 제공하고, SaaS(Software as a Service, 서비스형 소프트웨어)버전을 준비하고 있다"고 말했다. 2023.04.19
회사이야기 ‘Zenius ITSM 3.0’ GS인증 1등급 획득! 회사이야기 ‘Zenius ITSM 3.0’ GS인증 1등급 획득! 브레인즈컴퍼니(099390)는 IT 서비스 관리 소프트웨어 ’Zenius(제니우스) ITSM v3.0’이 한국정보통신기술협회(TTA)로부터 GS인증 1등급을 획득했다고 13일 밝혔다. GS인증은 국산 소프트웨어의 품질을 증명하는 국가 인증제도다. 국제표준화기구(ISO)가 정한 표준을 기반으로 소프트웨어의 기능적합성, 성능효율성, 사용성, 신뢰성, 보안성 등 9가지 항목을 점검해 인증을 부여한다. Zenius ITSM(IT Service Management system)은 국제표준 ITIL(IT Infrastructure Library)을 기반으로 IT 서비스 부서의 업무 프로세스를 자동화 및 통합하는 소프트웨어로서, IT 문제 해결과 개선을 위한 체계적이고 모범적인 프로세스를 제공한다. Zenius ITSM v3.0은 로우코드 기반의 워크플로우 엔진과 구성정보데이터베이스(CMDB) 엔진을 탑재했으며, 워크플로우를 쉽게 생성하고 수정할 수 있는 프로세스 및 폼 디자이너를 포함하고 있다. 강선근 브레인즈컴퍼니 대표는 “브레인즈컴퍼니는 Zenius ITSM v3.0을 소규모 기업, 스타트업, 공공시장 등 다양한 시장에 공격적으로 확대해 나갈 예정이며, 적은 초기 비용으로 도입이 가능하도록 SaaS(Software as a Service, 서비스형 소프트웨어) 형태의 서비스 출시를 준비 중”이라고 밝혔다. 2023.04.13
기술이야기 클라우드 송환(Cloud Repatriation): 클라우드에서 다시 온프레미스로 기술이야기 클라우드 송환(Cloud Repatriation): 클라우드에서 다시 온프레미스로 다시 온프레미스로 복귀하려는 움직임 2022년 발표된 IDC 조사 결과에 의하면, 미국 기업의 71%가 향후 2년내에 ‘클라우드 송환’ 계획이 있다고 합니다. 실제 일부 애플리케이션을 클라우드에서 빼내 자체 데이터센터로 다시 가지고 오는 기업이 늘고 있습니다. 우리나라의 경우 ‘클라우드 전환’이 업계의 화두가 되고 있지만, 클라우드 전환을 10년 넘게 경험하고 있는 미국의 경우에는 이제 ‘클라우드 송환’이 또 다른 화두가 되고 있습니다. 클라우드 송환(Cloud repatriation)은 기업이 클라우드 환경에서 운영하던 애플리케이션, 데이터, 서비스 등을 온프레미스 환경으로 되돌리는 것을 말합니다. 이는 퍼블릭 클라우드가 비즈니스 민첩성을 향상시킬 수 있지만, 특정한 상황에서 온프레미스보다 퍼블릭 클라우드의 지출 비용이 더 크다는 사실을 기업이 깨달으면서 해당 애플리케이션 등을 온프레미스로 복귀시키려는 IT 전략입니다. 클라우드 송환 현상은 IT 비용과 성능을 비롯한 여러 측면에서 클라우드가 항상 최선의 해결책은 아니라는 인식을 바탕으로 확대되는 추세이며 이제 기업이 비용, 성능, 보안의 극대화를 위해 기존 환경과 새로운 환경 사이에서 자연스러운 워크로드 분산을 시작했다는 의미이기도 합니다. 미처 몰랐던 클라우드 서비스의 문제점 클라우드를 채택한 기업이 클라우드 송환을 선택하는 이유는 다음과 같은 문제가 있기 때문입니다. 첫째, 클라우드 비용 문제입니다. 2022년 클라우드 현황(Flexera 2022 State of the Cloud Report) 보고서에 따르면, 클라우드 비용의 30% 정도가 낭비되고 있습니다. 클라우드 서비스가 표면적으로 내세우는 클라우드의 가장 큰 장점이 비용 절감임에도 불구하고, 클라우드 전환 OPEX(operational expenses)가 기존 CAPEX(capital expenses) 대비 더 낫다고 단정하기 어렵습니다. 초기에는 클라우드의 비용이 저렴하게 느껴지지만, 가상머신(VM)과 컨테이너 인스턴스에서 처리하는 작업이 늘어날수록 비용도 더해지기 때문입니다. 워크로드가 증가하는 스타트업은 클라우드를 통해 유연성을 확보하는 것이 비용면에서 유리하겠지만, 예측 가능한 수준의 워크플로우를 갖고 있는 기업이라면 얘기가 달라집니다. 특히, 클라우드에서는 인터넷 대역폭 및 스토리지 요금 등 추가적인 비용이 발생할 수 있습니다. 둘째, 보안 문제입니다. 기업은 클라우드 제공자가 제공하는 기본적인 보안 기능 외에도 보안 문제에 대한 책임을 직접 지게 됩니다. 또, 기업은 자체 보안 정책을 준수해야 하며, 이를 클라우드 환경에 적용하는 것이 쉽지 않습니다. 특히 복잡한 멀티클라우드 환경에서는 견고하게 클라우드 보안 아키텍처를 구축하기 어렵고 외주 처리에 따라 많은 비용이 듭니다. 셋째, 성능 문제입니다. 클라우드에서는 다른 기업과 리소스를 공유하기 때문에 성능 문제가 발생할 수 있습니다. 또, 클라우드 환경에서 애플리케이션 및 데이터를 조작하는 데 필요한 대역폭이 충분하지 않을 경우 성능 문제가 발생할 수 있습니다. 따라서 기업은 성능 문제로 인해 클라우드 송환을 선택할 수 있습니다. 넷째, 제어 문제입니다. 클라우드에서는 기본적으로 클라우드 제공자가 인프라 관리와 보안을 담당합니다. 이는 기업이 클라우드 환경에서는 많은 경우 애플리케이션, 데이터, 서비스 등을 직접 제어할 수 없다는 것을 의미합니다. 따라서, 기업이 직접 컨트롤하지 못해서 문제가 발생한다고 느낄 때에는 클라우드 송환을 선택할 수 있습니다. 클라우드 송환의 이점 클라우드 송환(Cloud repatriation)은 기업에게 여러 가지 이점을 제공합니다. 첫째, 기업은 애플리케이션, 데이터, 서비스 등을 직접 관리할 수 있습니다. 이는 기업이 보안 및 규정 준수와 같은 중요한 문제를 직접 다룰 수 있도록 해주며, 제어력을 높임으로써 IT 부서가 잠재적 문제에 대비해 인사이트와 더 나은 계획을 수립할 수 있게 해줍니다. 클라우드에서는 기본적으로 클라우드 제공 업체가 인프라 관리와 보안을 담당하기 때문에, 이를 직접 제어할 수 없습니다. 클라우드 송환에 적합한 케이스는 정적인 기능을 제공하며 사용량이 많은 애플리케이션입니다. 비용이 고정되고 예측 가능한 애플리케이션은 온프레미스 환경에서 관리하는 편이 더 효과적입니다. 둘째, 기업은 클라우드 비용을 절감할 수 있습니다. 한때 퍼블릭 클라우드가 모든 문제의 해답이라고 생각했다가 퍼블릭 클라우드의 비용 특성과 이점이 기업의 상황과는 맞지 않는다는 사실을 깨닫게 됩니다. 2~3년에 걸쳐 추가되는 비용을 감안하면 퍼블릭 클라우드를 계속 사용할 만한 매력은 시간이 갈수록 희석됩니다. 기업은 반복적으로 발생하는 클라우드 운영 비용을 줄이거나 없애는 방법으로 많은 비용을 절감할 수 있습니다. 예를 들어, 어떤 기업의 데이터가 여러 사이트에서 발생하고 그 양이 많다면 클라우드 환경에서 데이터를 보관하고 이동시키는 데 많은 비용이 발생할 수 있습니다. 또 다른 예로 영상을 불러오고 저장하는 작업이 빈번한 영상 제작 기업의 경우, 클라우드 서버에서 병목현상이 발생할 수 있고 내부 LAN처럼 10Gbps 속도로 데이터를 옮기려면 그 비용이 저렴하지 않을 수 있습니다. 비용 외에도 데이터 이동에 많은 시간이 소모되며 이로 인해 데이터를 필터링해 최소한의 데이터만 저장해야 하는 불편함이 있습니다. 한편, 메모리와 디스크 리소스 비용이 계속 하락하면서 기업의 온프레미스 투자가 유리해지고 있습니다. 더불어 클래스 메모리 및 SDN(소프트웨어 정의 네트워크)과 같은 비용에 도움을 주는 솔루션을 활용하면, 한때 퍼블릭 클라우드의 큰 매력이었던 유연성, 확장성, 중복성의 간극이 상당부분 사라집니다. 셋째, 기업은 데이터 보호와 백업을 더욱 쉽게 할 수 있습니다. 클라우드 업체도 데이터 프라이버시에 대해 엄격하지만 온프레미스 환경에서 데이터를 저장하고 백업 받고 복구하는 것보다 더 안전할 수 없습니다. 물론 민감한 정보를 로컬 환경에 저장하는 것 역시 문제 제기가 있겠지만 최소한 고객 데이터가 사라졌을 때 무엇을 어떻게 해야 하는지 알 수 있습니다. 규정 준수 측면에서도 각 국마다 개인정보보호 규정이 달라 우발적인 규정 위반 가능성이 있습니다. 이러한 우려를 줄이는 방법은 애플리케이션을 특정 위치의 온프레미스 환경에서 실행하는 것입니다. 넷째, 대역폭 문제에서 자유로운 장점이 있습니다. 클라우드 환경에서 빅데이터 시스템을 활용하는 기업은 빅데이터 시스템에서 생성되는 데이터가 높은 대역폭을 요구하면서 자사 데이터 센터보다 훨씬 더 많은 운용 비용을 지불합니다. 컴퓨팅은 온디맨드이므로 탄력적인 클라우드가 유리할 수 있지만 스토리지는 매일 매초 비용이 계속 증가하고 있는 사실을 알아야 합니다. 클라우드냐 온프레미스냐 고려할 점 클라우드 송환은 비용면에서 매력적이지만 매우 도전적인 과제입니다. 클라우드 서비스 공급자는 일반적으로 클라우드에서 빠져나오기 상당히 어렵게 계약하고, 해체됐거나 아예 존재하지 않던 온프레미스 환경을 준비하기 위해 기업의 재무와 조직 운영에 큰 영향을 미치기 때문입니다. 게다가 애플리케이션을 온프레미스 데이터센터로 마이그레이션하는 경우 기업은 클라우드의 확장성, 유연성, 가용성, 탄력성을 유지하기 힘들고 자체 데이터센터가 클라우드에 비해 더 안전하다는 보장을 하기도 어렵습니다. 따라서 이런 경우에는 애플리케이션에서 실행 중인 환경에 대한 종속성이 있는 부분과 단순히 데이터를 관리하는 부분을 분리하면 혼란을 최소화할 수 있습니다. 처음부터 클라우드 환경을 고려해 서비스를 설계했다면, 워크로드를 다시 데이터센터로 되돌리기 위해서는 어느 정도의 재설계가 필요하며 빅데이터에 의존하는 기업은 상당한 마이그레이션 작업을 각오해야 합니다. 이처럼 클라우드 송환은 매우 어려운 과제입니다. 따라서 처음부터 워크로드를 퍼블릭 클라우드로 이전하는데 매우 신중한 입장을 취하는 것이 가장 중요합니다. 그래서 최근에는 기업들이 클라우드 환경을 고수하는 것보다는 필요한 경우 클라우드와 온프레미스 환경을 융합하는 하이브리드 클라우드 전략을 선택하는 경향이 있습니다. 모든 서비스를 클라우드로 전환하는 것이 아니라, 단기간에 트래픽이나 사용자가 급속히 늘어날 가능성이 있거나, 클라우드 서비스를 활용해 서비스를 빠르게 런칭해야 하는 경우로 한정하는 것이 필요합니다. 우리나라에서도 많은 기업들이 이미 클라우드가 갖고 있는 단점들을 경험하고 온프레미스로 전환하고 있습니다만, ‘클라우드 전환’이라는 큰 물결 아래 ‘클라우드 송환(Cloud Repatriation)’에 대한 논의는 제한적입니다. 우리나라의 클라우드 전환율이 세계시장과 비교해 볼 때 현저히 낮지만, 오히려 클라우드 환경의 문제를 이미 경험한 나라들의 교훈을 미리 받아들인다면 학습비용을 줄일 수 있을 것으로 기대합니다. Zenius-EMS는 고객들이 레거시 시스템에서부터 클라우드 네이티브 시스템에 이르기까지 다양한 관점의 서버모니터링을 할 수 있도록 지원합니다. 대규모 인프라가 존재하는 데이터센터 및 클라우드 환경에서 대용량 데이터 처리에 대한 높은 성능을 확인할 수 있습니다. 고유의 특허 기술을 통해 수천대의 장비에서 발생되는 데이터들을 안정적으로 수집하고 빠르게 처리할 수 있습니다. [출처] John Edwards, "클라우드의 온프레미스 송환이 타당한 5가지 경우", IT WORLD, 2019.04.16 Steven J. Vaughan-Nichols, "모두가 '클라우드' 외칠 때 '로컬 서버' 선택해야 하는 이유, IT WORLD, 2022.07.27 Andy Patrizio, "기업 71%, 2년 이내 클라우드에서 온프레미스로 복귀할 것", IT WORLD, 2022.06.29 Clint Boulton, "'전진 위한 후퇴'··· 클라우드서 온프레미스로 송환하는 기업들", CIO Korea, 2020.03.30 Brian Adler, "Cloud Computing Trends: Flexera 2022 State of the Cloud Report", flexera, 2022.03.21 2023.04.07
기술이야기 서버 모니터링 트렌드 살펴보기 기술이야기 서버 모니터링 트렌드 살펴보기 기업이나 조직의 IT 인프라 모니터링은 서버 모니터링에서 출발합니다. 통상적으로 서버 모니터링부터 네트워크, 데이터베이스, 웹애플리케이션, 전산설비 등으로 모니터링의 범위를 확장해 나가는 것이 일반적입니다. 서버는 초창기 메인 프레임부터 유닉스 서버, 리눅스 서버를 거쳐 최근의 가상화 서버에 이르기까지 물리적 및 논리적으로 그 성격이 변화해 왔습니다. 그에 따라 서버 모니터링의 관점도 많이 변모해 왔습니다. 기껏해야 1~2대 규모로 운영하던 메인 프레임의 시대와 수천, 수만대의 서버팜을 관리해야 하는 시대의 모니터링 개념은 달라야 합니다. 또, 가상화 시대를 맞아 물리적 서버 개념보다는 논리적 서버 개념이 중요해지고, 서버 1~2대의 장애 상황보다는 서버팜이 이루고 있는 서비스의 영속성이 중요해졌습니다. 이처럼 서버라는 인프라가 기술 발전에 따라 변모하고 있고, 그에 대응해 모니터링 콘셉트나 방법도 변화하고 있습니다. 이번 블로그에서는 서버 관련 새로운 인프라 개념 및 기술들이 대두되면서 변화하는 서버 모니터링의 새로운 트렌드에 관해 논의해 보고자 합니다. 1. 클라우드 네이티브 모니터링 더 많은 기업이나 조직이 전통적인 레거시 시스템에서 클라우드로 이동함에 따라 클라우드 모니터링의 필요성이 급격히 증가했습니다. 클라우드 네이티브 모니터링 도구는 Amazon Web Services(AWS), Microsoft Azure, Google Cloud Platform(GCP)과 같은 클라우드 환경에서 애플리케이션과 클라우드 인프라를 모니터링하도록 설계됐습니다. 또, 클라우드 인프라의 성능, 가용성 및 보안에 대한 실시간 인사이트를 제공해, IT운영부서가 문제를 신속하게 발견하고 해결할 수 있도록 지원합니다. 일반적인 클라우드 모니터링은 메트릭과 로그를 사용해 클라우드 인프라 및 애플리케이션 성능을 하나의 통합된 화면에 제공합니다. 또한 통합 IT 환경 측면에서는 컨테이너 오케스트레이션 플랫폼 및 서버리스 컴퓨팅과 같은 다른 클라우드 환경과 통합해 모니터링할 수도 있습니다. 클라우드 기반 모니터링의 최신 추세는 하이브리드 모니터링입니다. 조직은 하이브리드 모니터링을 통해 클라우드와 온프레미스에서 각각 실행 중인 서버 및 애플리케이션 모두를 단일 플랫폼에서 모니터링할 수 있습니다. 2. 인공지능과 머신러닝 서버 모니터링의 또 다른 트렌드는 인공 지능(AI)과 머신 러닝(ML)을 사용해 모니터링 과정을 자동화하는 것입니다. AI 및 ML 알고리즘은 모니터링 과정에서 생성된 방대한 양의 데이터를 분석하고 패턴을 식별해 이상 징후를 감지할 수 있습니다. 이는 실시간으로 수행될 수 있으므로 운영관리자는 발생하는 모든 문제에 신속하게 대응할 수 있습니다. ML 알고리즘은 과거 데이터를 분석해 트래픽이 가장 많은 시기나 잠재적 장애와 같은 미래 추세를 예측할 수 있습니다. 이를 위해 서버의 성능과 관련된 대규모 데이터 세트에서 ML 알고리즘을 교육해야 합니다. 이 데이터는 서버 로그, 시스템 메트릭, 애플리케이션 로그 및 기타 관련 정보가 해당됩니다. 다음으로 알고리즘을 학습해 다양한 메트릭 간의 패턴과 상관 관계를 식별하고 이상 징후와 잠재적 문제를 감지합니다. 머신 러닝 모델이 훈련되면 서버를 실시간으로 모니터링하도록 배포할 수 있으며, 모델은 지속적으로 서버 메트릭을 분석하고 이를 학습한 패턴과 비교합니다. 편차나 이상을 감지하면 문제를 해결하기 위해 경고 또는 자동화된 작업을 트리거할 수 있습니다. 예를 들어, 트래픽이 갑자기 증가하는 경우 리소스를 자동으로 Scaling 하거나 다운 타임을 방지하기 위해 다른 조치를 취할 수 있습니다. 전반적으로 인공 지능과 머신 러닝을 사용해 서버 모니터링을 자동화하면, 문제해결에 시간을 절약하고 인적 오류의 위험을 줄일 수 있습니다. 또, 심각한 문제로 번지기 전에 잠재적 문제를 식별해 서버 인프라의 전반적인 안정성과 가용성을 향상할 수 있습니다. 3. 컨테이너 모니터링 컨테이너가 애플리케이션 배포에 점점 더 많이 사용되면서, 컨테이너 모니터링은 서버 모니터링의 중요한 측면이 됐습니다. 컨테이너란 애플리케이션을 모든 인프라에서 실행하는데 필요한 모든 파일 및 라이브러리와 함께 번들로 제공하는 소프트웨어 배포 도구입니다. 컨테이너를 사용하면 모든 유형의 디바이스 및 운영 체제에서 실행되는 단일 소프트웨어 패키지를 만들 수 있습니다. 뿐만 아니라, 단일 시스템에서 한 컨테이너는 다른 컨테이너의 작업을 방해하지 않으므로 확장성이 뛰어나고, 결함이 있는 서비스가 다른 서비스에 영향을 주지 않아 애플리케이션의 복원력과 가용성이 향상되는 장점이 있습니다. 컨테이너 모니터링은 CPU 및 메모리 사용량과 같은 컨테이너 리소스 사용률에 대한 실시간 메트릭을 제공할 수 있습니다. 또, 애플리케이션이 의도한 대로 실행되고 있는지 확인하기 위해 Kubernetes(쿠버네티스)와 같은 컨테이너 오케스트레이션 플랫폼을 모니터링하고, 컨테이너 및 기본 인프라에 대한 실시간 가시성을 제공합니다. 4. 서버리스 모니터링 서버리스 컴퓨팅은 사용량에 따라 백엔드 서비스를 제공하는 방법으로, 개발자가 서버를 관리할 필요없이 애플리케이션을 빌드하고 실행하는 것을 가능하게 합니다. 서버리스 컴퓨팅은 벤더 종속성(Vendor lock-in), 콜드 스타드와 DB백업이나 영상 인코딩 등 단시간에 많은 컴퓨팅 용량이 필요한 경우, 효율적이지 않음에도 불구하고 최근 몇 년 동안 주목을 받아오며 서버리스 모니터링이 서버 모니터링의 새로운 트렌드가 됐습니다. 서버리스 모니터링은 CPU, 메모리, 디스크 사용량 등 리소스 사용률, 애플리케이션 성능, 호출 시간 및 오류율과 같은 기능 성능에 대한 실시간 인사이트를 제공합니다. 서버리스 모니터링은 데이터베이스 쿼리 성능과 같은 서버리스 함수의 종속성에 대한 인사이트도 제공합니다. 5. 마이크로서비스 모니터링 마이크로서비스는 하나의 큰 애플리케이션을 여러 개의 작은 기능으로 쪼개어 변경과 조합이 가능하도록 만든 아키텍처로, 각 서비스를 다른 서비스와 독립적으로 개발, 배포 및 확장할 수 있는 장점이 있습니다. 하지만 마이크로서비스는 일반적으로 분산된 환경에 배포되므로 성능을 추적하고 문제를 찾아내기가 어렵고, 독립적으로 설계됐으므로 호환성에 어떤 문제가 있는지 감지할 필요가 있어 마이크로서비스 모니터링이 필요합니다. 마이크로서비스 모니터링은 개별 마이크로서비스 및 전체 애플리케이션의 성능과 상태를 추적하는 프로세스로 로그, 메트릭 및 트레이스와 같은 다양한 소스에서 데이터를 수집하고 분석해 문제를 식별하고 성능을 최적화하는 작업입니다. 마이크로서비스 모니터링은 각 마이크로서비스 별 가용성, 응답 시간, 가동 시간, 지연 시간, 오류율을 포함합니다. CPU, 메모리, 디스크 사용량과 같은 리소스 사용률을 추적해 잠재적인 성능 병목 현상이나 리소스 제약을 식별할 수 있고, 마이크로서비스 간의 데이터 흐름을 추적하고 서비스 간의 종속성 추적을 모니터링합니다. 또, 마이크로서비스 모니터링은 애플리케이션 전체의 전반적인 상태와 성능뿐만 아니라 타사 서비스 및 API의 성능과 상태도 모니터링할 수 있습니다. ----------------------------------- 브레인즈컴퍼니는 꾸준히 연구개발에 매진해 상기와 같은 새로운 트렌드를 반영한 Zenius-EMS를 개발, 출시했습니다. Zenius-EMS는 고객들이 레거시 시스템에서부터 클라우드 네이티브 시스템에 이르기까지 다양한 관점의 서버모니터링을 할 수 있도록 지원합니다. *이미지 출처: Unsplash, flaction 2023.03.29
기술이야기 Monitoring vs Observability, 모니터링과 옵저버빌리티 이해하기 기술이야기 Monitoring vs Observability, 모니터링과 옵저버빌리티 이해하기 옵저버빌리티는 "무슨 일이 일어났는가?", "왜 그런 일이 일어났는가?"와 같은 질문에 답하는 것을 목표로 합니다. 옵저버빌리티는 IT시스템 전체적인 관점에서 문제를 신속하게 식별하고 근본 원인을 분석할 수 있습니다. 최근 IT 인프라의 종류가 다양해지고, 수가 기하급수적으로 많아지고, 복잡도가 급격히 증가함에 따라 IT 인프라의 가용성을 보장하기 위해서 전통적으로 행해지던 모니터링의 범주를 넘어서는 옵저버빌리티라는 개념이 등장했습니다. 모니터링과 옵저버빌리티라는 두 용어들은 때로는 비슷한 개념으로 서로 바꿔서 사용되기도 하지만, 시스템 관리에 대한 다른 접근 방식을 나타냅니다. 이번 블로그에서는 모니터링과 옵저빌리티의 차이점을 알아보겠습니다. Monitoring이란? 모니터링은 IT 시스템에서 CPU 사용량, 메모리 사용량, 네트워크 트래픽과 같은 데이터를 수집하고 분석해 성능과 동작을 파악하는 것입니다. 모니터링의 목표는 시스템에 문제가 있는 것으로 추정되는 이상한 동작이나 조건을 감지하고 경고하는 것입니다. 모니터링은 종종 문제를 나타낼 수 있는 특정 메트릭이나 이벤트에 대한 알람 설정을 포함합니다. 이 접근 방식은 일반적으로 예측 가능한 개별 시스템에 사용합니다. 전통적인 모니터링 방법은 일정한 간격으로 수집되는 사전 정의된 메트릭이나 로그에 의존합니다. 예를 들어, 서버의 CPU 사용량을 1분마다 확인하고 사용량이 특정 임계값을 초과하면 알람을 보낼 수 있습니다. 이러한 방식은 특정 유형의 문제를 감지하는 데 효과적이지만, IT 시스템 동작을 전체적으로 파악하거나 근본 원인 분석에 대한 심층적인 인사이트는 제한적일 수 있습니다. Observability란? 옵저버빌리티는 IT 시스템 관리에 대한 새로운 접근 방식으로, 시스템의 내부 동작을 이해하는 것에 중점을 둡니다. 옵저버빌리티의 목표는 시스템의 동작을 깊이 이해하고 발생 가능한 모든 문제의 근본 원인을 파악하는 것입니다. 옵저버빌리티는 메트릭, 추적, 로그 등을 실시간으로 수집하고 분석하는 것을 포함합니다. 참고로 메트릭은 CPU 사용량, 메모리 사용량, 네트워크 트래픽과 같은 시스템 성능과 관련된 정량적 정보를, 추적은 요청의 호출 순서 및 응답 시간과 같은 시스템 동작에 대한 정보를, 로그는 사용자 작업 및 오류를 포함해 시스템 활동을 제공합니다. 옵저버빌리티가 필요한 이유 옵저버빌리티는 복잡하고 동적인 시스템에서는 문제를 빠르게 찾고 해결하기 위해 시스템의 동작과 성능을 측정하고 분석할 필요가 있습니다. 옵저버빌리티를 통해 다음과 같은 이점을 얻을 수 있습니다. 옵저버빌리티가 필요한 이유 1. 문제 해결 속도 향상: 옵저버빌리티를 사용하면 복잡한 시스템에서 발생하는 문제를 더욱 빠르게 파악할 수 있습니다. 이를 통해 시스템 장애나 성능 저하와 같은 문제를 빠르게 해결할 수 있습니다. 2. 전체 시스템 이해도 증가: 옵저버빌리티를 사용하면 전체 시스템의 내부 동작을 쉽게 이해할 수 있습니다. 이는 문제를 예방하거나 빠르게 대처할 수 있도록 도와줍니다. 3. 대규모 시스템 관리 가능: 대규모 분산 시스템에서는 옵저버빌리티가 필수적입니다. 이를 통해 수많은 서버, 네트워크, 애플리케이션 등에서 발생하는 다양한 데이터를 수집하고 분석할 수 있습니다. 4. 문제 예방 및 최적화: 옵저버빌리티를 사용하면 시스템의 성능을 지속적으로 모니터링하고 문제를 예방할 수 있습니다. 또한 시스템의 최적화를 위해 데이터를 분석하고 개선할 수 있습니다. 따라서, 옵저버빌리티는 복잡한, 여러 개의 세분화된 시스템으로 구성된 전체 시스템에서 필수적인 도구로, 시스템의 성능 개선과 장애 대응 등 다양한 측면에서 가치를 제공합니다. Monitoring vs Observability 모니터링과 달리, 옵저버빌리티는 사전에 정의된 메트릭과 알람에 의존하는 대신, 시스템 동작의 더욱 전체적인 관점을 제공합니다. 옵저버빌리티는 여러 소스에서 수집한 데이터를 같이 분석함으로써 쉽게 찾을 수 없는 어떤 패턴과 상관관계를 발견하는 데 도움을 줄 수 있습니다. 이 접근 방식은 예측할 수 없는 동작을 가진 복잡한 시스템에서 특히 유용합니다. 모니터링과 옵저버빌리티의 또 다른 중요한 차이점은 사람의 개입 수준입니다. 모니터링은 특정 이벤트 또는 조건을 감지하고 해당 이벤트 또는 조건이 발생할 때 경고를 트리거하도록 설계되므로 모니터링을 설정하고 구성하는데 사람의 개입이 필요할 수 있지만 일단 도구가 셋업되면 사람의 개입 없이 자동으로 작동하는 편입니다. 반면에, 옵저버빌리티는 데이터를 해석하고 결정을 내리고 조치를 취하는데 IT 운영자의 전문 지식을 사용해 프로세스에 관여합니다. 이러한 접근 방식은 시간이 더 많이 소요될 수 있지만, 문제의 근본 원인에 대한 더 많은 인사이트를 제공할 수도 있습니다. 올바른 어프로치 선택하기 모니터링과 옵저버빌리티는 각각 장단점이 있으며, 시스템의 특정 요구사항에 따라 어떤 접근 방식을 선택할지 달라져야 합니다. 비교적 상황 파악이 어렵지 않은 간단한 시스템의 경우, 전통적인 모니터링 도구로 충분할 수 있습니다. 그러나 복잡하고 시스템이 분산된 경우, 시스템 동작을 완전히 이해하기 위해 옵저버빌리티가 필요할 수 있습니다. 결국, 효과적인 시스템 관리의 핵심은 문제를 빠르게 감지하고 해결하기 위한 적절한 도구와 프로세스를 갖추는 것입니다. 모니터링 또는 옵저버빌리티를 선택하든, 시스템과 조직의 요구에 부합하는지 정기적으로 검토하고 개선하는 것이 중요합니다. 적절한 도구와 프로세스에 투자함으로써, 시스템의 신뢰성과 성능을 개선하고 비용이 많이 드는 다운타임과 서비스 중단을 피할 수 있습니다. Zenius EMS 브레인즈컴퍼니는 20년 이상 축적된 노하우를 바탕으로 레거시 환경은 물론 최근 더욱 복잡해지고 있는 클라우드 네이티브 시스템까지 모니터링과 옵저버빌리티 모두를 제공함으로써 고객이 원하는 방식으로 사용이 가능합니다. Zenius EMS는 SMS, NMS, APM 등 각 인프라별 모니터링을 통합해 시스템을 더욱 안정성 있게 관리하고 자동화된 장애대응 환경을 제공하며 객관적인 데이터 기반으로 리포팅이 가능한 지능형 IT 성능 모니터링입니다. 또한 쿠버네티스, 오픈 스택을 지원하는 클라우드 환경을 모니터링합니다. 국내 공공분야 관제 SW 1위, 제니우스의 상관관계 분석, 인공지능을 활용한 성능예측 등 옵저버빌리티 기술을 통해 다양한 시스템 레이어에서 성능, 장애, 구성에 대한 인사이트를 얻으시기 바랍니다. 2023.03.28
사람이야기 [부산SW마이스터고 현장 실습] 기본기, 그리고 함께의 가치를 깨달았던 시간 사람이야기 [부산SW마이스터고 현장 실습] 기본기, 그리고 함께의 가치를 깨달았던 시간 지난 1월, 앳된 얼굴의 여고생 한 명이 브레인즈컴퍼니에 모습을 드러냈습니다. 저 먼 곳 부산에서 상경한 미진님은 중학생 시절부터 개발자의 꿈을 꾸다, 소프트웨어마이스터고로 진학을 했다는데요. 올해 고3이 되는 미진님은 학기 시작 전, 방학기간 동안 잠시 브레인즈컴퍼니에서 현장실습할 기회를 얻었습니다. 미진님은 짧은 기간이었지만 새로운 경험에 많은 것을 얻어갈 수 있었고, 브레인즈컴퍼니에서 다시 일할 기회가 있길 바란다는 말을 남기며 다시 부산으로 돌아갔습니다. 미진님이 브레인즈에서 어떤 생활을 했을지 함께 보러 가실까요? -------------------------------- Q. 안녕하세요, 미진님. 자기소개 부탁드릴게요. 안녕하세요. 저는 부산소프트웨어마이스터고에 재학중인 심미진입니다. 체험형 현장실습으로 브레인즈컴퍼니 ITSM팀에서 약 5주간 인턴생활을 했습니다. 시작한 게 엊그제 같은데 벌써 5주나 지나갔네요.ㅎㅎ Q. 실습 기간 동안 ITSM팀에서 어떤 교육을, 어떻게 받았나요? 총 5주동안 교육이 진행됐는데요. 첫 주에는 ITSM에 대한 리뷰를 했습니다. 사용자가 쉽게 따라올 수 있도록 가이드된 매뉴얼을 보고 다른 부분이나 결함, 개선점에 대해 찾았습니다. 개발하고 있는 제품에 대한 개발 환경 구축도 해보고, 어떤 기능이 있는지 하나하나 확인하면서 리뷰를 진행했습니다. 그 결과 결함 4개, 개선의견 5개를 찾았습니다. 2주차에는 제가 찾은 결함과 개선의견을 일감으로 정하고, 첫 PR(Pull Request)을 날린 경험을 했습니다. 사내 시스템 중 ‘레드 마인’이라는 것이 있는데, 그곳에서 해야 할 일을 기록하고 공유하고 있었습니다. 보통 해야 할 일을 ‘일감’이라고 부르고 있습니다. 제 사수가 어떻게 사용하는지에 대해 알려주시고 이를 따라할 수 있도록 도와주셨습니다. 사실 학교에서는 작은 프로젝트만 진행해왔고, 자주 모여서 이야기했기 때문에 이렇게까지 꼼꼼하게 기록한 적 없었는데 이번 기회를 통해서 문서 작성 그리고 공유에 대한 중요성을 배웠습니다. 또 처음 일감을 받아 PR을 날렸을 때 코딩 컨벤션의 중요성을 알게 됐습니다. 3주차에는 팀장님께서 저에게 주신 일감을 하나씩 처리하는 일을 시작했는데요. 지난 주에 날렸던 PR에 대한 피드백을 받고 이에 맞게 수정도 했습니다. 이 과정에서 학교에서와 달리 리뷰와 의견에 대해 빠른 피드백을 주셔서 좋았던 것 같아요. 처음 맡은 일감은 HTML을 이용해 구조를 수정하는 일이었어요. 내용적인 부분에 있어서는 학교에서 배운 부분이라 어려움이 없었어요. 4주차와 5주차에는 해결하는 시간이 조금 더 걸리는 일감을 받았어요. 이 과정에서 제일 중요하게 배운 것은 ‘깔끔한 코드’를 짜야한다는 것과 작은 결함일 줄 알았지만, 사실은 더 크거나 혹은 더 작은 결함이 발생할 수 있다는 것이었습니다. 서비스는 만드는 것보다 유지보수를 하는게 더 중요하기 때문에 깔끔한 코드를 짜는 것이 중요한데요. 깔끔한 코드에 대한 정의는 사람마다 조금씩 다를 수 있겠지만, 제 생각엔 유지 보수가 쉽게 가능하고 의도가 명확히 드러나는 코드라고 생각합니다. 또 제가 생각했던 것 보다 결함이 큰 경우도 있었는데, 저도 그동안 개발하면서 놓친 부분은 없는지 되돌아보는 계기가 됐습니다. 5주동안 개발적인 부분뿐만 아니라 다른 사람들과 '함께’ 코딩하는게 어떤 것인지 명확한 경험을 한 것 같아 좋았습니다. Q. 개발자로서 사용해 본 ITSM을 평가한다면? 제가 사용해 본 ITSM은 장단점이 확실히 구분되는 제품이었습니다. 먼저 장점은 편리한 기능이 다 갖춰져 있다는 것인데요. 문서 관리부터 자산 관리, 시스템 관리, 공지 등등 회사에게 필요한 기능이 다 갖춰져 있습니다. 또 회사에서 사용하는 문서들을 사용자(고객)가 원하는 대로 커스텀이 가능하다는 것인데요. 회사마다 절차도 다르고 사용해야 할 문서 형식도 다르게 나타나기 때문에 ‘폼 디자인’ 기능을 통해 구현되고 있었습니다. 그것뿐만 아니라 개인이 처리해야 할 문서에 대한 현황판을 대시보드로 한눈에 볼 수 있어 좋았던 것 같아요. 하지만 조금 아쉬운 점이 있다고 한다면 기능이 많은 만큼 고려해야 할 부분도 많이 생긴다는 것입니다. 아무래도 UI가 비슷하다면 같은 코드를 재사용하는 경우가 있습니다. 그런데 똑같이 적용을 했음에도 불구하고 생각치 못한 결함이 발생할 수 있다는 것인데요. 기능이 많으면 많을수록 재사용하는 코드는 늘어나기 때문에 결함을 수정하면서도 고려해야 할 부분이 많다는게 신경 쓰였습니다. 그리고 작은 프로젝트가 아니기 때문에 어쩔 수 없는 부분이라는 걸 알지만, 수정하는 것이 쉽지 않았다는 점이 조금 아쉬웠어요. Q. 브레인즈컴퍼니의 근무 환경은 어땠나요? 브레인즈컴퍼니에서의 근무 환경은 만족할 정도였습니다. 8층 라운지에는 매일 아침마다 간편한 식사가 준비돼 있었는데 덕분에 아침에 든든하게 있을 수 있었어요. 회사를 다닌다는 것 자체가 처음이라 긴장도 많이 하고, 실수할까봐 걱정도 많이 했는데 팀원분들께서 이해하기 쉽게 또 꼼꼼하게, 잘 알려주셨던 부분이 가장 좋았던 것 같아요. Q. 브레인즈컴퍼니에서 근무하며 가장 좋았던 점은 무엇인가요? 다른 사람이 짠 코드에 대해 결함을 찾고 이를 해결하는 과정이 가장 좋았습니다. 지금까지 제가 직접 코드를 짜고 고치고 하는 경우는 많았지만, 다른 사람이 미리 짜 놓은 코드를 고쳐본 적은 잘 없었어요. 처음에는 조금 이해하기 어려운 부분도 있었지만 그 과정에서 제가 스스로 공부하면서 해결해 나가는 과정이 좋았습니다. Q. 첫 직장생활을 해보며, 가장 힘들었던 점은 무엇인가요? 학교에서는 별도로 쉬는 시간이 주어지기 때문에 주기적인 리프레쉬가 가능했지만, 회사는 학교와 다르게 자유롭다 보니 쉬는 시간을 스스로 조절하는 게 쉽지 않았어요. 다른 분들이 열심히 하는 모습을 보고 “이렇게 열심히 하시는 데 내가 쉬어도 괜찮은 걸까?”라는 생각을 했던 것 같아요. 처음에는 쉬는 시간에 대해 생각도 않고 계속 일을 했지만, 그 덕분에 제 집중력도 많이 늘어난 것 같아요. Q. 학교로 돌아가면 졸업까지 1년 남짓 남았는데, 이번 현장 체험을 통해 세운 계획이나 결심이 있다면 이야기해주세요. 이번 기회를 통해서 무엇보다 기본이 중요하다는 것을 알게 됐어요. 사실 그동안 제가 짠 코드에 대해 동작 원리에 대한 생각을 깊이 있게 해본 적이 없었던 것 같은데, 이곳에 오면서 그게 가장 중요하다는 것을 알게 됐어요. 또 일은 혼자 하는게 아니고, 개발도 혼자 하는게 아니니까 제가 무엇을 하려고 했는지 의도가 잘 드러나는 코드를 짜는 게 중요하다는 생각을 하게 됐습니다. 그래서 돌아간 후에는 기본적인 내용들을 보충해 나가며 제가 부족했던 부분들을 채워 나갈 예정입니다.ㅎㅎ 2023.03.03
회사이야기 '대한민국 SW기업경쟁력 대상' 우수상 수상 회사이야기 '대한민국 SW기업경쟁력 대상' 우수상 수상 브레인즈컴퍼니가 22일 서울 역삼동 삼정호텔에서 열린 '제22회 대한민국 SW기업 경쟁력 대상 시상식'에서 우수상을 수상했습니다. 대한민국 SW기업 경쟁력 대상은 인적자원·기술력·시장가치국제화 등 다각적으로 기업 역량을 평가해, 국내 SW산업 수준을 향상시킨 우수 SW기업에 수여하는 상입니다. 브레인즈컴퍼니는 IT솔루션 부분에서 자사 제품인 Zenius(제니우스)의 기술력을 인정받아 우수상을 수상했습니다. Zenius는 다양한 이기종 IT 인프라에 대한 통합관리 시스템 Zenius EMS, 웹 애플리케이션 실시간 성능 관리 시스템 Zenius APM, 분산된 대용량 로그에 대한 통합관리 시스템 Zenius LogManager 등으로 구성된 소프트웨어입니다. 이번 행사는 전자신문·한국소프트웨어산업협회·연세대 기업정보화연구센터·소프트웨어공제조합이 공동주최하고 과학기술정보통신부가 후원하며, 연세대 기업정보화연구센터가 개발한 SW기업 전문평가시스템을 적용해 수상자를 선발했습니다. 2023.02.23
사람이야기 입사 5개월 차 신입 개발자의 브레인즈 적응기 사람이야기 입사 5개월 차 신입 개발자의 브레인즈 적응기 안녕하세요. 저는 개발2그룹 인프라웹팀의 신입 사원 김예지입니다. 이제 입사한 지 5개월 차의 따끈따끈한 신입 개발자인데요. 브레인즈컴퍼니 홈페이지 및 블로그를 정독하며 면접 준비에 열을 올리던 게 엊그제 같은데, 예비 브레인저들을 위해 글을 쓰게 되다니 감회가 새롭네요. 개발자로 취업 준비를 하거나 취업 후 입사를 앞뒀을 때 막막함을 느낀 적 있으시죠? “앞으로 어떤 일을 하게 될까”, “일을 하기에 내가 충분한 실력을 갖췄을까?”, “입사 후 적응은 잘 할 수 있을까?”등의 생각을 하게 될텐데요. 저 또한 개발자로 커리어 전환을 하며 취업 준비를 할 때뿐만 아니라, 최종 합격 전화를 받은 이후에도 이런 걱정들 때문에 편히 잠을 이루지 못했는데요. “누가 미리 알려주면 좋겠다”라고 많이 생각했던 것 같아요! 그래서 저와 같은 분들을 위해 브레인즈컴퍼니 인프라웹팀의 신입 사원은 어떤 과정을 거치면서 팀에 적응해 나가게 되는지를 알려드리려고 합니다. 3개월간의 시용평가, 평가 종료 후 업무 그리고 제가 성장하는데 가장 큰 도움이 된 신입 사원 공유회의에 대해 이야기 드릴게요. ---------------------------------- 1. 입사 후 첫 3개월, 시용평가 브레인즈컴퍼니의 채용공고를 보신 분이라면 아시겠지만, 저희 회사에는 3개월의 시용평가 기간이 존재하는데요. 시용평가는 각 팀의 성격에 맞게 팀 마다 다른 방식으로 이뤄집니다. 제가 소속된 인프라웹팀의 경우, 이 3개월 동안 앞으로 해나가야 할 업무에 익숙해지기 위한 프로세스가 아주 체계적으로 구성돼 있습니다. 3개월 동안 총 3번의 발표를 진행하고, 이 3번의 평가를 취합해 최종 채용 여부가 결정됩니다. ‘최종 채용’, ‘평가’ 이런 말들이 너무 살벌하게 들릴지도 모르겠습니다만, 회사에 단계적으로 적응할 수 있는 프로세스라고 생각하고 그 단계에 맞는 일들을 열심히 수행해 나가면 되는 것 같습니다. 뭐든 그렇겠지만 정말로 ‘열심히!’가 중요하거든요.(‘잘’이 중요했다면 어쩌면 저는 이 글을 쓰고 있지 못했을지도 몰라요!) 그럼, 3번의 발표가 어떻게 진행됐는지 제 경험담을 바탕으로 자세히 설명해보겠습니다. 1) 1차 발표 1개월 차에는 약 2주 동안 IT인프라 통합관리 소프트웨어인 Zenius의 특정 인프라 화면을 구현하고 해당 내용을 발표합니다. 기존의 소스코드를 분석 및 참고해 요구 사항에 맞는 서비스 화면을 개발하면서, 앞으로 업무를 하며 꼭 알아야 할 인프라의 기본적 구조와 기능에 대해 파악하는 기간이라고 보면 될 것 같습니다. 처음 과제를 받았을 땐 “와… 할 수 있을까?”하는 생각이 잠시 스치기도 하는데요. 너무 걱정하실 필요는 없습니다. 발표를 준비하며 개발하는 기간 동안에 신입사원 교육을 주관하시는 보람님께서 꾸준히 개발 진행 상황을 점검하며 코드 리뷰를 해주시고, 이외에도 개발에 필요한 내용들이 문서화로 잘 정리돼 있어서 많은 도움을 얻을 수 있거든요! 또 약간 자랑을 하자면, 저희 팀원 분들이 정말 다 좋으신 분들이어서 뭘 물어봐도 대충 알려주는 일 없이 관련 내용을 자세히 설명해주세요. 또, 참고할 만한 자료까지 찾아 보내주시기 때문에 본인이 열심히 할수록 그에 맞는 충분히 좋은 결과를 얻을 수 있어요! 이렇게 열심히 준비를 마치면 그룹장님이신 성준님을 비롯해 팀원분들 앞에서 발표를 하게 됩니다. 당연하지만 정말 떨리고 토할 것 같은 기분을 느끼게 됩니다. 물론 발표를 들으시는 분들은 일부러 분위기를 무섭게 하시지는 않고, 오히려 웃는 얼굴로 왜 이렇게 긴장했냐며 분위기를 풀어주지만... 그렇다고 긴장이 풀리지는 않더라고요. 이때에는 Zenius에 대해 얼마나 이해했는지를 중점적으로 보고 질문을 던지고 피드백을 주십니다. 얼마나 이해했는지에 대해서 합격과 불합격을 결정짓는 절대적인 기준이 있기보단 이 기간 동안 얼마나 노력했는지를 함께 봐주시는 것 같습니다. 2) 2차 발표 2개월 차에는 한 달 동안 실제 고객사에 배포될 개발요청 업무를 진행하고, 그 중에 몇 가지를 추려 발표를 합니다. 신입 사원임을 고려해 비교적 난이도가 쉬운 개발요청을 주시고 공수도 여유있게 산정해 주시기 때문에, 이 기간에도 1차 때와 마찬가지로 단순히 일에 그치지 않고 Zenius의 기능과 인프라를 이해하는 데 시간을 많이 할애하는 게 좋습니다! 주어진 업무에 대해 단순히 개발만 하는 게 아니라, 이게 왜 필요할지에 대해서 생각해보는 것 또한 중요한 것 같습니다. 업무를 시작하기 전 기능을 추가하거나 수정해야 할 인프라의 역할과 구조를 설명해주시고, 참고할 만한 비슷한 업무 등을 함께 알려주시기 때문에 개발요청 자체에 큰 어려움은 없습니다. 모든 업무가 문서화돼 관리되고 있기 때문에 업무를 시작하기 전 항상 도움을 받을 수 있어요. 고객사에 실제로 배포되기 전까지 [개발자 테스트> 관리자 테스트> QA 테스트]를 거쳐 오류를 걸러내고 수정한 후에 배포가 이루어지는 구조라서, “신입 사원으로서 내가 사고를 치진 않을까”하는 부담을 덜 수 있습니다. 또, 이 기간에 주어진 개발요청에는 만약 신입 사원이 해당 개발요청을 제대로 해내지 못했을 경우를 대비해 커버해 줄 팀원 분을 함께 배정해주시기도 하는데요! 애초에 능력을 고려해서 업무를 배정하고, 일정을 조정해주시므로 커버가 필요한 경우까지 가는 일은 아마 없지 않을까 싶습니다. 2차도 당연히 발표를 하는데요.(2번째라고 덜 떨린다거나 하진 않습니다.) 주로 기존에 있던 코드를 활용한 1차 발표에 비해, 2차의 경우 요건을 충족하도록 본인이 작성한 코드와 로직이 발표의 주가 됩니다. 당연히 1차에 비해 조금 더 다양한 질문을 받게 되고 더 좋은 코드를 작성할 수 있는 방법에 대해 피드백을 주시며, 더 고민해 볼만한 부분을 숙제로 내주시기도 합니다. 3) 3차 발표 3개월 차에는 커스터마이징 보고서 개발 업무에 대해 배우고, 해당 내용을 발표하게 됩니다. Zenius는 여러 인프라 장비 혹은 서버의 데이터를 수집하고, 사용자가 수집한 데이터를 원하는 형태로 볼 수 있도록 보고서를 제공해주고 있습니다. 고객사의 요구사항에 따라 어느 데이터를 어떤 형태로 볼지는 달라지지만, 하나의 보고서를 만드는 프로세스와 설계는 동일하기 때문에 이 기간에 꼭 보고서가 생성되는 프로세스를 잘 이해하고 넘어가야 합니다. 개인적으로는 이 기간에 가장 많은 깨달음을 얻었습니다. 또, 이 기간엔 'OzReport'라는 다소 낯선 툴에 대해서도 배워야 하는데요. Report 교육을 받으러 본사에도 다녀오긴 하지만, 그것만으로는 심히 부족해 팀원분들에게 매우 많은 도움을 받아야 하는 기간이기도 합니다. 물론 언제나 그랬듯이 정말 친절하고 알 때까지 친절히 설명해 주신답니다! 그리고 언제나처럼 발표를 하게 되는데요. 보고서를 만들 때 꼭 알아야 하고, 실수하기 쉬운 부분들 전반에 대해 피드백을 주십니다. 이렇게 마지막 발표까지 3번의 발표를 모두 마치면 시용평가가 끝이 나게 됩니다! 그리고 이렇게 3개월을 마치고 나면 팀이 어떻게 돌아가는지, 내가 무슨 일을 해야 하고 그 일을 하기 위해서 무엇이 부족한지 그리고 그 부족함은 어떻게 채워나가야 하는지 스스로 깨닫게 되고 팀의 일원으로 자연스럽게 섞일 수 있게 되는 것 같습니다. 2. 업무 시용평가가 끝나면 본격적으로 개발 요청 업무를 맡아 진행하게 됩니다. 2차 발표에서 말했던 것처럼 [업무설명> 개발> 검토> 관리자 테스트> QA테스트> 배포]의 순서로 한 사이클이 진행됩니다. Java/Spirng, javaScript, postgreSql을 사용하고, 백/프론트를 나누지 않고 전체적으로 아울러 개발합니다. 본인이 잘 모르거나 부족한 부분이 있을 경우, 회사에 교육 신청서를 내서 인강을 지원받을 수 있습니다.(*참고로 시용평가 3개월 기간에는 의무로 3가지 인강을 듣습니다. 과제의 진행 상황이 스스로 여유롭다고 판단되면 업무 시간 중 강의를 수강하는 것도 가능합니다. 이후로는 자유롭게 필요한 인강을 선택해 신청하면 됩니다.) 업무는 모두 문서화돼 관리하고 있습니다. 조금 더 자세히 설명하자면, 먼저 회사 내부에 등록된 업무(팀에서는 일감이라도 부릅니다.) 문서를 통해 개발요건과 공수를 확인합니다. 고객사마다 패키지가 다르므로 각각의 개발환경을 세팅하게 되는데요. 이 과정에서 만약 신규 고객사라면 고객사의 테스트서버와 배포 폴더를 생성하는 등의 일을 하게 됩니다.(SVN과 Jenkins를 사용합니다.) 이러한 내용들 또한 문서화돼 있어, 신입 사원 교육과정의 일부로 차근히 알려주시기 때문에 혹시 모르는 개념이 있으시더라도 너무 걱정하실 필요 없습니다! 모든 건 다 정말 친절히 알려주시고 적응할 때까지 기다려주시니까요. 가장 중요한 건, 개발기간을 지켜야 한다는 점인데! 보시는 것처럼 주어진 업무마다 개발일정이 정해져 있는데요. 개발일정을 픽스하기 전에 먼저 기간 내에 특이사항은 없는지, 공수는 충분한지 등을 확인 차 물어봐 주세요. 이 때 뭔가 특이사항이 있거나, 공수가 모자라다고 생각된다면 사유를 말씀드리고 일정을 수정할 수 있습니다. 예를 들면, 휴가! 휴가가 있다면 피해서 일정을 잡아주세요. 참고로 휴가는 미리 말만 한다면 언제든 자유롭게 사용할 수 있습니다. 업무 자체가 타이트하게 관리되기도 하고, 아까 말씀드린 것처럼 모든 업무가 문서화돼 관리하고 있다는 게 장점인 만큼, 개발자도 개발요청을 하면서 문서로 기록해둬야 하는 일이 많다는 얘기이기도 한데요. 그래서 저희 팀에 가장 필요한 성격 중 하나는 꼼꼼함과 정확함이 아닐까 합니다. 실제로 성준님께서도 “속도보다는 정확함이 중요하다!” 라는 말씀을 신입 사원 면담 때 해주시기도 했거든요! 그리고 이건 팀에 맞는 인재인지를 판별하는데 꽤 중요하게 작용하는 것 같다고 생각합니다. 본인이 정해진 일정 속에서 체계적으로 일하는 걸 선호하거나, 신입 사원으로서 팀에 잘 적응해 나가기 위해 항상 나를 돌봐주는(?) 누군가가 필요한 편이라면 저희 팀은 굉장히 좋은 선택이 되지 않을까 합니다. 3. 신입 사원 공유회의 마지막으로 소개하고 싶은 건 신입사원 공유회의입니다. 개인적으로 회의라기보다는 스터디에 가깝다고 생각하는데요. 신입 사원을 대상으로 1차 평가가 끝난 이후 매주 화, 목에 1시간씩 6개월 이상 동안 진행되고, 1주일에 하나씩 Zenius나 회사 업무와 관련해 알게 된 지식을 정리해 공유하고 발표하는 자리입니다. 신입 사원 공유회의라고는 하지만 신입 사원끼리만 진행하는 건 아니고 저희 이사님이신 성준님도 함께하는데요. 그렇기 때문에 사실 시용평가는 끝났지만 발표는 계속된다…의 느낌이기도 합니다.(발표를 하다 보면 내용이 길어지기도 하고, 알려주시는 것도 많아 지기 때문에 사실 1시간 내에 끝난 적은 별로 없습니다.) 부담되지 않는다면 거짓말이겠지만 실로 엄청나게 도움이 되고, 업무에 국한되지 않고 더 깊고 근본적인 지식을 많이 얻어갈 수 있는 자리입니다. 일단, 나도 모르게 더 좋은 개발자가 될 수 있도록 생각의 근간을 뜯어고치는 느낌이고, 하나의 내용에 대해서도 심도 있게 다루는 시간이기 때문에 발표는 부담스럽지만 알아가는 자체가 즐겁고 재밌습니다! 사실 신입 사원 공유회의를 하고 난 뒤에 “가장 많이 뭔가 스스로 발전했다!”라고 느끼게 되는 것 같아요. ---------------------------------- 사실 아직도 신입이고 저희 팀을 100% 안다고 할 수 없지만, 분명히 말씀드릴 수 있는 건! 인프라웹팀은 입사 당시에 많이 부족했던 제가 한 명의 개발자로서 잘 적응할 수 있을 만큼 신입 사원을 위한 프로세스가 잘 갖춰져 있다는 것입니다. 프로세스마다 코드리뷰를 통해 개발을 하면서 기본적으로 가져야 할 개념이나 마인드 그리고 고쳐야 할 습관들을 알려주시고, 나아가 공부해야 할 부분도 알려주시기 때문에 느리더라도 확실하게 발전해 나갈 수 있습니다. 그리고 이런 과정을 통해 스스로 “더 좋은 개발자로 성장할 수 있겠다”라는 확신을 가질 수 있습니다. 너무 장점만 소개해드린 건 아닌가 싶지만, 저는 정말 다니면서 단점이라고 느낄만한 부분을 아직은 찾지 못했어요! (굳이 따지자면 신입 사원 공유회의의 발표가 매주 있다는 것이 다소 부담스럽다는 점…. 하지만 이 또한 본인의 마음가짐에 따라 즐길 수 있는 부분이지 않을까요?! 실력은 확실히 느니까요!) 이 글이 예비 브레인저에게 조금이나마 도움이 되면 너무 기쁠 것 같습니다. 혹시 지원을 망설이고 계시거나 걱정하는 분이 이 글을 읽으면서 “와, 브레인즈컴퍼니 좋다! 나도 지원해야지!”라는 생각이 들면 좋겠네요. 이렇게 약 5개월 간의 신입 사원 적응기를 마무리하겠습니다! 2023.02.02
기술이야기 JPA 도입을 위한 고민_ORM 기술을 써야 하나? 기술이야기 JPA 도입을 위한 고민_ORM 기술을 써야 하나? 몇 해전에 새로운 버전의 ITSM을 개발하기 시작하면서 JPA 기술 도입을 두고 고민했던 내용을 이제는 한 번쯤 정리해야 할 시점이라고 생각했다. 비단 JPA뿐 아니라 Spring Boot, Thymeleaf, Kotlin과 같은 새로운 개발 기술이나 Git, Gradle, Slack, PR처리 등 새로운 업무 환경까지 상당한 변화를 시작한 프로젝트였기 때문에 고민되는 것이 한두 개가 아니었지만 가장 길고 심각하게 고민했던 부분이라 따로 기록을 남겨본다. 이 글은 기술적인 내용은 아니고 어떻게 보면 당연하고 일반적인 내용이지만 다음 기회에 새로운 기술, 환경, 프로세스에 대한 도입을 검토할 때 조금이나마 도움이 됐으면 하는 마음이다. 여기에선 기술적인 내용에 대한 설명을 덧붙이지 않는 것은 관련된 내용은 'JAVA', 'ORM', 'JPA' 등으로 검색만 해도 비슷한 글들이 넘쳐나는 상황에 하나 더 덧붙이는 건 별로 의미가 없어 보이기 때문이다. 1. ORM에 대한 갑을논박 ORM에 대한 검색을 해보면 정말 여기서 다시 얘기하고 싶지 않을 정도로 오랜 시간동안 많은 사람들의 많은 의견들이 쏟아져 나온다. 게다가 더욱 혼란스러운 점은 구구절절 옳은 말들이라는 점이다. 여기서 뭔가 딱 부러진 결론을 내는 것은 불가능하고 너무 많은 의견들을 접하면서 점점 혼란스러워졌다. 대표적으로 참고 삼아 [자바 ORM 표준 JPA 프로그래밍]을 쓰신 김영한님의 글로 추정되는 링크 하나 투척~ https://okky.kr/article/286812 2. 우리에게 중요한 것 2.1. 진입장벽 : 진입장벽… 이 높다한들 하늘 아래 뫼… 일까? 어떤 기술이든 진입장벽은 그 도입 여부를 결정하는 가장 중요한 요소이다. 개인적으로 스터디를 하거나 한번 써보고 싶은 마음에서라면 진입장벽이 높을수록 구미가 당기는 변태적인 성향이 있는 사람도 있겠지만 이게 업무적인 접근이고 다른 팀원들과 함께 해야 하는 것이라면 진입장벽이 높이에 따라서는 그 기술의 효과가 인정되어도 도입이 쉽지 않은 것이 사실이다. JPA는 많은 사람들이 진입장벽이 높은 편이라고 입을 모아 말한다. 검토를 위해 살짝 들여다 보았을때도 쉬워 보이진 않았다. 말 그대로 ORM을 잘 쓰기 위해서는 Object와 Model에 대한 깊이 있는 사전 지식과 그 둘을 Mapping하는 개념적인 체계가 머리 속에 있어야 충분히 활용할 수 있을 것 같았다. 진입장벽이란 것도 사실 상대적인데 당시에 판단으로 우리 팀에서 도입하기에 진입장벽은 중상(中上)이라고 생각했다. 잘 자리잡기 쉽지 않을 것이고 시간도 오래 걸리리라 생각이 들었다. 이러한 점을 만회할 장점이 있는지 고민이 필요했다. 2.2. 제품 특징 : 우리가 만드는 제품/프로젝트의 특징에 맞는가? 당시에 새롭게 시작되는 프로젝트에서 만드는 제품은 기존 Zenius ITSM 시스템의 새로운 버전이다. 업무적으로 여러가지 특징이 있지만 Model과 관련되어서는 상대적으로 복잡한 구조라 할 순 없었고 극단적인 성능과도 거리가 좀 있다. 상대적으로 깔끔하고 명확한 모델링이 훨씬 더 중요하다고 판단했고 이러한 면은 JPA도입에 대한 긍정적인 입장을 가지게 했다. 쿼리와 관련되어서 수많은 간단한 작업들을 효과적으로 할 수 있을거란 기대감… 만약 만들려고 하는 제품이 특정 RDBMS에 의존적이거나, 혹은 인수인계나 유지보수가 어려울 정도로 비즈니스부터가 복잡한 형태라서 JPA를 쓰면서도 많은 성능 튜닝과 Native Query를 사용해야 하는 상황이거나 한다면 상황은 약간 달라졌을 것이다. 제품의 특징과 더불어 현재 프로젝트의 특성도 같이 살펴봐야 한다. 레거시 시스템의 업그레이드인지, 이번 프로젝트처럼 완전히 새 판에서 시작하는 게 가능한 상황인지… 새로운 제품을 만드는 프로젝트가 납기일이 정해진 프로젝트보다 나은 점은 그나마 초기 학습과 관련된 투입을 감안하기가 좀 더 수월하다는 점이다. SI같은 성격의 프로젝트라면 내부 고객뿐 아니라 상대방 고객도 설득해야 하는 문제점이 더 크다. 그런 면에서 이번 프로젝트는 JPA를 도입하거나 적용하기엔 괜찮은 상황이라는 게 결론이었다. 2.3. 조직/인력 구조 : 바로 우리가 쓰는 기술이다. 기술도 중요하지만 우리도 중요하다. 제목처럼 아무리 좋은 기술이라도 우리에게 맞냐는 게 결정적이다. 아래와 같은 질문들을 던져 보았다. • 현재 구성원들의 사전 지식은 어느 정도인가? • 우리 회사나 우리 팀에서 향후 관련된 개발자를 계속 충원할 수 있는가? • 우리 팀은 새로운 기술을 공부하며 도입할 의지를 가졌는가? • 회사는 관련된 교육과 초기에 벌어질 삽질을 감내할 수 있는가? 결론적으로 반반이었다. 우리 팀은 JPA에 대해서 아는 바가 거의 없는 상태였다. 게다가 지금이야 JPA를 사용하는 사람들도 더 늘어난 것 같고 우리 회사의 위상도 달라졌지만 당시의 우리 회사의 규모나 채용 형태를 봤을 때 관련된 개발자를 충원하는 것도 쉽지는 않을 것 같았다. 반대로 새로운 기술 도입에 대해서 강한 의지까지는 아니라도 긍정적은 자세를 가진 팀원과 초기 삽질에 대해서 어느 정도 감내할 수 있는 회사라는 것이 당시의 생각이었다. 그래도 반이 어디냐…는 게 최종 결론이었다. 2.4. 재미 : 그래서 땡기냐? 이성적이고 객관적인 여러 사실들을 매트릭스화해서 평가를 하면서도 스스로에게 던지는 마지막 질문은… 그래서 땡기냐는 거다. 모든 수치가 부정적인데도 끝까지 미련을 버리지 못하고 하고 싶은 경우가 있고, 모든 결과가 긍정적인데도 뭔가 하기 싫은 경우가 많은데, 결국 그것들은 결과로 이어지더라. 리누스 토발즈가 커널을 업그레이드할 때 가장 중요한 점으로 “얼마나 재미”가 있냐는 점이라고 얘기 했다는데, 우리는 그 정도 레벨의 개발자는 아직(!) 아니지만 우리에게도 “재미”는 가장 중요한 결정요인 중 하나이다. 스스로에게 물어보자. 재미있어 보이나? 그리고, 당시에 나에게는 무척 설레었던 일이었음을 고백해야겠다. 3. 염려스러운 점 3.1. 회귀본능 아직 익숙하지 않은 상태에서 개발을 진행하다 보면 도무지 JPA에서 왜 이런 쿼리를 만들어내는지 이해하기 어려운 경우를 종종 만난다. 혹은 익숙한 SQL이 머리속에서 막 떠오르는데 JPA로 적용하기 위해서 이런저런 삽질을 하다 보면… 아… 그냥 쿼리를 직접 짤까? Native Query도 Mybatis도 지원한다던데… 분명 이런 순간이 올 것이라고 예상했다. 공부를 하는 것도 좋지만 회사에서 업무로 일정에 맞춰 무언가를 만들어내야 하는 압박감은 따로 누가 주지 않아도 가지고 있는 것이니… 침착하자. 익숙하지 않고 힘들다고 나도 모르게 무언가 자꾸 길을 벗어나고 있는 건 아닌지 계속 주의 깊게 들여다 봐야 한다. 결론적으로 지금에 와서 돌이켜보면 초반에는 의도대로 생성되지 않는 쿼리들에 당황하긴 했지만, 약간의 삽질 후에는 왜 그런 상황이 발생되는지 알기가 어렵지는 않았다. 언젠가는 복잡한 통계나 로직 때문에 Native Query를 쓰게 될 날이 오겠지만 아직은 아니다. 3.2. 학습곡선 도입하려는 기술에 따라, 혹은 구성원의 사전 지식에 따라 학습곡선은 상당히 다양한 형태로 나타나는데, 평균적으로 JPA의 학습곡선은 전반적으로 경사가 아주 완만하다고 판단했다. 즉 도입 검토 시점의 진입장벽은 그 자체로 염려스러운 점이었다. 그 얘기는 수준을 일정수준 이상으로 끌어올리기 위해서 많은 시간과 노력이 팀 차원에서 필요하다는 얘기였고 필요로 하는 사전지식도 꽤 있을 듯 했다. 게다가 여러 가지 이유로 개인별로 나타나는 학습곡선도 많이 다르리라 예상했다. 뭔가 기막힌 해결책이 있으면 좋겠지만, 책을 구매해서 읽고 유료 강의, 무료 강의들을 공유하고… 서로서로 도와가며 공부하는 클래식한 정공법을 택했다. (그만큼 사실 효과는 기대하기 힘들다는 것도 알지만…) 지금 생각해보면 어떤 기술이나 프로세스든 누군가 소수의 인원이 먼저 출발해서 끌어줄 수 있는 형태가 되는 것이 제일 나은 것 같다. 서로서로 도움을 주면서 같이 커가는 모양새가 될 수 있을 듯 한데 우리는 그렇지는 못했고 모두가 공평(?)하게 모르는 상태에서 스타뜨~ JPA의 도입에 대한 학습곡선은 최종적으로 도입을 결정하는데 마지막까지 고민을 하게 했던 점이었다. 3.3. Mapper는 누가? 자, 우리는 Object도 Model도 이제까지 다 개발자가 했다. Object야 당연히 개발자가 만들어야 하겠지만 큰 기업에서처럼 DBA가 있거나 화면을 퍼블리싱해주거나 하지 않는다. 우리는 우리가 화면, 미들웨어, DB까지 직접 만들고 컨트롤 해왔다. 그게 좋은 것이냐의 문제를 여기서 얘기하자는 게 아니라 현실이라는걸 얘기하는 거다. 우리 팀원 모두가 JPA 초보이다. Mybatis를 사용하고 Spring을 사용해봤다고 하지만 ORM이나 SQL Mapper에 대한 심도있는 고민은 부족한 상황. 앞으로 JPA에서 Object와 Model은 그렇다고 해도 Mapper역할은 또 필요하지 않을까? 그런 가이드는 또 누가 해야 하나… 모든 개발자에게 알아야 한다고 말할 수 있지만 모든 개발자에게 팀에서 잘하는 메인이 되라고 하기엔 좀 애매한 영역이란 게 항상 있다. 프로그램의 오브젝트와 DB의 모델을 연결하는 Mapper를 잘 구성할 경험이 많은 개발자가 없다는 점은 학습곡선과 더불어 JPA 도입을 망설이게 했던 주요 고민이었다. 결론적으로 선임 개발자를 중심으로 착실히 스터디를 잘 해주었고 제품의 특성상 그렇게 복잡한 관계를 매핑할 일이 많지 않아서인지 초반에 몇 번 팀원들이 같이 머리를 싸매고 논의했던 것 외에 문제는 없었다. 4. 결론(현재까지는…) 도입 결정 후 꽤 긴 시간 제품을 만들고, 이제는 고객사에 납품도 하면서 기능을 계속 추가하고 있는 이 시점에서 돌아보면, 어떤 부분은 팀원들이 너무 잘해주고 있고, 어떤 부분은 전혀 예상하지 않은 형태로 진행이 돼서 난감한 경우도 있지만 전체적으로는 아주 만족하고 있다. 정확하게 측정을 하진 못했지만 쿼리를 직접 짜면서 개발을 진행하는 것보다 생산성 측면에서 확실히 나아졌다고 느끼고 있고 그 효과는 초반에 투입된 시간에 비례해 앞으로 더욱 더 기대된다. 만족하고 있다고는 했지만 여기서 만족이라는 게 성과나 기술적인 완성도에 대한 절대적인 만족은 아니다. 다만 아직 우리 제품에 대한 아쉬움을 가지는 것이 JPA 때문은 아니라는 점은 확실하다. JPA가 유행에 따라 생긴 기술이라고 하기엔 너무 오래된 기술이지만 그래서인가 ORM 자체에 대한 흥미도 점점 더 해가고 있다. JPA도 ORM에 대한 가장 최근의 시도중 하나겠지만, 앞으로 어떤 식으로 발전해 나갈지, 그에 따른 개발 업무는 또 어떤 식으로 변화가 있을지도 궁금하고… 어쨌든, 지금으로서는 다시 돌아가진 않을 생각이다. 2023.01.03

1 2 3 4 5 6 7 8