LLM Wiki로 시작한 지식과 경험의 자산화
안녕하세요. 통합기술연구3팀 손진우입니다.
저는 모니터링 솔루션 기술지원과 SQL 튜닝 컨설팅, 제품 화면 기술 기획을 함께 맡고 있습니다. 요즘 들어 현장에서 쌓아 온 지식과 경험을 AI를 활용하여 제품 화면 기술 기획에 반영하는 업무가 늘어나고 있습니다.
업무에 AI를 쓰기 시작하면서 한 가지가 계속 걸렸습니다. 매번 같은 배경 설명을 다시 써야 했다는 점입니다. 게다가 제 기억도 시간이 지나면 희미해집니다. 알아낸 것을 제 지식 자산으로 남겨 둘 필요가 있었습니다.
그래서 개인 위키를 만들어 쓴 과정과, 거기서 나온 결과물을 공유합니다.
1. 같은 일을 매번 처음부터 다시 했습니다
업무를 돌아보니 조사했던 것을 다시 조사하고, 설명했던 것을 다시 설명하는 일이 많았습니다. 한 번 알아낸 것이 남지 않아 같은 일이 매번 처음부터 다시 시작됐습니다. 돌이켜보니 제 기억에서도 사라졌고, 제가 질문해서 알아냈던 AI 세션의 메모리에서도 사라진 경우였습니다.
1-1. 제 기억은 흐려집니다
기술지원 엔지니어는 여러 고객사를 거치면서 경험과 지식을 쌓습니다. 같은 제품이라도 고객사마다 환경이 다르고, 장애가 나는 지점이 다르고, 운영자가 주로 보고 궁금해하는 화면이 다릅니다.
그렇게 알게 된 것들은 대부분 문서로 남지 않습니다.
장애 상황에서 운영자가 가장 먼저 확인하는 화면이 무엇인지,
우리 제품의 수집 주기 때문에 어느 구간의 데이터가 비는지,
이 지표를 %로 나타낼 때 무엇으로 나눈 값이어야 하는지. 그때그때 알아내고 기억해 둘 뿐입니다.
시간이 지나면 그 기억은 흐릿하게만 남습니다. 구체적인 내용을 다시 확인하려면 예전 파일을 찾아보거나 조사를 처음부터 다시 해야 합니다.
1-2. AI는 흐려진 자리를 지어내 채웁니다
AI를 업무에 쓰기 시작하면서 비슷한 문제를 하나 더 만났습니다.
기획 검토를 시키려면 배경부터 설명해야 합니다. 우리 제품이 어떤 구조인지, 이 지표가 어디서 수집되는지, 어떤 값이 나오면 이상한 것인지. 그 배경을 채팅창에 써 넣으면 쓸 만한 답이 나옵니다.
요즘 AI 도구들은 대화 내용을 어느 정도 기억합니다. 그래서 써 넣은 배경은 한동안 남아 있습니다. 다만 영구적이지 않습니다. 시간이 지나고 대화가 쌓이면 사람 기억이 흐려지듯 같이 흐려집니다. 그러면 같은 설명을 처음부터 다시 쓰게 됩니다.
더 곤란한 것은 그때 AI가 “기억나지 않는다”고 말해 주지 않는다는 점입니다. 흐려진 자리를 그럴듯한 내용으로 채워 넣습니다.
우리 제품에 없는 지표를 있는 것처럼 근거로 삼고, 예전에 정해 뒀다는 기준을 지어내 갖다 붙입니다. 답을 못 받는 것보다 지어낸 답이 위험합니다. 틀린 줄 모르고 다음 단계로 넘어가기 때문입니다.
정정도 마찬가지입니다. “그 지표는 우리 제품에 없다”고 알려 줘도 그 정정은 대화와 함께 흐려지고, 얼마 뒤 같은 오류가 같은 자리에서 다시 나옵니다.
공통점
두 가지는 겉보기에 다른 일이지만 구조가 같습니다. 이미 어딘가에 있던 것이 휘발돼서, 그것을 다시 만들어 내는 데 시간이 드는 것입니다. 제 머리에서, AI 세션에서 각각 휘발됩니다. 그리고 둘 다 본연의 업무에 앞서 치러야 하는 부차적인 과정입니다.
한 번 알아낸 것을 다음에 그대로 다시 활용할 수 있는 형태로 남겨 둘 방법이 필요했습니다.
2. 팀 기술발표에서 LLM Wiki를 알게 됐습니다
그 실마리를 팀 기술발표 시간에 얻었습니다. 통합기술연구3팀은 매달 한 번 Homecoming Day를 엽니다. 업무 특성상 외근이 많은 팀원들이 하루 날을 잡고 사내에 들어와, 각자 공부한 것이나 업무에 적용해 본 것을 서로에게 공유하는 자리입니다.
AI 연구자 안드레이 카파시(Andrej Karpathy)가 공개한 LLM Wiki 패턴 이야기를 그 자리에서 처음 들었습니다.
LLM은 ChatGPT나 Claude 같은 AI 모델을 가리키는 말입니다. LLM Wiki는 그 AI가 직접 작성하고 관리하는 개인 위키를 지식 창고로 쓰는 방식입니다.
제가 겪던 문제를 풀 방법이 되겠다고 생각했습니다. 매번 새로 설명하는 대신, 한 번 설명한 것을 파일로 쌓아 두면 되기 때문입니다.
그전까지는 자료만 모아 두고, 질문할 때마다 AI에게 필요한 대목을 찾아 읽히는 식으로 썼습니다. 다만 이 방식으로는 AI가 답을 만들 때마다 처음부터 다시 찾습니다. 문서 5개를 엮어야 나오는 답이라면 그 작업을 물어볼 때마다 새로 합니다. 어제 한 정리가 오늘은 남아 있지 않습니다.
카파시가 제안한 방식은 다릅니다. 질문을 받고 정리하는 대신, 자료가 들어올 때마다 AI가 미리 위키를 갱신해 둡니다.
새 자료가 들어오면 읽고 핵심을 기존 페이지에 합칩니다. 문서 사이 링크를 손보고, 예전 내용과 모순되면 그 지점을 표시해 둡니다. 그래서 어제 한 정리가 오늘도 그대로 남고, 자료를 넣을수록 위키가 두꺼워집니다.
듣고 바로 시작했습니다. 현장에서 얻은 지식과 앞으로 조사할 지식을 같은 형식으로 쌓아 두고, 다음 작업에서 근거로 다시 활용하는 것이 목표였습니다.
3. 제 위키를 먼저 보여 드립니다
여기서 말하는 위키는 제 PC 폴더에 마크다운이라는 텍스트 문서로 쌓아 두는 개인 위키입니다. 파일을 만들고 고치는 일은 컴퓨터의 파일을 직접 읽고 쓸 수 있는 AI 에이전트 Claude Code에게 맡겼습니다.
완성된 모습부터 소개해 드리겠습니다. 5장에는 실제로 생성하고 유지하는 방법을 담았습니다.
3-1. 원본·위키·규약의 3개 층
구조는 3개 층입니다.
- 원본(raw): deep-research(AI에게 맡기는 심층 조사) 결과, 제품 소스 분석, 공식 문서를 그대로 모아 둡니다. AI는 읽기만 하고 고치지 않습니다. 판단의 근거를 나중에 다시 확인할 수 있는 유일한 층입니다.
- 위키(wiki): 원본에서 뽑아낸 정제 지식. 도메인별 폴더로 나누고 AI가 전적으로 관리합니다. 사람은 읽고 질문할 뿐입니다.
- 규약(CLAUDE.md): 위키를 어떻게 다룰지 정한 규칙 파일. Claude Code가 일을 시작하기 전에 먼저 읽습니다(다른 AI 도구는 AGENTS.md). 이 파일이 있어야 AI가 위키 관리자로 움직입니다.
여기에 특수 파일 2개가 붙습니다.
index.md는 AI가 가장 먼저 읽는 전체 목차, log.md는 언제 무엇을 넣었는지 남긴 기록입니다.운영은 새 자료를 편입하고(ingest), 위키에 질문하고, 주기적으로 점검하는 3가지 동작입니다. 위키를 AI에게 맡기는 만큼, 지어낸 내용이 섞이지 않게 하는 장치도 함께 둡니다. 문장마다 어디까지 확인된 것인지 등급을 달고 값에는 확인한 날짜를 붙여, AI가 근거로 쓸 때 확인된 사실인지 짐작인지 함께 보게 합니다. 저는 여기에 위키에 적힌 값을 제품에 다시 조회해 보는 검증을 하나 더 뒀습니다.
이 3개 층은 전부 마크다운 파일일 뿐입니다. 그래서 AI가 별도 연동 없이 폴더에서 바로 읽습니다. 지식을 어떤 서비스 안에 넣어 두면 그 서비스를 더 쓰지 못하게 되는 순간 지식도 같이 사라지지만, 파일로 두면 남습니다. GitHub 같은 저장소에 올리면 팀이 함께 보는 자산이 되기도 합니다.
폴더와 파일 이름은 규약에 적어 두면 AI가 그대로 따릅니다. 사람이 외워 둘 필요는 없습니다.
3-2. 폴더 구성과 그래프 뷰
위 화면은 마크다운 폴더를 그대로 열어 보여 주는 편집기 Obsidian으로 위키 폴더를 연 모습입니다. 왼쪽 폴더 목록에 펼쳐진 것이 원본 자료입니다. 자료가 들어온 단위 그대로 쌓아 둡니다.
원본에서 뽑아낸 지식을 넣는
wiki/는 폴더 이름을 aws-ai, exemone, postgresql-rca, sql-tuning처럼 도메인으로 나눴습니다. 프로젝트 단위로 나누지 않은 것은, 같은 지식이 여러 프로젝트에서 쓰이기 때문입니다.오른쪽 그래프 뷰에서 가운데 크게 모여 있는 두 노드가
index와 log입니다. 거의 모든 문서가 여기로 연결됩니다.문서를 하나 열면 상단에 두 가지가 더 있습니다. 내용이 어디까지 확인된 것인지 나타내는 근거 등급과, 값을 직접 확인한 날짜(
verified)입니다.3-3. 채팅창에 배경을 써 넣던 때와 달라진 점
1장에서 말한, 채팅창에 배경을 매번 써 넣던 방식과 무엇이 달라지는지 정리하면 이렇습니다.
구분 | 채팅창 프롬프트 | 로컬 위키 + 에이전트 |
지식 수명 | 시간이 지나면 흐려짐 | 파일로 남아 다음 세션에서 그대로 읽힘 |
배경 설명 | 안 쓸 배경까지 사람이 매번 복사해 넣음 | 에이전트가 필요한 문서만 골라 읽음 |
오류 정정 | 지적해도 다음 세션에 재발 | 고친 내용이 파일에 남아 다음 세션이 그것을 읽음 |
결과물 | 텍스트 (사람이 복사해 적용) | 실제 파일 수정과 검증까지 |
공유 | 개인 대화 기록 | 팀이 읽는 문서 |
표로만 보면 차이가 크지 않아 보입니다. 실제로 무엇이 달라졌는지는 결과물 3개를 만들면서 드러났습니다.
4. 위키를 업무에 적용한 사례
위키를 근거로 업무에 적용한 사례는 자사 통합 모니터링 솔루션 exemONE의 통합관제 홈, AWS Cost Advisor, PostgreSQL 장애 원인분석(RCA) 3가지입니다. 통합관제 홈과 Cost Advisor는 화면이고, RCA는 장애의 원인과 조치를 판별하는 규칙입니다. 3개 사례에서 위키가 한 일은 각각 달랐습니다.
4-1. exemONE 통합관제 홈
첫 결과물은 exemONE 통합관제 홈 재기획입니다. 홈은 접속하면 가장 먼저 보이는 화면으로, 애플리케이션·데이터베이스·인프라스트럭처·클라우드·쿠버네티스·메시지큐까지 관제 대상 전 영역을 한 화면에 올려 둡니다. 인프라 운영 담당자가 지금 어느 영역에 문제가 있는지를 이 화면에서 빠르게 판단하게 하는 것이 목적입니다.
제 지식과 경험은 DB 쪽에 치중돼 있습니다. 경험해 본 적 없는 영역까지 무엇을 보여줄지 정해야 했습니다. 그래서 제 경험 대신 제품이 이미 가진 것에서 출발하기로 하고, 시작점을 exemONE의 데이터 수집 DB로 잡았습니다.
제 머릿속에 있던 것과, 제품이 수집해 저장하는 테이블 구조와 항목을 먼저 위키에 넣었습니다. 다만 컬럼 목록만으로는 쓸 데가 없었습니다. 필요한 것은 그다음이었습니다.
- 이 데이터를 왜 수집하는가 어떤 상황을 보려고 만든 항목인지
- 값의 성격이 무엇인가 그 순간의 값인지 계속 쌓여 온 값인지, 사용률이라면 무엇으로 나눈 비율인지, 단위가 무엇인지
- 운영자가 어떤 판단을 할 때 쓰는가
이 3가지가 채워지지 않는 영역은 deep-research로 보완한 뒤, 제품이 실제로 수집하는 항목과 맞춰 보고 우리 환경에서 성립하는 것만 위키에 정리했습니다. 저도 그 과정을 따라 읽으며 모르던 영역을 조금씩 이해했습니다.
이렇게 정리한 위키를 근거로 초안을 만들었습니다. AI 에이전트 3명에게 그 위키와 exemONE이 실제로 수집한 데이터를 주고, 각각 인프라 전문가, 화면 기획자(UI/UX 전문가), 이 화면을 매일 볼 운영자 역할을 부여했습니다.
3가지 관점이 서로 의견을 내고 반박하게 두었고, 저는 그 논의를 보며 무엇을 채택할지만 결정했습니다. 그렇게 나온 초안을 여러 차례 다듬어, 실제로 동작하는 화면까지 만들었습니다.
화면을 그리는 동안 위키 지식도 함께 수정과 보완이 이루어졌습니다. 정리해 둔 것과 실제 데이터가 어긋나는 지점이 계속 나왔기 때문입니다. 없다고 적어 둔 값이 다른 테이블에서 나오기도 했고, 쓸 수 있다고 본 지표가 화면에 올리기에는 맞지 않기도 했습니다. 그때마다 위키를 고쳤습니다.
영역마다 한 번씩 이 과정을 거치고 나니, 경험해 본 적 없는 영역까지 무엇을 왜 화면에 올려야 하는지 근거를 갖고 말할 수 있게 됐습니다. 새 기능이나 화면 탭을 추가할 때도 그때까지의 이력을 다시 설명하지 않고 바로 이어서 작업할 수 있었습니다. 위키에 그 이력이 남아 있었기 때문입니다.
다만 여기까지가 제가 혼자 할 수 있는 범위입니다. 쿠버네티스나 네트워크처럼 직접 운영해 본 적 없는 영역은 해당 영역 전문가의 피드백을 받아 수정해야 합니다. 그 초안이 현장에서 쓸 만한지는 그 일을 해 본 사람만 판단할 수 있었습니다.
4-2. AWS Cost Advisor
그다음은 AWS 비용을 보는 화면입니다. 사내에서 만들고 있는 AWS Dashboard는 여러 AWS 계정의 리소스를 한 화면에서 보는 프로젝트이고, Cost Advisor는 그 안에서 요금을 다루는 화면입니다. 기존 제품에 클라우드를 모니터링하는 화면은 있어도 요금 쪽은 비어 있었습니다.
클라우드는 쓴 만큼 청구되는 구조라 비용을 줄이는 일이 상시 과제로 남습니다. 요구사항이 생겼을 때를 대비해 Cost Advisor 화면은 제가 선제적으로 만들어 두었습니다.
리소스와 구성은 DB 서비스와 관련해서는 다뤄 봤지만 나머지는 생소했고, 비용 화면을 만들려니 요금 체계도 따로 조사해야 했습니다.
요금은 가상 서버인 인스턴스의 종류와 서비스 지역에 따라 다르고, 저장 공간과 입출력량은 또 따로 청구됩니다. 화면에 “월 $22 절감”이라고 적으려면 이 계산이 전부 맞아야 합니다. 이 $22는 온디맨드 기준 월 $45.26짜리 인스턴스를 $22.63짜리로 바꿔 비용을 절반으로 줄인다는 뜻입니다.
순서를 이렇게 잡았습니다.
- Claude Code의 deep-research로 AWS 요금 구조를 조사 (인스턴스 패밀리 체계, 과금 단위, 라이선스 모델, 리사이징 시 실제로 바뀌는 항목)
- 결과를
raw/aws-ai/에 원본 그대로 저장
- 화면 설계에 필요한 사실만 뽑아 위키에 원자 단위로(한 항목이 한 가지 사실만 말하게) 정리
- 그 위키를 근거로 화면 설계
결과가 이 화면입니다. Cost Advisor도 동작하는 화면으로 만들었습니다.
AI를 통해 정보 조사를 지시하고 화면을 설계하면서, 사람인 제가 고민해야 할 것은 운영자의 물음에 화면이 답하게 만드는 일이었습니다. 제가 운영자라고 가정했을 때, 확인하고 싶은 것은 3가지였습니다. 얼마 아끼나, 왜 그렇게 판단했나, 바꿔도 리소스상 문제가 생기지 않나.
- 권고 목록 리소스를 다운사이징 / 업사이징 / 삭제 / 적정으로 분류하고, 권고대로 바꾸면 월 요금이 얼마나 달라지는지 함께 나타냅니다. 운영자는 이 목록에서 비용을 줄일 수 있는 리소스를 찾을 수 있습니다.
- 판정 기준 목록에서 특정 리소스를 클릭하면 현재 사양과 권고 사양을 비교해, 바꿔도 문제가 없는지 항목별로 표시합니다. 판단은 사용량이 몰렸던 시간대를 기준으로 하고, 지금의 사용률과 바꾼 뒤의 예상 사용률을 그래프로 함께 보여 줍니다. 비교하는 항목은 리소스 유형(서버, DB, 디스크)마다 다릅니다. 운영자는 근거를 직접 확인하고 클래스 변경 여부를 판단할 수 있습니다.
- 클래스 변경 후보 서버와 DB의 사양 등급인 클래스를 위아래로 모두 월 요금과 함께 보여 주고, 각 클래스마다 현 사용량을 기준으로 바꿀 수 있는지 표시합니다. 그중 하나를 클릭하면 그 클래스로 바꿨을 때의 판정 결과와 예상 사용률이 오른쪽 판정 기준·지표 추이 비교 영역에 다시 그려집니다. 운영자는 클래스를 실제로 바꾸기 전에, 바꾼 뒤의 사용률 추이를 미리 시뮬레이션해 볼 수 있습니다.
이 화면의 판단 로직, 즉 어떤 사용률 구간에 어떤 등급을 매기는지도 위키에 다시 적어 두었습니다. 다음에 다른 리소스 타입을 추가할 때 같은 기준을 그대로 쓰기 위해서입니다.
조사한 요금도 위키에 넣었습니다. 요금은 계속 바뀌므로 값과 함께 확인한 날짜를 남겨, 오래된 것부터 다시 조회해 갱신하도록 했습니다. 생소한 데다 외워 둘 이유도 없고 시간이 지나면 달라지는 지식일수록, 머리에 담는 대신 위키에 두고 필요할 때 꺼내 쓰는 편이 낫습니다.
4-3. PostgreSQL 장애 원인분석(RCA)
exemONE의 AI 운영 분석 기능인 AIOps에 장애 원인분석(RCA)을 더하는 사내 프로젝트도 있습니다. DB가 느려지거나 장애가 나면 AIOps가 그것을 감지해 알람을 냅니다.
많은 인프라 요소 중에 저는 PostgreSQL 플랫폼을 담당하게 되었습니다.
기존 제품 알람은 “특정 지표가 급증했다”까지만 알려 줍니다. AIOps는 지금 무엇이 문제인지, 왜 그렇게 됐는지, 어떻게 조치해야 하는지까지 알려 주는 것을 목표로 합니다.
다만 exemONE이 구축되는 고객사는 보통 외부 인터넷과 단절된 환경이라, 인터넷 너머의 AI 서비스에 질문을 보낼 수 없습니다. 그래서 AI가 판단할 지식을 제품 안에 미리 갖춰야 합니다. 그 지식 기반 판단 체계를 만드는 일은 저를 포함해 이 프로젝트에 참여하는 본부원들의 몫입니다.
그래서 자주 겪는 장애를 Lock 대기·CPU 급증·IO 부하·Vacuum 이슈·WAL 압박 5가지 신호로 정리했습니다. Lock 대기는 앞선 작업이 끝나기를 기다리며 멈춰 있는 상태, CPU 급증과 IO 부하는 연산과 디스크 읽기·쓰기가 몰린 상태입니다. Vacuum은 지운 데이터를 정리하는 작업이고, WAL은 변경 내역을 먼저 적어 두는 기록입니다.
이 중 하나라도 문제가 생기면 DB가 느려질 수 있으며, 여러 문제가 동시에 발생할 경우 복합적인 분석이 필요합니다.
저는 신호가 겹치는 경우를 하나씩 상황으로 정의하고, 상황마다 무엇이 원인이고 어떻게 조치할지를 규칙으로 적었습니다. 여러 신호가 함께 나타났을 때 무엇이 무엇을 불러왔는지는 AI의 도움을 받아 정리했습니다.
그 규칙의 근거는 전부 위키에 있습니다. 위키의 postgresql-rca 도메인에 신호 정의부터 조합 매트릭스, 상황별 규칙, 검증 환경까지 13개 페이지로 정리해 두었습니다.
다음은 검증입니다. 각 상황을 실제 DB에서 그대로 일으키는 시뮬레이션 스크립트를 AI로 만들었습니다. 상황마다 두 차례씩 재현해 보고, 미리 정의해 둔 규칙이 실제와 맞는지 확인했습니다.
검증에서 새로 알게 된 것은 다시 위키에 적었습니다. 화면 2개를 만들 때와 같은 순환입니다.
본부에서는 이렇게 정리한 규칙을 RAG 학습 데이터(AI가 답할 때 참고하는 자료)로 만들어 반영하고 있습니다. 학습 결과는 AIOps에 들어갑니다. 다음 단계는 검증을 계속하면서 최종적으로 실무에 적용해 보는 일입니다. 그 과정에서 미처 정의하지 못한 상황이나 고쳐야 할 규칙이 나올 텐데, 그 내용도 위키에 반영해 지식 자산으로 쌓아 나갈 계획입니다.
5. 위키를 생성하고 유지하는 방법
3장에서 보여 드린 위키를 어떻게 생성하고 유지하는지, 제가 진행했던 순서대로 소개해 드립니다.
5-1. 카파시의 지침으로 시작하기
원문은 카파시가 GitHub Gist에 공개해 두었습니다. 전문을 복사해 붙여 넣어도 되고, 주소만 줘도 에이전트가 읽습니다. 저는 빈 폴더에서 Claude Code를 열어 이렇게 시켰습니다.
Claude Code가 폴더 구조와 규약 파일을 만듭니다. 자료를 넣고 질문하고 점검하는 절차,
index.md와 log.md까지 카파시 문서에 이미 들어 있어서 따로 지시하지 않아도 나옵니다. 이후로는 “이 자료를 ingest 해줘” 한 줄이면 됩니다.vault와 Web Clipper를 언급한 두 줄은 제가 쓰는 환경에 맞춘 것이라 따로 적어야 반영됩니다.
vault는 Obsidian이 열어 두는 폴더 단위를 부르는 말입니다. Obsidian을 설치하고 위키 폴더를 vault로 지정하면 왼쪽에 문서 목록이 뜨고, 문서끼리 어떻게 연결돼 있는지 그래프로 볼 수 있습니다. 그래프가 그려지려면 문서 간 연결을
[[파일명]] 형식으로 맞춰 두어야 합니다.규약은 처음부터 완성할 필요가 없습니다.
CLAUDE.md에 적는 지침과 규칙은 업무 성격에 맞춰 바꿔 가며 쓰면 됩니다. 저도 폴더 기준을 중간에 바꿨고, 근거 등급은 한참 뒤에 넣었습니다.5-2. 조사한 자료를 위키에 편입하기
조사해서 알게 된 것은 그때그때 위키에 편입합니다. 저는 보통 자료를 조사할 때 두 가지 방법을 씁니다.
하나는 Claude의 deep-research입니다. “AWS 요금 체계를 조사해 줘”처럼 지시하면 조사 결과가 문서로 나옵니다. 그 결과를 그대로 원본 폴더에 넣습니다.
다른 하나는 직접 찾아 읽던 웹 페이지를 저장해 두는 것입니다. 브라우저 확장 도구인 Obsidian Web Clipper를 쓰면 보고 있던 화면에서 버튼 한 번으로 위키에 저장됩니다. 즐겨찾기(북마크)에 URL을 넣어 두듯이 쓰는데, 주소만 남는 북마크와 달리 본문까지 같이 들어옵니다. 제목과 출처 URL, 저장한 날짜가 자동으로 붙습니다.
어느 쪽이든 편입한 원문은 그대로 두고, 위키 페이지에는 거기서 필요한 것만 뽑아 씁니다.
5-3. 쓸 만한 답변을 위키에 저장하기
질문해서 받은 답 중 쓸 만한 것은 그대로 위키 페이지로 만듭니다. 비교표 하나, 판단 기준 하나라도 남겨 둡니다. 대화 기록에만 두면 시간이 지나 찾기 어렵지만, 위키에 넣으면 다음 질문에서도, 그다음 기획에서도 근거로 다시 씁니다.
5-4. 위키에 넣는 문장마다 근거 등급 매기기
위키에 넣은 문장은 나중에 전부 판단의 근거로 쓰입니다. 그래서 어디까지 확인된 내용인지를 실측·인용·추정으로 구분해 둡니다.
등급 | 정의 | 조건 |
실측 | 1차 출처를 직접 실행해 값을 확인 | 재현 가능한 쿼리와 경로를 본문에 남김 |
인용 | 신뢰 가능한 1차 문서나 소스 코드 근거. 실행은 안 함 | 파일:라인 또는 문서 위치 명시 |
추정 | 정황과 유추 | 근거와 반례 가능성을 함께 적음 |
한 페이지에 여러 등급이 섞이면 확인이 덜 된 쪽으로 맞춥니다.
구분해 두지 않으면 짐작한 내용이나 확인되지 않은 내용까지 AI 답변의 근거가 되고, 그 위에서 나온 기획도 같이 틀어집니다. 확정 사실과 미확인을 구분하지 않으면 나중에는 이 위키를 스스로 못 믿게 됩니다.
5-5. 값을 확인한 날짜를 남기고 갱신하기
위키에 정리해 둔 내용은 시간이 지나면 실제와 어긋납니다. 제 업무에서는 제품 버전이 올라가면서 지표의 이름 규칙이나 저장 위치가 달라지는 경우가 그렇습니다. 위키에 적힌 대로 조회하면 값이 한 줄도 나오지 않습니다. AI는 그 차이를 확인하지 않고 적힌 것을 그대로 근거로 씁니다.
그래서 새로 만드는 페이지에는 값을 직접 확인한 날짜(
verified)를 답니다. 주기 점검에서는 이 날짜가 오래된 페이지가 갱신 후보로 잡힙니다. 넣은 날과 점검한 날은 log.md에 한 줄씩 남깁니다.5-6. 분기에 한 번 AI에게 점검 시키기
문서가 늘면 서로 어긋나기 시작합니다. 같은 대상을 두고 페이지마다 다른 말을 하거나, 어디에서도 이어지지 않는 문서가 생깁니다. 그래서 분기에 한 번 점검을 시킵니다.
그러면 모순, 오래된 내용, 그렇게 고립된 문서, 본문에 자주 나오는데 페이지가 없는 개념, 깨진 링크가 목록으로 나옵니다. 사람이 직접 하면 미루게 되는 일이라 AI에게 맡깁니다.
6. 마치며
지금까지 위키를 근거로 AI를 활용하여 초기 기술 기획안을 짜고, 바이브 코딩으로 화면까지 만들어 봤습니다. 그 과정에서 느낀 것을 3가지로 적었습니다.
6-1. 제가 만든 것은 초안까지입니다
AI에게 말로 지시해 프로그램을 만드는 바이브 코딩 덕분에, 생각만 하던 것을 직접 만들 수 있는 시대가 되었습니다. 통합관제 홈과 Cost Advisor도 그렇게 만들었습니다. 다만 이 방식으로 할 수 있는 일에는 한계가 분명합니다.
내부에서 개인 혹은 조직원 간에 사용 가능한 프로그램을 만드는 것은 가능하겠지만, 시판되는 솔루션 제품은 성능과 보안, 확장성, 장애 대응까지 함께 설계해야 합니다. 성능·보안 설계는 오래 쌓인 경험이 있어야 하는 전문 영역입니다. 그 때문에 제가 바이브 코딩으로 만든 프로그램은 초안에 불과하며, 개발 조직의 검토와 최종 개발이 필요합니다.
6-2. AI를 쓸수록 도메인 지식이 더 필요했습니다
3개 프로젝트 모두 무엇을 만들지, 그것을 어떻게 편리하게 만들지 정하는 데 시간이 가장 많이 들었습니다.
- exemONE 통합관제 홈 인프라 운영자 관점에서 어떤 정보를 먼저 보여줘야 하는지, 그 화면이 어떻게 동작해야 하는지
- AWS Cost Advisor 클라우드 운영자가 비용을 볼 때 무엇을 궁금해하는지, 그 물음에 화면이 어떻게 답해야 하는지
- PostgreSQL RCA 흔한 장애를 어떤 신호의 조합으로 나눌지, 각 조합에서 무엇을 원인으로 보고 어떤 조치를 낼지
3가지 모두 기반 지식이 있어야 가능하고, 그 깊이와 아이디어가 결과물의 질을 좌우합니다.
AI가 일상으로 다가오기 시작할 때 많은 고민을 했습니다. AI 시대에 내 역할은 무엇이고, 어디에 시간을 더 써야 하는가. 한동안은 AI에게 일을 시키는 요령을 익히는 데 시간을 많이 썼습니다. 그런데 그때 익힌 요령 상당수는 AI가 개선되면서 덜 중요해졌습니다.
제가 신경 써야 하는 일은 3가지로 좁혀졌습니다.
- 도메인 지식을 근거로 어떤 순서로 기획을 끌고 갈지 정하는 일
- 말로만 오가던 업무 절차를 화면과 데이터의 순서로 옮겨 프로그램으로 구현할 수 있는 형태로 짜는 일
- AI가 만들어 낸 절차와 데이터가 이 도메인에서 맞는 것인지 가려내는 일
업무는 대개 사람 머릿속에 흐릿한 순서로만 있습니다. 화면 어디에 무엇을 놓을지, 어떤 데이터를 어느 시점에 불러올지까지 정해 놓으면 그다음 구현은 AI가 해 줍니다.
다만 AI는 우리 환경에 없는 지표와 쓸 수 없는 화면도 얼마든지 만들어 냅니다. AI가 내놓은 것 가운데 무엇이 실제로 쓸 수 있는 것인지는 그 업무를 아는 사람이 봐야 알 수 있습니다. 그래서 AI를 쓸수록 사람의 몫이 오히려 분명해집니다.
6-3. 제 지식과 경험을 익힌 위키가 그 판단을 돕습니다
지식이 머릿속에만 있으면 필요할 때마다 다시 설명해야 합니다. 위키에 정리해 두면 AI가 그것을 먼저 읽고 판단합니다. 제가 아는 것이 근거가 되니, 나오는 답도 제가 생각하는 방향에 가까워집니다.
그러니 무엇을 만들지 정할 때도, 새로운 안을 떠올릴 때도 쌓아 둔 지식이 판단의 재료가 됩니다. 4장의 화면 초안과 판단 로직이 그렇게 나왔습니다. 설명을 줄이려고 시작한 일인데, 결과적으로는 위키가 제 판단 기준을 대신 보관하게 됐습니다.
위키는 그렇게 쌓은 도메인 지식을 한 번 쓰고 끝내지 않게, 다음 일에서 다시 활용하고 그 위에 계속 축적할 수 있게 해 주는 장치였습니다. 맥락을 자산으로 남겨 두고, AI가 내놓은 결과를 도메인 지식으로 판별하는 일이 제 몫으로 남았습니다. 매번 다시 설명하던 시간을 줄인 만큼, 그 판단에 시간을 쓰고 있습니다.
출처
LLM Wiki: A pattern for building personal knowledge bases using LLMs - Andrej Karpathy What Is Andrej Karpathy’s LLM Wiki? - MindStudio (2026.07.22)
함께 보면 좋은 아티클
