에이전트 시대의 AI 시스템 설계

 

 

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

들어가며

 회의에서 AI 얘기가 나올 때마다, 내가 보탤 수 있는 말은 늘 머리 속을 맴돌기만 할뿐, 구조화된 답변은 입밖으로 잘 나오지 못했다.

 늘, '그건 환각때문에 .. ', '그건 하네스를 사용해서..' 등과 같은 어디선가 들은 이야기뿐이었다. 그 내용은 틀린 말은 아니었다고 생각한다. 하지만 내용을 뒷받침해줄 그 다음이 없었다. 그래서 말하고자 하는 바가 어떤 종류의 문제이고, 어떤 결을 가진 해법이 있고, 그걸 쓰면 무엇을 내주게 되는지, 거기서부터는 생각이 진행되지 못한 채로 입을 다물 수 밖에 없었다.

 

 이상한 일이었다. 나는 업무를 하며 프롬프트를 자주, 아니 매일 사용한다. 컨텍스트 윈도우를 요리조리 채워 넣을 줄도 알고, 안 되면 RAG를 붙이고, 그래도 안 되면 다시 프롬프트를 깎는다. 손은 바쁜데, 머릿속엔 지도가 없었다. 할 줄은 아는데, 분류할 줄은 몰랐다. 내가 지금 풀고 있는 게 지식이 모자란 문제인지, 추론이 얕은 문제인지, 출력 형식이 깨지는 문제인지조차 이름 붙이지 못한 채 손만 움직이고 있었던 것이다.

 

 나는 백엔드 개발자로 일을 하고 있다. 그동안 AI를 다뤄온 방식은 솔직히 '하네스 만지기'에 가까웠다고 생각한다. 하네스 프롬프트가 손에는 익었지만, 요즘 들어 이 손맛만으로는 부족하다는 생각이 들었다. 회사 업무에서 길어 올린 개념들을 도메인 그래프로(일종의 커스텀 온톨로지로) 엮고, 그 위에서 프롬프트를 짜면 훨씬 촘촘한 요청과 개발이 되지 않을까. 그 그림이 자꾸 어른거렸다.

 

 연차가 8년에 접어드니 시야의 무게중심도 옮겨갔다. 단순한 의사결정보다 수치와 여러 트레이드오프를 함께 저울질하는 아키텍처적 판단이 요구되는 자리에 와 있다는 감각. 그리고 이 회사에서 일한다는 건, 회사가 고민하며 나아가려는 방향에서 부딪힐 사고들에 적절한 조치를 취해줄 수 있는 엔지니어가 되어야 한다는 뜻이라고 나는 생각한다. 이제는 AI 솔루션을 직접 갖지 않은 기업이라 해도 이제 AI를 뺀 업무 진행은 어디서도 어렵다고 생각한다. 그러니 사내에서 더 적극적으로 의견을 보태려면, 최소한의 교양은 갖춰야 한다는 생각으로 이 책을 서평을 하기 위한 책으로 선택했다.

 

나느 이 책을 펼치기 전, 나는 스스로에게 세 가지 질문을 던졌다.

• Q1. 하네스 만지기를 넘어, 도메인 그래프를 품은 커스텀 온톨로지 위에서 더 촘촘하게 요청하고 개발하는 법을 여기서 배울 수 있는가?
• Q2. 단순한 의사결정을 넘어, 수치와 트레이드오프로 설계를 저울질하는 아키텍처적 시야를 얻을 수 있는가?
• Q3. 이 무기를 회사가 나아갈 방향에 대응할 '팀의 공용어'이자, 사내에서 의견을 보탤 '교양'으로 옮길 수 있는가?

 

책이 다루는 범위, 일곱 개의 서랍

 저자는 발리아파 락슈마난과 하네스 하프케입니다. 책의 발상은 단순하고 강합니다. GoF가 객체지향에 했던 일을 생성형 AI에 한 번 더 합니다. LLM 애플리케이션을 만들 때 반복해 부딪히는 난제들(환각, 비결정적 응답, 지식 컷오프)에 검증된 해법을 32개의 패턴으로 카탈로그화했습니다.

 

 그런데 제가 책을 덮고 가장 오래 곱씹은 건 개별 패턴이 아니라, 그 32개를 담아둔 일곱 개의 장(章)이었습니다. 이게 사실상 "생성형 AI 시스템에는 어떤 종류의 문제가 존재하는가"에 대한 지도이거든요. 제 백엔드 언어로 번역하면 이렇습니다.

• ① 콘텐츠 스타일 제어 (로짓 마스킹, 문법 제약, 스타일 트랜스퍼…)
  → 출력이 항상 유효한 형식을 지키게 강제하는 일. 응답 스키마와 직렬화 계약의 문제.
  
  
• ② 지식 더하기 (기본 RAG, 시맨틱 인덱싱, 대규모 인덱싱, 인덱스 인지 검색…)
  → 모델 바깥의 지식을 끌어오는 일. 읽기 경로의 캐시·인덱스·검색 전략.
  
  
• ③ 모델 능력 확장 (생각의 사슬 CoT, 생각의 나무 ToT, 어댑터 튜닝…)
  → 한 번의 호출로 안 되는 걸 펼쳐서 푸는 일. 연산을 어떻게 분기·전개할 것인가.
  
  
• ④ 신뢰성 개선 (LLM-as-Judge, 리플렉션, 의존성 주입…)
  → 출력을 한 번 더 검증하는 일. 테스트·회귀 검증 루프.
  
  
• ⑤ 에이전트의 행동 (툴 콜링, 코드 실행, 멀티에이전트 협업)
  → 모델이 바깥 세계를 건드리게 하는 일. 서비스 오케스트레이션과 사이드이펙트 경계.
  
  
• ⑥ 제약 조건 해결 (소형 언어 모델 SLM, 프롬프트 캐싱, 추론 최적화, 열화 테스트, 장기 기억)
  → 비용·지연·용량을 맞추는 일. 그냥 운영(SRE) 그 자체.
  
  
• ⑦ 안전장치 설정 (템플릿 생성, 셀프체크, 가드레일)
  → 나쁜 입출력을 경계에서 막는 일. 입력 검증과 서킷 브레이커.

 새로운 세계가 아니었습니다. 제가 이미 알던 세계에 붙일 일곱 개의 이름표였습니다. 그리고 이 일곱 개를 손에 쥐는 순간, 묘한 일이 벌어집니다. 내 파이프라인을 이 서랍에 하나씩 넣어보면, 어떤 서랍은 꽉 차 있고, 어떤 서랍은 텅 비어 있다는 게 보입니다. 저는 ②(검색)와 ③(추론)에만 손이 가 있었고, ④(검증)와 ⑦(안전장치) 서랍은 사실상 비어 있었더군요. 분류는 그렇게, 내가 무엇을 안 하고 있었는지를 드러냅니다.

각 패턴의 골격도 한결같습니다. 문제 → 검증된 해법 → 코드 예제 → 트레이드오프 논의. 백엔드 하는 사람이라면 낯설지 않은 구조죠. "이 패턴은 이런 상황에서, 이런 비용을 치르고 쓴다"를 외우던 그 감각 그대로입니다.

 

솔직히, 한 칸이 비어 있었다

 정직하게 적겠습니다. 앞서 자꾸 어른거린다고 한 그 그림 (도메인 그래프와 커스텀 온톨로지 위에서 작업하는 법)이야말로 내가 이 책에 걸었던 가장 큰 기대였습니다. 일곱 개의 서랍 중 하나쯤은 '지식을 그래프로 모델링하기' 일 거라고 믿었습니다. (하지만 그 서랍은 없었습니다. 제가 선택한 이유에는 없었지만, 그래도 이 책을 읽을 가치는 충분했습니다.)

 

 가장 가까운 ②번 '지식 더하기' 서랍을 열어보면, 거기 들어 있는 건 검색 인프라(인덱스 설계, 시맨틱 인덱싱, 대규모 인덱싱)였습니다. 내가 기대한 건 도메인 모델(엔티티 간 관계와 제약을 명시한 스키마) 위에서 질의하는 법이었는데, 책이 정성껏 가르치는 건 그 지식을 어떻게 찾아올 것인가였던 셈이다. 둘 다 중요하지만 같은 것은 아니다. 32개 패턴을 다 훑어도 지식그래프·온톨로지 기반 접근(이를테면 '그래프 RAG' 같은)은 카탈로그의 중심이 아니었다.

 

 여기서 책을 탓할 일은 아니라고 본다. 제목은 '온톨로지 설계'가 아니라 '디자인 패턴'이니까. 다만 나처럼 같은 기대를 품고 책을 펴는 사람이라면, 그 한 칸이 비어 있다는 걸 미리 알아두는 편이 낫다.

 

 그리고 또 하나. 일곱 서랍을 다 채운다 해도, 무엇부터 내 파이프라인에 끼울지는 여전히 내 몫이다. 카탈로그는 지도이지 내비게이션이 아니다. 어떤 패턴이 내 상황에 맞는지는 결국 내가 트레이드오프를 저울질해 골라야 한다, 그 저울질을 대신해주진 않는다. 하지만 이건 책의 흠이라기보다, 패턴 책이라는 장르의 숙명에 가깝다.

 

그래서, 처음의 세 가지 질문은 어떻게 되었나

Q1 — 도메인 그래프·온톨로지 위에서 작업하는 법을 배울 수 있는가? → 절반의 yes.

일곱 개의 서랍은 내 즉흥적인 프롬프트 노동에 분류표를 달아줬다. "컨텍스트를 끼워 넣어 봤다"는 ②번 서랍의 기본 RAG가 되고, "답을 한 번 더 검토시켰다"는 ④번 서랍의 리플렉션·LLM-as-Judge가 된다. 손맛을 분류 가능한 구조로 끌어올린다는 의미에서는 분명한 yes다. 하지만 내가 진짜 원했던 것 — 회사 업무에서 길어 올린 도메인 그래프, 커스텀 온톨로지 위에서 질의하는 법 — 은 이 책의 사정거리 밖이었다. 그래서 절반이다. 분류의 틀은 얻었지만, 내가 원하던 그 한 칸은 비어 있었다.

Q2 — 수치와 트레이드오프로 저울질하는 아키텍처적 시야를 얻는가? → 강한 yes.

이게 이 책의 진짜 값어치다. 모든 패턴이 트레이드오프 논의로 끝난다. 정확도를 얻으면 지연이 늘고, 지연을 줄이면 비용이 오르고, 비용을 누르려 SLM을 쓰면 능력이 깎인다. 그런데 트레이드오프보다 한 층 위에 있는 게 바로 그 일곱 개의 서랍이었다. 시야란 결국, 내가 지금 몇 번 서랍의 문제를 풀고 있는지 부를 수 있는 능력이더라. 8년 차쯤 되면 단순 의사결정이 아니라 "이건 ⑥번(제약) 문제니까 ②번(지식)을 더 늘리는 건 헛심"이라고 말할 수 있어야 하는 자리에 선다. 이 책은 그 저울의 눈금과, 저울을 놓을 선반 자체를 손에 쥐여준다.

Q3 — 팀의 '공용어'이자 사내 의견의 '교양'으로 옮길 수 있는가? → yes.

GoF가 위대했던 건 알고리즘이어서가 아니라 이름 때문이었다. "여기 팩토리 쓰자" 한마디면 끝나는 그 압축. 이 책의 일곱 서랍과 32개 패턴 이름도 똑같이 작동한다. 회의에서 "그건 환각 때문에 좀…"이라고 멈추던 내가, 이제는 "그건 ⑦번 가드레일과 ④번 셀프체크로 나눠 봐야 할 문제고, 비용은 이쪽에서 치르게 됩니다"라고 말할 수 있다. 어떤 종류의 문제인지 부를 수 있을 때, 비로소 회의에서 의견이 된다. AI를 뺀 업무가 어디서도 어려워진 지금, 이 분류표는 사내 어떤 자리에서든 의견을 보탤 교양의 최소 단위가 되어준다.

 

이 책이 맞는 분, 안 맞는 분

 맞는 분. 이미 LLM으로 뭔가 굴려봤고, 이제 그 경험을 분류 가능한 설계로 굳히고 싶은 중·고년차 엔지니어에게 맞습니다. 결정을 수치와 트레이드오프로 방어해야 하는 자리에 있는 분에게도 그렇고요. 그리고 — 솔직히 저처럼 — AI 솔루션을 직접 만들지 않는 회사에 있더라도, 사내에서 AI 이야기에 적극적으로 의견을 보태기 위한 교양을 쌓으려는 분에게 권합니다.

 안 맞는 분. 프롬프트 한 줄로 당장의 결과만 빠르게 뽑고 싶은 분에게는 무겁습니다. 도메인 지식을 그래프·온톨로지로 모델링하는 법을 배우러 온 분에게는 결이 다릅니다(그 서랍은 이 책에 없습니다). 코드를 직접 짜지 않고 개념만 훑고 싶은 분에게는 장마다 붙은 코드 예제 비중이 다소 부담일 수 있습니다.

 

마지막으로, 시야란.. 가진 서랍의 개수다

 책을 덮으며 든 생각은, 결국 나는 답이 없어서 헤맸던 게 아니라, 답을 분류할 서랍이 없어서 헤맸다는 것이었다.

회의에서 "환각 때문에 좀…"이라고 멈추던 그날, 내게 없던 건 해법이 아니었다. 내 앞의 문제가 어떤 종류의 문제인지 넣어둘 칸이 없었던 것이다. 지식의 문제인지, 추론의 문제인지, 신뢰성의 문제인지 — 서랍이 없으니 다 같은 덩어리로 보였고, 다 같은 덩어리는 손맛으로밖에 만질 수 없었다.

 

 개발은 취향이라고 나는 종종 말해왔다. 그런데 취향이 발휘되려면 그 전에 분류가 있어야 한다. 무엇과 무엇이 다른 종류의 문제인지 구분할 수 있어야, 비로소 그중에서 고르는 취향이 생긴다. 이 책이 준 가장 큰 선물은 32개의 해법이 아니라, 내 일을 일곱 칸으로 나눠 담을 선반이었다. 그리고 나는 이제 안다 — 8년 차의 시야란 거창한 게 아니라, 결국 내가 몇 개의 서랍을 가졌느냐의 문제라는 걸.

도메인 그래프라는 비어 있는 한 칸은, 아직 다음 책의 몫으로 남겨두기로 했다. 선반은 놓였으니, 빈 칸을 찾아 채우는 일은 이제 내 손에 달렸다.