[100자평] RxJava를 활용한 리액티브 프로그래밍

RxJava를 활용한 리액티브 프로그래밍 - RxJava의 개념과 사용법, 실무 활용까지 (안드로이드 활용 사례 포함) ㅣ 프로그래밍 인사이트 Programming Insight
토마스 누르키비치.벤 크리스텐센 지음, 김인태 옮김 / 인사이트 / 2017년 4월

추천 받아서 보고 있는데... 문장 하나하나가 한번에 읽히지 않는다.
내가 문제인가 싶어, 원문을 찾아 보니... 한숨이 나온다.

실무자를 위한 그래프 데이터 활용법

실무자를 위한 그래프 데이터 활용법
데니즈 고즈넬.마티아스 브뢰헬러 지음, 우정은 옮김 / 한빛미디어 / 2022년 5월

1. 이 책은 제목에서 알 수 있듯이 그래프 데이터베이스 사용에 대한 입문서라고 할 수 있을 것 같다. 개인적으로 그래프 데이터베이스라는 단어를 접한 것은 NoSQL이 대두되는 시기에 그 종류 중 한가지로 접했었다. 바로 떠오르는 디비로는 Neo4j 정도인데... 사용해본 적은 없다. 페이스북을 중심으로 소설 미디어 서비스가 떠오르면서 이를 구현하는 기술적인 분야에도 많은 변화의 바람이 불었는데 그래프 DB도 한 몫을 했었던 것 같다. 

2. 왜 그래프 DB 인가? 이 책의 시작은 이 질문에 대해 친절히 설명해주고 있다. 관계형 디비에서 그래프 디비로 넘어가야하는 이유. 당연하겠지만 그래프 디비가 관계형 디비를 대체하는 그런 것은 아니다. 모든 것이 그렇듯이 각각의 기술이 좀 더 적합한 분야가 있을 뿐. 하지만, 이 책에서 설명하는 내용들은 좀 원론적인 내용으로, 확 와닿는 무언가를 느끼진 못했다.

3. 이후 책은 제목처럼 실무에서 사용할 수 있을 법한 주제들을 중심으로 모델링과 사용법들을 실습을 통해서 진행한다. 모델링에 대한 설명들은 친절하고 이해도 잘 되었다. 다만 아쉬운 것은 여기서 사용하고 있는 기술들에 대해 좀 더 자세한 설명이 있었으면 어떘을까 한다. 예를 들어 어떤 기술들이 있는지, 어떤 차이점들이 있는지... 그리고 사용하고 있는 기술이나 디비들도 생소한데, 이에 대해 좀 더 자세한 사용법이 빠져있는게 아쉬웠다. 

4. 그래프 알고리즘, 그래프 데이터베이스에 대한 기본적인 개념과 활용 방법에 대해 배울 수 있어 좋은 기회였던 것 같다. 하지만 책에서도 말하듯이 "여정을 시작했을 뿐"이다. 실제 프로젝트에 그래프 데이터베이스를 당장 활용하기에는 어려움이 따를 수 밖에 없다. 이 후에는 특정 디비를 선택해서 그에 대해 좀 더 깊이 학습을 해본다면 도움이 될 것 같다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

마이 어려버...

유연한 소프트웨어를 만드는 설계 원칙 - 막다른 골목 없이 진화하는 시스템 개발하기
크리스 핸슨.제럴드 제이 서스먼 지음, 류광 옮김 / 한빛미디어 / 2022년 3월

개발 관련 필독서에 항상 상위에 올라오는 책들이 있다. 하지만 그 책들을 온전히 받아들이고 흡수할 수 있느냐는 다른 얘기다. 이 책 “유연한 소프트웨어를 만드는 설계원칙”도 그런 책 중 하나라고 생각이 든다. 내가 처음부터 이런 말로 시작하는 이유는 책 내용이 그만큼 쉽지 않기 때문이다.

가산적 프로그래밍 Additive programming

저자들이 이 책을 통해 “요구사항이 변해도 작동 중인 프로그램을 뜯어고칠 필요 없이, 그냥 새로운 기능을 구현한 코드를 추가하거나 기존 함수를 새로운 요구사항에 맞게 조정할 수 있어야 한다” 라는 핵심 가치를 가산적 프로그래밍 이라고 부른다. 사실 이 책의 핵심 주제는 위의 저 문장안에 모두 들어있다고 보면된다. 그리고 책에서는 이를 추구하기 위한 기법들을 소개한다.

사실 이 주제가 특별한건 아니다. 이를 다루는 책들도 많으며, 지겹도록 듣는 “객체지향 프로그래밍의 특징과 원칙”, “디자인 패턴” 들의 태생도 별반 다르지 않기 때문이다. 다만, 이 책의 차별점이자 개인적으로 느끼는 단점으로는 저자들의 설명이 단순하지 않고, 어려운 비유를 들고 있다는 것이다.

생체계들은 견고성을 엄청나게 진화시켰다. 생체계의 한 가지 특징은 중복성이다. 간이나 콩팥 같은 장기는 중복성이 높다. …

유전 부호 자체가 충중적이다. 코돈에서 아미노산으로의 사상은 일대일 사상이 아니다. …

제 1장의 제목인 “자연과 설계의 유연성”에서도 알 수 있듯이 책 전반에 있어서 이런 내용을 기반으로 설명을 한다. 개인적으로는 이런 비유들은 한번 읽어서는 오히려 각 챕터별 주제를 이해하는데 방해가 되기도 했다. 즉, 나의 수준이 못 따라간다고 해야할 것 같다.

함수형 프로그래밍

책의 예제로 사용되는 언어인 ‘스킴’은 “함수형 프로그래밍과 절차적 프로그래밍을 지원하는 다중패러다임 프로그래밍 언어” 라고 정의하고 있는데, 책에서 설명하고 있는 많은 기법들을 읽다보면 함수형 프로그래밍을 떠올리게 되었다. 작은 단순한 함수들의 조합으로 더 크고 복잡한 시스템을 구축할 수 있는 강력함을 맛보게 해주는 것 같았다. 하지만 함수형 프로그래밍에 익숙하지 않은 나와 같은 사람에게는 다소 개념들이 어렵게 다가오고, 스킴이라는 언어 또한 그리 친절하진 않았다. 처음엔 수도코드 수준으로 읽어지겠지 싶었지만, 전혀 그렇지 못했다.

조금은 학술적인…

저자 중 한 분은 컴퓨터 프로그램의 구조와 해석 이 책의 저자이기도 한데, 이 책 또한 가벼운 책은 아니다. 이 처럼 읽는데 어려움을 느끼다보니, 내용에 있어서 실용적이기 보다는 학술적인 내용으로 읽혀질 수 밖에 없었다. 저자들의 지식을 온전히 흡수하기 위해서는 중급 이상의 내공을 필요로 한다고 본다.

“한빛미디어 <나는 리뷰어다=""> 활동을 위해서 책을 제공받아 작성된 서평입니다."

소프트웨어 아키텍처 101

소프트웨어 아키텍처 101 - 엔지니어링 접근 방식으로 배우는 소프트웨어 아키텍처 기초
마크 리처즈.닐 포드 지음, 이일웅 옮김 / 한빛미디어 / 2021년 11월

이 책을 선택하고 책장을 펼치기 전까지도 사실 "아키텍트"에 대해서는 관심이 없었다. "소프트웨어 아키텍처"라는 주제에 관심을 두면서도, 아키텍처를 결정하는 사람이라고 할 수 있는 "아키텍트"에 대해서는 관심이 없었다는게 지금와서 생각해보면 좀 이상한 것도 같다. 그러고 나서 또 가만히 생각해보면 내 주위에 자신을 아키텍트라고 말하는 사람도 없었던 것은 사실이다.

내가 기대했던 책의 내용은 소프트웨어 아키텍처에 대한 소개와 구현에 대한 내용이라고 짐작하고 있었다. 그런데 이 책은 아키텍처를 결정해야하는 "중요한" 역할의 아키텍트에 대해 먼저 이야기를 풀어나간다. 단순히 아키텍처의 특징은 무엇이고 장단점은 무엇이다를 설명하는게 아니라, 아키텍트의 입장에서 아키텍처를 결정하기 위해 어떤 것들에 집중해야하는지를 시작으로 이야기를 풀어나간다. 

앞서 얘기했지만, 적지않은 개발경력에도 (물론 큰물에서 아직 놀아보지 못해봐서 그럴 수도 있지만) 아직 명함에 "아키텍트" 라고 써있거나, 스스로를 아키텍트라고 소개하는 사람을 만나보지 못했다. 그렇다면 내가 지금까지 진행했던 프로젝트들의 아키텍처는 "누가" 결정한 것일까? 대부분이 아시겠지만, 보통은 경험이 많은 시니어 개발자가 보통은 결정할 것이다. 그리고 더 아이러니는 프로젝트를 여럿 진행하면서도 우리 프로젝트의 아키텍처는 "이것"으로 결정했다 거나 하는 얘기도 들어보진 못했다. 그만큼 주먹구구식의 프로젝트 였을 수도 있고, 암묵적인 표준이라고 할만한 아키텍처를 컨벤션처럼 받아들이고 있었는지도 모른다. 아마 이것이 이책에서도 소개하는 모놀리식한 레이어드 아키텍처 스타일 이었는지도 모르겠다. 이런만큼 이 책은 내게 특별하게 다가왔다. 

이 책은 크게 세 파트로 나눠져있다. 첫 파트인 '기초'에서는 아키텍처의 특성에 대해 상세하게 다룬다. 사실 이 부분에서 그리 쉽게 읽히지만은 않았다. 오히리 두번째 파트의 아키텍처 스타일에 대한 내용은 조금 더 구체적이고 기술적인 내용이라 더 쉽게 읽혔던 것 같다. 그 이유는 아마도 생소한 단어들 때문이 아닌가 싶다. 생소하지 않더라도 명확한 의미보다는 뭔가 조금 추상적이고 개념적인 뜻으로 다가오는 단어들이 중간 중간 끼어있다보니 한번에 술술 읽히기 보다는 컴퓨터가 옆에 있으면 검색을 한번 해본다거나 하는 인터럽트가 발생하는 경우가 좀 있었다. 그렇다고 너무 어렵다거나 이해를 전혀 못할만한 내용은 아니니 겁을 먹을 필요까진 없을 것 같다.

두번째 파트에서는 개인적으로 가장 궁금했던 각 아키텍처 스타일들에 대해 설명하고 있다. 물론 다른 책들을 통해서 이해하고 있던 내용도 있었지만, 처음 들어보거나 이걸 이렇게 따로 분류를 하기도 하는구나 싶은 내용도 있었다. 그리고 결국 요즘 핫한 '마이크로서비스' 역시도 아무것도 없는 상황에서 마법처럼 등장한게 아니라는 것이었다. 그리고 이 모든것의 핵심은 "트레이드 오프" 라는 것. 절대적인 해결책이 있는 것이 아닌 각 프로젝트의 요구사항에 따라 결정을 해야한다는 것이다. 그래서 각 스타일별로 특징과 장단점 등을 설명하고 "아키텍처 특성 등급표" 라는 것을 보여준다. 단순히 어떤 아키텍처 스타일이 더 좋고 나쁜게 아니라 앞에서 설명한 아키텍처 특성들 별로 별점을 통해 평가를 하고 있다. 예를 들어 "확장성"은 별5개 만점이지만 "단순성"은 별1개라거나... 또한 각 스타일별로 그림을 통해서 아키텍처의 구성도를 상세하게 보여주고 있어서 이해도를 높이는데 도움이 되었다.

그리고 마지막 파트인 "테크닉과 소프트 스킬"에서는 아키텍처와 관련있는 다양한 주제들을 다루고 있다. "도식화 및 프레젠테이션" 에서는 아키텍트로서 필요한 소프트 스킬이라고 할수 있는 아키텍처를 어떻게 도식화하고 프리젠테이션을 준비하면 좋은지를 설명하고, "협상과 리더십 스킬" 챕터를 통해 바람직한 리더가 될 수 있는 팁들을 담고있다. 마지막은 "커리어패스 개발" 이라는 주제로 아키텍트가 되기 위해 어떤 노력을 하면 좋은지에 대한 노하우를 제시한다. 책 전반적으로 이런 깨알같은 팁들이 등장하는데, 개인적으로 이런 내용들에 포스트잇을 더 많이 붙이게 되는 것 같았다.

아키텍트, 아키텍처라는 단어에 거부감을 가지거나 어려움을 가지는 사람들이 많다고 본다. 관련해서 등장하는 용어들도 딱딱한 것 같고. 그래서 이런 얘기를 주제로 토론을 하기가 쉽지 않은 것 같다. 이럴 때 구성원들이 이런 책을 통해 이해도를 높인다면, 현재 진행중이거나 앞으로의 프로젝트 개발에 많은 도움이 되리라 생각한다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

SQL Cookbook

SQL 쿡북 - 모든 SQL 사용자를 위한 쿼리 완벽 가이드
앤서니 몰리나로.로버트 더그래프 지음, 송희정 옮김 / 한빛미디어 / 2022년 1월

“한빛미디어 <나는 리뷰어다=""> 활동을 위해서 책을 제공받아 작성된 서평입니다."

아주 오랜만에 읽게된 SQL 서적인 것 같다. 마지막으로 읽었던 SQL 관련 책은 “SQL AntiPatterns” 였다.

이책 SQL Cookbook 은 전형적인 Cookbook 형식의 책으로 14개의 챕터로 각 챕터마다 큰 주제 아래 여러개의 문제들로 이뤄져있다. 쿡북의 장점답게 처음부터 모든 내용을 읽어나갈 필요는 없고, 먼저 목차를 보면서 관심이 가거나 가장 궁금했던 주제나 문제별로 찾아서 읽는 장점이 있겠다. 물론 입문자라면 처음부터 하나씩 읽어나가도 문제없을 정도로 난이도 조절도 잘 되어있다고 생각이 든다. 각 챕터별 초반엔 기초적인 내용부터 시작해서 점차 난이도를 높여가는 식이다. 또한 각 문제별 솔루션마다 RDBMS 종류에 따른 해법을 모두 알려주고 있기에 다양한 벤더의 DB를 사용하는 사람에게는 더없이 훌륭한 가이드가 될 것으로 생각된다. 만약 본인이 한가지 DB만 사용한다면 해당 DB에 대한 해법만 찾아보는 본다면 책을 다 읽는데 드는 시간도 단축될 것이다.

개인적인 생각으로 추천해주고 싶은 대상은 어느정도 SQL을 다룰줄 알지만, 아직은 복잡한 쿼리를 뽑기위해서는 어려움을 격는 분들이 적당할 것 같다. 완전 입문자가 보기에는 문법자체를 하나씩 알려주지 않다보니 어려움이 있을 것으로 생각된다.

개인적으로 아쉬웠던(?) 부분은 사용하는 SQL 이 ANSI-89 표준을 사용하고 있다는 것인데, 물론 나역시 이 SQL 스타일에 익숙하고 자연스럽긴하지만 ANSI-92 문법도 보여주었으면 어땠을까 싶은 생각도 들었다.

이 책을 읽으면서 느낀 주관적인 단점 한가지는 번역에 있었는데… 번역이 잘못되거나 번역기를 돌린 수준이냐하면 꼭 그렇진 않다. 그런데 내가 문제인지 문장을 읽다보면 한번에 확 와닿지 않는다고 해야할까? 어색하다고 해야할까. 처음엔 옮긴이가 전공자가 아닌줄 알았는데 누구나 아는 외국계 대기업 출신이었다. 전반적으로 단어의 선택이나 문장간의 연결이 매끄럽지 못한 곳이 눈에 띄어 아쉬었다.

그럼에도 불구하고 SQL을 주로 사용하는 개발자라면 옆에 두고 필요할때마다 꺼내보면 좋을 것 같다.