조비엣을 만들면서 내가 제일 먼저 한 일은… 의외로 “기능 추가”가 아니었다.
누군가는 이런 걸 비효율이라고 부를지도 모르겠다.
하지만 나는 요즘, 삶도 개발도 같은 결론에 도착했다.
빨리 달리려면, 먼저 길부터 닦아야 한다.
그리고 그 길은 대개 “보이지 않는 규칙”으로 만들어진다.
조비엣(Chợ Việt)은 이름부터 베트남어를 품고 시작했다.
앱의 결은 줄곧 베트남어가 먼저였고, 그래서 나도 그 결을 억지로 바꾸지 않기로 했다.
대신, 그 결이 앞으로 흔들리지 않도록 표현의 규칙을 세우는 쪽을 택했다.
1. 이번 주에 만든 건 ‘화면’이 아니라 ‘문법’이었다
처음엔 화면이 지저분했다.
똑같은 메시지가 페이지마다 다른 표정으로 나타났다.
- 어떤 곳에서는 뱃지로
- 어떤 곳에서는 경고 패널로
- 어떤 곳에서는 플래시로
- 어떤 곳에서는 자잘한 문구로
문제는 “예쁨”이 아니라, 일관성이었다.
사람은 반복되는 패턴에서 신뢰를 느끼는데, 앱이 제멋대로 말하면 신뢰가 깎인다.
그래서 나는 이렇게 생각했다.
조비엣은 지금 ‘말투’를 정해야 한다.
그 말투를 만들기 위해, 기능보다 먼저 UI 부품부터 정리하기 시작했다.
2. UI 부품 인벤토리: “규칙의 집”과 “표현의 표준 부품”
이번 주에 정리된 조합을 한 문장으로 말하면 이렇다.
“안내/경고/에러/권유”를 같은 언어로 말할 수 있게 만들었다.
정리된 인벤토리는 이렇다.
✅ 표현 계층 (보여주는 방식의 표준)
- _badge
- _counter_badge
- _status_panel
- _alert_panel
✅ 에러 계층 (실패를 다루는 방식의 표준)
- _form_errors
✅ 상호작용 계층 (사용자 행동을 다루는 방식의 표준)
- _dismissible_alert + Stimulus
나는 이 구조가 되게 마음에 든다.
왜냐하면 이게 단지 “뷰 리팩터링”이 아니라, 제품의 태도를 바꾸는 일이기 때문이다.
말을 줄이고, 의미를 통일하는 작업.
조비엣이 더 “앱” 같아지는 순간은, 이런 땅 작업에서 시작되는 것 같다.
3. PR #40: “배너 정리”가 아니라, Turbo Native 관문이었다
솔직히 PR #40은 처음엔 단순했다.
“리뷰 리마인더 배너 좀 깔끔하게 정리하자” 수준이었다.
근데 하다 보니 딱 걸렸다.
문제: 인라인 스크립트
웹에서는 어떻게든 되지만, Turbo Native(= iOS/Android 웹뷰 기반 네이티브)로 갈 때
인라인 스크립트는 금방 지뢰가 된다.
그래서 결론은 하나였다.
상호작용은 Stimulus로 표준화한다.
- 인라인 <script> 제거
- dismissible_alert_controller.js로 동작을 옮김
- _dismissible_alert partial로 UI를 고정
이 한 번의 정리가 “지금은 웹”이지만 “미래는 네이티브”인 프로젝트에게
엄청 중요한 관문이었다.
겉으로는 배너지만, 사실은 내비게이션 규칙으로 넘어가기 위한 첫 관문이었다.
4. 내가 이번 주에 배운 것: “기능은 나중에도 만들 수 있다”
이번 주엔 기능이 폭발적으로 늘진 않았다.
대신, 기능이 자라날 토양을 만들었다.
나는 요즘 이게 되게 중요하다고 느낀다.
- 토양이 없으면 기능은 금방 썩는다.
- 규칙이 없으면 팀이 되지 못한다. (미래의 나도 팀이다.)
- 문법이 없으면 번역도, 네이티브도, 확장도 다 흔들린다.
그러니까 이번 주의 성과는 “코드 몇 줄 줄였다”가 아니라,
조비엣이 앞으로 말을 할 때, 어떤 말투로 말할지 정했다
에 가깝다.
5. 다음 주 예고: “UI 부품”에서 “네비게이션 규칙”으로
이번 주에 나는 말투를 만들었다.
다음 주에는 길(라우팅)을 닦을 차례다.
Turbo Native로 가려면 결국 이 질문을 만나게 된다.
- 어떤 화면은 “탭”으로?
- 어떤 화면은 “모달”로?
- 로그인/회원가입은 “replace”로?
- 딥링크가 흔들리지 않게 URL은 어떻게 고정할지?
이제 조비엣은 “보기 좋게”가 아니라
“흔들리지 않게”로 넘어가려 한다.
그리고 그게, 내가 지금 만들고 싶은 제품의 태도다.
조비엣은 빨리 말하는 앱이 아니라,
신뢰를 지키는 앱이었으면 좋겠다.