한빛미디어

이 책에 쓰여 있는 내용들은 언젠가 실무에서 반드시 대면하게 될 내용들이다. 다만, 그것을 글로 체감하는 것과 경험을 한 후, 책을 통해 얻는 깊이는 다를 것이다.

요즘 필자가 회사 업무를 담당하며 대면한 문제는 바로 모든 객체의 독립된 성격을 보존하는 동시에 가독력이 보장된 프로젝트를 만드는 것이다.

솔직히 업무를 혼자 하는 것이라면 코드의 규칙이나 아키텍처가 어찌 되었건 결과적으로 돌아가는 무엇인가만 나오면 된다.
확장이 가능한 느슨한 구조? 대략적인 인터페이스만 잘 뽑았다면 나중에 적당히 틀만 맞추면 되는 일이다.

인프라 확장? MQTT를 비롯한 분산 구조로만 대략적으로 구성하면 되는 문제다.

하지만, 협업의 관점에서 누군가가 내 코드를 봤을 때 혼란의 여지가 없고, 혹 실수를 하더라도 그 영향력을 최소화하는 프로그램을 구성한다는 것은 대단히 어렵고 쉽지 않은 이야기이다.

그런 관점에서 이번에 리뷰를 진행한 함수형 프로그래밍 책은 누군가 추후 내 손을 떠난 이 프로젝트를 건들 때, 혹은 같이 협업을 하며 복잡한 로직을 누군가 살펴볼 때, 혼란의 여지를 줄이고 코드의 가독력과 생산력을 향상시키는 팁들과 관련 기술들을 묶은 훌륭한 책이라 할 수 있다.


【책의 구성】 "함수형 프로그래밍 with 자바"의 구성은?

본 서를 공부하기 좋았던 이유는 샘플 코드가 많다는 것이었다.

저자가 충분히 글로써 친절히 설명하려 노력한 부분이 다수 보이나, 솔직히 코드를 설명하는 것은 코드를 보여주는 것만큼 훌륭한 접근법은 없다. 이 책은 글뿐만 아니라 예가 되는 샘플 코드들을 다수 채용하여 독자에게 제공하고 있기 때문에, 애매한 부분 없이 확실히 이해하는 데에 큰 어려움이 없었다.

또한, 실무에서 대면할 법한 어려운 문제들에 대해서도 저자의 생각과 고찰이 적절히 이 책에 녹아들어 있기 때문에, 주니어와 시니어 사이를 달리는 중니어들이 이 책을 본다면 많은 것을 얻을 수 있을 것이라 생각된다.

솔직히 너무 주니어들은 이 책을 읽어도 아~ 이런 게 있구나 정도이지 않을까 싶긴 하다.

 

챕터 1 : 함수형 프로그래밍 소개

거의 대부분의 책이 그렇듯. 이 책도 처음 챕터는 함수형 프로그래밍이 무엇인지. 함수형 프로그래밍이 지향하는 바가 무엇인지에 대해서 설명하고 있다.

모든 법이 헌법에 그 근간을 두었듯, 모든 학문에 있어서 그 학문이 탄생하게 된 배경을 아는 것은 중요하다. 그렇기에 꼭 해당 챕터를 꼼꼼히 읽어두도록 하자.

함수형 프로그래밍은 무엇일까? 간단하다.

순수하며, 일관되며, 간결된 이 삼박자를 갖추면 그것이 함수형 프로그래밍이다. (간추려 정리하자면..)

 

챕터 5 : 레코드

이 장은 레코드 타입에 대해서 설명하고 있다.

솔직히 POJO나 JavaBean이나 그 등장 배경은 코드를 많은 사람들이 보았을 때 통일성을 갖추게 하기 위함에 있다. 이 말이 무엇인고하면 A라는 객체가 있으면 그 A라는 객체는 중간에 변조 없이 A라는 객체의 본연의 역할 그 자체에 충실하면 된다는 것이다.

하지만, 앞서 언급한 POJO든 JavaBean이 든 그 역할을 함에 있어서 아쉬운 부분이 많이 있었다. 중간에 변조가 발생할 수 있는 setter를 허용한다거나 보일러 플레이트 코드를 구성하기 위해 객체 정의의 상당 부분을 해당 코드로 낭비하는 등이 그것이다.

하지만 modern java에서 지원해 주는 record라는 타입은 그러한 단점을 극복하고 보다 독립화된 객체를 쉽게 구성하는 데에 초점을 둔 타입이라 할 수 있다.

필자가 10년 넘게 웹서비스 회사에서 일해보았지만, 아직 레코드 타입은 대중화가 안된 것 같긴 하다. 왜냐하면 대부분의 코드가 아직도 POJO나 JavaBean과 같이 옛날 형식 그대로 여전히 이어져 내려오고 있기 때문이다.

아마 프로젝트가 오래되었거나, 아니면 이전 방식에 익숙한 다수의 개발자들에 의해 프로젝트가 시작되었기 때문이리라...

【 함수형 프로그래밍 with 자바를 읽고 나서 】

필자는 그동안 프로그래밍의 관점을 크게 객체지향적이냐 아니면 절차 지향적이냐 이 두 가지 분류로 나누곤 했는데, 이 책을 읽으며 객체지향적이건 절차 지향적이건 가장 중요한 관점은 다수가 코드를 보았을 때, 코드 하나하나의 역할이 확실히 정해져 있고, 중간에 변조가 없어 해당 객체 하나만으로도 그 룰이 충분히 정해지는 그런 코드가 협업에 있어서 중요하다는 것이었다.

물론 협업을 하더라도 본인이 담당한 영역에 다른 사람이 손을 대는 일이 거의 없다면 위의 관점에서 프로그램을 구성하는 것은 낭비일 수 있다. 왜냐하면 어차피 내 코드는 나만 담당하고 나만 보는데, 어찌 프로그램을 짜든 무슨 상관이란 말인가?

하지만 위와 같은 자세는 상당히 위험하다. 왜냐하면 누군가 꼭 보기 때문에 코드의 역할을 잘 세분화하고 가독성 있게 짜야 하는 것이 아니기 때문이다.

옛말에 이런 말이 있다. '보기 좋은 떡이 먹기도 좋다.' 그렇다. 코드도 '보기 좋은 코드가 퍼포먼스, 코드 확장에 있어서도 용이하다.' 즉, 각 객체의 역할을 각 객체 본연의 성격에 맞게 잘 구성하고 코드의 가동력이 뛰어나며 이와 동시에 각 구간이 독립적으로 잘 추상화되어있는 프로젝트 그것이 바로 '보기 좋은 떡'에 해당하는 것이다.

이제는 나름 규모가 있는 프로젝트는 혼자 하기엔 그 허들이 높아진 시대라 할 수 있다. 옛날 같으면 일인 개발자다 뭐다 해서 금방 금방 프로덕트를 뽑아냈지만, 지금은 조금 규모가 있다 싶은 프로젝트들은 어느 정도 개발자들을 모아 협업 없이는 만들 수 없는 시대가 되었기 때문이다. (아.. 물론 언젠가 이 부분을 AI가 대신해 줄 것이라 생각되지만..)

따라서 협업의 관점에서 프로그램을 만들 줄 아는 능력. 이것이야말로 진정한 시니어로 거듭나는 지름길이라 할 수 있다.

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