사용자의 하루에서
불편한 순간 하나를
없애는 일을 합니다.

직접 만든 것

• 플로팅 비디오스크롤 위치를 읽어 영상을 화면 아래에 고정합니다. 고정한 자리에는 같은 높이의 빈 공간을 넣어 본문이 튀지 않게 했고, 닫으면 원래 자리로 돌아가며 상태를 초기화합니다.
• 페이지 로딩 컨트롤러화면을 덮는 대신 콘텐츠의 투명도를 0에서 1로 올립니다. 덮개 방식은 광고 로드를 막았기 때문입니다. 로딩 중에는 스크롤을 막고, 3초가 지나면 강제로 엽니다.
• 내한 공연 캘린더크롤러가 수집한 일정을 JSON으로 두고 캘린더가 읽어 그립니다. 날짜를 누르면 장소와 예매 링크가 나오고, 달을 넘길 수 있고, 모바일에서도 같은 표가 나옵니다.
• 접이식 목차카테고리마다 따로 접고 펼칩니다. 하나를 열어도 다른 것이 닫히지 않아서 여러 카테고리를 같이 볼 수 있습니다.
• 일본어 단어 카드JSON의 단어를 Fisher-Yates로 섞어 한 장씩 보여 주고, 발음과 뜻은 눌러야 보입니다. 카드마다 그 단어가 나오는 실제 가사 글로 이어집니다. 코츠코츠가 나온 뒤에는 블로그에서 내렸습니다.
• 채팅 위젯WidgetBot으로 디스코드 서버를 블로그에 붙였습니다. 마우스로 끌어 옮길 수 있고, 1040px을 기준으로 데스크톱과 모바일 화면을 나눴습니다.
• 운영 자동화번역 요청과 평점은 구글 폼으로 받아 시트와 독스에 정리했고, 앱스 스크립트로 시트를 자동 갱신했습니다. 지금은 쓰지 않습니다. 월간 순위 글은 엑셀로 순위 변동을 계산해 HTML을 만들어 올립니다.

블로그가 알려 준 것

방문자가 늘면서 사람들이 무엇을 찾아 들어오는지 보였습니다. 생각보다 많은 사람이 노래방 번호를 찾았고, 내한 공연 일정을 찾았습니다. 손으로 정리하던 카테고리 둘이 앱 둘이 됐습니다. 노래방 번호 모음은 14만 곡을 크롤러로 채우는 노래방 가자!가 됐고, 내한 캘린더는 예매처 네 곳을 모으는 MyCon이 됐습니다. 번역은 크몽에서 의뢰 77건을 받았습니다.

기술

직접 만든 것

• 웹은 곡마다 페이지, 앱은 목록에서 펼치기검색 엔진과 링크 공유가 필요한 곳은 웹이라서, 곡 페이지 14만 개와 아티스트 페이지 3만 개를 첫 요청 때 정적으로 만들어 CDN에 두고 신곡이 들어오면 그 경로만 다시 만듭니다. 사이트맵 3.8만 URL과 IndexNow로 새 곡을 바로 알립니다. 반대로 노래방에서 번호를 찾는 사람은 한 곡을 깊이 보지 않고 여러 곡을 훑기 때문에, 앱은 목록 안에서 곡을 펼치고 아코디언은 하나만 열립니다. 관련 곡이나 차트에서 파고들 때만 상세 창이 겹으로 쌓입니다.
• 검색은 코드보다 데이터였습니다곡 제목의 한글 발음 44,500개와 로마자 11,600개, 아티스트 로마자 38,400개를 만들고 직접 검수했습니다. 영문 제목은 토큰마다 발음 사전을 곱해 최대 16가지 변형을 두어 "미세스"로 쳐도 Mrs.가 잡힙니다. 검색은 시작 일치, 발음 시작 일치, 포함 순서로 세 단계를 거치고, 사용자와 커뮤니티가 올린 번역 표기까지 합쳐서 봅니다.
• TJ와 KY가 같은 가수를 다르게 씁니다TJ는 "가수(Feat.X)", KY는 "가수,X"로 쓰고, 같은 사람을 한글·영문·가나로 제각각 적습니다. 표기마다 페이지가 갈라지면 한 가수의 곡이 서너 곳으로 흩어지기 때문에 별칭 7,688개로 변형을 대표 표기 하나에 묶었습니다. 규칙으로 묶을 수 있는 것은 트리거가 묶되 같은 카테고리끼리만, 한 단계 연결만 허용합니다. 신곡의 feat. 표기는 별칭 표로 자동 분류하되 유일하게 맞거나 1위가 3표 이상이면서 2위의 두 배일 때만 채택합니다. 나머지는 다섯 개씩 손으로 봅니다. KY의 콤마는 대부분 합창이라 별칭이 아니었고, 보컬로이드 이름은 여러 프로듀서가 같이 써서 묶으면 안 되고, LISA와 LiSA처럼 카테고리가 다른 동명이인이 있습니다.
• 가입부터 시키지 않습니다번호 하나 찾으러 온 사람에게 로그인을 요구하지 않습니다. 즐겨찾기와 플레이리스트는 기기에 먼저 저장하고, 로그인하면 클라우드로 올라갑니다. 플레이리스트는 공유하고 커버를 올릴 수 있고, 곡마다 난이도·키·메모를 남깁니다. 커버는 복사본에 승계하지 않습니다. 원본 주인이 커버를 바꾸면 복사본이 깨지기 때문입니다.
• 가시성이 브랜드보다 앞섭니다테마는 배경 하나와 액센트 하나만 고르게 했습니다. TJ·KY 브랜드색은 공식 로고에서 채집한 뒤 WCAG 대비를 실측해, 다크용 실제 색과 라이트용 변형 두 벌로 고정했습니다. 글자 크기 4단계를 넣으면서 행간 토큰을 같이 만들어 21곳을 다시 연결했습니다. 행간이 21곳에서 제각각 비율로 박혀 있어 글자 배율을 따라가지 못했기 때문입니다.
• 번호 너머의 것곡을 펼치면 유튜브와 가사 원문, 댓글, 관련 곡이 나옵니다. 가사는 커뮤니티가 번역을 올리고 투표하며, 댓글에는 좋아요와 신고가 있습니다. 차트는 트렌딩·인기 아티스트·댓글 활발을 기간별로 보고 주간 스냅샷을 23주째 쌓습니다. 라운지의 VS 게임은 두 곡 중 하나를 끝없이 고르고 결과를 영구 URL로 남깁니다.
• 사람이 고르고 기계가 채웁니다신곡은 하루 다섯 번 TJ·KY에서 긁어 와 넣고, 카테고리는 두 사이트에서 다시 확인해 매깁니다. 앨범 커버는 Apple Music API로 맞춰 점수 0.75 이상이면 자동으로 붙입니다. 아티스트 이미지와 유튜브 ID, 일본어·한국어 가사는 크롤러가 후보를 모아 검토 화면에 올리고 제가 고른 것만 한 번에 적용하며, 영어 가사는 정확히 일치할 때만 자동으로 넣습니다. 가사 원문 11만 곡이 이렇게 쌓였고, 곡 소개 12,429편은 따로 씁니다. 쓰기는 전부 Supabase 함수 158개를 거쳐서 클라이언트가 테이블을 직접 만지지 않고, 크롤러는 Oracle Cloud의 cron이 돌립니다. 신고와 차단은 모더레이션 로그로 Discord에 갑니다.

운영하며 겪은 것

• 통계 패널이 DB를 멈춘 것 · 2026.06곡 페이지에 통계 패널을 붙였습니다. 처음에는 페이지를 열 때마다 28일 조회 추이, 시간대 분포, 보관 수, 재방문 비율을 RPC 넷으로 그 자리에서 계산했습니다. 곡마다 조회 기록 전체를 다시 훑으니 디스크 IO가 한도를 넘어 DB가 멈췄습니다. 해결은 DB에서 했습니다. 계산을 전부 하루 한 번 도는 배치로 옮겨 곡별 통계 표에 미리 써 두고, 페이지는 RPC 하나로 그 행만 읽습니다. 같은 날 안에 네 함수를 하나로 접었습니다.
• 리뷰 한 줄로 찾은 보관함 유실 · 2026.06"보관함에 저장해 둔 게 멋대로 날아감"이라는 리뷰가 왔습니다. 세션이 비면 무조건 로컬 보관함을 지우는 분기가 있었고, 사용자가 로그아웃하지 않아도 앱을 처음 켤 때와 토큰 갱신에 실패할 때 그 분기가 돌았습니다. 저장을 다 읽기 전에 지우는 경쟁까지 겹쳐 "멋대로"로 보였습니다. 직접 로그아웃할 때만 지우게 바꾸고, 읽기가 끝나기 전에는 쓰지 못하게 막았습니다.
• 발음이 증발하던 트리거 · 2026.06일본 곡에 손으로 넣은 발음이 사라졌습니다. 제목이 갱신될 때마다 트리거가 한·일 제목의 발음을 NULL로 밀고 있었습니다. 기존 값을 보존하도록 고쳤고, 지워진 발음은 백업에 남아 있어 되돌릴 수 있게 해 두었습니다.
• 조용히 어긋나던 곡 수 · 2026.07아티스트별 곡 수 캐시가 392건 틀려 있었습니다. 크롤러가 존재하지 않는 함수를 부르고 있었고, 실패가 조용히 폴백으로 넘어가 아무도 몰랐습니다. 곡이 늘고 줄 때마다 트리거가 다시 세게 하고, 모든 경로를 몇 번 겹쳐 돌아도 같은 결과가 나오게 만들었습니다.
• DB가 한 시간 멈춘 날 · 2026.08.10낮 배치가 늘어지며 DB가 한 시간 멈췄습니다. work_mem 256MB가 노드당 설정이라 배치 하나가 1GB 인스턴스를 압박했고, 커넥션 60개가 차서 뒤따르던 작업이 시작도 못 했습니다. 배치의 count(DISTINCT) 하나가 665만 행을 디스크에서 정렬하고 있었는데, 원천이 이미 DISTINCT라 결과가 같다는 것을 증명한 뒤 바꿔 762초를 30~50초로 줄였습니다. 그 과정에서 정렬 타이브레이커가 없어 추천 순서가 갱신마다 뒤바뀌던 버그도 찾았습니다. 신고도 에러도 없던 버그였습니다.
• 곡 페이지가 API의 절반을 먹던 것 · 2026.08.18곡 페이지가 관련 아티스트 여덟 명마다 별칭 해석 함수를 불러 렌더당 9회, 피크에는 시간당 15만 건으로 Supabase 호출의 절반이었습니다. 캐시에 든 값이 이미 정규화돼 있다는 것을 2,698건 전수로 확인하고 호출을 지워 1.64회로 줄였습니다.
• 봇을 막았더니 앱 이미지가 깨진 것 · 2026.08.18Vercel 방화벽의 봇 방어를 켰더니 앱의 아티스트 이미지가 깨졌습니다. 앱은 브라우저가 아니라 자바스크립트 챌린지를 통과하지 못하기 때문입니다. 이미지 경로만 우회 규칙으로 빼고, 레이트 리밋 규칙을 그 위에 두어 봇이 이미지 경로로 빠져나가지 못하게 했습니다.
• ISR이 걸려 있지 않았던 것 · 2026.08.30Vercel 청구가 보름에 36달러였고, 곡 페이지 하루 14.6만 호출이 CPU의 85%였습니다. 처음에는 재검증 주기가 짧다고 보고 배포까지 했지만 틀렸습니다. 응답 헤더가 no-store였고 빌드 라우트표에서 곡 페이지가 Dynamic이었습니다. generateStaticParams가 없어서 ISR이 걸리지 않고 매 요청 렌더하고 있었습니다. 빈 배열을 돌려주는 한 줄로 라우트가 SSG로 바뀌고 캐시가 맞기 시작했고, 하루 호출이 86% 줄었습니다. 선언값이 아니라 관측값으로 판정한다는 규칙이 여기서 생겼습니다.
• 로그아웃해도 오던 알림 · 2026.06로그아웃한 기기에 알림이 계속 왔습니다. 푸시 토큰 삭제를 기다리지 않고 세션을 먼저 끊어서, 권한 정책이 0행을 지우고 있었습니다. 세션이 살아 있을 때 이 기기 토큰만 지우고 끝나기를 기다리게 바꿨습니다.

기술

지금 이 값은 목돈의 스냅샷 CDN에서 옵니다

직접 만든 것

• 값은 모두에게 같은데 사람마다 계산하고 있었습니다시세 화면이 워커 API를 종목 단위로 불러서 코스피 한 페이지에 워커 요청이 6건이었고, 방문자 수만큼 늘었습니다. 발행기가 시세를 파일로 만들어 CDN에 올리고, 웹은 그 파일을 읽어 그리고 클라이언트가 폴링으로 갱신하게 바꿨습니다. 스키마, 하트비트, 파일 신선도, 분량 네 가지 게이트를 통과하지 못하면 워커로 돌아갑니다. 살아있음은 하트비트로, 신선함은 파일마다 따로 판정합니다. 합치면 장 마감 때 전 소비자가 폴백해서 CDN이 무의미해지기 때문입니다. 야간선물만은 마감 면제를 주지 않았습니다. 멈춘 값을 실시간처럼 보여 주는 것이 빈칸보다 나쁘기 때문입니다.
• 발행 주기는 값의 무게가 아니라 쓰기 건수로 정했습니다R2는 바이트가 아니라 건수로 과금합니다. 재 보니 쓰기의 94%가 하트비트와 지수였고 사용자가 보는 시세는 6%였습니다. 하트비트를 5초에서 20초로, 지수를 5초에서 10초로 늦추고 시세를 30초에서 5초로 당겨서 월 쓰기를 1.03M에서 771K로 줄이면서 사용자가 보는 값은 6배 신선해졌습니다. 여러 스케줄러가 동시에 깨어나 같은 파일을 8번 받던 것은 완료값이 아니라 약속을 캐시해 2번으로 줄였습니다.
• 스로틀을 지우고 렌더를 없앴습니다코스피·코스닥 2,500여 종목과 ETF 1,100여 개를 담은 스크리너가 틱마다 등락률로 재정렬되며 활발한 장에 렉이 났습니다. 먼저 써 본 2.5초 스로틀은 증상만 덮고 신선도를 잃었습니다. 표를 가상화해 DOM에 40행만 두자 재배치 비용이 사라져 스로틀을 뺐습니다. SSR로 40행을 먼저 내보내 검색 엔진과 첫 화면을 지켰고, 정렬은 정적인 시가총액으로 하고 표시값만 라이브로 해서 사용자가 잡은 행이 흔들리지 않게 했습니다.
• 갱신 패턴을 셋으로 나누고 이유를 적었습니다지수는 지수마다 5~7초 독립 타이머라 제각각 살아 움직입니다. 관심 종목은 요청은 한 번이지만 적용을 0~1.2초 흩뿌려 종목마다 펄스가 보입니다. 급등락 카드는 일부러 동시에 바뀝니다. 같은 데이터를 다르게 갱신하는 이유를 각각 설명할 수 있어야 한다고 생각했습니다.
• 비용은 추정하지 않고 재서 판정했습니다Cloudflare 청구를 항목 여덟 개로 계량하는 스크립트를 만들어 $23에서 $9로, 다시 $7.76으로 내렸습니다. 가장 큰 항목은 요청이 아니라 R2 쓰기였고, 워머가 매일 전 페이지를 훑는 것이 하루 쓰기의 45%였습니다. 페이지 안의 fetch 하나가 라우트 재검증 주기를 끌어내리는 것도 여기서 알았습니다. 회귀분석으로 방문자가 CPU를 설명하지 못한다는 것을 확인하고, 76~85%가 기계가 만드는 고정분이라 사용자를 겨냥한 최적화는 천장이 낮다고 판단해 멈췄습니다. 기본료가 청구서의 64%입니다.
• 탭을 늘리지 않았습니다메뉴를 찾으려고 검색하는 것이 사용자에게 최악의 경험입니다. 하단 탭은 사용자가 고르고 최대 4개, 나머지는 서랍에 넣어 탭 목적지 8개와 스택 화면 6개로 압축했습니다. 지표마다 툴팁, 체크리스트는 판정 문장, 용어는 하나로 통일했습니다. RSI 과매도는 팔레트에 파랑이 없어 초록으로 했고 그 이유를 주석에 적었습니다.
• 서버가 대신 지켜봅니다목표가와 등락률, 거래량 배수, 52주 고저, PER·PBR, 체크리스트 통과 개수, RSI 진입, 이동평균 교차 조건을 전부 서버가 평가해 푸시합니다. 빠른 조건은 5초마다, 느린 조건은 실행마다 한 번 봅니다. "오늘 봉" 판정은 시장의 현지 날짜로 해야 미국 장이 자정을 넘어도 틀리지 않습니다.
• 24시간 유튜브 라이브 2방송국장과 미장 화면을 미니PC가 렌더링해 1080p60으로 송출합니다. 지수 카드, 차트 넷, 히트맵, 실시간 순위, 하단 티커가 웹과 같은 컴포넌트와 토큰으로 돌아갑니다. 채팅 봇은 시세를 답하고 급변과 거래량 급증을 자동으로 띄웁니다.

운영하며 겪은 것

• 브라우저가 시세를 4시간 붙들고 있던 것 · 2026.07.30워커가 엣지 캐시용으로 내보낸 max-age 헤더를 Cloudflare 존 캐시가 브라우저 TTL 4시간으로 바꿔 쓰고 있었습니다. 11시 국장 방송 화면에 프리마켓 칩이 남아 있어 알아챘습니다. 엣지용 캐시 키를 따로 두고 브라우저에는 no-store를 보내도록 갈랐습니다.
• 하한가가 +30%로 뒤집혀 보인 것 · 2026.07.10네이버 응답의 등락 부호 코드를 잘못 읽어 하한가였던 펩트론과 HLB가 +30%로 보였습니다. 이후로 시세 소스를 붙일 때마다 하락 종목을 실제로 골라 부호를 확인합니다. 시간외 시세를 붙일 때도 같은 확인을 거쳤습니다.
• 방송 서버의 프레임 손실 · 2026.07.25전용 코어를 보장한다는 서버에서 하루 만에 프레임 손실이 38%까지 올랐습니다. 미장 방송 하나를 끄니 즉시 회복돼 누수가 아니라 용량 문제였고, 게스트가 놀고 있는데도 steal이 5~6%였습니다. 미니PC로 옮겨 부하가 15.6에서 4.5로 내려갔습니다.
• ISR 쓰기를 줄이려다 늘린 것 · 2026.08.11 ~ 22R2 쓰기를 줄이려고 재검증 주기를 올려 배포했는데 하루 쓰기가 10만 건대에서 줄기는커녕 13만까지 늘었습니다. 워머가 매일 전 페이지를 훑어 만료된 페이지를 전부 다시 만들고 있었고, 페이지 안의 5초짜리 fetch 하나가 라우트 주기를 끌어내리고 있었습니다. 워머를 주 1회로 줄이고 52곳의 주기를 한 시간으로 맞춰 쓰기가 하루 1.3만으로 떨어졌고 R2 비용이 $8.97에서 $0이 됐습니다.
• ETF 크롤러가 사흘 연속 죽어 있던 것 · 2026.08.058월 3일부터 사흘 연속 크래시해 ETF 750종이 닷새째 갱신되지 않았습니다. 행마다 키 집합이 달라 PostgREST가 배치 전체를 거부한 것이라 같은 키 집합끼리 묶어 보내게 했고, 이후 업서트는 키를 늘 채우고 값만 비우는 규칙을 세웠습니다.
• 방송 화면이 두 시간 넘게 깨진 채 송출된 것 · 2026.08.26크롬 렌더러가 파일 디스크립터 1,024개 한도를 넘어 죽었는데 브라우저 프로세스는 살아 있어서 systemd가 잡지 못했습니다. 메모리가 아니었습니다. 시세 파일 발행을 늦추자 같은 데이터를 12번 받으며 공유메모리 핸들이 새는 것이 방아쇠였습니다. 한도를 올리고 장 열기 전 새로고침을 예약했습니다. 새로고침 한 번에 핸들의 97%가 돌아옵니다.
• "스켈레톤이 안 풀린다" · 2026.09.01신고를 따라가니 스파크라인 하나가 한 달치 봉을 통째로 받아 6장에 3.3MB였습니다. 소비자는 마지막 96개만 씁니다. 지표 계산이 끝난 뒤에 개수를 자르는 인자를 두어 104KB로 줄였습니다. 먼저 자르면 앞쪽 봉의 이동평균이 비기 때문입니다.

기술

직접 만든 것

• 네 곳을 하나로 합칩니다NOL·멜론·예스24·티켓링크를 하루 27번쯤 HTTP 요청으로 긁어 오고, 브라우저는 티켓링크 토큰을 한 번 뽑을 때만 씁니다. 제목과 공연장을 정규화하고 날짜를 키로 삼아 같은 공연을 자동으로 묶어 195건을 병합했고, 손으로 고칠 때는 파일에 근거를 남기는 규칙을 두었습니다.
• 첫 화면에서 결정이 끝나는 상세가격, 오픈일, 러닝타임, 등급, 판매 상태, 예매 버튼을 첫 화면에 다 둡니다. 예매처가 여럿이면 나란히 비교하고, 회차와 장소, 지도가 이어집니다. 데스크톱은 헤더가 따라오고 모바일은 예매 버튼이 아래에 고정됩니다.
• 캘린더와 검색월 뷰에서 공연일과 티켓 오픈일을 토글로 오가고, 콘서트·내한·페스티벌·팬미팅을 네 색으로 나눕니다. 검색은 Cmd+K 팔레트로 어디서든 열리고, 250ms 디바운스에 키보드로만 고를 수 있습니다.
• 좁은 화면에 달력을 어떻게 넣을지데스크톱은 Fantastical에서 배운 두 칸 구조입니다. 왼쪽 작은 달력에서 언제를 고르고 오른쪽에서 무엇이 있는지 봅니다. 일·주·월 뷰를 두고 마지막 뷰를 기억합니다. 모바일에는 그 셋을 그대로 옮기지 않았습니다. 날짜 띠 하나가 기본이고, 달력 버튼을 누르면 달 전체가 펼쳐지고, 그 아래가 그날의 목록입니다. 띠와 펼친 달과 필터의 높이를 함께 움직여 스크롤하면 상단이 접힙니다. 펼친 달에서 ‹ ›는 보이는 달만 넘기고 선택한 날은 그대로 둡니다. 웹의 모바일 화면도 같은 구조를 쓰고, 상단의 달력 버튼을 누르면 캘린더 페이지가 시트로 내려옵니다. 시트는 표준 이징으로는 펼쳐지는 맛이 없어서 느리게 시작해 중반에 급가속하는 420ms 곡선으로 열고, 닫힐 때는 240ms로 빠르게 빠집니다.
• 상태를 세 등급으로 나눴습니다조작 상태를 다음 방문에도 남길 것, 이번 방문 동안만 남길 것, 열 때마다 초기화할 것으로 나눴습니다. 카테고리 필터는 며칠 뒤 들어왔을 때 "페스티벌"만 걸려 있으면 데이터가 사라진 것처럼 보여서 방문 단위로 내렸고, 저장하는 것은 기본 뷰뿐입니다. 전체와 내 일정 전환은 라우트가 아니라 상태로 바꿔서, 누를 때마다 보던 날짜와 달이 초기화되지 않게 했습니다.
• 저장과 알림로그인 없이 저장하고, 로그인하면 저장한 것이 합쳐집니다. 티켓 오픈과 공연 전날을 푸시로 알리고, 직접 일정을 넣을 수도 있습니다.
• 티켓북다녀온 공연이 티켓 스텁 한 장으로 남습니다. 노치는 mask와 radial-gradient로 파고, 노치를 따라 도는 1px 테두리는 4방향 drop-shadow로, 천공선은 SVG 점선으로 그렸습니다. 별점 0.5 단위, 사진 4장, 좌석, 가격을 적고 링크로 공유합니다. 공유 주소의 키는 닉네임은 바뀌고 uuid는 인증을 드러내고 시퀀스는 열거되기 때문에 셋 다 버리고, base62 8자를 암호학적 난수로 뽑았습니다.
• 통계는 숫자를 지어내지 않습니다포토 캘린더, 차트, 필름, 포스터 네 가지 뷰와 연말 결산 카드가 있습니다. 필름은 컷의 폭이 티켓값에 비례해 줄 길이가 곧 지출이고, 포토 캘린더는 같은 날 두 장이면 부채꼴로 겹칩니다. 헤드라인 숫자는 관람 횟수와 지출 둘로 절제했고, 기록이 없어도 축과 열두 달과 0회를 그대로 보여 줍니다. 안내 문장 대신 구조를 지키는 쪽을 택했습니다.
• 웹 채팅과 X 봇오픈 시각에 몰리는 1회성 사용자가 주 고객이라 채팅은 익명을 허용합니다. 메시지에 "그때 보던 공연" 칩이 붙고, 신고는 Discord로 가고, 킬 스위치가 있습니다. 익명 격리는 채팅보다 먼저 따로 커밋했습니다. 기본이 차단이고 채팅만 명시적으로 열리는 구조가 페이지마다 게이트를 고치는 것보다 안전하기 때문입니다. X 봇은 API 없이 Playwright 브라우저 자동화로 신규·오픈 공연을 2,995번 트윗했습니다.
• 디자인에서 정한 것액센트는 검정입니다. 강렬한 브랜드 색은 포스터와 충돌하고, 무채색이 포스터를 돋보이게 합니다. 모바일 후기 폼은 바텀시트가 아니라 풀스크린입니다. 필드가 많아 키보드가 올라오면 바텀시트는 짓눌립니다. 필수는 공연과 관람일 둘뿐이고, 게시판은 만들지 않았습니다. 혼자서도 쓸 수 있어야 초기의 빈 서비스를 견딥니다.

만들며 겪은 것

• 상세 페이지에서 네 번 틀린 것실패 네 가지를 적고 나서야 방향이 잡혔습니다. Spotify를 잘못 따라했습니다. 그것은 아티스트를 탐색하는 페이지고, 우리는 공연을 예매하는 페이지입니다. 목적이 다른데 구조를 베꼈습니다. 비주얼만 Spotify에서 배우고 구조는 티켓 사이트에서 가져오자 첫 화면만 보고 결정을 내릴 수 있게 됐습니다.
• 포스터 그리드를 버린 것티켓북의 첫 시안은 포스터를 격자로 늘어놓은 것이었는데 수집하는 감성이 없었습니다. 티켓 스텁 한 장이 기능의 인상을 좌우한다고 보고 그것부터 제대로 만들었습니다.
• 사라지지 않던 삭제 이벤트채팅에서 메시지를 소프트 삭제하면 Postgres Realtime이 새 행에 읽기 정책을 적용해 삭제 이벤트가 구독자에게 오지 않았습니다. 정책을 열고 본문을 비워서, 삭제된 행이 공개돼도 남는 것이 없게 했습니다.
• ‹ ›가 선택한 날을 끌고 가던 것 · 2026.07앱에서 펼친 달을 다른 달로 넘기는 유일한 수단이 ‹ ›였는데, 그것이 선택한 날까지 같은 날짜로 점프시켰습니다. 6월 27일에서 ›를 누르면 7월 3일을 고르기도 전에 7월 27일이 잡혀 목록이 바뀌었습니다. 보이는 달과 선택한 날을 다른 상태로 분리했습니다.
• 뒤로가기가 시트를 닫지 않고 페이지를 떠나던 것 · 2026.08모바일 캘린더 시트는 페이지처럼 보여서 사람들이 뒤로가기로 닫힐 것이라고 기대합니다. 열 때 히스토리에 표식을 하나 쌓고 popstate에서 닫게 해서 보던 페이지를 지키게 했습니다.
• 주 달력 칩의 첫 줄이 비던 것 · 2026.08주간 칸은 폭이 112px쯤이라 12px 한글이 아홉 자 들어가는데, "전주얼티밋뮤직페스티벌"은 어절을 지키면 첫 줄에 들어갈 수 없어 브라우저가 통째로 다음 줄로 밀었습니다. 넓은 곳은 어절을 지키고 좁은 칩에서만 포기하게 나눴습니다.

기술

직접 만든 것

• 뺀 것마다 이유를 적었습니다새 기능은 질문 셋을 통과해야 들어옵니다. 이게 없으면 단어를 못 외우나, 사람에게 새 판단을 요구하나, 재촉하거나 남과 비교하나. 예문, 랭킹, 로그인, 알림은 그래서 없습니다. 덜어냄은 안 만든 것의 변명이 아니라서 이유를 못 쓰면 미완성으로 봤고, 대가도 같이 적었습니다. 알림이 없어서 앱을 잊는 사람이 생기고, 계정이 없어서 기기를 바꾸면 백업 파일로 옮겨야 합니다.
• 요령은 앱이, 꾸준함은 사람이어느 단어를 언제 볼지는 FSRS-6이 계산합니다. 채점은 2버튼과 4버튼 중 고르고, 버튼마다 실제로 계산한 다음 간격을 보여 줍니다. 배우는 중인 카드는 20분 안이면 세션 안에서 다시 나오고, 되돌리기 20단계와 오늘은 넘기기, 전체 복습을 막지 않고 둡니다. 하루 신규 카드, 복습 상한, 목표 암기율, 하루가 바뀌는 시각까지 기본값은 좋되 전부 바꿀 수 있습니다.
• 기억 상태는 숫자가 아니라 온도로수치는 판단을 요구하고 색은 요구하지 않습니다. FSRS의 기억 확률을 색으로 바꿔 단어장의 LED 미터 12칸, 목록의 도트, 오십음도의 셀, 진행바까지 한 언어로 관통시켰습니다.
• 단순하지만 진보됨구조는 검증된 문법만 쓰고, 실험은 재질과 모션에서 합니다. 글자 크기는 여섯 단계로 잠그고 모션은 300ms 아래에서 transform과 opacity만 씁니다. 암기 카드는 끌기와 연동된 회전과 뒷카드 스케일이 실시간으로 따라오는 물리이고, 화면 전환은 우리 수준을 인정하고 미니멀한 애니메이션으로 갔습니다. 배경 블롭은 42~68초에 30px 움직이는데 60fps로 그릴 이유가 없어 초당 넷으로 갱신해 프레임 생산을 15~30분의 1로 줄였습니다.
• iOS와 Android가 100% 같은 화면플랫폼 종속 네이티브를 빼고 글래스 재질을 틴트와 보더와 그림자만으로 다시 만들었습니다. 웹에서 설계하고 검증한 뒤 앱으로 옮기는데, 경로 별칭을 웹과 같게 맞춰 라이브러리 아홉 개와 덱 데이터를 손대지 않고 옮겼고 RN 어댑터 셋만 바꿨습니다. 테마 색은 웹의 oklch를 브라우저 캔버스 픽셀로 뽑아 sRGB로 옮겼습니다.
• 데이터는 직접 만들고 검수했습니다코츠코츠는 가나 표제어를 발음만으로 맞추다 한자 뜻이 뒤섞인 오염을 발견해 정제, 메타, 뜻 확정 세 패스로 다듬었고, 한자가 있으면 한자를 표기로 삼는 표기 체계를 정해 판정 1,500건 넘게 근거와 함께 기록했습니다. 티엔티엔은 HSK 3.0 1~9급 전체를 담되 7~9급은 공식 배정이 없어 빈도순 3분할이라고 정직하게 썼고, 뜻 11,092건을 전건 검수했습니다. 피터패터는 CEFR-J 하나만 등급 정본으로 삼고, 미국식과 영국식을 나란히 두고, 불가산 명사에 잘못 붙은 복수형 66장을 걷어냈습니다.
• 발음은 통째로 받아 오프라인에서Google Cloud TTS로 네 목소리를 미리 만들어 두고, 파일 16,455개를 색인이 든 팩 하나로 받습니다. R2 앞에 워커를 두어 캐시와 CORS 헤더를 직접 붙였고, 키가 내용 해시라 1년 불변 캐시입니다. 무료 한도를 실측하니 SSML 태그가 과금에 들어가 순수 글자의 15배였고, Standard 목소리로 바꿔 전량 무료로 만들었습니다.
• 덱을 번들에서 빼고 DB 둘을 붙였습니다"왜 덱을 캐시에 넣어야 하지"라는 질문에서 전제 오류를 잡았습니다. 번들러가 JSON을 모듈로 굽고 이미 캐시하고 있어서, 할 일은 캐시가 아니라 번들에서 빼는 것이었습니다. 진도 DB와 덱 DB를 둘로 나눠 붙여 콘텐츠 갱신이 진도를 건드리지 않게 했고, 갤럭시 S10 실기기로 여덟 단계를 전후 대조했습니다.

만들며 겪은 것

• 에러 없는 스케줄 버그 · 2026.08.15학습 단계 인덱스가 저장에서 빠져 매 세션 0단계로 리셋됐습니다. Good을 눌러도 다음 복습이 영원히 10분이었는데 화면은 정상이고 에러도 없었습니다. 저장, 복원, 채점을 노드에서 왕복시켜 재현했고, 상태를 저장할 때는 복원했을 때 같은 미래가 나오는지를 검증하게 됐습니다.
• 가나 표제어 오염 · 2026.08.14단어 데이터를 만들 때 가나 표제어를 발음만으로 맞춰서 사탕과 비가 한 카드에 섞이는 식의 오염이 있었습니다. 충돌 66건을 걷어내고 JMdict 태그로 대조한 뒤 표기 체계를 확정했습니다.
• 성조 부호만 색칠하기 · 2026.08.22음절 전체를 칠하면 알록달록해서 기각했고, 결합 부호를 스팬으로 쪼개면 ǚ의 점이 사라졌습니다. 부호만 색칠하는 표준이 없다는 것을 확인한 뒤 전략 세 벌을 만들어 비교했고, 11,092장을 NFC로 정규화하면 결합 부호가 남지 않는다는 것을 실측해 합성 글자 하나만 칠하는 쪽을 택했습니다.
• 로드만 되고 안 쓰이던 한자 폰트공용 Text 래퍼가 굵기를 Pretendard로 강제해서 HarmonyOS Sans가 로드만 되고 쓰이지 않았습니다. 反은 고딕이고 应은 명조로 보이는 혼재로 발견했습니다.
• 한 파일을 나눠 쓰던 발음 62쌍발음 파일 키를 표기만으로 해시해서 还처럼 읽기가 둘인 글자 62쌍이 파일 하나를 공유했고 한쪽은 틀린 소리가 났습니다. 키를 표기와 병음을 합친 해시로 바꿨습니다.
• r2.dev 공개 주소는 프로덕션 부적격스로틀 503에 CORS 헤더가 없어 앱이 실패 이유조차 읽지 못했고, 캐시 없이 요청마다 0.6초가 걸렸습니다. 버킷 앞에 워커를 두고 헤더를 직접 붙였습니다.
• 안드로이드 블러를 포기한 것진짜 블러를 쓰려고 라이브러리에 패치까지 넣었다가 자기 포함 크래시와 자글거림 때문에 걷어냈습니다. 틴트와 보더만으로 같은 인상을 내는 쪽이 두 플랫폼을 같게 만드는 길이었습니다.

기술