일러스트 RAG - < 답변 서비스에서 개인 지식 저장소로 >

개요

과제를 제출하고 나서 ChatGPT에게 이렇게 부탁했다.

내가 만들고 싶은 일러스트 RAG 기획을 커스터마이징하여 더 내가 원하는 기능 위주로 리팩토링할꺼야. (SSAFY 가 요구하는 사항들은 전부 배제하고) 이에 대해 기획을 확정하고 싶으니 비슷한 사례나 비즈니스 모델들로 여러 참고 자료들을 검색해주고, 이가 시사하는 바 들을 정리해줄래?

5분 48초 뒤에 돌아온 건 조사 결과가 아니라 완성된 기획서였다. 제품 정의, 사용자층, MVP 범위, 아키텍처, 비즈니스 모델까지. 마지막에는 “개인화된 일러스트 제작 의사결정 어시스턴트”를 1차 제품 방향으로 채택하라고 추천했다.

일단 너 혼자서 임의로 너무 많은 가정과 판단을 내렸고, 이에 대해 대부분 기각할거야.

“기획을 확정하고 싶다”고 한 건 확정하기 위한 조사와 토론을 하자는 뜻이었는데, AI는 확정 자체를 대신 해 버렸다. 이 글은 그걸 되돌린 뒤 무엇을 만들지 다시 정한 기록이다. AI와 기획을 같이 하다가 AI가 너무 앞서 간 적이 있다면 어디서 끊고 무엇을 다시 물었는지 볼 수 있을 거다.

내가 원한 건 답변보다 배운 걸 다시 꺼내 쓰는 것

기각한 다음 내가 원하는 걸 세 줄로 다시 적었다.

1. ChatGPT나 Claude 같은 LLM 서비스를 하네스 엔지니어링된 레포지토리 또는 Skill로 실행하게 한다.
2. 내가 좋아하는 그림을 분석하고, 어느 부분을 배울지 통찰과 고찰로 기록하며 확장하는 나만의 일러스트 지식 저장 창고를 만들고, AI로 쉽게 꺼내 쓴다.
3. 강사님께 받았던 피드백은 먼저 기록해 두면 좋겠다 싶어 RAG에 넣으려 한 것뿐이다.

1번은 처음부터 전제였다. 별도 AI 앱을 새로 만들지 않고, 대화와 이미지 해석은 이미 쓰는 LLM 서비스에 맡기고, 나는 그 뒤에서 검색·저장을 하는 쪽을 만든다.

3번도 중요했다. 과제 버전에서는 강사 피드백이 RAG의 중심이었는데, 이제는 초기 자료다. 이미 피드백을 받은 그림이라 AI 분석을 원문과 대조하기 좋을 뿐, 이 시스템이 강사 피드백 전용인 건 아니다. 새로 발견한 작품이나 외부 레퍼런스도 똑같이 분석해서 넣을 수 있어야 한다.

2번의 “분석”에서 AI에게 바란 게 뭔지도 물어왔다. 내가 이미 발견한 특징을 깊게 분석하는 쪽과, 내가 못 본 특징을 독립적으로 찾아내는 쪽 중에서.

둘 다 기대하지만, 더욱 기대하는 건 내가 발견 못 한 특징을 독립적으로 찾아내어 나한테 설명을 하는거야. 내 시각 자체를 더 넓힐 기회 말이야.

A·B·C 중 B를 고른 건 비 RAG에 지지 않기 위해서다

강사 피드백 한 건을 자동으로 가공한다고 하면, 어디까지 해석하게 할지에 따라 세 갈래가 나온다. “배경 글자의 채도를 낮춰라”라는 피드백을 예로 들면 이렇다.

접근	출력	예시
A. 충실한 재구성	원문 정리, 이미지 분류, 관련 근거 정돈	원래 조언과 해당 이미지 특징 정리
B. 근거 기반 해석	원문과 이미지 관찰을 묶은 조건부 통찰	채도가 강한 인물과 배경 글자가 시각적으로 경쟁할 때 강조를 조절한다
C. 일반 원리 추출	다른 그림에도 쓸 수 있는 기법·원칙	시각적 위계를 조절하는 색채 설계 원칙

A만 하면 원문을 정리한 자료집이고, C는 쓸모가 넓지만 한 장의 그림에서 나온 조언을 보편 규칙으로 바꾸다 왜곡될 수 있다.

사실 C가 조금 더 좋아보이지만, 결국엔 그냥 비 RAG가 더 나을 수 있는 상황이될 수 있으니까 B가 차별점이 될수 있다고 생각해

C 같은 일반 원리는 일반 LLM도 이미 잘 말한다. 과제 버전 마지막 비교에서 RAG 없는 답이 더 풍부했던 것과 같은 걱정이다. 반면 B는 “이 그림에서, 이런 조건일 때”가 붙어 있어서 내 자료가 없으면 나올 수 없는 지식이다.

그래서 저장 규칙도 B 중심으로 잡았다.

• B에는 구체적인 실기 방법뿐 아니라 관찰·진단에 관한 통찰도 들어간다.
• C는 꼭 만들 필요가 없다. 받쳐줄 B가 없거나 반례와 부딪히면 보류한다.
• C를 만들면 어떤 B와 어떤 실제 이미지에서 나왔는지 따라갈 수 있어야 한다.
• B·C 모두 AI가 만든 건 초안(draft)이 기본이고, 내가 채택해야 기본 검색에 들어간다.

개수를 늘리는 게 목표가 아니었다. 기준은 하나였다. 새로운 발견이나 이해를 주거나, 실제 그림 작업에 쓸 가치가 있는가. 이미 널리 알려진 일반론을 다른 문장으로 반복하는 거라면 저장할 이유가 없다.

이미지 없는 통찰은 다시 꺼내도 못 쓴다

“인물 얼굴의 대비를 높여 시선을 유도한다”는 문장만 남아 있으면, 나중에 꺼내 봐도 어떤 그림에서 무엇이 어떻게 달라졌는지는 알 수 없다. 그래서 통찰을 저장할 때 원본 이미지와 그 통찰이 나온 근거를 같이 묶어야 했는데, 생각보다 구분할 게 많았다.

• 같은 Notion 피드백 구간에 있는 이미지라고 그 문장의 직접 근거는 아닐 수 있다.
• 원본 이미지와 첨삭 이미지는 관계는 있지만 같은 자료가 아니다.
• 크롭 이미지는 어느 원본의 어느 영역을 잘랐는지 알아야 한다.
• 내가 당시 남긴 고찰과 AI가 나중에 새로 해석한 내용은 구분해야 한다.

그래서 원문 구간, 이미지, 지식, 근거 관계를 따로 저장하기로 했다. Notion 원문은 추출 당시 스냅샷으로 남긴다. 원본 페이지가 나중에 바뀌어도 그때 무엇을 보고 통찰을 끌어냈는지 확인할 수 있어야 해서다. 지식 문장을 임베딩하는 것보다 그 지식이 어디서 왔고 실제로 무엇을 보고 판단했는지 남기는 쪽에 무게가 실렸다.

질문마다 꺼내는 방식이 달라야 한다

과제 버전은 관련 문서를 찾아 답하는 한 가지 방식뿐이었다. 지식을 B·C로 나누고 나니 질문 목적에 따라 보여줄 게 달라졌다.

질문	먼저 보여줄 것
색을 많이 써도 산만하지 않은 그림의 공통점은?	저장된 일반 원리(C)가 있으면 그 원리, 그리고 근거 작품들
이 표현을 쓴 작품들을 비교해 줘	작품별로 관찰한 차이
예전에 선생님께 어떤 피드백을 받았지?	일반 이론보다 당시 피드백 원문, 첨삭 그림, 내가 남긴 고찰

문장 유사도만으로는 이 목적을 가르기 어렵다. 질문이 노리는 표현 목적, 해결하려는 문제, 관련 기법, 꼭 맞아야 하는 시각 조건을 같이 봐야 한다.

저장소에 답이 없으면, 찾아서 넓힌다

기획을 다시 세운 뒤에는 “좋은 답이 뭔가”부터 정해야 했다. 실제로 내가 할 법한 그림 질문을 하나씩 놓고, 어떤 답이 도움이 되고 어떤 답이 틀렸는지 AI와 토론하며 채점 기준을 만들었다.

첫 질문은 “캐릭터 묘사를 진행했는데, 더 다채로운 색감이나 빛 연출을 어떻게 하면 좋을까?”였다. 내 그림을 첨부해서 묻는 실제 적용형 질문이다. 여기서 바로 걸리는 경우가 있었다. RAG가 관련 강사 피드백이나 참고 이미지를 못 찾았다면 이 답은 몇 점일까?

AI가 내놓은 후보는 두 개였다.

채점 후보	내용	근거
후보 1	답변은 부분 성공. 검색 성공 점수만 낮춘다	첨부한 그림만 보고도 유용한 조언은 할 수 있다
후보 2	근거를 못 찾으면 답변 성공도 크게 제한한다	이 프로젝트의 목적이 피드백과 참고 이미지를 쓰는 것이다

AI는 후보 1을 추천했다. 답만 쓸 만하면 됐다는 쪽이다.

나는 후보 2를 골랐다. 스크린샷 속 대화에서는 두 후보가 A·B로 적혀 있어서 내 답도 “B로”로 시작한다.

B로 진행하되, 이 경우엔 추가 자료 조사를 진행하여 일러스트 중 통찰 후보들을 보여주어, 사용자가 쉽게 새로운 RAG 근거 확장을 진행할 수 있도록 도와줘야함

앞 절에서 지식 B를 고를 때의 걱정과 같은 방향이다. 근거 없이 그림만 보고 좋은 조언을 하는 건 비 RAG도 한다. 그래서 근거를 못 찾으면 답변 성공도 낮게 보고, 대신 저장소 밖에서 작품을 찾아 새 근거 후보로 내밀게 했다.

여기서 GPT에게 레퍼런스를 찾아달라고 했을 때의 불만이 다시 기준이 됐다. 검색 결과의 제목이나 설명이 그럴듯하다고 적합한 레퍼런스는 아니다. AI가 실제 이미지를 열어 질문에 필요한 시각적 특징이 있는지 확인한 다음 후보로 내놓아야 한다. 내가 그중 하나를 고르면 더 깊이 분석하고, 쓸 만한 통찰은 새 지식 초안이 된다.

이렇게 되면 이 RAG는 과거 자료만 반복해서 검색하지 않는다. 새 작품을 탐구하고, 기존 지식과 비교하고, 필요하면 지식을 넓힌다.

소감

기획 확정만하는데도 AI는 엣지케이스(조금 색다른 가정의 경우)들을 수도없이 뱉어내서 주말 하루종~~~~일 토론만 했던게 점심 나가서 먹을 뻔 했다.. 경험해보니 일단 디테일보단 방향성을 잡은 뒤에는 빠르게 구현을 진행하며 보완하는 방식이 더 효율적인 것 같다.