노트

블로그

프론트엔드 엔지니어링, SEO, AI, 분석, 그리고 실제 제품을 만드는 과정에 대한 기록.

42

2026년 8월 31일8 분 읽기

“Guaranteed Resources — No Sharing”이라던 AVA Hosting VPS에서 평균 CPU Steal 32.73%가 나왔다

일반적인 프로덕션 트래픽에서 제 AVA Hosting KVM VPS는 평균 CPU steal 32.73%, CPU idle 0%, CPU pressure 약 99%를 기록했습니다. 이것은 부정적인 리뷰가 아니라 Linux가 VM 내부에서 실제로 무엇을 보여줬는지에 대한 직접적인 디버깅 기록입니다.

AVA HostingVPSLinuxCPU stealVPS 성능
2026년 8월 31일10 분 읽기

제 FDCServers VPS는 3 TB가 넘는 트래픽까지 멀쩡했습니다. 그런데 디스크 읽기에 18초가 걸리기 시작했습니다

제 FDCServers VPS는 처음에는 실제 트래픽을 정상적으로 처리하며 3 TB가 넘는 데이터를 전송했습니다. 이후 평범한 workload에서도 심각한 가상 디스크 stall이 발생해 CPU iowait가 100%, Linux I/O pressure가 거의 100%, read latency가 18.7초, flush latency가 53초 이상까지 올라갔습니다.

FDCServersVPSLinux디스크 I/ODevOps
2026년 8월 31일8 분 읽기

트래픽을 모두 제거해도 REGXA VPS에서 CPU Steal이 94%였다

REGXA KVM VPS의 심각한 성능 문제를 조사하면서 92–94%의 CPU steal, 수초가 걸리는 localhost 요청, 증가하는 연결 큐, 2분 넘게 걸린 HTTP 504를 확인했다. production traffic을 모두 제거한 뒤에도 CPU steal은 94.17%까지 올라갔고, REGXA 지원팀은 이후 shared infrastructure의 resource contention이 원인이라고 설명했다.

REGXAVPSLinuxCPU steal가상화
2026년 8월 28일13 분 읽기

Nginx 뒤에서 Bunny Storage를 두 달 운영한 뒤 이미지·비디오·오디오를 전용 미디어 서버로 옮긴 이유

두 달 동안 Bunny CDN이 아니라 Bunny Storage를 자체 Nginx 캐시의 private origin으로 사용했다. Production log에서는 cold media의 long-tail connection timeout과 MP4에서 Nginx Slice와 ETag 불일치라는 별도 문제가 확인됐고, 결국 더 단순한 private media origin으로 이전했다.

Bunny StorageNginx비디오 캐시Cache miss미디어 서버
2026년 8월 20일10 분 읽기

WebP를 AVIF로 트랜스코딩할 때의 SSIMULACRA2: 원본에는 60, 이미 손실 압축된 파생본에는 65를 쓰는 이유

이미 lossy 압축된 WebP에서 AVIF를 만들면 SSIMULACRA2는 두 번째 세대의 손실만 측정합니다. 그래서 깨끗한 source에는 60/58, known lossy derivative에는 65/63을 사용합니다.

AVIFWebPSSIMULACRA2이미지 압축웹 성능
2026년 8월 17일12 분 읽기

DeepSeek가 가격을 올렸다 — 같은 V4 Flash를 예전 요금보다 더 싸게 찾았다

8월 17일 아침 DeepSeek API 지출이 평소의 약 5배로 늘어난 것을 확인했다. 이후 동일한 DeepSeek-V4-Flash-0731 checkpoint를 제공하는 다른 provider를 찾아 직접 테스트했는데, 현재 가격은 DeepSeek의 예전 요금보다도 약 45% 낮았다.

DeepSeekRunwareLLM APIAI 인프라Open-weight 모델
2026년 8월 13일16 분 읽기

프레임과 타이밍을 망치지 않고 애니메이션 WebP·GIF·APNG를 H.264 MP4로 바꾸는 방법

제 운영 처리 체계는 사용자가 실제로 보는 완전한 프레임을 재구성하고 원본 타이밍을 보존하며, 최종 MP4마다 하나의 CFR을 선택하고 확대 없이 가장 작은 공통 캔버스를 사용합니다. 호환되는 H.264 세그먼트를 인코딩해 두 번째 손실 인코딩 없이 연결하고, 파일 자체와 HTTP 전달 경로까지 검증합니다. 실제 측정 사례에서는 총 1.49 GB의 애니메이션 WebP 217개가 78.49 MB H.264 MP4 하나가 됐습니다.

H.264FFmpegMP4애니메이션 WebPGIFAPNG영상 압축미디어 처리
2026년 8월 13일20 분 읽기

모든 브라우저 오류에 알림을 보내던 내가, 오류 소음을 실제로 쓸 수 있는 프로덕션 모니터링으로 바꾼 방법

초기 프런트엔드 리포터는 광고 차단, GTM 실패, AbortError, 정보가 거의 없는 Script error, 실제 Next.js 청크 장애를 모두 같은 오류로 취급했습니다. 이후 소유 주체, 사용자 영향, 증거의 질, 사건 간 상관관계, 복구 여부를 기준으로 모니터링을 다시 설계했습니다.

브라우저 오류 모니터링프런트엔드 관측 가능성JavaScript 오류프로덕션 모니터링Next.js웹 성능
2026년 8월 13일26 분 읽기

배포 뒤 오래된 Next.js 탭이 깨지는 이유: 오래된 HTML, 사라진 청크, 버전 불일치

한 번의 배포 뒤 운영 모니터링에서 제 Next.js 애플리케이션 자체의 청크 하나가 로드되지 않은 기록이 잡혔습니다. 로그가 증명한 것은 실패가 발생했다는 사실이지 원인은 아니었습니다. 이 글에서는 그 사례를 바탕으로 오래 열어 둔 탭, 오래된 HTML, 사라진 /_next/static 리소스, 버전 불일치, 이전 자산 보존, deploymentId, 게시 순서, 모니터링, 통제된 복구를 설명합니다.

Next.js배포버전 불일치웹 캐시프런트엔드 신뢰성정적 리소스
2026년 8월 13일16 분 읽기

CFR을 깨뜨린 단 1 tick: 왜 5580은 5625가 아니었고 3751은 3750이 아니었나

제 검증기는 16 fps MP4에서 한 패킷의 지속시간이 5625가 아니라 5580 tick이라는 이유로 같은 작업을 반복해서 거부했습니다. 이후에는 24 fps에서 정확히 3750이어야 할 값이 3751로 나온 사례도 잡았습니다. 두 오류를 통해 소스 타이밍, CFR 양자화, MP4 타임 베이스, PTS/DTS, 멀티플렉싱, 패킷 단위 검증을 분리해서 보게 됐습니다.

FFmpegH.264CFR비디오 타임스탬프PTS와 DTSMP4 검증
2026년 8월 13일15 분 읽기

H.264로 실제 운영 영상 하나를 약 280 MB에서 약 50 MB로 줄인 방법

실제 운영 환경의 영상 하나가 H.264 구성을 CRF 28, x264 veryslow, 720p급 해상도 상한, 실제로 필요한 프레임률, 무리하지 않은 디코더 요구 조건을 중심으로 다시 설계한 뒤 약 280 MB에서 약 50 MB로 줄었다. 더 이전 단계에서는 같은 예시가 약 350 MB에서 238 MB로 이미 줄어 있었고, 옛 라이브러리 조사에서는 초당 수 메가비트급 H.264 파일이 흔했다.

H.264FFmpegx264영상 압축웹 성능미디어 최적화
2026년 4월 16일8 분 읽기

Gitae를 만든 이유: 웹사이트 장애를 단순한 ‘up/down’보다 깊게 진단하기 위해

Gitae는 ‘사이트가 정말 다운된 것인가, 아니면 내 환경만의 문제인가?’를 구분하기 위해 만든 도구입니다. 모스크바와 헬싱키의 외부 VDS에서 DNS, HTTPS/TLS, 포트, 라우팅, IP, 호스팅, CMS 신호를 확인하며, 각 결과를 최종 판정이 아니라 진단 근거로 다룹니다.

Gitae웹사이트 진단웹사이트 모니터링DNSSSLPingTraceroute포트 체크호스팅SEO
2026년 4월 14일7 분 읽기

프로덕션 개발에서 TypeScript와 Codex의 궁합이 특히 좋은 이유

프로덕션에서 TypeScript는 좋은 프롬프트만으로는 대체할 수 없는 것을 Codex에 제공합니다. 기계적으로 검증 가능한 계약, 빠른 컴파일러 피드백, 그리고 대규모 리팩터링을 더 안전하게 진행할 수 있는 경로입니다.

TypeScriptCodexAI 코딩소프트웨어 납품JavaScript개발 워크플로
2026년 4월 6일5 분 읽기

Jurfi.com을 만들었다: 구조화된 법률 문서 초안을 위한 브라우저 스튜디오

Jurfi.com은 폼과 템플릿을 브라우저 안에서 구조화된 법률 문서 작업 초안으로 만들고, 초안을 로컬에 보관하며, 검토를 명시적인 과정으로 남기기 위해 만든 서비스다. 소프트웨어가 변호사를 대체한다고 주장하지 않는다.

JurfiJurfi.com법률 문서리걸테크SaaS문서 초안브라우저 도구
2026년 4월 5일5 분 읽기

첫 SaaS 매출: 한 번의 결제가 실제로 증명한 것

직접 만든 SaaS에서 받은 첫 결제 금액은 작았지만, 제가 가진 증거의 질은 달라졌습니다. 한 번의 거래가 무엇을 검증할 수 있고 무엇은 증명하지 못하는지, 그리고 왜 그 순간보다 반복 가능성이 더 중요한지 정리했습니다.

SaaS첫 수익인디 개발자제품 검증제품 개발스타트업 여정개발자 경험
2026년 4월 3일11 분 읽기

Codex로 15개 프로젝트를 리뷰하면서 최종 통제는 사람이 유지하는 방법

15개 소프트웨어 프로젝트를 리뷰한다는 것은 예전에는 반복적인 확인 작업에 파묻히는 일이었습니다. Codex는 버그, 테스트, SEO, 번역, 현지화, 일관성 검사를 훨씬 빠르게 해주지만, 저는 AI의 finding을 결론이 아니라 단서로 보고 모든 변경을 직접 검증합니다.

CodexAI 코딩코드 리뷰소프트웨어 테스트개발 워크플로현지화기술 SEO개발자 생산성
2026년 4월 2일8 분 읽기

ChatGPT Plus Codex 한도 마지막 3–5%를 큰 개발 작업에 쓰는 이유 — 업데이트: 2026년 여름에는 더 이상 통하지 않았다

업데이트: 2026년 여름이 되자 이 workflow는 제 환경에서 더 이상 안정적으로 통하지 않았다. 계정에서 5시간 사용량 표시가 사라지고 주간 한도만 보였으며, 긴 작업은 주간 한도를 소진하면 중단될 수 있었다.

CodexChatGPT PlusAI 코딩 도구개발자 워크플로소프트웨어 엔지니어링TypeScript 마이그레이션ESLint 정리리팩터링Codex 사용 제한2026 업데이트
2026년 4월 1일12 분 읽기

AI로 SEO 글 1만 개를 발행했다가 Google 색인 페이지가 0개까지 떨어진 경험

대규모 AI 발행은 처음엔 지름길처럼 보였다. Google은 생성한 1만 개 글 URL을 모두 크롤링했지만, 실제로 색인되어 Search에 노출되고 트래픽을 만든 페이지는 약 1,000개뿐이었다. 이후 그 페이지들마저 사라지면서 결국 사이트 전체가 색인 페이지 0개까지 내려갔다. 이 경험은 AI, SEO, 번역, 편집 책임에 대한 내 접근을 완전히 바꿨다.

AI SEO생성형 AIGoogle 검색대규모 콘텐츠색인AI 보조 글쓰기다국어 SEO
2026년 3월 31일7 분 읽기

8GB/256GB M1 맥북을 5년 쓴 뒤: 아직도 바꾸지 않은 이유

약 1,000달러에 8GB 메모리와 256GB SSD의 기본형 M1 맥북을 샀고, 개발·영상·오디오·이미지 처리·글쓰기·학습·사이드 프로젝트에 하루 약 15시간씩 사용했다. 5년 뒤 한계는 분명히 보이지만, 업그레이드를 고민하는 이유는 기계가 쓸모없어졌기 때문이 아니라 내 워크로드가 커졌기 때문이다.

MacBookAppleM1Apple Silicon소프트웨어 개발장기 리뷰하드웨어 수명
2026년 3월 30일5 분 읽기

ChatGPT로 블로그를 20개 언어로 번역했더니 전 세계에서 검색 유입이 들어오기 시작했다

AI는 다국어 콘텐츠의 비용 구조를 완전히 바꿨다. 한 언어로 운영하던 블로그를 글마다 최대 20개 언어로 확장했고, 각 현지화 페이지가 새로운 자연 검색 유입 경로가 되었다.

AI 현지화다국어 SEOChatGPTNext.js국제 SEO블로그
2026년 3월 27일5 분 읽기

무료 정적 QR 코드 생성기 QRViz를 출시하고, 유입은 SEO에 맡겼습니다

QRViz는 캠페인 플랫폼이 아니라 브라우저 기반의 static QR code generator입니다. qrviz.com을 무료 QR 코드 생성기로 출시했습니다. 광고 예산, 유료 유입, 수익화 퍼널은 없습니다. 유입을 전적으로 SEO에 의존하고 있어 가장 큰 불확실성은 제품을 만드는 일이 아니라 사람들이 발견하게 만드는 일입니다.

QR 코드 생성기Qrviz제품 출시SEO사이드 프로젝트웹 개발제품 개발
2026년 2월 18일5 분 읽기

SaaS를 만드는 것보다 고객 확보가 더 어렵게 느껴진 이유

SaaS를 만들며 직접 배운 점이다. 엔지니어링은 명확하고 검증 가능한 피드백을 줬지만, 배포·포지셔닝·메시징·유지율은 전혀 다른, 훨씬 예측하기 어려운 루프를 요구했다.

SaaS 성장고객 확보제품 마케팅부트스트래핑공개 개발배포
2026년 2월 17일5 분 읽기

SaaS 제품을 혼자 만들었다. 결제를 켜자 일의 의미가 달라졌다

저녁, 주말, 휴일을 써가며 이 제품을 혼자 만들었다. 결제가 시작된 순간 버그, 온보딩, 모더레이션, 리텐션, 신뢰는 더 이상 나중 문제가 아니라 실제 제품 운영의 일부가 됐다.

SaaS1인 개발제품 출시PaymentsReliability제품 운영
2026년 1월 22일4 분 읽기

I Got 550 Views from One Image, Voiceover, and Subtitles: What Three Shorts Tests Actually Taught Me

A simple YouTube Short built from one static image, a voiceover, and subtitles reached 550 views. After three early tests, the useful lesson was not a proven formula, but a repeatable way to experiment without confusing a promising signal with proof.

YouTube ShortsContent ExperimentsShort-form VideoVideo EditingCapCutCreator Workflow
2026년 1월 20일6 분 읽기

모스크바 프론트엔드 공고에서 지원 약 6,000건을 봤다. 이 숫자가 러시아 IT 채용 시장에 대해 말해주는 것과 말해주지 않는 것

2023년 말에는 채용 담당자들이 공고 하나에 300–500건의 지원만 들어와도 많다고 말했습니다. 그런데 2026년 1월 20일, 모스크바의 미들급 프론트엔드 공고가 몇 시간 만에 약 6,000건의 지원에 가까워지는 것을 봤습니다. 이 숫자가 실제로 의미하는 신호와 증명하지 못하는 것, 그리고 후보자 입장에서 지금이라면 어떻게 읽을지를 정리했습니다.

커리어IT 채용 시장Frontend러시아모스크바채용구직
2026년 1월 1일5 분 읽기

DeepSeek가 제 Node.js 워크플로를 바꾼 과정: 6개월 동안 4,000개 이상의 커밋

2025년 제 GitHub 그래프는 상반기에는 거의 비어 있었지만 하반기에는 4,000개가 넘는 commit이 찍혔습니다. 이 글은 AI coding이 Node.js side-project workflow를 어떻게 바꿨는지, 어디서 시간을 줄였고 어디서 실패했는지, 그리고 왜 생성 속도보다 검증이 더 중요했는지를 정리합니다.

Node.jsDeepSeekAI CodingDeveloper ProductivitySide ProjectsSoftware Engineering
2025년 12월 30일6 분 읽기

My First TikTok at 28: What a Vertical Product Demo Taught Me About Traffic

At 28, I posted my first TikTok and cross-posted the same product demo to Reels and Shorts. The useful lesson was not the view count: it was how much a 9:16 frame changes a desktop interface, and how to measure short-form traffic without confusing reach with acquisition.

TikTokProduct MarketingProduct DemosAnalyticsIndie Dev
2025년 11월 16일7 분 읽기

25년 된 도메인을 샀더니 죽은 URL로 하루 1,000+ 요청이 들어왔다

2000년에 처음 등록된 도메인에 새 사이트를 올린 뒤, 옛 URL로 하루 1,000건이 넘는 요청이 들어오고 Yandex Webmaster에는 하룻밤 사이 900건이 넘는 오류가 쌓였습니다. 무엇을 실제로 확인할 수 있었는지, 왜 410을 선택적으로 썼는지, 지금이라면 오래된 도메인을 어떻게 점검할지 정리합니다.

SEOHTTPDevOps도메인웹 크롤링
2025년 11월 14일7 분 읽기

Yandex에는 12,500페이지가 색인돼 있었지만 러시아 트래픽은 거의 0이었다: 내가 놓친 Cloudflare 문제

Yandex에 12,500페이지가 색인돼 있었지만 러시아 트래픽은 거의 0이었다. 문제를 네트워크 경로로 좁힌 뒤 Cloudflare 프록시를 끄고 VDS의 Nginx로 캐시, 압축, 기본 보호를 옮겨 접근성을 복구했다. 핵심은 색인, 접근성, 트래픽을 같은 신호로 보지 않는 것이었다.

DevOpsSEONginxCloudflare네트워크인프라
2025년 10월 27일6 분 읽기

내 정적 Next.js 사이트에는 하루 수천 건의 취약점 스캔이 들어온다. Nginx는 거의 흔들리지 않는다

로그에는 WordPress, PHP 백도어, .env, .git/config를 찾는 probe가 계속 쌓인다. 하지만 정적 Next.js + Nginx 구성에서는 대부분 저비용 miss와 404로 끝났고, 관찰 중 CPU 부하는 변하지 않았다. 이 경험이 정적 사이트 보안에 대해 말해 주는 것과 말해 주지 못하는 것을 구분해 본다.

보안Next.jsNginxDevOps정적 호스팅Attack Surface
2025년 10월 27일5 분 읽기

Yandex는 새 사이트에 트래픽을 보내기 시작했지만 Google은 거의 움직이지 않았다

같은 새 프로젝트에서 Google은 긴 기간 동안 약 300클릭에 그쳤지만 Yandex Webmaster는 뚜렷한 상승세와 한때 +500% 클릭 증가를 보여줬습니다. 중요한 것은 이 숫자가 실제로 증명하는 것과 증명하지 못하는 것을 구분하는 일입니다.

SEOGoogle SearchYandexGoogle Search ConsoleYandex Webmaster테크니컬 SEO
2025년 10월 17일6 분 읽기

Yandex가 제 Next.js 페이지 4,278개를 하룻밤 사이에 색인했습니다 — 이것이 실제로 증명한 것

Next.js로 정적 생성한 페이지 4,278개가 거의 한꺼번에 Yandex 색인에 들어갔습니다. 분명한 기술적 이정표였지만, 검색 순위나 트래픽 성공의 증거는 아니었습니다. SSG와 프로그래매틱 SEO에 대해 이 결과가 말해 준 것과 말해 주지 못한 것을 구분해 봅니다.

SEONext.jsSSGYandex프로그래매틱 SEO색인
2025년 10월 16일7 분 읽기

SEO 첫 한 달: 오가닉 방문자 632명과 봇 트래픽을 의심하게 된 하루

직장에서 진행할 더 큰 SEO 이니셔티브를 준비하기 위해 개인 사이드 프로젝트를 실험 환경으로 사용했습니다. 한 달 동안 오가닉 방문자 632명을 얻었지만, 83명이 방문한 하루를 분석하면서 의심스러운 트래픽과 분석 도구의 한계가 결과를 얼마나 쉽게 왜곡할 수 있는지 배웠습니다.

SEO웹 분석봇 트래픽Yandex MetricaSEO 실험
2025년 10월 6일4 분 읽기

Yandex Webmaster를 거의 무시할 뻔했다. 2주 뒤 Google보다 더 많은 트래픽이 들어왔다

SEO가 중요한 업무 프로젝트를 앞두고 Next.js 사이드 프로젝트로 먼저 실전 경험을 쌓았다. 첫 2주 동안 Google에서 58명, Yandex에서 200명이 방문했고, 트래픽·색인·진단을 분리해서 봐야 한다는 걸 배웠다.

SEONext.jsGoogle SearchYandexSearch Console색인
2025년 10월 5일7 분 읽기

Yandex Metrica vs. Google Analytics: 일주일 뒤 내가 Metrica를 더 선호한 이유

새 프로젝트에서 Google Analytics와 Yandex Metrica를 일주일 동안 함께 운영했습니다. 제가 Metrica를 더 자주 열게 된 결정적 이유는 Webvisor의 세션 리플레이였습니다. 다만 이것은 제 작업 흐름에 대한 결론이지, 한 플랫폼이 모두에게 더 낫다는 증명은 아닙니다.

웹 분석UX세션 리플레이Yandex MetricaGoogle AnalyticsGA4
2025년 10월 3일5 분 읽기

Yandex가 /en 없이 내 블로그를 크롤링했다. 308 리디렉션이 404를 막아줬다

sitemap에 약 3,000개의 /en/blog/... 페이지를 추가한 뒤 Yandex가 대응되는 /blog/... 경로를 시도하는 것을 봤습니다. 미리 설정해 둔 308 리디렉션 덕분에 해당 요청은 404로 끝나지 않았습니다. 핵심은 Yandex가 sitemap을 “망가뜨렸다”는 이야기가 아니라, 정확한 리디렉션 계층이 URL 구조를 얼마나 견고하게 만들 수 있는지였습니다.

SEOYandexSitemap308 리디렉션테크니컬 SEO크롤링
2025년 10월 2일6 분 읽기

새 사이트 두 개가 Google에서 급등한 뒤 며칠 만에 트래픽이 약 10분의 1로 줄었다

두 번의 연속된 론칭에서 Google 노출이 즉시 급증한 뒤 며칠 만에 트래픽이 약 10분의 1로 떨어졌습니다. 패턴 자체는 실제였지만, 흔히 말하는 ‘Google 허니문’이 원인이라고 증명할 수는 없습니다.

SEOGoogle SearchSearch Console오가닉 트래픽테크니컬 SEO
2025년 10월 1일5 분 읽기

Yandex 검색에서 하룻밤 사이 2,000페이지가 사라졌다. 그때 실제로 확인할 수 있었던 것

Yandex Webmaster에서 약 8,000페이지 중 2,000페이지가 더 이상 검색에 참여하지 않는 것을 확인했다. 25% 하락은 컸지만, 더 중요한 교훈은 관찰된 검색 상태 변화와 입증된 원인을 구분하는 것이었다.

SEOYandex Webmaster인덱싱검색 가시성테크니컬 SEO
2025년 7월 11일3 분 읽기

MoscowJS 66에서 10개 넘게 질문했고 상 두 개를 받았습니다

MoscowJS 66에서 Telegram 봇, LangChain.js, 사이트 빌더 아키텍처, TypeScript 타입 테스트에 관한 발표를 들으며 10개 넘는 질문을 했습니다. 그중 두 개가 최고의 질문으로 선정되어 상 두 개를 받았습니다.

이벤트JavaScriptTypeScriptAILangChain.js커뮤니티MoscowJS
2025년 6월 23일7 분 읽기

PiterJS #79에서 가져온 것들: 레거시 모놀리스, FrontOps, 웹 성능, 그리고 더 나은 질문

상트페테르부르크의 PiterJS #79는 이미 존재하는 시스템을 유지하는 일에 초점을 맞췄습니다. 레거시 모놀리스, FrontOps, 웹 성능 지표에 대한 실용적인 메모와 Q&A에서 받은 두 개의 상, 그리고 오프라인 밋업은 직접 참여할 때 더 가치 있다는 생각을 가지고 돌아왔습니다.

PiterJSJavaScriptFrontOpsDocker웹 성능커뮤니티
2025년 6월 17일6 분 읽기

Next.js 블로그를 21개 언어로 공개했다. Google 노출 439회가 실제로 알려준 것

첫 주에 21개 언어로 만든 Next.js 블로그는 Google에서 439회 노출과 5회 클릭을 기록했습니다. 이후 471페이지 중 436페이지가 색인되었습니다. 가장 큰 교훈은 노출, 색인, 실제 검색 성과를 서로 다른 지표로 봐야 한다는 것이었습니다.

Next.jsSEOI18n다국어 SEOGoogle Search웹 개발
2025년 6월 7일4 분 읽기

JavaScript 6년 차에 다녀온 MoscowJS 65: 그래도 로컬 밋업에 가는 이유

2025년 6월 5일 T Bank에서 열린 MoscowJS 65에 참석했습니다. 네 개의 발표는 AI를 서로 다른 관점에서 다뤘지만, 제가 얻은 가장 큰 결론은 더 단순했습니다. 로컬 밋업에는 문서나 녹화 영상만으로는 완전히 대체하기 어려운 가치가 여전히 있습니다.

JavaScriptMoscowJS밋업개발자 커뮤니티AI