반복영역 건너뛰기
주메뉴 바로가기
본문 바로가기
제품/서비스
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
블로그
열기
메인 페이지로 이동
블로그
기술이야기
블로그
최신이야기
사람이야기
회사이야기
기술이야기
다양한이야기
[행사] 브레인즈컴퍼니 전략사업본부 ‘happy 호프데이’
[전시회] ‘CDA 컨퍼런스’를 통해 해법을 제시한 브레인즈컴퍼니
이화정
2023.12.05
페이스북 공유하기
트위터 공유하기
링크드인 공유하기
블로그 공유하기
[전시회] 브레인즈컴퍼니 ‘소프트웨이브 2023’에서 새로운 비전 제시
지난 11월 29일, 브레인즈컴퍼니가 잠실 롯데호텔에서 열린
「CDA컨퍼런스」
에 참가했어요. 브레인즈컴퍼니는 이번 컨퍼런스를 통해
성공적인 클라우드 전환을 위한 비전과 해법
을 제시했는데요. 자세한 후기를 바로 들려드릴게요!
CDA
컨퍼런스는
「클라우드 데
이터센터 협의회(이하 CDA)」에서 주관한 이번 컨퍼런스는, '클라우드 네이티브 및 SaaS 전환을 위한 클라우드 데이터 센터의 첫걸음'이라는 주제로 클라우드 분야별(SaaS, Cloud, Infra) 전문기업 30개사가 참여했는데요.
▲CDA 컨퍼런스 2023 개회식
▲
CDA 컨퍼런스 2023 기조강연
이번 컨퍼런스는 기업·공공·의료·교육 등 다양한 영역에서 디지털 서비스/솔루션/인프라를 제공하는 많은 회원사들이 참가하여, 클라우드에 대한 비전과 서비스의 우수성을 소개했어요. 총 천명 이상이 참가한 이번 컨퍼런스는 크게 기조강연·주제별강연·전시부스로 나누어 진행됐어요.
성공적인 클라우드 전환을 위한 모니터링 방안 강연
브레인즈컴퍼니는 강연과 부스 운영을 통해, 클라우드 전환기의 성공적인 모니터링에 대한 비전을 제시했는데요. 먼저
'성공적인 클라우드 전환을 위한 효율적인 모니터링 방안'
이라는 주제로 강연을 진행했어요.
브레인즈컴퍼니의 오다인 님께서
과도기에 봉착한 클라우드 전환 현황, 클라우드 전환 과도기 하이브리드 환경에서의 모니터링 전략, 성공적인 모니터링 솔루션 선택 기준
이렇게 세 가지 이슈를 중심으로 구성하여 강연을 진행하셨어요.
이날 강연을 통해 브레인즈컴퍼니는, 과도기에 봉착한 클라우드 전환기에서 성공적으로 모니터링할 수 있는 명확한 해법을 제시해 드렸어요.
총 이백여 명 이상의 참관객들이 브레인즈컴퍼니의 강연을 경청해 주셨는데요. 강연의 뜨거운 열기는 브레인즈컴퍼니의 부스에 대한 관심으로 이어졌어요.
열띤
관심이 이어진 브레인즈컴퍼니의 부스
브레인즈컴
퍼니 부스에선, 브로슈어와 제품데모(Demo) 시연을 통해 제니우스(Zenius)에 대해 자세히 알리는 시간을 가졌는데요.
▲큰 관심을 끌었던 브레인즈컴퍼니의 부스
부스에 방문한 참관객분들은 클라우드뿐 아니라, 온프
레미스 환경도 모니터링이 가능한 점과 EMS·APM·SIEM·ITSM 등 핵심제품들의 기능을 모듈화하여 사용할 수 있는 부분에도 큰 관심을 보여주셨어요.
브레인즈컴퍼니의 심재걸, 김선효, 오다인, 최승훈 님께서 Zenius 제품에 대한 구체적인 설명을 진행해 주셨는데요. 기본적인 설명 이후에 참관객분들의 상황별로 다양한 문의가 이어졌어요. 이에 대해 막힘없이 답변을 해드리며 열띤 분위기를 이어갔답니다!
부스에 방문하신 한 참관객분은
"지금 회사가 클라우드로의 전환기에 있어, 모니터링 서비스가 필요했었어요. 오늘 설명을 들어보니 Zenius가 적합하다고 판단되어 도입에 대해 긍정적으로 검토할 계획이에요"
라며 만족감을 나타내셨어요.
브레인즈컴퍼니는 이번 CDA 컨퍼런스를 통해, 새로운 비전을 제시하고 많은 분들께 Zenius를 알릴 수 있었어요.
앞으로 CDA 컨퍼런스뿐만 아니라 다양한 온·오프라인을 통해 IT 인프라 모니터링의 새로운 비전을 제시하고, Zenius의 우수성을 알릴 예정인데요. 여러분들의 많은 관심과 응원 부탁드릴게요🙌
#CDA
#CDA컨퍼런스
#브레인즈컴퍼니
이화정
프리세일즈팀
프리세일즈팀에서 마케팅, 내외부 홍보, 콘텐츠 제작을 담당하고 있어요.
필진 글 더보기
목록으로
추천 콘텐츠
이전 슬라이드 보기
브레인즈컴퍼니, KB저축은행에 '제니우스 ITSM 3.0' 구축
브레인즈컴퍼니, KB저축은행에 '제니우스 ITSM 3.0' 구축
‘Zenius ITSM 3.0’ 성공적 시장 진입 향후 ITAM, PMS로 도메인 확장 브레인즈컴퍼니(대표 강선근)는 KB저축은행 차세대 시스템 구축 프로젝트에서 자사 ‘제니우스(Zenius) ITSM 3.0’으로 IT 서비스 체계 표준화 및 IT 관리업무 자동화 시스템을 구축했다고 3일 밝혔다. 이번 ITSM(IT Service Management) 구축으로 KB저축은행은 차세대 IT 서비스 플랫폼을 통해 IT 서비스에 대한 사용자 요청을 접수하고, 처리하는 과정과 그 이력을 단일 시스템에서 관리할 수 있게 됐다. 또 방화벽, 원장, 형상관리 등 10개의 시스템과 연동해 IT 관리업무를 자동화할 수 있게 됐다. Zenius ITSM 3.0은 로우코드 기반의 워크플로우 엔진과 구성정보데이터베이스(CMDB) 엔진을 탑재했으며, 워크플로우를 쉽게 생성하고 수정할 수 있는 프로세스 및 폼 디자이너를 포함하고 있다. 워크플로우는 기업마다 다른 IT 서비스를 각자 환경에 맞게 일의 순서와 역할을 손쉽게 편집할 수 있으며, 코딩없이 15개 이상의 다양한 폼 컴포넌트를 통해 업무 신청서를 쉽게 디자인할 수 있다. CMDB 엔진은 IT 서비스와 연관된 인프라, 소프트웨어, 다양한 문서 등을 생명주기에 따라 다양한 세부 항목으로 관리할 수 있다. 정희찬 ITSM 개발팀장은 “Zenius ITSM 3.0은 ITSM 구축 프로젝트 특성상 갖게 되는 시스템 통합(SI) 사업의 한계를 극복하기 위해 관리 프로세스를 모듈화함으로써 필요한 프로세스를 선택적으로 도입할 수 있다. 향후 유연하게 프로세스를 확장할 수 있는 플랫폼 개발에 역량을 집중한 제품”이라며 “다음 목표는 사용자 편의를 위한 부가기능을 강화하면서 Zenius ITSM의 워크플로우 엔진을 기반으로 ITAM(IT Asset Management), PMS(Projenct Management System) 등을 통해 도메인을 확장하는 것”이라고 말했다. 브레인즈컴퍼니는 올해를 기점으로 ITSM 수요가 가파르게 증가할 것으로 예상하고 있다. 2018년 신외감법 개정으로 내부회계관리제도가 감사로 상향 조정돼 많은 기업들이 내부회계관리제도의 '정보기술일반통제(ITGC)' 위험요소에 대응하기 위해 ITSM 도입을 고려하기 때문이다. 그러나 기업들이 ITSM 도입에 있어 도입 및 관리 비용에 부담을 느끼고 있는 실정이다. 이 가운데 이번 KB저축은행의 차세대 ITSM의 성공적인 공급은 Zenius ITSM 3.0이 다양한 고객의 요구사항을 보다 넓은 관점에서 충족시킬 수 있는 솔루션임을 입증한 것이다. 강선근 브레인즈컴퍼니 대표는 “2005년 첫 출시된 Zenius ITSM은 최근 로우코드 기반으로 고객이 직접 커스터마이징하고, 기존 제품 대비 쉽고 빠르게 고객의 요구를 반영할 수 있도록 업그레이드한 제품”이라며, “그 결과 수익성을 확보하면서 고객 편의성을 제고시킨 Zenius ITSM 3.0을 출시했고, 향후 소규모 기업이나 스타트업 등에서도 적은 비용으로 ITSM 솔루션 도입이 가능한 SaaS(Software as a Service, 서비스형 소프트웨어) 형태의 서비스 출시를 계획하고 있다”고 밝혔다.
2022.11.03
시련이 많았던 경험자의 CI/CD 간략 소개
시련이 많았던 경험자의 CI/CD 간략 소개
과거에는 근로자 1명이 기획/설계/구현 테스트까지 진행이 가능했다고 합니다. 하지만 최근에는 근로자 1명이 기획부터 테스트까지 진행하는 일은 거의 드물다고 볼 수 있습니다. OLD SCHOOL 지금 이 시간에도 많은 회사 내의 개발자들은 자신에게 주어진 기능 구현을 훌륭하게 완수하기 위해서 모니터를 째려보고 있습니다. 모니터를 째려보다가 자신이 작성한 내용을 다른 팀원에게 공유하고자 혹은 반대로 다른 팀원이 작성한 내용을 공유받고자 '형상 관리 시스템'을 사용하고 있습니다. CVS와 SVN으로 대표되는 이 시스템은 최근들어 Git을 많이 사용하는 추세라고 합니다. 필자 역시 여러 프로젝트에서 해당 시스템을 사용도 해보았고, 연동하여 다른 시스템을 구현한 경험이 있습니다. 하지만 프로젝트 마다 해당 시스템 사용에 있어서 몇몇 시련이 있었습니다. "차주에 전체 기능 리뷰가 있습니다. 각 파트 별로 코드 커밋해주세요." 라고 PM(Project Manager) 또는 PL(Project Leader)이 요청을 하면, 각 하위 PL(Part Leader)은 파트(Part)에 돌아가 파트원들에게 이 내용을 공유하고, 개별 개발자들은 자신이 작성한 코드를 관리 시스템에 커밋하게 됩니다. 잠시 후 형상 관리 시스템에서 작성 코드를 내려 받은 PL(Part Leader)은 아래와 같은 상황에 직면하게 됩니다. - 동료의 작성 코드에는 관심 없이, 본인의 작성물만 커밋하는 경우 - 별도의 공지 없이 이미 작성된 파일 등을 삭제하여 커밋하는 경우 - 약속되지 않은 환경이나 lib으로 작성한 코드를 커밋하는 경우 프로젝트에 따라 기간이 길어지거나 다른 여러 상황이 발생하면 위의 문제보다 더 많은 문제를 경험하게 됩니다. 각 파트 단위로 위와 같은 문제가 해결되고 정상적으로 컴파일, 빌드까지 완료되면, PL(Part Leader)들은 파트별로 단위테스트를 완료하고 결과가 정상적이면 결과를 품질관리자에게 통보합니다. 각 파트별로 완료 통보를 받은 품질관리자는 다시 관리 시스템에서 전체 작성물을 수동으로 내려받아 통합테스트를 진행합니다. 통합테스트까지 완료되었다면 해당 내용을 릴리즈관리자에게 통보합니다. 릴리즈관리자는 바뀐 부분만 찾아서 변경하면 시간적으로 적용이 빠르겠지만 '바뀐 부분만 변경하면 될까?'라는 의심으로 전체 작성물을 수작업으로 전처리(컴파일 & 빌드)하고 다시 수작업으로 릴리즈하게 됩니다. 만약 진행상의 이슈가 없다면 이제 기능 리뷰 준비가 완료됩니다. 단계별로 문제 없이 진행되고 모든 기능을 확인하였다고 하지만 기능 리뷰 혹은 데모만하면 꼭! 오류가 발생하여 난처한 상황이 종종 발생하곤 합니다. 필자 역시 이런 경우가 많았으며 그때마다 문제 부분을 찾기 위해 많이 고생했습니다. 아래의 개념은 아마도 저 같은 경험을 하고 있는 많은 사람들을 위한 것이 아닌가 싶습니다. CI (Continuous Integration, 지속적인 통합) '지속적인 통합'이란 개발 과정에서 생산되는 코드의 관리와 코드의 문법적인 오류 확인 및 기능 점검(=테스트)을 특정한 일정에 진행하는 것이 아니라 날마다 혹은 특정 시간마다 진행하여 코드 및 기능에 대한 품질을 유지하는 개념이라고 말할 수 있을 것입니다. 앞에서 언급했던 과거 모습을 개선하는 노력은 CI 라는 개념이 나오기 이전부터 많은 개발사 혹은 팀에서 그들만의 문화나 관습으로 처리하는 경우가 있었을 것입니다. 하지만 문제는 새로운 구성원이 생겼을 때 입니다. 조직 문화를 새로이 접하는 이들에게는 이를 설명하고 이해시키는 일은 시간과 노력이 드는 일이니까요. 하지만 이젠 일반적인 Java 개발팀에서는 SVN(or GitHub)+Jenkins+Maven+JUnit으로 구성하는 개발 환경을 사용하고 있습니다. 다만, 프로젝트 목표나 목적되는 환경에 따라 약간씩 다른 환경을 구성하기도 합니다. 그러나 대부분의 경우 Open Source 기반으로 CI 개념을 구성하는 경우가 많습니다. 이는 일단 무료라는 큰 장점과 많은 레퍼런스가 있어 구성하기 편리하고 "우린 Open Source인 SVN과 Jenkins를 사용합니다. 일단 자세한 개념과 동작 원리는 너트뷰 선생님께..." 라고 하며 짧은 노력으로 교육을 끝낼 수 있어 그런 것이 아닌가 합니다. CI 개념을 활용하는 개발 프로젝트에서는 UI 메뉴 혹은 구현 단위 기준으로 구분하여 개발파트나 개발자를 할당하고는 합니다. 각각의 개발자는 할당받은 구현 범위에 대한 문제를 개별적으로 개발 도구를 활용하여 구현하고 구현 내용을 형상 관리 시스템에 커밋합니다. 이런 과정을 다른 개발자들도 같이 수행한 후에 빌드 자동화 환경에서 컴파일 및 빌드 스크립트에 맞춰서 문법적으로 확인된 결과물을 만들고 이를 다시 기능이 확인이 가능한 테스트 스크립트에 맞춰서 테스까지 진행합니다. 만약 테스트 과정에서 비정상적인 결과가 발생할 경우, 해당 내용 수정 후 위의 작업을 다시 진행하게 됩니다. 이런 일련의 절차는 일정 시간 준위 단위로 수행되어 구현하고 있는 기능을 주기적으로 확인하는 과정을 수행합니다. 올바른 진행을 위하여 개발자 개개인에게 분장되는 업무의 크기가 비슷해야 한다고 생각됩니다. 개발자별로 업무의 크기가 서로 다른 겨우, 결과물이 정상적이라고 볼 수 없게 될 것이고 그렇게 된다면 테스트 결과 역시 믿을 수 없는 경우가 발생할 것입니다. CD (Continuous Delivery/Deploy, 지속적 제공/배포) 지속적인 통합(CI)을 사용하던, 기존의 개발 환경을 사용하던, 결국 작성된 결과물은 최종적으로 운영환경에 적용되어 사용작 혹은 타 시스템과 연결되어야 합니다. 그래야 제품 개발 또는 프로젝트가 완료됩니다. CD는 결과물을 운영환경에 적용하는 방식을 나타내는 환경으로써 결과물 적용 여부를 판단하는 행위를 담당하는 주체가 누구냐에 따라, Continuous Delivery와 Continuous Deploy로 구분됩니다. Continuous Delivery는 CI 환경을 통하여 자동으로 컴파일 및 빌드가 되고, 테스트된 결과물에 대해서 릴리즈 관리자가 적용 시점마다 테스트 결과 및 서비스 영향도를 판단하여 수동으로 적용하는 방식이며, Continuous Deploy는 결과물은 항상 옳고 서비스 영향도는 없다고 미리 판단하여 자동으로 적용하는 방식입니다. 아마도 대부분의 개발 환경에서는 Continuous Delivery로 적용하고 있기에 CD라고 표기되는 경우 Continuous Delivery를 의미하는 경우가 많을 것입니다. 소프트웨어 솔루션을 제작하는 개발팀에서는 아마도 Continuous Delivery로 또한 MSA 기반의 서비스를 제공하는 개발팀에서는 Continuous Deploy를 사용하는 편이 여러 관계를 보았을 때 유리하다고 판단합니다. 하지만, 개발팀의 업무 성격과 제품 혹은 서비스의 출시 시기 등이 CD 방식을 결정하는 가장 중요한 요소가 될 것입니다. 지금까지 CI/CD 도입 배경과 내용을 필자의 경험을 바탕으로 간략하게 정리하였습니다. 개발자들이 자기가 맡은 기능 혹은 프로세스에만 전념할 수 있는 훌륭하고 편리한 개발 환경 및 적용 환경이 언제 어떻게 나타나게 될지 궁금합니다. 가능하다면, 많이 바꿔서 따라가기 귀찮은 시니어들과 새롭게 따라가야하는 주니어 개발자 모두에게 즐거운 환경이 등장했으면 합니다. 감사합니다.
2023.08.22
다음 슬라이드 보기