기술 스택
FlutterDartProviderRiverpodGitLab CI/CDGitLab IssueMS PlannerMS LoopFastlaneMaestroFirebaseSentryGA4BigQueryFeature-based Clean Architecture
문제 상황
- 문서, 이슈 관리, 테스트 정리, 배포 관리 체계가 부족해 업무 요청과 개발 이력이 체계적으로 연결되지 않는 상태였습니다.
- 하나의 GitLab repository에서 글로벌 앱과 일본 앱을 branch로 나누어 관리하며 공통 기능을 중복 개발해야 하는 생산성 문제가 있었습니다.
- 여러 사람이 관리 없이 개발하며 중복 코드와 일관되지 않은 설계가 쌓여 유지보수와 신규 개발을 병행하기 어려운 상태였습니다.
- 출시 이후 문제를 빠르게 확인할 수 있도록 테스트 자동화, 모니터링, 운영 데이터 확인 체계가 필요했습니다.
내 역할
- 모바일 Tech Lead로 개발 프로세스, 소스 관리, 리뷰, 테스트, 배포 기준을 새로 수립했습니다.
- MS Teams 환경 안에서 바로 적용 가능한 이슈 관리와 문서 관리 체계를 설계하고 도입했습니다.
- 공통 기능 재사용과 점진적 마이그레이션을 위해 Feature-based Clean Architecture 기반 개선 방향을 잡았습니다.
- Flavor 기반 환경 분리, Fastlane, GitLab Runner CI/CD, Mac 배포 프로그램을 활용한 배포 자동화 흐름을 설계했습니다.
- 테스트 자동화와 모니터링 도구를 제품 개발 흐름에 연결했습니다.
접근 방식
- MS Planner를 도입해 Backlog, Todo, Doing, Review, Done, Archive 단계로 이슈를 관리하도록 정리했습니다.
- GitLab Issue ID와 MS Planner 업무 내용을 연결해 개발 이력과 업무 보고의 신뢰성, 연속성을 유지하도록 했습니다.
- Confluence를 바로 사용할 수 없는 환경에서 MS Loop을 활용해 개발 내용과 히스토리를 문서로 관리했습니다.
- main, dev, issue 기반 worktree branch, MR review 중심 브랜치 전략을 수립하고 MR 전 lint, 테스트 코드, Unit Test, 테스트 케이스 문서화 기준을 정리했습니다.
- VSCode, lint, 설정값을 통일해 개발 컨벤션을 맞추고, 신규 기능은 Feature-based Clean Architecture로 개발하며 기존 소스는 점진적으로 마이그레이션했습니다.
- 글로벌/일본 앱 branch 분리 구조를 Flavor 기반 단일 repository 구조로 개선해 공통 기능 중복 개발을 줄일 수 있도록 설계했습니다.
- Fastlane과 Mac 배포 프로그램을 통해 Flavor별 테스트·배포 빌드를 자동화하고 배포 과정의 human-error를 줄일 수 있도록 구성했습니다.
- Firebase, TestFlight, Sentry, GA4, BigQuery를 활용해 배포와 운영 데이터를 확인할 수 있는 기반을 만들었습니다.
- Maestro 기반 E2E 테스트를 도입해 주요 사용자 흐름을 릴리즈 전 검증할 수 있도록 구성했습니다.
결과
- 모바일팀 개발 업무를 이슈·문서·리뷰·테스트·배포 흐름으로 관리할 수 있는 체계로 정리했습니다.
- Flavor 기반 단일 repository 구조와 공통 기능 재사용 방향을 마련해 중복 개발을 줄일 수 있는 기반을 만들었습니다.
- 신규 기능 개발과 기존 코드 개선을 병행할 수 있는 아키텍처와 마이그레이션 방향을 마련했습니다.
- 서비스별 빌드와 배포 과정을 자동화해 반복 작업과 human-error를 줄이고 릴리즈 안정성을 높이는 기반을 만들었습니다.
- 배포 전 E2E 검증과 배포 후 운영 데이터 확인 체계를 구축해 제품 개발과 운영의 피드백 루프를 강화했습니다.
근거 자료
- Flavor 기반 국가/서비스별 빌드 구성
- MS Planner 기반 이슈 단계 관리
- GitLab Issue와 MS Planner 연계
- MS Loop 기반 개발 문서와 히스토리 관리
- main/dev/worktree branch/MR review 기반 브랜치 전략
- Feature-based Clean Architecture 기반 점진적 마이그레이션
- Fastlane과 Mac 배포 프로그램 기반 배포 자동화
- GitLab Runner 기반 CI/CD 자동화
- Sentry 기반 모니터링 적용
- GA4와 BigQuery 기반 통계 설계
- Maestro 기반 E2E 테스트 시나리오
기술 스택
Claude CodeCodexOpenClawHermesAgent SkillsMarkdownFlutterRiverpodMaestroGitLab
문제 상황
- 신규 모바일 서비스, 운영 자동화, 개발팀 체계 정립을 동시에 진행해야 하는 상황이었습니다.
- 시니어와 주니어가 함께 일하는 팀에서 요구사항, 설계 의도, 리뷰 기준이 개인에게만 남지 않도록 관리할 필요가 있었습니다.
- 짧은 기간 안에 여러 프로젝트를 출시해야 했기 때문에 개발 속도와 품질 관리 절차를 함께 확보해야 했습니다.
내 역할
- 모바일 Hands-on Tech Lead로 신규 서비스 설계와 핵심 구현 방향을 잡았습니다.
- AI Agent를 팀 개발 프로세스에 적용하는 방식과 산출물 기준을 설계했습니다.
- 주니어 개발자의 작업 맥락을 유지할 수 있도록 리뷰, 문서화, 피드백 반영 흐름을 운영했습니다.
접근 방식
- Claude Code, Codex, OpenClaw, Hermes를 요구사항 분석, PRD 작성, 설계, 구현, 코드 리뷰, 테스트, 피드백 반영 단계에 나누어 적용했습니다.
- Flutter, Provider, Riverpod, Clean Architecture 기준을 Agent Skills로 구조화해 프로젝트별 개발 컨텍스트를 재사용할 수 있게 했습니다.
- PRD, Design, Development Plan, Test Case를 Markdown 산출물로 관리해 의사결정 이력과 작업 맥락을 남겼습니다.
- Maestro 기반 E2E 테스트 자동화와 코드 리뷰 절차를 함께 운영해 빠른 개발 과정에서도 검증 흐름을 유지했습니다.
결과
- 4인 개발팀이 한 달 동안 3개 프로젝트를 병렬로 진행하고 출시까지 완료할 수 있는 협업 구조를 만들었습니다.
- 요구사항부터 피드백 반영까지 이어지는 개발 흐름을 문서와 Agent 기반으로 반복 가능하게 정리했습니다.
- AI Agent를 일회성 코드 생성 도구가 아니라 팀 단위 개발 운영 도구로 활용하는 기반을 만들었습니다.
근거 자료
- Agent Skills 기반 개발 컨텍스트
- Markdown 기반 PRD, 설계, 개발 계획, 테스트 케이스 산출물
- Maestro E2E 테스트 자동화 흐름
- GitLab Issue와 Merge Request 기반 협업 흐름
기술 스택
Next.jsReactTypeScriptTailwind CSSSupabaseSupabase AuthReact QueryReact Tableshadcn/uiGoogle Cloud Translationjszipxlsx
문제 상황
- 운영 중인 Flutter 앱의 다국어 리소스를 프로젝트별로 확인하고 수정할 수 있는 사내 관리 도구가 필요했습니다.
- 관리자, 번역자, 개발자가 각자 다른 권한과 업무 흐름으로 언어셋을 다뤄야 했습니다.
- JSON 파일을 직접 수정하거나 Excel로 주고받는 방식은 변경 이력 추적과 실수 방지에 한계가 있었습니다.
- 사내 도구이기 때문에 외부 사용자 가입을 막고 phoenixdarts.com 이메일 사용자만 인증할 수 있는 접근 제어가 필요했습니다.
내 역할
- PM으로 프론트엔드와 백엔드 역할을 나누고 요구사항, 화면, API, 데이터 모델을 정리했습니다.
- Next.js App Router와 Supabase 기반의 풀스택 구조를 설계하고 주요 기능 구현을 리드했습니다.
- 관리자, 번역자, 개발자 역할별 권한 모델과 프로젝트 멤버십 검증 흐름을 설계했습니다.
- 개발 완료 후 인증, API, 데이터 모델, Import/Export, AI 번역, 배포 기준을 개발자 가이드로 문서화했습니다.
접근 방식
- Lokalise를 참고 사이트로 삼아 프로젝트 단위 언어셋 관리, 번역 테이블, Import/Export, 역할 기반 협업 흐름을 사내 환경에 맞게 재구성했습니다.
- Next.js 16 App Router에서 인증 영역과 대시보드 영역을 분리하고, Supabase Auth OTP 기반 이메일 인증을 구성했습니다.
- 가입 가능한 이메일을 phoenixdarts.com 도메인으로 제한하고, 프로젝트별 멤버십과 admin, translator, developer 역할에 따라 API 권한을 검증했습니다.
- projects, project_members, languages, translation_keys, translations, translation_history 구조로 다국어 리소스와 변경 이력을 관리했습니다.
- React Query와 React Table을 활용해 1,900여 개 번역 키와 17개 언어를 검색, 필터, 페이지네이션, inline edit로 관리하는 번역 테이블을 구성했습니다.
- JSON 다중 파일 Import, Excel 다국어 일괄 Import, JSON/Excel Export를 구현해 앱 리소스와 번역 협업 흐름을 연결했습니다.
- 빈 번역 셀에서 Google Cloud Translation 기반 AI 번역을 호출하고 Enter/Escape 키로 적용과 취소를 처리하는 편집 흐름을 만들었습니다.
- 업데이트 히스토리, 활동 로그, 멤버 관리, 언어 순서 변경을 포함해 운영자가 프로젝트 상태를 확인할 수 있도록 구성했습니다.
결과
- 사내용 다국어 리소스 관리 플랫폼을 구축했습니다.
- 관리자, 번역자, 개발자 역할별로 언어셋 추가, 수정, Import/Export, 멤버 관리를 수행할 수 있는 업무 흐름을 만들었습니다.
- Flutter 앱 언어셋 JSON 파일과 Excel 번역 파일을 웹 플랫폼에서 관리할 수 있게 해 수작업 오류를 줄일 수 있는 기반을 마련했습니다.
- 변경 이력과 활동 로그를 남겨 번역 수정 과정의 추적 가능성을 높였습니다.
- 개발자 가이드를 작성해 이후 기능 확장과 운영 인수인계가 가능하도록 정리했습니다.
근거 자료
- 사내 다국어 관리 플랫폼 실제 서비스 화면 캡처
- 참고 사이트 Lokalise 기반 기능 범위 검토
- 1,961개 번역 키와 17개 언어를 표시하는 번역 관리 테이블
- 다국어 관리 플랫폼 개발자 가이드 문서
- phoenixdarts.com 이메일 도메인 제한 인증 흐름
- admin, translator, developer 역할 기반 API 권한 설계
- JSON/Excel Import·Export 기능
- Google Cloud Translation 기반 AI 번역 기능
- translation_history와 activity_logs 기반 변경 이력 관리
기술 스택
FlutterDartAMQPMQTTWebSocketRabbitMQPushCustom WidgetCanvasFeature-based Clean ArchitectureMVP
문제 상황
- 다트 머신에서 발생하는 점수와 경기 진행 상황을 앱에서 실시간으로 확인할 수 있는지 기술 가능성을 검토해야 했습니다.
- 게임 시작 Push, 실시간 점수 수신, 게임 종료, 히스토리 확인, SNS 공유까지 이어지는 사용자 시나리오를 앱 관점에서 구체화할 필요가 있었습니다.
- 서버 통신 설계 정보가 충분하지 않은 상태에서 MQTT, WebSocket, AMQP 등 가능한 실시간 통신 방식을 비교하고 앱 연동 구조를 예상해야 했습니다.
- 머신의 좌표와 점수 데이터를 앱 화면의 다트 UI에 정확히 표현하기 위한 좌표 변환과 Custom UI 설계가 필요했습니다.
내 역할
- 모바일 Tech Lead로 요구사항 초안을 정리하고 MVP에서 검증해야 할 기능 범위를 정의했습니다.
- 실시간 통신 방식, 데이터 플로우, 앱 화면 구성, 테스트 방향을 모바일 앱 관점에서 설계했습니다.
- Flutter 앱에 적용할 `features/realtime` 구조와 `realtime_darts` 화면 흐름을 Feature-based Clean Architecture 기준으로 정리했습니다.
- 개발 명세로 확장될 수 있도록 요구사항, 프로토콜, 인터페이스, 일정 및 테스트 항목을 문서화했습니다.
접근 방식
- 게임 시작 Push를 통해 앱이 실시간 경기 화면으로 진입하고, 점수 데이터 수신 후 다트 UI에 표시되는 사용자 흐름을 정의했습니다.
- MQTT는 토픽 구독 기반의 빠른 데이터 전달 방식으로, WebSocket은 웹 확장성과 요청/응답 구조 측면에서 비교 검토했습니다.
- AMQP 기반 데모 서버와 Publish API를 활용해 card sequence별 queue 구독, routing key, payload 전달 흐름을 검증할 수 있도록 정리했습니다.
- 다트 머신과 유사한 화면을 만들기 위해 Custom Widget, Canvas 기반 표현, 좌표 to pixel/dp 변환 알고리즘 필요성을 정리했습니다.
- Lottie, Rive, WebP 등 애니메이션 패키지 후보와 게임 시작/완료 애니메이션 적용 방향을 검토했습니다.
- 앱 화면 전환, 통신 불안정, 재접속, 백그라운드 통신 대응을 고려해 AOS Service와 iOS Background fetch 관점의 추가 검토 항목을 도출했습니다.
결과
- 실시간 다트 기록 확인 기능의 요구사항, 기능 정의, 기술 검토 항목을 MVP 개발 가능한 수준으로 구조화했습니다.
- MQTT, WebSocket, AMQP 기반 통신 후보를 앱 연동 관점에서 비교하고 데이터 흐름과 시퀀스를 문서화했습니다.
- 실시간 점수 표시 화면을 Flutter 앱에 추가하기 위한 `features/realtime` 구조와 `realtime_darts` 화면 방향을 정리했습니다.
- 향후 개발 명세, QA, 예외 사항 검증, 데모 서버 테스트로 이어질 수 있는 기술 검토 문서를 만들었습니다.
근거 자료
- 실시간 다트 기록 확인 요구사항 초안
- MQTT/WebSocket 통신 구조 및 시퀀스 정리
- AMQP Publish API와 queue 구독 테스트 흐름
- DartData payload 모델과 점수 데이터 필드 정의
- 다트보드 Custom UI와 좌표 변환 검토
- Feature-based Clean Architecture 기반 `features/realtime` 설계
기술 스택
FlutterDartFlavorFastlaneGitLab CI/CDAndroidiOSXcodeClean ArchitectureWorktreeTest Plan
문제 상황
- 글로벌 앱과 일본 앱이 develop/dev_jp 브랜치로 분리되어 있어 공통 기능을 중복 개발하거나 버그 수정이 누락될 가능성이 있었습니다.
- 국가별 차이를 코드 곳곳에서 분기하면 테스트가 어려워지고 유지보수 비용이 커질 수 있었습니다.
- 앱별 package name, bundle id, entry point, 배포 경로가 달라 빌드와 배포 과정에서 human-error가 발생할 수 있었습니다.
- 브랜치 통합 이후에도 글로벌/일본 앱이 기존 앱과 동일하게 동작하는지 검증할 수 있는 테스트 전략이 필요했습니다.
내 역할
- 모바일 Tech Lead로 기존 브랜치 구조와 앱 차이를 분석하고 통합 전략을 수립했습니다.
- 단일 master/develop 기반 운영과 release/jp, release/global 배포 브랜치 전략을 설계했습니다.
- Flavor를 비즈니스 로직 분기 수단이 아니라 빌드·환경·앱 식별자 분리 수단으로 사용하는 원칙을 정리했습니다.
- Fastlane, GitLab CI/CD, 수동/자동 테스트 체크리스트를 포함한 배포와 검증 전략을 문서화했습니다.
접근 방식
- develop 브랜치를 기준으로 integration 브랜치를 만들고 dev_jp 브랜치 차이를 분석해 Japan 전용 기능을 통합하는 흐름을 설계했습니다.
- globalDev, globalProd, japanDev, japanProd Flavor 매트릭스를 정의하고 entry point와 Android/iOS 식별자 분리 기준을 정리했습니다.
- UI 전반의 Flavor 분기는 지양하고 Entry Widget, Factory, Router, Domain 추상화 지점에서만 차이를 처리하는 규칙을 세웠습니다.
- GitLab CI/CD에서는 master merge 이벤트를 기준으로 global/japan Flavor 병렬 빌드와 배포가 가능하도록 파이프라인 방향을 정리했습니다.
- Fastlane 기반 Android/iOS 빌드 전략을 정리하고 iOS에서는 target 중심 빌드 방식 등 플랫폼별 제약을 반영했습니다.
- 통합 후 global Flavor는 기존 develop 빌드와, japan Flavor는 기존 dev_jp 빌드와 동일하게 동작해야 한다는 검증 기준을 세웠습니다.
결과
- 브랜치는 통합하고 앱은 Flavor로 분리하는 단일 코드베이스 운영 전략을 수립했습니다.
- 공통 기능 중복 개발과 버그 수정 누락 가능성을 줄일 수 있는 코드 관리 기준을 마련했습니다.
- Flavor별 빌드, 배포, 테스트 명령과 후속 검증 계획을 문서화해 팀이 재현 가능한 작업 흐름을 갖게 했습니다.
- Android global dev, Japan prod, iOS global dev 등 주요 Flavor 빌드 검증 흐름을 정리했습니다.
근거 자료
- develop/dev_jp 브랜치 차이 분석과 integration 브랜치 통합 플로우
- Global/Japan Flavor 매트릭스와 entry point 설계
- Flavor 적용 금지 규칙과 Domain 추상화 기준
- GitLab CI/CD Flavor 병렬 빌드·배포 전략
- Fastlane 기반 Android/iOS 빌드 설정 문서
- Flavor 통합 테스트 계획과 수동 테스트 체크리스트
기술 스택
FlutterDartGetXKotlinMethod ChannelFirebaseTestFlight
문제 상황
- 회의록 시스템의 모바일 사용 흐름을 빠르게 검증할 수 있는 MVP가 필요했습니다.
- Android 통화 녹음 파일 관리처럼 Flutter만으로 처리하기 어려운 네이티브 연동 기능이 포함되어 있었습니다.
- 녹음 파일 보안과 상태관리, 앱스토어 배포까지 짧은 기간 안에 함께 해결해야 했습니다.
내 역할
- Flutter Hands-on 프로젝트 리드로 모바일 앱 구조와 핵심 기능 개발을 담당했습니다.
- Android Method Channel 기반 네이티브 기능 연동과 파일 암호화/복호화 흐름을 구현했습니다.
- 음성 녹음, 재생, 데이터 관리, 콘텐츠 상태, 푸시 알림 등 모바일 시나리오를 기획했습니다.
접근 방식
- Flutter와 GetX를 사용해 Android/iOS 동시 배포가 가능한 MVP 구조를 구성했습니다.
- Android Method Channel로 통화 녹음 파일 관리 기능을 연동했습니다.
- 녹음 파일 자체 암호화/복호화 처리와 녹음 기능 상태관리를 구현했습니다.
- Firebase와 TestFlight를 활용해 테스트와 배포 과정을 진행했습니다.
결과
- SK 사내 녹취 시스템 MVP를 4주 내 개발·배포하며 빠른 검증이 가능한 모바일 제품을 만들었습니다.
- Flutter 기반으로 Android와 iOS 앱을 동시에 배포해 개발 및 관리 효율을 높였습니다.
- 네이티브 기능이 필요한 모바일 서비스에서도 Flutter를 활용할 수 있는 구현 경험을 확보했습니다.
근거 자료
- Google Play 등록 앱
- Android Method Channel 기반 통화 녹음 파일 관리
- 녹음 파일 암호화/복호화 처리
- Firebase 기반 테스트 앱 운영
기술 스택
AndroidKotlinJavaSwiftUIMVVMWebSocketFirebaseUnity UI
문제 상황
- 청각장애인 사용자를 위한 브라우저 기반 접근성 서비스를 모바일 환경에서 안정적으로 제공해야 했습니다.
- 오픈소스 브라우저 커스텀, 영상 음성 데이터 처리, 수어 UI 연동 등 여러 기술 영역을 함께 다뤄야 했습니다.
- 정부지원 사업 특성상 개발 실무와 프로젝트 리딩, 제안 대응이 함께 요구되었습니다.
내 역할
- PL로 프로젝트 진행을 리드하고 Android 고급 개발자와 iOS 개발자로 실무 개발을 수행했습니다.
- Firefox for Android 오픈소스를 분석하고 서비스 요구사항에 맞게 커스텀 적용했습니다.
- 한국정보통신기술협회, 시청자미디어재단 대상 개발 관련 서비스 제안에 참여했습니다.
접근 방식
- SNS 로그인, 회원관리, UI 고도화 기능을 Android/iOS 앱에 적용했습니다.
- Java 기반 Android 코드를 Kotlin으로 전환하고 MVVM 구조를 적용했습니다.
- 영상의 음성 데이터를 추출해 WebSocket으로 내부 솔루션 서버와 연동하고 자막 처리 흐름을 구성했습니다.
- 수어 기능을 위해 Unity UI를 모바일 앱에 연동했습니다.
결과
- 정부지원 사업을 3년간 이어갈 수 있도록 모바일 개발과 프로젝트 리딩을 수행했습니다.
- Android와 iOS 앱스토어 배포를 완료하고 현재까지 서비스될 수 있는 기반을 만들었습니다.
- 접근성 서비스에서 브라우저, 음성 처리, 수어 UI를 연결하는 복합 모바일 개발 경험을 쌓았습니다.
근거 자료
- Google Play 등록 앱
- Firefox for Android 오픈소스 커스텀
- WebSocket 기반 음성 데이터 연동
- Unity UI 기반 수어 기능 연동
기술 스택
AndroidJavaObjective-CSwiftJNISocketBLENFC
문제 상황
- 피부와 헤어 진단기에서 발생하는 영상, 제품, 카메라 제어 데이터를 모바일 앱에서 안정적으로 처리해야 했습니다.
- 제품 판매와 해외 납품을 위해 Android/iOS UI, 장비 통신, 진단 알고리즘, 생산 검증까지 폭넓은 개발이 필요했습니다.
- 스타트업에서 시작한 제품을 장기간 운영 가능한 형태로 개발하고 개선해야 했습니다.
내 역할
- PM, PL, 주 개발자로 모바일 앱 UI/UX 기획과 핵심 기능 개발을 담당했습니다.
- 카메라 모듈, 진단 알고리즘, 제품 연동 프로토콜 설계와 구현을 수행했습니다.
- 생산 QC 앱, 생산 ERP 서버, 클라우드 서비스 기획과 설계에도 참여했습니다.
접근 방식
- Socket 기반 제품 연동 프로토콜을 설계해 H.264 영상 데이터와 카메라 제어 정보를 처리했습니다.
- 영상 데이터와 카메라 데이터 처리를 위해 JNI Interface와 네이티브 모듈을 설계했습니다.
- BLE와 NFC 기반 제품 연동 기능을 개발해 제품 정보와 통신 흐름을 앱에서 활용할 수 있게 했습니다.
- QC 팀과 협업해 생산 검증 앱과 생산 관리 시스템 설계를 진행했습니다.
결과
- 국내외 제품 판매와 P&G, 로레알 등 B2B 납품에 필요한 핵심 모바일 개발을 수행했습니다.
- 스타트업으로 시작한 제품이 장기간 판매될 수 있도록 모바일 앱과 제품 연동 기반을 구축했습니다.
- 피부/헤어 진단기 업체로서 국내외 시장에 제품을 공급하는 과정에 기여했습니다.
근거 자료
- Chowis 제품 소개 사이트
- Socket, BLE, NFC 기반 제품 연동
- JNI Interface 기반 영상/카메라 데이터 처리
- 생산 QC 앱과 생산 ERP 설계 경험