멀티패러다임 프로그래밍 서평

도서정보: 한빛미디어 | 유인동 지음 | 511p | 2025년 4월 21일 발행

 

2024년 여름 유인동님의 이전 저서인 함수형 자바스크립트 프로그래밍 책을 가지고 스터디를 진행했었습니다. 그 경험은 저에게 많은 영감을 주었고, 더 좋은 소스코드를 작성하기 위해 고민하게 만들었으며, 읽기 좋고 유지보수하기 용이한 코드를 작성하는 실력을 높여주었다고 생각합니다. 그렇게 1년이 지나 최근 멀티패러다임 프로그래밍 책의 발간소식을 듣게 되었습니다. 저에게 많은 영향을 주었던 저자님의 신간 발간 소식이었기에 꼭 읽어봐야겠다는 생각을 하고 있었습니다. 특히나 책의 소개 문구가 신선했습니다. 

멀티패러다임 프로그래밍 - 유인동 (한빛미디어)

“객체지향, 함수형, 명령형의 통합적 사고로 구현하는 소프트웨어 설계와 구현”
- 멀티패러다임 프로그래밍

“어!? 이 3개가 합쳐지는거였다고?” 마침 서평단 모집 이벤트가 열려 응모하였고, 참 감사하게도 서평단으로 선정해주셔서 이렇게 책을 읽고 서평을 작성해봅니다.

 

멀티패러다임과 가치를 전하는 프로덕트

우리는 주변에서 패러다임간의 우위를 논하는 장면을 어렵지 않게 목격하게 됩니다. 가독성을 위해 명령형보다는 선언형으로 작성해야 한다거나, 특정 패러다임이 대세라든가 하는 이야기들 말이죠. 우리는 일반적으로 “하나의 메인 패러다임과 나머지 보조 패러다임들”과 같은 방식으로 프로그래밍을 바라보아 왔습니다. 굳이 함수형 체이닝 방식을 지원하는 구조를 만들어보려고 코드를 더 복잡하게 만들어버린다거나, for(명령형)문으로 마무리지어야 할때면 괜히 아쉬움이 남는다거나 하면서 저 자신도 그 관점에서 자유롭지 못했습니다. 책은 어떤 상황에 어떤 패러다임이 적절하며, 때로는 과감히 패러다임을 버려야함을 이야기해줍니다.

395p.
명령형 스타일은 상황에 따라 오히려 코드를 단순하고 명확하게 만들수 있습니다. 

184p.
각 패러다임으로 작성한 코드는 서로를 완전히 대체할 수 있으며 필요하다면 섞어서 사용할 수도 있습니다. 멀티패러다임 언어를 사용하는 우리는 언제든지, 심지어 하나의 함수 안에서도 상황에 따라 가장 알맞은 패러다임을 선택하거나 조합하여 활용할 수 있습니다.

하나의 패러다임을 선택하고 모든 코드를 그 패러다임에 맞춰 마치 다른 클래스는 포기하고 전직을 해야만 하는 게임 캐릭터의 운명처럼 개발을 해야할 것 같은 느낌이 있었습니다. 특정 조직의 개발 문화도 우리는 함수형이다, 객체지향이다 처럼 하나의 패러다임으로 대표될 것이라고 생각하기도 했었습니다. 그러나 과감히 특정 패러다임을 포기하는 것도 하나의 선명한 옵션일 수 있음을 책은 말해주고 있습니다.

386p.
특정 부분은 함수형 패러다임이 적합하고 어떤 부분은 명령형 코드가 더 단순할 때, 두 패러다임을 과감히 섞거나 빼는 태도가 유지보수성과 확장성에 도움을 줄 수 있습니다.

만약 당신이 이미 “패러다임이 무슨 상관이야. 고객에게 가치를 전하는 제품을 만드는 게 더 중요하지.”라는 가치관을 갖고 있었다면 크게 박수를 쳐드리고 싶습니다. 그러한 가치관에 이 책이 이야기하는 멀티패러다임의 가치가 더해진다면 더욱 지속가능한 제품개발을 이어갈 수 있을 것입니다.

498p.
이러한 구조(멀티패러다임 기반 소프트웨어 개발 아키텍처)는 규모가 큰 애플리케이션에서도 유연성과 확장성을 보장하며 프로젝트가 장기화될수록 안정성, 유지보수성 그리고 추가 기능 개발에 큰 이점을 제공합니다.

 

변하는 것과 변하지 않는 것

제프베조스: 변화를 묻지 말고, 불변을 보라” - ChatGPT 로 생성 Excalidraw 로 수정

누군가 10년 후 어떤 변화가 있을 것이라는 기자의 질문에 10년 뒤에도 변하지 않을 것이라는 더 중요한 것에 대해서는 왜 질문하지 않느냐라고 반문했다던 아마존의 제프 베조스 회장의 일화는 유명합니다. 멀티패러다임 프로그래밍은 10년 뒤에도 변하지 않을 것에 대한 이야기입니다. 우리 개발자들은 평생 새로운 기술을 습득하고 새로운 지식을 학습해야하며 심지어 그것을 즐기는 사람들입니다. 하지만 대부분은 또 한편으로 뒤처지면 어쩌나 하는 불안감을 갖고 있는 것도 사실입니다. 이 책은 그런 불안을 어느정도 해소해주는 요소도 갖고 있었다고 생각합니다. AI 의 시대에 여전히 멀티패러다임적인 사고를 갖고 사람이 관여해야할 부분이 있다는 것을 직접 보여줍니다. 또한, 채용 시장 위에서 생산성(추후 확장성과 유지보수성을 보장한)으로 평가 받아야만 하는 피고용인의 입장에서 갖추어야할 좋은 개발자의 자질을 스스로 정의할 수 있도록 도와줍니다.

 

유대인의 속담에 삼겹줄은 끊어지지 않는다는 말이 있습니다. 명령형, 함수형, 객체지향의 세 패러다임을 섞는다는 그시도가 곧 삼겹줄이 되어 앞으로도 끊어지지 않을 개발자의 기본기로 만들어봐야겠다는 생각을 해보게 됩니다.

 

다시 기본으로

401p. 탄탄한 기본기는 결국 뛰어난 응용력을 이끌어냅니다.

 

책을 읽으면서 더욱 친숙해질 수 있었던 기본기에 준하는 개념들을 나열해봅니다.

Promise

저는 2018년도 여름에 본격적으로 개발을 업으로 삼기 시작했는데, 저는 비동기-논블록킹 언어인 javascript 를 async/await 을 남발하며 거의 블록킹 언어처럼 사용했던 부끄러운 과거가 있는 개발자입니다. 조금씩 비동기 방식의 프로그래밍에 익숙해지면서, 비동기 처리에 관해 새로운 관점을 제시해줬던 게 『Node.js 디자인 패턴 바이블』이라는 책이었고, 『멀티패러다임 프로그래밍』을 통해 그 관점을 확장할 수 있었습니다. javascript 개발자(node, typescript)에게는 Promise 는 기본개념이지만, 오랫동안 익숙하게 사용해왔던 Promise 에 관해서도 보완할 부분이 있다는 점을 발견할 수 있었고(예제의 코드를 보고도 동작을 제대로 예측하지 못했던 부분이 더러 있었던 점), 기본기에 대해서 더욱 제대로 공부하고, 다양한 사례에 익숙해질 필요가 있겠다는 생각을 하게 되었습니다

비동기 프로그래밍

비동기 동시성 제어에 대한 실무 경험을 해본 경험이 많이 없습니다. 비동기 요청을 한꺼번에 보내야 하는 상황의 대부분은 await Promise.all(…) 로 해결이 가능했었고, 한꺼번에 수 백개의 요청을 보낼 때 런타임 제약으로 인해 요청을 끊어 보내야 할 때도 있었지만, 단순히 요청을 임의의 개수로 나눠 각각을 await Promise.all() 하여 보냈던 기억이 납니다. 책에서는 비동기 동시성 제어에 관해서는 거의 최종 보스급으로 비동기 방식 기반으로 동시성 핸들링 기능을 구현하게 되는데 (6.2. 멀티패러다임을 활용한 동시성 핸들링) n 개의 비동기 작업을 한 번에 m 개씩 수행하도록 하는 일종의 동시성(부하) 제어 부분을 다룹니다. 이제 비동기 동시성 제어를 활용한 부하 처리를 위한 지식적 기반은 갖추게 되었으니 수백만개의 요청이야 만들면 되는 것이고 백엔드 개발자의 통과의례처럼 여겨지는 대용량 부하 처리 경험에 한걸음 가까워진 느낌입니다. 토비의 스프링의 저자이신 이일민님께서는 새로운 기능의 튜토리얼만 20~30번을 직접 작성하고 실행해보면서 기능의 본질을 파악하신다고 합니다. 이 책의 비동기 요청 동시성 제어 파트는 이일민님의 일화의 방식을 적용해보아야겠다는 생각이 드는 파트였고, 시간을 내어 꼭 도전해볼 계획입니다.

언어에 대한 이해

23p. 현재 우리는 어쩌면 특정 라이브러리나 프레임워크에 의존하며 그에 맞는 한정적인 패러다임을 따르다가 언어 레벨의 다양한 기능과 패러다임을 충분히 활용하지 못하고 있을지도 모릅니다.

특정 프레임워크나 라이브러리의 사용에 익숙해지다보면 대부분의 문제 상황이 이미 정형화된 패턴 위에서 손쉽게 해결되기 때문에 기본 문법에 소홀하게 되는 경향이 있는 것 같습니다. 꼭 특정 프레임워크나 라이브러리에 종속되는 부분에서 오는 문제이기 이전에, 비즈니스적 요구사항은 대체적으로 이전에 이미 작성된 누군가의 코드 패턴을 복사해오는 것으로 해결이 가능한 상황이 많았던 것도 언어의 기본에 대해 소홀하게 되는 원인으로 꼽을 수 있다고 생각합니다. 그러한 일반 개발자들에게 22년차의 경력을 가진 개발자가 책을 통해서 그동안의 경험을 밀도있게 전달해주고 있습니다. 특히 현업 관점에서 javascript, typescript 에 관해서는 언어 자체의 패러다임의 보다 깊은 이해와 함께 현직 개발자들의 코드 표현력을 높여준다고 생각합니다.

동작하는 코드 그 너머

424p. 어쩌면 우리의 이벤트가 자꾸만 루프에 빠지고 부수 효과가 발생하는 이유는 처음 작은 문제를 마주했을 때 근본적인 원인을 파악하기보다 구조가 어긋난 상태에서 단순히 if 문으로 상황을 막으려 하거나 이벤트와 상태/흐름을 관리하는 라이브러리를 무분별하게 도입하는 등의 단편적 대응을 했기 때문일지도 모릅니다.

우리는 매일 과거의 코드와 씨름합니다. 레거시, 동료의 코드, 심지어는 과거의 내가 작성한 코드도 그 싸움의 대상이 됩니다. 좋은 개발자는 유지보수(및 디버깅)하기 쉽고, 확장에 유리하며, 비즈니스적 요구사항에 신속하고 유연하게 대처할 수 있는 코드 베이스를 어떻게 구성할 수 있을지 고민합니다. 책은 그 고민에 도움이 될 만한 현실적인 해답을 책 전반에 걸쳐 제시합니다. 책의 전반에 걸쳐 좋은 개발 문화를 위해 실무에 적용해볼 수 있을 법한 내용들이 조각 조각 분포되어 있습니다. 긴 호흡으로 읽어가며 한 부분 한 부분 어떻게 현업에 적용해볼 수 있을지 고민해보는 것도 좋은 읽기 방법이 될 것이라고 생각합니다.

 

책의 장단점

적은 시각 자료

(추측이지만) 출판사와 저자가 책의 분량을 애써 줄이려고 한 흔적들이 있습니다. 아마도 일반 소설책 정도의 두께에 저자가 전하고자 하는 바를 최대한 놓치지 않고 담으면서도, 독자가 책의 분량이나 가격과 같은 책의 외형에 압도되지 않기를 바란 것이 아닐까 추측해봅니다.

어떻게든 제한된 분량 안에 중요한 것에 집중하며 많은 것을 전달하려는 출판의도에 대한 추측을 사실이라고 가정해본다면 모두 이해가 되는 부분이지만, 책의 물리적 분량을 줄이기 위한 노력의 일환으로 세부 내용이 축약되거나 포함되지 않은 것처럼 느껴지는 부분들이 있습니다. 책의 전반적인 흐름과 의도를 헤치는 수준은 아닙니다. 하지만 보완된다면 독자가 개념을 이해하는 데 더욱 도움이 될 만한 부분들도 있었다고 생각되는데요. 가령, 로직을 한국어 문장으로만 설명(마치 수능의 비문학 지문같은 느낌)하여 코드를 직접 떠올려보아야 했던 부분이 있었고, 규모가 큰 객체 구조에 대해서는 다이어그램을 포함해주었으면 어땠을까 하는 부분들이 있었습니다. 하지만 그러한 부분일지라도 곱씹으면서 또는 직접 손으로 그려보면서, 그리고 무엇보다 예제코드에 대해서는 책을 200%로 활용하기 부분에서처럼 직접 코딩해보면서 구조를 그려본다면 연결과 이해가 더욱 와닿게 될 것이라고 생각합니다.

대상 독자

또한 책에서는 “언어의 기본문법을 이해”하고 있으면 어렵지 않게 읽을 수 있음을 이야기하고 있습니다. 반면, 한빛미디어의 도서 소개페이지에서는 책의 난이도가 “중고급”으로 표현되어 있는데요. ‘중고급’이라는 표현이 보다 추상적이기는 해도 오히려 책의 난이도를 더 적절히 표현한 것 같아보입니다. 만약 책을 읽어야 할 지 말아야 할 지 고민하는 입문자가 있다면 저는 다음과 같이 조언해줄 것 같습니다. 굳이 읽어야겠다면, 사례를 중심으로 무엇을 할 수 있게 되는지 가볍게 읽고 이해가 당장 되지 않더라도 어느정도 수준이 있는 내용이니까 너무 압도되지는 말라고요.

예제의 높은 실무 연관성

책의 초반부(이론)에서는 각 패러다임의 이론적 토대를 설명하기 위해 [1,2,3] 과 같은 예시용 데이터들을 활용한 예제들이 주를 이룹니다. 하지만 후반부(응용)로 갈수록 예제가 실무에서 있을법한 예제를 많이 보여주는데요. 아예 실무에의 적극적인 활용을 가정하고 가능하면 실무에 바로 쓰일 수 있는 코드로 예제를 구성한 저자의 노력이 돋보입니다.

 

개인적으로 기술(기법)을 이해할 때 단순히 어떻게(how)만이해하는 것을 넘어서 무엇(what)과 왜(why)라는 맥락적인 부분과 함께 학습하면 실제 응용 상황 발생시 해당 기술(기법)을 떠올리는 데 큰 도움이 된다고 생각하는데요. 책의 응용부에서 예제는 모두 실무 연관성이 높은 예제로 구성되어 있으며, 실제로 비슷한 요구사항이 발생했을 때 해당 예제를 그대로 적용해도 될만큼 높은 완성도를 갖추고 있습니다.

 

마치며

책을 모두 읽고 나니, 함수형 프로그래밍은 로직의 흐름 곧 시간에 관한 이야기이며, 객체지향 패러다임은 구조 즉 공간에 관한 이야기인 것 같다는 생각, 그리고 명령형 프로그래밍은 이들을 엮는 물리법칙에 비유할 수 있지 않을까라는 생각을 해보게 되었습니다.

Generated By ChatGPT - Multiparadigm Metaphor Spacetime: 그런대로 잘 뽑아준 GPT의 작품

시간과 공간의 개념을 하나의 개념으로 통합했던 아인슈타인이 상대성이론이라는 위대한 업적과 함께 인류를 한 층 더 미래에 가깝게 이끌었던 것처럼, 소프트웨어 업계에 멀티패러다임이라는 방식이 다가올 미래를 더욱 앞당겨는 계기가 되기를 내심 기대해보게 됩니다.

가면서 읽고, 기다리며 읽고, 오면서 읽고, 플래그는 나중에 정리가 필요한 부분 (이해가 잘 안되거나, 새로운 개념이거나, 공유하고싶거나)

멀티패러다임이라는 개념을 5년 전에 알고 있었다면 얼마나 더 많은 코드에 멀티패러다임을 적용해볼 수 있었을텐데라는 아쉬움이 생길 정도로, 지금이라도 멀티패러다임을 알게 되어 다행이라는 생각이 듭니다. 완독 후 지금 이 순간 제게는 멀티패러다임의 아우라가 가득합니다. (망치가 생겼습니다. 그 순간 모든 것이 못으로...) 미래를 앞당기는 그 여정에 함께할 기회가 주어진것만 같은 느낌과 함께 미래에 저는 어떤 개발자로 성장해있을지 그려보게 됩니다.

 

한빛미디어의 도서 지원을 받아 작성한 리뷰입니다.