출제기준 세세항목: 플랫폼 기능 분석 · 플랫폼 성능 특성 분석 · 운영체제 분석 · 네트워크 분석 · DBMS 분석 · 비즈니스융합분석
이사 갈 집을 고르기 전에 지금 집에 무엇이 있고 무엇이 불편했는지 먼저 정리해 두면, 새 집에서 같은 실수를 덜 하게 됩니다. 소프트웨어도 마찬가지입니다. 새 시스템을 만들거나 기존 시스템을 고치려면, 지금 시스템이 어떤 기능을 하고, 어떤 장비와 소프트웨어 위에서 돌아가며, 다른 시스템과 무엇을 주고받는지부터 알아야 합니다. 이 작업을 현행 시스템 분석이라고 합니다.
이 분석을 건너뛰면 곤란한 일이 생깁니다. 새 시스템이 기존 장비에서 돌지 않거나, 다른 부서 시스템과 연결이 끊기거나, 지금도 잘 되던 기능을 빠뜨리는 식입니다. 현행 시스템 분석은 개발 범위를 정하고, 새로 사야 할 것과 그대로 쓸 것을 가르는 출발점입니다.
분석은 보통 위에서 아래로 내려갑니다. 먼저 시스템이 어떤 하위 시스템으로 이뤄져 있고 어떤 기능과 인터페이스를 가졌는지 파악합니다. 다음으로 아키텍처와 그 위에서 쓰는 소프트웨어 구성을 살핍니다. 마지막으로 하드웨어와 네트워크 구성까지 확인합니다. 이 항목의 세세항목들은 이 흐름 속에서 각각 한 부분을 맡는다고 보면 됩니다.
플랫폼은 애플리케이션이 올라가 동작하는 바탕을 말합니다. 기차가 달리려면 선로와 역이 필요하듯, 애플리케이션이 돌아가려면 하드웨어, 운영체제, 미들웨어, DBMS 같은 바탕이 필요합니다. 이 바탕 전체 또는 일부를 플랫폼이라고 부릅니다.
플랫폼 기능 분석은 현재 플랫폼이 어떤 기능을 제공하는지, 그리고 그 위의 애플리케이션이 플랫폼의 어떤 기능에 기대고 있는지를 정리하는 일입니다. 예를 들어 지금 시스템이 특정 웹 애플리케이션 서버(WAS)의 기능을 써서 세션을 관리하고 있다면, 새 시스템에서도 같은 기능이 필요한지, 다른 플랫폼으로 바꾸면 무엇을 다시 만들어야 하는지 판단할 수 있습니다.
플랫폼을 잘 고르면 여러 사람이 같은 바탕 위에서 개발하고 서비스를 주고받기 쉬워져 개발·운영 비용이 줄어듭니다. 반대로 특정 플랫폼에만 묶인 기능이 많으면 나중에 바꾸기 어려워지므로, 분석할 때 이런 의존 관계를 함께 적어 둡니다.
기능이 있다고 끝이 아닙니다. 같은 기능이라도 얼마나 빠르고 안정적으로 해내는지가 중요합니다. 플랫폼 성능 특성 분석은 현재 플랫폼의 성능을 숫자로 파악해, 새 시스템이 어느 정도의 성능을 가져야 하는지 기준을 세우는 일입니다.
자주 쓰는 지표를 알아 두면 좋습니다. 응답 시간은 요청을 보낸 뒤 첫 응답을 받기까지 걸린 시간입니다. 경과 시간(반환 시간)은 일을 맡긴 뒤 완전히 끝날 때까지 걸린 전체 시간입니다. 처리량은 정해진 시간 동안 처리한 일의 양입니다. 사용률은 CPU나 메모리 같은 자원이 얼마나 바쁘게 쓰이고 있는지의 비율입니다. 가용성은 시스템이 필요할 때 실제로 쓸 수 있는 상태였던 시간의 비율입니다.
성능을 재는 방법으로는 실제 사용자에게 불편했던 점을 묻는 방법, 이미 있는 성능 측정 결과나 운영 문서를 확인하는 방법, 같은 조건에서 부하를 걸어 직접 재 보는 벤치마크 테스트가 있습니다. 숫자 하나만 보지 말고, 사람이 몰리는 시간대처럼 상황별로 나눠 보는 것이 중요합니다.
운영체제는 하드웨어를 관리하고 그 위의 프로그램들이 하드웨어를 쉽게 쓸 수 있게 해 주는 기본 소프트웨어입니다. 서버에서는 주로 유닉스(Unix) 계열, 리눅스(Linux), 윈도우(Windows) 서버를, 휴대용 기기에서는 안드로이드(Android)와 iOS를 많이 씁니다.
현행 운영체제를 분석할 때는 종류와 버전, 지원이 언제까지 이어지는지, 그 위에서 돌아가는 소프트웨어가 무엇인지를 확인합니다. 지원이 끝난 버전이라면 보안 업데이트를 받을 수 없으니 새 시스템에서는 바꿔야 할 대상이 됩니다.
운영체제를 고를 때 따지는 기준은 크게 품질 측면과 지원 측면으로 나눠 기억하면 편합니다. 품질 측면에서는 오래 멈추지 않고 돌아가는지(신뢰도)와 많은 요청을 빠르게 처리하는지(성능)를 봅니다. 지원 측면에서는 문제가 생겼을 때 도움을 받을 수 있는지(기술 지원), 프린터나 저장 장치 같은 장비를 지원하는지(주변기기), 그리고 구입비뿐 아니라 운영·유지보수까지 합친 전체 비용(총소유비용, TCO)을 봅니다. 공개 소프트웨어는 구입비가 낮아도 기술 지원 비용이 따로 들 수 있으니, 처음 가격만 보고 판단하지 않습니다.
시스템은 혼자 돌아가지 않고 여러 서버와 사용자 기기가 네트워크로 이어져 있습니다. 네트워크 분석은 이 연결 구조를 파악하는 일이며, 가장 먼저 보는 자료가 네트워크 구성도입니다. 구성도에는 서버, 라우터, 스위치, 방화벽 같은 장비가 어디에 있고 어떻게 이어져 있는지가 그려져 있습니다.
구성도를 보면 업무별로 어느 서버에서 처리하는지, 외부와 내부를 가르는 경계가 어디인지 알 수 있습니다. 이를 통해 보안상 약한 곳, 예를 들어 외부에서 바로 닿을 수 있는 서버가 무엇인지 찾을 수 있습니다. 또 한 장비가 고장 나면 전체가 멈추는 지점(단일 장애 지점)이 있는지, 장비를 이중으로 둬서 대비하고 있는지도 확인합니다.
네트워크를 계층으로 나눠 이해하는 대표적인 기준이 OSI 7계층입니다. 아래에서부터 물리, 데이터 링크, 네트워크, 전송, 세션, 표현, 응용 계층이며, 장비도 계층에 따라 나눠 볼 수 있습니다. 허브는 물리 계층, 스위치는 데이터 링크 계층, 라우터는 네트워크 계층에서 주로 동작합니다. 문제를 찾을 때 '어느 계층의 문제인가'부터 좁혀 가면 원인을 빨리 찾을 수 있습니다.
DBMS(데이터베이스 관리 시스템)는 데이터를 저장하고 여러 사용자가 동시에 안전하게 꺼내 쓸 수 있도록 관리해 주는 소프트웨어입니다. 오라클(Oracle), MySQL, MS-SQL Server, PostgreSQL 등이 많이 쓰입니다.
현행 DBMS를 분석할 때는 어떤 제품과 버전을 쓰는지부터, 테이블이 몇 개이고 데이터가 얼마나 빨리 늘고 있는지, 저장 공간은 얼마나 남았는지, 백업은 얼마나 자주 하는지, 서버를 이중으로 두고 있는지 등을 확인합니다. 특히 데이터가 늘어나는 추세는 새 시스템의 저장 용량과 성능 목표를 정하는 데 꼭 필요합니다.
DBMS를 고를 때 따지는 기준도 운영체제와 닮았습니다. 장애가 나도 서비스를 이어 갈 수 있는지(가용성), 많은 질의를 빠르게 처리하는지(성능), 다른 시스템이나 기존 데이터와 잘 맞물리는지(상호 호환성), 기술 지원을 받을 수 있는지(기술 지원), 전체 비용이 얼마인지(구축 비용)를 봅니다. 운영체제 쪽 첫 기준을 '신뢰도'라고 부르는 자료와 '가용성'이라고 부르는 자료가 함께 있으니, 두 이름 모두 '오래 멈추지 않고 서비스하는 능력'을 가리킨다고 알아 두면 됩니다.
지금까지는 시스템의 기술적인 바탕을 살펴봤습니다. 하지만 시스템은 결국 업무를 돕기 위해 존재합니다. 비즈니스 융합 분석은 현재 업무가 어떤 흐름(업무 프로세스)으로 처리되고, 시스템이 그 흐름의 어느 부분을 맡고 있는지를 함께 분석하는 일입니다.
예를 들어 주문 접수는 시스템으로 하지만 재고 확인은 담당자가 엑셀로 따로 한다면, 그 사이에 손이 많이 가고 실수도 생깁니다. 이런 끊긴 부분을 찾아내면 새 시스템이 무엇을 이어 줘야 할지가 보입니다. 또 클라우드, 모바일, 빅데이터, 인공지능 같은 새 기술을 업무에 결합하면 어떤 새로운 서비스나 효율이 생길지도 함께 검토합니다.
정리하면, 앞의 다섯 가지가 '무엇으로 돌아가는가'를 본다면 비즈니스 융합 분석은 '무엇을 위해, 어떻게 더 잘 돌아가게 할 것인가'를 봅니다. 두 시선이 함께 있어야 기술적으로도 맞고 실제로도 쓸모 있는 새 시스템을 설계할 수 있습니다.
학사 관리 시스템을 새로 만들기 전에 현행 시스템을 분석해 보니, 서버 한 대가 이미 제조사 지원이 끝난 운영체제 버전을 쓰고 있었습니다. 보안 업데이트를 받을 수 없으므로, 새 시스템 계획에 운영체제 교체와 그 위에서 돌던 프로그램의 호환성 확인을 범위로 넣었습니다.
평소에는 응답 시간이 1초 안팎이던 수강 신청 화면이, 신청 시작 직후에는 10초 넘게 걸린다는 불만이 있었습니다. 운영 기록을 보니 그 시간대에 서버 CPU 사용률이 거의 100%였습니다. 이 숫자를 근거로 새 시스템의 목표 처리량과 서버 증설 규모를 정했습니다.
쇼핑몰의 주문은 시스템으로 받지만 배송 업체에 넘길 목록은 담당자가 매일 엑셀로 옮겨 적고 있었습니다. 비즈니스 융합 분석에서 이 끊긴 구간을 찾아, 새 시스템에서는 주문 정보가 배송 업체 시스템으로 바로 넘어가도록 연동을 요구사항에 넣었습니다.