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

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

개인 서비스를 만들 때 저는 기능보다 예산 상한을 먼저 정합니다. 월 1만 원. 이 숫자에 특별한 근거가 있는 것은 아니고, 커피 두어 잔 값이라 서비스가 잘 안 되더라도 감정 없이 계속 둘 수 있는 금액이기 때문입니다. 유지비가 이 선을 넘기 시작하면 판단에 감정이 섞입니다.상한을 먼저 정하면 설계가 달라집니다. 상시 켜둘 서버가 정말 필요한지, 이미지를 서버에서 변환해야 하는지, 로그를 얼마나 오래 둘지가 전부 비용 문제로 바뀝니다. 기능을 다 만든 뒤에 요금을 줄이려 하면 대개 구조를 뜯어야 해서 잘 줄지 않습니다.이 글에서는 구체적인 가격을 적지 않습니다. 요금제는 자주 바뀌고 지역과 계정 상태에 따라서도 달라지므로, 지금 적어두면 얼마 못 가 틀린 글이 됩니다. 대신 비용이 어떤 단위로 매겨지는..

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