[인사이트] 퍼스널 온톨로지 기반 '스스로 발전하는' 포트폴리오를 만들어봤습니다.

요즘 "AI로 뭐 만들어봤습니다" 글이 많은데, 저는 좀 다른 각도로 하나 얹어보려고요. 단순 홍보보다, 몇 달 굴리면서 얻은 인사이트 위주로 풀어볼게요. 키워드는 퍼스널 온톨로지랑 자기발전 루프 두 개입니다.

시작은 유지보수의 피로감이었어요. 커리어가 한 발짝 나아갈 때마다 포트폴리오에 반영해줘야 하고, 특히 제 포지션이나 역할이 바뀌면 아예 처음부터 다시 만드는 일도 잦았습니다. 매번 손으로 다시 짜는 게 지겨워서, 온톨로지 하나만 잘 업데이트해두면 나머지는 알아서 굴러가는 포트폴리오가 필요했어요. 나를 단일 소스로 한 번 정리해두고 거기서 사이트가 파생되게 하자는 거였죠.

그런데 "나를 정리한다"를 도구로 옮기려니 벽이 있더라고요. Notion 같은 표 기반은 데이터 모델은 있는데 관계 그래프가 약하고, Obsidian 같은 자유 노트는 그래프는 좋은데 명시적인 모델이 없어요. 6개월쯤 지나면 어떤 노트가 "회사"고 어떤 게 "프로젝트"인지 분류 규칙이 흐려지고, 노트 사이에 빠진 링크가 늘어납니다. 두 도구 사이 빈자리가 보였어요.

그래서 팔란티어 Foundry의 Object Backend 데이터 모델을 딱 한 명한테, 그러니까 저 자신한테 옮겨봤습니다. 저는 팔란티어 주주라 분석가들이 Foundry 위에서 일하는 방식을 오래 구경했거든요. Obsidian은 그대로 쓰되 그 위에 Foundry의 데이터 모델을 한 층 얹은 겁니다. 구체적으로는 저를 여덟 개 메타타입(사람·조직·프로젝트·사건·개념 같은 타입 정의와 그 인스턴스)으로 쪼갰어요. 타입 정의는 _ontology 폴더에 사람이 읽을 수 있는 마크다운으로 두고, 실제 데이터는 frontmatter가 구조화 필드를 담고 본문이 자유 서술을 담습니다. 관계는 wikilink로 잇고요. 사람 노트가 회사 노트를 가리키면 그걸 "근무한 적 있다" 관계로 추론합니다. Foundry는 관계 타입을 일일이 정의하지만, 1인 vault에선 가리키는 객체 타입에서 관계를 추론해 갈음했어요. 지금 사람 76명, 개념 68개, 전체 노트 1,700개 규모로 쌓여 있습니다.

요즘 RAG 한다고 문서를 통째로 벡터DB에 밀어넣잖아요. 근데 문서 덩어리를 던지는 거랑 타입과 관계로 구조화된 온톨로지를 주는 건 챗봇 품질이 꽤 달라집니다. 제 사이트의 Ask Hansol이라는 챗봇은 방문자가 저한테 물어보면 이 온톨로지에서 관련 객체랑 그 관계를 타고 답을 만들어요. "토스에서 뭐 했냐"고 물으면 사람과 조직 링크를 타고 연결된 프로젝트까지 끌어옵니다. 문서 유사도만으로 긁는 것보다 맥락이 정확해요. 그리고 구조가 명시돼 있으니 없는 걸 없다고 말하기가 쉬워집니다. 제일 크게 느낀 게 이거였어요. 챗봇이 모르는 걸 아는 척하는 순간 신뢰가 훅 가는데, 온톨로지에 해당 객체가 없으면 지어내지 말고 없다고 답하게 막기가 훨씬 수월했습니다.

'스스로 발전하는'이라고 붙인 건 사이트가 이 온톨로지를 소재로 자기를 다시 만들기 때문이에요. vault가 바뀌면 Claude가 사이트 콘텐츠를 다시 생성하고 배포까지 갑니다. 재밌는 건 배포할 때마다 뭘 왜 고쳤는지가 기록으로 쌓인다는 거예요(빌드로그에서 회차별로 보입니다). 데이터 모델이랑 데이터가 git 한 commit에 같이 묶이니까 "이 시점의 나"가 통째로 보존되고요. 방문 목적에 따라 다르게 뜨는 소개 페이지들(채용담당자 대상, 협업대상자 대상)도 사실 같은 온톨로지를 다른 뷰로 시각화한 결과입니다. 전체 구조가 궁금하시면 저장소랑 콘텐츠랑 배포 관계를 Mermaid 구조도 한 장으로 그려뒀으니 구경해보세요.

만족감이 가장 높은 부분은 vault를 채우고 사이트까지 흘려보내는 방식이에요. 요즘은 이 온톨로지를 손으로 편집하기보다 Claude 코워크에서 대화하면서 채웁니다. 커리어에 뭐가 생기거나 프로젝트 하나가 끝나면 대화로 풀어놓기만 해도 Claude가 관련 객체랑 관계랑 그날의 기록을 vault에 정리해 넣어요. 지금 이 글을 다듬는 작업도 그중 하나고요.

여기서부터가 레이어로 갈립니다. vault는 원천이고, 사이트가 실제로 읽는 건 그걸 정규화한 site-data라는 계약 하나예요. zod 스키마로 검증되는 단일 진실 소스인데, 여기에 소개 문구랑 블록 구성이 다 들어갑니다. vault가 바뀌면 파이프라인에서 Claude(Opus)가 vault를 컨텍스트로 읽어 이 site-data를 다시 써요. 이때 문구만 갈아끼우면 될 것 같지만 실제로는 컴포지션이라는 게 돌아갑니다. 페이지마다 디자인시스템 컴포넌트를 트리로 조합하고, 그 안에 들어갈 문구를 vault 근거로 직접 채우는 방식이에요. 덕분에 내용이 바뀌면 레이아웃도 같이 다시 조립됩니다. 컴포지션이 붙은 페이지는 그 트리로 렌더하고 없는 페이지는 예전 블록 레이아웃으로 폴백해서, 한 페이지가 깨져도 사이트 전체가 안 무너지게 해뒀어요. 이렇게 나온 site-data는 코드 안에 스냅샷으로도 굳혀두고 실제 서빙은 Blob의 최신본부터 로컬 스냅샷, 번들 스냅샷 순서로 폴백하며 읽습니다. 그리고 이 site-data가 갱신되면 그대로 빌드랑 배포까지 이어지고요.

그러니까 저는 코워크에서 대화만 하고, 온톨로지 업데이트랑 site-data 재생성이랑 레이아웃 재조립이랑 배포는 뒤에서 알아서 굴러가는 구조예요. 처음에 원했던 "온톨로지만 잘 업데이트하면 나머지는 알아서"가 지금은 실제로 그렇게 돌아가고 있어요.

물론 회사용 시스템을 혼자 옮기니 다 가져올 순 없었어요. 대충 옮긴 게 절반, 1인 환경에 맞게 적응시킨 게 3할, 버린 게 2할 정도예요. Foundry의 자동화랑 검증이랑 마이그레이션 도구는 통째로 버렸습니다. 혼자 그걸 다 운영하면 부담이 폭발하거든요. 대신 본질인 여덟 메타타입 구조만 챙기고, 자동 추적이 할 일은 손으로 적는 기록이랑 git history로 갈음했어요. 한계도 분명합니다. 모델을 저 혼자 정의하고 저 혼자 따르니 제 편향이 그대로 들어가고, 타입을 바꾸면 기존 노트를 손으로 다 고쳐야 하고, 활동 자동 수집은 아직 손도 못 댔어요. 다음 목표는 Medium이나 LinkedIn 활동을 크롤링해서 기록이 자동으로 들어오게 만드는 겁니다.

효과는 반반이에요. 데이터만 갈아끼우면 사이트가 알아서 갱신되니 유지보수는 확 줄었고, 챗봇도 실제로 경력 질문에 답합니다. 다만 검색 노출은 아직 고전 중이에요. "임한솔"로 치면 동명이인 정치인이랑 변호사가 1페이지를 다 먹고 있어서, 색인은 됐는데 순위는 한참 밑입니다. 데이터 모델은 공들여 짜뒀는데 그 다음 도메인 권위 싸움은 여전히 사람 몫이구나 싶은 게 지금 결론이에요.

hsol.info 한번 구경해보시고 Ask Hansol한테 아무거나 한번 물어보세요~!

여러분들이 보시기에는 자기 자신을 이렇게 온톨로지로 모델링하는 거 오버엔지니어링일까요, 아니면 1인 지식관리의 새로운 방향성일까요? 비슷하게 퍼스널 지식그래프 굴려보신 분들이 있다면 경험도 듣고 싶습니다.