naite는 daehyeon-wiki를 운영하며 쌓인 규칙을 저장소 하나에 가둬 두지 않고, 다른 저장소에도 설치해 쓸 수 있도록 떼어낸 지식 운영 시스템입니다. 개인 위키, 공개 스타터 하네스, 데스크톱 앱, MCP 실험을 하나로 묶어, 사적인 기억을 안전하게 다루는 AI 협업 흐름을 만들고 있습니다.
왜 위키에서 떼어냈는가
처음 제가 손댄 것은 개인 위키 안의 명령과 규칙을 정리하는 일이었습니다. 그런데 정리를 거듭할수록, 이 구조가 제 vault 하나에만 묶여 있으면 금방 쓸모가 좁아진다고 판단했습니다. 지식을 모으고, 분류하고, 공개 가능한 형태로 추리고, 품질을 점검하는 흐름은 제 저장소만의 문제가 아니었습니다. 그래서 위키 내부 규칙을 다른 사람도 설치해 볼 수 있는 하네스로 떼어내기로 결정했습니다.
이 결정의 핵심은 "제가 쓰는 규칙"과 "남이 설치하는 구조"를 갈라놓는 일이었습니다. 개인 위키는 제 맥락에 맞춰 얼마든지 빠르게 바꿀 수 있지만, 공개 스타터는 설치와 시작, 업그레이드, 검증 흐름이 누구에게나 분명해야 합니다. 저는 이 둘을 섞지 않기로 선을 긋고 나서야 naite를 독립 프로젝트로 다룰 수 있었습니다.
만든 구성
naite는 앱 하나를 가리키는 이름이 아닙니다. 공개 스타터 하네스는 명령과 스키마, 품질 점검, 업그레이드 흐름을 제공하고, 데스크톱 앱은 대화와 작업 상태를 더 편하게 다루는 인터페이스로 발전했습니다. 여기에 외부 도구와 데이터를 잇는 MCP 통로, 릴리스 흐름, 작업 상태를 실시간으로 다루는 에이전트 실험을 붙였습니다.
2026년 6월에는 에이전트가 읽고 따라야 하는 지시 문서를 정리하고, 하네스와 앱의 버전 감각을 맞추는 작업을 했습니다. 이때 저는 코드보다 문서와 운영 규칙이 더 큰 버그를 만든다는 것을 크게 느꼈습니다. 시작 명령, 업그레이드 흐름, 품질 검사, 공개 문서가 서로 조금씩 어긋나 있으면, 정작 실행은 멀쩡해 보여도 사용자는 길을 잃습니다. 그래서 이 네 가지를 한 방향으로 맞추는 데 시간을 많이 썼습니다.
제가 지키려 한 경계
naite에서 제가 가장 중요하게 본 것은 편리함이 아니라 경계입니다. 개인 지식은 공개 자료와 다르고, 에이전트가 읽어도 되는 정보와 밖으로 나가도 되는 정보는 같지 않습니다. 그래서 저는 원자료 기억을 그대로 노출하는 제품이 아니라, 분류와 검토, 요약, 공개 승인이라는 단계를 거치는 시스템을 만들려 했습니다. 지금 이 포트폴리오의 프로젝트 서술을 고칠 때도 같은 원칙을 그대로 적용합니다.
자동화가 늘어날수록 이 경계는 더 중요해집니다. 어떤 파일을 읽는지, 무엇을 산출하는지, 어떤 검사를 통과해야 하는지가 흐릿하면 편리함이 오히려 오염을 부릅니다. 저는 naite를 명령만 많은 도구가 아니라, 명령과 품질 검사를 함께 쥔 프로젝트로 두려고 합니다.
지금의 의미
naite는 아직 계속 바뀌는 프로젝트입니다. 그래도 제게는 단순한 도구 모음이 아니라, AI를 개인 작업 환경에 들일 때 필요한 운영 철학을 실험하는 자리입니다. 좋은 에이전트 흐름은 명령이 많아서 좋은 것이 아니라, 무엇을 읽고 무엇을 만들며 무엇을 공개하지 않을지가 분명할 때 생깁니다. naite는 그 기준을 코드와 문서, 앱으로 동시에 세워 보는 프로젝트입니다.
