이야기를 디버깅하는 개발자.

개발과 창작 사이에서, 사람들이 자기만의 이야기를 만들 수 있는 도구와 기록을 만듭니다.

roslyn.dev 자세히보기

만드는 기록 21

Google 검색 생성형 AI 보고서에서 블로그 운영자가 볼 지표

블로그 글을 운영하다 보면 검색 유입이 줄거나 늘었을 때 원인을 알고 싶어집니다. 기존 Search Console 성과 보고서만으로는 웹 검색, Discover, 생성형 검색 경험에서 나타난 노출을 모두 같은 방식으로 해석하기 어렵습니다. Google은 2026년 6월 Search Console에 생성형 AI 검색 성과 보고서를 소개했고, 8월 31일 전 세계 배포를 알렸습니다.이 기능이 검색 유입을 늘려 주거나 특정한 AI 추천 위치를 보장하는 것은 아닙니다. 어떤 데이터를 별도로 보고할 수 있는지, 그리고 작은 블로그 운영자가 실제로 취할 수 있는 행동은 무엇인지 공식 안내를 바탕으로 살펴보겠습니다. Google Search Central 발표를 확인일 기준으로 참고했습니다.새 보고서는 어떤 질문에 ..

GitHub Copilot 코드 리뷰 비용, AI Credits와 Actions를 나눠 보기

AI 코드 리뷰 도구의 비용을 월 구독료 하나로 계산하기 어려워지고 있습니다. GitHub는 2026년 6월 1일부터 Copilot 사용을 AI Credits 기반으로 청구하고, Copilot code review는 AI Credits에 더해 일부 저장소에서 GitHub Actions minutes도 소비한다고 공지했습니다. 코드 리뷰를 자동으로 켜 두었다면 두 항목을 분리해 살펴볼 필요가 있습니다.이 글은 특정 계정의 청구 내역을 직접 확인한 비용 후기가 아닙니다. GitHub 공식 변경 공지와 과금 단위를 기준으로 작은 팀이 예상 비용을 관리할 때 확인할 지점을 정리합니다. 요금과 포함량, 플랜별 정책은 계정 종류와 시점에 따라 바뀔 수 있으므로 2026년 6월 1일 GitHub 공지와 현재 요금 문..

EmDash 1.0 이후, 개인 블로그를 직접 운영할 때 따져볼 비용과 권한

블로그를 직접 운영하고 싶다는 생각은 화면을 조금 더 자유롭게 바꾸고 싶은 순간에 찾아옵니다. 주소와 데이터, 편집 방식을 스스로 정할 수 있다는 점도 매력적입니다. 하지만 글을 쓰는 일보다 사이트를 고치는 일이 많아진다면 원래 목적과는 멀어질 수 있습니다.Cloudflare는 2026년 9월 28일 Astro 기반 오픈소스 CMS인 EmDash의 1.0 안정 버전과 플러그인 레지스트리를 발표했습니다. 새로운 선택지가 생겼다는 점은 흥미롭습니다. 다만 안정 버전이라는 이름과 내 블로그를 옮길 준비가 됐다는 판단은 따로 다뤄야 합니다.이 글은 EmDash로 블로그를 이전한 사용기가 아닙니다. 공식 발표를 10월 11일 확인하고 개인 운영자의 비교 기준을 정리한 검토안입니다. 제목의 1.0은 발표의 기준점이..

일본 철도 지도 프로젝트에서 배우는 작은 웹 도구의 차별화

개인 프로젝트를 생각하다가 비슷한 서비스가 있다는 이유로 접는 경우가 있습니다. 이미 검색도 되고 지도도 있는데 내가 하나 더 만들어야 할 이유를 찾기 어려워서입니다. 하지만 같은 데이터를 다루더라도 사용자가 무엇을 바라보게 하는지에 따라 도구의 인상은 달라질 수 있습니다.2026년 10월 5일 일본의 제작자 ‘地図とかデザインとか’는 약 600개 철도 노선의 조감도를 볼 수 있는 사이트 제작기를 공개했습니다. 옛 조감도 화가 요시다 하쓰사부로의 표현에서 출발한 작업입니다. 이 글에서는 그 제작기를 읽고, 작은 도구를 기획할 때 가져올 수 있는 판단 방법을 정리합니다.저도 서비스를 만드는 개발자이지만 이 지도 프로젝트의 구현이나 성능을 직접 검증한 것은 아닙니다. 제작자가 밝힌 사실과 제 기획 제안을 구분..

네이버 AI 검색에 일본 note 글이 들어옵니다: 개인 블로그가 점검할 세 가지

블로그를 운영하면 검색 화면이 달라졌다는 소식이 남의 일처럼 들리지 않습니다. 글을 더 잘 써야 하는지, 제목을 바꿔야 하는지, 다른 플랫폼에도 올려야 하는지부터 생각하게 됩니다. 그런데 이런 때일수록 무엇이 실제로 바뀌었는지와 내가 바꿀 수 있는 일을 나누어 볼 필요가 있습니다.일본의 창작 플랫폼 note가 네이버 AI 검색에 콘텐츠를 제공하는 시험을 소개했습니다. 한국어로 검색하는 독자가 일본 창작자의 글을 만나는 통로가 넓어지는 사례입니다. 21년 동안 웹 개발을 해 왔고 지금은 메리톡톡을 만들며 글도 쓰는 제게는, 특정 검색 기법보다 원문과 독자 사이의 관계를 다시 생각하게 하는 소식입니다.이 글은 검색 유입이 늘었다는 실험 보고가 아닙니다. 2026년 10월 11일에 확인한 공식 발표를 바탕으로..

베타 사용자 인터뷰를 이슈로 바꾸는 질문과 기록 방식

초기 서비스의 사용자는 ‘좋아요’라고 말해 주지만, 그 말만으로 무엇을 고쳐야 하는지는 알기 어렵습니다. 반대로 불편했다는 말도 어떤 상황에서 어떤 결과를 기대했는지 모르면 기능 목록으로 바뀌지 않습니다.이번 글에서는 베타 사용자 인터뷰를 제품 이슈로 변환하는 흐름을 기록합니다. 인터뷰의 목적은 좋은 아이디어를 많이 받는 것이 아니라, 반복해서 나타나는 문제를 작게 재현하는 데 있습니다.질문은 의견보다 최근 행동을 묻습니다‘어떤 기능이 필요합니까?’라는 질문은 상상 속 요구를 만듭니다. 저는 ‘최근에 이 작업을 언제 했습니까’, ‘그때 어디에서 막혔습니까’, ‘문제를 해결하려고 무엇을 했습니까’를 먼저 묻습니다. 실제 행동이 있어야 문제의 맥락을 알 수 있습니다.인터뷰 대상이 서비스를 사용하지 않았다면 ..

원고와 사진 파일의 버전·백업 정책을 직접 만든 기록

백업은 파일을 복사하는 일이라고 생각하기 쉽습니다. 하지만 복사본이 어디에 있는지 모르거나, 최신 버전인지 확인할 수 없거나, 복구해 본 적이 없다면 위기 때 백업은 존재하지 않는 것과 비슷합니다.저는 원고와 사진을 동시에 다루면서 파일의 종류보다 복구 시나리오를 먼저 정했습니다. 이번 글에서는 비용이 큰 시스템보다 혼자 유지할 수 있는 백업 정책을 설명합니다.원본·공개 자산·백업을 분리합니다작업 폴더에는 편집 중인 원본과 업로드용 변환 파일이 함께 생깁니다. 이 둘을 백업할 때 같은 폴더에 넣으면 무엇을 보존해야 하는지 모호해집니다. 저는 원본, 공개 자산, 백업을 저장 위치와 키 구조에서 구분합니다.원본은 수정 이력을 보존하고, 공개 자산은 다시 만들 수 있도록 생성 정보만 남깁니다. 백업은 현재 폴..

회원가입 없는 서비스의 스팸 방지 최소 장치

회원가입을 요구하지 않는 서비스는 진입 장벽이 낮다는 장점이 있습니다. 대신 한 사람이 반복 요청을 보내도 누구인지 구분하기 어렵고, 공격과 정상 사용을 구분할 정보가 부족합니다.저는 처음부터 복잡한 인증을 붙이기보다 서비스가 감당할 수 있는 행동의 범위를 정했습니다. 이번 글에서는 경로별 제한, 사용자 식별, 실패 응답, 관찰 지표를 최소 구성으로 나눠 보겠습니다.막아야 할 행동을 먼저 정의합니다스팸은 사용자라는 사람이 아니라 행동의 패턴으로 나타납니다. 짧은 시간에 같은 요청을 반복하거나, 파일 크기가 비정상적으로 크거나, 실패한 요청만 계속 보내는 식입니다. 무엇을 막을지 정하지 않고 방어 도구부터 붙이면 정상 사용도 함께 막힙니다.저는 엔드포인트마다 비용과 피해를 적습니다. 읽기 요청과 데이터 생..

작은 CLI 도구를 배포할 때 설정·로그·업데이트를 설계하는 법

개인적으로 쓰려고 만든 CLI는 실행만 되면 충분합니다. 그러나 다른 사람이 사용하기 시작하면 설정 파일이 어디에 있는지, 오류가 무엇을 뜻하는지, 업데이트 후 되돌릴 수 있는지를 설명해야 합니다.이번 글에서는 작은 도구를 배포할 때 코드 기능보다 먼저 결정해야 할 네 가지를 정리합니다. 패키지 레지스트리를 쓰든 실행 파일을 배포하든 공통으로 적용되는 기준입니다.첫 실행에서 알아야 할 것을 줄입니다CLI 사용자는 README를 끝까지 읽지 않고 명령을 실행합니다. 첫 실행에서 필요한 설정이 무엇인지, 기본 출력이 어디에 저장되는지, 실패했을 때 다음에 무엇을 해야 하는지가 바로 보여야 합니다.저는 설정을 명령행 인자, 환경 변수, 설정 파일 세 층으로 나누고 우선순위를 문서에 고정합니다. 비밀 값은 로그..

API 사용량 상한과 비용 알림을 붙인 기록

개인 프로젝트는 처음에 사용자가 적어 비용도 작습니다. 그래서 사용량 제한을 나중에 붙이려 합니다. 하지만 공개 주소가 알려지거나 자동화된 요청이 들어오면 비용과 장애가 동시에 커질 수 있습니다.저는 기능을 추가하기 전에 요청을 세고, 상한을 넘으면 알려 주고, 더 넘으면 안전하게 거절하는 흐름을 만들기로 했습니다. 이번 글에서는 숫자 자체보다 제한 정책을 정하는 순서를 설명합니다.API마다 비용과 위험이 다릅니다모든 엔드포인트에 같은 제한을 걸면 사용자는 불편하고 운영자는 중요한 기능을 구분하지 못합니다. 읽기 요청은 캐시로 흡수할 수 있지만, 외부 AI 호출이나 파일 변환은 한 번의 요청도 비용이 큽니다.저는 먼저 엔드포인트를 비용·시간·데이터 변경 여부로 나눕니다. 그 다음 사용자별 제한과 전체 제..

반응형