전성훈

복잡한 상태 설계

캐츠비는 베타 출시를 일주일 앞두고 합류해 서비스가 끝날 때까지 iOS를 맡은 제품입니다. 금융 교육을 게임처럼 만든 앱이라 화면마다 상태가 많았고 매주 기능이 새로 붙었습니다. 1년 3개월 동안 화면 구현부터 네트워크, 내비게이션, 결제, 분석까지 iOS 전반을 혼자 결정하고 책임졌습니다. 처음부터 끝까지 제 손으로 끌고 간 제품이라 애착이 큽니다.

대표적인 기능이 퀘스트 보상입니다. 퀘스트를 달성하면 진행 바가 차오르고 보상이 날아가고 완료 표시가 뜨는데, 이 셋이 순서대로 한 번씩만 나와야 합니다. 어려운 지점은 무엇이 바뀌었는지를 어디서 판단하느냐였습니다. 화면이 판단하면 그 화면에 들어와 있어야만 알 수 있어서, 퀴즈를 풀다 보상을 받고 빠져나가면 이미 바뀐 값은 아무에게도 보이지 않은 채 사라집니다.

그래서 변화를 판단하는 일을 데이터 영역으로 옮겼습니다. 저장소가 마지막으로 사용자에게 보여준 스냅샷과 지금 상태를 함께 들고 둘을 비교해 아직 안 보여준 변화만 값으로 만들어 넘깁니다. 화면은 그 값을 받아 순서대로 보여주기만 합니다. 여러 화면이 동시에 읽고 쓰기 때문에 actor로 직렬화했고 스냅샷은 애니메이션이 끝난 뒤에만 확정합니다. 그래서 퀴즈 화면에서 놓친 변화를 퀘스트 보드가 이어서 보여주고 앱을 껐다 켜도 남습니다.

보여주는 쪽은 따로 뒀습니다. 애니메이션 단계를 타입으로 정의해 순서를 강제하고 화면을 벗어나면 취소합니다. 무엇이 달라졌는지는 데이터 영역이 알고, 그걸 어떻게 보여줄지는 화면이 압니다.

나눠 두니 두 쪽이 서로를 몰라도 됐습니다. 나중에 재화를 얻는 보상 애니메이션이 중간에 하나 더 붙었을 때도 변화를 판단하는 코드는 그대로 두고 보여주는 순서만 고치면 됐습니다. 매주 기능이 붙는 일정에서 손댈 자리가 정해져 있으니 요구가 늘어도 그만큼 빠르게 붙일 수 있었습니다.

사용자 경험 개선

퀴즈는 캐츠비의 핵심 콘텐츠였습니다. 사용자가 앱에서 가장 오래 머무는 곳이라 여기서 생기는 지연은 한 번으로 끝나지 않고 문제를 풀 때마다 반복됩니다.

문제를 풀면 서버 응답을 기다린 뒤에 다음으로 넘어가서, 맞힌 걸 알면서도 매번 한 박자씩 멈췄습니다. 화면 전환과 서버 반영을 떼어내 진행은 곧바로 이어지게 하고, 정합이 필요한 체크포인트에서만 진행 중인 제출이 끝나기를 기다리게 했습니다. 실패한 제출은 큐에 모아 그 지점에서 다시 보냅니다.

퀴즈맵은 그 콘텐츠로 들어가는 입구입니다. 챕터별 레슨을 세로로 길게 잇는 스크롤 화면이라, 한 코스가 끝나는 지점에 스크롤이 닿고 다음 코스가 있으면 그때 다음 코스를 미리 받아 둡니다. 코스의 마지막 레슨을 풀고 있을 때도 같은 준비를 합니다. 사용자가 다음 코스로 넘어가면 받아 둔 것을 그대로 써서 네트워크 없이 바로 그립니다.

미리 받아 두는 쪽만 만들면 오히려 어긋납니다. 스크롤이 오르내리며 여러 번 요청되지 않게 묶었고 코스가 바뀌면 받아 둔 내용과 트리거 조건을 함께 비웁니다. 화면을 벗어나면 진행 중인 요청을 취소합니다. 코스를 넘나들 때 조금이라도 자연스럽게 이어지도록 붙인 장치들입니다.

제가 만드는 서비스는 하루에도 수십 번씩 직접 눌러 보고 실제로도 씁니다. 그러면서 걸리는 지점과 비슷한 서비스를 보며 아쉬웠던 지점을 목록으로 모아 두고, 일정이 허락하는 만큼 하나씩 처리해 왔습니다. 앞의 두 가지도 그 목록에서 나왔습니다.

변경에 대응하는 구조

첫 앱 AVIRO는 데이터와 로직, 화면이 한 곳에 섞인 채로 출시했습니다. 운영 중 대규모 업데이트가 들어왔을 때 어디를 고치면 어디가 깨지는지 알 수 없어 손대지 못한 지점이 생겼습니다. 그때부터 구조를 먼저 잡는 쪽으로 방향을 바꿨고 다음 실무부터는 계층을 나눠 설계했습니다.

실무에서 반영한 건 캐츠비였습니다. 퀴즈는 처음에 학습과 복습 정도만 있어서 불리언 몇 개로 화면 상태를 표현했습니다. 설문과 결말, 완료가 차례로 붙으면서 조합이 곱으로 늘었고 복습이면서 완료 같은 있을 수 없는 상태가 컴파일을 통과했습니다. 진행 단계를 타입으로 바꾸니 단계가 하나 늘 때마다 컴파일러가 처리하지 않은 자리를 전부 짚어 줘서, 상태가 더 붙어도 빠뜨리는 곳 없이 확장할 수 있었습니다. 다음 단계를 정하는 규칙은 레슨 상태만 받는 순수 함수로 빼 화면 없이 확인할 수 있게 했습니다.

운영하면서 계층만으로는 아쉬운 지점도 봤습니다. 기능이 커질수록 하나를 고치는 데 열어야 할 모듈이 늘었고, 테스트를 잘게 나누기 어려웠습니다. 그 지점은 개인 프로젝트에서 시험했습니다. 같은 앱을 계층 단위와 피처 단위로 두 번 만들면서 피처마다 모듈을 나누고 계약만 밖으로 내보내, 화면 하나를 고칠 때 그 피처만 열면 되게 했습니다. 대표적으로 이미지 파이프라인은 저장소가 데이터만 돌려주고 크기를 줄이는 일과 캐시는 화면 쪽에 뒀습니다. 저장소가 그리는 일을 모르니 UI 프레임워크 없이 확인할 수 있습니다.

나중에 나누는 비용이 지금 나누는 비용보다 훨씬 크다는 걸 한 번 겪었습니다. 그래서 일정이 빠듯할 때도 어느 코드가 어디까지 책임지는지는 먼저 정해 두고 시작합니다.

AI로 만든 생산성

Android는 출시일이 정해져 있는데 인력이 부족했습니다. iOS를 만들면서 판정 규칙과 화면 상태, 예외 처리를 명세로 정리해 둔 것이 있어서, 그 명세를 기준으로 Android 개발자와 함께 Claude Code로 구현했습니다. 새로 설계할 것이 없었으니 두 플랫폼이 같은 규칙 위에서 도는지만 확인하면 됐고 정해진 일정을 지켜 출시했습니다.

WebView 전환의 React와 Next.js 화면도 같은 방식이었습니다. 익숙하지 않은 스택이라 요구사항과 구조를 먼저 잡고 구현을 맡겼습니다. 브라우저에서 되던 것이 웹뷰에서 안 되는 경우가 있어서, 실제 Safari와 WKWebView에서 하나씩 확인하고 고쳐 넣었습니다.

브리핑 콘텐츠 파이프라인은 사람이 매일 손대지 않아도 돌아가야 했습니다. 생성부터 품질 검사, 발행까지 자동으로 이어지게 설계하고 검사를 통과하지 못한 것은 나가지 않게 했습니다.

셋 다 구조와 판단은 제가 하고 구현 속도를 AI로 벌었습니다. 그렇게 아낀 시간은 생성된 것이 실제 환경에서 도는지 확인하는 데 썼습니다.