예전에는 웹호스팅 계정 하나를 만들고 파일을 올리면 서비스가 시작됐습니다. 지금은 서버리스 함수, 오브젝트 스토리지, CDN, 관리형 데이터베이스를 조합해 훨씬 빠르게 시작할 수 있습니다. 대신 어디서 문제가 생겼는지 추적해야 할 지점도 늘었습니다.저는 비용이 싸다는 이유만으로 구조를 고르지 않으려고 합니다. 월 요금보다 중요한 것은 장애가 났을 때 누가 무엇을 확인해야 하는지, 데이터가 어디에 있고 어떻게 복구하는지 알 수 있는가입니다.호스팅 시대에는 책임이 한 덩어리였습니다공유 호스팅에서는 운영자가 관리할 수 있는 범위가 제한적이었습니다. 웹 서버 설정과 데이터베이스가 이미 준비돼 있었고, 사용자는 파일과 애플리케이션에 집중했습니다. 문제가 생기면 고객센터에 문의하는 것도 운영의 일부였습니다.이 구조..

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

제 저장소 목록을 열어 이름을 하나씩 세어봤습니다. 시작만 하고 배포까지 가지 못한 프로젝트가 열 개가 넘었습니다. 그중 절반은 로그인 화면까지는 만들어져 있었고, 몇 개는 데이터베이스 설계 문서만 남아 있었습니다. 코드를 다시 열어보니 문제는 실력이 아니었습니다.공통점이 하나 있었습니다. 전부 처음 상상한 완성본이 너무 컸습니다. 만들려던 것 자체는 단순했는데, 거기에 회원 관리와 관리자 화면과 결제와 다국어가 자동으로 따라붙었습니다. 정작 만들고 싶었던 기능은 그 뒤에 있었고, 거기까지 도달하기 전에 흥미가 먼저 식었습니다.이 글은 그 반대로 가는 방법입니다. 기간을 2주로 못박고, 거기에 들어가지 않는 것을 전부 잘라내는 순서를 정리했습니다. 2주는 임의의 숫자가 아니라 흥미가 식기 전에 결과를 보..