글또와 글쓰기 세미나를 통한 저의 변화를 통해, 현재까지의 글쓰기 프로세스를 점검하고 어떻게 개선할 수 있을지 살펴보고 과거의 작성글을 직접 수정하여 비교해 보겠습니다.
글쓰기 세미나 회고
기존의 글쓰기에 대한 반성
자기만족을 추구하며 글을 써왔습니다. 예상독자도 저와 항상 비슷한 사람으로 생각했고, 제가 마주한 문제를 해결하는 식의 글, 제 경험으로 비롯된 글감들이 전부였습니다. 이런 것을 지정해 놓고 써왔다기보다 당연하게 여겼다는 게 정확한 설명입니다. 글에 정답은 없다지만 보고 싶은 글만 보고 편식을 많이 해왔습니다.
글또에서의 메타인지
다양한 개발자분들의 글을 보고 부끄러웠습니다. 이전보다 글을 쓰기가 어려워졌습니다. 완벽함에 대한 강박이 생겼어요. 글감을 잘 떠올리던 이전과 다르게 부담감이 엄습.. 기간에 아슬아슬하게 제출하고 나서 자괴감이 들었습니다. 즐겁던 글쓰기가 일처럼 느껴지게 된 겁니다.
20240114 글쓰기 세미나
스스로 적절한 로드맵을 선정하고 자기 만족도 좋지만 또 다른 분들에게 어떤 식으로 도움이 될 수 있을지? 기존 글쓰기 방식에서 어떻게 더욱 발전할 수 있을까? 를 고민해 보는 것의 중요성을 알게 되었습니다. 그리고 다른 분들의 글을 많이 참고해야겠다는 것을 깨달았습니다. 문제 해결에만 초점을 두고 블로그를 보았던 것을 반성하는 시간을 가졌습니다.
글쓰기 프로세스 점검
기존 글쓰기는 글감 선정 방식에 따라 두 가지로 이루어졌습니다.
1. 문제를 직면하고 해결하는 과정에서 글감을 선정하는 경우
2. 일상 속 관심사를 글감으로 선정하는 경우
글쓰기 방식에서의 장단점
저의 경험으로 미루어보아, 1번 방식이 훨씬 수월하게 썼고, 퇴고도 빨랐습니다. 다만 단순 문제 해결의 서술이 되는 경우가 있었고 전체적으로 글의 깊이가 얕게 느껴지는 단점이 있었습니다.
2번 방식은 제가 생각한 부분보다 방대한 규모를 맞닥뜨리게 되어서 세세하게 어느 부분을 보여줄 것인지를 정하지 않으면 예상보다 더욱 오래 걸려 집중력이 바닥나게 되었습니다.
둘의 장점을 살리고 단점을 없앨 수 있는 방식을 생각해보았습니다.
스스로 느꼈던 단점
▶︎ 즉흥으로 글감이 정해지는 경우가 많았습니다. 쓰다가도 너무 힘들면 엎어버리고 다른 주제를 선정하기도 했었습니다..
▶︎ 피드백을 두려워해서 개선할 수 있는 방향성을 갖지 못했습니다. 한정된 영역으로 글을 공유했던 거 같네요!
▶︎ 전체적인 구조를 잡지 않고 의식의 흐름대로 intro와 과정, 결과, 느낀점 식으로 서술하여 전체적으로 논리정연한 느낌이 부족하다고 느꼈습니다.
점검 후 개선점
▶︎ 글감 소재 미리 보관해두기
▶︎ 글감 선정 때 구조를 짜보기(예상 독자, 목차 구조와 분량, 인사이트를 주고 싶은 부분 등 세미나에서 얻은 인사이트로!)
▶︎ 번복 금지 (쓰다가 포기하는 경우 많으니 규칙으로 정함)
▶︎ 피드백 꼭 1번 이상 받기(글또 내 피드백 모임 참여중 & 최대한 많은 플랫폼에 게시해보기)
과거 작성글 수정하기
2023.11.29 - [JavaScript/React] - React, TS에서의 Event Type interface와 React Event System 구조
React, TypeScript에서의 Event Type interface와 React Event System과의 상관관계
Introduction 나는 null이 아니라 any 형식이 포함된다고 Error가 떴다. React에서의 event를 제대로 이해하지 못한 탓인지 tsx를 화나게 했다. 나처럼 js에서의 Event는 익숙한데, React + TypeScript에서의 Event 타
nami-socket.tistory.com
내가 선택한 글은 이것..! WHY? 글또를 하고 계신 개발자분께서 피드백을 주신적이 있다. (정말 감사합니다!)
예상 독자를 잘 파악하고, 그 독자층에 맞게 쓰였는가?
=> 예상독자는 추정컨데, 미래의 자기 자신.자기 자신이 보기 위한 글도 나쁘진 않지만, 이를 명확하게 의도했는지는 한번 확인할 필요가 있다. 이는 ‘글을 왜 쓰는가?’ 하고도 연관되어있기 때문.
글의 내용이 중언부언하지 않고, 결론을 향해 명료하게 달려가는가?글의 주저는 DOM, JSX 의 event callback 주입 과정에서, callback fucntion 의 args 타입의 상속 구조에 대한 설명을 하고있다.
React Event System이 뭐지?* <T = Element> generic 관련해 설명을 하는걸까?T ⊂ Element 를 의미하는거면, 구체적인 Element interface 의 implementation 을 보여주면 좋았을꺼같은데. Ex) HTMLInputElement 같이.
Element는 문서의 모든 Element 객체가 상속하는 가장 일반적인 Base class 이다. => element 는 class 가 아닌 interface.
TS 는 특히 이 두개를 구분하는걸로 알고있는데.
React에서는 모든 플랫폼에서 동일한 이벤트 처리를 위해 SyntheticEvent 객체를 사용한다
=> 이 또한 SyntheticEvent 는 class 가 아닌 interface.
브라우저의 Native event 와 synthesized 된 event 의 차이에 대해 더 자세한 설명이 있었으면 어떨까?
결론에 유닉한 인사이트가 담겨있는가?
아쉽게도 학습한 내용의 정리에 대해 집중하고 있다.결론부를 보면, 포스팅을 한 동기가 TS lint warn 때문인걸로 보이는데, 이를 글의 동력으로 사용했어도 좋았을꺼 같다.
이렇게 상세한 피드백을 받고 부끄러움과 감사함이 공존... 개인적으로 글을 다시 읽어보니(벌써 2달이 지났다) 아쉬워서 추가할 부분에 대한 공부도 좀 필요했고..(그만큼 제대로 된 이해 없이 글쓰기에 투입했던 것일수도)어디부터 건들여야할지 엄두가 나지 않았다. 하지만 이 기회에 제대로 고쳐보자는 마음으로 임했다.
✔️ 모호한 제목 변경
Before
제목 변경은 하고싶지 않았는데 글 내용을 쓰기 전에 정해버린 타이틀이었기도 했고 전체적인 글을 정리해주는 요약글이 전혀 아니었기에 큰 마음을 먹고 변경했다. (마지막에 바꿨지만 우선적으로 보여드린다)
After
React, TS에서의 Event Type interface와 React Event System 구조
=> 제목은 간단히 초안에 말하고 싶은 부분을 적고 내용을 전부 쓴 후에 전체적으로 글을 읽고 고치기
✔️ 동기와 예상 독자를 확실하게 보여주기
Before
After
=> Too much intro는 뒤로 빼고, 첫인상같은 동기를 한 눈에 보이도록 했다.
✔️ 의도를 정확하게 티내기
Before
After
Before
After
=> 불친절하게 나만의 방식으로 서술하지말고 상세하게 목적에 부합도록 쓰기
=> 모호한 설명에 대한 부분, 피드백 반영
✔️ 잘못된 부분 수정 & 예상 독자에 맞게 내용 보충하기
Before
After
✅ 피드백으로 알게된 잘못된 부분을 수정했고, 추가로 어려울 수 있는 설명을 보충했다.
Before
After
🤔💭
이전에 썼던 글은 정말 제대로 된 이해없이 썼다는 걸 알게된 부끄러운 경험이었다. 하지만 글을 수정하며 정말 즐거웠다. 피드백을 두려워하지 않게 되었고 더 잘 알 수 있는 기회라고 느껴졌다. 눈에 띄게 좋은 글로 변하는 것을 느낄 수 있어서 행복했다! 이번 주에 쓰게 될 글은 개선점을 반영해서 적어볼 것이고 많은 플랫폼에 게시해서 여러 개발자 분들께 피드백을 받으려 한다. 성장할 수 있도록 도와주신 글또, 개발자분들께 감사합니다. 🌞