스포카

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

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

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

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

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

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

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

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

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

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

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

식자재 유통사–매장 간 청구/수납은 일반 공과금과 달리 금액 불일치, 미납금 추적, 청구 없는 수납 같은 유연한 처리가 필요했다. 또한 Sendbird API의 초당 5개 제한을 넘는 메시지 발송도 풀어야 했다.

스포카에 입사한 신입 백엔드 개발자가 재택 환경에서 성과 측정·팀 관계 형성·질문 타이밍 같은 시니어와의 협업 마찰을 겪으며 어떤 습관이 1년차에 효과적인지 정리할 필요가 있었다.

Kotlin으로 JPA Entity를 만들 때 Java 패턴을 그대로 따르다 보면 mutable property 남용, data class 오용, lateinit 남발 같은 설계 문제가 생긴다.

매장·거래처·관리자가 동시에 같은 주문서를 수정하면 의도치 않은 덮어쓰기와 데이터 정합성 문제가 발생한다.

운영 서비스의 긴급 이슈와 계획된 작업을 동시에 다뤄야 하는 팀에서 협업과 진행 가시성을 어떻게 확보할지가 과제였다.

도도카트 모바일 앱의 리그레션 테스트가 수작업이라 애자일 사이클이 느려지고, 자동화의 효과와 한계도 불명확했다.

2년 운영된 키친보드 Android 앱이 빌드 경고 30~40개, 슈퍼 클래스 비대화, 의존성 관리 미흡으로 유지보수가 어려워졌다.

Python 기반 키친보드 서버가 동적 타입으로 유지보수가 어렵고, 사내 Python 전문가가 부족해 신규 팀원 온보딩도 지연됐다.