IT아키텍트가 하지 말아야 할 128가지

이제 내가 가야할길은 아키텍트인가...

요즘엔 나에 마지막 IT밥은 뭘 먹고 있을지 궁금해진다.

"IT아키텍트가 하지 말아야 할 128가지"

는 설계, 방법론, 구축/테스트, 운용,보안 과 관련하여 일본 여러IT회사에서 실무자들의 기고를 근거로 펴낸 책이다

내용은 국내와 조금 다른 상황이 있기는 하지만 프로젝트에 참고하기에 충분하다

1장. 설계 

No.001 EC 사이트에서는 Sorry 화면 방식을 채택해서는 안 된다 

  -생각: EC사이트는 이용자와 사이트간 거래가 목적인 사이트, sorry화면은 과부하 안내하는 화면을 의미. 

          즉, 거래중에 sorry화면이 나오면 안되므로 과부하걸리기전에 일정사용자 이상은 대기 혹은 차단을 미리 하자는 내용.

No.002 어플리케이션 개발자가 설계서대로 개발해 줄 것이라고 생각해서는 안 된다 

  -생각: 설계는 설계로 끝나는것이 아닌 설계된 내용을지키는것

          개발팀을 리드하여 지속적으로 설계된 내용의 준수를 점검한다. 그리고 성능테스트를 빨리 할것

No.003 사용자가 성능 요건을 정해줄 것이라고 생각해서는 안 된다 

  -생각: 이건 이미 알고 있다. 

No.004 동일 서버 내의 웹 서비스를 호출해서는 안 된다

  -생각: 알지만 국내에서는 이런식으로 설계하기 어렵다. 보스가 싫어한다..  

No.005 24시간 가동 시스템이라고 모든 것을 24시간 동작시키려고 해서는 안 된다

  -생각: 상당히 어려운 일이다... 

          우리 회사 시스템도 최근에 도입했지만 유지보수와 하다못해 중앙회 연동이 걸려 24시간 영업이 안되고 있다. 

No.006 클라이언트/서버형 시스템을 가볍게 보아서는 안 된다 

  -생각: 누가 가볍게 생각할까...

          내부사용자를 위한 시스템은 클라이언트가 모두 같은 환경인데도.. 고려할게 많다..

No.007 데이터 구조의 품질/성능이 나빠지는 것을 고려해야 한다

  -생각: 최근에 고민되는 부분이다.

          초기 오픈된 시스템은 어찌되었건 관리가 되는데.. 

          운영이 어느정도 잘 되는 시스템은 담당자도 바뀌고 하기 때문에 나중에 열어보면 데이터구조와 품질이 문제 생긴다.

          따라서 여유가 되면 데이터거버넌스개념을 도입하는등으로 품질유지를 위한 방안을 고려해야 할것이다  

No.008 백업 설계를 먼저 해서는 안 된다 

  -생각: 복원설계를 먼저한다.

No.009 레코드 길이×건수로 데이터 용량을 결정해서는 안 된다 

  -생각: RDBMS에 따라 물리사이즈가 결정된다.

No.010 참조 정합성 제약 기능을 여러 번 사용해서는 안 된다 

 -생각: 참조정합성은 데이터 이행할때 짜증난다. 

         그래서 아예 어플리케이션에서만 체크하는 경우도 있는데.. 좋은 방법이 아니라는것은 알고 있다.

No.011 테스트 데이터로 성능 평가를 해서는 안 된다

  -생각: 우리회사는 개인정보보호강화로 운영데이터를 개발/테스트장비로 가져다 쓰는데 제약이 있다.

          운영데이터를 옮겨와 개인정보만 가공해 사용하고 있다 

No.012 파티션 분할을 가볍게 해서는 안 된다 
  -생각: DB 파티션 분할 얘기로... DBA가 아니라서 와닿는 내용이 아니다.

          다만 아키텍트로써. DB 파티션 분할을 처음부터 설계하는건 설계가 잘못하는것 같다..

No.013 오랜 시간 종료하지 않은 트랜잭션을 사용해서는 안 된다 

  -생각: 우리나라에서는 프로젝트시 프레임웍을 기본으로 사용하기때문에 트랜잭션 고민이 많이 없다.

          다만 각 솔루션마다 타임아웃 시간에 대한 설계가 필요하다.

No.014 기술 영역만 고려해서는 안 된다 

  -생각: 아키텍트라면 당연히 기술영역만 고려하는 사람은 없다. 

          보안,운용등 사실상 총괄이다.

No.015 기기의 스펙(명세서)을 bps만으로 판단해서는 안 된다 

No.016 가상 네트워크를 물리 네트워크와 똑같이 생각해서는 안 된다 

  -생각: 이 부분은 읽다가 다른 생각이 많이 났다.. 내가 부족한 부분이 네트웍이라는 것과.. 

         가상OS에 악몽이다.. 최근 가상OS영업이 부쩍 늘었는데.. 주의할것은 가상OS에도 결국 하드웨어에 병목부분이 있다. 문제는 거기서 생긴다.

No.017 QoS라는 말로 숨겨서는 안 된다 

No.018 QoS를 과신해서는 안 된다 

No.019 구축 멤버의 시선만으로 로그 출력을 설계해서는 안 된다 

No.020 GC를 정하지 않고 자바 어플리케이션을 설계해서는 안 된다

  -생각: WAS와 프레임웍이 좋아져서 근래 GC로 고생한적이 없다. 다만 개발실수로 인한 memory leak으로 RollBack을 했다.

          GC설계와 겹치면서 문제 원인파악이 힘들어졌었다. 

No.021 실물 모형과 프로토 타입을 혼동해서는 안 된다 

No.022 어플리케이션을 함부로 리치화해서는 안 된다 

No.023 화면 디자인이나 화면 이동의 변경에 "이것이 최선"이라고 생각해서는 안 된다 

No.024 사용자 경험을 무조건 포함시키려 해서는 안 된다 

No.025 사용자에게 사용하기 어려운 점을 물어서는 안 된다 

  -생각: 사용자는 진짜 바보는 아니지만 바보인것으로 생각해서 어려운점도 묻지 말자. 

No.026 신 클라이언트용 어플리케이션이라고 해도 안심해서는 안 된다 

No.027 산출해 보지 않고 TCO를 줄일 수 있다고 생각해서는 안 된다 

No.028 신 클라이언트의 도입으로 가용성이 좋아졌다고 트러블이 없다고 생각해서는 안 된다 

No.029 가상 PC형으로 이행을 하더라도 검증을 게을리해서는 안 된다 

Column1 IT 아키텍트로서 가장 재미있게 느끼는 부분 

2장. 방법론 

No.030 유스 케이스를 상세하게 작성해서는 안 된다 

 -생각: 국내는 유스케이스를 작성하지 않는것 같다..(아니면 내가 경험이 미천하거나...)

         하지만 핵심은 알겠다. 상세하게 작성하지 말라는 말이 아니라. 상세하게 작성하되 조건을 명확히 구분하라는 것이다.

No.031 납품 문서만 남겨 두면 된다고 생각해서는 안 된다 

  -생각: 그렇다. 문서도 형상관리를 통한 버전관리가 되어야 한다... 어떻게?

No.032 패키지를 도입할 때 부가 기능 개발을 선행해서는 안 된다 

  - 생각: 패키지 도입해보고 싶다.. 

No.033 패키지를 도입하면 납기를 단축할 수 있다고 생각해서는 안 된다 

  - 생각: 패키지라해도 패키지 그대로 도입한 적이 없다.

No.034 협력사나 고객사와 실데이터 파일을 주고 받아서는 안 된다 

  - 생각: ㅋㅋ 그래.. 원가계산을 한 엑셀 견적서도 받아봤다. 영업비밀을 알아버린 나..

No.035 WBS 하나의 작업 항목에 여러 담당자를 선정해서는 안 된다

  - 생각: 하지만 큰 회사일수록... 한명이 결정을 못한다..   

No.036 특정 프로세스나 패턴에 집착해서는 안 된다 

No.037 "UP=반복 개발"이라고 생각해서는 안 된다 

No.038 ERP와 현행 기능을 비교해서는 안 된다 

No.039 다짜고짜 프로토타입부터 시작해서는 안 된다 

No.040 고객이 말하는 패키지의 갭 판단을 그대로 받아들여서는 안 된다 

No.041 보고서 검토를 뒤로 미뤄서는 안 된다 

No.042 "고객이 주체가 되어 해야 할 작업"이라고 해서 고객에게 그대로 주어서는 안 된다 

No.043 요건 정의를 하기 위한 계획을 게을리 해서는 안 된다 

No.044 비즈니스 요건과 시스템 요건을 혼동해서는 안 된다 

No.045 비즈니스 요건을 문장만으로 표현해서는 안 된다 

No.046 현행 업무, 현행 시스템의 조사를 회피해서는 안 된다 

No.047 성과물의 선정과 표준화를 뒤로 미뤄서는 안 된다 

No.048 모든 요건을 사용자가 알고 있다고 생각해서는 안 된다 

No.049 후속 공정에 들어가고 나서 테스트를 시작해서는 안 된다 

No.050 사용자의 오해를 초래하기 쉬운 요건 정의서를 만들어서는 안 된다 

No.051 유스 케이스를 기능 요건이라고 착각해서는 안 된다 

No.052 사각지대에 있는 요건을 놓쳐서는 안 된다 

No.053 비용과 기간의 밸런스를 무시해서는 안 된다 

No.054 요건 정의가 충분하다고 요건 변경이 발생하지 않는다고 생각해서는 안 된다 

No.055 프로젝트 특성을 생각하지 않고 모두 동일하게 진행해서는 안 된다 

Column2 "풍림화산"과 IT 아키텍트 

3장. 구축 및 테스트 

No.056 64비트 OS가 32비트 OS보다 우수하다고 생각해서는 안 된다 

No.057 기호 링크를 조심성 없이 이용해서는 안 된다 

No.058 여러 가지의 OS를 이용할 때는 개행 코드를 무시해서는 안 된다 

No.059 정의된 것 이외의 것을 가볍게 보아서는 안 된다 

No.060 공개 기능 클래스의 인스턴스를 직접 생성해서는 안 된다 

No.061 거대한 정수 클래스를 만들어서는 안 된다 

No.062 분량이 많은 코딩 규칙을 만들어서는 안 된다 

No.063 오픈소스는 무료라고 생각해서는 안 된다 

 -생각: 오픈소스 사용이 싼건 아니다. 게다가 회사에서.. 오픈소스를 운영할 직원을 채용해주지도 않는다. 

No.064 직접 빌드한 바이너리를 실제 환경에서 이용해서는 안 된다 

No.065 독자적으로 구축해서는 안 된다 

No.066 소스 코드에 HTML 생성 코드를 포함해서는 안 된다 

No.067 글로벌 변수나 순환 참조를 사용해서는 안 된다 

No.068 스레드 세이프로 하는 것을 잊어서는 안 된다 

No.069 소스코드를 유용해서는 안 된다 

No.070 메모리 관리를 처리계에 맡겨서는 안 된다 

No.071 매직 넘버를 이용해서는 안 된다 

No.072 실 환경에서 갑자기 테스트를 해서는 안 된다 

No.073 모든 결합 테스트를 자동화해서는 안 된다 

No.074 테스트를 개발자에게만 맡겨서는 안 된다 

No.075 자동식별 모드와 전이중 모드를 혼재시켜서는 안 된다 

No.076 랜(LAN) 스위치로 루프 구조를 만들어서는 안 된다 

No.077 뷰, 트리거를 많이 사용해서는 안 된다 

No.078 현상만 보고 튜닝을 서둘러서는 안 된다 

Column3 왜 IT 아키텍트가 중요한가? 

4장. 운용 

No.079 가상화 환경의 게스트 OS에서 취득한 CPU 사용률을 믿어서는 안 된다 

No.080 SLA를 뒤로 연기해서는 안 된다 

  -생각: SLA계약 뒤에 평가가 형식적일때가 많다... 

No.081 운용 비용 절감만을 목표로 해서는 안 된다 

No.082 운용 절차 없이 운용해서는 안 된다 

No.083 운용을 아웃소싱하고 나서 안심해서는 안 된다 

No.084 개발과 운용 커뮤니케이션을 소홀히 해서는 안 된다 

No.085 1rack(랙) 60A(암페어) 이상 사용해서는 안 된다 

 -생각: 간과하고 있었다... 

         공간이 없으니까. 촘촘히 서버를 넣다보면 ..60A이상 사용할수밖에 없었다..

         데이터센터에서 지적받아도 무시하곤했는데.. 그러게 열화얘길 하던가..

         그냥 한 랙에 전기 많이 쓴다고 하지 말라고만 하니.. 그냥 넘겨들었지... 

No.086 이중 구성을 믿어서는 안 된다 

  -생각: 시스템운영을 해본사람만 알 내용이다.

          이중구성이 몇가지 있는데. 

          특히 액티스-스탠바이 시스템은 구성이 단순해서 애용되지만 장애시 종종 복구를 어렵게 만들거나 또다른 장애를 만든다.. 

          이중화구성된 서버가 복구되다가 서로 미쳐돌아가면 여러번 보았다. 그걸 우리회사에서는 핑퐁치다 죽었다고 보고한다. ㅋㅋ.

No.087 자동 백업 툴에 의지해서는 안 된다 

  -생각: 백업담당이라면 백업된 데이터를 확인하는것이 일이다.

          장애나서.. 최후에 보루인 백업데이터 확인하다 미치는줄 알았다 

No.088 환경 설정을 복사 & 붙여넣기해서는 안 된다 

No.089 커널 튜닝을 해서는 안 된다 

 -생각: 커널까지는 아니지만 종종 솔루션 패치를 쉽게 얘기하는 엔지니어들이 있다..

         패치전 원인파악부터 주변 영향까지 철저하게 분석이 된 다음에... 롤백준비하고 진행할것이 튜닝이고 패치다.

No.090 출시 직전의 완성형 제품에 갑자기 패치를 해서는 안 된다 

No.091 스냅샷으로 백업을 대신해서는 안 된다 

No.092 RAID라고 안심해서는 안 된다 

 -생각: RAID로 복구안된적이 많아서 공감이 된다.

No.093 서버 사이에 틈을 남겨두어서는 안 된다

 -생각: 블랭크 패널이 이런 용도였구나.. 랙이 예쁘라고. 혹은 케이블 정리용으로 알았는데... 

No.094 서버 뒷면에 케이블을 늘어뜨려서는 안 된다

 -생각: 케이블이 이정도 많은 경우는 없어서... 그래서 기억해둬야겠다. 

No.095 랙과 서버 사이에 공간을 두어서는 안 된다 

No.096 냉통로와 온통로만으로 만족해서는 안 된다 

 -생각: 헉. 랙 놓을때 생각못했는데...

No.097 서버 수만큼만 UPS를 준비해서는 안 된다 

 -생각: IDC를 사용하고 작은 통신실은 대형UPS를 사용하는것이 일반적이다.

No.098 전체를 생각하지 않고 이중 전원으로 해서는 안 된다 

 -생각: 아놔. 그렇다.. 서버는 이중화해놓고. 정작 네트웍단말기는 스팩상 이중화 안되어 있는 경우가 있다. 

         결국 서버만 안죽지, 업무는 마비되는 꼴이다.

No.099 랙이 사용하고 있는 전류 값을 간과해서는 안 된다 

No.100 UPS를 설치하는 것만으로 안심해서는 안 된다 

No.101 파손된 HDD를 계속 사용해서는 안 된다 

  -생각: 일반PC용  HDD도 마찬가지다.

No.102 젖은 디스크를 말려서는 안 된다 

No.103 젖은 USB 메모리에 전기가 흐르게 해서는 안 된다 

No.104 테이프를 적셔서는 안 된다 

No.105 테이프의 압축률을 그대로 받아들여서는 안 된다 

  -생각: 그래.. LTO4로 그렇게 압축이 안되더라...

No.106 공유 폴더를 새로운 서버에 이행해서는 안 된다 

No.107 리눅스의 free값(빈 메모리)은 메모리의 빈 영역이 아니다 

  -생각: 앗 ... 나 그동안 잘못 보고했다.. ㅜㅜ 이런......

Column4 IT 아키텍트에게 요구되는 세가지 힘 

5장. 보안 

No.108 IPS를 도입해도 안심해서는 안 된다 

No.109 접근의 증거가 될 만한 흔적을 과잉으로 추출해서는 안 된다 

No.110 패스워드 정책을 너무 엄격하게 해서는 안 된다 

 -생각: 보안이 중요해진 요즘.. 각 솔루션마다 암호정책이 달라서 짜증나 죽겠다..

         암호는 길게 하는것이 규칙을 엄격하게 하는것보다 효율적이다..

No.111 바이러스 체크는 과잉도 과소도 안 된다 

No.112 패스워드를 프로그램에 하드 코딩해서는 안 된다 

No.113 방화벽으로 너무 많은 규칙을 설정해서는 안 된다 

No.114 운용이나 성능을 고려하지 않고 암호화해서는 안 된다 

No.115 모든 통신을 암호화해서는 안 된다 

No.116 운용 관리에 텔넷을 사용해서는 안 된다 

No.117 관리자 권한을 공유해서는 안 된다 

No.118 DBMS의 감사 기능에 의지해서는 안 된다 

No.119 DBMS 기능으로 데이터를 암호화해서는 안 된다 

No.120 신 클라이언트의 보안 대책을 게을리 해서는 안 된다 

No.121 로그온/로그아웃의 이력을 로그에서 빼서는 안 된다 

No.122 로그를 수작업으로 수집해서는 안 된다 

No.123 일시적이더라도 UAC를 무효로 해서는 안 된다 

No.124 사용자 계정을 바로 삭제해서는 안 된다 

No.125 루트 계정을 사용해서는 안 된다 

No.126 임시 파일을 안이하게 작성해서는 안 된다 

No.127 사용자 이름을 숫자만으로 구성해서는 안 된다 

No.128 다운로드 받은 파일이 올바르다고 믿어서는 안 된다

-------------------------------------------------------------

아는내용도 있었지만 .. 

앗차 싶었던 서버 얘기도 있어. 오랫만에 재밌게 읽은 책이였습니다.

이상입니다.