[AX 시리즈 100편 기념 특집] 제가 쓰는 하네스와 RAG, 활용사례를 공개합니다 — AX PM 컨설턴트의 실록·3층 RAG 운영 실측

AX 시리즈 100편 기념 특집 1편 · 하네스 × RAG

강의가 끝나면 가장 많이 받는 질문은 도구 이름이 아닙니다. “강사님이 쓰시는 그 체계를 저도 만들 수 있을까요”입니다. 그래서 AX 시리즈 100편째인 이번 글은 설명 대신 화면을 엽니다. 제가 강의와 컨설팅에 실제로 쓰는 하네스(실록)와 3층 RAG의 운영 대시보드 다섯 장, 구조 도식 두 장입니다. 세 갈래 활용 사례와, 그 숫자들이 각각 무엇을 세는지까지 함께 싣습니다.

Why this post“나만의 RAG와 하네스” — 강의장에서 가장 많이 나온 요청

먼저 이 글을 쓰게 만든 문장부터 보여드리겠습니다. 제가 지어낸 말이 아니라, 워크숍이 끝난 뒤 수강생들이 무기명으로 남긴 후기 원문입니다.

어느 전자·가전 대기업의 사내 세미나였습니다. 종료 후 설문의 “가장 큰 인사이트” 항목 1위가 ‘나만의 RAG/하네스 구축 필요성’(11건)이었습니다. 같은 순위에 오른 다른 하나는 ‘타사 사례로 시야가 넓어졌다’였는데, 전자가 훨씬 구체적이었습니다.

“강사님의 15년 경력과 경험을 통해서 만든 RAG 와 하네스를 저도 만들 수 있으면 좋겠다”

“나만의 rag가 필요하다”

“RAG와 harness를 잘 구성을 해야겠다. 옵시디안으로 세컨 브레인을…”

같은 설문의 개선 요청 1위(11건·19%)는 “간단한 수준의 하네스 도구를 직접 만들어보는 실습”이었습니다. 보는 것으로는 부족하고 손으로 만들어보고 싶다는 뜻입니다.

개인의 학습 의지만 있었던 것은 아닙니다. 사내 데이터를 대규모 언어 모델(LLM)에 연결하는 조직 차원의 배관이 없다는 호소도 나왔습니다.

“조직 차원에서 Jira/Confluence의 데이터가 RAG/LLM으로 연결되어 있지 않습니다”

다른 현장, 어느 IT 서비스 기업의 2일 워크숍 회고에서는 후속 학습 요청 1위가 ‘하네스 + RAG 도메인 최적화’였습니다. 그 회고의 첫 줄은 이렇게 정리돼 있습니다.

“참여자들은 2일 만에 ‘AI 이용자(채팅 소비)’에서 ‘AI 활용자(에이전트·RAG·하네스를 만들고 강화하는 실무자)’로 정체성이 이동했다”

Layer 1 · Harness실록(Sillok) — 규칙이 경로를 지키는 하네스

실록은 제가 운영하는 하네스의 이름입니다. 조선왕조실록에서 따왔습니다 — 기록이 쌓여 다음 판단의 근거가 되는 구조라는 뜻에서입니다. 기능을 한 줄로 줄이면 이렇습니다.

핵심은 경로 기반 자동 적용입니다. 강의 자료 폴더를 건드리면 반복 차수 규칙이 로드되고, 고객사 폴더를 건드리면 반출 등급 규칙이 로드됩니다. 제가 “이번엔 그 규칙 적용해줘”라고 말할 필요가 없습니다 — 말해야 한다면 언젠가 반드시 잊기 때문입니다.

글로 설명하면 층이 많아 보이지만, 실제로 도는 모양은 여섯 칸짜리 고리 하나입니다. 먼저 전체를 한 장으로 보시고, 그다음에 화면을 하나씩 여는 편이 빠릅니다.

화면 ① — 흐름 콘솔: 무엇이 어디로 흘러 무엇이 되는가

운영 대시보드의 첫 화면은 “지금 잘 돌아가나”가 아니라 “무엇이 어디로 흘러 무엇으로 바뀌는가”를 봅니다. 시계가 아니라 물길을 보는 화면입니다.

이 화면에서 실제로 읽는 항목은 다음과 같습니다. 숫자보다 “무엇을 세고 있는가”가 중요합니다.

화면 ② — 엔진 헬스체크: 색이 아니라 신호로 본다

Knowledge structure지식 구조 — 무엇이 어디에 쌓이는가

여기까지가 화면이었다면, 그 화면 뒤에 실제로 쌓여 있는 것들은 이렇습니다. 층이 나뉘어 있는 이유는 정리벽이 아니라 갱신 주기와 갱신 권한이 층마다 다르기 때문입니다. 용어는 차수마다 바뀌고, 규칙은 사고가 나야 바뀌고, 사례는 마감할 때만 늘어납니다.

세는 기준 = 각 층의 정본 원장을 직접 집계한 값입니다(앞의 대시보드 캡처와는 기준이 다릅니다 — 화면은 라우팅 대상이나 활성 노출분을 세고, 이 표는 등록분 전체를 셉니다).

Case A · Lecture강의에서 실록은 이렇게 씁니다

제 강의는 같은 고객사에서 차수가 반복되는 형태가 많습니다. 반복 차수는 편할 것 같지만, 실제로는 지난 차수의 지식이 사람 기억에만 남아 매번 증발하는 구조적 문제를 안고 있습니다.

자랑이 아니라 실패에서 나온 규칙입니다

“차수 마감 때 도메인 좌표를 다시 봉인한다”는 규칙에는 사연이 있습니다. 어느 자동차 부품사 워크숍 2차수의 일입니다. 대상 도메인이 1차수와 완전히 달라졌는데도 13일 동안 이전 차수의 좌표만 참조했습니다. 좌표 갱신이 마감 절차에 묶여 있지 않았기 때문입니다. 회고 문서가 뒤늦게 그 사실을 발견했는데, 3차수에서 같은 일이 또 일어났습니다.

워크숍 진행 자체에도 같은 원리가 걸려 있습니다. 참여자 데이터 분석 → 도메인 관점 수립 → 업무 온톨로지 지도 → 그 좌표 위의 실습. 이 4단 체인의 순서를 지키면 “일반론 PM 강의”가 되지 않습니다.

Case B · Project프로젝트에서 실록은 이렇게 씁니다 — 이 글이 그 증거입니다

고객사 프로젝트에서 가장 중요한 규칙은 품질이 아니라 경계입니다. 어떤 자료가 어디까지 나갈 수 있는가. 이 규칙은 설명하기보다 보여드리는 편이 빠릅니다 — 이 글을 만드는 동안 실제로 세 번 작동했기 때문입니다.

고객사 자료에는 이 밖에도 알 필요 원칙(need-to-know)에 따른 3단 공개 범위와 민감도 등급이 걸려 있습니다. 프로젝트가 여러 달 이어질 때는 인물·용어·이전 회의 맥락을 승계하는 규칙이 따로 붙습니다. 이 층이 없으면 매번 “저번에 뭐 했었죠?”로 시작하게 됩니다.

Case C · Publishing발행에서 실록은 이렇게 씁니다 — 지금 읽고 계신 이 글이 산출물입니다

세 번째 사례는 증명하기가 가장 쉽습니다. 이 글 자체가 그 파이프라인을 통과한 결과물이기 때문입니다. 콘텐츠 폴더를 여는 순간 발행 규칙이 붙고, 나가기 전에 게이트가 걸립니다.

그런데 이번에도 두 군데가 새로 뚫렸습니다

Layer 2 · RAGRAG 3층 — 노트에서 지도로, 지도에서 조직 자산으로

많은 분이 RAG를 “문서를 넣으면 답해주는 검색”으로 이해하십니다. 실제로 컨설팅에서 필요한 건 조금 다릅니다 — 지금 쓰려는 문서와 가장 가까운 지난 사례를 먼저 꺼내오는 것입니다. 그래서 제 RAG는 세 층으로 나뉩니다.

화면 ③ — 사례 지도(Atlas): 1,205건을 어떻게 보는가

화면 ④ — 코퍼스 지도: 경험을 한 장으로

같은 코퍼스를 외부 공개용으로 다시 그린 도식입니다. 개별 사례명 없이 고객군 × 사업영역 교차 집계까지만 보여줍니다. 좌표와 건수는 손으로 적지 않고 원본 데이터에서 생성하며, 빌드할 때 정본 집계와 대조해 어긋나면 실패하도록 만들어 두었습니다.

세 층이 실제로 도는 순서

Where it transfers응용분야 — 이 구조가 옮겨 붙는 자리와 그렇지 않은 자리

여기까지는 제 일(강의·컨설팅·발행)에서의 이야기입니다. 그런데 이 구조에서 도메인에 의존하는 부분은 규칙의 내용뿐이고, 배선 자체는 도메인과 무관합니다. 그래서 “우리 일에도 되나요”라는 질문에는 일의 종류가 아니라 일의 성질로 답하는 편이 정확합니다.

반대로, 붙이지 않는 편이 나은 경우

Honesty정직한 한계 — 이 글을 쓰다가 발견한 것 포함

여기까지 읽으시면 잘 굴러가는 체계처럼 보일 수 있어, 관측된 결함을 그대로 적습니다.

화면 ⑤ — 자동화 함대: 조용히 죽은 잡을 찾는 화면

위 두 건을 발견하게 해준 화면을 그대로 싣습니다. 이 보드는 정기 실행 작업을 “무엇을 만들어 어디에 두는가” 기준으로 전수 나열합니다. 그리고 각 잡이 직전 예정 시각에 실제로 돌았는지를 따로 표시합니다. 등록 여부가 아니라 실행 여부를 보는 화면입니다.

MilestoneAX 시리즈 100편 — 무엇이 쌓였나

이 글이 100편째라고 말씀드렸으니, 그 100편이 어떤 축으로 쌓였는지도 열어 보이는 게 맞겠습니다. 아래 지도는 시리즈 원장에서 자동으로 생성했습니다 — 편수를 손으로 적으면 다음 글이 올라가는 순간 틀린 숫자가 되기 때문입니다.

이 분포를 보고 제가 확인한 건 자랑거리가 아니라 편중이었습니다. 현장에서 검증한 기록과 인물·사고 체계 쪽은 두꺼운데, 공공·SI 사업관리처럼 실제로 요청이 많은 영역이 두 편에 그쳐 있습니다. 사례 지도에서 “강점이 아니라 공백을 본다”고 말씀드린 것과 정확히 같은 사용법입니다 — 지도는 잘한 걸 확인하는 도구가 아니라 다음에 어디로 갈지 정하는 도구입니다.

Read next더 깊이 — 하네스 트랙 · RAG 트랙 · 오픈소스

이 글은 “실제로 어떻게 쓰는가”에 초점을 뒀습니다. 각 층의 설계 근거와 실측은 아래 글에서 더 자세히 다뤘습니다.

Closing결국 남는 한 문장

강의에서 이 화면들을 띄우면 자주 나오는 반응이 “저건 너무 많이 만들어야 하는 것 아닌가요”입니다. 정직하게 말씀드리면, 저 화면들은 한 번에 만들어진 것이 아니라 실패할 때마다 한 칸씩 늘어난 것입니다. 13일 동안 잘못된 좌표를 참조한 뒤에 규칙 한 줄이 생겼고, 캡처에서 과제명이 새는 걸 눈으로 잡은 뒤에 차단 규칙이 생겼습니다.

그러니 시작점은 도구 선택이 아닙니다. 지난달에 같은 실수를 두 번 했던 자리를 하나 고르고, 거기에 말뚝 하나를 세우는 것입니다. 그 말뚝이 열 개쯤 쌓이면, 그때는 이미 자기만의 하네스를 갖고 계신 겁니다.

이 글이 100편째라 특별한 걸 쓸까 했지만, 결국 가장 자주 받은 질문에 화면째로 답하는 것보다 더 나은 기념은 없다고 판단했습니다. 100편도 한 편씩 쌓인 것이고, 저 대시보드도 한 칸씩 늘어난 것이라 원리가 같습니다.

“나만의 RAG와 하네스를 만들고 싶다”고 적어주신 분들께 이 글이 그 첫 말뚝의 자리를 정하는 데 도움이 되기를 바랍니다. 다음 100편에서는 여러분의 하네스 이야기도 듣게 되기를 바랍니다.