라떼군 이야기


Typdit

운영 중 생산성https://typdit.com

외부 에디터 라이브러리 없이 자체 코어로 만든 웹 리치텍스트 에디터. 마크다운 단축 입력, 슬래시 커맨드, 노션, 워드 붙여넣기 정리, 자동 저장, 문서 템플릿을 갖췄고, 같은 편집기를 스크립트 한 줄로 다른 사이트에 심을 수 있습니다.

Typdit 바로가기

포지셔닝

Typdit (“I typed it”) 은 브라우저에서 바로 여는 리치텍스트 에디터 입니다. 글을 쓰는 사람에게는 준비 없이 열리는 편집 화면이고, 사이트를 만드는 사람에게는 스크립트 한 줄로 자기 페이지에 심는 편집기입니다.

전제는 하나입니다. 에디터 코어를 외부 라이브러리에 맡기지 않고 직접 만든다. 편집기가 제품의 심장인데 그 심장이 남의 것이면 성능도, 한국어 입력 품질도, 확장 방향도 통제할 수 없기 때문입니다. ProseMirror, Tiptap, Lexical, Slate, Quill 을 쓰지 않고 문서 모델부터 렌더링, 입력 처리까지 직접 구현했습니다.

초기에는 타이핑 과정을 기록하고 재생하는 서비스였고, 2026-08 에 순수 에디터 서비스로 전면 재정의 했습니다. 기록, 리플레이 축은 접고 편집 경험과 임베드 배포에 집중합니다.

시장과 문제 정의

문서 편집기 시장은 양 끝으로 갈라져 있습니다. 한쪽에는 Notion, Google Docs 처럼 완결된 서비스가 있고, 다른 쪽에는 개발자가 직접 조립해야 하는 에디터 라이브러리가 있습니다. 그 사이에서 “지금 바로 쓸 화면” 과 “내 사이트에 붙일 편집기” 를 함께 원하는 수요는 매번 한쪽을 포기합니다. 서비스를 쓰면 내 페이지에 못 넣고, 라이브러리를 고르면 붙이는 데만 며칠이 듭니다.

두 번째 문제는 한국어와 일본어입니다. 대부분의 웹 에디터는 IME 조합 입력을 사후 보정으로 다루기 때문에, 빠르게 치면 글자가 겹치거나 되돌아가는 현상이 남습니다. 조합 중 상태를 코어 레벨에서 다루지 않으면 표면에서 아무리 감싸도 근본적으로 사라지지 않습니다.

핵심 타깃과 페르소나

  • 매일 문서를 쓰는 실무자, 회의록, 주간보고, 기획서를 반복해서 쓰고 도구를 여는 마찰이 낮기를 바라는 사용자
  • 자기 서비스에 편집기가 필요한 1인 개발자, 소규모 팀, 라이브러리를 조립하고 유지보수할 여력 없이 글 작성 기능만 얹고 싶은 개발자
  • CJK 로 길게 쓰는 사용자, 조합 입력이 흔들리는 편집기에서 문장을 다시 쓴 경험이 있는 한국어, 일본어 사용자

가치 제안과 차별점

  • 자체 코어, 문자열 저장은 piece tree(불변 원본 버퍼 + append 버퍼의 균형 트리), 히스토리는 위치가 아니라 안정 ID 정체성 기준. 삭제를 되돌리면 원래 런 세그먼트가 복원되고, 삽입을 다시 하면 같은 블록 id 를 재사용해 되돌리기가 문서 구조와 어긋나지 않습니다
  • 쓰기 시작까지의 마찰 0, 랜딩에서 바로 데모 편집기가 열리고, 로그인은 저장 시점에만 요구합니다. 무료로 문서 20개까지 계정에 자동 저장됩니다
  • 한 줄 임베드, 스크립트 태그 하나(/embed/v1.js)로 어느 페이지에나 같은 편집기가 붙습니다. 키 없이도 동작하되 워터마크가 붙고, 구독하면 도메인, 만료가 고정된 라이선스 키로 워터마크가 사라집니다
  • 붙여넣기 정리, 노션, 워드에서 가져온 서식을 문서 스키마로 정규화해 안 보이는 태그가 따라오지 않습니다
  • 마크다운 단축 입력과 슬래시 커맨드, 손을 키보드에서 떼지 않고 제목, 목록, 인용, 코드블록, 이미지, 영상까지 넣습니다
  • 바로 쓰는 뼈대, 회의록, 주간보고 등 문서 템플릿과 그 문서 유형을 잘 쓰는 법을 다루는 가이드가 편집 화면과 직접 연결됩니다

핵심 사용자 흐름

  • 진입: 랜딩에서 데모 편집기에 바로 타이핑, 가입 안내는 저장하려는 순간에만 나타남
  • 작성: 마크다운 단축, 슬래시 커맨드, 툴바 중 편한 것으로 서식 지정 (색, 형광, 글꼴, 정렬 포함)
  • 저장: 자동 저장, 무료는 문서 20개, 문서당 5만 자, 구독하면 무제한, 50만 자
  • 첨부: 이미지, 영상, 일반 파일 업로드와 YouTube, Vimeo 임베드 (구독 기능)
  • 배포: 임베드 지면에서 라이선스 키를 발급하고 스크립트 한 줄을 자기 사이트에 붙임
  • 구독: 가격 지면에서 계정 허브를 거쳐 결제, 결제 완료 후 원래 보던 화면으로 복귀

구독 → 임베드 키 → 고객 사이트 검증 흐름

flowchart LR
    Write["에디터에서 작성"] --> Save["자동 저장"]
    Save --> DB[("Firestore
문서 · 임베드 키")] Sub["Plus 구독"] --> Key["임베드 키 발급
도메인 · 만료 고정"] Key --> DB Site["고객 사이트
script 한 줄"] --> Load["로드 시 키 조회"] DB --> Load Load --> Ok["유효 → 워터마크 없음"] Load --> Wm["무키 · 만료 → 워터마크"]

키 검증은 별도 인증 서버 없이 공개 읽기 규칙으로 처리하고, 만료 시각은 발급 시점의 구독 종료일로 고정합니다. 구독이 연장돼도 이미 발급된 키의 만료는 바뀌지 않으므로, 검증 경로가 항상 문서 하나만 읽는 단순한 형태로 유지됩니다.

비즈니스 모델 가설

수익화는 구독 단일 레일 입니다. 건당 차감이나 크래딧 소비를 쓰지 않고 요금 구조를 하나로 유지합니다.

  1. 무료, 문서 20개, 문서당 5만 자. 편집 기능 자체는 막지 않고 보관량으로만 구분합니다
  2. Plus (월 $5, 년 $50), 문서 무제한, 50만 자, 파일 첨부, 임베드 라이선스, 우선 지원. 연간은 2개월분이 무료인 구조입니다
  3. 임베드가 성장 루프, 키 없이 쓰면 워터마크가 붙은 채로 남의 사이트에서 계속 노출되고, 그 워터마크가 구독으로 되돌아오는 유입입니다
  4. 다음 가설, 팀 단위 라이선스와 임베드 사용량 기반 상위 티어

결제는 패밀리 공용 계정 허브를 경유해 외부 결제 제공자의 구독 상품으로 처리하고, 웹훅이 서비스별 사용자 문서의 플랜 필드를 갱신합니다. 결제 인프라를 새로 만들지 않고 이미 있는 것을 재사용했습니다.

시스템 아키텍처 (기획 결정을 시스템으로)

기획 결정 두 가지가 구조를 결정했습니다.

1. “에디터 코어는 우리 것이어야 한다” → 저장소를 코어, 뷰, 확장, React 바인딩 패키지로 나누고, 코어는 DOM 에 의존하지 않게 만들어 Node 에서 단위 테스트가 가능하도록 했습니다. 서비스 지면은 이 패키지들을 벤더링해서 쓰고, 원본과 벤더 사본이 어긋나면 CI 가 잡습니다.

2. “같은 편집기가 남의 사이트에서도 돌아야 한다” → 웹 빌드 이후 별도 번들 단계를 두어 편집기를 의존성 없는 단일 스크립트로 묶습니다. 임베드는 이 파일 하나만 요구하고, 라이선스 확인도 공개 읽기 한 번으로 끝납니다.

문서 저장은 서비스 전용 Firestore 데이터베이스, 첨부 파일은 사용자별 경로의 오브젝트 스토리지를 씁니다. 별도 백엔드 API 서버는 없고, 과금과 플랜 갱신 같은 서버 권위 작업만 공용 함수 계층이 담당합니다.

기술 결정과 트레이드오프

  • 에디터 코어 자체 구현, 초기 개발 비용을 크게 치르는 대신 입력 처리, 히스토리, 확장 지점을 전부 통제합니다. 라이브러리를 썼다면 IME 대응과 붙여넣기 정규화가 상류 이슈 대기열에 묶였을 것입니다
  • piece tree 버퍼, 원본 버퍼를 불변으로 두고 추가 텍스트만 append 버퍼에 쌓아, 긴 문서에서도 편집 비용이 문서 길이에 비례하지 않습니다
  • Astro + React 아일랜드, 랜딩, 템플릿, 문서, 가이드는 정적으로 미리 굽고 편집기만 클라이언트 컴포넌트로 띄웁니다. 콘텐츠 지면이 검색에 그대로 노출되면서 편집 화면은 앱처럼 동작합니다
  • 다크, 라이트 분리, 사이트는 라이트 기조, 편집기만 양쪽 테마를 지원합니다. 글을 쓰는 표면과 읽는 표면의 요구가 다르기 때문입니다
  • 포기한 것, 실시간 협업(로드맵), 표, 찾기바꾸기(구현 예정), 외부 에디터 라이브러리 도입(원칙적으로 배제)

운영 자동화

  • 데이터 파일이 곧 지면, 템플릿, 가이드, 사용 안내는 각각 데이터 파일 하나가 정본이고 항목을 추가하면 목록, 상세, 구조화 데이터, 편집기 연결이 자동으로 생깁니다
  • 5개 로케일 강제, 한국어, 영어, 일본어, 중국어 간체, 번체를 항목 단위로 함께 채웁니다. 누락은 해당 언어 지면의 빈 칸으로 바로 드러납니다
  • 임베드 번들 빌드, 웹 빌드 뒤 단일 스크립트로 묶는 단계가 배포 파이프라인에 포함됩니다
  • 벤더 드리프트 검사, 코어 패키지와 서비스 안 사본이 어긋난 채로 배포되지 않도록 CI 가 대조합니다
  • 구독 반영, 결제 웹훅이 사용자 플랜을 갱신하고 계정 허브에서 구독 기간을 확인할 수 있습니다

현재 상태와 운영 신호

  • 상태: 운영 중. 편집기, 템플릿, 사용 안내, 가이드, 임베드, 가격 지면이 5개 로케일로 라이브
  • 시작: 2026-02 첫 출시, 2026-08 에디터 서비스로 재정의
  • 인프라: Firebase App Hosting(typdit.com) + 서비스 전용 Firestore 데이터베이스 + 오브젝트 스토리지
  • 검증 신호: 무료 문서 20개 한도 도달률, 임베드 키 발급 수, 템플릿, 가이드 검색 유입에서 편집기 진입으로 이어지는 비율

회고와 다음 가설

  • 잘 작동한 것: 되돌리기를 위치가 아니라 ID 정체성 기준으로 설계한 것. 문서 구조가 바뀐 뒤에도 되돌리기가 어긋나지 않아 편집 신뢰도가 올라갔습니다
  • 다시 한다면: 서비스 성격을 바꿀 때 지면 정리와 신규 지면 발행을 같은 순서로 묶었을 것입니다. 컷오버 직후 남은 구 지면이 검색 결과와 내부 링크에서 잠시 어긋났습니다
  • 다음 가설: (1) IME 조합 입력 품질을 회귀 픽스처로 고정, (2) 찾기/바꾸기, 표, (3) 실시간 협업, (4) 팀 라이선스

비슷한 결의 작업 의뢰

Typdit 을 단독으로 기획, 구현, 운영하면서 만들어낸 핵심 역량은 다른 도메인에도 적용 가능합니다.

  • 텍스트 편집기, 문서 모델 설계, contentEditable 위에서 입력, 선택, 히스토리를 직접 다뤄야 하는 모든 작업
  • 한국어, CJK 입력 품질, IME 조합 입력이 깨지는 웹 UI 를 코어 레벨에서 고치는 작업
  • 임베드 SDK 와 라이선스 게이트, 남의 사이트에서 도는 스크립트 배포, 도메인, 만료 검증, 워터마크 전환 설계
  • 구독 결제 연동, 외부 결제 제공자와 자체 서비스 플랜을 웹훅으로 잇는 최소 구조
  • 정적 콘텐츠 + 앱 지면 혼합 설계, 검색 유입 지면과 로그인 앱 지면을 한 사이트 안에서 함께 굴리는 구조

기획부터 시스템 구축, 운영 자동화까지 한 사람이 끝까지 들고 가는 형태의 작업을 선호합니다. 의뢰는 /work-with-me 또는 /contact 로 연락주세요.

제품 기획, 개발 파트너 찾으시나요? 개인, 팀, 기업 모두 환영. 문제 정의부터 출시까지 함께합니다.