기술이야기 | 브레인즈컴퍼니

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

메인 페이지로 이동
블로그
기술이야기

블로그

기술이야기

기술이야기 서버 모니터링 솔루션 유형별 장단점과 선택 기준은? 기술이야기 서버 모니터링 솔루션 유형별 장단점과 선택 기준은? 지난 글에서는 서버 자원과 성능 데이터 수집, 장애 탐지와 알림, 서버 간 연관관계 분석, 운영 활용성, 하이브리드 환경과 보안 대응 등 서버 모니터링 솔루션을 도입하기 전에 확인해야 할 5가지 선택 기준을 살펴봤습니다. 실제 솔루션을 선택할 때는 기능뿐 아니라 도입 및 운영 방식의 차이도 고려해야 합니다. 오픈소스 도구를 내부에서 직접 구축할 수도 있고, 공급사가 운영하는 SaaS를 이용하거나 상용 솔루션을 기업이나 기관의 환경에 구축할 수도 있습니다. 방식에 따라 필요한 내부 기술 역량과 데이터 관리 방법, 비용이 발생하는 지점, 공급사의 기술지원 범위가 달라집니다. 그렇다면 서버 모니터링 솔루션은 도입 및 운영 방식에 따라 어떤 차이가 있을까요? 대표적으로 활용되는 오픈소스 직접 구축, SaaS 이용, 상용 솔루션 구축 방식의 특징과 장단점을 살펴보고, 조직의 서버 환경과 운영 여건에 맞는 방식을 선택하려면 무엇을 확인해야 하는지 자세히 알아보겠습니다. 1. 오픈소스 서버 모니터링 구축에는 어떤 역량이 필요할까? 오픈소스 직접 구축은 Zabbix, Prometheus, Grafana와 같은 도구를 기업이나 기관의 인프라에 설치하고, 서버 모니터링 체계를 자체적으로 구성·운영하는 방식입니다. Zabbix처럼 데이터 수집과 저장, 시각화, 알림 기능을 비교적 통합적으로 제공하는 제품을 사용할 수도 있고, Prometheus와 Grafana처럼 역할이 다른 도구를 조합할 수도 있습니다. 여러 도구를 함께 사용한다면 개별 기능보다 서버에서 수집한 데이터가 저장과 시각화, 알림으로 어떻게 연결되는지를 먼저 설계해야 합니다. 가장 큰 장점은 조직의 서버 환경에 맞춰 수집 대상과 데이터 저장 구조, 대시보드와 알림 정책을 자유롭게 구성할 수 있다는 점입니다. 소프트웨어 라이선스 비용 부담을 낮출 수 있고, 공개된 플러그인과 연동 도구를 활용해 지원하는 OS와 수집 항목을 확장할 수도 있습니다. 반면 패치와 업그레이드, 백업, 이중화, 용량 관리 등 모니터링 플랫폼의 운영 전반을 자체적으로 담당해야 합니다. 또한, 여러 도구를 조합해 사용하게될 경우에는 구성요소 간 버전 호환성을 확인하고, 데이터 수집이나 알림에 문제가 발생했을 때 원인이 발생한 구간도 직접 분석해야 합니다. Zabbix의 기술지원 구독이나 Grafana Enterprise 같은 유료 서비스를 이용해 운영 부담을 보완할 수 있지만, 지원 범위에 포함되지 않는 서버와 데이터베이스, 스토리지 등의 기반 인프라는 여전히 내부에서 관리해야 할 수 있습니다. 따라서 내부 운영팀이 맡을 영역과 외부에서 지원받을 범위를 명확히 나누고, 담당자가 바뀌어도 운영을 이어갈 수 있도록 설정 기준과 변경·복구 절차를 문서화해야 합니다. 따라서, 오픈소스로 직접 구축하기 전에는 다음 사항을 점검하는 것이 좋습니다. 플랫폼 구축·업데이트·장애 대응을 담당할 인력 확보 여부 수집·저장·시각화·알림 도구 간 연동 구조 백업·복구·이중화 및 장기 데이터 보관 방안 서버 증가에 따른 데이터 처리 성능과 저장 용량 공식 기술지원 또는 전문 파트너의 지원 범위와 비용 설정 근거와 변경 이력을 관리할 문서화 체계 결국 오픈소스 방식에서는 개별 도구의 기능보다 전체 모니터링 플랫폼을 지속적으로 운영할 수 있는 인력과 절차를 갖추고 있는지가 중요한 선택 기준이 됩니다. 2. SaaS 방식의 서버 모니터링 솔루션은 어떤 환경에 적합할까? SaaS 방식은 공급사가 운영하는 클라우드 플랫폼을 이용해 물리·가상·클라우드 서버를 모니터링하는 방법입니다. 고객은 서버에 Agent를 설치하거나 클라우드 서비스를 연동해 데이터를 전송하고, 웹 기반 플랫폼에서 서버의 성능과 장애 현황을 확인할 수 있습니다. 대표적인 SaaS 모니터링 제품 중 하나인 Datadog은 호스트와 컨테이너, 프로세스의 성능 데이터를 하나의 플랫폼에서 확인할 수 있도록 지원합니다. 다양한 클라우드 서비스와 연동할 수 있으며, 기본 제공 대시보드를 활용해 비교적 빠르게 모니터링을 시작할 수 있습니다. 서버 인프라 모니터링으로 시작한 뒤 필요에 따라 로그 분석이나 APM으로 관리 범위를 확장할 수도 있습니다. 중앙 플랫폼과 데이터 저장소를 직접 구축하지 않아도 된다는 점은 SaaS 방식의 주요 장점입니다. 여러 지역과 클라우드에 분산된 서버를 한곳에서 확인할 수 있으며, 중앙 플랫폼의 업데이트와 운영도 공급사가 담당합니다. 다만 Agent의 설치와 업데이트, 데이터 수집 범위, 태깅 기준과 네트워크 설정은 고객이 관리해야 합니다. 서버와 서비스를 구분하는 태그가 일관되지 않으면 장애 영향 범위나 서버별 사용량을 정확하게 파악하기 어려울 수 있습니다. 따라서 도입 초기부터 조직과 서비스 구조를 반영한 태깅 기준을 마련해야 합니다. 데이터가 외부 플랫폼으로 전송되고 구독 항목이나 사용량에 따라 비용이 달라질 수 있다는 점도 SaaS 방식에서 중요하게 살펴봐야 할 부분입니다. 일부 서버만 연결한 PoC에서는 데이터 전송량과 비용이 실제 운영 환경보다 작게 보일 수 있으므로, 전체 서버와 데이터 수집 범위를 기준으로 예상 비용을 확인해야 합니다. SaaS 방식을 검토할 때는 다음 사항을 확인해야 합니다. 외부 플랫폼으로 전송되는 데이터의 종류와 민감정보 포함 여부 데이터 저장 지역과 보존·삭제 정책 Agent 및 클라우드 연동에 필요한 방화벽·프록시 등 외부 통신 조건 호스트·컨테이너·로그·메트릭별 과금 기준과 사용량 증가 시 비용 통제 방법 계약 종료 또는 플랫폼 변경 시 데이터·대시보드·탐지 정책의 이전 가능성 결국 SaaS 방식은 데이터 외부 전송이 가능하고, 자체 플랫폼의 구축 부담을 줄이면서 분산된 서버 환경을 빠르게 관리하려는 조직에 적합합니다. 도입 편의성뿐 아니라 고객이 담당해야 할 운영 범위와 데이터 관리 정책, 실제 사용량에 따른 비용을 함께 판단해야 합니다. 3. 구축형 상용 서버 모니터링 솔루션은 어떤 경우에 적합할까? 상용 솔루션을 구축하는 방식은 기업이나 기관의 데이터센터 또는 지정된 클라우드 환경에 모니터링 제품을 설치하는 방법입니다. 제품의 기본 기능과 공급사의 구축 경험을 활용하면서 데이터 저장 위치와 사용자 접근 방식을 내부 정책에 맞게 구성할 수 있다는 장점이 있습니다. 온프레미스와 클라우드 서버를 함께 운영하거나 다양한 OS와 서버 환경을 하나의 체계에서 관리해야 하는 조직에 적합합니다. 상용 구축 방식은 대시보드와 감시 정책, 알림, 보고서 및 조치 이력을 일정한 기준으로 관리하기에 유리합니다. 구축과 운영 과정에서 공급사의 기술지원을 활용할 수 있어 모니터링 플랫폼의 설치와 연동부터 장애 대응까지 모두 내부에서 담당하기 어려운 조직의 운영 부담을 줄일 수 있습니다. 다만 상용 제품이라도 현재운영 중인 OS와 서버, 가상화 및 클라우드 환경을 모두 기본으로 지원하는 것은 아닙니다. 제품 소개서의 지원 여부만 확인하지 말고 실제 사용 중인 버전과 수집 항목, 연동 방식까지 살펴봐야 합니다. 새로운 OS나 서버 환경을 추가할 때 별도의 연동 개발이나 추가 비용이 필요한지도 확인해야 합니다. 상용 솔루션을 실제 운영에 적용할 때는 여러 서버의 상태를 일관된 기준으로 파악하고, 장애 감지부터 분석과 조치까지의 과정을 하나의 흐름으로 연결할 수 있는지가 중요합니다. 예를 들어 브레인즈컴퍼니의 제니우스(Zenius)는 물리·가상·클라우드 서버에서 수집되는 성능 정보와 이벤트를 통합적으로 관리할 수 있도록 지원합니다. 서버 상태 파악과 감시 정책 적용, 장애 분석, 알림 및 조치 이력 관리를 하나의 운영 체계로 연결할 수 있다는 점이 주요 장점입니다. 이를 통해 서버와 운영 담당자가 늘어나는 환경에서도 공통된 기준에 따라 모니터링하고 장애에 대응할 수 있습니다. 이러한 장점을 바탕으로 제니우스는 다양한 서버 환경을 통합적으로 관리해야 하는 기업과 기관에서 활용되고 있습니다. 상용 솔루션을 구축하기 전에는 다음 사항을 확인해야 합니다. 실제 운영 중인 서버 OS와 가상화·클라우드 환경의 지원 범위 Agent·SNMP·API 등 서버 환경별 데이터 수집 방식 예상 서버 규모에 필요한 제품 서버·DB·스토리지 용량 새로운 OS나 서버 환경 추가 시 연동 개발과 추가 비용 발생 여부 라이선스·용량 증설·업그레이드·유지보수 기준 제품 장애 시 내부 운영팀과 공급사의 역할 및 대응 절차 망분리·폐쇄망에서의 라이선스 인증·업데이트·기술지원 방식 결국 상용 구축 방식에서는 현재 서버 환경에 필요한 기능을 지원하는지뿐 아니라, 서버 규모가 확대됐을 때도 제품의 처리 용량과 공급사의 지원 체계가 함께 대응할 수 있는지를 확인해야 합니다. 우리 조직에 맞는 서버 모니터링 방식은 어떻게 선택해야 할까? 서버 모니터링 방식을 선택할 때는 기능의 수보다 우리 조직의 운영 역량과 책임 범위를 먼저 살펴야 합니다. 플랫폼 구축과 유지관리, 데이터 관리, 장애 대응 중 내부에서 담당할 영역과 외부 플랫폼 또는 기술지원이 필요한 영역을 구분해야 합니다. 최종 선택 전에는 실제 서버 규모와 장애 대응 시나리오를 기준으로 솔루션을 검증해야 합니다. 관리 대상이 늘어나도 데이터 수집과 감시 정책, 알림이 안정적으로 운영되는지 확인하고, 내부 인력과 데이터 저장, 유지보수, 증설을 포함한 장기 비용도 비교해야 합니다. 결국 현재의 요구사항을 충족하는 데 그치지 않고, 서버와 데이터가 늘어난 이후에도 조직의 비용과 운영 체계 안에서 안정적인 모니터링과 장애 대응을 이어갈 수 있는 방식을 선택하는 것이 좋습니다. FAQ Q1. 오픈소스와 상용 모니터링 솔루션은 어떤 기준으로 선택해야 하나요? 기능 수나 라이선스 비용만으로 판단하기보다 조직의 운영 역량과 관리 환경을 먼저 살펴봐야 합니다. 관리 대상의 규모와 종류, 내부 전문 인력, 장애 대응 목표, 보안 정책, 향후 확장 계획이 주요 기준입니다. 아키텍처를 직접 설계하고 지속적으로 개선할 역량이 있다면 오픈소스의 유연성을 활용할 수 있습니다. 반면 다양한 인프라를 일관된 기준으로 관리하고 표준화된 운영 및 기술지원 체계가 필요하다면 상용 솔루션이 적합합니다. Q2. 오픈소스 솔루션은 상용 솔루션보다 비용을 절감할 수 있나요? 오픈소스는 라이선스 비용을 줄일 수 있다는 장점이 있습니다. 다만 구축과 연동, 서버 및 저장소 증설, 고가용성 구성, 업그레이드, 보안 패치 등에 필요한 비용도 함께 고려해야 합니다. 비교할 때는 최소 3년 이상의 총소유비용(TCO)을 기준으로 삼는 것이 좋습니다. 라이선스와 유지보수 비용뿐 아니라 내부 운영 인력의 투입 시간, 데이터 증가에 따른 인프라 비용, 장애 대응에 필요한 자원까지 포함해야 실제 비용 차이를 판단할 수 있습니다. Q3. 장애 대응 측면에서 오픈소스와 상용 솔루션은 어떤 차이가 있나요? 오픈소스 환경에서는 운영팀이 각 구성요소의 로그와 설정을 직접 분석해 장애 원인을 찾아야 합니다. 여러 도구가 연동된 경우에는 문제가 발생한 지점과 대응 범위를 구분할 수 있는 내부 분석 역량과 운영 절차가 중요합니다. 상용 솔루션은 장애 분석과 조치 과정에서 공급사의 기술지원 체계를 활용할 수 있다는 점이 차이입니다. 지원 시간, 초기 대응 기준, 원격·현장 지원 범위, 패치 제공 정책 등을 확인해 조직이 요구하는 장애 대응 수준과 맞는지 검토하는 것이 좋습니다. Q4. 상용 통합관리 솔루션을 검토하기 적절한 시점은 언제인가요? 관리 대상이 증가하면서 여러 모니터링 도구를 각각 유지하는 데 많은 시간이 들거나, 장애 분석이 특정 담당자의 경험에 의존하기 시작했다면 운영 체계를 점검할 시점입니다. 이기종 장비와 시스템을 함께 관리하거나, 24시간 관제와 일관된 장애 대응 절차가 필요한 환경에서도 통합관리의 필요성이 커집니다. 이 경우에는 개별 기능보다 통합 가시성, 운영 표준화, 확장성, 보안 정책 적용, 기술지원 범위를 중심으로 솔루션을 비교해야 합니다. 2026.09.08
기술이야기 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
기술이야기 벽을 넘어서고 싶은 신입 개발자의 브레인즈 생활기 기술이야기 벽을 넘어서고 싶은 신입 개발자의 브레인즈 생활기 지원 이유와 여정 대학교 졸업 후, 부족한 웹개발 역량을 쌓기 위해 5달간의 풀스택 부트캠프 교육을 수료하고 1달간의 기업 협업 인턴을 마쳤습니다. 이후, 제 역량을 마음껏 펼쳐내며 지속적으로 성장할 수 있는 회사에서 일하고 싶다는 생각이 들었습니다. 그러다 풀스택 기술뿐만 아니라, 빅데이터 및 AI 기술을 활용해 차세대 기술을 개발하는 브레인즈컴퍼니의 채용공고를 발견했습니다. 이 회사에서라면 많은 것을 배워 역량을 키우고 성장하며 일할 수 있겠다는 생각에 지원했고, 면접 끝에 첫 직장에 취업하게 됐습니다. 웹개발도 재밌지만 개발자로서 지속적으로 새로운 기술들을 습득하며 성장하는 것에서 성취감과 보람을 느끼는 것이 컸고, 그럴 수 있는 부서에서 첫 회사 생활을 시작할 수 있다는 생각에 기뻤습니다. 채용 과정 면접에서 기억에 남는 질문은 "우리 부서는 프론트엔드 보다 백엔드를 더 추구하는 편이라 함께 일을 하게 된다면, 프론트엔드와 백엔드 모두를 아울러 사용할 것인데 할 수 있습니까?"였습니다. 풀스택 개발자로서 일을 하게 된다는 질문이었고, 저는 이 부분에 대해 긍정적이었기 때문에 자신 있게 할 수 있다고 대답했습니다. 백엔드 개발자보다 많은 영역에서 발전하며 성장할 수 있다는 생각에 더욱 기대되고 설렜던 기억이 있습니다. 그렇게 저의 첫 직장 생활이 시작됐습니다. 입사 후, 지난 3달간의 일대기 채용이 된 후, 출근까지 2주간의 자유 시간이 주어졌습니다. 졸업 후 부트캠프 교육을 이수하면서 줄곧 달려왔고, 즐겁게 공부했지만 지쳐있는 심신을 달래기 위해 여행도 다녀오고 친구들과 가족들과 시간을 보내면서 출근 준비를 했습니다. 그렇게 2주 후 첫 출근을 하는 날이 됐고, 본격적으로 사원으로 근무하는 날이 다가왔습니다! 브레인즈컴퍼니의 개발 그룹은 1~5그룹으로 나눠져 있으며, 저는 개발4그룹에 소속됐습니다. 개발4그룹은 프론트엔드와 백엔드 개발뿐만 아니라, 빅데이터 및 AI 기술을 동원한 신기술 개발을 담당하고 있어, 배울 점도 많고 나아가야할 길도 멀리 펼쳐져 있다고 느꼈습니다. 1st Month_적응기 입사 첫 달은, 개발4그룹에서 집중적으로 개발 진행 중인 로그매니저와 Zenius AI의 제품 매뉴얼과 웹페이지에서 실제로 사용되고 있는 각각의 기능들을 학습하며 제품을 파악하고 익숙해지는 기간을 가졌습니다. 그렇게 한 달 간은 개발에 투입되기보다는 제품 및 사용된 기능들에 대한 학습과 공부를 하는 기간이었습니다. 단순히 제품의 매뉴얼만을 보며 학습을 했다면 집중도가 떨어졌을 수 있지만, 제품에서 사용하고 있는 다양한 기술들, Elasticsearch, Kibana, Kafka, Cluster 등 스택들에 대해 공부하면서 흥미와 재미를 느끼며 학습을 이어갈 수 있었습니다. 잘 몰랐던 신 기술들을 접하면서, 앞으로도 배우게 될 다양한 기술들에 대해 기대감이 부풀었던 한달이었습니다. 이외에도 학습을 진행하면서 원래 사용하던 스택인 JavaScript와 Linux의 Base부터 차근차근 다시 복습하며 결점을 보완하고, 제 자신을 Refactoring하기도 했던 한 달이었습니다. 2nd Month_개인정보 마스킹 기능 개발 입사 두 달째 부터는, 로그매니저와 Zenius AI의 기능들과 매뉴얼에 대해 전반적인 이해를 갖게 됐고, 각 사이트 기능들의 동작 원리 등을 대략적으로 파악할 수 있었습니다. 두 달이 된 이 시점부터 프론트엔드와 백엔드 모두를 사용하는 프로젝트가 주어졌습니다. 주어진 프로젝트는 ‘개인정보 마스킹 기능 개발’ 이었습니다. 로그매니저 내에서 수집되는 대용량의 로그들 안에 개인 정보가 포함될 경우가 있는데, 개인정보가 그대로 노출되는 것을 방지하기 위해 개인정보에 해당하는 정보는 마스킹처리를 자동적으로 진행하는 기능 개발을 진행하게 됐습니다. 예를 들어, 로그에 ‘961219-1234567’, ‘서울시 성동구 성수이로’, ‘010-1234-5678’ 등과 같은 주민등록번호, 주소, 연락처 뿐만 아니라 다양한 개인정보들을 지정한 특수문자(Default로는 *을 사용) 로 마스킹 처리를 해주는 기능을 개발하는 과정이 중점이 되는 프로젝트였습니다. 풀스택 공부를 하면서, 백엔드는 Node.js와 MySQL, PrismaOrm 등을 사용해 기능 개발을 진행했지만, 이번 프로젝트는 Elasticsearch, Kafka.js, Cluster.js 및 커스텀마이징된 다양한 메소드와 함수들을 통해 진행했기 때문에 배울 점이 매우 많았고, 성장하는 것을 느낄 수 있었습니다. 이외에도 프론트엔드에서 Ace.js를 통한 텍스트 편집기를 개발하고, 개인정보유형에 해당하는 정보가 입력되면 Syntax Highlighting 기능을 통해 해당 부분에 형광펜 효과를 적용시켜주는 기능의 개발을 진행했습니다. 개인정보 유형에 해당하는 정보에 대응되는 정규표현식, 그리고 백엔드에서 마스킹 처리될 특수문자 타입의 데이터 등은 Elasticsearch의 Index를 통해서 데이터의 저장과 반환작업 처리를 진행해줬으며, 이 데이터들을 기반으로 프론트엔드와 백엔드에서 모두 정상적인 마스킹 기능과 Syntax Highlighting 기능을 개발할 수 있었습니다. 새로운 기술을 활용해 프로젝트를 진행하면서 어려운 점도 많았고 시행착오도 겪었지만, 그만큼얻어가고 배워가는 것이 많았던 첫 업무였습니다. Elasticsearch, Kibana, Cluster, Kafka 등 새로운 기술 스택에 대해 배우고 적용할 수 있었다는 점이 매우 흥미로웠고 뿌듯한 경험이었습니다. <사진 설명: 개인정보 유형과 마스킹 여부, 정규표현식 관리와 마스킹 기능 ON/OFF가 가능한 페이지> <사진 설명: 선택한 개인정보 정규표현식에 해당되는 데이터 Syntax Hilighting 기능 구현> 3rd Month_데몬프로세스 그룹화 작업 및 테스트케이스 입사 세 달째 부터는, 어느 정도 회사 생활에 적응이 된 상태가 됐습니다. 아침 일찍 일어나는 것에도 적응이 됐고, 초반에는 어색했던 업무회의와 주간업무보고서 작성도 이제는 자연스럽게 하고 있는 모습을 발견할 수 있었습니다. 첫번째 프로젝트를 마친 후, 두번째로는 로그매니저의 데몬프로세스 기능을 그룹별로 정렬하는 업무를 맡게 됐습니다. 데몬프로세스가 각각의 그룹 속성을 지니고 있지만, 이를 그룹별로 나눠서 보여준다면 좀 더 가독성과 가시성이 높아질 것이기 때문에, Elasticsearch에서 반환 받는 데이터를 그룹의 조건에 따라 분류해주는 작업이 주가 됐습니다. 두번째 개발 후에는 로그매니저의 각 기능들에 대한 테스트 케이스 및 오류 사항 확인의 과정을 거쳤고, 제가 개발한 ‘개인정보 관리’ 기능에 대한 테스트 케이스 작성도 진행했습니다. 개발자가 개발을 잘하는 것도 중요하지만, 이렇게 자신이 개발한 기능에 대해 테스트케이스를 작성하면서 유저가 해당 테스트케이스를 확인하고, 개발한 기능을 자연스레 사용할 수 있게 해야 하는 것은 개발만큼이나 중요하다고 생각하기 때문에 기분 좋게 테스트케이스 작성을 진행할 수 있었습니다. 또, 로그매니저 제품 각 기술들의 테스트케이스들을 확인하며 각각의 기능들을 모두 테스트해볼 수 있는 기회가 됐으며, 개발하고 서비스되고 있는 기술들에 대해 좀더 명확하게 인지하고 확인할 수 있어 제품 이해에 큰 도움이 됐습니다. 이를 기회로 개발만이 중요한 것이 아닌 테스트케이스의 중요성을 절실히 깨닫고, 제가 개발하는 기술들에 대한 테스트케이스 작성이 필수불가결하다는 것을 느끼게 됐습니다. 느낀 점 브레인즈컴퍼니 개발4그룹에 입사 후, 3달간 근무하며 느낀 점은 제가 만족하며 회사를 다니고 있다는 점입니다. 그룹의 모든 구성원분들이 잘 적응할 수 있도록 도와주고 챙겨주셨고, 문제가 될 수도 있는 실수가 발생해도 모든 그룹원들이 다 잘 다독여 주셨습니다. 또, 좋은 피드백을 줘서 지속적으로 배워가고 성장할 수 있는 회사의 성장할 수 있는 부서라고 생각합니다. 그룹의 상래님, 신후님, 천웅님, 태민님 모두 제게 좋은 피드백과 도움을 주시고, 개선돼야할 점과 공부해야 할 부분, 그리고 개발을 하면서 고쳐야 할 습관들을 알려주셔서 점차 앞으로 나아갈 수 있다고 생각합니다. 일을 하면서 빼놓을 수 없는 게 워라밸일 것이라고 생각합니다. 첫 회사에서 일과 삶의 밸런스가 매우 적절하다고 생각하고 만족하며 근무를 하고 있습니다. 퇴근을 한 뒤에도 운동을 할 수 있고, 식단 관리도 병행하며 몸을 기르고 있습니다. 만약, 워라밸이 좋지 않았더라면 이렇게 삶을 유지할 수 없을 거라는 생각이 듭니다. 글을 마치며 면접에서 제가 했던 말이 있습니다. 저는 앞에 벽이 있다면 돌아가 다른 길을 찾으려 하기보다는 그 벽을 넘을 수 있는 방법을 생각합니다. 앞으로 나아갈 수 있고 성장할 수 있는 삶을 추구하고 있습니다. 비록 그 벽을 넘지 못하더라도, 다음에 그 벽보다 낮은 벽은 넘을 수 있을 것입니다. 시도조차 하지 않으면 당연히 발전도 없다고 생각합니다. 매번 도전하고 또 도전하며 발전하는 개발4그룹의 일원이 돼, 신기술 개발에도 큰 보탬이 되는 개발자로 성장하고 싶습니다. 그리고 브레인즈컴퍼니 개발4그룹에서 반드시 실현 가능하다고 생각합니다. 다양한 기술들을 배우고 학습해 제 것으로 만들고, 그룹과 회사에 보탬이 되는 개발자로 성장하겠습니다! [출처] https://twitter.com/gom_translate https://me2.kr/wvu3p http://jjaltoon.gallery/?p=11311 https://me2.kr/eq144 2022.08.25

1