이야기를 디버깅하는 개발자.

개발과 창작 사이에서, 사람들이 자기만의 이야기를 만들 수 있는 도구와 기록을 만듭니다.

roslyn.dev 자세히보기

웹소설 21

카쿠요무 10주년 논의를 읽고: 유행 장르 밖의 소설을 발견하는 법

웹소설을 고를 때 랭킹부터 열면 선택은 빠릅니다. 많은 사람이 읽는 작품의 제목과 소개를 한자리에서 볼 수 있기 때문입니다. 다만 매번 같은 입구로 들어가다 보면 내가 좋아할 만한 이야기를 충분히 찾아본 것인지, 익숙한 목록 안에서만 고른 것인지 구분하기 어려워집니다.카쿠요무 10주년 공식 기획에 실린 2026년 10월 7일 비평은 독자의 반응을 빠르게 반영하는 웹소설의 장점과, 인기 장르에 집중할 때 생기는 어려움을 함께 다룹니다. 기고자 아이사키 유지의 관점이지 일본 시장 전체를 조사한 통계나 플랫폼의 새 정책은 아닙니다.웹소설을 쓰는 사람으로서 저는 이 논의를 ‘유행을 따라야 할까’라는 선택만으로 읽고 싶지는 않았습니다. 독자로서 다른 작품을 만나는 경로를 늘리고, 작가로서는 내가 약속한 재미를 더..

작법서 한 권을 내 원고에 실험하는 독서 노트 템플릿

작법서를 읽을 때는 밑줄을 많이 긋지만, 며칠 뒤 원고를 열면 무엇을 적용해야 할지 모르는 일이 많습니다. 저도 좋은 문장을 수집하는 데 시간을 쓰면서 실제 장면은 그대로 둔 적이 많았습니다.작법서의 가치를 확인하는 가장 빠른 방법은 한 가지 주장을 작은 장면에 적용해 보는 것입니다. 이번 글에서는 책의 내용을 요약하는 대신 실험 가능한 독서 노트를 만드는 방법을 정리합니다.책의 주장과 내 해석을 분리합니다독서 노트 첫 칸에는 책이 실제로 말한 내용을 짧게 적습니다. 다음 칸에는 내가 이해한 뜻을 적습니다. 이 둘을 섞으면 나중에 내 생각을 책의 주장처럼 기억하게 됩니다.인용은 필요한 만큼만 하고, 페이지나 장을 기록합니다. 요약만으로 충분하지 않은 경우에는 책을 다시 펼쳐 원문을 확인해야 합니다. 노트..

독자 댓글을 다음 회차에 반영하는 기준과 금지선

연재를 시작하면 댓글 하나가 다음 회차의 방향을 바꿀 만큼 크게 느껴집니다. 독자가 발견한 오류를 고치는 일도 중요하지만, 모든 요구를 즉시 반영하면 작가가 세운 이야기의 중심이 흔들릴 수 있습니다.저는 댓글을 찬반으로 읽지 않고 정보의 종류로 분류합니다. 사실 오류인지, 취향인지, 오해인지, 스포일러를 요구하는 말인지 나누면 반영할 것과 거리를 둘 것이 보입니다.댓글은 사실·취향·오해·스포일러로 분류합니다댓글을 읽을 때 처음부터 방어적으로 반응하면 모든 말이 공격처럼 느껴집니다. 반대로 전부 맞다고 생각하면 작품이 댓글의 투표로 움직입니다. 네 가지 분류를 먼저 적용하면 반응과 판단 사이에 짧은 거리가 생깁니다.사실 오류는 가능한 한 빨리 확인하되, 취향은 작품 방향과 맞을 때만 참고합니다. 오해는 본..

대화문에서 인물 목소리를 분리하는 편집 루틴

대화문을 고칠 때 사투리나 어미를 바꾸면 인물 목소리가 달라진 것처럼 보입니다. 하지만 몇 문장 지나면 모든 인물이 같은 방식으로 질문하고 설명하는 문제가 다시 드러납니다.인물의 목소리는 말투보다 무엇을 말하지 않는지, 어떤 정보를 먼저 꺼내는지에서 더 잘 보입니다. 이번 글에서는 대사만 추출해도 화자를 구분할 수 있는지 확인하는 편집 순서를 소개합니다.대사를 장면에서 떼어 내 먼저 읽습니다지문과 서술이 함께 있으면 인물의 차이가 과장되어 보일 수 있습니다. 저는 한 장면의 대사만 복사해 화자 이름을 가리고 읽습니다. 누가 말했는지 쉽게 맞힐 수 없다면 말투가 아니라 사고 방식이 겹친 것입니다.이때 문장을 예쁘게 고치지 않고 목적과 정보량을 표시합니다. 질문하는 인물인지, 회피하는 인물인지, 상대의 말을..

클리프행어를 남발하지 않고 회차를 닫는 법

연재 글을 쓰다 보면 다음 회차를 읽게 만들기 위해 매번 큰 위기를 남기고 싶어집니다. 하지만 모든 회차가 같은 방식으로 끊기면 독자는 긴장보다 피로를 먼저 느낄 수 있습니다.회차의 끝은 반드시 폭발해야 하는 지점이 아니라, 이번 회차의 약속을 닫고 다음 질문을 여는 지점이라고 생각합니다. 세 가지 종료 방식을 나눠 보면 장면의 성격에 맞는 끝을 고르기 쉬워집니다.먼저 이번 회차의 약속을 한 문장으로 씁니다회차를 쓰기 전에 ‘이번 회차에서 독자가 반드시 확인해야 하는 것은 무엇인가’를 적습니다. 인물이 결심하는 회차인지, 비밀의 일부가 드러나는 회차인지, 관계가 틀어지는 회차인지 정하면 끝맺음의 방향도 달라집니다.약속을 닫지 않은 채 다음 회차의 질문만 남기면 독자는 아직 읽은 것이 끝나지 않았다고 느낄..

첫 문장과 첫 장면만 다시 쓰는 점검표

초고가 마음에 들지 않을 때 가장 먼저 전체를 고치고 싶어집니다. 하지만 첫 장면이 제 역할을 하지 못해서 뒤의 원고까지 불안하게 느껴지는 경우도 많습니다. 시작부를 작게 진단하면 무엇을 고쳐야 하는지 범위를 줄일 수 있습니다.이번 글에서는 첫 문장과 첫 장면만 떼어 내어 확인하는 점검표를 정리합니다. 정답 문장을 찾는 방법이 아니라, 독자가 무엇을 기대하게 되는지 확인하는 방법입니다.첫 문장은 분위기보다 약속을 전달해야 합니다첫 문장이 반드시 큰 사건으로 시작할 필요는 없습니다. 대신 독자가 어떤 종류의 이야기를 읽게 될지 약속해야 합니다. 인물의 문제인지, 세계의 이상인지, 관계의 긴장인지 한 가지가 보이면 다음 문장을 읽을 이유가 생깁니다.저는 첫 문장을 읽고 ‘이 장면에서 누가 무엇을 원하나’를 ..

연재 중 설정 충돌을 막는 캐릭터 상태표

연재가 길어질수록 설정집은 커지는데, 정작 다음 회차를 쓸 때 필요한 정보는 찾기 어려워집니다. 인물의 생일이나 외형보다 더 자주 바뀌는 것은 지금 알고 있는 사실과 감정입니다.저는 설정을 고정된 백과사전처럼 관리하지 않고, 회차가 끝날 때마다 상태를 갱신하는 표로 바꾸었습니다. 이번 글에서는 캐릭터 한 명의 현재 상태를 빠르게 확인하는 방법을 소개합니다.고정 정보와 회차 정보를 분리합니다이름·출신·말투처럼 쉽게 바뀌지 않는 정보와, 현재 목표·상대에 대한 의심·알게 된 사실처럼 회차마다 달라지는 정보를 한 표에 섞으면 업데이트가 어렵습니다. 저는 인물 카드와 상태표를 나눕니다.인물 카드는 작품 전체에서 유지할 약속이고, 상태표는 다음 장면을 쓰기 위한 작업 메모입니다. 상태표는 오래 보관할 문서가 아니..

퇴근 뒤 창작을 지키는 작업 경계 — 알림·회복·주간 약속을 설계한 기록

퇴근 후 두 시간이 있어도 글을 쓰지 못하는 날이 있습니다. 몸이 피곤해서이기도 하지만, 더 자주 일어나는 이유는 업무가 끝났다는 신호가 없기 때문입니다. 메신저 알림을 확인하고 내일 할 일을 생각하다 보면 창작 시간은 이미 지나가 있습니다.저는 시간표를 더 촘촘하게 만드는 대신 경계를 만들었습니다. 언제까지 업무를 확인하고, 얼마나 회복한 뒤, 어떤 최소 작업을 할지 미리 정하니 창작을 못한 날에도 다시 돌아오는 길이 생겼습니다.창작 시간을 확보하기 전에 업무 종료 신호를 만듭니다업무용 프로그램을 닫는 것만으로는 머릿속 일이 닫히지 않습니다. 저는 퇴근 전에 미완료 업무를 세 줄로 적습니다. ‘다음에 할 일’, ‘기다리는 사람’, ‘내일 확인할 시각’입니다. 이 기록이 있어야 머릿속에서 계속 같은 일을..

웹소설 설정집을 AI에 물려주는 프롬프트 구조 — 컨텍스트 설계법

연재 중이던 원고에서 조연 이름이 두 화 만에 바뀐 적이 있습니다. 제가 실수한 건 아니었고, AI에게 이어 쓰기를 시켰더니 설정집에 분명히 적혀 있는 이름 대신 비슷한 다른 이름을 써서 돌려준 겁니다. 그때 제가 넣은 프롬프트는 세계관 문서 전체를 복사해 붙인 것이었습니다. 분량으로는 원고 열 화쯤 되는 양이었습니다.설정집이 있으면 AI가 알아서 지켜줄 거라고 생각하기 쉽습니다. 그런데 실제로는 설정집을 많이 넣을수록 반영률이 떨어지는 구간이 생깁니다. 모델이 게을러서가 아니라, 넣은 정보 사이에 우선순위가 없어서 무엇이 중요한지 판단할 근거가 없기 때문입니다.메리톡톡을 만들면서 이 문제를 계속 붙들고 있었습니다. 결론은 단순했습니다. 설정집은 한 덩어리가 아니라 성격이 다른 세 종류의 정보이고, 그걸..

"자동 생성" 대신 "이어 쓰기"를 택한 이유 — 창작 보조 도구 설계 기록

이전에 이 주제로 관점을 한 번 정리한 적이 있습니다. 자동 생성이 아니라 이어 쓰기여야 한다는 이야기였는데, 그때는 문제 제기에 가까웠습니다. 이번 글은 그 뒤의 기록입니다. 실제로 메리톡톡을 만들면서 어디서 멈출지, 무엇을 포기할지를 코드 단위로 정해야 했고, 그 결정들을 남겨둡니다.가장 먼저 확인한 것은 제 자신의 반응이었습니다. 초기 버전에서 문단 하나를 통째로 생성해 화면에 띄워봤는데, 문장은 꽤 그럴듯했는데도 손이 멈췄습니다. 고쳐 쓸지 지울지를 판단하는 동안, 원래 쓰려던 문장이 머릿속에서 사라졌습니다. 잘 쓰인 남의 문장이 내 문장을 덮어쓴 셈입니다.그때 알았습니다. 창작 보조 도구에서 진짜 위험한 것은 품질이 낮은 결과물이 아니라, 품질이 적당히 높아서 판단을 대신해버리는 결과물입니다. ..

반응형