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

1 개요[ | ]

IT 아키텍트가 하지 말아야 할 128가지
설계, 방법론, 구축·테스트, 운용, 보안

 

2 책 소개[ | ]

누구도 알려주지 않았던 시스템 개발 현장의 128가지 해결책이 담긴 책. 시스템을 튼튼하게 만들 수 있는 건강한 개발자 그리고 유능한 아키텍트로 성장할 수 있는 경험적 노하우를 담았다. 누구나 현장에서 부딪힐 수 있는 실제 사례를 통해 하지 말아야 할 '나쁜 아키텍처'를 제시하며 이유를 설명하고 적절한 처방전을 내놓는다. 128가지의 다양한 처방전을 적재적소에 활용할 수 있다. 설계, 방법론, 구축 및 테스트, 운용, 보안 분야로 나누어 찾아보기 쉽게 정리했다.

3 목차[ | ]

3.1 설계[ | ]

  • No.001 EC 사이트에서는 Sorry 화면 방식을 채택해서는 안 된다
  • No.002 어플리케이션 개발자가 설계서대로 개발해 줄 것이라고 생각해서는 안 된다
  • No.003 사용자가 성능 요건을 정해줄 것이라고 생각해서는 안 된다
  • No.004 동일 서버 내의 웹 서비스를 호출해서는 안 된다
  • No.005 24시간 가동 시스템이라고 모든 것을 24시간 동작시키려고 해서는 안 된다
  • No.006 클라이언트/서버형 시스템을 가볍게 보아서는 안 된다
  • No.007 데이터 구조의 품질/성능이 나빠지는 것을 고려해야 한다
  • No.008 백업 설계를 먼저 해서는 안 된다
  • No.009 레코드 길이×건수로 데이터 용량을 결정해서는 안 된다
  • No.010 참조 정합성 제약 기능을 여러 번 사용해서는 안 된다
  • No.011 테스트 데이터로 성능 평가를 해서는 안 된다
  • No.012 파티션 분할을 가볍게 해서는 안 된다
  • No.013 오랜 시간 종료하지 않은 트랜잭션을 사용해서는 안 된다
  • No.014 기술 영역만 고려해서는 안 된다
  • No.015 기기의 스펙(명세서)을 bps만으로 판단해서는 안 된다
  • No.016 가상 네트워크를 물리 네트워크와 똑같이 생각해서는 안 된다
  • No.017 QoS라는 말로 숨겨서는 안 된다
  • No.018 QoS를 과신해서는 안 된다
  • No.019 구축 멤버의 시선만으로 로그 출력을 설계해서는 안 된다
  • No.020 GC를 정하지 않고 자바 어플리케이션을 설계해서는 안 된다
  • No.021 실물 모형과 프로토 타입을 혼동해서는 안 된다
  • No.022 어플리케이션을 함부로 리치화해서는 안 된다
  • No.023 화면 디자인이나 화면 이동의 변경에 "이것이 최선"이라고 생각해서는 안 된다
  • No.024 사용자 경험을 무조건 포함시키려 해서는 안 된다
  • No.025 사용자에게 사용하기 어려운 점을 물어서는 안 된다
  • No.026 신 클라이언트용 어플리케이션이라고 해도 안심해서는 안 된다
  • No.027 산출해 보지 않고 TCO를 줄일 수 있다고 생각해서는 안 된다
  • No.028 신 클라이언트의 도입으로 가용성이 좋아졌다고 트러블이 없다고 생각해서는 안 된다
  • No.029 가상 PC형으로 이행을 하더라도 검증을 게을리해서는 안 된다
  • Column1 IT 아키텍트로서 가장 재미있게 느끼는 부분

3.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.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 아키텍트가 중요한가?

3.4 운용[ | ]

  • No.079 가상화 환경의 게스트 OS에서 취득한 CPU 사용률을 믿어서는 안 된다
  • No.080 SLA를 뒤로 연기해서는 안 된다
  • No.081 운용 비용 절감만을 목표로 해서는 안 된다
  • No.082 운용 절차 없이 운용해서는 안 된다
  • No.083 운용을 아웃소싱하고 나서 안심해서는 안 된다
  • No.084 개발과 운용 커뮤니케이션을 소홀히 해서는 안 된다
  • No.085 1rack(랙) 60A(암페어) 이상 사용해서는 안 된다
  • No.086 이중 구성을 믿어서는 안 된다
  • No.087 자동 백업 툴에 의지해서는 안 된다
  • No.088 환경 설정을 복사 & 붙여넣기해서는 안 된다
  • No.089 커널 튜닝을 해서는 안 된다
  • No.090 출시 직전의 완성형 제품에 갑자기 패치를 해서는 안 된다
  • No.091 스냅샷으로 백업을 대신해서는 안 된다
  • No.092 RAID라고 안심해서는 안 된다
  • No.093 서버 사이에 틈을 남겨두어서는 안 된다
  • No.094 서버 뒷면에 케이블을 늘어뜨려서는 안 된다
  • No.095 랙과 서버 사이에 공간을 두어서는 안 된다
  • No.096 냉통로와 온통로만으로 만족해서는 안 된다
  • No.097 서버 수만큼만 UPS를 준비해서는 안 된다
  • No.098 전체를 생각하지 않고 이중 전원으로 해서는 안 된다
  • No.099 랙이 사용하고 있는 전류 값을 간과해서는 안 된다
  • No.100 UPS를 설치하는 것만으로 안심해서는 안 된다
  • No.101 파손된 HDD를 계속 사용해서는 안 된다
  • No.102 젖은 디스크를 말려서는 안 된다
  • No.103 젖은 USB 메모리에 전기가 흐르게 해서는 안 된다
  • No.104 테이프를 적셔서는 안 된다
  • No.105 테이프의 압축률을 그대로 받아들여서는 안 된다
  • No.106 공유 폴더를 새로운 서버에 이행해서는 안 된다
  • No.107 리눅스의 free값(빈 메모리)은 메모리의 빈 영역이 아니다
  • Column4 IT 아키텍트에게 요구되는 세가지 힘

3.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 다운로드 받은 파일이 올바르다고 믿어서는 안 된다

4 같이 보기[ | ]

5 참고[ | ]

문서 댓글 ({{ doc_comments.length }})
{{ comment.name }} {{ comment.created | snstime }}