DokuWiki를 다시 꺼낸 이유

아무리 노력해서 이미지에 한글이 깨진다. 챗GPT 내이놈.

 

 

DokuWiki를 다시 꺼낸 이유

나는 최근까지 고민하고 있었다.

Raw Data를 어디에 저장할 것인가?

• 작업 이력
• 설치 과정
• 실패 기록
• 중간 설계
• 감정 섞인 날것 메모

블로그는 정제된 결과물 공간이다.
하지만 모든 과정을 블로그에 담을 수는 없다.

그래서 필요했던 것은 “날것 저장소”였다.

---

왜 DokuWiki인가

선택 기준은 단순했다.

• 가벼울 것
• DB 의존성 최소
• 파일 기반
• 로컬에서 운영 가능
• 구조 강제하지 않을 것

DokuWiki는 DB가 필요 없다.
텍스트 파일 기반이다.
서버에 올려도 되고, 로컬에서도 돌아간다.

“기술 로그 저장소”로 쓰기에 충분했다.

---

설치 과정 요약

macOS(Homebrew) 환경에서:

brew install nginx
brew install mysql
brew install php

nginx + php-fpm + mysql 환경 구성 후
DokuWiki 압축 해제 → 웹루트 배치 → 권한 설정.

data/ 디렉토리 쓰기 권한 확인이 핵심이었다.

chown -R _www:_www data

nginx 설정 후 재시작:

brew services restart nginx

---

새 글 작성 방식

DokuWiki는 “새 글쓰기 버튼”이 따로 없다.

존재하지 않는 페이지 ID로 접근하면 자동 생성된다.

doku.php?id=obsidian:daily_template

또는 내부 링크로 생성:

[[obsidian:daily_template]]

폴더 개념은 콜론(:) 네임스페이스로 관리한다.

---

전용 태그 전략

처음에는 복잡한 태그 설계를 하려 했다.
하지만 과한 구조는 쓰기를 막는다.

그래서 최소화했다.

• 기술 태그
• 작업 유형 태그
• 대상 객체 태그

단, 민감 정보가 포함된 문서는
클라우드 LLM을 사용하지 않는다.

IP, 내부망, 암호 정보가 포함된 내용은
로컬 LLM(Ollama)을 통해 정리한다.

프롬프트 예시:

내용 변경 금지.
형식만 DokuWiki 문법에 맞게 정리.
불필요한 설명 추가 금지.

보안과 편의의 균형이다.

---

익스텐션 설치

필수로 고려한 것은 Struct 플러그인.

• Schema 정의 가능
• 필드 기반 구조화 가능
• 나중에 검색/필터 확장 가능

하지만 초반에는 과하게 사용하지 않는다.
기록이 먼저다.

---

테마를 바꾸지 않은 이유

스킨은 기본 테마 유지.

이유는 단순하다.

• 예쁘게 꾸미기 시작하면 방향이 바뀐다
• 위키는 전시 공간이 아니다
• 속도가 중요하다

기본 테마는 기능에 집중하게 만든다.

---

역할 분리 구조

• 위키 → 내가 뭘 했는가 (Raw Data 저장소)
• 블로그 → 토론 후 정리된 결과물
• Obsidian → 나는 어떻게 움직이는가
• 일정 프로그램 → 실행 관리

도구는 겹치지 않게 역할을 나눈다.

---

결론

이건 지식 관리 도구 선택의 문제가 아니다.

Raw Data를 버리지 않기 위한 시스템이다.

정리된 글은 블로그에 올라간다.
하지만 과정은 위키에 남는다.

날것을 저장할 수 있는 공간이 생기면
사고는 더 자유로워진다.

정리를 버리는 것도 정리다.