Thunderbird iOS 앱, 기존 코드 재사용 없이 새로 쓴다
데스크톱과 Android 경험은 가져가고 코드는 안 가져가는 선택이, 혼자 만드는 사람한테 어떤 기준이 되는지 적었어요.
데스크톱에서 잘 돌던 서비스를 모바일로 옮기자고 마음먹은 순간, 제일 먼저 드는 생각이 뭐예요? 저는 늘 "있는 코드 최대한 끌어오자"였어요. 로직은 다 있으니까 화면만 새로 붙이면 될 것 같거든요. 그런데 그 생각을 정면으로 거스르는 소식이 GeekNews에 올라와서 한참 봤습니다.
Thunderbird가 iOS 앱을 새로 쓰고 있어요
GeekNews에 올라온 글 내용은 이래요. Thunderbird iOS 앱을 기존 코드 재사용 없이 네이티브로 새로 개발하고 있고, 데스크톱과 Android에서 쌓은 경험을 바탕으로 기기 간 일관된 사용 경험을 목표로 한다고 해요. 지금 집중하는 건 계정 설정과 백그라운드 동기화고, 빠르고 안전한 로그인과 배터리를 고려한 받은편지함 쪽을 보고 있다는 정도까지 나와 있어요.
요약은 짧아요. 출시 시점이나 내부 구조 같은 건 글에 없으니 여기서 더 말하진 않을게요. 대신 왜 이 짧은 글이 제 눈에 걸렸는지를 적어보려고 해요.
그림 1.
경험은 가져가고 코드는 안 가져간다는 선택
눈에 띈 건 이 조합이에요. 데스크톱과 Android 경험은 바탕으로 삼는데, 코드는 재사용하지 않는다. 보통은 반대로 가잖아요. 코드는 어떻게든 공유하고, 경험은 플랫폼마다 조금씩 달라져도 어쩔 수 없다고 넘어가요.
혼자 만들 때 이 유혹이 더 커요. 사람이 저 하나니까 코드가 두 벌이면 그대로 작업이 두 배가 되거든요. 그래서 공통 모듈을 뽑고, 플랫폼 분기를 넣고, 어느새 어느 쪽에서도 깔끔하지 않은 코드가 남아요. 저도 그런 분기문을 몇 번 만들어봤어요. 돌려보면 되긴 되는데, 고칠 때마다 양쪽을 다 열어봐야 했어요.
Thunderbird가 왜 이 길을 골랐는지 글엔 자세히 안 나와요. 그래서 이건 제 해석인데, 재사용의 기준을 코드가 아니라 사용자 경험에 뒀다는 점이 핵심 같아요. 같은 코드를 쓴다고 같은 경험이 나오진 않으니까요.
왜 화면이 아니라 계정 설정과 동기화부터일까요?
메일 앱이면 받은편지함 화면부터 만들고 싶어져요. 눈에 보이고, 스크린샷 찍어 올리기도 좋고요. 그런데 이 팀은 계정 설정과 백그라운드 동기화에 먼저 집중한다고 적어놨어요.
안 보이는 쪽이 신뢰를 정해요. 로그인이 한 번 꼬이면 그 앱은 두 번 안 열어요. 동기화가 배터리를 먹으면 설정에서 알림을 끄다가 결국 삭제하고요. 화면은 나중에 고쳐도 되지만, 기반이 흔들리면 화면을 아무리 다듬어도 소용이 없어요.
혼자 만들다 보면 이 순서가 자꾸 뒤집혀요. 눈에 보이는 진척이 동기부여가 되니까요. 그래서 "뭐부터 만들었어요?"라는 질문에 "로그인이랑 동기화요"라고 답하는 팀이 있다는 게 저한테는 작은 기준점이 됐어요.
혼자 만드는 사람한테 달라지는 것
저는 Expo로 모바일을 만들고 있어서 상황이 조금 달라요. 웹과 앱이 어차피 React 계열이라 공유할 수 있는 게 더 많거든요. 그래도 이 소식을 보고 플랫폼 하나를 추가할 때 먼저 적어볼 질문이 생겼어요.
| 질문 | 가져오기 쪽 | 새로 쓰기 쪽 |
|---|---|---|
| 이 코드가 플랫폼 특성을 모르나? | 순수 계산·검증 로직 | 백그라운드 작업, 알림, 저장소 접근 |
| 사용자가 같다고 느끼는 기준이 뭔가? | 데이터와 결과 | 손에 익은 조작감, 응답 속도 |
| 고장 났을 때 어디서 터지나? | 한 곳 고치면 양쪽 해결 | 플랫폼별로 따로 봐야 함 |
표는 제 기준이에요. 소식에 이런 표가 있는 건 아니고요. 다만 코드 공유율을 성과처럼 보던 버릇을 한 번 의심하게 됐어요.
재사용할 건 코드가 아니라, 사용자가 어디서 떠났는지에 대한 경험일 수도 있어요.
직접 해 보려면
- 지금 만드는 앱에서 안 보이는 기반 세 가지를 적어보세요. 로그인, 동기화, 오프라인 저장 같은 것들이요. 그중 테스트가 없는 게 몇 개인지 세어보면 됩니다.
- 플랫폼 공통 모듈에 있는 if 분기를 세어보세요. 특정 플랫폼 조건이 셋 넘게 들어간 파일은 공유가 아니라 두 벌을 한 파일에 욱여넣은 상태일 가능성이 커요.
- 다음 플랫폼을 추가한다고 가정하고, 첫 2주에 뭘 만들지 순서를 써보세요. 화면이 맨 위에 있다면 한 번 더 생각해볼 만해요.
이걸로도 안 되는 것
소식 자체가 짧아요. Thunderbird가 어떤 구조로 짜는지, 어디까지가 재사용 없이인지 알 수 없어서 이 글의 해석엔 제 추측이 섞여 있어요. 후속 글이 올라오면 다시 확인해보겠습니다.
그리고 새로 쓰는 게 항상 맞는 것도 아니에요. 저처럼 혼자 하는 사람은 두 벌 유지 비용이 그대로 제 시간이라, 기준 없이 따라 하면 그냥 일만 늘어요. 위의 표도 결국 제 상황에서 몇 번 돌려봐야 쓸 만한지 알 것 같아요.