spoqa

문제Kotlin Multiplatform (KMP) + Compose Multiplatform (CMP) 이 프로덕션 환경에서 정말 쓸 만한지 의문이 많다.

접근스포카 키친보드 앱을 KMP/CMP 로 마이그레이션. iOS/Android 코드 공유율, 빌드 시간, 디버깅 경험, native 통합 시 마주친 함정까지 솔직 리뷰.

결과부분 영역에서 KMP 가 충분히 production-ready. 단점 영역(특히 iOS 디버깅) 도 명확히 식별.

문제B2B SaaS 디자인에서는 테이블 컬럼 8개·로우 30개 단위의 더미 데이터를 손으로 채우면 디자이너의 시간·체력 비용이 폭발한다. 외부 TF 없이 PD 혼자 해결할 도구가 필요했다.

접근피그마 플러그인 "커틀러리" 를 직접 제작. 텍스트 레이어 이름과 Google Spreadsheets 컬럼명을 매칭하고 Google Drive 이미지를 GCP API 로 연결한다. AI 답변 품질을 위한 룰 문서를 .md 로 관리.

결과매일 2~3시간 × 3일로 PD 혼자 만든 플러그인이 디자인 더미 데이터 작업의 반복 비용을 줄였다. TF 없이도 개인 단위로 도구를 만들 수 있다는 가능성을 보여준다.

문제키친보드 매장 앱에 권한 관리 기능을 추가해야 했지만, 기존 JWT 기반 stateless 인증은 권한 변경을 즉시 반영할 수 없었다. 토큰 탈취 시 서버가 제어할 방법도 없었다.

접근Refresh Token 을 도입해 인증 상태를 서버에서 관리한다. Access Token 의 만료를 짧게 가져가면서도 사용자 재로그인 부담을 줄이고, 권한 변경 시 토큰 재발급으로 즉시 반영. 권한 모델은 RBAC 형태로 매장 단위 권한을 정의한다.

결과인증 / 인가가 서로 분리된 깨끗한 구조로 정착. 보안 위험을 낮추면서 사장-직원 권한 분리 같은 새 기능을 쉽게 얹을 수 있게 됐다.

문제식자재 품목 검색이 DB LIKE 질의로만 동작해 띄어쓰기·맞춤법 차이에 취약했다. "깐마늘" 검색이 "마늘/깐" 으로 저장된 품목을 찾지 못해 점주들이 품목 미취급으로 오해하는 일이 발생.

접근Elasticsearch 를 POC 로 도입. 한국어 analyzer + ngram 기반 필드 구성으로 토크나이징을 정교화하고, DB LIKE 검색과 검색 품질·성능을 정량 비교한다. 점진적 개선 사이클로 운영.

결과검색 한계로 인한 점주 이탈 / 오해를 줄였다. POC 결과를 기준으로 검색 엔진 운영 정책과 품질 지표를 정착시켰다.

문제README 문서와 실제 코드가 어긋나면서 팀원 간 혼란이 생기고, 자동화 도구만으로는 계층 의존성과 클래스 네이밍 같은 구조적 규칙을 잡을 수 없었다.

접근ktlint로 스타일을, SonarQube로 중복·복잡도·보안을 사후 검증한 뒤 Konsist로 계층 의존성과 Entity 속성 규칙을 코드 테스트로 강제한다. 코드 리뷰는 도구가 못 잡는 영역에 집중한다.

결과Konsist 도입 직후 다수의 의존성 위반이 발견됐고, 사소한 스타일 이슈는 자동 처리돼 코드 리뷰가 본질에 집중하게 됐다. 단일 도구가 아닌 조합 전략이 효과적이라는 점을 보여준다.

문제카카오톡으로 들어온 식자재 주문 텍스트의 형식이 매장별로 제각각이고 불규칙해, 조건 분기만으로는 키친보드 주문서로 변환하기 어려웠다.

접근Spring AI 프레임워크로 OpenAI API를 연동해 자유 형식 텍스트를 `name`·`count` 키를 가진 JSON으로 구조화하고, 상품 후보 조회는 Kotlin의 async·awaitAll로 병렬화했다.

결과입력 텍스트로부터 주문서 초안이 자동 생성되고 사용자는 AI 추천 후보에서 정확한 상품만 선택해 확정한다. 유통사의 수작업과 배송 실수가 줄었다.

문제Querydsl이 kapt 의존성과 느린 빌드, 장기 유지보수 부재로 코틀린 코드베이스에서 부담이 되어 새로운 쿼리 빌더가 필요해졌다.

접근Exposed, Ktorm, JOOQ, JPA Criteria API를 비교한 뒤 Kotlin JDSL을 채택한다. Custom Repository 패턴으로 서비스 계층을 건드리지 않고 점진 마이그레이션하며, Helper 클래스와 Custom DSL로 반복 코드를 정리하고 페이징·잠금·fetch join 이슈를 풀어 나간다.

결과컴파일 시간이 82초에서 34초로 약 50% 줄었고 kapt를 제거해 향후 Kotlin 버전 호환 부담을 덜었다. 메타모델 없는 직관적 DSL과 JPQL 호환성 덕에 안정적으로 전환을 마쳤다.

문제2015년에 설계된 Clean Swift 아키텍처가 SwiftUI, 새로운 상태 관리, async/await 같은 현대 iOS 패러다임을 따라가지 못해 신기술 도입이 어려웠다.

접근Clean Swift의 핵심 가치는 유지하면서 CIS(Controller-Interactor-Store) 패턴으로 재설계한다. View 계층을 분리하고 DomainState를 도입했으며, 부수효과는 Worker에 위임해 UI 프레임워크 의존성을 끊었다.

결과UI 없이도 BDD 기반 통합 테스트를 작성할 수 있게 됐고, SwiftUI와 UIKit을 자유롭게 갈아끼울 수 있는 구조를 확보했다.

문제키친보드 안드로이드 앱은 XML 레이아웃·color·drawable 리소스를 오가며 작업해야 했고 RecyclerView 구현이 복잡해 개발 피로가 컸다.

접근선언형 UI인 Jetpack Compose를 도입해 UI 코드를 Kotlin 한 파일에서 작성하고 LazyList로 리스트를 단순화했으며 단방향 데이터 흐름과 MVI 패턴으로 상태 관리를 정리했다.

결과러닝 커브라는 비용은 있었지만 컨텍스트 전환을 줄여 개발 속도와 가독성을 끌어올렸고 향후 UI 변경에도 더 잘 견디는 구조를 확보했다.

문제통합 테스트만으로는 Hibernate Lazy Loading, Flush, TransactionalEventListener 같은 실제 운영 동작을 못 잡아내 배포 후에야 버그가 드러났다.

접근내장 서버로 실제 환경을 재현하고 외부 API는 MockServer로 HTTP 레벨에서 모킹했다. 테스트 헬퍼와 OpenEntityManager Aspect로 데이터·세션 문제를 정리하고 Kotest의 Eventually로 비동기 검증을 도입했다.

결과기존 통합 테스트 코드를 전부 제거하고 기능 테스트만으로 전체 기능을 검증하는 체계를 갖췄고 단위 테스트와 역할 분담도 명확해졌다.

문제스포카 키친보드의 기존 이벤트 로그 체계는 데이터가 부족하고 Figma 시안과 분리돼 있어 디버깅이 어려웠다.

접근구글 시트에 Screen·Variable·Event·Update 시트를 두고 Figma 시안과 로그 명세를 통합 관리한다. Redash로 BigQuery 스키마와 자동 비교해 검증한다.

결과직관적 이벤트명과 통합 문서화, 자동 검증으로 분석·디버깅 효율이 올라가고 팀 간 협업 비용이 줄었다.