[뽀둥이 AX ⑤] 한눈에 보는 기억 지도, 해골 하나를 따라가 봤어요

📝 한줄 요약

이 시리즈 제목의 AX는 AI Transformation, 그러니까 "AI로 일하는 방식을 바꾸는 것"을 말해요. 지피터스 사내에서 제가 직접 겪은 기록이에요.

뽀둥이의 기억은 텍스트 파일 수백 개로 흩어져 있어요. 그걸 점과 선의 지도로 그려서 인터넷에 공개해뒀어요. 2026년 8월 27일 오전 기준 노드 757개, 엣지 1,895개예요. 그리고 그 지도가 띄워둔 해골 표시 하나를 뒤늦게 따라가 봤더니, 한 달 전에 만든 규칙이 적용 대상 0건으로 헛돌고 있었어요.

바쁘시면 이것만:

텍스트 파일이 수백 개가 되면 사람 눈으로는 구조가 안 보여요. 지도는 "예뻐서"가 아니라 안 보이던 걸 보려고 그려요
지도가 보여준 첫 장면은 자랑거리가 아니라 아무 엣지도 없는 고아 노드 192개였어요
그걸 링크로 메우고 싶은 유혹이 제일 위험했어요. 숫자만 예뻐지고 검색은 그대로거든요
규칙을 만든 것과 그 규칙이 실제로 작동하는 건 다른 일이에요. 저는 한 달 동안 착각했어요

📝 지난 이야기, 그리고 이번 주제

④편에서는 뽀둥이가 스스로를 고치는 자동 작업에 관문 네 개를 세운 이야기를 했어요. 그리고 그 글을 쓰다가 자가진화가 10일째 멈춰 있었다는 걸 발견했죠. 게이트는 완벽하게 일했는데 막혔다는 사실을 알려주는 경로가 없었어요.

거기서 배운 게 이거였어요. 기록을 남기는 것과 알려주는 것은 다른 일이다.

이번 편은 그 이야기의 연장선이에요. 뽀둥이의 기억은 지금까지 ①편의 교훈 카드, ②편의 폴더 구조, ③편의 검색, ④편의 안전장치로 나눠서 봤는데, 이것들은 실제로는 서로 링크로 이어져 있어요. 그 연결 전체를 한 장으로 펼쳐서 인터넷에 공개해둔 게 이번 편의 주제예요. 그리고 요즘 자주 들리는 AI 용어 다섯 개도 그 지도 위에서 같이 정리할게요.

🗺️ 뽀둥이의 메모리 지식구조 한눈에 보기

처음 오신 분을 위한 30초 지도예요. 매 편 상단에 이 지도를 똑같이 두고, 그 편에서 다루는 곳에 ★를 찍어둘게요. 뽀둥이의 기억은 전부 폴더 속 텍스트 파일이고, 크게 여섯 부분이 맞물려 돌아가요.

책상 (자동 로드 문서) — 매 대화 시작 때 자동으로 읽는 정체성·규칙·현재 요약본·최근 기록 (②편)
서랍·창고 (일별 기록·아카이브) — 하루하루의 작업과 실패 기록, 14일 지나면 자동 보관 (②편)
교훈 카드 + 매뉴얼 위키 — 사고의 교훈을 담은 카드와, 반복 검증된 정본 규칙 (①·②편)
검색 엔진 — 수백 장 기억에서 필요한 것만 골라 꺼내는 색인·검색 (③편)
안전장치 (게이트) — 자동화가 사고 치지 않게 막는 검증·잠금·롤백 (①·④편)
지식그래프 ★ — 이 모든 연결을 한 장으로 보여주는 공개 지도 (⑤편)

이번 ⑤편은 ★ 찍힌 6번, 그러니까 "흩어진 기억을 한 장으로 보면 뭐가 보이는가"를 다뤄요.

🎬 장면: 지도에 해골이 하나 있어요

지도에는 건강 상태를 보여주는 탭이 있어요. 지금 열어도 거기에 해골 표시(💀)가 하나 있어요.

그 하나는 환불 정책 문서의 구버전이에요. 새 버전이 나왔을 때 구버전에 "이건 이제 폐기"라는 표시를 붙여둔 문서죠. 지도는 그 표시를 읽고 해골을 띄워요. 여기까지는 설계한 대로 작동하는 거예요.

이 화면은 계속 거기 있었어요. 그런데 저는 아무 생각도 안 했어요.

해골이 하나뿐이라는 게 왜 이상한 신호인지, 그때는 몰랐거든요. 그걸 알게 된 건 한참 뒤에, 지도와 아무 상관 없는 작업을 하다가였어요.

🤔 그런데 왜 '지도'까지 만들어야 했을까

솔직히 처음엔 저도 이걸 왜 만드나 싶었어요. 검색이 잘 되면 됐지, 그림이 왜 필요한가요?

그런데 ②편에서 본 것처럼 뽀둥이의 기억은 폴더 속 텍스트 파일이에요. 파일이 100개일 때는 폴더 목록만 봐도 감이 와요. 300개가 넘어가면 안 와요. 지금은 757개고요.

벽 1 — 폴더는 배치일 뿐 의미가 아니에요. 같은 폴더에 있다고 관련 있는 게 아니고, 다른 폴더에 있다고 무관한 것도 아니에요. 실제 관계는 문서끼리 걸어둔 링크에 있는데, 그 링크는 파일을 하나씩 열어봐야 보여요.

벽 2 — 안 쓰이는 기억이 안 보여요. 열심히 써놨는데 아무도 안 가리키고 아무 데도 안 걸린 문서가 있어요. 파일 목록에서는 다른 문서와 똑같이 생겼어요. 지도에서는 혼자 떨어져 있는 점으로 한눈에 보이고요.

벽 3 — 편중이 안 보여요. 특정 문서에 링크가 몰려 있으면 그게 병목이에요. 그 문서가 틀리면 딸린 판단이 전부 흔들리거든요. 이것도 세어보기 전엔 몰라요.

그래서 지도를 그렸어요. 예쁘게 보이려고가 아니라 폴더 목록으로는 절대 안 보이는 세 가지를 보려고요.

🏗️ 지도는 이렇게 만들어져요

구조 자체는 단순해요. 세 단계예요.

1단 · 점 찍기 — 문서 하나가 점 하나예요. 이 점을 노드(node)라고 불러요. 폴더 위치·마지막 수정일·글 길이 같은 정보를 노드에 달아둬요
2단 · 선 잇기 — 문서 A가 문서 B를 가리키면 A에서 B로 선을 그어요. 이 선은 엣지(edge)라고 하고요
3단 · 자동 갱신 — 5분마다 바뀐 게 있는지 확인하고, 바뀌었을 때만 다시 그려서 웹에 올려요. 이렇게 주기적으로 확인하는 걸 폴링(polling)이라고 불러요

여기서 조금 더 들어가면 재밌는 게 있어요.

엣지가 두 종류예요 — 본문 링크와 프론트매터 관계

문서를 이어주는 방법이 두 가지예요.

하나는 본문 안에서 그냥 다른 문서를 가리키는 링크예요. 글을 쓰다가 "이건 저기에 자세히 있어요" 하고 거는 거죠. 1,325개예요.

다른 하나는 문서 맨 위에 붙이는 머리말에 적는 관계 표시예요. 이 머리말을 프론트매터(frontmatter)라고 불러요. "이 문서의 상위는 무엇", "이건 무엇에서 나왔다" 하는 식으로 적고, 570개예요. 프론트매터 관계는 그냥 참조가 아니라 방향과 의미가 있는 엣지예요.

둘을 구분하는 이유는, 지도에서 길을 찾을 때 의미 있는 엣지를 먼저 따라가야 하기 때문이에요. 본문 링크는 "지나가다 언급"일 수 있지만 프론트매터 관계는 제가 의도적으로 선언한 거니까요.

건강 상태를 기계가 판정해요

지도를 그리기만 하면 결국 안 보게 돼요. 그래서 절대 깨지면 안 되는 조건 7개를 정해두고 매번 자동으로 검사해요. 이렇게 "항상 참이어야 하는 조건"을 불변식(invariant)이라고 불러요.

불변식 일곱 개는 예를 들면 이런 것들이에요. 존재하지 않는 노드를 가리키는 엣지가 있으면 안 돼요. 같은 재료로 다시 그렸을 때 다른 그림이 나와도 안 되고요. 지도 파일이 오래돼도 안 돼요.

일곱 개를 다 통과하면 여기에 점수를 매겨요. 8월 27일 기준 100점, 전부 통과예요. 다만 이 점수는 뒤에서 이야기할 함정을 하나 품고 있어요.

📊 지도를 열면 뭐가 보이나

이제 실제 숫자예요. 전부 2026년 8월 27일 오전 11시 57분 기준이고요.

노드 757개 · 엣지 1,895개 — 문서 757개가 1,895번 서로를 가리켜요 (본문 링크 1,325 + 프론트매터 관계 570)
영역별로는 일별 기록이 가장 많고, 그다음이 프로젝트, 스킬, 위키 순이에요
가장 많이 참조되는 문서는 자동화 운영을 총괄하는 문서인데, 링크 85개가 걸려 있어요
그런데 그 최대 허브가 전체 연결의 4.5%밖에 안 돼요

마지막 숫자를 조금 설명할게요. 링크가 유난히 많이 몰린 노드를 허브(hub)라고 부르는데, 한 노드에 지나치게 몰리면 위험해요. 그 문서가 틀리는 순간 딸린 판단이 전부 흔들리니까요. 그래서 가장 큰 허브가 전체의 몇 퍼센트를 차지하는지를 따로 재고, 넘치면 경고가 뜨게 해뒀어요.

4.5%면 지금은 괜찮아요. 다만 이건 제가 잘 설계해서가 아니라 문서가 여러 갈래로 자라준 결과에 가까워요. 자랑하기엔 이른 숫자예요.

이 숫자들은 쓰는 사이에도 움직였어요

앞에서 "5분마다 확인하고 바뀌면 다시 그린다"고 했잖아요. 그게 지금 이 순간에도 돌고 있어요.

이 글을 쓰면서 숫자를 처음 쟀을 때는 노드가 755개였어요. 원고를 고치는 사이에 757개가 됐고요. 이 원고 자체가 워크스페이스에 있는 문서라서, 제가 글을 쓰는 행위가 지도를 바꾸고 있었던 거예요.

그래서 위 숫자는 특정 순간의 스냅샷 하나를 떠서 고정한 값이에요. 여러분이 지도를 여는 시점에는 다를 거고요. 살아 있는 지도의 숫자를 글에 적으려면 "언제의 값인지"를 같이 적는 수밖에 없더라고요.

💥 고아 노드 192개를 링크로 메우고 싶었어요

지도를 처음 펼쳤을 때 제일 먼저 눈에 들어온 건 이거였어요. 757개 중 192개가 본 덩어리에 안 이어져 있었어요. 넷 중 하나가 섬처럼 떠 있던 거죠. 이렇게 아무 엣지도 없는 노드를 고아 노드(orphan node)라고 불러요.

솔직한 첫 반응은 "고아 노드를 다 이어야겠다"였어요. 링크를 몇 개만 걸면 숫자가 확 좋아지겠더라고요.

그런데 그게 바로 하면 안 되는 일이었어요.

링크로 메우면 지도는 예뻐지고 검색은 그대로예요

링크는 "실제로 관련 있다"는 신호예요. 숫자를 좋게 만들려고 억지로 걸면 그 신호가 거짓말이 돼요. 게다가 앞에서 봤듯이 이 링크는 검색 신호로도 쓰여요. 가짜 링크를 걸면 검색 결과까지 같이 오염돼요.

측정값을 목표로 삼으면 그 측정값이 망가지는 현상을 굿하트의 법칙(Goodhart's law)이라고 부르는데, 딱 그 상황이었어요. 저는 지도를 좋게 만들 수 있었지, 기억을 좋게 만들 수 있는 게 아니었어요.

그래서 잇는 대신 분류했어요

고아 노드 192개를 열어봤더니 종류가 달랐어요.

주기적으로 쌓이는 운영 로그 83개 — 매번 새로 생기는 기록이라 링크가 안 붙어요
등록부 성격 문서 68개 — 목록에서 찾아 쓰는 물건이라 다른 문서가 가리킬 이유가 없어요
보관 문서 35개 — 14일 지나 창고로 옮겨진 일별 기록 중 링크가 완전히 끊긴 것들이에요. 보관 문서 자체는 140개인데 그중 35개만 여기 해당해요
그리고 진짜 문제 6개 — 어디에도 안 걸렸고 왜 그런지 설명도 안 되는 문서요

넷을 더하면 192예요. 진짜 개선 대상은 마지막 6개뿐이었어요. 전체 노드의 0.8%죠. 고아 노드 192개를 다 이으려던 계획은 186개가 헛수고였을 뻔했어요.

그런데 이 분류 자체가 또 함정이에요

여기서 한 겹 더 있어요. 분류는 공짜로 숫자를 좋게 만들 수 있는 수단이거든요. 곤란한 문서를 "이건 원래 안 이어져도 되는 종류"로 옮기면 문제 숫자가 줄어요. 코드는 한 줄도 안 고치고요.

그래서 판정할 때 설명 안 되는 고아 노드 비율과 전체 고아 노드 비율을 항상 같이 봐요. 앞 숫자만 보면 재분류로 얼마든지 숨길 수 있는데, 뒤 숫자는 안 줄거든요. 지금은 앞이 0.8%, 뒤가 25%예요.

💡 여기서 배운 것 — 지표를 만들면 그 지표를 속이는 가장 싼 방법을 같이 적어두는 게 좋아요. 저희 경우엔 "링크 스팸"과 "재분류"였고, 둘 다 막는 데 든 비용은 숫자 하나를 나란히 표시한 게 전부였어요.

🔍 해골 하나를 따라가 보니 규칙이 헛돌고 있었어요

이제 장면으로 돌아갈게요. 폐기 표시가 붙은 문서가 전체에 하나뿐이던 그 일이요.

규칙은 이랬어요. 틀렸다고 판명된 문서는 지우지 않고 폐기 표시를 붙인다. 그러면 검색에서 순위가 절반으로 깎인다. 이렇게 지우는 대신 순위만 낮추는 걸 강등(superseded)이라고 불러요. 지우지 않는 이유는 "그때 왜 그렇게 판단했는지"가 나중에 필요하기 때문이에요. 한 달쯤 전에 만든 규칙이었고, 저는 강등이 잘 돌아가고 있다고 생각했어요.

붙잡은 계기는 지도가 아니었어요. 전혀 다른 작업이었어요.

검색 설정을 하나 켜봤는데, 아무 차이가 없었어요

검색을 조금 더 개선해보려고 설정을 하나 켜봤어요. 문서끼리 걸린 프론트매터 관계를 타고 가서 강등 판정을 한 겹 더 반영하는 기능이었어요. 켜기 전과 켠 뒤를 나눠서, 실제로 뽀둥이한테 던졌던 질문 53개로 네 가지 방식으로 정확도를 쟀어요.

완전히 똑같았어요. 네 지표 전부 소수점까지 같았고, 상위 3개 결과의 순서까지 동일했어요.

보통 이럴 때 "효과가 미미하네" 하고 넘어가요. 그런데 소수점까지 똑같은 건 좀 이상하잖아요. 미미한 게 아니라 아예 아무 일도 안 일어난 것처럼 보였거든요.

세어보니 대상이 0건이었어요

그래서 이 기능이 무엇을 근거로 판단하는지 거슬러 올라갔어요. 관계를 타고 가려면 "이 문서가 저 문서를 대체한다"는 관계, 그러니까 대체 관계(supersedes)가 걸려 있어야 해요. 그런데 대체 관계가 전역에 0건이었어요. 타고 갈 엣지가 없으니 차이가 날 리가 없었죠.

여기까지 왔으면 멈출 수 있었는데, 겸사겸사 원래 규칙 쪽도 세어봤어요. 그리고 더 나쁜 걸 발견했어요.

폐기 표시가 붙은 문서는 정말로 하나뿐이었어요. 장면에서 본 그 해골이요. 그런데 그 하나마저 색인 범위 밖에 있었어요.

뽀둥이 검색은 모든 폴더를 뒤지지 않아요. 자주 쓰는 영역만 색인해두고, 그 영역을 색인 범위라고 불러요. 그 해골 문서는 색인 범위 밖에 있었어요. 그러니까 강등의 실제 적용 대상이 0건이었던 거예요.

기능이 고장 난 게 아니에요. 코드는 멀쩡히 작동해요. 깎을 문서가 없었을 뿐이에요. 저는 한 달 동안 "틀린 기록은 강등돼서 뒤로 밀린다"고 믿고 일했고, 그동안 밀려난 문서는 하나도 없었어요.

확인된 원인은 두 가지였어요

기록에 남은 직접 원인은 둘이에요. 둘 다 "깎는 기능이 고장 났다"가 아니라 "깎을 입력이 없었다" 쪽이에요.

하나. 폐기 표시가 붙은 유일한 문서가 색인 범위 밖에 있었어요. 그러니 강등할 대상이 0건이었죠.

둘. 관계를 타고 가는 쪽도 대체 관계가 0건이었어요. 하나도 안 걸려 있었으니 타고 갈 엣지가 없었고요.

여기서 한 걸음 더 들어가면 "그럼 왜 표시가 하나밖에 안 붙었나"가 남는데, 이건 제가 측정한 게 아니라 짐작이에요. 실무에서 틀린 기록을 만나면 표시를 붙이기보다 그냥 맞는 내용으로 고치게 되거든요. 그게 빠르니까요. 그러면 틀렸던 흔적이 안 남고 표시를 붙일 일도 안 생겨요. 확인된 사실이 아니라, 제 행동을 돌아보며 세운 가설로 적어둘게요.

세는 방법도 두 번 틀렸어요

이 과정에서 제가 두 번 잘못 셌어요. 둘 다 같은 종류의 실수였고요.

첫 번째. 대체 관계가 0건이라고 했는데, 처음 세었을 땐 3건으로 보였어요. 그런데 그 3건은 실제 관계가 아니라 규약을 설명하는 문서에 제가 예시로 적어둔 문장이었어요. 세는 프로그램이 예시와 실제를 구분 못 하고 같이 센 거죠. 가리키는 대상 문서조차 없는 가짜였어요.

두 번째. 그 전에 저는 "폐기 표시를 붙여야 하는데 안 붙인 문서가 3건 있다"고 보고한 적이 있어요. 이것도 틀렸어요. 문서 전체에서 표시 문구를 단순 검색해서 센 결과였는데, 그 검색에 규칙을 정의한 문서 자신이 걸렸어요. 판정 담당 프로그램을 직접 불러서 물어보니 후보 0건이었고요.

단순 검색으로 센 숫자는 설명하는 문서와 실제 사례를 구분하지 못해요. 규칙을 설명한 글이 그 규칙의 위반 사례로 잡히는 일이 실제로 일어나요.

💡 여기서 배운 것 — 규칙을 만들면 "지금 이 규칙에 걸리는 게 몇 건인가"를 반드시 세어봐야 해요. 0건이면 규칙이 없는 것과 같으니까요. 셀 때는 단순 검색 말고 정본 판정기를 직접 불러야 하고요. 저는 만든 걸로 끝냈고 한 달을 착각으로 보냈어요. ④편에서 "기록과 알림은 다른 일"이라고 썼는데 이번 건은 한 칸 더 앞이에요. 만드는 것과 작동하는 것도 다른 일이에요.

🔒 공개의 대가 — 이름이 지도에 찍히면 안 되니까

이 지도는 인터넷에 공개돼 있어요. 누구나 열어볼 수 있게요. 그게 이 시리즈를 쓰는 이유이기도 하고요.

그런데 공개하려니 문제가 하나 있었어요. 폴더 이름에 사람 이름이 들어 있어요.

웨비나 프로젝트 폴더는 회차랑 연사분 성함으로 이름을 지어뒀거든요. 안에서 일할 때는 그게 제일 편해요. 그런데 지도에 그대로 찍히면 연사분 성함이 인터넷에 노출되는 거예요.

지우는 게 아니라 별칭(alias)으로 접었어요

원래 폴더 이름은 안 바꿨어요. 그건 실무의 정본이니까요. 대신 지도로 내보낼 때만 날짜 기준의 다른 이름으로 바꿔서 내보내요. 이렇게 원본은 두고 겉으로만 다르게 부르는 이름을 별칭(alias)이라고 해요. 안에서는 원래 이름, 밖에서는 날짜만 보이는 거죠.

여기에 ④편에서 이야기한 원칙을 하나 붙였어요. 검사에 실패하면 그냥 넘어가는 게 아니라 아예 멈추는 방식인데, 이걸 fail-closed라고 불러요. 별칭으로 바꾸는 데 실패하면 지도를 안 만들고 멈춰요. 이름이 노출된 채로 올라가는 것보다 지도가 하루 안 갱신되는 게 훨씬 낫거든요.

실제로 조건을 꽤 빡빡하게 걸어뒀어요. 날짜가 없어서 별칭을 못 만드는 폴더가 새로 생기면 그 자리에서 멈춰요. 하위 폴더로 옮겨 놓은 것까지 따라가서 확인하고요. 처음엔 직속 폴더만 봤는데, 보관 폴더로 옮기면 검사를 빠져나간다는 걸 발견하고 고쳤어요.

💡 여기서 배운 것 — 내부용으로 만든 걸 공개하려면 "안에서는 편한데 밖에서는 안 되는 것"을 먼저 찾아야 해요. 저희는 그게 폴더 이름이었어요. 그리고 이런 검사는 실패했을 때 멈추게 해두는 편이 안전해요. 통과 못 하면 그냥 넘어가는 검사는 없는 것과 같아요.

🔤 지도 위에서 정리하는 요즘 AI 용어 다섯 개

여기까지 지도를 만들고 읽고 세 번 데인 이야기를 했어요. 그런데 이 과정에 나온 것들에는 이미 이름이 붙어 있어요. AI 이야기에서 계속 들리는데 정작 뭔지 설명하기는 애매한 말들이요. 지금까지 본 것들로 다섯 개를 정리하고 갈게요. 전부 이 글에 실물이 나온 것들이에요.

1. 지식그래프 (knowledge graph)

지금 보고 있는 이 그림 자체예요. 정보를 문서 단위로 쌓는 대신 점(무엇)과 선(어떤 관계)으로 표현한 것을 지식그래프라고 불러요. 검색이 "이 단어가 든 문서"를 찾는다면, 그래프는 "이것과 이어진 것"을 따라갈 수 있어요.

거창해 보이지만 뽀둥이 지도는 별도 데이터베이스 없이 마크다운 파일에 걸린 링크를 세어서 만들어요.

2. 온톨로지 (ontology)

"우리는 세상을 어떤 종류로 나누고, 그 종류끼리 어떤 관계를 인정할 것인가"를 정해둔 규약이에요. 말이 어려운데 뽀둥이한테는 아주 구체적인 물건이에요.

문서마다 종류를 붙여요. 사람·도구 같은 명사인지, 운영 노하우 같은 동사인지, 시점 사건 기록인지, 종합 분석인지요. 관계 어휘도 정해뒀어요. 아무 말이나 관계 이름으로 쓰면 검사에서 걸려요.

이걸 왜 정하냐면, 종류가 없으면 검색이 "무엇을 우선할지" 판단할 근거가 없기 때문이에요. 사건 기록은 시간이 지나면 낡지만 정본 매뉴얼은 안 낡거든요. 같은 취급을 하면 안 돼요.

3. RAG (Retrieval-Augmented Generation)

③편에서 한 번 나왔는데 다시 짧게 풀면, 답을 만들기 전에 관련 문서를 먼저 찾아서 AI한테 같이 넣어주는 방식이에요. AI가 아는 것만으로 답하지 않고, 검색 결과를 근거로 답하게 하는 거죠.

여기서 흔한 오해가 하나 있어요. RAG는 흔히 벡터 검색과 한 몸처럼 이야기되는데, RAG의 R은 그냥 '찾기'예요. 어떻게 찾을지는 자유고요. 뽀둥이는 ③편에서 본 것처럼 벡터 임베딩(vector embedding)을 붙였다가 껐어요. 지금은 다섯 신호를 합쳐서 찾고요. 흔한 단어는 낮게 드문 단어는 높게 치는 BM25, 최신성(recency), 그래프, 제목 매칭, 사용 이력(usage)이에요.

그 다섯 중 세 번째가 바로 이 지도예요. 링크를 많이 받는 문서를 조금 위로 올려주는 신호로 쓰거든요. 지도는 보기 좋으라고만 있는 게 아니라 검색 부품이기도 해요.

4. 프로버넌스 (provenance)

이 정보가 어디서 왔는지 추적할 수 있게 남겨두는 것을 프로버넌스라고 해요. 원래 미술품 소장 이력을 뜻하던 말인데 데이터 쪽에서 그대로 쓰고 있어요.

AI 메모리에서는 이게 생각보다 급해요. 뽀둥이가 남긴 기록에는 직접 확인한 사실과 어디서 전해 들은 말과 추측이 섞여요. 구분 없이 쌓이면 다음 작업이 추측을 근거로 돌아가요.

그래서 규칙을 뒀어요. 외부에서 온 정보는 출처를 붙이고, 직접 확인 못 한 건 미확인 표시를 하고, 틀렸다고 판명되면 폐기 표시를 붙여 강등(superseded)해요. 해골이 바로 그 폐기 표시고요. 앞에서 한 달을 착각으로 보낸 그 사고가 정확히 이 규칙에서 났어요. 프로버넌스는 설계해두는 것만으로는 안 되고, 실제로 표시가 붙는지까지 봐야 작동한다는 걸 그때 배웠어요.

5. 컨텍스트 엔지니어링 (context engineering)

②편에서 한 번 나왔죠. AI가 한 번에 읽을 수 있는 양이 정해져 있으니, 그 한정된 자리에 무엇을 넣을지 설계하는 일이에요.

지금까지 ①~⑤편이 사실 전부 이 이야기예요. 무엇을 항상 읽힐지(②편 책상), 무엇을 그때그때 찾아 넣을지(③편 검색), 무엇을 못 건드리게 할지(④편 게이트), 그리고 그 전체가 어떻게 이어져 있는지(⑤편 지도)요.

💡 여기서 배운 것 — 이 다섯 개는 서로 다른 기술이라기보다 한 문제를 다른 각도에서 부르는 이름에 가까워요. "AI한테 무엇을 알려줄 것인가"라는 문제를 저장 구조로 풀면 지식그래프, 분류 규약으로 풀면 온톨로지, 꺼내는 방법으로 풀면 RAG, 믿을지 말지로 풀면 프로버넌스, 그 전체를 한정된 자리에 어떻게 담을지로 풀면 컨텍스트 엔지니어링이에요. 깔끔한 5층 구조라기보다 서로 겹쳐 있는 관점들이에요.

💡 따라 하실 분을 위한 팁 세 가지

지도는 자랑용이 아니라 검사용으로 그리세요 — 처음 펼치면 예상보다 지저분해요. 그게 정상이고 그걸 보려고 그리는 거예요. 저는 첫 화면에서 고아 노드 192개를 봤고, 그중 진짜 문제는 6개였어요. 지저분함을 감추는 방향으로 손대기 시작하면 그때부터 지도가 거짓말을 해요

규칙을 만들 때마다 "지금 몇 건 걸리나"를 세어보세요 — 이번 편에서 제가 제일 크게 데인 부분이에요. 운영하던 규칙 하나는 깎을 대상이 0건이었고, 켜볼까 검토하던 실험 기능 하나는 타고 갈 입력이 0건이었어요. 둘은 급이 다르지만 공통점이 있어요. 둘 다 세어보기 전까지는 몰랐다는 거예요. 특히 "사람이 표시를 붙여야 작동하는 규칙"은 0건에 가까울 수 있다고 의심하세요

지표를 만들면 그 지표를 속이는 방법도 같이 적어두세요 — 저희 지도는 "고아 노드를 줄이자"가 목표인데, 링크를 억지로 걸거나 분류를 바꾸면 코드 한 줄 안 고치고 숫자가 좋아져요. 그래서 속이기 어려운 숫자를 옆에 나란히 뒀어요. 비용은 숫자 하나 더 표시한 게 전부였고요

❓ 이런 게 궁금하실 것 같아요

Q. 문서가 몇 개쯤 되면 지도를 만들 만한가요?

제 체감으로는 100개 넘어가고, 문서끼리 서로 링크를 걸고 있을 때예요. 링크가 없으면 점만 잔뜩 흩어진 그림이 나와서 볼 게 없어요. 반대로 말하면 지도보다 문서에 링크를 거는 습관이 먼저예요. 저도 링크를 걸어온 게 먼저였고 지도는 나중이었어요.

Q. 지식그래프를 만들려면 전용 데이터베이스가 필요한가요?

저희는 안 썼어요. 마크다운 파일에 걸린 링크를 세어서 그리는 게 전부예요. ③편에서 벡터 데이터베이스를 재보고 껐던 것과 같은 이유예요. 이 규모에서는 필요가 없었어요. 문서가 수만 개가 되거나 여러 사람이 동시에 쓰면 결론이 달라질 수 있는데, 그건 제가 재본 게 아니라 가설이에요.

Q. 공개해두면 회사 내부 정보가 새는 것 아닌가요?

문서 제목과 연결 구조만 나가고 본문 내용은 안 나가요. 그리고 앞에서 이야기한 것처럼 사람 이름이 든 폴더는 별칭으로 접어요. 그래도 완전히 안전하다고는 말 못 해요. 제목만으로 짐작되는 것도 있으니까요. 그래서 공개 범위는 계속 보수적으로 잡고 있어요.

Q. 건강 점수 100점이면 완벽한 상태인가요?

아니에요. 이번 편이 그 증거예요. 점수는 100점인데 그 안에서 운영하던 강등 규칙은 대상이 0건이었고, 검토하던 실험 기능도 입력이 0건이었어요. 점수는 "정해둔 조건을 어겼는가"를 볼 뿐이고 애초에 조건으로 안 세운 건 못 봐요. 저는 이 점수를 "문제가 없다"가 아니라 "정해둔 종류의 문제는 없다"로 읽으려고 해요.

🚀 다음 편 예고 — ⑥ 아직 안 되는 것들

여기까지 다섯 편에 걸쳐 기억·구조·검색·안전장치·지도를 봤어요. 그런데 매 편 실패담을 하나씩 붙여온 데는 이유가 있어요. 아직 안 되는 게 많거든요.

마지막 편에서는 지금도 못 풀고 있는 한계들, 그리고 "이걸 처음부터 다시 만든다면 어디부터 시작할까"를 이야기할게요. 다섯 편을 다 만들 필요는 없어요. 작게 시작하는 순서를 정리해서 마무리할게요.

📋 재사용 가능한 프롬프트

프롬프트: 내 문서들의 연결 상태 점검하기

내 작업 폴더의 문서들이 서로 어떻게 연결돼 있는지 점검해줘. 순서대로 진행해:
① 문서마다 다른 문서를 가리키는 링크가 몇 개인지, 반대로 몇 개한테서 링크를 받는지 세어줘
② 아무 링크도 받지 못한 문서 목록을 뽑아줘
③ ②의 목록을 "원래 안 이어져도 되는 것"과 "이어져야 하는데 빠진 것"으로 나눠줘
   — 이때 어떤 기준으로 나눴는지 먼저 알려주고, 내가 동의하면 진행해
④ 링크를 가장 많이 받는 문서 상위 5개와, 그게 전체의 몇 %인지 알려줘
아직 아무것도 고치지 마. 링크를 새로 거는 것도 하지 마.

프롬프트: 내가 만든 규칙이 실제로 작동하는지 세어보기

내가 너한테 준 규칙들 중에서 "특정 표시나 조건이 붙은 대상에만 적용되는 규칙"을 전부 찾아줘.
각각에 대해 아래를 표 없이 목록으로 알려줘:
① 규칙 내용 한 줄
② 지금 이 규칙에 걸리는 대상이 실제로 몇 건인지 (직접 세어서)
③ 0건이거나 1건이면, 그 표시를 "누가 언제 붙이게 돼 있는지"
④ ③이 사람의 수동 작업이면, 실제로 그 작업이 일어난 기록이 있는지
0건인 규칙이 있으면 지우자고 하지 말고, 왜 0건인지 먼저 알려줘.

🔥<24기 AI 스터디> 블라인드 최저가로 신청하세요 🔥