복잡한 아이디어를 작동하는 첫 제품으로.

공정에서 쌓이는 두께 데이터를, 현장이 실제로 판단할 수 있는 화면으로 바꾸는 일이었다.

Situation

PLC에서 저장된 시계열 데이터와 기존 ERP 흐름을 함께 다뤄야 했다.

Constraint

구버전 MSSQL, Machbase, 대용량 그래프 조회와 갱신이 한 경로에 얽혀 있었다.

Decision

Elixir/Phoenix와 ODBC로 데이터 접근 계층을 구성하고, 사전 생성 응답·SSR·uPlot로 렌더링 부담을 나눴다.

Result

중앙값 대비 두께 편차를 색으로 읽을 수 있는 모니터링 흐름으로 연결했다.

인지 선별의 원천 응답이 분석을 거쳐 운영자가 확인하는 결과로 남아야 했다.

Situation

설문과 네 가지 인지 과제의 원천 데이터를 수집하고 분석해야 했다.

Constraint

분석 작업은 API 요청과 분리해야 했지만, 도메인 계약은 일관되어야 했다.

Decision

원천 데이터를 먼저 기록한 뒤 serverless worker가 지표를 계산하고 API가 결과를 제공하도록 나눴다.

Result

수집부터 분석 결과와 관리자 조회까지 이어지는 백엔드 흐름을 구성했다.

불확실한 최적화 아이디어를 먼저 볼 수 있게 만들고, 반복 가능한 SaaS 구조로 키우는 과정이었다.

Situation

산업 공정 최적화 솔루션을 시장 검증용 MVP에서 시작해야 했다.

Constraint

모델 학습, 데이터 업로드, 인증, 배포, 고객별 요구가 동시에 커졌다.

Decision

MVP 이후 인프라와 서비스 경계를 확장하고, 반복 요구는 Custom Template 구조로 전환했다.

Result

빠른 검증 단계와 장기 운영 단계가 다른 구조를 가질 수 있다는 기준을 남겼다.

이미 서비스 중인 제품을, 이후의 기능과 운영을 감당할 수 있는 구조로 다시 정리해야 했다.

Situation

인지평가, 리포트, 결제, 실시간 기능이 하나의 소비자 플랫폼에 연결되어 있었다.

Constraint

인증·결제·게임·실시간 세션과 Kubernetes 운영 제약을 함께 다뤄야 했다.

Decision

서비스 경계를 나누고, 보안·결제 정책·다중 pod 세션·배포 조건을 각각의 책임으로 정리했다.

Result

사용자 경험과 백엔드, 배포 구조가 함께 변경 가능한 서비스 형태로 이어졌다.

의료진, 관리자, 파트너, 사용자처럼 서로 다른 역할이 같은 운영 흐름 안에서 만나야 했다.

Situation

처방, 환자, 리포트, 파트너 관리, ERP 연동과 여러 웹 앱이 함께 존재했다.

Constraint

도메인별 요구는 다르지만 세션, 오류, 데이터 표시와 운영 추적은 일관되어야 했다.

Decision

백엔드의 연동·감사·생명주기 관심사를 분리하고, 프론트엔드는 공유 UI·API·리포트 경계로 묶었다.

Result

역할별 경험을 막지 않으면서도 유지 가능한 제품·운영 구조를 만들었다.