AI 시대를 위한 지식을 검증하고 보강하는 기술 : 『벡터 데이터베이스』

[전자책] 벡터 데이터베이스 - SQLite, PostgreSQL로 직접 만드는 시맨틱 검색과 RAG
니틴 보르완카르 지음, 정영균 옮김 / 한빛미디어 / 2026년 8월

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

지식이 농담이 된 시대에 벡터 스토어의 미시적 구성을 보다

AI(Artificial Intelligence, 인공지능)에 낯선 개념을 물으면 설명이 쏟아지고, 예제 코드까지 금세 따라온다. 시간을 들여 익힌 지식도 질문 한 번이면 얻을 수 있는 것처럼 느껴지는 시대다. 그런데 설명을 읽고 고개를 끄덕이는 일과, 검색 결과가 어긋났을 때 원인을 짚는 일 사이에는 여전히 거리가 있다. 비슷한 문서를 왜 놓쳤는지 판단하려면 도구 아래의 원리를 알아야 한다.

Spring AI와 Gemini, PostgreSQL의 pgvector 조합으로 RAG 강의를 진행한 뒤에도 검색 계층의 내부가 궁금했다. 『벡터 데이터베이스』는 연결해 사용하던 검색 기능을 거리 계산과 인덱스, 저장과 조회의 단위로 다시 들여다볼 기회가 됐다. SQLite와 PostgreSQL이라는 구체적인 구현을 따라가며 원리를 확인할 수 있다는 점이 특히 좋았다.

RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 관련 자료를 먼저 찾아 근거로 붙여 주고, 대규모 언어 모델(LLM, Large Language Model)이 그 근거를 바탕으로 답하게 하는 방식이다. 사내 문서를 넣어 두고 “우리 규정상 이게 되나요?”라고 묻는 챗봇을 떠올리면 이해가 빠르다. 문서를 검색하기 좋게 나눈 조각을 ‘청크’, 그 조각의 의미를 숫자 목록으로 표현한 것을 ‘임베딩’이라고 한다. 벡터 스토어는 이 임베딩을 담아 두고 질문과 가까운 것을 찾아 주는 계층이다.

이번 독서에서는 ‘가까운 것을 찾는다’는 짧은 설명 안에 어떤 선택들이 숨어 있는지 따라갔다. 비슷함의 기준을 정하고, 후보를 빠르게 찾고, 데이터베이스에서 조건에 맞게 꺼내는 일은 어떻게 연결될까. 검색할 자료를 준비하는 과정까지 함께 보니, 따로 알고 있던 개념들이 하나의 검색 흐름으로 이어졌다.

앞서 말한 도구를 짧게 정리하면 이렇다. Spring AI는 여러 AI 모델과 벡터 저장소를 같은 방식으로 다루게 해 주는 프레임워크, Gemini는 Google의 생성형 AI 모델, PostgreSQL은 널리 쓰이는 오픈소스 관계형 데이터베이스이고, pgvector는 PostgreSQL에 벡터 검색을 더하는 확장이다.

트랜스포머로 딥러닝은 끝났다고요? 임베딩은 이제부터 시작입니다

트랜스포머가 나온 뒤로 딥러닝의 큰 문제는 다 정리된 것처럼 이야기되곤 한다. 하지만 임베딩은 트랜스포머 이후에 처음 생긴 개념이 아니다. 단어와 문서를 벡터로 바꾸던 방법이 먼저 있었고, 트랜스포머는 그 표현을 문맥에 따라 더 정교하게 만드는 쪽으로 이어졌다.

word2vec(word to vector)은 단어를, doc2vec(document to vector)은 문서를 벡터로 바꾸는 초기 방법이다. “왕 - 남자 + 여자 ≈ 여왕”처럼 단어 사이의 의미 관계가 숫자 계산으로 드러나는 게 word2vec의 대표적인 예다. 트랜스포머는 지금의 LLM을 있게 한 신경망 구조로, 문맥 속 단어들 사이의 관계를 반영해 표현을 만들어 낸다.

사람의 말을 컴퓨터가 다루는 자연어 처리(NLP, Natural Language Processing)를 공부하며 봤던 이름들이라 반가웠다. word2vec에서 배웠던 벡터 연산이 지금의 검색 결과를 설명하는 언어로 돌아온 셈이다. 예전에 공부한 내용이 현재의 RAG를 이해하는 바탕이 되고, 자연어 처리와 데이터베이스 지식이 연결되는 대목이 오래 남았다.

임베딩은 비정형 데이터를 숫자 벡터로 옮겨, 의미가 비슷한 것끼리 가까이 놓는 일이다. 벡터는 데이터를 표현한 숫자 목록이고, 차원은 그 목록에 들어 있는 숫자의 개수다. 개별 숫자가 곧 특정 단어나 개념 하나에 대응하는 것은 아니다. 문맥을 얼마나 잘 반영해 이 숫자들을 만드는지가 검색 품질을 좌우한다. 트랜스포머가 임베딩을 없앤 게 아니라 더 쓸 만하게 만든 셈이고, 그래서 임베딩은 지금 시스템에서 오히려 더 중요해졌다.

여기서 한 걸음 더 들어가면 ‘의미가 비슷하다’는 말을 어떻게 계산으로 옮길지가 남는다. 가령 “비밀번호를 잊었어요”라는 질문과 “계정 암호 재설정 방법”이라는 문서는 표현이 달라도 관련될 수 있다. 이런 관계를 찾는 것이 의미 유사도 검색이다. 다만 데이터베이스가 문장을 직접 이해하는 것은 아니다. 임베딩 모델이 만든 표현을 바탕으로 숫자 사이의 가까움을 계산하고, 그것을 의미적 관련성의 단서로 사용하는 것이다.

대표적인 기준이 코사인 유사도와 L2 거리다. 코사인 유사도는 두 벡터가 얼마나 같은 방향을 향하는지 본다. 길이의 영향을 제거하고 각도를 비교하므로, 같은 방향이면 1이고 값이 클수록 방향이 비슷하다. L2 거리(Euclidean distance, 유클리드 거리)는 두 점 사이의 직선거리를 고차원으로 확장한 것이다. 좌표의 차이를 비교하며 값이 작을수록 가깝다.

실제 임베딩이 아닌 간단한 숫자 예로 (1, 0)과 (2, 0)을 보면 차이가 선명하다. 방향은 같아서 코사인 유사도는 1이지만, 두 점 사이의 L2 거리는 1이다. ‘비슷하다’는 기준이 방향인지 위치인지에 따라 계산 결과가 달라지는 셈이다.

비교하는 벡터들의 길이를 모두 1로 맞추는 정규화를 거치면 코사인과 L2의 가까운 순서는 같아지지만, 점수 자체가 같아지는 것은 아니다. 따라서 자연어 검색이라고 무조건 한 척도를 고르기보다, 임베딩 모델이 어떤 척도와 정규화를 전제로 하는지 함께 봐야 한다. 거리 척도에 관한 기술 설명도 이 관계를 정리해 준다.

점수의 방향도 구분해야 한다. 코사인 거리는 흔히 1 - 코사인 유사도로 계산하므로 작을수록 가깝다. 유사도가 0.8이라고 해서 ‘정답일 확률 80%’라는 뜻도 아니다. 의미가 가까운 문서가 사실이 틀리거나 질문의 조건과 맞지 않을 수도 있다. 임베딩을 이해한다는 것은 숫자를 만드는 방법뿐 아니라, 그 숫자를 어떤 기준으로 비교하고 어디까지 믿을지 이해하는 일이었다.

흩뿌려진 노드를 재빨라진 위계로 (HNSW)

코사인이나 L2가 ‘가깝다’의 기준이라면, HNSW(Hierarchical Navigable Small World)는 그 기준에 맞는 후보를 빠르게 찾는 방법이다. 둘은 경쟁하는 기술이 아니라 함께 쓰는 요소다. ‘위계’라는 말이 어렵게 들리면 그래프의 기본부터 떠올리면 된다. 노드는 그래프의 점, 간선은 점 사이의 연결이다. 벡터 검색에서는 각 벡터가 노드가 된다. 차원과 데이터 규모가 커질수록 질문 벡터와 모든 벡터의 거리를 다 계산하는 부담이 커지고, 그래서 비슷한 후보만 빠르게 골라내는 근사 최근접 이웃(ANN, Approximate Nearest Neighbor)을 쓴다. 정확한 최근접 결과의 보장을 완화해 속도를 얻는 절충이다.

인덱스는 검색을 빠르게 하도록 미리 만든 자료 구조다. HNSW는 이 ANN을 구현하는 그래프 기반 인덱스로, 노드를 여러 층의 그래프에 걸쳐 배치한다. 일부 노드는 여러 층에 함께 나타나고, 위층은 성글고 아래층으로 갈수록 촘촘하다. 위층에서 대략 위치를 잡고 아래층으로 내려가며 후보를 좁히는, 성긴 지도에서 점점 확대해 가는 탐색에 가깝다. 여기서 위계는 개념의 상하 분류나 언어의 위계가 아니라, 연결을 성글게·촘촘하게 나눠 둔 탐색 구조일 뿐이다.

이때 품질을 재는 잣대가 ‘재현율’이다. 찾아야 할 관련 결과 중 실제로 찾아낸 비율로, 근사 검색이 정확 검색의 상위 결과를 얼마나 회수하는지로 예를 들 수 있다. 검색이 빠른 대신 메모리 사용량이 늘고 인덱스 구축 시간이 더 걸릴 수 있다는 점도 함께 기억에 남았다. 데이터 분포와 탐색 설정에 따라 속도와 검색 품질이 달라진다.

여러 층을 오가며 후보를 좁히는 구조를 이해하고 나니, HNSW라는 이름이 단순히 켜 두는 인덱스 옵션보다 구체적으로 다가왔다. 얼마나 찾아볼지에 따라 무엇을 얻고 놓치는지 생각하게 된 것이다. 검색 속도와 결과의 품질을 함께 판단할 수 있는 관점을 얻었다는 점에서 특히 흥미로운 부분이었다.

정확성을 높이기 위한 킥 한 스푼 - 메타데이터와 SQL

유사도 계산과 인덱스를 실제 서비스로 가져오려면, 원문과 벡터를 어디에 저장하고 어떤 조건으로 조회할지 결정해야 한다. 이 지점에서 sqlite-vss와 pgvector가 단순한 도구 이름을 넘어 구체적인 구현으로 다가왔다.

SQLite는 파일 기반의 경량 관계형 데이터베이스다. 여기에 sqlite-vss(SQLite Vector Similarity Search) 확장을 붙이면 FAISS(Facebook AI Similarity Search)라는 벡터 유사도 검색 라이브러리의 기능을 활용할 수 있다. pgvector는 PostgreSQL에 벡터 타입과 거리 연산, HNSW 같은 인덱스를 더하는 확장이다. 데이터베이스 본체, 확장, 검색 라이브러리는 서로 다른 역할이며, pgvector가 FAISS 위에서 동작하는 구조는 아니다.

두 구성 모두 별도 벡터 전용 서버를 세우지 않고 기존 데이터와 벡터를 같은 데이터베이스에서 다룰 수 있다. 이때 사용하는 SQL(Structured Query Language, 구조화 질의 언어)은 데이터를 저장하고 조회하는 명령을 표현하는 언어다. 익숙한 데이터베이스에 벡터 타입과 검색 기능이 더해지는 과정을 보니, 벡터 스토어가 실제로 무엇을 저장하고 어떤 연산을 수행하는지 한층 선명해졌다.

실제 쿼리에서도 앞서 본 거리 척도의 차이가 드러난다. pgvector의 <-> 연산자는 L2 거리, <=>는 코사인 거리를 구하며, 두 경우 모두 작은 값부터 정렬하면 가까운 후보가 먼저 나온다. HNSW 인덱스도 사용할 척도에 맞춰 만든다. 수학적인 ‘가까움’의 정의가 조회 명령으로 이어지는 부분이다.

구현을 비교할 때는 반환값도 살펴야 한다. FAISS의 L2 검색은 제곱근을 취하지 않은 제곱 L2 거리를 반환한다. 가까운 순서는 같더라도 점수를 다른 구현과 그대로 비교할 수는 없다.

이제 조회 조건을 더해 볼 차례다. 현재 규정을 물었는데 폐기된 규정이 검색되면 주제는 맞아도 답의 근거로는 부적합하다. 메타데이터는 작성자·날짜·분류처럼 문서에 붙이는 부가 정보다. SQL로 ‘분류가 규정이고 현재 유효한 문서’라는 조건을 함께 표현하면, 벡터의 가까움만으로 판단하던 검색에 업무 맥락을 더할 수 있다.

다만 조건을 더한 뒤에도 결과를 점검해야 한다. pgvector의 근사 인덱스 검색에서는 후보를 탐색한 뒤 필터가 적용되어 필요한 결과 수를 채우지 못할 수도 있다. 거리 척도, 탐색 범위, 필터 조건을 함께 봐야 하는 이유다.

여기에 문서 전체의 단어를 분석하는 전문 검색을 결합하는 방식이 하이브리드 검색이다. 표현이 다른 문서를 찾는 데는 의미 검색이 유용하고, 제품명이나 오류 코드처럼 표기 자체가 중요한 경우에는 키워드 기반 검색이나 정확 일치 조건이 필요하다. 두 검색의 점수 체계가 다를 수 있으므로 결과를 합칠 때도 순위나 점수를 조정해야 한다. 메타데이터 필터는 대상의 조건을 정하고, 하이브리드 검색은 서로 다른 검색 결과를 결합한다는 차이가 있다.

sqlite-vss와 pgvector를 따라가며 좋았던 점은 이런 판단을 저장과 조회의 형태로 확인할 수 있다는 것이었다. 의미가 가까운 후보를 찾는 일과, 답변의 근거로 쓸 수 있는 문서를 고르는 일 사이에 어떤 조건이 필요한지 구체적으로 보였다.

참고로 sqlite-vss 공식 저장소는 활발한 개발이 중단된 상태이며 개발자가 sqlite-vec에 주력한다고 안내한다(2026-09-27 확인). 책의 예제로 구조를 이해하는 일과 새 프로젝트의 도구를 선택하는 일은 구분할 필요가 있다.

에이전틱 시대에는 결국 아키텍처만 남는다

여기까지는 준비된 벡터를 어떻게 비교하고 찾는지 살펴봤다. 그렇다면 검색할 벡터는 어떻게 준비되는가. 거리 척도와 인덱스를 이해한 뒤에는, 그 앞단의 데이터 준비 과정이 검색 품질에 미치는 영향도 더 구체적으로 보였다.

ETL(Extract, Transform, Load)은 데이터를 추출하고, 변환하고, 저장하는 흐름을 말한다. 벡터 검색에서는 PDF(Portable Document Format) 등 문서 파일에서 텍스트를 꺼내고, 불필요한 내용을 정리하고, 청크로 나누고, 출처·날짜 같은 메타데이터를 붙인 뒤, 임베딩을 만들어 저장하는 과정으로 구체화된다.

문서 수집 → 텍스트 추출·정리 → 청킹 → 임베딩 생성 → 원문·메타데이터·벡터 저장

흐름만 보면 단순하지만 결정할 것은 많다. PDF에서 본문이 제대로 추출되지 않으면 뒤에서 검색을 잘해도 쓸 만한 근거가 나오지 않는다. 청크가 너무 짧으면 문맥이 끊기고, 너무 길면 질문과 무관한 내용까지 섞인다. 경계 부분을 겹쳐 나누는 방법도 있지만 중복과 저장량을 함께 고려해야 한다. 임베딩 모델을 바꿀 때 기존 벡터와 새 벡터를 같은 기준으로 비교할 수 있는지도 확인해야 한다. 저장소에 넣기 전에 이미 검색 품질을 좌우하는 선택이 여러 번 일어나는 셈이다.

자료를 넣는 ETL과 질문을 처리하는 검색 흐름도 구분해서 볼 수 있었다. 앞단에서 자료와 인덱스를 준비했다면, 질문이 들어온 뒤에는 문서와 비교 가능한 방식으로 질문을 임베딩하고, 가까운 후보를 찾고, 조건과 순위를 조정해 LLM에 전달한다. 검색 인덱스만 바꿔서 해결할 문제인지, 애초에 문서를 잘못 잘랐는지, 임베딩 표현이 질문과 맞지 않는지 따로 살펴야 한다. 코사인 유사도·HNSW·sqlite-vss·pgvector가 이 흐름 속에서 각자 어느 일을 맡는지 보이기 시작했다.

강의에서 써 온 Spring AI도 문서를 읽고 변환하고 저장하는 구성 요소로 ETL 흐름을 제공한다. 책의 Python 예제와 구현 언어는 달라도 살펴야 할 단계가 이어진다는 점이 반가웠다. 코드 예시를 따라가는 것뿐 아니라, 각 단계가 맡은 역할을 중심으로 읽어도 배울 부분이 많았다.

Python 패키지와 로컬 컴퓨터에서 LLM을 실행하는 Ollama를 중심으로 구현을 따라가는 구성은 내부 흐름을 확인하는 데 도움이 된다. 다만 이를 에이전트 프레임워크나 관리형 모델 서비스에 연결하는 예시가 더 있었다면, 익힌 구조를 다른 환경으로 옮기기에도 좋았겠다. AI 모델과 도구를 연결하는 LangChain, 실행 순서와 상태를 관리하는 LangGraph 같은 선택지와 비교해 보고 싶은 아쉬움이 남았다.

에이전틱(agentic)은 AI가 도구를 골라 여러 단계의 작업을 수행하는 방식을 뜻한다. 에이전트가 검색을 대신 호출해도, 잘못 추출한 문서나 부적절한 거리 척도까지 저절로 해결되지는 않는다. 무엇을 저장하고, 무엇을 비슷하다고 판단하고, 어떤 근거를 답변에 넘길지는 여전히 설계의 몫이다. 그래서 ‘아키텍처만 남는다’는 말은 각 단계의 책임과 데이터 흐름을 이해해야 도구를 바꿔도 판단할 수 있다는 뜻에 가깝다.

RAG 파이프라인을 한 번 구성해 보고, 이제는 검색 결과가 왜 그렇게 나오는지 이해하고 싶은 개발자에게 특히 권하고 싶다. 코사인 유사도와 L2로 비교 기준을 이해하고, HNSW로 탐색 방식을 살핀 뒤, sqlite-vss와 pgvector의 저장·조회 구조와 ETL까지 연결해 읽을 수 있다. 학습 자료나 사내 문서 검색을 만들려는 사람, 검색 원리를 설명해야 하는 강사에게도 유용한 관점이다.

자격증 공부와 학습 자료 정리에도 이런 벡터 검색 기법을 더 잘 활용해 보고 싶어졌다. 자료를 어떻게 나누고, 무엇을 비슷하다고 판단하며, 어떤 조건으로 꺼낼지부터 생각하게 된다는 점이 이번 독서에서 얻은 가장 큰 변화다. 도구가 바뀌어도 이런 질문들은 남는다.

#한빛미디어 #나는리뷰어다 #벡터데이터베이스 #RAG #임베딩 #벡터검색 #시맨틱검색 #pgvector #생성형AI #코사인유사도 #의미유사도검색 #HNSW #postgres #sqlite #faiss

<사용자 입장에서 생각하세요> AI가 대체하는 시대에도 사용자는 대체되지 않는다

[전자책] 사용자 입장에서 생각하세요 - 서비스를 살리는 15명의 까다로운 사용자
정그린 지음 / 한빛미디어 / 2026년 8월

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

익숙함도 사용자 경험의 일부다

최근 유튜브 앱에서 익숙하던 구독 메뉴의 위치가 바뀐 뒤 생각보다 큰 불편을 느꼈다. 기능이 사라진 것도 아니고 사용법이 어려워진 것도 아니지만, 손은 계속 이전 위치를 찾았다. 아주 작은 변화였지만 이미 익숙해진 사용 방식이 얼마나 강하게 남아 있는지 체감할 수 있었다. 책에서 다루는 멘탈 모델과 러닝 커브를 읽으며 이 경험이 자연스럽게 떠올랐다. 사용자는 서비스를 새롭게 배우는 사람이 아니라, 이미 가진 경험과 기대를 바탕으로 다음 행동을 예측하는 사람이라는 점이 인상적으로 다가왔다.

학습자를 사용자처럼 바라본다면

특히 2장의 멘탈 모델과 러닝 커브는 강사로서의 경험과 연결됐다. 교육에서는 학습자가 배우기 위해 어느 정도의 노력과 시간을 들일 것이라고 전제하기 쉽다. 반면 사용자는 서비스를 배우기 위해 찾아오는 사람이 아니라 자신의 목적을 해결하기 위해 찾아온다. 사용법을 익혀야만 목적을 달성할 수 있다면 그 자체가 진입 장벽이 된다.

AI 시대의 학습자는 점점 이런 사용자에 가까워지고 있다고 느낀다. 모든 원리를 충분히 이해한 뒤 활용하기보다 부족한 이해는 AI의 도움으로 보완하면서 우선 필요한 일을 수행한다. 그렇다면 교육에서도 무엇을 가르칠 것인가만큼 어떻게 실제로 활용하게 할 것인가를 고민해야 한다. 학습의 깊이를 포기하자는 의미가 아니라, 배운 내용을 사용할 수 있는 상태까지 연결하는 과정도 교육의 일부로 봐야 한다는 뜻이다.

내가 조작하는가, 나를 조작하는가

사용자 중심이라는 말은 편리함만을 뜻하지 않는다. 서비스를 내가 조작하고 있는지, 오히려 서비스가 나의 선택을 유도하고 있는지도 함께 생각하게 됐다. 다크 패턴, 접근성, 국제화와 현지화 같은 주제를 다루는 이유도 여기에 있다고 보았다. 사용자가 선택권을 잃지 않도록 하고, 신체적 조건이나 언어와 지역의 차이 때문에 배제되지 않도록 하는 것 역시 설계의 책임이다.

이런 고려는 윤리적인 원칙에만 머물지 않는다. 화면을 구성하는 8px 단위의 그리드처럼 눈에 잘 띄지 않는 세부 기준까지 이어진다. 사용 경험은 거창한 기능 하나보다 수많은 작은 결정이 쌓여 만들어진다. 그래서 사용자 중심 설계에는 구색보다는 탐색이 필요하다고 느꼈다. 있어야 할 기능을 형식적으로 갖추는 데 그치지 않고, 사용자가 어디에서 망설이고 무엇을 불편해하며 어떤 흐름을 기대하는지 계속 살펴야 한다. 결국 중요한 것은 기능의 개수가 아니라 실제 사용자가 그것을 어떻게 받아들이고 사용하는지를 끝까지 고려하는 일이다.

실수를 막는 것만큼 중요한 회복

가장 인상 깊었던 부분은 9장의 예방과 회복이었다. 좋은 설계는 사용자의 실수를 막는 데서 끝나지 않고, 실수한 뒤 자연스럽게 돌아올 수 있도록 해야 한다. 오류 메시지의 문장, 취소할 수 있는 선택지, 잘못된 입력 이후의 흐름처럼 사소해 보이는 요소가 서비스에 대한 인상을 크게 좌우한다.

나는 이런 부분이야말로 마이크로디자인의 영역이라고 느꼈다. 개발의 편의가 이용의 편의보다 앞서는 상황은 생각보다 흔하다. 기술적으로 구현하기 쉬운가를 먼저 판단하다 보면 사용자는 그 과정에서 불필요한 학습과 시행착오를 떠안게 된다. 예방뿐 아니라 회복까지 설계한다는 관점은 결국 개발의 기준을 기능에서 사람으로 옮기는 일에 가깝다.

결국 남는 것은 사용자다

AI가 반복적인 작업과 복잡한 처리를 빠르게 수행할수록 사람의 역할이 사라진다고 생각하기 쉽다. 하지만 오히려 기술적 구현의 부담이 줄어든 만큼 무엇을 만들고, 어떤 경험으로 전달할지를 판단하는 책임은 더 커질 수 있다. 성경에는 신의 것은 신에게, 카이사르의 것은 카이사르에게라는 말씀이 있다. 이와 마찬가지로 AI가 잘할 수 있는 부분은 충분히 활용하되 사용자의 맥락과 불편을 살피고 경험의 방향을 결정하는 일은 사람이 계속 고민해야 한다. 정밀한 시스템의 도움을 쉽게 받을 수 있게 된 만큼 사람다운 세심함을 구현할 여지도 커졌다.

마셜 맥루한이 미디어가 곧 메시지라고 말했듯 서비스 역시 하나의 매체라고 생각한다. 무엇을 제공하는지만큼 그것을 어떤 방식으로 경험하게 하는지가 중요하다. 이 책은 UX를 막연한 감각이 아니라 심리학적 원리와 단계, 구조를 통해 이해하고 싶은 사람에게 좋을 것 같다. 개발자와 기획자, 디자이너뿐 아니라 나처럼 사람에게 무언가를 가르치거나 경험의 흐름을 설계하는 사람에게도 생각할 거리가 많다. 대체의 시대에도 사용자는 대체되지 않는다. Artificial Intelligence가 강해질수록 우리가 더 고민해야 할 것은 결국 Attractive Interaction, 사람이 자연스럽게 받아들이고 계속 사용하고 싶어지는 상호작용이 아닐까.

#한빛미디어 #나는리뷰어다 #사용자입장에서생각하세요 #UX디자인 #사용자경험 #사용자중심설계 #UX리뷰 #서비스기획 #프로덕트디자인 #AI시대 #멘탈모델 #다크패턴 #개발자독서

AI는 답을 만들고 리더는 책임을 설계한다

리더의 AI 노트 - 지시하는 기술에서 설계하는 기술로, 리더의 질문이 AX 성과를 결정한다
김지현 지음 / 한빛미디어 / 2026년 6월

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

AI를 쓰는 리더와 AI를 도입하는 조직 사이

AI를 잘 활용하는 것과 조직에 AI를 도입하는 것은 전혀 다른 문제다. 개인은 챗GPT나 퍼플렉시티를 결제하고 바로 사용하면 되지만, 조직에서는 어떤 업무에 적용할지, 누가 결과를 검증할지, 데이터와 보안 문제는 어떻게 다룰지, 그 결과에 대한 책임은 누가 질지를 함께 정해야 한다. 기술보다 사람과 프로세스가 더 큰 제약이 되는 이유다.

『리더의 AI 노트』는 이 간극을 리더의 관점에서 다룬다. 챗GPT, 퍼플렉시티, 젠스파크, 노트북LM, 에이닷 같은 도구의 활용법에서 시작해 시장과 경쟁사 분석, 고객 VOC 정리, 회의와 보고, 의사결정, 그리고 조직의 AX 전략으로 범위를 넓혀간다. AI 기술 자체를 깊게 설명하는 개발서는 아니지만, AI를 조직에 적용해야 하는 리더가 무엇을 경험하고 어떤 질문을 던져야 하는지를 정리한 실무서에 가깝다.

리더가 먼저 AI를 사용해야 하는 이유

책의 가장 분명한 메시지는 리더가 AI를 직접 사용해 봐야 한다는 것이다. 직접 써보지 않은 채 “우리도 AI를 도입하자”고 지시하면 목표는 쉽게 추상적인 구호가 된다. 반대로 AI가 잘하는 일과 못하는 일을 몸으로 겪어본 리더는 업무를 더 구체적으로 나눌 수 있다. 초안 작성과 자료 분류는 AI에 맡기되 사실 확인과 최종 판단은 사람이 담당하고, 반복 업무는 자동화하되 예외 상황의 책임자는 명확히 두는 식이다.

이 지점은 개발자가 새로운 기술을 검토하는 과정과도 닮았다. 문서와 발표 자료만 보고 프레임워크를 결정하는 것보다 작은 파일럿을 직접 만들어보는 편이 훨씬 많은 것을 알려준다. 다만 파일럿의 성공을 곧바로 전사 적용의 성공으로 해석해서는 안 된다. 90점짜리 패스트 팔로워와 100점을 노리는 퍼스트 무버에게 필요한 비용과 위험은 다르다. 먼저 해결할 문제와 성공 기준을 정하고, 작게 검증한 뒤 확장해야 한다.

AI는 유능하지만 책임지지 않는 부하직원이다

AI를 사용하면서 자주 드는 생각은 “굉장히 유능하지만 아무 책임도 지지 않는 부하직원”과 비슷하다는 것이다. 주어진 정보 안에서 그럴듯한 답을 빠르게 만들고, 사용자가 원하는 방향을 눈치껏 맞추며, 때로는 틀린 내용도 망설임 없이 말한다. 심지어 월 구독료는 웬만한 직장인의 식대보다 저렴하다. 문제는 결과가 잘못되었을 때 AI가 책임지지 않는다는 점이다.

그래서 AI 시대의 리더십은 지시하는 기술보다 일을 설계하는 기술에 가까워진다. 어떤 맥락과 자료를 제공할지, 결과를 어떤 기준으로 평가할지, 어느 단계에서 사람이 개입할지 정해야 한다. 책에서 보고서 검증, 경쟁사 분석, 규제 모니터링, 고객 리뷰 분석, 회의 시뮬레이션을 반복해서 다루는 이유도 여기에 있다. AI에게 질문 한 번 잘하는 요령보다, 입력과 검증과 판단이 연결된 업무 흐름을 만드는 일이 더 중요하다.

검색 역시 마찬가지다. AI가 검색 경험을 바꿀 수는 있지만 출처 확인까지 대신해 주지는 않는다. 퍼플렉시티나 젠스파크로 조사 시간을 줄이더라도 원문과 작성 시점, 데이터의 기준은 다시 확인해야 한다. 특히 규제, 시장 수치, 경쟁사 동향처럼 의사결정에 직접 영향을 주는 정보일수록 “답이 자연스러운가”보다 “근거를 추적할 수 있는가”가 중요하다.

초안을 압축해 더 많은 타석에 오르기

책에서 소개하는 활용 사례 중 가장 현실적으로 와닿은 부분은 AI가 초안의 비용을 줄여준다는 점이다. 많은 업무가 첫 문장, 첫 보고서, 첫 분석안을 만드는 과정에서 가장 많은 시간을 사용한다. 완성도에 대한 부담 때문에 시작하지 못하거나, 첫 결과물에 지나치게 매달리다 다음 시도까지 가지 못하기도 한다.

AI는 이 구간을 빠르게 통과하게 한다. 회의록에서 쟁점을 추출하고, 보고서의 뼈대를 만들며, 여러 시나리오를 비교하고, 발표 전에 예상 질문을 만들어볼 수 있다. 야구에 비유하면 출루율을 직접 높여준다기보다 더 많은 타석에 설 수 있게 해주는 도구다. 물론 판단 기준과 기본 역량이 부족하다면 타석이 늘어도 결과는 크게 달라지지 않는다. 결국 초안을 빠르게 얻은 뒤 무엇을 버리고 무엇을 발전시킬지는 여전히 사용자의 몫이다.

개발에서도 비슷하다. AI가 보일러플레이트와 테스트 초안, 리팩터링 후보를 빠르게 만들 수는 있지만 좋은 설계와 나쁜 설계를 구분해 주는 것은 아니다. 구조가 잘 잡힌 프로젝트에서는 생산성을 크게 높이지만, 책임과 경계가 흐린 코드베이스에서는 그 혼란까지 빠르게 복제한다. AI가 개발자를 대체한다는 표현보다 개발자가 더 자주 구현하고 검증하게 만든다는 설명이 현재로서는 더 정확해 보인다.

서비스로서의 AI와 조직의 AX

개발자의 시선으로 보면 AI 활용은 대략 세 층으로 나뉜다. 챗봇이나 에이전트 같은 AI 서비스를 사용하는 단계, API와 모델을 제품에 연결해 AI 활용 서비스를 만드는 단계, 그리고 모델과 데이터와 평가 체계를 직접 운영하는 단계다. 대부분의 사용자와 경영진은 당분간 첫 번째 단계에 머물 가능성이 크다. 이 책 역시 우선 리더가 이미 존재하는 도구를 제대로 사용하는 데 많은 분량을 할애한다.

그렇다고 책의 범위가 개인 생산성에서 끝나지는 않는다. 후반부는 AX의 목표, 적용 대상, 전략의 축, 보안과 생산성의 균형, 과의존을 막기 위한 규칙으로 확장된다. 여기서 흥미로운 역설이 생긴다. AI로 업무를 대체하거나 자동화할 기술적 수단은 점점 많아지지만, 실제 도입 속도를 결정하는 것은 엔지니어가 아니라 의사결정자와 사용자일 수 있다. 현업이 문제를 정의하지 못하거나 리더가 책임의 경계를 정하지 않으면 기술은 있어도 시스템은 만들어지지 않는다.

결국 AX는 도구를 배포하는 프로젝트가 아니라 조직의 업무 방식을 다시 설계하는 일이다. 전 직원에게 계정을 나눠주거나 AI 사용 횟수를 KPI로 잡는 것만으로는 부족하다. 어떤 업무에서 시간을 줄였는지, 의사결정의 품질이 좋아졌는지, 검증 비용과 새로운 위험은 얼마나 생겼는지를 함께 봐야 한다. AI 활용을 장려하면서도 출처 확인, 기밀 정보, 최종 승인과 같은 규칙을 정해야 하는 이유다.

기술에 익숙한 독자에게 보이는 거리감

기술적으로 AI를 일찍 사용해 온 독자라면 도구 소개와 활용 예시는 다소 익숙하게 느껴질 수 있다. 챗GPT의 프로젝트와 메모리, GPTs와 Gems, 노트북LM을 이용한 자료 정리처럼 이미 일상적으로 사용하는 기능도 많다. 모델, API, RAG, 에이전트 오케스트레이션이나 평가 체계를 깊게 알고 싶은 개발자에게는 기술적 설명이 부족할 수 있다.

하지만 이 거리감이 오히려 책을 읽은 이유가 되었다. 기술을 만드는 사람은 기능과 구조의 관점으로 AI를 바라보기 쉽지만, 실제 조직의 리더와 비개발 직군은 AI를 어떻게 이해하고 어떤 기대를 갖는지 확인할 필요가 있다. 우리가 상대해야 할 의사결정자와 고객이 어디까지 와 있는지를 아는 것 역시 제품과 시스템을 설계하는 데 중요한 정보다.

아쉬운 점은 여러 도구의 현재 기능에 기대는 부분이 많아 변화가 빠른 AI 시장에서는 일부 설명의 유효기간이 짧을 수 있다는 것이다. 또한 AI가 조직에 주는 효과를 이야기할 때 성공 사례뿐 아니라 실패한 파일럿, 도입 이후 늘어난 검증 비용, 책임 소재가 모호해진 사례까지 조금 더 구체적으로 다뤘다면 AX의 현실이 더욱 입체적으로 보였을 것 같다.

리더의 질문이 시스템의 품질을 결정한다

『리더의 AI 노트』를 읽고 남은 핵심은 리더가 AI보다 더 좋은 답을 내야 한다는 것이 아니다. 리더는 풀어야 할 문제와 판단 기준을 정하고, AI와 사람에게 역할을 나누며, 결과에 책임질 수 있어야 한다. AI가 누구에게나 그럴듯한 답을 제공할수록 질문의 방향과 검증 구조를 설계하는 능력은 더 중요해진다.

AI는 사용자가 원하는 역할을 꽤 충실하게 수행한다. 생각을 넓히는 동료가 될 수도 있고, 보고서 초안을 만드는 직원이 될 수도 있으며, 이미 내린 결정을 정당화해 주는 아첨꾼이 될 수도 있다. 무엇이 되는지는 도구보다 그것을 배치한 사람의 목적과 태도에 달려 있다.

이 책은 AI를 처음 접하는 리더에게는 바로 시도해 볼 수 있는 활용 안내서이고, AI에 익숙한 개발자에게는 조직의 다른 구성원들이 AI를 어떤 언어로 받아들이는지 살펴보는 참고서다. 개인의 생산성 도구를 넘어 조직의 AX로 가려면 무엇을 더 설계해야 하는지 생각하게 만든다는 점에서 의미가 있었다. 결국 AI 도입의 출발점은 최신 모델이나 거대한 예산이 아니라, 리더가 직접 사용해 보고 책임질 수 있는 질문을 만드는 일이다.

#리더의AI노트 #김지현 #한빛미디어 #개발도서리뷰 #AI도서추천 #AI리더십 #생성형AI #AI활용 #AX전략 #디지털전환 #업무자동화 #AI에이전트 #챗GPT #퍼플렉시티 #노트북LM #조직혁신 #리더십도서 #AI업무활용 #AI시대리더십 #AI도입전략

낯선 흐름에 압도될까 싶을 때는 익숙한 것으로 새것을 배우는 것도 방법이다

이것이 멀티 에이전트다 - 싱글 에이전트부터 멀티 에이전트까지, MCP와 A2A로 구현하는 에이전트 시스템 개발 | Cursor 최신 버전 반영, 9가지 실습 프로젝트 수록
서지영 지음 / 한빛미디어 / 2026년 6월

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

『이것이 멀티 에이전트다』를 읽고 실습하면서 가장 크게 든 생각은 “익숙한 것으로 새것을 배운다”는 감각이었다. 책은 LLM에서 출발해 RAG, 에이전트, 멀티 에이전트로 사고를 확장하게 만든다. 단순히 프롬프트를 잘 쓰는 수준을 넘어, 검색과 평가, 도구 호출, 상태 전달, 에이전트 간 협업, 오케스트레이션까지 하나의 시스템으로 바라보게 한다는 점이 인상적이었다.

최근에는 CLI 기반 AI 도구를 사용하면서 hooks, sub agents, 자동화된 명령 실행 같은 기능적 접근에 관심이 많이 쏠려 있었다. 그런데 이 책을 보면서 그보다 한 단계 아래에 있는 구조를 다시 보게 되었다. MCP, A2A, RAG, Vector DB, AgentContext, 오케스트레이터 같은 요소들은 “에이전트가 똑똑하게 처리한다”는 막연한 설명을 구체적인 시스템 설계의 언어로 바꿔준다. 누가 상태를 들고 있고, 누가 검색을 담당하며, 누가 평가하고, 누가 최종 응답을 만들고, 이 전체 흐름을 누가 조율하는지 생각하게 된 것이다.

특히 오케스트레이터 개념이 마음에 들었다. 멀티 에이전트라고 하면 여러 에이전트가 각자 알아서 대화하며 문제를 해결하는 장면을 떠올리기 쉽지만, 실제 서비스를 만든다고 생각하면 자유도보다 제어 가능성이 중요하다. 검색 에이전트, 평가 에이전트, 답변 생성 에이전트, 보고서 생성 에이전트처럼 역할을 나누고, 그 사이의 흐름을 조율하는 구조가 있어야 한다. 책의 실습들은 이런 역할 분리와 워크플로우 설계를 반복적으로 보여준다. 약관 기반 질의응답, 음성 Q&A, 병렬 검색, 반복 평가, 뉴스 기반 종목 영향 평가, 이상 거래 탐지, 여행 플래너까지 사례는 다양하지만 결국 핵심은 비슷하다. 하나의 거대한 프롬프트가 아니라, 책임이 분리된 작은 단위들이 연결되어 하나의 시스템을 이룬다는 점이다.

이 흐름을 따라가다 보니 실제 서비스 아키텍처에 대한 생각도 자연스럽게 이어졌다. 멀티 에이전트 시스템을 로컬 실습이나 데모 수준으로만 볼 것이 아니라, MSA나 컨테이너 기반 구조와 연결해 보면 더 깔끔한 접근이 가능할 것 같다. 각 에이전트를 독립된 서비스처럼 두고, MCP나 A2A를 통해 도구 호출과 에이전트 간 통신을 구성한다면 유지보수성과 확장성도 좋아질 수 있다. 물론 구현하다 보면 시행착오도 생기겠지만, 서비스로 만들려면 결국 이런 구조적 사고가 필요하다고 느꼈다.

실습 자체는 주제를 따라가기 좋게 구성되어 있었다. 영업 데이터 분석과 시각화, 개인정보 탐지와 마스킹, 약관 기반 질의응답, Whisper 기반 음성 Q&A, 병렬 검색, 반복 평가, 뉴스 기반 종목 영향 평가, 이상 거래 탐지, 여행 플래너로 이어지는 예제들은 에이전트를 단순한 답변 생성기가 아니라 작업 수행 단위로 바라보게 한다. 뒤로 갈수록 검색, 평가, 개선, 보고서 생성, 알림 같은 책임이 세분화되는데, 이 흐름을 따라가다 보면 “멀티 에이전트”가 단순히 에이전트 수를 늘리는 일이 아니라 워크플로우를 설계하는 일이라는 점이 분명해진다.

다만 실습을 따라가면서 아쉬운 점도 있었다. 전체적으로 OpenAI 의존성이 강하다는 느낌을 받았다. 물론 입문자나 실습 안정성을 고려하면 가장 무난한 선택일 수 있다. 하지만 요즘은 Groq, NIM, Gemini, Gemma 같은 대안도 있고, 로컬 모델이나 오픈 모델을 섞어 쓰는 경우도 많다. 벡터 DB 역시 전용 벡터 데이터베이스뿐 아니라 PostgreSQL 기반 pgvector 같은 선택지도 충분히 현실적이다. 책이 모든 조합을 다룰 수는 없겠지만, 모델과 인프라 선택지를 조금 더 열어두었다면 실무 확장성을 고민하는 독자 입장에서는 더 좋았을 것 같다.

또 하나의 아쉬움은 구현 스택을 내 방식으로 조금 더 모던하게 가져가 보고 싶다는 점이었다. 예를 들어 패키지 관리는 uv로 정리하고, 시각화는 Plotly 기반으로 더 인터랙티브하게 구성해보고 싶다. 에이전트 워크플로우도 LangChain이나 LangGraph로 다시 구현해보면 책에서 배운 구조를 다른 방식으로 검증할 수 있을 것 같다. 특히 LangGraph의 상태 기반 그래프 구조는 오케스트레이터, 반복 평가, 조건 분기, 에이전트 간 상태 전달을 표현하기에 잘 맞아 보인다. Spring AI로도 같은 접근을 시도해보면 Java/Spring 기반의 엔터프라이즈 서비스 안에서 RAG와 멀티 에이전트 구조를 어떻게 녹일 수 있을지 확인할 수 있을 것이다.

소스 코드 제공 방식에 대해서도 약간의 생각이 남았다. 압축 소스 파일에 거의 모든 파일이 포함되어 있는 방식은 따라 하기에는 편하지만, 한편으로는 독자가 구조를 직접 만들어가며 이해할 여지를 줄이기도 한다. 처음에는 내 방식대로 변환하면서 실습을 진행했지만, 뒤로 갈수록 귀찮아져서 제공된 구조에 맞춰 따라가게 되었다. 그래도 이 과정 자체가 나름의 코드 에이전트 활용 연습처럼 느껴졌다. 주어진 코드를 해석하고, 내 환경에 맞게 바꾸고, 일부는 내가 선호하는 방식으로 정리해 보는 과정이 책의 본문만큼이나 학습이 되었다.

결국 이 책에서 얻은 가장 큰 수확은 특정 라이브러리 사용법보다 사고의 확장이었다. LLM을 호출하는 코드에서 출발해, RAG로 지식을 연결하고, 에이전트로 작업을 위임하고, 멀티 에이전트와 오케스트레이터로 시스템을 설계하는 방향으로 생각이 넓어졌다. 이전에는 AI 도구의 편의 기능이나 CLI 자동화에 매몰되어 있었다면, 이제는 그 아래에 있는 구조와 프로토콜, 데이터 흐름을 함께 보게 되었다.

『이것이 멀티 에이전트다』는 멀티 에이전트를 마법처럼 포장하기보다는, 여러 실습을 통해 하나씩 분해해 보여주는 책이다. 익숙한 개념들에서 출발하지만, 읽고 나면 그것들을 내 방식으로 다시 조합해보고 싶어진다. 그래서 이 책은 “새로운 것을 알려준 책”이라기보다, 이미 알고 있던 것들과 막연히 흩어져 있던 관심사를 하나의 구조로 다시 보게 만든 책에 가깝다. 그리고 그 점이 가장 좋았다.

#멀티에이전트 #AI에이전트 #생성형AI #LLM #RAG #MCP #A2A #벡터DB #임베딩 #오케스트레이터 #LangChain #LangGraph #SpringAI #OpenAI #ClaudeAI #Gemini #pgvector #파이썬 #개발자 #한빛미디어 #이것이멀티에이전트다

구현 중심 개발에서 구조 중심 개발로 : 클린 아키텍처 with 파이썬

클린 아키텍처 with 파이썬 : 유지보수 쉽고, 테스트 가능하며, 확장 가능한 구조로 전환하는 실전 설계 전략
샘 킨 지음, 송영숙 옮김 / 한빛아카데미(교재) / 2026년 4월

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

AI 시대에도 여전히 중요한 아키텍처

개발에서 생산성과 견고하면서도 유연한 체계는 언제나 trade-off의 대상이다. 빠르게 기능을 만들려면 구조적 엄격함을 어느 정도 포기하게 되고, 장기적으로 변경에 강한 시스템을 만들려면 초기 설계와 추상화에 더 많은 비용을 들여야 한다.

AI가 개발 과정에 들어왔다고 해서 이 문제가 크게 달라진 것 같지는 않다. 오히려 AI는 기존 구조의 장점과 단점을 더 빠르게 증폭한다.

구조가 잘 잡힌 프로젝트에서는 생산성을 높이지만, 책임과 경계가 흐린 코드베이스에서는 혼란 역시 빠르게 키운다. 그래서 AI 시대일수록 아키텍처 공부는 선택적 교양이 아니라, 개발자가 속도와 복잡도 사이의 균형을 잡기 위해 갖춰야 할 기본 감각에 가깝다.

현업의 현실과 클린 아키텍처의 위치

현업에서는 사실 레이어드 아키텍처와 MVC 패턴 정도만으로도 상당수의 애플리케이션을 충분히 만들 수 있다. Controller, Service, Repository로 나뉜 익숙한 구조는 여전히 실용적이고, 스프링 같은 프레임워크는 깊은 설계 철학을 완전히 이해하지 못해도 어떻게든 동작하는 애플리케이션을 만들 수 있게 해준다.

그래서 클린 아키텍처, 헥사고날 아키텍처, DDD, TDD 같은 개념은 때로는 배부른 소리처럼 들리기도 한다. 당장 기능을 만들어야 하는 상황에서는 “이 정도까지 해야 하나?”라는 의문이 자연스럽게 생긴다.

하지만 『클린 아키텍처 with 파이썬』은 클린 아키텍처를 절대적 정답으로 제시하지 않는다. 이 책에서의 클린 아키텍처는 “깨끗한 구조만이 옳다”는 선언이 아니라, 객체지향 설계와 테스트, 도메인 중심 사고를 더 일관되게 받아들이기 위한 체계에 가깝다.

SOLID를 통해 다시 보는 설계 원칙

책은 먼저 객체지향 설계의 대표 원칙인 SOLID에서 출발한다. 처음에는 단일 책임 원칙, 개방-폐쇄 원칙, 리스코프 치환 원칙, 인터페이스 분리 원칙, 의존성 역전 원칙 같은 개념이 다소 고루하게 느껴질 수 있다.

그러나 책은 이 원칙들을 암기용 구호가 아니라, 구현에만 급급했던 코드가 왜 시간이 지날수록 변경하기 어려워지는지를 설명하는 도구로 사용한다. 특히 단일 책임 원칙은 “클래스 하나는 일 하나만 해야 한다”가 아니라 “변경 이유가 하나여야 한다”는 기준으로 읽힌다.

의존성 역전 원칙은 고수준 정책이 저수준 구현에 끌려가지 않게 만드는 핵심 원리로 이어진다. 이 지점에서 Service 클래스 안에 비즈니스 로직, DB 접근, 외부 API 호출, 예외 처리, DTO 변환이 뒤섞인 코드가 왜 테스트와 확장을 방해하는지 명확해진다.

양파 아키텍처와 의존성의 방향

중반부터 양파 아키텍처 설명은 이 책에서 가장 인상적인 부분이었다. 양파 아키텍처는 시스템을 여러 겹의 원으로 바라보며, 가장 안쪽에는 핵심 비즈니스 규칙과 도메인 모델을 둔다. 그 바깥에는 유스케이스와 애플리케이션 서비스가 위치하고, 더 바깥에는 데이터베이스, 웹 프레임워크, 외부 API, UI 같은 기술적 세부사항이 위치한다.

핵심은 의존성의 방향이다. 바깥쪽 계층은 안쪽 계층을 알 수 있지만, 안쪽 계층은 바깥쪽 계층을 몰라야 한다. 즉, 데이터베이스나 프레임워크가 바뀌더라도 핵심 비즈니스 규칙은 흔들리지 않아야 한다. 이 원칙은 계층 분리가 단순히 코드를 예쁘게 나누는 일이 아니라, 변경 가능성이 높은 세부사항을 핵심 정책으로부터 분리하는 실무적 장치라는 점을 설득력 있게 보여준다.

파이썬을 넘어 다른 기술 스택으로 확장되는 사고

제목은 『클린 아키텍처 with 파이썬』이지만, 읽고 나면 “파이썬은 거들뿐”이라는 생각이 든다. 파이썬의 타입 힌트, 프로토콜, 테스트 도구, 의존성 주입 방식에 대한 설명도 유익하지만, 이 책의 더 큰 가치는 특정 언어 문법보다 아키텍처적 사고방식에 있다.

같은 구조는 스프링 프로젝트에서도 적용할 수 있다. Controller를 어댑터로, Use Case를 애플리케이션 계층으로, Entity와 Value Object를 도메인 계층으로 분리하는 방식이다. 노드 기반 프로젝트에서도 Express나 NestJS의 라우터와 컨트롤러는 바깥쪽 어댑터로 두고, 핵심 비즈니스 규칙은 프레임워크 바깥에 독립적으로 둘 수 있다. 결국 이 책은 클린 아키텍처를 그대로 따르라고 말하는 책이 아니라, 구현 중심의 사고에서 구조 중심의 사고로 넘어가게 만드는 책이다.

AI와 프레임워크가 생산성을 높여주는 시대일수록 개발자가 직접 이해하고 통제해야 할 것은 더 선명해진다. 중요한 것은 유행하는 구조를 외우는 것이 아니다. 각 계층의 책임을 명확히 하고, 변경 가능성이 높은 세부사항을 핵심 정책으로부터 분리하며, 비즈니스 규칙을 기술 선택보다 오래 살아남게 만드는 것이다.

#클린아키텍처 #소프트웨어아키텍처 #객체지향설계 #SOLID #의존성역전 #양파아키텍처 #헥사고날아키텍처 #도메인주도설계 #테스트주도개발 #레이어드아키텍처 #MVC패턴 #파이썬개발 #백엔드개발 #AI시대개발 #소프트웨어설계