- Published on
[글또 10기]프론트엔드 큐레이션 글들을 읽어보자!(1~4회차)
- Authors
- Name
- Kevin(서희원)
글또에 참여하게 된지 1년하고도 2개월쯤 되었습니다. 그동안 글또에서 10개가 넘는 적다면 적고, 많다면 많은 글들을 썼지만, 큐레이션에는 한번도 뽑혀본 적이 없었는데요.
사실 9기 때 큐레이션에 뽑힌 글들을 읽고 한번 분석해서 작성해보고 싶었지만.. 괜히 잘못된 정보를 제공할 것 같아서 작성하진 않았습니다.
그런데 이번에 큐레이션에 관한 공식적인 글이 나와서 이 글들을 토대로 글또 10기 1회차 부터 4회차까지 뽑힌 프론트엔드 분야 큐레이션 글들은 어떤 특징과 형식을 가지며 작성해야 뽑힐 만한 글이 되는 것인지 한번 살펴봅시다.
글또란?
글또는 글 쓰는 또라이가 세상을 바꾼다라는 이름의 개발자 글쓰기 모임으로, 10기 기준 약 650명 정도 있으며, 그중 프론트엔드 개발자 분들이 약 180명 정도 있습니다.
글또의 Core 활동은 글쓰기에요! 자신의 블로그에 글을 2주 간격으로 작성하며, 총 5-6개월 동안 활동합니다. 2주 간격으로 작성할 수 있게 예치금을 걷고 활동 기간 동안 글을 2주마다 꾸준히 제출한다면 기수가 끝날 때 예치금을 돌려줘요.
마지막으로 글또 커뮤니티의 비전은 다음과 같아요. 글을 작성하는 개발 직군분들이 모여서, 좋은 영향을 주고 서로 같이 자랄 수 있는 커뮤니티
아쉽게도 이번이 마지막 기수라서 나중에 참여하기는 어려울 것 같아요.
제가 9기 때 어떤 활동을 했는지 보고 싶다면 여기를 확인해 보세요.
글또 큐레이션이란?
‘글 쓰는 또라이가 세상을 바꾼다’는 의미를 담고 있는 글또에서는 2주마다 개발과 관련된 글을 작성하는 게 핵심 활동인데요, 이 덕분에 정말 다양한 주제의 글들이 쏟아져 나오고 있어요! 그런데 참여 인원이 600명이 넘다 보니, 모든 글을 읽는 건 현실적으로 쉽지 않더라고요. 그래서 등장한 것이 바로 큐레이션입니다. 🎯 출처: 글또 블로그
글또 큐레이션은 매 회차 마다 큐레이션에 희망하는 글들에 한하여 운영진 분들이 직접 읽어보며 토론을 통해 약 10개 ~ 15개의 글들을 추천하여 글또 내부에서 소개하고 있어요.
참고로 매 회차마다 200개의 글들이 큐레이션에 희망한다고 합니다.
그렇다면 공식적으로 밝힌 큐레이션의 기준은 어떻게 될까요? 한번 블로그에 있는 글의 일부를 가져와 봤습니다.
- 어려운 기술도 알기 쉽게 잘 작성된 구조화되고 가독성이 높은 글
- 기존 내용을 그대로 인용하지 않고, 작성자의 독특한 관점이나 통찰이 담긴 글
- 개인의 실제 경험이나 프로젝트를 바탕으로 한 구체적인 사례와 인사이트가 담긴 글
- 주제에 대한 깊이 있는 분석과 함께 유용한 인사이트를 제공하는 글
- 회고글의 경우 진정성이 잘 담겨 있어 글쓴이의 경험에 몰입하게 만드는 글
이 기준들만 봐도 어느정도 작성하는데 도움이 되지만, 더 나아가서 구체적인 사례들을 한번 살펴보겠습니다.
큐레이션 살펴보기
실제로 작성자가 글을 통해 어떤 경험을 하고, 어떤 인사이트를 얻었는지에 관한 글들을 살펴보겠습니다 (글에 관한 제 설명 및 의견은 음슴체로 작성하겠습니다).
참고로 해당 링크의 필자를 작성자라 칭하고, 글의 순서는 랜덤입니다.
프론트엔드 경험 공유 위주의 큐레이션
먼저, 프로젝트나 오픈소스 기여 등 경험을 통해 작성한 큐레이션 글들을 살펴보겠습니다.
https://sungpaks.github.io/draggable-and-auto-walking-character-chrome-extension/
- 햄부기 크롬 익스텐션 프로젝트
- 리액트로 미리 만들어 본 후, 크롬 익스텐션으로 제작
- 글을 정말 재치있게 작성함(개인적으로 지향하고 싶었던 글쓰기 방식)
- 목차에 기능 설명과 크롬 익스텐션으로 만든 과정을 순서 번호 유무로 나눈 것과 솔직한 작성(지피티로 변환했다는 등.. 이) 인상 깊었음
- 문장을 짧게 한문장씩 개행해서 작성함 이런 방식으로 작성해서 그런지 가독성이 좋음
- ai 활용 프로젝트
- 시간 상 프로젝트에서 못했던 부분을 다시 한번 해봄
- 문제를 파악하고, 여러 가설을 세우며 시도하고, 최종적으로 대안을 만드는 모습까지 하나의 실험을 보는 것 같음(글을 fm으로 작성하면 이런 모습이지 않을까 개인적으로 생각함)
- 문장이 길어지는 만큼, 쪼개서 개행하고, 아예 다른 주제라면 한 문장도 문단처럼 개행함(가독성)
https://kangju.dev/posts/solving-style-conflicts-with-shadow-dom
- 교내 LMS(학습 관리 시스템) 관련 크롬 익스텐션 프로젝트
- 프로젝트 내부의 Shodow DOM을 적용한 과정을 설명함
- Shadow DOM의 소개, 장단점, 적용 과정, 트러블 슈팅(문제-원인-해결방법)으로 이어지는 정석적인 목차임
- 직접 개발자 도구를 사용하거나 특정 라이브러리의 깃허브 저장소 이슈 탭을 확인하여 원인을 찾음
- React hook form 구현
- 중간 점검을 통해 한번 쉬었다 다시 기능 설명함
- 블로그 자체가 문장이 길어도 글을 읽기 편하게 만들어짐
- 서론과 본론과 결론의 분리가 잘 되어 있어서 글 자체가 깔끔함
- 오픈 소스 기여
- 실제 오픈소스 기여를 통해 해외 개발자와 소통 과정을 보여줘서 오픈소스 기여에 관한 간접적인 경험을 느끼게끔 작성함
- 자신이 이렇게 작성한 이유에 대해 설명한 것이 두드러지게 나타남
- 다른 글도 마찬가지지만, 작성자의 부끄러운 부분도 함께 이야기 하는 부분에서 대단하다 생각함(필자는 개인적으로 부끄럽다고 블로그에서 일부러 말 안한 부분들이 많음)
프론트엔드 지식 공유 위주의 큐레이션
- 번들러 관련 글
- 위의 햄부기 글과 같은 작성자라 재치 있는 문장들이 많음
- MDN문서도 있어서 해당 문서를 토대로 작성 할 수 있었겠지만, 완전히 다른 글로 바꿔서 작성함
- 왜 번들이 필요한가에 대해 실제로 바닐라 js를 만들어서 쉽게 이해할 수 있도록 작성함
https://habwa.tistory.com/entry/SEO-검색-엔진-최적화-24년-버전BERT를-곁들인
- seo 관련 글
- seo를 설명하기 위해 서점을 비유하거나 예시를 들어서 설명함
- 예시 부분을 실제 있을 만한 사례로 설명하여 해당 seo 전략에 대한 이해를 크게 도와줌
https://mong-blog.tistory.com/entry/모바일에서-연속-입력시-값이-무시되는-이유feat-touch-pointer-event
- 모바일 환경 이벤트 처리 관련 글
- 예시 코드와 코드 속의 함수에 일련의 번호를 주석으로 부여하고 설명까지 테이블로 보여줌
- gif로 성능 상 어떤 부분이 좋은지 직관적으로 볼 수 있음
- js에서 이진 데이터와 파일 다루기 관련 글
- 직접 외국 자료들을 찾아봄(스택 오버플로우, 외국 Medium 글 등)
- 공식 문서스럽게 작성함
https://witch.work/posts/javascript-closure-deep-dive-application > https://witch.work/posts/javascript-closure-deep-dive-history
- js의 클로저 관련 글
- 시리즈로 나눈 2개의 글이 같이 큐레이션에 선정됨
- 각주가 있음(개인적으로 필자가 사용하는 블로그에 있다면 좋을 것 같다고 생각함)
- ECMAScript 명세 참고와 논문 인용까지 할 정도로 심도 있게 살펴봄
- 일련의 사건들을 작성할 때 한 자료만 참고하는 것이 아닌 다른 많은 자료들을 참고하여 아예 새로운 글을 작성함
- ts의 Object.keys 관련 글
- Object.keys와 관련한 ts의 깃허브 이슈를 찾거나 위의 글 처럼 ECMAScript 명세를 찾아봄
- Object.keys뿐만 아니라 ts의 핵심 개념을 중간에 설명하여 왜 ts 측에서 열린 구조라는 말을 했는지 궁금증이 해소하게끔 작성함
https://www.verycosy.net/posts/2024/11/typescript-namespace-deep-dive
- ts의 namespace 관련 글
- 마이크로소프트의 개발블로그 글과 ts 깃허브 저장소 등을 참고함
- 궁금증이 생긴 부분에 대해 일련의 탐색 과정을 거치고 거기서 얻은 지식으로 주관적인 의견에 대해 작성하고 그에 대한 근거들을 나열함
- 다형성 컴포넌트 관련 글
- 왜 에러가 났고, 어떻게 대처해야할지 깃허브 이슈나 ts의 공식문서를 바탕으로 설명함
- 가장 최선의 방법을 결정하는데 추후 가능성까지 확인함 + 마무리까지 따로 작성함(필자였으면 어떤 방법이 좋을까 까지만 작성해서 기승전만 있었을 것 같아요)
- 클로저와 this 관련 글
- 예시 코드를 보여주고 독자에게 이 값이 무언인지 주석으로 바로 알려주지 않음
- 어려울 법한 개념에 대해 최대한 풀어서 설명함
- 다른 독자들이 예상할 법한 오답에 대해 왜 오답인지 설명하고 정답을 설명해줌
이렇게 해서 총 15개의 글들을 살펴보았습니다. 이 글을 읽으시는 분들도 한번 링크타고 읽어 보시는 것을 추천드려요.
프론트엔드 큐레이션의 공통점
이번에는 큐레이션 글들을 읽고 정리해보며 개인적으로 느낀 공통점에 대해 설명해보겠습니다.
간결함
하나의 문장도 일부 쪼개서 개행함으로써 가독성이 높아졌다 생각합니다. 구구절절 설명하는 걸 다 읽기도 힘들고..
개인적으로 한 줄이 이정도 길이를 가져야 가장 이상적으로 가독성이 개선된다고 생각합니다.
벨로그 기준으로 문장이 이렇게 자동 개행되는 정도로 길게 작성하면 눈을 옆으로 굴려야하니까 읽기 조금 힘들었어요.
또한 하나의 문장 자체가 문단이 되는 경우도 많이 있습니다.
문단이라 나누는 것에 객관적인 답이 없겠지만, 확실한건 간결하게 짧은 문장으로 핵심을 전달해준다면 독자 입장에서 읽기가 정말 편해지더라구요.
주제 선정
알맞은 주제를 찾기는 힘들지만 확실한건 js기준 클로저 주제 하나, 스코프 주제 하나 처럼 개념, 용어의 개수를 1~2개 정도 정하고 주제를 잡는 것이 중요해 보여요.
목차
개인적으로 보기에 목차는 다음과 같은 방식이 많았어요.
- 문제 발생
- 문제 분석
- 해결 방안 나열
- 해결함
- 마무리
물론 지식 공유 부분에서는 해당 지식의 배경, 활용법, 왜?에 대한 의문점 설명 등이 있어요. 하지만 필자는 아직 지식을 공유할 정도로 고수는 아니라 넘어가겠습니다.
경험 공유의 경우, 솔직함
개인적으로 경험을 공유하는데 가장 필요한 부분이라 생각합니다. 그래야 메타인지도 상승하고, 너무 가식적으로 보이지 않을 것 같아요.
그리고 텐션이 오르락내리락하며 작성해야 독자들에게 흥미를 일으키기 좋을 것 같아요. 맨날 좋은 부분만 보여준다면 인스타랑 다를 바가 없기 때문에..
지식 공유의 경우, 자료의 깊음
필자가 개인적으로 지식 공유 부분의 글들을 보면서 개인적으로 궁금했던 부분 중 하나가 어떤 자료들을 참고하는 지 였습니다.
실제로 일부 글들을 읽으면서 기존에는 안봤지만, 참고하면 좋을 것 같은 자료의 링크들을 나열하자면 다음과 같아요.
- ECMAScript 공식문서
- ts 깃허브 저장소
- 스택 오버플로우
- 구글 영어검색(외국 기술블로그)
마무리
이렇게 해서 글또 10기 1~4회차 프론트엔드 분야에 선정된 큐레이션 글들을 살펴보았습니다.
시행착오를 겪으며 해결한 경험을 글감으로 삼아 그 경험을 토대로 독자들에게 지식, 몰입, 인사이트를 줄 법한 글을 쓰는 것이 중요하겠다는 생각이 들었습니다.
그래서 필자가 순수한 호기심으로 학습한 내용들을 블로그에 올리는 방식은 지양하고 당장 다음주 부터 동아리 내에 프로젝트가 있으므로 프로젝트 하며 생긴 문제들을 공부하여 블로그에 포스팅해야겠습니다.
이제 나도 큐레이션 보유자?