로슬린의 인생잡담

[애매한 개발자의 창작 기록 1] 나는 왜 글을 쓰고 싶어졌나

Roslyn — Tue, 26 May 2026 20:48:31 +0900

“무슨 일 하세요?”

누군가 직업을 물으면 저는 거의 망설이지 않고 대답합니다.

“웹 개발자입니다.”

이 대답은 틀리지 않습니다.
저는 21년 동안 웹 개발자로 일했습니다. 코드를 쓰고, 오류를 고치고, 화면을 만들고, 서버를 붙이고, 서비스가 어떻게든 돌아가게 만드는 일을 해왔습니다.

그 시간 덕분에 지금까지 먹고살 수 있었습니다.
개발자라는 직업은 제 삶을 지탱해준 가장 현실적인 이름입니다.

하지만 언제부턴가 그 이름만으로는 저를 다 설명하기 어렵다는 생각이 들기 시작했습니다.

개발자로 살아왔지만, 개발자로만 끝나고 싶지는 않았습니다.
그렇다고 스스로를 작가라고 부르기에도 아직은 많이 조심스럽습니다.
글을 잘 쓰는 사람도 아니고, 대단한 성과를 낸 사람도 아닙니다.

그럼에도 불구하고 이상하게 계속 글을 쓰고 싶었습니다.

이 글은 그 마음이 어디서 시작됐는지에 대한 첫 번째 기록입니다.

1. 시작은 나우누리의 파란 화면이었다

제가 처음으로 무언가를 써서 남에게 보여준 건 중학생 때였습니다.

당시는 하이텔과 나우누리 같은 PC통신이 있던 시절이었습니다. 지금처럼 세련된 글쓰기 플랫폼도, 편리한 에디터도 없었습니다. 파란 화면 위에 글자를 입력하고, 게시판에 글을 올리고, 누군가 읽어주기를 기다리던 시절이었습니다.

그때 저는 무협지에 빠져 있었습니다.
책 대여점에서 빌려온 무협지를 읽고 또 읽다가, 어느 순간 이런 생각을 했습니다.

“나도 한번 써볼 수 있지 않을까?”

지금 생각하면 별 근거 없는 자신감이었습니다.
구성도 서툴렀고, 문장도 거칠었고, 인물도 어디선가 본 듯한 모습이었을 겁니다. 그래도 그때는 그런 걸 따질 만큼 영리하지 않았습니다.

그냥 쓰고 싶었습니다.

머릿속에 떠오른 장면을 붙잡고 싶었고, 이름 모를 인물에게 말을 시키고 싶었고, 내가 만든 세계 안에서 누군가 움직이는 걸 보고 싶었습니다.

그게 제 글쓰기의 시작이었습니다.

물론 오래가지는 못했습니다.
학교를 다니고, 군대를 다녀오고, 취업을 하고, 직장인이 되면서 글쓰기는 자연스럽게 멀어졌습니다.

먹고사는 일은 언제나 먼저였습니다.
그리고 먹고사는 일을 핑계로, 저는 오랫동안 글을 쓰지 않았습니다.

2. 개발자로 사는 일은 나쁘지 않았다

개발자로 사는 일이 싫었던 것은 아닙니다.

코드를 쓰는 일에는 분명한 재미가 있습니다.
막혀 있던 오류가 풀릴 때, 복잡하던 흐름이 정리될 때, 아무것도 없던 화면이 사용 가능한 서비스가 될 때의 감각은 여전히 좋습니다.

다만 시간이 지날수록 알게 된 것도 있습니다.

저는 개발을 좋아하지만, 개발을 아주 잘하는 사람은 아니라는 것.
새로운 기술을 빠르게 흡수하고, 어려운 개념을 쉽게 이해하고, 복잡한 구조를 우아하게 설계하는 유형의 개발자는 아니라는 것.

그저 필요한 만큼 배우고, 맡은 일을 처리하고, 문제가 생기면 검색하고, 다시 고치고, 그렇게 직장 생활을 유지해온 사람에 가깝습니다.

이런 말을 공개적으로 쓰는 게 조금 불편하긴 합니다.
개발자라는 이름으로 오래 살아왔는데, 스스로를 대단한 개발자라고 말하지 못한다는 건 어쩐지 초라하게 느껴지기도 하니까요.

하지만 요즘은 오히려 그 사실을 인정하는 편이 낫겠다고 생각합니다.

저는 개발 천재도 아니고, 기술 인플루언서도 아닙니다.
AI 전문가도 아닙니다.
대단한 스타트업을 성공시킨 창업자도 아닙니다.

다만 오래 일했고, 계속 고쳤고, 어떻게든 서비스를 굴러가게 만들어온 사람입니다.

그리고 그 경험은 적어도 한 가지를 가르쳐주었습니다.

무언가를 계속하기 위해서는 재능만으로는 부족하다는 것.
계속 돌아오게 만드는 구조가 필요하다는 것.

이 생각은 나중에 글쓰기와도 연결되었습니다.

3. 다시 글을 쓰고 싶어진 이유

몇 년 전부터 다시 글을 쓰기 시작했습니다.

처음부터 거창한 목표가 있었던 건 아닙니다.
베스트셀러 작가가 되겠다거나, 인생을 바꾸겠다는 계획도 없었습니다.

그보다는 조금 더 단순했습니다.

“내 이야기를 하나쯤 끝까지 써보고 싶다.”

오랫동안 개발자로 살아오면서, 제 하루는 대부분 남의 요구사항을 구현하는 일로 채워졌습니다. 물론 그것이 직업이고, 그 일을 통해 살아왔습니다. 하지만 어느 순간부터는 제 안에 있는 무언가를 제 언어로 꺼내보고 싶다는 마음이 커졌습니다.

코드는 대체로 목적이 분명합니다.
요구사항이 있고, 입력이 있고, 출력이 있고, 오류가 있으면 고치면 됩니다.

하지만 글은 달랐습니다.

무엇을 써야 하는지부터 막혔고, 왜 쓰고 싶은지도 자주 흔들렸습니다.
분명 쓰고 싶은 이야기가 있는데, 막상 문서 앞에 앉으면 아무것도 아닌 것처럼 느껴졌습니다.
어제는 괜찮아 보였던 문장이 오늘은 부끄럽게 느껴졌고, 머릿속에서는 그럴듯했던 설정이 글로 옮기면 힘을 잃었습니다.

그래도 이상하게 다시 돌아오게 됐습니다.

잘 써서가 아니었습니다.
성과가 있어서도 아니었습니다.
오히려 결과만 놓고 보면 자신 있게 말할 만한 건 별로 없습니다.

온라인 출판을 한 번 해봤지만 성적은 좋지 않았습니다.
그 경험이 저를 작가로 만들어준 것도 아니었습니다.
오히려 “나는 아직 작가라고 말하기 어렵다”는 사실을 더 분명하게 알게 됐습니다.

그런데도 글을 쓰고 싶었습니다.

아마 글쓰기는 제게 결과보다 방향에 가까운 일이었던 것 같습니다.
어디에 도착했는지보다, 내가 어떤 사람으로 살아가고 싶은지를 묻게 만드는 일.

개발자로 먹고살고 있지만, 언젠가는 제 이야기를 쓰는 사람으로 살고 싶다.
그 마음이 다시 글쓰기 앞에 저를 앉혔습니다.

4. 글을 쓰고 싶어서 도구를 만들기 시작했다

문제는 글을 쓰고 싶다고 해서 글이 쉽게 써지지는 않는다는 점입니다.

퇴근 후에는 피곤했고, 주말에는 마음만 앞섰습니다.
설정은 쌓이는데 본문은 나아가지 않았고, 제목은 마음에 들지 않았고, 시놉시스는 자꾸 흐려졌습니다.

그때 자연스럽게 이런 생각을 하게 됐습니다.

“내가 계속 글을 쓰려면 어떤 환경이 필요할까?”

처음에는 단순한 질문이었습니다.
하지만 이 질문은 점점 제가 만들고 싶은 서비스의 방향이 되었습니다.

저는 AI가 글을 대신 써주는 것에 큰 매력을 느끼지 못했습니다.
물론 AI는 유용합니다. 막힌 부분을 풀어주기도 하고, 생각하지 못한 표현을 제안하기도 합니다. 하지만 AI가 만든 문장이 늘 제 글처럼 느껴지는 것은 아니었습니다.

제가 필요했던 건 대신 써주는 도구라기보다, 다시 쓰게 만드는 환경이었습니다.

흩어진 설정을 붙잡아주고, 막힌 시놉시스를 다시 보게 하고, 제목 후보를 정리하게 하고, 내가 쓰려던 이야기가 무엇이었는지 잊지 않게 해주는 공간.

그런 생각에서 메리톡톡을 만들기 시작했습니다.

거창한 서비스라고 말하기는 어렵습니다.
처음부터 완벽한 플랫폼도 아니었고, 지금도 부족한 점이 많습니다.
그저 제 안의 개발자가 제 안의 아직 서툰 작가를 위해 만들어본 작은 작업 공간에 가깝습니다.

하지만 그 방향만큼은 조금 분명해졌습니다.

저는 글쓰기를 대체하는 기술보다, 글을 계속 쓰게 만드는 구조에 관심이 있습니다.

5. 나는 아직 애매한 사람이다

이 연재의 제목을 “애매한 개발자의 창작 기록”이라고 붙인 이유도 여기에 있습니다.

저는 개발자로 오래 살았지만, 개발 실력을 앞세워 브랜딩하고 싶은 사람은 아닙니다.
글을 쓰고 싶지만, 작가라고 당당히 말하기에도 아직은 부족합니다.
AI 도구를 다루고 있지만, AI 전문가라고 말할 수도 없습니다.

그래서 애매합니다.

하지만 요즘은 그 애매함이 꼭 약점만은 아닐지도 모른다고 생각합니다.

개발자로 오래 일했기 때문에 서비스를 만드는 현실을 조금은 압니다.
글을 써보려다 자주 막혔기 때문에 창작의 막막함도 조금은 압니다.
대단한 성공을 하지 못했기 때문에, 계속하는 일이 얼마나 어려운지도 압니다.

어쩌면 제가 기록할 수 있는 건 성공한 사람의 방법론이 아니라, 아직 잘하지 못하는 사람이 계속하려고 애쓰는 과정일지도 모릅니다.

이 블로그와 이 연재는 그런 기록이 되기를 바랍니다.

잘난 척하기 위한 기록이 아니라,
잘하고 싶지만 아직 서툰 사람이 자기 자리를 찾아가는 기록.

개발자로 살아왔고,
글을 쓰고 싶고,
그래서 글을 계속 쓰기 위한 도구를 만들고 있는 사람의 기록.

첫 번째 글은 여기서 시작하려고 합니다.

저는 아직 무엇 하나 선명하게 잘한다고 말하기 어렵습니다.
하지만 글을 쓰고 싶습니다.
그리고 그 마음만큼은 오래전 나우누리의 파란 화면 앞에 앉아 있던 중학생 때와 크게 다르지 않은 것 같습니다.

다음 기록

다음 글에서는 조금 더 불편한 이야기를 해보려고 합니다.

한 번 온라인 출판을 해봤지만, 저는 여전히 스스로를 작가라고 부르기 어렵습니다.
왜 그런지, 그 경험이 제게 무엇을 남겼는지 정리해보겠습니다.

21년 차 개발자인데, 나는 왜 아직도 내가 애매하다고 느낄까

Roslyn — Mon, 25 May 2026 10:23:44 +0900

어디서 일한 기간을 말할 때면 문득 목소리가 작아질 때가 있습니다. 21년이라는 시간 동안 웹 개발자로 일해왔으니 남들은 베테랑이라 부를지 모르겠지만, 정작 스스로는 "뛰어난 개발자"라고 말하기가 참 어렵습니다. 엄청난 기술적 성취를 이루거나 트렌드를 선도하는 스타 개발자였던 적은 없습니다. 그저 주어진 직장 생활을 성실히 유지하고, 눈앞에 닥친 실무 문제를 해결하며 묵묵히 버텨온 시간에 가깝습니다.

마음 한구석에는 늘 글을 쓰고 싶다는 열망이 출렁였습니다. 그 마음을 모아 밤마다 웹소설을 썼고, 고맙게도 기회가 닿아 온라인 출판까지 해보았습니다. 하지만 시장의 냉정한 결과표 앞에서 제 글은 큰 성과를 거두지 못했습니다. 그러다 보니 어디 가서 당당하게 "작가"라고 제 소개를 하는 것 역시 조심스럽고 망설여집니다.

결국 저는 경계에 선 사람이 되었습니다. 개발자라고 하기엔 특별한 무기가 없는 것 같고, 작가라고 하기엔 내세울 성과가 부족하며, 요즘 대세라는 AI 전문가라고 하기엔 시중의 모델을 활용하는 실무자일 뿐이니 더더욱 아닙니다. 이 셋 중 어느 곳에도 온전히 속하지 못한다는 감각은 오랫동안 저를 '참 애매한 사람'이라는 고뇌 속에 가두어 두었습니다.

이 애매함의 틈바구니에서 발견한 것

하지만 오랫동안 앓아온 이 애매함이, 어쩌면 진정으로 다른 창작자들을 도울 수 있는 뜻밖의 출발점이 될지도 모른다는 생각이 들었습니다.

화려한 최신 기술을 뽐내는 전문가들은 '기능'을 보지만, 저는 글을 쓰고 싶어 하는 사람의 깊은 '막막함'을 압니다. 플롯이 엉켜 새벽 내내 깜빡이는 커서만 노려볼 때의 피로함, 내가 쓴 문장이 마음에 들지 않아 통째로 지워버릴 때의 좌절감을 뼈저리게 겪어보았기 때문입니다.

동시에 저는 비록 평범할지언정 서비스를 만들고, 고치고, 끈질기게 유지해 가는 실무 개발자로서의 경험을 가지고 있습니다.

최신 AI 기술이 쏟아져 나오며 버튼 하나로 소설을 뚝딱 만들어 준다는 자극적인 광고들이 넘쳐납니다. 하지만 작가들에게 정말 필요한 기술은 창작을 '대신'해 주는 기계가 아닙니다. 엉킨 생각을 스스로 정리할 수 있도록 돕고, 무너진 창작의 리듬을 찾아 다시 자기 문장으로 돌아오게 만드는 조용한 UI/UX 설계가 필요합니다.

화면의 레이아웃을 어떻게 잡아야 눈이 덜 피로할지, 어떤 인터페이스를 제공해야 작가가 기술에 압도당하지 않고 오롯이 자신의 원고에 집중할 수 있을지 고민하는 일. 대단한 기술 과시가 아니라, 창작자가 포기하지 않고 '계속할 수 있는 작은 구조'를 만드는 일. 이것이야말로 두 영역을 서툴게 서성여본 저 같은 사람만이 할 수 있는 고민이 아닐까 싶었습니다.

기록을 위한 작은 작업실을 열며

그래서 이 공간을 시작하려 합니다.

여기는 제가 얼마나 대단한 기술을 가졌는지 증명하거나, 가보지 못한 성공의 노하우를 과장해서 전시하는 잘난 척을 위한 공간이 아닙니다. 전문가로서 정답을 단정 짓기보다는, 매일 흔들리면서도 어떻게든 버텨내는 생활형 창작자의 솔직한 고민을 담고 싶습니다.

내가 왜 쓰려고 하는지, 왜 자꾸 멈추는지, 그리고 막힌 흐름을 풀기 위해 어떤 작은 도구들을 고민하고 만들어보았는지 그 서툰 과정들을 고스란히 기록해 두려 합니다.

비록 정점에 서지 못한 애매한 삶일지라도, 쓰다가 멈추고 다시 돌아오는 이 길고 조용한 여정의 기록이 매일 밤 모니터 앞에서 외롭게 글을 쥐어짜 내는 누군가에게 작은 힌트와 위로가 될 수 있기를 바랍니다. 완성된 성과가 아니라, 계속하려는 시도들을 차곡차곡 쌓아 나가겠습니다.

어른들이 '어린 시절'을 그리워하는 진짜 이유: 동심의 심리학

Roslyn — Sun, 24 May 2026 16:18:15 +0900

우리는 살면서 문득 어린 시절을 그리워하곤 합니다. 골목길에서 친구들과 해 저무는 줄 모르고 놀았던 기억, 별것 아닌 장난감 하나에 온 세상을 얻은 듯 기뻐했던 순간들이 문득 떠오를 때가 있죠. 나이가 들고 사회생활에 치일수록 이런 마음은 더 간절해집니다.

우리는 왜 이토록 '어린 시절의 마음(동심)'을 갈망하는 걸까요? 단순히 나이를 먹어서 부리는 감상적인 투정일까요? 최근의 심리학과 뇌과학 연구들은 우리가 어린 시절을 그리워하는 데에는 생각보다 훨씬 깊고 과학적인 이유가 숨어있다고 말합니다.

1. 우리가 부르는 '동심'의 진짜 얼굴

흔히 동심이라고 하면 '아무것도 모르는 순수한 마음'을 떠올리지만, 학문적으로 보면 동심은 꽤 입체적인 개념입니다.

철학에서는 동심을 인간이 태어날 때 가지고 있던 '본래의 순수함과 진실성'으로 봅니다.
심리학에서는 세상 모든 것을 새롭고 경이롭게 바라보는 '인지적 방식'이자, 놀이를 통해 세상을 배워나가는 정서적 소통으로 정의합니다.

재미있는 점은 실제 아이들의 마음은 어른들이 상상하는 것처럼 '아무 걱정 없는 천진난만한 낙원'만은 아니라는 사실입니다. 아이들도 나름대로 감정을 조절하느라 애를 쓰고, 친구 관계에서 스트레스를 받으며, 때로는 불안과 좌절을 겪습니다.

즉, 우리가 그리워하는 동심은 실제 아동의 날것 그대로의 마음이라기보다, 어른이 된 우리가 삶의 묵은 때를 벗겨내고 싶어 회고적으로 재구성한 '가장 아름다운 시절의 상징'에 가깝습니다.

2. 마음이 불안할 때 '향수'가 찾아오는 이유

심리학 연구에 따르면, 사람들이 과거를 그리워하는 '향수(Nostalgia)'는 평소보다 외로움을 느끼거나, 현실의 위협을 받거나, '내가 지금 잘 살고 있는 걸까?' 하는 불안감이 찾아올 때 유독 강하게 활성화된다고 합니다.

지치고 힘들 때 꺼내 보는 어린 시절의 기억은 우리 마음속에서 놀라운 물리치료제 역할을 합니다.

정서적 안정감: 옛 기억을 떠올리는 것만으로도 나를 무조건 지지해 주던 가족이나 친구들과의 '사회적 연결감'이 채워집니다.
자존감 회복: 자전적인 기억(내가 주인공인 기억)을 복기하면서 나의 존재 가치와 의미를 다시금 확인하게 됩니다.
삶의 연속성: '그때의 순수했던 아이가 자라서 지금의 내가 되었구나'라는 깨달음을 주어, 현실의 위기 속에서도 마음의 중심을 잡을 수 있게 돕습니다.

뇌과학적으로도 우리가 어린 시절을 그리워할 때, 나 자신을 인식하는 뇌 부위와 기억을 담당하는 부위, 그리고 즐거움을 느낄 때 활성화되는 '보상 회로'가 동시에 작동한다고 합니다. 과거 여행이 단순히 뇌의 착각이 아니라, 실질적으로 우리 마음을 위로하는 시스템인 셈입니다.

3. 이야기를 통해 동심을 되찾는 방법

그렇다면 이미 어른이 되어버린 우리는 어떻게 동심을 다시 경험할 수 있을까요? 가장 좋은 방법은 '이야기(서사)'를 통하는 것입니다. 우리가 소설, 영화, 드라마 혹은 동화를 보며 눈물을 흘리고 위로를 받는 이유가 바로 여기에 있습니다.

좋은 이야기는 다음과 같은 단계를 통해 우리 마음을 정화합니다.

1단계 (결핍과 상실): 주인공이 현실에서 상처를 입거나 소중한 가치(순수함 등)를 잃어버린 모습을 보여주며 우리의 현재 모습과 동질감을 느끼게 합니다.
2단계 (유년의 환기): 주인공이 어떤 계기나 매개체를 통해 어린 시절의 순수했던 기억이나 가치를 다시 떠올리게 만듭니다.
3단계 (회복과 통합): 과거의 기억으로부터 힘을 얻은 주인공이 현실의 문제를 해결해 나가는 과정을 보며, 독자 역시 "나에게도 저런 순수한 힘이 있었지" 하고 위로를 얻고 현실을 살아갈 에너지를 얻습니다.

글을 맺으며: 동심은 도망치기 위한 곳이 아닙니다

어린 시절을 그리워하는 것은 현실 도피가 아닙니다. 그것은 치열한 현실 속에서 나를 잃어버리지 않기 위해, 우리 마음이 스스로 작동시키는 '가장 건강한 방어 기제'입니다.

오늘 밤, 유독 현실이 무겁고 외롭게 느껴진다면 잠시 눈을 감고 가장 찬란했던 시절의 나를 만나보세요. 흙먼지를 묻히며 환하게 웃던 그 아이는 멀리 가버린 것이 아니라, 지금도 당신의 마음 깊은 곳에서 당신이 다시 힘을 내어 걸어가기를 묵묵히 응원하고 있습니다.

AI가 뚝딱 만들어낸 '남의 코드'를 보며, 작가의 하얀 화면을 생각했다

Roslyn — Sun, 24 May 2026 12:51:50 +0900

저는 21년 차 웹 개발자입니다. 대단한 기술 스타는 아니지만, 직장 생활 안에서 필요한 서비스를 만들고 고치며 오랫동안 코드를 만져왔습니다. 그리고 마음 한쪽에는 늘 글을 쓰고 싶다는 열망을 품은 채, 실제로 웹소설을 쓰고 온라인 출판을 경험해 본 초보 작가이기도 합니다.

얼마 전, 저는 평소처럼 AI 코딩 도구를 활용해 작은 서비스를 만들다가 아찔한 순간을 경험했습니다.

초반에는 아주 매끄러웠습니다. 머릿속 아이디어를 던지자 AI가 수백 줄의 코드를 순식간에 짜 내려갔고, 엄청난 생산성을 손에 쥔 기분이 들었죠. 하지만 프로젝트 덩치가 커지면서 엉뚱한 오류가 반복되기 시작했습니다. 간단한 문제 같은데도 AI는 갈팡질팡하며 엄청난 양의 토큰을 허비하더군요.

결국 제가 직접 개입해 코드를 수정하려고 에디터를 열었습니다. 그리고 순간 숨이 턱 막혔습니다. 화면을 가득 채운 것은, 그간 편하다는 이유로 일절 관여하지 않고 AI에게 통째로 맡겨두었던 완벽하게 낯선 ‘남의 코드’였기 때문입니다. 내가 직접 통제할 수 없다는 감각은 생각보다 큰 무력감을 주었습니다.

그 순간, 모니터 앞의 개발자인 제 모습 위로 화면을 가득 채운 하얀 배경과 깜빡이는 커서 앞에서 절망하던 '작가로서의 나'가 겹쳐 보였습니다. 이것은 코딩 에디터의 문제만이 아니라, AI와 함께 글을 쓰는 현대의 작가들이 마주한 인터페이스의 핵심 문제였습니다.

1. '남의 코드'가 주는 무력감, '남의 문장'이 주는 허무함

개발자가 AI에게 코딩을 통째로 맡겼을 때 마주하는 배신감은, 작가가 AI 소설 생성기로 글을 쓸 때 느끼는 허무함과 놀라울 정도로 닮아 있습니다.

최근 유행하는 수많은 창작 AI 도구들은 사용자에게 아무런 걸림돌이 없는 '가장 매끄러운 경험'을 제공하는 것을 자랑합니다. 몇 줄의 시놉시스만 넣으면 AI가 알아서 유려한 소설 본문을 뚝딱 만들어내죠. 키보드에서 손을 떼게 해 주니 참으로 친절한 인터페이스처럼 보입니다.

하지만 기술이 인간의 모든 고민을 대신하여 매끄러운 자동화를 이룩할 때, 작가는 가장 중요한 상태를 상실합니다. 바로 '내 글'이라는 주체성과 통제권입니다.

이야기가 복잡해지거나 인물의 감정선을 섬세하게 풀어야 하는 결정적인 순간이 오면, AI는 어김없이 한계에 부딪혀 뻔한 클리셰나 엉뚱한 전개를 뱉어냅니다. 이때 작가는 개입해서 글을 고쳐야 합니다. 하지만 앞부분을 AI에게 전부 맡겨왔다면, 작가는 화면 위에서 수만 자의 거대한 ‘남의 글’을 마주하게 됩니다. 내 생각의 줄기에서 뻗어 나오지 않은 문장들은 아무리 훌륭해도 맥락을 분석하기 어렵고, 결국 수정을 포기한 채 다시 AI 생성 버튼만 무력하게 연타하는 악순환에 빠집니다.

2. 개발자의 에디터에서 찾는 '작가적 안전망'

개발자들은 AI를 사용할 때 '남의 코드'가 되어버리는 것을 막기 위해 의도적인 불편함을 감수하곤 합니다. 상세한 프롬프트(지침)를 미리 별도로 작성해 두고, 세부 계획을 수립한 뒤, AI가 그 설계도를 벗어나지 않도록 끊임없이 확인하며 통제권을 유지합니다. 프로젝트가 커졌을 때 언제든 내가 개입해서 수정할 수 있는 '내 코드'의 상태를 유지하기 위함입니다.

진정으로 작가를 위하는 UI/UX 기술 역시 바로 이 지점에서 시작되어야 합니다.

좋은 창작 인터페이스는 작가의 손을 완전히 놀게 만드는 기술이 아닙니다. 오히려 개발자의 설계도처럼, 작가가 세워둔 세계관과 플롯이라는 세부 계획을 집필 화면 옆에 명확히 유지해 주고, AI가 인간 작가의 리듬을 깨뜨리지 않도록 철저히 '보조 장치'의 자리로 밀어내 주는 구조여야 합니다.

자동 생성이 아닌, 조율된 디자인적 마찰: 한 장의 에피소드를 통째로 채워주는 UI가 아니라, 작가가 막힌 골목에 섰을 때 생각을 툭 건드려 다시 스스로 키보드를 두드릴 수 있게 돕는 인터페이스.
언제든 내 문장으로 돌아오는 흐름: AI의 제안을 조심스럽게 참고하더라도, 이것이 내 이야기의 맥락을 해치지 않고 언제든 안심하고 내 글로 복귀할 수 있도록 지탱하는 시각적 안전망.

3. 완성된 사람의 전시장이 아니라, 계속 쓰는 사람의 조용한 작업실로

브랜딩과 기술의 홍수 속에서 가장 위험한 것은 내 역량보다 감당하지 못할 이미지를 먼저 만드는 것입니다.

AI가 소설을 알아서 척척 완성해 줄 것이라는 과장된 환상은, 결국 내가 통제할 수 없는 거대한 '남의 이야기'라는 부메랑이 되어 돌아올 뿐입니다.

저는 AI를 깊이 연구하는 전문가도 아니고, 모델을 직접 만드는 사람도 아닙니다. 다만 21년 동안 웹을 만들고 고치며 버텨온 실무 개발자의 시선으로, 글을 쓰고 싶어 하는 한 명의 창작자로서, 어떻게 하면 우리가 기술에 압도당하지 않고 오롯이 나만의 작업대를 지켜낼 수 있을지를 고민하고 있습니다.

AI를 앞세우고 싶지는 않습니다. 하지만 개발자로 살아온 제 작은 경험과 UI/UX적 고민이, 글을 쓰는 사람이 다시 자기 생각과 문장으로 돌아오는 데 조심스럽게나마 도움이 될 수 있다면 좋겠습니다.

이곳은 대단한 성과를 전시하는 곳이 아닙니다. 개발과 글쓰기 사이에서, 우리가 기술의 주도권을 잃지 않고 '오래, 그리고 계속 쓰는 방법'을 찾아가는 솔직한 작업 노트들을 차분히 쌓아가겠습니다.

부디 이 기록들이 글을 포기하지 않으려는 누군가에게 작은 공감과 실마리가 되기를 바랍니다.

자동 생성(Generation)이 아니라 이어 쓰기(Continuation) : AI 시대에 작가에게 진짜 필요한 UI

Roslyn — Sun, 24 May 2026 12:39:04 +0900

어느 날 문득 시중의 수많은 창작 보조 AI 도구들을 살펴보았습니다. 광고 문구들은 저마다 화려하더군요.

“단 3초 만에 소설 한 편 완성”, “클릭 한 번으로 베스트셀러 시놉시스 생성.”

그 기술들의 영리함과 속도에 감탄하면서도, 한편으로는 마음속에 묘한 서늘함과 질문이 남았습니다.

‘정말 자기 글을 쓰고 싶어 하는 작가들이 원한 게, 겨우 키보드에서 손을 떼는 일이었을까?’

현대의 기술 공급자들은 작가의 막막함을 해결해 주겠다며 ‘인간을 대신해 주는 자동화’를 미덕으로 삼습니다.

하지만 창작의 영역에서 이 방식은 치명적인 결함을 만들어냅니다.

AI가 뚝딱 만들어낸 매끄럽고 완벽한 문장을 마주할 때, 작가가 느끼는 감정은 경이로움이 아니라 대개 이질감과 허무함입니다.

내 생각의 줄기에서 뻗어 나오지 않은 문장은 아무리 훌륭해도 ‘내 글’이 아니기 때문입니다.

창작자들을 위한 UI/UX를 고민하는 입장에서, 저는 AI 시대의 창작 도구가 전면에 내세워야 할 가치는 자동 생성(Generation)이 아니라 이어 쓰기(Continuation)여야 한다고 믿습니다.

1. '생성' 중심 UI가 작가의 주체성을 해치는 방식

많은 AI 에디터들이 채택하고 있는 전형적인 사용자 경험(UX)은 다음과 같습니다. [키워드 입력] -> [생성 버튼 클릭] -> [수초 간의 로딩] -> [수백 자의 본문 완성].

이 매끄러운 흐름 속에서 작가의 역할은 ‘글을 쓰는 사람’에서 AI가 내놓은 결과물을 검토하고 골라내는 ‘감수자’나 ‘편집자’로 전락하고 맙니다.

심리학적으로 창작은 단순히 문자를 화면에 나열하는 행위가 아닙니다. 머릿속의 엉킨 실타래를 풀고, 단어를 고르고, 문장을 지웠다 다시 쓰며 내면의 세계를 구체화하는 인지적 리듬의 과정입니다. 이 리듬을 기술이 통째로 가로채 가 버리면, 작가는 창작의 핵심적인 기쁨인 '내가 이야기를 지어내고 있다'는 주체성을 잃어버립니다.

기술이 지나치게 친절하여 인간의 고민을 완전히 삭제할 때, 창작자는 오히려 소외감을 느낍니다.

2. 주인공은 기술이 아니라 작가의 '리듬'이다

진정으로 작가를 위하는 기술이라면, AI의 놀라운 연산 능력을 자랑하는 창이 되어서는 안 됩니다. 대신 철저하게 작가 옆에 놓인 ‘작은 작업대’의 역할을 자처해야 합니다.

작가가 글을 쓰다 멈추는 이유는 아이디어가 완전히 고갈되어서라기보다, 머릿속에 떠오른 파편들을 다음 문장으로 연결할 ‘실마리’를 찾지 못해서일 때가 많습니다. 이때 필요한 인터페이스는 완성된 소설의 한 장(Chapter)을 던져주는 것이 아닙니다.

“이 인물은 지금 왜 화가 났을까요?”
“앞서 언급한 그 오래된 열쇠를 여기서 활용해 보면 어떨까요?”
“이야기가 막혔다면, 인물의 시선을 주변 사물로 잠시 돌려보는 건 어떨까요?”

이처럼 작가의 생각을 툭 건드려, 다시 스스로 키보드를 두드릴 수 있게 돕는 ‘조율된 디자인적 마찰(Design Friction)’이 필요합니다. 시스템은 대단한 정답을 내놓는 AI 작가가 아니라, 멈춰버린 인간 작가의 생각이 다시 구르고 흘러가게 만드는 보조 장치여야 합니다.

3. 내가 글을 포기하지 않기 위한 작은 작업대

글을 쓴다는 것은 외롭고 쉽게 멈추는 일입니다. 저 역시 글을 쓰고 싶어 치열하게 고민해 본 경험이 있기에, 첫 문장을 떼지 못해 하얀 화면만 응시할 때의 막막함을 누구보다 잘 알고 있습니다.

제가 직접 쓰기 위해, 그리고 글을 포기하지 않기 위해 작은 도구를 고민하기 시작한 것도 바로 그 때문입니다.

기술을 앞세워 창작 생태계를 혁신하겠다는 거창한 포부 같은 건 없습니다. 다만 기술이 인간의 자리까지 침범해 들어오는 이 시대에, 글을 쓰려는 사람이 오롯이 자기 생각에 집중하고 다시 자기 문장으로 돌아올 수 있도록 돕는 조용한 작업 공간을 만들고 싶을 뿐입니다.

앞으로 이곳에는 화려한 신기술의 나열 대신, 어떻게 하면 우리가 기술의 홍수 속에서도 주체성을 잃지 않고 ‘오래, 그리고 계속 쓸 수 있을지’에 대한 소박한 고민과 UI/UX적 시도들을 차분히 쌓아가려 합니다.

글을 잘 쓰는 사람은 아직 아닐지라도, 글을 향한 마음만큼은 포기하지 않는 이들의 작은 길잡이가 되기를 바랍니다.

메리톡톡을 다시 만들며: 왜 ASP.NET MVC에서 Nuxt를 거쳐 Next.js까지 왔나

Roslyn — Sun, 24 May 2026 07:37:49 +0900

메리톡톡은 처음부터 지금의 모습으로 시작한 서비스가 아니었다.

가장 처음의 메리톡톡은 ASP.NET MVC로 만들었다. 당시의 나는 지금처럼 “글쓰기 경험”이나 “창작자의 리듬” 같은 표현을 명확히 붙잡고 있지는 못했다. 그래도 한 가지는 분명하게 알고 있었다.

이 서비스는 단순한 게시판이 아니어야 했다.
작품과 작가가 있고, 그 정보가 링크 하나로 외부에 공유될 수 있어야 했다.

누군가 특정 작품의 링크를 SNS에 붙여 넣었을 때, 그냥 밋밋한 URL 한 줄만 보이는 것이 아니라 작품 제목, 소개, 대표 이미지가 카드처럼 보여야 했다. 작가 페이지도 마찬가지였다. 링크 하나만으로도 “이 글이 무엇인지”, “누가 쓴 글인지”, “읽어볼 만한지”가 전달되어야 했다.

그래서 당시에는 서버에서 HTML을 만들어 내려주는 구조가 중요했다. ASP.NET MVC를 선택한 핵심 이유도 거기에 있었다. 페이지마다 제목, 설명, 이미지 같은 메타 정보를 서버에서 안정적으로 구성할 수 있었고, SNS나 검색엔진이 페이지를 읽을 때 필요한 정보를 비교적 명확하게 제공할 수 있었다.

지금 돌아보면 그 선택은 나름 합리적이었다.

문제는 시간이 지나면서 생겼다.

오래된 방식으로 계속 덧붙인 사이트

처음에는 ASP.NET MVC와 jQuery 조합이 익숙했다. 화면에서 필요한 부분을 찾아 값을 바꾸고, 버튼을 누르면 특정 영역을 보여주거나 숨기고, AJAX로 데이터를 가져와 다시 DOM에 붙이는 식이었다.

작은 기능을 만들 때는 빠르고 편했다.

하지만 기능이 늘어나자 점점 한계가 드러났다.
어느 버튼이 어떤 상태를 바꾸는지 추적하기 어려워졌고, 화면의 현재 상태와 코드의 상태가 따로 노는 느낌이 들기 시작했다. 기능을 하나 추가하면 다른 곳에서 예상하지 못한 문제가 생기기도 했다.

사이트도 느리게 느껴졌다.

정확히 말하면, jQuery 하나가 문제였다고 말하기는 어렵다. 성능 문제는 보통 하나의 원인으로 생기지 않는다. 오래된 구현 방식, 누적된 스크립트, 이미지와 리소스 최적화 부족, 서버 응답, 화면 구조 등이 함께 영향을 준다.

다만 분명한 것은 있었다.

메리톡톡은 내가 만들고 싶은 창작 공간의 모습과 점점 멀어지고 있었다.
글을 쓰고 싶은 공간이라기보다, 기능이 계속 붙은 관리형 웹사이트처럼 느껴졌다.

나는 메리톡톡을 다시 생각해야 했다.

Vue가 좋아서 시작한 Nuxt.js v2

나는 React보다 Vue를 더 좋아했다.

Vue의 문법은 직관적이었고, 컴포넌트를 작성하는 방식도 내게 더 자연스럽게 느껴졌다. 그래서 메리톡톡 v2를 구상하면서 Nuxt.js를 선택했다.

이 선택에도 이유가 있었다.

메리톡톡은 여전히 SEO와 공유 카드가 중요했다. 단순한 SPA로 만들면 화면은 현대적으로 만들 수 있을지 몰라도, 작품과 작가 페이지가 외부에서 공유될 때 메타 정보가 안정적으로 잡히지 않을 수 있었다.

Nuxt는 Vue 기반이면서도 SSR, 라우팅, 메타 태그 관리 같은 기능을 제공한다. 즉, 내가 좋아하는 Vue의 개발 경험을 유지하면서도 메리톡톡에 필요한 SEO 구조를 가져갈 수 있는 선택지처럼 보였다.

실제로 어느 정도까지는 잘 진행됐다.
화면도 이전보다 현대적으로 바뀌었고, 컴포넌트 구조도 정리되기 시작했다. “이번에는 제대로 다시 만들 수 있겠다”는 느낌도 있었다.

그런데 인증에서 문제가 생겼다.

인증서버와 OIDC, 그리고 예상보다 느렸던 로그인

메리톡톡은 별도의 인증서버를 사용한다.
서비스 자체에서 계정과 비밀번호를 직접 관리하기보다, 인증서버를 통해 로그인하고 토큰을 받아 사용하는 구조다.

기술적으로는 OIDC, 즉 OpenID Connect 기반의 인증 흐름이다.

비개발자에게 쉽게 말하면, 이런 구조다.

메리톡톡이 직접 “당신이 누구인지” 확인하는 것이 아니라, 인증을 담당하는 별도의 서버에 확인을 맡긴다. 사용자가 로그인하면 인증서버가 “이 사람은 정상적으로 로그인한 사용자다”라는 증명을 해주고, 메리톡톡은 그 결과를 바탕으로 사용자를 인식한다.

이 방식은 여러 서비스를 운영할 때 장점이 있다.
하나의 인증 체계를 여러 서비스에서 공유할 수 있고, 로그인 정책도 중앙에서 관리할 수 있다.

문제는 Nuxt.js로 구현한 v2에서 이 인증 흐름이 예상보다 느리게 느껴졌다는 점이다.

처음에는 인증서버가 느린 줄 알았다.
혹은 네트워크 문제일 수도 있다고 생각했다.
혹은 내가 코드를 잘못 작성했을 수도 있었다.

사실 지금도 Nuxt 자체의 문제였다고 단정할 수는 없다. 인증은 생각보다 많은 요소가 얽힌다. SSR 환경에서 세션을 어떻게 저장하는지, 토큰을 언제 검증하는지, 서버 미들웨어가 매 요청마다 어떤 일을 하는지, 인증서버와 몇 번 왕복하는지에 따라 체감 속도는 크게 달라질 수 있다.

그래서 나는 같은 인증 흐름을 Next.js에서 한번 구현해 보기로 했다.

결과는 의외였다.

Next.js에서는 같은 흐름이 훨씬 빠르고 안정적으로 느껴졌다.
적어도 내가 작성한 코드와 내 프로젝트 조건 안에서는 그랬다.

그 순간부터 고민이 시작됐다.

“내가 좋아하는 Vue와 Nuxt를 계속 붙잡아야 할까?”
“아니면 서비스 운영에 더 안정적으로 느껴지는 Next.js로 전환해야 할까?”

기술 취향보다 중요한 것

나는 원래 React보다 Vue를 선호했다.
그 취향은 지금도 크게 변하지 않았다.

하지만 메리톡톡은 내 취향을 증명하기 위한 프로젝트가 아니다.
사용자가 글을 쓰기 위해 들어오는 공간이다.

사용자는 내가 어떤 프레임워크를 좋아하는지 알 필요가 없다.
사용자는 로그인 후 바로 글을 쓸 수 있어야 하고, 작품 링크를 공유했을 때 자연스럽게 카드가 보여야 하며, 모바일에서도 불편하지 않게 접근할 수 있어야 한다.

결국 중요한 것은 기술의 이름이 아니라, 서비스가 사용자에게 어떤 경험을 제공하느냐였다.

그 기준으로 다시 보면 Next.js는 꽤 현실적인 선택지였다.

Next.js는 React 기반이라는 점에서 개인 취향과는 조금 거리가 있었지만, SSR, 동적 메타데이터, Open Graph 이미지, 라우팅, 서버 컴포넌트, 배포 생태계 측면에서 메리톡톡이 필요로 하는 조건과 잘 맞았다. Next.js는 App Router에서 페이지별 메타데이터를 구성할 수 있고, Open Graph 이미지도 정적 파일 또는 코드 기반으로 처리할 수 있다.

또 하나의 이유는 배포 선택지였다.

예전에는 Next.js를 특정 플랫폼에 강하게 묶인 기술처럼 느끼기도 했다. 하지만 최근에는 Cloudflare Workers에서 Next.js 앱을 운영하기 위한 가이드와 OpenNext 어댑터가 제공되고 있다. 물론 모든 기능이 모든 환경에서 아무 제약 없이 동작한다고 말할 수는 없지만, 예전보다 배포 선택지가 넓어진 것은 분명했다.

그렇게 나는 메리톡톡을 Next.js로 다시 만들기 시작했다.

결국 내가 지키고 싶었던 것

겉으로 보면 이 과정은 기술 스택의 변경처럼 보인다.

ASP.NET MVC에서 Nuxt.js로,
Nuxt.js에서 Next.js로.

하지만 내게 이 과정은 단순한 프레임워크 교체가 아니었다.

메리톡톡이 어떤 서비스여야 하는지 다시 확인하는 과정이었다.

처음 ASP.NET MVC를 선택했던 이유는 작품과 작가의 정보가 외부에 잘 전달되기를 바랐기 때문이다. 링크 하나만으로도 작품이 소개되고, 작가가 발견되고, 누군가의 글이 더 멀리 닿기를 바랐다.

Nuxt.js를 선택했던 이유는 더 현대적인 사용자 경험을 만들고 싶었기 때문이다. 오래된 방식의 화면에서 벗어나, 컴포넌트 기반으로 더 부드럽고 관리하기 쉬운 서비스를 만들고 싶었다.

Next.js로 전환한 이유는 결국 운영과 사용성의 균형 때문이었다. 로그인은 빨라야 하고, 글쓰기 화면은 안정적이어야 하며, 공유와 SEO는 여전히 중요했다.

그 과정에서 내가 지키고 싶었던 본질은 하나였다.

메리톡톡은 사용자가 글을 쓰고 싶어지는 공간이어야 한다.

화려한 AI 기능을 앞세우는 곳이 아니라,
정리되지 않은 생각도 일단 적을 수 있는 곳.

작품을 완성하지 않아도 초안을 남길 수 있고,
설정을 다 정하지 않아도 문장을 먼저 시작할 수 있고,
언젠가 그 글을 공유하고 싶어졌을 때 자연스럽게 외부로 전달될 수 있는 곳.

기술은 그 경험을 위해 존재해야 한다.

나는 여전히 완벽한 개발자는 아니다.
어떤 선택이 언제나 정답이었다고 말할 수도 없다.
ASP.NET MVC로 만들었던 첫 버전도, Nuxt.js로 만들던 v2도, Next.js로 다시 만들고 있는 지금도 각각의 이유와 한계가 있었다.

다만 이제는 조금 더 분명히 알고 있다.

내가 만들고 싶은 것은 단순히 “글쓰기 기능이 있는 웹사이트”가 아니다.
들어오자마자 한 문장을 쓰고 싶어지는 창작 공간이다.

그리고 메리톡톡의 기술 선택은 앞으로도 그 기준을 중심으로 바뀔 것이다.

사용자가 더 편하게 쓰고,
더 오래 머물고,
더 자기답게 문장을 이어갈 수 있다면.

그 선택이 지금의 메리톡톡에게는 가장 좋은 기술이라고 생각한다.

2026년 현재 React(SPA) 시작하기

Roslyn — Fri, 1 May 2026 16:34:32 +0900

1, 먼저 Typescript 기반으로 설치

npm create vite@latest my-modern-react -- --template react-ts

- 실행시 곧바로 http://localhost:5173 수행화면을 확인할 수 있다.

2. Tailwindcss 설치

npm install tailwindcss @tailwindcss/vite

3. Tailwindcss 설정


import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'
import tailwindcss from '@tailwindcss/vite'
import path from 'path'

export default defineConfig({
  plugins: [
    react(),
    tailwindcss(),
  ],
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
  // 개발 서버 설정 추가
  server: {
    port: 3030,
  },
})

4. src/index.css 파일을 수정

@import "tailwindcss";

5. 이제 npm run dev 로 실행해 보자.

2026년 프론트엔드 엔지니어링 시장의 패러다임 전환과 아키텍처 진화에 관한 심층 연구 보고서

Roslyn — Fri, 1 May 2026 15:43:52 +0900

2026년 프론트엔드 엔지니어링 시장의 패러다임 전환과 아키텍처 진화에 관한 심층 연구 보고서

전 세계 프론트엔드 개발 생태계는 2026년에 이르러 이른바 ‘피크 프레임워크(Peak Framework)’ 시대로 명명되는 성숙기에 진입했다.1 과거 새로운 라이브러리가 매달 등장하며 개발자들의 피로도를 높였던 혼란기는 종식되었으며, 이제 시장은 리액트(React)와 뷰(Vue), 앵귤러(Angular)라는 3대 거대 프레임워크를 중심으로 고착화된 안정성을 보이고 있다.1 이러한 안정성 이면에는 단순히 라이브러리의 선택을 넘어, 이를 어떤 메타 프레임워크 및 콘텐츠 인프라와 결합할 것인지가 기술 결정의 핵심 차별화 요소로 부상했다.1 본 보고서는 과거 리액트와 뷰를 경험했던 개발자가 현대의 시장에 다시 진입할 때 반드시 이해해야 할 기술적 단절과 새로운 표준, 그리고 배포 및 아키텍처 전략의 변화를 심도 있게 분석한다.

기술적 단절과 레거시의 재정의: CRA, Recoil, 그리고 Axios

최근 몇 년 사이 프론트엔드 생태계에서 가장 극적인 변화는 과거의 표준들이 대거 레거시(Legacy)로 분류되었다는 점이다. 이는 단순한 유행의 변화가 아니라, 웹 표준의 발전과 빌드 도구의 성능 혁신에 따른 필연적인 결과로 해석된다.

Create React App에서 Vite로의 빌드 패러다임 전환

과거 리액트 입문과 표준 프로젝트 구성을 담당했던 Create React App(CRA)은 이제 공식적으로 레거시 취급을 받으며, 신규 프로젝트에서는 거의 고려되지 않는다.2 CRA가 의존했던 웹팩(Webpack) 기반의 빌드 시스템은 프로젝트 규모가 커질수록 개발 서버 기동 속도와 핫 모듈 교체(HMR) 성능이 기하급수적으로 저하되는 고질적인 문제를 안고 있었다.3

이를 대체한 Vite는 브라우저에서 제공하는 네이티브 ES 모듈(ESM)을 활용하여 개발 서버 기동 시간을 수초 이내로 단축시켰다.3 대규모 모노레포 환경에서도 2초 미만의 콜드 스타트 속도를 보여주는 Vite는 95%라는 기록적인 개발자 만족도를 기록하며 사실상 리액트 단일 페이지 애플리케이션(SPA) 구축의 표준으로 자리 잡았다.2 이는 개발자가 코드를 수정하고 브라우저에 반영되는 시간을 밀리초(ms) 단위로 단축시킴으로써 생산성을 비약적으로 향상시켰다.4

Recoil의 몰락과 상태 관리 시장의 재편

사용자가 과거에 선호했던 Recoil은 현재 기술적 막다른 골목에 다다랐다. 2025년 1월 1일자로 Recoil 저장소는 공식적으로 아카이브(Archived) 처리되었으며, 더 이상의 기술 지원이나 업데이트는 기대할 수 없는 상태다.5 메타(Meta) 내부의 유지보수 인력 감축과 함께 리액트 18 및 19의 동시성 모드(Concurrent Mode) 변화에 대응하지 못한 것이 결정적인 패착으로 분석된다.5

Recoil이 개척했던 원자적(Atomic) 상태 관리 모델의 유산은 이제 Jotai가 이어받았다.5 한편, 시장의 전반적인 추세는 더욱 단순하고 직관적인 API를 제공하는 Zustand로 기울어졌다.9 Zustand는 리덕스(Redux)의 복잡한 보일러플레이트를 제거하면서도 Flux 패턴의 예측 가능성을 유지하여 중소규모는 물론 대규모 프로젝트에서도 주류로 사용되고 있다.8

Axios의 지위 변화와 웹 표준 우선주의

Axios 역시 과거의 독보적인 지위를 상당 부분 잃고 레거시 경계에 서 있다. 현대의 브라우저와 Node.js v18 이상 환경에서는 fetch API가 네이티브로 완벽하게 지원되면서, 추가적인 라이브러리 설치 없이도 안정적인 네트워크 요청이 가능해졌기 때문이다.12 특히 에지 컴퓨팅(Edge Computing)과 번(Bun), 데노(Deno)와 같은 최신 런타임 환경에서는 제로 번들 사이즈(Zero Bundle Size)를 지향하는 추세에 따라 네이티브 fetch가 더욱 선호된다.12

하지만 Axios가 완전히 사라진 것은 아니다. 대규모 엔터프라이즈 환경에서 요청/응답 인터셉터, 자동 JSON 변환, XSRF 보안 처리 등이 필요한 경우에는 여전히 Axios가 제공하는 안정적인 추상화 레이어가 유효하다.12 그럼에도 불구하고 현대적인 개발 스택에서는 fetch를 기반으로 한 경량 래퍼인 Ky나, 서버 상태 관리에 특화된 TanStack Query를 조합하는 방식이 권장된다.13

현대 프론트엔드 상태 관리의 아키텍처: Zustand, Immer, 그리고 Signals

상태 관리의 흐름은 이제 ‘어떻게 전역 상태를 저장할 것인가’에서 ‘어떻게 렌더링을 최적화하고 복잡한 불변성을 관리할 것인가’로 이동했다.

Zustand와 Immer의 조합이 주는 효용

현재 리액트 생태계에서 가장 추천되는 조합 중 하나는 Zustand와 Immer의 결합이다.16 Zustand는 훅(Hook) 기반의 간단한 API를 통해 스토어를 정의하며, Immer 미들웨어를 사용하면 불변성을 유지해야 하는 리액트의 상태 업데이트 로직을 마치 가변 객체를 수정하듯 직관적으로 작성할 수 있다.16

이 방식은 특히 중첩된 객체나 배열을 다룰 때 리덕스나 순수 Zustand에서 겪어야 했던 복잡한 스프레드 연산자 사용의 고통을 획기적으로 줄여준다.17 업계 전문가들은 리덕스의 엄격한 구조가 필요한 대규모 팀이 아니라면, 대부분의 프로젝트에서 Zustand가 최적의 균형점을 제공한다고 평가한다.11

신호(Signals)의 등장과 리액트 컴파일러의 미래

2026년 프론트엔드 시장에서 가장 뜨거운 논쟁 중 하나는 ‘신호(Signals)’ 기반의 반응성 모델이다.2 솔리드(SolidJS)나 프리액트(Preact)에서 대중화된 신호 모델은 값이 변경될 때 전체 컴포넌트를 다시 렌더링하는 대신, 해당 값을 사용하는 DOM 노드만을 정밀하게 업데이트한다.2

리액트 팀은 이러한 흐름에 대응하기 위해 ‘리액트 컴파일러(React Compiler, 구 React Forget)’를 전면에 내세웠다.2 이는 개발자가 수동으로 useMemo나 useCallback을 사용하여 렌더링을 최적화할 필요 없이, 컴파일 단계에서 자동으로 최적화된 코드를 생성하는 방식이다.2 이를 통해 리액트는 신호 모델이 가진 성능적 이점을 수용하면서도 기존의 선언적 프로그래밍 모델을 유지하려 하고 있다.2

주요 상태 관리 라이브러리 특성 비교

라이브러리	아키텍처 패러다임	주요 장점	권장 사용 사례
Zustand	중앙 집중식 Flux	최소한의 보일러플레이트, 단순한 API 8	전반적인 앱 상태 및 전역 설정 8
Jotai	원자적(Atomic)	정밀한 업데이트, 상향식 구성 8	복잡한 UI 상호작용 및 독립적 모듈 상태 8
Signals	세밀한 반응성(Fine-grained)	최상의 렌더링 성능, 직접적인 DOM 업데이트 11	고성능 데이터 시각화 및 실시간 업데이트 11
TanStack Query	서버 상태 동기화	자동 캐싱, 배경 업데이트, 상태 동기화 21	API 데이터 페칭 및 서버 데이터 관리 21

메타 프레임워크의 독주: Next.js와 Nuxt의 위상

사용자가 궁금해했던 "리액트와 뷰가 더 이상 선호되지 않는가"에 대한 답은 역설적이다. 리액트와 뷰는 그 어느 때보다 널리 사용되고 있지만, 이제는 독립적인 라이브러리가 아닌 Next.js나 Nuxt와 같은 메타 프레임워크의 ‘뷰 레이어’로서 기능하고 있다.19

프레임워크에서 플랫폼으로의 진화

Next.js는 리액트 생태계의 52.9%에 달하는 채택률을 기록하며 사실상 표준 프레임워크로 군림하고 있다.24 이는 단순한 라우팅 기능을 넘어, 서버 컴포넌트(RSC), 에지 런타임, 자동 이미지 최적화 등 웹 애플리케이션에 필요한 모든 인프라를 추상화하여 제공하기 때문이다.23 뷰 진영의 Nuxt 역시 Nuxt 4 출시와 함께 더욱 정교해진 데이터 페칭 시스템과 서버 사이드 렌더링(SSR) 최적화를 통해 강력한 풀스택 경험을 제공하고 있다.25

현대 개발자들에게 리액트나 뷰만을 사용하여 SPA를 구축하는 것은 특수한 경우(사내 대시보드, 강력한 인증이 필요한 폐쇄형 앱 등)를 제외하고는 드문 일이 되었다.3 대부분의 B2C 서비스나 SEO가 중요한 프로젝트는 초기부터 Next.js나 Nuxt를 기반으로 시작하는 것이 당연한 선택으로 여겨진다.3

SPA 방식의 가치와 선택 기준

그렇다고 해서 SPA 방식이 폐기된 것은 아니다. Vite를 기반으로 한 순수 리액트/뷰 SPA는 여전히 특정 영역에서 강력한 경쟁력을 가진다.3

SEO가 불필요한 경우: 로그인이 필수적인 대시보드나 내부 툴은 SSR의 복잡성을 감수할 이유가 없다.3
개발 속도와 단순함: Vite의 HMR 속도는 여전히 Next.js의 터보팩(Turbopack)보다 빠르며, 복잡한 서버 가이드라인 없이 순수 클라이언트 로직에 집중할 수 있다.3
배포 유연성: 정적 파일(HTML/JS/CSS)로 빌드되어 S3나 GitHub Pages 등 어디에나 쉽게 배포할 수 있는 장점이 있다.4

Next.js의 배포 이슈와 Vercel 종속성 탈피

사용자가 지적한 "Vercel 이외의 배포 환경에서의 설정 이슈"는 Next.js 16.2 버전에 이르러 획기적인 전환점을 맞이했다.29

Adapter API를 통한 인프라 독립성 확보

과거 Next.js는 Vercel 플랫폼에서만 작동하는 비공개 API나 최적화 기능들로 인해 타 플랫폼 배포 시 ISR(Incremental Static Regeneration)이나 에지 미들웨어 설정에 어려움이 많았다.3 하지만 2025년 말 도입된 공식 ‘어댑터 API(Adapter API)’는 Next.js의 빌드 출력을 표준화된 규격으로 제공하여 AWS, Cloudflare, Netlify 등 어떤 환경에서도 프레임워크의 모든 기능을 동일하게 사용할 수 있도록 보장한다.29

Vercel의 자체 어댑터조차 이제는 이 공개 API를 기반으로 작동하며, 이는 특정 호스팅 업체에 대한 종속성을 제거하겠다는 리액트 재단과 메타의 강력한 의지가 반영된 결과다.29

AWS 환경에서의 배포 전략

AWS를 선호하는 기업들을 위해 OpenNext와 같은 오픈소스 프로젝트가 성숙해졌으며, 이를 통해 AWS Lambda나 ECS 환경에서도 Next.js의 복잡한 서버 기능을 완벽하게 구현할 수 있게 되었다.30

AWS Lambda: 트래픽에 따른 자동 스케일링과 비용 효율성이 중요한 경우 선호된다.33
AWS ECS/Fargate: 컨테이너 기반의 제어가 필요하거나, 백엔드 서비스와 동일한 네트워크 환경 내에 위치시켜야 하는 대규모 엔터프라이즈 앱에 적합하다.33

2026년 리액트 프로젝트의 권장 기술 스택

다시 리액트를 시작한다면, 다음과 같은 구성이 가장 현대적이고 유지보수가 용이한 ‘골든 스택’으로 추천된다.

메인 프레임워크: Next.js 15+ (App Router 기반) 또는 Vite + React Router 7 (순수 SPA 필요 시).2
프로그래밍 언어: TypeScript. 이제 JS만으로 작성된 대형 프로젝트는 거의 없으며, 타입 안정성은 AI 코드 생성 도구와의 협업에서도 필수적이다.15
상태 관리:

서버 상태: TanStack Query. API 호출, 캐싱, 에러 처리를 위한 필수 라이브러리다.21
클라이언트 상태: Zustand + Immer. 전역 UI 상태 관리에 가장 가볍고 강력하다.16

스타일링: Tailwind CSS. 유틸리티 퍼스트 접근법은 이제 업계의 표준이 되었으며, 스타일 충돌 방지와 생산성 측면에서 압도적이다.15
UI 컴포넌트: shadcn/ui. 라이브러리를 직접 설치하는 대신 소스 코드를 프로젝트에 직접 포함시켜 자유롭게 커스터마이징하는 방식이 대세다.35
데이터 페칭: Native Fetch 기반의 래퍼(Ky 등) 또는 프로젝트 규모에 따라 Axios 선별적 사용.13
테스트 및 린팅: Vitest (빠른 유닛 테스트), Playwright (신뢰성 높은 E2E 테스트), Biome 또는 ESLint + Prettier.15

결론: 프론트엔드 엔지니어의 새로운 지향점

2026년의 프론트엔드 시장은 더 이상 어떤 도구가 ‘최고’인지를 두고 다투지 않는다. 대신, 비즈니스의 목적에 따라 아키텍처를 선택하는 엔지니어링 역량이 중시된다. 과거에 선호했던 Vue와 Recoil의 경험은 이제 Nuxt와 Jotai/Zustand라는 더 성숙한 도구로 전이되었으며, SSR과 SPA의 경계는 Next.js와 같은 메타 프레임워크 안에서 하이브리드 형태로 통합되었다.3

특히 Next.js의 배포 유연성 확보와 리액트 컴파일러의 도입은 향후 몇 년간 프론트엔드 개발의 복잡성을 낮추고 성능을 상향 평준화할 것으로 기대된다. 또한, Rust 기반의 도구 체인(VoidZero 등)과 웹 어셈블리(Wasm)의 성숙은 프론트엔드가 단순한 UI 구현을 넘어 고성능 컴퓨팅 영역으로 확장되고 있음을 보여준다.19 이제 개발자는 특정 라이브러리의 문법을 익히는 것을 넘어, 서버와 클라이언트 사이의 데이터 흐름을 최적화하고 사용자 경험을 극대화하는 아키텍트로서의 역할을 요구받고 있다..1

참고 자료

State of JavaScript 2025-2026: Key Takeaways for Modern Web Development Teams, 5월 1, 2026에 액세스, https://strapi.io/blog/state-of-javascript-2025-key-takeaways
React Stack Patterns - Patterns.dev, 5월 1, 2026에 액세스, https://www.patterns.dev/react/react-2026/
Vite vs Next.js: Complete Comparison for React Developers (2026) - DesignRevision, 5월 1, 2026에 액세스, https://designrevision.com/blog/vite-vs-nextjs
Next.js vs Vite: Choosing the Right Tool in 2026 - DEV Community, 5월 1, 2026에 액세스, https://dev.to/shadcndeck_dev/nextjs-vs-vite-choosing-the-right-tool-in-2026-38hp
The Recoil repository has been archived on Jan 1, 2025. You had a good run. - Reddit, 5월 1, 2026에 액세스, https://www.reddit.com/r/reactjs/comments/1huhqhm/the_recoil_repository_has_been_archived_on_jan_1/
Goodbye Recoil, Hello Speed: Why Our React App Got 40% Faster in 2025 | by Sameer Makwana | Medium, 5월 1, 2026에 액세스, https://medium.com/@sameermakwana07/goodbye-recoil-hello-speed-why-our-react-app-got-40-faster-in-2025-602de0690c3d
I Upgraded Three Apps to React 19. Here's What Broke. | by Zoe - Medium, 5월 1, 2026에 액세스, https://medium.com/@quicksilversel/i-upgraded-three-apps-to-react-19-heres-what-broke-648087c7217b
Jotai vs Zustand: Which React State Library is Better? - Zignuts Technolab, 5월 1, 2026에 액세스, https://www.zignuts.com/blog/jotai-vs-zustand-react-state-guide
Is Recoil still actively maintained or used at Meta? : r/reactjs - Reddit, 5월 1, 2026에 액세스, https://www.reddit.com/r/reactjs/comments/15tseap/is_recoil_still_actively_maintained_or_used_at/
Zustand vs Jotai vs Valtio: Performance Guide 2025 - React Libraries, 5월 1, 2026에 액세스, https://www.reactlibraries.com/blog/zustand-vs-jotai-vs-valtio-performance-guide-2025
State Management in 2026: Zustand vs Jotai vs Redux Toolkit vs Signals - DEV Community, 5월 1, 2026에 액세스, https://dev.to/jsgurujobs/state-management-in-2026-zustand-vs-jotai-vs-redux-toolkit-vs-signals-2gge
Axios vs Fetch: Which Should You Use in 2026? - IPRoyal.com, 5월 1, 2026에 액세스, https://iproyal.com/blog/axios-vs-fetch/
Saying Goodbye to Axios in 2026: A Simpler Way to Make API Calls - Medium, 5월 1, 2026에 액세스, https://medium.com/@avi2y07111999/saying-goodbye-to-axios-in-2026-a-simpler-way-to-make-api-calls-9e5a2e23a1b9
Axios vs Fetch: Which HTTP Client to Choose in JS? - Scrapfly Blog, 5월 1, 2026에 액세스, https://scrapfly.io/blog/posts/axios-vs-fetch
Senior React Devs: What stack would you choose for a large-scale production app in 2026?, 5월 1, 2026에 액세스, https://www.reddit.com/r/react/comments/1s3a0o2/senior_react_devs_what_stack_would_you_choose_for/
Immer middleware - Zustand, 5월 1, 2026에 액세스, https://zustand.docs.pmnd.rs/reference/integrations/immer-middleware
Why doesn't Zustand incorporate Immer for a cleaner API? #738 - GitHub, 5월 1, 2026에 액세스, https://github.com/pmndrs/zustand/discussions/738
Zustand: A Guide to Scalable State Management | by Ram Krishnan - Medium, 5월 1, 2026에 액세스, https://beyondthecode.medium.com/zustand-a-guide-to-scalable-state-management-0186c4208e01
Trends That Defined JavaScript in 2025 - The New Stack, 5월 1, 2026에 액세스, https://thenewstack.io/trends-that-defined-javascript-in-2025/
Zustand, Jotai, and Signals: A Head-to-Head Comparison of Granularity and Efficiency | by Rohit Imandi, 5월 1, 2026에 액세스, https://rohitimandi.medium.com/zustand-jotai-and-signals-a-head-to-head-comparison-of-granularity-and-efficiency-077599a4f68e
HTTP Requests in React(fetch vs Axios and Tanstack Query) - DEV Community, 5월 1, 2026에 액세스, https://dev.to/alifa_ara_heya/http-requests-in-react-10jk
9 Libraries for React Developers: Boost Your Productivity in 2025 - SVAR UI, 5월 1, 2026에 액세스, https://svar.dev/blog/react-libraries-for-productivity/
React vs. Next.js: A 2026 Developer's Guide to Differences and Use Cases | SaM Solutions, 5월 1, 2026에 액세스, https://sam-solutions.com/blog/react-vs-nextjs/
Top Frameworks for JavaScript App Development in 2025 - Strapi, 5월 1, 2026에 액세스, https://strapi.io/blog/frameworks-for-javascript-app-developlemt
Best Vue.js development companies of 2026, 5월 1, 2026에 액세스, https://suggestron.com/top-vue-js-development-companies/
Nuxt 4 is here: A Deep Dive into the New Features and What They Mean for Developers, 5월 1, 2026에 액세스, https://www.blueshoe.io/blog/nuxt4-new-features/
Nuxt 4.4 · Nuxt Blog, 5월 1, 2026에 액세스, https://nuxt.com/blog/v4-4
Vite vs Next.js: A Comprehensive Comparison - TatvaSoft Blog, 5월 1, 2026에 액세스, https://www.tatvasoft.com/outsourcing/2026/01/vite-vs-next-js.html
Next.js Across Platforms: Adapters, OpenNext, and Our Commitments, 5월 1, 2026에 액세스, https://nextjs.org/blog/nextjs-across-platforms
3 Years of OpenNext - OpenNext, 5월 1, 2026에 액세스, https://opennext.js.org/news/2026-03-25-3-years-of-opennext
OpenNext - OpenNext, 5월 1, 2026에 액세스, https://opennext.js.org/
Comparison - OpenNext, 5월 1, 2026에 액세스, https://opennext.js.org/aws/comparison
Deploying Next.js Apps on AWS: A Complete Step-by-Step Guide - Business Compass LLC, 5월 1, 2026에 액세스, https://blogs.businesscompassllc.com/2026/01/deploying-nextjs-apps-on-aws-complete.html
How to Deploy a Next.js App to AWS with ECS - OneUptime, 5월 1, 2026에 액세스, https://oneuptime.com/blog/post/2026-02-12-deploy-nextjs-app-to-aws-with-ecs/view
The React + AI Stack for 2026 - Builder.io, 5월 1, 2026에 액세스, https://www.builder.io/blog/react-ai-stack-2026
Senior React Devs: What stack would you choose for a large-scale production app in 2026?, 5월 1, 2026에 액세스, https://www.reddit.com/r/nextjs/comments/1s3a0xx/senior_react_devs_what_stack_would_you_choose_for/
30+ Best Shadcn Components List for React and Next.js - WrapPixel, 5월 1, 2026에 액세스, https://www.wrappixel.com/shadcn-components/
Nuxt 4 Performance Optimization: Complete Guide to Faster Apps in 2026, 5월 1, 2026에 액세스, https://masteringnuxt.com/blog/nuxt-4-performance-optimization-complete-guide-to-faster-apps-in-2026
Frontend Development Trends for 2025 - Rootstack, 5월 1, 2026에 액세스, https://rootstack.com/en/blog/frontend-development-trends-2025

Next.js 프로젝트 기본 셋팅

Roslyn — Wed, 8 May 2024 12:07:31 +0900

1. 프로젝트를 생성합니다.

npx create-next-app@latest

2. 다음과 같이 설정합니다.

What is your project named? my-app
Would you like to use TypeScript? Yes
Would you like to use ESLint? Yes
Would you like to use Tailwind CSS?  Yes
Would you like to use `src/` directory?  Yes
Would you like to use App Router? (recommended)  Yes
Would you like to customize the default import alias (@/*)?  Yes

3. 기본 라이브러리를 설치해 줍니다.

npm i

4. 실행하여 설치된 라이브러리가 문제가 없는지 확인합니다.

npm run dev

Next.js가 localhost:3000 에서 실행된 모습

5. nextauth 5(beta) 를 설치합니다.

npm i next-auth@5.0.0-beta.16

C#.net Core로 윈도우 서비스 만들기

Roslyn — Sun, 21 Apr 2024 20:21:14 +0900

먼저 Cmd에서 다음 명령어로 프로젝트를 생성합니다.

dotnet new worker --name <Project.Name>

그런 다음 WIndowsServices 라이브러리를 설치해 줍니다.

dotnet add package Microsoft.Extensions.Hosting.WindowsServices

이제 프로젝트 기본으로 주어지는 Worker.cs 파일을 WindowsBackgroundService.cs 파일로 교체합니다.

namespace App.WindowsService;

public sealed class WindowsBackgroundService(
    WorkService workService,
    ILogger<WindowsBackgroundService> logger) : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        try
        {
            while (!stoppingToken.IsCancellationRequested)
            {
                string test = workService.GetWork();
                logger.LogWarning("{test}", test);

                await Task.Delay(TimeSpan.FromMinutes(1), stoppingToken);
            }
        }
        catch (Exception ex)
        {
            logger.LogError(ex, "{Message}", ex.Message);
            Environment.Exit(1);
        }
    }
}

이제 실제로 작업을 수행할 WorkService.cs 파일을 만들어 줍니다.

namespace App.WindowsService;

public sealed class WorkService
{
    public string GetWork()
    {
        return "hello world";
    }
}