삶은달걀노른자

보호되어 있는 글입니다.

서평단 자격으로 도서를 지급받아 작성하였습니다. 이 책의 대상을 좁혀서 보면 일반 기업체의 IT팀 근무자들이고, 넓게 보면 모든 IT 인들이 대상이라고 할 수 있다. 하지만 개발자들을 위한 개발이나 아키텍처 서적도 아니고, 인프라 운영자들을 위한 인프라 설계/운영 노하우를 담은 서적도 아니다. 그렇다고 프로젝트 관리를 위한 PM 책은 더더욱 아니다. IT 시스템의 정석 - 예스24IT 시스템 개발 및 운영을 전체상으로 제시 IT 시스템 관리 부서의 프로젝트 관리 매니저를 핵심 대상으로 하여, IT팀의 전반적인 프로세스 과정을 하나하나 설명합니다. 시스템의 기획부터 개발,www.yes24.com 이런 책이 꼭 한 권 정도는 필요하다 싶었는데, 그동안 IT팀의 업무를 전체론적인 관점에서 망라한 책은 본 적이..

■ 34장 빠져 있는 장 The Missing Chapter ** 이번 장은 저자가 아닌 다른 사람이 적은 글이다. (By Simon Brown) ​ 악마는 항상 디테일(세부사항)에 있는 법이다. 클린 아키텍처가 물론 도움이 되겠지만 마지막 고비에 걸려 넘어지지 않도록 설계나 코드 조직화와 관련된 몇 가지 추가적인 접근법을 살펴본다. 이 장의 내용은 책의 저자(Robert C. Martin)와 일부 다른 견해도 포함된다. ​ 요약하면, 가능한 한 선택사항을 열어두되 실용주의적으로 행하고, 팀의 규모, 기술 수준, 해결책의 복잡성을 일정과 예산이라는 제약과 동시에 고려하라는 것. 또 선택된 아키텍처 스타일을 강제하는 데 컴파일러의 도움을 받을 수 있을지 고민하며, 데이터 모델과 같은 다른 영역에 결합되지 ..

■ 33장 사례 연구: 비디오 판매 Case Study: Video Sales ​ 웹사이트에서 비디오를 판매하는 소프트웨어 사례를 적용해 보자. 아래는 유스케이스를 분석한 것이다. 액터는 4개인데, 단일 책임 원칙에 따라 신규 기능의 추가나 기존 기능의 변경은 반드시 이 4개의 액터에게 기능을 제공하기 위해서여야 한다. 아래는 초기 컴포넌트 아키텍처의 모습이다. 각 경계를 구분으로 뷰, 프레젠터, 인터렉터, 컨트롤러가 나눠져 있는 전형적인 모습니다. 각 컴포넌트는 jar나 dll에 해당하지만, 뷰와 프레젠터를 합쳐서 같은 jar에 두고 나머지는 각각의 jar로 만들거나 나머지를 하나의 jar로 합치는 방법도 가능하다. ​ 이처럼 선택지를 열어두면(컴포넌트를 독립적으로 컴파일/빌드 할 수 있는 환경으로 구..

ITIL 4 Foundation 기초와 시험 강의를 하는 사이트들을 정리해 봤다. 각 홈페이지에 공개된 내용과 일부 오픈된 강의를 들어보고 주관적으로 적은 것이다. ■ Udemy / 온라인 이러닝 기본 교육과 자격증 대비 강의가 분리되어 있다. 외국인이 강의하며 한글 자막이 제공된다. 용어가 자연스럽게 번역이 잘 되었는지는 솔직히 잘 모르겠다. ITIL 4를 통한 서비스 관리 기초 강의 https://www.udemy.com/course/best-itil-4-service-management/ 강의 총 시간이 1시간 46분으로 짧기 때문에 기본적인 내용에 충실한 것 같다. 꼭 자격증이 아니라 그냥 ITIL과 ITSM을 공부하기 위해 처음 시작하는 강의로 적합해 보인다. 강의 종료 후에도 계속해서 다시 볼..

■ 32장 프레임워크는 세부사항이다 Frameworks Are Details ​ 프레임워크 역시 세부사항이다. 우리가 잘 아는 Spring 같은 프레임워크가 그렇다. 따라서 프레임워크는 아키텍처가 아니며 업무규칙으로부터 떨어져야 한다. 아키텍처 바깥쪽 원에 속하는 세부사항으로 취급하고 안으로 못 들어오게 해야 한다. ​ 물론 이것은 현실적이지 않을 수 있다. 사실상 규모가 있는 대부분의 프로젝트에서는 당연히 어떤 형태로든지 프레임워크를 쓰고 있으며 아마 저자가 당부하는 아키텍처 원칙을 적용하지 않을 것이기 때문이다. ​ 저자는 이에 대한 해결책으로, 가령 업무 객체를 만들 때 프레임워크가 자신의 기반 클래스로부터 파생하기를 요구하면, Proxy를 만들고 업무규칙에 플러그인할 수 있는 컴포넌트를 Proxy..

ITIL 4에 나오는 중요한 개념들을 개별적으로 알기 보다는 그것들 간의 관계를 이해할 필요가 있다. ■ 서비스 관리의 4개 차원 (4 Dimension) 서비스 관리를 구성하는 4개의 차원은 아래와 같다. • Organization & people 조직과 사람 • Information & technology 정보와 기술 • Suppliers & partners 공급자와 파트너 • Value streams & processes 가치 흐름과 프로세스 이 네 가지 차원을 모두 고려하지 않으면 당연히 서비스의 품질과 효율성이 떨어질 수 있다. 한 가지라도 소홀히 할 수 없는 것이다. 가령, 조직이 기술에만 너무 집중한 나머지 이 기술을 사용하는 사람들을 등한시한다면 바람직한 가치를 만들어 낼 수 없다. 서비스..

■ 31장 웹은 세부사항이다 The Web Is a Detail ​ 웹은 GUI 이므로 아키텍처에서 업무로직과 분리되어야 하는 세부사항이다. ​ 물론 웹은 너무 특이해서 장치 독립적인 아키텍처를 추구하는 것이 어렵다는 것을 저자도 어느정도 인정은 한다. 다만 UI와 어플리케이션 사이에 존재하는 또다른 추상화 경계인 유스케이스가 어느정도 완충작용을 할 수 있으리라 본다. ​ ​

◆ Part 6 세부사항 Details ​ ■ 30장 데이터베이스는 세부사항이다 The Database Is a Detail ​ 이 책에서 일관되게 표현하고 주장하는 것 중 하나는 바로 정책과 세부사항이라는 개념이다. 정책은 시스템의 업무 로직을 말하고, 세부사항은 이를 지원하는 도구 정도로 인식하면 된다. ​ 이러한 관점에서 데이터베이스는 세부사항에 속한다. 데이터 구조과 모델은 아키텍처에서 중요한 요소가 맞지만 데이터베이스는 아니다. (여기서 말하는 데이터베이스는 주로 RDBMS를 지칭하는 듯 보인다) ​ 데이터베이스가 발전하게 된 이유는 데이터를 디스크에 저장하면서 속도 저하를 만회하기 위한 색인, 캐시, 쿼리 플랜 최적화가 필요했기 때문이다. 하지만 이렇게 가져온 데이터는 결국 RAM으로 올라오게..

■ 28장 테스트 경계 The Test Boundary ​ 테스트는 아키텍처 원에서 가장 바깥쪽을 생각할 수 있다. 내부의 어떤 것도 테스트에 의존하지 않으며 반대로 테스트는 내부 컴포넌트를 향해 항상 원의 안쪽으로 의존한다. 잘 깨지지 않는 테스트를 만들기 위해서는 당연히 테스트를 고려해서 설계해야 한다. 즉, 변동성이 있는 것에 의존하지 말아야 한다. 가령 업무규칙은 GUI를 사용하지 않고 테스트할 수 있어야 한다. ​ 당연한 말이지만 업무규칙들 검증하기 위한 테스트용 API를 만들어서 테스트를(테스트 구조를) 어플리케이션으로부터(어플리케이션 구조로부터) 분리해야 한다. ​ ​