docs(blog): 비시리즈 글 문체와 구조 개편

비시리즈 Engineering/Life 글의 본문을 낮은 톤 해요체로 정리했어요.
도입과 전환, 정리 문장을 다시 구성해서 첫 화면의 문제 제기와 읽기 보상이 보이도록 맞췄어요.

Author: dev-wooyeon

posts/2025년-회고/index.mdx

@@ -1,4 +1,3 @@
-![](/images/posts/2025년-회고/4daf7765b912.jpg)
 2025년, 저는 많은 것들을 내려놓았어요.
 
 게임을 지웠고,
@@ -10,8 +9,10 @@
 데이터 엔지니어라는 명확한 목표,
 그리고 천천히 오래 달리는 방법.
 
-이 회고에서는
-방향을 찾아가는 한 개발자의 이야기를 담았어요.
+이 회고에서는 가족, 일, 학습이 제 선택 기준을 어떻게 바꿨는지 정리해요.
+버린 것과 얻은 것이 2026년의 방향에 어떤 기준을 남겼는지도 함께 적어보려고 해요.
+
+![](/images/posts/2025년-회고/4daf7765b912.jpg)
 
 ## 개인
 
@@ -22,7 +23,7 @@
 
 자연스럽게 찾아와 준 생명이 너무 감사했고,
 임신 기간 동안 고생할 와이프를 떠올리니
-기쁨과 걱정이 동시에 밀려오더라고요. 묘한 감정이었죠.
+기쁨과 걱정이 동시에 밀려왔어요. 묘한 감정이었죠.
 
 조금이라도 도움이 되고 싶어서
 하루에 5분씩 책을 읽어주는 태교를 시작했어요.
@@ -31,7 +32,7 @@
 2025년 5월 2일 오후 2시 12분,
 38주 차에 3.12kg로 건강하게 태어났어요.
 
-처음 만났을 때 아기는 생각보다 컸거든요.
+처음 만났을 때 아기는 생각보다 컸어요.
 '이만한 아기가 어떻게 엄마 뱃속에 있었지?'
 와이프가 뒤뚱뒤뚱 걷던 날들이 겹쳐보이며 신기했죠.
 
@@ -64,7 +65,7 @@
 
 그 시간에 가족과 더 시간을 보내거나
 책을 읽거나 기술 트렌드를 공부하는 편이
-훨씬 낫겠다는 판단이 섰거든요.
+훨씬 낫겠다는 판단이 들었어요.
 
 그걸 깨달은 날,
 모든 게임을 한 번에 삭제하고 데스크탑은 당근행.
@@ -83,12 +84,12 @@
 
 지금 생각해보면
 준비 없이 무턱대고 던진 도전이었어요.
-기업 분석도, 강점 정리도, 전달 전략도 부족했거든요.
+기업 분석도, 강점 정리도, 전달 전략도 부족했어요.
 
 그러다 카카오 개발자 오픈채팅방에서 딱구님이 공유해주신
 유스방 6기 모집 공고를 보게 됐어요.
 처음에는 이런게 있구나 정도로 말았는데,
-마지막 접수날까지 공유해주시길래 지금 이걸 안쓰면 후회할것 같더라고요. 와이프와 논의 후 지원하기로 했죠.
+마지막 접수날까지 공고가 계속 눈에 밟혔어요. 지금 쓰지 않으면 후회할 것 같아서 와이프와 논의한 뒤 지원하기로 했죠.
 
 "기술 학습"이 아니라
 **'전문가로 성장하기 위한 커리큘럼'**이라는 점이 매력적이었어요.
@@ -112,7 +113,7 @@
 
 "이건 정말 나를 찾는 포지션인데…"
 싶은 공고에도 서류에서 걸리는 이유가
-아마도 이 문제였지 않았을까 싶더라고요.
+아마도 이 문제가 컸지 않았을까 싶었어요.
 
 🧐 학사 학위..
 
@@ -138,7 +139,7 @@
 - 🔗 [소프트웨어 장인 – 프로페셔널리즘과 실용주의](https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=66925855)
 - 🔗 [함께 자라기 – 일과 삶의 통찰](https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=175977462)
 
-데이터 엔지니어 전환을 목표로 빅데이터를 지탱하는 기술, 견고한 시스템 엔지니어링도 읽었고요.
+데이터 엔지니어 전환을 목표로 빅데이터를 지탱하는 기술, 견고한 시스템 엔지니어링도 읽었어요.
 
 이 책들 이외에도 올해만 8권 이상을 읽었는데,
 내년 목표는 월 1권(12권).
@@ -160,7 +161,7 @@ Kafka, MSA, DDD, 테스트 코드, 아키텍처 설계.
 
 영상 도메인도 처음 경험했는데,
 H.264, MPEG-4 같은 영상·음성 개념을 처음 제대로 다뤄봤고
-프로덕션 설계까지 이어진 경험은 큰 자극이 되더라고요.
+프로덕션 설계까지 이어진 경험은 큰 자극이 됐어요.
 https://ieunune.notion.site/31b67939243941038e4b373418153217
 
 병목구간이나 비효율적인 코드를 찾아
@@ -173,7 +174,7 @@ https://ieunune.notion.site/31b67939243941038e4b373418153217
 데이터 엔지니어 직무를 새롭게 보게 됐어요.
 
 통계, 스트리밍, 자동화.
-회사 시스템에서도 충분히 도전해볼 수 있겠다는 생각이 들더라고요.
+회사 시스템에서도 충분히 도전해볼 수 있겠다는 생각이 들었어요.
 
 DMS(CDC) → S3(Storage) → Glue(Catalog) → 팩트/디멘전 테이블 설계까지
 시니어 개발자 분과 함께 PoC를 진행하며
@@ -190,7 +191,7 @@ DMS(CDC) → S3(Storage) → Glue(Catalog) → 팩트/디멘전 테이블 설계
 유스콘 25에 멘토로 참석해 AI를 활용한 비용 0원 학습법을 공유하는 세션을 진행했어요.
 멘티분이 집중해서 들어주신 덕분에 준비한 내용을 잘 전달할 수 있었고요.
 
-발표도 유익했고 듣는 분들의 반응도 좋더라고요.
+발표도 유익했고 듣는 분들의 반응도 좋았어요.
 현장의 열기에서 받은 자극을 에너지 삼아 미뤄왔던 이력서 지원까지 마무리.
 
 <img src="/images/posts/2025년-회고/09d119da2b00.png" />

posts/ai-시대-개발-환경-고정/index.mdx

@@ -12,12 +12,13 @@
 - 선택 자체가 또 하나의 업무가 돼요
 
 결국 생산성은 코드가 아니라 **선택 피로**에서 먼저 깎였어요.
+그래서 이 글에서는 무엇을 고정했고 무엇은 일부러 열어뒀는지, 제 개발 환경을 유지하는 기준을 함께 정리해요.
 
 ---
 
 ## 2. 문제를 어떻게 정의했는가
 
-처음에는 "더 좋은 도구를 찾으면 해결된다"고 생각했어요.
+처음에는 "더 좋은 도구를 찾으면 해결된다"고 여겼어요.
 실제로 모델, IDE 플러그인, 코딩 에이전트를 꽤 많이 바꿔봤어요.
 
 하지만 반복 실험 끝에 결론은 반대였어요.

posts/ai-시대-학습법/index.mdx

@@ -7,16 +7,17 @@ AI 시대에는 답을 빨리 찾는 것보다 질문을 만들고 검증하는
 고졸 출신으로 OpenAI 연구원이 된 가브리엘 피터슨의 이야기였어요.
 
 제가 더 크게 본 건 화려한 커리어보다 학습 순서였어요.  
-기초를 완벽하게 쌓은 뒤에 움직이기보다, 일단 프로젝트를 만들고, 막히는 개념을 끝까지 파고들고, 다시 구현으로 돌아와 이해를 확인하는 방식이었거든요.
+기초를 완벽하게 쌓은 뒤에 움직이기보다, 먼저 프로젝트를 만들고, 막히는 개념을 끝까지 파고든 뒤 다시 구현으로 돌아와 이해를 확인하는 방식이었어요.
 
 돌아보면 저도 꽤 오래 비슷하게 배워왔어요.  
-지금은 그 흐름을 조금 더 또렷하게 설명할 수 있어요.
+그런데 이 흐름을 설명하지 못하면 반복은 남아도 기준은 남지 않아요.
 
 - 먼저 실습해요.
 - 그다음 이론으로 기준을 붙잡아요.
 - 다시 실습으로 돌아가 이해를 검증해요.
 
 이 글에서는 이 세 단계가 왜 제 학습의 중심이 됐는지, 왜 AI 시대에 더 강해졌는지, 실제로 어떤 장면에서 돌아가는지 정리해보려고 해요.
+이 순서를 따라가면 질문 설계가 왜 중요한지, 그리고 실무에서는 어떤 기준으로 검증해야 하는지까지 한 번에 볼 수 있어요.
 
 ---
 
@@ -46,7 +47,7 @@ AI 시대에는 답을 빨리 찾는 것보다 질문을 만들고 검증하는
 저는 배울 때 준비가 다 끝날 때까지 기다리지 않아요.  
 대신 결과물부터 만들어요.
 
-그래야 제가 뭘 모르는지 바로 드러나거든요.  
+그래야 제가 뭘 모르는지 바로 드러나요.
 어디서 막히는지, 무엇이 애매한지, 어떤 판단이 비어 있는지가 손에 잡혀요.
 
 [`기술 블로그를 일주일 만에 만들 수 있었던 것`](/blog/blog-system-building)도 같은 흐름이었어요.  
@@ -74,7 +75,7 @@ AI 시대에는 답을 빨리 찾는 것보다 질문을 만들고 검증하는
 ## 공식 문서로 기준을 붙잡아요
 
 질문이 생긴 뒤에야 이론이 오래 남아요.  
-그때부터는 "왜 이게 이렇게 돌아가지?"를 설명할 수 있어야 하거든요.
+그때부터는 "왜 이게 이렇게 돌아가지?"를 설명할 수 있어야 해요.
 
 저는 그 지점에서 강의보다 공식 문서로 들어가요.  
 읽기 어렵더라도 결국 기준이 되는 문장은 공식 문서 안에 있다고 믿기 때문이에요.
@@ -86,7 +87,7 @@ AI 시대에는 답을 빨리 찾는 것보다 질문을 만들고 검증하는
 모르는 단어를 다시 찾고, 관련 개념을 옆으로 넓히고, 예제를 복기하면서 문장을 제 것으로 바꿔요.
 
 Redis나 Flink처럼 실무에서 자주 마주치거나 앞으로 더 깊게 써야 할 기술은 특히 이런 방식으로 붙잡아요.  
-작동은 시킬 수 있어도, 왜 그렇게 동작하는지 설명하려고 하면 말이 막히는 순간이 오거든요.
+작동은 시킬 수 있어도, 왜 그렇게 동작하는지 설명하려고 하면 말이 막히는 순간이 와요.
 
 그 간격을 메울 때 AI도 큰 도움이 돼요.  
 다만 저는 AI를 정답지보다 해설가에 가깝게 써요. 문서에서 읽은 추상 개념을 더 잘 이해하도록 질문을 던지는 도구로 써요.
@@ -117,7 +118,7 @@ Redis나 Flink처럼 실무에서 자주 마주치거나 앞으로 더 깊게 
 그런데 읽었다와 이해했다 사이에는 늘 간격이 남아요.
 
 그래서 다시 결과물로 돌아가요.  
-정말 제 것이 됐는지는 다시 만들어보면 바로 드러나거든요.
+정말 제 것이 됐는지는 다시 만들어보면 바로 드러나요.
 
 이론을 읽은 뒤에 구현으로 다시 들어가면 처음에는 보이지 않던 구조가 보여요.  
 예전에는 "일단 돌아가니까 됐다"에서 멈춘 적이 많았는데, 지금은 그 상태를 오래 두지 않으려고 해요.
@@ -150,10 +151,11 @@ Redis나 Flink처럼 실무에서 자주 마주치거나 앞으로 더 깊게 
 UIUX, 디자인, 프론트엔드, 백엔드, 데이터, 인프라를 두루 건드렸지만 어느 하나를 학교 커리큘럼처럼 체계적으로 깊게 밟아온 건 아니었어요.
 
 그 시기에는 이게 종종 약점처럼 느껴졌어요.  
-넓게는 아는데, 왜 그런지 설명하려고 하면 허전한 구간이 보였거든요.
+넓게는 아는데, 왜 그런지 설명하려고 하면 허전한 구간이 보였어요.
 
 그런데 AI가 생긴 뒤 이 경험의 의미가 달라졌어요.  
-여러 영역을 조금이라도 밟아본 사람은 문제의 좌표를 빨리 잡아요. 이게 디자인의 문제인지, 구조의 문제인지, 데이터 흐름의 문제인지, 운영 방식의 문제인지 감을 빠르게 잡을 수 있거든요.
+여러 영역을 조금이라도 밟아본 사람은 문제의 좌표를 더 빨리 잡아요.
+디자인 문제인지, 구조 문제인지, 데이터 흐름 문제인지, 운영 방식 문제인지 먼저 구분할 수 있기 때문이에요.
 
 AI는 바로 그다음 단계에서 큰 힘을 발휘해요.  
 이미 밟아본 지형 위에서 빠진 이론과 세부 개념을 훨씬 빠르게 메워주기 때문이에요.
@@ -173,26 +175,26 @@ AI는 바로 그다음 단계에서 큰 힘을 발휘해요.
 요즘은 글쓰기 자체도 이 루프로 다시 배우고 있어요.  
 글맛이 좋다고 느껴지는 글을 만나면 그냥 "잘 쓴다"에서 멈추지 않아요.
 
-어디서 독자의 질문을 붙잡는지, 어디서 글의 범위를 먼저 잡아주는지, 왜 중간 요약과 비유가 끝까지 읽게 만드는지 구조를 뜯어봐요.  
+어디서 독자의 질문을 붙잡는지, 어디서 글의 범위를 먼저 잡아주는지, 왜 중간 요약과 비유가 끝까지 읽게 만드는지 구조를 살펴봐요.
 최근에는 테오의 연재 글을 읽으면서 그 패턴이 더 선명하게 보였어요.
 
-독자 질문으로 문을 열고, 프롤로그로 범위를 잡고, 초반에 로드맵을 깔고, 예시와 비유로 설명한 뒤, 중간 요약과 마지막 질문으로 글을 회수하더라고요.
+독자 질문으로 문을 열고, 프롤로그로 범위를 잡고, 초반에 로드맵을 깔고, 예시와 비유로 설명한 뒤, 중간 요약과 마지막 질문으로 글을 회수하는 구조였어요.
 
 그걸 보면서 글맛이 좋다는 건 결국 문장이 예쁜 것만은 아니라는 생각도 했어요.  
-독자가 길을 잃지 않게 계속 안내하는 힘, 그래서 끝까지 읽게 만드는 구조가 함께 있어야 하더라고요.
+독자가 길을 잃지 않게 계속 안내하는 힘, 그래서 끝까지 읽게 만드는 구조가 함께 필요하다는 걸 배웠어요.
 
 저도 이걸 그대로 흉내 내기보다, 제 글에 맞는 방식으로 배우고 적용해보려고 해요.  
-소제목은 목차 역할을 하게 두고, 질문은 본문 안에서 독자와 호흡을 만드는 데 쓰는 쪽이 저한테 더 잘 맞는다고 느껴요.
+소제목은 목차 역할을 하게 두고, 질문은 본문 안에서 독자의 사고를 붙잡는 데 쓰는 방식이 저한테 더 잘 맞았어요.
 
 > **Tip. 글맛이 좋은 글을 읽을 때 제가 보는 기준**
 >
-> - 첫 화면에서 독자의 질문을 바로 붙잡는지 봐요.
-> - 초반에 이 글의 범위와 흐름을 먼저 알려주는지 봐요.
-> - 추상적인 개념을 비유나 사례로 내려주는지 봐요.
-> - 중간마다 `정리:` 같은 표지판으로 길을 다시 보여주는지 봐요.
-> - 마지막에 독자에게 다시 말을 걸며 생각을 남기는지 봐요.
+> - 첫 화면에서 독자의 질문을 바로 붙잡는지
+> - 초반에 이 글의 범위와 흐름을 먼저 알려주는지
+> - 추상적인 개념을 비유나 사례로 내려주는지
+> - 중간마다 `정리:` 같은 표지판으로 길을 다시 보여주는지
+> - 마지막에 독자에게 다시 말을 걸며 생각을 남기는지
 
-좋은 글을 읽고 구조를 분해하고, 제 글에 다시 적용해보면서 이해를 검증하는 일도 결국 같은 학습이라고 느껴요.
+좋은 글을 읽고 구조를 분해하고, 제 글에 다시 적용해보면서 이해를 검증하는 일도 결국 같은 학습이라고 생각해요.
 
 **정리: 글쓰기도 결과물을 읽고, 구조를 이해하고, 다시 제 방식으로 적용해보는 학습이에요.**
 
@@ -201,7 +203,7 @@ AI는 바로 그다음 단계에서 큰 힘을 발휘해요.
 ## 실제로는 이렇게 돌아가요
 
 추상적으로만 말하면 그럴듯하게 들릴 수 있어요.  
-그래서 이번에는 실제로 제 학습 루프가 어떻게 돌았는지, 두 장면으로 나눠서 적어볼게요.
+그래서 이번에는 실제로 제 학습 루프가 어떻게 돌았는지, 두 장면으로 나눠서 적어보려고 해요.
 
 ### 사례 1. 기술 블로그를 만들 때
 
@@ -212,7 +214,7 @@ AI는 바로 그다음 단계에서 큰 힘을 발휘해요.
 Next.js App Router를 어떤 경계로 나눌지, MDX 콘텐츠를 어떻게 읽어올지, 목차와 읽기 진행도를 어떤 식으로 붙일지, 전부 손으로 부딪히며 알아갔어요.
 
 이 지점에서 먼저 꺼내 쓴 건 프론트엔드 감각이었어요.  
-어떤 화면이 읽기 편한지, 어떤 인터랙션이 과한지, 어떤 디자인이 글의 집중을 깨는지는 경험적으로 어느 정도 알고 있었거든요.
+어떤 화면이 읽기 편한지, 어떤 인터랙션이 과한지, 어떤 디자인이 글의 집중을 깨는지는 경험적으로 어느 정도 알고 있었어요.
 
 하지만 감각만으로는 오래 못 가요.  
 그래서 공식 문서와 레퍼런스를 다시 읽고, AI에게 계속 반문했어요.
@@ -231,7 +233,7 @@ Next.js App Router를 어떤 경계로 나눌지, MDX 콘텐츠를 어떻게 읽
 ### 사례 2. 공식 문서를 번역하고 시리즈로 이어갈 때
 
 Redis나 Flink처럼 실무에서 계속 마주치는 기술은 이상하게도 "쓴다"와 "안다" 사이에 큰 간격이 있어요.  
-작동은 시킬 수 있는데, 왜 그렇게 동작하는지 설명하려고 하면 갑자기 말이 막히는 순간이 오거든요.
+작동은 시킬 수 있는데, 왜 그렇게 동작하는지 설명하려고 하면 갑자기 말이 막히는 순간이 와요.
 
 예전에는 그 간격을 적당히 넘기고 지나간 적도 많았어요.  
 하지만 지금은 그 구간을 그냥 두면 결국 다시 돌아오게 된다는 걸 알아요.
@@ -258,7 +260,7 @@ Redis나 Flink처럼 실무에서 계속 마주치는 기술은 이상하게도
 일단 만들어보고, 막히면 끝까지 파고들고, 다시 손으로 확인하는 습관 말이에요.
 
 그런데 블로그를 만들고, 공식 문서를 번역하고, 완전 정복 시리즈로 이어가다 보니 그 흐름이 조금 더 또렷하게 보였어요.  
-늘 같은 순서가 반복되고 있었거든요.
+늘 같은 순서가 반복되고 있었어요.
 
 먼저 제가 이미 알고 있는 감각과 경험이 나와요.  
 어떤 화면이 읽기 편한지, 어떤 구조가 오래 버틸지, 어디가 위험한지 먼저 짐작해보는 단계예요. 이게 제 학습의 `정`이에요.

posts/waveterm-번역-oss-기여/index.mdx

@@ -2,6 +2,7 @@
 
 Wave Terminal의 한국어 README를 번역해서 PR을 올렸고, maintainer 리뷰를 거쳐 `main`에 머지됐어요.  
 코드를 바꾸지는 않았지만, 한국어 사용자라면 매번 겪던 "번역 → 검증" 반복을 줄이는 구조적 개선이었어요.
+이 글에서는 그 불편을 어떻게 구조 문제로 정의했는지, 왜 문서 개선만으로도 읽기 리드타임을 줄일 수 있었는지 정리해요.
 
 ---
 
@@ -27,7 +28,7 @@ Wave Terminal은 제가 자주 쓰는 터미널이에요.
 이건 영어 실력의 문제가 아니었어요.  
 문서 접근 구조 자체가 비효율적이라는 게 핵심이었어요.
 
-문제를 세 가지로 정리해봤어요.
+문제를 세 가지로 정리했어요.
 
 1. 읽기 리드타임이 길어져요
 2. 번역 오차로 의미가 왜곡될 수 있어요
@@ -40,7 +41,7 @@ Wave Terminal은 제가 자주 쓰는 터미널이에요.
 ## 3. 해결
 
 가설은 단순했어요.  
-공식 한국어 README를 추가하면, 번역하고 검증하는 중간 단계를 줄일 수 있겠다고 생각했어요.
+공식 한국어 README를 추가하면, 번역하고 검증하는 중간 단계를 줄일 수 있다고 판단했어요.
 
 실행은 기여 가이드에 맞춰 범위를 최소화했어요.
 
@@ -90,11 +91,11 @@ https://github.com/wavetermdev/waveterm/pull/2943
 
 ---
 
-## 6. 오픈소스 기여는 이렇게 해보세요
+## 6. 오픈소스 기여는 이렇게 시작하면 좋아요
 
-1. 반복되는 불편은 개인 문제보다 구조 문제로 먼저 정의해보세요
-2. 첫 OSS 기여는 문서 개선처럼 작고 명확한 범위에서 시작해보세요
-3. 의사결정 기준을 PR 설명에 명시해서 리뷰어의 판단 비용을 줄여보세요
+1. 반복되는 불편은 개인 문제보다 구조 문제로 먼저 정의하면 좋아요
+2. 첫 OSS 기여는 문서 개선처럼 작고 명확한 범위에서 시작하면 좋아요
+3. 의사결정 기준을 PR 설명에 명시해서 리뷰어의 판단 비용을 줄이면 좋아요
 
 이번 경험에서 바뀐 건 기술 스택이 아니라 역할이었어요.  
 "사용자"에서 "기여자"로 전환되는 기준은 큰 기능 추가가 아니라, 작은 구조 비용을 실제로 줄였는지에 있었어요.

posts/데이터분석-파이프라인-poc/index.mdx

@@ -12,6 +12,7 @@
 
 이 문제는 단순히 "쿼리를 잘 짜면 되는 문제"가 아니라,
 **분석 업무 자체가 시스템의 보호를 받지 못하고 있다는 구조적 문제**라고 판단했어요.
+이 글에서는 그 불편을 어떻게 시스템 문제로 정의했고, 어떤 구조로 반복 분석을 흡수했는지 정리해요.
 
 ---