반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
EMS Solution
Features
클라우드 관리
AI 인공지능
서버관리
데이터베이스 관리
네트워크 관리
트래픽 관리
설비 IoT 관리
무선 AP 관리
교환기 관리
운영자동화
실시간 관리
백업 관리
APM Solution
애플리케이션 관리
URL 관리
ITSM Solution
서비스데스크
IT 서비스 관리
Big Data Solution
SIEM
Dashboard
대시보드
Consulting Service
컨설팅 서비스
고객
레퍼런스
고객FAQ
문의하기
가격
자료실
카탈로그
사용자매뉴얼
회사소개
비전·미션
연혁
2016~현재
2000~2015
인증서·수상
투자정보
재무정보
전자공고
IR자료
새소식
공고
보도자료
오시는 길
채용
피플
컬처
공고
FAQ
블로그
열기
메인 페이지로 이동
블로그
최신이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
잘파세대(Z세대 + 알파 세대)에 대한 모든 것
SMS를 통한 서버관리는 꼭 이렇게 해야만 한다?!
이화정
2024.02.22
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
네트워크 정보 수집 프로토콜의 모든 것 (SNMP, RMON, ICMP, Syslog)
Gartner에서 진행한 연구에 따르면 기업에서 서버의 다운타임이 발생할 경우, 시간당 약 748억 ~ 1,202억의 손실 비용이 발생한다고 합니다.
또한 서버 다운타임등 서버를 제대로 관리하지 못했을 경우에는, 금전적인 손실뿐 아니라 고객이탈이나 브랜드이미지 하락 등의 치명적인 손실도 입게 되죠.
따라서 올바른 서버 관리를 통해 문제를 미리 예방하고, 혹여나 문제가 발생할 경우에는 빠르게 대응할 수 있어야 합니다. 그렇다면
'올바른 서버 관리'란 정확히 무엇을 의미하는 걸까요?
ㅣ올바른 서버 관리를 위한 첫 걸음
ⓒoutsource2india
올바른 서버 관리를 위한 첫걸음은 바로 '통합 서버 관리' 도구의 도입입니다. 가장 많이 활용하는 도구가 바로 SMS(Server Management System)죠.
SMS는 복잡한 IT 인프라를 효과적으로 관리하고, 모니터링할 수 있는 해결책을 제공하여, 서버 사태를 쉽게 파악하고, 필요한 조치를 신속하게 처리할 수 있도록 도와줍니다.
SMS는 기업의 서비스 안정성과 비즈니스 연속성을 보장하는 데 필수적인 도구인 셈이죠. 최근에는 관리하는 서버의 규모와 상관없이 대부분 SMS을 사용하고 있습니다.
하지만 SMS를 도입하고 구축만 한다고 해서, 모든 과제를 해결할 수 있을까요?
ㅣSMS를 제대로 활용하는 방법
SMS를 '제대로' 활용하기 위해서는 단순한 모니터링을 넘어, 문제 발생 시 알림을 받고 이를 통해 신속하게 문제를 해결할 수 있는 적극적인 조치가 필요합니다.
적극적인 조치 중의 대표적인 예이자 서버 관리의 핵심은 바로 '감시 설정'입니다. 그렇다면 구체적으로 '감시 설정'을 통해 어떻게 서버를 관리해야 하는지, 이를 위한 SMS의 조건은 무엇인지 살펴보겠습니다.
최적화된 감시 설정 값을 간편하게 설정할 수 있어야 한다
SMS의 감시항목설정은 사용자가 기본적인 모니터링 환경을 빠르게 구축할 수 있도록 간편하게 설정할 수 있어야 합니다. 통합 서버 관리에 대한 경험이 부족한 사용자더라도, 제품을 쉽게 설정하고 사용할 수 있도록
최적화된 감시 설정 값을 제공
해야 하죠. 예를 들면 CPU 사용률이 몇% 였을 때 심각하고 위험한지를 각 항목별로 제공해야 합니다.
Zenius SMS의 경우 사용자의 OS에 따라 감시 설정 항목(CPU 사용률, MEM 사용률 등)의 심각도와 임계치 조건은 어떻게 해야 하는지 기본적인 디폴트 값을 제공합니다.
더불어서 제니우스만의 최적의 감시 설정 가이드라인을 제공하여, 복잡한 설정 과정을 거치지 않더라도 모니터링할 수 있도록 도와주죠. 물론 기업과 조직의 환경에 맞춰 감시 설정을 조정할 수 있습니다.
필수적인 감시 설정 기능을 갖추고 있어야 한다
또한 SMS의 감시 항목을 설정할 때는
필요한 주요 기능으로 구성
되어야 합니다. 사용자는 복잡한 설정 절차 없이 필요한 감시 항목을 설정해야 하고, 서버 관리에 소요되는 시간을 줄일 수 있어야 하기 때문이죠.
예를 들어 시스템의 중요한 지표(예: CPU 사용량, 메모리 사용량, 디스크 I/O 사용률)를 확인할 수 있는 감시 항목 설정이 있는지, 각 감시 항목에 대해 심각도 수준과 임계치를 설정할 수 있는지, 다양한 방식의 알림 방식 기능을 제공하는지 등을 직관적으로 확인할 수 있어야 합니다.
Zenius SMS의 경우 사용자에게 꼭 필요한 기능(감시 항목, 서버, 심각도, 임계치, 알림 설정, 복구 스크립트 등)만 집중할 수 있도록 구성되어 있습니다.
감시 항목에서는 사용 중인 OS를 설정하고, 원하는 감시 항목을 선택하여, 원하는 서버를 감시 설정 할 수도 있죠. 또한 심각도와 임계치 설정에서는 무해-주의-위험-긴급-치명 각 값에 맞게 임계치 값을 설정할 수 있습니다.
예를 들어 '긴급'이라는 항목에 80%라고 설정했는데 임계치 값이 80%를 넘어설 경우, 사용자에게 즉각적으로 알려줍니다. 또한 지속시간을 1분 발생 횟수를 1이라고 설정할 경우, 1분을 넘길 때 사용자에게 알림을 통보해 주죠.
알림 통보 서비스가 잘 갖춰져 있어야 한다
감시 항목 설정 중
알림 통보는 서버를 관리하는 데 있어 매우 중요한 기능
입니다. 서버에 문제점이 발생할 경우, 사용자에게 즉각적으로 알려줄 수 있는 장치이기 때문이죠. 또한 문제가 더 심각해지기 전에 신속하게 조치를 취할 수 있게 해주며, 시스템의 다운타임을 최소화하는 데 결정적인 역할을 합니다.
이 밖에도 알림 통보 기능에서는 사용자의 업무 환경과 선호도에 따라, 알림의 유형이나 수신자를 유연하게 선택할 수 있어야 합니다.
Zenius SMS를 예를 들어 살펴보면 감시 설정에 임계값을 초과하거나, 예상치 못한 이벤트가 발생했을 때 다양한 형태로 알림 서비스를 제공하고 있습니다. 이메일, 문자 Push App은 물론 외부 연동을 통해 슬랙이나, 카카오톡으로도 편리하게 알람을 받아볼 수 있죠.
이 밖에도 알림의 임계값과 조건, 적용 시간이나 요일, 알림을 받을 사용자도 별도로 지정할 수 있습니다.
자동화 복구스크립트 기능을 제공해야 한다
서버에 문제가 감지되었을 때는 알림 통보 기능뿐만 아니라,
사전에 정의된 스크립트를 자동으로 실행하여 문제를 신속하게 해결
할 수 있어야 합니다. 예를 들어 데이터베이스 서버의 응답 지연이 감지될 때 '캐시를 클리어하고 서비스를 재시작해 줘!'라는 스크립트 실행을 통해 즉각적으로 문제를 해결할 수 있어야 하죠.
이러한 자동화 복구스크립트 기능은 사용자가 알림을 받고 대응하기까지의 시간을 대폭 줄여줄 수 있고, 이에 따라 시스템 다운타임을 최소화할 수 있습니다. 또한 반복적이거나 단순한 문제 해결 과정을 자동화함으로써, 더 중요한 작업에 집중할 수 있겠죠.
위에 언급한 내용을 Zenius SMS를 통해 살펴보면, 장비에 장애가 발생할 경우 즉시 복구스크립트가 구동되어 문제를 자동적으로 해결할 수 있게 합니다.
예를 들어 A 서버에 임계치를 80%로 설정한 후, 복구스크립트를 통해 'C라는 방법으로 조치를 취해줘!'라고 미리 설정할 경우 자동적으로 문제를 해결할 수 있죠. 이러한 자동화 복구스크립트 기능은 수백 혹은 수천 대의 서버와 장비를 효율적으로 관리할 수 있어, 관리 부담을 줄이는 데 매우 효과적입니다.
또한 '정상 복구 시 통보' 옵션을 설정하면, 복구 스크립트가 완료됨에 따라 알림 통보를 사용자에게 재차 알려줍니다. 이 과정을 통해 사용자는 만족도와 제품에 대한 신뢰도를 높일 수 있겠죠.
감시 항목들을 한눈에 관리할 수 있어야 한다
이젠 앞에서 감시 설정하고 등록했던 감시 항목들을 모니터링할 수 있어야 하겠죠? 이때 중요한 점은
필수적인 감시 항목은 보여주되, UI는 단순화
해야 한다는 점입니다. 이는 주요 감시 항목의 상태를 신속하게 파악하고, 문제가 발생했을 때 즉각적으로 대응하기 위해서죠.
또한 감시 항목 상태를 색상 코드(예: 녹색은 정상, 노란색은 경고, 빨간색은 심각)와 아이콘으로 구분하여, 사용자가 감시 항목의 상황을 즉각적으로 인식할 수 있도록 해야 합니다.
Zenius SMS의 경우 주요 감시 항목들의 현황을 통합적으로 모니터링할 수 있습니다. 불필요한 항목들을 줄이고 핵심적인 항목들만 선별하여, 서버의 감시 항목을 신속하게 모니터링할 수 있죠.
감시 현황은 직관적인 UI가 중요한 만큼, 심각도 현황(정상-무해-주의-위험-긴급-치명)을 색상으로 구분하여 문제가 생겼을 때 신속하게 대응할 수 있도록 구성하였습니다. 또한 사용자의 환경에 맞춰 필수적인 감시 항목을 쉽게 선택하여 모니터링할 수 있습니다.
이 밖에도 많은 서버의 감시 항목을 관리하다 보면, 중요한 감시 항목을 추가하지 못한 상황이 발생할 수 있는데요. 최악의 경우에는 막대한 손실 비용 발생 등의 심각한 결과를 초래할 수 있겠죠.
이에 따라 감시 현황은 더더욱 직관적으로 모니터링할 수 있어야 합니다. 주요한 감시 항목을 실수로 설정하지 않더라도, 신속하게 파악하고 등록하여 대처할 수 있기 때문이죠. Zenius SMS는 감시 설정해 둔 항목 수가 예상과 다를 경우(예: 만약 관리하는 서버에 감시 항목이 2건이어야 하는데 → 1건으로 표기된 경우) 미등록 건 감시 항목을 조회하여 등록할 수 있습니다.
주요 감시 항목을 설정하고 동작여부에 '미등록' 항목으로 검색하면, 감시 설정하지 않은 항목을 조회할 수 있죠. 이처럼 Zenius SMS은 자칫 놓칠 수 있는 주요 감시 항목도 신속하게 찾아 등록할 수 있습니다.
。。。。。。。。。。。。
지금까지 살펴본 것처럼 Zenius와 같은 SMS를 통해서
서버를 한눈에 모니터링하고, 감시 설정 기능을 통해 체계적으로 관리하며, 문제 발생 시 다양한 알림과 자동화된 복구스크립트로 문제점을 신속히 해결
해야 합니다. Zenius SMS 대규모 서버자원을 관리하고 있는 한 고객사 관계자의 말씀으로 이 글을 마무리하려고 합니다.
"이 많은 서버의 감시 항목들을 휴일 없이 24시간 동안 지켜볼 수는 없잖아요. 그래서 서버를 통합 관리할 수 있는 Zenius SMS을 도입했죠. 이용하면서 좋았던 점은 감시 현황 페이지를 통해 한눈에 감시 항목을 관리할 수 있어 편리하다는 점이에요.
감시 설정을 걸어둔 항목들이 많아 종종 등록을 못한 경우가 발생해도, 직관적으로 확인하고 감시 항목을 추가할 수 있어요. 특히 복구 스크립트 기능을 애용하는 편인데요. 서버에 장애가 발생했을 때 복구 스크립트를 미리 걸어두면, 장비에 장애가 발생해도 신속하게 문제 해결을 할 수 있어 매우 만족스럽습니다!"
#SMS
#서버
#서버관리
#서버모니터링
#Zenius
#ZeniusSMS
#통합서버관리
이화정
프리세일즈팀
프리세일즈팀에서 마케팅, 내외부 홍보, 콘텐츠 제작을 담당하고 있어요.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
옵저버빌리티(Observability) vs APM, 우리 기업에 맞는 솔루션은?!
옵저버빌리티(Observability) vs APM, 우리 기업에 맞는 솔루션은?!
지난 글을 통해 웹 애플리케이션을 전반적으로 모니터링하고 관리하기 위한 좋은 도구인, APM의 핵심요소와 기능에 대해서 알아봤습니다(지난 글 보기). APM은 분명 좋은 도구이지만 문제 원인이 애플리케이션, 웹, WAS, DB가 아닌 특정한 시스템 오류이거나 클라우드 네이티브 환경에서의 장애일 경우 문제 발생 원인을 명확히 밝히기 어려울 수 있습니다. 따라서 이번 시간에는 APM의 한계성은 무엇이고, 이를 보완하기 위한 방법은 무엇인지 자세히 살펴보겠습니다. │APM 한계성 불과 얼마 전까지만 해도 예상치 못한 장애를 탐지하고 분석하는 것은, 기존 APM만으로 충분했었습니다. 기존에는 모놀리식 구조로 되어있어 애플리케이션이 적은 수로 구성되어 있었고, Web-WAS-DB가 모두 단일 구조로 구성되어 있었기 때문입니다. 하지만 현재 대다수 기업들은 MSA 환경에서 서비스를 구축하고, DevOps 구조로 업무를 진행하는 경우가 많습니다. 즉 클라우드 네이티브 환경에서는 기존 모놀리식 구조의 APM의 한계가 하나둘씩 보이기 시작한 것이죠. 이러한 이유로 클라우드 네이티브 방식에는 서비스 장애 원인을 분석하기 위한 새로운 모니터링 툴이 필요했습니다. 이때 등장하는 것이 바로 옵저버빌리티(Observability)입니다. │Observability란? 그렇다면 Observability란 무엇일까요? 옵저버빌리티는 IT 인프라에 대한 근본적인 장애 원인을 분석하기 위한 방법론입니다. 관찰 가능성이라고 표현되기도 하죠. Obsevability는 비교적 최근에 사용한 용어이지만, 옵저버빌리티를 위한 고민은 오래전부터 지속되어왔습니다. 시스템이 내가 의도한 대로 작동하고 있을까? 예상치 못한 장애 탐지와 장애 근본 원인은 어떻게 분석할 수 있을까? IT 인프라 운영 환경에 문제가 발생했을 때, 문제 식별을 위해 필요한 객관적인 지표는 어떻게 도출할 수 있을까? 하지만 소프트웨어 애플리케이션에서 Observability는, 위와 같은 고민이 발생하거나 겪어보지 못했던 현상이 생길 때 이를 이해하고 설명할 수 있는 지표를 분석해 줍니다. │Obsevability의 등장배경 및 필요성 앞에서 옵저버빌리티가 무엇인지 살펴봤는데요. 이어서 Observability가 등장하게 된 이유와 필요성에 대해 자세히 살펴보겠습니다. MSA 전환에 따른 복잡성 증가 옵저버빌리티가 등장하게 된 첫 번째 이유는, 모놀리식 아키텍처에서 MSA 환경으로 전환함에 따라 복잡성이 증가했기 때문입니다. 우선 그림을 통해 자세히 살펴보겠습니다. [그림(왼)]은 모놀리식 아키텍처를 나타내는데요. 애플리케이션의 모든 구성 요소가 하나의 인프라로 통합되어 있는 형태입니다. 배포가 간단하며, 확장성이 쉽고, E2E 테스트가 용이하다는 장점이 있습니다. 하지만 조그마한 수정 사항이 있으면, 다시 구성 환경을 빌드하고 배포해야 한다는 단점이 있습니다. 또한 일부 오류가 전체 아키텍처에 영향을 미친다는 치명적인 단점도 존재하죠. 반면 [그림(오)]에 해당하는 MSA(Micro Service Architecture)는 하나의 큰 애플리케이션을 여러 개의 작은 애플리케이션으로 쪼개어, 변경과 조합이 가능합니다. 작은 서비스의 독립적 배포라는 강력한 장점을 앞세워 Netflix, PAYCO와 같은 다양한 기업들이 앞다투어 MSA를 받아들였습니다. 여기서 문제는 MSA로 변화함에 따라 통합 테스트나 E2E 테스트 검증이 필요해졌는데요. 이처럼 여러 서비스의 API를 검증해야 하므로, 복잡성이 증가하고 많은 시간과 비용이 소모되었습니다. 무엇보다 각 서비스 별로 자체적인 데이터베이스가 있어, 트랜잭션에 대한 파악이 어려워지기도 했죠. 따라서 기존 APM이 담당하는 트랜잭션 모니터링의 복잡성은 더욱 증가했고, Observability의 필요성이 대두되었습니다. DevOps와 클라우드 네이티브 환경으로서의 전환 옵저버빌리티가 등장하게 된 두 번째 이유는, DevOps와 클라우드 네이티브 환경으로 전환하기 위해 필요한 도구이기 때문입니다. DevOps의 핵심은 소프트웨어의 개발(Deployment)과 운영(Operation)을 분리하는 것이 아닌, 하나로 통합된 업무 처리 방식으로 진행됩니다. 이때 관리하는 서비스 전반에 대한 가시성이 충분히 확보되지 않으면, DevOps 조직은 근본적인 원인을 찾는 데 어려움을 겪게 됩니다. 이러한 어려움을 해결하기 위해서는 서비스를 구성하는 아키텍처부터 트랜잭션까지 가시성이 확보되어야 합니다. 이를 통해 DevOps의 목표인 지속적인 개발과 운영의 통합을 만들어낼 수 있죠. 또한 Observability는 클라우드 네이티브 환경으로 전환하기 위한 필수 조건입니다. 기업에서 운영 중인 서비스/IT 인프라가 클라우드 네이티브 환경으로 전환되면서, 이전에 발생하지 않았던 모든 장애 가능성에 대한 인지를 위해 Observability가 선행되어야 합니다. │Observability와 Monitoring 차이점 그렇다면 기존의 모니터링(Monitoring)과 옵저버벌리티(Observability)의 차이점은 무엇일까요? 기존의 모니터링 역할은 IT 인프라의 '정상 작동 확인'을 위한 도구 역할에 초점이 맞춰져 있었습니다. 모니터링 구성 요소인 대시보드와 사용자 알람을 통해 가시성을 확보하고, 장애를 쉽게 감지할 수 있었죠. 즉 모니터링은 인프라 성능 지표, 구성 관리, 사용자 알람에 주 목적을 둔 IT 운영 담당자에 포커스를 맞춘 도구입니다. Observability는 기존 모니터링이 맡는 알람(Alerting), 메트릭(Metric) 외에도 로그(시스템, 애플리케이션), 트레이스, 디버깅과 같은 작업이 가능합니다. 이를 통해 앞으로 발생할 수 있는 장애를 미리 예측하고, 발생한 장애에 대한 근본적인 원인을 찾아내는 데 초점이 맞춰져 있습니다. │Observability 확보를 위한 핵심 구성 요소 옵저버빌리티는 앞서 언급했듯이 메트릭(Metric), 로깅(Logging), 트레이싱(Tracing) 등 작업이 가능한데요. 좀 더 자세히 살펴보겠습니다. Metric 모니터링 분야에서 Metric(메트릭)이란, 인프라 혹은 서비스 성능과 상태를 나타내는 지표입니다. 여기서 중요한 점은 단순히 현재 상태를 보기 쉽게 표현하는 것에서 더 나아가 '시계열 데이터' 형태로 변화하는 데이터를 보여줘야 합니다. 예를 들어 CPU 사용률, 메모리 사용률, 스레드 사용률과 같이 시간이 지남에 따라 어떻게 변화하는지 효율적으로 보여줄 수 있어야 하죠. 또한 메트릭은 여러 AI 분석툴과 오픈소스와 결합하여, 직관적인 파라미터를 통해 시계열 데이터의 다양한 패턴을 자동 감지할 수 있어야 합니다. 운영자와 개발자에게 필요한 리소스를 선택할 수 있도록 성능 예측하는 지표도 필요합니다. Logging Logging(로깅)은 운영 중인 시스템과 애플리케이션에서 발생하는 다양한 이벤트와 에러 등을 기록하는 과정입니다. Observability는 여기서 더 나아가 클라우드 시스템의 모든 로그를 수집하여, 해당 로그를 통해 문제 원인을 식별할 수 있어야 합니다. 물론 각 로그 스트림은 단일 인스턴스에 대한 이벤트를 알려주기 때문에, 마이크로 서비스 환경에서 전체적인 문제 원인을 파악하기 어려울 수 있습니다. 하지만 중앙 집중식 로깅을 사용하면, 애플리케이션 로그를 한곳에 저장할 수 있습니다. 이를 통해 여러 서비스로 구성된 MSA 환경에서 로그를 효과적으로 검색하고 모니터링할 수 있죠. 이러한 작업을 하기 위해서 ELK Stack1 과 같은 로그 수집 활용 도구가 필요한데요. 이 도구는 로그 관리를 단순화화여, 전체 시스템 문제를 더 쉽게 분석할 수 있도록 도와줍니다. *ELK Stack1: Elastic Search. Logstash, Kibana의 약자로 데이터를 수집하고 분석하는 도구 모음 Tracing 트레이싱은 애플리케이션 실행 정보를 기록하는 '특별한 로깅' 방식을 의미합니다. 사실 로깅과 트레이싱을 구분하는 것에 큰 의미는 없습니다. 하지만 Observability 관점에서 트레이싱은, 전체 로그 중 문제를 일으키는 특정 로그들을 시각화하고 이를 선택적으로 관찰하는데 의미가 있습니다. Debugging Observability에서 말하는 디버깅은, 시스템과 서비스 성능을 확인하고 검사할 수 있는 다양한 도구입니다. 장애 원인을 찾을 경우 그 장애 원인뿐만 아니라, 연관관계를 가진 여러 인프라와 애플리케이션을 함께 보여줄 수 있어야 하죠. RUM RUM은 Real User Monitoring 약자로, 사용자의 인터랙션을 추적하여 웹사이트나 애플리케이션 성능을 실시간으로 모니터링하는 기술입니다. 옵저버빌리티는 앞서 언급했듯, 더 이상 IT 인프라 운영자를 위한 도구가 아닙니다. DevOps를 위한 통합적인 가시성을 제공하는 도구이죠. 따라서 운영자와 개발자를 위한 '실제 사용자 관점'에서 모니터링을 제공해야 합니다. 이처럼 옵저버빌리티 시스템은 애플리케이션의 전체적인 상태를 깊이 있게 파악하고, 문제 원인을 분석하는 데 중점을 두는 접근 방식입니다. 그렇다면 애플리케이션 성능 관리 시스템인 APM 도구와는 어떤 차이점이 있을까요? │APM과 Observability 차이점 어떻게 보면 APM과 Observability는 비슷해 보이지만, 문제 원인과 인프라를 분석하는 시각에 따라서 다양한 차이점을 지니고 있습니다. 우선 첫 번째 차이점으로는 모니터링 목적 대상에 따른 차이가 있습니다. APM은 E2E(End-to-End) 성능 구간에 주목합니다. WEB-WAS-DB에 걸친 이 과정을 실제 서비스 사용자의 *액티브 서비스2에 초점을 맞춰, 애플리케이션 성능을 분석하고 모니터링하죠. *액티브 서비스: 현재 시점에서 사용자에게 제공되고 있는 상태 Observability는 APM에서 주목하는 E2E보다, 더 많은 범위를 모니터링합니다. 시스템 인프라, WAS, DB에 대한 정밀 성능 분석과 장애 감지는 물론. 운영 중인 인프라와 서비스를 통합하여 문제 원인을 찾는 데 집중합니다. [그림] Zenius-APM 사용자 정의 실시간 모니터링 상황판 따라서 두 번째 차이점으로는, 측정하는 지표에도 많은 차이가 있는데요. APM은 사용자 요청에 따른 응답 시간과 응답 분포, 액티브 서비스 상태, 트랜잭션 처리율, 이슈 중심으로 '사용자 요청' 관점에 따라 주요 지표를 확인할 수 있습니다. Observability는 사용자의 요청 관점이 아닌, 발생할 수 있는 '모든 이벤트 지표'에 주목합니다. 보다 더 전방위적인 모니터링이 가능하죠. 또한 옵저버빌리티는 기존 APM에서 발생하는 주요 장애 원인뿐 아니라, 예측하지 못한 장애를 객관적인 지표로 보여줍니다. 정리한다면 인프라와 서비스를 분석하고 장애를 탐지한다는 점에서 APM과 Observability는 동일한 역할을 갖지만, 결국 사용자가 무엇을 더 초점에 맞추느냐에 따라 사용 목적은 아래와 같이 달라질 수 있습니다. 우리 기업은 Observability가 맞을까, APM가 맞을까? APM Type Observability Type 애플리케이션 성능 최적화가 필요한 경우 애플리케이션 코드 내의 문제를 식별하고 해결하는 데 중점을 둘 경우 MSA 환경이 아닌 모놀리식 아키텍처에서 서비스를 구성하고 있는 경우 MSA 환경에서의 분산 시스템을 통해 서비스를 구성하는 경우 단순한 애플리케이션 성능을 넘어 전체 IT 인프라 환경에 대한 통찰력 확보가 필요한 경우 인프라 운영자, 개발자, 보안담당자 모두가 통합 모니터링 환경이 필요한 경우 이번 글에서는 옵저버빌리티의 중요성과 APM의 차이점을 자세히 살펴보았습니다. 결론적으로 옵저버빌리티와 APM 중 어느 하나를 더 좋다고 할 수 없으며, 각 조직의 요구사항과 사용 편의성에 맞춰 선택해야 합니다. 그러나 점점 복잡해지는 IT 환경을 고려한다면, 옵저버빌리티를 기반으로 한 Zenius-APM과 같은 도구를 활용하여 좀 더 효율적으로 웹 애플리케이션을 관리해 보는 것은 어떨까요? ?더보기 Zenius APM 더 자세히 보기 ?함께 읽으면 더 좋아요 • APM에서 꼭 관리해야 할 주요 지표는?! • APM의 핵심요소와 주요기능은?!
2024.07.24
하이브리드 클라우드 모니터링, 왜 필요한가?
하이브리드 클라우드 모니터링, 왜 필요한가?
최근 하이브리드 클라우드가 점점 더 중요한 역할을 하고 있습니다. 하이브리드 클라우드(Hybrid Cloud)는 온프레미스 환경과 프라이빗 클라우드, 퍼블릭 클라우드를 결합한 클라우드 환경을 의미하는데요. 쉽게 말해 필요에 따라 자체 인프라와 외부 클라우드 서비스를 동시에 사용할 수 있는 클라우드 환경입니다. 2024년까지 하이브리드 클라우드 시장은 연평균 22% 성장하여 약 3조 원 규모에 이를 것으로 예상될 정도로 각광받고 있습니다. 그렇다면 하이브리드 클라우드가 점점 더 주목을 받는 이유는 무엇일까요? │하이브리드 클라우드가 각광받는 이유 하이브리드 클라우드가 점점 더 주목을 받는 이유는 유연함 때문입니다. 기업들은 중요한 데이터를 프라이빗 클라우드에 저장하고, 일시적으로 많은 자원이 필요한 작업은 퍼블릭 클라우드를 사용하여 두 가지 클라우드의 장점을 모두 누릴 수 있습니다. 보안과 성능을 유지하면서도 필요한 만큼 자원을 사용할 수 있는 것이죠. 즉 프라이빗 클라우드의 퍼블릭 클라우드를 잘 조화하면 기업은 최적의 IT 환경을 구축할 수 있습니다. 하이브리드 클라우드의 이러한 장점은, 기업들이 경쟁력을 유지하고 빠르게 변화하는 시장 환경에 대응하는 데 큰 도움이 됩니다. 특히 클라우드 서비스 제공업체(CSP)의 다양한 서비스와 솔루션을 활용하면, 하이브리드 클라우드를 더욱 효과적으로 운영할 수 있는데요. 다음 내용을 통해 주요 클라우드 서비스 제공업체에 대해 좀 더 자세히 알아보겠습니다. │주요 클라우드 서비스 제공업체(CSP) 특징 클라우드 서비스 제공업체(CSP)으로 대표적으로 AWS(Amazon Web Services)와 마이크로소프트(Microsoft Azure)가 있습니다. 다음 내용을 통해 각각의 주요 특징을 살펴보겠습니다. Amazon Web Services (AWS) AWS는 서버, 스토리지, 데이터베이스, 네트워크 등 다양한 IT 인프라 서비스를 제공하는 아마존의 클라우드 플랫폼입니다. "AWS의 서버가 먹통이 되면, 시장에 혼돈이 온다."는 말이 있을 정도로 많은 기업이 AWS를 사용하고 있죠. AWS의 주요 특징은 아래와 같이 정리해 볼 수 있는데요. AWS의 주요 특징 1. AWS의 글로벌 인프라 AWS는 CSP 중 전 세계에서 가장 많은 리전을 보유하고 있습니다. 31개의 리전과 99개의 가용 영역을 운영하여, 사용자가 원하는 리전을 선택해 지연 시간을 단축할 수 있습니다. 다양한 지역에서 리전을 운영하는 만큼, 서비스 제공 범위가 넓고 안정성도 높습니다. 또한 엣지 로케이션을 통해 콘텐츠를 빠르게 전달하여 사용자 경험을 개선합니다. AWS는 CSP의 선두주자로서 AWS는 IaaS(인프라 서비스) 영역에서 시장 점유율이 가장 높고 안정적인 서비스를 제공합니다. 2. API 기반 서비스 AWS의 모든 서비스는 API를 통해 제어할 수 있으며, 다양한 프로그래밍 언어에서 사용 가능한 코드를 제공하여 다른 서비스를 연동할 수 있습니다. API Gateway라는 서비스를 통해 외부 애플리케이션과의 통신을 안전하게 관리할 수도 있죠. 3. 다채로운 서비스 AWS는 단순히 서버와 저장소를 제공하는 것을 넘어 S3(객체 스토리지), EC2(가상 서버), Lambda(서버리스 컴퓨팅), RDS(관계형 데이터베이스) 등 다양한 주요 서비스를 지원합니다. 최근에는 머신러닝과 AI 서비스까지 제공하고 있습니다. Microsoft Azure Microsoft Azure는 마이크로소프트가 제공하는 클라우드 컴퓨팅 플랫폼으로, AWS 다음으로 많은 기업들이 사용하고 있습니다. 애저라고도 많이 불리죠. 특히 PaaS(Platform as a Service)와 SaaS(Software as a Service) 분야에서 1위를 달리는 퍼블릭 클라우드라고 할 수 있습니다. Azure의 주요 특징은 다음과 같은데요. Microsoft Azure 주요 특징 1. Microsoft 제품과의 통합성 Azure의 가장 큰 장점은 Microsoft 제품과 쉽게 연동된다는 점입니다. 예를 들어 Office 365와 통합되며, 최근에는 생성형 AI 서비스인 Copilot 과의 통합으로 주목받고 있습니다. Microsoft 제품을 많이 사용하는 기업들에게 매우 유용하죠. 2. 웹 서비스에 집중 Azure는 특히 웹 서비스에 강점을 가지고 있습니다. 인프라(IaaS)에서는 다양한 유형을 수용하면서도, 애플리케이션 플랫폼(PaaS) 측면에서는 웹 서비스에 집중하고 있는데요. PC 웹, 모바일, API 등 모든 접속 유형을 하나의 앱 서비스에서 지원하며 가상 머신, 컨테이너, 서버리스 등 다양한 구성 방식을 제공합니다. 이처럼 AWS와 Microsoft Azure는 각각 고유한 강점을 가지고 있으며, 기업의 필요에 따라 적절한 서비스를 선택하여 사용할 수 있는데요. 하지만 이러한 다양한 클라우드 서비스의 특징과 이점을 제대로 활용하기 위해서는 클라우드 서비스 모니터링이 필수적입니다. 클라우드 인프라는 자원 사용량과 트래픽이 시시각각 변동되므로, 실시간 모니터링 없이는 문제를 사전에 발견하고 대응하기 어렵기 때문인데요. 다음 내용을 통해 어떤 솔루션이 필요한지 살펴보도록 하겠습니다. │하이브리드 클라우드 모니터링이 필요한 이유 앞서 언급한 내용처럼 AWS, Azure, GCP 등 다양한 퍼블릭 클라우드의 서비스 상태와 성능 지표를 확인하기 위해서는, 클라우드 서비스 모니터링 솔루션이 필요합니다. 물론 AWS의 *CloudWatch1처럼 자체적인 퍼블릭 클라우드 모니터링 도구들도 있는데요. * CloudWatch1 : AWS 클라우드 리소스를 모니터링하고 관리하는 서비스 통합적인 IT 환경에서 발생할 수 있는 다양한 문제를 예방하고 효율적으로 관리하기 위해서는, 퍼블릭 클라우드나 프라이빗 클라우드뿐만 아니라 온프레미스 인프라까지 함께 모니터링할 수 있는지 살펴보아야 합니다. 대표적인 사례로 Zenius CMS 솔루션을 통해, 어떤 방식으로 클라우드 서비스를 모니터링할 수 있는지 살펴보겠습니다. 하이브리드 클라우드의 통합 모니터링 Zenius CMS는 물리적인 서버, 네트워크 장비, DB와 같은 온프레미스 인프라와 퍼블릭 클라우드를 통합적으로 모니터링합니다. 사용자는 한 플랫폼 안에서 전체 인프라의 상태를 종합적으로 신속하게 장애를 파악할 수 있기 때문에, 다양한 환경에서 발생하는 성능 저하와 장애를 빠르게 식별하고 그 원인을 정확히 분석할 수 있죠. CloudWatch와 Alert History를 사용한 데이터 수집 Zenius CMS는 AWS의 CloudWatch나 Azure의 Alert History 같은 API를 사용해서 다양한 모니터링 데이터를 제공합니다. 예를 들어 CloudWatch가 기본적으로 제공하는 성능 지표뿐만 아니라 특정 서비스에 관심이 있다면, 그 서비스만 타겟으로 설정해서 모니터링할 수 있습니다. 이렇게 하면 사용하는 지역의 주요 서비스들만 선택해서 볼 수 있어, 필요한 정보를 더욱 쉽게 확인할 수 있는 장점이 있습니다. Billing(과금) 서비스 정보 제공 Zenius CMS를 통해 클라우드 자원의 사용량을 실시간으로 확인하여 예산을 더 잘 관리하고, 예상치 못한 과금이 발생하는 것을 막을 수 있습니다. 또한 비용이 어떻게 발생하는지 투명하게 파악할 수 있어 필요할 때 적절히 조정할 수 있죠. 자동 경고 기능을 통해 특정 비용 한도를 초과할 때 즉시 알림을 받아 효율적으로 관리할 수 있습니다. 이번 시간에는 하이브리드 클라우드 모니터링이 왜 중요해지고 있는지 중점적으로 알아보았습니다. 특히 클라우드 인프라는 자원 사용량이 수시로 변하기 때문에 실시간 모니터링이 중요합니다. 더불어 다양한 인프라를 통합 관리할 수 있는 온프레미스 환경도 함께 구축되어 있어야, 클라우드 인프라에 문제가 발생했을 때 빠르고 정확하게 대응할 수 있죠. 이제 하이브리드 클라우드 통합 관리와 온프레미스 환경 관제가 모두 가능한 Zenius CMS로, 클라우드 서비스를 더욱 효율적으로 관리해 보세요!
2024.07.29
하이브리드 클라우드의 5가지 도전과제
하이브리드 클라우드의 5가지 도전과제
클라우드를 활용하는 기업들은 일반적으로 하이브리드 클라우드 환경을 구성합니다. 단일 클라우드 환경에 비해서 여러 가지 장점이 있기 때문입니다. 하이브리드 클라우드는 멀티 클라우드의 일종입니다. 멀티 클라우드(Multi Cloud)는 하나 이상의 클라우드 환경을 병행하여 활용하는 것을 의미합니다. 클라우드 환경이 퍼블릭이든 프라이빗이든 상관없습니다. 멀티 클라우드는 특히 퍼블릭 클라우드 서비스를 활용할 때 하나의 서비스 제공업체에 종속되지 않고, 각 서비스의 특화된 기능을 조합하여 성능과 비용 효율성을 극대화하기 위해서 주로 활용됩니다. 하이브리드 클라우드(Hybrid Cloud)는 반드시 하나 이상의 퍼블릭 클라우드와 프라이빗 클라우드(또는 온프레미스 인프라)를 함께 사용하는 방식을 일컫습니다. 이 방식은 프라이빗 클라우드의 높은 보안성과 퍼블릭 클라우드의 유연한 확장성을 동시에 활용할 수 있다는 장점이 있습니다. 예를 들어 보안 유지와 규제 준수가 요구되는 민감한 데이터는 프라이빗 클라우드에 안전하게 저장하고, 트래픽의 변동성이 커서 유연성과 확장성이 필요한 서비스는 퍼블릭 클라우드에서 처리하는 방식입니다. 이를 통해 기업은 데이터 보안과 확장성 간의 균형을 유지하며, 비용을 절감할 수 있습니다. 레거시 환경에서부터 출발하여 클라우드 전환을 실행한 대부분의 조직들은 이와 같은 하이브리드 클라우드 환경을 갖추고 있다고 볼 수 있습니다. 두 개 이상의 퍼블릭 클라우드 서비스와 기업 내부의 프라이빗 클라우드 시스템 또는 온프레미스 시스템을 동시에 활용하기 때문입니다. 그러나 이러한 하이브리드 클라우드 장점을 최대한 활용하려면 몇 가지 도전 과제가 있습니다. 이 과제들을 어떻게 해결하느냐에 따라 하이브리드 클라우드의 성공적인 도입과 운영이 좌우됩니다. 이러한 도전 과제들에 대해 자세히 살펴보겠습니다. 통합 운영 및 자동화 체계 구축 각 클라우드 환경은 서로 다른 가상화 기술을 기반으로 운영되기 때문에, 이를 하나의 통합된 인터페이스에서 관리하려면 고유한 관리 도구와 API를 통합하고 상호 호환성을 확보하는 작업이 필수입니다. 또한, 클라우드 간에 워크로드를 자유롭게 이동하거나 자원을 효율적으로 관리하려면 일관된 오케스트레이션 체계를 구축해야 하지만, 각 클라우드가 고유의 관리 프로토콜을 사용하기 때문에 이를 통합하는 과정에서 기술적인 어려움이 발생할 수 있습니다. 이와 같은 통합 문제는 자동화 시스템 구축에서도 큰 난제로 작용합니다. 퍼블릭 클라우드의 오토스케일링(Auto Scaling)이나 리소스 프로비저닝(Resource Provisioning)과 같은 기능은 퍼블릭 클라우드에 특화된 기술로, 이를 프라이빗 클라우드에 동일하게 구현하는 것에도 어려움이 따릅니다. 이러한 기술적 차이를 해결하기 위해서는 양쪽 클라우드 환경을 통합하는 자동화 시스템을 설계해야 하며, 이 과정에서 복잡한 기술적 이슈가 제기될 수 있습니다. 예를 들어 퍼블릭 클라우드의 확장성과 유연성을 프라이빗 클라우드에서도 동일하게 적용하려면, 각 환경에 적합한 자동화 규칙과 관리 프로세스를 개발해야 합니다. 하지만 이 과정에서 많은 리소스와 시간이 요구되며, 결국 운영 효율성을 저하시키고, 자동화 시스템의 불완전함으로 인해 운영자의 수동 개입이 필요하게 되는 상황을 초래할 수 있습니다. 데이터 관리 하이브리드 클라우드 환경에서의 데이터 관리는 이동성, 일관성, 보존, 거버넌스 등 다양하고 복잡한 과제가 따릅니다. 특히 데이터가 여러 물리적 위치에 분산되어 저장하고 처리되기 때문에 모든 위치에서 일관된 상태를 유지하는 것이 어렵습니다. 예를 들어 프라이빗 클라우드에서 수정된 데이터가 퍼블릭 클라우드와 즉시 동기화되지 않을 경우, 데이터 불일치가 발생할 수 있으며 비즈니스 프로세스에 중대한 영향을 줄 수 있습니다. 또한 클라우드 간의 데이터 이동은 네트워크 성능에 크게 의존합니다. 대용량 데이터를 전송할 때 네트워크 지연이 발생하면 시스템 성능이 저하될 수 있으며, 특히 실시간 데이터 처리가 중요한 애플리케이션에는 이러한 지연이 심각한 성능 문제로 이어질 수 있습니다. 따라서 실시간 데이터 처리 환경에서는 네트워크 대역폭을 최적화하고 지연 시간을 최소화하는 것이 핵심 과제이며, 이를 제대로 해결하지 못하면 비즈니스의 신속한 의사 결정과 대응 능력이 저하될 수 있습니다. 추가적으로 데이터를 여러 클라우드 환경에 복제하여 관리할 경우, 불필요한 데이터 중복이 발생할 수 있어 스토리지 비용이 크게 증가할 수 있습니다. 이러한 비용 증가를 방지하려면 철저한 데이터 복제 정책과 함께 효율적인 스토리지 관리 전략을 반드시 수립해야 합니다. 비용 관리 하이브리드 클라우드는 유연한 비용 구조를 제공하지만, 이를 효과적으로 관리하지 못할 경우 비용이 급격히 증가할 수 있습니다. 프라이빗 클라우드와 퍼블릭 클라우드는 서로 다른 방식으로 비용을 책정하기 때문에, 이를 통합 관리하는 것은 쉽지 않은 일입니다. 특히 퍼블릭 클라우드는 사용한 만큼 요금을 부과하는 구조라서, 예상치 못한 리소스 사용이나 자원의 과도한 할당이 발생하면 비용이 급격히 증가할 위험이 있습니다. 반면, 프라이빗 클라우드는 고정된 인프라 유지 비용이 지속적으로 발생하기 때문에 두 환경의 비용을 동시에 효율적으로 통제하지 않으면 예기치 못한 지출로 이어질 수 있습니다. 따라서 이러한 이질적인 비용 모델을 결합해 장기적으로 비용을 예측하고 최적화하는 것이 매우 까다롭습니다. 워크로드의 특성에 따라 어느 환경이 더 비용 효율적인지를 판단하는 리소스 최적화 역시 복잡성을 더하는 요소입니다. 모든 워크로드가 퍼블릭 클라우드에서 비용 효율적인 것은 아니며, 프라이빗 클라우드에서 더 적합한 워크로드도 존재하기 때문에 이러한 선택이 적절히 이루어지지 않으면 불필요한 비용이 발생할 수 있습니다. 네트워크 관리 하이브리드 클라우드 환경에서 네트워크 성능은 시스템 전반의 안정성과 효율성이 직결되는 핵심 요소입니다. 프라이빗 클라우드와 퍼블릭 클라우드 간에 데이터 전송 시, 물리적 거리에 따른 네트워크 지연(latency)이 발생할 수밖에 없습니다. 이러한 지연은 대규모 데이터 처리 애플리케이션이나 실시간 트랜잭션을 요구하는 워크로드에서 치명적인 성능 저하를 초래할 수 있습니다. 이러한 문제를 완화하기 위해 네트워크 경로 최적화, 지능형 트래픽 관리 및 QoS(Quality of Service) 설정과 같은 고급 네트워크 성능 튜닝이 필요합니다. 또한 하이브리드 클라우드 환경에서 빈번하게 발생하는 대규모 데이터 전송은 대역폭 제한을 초래할 수 있습니다. 적절한 네트워크 프로비저닝과 데이터 압축, 캐싱 기법을 적용하지 않으면 네트워크 병목현상이 발생하여 시스템 성능에 부정적인 영향을 미칠 수도 있습니다. 더불어 네트워크 장애는 클라우드 서비스 전체에 심각한 중단을 일으킬 수 있기 때문에, 이를 예방하고 빠르게 복구할 수 있는 사전 준비가 필요합니다. 장애에 대비하려면 고가용성(HA) 네트워크 설계, 자동으로 장애를 감시하는 시스템, 그리고 멀티패스(multipath) 라우팅 같은 복구 방법을 적용해야 합니다. 하지만 이러한 작업은 여러 네트워크 계층이 얽혀 있고, 클라우드 시스템 간 상호작용이 복잡하기 때문에, 높은 기술력과 체계적인 관리를 필요로 합니다. 보안 및 규제 준수 프라이빗 클라우드와 퍼블릭 클라우드라는 이질적인 환경에서 데이터를 동시에 관리하고 보호해야 하기 때문에, 다양한 보안 위협과 복잡한 규제 요구사항을 충족시키는 것이 기술적으로 까다롭습니다. 특히 프라이빗 클라우드에서는 기업이 자체적으로 설정한 보안 정책과 방화벽, 액세스 제어 등을 사용할 수 있습니다. 반면 퍼블릭 클라우드에서는 클라우드 서비스 제공자가 제공하는 보안 프로토콜과 방어 체계가 의존해야 하므로, 이 두 환경을 일관되게 통합해 운영하는 것이 매우 복잡합니다. 데이터 보호 측면에서 암호화와 키 관리가 중요한 역할을 하지만, 각 클라우드 플랫폼이 사용하는 암호화 표준 및 키 관리 프로토콜이 상이할 수 있어 이를 일관되게 적용하는 것도 중요한 이슈입니다. 또한 하이브리드 클라우드 환경에서 규제를 준수하는 것은 매우 중요한 문제입니다. 그러나 데이터가 저장된 국가나 지역마다 규제 요구사항이 다르기 때문에, 모든 규정을 충족하는 것이 어려울 수 있습니다. 예를 들어 유럽연합의 GDPR, 미국의 HIPAA 같은 규제를 준수해야 하는 경우 퍼블릭 클라우드 제공자가 데이터가 저장하는 위치나 처리 방식을 명확하게 제공하지 않으면 규제 위반 가능성이 높아질 수 있습니다. 따라서 데이터 주권을 유지하기 위한 데이터 로컬리티 정책을 엄격하게 설정하고, 이를 지속적으로 모니터링하여 규제 준수 여부를 확인하는 추가적인 노력이 필요합니다. 하이브리드 클라우드의 성공적인 운영은 앞서 설명한 다섯 가지 핵심 과제들을 '얼마나 효과적으로 해결하느냐'에 달려 있습니다. 클라우드 간의 통합 관리, 비용 효율적인 운영, 그리고 보안 및 규제 준수의 문제는 단순히 기술적 과제일 뿐만 아니라 기업의 전략적 의사결정과도 깊이 연관되어 있습니다. 따라서 이러한 문제에 대한 종합적인 접근과 체계적인 해결책이 필요합니다.
2024.10.08
인턴 은서님의 자유롭고 따뜻했던 브레인즈 생활기
인턴 은서님의 자유롭고 따뜻했던 브레인즈 생활기
지난 1월, 경영기획실에 대학생 인턴 은서님이 첫 출근을 했습니다. 곧 졸업을 앞두고 있지만, 아직 진로를 결정하지 못해 고민이라던 은서님은 이번 인턴 활동으로 졸업 후 청사진을 그려볼 수 있었다는데요. 은서님이 브레인즈컴퍼니에서 어떤 경험을 해봤길래, 미래 계획을 세울 수 있었을까요? 두 달간의 따뜻했던 브레인즈 생활기, 함께 들으러 가시죠! ------------------------------------------------------- Q. 안녕하세요, 은서님. 자기소개 부탁드립니다. 안녕하세요, 브레인즈컴퍼니 경영기획실 HR인턴 박은서입니다. 벌써 약 두 달간의 인턴 생활이 끝나다니, 시간 참 빠른 것 같아요. Q. 인턴 기간 동안 브레인즈에서 어떤 업무를 했나요? 채용 관련 업무를 담당했어요. 주로 서류와 면접전형 심사에 참관한 후 합격자와 불합격자를 관리하는 업무를 했고요. 개발자 직군 채용에 도움이 될 수 있도록 ‘개발자 특집 인터뷰’를 진행하기도 했어요. 그 외에도 브레인저들의 주거 복지와 관련한 업무도 경험해봤습니다. Q. 가장 기억에 남는 업무나 뿌듯했던 순간이 있을까요? ‘넷플릭스 기업 문화가 한국에서도 통할까’라는 주제로 기업문화 TF 회의에서 발표했을 때요. 브레인즈컴퍼니는 행복한 회사를 만들기 위해 기업문화 TF인 ‘YB(Young Brainz)’를 운영 중인데요. YB팀은 일주일에 한 번씩 회의를 열어 브레인즈컴퍼니의 기업문화를 개선해 나가고 있습니다. 이 회의에서 제가 자료를 서치하고 직접 만든 PPT로 발표할 기회를 가질 수 있었는데요. 넷플릭스가 구축한 새로운 기업문화에 대해 이야기하고, 국내 6곳의 기업(메리츠 화재, 우아한 형제들, CJ ENM, 비바리퍼블리카, 와디즈, 렌딧)이 넷플릭스의 기업문화를 어떻게 벤치마킹하고 있는지에 대해 발표했어요. 나아가 영업부서와 함께 브레인즈컴퍼니는 이를 어떻게 적용해볼 것인지 함께 고민하는 시간도 가질 수 있었답니다. 차후에 YB팀 분들이 자료를 활용할 수 있도록 따로 전달 드렸고, 실무에 참고하고 있다는 얘길 들어 참 뿌듯하고 기뻤던 것 같아요. Q. 브레인즈컴퍼니의 근무 환경은 어땠나요? 근무 환경에 대해 느낀 3가지는, “무엇이든 할 수 있는 곳”이라는 것과 “누워서도 쉴 수 있을 정도의 자유로운 분위기” 그리고 “브레인저와 소통하는 선근님”입니다. 앞서 언급한 기업문화 TF에서 자유롭게 제 목소리를 낼 수 있다는 점에서 알 수 있듯이, 브레인즈컴퍼니는 직급에 상관없이 하고 싶은 업무가 있다면 해볼 수 있는 분위기더라고요. 인턴도 단순 업무가 아닌 해보고 싶은 일이 있다면 바로 주전 선수로 뛸 수 있었어요. 브레인즈컴퍼니 8층에는 라운지가 있는데요. 이 라운지는 음악이 흘러나오고, 소파와 책, 음료수가 비치돼 있어 카페테리아를 연상케 해요. 쿠션이나 쇼파에 몸을 눕다시피 기대고 쉬는 분도 봤어요. 마지막으로 선근님과 직원 간의 1:1 소통이 인상깊었는데요. 요청사항이 있거나 회사에서 하고 싶은 프로젝트가 있으면, 중간관리자를 거치지 않고 바로 선근님과 미팅룸에서 가볍게 대화를 나누기도 하더라고요. 저한테는 매우 신기한 풍경이었어요. Q. 브레인즈컴퍼니에서 근무하며 가장 좋았던 점은 무엇인가요? 직원 분들이 모두 좋았다는 점이었어요. 특히 제 사수님이 저를 너무 잘 챙겨주셔서 감사했어요. 사실 처음으로 직장생활을 하다 보면, 일하다 모르는 부분이 있어도 어디서부터 어디까지 여쭤봐야 하는지 감이 안 잡혀서 곤란할 때가 있거든요. 그런데 물어봐야 하나 말아야 하나 고민하기도 전에 먼저 알아봐 주시는 세심함에 놀랐어요. 연차가 있으신 임원들도 성품이 부드러웠고, 일 외에도 학교 생활이나 일상에도 관심을 가져 주셔서 참 따뜻한 곳이라고 느껴졌어요. 또 브레인즈컴퍼니는 아침식사가 항상 제공되는데, 아침에 출근하면 꼭 먹고 근무하라고 신신당부해주셨어요. Q. 첫 직장생활을 해보며, 직장인으로서 느낀 고충과 이점에 대해 얘기해주세요. 고충이라고 한다면, 첫 사회생활이다 보니 다소 낯설었다는 점이요. 처음이다 보니 모든 것이 어색하고, 기존의 삶과는 생활 패턴이 다르다 보니 적응하는데 시간이 좀 걸렸던 것 같아요. 특히 아침에 아주 일찍 일어나 지옥철을 뚫고 출근하는 길이 참 힘들었던 것 같네요. 직장인들이 새삼 대단하다고 느꼈어요. 이점은 그만큼 사회인으로서 성장할 수 있는 기회를 얻을 수 있었다는 것이요. 저는 졸업 전 방학 기간에 인턴을 했던 터라, 인턴십 프로그램이 끝나면 다시 학교로 돌아가야 하는데요. 학교로 돌아갔을 때, 앞으로 진로를 위해 무엇을 준비해야 하는지 구체적으로 알게 됐어요. 미래를 계획하는 데에 있어 경험을 제공해 준 브레인즈컴퍼니에게 감사드릴 뿐입니다. Q. 다음에 들어올 인턴에게 해주고 싶은 조언은? 적극적으로 업무를 추진하라고 조언하고 싶어요. 사실 첫 직장생활이다 보니, 제 업무의 범위가 어느 정도인지, 어떤 안건에 대해 의견을 제시해도 되는지 망설여질 때가 있는데 브레인즈컴퍼니는 언제나 열려 있더라고요. 생각 이상으로 제 의견을 충분히 반영해줬어요. 인턴십 프로그램은 기간이 짧기 때문에 주어진 시간 안에 일을 효율적으로 배우려면 거침없이 묻고, 업무 외에도 관련된 것들을 추가적으로 찾아보고 도전해봐야 한다고 생각합니다. Q. 퇴사 후 앞으로의 계획은? 퇴사 후에는 일단 다시 대학생의 신분으로 돌아가 학교 생활을 즐길 계획입니다. 학업에 더 집중하되, 브레인즈컴퍼니에서 배운 것들을 바탕으로 관련 대외활동이나 기자단을 하면서 진로를 구체화할 예정입니다. 제 첫 직장이 브레인즈컴퍼니여서 행복했어요! 브레인저 모두 감사했습니다!
2022.08.18
다음 슬라이드 보기