📝 한줄 요약
구글 타임라인·카카오톡·문자에 흩어져 있던 11.5년치(4,073일) 내 흔적을, AI 코딩 도구로 파싱·통합하고 하루 단위 실록체 기록 3,296편으로 자동 리라이트했습니다. 손으로는 평생 못 쓸 기록이 원클릭 캘린더 앱 안으로 들어왔고, 서로 다른 포맷에 갇혀 있던 조각들이 한 날짜로 엮이는 순간 잃어버린 지난 11년이 되살아났습니다.
바쁘시면 이것만 읽어도 돼요:
뭘 했나: 스마트폰 구글 지도 내보내기(80MB, 290만 줄, 2014~2026)를 파싱해 날짜별 활동일지를 만들고, 여기에 카톡·문자를 엮어 사실/해석을 분리한 '황제실록'체 서술로 자동 변환.
정량 성과: 하루 단위 기록 0건 → 4,073일 자동 생성 + 3,296편 실록 리라이트, 최종 재확인 미처리 0건.
핵심 난관 1 — 데이터: 공식 Takeout은 단 1일치만 줬다. 스마트폰 앱 직접 내보내기로 우회해 11.5년치를 확보.
핵심 난관 2 — 품질: "이동·지출·만난 사람 나열 + 상투적 논평"에 머물던 초기 결과를, 본기(사실)와 사관 논평(해석)을 분리하는 설계로 갈아엎음.
가장 신경 쓴 것 — AI 검증: 날짜·시각·기간·건수·거리·인용을 근거 데이터와 자동 대조하는 검증 로직을 심고, false positive를 여러 차례 잡아냄. AI가 지어낸 숫자를 그냥 믿지 않았다는 게 이 프로젝트의 핵심.
민감정보: 위치·대화·문자·금융성 알림이 원본이라, 처음부터 마스킹·추상화를 파이프라인 기본값으로 박아넣음.
배운 교훈: 개인 데이터 자동화의 승부처는 "생성"이 아니라 "검증과 마스킹"이었다.
🎯 이런 분들께 도움돼요
이 글은 특히 이 두 분을 위해 썼습니다:
흩어진 개인 기록(위치·메신저·문자)을 한데 모아 잃어버린 지난 시간을 되살리고 싶은 분 — 일기를 못 쓰는 사람일수록 효과가 큽니다. 스마트폰은 이미 당신을 몇 년째 기록하고 있으니까요.
AI에게 문서 정리를 맡기고 싶지만 "AI가 지어낸 내용"이 무서워 못 맡기던 분 — 이 글의 절반은 "AI가 뱉은 걸 어떻게 안 믿고 검증했나"에 대한 이야기입니다.
그리고 아래 실무자분들께도 그대로 이식됩니다(→ 🌍 섹션 참고): 개인정보·기밀이 섞인 데이터를 다루거나, "사실"과 "해석"을 분리해 기록해야 하는 분(법률·공공·상담·HR, 경위서·회의록·상담일지 등).
😫 문제 상황 (Before)
저는 일기를 거의 못 씁니다. 그런데 스마트폰은 저 대신 11년 넘게 성실히 기록하고 있었습니다. 문제는 그 기록이 사람이 읽을 수 없는 형태였다는 것.
구글 타임라인 위치 기록은 위경도 숫자 덩어리였고,
카카오톡·문자는 각각 다른 파일 포맷에 갇혀 있었고,
이 모든 게 날짜라는 공통 축으로 엮여 있지 않았습니다.
"11.5년을 하루 단위로 정리한다"는 건 손으로는 사실상 불가능한 작업이었습니다. 4,073일을 하루 10분씩만 정리해도 680시간, 꼬박 넉 달 걸립니다. 그래서 지금까지 아무도(=저도) 손대지 못했고, 그 결과 제 과거는 검색도 회상도 안 되는 죽은 데이터로 남아 있었습니다.
결정적 계기는 어느 날 특정 과거를 되짚어 볼 일이 생겼을 때였습니다. "그게 언제였지, 그날 뭘 했더라"를 확인하려는데, 기록이 없어 아무것도 재구성할 수 없었습니다. 분명 스마트폰 어딘가엔 흔적이 있는데 꺼내 읽을 수가 없다는 그 막막함이, 미루던 일을 시작하게 만든 방아쇠였습니다.
게다가 시간이 제 편이 아니었습니다. 구글이 타임라인 정책을 바꾸면서 서버에 있던 기록은 이미 1일치로 쪼그라들었고(뒤에서 설명), 폰에 남은 11.5년치도 기기를 바꾸거나 잃어버리면 그대로 증발합니다. "지금 안 꺼내면 영영 못 꺼낸다" — 이게 이 일을 더는 미룰 수 없었던 진짜 이유였습니다.
왜 기존 방법으로는 안 됐나 (기존 대안 검토)
구글 공식 Takeout(테이크아웃)을 먼저 받아봤습니다. 그런데 구글이 타임라인을 서버 저장에서 기기 로컬 저장으로 정책을 바꾸면서, 서버 기반 Takeout에는 딱 1일치(2025-07-11~12) 데이터만 들어 있었습니다. 11.5년을 원한 사람에게 하루치는 무의미했죠.
엑셀·수작업 정리는 위에서 계산한 대로 규모 자체가 감당 불가였습니다.
예전에 비슷한 자동 요약을 시도했을 때는 결과물이 "어디 갔고, 얼마 썼고, 누굴 만났다"를 건조하게 나열하고 끝에 상투적 코멘트를 붙이는 수준이라, 다시 읽고 싶은 기록이 아니었습니다.
그리고 이 문제는 자동화·AI에 딱 맞는 성격이었습니다 — 4,073일이 똑같은 패턴의 반복이고, 위경도·시각·상호명 같은 규칙적 데이터이며, 결국 텍스트로 서술하는 일이니까요. 양이 많아 사람이 못 하고, 규칙은 코드가, 서술은 LLM이 잘하는 전형적인 영역이라 "굳이 AI?"가 아니라 "AI가 아니면 불가능"에 가까웠습니다.
즉 문제는 두 겹이었습니다 — ① 데이터를 못 모은다, ② 모아도 읽을 만하게 안 나온다. 이 프로젝트는 이 두 벽을 차례로 넘은 기록입니다.
🛠️ 사용한 도구
도구: Claude Code(파싱·일지 생성 파이프라인 설계), Codex CLI(황제실록 리라이트 백엔드 실행)
왜 나눴나: 한 도구로 다 하지 않았습니다. 정확한 파싱·파이프라인 설계는 Claude Code가, 수천 편의 문체 생성(대량 배치)은 Codex가 각각 더 잘하는 영역이라 판단해 강점을 분담했습니다.
핵심 모델: 리라이트 백엔드는 상위 추론 모델을 reasoning effort를 최고로, 응답은 빠른 티어로 설정해 대량 배치에 맞춤
데이터 소스: 구글 타임라인(스마트폰 내보내기 80.7MB), 카카오톡 대화 JSON, 문자(SMS/MMS) XML
특이사항: 원본이 전부 민감정보라, 마스킹·추상화를 옵션이 아니라 기본값으로 두고 작업
🔧 작업 과정
1막. "하루치가 전부라고?" — 데이터 소스를 갈아탄 순간
처음엔 정석대로 갔습니다. 구글 테이크아웃에서 위치 기록을 받아, 원시 신호(위치 좌표·활동·와이파이 스캔)를 파싱하는 파서를 만들고 SQLite 데이터베이스에 넣었습니다. 파서는 잘 돌았습니다 — 위치 373건, 활동 3,001건이 깔끔하게 적재됐죠.
문제는 결과를 보고 나서였습니다.
날짜 범위를 확인해줘. 데이터가 며칠치나 들어온 거야?
돌아온 답은 "2025-07-11 ~ 07-12, 약 1일치". 구글 정책 변경 때문에 서버 Takeout이 껍데기만 준 것이었습니다. 여기서 포기했다면 이 프로젝트는 없었습니다.
대신 스마트폰 구글 지도 앱에서 직접 내보내기를 시도했더니, 완전히 다른 파일이 나왔습니다.
스마트폰에서 직접 내보낸 타임라인 파일을 확인해줘. 크기랑 기간, 며칠치인지 알려줘.
파일 크기: 80.7MB, 무려 292만 줄
기간: 2014-11-29 ~ 2026-06-28, 약 11.5년
고유 날짜: 4,073일, 총 세그먼트 73,820개(장소 방문 23,518 / 이동 경로 22,468 / 활동 27,679)
요청 → 작업 → 결과 → 배운 점
같은 "구글 타임라인"인데 Takeout판과 스마트폰판은 최상위 키도, 좌표 표기법도 완전히 달랐습니다. Takeout은 정수형 좌표(원시 신호), 스마트폰판은 문자열 좌표(의미 세그먼트: 방문·경로·활동). 그래서 기존 파서를 버리지 않고, 스마트폰 포맷 전용 파서를 새로 만들어 방문·경로·활동을 각각의 테이블로 나눠 담았습니다.
→ 배운 점: 같은 서비스라도 "어느 문으로 데이터를 꺼내느냐"에 따라 양과 형식이 하늘과 땅 차이다. 공식 경로가 막히면 대체 출구를 먼저 의심하라.
2막. 위치·카톡·문자를 '같은 날짜 서랍'에 모으다 — 세 기록의 삼각측량
타임라인만으로는 반쪽짜리였습니다. 구글 타임라인은 "어디에 있었고 얼마나 움직였나"(장소·거리)는 복원했지만, 정작 "거기서 무엇을 했나"는 비어 있었죠. 좌표는 남았는데 이야기가 없었습니다.
그래서 나머지 두 조각을 마저 데려왔습니다.
카톡 대화 내보낸 거랑 문자 내보낸 것도 날짜별로 잘라서 타임라인이랑 같은 날짜에 합쳐줘.
카카오톡 대화기록: 앱에서 대화를 내보내 파일로 저장한 뒤, 날짜별로 잘라(청킹) 정리했습니다.
문자(SMS/MMS): 휴대폰에서 내보내, 역시 날짜별로 분류·청킹했습니다.
핵심은 세 소스를 전부 "같은 날짜 서랍"에 나눠 담았다는 것입니다. 위치도, 대화도, 문자도 하루 단위로 정렬되니, 특정 날짜를 열면 그날의 세 기록이 한자리에 모였습니다.
그러자 서로의 결점이 메워졌습니다.
타임라인은 동선(어디→어디, 몇 km)을 알려주고,
카톡·문자는 그 자리에서 무슨 일이 있었는지(약속·대화·맥락)를 채워주고,
특히 카드결제 알림 문자에는 방문한 상호(가게 이름)가 찍혀 있었습니다.
여기서 결정적인 장면이 나왔습니다. 카드내역의 상호명과 타임라인의 그 시각 동선을 대조하니 "이 시각, 이 좌표에 있었다 = 이 가게였다"가 딱 맞아떨어졌습니다. 서로 다른 출처가 같은 사실을 가리키자, 기록의 신뢰도가 급격히 올라갔습니다. — 이건 곧 소스끼리 서로를 자동 교차검증해준 셈입니다.
요청 → 작업 → 결과 → 배운 점
세 소스를 날짜 축으로 합치자, 좌표 덩어리였던 과거가 "언제·어디서·누구와·무엇을"이 채워진 하루로 복원됐습니다. 옛날에 갔던 장소, 자주 가던 식당, 심지어 해외여행까지 — 잊고 있던 일상이 통째로 실록의 재료가 됐습니다.
→ 배운 점: 한 소스의 빈칸은 다른 소스가 메운다. 위치의 "어디"와 대화·결제의 "무엇"이 만나는 순간 로그는 기억이 되고, 서로 다른 출처가 겹치는 지점(카드 상호 ↔ 타임라인 동선)은 공짜 교차검증이 된다.
3막. AI가 만든 첫 실록을 보고, 설계를 갈아엎다
데이터가 모이자 진짜 목표로 갔습니다 — 이 숫자 덩어리를 읽을 만한 하루 기록으로 바꾸는 것. 컨셉은 '황제실록'이었습니다. 내 하루를 임금의 하루처럼 사서(史書) 문체로 서술하는 것.
그런데 초기 결과물이 딱 "그저 그런 자동 요약"이었습니다. 어디 갔고, 얼마 쓰고, 누굴 만났는지 단순 열거한 뒤 끝에 상투적 논평을 붙이는 식. 여기서 방향을 크게 틀었습니다.
실록을 사실과 해석으로 분리해줘. '본기'에는 근거가 있는 사실만 쓰고, 상상·풍자·통찰·비유는 맨 끝 '사관은 논한다' 논평 문단에만 넣어.
이 한 줄이 결과물의 격을 바꿨습니다.
본기(本紀): 그날의 장소·이동·지출·대화·알림을 근거 기반 사실만으로 서술.
사관은 논한다: 해석·비유·통찰은 오직 여기에만. (기존의 사신은 논한다 표현도 사관은 논한다로 통일)
페르소나: 생존 인물의 실제 문체를 모방하지 않고, 기능적 페르소나만 적용 — 냉정한 앵커형, 문명비평가형, 사마천형, 소설가형.
기록 주체: 나를 항상 상(上)으로만 지칭. 실명, "사용자", 대명사 "그"는 검증으로 차단.
실제로 이렇게 나옵니다 (2024년 어느 하루, 마스킹본):
총 이동 77.6km · 14곳 방문(17시간)
상은 오전 10시 10분 자전거로 나아가 개포로에 이르고, 지하철을 이어 타 종로를 거쳐 11시 36분 서울역사박물관에 들어갔다. 앞서 인물3이 그곳에 있겠다고 알렸고, 상은 짧게 응답하였다.
상은 낮에 스타벅스에 머문 뒤 대성집(미쉐린가이드 도가니탕)에 들렀고, 사직로 골목을 지난 다음 2시간 39분 동안 9.3km를 걸었다. 저녁에는 커피스트와 Wooh Ahh Craft Beer Bar에 들렀으며, 밤에는 지하철과 자전거를 이어 타고 트레이더스 위례점에 갔다가 22시 18분 집에 들었다. 이날 총 이동 거리는 77.6km였다.
금전 기록에는 00시 44분 2,500원 결제 알림이 있고, 인물3과의 사이에 송금·수취 알림이 여러 차례 이어졌다.
통신에는 국군의 날 교통통제 예고, 방문 일정 변경 알림, 등록 사건 알림, 공연 예매 완료 알림이 섞여 있었다. 인물2가 건강·의료에 관한 개인적 사정을 청하였고, 상은 세부를 옮기지 않은 채 문서와 절차의 관점에서 답하였다.
사관은 논한다. 이동은 길고, 알림은 촘촘하며, 돈의 오감도 여러 번 맞추었다. 누가 무엇을 맡고 어디서 확인할 것인가. 절차가 일의 뼈대다.
한 편 안에 설계가 전부 담깁니다 — 본기(사실)는 시각·장소·거리·금액 같은 근거만 서술하고, 해석은 오직 마지막 "사관은 논한다" 한 문단에만. 실명은 인물2·인물3으로, 나는 상으로, 민감한 건강 얘기는 "세부를 옮기지 않은 채"로 추상화됩니다. 그리고 이 하루 안에 타임라인 동선 + 카드결제 알림 + 카톡 송금이 자연스럽게 한 흐름으로 엮여 있죠.
요청 → 작업 → 결과 → 배운 점
"사실과 해석을 섞지 말라"는 원칙 하나로, AI의 창의성은 논평 문단이라는 우리(cage) 안에서만 풀어놓게 됐습니다. 덕분에 본문은 신뢰할 수 있고, 읽는 재미는 마지막 문단이 책임지는 구조가 됐습니다.
→ 배운 점: AI에게 "잘 써줘"가 아니라 "사실은 여기, 상상은 저기"라고 자리를 지정해주면, 환각이 갈 곳을 미리 가둘 수 있다.
4막. 진짜 승부처는 '생성'이 아니라 '검증'이었다 ⭐
이 프로젝트에서 시간을 가장 많이 쏟은 곳은 글을 뽑는 부분이 아니라, AI가 뽑은 글이 사실인지 확인하는 부분이었습니다. 개인 기록은 숫자 하나만 틀려도 "가짜 기억"이 되니까요.
AI가 만든 실록이 근거 데이터랑 실제로 맞는지 자동으로 검증하게 해줘. 틀리면 걸러내.
그래서 리라이트 결과를 원본 근거와 대조하는 검증 장치를 여러 겹 심었습니다.
시각 표현: '오전/오후', '12:09', '0시 9분' 같은 서로 다른 표기를 근거 시각과 대조.
기간 표현: 시각의 '분' 성분과 실제 체류 시간(duration)을 혼동하지 않도록 구분.
건수 표현: 본문에 나온 개수를 근거 데이터의 카운트 값과 대조.
거리 표현: '총 이동거리'와 '구간별 이동거리'를 구분해 검증.
인용 검증: 대화 원문을 길게 직접 인용하지 못하도록 제한.
여기서 흥미로운 반전이 있었습니다. 검증기가 너무 깐깐해서 멀쩡한 문장을 오탐(false positive) 하는 일이 반복됐고, 그걸 여러 차례 잡아 완화했습니다. 마지막 버그는 특히 기억에 남습니다 — Urban's Court라는 표현의 아포스트로피(')를 긴 인용부호로 오인해 정상 문장을 계속 막던 문제였죠. 이걸 고치고 나서야 마지막 한 편이 통과됐습니다.
요청 → 작업 → 결과 → 배운 점
검증을 켜자 처음엔 통과율이 나빴지만, 오탐을 하나씩 교정하면서 "믿을 수 있는 자동 기록"에 가까워졌습니다. 그리고 문법 검사와 자체 테스트를 통과시킨 뒤, 논평 표지(사신은 논한다 등)가 남아 있는지 전수 검색해 0건을 확인했습니다.
→ 배운 점: AI 자동화의 신뢰도는 생성 프롬프트가 아니라 검증 규칙의 촘촘함에서 나온다. 그리고 검증기도 코드라서, 검증기 자신의 버그까지 잡아야 완성된다.
5막. "매번 서버 켜기 귀찮아" — 원클릭 캘린더 앱으로
기록이 쌓여도 매번 개발 서버를 띄우고 브라우저 주소를 입력해야 본다면, 결국 안 보게 됩니다. 그래서 열람 경험까지 손봤습니다.
매번 서버 띄우고 [localhost](http://localhost) 접속하는 게 번거로워. 클릭 한 번으로 켜지는 앱처럼 만들어줘. 다크/라이트 모드도.
월간·주간 캘린더 뷰를 만들고, 클릭 한 번으로 실행되는 앱 래퍼로 감쌌습니다. 처음 만든 라이트/다크 모드가 육안으로 차이가 거의 없길래, 라이트 모드의 배경·카드·헤더·요일 영역 색상 대비를 다시 분명하게 조정했습니다.
→ 배운 점: 자동화의 마지막 1cm는 "얼마나 쉽게 다시 열어보게 만드느냐"다. 여기서 막히면 그동안의 작업이 전부 서랍 속으로 들어간다.
6막. 3,296편을 한 번에 — 그리고 멈춰도 이어달리게
마지막은 전체 적용이었습니다. 카톡 개인/소수 지인방은 근거로 통합하되 오픈채팅·서비스성 알림은 우선순위를 낮추거나 제외하고, 민감 주제는 원문을 복원하지 않고 추상 요약 수준으로만 쓰도록 못 박은 뒤 전량 리라이트를 돌렸습니다.
전체 대상 3,296편
1차 완료 3,293편, 실패 3편
재시도로 2편 해결, 마지막 1편은 위의 아포스트로피 버그를 고친 뒤 정상 저장
최종 재확인: 미처리 0건
대량 실행이라 중간에 멈출 위험이 있어서, 2건씩 배치 처리 + 타임아웃 시 단건으로 후퇴 + 실패분 재시도 + 이미 성공한 건 건너뛰고 재개하는 안전장치를 넣었습니다. 실제로 한도(rate limit)에 걸리면 5분 뒤 재개, 그래도 안 되면 다시 5분 뒤 재개하는 운영 규칙까지 정해뒀습니다. 다행히 최종 실행은 한도 없이 완주했고, 타임아웃은 단건 후퇴로 회복됐습니다.
→ 배운 점: 수천 건 배치의 핵심은 속도가 아니라 "중단돼도 처음부터 다시 안 하게" 만드는 재개 설계다.
그리고 — 잃어버린 11년이 되살아난 순간
기술적으로 가장 뿌듯했던 건 검증기를 다듬은 순간이었지만, 개인적으로 가장 뭉클했던 건 따로 있었습니다.
앞서 2막에서 세 기록을 같은 날짜 서랍에 모았을 때, 결과물로 그 진가가 드러났습니다. "2019년 그날, 나는 여기 있었고(타임라인) / 이 사람과 이런 얘길 나눴고(카톡) / 이 가게에서 카드를 긁었다(문자)"가 한 페이지에 나란히 서자, 기억에서 지워졌던 특정 하루가 통째로 되살아났습니다. 옛날에 갔던 장소, 자주 가던 식당, 해외여행까지 — 단순한 데이터 통합이 아니라 잃어버린 줄도 몰랐던 지난 11년을 실록으로 되찾은 경험이었습니다.
→ 배운 점: 개인 데이터의 가치는 각 소스에 있는 게 아니라 "엮이는 축(날짜)"에 있다. 흩어져 있으면 로그, 엮이면 기억이다.
✅ 결과 (After)
Before vs After
항목
Before
After
하루 단위 기록
0건 (11.5년간, 사실상 불가능)
4,073일 자동 활동일지 + 3,296편 실록체 서술
데이터 확보
공식 Takeout 1일치만 제공
스마트폰 내보내기로 11.5년(80.7MB) 확보
데이터 통합
위치·카톡·문자가 각각 다른 앱·포맷에 흩어짐
3개 소스를 날짜별 청킹 후 통합(삼각측량)
기록의 깊이
타임라인만 있어 "어디"는 알아도 "무엇을"은 공백
카톡·문자·카드내역으로 "무엇을"까지 복원
서술 품질
이동·지출·사람 단순 나열 + 상투적 논평
본기(사실)/사관 논평(해석) 분리된 읽을 만한 기록
열람 방식
없음 / 80MB JSON 직접 뒤지기
원클릭 캘린더 앱(월간·주간, 다크/라이트)
미처리
—
0건 (3,293 1차 + 3건 재시도로 전부 해결)
결과물 (동작 증거)
말이 아니라 실행 로그로 남은 증거들입니다.
파싱 로그: Positions 373 / Activities 3001 / Place Visits 9 정상 적재 확인
스마트폰 데이터: 4,073 고유 날짜 / 73,820 세그먼트 집계 확인
리라이트 로그: 3293 rewritten, 3 invalid → 재시도 후 최종 summary targets=0(미처리 0)
검증: 문법 검사 통과, 자체 테스트 통과, 논평 표지 전수 검색 0건
교차검증: 카드결제 문자의 상호명 ↔ 타임라인 동선이 같은 시각·좌표에서 일치 — 서로 다른 출처가 같은 사실을 가리킴
지금도 쓰고 있습니다. 완성 후 서랍에 넣어둔 게 아니라, 주기적으로 캘린더 앱을 열어 옛날 특정 날짜를 되짚어 봅니다. 원클릭 앱으로 만든 게 결정적이었습니다 — 매번 서버를 켜야 했다면 진작 안 봤을 겁니다.
주변 반응도 있었습니다. 여자친구는 결과물을 보더니 "이거 나한테도 알려줘"라고 했고, 어느 모임에서 만난 분은 이 작업물을 보고 깜짝 놀라며 방법을 꼭 알려달라고 카카오톡으로 따로 부탁해 왔습니다. 제 데이터라 남이 직접 써본 건 아니지만, "나도 만들고 싶다"는 반응은 이 방식이 개인적 취미를 넘어 남에게도 통한다는 신호였습니다.
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
한 소스의 빈칸은 다른 소스로 메워라(삼각측량). 타임라인의 "어디"에 카톡·문자의 "무엇"을 날짜 축으로 합치니 반쪽짜리 기록이 온전해졌습니다. 게다가 카드내역 상호명과 동선이 겹치면 공짜 교차검증까지 됩니다.
"사실은 여기, 상상은 저기"로 자리를 지정하라. 본기와 논평을 물리적으로 분리하니 환각이 갈 곳이 논평 문단으로 제한됐습니다. AI의 창의성을 죽이지 않으면서 본문 신뢰도를 지키는 방법.
검증을 프롬프트가 아니라 규칙으로 심어라. 날짜·시각·기간·건수·거리·인용을 근거와 자동 대조하게 하니, "그럴듯한 거짓말"이 걸러졌습니다.
대량 작업엔 재개 설계를 먼저. 실패분만 건너뛰고 이어달리는 구조 덕에 수천 건을 안전하게 완주했습니다.
공식 경로가 막히면 대체 출구를 의심하라. Takeout 1일치 → 스마트폰 내보내기 11.5년치. 데이터의 문은 하나가 아니었습니다.
이렇게 하면 안 돼요 (실제로 겪은 함정)
AI가 뱉은 숫자를 그냥 믿기. 시각·건수·거리는 서로 다른 값을 헷갈리기 쉽습니다(분 성분 vs 체류시간, 총거리 vs 구간거리). 반드시 근거와 대조하세요.
검증기를 만들고 방심하기. 검증기도 코드라 오탐을 냅니다. Urban's Court의 아포스트로피를 인용부호로 오인해 멀쩡한 문장을 계속 막았습니다. 검증기 자신의 버그까지 잡아야 끝납니다.
마스킹을 나중에 하기. 위치·대화·문자는 태생이 민감정보라, 마스킹·추상화를 처음부터 기본값으로 두지 않으면 나중에 통째로 다시 돌려야 합니다.
열람 편의를 무시하기. 매번 서버 켜야 보는 결과물은 결국 안 보게 됩니다. "다시 여는 마찰"을 0에 가깝게 만드세요.
🌍 다른 업무에 적용한다면?
이 프로젝트의 진짜 자산은 '실록'이 아니라 "흩어진 데이터를 → 날짜 축으로 통합 + 사실·해석 분리 서술 + 자동 검증 + 마스킹으로 정리하는 파이프라인" 자체입니다. 저는 두 방향 모두로 실제 확장을 고려하고 있습니다.
① 개인 영역으로 더 넓히기 (실제 다음 계획)
사진·가계부·건강기록까지 같은 날짜 축에 합류: 위치·카톡·문자에 사진(어디서 뭘 봤나), 가계부(그날 뭘 샀나), 건강 앱(수면·걸음)을 얹으면, 하루의 복원도가 로그에서 장면으로 올라갑니다. 검증·마스킹 부품은 그대로 두고 "근거 소스"만 추가하면 됩니다.
② 업무 문서로 옮기기 (직무 이식)
법률·공공기관 문서 정리: 사건 경위서·회의록·상담일지를 ① 사실 요약(근거 인용 대조) 과 ② 의견·해석으로 분리 서술하고, 실명·연락처·기관명을 자동 마스킹하며, 날짜·금액·인용의 정확도를 근거 문서와 대조 검증. "AI가 지어낸 사실"이 치명적인 분야일수록 이 구조가 강력합니다.
고객 상담/CS 로그 아카이브: 메신저·통화·티켓을 날짜·고객 축으로 통합하고, 개인정보는 추상 요약으로만 남긴 뒤 "무슨 일이 있었나(사실) / 무엇을 개선할까(해석)"를 분리 기록.
왜 이식이 되나: 이 사례에서 실제로 작동한 네 부품 — 날짜 축 통합, 사실/해석 분리, 근거 대조 검증, 마스킹 기본화 — 은 데이터 종류(위치든 대화든 사진이든 법률 문서든)와 무관하게 재사용됩니다. 바꿔야 할 건 "근거 데이터의 필드 이름"뿐입니다. 실제로 위치→카톡→문자로 소스를 늘릴 때 이 부품들을 그대로 재사용했습니다.
솔직한 재현 난이도 & 전제조건
과장 없이 말씀드리면, 이건 "복붙 한 번으로 끝"은 아닙니다. 층을 나눠 보면:
🟢 대화형 AI(ChatGPT·Claude)만으로 오늘 당장 되는 것: 위 재사용 프롬프트 2개(사실/해석 분리 서술 + AI 자가검증). 내 데이터 한 조각을 붙여넣기만 하면 됩니다. 비개발자도 즉시 가능.
🟡 AI 코딩 도구가 필요한 것: 11.5년치 대량 파싱·날짜별 청킹·자동 검증 파이프라인은 Claude Code·Codex 같은 도구(+약간의 스크립트)가 필요합니다. 순수 비개발자라면 이 부분을 AI 코딩 도구에 통째로 맡기거나, 규모를 "최근 몇 달"로 줄여 시작하길 권합니다.
필요 준비물: 스마트폰 타임라인 내보내기, 카톡·문자 내보내기, AI 코딩 도구 접근(유료 구독 포함 가능).
안 맞는 경우(비적용): 실시간 대응이 필요한 업무, 근거 데이터가 아예 없는 순수 창작, 소스가 한 종류뿐이라 교차검증이 불가능한 경우엔 이 방식의 강점(삼각측량·검증)이 약해집니다.
조직으로 키우려면: 개인은 이대로 충분하지만, 팀·조직 규모로 올리면 데이터 접근 권한·보안 규정·마스킹 수준 합의가 기술보다 먼저 필요합니다.
🚀 앞으로의 계획
사진 EXIF 결합(여행일지): 위치 기록에 사진 촬영 시각·좌표를 얹어, 인터랙티브 지도가 있는 여행일지로 확장.
검색·질의 연동: 4,073일 기록을 자연어로 "2019년 여름에 자주 가던 곳은?"처럼 물어볼 수 있게 Wiki/검색과 연결.
마스킹 정책 고도화: 외부 공유를 전제로, 민감 주제 추상화 수준을 사용자가 선택할 수 있게.
방법 전파: 지금 이 글이 첫 공유입니다. 나아가 "나도 알려달라"던 여자친구·모임 지인에게 따라 할 수 있는 방법(이 글의 재사용 프롬프트 + 데이터 내보내기 순서)을 정리해 전수할 계획입니다.
📋 재사용 가능한 프롬프트
아래 프롬프트는 대화형 AI(Claude, ChatGPT 등)에 복붙해서 바로 쓸 수 있습니다. [대괄호] 부분만 본인 상황에 맞게 바꾸세요.
프롬프트 1: 개인/업무 데이터를 '사실 ↔ 해석' 분리해 서술시키기
아래 [데이터 종류: 예) 하루치 위치·대화 기록 / 회의록 / 상담 로그]를 읽고 하나의 기록으로 정리해줘.
규칙:
[사실 섹션 이름: 예) 본기] 에는 근거가 있는 사실만 써라. 원본에 없는 내용은 추측해서 쓰지 마라.
상상·해석·비유·평가는 오직 맨 끝 [논평 섹션 이름: 예) 총평] 문단에만 써라.
인물은 [지칭 방식: 예) 실명 대신 이니셜]로만 부르고, [마스킹 대상: 예) 전화번호·기관명·금액]은 가리거나 추상화해라.
대화 원문을 길게 직접 인용하지 말고, 요지만 요약해라.
문체는 [원하는 톤: 예) 담담한 앵커 / 냉정한 비평가] 하나로 일관되게.
프롬프트 2: AI가 만든 요약의 '사실 정확도'를 스스로 검증시키기
방금 네가 작성한 [결과물: 예) 하루 기록]을 아래 [근거 데이터]와 대조해서 사실 오류가 있는지 자가 점검해줘.
다음 항목을 각각 O/X로 판정하고, X면 근거의 실제 값을 함께 제시해라:
시각: 본문에 쓴 시간이 근거의 시각과 일치하는가 (오전/오후, 표기법 혼동 주의)
기간: '몇 시 몇 분'과 '얼마나 머물렀는지(체류 시간)'를 혼동하지 않았는가
건수: 본문의 개수가 근거 데이터의 실제 카운트와 같은가
금액/수치: [핵심 수치: 예) 지출액·거리]가 근거와 일치하는가 (합계 vs 구간 구분)
인용: 원문에 없는 말을 지어내 인용하지 않았는가
판정이 모두 O가 될 때까지 본문을 고쳐 다시 제시해라. 근거가 없으면 지어내지 말고 "확인 불가"로 표기해라.
추천 이미지:
"결과 (After)" 섹션: 완성된 원클릭 캘린더 앱의 월간 뷰(다크/라이트 모드 나란히) 스크린샷 — 4,073일이 캘린더에 채워진 전경.
"2막 — 삼각측량" 섹션: 같은 날짜에 타임라인 동선 + 카톡 + 카드결제 문자가 나란히 놓인 화면, 또는 카드 상호명↔타임라인 좌표가 일치하는 대조 장면. ※ 마스킹 필수.
"4막 — 검증" 섹션: 리라이트 로그 3293 rewritten, 3 invalid 또는 최종 summary targets=0 터미널 화면.
"3막" 섹션: 실제 생성된 '황제실록' 하루 기록 예시(본기 + 사관은 논한다 문단이 분리된 화면). ※ 게시 전 반드시 실명·지명·대화 내용 마스킹.
소개
저는 일본과 한국을 오가며 옷·스니커즈를 양방향으로 판매합니다. 상품마다 어느 방향(한국↔일본)으로 넘겨야 남는지가 달라서, 늘 양쪽 시세를 함께 봐야 해요. 이번에 자동화한 건 그중 일본에서 사서 KREAM(한국)으로 넘기는 방향입니다. 이 장사는 결국 "어느 쪽으로, 얼마에 넘기느냐"가 전부라, 매일 밤 일본 공급처 사이트를 하나씩 열어 KREAM 시세와 비교하고 있었어요. "이거 지금 넘기면 수수료 떼고 얼마 남지?"를 손으로 계산하는 거죠.
이 짓을 매일 반복하다가, Claude Code로 이 과정을 자동화하는 딜 찾기 시스템을 붙여보기로 했습니다. 목표는 단순했어요. 여러 공급처를 자동으로 훑어서 "지금 사면 KREAM에서 남는 딜"만 추려주는 것. 그런데 만들고 보니, 딜을 '찾는' 것보다 그럴듯하게 틀린 딜을 '거르는' 게 훨씬 어려웠습니다. 오늘은 그 삽질기를 공유합니다.
스택: Claude Code + Python(FastAPI) 백엔드 + React 프론트 + SQLite. 크롤링·매칭·마진계산 로직을 대화로 하나씩 붙여나갔습니다.
진행 방법
⚠️ 아래 프롬프트는 실제 세션 로그 원문이 아니라, 제가 봇에게 어떤 식으로 지시했는지 흐름을 재구성한 대표 예시입니다. 실제로는 훨씬 잘게 쪼개서 주고받았어요.
1) 공급처 크롤러 — "매장 추가를 공짜로"
먼저 편집샵을 긁어오는 크롤러부터 시켰습니다.
일본 편집샵 상품을 긁어오는 크롤러를 만들어줘.
- 몽벨/진즈팩토리는 HTML 직접 파싱
- 스니커즈 편집샵(kickslab, wormtokyo, mita)은 Shopify 기반이니 /products.json 엔드포인트로 상품을 통째로 받아와
- 공급처를 추가할 때 base_url만 넘기면 되도록 전략(Strategy) 패턴으로 구성
여기서 Shopify /products.json 트릭 덕에 매장 추가가 거의 공짜가 됐습니다. 반면 Nike·adidas 공식몰은 일부러 뺐어요. nike.com/jp는 JS로 그리는 SPA라 정적 HTML에 상품이 없고, adidas는 403으로 봇을 막고, 무엇보다 공식 정가라 KREAM 마진이 안 나옵니다. 편집샵에서 두 브랜드가 다 커버되기도 했고요.
2) 매칭 & 마진 — KREAM 시세에 붙이기
긁어온 상품을 KREAM 시세와 맞대고 마진을 계산하게 했습니다. 마진 공식의 핵심은 이렇게 잡았어요(수수료를 숨은 상수로 두지 않고 명시 필드로).
# 판매가(KREAM 실거래가) 기준 마진율
estimated_margin_krw = kream_price_krw - purchase_cost_krw \ - shipping_krw - customs_krw - commission_krw
estimated_margin_rate = round(estimated_margin_krw / kream_price_krw * 100, 2)
▲ 실제 딜 추천 화면. 활성 딜 13건, 평균 마진 18.7%. 각 카드에 공급처가(¥)·KREAM가(₩)·마진이 한눈에.
결과와 배운 점
만드는 내내 벽을 세 번 넘었습니다. 그리고 셋 다 "코드가 안 돌아서"가 아니라 "봇이 자신 있게 틀려서" 생긴 벽이었어요.
벽 ① — "0건이 원래 정상인 줄 알았다"
전체를 돌렸더니 추천이 0건. 저는 순간 "일본 정가로 사서 KREAM에 팔면 수수료 떼고 원래 안 남는 거구나" 하고 납득했습니다. 그럴듯하죠. 근데 찜찜해서 로그를 팠더니 — DB에 컬럼 하나(kream_product_name)가 없어서, 조건을 통과한 딜조차 저장에 전부 실패하고 있었어요. 컬럼을 추가하니 바로 8건이 떴습니다.
배운 점: 수상한 결과를 '그럴듯한 경제 논리'로 덮으면, 버그가 정상인 척 숨는다. 0건을 납득해버린 나 자신이 제일 위험했다.
벽 ② — 목걸이를 신발로 착각한 봇
8건 중 몇 개는 마진이 70%를 넘었습니다. "대박!" 하고 열어봤더니… 피어스·뱅글·네크리스 액세서리 3개가 전부 똑같은 버켄스탁 신발(₩239,000)에 매칭돼 있었어요. 목걸이를 신발이라 우기면서 신뢰도 0.85로 아주 당당하게요.
원인은 매칭이 헐거웠던 것. 모델 번호 앞부분 몇 글자만 겹치면 같은 상품 취급했거든요. 그래서 봇에게 '의심'을 가르쳤습니다.
매칭 false positive가 너무 많아. 두 개를 넣어줘:
1) 모델번호 접두사가 너무 짧으면(5자 미만) 매칭 거부
2) 공급처 브랜드와 KREAM 브랜드가 실제로 같은지 검증하는 게이트
그리고 크로스브랜드 거부 / 동일브랜드 유지 단위테스트도 같이.
_MIN_BASE_MODEL_LEN = 5 # 짧은 접두사 충돌 차단 def _kream_brand_matches(supplier_brand, kream_result) -> bool: # KREAM 브랜드 필드 또는 상품명에 공급처 브랜드가 포함되는지 ...
재스캔하니 목걸이-신발 같은 쓰레기는 싹 사라지고, 브랜드가 맞는 딜만 남았습니다. 저는 "가끔 놓치더라도 절대 거짓말은 안 하는" 쪽(정밀도 우선)을 택했어요.
여기서 한 발 더 나갔습니다. 매칭이 왜 맞는지를 눈으로 검증할 수 있게, 실물 품번과 KREAM 품번목록을 나란히 놓고 대조하는 화면을 만들었어요. 제1원칙은 "AI는 후보를 찾아오는 데만 쓰고, 확정 근거로는 안 쓴다" — 최종 매치는 실물 품번이 KREAM 리스팅 품번목록에 포함되는지의 기계 판정으로만 확정합니다.
▲ 스캔 9건 중 품번 확정 4건·수동 검수 5건·오매칭 0건. 초록으로 하이라이트된 품번(예: FB7818-100)이 양쪽에 똑같이 들어있을 때만 확정. 아래 빨간 띠("단순차액 −18,340원 · 역마진")처럼, 매칭이 맞아도 마진이 안 나오면 자동 딜에서 제외됩니다.
배운 점: 딜 찾기의 진짜 적은 '0건'이 아니라 '자신 있게 틀린 것'이다. 없는 건 없다고 알면 그만이지만, 가짜를 진짜라 우기면 진짜 돈을 잃는다.
벽 ③ — '정확한 매칭'이 '팔리는 딜'은 아니었다
여기서 "이제 됐다" 했는데, 그게 방심이었습니다. 남은 목록을 보니 몽벨 아웃도어 자켓이 마진 28%로 딜에 올라와 있었어요. 매칭은 정확합니다. 그런데 몽벨 자켓은 KREAM에서 거의 거래가 안 됩니다. 사겠다는 사람이 없으면 28%는 그냥 종이 위 숫자죠.
▲ 왼쪽 Asics Gel-Kayano 14(마진 29.2%, KREAM에서 잘 거래됨)와 오른쪽 몽벨 클라이마플러스 자켓(마진 28.5%, KREAM 거래 거의 없음). 봇 눈엔 둘 다 신뢰도 98%의 똑같이 좋은 딜로 보인다 — 이게 벽③이다.
코드를 다시 까보고 이유를 알았습니다. KREAM 응답엔 '총 거래량(total_sales)'이 같이 오는데, 저는 그 값을 스냅샷에 저장만 하고 딜 판정엔 한 번도 안 쓰고 있었어요. 판정 기준이 오직 '마진'과 '매칭 신뢰도'뿐이라, 반년에 한 번 팔린 물건이든 매일 팔리는 물건이든 봇 눈엔 똑같아 보였던 겁니다.
배운 점: 봇에게 "같은 물건이냐"(정확도)는 가르쳤지만, "실제로, 곧 팔리냐"(유동성)는 아직 못 가르쳤다. 데이터를 손에 쥐고도.
앞으로의 계획 & 도움이 필요한 부분
다음 할 일은 정해졌습니다. 이미 받아둔 거래량(total_sales)과 '마지막 거래가 얼마나 최근이냐'를 딜 판정에 실제로 반영하는 것. 거래가 뜸한 물건은 마진이 높아도 뒤로 밀고, 자주 팔리는 물건에 가중치를 주려고요. 마진이 진짜가 되려면 그 가격에 팔 수 있다는 증거가 먼저 붙어야 하니까요.
혹시 국경 간 중고/병행 시세에서 '유동성(회전율)'을 점수화하는 좋은 방법을 써보신 분 있으면 팁 구합니다. 지금은 단순 거래량 + 최근성 가중치를 생각 중인데, 더 나은 접근이 있을 것 같아요.
돌아보면 이 봇은 벽을 하나씩 넘어온 과정이었어요. 저장이 안 되던 벽, 아무거나 갖다 붙이던 벽, 그리고 "정확하지만 안 팔리는" 벽. 딜을 '찾는' 코드는 하루면 짜지만, 믿을 수 있게 만드는 데는 벽이 계속 나옵니다. 좋은 딜을 많이 찾아주는 봇보다 틀렸을 때 틀렸다고 말하는 봇이 훨씬 든든하다는 것, 그거 하나는 확실히 배웠습니다.
ARGUS 설치 기록 — LLM Wiki LCL
작성일: 2026-06-17
대상: domains/ai-it/ Argus Wiki Integration Phase 0 + Phase 1
관련 커밋: 9719f58b (PRD 추가) → bbb1d17b (Phase 1 scaffold 설치)
1. Argus가 무엇인가
jasonxtn/Argus는 Python 기반 정보수집·보안점검(OSINT/Recon) 툴킷이다.
DNS 조회, WHOIS, SSL 만료 알림, HTTP 헤더 분석, robots.txt, sitemap, SPF/DKIM/DMARC 검증 같은 passive 체크부터 포트스캔·디렉토리 파인더 같은 active scan까지 다수의 모듈을 제공한다.
공식 README는 교육적·윤리적 사용과 명시적 허가가 있는 대상만 스캔할 것을 고지한다.
2. 설치 전 상황 (Before)
항목
상태
AI_IT 도메인
존재하지 않음
보안 점검 결과 저장 구조
없음 — 터미널 출력으로 끝
allowlist / 실행 정책
없음 — 어떤 대상에도 실행 가능
passive / active 모듈 구분
없음
결과 민감도 정책
없음 — public 인덱스 노출 위험
Ouroboros 감사 기록
Argus 실행 이력 없음
NAS public 배포 제어
Argus 결과 포함 여부 불명확
3. 설치 과정
3-1. PRD 작성 (Phase 0 정책 확정)
커밋 9719f58b — 2026-06-17 13:49
Show Me The PRD 플러그인으로 인터뷰 기반 요구사항을 추출한 뒤 4종 문서를 작성했다.
90_project_docs/10_prd/argus-wiki-integration/
├── 01_PRD.md # 제품 요구사항 (허가 경계, 핵심 기능, 성공 기준)
├── 02_DATA_MODEL.md # 데이터 모델 (AssetAllowlist, ArgusRunPlan, OuroborosLedgerEntry)
├── 03_PHASES.md # Phase 0~4 분리 계획
├── 04_PROJECT_SPEC.md # AI 행동 규칙 (금지사항·구현 순서)
└── README.md # 문서 네비게이션
핵심 결정: Argus는 local-contract-law·case-law·general-law 검색과 무관하다.
AI_IT 도메인의 security-recon collection으로만 격리 운영한다.
3-2. Phase 1 Scaffold 설치
커밋 bbb1d17b — 2026-06-17 14:21
Codex CLI가 PRD를 읽고 Phase 1을 구현했다. 생성된 파일은 다음과 같다.
정책·스키마 파일
domains/ai-it/90_schema/
├── argus-allowlist.yml # 허가된 자산 등록부 (현재 2개: system.cmdspace.work, 127.0.0.1)
└── argus-module-policy.yml # 모듈별 위험도 및 허용 여부 정의 (12개 모듈)
allowlist 등록 자산
asset_id
target
active scan
AIT-ASSET-001
system.cmdspace.work
불가
AIT-ASSET-002
127.0.0.1
불가
모듈 정책 (passive-only profile 허용 8개)
모듈
카테고리
위험도
기본 허용
DNS Records
network-passive
low
O
Domain Info / RDAP / WHOIS
network-passive
low
O
SSL Expiry Alert
web-passive
low
O
HTTP Headers
web-passive
low
O
Robots.txt Analyzer
web-passive
low
O
Sitemap Parsing
web-passive
low
O
Security.txt Check
web-passive
low
O
SPF / DKIM / DMARC Validator
email-passive
low
O
Open Ports Scan
network-active
medium
X (명시 승인 필요)
Directory Finder
web-active
medium
X (명시 승인 필요)
WAF Bypass Test
blocked-active
high
X (기본 차단)
Subdomain Takeover
blocked-active
high
X (기본 차단)
실행 엔진
domains/ai-it/
├── argus_run_plan.sh # wrapper (venv 자동 선택)
└── 91_scripts/ └── argus_run_plan.py # run plan 생성기 (337 lines)
argus_run_plan.py가 하는 일:
target이 allowlist에 있는지 확인 → 없으면 즉시 blocked 반환
profile에 따른 허용 모듈 목록 구성
active 모듈 요청 시 차단
run plan JSON/MD 생성 → 50_reports/argus/run-plans/ 저장
--write-ledger 옵션 시 Ouroboros ledger에도 기록
Phase 1 핵심 불변식: would_run: false, argus_installed_or_executed: false
실행 계획만 만들고 Argus 바이너리는 절대 호출하지 않는다.
결정 문서 및 워크플로우
domains/ai-it/20_wiki/
├── decisions/argus-phase1-no-run-policy.md # 4대 정책(allowlist-only, passive-only, private-by-default, no-run)
└── workflows/argus-run-plan-workflow.md # 실행 흐름 설명 + 예시 명령
domains/_registry.yml 갱신
ai-it 도메인이 멀티도메인 registry에 추가됐다.
검색앱과 라우터가 이 파일을 단일 진실로 사용하므로 AI_IT 도메인 검색이 활성화된다.
3-3. 첫 run plan 실행 (dry-run)
설치 직후 검증 명령:
./domains/ai-it/argus_run_plan.sh \ --target system.cmdspace.work \ --profile passive-only \ --dry-run \ --write-ledger
결과 (ARGUS-RUN-20260617-141653):
result: pass
would_run: False
argus_installed_or_executed: False
planned modules: 8개 (전부 passive-only)
ledger: domains/ai-it/50_reports/ouroboros/ledger/ 에 기록됨
미등록 target 차단 테스트도 통과했다.
4. 설치 전·후 비교 (After)
항목
설치 전
설치 후
AI_IT 도메인
없음
domains/ai-it/ 생성, registry 등록
보안 점검 저장 구조
없음
source / wiki / report / ledger 4계층
allowlist
없음
argus-allowlist.yml — 2개 자산 등록
모듈 정책
없음
argus-module-policy.yml — 12개 모듈 분류
Argus 실행
무제한(통제 없음)
Phase 1은 실행 자체 금지, run plan만 생성
결과 민감도
미정
기본 private — public 인덱스 승격 금지
NAS 공개 배포
불명확
Argus 결과 완전 제외
감사 추적
없음
Ouroboros ledger에 실행 이력 자동 기록
active scan
통제 없음
명시 승인 없이 기본 차단
5. 무엇이 달라졌는가
거버넌스 우선 구조
Argus를 바로 설치·실행한 것이 아니라 "어디에, 어떤 조건으로, 어떤 범위만" 먼저 정의했다.
Phase 1의 핵심 가치는 Argus 실행이 아닌 실행 통제 체계 구축이다.
도메인 격리
Argus 결과는 AI_IT 도메인 private 검색에서만 조회된다.
local-contract-law, case-law, general-law, journal 도메인 인덱스에는 영향이 없다.
실행 흔적의 누적 가능성
이전에는 Argus 실행 결과가 터미널에만 남았다.
이제는 run plan과 ledger가 50_reports/ 하위에 JSON/MD로 누적된다.
6. 다음 단계 (Phase 2 시작 조건)
첫 allowlist target 사용자 확정 (system.cmdspace.work 권장)
Argus 설치 방식 결정 (isolated venv 권장 vs. container)
Phase 2 시작 승인
Phase 2가 시작되면 실제 Argus 바이너리를 isolated venv에 설치하고,
passive-only 모듈 8개를 내 소유 자산 1개에 한해 pilot 실행한다.
7. 따라서 설치하고자 하는 사람을 위한 유의사항
반드시 지킬 것
allowlist 먼저 작성 — argus-allowlist.yml에 내 소유 자산만 등록한다. 등록되지 않은 target은 실행 자체가 차단된다.
거버넌스 → 설치 순서 — 정책 파일(allowlist, module-policy) 없이 Argus를 먼저 설치하면 안 된다. 이 scaffold가 없으면 실행 통제가 불가능하다.
Phase 1에서는 Argus 바이너리를 설치하지 않는다 — would_run: false가 Phase 1의 정상 상태다. 실행 결과가 나왔다면 뭔가 잘못된 것이다.
active scan은 기본 차단 — open-ports, directory-finder, waf-bypass, subdomain-takeover 계열은 requires_explicit_approval: true다. 별도 승인 없이 profile에 포함하지 않는다.
결과 sensitivity는 기본 private — Argus 결과는 취약점 정보가 될 수 있다. public 인덱스, NAS public 검색, 외부 공유에 절대 포함하지 않는다.
API key 필요 모듈은 Phase 1 제외 — Shodan, VirusTotal, Censys 계열은 no-API-key 원칙과 충돌한다. Phase 2 이후 별도 결정이 필요하다.
다른 도메인 인덱스 건드리지 않기 — local-contract-law, case-law, general-law, journal 도메인의 FTS/MongoDB/qmd 인덱스에 Argus 결과를 절대 합류시키지 않는다.
설치 검증 체크리스트
# 1. 등록 자산 통과 확인
./domains/ai-it/argus_run_plan.sh --target <내자산> --profile passive-only --dry-run
# 기대: result=pass, would_run=False # 2. 미등록 자산 차단 확인
./domains/ai-it/argus_run_plan.sh --target example.com --profile passive-only --dry-run
# 기대: result=blocked # 3. active 모듈 요청 차단 확인
./domains/ai-it/argus_run_plan.sh --target <내자산> --profile passive-only --modules open-ports --dry-run
# 기대: result=blocked
8. 관련 파일 맵
domains/ai-it/
├── argus_run_plan.sh # 실행 진입점
├── 90_schema/
│ ├── argus-allowlist.yml # 허가된 자산 등록부
│ └── argus-module-policy.yml # 모듈 정책 (passive/active/blocked)
├── 91_scripts/
│ └── argus_run_plan.py # run plan 생성기
├── 20_wiki/
│ ├── decisions/argus-phase1-no-run-policy.md
│ └── workflows/argus-run-plan-workflow.md
└── 50_reports/ ├── argus/run-plans/ # run plan 기록 └── ouroboros/ledger/ # 감사 ledger 90_project_docs/10_prd/argus-wiki-integration/ # PRD 4종
📝 한줄 요약
방대한 공공계약·법률 자료를 검색하는 내 AI 위키가 "그럴듯하게 틀리는" 게 불안해서, AI가 스스로 검색을 고치고 → 전체 성적표로 채점하고 → 좋으면 남기고 나쁘면 되돌리는 자가개선 루프를 한 달간 돌렸습니다. 그 과정에서 "점수는 오르는데 실력은 안 느는" 함정까지 잡았습니다.
바쁘시면 이것만 읽어도 돼요:
사용한 도구와 목표: Claude Code(설계·디버깅) + Codex(자동 실험 실행), 목표는 "믿을 수 있는 법률 자료 검색"
AI가 검색을 작게 고치고 → 전체 시험으로 채점 → keep/discard 하는 자가개선 루프를 한 달간 33번 반복
가장 큰 발견: 점수가 만점이어도 실력이 아니라 시험을 "외운" 것일 수 있다 → 비공개 시험지(holdout)로 진짜 실력만 따로 측정
"오!" 했던 순간: 한 달간 0%였던 복합 질문의 비공개 점수가 처음으로 움직였다 = 외운 게 아니라 진짜 실력이 늘었다는 첫 신호
법률 실무의 핵심: AI가 없는 근거를 지어내지 않고 "근거 부족"이라고 말하게 만든 것
배운 교훈: AI 결과물은 "좋아진 것 같다"가 아니라 안 본 문제 점수로 증명해야 한다
🎯 이런 분들께 도움돼요
법률·공공기관처럼 방대한 문서를 찾아 인용해야 하는 전문직
내 자료로 AI 검색(RAG)을 만들고 싶은 비개발자·세컨드브레인 사용자
AI 결과물이 "진짜 좋아졌는지"를 감이 아니라 증거로 관리하고 싶은 실무자
AI가 근거 없이 단정하는 환각(지어내기)이 무서워 업무에 못 쓰는 분
😫 문제 상황 (Before)
저는 공공기관에서 법률 자료를 다룹니다. 지방계약법, 시행령, 시행규칙, 계약집행기준, 질의회신 사례집… 이런 자료가 수백 건 쌓여 있고, 실무에서는 "이 상황에 맞는 정확한 조문 한 줄"을 빠르게 찾아야 합니다.
그래서 제 자료들을 AI가 검색해 주는 위키(LLM Wiki)를 만들어 쓰고 있었는데, 결정적인 불안이 하나 있었습니다.
검색을 믿을 수가 없었습니다.
문제는 세 갈래였습니다.
자료는 분명히 있는데, 검색이 엉뚱한 문서를 위에 올려서 정작 필요한 조문을 못 찾았습니다.
검색 규칙을 감으로 고치면 한 쪽이 좋아지고 다른 쪽이 망가지는데, 그걸 객관적으로 확인할 방법이 없었습니다.
가장 무서운 건, AI가 비슷한 자료만 보고 없는 근거를 있는 것처럼 단정하는 것이었습니다. 법률 실무에서 "모르면 모른다"는 건 정확한 답만큼이나 중요한데, AI는 일단 답을 지어내려는 경향이 있었습니다.
"잘 찾는 것 같다"는 느낌만으로는 업무에 쓸 수 없었습니다. 검색을 증명할 수 있는 시스템으로 바꿔야 했습니다.
🛠️ 사용한 도구
도구명: Claude Code (설계·디버깅·문서화), Codex (자동 실험 실행기)
보조: fablize (작업이 중간에 멈추지 않게 잡아주는 "작업 안전벨트")
특이사항: 검색 코드를 직접 짜기보다, "채점 → 실험 → 채택/폐기"라는 운영 절차를 AI에게 맡긴 것이 핵심
🔧 작업 과정
1. 시험이 너무 쉬워졌다 — 일부러 어려운 시험을 새로 냈다
처음엔 기쁜 일이었습니다. 검색을 다듬다 보니 기존 평가 문제 126개가 전부 만점이 나왔거든요. 그런데 곧 이게 함정이라는 걸 깨달았습니다. 전부 만점이면, 시스템을 고쳤을 때 좋아졌는지 나빠졌는지를 더 이상 알 수가 없습니다.
그래서 AI에게 일부러 어려운 시험을 새로 내달라고 했습니다.
실무에서 진짜 물어볼 법한, 어려운 평가 질문을 새로 만들어줘.
법률 용어를 안 쓰고 묻는 구어체 질문, 조문 두 개를 한꺼번에 찾아야 하는 복합 질문,
자료에 없는 걸 물었을 때 "모른다"고 하는지 보는 질문도 넣어줘.
이렇게 네 유형의 어려운 시험이 만들어졌습니다. 예를 들어 "지체상금 요율이 얼마인가" 대신 "공사 끝나는 날짜를 못 맞췄는데 하루에 얼마씩 물려야 하나요?" 처럼 일반인 말투로 묻는 식이죠.
첫 채점은 38점(100점 만점)이었습니다. 일부러 어렵게 냈으니 당연한 결과고, 이제부터 이 점수가 오르는지가 진짜 개선의 증거가 됩니다. 만점짜리 쉬운 시험을 버리고, 점수가 움직이는 어려운 시험을 손에 쥔 순간이었습니다.
2. AI가 스스로 검색을 고치게 했다 — 자가개선 루프(Autoresearch)
여기서부터가 이 프로젝트의 핵심입니다. 검색 규칙을 제가 일일이 손으로 고치는 대신, AI가 스스로 실험하게 만들었습니다. 이름은 거창하지만 원리는 단순합니다.
1. 문제 하나를 고른다
2. 왜 안 되는지 가설을 세운다
3. 아주 작은 수정만 한다
4. 전체 성적표를 다시 채점한다
5. 좋아졌으면 남긴다 (keep)
6. 나빠졌으면 되돌린다 (discard)
중요한 건 "어려운 시험 점수만 오르면 무조건 좋은 것"이 아니라는 점이었습니다. 검색 규칙을 세게 밀어붙이면 특정 어려운 문제는 맞히지만, 평소 잘 되던 질문의 답이 깨질 수 있거든요. 그래서 항상 두 가지를 동시에 봤습니다.
기존 126문항 품질검사 → 평소 질문이 안 깨졌는지
어려운 시험 → 까다로운 질문이 좋아졌는지
실제로 자동 실험 초반엔, 어려운 점수는 올랐는데 기존 품질검사가 떨어진 변경이 여럿 나왔습니다. 전부 버렸습니다. 이게 핵심입니다 — "잠깐 점수 올랐지만 다른 걸 망가뜨린" 변경을 AI가 스스로 폐기하게 한 것. 이 루프를 한 달간 33번 돌렸습니다.
여기서 "오!" 했던 장면도 있었습니다. 부정당업자 관련 문서 연결을 보강했더니, 정당해 보이던 그 수정이 엉뚱하게 다른 질문 하나를 망가뜨렸고, 안전장치가 그걸 곧바로 잡아냈습니다. AI가 규칙대로 변경을 전부 되돌리는 걸 보면서, "이제 감이 아니라 증거로 굴러가는구나" 싶었습니다.
3. 점수는 만점인데 실력은 제자리였다 — "외운 것 vs 실력"을 잡은 장치
한 달쯤 지나 이상한 걸 발견했습니다. 자동 실험이 어려운 시험 점수를 계속 만점으로 끌어올렸는데, 새 시험지를 만들 때마다 시작 점수가 0.5~0.6으로 뚝 떨어지는 겁니다.
시험 v1: 만점 → 더 어려운 v2 만듦 → 만점 → v3 → 만점 → v4 → 만점 → v5
(그런데 새 시험을 낼 때마다 처음엔 0.5점대로 추락)
원인은 충격적일 만큼 단순했습니다. AI가 "어떤 문제를 틀렸는지" 목록을 보고, 딱 그 문제만 맞히는 규칙을 손으로 추가해 온 거였습니다. 검색 코드가 그 사이 5,400줄까지 불어나 있었고요. 한마디로 실력이 는 게 아니라 시험을 외운 것이었습니다.
그래서 학교 시험에서 기출만 외운 학생을 가려내듯, 장치를 하나 넣었습니다.
공개 문제(dev) 12개: AI가 틀린 걸 보고 고칠 수 있음
비공개 문제(holdout) 6개: 점수만 보이고, 문제 내용은 숨김
이제 진짜 실력은 "비공개 문제 점수"로만 잽니다. 공개 점수만 오르고 비공개가 안 오르면 = 외운 것. 이 장치를 넣자마자 효과를 봤습니다. 어떤 보강을 했더니 공개 복합질문은 25%→50%로 올랐는데 비공개는 0%→0% 그대로. 즉 그것도 "그 문서에만 통하는 땜질"이었다는 걸 장치가 정확히 짚어준 거죠.
이 장치를 넣기 전이었다면 그 변경은 "점수 올랐네" 하고 그냥 채택됐을 겁니다. 지난 30여 번의 채택이 왜 실력으로 이어지지 않았는지가, 이 한 번의 실험에서 그대로 드러났습니다.
4. 한 달을 붙든 복합 질문의 천장 — 그리고 첫 진전
가장 어려웠던 건 복합 질문이었습니다. "한 번에 근거 2~3개를 다 찾아야 답할 수 있는" 질문인데, 이걸 풀려고 방법을 바꿔 가며 계속 시도했습니다. 그런데 세 번 연속 실패했습니다.
1차: 관련 문서 연결 보강 → 공개 점수만 오르고 비공개는 그대로
2차: 질문 속 조문번호로 자료 찾기 → 법·시행령·시행규칙이 같은 "제31조"를 각각 갖고 있어 엉뚱한 게 딸려옴
3차: "어느 법의 몇 조인지"까지 구분 → 엉뚱한 자료는 사라졌지만 점수는 그대로
세 번 실패하자 규칙대로 멈추고 원인부터 봤습니다. 그랬더니 놀라운 결론이 나왔습니다 — 이건 "어디서 찾을지"의 문제가 아니라 "비슷한 여러 자료 중 진짜 맞는 하나를 고르는" 문제였고, 더 깊이 파보니 검색이 아니라 채점이 발목을 잡고 있었습니다.
예를 들어 "하자담보책임 존속기간"을 물으면 시스템은 "존속기간 해석 사례"를 1순위로 가져오는데, 제가 만든 정답표는 "존속기간 조문" 하나만 정답으로 못박아 뒀습니다. 둘 다 맞는 자료인데, 옳게 찾고도 틀렸다고 채점되고 있었던 거죠.
그래서 순서를 바꿔, 채점부터 고쳤습니다.
이전: "공사용지 확보" = 특정 문서 하나만 정답
이후: 같은 내용의 두 문서 중 하나만 찾아도 정답 인정 (any-of)
(단, "시험을 통과시키려고 아무거나 정답에 넣지는 않는다"는 원칙은 지켰습니다. 똑같이 맞는 자료일 때만 여럿 인정.)
이 토대 위에서 "긴 질문을 작은 질문 여러 개로 쪼개서 각각 답을 찾는" 방법을 다시 붙였습니다. 그리고 드디어 — 한 달간 0%였던 비공개 시험의 복합질문 점수가 처음으로 움직였습니다.
공개 시험 복합질문: 50% → 83%
비공개 시험 복합질문: 0% → 17% (처음으로 0 탈출!)
제가 보지도 않은 문제가 좋아졌다는 건, 외운 게 아니라 진짜 실력이 늘었다는 첫 신호였습니다. 한 달을 붙들고 처음 본 진짜 진전이었죠. 최종적으로 채택된 방식은 "앞줄(1~3위 검색결과)은 건드리지 않고, 부족한 근거가 있을 때만 뒤쪽 빈자리에 조심스럽게 보충"하는 것이었습니다. 예전 시험은 만점을 유지하면서 새 시험과 비공개 시험이 함께 올라간, 처음으로 깨끗한 개선이었습니다.
5. AI가 "모른다"고 말하게 만들었다 — 법률 실무의 진짜 핵심
마지막은 정확도가 아니라 정직함에 관한 이야기입니다. 검색 시스템은 보통 "무언가를 찾아오는 능력"에 집중합니다. 하지만 법률·계약 실무에서는 없는 근거를 있는 것처럼 말하지 않는 능력이 그만큼 중요합니다.
그래서 자료에 없는 걸 물었을 때 AI가 어떻게 반응하는지를 따로 시험했습니다. 예를 들면 이런 것들입니다.
- 특정 지방공기업의 2026년 최신 내부 특수조건
- 개인정보보호위원회 과징금 산정자료
- 행정안전부 표준시장단가 단가표 수치
처음엔 시스템이 비슷한 문서를 찾으면 그냥 답을 만들어내려 했습니다. 이걸 고쳐서, 최신 자료나 외부기관 자료가 빠진 경우엔 답을 지어내지 않고 "근거 부족"으로 보류하도록 만들었습니다. 채점 방식도 함께 손봤습니다 — 사용자가 질문에 쓴 위험한 표현까지 AI의 단정으로 오해하지 않도록, 실제 답변 본문이 단정했는지만 보게 좁혔습니다.
최종 결과:
- 답이 없는 질문 3문항: 3개 모두 "근거 부족"으로 올바르게 보류
- 표준 답변 평가 28문항: 28문항 전부 통과
- 전체 품질검사: PASS
이제 이 위키는 비슷한 문서가 검색돼도 바로 답을 만들지 않고, 근거가 부족하면 멈춰 섭니다. 법률 자료를 다루는 사람에게는 이게 정확도보다 더 안심되는 변화였습니다.
✅ 결과 (After)
Before vs After
항목
Before
After
검색 신뢰도
"잘 찾는 것 같다"는 느낌뿐
안 본 문제(비공개) 점수로 증명
어려운 시험 점수
38점
77점 이상 (계속 측정 중)
복합(멀티홉) 질문
비공개 0%
비공개 첫 진전(0→17%)
근거 없는 질문
답을 지어냄
"근거 부족"으로 보류
개선 방식
감으로 코드 수정
작게 고치고 전체 채점 후 keep/discard
새 자료 추가
검색 규칙 수동 추가(25개 누적)
문서를 만들면 검색이 자동으로 따라옴
결과물
검색 규칙을 감이 아니라 성적표로 판단하는 운영 체계 (Autoresearch 루프)
"외운 것 vs 실력"을 가려내는 비공개 시험 장치
법률 자료를 지어내지 않고 보류하는 정직한 검색
새 정리 문서를 만들면 검색이 자동으로 연결되어, 자료가 스스로 자라는 구조
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
점수 말고 "안 본 문제"로 측정하라. 공개 점수만 보면 AI가 문제를 외웁니다. 일부를 숨긴 비공개 시험(holdout)을 만들어야 진짜 실력을 알 수 있습니다.
작게 고치고 전체를 다시 채점하라. 한 번에 크게 바꾸지 말고, 작은 수정 → 전체 성적표 → keep/discard. 한 쪽을 고치다 다른 쪽을 망가뜨리는 걸 바로 잡아냅니다.
AI가 "모른다" 하게 허용하라. 특히 법률·의료 같은 고위험 분야에선, 지어내는 것보다 "근거 부족"이라 말하는 게 더 가치 있습니다.
막히면 시제품으로 빨리 시험하라. 완벽하게 만들기 전에 거친 시제품으로 돌려보면, 진짜 막힌 곳이 "검색"이 아니라 "채점"이었다는 걸 적은 비용으로 알 수 있습니다.
이렇게 하면 안 돼요
틀린 문제만 콕 집어 고치지 마라. 그건 실력 향상이 아니라 시험 암기입니다. 코드만 5,400줄로 불어나고 새 문제 앞에선 무너집니다.
"점수 올랐네" 하고 바로 채택하지 마라. 다른 곳을 망가뜨렸는지(기존 품질검사) 반드시 같이 확인하세요.
정답표를 너무 좁게 못박지 마라. 똑같이 맞는 자료가 둘인데 하나만 정답으로 두면, AI가 옳게 찾고도 틀렸다고 채점됩니다. 채점이 잘못되면 검색을 아무리 고쳐도 점수에 안 잡힙니다.
🌍 다른 업무에 적용한다면?
이건 법률 자료라서 특별한 게 아닙니다. "내 자료가 많고, AI가 그걸 정확히 찾아 인용해야 하는" 모든 상황에 그대로 적용됩니다.
사내 규정·매뉴얼이 수백 건인 기업의 헬프데스크
논문·임상자료를 인용해야 하는 연구·의료 분야
판례·계약서를 찾아야 하는 법무팀
강의자료·교재가 쌓인 교육 현장
공통 원리는 하나입니다 — AI 검색을 "느낌"으로 운영하지 말고, 시험지와 성적표를 먼저 만들고, 그 점수로 개선을 증명하세요. 그리고 그 시험엔 반드시 AI가 못 보는 비공개 문제를 섞어 두세요.
🚀 앞으로의 계획
복합 질문 천장 뚫기: 질문을 똑똑하게 쪼개는 AI를 검색에 넣거나, 의미 기반 검색 단계를 추가해 지금 구조의 한계를 넘는다.
생활어 → 실무용어 번역: 사용자가 법률용어를 몰라도 예정가격·검사·보증금·물가변동 같은 실무 주제로 잘 번역하는 능력을 높인다.
답변 생성 능력 강화: "찾는 능력"을 충분히 키웠으니, 이제 찾은 근거로 "잘 답하는 능력"을 어려운 문제로 시험한다.
다른 분야 확장: 지금은 공공계약 분야지만, 같은 자가개선 틀을 다른 법률·업무 자료로 넓힌다.
📋 재사용 가능한 프롬프트
프롬프트 1: 어려운 평가 시험지 만들기
내 [자료 분야] 자료를 검색하는 시스템을 평가하려고 해.
실무에서 진짜 물어볼 법한 어려운 질문을 만들어줘. 다음 네 유형을 섞어줘:
(1) 전문용어 없이 일반인 말투로 묻는 질문
(2) 근거 두세 개를 한 번에 찾아야 답할 수 있는 복합 질문
(3) 비슷하지만 다른 제도로 잘못 답하는지 보는 함정 질문
(4) 자료에 없는 걸 물었을 때 "모른다"고 하는지 보는 질문
[자료 분야]를 본인 상황에 맞게 바꾸세요.
프롬프트 2: 외우기 방지 — 비공개 시험 장치
평가 문제의 일부를 "비공개(holdout)"로 떼어 놔줘.
너에게는 비공개 문제의 점수만 보여주고, 어떤 문제인지는 숨겨줘.
개선할 때 공개 점수만 오르고 비공개 점수가 안 오르면,
그건 일반화가 아니라 그 문제들에만 통하는 땜질이라고 알려줘.
프롬프트 3: 안전한 자가개선 루프
검색을 개선할 때 이 절차를 지켜줘:
문제 하나를 고르고 원인 가설을 세운다
아주 작은 수정만 한다
어려운 시험 점수와 함께, 기존에 잘 되던 질문들도 다시 채점한다
둘 다 괜찮으면 남기고(keep), 하나라도 나빠지면 되돌린다(discard)
같은 방향으로 3번 연속 실패하면 멈추고 원인부터 다시 보자.
프롬프트 4: AI가 "모른다"고 말하게 하기
자료에 근거가 없거나 최신·외부기관 자료가 빠진 경우엔,
비슷한 문서가 검색돼도 답을 만들지 말고 "근거 부족"이라고 보류해줘.
특히 [수치·최신 단가·특정 기관 내부자료]는 근거 없이 단정하면 안 돼.
[대괄호 부분]을 본인 분야의 민감한 정보로 바꾸세요.
이 문서는 LLM Wiki에서 지식이 어떻게 동일한 지식으로 취급되고, 어떤 지식이 상대적으로 확정된 지위에 도달하는지를 설명하기 위한 문서다.
핵심 이론은 두 가지다.
1. 지식동일성설 무엇과 무엇을 같은 지식 문제로 볼 것인가? 2. 지식확정력론 같은 지식 문제 안에서 어떤 지식이 상대적으로 확정된 지위를 갖는가?
1. 전체 위치
LLM Wiki 지식체계는 크게 다음 세 층으로 구성된다.
┌──────────────────────────────┐
│ ① 지식정체론 │
├──────────────────────────────┤
│ 이것은 무엇인가? │
│ - Primary Type │
│ - Facets │
│ - Attributes │
└──────────────────────────────┘ ↓ ┌──────────────────────────────┐
│ ② 지식인정론 │
├──────────────────────────────┤
│ 믿을 수 있는가? │
│ - 지식요건해당성 │
│ - 정합성 │
│ - 검증가능성 │
└──────────────────────────────┘ ↓ ┌──────────────────────────────┐
│ ③ 지식질서론 │
├──────────────────────────────┤
│ 어떻게 다룰 것인가? │
│ - 지식동일성설 │
│ - 지식확정력론 │
│ - 지식변경론 │
│ - 지식공존론 │
│ - 지식우선순위론 │
└──────────────────────────────┘
이 문서는 세 번째 층인 지식질서론 중에서도 특히 다음 두 부분을 다룬다.
지식동일성설
→ 어떤 지식들이 서로 비교·충돌·대체 가능한가? 지식확정력론
→ 그 비교 범위 안에서 어떤 지식이 확정적 지위를 갖는가?
2. 왜 지식동일성설이 먼저 필요한가
어떤 지식이 확정적 지위를 갖는지 말하려면, 먼저 그 지식이 무엇과 경쟁하거나 무엇을 대체하는지를 정해야 한다.
예를 들어 다음 두 지식은 서로 직접 경쟁한다.
천동설
지동설
둘은 모두 천체 운동과 우주 구조를 어떤 중심 체계로 설명할 것인가라는 문제에 답한다.
따라서 둘은 동일한 지식 문제 안에서 경쟁하는 지식이다.
반면 다음 둘은 관련은 있지만 동일한 지식 문제라고 보기는 어렵다.
천동설
만유인력
만유인력은 천체 운동을 설명하는 데 중요하지만, 천동설과 지동설이 다투는 “우주 구조를 어떤 중심 체계로 설명할 것인가”라는 자리를 그대로 차지하지는 않는다.
따라서 다음 구분이 필요하다.
동일한 지식 문제
→ 충돌, 대체, 확정력 비교 가능 관련된 지식 문제
→ 보강, 설명, 약화, 연결 가능 별개의 지식 문제
→ 단순 참조 또는 배경지식으로만 연결
3. 지식동일성설의 정의
지식동일성설이란, 서로 다른 문장·주장·문서·이론이 LLM Wiki 안에서 같은 지식 문제를 다루는 것으로 보아 비교·충돌·대체·승계·확정력 판단의 대상이 될 수 있는 범위를 정하는 이론이다.
짧게 말하면 다음 질문에 답한다.
무엇과 무엇을 같은 지식으로 볼 것인가?
4. 지식동일성 판단 요소
지식동일성을 판단할 때는 다음 요소들을 본다.
knowledge_identity_factors: primary_type: question: "Fact, Theory, Evaluation, State, Norm, Plan 등 같은 유형인가?" issue: question: "같은 문제에 답하고 있는가?" conclusion: question: "같은 결론을 말하는가?" context: question: "같은 자료·사실·시대·도메인 맥락에서 말하는가?" answer_slot: question: "LLM Wiki에서 같은 canonical answer 자리를 차지하려 하는가?" explanatory_role: question: "같은 현상을 설명하거나 같은 개념적 역할을 수행하는가?" scope: question: "시간, 장소, 도메인, 적용 범위가 같은가?" practical_effect: question: "답변이나 운영상 효과가 같은가?" source_or_ground: question: "같은 출처나 근거에 의존하는가?"
모든 경우에 같은 요소를 동일한 비중으로 보지는 않는다.
지식 유형에 따라 어떤 요소를 더 중시할지가 달라진다.
5. 네 가지 지식동일성 모델
지식동일성은 하나의 기준으로만 판단하기 어렵다.
LLM Wiki에서는 지식의 종류와 문서의 목적에 따라 서로 다른 동일성 모델을 사용할 수 있다.
기본 모델은 다음 네 가지다.
1. 출처근거형 동일성
2. 결론맥락형 동일성
3. 결론중심형 동일성
4. 기능역할형 동일성
좁은 기준에서 넓은 기준으로 배열하면 다음과 같다.
좁음 넓음
│ │
▼ ▼ 출처근거형 동일성 ↓
결론맥락형 동일성 ↓
결론중심형 동일성 ↓
기능역할형 동일성
6. 출처근거형 동일성
6.1 핵심 질문
이 주장은 같은 출처와 같은 근거에서 나온 것인가?
6.2 정의
출처근거형 동일성은 같은 결론처럼 보이는 주장이라도 그 주장을 떠받치는 출처, 자료, 문헌, 관찰, 근거, 이론적 기반이 다르면 별개의 지식으로 보는 기준이다.
6.3 예시
Claim A:
세종대왕은 조선의 4대 왕이다.
근거: 원자료 A Claim B:
세종대왕은 조선의 4대 왕이다.
근거: 역사 교재 B Claim C:
세종대왕은 조선의 4대 왕이다.
근거: 강의자료 C
출처근거형 동일성에서는 A, B, C를 서로 다른 claim으로 볼 수 있다.
결론은 같지만, 각 claim이 의존하는 근거가 다르기 때문이다.
6.4 적합한 용도
source summary
논문별 정리
강의자료별 정리
원문 주석
문헌 비교
자료별 claim 추출
6.5 장점
출처 차이를 보존한다.
원자료 추적성이 높다.
문헌별 미세한 차이를 놓치지 않는다.
6.6 단점
같은 결론의 claim이 너무 많이 쪼개질 수 있다.
중복이 많아진다.
canonical answer를 만들기 어렵다.
지식확정력 형성이 느려질 수 있다.
7. 결론맥락형 동일성
7.1 핵심 질문
이 주장은 같은 결론을 말하고, 같은 자료·사실·도메인 맥락에 근거하는가?
7.2 정의
결론맥락형 동일성은 최종 결론뿐 아니라 그 결론이 의존하는 자료군, 사실관계, 시대, 도메인, 범위가 같을 때 같은 지식으로 보는 기준이다.
7.3 예시
Claim A:
세종대왕은 조선의 4대 왕이다.
맥락: 조선 왕위 계승 순서 Claim B:
세종은 태종 다음 왕위에 오른 조선의 네 번째 왕이다.
맥락: 조선 왕위 계승 순서
표현은 다르지만 결론과 맥락이 같으므로 같은 지식으로 볼 수 있다.
반면 다음 claim은 같은 인물을 다루지만 동일한 지식은 아니다.
Claim C:
세종대왕은 훌륭한 왕이다.
맥락: 훈민정음 창제, 과학기술 진흥, 통치 업적
C는 평가적 지식이고, A·B는 왕위 계승에 관한 사실 지식이다.
7.4 적합한 용도
일반 Fact claim
역사적 사실
과학적 사실
법률 명제
일반 wiki claim
7.5 장점
너무 좁지도 않고 너무 넓지도 않다.
일반 LLM Wiki의 기본값으로 적합하다.
중복 claim을 줄이면서도 맥락 차이를 보존한다.
7.6 단점
어디까지를 같은 맥락으로 볼지 판단이 필요하다.
LLM의 해석이 개입될 수 있다.
7.7 기본값 추천
일반적인 LLM Wiki claim에는 결론맥락형 동일성을 기본값으로 두는 것이 가장 좋다.
default_identity_model: conclusion_contextual
label_ko: "결론맥락형 동일성"
8. 결론중심형 동일성
8.1 핵심 질문
최종 답이 같은가?
8.2 정의
결론중심형 동일성은 출처, 근거, 설명 방식이 달라도 최종 결론이나 답변 자리가 같으면 같은 지식으로 보는 기준이다.
8.3 예시
A: raw source는 수정하지 않는다.
B: 원자료는 immutable layer로 보존한다.
C: LLM은 raw 자료를 직접 덮어쓰지 않는다.
표현은 다르지만 최종 운영 결론은 같다.
따라서 하나의 policy claim으로 묶을 수 있다.
8.4 적합한 용도
운영정책
프로젝트 규칙
canonical answer
architecture decision
반복 사용되는 실무 기준
8.5 장점
중복을 크게 줄인다.
하나의 canonical answer를 만들기 쉽다.
LLM이 일관된 답변을 하기 좋다.
8.6 단점
근거 차이를 뭉갤 수 있다.
시대, 범위, source 차이를 놓칠 수 있다.
연구용 wiki에는 지나치게 넓을 수 있다.
9. 기능역할형 동일성
9.1 핵심 질문
이 지식은 같은 설명 기능이나 개념적 역할을 수행하는가?
9.2 정의
기능역할형 동일성은 표현, 근거, 출처, 세부 결론이 조금 달라도 LLM Wiki 안에서 같은 설명 기능, 이론적 역할, 개념적 위치를 차지하면 같은 지식 범주로 보는 기준이다.
9.3 예시: 천동설
다음 표현들은 서로 다르지만 같은 기능적 지식 범주로 묶을 수 있다.
천동설
지구중심 우주론
프톨레마이오스적 천문 체계
고대·중세의 지구중심 우주 체계
이들은 모두 다음 기능을 수행한다.
천체 운동과 우주 구조를 지구 중심으로 설명하는 체계
9.4 예시: 지동설
다음 표현들도 하나의 기능적 지식 범주로 묶을 수 있다.
지동설
태양중심설
코페르니쿠스 체계
태양중심 천문 체계
이들은 모두 다음 기능을 수행한다.
천체 운동과 태양계 구조를 태양 중심으로 설명하는 체계
9.5 적합한 용도
concept page
theory page
paradigm page
학설 비교
과학사 정리
큰 개념의 통합 문서
9.6 장점
여러 표현과 근거를 종합하기 좋다.
이론, 패러다임, 학설, 개념을 다루기에 적합하다.
LLM Wiki의 concept layer에 잘 맞는다.
9.7 단점
동일성 범위가 너무 넓어질 수 있다.
서로 다른 이론을 과도하게 통합할 위험이 있다.
source별 차이가 흐려질 수 있다.
10. 네 가지 동일성 모델 비교
모델
핵심 기준
범위
장점
위험
적합한 곳
출처근거형 동일성
source, 근거
좁음
출처 보존
claim 과분화
source summary
결론맥락형 동일성
결론 + 맥락
중간
균형적
맥락 판단 필요
일반 claim
결론중심형 동일성
최종 결론
넓음
canonical화 용이
차이 뭉개짐
policy, 운영규칙
기능역할형 동일성
설명 기능·개념 역할
매우 넓음
종합·이론화에 강함
과잉통합 위험
concept, theory
11. 지식유형별 권장 동일성 모델
지식 유형
권장 모델
이유
Resource
출처근거형
파일, 출처, provenance가 중요
Fact
결론맥락형
결론과 사실 맥락이 모두 중요
Theory
기능역할형
설명 기능과 이론적 역할이 중요
Interpretation
결론맥락형 또는 기능역할형
해석 대상과 해석 기능이 중요
Evaluation
결론맥락형
평가 결론과 평가 기준이 중요
State
주체-시점형
누구의 상태인지, 언제의 상태인지가 중요
Norm
결론중심형 또는 결론맥락형
최종 규범 결론과 적용 범위가 중요
Plan
행위-목적형
actor, action, time, goal이 중요
Policy
결론중심형
최종 운영 결론의 일관성이 중요
Concept Page
기능역할형
개념적 역할과 통합 기능이 중요
Source Summary
출처근거형
원문별 차이를 보존해야 함
12. 특수 동일성 모델
위 네 가지 모델 외에 일부 지식 유형에는 별도 모델이 필요하다.
12.1 주체-시점형 동일성
State에 적합하다.
누구의 상태인가?
언제의 상태인가?
어떤 맥락에서 발생했는가?
예:
“나는 피렌체를 좋아한다.”
이 문장은 객관적 사실 claim이 아니라 사용자 상태다.
따라서 다음 기준을 본다.
state_identity: owner: user state_type: preference object: Florence recorded_at: date
12.2 행위-목적형 동일성
Plan에 적합하다.
누가?
무엇을?
언제?
무슨 목적으로?
예:
“나는 10월에 피렌체에 갈 계획이다.”
plan_identity: actor: user action: travel destination: Florence time: October goal: travel
13. 천동설, 지동설, 만유인력 사례
13.1 천동설과 지동설
천동설과 지동설은 동일한 지식 범주 안에서 경쟁한다.
knowledge_identity: identity_model: functional_role identity_class: astronomical_world_system canonical_question: "천체 운동과 우주 구조를 어떤 중심 체계로 설명할 것인가?" relation: competing_paradigms same_identity_class: true
따라서 다음 논의가 가능하다.
천동설의 지식확정력 하락
지동설의 지식확정력 상승
지동설에 의한 천동설의 대체
천동설의 역사적 이론으로의 재분류
13.2 천동설과 만유인력
천동설과 만유인력은 관련은 있지만 같은 지식 범주에 속하지 않는다.
knowledge_identity: item_1: geocentrism item_2: universal_gravitation relation: related_explanatory_framework same_identity_class: false
천동설은 우주 구조와 천체 배열을 설명하는 세계체계다.
만유인력은 물체 간 인력과 운동 원리를 설명하는 법칙이다.
따라서 만유인력은 천동설을 직접 대체한다기보다, 천동설의 설명력을 약화시키거나 지동설적 세계관을 보강하는 관련 지식으로 처리하는 것이 적절하다.
13.3 지동설과 만유인력
지동설과 만유인력도 동일한 지식은 아니다.
knowledge_identity: item_1: heliocentrism item_2: universal_gravitation relation: supporting_explanatory_relation same_identity_class: false
만유인력은 지동설이 설명하려는 천체 운동을 더 깊은 물리 법칙으로 설명하는 데 기여한다.
그러나 지동설이 차지하는 answer slot을 만유인력이 그대로 차지하는 것은 아니다.
14. 지식확정력론의 정의
지식확정력론이란, 동일한 지식 범주 안에서 특정 지식이 어느 정도 상대적으로 확정된 지위를 갖는지를 판단하는 이론이다.
짧게 말하면 다음 질문에 답한다.
이 지식은 해당 지식질서 안에서 어느 정도 확정적인가?
여기서 “확정적”이라는 말은 절대적 진리를 뜻하지 않는다.
그 시대, 그 공동체, 그 wiki, 그 지식체계 안에서 상대적으로 확정적이라는 뜻이다.
15. 지식확정력의 기능
지식확정력은 다음 기능을 한다.
기존 지식의 조용한 덮어쓰기 방지
경쟁 지식 사이의 상대적 지위 표시
새 지식이 기존 지식을 대체할 수 있는지 판단
기존 지식을 현재 사실, 역사적 이론, 폐기된 이론 등으로 재분류
지식 변경 절차를 요구
16. 지식확정력의 판단 요소
지식확정력은 단순히 검증가능성만으로 결정되지 않는다.
knowledge_finality_factors: confirmability: description: "출처와 증거에 의해 어느 정도 확인되는가?" coherence: description: "현재 지식질서와 얼마나 정합적인가?" consensus: description: "관련 공동체나 wiki 내부에서 어느 정도 합의되어 있는가?" repeated_validation: description: "반복적으로 검증되었는가?" failed_challenges: description: "반대 claim들이 충분히 검토되었고 실패했는가?" explanatory_power: description: "경쟁 지식보다 더 많은 현상을 잘 설명하는가?" centrality: description: "지식질서 안에서 중심적인 위치를 차지하는가?" scope_clarity: description: "적용 범위가 명확한가?" temporal_durability: description: "시간을 견디며 유지되었는가?" revision_history: description: "수정과 반박의 이력이 어떻게 축적되었는가?"
17. 검증가능성과 지식확정력의 차이
검증가능성과 지식확정력은 관련이 있지만 같지 않다.
확증가능성
= 왜 이 지식을 받아들일 수 있는가?
= 정당화 지식확정력
= 왜 이 지식을 쉽게 바꿀 수 없는가?
= 정착
검증가능성이 높아도 지식확정력이 낮을 수 있다.
예:
현재 특정 도시의 인구는 약 950만 명이다.
공식 통계로 확증 가능하지만, 시간이 지나면 쉽게 바뀔 수 있다.
반대로 검증가능성은 중간이지만 지식확정력이 높은 경우도 있다.
예:
세종대왕은 훌륭한 왕이다.
가치판단이 포함되어 검증가능성은 중간일 수 있지만, 장기간의 역사적 평가와 사회적 합의로 인해 지식확정력은 높을 수 있다.
18. 지식확정력 등급
LLM Wiki에서는 지식확정력을 다음 단계로 표시할 수 있다.
draft
→ 아직 지식으로 편입되지 않음 admitted
→ 지식요건·정합성·확증가능성을 통과 contested
→ 동일 범주 내 경쟁 claim 존재 settled
→ 상대적으로 확정된 지식 canonical
→ 해당 wiki에서 기본 답변 지위를 가짐 superseded
→ 후속 지식에 의해 대체됨 historical
→ 현재 사실 지위는 잃었지만 역사적 지위로 보존됨
19. 지식확정력의 범위
지식확정력은 무제한으로 확장되지 않는다.
어떤 지식이 확정적이라고 하더라도, 그 확정력은 특정 범위 안에서만 작동한다.
예를 들어 지동설의 지식확정력은 다음 범위에서 강하다.
태양계에서 지구와 행성이 태양 주위를 공전한다는 설명
현대 천문학에서 천동설이 현재 사실 명제로 받아들여지지 않는다는 설명
하지만 다음 명제까지 확장되면 안 된다.
태양이 우주의 절대 중심이다.
우주의 모든 구조가 태양을 중심으로 배열되어 있다.
중력 법칙의 모든 세부 내용을 지동설이 설명한다.
따라서 지식확정력에는 항상 scope가 필요하다.
knowledge_finality_scope: applies_to: - "태양계 행성 운동의 기본 구조" - "지구가 태양 주위를 공전한다는 설명" does_not_apply_to: - "태양이 우주의 절대 중심이라는 주장" - "은하계 전체 구조" - "중력 법칙의 상세 수식"
20. 쿤식 패러다임 전환 사례
과학사는 지식확정력론을 설명하기에 좋은 사례다.
특정 시대에는 천동설이 해당 지식질서 안에서 강한 지식확정력을 가졌다.
천동설은 당시 관측과 이론 체계 안에서 세계를 설명하는 기본 모델이었다.
그러나 시간이 지나면서 천동설이 설명하기 어려운 문제들이 쌓였고, 지동설이 대안적 설명으로 등장했다.
초기 지동설은 곧바로 확정적 지위를 얻지 못했다.
천동설
→ 기존 지식질서 안에서 강한 확정력 보유 지동설 초기
→ 기존 지식질서와 충돌
→ 그러나 점차 확증가능성 상승 경쟁 기간
→ 천동설은 자기 체계 안에서 반박과 보정을 시도
→ 지동설은 새로운 관측·계산·설명력으로 지위를 강화 전환 이후
→ 천동설의 지식확정력 하락
→ 지동설의 지식확정력 상승
→ 지동설이 새로운 canonical 지식으로 정착
→ 천동설은 historical theory로 재분류
이 과정에서 핵심은 다음이다.
지동설은 천동설과 동일한 지식 문제를 다루었기 때문에 천동설을 대체할 수 있었다.
만약 동일한 지식 문제를 다루지 않았다면, 지동설은 천동설을 직접 대체하는 것이 아니라 단순히 관련 지식으로만 남았을 것이다.
21. 지식동일성설과 지식확정력론의 관계
두 이론의 관계는 다음과 같다.
지식동일성설
→ 비교 가능한 지식들의 범위를 정한다. 지식확정력론
→ 그 범위 안에서 어떤 지식이 확정적 지위를 갖는지 정한다.
아스키로 표현하면 다음과 같다.
새 claim 등장 │ ▼
지식동일성 판단 │ ├─ 동일성 없음 │ └─ related claim으로 연결 │ └─ 동일성 있음 │ ▼ 지식확정력 비교 │ ├─ 기존 claim 확정력 우세 │ └─ 새 claim rejected / disputed / view로 보존 │ ├─ 새 claim 확정력 상승 │ └─ revision_candidate │ └─ 새 claim 확정력 우세 └─ 기존 claim superseded / historical 처리
핵심 원칙은 다음이다.
지식동일성설 없이 지식확정력론 없음.
22. LLM Wiki schema 예시: 지동설
id: theory-heliocentrism-001
primary_type: Theory identity: model: functional_role identity_class: astronomical_world_system canonical_question: "천체 운동과 우주 구조를 어떤 중심 체계로 설명할 것인가?" answer_slot: dominant_astronomical_world_system competing_items: - theory-geocentrism-001 admission: 지식요건해당성: pass 정합성: coherent_in_modern_astronomy 검증가능성: settled finality: label: 지식확정력 level: canonical scope: applies_to: - "태양계에서 지구와 행성이 태양 주위를 공전한다는 설명" excludes: - "태양이 우주의 절대 중심이라는 주장" basis: - high_confirmability - broad_consensus - repeated_validation - centrality_in_modern_astronomy order_relations: supersedes: - theory-geocentrism-001 preserves_as_historical: - theory-geocentrism-001
23. LLM Wiki schema 예시: 천동설
id: theory-geocentrism-001
primary_type: Theory identity: model: functional_role identity_class: astronomical_world_system canonical_question: "천체 운동과 우주 구조를 어떤 중심 체계로 설명할 것인가?" answer_slot: historical_astronomical_world_system admission: 지식요건해당성: pass 정합성: coherent_as_historical_theory 검증가능성: strong_as_historical_claim finality: label: 지식확정력 level: historical former_level: canonical_in_pre_modern_astronomy current_scope: applies_to: - "과학사적 이론" - "지구중심 우주론의 역사적 설명" excludes: - "현대 천문학의 현재 사실 명제" order_relations: superseded_by: - theory-heliocentrism-001
24. 지식확정력 판단 절차
1. 새 지식 또는 새 claim이 들어온다. 2. 지식정체론으로 유형을 정한다. - Fact인가? - Theory인가? - Evaluation인가? - State인가? - Norm인가? - Resource인가? 3. 지식인정론으로 기본 편입 가능성을 본다. - 지식요건해당성 - 정합성 - 검증가능성 4. 지식동일성설로 기존 지식과의 관계를 본다. - 같은 지식 문제인가? - 관련 지식인가? - 별개 지식인가? 5. 동일한 지식 문제라면 지식확정력을 비교한다. - 기존 지식이 여전히 우세한가? - 새 지식이 도전 claim인가? - 새 지식이 revision candidate인가? - 새 지식이 기존 지식을 대체할 만큼 강한가? 6. 결과를 기록한다. - admitted - contested - settled - canonical - superseded - historical - rejected
25. 결과 처리 규칙
if_same_identity_class: and_new_claim_weaker: action: - mark_as_view - keep_existing_finality and_new_claim_plausible: action: - mark_as_contested - add_to_dispute_register and_new_claim_stronger_but_not_settled: action: - mark_as_revision_candidate - lower_existing_finality_if_needed and_new_claim_canonical: action: - supersede_existing_claim - preserve_existing_as_historical_or_archived if_related_but_not_same_identity_class: action: - link_as_related - mark_relation_type - do_not_supersede_directly if_unrelated: action: - store_separately - no_finality_comparison
26. 최종 핵심 명제
이 문서의 핵심 명제는 다음과 같다.
1. 지식확정력은 단순히 개별 지식의 강도가 아니라, 동일한 지식 범주 안에서 경쟁하는 지식들 사이의 상대적 지위다. 2. 따라서 지식확정력론은 반드시 지식동일성설을 전제로 한다. 3. 지식동일성설은 무엇과 무엇을 같은 지식 문제로 볼 것인지를 정한다. 4. 지식확정력론은 같은 지식 문제 안에서 어떤 지식이 확정적 지위를 얻었는지를 정한다. 5. 새 지식은 기존 지식과 동일한 범주에 있을 때만 기존 지식을 직접 대체할 수 있다. 6. 관련성은 동일성이 아니다. 7. 동일성이 없으면 대체가 아니라 연결, 보강, 약화, 배경화로 처리한다. 8. 지식확정력은 절대적 진리가 아니라 특정 시대·도메인·wiki 질서 안에서의 상대적 확정성이다.
27. 최종 요약
LLM Wiki에서 지식은 단순히 저장되는 것이 아니라, 서로 비교되고, 충돌하고, 대체되고, 역사화된다.
이를 제대로 처리하려면 먼저 다음을 정해야 한다.
어떤 지식들이 같은 문제를 다루는가?
이것이 지식동일성설이다.
그 다음에야 다음을 판단할 수 있다.
그 문제 안에서 어떤 지식이 확정적 지위를 가지는가?
이것이 지식확정력론이다.
따라서 LLM Wiki의 지식질서론 안에서 두 이론은 다음 순서로 작동한다.
지식동일성설 ↓
지식확정력론 ↓
지식변경론 ↓
지식공존론 ↓
지식우선순위론
이 구조를 사용하면 LLM Wiki는 새로운 정보를 무조건 기존 정보에 덮어쓰지 않고,
기존 지식과 새 지식의 관계를 먼저 판단한 뒤,
대체·공존·보강·역사화·폐기 중 적절한 처리를 선택할 수 있다.
한 줄 요약
한글 문서인 .hwp, .hwpx를 Markdown으로 변환할 때 픽셀 단위 화면 재현이 아니라 제목, 문단, 표, 이미지, 수식, 각주, 메타데이터 같은 의미 구조를 보존하는 방향으로 CLI/라이브러리 설계를 정리하고, 실제 변환 품질을 높이기 위한 회귀 테스트와 보완 작업까지 진행했습니다.
이런 분들께 도움돼요
한글 문서를 Markdown, Obsidian, Git 기반 문서로 옮기고 싶은 분
HWP/HWPX 변환을 단순 텍스트 추출이 아니라 편집 가능한 문서 구조로 다루고 싶은 분
AI와 함께 복잡한 문서 변환 도구의 설계 기준, 테스트 전략, 단계별 개발 계획을 잡고 싶은 분
"일단 변환은 되는데 표, 이미지, 수식, 각주가 망가지는" 문제를 겪어본 분
시작점: HWP를 Markdown으로 바꾸는 일은 생각보다 복잡했다
처음 목표는 단순했습니다.
.hwp 또는 .hwpx 문서를 넣으면 사람이 다시 읽고 편집하기 좋은 Markdown 문서와 첨부 자산 폴더가 나오는 도구를 만들고 싶었습니다.
하지만 실제로 들여다보니 이건 단순한 "파일 포맷 변환" 문제가 아니었습니다.
한글 문서에는 표, 병합 셀, 보도자료 상단 장식 표, 각주, 수식, 이미지, 캡션, 머리말/꼬리말, 도형 텍스트, HWP 고유 control 문자 같은 요소가 섞여 있습니다. 이것을 Markdown으로 옮길 때 화면 모양만 따라가면 결과물이 너무 지저분해지고, 반대로 텍스트만 뽑으면 문서의 의미가 많이 사라집니다.
그래서 기준을 먼저 정했습니다.
Markdown 변환의 목표는 한컴 화면을 픽셀 단위로 재현하는 것이 아니라, 사람이 다시 읽고 고칠 수 있는 의미 구조를 보존하는 것입니다.
"목표는 화면 복제가 아니라 다시 편집할 수 있는 Markdown 구조입니다."
만든 것
이 작업에서 정리한 산출물은 HWP/HWPX to Markdown 변환기 개발계획서와 초기 구현 보완 방향입니다.
대상 산출물은 다음과 같습니다.
.hwp, .hwpx 입력을 받는 CLI
Markdown .md 출력 파일
이미지와 첨부 파일을 담는 assets 폴더
변환 중 손실과 경고를 기록하는 report.json
CLI, GUI, Obsidian 플러그인 등에서 재사용할 수 있는 변환 라이브러리
예상 사용 방식은 이런 형태입니다.
hwp2md input.hwp -o output.md
hwp2md input.hwpx -o docs/output.md --assets-dir docs/output.assets
hwp2md input.hwp --format obsidian --image-mode extract --table-mode gfm
초기 버전의 목표는 완벽한 변환기가 아닙니다.
실제 문서를 Markdown 초안으로 안정적으로 바꾸고, Markdown으로 표현하기 어려운 정보는 조용히 버리지 않고 리포트에 남기는 도구입니다.
사용한 도구와 참고한 구조
이 프로젝트에서 AI에게 맡긴 핵심 역할은 "복잡한 변환 문제를 제품 설계와 테스트 가능한 작업 단위로 쪼개는 것"이었습니다. 단순히 코드를 바로 만들기보다, 어떤 정보를 보존하고 어떤 정보는 fallback으로 남길지 먼저 정리했습니다.
주요 참고 구조는 다음과 같습니다.
HOP: HWP/HWPX를 여는 데스크톱 앱 구조와 제품 계층 참고
rhwp: HWP/HWPX 파서와 문서 모델을 다루는 핵심 엔진 후보
obsidian-hwp-writer: Markdown과 HWPX 스타일이 연결되는 반대 방향 흐름 참고
Rust workspace: CLI와 core library, rhwp adapter, Markdown renderer를 분리하는 구조
회귀 테스트: 실제 변환 중 깨졌던 케이스를 다시 검증하는 안전장치
중요한 판단은 rhwp 같은 파서/엔진 계층과 Markdown 변환 계층을 분리하는 것이었습니다.
HWP/HWPX를 읽는 일과 Markdown으로 의미 있게 바꾸는 일은 서로 다른 책임입니다. 파서는 원본 구조를 최대한 정확히 읽고, 변환기는 그 구조를 사람이 편집할 수 있는 Markdown 표현으로 바꿔야 합니다.
진행 과정
1. 변환 기준을 "화면"이 아니라 "의미 구조"로 잡았다
처음부터 모든 레이아웃을 Markdown으로 재현하려고 하면 금방 막힙니다.
Markdown은 문서 편집과 공유에는 좋지만, 한글 문서의 복잡한 지면 배치와 장식 요소를 모두 담기에는 맞지 않습니다. 그래서 변환 기준을 이렇게 정했습니다.
제목은 Markdown heading으로 옮긴다.
일반 문단은 읽기 좋은 문단으로 나눈다.
단순 표는 GFM table로 옮긴다.
병합 셀이나 복잡한 표는 HTML table fallback을 쓴다.
이미지는 assets 폴더로 추출하고 Markdown 링크로 연결한다.
수식과 각주는 가능한 Markdown으로 보존하고, 어려운 것은 리포트에 남긴다.
머리말, 꼬리말, 바탕쪽은 기본 본문에 섞지 않는다.
이 기준 덕분에 "어디까지 변환할 것인가"를 매번 새로 고민하지 않고, 기능별 정책으로 나눌 수 있었습니다.
2. 중간 IR을 두는 구조로 설계했다
HWP/HWPX를 읽자마자 Markdown 문자열을 만들면 테스트와 디버깅이 어려워집니다.
그래서 중간에 Markdown Semantic IR을 두는 구조로 설계했습니다.
Document metadata blocks[] Block Heading(level, inlines, source) Paragraph(inlines) List(kind, items, nesting) Table(rows, caption, fallback) Image(asset_id, alt, caption) Equation(source, fallback_image) Footnote(id, blocks) HtmlBlock(reason, html) UnknownBlock(source_ref, diagnostic)
이 구조의 장점은 분명했습니다.
원본 파싱 결과가 이상한지, 의미 구조 변환이 이상한지, Markdown 렌더링이 이상한지를 따로 볼 수 있습니다. 나중에 GFM, CommonMark, Obsidian 친화 출력처럼 Markdown 방언을 나누기도 쉬워집니다.
3. 실제로 깨지는 변환 케이스를 하나씩 보완했다
개발계획서에는 이미 구현 보완 내역도 같이 정리되어 있습니다.
예를 들어 HWP 표는 단순히 텍스트를 줄 단위로 뽑으면 구조가 쉽게 깨집니다. 그래서 표 control과 cell record를 묶어 행, 열, 병합 정보를 복원하고, 단순 표는 GFM으로, 병합 표는 HTML fallback으로 출력하도록 방향을 잡았습니다.
보도자료 문서에서 자주 나오는 상단 장식 표도 별도 처리 대상이었습니다. 겉으로는 표지만 본문 표라기보다 배포일시, 보도일시, 담당부서, 담당자를 담은 메타데이터에 가깝습니다. 그래서 본문에서는 제거하되 frontmatter와 report.json metadata에 남기는 방식으로 정리했습니다.
실제 보완한 문제들은 꽤 구체적입니다.
HWP inline 제어문자 때문에 ('12)→)→)처럼 깨지던 연도별 수치 문자열 보정
HWP BMP 이미지를 PNG로 변환
공백과 괄호가 있는 자산 경로를 Markdown <...> destination으로 출력
재변환 시 이전 generated assets가 새 결과와 섞이지 않도록 정리
캡션 직후 그림 control을 감지해 해당 위치에 이미지 우선 배치
단순 분수 수식은 Markdown 수식 fallback으로 보존
각주 control은 placeholder로 남겨 후속 복원 대상으로 추적
HWPX inline style 태그를 bold, italic, underline, sub, sup 표현으로 보존
[1], 붙임1, 짧은 1. 제목, 가. 제목 같은 문단을 목록이 아니라 heading 후보로 승격
구조화하지 못한 HWP control id를 report.json warning/loss에 남김
여기서 좋았던 점은 "못 바꾸는 것"을 숨기지 않는 방향으로 설계했다는 점입니다.
변환기가 완벽하지 않아도, 무엇이 손실됐고 무엇이 fallback 처리됐는지 알 수 있으면 사람이 검수할 수 있습니다.
4. 변환 리포트를 기본 산출물로 넣었다
Markdown 파일만 나오면 사용자는 무엇이 누락됐는지 알기 어렵습니다.
그래서 output.report.json을 기본 산출물로 두는 설계를 넣었습니다.
{ "source": "input.hwp", "format": "hwp", "pages": 12, "blocks": 180, "assets": 8, "warnings": [ { "code": "TABLE_HTML_FALLBACK", "message": "Merged cells require HTML table fallback", "sourceRef": "section=0 paragraph=34" } ], "losses": [ { "code": "TEXT_COLOR_DROPPED", "count": 12 } ]
}
이 리포트는 단순 로그가 아니라 변환 품질을 개선하는 기준표가 됩니다.
예를 들어 수식이 fallback 처리됐는지, 병합 표가 HTML로 나갔는지, 색상 정보가 빠졌는지, 알 수 없는 control id가 있었는지를 나중에 다시 추적할 수 있습니다.
5. 회귀 테스트를 변환 품질의 중심에 뒀다
문서 변환기는 한번 고친 문제가 다시 깨지기 쉽습니다.
특히 HWP/HWPX는 실제 문서마다 구조가 다르고, 표와 이미지가 섞이면 엣지 케이스가 계속 나옵니다. 그래서 tests/test_hwp2md.py 회귀 테스트로 보완 내역을 검증하도록 정리했습니다.
검증 대상으로 잡은 항목은 다음과 같습니다.
파일명 보존
metadata 추출
heading 추론
inline 수치 복원
자산 링크
BMP 변환
수식 fallback
assets 정리
170508 샘플 변환
Before vs After
Before는 이런 상태였습니다.
HWP/HWPX를 Markdown으로 바꿀 때 무엇을 보존해야 하는지 기준이 흐릿했다.
표, 이미지, 수식, 각주 같은 요소가 케이스마다 다르게 깨질 수 있었다.
실패한 변환이 조용히 누락되면 사용자가 나중에 알아차리기 어려웠다.
기능을 어디서부터 구현해야 할지 범위가 커 보였다.
After는 이렇게 바뀌었습니다.
변환 목표를 "의미 구조 보존"으로 정의했다.
파서, 중간 IR, Markdown renderer, asset extractor, report를 분리했다.
단순 표와 복잡한 표의 출력 정책을 나눴다.
변환 손실과 경고를 report.json에 남기는 기준을 만들었다.
MVP와 v0.1.0 성공 기준을 분리했다.
실제 깨졌던 변환 케이스를 회귀 테스트로 묶었다.
단계별 개발 계획
이번 계획에서 가장 현실적이었던 부분은 "완벽한 변환기"를 바로 만들겠다고 하지 않은 점입니다.
단계는 이렇게 쪼갰습니다.
기술 검증: rhwp 소스와 라이선스 검토, 샘플 문서 파싱 확인
프로젝트 골격: Rust workspace, CLI 인자, 입력 감지, dump-ir 명령
기본 Markdown 변환: 문단, heading, 인라인 서식, 목록, frontmatter
표, 이미지, 각주: GFM table, HTML fallback, assets 추출
수식과 복잡 객체: 수식 원문, 이미지 fallback, 도형 텍스트, 머리말/꼬리말
품질 개선과 배포: OS별 빌드, 대용량 문서, batch 변환, README 작성
v0.1.0의 기준도 작게 잡았습니다.
HWP/HWPX 입력 자동 감지
텍스트, 제목, 문단, 목록 출력
단순 표를 GFM table로 출력
이미지를 assets 폴더로 추출
변환 리포트 생성
실패 시 panic 없이 진단 메시지 출력
이렇게 나누니 당장 할 일과 나중에 할 일이 분리됐습니다.
결과와 배운 점
이 작업에서 가장 크게 배운 점은, AI와 함께 개발할 때도 "무엇을 만들지"보다 "무엇을 보존할지"를 먼저 정해야 한다는 것입니다.
HWP/HWPX 변환은 표면적으로는 파일 변환이지만, 실제로는 문서의 의미를 재구성하는 작업에 가깝습니다. 제목인지 목록인지, 장식 표인지 메타데이터인지, 본문 이미지인지 캡션 뒤에 붙은 그림인지 판단해야 합니다.
또 하나의 교훈은 손실을 없애는 것만큼 손실을 기록하는 것도 중요하다는 점입니다.
Markdown으로 표현하기 어려운 요소를 억지로 예쁜 출력으로 숨기면 나중에 검수하기 어렵습니다. 반대로 report.json에 warning과 loss를 남기면, 도구가 아직 못 하는 일을 다음 개선 작업으로 연결할 수 있습니다.
현재 이 프로젝트는 "한 번에 모든 문서를 완벽하게 변환하는 도구"가 아니라, 실제 한글 문서를 Markdown 초안으로 안정적으로 옮기기 위한 구조와 검증 기반을 잡은 상태입니다.
다른 사람이 비슷하게 해보려면
바로 코드를 만들기 전에 이 순서로 접근하는 것이 좋았습니다.
변환 결과의 목적을 정한다. 화면 재현인지, 편집 가능한 Markdown인지 먼저 결정한다.
원본 문서에서 반드시 보존할 요소를 목록화한다.
Markdown으로 표현이 어려운 요소는 HTML fallback 또는 report로 남긴다.
파서와 renderer 사이에 중간 IR을 둔다.
실제로 깨진 문서를 fixture로 만들고 회귀 테스트에 넣는다.
v0.1.0 기준을 작게 잡고, 실패 시 진단 메시지를 잘 내는 쪽을 우선한다.
다음에 해볼 것
rhwp 연동 방식 확정
공개 샘플과 private fixture 분리
dump-ir 명령으로 실제 문서 구조 확인
문단, 제목, 목록부터 snapshot 테스트 구축
표와 이미지 변환 케이스 확장
Obsidian 친화 출력 옵션 정리
장기적으로 hwp2md serve, hwp2md watch, Obsidian 플러그인 검토
📝 한줄 요약
2014년부터 쌓인 텔레그램 대화 55,000개를 AI와 함께 주제별 아카이브로 정리했다. 이제 "우리 그때 무슨 얘기 많이 했지?"를 수초 안에 찾을 수 있다.
바쁘시면 이것만 읽어도 돼요:
Codex CLI로 12년치 텔레그램 대화(55,514개 메시지)를 2,706개 청크로 정리
신앙·법조·정치·여행·AI·우정 6개 주제 보고서 자동 생성
대화 패턴만으로 두 사람의 MBTI까지 추정
첫 보고서가 마음에 안 들면 "수박겉핥기 같다"고 말하면 된다 — 그게 전부
앞으로 다른 친구 대화도 같은 방식으로 아카이빙 예정
AI에게 "계획만 짜고 실행은 보류해"가 생각보다 강력한 요청이다
🎯 이런 분들께 도움돼요
수년 치 카톡·텔레그램 대화가 앱 안에 묻혀있는 사람
언젠가 그 기록이 사라질까봐 걱정되는 사람
AI로 "그때 우리 뭔 얘기 했지?"를 검색하고 싶은 사람
😫 문제 상황 (Before)
텔레그램 앱 안에 2014년부터 쌓인 대화가 있었다. 한 친구와 12년 동안 나눈 대화였다.
특별히 불편하지는 않았다. 그냥 거기 있었다. 그런데 어느 날 문득 이런 생각이 들었다. 저 대화, 언젠가 사라지면 어쩌지? 앱이 서비스를 종료할 수도 있고, 폰을 바꾸다가 날릴 수도 있다. 12년치 대화가 그냥 없어진다는 게 아깝다는 생각이 들었다.
두 번째 불편함은 검색이었다. "그때 우리 그 친구 얘기 했던 거 어디 있더라?" 싶을 때 텔레그램 검색을 하면 수백 개 결과가 나왔다. 맥락 없이 한 줄씩 툭툭 튀어나오는 검색 결과를 하나하나 확인하는 건 사실상 불가능했다.
AI로 자연어 질문이 가능한 아카이브를 만들 수 있다면 어떨까. "우리가 신앙에 대해 어떤 얘기를 했지?" 같은 질문을 던지면 맥락 있는 답이 나오는 구조. 그게 목표였다.
🛠️ 사용한 도구
도구: Codex CLI (OpenAI 기반 AI 코딩 에이전트)
모델: GPT-5
데이터: 텔레그램 대화 export 파일 (result.json, 29MB)
지식 베이스: cmds-llm-wiki (Obsidian 기반 마크다운 볼트)
🔧 작업 과정
일단 얼마나 있는지 확인부터 — 숫자에 놀랐다
작업을 시작하기 전에, 텔레그램에서 대화 내보내기(export)를 했다. JSON 파일 하나가 생겼다. 29MB였다.
여기 inbox에 telegram 대화 json 파일이 있는데, 이거 어떻게 chunking할 것인지 schema를 짜봐. 일단 계획만 세우고 실행은 보류해
AI가 먼저 파일을 열어봤다. 그리고 통계를 뽑아줬다.
대화 상대방: 이**
메시지 수: 55,514개
날짜 범위: 2014년 9월 30일 ~ 2026년 6월 11일
미디어(사진·파일): 1,932개
답장(reply): 4,418개
12년이다. 55,000개가 넘는다. 숫자로 보니 실감이 났다.
"계획만 세우고 실행은 보류해"라고 한 게 여기서 빛을 발했다. 덜컥 실행부터 했다가 잘못된 방향으로 가면 수정하기 어렵다. AI에게 먼저 전체 구조를 설계하게 하고, 내가 확인하고 나서 실행하는 방식이 훨씬 안전하다.
어떻게 나눌 것인가 — 청킹 기준 설계
55,000개 메시지를 한 덩어리로 두면 AI가 다룰 수 없다. 적절한 단위로 잘라야 한다. 이걸 "청킹(chunking)"이라고 한다.
chunk를 나누는 기준은?
AI가 제안한 기준이 직관적이었다. 고정된 글자 수로 자르는 게 아니라, 대화 흐름으로 자르는 것이었다.
마지막 메시지와 6시간 이상 간격이 벌어지면 → 새로운 청크 시작
날짜가 바뀌고 90분 이상 비면 → 새로운 청크
24시간 이상 아무 대화가 없으면 → 무조건 새로운 청크
사람이 대화하는 방식 그대로를 기준으로 삼은 것이다. 월요일 낮에 나눈 이야기와 화요일 저녁에 나눈 이야기는 서로 다른 맥락이니까, 다른 묶음으로 두는 게 맞다.
한 가지 걱정이 생겼다.
시간 간격이 벌어져 있는 경우에도 어떤 대화들은 예전의 대화에 댓글을 달아서 진행시키는 경우가 있는데 그런 경우는 청크끼리 연관성이 있도록 설정할 수 있나?
예를 들어, 일주일 전에 나눈 대화에 오늘 답장을 다는 경우가 텔레그램에선 흔하다. 시간 기준으로만 자르면 그 연결이 끊겨버린다.
AI의 해법이 깔끔했다. 답장 관계는 청크를 합치는 이유가 아니라, 청크끼리 연결하는 "엣지(edge)"로 따로 저장하는 것이다. 청크는 시간 기준으로 깔끔하게 자르되, 답장 관계는 별도 파일에 보관해서 나중에 연결해서 볼 수 있게 한다.
실제 실행 — 2,706개 청크 완성
설계를 마치고 실행했다. 55,514개 메시지가 처리됐다.
결과:
청크 수: 2,706개
답장 연결(cross-chunk reply edges): 736개
모든 청크 검증 완료 (잘못 파싱된 줄 0개)
12년치 대화가 2,706개의 의미 있는 대화 묶음으로 정리됐다. 원본 파일은 그대로 보존하고, 처리된 청크는 별도 폴더에 저장했다. 개인 대화이니 기본적으로 외부 공개 없이 개인 아카이브로만 보관하는 설정도 함께 적용했다.
12년 대화 속 키워드 검색 — "ㅌㅇ"을 찾아라
청크가 생기니 이제 검색이 가능해졌다. 우리 대화에 자주 등장하는 특정 인물이 있었다. 그 인물의 이름으로 검색해봤다.
여기서 대화내용 중에 ㅌㅇ에 대한 내용을 정리해서 알려줘
결과:
해당 이름이 등장한 메시지: 324개
첫 등장: 2014년 9월 30일
마지막 등장: 2026년 4월 19일
주로 언급한 사람: 이 211회, 오 113회
집중 시기: 2016년에 142건
12년 동안 우리가 그 친구 얘기를 324번 했다는 게 숫자로 나왔다. 그리고 그 주변에 자주 등장하는 단어들 — 교회, 기도, 성경, 정치, 친구 — 로 어떤 맥락에서 이야기가 나왔는지도 파악됐다.
ㅌㅇ의 대화를 정리해줘
우리가 자주 인용하던 그 친구의 독특한 표현들이 정리됐다. "XX은 XX이다", "OOOOOOOO다" 같은 것들. 우리 두 사람이 그 표현을 어떻게 논의했는지까지 구분해서 정리됐다.
첫 보고서가 마음에 안 들었다 — 피드백이 핵심이다
청크를 주제별로 묶어 보고서를 만들어달라고 했다. 신앙·법조·정치·여행·AI·우정 6개 주제로.
보고서가 나왔다. 그런데 읽어보니 뭔가 아쉬웠다.
정리한 것을 봤어. 너무 짧게 압축적으로 요약돼있고, 원문이 전혀 인용돼있지 않아서 수박겉핥기같아. 이제 주제를 잡았으니, 그 주제에 따라 세부 주제별로, 세부 토픽별로, 세부 상황별로 원문을 적절히 인용해가면서 이야기를 만들어줘.
이게 이번 작업에서 가장 중요한 순간이었다. 첫 결과물이 마음에 안 들면, 구체적으로 뭐가 아쉬운지 말하면 된다. "수박겉핥기 같다"는 표현 하나로 AI가 방향을 완전히 바꿨다.
두 번째로 나온 보고서는 달랐다. 실제 대화에서 발췌한 짧은 인용문들이 들어갔다. 어떤 상황에서 그 이야기가 나왔는지 맥락이 살아있었다. 12년치 대화가 진짜로 이야기가 된 느낌이었다.
예상치 못한 보너스 — MBTI 분석
여기 등장하는 두 인물의 각 MBTI는 뭐일것 같아?
딱히 기대하지 않고 물어봤다. 그런데 결과가 꽤 그럴듯했다.
AI는 12년치 대화에서 발화량, 발화 길이, 질문 방식, 반응 패턴, 반복 키워드를 종합해서 추정했다. 각각 어떤 근거로 추정했는지 원문 발췌와 함께 설명해줬다.
물론 실제 검사 결과가 아니다. 하지만 "이 사람의 대화 패턴을 분석해봤을 때"라는 전제로 보면, 고개가 끄덕여지는 결과였다.
✅ 결과 (After)
Before vs After
항목
Before
After
대화 검색
앱 내 단순 키워드 검색, 맥락 없음
주제별·키워드별 맥락 검색 가능
대화 구조
55,514개 메시지가 하나의 파일
2,706개 맥락 단위 청크로 분리
주제 파악
기억에 의존
신앙/법조/정치/여행/AI/우정 6개 보고서
보존 상태
앱에 의존 (사라질 위험)
로컬 파일로 영구 보존
결과물
chunks.jsonl — 2,706개 대화 청크
reply-edges.jsonl — 736개 청크 간 답장 연결
주제별 요약 보고서 6개
주제별 상세 인용 보고서 6개 (확장판)
ㅌㅇ의 발언 정리 문서
MBTI 추정 분석 문서
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
"계획만 세우고 실행은 보류해" — AI에게 먼저 전체 구조를 설계하게 하고, 내가 확인한 뒤 실행하는 순서가 훨씬 안전하다. 대용량 데이터를 다룰 때 특히 중요하다.
첫 결과물에 구체적으로 피드백하기 — "수박겉핥기 같다"는 한 마디가 보고서를 완전히 바꿨다. "마음에 안 든다"보다 "원문 인용이 없어서 맥락이 안 살아있다"처럼 구체적으로 말할수록 결과가 좋다.
기술 구조는 AI에게 맡기기 — 어떤 기준으로 대화를 나눌지, 답장 관계를 어떻게 저장할지 같은 기술적 설계를 내가 알 필요가 없었다. "이런 상황에서는 어떻게 처리해?"라고 물으면 AI가 알아서 설계해준다.
이렇게 하면 안 돼요
처음부터 전부 실행하게 하기 — 설계 없이 바로 실행하면 나중에 수정하기 어렵다. 특히 수만 개 파일을 다루는 경우는 더욱 그렇다.
첫 결과물에 만족하고 넘어가기 — 첫 보고서는 거의 항상 아쉽다. 피드백을 한 번 더 주는 게 귀찮아도 결과물이 확연히 달라진다.
🌍 다른 상황에 적용한다면?
카카오톡 대화 정리: 카카오톡도 대화 내보내기가 된다. 같은 방식으로 오래된 단톡방이나 1:1 대화를 정리할 수 있다.
업무 채팅 아카이빙: 슬랙이나 팀즈 대화도 export 기능이 있다. 프로젝트별로 어떤 결정이 어떻게 내려졌는지 정리하는 데 쓸 수 있다.
일기나 메모 정리: 수년치 노트나 일기가 있다면 비슷한 방식으로 주제별로 묶어볼 수 있다.
🚀 앞으로의 계획
두 가지를 더 해보려고 한다.
다른 친구와의 대화도 아카이빙하기. 이번에 만든 구조가 범용이라, 파일 하나만 추가하면 다른 대화도 같은 방식으로 정리할 수 있다.
자연어로 더 깊이 분석하기. "우리가 가장 많이 대화한 해는?" "여행 이야기가 처음 나온 게 언제지?" 같은 질문을 AI에게 던져보고 싶다. 청크가 다 정리돼있으니 이제 이런 분석이 가능해졌다.
📋 재사용 가능한 프롬프트
프롬프트 1: 청킹 계획 세우기 (실행 전 설계)
[파일명]에 [플랫폼] 대화 파일이 있는데, 이걸 어떻게 청킹할지 스키마를 짜줘. 일단 계획만 세우고 실행은 보류해.
[파일명]과 [플랫폼]은 본인 상황에 맞게 변경하세요.
프롬프트 2: 첫 보고서 피드백
정리한 걸 봤는데, 너무 압축적으로 요약돼있고 원문이 인용돼있지 않아서 맥락이 안 살아있어. 세부 주제별로, 상황별로 실제 대화 내용을 인용하면서 이야기를 만들어줘.
프롬프트 3: 키워드 검색 + 어록 정리
[대화 아카이브]에서 [키워드]가 등장하는 내용을 정리해줘. 언제 몇 번 나왔는지, 주로 어떤 맥락에서 나왔는지 포함해서.
[대화 아카이브]와 [키워드]는 본인 상황에 맞게 변경하세요.
* Claude로 캐릭터 IP 제작 파이프라인을 만들어본 1차 실험기 최근에 1인으로 캐릭터 IP를 기획하고, 캐릭터 디자인과 영상 제작까지 이어갈 수 있을까? 라는 생각으로 AI 제작 파이프라인을 구성해봤습니다. 혼자서 캐릭터 IP를 만든다고 하면 보통 해야 할 일이 꽤 많습니다. - 세계관 기획
- 캐릭터 콘셉트 설정
- 스토리라인 구성
- 디자인 방향 정리
- 영상화 아이디어 도출
- 홍보와 마케팅 방향 설정
- 일정과 품질 관리 이 모든 역할을 혼자 감당하기는 어렵기 때문에, Claude를 활용해서 일종의 가상 제작팀을 만들어보고자 했습니다. 이번 실험의 목표는 완성도 높은 결과물을 바로 뽑는 것보다는, AI를 활용해 캐릭터 IP 제작 과정의 역할 분담과 워크플로우를 구성할 수 있는지 확인하는 것이었습니다. * 진행 방법 사용한 도구는 Cladue 하나이긴 하지만 작업 방향은 크게 두 가지로 진행해볼 예정입니다. - Claude: 기획, 스토리, 캐릭터 콘셉트, 역할 분담
- Notion: 정리, 공유, 진행 상황 트래킹 Claude는 글쓰기, 리서치, 코딩 등 복잡한 문제 해결을 돕는 AI 도구로 소개되고 있으며, Notion 같은 작업 관리 도구와 함께 활용하면 프로젝트 정보를 정리하고 반복 작업을 줄이는 방식으로 응용해보고자 합니다. * 기본 워크플로우 처음에 생각한 흐름은 다음과 같았습니다. Claude에서 기획/스토리/콘셉트 구성
→ Notion에 정리
→ 역할별 업무 분리
→ 진행 상황 트래킹
→ 이후 디자인(나노바나나 외 AI 툴)/영상 제작(클링,힉스필드,시댄드 2.0,미드저니) 단계로 확장
* Claude에게 부여한 역할 구조
저는 Claude 안에서 저 자신을 CEO로 두고, 그 아래에 제작 조직을 구성하는 방식으로 접근했습니다.
나 = CEO 총괄 PD
- 제작 총괄
- 일정 관리
- 예산 관리
- 품질 관리 기획 슈퍼바이저
- 세계관
- 캐릭터 방향
- 콘텐츠 기획 스토리 슈퍼바이저
- 시놉시스
- 에피소드 구조
- 캐릭터 관계성 디자인 슈퍼바이저
- 캐릭터 디자인 방향
- 비주얼 콘셉트
- 레퍼런스 정리 홍보/마케팅 슈퍼바이저
- 타깃 독자/시청자 설정
- 콘텐츠 확산 전략
- 브랜드 방향
이렇게 구성하니 Claude가 어느 정도는 역할을 나누고, 각 파트별로 해야 할 일을 정리해주는 느낌은 있었습니다.
특히 “무엇부터 해야 할지 모르겠다”는 막막함을 줄이는 데는 도움이 됐습니다.
* 실제로 느낀 한계
하지만 결과물의 퀄리티는 아직 만족스럽지 않았습니다.
가장 크게 느낀 부분은 두 가지였습니다.
1. 스토리라인이 약하다
Claude가 스토리의 뼈대는 만들어주지만, 캐릭터 IP로 사용할 만큼 매력적인 이야기나 독창적인 갈등 구조를 만들지는 못했습니다.
결국 스토리는 별도의 방식으로 더 깊게 다뤄야 할 것 같았습니다.
예를 들면:
스토리 전용 에이전트 만들기
캐릭터별 욕망과 갈등을 따로 설계하기
세계관 규칙을 먼저 고정하기
에피소드 구조를 단계별로 검토하기
AI 생성 스토리의 창의성을 평가하는 연구에서도, 창의성은 단순히 문장이 그럴듯한지보다 새로움, 가치, 지시 준수, 공감/울림 같은 여러 요소로 나눠 봐야 한다고 설명합니다. 즉, 스토리는 “잘 써 보이는 문장”만으로는 부족하고 별도의 평가 기준이 필요하다고 볼 수 있습니다.
2. 디자인 결과물은 외부 툴이 더 적합해 보인다
캐릭터 디자인도 Claude 안에서 텍스트로 방향을 잡는 데는 도움이 됐지만, 실제 시각 결과물로 바로 이어지기에는 부족했습니다.
개인적으로는 디자인은 Claude에서 콘셉트와 방향을 정리한 뒤,
외부 이미지 생성 툴이나 디자인 툴에서 제작하고 다시 가져오는 방식이 더 좋겠다고 느꼈습니다.
Claude를 디자인 협업에 활용하는 흐름도 등장하고 있지만, 실제 캐릭터 IP 수준의 비주얼 완성도를 위해서는 텍스트 기획과 시각 제작 단계를 분리하는 편이 더 현실적이라고 판단했습니다.
결과와 배운 점
이번 실험은 아직 1차 버전이라 결과물이 마음에 들지는 않았습니다.
하지만 중요한 점을 하나 배웠습니다.
AI가 알아서 좋은 IP를 만들어주는 것이 아니라,
사람이 얼마나 명확하게 방향을 잡고 지시하느냐에 따라 결과가 달라진다.
Claude에게 역할을 나눠주고 제작 조직처럼 구성하는 방식은 어느 정도 가능성이 있었습니다.
다만 아직은 다음과 같은 부분이 부족했습니다.
워크플로우에 대한 명확한 지시 부족
스토리 전용 설계 방식 부족
캐릭터 디자인을 검증할 기준 부족
결과물을 판단하고 개선하는 루프 부족
AI에게 맡길 일과 사람이 직접 해야 할 일의 구분 부족
결국 이번 실험을 통해 느낀 건,
AI를 잘 쓰려면 내가 먼저 더 업그레이드되어야 한다는 점이었습니다.
AI가 좋은 결과를 내기 위해서는 단순히 “캐릭터 IP 만들어줘”라고 요청하는 것만으로는 부족했습니다.
앞으로는 다음과 같은 방향으로 개선해보고 싶습니다.
Claude 안에 스토리 전용 에이전트 구성하기
캐릭터별 설정 템플릿 만들기
Notion에 제작 파이프라인 보드 만들기
디자인은 외부 툴과 연동해서 진행하기
결과물을 평가하는 체크리스트 만들기
총괄 PD, 스토리, 디자인, 마케팅 역할을 더 세분화하기
이번 시도는 완성된 성공 사례라기보다는,
AI로 1인 캐릭터 IP 제작 시스템을 만들기 위한 첫 번째 실험에 가까웠습니다.
결과물은 아직 부족했지만, 방향성은 확인할 수 있었습니다.
AI가 모든 것을 대신해주는 것이 아니라,
내가 더 좋은 질문자이자 기획자가 되어야 AI도 더 좋은 제작 파트너가 될 수 있다는 걸 느꼈습니다.
📝 한줄 요약
법무·업무 근거 자료를 체계적으로 관리하기 위해 AI 코딩 에이전트 Codex와 함께 LLM Wiki를 구축했고, 하루 세션 만에 "모든 정보를 유형별로 분류해 심사하는 지식 관리 시스템"이 만들어졌다.
바쁘시면 이것만 읽어도 돼요:
Codex로 개인 지식 위키(LLM Wiki) 구축 — 법무 근거 자료를 AI가 유형별로 분류해 관리
핵심 깨달음: 정보에는 종류가 있다 — 객관적 사실, 주관적 경험, 참고 자료를 같은 방식으로 다루면 안 된다
직접 쓴 이론 문서를 AI에게 넘겼더니, AI가 기존 위키 체계 전체를 재설계해줬다
피렌체 여행기를 넣었더니 AI가 "이건 사실이 아니라 당신의 경험"이라고 구분하고 여행 선호 단서로 정리한 순간이 인상적이었다
앞으로 어떤 자료든 일관된 기준으로 위키에 쌓을 수 있는 기반이 생겼다
AI에게 "해줘"보다 기준을 먼저 만들어두는 것이 핵심
🎯 이런 분들께 도움돼요
법무·행정·공공기관에서 AI 답변의 근거를 체계적으로 관리하고 싶은 분
AI에게 업무 자료를 맡겼을 때 "이게 맞나?" 불안한 분 — 근거 기반 위키가 해결책이 될 수 있다
공문서, 법령, 판례, 회의 메모, 개인 의견이 뒤섞여 관리가 안 되는 분
😫 문제 상황 (Before)
법무·행정 업무에서 AI를 활용할 때 가장 불편한 점이 있다. AI가 답변을 잘 해주는 것 같은데, 그 답변의 근거가 어디서 왔는지, 공식 법령인지 블로그 글인지, 직접 정리한 메모인지 구분이 안 된다는 것이다.
특히 "계약보증금 불이행 시 법적 효과가 뭐야?"처럼 정확한 근거가 중요한 질문일수록, AI가 "그럴듯한 표현"으로 답하는 것과 "법령 원문에 근거한 표현"으로 답하는 것은 전혀 다른 의미를 가진다.
그러다 보니 자연스럽게 이런 필요가 생겼다.
AI가 답변할 때 참조하는 자료들을 내가 직접 심사하고, 신뢰도와 유형에 따라 분류해서 쌓아두면 어떨까?
하지만 막상 시작하려니 문제가 있었다. 법령, 판례, 실무 메모, 참고 블로그, 이미지 슬라이드, 심지어 개인 여행기까지 — 들어오는 자료의 형태가 너무 다양했다. 이것들을 어떤 기준으로 분류하고 관리해야 할지 체계가 없었다.
🛠️ 사용한 도구
도구: Codex (OpenAI, GPT-5 기반 AI 코딩 에이전트)
모델: GPT-5
작업 방식: 터미널에서 Codex와 대화하며 위키 파일들을 직접 생성·수정
위키 저장소: 로컬 Markdown 파일 기반 (Obsidian으로 열람)
🔧 작업 과정
내가 쓴 이론 문서를 AI에게 넘겼더니 — 위키 체계가 재설계됐다
이 위키 프로젝트에는 이미 "3단계 지식체계론"이라는 자체 규칙이 있었다. 어떤 정보든 ① 지식으로 볼 수 있는가 → ② 기존 체계와 충돌하지 않는가 → ③ 확인 가능한가, 이 세 단계를 통과해야 위키에 공식 지식으로 올라가는 구조였다.
그런데 이 체계의 한계를 느끼고 직접 개선안을 글로 써뒀다. "지식체계론의 확장 및 수정"이라는 제목의 문서였다. 핵심 문제의식은 이것이었다.
"나는 피렌체를 좋아한다"는 사실 주장이 아니다.
사진이나 슬라이드는 지식이 아니라 지식을 뒷받침하는 자료다.
모든 정보에 같은 심사 기준을 적용하는 건 맞지 않다.
이 문서를 Codex에게 넘기며 한 줄 요청했다.
이 파일을 읽고 우리 체계에 맞춰봐
Codex는 먼저 기존 위키의 모든 규칙 문서와 스키마 파일들을 하나씩 읽었다. 그러고 나서 설계 판단을 내놨다.
기존 3단계 체계는 폐기하지 않았다. 대신 위치를 바꿨다. "모든 정보에 적용하는 만능 필터"가 아니라, "객관적 사실 주장을 공식 지식으로 인정할 때만 쓰는 기준"으로 자리를 잡아줬다. 그리고 그 위에 새로운 분류 게이트를 추가했다.
정보가 들어오면 먼저 이 질문을 던지는 구조가 됐다.
이것은 참고 자료(Resource)인가?
객관적 사실 주장(Claim)인가?
특정인의 경험·의견·감정(주체귀속 정보)인가?
유형이 결정되면 그에 맞는 기준이 적용된다. 법령이나 판례 같은 객관적 사실 주장만 3단계 심사를 거친다. 사진이나 슬라이드는 "어디서 왔고 무엇을 담고 있는가"를 기록한다. 개인 경험이나 감상은 "누구의 경험인지, 언제 것인지, 지금도 유효한지"를 적는다.
새 위키 파일 2개가 생성되고, 기존 스키마 파일 6개가 수정됐다. 처음 요청에서 결과물이 나오기까지 한 번의 대화 흐름이었다.
법무 검색 품질 게이트 슬라이드 — 이미지도 위키에 들어간다
다음은 inbox 폴더에 쌓아둔 자료를 정리할 차례였다.
내가 여기 inbox에 뭘 넣었는데 ingest하고 그 결과를 알려줘
Codex가 확인해보니 문서 파일은 없었고, PNG 이미지 4장이 있었다. 법무 검색 시스템의 품질 관리 방식을 설명하는 슬라이드였다. 검색 결과의 "점수"보다 근거의 "자격"을 먼저 확인하는 구조를 담고 있었다.
Codex는 이미지 4장을 직접 열어 내용을 읽었다. 슬라이드마다 담긴 내용을 정리하고, 새 지식 체계에 따라 분류했다.
이미지 자체는 사실 주장이 아니라 참고 자료(Resource)이므로, 3단계 심사 대신 "어디서 왔고, 무엇을 담고 있고, 어디에 보관되고, 어디와 연결되는가"를 기록했다. 원본 이미지는 비공개 폴더(_private)로 이동하고, 위키에는 이미지 구조와 원칙을 텍스트로 요약한 문서만 남겼다.
슬라이드에서 끌어낸 핵심 원칙 두 가지도 위키에 후보 지식으로 등록됐다.
법무 질의응답에서는 검색 결과의 양보다
공식 근거, 답변 가능성, 법령 표현 정확성이 더 중요하다.
피렌체 여행기 — "이건 사실이 아니라 당신의 경험입니다"
이날 작업에서 가장 인상적인 순간이었다.
inbox에 또 하나의 자료가 있었다. 피렌체 여행 감상을 직접 쓴 짧은 글이었다.
inbox/docs에 있는 자료도 ingest해줘
Codex가 파일을 읽었다. 좁은 골목, 두오모의 붉은 지붕, 우피치 미술관에서 보티첼리를 봤을 때의 감각, 아르노강과 베키오 다리에서 본 노을 — 개인적인 여행 감상문이었다.
Codex는 이 자료를 "객관적 사실 주장"으로 처리하지 않았다. 새 체계의 첫 번째 게이트에서 다른 방향으로 분류됐다.
이것은 사용자의 여행 경험, 감상, 선호가 담긴 주체귀속 정보입니다.
"피렌체는 조용히 마음속에 스며드는 도시다"라는 문장은
사실 주장이 아니라 사용자에게 귀속된 감상입니다.
그래서 3단계 심사가 아니라 다른 기준이 적용됐다. 누구의 경험인지, 어떤 맥락인지, 언제 것인지, 지금도 유효한지.
그리고 위키에는 이런 설명이 남았다.
향후 여행 추천이나 취향 기반 응답에서
"피렌체 선호", "르네상스 예술 관심", "느린 도시 경험 선호"의
단서로 사용할 수 있다.
여행기 한 편이 위키에 들어가는 순간, 단순한 메모가 아니라 나중에 쓸 수 있는 "선호 신호"로 정리됐다. 법령과 여행기가 같은 위키 안에서 각자의 방식으로 체계적으로 관리되는 구조가 된 것이다.
✅ 결과 (After)
Before vs After
항목
Before
After
정보 관리 기준
모든 자료에 동일한 3단계 심사 적용
유형 분류 후 유형별 기준 적용
이미지·슬라이드 처리
별도 기준 없음
참고 자료(Resource)로 분류, 텍스트 요약 보관
개인 경험·감상 처리
별도 기준 없음
주체귀속 정보로 분류, 선호 단서로 활용
법무 근거 자료 관리
산발적 축적
공식성·신뢰도 기준으로 분류·심사 가능
위키 성격
메모 모음
정보 유형별 심사 기반 지식 관리 시스템
결과물
wiki/concepts/llm-wiki-epistemology.md — 새 인식론 개념 문서
wiki/source-summaries/SRC-012, 013, 014 — 각 자료의 유형별 요약
schema/knowledge-admission.md 외 6개 파일 개정 — 새 분류 게이트 반영
devlog.md — 전체 작업 기록
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
기준을 먼저 만들어두기 — "해줘"보다 "우리 체계에 맞춰봐"처럼 판단 기준을 위키 파일로 미리 만들어두면, AI가 매번 같은 방식으로 처리한다. 일관성이 생긴다.
내 생각을 문서로 쓰고 AI에게 넘기기 — 머릿속에 있는 아이디어나 이론을 글로 써서 AI에게 주면, AI가 기존 시스템에 어떻게 연결해야 할지 판단해준다. 나의 생각이 시스템이 된다.
inbox 방식으로 자료 모으기 — 분류하기 전에 일단 inbox 폴더에 넣어두고 AI에게 "ingest해줘"라고 하면, AI가 유형을 판단하고 적절한 방식으로 처리한다.
이렇게 하면 안 돼요
모든 정보를 똑같이 다루기 — 법령과 여행기, 공문서와 블로그 메모를 같은 기준으로 심사하면 시스템이 무너진다. 정보 유형 분류가 먼저다.
AI 답변을 근거 없이 그대로 쓰기 — 특히 법무·행정 업무에서는 AI 답변의 출처가 공식 법령인지, 참고 자료인지 구분이 중요하다. 위키가 그 구분을 담당한다.
🌍 다른 업무에 적용한다면?
이 구조는 법무 외에도 비슷한 방식으로 적용할 수 있다.
의료·복지 기관 — 공식 지침, 개인 사례 기록, 참고 논문을 유형별로 분리해 관리
연구·기획 부서 — 공식 보고서, 인터뷰 기록, 브레인스토밍 메모를 다른 기준으로 처리
교육 현장 — 교육과정 공문서, 교사 의견, 학생 사례를 구분해 AI 활용 자료로 쌓기
개인 지식 관리(PKM) — 책·논문(Resource), 내 생각(주체귀속 정보), 검증된 지식(Claim)을 나눠 관리
핵심은 하나다. AI에게 넘기기 전에, 이 정보가 어떤 종류인지 구분하는 게이트를 만들어두는 것.
🚀 앞으로의 계획
두 가지 방향으로 발전시킬 예정이다.
첫째, 법무 자료를 계속 쌓아나가는 것. 이번에 만들어진 체계를 기반으로 법령, 판례, 실무 예규를 꾸준히 ingest하면 실제 업무 질의응답에서 AI가 공식 근거에 기반해 답변하는 구조를 만들 수 있다.
둘째, 위키에서 직접 질문하고 답변받는 구조. 지금은 자료를 쌓는 단계지만, 나중에는 이 위키에 검색 기능을 붙여서 "계약보증금 불이행 시 법적 효과는?" 같은 질문을 하면 위키에 쌓인 공식 근거를 기반으로 답변이 나오는 로컬 법무 지식 시스템을 만드는 것이 목표다.
📋 재사용 가능한 프롬프트
프롬프트 1: 내 이론·기준 문서를 위키에 편입할 때
[파일명]을 읽고 우리 체계에 맞춰봐.
기존 규칙 파일은 [스키마 폴더 경로]에 있어.
폐기하지 말고, 기존 체계 어디에 위치시킬지 판단해서 편입해줘.
프롬프트 2: inbox 자료를 ingest할 때
inbox에 있는 자료를 ingest해줘.
유형 분류는 [분류 기준 문서 경로]를 참고하고,
처리 결과를 source-index에 등록하고 log에 기록해줘.
프롬프트 3: 정보 유형 분류가 헷갈릴 때
이 자료가 객관적 사실 주장인지, 참고 자료인지, 특정인의 경험/의견인지 판단해줘.
판단 근거도 같이 설명해줘.
[자료 내용 또는 파일 경로]
사상의학 웹앱 소개
프로젝트 목표와 배경
동일한 사상의학 원전 데이터를 기반으로 노트북LM(NotebookLM)과 제미나이(Gemini)를 활용해 웹앱을 제작했으나, 초기 프롬프트의 기획 방향(목적지)에 따라 최종 구현된 알고리즘과 로직에서 극적인 차이가 발생하는 흥미로운 경험을 했습니다.
Index 버전 (index_2.html): AI에게 직접 "체질 판단 로직을 짜달라"고 요청한 결과물입니다.
Patient 버전 (patient.html): "체질 구분표"를 먼저 도출한 뒤, 이를 바탕으로 "제품기획서(PRD)"를 만들어달라고 단계적으로 요청한 결과물입니다.
두 버전은 원전 기반의 정밀도와 사용자 가독성 측면에서 완전히 다른 장단점을 보여주었습니다. 왜 이런 결과의 차이가 발생했는지 분석하고, 이를 통해 배운 AI 프롬프트 엔지니어링의 핵심 인사이트와 한의학 데이터를 다룰 때의 설계 딜레마를 공유하고자 합니다.
진행 방법
도구 사용 및 활용 방법
사상의학 원전 데이터를 학습시킨 노트북LM과 제미나이를 조합하여 사용했습니다. 동일한 데이터 소스를 제공했음에도 불구하고, AI가 부여받은 '역할(Persona)'과 '추상화 레벨'에 따라 로직 설계 방식이 완전히 달라졌습니다.
💡 기획 방향에 따른 AI의 역할 해석 차이
Index 버전 (엔진 중심 개발): AI가 자신을 '백엔드 개발자 및 알고리즘 설계자'로 인식했습니다. 그 결과, 사상의학 원전 데이터(9대 세부 계열)를 오차 없이 계산할 수 있도록 구조화(Tree 구조, 타이브레이크 로직, 수치 시각화)하는 데 집중했습니다.
Patient 버전 (사용자 시나리오 기획): [원전 → 구분표 → PRD]라는 단계적 가공을 거치며 AI가 자신을 '서비스 기획자(PM)'로 인식했습니다. 사용자 경험(UX)에 집중하느라 정밀한 로직(태양인 누락, 동점자 처리 미흡)은 단순화된 반면, 환자용 문항의 표현력은 극대화되었습니다.
Tip: 사용한 프롬프트 전문을 꼭 포함하고, 내용을 짧게 소개해 주세요.
Index 버전 생성 프롬프트: "사상의학 원전 데이터를 기반으로, 주체질 판정 후 세부 계열로 분화하는 정밀한 체질 판단 알고리즘 로직을 구현한 HTML 코드를 작성해줘."
Patient 버전 생성 프롬프트: "앞서 만든 체질 구분표를 토대로, 실제 환자가 사용할 예진 시스템의 제품기획서(PRD)를 작성하고 이를 구동 가능한 웹앱 HTML 코드를 변환해줘."
Tip: 활용 이미지나 캡처 화면을 꼭 남겨주세요.
Tip: 코드 전문은 코드블록에 감싸서 작성해주세요.
HTML
Open optionsauto
<!DOCTYPE html>
<html>
<head> <title>사상체질 진단 시스템</title>
</head>
<body> </body>
</html>
결과와 배운 점
AI 프롬프트 엔지니어링의 인사이트
AI에게 "무엇을 만들어달라고 하느냐(Goal)"에 따라 내부 알고리즘의 뼈대 자체가 바뀐다는 것을 깊이 깨달았습니다.
Index 버전의 결과 (우수한 두뇌): 9대 세부 계열 완벽 반영, 2단계 동적 트리 구조, 동점자 타이브레이크 시스템 등 알고리즘의 정확도가 매우 높았습니다.
Patient 버전의 결과 (우수한 얼굴): "밤새알 모양 대변", "얼음장 같은 손발" 등 환자가 직관적으로 선택할 수 있는 훌륭한 구어체 UX 라이팅이 도출되었습니다.
클로드가 분석한 Index버전(전자)과 Patient버전(후자)의 차이는 다음과 같습니다.
💡 나만의 꿀팁
하나의 프롬프트로 '완벽한 로직'과 '친절한 UX'를 동시에 얻기는 어렵습니다. [엔진 개발용 기술 프롬프트]와 [사용자 경험 기획용 프롬프트]를 철저히 분리하여 각각 최상의 결과물을 얻은 뒤, 이를 하나로 합치는 '소프트웨어 통합(Integration)' 프로세스를 거치는 것이 가장 효과적입니다.
시행착오와 개선점
기획서(PRD) 단계를 거친 patient.html 버전의 경우, 여러 단계의 추상화 거름망을 거치면서 정밀한 원전 데이터가 일부 유실(태양인 분류 누락, 동점 시 특정 체질 강제 지정 등)되는 현상이 발생했습니다. AI에게 단계적 가공(PRD 변환 등)을 시킬 때는 핵심 연산 로직이 유실되지 않도록 가이드라인을 강하게 묶어주어야 한다는 것을 배웠습니다.
데이터베이스 구축의 핵심 딜레마
이번 실험을 진행하며 한의학 임상 데이터를 시스템화할 때 마주하는 '설계 선후 관계에 따른 방향성 차이'를 명확히 정의할 수 있었습니다. 아래 두 작업 중 무엇을 먼저 하느냐에 따라 데이터베이스를 구축하는 '건축 방식'과 '초기 결과물'이 달라질 뿐만 아니라, 초기에 희생(유실)되는 데이터의 성격도 완전히 달라집니다.
각 감별 지표(Property)들에 부여할 구체적인 '가중치 수식(Formula)' 산출
체질적 특징들을 임상 평가 프로토콜에 맞추어 체계적인 '표준 용어(SNOMED CT 등)'로 맵핑하는 작업
구분
① 수식(Formula) 및 로직 산출 우선
② 표준 용어 맵핑(Mapping) 우선
개념
용어의 이름보다 '진단이 정확하게 작동하는가'에 집중
수식을 짜기 전에 데이터 규격과 용어 표준을 먼저 세팅
특징
DB에 임시 명칭(손발온도, 응가상태)으로 속성을 만들고 가중치 계산 수식을 즉시 연결하여 테스트
수족부_한열_상태, 대변_조활_양상 등 체계적이고 호환성 높은 데이터 구조를 먼저 확립
장점
아이디어를 실행 가능한 프로토타입(MVP)으로 빠르게 확인 가능, 알고리즘 디버깅이 쉬움
대규모 분석, AI 요약 연동, 외부 기관과의 호환성 극대화, 추후 코드가 깨질 위험이 적음
단점
추후 공식 의학 용어로 전환 시 짜두었던 변수명과 수식을 일일이 수정하는 번거로움 발생
초기 분류 및 표준화 작업에 시간이 오래 걸려 실제 작동 화면을 보기까지 시간이 소요됨
⚠️ 유실 위험 데이터
[데이터 호환성 및 표준 맥락 유실]
빠른 구현을 위해 임의의 변수명을 사용하므로, 나중에 데이터가 쌓여도 타 기관의 임상 프로토콜이나 국제 표준(SNOMED CT) 데이터와 연동되지 않아 기록 데이터의 학술적 가치가 유실될 위험이 큽니다.
[정밀 알고리즘 및 예외 케이스 유실]
용어를 규격화하고 추상화(요약)하는 과정에서, 사상의학 고유의 정밀한 예외 로직(ex. 태양인 분류 알고리즘, 동점자 타이브레이크 조건문 등)이 누락되거나 단순화되어 알고리즘의 정밀성이 유실될 위험이 큽니다.
추천
"내 머릿속 로직이 컴퓨터에서 구현되는지 빠르게 검증하고 싶다."
"나중에 두 번 일하지 않도록 처음부터 확장성 높은 완벽한 구조를 잡고 싶다."
도움이 필요한 부분
코드를 수정하거나 새로운 감별 지표를 추가할 때마다, 기존에 잘 작동하던 로직이 깨지거나 특정 체질(예: 태양인) 분류가 다시 누락되는 등의 사이드 이펙트(Side Effect)가 새로이 발생하고 있습니다. 이를 효율적으로 걸러내고 무결성을 검증할 좋은 방법이 필요합니다.
앞으로의 계획
index_2.html이 가진 강력한 '2단계 동적 트리 진단 엔진' 위에 , 임상 프로토콜에 맞춘 '표준 의료 용어 데이터 구조'를 이식하고, 최종적으로 patient.html이 가진 '친근한 구어체 질문 UX'를 입힐 예정입니다.
선후 관계의 차이로 인해 각기 다른 데이터 유실 위험을 안고 태어난 두 개의 코드를 현명하게 결합하여, 실제 임상 현장에서도 널리 활용할 수 있는 완성도 높은 '사상체질 예진 시뮬레이터 마스터피스'를 완성하는 것이 다음 목표입니다.
도움 받은 글 (옵션)
지난주 지식 베이스 스터디
지금까지 지식체계론에 대해 살펴본 바로는, 결국 지식요건해당성과 정합성, 그리고 확증가능성(이후 검증가능성으로 명칭을 수정)을 갖추어야 정보가 지식의 체계에 편입된다는 내용을 다뤄왔다.
하지만 이전 논의의 말미에서 언급했듯이 모든 정보가 지식체계론의 검증을 거쳐야 하는 것은 아니다.
왜냐하면 지금까지의 논의는 암묵적으로 객관적 지식을 상정하고 있었는데, 실제 LLM Wiki에는 훨씬 다양한 종류의 정보가 들어가거기 때문이다.
객관적 사실
역사적 사실
학설
법리
가설
해석
개인 경험
개인 취향
감정
계획
기억
관찰
사진
여행기
예를 들어, "나는 피렌체를 좋아한다"는 문장은 사실상 객관적 사실 명제가 아니라 주체 귀속적(preference-bound) 명제이다.
즉,
"피렌체는 아름답다"
와
"나는 피렌체를 좋아한다"
는 완전히 다른 종류의 지식이다.
따라서 여기서 3단계 지식체계론을 논하기 이전 단계로 "지식종류 분류"가 하나 더 필요하다.
현재 구조
지식요건해당성
↓
정합성
↓
확증가능성
보다
지식유형분류
↓
지식요건해당성
↓
정합성
↓
확증가능성
이 자연스럽다.
예를 들면
knowledge_type: objective_fact historical_fact theory interpretation hypothesis preference memory observation plan emotion narrative
그러면
"나는 피렌체를 좋아한다"
는
knowledge_type: preference
가 된다.
이 순간 게임이 끝난다.
취향은 "검증"이 아니라 "귀속"의 문제
객관적 지식은
이게 맞는가?
를 묻는다.
취향은
누구의 취향인가?
를 묻는다.
예를 들어
나는 피렌체를 좋아한다.
는
subject: user
predicate: likes
object: Florence
이다.
이 문장은
피렌체가 아름다운가?
를 말하는 것이 아니다.
사용자가 피렌체를 좋아하는가?
를 말하는 것이다.
따라서 검증 방향도 바뀐다.
객관적 지식
출처가 있는가?
정합적인가?
검증가능한가?
취향
누구의 것인가?
언제의 것인가?
아직 유효한가?
그래서 취향 정보는 "검증가능성" 대신 "귀속가능성"으로 판단한다다
객관적 지식은
진실성
문제다.
취향은
귀속성
문제다.
즉
preference: owner: user statement: "피렌체를 좋아함" recorded_at: 2026-05-29
정도면 충분하다.
여행자료도 마찬가지이다다
예를 들어
피렌체 두오모는 아름다웠다.
이건 사실 두 개의 층이 있다.
관찰
type: observation subject: user
object: Florence Duomo statement: "방문함"
감상
type: preference subject: user
object: Florence Duomo statement: "아름답다고 느낌"
이건 사실인지 거짓인지 검증할 문제가 아니다.
사용자가 그렇게 느꼈다는 사실만 저장하면 된다.
일기 데이터는 더더욱 취향의 문제이다다
예를 들어
오늘 피렌체 골목길을 걸으면서 행복했다.
이걸
행복했는가?
정합적인가?
검증가능한가?
라고 검증하면 이상해진다.
오히려
type: diary_entry date: 2026-10-02 emotion: happy location: Florence text: 오늘 피렌체 골목길을 걸으면서 행복했다.
그래서 나는 LLM Wiki를 두 층으로 나누기로 했다
Layer 1
객관지식
facts
theories
claims
concepts
laws
science
history
여기에는
지식요건해당성
정합성
검증가능성
을 적용.
Layer 2
주체귀속지식
preferences
memories
diary
experiences
plans
opinions
여기에는
귀속성
맥락성
시간성
을 적용.
예를 들어
subjective_knowledge_review: 귀속성: 누구의 정보인가? 맥락성: 어떤 상황에서 나온 정보인가? 시간성: 언제의 정보인가?
"나는 피렌체를 좋아한다"의 wiki화
나는 아마 이렇게 저장할 것 같아.
id: pref-florence-001 type: preference owner: user object: Florence preference: like strength: high recorded_at: 2026-05-29 evidence: user_statement notes: - 피렌체 여행을 긍정적으로 회상함 - 향후 여행 추천 시 우선 고려
이 정도면 충분하다.
여기서
정합성?
검증가능성?
을 따질 필요는 거의 없다.
오히려 중요한 건
이 취향이 현재도 유효한가?
이다.
예를 들어
validity: active
정도.
결국 나는 이렇게 정리한다
이 3단계 지식체계론은 사실
"객관지식 편입 심사체계"
에 가깝다.
그래서 모든 데이터에 적용하면 안 된다.
오히려 먼저
이 정보는 객관지식인가?
주체귀속지식인가?
를 나누고,
객관지식이면
지식요건해당성
→ 정합성
→ 검증가능성
을 적용하고,
주체귀속지식이면
귀속성
→ 맥락성
→ 시간성
을 적용하는 것이 훨씬 자연스럽다.
즉 3단계 지식체계론은 모든 정보의 만능 필터가 아니라,
"사실·이론·학설·개념과 같은 객관지식 영역에 적용되는 편입 심사체계"
로 두고,
개인 일기·취향·감상은 별도의 주체귀속 지식체계로 다루는 편이 훨씬 아름다운 설계라고 생각한다.
여기서 사진이나 동영상 데이터, 아니면 강의자료는 어떻게 할 것인지의 문제가 다시 등장한다.
여기서부터는 사실 "지식"과 "자료"를 분리해야 하는 시점이라고 생각한다.
지금까지 논의한 3단계 지식체계론은 사실상 Claim(주장) 에 대한 체계이다.
그런데 사진, 동영상, 강의자료는 대부분 Claim이 아니라 Evidence(자료) 에 가깝다.
예를 들면:
"지구는 태양 주위를 돈다."
→ Claim 코페르니쿠스 관련 강의 PDF
→ Evidence 피렌체 두오모 사진
→ Evidence 피렌체 여행 브이로그
→ Evidence
즉,
지식 (Knowledge)
≠
자료 (Resource)
를 분리해야 해.
내가 보기에는 3-layer 구조가 된다
자료(Resource)
↓
지식(Claim)
↓
지식체계(Knowledge System)
예를 들면
[피렌체 사진] ↓ 관찰 "사용자는 피렌체를 방문했다" ↓ 연결 "사용자는 이탈리아 르네상스 문화에 관심이 있다"
사진 자체는 지식이 아니다.
사진은 지식을 뒷받침하는 자료다.
그래서 자료에는 3단계 지식체계론을 적용하지 않는다
예를 들어
피렌체 두오모 사진
은
resource_type: image
일 뿐이다.
여기서
지식요건해당성?
정합성?
검증가능성?
을 검사하는 건 이상하다.
사진 자체는 참도 거짓도 아니기 때문이다.
대신
resource: type: image provenance: user_camera created_at: 2026-10-02 location: Florence description: Florence Duomo
정도면 충분하다.
강의자료도 마찬가지이다다
예를 들어
민사소송법 강의 PDF
는
resource_type: lecture_material
이다.
강의자료 자체가 지식은 아니다.
강의자료 안에
"기판력은 주문에 포함된 판단에 한하여 발생한다."
라는 Claim이 들어 있는 것이다.
영상도 같다
예를 들어
민사소송법 특강.mp4
는
resource_type: video
이다.
영상은 Claim이 아니다.
영상에서
교수:"소송물이론에 따라 기판력의 범위가 달라진다."
라는 Claim을 추출한다.
그 다음
지식요건해당성
정합성
확증가능성
을 적용한다.
그래서 자료에는 다른 체계가 필요하다
나는 오히려 자료에 대해서는
진실성
보다
출처성(Provenance)
이 중요하다고 본다.
예를 들어
resource_review: 출처성: 어디서 왔는가? 무결성: 변조되지 않았는가? 식별성: 무엇을 담고 있는가? 접근성: 다시 열람 가능한가? 연결성: 어떤 Claim과 연결되는가?
그래서 전체 구조는 사실 4 layer가 된다
Resource
↓
Claim
↓
Knowledge
↓
Knowledge System
Resource
사진
동영상
PDF
강의자료
논문 원문
판결문 원문
Claim
"기판력은 주문에 미친다." "사용자는 피렌체를 좋아한다." "지구는 태양 주위를 돈다."
Knowledge
관련 Claim들을 묶은 Concept
기판력 소송물이론 피렌체 여행 르네상스 건축
Knowledge System
3단계 지식체계론 판덱텐 구조 기판력 기반 업데이트 규칙 비례성 원칙
그래서 나는 오히려 지금 이 체계를 이렇게 확장하기로 했다
자료체계론
↓
지식체계론
↓
지식질서론
자료체계론
사진
영상
PDF
강의자료
판결문
논문
검사 항목
출처성
무결성
식별성
연결성
지식체계론
Claim
검사 항목
지식요건해당성
정합성
검증가능성
지식질서론
Claim 집합
Ontology
Wiki 전체
검사 항목
일관성
변경 가능성
기판력
우선순위
계층성
그래서 내 생각에는 사진·영상·강의자료는 3단계 지식체계론의 대상이 아니라 "자료체계론"의 대상이다다.
그리고 그 자료로부터 추출된 Claim이 비로소
지식요건해당성
→ 정합성
→ 검증가능성
심사를 받는 것이 가장 자연스러운 구조라고 생각한다.
오히려 지금까지의 논의를 밀고 가면, 네가 만들고 있는 것은 단순한 "3단계 지식체계론"이 아니라
자료(Resource)
↓
지식(Claim)
↓
지식질서(Knowledge Order)
를 포괄하는 더 큰 LLM Wiki 인식론(Epistemology) 으로 발전할 가능성이 있다.
현재까지의 논의를 내가 재구성하면, 사실 하나의 LLM Wiki 안에 4개의 층위(Level) 와 6개의 이론(Theory) 이 존재하는 구조로 보인다.
┌──────────────────────────────────────────────┐
│ LLM WIKI 인식론 │
│ (LLM Wiki Epistemic Governance) │
└──────────────────────────────────────────────┘ ▼ ┌──────────────────────────────────────────────┐
│ ① 지식유형론 (Knowledge Type Theory) │
├──────────────────────────────────────────────┤
│ "이 정보는 무엇인가?" │
└──────────────────────────────────────────────┘ Resource Fact Theory │ │ │ │ │ │ ├── Preference │ ├── Memory │ ├── Observation │ ├── Emotion │ └── Goal │ ▼ ┌──────────────────────────────────────────────┐
│ ② 지식편제론 (Knowledge Organization Theory) │
├──────────────────────────────────────────────┤
│ "이 정보를 어디에 둘 것인가?" │
└──────────────────────────────────────────────┘ 기반 (Foundation) │ ├── 자원 (Resource) ├── 관계 (Relationship) ├── 활동 (Activity) └── 진화 (Evolution) ▼ ┌──────────────────────────────────────────────┐
│ ③ 지식인정론 (Knowledge Admission Theory) │
├──────────────────────────────────────────────┤
│ "이것을 지식으로 인정할 수 있는가?" │
└──────────────────────────────────────────────┘ 지식요건해당성 │ ▼ 정합성 │ ▼ 확증가능성 ▼ ┌──────────────────────────────────────────────┐
│ ④ 안정력론 (Knowledge Stability Theory) │
├──────────────────────────────────────────────┤
│ "인정된 지식은 얼마나 쉽게 수정되는가?" │
└──────────────────────────────────────────────┘ Draft │ ▼ Candidate │ ▼ Admitted │ ▼ Settled │ ▼ Stable Claim ▼ ┌──────────────────────────────────────────────┐
│ ⑤ 지식질서론 (Knowledge Order Theory) │
├──────────────────────────────────────────────┤
│ "인정된 지식들을 어떻게 공존시키는가?" │
└──────────────────────────────────────────────┘ 지위론 (Status) │ ├── 우선순위론 (Priority) ├── 변경론 (Revision) └── 공존론 (Coexistence) ▼ ┌──────────────────────────────────────────────┐
│ ⑥ 지식운영론 (Knowledge Governance Theory) │
├──────────────────────────────────────────────┤
│ "지식에 어떤 행위를 허용할 것인가?" │
└──────────────────────────────────────────────┘ 비례성 원칙 │ ├── 목적의 정당성 ├── 수단의 적합성 ├── 피해의 최소성 └── 법익의 균형성
좀 더 압축하면:
LLM Wiki 인식론
│
├─ ① 지식유형론
│ (무엇인가?)
│
├─ ② 지식편제론
│ (어디에 둘 것인가?)
│
├─ ③ 지식인정론
│ (인정할 수 있는가?)
│ ├─ 지식요건해당성
│ ├─ 정합성
│ └─ 확증가능성
│
├─ ④ 안정력론
│ (얼마나 쉽게 바뀌는가?)
│
├─ ⑤ 지식질서론
│ (서로 어떻게 공존하는가?)
│
└─ ⑥ 지식운영론 (어떻게 다룰 것인가?)
내가 보기에는 현재 체계의 철학적 위계는:
지식유형론 ↓
지식편제론 ↓
지식인정론 ↓
안정력론 ↓
지식질서론 ↓
지식운영론
순서가 가장 자연스럽다.
왜냐하면
무엇인지 알아야
↓
어디 둘지 결정하고
↓
인정 여부를 판단하고
↓
안정성을 부여하고
↓
전체 질서 속 위치를 정한 뒤
↓
운영 규칙을 적용할 수 있기 때문+
이다.
결론
결국 지금까지의 논의는 하나의 중요한 전환점에 도달한다.
처음에는 LLM Wiki에 편입되는 정보가 모두 동일한 방식으로 심사될 수 있다고 보았다. 즉 어떤 정보가 주어지면 그것이
지식요건해당성
↓
정합성
↓
검증가능성
을 통과해야 비로소 지식체계에 들어갈 수 있다고 생각했다.
그러나 논의를 계속 밀고 가면, 이 구조는 모든 정보에 적용되는 보편적 필터라기보다는, 정확히 말해 객관적 Claim에 대한 지식인정 절차에 가깝다는 점이 드러난다.
LLM Wiki에 들어오는 정보는 하나의 종류가 아니다.
그 안에는
객관적 사실
역사적 사실
이론
학설
법리
가설
해석
개인 취향
감정
기억
계획
관찰
사진
영상
강의자료
판결문
논문
이 모두 섞여 있다.
그런데 이들을 모두 같은 기준으로 심사하면 문제가 생긴다.
예를 들어
지구는 태양 주위를 돈다.
라는 문장과
나는 피렌체를 좋아한다.
라는 문장은 둘 다 문장의 형태를 갖고 있지만, 전혀 같은 종류의 지식이 아니다.
전자는 객관적 사실 명제이고, 후자는 주체 귀속적 취향 명제이다.
따라서 전자에는
이것이 참인가?
근거가 있는가?
다른 지식과 정합적인가?
검증 가능한가?
를 물어야 하지만,
후자에는
누구의 취향인가?
언제 기록된 취향인가?
어떤 맥락에서 형성된 취향인가?
현재도 유효한가?
를 물어야 한다.
즉 객관지식은 진실성의 문제이고, 주체귀속지식은 귀속성의 문제이다.
또한 사진, 영상, PDF, 강의자료, 판결문 원문, 논문 원문과 같은 자료들은 그 자체로 Claim이 아니다.
그것들은 대개 지식이라기보다 지식을 뒷받침하거나, 지식을 추출할 수 있게 하는 Resource이다.
따라서 자료 자체에 대해
지식요건해당성
정합성
검증가능성
을 묻는 것은 부자연스럽다.
사진은 참이거나 거짓인 것이 아니라, 특정 시점과 맥락에서 생성된 자료이다.
강의 PDF도 그 자체가 하나의 지식이라기보다는, 그 안에 여러 Claim을 포함하고 있는 자료이다.
영상도 마찬가지다.
영상은 Claim이 아니라 Resource이고, 그 영상에서 발화·설명·주장·관찰을 추출했을 때 비로소 Claim이 등장한다.
따라서 자료에는 지식체계론이 아니라 별도의 자료체계론이 적용되어야 한다.
자료에 대해서는 오히려
출처성
무결성
식별성
접근성
연결성
이 핵심 기준이 된다.
이렇게 보면 LLM Wiki의 구조는 단순히
정보
↓
지식
이 아니라,
보다 정교하게는
Resource
↓
Claim
↓
Knowledge
↓
Knowledge Order
의 구조를 가진다.
자료는 Claim의 근거가 되고, Claim은 지식인정 절차의 대상이 되며, 인정된 Claim들은 다시 개념·이론·법리·기억·취향·계획 등의 형태로 조직된다.
그리고 이렇게 조직된 지식들은 최종적으로 하나의 Wiki 전체 질서 속에서 우선순위, 안정성, 수정 가능성, 공존 가능성, 운영 규칙을 부여받는다.
따라서 지금까지의 3단계 지식체계론은 폐기되는 것이 아니라, 더 큰 체계 안에서 자신의 정확한 위치를 갖게 된다.
그 위치는 다음과 같다.
자료체계론
↓
지식유형론
↓
지식편제론
↓
지식인정론
↓
안정력론
↓
지식질서론
↓
지식운영론
여기서 기존의 3단계 구조인
지식요건해당성
정합성
검증가능성
은 이 중 지식인정론에 해당한다.
다시 말해, 3단계 지식체계론은 LLM Wiki 전체 인식론의 전부가 아니라, 그 안에서 Claim을 지식으로 인정할 수 있는지 판단하는 핵심 심사 장치가 된다.
결국 LLM Wiki에서 가장 먼저 해야 할 일은 어떤 정보가 들어왔을 때 곧바로 참·거짓을 따지는 것이 아니다.
먼저 물어야 할 것은 이것이다.
이것은 무엇인가?
이 질문에 대한 답에 따라 이후의 심사 방식이 완전히 달라진다.
자료인가?
객관적 Claim인가?
주체귀속적 정보인가?
기억인가?
취향인가?
감정인가?
계획인가?
해석인가?
가설인가?
이론인가?
이 분류가 선행되어야 한다.
그 다음에야 비로소 그 정보가 어디에 배치되어야 하는지, 어떤 기준으로 인정되어야 하는지, 얼마나 안정적인 지위를 가져야 하는지, 다른 지식들과 어떻게 공존해야 하는지, 그리고 어떤 방식으로 운영되어야 하는지를 판단할 수 있다.
그러므로 최종적으로 이 체계는 단순한 “지식 저장 방식”이 아니다.
이것은 LLM Wiki 안에서 정보가 자료로 들어오고, Claim으로 추출되고, 지식으로 인정되고, 질서 속에 배치되고, 운영 규칙에 따라 사용되는 전 과정을 다루는 하나의 LLM Wiki 인식론이다.
즉 핵심은 다음과 같이 정리할 수 있다.
자료는 보존되고,
Claim은 심사되며,
지식은 조직되고,
질서는 안정화되며,
운영은 비례적으로 통제된다.
이 구조를 통해 LLM Wiki는 단순한 메모 저장소나 검색 가능한 데이터베이스를 넘어선다.
그것은 사용자의 객관지식, 주체귀속지식, 경험, 취향, 기억, 자료, 이론, 해석, 계획을 각각의 성질에 맞게 다루는 하나의 살아 있는 지식 질서가 된다.
결국 이 논의의 결론은 다음과 같다.
3단계 지식체계론은 모든 정보에 대한 만능 필터가 아니라, LLM Wiki 인식론 안에서 객관적 Claim을 지식으로 인정하기 위한 지식인정론이다.
그리고 그 앞에는
이 정보가 무엇인지 분류하는 지식유형론
이 있어야 하고,
그 바깥에는
자료를 관리하는 자료체계론
지식의 위치를 정하는 지식편제론
인정된 지식의 안정성을 부여하는 안정력론
지식 간 충돌과 공존을 다루는 지식질서론
지식 사용과 변경을 통제하는 지식운영론
이 함께 존재해야 한다.
따라서 LLM Wiki의 최종 구조는 다음 한 문장으로 압축할 수 있다.
LLM Wiki는 정보를 단순히 저장하는 체계가 아니라, 자료를 근거로 Claim을 형성하고, Claim을 지식으로 인정하며, 인정된 지식을 질서 속에 배치하고, 그 운용을 통제하는 인식론적 거버넌스 체계이다.
소개
시도하고자 했던 것과 그 이유를 알려주세요.
(주식관련 자료 스크랩한것들을 자료로서 어떻게 풀어나갈지 갈피를 못잡아서,
클로드에게 자료를 넣으면 아웃풋이 어떻게 나올지 궁금했고 ,
그 결과가 괜찮다면 러버블에서 만들어 보려고 시작했습니다. )
진행 방법
어떤 도구를 사용했고, 어떻게 활용하셨나요?
클로드와 러버블을 사용해 보았습니다. 러버블은 제대로 하지 못하여
클로드 코워크로 대시보드만 만들었습니다.
Tip: 사용한 프롬프트 전문을 꼭 포함하고, 내용을 짧게 소개해 주세요.
2026년 종목 내용을 기반으로 투자 아이디어를 종목별로 섹터별로 정리해서 맥락있게 인사이트 설명하는 대시보드 만들어줘, 배경 톤앤매너는 화이트, 전문적으로 부탁해. 국내2026년_인사이트도 참고해줘
언급된 날짜가 없어서 기록의 신뢰도가 떨어져서 날짜를 추가했습니다.
종목별 인사이트 설명란에 날짜도 같이 언급해줘, 그래야 매수할지 매도할지 알 수 있을 것 같아.
Tip: 활용 이미지나 캡처 화면을 꼭 남겨주세요.
보이는 종목들은 투자권유가 아니며, 가짜 자료를 가지고 만든 대시보드입니다.
아래 대시보드중 일부예시는 이미지난 선거이슈 예시를 들겠습니다
(투자권유가 아니며 절대 참고하지마세요, 자료 일부는 가짜로 넣었습니다)
결과와 배운 점
배운 점과 나만의 꿀팁을 알려주세요.
>수집한 자료가 이렇게 배치가 되고, 내가 가진 자료는 이렇게 정리가 되는거구나 알수있었습니다.
>한눈에 보이는 자료가 되어서 초보입장에서 만족스러웠습니다.
>자료의 퀄리티가 좋을수록 결과도 만족스러웠습니다.
>동영상,노트북LM자료, PPT 자료를 클로드가 이해하기 쉽게 docx파일(?)로 만들어야겠다는 생각이 듭니다.
과정 중에 어떤 시행착오를 겪었나요?
>대책없이 러버블먼저 시작하려고 했던게 실수같습니다.
>클로드에게 자료를 주고난 후 내가 뭘 원하는지 몰라서 첫 질문이 어려웠습니다.
>역으로 클로드에게 내가 원하는게 뭔지 추측하라고하고, 내가 어떤 단계인것같은지 질문해달라고 해야한다는걸 알게되었습니다.
도움이 필요한 부분이 있나요?
> 좀더 해보겠습니다.
앞으로의 계획이 있다면 들려주세요.
(방송듣고 스크랩하는것이 집착인것같아, 일부라도 자동화해서 저장 하고 싶습니다.)
도움 받은 글 (옵션)
참고한 지피터스 글이나 외부 사례를 알려주세요.
(투자자동화 사례글 발표할때 윤미정님의 "러버블로 만들어봤다" 이 첫마디가 힌트가 되었습니다, 감사합니다)
소개
지난번에 만들었던 ChatTracker(chatLog, MCP) 를 지인들에게 배포하고 테스트해 보았습니다.
ChatTracker는 제가 LLM과 나눈 대화 기록을 추적하고, 나중에 다시 찾아볼 수 있도록 만든 도구입니다.
처음에는 OpenCode CLI 중심으로 만들었는데, 주변에 공유해보니 다들 “이런 기능은 필요하다”고 공감해주셨습니다.
그런데 테스트를 하다 보니 새로운 문제를 발견했습니다.
저는 주로 CLI를 사용하지만, 주변 분들은 CLI보다 VS Code 확장 프로그램인 Roo Code를 더 많이 사용하고 있었습니다.
회사에서도 OpenCode CLI 버전과 VS Code 확장 프로그램인 Roo Code가 함께 제공되고 있었고요.
문제는 VS Code 확장 프로그램으로 설치된 Roo Code는 .opencode 설정을 따르지 않는다는 점이었습니다.
그래서 기존 ChatTracker로는 OpenCode CLI 대화는 추적할 수 있었지만, Roo Code에서 나눈 대화는 추적할 수 없었습니다.
결국 ChatTracker가 제대로 쓰이려면 Roo Code 대화 기록도 함께 추적할 수 있어야 했습니다.
1. Roo Code 대화 기록 저장 위치 찾기
먼저 Roo Code의 대화 내용이 실제로 어디에 저장되는지 찾기 시작했습니다.
처음에는 Roo Code에게 직접 물어봤습니다.
너의 대화내역 저장 경로가 어디냐?
VS Code 확장 프로그램으로 실행한 Roo Code의 작업 기록과 채팅 기록이 저장되는 실제 파일 위치를 알려줘.
Windows 기준으로 가능한 경로들을 알려주고, 어떤 파일을 확인해야 하는지도 설명해줘.
Roo Code는 여러 경로를 알려주었습니다.
%AppData%\Roaming\d\code
%AppData%\Roaming\log
Code\User\workspaceStorage\...\chatSessions
하지만 실제로 확인해보니 제가 찾는 대화 기록은 없었습니다.
결국 C 드라이브를 거의 전체 스캔하듯이 확인했고, 마침내 아래 폴더를 찾았습니다.
codemate.roo-cline/tasks
그 안에는 작업별 폴더와 여러 JSON 파일이 있었습니다.
api_conversation_history.json
history_item.json
task_metadata.json
ui_message.json
확인해보니 각 파일의 역할은 대략 다음과 같았습니다.
파일명
역할
api_conversation_history.json
API 기준 대화 기록
history_item.json
작업 기록 항목
task_metadata.json
작업 메타데이터
ui_message.json
UI에 표시되는 메시지 기록
이 중에서 ChatTracker에 필요한 핵심 파일은 ui_message.json 이었습니다.
사용자가 Roo Code 화면에서 실제로 주고받은 대화 흐름을 확인하려면 이 파일을 읽어야 했습니다.
2. ChatTracker에 Roo Code 기록 연결하기
이후에는 Roo Code에게 ChatTracker에 기능을 붙여달라고 요청했습니다.
ChatTracker에서 Roo Code의 대화 기록도 추적할 수 있도록 기능을 추가해줘. Windows 환경에서 Roo Code 확장 프로그램의 작업 기록은 codemate.roo-cline/tasks 폴더 아래에 있고,
각 작업 폴더 안에는 ui_message.json 파일이 있어. 해야 할 일:
1. Roo Code tasks 폴더를 설정에서 지정할 수 있게 해줘.
2. 각 작업 폴더의 ui_message.json 파일을 읽어줘.
3. 파일 변경을 실시간 폴링해서 새 메시지를 감지해줘.
4. 메시지를 파싱해서 기존 ChatTracker SQLite DB에 저장해줘.
5. 기존 OpenCode 대화 기록과 구분되도록 source 값을 roo_code로 저장해줘.
6. ChatTracker UI에 Roo Code 대화내역 메뉴를 추가해줘.
7. 기존 기능은 깨지지 않게 유지해줘.
작업은 다음 흐름으로 진행했습니다.
결과적으로 ChatTracker에서 Roo Code 대화 내역을 확인할 수 있게 되었습니다.
CLI에서 나눈 대화뿐 아니라 VS Code 확장 프로그램에서 나눈 대화도 한곳에서 볼 수 있게 된 것입니다.
다만 아직 해결하지 못한 부분도 있습니다.
Roo Code 대화 기록을 ChatTracker에서 확인하는 것은 가능해졌지만, Roo Code 확장 프로그램 안에서 ChatTracker MCP를 직접 활용하는 방법은 아직 찾지 못했습니다.
이 부분은 앞으로 더 확인해봐야 할 숙제로 남아 있습니다.
3. 업무 자료 DB를 MCP로 연결하기
Roo Code 기록을 붙이고 나니, ChatTracker에 더 살을 붙이고 싶어졌습니다.
저는 이번 스터디를 하면서 회사 PC에 옵시디언을 설치하고, 그동안 모아두었던 개인 업무 파일과 고객 대응 매뉴얼을 위키처럼 정리해보려고 하고 있었습니다.
그러다 이런 생각이 들었습니다.
내가 모아둔 업무 파일과 고객 대응 가이드도 DB화해서 MCP로 연결하면, LLM이 내 업무 자료를 참고해서 답변할 수 있지 않을까?
바로 OpenCode와 대화를 나누며 만들기 시작했습니다.
내가 가지고 있는 고객 대응 매뉴얼과 업무 파일들을 SQLite DB로 정리하고,
MCP 서버에서 검색 도구로 제공하고 싶어. 현재 일부 자료는 Access DB 형태로 되어 있고,
최종적으로는 LLM이 MCP tool call을 통해 관련 내용을 검색한 뒤 답변에 참고하도록 만들고 싶어. 해야 할 일:
1. Access DB에 있는 고객 대응 데이터와 업무 자료를 SQLite로 변환해줘.
2. SQLite에 문서 제목, 본문, 카테고리, 키워드, 원본 경로를 저장할 수 있는 테이블을 설계해줘.
3. MCP 서버에 search_work_docs 같은 검색 도구를 추가해줘.
4. 사용자의 질문을 받아 관련 문서를 검색하고 결과를 요약해서 반환해줘.
5. ChatTracker의 기존 MCP 기능과 충돌하지 않도록 구성해줘.
구조는 아래와 같습니다.
4. ChatTracker 안에 챗봇 붙이기
업무 자료 MCP가 생각보다 잘 동작했습니다.
LLM이 MCP를 호출해서 내용을 확인하고, 관련 자료를 이해한 뒤 요약해서 답변하는 흐름이 꽤 자연스러웠습니다.
그래서 다음으로는 ChatTracker 안에 직접 채팅창을 붙여보고 싶었습니다.
구상은 단순했습니다.
ChatTracker 안에 봇 채팅창을 만들고, 백엔드에서 OpenCode CLI 를 호출합니다.
사용자가 ChatTracker 채팅창에서 업무 관련 질문을 하면, OpenCode가 새 세션을 열고 MCP를 통해 업무 자료를 검색한 뒤 답변하는 방식입니다.
이렇게 하면서 ChatTracker는 단순한 대화 기록 추적 도구에서 조금씩 업무 보조 도구처럼 변해가기 시작했습니다.
결과와 배운 점
이번 작업을 통해 ChatTracker에는 몇 가지 기능이 더 붙었습니다.
기능
상태
OpenCode CLI 대화 기록 추적
가능
Roo Code 대화 기록 추적
가능
ChatTracker UI에서 Roo Code 기록 확인
가능
업무 자료 SQLite DB 검색
가능
MCP를 통한 업무 자료 검색
가능
ChatTracker Bot 채팅창
구현 시도
Roo Code에서 ChatTracker MCP 직접 사용
아직 미해결
가장 크게 배운 점은 LLM 도구마다 대화 기록을 저장하는 방식이 다르다는 것이었습니다.
OpenCode CLI와 Roo Code는 비슷한 LLM 개발 도구처럼 보이지만, 설정 파일과 대화 기록 저장 방식은 전혀 달랐습니다.
또 하나 배운 점은 MCP가 단순한 부가 기능이 아니라 LLM의 활용 범위를 넓혀주는 연결 방식이라는 점입니다.
내가 가진 업무 자료를 DB화하고 MCP로 연결하니, LLM이 일반적인 답변만 하는 것이 아니라 실제 업무 자료를 참고해서 답변할 수 있었습니다.
시행착오도 있었습니다.
처음에는 Roo Code가 알려준 저장 경로를 믿고 찾아봤지만, 실제 대화 기록은 없었습니다.
결국 직접 파일 시스템을 뒤지면서 codemate.roo-cline/tasks 폴더를 찾아야 했습니다.
또, 회사 LLM은 인터넷 접속이 막혀 있기 때문에 MCP를 이용해서 웹 검색이나 URL 패치를 대신 해주면 어떨까 하는 생각도 했습니다.
기술적으로는 가능해 보였습니다.
하지만 이 부분은 일단 멈췄습니다.
사내 보안 정책상 인터넷 접근을 우회하는 형태로 해석될 수 있다고 판단했기 때문입니다.
이번 작업을 하면서 느낀 나만의 팁은 이것입니다.
LLM에게 “만들어줘”라고 하기 전에, 먼저 “너의 데이터가 어디에 저장되는지”, “어떤 파일이 실제 화면과 연결되는지”를 끝까지 물어보는 것이 중요했습니다.
앞으로는 아직 남아 있는 숙제인 Roo Code 확장 프로그램에서 ChatTracker MCP를 직접 활용하는 방법을 더 찾아보고 싶습니다.
또 ChatTracker Bot 기능도 조금 더 안정화해서, 실제 업무 자료 검색 도구로 쓸 수 있을지 테스트해볼 계획입니다.
결국 제가 계속 고민하게 되는 지점은 이 질문입니다.
제한적인 회사 내부 환경에서, 보안 정책을 지키면서도 LLM을 더 효과적으로 활용할 수 있는 서비스는 무엇일까?
ChatTracker는 그 질문에 대한 작은 실험으로 계속 살이 붙고 있습니다.
처음에는 문서를 많이 넣어두기만 한 상태였다. 지금은 질문을 하면 관련 법령ㆍ예규ㆍ해설 문서를 찾아내고, 그 근거가 믿을 만한지 점검한 다음, 필요한 조문만 짧게 꺼내고, 답변 끝에 "이 근거가 어떤 자격으로 쓰였는지"까지 표시할 수 있는 상태가 됐다.
전체 그림
처음 상태 문서가 많음 | v
어디에 뭐가 있는지 찾기 어려움 | v
AI가 답하더라도 근거를 확인하기 어려움 현재 상태 문서 원문 | v
작은 조각으로 나눔 | v
검색용 색인에 넣음 | v
여러 검색 방식으로 후보를 찾음 | v
공식 근거인지 점검함 | v
짧은 근거와 함께 답변함
이 위키가 해결하려는 문제
지방계약 문서는 길고 복잡하다. 법령, 시행령, 시행규칙, 예규, CSR 유권해석, 블로그, 직접 작성한 해설이 섞여 있다.
사람이 볼 때 어려운 점은 세 가지다.
어디에 답이 있는지 찾기 어렵다.
찾은 문서가 공식 근거인지 참고자료인지 구분하기 어렵다.
문서 전체가 너무 길어서 실제로 필요한 한 문장을 찾기 어렵다.
이 위키는 이 세 가지를 줄이기 위해 만들어졌다.
질문: 임대차계약은 수의계약이 가능할까? 예전 방식 시행령 제25조 전체를 열어봄 긴 조문 안에서 제1항, 제5호, 사목을 사람이 찾아야 함 개선 후 바로 제25조 제1항 제5호 사목 조각을 찾음 필요한 한 문장만 답변 근거로 보여줌
어려운 용어 쉽게 번역하기
어려운 말
쉬운 말
실제 의미
RAG
자료 찾아서 답하기
AI가 자기 머리로만 답하지 않고, 저장된 문서를 먼저 찾아서 답하는 방식
chunk
문서 조각
긴 문서를 검색하기 좋게 나눈 작은 단위
micro chunk
아주 작은 문서 조각
조문을 항ㆍ호ㆍ목 단위까지 더 잘게 나눈 것
embedding
의미 좌표 만들기
문장의 의미가 비슷한지 비교할 수 있게 숫자로 바꾸는 것
vector search
의미 검색
단어가 똑같지 않아도 뜻이 비슷한 문서를 찾는 검색
FTS/BM25
정확한 글자 검색
조문번호, 문구, 제목처럼 정확히 들어간 단어를 찾는 검색
MongoDB RAG
문서조각 저장소 검색
많은 chunk를 저장하고 의미 검색하는 기본 검색 창고
OpenViking hybrid
여러 검색법을 섞은 검색
의미 검색, 정확 검색, 우선순위 규칙을 합쳐 더 좋은 근거를 고르는 방식
qmd
Markdown 문서 탐색기
Obsidian 문서 위치를 찾는 데 좋은 보조 검색
evidence quality
근거 품질 검사
찾은 문서가 답변 근거로 써도 되는지 점검하는 과정
성능 지표 쉽게 보기
숫자
쉬운 뜻
예시
hit@1 1.0000
첫 번째 결과가 정답이라는 뜻
시험 질문을 물었을 때 기대한 근거가 바로 1등으로 나옴
hit@5 1.0000
상위 5개 안에는 정답이 있다는 뜻
첫 번째가 아니어도 5개 안에는 들어옴
MRR 1.0000
정답이 거의 항상 앞에 있다는 뜻
1.0에 가까울수록 좋음
answer-eligible@1
첫 번째 결과가 답변에 써도 되는 근거라는 뜻
공식자료나 잘 정리된 위키 문서인지 확인
low_trust_top 0
첫 번째 결과에 낮은 신뢰도 문서가 없다는 뜻
개인 메모나 임시 보고서가 1등으로 올라오지 않음
전체 발전 과정 한눈에 보기
[0] 문서 구조 점검 | v
[1] MongoDB RAG 저장소 구축 | v
[2] L0/L1 요약 지도 추가 | v
[3] OpenViking식 구조 실험 | v
[4] OpenViking 실제 실행 실험 | v
[5] Hybrid 검색 우선순위 개선 | v
[6] FTS/BM25 정확 검색 추가 | v
[7] 근거 품질 평가 추가 | v
[8] 법제처 공식 법령 원문 추가 | v
[9] 조문 단위로 자르기 | v
[10] 항ㆍ호ㆍ목 단위로 더 잘게 자르기 | v
[11] 답변 끝에 공식 근거 성적표 붙이기 | v
[12] 근거 자격표를 더 세밀하게 나누기
단계별 쉬운 해설
0단계: 문서가 망가지지 않았는지 확인
처음에는 검색 성능보다 기본 정리가 중요했다. 문서 링크가 깨지지 않았는지, 출처 번호가 맞는지, 파일 구조가 맞는지 확인했다.
검증 결과
lint PASS
errors 0
warnings 0
쉬운 의미:
문서함 정리 상태: 정상
깨진 링크: 없음
출처 목록: 정상
1단계: 문서를 검색 창고에 넣기
긴 Markdown 문서를 작은 조각으로 나누고 MongoDB라는 저장소에 넣었다.
긴 문서 | v
작은 조각들 | v
MongoDB 저장소 | v
질문하면 비슷한 조각 검색
주요 결과:
최초 전체 ingest: 14803/14803 chunks complete
쉬운 의미:
문서 조각 14,803개를 검색 창고에 모두 넣었다.
2단계: 문서 지도를 만들기
문서 조각만 많으면 검색이 느리고, 엉뚱한 조각이 나올 수 있다. 그래서 각 문서에 짧은 요약 지도인 L0/L1을 만들었다.
L0 = 아주 짧은 요약
L1 = 조금 더 긴 개요
L2 = 실제 원문
그림으로 보면:
질문 | v
먼저 L0/L1 지도에서 관련 문서 후보를 찾음 | v
필요할 때만 L2 원문 조각을 봄
초기 평가:
24문항 평가
MongoDB baseline hit@5 0.9583
MongoDB context hit@5 0.9583
MongoDB strict hit@5 0.9167
개선 후:
MongoDB baseline hit@5 1.0000
MongoDB context hit@5 1.0000
쉬운 의미:
처음에는 24문제 중 23문제 정도를 상위 5개 안에서 찾았다.
개선 후에는 24문제 모두 상위 5개 안에서 찾았다.
3단계: OpenViking식 구조로 바꿔볼 준비
OpenViking은 자료, 기억, 기술을 파일 시스템처럼 정리하는 방식이다. 이 단계에서는 실제 OpenViking을 완전히 쓰기 전에, 우리 위키 자료를 OpenViking이 읽을 수 있는 모양으로 정리했다.
LLM Wiki 문서 | v
OpenViking식 resource / skill / session 구조 | v
나중에 OpenViking으로 옮기거나 비교 가능
검증 결과:
coverage 1.0000
lexical-hybrid hit@5 1.0000
쉬운 의미:
OpenViking식으로 내보낸 자료 안에 필요한 정답 문서가 빠짐없이 들어 있었다.
4단계: OpenViking을 실제로 돌려본 실험
OpenAI API Key 없이, 로컬 embedding만으로 OpenViking runtime을 시험했다.
결과:
hit@1 0.5000
hit@5 0.6250
MRR 0.5778
쉬운 의미:
실제 OpenViking runtime만으로는 아직 성능이 충분하지 않았다.
첫 번째 결과가 정답인 경우가 절반 정도였다.
그래서 결론은 이랬다.
OpenViking runtime 단독 사용: 아직 이르다
MongoDB RAG: 기본 검색으로 유지
OpenViking: 구조 실험과 보조 검색으로 활용
5단계: 여러 검색 결과를 섞어 더 좋은 결과 고르기
이 단계에서 OpenViking hybrid가 중요해졌다. 단순히 한 검색엔진만 믿지 않고 여러 후보를 섞은 뒤, 공식 근거와 좋은 concept 문서를 위로 올렸다.
MongoDB 검색 결과 +
OpenViking식 L0/L1 결과 +
정확 문구 검색 +
우선순위 규칙 | v
OpenViking hybrid 결과
27문항 평가:
OpenViking hybrid hit@1 1.0000
OpenViking hybrid hit@5 1.0000
MRR 1.0000
쉬운 의미:
27개 시험 질문에서 첫 번째 결과가 모두 기대한 근거였다.
다만 이때 중요한 깨달음이 있었다.
검색 점수만 높다고 좋은 답변 근거는 아니다.
CSR 사례나 블로그가 1등으로 올라오면 답변에는 조심해서 써야 한다.
6단계: 정확한 글자 검색 FTS/BM25 추가
의미 검색은 비슷한 뜻을 찾는 데 좋지만, 조문번호나 정확한 문구는 글자 그대로 찾는 검색이 더 강하다.
그래서 FTS/BM25를 붙였다.
의미 검색이 잘하는 것: "입찰참가자격 제한"과 "부정당업자 제재"처럼 비슷한 뜻 찾기 FTS/BM25가 잘하는 것: "제25조제1항제5호사목" "SRC-002" "재공고입찰"
초기 결과:
FTS/BM25 hit@1 0.9630
FTS/BM25 hit@5 1.0000
쉬운 의미:
정확한 단어가 들어간 질문에서는 매우 잘 찾았다.
7단계: 찾은 문서가 믿을 만한지 검사
이때부터 단순히 "찾았나?"가 아니라 "찾은 것이 답변 근거로 안전한가?"를 보기 시작했다.
찾은 문서 | +-- 공식 법령/예규 원문인가? | +-- 공식 source chunk인가? | +-- 정리된 concept인가? | +-- CSR/블로그 같은 참고자료인가? | +-- 개인 메모나 임시 문서인가?
새로 본 지표:
official@1
answer-eligible@1
low-trust top
reference-only risk
쉬운 의미:
정답을 찾는 것만으로는 부족하다.
공식 근거와 참고자료를 구분해야 한다.
8단계: 법제처 공식 법령 원문 추가
이전에는 예규, CSR, 블로그, concept가 중심이었다. 이후 법제처 OpenLaw API로 지방계약법령 3종을 공식 source로 넣었다.
SRC-011 지방계약법
SRC-012 지방계약법 시행령
SRC-013 지방계약법 시행규칙
쉬운 의미:
이제 위키 안에 지방계약법령 공식 원문이 들어왔다.
답변이 더 공식 근거에 가까워졌다.
9단계: 법령을 조문 단위로 자르기
법령 원문이 들어와도 문서가 너무 길면 읽기 어렵다. 그래서 법령을 조문 단위로 나눴다.
지방계약법 시행령 전체 | v
제25조
제26조
제31조
...
생성 결과:
지방계약법 조문 chunks: 81
시행령 조문 chunks: 275
시행규칙 조문 chunks: 149
합계: 505
32문항 평가:
OpenViking hybrid hit@1 1.0000
FTS/BM25 hit@1 0.9375
쉬운 의미:
제25조, 제26조, 제31조처럼 조문 번호를 물으면 잘 찾게 됐다.
하지만 문제가 남았다.
제25조 하나가 여전히 너무 길다.
제25조 안에 제1항, 제5호, 사목 같은 세부 내용이 많다.
10단계: 항ㆍ호ㆍ목 단위로 더 잘게 자르기
마지막 성능개선은 조문을 한 번 더 잘게 나누는 것이었다.
예전 시행령 제25조 전체 개선 후 시행령 제25조 | v 제1항 | v 제5호 | v 사목
생성 결과:
SRC-017 지방계약법 micro chunks: 255
SRC-018 시행령 micro chunks: 1079
SRC-019 시행규칙 micro chunks: 483
합계: 1817
대표 예시:
시행령 제25조 제1항 제5호 사목
이 조각에는 이런 내용만 들어 있다.
사. 추정가격이 5천만원 이하인 임대차 계약 연액 또는 총액을 기준으로 추정가격을 산정한다
쉬운 의미:
"임대차 수의계약"을 물으면 이제 시행령 제25조 전체를 보여주지 않는다.
바로 제25조 제1항 제5호 사목만 꺼낸다.
11단계: 답변 끝에 공식 근거 성적표 붙이기
이번 단계의 핵심은 검색을 더 많이 하는 것이 아니라, 답변을 믿을 수 있게 만드는 규칙을 고정한 것이다.
예전에는 검색 결과가 좋아도 이런 의문이 남을 수 있었다.
이 답변은 공식 법령을 보고 쓴 걸까?
CSR 사례를 공식 근거처럼 쓴 건 아닐까?
블로그나 개인 메모가 앞에 온 건 아닐까?
어떤 검색 방식으로 찾은 걸까?
이제는 답변 끝에 다음과 같은 성적표가 붙는다.
근거 방식
근거 신뢰도
공식 근거 게이트
상위 근거
법령 전용 preflight 근거
판정 이유
한계
재현 명령
쉬운 말로 하면 다음과 같다.
답변 | v
어떤 자료를 봤는지 표시 | v
그 자료가 공식 법령인지 표시 | v
CSR/블로그는 참고자료인지 표시 | v
다시 확인할 명령까지 표시
이번에 고정한 근거 순서는 이렇다.
1순위: 지방계약법, 시행령, 시행규칙
2순위: 지방계약예규, 행정규칙
3순위: 잘 정리된 위키 concept와 source summary
4순위: CSR 유권해석
5순위: 블로그, 회원 메모, 사례글
중요한 점:
CSR이나 블로그가 검색되더라도 참고자료로만 쓴다.
공식 근거가 약하면 위키의 정식 지식으로 바로 승격하지 않는다.
또 OpenViking식 L0/L1 지도를 세 개 더 만들었다.
법령별 지도
조문별 지도
실무질의별 지도
쉬운 의미:
긴 법령집을 통째로 뒤지는 것이 아니라,
먼저 "어느 법령의 어느 조문 근처를 봐야 하는지" 알려주는 안내도를 만든 것이다.
최종 성능을 사람 말로 해석하기
FTS/BM25 eval
hit@1 0.9906
hit@5 1.0000
쉬운 말:
시험 질문 106개 중 거의 전부를 첫 번째 결과로 찾았다.
상위 5개 안에는 모두 들어왔다.
조문번호나 정확한 문구를 찾는 데 특히 강하다.
OpenViking hybrid eval
hit@1 0.8679
hit@5 1.0000
쉬운 말:
첫 번째 결과가 항상 정답은 아니지만,
상위 5개 안에는 기대한 근거가 모두 들어왔다.
답변 context를 만들 때 공식 근거와 위키 정리문을 함께 배치하는 데 유용하다.
MongoDB RAG eval
baseline hit@1 0.8302
baseline hit@5 0.9811
쉬운 말:
전체 문서 조각 저장소에서 빠르게 의미 검색하는 기본 검색 창고다.
대부분의 질문에서 좋은 후보를 찾지만,
가끔 CSR이나 웹 사례가 앞에 올 수 있어 공식 근거 게이트와 함께 써야 한다.
Evidence quality
legal FTS authority answer_eligible@1 0.9434
legal FTS authority answer_eligible@5 0.9811
low_trust_top 0
쉬운 말:
첫 번째 결과가 답변에 쓸 만한 근거인 경우가 94% 정도다.
상위 5개까지 보면 98% 정도가 답변 가능한 근거를 포함한다.
낮은 신뢰도 문서가 첫 번째로 올라온 경우는 없다.
Lint
PASS
errors 0
warnings 0
쉬운 말:
문서 구조와 링크 상태가 정상이다.
qmd
6911 files
56853 vectors
쉬운 말:
Obsidian/Markdown 문서 6,911개가 검색 색인에 들어가 있고,
의미 검색용 위치표가 56,853개 만들어져 있다.
성능 변화 막대그래프
숫자를 직관적으로 보면 다음과 같다.
OpenViking runtime pilot hit@1
0.5000 [##########----------] OpenViking hybrid 27문항 hit@1
1.0000 [####################] OpenViking hybrid 36문항 hit@1
1.0000 [####################] FTS/BM25 106문항 hit@1
0.9906 [####################] OpenViking hybrid 106문항 hit@1
0.8679 [#################---] MongoDB baseline 106문항 hit@1
0.8302 [#################---] legal FTS authority answer_eligible@1
0.9434 [###################-] FTS/BM25 27문항 hit@1
0.9630 [###################-] FTS/BM25 36문항 hit@1
0.9167 [##################--] qmd 36문항 hit@1
0.3333 [#######-------------]
해석:
OpenViking 단독 runtime은 아직 부족했다.
하지만 OpenViking hybrid 방식은 매우 안정적이다.
FTS/BM25는 106문항 기준으로 정확 검색 보조 역할이 더 강해졌다.
legal FTS authority는 "답변에 써도 되는 근거인가"를 보는 데 가장 안정적이다.
qmd는 답변용 검색보다 문서 위치 탐색에 더 적합하다.
새로 추가된 변화: "찾았다"와 "믿을 수 있다"를 분리
이번 개선의 핵심은 단순하다.
기존 질문 정답 문서를 찾았나? 새 질문 정답 문서를 찾았나? 그 문서가 공식 근거인가? 참고자료라면 공식 근거가 같이 잡혔나? 낮은 신뢰도 자료라면 위키 지식으로 승격하지 않도록 막았나?
예전에는 어떤 문서가 1등으로 검색됐는지를 주로 봤다. 이제는 1등 문서가 무엇인지뿐 아니라, 그 문서의 신분증까지 확인한다.
검색 결과 1등 | +--> 공식 법령인가? official-law +--> 행정안전부 예규인가? admin-rule +--> 위키 정리문인가? compiled-wiki +--> CSR/블로그/사례인가? reference-only +--> 회원 메모인가? member-note +--> 임시 보고서인가? low-trust
이렇게 나누는 이유는 분명하다.
법령/예규 -> 답변의 핵심 근거로 사용 가능 위키 정리문 -> 원문과 함께 확인하면 사용 가능 CSR/블로그/사례 -> 참고 사례로만 사용 회원 메모/임시 보고서 -> 답변 핵심 근거로 쓰면 위험
새 근거 자격표가 보여주는 것
이번 리포트에는 다음 숫자들이 추가로 남는다.
| 지표 | 쉬운 뜻 |
|---|---|
| official@1 | 1등 검색 결과가 공식 법령이나 공식 예규인가 |
| official@5 | 상위 5개 안에 공식 법령이나 공식 예규가 있는가 |
| answer-eligible@1 | 1등 결과를 답변 근거로 써도 되는가 |
| ref+official | 참고자료가 먼저 나왔지만 공식 근거도 함께 찾았는가 |
| reference-only risk | 참고자료만 있고 공식 근거가 부족한 위험 사례인가 |
| promotion blocked | 위키 지식으로 승격하면 안 되는 사례인가 |
실제 최신 OpenViking hybrid 결과는 다음과 같다.
OpenViking hybrid official@1 0.5377 official@5 0.9340 answer-eligible@1 0.9151 answer-eligible@5 0.9717 reference-only risk 3건 promotion blocked 3건
쉬운 말:
첫 번째 결과가 항상 공식 법령은 아니다.
하지만 상위 5개 안에는 공식 근거가 거의 들어온다.
첫 번째 결과가 답변에 쓸 수 있는 근거인 비율은 높다.
공식 근거 없이 참고자료만 잡힌 위험 사례는 따로 기록된다.
legal FTS authority는 조금 다르게 읽어야 한다.
legal FTS authority official@1 1.0000 official@5 1.0000 answer-eligible@1 1.0000
이 숫자는 "일반 검색이 완벽하다"는 뜻이 아니다. 공식 법령ㆍ예규 source id만 강제로 뒤지는 안전망을 만들었더니, 106개 평가 질문 모두에서 공식 근거 후보를 찾을 수 있었다는 뜻이다.
일반 검색 사용자가 실제로 질문했을 때 자연스럽게 어떤 문서가 올라오는지 봄 legal FTS authority 공식 근거만 따로 뒤져서 안전망이 있는지 봄
답변 끝에 붙는 새 표시
이제 답변 말미의 공식 근거 게이트에는 이런 표시가 붙는다.
1순위 근거 층위: admin-rule
공식 근거 rank: top-1
공식 법령 조문 rank: 전체 FTS 없음, 법령 전용 preflight top-1
예규/공식 실무자료 rank: top-1
답변 가능 근거 rank: top-1
참고자료 top 처리: not-reference-top
concept 승격 게이트: allow-official-supported
근거 품질 점수: 76/100 (중상)
비전문가용으로 번역하면 이렇다.
이번 답변은 행정안전부 예규가 1등 근거로 잡혔다.
법령 조문은 일반 검색 1등은 아니었지만, 법령 전용 검색에서 바로 확인됐다.
CSR이나 블로그를 핵심 근거로 쓰지 않았다.
이 답변은 위키 지식으로 축적해도 되는 수준의 공식 근거를 갖췄다.
다만 점수는 정답 확률이 아니라 근거 품질 점수다.
새 예시: 설계변경ㆍ물가변동 계약금액 조정
이번에는 이런 질문을 던졌다.
지방자치단체 공사계약에서 설계변경이나 물가변동이 발생한 경우
계약금액 조정이 필요한 이유는 무엇인가?
일반 말로 바꾸면 이런 질문이다.
공사 도중 설계가 바뀌거나 자재값ㆍ인건비가 달라졌는데,
처음 계약한 금액을 그대로 두어도 되는가?
위키가 찾아낸 핵심 근거는 다음이었다.
지방계약법 제22조 계약 후 물가변동, 설계변경, 계약내용 변경으로 계약금액 조정이 필요하면 조정한다. 시행령 제73조 물가가 일정 요건 이상 변동하면 계약금액을 조정한다. 시행령 제74조 설계변경으로 공사량이 늘거나 줄면 계약금액을 조정한다. 계약집행기준 조정 신청, 처리기한, 증빙, 기성대가 지급 등을 실무 절차로 정한다.
답변의 쉬운 결론은 이렇다.
처음 계약금액은 처음 설계와 처음 가격조건을 기준으로 정한 금액이다.
그런데 공사량이 바뀌거나 물가가 크게 달라지면,
처음 금액은 실제 공사 내용과 맞지 않게 된다.
그래서 계약금액을 다시 맞춰야 한다.
왜 중요한지도 분명하다.
계약상대자 보호 책임 없는 설계변경이나 물가 급등을 전부 떠안지 않게 한다. 지방자치단체 보호 공사량이 줄거나 가격이 내려갔는데도 과다 지급하지 않게 한다. 공사 안정성 돈 문제 때문에 공사가 지연되거나 품질이 떨어지는 것을 줄인다. 분쟁 예방 "누가 얼마를 더 부담해야 하는가"를 법령 절차로 정리한다.
이 질문의 근거 성적표는 이렇게 나왔다.
게이트 상태: 통과
공식 법령 조문: 전체 검색 top-2, 법령 전용 검색 top-1
1순위 근거 층위: admin-rule
답변 가능 근거: top-1
CSR/블로그 자료: 검색에는 잡혔지만 참고자료로만 처리
concept 승격 게이트: allow-official-supported
근거 품질 점수: 85/100 (높음)
쉬운 해석:
첫 번째 근거는 행정안전부 예규였다.
공식 법령 조문도 바로 뒤에서 확인됐다.
CSR 자료가 검색되기는 했지만 핵심 근거로 쓰지 않았다.
따라서 이 답변은 공식 근거가 충분한 답변으로 볼 수 있다.
새 예시: 계약보증금의 목적과 불이행 효과
이번에는 이런 질문을 던졌다.
계약보증금 제도의 목적은 무엇이며,
계약상대자가 계약을 이행하지 않을 경우 어떤 법적 효과가 발생할 수 있는가?
일반 말로 바꾸면 이런 질문이다.
지방자치단체와 계약한 업체가 계약을 제대로 이행하지 않으면,
처음에 맡겨둔 계약보증금은 어떻게 되는가?
위키가 찾아낸 핵심 근거는 다음이었다.
지방계약법 제15조 계약을 체결하려는 자는 계약보증금을 내야 한다. 계약상대자가 계약상 의무를 이행하지 않으면 계약보증금은 지방자치단체에 귀속된다. 시행령 제51조 계약의 이행을 보증하는 방법과 계약보증금 비율을 정한다. 시행령 제54조 정당한 이유 없이 계약상 의무를 이행하지 않으면 계약보증금을 세입조치한다. 지방계약법 제30조의2 계약보증금 세입조치는 계약 해제ㆍ해지 사유와 연결될 수 있다. 계약집행기준 계약보증금 제출, 면제 시 확약서, 세입조치 처리 절차를 실무적으로 설명한다.
답변의 쉬운 결론은 이렇다.
계약보증금은 그냥 맡겨둔 돈이 아니다.
계약상대자가 계약을 끝까지 이행하도록 압박하는 안전장치다.
계약을 제대로 이행하면 돌려받지만,
정당한 이유 없이 이행하지 않으면 지방자치단체에 귀속된다.
이 질문에서 특히 중요한 점은 표현을 정확히 고친 것이다.
부정확할 수 있는 표현 계약보증금을 손해배상에 사용한다. 법령 원문에 가까운 표현 계약보증금을 해당 지방자치단체에 귀속시킨다. 계약보증금을 세입조치한다.
이 질문의 근거 성적표는 이렇게 나왔다.
게이트 상태: 통과
공식 법령 조문: 전체 검색 top-1, 법령 전용 검색 top-1
1순위 근거 층위: official-law
예규/공식 실무자료: top-2
답변 가능 근거: top-1
CSR/블로그 자료: 상위 핵심 근거로 사용하지 않음
concept 승격 게이트: allow-official-supported
근거 품질 점수: 90/100 (높음)
쉬운 해석:
이번 답변은 지방계약법 조문이 바로 1등 근거로 잡혔다.
시행령과 행정안전부 예규도 함께 확인됐다.
그래서 "계약보증금은 왜 있고, 불이행하면 어떻게 되는가"라는 질문에
공식 법령 중심으로 답할 수 있었다.
그래서 무엇이 좋아졌나
이번 개선 전후를 비교하면 다음과 같다.
전 "검색 결과가 좋다" "hit@1이 높다" "hit@5가 높다" 후 "검색 결과가 좋다" "공식 근거가 상위에 있다" "참고자료는 참고자료로만 표시된다" "공식 근거가 없으면 위키 지식 승격을 막는다" "답변 끝에서 근거 자격을 확인할 수 있다"
즉, 이 위키는 이제 검색엔진이 아니라 작은 법무 검토실처럼 동작한다.
검색 담당 관련 문서를 찾음 근거 심사 담당 공식 근거인지 확인함 기록 담당 어떤 근거 자격으로 답했는지 남김
현재 위키의 검색 구조
사용자 질문 | +--> OpenViking hybrid | | | +--> 답변용 근거 고르기 | +--> 공식 근거와 concept 우선 | +--> 최종 context pack 구성 | +--> FTS/BM25 | | | +--> 조문번호, 정확 문구, Source ID 찾기 | +--> 낮은 신뢰도 문서 제외 | +--> MongoDB RAG | | | +--> 빠른 의미 검색 | +--> 많은 chunk에서 후보 찾기 | +--> qmd | +--> Obsidian 문서 위치 찾기 +--> Markdown 탐색 보조
예시: 임대차 수의계약 질문이 처리되는 방식
질문:
임대차계약은 수의계약이 가능한가?
검색 흐름:
질문 | v
수의계약 + 임대차 키워드 확인 | v
시행령 제25조 관련 후보 찾기 | v
제25조 전체가 아니라 제1항 제5호 사목으로 좁힘 | v
해당 micro chunk 원문 발췌 출력
답변 근거:
지방계약법 시행령 제25조 제1항 제5호 사목
답변에 들어가는 원문:
추정가격이 5천만원 이하인 임대차 계약
연액 또는 총액을 기준으로 추정가격을 산정한다
중요한 차이:
예전 답변 context: 시행령 제25조 전체 + concept 장문 발췌 현재 답변 context: 필요한 사목 micro chunk 1개
지금 가장 중요한 판단
이 위키의 성능은 단순히 "잘 찾는다"에서 끝나지 않는다.
지금은 다음 질문을 함께 본다.
1. 찾았는가?
2. 첫 번째로 찾았는가?
3. 공식 근거인가?
4. 답변에 써도 되는 자료인가?
5. 너무 긴 원문을 넣지 않고 필요한 부분만 넣었는가?
그래서 현재 기준으로 가장 중요한 검색 경로는 다음과 같다.
목적
추천 도구
이유
답변용 근거 구성
OpenViking hybrid
여러 검색 후보를 합쳐 공식 근거와 concept를 우선 배치한다.
조문번호ㆍ정확 문구 확인
FTS/BM25
제25조제1항제5호사목 같은 정확한 글자 검색에 강하다.
빠른 의미 검색
MongoDB RAG
전체 chunk에서 빠르게 비슷한 내용을 찾는다.
Obsidian 문서 위치 확인
qmd
문서 탐색과 관리 보조에 적합하다.
왜 이게 의미 있는가
일반 AI 답변은 그럴듯하지만 근거가 불명확할 수 있다.
이 위키는 답변 전에 문서를 찾고, 그 문서가 믿을 만한지 확인하고, 필요한 원문만 보여준다.
일반 AI 답변 질문 -> 바로 답변 위험: 근거가 불명확할 수 있음 이 LLM Wiki 답변 질문 -> 근거 검색 -> 공식성 점검 -> 짧은 원문 확인 -> 답변 장점: 왜 그렇게 답했는지 확인 가능
아직 남은 과제
현재는 답변 품질을 운영 규칙으로 고정하는 단계까지 왔다. 다음 과제는 이 규칙을 실제 반복 질의에서 더 다듬는 것이다.
다음 개선 방향 | +--> 공식 근거가 1순위로 오는 비율을 더 높이기 | +--> 실제 질문 로그를 모아 낮은 신뢰도 후보가 왜 올라오는지 분석하기 | +--> 답변에서 조문, 예규, 실무 판단을 더 짧고 명확하게 분리하기 | +--> 공식 근거가 약한 답변은 계속 concept 승격을 막기
결론
이 위키는 처음에는 문서를 검색 가능한 형태로 넣는 단계였다.
지금은 법령ㆍ예규ㆍ해설ㆍ사례를 나누어 저장하고, 여러 검색 방식을 조합해 근거를 찾고, 그 근거가 답변에 쓸 만한지 평가하는 단계까지 왔다.
가장 큰 변화는 다음이다.
전: 문서가 많다 찾기는 어렵다 근거 신뢰도 판단이 어렵다 후: 문서를 조각내 저장한다 질문에 맞는 조각을 찾는다 공식 근거인지 확인한다 필요한 조문만 짧게 보여준다
따라서 현재 위키는 단순한 메모 모음이 아니라, 지방계약 질문에 대해 근거를 추적하면서 답변을 만들 수 있는 로컬 지식 시스템에 가깝다.
한 줄 요약
지방계약법령과 행정안전부 예규, CSR 유권해석, 네이버 블로그 해설 글을 그냥 모아두는 데서 멈추지 않고, 의미 단위로 쪼개고, 검색 가능하게 만들고, 답변마다 출처와 신뢰도를 붙이는 LLM Wiki로 바꿨다.
중요한 것은 개발자가 멋진 검색기를 만들었다는 이야기가 아니다. 사용자가 실제로 지방계약 실무 질문을 던졌을 때, "이 답변은 어디를 보고 나온 것인가", "공식 근거인가 참고 사례인가", "다음에도 믿고 써도 되는가"를 확인할 수 있게 만든 과정이다.
이런 분들께 도움된다
지방계약법, 예규, 유권해석, 블로그 해설을 자주 찾아보는 실무자
자료는 많은데 막상 질문하면 어디를 봐야 할지 매번 다시 찾는 사람
AI 답변을 쓰고 싶지만, 출처 없는 답변은 불안한 사람
Obsidian이나 Markdown으로 법령 자료를 모아두었지만 검색 품질이 아쉬운 사람
"RAG가 좋다는데, 법령 업무에서 어떻게 믿을 수 있게 만들지?"가 궁금한 사람
시작점: 자료는 많았지만, 믿고 묻기는 어려웠다
지방계약 업무를 하다 보면 자료가 한 곳에만 있지 않다.
행정안전부 예규가 있고, 지방계약법령이 있고, CSR 유권해석처럼 오래 축적된 실무 사례가 있고, 네이버 블로그에는 사람이 읽기 좋게 풀어쓴 해설 글이 있다. 각각 가치가 있지만 성격은 다르다.
공식 예규는 직접 근거가 될 수 있다. CSR 유권해석은 실무 감각을 잡는 데 좋지만 국가계약법 기반 과거 사례가 섞여 있을 수 있다. 블로그 글은 이해하기 쉽지만, 공식 근거와 같은 층위로 쓰면 위험하다.
처음에는 이 자료들을 Markdown으로 모아두면 충분할 줄 알았다. 하지만 실제 질문은 이렇게 들어온다.
재입찰과 재공고입찰이 구체적으로 어떤 상황에서 차이가 있어?
임대차계약의 경우 수의계약 사유에 해당하려면 어떤 요건을 갖추어야 하나?
시공실적으로 입찰참가자격을 제한한 공사입찰에서 입찰참가자격이 없는 자가 추첨하여 결정된 예정가격이 효력이 없어 해당 입찰을 취소하고 새로운 입찰에 부쳐야 하는지?
이런 질문에 답하려면 단순 키워드 검색만으로는 부족하다. "비슷한 문서"를 찾는 것보다 더 중요한 것은, 답변의 근거가 될 수 있는 문장과 그 문장이 속한 문맥을 찾는 일이다.
그래서 목표가 바뀌었다.
자료를 많이 모으는 것이 아니라, 자료를 믿고 물어볼 수 있게 만드는 것.
모은 자료: 공식 근거, 사례, 해설을 한데 모으되 섞지는 않았다
가장 먼저 한 일은 자료를 모으고 성격을 나누는 일이었다.
네이버 블로그는 평소 참고했던 지방계약법 해설 글 1,028개를 개인 학술 백업용 Markdown으로 정리했다. 처음에는 권리 확인 전이라 제목, 주소, 날짜 같은 metadata만 저장했고, 사용 권한을 확인한 뒤에야 본문 전체 백업으로 확장했다. 구형 네이버 글은 본문 구조가 달라 일부 글이 짧게 추출되는 문제가 있었지만, 본문 컨테이너를 보강해 1,028개 모두 full text 상태로 맞췄다.
행정안전부 예규는 HWPX에서 Markdown으로 변환했다. 핵심 원문은 두 가지였다.
SRC-001: 지방자치단체 입찰시 낙찰자 결정기준
SRC-002: 지방자치단체 입찰 및 계약집행기준
CSR 자료는 건설계약연구원 웹 corpus로 들어왔다. 정규화된 RAG chunk는 11,948개였고, raw source 문서도 source bridge를 통해 위키와 연결했다. 여기서 중요한 기준을 세웠다. CSR 자료는 실무 사례로 유용하지만, 지방계약 직접 근거와 같은 자리에 놓지 않는다.
자료는 한데 모았지만, 같은 층위로 섞지는 않았다. 이 구분이 나중에 신뢰도 계산의 출발점이 됐다.
첫 번째 문제: 긴 문서를 그냥 넣으면 AI도 길을 잃는다
HWPX에서 변환한 예규 문서는 길고 복잡했다. 특히 표가 한 줄로 붙어 있거나, 조문과 설명이 길게 이어지는 부분은 사람이 읽기도 어렵고 AI가 검색하기에도 좋지 않았다.
그래서 문서를 의미 단위로 쪼갰다. 이것이 chunking이다.
처음에는 "문서를 적당한 길이로 자르면 되겠지"라고 생각하기 쉽다. 하지만 법령과 예규는 그렇게 자르면 안 된다. 어느 장, 어느 절, 어느 제목 아래 있는 내용인지가 중요하다. 같은 "제한"이라는 단어라도 "제한경쟁입찰"과 "입찰참가자격 제한"은 전혀 다른 쟁점이다.
그래서 chunk에는 본문만 넣지 않았다.
원문 Source ID
문서 제목
heading path
원문 줄 범위
관련 주제
source path
이런 정보를 함께 넣었다.
그 결과 SRC-001과 SRC-002는 heading 단위의 source chunk 1,277개로 나뉘었다. SRC-001은 580개, SRC-002는 697개였다. 표도 별도로 복원해 source table 753개를 만들었다. 이 중 병합 셀이 있는 표가 406개였다.
이 작업의 의미는 단순히 파일을 많이 만든 것이 아니다. 사용자가 질문했을 때, AI가 "예규 전체"가 아니라 "그 질문과 연결되는 작은 의미 단위"를 집어낼 수 있게 됐다는 뜻이다.
두 번째 문제: embedding은 답변이 아니라 길찾기다
chunking을 한 뒤에는 embedding을 했다. embedding은 문장을 숫자로 바꾸는 작업이다. 숫자로 바뀐 문장들은 서로 얼마나 비슷한지 계산할 수 있다.
여기서 중요한 깨달음이 있었다. embedding은 답변을 만드는 기술이 아니다. 길찾기 기술에 가깝다.
사용자가 "임대차계약 보증금도 수의계약 금액에 넣어야 하나?"라고 물으면, embedding은 그 질문과 비슷한 문서 조각을 찾아준다. 하지만 그 문서 조각이 공식 예규인지, 블로그 해설인지, CSR 과거 사례인지는 별도로 판단해야 한다.
그래서 이 시스템은 세 층으로 나눴다.
1. 찾기: embedding과 vector search로 관련 문서 후보를 찾는다.
2. 확인하기: 원문, source path, heading, 발췌문을 본다.
3. 답하기: 확인된 근거와 해석을 구분해 답변한다.
이 구분 덕분에 Ollama나 다른 답변 생성 모델이 필수인지도 분명해졌다. 검색과 원문 확인은 Ollama 없이도 가능하다. 답변을 자연어로 정리할 때만 선택적으로 쓸 수 있다.
세 번째 문제: AI 답변이 아니라 원문을 같이 봐야 한다
시범 질의를 해보자 바로 문제가 드러났다.
그러면 해당 문서의 원문도 같이 출력해줘야하지 않아?
맞는 말이었다. 법령과 계약 실무에서는 답변보다 원문이 먼저다. "그럴듯한 설명"보다 "어느 문서 어느 부분에서 나온 말인가"가 더 중요하다.
그래서 답변 방식이 바뀌었다.
이제 지방계약 관련 질문에는 답변 말미에 근거 방식을 붙인다. 여기에는 어떤 검색 방식을 썼는지, 어떤 문서를 근거로 삼았는지, 사용자가 같은 근거를 어떻게 다시 확인할 수 있는지를 적는다.
예를 들어 답변은 이렇게 끝나야 한다.
근거 방식
- 방식: LLM Wiki + OpenViking-style hybrid RAG
- 검색 모드: export 기반 --no-live-ov
- 주요 근거: SRC-002 source chunk, 관련 concept 문서
- 확인 방법: 같은 질문으로 context 검색 재현 가능
이 원칙 하나가 답변의 성격을 바꿨다. 이제 AI가 말한 결론만 보는 것이 아니라, 그 결론이 어떤 자료를 보고 나온 것인지 확인할 수 있게 됐다.
네 번째 문제: 공식 근거와 참고 사례를 분리해야 했다
자료가 많아지면 좋은 점도 있지만, 위험도 커진다. CSR 유권해석이나 블로그 글이 검색 1순위로 올라오면, AI가 그것을 공식 근거처럼 사용할 수 있다.
실제로 평가 과정에서 이런 일이 있었다. 제한경쟁입찰이나 복수예비가격 같은 일반 법리 질문에서 MongoDB RAG가 sources/web 사례를 1순위로 올리는 경우가 있었다. 검색 점수만 보면 맞아 보이지만, 답변 생성용 근거로는 위험할 수 있다.
그래서 출처 등급을 나눴다.
출처
역할
sources/docs
공식 원문
sources/source-chunks
공식 원문을 의미 단위로 쪼갠 직접 근거
sources/source-tables
공식 원문 표를 복원한 직접 근거
wiki/concepts
공식 근거를 바탕으로 정리한 위키 개념
sources/web
CSR, 웹 문서, 참고 사례
네이버 블로그
이해를 돕는 해설과 실무 맥락
이 표는 단순 분류가 아니다. 답변의 신뢰도와 위키 편입 여부를 결정하는 기준이다.
다섯 번째 문제: 질문과 답변도 쌓이지만, 아무 답변이나 쌓으면 안 된다
이 시스템의 중요한 특징은 질문과 답변도 다음 검색의 재료가 된다는 점이다.
예를 들어 "재입찰과 재공고입찰의 차이"를 묻고, 공식 근거를 확인해 답변했다면, 그 답변은 다음에도 재사용할 가치가 있다. 그래서 concept 문서로 저장한다.
실제로 이런 문서들이 만들어졌다.
임대차계약 수의계약 요건
보증금 환산과 연액·총액 기준
협상에 의한 계약 참여기술자 변경 조건
부정당업자 제재처분
제한경쟁입찰 제한사유
입찰무효자 복수예비가격 추첨 효력
용지보상 지연 공사중지 계약해지 처리
하지만 여기에도 함정이 있다. 신뢰도가 낮은 답변까지 위키에 넣으면, 다음 검색에서 그 낮은 신뢰도의 답변이 다시 근거처럼 회수된다. 그러면 위키가 똑똑해지는 것이 아니라 자기 말을 반복하는 구조가 된다.
그래서 근거 신뢰도와 저장 게이트를 만들었다.
근거 신뢰도
위키 편입 처리
높음
concept 또는 case로 편입 가능
중상
직접 공식 근거가 확인된 범위에서 편입 가능
보통
authoritative concept 금지, draft 또는 확인 필요 후보
낮음
위키 지식층 편입 금지
매우 낮음
저장하지 않거나 근거 부족 항목으로만 기록
이 기준은 사용자를 위한 안전장치다. "답변을 많이 저장하는 위키"보다 "믿을 수 있는 답변만 승격하는 위키"가 더 중요하기 때문이다.
여섯 번째 문제: Obsidian 그래프가 고립 문서로 가득했다
검색만 잘 되면 될까? 꼭 그렇지는 않았다.
Obsidian Graph View를 보니 문서들이 대부분 고립되어 있었다. 사람 입장에서 보면 지식이 연결되어 있지 않은 것이다. 하지만 원문을 함부로 고치면 안 된다. 법령, 유권해석, 블로그 원문은 보존되어야 한다.
그래서 controlled wikilink 방식을 썼다.
원문 내용을 바꾸지 않고, 자주 등장하는 키워드나 한글 tag만 제한적으로 [[ ]]로 연결했다. source 문서에는 무리하게 본문을 고치지 않고, 필요한 경우 연결 키워드 섹션이나 source bridge를 사용했다.
이 방식의 장점은 두 가지였다.
첫째, 사람은 Obsidian에서 문서 간 연결을 볼 수 있다.
둘째, AI는 embedding할 때 [[수의계약]] 같은 표현을 일반 텍스트처럼 정규화해 검색 noise를 줄일 수 있다.
그래프를 예쁘게 만들기 위한 작업이 아니라, 사람이 탐색하는 연결성과 AI가 검색하는 의미 단서를 함께 맞추는 작업이었다.
일곱 번째 문제: OpenViking을 붙이면 정말 좋아질까?
어느 정도 검색이 안정되자 OpenViking 이야기가 나왔다. OpenViking은 context를 파일 시스템처럼 다루고, L0/L1/L2 계층으로 필요한 만큼만 불러오는 방식이다. LLM Wiki가 커질수록 매력적인 구조였다.
하지만 바로 갈아타지는 않았다. 먼저 질문했다.
현재 LLM Wiki 안에 OpenViking식 L0/L1 계층을 먼저 구현하는 게 효율적이지 않아?
이 판단이 좋았다. 새 도구를 붙이기 전에 현재 위키 안에 L0/L1 계층을 먼저 만들었다.
L0: 짧은 요약, 빠른 후보 탐색용
L1: 문서 범위를 파악하는 개요
L2: 실제 원문 또는 chunk
그 다음 OpenViking runtime도 실험했다. 단, OpenAI API key 없이 운영한다는 조건이 있었다. 그래서 no-API embedding profile을 만들고 테스트했다.
초기 OpenViking no-API 8B pilot은 hit@5가 0.6250이었다. 반면 MongoDB RAG는 같은 평가셋에서 hit@5 1.0000이었다. 즉, OpenViking runtime을 바로 production으로 쓰기에는 부족했다.
여기서 포기하지 않고 방향을 바꿨다. `OpenViking을 단독 검색 엔진으로 쓰기보다, OpenViking식 L0/L1 export, exact keyword, 문서 타입별 우선순위, 공식 근거 boost를 결합한 hybrid wrapper를 만들었다.
그 결과 27개 지방계약 평가셋에서 OpenViking hybrid는 hit@1, hit@3, hit@5, MRR 모두 1.0000을 기록했다.
이 숫자보다 중요한 것은 top source였다. 단순히 맞는 문서가 5위 안에 있는 것이 아니라, 공식 source chunk나 정리된 concept가 상위에 오도록 조정했다.
실제 질의로 신뢰도를 높인 과정
이 시스템은 이론으로만 검증하지 않았다. 실제 질문을 계속 던졌다.
예를 들어 "용역계약에서 수의계약이 허용되는 경우를 모두 찾아서 열거하시오"라는 질문에서는 처음에는 넓은 수의계약 문서와 사례가 섞여 나올 수 있었다. 이후 용역계약 수의계약 허용 사유 concept를 만들고, 관련 SRC-002 source chunk를 상위 근거로 회수하도록 보강했다.
"제한경쟁입찰에서 제한사유는 무엇인가"라는 질문은 "제한"이라는 단어 때문에 입찰참가자격 제한이나 web 사례로 흐를 수 있었다. 그래서 제한경쟁입찰 의도 감지와 source chunk 우선순위를 추가했다.
"입찰참가자격이 없는 자가 복수예비가격을 추첨한 경우 예정가격이 무효인가"라는 질문은 LC-027 평가셋으로 추가했다. 이 질문은 단순 키워드 검색으로는 CSR 사례가 상위에 올 수 있었지만, OpenViking hybrid에서는 입찰무효자 복수예비가격 추첨 효력 concept와 SRC-001, SRC-002 source chunk가 상위에 오도록 개선했다.
마지막으로 "종합쓰레기장 민원 반대와 용지보상 지연으로 공사중지 상태인 경우 계약해지를 어떻게 처리해야 하는가"라는 질문에서는 새 concept를 만들고, 공식 source chunk와 함께 검증했다. 이 답변에는 근거 신뢰도 98/100, 높음이 붙었다. 다만 그 점수는 정답 확률이 아니라 근거 품질 점수라고 명시했다.
이 과정이 핵심이다. 질문을 던질 때마다 위키는 더 똑똑해졌지만, 아무 답변이나 위키에 넣지는 않았다. 공식 근거, 참고 사례, 해석, 신뢰도, 저장 여부를 계속 분리했다.
숫자로 본 변화
항목
결과
네이버 블로그 Markdown 백업
1,028개
CSR 정규화 RAG chunk
11,948개
SRC-001/SRC-002 source chunk
1,277개
SRC-001/SRC-002 source table
753개
L0/L1 context record
8,200개
OpenViking-compatible record
4,152개
지방계약 retrieval 평가셋
27문항
OpenViking hybrid hit@1
1.0000
OpenViking hybrid hit@5
1.0000
OpenViking hybrid MRR
1.0000
qmd hit@1
0.4444
여기서 qmd 수치가 낮다고 해서 qmd가 나쁘다는 뜻은 아니다. qmd는 Markdown 문서 탐색과 관리에 유용하다. 다만 지방계약 답변용 주 검색 backend로 쓰기에는 OpenViking hybrid나 MongoDB RAG가 더 적합하다는 뜻이다.
Before와 After
항목
Before
After
자료 상태
법령, 예규, CSR, 블로그가 흩어져 있음
Source ID와 역할이 붙은 LLM Wiki로 정리
검색 방식
파일명, 키워드, 기억에 의존
chunk, embedding, L0/L1, hybrid retrieval 사용
답변 확인
답변이 맞는지 원문을 다시 찾아야 함
답변 말미에 근거 방식과 주요 근거 표시
출처 구분
공식 근거와 참고 사례가 섞일 수 있음
공식 원문, concept, CSR, 블로그를 층위별로 분리
신뢰도
사용자가 감으로 판단
근거 신뢰도 0~100점과 한계 표시
저장 원칙
유용해 보이면 저장
낮은 신뢰도 답변은 위키 지식층 편입 금지
OpenViking
아이디어 단계
평가셋 기반 hybrid 검색으로 검증
운영 방식
그때그때 실행
HOWTO, schema, workflow, eval report로 반복 가능
이 과정에서 배운 것
첫째, RAG에서 중요한 것은 "AI가 답을 잘한다"가 아니라 "AI가 무엇을 보고 답했는지 확인할 수 있다"는 점이다.
둘째, 법령 분야에서는 자료의 출처 등급이 검색 점수보다 중요하다. 검색 점수가 높아도 CSR 사례는 참고 사례이고, 공식 예규 source chunk는 직접 근거다.
셋째, 블로그 글도 가치가 있다. 다만 공식 근거로 쓰는 것이 아니라, 해설과 맥락을 넓히는 보조 자료로 써야 한다.
넷째, 새 도구는 실제 질문으로 검증해야 한다. OpenViking은 구조적으로 매력적이었지만, no-API runtime 단독 검색은 처음에는 충분하지 않았다. 평가셋이 있었기 때문에 바로 갈아타지 않고 hybrid 방식으로 개선할 수 있었다.
다섯째, 낮은 신뢰도 답변은 저장하지 않는 것도 능력이다. 지식베이스는 많이 쌓는 것보다 잘못된 근거가 다시 검색되지 않게 막는 것이 더 중요하다.
다른 사람이 따라 한다면 이렇게 시작하면 좋다
처음부터 거대한 RAG 시스템을 만들 필요는 없다.
먼저 자료를 출처별로 나눈다. 공식 원문, 참고 사례, 해설 글을 구분한다.
긴 문서는 heading 단위로 쪼개고, 원문 위치를 metadata로 남긴다.
검색 결과에는 답변보다 원문 발췌를 먼저 붙인다.
실제 업무 질문 20~30개로 평가셋을 만든다.
검색 결과가 맞는지만 보지 말고, 1순위 문서가 공식 근거인지 확인한다.
답변이 좋더라도 신뢰도가 낮으면 위키 지식층에 넣지 않는다.
사용자가 반복해서 묻는 질문만 concept나 case로 승격한다.
이 순서로 가면 AI를 도입하더라도 출처 없는 답변에 끌려가지 않는다.
재사용 가능한 질문 템플릿
원문 근거 확인 요청
다음 질문에 답하되, 답변보다 먼저 관련 원문 근거를 찾아줘. 공식 원문, 정리된 위키 문서, 참고 사례를 구분하고, 답변 말미에 근거 방식과 근거 신뢰도를 표시해줘.
질문: [여기에 질문 입력]
낮은 신뢰도 저장 방지 요청
이 답변이 다음에도 재사용할 만한 지식인지 판단해줘. 근거 신뢰도가 보통 이하라면 concept로 저장하지 말고, 확인 필요 항목이나 후속 조사 과제로만 남겨줘.
법령 자료 RAG 구축 요청
이 폴더의 법령, 행정규칙, 유권해석, 블로그 해설 자료를 출처 등급별로 나누고, 긴 문서는 heading 단위로 chunking해줘. 검색 결과에는 source path, heading, 원문 발췌, 신뢰도 기준이 함께 나오도록 설계해줘.
마무리
이 프로젝트는 "AI에게 법령을 물어보자"에서 시작했지만, 실제로는 "AI가 법령을 어떻게 믿고 찾게 할 것인가"의 문제였다.
법령과 행정규칙, 유권해석, 블로그 해설은 모두 유용하다. 하지만 같은 높이로 섞이면 위험하다. 그래서 자료를 쪼개고, 출처를 붙이고, embedding하고, 검색 결과를 평가하고, 답변마다 신뢰도를 붙였다.
결국 만들어진 것은 멋진 챗봇이 아니라, 질문할수록 더 정리되고, 근거가 약하면 스스로 멈추는 지방계약 LLM Wiki다.
나에게 가장 큰 변화는 이것이었다.
이제 AI에게 묻는다는 말은 "대충 설명해줘"가 아니다.
"내가 가진 자료 중에서, 믿을 수 있는 근거를 먼저 찾고, 그 근거의 한계를 밝힌 다음, 실무적으로 답해줘"라는 뜻이 됐다.
지방계약 자료를 LLM Wiki와 RAG 지식베이스로 만든 기록
한 줄 요약
네이버 블로그 자료, HWPX 예규, Markdown 문서를 AI 코딩 에이전트와 함께 정리해서 개인 학술용 LLM Wiki와 MongoDB 기반 RAG 검색 파이프라인으로 바꿨습니다.
이런 분들께 도움돼요
법령, 예규, 판례, 매뉴얼처럼 긴 문서를 계속 찾아보는 분
Obsidian이나 Markdown으로 개인 지식베이스를 운영하는 분
RAG/vector DB를 해보고 싶은데 “문서를 어떻게 넣어야 하지?”에서 막히는 분
AI에게 단순 답변이 아니라 출처와 근거가 있는 질의를 시키고 싶은 분
시작점: 자료는 많은데, 매번 다시 찾고 있었다
저는 지방공기업에서 행정 업무를 하면서, 항상 지방자치단체를 당사자로 하는 계약에 관한 법률(이하 '지방계약법'이라 합니다)의 적용 문제로 고민했습니다.
지방계약법 관련 자료는 많지도 않은데다 법령, 행정규칙, 그리고 사례들이 흩어져 있었습니다. 법령 조문도 많지만, 문제는 '지방자치단체 입찰시 낙찰자 결정기준'과 '지방자치단체 입찰 및 계약집행기준'이 매우 많은 분량의 pdf/hwpx 문서로 되어 있어 찾기가 쉽지 않았습니다. 다만, 지방계약법에 대해 매우 잘 정리된 blog 글과 조달청, 국가계약법에 대한 유권해석을 수집해 놓은 사이트가 있어서 이를 참고할 수 있었습니다. 하지만 문제는 이 자료들이 각기 다른 곳에 흩어져 있다는 것이었습니다.
공개 블로그에는 해설 글이 많았고, 한글 문서에는 행정 기준 전문이 있었고, Obsidian에는 정리 중인 LLM Wiki가 있었습니다. 문제는 자료가 많을수록 “정확한 근거가 어디였지?”를 다시 찾는 시간이 늘어난다는 점이었습니다.
처음 목표는 단순했습니다.
사례사이트의 유권해석과 네이버 블로그 글을 Markdown으로 백업한다.
HWPX로 된 지방계약 기준 문서를 Markdown으로 바꾼다.
그 Markdown을 chunk로 나눠 RAG/vector DB에 넣는다.
LLM Wiki에서 질의하면 출처와 heading까지 같이 나오게 만든다.
여기서 중요한 전제는, 원문을 공개 재배포하려는 목적이 아니라 개인 학술 백업과 검색용 지식베이스를 만드는 것이었습니다. 그래서 초반에는 권리 확인 전까지 본문 전체를 복제하지 않고 metadata만 저장했고, 사용 권한을 확인한 뒤에야 full text 백업으로 확장했습니다.
만든 것
최종적으로 만든 것은 “지방계약 자료를 위한 로컬 AI 지식베이스 파이프라인”입니다.
구성은 이렇게 잡았습니다.
자료 수집
-> Markdown 변환
-> RAG chunk 생성
-> LLM Wiki source 등록
-> lint/query 자동화
-> MongoDB Local Atlas + Vector Search ingest
-> Ollama 기반 답변 생성
실제 산출물은 다음과 같습니다.
네이버 블로그 Markdown 백업: 1,028개
HWPX -> Markdown 변환 문서: 2개
지방계약 RAG chunk: 1,304개
LLM Wiki Markdown 문서: 1,958개 기준 dry-run
MongoDB RAG 전체 chunk 예정: 약 14,610개
"자료, schema, 자동화 스크립트, report를 분리한 LLM Wiki 구조"
사용한 도구와 역할
Codex: 파일 조사, 스크립트 작성, 오류 수정, 테스트, devlog 정리
insane-search: 네이버처럼 일반 fetch가 까다로운 사이트 접근 가능성 확인
hwp2md: HWPX 행정 문서를 Markdown으로 변환
Python: 블로그 백업, chunking, lint, query, MongoDB ingest 스크립트 작성
LLM Wiki: source, schema, workflow, glossary, question 문서 관리
MongoDB Local Atlas: RAG chunk 저장과 Vector Search
voyageai/voyage-4-nano: 로컬 embedding 모델
Ollama gemma4:e2b: 검색 결과 기반 답변 생성
AI에게 한 번에 “RAG 만들어줘”라고 맡긴 것이 아니라, 각 단계마다 역할을 나눴습니다. 자료 수집은 자료 수집대로, 변환은 변환대로, schema는 schema대로, 검증은 검증대로 분리했습니다. 이게 나중에 오류를 찾는 데 꽤 중요했습니다.
진행 과정
1. 네이버 블로그 글을 Markdown으로 백업
처음에는 네이버 블로그 전체 글 목록을 수집했습니다.
블로그의 RSS와 글 목록 API를 확인했고, 전체 글 수가 1,028개라는 것을 확인했습니다. 권리 확인 전에는 본문 전체를 저장하지 않고 제목, URL, 날짜, 글번호 같은 metadata만 저장했습니다.
그 다음 사용자가 개인 학술 백업 권한을 확인한 뒤, 각 글의 모바일 HTML 본문을 읽어 Markdown 파일로 갱신했습니다.
중간에 구형 네이버 글에서 본문이 너무 짧게 추출되는 문제가 있었습니다. 최신 글은 se-main-container를 쓰고, 구형 글은 __se_component_area를 쓰고 있었기 때문입니다. 본문 컨테이너 인식 규칙을 추가한 뒤 전체 1,028개 글이 full text 상태로 저장됐습니다.
검증 결과:
posts=1028
full_text=1028
missing=0
"1,028개 블로그 글을 개인 백업용 Markdown으로 정리"
2. HWPX 행정 문서를 Markdown으로 변환
다음은 HWPX 문서였습니다.
외부에 있던 hwp2md 프로그램을 먼저 읽었습니다. 이 도구는 HWP/HWPX를 Markdown 초안으로 바꾸는 로컬 변환기였습니다. 테스트도 실행했습니다.
hwp2md 0.1.0
Ran 23 tests in 0.564s
OK
그리고 현재 작업 폴더에서 바로 실행할 수 있도록 convert_hwp_here.bat를 만들었습니다. 더블클릭하면 현재 폴더의 .hwp, .hwpx 파일을 converted_hwp_md로 변환하는 방식입니다.
변환한 문서는 두 개였습니다.
지방자치단체 입찰시 낙찰자 결정기준
지방자치단체 입찰 및 계약집행기준
변환 결과에는 .md, .report.json, .assets가 함께 생겼습니다. 리포트에는 layout 손실이나 이미지 위치 추정 같은 경고가 남았지만, 본문 Markdown 변환은 성공했습니다.
3. 법령 문서에 맞는 chunking 스크립트 작성
그 다음 단계가 핵심이었습니다. Markdown을 그냥 일정 글자 수로 자르면, 법령 문서에서는 검색 품질이 떨어집니다.
그래서 chunking 스크립트는 다음 metadata를 보존하도록 만들었습니다.
title
heading_path
heading
source_file
source_document
legal_refs
text
특히 legal_refs에는 이런 패턴을 잡도록 했습니다.
제n장
제n절
제n조
별표
별지
부칙
시행령 제n조
시행규칙 제n조
최종 chunk 통계는 이렇습니다.
input_md_files=2
chunks=1304
unique_ids=1304
min_chars=125
max_chars=2200
mean_chars=667.5
검색 샘플도 확인했습니다.
query: 새로 공고
hit heading: 3. 새로 공고와 정정공고
legal_refs: 시행령제33조
"법령 검색을 위해 heading_path와 legal_refs를 metadata로 보존"
4. LLM Wiki에 source와 schema를 넣었다
처음에는 chunk만 만들면 끝이라고 생각하기 쉽습니다. 그런데 실제로 운영하려면 “이 chunk가 어디서 왔는지”, “어떤 source에 속하는지”, “query에서 어떤 결과를 우선해야 하는지”를 계속 확인해야 합니다.
그래서 LLM Wiki 안에 source와 schema를 정리했습니다.
등록한 주요 source:
SRC-001: 지방자치단체 입찰시 낙찰자 결정기준
SRC-002: 지방자치단체 입찰 및 계약집행기준
SRC-003: 지방계약 HWPX 변환 문서의 RAG chunk 산출물
그리고 RAG chunk schema, ingest checklist, lint checklist, query workflow를 추가했습니다.
schema/rag-chunk-schema.md
schema/ingest-checklist.md
schema/lint-checklist.md
wiki/workflows/query-and-update.md
이 단계에서 깨달은 점은, RAG는 “embedding을 넣는 일”보다 “나중에 믿고 운영할 수 있게 source와 검증 규칙을 남기는 일”이 더 중요하다는 것이었습니다.
5. lint와 query를 자동화했다
LLM Wiki가 커지면 사람이 매번 확인하기 어렵습니다. 그래서 lint와 query 도구를 만들었습니다.
lint는 source index, source summary, inbox 잔여물, 내부 링크, RAG JSONL/manifest 정합성을 검사합니다.
최종 lint 결과:
LLM Wiki lint: PASS
errors=0 warnings=0 links=80 sources=6 rag_sources=2
query 도구는 Markdown 문서와 RAG JSONL을 함께 검색합니다.
검증한 질의는 이런 것들이었습니다.
물가변동 계약금액 조정
수의계약 배제사유
공동수급체 구성 제한
새로 공고 / 정정공고
부정당업자 제재사유
예를 들어 “부정당업자 제재사유”를 물어봤을 때는 LLM Wiki의 SRC-002 chunk와 공식 법령 근거를 함께 확인해 답변했습니다. 답변에는 지방계약법 제31조, 지방계약법 시행령 제92조, 그리고 계약집행기준의 관련 chunk가 같이 쓰였습니다.
6. MongoDB RAG 파이프라인으로 확장
마지막으로 handoff 문서를 읽고, 기존 실습용 RAG 구조를 LLM Wiki vault에 맞게 적용했습니다.
목표는 이랬습니다.
Markdown 문서 읽기
-> Obsidian metadata 추출
-> heading-aware chunking
-> voyageai/voyage-4-nano embedding
-> MongoDB Local Atlas 저장
-> Vector Search index 생성
-> query와 Ollama answer 생성
추가한 파일:
llm_wiki_rag.bat
scripts/index_llm_wiki.py
scripts/README.md
scripts/requirements-llm-wiki-rag.txt
scripts/llm_wiki_rag.env.example
RAG 스크립트는 네 가지 명령을 지원하게 했습니다.
check
dry-run
ingest
query
환경 확인 결과:
MongoDB Local Atlas: running
Ollama: gemma4:e2b, gemma4:e4b
Embedding model: voyageai/voyage-4-nano
Embedding dimensions: 2048
dry-run 결과는 꽤 컸습니다.
Markdown docs=1958
chunks=약 14610
작은 smoke ingest에서는 MongoDB 저장, Vector Search index, query, Ollama answer까지 확인했습니다.
막힌 점: YAML 날짜 때문에 MongoDB 저장이 실패했다
전체 ingest를 실행했더니 첫 저장 전에 멈췄습니다.
오류는 이랬습니다.
bson.errors.InvalidDocument:
cannot encode object: datetime.date(2026, 6, 5)
원인은 단순했지만 중요했습니다. Markdown frontmatter의 updated: 2026-06-05 값이 PyYAML에서 datetime.date로 파싱되었고, MongoDB BSON encoder는 이 타입을 직접 저장하지 못했습니다.
그래서 mongo_safe() 함수를 추가했습니다.
처리한 타입:
datetime.date -> ISO date string
Path -> string
dict/list/tuple -> recursive conversion
수정 후 검증:
Python py_compile: PASS
BSON smoke: docs=20 chunks=1412 bson_ok=1412
small ingest: docs=9 chunks=47 저장 성공
이 실패가 좋았던 점은, RAG 파이프라인에서 “본문 chunk만 잘 만들면 된다”가 아니라 metadata도 DB 저장 가능한 형태로 정규화해야 한다는 것을 명확히 보여줬다는 점입니다.
실제 실행 상태
전체 ingest는 CPU embedding 속도 때문에 오래 걸립니다. 그래서 명령창을 붙잡아두지 않고 백그라운드로 실행했습니다.
실행 명령:
llm_wiki_rag.bat ingest --reset --create-index --wait-index --progress
작성 시점 상태:
wiki_chunks 저장 수: 192 / 14610
process alive: true
즉, 아직 완료된 상태는 아닙니다. 완료 전 query는 부분 데이터 기준으로만 동작합니다. 전체 ingest가 끝나면 chunk count, vector_index READY, 실제 query 결과를 다시 확인해야 합니다.
이 부분은 오히려 현실적인 운영 포인트였습니다. RAG는 “한 번에 멋지게 완성”보다, 긴 ingest와 중간 실패를 견디는 운영 방식이 필요합니다.
Before vs After
Before:
블로그 글, HWPX 문서, Obsidian 정리 문서가 따로 있었다.
법령 근거를 찾으려면 원문을 다시 열고 검색해야 했다.
AI에게 물어도 출처가 없는 답변은 바로 믿기 어려웠다.
RAG chunk, source metadata, 검증 규칙이 분리되어 있지 않았다.
After:
블로그 글 1,028개가 Markdown으로 정리됐다.
HWPX 예규 2건이 Markdown과 report로 변환됐다.
지방계약 문서 2건에서 1,304개 RAG chunk가 생성됐다.
LLM Wiki에 source, schema, workflow, lint, query가 연결됐다.
MongoDB Local Atlas 기반 vector search ingest 파이프라인이 만들어졌다.
질의 결과에서 source ID, heading, legal_refs를 함께 확인할 수 있게 됐다.
배운 점
첫째, RAG의 핵심은 embedding이 아니라 source 관리였습니다.
어떤 문서에서 왔는지, 어떤 heading 아래 있는지, 어떤 법령 조문과 연결되는지가 metadata로 남아 있어야 나중에 답변을 믿을 수 있었습니다.
둘째, 문서 변환은 “성공/실패”가 아니라 “어떤 손실이 있었는지”까지 봐야 했습니다.
HWPX를 Markdown으로 바꿀 때 layout 손실이나 이미지 위치 추정 경고가 있었지만, report가 있었기 때문에 변환 품질을 판단할 수 있었습니다.
셋째, 자동화에는 반드시 lint가 필요했습니다.
source가 늘어나면 사람이 링크, ID, manifest, chunk 수를 계속 맞추기 어렵습니다. lint가 있으니 수정 후 바로 PASS 여부를 확인할 수 있었습니다.
넷째, AI 코딩 에이전트는 “전체를 맡기는 도구”라기보다 “검증 가능한 작은 단계를 계속 밀어주는 도구”에 가까웠습니다.
이번 작업은 자료 수집, 변환, chunking, schema 정리, lint, query, MongoDB ingest를 나눠서 진행했기 때문에 중간에 문제가 생겨도 어디서 깨졌는지 찾을 수 있었습니다.
다음에 해볼 것
전체 MongoDB ingest 완료 후 vector_index READY 확인
실제 질의 세트로 검색 품질 평가
ingest 중단 시 재시작 비용을 줄이는 --resume 옵션 추가
경로별 부분 ingest 옵션 추가
키워드 검색과 vector search를 섞는 hybrid search 구성
질의 결과를 LLM Wiki 문서 업데이트 workflow와 더 강하게 연결
따라 해보고 싶은 분들을 위한 최소 시작점
처음부터 MongoDB와 vector search까지 가지 않아도 됩니다. 가장 작은 시작점은 이 정도면 충분합니다.
1. 자주 보는 문서 1~2개를 Markdown으로 변환한다.
2. heading_path와 source_file을 metadata로 남긴다.
3. chunk JSONL을 만든다.
4. 검색 샘플 3개를 정해 결과가 맞는지 확인한다.
5. 그 다음에 vector DB를 붙인다.
이 순서가 좋은 이유는, embedding 전에 문서 구조와 출처가 먼저 정리되기 때문입니다. RAG가 틀렸을 때도 “모델이 틀렸나?”가 아니라 “chunk가 잘렸나?”, “metadata가 빠졌나?”, “source가 잘못 연결됐나?”를 확인할 수 있습니다.
친구들의 단톡방에서 어느 날 노원에 학원 이야기가 나왔습니다.
특히 중학생 자녀를 둔 학부모 입장에서는 이런 고민이 많았습니다.
중1은 어떤 과목을 먼저 챙겨야 할까?
중2부터 내신이 중요하다는데 어떤 학원이 좋을까?
중3은 고등학교 준비를 어떻게 시작해야 할까?
노원구 학원이 너무 많은데, 유명하고 선호도 높은 곳만 추릴 수 없을까?
노원구, 특히 중계동 은행사거리 주변은 학원이 워낙 많다 보니 정보를 일일이 찾고 비교하는 데 시간이 많이 걸렸습니다.
그래서 이번에는 ChatGPT와 Claude를 활용해서 중1~중3 학년별 필요 과목과 학원 정보를 정리해보기로 했습니다.
진행 방법
1. ChatGPT로 학년별 집중 과목 분석하기
먼저 ChatGPT에게 중학교 1학년부터 3학년까지
각 학년마다 어떤 과목에 집중해야 하는지 분석을 요청했습니다.
정리 방향은 단순했습니다.
중1: 시험 부담이 적은 시기 → 수학 선행, 영어 기초, 코딩·AI
중2: 본격적인 내신 시작 → 수학, 영어, 과학
중3: 고등 입시 체제로 전환 → 국어 비문학, 고등 수학 선행, 통합과학
특히 AI 디지털교과서는 2025년부터 초3·4, 중1, 고1을 대상으로 영어·수학·정보 교과에서 활용이 시작된다고 안내되어 있어, 중1 단계에서 코딩·AI 역량도 함께 고려해볼 만한 요소로 봤습니다.
2. Claude에 학년별 학원 검색 요청하기
ChatGPT에서 정리한 내용을 Claude에 가져가서,
서울시 노원구 중심으로 학부모가 선호할 만한 학원을 찾아 정리해달라고 요청했습니다.
사용한 요청 내용은 아래와 같습니다.
학년,중심 학원 (우선순위),이유 및 특징 중1,수학 / 영어 / 코딩·AI,
시험 부담이 적은 시기라 수학 선행에 집중합니다.
최근에는 2025년부터 도입된 AI 디지털 교과서 영향으로
코딩 및 AI 활용 능력 학원 수요가 높습니다. 중2,수학 / 영어 / 과학,
본격적인 내신 시험이 시작되는 시기입니다.
수학은 난도가 급격히 높아져 '수포자' 방지용 과외나 학원이 필수이며,
과학 탐구 학원을 시작하는 비중이 늘어납니다. 중3,국어(비문학) / 수학 / 통합과학,
고등 입시 체제로 전환됩니다.
특히 수능형 국어(비문학)와 고등 수학 선행,
그리고 고등학교 '통합과학' 대비를 위해
입시 전문 종합학원이나 단과 학원 비중이 압도적입니다. 위의 내용을 가지고 중학교 1학년부터 3년까지
학부모가 가장 선호하는 학원을 서울시 노원구 중심으로 찾아서 정리해줘.
3. HTML 페이지로 보기 쉽게 정리하기
검색된 내용을 단순 텍스트로만 두지 않고,
웹에서 한눈에 볼 수 있도록 HTML 페이지 형태로 정리했습니다.
결과물은 “노원구 중학생 학원 가이드 2026” 형태로 만들었고,
중1·중2·중3 학년별로 필요한 과목과 학원을 카드 형태로 배치했습니다.
첨부한 HTML에는 다음 요소들이 들어가 있습니다.
중1, 중2, 중3 학년별 섹션
수학, 영어, 과학, 국어, 코딩·AI 과목별 분류
학원명, 특징, 위치, 후기·추천율 등 요약 정보
과목별 필터 기능
학원명 검색 기능
학부모 정보 공유 목적의 안내 문구
결과와 배운 점
이번 작업을 통해 가장 좋았던 점은 학원이 한눈에 정리되었다는 것입니다.
노원구에는 학원이 너무 많아서 처음에는 어디부터 봐야 할지 막막했는데,
AI를 활용하니 다음과 같이 기준이 생겼습니다.
학년별로 우선순위 과목을 먼저 정할 수 있음
과목별로 관련 학원을 빠르게 추릴 수 있음
유명하거나 자주 언급되는 학원을 중심으로 비교할 수 있음
검색 결과를 웹페이지 형태로 바꾸면 다른 사람과 공유하기 쉬움
물론 AI가 정리해준 내용을 그대로 믿기보다는,
최종적으로는 학원에 직접 상담하고 반 편성, 수강료, 셔틀, 강사 변동 여부를 확인해야 합니다.
하지만 처음 후보군을 줄이는 용도로는 충분히 도움이 되었습니다.
실생활 활용 가능성도 확인
이번에 한 가지 더 테스트해본 것이 있습니다.
지금 살고 있는 동네에서
내 형편에 맞는 금액대로 갈 수 있는 집을 정리해달라고 요청해봤습니다.
그랬더니 여러 군데의 집을 직접 다 둘러보지 않아도,
예산에 맞는 후보지를 먼저 추려볼 수 있었습니다.
이 경험을 통해 느낀 점은 분명했습니다.
AI는 단순히 글을 써주는 도구가 아니라,
시간과 노력이 많이 들어가는 생활형 정보 탐색을 줄여주는 도구로도 충분히 활용할 수 있습니다.
학원 찾기, 집 찾기, 병원 찾기, 여행지 정리처럼
정보가 너무 많아서 선택이 어려운 상황에서 특히 유용했습니다.
도움 받은 글
교육부, 2025년 AI 디지털교과서 검정심사 및 활용 안내
교육부 카드뉴스, AI 디지털교과서는 서책형 교과서와 함께 수업 지원 도구로 활용된다는 안내
직접 제작한 노원구 중학생 학원 가이드 2026 HTML 결과물
1. 도입
inbox에 있는 정보를 wiki에 지식으로 편입하기 위해 "3단계 지식체계론"이라는 검증절차를 세우고 3개의 각각 다른 성격의 문서를 ingest해 보았다.
그렇다면 3단계 지식체계론이 없는, 일반적인 schema만 있을 때에 똑같은 문서를 LLM-Wiki에서 ingest하면 어떤 결과가 나올까?
그래서 똑같은 llm-wiki를 만들되, 3단계 지식체계론이 없는 llm-wiki에서 위 3가지 문서를 ingest해 보았다.
2. ingest 결과
LLM은 6분 29초동안 ingest 작업을 수행한 후 다음과 같은 메시지를 출력했다.
완료했습니다. inbox/docs의 3개 문서를 sources/docs로 이동했고, source-index.md에 SRC-001부터 SRC-003까지 등록했습니다. 추가로 원본 요약 3개와 개념 문서 3개를 만들고, index.md, log.md, 관련 운영 문서의 “아직 ingest 없음” 문구도 정리했습니다. 검증 결과: - inbox/docs는 비어 있음
- 신규 source/source-summary/concept 경로 모두 존재
- 세종대왕.md는 검증 필요 주장이 섞여 있어 review-needed로 표시해두었습니다.
inbox 폴더는 비었고, sources/docs에 원본 문서가 저장돼있었으며, wiki 폴더에는 concepts, source-summaries 폴더에 3개의 문서가 각각 생겼다.
2.1 concept/서시.md 및 source-summaries/SRC-001-서시.md의 내용
concept/서시.md의 메타데이터는 아래와 같다.
type: concept
status: draft
updated: 2026-05-31
summary_l0: "윤동주 「서시」의 양심과 소명 의식"
summary_l1: "이 문서는 SRC-001에 기록된 「서시」 원문을 바탕으로 작품의 핵심 정서와 해석 후보를 정리한다. 작품은 부끄럼 없는 삶을 향한 바람, 작은 흔들림에도 괴로워하는 양심, 죽어가는 존재를 사랑하려는 태도, 자신에게 주어진 길을 걷겠다는 결심을 중심으로 읽을 수 있다. 현재 문서는 원문 하나에 근거한 초안이며, 저자와 발표 맥락은 추가 출처로 보강할 수 있다."
source_refs:
- SRC-001
tags:
- poetry
- korean-literature
3단계 지식체계론이 적용되지 않았기 때문에 LLM이 자체적으로 판단해서 summary_L0과 L1을 작성했다. 주로 서시의 내용에 기초하여 summary를 했다.
이와 관련된 source-summaries/SRC-001-서시.md의 메타데이터 및 내용은 다음과 같다.
type: source-summary
status: draft
updated: 2026-05-31
summary_l0: "윤동주 시 「서시」 원문"
summary_l1: "SRC-001은 윤동주의 시 「서시」 원문을 담은 짧은 문서다. 원문은 부끄러움 없는 삶을 바라는 마음, 작은 흔들림에도 괴로워하는 양심, 죽어가는 존재에 대한 사랑, 자신에게 주어진 길을 걸어가려는 태도를 중심으로 전개된다. 현재 요약은 원문 내용의 정서와 주제 후보만 정리하며, 작품 해석은 별도 위키 문서에서 다룬다."
source_refs:
- SRC-001
tags:
- poetry
- korean-literature
SRC-001 서시 요약
원본 정보
Source ID: SRC-001
원본 위치: sources/docs/서시.md
자료 유형: document
민감자료 확인: API Key, 토큰, 비밀번호, 주민등록번호, 계좌번호, 전화번호 등 민감정보 발견 없음.
핵심 요약
원본은 윤동주의 시 「서시」 전문이다. 화자는 하늘을 우러러 부끄럼 없는 삶을 바라며, 사소한 바람에도 괴로워할 만큼 예민한 양심을 드러낸다.
시의 후반부는 별을 노래하는 마음, 죽어가는 존재에 대한 사랑, 자신에게 주어진 길을 걸어가겠다는 다짐으로 이어진다.
위키에 반영할 지식 후보
「서시」는 부끄럼 없는 삶, 양심, 사랑, 소명 의식을 핵심 정서로 다룬다.
작품 속 별과 바람은 화자의 내면과 윤리적 긴장을 드러내는 이미지로 정리할 수 있다.
원문 전체 인용보다는 핵심 주제와 해석 후보를 분리해 다루는 것이 좋다.
연결될 수 있는 문서
서시
남은 질문
작품의 저자, 발표 시기, 문학사적 맥락을 보강할 외부 출처를 추가할지 결정해야 한다.
위와 같은 내용으로 source-summaries 폴더 아래 서시 관련 내용이 작성되었다.
뭔가 LLM이 내용을 요약하고 평가를 내려서 글의 내용이 풍부해진 느낌이다.
실제로 3단계 지식체계론을 거친 지난 llm-wiki-test1에서의 source-summaries에 있는 같은 이름의 문서의 핵심 요약에는 다음의 내용만 무미건조하게 있었다.
- 한국어 시 원문으로 구성된 자료다.
- 파일명은 `서시.md`이며, 본문은 짧은 시 형태다.
- 위키에는 원문 전체를 재수록하지 않고, 문학 자료로서의 존재와 활용 원칙만 기록한다.
여기서 중요한 차이점은 3단계 지식체계론을 거쳤던 지난 위키에서는 원문을 수록하지 않는다는 것이었다. 하지만 3단계 지식체계론을 거치지 않은 이번 위키에서는 원문을 해설했고, 요약했으며, 또한 위키에 지식으로 반영할 후보를 만들었다는 점이 차이가 있었다.
이러한 차이는 앞으로 llm-wiki를 어떤 식으로 운영해야 할 것인지 중요한 숙제를 남겨주었다.
2.2 영주 부석사 무량수전의 wiki 파일의 내용
concept/영주 부석사 무량수전.md 파일의 메타데이터는 아래와 같다.
type: concept
status: draft
updated: 2026-05-31
summary_l0: "영주 부석사 무량수전의 연대와 건축미"
summary_l1: "이 문서는 SRC-003을 바탕으로 영주 부석사 무량수전의 시대, 국보 지정, 건립 연대 추정, 건축적 평가를 정리한다. 원본은 무량수전을 고려 시대 중기 건물로 추정하고 1962년 국보 제18호 지정 사실을 제시한다. 건립 시기는 직접 기록이 없어 중수 기록을 근거로 추정한다고 설명하며, 봉정사 극락전과 예산 수덕사 대웅전과의 비교도 함께 다룬다."
source_refs:
- SRC-003
tags:
- architecture
- heritage
- buddhist-temple
3단계 지식체계론을 따르지 않았기 때문에 해당 내용 중 claim으로 검증 대상이 될 사항에 대한 별도의 검증은 없고 해당 내용을 요약해서 수록했음을 알 수 있다.
이어서 source-summaries에 있는 같은 이름의 문서를 살펴본다.
핵심 요약
원본은 경상북도 영주시 부석사의 무량수전을 고려 시대 중기 건물로 추정되는 현존 고려 건축물로 설명한다. 1962년에 국보 제18호로 지정되었다고 기록한다.
건립 연대는 직접 기록이 없어 중수 기록으로 추정한다고 설명한다. 원본은 1376년 진각국사 천희의 중수 기록과 전통 건물의 수리 주기를 바탕으로 건립 시기를 더 이른 시기로 본다.
무량수전은 봉정사 극락전, 예산 수덕사 대웅전과 비교된다. 원본은 봉정사 극락전이 구조미를, 부석사 무량수전이 형태와 비례미를 잘 보여준다고 평가한다.
위키에 반영할 지식 후보
무량수전은 고려 시대 목조건축, 국보, 부석사와 연결되는 문화유산 문서로 정리할 수 있다.
건립 연대는 확정 표현보다 추정 표현을 유지해야 한다.
봉정사 극락전과 예산 수덕사 대웅전은 비교 문서나 관련 문서 후보가 된다.
건축적 평가는 원본의 평가로 표시하고, 추후 전문 출처로 보강하는 것이 좋다.
연결될 수 있는 문서
영주 부석사 무량수전
남은 질문
국보 지정 정보와 중수 기록을 검증할 공식 문화유산 출처를 추가 ingest할지 결정해야 한다.
이것을 보면, 일단 문서가 어떠하든지, 그 내용이 무엇이든지 LLM은 위키에 반영할 지식 후보를 선별하여 정리하는 것을 알 수 있다.
다만, LLM 나름대로의 평가기준에 따라 건립 연대와 같이 확실하지 않은 정보는 자체적으로 추정 표현을 유지해야 함을 밝히고 있다. 또한 건축적 평가는 원본의 평가로 표시해서 최대한 객관성을 유지하고자 함을 알 수 있다. 하지만 3단계 지식체계론에 따른 것보다는 세밀하지 못하다는 점을 알 수 있다.
2.3 세종대왕의 wiki 파일의 내용
드디어 세종대왕에 관하여 LLM이 어떻게 처리했는지 살펴볼 시간이 왔다.
먼저, concepts/세종대왕.md의 내용이다.
이 문서는 중요한 논의를 담고 있으므로 파일의 전문을 수록하고자 한다.
type: concept
status: draft
updated: 2026-05-31
summary_l0: "세종대왕 관련 원본 주장과 검토 항목"
summary_l1: "이 문서는 SRC-002에 들어 있는 세종대왕 관련 주장을 검토용 지식으로 정리한다. 원본에는 조선 제4대 왕, 한글 창제처럼 역사 정보로 확인할 수 있는 후보와 존경, 추앙, 외모 평가 같은 평가적 진술이 섞여 있다. 아이패드 관련 진술과 단종의 아버지라는 진술은 사실 문서에 단정적으로 반영하지 않고 검토 필요 항목으로 분리한다."
source_refs:
- SRC-002
tags:
- history
- joseon
- review-needed
세종대왕
한 줄 요약
SRC-002의 세종대왕 문서는 사실 후보, 평가적 진술, 검토 필요 주장이 섞여 있어 분리해서 다뤄야 한다.
핵심 내용
원본은 세종대왕을 조선의 제4대 왕이자 한글 창제와 연결되는 인물로 제시한다. 이 두 항목은 역사 지식 문서로 확장할 수 있는 후보지만, 현재 문서는 SRC-002만 근거로 삼으므로 공식 출처 보강 전에는 검증 후보로 남긴다.
원본에는 세종대왕이 존경받을 만하다는 평가와 업적이 널리 알려져야 한다는 주장도 들어 있다. 이런 문장은 사실 정보라기보다 가치 판단이나 서술 방향으로 분류한다.
외모 평가, 아이패드 관련 진술, 단종의 아버지라는 진술, 모든 한국 사람이 추앙해야 한다는 표현은 컴파일 지식으로 단정하지 않는다. 특히 시대착오적 표현이나 친족 관계 주장은 별도 검증이 필요하다.
관련 문서
SRC-002 세종대왕 요약
남은 질문
근거 출처
SRC-002: sources/docs/세종대왕.md
남은 질문
세종대왕의 생애, 한글 창제, 왕위 계보를 검증할 공식 출처를 추가해야 한다.
원본의 평가적 표현을 역사 지식 문서에 어느 수준까지 남길지 결정해야 한다.
원본에는 다음의 8개의 문장이 있었다.
1. 세종대왕은 잘 생겼다
2. 세종대왕은 존경받을만 하다.
3. 세종대왕은 조선의 제4대 왕이다.
4. 세종대왕은 한글을 창제했다.
5. 세종대왕은 아이패드를 집어던지셨다.
6. 세종대왕은 단종의 아버지이다.
7. 세종대왕의 업적은 널리 알려져야 한다.
8. 모든 한국 사람들은 세종대왕을 추앙해야 한다.
여기서 wiki/concepts 폴더의 문서에서는 3번과 4번의 항목은 역사 지식 문제이나 근거가 원본 문서밖에 없으므로 공식 출처 보강 전에는 검증 후보로 남기고, 2번과 7번 항목은 사실정보라기보다 가치 판단이나 서술 방향으로 분류하며, 나머지 항목은 컴파일 지식으로 단정하지 않고, 특히 아이패드 관련이나 단종의 아버지에 대해서는 별도 검증이 필요하다고 분류했다.
그렇다면 source-summaries 폴더의 해당 항목 내용을 살펴보자. 이 역시 전문을 수록한다.
type: source-summary
status: draft
updated: 2026-05-31
summary_l0: "세종대왕에 대한 혼합 주장 목록"
summary_l1: "SRC-002는 세종대왕에 관한 여덟 개의 짧은 주장으로 구성된 문서다. 원본에는 조선 제4대 왕, 한글 창제처럼 검증 가능한 역사 정보 후보와 존경, 추앙, 외모 평가 같은 평가적 진술이 함께 들어 있다. 또한 아이패드 관련 진술과 단종의 아버지라는 진술처럼 사실 검증이 필요한 항목도 포함되어 있어, 컴파일 문서에서는 원본 주장과 검토 필요 항목을 분리한다."
source_refs:
- SRC-002
tags:
- history
- joseon
- review-needed
SRC-002 세종대왕 요약
원본 정보
Source ID: SRC-002
원본 위치: sources/docs/세종대왕.md
자료 유형: document
민감자료 확인: API Key, 토큰, 비밀번호, 주민등록번호, 계좌번호, 전화번호 등 민감정보 발견 없음. 내용상 사실 검증이 필요한 주장이 포함되어 있음.
핵심 요약
원본은 세종대왕에 대한 단문 주장 8개를 번호 목록으로 기록한다. 조선의 제4대 왕, 한글 창제, 업적의 중요성처럼 역사 지식으로 편입할 수 있는 후보가 있다.
동시에 잘생겼다는 외모 평가, 존경과 추앙을 요구하는 규범적 진술, 아이패드 관련 시대착오적 진술, 단종의 아버지라는 검증 필요 진술이 함께 들어 있다.
위키에 반영할 지식 후보
세종대왕은 조선 제4대 왕이라는 역사 정보 후보로 분류한다.
세종대왕과 한글 창제의 연결은 별도 신뢰 출처로 보강할 가치가 있다.
평가적 진술과 사실 진술을 분리해 기록해야 한다.
명백히 시대착오적이거나 검증이 필요한 진술은 단정하지 않고 검토 필요로 남긴다.
연결될 수 있는 문서
세종대왕
남은 질문
남은 질문
세종대왕 문서를 사실 문서로 확장하려면 공식 역사 출처를 추가 ingest해야 한다.
단종의 부계 관계처럼 원본과 충돌 가능성이 큰 항목은 별도 검증이 필요하다.
이를 통해 볼 때, LLM이 스스로의 기준에 의해 사실(fact)와 평가(interpretation)을 구분하고 있음을 알 수 있으나, 어떤 근거에 의해, 어떤 과정을 거쳐서 그러한 결론에 이르렀는지를 추적하는 것은 쉽지 않다. 물론 LLM에게 물어보면 근거를 말하겠지만, 그렇게 말하는 근거 역시 LLM이 사후적으로 생성한 것인지, 아니면 ingest 당시의 LLM의 분류 및 검증 원칙에 따른 것인지는 미지의 영역으로 남을 것 같다.
3. 결론
그렇다면 3단계 지식체계론을 적용하는 것은 LLM의 분류 및 검증, 판단의 근거를 명확히 할 뿐 아니라 사후 추적이 가능하며, 발생할 수 있는 hallucination을 방지할 수 있다는 점에서도 충분히 도입할만한 가치가 있다는 생각이 든다.
특히 세종대왕에 관한 문서에서 3단계 지식체계론을 적용하지 않은 문서에서는 "평가적 진술과 사실 진술을 분리해 기록해야 한다"고만 하고 있을 뿐, 어떠한 진술이 사실 진술이고 어떠한 진술이 평가적 진술인지를 구분하지 않은 채 모호하게(물론 문서의 문맥을 읽으면 사실 진술과 평가적 진술이 파악되기는 한다) 서술해 놓았지만 3단계 지식체계론을 통해 처음부터 진술을 명확히 구분해 놓으면 진술의 신빙성이 훨씬 높아지고 안정적이 될 것으로 생각된다.
또한 본 세종대왕에 관한 진술처럼 짧고 이해하기 쉬운 문서의 경우에는 어떤 것이 사실 진술이고 어떤 것이 평가적 진술인지 파악이 용이하지만, 복잡한 문서인 경우에는 이를 구분하는 것이 쉽지 않을 수도 있다. 그보다도 애초에 LLM Wiki를 작성하는 목적이 이러한 판단을 사용자가 문서를 읽고 내리는 것이 아니라 LLM이 스스로 판단하도록 하기 위한 것임을 볼 때, LLM이 위와 같이 모호하게 "평가적 진술과 사실 진술을 분리해 기록해야 한다"고만 하는 것은 어찌보면 무책임한 LLM이라고 할 수도 있을 것이다.
따라서 비록 몇 안 되는 3개의 문서였지만, 3단계 지식체계론을 적용한 경우와 그렇지 않은 경우를 비교해봄으로써 3단계 지식체계론의 효용성은 어느 정도 입증되었다고 생각된다. 특히 사실과 평가를 구분해야 하는 부분이 있을 때, 객관적 사실의 진위여부가 중요하게 다루어지는 문서인 경우, 지식자료의 무결성을 엄격하게 지켜야 하는 상황에서 이 3단계 지식체계론은 충분히 도입할만한 schema로 생각된다.
4. 제기된 의문과 그 해결
그렇지만 '서시'와 같은 문학작품에 있어 3단계 지식체계론이 적용된 경우와 그렇지 않은 경우는 차이가 확연하다. 그런데 이 경우는 3단계 지식체계론이 적용된 경우가 반드시 우월하다고 할 수만은 없다. 3단계 지식체계론이 적용된 경우의 '서시'는 문학작품으로만 취급되고, 그 내용에 대해서는 전혀 다루어지지 않는다. 즉, '서시라는 문학작품의 존재'에 대해서만 wiki가 판단하는 것이다. 서시의 내용에 대해서는 요약하거나 wiki에 편입하지 않는다.
반면에 3단계 지식체계론을 적용시키지 않는 경우에는 '서시'라는 시의 내용에 대해 wiki에 지식으로 반영할 여지를 준다. 다만, 서시의 원문이 아닌, 서시에 대한 요약이나 평가를 그 내용으로 하고 있다.
그래서 고민이 된다. 이러한 문학작품에 대해서는 어떤 방식으로 접근하는 것이 좋을지.
그래서 3단계 지식체계론을 적용한 llm-wiki와 그렇지 않은 llm-wiki에게 같은 질문을 했다. '서시의 내용에서 별과 바람이 어떤 역할을 하고 있는지? 본 llm-wiki에 근거하여 제시해' 라는 내용의 질의를 해 보았다.
먼저, 3단계 지식체계론이 적용된 llm-wiki에서의 답변이다.
• 현재 LLM Wiki 기준으로는 서시의 별/바람 해석이 아직 공식 claim으로 따로 편입되어 있지는 않다. 그래서 아래 답변은 SRC-009 원문에 근거한 문학적 해석이며, 위키의 정책상 assert가 아니라 qualify 수준으로 제시하는 것이 맞다. 별은 시 안에서 지향해야 할 이상, 맑은 마음, 윤리적 방향성의 역할을 한다. 원문에서 별은 “노래하는 마음”과 연결되고, 죽어가는 것을 사랑하겠다는 태도 및 주어진 길을 걸어가겠다는 결심과 이어진다. 따라서 별은 단순한 자연물이 아니라 화자가 붙들고자 하는 내면의 기준에 가깝다. 바람은 작은 흔들림, 양심의 민감함, 현실의 스침을 드러내는 역할을 한다. 원문 초반에서 화자는 아주 작은 바람에도 괴로워하는 존재로 나타나고, 마지막에서도 별이 바람에 스치는 장면이 나온다. 그래서 바람은 화자의 이상을 무너뜨리는 절대적 장애라기보다, 그 이상이 현실 속에서 계속 시험받고 흔들리는 조건으로 볼 수 있다. 정리하면, 별은 화자가 향하는 윤리적 이상이고, 바람은 그 이상을 스치며 흔들리게 하는 현실적·내면적 긴장이다. 둘이 함께 놓이면서 시는 “순수한 이상을 품고 살고자 하지만, 아주 작은 흔들림에도 괴로워하는 자기 성찰”을 보여준다. 근거는 SRC-009 원문과 llm-wiki/wiki/source-summaries/SRC-009-seosi.md에 있다. 다만 위키가 명시하듯, 현재 서시 문서는 원문 자료 관리 노트 수준이므로 이 해석은 확정된 공식 지식이 아니라 짧은 원문 근거에 기반한 해석으로 다루는 것이 적절하다.
이에 비해 3단계 지식체계론이 적용되지 않은 llm-wiki의 답변은 아래와 같다.
본 llm-wiki 기준으로 보면, 「서시」에서 **별**과 **바람**은 화자의 내면을 드러내는 상징적 이미지입니다. **별**은 화자가 지향하는 순수함, 양심, 삶의 방향을 떠올리게 합니다. 위키의 서시 개념 문서는 “별은 지향점과 순수한 마음”을 나타낸다고 정리합니다. seosi.md (line 24) **바람**은 그 순수한 마음을 흔드는 미세한 자극이자, 화자가 느끼는 윤리적 긴장을 드러냅니다. 같은 문서에서 “바람은 양심을 흔드는 미세한 자극”이라고 설명하고, source-summary도 “사소한 바람에도 괴로워할 만큼 예민한 양심”을 드러낸다고 요약합니다. seosi.md (line 24), SRC-001-seosi.md (line 25) 따라서 둘을 함께 보면, **별은 화자가 닿고 싶은 윤리적 이상**, **바람은 그 이상을 향해 가는 과정에서 느끼는 흔들림과 양심의 민감함**입니다. llm-wiki는 이를 “화자의 내면과 윤리적 긴장을 드러내는 이미지”로 정리해두었습니다. SRC-001-seosi.md (line 32)
내용은 LLM이 비슷하게 해석한 것으로 보인다. 다만, 차이가 있다. 3단계 지식체계론이 적용된 llm-wiki에서는 서시의 원문은 있지만, 별/바람 해석이 공식 claim으로 있지는 않음을 밝히면서 별과 바람에 대한 문학적 해석을 LLM이 스스로 보충하지만, 확정된 공식 지식이 아니라 짧은 원문 근거에 기반한 해석으로 다루는 것이 적절하다는 코멘트를 남기고 있다.
반면에, 3단계 지식체계론이 적용되지 않은 llm-wiki에서는 wiki의 concept 문서에 나타난 내용과 source-summary에 나타난 요약을 근거로 들어 해석을 제시한다.
따라서 이는 일장일단이 있는 것 같다. 문학작품으로 원문을 검증, 보존하고 내용에 대해서는 별도의 해석이나 평가를 하지 않고 있다가 질의가 들어오면 LLM이 스스로 답변을 생성하는 3단계 지식체계론이 적용된 위키와 문학작품의 내용 중 일부를 해석하여 wiki에 편입시킨 후 이에 근거하여 답변을 도출하는 3단계 지식체계론이 적용되지 않은 위키는 각각 장단점을 갖고 있는 것이다.
다만, 처음의 우려는 3단계 지식체계론이 적용된 wiki에서는 서시의 내용에 나타난 일부 상징에 대해 llm-wiki에 근거한 답변을 제시하도록 물어볼 경우에 제대로 답변을 하지 않을지도 모른다는 것이었으나 근거에 차이가 있을 뿐, 답변의 내용은 크게 차이가 없는 것으로 생각된다.
따라서 이것은 선택의 문제가 되었다. 어떤 시스템이 우월하고 어떤 시스템이 열후하다는 문제가 아니라 정책의 문제 또는 취향의 문제가 되는 것이다.
# [Claude Code] "같은 서버인데 왜 하나만 죽었지?" — AI에게 봇 끊김 미스터리를 통째로 맡겨봤습니다 ## 📝 한줄 요약
같은 서버(맥북)에서 돌리던 두 개의 AI 봇 중 하나만 텔레그램 연결이 끊긴 미스터리를, Claude Code가 시스템 로그를 직접 뒤져 "노트북 뚜껑을 닫아서"라는 진짜 원인까지 30분 만에 찾아냈습니다. ## 🎯 이런 분들께 도움돼요
- 개인 서버나 맥에서 텔레그램/디스코드 봇, 자동화 에이전트를 24시간 돌리는 분
- "재시작하면 되긴 하는데 왜 죽는지는 모르겠는" 문제를 매번 손으로 때우고 계신 분
- 로그 분석·장애 원인 추적을 AI에게 어디까지 맡길 수 있는지 궁금한 분 ## 😫 문제 상황 (Before)
저는 맥북 한 대에서 AI 비서 봇을 **두 개** 동시에 돌리고 있습니다.
- **Hermes** (루이-휴먼)
- **Openclaw** (루피) 둘 다 텔레그램으로 메시지를 주고받는 같은 구조인데, 어느 날 보니 **Hermes만 텔레그램 연결이 끊겨 있고 Openclaw는 멀쩡히 살아 있었습니다.**
대답을 한참동안 안하고 있는 루이-휴먼(Hermes)
요청 즉시 대답하는 루피(Openclaw)
같은 노트북, 같은 네트워크, 같은 텔레그램. 조건이 전부 똑같은데 한쪽만 죽는다? 이게 제일 찝찝했습니다. 그냥 재시작하면 다시 붙긴 하는데, **원인을 모르니 내일 또 끊길 게 뻔했죠.** 매번 "어 또 끊겼네" 하고 손으로 살리는 게 일이었습니다. ## 🛠️ 사용한 도구
- **Claude Code** (모델: Claude Opus 4.8)
- 별도 설정 없이, 평소 쓰던 터미널에서 한 문장으로 시작했습니다. ## 🔧 작업 과정 ### 1. "Hermes 연결 끊긴 것 같은데 확인 좀 해봐"
딱 이 한 문장으로 시작했습니다. 제가 한 일은 이게 전부예요. Claude Code는 먼저 시스템에서 'hermes'라는 이름의 프로세스와 서비스를 직접 훑었습니다. 그리고 게이트웨이 프로세스 자체는 **4일째 멀쩡히 살아 있다**는 걸 확인했죠. 죽은 건 프로그램이 아니라 **텔레그램 채널 하나**였습니다. ### 2. 로그에서 "범인의 흔적"을 찾다
Claude Code가 게이트웨이 로그를 뒤지자 결정적인 줄이 나왔습니다. > `telegram paused after 10 consecutive failures` (2026-05-30 13:23:18) 즉, 텔레그램 연결이 **10번 연속 실패하자 시스템이 채널을 스스로 "일시정지(paused)" 시켰고**, 그 상태는 사람이 직접 풀어주기 전까지 자동으로 복구되지 않는 구조였습니다. 그래서 무려 **약 34시간** 동안 끊긴 채 방치돼 있었던 거죠. 실패 로그의 에러 메시지도 단서였습니다.
> `nodename nor servname provided, or not known` 이건 "서버가 다운됐다"가 아니라 **"인터넷 주소를 변환하는 것 자체가 안 됐다"** — 즉 그 시점에 맥의 네트워크가 통째로 죽어 있었다는 뜻이었습니다. ### 3. 진짜 범인: 노트북 뚜껑
여기서 Claude Code가 한 발 더 들어갔습니다. "그 시각에 이 맥에서 무슨 일이 있었나"를 보려고 **macOS 전원 로그(pmset)**를 직접 확인한 거죠. 그리고 결정적 증거가 나왔습니다. > `2026-05-30 11:32:08 Sleep — 'Clamshell Sleep' Using Batt` **클램셸 슬립** = 노트북 뚜껑을 닫아서 잠든 상태. 게다가 충전기도 안 꽂힌 배터리 상태였습니다. 뚜껑을 닫는 순간 Wi-Fi가 내려갔고, 그 와중에 봇이 재연결을 시도하다 10번 연속 실패해서 영구 정지에 빠진 겁니다. 범인은 해커도, 버그도 아니고 **"노트북 뚜껑을 닫은 것"** 이었습니다. 😅 ### 4. 그럼 Openclaw는 왜 안 죽었을까? (핵심)
여기서 제가 진짜 궁금했던 걸 물어봤습니다. *"같은 맥북인데 Openclaw는 왜 멀쩡하지?"* Claude Code가 Openclaw 로그를 똑같이 까봤더니 — **Openclaw도 정확히 같은 시각에 똑같이 끊겨 있었습니다.** ```
09:47 [health-monitor] 텔레그램 재시작 (이유: 연결 끊김) → 시도 1/10
09:59 재시작 → 시도 1/10
10:16 재시작 → 시도 2/10
10:34 재시작 → 시도 1/10 ← 카운터가 다시 1로 리셋!
``` 차이는 **실패를 세는 방식**이었습니다. 이게 이번 사건의 핵심입니다. ## 🆚 두 봇의 근본적인 차이 둘 다 같은 맥에서, 같은 뚜껑 닫힘으로, 똑같이 끊겼습니다. 운명을 가른 건 **"끊겼을 때 어떻게 대응하도록 설계됐느냐"** 단 하나였습니다. | 구분 | **Hermes** 🔴 | **Openclaw** 🟢 |
|---|---|---|
| 실패 카운트 방식 | 끊긴 구간을 **하나로 계속 누적** | 끊김이 생길 때마다 **카운터 리셋** |
| 한계 도달 시 | 10회 → **영구 정지(사람이 풀어야 함)** | 감지 즉시 **자동 재시작 반복** |
| 노트북이 깨어난 뒤 | 끊긴 채 그대로 (34시간 방치) | **스스로** 다시 연결 |
| 설계 철학 | **래치형(걸쇠) 차단기** | **자가 치유형** | - **Hermes**는 "문제가 반복되면 일단 멈추고 사람을 부른다"는 안전장치형 설계입니다. 서버 환경에선 합리적이지만, **노트북처럼 자주 잠들었다 깨는 환경**에서는 잠든 동안의 실패가 쌓여 깨어난 뒤에도 죽어 있게 됩니다.
- **Openclaw**는 "끊기면 그냥 계속 다시 붙어본다"는 끈질긴 설계입니다. 그래서 뚜껑을 여닫을 때마다 알아서 회복합니다. 하드웨어 문제도, 네트워크 문제도 아니었습니다. **순전히 소프트웨어의 '장애 복구 철학' 차이**였습니다. ## ✅ 결과 (After) | | Before | After |
|---|---|---|
| 원인 파악 | "왜 끊기는지 모름" | 노트북 클램셸 슬립 → 네트워크 단절 → 영구 정지로 **명확히 규명** |
| 두 봇의 차이 | "느낌상 Openclaw가 튼튼한가?" | **설계 차이를 로그 증거로 입증** |
| 복구 | 매번 수동 | 원인을 아니 **재발 방지 방향**까지 확보 |
| 소요 시간 | (원인 영영 모름) | **약 30분** | 그 자리에서 `hermes gateway restart` 한 번으로 텔레그램이 23:25:19에 다시 붙는 것까지 확인했습니다. ## 🛡️ Hermes도 계속 끊기지 않게 하려면 Claude Code와 함께 정리한, 끊김을 막는 3가지 방법입니다. 상황에 맞게 고르면 됩니다. **1) 근본 해결 — 노트북을 안 재우기**
24시간 돌릴 거라면 충전기를 꽂고, 뚜껑을 닫아도(혹은 일정 시간 지나도) 잠들지 않게 전원 설정을 바꾸는 방법입니다. 네트워크가 안 끊기면 애초에 "정지"가 발생하지 않습니다. (단, 배터리 소모·발열은 감수) **2) 끈질기게 재시도하게 만들기 (Openclaw처럼)**
Hermes가 10번 실패 후 영구 정지하는 동작은 **설정이 아니라 코드에 박혀 있어서**, 이 부분을 고치면 Openclaw처럼 "계속 다시 붙는" 방식으로 바꿀 수 있습니다. 다만 프로그램을 업데이트하면 수정이 덮어써질 수 있어 재적용이 필요합니다. **3) 운영으로 보완하기**
끊김을 완전히 막기보다, **끊기면 자동으로 살리는** 방식입니다. 일정 주기로 상태를 점검해 "정지" 상태가 보이면 자동으로 재시작하거나, 텔레그램 창에서 명령어 한 줄(`/platform resume`)로 즉시 되살리는 방법입니다. > 제 결론: 노트북에서 돌리는 만큼 **1번(전원 유지)** 을 기본으로 하고, 혹시 모를 상황 대비로 **3번(자동 살리기)** 을 얹는 조합이 가장 마음 편합니다. ## 💬 AI 활용 팁
- **"확인 좀 해봐"처럼 막연하게 던져도 됩니다.** AI가 알아서 프로세스 → 로그 → 시스템 로그 순으로 좁혀 들어갑니다. 처음부터 완벽한 질문을 만들 필요가 없어요.
- **"왜?"를 한 번 더 물어보세요.** "끊겼다"에서 멈추지 않고 "왜 그 시각에 네트워크가 죽었지?"라고 물으니 전원 로그까지 파고들어 진짜 원인이 나왔습니다.
- **비교는 AI의 특기입니다.** "쟤는 왜 안 죽었어?"라는 질문 하나로 두 시스템의 설계 철학 차이까지 정리해줬습니다.
- **주의점:** 실행 중인 서비스를 재시작·수정하는 건 영향이 있으니, AI가 원인을 설명한 뒤 **무엇을 바꿀지 확인하고 진행**하는 게 안전합니다. ## 📋 재사용 가능한 프롬프트
실제로 제가 던진 문장들입니다. 그대로 따라 하셔도 됩니다. > "(서비스 이름) 연결이 끊긴 것 같은데 확인 좀 해봐" > "원인이 정확히 뭐야?" > "같은 맥북에서 돌리는데 A는 끊겼고 B는 안 끊겼어. 이유가 뭘까?" > "A에서도 계속 끊기지 않게 하려면 어떻게 해?" ---
1. 이 글을 쓰는 이유
앞서 글에서 3단계 지식체계론을 실제로 적용하여 ingest한 예시를 살펴보았다. 그런데 곧바로 다음과 같은 의문이 생겼다. 그것은 weak confirmability로 분류된 두 문장이 3단계 지식체계론에서 어떤 과정을 거쳤는지 궁금했기 때문이었다.
여기서 내가 궁금한 사항이 있어. 너는 세종대왕 관련 문서에서 claim의 유형을 fact와 interpretation으로 구분했어. 그렇다면 8개의 claim 중에서 4개가 fact(historical fact 포함)이고 4개가 interpretation인데, 3단계 지식체계론을 각각의 claim에 어떻게 적용했는지는 내가 모르겠어. 똑같이 strict로 적용했는지, 아니면 일부는 weak로 적용했는지, 아니면 적용하지 않은 것이 있는지를 모르겠어. 그리고 지금 interpretation 4개 중에 2개는 weak confirmability로 분류됐는데, 그 근거가 무엇인지 내가 알 수가 없어. 그리고 weak confirmability로 분류한 claim조차 3단계 지식체계론에서 typicality, coherence가 모두 어떻게 평가된 것인지를 알 수가 없어. 3단계 지식체계론은 순차적인 검증 단계를 거치도록 되어 있어. 그래서 1단계와 2단계를 거쳐야 해. 그런데 weak confirmability로 분류됐음에도 1단계인 typicality와 2단계인 coherence가 어떤 상태인지 알지 못한다는 것은 문제가 있는 것 같아. 이에 대해 설명해주고 개선 방안을 마련해줘
이에 대해 LLM은 다음과 같이 답별했다.
• 지적이 맞습니다. 현재 기록은 confirmability 결과만 눈에 띄고, 각 claim이 1단계 지식요건해당성과 2단계 정합성을 어떻게 통과했는지 추적하기 어렵습니다. 관련 문서를 확인한 뒤, claim별 3단계 판정표가 남도록 고치겠습니다. • 개선은 세 갈래로 하겠습니다. 첫째, SRC-010의 8개 claim마다 typicality -> coherence -> confirmability -> answer_policy를 표로 남깁니다. 둘째, weak/contradiction register도 1·2단계 판정 없이 3단계만 적는 형태를 금지합니다. 셋째, schema에 “확증가능성만 단독 기록하지 말라”는 규칙을 추가합니다. • 맞습니다. 이전 처리는 불완전했습니다. 문제는 두 가지였습니다. 첫째, SRC-010 전체 문서에는 knowledge_review: strict를 달았지만, 8개 claim 각각에 대해 typicality -> coherence -> confirmability가 어떻게 통과/탈락했는지 남기지 않았습니다. 둘째, weak-confirmability-register.md에는 confirmability만 기록하고 1단계·2단계를 생략했습니다. 3단계 지식체계론의 취지상 이건 추적성이 부족합니다. 개선해서 반영했습니다. 이제 세종대왕.md의 8개 claim은 모두 아래 순서로 표시됩니다.
claim -> type -> typicality -> coherence -> confirmability -> answer_policy -> reason
정리하면: - 8개 claim 모두 3단계 검토를 적용했습니다. - interpretation 4개도 1단계와 2단계를 거친 뒤 weak로 분류했습니다. - weak의 근거는 “claim 단위로는 성립하지만, 평가 기준·독립 근거·검증 가능성이 부족하다”입니다. - “아이패드”와 “단종의 아버지” claim은 typicality: pass지만 coherence: rejected, confirmability: none, answer_policy: do_not_assert로 명시했습니다. - “조선의 제4대 왕”, “한글 창제”는 현재 wiki 내부에서는 SRC-010 단일 근거만 있으므로 moderate/qualify로 낮췄습니다. 공식 출처를 ingest하면 strong/assert_with_citation으로 올릴 수 있습니다. 또 schema에도 규칙을 추가했습니다. confirmability는 typicality와 coherence 없이 단독 기록하지 않는다. 검증 결과도 통과했습니다. - index 링크 누락 없음 - Source ID 미등록 참조 없음 - wiki frontmatter 누락 없음 - schema 밖 coherence 값 잔존 없음
2. 변경된 schema에 따른 결과
이렇게 하니까 바로 전에 세종대왕에 대한 ingest 및 3단계 지식체계론 적용 결과와는 다른 결론이 도출되었다.
특히 interpretation으로 분류된 4개의 문장 중 이전에는 confirmability를 통과한 claim 2개가 weak confirmability로 재분류되어 weak confirmability가 기존의 2개에서 4개로 늘어났다.
결론적으로 3단계 지식체계론이 어떻게 적용된 것인지를 추적가능하도록 LLM에게 요청하니 LLM Schema의 적용기준이 한층 강화되어 심사가 더 까다로워졌다.
추가된 2개의 claim은 다음과 같다.
claim: "세종대왕은 존경받을만 하다."
claim: "세종대왕의 업적은 널리 알려져야 한다."
이전의 결과에서는 이 두개의 claim은 비록 interpretation이었지만 확증가능성이 약한 것으로 분류되지는 않았었다. 그런데 3단계 지식체계론을 어떻게 적용시켰는지에 대해 묻고 이를 어떻게 할 것인지 방안을 지시하자 3단계 지식체계론을 적용하여 더 강화시키는 결과를 낳았다.
2.1. 변경된 schema에 따른 결과 상세
Initial State
이전 wiki/source-summaries/SRC-010-sejong-the-great.md의 Candidate Claims 표는 다음처럼 축약되어 있었다.
Claim
유형
3단계 판단
answer_policy
세종대왕은 잘 생겼다
interpretation
주관적 평가, 근거 없음
mention_as_view
세종대왕은 존경받을만 하다
interpretation
평가 claim
mention_as_view
세종대왕은 조선의 제4대 왕이다
fact
정합성 높음, 추가 신뢰 출처 필요
assert_with_citation
세종대왕은 한글을 창제했다
historical_fact
정합성 높음, 추가 신뢰 출처 필요
assert_with_citation
세종대왕은 아이패드를 집어던지셨다
fact
시대착오로 정합성 탈락
do_not_assert
세종대왕은 단종의 아버지이다
fact
일반 역사 지식과 충돌하는 오류 claim
do_not_assert
세종대왕의 업적은 널리 알려져야 한다
interpretation
규범적 평가
mention_as_view
모든 한국 사람들은 세종대왕을 추앙해야 한다
interpretation
과잉 일반화된 규범 주장
mention_as_view
이전 wiki/concepts/sejong-the-great.md의 Claim 처리 표는 다음처럼 결과만 요약했다.
원문 claim 요지
처리
외모 평가
주관적 평가. 사실로 단정하지 않음
존경받을 만하다는 평가
의견으로만 소개
조선의 제4대 왕
역사적 사실 claim. 공식 출처 보강 권장
한글 창제
역사적 사실 claim. 공식 출처 보강 권장
아이패드를 집어던졌다는 주장
시대착오 claim. 답변 근거로 사용 금지
단종의 아버지라는 주장
오류 claim. 답변 근거로 사용 금지
업적이 알려져야 한다는 주장
규범적 의견
모든 한국인이 추앙해야 한다는 주장
과잉 일반화된 규범적 의견
이전 weak-confirmability-register.md에는 weak claim 두 개만 있었고, typicality와 coherence가 없었다.
weak-sejong-001: claim: "세종대왕은 잘 생겼다." confirmability: weak answer_policy: mention_as_view reason: 주관적 외모 평가이며 근거와 판단 기준이 없다. weak-sejong-002: claim: "모든 한국 사람들은 세종대왕을 추앙해야 한다." confirmability: weak answer_policy: mention_as_view reason: 규범적·과잉 일반화 주장이다.
이전 contradiction-register.md에는 rejected claim 두 개가 있었지만 typicality가 없었다.
conflict-sejong-001: new_claim: "세종대왕은 아이패드를 집어던지셨다." coherence: rejected confirmability: none answer_policy: do_not_assert conflict-sejong-002: new_claim: "세종대왕은 단종의 아버지이다." coherence: rejected confirmability: none answer_policy: do_not_assert
새로운 schema에 의해 3단계 지식체계론이 순차적으로 적용되고 그 과정을 추적할 수 있도록 한 결과는 다음과 같다.
new_state
새 상태에서는 SRC-010의 8개 claim 모두 아래 순서를 갖는 판정표로 바뀌었다.
claim -> type -> typicality -> coherence -> confirmability -> answer_policy -> reason
핵심 변경:
모든 claim에 typicality, coherence, confirmability, answer_policy를 명시했다.
interpretation claim 4개도 1단계와 2단계를 거친 뒤 weak/mention_as_view로 분류했다.
역사 fact 후보 2개는 공식 출처 보강 전까지 moderate/qualify로 낮췄다.
시대착오/오류 claim 2개는 typicality: pass, coherence: rejected, confirmability: none, answer_policy: do_not_assert로 명시했다.
register의 기록 형식에도 typicality, coherence 필드를 추가했다.
개정된 판정표는 다음과 같다.
ID
Claim
유형
1단계 typicality
2단계coherence
3단계 confirmability
answer_policy
근거
C-010-01
세종대왕은 잘 생겼다
interpretation
pass
coherent
weak
mention_as_view
의견으로 범위를 한정하면 충돌은 없지만, 외모 평가 기준과 독립 근거가 없다.
C-010-02
세종대왕은 존경받을만 하다
interpretation
pass
coherent
weak
mention_as_view
평가 claim으로 성립하지만, 왜 존경받을 만한지 근거가 제시되지 않았다.
C-010-03
세종대왕은 조선의 제4대 왕이다
fact
pass
coherent
moderate
qualify
직접 claim은 있으나 현재 wiki에는 SRC-010 외 독립 출처가 없다.
C-010-04
세종대왕은 한글을 창제했다
historical_fact
pass
coherent
moderate
qualify
직접 claim은 있으나 공식 역사 출처 ingest 전이므로 강한 확증으로 올리지 않는다.
C-010-05
세종대왕은 아이패드를 집어던지셨다
fact
pass
rejected
none
do_not_assert
시간 범위가 맞지 않는 시대착오 claim이다.
C-010-06
세종대왕은 단종의 아버지이다
fact
pass
rejected
none
do_not_assert
조선 왕실 계보에 관한 일반 역사 지식과 충돌하는 오류 claim이다.
C-010-07
세종대왕의 업적은 널리 알려져야 한다
interpretation
pass
coherent
weak
mention_as_view
규범적 견해로는 기록 가능하지만 사실 claim이나 wiki 정책으로 단정할 근거는 없다.
C-010-08
모든 한국 사람들은 세종대왕을 추앙해야 한다
interpretation
pass
coherent
weak
mention_as_view
source의 규범적 견해로만 보존한다. 보편 의무로 일반화하면 scope mismatch가 발생한다.
이윽고 발견한 또다른 문제는 바로 이전의 문서가 모두 update되어서 그 내용이 덮어쓰기가 되었다는 것이다. 따라서 기존의 schema에 따라 작성한 문서는 완전히 사라지고, 완전히 새로운 내용으로 탈바꿈하게 되었다. 결국 통시적인 관점에서 추적은 제한이 있을 수밖에 없게 된 것이었다.
또한 처음부터 내재되어 있던 문제, 즉, 의견이나 규범과 같은 곳에서까지 3단계 지식체계론을 적용시킬 필요가 있는지에 대한 의문은 여전히 남아있게 되었다. 아예 처음부터 규범이나 의견, 해석과 같은 곳에는 3단계 지식체계론을 작동시키지 말고 그냥 규범, 의견, 해석으로만 처리해도 되지 않을까? 객관적 사실 여부가 문제되는 사안에서만 3단계 지식체계론을 가동시키면 되지 않을까 하는 의문이 또다시 제기됐다.
3. 내용의 update, 개정 시 이전의 내용 처리 문제
아래와 같이 프롬프트를 입력해서 LLM에게 물어보았다.
그렇다면, 이전의 내용은 어디에 있어? 새로운 schema에 따라서 3단계 지식체계론을 적용하기로 한 것은 좋은데, 이렇게 이전의 문서를 완전히 지우고 다시 새로운 내용으로 대체해버리면 해당 claim에 대한 개정 이력이 추적되지 않는 문제가 있는데 이에 대해 너는 어떻게 생각해?
그러자 다음과 같이 답변했다
• 맞습니다. 방금 제 수정은 “현재 문서의 정확성”은 올렸지만, “왜 이전 판단을 폐기하고 새 판단으로 바꿨는지”를 별도 이력으로 남기지 않았습니다. Git을 아직 보류한 상태라면 이런 개정 이력은 위키 내부 register로 반드시 남겨야 합니다. • 그래서 지금 바로 개정 이력 register를 추가하겠습니다. 특히 방금 바꾼 SRC-010의 이전 판단표를 “폐기된 내용”이 아니라 “superseded review”로 보존하고, 앞으로 중요한 claim review를 바꿀 때는 새 내용으로 덮어쓰기 전에 이력을 남기도록 schema에 규칙을 넣겠습니다. • 동의합니다. 지금 방식에는 실제로 문제가 있었습니다. 제가 한 일은 “현재 문서를 더 나은 schema에 맞게 고친 것”이지만, 그 과정에서 이전 판단표가 본문에서 사라졌습니다. Git을 아직 도입하지 않은 상태라면, 이렇게 덮어쓰는 방식은 지식의 개정 이력을 잃게 만듭니다. 특히 claim review는 “왜 이전 판단이 부족했고, 어떤 기준으로 새 판단이 채택됐는지”가 지식 자체의 일부라서 반드시 남겨야 합니다. 그래서 바로 보완했습니다. 추가한 문서: - llm-wiki/wiki/reviews/revision-history.md 여기에 SRC-010 세종대왕 claim review의 이전 상태를 보존했습니다. 즉, 이전의 축약된 Candidate Claims 표, 이전 concept 문서의 Claim 처리 표, 이전 weak register/contradiction register의 부족했던 형태를 previous_state로 남겼고, 새 판단표를 new_state로 기록했습니다. 또 schema에도 규칙을 추가했습니다. - llm-wiki/schema/lint-checklist.md: 중요한 claim review 변경에 revision history가 있는지 점검하도록 추가 앞으로 원칙은 이렇게 잡았습니다. 그 다음: 본문 문서를 새 판단으로 갱신 log.md: 요약만 기록 revision-history.md: 이전 상태, 새 상태, 변경 이유, 영향 파일을 상세 기록 검증도 완료했습니다. - index 링크 누락 없음 - Source ID 미등록 참조 없음 - wiki frontmatter 누락 없음
즉, 요약하면 개정된 이력을 모두 revision-history.md 파일에 기록하겠다는 것이었다. 실제로 reivision-history.md파일의 내용을 보니 개정되기 전 세종대왕에 관한 문서가 이력으로 남아있었다.
하지만 이같은 방식이 지금처럼 llm-wiki의 문서가 적을 때에는 괜찮을지 몰라도 문서가 많아지거나 개정이 빈번해지면 결국 reivision-history.md 파일의 내용이 무수히 늘어날 우려가 있었다.
› revision history를 남기는 것은 좋은데, wiki 문서의 양이 많아지면 revision도 많이 발생할 것이고, 그렇게 되면 revision history 문서의 양도 늘어날 것인데, 그러면 revision을 추적하기가 어려워지지 않아? 이것을 revision-history 폴더를 따로 만들어서 개별 문서에 대한 revision history를 별도로 만드는 것이 나을까? 아니면 지금 방식대로 하나의 revision-history.md에 저장하는 것이 나을까?
LLM과 이야기하니 금세 답이 나왔다.
나는 하이브리드 방식이 맞다고 봅니다. 지금처럼 revision-history.md 하나에 계속 쌓는 방식은 MVP 초기에는 좋지만, 문서가 많아지면 금방 한계가 옵니다. 반대로 문서별 revision만 두면 “최근에 전체적으로 뭐가 바뀌었는지”를 보기 어렵습니다. 추천 구조는 이겁니다. wiki/ reviews/ revision-index.md # 전체 revision의 시간순 색인 revisions/ SRC-010-sejong-the-great.md # 세종대왕 claim review 전용 이력 schema-knowledge-admission.md concept-llm-wiki.md 역할 분리: revision-index.md = 전체 변경의 목차 = 언제, 무엇이, 왜 바뀌었는지만 짧게 기록 revisions/*.md = 개별 문서/Source/claim group의 상세 개정 이력 = previous_state, new_state, reason, affected_files 보존 예를 들면 revision-index.md에는 이렇게만 둡니다. ## [2026-05-31] rev-src-010-claim-review-matrix - target: SRC-010 세종대왕 claim review - detail: [[wiki/reviews/revisions/SRC-010-sejong-the-great]] - reason: claim별 3단계 검증 이력 누락 보완 상세 내용은 별도 파일에 둡니다. wiki/reviews/revisions/SRC-010-sejong-the-great.md 이 방식의 장점은 명확합니다. - 특정 문서의 개정 이력을 추적하기 쉽다. - 전체 변경 흐름도 revision-index.md에서 볼 수 있다. - revision-history.md 하나가 비대해지는 문제를 피한다. - Git 도입 전에도 문서 단위 audit trail을 만들 수 있다. - 나중에 Git을 도입해도 이 구조는 그대로 의미가 있다. 운영 규칙은 이렇게 잡으면 됩니다. 오탈자, 링크 수정: log.md에만 기록하거나 생략 가능 중요 claim review 변경: revision-index.md에 1줄 기록 wiki/reviews/revisions/{target}.md에 상세 기록 schema 변경: revision-index.md에 1줄 기록 wiki/reviews/revisions/schema-{name}.md에 상세 기록 canonical 문서 변경: revision-index.md에 1줄 기록 wiki/reviews/revisions/concept-{name}.md에 상세 기록 결론적으로, 지금의 단일 revision-history.md는 임시로는 괜찮지만 장기 구조로는 부족합니다. 이 시점에서 revision-index.md + revisions/개별 파일 구조로 바꾸는 것이 더 낫습니다.
결국 이중으로 관리하자는 것인데, 이렇게 하면 문서의 개정 이력은 철저하게 관리되겠지만, 문서의 양이 늘어나고 결국 llm wiki가 비대해짐은 물론 토큰 소모량도 많아지는게 아닐까 우려됐다.
› 이러면 문서의 이력 관리는 철저하게 되겠지만, 문서가 비대해지고 검색할 때 토큰 소모량이 많아지지는 않을까?
역시 LLM은 이에 대해서도 좋은 해결책을 제시해주었다.
• 맞습니다. 이력 관리를 너무 철저하게 하면 위키가 “지식 저장소”가 아니라 “감사 로그 저장소”처럼 비대해질 수 있습니다. 검색·Query 때도 불필요한 revision 문서가 같이 읽히면 토큰 낭비가 큽니다. 그래서 핵심은 revision을 남기되 기본 검색/답변 경로에서는 제외하는 것입니다. 추천 구조는 이렇게 조정하는 게 좋습니다. wiki/ concepts/ workflows/ source-summaries/ reviews/ revision-index.md # 얇은 색인만 기본 참조 가능 revisions/ # 상세 이력. 기본 query 제외 SRC-010-sejong.md schema-knowledge-admission.md 운영 규칙: 일반 Query: index.md 관련 wiki 문서 source summary 필요 시 review register 일부 Revision 추적 Query: revision-index.md 필요한 revisions/{target}.md만 읽기 즉, revisions/는 기본 지식 검색 대상이 아니라 audit/archive 영역으로 둡니다. frontmatter로도 명확히 표시하면 좋습니다. --- type: revision-history status: archived search_scope: audit_only default_query: false summary_l0: "SRC-010 claim review 개정 이력" summary_l1: "세종대왕 claim 검토표의 이전 상태와 새 상태를 보존한 감사용 문서" source_refs: - SRC-010 tags: [revision, audit] --- 그리고 AGENTS.md에는 이렇게 넣는 게 좋습니다. 일반 질문에 답할 때는 `wiki/reviews/revisions/`를 읽지 않는다. 사용자가 "이력", "왜 바뀌었어?", "이전 판단", "revision", "audit"을 묻는 경우에만 revision 문서를 읽는다. 결론은 이겁니다. 상세 revision은 남긴다. 하지만 기본 query path에서는 제외한다. index에는 얇은 revision 색인만 둔다. 상세 이력은 사용자가 이력을 물을 때만 읽는다. 이렇게 하면 추적성과 토큰 효율을 둘 다 잡을 수 있습니다.
요약하자면, 일반 질문에 답할 때에는 읽지 않고, 이력에 대해 물어볼 때에만 revision 문서를 읽도록 하는 것이었다.
이 방식은 나로서는 반대할 이유가 없었다. 따라서 채택하기로 했다.
4. 개정 이력 기록 및 추적 schema 최종본
하지만 revision에 대한 기록 schema를 짜는 것이 일거에 된 것은 아니었다. LLM은 내가 의도한 방향이 아닌 다소 나와는 다른 방향을 제시했다.
지나치게 자세하게 개정 이력을 넣는 것을 넘어서 내용이 중복되도록 넣는다든지, 아니면 이것을 지적하자 반대로 개정된 사항만 축약해서 넣고, 실제 원문의 내용은 넣지 않는다든지 하는 티키타카가 계속 이루어졌다.
내가 의도한 것은 최초 개정되기 전 상태의 문서 내용이 맨 아래에 저장되어 있고, 개정이 될 때마다 해당 문서의 전체 개정된 내용이 그 위에 쌓이는, 역순 연대기 식으로 기록하는 것이었다. 가장 최신 개정된 내용이 맨 위에 오고, 그 밑으로 시간이 가까운 순서에 따라 개정된 내용이 수록되는 방식이었다.
몇 번의 밀당과 지적 끝에 결국 내가 원하는 방식의 revision-history schema가 만들어졌다.
이렇게 해서 만들어진 최종 schema의 요약은 아래와 같다.
핵심 원칙 revision은 일반 wiki 본문을 비대하게 만들지 않고, 감사가 필요할 때만 읽는 별도 이력 계층으로 관리한다. 각 개정 entry는 단순 요약이 아니라 “그 개정으로 실제 무엇이 되었는지”를 재구성할 수 있을 만큼 구체적인 new_state를 남긴다. 저장 위치 wiki/reviews/revision-index.md wiki/reviews/revisions/{target-id-or-slug}.md revision-index.md는 전체 이력의 얇은 색인이다. 날짜, 대상 문서, 변경 유형, 상세 revision 문서 링크만 둔다. wiki/reviews/revisions/는 개별 문서별 상세 이력 저장소다. 예를 들면: wiki/reviews/revisions/SRC-010-sejong-the-great.md 읽기 정책 일반 질문에 답할 때는 기본적으로 읽지 않는다. default_query: false search_scope: audit_only 다만 사용자가 아래와 같은 의도를 보이면 읽는다. 이력 왜 바뀌었어? 이전 판단 이전 내용 revision audit 개정 변경 근거 상세 revision 문서 구조 개별 revision 문서는 역순 연대기 방식이다. 가장 최근 revision 그 이전 revision 더 이전 revision 초기 상태 또는 최초 등록 상태 즉 최신 변경이 항상 맨 위에 온다. 새 개정이 발생해도 별도 파일을 계속 만드는 것이 아니라, 같은 대상 문서의 revision 파일 맨 위에 새 entry를 추가한다. Entry 기본 형식 ## 2026-05-31 - Revision Title ### change_summary 무엇이 바뀌었는지 요약한다. ### reason 왜 바꾸었는지 기록한다. ### new_state 이 개정 후 실제 상태를 구체적으로 기록한다. claim review라면 실제 claim 판정표를 넣는다. ### affected_files - `path/to/file.md` ### migration_note 이전 내용이 어떻게 보존되는지, 앞으로 어떻게 읽어야 하는지 적는다. 중요한 점은 new_state가 “요약”만이면 안 된다는 것이다. 예를 들어 claim review를 바꿨다면 다음 수준까지 들어가야 한다. claim -> type -> typicality -> coherence -> confirmability -> answer_policy -> reason 중복 방지 원칙 이전 entry의 new_state를 다음 entry에서 그대로 반복하지 않는다. 대신 새 entry는 “이번 개정 후 상태”를 구체적으로 남긴다. 시간이 지나면 각 entry의 new_state가 그 시점의 스냅샷 역할을 한다. 즉 구조는 이렇게 된다. 현재 최신 본문: wiki/source-summaries/SRC-010-sejong-the-great.md 이력: wiki/reviews/revisions/SRC-010-sejong-the-great.md - Revision 3: 개정 후 실제 상태 - Revision 2: 개정 후 실제 상태 - Revision 1: 최초 개정 후 실제 상태 - Initial State: 최초 상태 이 방식이면 일반 검색 토큰은 줄이고, 필요할 때는 문서별로 충분히 상세한 변경 이력을 추적할 수 있다.
5. 결론
3단계 지식체계론을 ingest, query, lint architecture에 포섭한 것은 의미있는 일이라고 잠정적으로 결론지었다. 첫째는 llm이 엉뚱하게 분류하는 것을 막는다는 점에서, 둘째는 llm이 어떤 근거에 의해 분류했는지를 추적할 수 있게 되었다는 점, 셋째는 llm wiki의 내용을 근거로 답변을 도출하도록 했을 때 역시 그 근거를 제시하도록 함으로써 답변의 무결성을 끌어올릴 수 있게 됐다는 점에서 의의가 있다.
다만, 세 번째와 관련하여 아직 ingest 단계에서만 이를 검증했고, query나 lint를 실행해보지는 않았는데, 실제로 query, lint를 했을 때 어떠한 결론이 도출될 것인지 궁금증이 꼬리에 꼬리를 물고 생겼다.
지난 글에서는 3단계 지식체계론을 적용하지 않은 llm-wiki에서의 동일 자료의 ingest 결과와 비교한 내용을 사례게시글로 쓰겠다고 생각했는데, query와 lint 시에 어떠한 결과가 될 것인지에 대해서도 써야하는 숙제(?)를 안게 되었다.
1. 3단계 지식체계론의 구체적 검증을 위한 테스트용 LLM-WIKI 구축
이제 llm-wiki-test1을 통해 3단계 지식체계론을 검증하고자 한다.
먼저 llm-wiki-PRD.md 파일을 통해 llm 위키를 구축한다.
현재 D:\03Gpters\llm-wiki-test1\llm-wiki-PRD.md에 위치한다.
D:\03Gpters\llm-wiki-test1\llm-wiki-PRD.md 문서를 읽고 이 문서의 내용에 따라 llm wiki를 만들어줘
완료했습니다. 생성/수정 위치는 전부 D:\03Gpters\llm-wiki-test1\llm-wiki 안입니다. D:\03Gpters\research_harness는 원본 자료 확인용으로 읽기만 했고 쓰지 않았습니다. 주요 산출물은 다음입니다. - llm-wiki/index.md: 전체 목차 - llm-wiki/sources/source-index.md: Source ID 관리 - llm-wiki/schema/AGENTS.md: LLM 작업 규칙 - llm-wiki/wiki/overview.md: LLM Wiki 전체 개요 - llm-wiki/wiki/workflows/newsletter-production-harness.md: 뉴스레터 Harness 루프 총 37개 파일을 만들었고, PRD의 Phase 1과 Phase 2 초기 인입 범위까지 반영했습니다. 초기 Source 요약은 SRC-000부 터 SRC-007까지 들어가 있고, 뉴스레터 제작은 입력 스키마, 개선 프롬프트, 품질 체크리스트로 분리했습니다. 검증도 했습니다. index.md의 Obsidian 링크 누락 없음, wiki/ 문서 frontmatter 누락 없음, source_refs의 Source ID 미등록 참조 없음으로 확인됐습니다.
이렇게 llm-wiki 시험판이 생성되었다.
여기에 3단계 지식체계론의 schema를 설정하고자 한다.
› D:\03Gpters\llm-wiki-test1\llm-wiki\정보가 지식으로서 LLM Wiki에 편입되기 위한 3단계 검증 요건.md 파일을 읽고 여기에서 구현하고자 하는 3단계 지식체계론을 본 llm wiki의 schema에 구현해줘
그렇게 하자 llm이 반환한 결과는 다음과 같다.
완료했습니다. 작업은 모두 D:\03Gpters\llm-wiki-test1\llm-wiki 안에서만 했습니다. 구현 핵심은 3단계 지식체계론을 무거운 전면 강제 규칙이 아니라, 공식 지식 편입 후보에 적용하는 얇은 admission schema로 넣은 것입니다. 주요 추가/수정 파일: - llm-wiki/schema/knowledge-admission.md: 3단계 지식체계론 본 schema - llm-wiki/schema/claim-template.md: claim 단위 검토 템플릿 - llm-wiki/schema/AGENTS.md: Ingest/Query/Lint에 3단계 검증 규칙 반영 - llm-wiki/schema/page-template.md: knowledge_review frontmatter 추가 - llm-wiki/schema/lint-checklist.md: 확증가능성/answer_policy 점검 항목 추가 - llm-wiki/wiki/concepts/three-stage-knowledge-system.md: 이론 요약 문서 - llm-wiki/wiki/reviews/knowledge-review-log.md: 지식 편입 심사 이력 - llm-wiki/wiki/reviews/contradiction-register.md: 충돌 claim 등록부 - llm-wiki/wiki/reviews/weak-confirmability-register.md: 확증가능성 약한 claim 등록부 또 원문을 SRC-008로 llm-wiki/sources/source-index.md에 등록했고, llm-wiki/index.md와 llm-wiki/log.md도 갱신했습니다. 검증 결과 index.md 링크 누락 없음, source_refs 미등록 Source ID 없음, wiki/ 문서 frontmatter 누락 없음으로 확인했습니다. 지식유형론 부분은 원문에서도 별도 이론으로 예고되어 있어서 이번 구현에는 넣지 않고 3단계 지식체계론만 반영했습니다.
이렇게 3단계 지식체계론이 llm wiki에 반영됐다. 이제 ingest, query, lint를 통해 이 스키마가 제대로 작동하는지 살펴보면 된다.
그런데 문제가 생겼다. 나의 원자료가 어떤 폴더에 있어야 하는지를 설정하지 않은 것이었다. 그래서 나의 raw material이 어디에 위치해야 ingest가 될 수 있는지를 mermaid나 ASCII그램과 같은 시각적 자료로 표시해달라고 했다.
그러자 LLM은 다음과 같이 답했다.
현재 구현 기준으로는 원래 raw material은 여기입니다: D:\03Gpters\llm-wiki-test1\llm-wiki\sources\ 세부 배치는 이렇게 보면 됩니다. llm-wiki/ sources/ # 원본 자료 위치 docs/ # PDF, 강의자료, 일반 문서 transcripts/ # 전사본, 회의록 web/ # 웹 클리핑, 기사 저장본 attachments/ # 민감하지 않은 비미디어 첨부파일 _private/ # 기본 ingest 제외 media/ # 이미지, 동영상 visual-references/ # 사용자가 명시한 시각 참고자료 secrets/ # API Key 등 identifiers/ # 일련번호, 식별자 wiki/ # LLM이 정리한 지식 schema/ # LLM이 따를 규칙 members/tearess/ # 개인 메모, 초안, 아이디어 즉, PDF나 문서 원본은 sources/docs/, 회의록이나 전사본은 sources/transcripts/, 웹에서 긁은 글은 sources/web/에 두면 됩니다. 이미지, 동영상, API Key, 일련번호는 일반 sources/가 아니라 _private/ 쪽입니다. 다만 기존처럼 다른 폴더에 이미 원본이 있으면 꼭 복사하지 않아도 됩니다. llm-wiki/sources/source-index.md에 경로만 Source ID로 등록해도 됩니다.
이런 식으로 원본 자료는 sources에 위치하도록 하고 있다.
그렇다면 sources 폴더에 위치한 자료는 ingest 후에도 해당 자료가 있던 폴더에 그대로 위치하게 된다.
그렇게 되면 sources 폴더(하위폴더 포함)에 위치한 자료는 ingest된 자료와 ingest되기 전의 자료가 혼재한 상태에 있게 된다.
예를 들어 sources/docs/강의자료.pdf를 ingest하면: 1. 원본 강의자료.pdf는 sources/docs/강의자료.pdf에 그대로 둠 2. llm-wiki/sources/source-index.md에 SRC-009로 등록 3. wiki/source-summaries/SRC-009-강의자료.md 생성 4. 필요한 개념은 wiki/concepts/, 절차는 wiki/workflows/, 결정사항은 wiki/decisions/에 반영 5. llm-wiki/index.md와 llm-wiki/log.md 갱신
그래서 inbox를 만들어서 inbox에 있는 자료를 ingest시키고, ingest시킨 원본은 sources 폴더로 옮기도록 했다.
그렇게 해서 llm-wiki의 프로세스가 바뀌었다.
llm-wiki/ inbox/ # 미처리 raw material 대기열 docs/ transcripts/ web/ attachments/ sources/ # ingest 완료 원본 보관소 docs/ transcripts/ web/ attachments/ source-index.md wiki/ # 컴파일된 지식 schema/ # 운영 규칙 핵심 변경은 이겁니다. 사용자: inbox/에 원본 투입 LLM: 민감자료 여부 확인 LLM: ingest 가능한 원본을 sources/로 이동 LLM: source-index.md에 Source ID 등록 LLM: wiki/source-summaries/ 작성 LLM: 3단계 지식체계론 검토 LLM: wiki 문서 컴파일 LLM: index.md + log.md 갱신
2. 테스트용 LLM-Wiki에 시험용 문서 생성
이제 inbox에 원본을 투입하면 3단계 지식체계론을 검토하여 wiki 문서가 컴파일될 것이다.
검증이 가능하도록 obsidian에서 llm-wiki를 새로운 볼트로 열어 inbox에 새 파일들을 생성했다.
한꺼번에 많은 자료를 넣으면 역추적하기가 어려울 수 있으므로 간략한 문서자료 위주로 넣었다.
넣은 자료는 1. 서시(윤동주) 2. 영주 부석사 무량수전에 관한 나무위키의 글 3. 세종대왕에 대해 작성한 글로 이 글의 내용은 다음과 같다.
1. 세종대왕은 잘 생겼다
2. 세종대왕은 존경받을만 하다.
3. 세종대왕은 조선의 제4대 왕이다.
4. 세종대왕은 한글을 창제했다.
5. 세종대왕은 아이패드를 집어던지셨다.
6. 세종대왕은 단종의 아버지이다.
7. 세종대왕의 업적은 널리 알려져야 한다.
8. 모든 한국 사람들은 세종대왕을 추앙해야 한다.
3. ingest 수행
이제 이 3개의 문서를 ingest하겠다.
지금 inbox/docs 폴더에 있는 문서를 ingest해
LLM이 다음과 같이 반응한다.
• inbox/docs에는 3개 Markdown 문서가 있고 sources/docs는 비어 있습니다. 이제 원문 내용을 읽고, 각 문서별 Source 요약과 필요한 위키 문서를 만들겠습니다. • 이 3개는 성격이 다릅니다. 서시.md는 문학 원문이라 저작권/인용 위험이 있고, 세종대왕.md는 참/거짓/의견/시대착오 claim이 섞여 있으며, 영주 부석사 무량수전.md은 역사·문화재 claim 위주입니다. 3단계 지식체계론을 적용해 단정 가능한 것과 보류/반박할 것을 분리하겠습니다. • 원본 3개를 sources/docs로 이동했습니다. 이제 SRC-009부터 SRC-011까지 등록하고, 각 자료의 요약 및 관련 개념 문서를 생성하겠습니다. 잘못되었거나 주관적인 claim은 정식 지식으로 단정하지 않고 answer_policy로 제한합니다.
이렇게 하여 inbox/docs에 있던 원본은 ingest되어 sources/docs로 이동했다. inbox/docs에는 해당 원본들이 없어진 것을 확인했고, 같은 내용의 원본들이 sources/docs로 이동한 것을 확인할 수 있었다.
4. ingest 결과
ingest는 성공적으로 완료됐다. 필자가 의도적으로 넣은 윤동주의 서시 전문, 그리고 부석사 무량수전에 대한 사실과 평가가 섞인 나무위키 본문, 마지막으로 세종대왕에 대한 8가지 짤막한 문장은 각각 다음과 같이 컴파일되었다.
여기서 해당 내용을 모두 본문에 수록하기에는 양이 많으므로 여기서는 해당 내용의 핵심을 요약해서 수록하고자 한다.
LLM은 일단 각 원문을 읽고 성격을 분류했다.
서시.md: 문학 원문. 원문 재인용/저작권 위험 주의.
세종대왕.md: 사실, 의견, 시대착오, 오류 claim이 섞인 메모.
영주 부석사 무량수전.md: 문화재·건축사 claim. 일부 평가는 해석으로 한정.
필자의 의도는 '서시'와 같은 문학작품에게도 과연 llml이 3단계 지식체계론에 따라 검증을 거칠 것인지, 그리고 '영주 부석사 무량수전'과 같은 사실과 평가가 혼재된 문서에 대해 어떻게 처리할지, 마지막으로 세종대왕에 대한 추상적 평가, 사실 판단, 잘못된 사실, 당위성 주장 등이 있는 경우 LLM이 어떻게 처리할지를 추적하는 것이었다.
가. 서시
서시에 대해, LLM은 서시의 제목과 본문 내용만으로도 이것이 문학작품임을 파악하고 문학작품으로 분류하여 다음과 같이 정리했다.
# 서시
## 한 줄 요약
`SRC-009`는 `서시`라는 제목의 한국어 시 원문 자료이며, 위키에서는 원문 반복 복제보다 자료 관리와 분석 원칙을 우선한다.
## 핵심 내용
- `SRC-009`는 짧은 한국어 시 원문으로 구성되어 있다.
- 문학 텍스트는 원문 전체를 위키 본문에 반복 복제하지 않는다.
- 분석이 필요하면 짧은 근거 구절과 해석 범위를 분리한다.
- 저자, 창작 시기, 문학사적 의의는 별도 출처가 추가될 때 공식 claim으로 편입한다.
따라서 별도의 3단계 지식체계론에 맞춰 분석했지만, 서시의 내용을 이루는 각 문장을 분해하지 않았고
- 원문 전체나 긴 구절을 wiki 본문에 반복 복제하지 않는다.
- 저자, 발표 시기, 문학사적 의미는 현재 Source만으로 확정하지 않는다.
는 내용을 주의사항에 스스로 반영했다.
3단계 지식체계론이 서시.md를 분석한 결과는 다음과 같다.
knowledge_review: applies: light typicality: pass coherence: coherent confirmability: strong answer_policy: assert_with_citation reason: "파일명과 원문 형식이 claim을 직접 뒷받침한다."
즉, 3단계 지식체계론을 light로 적용했고, 1단계인 지식요건해당성은 pass했으며, 정합성도 만족시켰고, 확증가능성은 strong으로 평가했다. 따라서 인용이 있으면 확정적으로 단언(assert_with_citation)할 수 있는 성격의 지식으로 분류됐다. 그 이유는 "파일명과 원문 형식이 claim을 직접 뒷받침한다"는 것이기 때문이다.
생각해보면, 윤동주의 서시라는 시가 문학작품으로 존재한다는 사실은 지식으로서의 형식적 요건도 충족할 뿐 아니라, 전체 지식 체계에도 부합하고, 따라서 인용의 근거만 확보되면 확정적으로 주장할 수 있는 지식에 편입된 것이다.
나. 영주 부석사 무량수전
영주 부석사 무량수전은 나무위키에 있는 내용 중 첫번째 단락의 설명을 그대로 가져온 문서이다.
이에 대해 LLM은 아래와 같이 요약했다.
# 영주 부석사 무량수전
## 한 줄 요약
`SRC-011`은 영주 부석사 무량수전의 시대, 지정, 연대 추정, 건축미 평가를 다루는 문화재 메모다.
## 핵심 내용
- 영주 부석사 무량수전을 고려 시대 건축물로 설명한다.
- 1962년 국보 제18호 지정 claim이 있다.
- 봉정사 극락전과의 연대 비교는 건립 연대가 추정에 의존한다는 점을 함께 표시해야 한다.
- 1376년 중수 기록과 전통 건물의 수리 주기를 근거로 건립 시기를 추정한다.
- 건축미 평가는 사실 claim이 아니라 해석 claim으로 다룬다.
여기에는 claim이 있으므로 LLM은 앞의 서시와 달리 이에 대해 claim 처리라는 단락으로 별도로 처리했다.
Claim
처리
경북 영주시 부석사 소재
출처와 함께 사용 가능
고려 시대 건축물 추정
추정 표현 유지
국보 제18호 지정
공식 출처 보강 권장
봉정사 극락전과 연대 비교
논쟁/추정으로 표시
형태·비례미 평가
평가 또는 해석으로 표시
이에 대한 source-summaries의 항목을 보면 좀 더 자세히 나타난다.
knowledge_review: applies: light typicality: pass coherence: presumed confirmability: moderate answer_policy: qualify reason: "자료가 구체적인 문화재 claim을 제공하지만, 현재는 단일 local source이므로 공식 출처 보강 전에는 범위를 한정해 사용한다."
즉, 여기에는 3단계 지식체계론을 light로 적용했고, 1단계 지식요건해당성은 pass이고, 정합성은 앞의 서시가 정합성을 갖춘(corehent)것과 달리 추정(presumed)되며, 확증가능성(comfirmability)는 중간 정도임을 알 수 있다. 따라서 답변 정책도 qualify로 이는 "자료가 구체적인 문화재 claim을 제공하지만, 현재는 단일 local source이므로 공식 출처 보강 전에는 범위를 한정해 사용한다."는 것이다.
Claim
유형
3단계 판단
answer_policy
부석사 무량수전은 경북 영주시 부석사에 있다
fact
source 직접 근거, 추가 공식 출처 필요
assert_with_citation
부석사 무량수전은 고려 시대 건축물로 추정된다
historical_fact
추정 claim이므로 시점·범위 한정 필요
qualify
1962년 국보 제18호로 지정되었다
historical_fact
구체적 claim, 공식 출처 보강 권장
assert_with_citation
봉정사 극락전과 연대 비교 논쟁이 있다
relation
source 직접 근거, 논쟁 상태 표시 필요
qualify
무량수전은 형태와 비례미가 뛰어나다
interpretation
건축 평가 claim
mention_as_view
즉, 주장의 유형에 따라 유형과 answer_policy가 다양하게 구분되는 것을 볼 수 있다.
특히 추정되는 것과 논쟁이 있는 문장은 단언하지 않고 잠정적으로 사용해야 함을 알 수 있으며, '뛰어나다'와 같은 평가는 견해로 소개되도록 정해놓았음을 알 수 있다.
다. 세종대왕에 대한 문장들
이것은 필자가 3단계 지식체계론이 작동되는 것을 테스트하기 위해 임의로 넣은 8개의 문장이다. 앞에서도 언급했지만 다음의 8개의 문장으로 이루어져 있다.
1. 세종대왕은 잘 생겼다
2. 세종대왕은 존경받을만 하다.
3. 세종대왕은 조선의 제4대 왕이다.
4. 세종대왕은 한글을 창제했다.
5. 세종대왕은 아이패드를 집어던지셨다.
6. 세종대왕은 단종의 아버지이다.
7. 세종대왕의 업적은 널리 알려져야 한다.
8. 모든 한국 사람들은 세종대왕을 추앙해야 한다.
LLM이 이를 요약한 내용은 다음과 같다.
summary_l0: "세종대왕 claim 검증 노트"
summary_l1: "이 문서는 SRC-010의 세종대왕 관련 claim을 3단계 지식체계론으로 분류한다. 사실로 사용할 수 있는 claim, 의견으로만 소개할 claim, 정합성에서 탈락해 답변 근거로 쓰지 않을 claim을 구분한다. 현재 자료는 단일 메모이므로 역사적 사실 claim은 향후 신뢰 출처로 보강하는 것이 좋다."
각각의 claim에 대해서는 다음과 같이 처리했다.
원문 claim 요지
처리
외모 평가
주관적 평가. 사실로 단정하지 않음
존경받을 만하다는 평가
의견으로만 소개
조선의 제4대 왕
역사적 사실 claim. 공식 출처 보강 권장
한글 창제
역사적 사실 claim. 공식 출처 보강 권장
아이패드를 집어던졌다는 주장
시대착오 claim. 답변 근거로 사용 금지
단종의 아버지라는 주장
오류 claim. 답변 근거로 사용 금지
업적이 알려져야 한다는 주장
규범적 의견
모든 한국인이 추앙해야 한다는 주장
과잉 일반화된 규범적 의견
세종대왕 문서를 3단계 지식체계론은 어떻게 적용했을까? 다음에 그 예시가 있다.
knowledge_review: applies: strict typicality: pass coherence: conflicted confirmability: moderate answer_policy: qualify reason: "자료 안에 사실 claim, 의견 claim, 시대착오 claim, 오류 claim이 섞여 있어 claim별 분리 검토가 필요하다."
여기서는 서시, 영주 부석사 무량수전과 달리 3단계 지식체계론을 엄격(strict)하게 적용했음을 알 수 있다. 일단 지식요건해당성은 pass했으나 정합성에서 conflicted되는 문제가 나왔다. 즉, 정합성에 부합하지 않고 불일치 내지는 충돌되는 문제가 발생한 것이었다. 확증가능성은 중간정도로 나왔다. 그리고 answer_policy는 qualify로 나왔는데, 이유는 "자료 안에 사실 claim, 의견 claim, 시대착오 claim, 오류 claim이 섞여 있어 claim별 분리 검토가 필요하다."는 것이었다.
아마도 8개의 claim 모두가 일률적으로 정합성을 갖추지 못했다거나, 또는 모든 claim의 확증가능성이 중간 정도라는 의미는 아니고, 서로 다른 유형의 claim이 혼재되어 있다보니 일률적으로 저렇게 평가한 것으로 생각된다. 핵심요약은 다음과 같다.
## 핵심 요약
- 세종대왕에 관한 8개 claim이 번호 목록으로 기록되어 있다.
- 역사적 사실, 주관적 평가, 규범적 주장, 시대착오적 주장, 오류로 보이는 주장이 섞여 있다.
- 정식 지식으로 편입할 때는 claim별로 분리해 answer_policy를 달리해야 한다.
그리고 각 claim에 대한 처리는 아래와 같다.
Claim
유형
3단계 판단
answer_policy
세종대왕은 잘 생겼다
interpretation
주관적 평가, 근거 없음
mention_as_view
세종대왕은 존경받을만 하다
interpretation
평가 claim
mention_as_view
세종대왕은 조선의 제4대 왕이다
fact
정합성 높음, 추가 신뢰 출처 필요
assert_with_citation
세종대왕은 한글을 창제했다
historical_fact
정합성 높음, 추가 신뢰 출처 필요
assert_with_citation
세종대왕은 아이패드를 집어던지셨다
fact
시대착오로 정합성 탈락
do_not_assert
세종대왕은 단종의 아버지이다
fact
일반 역사 지식과 충돌하는 오류 claim
do_not_assert
세종대왕의 업적은 널리 알려져야 한다
interpretation
규범적 평가
mention_as_view
모든 한국 사람들은 세종대왕을 추앙해야 한다
interpretation
과잉 일반화된 규범 주장
mention_as_view
여기서 보면, 일단 LLM은 claim의 유형을 fact와 interpretation으로 분류하고, 그에 따라 판단을 하되, fact의 경우 3단계 지식체계론을 적용하여 정합성을 판단하는 것을 알 수 있다.
다만, 위의 claim 처리표만으로는 3단계 판단이 어떻게 구현됐는지 알기가 어려우므로 다른 자료를 살펴보았다.
LLM은 3단계 지식체계 평가 후 contradiction-register.md에 충돌 claim을 등록하도록 하고 있다.
여기에 기록된 contradiction을 살펴본 결과는 아래와 같다.
## [2026-05-31] conflict-sejong-001
- new_claim: "세종대왕은 아이패드를 집어던지셨다."
- conflicts_with: "세종대왕 생존 시기와 iPad의 현대 기기라는 시간적 정합성"
- source_refs: `SRC-010`
- coherence: rejected
- confirmability: none
- answer_policy: do_not_assert
- treatment: 시대착오 claim으로 보존하되 답변 근거로 사용 금지
- next_review: 필요 없음. 다만 자료 목적이 풍자나 예시인지 사용자가 밝히면 interpretation으로 재분류 가능 ## [2026-05-31] conflict-sejong-002
- new_claim: "세종대왕은 단종의 아버지이다."
- conflicts_with: "일반 역사 지식과 충돌하는 계보 claim"
- source_refs: `SRC-010`
- coherence: rejected
- confirmability: none
- answer_policy: do_not_assert
- treatment: 오류 claim으로 보존하되 답변 근거로 사용 금지
- next_review: 조선 왕실 계보에 대한 공식 출처 ingest 후 correction claim 작성 가능
세종대왕이 아이패드를 집어던지셨다는 것은 시간적 정합성을 갖추지 못한 claim으로 contradiction이 발생한 상황이고, 반면에 "세종대왕이 단종의 아버지"라는 주장은 실체적 역사 지식인 세종대왕이 문종의 아버지이고, 단종의 할아버지라는 사실과 배치되는 사실이므로 정합성을 갖추지 못한 것이다.
둘 다 정합성(coherence)이 rejected됨을 알 수 있다. 또한 confirmability도 없다.
따라서 LLM은 이를 각각 시대착오 claim과 오류 claim으로 보존하되 답변 근거로 사용을 금지하도록 했고, 세종대왕 아이패드 사건은 아예 next review도 필요없지만, 만약 이것이 AI 초창기에 AI의 한계를 나타내는 예시나 풍자로 사용된다는 문맥 속에서는 interpretation으로 재분류될 수 있을 뿐, 현재로서는 주장이 불가능한 지식에 분류된다.
한편, 세종대왕이 단종의 아버지라는 잘못된 사실은 오류 claim이므로 사용이 금지되며, 만약 조선 왕실 계보에 대한 공식 출처가 ingest된 후에 correction claim 작성이 가능하다는 점이 인상적이었다.
다음으로는 확증가능성이 weak인 claim에 대한 내용이다.
여기에는 "세종대왕은 잘 생겼다"와 "모든 한국 사람들은 세종대왕을 추앙해야 한다"는 claim이 해당된다.
LLM은 이를 weak-confirmability-register.md에 별도의 문서를 만들어 저장한다.
여기에 기록된 weak confirmability는 아래와 같다.
## [2026-05-31] weak-sejong-001
- claim: "세종대왕은 잘 생겼다."
- source_refs: `SRC-010`
- confirmability: weak
- answer_policy: mention_as_view
- reason: 주관적 외모 평가이며 근거와 판단 기준이 없다.
- required_action: 사실 claim으로 사용하지 않는다. ## [2026-05-31] weak-sejong-002
- claim: "모든 한국 사람들은 세종대왕을 추앙해야 한다."
- source_refs: `SRC-010`
- confirmability: weak
- answer_policy: mention_as_view
- reason: 규범적·과잉 일반화 주장이다.
- required_action: 사용자의 의견으로만 소개하고 일반 명제로 단정하지 않는다.
이 두 claim은 확증가능성이 weak로 분류된 문서이다. 여기서 필자는 의문이 생겼다. 이것이 3단계 지식체계론을 거친 것으로 생각되는데, 그렇다면 지식요건해당성과 정합성을 갖춘 것이고, 다만 확증가능성만 weak인 상태인지, 아니면 지식요건해당성과 정합성에 대해서는 판단하지 않은 채 확증가능성에 대해서만 판단한 것인지 의문이 들었다.
이것은 좀 더 지식체계를 정교화시키면서 해결해야 할 문제라고 생각됐다. 아니면 그보다 앞서 개인적의 주관적 판단이나 평가가 들어간 문장에 3단계 지식체계론을 적용시키는 것이 타당한지, 만약 적용시키더라도 어느 정도로 적용시켜야 하는지에 대해 고민해야 함을 깨달았다.
어쨌든 LLM은 지식요건해당성과 정합성에 대해서는 침묵한 채, 이것을 해석의 유형으로 판단한 후 weak confirmability로 분류하여 별도로 기록했다.
앞서 세종대왕에 대한 8가지 claim 중 LLM이 interpretation으로 분류한 것은 4개이며 다음과 같다.
Claim
유형
3단계 판단
answer_policy
세종대왕은 잘 생겼다
interpretation
주관적 평가, 근거 없음
mention_as_view
세종대왕은 존경받을만 하다
interpretation
평가 claim
mention_as_view
세종대왕의 업적은 널리 알려져야 한다
interpretation
규범적 평가
mention_as_view
모든 한국 사람들은 세종대왕을 추앙해야 한다
interpretation
과잉 일반화된 규범 주장
mention_as_view
이 중에서 "세종대왕은 존경받을만하다"와 "세종대왕의 업적은 널리 알려져야 한다"는 claim에 대해서는 3단계판단에서 확증가능성을 weak 이하로 보지 않았으나,, 나머지 2개의 interpretation에 대해서는 확증가능성을 weak로 본 것이다.
LLM이 이것을 위와 같이 분류한 이유는 분명히 있을 것인데, 이에 대한 wiki 문서를 모두 뒤져보아도 딱히 그렇게 분류한 근거가 따로 붙어있지는 않았다.
다만, 아마도 LLM은 내재적으로 interpretation을 두 종류로 구분하고 있는 것 같다.
하나는 주관적 주장이라 하더라도 다수의 사람들이나 문헌, 자료들에 의해 지지를 받을 수 있는 주장, 즉 여기서 "세종대왕은 존경받을만 하다"는 것과 "세종대왕의 업적은 널리 알려져야 한다"는 것과, 그런 confirmability가 없거나 낮은 "세종대왕은 잘 생겼다", "모든 한국 사람들은 세종대왕을 추앙해야 한다"를 구분한 것으로 생각된다.
하지만 다음에는 이 confirmability의 grade에 대한 근거도 설시하도록 하면 더욱 더 근거가 탄탄해질 것으로 생각된다.
5. 결론 및 제언
지금까지 필자가 지난 사례게시글에서 언급했던 3단계 지식체계론을 실제로 테스트용 LLM-Wiki에 작게나마 적용한 사례를 풀어보았다.
여기서 들었던 몇 가지 의문에 덧붙여 다른 의문이 생겼다.
만약 3단계 지식체계론이 없는 LLM-Wiki에 동일한 3가지 자료-서시, 영주 부석사 무량수전, 세종대왕-을 넣고 ingest하면 어떤 결과가 있을까?
결과값에 차이가 있을 수도 있고, 결과값에는 차이가 없지만 지금과 같은 분류근거는 없을 수도 있을 것인데, 실제로 이를 직접 구현해서 확인해보고 싶었다. 이것을 그냥 LLM에게 물어보는 것만으로는 LLM이 거짓말을 할 것도 같아서 직접 다시 동일한, 그러나 3단계 지식체계론이 적용되지 않은 날 것 그대로의 llm-wiki를 구축해서 거기서 ingest를 해서 그 결과값을 확인해보고 싶었다.
그래서 다음 사례게시글은 아래와 같은 순서로 작성하고자 한다.
3단계 지식체계론이 적용되지 않은 llm-wiki에서의 ingest 결과
기존 claim과 모순되는 claim이 제기되는 경우 현재의 llm-wiki는 어떻게 처리하는가
기존 claim과 모순되는 claim 제기 시 llm-wiki의 schema로서 "안정력이론"의 적용
"안정력 이론"을 적용하기 위한 전제조건으로서 동일한 문서의 범위를 어떻게 확정할 것인가에 대한 "동일문서이론"
OpenCode 대화 이력 영구 저장을 위한 MCP(Model Context Protocol) 개발기
1. MCP 활용 배경
💡 시도하고자 했던 것과 그 이유
"인터페이스"를 주제로 새로운 기술을 공부하고 구현해 볼 고민을 하던 중, 스터디장님이 공유해주신 MCP(Model Context Protocol) 자료를 접하고 '바로 이거다'라는 확신이 들었습니다.
당시 회사에서 제공하는 AI 툴인 OpenCode를 유용하게 사용하고 있었지만, 한 가지 치명적인 아쉬움이 있었습니다. 이전 대화 내용이나 AI가 제시한 코드 솔루션을 다시 찾을 수 없다는 점이었습니다. 대화 내용이 휘발성으로 사라지다 보니 매번 같은 질문을 반복하거나 기록을 놓치기 일쑤였습니다.
만약 'ChatLog'를 단발성 대화가 아닌, 지속적으로 저장하고 검색할 수 있는 장기 기억(Long-term Memory) 형태로 구축할 수 있다면 이 문제를 완벽히 해결할 수 있을 것 같았습니다. 나아가 이를 성공적으로 구현한다면, 사내 동료들에게 배포하여 업무 생산성을 높이는 훌륭한 모범 사례(Best Practice)가 될 것이라 확신했습니다.
2. MCP 활용을 위한 도구와 방법
🛠️ 문제 해결과 구현 과정
🔍 1단계: OpenCode 대화 데이터 추적 (시행착오)
가장 먼저 OpenCode가 Claude처럼 대화 내용을 내부적으로 jsonl 형태로 저장하는지 확인해야 했습니다. 하지만 시작부터 난관에 봉착했습니다.
로컬 디렉터리 탐색: .opencode 설치 경로와 로그 폴더를 샅샅히 뒤졌으나 대화 로그는 존재하지 않았습니다.
DB 파일 분석: 탐색 끝에 opencode.db 파일을 발견했으나, 테이블 중 오직 content(대화 내용) 테이블만 비어 있는 상태였습니다.
이슈 확인: 확인 결과, 이는 이미 알려진 알려진 오픈소스 이슈였습니다 (GitHub Issue #10592).
💡 2단계: 해결의 실마리, /export와 Hook
퇴근길에 Claude와 집요하게 대화를 나누며 상황을 설명한 끝에 결정적인 힌트를 얻었습니다. 바로 OpenCode의 내장 명령어인 /export 기능이었습니다.
출근하자마자 테스트해 보니 대화 내용이 .md 파일로 정상 저장되는 것을 확인했습니다.
하지만 터미널을 실행한 현재 디렉터리에만 수동으로 저장되는 한계가 있었습니다. 자동으로 로그를 수집하기에는 역부족이었습니다.
⚙️ 3단계: TypeScript Hook 기반 자동 저장 구현
자동화를 위해 Claude가 제시한 Hook 개념을 도입했습니다. 대화가 끝나는 시점을 감지해 파일로 자동 저장하는 TypeScript 플러그인을 작성하고 config.json에 연동했습니다.
opencode.json 설정
JSON
{ "$schema": "https://opencode.ai/config.json", "plugin": ["./plugins/save-messages.ts"]
}
결과: 드디어 원하던 로컬 경로에 대화 로그가 자동으로 저장되기 시작했습니다!
추가적으로 원하는 형식으로 나오게 하기까지 과정이 좀 있었지만
일단 이제 본격적으로 chatlog 가이드로 mcp 를 만들기 시작 했습니다.
🏠 4단계: 환경의 전환
사내 LLM을 활용해 MCP 인프라를 구축하려 했으나, 내부 모델의 성능 한계로 인해 Tool Call이 실패하거나 엉뚱한 답변을 내놓는 문제가 발생했습니다.
결국 퇴근 후 집에서 Claude를 활용해 본격적인 개발을 이어가기로 결정했습니다.
집 PC에 OpenCode를 새로 설치하고 회사와 동일한 환경을 셋팅했습니다.
Hook을 재설정하고, 수집된 로그를 분석하기 좋은 jsonl 규격으로 변환해 주는 TypeScript 코드를 고도화했습니다. 이 과정에서 많은 시행착오가 있었지만 결국 원하는 UI 화면에 내 대화 이력이 깔끔하게 출력되는 감격스러운 순간을 맞이했습니다.
🚀 5단계: MCP 서버 등록 및 최종 테스트
구현한 Chat Tracker를 MCP 컴포넌트로 등록하기 위해 opencode.jsonc 설정을 마쳤습니다.
opencode.jsonc MCP 등록 설정
{ "$schema": "https://opencode.ai/config.json", "plugin": ["./plugins/save-messages.ts"], "mcp": { "chattracker": { "type": "remote", "url": "http://localhost:7373/mcp", "enabled": true } }
}
이후 OpenCode 인터페이스를 통해 "과거 이력에 대해 알려줘"라고 요청하자, LLM이 컨텍스트를 정상적으로 이해하고 chattracker MCP 서버와 성공적으로 통신하며 이전 답변을 훌륭하게 찾아주었습니다. (최종 터미널 및 UI 테스트 스크린샷 참고)
3. 결과 및 배운 점
🧠 이번 프로젝트를 통해 배운 점
Hook과 이벤트 핸들러의 명확한 이해: 이번 스터디를 통해 Hook의 메커니즘을 확실하게 정립했습니다. 이를 '이벤트 핸들러' 개념으로 접근하니 구조가 명확해졌습니다.
이벤트(Event): AI와의 대화가 종료되는 시점
핸들러(Handler): 대화 이벤트 데이터(컨텐츠)를 받아 지정된 경로에 파일로 저장하는 로직
⚠️ 주요 시행착오
대화 내용 추출 가시화: OpenCode의 내부 아키텍처 한계로 인해 대화 내용을 파싱하고, 이를 정제된 jsonl 파일로 완벽하게 떨어뜨리는 초기 단계에 가장 많은 시간과 노력을 투자했습니다. 환경 차이(opencode vs Claude)에서 오는 파싱 싱크를 맞추는 것도 까다로운 숙제였습니다.
🔮 앞으로의 계획
사내 검증 및 배포: 집에서 성공적으로 빌드한 이 프로젝트 코드를 다시 회사 환경으로 가져가 정상 동작 여부를 정밀 테스트할 예정입니다.
솔루션 고도화: 발견되는 버그나 예외 상황을 보완하여 안정성을 높인 후, 팀원들과 주변 동료들에게 배포하여 팀 전체의 AI 생산성을 높이는 BP(Best Practice) 도구로 확장하고 싶습니다.
정보가 지식으로 편입되기 위한 기준 설정의 필요성
필자는 Andrej Karpathy의 LLM Wiki를 구축하면서 Karpathy의 이론에 따라 Raw-Wiki-Schema의 구조와 Ingest-Query-Lint의 Architecture를 갖도록 설계했으나 여기에 약간의 변경을 가하여 Raw를 Inbox와 Sources로 나누고, Wiki 외에 작업의 결과물인 Project와 다른 팀원들의 작업공간인 Person으로 나눴다. 그리고 개인정보가 저장되는 Private 폴더와 마지막으로 Schema 폴더로 구성했다.
카파시가 제안한 구조가 분화되기는 했으나 본질적으로는 차이가 없다. 다만, Inbox에 있는 자료는 schema에서 정한 규칙에 따라 ingest되어 원본 그대로 저장되는 한편, wiki를 구성하도록 한 것이다.
그렇다면 이제는 어떤 원칙에 따라 정보를 지식으로 편입시킬 것인지가 고민되었다.
여기서 3단계 지식체계론을 세웠다.
3단계 지식체계론
3단계 지식체계론은 다음과 같다.
지식요건해당성
→ 이것이 LLM Wiki의 지식 단위로 성립할 형식적 요건을 갖추었는가?
정합성
→ 형식은 맞지만 이것이 전체 지식질서·정책·출처규칙과 모순·충돌하지 않는가?
확증가능성
→ 이것이 출처·증거·검토·반대증거 검토를 통해 어느 정도 확증될 수 있는가?
즉, 어떤 지식이 wiki로 편입되기 위해서는 일단 지식요건해당성을 갖춰야 하며, 정합성과 확증가능성이 있어야 한다는 것이다.
1. 1단계 : 지식요건해당성 = "지식 후보의 형식 요건"
이 단계는 내용의 참거짓을 최종 판단하는 단계가 아니라, wiki에 넣을 수 있는 단위인지 확인하는 단계이다. aw source에서 추출된 정보가 미리 정의한 claim/page type에 맞는지를 보는 것이다.
예를 들어 LLM Wiki에서 모든 지식 단위를 다음 중 하나로 분류하게 한다.
claim_types: - fact # 단순 사실 - definition # 개념 정의 - relation # A가 B에 영향을 줌, A는 B의 하위개념 등 - timeline # 시점이 중요한 사건 - decision # 회의/프로젝트 결정 - interpretation # 해석, 논평, 추론 - question # 아직 답이 없는 쟁점
그리고 모든 claim은 최소한 아래 필드를 갖춰야 한다.
typicality_requirements: subject: required predicate: required object: required source_id: required evidence_span: required claim_type: required time_scope: optional_but_recommended domain_scope: optional_but_recommended
이 단계에서 떨어지는 정보는 보통 이런 것들이다.
출처가 없는 주장
subject/predicate/object가 분리되지 않는 문장
요약인지 사실인지 해석인지 불명확한 문장
같은 문장 안에 여러 주장이 섞여 있는 경우
날짜나 범위가 중요한데 scope가 없는 경우
처리 규칙은 간단하다.
지식요건해당성 없음 → wiki에 본문 claim으로 편입하지 않음
대신:
raw extraction note에 보관하거나
pending_claims.md로 이동하거나
사람이 다시 분해하도록 표시
2단계 : 정합성 = “전체 지식질서와의 충돌 검사”
지식요건에 해당한다고 해서 바로 wiki에 넣으면 안 될 것이다. 지식요건에 해당한다는 것은 사실판단·잠정판단이고, 정합성 판단을 거쳐 확정적 평가를 받는다.
예를 들어 "태양이 지구 주위를 돈다"라는 정보가 있다고 하자. 이 정보는 형식적으로는 지식의 요건을 갖추었기 때문에 1단계의 지식요건해당성을 갖춘 정보이다. 하지만 전체 지식질서를 볼 때, 명백히 모순되는, 잘못된 내용이다. 이것을 무분별하게 wiki에 편입하게 되면 wiki는 잘못된 지식으로 오염되게 된다.
따라서 "태양이 지구 주위를 돈다"는 정합성 단계에서 탈락하게 된다.
검사 항목은 다음과 같다.
wrongfulness_checks: contradiction: description: "기존 wiki claim과 충돌하는가?" action_if_true: "disputed 상태로 저장하고 양쪽 출처를 병기" supersession: description: "더 최신 source가 이 claim을 대체했는가?" action_if_true: "superseded 상태로 전환" privacy_or_security: description: "개인정보, 비밀, 내부 보안정보를 부적절하게 노출하는가?" action_if_true: "redact 또는 restricted namespace로 이동" copyright_or_quote_risk: description: "원문을 과도하게 복제하는가?" action_if_true: "요약으로 전환하고 짧은 evidence span만 유지" scope_mismatch: description: "특정 문맥의 주장을 일반 명제로 과잉 확장했는가?" action_if_true: "domain_scope/time_scope 추가" source_hierarchy: description: "낮은 신뢰도의 source가 높은 신뢰도의 source와 충돌하는가?" action_if_true: "confidence 하향 또는 disputed 처리"
여기서 정당화사유에 해당하는 것을 schema에 둘 수 있다. 이렇게 함으로써 정합성 판단의 근거를 강화할 수 있다.
justification_tags: - directly_sourced # raw source에 직접 근거 있음 - human_approved # 사용자가 명시적으로 승인 - clearly_marked_opinion # 사실이 아니라 의견/해석으로 표시 - redacted # 민감정보 제거됨 - limited_quote # 인용 범위 최소화 - domain_scoped # 적용 범위가 제한되어 있음 - time_scoped # 특정 시점 기준임
예를 들어 어떤 claim이 기존 문서와 충돌하지만 양쪽 모두 출처가 있으면 삭제하지 말고 이렇게 저장한다.
stage_2_wrongfulness: passed: true status: disputed contradiction_with: - claim-2026-05-20-004 justification: - directly_sourced - clearly_marked_conflict required_page_treatment: - "본문에서 단정하지 말 것" - "양쪽 출처와 날짜를 병기할 것" - "query 답변 시 disputed로 표시할 것"
이렇게 하면 LLM Wiki의 lint 작업과도 잘 맞는다. LLM Wiki schema의 일반적인 lint는 contradictions, stale claims, orphan pages, missing cross-references 등을 점검하도록 설계된다.
3. 3단계 : 확증가능성 = "이 지식이 어느 정도로 확증될 수 있는가"
지식요건에 해당하고 정합성을 갖춘 지식이라 하더라도 그 지식이 증거에 의해 뒷받침될 수 있는 정도는 차이가 있을 것이다. 어떤 지식은 진리 또는 공리여서 매우 높은 확증가능성을 가지고 있음에 비해, 어떠 지식은 옳기는 하지만 확증되기에는 약한 지위를 가질 수 있다. 다만, 확증가능성이 아예 없는 지식은 비록 앞의 두 요건을 갖추었다 하더라도 지식으로 편입되어서는 안 될 것이다.
사실 이것은 원래 "주장책임성"이라는 용어를 사용했다. 이는 정합성이 인정된 지식을 LLM Wiki가 어느 범위와 강도로 주장할 수 있는지 판단하는 것이다. 그런데 LLM 입장에서는 해당 지식을 "주장"하는 것일지 몰라도 사용자인 필자의 입장에서는 LLM의 주장을 보는 입장이기 때문에 "주장책임성"이라는 용어가 와닿지 않았다. 따라서 LLM 입장에서의 "주장책임성"을 사용자 입장에서의 "확증가능성"으로 바꾸도록 했다.
원래 LLM Wiki에서의 "주장책임성"의 내용은 아래와 같았다.
이 지식을 누가 주장하는가?
어떤 출처에 근거하는가?
얼마나 확실한가?
추론이 많이 개입되었는가?
검토되었는가?
답변에 단정적으로 써도 되는가?
필자는 이를 "확증가능성"으로 바꾸었지만, 내용에 있어서 달라진 것은 없다. 보는 관점에서의 차이일 뿐이다.
여기서 중요한 것은 정합성과 확증가능성은 분명 다르다는 것이다.
개념만으로는 쉽게 이해하기 어려울 수 있으므로 예를 들어 설명하겠다.
“A 논문은 X 방법이 효과적이라고 주장한다.”
위와 같은 정보가 있다.
이 정보는 형식적으로 잘 구성되어 있고, 기존 지식과 충돌하지 않을 수 있다.
그러면
지식요건해당성 있음
정합성 있음
이다.
하지만 그 논문이 낮은 신뢰도의 preprint이고, 다른 검증이 없고, LLM이 논문 내용을 크게 추론해서 요약했다면?
그 경우에는:
확증가능성 낮음
인 것이다.
그래서 답변에서는 이렇게 말해야 한다.
“X 방법이 효과적이다.”
이런 식의 단정적 표현이 아니라,
“해당 논문은 X 방법이 효과적이라고 주장하지만, 아직 검증 수준은 제한적이다.”
라고 해야 할 것이다.
확증가능성의 판단 요소
확증가능성은 다음 요소로 판단하는 것이 좋다.
확증가능성: 출처접근성: question: "원자료 또는 신뢰 가능한 출처를 확인할 수 있는가?" 증거직접성: question: "출처가 해당 claim을 직접 뒷받침하는가?" 증거충분성: question: "하나의 약한 근거가 아니라 충분한 근거가 있는가?" 독립확인성: question: "서로 독립된 자료들이 같은 결론을 지지하는가?" 반대증거검토: question: "충돌하는 자료나 반대 견해가 검토되었는가?" 추론개입도: question: "LLM의 해석이나 추론이 얼마나 개입되었는가?" 재현가능성: question: "경험적 명제라면 관측·실험·계산으로 재확인 가능한가?" 문헌확인성: question: "법학·역사·철학 명제라면 원전·판례·문헌으로 확인 가능한가?" 시점적합성: question: "특정 시대에는 맞지만 현재 사실로는 틀린 것은 아닌가?" 범위한정성: question: "어느 도메인, 시대, 법체계, 학설 안에서만 확증되는가?"
이렇게 하면 확증가능성은 단순한 “출처 있음”보다 훨씬 강한 개념이 된다.
# 확증가능성의 단계
확증가능성은 5단계 정도로 나누는 게 좋다.
confirmability_levels: none: label: "확증불가" meaning: "출처가 없거나, 출처가 claim을 뒷받침하지 않음" answer_policy: "do_not_assert" weak: label: "약한 확증가능성" meaning: "출처는 있으나 간접적이거나 견해 수준임" answer_policy: "mention_as_view" moderate: label: "중간 확증가능성" meaning: "신뢰 가능한 근거가 있으나 범위 제한이나 반대 견해가 있음" answer_policy: "qualify" strong: label: "강한 확증가능성" meaning: "직접 출처와 충분한 근거가 있고 중대한 충돌이 없음" answer_policy: "assert_with_citation" settled: label: "정착된 확증가능성" meaning: "현재 지식체계 안에서 안정적으로 받아들여지는 수준" answer_policy: "assert"
여기서 중요한 건 확증가능성은 절대적 진리 선언이 아니라는 점이다.
settled라고 해도 “영원히 참”이라는 뜻이 아니라, 현재의 LLM Wiki 지식질서 안에서 충분히 확증되어 안정적으로 사용할 수 있다는 뜻이다.
확증가능성의 결과값
확증가능성은 단순히 “있다/없다”로 나누기보다, LLM Wiki에서는 확증의 강도로 나누는 것이 좋다.
answer_policy: assert: meaning: "단정적으로 주장 가능" example: "A는 B이다." assert_with_citation: meaning: "출처를 붙이면 단정 가능" example: "자료 X에 따르면 A는 B이다." qualify: meaning: "조건부·유보적으로만 주장 가능" example: "A는 B로 볼 수 있으나, 적용 범위는 제한된다." mention_as_view: meaning: "하나의 견해로만 소개 가능" example: "일부 견해는 A를 B로 본다." mention_as_disputed: meaning: "논쟁 중인 주장으로만 소개 가능" example: "A가 B인지에 대해서는 견해가 갈린다." do_not_assert: meaning: "답변 근거로 사용 금지" example: "출처 부족 또는 검토 미완료"
이렇게 하면 세 번째 단계는 단순한 탈락 심사가 아니라, 지식의 발화 강도를 정하는 단계가 된다.
확증가능성 결여 사유
LLM Wiki에서는 확증가능성 결여 사유를 둘 수 있다.
예를 들면 다음과 같다.
확증가능성_결여사유: - source 없음 - source는 있으나 evidence span 없음 - source가 claim을 직접 뒷받침하지 않음 - LLM의 추론이 과도하게 개입됨 - confidence가 낮음 - 오래된 정보인데 time_scope가 없음 - 정합성은 있지만 minority view임을 표시하지 않음 - human review가 필요한데 검토되지 않음 - privacy, license, confidentiality 문제로 답변에 사용 불가 - claim은 맞지만 사용자의 질문 범위를 넘는 과잉 일반화 위험이 큼
여기서 중요한 점은, 확증가능성이 없다고 해서 반드시 wiki에서 삭제해야 하는 것은 아니라는 것이다.
대신 상태를 나눈다.
확증가능성 충분 → assert
확증가능성 일부 있음 → qualify
확증가능성 낮음 → mention_as_view
확증가능성 없음 → do_not_assert / pending
4. 천동설과 지동설을 예시로 3단계 지식체계 설명
1. 3단계 지식체계론의 기본 구조
1. 지식요건해당성 → 이 정보가 LLM Wiki에 들어갈 수 있는 지식 단위인가? 2. 정합성 → 이 정보가 전체 지식질서와 충돌하지 않는가? 3. 확증가능성 → 이 정보는 어느 정도로 확증성(신뢰성)을 가진 정보인가?
여기서 핵심은 1단계와 2단계가 다르다는 점이다.
천동설도 문장 구조만 보면 충분히 “지식요건”을 갖출 수 있다. 예를 들어:
“프톨레마이오스 체계는 지구를 우주의 중심으로 본다.”
이 문장은 주어, 술어, 목적어, 이론명, 출처, 시대 범위를 가질 수 있다. 따라서 지식요건해당성은 인정된다.
하지만 다음 문장은 다르다.
“현재 실제 우주의 중심은 지구이다.”
이 문장도 형식상으로는 claim이다. 그러나 현대 천문학 지식질서 안에서는 지동설·현대 태양계 모델과 충돌한다. 따라서 정합성 단계에서 문제가 생긴다.
2. 예시 1: “지구는 우주의 중심이다”
A. 현재 자연과학 명제로 저장하는 경우
claim: text: "지구는 우주의 중심이다." claim_type: fact domain_scope: astronomy time_scope: present
1단계: 지식요건해당성
이 문장은 형식적으로는 지식 단위가 될 수 있다.
주어: 지구
술어: ~이다
객체: 우주의 중심
claim_type: fact
domain_scope: astronomy
time_scope: present
따라서 1단계에서는 이렇게 판단한다.
지식요건해당성: passed: true reason: "주어, 술어, 객체, 도메인, 시점이 특정되어 있음"
즉, 형식적으로는 지식처럼 생겼다.
2단계: 정합성
문제는 여기서 발생한다.
현대 천문학 체계에서 코페르니쿠스적 태양중심 모델은 지구와 행성이 태양 주위를 돈다는 방향으로 우주 구조를 설명했고, 현재의 태양계 이해도 지구중심 우주론과는 양립하지 않는다. 코페르니쿠스는 태양을 중심에 놓고 지구가 그 주위를 돈다고 보았으며, 이는 프톨레마이오스적 지구중심 모델과 대립했다.
따라서 이 claim은 현재 자연과학 명제로는 정합성 단계에서 탈락한다.
정합성: passed: false reason: "현대 천문학의 태양계 모델과 충돌함" 정합성_배제사유: - "current_scientific_consensus_conflict" - "outdated_theory_presented_as_current_fact"
3단계: 확증가능성
정합성에서 탈락했기 때문에, LLM Wiki는 이 문장을 현재 사실로 주장하면 안 된다.
확증가능성: level: none answer_policy: do_not_assert_as_fact
따라서 LLM은 답변에서 이렇게 말하면 안 된다.
지구는 우주의 중심입니다.
대신 이렇게 처리해야 한다.
“지구가 우주의 중심이라는 주장은 프톨레마이오스적 천동설의 핵심 전제였지만, 현대 천문학의 현재 사실 명제로는 받아들여지지 않는다.”
B. 같은 문장을 과학사 명제로 저장하는 경우
이번에는 같은 내용을 다르게 저장해보자.
claim: text: "프톨레마이오스 체계는 지구가 정지해 있고 우주의 중심에 있다고 보았다." claim_type: historical_theory domain_scope: history_of_science time_scope: "Ptolemaic astronomy"
이 경우 판단이 완전히 달라진다.
1단계: 지식요건해당성
지식요건해당성: passed: true reason: "이론명, 주장 내용, 역사적 범위가 명확함"
이 claim은 잘 구성된 지식에 해당한다.
2단계: 정합성
이제 이 문장은 현대 과학 명제가 아니라 과학사적 명제이다.
“프톨레마이오스 체계가 지구중심 우주론이었다”는 설명은 프톨레마이오스 체계 자체의 역사적 성격을 설명하는 것이므로, 현대 지동설과 충돌하지 않는다. Britannica도 프톨레마이오스 체계를 지구가 정지해 있고 우주의 중심에 있다는 전제에서 출발한 지구중심 우주론으로 설명한다.
따라서 정합성도 인정된다.
정합성: passed: true reason: "현재 자연과학 명제가 아니라 역사적 이론 설명이므로 현대 천문학과 충돌하지 않음"
3단계: 확증가능성
이 경우에는 LLM이 비교적 강하게 주장할 수 있다.
확증가능성: level: high evidence_quality: direct inference_level: low answer_policy: assert_with_citation
답변에서는 이렇게 말할 수 있다.
프톨레마이오스 체계는 지구가 정지해 있고 우주의 중심에 있다는 전제에서 출발한 지구중심 우주론이었다.
즉, “지구는 우주의 중심이다”는 현재 사실로는 탈락하지만, “프톨레마이오스 체계는 지구를 중심으로 보았다”는 역사적 지식으로는 통과한다.
4. 예시 2: “지구는 태양 주위를 돈다”
이번에는 지동설 claim을 보겠다.
claim: text: "지구는 태양 주위를 돈다." claim_type: fact domain_scope: astronomy time_scope: present
1단계: 지식요건해당성
지식요건해당성: passed: true reason: "주어, 술어, 객체, 도메인, 시점이 명확함"
형식적으로 완전한 claim입니다.
2단계: 정합성
이 claim은 현대 태양계 이해와 충돌하지 않습니다. 코페르니쿠스 체계는 태양을 중심에 놓고 지구와 다른 행성들이 태양 주위를 돈다는 모델로 설명됩니다.
정합성: passed: true reason: "현대 천문학의 태양계 설명과 양립함"
3단계: 확증가능성
이 claim은 답변에서 단정적으로 사용할 수 있다.
확증가능성: level: high answer_policy: assert
다만 LLM Wiki 관점에서는 더 정밀하게는 이렇게 저장하는 편이 좋겠다.
claim: text: "태양계에서 지구는 태양 주위를 공전한다." claim_type: fact domain_scope: astronomy time_scope: present
왜냐하면 “우주의 중심은 태양이다”라고 말하면 현대 우주론과는 부정확해질 수 있기 때문이다. 코페르니쿠스 체계는 역사적으로 태양중심 모델이었지만, 현대적 표현에서는 “태양계에서 지구가 태양 주위를 공전한다”가 더 안전하다.
4. 세 단계의 차이를 한눈에 보기
명제
지식요건해당성
정합성
확증가능성
“지구는 우주의 중심이다.”
통과
현재 자연과학 체계에서는 탈락
현재 사실로 주장 금지
“프톨레마이오스 체계는 지구를 중심으로 보았다.”
통과
통과
역사적 사실로 주장 가능
“지구는 태양 주위를 돈다.”
통과
통과
현대 천문학 명제로 주장 가능
“코페르니쿠스는 지구가 태양 주위를 돈다고 보았다.”
통과
통과
과학사적 사실로 주장 가능
“천동설은 과거에 아무런 설명력을 갖지 못했다.”
통과 가능
부분 충돌 가능
조건부·유보적으로만 주장
“천동설은 현대 과학 기준으로 폐기된 이론이다.”
통과
통과 가능
문맥을 붙여 주장 가능
5. 여기서 중요한 포인트: 정합성은 “문맥 의존적”이다
LLM Wiki에서 정합성은 단순히 어떤 문장이 참인지 거짓인지 보는 것이 아니다.
정합성은 다음 요소에 따라 달라진다.
- claim_type: 사실인가, 역사적 이론인가, 견해인가, 해석인가?
- domain_scope: 천문학인가, 과학사인가, 철학사인가, 교육사인가?
- time_scope: 현재 기준인가, 2세기 프톨레마이오스 체계 기준인가, 16세기 코페르니쿠스 기준인가?
- source_scope: 누가 그렇게 주장했는가?
- answer_policy: 사실로 단정할 것인가, 견해로 소개할 것인가?
예를 들어:
“천동설은 맞다.”
이 문장은 정합성에서 탈락할 가능성이 크다.
하지만:
“천동설은 고대와 중세 천문학에서 중요한 설명 체계였다.”
이 문장은 정합성을 가질 수 있다.
또:
“프톨레마이오스 체계는 행성의 겉보기 운동을 설명하기 위해 주전원과 이심원 같은 장치를 사용했다.”
이 문장은 과학사적 설명으로서 정합성이 높다. 프톨레마이오스 체계에서 행성이 주전원을 따라 움직이고 그 주전원의 중심이 더 큰 원인 이심원을 따라 움직인다는 설명은 잘 알려진 프톨레마이오스 체계의 구조이다.
6. “정합성 추정”을 천동설 예시로 설명하기
필자가 3단계 지식체계론을 제시하면서 말한 원칙은 아래와 같다.
지식요건에 형식적으로 해당하면
명백한 정합성 배제사유가 없는 한
일단 정합성이 있는 것으로 추정한다.
이 원칙을 천동설에 적용하면 다음과 같다.
후보 claim
“프톨레마이오스 체계는 지구중심 우주론이다.”
1단계
형식적 요건을 갖췄다.
이론명 있음.
주장 내용 있음.
도메인 있음.
출처 부여 가능.
따라서 지식요건해당성이 있다.
2단계
이 claim은 “현재 지구가 우주의 중심이다”라고 말하는 것이 아니다. 단지 “프톨레마이오스 체계가 그런 이론이었다”고 말한다.
명백한 정합성 배제사유가 없다.
따라서 정합성이 추정된다.
정합성: presumed: true exclusion_found: false
3단계
출처가 충분하다면 확증가능성도 높다.
확증가능성: level: high answer_policy: assert_with_citation
8. 반대로 정합성 배제사유가 있는 경우
후보 claim
“현대 천문학에 따르면 지구가 우주의 중심이다.”
1단계
형식은 갖췄다.
지식요건해당성: passed: true
2단계
그러나 이 문장은 현대 천문학 지식질서와 명백히 충돌한다. 따라서 정합성 배제사유가 있다.
정합성: passed: false exclusion_reason: - "현대 천문학 지식질서와 충돌" - "역사적 이론을 현재 사실로 오분류"
3단계
정합성이 탈락했으므로 현재 사실로 주장할 수 없다.
확증가능성: level: none answer_policy: do_not_assert
하지만 완전히 삭제할 필요는 없다. LLM Wiki는 이 정보를 다음처럼 변형해서 보존할 수 있다.
corrected_claim: text: "프톨레마이오스 체계는 지구가 우주의 중심이라고 보았다." claim_type: historical_theory answer_policy: assert_with_citation
8. 확증가능성의 핵심: “맞다/틀리다”보다 “어떻게 말할 수 있는가”
천동설·지동설 예시에서 가장 중요한 단계는 사실 3단계이다.
LLM Wiki는 천동설을 무조건 삭제하면 안 된다. 왜냐하면 천동설은 현재 자연과학 명제로는 틀렸지만, 과학사적 지식으로는 매우 중요한 정보이기 때문이다.
따라서 확증가능성은 이렇게 나뉜다.
천동설_as_current_fact: answer_policy: do_not_assert allowed_expression: "현재 사실로는 받아들여지지 않는다." 천동설_as_historical_theory: answer_policy: assert_with_citation allowed_expression: "프톨레마이오스 체계는 지구중심 우주론이었다." 천동설_as_pedagogical_example: answer_policy: qualify allowed_expression: "천동설은 관측 자료와 이론 체계가 어떻게 재구성되는지를 보여주는 과학사적 사례다." 지동설_as_current_astronomy: answer_policy: assert allowed_expression: "태양계에서 지구는 태양 주위를 공전한다."
즉, 확증가능성은 지식을 폐기할지 보존할지가 아니라, 어떤 말투와 지위로 사용할지를 정한다.
9. LLM Wiki에 실제로 저장한다면
천동설 page
id: theory-ptolemaic-geocentrism
type: theory
title: "프톨레마이오스적 천동설" 지식요건해당성: passed: true reason: "역사적 이론으로서 주체, 내용, 시대, 출처가 특정됨" 정합성: passed: true reason: "현재 자연과학 사실이 아니라 과학사적 이론으로 저장됨" caveat: - "현재 천문학 사실로 주장하면 정합성 탈락" 확증가능성: level: high_as_historical_claim answer_policy: assert_as_historical_theory prohibited_use: - "assert_as_current_astronomical_fact" canonical_claim: text: "프톨레마이오스 체계는 지구가 정지해 있고 우주의 중심에 있다고 보는 지구중심 우주론이다."
지동설 page
id: theory-copernican-heliocentrism
type: theory
title: "코페르니쿠스적 지동설" 지식요건해당성: passed: true reason: "이론의 주체, 내용, 역사적 맥락이 특정됨" 정합성: passed: true reason: "태양계에서 지구가 태양 주위를 돈다는 설명은 현대 천문학 지식질서와 양립함" 확증가능성: level: high answer_policy: assert_with_citation canonical_claim: text: "코페르니쿠스 체계는 태양을 중심으로 놓고 지구와 다른 행성들이 태양 주위를 돈다고 본다."
10. 이 예시가 보여주는 3단계의 의미
천동설과 지동설을 통해 보면, 이 3단계 지식체계론은 다음처럼 작동한다.
지식요건해당성: 천동설도 지식 형식은 갖출 수 있다. 틀린 이론도 지식 단위로 기술될 수 있다. 정합성: 천동설이 현재 사실로 들어오면 전체 과학 지식질서와 충돌한다. 하지만 과학사적 이론으로 들어오면 정합성을 가진다. 확증가능성: 천동설은 현재 사실로 단정할 수 없다. 하지만 역사적 이론으로는 단정적으로 설명할 수 있다. 지동설은 현재 태양계 설명으로 강하게 주장할 수 있다.
그래서 최종적으로 LLM Wiki는 이렇게 답해야 한다.
“천동설은 틀렸으니 삭제한다.”
가 아니라
“천동설은 현재 천문학 명제로는 주장할 수 없지만,
프톨레마이오스적 과학사 이론으로는 보존·설명할 수 있다.”
라고 처리해야 한다.
11. 한 줄 정리
천동설과 지동설 예시로 보면:
지식요건해당성은 ‘그 말이 지식 단위로 성립하는가’를 보고,
정합성은 ‘그 지식이 올바른 문맥에서 전체 지식질서와 양립하는가’를 보며,
확증가능성은 ‘그 지익이 현재 사실, 역사적 이론, 견해, 반례 중 무엇에 의해 뒷받침되어야 하는가’를 결정한다.
이렇게 보면 3단계 지식체계론은 단순히 “참/거짓 판별기”가 아니라, 틀린 이론도 적절한 지위로 보존하고, 맞는 이론은 적절한 강도로 주장하게 만드는 LLM Wiki의 지식 운영 원리가 된다.
12. 중요한 보완: 확증가능성은 정합성을 뒤집을 수도 있다
여기서 중요한 점이 하나 있다.
이 체계가 너무 보수적으로 작동하면, 기존 지식질서와 충돌하는 새로운 지식이 항상 정합성 단계에서 탈락할 위험이 있다.
그런데 과학사는 그렇지 않다.
지동설은 처음에는 기존 천동설 중심 지식질서와 충돌했지만, 점점 더 강한 관측적·이론적 확증을 얻으면서 오히려 기존 지식질서를 바꾸었다.
그래서 LLM Wiki에서는 이렇게 처리해야 한다.
기존 지식질서와 충돌한다
→ 무조건 탈락 이 아니라, 기존 지식질서와 충돌한다
→ 정합성 문제 있음
→ 확증가능성이 높은지 별도 심사
→ 높다면 disputed 또는 revision_candidate로 등록
→ 기존 지식질서를 수정하거나 supersede할 수 있음
즉, 정합성 탈락에는 두 종류가 있다.
정합성_문제: ordinary_incoherence: meaning: "근거 없는 오류 또는 문맥 착오" action: "reject_or_correct" revolutionary_conflict: meaning: "기존 지식질서와 충돌하지만 강한 확증가능성이 있는 새 지식" action: "mark_as_revision_candidate"
천동설·지동설 사례로 말하면:
지동설 초기: 기존 천동설 체계와 정합성 충돌 하지만 관측과 계산을 통해 확증가능성 증가 결국 기존 지식질서를 수정 LLM Wiki: 충돌 claim을 바로 삭제하지 않고, 확증가능성이 높으면 체계 수정 후보로 보존
이건 아주 중요하다.
왜냐하면 좋은 지식체계는 단순히 기존 질서와 맞는 것만 받아들이는 체계가 아니라, 더 강하게 확증된 지식이 등장하면 기존 질서를 고칠 수 있는 체계여야 하기 때문이다.
13. 따라서 정합성과 확증가능성의 관계는 이렇게 잡는 게 좋다
정합성은 현행 지식질서와의 관계를 본다.
확증가능성은 증거와 근거의 강도를 본다.
둘의 조합은 네 가지가 나온다.
정합성
확증가능성
처리
높음
높음
확정 지식으로 사용
높음
낮음
보류 또는 약한 견해로 저장
낮음
낮음
오류 가능성이 높으므로 탈락 또는 수정
낮음
높음
기존 지식질서 수정 후보로 등록
마지막 칸이 중요하다.
정합성 낮음 + 확증가능성 높음
= 단순 오류가 아니라 패러다임 전환 후보
이 구조를 넣으면 3단계 지식체계론이 훨씬 강해진다.
knowledge_review: stage_1_knowledge_elements: label: "지식요건해당성" passed: true required_elements: - subject - predicate - object - claim_type - source_id - evidence_span - domain_scope - time_scope stage_2_coherence: label: "정합성" passed: true presumed_if_stage_1_passed: true coherence_exclusions: - contradiction_with_settled_claim - wrong_time_scope - wrong_domain_scope - category_error - source_misread conflict_handling: if_low_confirmability: "reject_or_correct" if_high_confirmability: "mark_revision_candidate" stage_3_confirmability: label: "확증가능성" level: strong basis: - direct_source - independent_corroboration - low_inference - no_unanswered_counterevidence answer_policy: assert_with_citation
14. “확증가능성” 안에 반드시 넣어야 할 하위 개념
확증가능성을 쓰려면, 단순히 “확증할 수 있다”로 끝내면 안 되고 다음 하위 개념을 넣는 게 좋다.
1. 출처확인성 원자료 또는 신뢰 가능한 자료에 접근할 수 있는가? 2. 증거관련성 그 자료가 실제로 이 claim을 뒷받침하는가? 3. 증거충분성 근거가 충분한가, 단일한 약한 자료인가? 4. 독립확인성 여러 독립 근거가 서로 보강하는가? 5. 반증검토성 반대 근거를 검토했는가? 6. 추론절제성 LLM의 추론이 과도하게 개입되지 않았는가? 7. 범위한정성 어느 시대, 도메인, 학설, 관점에서 확증되는지 표시되어 있는가?
특히 반증검토성은 꼭 넣는 게 좋다.
왜냐하면 “확증가능성”이라는 말이 자칫하면 자기 주장에 맞는 증거만 모으는 확증편향처럼 오해될 수 있기 때문이다.
그래서 확증가능성은 이렇게 정의하는 게 안전하다.
확증가능성은 찬성 근거의 존재만이 아니라,
반대 근거를 검토한 뒤에도 해당 지식이 어느 정도 유지될 수 있는지를 포함한다.
15. 최종 용어 체계 제안
이 체계는 이렇게 정리하면 가장 좋다고 본다.
3단계 지식체계론 1. 지식요건해당성 해당 정보가 LLM Wiki의 지식 단위로 성립하기 위한 형식적 요건을 갖추었는지 판단한다. 2. 정합성 지식요건에 해당하는 정보가 전체 지식질서와 모순·충돌하지 않는지 판단한다. 지식요건해당성이 인정되면 명백한 정합성 배제사유가 없는 한 정합성은 일응 추정된다. 다만 정합성 충돌이 있더라도 확증가능성이 높은 경우에는 탈락시키지 않고 지식질서 수정 후보로 보존한다. 3. 확증가능성 정합성이 인정되었거나 정합성 충돌에도 불구하고 검토할 가치가 있는 지식에 대하여, 출처, 증거, 독립확인, 반대증거 검토, 추론개입도, 검토절차, 시점과 범위에 비추어 그 지식이 어느 정도 확증될 수 있는지 판단한다.
16. 한 줄 결론
“확증가능성”은 3단계 지식체계론의 세 번째 단계로 매우 적합하다.
최종 구조는 이렇게 가면 좋다.
지식요건해당성 → 정합성 → 확증가능성
각 단계의 질문은 다음이다.
지식요건해당성: 이것은 지식 단위로 성립하는가? 정합성: 이것은 전체 지식질서와 양립하는가? 확증가능성: 이것은 출처와 증거에 의해 어느 정도 확인될 수 있는가?
그리고 LLM Wiki의 실무 적용은 이렇게 된다.
확증가능성이 높으면 단정 가능.
확증가능성이 중간이면 조건부 주장.
확증가능성이 낮으면 견해로 소개.
확증가능성이 없으면 사실로 사용 금지.
정합성과 충돌하지만 확증가능성이 높으면 기존 지식질서 수정 후보.
이렇게 정리하면 “주장책임성”보다 훨씬 더 지식체계론다운 세 번째 단계가 된다.
17. 문제 1:위와 같은 3단계 지식체계론 schema 구성의 필요 여부
갑자기 근본적으로 위와 같은 3단계 지식체계론을 schema에 구성하는 것이 과연 llm wiki에 도움이 될지가 궁금해졌다. llm에게 맡기면 오히려 이보다 더 잘 설계해서 작동할 수도 있는데, 오히려 이러한 설계가 llm을 경직되게 하고 llm의 성능을 제한하는 것은 아닌지 의문이 들었다.
Prompt
이러한 schema, 즉 3단계 지식체계론을 llm wiki에 편입시키는 것이 더 나을지, 아니면 이것을 llm의 자체적인 판단에 맡기고 별도의 schema로 구성하지 않는 것이 더 나을지 모르겠어
이를 통해 받은 LLM의 답변은 다음과 같았다. 여기서부터 이 단락의 마지막 부분까지는 LLM의 답변을 그대로 수록하고자 한다.
내 판단은 이거야.
3단계 지식체계론은 LLM Wiki에 넣는 편이 낫다.
다만 “모든 지식에 붙는 거대한 형식요건”이 아니라, LLM의 판단을 구조화하는 얇은 admission schema로 넣는 게 좋다.
즉, LLM 자체 판단을 배제하는 schema가 아니라, LLM 자체 판단을 기록 가능하고 반복 가능하게 만드는 schema로 쓰는 게 맞아.
Karpathy의 LLM Wiki 구상 자체도 raw sources, wiki, schema의 세 층을 두고, schema를 LLM에게 wiki 구조·관례·ingest/query/lint workflow를 알려주는 핵심 설정 파일로 설명한다. 특히 schema가 LLM을 “generic chatbot”이 아니라 “disciplined wiki maintainer”로 만든다는 식의 취지가 들어 있다.
(1) 결론: “명시적 schema + LLM 판단”의 혼합형이 가장 좋다
선택지는 세 가지야.
A. 3단계 지식체계론을 명시적 schema로 넣는다.
B. LLM 자체 판단에 맡긴다.
C. 기본 schema는 넣되, 판단의 상당 부분은 LLM에게 맡긴다.
나는 C가 가장 좋다고 봐.
왜냐하면 LLM Wiki의 핵심은 LLM이 계속 source를 읽고, wiki를 수정하고, 충돌을 발견하고, synthesis를 갱신하는 데 있어. Karpathy도 LLM Wiki를 raw 문서에서 매번 답을 재발견하는 RAG와 달리, LLM이 persistent wiki를 점진적으로 만들고 갱신하는 구조로 설명한다. 그런데 이 과정에서 아무 schema도 없으면 LLM은 매번 그럴듯하게 판단하지만, 왜 이 지식이 편입되었는지, 왜 단정되었는지, 왜 폐기되었는지가 남지 않아.
반대로 schema를 너무 무겁게 만들면 LLM Wiki가 “살아 있는 지식베이스”가 아니라 “모든 문장마다 재판하는 관료제”가 될 수 있어.
그래서 추천은 이거야.
3단계 지식체계론은 넣는다.
그러나 모든 문장에 강제하지 않는다.
중요 claim, 충돌 claim, canonical claim, 업데이트 claim에만 명시적으로 적용한다.
(2) LLM 판단에만 맡기면 생기는 문제
LLM에게 “알아서 잘 판단해”라고 맡기는 방식은 초기에 빠르고 자연스럽다. 작은 개인 wiki, 브레인스토밍, 독서노트 정도라면 꽤 잘 작동할 수도 있다.
하지만 wiki가 커질수록 문제가 생긴다.
첫째, 판단 기준이 세션마다 달라진다.
오늘은 어떤 claim을 “충분히 근거 있음”으로 보고, 다음 세션에서는 같은 수준의 claim을 “불확실”로 볼 수 있다.
둘째, 확증가능성의 흔적이 남지 않는다.
나중에 “왜 이 claim을 사실처럼 썼지?”라고 물었을 때, 출처·증거·정합성 판단이 metadata로 남아 있지 않으면 재검토가 어렵다.
셋째, lint가 불가능해진다.
정합성: conflicted, 확증가능성: weak, answer_policy: qualify 같은 필드가 있어야 나중에 “약한 확증가능성인데 단정적으로 쓰인 claim”을 찾을 수 있다.
넷째, 새 정보가 들어왔을 때 기존 정보를 어디까지 바꿀 수 있는지 불분명해진다.
앞서 말한 기판력적 사고와 연결하면, 어떤 것이 holding이고 어떤 것이 reason인지, 어떤 claim이 settled이고 어떤 claim이 draft인지가 없으면 조용한 덮어쓰기가 발생한다.
최근 LLM Wiki 관련 연구에서도 raw 문서를 wiki로 “컴파일”할 때 중요한 사실이 빠지는 문제가 지적된다. WiCER 논문 초록은 blind compilation이 상당한 실패율을 보였고, diagnostic probe로 빠진 사실을 찾아 반복적으로 보정하는 방식이 품질 회복에 도움을 준다고 보고한다. 아직 하나의 연구 결과로 신중히 봐야 하지만, LLM에게 단순 압축·정리만 맡기면 지식 손실이 생길 수 있다는 문제의식은 네 schema 도입 쪽을 뒷받침한다.
(3) 그렇다고 무거운 schema가 항상 좋은 것은 아니다
반대로 3단계 지식체계론을 너무 엄격하게 넣으면 이런 문제가 생긴다.
- 모든 문장마다 지식요건해당성, 정합성, 확증가능성을 쓰느라 wiki가 비대해짐
- LLM이 본문보다 심사표 작성에 더 많은 에너지를 씀
- 확증가능성 등급이 기계적으로 붙어 가짜 객관성을 만들 수 있음
- 창의적 연결, 임시 가설, 탐색적 메모가 위축됨
- 사용자가 wiki를 읽을 때 지식보다 metadata가 더 많아짐
Karpathy도 LLM Wiki 아이디어 파일에서 구체적인 directory 구조, schema convention, tooling은 domain과 선호에 따라 달라진다고 하고, 필요한 것은 선택하고 불필요한 것은 버리라는 취지로 설명한다. 즉 schema는 고정 법전이라기보다 domain에 맞춰 co-evolve하는 설정 파일에 가깝다.
그래서 네 3단계 지식체계론도 처음부터 완성된 대형 ontology로 넣기보다, 작게 넣고 점진적으로 발전시키는 게 좋다.
(4) 내가 추천하는 방식: “얇은 3단계 schema”
3단계 지식체계론은 LLM Wiki에 다음 정도로만 넣으면 충분해.
knowledge_review: 지식요건해당성: pass | fail | uncertain 정합성: presumed | coherent | conflicted | revision_candidate | rejected 확증가능성: none | weak | moderate | strong | settled answer_policy: do_not_assert | mention_as_view | qualify | assert_with_citation | assert reason: "짧은 자연어 이유"
핵심은 reason이야.
등급만 있으면 기계적 분류가 되고, 이유가 있어야 나중에 사람이 이해할 수 있다.
예시는 이렇게.
knowledge_review: 지식요건해당성: pass 정합성: coherent 확증가능성: strong answer_policy: assert_with_citation reason: "source가 해당 claim을 직접 뒷받침하고, 기존 wiki의 settled claim과 충돌하지 않음."
충돌하는 경우는 이렇게.
knowledge_review: 지식요건해당성: pass 정합성: conflicted 확증가능성: moderate answer_policy: mention_as_disputed reason: "기존 settled claim과 결론이 다르지만, 새 source가 직접 근거를 제공하므로 rejected가 아니라 disputed로 보존."
이 정도면 충분히 실용적이야.
(5) 모든 곳에 붙이지 말고, 적용 대상을 나누는 게 좋다
가장 중요한 설계는 적용 강도의 차등화야.
1단계 적용: 일반 메모와 임시 노트
일반 독서 메모, 아이디어, 임시 요약에는 3단계 schema를 강제하지 않아도 된다.
적용 방식:
- LLM이 암묵적으로 판단
- 필요하면 본문에 “불확실”, “추후 검토” 정도만 표시
예:
## Note
이 논문은 LLM memory를 단순 retrieval보다 compiled representation으로 보는 관점을 제시하는 듯하다. Status: rough note
여기에는 굳이 지식요건해당성: pass 같은 걸 붙이지 않아도 된다.
2단계 적용: claim page, concept page, source summary
wiki의 본문 지식으로 들어가는 claim에는 압축된 3단계 schema를 붙이는 게 좋다.
적용 방식:
- frontmatter 또는 claim block에 3단계 요약 필드 추가
- 확증가능성 등급과 answer_policy 기록
예:
claim_id: claim-llmwiki-001
text: "LLM Wiki는 raw source를 매번 재검색하는 대신, LLM이 persistent wiki를 점진적으로 구축하는 방식이다." knowledge_review: 지식요건해당성: pass 정합성: coherent 확증가능성: strong answer_policy: assert_with_citation reason: "Karpathy의 LLM Wiki 설명에서 직접 확인됨."
3단계 적용: 충돌 claim, canonical claim, policy claim
여기는 엄격하게 해야 한다.
적용 대상:
- 기존 지식을 대체하는 claim
- settled claim과 충돌하는 claim
- source 간 충돌이 있는 claim
- wiki policy
- 법학, 의학, 과학, 재무처럼 정확성이 중요한 claim
- 사용자가 반복해서 참조할 canonical page
이 경우에는 3단계를 조금 더 자세히 쓴다.
knowledge_review: 지식요건해당성: result: pass reason: "subject, predicate, object, source_id, evidence_span 존재" 정합성: result: conflicted conflict_with: - claim-2026-05-20-004 treatment: disputed reason: "기존 claim과 결론이 다르나 새 source가 직접 근거를 제공함" 확증가능성: level: moderate evidence_quality: direct independent_confirmation: absent counterevidence_reviewed: partial inference_level: low answer_policy: mention_as_disputed
즉, 중요도에 따라 schema의 두께를 다르게 해야 한다.
(6) 3단계 지식체계론은 “LLM을 대체”하는 것이 아니라 “LLM의 판단을 노출”하는 것이다
이 지점이 제일 중요해.
3단계 schema를 넣는다고 해서 LLM의 판단을 없애는 게 아니야. 오히려 LLM 판단을 더 잘 쓰는 거야.
schema 없음: LLM이 판단한다. 그러나 판단 기준과 결과가 사라진다. schema 있음: LLM이 판단한다. 그리고 그 판단을 지식요건해당성, 정합성, 확증가능성으로 기록한다.
즉 schema는 판사가 아니라 판결문 양식에 가깝다.
LLM은 여전히 판단한다.
다만 판단을 다음 세 질문으로 나누어 남긴다.
1. 이것은 지식 단위로 성립하는가?
2. 기존 지식질서와 충돌하지 않는가?
3. 어느 정도 확증 가능한가?
이렇게 하면 나중에 사람이 검토하기 쉽고, 다른 LLM이 이어받아도 기준이 유지된다.
(7) 가장 좋은 실무 구조
나는 다음 구조를 추천해.
llm-wiki/ AGENTS.md raw/ wiki/ index.md log.md claims/ concepts/ sources/ disputes/ policies/ knowledge-admission.md update-and-supersession.md evidence-and-confirmability.md reviews/ knowledge-review-log.md contradiction-register.md weak-confirmability-register.md
그리고 AGENTS.md에는 원칙만 짧게 둔다.
## 3단계 지식체계론 LLM은 중요한 지식을 wiki에 편입할 때 다음 세 단계를 적용한다. 1. 지식요건해당성
정보가 wiki의 지식 단위로 성립할 형식요건을 갖추었는지 판단한다. 2. 정합성
해당 정보가 기존 지식질서와 모순·충돌하지 않는지 판단한다.
지식요건해당성이 인정되면 명백한 정합성 배제사유가 없는 한 정합성은 일응 추정한다.
정합성 충돌이 있더라도 확증가능성이 높으면 rejected가 아니라 disputed 또는 revision_candidate로 보존한다. 3. 확증가능성
출처, 증거직접성, 독립확인성, 반대증거 검토, 추론개입도, 시점과 범위에 비추어
해당 지식이 어느 정도 확증될 수 있는지 판단한다. 확증가능성 등급:
- none
- weak
- moderate
- strong
- settled answer_policy:
- do_not_assert
- mention_as_view
- qualify
- assert_with_citation
- assert
이 정도면 충분해.
(8) schema로 넣을 때 특히 조심할 점
첫째, 정합성을 너무 강하게 쓰면 안 된다
정합성은 기존 지식질서와의 충돌 검사야. 그런데 기존 지식질서가 틀렸을 수도 있다.
그래서 네 체계에는 반드시 이 규칙이 들어가야 해.
정합성 충돌 + 확증가능성 낮음
→ reject 또는 correction 정합성 충돌 + 확증가능성 높음
→ revision_candidate 또는 disputed로 보존
이 규칙이 없으면 지동설 같은 새 지식은 기존 천동설 체계에 안 맞는다는 이유로 탈락해버린다.
둘째, 확증가능성을 “진리성”과 동일시하면 안 된다
확증가능성: settled은 “영원히 참”이 아니라:
현재 wiki의 출처와 증거 체계 안에서 안정적으로 사용할 수 있음
이라는 뜻이어야 한다.
그래서 항상 as_of, domain_scope, source_scope가 필요하다.
확증가능성: level: settled as_of: 2026-05-29 domain_scope: "현대 천문학"
셋째, LLM의 창의적 연결을 막으면 안 된다
LLM Wiki의 장점 중 하나는 source들 사이의 연결을 만들어내는 것이다. Karpathy도 LLM이 source를 읽고 key information을 추출하고, 기존 wiki에 통합하고, entity/concept page를 갱신하고, contradiction을 표시하는 식으로 지식이 누적된다고 설명한다.
따라서 모든 연결을 “확증가능성 strong”으로 요구하면 안 된다.
대신 다음처럼 나누면 된다.
claim_type: - fact - historical_fact - interpretation - analogy - hypothesis - question - synthesis
(9) 언제 schema를 생략해도 되는가
다음 경우에는 굳이 3단계 schema를 명시하지 않아도 된다.
- 순수한 임시 메모
- brainstorming
- 사용자가 직접 쓴 개인적 생각
- 아직 source를 붙이지 않은 reading note
- wiki에 정식 편입되지 않은 scratchpad
- 단순 index update
- 단순 링크 추가
- 문체 수정
이런 것까지 전부 3단계로 심사하면 부담이 커진다.
대신 상태를 이렇게 두면 된다.
status: scratch | draft | candidate | admitted | disputed | settled
scratch, draft 단계에서는 3단계를 생략하고, candidate → admitted로 갈 때 3단계를 적용한다.
(10) 최종 추천 운영 방식
내가 추천하는 운영 규칙은 이거야.
1. LLM Wiki에 3단계 지식체계론을 명시적으로 넣는다.
2. 단, 모든 문장에 적용하지 않는다.
3. wiki에 정식 편입되는 claim에만 압축 적용한다.
4. settled claim, 충돌 claim, 새 정보로 기존 정보를 대체하는 경우에는 엄격 적용한다.
5. scratch note, brainstorming, 단순 요약에는 생략한다.
6. 확증가능성은 answer_policy와 연결한다.
7. 정합성 충돌이 있어도 확증가능성이 높으면 revision_candidate로 남긴다.
8. schema 자체도 주기적으로 lint하고 수정한다.
한 줄로 정리하면:
3단계 지식체계론은 LLM Wiki의 “판단을 대신하는 규칙”이 아니라, LLM의 지식 편입 판단을 반복 가능하고 감사 가능하게 만드는 최소 절차로 넣는 것이 좋다.
그래서 네가 넣으려는 방향은 맞다고 봐.
다만 “강한 schema”가 아니라 얇고 점진적으로 진화하는 schema로 시작하는 것이 가장 안전하다.
위와 같은 답변을 받았다.
이렇게 함으로써 3단계 지식체계론은 LLM의 검증도 통과했다.
이를 구현하는 구체적인 방법이 남아있는데, 그 전에 다른 문제에 직면했다.
18. 문제 2:다양한 정보에의 적용 문제
그렇다면 내가 갖고 있는 모든 정보가 바로 이 3단계 지식체계론의 검증 대상이 될까? 되어야 할까? 개인 일기나 개인의 감상, 의견, 여행자료, 사진자료와 같은 데이터들을 3단계 지식체계론을 적용하는 것이 타당할까? 예를 들어 "나는 피렌체를 좋아한다"라는 데이터가 3단계 지식체계론의 검증을 거칠 필요가 있을까? 그렇다면 위와 같은 정보는 어떤 방식으로 지식화, wiki화를 해야 할까?
위와 같은 물음이 생겼다.
객관적 지식에 대해서는 3단계 지식체계론을 적용하는 것이 타당성이 있다고 생각한다. 물론 이 역시 사람마다 다를 수 있다. 하지만 데일리 노트, 감상 등의 주관적 자료들을 위의 잣대로 평가할 수는 없는 것 아닌가? 아예 중립적인 자료, 사진, 음악, 동영상과 같은 자료를 3단계 지식체계론을 적용시킨다면 그게 무슨 의미가 있을까?
이에 대해서는 "지식유형론"이라는 별도의 이론을 통해 schema를 다듬을 수 있었다. "지식유형론"을 비롯한 다른 schema의 이론적 근거에 대해서는 별도의 사례에서 다루도록 하겠다.
비개발자 1인 사업가가 코딩없이 회사 내부 프로젝트 관리 시스템 만들기
업종 상품 기획·수입·유통 | 도구 Claude Code | 소요 시간 약 2시간
---
이런 분이 읽으면 좋아요
반복적인 수작업 계산이 지겨운 소규모 사업자
맞춤형 관리 도구가 필요하지만 개발 외주를 맡기기엔 부담스러운 분
바이브코딩이 궁금하지만 "나 같은 사람도 할 수 있을까?" 반신반의하는 분
---
비개발자 대표의 도전
나는 개발자가 아니다. 상품을 기획하고 해외 공장에 제작을 의뢰한 뒤, 수입해서 국내에 납품하는 회사를 운영하는 대표다. 코드는 한 줄도 쓸 줄 모른다. 그런 내가 오늘, 우리 회사 전용 영업이익 관리 웹사이트를 직접 만들었다.
---
기존 문제점 분석
프로젝트마다 들어가는 비용 항목이 다양하다. 제조원가, 해상운임, 수입통관비, 디자인·샘플비, 검사비, 국내운송비까지 — 이걸 매번 엑셀에 손으로 입력하고, 수식을 짜서 남는 금액을 계산하는 게 일상이었다.
더 큰 문제는 전체 그림이 보이지 않는다는 점이었다. 프로젝트별 이익률을 한눈에 비교할 수 없고, 판관비와 세금까지 반영한 실제 순이익을 파악하려면 또 별도로 계산해야 했다. 비효율이 쌓이고 있었지만 뾰족한 방법이 없었다.
---
목표 설정
거창한 시스템이 필요한 게 아니었다. 원하는 건 딱 세 가지였다.
비용 항목을 입력하면 이익과 이익률이 자동으로 계산될 것
판관비와 세금까지 반영한 세후 순이익을 한눈에 볼 수 있을 것
정리된 보고서를 이메일로 받을 수 있을 것
외주를 맡기기엔 너무 작은 내부 도구였다. 그래서 처음으로 Claude Code를 열었다.
---
개발 과정
Step 1. 코드 전에 대화 먼저
가장 먼저 한 일은 개발 요청이 아니었다. 우리 회사가 어떻게 돌아가는지를 설명하는 것이었다. 매출 구조, 비용 항목 분류 방식, 업무 흐름까지 — 현업의 맥락을 그대로 전달했다.
AI는 단순히 받아 적는 게 아니라 함께 구조를 검토했다. 덕분에 "어떻게 만들까"보다 "어떻게 설계할까"를 먼저 합의할 수 있었다.
Step 2. 비용 항목 구조 합의
프로젝트별 매출원가를 6개 항목으로 나눠 입력하기로 했다.
제조원가 / 해상운임 / 수입통관비 / 디자인·샘플비 / 검사비 / 국내운송비
특히 해상운임과 수입통관비는 하나로 묶지 않고 따로 입력하도록 구분했다. 실제 업무에서 두 항목의 발생 시점과 성격이 다르기 때문이다.
Step 3. 판관비·세금 처리 방식 결정
AI가 판관비 처리 방식으로 세 가지 옵션을 제안했다.
A. 프로젝트마다 판관비 직접 입력
B. 월 고정비 등록 후 매출 비중으로 자동 배분
C. 판관비는 회사 전체 요약에서만 반영, 프로젝트는 매출총이익까지만 계산
우리 업종 특성상 프로젝트 기간이 불규칙하기 때문에 C 방식을 선택했다. AI도 같은 이유에서 C가 가장 합리적이라고 동의했다. 이 한 가지 결정이 이후 전체 시스템의 정확성을 좌우했다.
Step 4. 개발 및 완성
구조 합의가 끝나자 개발이 시작됐다. 파일이 하나씩 생성되는 과정이 실시간으로 보였고, 얼마 지나지 않아 브라우저에 실제 화면이 열렸다. 마지막으로 회사 로고 파일 위치를 알려주자, AI가 직접 파일을 읽어 사이드바에 적용해줬다.
---
최종 결과물
2시간 만에 완성된 웹앱의 주요 기능은 다음과 같다.
프로젝트 등록 및 실시간 손익 계산
6개 원가 항목을 입력하면 매출총이익과 이익률이 화면 오른쪽에서 실시간으로 계산된다.
대시보드 및 차트
전체 프로젝트의 매출·이익·이익률이 카드와 차트로 한눈에 정리된다.
회사 전체 손익 요약
매출총이익 합계 → 판관비 차감 → 영업이익 → 세금 적용 → 세후 순이익까지 자동 계산된다.
이메일 보고서 발송
버튼 하나로 현황 보고서를 이메일로 발송할 수 있다.
회사 로고 적용
사이드바에 로고가 들어가면서 외부 도구가 아닌 '우리 회사 시스템'이 됐다.
경험에서 얻은 교훈
1. 바이브코딩, 생각보다 훨씬 쉬웠다
솔직히 말하면 처음엔 반신반의했다. '코딩을 모르는 내가 진짜 뭔가를 만들 수 있을까?' 그런데 막상 해보니 놀라울 정도로 단순했다. 내가 한 건 대화뿐이었다. 내 업무 방식을 설명하고, 구조에 동의하고, 결과를 확인하는 것. 그게 전부였다. 막연하게만 느껴지던 바이브코딩이 이렇게 빠르게, 이렇게 실제로 작동하는 결과물로 이어질 줄은 몰랐다.
2. AI에게 일을 잘 시키는 방법은 내 일을 잘 설명하는 것이다
"관리 시스템 만들어줘"가 아니라, 비즈니스 구조와 맥락을 구체적으로 전달했기 때문에 실제로 쓸 수 있는 결과물이 나왔다. 내가 10년 가까이 이 업을 하면서 쌓아온 도메인 지식이, AI를 만나서 비로소 작동하는 도구가 됐다.
3. 빠르게 만들 수 있다고 해서, 빠르게 완성되는 건 아니다
이번에 2시간 만에 초기 버전을 만든 건 사실이다. 하지만 개인적으로 이렇게 생각한다. 진짜 완성도 높은 결과물은 여기서부터가 시작이다. 실제로 써보고, 불편한 점을 발견하고, 더 나은 방식을 고민하고, 계속 수정하고 발전시켜 나가는 과정이 반드시 필요하다. 바이브코딩이 아무리 빠르고 편해도, 끊임없이 생각하고 개선하려는 태도 없이는 그냥 한 번 만들고 마는 도구에 그친다. 도구를 빠르게 만드는 시대일수록, 그것을 제대로 발전시키는 사람의 역할이 더 중요해진다.
---
처음 Claude Code를 열었을 때는 반신반의했다. 두 시간 후, 브라우저에 우리 회사 로고가 달린 관리 시스템이 떠 있었다. 앞으로 만들고 싶은 도구를 만드는 데 코딩 능력은 더 이상 필요 조건이 아니다.
비개발자 대표의 첫 바이브코딩 경험
하려던 것 📝
대외비 K-아티스트 IP 한정판 프로젝트(해외 도시 런칭)의 운영체계를 만들고 싶었습니다.
해결하고 싶었던 문제:
ChatGPT/Claude로 의논한 사업 인사이트가 세션 끊기면 사라짐
대외비 정보를 AI에 그대로 입력할 수 없는 답답함
의사결정이 머릿속·카톡·회의 메모로만 흩어져 한 달 뒤 사라짐
다음 도시·다음 IP 프로젝트가 또 처음부터
목표: 위 4가지를 하나의 운영체계로 묶어 매일 아침 자동 브리핑까지 받기.
활용한 툴 ⚒️
Claude Code (데스크탑 앱, Opus 4.7 1M 컨텍스트) — OS 설계·빌드
Anthropic API + Python — 자동 브리핑 생성
Slack Incoming Webhook — 채널 발송
macOS launchd — 매일 08:30 자동 실행 스케줄러
로컬 Markdown 파일 — 외부 클라우드·Notion 안 쓰고 대외비 보호
진행 세부 내용 🔍
1) 사양 합의 (10분)
Genspark 설계서 17개 모듈 + AI 에이전트 기획 워크시트(매일 8:30 브리핑 사양)를 합쳤습니다. Claude Code가 "MVP 9개부터 / 전체 17개 / Phase 1 분량 중?"을 물어와서 MVP 9개부터 선택.
2) MVP 9개 모듈 빌드
Command Center, Privacy Rule, Project Brief, AI Insights DB, Finance, Risk Register, Proposal Backlog, Decision Log, Sprint Board.
3) 나머지 8개 모듈 확장
Strategy, IP Approval, Product, Taiwan Growth, Content & Fan Journey, Partner Map, Commerce Ops, Launch Checklist, Post-Launch Review, Vault.
4) Decision Gate 점수화 매트릭스
AI 제안을 11개 항목 점수표(가산 6 + 감산 5)로 강제 구조화. 합계 ≥ +15 즉시 실행, 단일 -5(대외비·브랜드)면 자동 폐기.
5) Level 1 프롬프트형 에이전트
ChatGPT/Claude에 복붙하는 시스템 프롬프트 작성. 10분 만에 즉시 사용 가능.
6) Level 3 Slack 자동 브리핑
Python 150줄 스크립트가 매일 08:30 19개 모듈을 읽고 Claude를 호출 → 5섹션 브리핑(어제/오늘/지연/의사결정/시장신호) → Slack Webhook 발송. macOS launchd로 스케줄링. 월 $1~3.
시행착오 ⚠️
분량 압박 — 17개 모듈 한 번에 빌드하니 양에 질림. 처음에 "X개 파일, 약 Y분"으로 사전 고지받았어야
선택지 부담 — 다중 선택 옵션을 단일 선택으로 오해 ("4개 중 하나 골라야 해?")
파일 첨부 사고 — 워크시트 첨부했다고 했는데 폴더에 없어서 한 번 끊김
AI 환상 — "AI가 OS 다 만들어주겠지"는 환상. 설계는 30%, 매일 5분 운영 입력이 70%
계정 분리 혼동 — 회사 계정으로 로그인된 Claude Code를 개인 계정으로 전환하는 과정에서 시간 소요
CLI 버전 ≠ 모델 버전 — Claude Code 2.1.150은 도구, Opus 4.7은 모델. 두 레이어 구분이 헷갈렸음
배운 점 📚
AI 제안은 점수화해서 관리하라 — AI는 좋은 아이디어 10개 던지는 게 쉽지만 그대로 다 실행하면 망함. 점수 매트릭스로 강제 정렬해야 진짜 가치가 드러남
단일 -5 자동 폐기 같은 안전장치가 필수 — 대외비·브랜드 훼손 항목은 다른 점수와 무관하게 자동 폐기. 카리스마성 의사결정 차단 장치
한 번에 풀 자동화 가지 마라 — Level 1(복붙) → 2(Custom GPT) → 3(자동) → 4(양방향) 단계적으로. 갑자기 풀 자동화 하면 "내가 이게 정말 필요한가?" 본질 질문에 답 못함
설계 30%, 운영 70% — AI는 골조까지. 매일 5분 Sprint Board 채워야 살아있는 운영체계가 됨. 안 채우면 다음 날 브리핑은 "어제 기록 없음 — 업데이트 필요"만 반복
익명화는 협상 불가능 — 실명·계약 조항을 AI에 그대로 입력하면 그 세션 로그가 어디 저장되는지 모름. 매핑표는 AI 외부 암호화 보관 필수
MVP-first가 정신건강에 좋다 — 17개 한 번에 만들면 사용도 안 해보고 양에 질림. 9개 써보고 좋으면 확장하는 방식
향후 계획 🧭
T-Day까지 실제 운영으로 검증 — 17개 모듈 중 안 쓰이는 건 제거, 부족한 건 보강
Slack 양방향(Slash Command) 고도화 — /done 카피작성 입력하면 Sprint Board 자동 업데이트. 매일 5분 운영도 슬랙에서 끝나게
GitHub Actions 이식 — macOS 의존 제거 (출장·주말 영향 없게). 비공개 저장소로 관리
다음 IP/도시 프로젝트에 1-day clone — Project Brief만 새로 쓰고 16개 모듈 재사용. 다음 프로젝트 시작 시간을 일주일 → 하루로 단축
도움이 필요한 점 🤝
매일 5분 OS 업데이트 루틴 정착 — 빌드는 끝났지만 매일 채우는 게 진짜 시험대. 비슷한 시도해본 PM의 운영 노하우·습관 형성 팁
Slash Command 양방향 봇 개발 — Python으로 Slack Events API 다뤄본 분의 도움 또는 참고 사례
대외비 보호 + GitHub Actions 조합 best practice — 비공개 저장소 + Secrets 관리 (특히 IP 권리사 자료)
1-day clone 검증 — 다음 IP/도시로 복제할 때 정말 하루 만에 가능한지 같이 검토해줄 사람
OS 자체 피드백 — 17개 모듈 중 실제로 빠진 영역이 있는지 / 과한 모듈은 없는지 외부 시선 환영
기쁜 마음으로 llm wiki의 20.wiki 폴더를 obsidian으로 열어서 하나하나 살펴보던 중 문제를 발견했다.
첫 번째 문제 - 문서 생성 이유의 일률적 오류(?)
나는 schema에 "본 문서 생성 이유"라는 란을 두어 문서를 생성한 이유를 적어두도록 지시했다. 왜냐하면 왜 이러한 문서가 만들어졌는지를 알아야 해당 문서에 대한 이해도가 높아질 것이라고 생각했기 때문이다.
그런데, 20.Wiki 폴더에 있는 문서들은 하나같이 모두 다음과 같은 "본 문서 생성 이유"로 되어 있었다.
본 문서 생성 이유 이 문서는 $name 내용을 LLM Wiki에서 일관되게 참조하고 재사용하기 위해 생성했다.
이러면 아무런 의미가 없다. 사실 틀린 말은 아니다. 그런데 "$name 내용"이라는 식으로 되어 있는데, 그마저도 뭔가 불완전한 것이었다.
10.Sources 폴더 내의 문서들을 열어봤다. 여기에는 별다른 수정사항이 없어야 했기에 "본 문서 생성 이유"와 같은 내용도 없었다.
그런데 다른 폴더의 문서에는 실제로 "문서 생성 이유"가 제대로 적혀있는 문서가 있었다. 그렇다면 아예 잘못 작동하는 것은 아닐 것인데, 이게 앞으로 계속해서 어떻게 작동할 것인지는 좀 지켜봐야 할 것 같다.
두 번째 문제 - 원천자료의 형식 문제
다음으로 문제는 raw 파일이 md 파일인 경우에는 해당 내용이 wiki로 잘 편입되지만, 동영상 파일이나 음성파일, PDF파일이나 이미지 파일인 경우에는 어떡할지였다. 물론 원본은 자료 그대로 보존해야 하겠지만 이것을 md파일로 변환해야 유의미한 정보가 될 것인데, 굳이 모든 자료를 그렇게 해야할지 아니면 필요한 자료만 수동으로 md화하여 적용할 것인지는 숙제로 남겨두었다.
세 번째 문제 - 원문의 역링크 문제
raw material을 ingest하면 그것이 sources에 메타데이터를 달고 저장되고, 필요한 사항은 wiki로 작성되는 것은 좋은데, 원문에는 그 원문이 어떤 wiki를 만드는 데에 쓰였는지, 아니면 어떤 산출물에 연결되는지에 대한 내용은 없다. 적어도 원문이 어디에 기여했는지를 아는 것은 유의미한 정보가 될 수 있지 않을까?
이것은 초창기에 빨리 원칙을 세워서 적용해야 할 것이기 때문에 이 부분을 그대로 codex에게 물어보았다.
그러자 다음과 같은 답이 나왔다.
맞아요. 그건 꽤 유의미한 정보입니다. 지금 구조는 산출물 -> source_refs -> 원문 방향 추적은 되는데, 반대로 원문 -> 어디에 쓰였나가 약합니다.
다만 raw 원문 자체를 수정하는 방식은 피하는 게 좋고, 원문 주변의 메타데이터에 “기여 이력”을 붙이는 게 좋아 보입니다.
추천 구조는 이렇습니다.
source_refs: - SRC-001
이건 지금처럼 산출물 쪽에 유지하고,
used_by: wiki: - 20.Wiki/02.Concepts/llm-wiki-harness-engineering-relationship.md artifacts: - 40.Projects/02.GPTers Case Posts/01-llm-wiki-build.md
같은 역방향 정보는 10.Sources/source-index.md나 20.Wiki/01.Sources/SRC-###... 요약 문서에 두는 게 좋습니다.
제가 보기엔 가장 현실적인 방식은:
source_refs는 모든 wiki/산출물 frontmatter에 계속 둔다.
10.Sources/source-index.md에는 너무 길어지지 않게 Used By 대신 Usage 또는 Impact 열을 추가한다.
자세한 역방향 목록은 별도 문서 10.Sources/source-usage-index.md로 생성한다.
lint 때 “산출물의 source_refs와 source usage index가 서로 맞는지” 점검한다.
예를 들면 현재 열린 글은 이런 연결을 만들어야 합니다.
SRC-001, SRC-003, SRC-013, SRC-042, SRC-045, SRC-053, SRC-055
-> 40.Projects/02.GPTers Case Posts/01-llm-wiki-build.md
이렇게 하면 Source ID가 단순 출처 목록이 아니라 “이 자료가 어떤 지식/산출물을 낳았는지”를 보여주는 provenance map이 됩니다. 특히 나중에 원문을 갱신하거나 삭제 후보를 판단할 때 엄청 유용해져요.
이렇게 답변을 받은 나는 다시 물어봤다.
이 규칙을 적용했을 때의 예시를 보여줘
그러자 codex는 다음의 예시를 보여줬다.
예를 들면 현재 열린 문서 기준으로는 이렇게 됩니다.
40.Projects/02.GPTers Case Posts/01-llm-wiki-build.md는 지금 이미 정방향 출처를 갖고 있습니다.
source_refs: - SRC-001 - SRC-003 - SRC-013 - SRC-042 - SRC-045 - SRC-053 - SRC-055
여기에 역방향 추적을 적용하면, 각 Source 쪽에는 이런 정보가 생깁니다.
## 기여한 문서 - [[40.Projects/02.GPTers Case Posts/01-llm-wiki-build|AI에게 매번 설명하지 않으려고, Obsidian에 개인용 LLM Wiki를 만들었습니다]] - 기여 방식: LLM Wiki 개념 설명, Source ID 구조, ingest 운영 흐름 설명에 사용됨 - 산출물 유형: GPTers 게시용 글 - 반영일: 2026-05-25
예를 들어 SRC-042 요약 문서에 붙이면 이런 느낌입니다.
---
type: source_summary
source_id: SRC-042
status: linked
source_refs: []
used_by: artifacts: - "40.Projects/02.GPTers Case Posts/01-llm-wiki-build.md" wiki: []
---
본문에는 이렇게 적습니다.
## 기여한 문서 - [[40.Projects/02.GPTers Case Posts/01-llm-wiki-build]] - 초보자용 LLM Wiki 설명 문단의 근거로 사용됨 - 원문을 그대로 옮긴 것이 아니라, 게시용 글에 맞게 재구성됨
그리고 중앙 인덱스를 만들면 더 보기 쉬워집니다.
Source ID
Used By
Type
Contribution
SRC-001
40.Projects/02.GPTers Case Posts/01-llm-wiki-build.md
artifact
LLM Wiki 원문 아이디어와 전체 구조 설명
SRC-003
40.Projects/02.GPTers Case Posts/01-llm-wiki-build.md
artifact
Harness, Obsidian, AI 작업 루프 설명
SRC-013
40.Projects/02.GPTers Case Posts/01-llm-wiki-build.md
artifact
LLM Wiki를 Harness Engineering 기반으로 해석
SRC-042
40.Projects/02.GPTers Case Posts/01-llm-wiki-build.md
artifact
초보자용 LLM Wiki 설명 재구성
SRC-045
40.Projects/02.GPTers Case Posts/01-llm-wiki-build.md
artifact
LLM Wiki와 Harness Engineering 관계 설명
SRC-053
40.Projects/02.GPTers Case Posts/01-llm-wiki-build.md
artifact
Inbox README 제외 규칙 설명
SRC-055
40.Projects/02.GPTers Case Posts/01-llm-wiki-build.md
artifact
Query workflow 후속 과제 설명
핵심은 이렇게 됩니다.
산출물에는 source_refs로 "무엇을 근거로 만들었는지"를 남긴다.
Source 쪽에는 used_by 또는 usage index로 "내가 어디에 쓰였는지"를 남긴다.
원문 파일 자체는 수정하지 않는다.
이렇게 하면 SRC-042를 봤을 때 “아, 이 자료가 단순히 요약만 된 게 아니라 GPTers 게시글에도 기여했구나”를 바로 알 수 있습니다.
그래서 이것은 나에게 유용한 정보가 될 것으로 생각됐다. 적용하기로 결정했다.
그런데, yaml frontmatter에 표시된 src-xxx로 연결된 문서들은 링크가 됐는지, 가능한지 궁금했다.
이게 문서 내에서 링크가 돼 있어야 의미가 있을 것 같았다. 그런데 frontmatter도 링크가 되는지 그것도 궁금했다.
그래서 물어봤다.
여기에 대한 답변은 다음과 같았다.
네. 핵심만 말하면:
source_refs: - SRC-001은 링크가 아닙니다. 그냥 문자열이에요.
Obsidian에서 frontmatter/properties 안에도 링크는 가능합니다. 공식 문서 기준으로 텍스트/리스트 property에는 Internal link를 넣을 수 있고, YAML에서는 따옴표로 감싸야 합니다. 또 Obsidian Bases의 file.links는 frontmatter 안의 링크도 포함한다고 설명합니다.
그래서 현재 방식은:
source_refs: - SRC-001 - SRC-042
Obsidian 링크가 아니라 “기계가 읽기 좋은 Source ID 목록”입니다.
링크로 만들려면 이렇게 해야 합니다.
source_refs: - "[[20.Wiki/01.Sources/SRC-001_llm-wiki|SRC-001]]" - "[[20.Wiki/01.Sources/SRC-042_inbox-llm-wiki-teaching-note-review|SRC-042]]"
다만 저는 이 위키에는 아래처럼 ID 필드와 링크 필드를 분리하는 방식이 제일 좋아 보입니다.
source_refs: - SRC-001 - SRC-042
source_links: - "[[20.Wiki/01.Sources/SRC-001_llm-wiki|SRC-001]]" - "[[20.Wiki/01.Sources/SRC-042_inbox-llm-wiki-teaching-note-review|SRC-042]]"
이러면 source_refs는 lint/검색/자동 처리용으로 안정적이고, source_links는 Obsidian에서 클릭 가능한 링크가 됩니다.
그리고 사람이 읽는 문서 본문에도 한 번 더 두면 가장 좋습니다.
## 근거 Source - [[20.Wiki/01.Sources/SRC-001_llm-wiki|SRC-001]]: LLM Wiki 원문 아이디어
- [[20.Wiki/01.Sources/SRC-042_inbox-llm-wiki-teaching-note-review|SRC-042]]: 초보자용 LLM Wiki 설명 초안
정리하면: frontmatter 링크는 가능하지만, 현재 SRC-xxx만 적은 것은 링크가 아닙니다. 운영상으로는 source_refs는 ID로 유지하고, source_links나 본문 근거 Source 섹션에 실제 Obsidian 링크를 두는 게 제일 균형이 좋아요.
결국 이것은 내가 결정해야 할 문제로 남게 되었다. 따라서 아직 본격적으로 문서들을 ingest하기 전에 이 규칙을 어떻게 할 것일지를 결정해야 한다. 그래서 다음 시간에는 다른 사람들이 만들어놓은 llm wiki 제작 규칙을 살펴보고 나의 규칙과 비교해보기로 했다.
네 번째 문제
각 schema의 적용 범위를 어떻게 설정할지이다. 전역/지역으로 구분될 수 있는데, 이 구분을 결국 내가 해야 할텐데 나도 사실 확신을 하지 못하는 문제가 있어서 이 구분을 계속 미루고 있다. 또한 마음 한 편으로는 '과연 이 구분이 필요할까?'라는 의문이 떠나지 않고 있기 때문에 주저하는 것도 있다.
위의 내용을 프롬프트로 해서 그대로 codex에게 물었더니 다음과 같은 답변이 나왔다.
그 주저는 꽤 건강한 신호라고 봅니다. 지금 단계에서 전역/지역 schema를 너무 빨리 나누면, 위키가 “쓰기 위한 도구”가 아니라 “규칙을 관리하기 위한 도구”가 될 수 있어요.
제 추천은 이겁니다.
전역/지역을 먼저 완벽히 나누지 말고, “기본값 + 예외”로 시작하세요.
전역 schema = 모든 문서에 적용되는 최소 안전장치 지역 schema = 특정 폴더/문서유형/워크플로우에서만 의미 있는 규칙
예를 들면:
규칙
적용 범위
이유
created, updated, type, status
전역
거의 모든 문서에서 의미 있음
source_refs
전역
출처 추적은 위키 전체의 핵심 원칙
tags를 Obsidian wikilink로 쓰기
전역
검색/연결 방식의 공통 규칙
private 자료는 80.Private에 둠
전역
보안/노출 문제
Inbox README는 ingest 제외
전역에 가까움
ingest 전체에 영향을 줌
뉴스레터 Stage 승인 규칙
지역
뉴스레터 workflow에서만 의미 있음
법률강의 transcript는 강의 요약본 생성
지역
법률강의 자료에만 해당
GPTers 사례글 구조
지역
40.Projects/02.GPTers Case Posts에만 해당
더 정확히는 2단계보다 3단계가 좋아 보입니다.
1. Core Schema 위키 전체의 공통 생존 규칙 2. Type Schema document, transcript, artifact, workflow, decision 같은 type별 규칙 3. Project/Folder Schema 뉴스레터, 법률강의, GPTers 사례글처럼 특정 작업 영역 규칙
판단 기준은 단순하게 잡으면 됩니다.
이 규칙을 어기면 위키 전체가 헷갈리는가? -> 전역 이 규칙을 어겨도 특정 작업물만 이상해지는가? -> 지역 아직 잘 모르겠는가? -> 전역으로 올리지 말고 "local/default 후보"로 둔다`
그리고 “이 구분이 필요한가?”에 대한 제 답은: 완벽한 구분은 필요 없고, 최소한의 구분은 필요합니다.
왜냐하면 source_refs, private, Source ID 같은 건 전역이어야 AI가 안정적으로 움직입니다. 반대로 뉴스레터 승인 단계나 GPTers 글쓰기 구조까지 전역으로 올리면, 다른 문서를 만들 때 불필요한 규칙이 계속 끼어들어요.
그래서 지금은 이렇게 정하면 좋겠습니다.
기본 원칙: 새 규칙은 처음부터 전역으로 승격하지 않는다. 1. 먼저 해당 문서나 workflow 안의 지역 규칙으로 둔다. 2. 같은 규칙이 3개 이상의 문서 유형에서 반복되면 type schema로 올린다. 3. 위키 전체의 안정성에 영향을 주면 core schema로 올린다.
한 줄로 줄이면:
Schema는 먼저 지역에서 태어나고, 반복되거나 위험해질 때 전역으로 승격된다.
이렇게 하면 지금처럼 확신이 부족한 상태에서도 결정을 미루는 게 아니라, “유보를 운영 방식으로 만든 것”이 됩니다.
이건 회피가 아니라 좋은 설계에 가까워요.
이러한 좋은 방안이 나왔다.
2단계(전역/지역)보다 3단계(전역/유형별/프로젝트, 폴더별)로 나누는 것이 좋다.
Schema는 먼저 지역에서 태어나고, 반복되거나 위험해질 때 전역으로 승격된다.
IR 자료 20개를 AI로 분석해 신사업 아이디어를 뽑아본 후기
소개
최근 신사업 아이디어를 구상하기 위해 여러 분야의 IR 자료를 모아 AI로 분석해보는 실험을 진행했습니다.
수집한 자료는 전시영상, VFX, 애니메이션, 엔터테인먼트, 교육, 댄스 등 다양한 업체들의 IR 자료였습니다.
처음 시도한 이유는 단순했습니다.
여러 업계의 사업 구조를 빠르게 비교해보고 싶었다.
각 회사가 어떤 방식으로 성장 전략을 설명하는지 보고 싶었다.
흩어진 자료 속에서 새로운 사업 기회를 발견해보고 싶었다.
혼자 보기에는 시간이 오래 걸리는 자료를 AI의 도움으로 빠르게 요약하고 싶었다.
즉, 이번 실험의 목적은 IR 자료를 기반으로 시장 흐름과 사업 아이디어의 단서를 찾는 것이었습니다.
진행 방법
1. IR 자료 수집
먼저 다양한 분야의 기업 IR 자료를 약 20개 정도 수집했습니다.
수집한 분야는 다음과 같았습니다.
전시영상
VFX
애니메이션
엔터테인먼트
교육
댄스
기타 콘텐츠/미디어 관련 분야
자료를 모은 뒤, 각 자료에서 사업 모델, 핵심 역량, 타깃 시장, 수익 구조, 성장 전략 등을 중심으로 살펴보고자 했습니다.
2. 사용한 AI 도구
이번 실험에서는 유료 도구와 무료 도구를 함께 사용했습니다.
유료 도구
ChatGPT
Gemini
Manus
Claude
무료 도구
Grok
Genspark
Perplexity
각 도구마다 장단점이 달랐습니다. 어떤 도구는 자료 요약이 편했고, 어떤 도구는 아이디어 확장에 강점이 있었고, 어떤 도구는 검색 기반 확인에 유용했습니다.
아이디어를 너무 추상적으로 말하지 말고, 실제 실행 단계와 초기 고객 확보 방법까지 포함해주세요.
결과와 배운 점
1. 자료 정리에는 도움이 됐다
AI를 활용하니 많은 IR 자료를 빠르게 훑고, 핵심 내용을 요약하는 데는 확실히 도움이 됐습니다.
특히 여러 회사의 사업 구조나 키워드를 비교할 때는 사람이 처음부터 끝까지 읽는 것보다 훨씬 빠르게 큰 흐름을 잡을 수 있었습니다.
예를 들어 AI는 다음과 같은 내용을 비교적 빠르게 정리해줬습니다.
각 기업의 주요 사업 영역
반복적으로 등장하는 시장 키워드
수익 모델의 공통점
콘텐츠 산업에서 확장 가능한 방향
교육, 엔터테인먼트, 기술이 만나는 지점
2. 하지만 신사업 아이디어의 깊이는 기대보다 아쉬웠다
아쉬운 점도 있었습니다.
IR 자료를 많이 넣는다고 해서 곧바로 좋은 신사업 아이디어가 나오는 것은 아니었습니다.
특히 다음과 같은 한계가 있었습니다.
결과가 다소 일반적인 아이디어로 나오는 경우가 많았다.
업계 맥락을 깊게 이해한 전략이라기보다는 키워드 조합처럼 느껴질 때가 있었다.
자료가 많아질수록 토큰과 크레딧 소모가 생각보다 컸다.
유료 도구를 사용해도 원하는 수준의 결과물을 한 번에 얻기는 어려웠다.
결국 AI가 모든 방향을 알아서 잡아주기를 기대하면 만족도가 낮아질 수 있다는 것을 느꼈습니다.
3. 비용과 사용량 관리가 중요했다
이번 실험에서 가장 크게 체감한 부분은 비용이었습니다.
유료 AI 도구를 여러 개 사용하면서 IR 자료를 많이 넣고 반복 분석을 하다 보니, 생각보다 토큰과 크레딧이 빠르게 소모됐습니다.
특히 긴 PDF나 여러 개의 자료를 한 번에 분석할 때는 사용량 관리가 중요했습니다.
다음에는 이런 방식으로 개선해볼 계획입니다.
자료를 한 번에 넣기보다 업종별로 나누기
먼저 사람이 핵심 페이지를 추려서 넣기
AI에게 전체 분석을 맡기기 전에 분석 기준을 먼저 정하기
같은 질문을 반복하기보다 단계별 프롬프트를 설계하기
아이디어 도출 전에 시장, 고객, 수익 모델 기준을 명확히 하기
4. 핵심은 “AI에게 맡기는 것”보다 “AI와 같이 만드는 것”이었다
이번 실험을 통해 가장 크게 배운 점은 이것입니다.
AI는 신사업을 대신 만들어주는 도구라기보다, 사람이 가진 방향성을 정리하고 확장해주는 도구에 가깝다.
AI가 좋은 결과를 내기 위해서는 먼저 사람이 다음과 같은 기준을 잡아줘야 했습니다.
어떤 시장을 보고 있는지
어떤 고객 문제를 해결하고 싶은지
어떤 기술이나 자산을 활용할 수 있는지
어느 정도 규모의 사업을 생각하는지
실행 가능한 범위가 어디까지인지
내가 만들고 싶은 비전이 무엇인지
자료만 많이 넣는 것보다 중요한 것은 확실한 방향성, 명확한 질문, 그리고 정리된 비전이었습니다.
마무리
이번 ChatGPT 자동화 실험은 완벽한 결과물을 얻었다기보다는, AI를 활용한 신사업 기획의 가능성과 한계를 동시에 확인한 경험이었습니다.
IR 자료 분석 자체는 AI가 충분히 도와줄 수 있었습니다.
하지만 좋은 신사업 아이디어를 만들기 위해서는 AI에게 모든 것을 맡기기보다, 사람이 먼저 방향을 정하고 AI와 함께 다듬어가는 과정이 필요했습니다.
앞으로는 단순히 “자료를 넣고 아이디어를 뽑는 방식”에서 더 나아가, 다음과 같은 흐름으로 실험해보고 싶습니다.
내가 생각하는 사업 방향과 비전 정리
관련 IR 자료 수집
AI를 통한 공통 패턴 분석
아이디어 후보 도출
실행 가능성 검토
초기 고객과 수익 모델 검증
결국 AI 자동화의 핵심은 시간을 줄이는 데만 있는 것이 아니라, 생각을 더 구조화하고 더 나은 질문을 만들게 해주는 것이라는 점을 배웠습니다.
도움 받은 글 (옵션)
OpenAI 공식 가격 및 사용량 안내
Google Gemini 공식 가격 및 플랜 안내
Anthropic Claude 공식 플랜 및 사용량 안내
Manus 공식 크레딧/가격 안내
Perplexity 공식 플랜 안내개
NotebookLM 실험기: 소스의 양과 질, 그리고 프롬프트가 AI 결과물을 얼마나 바꾸는가?
소개
"AI에게 같은 질문을 해도, 무엇을 얼마나 보여주느냐에 따라 답이 이렇게 달라진다."
저는 현재 사상체질 한의학 관련 콘텐츠를 정리하는 작업을 하고 있습니다. 보유하고 있는 임상 자료가 총 31개의 문서로 상당한 분량이다 보니, 이 자료들을 어떻게 AI에 투입하느냐에 따라 결과물의 품질이 달라질 것이라는 가설이 생겼습니다.
특히 두 가지 변수가 궁금했습니다.
소스의 양과 질: 자료를 전부 넣었을 때와 일부만 넣었을 때, 그리고 내가 직접 고른 자료와 무작위로 고른 자료가 결과물에 어떤 차이를 만드는가?
프롬프트의 구체성: 같은 자료라도 "4체질로 정리해줘"와 "8체질로 세분화해줘"라는 지시의 차이가 결과물의 깊이와 정확성에 어떤 영향을 미치는가?
한의학을 모르는 분들도 이해할 수 있도록 설명하자면, 사상체질 의학은 사람을 태음인·소양인·소음인·태양인 4가지 유형으로 나눠 각자에게 맞는 건강 관리법을 제시하는 한국 전통 의학입니다. 더 정밀하게는 각 체질을 다시 2개로 세분화해 총 8가지 유형으로 구분하기도 합니다. 이 실험은 한의학의 옳고 그름을 따지는 것이 아니라, AI가 전문 지식을 얼마나 충실하게 재구성하는가를 검증하기 위한 것입니다.
진행 방법
사용한 도구
NotebookLM (Google): 소스 문서를 업로드하고 보고서를 생성하는 메인 도구
Claude (Anthropic): 5개의 생성 결과물을 비교 분석하는 도구
실험 설계: 2×2+1 구조
총 5가지 조건 조합으로 실험을 구성했습니다.
문서
소스 조건
프롬프트 조건
lm1
31개 중 무작위 선택 9개
4체질 (분류 체계 지시 없음)
lm2
전체 31개
4체질 (분류 체계 지시 없음)
lm3
전체 31개
8체질 세분화 명시 요청
lm4
선별된 9개
4체질 (분류 체계 지시 없음)
lm5
선별된 9개
8체질 세분화 명시 요청
lm4와 lm5의 '선별 9개'란? 총 31개 자료 중 생리 지표·체질 분류·처방 정보가 고루 담긴 핵심 자료 9개를 직접 선별한 것입니다. lm1의 '무작위 9개'와 대비됩니다.
사용한 프롬프트 전문
[4체질 조건 공통 프롬프트 — lm1, lm2, lm4에 사용]
임상 20년차 한의사로서, 환자들이 이 보고서를 읽었을 때,
본인의 체질을 즉각적으로 분류할 수 있도록,
각 체질의 생리(대변, 소변, 소화, 식욕, 땀..) 등에 따른 차이,
병리적 차이(질병 상태일 때의 각 체질별 차이..), 치법 및 관리 방법을 제시하는 보고서를 만들어줘
[8체질 세분화 추가 프롬프트 — lm3, lm5에 사용]
임상 20년차 한의사로서, 환자들이 이 보고서를 읽었을 때,
본인의 체질을 즉각적으로 분류할 수 있도록,
각 체질의 생리(대변, 소변, 소화, 식욕, 땀..) 등에 따른 차이,
병리적 차이(질병 상태일 때의 각 체질별 차이..), 치법 및 관리 방법을 제시하는 보고서를 만들어줘. 소스에 제시된 8가지 분류로 4개의 체질을 세부적으로 각 2체질로 나눠
총 8개의 체질로 판단할 수 있도록 정리해줘
두 프롬프트의 차이는 단 두 문장, 8체질 세분화 요청의 유무입니다. 이 작은 차이가 결과물 전체의 구조와 깊이를 얼마나 바꾸는지가 이번 실험의 핵심 관찰 포인트였습니다.
#1. 소스의 양이 만드는 차이: lm1(무작위 9개) vs lm2(전체 31개)
조건 요약
두 문서 모두 동일한 4체질 프롬프트를 사용했습니다. 차이는 오직 NotebookLM에 넣어준 자료의 수뿐입니다.
결과 비교
lm1 (무작위 9개) 은 생리 지표 설명에 집중된 구성을 보였습니다. 예를 들어 대변 상태에 대해 이렇게 설명합니다.
소양인: 대변이 가장 굵고, 하루라도 변비가 생기면 몸에 열이 쌓이는 위험 신호
소음인: 가래떡 정도의 중간 굵기, 체질 중 가장 길게 나오는 것이 이상적
일상 언어로 쉽게 풀어낸 표현이 돋보이고, 환자용 체크리스트로 바로 활용 가능한 수준입니다. 그러나 처방약이나 한약재 정보는 거의 등장하지 않습니다. 무작위로 선택된 9개 자료에 해당 내용이 충분히 포함되지 않았기 때문으로 보입니다.
lm2 (전체 31개) 는 같은 질문에 훨씬 풍부한 레이어로 응답했습니다.
외형과 걸음걸이 비교표
생리 지표별 4체질 상세 비교표
체질별 위험 신호 설명
핵심 한약재와 처방의 임상 작용 기전
체질별 권장·금기 음식 목록
특히 주목할 만한 점은, 단순히 "이 약이 좋다"를 나열하는 것이 아니라 왜 좋은지를 연결한다는 것입니다. 예를 들어 태음인의 '청심연자탕'에 대해 "단순히 심장약이 아니라, 폐가 약해 탁기를 걸러주지 못해 생기는 심계항진을 해결하기 위해 폐와 심장을 동시에 정화한다"고 기전을 설명합니다. 이런 연결은 여러 소스가 함께 있을 때만 만들어질 수 있는 정보입니다.
배운 점
소스의 양은 단순히 '정보 분량'의 차이가 아니라, 맥락 간 연결을 생성하는 능력의 차이를 만듭니다. NotebookLM은 여러 소스를 교차 참조해 단일 소스에서는 나오지 않는 인사이트를 생성합니다.
#2. 소스의 질이 만드는 차이: lm1(무작위 9개) vs lm4(선별 9개)
조건 요약
두 문서 모두 9개 소스, 동일한 프롬프트를 사용했습니다. 차이는 9개 자료를 무작위로 골랐는가 vs 직접 선별했는가입니다.
결과 비교
lm4 (선별 9개) 의 경우, 분량과 구조 면에서 lm1보다 더 체계적인 보고서가 나왔습니다. 4단계 접근법(외형→생리지표→병리→처방·음식)으로 구성되었고, 처방명과 약재 정보도 포함되었습니다.
그러나 동일 문서 내 정보 충돌이 발견되었습니다. 소음인 관련 음식표에서는 '우유'를 이로운 음식으로 분류했다가, 같은 문서 다른 섹션에서 "소음인이 아침에 우유와 토스트를 즐기면 담석증 발생 위험이 높아진다"고 경고합니다. 이는 선별된 9개 소스 사이에 해당 정보에 대한 서로 다른 기술이 존재했을 때, NotebookLM이 이를 하나의 일관된 결론으로 통합하지 못하고 그대로 병치한 결과로 보입니다.
lm1 (무작위 9개) 은 정보 충돌은 없었지만, 처방 정보 자체가 없었습니다. 내용의 일관성은 높지만, 그것은 다루는 주제의 범위가 처음부터 좁았기 때문입니다.
배운 점
소스 선별의 목적이 '주제 집중'이라면 효과적이지만, 선별된 소스들 사이에 정보가 충돌할 경우 NotebookLM은 이를 자동으로 해소하지 못합니다. 소스를 선별할 때는 내용의 일관성도 사전에 검토해야 합니다.
#3. 프롬프트 한 줄의 차이: lm2(4체질) vs lm3(8체질)
조건 요약
두 문서 모두 전체 31개 소스를 사용했습니다. 차이는 오직 8체질 세분화를 명시적으로 요청했는가의 여부입니다.
결과 비교
lm2 (4체질) 에서 태음인은 하나의 통일된 유형으로 다뤄집니다. "태음인은 땀이 잘 나야 건강하다"가 성립하는 단일 명제의 세계입니다.
lm3 (8체질) 에서 태음인은 두 유형으로 나뉩니다.
위완계 태음인: 찬 기운에 약하고, 땀이 거의 없으며, 대변이 무른 편. 감기에 걸리면 땀을 내는 치료가 핵심.
간계 태음인: 간의 열이 많고, 줄줄 흐르는 땀이 나며, 대변이 단단하거나 변비 경향. 감기에 걸리면 근육의 긴장을 푸는 치료가 우선.
이 두 유형은 같은 약재에 완전히 다르게 반응합니다. lm2에서 "커피는 태음인의 숙면에 도움이 된다"고 단순화된 내용이, lm3에서는 "위완계에게는 숙면을 돕는 보약이 될 수 있지만, 간계가 마시면 심장 두근거림과 불면을 유발한다"로 세분화됩니다. lm2의 단순화된 정보가 실제로는 잠재적 오정보가 될 수 있음을 lm3이 보완하고 있는 것입니다.
그러나 대가도 있습니다. lm3의 분류 체계는 '위수심한', '간수열이열'과 같은 전문 용어가 설명 없이 등장하며, 일반 독자가 자신을 8분류 중 어디에 위치시키기는 쉽지 않습니다.
배운 점
8체질 세분화 프롬프트는 임상 정확성을 높이는 대신 환자 전달력을 희생시키는 명확한 트레이드오프를 만들었습니다. 목적에 따라 프롬프트를 달리해야 합니다. 전문가용 감별 기준이 필요하다면 lm3 방식이, 환자 교육 자료가 목적이라면 lm2 방식이 더 적합합니다.
#4. 소스가 적을 때 8체질 요청의 한계: lm4(선별9·4체질) vs lm5(선별9·8체질)
조건 요약
두 문서 모두 선별된 9개 소스를 사용했습니다. 차이는 8체질 세분화 요청의 유무입니다.
결과 비교
lm5 (선별9·8체질) 는 8체질 구조로 결과물을 생성했지만, lm3(전체31·8체질)과 비교하면 세분화의 근거가 다소 빈약합니다. 대변 관찰 지표는 오히려 lm5가 더 정밀한 면도 있습니다. 대변의 시작 부분이 딱딱하고 끝이 무른 경우(두조미활)는 병이 나아가는 신호, 반대로 시작이 무르고 끝이 딱딱한 경우(두활미조)는 병이 낫지 않는 신호라는 구체적 기준을 제시합니다. 이는 선별 9개 소스에 이 내용이 집중적으로 포함되어 있었기 때문으로 보입니다.
그러나 처방과 약재 기전 설명에서는 "인삼으로 위장을 데운다" 수준을 크게 벗어나지 못했습니다. 8체질 구조를 요청했지만, 소스에 각 세부 체질별 처방 정보가 충분히 없으면 그 틀을 채울 내용이 부족한 것입니다.
배운 점
구조(프롬프트)와 내용(소스)은 함께 갖춰져야 합니다. 정밀한 분류 체계를 요청해도, 소스 안에 그 분류를 채울 정보가 없으면 껍데기 구조만 남습니다.
결과와 배운 점
5개 조건 종합 비교
조건
임상 정확성
환자 전달력
정보 일관성
권장 활용
lm1 (무작위9·4체질)
낮음
높음
높음
환자용 자가 체크리스트
lm2 (전체31·4체질)
높음
높음
높음
교육 자료, 안내문
lm3 (전체31·8체질)
매우 높음
낮음
높음
전문가용 감별 기준표
lm4 (선별9·4체질)
중간
중간
낮음
초안 참고용
lm5 (선별9·8체질)
중간
낮음
중간
중급 이상 독자용
핵심 발견 세 가지
1. 소스의 양보다 소스 간 '연결 가능성'이 중요합니다 전체 31개를 넣었을 때 결과물의 품질이 가장 높았던 이유는 단순히 정보량 때문이 아닙니다. 여러 소스가 동일한 주제를 다른 각도에서 다루고 있을 때, NotebookLM이 이를 교차 참조해 단일 소스에서는 나오지 않는 새로운 연결을 만들어냅니다.
2. 소스 선별은 일관성 검토와 함께해야 합니다 9개를 직접 선별한 lm4에서 동일 문서 내 정보 충돌이 발생했습니다. 좋은 소스를 고르는 것만큼, 선별된 소스들 사이에 상충하는 내용이 없는지 사전에 확인하는 것이 필요합니다.
3. 프롬프트의 구체성은 용도에 맞게 설계해야 합니다 8체질 세분화 요청은 전문성을 높였지만 접근성을 낮췄습니다. 결과물의 최종 독자가 누구인지, 어떤 목적으로 쓸 것인지에 따라 프롬프트의 방향이 달라져야 합니다.
시행착오
무작위 9개 선택의 함정: lm1을 만들 때 무작위로 선택한 9개 자료에 처방 관련 내용이 거의 없었습니다. 결과물이 '생리 지표' 중심으로만 나온 것은 NotebookLM의 한계가 아니라 소스 구성의 문제였습니다. AI에게 없는 정보를 만들어내라고 할 수는 없습니다.
8체질 용어의 장벽: lm3과 lm5에서 8체질 세분화 결과물이 나왔지만, 전문 용어를 일반 독자 언어로 다시 풀어주는 후처리 작업이 별도로 필요했습니다. NotebookLM은 소스에 있는 언어 수준을 그대로 반영하는 경향이 있습니다.
앞으로의 계획
이번 실험을 통해 가장 좋은 결과를 낸 조건(lm2: 전체 31개 + 4체질 프롬프트)을 기반으로, lm3의 8체질 세분화 내용을 일반 독자 언어로 재서술하는 후처리 작업을 진행할 예정입니다. 즉, NotebookLM으로 전문가 수준의 정보를 추출하고, Claude로 일반 독자용 언어로 변환하는 2단계 워크플로우를 구축해볼 계획입니다.
도움 받은 글 (옵션)
Google NotebookLM 공식 가이드: https://notebooklm.google.com
사상의학 관련 임상 자료 31종 (자체 보유 자료)
Claude (Anthropic) - 5개 결과물 비교 분석 및 이 글 정리에 활용
## 📝 한줄 요약
YouTube Studio를 영상별로 들락날락하며 지표 보는 게 답답해서, Claude Code와 함께 **하루 만에** 내 채널 전용 분석 대시보드를 만들었다. 핵심은 "예쁜 차트"가 아니라 **거기서 다음 영상 기획용 action item을 뽑아내는 것**이라는 걸 깨달았다.
**바쁘시면 이것만 읽어도 돼요:**
- **사용한 도구와 목표**: Claude Code로 본인 YouTube 채널 전용 분석 대시보드 구축 — 영상별 지속률·CTR·트래픽 소스를 한 페이지에서 조회
- **가장 만족도 높았던 워크플로우**: docs 스킬로 YouTube API의 불가능한 부분부터 먼저 파악 → 그걸 반영한 PRD 작성 → /kkirikkiri 멀티 에이전트로 PRD 재검증 (이 3단 파이프라인)
- **검증 효과**: PRD 재검증 단계에서 본격 개발 전 P0(필수 픽스) 9건 + 핵심 P1 다수가 한 번에 도출됨
- **하루 안에 풀스택 완성**: 인증 + DB + YouTube API + 스케줄러 + 3개 UI 페이지를 한 세션에서
- **현실 트러블슈팅**: 포트 3000을 좀비 프로세스가 점유 → OAuth 콜백 URL 불일치로 로그인 자체가 안 될 뻔 → PowerShell로 진단·해결
- **배운 교훈**: 처음부터 "어디에 배포할지" 정하고 시작해라. 그리고 **지표 자체가 아니라 거기서 뽑는 action item이 진짜 가치다.**
## 🎯 이런 분들께 도움돼요
- YouTube/SNS 운영하는 1인 크리에이터 — 매번 Studio 메뉴 들락날락이 답답한 분
- AI 코딩 도구로 본인 업무용 도구를 만들고 싶은데 어디서 시작할지 막막한 분
- 한 번 시도했다가 PRD 단계에서 막막해서 그냥 코드부터 짜다가 망친 경험이 있는 분
## 😫 문제 상황 (Before)
YouTube Studio가 보여주는 분석은 영상별로 메뉴에 들어가서 봐야 한다. "이 영상은 알고리즘 추천이 몇 퍼센트, 검색 유입이 몇 퍼센트지?" "Shorts 평균 지속률이랑 비교하면 이 영상은 잘 나온 건가?" 같은 질문을 하려면 영상 하나하나 클릭해서 표를 따로 만들어야 했다.
**유튜브 지표를 빠르게 보고 판단하기 위해서** — 그게 시작이었다. 영상을 올린 다음 "다음 영상은 어떤 방향으로 갈지" 결정하려면 데이터를 빠르게 봐야 하는데, 매번 Studio 안에서 길을 잃었다.
그래서 결심했다. **한 페이지에서 다 보이는 내 전용 대시보드를 만들자.**
## 🛠️ 사용한 도구
- **도구명**: Claude Code (Anthropic 공식 CLI)
- **모델**: Claude Opus 4.7
- **활용한 외부 스킬**:
- 지피타쿠님의 docs 스킬 — 외부 API 문서를 정확히 읽고 한계를 파악해주는 스킬
- /kkirikkiri 스킬 — 자연어로 AI 에이전트 팀을 자동 구성해서 동시 검토 시키는 멀티 에이전트 스킬
---
## 🔧 작업 과정
### 1단계 — 코드부터 짜지 않고 "안 되는 것"부터 알아보기
이번 프로젝트에서 가장 결과물 만족도가 높았던 이유는 **시작을 잘 했기 때문**이다. 보통 AI 코딩을 한다고 하면 바로 "이런 거 만들어줘" 하고 코드부터 짜는데, 이번엔 의도적으로 한 단계를 더 두었다.
YouTube에는 두 종류의 API가 있다. 하나는 영상 메타데이터를 주는 Data API, 다른 하나는 시청률·노출수 같은 분석 지표를 주는 Analytics API. **각각이 뭘 줄 수 있고, 뭘 못 주는지를 모르고 PRD를 쓰면 십중팔구 헛것을 그리게 된다.**
그래서 먼저 지피타쿠님이 만드신 docs 스킬을 돌렸다. 이 스킬은 공식 문서를 정확히 읽고 "이런 dimension은 있고, 이런 건 없다" "이 API는 D-3 지연이 있어서 오늘 데이터는 못 받는다" 같은 한계를 정리해준다.
그렇게 **불가능한 것의 목록**을 먼저 받아두고, 그 위에서 PRD를 작성했다. 이게 나중에 엄청난 차이를 만들었다.
---
### 2단계 — 만든 PRD를 혼자 검토하지 않고 가상 전문가 팀에게 맡기기
PRD를 다 쓰고 나면 보통 "이 정도면 됐겠지" 하고 바로 구현 들어간다. 근데 이번엔 한 가지 더 했다.
```
/kkirikkiri 유튜브 전문가 관점으로 prd 체크해봐
```
/kkirikkiri는 자연어로 "이런 관점에서 검토 팀을 만들어줘" 하면 AI가 가상 전문가 4명을 자동으로 구성해서 동시에 검토시켜주는 스킬이다. 처음엔 Claude가 "어떤 관점이 필요하냐"고 묻길래 골랐다:
> 유튜브 전문가가 어떤 관점으로 PRD를 봐줬으면 좋겠어요?
선택지를 3개 골랐다 — **콘텐츠 성과 지표**, **YouTube API 제약·현실성**, **성장·알고리즘 인사이트**. 이렇게 시점이 다른 가상 전문가들이 동시에 PRD를 뜯어보고 문제점을 도출했다.
결과는 놀라웠다. 본격 코드를 한 줄도 짜기 전에 **반드시 고쳐야 할 P0 9건**이 한 번에 발견됐다. 예를 들면:
- Analytics API는 D-3 지연이 있어서 오늘 데이터는 못 받는다 → 화면에 "Analytics 데이터는 X일까지 반영"이라고 명시 필요
- 트래픽 소스를 raw 그대로 보여주면 종류가 너무 많다 → 알고리즘 / 검색 / 직접 / 기타 4그룹으로 정규화 필요
- 영상 삭제됐을 때 DB에서 지우면 과거 분석 데이터가 사라진다 → soft delete 패턴 필요
**이 9건을 PRD 단계에서 잡았기 때문에**, 나중에 구현하면서 "어 이거 안 되네" 하고 멈춰서 PRD를 다시 고치는 일이 거의 없었다.
---
### 3단계 — "한 번에 진행하자" 한 마디로 풀스택 앱 완성
PRD가 단단해진 다음엔 사실상 일사천리였다. Google Cloud Console 세팅(이건 처음이라 Claude한테 단계별 가이드 시킴), 자격증명 발급, pnpm 설치까지 끝낸 다음 한 마디 했다.
```
한번에 남은 작업 한번에 진행하자
```
이 한 마디로 Claude가 6개 작업을 한 번에 처리했다:
- 로그인 인증 시스템 (Google OAuth, 본인만 통과하는 화이트리스트)
- 데이터베이스 10개 테이블 설계
- YouTube API 호출 모듈 (쿼터 관리 포함 — 하루 한도 넘으면 자동 중단)
- 동기화 파이프라인 (영상 메타 + 일별 통계 + 트래픽 소스 + 지속률 곡선)
- 자동 스케줄러 (매일 새벽 3시에 자동 동기화)
- 3개 화면 (홈 KPI / 영상 목록 / 영상 상세)
이게 가능했던 이유는 **앞 단계에서 PRD가 단단했기 때문**이다. PRD가 흐릿하면 "한 번에 진행해" 시키면 100% 산으로 간다. 근데 PRD에 "이건 이렇게 해야 한다"가 명확히 적혀있으니까 Claude가 헷갈릴 일이 없었다.
---
### 4단계 — 첫 동기화 직전, 좀비 프로세스에게 발목 잡힐 뻔
로컬에서 처음 실행하는데 메시지가 떴다.
```
PS C:\Full_Ai\youtube_dashboard> pnpm dev
⚠ Port 3000 is in use by process 78816, using available port 3002 instead.
```
3000번 포트가 다른 프로세스에게 점유돼서 Next.js가 알아서 3002로 옮겨갔다. 보통이면 "오 그래 3002로 가자" 하고 넘어갈 일이다. **근데 Google OAuth 콜백 URL은 localhost:3000으로 고정 등록**돼 있었다. 3002에서 로그인 시도하면 "redirect_uri_mismatch"로 통째로 막힌다.
Claude에게 물었다.
```
포트 바꿔야되는거아냐?
```
Claude는 즉시 진단했다: "3000번 점유한 프로세스가 이전 세션의 좀비 next dev 서버다. 죽이는 게 맞다 — OAuth URL을 다시 등록하기보다." 그리고 PowerShell로 프로세스 ID 식별 → 강제 종료 → 포트 회수 → "이제 다시 pnpm dev 하면 3000번으로 뜬다"까지 정확히 안내했다.
**이런 환경 문제는 비개발자가 가장 잘 막히는 지점**인데, AI가 진단·해결까지 가이드해주니까 5분도 안 걸렸다.
---
### 5단계 — 첫 동기화 결과 화면이 의도대로 비어 있는 걸 확인한 순간
로그인하고 "수동 동기화" 한 번 누르니까 영상 3개가 적재됐다. 근데 시청시간·CTR·노출수 컬럼이 전부 "—"로 비어 있었다.
순간 "어 버그인가?" 했는데, Claude가 바로 짚어줬다.
> 이건 버그가 아닙니다. 오늘이 2026-05-22인데 Analytics API는 D-3 지연이 있어서 5-19까지만 데이터를 줍니다. 그런데 영상 업로드일이 5-20이에요. **영상이 업로드되기도 전 시점까지밖에 데이터가 없는 셈이라 비어 있는 게 정상.** 내일부터 채워집니다.
**1단계에서 docs 스킬로 D-3 지연을 미리 파악해뒀기 때문에**, 코드도 정확히 그렇게 짜져 있었던 거다. PRD 단계의 정확성이 끝까지 일관되게 이어진 순간이었다.
---
### 6단계 — 로컬용으로 만든 걸 Vercel 배포용으로 다시 만들기
여기서 한 가지 후회되는 게 있다. 처음엔 "내 PC에서만 돌면 되지" 싶어서 로컬 SQLite + 상주 스케줄러 구조로 만들었다. 근데 첫 동기화 성공한 다음에 생각이 바뀌었다.
```
이 페이지를 vercel 배포해볼까?
```
Vercel은 서버리스 환경이라서 **로컬용 구조가 통째로 안 맞는다**. SQLite 파일은 매번 휘발되고, 상주 스케줄러는 동작 자체를 안 한다. Claude가 옵션 3가지를 정리해서 보여주고 결정을 도와줬다 — 결국 리팩토링 진행.
DB는 Turso(libSQL)로, 스케줄러는 Vercel Cron으로 교체. 다행히 같은 날에 작업해서 코드가 머릿속에 살아있어 부담이 적었다. **하지만 일주일 뒤였으면 훨씬 큰 비용이 들었을 거다.**
이게 두 번째 교훈이다: **처음부터 "어디에 배포할지" 정하고 시작해라.**
---
## ✅ 결과 (After)
### Before vs After
| 항목 | Before | After |
|------|--------|-------|
| 영상별 지표 확인 | YouTube Studio에서 영상 하나씩 클릭, 표 따로 작성 | 한 페이지에서 전체 목록 + 정렬·필터 즉시 |
| Shorts vs Long 비교 | 직접 분류해서 평균 계산 | 자동 분리 + 평균 지속률 카드 분리 표시 |
| 본인 영상 vs 채널 평균 | 비교 불가능 | 영상 상세에 채널 평균 지속률 곡선 오버레이 |
| 트래픽 소스 분석 | 영상별 메뉴에서 raw 데이터 | 알고리즘/검색/직접/기타 4그룹 자동 정규화 + 드릴다운 |
| 의사결정 속도 | 데이터 모으는 데 시간 소요 → 판단 지연 | 페이지 로드 즉시 다음 영상 방향 판단 가능 |
| 자동 갱신 | 없음 (매번 수동 확인) | 매일 03:00 자동 동기화 (Vercel 배포 후 PC 안 켜도 됨) |
### 결과물
- 본인 YouTube 채널 전용 분석 대시보드 (3개 화면 — 홈 KPI / 영상 목록 / 영상 상세)
- 매일 새벽 자동 동기화 시스템
- 본인 외 다른 계정은 로그인조차 막힌 보안 구조
## 💬 이 과정에서 배운 AI 활용 팁
### 효과적이었던 것
1. **외부 API 쓸 거면 docs 스킬부터 돌려라**
"되는 것"보다 **"안 되는 것"**을 먼저 알아야 PRD가 현실적이다. YouTube Analytics의 D-3 지연, search.list 쿼터 100 같은 제약을 모르고 가면 한참 헤맨다.
2. **PRD를 혼자 검토하지 말고 /kkirikkiri 같은 멀티 에이전트로 재검증해라**
사람 한 명 시점에선 빈틈을 못 본다. 4명의 가상 전문가가 동시에 검토하면 P0 9건이 한 번에 잡힌다. 본격 개발 전에 이 단계를 거치는 비용 < 개발 도중에 발견해서 다시 만드는 비용.
3. **처음부터 "어디에 배포할지" 정하고 시작해라**
로컬용으로 만들었다가 클라우드용으로 다시 만드는 비용은 처음부터 클라우드용으로 만드는 비용과 비슷하다. 일주일만 늦어도 비용이 훨씬 커진다.
4. **단단한 PRD가 있을 땐 "한 번에 진행하자" 큰 위임을 무서워하지 마라**
AI가 6개 작업을 한 번에 처리할 수 있다. 단 **앞 단계에서 PRD가 단단해야** 통한다.
### 이렇게 하면 안 돼요
1. **PRD 없이 "이런 거 만들어줘" 한 마디로 시작하기**
초기엔 빨라 보이지만 결국 중간에 멈춰서 PRD 만들기를 반복하게 된다. 시작에서 30분 더 쓰는 게 전체 시간을 줄인다.
2. **API 한계를 안 보고 "그냥 다 가능하겠지" 가정하기**
YouTube Analytics가 오늘 데이터를 줄 거라 가정하고 UI를 짜면, 막상 받아보니 비어 있어서 화면이 깨진다.
3. **환경 문제(포트, 좀비 프로세스 등)를 혼자 끙끙대기**
"포트 3000 점유 중인 프로세스 뭐냐"만 물어봐도 AI가 PowerShell 명령어 + 해결 순서를 그대로 알려준다.
## 🌍 다른 업무에 적용한다면?
이 워크플로우 — **docs로 한계 파악 → PRD → /kkirikkiri 재검증 → 단계별 위임** — 는 외부 API에 의존하는 모든 도구 만들기에 그대로 통한다.
- **인스타그램·블로그 통합 분석 대시보드**: docs로 각 플랫폼 API 한계 파악 → 어떤 지표는 받을 수 있고 어떤 건 못 받는지 먼저 정리.
- **고객사 데이터 자동 리포트**: 고객사 CRM/Slack/Sheets API 제약을 먼저 docs로 확인 후 PRD.
- **이커머스 매출 모니터링**: 쇼피파이/네이버스마트스토어 API의 일별 호출 한도, 데이터 지연 같은 제약을 PRD에 미리 반영.
**핵심은 항상 같다 — "AI가 헛것을 그리지 않게, 시작 단계에서 현실 제약을 정확히 알려주는 것".**
## 🚀 앞으로의 계획
대시보드가 완성됐지만, 정말 중요한 건 차트 자체가 아니라 **거기서 어떤 action item을 뽑아낼 것인가**다. 다음 두 가지를 추가할 계획.
### 1. 자동 인사이트 생성기
동기화가 끝나면 영상별 지표를 LLM에 보내서 자동으로 분석을 받는다. 예:
> "이 영상은 알고리즘 추천 30% / 검색 50% — 검색 최적화가 잘 됐다. 다음 영상도 같은 키워드 전략 시도 권장."
이런 인사이트를 사이드바에 매일 새로 띄워서, **대시보드를 켜자마자 "오늘 뭘 해야 하는지"가 보이도록**.
### 2. 데이터 기반 영상 기획
"지금까지 검색 유입이 잘 됐던 영상들의 제목/태그/길이 공통점"을 분석해서, **다음 영상을 기획할 때 데이터 기반 결정**이 가능하게.
결국 분석 대시보드 → 행동 안내 시스템으로 진화시키는 게 다음 목표다.
## 📋 재사용 가능한 프롬프트
### 프롬프트 1: 외부 API의 한계 먼저 파악하기
> [API 문서 URL 또는 플랫폼 이름]의 공식 문서를 정확히 읽고, 다음을 정리해줘:
> 1. 받을 수 있는 데이터 종류
> 2. **받을 수 없는 데이터 (가장 중요)**
> 3. 호출 제한 (쿼터, 일일 한도)
> 4. 데이터 지연 (실시간인지, 며칠 늦는지)
> 5. 인증 방식과 만료 정책
>
> [플랫폼]은 본인이 분석하려는 외부 서비스로 바꿔서 쓰세요. (예: YouTube Analytics, 인스타그램 Graph API, 네이버 검색광고)
### 프롬프트 2: PRD를 가상 전문가 팀에게 재검증 받기
> /kkirikkiri [도메인] 전문가 관점으로 prd 체크해봐
>
> [도메인] 자리에 본인 프로젝트의 도메인을 넣으세요. (예: 유튜브, 이커머스, SaaS 운영) 검토 관점 선택지가 나오면, 본인 프로젝트에서 가장 위험할 것 같은 시점을 골라주세요 (예: API 제약, 사용자 시점, 데이터 일관성).
### 프롬프트 3: 단단한 PRD가 있을 때 큰 단위 위임
> 위 PRD 기반으로 Phase 1 작업 N개를 한 번에 진행해줘. 단,
> 1. 각 작업 시작 전에 어떤 파일을 만들/수정할지 한 줄로 알려줘
> 2. PRD에 명시되지 않은 부분은 임의로 결정하지 말고 나에게 물어봐
> 3. 마지막에 type-check + 동작 확인까지 같이
>
> N은 본인 작업 개수로 바꿔서 쓰세요.
### 프롬프트 4: 환경 문제 빠르게 진단
> [에러 메시지 or 증상] 발생했는데, 원인 진단하고 해결 명령어까지 한 번에 알려줘. 운영체제는 [Windows/Mac/Linux].
>
> 예: "포트 3000이 다른 프로세스에게 점유돼 있다. 운영체제는 Windows."
Claude로 주식 분석할 때 바로 복붙해서 쓸 수 있는 프롬프트 7개를 가져갈 수 있어요. Anthropic 공식 가이드와 실제 운용 사례를 종합해서 정리했고, 한국 투자자가 한국 주식·미국 주식 분석에 쓸 수 있는 형태로 다듬었습니다.
먼저 알아두면 좋은 사실 하나. 2026년 2월 출시된 Claude Sonnet 4.6이 Finance Agent v1.1 벤치마크에서 63.33%를 기록했어요. 출시 당시 1위였고, 현재는 Opus 4.7이 64.37%로 최고점이지만 여전히 Sonnet급에서는 압도적인 점수예요. Opus 4.6(60.05%)보다 Sonnet 4.6이 높았던 게 핵심 포인트입니다.
이 벤치마크는 vals.ai가 Stanford 연구진과 Goldman Sachs·Citadel 등 업계 전문가들과 함께 만든 외부 벤치마크예요. SEC 공시 기반으로 9개 카테고리에 걸친 537개 애널리스트 스타일 질문으로 구성되어 있어요. 10-K 파싱하고 마진 뽑아내고 주식 수 맞추는 작업에서 Claude가 가장 정확하다는 의미입니다.
여기서 흥미로운 포인트는, Sonnet 4.6이 Opus 4.6보다 잘했다는 거예요. 즉 모델이 한계가 아니라 프롬프트가 한계라는 뜻이에요. 좋은 프롬프트만 있으면 입력 $3/M 토큰의 Sonnet 4.6(Opus 4.6 입력 $5/M 대비 약 60% 가격)으로도 Wall Street 애널리스트급 결과를 받을 수 있습니다.
1. Wall Street 애널리스트 종합 분석 프롬프트
가장 기본이자 가장 강력한 프롬프트예요. 단일 종목을 매수/보유/매도 관점에서 종합 분석합니다.
시니어 Wall Street 애널리스트 역할로 [티커: 삼성전자 005930]을 분석해줘. 다음 항목을 모두 다뤄줘:
1. 매출 성장률 (최근 4분기 YoY)
2. 영업이익률·순이익률 추세
3. 부채비율과 현금흐름
4. 동종업계 대비 경쟁력
5. PER·PBR·PSR 기반 밸류에이션
6. 주요 리스크 3가지 마지막에 매수/보유/매도 추천을 명확한 근거와 함께 제시해줘.
핵심은 역할 부여 + 항목 명시 + 결론 강제예요. "분석해줘"만 던지면 인턴급 답변이 나오지만 이렇게 구조를 잡아주면 투자위원회에서 쓸 만한 분석이 나와요.
2. 10-K 위험 신호 탐지 (포렌식 분석가)
기업 연차 보고서에서 숨겨진 적신호를 찾는 프롬프트예요. 미국 주식 투자자에게 특히 유용해요.
포렌식 재무 분석가 역할로 [기업명]의 최근 10-K 파일을 검토해줘. 다음 카테고리에서 경고 신호를 찾아내줘:
- 매출 인식 방식의 변화
- 일회성 항목으로 처리된 경상적 비용
- 관계자 거래 (related party transactions)
- 재고 회전율 급변
- 영업현금흐름 vs 순이익 괴리
- 주석에 묻혀있는 우발채무 각 신호마다 구체적 페이지/문장을 인용하고,
신중한 애널리스트가 추가 조사해야 할 우선순위를 매겨줘.
이 프롬프트가 강력한 이유는 Claude가 10-K를 단순 요약하는 게 아니라 숨겨진 위험을 적극적으로 찾는 모드로 들어가기 때문이에요.
3. 산업 디스럽션 분석 — 5~10년 관점
장기 투자자용 프롬프트예요. 단기 실적이 아니라 산업 자체의 변화를 봅니다.
기술·산업 전략가 역할로 [업종: 자동차 산업]의
향후 5~10년 디스럽션 리스크를 분석해줘. 분석 프레임워크:
1. 가장 신뢰할 만한 디스럽션 시나리오 3가지
2. 각 시나리오의 발생 확률과 시점
3. 디스럽션 시 가장 타격받을 기존 플레이어
4. 가장 수혜받을 신규/기존 플레이어
5. 투자자가 지금 모니터링해야 할 선행 지표 5개
워런 버핏이 자주 말하는 "moat(해자)"가 진짜로 유효한지 검증할 때 쓰기 좋아요.
4. 한국 주식 기술적 분석 (한국투자증권 API 연동)
한국 주식을 자동으로 분석하려면 한국투자증권 모의투자 API와 결합하는 게 가장 안정적이에요. nocodetechstacker.com에서 공유한 실전 사례 기반입니다.
한국투자증권 모의투자 API를 통해 [종목코드: 005930 삼성전자]의
최근 20영업일 일봉 데이터를 가져와서 다음을 분석해줘: 1. 이동평균선 (5일/20일/60일) 정배열·역배열 여부
2. RSI(14) 과매수·과매도 진입 시점
3. MACD 골든크로스/데드크로스
4. 거래량 급증 일자와 그날의 가격 변동
5. 볼린저 밴드 상단·하단 터치 빈도 분석 결과를 표로 정리하고, 단기(5일) 매매 관점에서
주의할 신호 3가지를 알려줘.
여기서 핵심은 데이터 소스를 명시하는 거예요. "분석해줘"라고만 하면 Claude가 학습 데이터로 답하지만, "API로 가져온 데이터로 분석해줘"라고 하면 실제 데이터 기반 분석이 나옵니다.
*Photo by Mehedi Hasan on Unsplash*
5. 자동매매 시스템 설계 프롬프트 (Claude Code)
Claude Code로 자동매매 봇을 만들 때 쓰는 프롬프트예요. 5일 만에 AI 자동매매를 만든 사례에서 추출한 패턴입니다.
파이썬으로 한국투자증권 API 기반 자동매매 봇을 만들어줘. 기능 명세:
1. 매일 오전 9시에 코스피 시가총액 상위 30종목의 전일 종가·당일 시가 받아오기
2. 전일 대비 시가가 -2% 이상 갭다운한 종목을 후보 리스트에 저장
3. 당일 9:10에 후보 종목의 30분봉 데이터로 RSI(14) 계산
4. RSI 30 이하 종목 매수, 매수가 +3%에 익절·-2%에 손절
5. 매매 내역을 Google Sheets에 자동 기록
6. 일일 손익을 슬랙으로 발송 아래 단계로 진행해줘:
1단계: 전체 아키텍처 설계 검토
2단계: API 연결 부분만 먼저 구현·테스트
3단계: 매매 로직 구현
4단계: 모니터링·알림 추가
자동매매는 한 번에 다 만들면 디버깅이 지옥이에요. 단계별로 검증하면서 진행하는 게 핵심입니다.
6. 거인의 투자전략 복제 (백테스팅)
특정 투자자의 전략을 분석하고 자동으로 복제하는 프롬프트예요. 지피터스 멤버 분이 공개한 사례 기반입니다.
[투자자 이름: 워런 버핏]의 공개된 매매 기록 (13F 공시)을 기반으로
다음을 분석해줘: 1. 최근 5년간 매수·매도 패턴
2. 평균 보유 기간
3. 섹터별 비중 변화
4. 매수 시점의 공통 신호 (밸류에이션, 재무지표)
5. 매도 시점의 공통 신호 이 패턴을 Python 스크립트로 구현해서,
미국 주식 시장에 동일한 룰을 적용할 때
백테스팅 결과를 시뮬레이션할 수 있는 코드를 만들어줘.
⚠️ 백테스팅 결과는 과거 성과일 뿐 미래 수익을 보장하지 않아요. 참고용으로만 활용하세요.
7. 주식 분석 콘텐츠 검증·개선 프롬프트
본인이 쓴 주식 분석 글이 있다면 Claude로 교차 검증·개선할 수 있어요. 콘텐츠 발행 전 마지막 점검용으로 좋아요.
첨부한 주식 분석 초안을 다음 관점에서 검증·개선해줘: 1. 사실관계 검증 - 인용한 수치의 출처 확인 - 최근 분기 실적과 일치 여부 - 동종업계 비교 데이터 정확성 2. 논리 구조 검증 - 결론을 뒷받침하는 근거 충분성 - 반대 시나리오에 대한 고려 - 가정과 추론의 명시성 3. 가독성 개선 - 일반 투자자가 이해하기 쉬운 표현 - 핵심 메시지가 처음 3문단에 들어가 있는지 - 전문 용어에 대한 설명 추가 각 항목별로 수정 제안을 구체적으로 표시해줘.
저는 이 프롬프트로 주식 콘텐츠를 검증하면서 사실관계 오류를 잡은 적이 여러 번 있어요.
마무리
Claude로 주식 분석하는 핵심 원칙 5가지를 정리할게요:
역할을 명시하라 — "Wall Street 애널리스트", "포렌식 분석가" 같이 구체적 페르소나를 줘야 깊이가 나옵니다.
분석 항목을 미리 정의하라 — "분석해줘"가 아니라 "1. 매출, 2. 마진, 3. 부채..." 식으로 구조를 잡아주세요.
데이터 소스를 명시하라 — API 데이터인지, 10-K 파일인지, 학습 데이터인지 알려줘야 정확한 답이 나와요.
단계별로 검증하라 — 한 번에 다 시키지 말고 데이터 가져오기 → 분석 → 추천 순서로 끊어서 진행하세요.
결론을 강제하라 — "매수/보유/매도 추천을 명확한 근거와 함께"처럼 구체적 결론을 요구해야 두루뭉술한 답이 안 나옵니다.
원문:
Prompting strategies for financial analysis | Claude
Finance Agent v1.1 Benchmark | vals.ai
vals.ai 방법론
Claude Sonnet 4.6 출시 소식 | Anthropic
Anthropic 가격 정책
코딩 없이 AI 도구로 주식 기술적 분석하기 — Claude + 한국투자증권 API
클로드 코드를 이용한 주식 분석 agent 만들기 | GPTers
한국투자증권 KIS Developers
최근 SNS 계정들을 좀 키우고 싶었는데 쉽지 않더라고요.
시간을 아끼자해서 생각해낸게 X, 레딧, 쓰레즈, 릴즈 등을 AI가 주기적으로 모니터링 하고 저한테 슬렉으로 추천 댓글을 보내주는 것을 만들고 싶었습니다.
근데 이게 막상 만들려고 하니 플랫폼별로 API 전부 다르고, 데이터 받아오는 포맷도 다르고, 호출 방법도 다르고... 세네군데에서 따로 돈 내야하고 너무 불편하더라고요. 그리고 클로드가 쓸수있는 skill/MCP를 지원하는 곳도 없어서 사용법도 하나씩 알려줘야하고 그랬습니다.
저는 평소에 Firecrawl이라는 AI를 위한 웹 클롤링 서비스를 MCP로 자주 이용하는데, 왜 SNS 데이터는 이런 비슷한게 없지? 라는 생각이 들었고, 바로 클로드랑 대화하면서 한 2주일정도 걸려서 만든것같습니다.
주 스택은 NextJS(프랜트+백)와 Hono API(백앤드)를 사용했습니다! 그리고 최대한 무료/오픈소스 인프라를 이용하고 싶어서 좀 번거롭더라도 supabase가 아닌 NeonDB(데이터베이스), BetterAuth(로그인), Cloudflare R2(스토리지)로 했습니다. 프론트는 shadcn에서 컴포넌트 그대로 가져와서 사용했네요.
X, 쓰레즈, 인스타, 등 21개 SNS 모두 하나의 API로 받아올 수 있게 만들었습니다!
👉 socialcrawl.dev
혹시 관심있으신 분은 알려주세요 무료 크레딧 쿠폰 따로 드리겠습니다 🙂
-----------------------
(현재 해외에 거주하고 있지만, GPTers 만한 AI 커뮤니티가 없네요! 항상 많은 도움 받고 있고 앞으로도 커뮤니티에 적극적으로 참여하고싶습니다 :))
Message founders
관보 12.8만 건을 마크다운으로 변환해서 AI가 읽을 수 있게 만들었습니다
정부가 매일 발행하는 공식 기록이 있습니다. 관보(官報)입니다.
법률 공포, 인사발령, 고시, 공직자 재산공개까지 — 정부가 ‘했다’고 선언하는 모든 행위는 관보에 실려야 효력이 생깁니다. 조선시대 조보(朝報)부터 따지면 500년 된 기록 체계인데, 지금은 gwanbo.go.kr에서 PDF로 누구나 열람할 수 있습니다.
문제는 이 PDF를 AI에 넣으려고 하면 생깁니다.
왜 만들었나
중앙부처에서 일하면서 다른 부처 직제 개정이나 인사발령을 추적할 때 관보를 자주 봅니다. 그런데 매번 PDF를 열어서 눈으로 훑는 게 비효율적이었고, RAG에 넣으려 해도 매번 전처리부터 다시 해야 했습니다. 관보는 저작권법 제7조에 따라 자유 이용 대상이라 법적 장벽도 없습니다. 그래서 원본 PDF는 그대로 두고, 같은 내용을 AI가 읽기 쉬운 형태로 한 벌 더 만들자고 생각했습니다.
무엇을 만들었나
2020-01 ~ 2026-04, 약 128,000건의 관보를 Markdown + YAML frontmatter로 변환했습니다.
• 날짜별·기관별 정적 JSON 인덱스 제공 (CORS 제한 없음)
• 정적 HTML 리더에서 바로 탐색·본문 읽기 가능
• 외부에서 fetch해서 RAG / 임베딩 파이프라인에 바로 연결 가능
# 예시: 코퍼스에서 날짜·기관·본문 추출
from pathlib import Path
import re
ROOT = Path('derived/readable-corrected')
fm_re = re.compile(r'^---\n(.*?)\n---\n', re.DOTALL)
for md in ROOT.rglob('*.md'):
text = md.read_text(encoding='utf-8')
fm_match = fm_re.match(text)
body = text[fm_match.end():] if fm_match else text
yield {
'date': md.parent.name,
'inst': md.name.split('_')[1],
'body': body,
}
// 정적 인덱스 API — 브라우저에서 바로 fetch 가능
fetch('https://hosungseo.github.io/ai-readable-gazette-kr/data/meta.json')
.then(r => r.json())
.then(meta => console.log(meta.total_docs, meta.date_range));
OCR 파이프라인
PDF → 텍스트 추출에는 한글과컴퓨터의 오픈소스 오픈데이터로더(opendataloader)를 사용했습니다. 공공 데이터를 다루는 작업이니 도구도 국산 오픈소스 위에서 돌리는 게 맞다고 생각했습니다.
변환 과정에서 ‘위’→’옄’, ‘번’→’뮈’ 같은 OCR 깨짐이 있었는데, 사전 기반 12단계 보정 파이프라인을 만들어 자체적으로 고쳤습니다. 초기에 단일 글자를 무작정 전역 치환했다가 ‘모친동산’ 같은 과보정 사고가 나서, 지금은 1,000+ 샘플에서 이웃 글자 분포를 확인한 뒤에만 전역 치환을 허용하는 정책을 쓰고 있습니다. 오픈데이터로더 자체가 발전하면 깨진 글자도 줄어들 것이고, 도구가 좋아지면 코퍼스도 같이 좋아지는 구조입니다.
활용 시나리오
• Claude / ChatGPT에 날짜별 관보 md를 첨부해서 “이 날 어떤 인사발령이 있었나” 질문
• 법령 공포 이력을 시계열로 추적
• 기관별 고시·공고 트렌드 분석
• 공직자 재산공개 데이터 구조화
• 커스텀 GPT / RAG 시스템의 공공 법령 지식 베이스로 활용
링크
• 라이브 리더: https://hosungseo.github.io/ai-readable-gazette-kr/
• GitHub: https://github.com/hosungseo/ai-readable-gazette-kr
• 배경 에세이: https://gongpenclaw.substack.com/p/ai-readable
한 줄 요약
공개는 계속 중요하지만, 이제는 공개만으로 충분하지 않습니다. 공개 다음에는 AI-readable이 와야 합니다
목표 :
저번 주에 api 연결하지 못한 정비사업구역의 투자에 대해 디벨롭을 해보자.
하고 싶었던 일 :
내가 원하는 구역의 현재 정비사업이 진행되고 있거나 진행하는 상황을 지도에 표시해준다.
원하는 행정동에서 정비사업이 가능한 구역을 추천받거나, 또는 내가 지정한 폴리곤이 사업 가능한 곳인지 검토해준다.
AI 전문가 페르소나들이 주어진 지역에 대해 투자 가능성 분석 평가 의견을 준다.
- 사용도구
Claude code sonnet 4.5, Claude opus, Antigravity, Codex.
저번에 만들다 만 가이드가 있으니 그것에 API 연동하면서 함께 다양화 해보자.
Claude Code 의 토큰 이슈로 먼저 Codex 에 물어봅니다.
촤라락
어떤 API 가 있는지 잘 모르니..
이 외에도 주르륵 너무 많지만 이렇게 필요한 API 키를 받아 최대한 신청하여
Claude Code 로 저번 주 워크스페이스 수정에 필요한 것을 요청했습니다.
했더니
열심히 만들어 줬습니다.
사실 대화 내용은 정말 많고 긴데…
나름대로 여러 선정 기준을 교차 검증하여 분석할 수 있게 생각해보며
API 연결한다고 했는데
뭔가 나왔지만 지역 검색도 잘 안되고,
데이터도 거의 동일한 데이터만 나오고.
여러 번의 수정 요구와 윽박지름, 수 많은 5시간 기다림을 해보았지만.
실패입니다. ....
제 롤 모델은
이런 식의 표현과 폴리곤을 지정할 수 있고, 그에 따른 분석도 나오는 것이었는데.
일단은 실패로 끝났습니다.
결과와 배운 점
무언가 나의 접근 방식이 잘못되었다. - 하지만 뭔지 모르겠다.
다음엔 API 를 잘 섞어낼 수 있도록 Claude.md 에 지침을 잘 줘봐야겠다.?
너무 광범위하게 어렵게 풀어내려 한 것 같다.
간소화하되 중심을 가진 질문을 해야한다.?
시각화가 필요하면 참고 이미지나 결과 이미지를 주면
훨씬 좋은 결과물이 나온다.
이상입니다.
소개
아파트 매매와 전세 실거래가 데이터를 Streamlit 라이브러리를 활용하여 시각화해보았습니다.
당연히 데이터는 먼저 공공데이터포털에서 API를 활용하여 수집해서 전처리 후 DB에 저장했습니다.
진행 방법
데이터 수집
공공데이터포털 에서 아파트 실거래가를 검색한 후에 활용 신청하면 API Key를 받을 수 있습니다. API Key는 Encoding, Decoding Key 두 개가 발급되는데, AI에게는 수집하고자 하는 데이터와 Decoding Key값을 알려주면 됩니다. 그러면 수집은 바로 됩니다.
데이터 전처리
공공데이터포털에서 수집된 데이터는 주소가 파싱이 안되어 있어서 전처리가 필요합니다. 시도/시군구/법정동으로 구분되어야 대시보드를 만들더라도 선택이 가능하기에 주소 파싱을 해야합니다. AI에게 아래와 같이 주소를 파싱해달라고 요청합니다.
- 원본 시군구 컬럼(예: "서울특별시 강남구 압구정동")을 시도 / 시군구 / 읍면동으로 분리
데이터 시각화
Streamlit 라이브러리를 활용해서 시각화 대시보드를 구현했고, 지역, 단지, 거래유형을 선택해서 조회해볼 수 있습니다.
대시보드는 한번에 원하는 결과를 바로 구현하기는 어렵습니다. 그래서 프롬프트 입력할 때 대시보드를 만들기 위한 요구사항을 구체적으로 적으면 좋습니다. 물론 그렇게 한다고 해도 한번에 딸깍 완성되는 건 아니라서 수차례 티키타카는 필요합니다.
아래 프롬프트 참조해보세요.
### 시각화 #### 뷰 1: 개별 실거래가 (산점도 + 거래량)
매매 가격 → 전세 가격 → 매매 거래량 → 전세 거래량 순서로 4행 분리 배치한다. X축(시간)은 모든 행이 공유한다.
- 가격 행: 산점도(scatter). 개별 거래를 점으로 표시. 같은 월의 점들이 겹치지 않도록 jitter(수평 흩뿌림)를 적용. 평형대별(10평대, 20평대, 30평대 등) 색상으로 구분
- 거래량 행: 막대(bar). 월별 거래 건수
- 거래유형 선택에 따라 매매만(2행), 전세만(2행), 또는 매매+전세(4행)로 자동 조정 #### 뷰 2: 평균 실거래가 (선 그래프 + 거래량)
뷰 1과 동일한 행 분리 배치.
- 가격 행: 선 그래프(line). 월별 중위가를 선으로 표시. 매매와 전세를 색상으로 구분. 선 위에 데이터 포인트 마커 표시
- 거래량 행: 막대(bar). 월별 거래 건수 #### 공통 사항 - 차트 크기는 충분히 크게 (가로 전체 너비, 세로 500px 이상)
- 호버 시 상세 정보 표시 (뷰 1: 단지명, 계약년월, 거래금액, 전용면적, 추정평형, 층 / 뷰 2: 중위가, 거래량, 해당 월)
- 범례 표시 ### 사용자 인터페이스 (사이드바) #### 뷰 전환
- 메인 영역 상단에서 뷰를 전환한다: "개별 실거래가", "평균 실거래가" (탭 또는 라디오 버튼) #### 지역 선택 (계층적 필터)
- 시도: selectbox (단일 선택, 기본값: 서울특별시)
- 시군구: selectbox (시도 선택에 따라 목록 갱신, 기본값: 강남구)
- 읍면동: multiselect (시군구 선택에 따라 목록 갱신, 기본값: 전체)
- 단지: multiselect (읍면동 선택에 따라 목록 갱신, 기본값: 전체) #### 거래유형 선택
- 매매+전세 함께 보기, 매매만, 전세만 (라디오 버튼, 기본값: 매매+전세) #### 평형 필터
- 평형대: multiselect (10평 미만, 10평대, 20평대, 30평대, 40평대, 50평대, 60평 이상 / 기본값: 30평대) #### 기간 선택
- 시작 연도 ~ 종료 연도 범위 슬라이더 (데이터 존재 범위 내에서 선택)
- 기본값: 전체 기간 #### 기타
- 직거래 포함 여부: 체크박스 (기본: 미포함) ### 메인 화면 추가 정보
차트 아래에 매매 기준 요약 정보를 표시한다. "전세만" 선택 시에는 요약 정보를 표시하지 않는다.
- 선택한 조건의 총 거래 건수
- 최근 거래가 (최근 3건)
- 기간 내 최고가 / 최저가
얼마 전 우연히 참석한 민간개발 주민 설명회!
생각보다 꽤 많은 인원이 참여하는 것을 보고
엄청난 APT 가격이 부담스러울 때
아..저런 계획을 미리 알고 투자한다면
실거주도 해결되고 장기적으로 투자도 하는 일석이조가 될 수 있겠군.
무엇을 만들고 싶었는가.
‘어떤 지역에 정비사업의 바람이 솔랑솔랑 귀에 들어오면 그 지역의 현재 상태, 시세, 진행상황 등을 여러 페르소나를 가진 cli 가 공공데이터를 서로 분석하여 투자에 대한 의견을 내놓도록 만들어 참고 할 수 있는 앱,
더불어 재개발, 재건축 진행할만도 한 곳을 추천 받을 수 있는… 진행할 수 있는 조건이 되는 구역의 선정보 취득 등을 함께 접근할 수 있는 것을 만들어보고 싶다.’
라는 생각으로 시작했습니다.
Claude , Claude Code 와 ChatGpt , Gemini
초기 Prompt
문득 요즘 신축현장들이 은근히 많이 보이더라고.. 그리고 또 재개발 지역 선정 플랜카드도 많이 보이고 .. 이것을 API 로 이끌어와서 볼 수 있는 서비스를 구현해보고 싶은데 너는 어떻게 생각해?...확증편향적인 성향을 버리고 매우 객관적으로 AI와 프롭테크의 결합 그리고 현실 가능성과 그로 인해 얻는 이득을 잘 분석해서 말해줘
재개발, 재건축에 대해 만들어보고 싶은 이유는 현재 천정부지로 뛰어 올라 있는 가격의 APT 를 구매하기는 힘든 서민들에게 기간은 좀 걸리지만 구옥의 다가구 다세대 단독주택 등의 매매를 통해 조합원등 재개발을 통한 APT 거주기회의 확장 가능성에 대해 가치를 두고 기획했음을 반영해줘.
이 모든 내용을 토대로 PRD 와 별개로 가치평가와 현실 반영 실현 가능성의 평가보고서를 줘. 다만 2026년 4월 현재의 기준의 부동산 관련 이슈와 정책등을 토대로 편향적이지 않게 객관적으로 분석하여 제출해줘
재개발, 재건축에 대해서 진행할 수 있는 조건이 있어 예를 들어 신속통합이나 모아주택 역세권 민간 개발 등등 여러 종류가 있지 그리고 특정 시설에서 몇 m 까지 포함되는 위치, 노후도 몇년이상 주택이 몇 %이상일 때 등등 아주 많은 교차 조건들이 있어. 이것을 공공 문서를 기준으로 싹 모아서 문서화 해줄래?
요렇게 아래 문서들을 생성.
여차 저차 지리한 시간과의 싸움 끝에
핸드오프 문서 받아서 Claude Code 에게 놀아보라고 쥐어줬습니다.
이제 Claude Code 에 인식시키고 단계별로 나름 발전시켜봤습니다.
너무 초반의 내용들이
실종되었습니다.
이렇게 테스트는 성공했다고 하는데
api 가 연결되지 않아서 아직은 결과물을 받지 못했습니다.
40분 대화하고 4~5시간 기다리고…
또 썸 탈까 하다가 limit ….
정말 pro 는 ......힘듭니다.
결과
테스트는 성공이라 했는데 API 를 아직 연동하지 않아
결과물들은 아직 보지 못했습니다.
다만 워크스페이스는 구성되었고
매우 많이 부족해 보이는 페이지를 얻었습니다. .
기능은 꼭 붙여서 다음 사례로 연결해보겠습니다.
와 배운 점
제공해주신 워크스페이스를 벤치마킹하여 만들어보니
그냥 기능설명으로는 제대로 만들어주지 않았습니다.
결국 그 워크스페이스를 분석하여 유사한 형식으로 만들어 달라고 하니
그제서야 잘 만들어주더군요.
그 과정에서 Claude Code 가 자신이 어떤 의미로 만들었고
참고하면서 수정 보완 내용도 기존과 차이점도 설명해주니
기존 md 파일 구조를 더 이해하기 편했습니다.
어떤 구조를 파헤쳐보고 싶을 때는 유사하게 구현하면서 배우는 방법도 유용하다.
앞으로의 계획이 있다면 들려주세요.
API 연결하여 하나의 기능이라도 잘 돌아가도록 만드는 것.
도움 받은 글 (옵션)
21기 ChatAPT 에서 제공해주신 워크스페이스와 Cli
## 📝 한줄 요약 임장 전 구 전체 아파트 시세를 파악하려고 매번 네이버 부동산을 단지별로 검색하던 걸, Claude Code로 자동화했더니 지도 이미지 한 장이 생겼다. **바쁘시면 이것만 읽어도 돼요:**
- Claude Code로 서초구 아파트 61개 단지 시세를 지도 위에 색깔 박스로 자동 표시
- 코드는 한 줄도 직접 안 썼다 — "이 부분 바꿔줘", "이건 마음에 안 들어"로만 진행
- 원하는 결과물 예시 이미지를 보여주면 AI가 훨씬 빠르게 이해한다
- 처음엔 3개 스크립트였는데 AI가 알아서 1개로 합치고 실행 시간 6분을 줄여버렸다
- 이제 구 이름만 입력하면 강남구, 마포구도 똑같이 뽑힌다 --- ## 🎯 이런 분들께 도움돼요 - 부동산 투자에 관심 있는데 코딩은 하나도 모르는 직장인
- 임장 전 네이버 부동산을 단지별로 하나하나 뒤지는 게 번거로운 분
- AI 코딩 도구를 써보고 싶은데 뭘 만들어야 할지 모르는 분 --- ## 😫 문제 상황 (Before) 임장을 가기 전에 항상 이런 과정을 반복했다. 서초구 아파트 시세를 파악하고 싶다 → 네이버 부동산 접속 → 서초구 지도 열기 → 단지 하나 클릭 → 매매 최저가 확인 → 전세 최저가 확인 → 엑셀에 수동 입력 → 다음 단지 클릭 → 반복... 단지 수가 60개가 넘으니 이걸 다 뒤지면 두 시간은 그냥 날아갔다. 그리고 다 정리해도 "이 단지가 지도에서 어디쯤이지?"를 또 별도로 확인해야 했다. 더 이상 미루기 싫어서 AI한테 물어봤다. --- ## 🛠️ 사용한 도구 - **도구**: Claude Code
- **모델**: Claude Sonnet 4.6
- **데이터 출처**: 네이버 부동산 호가 --- ## 🔧 작업 과정 ### 원하는 것부터 말했다 — 기준 정하기 막연하게 "시세지도 만들어줘"라고 하면 AI도 뭘 만들지 모른다. 그래서 조건을 직접 정리해서 전달했다. ```
부동산 시세지도를 만들어보려고 해.
조건:
- 아파트만 (오피스텔, 빌라 제외)
- 300세대 이상
- 20평형대·30평형대 있는 단지
- 매매·전세 각 1건 이상 매물 있는 곳
결과물: 단지별 매매/전세/갭/전세가율 정리한 엑셀 파일 + 지도 이미지
``` Claude Code가 조건을 정리하고, 네이버 부동산 데이터를 자동으로 수집하는 방법까지 바로 제안했다. 나는 시작 지역만 정해줬다. ```
시작 지역: 서울시 서초구
``` --- ### 데이터가 쌓이는 걸 기다렸다 여기서 처음으로 막혔다. 코드 실행을 시작하니까 화면에 로그가 찍히면서 진행은 되는데... 10분이 넘게 걸렸다. 네이버 부동산 서버에 과부하를 주지 않으려고 요청 사이에 의도적으로 간격을 두기 때문이다. "이거 멈춘 거 아니야?" 싶었지만 그냥 기다렸더니 결과가 나왔다. 서초구 아파트 770개 단지를 훑고, 조건에 맞는 단지를 추려서 엑셀 파일로 정리해줬다. 20평형대·30평형대 시트가 나눠져 있고, 단지별로 매매 최저가·전세 최저가·갭·전세가율이 다 들어있었다.
--- ### 예시 이미지를 보여줬더니 바로 이해했다 데이터는 생겼는데, 이걸 지도 위에 올리는 게 문제였다. 말로 설명하기가 애매해서 참고 이미지를 하나 캡처해서 붙였다. ```
지금 만든 데이터를 지도 위에 올리는 작업을 해줘.
예시 이미지 첨부 [시세지도.png]
지도 위에 단지들이 어느 정도 가격인지 한눈에 보고 싶어
``` 말로 열 줄 설명하는 것보다 이미지 하나가 훨씬 빨랐다. AI가 이미지를 보고 스타일을 파악해서 그대로 구현해줬다. 지도 배경 위에 단지별로 작은 정보 박스가 올라왔다. 단지명, 전용면적, 사용연도, 매매/전세/갭/전세가율이 한 박스에 다 들어있었다.
--- ### 색상 기준은 내가 직접 설계했다 처음엔 전세가율에 따라 색이 달라졌는데, 내가 보고 싶은 건 그게 아니었다. 매매가 기준으로 가격대가 한눈에 보이길 원했다. ```
박스 색상을 가격대 기준으로 다시 설정해줘. 파일 재생성은 안 해도 되고 로직만 수정해줘. 색상 기준:
6억 미만 / 6~9억 / 9~11억 / 11~13억 / 13~15억 / 15~20억 / 20~30억 / 30억 초과
``` "파일 재생성은 안 해도 되고 로직만 수정해줘" — 이 말 한 마디로 AI가 색상 판단 부분만 딱 바꿔줬다. 엑셀 파일은 건드리지 않고. --- ### 평형 기준 문제 — 알고 보니 내가 헷갈렸던 것 작업 중에 이상한 게 있었다. 20평형대 단지가 너무 적게 나왔다. 이유를 물어봤더니 AI가 쓰던 라이브러리의 "20평대" 기준이 전용 66~99㎡였다. 우리가 일상에서 "20평형대"라고 부르는 전용 59㎡ 근방과 달랐다. ```
평형 기준을 재설정하자.
나는 통상적으로 의미하는 20평형대와 30평형대를 기준으로 하고 싶어.
헷갈리면 검색해서 확인해봐.
``` AI가 직접 검색해서 확인하고 기준을 다시 잡아줬다.
- 20평형대 = 전용 55~70㎡ (흔히 말하는 "59㎡")
- 30평형대 = 전용 75~95㎡ (흔히 말하는 "84㎡") --- ### AI가 알아서 구조를 최적화했다 — 6분 절약 어느 정도 완성됐을 때 이렇게 요청했다. ```
지금까지 작업을 최적화해주고, 제대로 된 결과물이 나오는지 검증해줘.
그리고 앞으로 조사하고 싶은 구 이름만 입력하면 자동으로 엑셀 파일이랑 지도 이미지가 나오는 스킬로 만들어줘.
``` 이때 AI가 스스로 문제를 찾아냈다. 처음엔 3개 스크립트로 나눠져 있었는데, 두 번째 스크립트가 첫 번째 스크립트가 이미 수집한 데이터를 또 수집하고 있었다. 그걸 1개로 합치면서 실행 시간이 6분 줄었다. 나는 "최적화해줘"라고만 했는데 AI가 중복 작업을 찾아서 구조를 통째로 바꿔버렸다. --- ### 처음으로 지도를 봤을 때 서초구 지도 위에 61개 단지가 색깔별 박스로 올라왔다. 파란 박스는 13억대, 주황 박스는 15~20억대, 빨간 박스는 20억 이상. 지도를 보자마자 "이 동네가 이 가격대구나"가 한눈에 들어왔다. 엑셀로 볼 때는 숫자를 하나하나 읽어야 했는데, 지도로 보니까 동네별 가격 분포가 바로 보였다. --- ## ✅ 결과 (After) ### Before vs After | 항목 | Before | After |
|------|--------|-------|
| 시세 파악 방법 | 단지별 네이버 부동산 수동 검색 | 구 이름 입력 → 자동 수집 |
| 소요 시간 | 단지 60개 기준 약 2시간 | 대기 시간 10~15분 (자동) |
| 결과물 형태 | 수동 엑셀 + 지도 별도 확인 | 엑셀 + 지도 이미지 자동 생성 |
| 재사용성 | 매번 처음부터 반복 | 구 이름만 바꿔서 재실행 | ### 결과물 - `서초구_시세지도_20260401.xlsx` — 20평형대 16개 / 30평형대 45개 단지
- `서초구_시세지도_20평형대.png` — 지도 위 가격대별 색상 박스
- `서초구_시세지도_30평형대.png` — 동일 방식, 30평형대 기준
- `sisemap` 스킬 — 이제 구 이름만 입력하면 자동 실행 --- ## 💬 이 과정에서 배운 AI 활용 팁 ### 효과적이었던 것 1. **코드 몰라도 된다** — "이 부분 바꿔줘", "이건 마음에 안 들어", "왜 이렇게 됐어?"로만 진행했다. 코드를 이해하지 않아도 원하는 방향을 말로 설명하면 AI가 알아서 바꿔준다.
2. **예시 이미지 한 장이 설명 열 줄보다 낫다** — 원하는 결과물이 어떻게 생겼는지 이미지로 보여주면 AI가 훨씬 빠르게 방향을 잡는다.
3. **처음부터 완벽하게 기획 안 해도 된다** — "이건 마음에 들어, 이건 바꿔줘"로 조금씩 수정하면서 완성됐다.
4. **범위를 한정해서 요청한다** — "파일 재생성은 안 해도 되고 로직만 수정해줘"처럼 AI가 건드려야 할 범위를 명확히 하면 엉뚱한 곳을 수정하지 않는다. ### 이렇게 하면 안 돼요 1. **기다림을 못 참고 중단하지 마세요** — 데이터 수집 중 10~15분은 정상이다. 화면에 로그가 계속 찍히면 돌아가고 있는 것이다.
2. **처음 결과가 맘에 안 든다고 포기하지 마세요** — 첫 번째 지도는 색상 기준도 달랐고 평형 분류도 틀렸다. "이건 바꿔줘"를 몇 번 하고 나서 원하는 결과가 나왔다. --- ## 🌍 다른 업무에 적용한다면? 이번에 만든 방식은 부동산 말고도 쓸 수 있다. - **상권 분석**: 특정 구의 카페/음식점 임대료를 지도 위에 표시
- **공시지가 지도**: 토지·건물 가격을 구 단위로 지도에 표시
- **학군 지도**: 학교별 입시 결과를 지도 위에 색깔로 구분 지도 위에 데이터를 올리는 구조 자체는 어떤 종류의 데이터든 쓸 수 있다. --- ## 🚀 앞으로의 계획 서초구 하나로 검증했으니 이제 다른 구도 뽑아볼 예정이다. 강남구, 마포구, 용산구처럼 관심 있는 구를 몇 개 더 만들어서 구 간 가격대 분포를 비교해보려 한다. "이 구는 20평형대가 이 가격대에 몰려있고, 저 구는 저 가격대에 몰려있다" — 이걸 지도로 나란히 놓고 보면 투자 판단에 쓸 수 있을 것 같다. --- ## 📋 재사용 가능한 프롬프트 ### 프롬프트 1: 시세 수집 조건 정하기 > [지역명] 아파트 시세를 자동으로 수집하고 싶어.
> 조건은 이래:
> - [아파트 유형] 만 대상
> - [세대수] 세대 이상
> - [평형 조건] 있는 단지
> - 매매·전세 각 1건 이상 매물 있는 곳
>
> 결과물: 단지별 [원하는 항목들] 정리한 엑셀 + 지도 이미지
>
> `[대괄호]` 안의 내용을 본인 상황에 맞게 변경하세요 ### 프롬프트 2: 일부만 수정 요청하기 > [수정할 항목]을 [원하는 방식]으로 바꿔줘.
> [건드리지 말아야 할 것]은 그대로 둬. ### 프롬프트 3: 반복 사용 가능한 스킬로 만들기 > 지금까지 작업을 최적화해주고 검증해줘.
> 그리고 앞으로 [변수]만 입력하면 자동으로 [결과물]이 나오는 스킬로 만들어줘.
소개
시도하고자 했던 것과 그 이유
매월 공공기관에 hwpx, xlsx 형식의 보고서를 제출해야 하는데, 너무 단순반복적인 일이라서 정말 자동화가 간절했습니다. 챗GPT, Gemini, Claude로 보고서 작성을 종종 시도해봤었는데, 불과 얼마 전까지만 해도 엑셀이나 한글파일 작성은 오류가 많았습니다. 오류+재작성을 반복하다보면 너무 열받아서 직접 작성하느니만 못했습니다.
금전지출내역서(엑셀): 통장내역에서 수입·지출 내역을 항목별로 엑셀 파일에 정리
월정기보고서(한글): 당월 활동내역, 방문사진, 기타 보고사항을 담은 한글(.hwpx) 문서
지출증빙(pdf): 통장내역 사진, 영수증
시도 방법
Obsidian에 작업 가이드 MD 파일을 만들어 두고, Claude Code가 그 가이드를 읽고 실행한다.
물론, MD 파일은 샘플 작업하면서, Claude Code가 제작했습니다.
Obsidian (가이드 저장소) Claude Code (실행자)
───────────────────────── ──────────────────
컨택기록 템플릿.md → 컨택기록 MD 생성
금전기록_작업가이드.md → 통장 사진 보고 엑셀 작성
월정기보고서_작업가이드.md → 보고서 작성 실행
1단계: 엑셀 금전지출내역서 작성 (통장 사진 → 엑셀)
통장 사진을 촬영해서 이미지 폴더에 저장하면, Claude Code가 사진을 보고 엑셀 파일에 직접 기록합니다.
통장 사진 촬영 → 이미지 폴더 저장 → Claude Code에게 사진 + 엑셀 제공 → 엑셀 업데이트
1) Claude Code에게 요청
"금전기록_작업가이드.md 읽고, 이미지 폴더의 통장 사진 보고 엑셀 업데이트해줘."
2) 잔액 검증
엑셀 업데이트 후 통장 사진의 마지막 잔액과 엑셀 합계를 대조하여 검증
통장 사진 잔액 = 엑셀 합계 → OK
통장 사진 잔액 ≠ 엑셀 합계 → 해당 기간 누락 내역 확인
3) 지출증빙 확인
이미지 폴더에 있는 영수증·지급내역 사진과 엑셀 지출 내역을 대조해서, 누락된 증빙 확인
4) pdf 파일 생성 (이미지 파일 분류 → pdf)
엑셀 작업과 한글 문서 작성이 끝나면 이미지 폴더를 스캔해서 통장사본과 지출증빙 각각 PDF 파일로 자동 생성
이미지 폴더 스캔 → 통장사본 PDF + 지출증빙 PDF
생성 파일:
통장사본_기○○_2026년3월.pdf — 통장 사진 전체
지출증빙_기○○_2026년3월.pdf — 지출증빙 전체
지출증빙 PDF 페이지 순서 및 파일 규격
A4 사이즈, 150dpi
사방 여백 1.5cm
여백 안에 이미 들어오는 이미지는 크기 조정 없음
PDF 생성 완료 후 사용된 이미지는 이미지/정리완료/ 폴더로 이동
2단계: 월정기보고서 작성 ( → 한글)
1) 한글 파일 HWPX로
지난 주 스터디에서 한글파일은 hwpx로 작업해야 AI가 비교적 잘 읽을 수 있다고 스터디원들이 공유해주셔서, 기존 파일들의 형식을 맞춰 놓고 자동화 작업을 진행했습니다.
클로드 설명
.hwp는 바이너리 포맷이라 Claude Code가 내부 구조를 파악하기 어렵지만, .hwpx는 XML 기반의 ZIP 파일이어서 Python으로 직접 읽고 수정할 수 있습니다.
2) 보고서 기초 데이터 관리
통화 녹음, 사진, 관련자들과 의논한 채팅
컨택기록 폴더를 드라이브에 별도로 모아서 저장
Claude Code는 아직 음성 파일처리는 안된다고 해서 모바일 텍스트 변환하고 OneDrive에 저장하면, Claude Code가 읽어서 컨택기록 MD를 날짜별로 생성해둠.
3) Claude Code가 가이드를 읽고 보고서 작성 실행
"월간작업_가이드.md 읽고 3월 보고서 작업 시작해줘.
Claude Code가 하는 일:
가이드 MD 파일을 읽고 작업 순서 파악
컨택기록 MD 파일들을 순서대로 읽어서 내용 파악
전월 HWPX 파일을 복사해서 날짜·금액 수정
활동내역 테이블에서 사진 삽입 스크립트 실행
컨택기록 및 사진 메타속성을 확인해서 날짜 및 시간 입력
4) HWPX 방문 사진 자동 삽입
보고서 형식에 표 안에 사진 삽입은 Python 스크립트로 작업
월정기보고서.hwpx (ZIP)
├── Contents/section0.xml ← 본문 XML (이미지 위치·크기 정보)
├── Contents/content.hpf ← 이미지 등록 목록
└── BinData/image1.png ← 삽입된 이미지 파일
사진 삽입 스크립트 사용법
월정기보고서_사진삽입.py 설정만 매월 수정
# ===설정=== (매월 수정)
HWPX_FILE = "월정기보고서_한○○_2026년4월.hwpx"
BIN_EXT = ".png" # 한○○: ".png" / 기○○: ".PNG" PHOTOS = [ # (소스파일명, xml_ref, 새ref번호 또는 None) # xml_ref: binaryItemIDRef 속성값 — 확장자 없이 입력 # None → 기존 슬롯 교체 / 숫자 → 해당 슬롯 뒤에 추가 ("20260408_132603.jpg", "image1", None), # image1 슬롯 교체 ("20260410_095223.jpg", "image2", None), # image2 슬롯 교체 ("20260410_104341.jpg", "image2", 7), # image2 뒤에 image7 추가
]
imgClip 오류 수정
사진이 잘리거나 사이즈가 잘못 들어가는 오류들이 있었는데, 클로드코드가 기존 보고서 형식을 분석해서 좌표 단위 등을 수정합니다.
# 기존 파일 이미지 크기 역산
img.width # → 3968px
xml_imgClip_right # → 297600 # 297600 / 3968 = 75 → imgClip은 px × 75 (96 DPI 기준)
# 이미지 비율 유지, 슬롯 내 최대 크기로 스케일
def _calc_display(w_px, h_px, slot_w, slot_h): aspect = w_px / h_px slot_aspect = slot_w / slot_h if aspect >= slot_aspect: return slot_w, int(slot_w / aspect) else: return int(slot_h * aspect), slot_h # imgClip: 96 DPI 기준 전체 이미지 (px × 75)
clip_w, clip_h = w_px * 75, h_px * 75
결과
매월 약 3시간 이상 걸리던 노가다 작업이 엄청 단축되었습니다.
아주 완벽한 건 아니어서, 조금씩 편집 수정은 있습니다만, 점점 더 개선될 것으로 기대됩니다.
Obsidian에 저장된 작업별 가이드 MD 파일 확인 (각 사람마다 각각의 md 파일)
Claude Code가 프로세스대로 보고서 작성
작성 파일과 이미지 삽입하는 python 파일은 드라이브에 저장
앞으로의 계획
월정기보고서를 이렇게 자동화하고, 월 주요한 이벤트를 md 파일로 기록해두고 연간 보고서나 케이스 발표에 활용하려고 했는데, hwpx 파일이 잘 읽어지니 히스토리 기록이 필요한 일들을 어떻게 효과적으로 기록하면 좋을지 생각해봐야겠습니다.
위스퍼와 오픈클로로 비슷한 것 자동화하신 스터디원 계셨는데, 참고해서 적용해보려고 합니다.
소개
평소 부동산 시장 분석을 위해 광범위한 데이터를 수집하고 있습니다. API, 크롤링, RSS 등 여러가지 방법으로 수집할 수 있을텐데, 이번 글에서는 API로 수집할 수 있는 정보를 공유합니다.
진행 방법
아래 링크에서 데이터 수집이 가능합니다. API Key가 필요하니 신청은 필요합니다.
공공데이터포털
실거래가
KB부동산
KOSIS
국가데이터처_KOSIS 통계표설명 조회 서비스
ECOS
인허가
한국부동산원
국가공간정보(V-World)
공매
서울열린데이터광장
데이터 수집은 아주 쉽습니다. 그저 AI한테 API Key 알려주면서 수집 요청하면 됩니다. API Key는 .env에 저장해주세요. 예전에는 은근히 번거로운 작업이었는데, 이제는 너무 쉽네요. ㅎㅎ
단, 수집된 데이터는 내가 원하는 형태인지 직접 눈으로 확인하고, 나의 분석에 필요한 형태로 되어 있는지 여부에 따라 전처리가 필요합니다.
수집된 데이터를 어디에 저장할지는 각자의 목적과 용도에 따라 다르겠지만, 로컬로 사용하실 분들이라면 DuckDB를 사용해보셔도 좋을 것 같습니다.
나만의 분석용 DuckDB 활용 with Python
설치도 간단하고 빨라서 여러모로 장점이 있습니다. 혹시 서비스를 원하신다면 다른 DB를 선택해도 되고 아니면 MotherDuck으로 마이그레이션 하면 됩니다.
소개
시도하고자 했던 것과 그 이유를 알려주세요.
공공기관 취업이 목표라 제미나이 딥리서치 방법을 통해 더 심층 있는 정보를 얻고자 하였습니다.
진행 방법
어떤 도구를 사용했고, 어떻게 활용하셨나요?
Tip: 사용한 프롬프트 전문을 꼭 포함하고, 내용을 짧게 소개해 주세요.
Tip: 활용 이미지나 캡처 화면을 꼭 남겨주세요.
Tip: 코드 전문은 코드블록에 감싸서 작성해주세요. ( / 을 눌러 '코드 블록'을 선택)
P: 저는 경영학과 4학년 재학 중인 대학생입니다. T: 2026년 공공기관 중에서 병원과 관련된 업무를 할 수 있는 신입 포지션의 종류, 준비 방법, 국내 채용 현황을 조사해주세요. C: 내년 2월 졸업 예정으로 대학원보다 바로 취업을 원합니다. 재무/회계 분야 다수의 자격증 보유가 강점입니다. F: 신입 취업 전략 보고서를 아래 내용으로 구성해주세요. 현재 준비해야 하는 자격증 6개월 안에 취업 경쟁력을 높이는 스펙 쌓기 로드맵 면접에서 자주 나오는 질문과 비전공자 합격자 답변 사례 체험형 인턴 관련 공고
결과 docs 첨부
결과와 배운 점
배운 점과 나만의 꿀팁을 알려주세요.
모든 채용 사이트를 하나하나 다 들어가서 찾아보았는데, 관련 직무를 하나로 묶고 필요한 자격증이나 경력을 한 눈에 볼 수 있어서 편했습니다. 그리고 AI 특성상 많은 정보를 주더라도 정확하지 않은 정보가 섞여 있을 수도 있는데 관련 사이트 주소까지 첨부해줘서 딥리서치의 기능을 믿고 더 잘 활용할 수 있었던 것 같습니다.
과정 중에 어떤 시행착오를 겪었나요?
도움이 필요한 부분이 있나요?
앞으로의 계획이 있다면 들려주세요.
이 기획안을 바탕으로 준비를 열심히 해봐야겠습니다. ㅎㅎ
소개
시도하고자 했던 것과 그 이유를 알려주세요.
저는 바이오인포매틱스 분야에서 5년간 유전체 빅데이터 분석과 자동화 파이프라인 구축을 담당해온 주임연구원입니다. 최근 약물경제 및 빅데이터 전공으로 석사 학위를 마쳤으며, 이를 계기로 기존의 바이오 도메인 지식에 전문적인 머신러닝(ML) 역량을 더해 데이터 사이언티스트(Data Scientist)로 커리어를 전환하고자 합니다. [1, 1]
전환을 시도한 이유는 명확합니다. 현재 보유한 Python/R 기반의 데이터 처리 및 자동화 강점은 데이터 사이언티스트에게 필수적인 역량이며, 여기에 ML 실무 경험이라는 '마지막 퍼즐'을 맞춘다면 헬스케어 및 인공지능 시장에서 독보적인 경쟁력을 가질 수 있다고 판단했기 때문입니다.
진행 방법
어떤 도구를 사용했고, 어떻게 활용하셨나요? 이번 커리어 로드맵 설계를 위해 AI 리서치 도구를 활용하여 저의 이력서(PDF)와 포트폴리오를 심층 분석했습니다. 특히 제 강점인 '자동화' 역량이 현대 DS 채용 시장(MLOps, AgentOps)에서 어떻게 해석될 수 있는지, 그리고 부족한 ML 실무를 어떻게 단기간에 보완할 수 있을지 단계별 전략을 도출했습니다.
사용한 프롬프트 전문:
"P: 저는 Bioinformatics 분야에서 5년간 Bio 유전체 빅데이터 분석 부터 분석 자동화까지 담당한 주임연구원입니다. 회사를 다니면서 약물경제 및 빅데이터 석사 전공도 마무리 했습니다.
T: datascientist로 전환하기 위해 필요한 핵심역량, 준비기간, 채용트랜드 를 조사해주세요.
C: 현재 나이는 30대 초반이이고, 나의 강점은 자동화이며 python R이 주 언어였으며, 부족한점은 ML으로 실무를 해본적이 없습니다.
F: 단계별 로드맵/ 비교표/ 대기업 리스트 형식으로 보고서를 만들어주세요."
결과와 배운 점
배운 점과 나만의 꿀팁을 알려주세요.
자동화의 재해석: 단순히 업무를 줄이는 '스크립트 작성' 능력이 DS 시장에서는 데이터 파이프라인 설계 및 MLOps 역량으로 높게 평가받는다는 것을 알게 되었습니다.
도메인 특화의 중요성: 범용 DS보다는 저의 강점인 약학/바이오 데이터를 ML 모델링($P(Y|X)$ 추정 등)과 결합했을 때 연봉 상승폭(최대 100% 수준)이 가장 컸습니다.
과정 중에 어떤 시행착오를 겪었나요?
단순히 ML 라이브러리를 사용할 줄 아는 것과, 비즈니스 문제를 정의하고 모델로 해결하는 것은 큰 차이가 있다는 점을 깨달았습니다. 실무 경험 부재를 메우기 위해서는 단순 캐글 참여보다 '데이터 수집-모델 설계-배포'의 전체 사이클을 직접 경험해보는 프로젝트가 필수적입니다.
앞으로의 계획이 있다면 들려주세요.
6개월 로드맵 가동: 1~3개월 차에는 통계 및 ML 이론 심화, 4~6개월 차에는 바이오 데이터를 활용한 딥러닝 예측 모델링 및 포트폴리오 구축에 집중할 예정입니다.
타겟 기업 공략: 루닛, 뷰노와 같은 의료 AI 선도 기업이나 네이버, 카카오의 헬스케어 부문을 목표로 기술 면접과 코딩 테스트를 준비할 계획입니다.
도움 받은 글 (옵션)
참고한 외부 사례를 알려주세요.
데이터 사이언티스트 이직 로드맵: 30대 경력직의 직무 전환 시 수학적 기초와 알고리즘 이해의 중요성을 강조한 가이드를 참고했습니다.
2025-2026 채용 트렌드: MLOps를 넘어선 AgentOps(AI 에이전트 자율 최적화) 시대의 도래와 이에 따른 데이터 엔지니어링 역량의 중요성을 확인했습니다.
<이사 배경>
스터디 필기, 프로젝트 아이디어, 발표자료 등 노션에 흩어져 있던 데이터들을 옵시디언으로 이사하기로 했습니다. 노션을 아이디어 기록용으로 주로 이용했었기 때문에 복잡한 데이터가 없었고, 오류없이 심플하게 진행된 편입니다.
<이사 전 노션 데이터 현황>
노션에 쌓여 있던 데이터:
스터디 필기
프로젝트 아이디어
회의록 등
업무 목표 및 ToDo
스터디장님 알려주신대로 옵시디언 공식 가이드라인 Import from notion 참고했습니다.
https://obsidian.md/help/import/notion
공식 가이드라인을 주고 Claude Code로 진행하는데,
다른 형식으로 가져오라고 지시하네요.(뭐였는지 잘 기억나지 않음)
다른 스터디원이 오류 났던 경험을 스터디시간에 공유해줬기 때문에
스터디장님이 html로 가져와야 오류 없이 옮겨올 수 있다고 미리 알려주셨습니다.
노션 HTML 내보내기 → 옵시디언 Import
1단계: 노션 내보내기
노션 설정 → 전체 내보내기 → HTML 형식 → ZIP 파일 다운로드
2단계: 옵시디언 Importer plugin
Obsidian Importer 플러그인으로 ZIP 파일 Import. 출력 폴더는 notion/으로 지정.
⚠️ 오류
노션에서 내보내기가 시간이 꽤 걸립니다. 저는 Data가 얼마 없었는데도요.
기다리다 자버렸는데, 여러 건 내보내기가 되었습니다.
Import 과정에서도 오류가 난 듯 해서 두 번 실행되어 옵시디언에 노션 폴더가 두 번 생성되었습니다.
notion/(소문자)과 Notion/(대문자) 폴더가 동시에 생겼나 본데
Data 정리하는 과정에서 AI가 폴더를 헷갈려해서 잘못 정리하거나 삭제하기도 했습니다.
<Claude Code가 한 일: CMDS 구조로 정리>
노션 HTML Import 결과물 → CMDS 폴더 구조에 맞게 재배치
이 과정에서
앞서 볼트를 셋팅했던 CMDS 폴더 구조와 성격에 대해 제 스스로 정확하게 파악되지 않은 상태에서 클로드 코드로 파일들을 정리하다보니, 예상치 못한 경로에 파일이 들어가 있기도 하고,
기존에 정리되어있던 Data들을 클로드가 마음대로 다시 배치해버리는 일이 발생하기도 했습니다.
그런 이유로
노션 파일들을 재배치 하는 과정에서 CMDS 구조를 더 많이 스터디하게 되네요.
또, 볼트를 제게 맞는 구조로 커스터마이징하는 데에도 많이 도움이 됩니다.
CMDS 구조에서
아직 어느 폴더에 넣을지 결정되지 않은 data를 00. Inbox/ 폴더에 임시로 저장한다거나
AI Agent에서 생성한 정보 컨텐츠들을 03. AI Agent에 저장되도록 한다거나
이런 구조가 Data가 우후죽순으로 쌓이다보면, 자칫 헝클어질 수 있는 구조를
더 신중하게 관리할 수 있게 도와주는 것 같습니다.
프로젝트 관리
각 비즈니스 영역들의 업무를 프로젝트 단위 폴더로 관리하고
전체 프로젝트를 한 눈에 볼 수 있는 Dash Board md 파일을 생성했습니다.
전화통화나 회의록, 각종 계획들에 관한 파일을 볼트 외부 클라우드 파일에 Raw Data로 업로드하면 클로드가 회의록을 정리해서, 각 프로젝트 별 md 파일과 전체 프로젝트를 한 눈에 보는 Dash Board를 업데이트 하는 프로세스입니다.
얼마나 유용하게 사용할 수 있을지는 좀 더 사용해봐야겠습니다.
<배운 점>
Data 이사해서 정리해보니, 옵시디언 공부에 많은 도움이 됩니다.
📝 한줄 요약
기존 임장보고서 PDF 하나를 학습시켰더니, 서초구 데이터를 직접 수집해서 같은 형식의 PPT를 만들어줬다. 지역당 2~3시간 걸리던 사전조사가 수십 분으로 줄었다.
바쁘시면 이것만 읽어도 돼요:
Claude Code에게 임장보고서 PDF를 학습시키고 서초구 분석을 요청 → 인구·교통·학군·호재 데이터까지 직접 수집해서 PPT 생성
AI가 PDF 구조를 파악하고 데이터 수집부터 슬라이드 디자인까지 스스로 설계함
한 번 만든 보고서 생성 과정을 스킬로 저장해두면 다음 지역은 지역명만 입력하면 됨
WebSearch를 서브에이전트에 맡기면 권한 오류 발생 — 메인 세션에서 직접 실행해야 함
지역당 사전조사 2~3시간 → 수십 분으로 단축
🎯 이런 분들께 도움돼요
임장 전에 인구·교통·학군·공급 등 기본 데이터를 직접 찾아 정리하는 분
여러 지역을 반복해서 조사하다 보니 매번 같은 작업이 반복된다고 느끼는 분
현장에서 더 깊은 인사이트를 얻고 싶은데 조사 시간에 에너지를 다 쏟는 분
😫 문제 상황 (Before)
임장을 가기 전에 지역 조사를 직접 해본 분이라면 공감하실 거예요.
인구는 구청 홈페이지, 교통은 따로 검색, 학군은 또 다른 데서 찾고, 재건축 현황은 여기저기 흩어져 있고... 이걸 한 장의 보고서로 만들려면 기본 2~3시간은 각오해야 했어요. 그나마도 정보를 취합해서 PPT로 정리하다 보면 정작 "이 지역에서 뭘 봐야 할까"를 생각할 여유가 없었죠.
반복되는 지역 조사마다 같은 작업을 처음부터 다시 하고 있다는 게 가장 비효율적으로 느껴졌어요. 아낀 시간을 현장 방문과 인사이트를 얻는 데 쓰고 싶었습니다.
🛠️ 사용한 도구
도구: Claude Code
모델: Claude Sonnet 4.6
특이사항: WebSearch(인터넷 검색), python-pptx(PPT 생성) 활용
🔧 작업 과정
1단계: PDF 한 장 학습시키기 — "이 형식으로 만들어줘"
시작은 간단했어요. 기존에 직접 작성했던 임장보고서 PDF를 Claude Code에 건네면서 이렇게 요청했습니다.
이 파일과 같은 구조의 부동산 임장 보고서를 작성하려고 해.
우선 내용을 학습해주고, 이 자료를 이해하는 데 필요한 것들을 나에게 질문해줘
PDF가 20MB를 넘어서 직접 읽지 못하는 문제가 있었는데, Claude Code가 스스로 pdftotext라는 변환 도구를 써서 텍스트로 바꾼 다음 읽었어요. 결과적으로 40개 섹션, 5부 구성 (지역선택 기준 → 입지분석 → 시장분석 → 단지분석 → 의사결정)을 파악했습니다.
이걸 학습시켰더니 "어떤 데이터를 수집해야 하는지", "슬라이드를 어떻게 구성해야 하는지"를 스스로 설계하더라고요.
2단계: PDF 읽기 환경 설정 — 약간의 고비
PDF 읽기에 필요한 시스템 도구 pdftoppm 은 어떻게 설치하면 돼?
도구 설치 자체는 금방 됐는데, 설치 후에 경로(PATH)가 제대로 적용이 안 되는 문제가 있었어요. 새로운 화면을 열 때마다 도구를 못 찾는 상황이었는데, Claude Code가 직접 경로 설정 명령어를 찾아서 해결해줬습니다.
이런 환경 설정 문제는 익숙하지 않은 분들한테 걸림돌이 될 수 있어요. 저도 처음엔 당황했는데, "왜 안 되는지 설명해줘"라고 물어보니 원인과 해결 방법을 바로 알려줬습니다.
3단계: 서초구 데이터 수집 + PPT 생성 — 진짜 핵심
이제 본론이에요.
1. 서울시 서초구를 분석해주고
2. 투자 조건은 제외, 지역 공부 목적으로
3. AI로 공공 데이터 수집해서 사전조사 먼저
4. 출력 형식은 PPT, 학습한 임장보고서 형식으로
5. 개요 + 입지분석(인구/직장/교통/학군/환경/공급/호재)부터
이 요청 하나로 Claude Code가 스스로 웹 검색을 시작했어요.
서초구청 공식 홈페이지에서 인구 415,407명, 세대수 195,234세대 수집
9호선 급행·3호선 등 6개 지하철 노선 데이터 정리
강남 8학군 현황, 서울성모병원 등 의료 인프라
반포·서초 재건축 단지 현황, 개발 호재까지
그리고 이걸 바탕으로 다크 테마 PPT 15장을 직접 만들어줬습니다.
인상적이었던 순간: 제가 따로 "이런 슬라이드를 만들어"라고 지정하지 않았는데, PDF에서 학습한 보고서 구조를 그대로 재현해서 비슷한 형식으로 정리해줬어요. "내가 보고 싶어 하는 데이터들이 거기 있다"는 느낌이었습니다.
4단계: 자동화 스킬로 저장 — 다음 지역부터는 지역명만
한 번 만든 걸로 끝내기엔 아쉬웠어요. 매번 이 과정을 처음부터 반복하고 싶지 않았거든요.
좀전에 임장사전조사보고서 만들던 과정을 스킬로 만들어줘.
지역명을 입력하면 자동으로 만들어지는 스킬로
4명의 AI 전문가 에이전트가 병렬로 이 요청을 분석했어요. 기획자·사용자·기술 전문가·검수자 역할로 나뉘어서 각자 어떤 기능이 필요한지 의논하고, 위험 요소(데이터 신뢰도, 환경 오류, 권한 문제)까지 미리 점검했습니다.
기획 인터뷰 중 결정한 내용들:
Q: 스킬 이름을 어떻게 할까요?
→ pre-visit (임장 사전 방문의 의미)
Q: 어느 수준으로 만들까요?
→ 풀버전 (에러 대응, 신뢰도 관리, 폴백까지 포함)
Q: 저장 위치는?
→ 지역별 자동 분류 (30-analysis/research/서초구/ 형식)
결과물로 6개 파일이 생성됐고, 이제 /pre-visit 수원 영통구 한 줄이면 같은 구조의 보고서가 나옵니다.
✅ 결과 (After)
Before vs After
항목
Before
After
지역당 사전조사 시간
2~3시간
수십 분
데이터 수집 방식
직접 탭 열어가며 취합
AI가 7개 카테고리 자동 수집
보고서 형식
매번 새로 작성
PDF 학습 후 동일 형식 재현
다음 지역 사용
처음부터 반복
지역명 하나만 입력
생성된 결과물
서초구_임장사전조사보고서.pptx — 다크 테마 15장 슬라이드
pre-visit 스킬 — 지역명 입력 시 자동 수집·생성
서초구_raw_data.json — 수집 데이터 체크포인트 (재생성 시 재수집 불필요)
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
"이 형식으로 해줘"가 강력하다: 말로 설명하는 것보다 실제 예시 파일을 보여주는 게 훨씬 정확한 결과물이 나왔어요. PDF 하나 학습시켰을 뿐인데 구조를 그대로 재현했습니다.
한 번의 과정을 스킬로 저장한다: 좋은 결과가 나왔을 때 "이걸 자동화해줘"로 이어지면 다음엔 반복 작업이 없어집니다.
막히면 바로 물어본다: PDF 경로 문제처럼 낯선 오류가 나왔을 때 "왜 안 되는 거야?"라고 물어보면 원인을 찾아줍니다.
이렇게 하면 안 돼요
WebSearch를 "대신 해줘"라고 시키면 권한 오류: AI가 다른 AI에게 인터넷 검색을 맡기려고 하면 막히는 경우가 있어요. 메인 대화창에서 직접 검색하도록 유도하세요.
너무 많은 걸 한 번에 요청: 15장 슬라이드를 한 번에 "다 만들어줘"보다 "개요+입지분석부터 해보자"처럼 단계를 나누는 게 결과물 품질이 더 좋았어요.
🌍 다른 업무에 적용한다면?
분양 시장 조사: 청약 전에 해당 지역 분양 단지·경쟁률·시세를 자동 수집
스터디 사전 자료 준비: 지역 스터디 발표 전에 데이터 수집·정리 자동화
비교 분석: 두 지역을 /compare 서초구 vs 동작구 형태로 나란히 비교 보고서 생성
🚀 앞으로의 계획
우선 다른 후보 지역(수원 영통구, 동탄2신도시 등)에 바로 pre-visit 스킬을 실행해볼 예정이에요. 서초구 외에도 잘 작동하는지 검증하면서 필요한 부분을 개선할 계획입니다.
이후엔 사전임장 보고서 생성 후 /council 스킬로 5인 AI 토론까지 이어지는 흐름을 만들고 싶어요. 데이터 수집 → AI 토론 → 임장 체크리스트 순으로 이어지면 현장 방문 전 준비를 거의 자동화할 수 있을 것 같습니다.
📋 재사용 가능한 프롬프트
프롬프트 1: PDF 학습 후 동일 형식 보고서 요청
[첨부파일.pdf] 이 파일과 같은 구조의 보고서를 [분석 대상]에 대해 작성해줘. 공공 데이터를 직접 수집해서 PPT로 만들어줘. [포함할 항목]부터 시작해보자.
[수정할 부분]: 분석 대상과 포함할 항목을 본인 상황에 맞게 변경하세요.
프롬프트 2: 반복 작업을 스킬로 저장
방금 만든 과정을 스킬로 저장해줘. [입력값]만 바꾸면 자동으로 실행되는 방식으로. 저장 위치는 [경로]로 해줘.
[수정할 부분]: 입력값(지역명, 회사명 등)과 저장 경로를 원하는 대로 설정하세요.
## 데이터 관리 계획
데이터 중 정기적으로 반복적으로 쌓이는 데이터들을 우선으로 먼저 설정했습니다.
- 유튜브 채널: 치매예방프로그램 교안과 영상을 제작하는 일
- 치매공공후견: 주간 방문 기록, 월보고서·연간보고서, 연간 사례 아티클 및 발표자료 제작
- 시니어 커뮤니티 웹사이트 개발 업무와 관련된 아이디어 노트
- 블로그·웹사이트 콘텐츠
- 스터디 관련 자료
## 데이터 관리 상황 (옵시디언 셋팅 전)
OneDrive, 카카오톡, 노션, 등 다양한 형태의 파일로 기록
## 옵시디언 + CMDS 프레임워크 + Claude Code
> 인터뷰지를 작성하면, AI가 나에게 맞는 지식관리 시스템을 설계하고 볼트까지 세팅해준다.
## 인터뷰지 12개 질문에 답변 작성 CMDS System Files_Interview.md
인터뷰는 직무기술과 업무방식에 대한 인터뷰로 진행되는데, 인터뷰에 답변하면서, 나의 DB의 저장형태, 파일 종류 등 스스로 데이터관리에 대한 개념과 계획에 대해 스스로도 정리되는 것 같다.
- 나와 내 업무
- 데이터 관리 방식
- 업무 프로세스
- 활용 도구
- 데이터 관리 지향점
## Claude Code가 한 일: 시스템 파일 5개 자동 생성 (Phase 1)
CMDS System Files_Interview.md의 답변을 읽고,
CMDS System Files_v3/ 폴더의 템플릿을 참고하여
나에게 맞는 CMDS 시스템 파일 5개를 볼트 최상위에 만들어줘.
**파일 및 용도
| CMDS.md | 나의 지식관리 철학 + 워크플로우 전체 설계도 |
| CLAUDE.md | Claude Code 전용 기술 가이드 |
| AGENTS.md | Gemini 등 기타 AI 에이전트 가이드 |
| 🏛 CMDS Head Quarter.md | 카테고리 전체 네비게이션 허브 |
| 🏛 CMDS Guide.md | Properties 표준, 노트 규칙, 템플릿 |
Claude Code가 자동으로 생성한 것들:
- 폴더 구조: 00. Inbox ~ 90. Settings 10개 최상위 폴더 + 하위 폴더
- CMDS 카테고리 노트: 📖 1단계(9개) + 📚 2단계 서브카테고리 노트 전체
- 인덱스 노트: 교안 목록, 유튜브 영상 목록, 후견보고서 기록 등
- 템플릿: 기본 노트, 회의록, 데일리 노트, 교안/커리큘럼, 보고서 등
## 해결된 문제들
1. 교안 이미지 재활용
50. Assets/53. Image Assets/ 폴더에 소재별로 분류 저장합니다. 음식재료, 꽃, 동물, 계절... 다음 교안 기획 때 바로 꺼내 씁니다. AI 재생성 없이요.
동물 폴더에 저장했어요. 색칠오리기도안_거북이.png 파일명이 이런 형식인데, 이미지를 메타데이터로 관리하는 방법?
2. 교안 아이디어 관리
📚 102 Topics에 바로 기록합니다. 다음 주제 선정 때 여기서 꺼내 씁니다.
교안은 pdf 형태인데, 볼트 안에는 최대한 md 파일만 관리한다는 고수가 있었어요. 관련된 모든 파일을 볼트에 넣을 수는 없으니 어떻게 하는 것이 효율적일지 궁금합니다.
3. 치매공공후견 보고서 자동화
방문 기록을 📚 301 피후견인 기록에 쌓아두면, Claude Code가 한글파일 복붙용 초안을 생성합니다. 이 기록을 바탕으로 연간보고서와 발표자료 만들기
4. 스터디 노트 정착
노션 여기저기에 흩어져 있던 AI 스터디 노트가 📚 630 Generative AI로 모입니다.
## 앞으로 더 알아보고 싶은 것
다양한 형식의 데이터를 옵시디언 볼트, md 파일과 효과적으로 연결하고 관리해나가는 방법을 찾아나가야 겠다.
소개
지난번에 상급종합병원 손익계산서 데이터를 분석해 리포트를 만드는 프로젝트를 성공적으로 마무리했었습니다.
그런데 문득 이런 생각이 들었습니다.
"이걸 더 자유롭게 분석할 수는 없을까?"
정해진 분석 결과를 보여주는 리포트도 의미 있었지만,
사용자가 직접 비교하고, 선택하고, 탐색할 수 있는 대시보드 형태로 확장해보고 싶었습니다.
이번 프로젝트는 완전히 새로운 시도가 아니라,
기존 프로젝트를 디벨롭(Upgrade) 하는 과정이었습니다.
그리고 한 가지 더 도전한 것이 있습니다.
"대시보드처럼 구조가 있는 프로젝트는 형상관리가 필요하지 않을까?"
그래서 GitHub도 함께 공부해보았습니다.
아직 push는 성공하지 못했지만요…ㅎㅎ 😅
진행 방법
1️⃣ 데이터 구조 이해부터 시작
46개 상급종합병원 손익계산서 (2022/2023)
병상수 데이터
전문의수 데이터
손익계산서의 고정 행번호 구조를 파악하고 매핑 테이블을 만들었습니다.
ROW_MAP = { 12: "의료수익", 13: "입원수익", 76: "연구수익", 103: "연구비용", 150: "당기순이익"
}
✔ 구조를 먼저 이해하니, 이후 확장은 어렵지 않았습니다.
✔ 각 지표의 매핑 테이블을 만들어야겠다는 아이디어만 있었고, 추출하고 매핑하는 과정은 모두 Claude가 했답니다!
2️⃣ Python → 단일 HTML 대시보드 생성 구조
서버 없이 실행되는 구조를 목표로 했습니다.
Python으로 모든 데이터 파싱
파생지표 계산 (이익률, 병상당 수익 등)
JSON 형태로 HTML 내부에 삽입
Chart.js CDN 사용
python3 151_build_dashboard.py
한 번 실행하면 152_dashboard.html이 생성되고,
브라우저에서 바로 열어볼 수 있도록 만들었습니다.
온라인 연결 없이도 대시보드가 작동한다는 점이 가장 신기했습니다.
3️⃣ 자연어 기능 시도 → UI 기반 비교로 전환
처음에는 자연어 질의 기능을 넣어보았습니다.
예:
"부울경 지역 연구수익을 서울 Big4와 비교해줘"
하지만 생각보다 안정적으로 동작하지 않았고,
결국 방향을 바꾸었습니다.
👉 사용자가 직접 선택하는 UI 기반 비교 분석 탭으로 전환
구성 요소:
셀렉트박스: 지역권 / 병원 그룹
체크박스: 개별 병원 선택
라디오버튼: 29개 지표 선택
좌/우 패널: 대상 vs 비교군
특히 인상 깊었던 부분은,
줄글로만 UI 요구사항을 설명했는데도 AI가 구조를 정확히 구현해준 점
그리고 병원 그룹핑도 자연스럽게 정리된 점이 놀라웠습니다. 😮
비교군을 선택하고 분석 지표를 선택하면,
이렇게 그래프와 함께 분석 요약까지 출력해준답니다!
결과와 배운 점
💡 가장 크게 배운 점
"무엇을 분석할지 구조적으로 사고할 수 있다면, 만드는 건 생각보다 어렵지 않다."
AI 코딩 도구는 생각보다 더 빠르고, 더 정확하게 구현해줬습니다.
핵심은:
✔ 데이터 구조 설계
✔ 지표 정의
✔ 비교 방식 결정
이 세 가지가 명확하면 구현은 빠르게 진행되었습니다.
✨ 인상 깊었던 경험
UI 전환이 생각보다 매끄럽게 구현된 것
그룹핑 로직이 자동으로 정리된 것
오프라인 HTML 구조가 안정적으로 작동한 것
그리고 무엇보다,
같은 아젠다를 다양한 결과물로 확장하는 과정이 정말 재미있었습니다.
리포트 → 대시보드 → 비교 분석 도구
같은 데이터도 어떻게 설계하느냐에 따라 완전히 다른 결과물이 된다는 걸 경험했습니다.
🔜 앞으로의 계획
GitHub push 성공하기 😅
병상 데이터 미매칭 병원 정리
추가 비교 시나리오 확장
사용자 피드백 기반 개선
독자에게 남기고 싶은 말 💬
같은 아젠다라도 결과물은 무궁무진합니다.
더 좋은 아이디어가 있다면 함께 나눠주세요!
AI는 마법이 아니라 협업 도구라고 느꼈습니다.
설계를 내가 하면, 구현은 정말 빠르게 도와줍니다.
혹시 비슷한 프로젝트를 고민 중이라면,
작게라도 한번 시작해보세요 🚀
📊 데이터로 시작한 나의 첫 부동산 탐험기 - 3부
참고 문서 : https://dev.to/menilek/when-it-comes-to-refactoring-code-should-we-tidy-first-5df8
https://www.youtube.com/watch?v=XmsyvStDuqI
지피터스 스터디장님들께서 방향을 빠르게 제시해준 덕분에 저번주에 이미 기능 구현은 모두 끝났었습니다.
그래서 Tydy 방식을 AI에게 맡겨보고 진행하고자 하였습니다.
Cursor에서 요청 시 이렇게 Question을 내놓기 때문에, 편리하게 선택 후 진행하였습니다.
(개인적으로 복잡도가 높은 문건의 경우, GPT를 선호하기 때문에 Codex로 진행하였습니다. 무조건 Reasoning은 Xhigh로..!)
API 모듈 중간 점검
백엔드 모듈 중간 점검
깔끔하게 떨어지네요.
특히
이 문건처럼 '변경이 안전한 이유'를 별도로 명시하고 나오는 것이 참 좋았습니다.
이후에 다음과 같이 작업을 진행합니다.
Build 처리하고 진행하였습니다.
깔끔하게 관련 리팩토링이 진행되었네요.
Tidying 방식을 채용하면 어느것이 리팩토링에서 먼저인지 우선순위를 정할 수 있고, 이후에 최소한의 변경을 통해 먼저 하나씩 리팩토링할 수 있어 좋습니다.
물론 실제 프로덕션에서는 이를 Hooks로 잡아두면 더 좋을거 같네요.
실제 수정 시
이렇게 깔끔하게 처리해줍니다 🙂
📝 한줄 요약
메타 리드 광고에서 수집되는 리드를 Stibee 뉴스레터 구독자로 자동 추가하고, 동시에 내부 DB에도 저장되도록 자동화 파이프라인을 구축했습니다. 하루 10~15분씩 수동으로 하던 작업이 완전히 사라졌어요.
🎯 이런 분들께 도움돼요
메타 광고로 리드를 수집하는 캠페인을 운영 중인 마케터
리드 데이터를 수동으로 옮기는 반복 작업에 지친 분
뉴스레터 구독자 추가를 자동화하고 싶은 분
😫 문제 상황 (Before)
지피터스는 메타 리드 광고로 뉴스레터 구독자를 모으고 있었어요.
광고는 24시간 돌아가는데, 리드가 들어올 때마다 제가 직접:
메타 광고 관리자에서 새 리드 확인
이메일, 이름 복사
Stibee 주소록에 붙여넣기
내부 DB에도 따로 정리
이 과정을 매번 반복했습니다. 리드가 실시간으로 쌓이는데 제가 확인하고 옮기는 건 하루에 한두 번이라 타이밍도 늦었고, 단순 반복 작업에 시간이 계속 빠져나갔어요.
🛠️ 사용한 도구
AI 코딩 도구: Claude Code
모델: Claude Opus 4.5
연동 서비스: Zapier, Fly.io, PostgreSQL(Neon)
🔧 작업 과정
메타 리드 광고를 진행 중이고, 메타 리드 폼에 데이터가 쌓이면 자동으로 PostgreSQL에 쌓는 것과 동시에 Stibee 뉴스레터 구독자 주소록에 내용이 자동으로 채워지게 구현하고 싶어.
Claude Code가 전체 아키텍처를 설계하고, Node.js Express 서버 코드를 만들어줬어요. Webhook 수신, DB 저장, Stibee API 연동까지 필요한 파일을 전부 생성했습니다.
메타 -> 스티비 연동
위 과정은 Zapier 를 통해 아주 간단히 진행했습니다.
Zapier 사용이 처음이었는데 클로드 코드가 가이드를 상세히 줘서 이건 정말 어렵지 않게 연동할 수 있었습니다.
메타 -> PostgreSQL 데이터 연동
Railway 배포하려다 유료라서 Fly.io로 전환
처음엔 Railway에 배포하려고 했는데, 무료 기간이 끝났더라고요. Claude Code에게 물어봤어요.
Railway 유료야? 다른 무료 서비스로 안내해줘. Fly.io는 어때?
Fly.io가 무료 티어도 있고 서버가 계속 깨어있어서(슬립 없음) Webhook 받기에 적합하다고 했어요. 그래서 바로 전환했습니다.
Claude Code가 Dockerfile이랑 설정 파일 만들고, CLI 설치하고, 환경 변수 세팅하고, 배포까지 터미널에서 직접 실행해줬어요.
이러한 서버 관련한 것들이 어떤 것들이 있고 어떤 장단점이 있는지도 클로드코드에게 요청을 하였고 쉽게 고르기만 했었습니다.
Meta Webhook 설정이 안 돼서 막혔어요
서버는 떴는데, 문제는 Meta 개발자 콘솔이었어요. Webhooks 메뉴를 아무리 찾아도 안 보이는 거예요.
Claude Code가 여러 경로를 안내해줬는데 계속 없었어요. 알고 보니 제가 만든 앱 유형(비즈니스용 Facebook 로그인)에서는 Webhooks 제품 추가가 안 되는 거였습니다.
여기서 막힐 뻔했는데, Claude Code가 대안을 제시했어요.
Zapier로 우회해서 오히려 더 간단해진 공정
Zapier로 이미 Meta → Stibee 연결하고 있다고 하셨죠? Zapier에서 우리 서버로도 데이터를 보내면 됩니다!
이미 Zapier로 Stibee 연동은 해둔 상태였거든요. 거기에 우리 서버로 데이터를 보내는 액션만 추가하면 되는 거였어요.
Claude Code가 서버에 Zapier 전용 엔드포인트를 추가하고 재배포했습니다. 그다음 Zapier 설정을 단계별로 안내해줬어요.
URL 넣는 곳, 데이터 매핑하는 방법을 하나씩 따라 했더니 테스트 성공! Success: true, ID: 1 결과가 떴을 때 진짜 뿌듯했어요.
리드가 쌓이는 걸 실시간으로 DB에 저장도 하고, Stibee에 발송 대상으로 추가하는 것들이 자동화된 게 너무 좋았습니다.
✅ 결과 (After)
Before vs After
항목
Before
After
리드 → Stibee 추가
수동 (하루 1~2회)
자동 (실시간)
리드 → 내부 DB 저장
수동 정리
자동 저장
소요 시간
하루 10~15분
0분
웰컴 이메일 발송
늦음
즉시
최종 구조
메타 리드 광고 → Zapier → Stibee 구독자 추가 ↓ Fly.io 서버 → PostgreSQL 저장
결과물
DB: PostgreSQL ops_meta_paid.meta_leads 테이블에 리드 자동 저장
Zapier Zap 게시 완료, 자동화 작동 중
🚀 앞으로의 계획
fly.io 를 사용한 이유가 메타에서 postgresql 로 데이터를 보내는 과정에서 서버가 필요했었던 거 같은데, 이 과정이 Zaiper를 이용하게 되면서 사실상 필요 없지 않을까 하는 생각을 했습니다.
그래서 아래와 같이 클코에게 물어보니 아니나 다를까 그랬더라구요.
시간 날 때 그래서 다시 이 부분을 조금 더 단순한 공정으로 (fly.io 안 거치게) 수정해두려고 합니다.
파워리버 데이터로 시작한 나의 첫 부동산 탐험기 2편 — Gemini API와 검색 기반 인사이트 추출
소개
1편에서는 Streamlit과 공공데이터 API를 통해 부동산 데이터를 수집·정리·시각화해보는 시고를 했어요.
금일은 “표”이 아닌 “인사이트”에 가게 위해, 좀 더 가치적인 보안을 해보려고 했습니다.
정확히는 "무엇이 트여나오고 가격이 드린 것인가?" 를 해석하기 위해, Google Search 검색과 개인 진화를 가능하게 해주는 Gemini API의 Grounding 기능을 활용했어요.
진행 방법
사용 도구
Gemini API + Google Search Grounding
Streamlit (다양한 데이터 표시 목적)
진행 과정
Streamlit에서 지역 별 가격 평균 월목 중 “트여나오는” 것과 같은 관찰점을 보여주는 차트를 구성
각 “트여나온 시점”에 대해, Gemini API에 다양한 Prompt를 전달:
Gemini가 검색 Grounding을 통해 반환한 결과를 통해:
지역과 관련된 지원 정책
공간과 관련된 개발/지역 지원 기여
건설, 건파 중복과정 등을 각 가격 피해 정보로 정리
이 결과를 다시 Streamlit 차트에 규칙적으로 표시
실제 데이터 결과
"""분석 기간인 2025년 10월 25일부터 2026년 1월 23일까지 한국 부동산 시장은 정부의 고강도 규제 정책과 거시경제적 불확실성이 정면에 충돌하며 극심한 가격 변동성을 보였습니다. 2025년 10월 15일 발표된 정부의 부동산 대책은 시장 과열을 막기 위한 강력한 규제 의지를 담았으나, 이에 대한 효력 여부를 두고 시장 내 논란과 소송이 이어지는 등 정책 신뢰도에 균열이 발생했습니다(나무위키 '10.15 부동산 대책' 인용). 또한 한국은행 기준금리가 2025년 하반기 2.50% 수준으로 인하되며 유동성 공급의 불씨가 살아난 가운데, 2026년 초에는 다시 금리 동결 기조로 전환되는 등 통화 정책의 변동성도 시장의 불안 심리를 자극했습니다(한국은행 보도자료 인용). 특히 이 시기는 수도권의 공급 부족 우려와 '똘똘한 한 채'를 향한 선호 현상이 심화되며 특정 핵심 지역으로의 수요 쏠림이 가속화된 시점으로 분석됩니다.
시장 데이터에 따르면, 해당 기간 평균 거래가격은 직전 동기간 대비 48.6% 급상승했고 거래건수 또한 63.6% 증가하며 시장이 극도로 과열된 '활황 국면'을 나타냈습니다. 이는 정부의 10.15 대책과 같은 규제에도 불구하고, 공급 부족에 대한 불안감과 금리 인하 기대감이 선반영되면서 매수세가 폭발적으로 유입되었기 때문으로 풀이됩니다. 특히 ㎡당 가격 상승률(+46.3%)과 평균 가격 상승폭이 유사한 점은 중소형과 대형 면적을 가리지 않고 전반적인 지가 상승이 이루어졌음을 의미하며, 거래 가격의 넓은 범위(5,900만 원~155억 원)는 초고가 단지의 신고가 경신과 저가 매물의 활발한 소진이 동시에 일어나는 시장 양극화를 시사합니다. 결론적으로 이 기간은 규제의 역설과 공급 불안이 맞물려 가격 변동성이 극대화된 시기였으며, 시장 신호는 여전히 강력한 상승 동력을 유지하고 있었을 가능성이 큽니다."""
결과와 배우는 점
데이터가 “어느 지역의 가격”이라는 구체적 정보에서 “어느 지역에서 무엇이 있어서 트여날 것인가?”로 내용의 수준이 변해
수집과 시각화 종이에서 결국 “분석”으로 진화
저녁 학생시에 들어가기 전에 학교 앞 문에 나와있던 건설하고 공직 되어있던 공고 파는 건물이 건설 되는 것과 같은 사실과 결합되면 데이터가 “설명되는” 것을 착각
따라서 “화이팅”이 아닌 “정보의 관계 방향성”을 보겠다는 것을 느낀 기호
도움 받은 글
푸디 스터디장님의 의견:
"다른 사람들고 다른 것 하는 것같지만, 데이터 속에서 사람들의 행동 패턴을 보고 인사이트를 내릴 수 있는 것이 차류점이며 가격이 트여지는 것과 동시에 무엇이 있었는지가 종합적으로 분석되어야 의미가 있을 것…"
하면 되는 것과 안 되는 것은 자동적으로 결정되는 것과 같아요. “생각하고, 해보고, 보여주는” 것의 모든 고려가 AI가 되는 것 같아요. 모두들 부동산을 보고 있으면, 이제는 데이터를 보세요!
소개
지난 시간, 딥리서치가 다 에러가 나는 바람에 다 보여드리지 못했던 결과물을 보여드리려고 해요.
✅ 취업 준비용 딥리서치 워크플로우
먼저 전체 흐름을 소개해 드릴게요.
실제로 해보면 보기보다 간단한 과정입니다.
한 단계씩 해볼게요.
✅ 진행과정
1. 프롬프트 고도화
과제 페이지에 올라왔던 기업 & JD 분석 프롬프트 입니다.
파트1. {기업명}에 대한 심층 분석 보고서를 작성해주세요:
1. 회사 개요 및 비즈니스 모델
2. 주요 제품/서비스 및 시장 점유율
3. 최근 3년간 재무 상황 및 성장 추세
4. 주요 경쟁사 비교 분석 (최소 3개사)
5. 해당 산업 최신 트렌드 및 기업의 대응 전략
6. SWOT 분석
7. 조직문화, 일하는 방식
모든 데이터는 신뢰할 수 있는 출처와 함께 제시해주세요. 파트2. 채용공고(JD)를 분석하고 다음 정보를 제공해 주세요:
1. 핵심 업무 5가지와 각 중요도(상/중/하)
2. 필수 기술역량 vs. 우대사항 비교표
3. 명시적/암묵적 소프트 스킬 목록
4. 현업 면접관이 물을 가능성 높은 질문 5개
[채용공고 파일 첨부하기] 파트3. 나의 이력서와 JD를 비교하여 역량 일치도를 확인하고, 강점과 약점을 분석해 주세요. 결과는 시각적으로 제시해 주세요
[이력서 파일 첨부하기]
충분히 좋은 프롬프트이지만 더 꼼꼼히 만들어 봅니다.
만드는 방법은 2가지 소개했었는데요,
1) 제미나이는 제미나이에게, GPT는 GPT에게
: 제미나이 딥리서치로 돌릴 프롬프트는 제미나이한테 '딥리서치용으로 고도화 해줘.'
GPT 딥리서치로 돌릴 것은 GPT에게 물어봐서 업그레이드 시킵니다.
2) 딥리서치용 봇에게 요청합니다.
https://chatgpt.com/g/g-67e2161dd7b88191bfc4e6b56b66ce90-dibriseoci-peurompeuteu-jagseong-doumi
: 엄~~~청 꼼꼼하고 자세한 프롬프트가 나오는데.. 그만큼 채워 넣어야 할 것도 많았어요. 정답은 없는 것 같아요. 이미 모델들이 똑똑해서 어떻게 해도 자세히 리서치 해줍니다. 😅
분석해야할 내용이 많아서 파트1과 파트 2,3으로 나눠서 2번에 걸쳐서 분석하려 합니다.
프롬프트도 2개로 나눠서 만들었어요.
저는 위의 gpt로 만든 프롬프트를 써봤어요. (헉 길어요;; 기업분석 프롬프트만..)
# [Deep Research Prompt] {기업명} 채용 준비용 심층 기업 분석 ## 목적
- {기업명}에 대한 **채용 인터뷰 대비** 중심의 종합 분석 리포트를 생성한다.
- 지원 예정 포지션: {직무/레벨}, 타깃 지역/시장: {지역/국가}.
- 산출물 언어: {한국어/영어/혼합}. 최종 제출 형태: {슬라이드형 요약/서술형 리포트/테이블 중심}. ## 분석 범위 및 기간
- 기본 기간: 최근 {3~5}년, 분기 데이터 포함 시 최근 {8~12}개 분기.
- 최신성 기준: {YYYY-MM-DD}.
- 상장/비상장: {상장/비상장}. 비상장 시 공개 대리지표(뉴스, 인터뷰, 채용공고, 유저 트래픽 등)로 **삼각검증**. ## 산출물(섹션 & 형식)
1) **회사 개요 & 비즈니스 모델** - 수익원(제품/구독/광고/트랜잭션), 가치사슬, GTM(세일즈 모션/파트너/채널). - **비즈니스 모델 캔버스** 1표. 2) **제품·서비스 & 시장 점유** - 핵심 제품 라인업/가격대/차별화 포인트, 로드맵(일정/마일스톤). - 시장 구조(TAM/SAM/SOM 추정 근거 포함), 경쟁 우위 지표. - **경쟁 기능·가격 매트릭스** 1표, **TAM/SAM/SOM 표** 1표. 3) **재무 & 성장 추세 (최근 {3~5}년)** - 매출/성장률/총이익률/영업이익/FCF, 세그먼트/지역별 기여도. - **트렌드 차트(매출·마진)**, **세그먼트별 표**. 4) **경쟁사 비교 (최소 3~5개)** - 선택 기준: 동일 카테고리/대체제/상위·신흥 플레이어. - 포터 5력, 유닛 이코노믹스(LTV/CAC), 네트워크 효과/전환비용 분석. - **비교 스코어카드 표** 1개. 5) **산업 트렌드 & 규제** - PESTEL(정치·경제·사회·기술·환경·법) 요인, 표준/규제/보안 이슈. - 거시 변수(금리/환율/원자재/IT 사이클)가 수요·마진에 미치는 영향. 6) **전략 & 실행** - 최근 12~24개월 전략적 움직임(M&A, 파트너십, 가격/패키징 변경, 채용·조직 개편). - 성공/위험 가정, 북극성 지표(NSM), 리스크 완화책. 7) **SWOT** - 인터뷰 대비 관점으로 Strength/Weakness/Opportunity/Threat 각각 **3~5개** 핵심 근거 포함. 8) **조직문화 & 일하는 방식** - 리더십/가치/워크모델(오피스/하이브리드/리모트), 엔지니어링·제품 운영 리듬(스프린트, RFC, 온콜). - 채용공고/어닝콜/블로그/글래스도어 등에서 **행동특성 및 평가기준** 추출. 9) **인터뷰 대비 아웃풋** - (a) **엘리베이터 피치(60–90초)**: {기업명}의 가치제안·차별화·시장전망. - (b) **역질문 리스트 10개**: 제품/전략/조직문화/성장 관련. - (c) **30-60-90 플랜(직무 맞춤)**: 목표·활동·지표, 리스크·의존성 포함. - (d) **역량-경험 매핑 표**: JD 핵심 요구 vs 내 경험 STAR 매핑. 10) **리스크 & 레드플래그** - 규제/보안/품질/평판/집중 리스크(고객·공급·채널), 회계 이슈 가능성. 11) **결론 & 액션아이템(채용 관점)** - 합류 타당성 요약, 입사 전 사전 학습·관찰 포인트, 첫 90일 빠른 성과 아이디어. ## 방법론·검증 규칙
- **삼각검증**: 1차(공시/IR/감사) → 2차(시장/애널) → 3차(뉴스/블로그/리뷰) 교차 확인. 수치 불일치 시 이유/범위 명시.
- **추정치 표시**: 비공개 지표는 가정·모형·근거(유사기업 멀티플, 트래픽·모바일 인덱스, 공시 단서) 명시.
- **최신성**: 모든 수치·발언에 날짜(YYYY-MM-DD) 표기, 24개월 이상 자료는 “역사적”으로 라벨.
- **출처 표기**: 문장·표·도표 단위로 각주/링크 제공. 신뢰도 등급(A/B/C) 부여.
- **한계/가정 로그**: 데이터 공백, 샘플 바이어스, 대체 지표 사용 사유 기록. ## 우선순위 소스(예시)
- 공시/IR: 10-K·10-Q·사업보고서, 실적 콜 트랜스크립트, 감사보고서.
- 시장/규제: {해당 산업 협회/정부통계/규제기관}, 주요 리서치(가트너/IDC 등).
- 제품/기술: 제품 문서, 릴리즈 노트, 엔지니어링 블로그, 컨퍼런스 발표.
- 채용/문화: 공식 채용 사이트, Glassdoor/Blind(정성 참고), 링크드인 인력 구조.
- 뉴스/분석: 전문 매체, 애널리스트 코멘트(출처·날짜 필수). ## 출력 형식
- 상단에 **행정 요약(1~2페이지)**.
- 본문 각 섹션에 **표/차트 최소 1개** 포함.
- 모든 수치 단위·통화 명시, 환율/회계기준 기재.
- 마지막에 **참고문헌/데이터 사전/가정·한계 로그/원자료 링크 모음(부록)**.
2. 명확한 지시사항 추가
위 프롬프트의 빈칸{ } 을 잘~ 채워줍니다.
파트 2,3 부분의 JD에는 채용공고와 지원자의 이력서를 넣었습니다.
(이번 예시는 마켓컬리로 해보았습니다.)
3. 다중 플랫폼 딥리서치
여러 개 플랫폼을 돌려보고 비교하면 각각 다른 인사이트를 얻을 수 있습니다.
교차 검증도 돼서 내가 잘 모르는 지식이더라도 환각을 가려낼 때 좋기도 하고요.
1) 기업분석 딥리서치 결과
챗GPT
https://chatgpt.com/s/dr_6979cb2faf44819194a1fc29f42063fd
제미나이
https://gemini.google.com/share/9e87b965d2f8
퍼플렉시티
https://www.perplexity.ai/search/makeskeolri-caeyong-junbiyong-en5VdwV7TdqVqXc.i9DLFw#0
2) 채용공고, JD 분석 및 역량
챗GPT
https://chatgpt.com/s/dr_6979d33975108191a0744bb47e6193a3
제미나이
https://gemini.google.com/share/5afe6e8e92a0
📍환각 골라내기!
3가지 정도 리서치 시켰을 때 비슷한 얘기를 하는 부분(마켓컬리의 흑자 전환 및 재정 위기 구조 등)은 신뢰성이 높다고 생각해요. 하지만 수치로 얘기하는 부분은 근거가 없는 걸 얘기하거나 연도와 데이터의 매치가 틀리는 등 환각이 많이 보였어요. 숫자를 얘기해야 하는 내용이 있다면 더 꼼꼼히 분석해야 할 것 같습니다.
다만, SWOT 분석이나 지원자의 역량 분석, 접합성 등을 분석한 인사이트는 비슷한 결로 얘기하고 있었고 환각도 적다고 느꼈어요. JD 분석, 시장 분석 경쟁사 분석 등의 내용도 큰 그림에서는 신뢰하고 봐도 될것 같아요.
4. 제미나이 기반 2차 결과물
이 부분을 보여드리려다 에러가 나버린;;; 그리고 그 이후에도 밤마다 에러를 뱉어내던 이녀석들...
제미나이 딥리서치에서는 활용도가 높은 2차 결과물을 만들수 있어요.
웹페이지/인포그래픽 : 긴- 보고서 형식의 딥리서치를 한눈에 파악하기 쉽습니다.
AI 오디오 오버뷰 : 이동하며 팟캐스트처럼 들을 수 있어서 좋습니다. 👇
그런데? 웹페이지 / 인포그래픽이 예전에는 예~쁘게 보여줬단 말이죠?
(ㄴ예전에 만들었언 것)
근데 오류인지 최근 며칠은 계속 html 코드만 뱉어 냅니다..
😊 이렇게 코드를 주면 못 볼줄 알고? 훗- 예쁘게 보는 방법이 다 있지요~ 🤩
1) 새 채팅 -> "Canvas" 클릭
2) '걍 해줘' -> 짜란~
참고로 웹페이지 / 인포그래픽은 둘다 웹페이지 형식의 결과물입니다. (왜 나눈건지;;;)
결과 및 인사이트
🔍 교차 검증을 통한 정확도 향상
3개 플랫폼 결과가 일치하는 경우 → 신뢰도 ↑
수치 기반 데이터는 환각 위험이 높으므로 추가 확인 필수
⚠️ 시행착오 및 주의점
Gemini 플랫폼 에러 빈번 → 시간 분산 실행 추천
HTML 결과물 시각화 실패 시 Canvas로 해결 가능
(결과 및 인사이트 섹션은 사례게시글 GPT의 도움을 받았습니다. 😋)
〰️🚣🏻♀️〰️🚣🏻♀️〰️🚣🏻♀️ 부 록 〰️🚣🏻♀️〰️🚣🏻♀️〰️🚣🏻♀️
프롬프트부터 너~~무 복잡해! 한다면.. 걍 과제에 있던 프롬프트만 넣고 한방에 딥리서치 돌려도 돼요 😁
요거요 👇
파트1. {기업명}에 대한 심층 분석 보고서를 작성해주세요:
1. 회사 개요 및 비즈니스 모델
2. 주요 제품/서비스 및 시장 점유율
3. 최근 3년간 재무 상황 및 성장 추세
4. 주요 경쟁사 비교 분석 (최소 3개사)
5. 해당 산업 최신 트렌드 및 기업의 대응 전략
6. SWOT 분석
7. 조직문화, 일하는 방식
모든 데이터는 신뢰할 수 있는 출처와 함께 제시해주세요. 파트2. 채용공고(JD)를 분석하고 다음 정보를 제공해 주세요:
1. 핵심 업무 5가지와 각 중요도(상/중/하)
2. 필수 기술역량 vs. 우대사항 비교표
3. 명시적/암묵적 소프트 스킬 목록
4. 현업 면접관이 물을 가능성 높은 질문 5개
[채용공고 파일 첨부] 파트3. 나의 이력서와 JD를 비교하여 역량 일치도를 확인하고, 강점과 약점을 분석해 주세요. 결과는 시각적으로 제시해 주세요
[이력서 파일 첨부]
요 프롬프트의 결과물 보기
- 챗 GPT
https://chatgpt.com/s/dr_6979e1e622d08191adadeb8a313b2ec7
- 제미나이
https://gemini.google.com/share/14a1bdd4cfbb
(ㄴ 웹페이지 https://gemini.google.com/share/288c2df4aa6e )
(ㄴ 인포그래픽 https://gemini.google.com/share/f34a86ccc587)
📝 한줄 요약
"강의 준비하려면 영어로 된 사이트 100페이지를 다 읽어야 한다고?" 2주 걸릴 일을 반나절 만에 끝낸 비결은 바로 '말로 시키는 AI'였습니다.
바쁘시면 이것만 읽어도 돼요:
목표: 영어로 된 ACT 치료 자료 방대한 양(100+ 페이지, PDF 30+개)을 한글로 정리하고 수집하기
성과: 꼬박 1~2주 걸릴 단순 반복 작업을 반나절 만에 자동화 완료
핵심: 복잡한 코드 작성 없이 "이 사이트 크롤링해줘", "PDF도 번역해줘"라고 말로만 요청
비결: GPTers 스터디에서 배운 '구체적인 요청(메타 프롬프트)' 방식 적용
도구: Antigravity (비개발자도 쓰기 편한 AI 코딩 에이전트)
🎯 이런 분들께 도움돼요
방대한 자료 조사가 필요한 대학원생, 연구자
강의 자료 준비로 시간을 쫓기는 강사님들
"크롤링? 파이썬? 그게 뭐죠?" 코딩은 모르지만 데이터는 필요한 분들
😫 문제 상황 (Before)
공부도 하고 강의 자료도 준비해야 하는데, actwithcompassion.com이라는 보물 같은 사이트를 알게 되었습니다. 하지만 들어가 보니 자료가 너무 방대하고(100페이지 이상), 전부 영어라 막막하더군요.
예전 같았으면 최소 1~2주는 걸렸을 겁니다.
일일이 페이지 들어가서 읽고 번역기 돌리고
PDF 다운받아서 파파고에 복사-붙여넣기 하고
폴더별로 정리하고...
제가 속한 'AI 워크스페이스' 같은 스터디 그룹의 'Suyoil(수요일)'님이 위키피디아 방식의 강의안 제작을 안티그라비티로 진행하시는 것에 영감을 받아, 클로드 코드도 아직 익숙치 않치만, 안티그라비티 사용에도 도전해보았습니다. 말씀주셨던 '구구절절 프롬프트' ^.~ 정말 좋더라구요.
다른 업무도 바쁜데 틈틈이 이 '노가다'를 해야 한다고 생각하니 엄두가 안 났습니다. "누가 대신 싹 긁어서 한글로 번역해서 내 책상 위에 올려줬으면 좋겠다"는 생각이 간절했죠.
🛠️ 사용한 도구
도구명: Antigravity (Google DeepMind)
특징: 복잡한 설치나 설정 없이 대화하듯 명령하면 필요한 라이브러리를 알아서 설치하고 프로그램을 짜줍니다. (Claude Code보다 비개발자가 쓰기에 훨씬 편하다고 느꼈어요!)
🔧 작업 과정
1단계: "이 사이트, 싹 다 긁어줄 수 있어?" 🕷️
GPTers 스터디에서 '수요일'님의 강의를 듣고 용기를 얻었습니다. "복잡하게 생각 말고 구체적으로 말해보자!" 그래서 이렇게 요청했죠.
https://www.actwithcompassion.com/ 웹사이트에 있는 내용을, 하나씩하나씩 열어보고 그 내용을 영문으로 가져오고, 단락별로 한글로 번역해서 마크다운방식의 자료로 정리해서 저장하고 싶어. 그림파일이 있다면 그 역시 들고 오고, 다운로드 받을 수 있는 PDF파일이 있다면 다운로드 해서 같은 폴더에 모아주고. collect폴더에 이 사이트의 내용을 하나씩 크롤링해서 모조리 가져와서 정리해줘. 그러려면 필요한게 있을까? 계획을 세워 단계별로 수행해줘. 깊이 생각하고 진행해줘.
그러자 놀라운 일이 벌어졌습니다. AI가 알아서 웹사이트 구조를 분석하더니, 'About', 'Blog', 'Resources' 같은 메뉴를 파악하고 100개가 넘는 페이지를 스스로 탐색하기 시작했습니다. 제가 한 줄의 코드도 짜지 않았는데, 폴더에 번역된 한글 문서들이 착착 쌓이는 걸 보니 쾌감이 느껴지더군요.
2단계: "PDF 파일도 번역해줄래?" 📄
욕심이 생겼습니다. 웹페이지 텍스트뿐만 아니라, 치료에 쓰이는 중요한 워크시트(PDF)들도 많았거든요.
여기서 크롤링해온 자료가 PDF인 경우에는 그 내용을 읽어서, 한글로 번역한 문서를 만들어줘. PDF안에 그림이 있는 경우에는 그림 파일로 저장해주고. 영문 한 단락, 한글 번역 한 단락식으로 작업해주고, 가급적 그림이 있던 위치에 그림을 배치해줘.
AI는 PyMuPDF라는 도구를 스스로 설치하더니, PDF 파일을 뜯어서 텍스트와 이미지를 분리해냈습니다. 그리고 텍스트는 한글로 번역하고, 이미지는 원래 위치에 쏙쏙 넣어주더군요. 마치 전문 번역가가 편집해준 것처럼요.
3단계: "원본이랑 비교해보고 싶어" 🔗
번역된 글만 보다 보니, 가끔 원문이 궁금할 때가 있었습니다.
그리고 PDF번역한 내용을 보니 잘했는데, 가급적 원문이랑 같이 볼 수 있으면 좋겠어. 번역하며 생성한 문서의 제목 아래에, 원본 PDF파일명과, 연결될 수 있는 하이퍼링크를 달아주면 좋겠어. 마크다운 문서 안에서 PDF뷰어가 돌아가기엔 무리가 있지?
이 요청 한 마디에 바로 코드를 고쳐주었습니다. 이제 번역본을 읽다가 [View Original PDF] 버튼만 누르면 원본이 팝업됩니다. 공부 효율이 2배는 오르는 기분이었어요.
4단계: "컴퓨터 꺼지면 어떡하지?" 🔌
파일이 많아서 시간이 좀 걸리는데, 혹시나 노트북이 꺼지거나 프로그램을 껐다 켜면 처음부터 다시 해야 하나 걱정이 되었습니다.
시스템이 알아서 남은 작업을 마칠거라고 했잖아? 시스템이 돌아가고 있는 동안에는 이 노트북을 끄면 안되지? 중간에 끄게 되면 작업 진행되던게 멈추고, 다시 안티그라비티를 실행해야 이어서 작업을 하게 될까? 아니면 껐다 다시 실행하면 초기화가 되어서 작업 진행 정도를 잃어버리게 될까?
AI는 "걱정 마세요!"라며 '이어하기(Resume)' 기능을 추가해줬습니다. 이미 작업한 파일은 건너뛰고 남은 것만 처리하도록 코드를 수정해준 거죠. 덕분에 마음 편하게 다른 업무를 볼 수 있었습니다.
✅ 결과 (After)
Before vs After
항목
기존 방식 (수동)
AI 활용 (Antigravity)
소요 시간
1~2주 (틈틈이 작업)
반나절 (실제 작업 시간)
작업 방식
클릭, 복사, 붙여넣기 무한반복
말 한 마디로 명령해두고 커피 한 잔
결과물
뒤죽박죽 파일들
깔끔하게 정리된 135개 번역 문서
결과물
collect 폴더 안에 135개가 넘는 문서가 완벽하게 정리되었습니다. 이제 저는 '노가다' 대신, 잘 정리된 한글 자료를 읽고 공부하는 데 온전히 시간을 쏟고 있습니다.
작업결과 보고서를 작성해달라고 해도 잘 해줍니다. 번역작업은 시간이 걸리기에, 아직 진행형입니다.
💬 이 과정에서 배운 AI 활용 팁
1. "무서워 말고 일단 말 거세요"
코딩을 몰라도 됩니다. 저도 개발자가 아니지만, 원하는 걸 구체적으로 말하니 AI가 다 알아서 해줬습니다. Antigravity는 특히나 비개발자 친화적이라 좋았어요.
2. "구체적일수록 좋습니다" (feat. 메타 프롬프트)
GPTers 스터디에서 배운 대로, 두루뭉술하게 "해줘"보다는 "어떤 폴더에, 어떤 형식으로, 무엇을 포함해서"라고 구체적으로 말하는 게 핵심이었습니다.
3. "안 되면 되게 하라? 아니요, 안 되면 '고쳐줘' 하세요"
오류가 나거나 원하는 결과가 아니면 당황하지 말고 "이 부분이 이상해, 이렇게 고쳐줘"라고 피드백하면 찰떡같이 알아듣고 수정해줍니다.
🚀 앞으로의 계획
이 방식을 응용해서 논문 검색이나 뉴스 스크랩 자동화도 시도해볼 생각입니다. 이제 '자료 수집' 스트레스에서 완전히 해방된 것 같아요!
📋 재사용 가능한 프롬프트
여러분도 바로 써먹어보세요! ([ ] 부분만 본인 상황에 맞게 고치면 됩니다)
프롬프트 1: 웹사이트 전체 번역 크롤링
[웹사이트주소] 사이트를 크롤링하고, 영문 내용을 문단별로 한글로 번역하여 마크다운으로 저장해줘. 관련된 이미지와 PDF 파일도 [저장할폴더명] 폴더에 다운로드해줘.
프롬프트 2: PDF 파일 일괄 번역
[폴더명]에 있는 PDF 파일들을 읽어서, 한글로 번역한 마크다운 문서를 만들어줘. PDF 안에 그림이 있는 경우에는 그림 파일로 추출해서 원래 위치에 배치해주고, 문서 상단에 원본 PDF를 볼 수 있는 링크도 달아줘.
소개
시도하고자 했던 것과 그 이유를 알려주세요.
Dart 보고서에 있는 재무정보를 가지고 안정성 분석등을 해보고자 했다.
또한 내가 보고자하는 지표 등을 조금더 집중해 보고자 했다.
단순 지표라고 하면, 통상적인 지표만 들고 와서, 좀더 중요하다고 보는 지표를 Skill에 추가하는 방법으로 진행
진행 방법
어떤 도구를 사용했고, 어떻게 활용하셨나요?
클로드 코드에서 Vscode로 진행했고
1차주셨던 파일을 기반으로 진행했습니다.
1차적으로는 Dart에서 PDF를 다운받아, Collected에다가 저장을 하면, 클로드코드에게 지시하면 분석하는 방법으로 진행을 하였습니다. 다만, PDF가 너무 커서 진행이 안된다고 자꾸 떠서, 이걸어떻게 풀어내야하나 했습니다. (상영 스터디장님 2주차때, PDF를 읽게 하면 너무 많은 토큰을 쓰게 한다고 했는데... 저는 아예 쓰지도 않는건 왜일까요? 그리고, 다른 분것도 보니, PDF로 분석하는건 뭔가 힘들다고 하네요..)
무언가 이전주차에 겪었던걸 제가 지금 겪은 느낌이지만.
2번째 방법인 DART에서 직접 끌고와서 분석하는 방법을 진행했습니다.
약간 클로드 챗봇이나 이런데에서 해도 이정돈 나오지 않나? 살짝은 그 모호한 정도의 분석을 갖고온 느낌이였습니다. 그리고 챗봇스타일의 분석 인거 같아, 약간은
재무적인 지표를 기반으로 좀더 계산해서 지표를 갖고 왔으면 좋겠단 생각을 했습니다.
추가적으로 벨류에이션 지표 + 매출채권 회전율을 넣었습니다
(이전에 엔비디아가 매출채권증가율이 매출증가율보다 높아 실질적인 매출증가냐는 논란이 있어..)
추가적인 분석기준을 추가하여 진행하였습니다. 다만, 이건 추가분만 넣어주서 준거라 다시한번 요약.
SK하이닉스 재무 리스크 분석 결과 요약
분석 기준 적용
my-analysis-criteria.md 기준으로 3개년 추이, 매출채권 회전율, 고객 집중도, 밸류에이션을 중점 분석했습니다.
1. 3개년 손익 추이 (2022-2024)
항목
2022년
2023년
2024년
3년 CAGR
매출액
44.65조
32.77조
66.19조
+21.8%
영업이익
7.01조
-7.73조
23.47조
+82.9%
당기순이익
2.44조
-9.14조
19.80조
+185.0%
해석: 2023년 대규모 적자 후 2024년 V자 반등. 변동성이 매우 큼.
2. 수익성 지표 (반도체 벤치마크 적용)
지표
2024년
벤치마크
평가
ROE
31.1%
>15% 우수
🟢 우수
ROA
18.0%
>5% 양호
🟢 우수
영업이익률
35.5%
>25% 우수
🟢 우수
3. 효율성 지표 (핵심: 매출채권 회전율)
지표
2022년
2023년
2024년
평가
매출채권 회전율
8.1회
4.7회
4.5회
🟠 주의
매출채권 회전일수
45일
78일
81일
🟠 악화
⚠️ 경고 신호 발견:
매출채권 증가율 (+108%) > 매출 증가율 (+102%)
회전율이 업종 기준(8회) 대비 절반 수준
대금 회수 속도 저하 또는 매출 품질 이슈 가능성
4. 밸류에이션 (3개년)
지표
2022년
2023년
2024년
평가
PER
24.5배
N/A
6.4배
🟢 저평가
PBR
0.8배
1.8배
1.7배
🟡 적정
EV/EBITDA
3.5배
21.5배
3.8배
🟢 저평가
5. 고객 집중도 (3개년 추이)
연도
최대고객 비중
변화
2022년
~5%
-
2023년
~8%
↗️
2024년
16%
⚠️ 3배 증가
위험 등급: 🟡 보통 (10-20% 구간)
20% 임계치 근접 시 "주의" 등급 상향 필요
6. 위험 신호 체크리스트 결과
항목
결과
매출채권 회전율 20%↑ 하락
✅ 통과
단일 고객 20% 이상
✅ 통과
3년 연속 ROE 하락
✅ 통과
영업이익률 업종 평균 50% 미만
✅ 통과
재고만 증가
✅ 통과
매출채권 증가율 > 매출 증가율
⚠️ 해당
결과: 6개 중 1개 해당
7. 종합 평가
┌──────────────────────────────────────────────┐
│ 종합 등급: A- (양호, 일부 주의) │
│ │
│ 🟢 수익성: 우수 (ROE 31.1%, OPM 35.5%) │
│ 🟢 안정성: 양호 (부채비율 48.4%) │
│ 🟢 성장성: 우수 (매출 +102%) │
│ 🟠 효율성: 주의 (매출채권 회전율 4.5회) │
│ 🟡 집중도: 보통 (최대고객 16%, 상승 추세) │
└──────────────────────────────────────────────┘
핵심 모니터링 포인트
매출채권 품질: 2025년 1분기 회전율 추이 확인
고객 집중도: 엔비디아 비중 20% 초과 여부
사이클 리스크: AI 투자 둔화 시 실적 변동성
배운 점
배운 점과 나만의 꿀팁을 알려주세요.
과정 중에 어떤 시행착오를 겪었나요?
PDF 파일이 너무 커서 못하는 경우가 있었는데... 이건 어찌할
도움이 필요한 부분이 있나요?
1) 파일 Collected, Created가 좀 헷갈립니다. PDF을 기반으로 분석해서 생성한 파일을 만드는 경우가 있는데, 보통 원래 정리하는 방식은 분석파일을 만들면, 그 폴더안에 backdata 파일을 만드는 방식으로 진행했습니다.
- 원래 파일관리 방식 : 비즈분석 - SK하이닉스 분석(클로드로 분석) - backdata(하이닉스 pdf)
- 현재 VScode 파일관리 : Created - SK하이닉스 분석(클로드로 분석)
Collected- backdata(하이닉스 pdf)
앞으로의 계획이 있다면 들려주세요.
조금더 효용성 있는 지표 추가 및 보고서 양식을 조금 수정해보고 싶어요.
도움 받은 글 (옵션)
상영 스터디장님 글
다트 사업보고서 및 PDF분석 및 재무 리스크 도출
오늘도 아웃풋님 글
이미지로 저장된 PDF의 텍스트까지 자동으로 추출후 공유까지
📝 한줄 요약
구글 타임라인·카카오톡·문자에 흩어져 있던 11.5년치(4,073일) 내 흔적을, AI 코딩 도구로 파싱·통합하고 하루 단위 실록체 기록 3,296편으로 자동 리라이트했습니다. 손으로는 평생 못 쓸 기록이 원클릭 캘린더 앱 안으로 들어왔고, 서로 다른 포맷에 갇혀 있던 조각들이 한 날짜로 엮이는 순간 잃어버린 지난 11년이 되살아났습니다.
바쁘시면 이것만 읽어도 돼요:
뭘 했나: 스마트폰 구글 지도 내보내기(80MB, 290만 줄, 2014~2026)를 파싱해 날짜별 활동일지를 만들고, 여기에 카톡·문자를 엮어 사실/해석을 분리한 '황제실록'체 서술로 자동 변환.
정량 성과: 하루 단위 기록 0건 → 4,073일 자동 생성 + 3,296편 실록 리라이트, 최종 재확인 미처리 0건.
핵심 난관 1 — 데이터: 공식 Takeout은 단 1일치만 줬다. 스마트폰 앱 직접 내보내기로 우회해 11.5년치를 확보.
핵심 난관 2 — 품질: "이동·지출·만난 사람 나열 + 상투적 논평"에 머물던 초기 결과를, 본기(사실)와 사관 논평(해석)을 분리하는 설계로 갈아엎음.
가장 신경 쓴 것 — AI 검증: 날짜·시각·기간·건수·거리·인용을 근거 데이터와 자동 대조하는 검증 로직을 심고, false positive를 여러 차례 잡아냄. AI가 지어낸 숫자를 그냥 믿지 않았다는 게 이 프로젝트의 핵심.
민감정보: 위치·대화·문자·금융성 알림이 원본이라, 처음부터 마스킹·추상화를 파이프라인 기본값으로 박아넣음.
배운 교훈: 개인 데이터 자동화의 승부처는 "생성"이 아니라 "검증과 마스킹"이었다.
🎯 이런 분들께 도움돼요
이 글은 특히 이 두 분을 위해 썼습니다:
흩어진 개인 기록(위치·메신저·문자)을 한데 모아 잃어버린 지난 시간을 되살리고 싶은 분 — 일기를 못 쓰는 사람일수록 효과가 큽니다. 스마트폰은 이미 당신을 몇 년째 기록하고 있으니까요.
AI에게 문서 정리를 맡기고 싶지만 "AI가 지어낸 내용"이 무서워 못 맡기던 분 — 이 글의 절반은 "AI가 뱉은 걸 어떻게 안 믿고 검증했나"에 대한 이야기입니다.
그리고 아래 실무자분들께도 그대로 이식됩니다(→ 🌍 섹션 참고): 개인정보·기밀이 섞인 데이터를 다루거나, "사실"과 "해석"을 분리해 기록해야 하는 분(법률·공공·상담·HR, 경위서·회의록·상담일지 등).
😫 문제 상황 (Before)
저는 일기를 거의 못 씁니다. 그런데 스마트폰은 저 대신 11년 넘게 성실히 기록하고 있었습니다. 문제는 그 기록이 사람이 읽을 수 없는 형태였다는 것.
구글 타임라인 위치 기록은 위경도 숫자 덩어리였고,
카카오톡·문자는 각각 다른 파일 포맷에 갇혀 있었고,
이 모든 게 날짜라는 공통 축으로 엮여 있지 않았습니다.
"11.5년을 하루 단위로 정리한다"는 건 손으로는 사실상 불가능한 작업이었습니다. 4,073일을 하루 10분씩만 정리해도 680시간, 꼬박 넉 달 걸립니다. 그래서 지금까지 아무도(=저도) 손대지 못했고, 그 결과 제 과거는 검색도 회상도 안 되는 죽은 데이터로 남아 있었습니다.
결정적 계기는 어느 날 특정 과거를 되짚어 볼 일이 생겼을 때였습니다. "그게 언제였지, 그날 뭘 했더라"를 확인하려는데, 기록이 없어 아무것도 재구성할 수 없었습니다. 분명 스마트폰 어딘가엔 흔적이 있는데 꺼내 읽을 수가 없다는 그 막막함이, 미루던 일을 시작하게 만든 방아쇠였습니다.
게다가 시간이 제 편이 아니었습니다. 구글이 타임라인 정책을 바꾸면서 서버에 있던 기록은 이미 1일치로 쪼그라들었고(뒤에서 설명), 폰에 남은 11.5년치도 기기를 바꾸거나 잃어버리면 그대로 증발합니다. "지금 안 꺼내면 영영 못 꺼낸다" — 이게 이 일을 더는 미룰 수 없었던 진짜 이유였습니다.
왜 기존 방법으로는 안 됐나 (기존 대안 검토)
구글 공식 Takeout(테이크아웃)을 먼저 받아봤습니다. 그런데 구글이 타임라인을 서버 저장에서 기기 로컬 저장으로 정책을 바꾸면서, 서버 기반 Takeout에는 딱 1일치(2025-07-11~12) 데이터만 들어 있었습니다. 11.5년을 원한 사람에게 하루치는 무의미했죠.
엑셀·수작업 정리는 위에서 계산한 대로 규모 자체가 감당 불가였습니다.
예전에 비슷한 자동 요약을 시도했을 때는 결과물이 "어디 갔고, 얼마 썼고, 누굴 만났다"를 건조하게 나열하고 끝에 상투적 코멘트를 붙이는 수준이라, 다시 읽고 싶은 기록이 아니었습니다.
그리고 이 문제는 자동화·AI에 딱 맞는 성격이었습니다 — 4,073일이 똑같은 패턴의 반복이고, 위경도·시각·상호명 같은 규칙적 데이터이며, 결국 텍스트로 서술하는 일이니까요. 양이 많아 사람이 못 하고, 규칙은 코드가, 서술은 LLM이 잘하는 전형적인 영역이라 "굳이 AI?"가 아니라 "AI가 아니면 불가능"에 가까웠습니다.
즉 문제는 두 겹이었습니다 — ① 데이터를 못 모은다, ② 모아도 읽을 만하게 안 나온다. 이 프로젝트는 이 두 벽을 차례로 넘은 기록입니다.
🛠️ 사용한 도구
도구: Claude Code(파싱·일지 생성 파이프라인 설계), Codex CLI(황제실록 리라이트 백엔드 실행)
왜 나눴나: 한 도구로 다 하지 않았습니다. 정확한 파싱·파이프라인 설계는 Claude Code가, 수천 편의 문체 생성(대량 배치)은 Codex가 각각 더 잘하는 영역이라 판단해 강점을 분담했습니다.
핵심 모델: 리라이트 백엔드는 상위 추론 모델을 reasoning effort를 최고로, 응답은 빠른 티어로 설정해 대량 배치에 맞춤
데이터 소스: 구글 타임라인(스마트폰 내보내기 80.7MB), 카카오톡 대화 JSON, 문자(SMS/MMS) XML
특이사항: 원본이 전부 민감정보라, 마스킹·추상화를 옵션이 아니라 기본값으로 두고 작업
🔧 작업 과정
1막. "하루치가 전부라고?" — 데이터 소스를 갈아탄 순간
처음엔 정석대로 갔습니다. 구글 테이크아웃에서 위치 기록을 받아, 원시 신호(위치 좌표·활동·와이파이 스캔)를 파싱하는 파서를 만들고 SQLite 데이터베이스에 넣었습니다. 파서는 잘 돌았습니다 — 위치 373건, 활동 3,001건이 깔끔하게 적재됐죠.
문제는 결과를 보고 나서였습니다.
날짜 범위를 확인해줘. 데이터가 며칠치나 들어온 거야?
돌아온 답은 "2025-07-11 ~ 07-12, 약 1일치". 구글 정책 변경 때문에 서버 Takeout이 껍데기만 준 것이었습니다. 여기서 포기했다면 이 프로젝트는 없었습니다.
대신 스마트폰 구글 지도 앱에서 직접 내보내기를 시도했더니, 완전히 다른 파일이 나왔습니다.
스마트폰에서 직접 내보낸 타임라인 파일을 확인해줘. 크기랑 기간, 며칠치인지 알려줘.
파일 크기: 80.7MB, 무려 292만 줄
기간: 2014-11-29 ~ 2026-06-28, 약 11.5년
고유 날짜: 4,073일, 총 세그먼트 73,820개(장소 방문 23,518 / 이동 경로 22,468 / 활동 27,679)
요청 → 작업 → 결과 → 배운 점
같은 "구글 타임라인"인데 Takeout판과 스마트폰판은 최상위 키도, 좌표 표기법도 완전히 달랐습니다. Takeout은 정수형 좌표(원시 신호), 스마트폰판은 문자열 좌표(의미 세그먼트: 방문·경로·활동). 그래서 기존 파서를 버리지 않고, 스마트폰 포맷 전용 파서를 새로 만들어 방문·경로·활동을 각각의 테이블로 나눠 담았습니다.
→ 배운 점: 같은 서비스라도 "어느 문으로 데이터를 꺼내느냐"에 따라 양과 형식이 하늘과 땅 차이다. 공식 경로가 막히면 대체 출구를 먼저 의심하라.
2막. 위치·카톡·문자를 '같은 날짜 서랍'에 모으다 — 세 기록의 삼각측량
타임라인만으로는 반쪽짜리였습니다. 구글 타임라인은 "어디에 있었고 얼마나 움직였나"(장소·거리)는 복원했지만, 정작 "거기서 무엇을 했나"는 비어 있었죠. 좌표는 남았는데 이야기가 없었습니다.
그래서 나머지 두 조각을 마저 데려왔습니다.
카톡 대화 내보낸 거랑 문자 내보낸 것도 날짜별로 잘라서 타임라인이랑 같은 날짜에 합쳐줘.
카카오톡 대화기록: 앱에서 대화를 내보내 파일로 저장한 뒤, 날짜별로 잘라(청킹) 정리했습니다.
문자(SMS/MMS): 휴대폰에서 내보내, 역시 날짜별로 분류·청킹했습니다.
핵심은 세 소스를 전부 "같은 날짜 서랍"에 나눠 담았다는 것입니다. 위치도, 대화도, 문자도 하루 단위로 정렬되니, 특정 날짜를 열면 그날의 세 기록이 한자리에 모였습니다.
그러자 서로의 결점이 메워졌습니다.
타임라인은 동선(어디→어디, 몇 km)을 알려주고,
카톡·문자는 그 자리에서 무슨 일이 있었는지(약속·대화·맥락)를 채워주고,
특히 카드결제 알림 문자에는 방문한 상호(가게 이름)가 찍혀 있었습니다.
여기서 결정적인 장면이 나왔습니다. 카드내역의 상호명과 타임라인의 그 시각 동선을 대조하니 "이 시각, 이 좌표에 있었다 = 이 가게였다"가 딱 맞아떨어졌습니다. 서로 다른 출처가 같은 사실을 가리키자, 기록의 신뢰도가 급격히 올라갔습니다. — 이건 곧 소스끼리 서로를 자동 교차검증해준 셈입니다.
요청 → 작업 → 결과 → 배운 점
세 소스를 날짜 축으로 합치자, 좌표 덩어리였던 과거가 "언제·어디서·누구와·무엇을"이 채워진 하루로 복원됐습니다. 옛날에 갔던 장소, 자주 가던 식당, 심지어 해외여행까지 — 잊고 있던 일상이 통째로 실록의 재료가 됐습니다.
→ 배운 점: 한 소스의 빈칸은 다른 소스가 메운다. 위치의 "어디"와 대화·결제의 "무엇"이 만나는 순간 로그는 기억이 되고, 서로 다른 출처가 겹치는 지점(카드 상호 ↔ 타임라인 동선)은 공짜 교차검증이 된다.
3막. AI가 만든 첫 실록을 보고, 설계를 갈아엎다
데이터가 모이자 진짜 목표로 갔습니다 — 이 숫자 덩어리를 읽을 만한 하루 기록으로 바꾸는 것. 컨셉은 '황제실록'이었습니다. 내 하루를 임금의 하루처럼 사서(史書) 문체로 서술하는 것.
그런데 초기 결과물이 딱 "그저 그런 자동 요약"이었습니다. 어디 갔고, 얼마 쓰고, 누굴 만났는지 단순 열거한 뒤 끝에 상투적 논평을 붙이는 식. 여기서 방향을 크게 틀었습니다.
실록을 사실과 해석으로 분리해줘. '본기'에는 근거가 있는 사실만 쓰고, 상상·풍자·통찰·비유는 맨 끝 '사관은 논한다' 논평 문단에만 넣어.
이 한 줄이 결과물의 격을 바꿨습니다.
본기(本紀): 그날의 장소·이동·지출·대화·알림을 근거 기반 사실만으로 서술.
사관은 논한다: 해석·비유·통찰은 오직 여기에만. (기존의 사신은 논한다 표현도 사관은 논한다로 통일)
페르소나: 생존 인물의 실제 문체를 모방하지 않고, 기능적 페르소나만 적용 — 냉정한 앵커형, 문명비평가형, 사마천형, 소설가형.
기록 주체: 나를 항상 상(上)으로만 지칭. 실명, "사용자", 대명사 "그"는 검증으로 차단.
실제로 이렇게 나옵니다 (2024년 어느 하루, 마스킹본):
총 이동 77.6km · 14곳 방문(17시간)
상은 오전 10시 10분 자전거로 나아가 개포로에 이르고, 지하철을 이어 타 종로를 거쳐 11시 36분 서울역사박물관에 들어갔다. 앞서 인물3이 그곳에 있겠다고 알렸고, 상은 짧게 응답하였다.
상은 낮에 스타벅스에 머문 뒤 대성집(미쉐린가이드 도가니탕)에 들렀고, 사직로 골목을 지난 다음 2시간 39분 동안 9.3km를 걸었다. 저녁에는 커피스트와 Wooh Ahh Craft Beer Bar에 들렀으며, 밤에는 지하철과 자전거를 이어 타고 트레이더스 위례점에 갔다가 22시 18분 집에 들었다. 이날 총 이동 거리는 77.6km였다.
금전 기록에는 00시 44분 2,500원 결제 알림이 있고, 인물3과의 사이에 송금·수취 알림이 여러 차례 이어졌다.
통신에는 국군의 날 교통통제 예고, 방문 일정 변경 알림, 등록 사건 알림, 공연 예매 완료 알림이 섞여 있었다. 인물2가 건강·의료에 관한 개인적 사정을 청하였고, 상은 세부를 옮기지 않은 채 문서와 절차의 관점에서 답하였다.
사관은 논한다. 이동은 길고, 알림은 촘촘하며, 돈의 오감도 여러 번 맞추었다. 누가 무엇을 맡고 어디서 확인할 것인가. 절차가 일의 뼈대다.
한 편 안에 설계가 전부 담깁니다 — 본기(사실)는 시각·장소·거리·금액 같은 근거만 서술하고, 해석은 오직 마지막 "사관은 논한다" 한 문단에만. 실명은 인물2·인물3으로, 나는 상으로, 민감한 건강 얘기는 "세부를 옮기지 않은 채"로 추상화됩니다. 그리고 이 하루 안에 타임라인 동선 + 카드결제 알림 + 카톡 송금이 자연스럽게 한 흐름으로 엮여 있죠.
요청 → 작업 → 결과 → 배운 점
"사실과 해석을 섞지 말라"는 원칙 하나로, AI의 창의성은 논평 문단이라는 우리(cage) 안에서만 풀어놓게 됐습니다. 덕분에 본문은 신뢰할 수 있고, 읽는 재미는 마지막 문단이 책임지는 구조가 됐습니다.
→ 배운 점: AI에게 "잘 써줘"가 아니라 "사실은 여기, 상상은 저기"라고 자리를 지정해주면, 환각이 갈 곳을 미리 가둘 수 있다.
4막. 진짜 승부처는 '생성'이 아니라 '검증'이었다 ⭐
이 프로젝트에서 시간을 가장 많이 쏟은 곳은 글을 뽑는 부분이 아니라, AI가 뽑은 글이 사실인지 확인하는 부분이었습니다. 개인 기록은 숫자 하나만 틀려도 "가짜 기억"이 되니까요.
AI가 만든 실록이 근거 데이터랑 실제로 맞는지 자동으로 검증하게 해줘. 틀리면 걸러내.
그래서 리라이트 결과를 원본 근거와 대조하는 검증 장치를 여러 겹 심었습니다.
시각 표현: '오전/오후', '12:09', '0시 9분' 같은 서로 다른 표기를 근거 시각과 대조.
기간 표현: 시각의 '분' 성분과 실제 체류 시간(duration)을 혼동하지 않도록 구분.
건수 표현: 본문에 나온 개수를 근거 데이터의 카운트 값과 대조.
거리 표현: '총 이동거리'와 '구간별 이동거리'를 구분해 검증.
인용 검증: 대화 원문을 길게 직접 인용하지 못하도록 제한.
여기서 흥미로운 반전이 있었습니다. 검증기가 너무 깐깐해서 멀쩡한 문장을 오탐(false positive) 하는 일이 반복됐고, 그걸 여러 차례 잡아 완화했습니다. 마지막 버그는 특히 기억에 남습니다 — Urban's Court라는 표현의 아포스트로피(')를 긴 인용부호로 오인해 정상 문장을 계속 막던 문제였죠. 이걸 고치고 나서야 마지막 한 편이 통과됐습니다.
요청 → 작업 → 결과 → 배운 점
검증을 켜자 처음엔 통과율이 나빴지만, 오탐을 하나씩 교정하면서 "믿을 수 있는 자동 기록"에 가까워졌습니다. 그리고 문법 검사와 자체 테스트를 통과시킨 뒤, 논평 표지(사신은 논한다 등)가 남아 있는지 전수 검색해 0건을 확인했습니다.
→ 배운 점: AI 자동화의 신뢰도는 생성 프롬프트가 아니라 검증 규칙의 촘촘함에서 나온다. 그리고 검증기도 코드라서, 검증기 자신의 버그까지 잡아야 완성된다.
5막. "매번 서버 켜기 귀찮아" — 원클릭 캘린더 앱으로
기록이 쌓여도 매번 개발 서버를 띄우고 브라우저 주소를 입력해야 본다면, 결국 안 보게 됩니다. 그래서 열람 경험까지 손봤습니다.
매번 서버 띄우고 [localhost](http://localhost) 접속하는 게 번거로워. 클릭 한 번으로 켜지는 앱처럼 만들어줘. 다크/라이트 모드도.
월간·주간 캘린더 뷰를 만들고, 클릭 한 번으로 실행되는 앱 래퍼로 감쌌습니다. 처음 만든 라이트/다크 모드가 육안으로 차이가 거의 없길래, 라이트 모드의 배경·카드·헤더·요일 영역 색상 대비를 다시 분명하게 조정했습니다.
→ 배운 점: 자동화의 마지막 1cm는 "얼마나 쉽게 다시 열어보게 만드느냐"다. 여기서 막히면 그동안의 작업이 전부 서랍 속으로 들어간다.
6막. 3,296편을 한 번에 — 그리고 멈춰도 이어달리게
마지막은 전체 적용이었습니다. 카톡 개인/소수 지인방은 근거로 통합하되 오픈채팅·서비스성 알림은 우선순위를 낮추거나 제외하고, 민감 주제는 원문을 복원하지 않고 추상 요약 수준으로만 쓰도록 못 박은 뒤 전량 리라이트를 돌렸습니다.
전체 대상 3,296편
1차 완료 3,293편, 실패 3편
재시도로 2편 해결, 마지막 1편은 위의 아포스트로피 버그를 고친 뒤 정상 저장
최종 재확인: 미처리 0건
대량 실행이라 중간에 멈출 위험이 있어서, 2건씩 배치 처리 + 타임아웃 시 단건으로 후퇴 + 실패분 재시도 + 이미 성공한 건 건너뛰고 재개하는 안전장치를 넣었습니다. 실제로 한도(rate limit)에 걸리면 5분 뒤 재개, 그래도 안 되면 다시 5분 뒤 재개하는 운영 규칙까지 정해뒀습니다. 다행히 최종 실행은 한도 없이 완주했고, 타임아웃은 단건 후퇴로 회복됐습니다.
→ 배운 점: 수천 건 배치의 핵심은 속도가 아니라 "중단돼도 처음부터 다시 안 하게" 만드는 재개 설계다.
그리고 — 잃어버린 11년이 되살아난 순간
기술적으로 가장 뿌듯했던 건 검증기를 다듬은 순간이었지만, 개인적으로 가장 뭉클했던 건 따로 있었습니다.
앞서 2막에서 세 기록을 같은 날짜 서랍에 모았을 때, 결과물로 그 진가가 드러났습니다. "2019년 그날, 나는 여기 있었고(타임라인) / 이 사람과 이런 얘길 나눴고(카톡) / 이 가게에서 카드를 긁었다(문자)"가 한 페이지에 나란히 서자, 기억에서 지워졌던 특정 하루가 통째로 되살아났습니다. 옛날에 갔던 장소, 자주 가던 식당, 해외여행까지 — 단순한 데이터 통합이 아니라 잃어버린 줄도 몰랐던 지난 11년을 실록으로 되찾은 경험이었습니다.
→ 배운 점: 개인 데이터의 가치는 각 소스에 있는 게 아니라 "엮이는 축(날짜)"에 있다. 흩어져 있으면 로그, 엮이면 기억이다.
✅ 결과 (After)
Before vs After
항목
Before
After
하루 단위 기록
0건 (11.5년간, 사실상 불가능)
4,073일 자동 활동일지 + 3,296편 실록체 서술
데이터 확보
공식 Takeout 1일치만 제공
스마트폰 내보내기로 11.5년(80.7MB) 확보
데이터 통합
위치·카톡·문자가 각각 다른 앱·포맷에 흩어짐
3개 소스를 날짜별 청킹 후 통합(삼각측량)
기록의 깊이
타임라인만 있어 "어디"는 알아도 "무엇을"은 공백
카톡·문자·카드내역으로 "무엇을"까지 복원
서술 품질
이동·지출·사람 단순 나열 + 상투적 논평
본기(사실)/사관 논평(해석) 분리된 읽을 만한 기록
열람 방식
없음 / 80MB JSON 직접 뒤지기
원클릭 캘린더 앱(월간·주간, 다크/라이트)
미처리
—
0건 (3,293 1차 + 3건 재시도로 전부 해결)
결과물 (동작 증거)
말이 아니라 실행 로그로 남은 증거들입니다.
파싱 로그: Positions 373 / Activities 3001 / Place Visits 9 정상 적재 확인
스마트폰 데이터: 4,073 고유 날짜 / 73,820 세그먼트 집계 확인
리라이트 로그: 3293 rewritten, 3 invalid → 재시도 후 최종 summary targets=0(미처리 0)
검증: 문법 검사 통과, 자체 테스트 통과, 논평 표지 전수 검색 0건
교차검증: 카드결제 문자의 상호명 ↔ 타임라인 동선이 같은 시각·좌표에서 일치 — 서로 다른 출처가 같은 사실을 가리킴
지금도 쓰고 있습니다. 완성 후 서랍에 넣어둔 게 아니라, 주기적으로 캘린더 앱을 열어 옛날 특정 날짜를 되짚어 봅니다. 원클릭 앱으로 만든 게 결정적이었습니다 — 매번 서버를 켜야 했다면 진작 안 봤을 겁니다.
주변 반응도 있었습니다. 여자친구는 결과물을 보더니 "이거 나한테도 알려줘"라고 했고, 어느 모임에서 만난 분은 이 작업물을 보고 깜짝 놀라며 방법을 꼭 알려달라고 카카오톡으로 따로 부탁해 왔습니다. 제 데이터라 남이 직접 써본 건 아니지만, "나도 만들고 싶다"는 반응은 이 방식이 개인적 취미를 넘어 남에게도 통한다는 신호였습니다.
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
한 소스의 빈칸은 다른 소스로 메워라(삼각측량). 타임라인의 "어디"에 카톡·문자의 "무엇"을 날짜 축으로 합치니 반쪽짜리 기록이 온전해졌습니다. 게다가 카드내역 상호명과 동선이 겹치면 공짜 교차검증까지 됩니다.
"사실은 여기, 상상은 저기"로 자리를 지정하라. 본기와 논평을 물리적으로 분리하니 환각이 갈 곳이 논평 문단으로 제한됐습니다. AI의 창의성을 죽이지 않으면서 본문 신뢰도를 지키는 방법.
검증을 프롬프트가 아니라 규칙으로 심어라. 날짜·시각·기간·건수·거리·인용을 근거와 자동 대조하게 하니, "그럴듯한 거짓말"이 걸러졌습니다.
대량 작업엔 재개 설계를 먼저. 실패분만 건너뛰고 이어달리는 구조 덕에 수천 건을 안전하게 완주했습니다.
공식 경로가 막히면 대체 출구를 의심하라. Takeout 1일치 → 스마트폰 내보내기 11.5년치. 데이터의 문은 하나가 아니었습니다.
이렇게 하면 안 돼요 (실제로 겪은 함정)
AI가 뱉은 숫자를 그냥 믿기. 시각·건수·거리는 서로 다른 값을 헷갈리기 쉽습니다(분 성분 vs 체류시간, 총거리 vs 구간거리). 반드시 근거와 대조하세요.
검증기를 만들고 방심하기. 검증기도 코드라 오탐을 냅니다. Urban's Court의 아포스트로피를 인용부호로 오인해 멀쩡한 문장을 계속 막았습니다. 검증기 자신의 버그까지 잡아야 끝납니다.
마스킹을 나중에 하기. 위치·대화·문자는 태생이 민감정보라, 마스킹·추상화를 처음부터 기본값으로 두지 않으면 나중에 통째로 다시 돌려야 합니다.
열람 편의를 무시하기. 매번 서버 켜야 보는 결과물은 결국 안 보게 됩니다. "다시 여는 마찰"을 0에 가깝게 만드세요.
🌍 다른 업무에 적용한다면?
이 프로젝트의 진짜 자산은 '실록'이 아니라 "흩어진 데이터를 → 날짜 축으로 통합 + 사실·해석 분리 서술 + 자동 검증 + 마스킹으로 정리하는 파이프라인" 자체입니다. 저는 두 방향 모두로 실제 확장을 고려하고 있습니다.
① 개인 영역으로 더 넓히기 (실제 다음 계획)
사진·가계부·건강기록까지 같은 날짜 축에 합류: 위치·카톡·문자에 사진(어디서 뭘 봤나), 가계부(그날 뭘 샀나), 건강 앱(수면·걸음)을 얹으면, 하루의 복원도가 로그에서 장면으로 올라갑니다. 검증·마스킹 부품은 그대로 두고 "근거 소스"만 추가하면 됩니다.
② 업무 문서로 옮기기 (직무 이식)
법률·공공기관 문서 정리: 사건 경위서·회의록·상담일지를 ① 사실 요약(근거 인용 대조) 과 ② 의견·해석으로 분리 서술하고, 실명·연락처·기관명을 자동 마스킹하며, 날짜·금액·인용의 정확도를 근거 문서와 대조 검증. "AI가 지어낸 사실"이 치명적인 분야일수록 이 구조가 강력합니다.
고객 상담/CS 로그 아카이브: 메신저·통화·티켓을 날짜·고객 축으로 통합하고, 개인정보는 추상 요약으로만 남긴 뒤 "무슨 일이 있었나(사실) / 무엇을 개선할까(해석)"를 분리 기록.
왜 이식이 되나: 이 사례에서 실제로 작동한 네 부품 — 날짜 축 통합, 사실/해석 분리, 근거 대조 검증, 마스킹 기본화 — 은 데이터 종류(위치든 대화든 사진이든 법률 문서든)와 무관하게 재사용됩니다. 바꿔야 할 건 "근거 데이터의 필드 이름"뿐입니다. 실제로 위치→카톡→문자로 소스를 늘릴 때 이 부품들을 그대로 재사용했습니다.
솔직한 재현 난이도 & 전제조건
과장 없이 말씀드리면, 이건 "복붙 한 번으로 끝"은 아닙니다. 층을 나눠 보면:
🟢 대화형 AI(ChatGPT·Claude)만으로 오늘 당장 되는 것: 위 재사용 프롬프트 2개(사실/해석 분리 서술 + AI 자가검증). 내 데이터 한 조각을 붙여넣기만 하면 됩니다. 비개발자도 즉시 가능.
🟡 AI 코딩 도구가 필요한 것: 11.5년치 대량 파싱·날짜별 청킹·자동 검증 파이프라인은 Claude Code·Codex 같은 도구(+약간의 스크립트)가 필요합니다. 순수 비개발자라면 이 부분을 AI 코딩 도구에 통째로 맡기거나, 규모를 "최근 몇 달"로 줄여 시작하길 권합니다.
필요 준비물: 스마트폰 타임라인 내보내기, 카톡·문자 내보내기, AI 코딩 도구 접근(유료 구독 포함 가능).
안 맞는 경우(비적용): 실시간 대응이 필요한 업무, 근거 데이터가 아예 없는 순수 창작, 소스가 한 종류뿐이라 교차검증이 불가능한 경우엔 이 방식의 강점(삼각측량·검증)이 약해집니다.
조직으로 키우려면: 개인은 이대로 충분하지만, 팀·조직 규모로 올리면 데이터 접근 권한·보안 규정·마스킹 수준 합의가 기술보다 먼저 필요합니다.
🚀 앞으로의 계획
사진 EXIF 결합(여행일지): 위치 기록에 사진 촬영 시각·좌표를 얹어, 인터랙티브 지도가 있는 여행일지로 확장.
검색·질의 연동: 4,073일 기록을 자연어로 "2019년 여름에 자주 가던 곳은?"처럼 물어볼 수 있게 Wiki/검색과 연결.
마스킹 정책 고도화: 외부 공유를 전제로, 민감 주제 추상화 수준을 사용자가 선택할 수 있게.
방법 전파: 지금 이 글이 첫 공유입니다. 나아가 "나도 알려달라"던 여자친구·모임 지인에게 따라 할 수 있는 방법(이 글의 재사용 프롬프트 + 데이터 내보내기 순서)을 정리해 전수할 계획입니다.
📋 재사용 가능한 프롬프트
아래 프롬프트는 대화형 AI(Claude, ChatGPT 등)에 복붙해서 바로 쓸 수 있습니다. [대괄호] 부분만 본인 상황에 맞게 바꾸세요.
프롬프트 1: 개인/업무 데이터를 '사실 ↔ 해석' 분리해 서술시키기
아래 [데이터 종류: 예) 하루치 위치·대화 기록 / 회의록 / 상담 로그]를 읽고 하나의 기록으로 정리해줘.
규칙:
[사실 섹션 이름: 예) 본기] 에는 근거가 있는 사실만 써라. 원본에 없는 내용은 추측해서 쓰지 마라.
상상·해석·비유·평가는 오직 맨 끝 [논평 섹션 이름: 예) 총평] 문단에만 써라.
인물은 [지칭 방식: 예) 실명 대신 이니셜]로만 부르고, [마스킹 대상: 예) 전화번호·기관명·금액]은 가리거나 추상화해라.
대화 원문을 길게 직접 인용하지 말고, 요지만 요약해라.
문체는 [원하는 톤: 예) 담담한 앵커 / 냉정한 비평가] 하나로 일관되게.
프롬프트 2: AI가 만든 요약의 '사실 정확도'를 스스로 검증시키기
방금 네가 작성한 [결과물: 예) 하루 기록]을 아래 [근거 데이터]와 대조해서 사실 오류가 있는지 자가 점검해줘.
다음 항목을 각각 O/X로 판정하고, X면 근거의 실제 값을 함께 제시해라:
시각: 본문에 쓴 시간이 근거의 시각과 일치하는가 (오전/오후, 표기법 혼동 주의)
기간: '몇 시 몇 분'과 '얼마나 머물렀는지(체류 시간)'를 혼동하지 않았는가
건수: 본문의 개수가 근거 데이터의 실제 카운트와 같은가
금액/수치: [핵심 수치: 예) 지출액·거리]가 근거와 일치하는가 (합계 vs 구간 구분)
인용: 원문에 없는 말을 지어내 인용하지 않았는가
판정이 모두 O가 될 때까지 본문을 고쳐 다시 제시해라. 근거가 없으면 지어내지 말고 "확인 불가"로 표기해라.
추천 이미지:
"결과 (After)" 섹션: 완성된 원클릭 캘린더 앱의 월간 뷰(다크/라이트 모드 나란히) 스크린샷 — 4,073일이 캘린더에 채워진 전경.
"2막 — 삼각측량" 섹션: 같은 날짜에 타임라인 동선 + 카톡 + 카드결제 문자가 나란히 놓인 화면, 또는 카드 상호명↔타임라인 좌표가 일치하는 대조 장면. ※ 마스킹 필수.
"4막 — 검증" 섹션: 리라이트 로그 3293 rewritten, 3 invalid 또는 최종 summary targets=0 터미널 화면.
"3막" 섹션: 실제 생성된 '황제실록' 하루 기록 예시(본기 + 사관은 논한다 문단이 분리된 화면). ※ 게시 전 반드시 실명·지명·대화 내용 마스킹.
소개
저는 일본과 한국을 오가며 옷·스니커즈를 양방향으로 판매합니다. 상품마다 어느 방향(한국↔일본)으로 넘겨야 남는지가 달라서, 늘 양쪽 시세를 함께 봐야 해요. 이번에 자동화한 건 그중 일본에서 사서 KREAM(한국)으로 넘기는 방향입니다. 이 장사는 결국 "어느 쪽으로, 얼마에 넘기느냐"가 전부라, 매일 밤 일본 공급처 사이트를 하나씩 열어 KREAM 시세와 비교하고 있었어요. "이거 지금 넘기면 수수료 떼고 얼마 남지?"를 손으로 계산하는 거죠.
이 짓을 매일 반복하다가, Claude Code로 이 과정을 자동화하는 딜 찾기 시스템을 붙여보기로 했습니다. 목표는 단순했어요. 여러 공급처를 자동으로 훑어서 "지금 사면 KREAM에서 남는 딜"만 추려주는 것. 그런데 만들고 보니, 딜을 '찾는' 것보다 그럴듯하게 틀린 딜을 '거르는' 게 훨씬 어려웠습니다. 오늘은 그 삽질기를 공유합니다.
스택: Claude Code + Python(FastAPI) 백엔드 + React 프론트 + SQLite. 크롤링·매칭·마진계산 로직을 대화로 하나씩 붙여나갔습니다.
진행 방법
⚠️ 아래 프롬프트는 실제 세션 로그 원문이 아니라, 제가 봇에게 어떤 식으로 지시했는지 흐름을 재구성한 대표 예시입니다. 실제로는 훨씬 잘게 쪼개서 주고받았어요.
1) 공급처 크롤러 — "매장 추가를 공짜로"
먼저 편집샵을 긁어오는 크롤러부터 시켰습니다.
일본 편집샵 상품을 긁어오는 크롤러를 만들어줘.
- 몽벨/진즈팩토리는 HTML 직접 파싱
- 스니커즈 편집샵(kickslab, wormtokyo, mita)은 Shopify 기반이니 /products.json 엔드포인트로 상품을 통째로 받아와
- 공급처를 추가할 때 base_url만 넘기면 되도록 전략(Strategy) 패턴으로 구성
여기서 Shopify /products.json 트릭 덕에 매장 추가가 거의 공짜가 됐습니다. 반면 Nike·adidas 공식몰은 일부러 뺐어요. nike.com/jp는 JS로 그리는 SPA라 정적 HTML에 상품이 없고, adidas는 403으로 봇을 막고, 무엇보다 공식 정가라 KREAM 마진이 안 나옵니다. 편집샵에서 두 브랜드가 다 커버되기도 했고요.
2) 매칭 & 마진 — KREAM 시세에 붙이기
긁어온 상품을 KREAM 시세와 맞대고 마진을 계산하게 했습니다. 마진 공식의 핵심은 이렇게 잡았어요(수수료를 숨은 상수로 두지 않고 명시 필드로).
# 판매가(KREAM 실거래가) 기준 마진율
estimated_margin_krw = kream_price_krw - purchase_cost_krw \ - shipping_krw - customs_krw - commission_krw
estimated_margin_rate = round(estimated_margin_krw / kream_price_krw * 100, 2)
▲ 실제 딜 추천 화면. 활성 딜 13건, 평균 마진 18.7%. 각 카드에 공급처가(¥)·KREAM가(₩)·마진이 한눈에.
결과와 배운 점
만드는 내내 벽을 세 번 넘었습니다. 그리고 셋 다 "코드가 안 돌아서"가 아니라 "봇이 자신 있게 틀려서" 생긴 벽이었어요.
벽 ① — "0건이 원래 정상인 줄 알았다"
전체를 돌렸더니 추천이 0건. 저는 순간 "일본 정가로 사서 KREAM에 팔면 수수료 떼고 원래 안 남는 거구나" 하고 납득했습니다. 그럴듯하죠. 근데 찜찜해서 로그를 팠더니 — DB에 컬럼 하나(kream_product_name)가 없어서, 조건을 통과한 딜조차 저장에 전부 실패하고 있었어요. 컬럼을 추가하니 바로 8건이 떴습니다.
배운 점: 수상한 결과를 '그럴듯한 경제 논리'로 덮으면, 버그가 정상인 척 숨는다. 0건을 납득해버린 나 자신이 제일 위험했다.
벽 ② — 목걸이를 신발로 착각한 봇
8건 중 몇 개는 마진이 70%를 넘었습니다. "대박!" 하고 열어봤더니… 피어스·뱅글·네크리스 액세서리 3개가 전부 똑같은 버켄스탁 신발(₩239,000)에 매칭돼 있었어요. 목걸이를 신발이라 우기면서 신뢰도 0.85로 아주 당당하게요.
원인은 매칭이 헐거웠던 것. 모델 번호 앞부분 몇 글자만 겹치면 같은 상품 취급했거든요. 그래서 봇에게 '의심'을 가르쳤습니다.
매칭 false positive가 너무 많아. 두 개를 넣어줘:
1) 모델번호 접두사가 너무 짧으면(5자 미만) 매칭 거부
2) 공급처 브랜드와 KREAM 브랜드가 실제로 같은지 검증하는 게이트
그리고 크로스브랜드 거부 / 동일브랜드 유지 단위테스트도 같이.
_MIN_BASE_MODEL_LEN = 5 # 짧은 접두사 충돌 차단 def _kream_brand_matches(supplier_brand, kream_result) -> bool: # KREAM 브랜드 필드 또는 상품명에 공급처 브랜드가 포함되는지 ...
재스캔하니 목걸이-신발 같은 쓰레기는 싹 사라지고, 브랜드가 맞는 딜만 남았습니다. 저는 "가끔 놓치더라도 절대 거짓말은 안 하는" 쪽(정밀도 우선)을 택했어요.
여기서 한 발 더 나갔습니다. 매칭이 왜 맞는지를 눈으로 검증할 수 있게, 실물 품번과 KREAM 품번목록을 나란히 놓고 대조하는 화면을 만들었어요. 제1원칙은 "AI는 후보를 찾아오는 데만 쓰고, 확정 근거로는 안 쓴다" — 최종 매치는 실물 품번이 KREAM 리스팅 품번목록에 포함되는지의 기계 판정으로만 확정합니다.
▲ 스캔 9건 중 품번 확정 4건·수동 검수 5건·오매칭 0건. 초록으로 하이라이트된 품번(예: FB7818-100)이 양쪽에 똑같이 들어있을 때만 확정. 아래 빨간 띠("단순차액 −18,340원 · 역마진")처럼, 매칭이 맞아도 마진이 안 나오면 자동 딜에서 제외됩니다.
배운 점: 딜 찾기의 진짜 적은 '0건'이 아니라 '자신 있게 틀린 것'이다. 없는 건 없다고 알면 그만이지만, 가짜를 진짜라 우기면 진짜 돈을 잃는다.
벽 ③ — '정확한 매칭'이 '팔리는 딜'은 아니었다
여기서 "이제 됐다" 했는데, 그게 방심이었습니다. 남은 목록을 보니 몽벨 아웃도어 자켓이 마진 28%로 딜에 올라와 있었어요. 매칭은 정확합니다. 그런데 몽벨 자켓은 KREAM에서 거의 거래가 안 됩니다. 사겠다는 사람이 없으면 28%는 그냥 종이 위 숫자죠.
▲ 왼쪽 Asics Gel-Kayano 14(마진 29.2%, KREAM에서 잘 거래됨)와 오른쪽 몽벨 클라이마플러스 자켓(마진 28.5%, KREAM 거래 거의 없음). 봇 눈엔 둘 다 신뢰도 98%의 똑같이 좋은 딜로 보인다 — 이게 벽③이다.
코드를 다시 까보고 이유를 알았습니다. KREAM 응답엔 '총 거래량(total_sales)'이 같이 오는데, 저는 그 값을 스냅샷에 저장만 하고 딜 판정엔 한 번도 안 쓰고 있었어요. 판정 기준이 오직 '마진'과 '매칭 신뢰도'뿐이라, 반년에 한 번 팔린 물건이든 매일 팔리는 물건이든 봇 눈엔 똑같아 보였던 겁니다.
배운 점: 봇에게 "같은 물건이냐"(정확도)는 가르쳤지만, "실제로, 곧 팔리냐"(유동성)는 아직 못 가르쳤다. 데이터를 손에 쥐고도.
앞으로의 계획 & 도움이 필요한 부분
다음 할 일은 정해졌습니다. 이미 받아둔 거래량(total_sales)과 '마지막 거래가 얼마나 최근이냐'를 딜 판정에 실제로 반영하는 것. 거래가 뜸한 물건은 마진이 높아도 뒤로 밀고, 자주 팔리는 물건에 가중치를 주려고요. 마진이 진짜가 되려면 그 가격에 팔 수 있다는 증거가 먼저 붙어야 하니까요.
혹시 국경 간 중고/병행 시세에서 '유동성(회전율)'을 점수화하는 좋은 방법을 써보신 분 있으면 팁 구합니다. 지금은 단순 거래량 + 최근성 가중치를 생각 중인데, 더 나은 접근이 있을 것 같아요.
돌아보면 이 봇은 벽을 하나씩 넘어온 과정이었어요. 저장이 안 되던 벽, 아무거나 갖다 붙이던 벽, 그리고 "정확하지만 안 팔리는" 벽. 딜을 '찾는' 코드는 하루면 짜지만, 믿을 수 있게 만드는 데는 벽이 계속 나옵니다. 좋은 딜을 많이 찾아주는 봇보다 틀렸을 때 틀렸다고 말하는 봇이 훨씬 든든하다는 것, 그거 하나는 확실히 배웠습니다.
ARGUS 설치 기록 — LLM Wiki LCL
작성일: 2026-06-17
대상: domains/ai-it/ Argus Wiki Integration Phase 0 + Phase 1
관련 커밋: 9719f58b (PRD 추가) → bbb1d17b (Phase 1 scaffold 설치)
1. Argus가 무엇인가
jasonxtn/Argus는 Python 기반 정보수집·보안점검(OSINT/Recon) 툴킷이다.
DNS 조회, WHOIS, SSL 만료 알림, HTTP 헤더 분석, robots.txt, sitemap, SPF/DKIM/DMARC 검증 같은 passive 체크부터 포트스캔·디렉토리 파인더 같은 active scan까지 다수의 모듈을 제공한다.
공식 README는 교육적·윤리적 사용과 명시적 허가가 있는 대상만 스캔할 것을 고지한다.
2. 설치 전 상황 (Before)
항목
상태
AI_IT 도메인
존재하지 않음
보안 점검 결과 저장 구조
없음 — 터미널 출력으로 끝
allowlist / 실행 정책
없음 — 어떤 대상에도 실행 가능
passive / active 모듈 구분
없음
결과 민감도 정책
없음 — public 인덱스 노출 위험
Ouroboros 감사 기록
Argus 실행 이력 없음
NAS public 배포 제어
Argus 결과 포함 여부 불명확
3. 설치 과정
3-1. PRD 작성 (Phase 0 정책 확정)
커밋 9719f58b — 2026-06-17 13:49
Show Me The PRD 플러그인으로 인터뷰 기반 요구사항을 추출한 뒤 4종 문서를 작성했다.
90_project_docs/10_prd/argus-wiki-integration/
├── 01_PRD.md # 제품 요구사항 (허가 경계, 핵심 기능, 성공 기준)
├── 02_DATA_MODEL.md # 데이터 모델 (AssetAllowlist, ArgusRunPlan, OuroborosLedgerEntry)
├── 03_PHASES.md # Phase 0~4 분리 계획
├── 04_PROJECT_SPEC.md # AI 행동 규칙 (금지사항·구현 순서)
└── README.md # 문서 네비게이션
핵심 결정: Argus는 local-contract-law·case-law·general-law 검색과 무관하다.
AI_IT 도메인의 security-recon collection으로만 격리 운영한다.
3-2. Phase 1 Scaffold 설치
커밋 bbb1d17b — 2026-06-17 14:21
Codex CLI가 PRD를 읽고 Phase 1을 구현했다. 생성된 파일은 다음과 같다.
정책·스키마 파일
domains/ai-it/90_schema/
├── argus-allowlist.yml # 허가된 자산 등록부 (현재 2개: system.cmdspace.work, 127.0.0.1)
└── argus-module-policy.yml # 모듈별 위험도 및 허용 여부 정의 (12개 모듈)
allowlist 등록 자산
asset_id
target
active scan
AIT-ASSET-001
system.cmdspace.work
불가
AIT-ASSET-002
127.0.0.1
불가
모듈 정책 (passive-only profile 허용 8개)
모듈
카테고리
위험도
기본 허용
DNS Records
network-passive
low
O
Domain Info / RDAP / WHOIS
network-passive
low
O
SSL Expiry Alert
web-passive
low
O
HTTP Headers
web-passive
low
O
Robots.txt Analyzer
web-passive
low
O
Sitemap Parsing
web-passive
low
O
Security.txt Check
web-passive
low
O
SPF / DKIM / DMARC Validator
email-passive
low
O
Open Ports Scan
network-active
medium
X (명시 승인 필요)
Directory Finder
web-active
medium
X (명시 승인 필요)
WAF Bypass Test
blocked-active
high
X (기본 차단)
Subdomain Takeover
blocked-active
high
X (기본 차단)
실행 엔진
domains/ai-it/
├── argus_run_plan.sh # wrapper (venv 자동 선택)
└── 91_scripts/ └── argus_run_plan.py # run plan 생성기 (337 lines)
argus_run_plan.py가 하는 일:
target이 allowlist에 있는지 확인 → 없으면 즉시 blocked 반환
profile에 따른 허용 모듈 목록 구성
active 모듈 요청 시 차단
run plan JSON/MD 생성 → 50_reports/argus/run-plans/ 저장
--write-ledger 옵션 시 Ouroboros ledger에도 기록
Phase 1 핵심 불변식: would_run: false, argus_installed_or_executed: false
실행 계획만 만들고 Argus 바이너리는 절대 호출하지 않는다.
결정 문서 및 워크플로우
domains/ai-it/20_wiki/
├── decisions/argus-phase1-no-run-policy.md # 4대 정책(allowlist-only, passive-only, private-by-default, no-run)
└── workflows/argus-run-plan-workflow.md # 실행 흐름 설명 + 예시 명령
domains/_registry.yml 갱신
ai-it 도메인이 멀티도메인 registry에 추가됐다.
검색앱과 라우터가 이 파일을 단일 진실로 사용하므로 AI_IT 도메인 검색이 활성화된다.
3-3. 첫 run plan 실행 (dry-run)
설치 직후 검증 명령:
./domains/ai-it/argus_run_plan.sh \ --target system.cmdspace.work \ --profile passive-only \ --dry-run \ --write-ledger
결과 (ARGUS-RUN-20260617-141653):
result: pass
would_run: False
argus_installed_or_executed: False
planned modules: 8개 (전부 passive-only)
ledger: domains/ai-it/50_reports/ouroboros/ledger/ 에 기록됨
미등록 target 차단 테스트도 통과했다.
4. 설치 전·후 비교 (After)
항목
설치 전
설치 후
AI_IT 도메인
없음
domains/ai-it/ 생성, registry 등록
보안 점검 저장 구조
없음
source / wiki / report / ledger 4계층
allowlist
없음
argus-allowlist.yml — 2개 자산 등록
모듈 정책
없음
argus-module-policy.yml — 12개 모듈 분류
Argus 실행
무제한(통제 없음)
Phase 1은 실행 자체 금지, run plan만 생성
결과 민감도
미정
기본 private — public 인덱스 승격 금지
NAS 공개 배포
불명확
Argus 결과 완전 제외
감사 추적
없음
Ouroboros ledger에 실행 이력 자동 기록
active scan
통제 없음
명시 승인 없이 기본 차단
5. 무엇이 달라졌는가
거버넌스 우선 구조
Argus를 바로 설치·실행한 것이 아니라 "어디에, 어떤 조건으로, 어떤 범위만" 먼저 정의했다.
Phase 1의 핵심 가치는 Argus 실행이 아닌 실행 통제 체계 구축이다.
도메인 격리
Argus 결과는 AI_IT 도메인 private 검색에서만 조회된다.
local-contract-law, case-law, general-law, journal 도메인 인덱스에는 영향이 없다.
실행 흔적의 누적 가능성
이전에는 Argus 실행 결과가 터미널에만 남았다.
이제는 run plan과 ledger가 50_reports/ 하위에 JSON/MD로 누적된다.
6. 다음 단계 (Phase 2 시작 조건)
첫 allowlist target 사용자 확정 (system.cmdspace.work 권장)
Argus 설치 방식 결정 (isolated venv 권장 vs. container)
Phase 2 시작 승인
Phase 2가 시작되면 실제 Argus 바이너리를 isolated venv에 설치하고,
passive-only 모듈 8개를 내 소유 자산 1개에 한해 pilot 실행한다.
7. 따라서 설치하고자 하는 사람을 위한 유의사항
반드시 지킬 것
allowlist 먼저 작성 — argus-allowlist.yml에 내 소유 자산만 등록한다. 등록되지 않은 target은 실행 자체가 차단된다.
거버넌스 → 설치 순서 — 정책 파일(allowlist, module-policy) 없이 Argus를 먼저 설치하면 안 된다. 이 scaffold가 없으면 실행 통제가 불가능하다.
Phase 1에서는 Argus 바이너리를 설치하지 않는다 — would_run: false가 Phase 1의 정상 상태다. 실행 결과가 나왔다면 뭔가 잘못된 것이다.
active scan은 기본 차단 — open-ports, directory-finder, waf-bypass, subdomain-takeover 계열은 requires_explicit_approval: true다. 별도 승인 없이 profile에 포함하지 않는다.
결과 sensitivity는 기본 private — Argus 결과는 취약점 정보가 될 수 있다. public 인덱스, NAS public 검색, 외부 공유에 절대 포함하지 않는다.
API key 필요 모듈은 Phase 1 제외 — Shodan, VirusTotal, Censys 계열은 no-API-key 원칙과 충돌한다. Phase 2 이후 별도 결정이 필요하다.
다른 도메인 인덱스 건드리지 않기 — local-contract-law, case-law, general-law, journal 도메인의 FTS/MongoDB/qmd 인덱스에 Argus 결과를 절대 합류시키지 않는다.
설치 검증 체크리스트
# 1. 등록 자산 통과 확인
./domains/ai-it/argus_run_plan.sh --target <내자산> --profile passive-only --dry-run
# 기대: result=pass, would_run=False # 2. 미등록 자산 차단 확인
./domains/ai-it/argus_run_plan.sh --target example.com --profile passive-only --dry-run
# 기대: result=blocked # 3. active 모듈 요청 차단 확인
./domains/ai-it/argus_run_plan.sh --target <내자산> --profile passive-only --modules open-ports --dry-run
# 기대: result=blocked
8. 관련 파일 맵
domains/ai-it/
├── argus_run_plan.sh # 실행 진입점
├── 90_schema/
│ ├── argus-allowlist.yml # 허가된 자산 등록부
│ └── argus-module-policy.yml # 모듈 정책 (passive/active/blocked)
├── 91_scripts/
│ └── argus_run_plan.py # run plan 생성기
├── 20_wiki/
│ ├── decisions/argus-phase1-no-run-policy.md
│ └── workflows/argus-run-plan-workflow.md
└── 50_reports/ ├── argus/run-plans/ # run plan 기록 └── ouroboros/ledger/ # 감사 ledger 90_project_docs/10_prd/argus-wiki-integration/ # PRD 4종
한 줄 요약
한글 문서인 .hwp, .hwpx를 Markdown으로 변환할 때 픽셀 단위 화면 재현이 아니라 제목, 문단, 표, 이미지, 수식, 각주, 메타데이터 같은 의미 구조를 보존하는 방향으로 CLI/라이브러리 설계를 정리하고, 실제 변환 품질을 높이기 위한 회귀 테스트와 보완 작업까지 진행했습니다.
이런 분들께 도움돼요
한글 문서를 Markdown, Obsidian, Git 기반 문서로 옮기고 싶은 분
HWP/HWPX 변환을 단순 텍스트 추출이 아니라 편집 가능한 문서 구조로 다루고 싶은 분
AI와 함께 복잡한 문서 변환 도구의 설계 기준, 테스트 전략, 단계별 개발 계획을 잡고 싶은 분
"일단 변환은 되는데 표, 이미지, 수식, 각주가 망가지는" 문제를 겪어본 분
시작점: HWP를 Markdown으로 바꾸는 일은 생각보다 복잡했다
처음 목표는 단순했습니다.
.hwp 또는 .hwpx 문서를 넣으면 사람이 다시 읽고 편집하기 좋은 Markdown 문서와 첨부 자산 폴더가 나오는 도구를 만들고 싶었습니다.
하지만 실제로 들여다보니 이건 단순한 "파일 포맷 변환" 문제가 아니었습니다.
한글 문서에는 표, 병합 셀, 보도자료 상단 장식 표, 각주, 수식, 이미지, 캡션, 머리말/꼬리말, 도형 텍스트, HWP 고유 control 문자 같은 요소가 섞여 있습니다. 이것을 Markdown으로 옮길 때 화면 모양만 따라가면 결과물이 너무 지저분해지고, 반대로 텍스트만 뽑으면 문서의 의미가 많이 사라집니다.
그래서 기준을 먼저 정했습니다.
Markdown 변환의 목표는 한컴 화면을 픽셀 단위로 재현하는 것이 아니라, 사람이 다시 읽고 고칠 수 있는 의미 구조를 보존하는 것입니다.
"목표는 화면 복제가 아니라 다시 편집할 수 있는 Markdown 구조입니다."
만든 것
이 작업에서 정리한 산출물은 HWP/HWPX to Markdown 변환기 개발계획서와 초기 구현 보완 방향입니다.
대상 산출물은 다음과 같습니다.
.hwp, .hwpx 입력을 받는 CLI
Markdown .md 출력 파일
이미지와 첨부 파일을 담는 assets 폴더
변환 중 손실과 경고를 기록하는 report.json
CLI, GUI, Obsidian 플러그인 등에서 재사용할 수 있는 변환 라이브러리
예상 사용 방식은 이런 형태입니다.
hwp2md input.hwp -o output.md
hwp2md input.hwpx -o docs/output.md --assets-dir docs/output.assets
hwp2md input.hwp --format obsidian --image-mode extract --table-mode gfm
초기 버전의 목표는 완벽한 변환기가 아닙니다.
실제 문서를 Markdown 초안으로 안정적으로 바꾸고, Markdown으로 표현하기 어려운 정보는 조용히 버리지 않고 리포트에 남기는 도구입니다.
사용한 도구와 참고한 구조
이 프로젝트에서 AI에게 맡긴 핵심 역할은 "복잡한 변환 문제를 제품 설계와 테스트 가능한 작업 단위로 쪼개는 것"이었습니다. 단순히 코드를 바로 만들기보다, 어떤 정보를 보존하고 어떤 정보는 fallback으로 남길지 먼저 정리했습니다.
주요 참고 구조는 다음과 같습니다.
HOP: HWP/HWPX를 여는 데스크톱 앱 구조와 제품 계층 참고
rhwp: HWP/HWPX 파서와 문서 모델을 다루는 핵심 엔진 후보
obsidian-hwp-writer: Markdown과 HWPX 스타일이 연결되는 반대 방향 흐름 참고
Rust workspace: CLI와 core library, rhwp adapter, Markdown renderer를 분리하는 구조
회귀 테스트: 실제 변환 중 깨졌던 케이스를 다시 검증하는 안전장치
중요한 판단은 rhwp 같은 파서/엔진 계층과 Markdown 변환 계층을 분리하는 것이었습니다.
HWP/HWPX를 읽는 일과 Markdown으로 의미 있게 바꾸는 일은 서로 다른 책임입니다. 파서는 원본 구조를 최대한 정확히 읽고, 변환기는 그 구조를 사람이 편집할 수 있는 Markdown 표현으로 바꿔야 합니다.
진행 과정
1. 변환 기준을 "화면"이 아니라 "의미 구조"로 잡았다
처음부터 모든 레이아웃을 Markdown으로 재현하려고 하면 금방 막힙니다.
Markdown은 문서 편집과 공유에는 좋지만, 한글 문서의 복잡한 지면 배치와 장식 요소를 모두 담기에는 맞지 않습니다. 그래서 변환 기준을 이렇게 정했습니다.
제목은 Markdown heading으로 옮긴다.
일반 문단은 읽기 좋은 문단으로 나눈다.
단순 표는 GFM table로 옮긴다.
병합 셀이나 복잡한 표는 HTML table fallback을 쓴다.
이미지는 assets 폴더로 추출하고 Markdown 링크로 연결한다.
수식과 각주는 가능한 Markdown으로 보존하고, 어려운 것은 리포트에 남긴다.
머리말, 꼬리말, 바탕쪽은 기본 본문에 섞지 않는다.
이 기준 덕분에 "어디까지 변환할 것인가"를 매번 새로 고민하지 않고, 기능별 정책으로 나눌 수 있었습니다.
2. 중간 IR을 두는 구조로 설계했다
HWP/HWPX를 읽자마자 Markdown 문자열을 만들면 테스트와 디버깅이 어려워집니다.
그래서 중간에 Markdown Semantic IR을 두는 구조로 설계했습니다.
Document metadata blocks[] Block Heading(level, inlines, source) Paragraph(inlines) List(kind, items, nesting) Table(rows, caption, fallback) Image(asset_id, alt, caption) Equation(source, fallback_image) Footnote(id, blocks) HtmlBlock(reason, html) UnknownBlock(source_ref, diagnostic)
이 구조의 장점은 분명했습니다.
원본 파싱 결과가 이상한지, 의미 구조 변환이 이상한지, Markdown 렌더링이 이상한지를 따로 볼 수 있습니다. 나중에 GFM, CommonMark, Obsidian 친화 출력처럼 Markdown 방언을 나누기도 쉬워집니다.
3. 실제로 깨지는 변환 케이스를 하나씩 보완했다
개발계획서에는 이미 구현 보완 내역도 같이 정리되어 있습니다.
예를 들어 HWP 표는 단순히 텍스트를 줄 단위로 뽑으면 구조가 쉽게 깨집니다. 그래서 표 control과 cell record를 묶어 행, 열, 병합 정보를 복원하고, 단순 표는 GFM으로, 병합 표는 HTML fallback으로 출력하도록 방향을 잡았습니다.
보도자료 문서에서 자주 나오는 상단 장식 표도 별도 처리 대상이었습니다. 겉으로는 표지만 본문 표라기보다 배포일시, 보도일시, 담당부서, 담당자를 담은 메타데이터에 가깝습니다. 그래서 본문에서는 제거하되 frontmatter와 report.json metadata에 남기는 방식으로 정리했습니다.
실제 보완한 문제들은 꽤 구체적입니다.
HWP inline 제어문자 때문에 ('12)→)→)처럼 깨지던 연도별 수치 문자열 보정
HWP BMP 이미지를 PNG로 변환
공백과 괄호가 있는 자산 경로를 Markdown <...> destination으로 출력
재변환 시 이전 generated assets가 새 결과와 섞이지 않도록 정리
캡션 직후 그림 control을 감지해 해당 위치에 이미지 우선 배치
단순 분수 수식은 Markdown 수식 fallback으로 보존
각주 control은 placeholder로 남겨 후속 복원 대상으로 추적
HWPX inline style 태그를 bold, italic, underline, sub, sup 표현으로 보존
[1], 붙임1, 짧은 1. 제목, 가. 제목 같은 문단을 목록이 아니라 heading 후보로 승격
구조화하지 못한 HWP control id를 report.json warning/loss에 남김
여기서 좋았던 점은 "못 바꾸는 것"을 숨기지 않는 방향으로 설계했다는 점입니다.
변환기가 완벽하지 않아도, 무엇이 손실됐고 무엇이 fallback 처리됐는지 알 수 있으면 사람이 검수할 수 있습니다.
4. 변환 리포트를 기본 산출물로 넣었다
Markdown 파일만 나오면 사용자는 무엇이 누락됐는지 알기 어렵습니다.
그래서 output.report.json을 기본 산출물로 두는 설계를 넣었습니다.
{ "source": "input.hwp", "format": "hwp", "pages": 12, "blocks": 180, "assets": 8, "warnings": [ { "code": "TABLE_HTML_FALLBACK", "message": "Merged cells require HTML table fallback", "sourceRef": "section=0 paragraph=34" } ], "losses": [ { "code": "TEXT_COLOR_DROPPED", "count": 12 } ]
}
이 리포트는 단순 로그가 아니라 변환 품질을 개선하는 기준표가 됩니다.
예를 들어 수식이 fallback 처리됐는지, 병합 표가 HTML로 나갔는지, 색상 정보가 빠졌는지, 알 수 없는 control id가 있었는지를 나중에 다시 추적할 수 있습니다.
5. 회귀 테스트를 변환 품질의 중심에 뒀다
문서 변환기는 한번 고친 문제가 다시 깨지기 쉽습니다.
특히 HWP/HWPX는 실제 문서마다 구조가 다르고, 표와 이미지가 섞이면 엣지 케이스가 계속 나옵니다. 그래서 tests/test_hwp2md.py 회귀 테스트로 보완 내역을 검증하도록 정리했습니다.
검증 대상으로 잡은 항목은 다음과 같습니다.
파일명 보존
metadata 추출
heading 추론
inline 수치 복원
자산 링크
BMP 변환
수식 fallback
assets 정리
170508 샘플 변환
Before vs After
Before는 이런 상태였습니다.
HWP/HWPX를 Markdown으로 바꿀 때 무엇을 보존해야 하는지 기준이 흐릿했다.
표, 이미지, 수식, 각주 같은 요소가 케이스마다 다르게 깨질 수 있었다.
실패한 변환이 조용히 누락되면 사용자가 나중에 알아차리기 어려웠다.
기능을 어디서부터 구현해야 할지 범위가 커 보였다.
After는 이렇게 바뀌었습니다.
변환 목표를 "의미 구조 보존"으로 정의했다.
파서, 중간 IR, Markdown renderer, asset extractor, report를 분리했다.
단순 표와 복잡한 표의 출력 정책을 나눴다.
변환 손실과 경고를 report.json에 남기는 기준을 만들었다.
MVP와 v0.1.0 성공 기준을 분리했다.
실제 깨졌던 변환 케이스를 회귀 테스트로 묶었다.
단계별 개발 계획
이번 계획에서 가장 현실적이었던 부분은 "완벽한 변환기"를 바로 만들겠다고 하지 않은 점입니다.
단계는 이렇게 쪼갰습니다.
기술 검증: rhwp 소스와 라이선스 검토, 샘플 문서 파싱 확인
프로젝트 골격: Rust workspace, CLI 인자, 입력 감지, dump-ir 명령
기본 Markdown 변환: 문단, heading, 인라인 서식, 목록, frontmatter
표, 이미지, 각주: GFM table, HTML fallback, assets 추출
수식과 복잡 객체: 수식 원문, 이미지 fallback, 도형 텍스트, 머리말/꼬리말
품질 개선과 배포: OS별 빌드, 대용량 문서, batch 변환, README 작성
v0.1.0의 기준도 작게 잡았습니다.
HWP/HWPX 입력 자동 감지
텍스트, 제목, 문단, 목록 출력
단순 표를 GFM table로 출력
이미지를 assets 폴더로 추출
변환 리포트 생성
실패 시 panic 없이 진단 메시지 출력
이렇게 나누니 당장 할 일과 나중에 할 일이 분리됐습니다.
결과와 배운 점
이 작업에서 가장 크게 배운 점은, AI와 함께 개발할 때도 "무엇을 만들지"보다 "무엇을 보존할지"를 먼저 정해야 한다는 것입니다.
HWP/HWPX 변환은 표면적으로는 파일 변환이지만, 실제로는 문서의 의미를 재구성하는 작업에 가깝습니다. 제목인지 목록인지, 장식 표인지 메타데이터인지, 본문 이미지인지 캡션 뒤에 붙은 그림인지 판단해야 합니다.
또 하나의 교훈은 손실을 없애는 것만큼 손실을 기록하는 것도 중요하다는 점입니다.
Markdown으로 표현하기 어려운 요소를 억지로 예쁜 출력으로 숨기면 나중에 검수하기 어렵습니다. 반대로 report.json에 warning과 loss를 남기면, 도구가 아직 못 하는 일을 다음 개선 작업으로 연결할 수 있습니다.
현재 이 프로젝트는 "한 번에 모든 문서를 완벽하게 변환하는 도구"가 아니라, 실제 한글 문서를 Markdown 초안으로 안정적으로 옮기기 위한 구조와 검증 기반을 잡은 상태입니다.
다른 사람이 비슷하게 해보려면
바로 코드를 만들기 전에 이 순서로 접근하는 것이 좋았습니다.
변환 결과의 목적을 정한다. 화면 재현인지, 편집 가능한 Markdown인지 먼저 결정한다.
원본 문서에서 반드시 보존할 요소를 목록화한다.
Markdown으로 표현이 어려운 요소는 HTML fallback 또는 report로 남긴다.
파서와 renderer 사이에 중간 IR을 둔다.
실제로 깨진 문서를 fixture로 만들고 회귀 테스트에 넣는다.
v0.1.0 기준을 작게 잡고, 실패 시 진단 메시지를 잘 내는 쪽을 우선한다.
다음에 해볼 것
rhwp 연동 방식 확정
공개 샘플과 private fixture 분리
dump-ir 명령으로 실제 문서 구조 확인
문단, 제목, 목록부터 snapshot 테스트 구축
표와 이미지 변환 케이스 확장
Obsidian 친화 출력 옵션 정리
장기적으로 hwp2md serve, hwp2md watch, Obsidian 플러그인 검토
이 문서는 LLM Wiki에서 지식이 어떻게 동일한 지식으로 취급되고, 어떤 지식이 상대적으로 확정된 지위에 도달하는지를 설명하기 위한 문서다.
핵심 이론은 두 가지다.
1. 지식동일성설 무엇과 무엇을 같은 지식 문제로 볼 것인가? 2. 지식확정력론 같은 지식 문제 안에서 어떤 지식이 상대적으로 확정된 지위를 갖는가?
1. 전체 위치
LLM Wiki 지식체계는 크게 다음 세 층으로 구성된다.
┌──────────────────────────────┐
│ ① 지식정체론 │
├──────────────────────────────┤
│ 이것은 무엇인가? │
│ - Primary Type │
│ - Facets │
│ - Attributes │
└──────────────────────────────┘ ↓ ┌──────────────────────────────┐
│ ② 지식인정론 │
├──────────────────────────────┤
│ 믿을 수 있는가? │
│ - 지식요건해당성 │
│ - 정합성 │
│ - 검증가능성 │
└──────────────────────────────┘ ↓ ┌──────────────────────────────┐
│ ③ 지식질서론 │
├──────────────────────────────┤
│ 어떻게 다룰 것인가? │
│ - 지식동일성설 │
│ - 지식확정력론 │
│ - 지식변경론 │
│ - 지식공존론 │
│ - 지식우선순위론 │
└──────────────────────────────┘
이 문서는 세 번째 층인 지식질서론 중에서도 특히 다음 두 부분을 다룬다.
지식동일성설
→ 어떤 지식들이 서로 비교·충돌·대체 가능한가? 지식확정력론
→ 그 비교 범위 안에서 어떤 지식이 확정적 지위를 갖는가?
2. 왜 지식동일성설이 먼저 필요한가
어떤 지식이 확정적 지위를 갖는지 말하려면, 먼저 그 지식이 무엇과 경쟁하거나 무엇을 대체하는지를 정해야 한다.
예를 들어 다음 두 지식은 서로 직접 경쟁한다.
천동설
지동설
둘은 모두 천체 운동과 우주 구조를 어떤 중심 체계로 설명할 것인가라는 문제에 답한다.
따라서 둘은 동일한 지식 문제 안에서 경쟁하는 지식이다.
반면 다음 둘은 관련은 있지만 동일한 지식 문제라고 보기는 어렵다.
천동설
만유인력
만유인력은 천체 운동을 설명하는 데 중요하지만, 천동설과 지동설이 다투는 “우주 구조를 어떤 중심 체계로 설명할 것인가”라는 자리를 그대로 차지하지는 않는다.
따라서 다음 구분이 필요하다.
동일한 지식 문제
→ 충돌, 대체, 확정력 비교 가능 관련된 지식 문제
→ 보강, 설명, 약화, 연결 가능 별개의 지식 문제
→ 단순 참조 또는 배경지식으로만 연결
3. 지식동일성설의 정의
지식동일성설이란, 서로 다른 문장·주장·문서·이론이 LLM Wiki 안에서 같은 지식 문제를 다루는 것으로 보아 비교·충돌·대체·승계·확정력 판단의 대상이 될 수 있는 범위를 정하는 이론이다.
짧게 말하면 다음 질문에 답한다.
무엇과 무엇을 같은 지식으로 볼 것인가?
4. 지식동일성 판단 요소
지식동일성을 판단할 때는 다음 요소들을 본다.
knowledge_identity_factors: primary_type: question: "Fact, Theory, Evaluation, State, Norm, Plan 등 같은 유형인가?" issue: question: "같은 문제에 답하고 있는가?" conclusion: question: "같은 결론을 말하는가?" context: question: "같은 자료·사실·시대·도메인 맥락에서 말하는가?" answer_slot: question: "LLM Wiki에서 같은 canonical answer 자리를 차지하려 하는가?" explanatory_role: question: "같은 현상을 설명하거나 같은 개념적 역할을 수행하는가?" scope: question: "시간, 장소, 도메인, 적용 범위가 같은가?" practical_effect: question: "답변이나 운영상 효과가 같은가?" source_or_ground: question: "같은 출처나 근거에 의존하는가?"
모든 경우에 같은 요소를 동일한 비중으로 보지는 않는다.
지식 유형에 따라 어떤 요소를 더 중시할지가 달라진다.
5. 네 가지 지식동일성 모델
지식동일성은 하나의 기준으로만 판단하기 어렵다.
LLM Wiki에서는 지식의 종류와 문서의 목적에 따라 서로 다른 동일성 모델을 사용할 수 있다.
기본 모델은 다음 네 가지다.
1. 출처근거형 동일성
2. 결론맥락형 동일성
3. 결론중심형 동일성
4. 기능역할형 동일성
좁은 기준에서 넓은 기준으로 배열하면 다음과 같다.
좁음 넓음
│ │
▼ ▼ 출처근거형 동일성 ↓
결론맥락형 동일성 ↓
결론중심형 동일성 ↓
기능역할형 동일성
6. 출처근거형 동일성
6.1 핵심 질문
이 주장은 같은 출처와 같은 근거에서 나온 것인가?
6.2 정의
출처근거형 동일성은 같은 결론처럼 보이는 주장이라도 그 주장을 떠받치는 출처, 자료, 문헌, 관찰, 근거, 이론적 기반이 다르면 별개의 지식으로 보는 기준이다.
6.3 예시
Claim A:
세종대왕은 조선의 4대 왕이다.
근거: 원자료 A Claim B:
세종대왕은 조선의 4대 왕이다.
근거: 역사 교재 B Claim C:
세종대왕은 조선의 4대 왕이다.
근거: 강의자료 C
출처근거형 동일성에서는 A, B, C를 서로 다른 claim으로 볼 수 있다.
결론은 같지만, 각 claim이 의존하는 근거가 다르기 때문이다.
6.4 적합한 용도
source summary
논문별 정리
강의자료별 정리
원문 주석
문헌 비교
자료별 claim 추출
6.5 장점
출처 차이를 보존한다.
원자료 추적성이 높다.
문헌별 미세한 차이를 놓치지 않는다.
6.6 단점
같은 결론의 claim이 너무 많이 쪼개질 수 있다.
중복이 많아진다.
canonical answer를 만들기 어렵다.
지식확정력 형성이 느려질 수 있다.
7. 결론맥락형 동일성
7.1 핵심 질문
이 주장은 같은 결론을 말하고, 같은 자료·사실·도메인 맥락에 근거하는가?
7.2 정의
결론맥락형 동일성은 최종 결론뿐 아니라 그 결론이 의존하는 자료군, 사실관계, 시대, 도메인, 범위가 같을 때 같은 지식으로 보는 기준이다.
7.3 예시
Claim A:
세종대왕은 조선의 4대 왕이다.
맥락: 조선 왕위 계승 순서 Claim B:
세종은 태종 다음 왕위에 오른 조선의 네 번째 왕이다.
맥락: 조선 왕위 계승 순서
표현은 다르지만 결론과 맥락이 같으므로 같은 지식으로 볼 수 있다.
반면 다음 claim은 같은 인물을 다루지만 동일한 지식은 아니다.
Claim C:
세종대왕은 훌륭한 왕이다.
맥락: 훈민정음 창제, 과학기술 진흥, 통치 업적
C는 평가적 지식이고, A·B는 왕위 계승에 관한 사실 지식이다.
7.4 적합한 용도
일반 Fact claim
역사적 사실
과학적 사실
법률 명제
일반 wiki claim
7.5 장점
너무 좁지도 않고 너무 넓지도 않다.
일반 LLM Wiki의 기본값으로 적합하다.
중복 claim을 줄이면서도 맥락 차이를 보존한다.
7.6 단점
어디까지를 같은 맥락으로 볼지 판단이 필요하다.
LLM의 해석이 개입될 수 있다.
7.7 기본값 추천
일반적인 LLM Wiki claim에는 결론맥락형 동일성을 기본값으로 두는 것이 가장 좋다.
default_identity_model: conclusion_contextual
label_ko: "결론맥락형 동일성"
8. 결론중심형 동일성
8.1 핵심 질문
최종 답이 같은가?
8.2 정의
결론중심형 동일성은 출처, 근거, 설명 방식이 달라도 최종 결론이나 답변 자리가 같으면 같은 지식으로 보는 기준이다.
8.3 예시
A: raw source는 수정하지 않는다.
B: 원자료는 immutable layer로 보존한다.
C: LLM은 raw 자료를 직접 덮어쓰지 않는다.
표현은 다르지만 최종 운영 결론은 같다.
따라서 하나의 policy claim으로 묶을 수 있다.
8.4 적합한 용도
운영정책
프로젝트 규칙
canonical answer
architecture decision
반복 사용되는 실무 기준
8.5 장점
중복을 크게 줄인다.
하나의 canonical answer를 만들기 쉽다.
LLM이 일관된 답변을 하기 좋다.
8.6 단점
근거 차이를 뭉갤 수 있다.
시대, 범위, source 차이를 놓칠 수 있다.
연구용 wiki에는 지나치게 넓을 수 있다.
9. 기능역할형 동일성
9.1 핵심 질문
이 지식은 같은 설명 기능이나 개념적 역할을 수행하는가?
9.2 정의
기능역할형 동일성은 표현, 근거, 출처, 세부 결론이 조금 달라도 LLM Wiki 안에서 같은 설명 기능, 이론적 역할, 개념적 위치를 차지하면 같은 지식 범주로 보는 기준이다.
9.3 예시: 천동설
다음 표현들은 서로 다르지만 같은 기능적 지식 범주로 묶을 수 있다.
천동설
지구중심 우주론
프톨레마이오스적 천문 체계
고대·중세의 지구중심 우주 체계
이들은 모두 다음 기능을 수행한다.
천체 운동과 우주 구조를 지구 중심으로 설명하는 체계
9.4 예시: 지동설
다음 표현들도 하나의 기능적 지식 범주로 묶을 수 있다.
지동설
태양중심설
코페르니쿠스 체계
태양중심 천문 체계
이들은 모두 다음 기능을 수행한다.
천체 운동과 태양계 구조를 태양 중심으로 설명하는 체계
9.5 적합한 용도
concept page
theory page
paradigm page
학설 비교
과학사 정리
큰 개념의 통합 문서
9.6 장점
여러 표현과 근거를 종합하기 좋다.
이론, 패러다임, 학설, 개념을 다루기에 적합하다.
LLM Wiki의 concept layer에 잘 맞는다.
9.7 단점
동일성 범위가 너무 넓어질 수 있다.
서로 다른 이론을 과도하게 통합할 위험이 있다.
source별 차이가 흐려질 수 있다.
10. 네 가지 동일성 모델 비교
모델
핵심 기준
범위
장점
위험
적합한 곳
출처근거형 동일성
source, 근거
좁음
출처 보존
claim 과분화
source summary
결론맥락형 동일성
결론 + 맥락
중간
균형적
맥락 판단 필요
일반 claim
결론중심형 동일성
최종 결론
넓음
canonical화 용이
차이 뭉개짐
policy, 운영규칙
기능역할형 동일성
설명 기능·개념 역할
매우 넓음
종합·이론화에 강함
과잉통합 위험
concept, theory
11. 지식유형별 권장 동일성 모델
지식 유형
권장 모델
이유
Resource
출처근거형
파일, 출처, provenance가 중요
Fact
결론맥락형
결론과 사실 맥락이 모두 중요
Theory
기능역할형
설명 기능과 이론적 역할이 중요
Interpretation
결론맥락형 또는 기능역할형
해석 대상과 해석 기능이 중요
Evaluation
결론맥락형
평가 결론과 평가 기준이 중요
State
주체-시점형
누구의 상태인지, 언제의 상태인지가 중요
Norm
결론중심형 또는 결론맥락형
최종 규범 결론과 적용 범위가 중요
Plan
행위-목적형
actor, action, time, goal이 중요
Policy
결론중심형
최종 운영 결론의 일관성이 중요
Concept Page
기능역할형
개념적 역할과 통합 기능이 중요
Source Summary
출처근거형
원문별 차이를 보존해야 함
12. 특수 동일성 모델
위 네 가지 모델 외에 일부 지식 유형에는 별도 모델이 필요하다.
12.1 주체-시점형 동일성
State에 적합하다.
누구의 상태인가?
언제의 상태인가?
어떤 맥락에서 발생했는가?
예:
“나는 피렌체를 좋아한다.”
이 문장은 객관적 사실 claim이 아니라 사용자 상태다.
따라서 다음 기준을 본다.
state_identity: owner: user state_type: preference object: Florence recorded_at: date
12.2 행위-목적형 동일성
Plan에 적합하다.
누가?
무엇을?
언제?
무슨 목적으로?
예:
“나는 10월에 피렌체에 갈 계획이다.”
plan_identity: actor: user action: travel destination: Florence time: October goal: travel
13. 천동설, 지동설, 만유인력 사례
13.1 천동설과 지동설
천동설과 지동설은 동일한 지식 범주 안에서 경쟁한다.
knowledge_identity: identity_model: functional_role identity_class: astronomical_world_system canonical_question: "천체 운동과 우주 구조를 어떤 중심 체계로 설명할 것인가?" relation: competing_paradigms same_identity_class: true
따라서 다음 논의가 가능하다.
천동설의 지식확정력 하락
지동설의 지식확정력 상승
지동설에 의한 천동설의 대체
천동설의 역사적 이론으로의 재분류
13.2 천동설과 만유인력
천동설과 만유인력은 관련은 있지만 같은 지식 범주에 속하지 않는다.
knowledge_identity: item_1: geocentrism item_2: universal_gravitation relation: related_explanatory_framework same_identity_class: false
천동설은 우주 구조와 천체 배열을 설명하는 세계체계다.
만유인력은 물체 간 인력과 운동 원리를 설명하는 법칙이다.
따라서 만유인력은 천동설을 직접 대체한다기보다, 천동설의 설명력을 약화시키거나 지동설적 세계관을 보강하는 관련 지식으로 처리하는 것이 적절하다.
13.3 지동설과 만유인력
지동설과 만유인력도 동일한 지식은 아니다.
knowledge_identity: item_1: heliocentrism item_2: universal_gravitation relation: supporting_explanatory_relation same_identity_class: false
만유인력은 지동설이 설명하려는 천체 운동을 더 깊은 물리 법칙으로 설명하는 데 기여한다.
그러나 지동설이 차지하는 answer slot을 만유인력이 그대로 차지하는 것은 아니다.
14. 지식확정력론의 정의
지식확정력론이란, 동일한 지식 범주 안에서 특정 지식이 어느 정도 상대적으로 확정된 지위를 갖는지를 판단하는 이론이다.
짧게 말하면 다음 질문에 답한다.
이 지식은 해당 지식질서 안에서 어느 정도 확정적인가?
여기서 “확정적”이라는 말은 절대적 진리를 뜻하지 않는다.
그 시대, 그 공동체, 그 wiki, 그 지식체계 안에서 상대적으로 확정적이라는 뜻이다.
15. 지식확정력의 기능
지식확정력은 다음 기능을 한다.
기존 지식의 조용한 덮어쓰기 방지
경쟁 지식 사이의 상대적 지위 표시
새 지식이 기존 지식을 대체할 수 있는지 판단
기존 지식을 현재 사실, 역사적 이론, 폐기된 이론 등으로 재분류
지식 변경 절차를 요구
16. 지식확정력의 판단 요소
지식확정력은 단순히 검증가능성만으로 결정되지 않는다.
knowledge_finality_factors: confirmability: description: "출처와 증거에 의해 어느 정도 확인되는가?" coherence: description: "현재 지식질서와 얼마나 정합적인가?" consensus: description: "관련 공동체나 wiki 내부에서 어느 정도 합의되어 있는가?" repeated_validation: description: "반복적으로 검증되었는가?" failed_challenges: description: "반대 claim들이 충분히 검토되었고 실패했는가?" explanatory_power: description: "경쟁 지식보다 더 많은 현상을 잘 설명하는가?" centrality: description: "지식질서 안에서 중심적인 위치를 차지하는가?" scope_clarity: description: "적용 범위가 명확한가?" temporal_durability: description: "시간을 견디며 유지되었는가?" revision_history: description: "수정과 반박의 이력이 어떻게 축적되었는가?"
17. 검증가능성과 지식확정력의 차이
검증가능성과 지식확정력은 관련이 있지만 같지 않다.
확증가능성
= 왜 이 지식을 받아들일 수 있는가?
= 정당화 지식확정력
= 왜 이 지식을 쉽게 바꿀 수 없는가?
= 정착
검증가능성이 높아도 지식확정력이 낮을 수 있다.
예:
현재 특정 도시의 인구는 약 950만 명이다.
공식 통계로 확증 가능하지만, 시간이 지나면 쉽게 바뀔 수 있다.
반대로 검증가능성은 중간이지만 지식확정력이 높은 경우도 있다.
예:
세종대왕은 훌륭한 왕이다.
가치판단이 포함되어 검증가능성은 중간일 수 있지만, 장기간의 역사적 평가와 사회적 합의로 인해 지식확정력은 높을 수 있다.
18. 지식확정력 등급
LLM Wiki에서는 지식확정력을 다음 단계로 표시할 수 있다.
draft
→ 아직 지식으로 편입되지 않음 admitted
→ 지식요건·정합성·확증가능성을 통과 contested
→ 동일 범주 내 경쟁 claim 존재 settled
→ 상대적으로 확정된 지식 canonical
→ 해당 wiki에서 기본 답변 지위를 가짐 superseded
→ 후속 지식에 의해 대체됨 historical
→ 현재 사실 지위는 잃었지만 역사적 지위로 보존됨
19. 지식확정력의 범위
지식확정력은 무제한으로 확장되지 않는다.
어떤 지식이 확정적이라고 하더라도, 그 확정력은 특정 범위 안에서만 작동한다.
예를 들어 지동설의 지식확정력은 다음 범위에서 강하다.
태양계에서 지구와 행성이 태양 주위를 공전한다는 설명
현대 천문학에서 천동설이 현재 사실 명제로 받아들여지지 않는다는 설명
하지만 다음 명제까지 확장되면 안 된다.
태양이 우주의 절대 중심이다.
우주의 모든 구조가 태양을 중심으로 배열되어 있다.
중력 법칙의 모든 세부 내용을 지동설이 설명한다.
따라서 지식확정력에는 항상 scope가 필요하다.
knowledge_finality_scope: applies_to: - "태양계 행성 운동의 기본 구조" - "지구가 태양 주위를 공전한다는 설명" does_not_apply_to: - "태양이 우주의 절대 중심이라는 주장" - "은하계 전체 구조" - "중력 법칙의 상세 수식"
20. 쿤식 패러다임 전환 사례
과학사는 지식확정력론을 설명하기에 좋은 사례다.
특정 시대에는 천동설이 해당 지식질서 안에서 강한 지식확정력을 가졌다.
천동설은 당시 관측과 이론 체계 안에서 세계를 설명하는 기본 모델이었다.
그러나 시간이 지나면서 천동설이 설명하기 어려운 문제들이 쌓였고, 지동설이 대안적 설명으로 등장했다.
초기 지동설은 곧바로 확정적 지위를 얻지 못했다.
천동설
→ 기존 지식질서 안에서 강한 확정력 보유 지동설 초기
→ 기존 지식질서와 충돌
→ 그러나 점차 확증가능성 상승 경쟁 기간
→ 천동설은 자기 체계 안에서 반박과 보정을 시도
→ 지동설은 새로운 관측·계산·설명력으로 지위를 강화 전환 이후
→ 천동설의 지식확정력 하락
→ 지동설의 지식확정력 상승
→ 지동설이 새로운 canonical 지식으로 정착
→ 천동설은 historical theory로 재분류
이 과정에서 핵심은 다음이다.
지동설은 천동설과 동일한 지식 문제를 다루었기 때문에 천동설을 대체할 수 있었다.
만약 동일한 지식 문제를 다루지 않았다면, 지동설은 천동설을 직접 대체하는 것이 아니라 단순히 관련 지식으로만 남았을 것이다.
21. 지식동일성설과 지식확정력론의 관계
두 이론의 관계는 다음과 같다.
지식동일성설
→ 비교 가능한 지식들의 범위를 정한다. 지식확정력론
→ 그 범위 안에서 어떤 지식이 확정적 지위를 갖는지 정한다.
아스키로 표현하면 다음과 같다.
새 claim 등장 │ ▼
지식동일성 판단 │ ├─ 동일성 없음 │ └─ related claim으로 연결 │ └─ 동일성 있음 │ ▼ 지식확정력 비교 │ ├─ 기존 claim 확정력 우세 │ └─ 새 claim rejected / disputed / view로 보존 │ ├─ 새 claim 확정력 상승 │ └─ revision_candidate │ └─ 새 claim 확정력 우세 └─ 기존 claim superseded / historical 처리
핵심 원칙은 다음이다.
지식동일성설 없이 지식확정력론 없음.
22. LLM Wiki schema 예시: 지동설
id: theory-heliocentrism-001
primary_type: Theory identity: model: functional_role identity_class: astronomical_world_system canonical_question: "천체 운동과 우주 구조를 어떤 중심 체계로 설명할 것인가?" answer_slot: dominant_astronomical_world_system competing_items: - theory-geocentrism-001 admission: 지식요건해당성: pass 정합성: coherent_in_modern_astronomy 검증가능성: settled finality: label: 지식확정력 level: canonical scope: applies_to: - "태양계에서 지구와 행성이 태양 주위를 공전한다는 설명" excludes: - "태양이 우주의 절대 중심이라는 주장" basis: - high_confirmability - broad_consensus - repeated_validation - centrality_in_modern_astronomy order_relations: supersedes: - theory-geocentrism-001 preserves_as_historical: - theory-geocentrism-001
23. LLM Wiki schema 예시: 천동설
id: theory-geocentrism-001
primary_type: Theory identity: model: functional_role identity_class: astronomical_world_system canonical_question: "천체 운동과 우주 구조를 어떤 중심 체계로 설명할 것인가?" answer_slot: historical_astronomical_world_system admission: 지식요건해당성: pass 정합성: coherent_as_historical_theory 검증가능성: strong_as_historical_claim finality: label: 지식확정력 level: historical former_level: canonical_in_pre_modern_astronomy current_scope: applies_to: - "과학사적 이론" - "지구중심 우주론의 역사적 설명" excludes: - "현대 천문학의 현재 사실 명제" order_relations: superseded_by: - theory-heliocentrism-001
24. 지식확정력 판단 절차
1. 새 지식 또는 새 claim이 들어온다. 2. 지식정체론으로 유형을 정한다. - Fact인가? - Theory인가? - Evaluation인가? - State인가? - Norm인가? - Resource인가? 3. 지식인정론으로 기본 편입 가능성을 본다. - 지식요건해당성 - 정합성 - 검증가능성 4. 지식동일성설로 기존 지식과의 관계를 본다. - 같은 지식 문제인가? - 관련 지식인가? - 별개 지식인가? 5. 동일한 지식 문제라면 지식확정력을 비교한다. - 기존 지식이 여전히 우세한가? - 새 지식이 도전 claim인가? - 새 지식이 revision candidate인가? - 새 지식이 기존 지식을 대체할 만큼 강한가? 6. 결과를 기록한다. - admitted - contested - settled - canonical - superseded - historical - rejected
25. 결과 처리 규칙
if_same_identity_class: and_new_claim_weaker: action: - mark_as_view - keep_existing_finality and_new_claim_plausible: action: - mark_as_contested - add_to_dispute_register and_new_claim_stronger_but_not_settled: action: - mark_as_revision_candidate - lower_existing_finality_if_needed and_new_claim_canonical: action: - supersede_existing_claim - preserve_existing_as_historical_or_archived if_related_but_not_same_identity_class: action: - link_as_related - mark_relation_type - do_not_supersede_directly if_unrelated: action: - store_separately - no_finality_comparison
26. 최종 핵심 명제
이 문서의 핵심 명제는 다음과 같다.
1. 지식확정력은 단순히 개별 지식의 강도가 아니라, 동일한 지식 범주 안에서 경쟁하는 지식들 사이의 상대적 지위다. 2. 따라서 지식확정력론은 반드시 지식동일성설을 전제로 한다. 3. 지식동일성설은 무엇과 무엇을 같은 지식 문제로 볼 것인지를 정한다. 4. 지식확정력론은 같은 지식 문제 안에서 어떤 지식이 확정적 지위를 얻었는지를 정한다. 5. 새 지식은 기존 지식과 동일한 범주에 있을 때만 기존 지식을 직접 대체할 수 있다. 6. 관련성은 동일성이 아니다. 7. 동일성이 없으면 대체가 아니라 연결, 보강, 약화, 배경화로 처리한다. 8. 지식확정력은 절대적 진리가 아니라 특정 시대·도메인·wiki 질서 안에서의 상대적 확정성이다.
27. 최종 요약
LLM Wiki에서 지식은 단순히 저장되는 것이 아니라, 서로 비교되고, 충돌하고, 대체되고, 역사화된다.
이를 제대로 처리하려면 먼저 다음을 정해야 한다.
어떤 지식들이 같은 문제를 다루는가?
이것이 지식동일성설이다.
그 다음에야 다음을 판단할 수 있다.
그 문제 안에서 어떤 지식이 확정적 지위를 가지는가?
이것이 지식확정력론이다.
따라서 LLM Wiki의 지식질서론 안에서 두 이론은 다음 순서로 작동한다.
지식동일성설 ↓
지식확정력론 ↓
지식변경론 ↓
지식공존론 ↓
지식우선순위론
이 구조를 사용하면 LLM Wiki는 새로운 정보를 무조건 기존 정보에 덮어쓰지 않고,
기존 지식과 새 지식의 관계를 먼저 판단한 뒤,
대체·공존·보강·역사화·폐기 중 적절한 처리를 선택할 수 있다.
