Lab Log

2025 회고: 글 33개, PR 38회, 발표 3회로 '보여주는 개발자'가 되다

10 min read

2025 회고: 글 33개, PR 38회, 발표 3회로 '보여주는 개발자'가 되다

2025년은 "숨어서 잘하는 개발자" 에서 "보여주고 나누는 개발자" 로 방향을 튼 해였습니다. 시작점은 2024년 12월 23일, 한 개발자의 피드백이었습니다.

"평소 기술 관련 답변을 잘 해주시는데, 회고에는 기술적인 내용이 하나도 없네요."

그때 깨달았습니다. 개인브랜딩은 말을 잘하는 게 아니라, 내가 어떤 문제를 어떤 방식으로 해결하는지를 검증 가능한 산출물(글/PR/발표) 로 남기는 일이라는 것. 이 글은 그 전환의 기록입니다.

📊 한눈에 보는 2025

활동실적주요 성과
📝 블로그33개 포스트누적 35,000+ 조회수
🔧 오픈소스38회 PR 승인Mantine 27회, Node.js 4회
🎤 발표3회쑥떡콘, FEConf 2025, TeoConf

블로그: “어떤 글이 읽히는지”를 확인하다

처음엔 "내가 이런 글을 써도 될까?" 가 제일 컸습니다. 하지만 첫 글이 일주일 만에 500회 조회수를 넘기면서(초기 지표), “내가 어떤 고민으로 개발하는지” 를 글로 증명할 수 있겠다는 확신이 생겼습니다.

연말에 조회수 TOP3를 뜯어봤습니다.

  • 4시간 만에 Node.js PR 승인받기
  • 15줄에서 2줄로: useSyncExternalStore 기반 React Toast 시스템 설계법
  • React 에러 구조 설계: throw만으로 선언적 에러 핸들링 하기

세 글의 공통점을 분석해보니, 반응 좋은 글에는 패턴이 있었습니다.

  • 제목은 과정이 아니라 결과가 먼저 보인다. (숫자/시간/변화량처럼 “얼마나?”가 즉시 답이 나는 형태)
  • 권위 있는 대상 + 나의 실전 경험이 같이 있다. (튜토리얼/이론이 아니라 “충돌/기여/실패/통과”의 신뢰 신호)
  • 문제 상황이 한 줄로 선명하다. (“이 상황에서 어떻게 했는지”가 제목만 봐도 보인다)
  • 본문은 왜 쓰게 됐는지 → 기존 방식의 한계 → 선택 → 결과 흐름을 가진다.

개념 중심/정리형 글은 검색 유입은 되지만 반응 지표는 약한 편이었습니다. 그래서 앞으로는 제목을 만들 때 숫자 / 실패·충돌 / 특정 대상 / 변화 한 문장 중 3개 이상을 기본 체크리스트로 두려고 합니다.

오픈소스: 레퍼런스를 “외부 검증”으로 만들다

처음 오픈소스에 기여할 때는 "이런 사소한 것을 PR로 올려도 될까?" 망설였습니다. 그런데 한 번 머지/승인을 경험하니 관점이 바뀌었습니다. 개인 프로젝트의 결과는 “내가 잘 됐다고 느끼는 것”에 머물 수 있는데, 오픈소스는 외부 리뷰와 릴리스라는 검증이 붙습니다.

2025년에는 특히 아래 경험이 글/발표의 근거가 됐습니다. (링크는 글 끝에 정리했습니다.)

  • Node.js: util.inspect 숫자 포맷팅 버그 재현 → 테스트 작성 → 수정 → 4시간 만에 PR 승인
  • Mantine: Slider의 onChangeEnd 동기화 이슈를 useRef로 해결, 머지 후 릴리스 포함
  • Next.js: 2번 실패 후, 원인/의도 파악을 거쳐 최종 PR 성공
  • gemini-cli: Promise.allSettled() 병렬 처리로 전환해 74% 성능 개선(408ms→107ms)

오픈소스 기여는 단순히 횟수가 아니라, 글과 발표의 밀도를 높여주는 재료가 됐습니다. 특히 실패/거절/리뷰 대응은 문서로 배울 수 없는 실전 경험이었습니다.

컨퍼런스: 무대 위에 서다

쑥떡콘: Panda CSS 1년 사용기

"Panda CSS 1년 사용기" 로 첫 발표를 했습니다. 10건 이상의 질의응답을 주고받으며 사람들이 무엇을 궁금해하는지 알게 되었고, 이 경험이 더 나은 콘텐츠를 만드는 밑거름이 되었습니다.

FEConf 2025: 오픈소스 밥상차리기

그리고 FEConf 2025. 내가 해도 되는 건가? 하는 마음으로 라이트닝 토크에 신청했고, 선정되었습니다. 3개월간 준비해서 35장의 슬라이드를 11장으로 압축하며 핵심만 남겼습니다.

"오픈소스 밥상차리기: 환경설정과 디버깅편" 이라는 주제로 무대에 섰을 때, 다리가 떨렸지만 이 생각을 했습니다. "나는 이미 충분히 준비됐어. 이제 내 이야기를 들려주기만 하면 되는 거야."

발표 후 가장 기뻤던 피드백은 "오늘 집에 가서 바로 PR 하나 올려볼게요!" 였습니다. 누군가의 첫 걸음을 도왔다는 것, 그것이 발표자로서 가장 큰 보람이었습니다.

TeoConf: 3주간의 디자인 시스템 배포 삽질기

세 번째 컨퍼런스인 TeoConf에서는 디자인 시스템 배포 이야기를 꺼냈습니다. 하루면 끝낼 줄 알았던 배포가 3주로 늘어나고, 300KB를 목표로 했던 번들이 20MB까지 불어나는 등 소재는 차고 넘쳤습니다. 문제는 “할 이야기가 많다”는 게 곧 좋은 발표가 아니라는 것이었습니다.

사전 피드백에서 가장 뼈아팠던 말은 이거였습니다.

  • 핵심 메시지가 보이지 않는다
  • 설명 흐름이 너무 기술적이다
  • 청중과의 연결고리가 약하다

리허설에서 “그래서 제일 어려웠던 게 뭐였나요?” 라는 질문에 답을 못한 순간, 내가 발표를 정리하지 못했다는 걸 인정하게 됐습니다. 결국 TeoConf가 내게 남긴 건 번들링/빌드 삽질의 해결책보다, 발표는 기술을 나열하는 자리가 아니라 청중이 가져갈 한 문장을 만드는 과정이라는 깨달음이었습니다.

선순환 구조의 형성

2025년 가장 큰 성과는 개인 브랜딩을 의지가 아니라 구조로 만든 것입니다.

블로그 글은 꾸준히 쓰고 있었고, 그 글을 기반으로 FEConf 같은 곳에 신청하며 발표도 함께 늘려갔습니다. 여기에 오픈소스 기여가 더해지면서 실전 경험과 레퍼런스가 폭발적으로 쌓였고, 글과 발표의 밀도가 올라가며 네트워크가 확장되고 더 많은 기회가 열렸습니다.

(블로그: 기록/정리) ↔ (컨퍼런스: 신청/발표) + (오픈소스: 기여) → 실전 경험·레퍼런스 → 신뢰·네트워크 → 더 많은 기회 → 다시 글/발표/기여

이 선순환이 작동하기 시작하면서, 더 이상 "브랜딩을 위해 무언가를 해야 한다" 는 부담이 사라졌습니다. 그냥 좋아서 하는 일들이 자연스럽게 브랜드를 만들어갔습니다.

배운 것들

  • 브랜딩은 ‘자기소개’가 아니라 ‘증명’이다. 신뢰는 “잘할 것 같다”가 아니라 “이미 해본 흔적(글/PR/발표)”에서 나온다.
  • 작은 기여도 쌓이면 흔적이 남는다. 27회 기여하니 내 PR 히스토리가 곧 신뢰 지표가 됐다.
  • 발표는 청중 중심이다. “할 이야기가 많다”를 버리고 “청중이 가져갈 한 문장”을 먼저 만든다.
  • 실패를 숨기지 않을수록 설득력이 커진다. 실패→수정→통과의 과정이 재현 가능한 학습 재료가 됐다.

마치며

처음에는 "내가 공유할 만한 가치가 있을까?" 라고 의심했습니다. 하지만 작은 용기를 내어 글을 쓰고, PR을 올리고, 발표를 하다 보니 생각보다 많은 사람들이 “경험의 맥락”에서 가치를 발견했습니다.

개인 브랜딩의 핵심은 "대단한 무언가" 가 아니라 "진정성 있는 공유" 였고, 시행착오와 꾸준함이 전문성을 만든다는 것을 배웠습니다.

2026년에는 이 선순환 구조를 더 단단하게 만들어, 한국 프론트엔드 커뮤니티에 긍정적인 영향을 주는 개발자가 되고 싶습니다.

💬 여러분의 이야기를 들려주세요

  • 2025년 여러분의 가장 큰 성장은 무엇이었나요?
  • 오픈소스 기여를 시작하고 싶은데 망설여지시나요?
  • 블로그를 시작하려는데 주저하고 계신가요?

댓글로 여러분의 경험과 고민을 나눠주세요! 🙌

링크 모음