Opkle(옵클) - 창작자를 위한 앱과 시스템

EDITOR

CLASS

BLOG

표현한다는 것의무한한 가능성,

새로운 형태로
담아내다.

새로운 형태의 콘텐츠

Opkle은 코드 없이 웹을 마음껏 만들고, 누구나 자기 화면을 그릴 수 있도록 에디터를 만들고, 그 결과물을 어디서나 즐길 수 있게 돕는 팀입니다.

텍스트와 화면과의 조화를 통해, 웹을 짓는다는 것이 그저 단순한 코딩이 아닌, 상상을 펼치고 감각을 깨우는 과정이 될 수 있도록 좋은 도구를 만들어 냅니다.

옵클 에디터 개발기: 첫 번째 구현은 코드 편집기였습니다

dev

옵클 에디터 개발기: 미리보기는 곧 또 하나의 편집기였습니다

dev

옵클 에디터 개발기: 미디어쿼리까지 편집하는 EPUB 에디터

dev

옵클 에디터 개발기: CSS 애니메이션으로 영상을 흡수하는 방식

dev

옵클 에디터 개발기: 책을 만들기 위한 LLM을 설계하다

dev

...

6 옵클 에디터 개발기: 책을 만들기 위한 LLM을 설계하다

미디어쿼리, 이미지 variant, CSS animation, 이미지 시퀀스 영상까지 들어오고 나니 옵클 에디터는 단순한 EPUB 제작 도구를 넘어 멀티미디어 출판 환경에 가까워지고 있었습니다. 문단과 이미지, 표, 애니메이션, 영상까지 하나의 EPUB 안에서 다룰 수 있게 되면, 창작자는 더 많은 결정을 내려야 합니다. 어떤 문체를 유지할지, 장면의 흐름을 어떻게 연결할지, 이미지와 문장이 어느 정도의 밀도로 만나야 할지, 전체 책의 톤이 끝까지 흔들리지 않는지 계속 판단해야 합니다.

이 지점에서 저는 AI helper가 반드시 필요하다고 봤습니다. 다만 일반 챗봇을 에디터 옆에 붙이는 식으로는 충분하지 않았습니다. 책을 만드는 LLM이라면 선택된 문단 하나만 보고 답하면 안 됩니다. 장 전체, 이전 장의 리듬, 뒤에서 회수될 설정, 장르별 문체, 작가가 금지한 표현, 독자층, 전체 시놉시스까지 함께 이해해야 합니다. 그래서 AI 기능은 단순 API 호출이 아니라, 에디터의 document state를 LLM inference payload로 변환하는 별도의 시스템이어야 했습니다.

기준은 처음부터 분명했습니다. 10만 토큰 이상의 장문 컨텍스트를 안정적으로 다룰 수 있어야 했고, 한국어 장문 원고의 흐름을 잃지 않아야 했습니다. 시스템 프롬프트에는 장르, 문체, 주제, 세계관, 금지 조건, 출력 형식, 편집 기준을 넣어 모델의 작동 범위를 고정해야 했습니다. 여기에 파인튜닝 데이터와 평가 데이터까지 필요했습니다. 옵클 에디터에 들어갈 LLM은 문장 생성기가 아니라, 책의 구조와 문체와 세계관을 유지하는 장문 편집 엔진이어야 했습니다.

100K context

책은 짧은 입력과 짧은 출력으로 다루기 어렵습니다. 한 장의 문체는 앞 장의 리듬과 이어지고, 후반부의 문장은 초반부의 설정을 다시 받아야 합니다. 정보성 글이라면 앞에서 정한 용어와 기준이 뒤에서도 유지되어야 하고, 소설이라면 인물의 말투와 관계, 세계관의 규칙이 계속 살아 있어야 합니다. 그래서 모델 조건에서 가장 먼저 본 것은 context window였습니다.

10만 토큰 이상의 컨텍스트를 기준으로 잡은 이유도 여기에 있습니다. 원고 일부만 보고 답하는 모델은 빠르게 문장을 만들 수는 있지만, 책 전체를 책임지기 어렵습니다. 앞에서 어떤 표현을 피했는지, 어떤 개념을 이미 설명했는지, 어떤 인물이 어떤 방식으로 말해 왔는지 기억하지 못하면 결과가 흔들립니다. 에디터 안에서는 선택 block, 주변 block, 장 전체, 장별 요약, 전체 시놉시스, 스타일 가이드, 시스템 프롬프트가 한 번에 들어갈 수 있어야 했습니다.

여기서 중요한 것은 단순히 긴 문자열을 모델에 밀어 넣는 것이 아니었습니다. context packing이 필요했습니다. 선택된 block은 가장 높은 priority로 들어가고, 주변 block은 local context로 들어갑니다. 장 요약과 전체 시놉시스는 compressed context로 들어가며, 시스템 프롬프트와 style guide는 instruction zone에 고정됩니다. 필요하면 최근 편집 히스토리나 사용자의 이전 선택도 추가됩니다. 긴 컨텍스트를 쓸 수 있어도 어떤 순서와 밀도로 넣을지 설계하지 않으면 모델의 attention은 쉽게 흐려집니다.

그래서 AI 호출은 prompt string 하나가 아니라 structured payload가 되었습니다. `system`, `style`, `book_summary`, `chapter_context`, `selected_block`, `neighbor_blocks`, `task`, `output_schema`처럼 역할이 나뉜 데이터가 들어가고, inference layer는 이를 모델이 가장 안정적으로 이해하는 순서로 조립합니다. 이 구조가 있어야 100K context가 단순 용량이 아니라 편집 정확도로 이어집니다.

System prompt architecture

LLM을 책 제작에 쓰려면 시스템 프롬프트가 매우 중요합니다. 일반적인 “자연스럽게 고쳐줘” 정도로는 부족합니다. 장르가 무엇인지, 문체가 어떤지, 독자에게 어느 정도의 설명을 허용하는지, 문장이 건조해야 하는지 서정적이어야 하는지, 어떤 표현은 절대 쓰지 말아야 하는지까지 모델에게 계속 주입되어야 합니다.

저는 시스템 프롬프트를 하나의 긴 지시문으로만 보지 않았습니다. 역할별로 분리된 prompt layer로 봤습니다. base system은 모델의 기본 역할을 정하고, genre system은 장르 규칙을 정합니다. style system은 문장 길이, 어휘 밀도, 리듬, 존댓말/반말, 서술 거리 같은 문체 조건을 정합니다. world system은 세계관, 인물 관계, 설정, 금지된 전개를 붙들고, task system은 지금 요청이 교정인지 번역인지 구조 제안인지 문체 변환인지 지정합니다.

이렇게 나누면 프롬프트를 더 안정적으로 조립할 수 있습니다. 사용자가 소설을 편집할 때와 기술 문서를 편집할 때 같은 base prompt를 쓰되, genre/style/world layer를 바꿀 수 있습니다. 에세이에서는 글쓴이의 거리와 목소리를 유지하고, 정보글에서는 근거와 용어 일관성을 우선하며, 소설에서는 인물 말투와 장면 continuity를 우선합니다.

시스템 프롬프트는 모델을 묶어 두는 족쇄가 아니라, inference boundary를 정하는 장치였습니다. 모델이 임의로 장르를 바꾸거나, 갑자기 광고문처럼 말하거나, 세계관 밖의 설정을 만들어 내지 않게 하는 기준입니다. 에디터 안에서 AI를 호출할 때마다 이 prompt layer가 들어가기 때문에, 사용자는 단순한 챗봇이 아니라 자기 책의 규칙을 이해하는 편집 엔진을 쓰게 됩니다.

SFT dataset

책 제작에 맞춘 모델을 만들려면 instruction data도 달라야 했습니다. 일반적인 질의응답 데이터나 짧은 글쓰기 데이터만으로는 부족합니다. 좋은 책이 왜 좋은지, 어떤 문체가 장르와 맞는지, 어떤 구조가 독자를 끝까지 데리고 가는지, 어떤 문장이 과하고 어떤 생략이 효과적인지 모델이 학습해야 했습니다.

그래서 잘 쓰인 책들을 리스트업하고, 그 책들이 좋은 평가를 받는 이유를 분석했습니다. 단순히 문장을 수집하는 것이 아니라, 장 구성, 도입 방식, 문장 리듬, 장면 전환, 인물의 말투, 주제의 반복과 변주, 설명 밀도, 독자 경험을 분리해서 보았습니다. 좋은 책은 우연히 좋은 문장 몇 개로 만들어지는 것이 아니라, 구조와 문체와 독자 경험이 일관되게 맞아 들어간 결과입니다.

이 분석은 SFT 데이터로 바꿀 수 있어야 했습니다. 하나의 sample은 `instruction`, `input`, `context`, `reference_output`, `critique`, `revision_reason`, `style_tags` 같은 구조를 가질 수 있습니다. 예를 들어 특정 문단을 주고 “이 장르의 문체를 유지하면서 더 자연스럽게 고치라”는 instruction을 만들고, output에는 수정문뿐 아니라 왜 그렇게 고쳤는지의 편집 근거를 포함시킬 수 있습니다.

질이 가장 중요하지만, 양도 중요했습니다. 한국어 장문 글쓰기 데이터가 좁으면 모델은 쉽게 특정 문체로 기울거나, 모든 글을 비슷한 블로그 문장으로 평평하게 만듭니다. 그래서 장르, 독자층, 문체 강도, 서술 거리, 정보 밀도, 대화문 비율이 다른 sample을 충분히 쌓아야 했습니다. 이 데이터가 있어야 “책을 만들기 위한 LLM”이라는 방향이 실제 훈련 데이터로 내려옵니다.

JSON schema

파인튜닝 데이터에서 중요한 것은 사람이 읽기에 좋은 설명만이 아니었습니다. 모델과 파이프라인이 반복해서 같은 기준을 사용할 수 있는 구조가 필요했습니다. 그래서 분석 결과를 자유로운 메모로 두지 않고, 일관된 JSON schema로 정리했습니다. 책마다 평가 기준이 다르게 적히면 SFT 데이터로 변환할 때도 흔들리고, 나중에 evaluation set을 만들 때도 비교가 어려워집니다.

JSON에는 작품 메타데이터와 분석 필드를 분리했습니다. `genre`, `target_reader`, `tone`, `narrative_distance`, `sentence_rhythm`, `vocabulary_density`, `structure_pattern`, `scene_transition`, `character_voice`, `world_rules`, `editorial_strength`, `avoid_patterns` 같은 필드를 둘 수 있습니다. 문체 분석과 구조 분석, 독자 경험 분석, 편집 판단 근거를 분리해야 모델이 어떤 기준을 학습하는지 추적할 수 있습니다.

이 schema는 학습용이면서 동시에 inference용이었습니다. 특정 장르의 style profile을 시스템 프롬프트에 넣을 수 있고, 사용자가 어떤 책의 톤을 기준으로 삼고 싶을 때 해당 JSON을 context asset으로 넣을 수 있습니다. 같은 JSON에서 fine-tuning sample도 만들고, evaluation prompt도 만들고, 에디터 안의 실시간 AI helper payload도 만들 수 있습니다.

이렇게 데이터 구조를 통일하면 모델 개발이 훨씬 단단해집니다. 데이터셋의 품질을 검사할 수 있고, field별 누락을 찾을 수 있으며, 특정 장르나 문체에 데이터가 치우쳤는지도 확인할 수 있습니다. 좋은 글의 감각을 사람이 읽는 평론으로만 남기는 것이 아니라, 모델이 읽을 수 있는 structured signal로 바꾸는 작업이었습니다.

Korean long-form model

책을 위한 LLM에서 한국어 장문 이해는 별도의 기준이었습니다. 짧은 문장 생성은 많은 모델이 그럴듯하게 합니다. 하지만 긴 원고를 넣고, 앞뒤 맥락을 유지하며, 장르와 문체를 흔들지 않고, 독자의 이해 흐름까지 고려하는 일은 완전히 다른 계층입니다. 한국어는 문장 끝의 뉘앙스, 존댓말과 반말, 서술 거리, 감정의 절제, 호흡의 길이가 결과 품질을 크게 바꿉니다.

그래서 모델 선택에서도 long-context와 Korean understanding을 우선했습니다. 긴 입력을 받아도 앞부분의 설정을 잃지 않아야 하고, 문장 표면만 고치는 것이 아니라 문단의 역할을 이해해야 했습니다. 소설에서는 인물의 말투와 장면의 온도를 유지해야 하고, 정보글에서는 용어와 근거의 흐름을 유지해야 하며, 에세이에서는 글쓴이의 거리와 목소리를 지켜야 합니다.

기본 모델 위에는 SFT 데이터와 style instruction이 올라가야 했습니다. base model이 장문 한국어를 안정적으로 처리하고, fine-tuning 또는 adapter layer가 책 제작 task에 맞게 조정됩니다. 여기에 system prompt와 context packing을 얹으면, 모델은 단순히 문장을 생성하는 것이 아니라 책 전체의 구조 안에서 선택 block을 다룹니다.

이 구조에서는 evaluation도 중요했습니다. 단순히 출력이 자연스러운지 보는 것만으로는 부족합니다. 장르 유지, 문체 유지, 세계관 유지, 앞뒤 문맥 반영, 금지 표현 회피, 과장 생성 억제, 한국어 호흡 보존 같은 항목으로 eval set을 구성해야 합니다. 모델 개발은 fine-tuning에서 끝나지 않고, 실제 책 편집 task에서 안정적으로 작동하는지 반복 평가되어야 했습니다.

Context builder

AI helper가 제대로 작동하려면 에디터의 문서 상태와 연결되어야 합니다. 사용자가 어느 문단을 선택했는지, 그 문단이 어느 장에 속하는지, 주변 block에는 무엇이 있는지, 현재 책의 장르와 문체 기준은 무엇인지 알아야 합니다. 그래서 AI 요청은 단순한 prompt string이 아니라 context package로 구성했습니다.

context builder는 에디터의 document state에서 필요한 정보를 뽑습니다. 선택 block의 원문, block id, chapter id, 주변 block, 장 제목, 장 요약, 전체 책 요약, style profile, system prompt layer, task instruction, output schema를 하나로 묶습니다. 멀티미디어 EPUB에서는 이미지나 표, 애니메이션 block의 설명도 들어갈 수 있습니다. 텍스트만이 문맥이 아니기 때문입니다.

응답도 구조화했습니다. 바로 본문에 덮어쓰는 방식보다, 변경 제안과 적용 단계를 나누는 것이 안정적입니다. 모델 응답은 `revised_text`, `reason`, `style_preservation`, `risk_flags`, `apply_range` 같은 구조로 받을 수 있습니다. 사용자가 적용하면 해당 block state와 CM6 문자열, IndexedDB 저장 상태가 함께 갱신됩니다. AI 편집도 기존 document state와 serialization 흐름 안으로 들어와야 합니다.

이 구조가 잡히면 AI는 외부 도구가 아니라 에디터 내부 기능이 됩니다. 문장을 교정하고, 번역하고, 장면을 제안하고, 문체를 맞추고, 장별 요약을 만들고, 전체 일관성을 점검하는 모든 작업이 같은 문서 모델 위에서 움직입니다. LLM은 별도의 채팅창이 아니라, 선택된 책 상태를 이해하는 inference layer가 됩니다.

Inference pipeline

최종적으로 필요한 것은 모델, 데이터, 프롬프트, 에디터 상태를 하나로 연결하는 inference pipeline이었습니다. 사용자가 AI 기능을 누르면 에디터는 선택 상태를 읽고, context builder가 payload를 만들고, system prompt layer가 붙고, 모델은 schema에 맞는 응답을 반환합니다. 그 응답은 바로 DOM에 덮이는 것이 아니라 적용 가능한 patch가 됩니다.

이 patch는 다시 옵클 에디터의 기존 구조로 들어갑니다. 선택 block이 수정되면 document state가 갱신되고, XHTML 문자열과 CM6 상태가 바뀌며, IndexedDB에 저장됩니다. 필요하면 preview DOM도 다시 렌더링됩니다. AI가 만든 결과도 사람이 직접 편집한 결과와 같은 저장/검수 흐름을 통과해야 합니다. 그래야 AI 기능이 에디터 안에서 별도 예외가 되지 않습니다.

결과적으로 구조는 명확하게 완성되었습니다. 긴 한국어 컨텍스트를 이해하는 모델, 장르와 문체와 세계관을 유지하는 system prompt architecture, 좋은 책을 분석한 JSON 기반 SFT dataset, evaluation 기준, context builder, structured output, document patch 적용 흐름이 하나로 맞물렸습니다. AI helper는 독립적인 문장 생성 기능이 아니라, 책 제작 workflow의 한 계층이 되었습니다.

이 단계도 성공적으로 정리되었습니다. 긴 원고 맥락, 장르별 시스템 프롬프트, JSON 분석 데이터, fine-tuning 흐름, eval set, 에디터 document state 연동이 하나의 LLM 시스템으로 연결되었습니다. 옵클 에디터는 이제 멀티미디어 EPUB을 만드는 도구이면서, 동시에 책의 문장과 구조와 세계관을 함께 관리하는 AI 편집 환경으로 확장되었습니다.

목록으로

저작권 고시

본 웹사이트의 모든 디자인 결과물 및 영상에 대한 저작권은 Abstract Cloud에 있으며, 저작권법 및 관련 법령에 의해 보호받습니다. 웹, 영상, 본문, 표지, 내지 디자인을 포함한 모든 콘텐츠는 저작권자의 자산으로, 사전 동의 없이 무단 복제, 배포, 2차 저작물 제작, 온라인 공유 등을 금지합니다. 이를 위반할 시, 저작권법에 따라 민형사상 책임을 질 수 있습니다. 정당한 구매와 저작권 보호는 창작자의 권리를 지키며, 더 나은 작품으로 보답할 힘이 됩니다.

HOME

FAQ

이용 약관

개인정보 이용방침

help@opkle.app
010-2747-3403

상호 :추상적 형상 디자인(Abstract cloud) | 대표자 :배창규

사업자등록번호 :249-74-00533

통신판매업 신고번호 :2025-의정부송산-0634

주소 :경기도 의정부시 부용로 49, 108동 402호