페퍼는 챗봇이 아니다
페퍼를 "AI 비서 앱"이라고 소개하면 절반은 맞고 절반은 틀리다.
뭐가 다른지 이야기하려면, 페퍼가 우리 가족을 어떻게 아는가부터 시작해야 한다.
우리 가족을 아는 AI — Family Graph와 Family Vault
일반 챗봇은 대화가 끝나면 리셋된다. 다음 대화에서 내가 누군지, 우리 가족이 어떻게 돌아가는지 아무것도 모른다. 매번 zero에서 시작한다.
페퍼는 두 가지를 항상 알고 있다.
Family Graph는 우리 가족의 관계와 권한 구조다. 내가 은수에게 알림을 보낼 수 있다는 것, 은수는 은제에게 reminder만 가능하다는 것을 페퍼는 안다. 단순히 메시지를 처리하는 게 아니라 누가 → 누구에게 → 무엇을 할 수 있는지의 맥락 위에서 작동한다.
Family Vault는 우리 가족의 모든 것을 담아두는 공간이다. 금융 기록, 법적 문서, 은수의 그림들, 가족 사진, 우리가 좋아하는 맛집과 레시피까지. Vault가 쌓일수록 페퍼는 우리 가족을 더 깊이 안다. "미용실 바꿨어, 이제 OO헤어야"라고 말 한마디 하면 다음 예약부터 자동으로 반영된다. 매번 설명하지 않아도 된다.
이게 일반 챗봇과 근본적으로 다른 지점이다. 목표는, 일상 생활에서 Gemini랑 Claude를 열지 않는 것이다. 그리고 물어 보는게 아니라 챙김 받는것이다.
페퍼가 해야 하는 두 가지
이 맥락 위에서 페퍼가 해야 하는 건 두 가지다.
하나, 선제적으로 챙겨준다. 내 이메일, 캘린더, 포트폴리오를 알아서 읽고 아침에 먼저 알려준다. "오늘 은수 학원 픽업 있어요", "어제 포트폴리오 2% 빠졌어요", "답장 못 한 메일 3개 있어요" — 내가 물어보기 전에 먼저. 그리고 정보를 선별해서 준다. 답장 못 한 메일 중에서 실제로 내가 답장 해야되고 액션해야 되는것은 무엇인지.
둘, 내가 해달라는 걸 해준다. "은수한테 3시에 간식 먹으라고 알림 보내줘", "이번 주 가족 일정 정리해줘", "학비 납부 확인해줘" — 자연어로 말하면 처리된다.
너무 이상적인데, 여기서 현실적인 문제가 생긴다.
나는 계속 만들 수 없다
나는 개발자가 아니다. 지금 모든 use case를 알지도 못한다. 가족이 쓰다 보면 새로운 요청이 계속 나올 것이다. 은수가 "페퍼, 내 그림 포트폴리오 사이트에 올려줘"라고 할 수도 있고, 소연이 "이 학원 공지 메일 파싱해줘"라고 할 수도 있다.
그걸 하나하나 내가 개발해서 배포할 수 없다. 능력도 없고 시간도 없다.
그래서 페퍼는 스스로 진화해야 한다. 자가 발전 시스템. 이것이 핵심이다. 내가 instruction만 주면 Claude Code가 다 만들어주는 세상인데. 페퍼도 같은 방식으로 작동해야 할것 같았다.
판단 레이어가 필요하다 — STATE A / B / C
그러면서 부딪힌 질문이 있었다. 챗봇이랑 대화하면, 이게 그냥 답변하면 되는 건지, 뭔가 실행해야 하는 건지, 아예 새로운 기능을 만들어야 하는 건지 — 어떻게 구분하지?
상황은 크게 세 가지로 나뉜다고 생각했다.
첫째, 그냥 답변하면 되는 것. "오늘 날씨 어때?" 같은 거.
둘째, 이미 있는 기능을 실행하면 되는 것. "은수한테 알림 보내줘"처럼 페퍼가 이미 알림 기능을 갖고 있는 경우.
셋째, 아직 없는 기능인데 만들 수는 있는 것. 또는 아예 사람이 개입해야 하는 것.
이 세 가지를 구분하는 판단 레이어가 있어야 한다. 판단에 따라 뒤에서 일어나는 일이 완전히 달라지니까.
그리고 여기서 또 하나의 현실적인 문제가 나왔다. 비용.
AI API는 쓸수록 돈이 나온다. 가족 4명이 매일 쓰는 시스템인데, 모든 요청마다 비싼 모델을 돌리면 감당이 안 된다. 아이들끼리 계속 장난을 칠 수도 있다. "오늘 날씨 어때?" 한 마디에 최고 성능 모델을 쓸 필요가 없다.
그래서 판단 레이어와 비용 구조를 함께 설계하게 됐다. 가벼운 판단은 저렴한 모델로, 진짜 두뇌가 필요한 순간에만 비싼 모델을 쓰는 구조. Gemini와 Claude 두 가지를 섞어서 용도에 맞게 배치하면 된다고 생각했다. 이것도 Claude랑 같이 기획하면서 나온 구조다. 나 혼자선 몰랐을 내용들이다.
결국 이 고민이 STATE A / B / C라는 개념으로 정리됐다.
STATE A — 이미 있는 기능: 요청을 받으면 즉시 실행한다. 저렴한 모델로 의도를 파악하고, 등록된 기능을 바로 돌린다. 비용도 적고 빠르다.
STATE B — 없는 기능을 만든다: 등록된 기능이 없지만 만들 수 있는 경우다. 페퍼가 직접 코드를 생성하고, 격리된 환경에서 검증한 뒤, 시스템에 자동 등록한다. 내가 개발하지 않아도 페퍼가 스스로 자신을 확장한다. 이 단계에서만 비싼 모델(Claude Sonnet)을 쓴다. 진짜 두뇌가 필요한 순간이니까.
STATE C — 사람이 필요하다: 페퍼가 자율로 처리할 수 없는 경우다. 그냥 "못 해요"로 끝내면 안 된다고 생각했다. 가족 입장에서 그러면 신뢰가 깨진다.
은수가 "페퍼, 네이버에서 마라탕 예약해줘"라고 했는데 아직 그 기능이 없다면:
- 은수에게 즉시: "지금은 못 해요. 아빠가 해결하면 알려드릴게요."
- 내 채팅방에 카드 하나가 온다: 뭘 시도했고, 뭐가 막혔고, 해결하려면 뭐가 필요한지
- GitHub에 이슈가 자동으로 생성된다
- 내가 해결하고 배포하면 — 은수에게: "아까 못 했던 거 이제 할 수 있어요. 다시 해볼까요?"
실패가 다음 진화의 입력값이 된다. STATE C는 포기가 아니라 성장의 한 단계다.
Phase 0의 단 하나의 질문
그래서 지금 Phase 0는 기능을 만드는 단계가 아니다. "페퍼의 뇌가 실제로 작동하는가"를 검증하는 단계다. Gmail 연동, 캘린더, 포트폴리오 모니터링은 피처가 아니라 테스트 베드다. 이것들로 STATE A/B/C가 실제로 올바르게 작동하는지 확인한다.
STATE B — 페퍼가 스스로 코드를 짜는 그 순간이, Phase 0의 진짜 골인 지점이다.