글자 크기

빌드

창업과 자동화 기록 – 아이디어에서 실험, 실패, 수정까지

조비엣 빌드로그 4주차: 이미지를 상태에서 화면으로 옮기는 일

3주차에서 결론을 하나 냈다. 이미지 확대는 연출이 아니라 라우팅이다. 그 말은 멋있어서 한 말이 아니다. Turbo Native 앞에 서면, 웹에서 “그냥” 하던 것들이 전부 질문으로 돌아온다. 이게 화면이야? 오버레이야? 뒤로가기는 어디로 가? 캐시는 남아? 안 남아? 이걸 공유하면 어디로 열려? 이미지가 URL을 가져야 하는 이유는, 예쁘게 보이기 위해서가 아니라 흔들리지 않기 위해서다. 이번 4주차는 그 계속 읽기 →

조비엣 빌드로그 4주차: 이미지를 상태에서 화면으로 옮기는 일 더 읽기"

조비엣 빌드로그 3주차: 이미지는 어디로 가야 하는가

지난주에 우리는 길을 닦았다. /me로 내 프로필을 고정하고, 로그인 후 랜딩을 /posts로 통일하고, PathConfiguration로 “어떤 화면을 탭으로, 어떤 화면을 모달로” 규칙을 만들었다. 그때부터 조비엣은 그냥 웹앱이 아니었다. 앱의 문법을 갖기 시작했다. 그리고 이번 주, 그 문법이 가장 먼저 부딪히는 질문이 하나 있었다. 이미지는 어디로 가야 하지? 웹에서는 이미지 클릭하면 그냥 확대하면 된다. 하지만 Turbo Native로 계속 읽기 →

조비엣 빌드로그 3주차: 이미지는 어디로 가야 하는가 더 읽기"

조비엣 빌드로그 2주차: 길은 화면보다 먼저 열린다

지난주엔 UI 부품을 깎았다. 말투를 정리했다. 앱이 어떤 표정으로 “안내/경고/에러/권유”를 말할지 통일했다. 근데… 그 다음 주에는 이런 생각이 들었다. “좋은 말투만으로는 부족하다.” 말을 어떻게 하느냐만큼 중요한 게 있다. 어디서 말을 하느냐. 그리고 그 말이 ‘어떻게 이동하느냐’. 이 주는 그래서, 화면을 더 예쁘게 만드는 주가 아니었다. 길을 만드는 주였다. Turbo Native(iOS/Android)로 가기 위한 “내비게이션 규칙”을 코드로 계속 읽기 →

조비엣 빌드로그 2주차: 길은 화면보다 먼저 열린다 더 읽기"

조비엣 빌드로그 1주차: UI 부품을 깎으며, 길부터 닦기 시작했다

조비엣을 만들면서 내가 제일 먼저 한 일은… 의외로 “기능 추가”가 아니었다. 누군가는 이런 걸 비효율이라고 부를지도 모르겠다. 하지만 나는 요즘, 삶도 개발도 같은 결론에 도착했다. 빨리 달리려면, 먼저 길부터 닦아야 한다. 그리고 그 길은 대개 “보이지 않는 규칙”으로 만들어진다. 조비엣(Chợ Việt)은 이름부터 베트남어를 품고 시작했다. 앱의 결은 줄곧 베트남어가 먼저였고, 그래서 나도 그 결을 억지로 계속 읽기 →

조비엣 빌드로그 1주차: UI 부품을 깎으며, 길부터 닦기 시작했다 더 읽기"

HealthNote 전체 회고: 이 앱은 무엇을 만들지 않으려 했는가

들어가며: 우리는 왜 또 하나의 앱을 만들었을까 세상에는 이미 충분히 많은 앱이 있다. 기록하는 앱, 분석하는 앱, 조언하는 앱, 관리해주는 앱. 그럼에도 불구하고 이 앱을 만들기 시작한 이유는 단순했다. “나는 기록을 남기고 싶은데, 계속 설명받고 싶지는 않다.” 이 모순적인 요구에서 이 프로젝트는 시작됐다. Chapter 1: 말로 남기면, 기록이 된다 첫 번째 질문은 이거였다. “왜 기록은 계속 읽기 →

HealthNote 전체 회고: 이 앱은 무엇을 만들지 않으려 했는가 더 읽기"

Chapter 10: 남기되, 쥐지 않는다

이 앱은 여기까지 오는데 오래 걸렸다. 기능을 더하는 데 시간이 걸린 게 아니라, 멈추는 법을 배우는 데 시간이 걸렸다. Chapter 10은 새로운 기능을 추가하는 장이 아니다. 오히려 하나를 내려놓는 장이다. 기록은 남기되, 소유하지 않는다 대부분의 앱은 이렇게 말한다. “당신의 기록은 소중합니다.” “관리하세요.” “유지하세요.” 하지만 이 앱은 그렇게 말하지 않기로 했다. 기록은 앱의 자산도 아니고 서비스의 계속 읽기 →

Chapter 10: 남기되, 쥐지 않는다 더 읽기"

Chapter 9: 존재하지만, 머무르지 않는다

이 앱은 이제 무언가를 더 하려 하지 않는다. 오히려 언제 물러나야 하는지를 배우기 시작했다. 왜 ‘머무르지 않는 단계’가 필요했을까 우리는 보통 앱을 이렇게 만든다. 항상 켜져 있고 계속 알리고 놓치지 말라고 말하고 사용자를 붙잡는다 그게 “좋은 UX”라고 배워왔다. 하지만 건강 기록 앱을 만들면서 나는 점점 불편해졌다. 정말 사람에게 필요한 건 계속 붙잡아두는 서비스일까? Chapter 9의 계속 읽기 →

Chapter 9: 존재하지만, 머무르지 않는다 더 읽기"

Chapter 8: 스스로 말하지 않는다. 불릴 수만 있다

앱을 만들다 보면 어느 순간 이런 유혹이 생긴다. “이쯤이면 먼저 말해줘도 되지 않을까?” 사용자의 데이터를 가지고 있고, 패턴도 보이고, 이제는 ‘도움이 될 만한 말’을 할 수 있을 것 같을 때. 하지만 나는 Chapter 8에서 그 유혹을 완전히 거절하기로 했다. 앱이 말을 잘하기 시작할수록 불편해지는 순간 Chapter 6에서 앱은 처음으로 요청받았을 때만 정리해서 보여주는 존재가 되었다. 계속 읽기 →

Chapter 8: 스스로 말하지 않는다. 불릴 수만 있다 더 읽기"

Chapter 7: 머무를 곳과 물러날 곳을 안다

이 앱은 언제 말을 멈춰야 하는지를 스스로 안다 앱을 만들다 보면 기능은 계속 늘릴 수 있다. 기억도, 분석도, 추천도. 하지만 어느 순간 이런 질문이 생겼다. “이 앱은 언제 조용해져야 할까?” 기억은 선물이 될 수도, 부담이 될 수도 있다 Chapter 5에서 이 앱은 사용자의 말을 기억하기 시작했다. “기억하고 있어요.” “이어서 적어도 돼요.” 말을 잊지 않는 존재는 계속 읽기 →

Chapter 7: 머무를 곳과 물러날 곳을 안다 더 읽기"

Chapter 6: 필요할 때만, 조심스럽게 건넨다

앱을 만들다 보면 자꾸 뭔가를 더 보여주고 싶어진다. 데이터가 있으니까, 비교할 수 있으니까, 분석할 수 있으니까. “이 정도면 알려줘도 되지 않을까?” “이건 도움이 될 텐데?” 그 유혹이 계속 온다. 하지만 Senior HealthNote의 흐름은 여기서 한 번 멈췄다. Chapter 6의 한 문장 “불렸을 때만 대답한다.” 왜 ‘요청할 때만’이어야 했을까 Chapter 4에서 앱은 처음으로 말을 걸기 시작했다. 계속 읽기 →

Chapter 6: 필요할 때만, 조심스럽게 건넨다 더 읽기"