앱에 AI를 적용하기 - 1

기능 - 컴패니언

첫번째 이야기 - 복잡성

앱을 깔고 이틀 만에 삭제한 경험이 있을 것이다.

사용법을 몰라서가 아니다. 기능이 많아서가 아니다.

뭘 먼저 해야 할지 몰라서.

Odyssey를 처음 공개했을 때, 테스터 20여 명이 사용해봤다. 프로젝트 기능이 좋다, 루틴이 편하다, 공유 흐름이 신선하다는 피드백이 돌아왔다. 그리고 한 가지, 예외 없이 전원이 같은 말을 했다.

"기능이 많아서 처음에 복잡해요."

100%. 단 한 명도 빠지지 않았다.

기능이 많은 게 문제가 아니었다. 일상을 제대로 다루려면 기능이 많아질 수밖에 없다. 그게 현실이다. 문제는 그 기능들을 사용자 앞에 그대로 꺼내놓는 방식이었다.

그래서 나는 컴패니언을 두 가지 축으로 설계했다.

복잡성을 해결하는 레이어

일상을 운영해주는 비서

이 글은 그 두 이야기를 한 번에 꺼내 보려는 시도다. 그리고 다음 글들에서, 내가 이 두 문제를 어떻게 바라봤고 어떤 방식으로 풀어가고 있는지를 순서대로 공개하려고 한다.

그런데 한 가지 아이러니한 사실이 있다.

컴패니언은 이 앱에서 가장 먼저 구상한 기능이지만, 가장 마지막에 만들고 있는 기능이다.

두번째 이야기 - 가장 먼저 생각했지만, 가장 늦게 만든 이유

처음 이 앱의 아이디어를 꺼냈을 때 이야기다.

"일상을 운영하는 앱을 만들고 싶다"는 계획을 누군가에게 들려줬다. 그 자리에서 돌아온 반응이 있었다.

"그걸 같이 도와주는 존재가 있으면 어떨까요? 뭔가 서포트해주는 게."

좋은 아이디어였다. 사실 나도 이미 비슷한 그림을 머릿속에 그리고 있었다. AI를 붙이면 될 것 같았다. 기술적으로도 가능한 시대였고. 그런데 멈췄다.

AI를 넣으려면 먼저 질문에 답해야 했다.

일상이 무엇인가?

어떤 기능을 만들어야 하는가?

그 AI가 사용자에게 정확히 무엇을 해줘야 하는가?

이걸 모르는 채로 AI를 붙이면, 그건 그냥 채팅창이다. ChatGPT를 쓰는 것과 다를 게 없다. AI는 도구가 아니라 경험이어야 했고, 경험을 설계하려면 먼저 기능과 흐름이 존재해야 했다.

그래서 결정했다. 컴패니언은 나중에. 일상을 먼저 정의하고, 기능을 먼저 만들고, AI가 무엇을 해줘야 하는지가 명확해진 뒤에 넣자.

그렇게 할 일, 루틴, 메모, 프로젝트, 타임라인, 스냅샷, 피드가 먼저 만들어졌다. 기능이 갖춰졌고, 테스터들이 썼고, 피드백이 쌓였다. 그제서야 질문에 답할 수 있게 됐다.

AI가 사용자에게 무엇을 해줘야 하는가.

복잡성을 해결하는 레이어

컴패니언이 생성해준 프로젝트

할 일, 루틴, 메모, 프로젝트, 캘린더, 타임라인, 스냅샷, 피드.

일상을 다루는 앱이 갖춰야 할 도구들이다.

그런데 이걸 사용자 앞에 전부 꺼내놓으면 어떻게 될까.

처음 앱을 열면, 선택지가 너무 많다. 할 일을 쓰려다 루틴이 눈에 들어온다. 루틴이 뭔지 확인하다가 프로젝트가 보인다. 프로젝트를 눌러보다가 어느새 뭘 하러 들어왔는지를 잊는다. 그리고 앱을 닫는다.

이건 사용자의 문제가 아니다. 통합을 설계한 사람의 문제다.

기능을 하나로 모으는 것과, 그 기능을 사람이 자연스럽게 쓰게 만드는 것은 전혀 다른 문제다. 그리고 그 간극이 정확히 "올인원 앱이 항상 실패한 이유"다.

기능을 통합하는 것만으로는 "일상의 OS"가 되지 않는다.

통합의 복잡성을 흡수하는 레이어가 필요하다.

컴패니언은 그 레이어다. 사용자에게 기능을 더 보여주는 게 아니라, 기능을 덜 보이게 만들고도 목표를 달성하게 하는 레이어. "매일 운동하고 싶어"라고 말하면 루틴이 생성된다. "내일 여행 계획 잡아줘"라고 말하면 프로젝트와 할 일과 지도가 엮인다. 사용자는 어떤 기능을 써야 하는지 몰라도 된다.

일상을 운영해주는 비서

항목을 생성하는 과정

그런데 복잡성을 숨기는 것만으로는 충분하지 않다. 왜냐하면, 일상은 구조가 아니라 지속이기 때문이다.

모두가 안다. 운동이 좋다는 것을. 기록이 도움이 된다는 것을. 회고가 중요하다는 것을. 그런데도 못 한다.

정보가 없어서가 아니다. 의지가 없어서도 아니다. 매번 스스로 챙겨야 하는 구조이기 때문이다.

비서가 있는 사람은 다르다. 비서는 지식을 말해주는 존재가 아니다. 오늘 일정을 먼저 정리해두고, 빠진 것이 있으면 알려주고, 적절한 타이밍에 말을 걸어주는 존재다. 사용자는 생각하는 일에만 집중하면 된다.

컴패니언도 그렇게 움직여야 한다고 생각했다.

앱을 열면 먼저 말을 건다. "오늘 루틴 중에 아직 시작 안 한 게 있어요." 특정 시간이 되면 서버에서 알림을 보낸다. "어제 계획했던 거, 오늘도 이어갈까요?" 대화를 통해 목표를 잡으면 항목을 직접 만들고, 알림을 예약하고, 다음에 확인하러 다시 찾아온다.

이게 챗봇과 컴패니언의 차이다.

챗봇은 물어야 답한다. 컴패니언은 먼저 찾아와서 실행한다.

다음 글들에서 다룰 것

이 글에서는 두 축의 방향만 꺼냈다. 다음 글들에서는 각각을 더 깊이 들어갈 예정이다.

복잡성을 어떻게 분해했는가 — 기능이 아니라 목표로 설계하는 방식

비서처럼 동작하려면 무엇이 필요한가 — 타이밍 설계와 능동성의 구조

어떻게 실제 실행으로 이어지는가 — 항목 생성, 알림 예약, 흐름 오케스트레이션

왜 다중 컴패니언인가 — 하나의 AI가 아니라 여러 역할로 분리된 이유

마무리

컴패니언은 아직 개발 중이다.

사실 그게 이 연재를 쓰는 이유이기도 하다. 완성된 것을 공개하는 게 아니라, 만들어가는 과정을 같이 보는 것. 어떤 문제를 마주쳤고, 어떻게 풀려고 했는지.

조만간 업데이트로 실제 앱 안에서 만나게 될 것이다. 그때쯤 이 글들이 맥락이 되면 좋겠다.