프로젝트마다 상황, 해결, 결과, 회고 순서로 적었습니다. 요약은 이력서에 있습니다.
Android Developer → 네이티브 팀장 · 2021.11 ~ 2026.05
공비서 원장님 — 뷰티 B2B SaaS CRM · Google Play 10만+ 다운로드 · 평점 4.2 (리뷰 662)
01
상황로그인 비밀번호가 기기에 평문으로 저장되는 문제를 직접 찾아 주도적으로 개선했습니다. SharedPreferences를 DataStore로 옮기려 했지만 DataStore도 기본 암호화를 제공하지 않아 저장소 자체에 암호화를 넣어야 했습니다.
해결DataStore를 감싼 보안 저장소를 만들어, 값을 저장할 때 암호화하고 읽을 때 복호화하도록 했습니다. 키는 Android Keystore에서 AES-GCM으로 생성·관리해 앱 밖으로 꺼낼 수 없게 했습니다. 비밀번호를 쓰던 화면 7곳(로그인, 회원가입, 스플래시, 회원정보 수정 등)을 이 저장소로 직접 옮겼고, 이미 배포된 앱의 평문 데이터는 앱 시작 시 암호화 저장소로 옮긴 뒤 삭제해 강제 업데이트 없이 전환했습니다.
결과강제 업데이트 없이 전환 · 로그인 실패 0건
02
팀 구성 — Android 1
상황RemoteViews 기반 레거시 위젯이 유지보수가 어려웠고, 앱과 위젯 사이 데이터가 어긋나 값이 오래된 채로 남는다는 VOC, 고해상도 기기에서 텍스트가 안 읽힌다는 VOC가 들어왔습니다.
해결RemoteViews를 Jetpack Glance로 옮겼습니다. Compose 문법으로 작성하지만 실제로는 RemoteViews로 변환돼 홈 화면에 그려지기 때문에, 일반 Compose와 쓸 수 있는 컴포넌트와 스타일이 다릅니다.
동기화는 WorkManager 주기 작업 + DataStore(Protobuf)로 — JSON보다 파싱 오버헤드가 적어 위젯처럼 제한된 환경에 맞다고 봤습니다.
절전 모드는 VOC로 들어온 것이 아니라 작업 중 직접 조사해 파악한 부분입니다. 절전 모드에서는 백그라운드 작업이 제한돼 위젯이 데이터를 받아 오지 못했습니다. 배터리 최적화 예외 같은 민감 권한으로 강제할 수도 있었지만 스토어 심사에서 리젝 사유가 될 수 있어, 동기화할 때 절전 모드를 확인하고 해제를 안내하는 UI로 풀었습니다.
텍스트는 앱 실행 시 해상도·글자 크기를 저장해 렌더링 때 조정했습니다. 이 프로젝트에서 LeakCanary를 도입해 Crashlytics·ANR이 못 잡던 메모리 누수를 잡기 시작했고, 이후 실제 누수 수정으로 이어졌습니다.
결과데이터 불일치·텍스트 VOC 해소 · 절전 모드 해제 안내 UI 제공 · 운영 기간 위젯 관련 크래시 0건(Crashlytics) · LeakCanary는 이후 팀 빌드 옵션으로 정착
회고텍스트 크기 조정은 앱을 한 번 실행해야 반영됩니다. 위젯 단독으로 갱신할 방법을 못 찾았고, 그 한계는 그대로 남았습니다.
03
팀 구성 — Android 3
상황Java 71%의 MVC + AsyncTask 레거시. 앱마다 레포가 나뉘어 있어 공통 코드가 중복됐습니다. 서비스는 계속 굴러가야 했으므로 한 번에 갈아엎는 선택지는 없었습니다.
해결서비스를 멈추지 않으려고 4단계로 나눠 순차 전환했습니다.
| 단계 | 전환 | 판단 |
|---|---|---|
| 1 | Java → Kotlin | 신규는 Kotlin으로 시작, 레거시는 영향도가 낮은 파일부터 전환 |
| 2 | 멀티레포 → 모노레포 | Presentation / Network / Common 3-Layer 멀티모듈 |
| 3 | MVVM → MVI | Compose·MVI 스터디를 열어 구성원과 함께 학습하고 코드 컨벤션 정리 |
| 4 | XML → Compose | 디자인 시스템부터 만들고, 신규·개편 화면부터 단계적으로 전환 |
아키텍처를 옮기고 나니 다음 병목은 빌드였습니다. 구버전 AGP에 병렬 빌드와 캐시가 꺼져 있어 최대 8분이 걸렸습니다. VersionCatalog로 모듈 간 버전을 맞추고, AGP·Gradle 최신화, Hilt의 kapt → KSP 전환과 Kotlin 2.0(K2) 업그레이드, 병렬 빌드·캐시 활성화로 빌드 시간을 줄였습니다.
결과
- Java → Kotlin 28.8% → 99.2%
- 앱별 레포를 모노레포로 통합 → 3개 앱 단일 구조
운영
- 빌드 최대 8분 → 3분
04
상황기존 자동 생성 스킬이 LINE 커버리지를 20.6%까지 올려둔 상태였는데, 생성된 테스트가 실패하면 결국 사람이 붙어야 해서 그 위로 올라가지 못하고 있었습니다.
자동화에 앞서 테스트를 어떤 모양으로 쓸지부터 정했습니다. Given-When-Then 패턴을 표준으로 잡아 요구사항 단위로 시나리오를 설계했고, 대상은 ViewModel의 비즈니스 로직으로 한정했고(JUnit5 · MockK · Turbine), UI 테스트는 이 파이프라인의 범위에 넣지 않았습니다. 형식이 정해져 있어야 자동 생성이 의미를 갖는다고 봤기 때문입니다.
해결생성만으로는 부족하다고 보고, 고치는 단계까지 넣은 5단계 파이프라인을 Claude Code로 설계했습니다.
Planner → Scaffold → Generator → Healer → Coverage
↑ ↓
└──────────┘ 실패 테스트 자동 진단·수정 루프핵심은 네 번째 수정 단계(Healer) 입니다. 실패한 테스트를 자동 진단해 고치고 다시 검증 루프를 도는 구조라, 사람 개입 없이 통과 가능한 지점까지 도달합니다.
결과
- 3,805줄 ViewModel 기준 LINE 20.6% →
83% / BRANCH 6.3% → 52% / METHOD 30% → 88% — 이후 전체
ViewModel에 적용
- QA 집계 기준 회귀 버그 티켓 50% 감소
세 지표를 함께 보는 이유는 LINE만으로는 분기 미탐지가 가려지기 때문입니다.
회고초기에 relaxed mock을 쓰다 분기를 못 잡는 문제가 있었습니다. MockWebServer + JSON fixture 패턴으로 전환했습니다.
05
상황사내 AI 봇 운영을 맡았습니다. 고객 상담봇은 최상위 모델이 질문마다 지식 베이스 전체를 훑어 답하는 구조라 토큰 소모가 컸고, 가장 높은 요금제를 쓰고도 사용 한도에 걸려 업무 시간 중에 상담이 멈추는 일이 생겼습니다. 자동응답 회수율도 22%에 머물렀습니다. 비용과 품질을 함께 고쳐야 한다고 보고 최적화를 시작했습니다.
해결고객에게 바로 나가는 시스템이라 비대칭 리스크가 있다고 봤고, 개선안을 바로 넣는 대신 측정 인프라부터 만들었습니다. 오답률·회수율·건당 비용 3축을 매일 자동 수집한 뒤, RAG 파이프라인과 토큰 구조를 재설계해 8개 variant를 Shadow A/B로 비교하고 대부분을 기각했습니다.
결과최종 후보 측정값
- 건당 비용 ₩2,173 → ₩97 (-96%)
- 자동응답 회수율 22% → 43%
- overconfidence 73% → 20%
다만 배포는 중단했습니다. 카나리 배포 직전 지식 베이스를 감사해 보니 고객에게 보여서는 안 되는 데이터가 섞여 있었습니다. 자격 증명 평문 6건(플레이스토어 계정 포함)과 회사 계좌 2건으로, 정규식 1차 필터에 LLM 2차 검증을 붙인 탐지 파이프라인을 직접 만들어 찾아냈습니다. 상담봇이 이 데이터를 답변에 실을 수 있는 상태였기 때문에, 지식 베이스를 사람이 한 번 검수하는 과정이 먼저 필요하다고 판단했습니다.
이 기간 운영에 반영한 것은 최우선 버그 7건 수정과 지식 베이스 카테고리 표준 분류 724건입니다. 파이프라인 개선분은 보안 보고서와 조치 권고를 올리고 봇 검색용 데이터와 사람 검토용 데이터를 분리하는 설계 변경을 제안하는 데서 마무리했습니다.
06
팀 구성 — Android 1 · iOS 1 · Frontend 1 · Backend 2 · Product Designer 1
상황원장과 직원의 회원가입이 분리돼 있었습니다. VOC·버그 대응으로 주 2~3회 불규칙하게 배포하던 상황이었습니다.
해결회원가입을 통합하고 강제/선택 업데이트를 구현했습니다. 배포 후 백엔드 롤백이 필요한 크리티컬 이슈가 났는데, 네이티브 앱은 심사와 배포를 거쳐야 해서 기민하게 대응하기 어려웠습니다. 그래서 Firebase RemoteConfig 피처 플래그 도입을 제안해 배포 없이 기능을 켜고 끌 수 있게 했고, 불규칙 배포를 정기 배포로 바꿨습니다. 업무 우선순위 제도도 함께 도입했습니다.
결과통합 회원가입 배포. 이후 장애는 앱 배포 없이 피처 플래그로 기능을 내려 대응할 수 있게 됐고, 이후 큰 프로젝트 배포에서 활용했습니다
회고백엔드는 바로 되돌릴 수 있어도 네이티브 앱은 장애에 기민하게 대응하기 어렵다는 것을 겪었습니다. 정기 배포와 피처 플래그가 왜 필요한지 이때 체감했습니다.
네이버 연동 고도화 | 2025.11 ~ 2026.05 | 기여도 100%
Android 1 · iOS 1 · Frontend 1 · Backend 1 · Product Designer 1
상황네이버 헤어샵을 통한 고객 유입을 늘리기 위해 네이버페이 매장결제·예약금·쿠폰·스타일 태그를 앱에 연동하는 프로젝트였습니다. 매장결제는 앱에서 결제를 요청한 뒤 고객이 자기 휴대폰에서 결제를 마칠 때까지 앱이 기다려야 하는 구조라, 그 사이에 결제 결과를 앱이 알 방법이 필요했습니다.
해결서버가 앱으로 결과를 알려주는 방식이 더 낫다고 봤지만 작업 공수가 매우 짧았습니다. 그래서 타임아웃을 두고 일정 주기로 승인 여부를 API로 확인하는 폴링 방식을 먼저 도입하자고 제안해 구현했습니다.
화면은 결제 요청 → 진행 중 → 완료 → 환불까지 전 플로우를 Compose + MVI로 만들었고, 스타일 태그는 카테고리별 복수 선택이 가능한 바텀시트로 구현했습니다. 백엔드 API가 나오기 전에는 로컬 JSON 목 데이터로 통신 케이스를 미리 만들어 개발하고 엣지 케이스를 먼저 공유했습니다. 외부 결제가 섞이면서 달라지는 매출·포인트 계산은 경우별로 백엔드와 규칙을 다시 맞췄습니다.
결과
- 매장결제 · 예약금 · 쿠폰 · 스타일 태그 배포
- 매출 ViewModel 단위 테스트는 자체 테스트 생성 파이프라인으로
작성, 네이버 예약 검증 E2E 플로우 구축
회고폴링은 짧은 일정에 맞춘 선택이었습니다. 서버가 결과를 알려주는 방식이 더 낫다는 점은 제안할 때 함께 공유했습니다.
Compose MVI 외부 결제 연동
Polling 단위 테스트 E2E
통계 개선 | 2025.01 ~ 06 · 2026.01 ~ 05 | 기여도 100%
Android 1 · iOS 1 · Frontend 1 · Backend 1 · Product Designer 1
상황통계 정합성 문제로 제공 중인 통계의 신뢰도가 떨어져 있었습니다. 통계 메뉴는 항목 나열 구조였고, 직원·고객·시간별·요일별 분석 화면은 네이티브에 없었습니다.
해결먼저 결제수단 다양화와 함께 통계 3종을 다시 만들었습니다. Compose 차트 라이브러리가 레퍼런스가 적고 커스터마이징에 제약이 있어, 디자인 가이드를 반영해 차트를 직접 구현하고 확장성과 UX 일관성을 기준으로 설계했습니다.
이후 이 차트 컴포넌트 위에 네 화면을 Compose로 구현했습니다. 차트는
막대·라인·테이블 세 종류를 직접 구현했습니다. 시간별·요일별 차트는
매출이 없는 시간대를 영업시간 기준으로 x축에 채우고, 24시 자정을 넘는
구간과 화면별 y축 단위를 따로 처리했습니다. 직원 통계 목록은 스크롤이
무거워 derivedStateOf·shadow·NumberFormat 재사용으로
최적화했습니다. 채널별·고객 통계처럼 웹 대시보드에 있는 화면은 브릿지로
네이티브↔︎웹을 오가게 연결했고, 메뉴는 용도별 3개 그룹 카드로
재편했습니다.
결과통계 3종과 직원·고객·시간별·요일별 분석 화면 배포 · 메뉴를 3그룹으로 재편해 매장이 한눈에 볼 수 있는 통계 화면 제공
Compose 차트 직접 구현
WebView Bridge derivedStateOf
결제수단 다양화 | 2025.01 ~ 06 | 기여도 100%
Android 1 · iOS 1 · Frontend 1 · Backend 1 · Product Designer 1
상황매출 구조가 결제수단 하나를 전제로 만들어져 여러 결제수단을 함께 받을 수 없었습니다. 매출 로직이 복잡한데 UI까지 직접 제어하는 구조라 유지보수와 기능 변경 때마다 비용이 컸습니다.
해결매출 등록 화면의 상호작용 로직을 상태 기반으로 구조화하고 Compose + MVI로 재설계했습니다. 백엔드 API가 나오기 전에는 로컬 JSON 목 데이터로 통신 케이스를 미리 만들어 개발했습니다.
결과매출 등록/수정 · 포인트 · 회원권 결제 차감 전면 구현 후 배포 · 담당 직원 복수 선택 등 기획 변경에 낮은 비용으로 대응 · 함께 진행한 통계 3종은 바로 위 통계 항목에 정리
회고기존 정책을 유지하는 로직에서도 결제 구조 개편의 사이드 이펙트가 났습니다. 변경 사항 간 연관성을 미리 점검했어야 했습니다.
Compose MVI 로컬 목 데이터
고객 목록 개선 | 2024.07 ~ 11 | 기여도 100%
Android 1 · iOS 1 · Frontend 1 · Backend 1 · Product Designer 1
상황고객 목록에 필터·그룹 기능이 없어 매장이 고객을 나눠 관리하기 불편했습니다.
해결B2B 앱에 Compose를 처음 도입하고 MVI를 적용했습니다. 필터·그룹은 조건 카테고리가 전부 숨김일 때의 노출 정책과, 필터 수정 후 복귀 시 리프레시 시나리오를 먼저 정의해 프론트·백엔드와 합의했고, 화면 전환 구조는 iOS와 회의록을 만들어 함께 정리했습니다. 디자인 시스템을 처음 적용한 화면으로, 필터에 필요한 컴포넌트는 디자이너와 상의해 공통 컴포넌트로 추가했습니다. 실시간 검색은 debounce로 불필요한 API 호출을 줄였고, 드래그앤드롭은 OS 업데이트로 외부 라이브러리가 깨져 직접 구현으로 바꿨습니다.
결과필터·그룹 기능 배포 · B2B 앱의 Compose 전환 시작점
Compose MVI 디자인 시스템
Paging3 Turbine
캘린더·예약 개편 | 2022.08 ~ 2023.07 | 기여도 90%
Android 2 · iOS 2 · Frontend 2 · Backend 3 · Product Designer 1
상황플랫폼별 캘린더 UX가 달라 사용자 혼란이 있었고, 웹뷰 화면마다 인증과 네비게이션을 매번 다시 붙이고 있었습니다.
해결이 프로젝트 하나만 고치는 대신 다음에도 쓸 수 있는 구조를 만들기로 했습니다. 웹뷰 브릿지 자체는 직전 프로젝트에서 메시지 발송 화면용으로 처음 만들었는데, 그때는 화면 하나에 맞춘 것이었습니다. 캘린더에서 이를 공통 함수 15개 이상으로 컨벤션화하고 문서화해, 쿠키 인증 + 단일 Activity 구성으로 화면 뎁스와 무관하게 재사용되게 했습니다. 테스트가 없던 시점이라 JUnit5도 이 프로젝트에서 처음 들였습니다.
결과이후 메시지 발송·네이버 연동 등 새로 추가된 WebView 기능이 이 브릿지를 재사용
회고초기 고객 니즈 파악이 미흡해 클레임이 발생했습니다. 이를 계기로 기획 단계에 고객 인터뷰 프로세스를 제안했습니다.
WebView Bridge Paging3 FCM
JUnit5
Android 2(본인 포함) · iOS 2 · QA 1 네이티브 팀
AI 기반 Android 개발 고도화 | 2025.07 ~ 2026.02 | 기여도 100%
상황테스트 코드 작성, Compose UI 구현, API 연동 코드, 문자열 리소스, 작업 티켓·브랜치·커밋·PR 생성처럼 작업마다 반복되는 일이 많았습니다. AI 도구를 들인 초기에는 활용 수준이 사람마다 크게 갈렸고, 각자 만든 스킬과 설정은 로컬에만 있어 옆 사람이 볼 방법이 없었습니다.
해결반복 작업을 Claude Code 커스텀 스킬
14종(create-api, compose-ui,
string-resource, backlog-refiner,
command-creator 등)과 MCP(Figma·Notion) 연결로
자동화했습니다. 가장 까다로웠던 건 UI였습니다. 토큰 제약 때문에 화면
전체를 한 번에 맡기기 어려워, Figma 디자인 가이드와
디자인시스템(컬러·타이포그래피·컴포넌트)을 컨벤션 문서로
구조화해 가이드에 가까운 Compose 코드가 나오도록 했습니다.
브랜치·커밋·PR·문자열 리소스 컨벤션도 같은 방식으로 문서화했습니다.
결과반복되는 작업을 AI에 위임해 핵심 개발에
집중할 수 있는 환경을 만들어 생산성을 높임 · 스킬 14종과 컨벤션 문서를
레포에 올리고 사용법을 팀 공통 문서로 전파해 팀원들도
사용 · 플랫폼이 달라도 서로의 스킬을 볼 수 있게 팀 간 레포 열람 권한을
정리 · compose-ui로 만든 화면은 대부분 큰 수정 없이 리뷰를
통과
Claude Code MCP
프롬프트·컨텍스트 엔지니어링 컨벤션 문서화
종료된 상담은 관리자 페이지에 상담 이력으로 남겨야 했고, 그동안은
사람이 이 등록을 따로 반복하고 있었습니다. 문의 통계와 해지 분석의
바탕이 되는 데이터라 빠뜨릴 수도 없는 일이었습니다. 이 반복
작업을 AI로 넘겨 사람 손에서 없앴습니다.
한 일 종료된 상담 내용을 LLM으로 읽어 상담 유형을
분류하고, 상담 이력으로 자동 등록하는 작업을 만들어 평일 10분
주기로 운영에 반영 · 분류 기준은 CX 리드·상담사와 함께 맞춤 ·
중복 등록 방지 기준을 자체 상태 파일이 아닌 상담 솔루션의 처리 상태값에
두어 스크립트가 죽어도 판정이 흔들리지 않게 함 · 등록은 됐는데 상태
전환만 실패한 건은 재처리 큐로 분리 · 모델이 고른 카테고리가 실제 분류
트리에 있는지 역검증하고, 확신도가 낮으면 ’기타’로 처리
사내 AI 봇들의 토큰 소모가 커서 사용 한도에 자주 걸렸는데, 어느 봇이
얼마나 쓰는지와 봇이 살아 있는지는 개발자가 터미널로만 확인할 수
있었습니다.
한 일 봇별 토큰 사용량을 수집해
기간별(5시간·7일·오늘)·모델별·봇별 차트로 보여주는 웹
화면을 설계·구현 · 봇 상태를 정상·주의·오류 3단계로 표시하고
실시간 로그 보기와 재시작 버튼을 붙여, 문제가 생겼을 때
터미널 없이도 원인을 보고 다시 띄울 수 있게 함 · 새 봇은 자동 감지 ·
상시 떠 있는 화면이라 메모리·CPU 부하를 최소화하는 것을 제약으로 둠 ·
사용 가이드를 문서로 남겨 직무와 상관없이 누구나 보고 조치할 수
있게 공유
사내 백엔드 API를 Claude Code에서 바로 다룰 수 있게 TypeScript로 로컬
MCP 서버를 만들었습니다. 완성 후 네이티브 팀 구성원에게 설치·사용법을
전파해 쓸 수 있게 했습니다.
한 일 도구 87개 구현(GET 84 / WRITE
3) · 53개에 직원 권한 코드 7종 매핑으로 접근 제한 + 연락처 마스킹 ·
토큰을 평문 파일 대신 macOS Keychain에서 로드
Android 프리랜서 · 2020.12 ~ 2021.06
대교 써밋 국어 — 초등학생 국어 학습 태블릿 앱 · 필기와 음성이 주 입력 방식
01
상황초등학생 국어 학습 앱이라 필기와 음성이 주 입력 방식이었습니다. 학습 노트와 문제 풀이에는 필기가, 소리 내어 읽기 평가에는 음성 인식이 필요했습니다.
해결Samsung S-Pen SDK로 학습 노트·문제 풀이 영역에 필기 인식을 구현했습니다(필압 감지·손바닥 리젝션). 음독 평가는 음성 인식(STT)을 통합했는데, 벤더는 같은 문구로 구글 STT와 비교 테스트해 한글 인식률이 우위였던 셀바스로 정했습니다.
02
상황학습 결과를 아이가 한눈에 볼 수 있게 보여줘야 했고, 교육용 태블릿 여러 기종에서 안정적으로 돌아가야 했습니다.
해결MPAndroidChart 차트와 WebView 기반 워드클라우드로 학습 결과를 시각화했습니다. Android Profiler로 메모리 사용을 분석해 최적화했고, Galaxy Tab S6 Lite부터 S7+까지 기종별 호환성을 맞췄습니다. Volley로 네트워크 통신을 구성하고 Firebase Crashlytics·Analytics·IMQA로 모니터링 체계를 갖췄으며, 코드는 Javadoc으로 문서화했습니다.
Android 프리랜서 · 2020.06 ~ 2020.07
메디팔 — 환자와 간호사를 1:1로 매칭해 건강관리를 제공하는 서비스
01
상황Android 앱을 착수 단계부터 혼자 맡았습니다. 환자와 간호사가 실시간으로 대화하는 채팅이 핵심 기능이었습니다.
해결텍스트와 이미지를 주고받는 채팅방을 WebSocket으로 직접 구현했습니다. 채팅 이미지는 기기에 캐싱해 대화 기록을 다시 볼 때 매번 내려받지 않게 했습니다. Retrofit 기반 네트워크 통신, ExoPlayer 미디어 플레이어, 채널톡 API 연동, FCM 푸시를 함께 구현했습니다.
결과착수부터 배포까지 2개월 · 자체 QA 후 스토어 배포
Android · 2018.08 ~ 2019.09
비트탑 — 암호화폐 거래소 앱
01
상황거래소 앱에서 이더리움과 ERC-20 토큰의 잔액·거래 내역을 모바일 화면에 보여줘야 했습니다.
해결Web3j로 이더리움 네트워크와 직접 통신하는 모듈을 개발해 ERC-20 토큰 잔액과 거래 내역을 조회하고 화면에 표시했습니다. 블록체인 통신의 비동기 처리와 에러 핸들링을 구현했고, 실시간 시세 조회·거래 기능, 키스토어 기반 개인키 관리, PIN·지문 인증을 맡았습니다.
02
해결WebView로 휴대전화 본인확인(다날)과 도로명주소 입력을 연동했습니다. LeakCanary로 메모리 누수를 점검하고 FCM·Analytics·Crashlytics를 도입했습니다. Android와 함께 Spring·JPA 기반 백엔드 REST API도 직접 개발했습니다.