반응형

이전에 OO기업 1차 실무 면접 시, 렌터카 시스템 흐름 및 구성도에 대하여 자유롭세 작성하여 제출하는 과제가 있었다.

아래 그림은 해당 과제에서 제출했던 구성도 자료이며, 열심히 고민하고 설계했었기에  블로그 기록으로 남겨놓으려 한다.

 

반응형

고객 채널 시스템 구축시에는 고려해야 할 사항이 몇 가지 있다. SI Project를 수행 하면서 다양한 고객 채널 시스템을 구축해 보았고, 이러한 경험을 통해 많은 부분을 배울 수 있었다. 그 중 공통적으로 고려해야 하는 사항 몇가지를 설명하고자 한다. 물론 고객 채널 목적 및 성격에 따라 해당 부분은 Project 리소스 낭비로 바라 볼수도 있다. 따라서, 해당 부분은 Project 성격 및 환경에 따라 적절히 적용하면 될 듯 하다. 

 

1. SEO (Search Engine Optimization) 검색 엔진 최적화

- 웹사이트가 검색 결과에 더 잘 보이도록 최적화하는 과정 

 

2015년도 SI Project 당시 SEO라는 단어를 처음 접하게 되었다. 당시 SEO는 지금처럼 활성화 되지 않았던 시기였다. 

2017년도에 첫 이직을 하였는데, 이직하는 회사에서 SEO 대해 말하면 SEO가 뭔지 묻는 사람이 많았다. SEO는 Google 검색엔진 내 검색결과 노출을 높이기 위한 활동이라고 생각하면 비교적 이해하기 쉽다.

내가 SEO에서 수행했던 영역은 URL Path 구조 개선 부분이였다. 보통 이전에 URL이라고 하면, Get 방식의 URL 구조를 자주 사용하였다. 

 

Get 방식, 예시) www.test.com/test_id=1&content_id=100/  

 

위 예시는 단순하게 작성하였지만 실제 웹사이트에서 사용하는 URL은 저것보다 훨씬 더 복잡하게 구성되는 경우가 많다. 

SEO분야에서는 URL Path의 경우, 계층구조를 띄고 있어야 하며 URL 內 Title (제목)을 포함하고 있어야 한다. 예시는 아래와 같다.

 

위와 같은 메뉴 구성이 있다고 가정해 보자. SEO를 적용한 일반적인 URL 구성은 다음과 같다.

 

1) 2 Depth Menu 1 구조 : URL : www.test.com/1-depth-menu-2/2-depth-menu-1 

- 2뎁스 메뉴를 표현 시 URL 內 1뎁스 2뎁스 메뉴명이 포함되어야 하며, 띄어쓰기는 하이픈 '-' 으로 대체하고 알파벳 대소문자는 소문자로만 표현하도록 한다.

 

2) 3 Depth Menu 1 내 게시글1 : URL : www.test.com/1-depth-menu-3/2-depth-menu-2/3-depth-menu-1/게시글-1   

- 1번과 마찬가지로 URL 內 Depth 별 메뉴명이 포함되어야 하며 게시글이 있을 경우, 게시글의 제목이 URL에 포함되어야 한다. 

 

당시 Project 內 Framework 로 Spring을 사용하고 있었고, SEO URL구성을 위해 Interceptor 를 사용하여 모듈을 개발하고 SEO 부분을 구현했다.

 

2. 크로스브라우징 (Cross Browing)

- 웹사이트 구축 시 모든 브라우저에서 기획 의도 대로 화면이 정상 표출되도록 하는 작업이다. 

 

보통, SI Project 를 진행하다 보면, Edge 브라우저에서는 UI/UX 부분이 정상적으로 동작 되지만 Chrome 나 Safari 에서는 정상적으로 동작되지 않는 경우가  있을 수 있다. 이러한 Issue는 고객이나 User에게 지속적으로 표준화된 서비스를 제공 할 수 없을 뿐더러, 기업 입장에서는 브랜드 이미지를 손상시키는 요소가 될 수 있고, 나아가 신뢰성 부분에서도 부정적인 평가를 받을 수 있다. 

 

때문에, 제품을 인도하거나 User 에게 서비스를 Open 하기 전에는 크로스브라우징 TEST를 필수적으로 진행하여 품질을 만족해야 한다.  

 

3. 반응형 웹 VS 적응형 웹 

- 2011년도 N-스크린에 대한 개념을 처음 접하였다. 멀티미디어가 발달하면서 다양한 디바이스가 출시 되고, 이에 따라 User는 다양한 디바이스에서 동일한 서비스를 제공받기를 원했다. 때문에, 고객 채널을 구축시에는 웹 디자인 시 반응형 웹/적응형 웹 2개 중 1개를 선택하여 다양한 화면에서 적절한 레이아웃을 통해 동일한 서비스를 제공할 수 있도록 하는 것이 좋다. 

 

1) 반응형 웹 : CSS 미디어 쿼리를 사용하여 User가 사용하는 기기 특성을 검사하여 웹사이트에서 검사된 내용을 바탕으로 디자인과 레이아웃을 화면에 맞춰지도록 함 

 

2) 적응형 웹 : 웹사이트에서 검사된 기기 정보를 기반으로 미리 만들어진 레이아웃을 불러오도록 함

 

4. 웹접근성  

- 웹 접근성 (Web Accessibility), 장애인 고령자 User 등이 웹사이트에서 제공하는 정보에 비장애인과 동등하게 접근하고 이해할 수 있도록 보장하는 부분이다.

 

보통 공공 SI Project에서 고객 채널을 구축하게되면 웹 접근성 인증을 받아야 하는 경우가 많다. 

 

5. CDN (Content Delivery Network) 

- CDN은 지리적으로 분산된 서버들을 연결한 네트워크로서 웹 컨텐츠의 복사본을 사용자에 가까운 곳에 두거나 동적 컨텐츠의 전달을 활성화하여 웹 성능 및 속도를 향상할 수 있게 한다. 

- 구축하고자 하는 고객 채널이 글로벌향이라면, CDN은 아마 중요한 고려사항 될 것 이다.

자주 사용되는 솔루션은 아래와 같다.

1) Akamai

2) AWS-CloudFront

3) Google-Cloud CDN

 

고객 채널 구축 시 위 5가지 정도는 고려하는 것이 Project에 도움이 될 것 이다. 

반응형

이전 글, SI (System Ingreation) Project 회고 #2 (스포츠 SI)에서 언급하였듯이 내가 수행한 SI Project 에서는 유관 시스템 간 Data Interface 가 매우 중요한 부분이였다.

데이터를 송/수신하기 위하여 XML (eXtensible Markup Language) / JSON (JavaScript Object Notation) 을 모두 사용하였고, 전체적인 아키텍처는 아래 그림과 같다. 

 

 

대회 기간 동안 각 Venue 별로 Game Event 가 다수 진행된다. Event 가 진행되는 동안 수많은 데이터들이 생성되며, 해당 데이터들은 Info시스템으로 송신되어 정보시스템에서 관리 및 조회 될 수 있다. 데이터들이 동시 다발적으로 송신되기에 서버 상태에 따라 데이터를 안전하게 수신받을 수 있도록 ActiveMQ를 활용하여 클라이언트-서버 패턴의 미흡한 부분을 보완하여 브로커 패턴으로아키텍쳐를 설계했다. 

 

각 Venue 별 GRS시스템은 클라이언트로서 Producer 역할을 하며, ActiveMQ의 Queue를 통해 메세지를 수신하여 부하 부분을 완화 할 수 있었다. Consumer 부분은 별도의 Java 기반의 Paser 서버 모듈을 구축하여 XML을 Parsing 하여 DB서버에 Data Insert 작업을 수행하도록 구축 했다. 

 

쥬니어 시기 2-3년차에 (2013~2015) 에 비교적 단순한 Web Application Programming 뿐 아니라, 위와 같은 아키텍쳐를 설계하고 직접 구축해 봄으로써 IT시스템을 조금 더 넓은 시야로 볼 수 있었다. 

 

반응형

Career의 첫 시작은 SI전문 기업인 "쌍용정보통신" 에서 약 5년 간 개발자로 근무 하였다. 당시 나의 개발실은 스포츠SI 개발실이였다. 스포츠 SI Project가 생소한 분들이 많을 것으로 생각된다. 하지만, 스포츠 SI 또한 공공SI 중 하나이다. 보통 공공 SI라하면 행안부나 우정국 관련 Project를 생각하겠지만 스포츠 대회는 보통 나라에서 주관을하고 공공사업으로 진행 한다. 

 

총 4번의 SI Project를 수행한 경험이 있다. 스포츠 대회를 운영하는 부분에는 많은 IT장비들과 업무 시스템이 필요하기에 그 규모가 작지 않다. 규모가 큰 만큼 이해관계자, Project 수행 구성원이 많다.

 

아래 4개가 내가 참여했던 Project 리스트 이다. 베트남 다낭 Project 外 모두 50억 이상 규모이며, IT Outsourcing 외에 50명~150명 정도의 개발자가 투입되어 개발/운영이 진행 되었다.

 

1. 2018 평창 동계 올림픽 정보통합 구축 프로젝트 (약 350억) - '15.10~'17.08 (1년 10개월)

2. 2016 다낭 베트남 아시아 비치게임 정보통합 구축 프로젝트 협력회사로 참여 (약 10억) - '16.04 ~ '16.10 (7개월)

3. 2015 경북 문경 세계군인체육대회 정보통합 구축 프로젝트 (약 50억) - '14.10~'15.10 (1년) 

4. 2014 인천 아시아 경기대회 정보통합 구축 프로젝트 (약 250억) - '12.08~'14.10 (2년 2개월)

 

스포츠 SI는 주요 시스템 영역을 3가지 정도로 구분 할 수 있다.

 

1. GMS (Game Menagement) : 스포츠 대회 운영을 위한 시스템  

 예시) 출입국 관리 시스템, 선수촌 관리 시스템, 선수등록 시스템, 보안 시스템 등 

 

2. GRS (Game Result System) : 스포츠 대회 內 각 종목 별 게임운영을 위한 시스템 

 예시) 수영 경기 운영 시스템,  각 종 기록 장비, 스코어 보드 등 

 

3. Info (Infomation System) : 스포츠 대회 공식 홈페이지 및 Official 기록을 배포하는 정보 시스템 

 예시) 공식 홈페이지, Official 공식 기록 정보 시스템, 모바일 시스템 등 

 

스포츠 SI는 보통 글로벌 Project로 진행되며, 기록 장비, 측정 부분에서 독보적인 솔루션을 보유하고 있는 "스위스타이밍" 이라는 회사와 협업을 많이 한다. 

 

예를 들어, 육상같은 경우 정확하고 세밀한 기록 측정을 통해 순위를 가리고 기록을 관리한다. 때문에 관련 분야에서 특화된 솔루션을 보유하고있는 기업이 필요하며 그 중 하나가 "스위스타이밍"이라는 회사가 있다. 아시아권에서는 "세이코"가 있다.

 

[참고]

https://www.swisstiming.com/

 

[글로벌 Project]

프로젝트 발주 및 사업은 국내에서 이루어지지만 스포츠 대회의 경우, 글로벌인 경우가 많기에 Project 또한 글로벌 방식으로 진행 되어진다. Agile 방법론이 활성화 되지 않은 시기 이기에 예측적 개발 방법론인 Waterfall 방식으로 Project가 통합관리 되었고, 변경요청서 (Change Request)가 아주 타이트하게 관리 되었던 부분이 기억에 남는다. 또한, 글로벌 Project 였기에 해외 업체 및 해외 이해관계자와 의사소통 부분이 많았다.

 

[주요 시스템]

스포츠 SI의 핵심은 단 한번의 실수도 용납되지 않는 GRS (Game Resul System) 시스템 운영이다. 상상을 해보면 당연하다. 100M 육상 이벤트를 진행했는데 기록이 측정되지 않았다고 가정해보자. 해당 Issue는 대회 조직위원회 뿐 아니라, 국가적 망신이 된다. 때문에 GRS는 Live 에 강해야 하며 실수가 용납되지 않는다. 

 

[핵심 기술영역]

해당 GRS에서 발생한 데이터는 실시간으로 Info 시스템으로 송신되며, Info 시스템은 기자들 (Press) 에게 실시간으로 공식 기록 정보를 제공한다. 때문에 해당 SI Project에서는 데이터 송/수신 기술이 매우 중요하게 다뤄졌다. 이러한 부분 때문에 IOC (International Olympic Committee) 에서는 데이터 피드 부분을 전문적으로 관리하고 해당 자료를 Open 하여 타 대회에서 참고할 수 있도록 한다.

개인적인 생각으로는 XML 이나 Josn  데이터 구조를 설계할 때 ODF (Olympic Data Feed) 를 참고하면 많은 도움이 될 수 있다고 생각한다. 

 

[Sample]

https://odf.olympictech.org/

 

데이터 송수신 방식에 대한 자세한 내용은 다음 글에서 설명하도록 하겠다. 

 

 

 

 

 

 

 

반응형

IT 계열 Career Path를 발전시켜 온지 올해 13년차가 되었다. 사회 초년생 때에는 내 Career 을 정리하고자 하는 마음이 크지 않았다. 하지만, 시간이 흐를 수록 Career를 어느정도 정리하고 글로 남겨놔야 하겠다는 생각이 들었다. 그렇게 마음을 먹고 작성하는 첫번째 글이다. 

 

첫 번째 주제는 SI(System Ingreation) Project 이다. 그 중에서도 대규모(Enterprise) SI Project 에 대하여 이야기 하려고 한다. 

 

SI Project 사업 특성상 여러 종류가 있겠지만 규모적으로 Project를 구분할 수 있다. 중소 시스템 구축을 위한 비교적 작은 규모의 Project, 또 다른 하나는 공공사업 부문에서 다뤄지는 대규모의 정통적 SI Project이다. (신규 시스템 구축 또는 차세대 구축 등이 Enterprise에 해당된다)

 

나의 첫 회사는 SI 전문기업인 "쌍용정보통신"이였다. 쌍용정보통신의 대부분 매출은 그룹사 SM(System Management)보다는 외부 SI Project 매출로 이루어져 있었다. 나는 공공사업 본부 스포츠 SI팀에 배정되어 약 5년 간 개발자로 직무를 수행하였다.

 

주요 프로젝트의 규모 및 수행 기간은 아래와 같다. 

  1. 2018 평창 동계 올림픽 정보통합 구축 프로젝트 (약 350억) - '15.10~'17.08 (1년 10개월)

  2. 2015 경북 문경 세계군인체육대회 정보통합 구축 프로젝트 (약 50억) - '14.10~'15.10 (1년) 

  3. 2014 인천 아시아 경기대회 정보통합 구축 프로젝트 (약 250억) - '12.08~'14.10 (2년 2개월)

 

Career를 관리해 오면서 크고 작은 SI/SM Project를 경험했지만 실직적으로 Project 관리 전문성에 큰 자양분이 된 것은 쥬니어 시절의 공공사업 SI Project 수행 경험이였다. 

 

Project의 영업 과정(제안서 등)에서 부터 Open 후 운영까지의 수행 경험, Predicitive(예측적) 개발 방법론의 각 단계별 AtoZ 업무 등을 수행하며 Project Life Cycles를 모두 경험하였고, 이로인해 정확한 이해를 기반으로 Project 수행/관리 전문성을 보유할 수 있게 되었다.  

 

대규모 Project를 수행하며 얻은 직무 전문성은 다음과 같다. 

 

1. Web Programming 지식 뿐 아니라, Infra/Network에 대한 전문 지식을 얻을 수 있다.

보통 SM(System Management)으로 Career를 시작한 쥬니어 분들은 비교적 Infra/Network에 대한 지식이 부족한 경우가 많다. 구축 Project 경험이 없고, 보통 이미 구축된 시스템에서 개선 및 운영 작업만 진행하다 보니 Infra/Network 작업 부분을 접할 기회가 많지 않기 때문이다. 아래와 같은 세부사항을 알고 시스템을 운영하는 것과 모르고 운영하는 것은 추후 시스템 고도화나 신규 Project 진행 시에 개인별로 성과 차이가 발생할 수 있다고 생각한다. 

 

[예시]

 1) Server OS에 대한 개념, Linux에 대한 Permission, 계정, 소유자, 그룹 소유자, bash_profile, Mount, 컴파일러 개념 등  

 2) Web Server, Was Server에 대한 기술적 메커니즘, 로드밸런싱(L4) 개념, 이중화 구조, 세션클러스터링, Full GC 등 

 3) 내부망, 전용망, 인터넷망 (DMZ) 등

 4) Fire-wall(방화벽), NAT(Network Address Translation), 사설IP, 공인IP, DNS(Domain name server) 등 

 

2. Predicitive (예측적) 개발 방법론에 기반한 Project의 각 Phase 별 모든 관리 절차를 경험할 수 있다.  

 - 제안요청서, 견적요청서, 제안서, 사업수행계획서, 과업내역서, SoW(Statement of Work) 등

 - 분석 : 요구사항 목록, 요구사항 정의서, 요구사항 추적표 등 

 - 설계 ; 프로그램 목록, 메뉴구조도, UI화면 설계서, Interface 설계서, 프로세스 흐름도 등 

 - 개발 :  테이블 목록, 테이블 정의서, ERD, 단위 TEST 결과서 등

 - 테스트 : 통합 TEST 시나리오, 통합 TEST 결과서, 부하 TEST, 모의해킹, 사용자 인수 TEST 등 

 - Open : Open 계획서

 - 운영 : 프로젝트 운영 결과서 

 

위 절차에 따라 체계적으로 프로젝트를 관리하는 방법과 각종 도구 사용 경험을 할 수 있다. 

 

3.  Project 요구사항 정의를 위한 고객 인터뷰 및 Product 벤치마킹 등을 통해 IT Trend를 빠르게 접할 수 있다.

나의 경우는 2015년도에 Project를 수행하면서 Web Application 성능 측정 (리소스 압축관리, Page 로딩 속도 개선, 이미지 로딩 속도 개선 등), Google Analytics, SEO 등을 적용하고 운영하며 그 성과를 측정하고 Reporting 했던 업무 경험이 있다. 

 2017년도에 이직을 진행할 때, 프로젝트 수행 성과로 SEO 관련 업무를  작성 했는데 당시 이직 할 회사의 리더급(상무) 분이 SEO가 뭔지 모르겠다며 개념을 질의하시던게 지금도 기억에 남는다. 그 만큼 SEO가 활성화 되지 않았던 시기였으며, SI였기에 비교적 IT Trend를 빠르게 접하고 받아들여, 직접 구현하고 시험에 볼 수 있는 기회가 있었다고 생각한다. 

 

4. 다양한 Project 팀, 이해관계자들과 일하면서 의사소통 관리에 대한 중요성과 커뮤니케이션 스킬에 대해 배울 수 있다. 

대규모 Project를 진행하다 보면 의사소통의 중요성을 깨닫게 된다. 예를 들어, 15명 정도로 구성된 개발 파트가 있다고 가정해 보자. 보통은 선임 개발자나 공통 영역 개발자 분이 개발에 대한 프로토타입을 만들어 개발 가이드를 제공하는 것이 일반적이다. 하지만 의사소통이 제대로 되지 않는다면 이러한 개발 Rule이 모두 깨지고 추후, 유지보수 뿐 아니라 보안 감사나 소스 정적분석/점검 등에서 많은 지적사항이 나올 수 있다. 그로 인해 예상치 못한 유지보수 공수가 증가 될 수 있으며, 이러한 결과는 Project 수행과정의 납기 부분에 Risk 요소가 될 수 있다. 

 

또 다른 경우는 고객과 함께 요구사항 정의 시 의사소통이 서로 잘 되지 않는다면 고객이 원하지 않는 엉뚱한 결과물(인도물)이 나올 수 있다.

때문에, 의사소통 Ground Rule 수립이 매우 중요하며, 상대와 내가 이해 수준이 동일한지 확인하는 습관이 매우 중요하다. 

대량의 자료 및 공통 규칙 등은 Pull 방식으로 PMIS나 공통 게시판을 사용하여 Rule을 공지하고, 정확한 의사소통이 필요한 경우는 프로토타입을 만들어 상대방과 소통하는 것이 효과적일 수 있다. 이 처럼 여러 Case 별로 커뮤니케이션 스킬을 배울 수 있다. 

 

5. FW(Framework)에 대한 메커니즘을 이해 할 수 있고, 전체적인 시스템 아키텍처를 볼 수 있는 시야를 얻을 수 있다.  

1번에서 이야기 했던 Infra와 Network 에 대한 이야기의 연장선일 수도 있지만, FW(Framework)의 정확한 메커니즘을 이해 할 수 있다. 

우리나라 SI Project의 대부분은 Web Application 이며 보통 Java 기반의 Spring Framework를 사용한다. 

하지만, 의외로 FW(Framework)를 직접 구축해본 경험이 없는 개발자가 상당히 많다. SM의 경우, 개별적으로 사이드 Project를 진행하지 않는다면 Enterprise급 Spring Framework를 구축할 기회가 많지 않다. 

FW(Framework) 를 맨땅에 구축해본 개발자와 이미 안정성있게 구축된 FW(Framework)에 들어가 MVC 패턴을 준수하며 개발하는 개발자는 추후 개발능력 성장에 많은 차이가 있다고 생각한다. 아마 개발자라면 나의 이런 말을 이해 할 것이라 생각한다. 

 

[정리]

위 5가지 뿐만 아니라, 얻을 수 있는 직무 전문성과 장점이 무수히 많지만 글로 다 풀어내기엔 내용이 많으므로 다른 글에서 조금씩 정리하겠다. 추가로, 나의 개인적인 생각으로는 SI 직무를 먼저 경험하고 SM직무로 전환하는 것이 개발자나 Project Manager에게 Career 측면에서 더 도움이 될 수 있다고 생각한다. 

+ Recent posts