2016년 9월 26일 월요일

작은 시스템 설계

가장 공유가 많았었던 문맥에 맞도록 코드들과 합치고 변형해서 넣을 예정.


최근 작은 시스템 설계 및 검수 의뢰가 들어왔다. 수백억 짜리 공사인데 IT 관련 기술이 들어가야 한다고 했다. 이와 관련한 일련의 고민 과정들을 적어 보려고 한다. 자세한 것은 공개하기 힘드므로... 
Embedded + SI +  X(비공개)였다. 시스템 통합에는 DB와 원격 관리, 백업 기능은 기본 중의 기본이다.

1

시스템이 나누어져 있으면 큰 시스템이 아니고 작은 시스템이라고 보면 된다. 가장 먼저 고려되어야 할 것은 가용성이다. 학부 과정에서 배우는 고가용성이란 다음과 같다. 간단히 말해서 고장 없이 잘 돌아야 한다는 것이다.
ko.wikipedia.org
이 말은 맞기도 하지만 보험회사의 광고와 비슷하게 내면을  들여다보면 조금 다른 점이 있다.
고장 나지 않는 시스템은 없으며, 버그 없는 소프트웨어는 없다는 것

작은 시스템 설계에서 가장 먼저 고려되어야 할 것은 이 고장들을 관리할 수 있는 수준으로 만들어야 한다는 것.

2

공사가 들어갈 때 일단 콘크리트를 치고 나면 바꾸기 힘든 부분이 있다. 특수한 부분에 설치되는 케이블 등은 再공사가 힘들다는 것이다. 보안전문가에게는 크레커에게 뚫려봤던 경험이 중요하듯이 책에서 모아서는 볼 수 없는 작은 것들이 성패를 결정한다. 이미 많은 책 내용의 사이사이에는 조금씩 노하우가 적혀있지만 무심코 지나치는 것들의 중요성을 아는 것. 사람들은 그것을 노하우라고 부르고. 공개하지 않으면 '비법'이 된다.

 네트워크 연결은 유선/무선을 다 고려해야 한다. 무선과 보안 기술이 많이 발전했기에 하드웨어상으로 문제가 발생했을 때 Alternative 할 수 있도록 구성을 해야 한다. LAN선은 100미터 넘게도 설치할 수 있겠지만 15M 이상 리피터나 게이트웨이, 허브 등의 구성이 없을 때는 노이즈가 낀다. 튀는 값 때문에 어느 순간에는 네트워크 오류가 자주 발생한다. 네트워크 계층에서 알아서 해 주겠지만 TCP/IP만 믿지 말자. 디버깅 단계에서는 모든 것을 믿어야 하고 설계 단계에서는 모든 것을 의심해야 한다. 비용이 높아질 수 도 있기 때문에 임베디드 장비에 무선 기능 탑재는 옵션으로 두고 사람 손이 닿을 수 있는 곳에 동글을 꽂을 수 있도록 하자. 침수, 누수, 랜선 불량 등으로 IT 문제 때문에 수십 년 뒤에 벽을 뜯어내는 수고로움을 덜기 위해서다. 

케이블은 기가비트 지원이 기본이겠지만 영상 용량이 4K로 가면서 계속 늘고 있기 때문에 10기가 이상 지원으로 할까? 

IDC에서의 최근 트렌드를 검색해 보고 비용 문제와 고려해서 선택해 보자. 이미 해봤다고 자만하지 말고 최신 트렌드를 계속해서 검색하고 이미 검증된 부분과 아닌 부분들을 잘 선택해야 한다.

3

소프트웨어 설계할 때 고려해야 할 것은 고장이 나면 어느 파트에서 고치는 것이 가장 빠르고 비용이 적게 들어  가는가?이다. SI 중에 임베디드 장비와 연결된 부분이 있다. 영상 PLAY 부분인데. 이 프로젝트에서는 임베디드 장비에서 다운로드 후에 영상을 PLAY 할지. 스트리밍으로 지원할지 2가지 옵션이 있었다. 연결 장비가  수십대였는데 중앙에서 관리가 가능해야 했다. 영상을 보내주는 서버는 따로 구성을 하는 것이 맞다. 확장 가능한 것도 이유겠지만 백업 플랜에서 저 비용으로 갈 수 있기 때문이다. 여기서 왜 기술 공개를 잘 안 하는지에 대한 이유가 나온다. 백업 플랜을 아마존 Unlimit 같은 개인 클라우드로 저 비용을 노린다고 하면? 한국 상륙한 아마존이 뭔가 대책을 세우지 않겠나... 물론, 이 시스템에서도 고려를 하고 있고. 또 B2B 기업들이 가격이나 내부 정책을 바꾸었을 때의 대안도 마련되어 있어야 한다. 자잘한 툴의 경우 삼성같이 큰 기업에서도 엔터프라이즈 라이센스가 아닌 개인 라이센스로 개발하는 일이 많았었다.

 이번 시스템에서는 대세에 따라 스트리밍으로 가는 것이 맞다는 의견이 있었지만 이번 프로젝트에서는 임베디드 장비에서 PLAY 되는 것으로 했다. 대신 Bittorrent나 곰플레이어가 지원하는 기능처럼  다운로드하면서 플레이가 가능하도록 해야 했다. 그 이유는 임베디드 장비 1대가 고장 났을 때는 1대만 영상 PLAY가 되지 않는다. 그러나 제어 서버나 영상 서버가 고장 났을 때는 전체 PLAY에 문제가 생긴다. 중앙 서버의 고장을 고칠 동안 받은 영상들은 PLAY를  계속되도록 해야 마치 고장 나지 않은 것처럼 보일 수 있다. 임베디드 장비에 어느 정도 코드를  집어넣을 수 있는, 프로그래밍을 할 수 있는 수준이라 많은 고민들은 임베디드 장비로 이관하기로 하였다.
 이렇게 되면 중앙 제어 서버도 특정 정보들만 제공을 하는 수준이고 임베디드 장비가 알아서 서버에 접속하고 서버에서 환경설정 정보를 받아오고 스스로 판단해서 행동하게끔 되어 있다. 가령 자동으로 전원 on/off 하는 경우도 메시지 큐 형식으로 서버에서 상태 변화  configuration  format을 만들면 임베디드 장비가 필요한 시간에 스스로 접속해서 정보를 읽고 사람들이 있는지 영상 PLAY는  어디까지 되었는지 등 알아서 판단하고 전원을 off 하는 것이다.
 고가용성을 지키기 위해서는 시스템 간 연결고리를 최대한 느슨하게 해 주어야 한다. 이것 하나만 생각하면 된다.

4

이제 고려해야 할 것은 소프트웨어 개발의 문제점이다. 나 역시 기업에서 개발팀장을 하고 있는 입장이지만 프로젝트 성공을 위해서는 사람을 다룰 줄 알아야 하고. 실무적 측면에서 사람 다루는 데는 돈, 혹은 기술 밖에는 없다. 비전만 맞추고 각자 알아서 일하면 되는 큰 시스템과는 달리 작은 시스템에서는 전통적인 상하 방식이고, 장점은 그것이 실패했을 때 아랫사람에게는 책임을 지우지 않는 방식이라는 것. 즉, 독박쓰는 시스템이다. 그래서 보수가 괜찮다.
 나 역시 입으로 일하거나 일정한 위치 선점을 해서 내 것을 챙기면 된다. 그러나 그런 마음가짐으로는 설계를 할 수 없다. 최근 아키텍트가 코더에 비해 낮은 위상으로 인식되는 것도 이와 같은 이유에서이다. 최근 가트너에서 연락 왔을 때도 내가 컨택 채널로 고정되어 권한도 받았으나, 초기 세팅을 하고 실무는 실무자를 정해서 넘겨줬다. 어떤 포지션이던 중간자 역할이 되어 버리면 중간자 입장만 고수하고 문제 발생시 책임 소재를 한정 지어 버린다. 확실하게 일할 기회를 주기 위해서는 '중간자'를 만들면  안 된다. 물론, 그 기회를 받고 싶은지 물어봐야 한다. 강압적으로 책임감이 요구되는 일을 주고 결과를 보면 대부분 '퇴사'로 이어진다.
법적으로 이미 폐지된 연대보증 시스템을 싫어하기는 하지만  '무한책임'에서 오는 긴장감은 본받아서 유지해야 한다는 것.

자, 그럼 초기 셋업 코드는 내가 짜 놔야 한다. 해당 프로젝트가 시작되면 결국엔 실무자가 가장 잘 알기 때문에 프로젝트 중반부터는 담당 엔지니어가 잘하면 잘할수록 설계자의 말을 듣지 않는다. 그러나 초기 코드를 만든 사람의 발언은 먹혀든다. 그래서 초기 코드를 만들거나 초반에 도움을 많이 줘야 프로젝트를 성공시킬 수 있다. 어차피 대부분은 실패해도 덕지덕지 붕대 감아서 무조건 성공시켜야 하는 입장이기는 하다.

초기 코드는 생짜로 전부 직접 짜지 않는다. sourceforge, github 등을 검색해서 쓸만한 애들을  찾아본다. 그리고 라이브러리 구매는 기본이다. 메신저나 화상회의 같은 경우 라이브러리를 사면 손쉽게 구축이 가능하다. 고급 개발자 1달 인건비만 따져보더라도 남는 장사고, 고급 개발자가 한 달 안에 구현해도 품질 테스트에 시간이 또 걸린다. 시간은 가장 큰 '비용'의 척도고, 돈을 쓰는 사람 입장에서는 가격보다는 기간을 더  중요시한다. 4계절이 뚜렷한 국내 사정은 더 심각하다. 공사가 포함된 프로젝트는 계절도 고려해야 한다. 그래서 견적을 뽑을 때 프로젝트 기간을 길게 잡고 싸게 저렴하게 하면 더 선택을 잘 할 거라 생각하는데 그렇지 않다. 대기업과 계약도 그렇다. 그들과의 계약은 모두 비공개이기에 제대로 공개되지 않는다. 한 가지 분명한 점은 결과물을 빨리 보여주고 초반에 빨리 달릴 수 있는 팀을 더 선호한다. 그리고 대기업 구조상 지인을 이용하는 것이 아니라면 그럴  수밖에 없다. 여담이지만 대기업과의 거래에서는 진행에 따라 많게는 70%까지 단가를 후려치는데  대기업 프로젝트를 했던 작은 IT 기업들이 그것을 포트폴리오로 표현할 때는 돈을 많이  벌었다고 생각하면  안 된다. 이름을 남기기 위해 남는 게 거의 없지만 프로젝트를 성공적으로 마쳤다. 정도로 이해하면 된다. 애플스토어의 액세서리들도 애플이 70% 먹는다. 

초기 코드들을 구하더라도 기존 유지될 시스템과 마이그레이션이 가능한지 안 한지 잘 따져봐야 한다.
msdn.microsoft.com
지금도 MSDN Subscription에서 찾을 수도 없는 Visual Studio  6로 시판되는 프로그램을 생산해 내고 있다. 그러나 Windows 10에서 문제가 점점 나오기에 64비트 빌드 옵션으로 처리를 하긴 했다만 언젠가는 마이그레이션 해야 한다. Visual Studio 마이그레이션 하면서 느끼는 점은... 버전 간의 호환성이 없다고 보면 된다는 것이다. 어느 정도 규모가 되고 라이브러리와 연계된 프로젝트는 자동으로 마이그레이션 된 적이 단 한 번도 없다. 개인적으로 말하자면 2008이 명작이고, 2008은 아마 향 후 5년은 더 지원할 것이라 본다. 다만 새로 진행하는 프로젝트는 2015로 갈  수밖에 없다. 최소 10년은 바라봐야 하기 때문이다. 일 년 일 년이 판이하게 다른 스타트업에서의 플레이와는 별개의 세계다.
www.visualstudio.com
Visual Studio 가 무료가 될지 누가 알았겠나?

PostgreSQL: File Browser        
www.postgresql.org
좋은 DB도 무료로 쓸 수 있게 될지...

7-Zip    
www.7-zip.org
데이터 압축도 오픈소스를 선택하고

github.com
오래된 녀석도 여러 라이브러리를 이용해서 손볼 수 있다.

dev.windows.com

시스템 구축에 MAC을 쓰면 참... 깔끔하고 좋겠지만. 아시다시피 리눅스가 가장 오픈적 형태이고  그다음은 윈도즈 기반이다. 오픈이 되면  될수록 고객의 입맛에 맞게 커스터마이징을 할 수 있다. 아쉽게도 BSD나 System V 계열처럼 저널링 파일 시스템을 쓰는 친구들은 계량기 및 전기 공사를 다시 하고 UPS도 달아줘야 해서 최소 2천만 원의 단가가 올라간다. 안정적인 서버에 UPS는 필수겠지만 견적서에 융통성을 두지 않으면 경쟁력이 없다. 게다가 전기세까지 고려하는 시스템은 필요 없는 시간에 전원을 끌 수 있게 설계가 되어야 한다. UPS가 들어가면 벽면과의 공간은 2.5Cm만 뛰우면 된다. 생각보다 작게 띄워도 된다. 벽면과의 거리면 지켜주면 되고 바닥에 놓아도 관계없다. 타워 렉의 가장 하단에 놓는 것도 좋다. 정말 중요한 온도는 0~40를 넘지 말아야 한다. 강한 햇빛, 겨울철 전열기 복사열, 습한 곳에서의 설치는 문제가 된다.


Fin.


업계에서 공개적으로 인지도가 있거나, 여러 프로젝트들과 괜찮은 퍼포먼스로 브로커와 손쉽게 연락이 닿는 사람들에게는 별 어쭙잖은 생각들일지도 모르나. 분명, 도움이 될 사람이 있다는 가정 아래 글을 썼다.

댓글 없음:

댓글 쓰기

국정원의 댓글 공작을 지탄합니다.

UPBIT is a South Korean company, and people died of suicide cause of coin investment.

 UPBIT is a South Korean company, and people died of suicide cause of coin. The company helps the people who control the market price manipu...