AI 시대의 에디터 저장 구조에 대한 고민

시작하며

최근 업무 중 에디터 도입을 위한 사전 조사를 맡게 되었습니다. 여러 라이브러리를 비교하고 분석하던 중, 에디터 개발의 핵심이라 할 수 있는 데이터 저장 방식에 대해 깊은 고민에 빠지게 되었습니다.

처음에는 정형화된 데이터 구조를 사용하는 방안을 제안해볼까 생각했습니다. 하지만 개발 리소스와 유지보수 효율성을 함께 고려해보니, 과연 이것이 최선의 선택인지 확신이 서지 않았습니다. 막상 의사 결정을 내려야 하는 시점이 다가올수록 의구심은 점점 커져만 갔습니다.

확신을 얻기 위해 퇴근 후에도 관련 자료를 더 찾아보며 고민을 이어갔습니다. 이 글은 그 과정에서 정리한 에디터 저장 구조에 대한 개인적인 생각 변화를 기록한 글입니다.

내가 생각하는 에디터

에디터는 개발자로서 한 번쯤은 직접 만들어보고 싶은 아이템 중 하나라고 생각합니다.
상용 에디터를 선택하든, 자체 에디터를 개발하든 작은 기능부터 시작해 점차 확장 가능한 프로젝트로 발전시킬 수 있기 때문입니다.

기능적으로도 에디터는 비교적 명확하게 역할을 나눌 수 있습니다.

• 글 작성 및 편집 기능
• 데이터 저장 구조
• 뷰어 및 렌더링 로직

이런 구조 덕분에 업무 분담이 비교적 쉽고, 스타일 처리나 편집 기능처럼 난이도가 있는 영역도 포함되어 있어 신입부터 시니어까지 한 팀으로 함께 작업하기에도 좋은 문제라고 느껴왔습니다.

다만, 이런 선택과 확장이 가능해지기 위한 전제 조건은 결국 저장 구조의 설계라고 생각해왔습니다.
그래서 에디터를 만든다면 기능 구현보다도 저장 구조 설계 단계부터 참여해보고 싶다는 생각을 자주 했습니다.

에디터 저장 구조에 대한 기존 생각

오랫동안 저는 에디터의 저장 구조는 정형화된 구조가 정답이다라고 생각했습니다.

HTML을 통째로 저장하거나, 상용 에디터의 블랙박스 형태의 데이터를 그대로 사용하는 방식은 위험해 보였습니다.

• HTML 표준이나 브라우저 렌더링 방식이 바뀌면 대응하기 어렵습니다.
• 사용하던 라이브러리가 유지보수를 중단하면(Deprecated) 대안이 없습니다.
• 다른 에디터로 마이그레이션할 때 데이터 변환 비용이 매우 큽니다.

실제로 많은 HTML 저장 기반 에디터에서 발생하는 태그 중첩 이슈나, Facebook의 Draft.js가 Lexical로 전환되며 겪은 마이그레이션 사례들은 이런 생각을 더욱 확고하게 만들었습니다.

그래서 Notion이나 Confluence처럼 독자적인 블록(Block) 구조를 정의해 저장하는 방식이 정답이라고 생각했습니다.

// 과거에 제가 정답이라고 믿었던 구조
{
  "type": "paragraph",
  "content": [
    { "type": "text", "text": "안녕하세요", "bold": true }
  ]
}

AI 등장 이후의 생각 변화

하지만 최근 들어 이 생각이 조금씩 바뀌기 시작했습니다.

AI 활용이 급격히 늘어나면서 개발 환경 자체가 크게 변하고 있다는 느낌을 받았기 때문입니다. 모바일 디바이스가 등장했을 때와 비슷하거나, 어쩌면 그보다 더 큰 변화가 오고 있는 것처럼 느껴졌습니다.

프롬프트 주도 개발, AI 기반 테스트 등 AI를 중심으로 한 새로운 개발 방식들이 빠르게 등장하고 있습니다.

이 과정에서 제가 사용해왔던 Notion과 Confluence에서는 AI 기능이 어떤 방식으로 활용되고 있는지도 함께 살펴보게 되었습니다.

그러던 중 Notion의 프론트엔드 리드인 Ryan Nystrom의 인터뷰 영상을 보게 되었습니다.

그는 인터뷰에서 다음과 같은 인상적인 표현을 사용했습니다.

우리는 AI를 위해 시스템을 다시 멍청하게(stupid) 만들었습니다.

가장 정교한 블록 구조를 자랑하던 Notion조차도, AI가 데이터를 더 쉽게 이해하고 가공할 수 있도록 Markdown 형식을 적극적으로 활용하기 시작했다는 이야기였습니다.

이 이야기를 통해 Markdown이 가진 장점이 AI 시대에는 다시 평가될 수 있겠다는 생각이 들었습니다.

• 텍스트 비중이 높아 불필요한 파싱이 줄어듭니다.
• 결과적으로 토큰 사용량도 자연스럽게 감소합니다.
• AI가 이해하고 활용하기 쉬운 구조를 유지할 수 있습니다.

Markdown은 충분히 AI 친화적인 저장 구조가 될 수 있다고 느꼈습니다.

현재의 결론: Markdown + Custom Directives

지금 시점에서, 만약 제가 에디터의 저장 구조를 초기 설계부터 담당하게 된다면 예전처럼 무조건 정형화된 구조만을 고집하지는 않을 것 같습니다.

Markdown 형식 역시 충분히 현실적인 선택지라고 생각합니다.

물론 순수 Markdown만으로는 한계가 분명합니다. 스타일 표현이나 특정 기능을 담기에는 표현력이 부족합니다.

이를 보완하는 방법으로는 크게 두 가지가 있다고 봅니다.

1. MDX처럼 JSX 문법을 직접 사용하는 방식 (이 블로그의 포스트와 튜터리얼 모두 이 방식을 사용하고 있습니다)
2. 명시적인 확장 문법(Custom Directives)을 사용하는 방식

개인적으로는 MDX보다는 다음과 같은 명시적인 블록 문법이 더 나은 선택지라고 생각합니다.

::: map-viewer
lat: 37.5
lng: 127.0
:::

이런 방식은

• 사람이 읽고 이해하기 쉽고
• JSX처럼 서로 다른 문법이 혼재되지 않으며
• AI가 문서를 해석·요약·변환하기에도 유리하고
• UI 변경에 유연하게 대응할 수 있는

장점이 있다고 생각합니다.

결론

세상이 정말 빠르게 변하고 있다는 생각이 듭니다. 예전에는 얼마나 견고하게 구조를 설계할 것인가가 가장 중요한 고민이었다면, 이제는 여기에 더해

얼마나 AI가 이해하기 쉬운 형태로 데이터를 제공할 수 있는가

까지 함께 고민해야 하는 시대가 된 것 같습니다.

앞으로 미래가 어떻게 흘러갈지 알 수 없지만, Markdown 기반으로 저장 구조를 설계하는 에디터와 이를 선택하는 기업은 점점 더 늘어나지 않을까 조심스럽게 생각해봅니다.

참고 자료

• NOTION's AI Secret: Stop Overcomplicating! They Use DUMB Markdown (And the Models LOVE It)
• AI-Driven Collaboration with Notion's Ryan Nystrom