<에이전트 시대의 AI 시스템 설계> AI 실습 문제 생성은 프롬프트만 잘 쓰면 충분할까?

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

제품을 만들 때 AI로 실습 문제를 생성하는 기능을 붙인 적이 있다. 사용자의 직무, 개선하고 싶은 업무, 지금 하고 있는 일을 입력으로 받아서 그 사람의 상황에 맞는 실습 문제를 만들어주는 흐름이었다. 처음에는 프롬프트에 규칙을 잘 적어두면 어느 정도 안정적인 결과가 나올 거라고 생각했다.

그런데 실제로 만들어보니 생각보다 쉽지 않았다. 결과물이 겉으로는 문제 형식을 갖추고 있었지만, 실제 업무 상황처럼 느껴지지 않는 경우가 많았다. 실습 데이터도 부실해서 사용자가 “이걸 내 업무에서 어떻게 쓰지?”라고 느낄 만한 결과가 나왔다. 직무와 상황을 입력으로 넣었는데도, 결과물은 그 맥락을 깊게 반영하지 못했다.

그래서 계속 규칙을 고쳤다. “이런 상황을 더 구체적으로 반영해라”처럼 규칙을 자세히 쓰기도 했고, 반복해서 안 좋은 결과가 나오는 경우에는 “이런 식으로 만들면 안 된다”는 금지 규칙을 추가하기도 했다. 이 과정을 반복하면서 AI 기능은 프롬프트 한 번으로 완성되는 게 아니라, 실패 사례를 보고 규칙과 검증 기준을 계속 보강하는 운영 루프에 가깝다는 생각을 하게 됐다.

이 책 <에이전트 시대의 AI 시스템 설계>는 생성형 AI를 실제 서비스로 운영할 때 마주치는 환각, 비결정적 응답, 지식 공백, 도구 호출 실패, 비용과 지연시간, 안전장치 문제를 32가지 설계 패턴으로 다루는 책이다. 내가 겪었던 “AI가 문제는 만들지만 좋은 실습 문제는 못 만든다”는 문제도 결국 프롬프트 문장력보다 시스템 설계에 가까웠다.

인사이트 1: 좋은 문제를 만들려면 좋은 맥락이 먼저 필요하다

AI에게 직무와 상황을 넣었다고 해서 곧바로 실제 업무 같은 문제가 나오지는 않았다. “프론트엔드 개발자”, “업무 자동화를 개선하고 싶다”, “현재 이런 일을 하고 있다” 같은 정보를 줘도 결과물은 종종 일반적인 예시 문제에 머물렀다. 입력값은 구체적인데 출력은 뭉뚱그려지는 느낌이었다.

이때 아쉬웠던 건 실습 데이터였다. 실제 업무에서 다룰 법한 데이터, 제약 조건, 예외 상황, 의사결정 맥락이 있어야 문제가 살아나는데, AI가 만든 데이터는 너무 얇았다. 테이블이나 예시 값은 있지만 현업에서 마주치는 복잡함이 없었다. 그래서 학습자는 문제를 풀 수는 있어도, 그 문제가 자기 업무와 연결된다는 느낌을 받기 어려웠다.

책을 읽으면서 가장 먼저 연결된 부분도 RAG와 지식 추가였다. 기본 RAG, 의미 기반 색인화, 대규모 색인화, 신뢰할 수 있는 생성 같은 주제를 따로 다루는데, 여기서 좋았던 건 RAG를 단순히 “문서 검색 붙이기”로 설명하지 않는다는 점이었다. 내가 만들던 기능에 대입해보면, 사용자 입력 몇 개를 프롬프트에 넣는 것만으로는 부족하고, 직무별 업무 사례나 좋은 실습 데이터의 기준을 어떻게 공급할지까지 설계해야 한다는 이야기로 읽혔다.

결국 맥락은 “문장으로 설명하는 것”만으로 충분하지 않다. 좋은 실습 문제를 만들려면 사용자의 직무와 상황을 해석할 수 있는 참고 데이터, 예시, 제약 조건이 같이 들어가야 한다. 책을 읽고 나서는 내가 부족하다고 느꼈던 “실습 데이터의 부실함”도 단순 데이터 양의 문제가 아니라, 어떤 지식을 어떻게 가져오고 생성 과정에 연결할지의 문제였다는 생각이 들었다.

인사이트 2: 금지 규칙도 시스템의 일부다

실습 문제 생성에서 규칙을 추가하다 보면 자연스럽게 금지 규칙이 늘어난다. 처음에는 “직무와 레벨을 반영해라”처럼 원하는 방향을 적는다. 그런데 결과를 보다 보면 “이런 식으로 만들면 안 된다”는 조건이 더 중요해지는 순간이 생긴다. 실제 업무 상황 같지 않은 문제, 데이터가 너무 단순한 문제, 정답이 뻔한 문제, 맥락 없이 용어만 바꾼 문제 같은 것들이다.

이런 금지 규칙을 넣으면 당장은 나아진다. 하지만 금지 규칙만 계속 늘어나는 방식은 한계가 있다. 프롬프트가 길어지고, 규칙 사이의 우선순위가 애매해지고, 새로운 실패 유형이 나오면 또 규칙을 추가해야 한다. 결국 “규칙을 얼마나 많이 쓰느냐”보다 “어떤 실패를 막아야 하고, 그 실패를 어떻게 감지할 것인가”가 더 중요한 문제가 된다.

책의 후반부에는 템플릿 생성, 조립 후 재구성, 자체점검, 가드레일 같은 안전장치 패턴이 나온다. 이 부분을 읽으면서 내가 프롬프트에 계속 추가하던 금지 규칙을 조금 다르게 보게 됐다. AI가 부실한 실습 문제를 만들지 않게 하려면 단순히 “잘 만들어줘”라고 하는 게 아니라, 나쁜 결과의 유형을 정의하고 막는 장치가 필요하다.

내가 추가했던 금지 규칙은 일종의 작은 가드레일이었다. 다만 그때는 그것을 시스템 설계라고까지 생각하지 못했다. 책을 읽고 나니 금지 규칙을 프롬프트 안에 계속 쌓아두는 것보다, 템플릿, 자체점검, 평가 기준으로 분리하는 편이 더 운영 가능한 방식이라는 생각이 들었다.

인사이트 3: 퀄리티 컨트롤은 생성 이후에 더 중요해진다

실습 문제 생성에서 가장 어려웠던 건 퀄리티 컨트롤이었다. 문제를 하나 생성하는 것 자체는 어렵지 않았다. 어려운 건 그 문제가 정말 사용자의 직무와 상황에 맞는지, 실습 데이터가 충분한지, 실제 업무 상황처럼 느껴지는지 판단하는 일이었다.

처음에는 결과가 마음에 들지 않으면 프롬프트를 고쳤다. 규칙을 더 구체화하거나 금지 규칙을 추가했다. 하지만 시간이 지날수록 프롬프트를 수정하는 것만으로는 충분하지 않다는 생각이 들었다. 어떤 결과가 좋은 문제인지, 어떤 결과가 나쁜 문제인지 판단하는 기준이 더 중요했다. 기준이 없으면 매번 사람이 감으로 보고 고쳐야 한다.

이 책은 신뢰성 개선 파트에서 심판형 LLM, 성찰, 의존성 주입, 프롬프트 최적화 같은 패턴을 다룬다. 제약 조건 해결 파트에는 성능 저하 테스트도 있다. 이 부분을 읽으면서 이 책이 “생성”만이 아니라 “생성된 결과를 어떻게 믿을 것인가”를 꽤 중요하게 다룬다는 느낌을 받았다.

내 경험에 대입하면, AI가 만든 실습 문제를 다시 평가하는 단계가 필요했다. 예를 들어 “실제 업무 상황이 드러나는가”, “사용자의 입력이 문제에 반영됐는가”, “실습 데이터가 충분한가”, “금지한 유형의 문제가 나오지 않았는가” 같은 기준이다. 이 기준을 사람이 매번 감으로 보는 게 아니라, 시스템 안에 넣을 수 있어야 제품으로 안정화될 수 있다. 책에서 말하는 신뢰성 개선 패턴은 이 지점을 정리하는 데 도움이 됐다.

마무리

책을 다 읽고 나니, 이 책은 단순한 AI 입문서나 프롬프트 작성법 책과는 거리가 있었다. 생성형 AI를 실제 서비스로 운영할 때 생기는 문제를 패턴 단위로 다루는 책에 가깝다. 그래서 처음부터 끝까지 순서대로 읽는 것도 가능하지만, 지금 만들고 있는 AI 기능에서 막히는 지점을 기준으로 필요한 패턴을 찾아 읽는 방식도 잘 맞아 보였다.

내가 AI 실습 문제 생성 기능을 만들면서 겪었던 문제도 결국 같은 방향이었다. 좋은 결과가 나오지 않을 때마다 프롬프트를 고치고 규칙을 추가했지만, 더 근본적으로는 맥락 공급, 금지 규칙, 품질 평가, 검증 루프가 필요했다. 이 책을 읽으면서 그 경험을 RAG, 신뢰성 개선, 가드레일, 성능 저하 테스트 같은 패턴으로 다시 정리할 수 있었다.

AI 기능을 빠르게 만드는 단계에서는 프롬프트와 데모가 중요하다. 하지만 오래 버티는 AI 시스템을 만들려면 그 뒤의 설계가 필요하다. 특히 AI로 무언가를 생성하는 제품을 만들고 있고, “결과는 나오는데 품질이 안정적이지 않다”는 고민을 해본 사람이라면 이 책에서 연결해볼 지점이 많을 것 같다.

#한빛미디어 #나는리뷰어다 #에이전트시대의AI시스템설계 #AI시스템설계 #RAG #가드레일 #AI에이전트