"AI에게 잘 물어보는 것보다 중요한 건, AI가 읽을 정본(Single Source of Truth)을 제대로 만들어주는 것이다."
이번 지피터스 스터디에서 AKM과 LLM Wiki 개념을 배우며 일하는 방식에 대해 얻은 깨달음을 정리합니다.
1. 수업을 시작하며: "왜 AI 답변은 매번 널뛰기할까?"
그동안 AI를 활용하면서 느꼈던 가장 큰 답답함은 답변의 일관성이었습니다. 프롬프트를 잘 써서 오늘 만족스러운 답변을 얻어도, 내일 다시 물어보면 또 다른 엉뚱한 소리를 하곤 했습니다. 자료를 한꺼번에 많이 넣어주어도 법적 예외나 핵심 맥락을 놓치는 경우가 많았습니다.
"어떻게 해야 AI가 내 업무 맥락과 판단 기준을 완벽히 이해하고 계속 함께 일할 수 있을까?"
이 고민의 답을 찾기 위해 이번 스터디에 참여했습니다.
2. 이번 수업에서 얻은 핵심 깨달음 3가지
① Source(원본)와 Knowledge(지식)의 명확한 분리
가장 인상 깊었던 원칙은 법령/자료 원문과 나의 해석(지식)을 절대 섞지 않는 것이었습니다.
Source: 수정되지 않는 원본 자료 (법령, 조례, raw data)
Knowledge: 원본을 바탕으로 재사용 가능하게 가공한 판단 기준과 업무 매뉴얼
이 둘을 분리해두어야 AI가 오답을 내더라도 원본이 오염되지 않고, 지식의 출처를 투명하게 추적할 수 있음을 배웠습니다.
② 100% 자동화보다 중요한 '안전 게이트(Verify)'
AI가 알아서 다 해주길 바라는 것은 환상이었습니다. 행정이나 실무 현장에서는 '그럴듯한 정답'보다 '위험하지 않은 안전함'이 훨씬 중요합니다. 근거가 모호하거나 법적 위험이 높은 영역은 AI가 단정 짓지 않고 담당자 검토(HOLD)로 남기도록 안전장치를 만드는 구조가 왜 필수인지 명확히 알게 되었습니다.
③ 오답을 시스템으로 환류하는 회귀개선(Learn Back)
AI가 틀린 답을 냈을 때, 단순히 프롬프트 문장만 고치고 끝내는 게 아니라:
검색 문제인가?
매뉴얼 지식이 부족한가?
절차가 모호한가?
원인을 나누고 Markdown 위키 정본과 절차(AGENTS.md) 자체를 개선해야 오늘 발견한 실패가 내일의 더 강력한 자산이 된다는 것을 깨달았습니다.
3. 앞으로 내 실무에 적용해볼 점
이번 스터디를 통해 단순히 '프롬프팅 기술'을 배운 게 아니라, 나만의 지식 운영체계(LLM Wiki)를 만드는 관점을 얻었습니다.
Inbox-first: 떠돌아다니는 아이디어나 사례를 검증 전까지 '검토 대기' 상태로 관리하기
지식의 정본화: 흩어진 개인 노트와 업무 노하우를 에이전트가 읽을 수 있는 Markdown 위키로 구조화하기
에이전트와의 협업: Claude Code, VS Code 등 개발/업무 환경에서 에이전트가 하나의 공유된 매뉴얼을 읽고 작업하도록 세팅하기
4. 마치며
AI에게 자료를 많이 집어넣는다고 곧바로 조직의 지식이 되지는 않았습니다. 원본과 해석을 나누고, 예외를 기록하고, 사람의 검증을 거쳐 매뉴얼로 승격시키는 과정이야말로 진정한 '에이전트용 지식 구축'이었습니다.
수업에서 배운 AKM 지식 관리 체계를 바탕으로, 전임자가 떠나도 맥락이 남고 후임자와 에이전트가 함께 이어 쓰는 살아있는 지식 시스템을 계속 만들어보려 합니다!
함께 스터디하며 좋은 인사이트 나눠주신 크루분들과 스피커분들께 감사드립니다! 🙏
