본문 바로가기

관심사/독후감

<마르티네즈> 카오스 멍키 - 혼돈의 시대, 어떻게 기회를 낚아챌 것인가 '카오스 몽키'라는 제목에 속아 읽기 시작한 책이다. 이 책을 읽기 전에는 '카오스 엔지니어링'과 관련된 내용을 기대했다. 실은 저자가 실리콘밸리에서 겪은 IT 업계의 비하인드를 담은 회고록이었다. 저자는 솔직하고 대담한 필력으로 스타트업 창업과 인수합병, 그리고 실리콘밸리의 IT 대기업에 대한 이야기를 다룬다. 글을 읽다보면 저자인 마르티네즈는 똑똑하지만 거칠고, 잔꾀가 많은 사람으로 보인다. 책 내용과 관계없는 '카오스 몽키'를 제목으로 삼은 것은 실리콘밸리 사람들의 이목을 끌기 위한 전략이지 않았을까 의심스럽다. '카오스 엔지니어링'이란, 시스템이 예상치 못한 상황을 견딜 수 있도록 실험하는 것을 말한다. 운영 시스템에 무차별적인 부하를 일으켜 분산 시스템의 장애 지점을 찾아내고, 회복하는 과정을 ..
<나루세 마사노부> 도메인 주도 설계 철저입문 밑줄 그으며 책 읽기 📝 애플리케이션 서비스는 유스케이스를 구현하는 객체이다. 도메인 객체는 도메인을 코드로 옮긴 것이다. 도메인을 코드로 나타냈다고 해도 그것만으로는 이용자가 당면한 문제나 필요가 해결되지 않는다. 이용자의 필요를 만족시키거나 문제를 해결하려면 도메인 객체의 힘을 하나로 엮어 올바른 방향으로 이끌어야 한다. ... 유효성 검증 로직에서 에러를 반환하게 하는 경우, 결과 객체를 반환한다. 결과 객체는 개발자에게 강제력을 미치지 못한다. 즉, 처리 실패 핸들링의 역할을 클라이언트에 전적으로 위임하게 되는데, 이는 자칫 의도치 않게 실패를 그냥 지나쳐버리는 결과를 낳는다. 반대로 예외를 발새하는 쪽을 택하면 반환 값을 반환하지 않는다. 예외를 발생시키고 아무것도 하지 않으면 프로그램이 종료되..
<이동욱> 스프링 부트와 AWS로 혼자 구현하는 웹 서비스 나는 새로운 프레임워크를 학습할 때에는 일단 튜토리얼을 따라서 간단한 게시판을 만들어본다. 그리고 서버에 애플리케이션을 올려보는 것까지 실습해본다. 처음에는 새로운 언어를 배우는 것이 무작정 어렵게만 느껴진다. 그러나 실습을 하다 보면 패턴이 익숙해지고, 초기에 느꼈던 마음의 장벽들이 낮아진다. 그리고 의미를 모르는 채 코드를 따라치는 것에 갑갑함을 느끼게 되어, 동작 원리에 흥미를 갖게 된다. 올해 중순부터 자바/스프링을 공부하기로 결심했다. 그래서 학습의 방향성을 잡고 언어에 대한 흥미를 줄 수 있는 첫 삽이 필요했다. 그래서 얇은 스프링 부트 책 몇 권을 따라쳐보았다. 그 중, "스프링 부트와 AWS로 혼자 구현하는 웹 서비스"가 가장 이해하기 쉽고, 실습하기 좋았다. 폰트 크기와 컬러 여부, 그리..
<이미예> 달러구트 꿈 백화점 달러구트 꿈 백화점은 꿈을 판매하는 상점을 다룬 소설이다. 꿈 판매자와 제작자, 현실의 손님들의 이야기를 다루고 있어, 판타지와 현실 세계를 번갈아가며 이야기를 풀어나간다. 소설 속 판타지 세계에서는 꿈 제작자들이 꿈을 만들고, 사람들은 자기가 꾸고 싶은 꿈을 구매한다. 소설을 읽으면서 나도 인셉션처럼 꿈을 설계하고 싶다는 생각이 들었다. 현실에서 경험할 수 없는 것들을 체험해보고자 우주에 가는 꿈을 상상해보기도 했다. 그러나 꿈속의 나는 여전히 평범했다. 소설을 읽는 내내 나도 이런 판타지 세계를 경험하고 싶다는 생각이 들었다. 소설에서는 심신 안정용 쿠키, 진정 시럽을 추가한 커피, 설렘 용액처럼 마법의 약이 등장한다. 그런데 다른 관점으로 보면 나는 이미 판타지적인 세계를 살고 있다. 나는 최근 들..
<마이클 C. 페더스 > 레거시 코드 활용 전략 레거시 코드 활용 전략은 테스트 코드 없이 레거시 코드를 다 감수하시겠습니까? 글을 읽은 후, 흥미를 갖게 된 책이었다. 이후, 비즈니스 로직이 복잡한 업무를 담당하게 되었고 나의 복잡한 심정을 대변해줄 대상을 찾는 심정으로 이 책을 읽게 되었다. 이 책은 현업에서 리팩토링을 하면서 암묵적으로 체득한 기법들이 명쾌하게 정리되어 있어 흥미로웠다. 리팩토링을 할 때, 적용 결과가 이전보다 낫다고 확신할 수 없는 경우가 종종 있었다. 이 때, 리팩토링을 하지 않으면 코드를 이해하기 어려웠기 때문에 별다른 선택지가 없어서 고민하고는 했다. 몇 번의 실패를 경험한 후, 스케치하듯이 연습 삼아 리팩토링을 하며 코드를 분석하는 패턴을 체득하게 되었다. 물론, 이 코드는 로컬에서만 사용했고, 리팩토링 효과가 확실하다고..
<조영호> 오브젝트 05. 책임 할당하기 1. 클래스가 여러 이유로 변경돼야 한다면 응집도가 낮은 것이다. 변경의 이유를 기준으로 클래스를 분리해야한다. 2. 응집도가 높은 클래스는 인스턴스를 생성할 때 모든 속성을 함께 초기화한다. 반면 응집도가 낮은 클래스는 객체의 속성 중 일부만 초기화하고, 일부는 초기화되지 않은 상태로 남겨진다. 때문에 함께 초기화되는 속성들을 기준으로 클래스를 분리해야한다. 3. 모든 메서드가 객체의 모든 속성을 사용한다면 클래스의 응집도가 높다고 볼 수 있다. 반면 메서드들이 사용하는 속성에 따라 그룹이 나뉜다면 클래서의 응집도가 낮다고 볼 수 있다. 06. 메시지와 인터페이스 디미터 법칙 클래스 내부의 메서드는 아래 조건을 만족하는 인스턴스에게만 메시지를 전송해야한다. -> this 객체 / ..
<마틴 클러스만> 데이터 중심 애플리케이션 설계 01장. 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션 트위터의 데이터 파이프라인 사례 System design for Twitter The Architecture Twitter Uses To Deal With 150M Active Users, 300K QPS, A 22 MB/S Firehose, And Send Tweets In Under 5 Seconds 꼬리 지연 시간 상위 백분위 응답 시간은 서비스의 사용자 경험에 직접 영향을 주기 때문에 중요하다. 예를 들어 아마존은 내부 서비스의 응답 시간 요구사항을 99.9분위로 기술한다. 99.9분위는 요청 1000개 중 1개만 영향이 있음에도 말이다. 보통 응답 시간이 가장 느린 요청을 경험한 고객들은 많은 구매를 해서 고객 중에서 계정에 ..
도커/쿠버네티스를 활용한 컨테이너 개발 실전 입문 03. 컨테이너 실전 구축 및 배포 애플리케이션과 시스템 내 단일 컨테이너의 적정 비중 도커는 애플리케이션과 인프라를 도커 컨테이너라는 단위로 분리한 것이라 볼 수 있다. 이런 관점에서 웹 애플리케이션과 워커형 상주 애플리케이션 프로세스 하나를 하나의 컨테이너로 만드는 방식 (컨테이너 1개 = 프로세스 1개)이 괜찮게 생각될 수 있다. 실제로 도커 초기에는 "컨테이너 1개 = 프로세스 1개"를 반드시 지켜야 한다고 생각하는 사용자가 있어 자주 토론거리가 됐다. 그러나 "컨테이너 1개=프로세스 1개" 원칙을 고수하는 것은 무리이다. 예를 들어, 크론 프로세스에서, 다른 job을 실행하는 경우가 있다. 사실 도커 공식문서에는 "컨테이너는 하나의 관심사에만 집중해야 한다"라고 적혀있다. 즉, 컨테이너 하나가 ..