1인 개발로 웹 도구를 만들고 운영하며 배운 것들을 중간 결산으로 정리합니다. 제작 노트 카테고리에서 지금까지 도구를 만든 이유, 설계 기준, 데이터 소스, 무료 공개 철학, 그리고 사용자 피드백으로 바뀐 기능들까지 이야기했습니다. 이번 글은 그 여정을 기술적인 교훈과 기술 바깥의 교훈으로 나누어 돌아보는 자리입니다. 거창한 성공담이 아니라, 혼자서 무언가를 만들어 운영해 보려는 분들이 미리 알았으면 좋았을 현실적인 이야기들입니다. 잘한 판단보다 틀린 판단이 더 많이 등장할 예정입니다.
1인 개발에서 배운 기술적 교훈
만드는 시간보다 운영하는 시간이 길다
1인 개발을 시작하기 전에는 완성이라는 단어를 믿었습니다. 기능을 다 만들면 끝이라고 생각했습니다. 그런데 도구를 공개하는 순간 알게 됐습니다. 완성은 시작일 뿐이었습니다. 공개 이후의 시간은 이렇게 흘러갑니다. 데이터가 제대로 조회되는지 수시로 확인하고, 외부 데이터 소스의 정책이 바뀌면 대응하고, 사용자 의견을 분류하고, 서버 상태를 점검합니다. 코드를 새로 짜는 시간보다 이미 만든 것을 지키는 시간이 더 깁니다. 배포 기록을 열어보면 이 사실이 그대로 드러납니다. 6월 한 달 동안만 스무 번 가까이 배포가 있었는데, 목록을 살펴보면 새 기능 추가보다 파일 교체와 설정 수정이 대부분이었습니다. 눈에 보이는 변화는 거의 없지만 손은 계속 가는 작업들입니다.
혼자 유지할 수 있는지를 먼저 묻는다
그래서 혼자 도구를 만들려는 분께 드리는 첫 조언은 이것입니다. 이 기능을 만들 수 있는가보다 이 기능을 혼자서 계속 유지할 수 있는가를 먼저 물어보세요. 그 질문 하나가 기능의 개수를 줄여주고, 결과적으로 도구의 수명을 늘려줍니다. 만들고 싶었지만 유지 부담 때문에 접은 기능이 실제로 여러 개 있습니다. 1인 개발의 진짜 비용은 개발 기간이 아니라 운영 기간에 있다는 것이 첫 번째 배움이었습니다.
기술 선택의 기준은 유행이 아니라 회복 속도다
기술 스택을 고를 때 저는 가장 유명한 것도, 가장 새로운 것도 아닌 문제가 생겼을 때 혼자서 가장 빨리 복구할 수 있는 것을 골랐습니다. 팀이 있다면 낯선 기술에 도전하는 비용을 나눠 질 수 있지만, 1인 개발에서는 새벽에 도구가 멈추면 그걸 고칠 사람도 저 하나뿐이기 때문입니다. 이 기준은 실제로 여러 번 저를 구했습니다. 자동 배포 구조를 만들어 둔 덕분에 배포 한 건이 6초에서 9초면 끝나고, 관리형 서비스를 쓴 덕분에 서버 자체를 손볼 일이 거의 없었습니다. 화려한 기술로 만든 느린 도구보다, 익숙한 기술로 만든 안정적인 도구가 사용자에게는 백 배 낫습니다. 배포가 10초 안에 끝난다는 것은 문제를 발견하고 고치는 주기도 그만큼 짧아진다는 뜻입니다. 도구를 쓰는 사람은 그 도구가 무엇으로 만들어졌는지 아무 관심이 없다는 당연한 사실을, 만드는 사람은 자주 잊습니다.
1인 개발에서 비용과 판단을 관리하는 방법
비용은 금액이 아니라 구조로 관리한다
무료 도구 운영에서 비용 이야기를 빼놓을 수 없습니다. 이전 글에서 무료 공개의 철학을 이야기했지만, 철학은 통장 잔고 앞에서 시험받기 마련입니다. 1인 개발에서 배운 비용 관리의 핵심은 금액을 줄이는 것이 아니라 구조를 단순하게 유지하는 것이었습니다. 구체적으로는 세 가지를 지켰습니다. 첫째, 고정비가 늘어나는 결정은 최대한 늦춥니다. 둘째, 사용량에 따라 비용이 늘어나는 항목은 상한을 정해두고 감시합니다. 셋째, 유료 전환이 필요한 시점의 기준을 미리 정해둡니다. 수익이 없는 기간에는 버티는 구조를, 수익이 생기면 그때 확장하는 구조를 준비하는 것입니다. 이 순서를 지킨 덕분에 도구는 수익 없이도 계속 운영될 수 있었습니다. 유료 전환이 필요해진 시점에도 미리 정해둔 기준이 있어서 망설임 없이 결정할 수 있었습니다.
혼자 만들지만 혼자 판단하지 않는다
역설적이지만 혼자 개발할 때 가장 위험한 것은 혼자 판단하는 습관이었습니다. 사용자 피드백으로 바뀐 기능들을 정리한 지난 글에서 확인했듯, 개발자의 확신은 자주 틀립니다. 무반응 화면이 문제인 줄 몰랐고, 지표가 많으면 좋은 줄 알았고, 재조회 수요가 있는 줄 몰랐습니다. 세 가지 모두 제가 확신하고 있던 판단이었는데, 셋 다 틀렸습니다.
판단의 근거를 밖에서 가져온다
그래서 지금은 판단의 근거를 밖에서 가져오는 습관을 들였습니다. 기능을 바꾸기 전에 사용 기록을 먼저 보고, 의견이 두 번 이상 반복되는지 확인하고, 바꾼 뒤에는 반응을 다시 관찰합니다. 혼자 일한다는 것은 모든 일을 혼자 한다는 뜻이지, 모든 판단을 혼자 내린다는 뜻이 아니었습니다. 혼자 일한다는 말이 주는 오해가 정확히 여기에 있습니다.
1인 개발자가 신뢰를 얻는 방법
블로그가 곧 도구의 얼굴이다
마지막 배움은 이 블로그 자체에 관한 것입니다. 처음에는 도구 따로, 블로그 따로라고 생각했습니다. 그런데 운영해 보니 둘은 한 몸이었습니다. 도구가 어떤 원칙으로 만들어졌는지, 데이터를 어디서 가져오는지, 왜 무료인지를 블로그에 기록해 두자, 그 기록이 도구에 대한 신뢰의 근거가 되었습니다. 제작 노트 카테고리에 쌓인 글들이 그 역할을 하고 있습니다. 도구 화면 캡처와 설계 판단을 함께 남긴 글이 아홉 편인데, 이 기록이 도구 소개 문구 하나보다 설명을 잘 해줍니다.
브랜드가 없는 자리를 기록이 채운다
1인 개발자에게는 회사 이름도, 브랜드 인지도도 없습니다. 그 빈자리를 채우는 것이 투명한 기록입니다. 무엇을 만들었는지가 아니라 어떻게 만들었는지를 보여주는 것, 그것이 혼자 만드는 서비스가 신뢰를 얻는 가장 현실적인 방법이라고 지금은 믿습니다. 실패한 판단까지 함께 적어두는 것이 오히려 신뢰를 만든다는 것도 알게 됐습니다. 성공만 적힌 기록은 광고처럼 읽히지만, 실패가 섞인 기록은 사람이 쓴 것으로 읽힙니다.
우선순위의 문제였다
다섯 가지 배움을 관통하는 결론은 하나입니다. 1인 개발은 기술의 문제라기보다 우선순위의 문제입니다. 무엇을 만들지보다 무엇을 만들지 않을지, 어떤 판단을 혼자 내리고 어떤 판단을 데이터에 맡길지를 정하는 일이 혼자 일하는 사람의 진짜 기술이었습니다. 기술을 더 배우는 것보다 이 우선순위를 정하는 데 시간을 쓰는 편이 결과적으로 도구를 오래 살립니다.
자주 묻는 질문
1인 개발로 웹 도구를 운영하는 데 가장 큰 비용은 무엇인가요?
개발 기간이 아니라 운영 기간입니다. 데이터 소스 정책 변경 대응, 상태 점검, 의견 분류처럼 이미 만든 것을 지키는 일에 대부분의 시간이 들어갑니다.
기술 스택은 어떤 기준으로 고르면 되나요?
문제가 생겼을 때 혼자서 가장 빨리 복구할 수 있는 것을 고르는 것이 안전합니다. 새벽에 멈춰도 고칠 사람이 본인뿐이라면 회복 속도가 유행보다 중요합니다.
수익이 없는데 유료 인프라를 써도 되나요?
고정비가 늘어나는 결정을 최대한 늦추고, 사용량 기반 항목에는 상한을 걸어두는 구조라면 감당 가능합니다. 유료로 전환할 시점의 기준을 미리 정해두는 것이 핵심입니다.
혼자 개발할 때 판단 실수를 줄이는 방법이 있나요?
사용 기록을 먼저 보고, 같은 의견이 두 번 이상 반복되는지 확인한 뒤에 바꾸는 것입니다. 혼자 만드는 것과 혼자 판단하는 것은 다른 문제입니다. 사용 기록이라는 근거가 있으면 확신이 틀렸을 때 빨리 알아차릴 수 있습니다.
그리고 요즘 혼자 개발하는 사람과 혼자 쓰는 블로거에게는 강력한 지원군이 하나 더 생겼습니다. 바로 AI입니다. 다음 글부터는 카테고리를 옮겨서, AI를 키워드 분석과 콘텐츠 제작에 실제로 어떻게 활용하는지, 그리고 어디까지 믿어도 되는지를 실전 중심으로 다뤄보겠습니다.