창업과 자동화 기록 – 아이디어에서 실험, 실패, 수정까지
노션을 쓰다 보면 어느 순간 이런 날이 온다. 갑자기 페이지가 안 만들어지고, 업로드도 막히고, 뭔가 답답한 경고가 뜬다. “용량이 찼습니다.” 유료로 넘어가면 시원하게 끝날 문제다. 근데 솔직히… 매달 구독이 하나씩 늘어나는 세상에서, 모든 걸 결제로 해결하기엔 내 지갑이 너무 인간적이다. 그래서 나는 결국 우회로를 택했다. 새 계정을 만들어 새 워크스페이스를 하나 더 만들고, 필요한 페이지들을 계속 읽기 →
노션 무료 용량이 찼을 때 내가 선택한 우회로 더 읽기"
이번 주에 내가 만든 건 단순히 채팅 기능이 아니다. 앱 안에 “사람과 사람 사이의 길”을 하나 뚫어 둔 것에 가깝다. 마켓이든 동네 앱이든, 결국 마지막은 늘 이 한 문장으로 귀결된다. “혹시 지금 가능하세요?” “네, 어디서 볼까요?” 그 대화를 앱 안에서 시작할 수 있게 만드는 것. 그게 이번 5주차의 목표였고, 결론적으로 Chat V1을 완성했다. 이번 주의 계속 읽기 →
5주차 빌드 로그: 채팅 V1 — 거래는 결국 대화다 더 읽기"
— 건강 기록 앱에서 “언제”의 의미를 다시 묻다 오늘 하루를 돌아보면, 코드보다 더 많이 만진 건 시간이었다. 정확히 말하면, 숫자로 찍히는 시간이 아니라 의미를 가진 시간. 문제는 사소해 보였다 처음 시작은 단순했다. 모바일에서 회원가입이 안 된다 회색 레이어가 화면을 덮고 클릭이 안 된다 기록 시간이 현재 시간이 아니다 수정했다는데 여전히 반영이 안 된다 흔한 버그처럼 계속 읽기 →
4주차의 목표는 단순했다. 사람들이 글(포스트)을 더 잘 찾게 만들기. 근데 개발은 늘 그렇다. 검색 기능 추가는 쉬운데, 검색이 풀리지 않게 만드는 건 어렵다. 검색어를 넣고, 필터를 고르고, 정렬까지 선택해놓고 2페이지를 눌렀더니… 전부 초기화. 이건 사용자가 아니라, 개발자가 사람을 배신한 UX다. 그래서 이번 주는 기능보다 더 중요한 것— 문맥(context)을 지키는 검색 경험을 만드는 데 집중했다. 1) 계속 읽기 →
4주차 빌드 로그: 검색이 풀리지 않게 만들었다 더 읽기"
시간이 어긋난 앱은 몸을 맡길 수 없다 오늘 하루를 한 문장으로 요약하면 이거다. 시간이 틀린 건강 앱은 신뢰를 잃는다. 💡 시간이 틀리면,기록은 그냥 메모가 된다. 문제의 시작: 기록했는데, 지금이 아니다 건강 기록을 남겼다. 오한이 와서 타이레놀을 먹었고, 몇 시간 뒤 한 알을 더 먹고 괜찮아졌다. 그날의 몸 상태를 있는 그대로 남겼다. 그런데 기록 화면에 찍힌 계속 읽기 →
UV 프린터를 샀다. 그리고 첫 작품을 찍었다. 2026년은 붉은 말의 해. 그래서 말을 찍기로 했다. 왜 말이었을까 처음 프린터를 받고 뭘 찍을지 한참 고민했다. 테스트용으로 간단한 로고? 사진? 텍스트? 근데 그건 “테스트”지 “작품”이 아니잖아. 첫 번째 출력물은 기록으로 남는다. 그래서 의미 있는 걸 찍고 싶었다. 2026년, 붉은 말의 해. 앞으로 달리는 말. 늦깎이지만, 여전히 달리는 계속 읽기 →
— 512MB에서 2GB로, 생각보다 험난했던 여정 시작은 단순했다 choviet.chat은 베트남 커뮤니티를 위한 서비스다. 당근마켓처럼 중고거래, 질문답변, 자유게시판이 있다. 그런데 서버가 512MB RAM이었다. MVP라서 작게 시작했지만, 아무리 MVP라도 512MB는 너무 작았다. 이미지 업로드, 검색, 실시간 알림까지 생각하면 최소 1~2GB는 필요했다. “업그레이드하자.” 단순한 결정이었다. 그런데 Lightsail은 단순하지 않았다. Lightsail의 불편한 진실 AWS Lightsail에서는 인스턴스를 직접 업그레이드할 수 계속 읽기 →
Lightsail 인스턴스 업그레이드 삽질기 — 512MB에서 2GB로, 생각보다 험난했던 여정 더 읽기"
— 422 에러의 진짜 원인은 SSL이었다 증상은 단순했다 PC에서는 회원가입이 잘 됐다. 그런데 모바일에서 가입 버튼을 누르면 이런 메시지가 떴다. 422 Unprocessable Entity “The change you wanted was rejected.” 같은 서버, 같은 코드, 같은 폼. 왜 모바일에서만? 처음엔 흔한 용의자들을 의심했다 Rails에서 422 에러가 나면 보통 이런 것들을 먼저 본다. CSRF 토큰 문제? Turbo가 뭔가 계속 읽기 →
모바일에서만 회원가입이 안 됐던 이유 — 422 에러의 진짜 원인은 SSL이었다 더 읽기"
배포가 성공했다는 건, 사실 끝이 아니라 시작이다. 특히 혼자 만들고, 혼자 배포하고, 혼자 책임지는 프로젝트라면 더 그렇다. healthnote는 며칠 전 무사히 프로덕션에 올라갔다. 도메인도 붙었고, 모바일에서도 접속된다. 겉으로 보면 “이제 되는 것처럼” 보인다. 하지만 진짜 일은 그다음부터 시작됐다. CI가 말을 걸어오기 시작했기 때문이다. “로컬에서는 되는데요?” CI 에러의 시작은 늘 이 문장이다. 로컬에서는 되는데요? 이번에도 그랬다. 계속 읽기 →
CI는 고쳐야 할 문제가 아니라, 말을 걸어오는 방식이다 더 읽기"
— 늦깎이 건강노트 개발일지 4화 오늘 나는 오랜만에 “이게 정말 끝났구나”라는 감각을 느꼈다. 물론, 개발은 끝나지 않았다. 하지만 ‘서버 에러와 싸우는 시간’은 끝났고, 이제는 ‘앱을 쓰는 사람’의 자리로 돌아올 수 있게 됐다. 배포는 성공했지만, 마음은 아직 안심이 안 됐다 며칠 전 Senior HealthNote는 분명히 배포에 성공했다. Kamal, Docker, PostgreSQL, Solid Cache/Cable/Queue… Rails 8이 요구하는 것들을 계속 읽기 →
배포 이후, 앱은 살아 있었고 나는 다시 사용자로 돌아왔다 더 읽기"
