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

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

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

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

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

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

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

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

혼자 운영하는 서비스에서 장애가 나면 코드부터 고치고 싶습니다. 그러나 사용자는 원인이 무엇인지보다 지금 사용할 수 있는지, 언제 다시 확인하면 되는지를 먼저 알고 싶어 합니다. 공지가 늦으면 작은 장애도 불안으로 커집니다.이번 글에서는 복잡한 상태 페이지 제품이 아니라, 혼자서 실제로 갱신할 수 있는 장애 공지의 최소 구성을 정리합니다. 관측 데이터와 공지 문장을 연결해 사후 회고까지 이어지는 흐름을 목표로 합니다.장애 공지는 네 가지 사실로 시작합니다첫 공지에는 원인을 추측해 쓰지 않습니다. 발생 시각, 영향 범위, 현재 조치, 다음 업데이트 시각 네 가지만 적습니다. 원인이 확인되지 않았는데 ‘서버 문제’라고 단정하면 나중에 공지를 다시 고쳐야 합니다.영향 범위는 모든 사용자가 아니라 특정 기능·지..

사용자가 0명인 서비스의 7일 리텐션은 몇 퍼센트일까요. 계산이 되지 않습니다. 분모가 0이기 때문입니다. 그런데도 많은 개인 서비스의 관리자 화면 첫 줄에는 DAU와 리텐션 자리가 마련되어 있고, 거기에는 대개 0과 하이픈이 표시되어 있습니다.관리자 화면을 먼저 만들어두는 편이 낫다는 이야기와, 로그 다음에 필요한 것이 상태를 보는 화면이라는 이야기는 앞서 따로 쓴 적이 있습니다. 이 글은 그 다음 단계입니다. 그래서 그 화면에 정확히 무엇을 몇 개나 넣을 것인가를 목록으로 정리합니다.기준은 하나입니다. 그 숫자를 보고 내일 할 일이 바뀌는가. 바뀌지 않는 숫자는 아무리 그럴듯해도 초기에는 자리만 차지합니다. 사용자 0명 구간에서 그 조건을 만족하는 항목은 생각보다 적습니다.0명일 때 의미가 생기는 다..

이전에 이 주제로 관점을 한 번 정리한 적이 있습니다. 자동 생성이 아니라 이어 쓰기여야 한다는 이야기였는데, 그때는 문제 제기에 가까웠습니다. 이번 글은 그 뒤의 기록입니다. 실제로 메리톡톡을 만들면서 어디서 멈출지, 무엇을 포기할지를 코드 단위로 정해야 했고, 그 결정들을 남겨둡니다.가장 먼저 확인한 것은 제 자신의 반응이었습니다. 초기 버전에서 문단 하나를 통째로 생성해 화면에 띄워봤는데, 문장은 꽤 그럴듯했는데도 손이 멈췄습니다. 고쳐 쓸지 지울지를 판단하는 동안, 원래 쓰려던 문장이 머릿속에서 사라졌습니다. 잘 쓰인 남의 문장이 내 문장을 덮어쓴 셈입니다.그때 알았습니다. 창작 보조 도구에서 진짜 위험한 것은 품질이 낮은 결과물이 아니라, 품질이 적당히 높아서 판단을 대신해버리는 결과물입니다. ..