지금으로부터 약 3개월 전인 9월 15일 첫발행을 시작으로, 가장 최근에 발행한 12월 15일까지 오픈률과 클릭률을 정리하였습니다.

우리는 여기서 어떤 의미 있는 인사이트를 얻어볼 수 있을까요?

궁극적으로 많은 분들에게 뉴스레터를 열람하게 하기 위해 어떤 액션을 취하면 좋을지 한번 같이 알아봅시다.

뉴스레터 발행은 요일에 영향을 미칠까?

별로 미치지 않을 것 같아 보이지만, 요일은 생각보다 많은 영향을 미칩니다.

당장 11월 뉴스레터는 토요일마다 발행했는데요, 당시 오픈률이 1, 15일 각각 41.8%, 38.5%를 나타내였고, 직전 오픈률 44.4%에 비해 점점 낮아지는 모습을 보입니다.

그리고 그 다음달인 12월 뉴스레터를 살펴본다면, 오픈률이 1, 15일 각각 40.2%, 43.3%로, 11월에 비해 소폭 상승한 모습을 볼 수 있습니다.

이로써 우리는 뉴스레터가 어떤 날짜로 발행하냐가 아닌, 어떤 요일로 발행하냐에 따라 열람률이 달라짐을 알 수 있었습니다.

그렇다면, 요일이 아닌 다른 요소로 무엇이 있었을까요?

아까 전에 테이블을 다시 가져와봤는데요.

이번엔 대학교 일정을 대입해서 알아봅시다.

2학기 대학교 일정은 보통 크게 보면 다음과 같이 이루어지는데요.

1. 개강(9월의 첫 평일)
2. 중간 고사 기간(개강 이후 7~8주차, 10월 20일 쯤 중간 고사 시작)
3. 기말 고사 기간(개강 이후 15~16주차, 12월 15일 쯤 기말 고사 시작)및 종강

1번인 개강 시기에는, GDGoC가 새로 시작되는 시기이므로, 이 당시 새로 유입되는 구독자 분들이 한번 쯤 열람해주므로 오픈률이 높은 모습을 보입니다.

그리고 2, 3번인 시험 기간에는 대학생들이 바빠서 뉴스레터를 열람하지 않을 것 같아 보입니다. 하지만 10월 1일에 비해 10월 15일에 오픈률이 내려가지 않고, 유지하는 모습을 보이며, 12월에는 오히려 약 3% 더 오픈률이 올라가는 모습을 보입니다.

이로써 다음과 같은 결론을 알 수 있게 됩니다.

• GDGoC 해당 기수 첫 뉴스레터 오픈 시기에는 유입되는 구독자로 인해 오픈률이 가장 높다.
• 시험 기간에는 일부 구독자 분들이 공부 이외에 재미를 붙여(?) 뉴스레터를 오픈하여 상대적으로 조금 더 높은 오픈률을 보인다.

왜 뉴스레터 오픈률은 점점 우하향할까?

많은 요인(지겨운 콘텐츠, 오픈을 까먹음 등)들로 인해 오픈률이 우하향하겠지만, 여기에 객관적인 자료를 하나 가져와봤습니다.

바로 저희 뉴스레터 발송 시 사용하는 플랫폼인 스티비에서 공개한 업종 별 이메일 성과지표인데요.

여기의 자료들을 살펴본다면, 수많은 업종들이 있지만, 일단 컴퓨터, IT, 기타 부분의 성과지표들을 가져와봤습니다.

뉴스레터를 들어가서 내부의 어떠한 링크를 클릭한다면, 이는 클릭률을 높여줍니다.

물론, 퍼센트로 보다시피, 상대적으로 적은 비율을 차지하여 이게 표본이 확실히 많은 것이 아니지만, 구독자 분들이 관심있게 봐준다는 지표가 되는데요.

오픈률과 비슷하지만, 약간 미묘하게 다른 점이 하나 있어 이 부분을 한번 살펴보겠습니다.

시험 기간의 클릭률?

중간고사 기간인 10월 15일, 기말고사 기간인 12월 15일의 클릭률을 살펴보면 굉장히 정 반대의 모습을 보입니다.

중간고사에는 6%, 기말고사에는 1.5%인데요.

각각 왜 이런 지표가 나왔을까 생각해보면 다음과 같이 추측해볼 수 있습니다.

• 중간고사: 아직은 공부할 힘이 난다. 링크를 타고 들어가서 재밌는 것들을 보자.
• 기말고사: 각종 팀플, 과제, 시험으로 지쳐있다. 링크를 들어갈 힘이 없다.

그래서 기말고사가 시작되는 달에는 최대한 뉴스레터의 힘을 빼면서, 구독자들의 나름대로 니즈를 맞추면 좋을 듯 싶습니다.

마무리

이렇게 해서 2025년 GDGoC HUFS에서 진행한 뉴스레터를 데이터로 살펴보고, 어떤 가설을 세워볼지 알아봤습니다.

한번 정리해보면 이렇겠네요

• 요일은 가능하면 평일 - 특히 월요일
• 시험 기간인 달이면, 해당 시험 기간으로 발행 조정
• 기말 고사 기간에는 힘빼기

요즘 뉴스레터 홍보를 돌리고 있는데, 많은 분들이 구독해주셔서 감사할 따름입니다. 앞으로 뉴스레터에 큰 변화가 한번 일어날텐데, 이 또한 직전에 공지한번 해드리겠습니다!

지난 12월 초, 프론트엔드에서 주로 사용하는 라이브러리인 React에서 보안관련 사고가 2차례일어났습니다.

이로 인해 React를 새로운 버전으로 업데이트해야되었는데요.

이번엔 이 두 사건이 어떤 일로 일어났는지 한번 차근차근 알아봅시다.

11월 29일

한 남성이 메타 버그바운티를 통해 보안 취약점을 제보하게 됩니다.

여기서 버그바운티(Bugbounty)란 윤리적인 화이트햇 해커가 기업이 허용한 자산을 분석해 보안 취약점을 제보하고 보상받는 제도입니다.

참고로 제보한 남성의 이름은 Lachlan Davidson으로, 정보보안 엔지니어라고 하네요.

11월 30일

메타 보안 연구원들은 이 제보를 확인하고 React팀과 같이 고치기 시작했습니다.

12월 1일

수정 사항을 생성하였으며, React팀에서 이 변경된 수정 사항에 대해 영향을 받는 오픈소스 프로젝트와 호스팅 제공업체들과 같이 검증하고 구현하여 배포하였습니다.

12월 3일

수정 사항은 NPM에 게시되었으며 공개적으로 CVE-2025-55182로 공개되었습니다.

이 타임라인에서 우리는 이 이슈 때문에, 메타에서 빠르게 새 버전을 내놓고 React 블로그로도 공지하는 것을 볼 수 있었는데요. 왜 이런 선택을 하는 것인지 한번 알아봅시다.

매우 간략한 요약

CVSS 10.0 등급의 공격 난이도도 낮으며, 원격으로 인증 없이 데이터나 비밀로 유지해야하는 정보 등을 탈취당할 수 있습니다.

CVSS(Common Vulnerability Scoring System)

여기서 우리는 CVSS 점수가 10.0이라는 것에 주목할 필요가 있습니다.

CVSS는 소프트웨어 보안 취약점의 심각도를 평가하고 점수화하는 표준 프레임워크로, 0.0부터 10.0까지의 점수를 매깁니다. 그리고 점수가 높을수록 취약점이 심각함을 의미하는데요.

앞서서 이야기한 10점 만점은 평가 기준상 악용 시 기밀성, 무결성, 가용성 모두에 완전한 영향을 주거나, 네트워크 접근, 권한 상승 없이도 공격이 가능한 경우입니다.

이를 고깃집으로 비유하자면 손님이 종업원에게 고기1인분과 현금 100만원을 달라고 요청했는데, 종업원은 어떤 손님인지도 모른 상태로 고기 1인분과 100만원을 덜컥 준다는 것입니다.

그렇다면 일단 여기까지만 이야기하고, 이후 12월 11일에 일어난 보안 이슈는 어땠을까요?

이번에도 같은 형식으로 살펴보겠습니다.

12월 3일

Andrew MacPherson이 Vercel과 Meta Bug Bounty에 취약점 유출을 보고하였습니다.

12월 4일

RyotaK가 Meta Bug Bounty에 최초 DoS 공격을 보고하였습니다.

12월 6일

React 팀에서 두 가지 문제를 모두 확인하고 조사에 착수하였습니다.

12월 7일

초기 수정 사항이 적용되고 React 팀은 새로운 패치를 검증하고 계획하였습니다.

12월 8일

영향을 받는 호스팅 제공업체와 오픈 소스 프로젝트에 알렸습니다.

12월 10일

호스팅 제공업체의 완화 조치가 완료되고 패치가 검증되었습니다.

12월 11일

Shinsaku Nomura가 Meta Bug Bounty에 추가 DoS 공격을 보고하였습니다.

패치가 게시되고 CVE-2025-55183 및 CVE-2025-55184로 공개되었지만,

내부적으로 발견된 누락된 DoS 공격 사례에 대해 패치를 적용하고 CVE-2025-67779로 공개했습니다.

그러면 한번 Dos 취약점과 소스코드 중 환경변수는 왜 노출되지 않는지에 대해 살펴보겠습니다.

매우 짧은 요약

• 의도적으로 서버가 무한루프에 빠지는 Dos 공격로 인해 사이트가 마비될 수 있고, CVSS는 7.5점 정도 됩니다.
• 소스코드 노출로 인해 직접적인 위험은 없지만, 간접적으로 보안 상 실수(대표적인 예시: API 키 값 하드코딩)를 하면 그대로 노출 될 수 있습니다. CVSS는 5.0점 정도 됩니다.

Dos 공격?

Dos공격은 다시 정석대로 이야기하자면, 과도한 트래픽을 서버에게 주어서 유저들이 서비스를 사용하지 못하게 하는 공격입니다.

그래서 이번 Dos공격은 과도한 리소스를 주는 것이 아닌, 서버에게 무한 루프를 주는 방식으로, 계속 CPU를 점유하게 만들기 때문에, 서비스를 운영하는 회사입장에서 손해일 수 밖에 없습니다.

환경변수란?

.js와 같은 파일에서 저장되는 다른 변수들과 달리, 환경변수는 서버의 운영체제 내부에서 따로 저장하고 있습니다. 그래서 환경변수를 접근하려는 시도 자체가 거의 불가능하다고 보면 되는데요. 만약 프론트엔드 개발을 하는데, API 비밀 키값으로 process.env를 사용하지 않는다면, 즉시 사용해야 합니다.(진짜 필수입니다.)

그래서 우리는 어떻게 해야하나요?

가장 간단하면서 명확하게 이런 보안이슈를 피하고자 한다면, React Server Component를 사용하는 프레임워크의 가장 최신 버전을 설치하시면 됩니다. 아래 링크에 자세히 적어놓아서 해당 링크를 들어가서 읽어보는 것을 추천드립니다.

https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components#update-instructions

마무리

이렇게 해서 최근 12월 초반을 뜨겁게 달군 React관련 보안 이슈에 대해 알아봤습니다.

혹시 주변에 배포해놓고 방치한 React, Next 프로젝트가 있다면 신속히 업데이트하고, 나중에 프로젝트를 하나 만들고자 한다면 create react app으로 초기 프로젝트 세팅이 아닌, 직접 하니씩 설치하며 프론트엔드의 구조를 알아가보는 것도 좋은 경험이라 생각합니다.

그렇다면 분명 좋은 프론트엔드 개발자로 거듭날것입니다!

갈등은 버그가 아닌, 협업의 증거

그럼 에이전트끼리는 주로 어떤 갈등이 발생할까요?

Orchestrator-worker pattern, Credit: Confluent

이 난장판(?)을 정리하는 역할을 맡는 존재가 바로 AI 팀의 리더,

Orchestrator Agent입니다.

좋은 오케스트레이터를 설계하기 위해 반드시 짚고 넘어가야 할 다섯 가지 원칙을 정리해봤습니다.

이 다섯 가지 설계 원칙을 관통하는 핵심은 결국 ‘통제된 자율성’입니다.

개별 에이전트가 각자의 전문성을 충분히 발휘하도록 두되,

오케스트레이터가 전체 비즈니스 맥락과 거버넌스라는 울타리를 단단히 유지할 때

비로소 다중 에이전트 시스템은 완성됩니다.

단순히 작업을 배분하는 관리자를 넘어, 시스템의 병목을 진단하고 조직의 가이드라인을 지켜내는 ‘이 AI 리더를 어떻게 설계하느냐’가 앞으로 AI 도입의 성패를 가르는 핵심 경쟁력이 될 것입니다.🏆

1. 2026.01.05. (월) | SIPE 5기 보러가기
2. 2026.01.10. (토) | GNP 2026 보러가기    
3. 2026.01.10. (토) | 오픈소스 기여모임 10기 보러가기
4. 2026.01.18. (일) | MCP PLAYER 10 보러가기