뱅크샐러드

게임형 앱테크 서비스의 character_state(잔액·레벨)는 유저 액션·운영 백오피스·배치 등 여러 경로로 동시에 갱신된다. 동시성 제어가 없으면 Lost Update 가 발생해 현금성 자산 정합성이 깨진다.

게임 엔진 경험 없이 웹뷰 게이미피케이션 앱(일해라 김뱅샐)을 만들어야 했다. 캐릭터 옷 조합 수가 폭발적으로 늘어 모든 조합마다 애니메이션 파일을 만들 수 없었고, iOS 웹뷰에서 화면 깜빡임도 발생했다.

샐러드게임 미션 규칙을 운영자가 직접 수정해 신속히 실험하려 했지만, LLM 으로 코드를 생성하면 보안 / 안정성 검증을 다시 엔지니어가 해야 해 생산성 이득이 없었다.

접근성 지원이 별도 비용으로 인식되어 개발 일정에서 미뤄지거나 사후 작업으로 처리된다. 실제로는 보안처럼 개발 과정에 자연스럽게 녹아야 할 관심사다.

100+ 금융기관 API 운영 시 실패 가시성 부족으로 사용자가 대출 기회를 놓치는 문제.

마이데이터 기반 자산관리 서비스는 은행/카드/대출/투자/보험을 아우르는 일관된 테스트 데이터가 필요한데 수동 생성은 시간이 너무 많이 든다.

"문서보다 작동하는 소프트웨어"라는 애자일 원칙 때문에 테크스펙 작성이 부정되거나, 늘 최신화해야 하는 부담스러운 문서로 오해되는 일이 잦다.

초기 사용성 테스트에서 사용자들이 게임 설명을 읽지 않고 버튼만 눌러 온보딩이 실패했고, 협동 미션의 복잡한 규칙을 직관적으로 전달하기 어려웠다.

협력형 지출 관리 게임 개발에서 초기 '지름신' 콘셉트가 사용자에게 죄책감을 유발했고, 3D 아이소메트릭 애니메이션이 파일 크기 제약을 초과했다.

새 홈 탭이 안정 출시된 뒤에도 기존 사용자는 홈을 "거쳐가는 관문"으로만 인식해, 매출 전환과 신규 기능 노출이라는 본래 역할을 충분히 해내지 못했다.

뱅크샐러드 첫 화면을 새로 짓는 과정에서, 복잡한 레이아웃을 효율적으로 표현하고 출시 위험을 줄일 기술적 토대가 필요했다.

마이데이터 도입으로 자산 종류가 늘면서 자산 탭이 비대해졌고, 사용자는 기존 기능만 반복적으로 쓰며 새 서비스를 발견하지 못했다. 비즈니스 영역을 담아낼 공간도 부족했다.

모바일 앱은 배포 후 되돌리기 어렵고 스토어 심사에 시간이 들며 강제 업데이트도 쉽지 않다. 뱅크샐러드는 이 제약 아래서 일관된 품질로 매주 배포해야 했다.

뱅크샐러드 iOS 앱이 커지면서 Shared 모듈이 비대해지고 불필요한 의존성 때문에 빌드와 변경 영향 범위가 넓어졌다.

뱅크샐러드 웹은 마이크로서비스 gRPC 호출마다 HTTP 클라이언트를 수작업으로 작성했고 외부망 경유로 IPS 부하와 200ms 수준 지연이 발생했다.

다양한 개발자가 함께 일하는 백엔드 팀에서 4년간 Go를 쓰며 쌓인 시행착오를 일관된 규칙으로 정리할 필요가 있다.

서비스별로 분리된 약 50개 RDS 클러스터를 7개 업무 도메인으로 통합해 비용을 1/3로 줄이려 했고, 무중단 N:1 이관이 필요했다.

신용올리기 서비스의 마이데이터 이벤트 로그가 MySQL에 쌓이며 비용이 급증했고, S3로 옮긴 뒤에도 Athena 풀스캔으로 조회 비용이 폭증했다.

분석 데이터로 프로덕션 제품을 만들 때마다 아키텍처가 새로 설계되고 서버 엔지니어 개입이 필요했다.

데이터 파이프라인 개발이 데이터 엔지니어에게 집중되며 요청·협의·구현·배포가 반복돼 조직 확장이 막혔다.