하이독스의 흐름

이 문서는 하이독스가 어떤 생각의 흐름으로 자라났는지를 정리한 문서이다.

별이아빠가 하이독스를 만들면서 무엇을 원했고, 어떤 문제를 먼저 느꼈고, 그 문제를 해결하기 위해 어떤 구조를 붙였으며, 그 구조가 다시 다음 기능으로 어떻게 이어졌는지를 설명한다.

하이독스의 흐름은 다음 순서로 볼 수 있다.

자료 보관
  -> 책과 문장
  -> 원본 보존
  -> 수정 이력
  -> 표 편집기
  -> import/export
  -> 계정과 권한
  -> 도움말과 릴리즈 노트
  -> 게시판과 사용자 접점
  -> 운영 가능한 포털

처음부터 모든 기능을 계획한 것이 아니라, 실제 작업을 하면서 불편한 지점이 드러났고, 그 불편을 해결하는 과정에서 다음 구조가 생겼다.

하이독스의 출발점은 자료를 한곳에 모으는 것이었다.

하지만 별이아빠의 생각은 단순 저장소에서 멈추지 않았다. 자료는 보관만 하면 죽은 자료가 된다. 자료를 다시 읽고, 나누고, 비교하고, 수정하고, 기록하고, 필요한 형태로 다시 꺼낼 수 있어야 한다.

그래서 하이독스의 방향은 다음처럼 바뀌었다.

파일을 올린다
  -> 파일을 읽는다
  -> 내용을 나눈다
  -> 변경한다.
  -> 이력을 남긴다
  -> 문서나 화면으로 다시 출력한다

이 시점에서 하이독스는 개인 클라우드가 아니라, 작업 흐름을 이어주는 포털이 되기 시작했다.

하이독스의 중심은 단테 신곡 자료를 다루면서 책의 구조와 문장 쪽으로 이동했다.

긴 텍스트를 통째로 읽는 방식보다, 문장을 여러 단위로 나누고, 원문과 번역과 사용자 입력값을 비교하는 방식이 중요해졌다.

이 흐름에서 도서관은 단순한 책 목록이 아니라 다음 기능을 가진 작업 공간이 된다.

• 책을 관리한다.
• 문장을 관리한다.
• 원문과 번역을 비교한다.
• 사용자 입력값을 받는다.
• 운영자가 선택한 값을 실제 표시값으로 삼는다.
• 이후 표 편집기와 연결된다.

즉 도서관은 읽기 화면이 아니라, 문장을 재활용하기위해 재구성하는 공간이다.

단테 신곡 같은 원문 자료를 다루면서 가장 중요한 문제가 드러났다.

원본을 직접 고치면 안 된다.

원본은 보존되어야 하고, 사용자가 입력하거나 수정한 값은 원본 위에 덧붙는 작업값이어야 한다. 따라서 하이독스의 구조는 자연스럽게 revision 중심으로 움직였다.

원본 문장
  -> 사용자 입력값
  -> 수정 이력
  -> 운영자 검수
  -> 선택된 표시값

이 구조의 핵심은 다음과 같다.

• 원본은 읽기 기준으로 보존한다.
• 사용자의 수정은 별도 revision으로 남긴다.
• 운영자는 여러 revision 중 사용할 값을 선택한다.
• 나중에 어떤 값이 왜 선택되었는지 추적할 수 있어야 한다.

이 단계에서 하이독스는 단순 입력기가 아니라, 원본과 수정값의 관계를 관리하는 시스템이 되었다.

실제 나의 업무가 곧 표 편집기 작업으로 이어졌다. 나에게는 항상 반복 입력하고 반복확인하는 업무 루틴이 있다. 이걸 일정한 시스템으로 관리해서 반복작업을 줄여야하는 필요성이 대두되었다.

이 시스템이 곧 표 편집기의 뼈대를 이룬다. 그런데 표 편집기가 바로 나의 다른 프로젝트인 단테 신곡 정리 작업과 연결되기 시작했다.

단테 원문, 발음, 번역, 검수값, 주석 같은 항목을 다루다 보면 결국 행과 열로 이루어진 작업 화면이 필요하다.

처음에는 브라우저에서 표를 보여주는 정도였지만, 점차 다음 기능이 필요해졌다.

• workbook
• sheet
• cell
• cell history
• import, export

하이독스의 표 편집기는 자료를 직접 확인하고, 수정하고, 이력을 남기기 위한 작업 공간이다.

따라서 표 편집기의 의미는 다음과 같다.

반복 입력을 편하게 한다
  -> 수정 근거를 남긴다
  -> 도서관 자료와 연결한다
  -> 나중에 다시 출력할 수 있게 한다

표와 도서관이 연결되면서 import/export 문제가 커졌다.

CSV, ODS, XLS, XLSX 같은 파일은 단순히 올리는 것이 아니라, 서버에서 안전하게 읽고, 기존 데이터와 비교하고, 필요한 값만 반영해야 한다.

이때 별이아빠의 생각은 다음 방향으로 이동했다.

• 기존 데이터와 새 데이터를 구분해야 한다.
• 최초 입력과 갱신 입력을 다르게 처리해야 한다.
• 강제 import가 필요한 경우도 있다.
• import 결과를 나중에 확인할 수 있어야 한다.
• 서버 부하를 고려해야 한다.

이 단계에서 하이독스는 단순 업로드 기능을 넘어서, 파일을 작업 흐름 안으로 끌어들이는 구조를 가지게 되었다.

웹 서비스가 되면 보안 문제가 따라온다.

하이독스는 처음에는 별이아빠 개인 작업 도구에 가까웠지만, 사이트로 배포되고 사용자 계정이 생기면서 다음 문제가 생겼다.

• 로그인한 사용자를 어떻게 구분할 것인가.
• 인증을 어떻게 할 것인가.
• 관리자는 어디에서 접근 가능해야 하는가.
• 탭별 로그인은 유지할 것인가.
• 세션 충돌은 어떻게 처리할 것인가.

이 흐름에서 하이독스는 기능보다 안전을 먼저 고려하는 방향으로 움직였다.

특히 관리자 접근 제한, 세션 정책은 하이독스가 실제 운영 가능한 사이트로 가기 위한 방어선이다.

기능이 많아질수록 문서가 필요해졌다.

별이아빠의 생각은 여기서 다시 한 번 정리된다.

기능만 있으면 부족하다. 사용자가 보는 도움말, 관리자가 보는 운영 문서, 앞으로 할 일을 적는 TODO, 이미 반영된 것을 적는 릴리즈 노트가 분리되어야 한다.

그래서 문서 흐름은 다음처럼 정리된다.

TODO
  -> 구현
  -> 릴리즈 노트
  -> 도움말

여기서 중요한 구분은 다음과 같다.

• 도움말은 실제 사용할 수 있는 기능만 설명한다.
• 릴리즈 노트는 이미 반영된 변화를 사용자에게 알려주는 문서이다.
• TODO는 아직 남은 작업과 판단 보류 사항을 담는다.

이 단계에서 하이독스는 단순 코드 프로젝트가 아니라, 문서화된 운영 프로젝트가 된다.

하이독스의 문서 흐름은 Org 문서를 HTML로 출판하는 방식과 연결된다.

Org는 별이아빠에게 작업 기록, 도움말, TODO, 릴리즈 노트, 개발 문서를 한 방식으로 다룰 수 있게 해준다. 하지만 HTML로 출판할 때는 별도의 문제가 생겼다.

• 표가 화면 폭보다 넓을 때 어떻게 처리할 것인가.
• ~코드~ 와 =강조= 를 HTML에서 어떻게 구분할 것인가.
• src block의 빈 마커를 어떻게 제거할 것인가.

이 흐름은 하이독스가 문서를 단순히 작성하는 수준을 넘어서, 문서를 사이트의 일부로 출판하는 단계에 들어갔다는 뜻이다.

게시판은 하이독스가 사용자와 만나는 입구이다.

공지사항은 운영자가 사용자에게 알려야 할 내용을 제공한다. 자유게시판은 사용자가 글과 미디어를 올리는 공간이다.

게시판이 들어오면서 다음 문제가 생겼다.

• 누가 공지사항을 작성할 수 있는가.
• 누가 공지사항을 고정할 수 있는가.
• 누가 게시글을 삭제 처리할 것인가.
• 조회수는 언제 증가시킬 것인가.
• 반복 조회와 봇 조회는 제외할 것인가.
• 댓글과 대댓글은 어떻게 보여줄 것인가.
• 게시판 운영 화면은 누가 관리할 것인가.

게시판은 단순 소통 기능이 아니라, 하이독스와 사용자가 만나서 대화를 나누는 장소이다.

현재 하이독스는 다음 흐름이 함께 존재한다.

하이독스의 흐름을 보면 별이아빠의 생각 패턴이 분명하게 드러난다.

하이독스는 단순히 파일을 보관하거나 화면을 만드는 프로젝트가 아니다. 자료를 오래 살리고, 수정 과정을 추적하고, 문서를 하나의 흐름으로 묶는 지식 운영 플랫폼을 목표로 한다.

하이독스의 독창성은 결과만 중요한게 아니고, 과정 또한 소중하다는 철학이 반영된다는 것이다. 하이독스는 먼저 자료의 성격을 읽고, 원본이 훼손될 위험을 줄인 뒤, 수정 이력을 만들고, 그 위에 권한과 보안과 도움말을 세운다.

자료의 성격을 이해한다
  -> 원본을 보존한다
  -> 수정 이력을 남긴다
  -> 선택 구조를 만든다
  -> 권한과 보안을 설계한다
  -> 도움말과 운영 기준을 함께 세운다
  -> 사용자 접점을 서비스로 연결한다

많은 도구는 결과 화면을 먼저 보여준다. 하이독스는 결과가 만들어지는 과정까지 남긴다. 누가 어떤 값을 입력했는지, 어떤 revision이 선택되었는지, 그 선택이 어떤 문서와 운영 기준 위에서 이루어졌는지를 추적할 수 있게 한다.

이 구조 때문에 하이독스는 임시 작업 도구가 아니라 축적형 서비스에 가깝다. 책의 문장, 표 편집기의 셀, 게시글과 도움말, 운영 기준이 서로 따로 놀지 않고 하나의 작업 흐름 안에서 연결된다.

하이독스가 특별한 이유는 여기에 있다. 개인의 실제 작업에서 출발해서, 작업을 오래 유지하고 생각의 흐름을 설명할 수 있는 구조를 설계한 후에, 다른 사람들이 자신들의 작업을 유지할 수 있는 서비스 구조로 끌어올리고 있다. 원본을 잃지 않고, 이력을 숨기지 않고, 생각의 흐름을 문서로 남기는 것. 그것이 하이독스가 다른 프로젝트와 구분되는 가장 큰 차별점이다.

현재 하이독스에서 중요한 판단은 기능을 더 많이 붙이는 것이 아니라, 다음 기준을 흔들리지 않게 잡는 것이다.

• 도움말은 사용자들이 기능을 쉽게 사용할수 있게 도와주는 선생님이다.
• 원본 데이터는 직접 훼손하지 않는다.
• 수정값은 revision으로 남긴다.
• 표 편집기는 이해하기 쉬운 동작과 이력 중심으로 유지한다.
• 게시판은 사용자 접점이므로 운영 정책을 먼저 정한다.

하이독스의 핵심 흐름은 다음 한 문장으로 정리할 수 있다.

자료를 훼손하지 않고, 반복되는 입력을 기억하고, 실제 사이트로 운영할 수 있게 만드는 지식 운영 플랫폼.

하이독스는 책의 문장과 업무 기록을 계속 이어서 다루기 위해 만든 작업 흐름의 집합이다.

따라서 앞으로의 개발도 항상 다음 질문을 기준으로 삼아야 한다.

이 기능은 자료 흐름을 이어주는가?
원본과 수정 이력을 지키는가?
반복 작업을 편하게 하는가?
운영자가 설명하고 관리할 수 있는가?
사용자에게 보여도 되는 상태인가?

이 질문에 답할 수 있으면 하이독스의 방향은 유지된다.