Portfolio

사례 중심 포트폴리오

실제 개발 조직과 제품 출시 과정에서 만든 사례 중심 포트폴리오입니다. 각 항목은 문제 상황, 내 역할, 접근 방식, 결과, 근거 자료를 기준으로 정리했으며 실제 공개 가능한 범위 안에서 작성하였습니다.

PDF 전용 페이지

Focus

AI Agent 개발 운영

요구사항부터 테스트와 피드백 반영까지 이어지는 팀 단위 워크플로우를 구조화한 사례를 중심으로 정리했습니다.

Mobile

Flutter / Native 리딩

Android, iOS, Flutter 개발 경험을 기반으로 크로스플랫폼 전환과 네이티브 연동을 수행한 사례를 담았습니다.

Product

출시·운영·사내 도구

CI/CD, Flavor, Maestro E2E 테스트, 모니터링과 사내 웹 도구 구축 경험을 함께 설명합니다.

Case 01

모바일 개발팀 프로세스 재정립과 배포 자동화 구축

㈜피닉스다트 / 2025.10 ~ 2026.05

㈜피닉스다트

사례 요약

입사 당시 문서, 이슈 관리, 브랜치 전략, 테스트, 배포 관리가 체계화되지 않은 모바일 개발 환경에서 이슈·문서·소스·리뷰·테스트·배포 흐름을 새로 정립하고, Flavor와 Fastlane 기반 배포 자동화를 구축한 Tech Lead 사례입니다.

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 테스트 시나리오
Google PlayApp Store

Case 02

AI Agent 기반 모바일 개발 프로세스 구축

㈜피닉스다트 / 2025.10 ~ 2026.05

㈜피닉스다트

사례 요약

4인 개발팀이 여러 신규 모바일 프로젝트를 병렬로 진행해야 하는 상황에서 AI Agent 기반 개발 워크플로우를 실무 개발 과정에 도입한 사례입니다.

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 기반 협업 흐름
Google PlayApp Store

Case 03

사내 다국어 관리 플랫폼 구축

㈜피닉스다트 / 2026.02

㈜피닉스다트

사례 요약

Flutter 앱의 localizable 리소스를 사내에서 관리하기 위해 구축한 다국어 번역 관리 웹 플랫폼 사례입니다. Lokalise와 같은 외부 서비스를 참고하되, 사내 이메일 인증, 역할 기반 권한, JSON/Excel Import·Export, 변경 이력, AI 번역 기능을 Phoenix Darts 업무 환경에 맞게 설계하고 구현했습니다.

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 기반 변경 이력 관리
서비스 보기참고 사이트

Case 04

실시간 다트 기록 확인 MVP 기술 검토

㈜피닉스다트 / 2025.11

㈜피닉스다트

사례 요약

실제 다트 머신에서 진행되는 경기 내용을 모바일 앱에서 실시간으로 확인하기 위한 MVP 기술 검토 사례입니다. 요구사항이 러프한 상태에서 예상 사용자 시나리오, 실시간 통신 구조, 데이터 흐름, 다트보드 UI, 앱 화면 구성을 정리하고 개발 명세로 확장 가능한 초안을 만들었습니다.

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` 설계
Google PlayApp Store

Case 05

Global/Japan 앱 코드 통합과 Flavor 배포 전략

㈜피닉스다트 / 2025.11

㈜피닉스다트

사례 요약

글로벌 앱과 일본 앱이 별도 브랜치로 관리되던 Flutter 프로젝트를 단일 코드베이스와 Flavor 기반 운영 구조로 통합하기 위한 전략 문서화 사례입니다. 브랜치 전략, Flavor 분리 원칙, Android/iOS 빌드 설정, Fastlane 배포, CI/CD, 테스트 계획까지 하나의 실행 가능한 통합 방향으로 정리했습니다.

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 통합 테스트 계획과 수동 테스트 체크리스트
Google PlayApp Store

Case 06

팀블로 모바일 MVP 4주 개발 및 출시

㈜팀벨 / 2024.01 ~ 2024.12

㈜팀벨

사례 요약

Flutter 기반 녹취/회의록 모바일 MVP를 빠르게 개발하고 Android와 iOS 배포까지 진행한 사례입니다.

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 기반 테스트 앱 운영
Google Play

Case 07

이어줌 접근성 모바일 서비스 개발 및 PL 수행

㈜팀벨 / 2022.06 ~ 2023.12

㈜팀벨

사례 요약

청각장애인 접근성 서비스를 위한 Android/iOS 개발과 PL 역할을 수행하며 정부지원 사업의 지속 수행에 기여한 사례입니다.

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 기반 수어 기능 연동
Google Play

Case 08

Chowis 진단기 연동 모바일 앱 및 제품화

㈜초위스컴퍼니 / 2013.03 ~ 2020.12

㈜초위스컴퍼니

사례 요약

피부/헤어 진단기와 모바일 앱을 연동하고 제품 판매와 B2B 납품에 필요한 핵심 모바일 개발을 수행한 장기 제품화 사례입니다.

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 설계 경험
Chowis