banksalad

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

접근재시도 로직 없는 낙관적 락을 채택. version 컬럼을 두고 UPDATE 시 WHERE version = ? 조건으로 CAS 한다. 충돌 시 즉시 실패시켜 호출자가 처리하도록 위임한다.

결과잠금 대기 없이 정합성을 보장하고 코드 복잡도를 낮췄다. 현금성 재화가 오가는 도메인에서도 트랜잭션 단순화와 동시성 안전성을 동시에 확보했다.

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

접근Lottie JSON 구조를 런타임에 조작해 하나의 파일로 모든 조합을 표현. assets 배열의 이미지 경로만 동적으로 교체한다. iOS 깜빡임은 img absolute 누적 대신 background-image 로 전환해 해결.

결과React + DOM + Lottie 만으로 게임 엔진 없이 캐릭터 커스터마이징을 구현했다. 디자이너는 뼈대만 만들고 개발팀은 JSON 만 다루는 분업 구조를 정착시켰다.

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

접근지출 내역에 map / filter / reduce 만 적용하는 제한된 표현력의 DSL 을 설계. GitLab micro-language-framework 로 토큰 파싱은 위임하고 연산자·함수만 플러그인으로 정의한다. 운영자는 DSL 안에서만 자유롭게 규칙을 짠다.

결과자유도와 안정성의 균형을 잡았다. 운영자가 코드 변경 없이 미션을 빠르게 실험하면서도 시스템 안전성은 DSL 의 표현력 제한이 보장한다.

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

접근일반 텍스트의 힘이라는 관점으로 접근성을 재정의. UI 의 입출력을 텍스트로 다루는 습관이 곧 접근성 지원이며, aria-label / accessibilityLabel 같은 인터페이스가 스크린리더뿐 아니라 음성명령·안구추적 등 사후 등장한 모드에서도 동작 근거가 된다.

결과접근성을 추가 작업이 아닌 더 좋은 제품 설계의 다른 측면으로 정렬한다. 텍스트 기반 인터페이스가 다양한 환경에서 살아남는 이유를 사례로 제시한다.

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

접근메트릭(성공/실패 카운트) 기반 observability + 임계치 이하 시 Slack 자동 알림.

결과proactive 에러 탐지로 빠른 대응 가능. API 성공률 90% → 99% 로 5 개월간 개선.

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

접근LLM에 페르소나(인구통계, 라이프스타일, 재무 목표)와 JSON 스키마, few-shot 예시를 주는 prompt engineering으로 데이터를 만든다. 후처리로 markdown/설명을 제거하고 Kotlin DataClass로 변환해 개발 서버에 적재한다. GitHub Actions Cron으로 매일 갱신한다.

결과요일별 소비 패턴(월요일 공과금, 주중 쇼핑, 주말 가족 활동)까지 자연스럽게 들어간 테스트 데이터가 자동 생성된다. QA·개발 조직 전체가 별도 수작업 없이 활용한다.

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

접근테크스펙을 일방향 정적 문서가 아니라 협업과 창의가 필요한 작업 전에 조기 피드백을 받는 양방향 토론방으로 재정의한다. 영화의 시나리오·콘티처럼 지적 생산활동의 일부로 본다.

결과테크스펙은 배포 시점에 수명을 다하므로 최신화가 필요 없다. 오히려 개인 간 상호작용과 즉각적 피드백이라는 애자일 본래 취지를 강화하는 도구가 된다.

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

접근사용자 인터뷰와 클릭 전환율 같은 정성·정량 데이터를 함께 보고 휴리스틱 평가로 복잡도 피드백을 풀었다. "위클리 홈 아이디어" 회의로 팀 전체가 사용자 문제를 공유하고, 슬랙과 연동한 백오피스로 배너 등록 운영을 자동화했다.

결과매출 전환의 핵심 유입 채널로 자리 잡았고, 지출 관리 섹션 개선에서는 클릭율이 25% 올랐다. 배너 등록 수는 3.27배 늘었고 이탈 없이 안정적으로 운영되고 있다.

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

접근3주간 POC로 신기술 도입과 기존 기술 재활용 사이의 트레이드오프를 검증한 뒤, 서버에서 레이아웃·색상·네비게이션을 내려주는 서버 드리븐 UI와 자체 개발한 스크린 네비게이터로 화면 이동까지 데이터화했다. 작업은 페이즈로 쪼개 인지 부하를 낮췄다.

결과114일간의 보수적 실험을 거쳐 지표 하락 없이 안정적으로 배포했고, 2023년 1월 전체 사용자 대상 새 홈 출시에 성공했다.

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

접근CUJ(Critical User Journey)로 사용자 동선을 따라가며 헤비유저·저빈도 사용자·신규 사용자를 모두 대상으로 반복 리서치를 돌렸다. CDO·CTO가 팀 리더와 1:1 면담을 진행하고 모든 PM이 참여한 청문회에서 16장 분량의 피드백을 모아 조직 내 합의를 만들었다.

결과"변동 금액"이 매일 들어와 확인하는 주요 방문 목적으로 자리 잡았다. 신규 사용자의 학습 경험이 개선됐고, 홈이 상품 구매 전환율이 가장 높은 유입 채널이 됐다.

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

접근develop/release 브랜치를 분리하고 release에는 cherry-pick으로만 핫픽스를 넣는다. GitHub Actions와 자체 Mac 빌드 시스템으로 자동화 테스트를 돌리고, 사용자 5%부터 점진 출시하며 미완성 기능은 Feature Flag로 막는다.

결과개발 1주, 자동화 테스트 주말, Release QA 1주, 점진 배포 2일의 루틴이 자리잡았다. 개인 역량이 아닌 프로세스로 품질이 유지되면서 대규모 리팩토링도 안정적으로 배포할 수 있게 됐다.

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

접근Shared를 Constant·SwiftExtension·DIContainer 등으로 쪼개고 Data 레이어의 인터페이스를 DataInterface 모듈로 분리해 의존성 역전 원칙을 적용했다.

결과Live Activity 같은 신규 기능을 최소 의존성으로 만들 수 있게 됐고 다른 엔지니어와 충돌이 거의 없었으며 추후 gRPC·캐싱 도입 대비 구조가 마련됐다.

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

접근@bufbuild/protoplugin으로 코드 생성기를 만들고 buf CLI 빌드에 연결해 .proto 파일에서 TypeScript HTTP 클라이언트를 자동 생성하면서 내부망(k8s 서비스 DNS)과 외부망 호출을 별도 클래스로 분리했다.

결과SSR에서 방화벽을 우회해 응답 속도를 200ms에서 20ms 수준으로 약 90% 줄였고 API 코드 작성과 타입 정의를 자동화해 개발 생산성과 안정성을 함께 올렸다.

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

접근컨벤션을 코딩 스타일, 프랙티스, 원칙 세 층위로 정의한다. panic 안전성, error stacking, goroutine 안전성, HTTP 커넥션 재사용, table-driven test, context 사용법 같은 실전 프랙티스를 코드 예시와 함께 기술한다.

결과golangci-lint와 결합된 문서화된 컨벤션으로 코드 리뷰의 기준점을 만든다. 팀 단위 개념적 일관성을 유지하면서 신규 입사자 온보딩 비용을 낮춘다.

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

접근AWS DMS의 Full Dump + CDC로 무중단 이관을 구성한다. 운영 DB CPU 100% 부하에 대비해 인스턴스를 피크의 2배로 키우고, 바이너리 로그 보존 한계는 DMS 인스턴스 r5.8xlarge + Limited LOB Mode로 회피한다. FK 제약은 `initstmt=SET FOREIGN_KEY_CHECKS=0` 으로 푼다.

결과데이터 유실 없이 클러스터 비용을 1/3로 줄였다. 대용량 이관은 과하다 싶게 스펙업하는 것이 안전하다.

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

접근사용자 ID 기준 Spark Bucketing으로 특정 사용자의 데이터 위치를 사전에 파악했다. 파티션을 dt·hour에서 dt 단위로 축소하고, Athena 호환을 위해 CTAS 임시 테이블을 활용했다. Executor당 파일 중복은 repartition으로 정리했다.

결과S3 Object 호출 수가 약 700배 감소했다. MySQL 저장 비용 절감액이 늘어난 조회 비용의 약 3배로 전체 비용도 줄었다.

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

접근분석 테이블을 프로덕션 API로 노출하는 플랫폼 dataserving을 만들었다. Amazon DocumentDB를 백엔드로 두고 protobuf·IDL로 데이터 명세를 정의했다. datapipe에서 정기적으로 테이블을 업데이트하고 DataservingInsertOperator로 테이블·데이터셋 매핑을 자동화했다.

결과데이터 분석가가 서버 엔지니어 없이 API를 만들 수 있다. 금융쇼핑·내 자산 순위·보험 진단·자산 분석 보드 같은 데이터 제품이 이 플랫폼 기반으로 출시됐다.

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

접근datapipe로 EMR·Spark·Airflow DAG 구성을 추상화했다. 메타데이터와 비즈니스 로직만 작성하면 동작하고, Slack ChatOps 기반으로 분석가가 직접 배포한다. PR별 자동 테스트 서버와 pytest 유닛 테스트, DqCriteria 기반 데이터 품질 검증도 통합했다.

결과비엔지니어 직군의 파이프라인 개발 사례가 연간 600건으로 약 6배 늘었다. 엔지니어는 인프라에, 제품팀은 지표·데이터 제품 운영에 집중하게 됐다.