AI가 앱을 만들어준다고요? 진짜 문제는 그 다음이에요 — 개인화 소프트웨어의 공급망

소프트웨어를 ‘만드는’ 비용은 급격히 낮아졌어요. 그런데 정작 바뀌는 건 생산이 아니에요. 소프트웨어 공급망(supply chain) 이 바뀌고 있어요.

기업용 소프트웨어에는 이미 공급망이 있었죠 — 요구사항 → 설계 → 개발 → 배포 → 운영 → 관측. 이 흐름이 지금 개인에게 내려오고 있어요. 개인도 자기 삶을 위한 개인화 소프트웨어를 갖게 되고, 그 소프트웨어가 만들어지고 운영되는 방식 자체가 하나의 공급망이 돼요.

이 글은 그 구조를 두 개의 개념으로 정리해보려는 시도예요.

Platform as Self (PaSelf): 플랫폼이 ‘서비스’가 아니라 나의 운영체제 가 되는 상태
Builder-as-a-Service (BaaS): 그 운영체제를 만들고 유지보수하는 빌더 레이어

1) Platform as Self(PaSelf): 플랫폼이 ‘나’가 되는 순간

PaSelf는 “SNS/툴/앱을 많이 쓴다”는 뜻이 아니에요. 핵심은 이거예요.

내 삶의 의사결정이 플랫폼 안에서 발생하고
내 행동 데이터가 플랫폼 안에서 쌓이고
내 규칙(루틴/상태/취향/금지사항)이 플랫폼 안에서 관리되고
결과적으로 플랫폼이 “나라는 시스템”의 일부가 되는 상태

구체적으로 어떤 모습일까요?

예를 들어, 매달 식비가 예산을 초과하는 사람이 있다고 해요. 기존이라면 가계부 앱을 깔고 수동으로 기록하겠죠. PaSelf에서는 달라요. 결제 데이터가 자동으로 카테고리별로 분류되고, “이번 주 외식이 기준치를 넘었어요”라는 알림이 오고, 다음 주엔 자취 레시피를 추천하는 루틴이 돌아요. 규칙을 한 번 정해두면 시스템이 상태를 추적하고, 피드백을 주고, 행동을 조정해주는 거예요.

운동도 마찬가지예요. 매주 3회 유산소를 목표로 잡았다고 해볼게요.

상태 감지: 이번 주 운동 기록을 보니 화요일 1회만 됐어요. 수면 시간은 평균 5.5시간, 어제 하체 운동 후 피로 지수가 평소보다 높은 상태예요.
규칙 적용: 시스템엔 이런 규칙이 있어요. “수면이 6시간 미만이고 근피로가 높으면, 고강도 운동 대신 저강도 회복 루틴으로 전환한다.”
피드백: 목요일 알림이 왔어요. “오늘 HIIT 예정이었지만, 현재 상태 기준으로 15분 스트레칭 루틴으로 대체할게요. 다음 주 월요일에 HIIT를 재개해요.”

“오늘 운동해야 하는데 피곤하다”는 갈등을 혼자 해소하지 않아도 돼요. 상태를 감지하고, 규칙을 적용하고, 피드백을 받는 과정이 시스템 안에 이미 있으니까요. 이게 상태 기반 자동화예요.

관계 관리도 다르지 않아요. 핵심은 이런 결정들이 더 이상 ‘머리 속’에 흩어져 있지 않고, 상태(state) + 규칙(rule) + 피드백(loop) 으로 구조화된다는 거예요. 이 지점에서 개인화 소프트웨어는 단순한 ‘앱’이 아니라 개인 운영 시스템이 돼요.

기존 생산성 앱과 뭐가 다른가요?

Notion이나 노코드 툴도 ‘나만의 시스템’을 만들 수 있잖아요. 차이는 작동 방향이에요. 기존 앱은 사용자가 도구를 ‘쓰는’ 거예요 — 입력하고, 정리하고, 확인하는 주체가 나. PaSelf는 시스템이 나를 ‘운영’하는 방향으로 작동해요 — 상태를 감지하고, 규칙을 적용하고, 결과를 돌려주는 주체가 시스템이에요. 도구를 넘어서 운영 주체가 전환되는 게 핵심이에요.

경계를 더 명확히 그어볼게요.

라이프로그 앱과의 차이: Apple Health나 Daylio 같은 라이프로그 앱은 ‘기록’이 목적이에요. 데이터가 쌓이지만, 시스템이 규칙을 적용하거나 행동을 유도하지는 않아요. “오늘 운동 30분”을 기록하는 건 라이프로그예요. 그 기록이 “이번 주 패턴이 흔들렸으니 목요일 루틴을 자동 조정한다”로 연결되면 PaSelf예요. 핵심 차이는 데이터가 행동 루프로 연결되는지 여부예요.

노코드/자동화 툴과의 차이: Notion DB로 식비를 집계하거나, Zapier로 트리거-액션을 연결하는 건 ‘도구의 고도화’예요. 노코드는 사용자가 설계한 구조에 데이터를 채우는 것이고, 자동화는 미리 정의한 조건을 실행하는 것이에요. 노코드의 한계는 여기에 있어요 — 구조를 만드는 주체가 여전히 사용자예요. PaSelf는 여기서 한 단계 더 나아가요 — 상태 누적 + 규칙 적용 + 피드백 루프, 이 세 가지가 함께 돌아가야 해요. 그 중 하나나 둘만 있다면 PaSelf와 경계에 있는 거예요.

반례: Notion에서 식비를 자동 합산하는 페이지를 만들었다면? 유용하지만 PaSelf는 아니에요. 집계 결과를 보고 다음 행동을 결정하는 주체가 여전히 사용자거든요. 시스템이 집계 결과를 기반으로 다음 루틴을 직접 조정하는 구조가 갖춰질 때 비로소 PaSelf라고 부를 수 있어요.

2) Builder-as-a-Service(BaaS): 개인화 소프트웨어의 제작/유지보수 계층

PaSelf가 보편화되면 문제가 생겨요. 개인의 운영 시스템은 ‘한 번 만들고 끝’이 아니거든요.

데이터가 쌓이면 구조가 바뀌어야 하고
목표가 바뀌면 지표가 바뀌어야 하고
도구가 늘면 통합이 필요하고
실수가 나면 복구가 필요하고
무엇보다 “안 깨지게” 운영해야 해요

이건 1인 개발자가 사이드프로젝트를 만든 뒤 맞닥뜨리는 문제와 똑같아요. 만드는 건 됐는데, 유지하는 게 더 어려워요.

이때 등장하는 레이어가 BaaS예요. 개인의 요구를 듣고(요구사항), 모델로 만들고(설계), 기능을 구현하고(개발), 적용하고(배포), 고장 나면 복구하고(운영), 더 나아지게 학습시키는(개선) — 개인화 소프트웨어의 공급망을 대신 운영해주는 역할이에요.

여기서 중요한 건 “AI가 다 해준다”가 아니에요. BaaS의 본질은 책임의 경계를 만드는 거예요.

무엇이 ‘정의’이고 무엇이 ‘가정’인지
무엇이 ‘자동화’이고 무엇이 ‘승인’인지
무엇이 ‘실험’이고 무엇이 ‘정책’인지

개인의 삶에 들어오는 소프트웨어는, 실수하면 비용이 커요. 자동이체가 잘못 걸리거나, 운동 루틴이 부상을 유발하거나, 학습 계획이 시험 범위를 빗나가면 되돌리기 어렵죠. AI 자동화만으로는 안전/해석/지속이 보장되지 않아요. 그래서 공급망에는 반드시 품질 게이트 — 자동 실행과 승인 실행의 경계, 되돌리기 플로우 — 가 필요해요.

3) 개인화 소프트웨어 공급망, 기업과 뭐가 다를까?

기업 소프트웨어 공급망은 익숙해요. 하지만 개인화 공급망은 성격이 달라요.

(1) 요구사항은 “기능”보다 “상태”에서 시작해요

개인 운영 시스템의 요구사항은 기업과 달라요. 기업은 기능 요구가 많아요. 개인은 보통 이렇게 말하죠.

“요즘 너무 산만해요”
“돈이 어디서 새는지 모르겠어요”
“운동을 하긴 하는데 늘 제자리예요”

이건 기능 요구가 아니라 상태 진단이에요. 그래서 개인화 소프트웨어는 “무엇을 만들까요?”보다 “지금 상태를 어떻게 모델링할까요?”가 먼저예요.

(2) 배포는 ‘릴리즈’가 아니라 ‘루틴에 편입’이에요

개인에게 배포는 버전 번호가 아니에요. 내 루틴에 들어오느냐가 배포예요.

오늘부터 쓰는가?
일주일 후에도 남아있는가?
실패했을 때 다시 돌아오는가?

그래서 개인화 소프트웨어의 진짜 배포는 온보딩 + 습관화 + 되돌림(rollback) 까지 포함해요.

(3) 관측은 “성능”보다 “행동 변화”에 맞춰져요

기업은 latency, error rate 같은 운영 지표를 봐요. 개인은 이런 걸 봐요.

내가 덜 후회하게 됐는지
반복이 더 쉬워졌는지
선택이 더 빨라졌는지

관측 대상이 ‘시스템’이 아니라 ‘나’예요. 그래서 지표 설계가 제품 설계만큼 중요해요. 그리고 이 관측 결과는 곧 품질 게이트의 입력이 돼요 — “이 변경이 정말 나를 더 낫게 만들었는가?”를 판단하는 기준이 되니까요.

4) BaaS가 해결해야 하는 세 가지: 안전 / 해석 / 지속

개인화 소프트웨어가 커질수록, BaaS는 세 가지를 책임져야 해요.

안전(Safety)

개인정보, 권한, 실수의 영향 범위를 통제
자동 실행 vs 승인 실행의 경계를 명확히 — 이것이 곧 품질 게이트예요
되돌리기/복구 플로우를 기본 내장

해석(Interpretation)

데이터가 늘수록 “의미”가 필요해요
취향/상태/목표가 바뀌는 걸 감지해야 해요
모델은 기능보다 해석 프레임에 가까워져요

지속(Sustainability)

한 번 잘 되는 것보다 계속 굴러가게 만드는 운영이 어려워요
그래서 공급망의 비용 구조 — 누가, 얼마나, 어떤 주기로 유지하는가 — 가 핵심이에요

5) 정리

공급망이 기업에서 개인으로 내려오고 있어요. PaSelf는 그 종착점이고, BaaS는 그 공급망을 굴리는 레이어예요.

앞으로는 “어떤 앱을 쓰냐”가 아니라, “내 운영 시스템이 어떤 공급망으로 업데이트되느냐” 가 경쟁력이 될 거예요.

다음 글 예고: 개인화 소프트웨어에서 ‘권한/승인’ 설계는 어떻게 해야 할까요? BaaS가 제품이 되려면 ‘표준 산출물’은 어떤 형태여야 할까요? 다음 글에서 이어갈게요.