앱
자라는 가계부
예산의 흐름을 나무의 변화로 보여주는 개인 가계부 앱입니다.
주요 성과
복원 전 검증과 실패 시 원본 보존을 갖춘 백업 구현
SQLite 무결성·필수 테이블·스키마 버전을 확인하고 교체 전에 안전 복사본을 남깁니다. CSV 가져오기에는 미리보기와 중복 제외를 적용했습니다.
앱 업데이트와 월별 계산의 데이터 호환성 검증
스키마 변경을 트랜잭션으로 처리하고, 구버전 데이터·월 전환·반복 지출·거래 CRUD·파일 왕복을 단위·통합·UI 테스트로 확인했습니다.
예산 계산과 나무 상태 표현의 책임 분리
월 진행률·예산 사용률·잔액으로 상태를 판단하는 계산 로직을 화면에서 분리하고 월말·추가 수입·빈 거래의 경계를 다뤘습니다.
같은 사용률도 월의 어느 시점인지에 따라 다르게 보기
예산을 50% 썼다는 값만으로는 소비 흐름을 판단하기 어려웠습니다. 월 초와 월 말의 의미가 다르고 추가 수입·빈 거래·월말도 상태 계산에 영향을 주기 때문에 화면의 표현과 계산 기준을 분리해야 했습니다.
월 진행률·예산 사용률·잔액을 함께 보는 계산 로직을 별도로 구성했습니다. 월말 성공과 추가 수입 후 회복, 거래가 없는 상태를 구분하고 이 경계를 테스트했습니다. 화면은 계산된 나무 상태를 표현하도록 했습니다.
업데이트 중 데이터 구조가 바뀌어도 기록 유지하기
SQLite 스키마를 바꾸는 도중 실패하면 일부 변경만 남을 수 있었습니다. 월별 기록과 반복 거래가 연결돼 있어 스키마 변경, 재실행, 수정·삭제의 영향을 함께 확인해야 했습니다.
마이그레이션을 트랜잭션 안에서 처리하고 이력을 관리했습니다. 구버전 데이터·월 전환·반복 고정 지출·거래 CRUD를 단위·통합·UI 테스트로 확인했습니다.
백업 파일을 검증한 뒤 원본 교체하기
잘못된 파일이나 더 새로운 스키마의 백업을 그대로 덮어쓰면 기존 기록을 잃을 수 있었습니다. 복원을 시도하는 것과 원본을 교체해도 되는지 판단하는 단계를 나눴습니다.
SQLite 스냅샷을 내보내고, 복원 후보의 무결성·필수 테이블·스키마 버전을 먼저 검사했습니다. 교체 전 안전 복사본을 남기고 실패 시 원본을 보존하도록 구성했습니다. CSV 가져오기도 미리보기와 중복 제외를 적용하고 파일 왕복을 검증했습니다.