Into The Kernel

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

솔직히 고백하자면 나는 개발자이긴 한데 AI 쪽은 거의 문외한이다.
ChatGPT나 클로드 같은 건 쓰고 있지만, 그게 내부적으로 어떻게 돌아가는지는 관심을 크게 두지 않았다.
그냥 질문하면 답이 나오는 도구 정도로 인식하고 있었다.

그런데 요즘 주변에서 "AI 에이전트"라는 말이 너무 자주 들린다.
뭔가 나만 뒤처지고 있는 것 같은 느낌이 들기 시작했고, 한번쯤 제대로 들여다봐야겠다는 생각이 들었다.

이 책은 바로 그런 사람에게 어울리는 책이었다.

책 목차

• PART 01 / AI 에이전트의 개념과 원리
• PART 02 / 랭그래프로 구현하는 AI 에이전트 (싱글 에이전트)
• PART 03 / 멀티 에이전트 시스템 메모리 설계와 구현
• PART 04 / 프로토콜 기반 에이전트 확장 전략
• PART 05 / 멀티 에이전트 실전 프로젝

총 25가지 에이전트를 직접 만들어보는 구성이다.
입문부터 실전까지 한 권에 담으려다 보니 652쪽이라는 두께는 예고된 수순이었다.
앞쪽은 개념과 기초, 뒤로 갈수록 멀티 에이전트와 실전 통합으로 넘어가는 흐름이다.
개인적으로는 가치가 PART 03 이후에 몰려 있다고 느꼈다.

책 내용 중 흥미로웠던 부분

PART 01 / LLM이 어떻게 결정을 내리는지부터 설명한다

대부분의 책들이 프레임워크 사용법부터 시작하는 것과 달리, 이 책은 LLM의 동작 원리부터 출발한다.

LLM은 매 호출마다 주어진 컨텍스트만 처리하고 그 이상은 기억하지 못한다.
에이전트 프레임워크는 이 무상태 엔진 주위에 상태 관리, 도구 호출, 메모리 레이어를 씌워
"생각하고 행동하는" 시스템처럼 동작하게 만드는 것이다.

특히 ReAct와 Reflection 개념을 먼저 짚어주는 부분이 좋았다.
ReAct는 "생각하고 → 행동하고 → 관찰하는" 루프, Reflection은 스스로 결과를 검토하고 수정하는 능력이다.
이게 이해되고 나니 에이전트가 왜 단순한 LLM 호출과 다른지 납득이 됐다.

PART 02 / 랭그래프가 왜 그래프 구조인지 이해됐다

랭그래프의 그래프 기반 구조를 처음 봤을 때는 "왜 이렇게 복잡하게 만들었나" 싶었다.

책을 읽고 나서야 납득이 됐다.
에이전트의 흐름은 단순한 순차 실행이 아니라, 조건에 따라 분기하고 반복하고 되돌아가는 구조다.
이걸 표현하기에 그래프가 가장 자연스러운 방식이라는 것이다.
노드(처리 단계)와 엣지(분기 조건)로 흐름을 제어하는 방식은
개발할 때 상태 머신이나 플로우차트로 로직을 설계하는 것과 맥락이 닿아 있었다.

PART 03 / 왜 에이전트를 여러 개로 나누는가

"왜 에이전트를 여러 개로 나눠야 하는가?"라는 질문에 책은 납득가는 답을 내놓는다.

하나의 에이전트에 도구가 많아지면 LLM의 판단 정확도가 떨어지고, 유지보수도 어려워진다.
슈퍼바이저 에이전트가 서브 에이전트에게 작업을 위임하는 구조가 왜 더 안정적인지를
코드와 함께 보여주는 방식이 인상적이었다.

단순히 "이렇게 해라"가 아니라 "안 나누면 이런 문제가 생긴다"를 먼저 보여주는 것이다.
함수가 너무 커지면 쪼개는 것과 같은 논리라 이해가 빨랐다.

PART 04~05 / RAG, MCP, A2A

RAG는 LLM이 모르는 내용을 외부 문서에서 검색해서 답하게 하는 기술이다.
이 책은 RAG를 단순히 "벡터 DB에서 꺼내기"로 설명하지 않고,
어떤 데이터를 어떻게 쪼개고 인덱싱할지까지 다루는 부분이 실무적으로 느껴졌다.

MCP(Model Context Protocol)와 A2A(Agent-to-Agent)는 이름만 봐서는 뭔지 전혀 감이 안 왔다.
읽고 나서 이해한 건 이렇다.
에이전트마다 외부 도구나 다른 에이전트와 연결하는 방식이 제각각이면 나중에 통합이 엉망이 된다.
그래서 "이렇게 연결하자"는 표준을 만든 것이 MCP와 A2A라는 것이다.
API 규격을 맞추는 이유와 같다. 표준 없이 각자 다른 방식으로 붙이면 통합할 때 지옥이 펼쳐진다.

책을 읽으며 좋았던 점

AI를 잘 모르는 개발자 입장에서 가장 좋았던 건, 코드 전에 "왜"를 먼저 설명한다는 점이다.

무작정 랭그래프 코드부터 들이밀지 않고, LLM이 왜 이런 구조를 필요로 하는지를 먼저 짚어준다.
덕분에 코드를 봤을 때 "이게 이래서 이렇게 생겼구나"가 이해됐다.
그냥 복붙해서 돌리는 것과는 완전히 다른 느낌이었다.

25가지 에이전트를 단계적으로 쌓아가는 구성도 좋았다.
앞에서 만든 것이 뒤에서 확장되는 흐름이라, 처음부터 끝까지 맥락이 끊기지 않았다.

책을 읽으며 아쉬웠던 점

첫째, 파이썬 기초가 어느 정도 있어야 따라갈 수 있다.
완전 비전공자나 파이썬을 처음 접하는 사람에게는 진입 장벽이 있을 것 같다.
이 책은 어디까지나 개발자를 대상으로 쓰여진 책이다.

둘째, LangChain과 LangGraph는 버전 업데이트가 빠른 라이브러리다.
책이 v1 기반으로 작성되어 있어서, 예제 코드를 그대로 실행하면 버전 차이로 오류가 날 수 있다.
저자가 유튜브 강의와 Q&A 채널을 함께 제공하고 있으니, 막히는 부분은 그쪽을 활용하는 게 좋을 것 같다.

셋째, AI 에이전트를 프로덕션에 올렸을 때 비용이나 성능 이슈를 어떻게 다루는지 내용이 조금 더 있었으면 했다.
실제로 서비스에 붙이려면 LLM 호출 비용이나 응답 속도도 신경 써야 하는데, 그 부분은 독자 몫으로 남겨진 것 같았다.

누가 읽으면 좋을까

• 개발 경험은 있지만 AI 에이전트는 처음인 사람
• LangChain, LangGraph 예제는 돌려봤는데 왜 그런 구조인지 이해가 안 됐던 사람
• LLM 라우팅, RAG, MCP, A2A 같은 키워드를 들어는 봤지만 개념 정리가 안 된 사람
• 업무 자동화에 AI를 직접 연결해보고 싶은 개발자

반대로 이미 에이전트를 실무에서 운영하고 있거나, 프레임워크 내부 구현까지 파고들고 싶은 사람에게는 다소 기초적으로 느껴질 수 있다.
이 책은 명확히 "입문+실전" 포지셔닝이다.

마무리 하며

개발자라면 새로운 기술이 나왔을 때 일단 써보고, 왜 이렇게 동작하는지 따라가는 과정이 익숙할 것이다.
AI 에이전트도 다를 게 없었다. 막연하게 어렵게 느껴졌던 건 그냥 낯설었기 때문이었다.

AI 에이전트가 아직 낯선 개발자라면, 이 책이 그 낯섦을 걷어내는 데 꽤 도움이 될 것이다.
나처럼 "일단 원리부터 이해하고 싶다"는 사람에게는 특히 잘 맞는 책이었다.

저자가 동영상 강의를 제공하고 있다. 아래 링크를 통해 확인해 볼 수 있다.
https://youtube.com/playlist?list=PLGdAO3WWoeI73hv_jTtKnOx7uqH5htc1a&si=0px9BhLsuwCgcDK5

도서링크: https://www.hanbit.co.kr/store/books/look.php?p_code=B5614034531

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

솔직히 고백하자면 나도 클로드를 유료로 결제해놓고 채팅창에 "질문하고 답변 받기"가 전부였다.

답변은 그럴듯하게 나오는데 정작 그걸 워드에 붙여넣고 형식을 잡는건 늘 내 손을 거쳐야 했다.

이 책은 바로 그 지점에서 출발한다.

제목에 들어간 "코워크(Cowork)"라는 키워드가 핵심이다.

기존의 AI가 대화만 잘하는 조언자였다면, 코워크는 내 컴퓨터 폴더에 직접 들어와서 파일을 만들고 수정하고 정리하는 동료에 가깝다.

폴더를 지정하고 "이 폴더의 엑셀들 분석해서 워드 보고서로 만들어줘" 한마디면 끝이라는 것이다.

업로드, 다운로드를 반복할 필요가 없어진다는 점이 가장 큰 차이다.

책 목차

크게 3부 13장으로 구성되어 있다.

1부) 클로드 - 클로드 기초, 설치, 대화법, 업무/일상 활용법

2부) 코워크 시작 - 코워크 개념, 파일·폴더 6다루기, 워드/PPT/엑셀/PDF 문서 만들기

3부) 코워크 확장 - 외부 서비스 연결(MCP), 웹 검색, 반복 업무 자동화, 스킬, 플러그인

목차를 쭉 훑어보면 알 수 있듯이 앞쪽은 기초, 뒤로 갈수록 확장과 자동화로 넘어가는 흐름이다.

개인적으로는 가치가 뒤쪽 3부에 몰려 있다고 느꼈다.

책 내용 중 흥미로웠던 부분

Chapter 05 / '대화'에서 '작업'으로

5장은 코워크가 기존 웹 채팅과 뭐가 다른지를 다룬다.

여기서 인상 깊었던건 코워크의 샌드박스를 "새 직원에게 특정 서랍 열쇠만 주는 것"에 비유한 부분이었다.

허용된 폴더 안에서만 파일을 보고 수정할 수 있다는 설명인데, 보안과 실용성의 균형이 한번에 이해됐다.

평소 회사 소스코드나 인증서, 민감한 파일을 다루다보니 "내 파일은 어디로 가는가"를 설명한 5.7절을 가장 먼저 펼쳐봤다.

이런 부분을 빼놓지 않고 짚어준다는 점이 마음에 들었다.

Chapter 10 / 반복 업무를 자동화하는 법

이 책의 백미는 10장이라고 생각한다.

회의록에서 액션 아이템을 뽑고, 엑셀 데이터로 분석 보고서를 만들고, 경쟁사 비교표를 정리하는 과정을 하나의 대화 흐름으로 보여준다.

특히 10.10절은 "조사 → 엑셀 정리 → 비교 차트 → 워드 보고서 → 발표용 PPT"까지 한 번에 이어지는 파이프라인을 다룬다.

생각해보면 개발 업무에서도 코딩 자체보다 이런 잡일에 시간을 더 쓰는 경우가 많다.

릴리스 노트 작성, 장애 보고서 정리, 주간 보고 같은 것들 말이다.

Chapter 11 / 스킬 활용하기

스킬과 플러그인의 차이를 설명한 비유가 기억에 남는다.

스킬이 레시피라면, 플러그인은 식재료와 조리도구까지 담은 밀키트라는 것이다.

개발자 입장에서 풀어보면 스킬(SKILL.md)은 재사용 가능한 함수에 코딩 컨벤션 문서를 더한 느낌이고, 플러그인은 그것들을 설정까지 묶어놓은 패키지에 가깝다.

재미있는건 스킬이 동작하는 방식이다.

먼저 메타데이터만 짧게 읽어 관련성을 판단하고, 필요할 때만 본문을 마저 읽는다고 한다.

우리가 흔히 쓰는 lazy loading이나 코드 스플리팅과 똑같은 발상이다.

AI도 결국 컨텍스트라는 한정된 자원을 메모리처럼 아껴쓰는구나 싶었다.

책을 읽으며 좋았던 점

가장 좋았던건 무작정 기능 나열이 아니라 "왜 이걸 써야 하는지"를 먼저 설명해준다는 점이다.

예를 들어 1부에서 프롬프트의 4요소(역할·컨텍스트·지시·출력 형식)를 먼저 다지고 코워크로 넘어가는 구성이 그렇다.

성급하게 기능부터 보고 싶은 사람도 있겠지만, 사실 가장 흔한 실패는 "도구는 아는데 뭘 시켜야 할지 모르는 경우"다.

저자는 이 문제를 피해가지 않는다.

또 하나, 각 장 끝에 실습이 붙어 있어서 따라하기 좋았다.

분량도 부담스럽지 않아서 한 챕터씩 마무리하고 덮을 수 있었다.

책을 읽으며 아쉬웠던 점

첫째, 코워크는 데스크톱 앱이 켜져 있어야만 예약 작업이 돈다.

서버에 올려두고 헤드리스로 돌리거나 CI 파이프라인에 끼우고 싶은 사람에게는 분명한 제약이다.

이런 용도라면 코워크가 아니라 클로드 코드 쪽을 봐야 하는데, 그 영역은 이 책이 다루지 않는다.

둘째, 스킬의 중요성을 그렇게 강조하면서도 정작 커스텀 스킬 작성법(11.4절)은 분량이 짧게 느껴졌다.

업무 유형별 예제 스킬이 조금 더 있었다면 실무 활용도가 한층 높아졌을 것 같다.

셋째, 이건 AI 도서의 숙명이긴 한데 시점 리스크가 있다.

모델이며 요금제며 기능이 워낙 빠르게 바뀌다보니, 출간 시점(2026년 3월) 이후 내용은 다시 찾아봐야 할 것 같다.

누가 읽으면 좋을까

• AI를 결제까지 해놓고 "보고서 써줘" 수준에서 멈춰 있는 사람
• 코워크, MCP, 스킬, 플러그인이 뭔지 들어는 봤지만 손대본 적 없는 사람
• 코딩 외에 문서·보고·자료 정리 업무 비중이 큰 직장인이나 개발자

반대로 이미 클로드 코드나 CLI를 능숙하게 쓰고 있거나, 개발자 수준의 깊은 활용을 기대하는 사람에게는 다소 기초적으로 느껴질 수 있다.

이 책은 명확히 "입문서"다.

마무리 하며

책을 덮고 나니 머릿속에 한 문장이 남았다.

AI를 잘 쓰는 사람과 그렇지 않은 사람의 차이는 능력이 아니라, 실제로 써봤는지의 차이라는 것이다.

사실 나는 새로운 도구를 업무에 들일 때 꽤 보수적인 편이다.

검증되지 않은 기능을 덜컥 끌어다 쓰는걸 경계하기 때문이다.

그런데 코워크는 한번 폴더를 내어주고 일을 시켜보니 생각이 좀 달라졌다.

채팅은 채팅이고 업무는 업무라는 고정관념이 의외로 쉽게 깨졌다.

거창한 자동화까지는 아니더라도, 매주 손으로 하던 반복 작업 하나쯤은 코워크에 맡겨볼 생각이다.

그렇게 조금씩 손을 덜다 보면 나도 퇴근 시간이 조금은 당겨지지 않을까 싶다.

도서링크: https://www.hanbit.co.kr/store/books/look.php?p_code=B9559034431

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

책 소개

해당 책은 제목과 같이 개발함에 있어서 무언가 더 기술적으로 더하는 느낌이 아닌 덜어내는데 집중하는 내용으로 구성되어 있다.

저자는 과거에는 신기술이 나올 때 마다 필요보다는 호기심 때문에 프로그램/프로젝트에 적용했었던 과거를 회상하며 현재는 그 반대의 삶을 살아가려고 노력하는 내용을 담고 있는 것 같았다.

책 목차

PART 01 / 하는 일을 단순화하라, 일하는 방식을 단순화하라.

PART 02 / 환경을 단순화하라.

PART 03 / 상호작용을 단순화하라.

PART 04 / 코드를 단순화하라.

책 목차를 보면 알 수 있듯이 주된 키워드는 "단순화"이다.

무소유라는 말을 들어봤을 것이다. 갖고 싶은 것들을 다 가지고 난 후 남는 건 공허함이다.

결국 필요한 것 하나만 남기고 다 정리하는 것이 미덕이 된다는 말이 있다.

저자는 이론 설명보다는 개발 현장에서 직접 체득한 것들과 습관들에 대해서 바로 실천할 수 있도록 안내하고 있다.

단순화하기 위한 29가지 실천법은 꽤나 공감가는 가는 부분도 있었고 그렇지 못한 것들도 있었다.

그럼 어떤 것들이 내가 공감했고 또 처음 알게 되었던 것들인지 몇 가지 책의 내용을 공유해본다.

CHAPTER 03 프로젝트 최적화 / 지긋지긋한 회의를 줄이기

아래 이미지의 내용을 보면 백프로 공감하게 된다.

회의가 너무 쉽게 지배당한다는 코멘트와 지식이 공유되는 것이 아니라 강요된다는 글을 읽고나서 내가 주최하는 회의에서는 어떤면이 더 클런지 반성하게 되었다.

CHAPTER 04 업무 자동화 / 그 외 모든 것 자동화하기

아래 이미지 내용은 업무 자동화 편에서 저자가 실천해보라고 남겨놓은 메시지다.

과거 유사한 글을 본적이 있었던 것 같은데 실천을 해보지는 못했었다.

글의 요지는 새로운 언어를 공부 또는 개발할 때 코드를 완성한 후 개발/배포 환경을 구축하기보다는 가장 단순한 코드를 가지고 배포 환경을 미리 구축하여 단일명령어 하나로 릴리즈까지 빠르게 한사이클을 끝내보라고 한다.

과거 경험상 이를 미루게 되면 한없이 밀려서 크나큰 고생을 한 경험을 이야기해주고 있었다.

또한 이 내용도 한번쯤 생각해볼 필요가 있다.

내 업무 PC가 갑자기 켜지지 않는다면? 내 개발 환경이 꼬여서 빌드 및 릴리즈를 할 수 없다면? 정말 아찔하다.

사실 그런 상황이 벌어지는 경우는 드물지만 일어나긴 한다.

상시 백업 또는 환경을 이미지화 해놓는 방안등을 고려하지 않았다면 머리가 아파올 것이다.

지금이라도 이런 문제를 방지하기 위해서 내가 할 수 있는 무엇일지 생각해보게 된다.

CHAPTER 05 변화의 수용 / 미래에서 놀고, 과거에서 일하기

이 내용은 항상 새로운 것이 좋은 것은 아니다라는 내용을 말해주고 있다.

누구나 새로운 아이디어가 있다면 다음 기능에 넣고 싶고, 사용하는 프레임워크에 신규 기능이 들어왔다면 사용해보고 적용해보고 싶을 것이다. 하지만 검증되지 않는 이런 기능들을 넣는다는 것은 위험성을 가지고 있다는 것을 인지하라는 내용이다.

사실 기존의 프로젝트에 새로운 것을 추가하거나 유지보수함에 있어 보수적으로 접근하는 편이다.

새로운 기능을 써보는 것도 좋지만 오류 없이 현상 유지를 하는 것도 무엇보다 중요한 부분이라 생각하기 때문이다.

저자의 이 내용은 실로 매우 공감가는 부분임이 틀림없었다.

CHAPTER08 가독성 높은 코드 / TODO를 쓰느냐 마느냐

코드를 유지보수하는 상황을 보면 다른 사람이 작성한 코드를 볼 때 고처야 할 부분이 있는 경우나 TODO를 통해 고쳐야 한다고 나열되어 있는 경우를 본적이 있을 것이다. 저자도 이러한 상황에서 아주 간단한 부분이 아니고서는 TODO를 달아놓고 향후에 처리한다고 한다. 그러는 과정에서 툴들을 활용해 TODO 항목을 놓치지 않는다고 한다.

마무리 하며

위 29가지 실천법들 중에 몇가지 공감가는 부분들을 발췌해서 소개했다.

저자도 이야기 하지만 모든 실천법을 적용할 필요는 없다. 그리고 그럴 수도 없다.

자신의 환경에 맞는 형태로 수정해서 사용하거나 발전시키면 될 일이다.

결국 책을 읽고 난 후 내 머리속에 남는 것은 "Simple is Best"이다. 

난 사실 물질적 욕구에 있어서는 맥시멀리즘을 추구한다.

하지만 개발에 있어서는 미니멀리즘을 추구하려고 노력하겠다.

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

책 소개

먼저 표지 가장 왼쪽 위에 "부트캠프"라는 키워드가 눈에 띄었습니다.

제로베이스에서 취업까지 부트캠프, 즉 실제 부트캠프 교육과정을 한권에 옮겨 놓은듯한 구성을 하고 있는 것 같습니다.

저 같이 프론트엔드/백엔드에 대해서 경험해보지 못한 개발자나 비전공자들에게도 쉽게 첫 걸음을 띌 수 있도록 해주는 것 같았습니다.

책 목차

총 5주차(14강)으로 구성되어 있습니다.

1주차) 스프링, 스프링 부트와의 첫 만남

2주차) 스프링 코어와 프로젝트 시작

3주차) 난생 첫 프로젝트, 상품 조회와 등록 API

4주차) 스프링 프로젝트 고도화

5주차) 살아남는 백엔드 개발자가 되려면

주차별 커리큘럼 특징

1주차

- 백엔드 개발의 본질인 '데이터의 흐름'을 이해합니다. 스프링과 스프링 부트의 차이, HTTP 통신 규약, 그리고 API와 REST의 기본 개념을 비전공자도 이해하기 쉬운 비유로 학습합니다.

2주차

- IntelliJ 설치부터 프로젝트 생성을 다룹니다. 특히 스프링의 핵심인 **DI(의존성 주입)와 IoC(제어의 역전)**를 이론이 아닌 '불편한 코드를 직접 짜본 뒤 개선하는 방식'으로 체득하게 합니다.

3주차

- 본격적으로 MVC 패턴을 적용합니다. 데이터베이스 연결 전 단계로 로컬 저장소를 활용해 상품 등록/조회 기능을 만들며, 포스트맨(Postman)을 통해 직접 만든 API를 테스트하는 실전 감각을 익힙니다.

4주차

- Query String, PathVariable 등을 활용해 API를 더 정교하게 설계합니다. '어떻게 하면 더 백엔드 개발자다운 객체 설계를 할 수 있을지' 고민하며 프로젝트의 완성도를 높이는 리팩터링 과정을 거칩니다.

5주차

- 기술 학습을 넘어 백엔드 개발자의 6가지 핵심 역량(DB 설계, 클린 코드, 성능 최적화, 협업 등)을 정리합니다. 단순한 '코더'가 아닌 '생각하는 개발자'가 되기 위한 면접 대비 및 향후 학습 방향을 제시합니다.

책을 읽으며 좋았던 점

단순히 암기? 이런식이 아니라 "왜?"를 먼저 생각하게 하고 설명해줍니다.

프로그래밍에 있어서는 더더욱 이해가 중요하기 때문에 최대한 이해하기 쉽게 설명해주려고 노력하고 있었습니다.

생각보다 주차별 그리고 챕터 구성이 길지가 않아서 틈틈히 따라하기 좋았습니다.

어떤 책들은 너무 길게 잡혀 있어서 한번에 따라하기가 시간적으로 부족하거나해서 끝까지 완성하지 못하는 경우도 있었는데 이 책은 그런면에서 최대한 마무리를 하고 책을 덮을 수 있도록 구성되어 있어서 좋았습니다.

책을 읽으며 아쉬웠던 점

아무래도 백엔드라는 큰 범주의 내용을 책 한권으로 녹아내기라는 쉽지 않았을 겁니다.

그래서 최대한 핵심만 그리고 최소한 동작할 수 있는 구조로 이야기를 풀어가서 초심자가 아닌 경우라면 크게 도움이 되지는 못할 것 같습니다.

마무리하며

사실 백엔드라는 키워드는 많이 들어봤지만 그 동안 개발하면서 접하지 않았던 도메인이라 생소했지만 책을 따라하다보니 대학시절에 경험했던 기억이 어렴풋이 떠올랐습니다.

그 당시에는 프론트엔드/백엔드 이렇게 나누지도 않았던 것 같고 그런 용어도 없었던 것 같은데 세월이 많이 흐른듯 합니다.

그래도 맛보기를 해봤으니 조금 더 심화 학습으로 넘어가도 될 것 같습니다^^

오래만에 제이펍 도서리뷰 이벤트에 당첨되어 책을 전달 받게 되었다.

오라일리 책 번역본은 주로 한빛미디어 출판사에서 봤었는데 이제는 제이펍에서도 번역을 진행하는 것 같았다.

반가운 소식이다.

먼저 이 책 제목을 보면서 "그린 소프트웨어"라고 되어 있어 무엇을 말하려고 하는지 궁금했다.

챕터 1에 아래와 같이 그린 소프트웨어, 즉 친환경 소프트웨어란 무엇인지 정의하고 있다.

친환경 소프트웨어(green software) 또는 지속 가능한 소프트웨어(sustainable software)는 실행 시 탄소 배출을 최소화하는 소프트웨어 

친환경 소프트웨어는 더 적은 전력, 하드웨어 사용으로 인하여 "탄소 효율성(carbon efficiency)"를 추구한다.

책의 전반적인 내용은 탄소(모든 종류 온실가스를 총칭), 즉 지구 온난화의 주범인 온실가스를 줄이기 위한 노력을 소프트웨어 업계에서 어떻게 실천할 수 있는지 말해주고 있다.

저자도 이야기 하고 있지만 13개의 챕터로 이뤄진 구성을 순차적으로 읽을 필요는 없으며, 관심가는 부분을 먼저 읽어도 무방하다고 이야기 한다.

그렇다면 이 책은 누가 읽으면 좋을까?

• 소프트웨어 개발자 및 엔지니어
  에너지 효율적인 코드 작성에 관심 있는 개발자에게 필독서다.
  특히 대규모 시스템을 다루거나 백엔드, 클라우드 개발 경험이 있는 개발자라면 책의 내용이 실무에 직접 연결된다.
• IT 인프라 및 클라우드 운영자
  데이터 센터 운영, 가상화, 컨테이너 기반 환경에서의 에너지 최적화 기법은 실제 클라우드 비용 절감에도 직결된다.
• 기술 관리자 및 CTO
  ESG(환경·사회·지배구조) 경영이 점점 중요한 이슈로 떠오르면서, 기술 조직도 이에 대한 대응이 요구된다.
  기술 전략 차원에서 그린 소프트웨어를 고민하는 리더에게 통찰을 제공한다.
• 환경에 관심 있는 일반 독자
  기술적 배경이 부족해도 기본 개념부터 친절히 설명해주기 때문에, 기술과 환경의 교차점에 흥미 있는 독자도 무리 없이 읽을 수 있다.

그럼 책의 내용 중 2가지 정도 흥미로운 내용을 발췌했다.

첫번째로 나를 포함한 모든 개발자들은 개발을 진행할 때 "성능" vs "효율성"이라는 키워드를 유념하면서 개발을 할 것이다.

그런데 이번에 책을 읽다보니 거기에 한가지가 더 있는 것이 아닌가? 바로 "친환경"이라는 키워드다.

사진 속 책의 내용을 보면

"느린 코드도 친환경적일 수 있다." 라는 글과 "효율적인지 못하지만 더 친환경적일 수 있다." 라는 글이 와닿았다.

한 때 요리에서도 패스트 푸드가 아닌 슬로우 푸드라는 용어를 들어봤을 것이다.

웰빙이라는 키워드가 흥할 때 슬로우 푸드, 즉 천천히 만들고 먹는다는 것을 넘어서 전통적이고 지역적인 음식 문화를 지키고 건강하고 지속가능한 식생활을 추구한다는 국제적인 운동이라고 한다.

이는 지금의 친환경 소프트웨어와 닮아 있는 것 같다는 생각이 들었다.

두번째로 일론 머스크의 스타링크에 대한 이야기다.

전 지구적으로 지구 저궤도 위성을 통해 인터넷 연결을 제공한다라는 것이 목적이다.

이를 실현시키기 위해 저궤도 위성의 장/단점을 소개하고 있다.

글을 읽어보면 장/단점 양면의 내용이 다 일리 있고 타당하다고 생각한다.

그 선택은 어떠한 상황에 처해 있냐에 달려있을 거란 생각이 든다. 

이렇듯 모든 일에는 선택의 기로에 놓일 때가 있는데 현명한 판단을 내리기 위해 많은 준비를 해야 할 것 같다는 생각을 해본다.

끝으로 

친환경이라는 키워드를 가지고 소프트웨어 개발에 적용시킬 생각을 가져본적이 없던터라 이 책을 읽으면서 다양한 분야에서 다양한 노력을 통하여 그린 소프트웨어를 실천할 수 있음을 조금이나마 알게 된 것 같다.

사소한 것일지라도 조금씩 실천해보려고 한다.

그러다 보면 우리 모두가 동참하여 심각한 기후 변화에 대응하고 있지 않을까 싶다.

"제이펍으로부터 부터 도서를 제공 받아 지극히 주관적인 느낌으로 작성되었습니다."