socar

문제사내 디자인 시스템 v1 의 한계 (확장성, 버전 관리, 빌드 속도) 가 누적되며 v2 가 필요해졌다.

접근쏘카 디자인 시스템 2.0 의 기술 측면. 토큰 / 컴포넌트 구조, 빌드 / 배포 파이프라인, 버전 관리 전략을 새로 설계.

결과새 컴포넌트 추가 / 마이그레이션 속도 개선. 기술 측면에서 "굴러가는" 디자인 시스템 정착.

문제디자인 시스템은 기술만 잘 만들어도 운영 거버넌스가 없으면 점차 사용 빈도가 줄고 "디자인 빚" 이 쌓인다.

접근쏘카 디자인 시스템 2.0 의 시스템 측면 — 오너십 모델, 기여 프로세스, 우선순위 결정 framework, 변경 알림 체계.

결과디자인 시스템이 사내 표준으로 자리잡고, 디자이너 / 개발자 협업 비용이 줄었다.

문제6년 누적된 레거시 코드를 새 기능 개발 중에 어떻게 점진적으로 개선하나.

접근쏘카존 관리 시스템의 레거시 개선 3편. 우선순위 framework, strangler fig 패턴, 단계별 마이그레이션 전략까지.

결과새 기능 개발 속도를 유지하면서 레거시 부담 점진 해소. 같은 함정에 빠진 팀에 참고 자료.

문제Node.js 컨테이너가 SIGTERM 을 받았을 때 in-flight 요청을 끝내지 않고 죽으면 사용자에게 5xx 가 보인다.

접근쏘카가 graceful shutdown 을 제대로 구현 — SIGTERM 핸들러로 새 요청 거부 + 진행 중 요청 완료 대기 + DB 연결 정리. K8s preStop hook 과 readiness probe 를 연동.

결과배포 / 스케일 다운 시 사용자 영향 없이 안전한 종료. Node.js / K8s 운영의 기본기 정리.

문제쏘카 / 일레클 / 따릉이 앱은 차량·자전거 단말과 블루투스로 직접 통신해 잠금·해제·반납을 수행한다. Android · iOS 플랫폼이 제공하는 블루투스 API 는 파편화돼 있어 서비스 도메인 요구를 그대로 표현하기 어렵다.

접근플랫폼 블루투스 API 위에 "쏘카프레임 블루투스 모듈" 을 만들어 하드웨어 맥락을 응집된 도메인 모델로 추상화. DeviceX 의 식별·통신 규격·수행 가능 동작을 하나의 단위로 다루고 서버 통신 fallback 까지 함께 다룬다.

결과쏘카 / 일레클 / 따릉이 피쳐가 같은 블루투스 모듈을 공유한다. 플랫폼별 차이를 도메인 계층에서 흡수해 모바일 개발자가 비즈니스 로직에 집중할 수 있다.

문제쏘카는 2019년 앱 코드를 새로 만드는 개편을 단행했다. 변화가 잦은 모바일 환경에서 생산성을 지속적으로 끌어올리려면 개발자 경험(DX) 자체가 시스템 자산이 되어야 했다.

접근Android / iOS 네이티브 위에 동일한 추상화를 제공하는 "쏘카프레임" 앱 프레임워크를 구축. 라이브러리·예외 처리·코딩 컨벤션을 규격화해 코드 일관성을 확보하고 선택의 인지 비용을 줄인다.

결과잉여 시간을 생산성 재투자로 돌리는 선순환을 만든다. 프레임워크가 사고 방식을 가이드해 한 사람이 짠 듯한 일관성과 실수 방지를 동시에 달성한다.

문제turborepo 기반 monorepo 에 30+ Next.js 앱이 공존하면서 main 머지마다 전체 빌드가 트리거된다. 캐시 미스 시 20분 이상, 동시 워크플로우면 30분 이상 대기로 CI 가 강제 종료되는 일이 반복됐다.

접근Runner 사양 상향, Matrix 기반 병렬 빌드, Turborepo 원격 캐시 + paths-filter 정교화, 빌드 / 검증 단계 분리 네 가지를 함께 적용. 각 전략의 효과를 정량적으로 측정한다.

결과CI 시간 단축과 신뢰성 개선을 동시에 달성. monorepo 의 변경 빈도가 늘어도 빌드 병목이 배포 속도를 잡지 않도록 만들었다.

문제QA 가 외주 인력 기반 수동 테스트에 의존하면서 리소스 소모와 실행 속도 한계가 컸다. 자동화 도입을 시도했지만 도구 선택과 환경 구축에서 시행착오가 이어졌다.

접근UI 의존도가 낮은 API 자동화부터 시작. 처음엔 Jenkins + Postman + Slack 으로 구축했다가 인프라 관리 부담을 줄이기 위해 GitHub Actions 같은 매니지드 환경으로 전환한다. Zephyr 와 연동해 테스트 케이스 관리 일원화.

결과작고 안정적인 자동화 단위부터 잡아 점진 확장. 실패 사례 자체를 자산화해 QA 자동화 도입의 의사결정 체크포인트를 정리했다.

문제Kinesis Data Stream + Firehose 기반 로그 파이프라인이 S3/GCS 중복 저장, 1~2시간 배치 지연, 스키마 변경 추적 부재로 비효율적이었다.

접근MSK(Managed Streaming for Apache Kafka) + 커스텀 Python Consumer로 전환하고 Protobuf + Buf 기반 Schema Registry로 스키마 관리를 자동화한다. GCS를 SSoT로 두고 BigQuery 외부 테이블로 적재한다.

결과데이터 신선도가 1~2시간에서 약 3분 수준으로 줄었고 수기 스키마 작업이 사라졌다. 단일 장애점이 제거되어 선택적 로그 적재가 가능해졌다.

문제수만 대 차량의 세차 운영이 오염 여부만 보고 결정되어 비/눈 오는 날에도 불필요한 세차 요청이 발생했다.

접근기상청 ASOS 관측소 데이터를 차량 위치 반경 32km 내에서 매칭하고, 시간당 강우 3mm 이상 또는 적설 1cm 이상이면 세차 보류 규칙을 적용한다. 예보와 관측치를 시뮬레이션으로 검증한다.

결과1년 이상 운영하며 세차 요청이 줄었고 강수 종료 후 요청 몰림도 없었다. 직관적 가설을 데이터로 정량 검증해 비용 절감으로 연결한 사례다.