가족여행 · 개인용 소프트웨어
Situational Software
시장규모 3명, 제품수명 6일, 목표 리텐션 0%
가족여행을 앞두고 일정 앱을 하나 만들었다.
예쁜 여행계획표를 만들고 싶었던 건 아니다.
아기와 함께 움직이면 여행의 난이도는 방문할 장소의 수보다, 제때 확인해야 하는 정보의 수에서 올라간다.
항공권은 이메일에 있고, 숙소 예약은 예약 앱에 있다. 렌터카 픽업 안내는 문자로 왔고, 공항 발렛파킹 동선은 웹페이지에 있다. 준비물은 메모장에 있고, 날씨와 이동시간은 그때마다 다시 찾아야 한다.
정보가 없는 것은 아니다.
문제는 그 정보들이 지금 해야 할 행동으로 정리되어 있지 않다는 것이다.
평소라면 화면을 몇 번 넘기면 그만이다.
하지만 아기, 유모차, 캐리어를 동시에 챙기면서 다음 목적지를 찾아야 하는 순간에는 검색 한 번도 일이다.
그래서 현재 시간을 기준으로 지금 일정과 다음 일정을 보여주고, 날씨, 교통, 예약정보, 준비물을 한 화면에 모았다.
체크한 내용은 새로고침해도 남게 했다. 발렛파킹처럼 현장에서 헷갈릴 정보는 행동 순서대로 다시 정리했다.
가족여행을 위한 작은 조종석을 만든 셈이다.
기술스택은 Next.js, React, TypeScript, Tailwind CSS, Open-Meteo, Vercel, localStorage, Vitest, Playwright.
근데 중요한가?
딸깍했는데 ㅋㅋ
“지금 일정이 가장 잘 보이게 해줘.”
“비가 오면 바로 알 수 있게 해줘.”
“발렛파킹 동선을 단계별로 넣어줘.”
“체크한 내용은 새로고침해도 남겨둬.”
대체로 이렇게 시켰다.
물론 완전히 딸깍은 아니다.
무엇이 필요한지 정하고, 결과를 확인하고, 이상한 부분을 찾아 계속 수정했다.
노동이 사라졌다기보다 노동의 중심이 코드를 작성하는 일에서 상황을 관찰하고 판단하는 일로 옮겨갔다.
최악의 SaaS, 완벽한 도구
이 앱의 사용자는 우리 가족 세 명이다.
제품수명은 여행하는 6일이다.
결제고객은 없고, 여행이 끝나면 아무도 다시 들어오지 않을 것이다.
시장규모 3명. 제품수명 6일. 목표 리텐션 0%.
SaaS로 보면 처참하다.
그런데 여행이 끝난 뒤에도 계속 사용하고 있다면, 오히려 제품 정의를 잘못한 것이다.
이 앱은 오래 살아남기 위해 만든 것이 아니다.
발렛파킹 입구를 한 번 덜 헤매고, 아기 준비물을 하나 덜 빼먹고, 예약정보를 찾느라 가족을 길바닥에 세워두는 일을 한 번만 줄여도 역할을 다한다.
AI가 바꾸는 것은 단순히 코딩의 난이도가 아니다.
무엇이 소프트웨어가 될 수 있는지의 기준 자체를 낮추고 있다.
예전에는 너무 작고, 너무 개인적이고, 너무 잠깐이라 그냥 참고 살았던 문제들이 있었다.
이제는 이번 주 우리 가족만 겪는 문제도 소프트웨어가 된다.
Situational Software
나는 이런 도구를 Situational Software라고 부르기로 했다. 레오폴드 아셴브레너의 『Situational Awareness』를 기리며 붙인 이름이다. 다만 특정한 사회적 집단과 맥락을 위한 소프트웨어라는 발상 자체는 클레이 셔키가 2004년 발표한 「Situated Software」까지 거슬러 올라간다.[1]
“This is software designed in and for a particular social situation or context.” — Clay Shirky, “Situated Software”[1]
다만 2026년의 Situational Software는 셔키가 보았던 세계에서 한 걸음 더 나아간다.
그때는 특정한 집단의 사람이 직접 자신들을 위한 소프트웨어를 만들었다.
앞으로는 에이전트가 개인의 맥락을 읽고, 상황이 발생할 때마다 필요한 소프트웨어를 생성할 수 있다.
여행할 때 만들고, 이사할 때 만들고, 출산을 준비할 때 만들고, 정부지원사업을 제출하는 2주 동안 만든다.
특정한 투자 이벤트가 끝날 때까지만 사용할 수도 있다.
목적이 끝나면 버린다.
Situational Software의 성과는 MAU나 리텐션으로 측정되지 않는다.
몇 번의 검색을 줄였는가. 몇 번의 질문을 없앴는가. 몇 번의 실수를 막았는가. 몇 번의 판단을 하지 않아도 되게 했는가.
일반적인 소프트웨어가 Product-Market Fit을 찾는다면, Situational Software는 그 상황에 정확히 들어맞기만 하면 된다.
이것도 과도기일 것이다
지금은 내가 먼저 불편을 발견해야 한다.
정보를 모으고, 필요한 화면을 생각하고, AI에게 기능을 설명한 뒤 결과를 확인해야 한다.
그런데 이것조차 과도기일 것 같다.
아셴브레너가 제시한 AI 연구 자동화와 재귀적 자기개선의 시나리오가 현실화한다면, 문제를 발견하고 전용 앱을 만드는 과정까지 에이전트가 흡수할지도 모른다.[2]
에이전트가 이메일에서 항공권과 예약정보를 찾는다.
캘린더에서 일정을 읽고, 지도와 날씨를 확인하고, 우리 가족의 생활패턴과 지난 여행의 실수까지 기억한다.
그리고 나에게 어떤 앱을 만들지 묻지 않는다.
필요한 순간에 필요한 화면만 잠깐 꺼내준다.
“비가 오니 유모차 커버를 챙기세요.”
“지금 출발해야 예약시간에 맞습니다.”
“아기가 늦게 잠들었으니 다음 일정을 40분 미루는 편이 좋습니다.”
“차량은 아빠가 먼저 찾고, 가족은 도착층에서 기다리는 편이 빠릅니다.”
그 단계에서는 여행 앱, 일정 앱, 날씨 앱이 따로 존재하지 않을 수도 있다.
지금은 내가 앱을 호출한다.
다음에는 에이전트가 앱을 만든다.
그다음에는 상황이 소프트웨어를 호출한다.
맥락이 소스코드가 된다
그때 소프트웨어의 원본은 코드가 아닐 것이다.
우리 가족은 몇 시에 움직이기 어려운지, 어떤 준비물을 자주 놓치는지, 아기와 이동할 때 얼마의 여유시간이 필요한지, 어떤 일정은 포기해도 되는지에 대한 맥락이 원본이 된다.
맥락이 소스코드가 되고, 에이전트가 그것을 컴파일해 그 순간 필요한 화면과 행동을 만든다.
앱은 잠깐 렌더링되었다가 사라지는 결과물일 뿐이다.
다음 여행에서 재사용할 것도 코드가 아니다.
우리 가족이 어떻게 움직이고, 무엇을 자주 놓치며, 어떤 판단을 귀찮아하는지에 대한 가족 운영모델이다.
소프트웨어는 일회용이 되고, 맥락은 계속 쌓인다.
그렇다면 앞으로 가장 중요한 자산은 앱이 아니라, 나를 이해하고 상황마다 필요한 도구를 생성해주는 에이전트일지도 모른다.
누가 좀 빨리 만들어줬으면 좋겠다.
여행 앱 딸깍하는 것도 벌써 귀찮다.
다만 그 에이전트가 제대로 작동하려면 내 이메일, 일정, 위치, 결제, 건강정보와 가족의 생활패턴까지 알아야 한다.
그때 우리가 선택하게 될 것은 어떤 앱이 아닐 것이다.
우리 삶의 맥락을 누구에게 맡길 것인가.
그리고 그 에이전트의 주인은 정말 우리일까?
참고 자료
[1] Clay Shirky, “Situated Software,” March 30, 2004.
https://shirky.com/essays/situated-software/
[2] Leopold Aschenbrenner, “From AGI to Superintelligence: the Intelligence Explosion,” Situational Awareness: The Decade Ahead, June 2024.
https://situational-awareness.ai/from-agi-to-superintelligence/