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

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

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

블로그

기술이야기

기술이야기 행안부 표준운영절차 대응을 위한 ITSM 시스템 구축 시 고려사항 5가지 기술이야기 행안부 표준운영절차 대응을 위한 ITSM 시스템 구축 시 고려사항 5가지 최근 공공기관의 IT 인프라는 클라우드 전환과 마이크로서비스 아키텍처(MSA)의 확산으로 인해 그 구조가 유례없이 복잡해지고 있습니다. 이러한 변화 속에서 행정안전부는 공공 서비스의 안정성과 투명성을 확보하기 위해 2026년부터 모든 공공기관을 대상으로 「정보시스템 표준운영절차(SOP)」 적용을 의무화할 예정입니다. 이러한 정책적 변화는 단순히 절차에 맞춘 문서를 생성하는 수준을 넘어, 범정부 표준에 부합하는 체계적인 IT 서비스 관리(IT Service Management, 이하 ITSM) 시스템의 구축을 요구하고 있습니다. 과거의 IT 관리가 특정 장비의 가동 여부를 확인하는 '시설 관리' 중심이었다면, 이제는 서비스의 신청부터 장애 대응, 사후 관리까지 전 과정을 표준화된 프레임워크 안에서 관리해야 하기 때문입니다. 성공적인 공공 ITSM 도입과 안정적인 운영 정착을 위해 반드시 검토해야 할 5가지 핵심 전략적 고려사항을 상세히 살펴보겠습니다. 1. 8대 표준 프로세스의 '유기적 연계'를 통한 운영 정착 행안부가 제시한 8종 프로세스(요청, 이벤트, 변경, 구성, 서비스수준, 장애, 백업, 문제)는 독립된 기능이 아니라 서로 밀접하게 연결된 하나의 생태계입니다. 많은 기관이 각 절차를 파편화된 기능으로 도입하려다 보니, 데이터가 단절되고 운영이 정착되지 않는 '사일로(Silo) 현상'을 겪곤 합니다. 프로세스 간 선순환 워크플로우: 특정 이벤트가 발생했을 때 이것이 장애(Incident)로 판명되는 과정, 그리고 해당 조치가 구성 정보(CMDB)에 어떤 영향을 주어 변경 관리(Change) 프로세스를 거치는지 그 전체 생애주기(Lifecycle)가 시스템상에서 단일 맥락으로 이어져야 합니다. 실무 정착의 핵심: 시스템 도입 자체가 목적이 되어서는 안 됩니다. 실무자가 업무를 수행하는 과정에서 데이터가 자연스럽게 축적되도록 설계해야 합니다. 프로세스가 실제 업무 흐름보다 복잡하면 실무자는 시스템을 외면하게 되며, 이는 결국 '절차 따로, 업무 따로' 노는 결과를 초래합니다. 유기적인 연계 체계는 장애 대응의 효율성을 극대화합니다. 운영자가 파편화된 기록을 직접 조합할 필요 없이, 통합된 워크플로우를 통해 문제의 근본 원인을 논리적으로 규명함으로써 복잡한 인프라 환경에서도 안정적인 서비스 유지가 가능해집니다. 2. 감사와 보고를 위한 '객관적·정량적 증적'의 자동 확보 표준운영절차 준수 여부를 입증하는 가장 강력한 수단은 '기록'입니다. 하지만 수많은 IT 자원과 서비스 요청을 실무자가 일일이 수기로 기록하고 증적을 남기는 것은 불가능에 가깝고, 인적 오류(Human Error)의 위험도 큽니다. 디지털 증적 자동화: 모든 서비스 요청부터 최종 완료, 승인 이력까지 전 과정이 시스템에 타임스탬프와 함께 자동으로 기록되어야 합니다. 이는 감사 대응 시 데이터의 신뢰성을 보장하는 핵심 근거가 됩니다. 실시간 통계 및 리포팅: 별도의 데이터 가공 없이도 처리 건수, 평균 처리 시간(MTTR), 가용성 지표 등이 정량적으로 자동 산출되어야 합니다. 특히 정기 점검이나 감사 시점에 즉각적으로 표준화된 보고서를 추출할 수 있는 환경이 필수적입니다. 객관적인 데이터 확보는 운영의 투명성을 높여줍니다. 시스템을 통해 자동으로 생성되는 증적은 실무자의 보고 업무 부담을 획기적으로 줄여주며, 관리자는 정확한 데이터에 기반하여 운영 현황을 진단하고 개선 방향을 설정할 수 있습니다. 3. 정책 변화와 조직 개편에 대응하는 '아키텍처의 유연성' 공공기관은 범정부 가이드라인의 세부 변경이나 빈번한 조직 개편, 인사이동 등 환경 변화가 매우 잦습니다. 고정된 형태의 ITSM 시스템은 이러한 변화에 대응하기 어렵고, 그때마다 발생하는 유지보수 비용은 장기적인 부담이 됩니다. No-Code 기반의 프로세스 설계: 코딩에 대한 전문 지식이 없더라도 관리자가 드래그 앤 드롭 방식으로 신청서 양식을 수정하거나 업무 승인 절차를 재설계할 수 있는 '노코드(No-Code)' 환경을 갖추어야 합니다. 단계별 확장성: 초기에는 행안부 권고 수준의 필수 프로세스로 시작하되, 향후 운영 범위 확대나 신규 기술 도입에 따라 기능을 유연하게 추가할 수 있는 플랫폼 기반의 아키텍처가 필요합니다. 시스템의 유연성은 총소유비용(TCO) 절감과 직결됩니다. 정책 변화에 민첩하게 대응할 수 있는 구조를 통해 신규 기술 도입에 따른 관리 혼선을 줄이고, 조직의 성장에 맞춰 지속 가능한 운영 환경을 구축할 수 있습니다. 4. '서비스 수준 관리(SLA)'의 실시간 자동화와 지능화 SLA는 서비스의 품질을 측정하는 핵심 지표지만, 많은 곳에서 엑셀을 이용한 수동 계산이나 사후 결과 확인에 그치는 경우가 많습니다. 진정한 의미의 ITSM은 서비스 품질을 실시간으로 감시하고 개선하는 데 목적이 있어야 합니다. 실시간 지표 계산 및 알림: 서비스 가용성이나 목표 복구 시간 준수 여부가 시스템 내에서 실시간으로 계산되어야 합니다. 만약 목표 수준이 미달될 조짐이 보이면 담당자에게 즉시 알림을 보내 선제적으로 조치할 수 있는 체계가 마련되어야 합니다. 데이터 기반의 의사결정 지원: 축적된 SLA 데이터를 분석하여 특정 서비스에 부하가 집중되거나 반복적인 장애가 발생하는 지점을 식별해야 합니다. 이는 향후 IT 예산 확보나 인프라 증설 계획 수립 시 객관적인 근거 자료로 활용될 수 있습니다. 자동화된 서비스 수준 관리는 실무자의 업무 부담을 줄이는 동시에 공공 서비스의 품질을 실질적으로 상향 평준화합니다. 이는 단순히 규정을 지키는 수준을 넘어, 국민에게 제공되는 서비스의 안정성을 보장하는 핵심 역량이 됩니다. 5. 통합 가시성 확보를 위한 '단일 접점(SPOC)'의 완성 사용자가 서비스를 요청하는 창구와 관리자가 인프라를 모니터링하는 화면이 이원화되어 있다면 정보의 단절과 대응 지연이 발생합니다. 물리적 장비의 상태를 넘어 서비스 관점의 통합 가시성(Visibility) 확보가 필요한 이유입니다. 사용자 포털을 통한 단일 접점(Single Point of Contact): 사용자는 복잡한 절차를 고민할 필요 없이 단일한 창구를 통해 모든 IT 서비스를 요청하고, 처리 과정을 실시간으로 확인할 수 있어야 합니다. 인프라 관제와의 연계: 네트워크나 서버의 장애 이벤트가 발생했을 때, 이것이 자동으로 ITSM의 장애 티켓으로 발행되어야 합니다. 인프라 계층의 데이터와 서비스 계층의 운영 절차가 하나로 통합될 때 비로소 전체 IT 환경에 대한 유기적인 관리가 가능해집니다. 직관적인 통합 관제 환경은 부서 간 원활한 소통을 지원하고 장애 상황에서 의사결정 속도를 높여줍니다. 복잡한 수치 대신 공용 시각 자료를 공유함으로써 장애 영향 범위를 즉각 파악하고, 조직 전체의 운영 효율을 극대화하는 역할을 합니다. 행정안전부의 표준운영절차 대응은 결코 한 번의 시스템 도입으로 끝나는 프로젝트가 아닙니다. 2026년 의무화 이후에도 공공 IT 환경은 더욱 복잡해질 것이며, 이에 얼마나 체계적이고 유연하게 대응하느냐가 기관의 서비스 경쟁력을 결정지을 것입니다. 결국 성공의 열쇠는 '얼마나 표준을 완벽히 따르면서도 실무 정착이 가능한 유연한 ITSM 체계를 구축하는가'에 있습니다. 위 5가지 고려사항을 바탕으로 파편화된 운영 데이터를 자산화하고, 자동화된 지표 관리와 투명한 이력 관리가 가능한 환경을 조성하십시오. 이를 통해 규정 준수를 넘어선 진정한 의미의 '지능형 공공 IT 거버넌스'를 실현해 보시기 바랍니다. ITSM 구축 및 운영 관련 FAQ Q1. 2026년 의무화되는 '행안부 정보시스템 표준운영절차(SOP)'의 핵심은 무엇인가요? A1. 핵심은 공공기관 IT 서비스 운영의 투명성 확보와 표준화입니다. 기존의 개별적인 시설 관리 방식에서 벗어나, 행안부가 제시한 8대 표준 프로세스(요청, 이벤트, 변경, 구성, 서비스수준, 장애, 백업, 문제)를 유기적으로 연계하여 운영하는 것이 골자입니다. 이를 통해 서비스 신청부터 사후 관리까지 전 과정을 단일한 프레임워크 내에서 관리해야 합니다. Q2. 공공기관이 ITSM 시스템 구축 시 가장 먼저 고려해야 할 기술적 요소는? A2. '노코드(No-Code) 기반의 유연성'과 '데이터 통합 가시성'입니다. 공공기관은 조직 개편이나 정책 변화가 잦기 때문에, 코딩 없이도 프로세스를 즉시 수정할 수 있는 아키텍처가 필수적입니다. 또한, 인프라 관제 데이터와 운영 절차가 실시간으로 연동되어 장애 발생 시 즉각적으로 티켓이 발행되는 통합 환경을 갖춰야 합니다. Q3. 표준운영절차 준수를 증빙하기 위한 '디지털 증적'은 어떻게 관리하나요? A3. 실무자의 수기 기록은 인적 오류의 위험이 크므로 자동화된 타임스탬프 기록 체계가 필요합니다. 모든 서비스 요청, 승인 이력, 조치 결과가 시스템상에 자동으로 남아야 하며, 이를 기반으로 정량적인 통계 리포트(MTTR, 가용성 등)가 즉시 산출될 수 있어야 감사 및 보고 업무의 신뢰성을 확보할 수 있습니다. Q4. 복잡한 MSA 및 클라우드 환경에서 장애 대응 효율을 높이는 방법은? A4. 단일 접점(SPOC) 구축과 프로세스 간 선순환 워크플로우가 답입니다. 사용자는 단일 포털을 통해 서비스를 요청하고, 운영자는 장애(Incident) 발생 시 관련 구성 정보(CMDB)와 변경 이력을 한눈에 파악할 수 있어야 합니다. 파편화된 데이터를 하나로 잇는 통합 ITSM은 복잡한 인프라에서도 문제의 근본 원인을 빠르게 규명하게 해줍니다. { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://www.brainz.co.kr/#organization", "name": "브레인즈컴퍼니 (Brains Company)", "url": "https://www.brainz.co.kr/", "tickerSymbol": "KOSDAQ:099390", "sameAs": [ "https://www.facebook.com/brainzcompany.official/", "https://kr.linkedin.com/company/brainzcompany", "https://thevc.kr/brainzcompany" ] }, { "@type": "Product", "@id": "https://www.brainz.co.kr/#zenius", "name": "Zenius (제니우스)", "description": "AI 기반 IT 인프라 통합 모니터링 솔루션 (EMS/NMS/APM/ITSM)", "brand": { "@id": "https://www.brainz.co.kr/#organization" } }, { "@type": "TechArticle", "headline": "행안부 표준운영절차(SOP) 대응을 위한 ITSM 시스템 구축 시 고려사항 5가지", "description": "2026년 공공기관 의무화 예정인 행안부 정보시스템 표준운영절차 대응을 위한 핵심 ITSM 구축 전략과 Zenius 솔루션의 강점 안내.", "author": { "@id": "https://www.brainz.co.kr/#organization" }, "publisher": { "@id": "https://www.brainz.co.kr/#organization" }, "mainEntityOfPage": "https://www.brainz.co.kr/recent-story/view/id/453#u", "datePublished": "2026-03-12" }, { "@type": "ItemList", "name": "ITSM 구축 핵심 전략 요약", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "8대 표준 프로세스 연계", "description": "요청, 장애, 변경 등 8종 프로세스의 데이터 사일로 방지 및 유기적 통합" }, { "@type": "ListItem", "position": 2, "name": "디지털 증적 자동 확보", "description": "감사 대응을 위한 타임스탬프 기반 자동 기록 및 정량적 리포팅" }, { "@type": "ListItem", "position": 3, "name": "노코드 아키텍처", "description": "조직 개편 및 정책 변화에 대응하는 유연한 프로세스 설계 환경" }, { "@type": "ListItem", "position": 4, "name": "지능형 SLA 관리", "description": "실시간 지표 감시 및 AI 기반 선제적 장애 예방" }, { "@type": "ListItem", "position": 5, "name": "통합 가시성(SPOC)", "description": "사용자 포털과 관제 데이터를 하나로 잇는 단일 접점 구축" } ] }, { "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "2026년 의무화되는 행안부 정보시스템 표준운영절차(SOP)의 핵심은 무엇인가요?", "acceptedAnswer": { "@type": "Answer", "text": "핵심은 공공기관 IT 서비스 운영의 투명성 확보와 표준화입니다. 8대 표준 프로세스를 유기적으로 연계하여 서비스 신청부터 사후 관리까지 단일 프레임워크 내에서 관리해야 합니다." } }, { "@type": "Question", "name": "공공기관이 ITSM 시스템 구축 시 가장 먼저 고려해야 할 기술적 요소는?", "acceptedAnswer": { "@type": "Answer", "text": "'노코드(No-Code) 기반의 유연성'과 '데이터 통합 가시성'입니다. 조직 개편이나 정책 변화에 즉각 대응 가능해야 하며, 인프라 관제 데이터와 운영 절차가 실시간으로 연동되어야 합니다." } }, { "@type": "Question", "name": "표준운영절차 준수를 증빙하기 위한 '디지털 증적'은 어떻게 관리하나요?", "acceptedAnswer": { "@type": "Answer", "text": "수기 기록 대신 자동화된 타임스탬프 기록 체계가 필요합니다. 모든 승인 이력과 조치 결과가 시스템에 자동으로 남아야 하며, 이를 통해 정량적인 통계 리포트가 즉시 산출되어야 합니다." } }, { "@type": "Question", "name": "복잡한 MSA 및 클라우드 환경에서 장애 대응 효율을 높이는 방법은?", "acceptedAnswer": { "@type": "Answer", "text": "단일 접점(SPOC) 구축과 프로세스 간 선순환 워크플로우가 답입니다. 인프라 계층의 데이터와 서비스 계층의 운영 절차가 하나로 통합될 때 문제의 근본 원인을 가장 빠르게 규명할 수 있습니다." } } ] } ] } 2026.03.12
기술이야기 네트워크 모니터링에서 Zenius가 가지는 3가지 강점 기술이야기 네트워크 모니터링에서 Zenius가 가지는 3가지 강점 최근 기업의 네트워크 인프라는 클라우드 전환과 마이크로서비스 아키텍처(MSA)의 확산으로 그 구조가 복잡해지고 있습니다. 특히 쿠버네티스(Kubernetes) 환경의 도입은 네트워크 장비 간의 연결뿐만 아니라 컨테이너 간의 동적인 통신 흐름까지 관리해야 하는 새로운 숙제를 안겨주었습니다. 이러한 환경에서는 단순히 특정 장비의 전원이 켜져 있는지 확인하는 것만으로는 부족합니다. 인프라 전 계층의 데이터를 유기적으로 살펴보고, 문제가 발생했을 때 그 원인을 정확히 짚어낼 수 있는 체계적인 관제 역량이 필요합니다. 물리 장비의 이상 유무를 넘어 가상화 영역의 트래픽 흐름까지 파악해야 비로소 서비스의 안정성을 보장할 수 있기 때문입니다. 이러한 복잡한 관리 환경에 대응하기 위해 브레인즈컴퍼니는 Zenius를 통해 온프레미스와 클라우드가 혼재된 이기종 네트워크 전반에 대한 통합 가시성을 확보하고, 운영자가 데이터에 기반해 문제를 즉각 판단할 수 있는 정밀한 분석 환경을 제공하고 있습니다. 단순히 인프라의 상태를 보여주는 데 그치지 않고 실무적인 해결책을 제시하는 Zenius만의 네트워크 모니터링 강점 3가지를 자세히 살펴보겠습니다. 1. NMS·TMS·NPM의 '유기적 연계'를 통한 가시성 확보 네트워크 장애가 발생했을 때 원인을 빠르게 찾으려면 장비의 상태, 트래픽의 흐름, 프로세스 단위의 성능을 하나의 맥락에서 분석할 수 있어야 합니다. Zenius는 NMS, NPM, TMS의 유기적인 연계를 통해 인프라 하부 조직부터 상위 서비스 흐름까지를 단일 분석 체계로 분석할 수 있도록 지원합니다. 상태와 흐름의 교차 분석: 장비 가용성을 관리하는 NMS와 FLOW 단위 트래픽 정보를 분석하는 TMS의 연동을 통해, 특정 구간에 부하가 생겼을 때 어떤 IP나 서비스 포트가 대역폭을 점유하고 있는지 즉각 식별하여 현상과 원인을 동시에 파악할 수 있습니다. 커널 레벨의 정밀 성능 측정: NPM은 커널 레벨에서 패킷 정보를 수집하여 1초 단위의 지표를 생성합니다. 이러한 정밀 측정을 통해 일반적인 방식으로는 놓치기 쉬운 순간적인 트래픽 급증이나 쿠버네티스 파드(Pod) 간의 미세한 지연 현상을 효과적으로 감지할 수 있습니다. 전 계층 통합 추적: 물리적 네트워크 장비부터 가상화 영역의 가상 스위치, 그리고 컨테이너 내부의 프로세스 간 통신까지 전 구간에 대한 단계별 추적 기능을 지원합니다. 이를 통해 운영자는 온프레미스와 가상화 환경이 혼재된 복잡한 인프라 내에서 병목 지점을 명확히 식별하고, 문제 해결을 위한 분석 범위를 신속하게 좁힐 수 있습니다. 이러한 연계 체계는 장애 대응의 효율성을 높여줍니다. 파편화된 데이터를 운영자가 직접 조합할 필요 없이, 통합된 지표를 통해 문제의 근본 원인을 논리적으로 규명함으로써 복잡한 인프라에서도 안정적인 관리가 가능해집니다. 2. 통합 플랫폼 기반의 '유연한 확장성' 인프라의 규모가 커지고 기술 스택이 다양해짐에 따라 관리 도구를 개별적으로 도입하는 경우가 많아, 도구간 데이터 연계가 제한될 경우 데이터 사일로 현상을 초래할 수 있습니다. Zenius는 단일 플랫폼 아키텍처를 기반으로 설계되어, 네트워크뿐만 아니라 전체 IT 자원을 일관된 관리 체계 내에서 운영할 수 있도록 지원합니다. 단일 관제 환경 제공: 온프레미스의 레거시 장비와 퍼블릭 클라우드 자원을 하나의 인터페이스에서 통합 관리합니다. 운영자는 서로 다른 콘솔을 오갈 필요 없이 동일한 UI와 정책 하에서 인프라 전체의 건강 상태를 점검할 수 있어 관리의 일관성이 확보됩니다. 모듈 단위의 기능 확장: 네트워크 관리(NMS)로 시작하여 필요에 따라 클라우드(CMS), 서버(SMS), 애플리케이션(APM), 쿠버네티스(K8s) 기능을 애드온(Add-on) 방식으로 자유롭게 추가할 수 있습니다. 모든 모듈은 플랫폼 내에서 데이터를 실시간으로 공유하며 시너지를 냅니다. 이기종 지표 상관관계 분석: 서로 다른 계층에서 수집된 데이터를 통합 처리하여, 서버 부하와 네트워크 트래픽 간의 연관성을 분석하는 등 고도화된 관제를 지원합니다. 이는 인프라 전체 관점에서 서비스 가용성을 객관적으로 판단하는 근거가 됩니다. 플랫폼 중심의 접근은 신규 기술 도입에 따른 학습 비용과 관리 혼선을 줄여줍니다. 인프라 규모가 확장되더라도 기존의 운영 프로세스를 그대로 유지할 수 있어, 장기적으로 운영 효율을 높이고 안정적인 인프라 환경을 구축하는 데 유리합니다. 3. 직관적인 시각화와 '분석 기능'을 통한 의사결정 지원 모니터링 시스템이 수집하는 방대한 로우 데이터는 운영자가 즉시 이해하고 조치할 수 있는 정보로 가공되어야만 가치를 가집니다. Zenius는 복잡한 네트워크 현황을 직관적으로 파악하고 의사결정에 활용할 수 있도록 실무 중심의 시각화 도구와 지능형 분석 기능을 탑재하고 있습니다. 지능형 토폴로지 맵: 네트워크 자원 간의 연결 관계를 자동으로 탐색하여 시각화합니다. 특정 노드에 장애가 발생하면 연결된 인접 장비와의 연관 관계와 장애 영향 범위가 실시간으로 표시되어, 운영자가 장애 규모를 즉각 파악하고 대응 우선순위를 판단할 수 있습니다. 다차원 트래픽 분석: 대량의 트래픽 데이터 중 점유율이 높은 IP, 서비스 포트 등을 실시간으로 추출(Top-N)합니다. 이를 통해 자원 낭비 지점을 식별하거나, 향후 인프라 증설 계획을 세울 때 필요한 객관적인 근거 자료로 활용할 수 있습니다. 운영 자동화 리포팅: 웹 기반 UI를 통해 성능 지표를 정해진 양식의 리포트로 자동 생성합니다. 운영자가 수작업으로 데이터를 취합하는 시간을 획기적으로 줄여주어, 단순 반복 업무가 아닌 본연의 분석 및 운영 업무에 집중할 수 있는 환경을 만듭니다. 직관적인 시각화 도구는 부서 간의 원활한 소통을 지원합니다. 복잡한 수치 대신 공용 시각 자료를 공유함으로써 장애 상황에서 의사결정 속도를 높이고, 조직 전체의 IT 운영 효율을 상향 평준화하는 역할을 합니다. 고도화된 네트워크 환경에서 발생하는 장애는 원인을 파악하는 것만으로도 많은 시간과 노력이 소모되곤 합니다. 수많은 현장에서 검증된 제니우스와 같은 솔루션을 통해 인프라 전 계층에 대한 통합 가시성을 확보하고, 데이터에 기반한 신속한 의사결정으로 서비스 운영의 연속성을 높여 보시기 바랍니다. Q&A Q1. 클라우드나 가상화 등 최신 인프라의 네트워크 모니터링도 가능한가요? A: 네, 가능합니다. 물리적인 네트워크 장비는 물론, 가상화 환경의 가상 스위치와 컨테이너 내부의 프로세스 통신까지 단계별 추적 기능을 지원합니다. 온프레미스와 클라우드가 혼재된 복잡한 경로 상에서도 어느 구간에서 병목이 발생하는지 명확한 가시성을 제공합니다. Q2. 쿠버네티스나 클라우드 내부의 네트워크 흐름도 모니터링이 가능한가요? A: 네, 가능합니다. 물리 장비뿐만 아니라 가상화 환경의 가상 스위치(vSwitch) 및 컨테이너 내부 프로세스 간 통신까지 단계별 모니터링 기능을 지원합니다. 네트워크가 파편화된 쿠버네티스 환경에서도 어느 지점에서 병목이 발생하는지 경로를 추적하여 분석 범위를 신속하게 좁힐 수 있습니다. Q3. NMS, TMS 등 여러 솔루션의 데이터를 한곳에서 연결해서 볼 수 있나요? A: 단일 플랫폼 아키텍처를 기반으로 하므로 가능합니다. 네트워크(NMS) 장비 부하와 트래픽(TMS) 데이터, 서버(SMS)의 프로세스 지표를 하나의 화면에서 상관관계 분석을 할 수 있습니다. 이를 통해 관리자가 여러 콘솔을 오가며 데이터를 직접 조합해야 하는 수고를 덜어주고, 의사결정 속도를 높여줍니다. Q4. 서로 다른 장비나 IT 인프라 자원들도 함께 모니터링할 수 있나요? A: Zenius는 단일 플랫폼(EMS)을 기반으로 설계되어, 이기종 IT 인프라 장비와 자원들을 통합 인터페이스에서 관리할 수 있습니다. 네트워크, 서버, 클라우드 등 각기 다른 지표들 간의 상관관계를 분석하는 기능을 지원하므로, 관리자가 여러 도구를 오가지 않고도 전체 인프라의 가용성을 한눈에 판단할 수 있습니다. { "@context": "https://schema.org", "@graph": [ { "@type": "Person", "@id": "https://www.brainz.co.kr/#expert_writer", "name": "브레인즈컴퍼니 기술전략팀 (Technical Writer)", "jobTitle": "Senior IT Infrastructure Analyst & Technical Writer", "worksFor": { "@id": "https://www.brainz.co.kr/#organization" }, "description": "15년 경력의 IT 인프라 모니터링 및 Observability 분야 전문가로, Zenius 솔루션을 통한 엔터프라이즈 관제 최적화 전략을 연구합니다." }, { "@type": "TechArticle", "@id": "https://www.brainz.co.kr/recent-story/view/id/449#article", "headline": "네트워크 모니터링에서 Zenius가 가지는 3가지 강점", "description": "단순히 인프라의 상태를 보여주는 데 그치지 않고 실무적인 해결책을 제시하는 Zenius만의 네트워크 모니터링 강점 3가지를 자세히 살펴보겠습니다.", "author": { "@id": "https://www.brainz.co.kr/#expert_writer" }, "publisher": { "@id": "https://www.brainz.co.kr/#organization" }, "url": "https://www.brainz.co.kr/recent-story/view/id/449#u", "datePublished": "2024-05-20", "mainEntityOfPage": "https://www.brainz.co.kr/recent-story/view/id/449#u" }, { "@type": "Organization", "@id": "https://www.brainz.co.kr/#organization", "name": "브레인즈컴퍼니 (Brains Company)", "url": "https://www.brainz.co.kr/", "tickerSymbol": "KOSDAQ:099390", "sameAs": [ "https://www.facebook.com/brainzcompany.official/", "https://kr.linkedin.com/company/brainzcompany", "https://thevc.kr/brainzcompany" ] }, { "@type": "ItemList", "name": "Zenius 네트워크 모니터링 핵심 강점 요약", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "유기적 연계 가시성", "description": "NMS, TMS, NPM 연동으로 장비 상태와 트래픽 흐름을 단일 맥락에서 분석" }, { "@type": "ListItem", "position": 2, "name": "유연한 플랫폼 확장성", "description": "단일 아키텍처 기반으로 이기종 자원 통합 및 모듈별 기능 확장 지원" }, { "@type": "ListItem", "position": 3, "name": "지능형 시각화 분석", "description": "자동 탐색 토폴로지 맵과 트래픽 분석을 통한 신속한 의사결정 지원" } ] } ] } 2026.02.23
기술이야기 SDN(소프트웨어 정의 네트워크)의 주요 특징과 성공사례는?! 기술이야기 SDN(소프트웨어 정의 네트워크)의 주요 특징과 성공사례는?! 지메일, 유튜브, 구글맵스, 구글 클라우드까지.. 구글은 자사의 다양한 서비스들이 어디에서나 원활하게 돌아갈 수 있도록, 전 세계 곳곳의 수많은 데이터 센터를 운영하고 있습니다. 구글의 한 데이터 센터 전경(출처ⓒ google.com) 그리고 이 데이터 센터간의 효율적이고 안정적인 '네트워크' 구축을 위해, 다양한 노력을 펼치고 있습니다. 사용자에게 빠른 서비스를 제공하기 위해선 데이터 센터간의 높은 연결성과 효율성이 필수조건이기 때문이죠. 구글의 네트워크 운영은 2012년에 큰 전환점을 맞이합니다. 이 변화의 중심에는 SDN(Software Defined Network, 소프트웨어 정의 네트워크)이란 기술이 있는데요. 구글의 네트워크 운영 효율과 안정성을 극적으로 개선시킨 SDN은 과연 무엇일까요? 우선 SDN의 주요 특징부터 살펴보겠습니다. ㅣSDN의 두 가지 핵심특징 SDN은 네트워크 관리를 간소화하고 네트워크 구성의 유연성을 높이기 위해 고안된 기술입니다. SDN에는 두 가지 핵심적인 특징이 있는데요. 첫 번째 특징, 컨트롤 플레인과 데이터 플레인의 분리 SDN을 대표하는 첫 번째 특징은, 네트워크 장비의 전반적인 데이터를 중앙 집중적으로 관리할 수 있는 컨트롤 플레인(Control Plane)과, 트래픽 전송 역할을 하는 데이터 플레인(Data Plane)이 분리된 것입니다. 이러한 분리에 따른 두 가지 효과를 살펴보겠습니다. (1) 최적의 로드밸런싱이 가능해짐 기존에는 라우터와 스위치 등의 네트워크 장비가 경로를 결정했었습니다. 이 장비들은 주로 최단 경로 알고리즘을 통해 패킷을 전달하기 때문에, 네트워크 관리자가 특정 경로를 원하는대로 설정하기엔 어려움이 있었습니다. 즉 '로드밸런싱'이 어려웠었죠. 하지만 SDN은 이러한 상황의 변화를 가져왔습니다. [그림] SDN 로드밸런싱 예를 들어 보겠습니다. 기존에는 경로 정보가 있을 때 U에서 나가는 트래픽을 V와 X에 각각 분산시키고 싶을 경우, 기존의 최단 알고리즘을 통하면 항상 최단의 경로로만 라우팅할 수 있었습니다. 하지만 위 [그림]처럼 SDN을 사용하면 네트워크 관리자는 전체 네트워크의 상태를 실시간으로 파악하고, 트래픽을 V와 X로 균등하게 분산시키는 등 세밀한 조정을 할 수 있습니다. 이를 통해 네트워크의 효율성을 극대화하고, 트래픽 과부하나 장애 발생 시 빠르게 대응할 수 있게 되었죠. (2) 비용 절감과 효율성 증대 SDN을 통해 기업들은 고가의 전용 네트워크 장비를 사용하지 않고도, 필요한 네트워크 기능을 구현할 수 있게 되었습니다. 이에 따라서 초기 장비 투자 비용(CapEx)과 네트워크의 운영 비용(OpEx)을 모두 줄일 수 있습니다. 또한 네트워크 관리의 자동화와 최적화로 운영의 효율성을 높여주며, 장기적으로는 인적 자원에 대한 비용 절감으로도 이어집니다. 두 번째 특징, 중앙 집중식 관리 시스템 SDN을 대표하는 또다른 특징은 소프트웨어(SDN 컨트롤러)가 중앙에서 제어한다는 것입니다. 이 소프트웨어가 네트워크의 '두뇌' 역할을 하며, 네트워크의 각 기능이 어떻게 동작할지 지시합니다. 이러한 특징으로 인한 대표적인 효과를 살펴보겠습니다. (1) 유연성과 신속한 대응 기존 네트워크 시스템은 하드웨어 중심으로 돌아가기 때문에, 이 변화에 적응하기 위해선 실제 장비를 교체하거나 수동으로 설정을 변경해야 했습니다. 하지만 SDN에서는 모든 제어 기능이 '중앙'에서 소프트웨어로 이루어지기 때문에, 변경 사항이나 새로운 요구 사항이 발생했을 경우 관리자는 물리적 장비에 접근하거나 개별 설정을 조정할 필요없이 소프트웨어를 통해 네트워크를 즉시 업데이트할 수 있게 되었습니다. 이 덕분에 기존에 며칠이나 몇 주가 걸리던 네트워크 변경 작업을 몇 분 안에 할 수 있게 됐습니다. (2) 보안과 성능 최적화 기존의 전통적인 네트워크 관리 방식에서는, 네트워크의 각 부분에 대해서 심층적으로 들여다 보는 것이 어려웠습니다. 네트워크 장비와 시스템이 서로 다른 플랫폼과 프로토콜을 사용했기 때문에, 전체적인 네트워크 상태의 모니터링이 사실상 불가능했었죠. 하지만 SDN은 소프트웨어를 통한 중앙집중식 관리 시스템으로 이루어져 있기에, 네트워크의 모든 부분에 대한 실시간 통합 관리가 가능합니다. 이를 통해서 보안 위협을 빠르게 식별하고 대응할 수 있게 되었죠. 또한 트래픽 패턴을 정밀하게 분석하여 재분배하고, 트래픽 병목 현상을 예방하여 전반적인 네트워크 성능도 개선할 수 있게 됐습니다. SDN의 두 가지 특징과 그로 인한 효과를 알아봤는데요. 이제 SDN의 아키텍처와 구현 방식에 대해서도 한번 살펴보겠습니다. ㅣSDN의 아키텍처와 구현 방식 SDN 아키텍처: 세 가지 주요 계층 SDN은 네트워크 관리를 더 유연하고 효율적으로 만들기 위해, '세 가지' 주요 계층으로 구성되어 있습니다. 세 가지 계층은 앞서 언급했던 Control Plane(컨트롤 플레인)과 Data Plane(데이터 플레인), 그리고 Application Plane(응용 프로그램 계층)입니다. 각 계층은 네트워크를 관리하고 운영하는데 있어 중요한 역할을 하는데요. 각 계층별 역할과 연관성에 대해서 알아보겠습니다. 우선 아래 [그림]에 가장 하단에 위치한 Data Plane(데이터 플레인)은 Control Plane(컨트롤 플레인)이 내린 결정에 따라 실제 데이터 패킷(Data packet)을 전송하는 역할을 합니다. 데이터 플레인은 스위치, 라우터 같은 물리적 장비를 통해 구현되며, 이들 장비는 데이터 패킷을 처리하고 전달하죠. [그림] SDN 아키텍처 중간에 위치한 Control Plane(컨트롤 플레인)은 네트워크에서 어떤 데이터가 어디로 가야 하는지 결정하는 역할을 합니다. 즉 Control Plane(컨트롤 플레인)은 네트워크 트래픽을 어디로 보낼지 결정하는 역할을 합니다. 가장 위에 위치한 Application Plane(응용 프로그램 계층)은 사용자에게 서비스를 제공하는 소프트웨어 애플리케이션을 말합니다. 이 계층은 SDN의 나머지 두 계층 위에 있으며, 네트워크의 다양한 리소스를 활용해 실제 사용자에게 서비스를 제공합니다. 클라우드 스토리지 서비스나 스트리밍 서비스 같은 것이 여기에 해당됩니다. 이 서비스들은 Control Plane(컨트롤 플레인)과 Data Plane(데이터 플레인)을 통해 데이터를 주고 받으며, 사용자에게 콘텐츠를 제공하죠. 이처럼 세 계층은 서로 밀접하게 연결되어 있습니다. 다시 말해 Control Plane(컨트롤 플레인)이 네트워크의 전반적인 관리와 결정을 담당하면, Data Plane(데이터 플레인)은 그 결정을 바탕으로 실제 데이터를 전송하죠. 그리고 Application Plane(응용 프로그램 계층)은 이 모든 네트워크 인프라 위에서 동작하며, 최종 사용자에게 서비스를 제공합니다. SDN의 구현 방식 위에서 살펴본 것 처럼 SDN은 세 개의 층으로 이루어져 있는데요. 이 각각의 층이 '제대로' 역할을 수행하기 위해서 꼭 필요한 것이 SDN Controller, OpenFlow 프로토콜입니다. OpenFlow 프로토콜은 SDN 컨트롤러와 네트워크 장비 사이에서 동작하는 프로토콜입니다. 컨트롤 플레인과 데이터 플레인 사이의 소통을 담당하고 있죠. OpenFlow 프로토콜은 컨트롤 플레인이 네트워크 장비에 구체적인 지시를 내리고, 그 지시에 따라 트래픽을 어디로 보낼지 결정할 수 있게 해줍니다. [그림] SDN 컨트롤러, OpenFlow 프로토콜 SDN 컨트롤러는 이 모든 과정을 조율하는 '중앙 집중식 지휘소'라 할 수 있는데요. 컨트롤러는 네트워크의 전반적인 상황을 파악하고, 데이터 플로우를 최적화하기 위한 결정을 내리며, OpenFlow를 통해 그 결정을 네트워크 장비에 전달합니다. 컨트롤러가 없다면 마치 중앙 교통 관리 시스템이 없이 각자의 판단에 따라 움직이는 차량들처럼 혼란스러워 지겠죠. 이처럼 SDN 컨트롤러와 OpenFlow 프로토콜을 통해 구현된 중앙 집중식 네트워크 관리는 효율적이고 유연한 트래픽 조정을 가능하게 합니다. 이제 마지막으로 맨 앞에서 잠시 살펴 본 구글(Google)의 사례를 자세히 들여다보겠습니다. ㅣ사례를 통해 보는 SDN: 구글의 G-Scale 구글의 'G-Scale SDN 프로젝트(2012)'는 SDN을 가장 효과적으로 활용한 대표적인 사례입니다. 이 프로젝트는 구글이 2010년부터 진행한 OpenFlow 프로젝트의 일환으로, 구글 데이터센터 백본(BackBone)1 구간을 SDN 기반으로 전환하는 대담한 시도였죠. 구글 이 프로젝트를 통해 성취한 결과는 인상적인 수준을 넘어, 네트워크 관리 방식에 혁신을 일으켰다고 평가받고 있습니다. 구글은 얻은 대표적인 세 가지 이득을 살펴보겠습니다. *1: 백본: 전산망 속에서 근간이 되는 네트워크를 연결시켜주는 대규모 전송회선 [그림] 구글 G-Scale 프로젝트를 통해 구축된 데이터 센터(2012) 1. 인프라 리소스의 최적 활용 구글은 OpenFlow를 기반으로 한 SDN을 적용해 기존에 40~50% 수준에 머물렀던 네트워크 인프라의 활용도를 거의 100% 가까이 끌어올렸습니다. 기존 네트워크 시스템에서는 다양한 벤더의 장비들이 서로 완벽하게 호환되지 않은 문제로 인해, 전체 네트워크 장비의 효율성이 제한되곤 했었죠. 하지만 구글의 SDN 구현은 이러한 한계를 넘어서, 네트워크 자원을 훨씬 유연하게 관리할 수 있는 방법을 제시할 수 있게 했습니다. 2. WAN 대역의 경로 최적화 WAN(Wide Area Network)에서의 데이터 전송 속도와 효율성은, 전 세계 사용자들에게 고품질의 서비스를 제공하는 데 핵심적인 요소인데요. 구글은 SDN을 통해 이러한 WAN 대역의 데이터 전송 경로를 최적화하여, 사용자 경험을 크게 향상시킬 수 있었습니다. 이는 전 세계 서비스를 제공하는 구글에게 있어 대단히 중요한 성과였죠. 3. 네트워크 구축 비용의 절감 구글은 SDN 컨트롤러와 화이트박스 스위치의 조합을 통해, 데이터센터 내 네트워크 구축 비용을 대폭 낮출 수 있었습니다. 화이트박스 스위치는 사용자가 네트워크 장비의 동작방식을 직접 결정할 수 있게 하는 개방형 장비로, 구글은 이를 통해 더 효율적이고 경제적인 네트워크 인프라를 구축할 수 있게 됐습니다. 또한 구축 비용의 절감 뿐 아니라 전반적인 서비스 품질의 향상 효과도 거둘 수 있었습니다. [그림] 구글의 다양한 SDN 기술 이처럼 구글의 'G-Scale SDN 프로젝트'는 단순히 기술적 성공을 넘어서, 전 세계 통신사와 네트워크 장비 제조사들이 SDN을 도입하고 네트워크 가상화에 뛰어들게 만든 결정적 계기가 되었습니다. 구글은 여기서 한 발자국 더 나아가 BGP, Espresso, B4, Andromeda, Jupiter 등 다양한 SDN 기술을 적극적으로 활용하고 있습니다. 이러한 노력은 네트워크의 효율성을 극대화하고, 비용을 최적화하여, 데이터 중심의 세계에서 경쟁력을 유지하고, 사용자에게 더 나은 서비스를 제공하는 성과를 만들어내고 있습니다. 구글의 G-Scale 프로젝트라는 큰 성공을 만들어낸 SDN도 '어떻게 하면 안정적으로 네트워크를 관리하고 운영할 수 있을까?'라는 고민에서 시작됐습니다. 네트워크 관리의 중요성은 더욱 더 커지고 있습니다. SDN이라는 혁신적인 기술을 바로 도입하는 것도 물론 좋지만, 그 전에 현재의 네트워크를 제대로 모니터링 하고 있는지 부터 점검해봐야 합니다. 여러분의 네트워크는 제대로 관리되고 있나요? 2024.05.09
기술이야기 데브옵스(DevOps)에 대한 오해, 그리고 진실은?! 기술이야기 데브옵스(DevOps)에 대한 오해, 그리고 진실은?! 2000년 대 후반 IT 분야에서 데브옵스(DevOps)라는 움직임이 시작된 후, 꾸준하게 관심이 이어지고 있습니다. 데브옵스와 관련된 전 세계 시장의 규모는 2023년 기준 약 15조 원으로 추산되며, 올해부터는 연평균 25.5%씩 성장하여 2032년에 118조 원에 이를 것으로 예상됩니다(*출처: Grand View Research). 우리나라의 경우 네이버, 카카오, 우아한 형제들, 토스 등과 같은 국내 대기업부터 스타트업까지 데브옵스 팀을 구축하여 적극적으로 활용하고 있기도 한데요. 이처럼 많은 기업들이 말하는 데브옵스란 과연 무엇일까요? 그리고 어떻게 하면 데브옵스를 성공적으로 도입하고 활용할 수 있을까요? │ 데브옵스(DevOps)란 무엇인가? [그림 1] DevOps 개념 ⓒdevopedia 우선 데브옵스가 무엇인지부터 살펴봅시다. 검색 사이트에서 '데브옵스 혹은 DevOps'라고 검색하면 위 [그림1]과 같은 결과를 찾을 수 있는데요. [그림 2] DevOps에 대한 필자의 첫인상 하지만 처음 데브옵스라는 단어를 접할 경우 [그림 2]처럼 오버랩되는 건, 필자만 그런 것은 아니라고 생각합니다. 위 그림처럼 "개발자 보러 운영까지 하라는 거야? 아니면 운영자에게 개발까지 하라는 거야?"라는 질문을 던질 수 있겠죠. 데브옵스(DevOps)는 소프트웨어의 개발(Developmnet)과 + 운영(Operations)의 합성어이다. 이는 소프트웨어 개발자와 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다. 데브옵스는 소프트웨어 개발조직과 운영조직 간의 상호 의존적 대응이며, 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다. ⓒ위키백과 위 내용에도 언급되었듯이, 데브옵스라는 것은 결국 단순한 기술이 아닌 환경 또는 사람들 간에 관계라고 할 수 있습니다. 그렇다면 데브옵스는 어떤 이유로 주목받을 수 있었을까요? │ 데브옵스(DevOps)가 주목받게 된 배경은? 데브옵스가 주목받은 이유는 여러 가지 있을 수 있지만, 주요한 이유 중 몇 가지를 설명하면 다음과 같습니다. 클라우드 컴퓨팅 기술의 발전 IT 산업의 발전에 따라 빠른 개발과 빠른 배포, 그리고 고객의 요구에 신속하게 대응하는 능력이 중요해졌습니다. 특히 클라우드 컴퓨팅(Cloud Computing) 기술의 발전으로 데브옵스의 필요성이 더 대두되었는데요. 클라우드 자원의 가상화 기술과 빠른 프로비저닝*1을 통해 기존의 개발과 운영 간의 경계가 허물어지며, 서로 간의 협력이 필수적으로 요구되었기 때문입니다. 실제로 데브옵스만으로는 52%, 클라우드 단독 사용으로는 53%의 성능 향상을 얻었지만, 데브옵스와 클라우드가 결합된 환경에서는 평균 81%의 성능을 향상시킬 수 있다는 조사 결과도 있습니다. *1 프로비저닝(Provisioning): 사용자가 요청한 IT 자원을 사용할 수 있는 상태로 준비하는 것 MSA의 등장 [그림 4] 모놀리식 구조 예시(왼) [그림 5] MSA 구조 예시(오) 지금까지 운영 중인 시스템 혹은 서비스는, 하나의 큰 덩어리로 구성된 [그림 4] 모놀리식(Monolithic) 구조를 많이 사용하고 있습니다. 안정성을 확보하고 기능 추가를 편리하게 할 수 있었기 때문이죠. 하지만 한 부분의 변경이 전체 시스템에 영향을 미칠 수 있어, 유지보수가 어렵다는 한계점이 있습니다. 예를 든다면 특정 기능이 수정이 필요한 경우에도, 전체 시스템을 수정해야 해서 번거롭고 비효율적인 부분이 있습니다. 이러한 모놀리식 구조의 한계점으로 소프트웨어의 구조가 서서히 [그림 5] MSA(Micro Service Architecture)로 변화되고 있습니다. MSA는 통합된 하나의 덩어리를 관리하는 것이 아닌, 작은 단위로 쪼개어 관리하는 방식인데요. 관리하기도 효율적이고, 소프트웨어 품질개선과 요구사항 반영이 비교적 편리해졌습니다. 각 서비스가 독립적으로 배포되고 운영되기 때문에, 특정 기능을 수정할 때 전체 기능을 수정하거나 다시 배포할 필요가 없어진 거죠. 하지만 이러한 변화는 기존의 개발 환경과 조직 문화로 대응하기엔 어려움이 있었습니다. 이때 '데브옵스(DevOps)'가 좋은 솔루션으로 등장한 것이죠! 데브옵스가 지속적인 통합(CI)1과 지속적인 배포(CD)2를 통해 빠른 개발 주기를 실현하고 배포할 수 있을 뿐만 아니라, 다수의 독립적인 서비스가 상호작용할 수 있도록 원활한 협업과 통합을 가능하게 했기 때문입니다. *1 지속적인 통합(Continuous Integration, CI) 개발자가 코드를 변경할 때마다 자동으로 통합하고 빌드 하여, 소프트웨어의 품질을 빠르게 확인하는 과정 *2 지속적인 배포(Continuous Delivery, CD) 통합된 코드를 자동으로 테스트하고, 안정적으로 통과한 경우에는 자동으로 프로덕션 환경에 소프트웨어를 배포하는 것. 이에 따라 사용자에게 새로운 기능이나 수정 사항을 신속히 제공하는 과정 │ 데브옵스(DevOps) 도입 성공사례는? 이처럼 데브옵스의 정의와 주목받게 된 배경을 살펴봤는데요. 이번에는 데브옵스를 실제로 기업에 적용해 보고 성공한 사례를 자세히 살펴볼까요? 넷플릭스 넷플릭스(Netflix)는 데브옵스를 성공의 핵심요소로 삼아, 지속적으로 새로운 기능과 업데이트를 제공했습니다. 자동화된 유연한 인프라로 사용자 경험을 향상시켰죠. 이를 통해 빠르게 변화하는 스트리밍 산업에서 앞서 나갈 수 있게 되었고, 많은 비즈니스 이점을 얻게 되었습니다. 사실 넷플릭스는 2008년 큰 장애를 겪은 후, 클라우드로 이전되면서 인프라를 혁신적으로 개편했습니다. 이로써 기존의 수직적 단일 장애 지점에서 벗어나, 수평적으로 확장 가능한 분산 시스템을 구축할 수 있었습니다. 아마존 아마존(Amazon)은 데브옵스 원칙을 초기에 채택하여, 개발과 운영팀 간의 협력을 강화했습니다. 자동화와 지속적인 통합을 강조함에 따라, 빠른 배포 주기와 개선된 확장성을 달성할 수 있었죠. 이러한 아마존의 데브옵스 접근 방식은, 시장에서 경쟁 우위를 유지하는데 중요한 역할을 했습니다. 아마존 창립자인 제프 베이조스는 아마존의 데브옵스에 대해 '고객에게 집중하고, 혁신을 포용하며, 실험할 용기'를 강조했습니다. 베이조스는 혁신을 위해, 오해를 받고 비판받을 의향이 있어야 한다고 말했던 것이죠. 페이스북 페이스북(Facebook)은 "빠르게 움직이고 물건을 부수라"는 문화에 뿌리를 둔 데브옵스 관행을 택했습니다. 실험, 민첩성, 위험 감수를 중시하는 접근 방식을 포함해서 말이죠. 이처럼 페이스북은 지속적인 통합과 배포, 자동화된 테스팅, 모니터링을 사용하여 사용자에게 더 빠르고 높은 품질의 새로운 기능과 업데이트를 제공하고 있습니다. 월마트 2011년부터 데브옵스를 도입한 월마트(Walmart)는 자동화와 협업 그리고 지속적인 배포에 중점을 두었습니다. 애자일(Agile) 방법론과 클라우드 기반의 인프라 및 데브옵스 툴체인을 활용하여, 하루에 최대 100번까지 코드를 배포할 수 있게 된 것이죠. 이를 통해 디지털 변환을 가속화하고, 전자상거래 플랫폼을 개선하며, 고객 경험을 향상시킬 수 있었습니다. 위 기업들은 데브옵스라는 도구를 효과적으로 활용하여 비즈니스 성과를 창출하고, 경쟁 우위를 확보할 수 있었습니다. 그렇다면 데브옵스를 도입하기만 하면 무조건 성공할 수 있을까요? │ 데브옵스(DevOps)의 오해와 한계 앞선 질문에 대한 대답은 아쉽게도 NO입니다. 데브옵스는 개발 환경과 문화를 전부 해결해 줄 수 있는 '만능책'은 아니라는 것이죠. 데브옵스가 도입된 이후 새로운 한계점이 발견되었고, 실패할 사례들도 적지 않게 나왔습니다. 이러한 결과는 아래와 같은 오해들에서 비롯될 확률이 높은데요. 대표적으로 3가지만 살펴봅시다. [그림 6] DevOps 구현을 위한 도구 ⓒMedium_Ajesh Martin 오해 1. 데브옵스는 일종의 단순한 도구일 뿐이다? 데브옵스를 '일종의 도구'로만 보는 것은 잘못된 판단입니다. 물론 여러 팀에서 보다 더 나은 환경과 문화를 위해 슬랙(Slack), 젠킨즈(Jenkins), 도커(Docker) 등 여러 도구를 사용하는 것은 좋습니다. 하지만 데브옵스는 이보다 더 광범위한 접근 방식을 담고 있습니다. 즉 개발과 운영팀 간의 협력과 더 빠른 소프트웨어 개발과 배포를 가능하게 하는 방법론을 포함한다는 것이죠. 다시 말해 데브옵스라는 '도구'를 이용하기 이전에, 문화적 그리고 기술적 접근 방식이 바탕이 되어야 데브옵스라는 툴이 도움 될 수 있습니다. 오해 2. 데브옵스는 모든 조직에 적합하다? 만약 '다른 회사에 데브옵스라는 팀이 있으니, 우리도 데브옵스 팀을 만들자'라는 식으로 접근한다면, [그림 2]와 같은 모습이 될 것으로 예상됩니다. 즉 데브옵스의 조직 체계를 구성한다고 해서 데브옵스가 실현될 순 없습니다. 서로 다른 입장과 상황이 있는 개발자-팀-회사, 운영자-팀-회사 간에 상당한 노력을 통해 만들어 내는 것이 더 중요한 것이죠. 이와 비슷한 사례로 애자일(Agile) 문화가 있습니다. 2000년대 초반 '애자일 소프트웨어 선언문'으로 다양한 애자일 방법론이 주목을 받았었죠. 개발에서 빠르고 유연한 방법을 강조하며, 이후 많은 기업들이 애자일 방법론을 도입하게 되며 유행처럼 번져갔습니다. [그림 7] Agile 프로세스 여기서 애자일 문화를 도입한 많은 기업들이 간과했던 사실은, 애자일 문화 도입 자체가 '해결책'이라고 생각했다는 점입니다. 이보다 기존의 조직 문화에서 애자일 문화를 도입하는 것이 적합한 상황인지, 기존의 프로세스보다 효과를 발휘할 수 있는지, 팀 구성원들이 충분히 적응할 수 있는 문화인지 등을 우선적으로 고려하는 것이 더 중요합니다. 데브옵스 역시 마찬가지로 기존의 조직 규모, 문화, 프로젝트의 특성에 대한 명확한 이해가 먼저 선행되어야 합니다. 데브옵스 도입 전에 조직의 현재 상황과 목표를 면밀히 평가한 후, 점진적으로 도입하는 것이 중요하죠. 대기업이나 캐시카우가 있는 기업들이 데브옵스를 실행했다고 해서, 또는 단지 트렌드라는 이유만으로 도입하는 것은 위험할 수 있습니다. 오해 3. 데브옵스는 빠른 소프트웨어 배포만을 목표로 한다? 데브옵스는 속도만 중시하고 품질이나 안정성을 소홀히 한다는 인식이 있습니다. 하지만 데브옵스는 소프트웨어의 빠른 배포뿐만 아니라, 품질과 안정성 그리고 보안을 동시에 추구해야 합니다. 이에 따라 지속적인 통합과 배포(CI/CD), 자동화된 테스트, 모니터링 등을 통해 이러한 목표를 달성하려고 노력해야 하죠. 이처럼 데브옵스라는 도구를 도입하고 데브옵스 팀을 구성했다고 해서, 데브옵스가 즉각적으로 실현되는 것은 아닙니다. │ 데브옵스(DevOps) 보다 선행되어야 하는 '이것' 진정한 데브옵스를 실현하기 위한 방법을 한 문장으로 표현한다면 다음과 같습니다. "싸우지 말고 함께 소프트웨어 시스템 혹은 서비스를 만들어봐요" 힘 빠지는 결론일 수도 있습니다. 하지만 데브옵스를 도입하기 이전에 더 선행되어야 할 것은 각각 다른 업무의 조직원들끼리 서로를 이해하고, 협력하며, 보다 안정적인 시스템과 서비스를 제공하는 '문화'를 만드는 것이 더 현실적인 행동이라고 생각합니다. 물론 데브(Dev)와 옵스(Ops)는 우선순위가 동일하지 않고, 동일한 언어를 사용하지 않을 수 있으며, 매우 다른 관점에서 문제 해결될 가능성이 높습니다. 이처럼 팀을 하나로 모으기 위해서는 상당한 시간과 지속적인 노력이 필요한 것이죠. 그렇다면 어떤 방식으로 팀 협업 문화를 만들어야, 데브옵스를 보다 성공적으로 도입할 수 있을까요? │ 데브옵스(DevOps) 성공을 위한 첫걸음 먼저 조직 내의 문화를 이해한 다음, 조직 내 교육과 커뮤니케이션을 강화하는 것이 중요한데요. 구체적인 방안을 제안한다면 다음과 같습니다. 로테이션 프로그램 도입 진정한 데브옵스를 실현하려면, 무엇보다 각 부서의 업무적인 이해가 중요합니다. 가장 직관적인 방법으로는 다른 부서의 업무를 '직접 체험'해 보는 것입니다. 예를 든다면 개발자가 운영팀의 업무를 수행하거나, 보안 팀이 개발 업무에 참여하는 등, 다양한 부서 간의 경험을 쌓아 보는 것이죠. 이를 통해 서로의 업무 환경과 각 부서 간의 역할을 이해하는 데 큰 도움을 받을 수 있습니다. 지식 공유 플랫폼 구축 내부 플랫폼이나 문서화된 지식 공유 시스템을 구축하는 방법도 있습니다. 각 부서의 업무와 프로세스에 대한 정보를 쉽게 접근할 수 있도록 하는 것이죠. 예를 들면 데브옵스 문화나 기술적인 도구, 프로세스 등을 포함하여 다양한 지식을 공유합니다. 이를 통해 각 부서의 업무 특성을 명확히 이해할 수 있고, 협업을 원활하게 진행할 수 있겠죠. 정기적인 교육 세션 빠르게 변화하는 기술에 대응하기 위해, 팀원들이 지속적으로 학습하고 발전해야 합니다. 정기적인 교육은 이러한 학습을 지원하는 데 중요한 역할을 하는데요. 예를 든다면 새로 도입된 CI/CD 도구에 대한 워크숍을 개최하여, 팀원들이 해당 도구의 사용법과 이점을 학습할 수 있도록 합니다. 또한 현재 사용 중인 프로세스 개선점에 대한 세션을 주기적으로 열어, 팀원들이 학습한 내용을 바탕으로 업무에 효율적으로 적용할 수 있습니다. 만약 특정 분야에 강점을 가진 팀원이 있어 주기적으로 자신의 경험과 성과를 공유한다면, 팀 전체에게 영감을 주고 학습 기회를 제공할 수도 있겠죠. 스탠드 업 미팅 활성화 매일 정해진 시간에 각 팀원이 자신의 진행 상황이나 이슈, 계획을 간결하게 공유합니다. 정해진 시간을 지키고 효율적인 미팅 진행을 위해, 공유하는 팀원들의 말에 집중하되 '총 15분'을 초과하지 않도록 노력하는 것이 중요합니다. 이를 통해 짧은 시간 동안 팀 전체가 빠르게 현재 상황을 파악하고, 실시간으로 정보를 공유하며, 신속하게 문제를 해결할 수 있습니다. 이처럼 위와 같은 방법들을 통해 구성원들이 효과적으로 협력할 수 있는 환경을 조성하는 노력들이 필요합니다. 。。。。。。。。。。。。 많은 기업들이 경쟁에서 지지 않기 위해 도입하고 있는 데브옵스(DevOps). 하지만 진정한 데브옵스를 실현하기 위해서는 "싸우지 말고 소프트웨어 시스템 혹은 서비스를 만들어 봐요"라는 문장처럼 각각 다른 업무의 조직원들끼리 서로 이해하고, 협력하는 문화가 선행되는 것이 매우 중요합니다. 즉 너희 팀 vs 우리 팀 업무를 구분하지 않고 함께 협력하여, 아이디어를 생산하고, 가치를 창출해야 하는 것이죠. 혹시 아직 데브옵스를 도입하기 전이거나, 도입 이후에 올바르게 활용되고 있는지 궁금하시다면, 오늘 이 글을 통해 심도 있게 생각해 보시는 건 어떨까요? 2024.02.14
기술이야기 디자인 시스템이 필요한 이유와 핵심요소는? 기술이야기 디자인 시스템이 필요한 이유와 핵심요소는? “우리나라 금융 유니콘 기업이 개발과정에서 1,000시간을 아낀 비결” “애플과 구글이 제품을 기획하고 개발할 때 가장 중요하게 생각하는 것” 디자인 시스템은 무엇일까? 위에 있는 두 문장의 답은 바로 ‘디자인 시스템’이에요. 고객이 하나의 브랜드를 접하는 순간부터 끝까지 지속적으로 동일한 경험을 하게 해주는 디자인 시스템의 중요도는, 점점 더 커지고 있죠. 디자인 시스템은 시맨틱 컬러, 컴포넌트 디자인, 디자인 토큰 등을 구축하여 제품 전반에서 사용자가 일괄적인 시각적 경험을 할 수 있도록 도와주고 있어요. 제품을 더 빠르고 효율적으로 만들어주기도 해요. 그리하여 이번 시간에는 1) 디자인 시스템은 구체적으로 무엇이고 2) 브레인즈컴퍼니는 어떤 노력을 하고 있는지 살펴볼게요! 디자인 시스템의 요소1 : 시맨틱 컬러 ▲Zenius ITSM 버튼에 적용된 컬러 시스템 디자인 시스템의 중요 요소 중 하나인 '시맨틱 컬러'는, 사용 방법에 따라 색상 이름을 지정하는 방법이에요. 브레인즈컴퍼니의 제니우스(Zenius)도 시맨틱 컬러를 사용하고 있는데요. Primary, Secondary, Tertiary, Ghost, Gray, Severity Color 등으로 구성되어 있어요. 여기서 Primary 컬러는 UI 전체의 주요 구성 요소에 대한 역할을 해줘요. 가장 중요한 액션에 사용하며, 화면에서 가장 강력한 클릭 유도 문안인 CTA(call to action)을 강조하기 위해 사용하기도 하죠. ▲Zenius ITSM Primary 컬러의 변천사 Zenius ITSM은 BI 컬러를 보완한 Primary 색상을 사용 중이며, Secondary와 Tertiary는 이와 어울리는 색상을 지정해 사용하고 있어요. 브레인즈컴퍼니의 컬러는 선명한 파란색이지만, 제품 화면에 사용하기에는 채도가 너무 높아 두 번의 GUI 테스트를 거쳐 위와 같이 보완한 색상이 나왔어요. Secondary와 Tertiaty 사용 시 화면 구성의 위계질서에 따라 색상을 설정하여 중요도(중요, 보조, 부가)를 표현하기도 해요. [잠깐의 TMI?] 브레인즈컴퍼니 브랜드 색상인 Blue는 한국에서 가장 선호도가 높은 색상이며, 신뢰·젊음·성실·책임감 등의 이미지를 지닌 색상이에요. ▲컬러 팔레트 디자인 시스템의 요소2 : 심각도 컬러 ▲심각도 컬러 팔레트 '심각도 컬러'는 Zenius에서 사용하는 시맨틱 컬러의 일종이에요. Zenius에서 발생한 이벤트를 알려주는 색상으로 총 6단계의 색상을 구축하여서 사용하고 있답니다. 정상, 무해, 주의, 위험, 긴급, 치명의 6단계이며 위와 같은 컬러를 사용하고 있어요. 디자인 시스템의 요소3 : 디자인 토큰 '디자인 토큰'은 디자인 시스템의 시각적 디자인 요소이며, 디자인 관련 변수를 저장하는 데 사용하는 기본 요소에요. 기존에는 피그마(Figma)에서 컬러나 폰트 등을 Style로만 지정할 수 있었어요. 같은 색상을 여러 개의 항목에 적용할 경우, 토큰 별로 사용할 수 없는 점이 굉장히 불편했죠. 하지만 Figma의 Variable 기능이 업데이트된 후, 토큰을 만들 수 있게 되었어요! 브레인즈컴퍼니의 메인 제품 Zenius는 총 세 개의 테마를 사용 중이라, 디자인 토큰 시스템을 테스트하고 있답니다. ▲컬러 토큰 시스템 위와 같이 속성이 다른 두 개의 디자인에 동일하게 Neutral-500 컬러를 사용했는데요, 토큰별로 색상을 적용할 수 있는 시스템이라, 같은 색상을 지닌 다른 속성이어도 개별로 컬러 관리가 가능한 장점이 있어요. 개발자와의 협업에도 굉장히 좋은 시스템이랍니다! 。。。。。。。。。。。。 제니우스(Zenius) 제품이 태어난 지 오래된 만큼, 제품 디자이너가 여러 번 바뀌었어요. 컬러 시스템에 대한 가이드도 중간중간 변경되었죠. 브레인즈컴퍼니 디자인팀은 컬러 시스템을 다시 재정비하기 위해, 여러 가지 테스트 과정을 거치고 있어요. 아직은 구축 단계에 있어 디자인 팀 내의 규칙이나, 개발자들과 네이밍 규칙 등 협의해야 할 일이 적진 않아요. 그래도 구축이 완료된다면 정말 소통하기 편해질 거 같아요! 이제 곧 완성될 '디자인 시스템'을 통해 한층 더 성숙해질 Zenius! 많은 기대 부탁드려요? 2023.12.12
기술이야기 [ZNG 개발기] #1. ZNG와 Vue.js 기술이야기 [ZNG 개발기] #1. ZNG와 Vue.js 안녕하세요. 브레인즈컴퍼니 개발 3그룹에서 ZNG의 프론트엔드를 개발하고 있는 1년차 신입 개발자 김현수입니다. ZNG란 Zenius New Generation의 약자로, 브레인즈컴퍼니의 핵심 서비스인 제니우스의 차세대 버전을 말합니다. ZNG는 데이터베이스를 제외한 프론트엔드와 백엔드는 완전히 제로베이스에서 시작하는 장기 프로젝트이기에, 프로젝트를 진행하는 과정에서 새롭게 배운 것, 개발자로서 성장, 팀 개발 경험 등을 기록하고자 ZNG 개발기를 작성하게 됐습니다. ZNG 개발기는 달마다 개발과정에서 있었던 이슈들, 경험, 공부한 내용 등을 기술적인 내용과 함께 작성할 예정입니다. 다 함께! <사진 설명: 펭수, "렛츠고!"> 1. ZNG가 무엇인가요? ZNG는 기존 제니우스에서 발생하는 불편함을 해소하고자 탄생한 프로젝트입니다. 기존 제니우스에는 어떤 불편함이 있었고, 이를 해소하고자 ZNG는 어떤 컨셉을 목표로 개발할 것인가에 대해 알아보겠습니다. 같은 부서 선배 동료들을 쫄래쫄래 따라다니며 물어보고 배워가며 정리한 내용을 바탕으로 작성하는 글입니다. 혹시라도 틀린 부분이 있다면 알려주시면 감사하겠습니다! <사진 설명: 자환님은 아니라고 하셨다...> 제니우스는 B2B 솔루션 서비스 상품으로 사용자의 요구사항에 맞게 유연한 변경이 가능해야 합니다. 새로운 컴포넌트를 추가 한다거나, 여러 기능을 합치는 등 다양한 요구사항에 대응해야 합니다. 당연히도 현재 제니우스는 사용자의 요구사항에 맞춰 조금씩 커스텀해 서비스되고 있습니다. 그러나 효율적이지 못한 상황이 생기기도 합니다. 대체로 같은 내용의 코드를 반복해서 작성하는 상황이 그러합니다. 같은 형태를 가진 컴포넌트여도 출력하고자 하는 데이터의 종류가 다르다면 컴포넌트를 통째로 다시 만들어야 했습니다. 반복적인 작업은 개발자에게 피로감을 주게 되고 단순히 피로감을 넘어, 개발자에게 목표 의식을 저하시킬 우려가 있습니다. <사진 설명: 다양한 종류의 컴포넌트가 있다. 사용자마다 원하는 컴포넌트, 데이터가 다를 수 있다.> 이런 불편함을 해소하는 방법으로, ZNG는 코드의 재사용성을 높이기 위해 노력합니다. 각 기능끼리의 의존도는 낮추고, 독립성을 높여서 반복적인 작업을 최소화합니다. 같은 형태를 가진 컴포넌트에 대해서 데이터만 다르다면 데이터만 바꿔주면 됩니다. 사용자마다 다른 종류의 데이터를 출력하기를 원할 경우 더 빠르고 효율적인 대처가 가능합니다. 이러한 컨셉과 Vue.js의 Component를 관리하는 방법이 일치해 ZNG는 Vue.js로 개발하게 됐습니다. 2. ZNG와 Vue.js Vue.js에는 여러가지 특징이 있습니다. 그 중에서도 Vue Component에 대해서 자세히 알아보겠습니다. Vue Component Vue Component란 화면을 구성하는 하나의 블록입니다. Component는 하나의 전체 화면일수도 있고 전체 화면 중 일부분을 차지하는 또 하나의 작은 화면일수도 있습니다. 따라서 화면을 구현할 때 화면 전체를 한 번에 구현하지 않고, 부분적으로 구현해 관리하는 것이 가능합니다. Component를 활용하면 화면을 구조화해 직관적으로 개발할 수 있으며 코드의 재사용성이 올라갑니다. <사진 설명: 화면의 영역을 블록으로 쪼개 재활용 가능항 형태로 관리하는 것이 Vue Component> ZNG 기능 중 모니터링은 추출한 데이터를 그래프, 표 등을 통해 다양한 형태의 컴포넌트로 보여줍니다. 각각의 컴포넌트는 서로 다른 모양을 통해, 서로 다른 데이터를 보여줍니다. 반대로 말하면 하나의 컴포넌트에 대해서 모양, 데이터만 다르게 준다면 여러 종류의 컴포넌트를 만들 수 있습니다. 다음은 ZNG 코드 일부입니다. PCContainer는 컴포넌트를 감싸는 블록입니다. component 태그 안에 있는 ‘is’옵션에 ‘컴포넌트의 이름’을 넣어 그리고자 하는 컴포넌트를 선택할 수 있습니다. PCLineChart는 그래프를 그리는 컴포넌트입니다. highchartsOptions에 어떤 데이터를 넣느냐에 따라 원하는 그래프를 그릴 수 있습니다. <사진 설명: PCContainer> 하나의 PCContainer로 여러 모양의 컴포넌트를 그리고, 하나의 컴포넌트(PCLineChart)로 다양한 데이터를 표현할 수 있습니다. 컴포넌트를 만들기 위해 새로운 코드를 작성하지 않고, Vue Component를 통해 코드를 재사용함으로써 효율적이고 직관적인 코드를 개발할 수 있습니다. 부모와 자식 컴포넌트 관계 각 Vue Component는 데이터를 주고받을 때 부모-자식 관계를 갖는 것이 일반적입니다. <사진 설명: 부모-자식 컴포넌트> 부모는 자식에게 데이터를 전달할 수 있어야 하며, 자식은 부모에게 일어난 일을 알려야 합니다. 부모는 props를 통해 자식에게 데이터를 전달하며, 자식은 emit로 이벤트를 호출해 부모에게 데이터를 알립니다. 부모 컴포넌트와 자식 컴포넌트는 분명히 구분된 컴포넌트지만 props와 emit을 통해 의사소통이 가능합니다. ZNG는 최상단 레이아웃에서 서버로부터 데이터를 받아와 props를 통해 각 컴포넌트로 데이터를 보내줍니다. 하위 컴포넌트에서 발생한 이벤트를 통해 다시 상위 컴포넌트로 데이터를 전달해 데이터를 관리합니다. 다음은 ZNG 코드 중 일부입니다. 자식 컴포넌트는 props를 통해 부모 컴포넌트로부터 데이터를 받고, emit을 통해 부모 컴포넌트로 이벤트를 통해 알립니다. props와 emit을 통해 컴포넌트 간 의사소통을 수행하지만, 각 컴포넌트마다 코드를 분리하기 때문에 관리가 편하고 쉽게 재사용할 수 있습니다. 3. 마치며 ZNG의 개발 방향성과 이와 관련해 Vue.js의 Component 특징을 정리해봤습니다. Vue Component는 이전부터 알고 있던 개념이지만 직접 개발한 코드와 비교해보니 머릿속에 명확하게 정리되는 느낌이었습니다. 특히 코드를 다시 보면서 개념을 리마인드하는 과정이 좋았습니다. ZNG 개발기는 이제 시작입니다! 앞으로도 계속될 ZNG 개발기에 많은 관심 부탁드리며 ZNG 프로젝트를 성공적으로 수행할 때까지 응원해주세요! <사진 설명: 개발의 신이시여... 지켜봐 주세요!> [출처] https://kr.vuejs.org/ https://ko.wikipedia.org/wiki/Vue.js https://www.instagram.com/waterglasstoon/ 2022.08.03

1