SaaS/Insight Paser

Actonix에서 Todit으로 — 포지셔닝 실패를 인정하고 피벗하기 까지

Aidengoldkr 2026. 3. 18. 08:08

시작: inPaser라는 아이디어

처음 이걸 만들겠다고 생각한 건 단순한 질문에서였다.

"문서를 올리면 그냥 할 일 목록이 나오면 안 되나?"

회의록을 읽고 태스크를 뽑고, 메모를 정리하고 일정을 잡는 그 반복 작업이 너무 비효율적으로 느껴졌다. 요약이 아니라 실행. 읽는 게 아니라 움직이는 것. 그 차이가 핵심이라고 생각했다.

그래서 나온 게 inPaser였다. 문서 → 파싱 → 외부 시스템 실행까지 이어지는 인프라 엔진 개념. 근데 솔직히 말하면 그건 너무 큰 그림이었다. 고등학생 혼자서 처음부터 풀 엔진을 만들 수는 없었다. 그래서 MVP가 필요했다. inPaser의 첫 번째 레이어를 증명할 서비스. 그게 Actonix였다.

Actonix: 맞는 제품, 틀린 포지셔닝

Actonix는 이미지나 문서를 올리면 AI가 의도를 추론해서 할 일 목록을 생성해주는 서비스였다.

기술적으로는 꽤 잘 동작했다. Google Cloud Vision OCR과 OpenAI를 분리해서 비용을 최적화했고, AI 응답에 JSON 스키마 검증을 걸어서 파싱 실패 시 과금이 안 되게 막았다. 학교 안내문에 "3/15"처럼 연도가 빠진 날짜가 오면 오늘 기준으로 6개월 초과 미래면 전년도로 추론하는 로직도 있었다. Google Calendar 연동 버튼도 UI에 올라가 있었다 — 실제로는 클릭해도 아무 일이 없었지만.

 

베타 유저도 약 20명 모았다. 근데 문제가 생겼다.

유저들이 Actonix를 "문서 요약 도구"로 인식하고 있었다.

"이거 AI 요약 서비스죠?"라는 질문이 반복됐다. '할 일 생성'이 아니라 '요약'으로 읽히고 있었다. 즉, 제품이 하는 일과 유저가 인식하는 일 사이에 갭이 생긴 것이다.

원인을 뜯어봤다

단순히 "설명을 잘 못했다"는 말로 끝낼 수가 없었다. 구체적으로 뭐가 문제였는지 분석했다.

실패 원인 내용
정보 위계 역전 문서 메타데이터가 결과 최상단. 가장 중요한 Todo가 아래 있었음
추상적 카피 "의도 기반 실행"은 유저한테 와닿지 않는 표현
Calendar 버튼 미작동 실행 자동화를 주장하면서 핵심 버튼이 동작 안 함
브랜드 이름 문제 "Actonix" — 뭘 하는 서비스인지 이름에서 안 읽힘

 

결론은 하나였다. 제품이 실제로 하는 것보다 더 많은 걸 주장하고 있었고, 동시에 그 주장을 뒷받침하는 실행이 빠져 있었다.

포지셔닝 실패의 본질은 항상 이거다. 제품의 실제 능력과 외부에 드러나는 메시지 사이의 간극.

피벗: Todit

리브랜딩을 결정했다.

근데 단순히 이름만 바꾸는 게 아니었다. 포지셔닝 자체를 다시 설계했다.

핵심 메시지 변경:

  • Before: "문서에서 실행 계획을"
  • After: "사진 및 문서만 올리면 바로 Todo 생성"

전자는 무슨 뜻인지 생각해야 한다. 후자는 그냥 읽히는 동사다.

브랜드:
Todit. To-do + do it의 조합. 기능이 이름에 있다. 처음 들었을 때 "아 할 일 관련 서비스구나"가 읽혀야 했다.

결과 페이지도 뜯어고쳤다

정보 위계를 완전히 뒤집었다.

Before: [문서 정보] → [분석 결과] → [Todo]
After:  [Todo + 일정] → [Google Calendar 버튼] → [문서 정보 (접힘)]

사용자가 원하는 건 문서 메타데이터가 아니라 지금 당장 할 일이다. 당연한 말인데 실제로는 반대로 구현해놨었다.

추가된 것들:

  • Todo ↔ 일정 연결 (같은 항목이 양쪽에서 참조됨)
  • Google Calendar 버튼 — 이번엔 실제로 동작함. 할 일의 제목과 마감일을 추출해서 calendar.google.com/calendar/render URL로 인코딩, 클릭 한 번으로 일정 등록
  • 우선순위 기본 정렬
  • 완료 상태 시각 피드백 (취소선 + 투명도)

Calendar가 처음부터 됐어야 할 기능이었다. Actonix에서 가장 먼저 지적받았던 지점이기도 했다.

구조적 변경: 구독 모델로

원래 크레딧 방식을 생각했다. 1회 파싱 = 1크레딧.

근데 한국 PG사 정책을 파고들다가 알게 됐다. 크레딧 선충전 방식은 PG사가 전자화폐로 분류한다. 즉, 단순 결제가 아니라 자산 발행이 돼버리는 것이다. 규제 리스크가 생긴다.

그래서 구독으로 피벗했다.

플랜 가격 주요 기능
Free ₩0 월 20회, gpt-4o-mini, 이미지 분석, 광고 포함
Pro ₩2,900/월 무제한, gpt-4o, PDF 지원, 광고 제거, 상세도 조절, 커스텀 카테고리, 우선순위 자동 할당

 

구독은 사용자 입장에서도 예측 가능한 비용이다. 서비스 입장에서도 MRR 기반의 예측 가능한 수익이다. 크레딧보다 양쪽 다 낫다.

월 사용량은 last_refill_at의 달(Month) 정보를 현재와 비교해서 달이 바뀌면 자동으로 초기화된다. 별도 배치 없이 API 호출 시점에 인라인으로 처리하는 구조다.

기술적으로 뭐가 달라졌나

Actonix에서 Todit으로 넘어오면서 코어 로직(/lib, /api)은 그대로 이전했다.

UI는 의도적으로 버렸다. 기존 UI를 그대로 옮기면 Actonix의 정보 위계 문제가 그대로 따라온다. 처음부터 다시 짜는 게 맞다고 판단했다.

 

기술 스택은 바뀌지 않았다. Next.js 14 App Router, TypeScript, Supabase(DB + Storage), Google Cloud Vision, OpenAI. 달라진 건 구조가 아니라 각 레이어가 하는 역할의 명확성이다.

 

몇 가지 구현 포인트를 정리하면:

 

OCR + LLM 분리 유지

Google Cloud Vision으로 텍스트를 뽑고, OpenAI로 의도를 추론한다. 하나로 합치지 않는 이유는 비용과 정확도 모두 때문이다. OCR은 Vision이 훨씬 싸고 정확하다. LLM은 그 텍스트를 받아서 할 일로 변환하는 데만 집중한다.

 

AI 프롬프트의 5단계 프로토콜

"프로젝트 완료"라는 목표가 들어오면 AI가 스스로 "자료 조사", "초안 작성", "최종 검토"로 쪼갠다. 이게 원자적 분해(Atomic Decomposition)다. 요약이 아니라 실행 단위로 분해하는 것 — 이게 일반 요약 도구와 기술적으로 다른 지점이다. 유저가 선택한 상세도(Brief / Normal / Detailed)에 따라 "가장 필수적인 3~5개만" 또는 "최대한 잘게 쪼개기" 명령어가 동적으로 프롬프트에 추가된다.

 

스키마 검증이 비즈니스 로직

AI 응답은 확률적이다. 타입이 틀리거나 배열이 누락될 수 있다. validateActionPlan이 이걸 잡아서 기본값으로 보정한다. 여기서 실패하면 과금도 안 된다. 스키마 검증이 단순한 방어 코드가 아니라 수익 구조의 일부인 것이다.

 

보안: 경로 샌드박스 + 소유권 검증

클라이언트가 스토리지 경로를 직접 보내는 구조라 서버에서 ${userId}/로 시작하는지 반드시 검증한다. Directory Traversal도 정규식으로 차단. 혼자 만들 때 빠뜨리기 쉬운 부분인데, 상용 서비스라면 이게 없으면 안 된다.

 

임시 파일 자동 제거

분석이 성공하든 에러가 나든, finally 블록에서 업로드 파일을 스토리지에서 즉시 삭제한다. 사용자 이미지가 서버에 남아있지 않는다는 게 개인정보 관점에서 중요한 포인트다.

inPaser와의 관계

Todit이 최종 목적지가 아니라는 걸 처음부터 알고 있었다.

Todit은 inPaser의 1레이어다. 의도 추출 능력을 실제 유저로 검증하는 것.

Actonix의 취약점은 명확했다 — 실행 루프가 불완전했다. 문서 → JSON까지는 되는데, 시스템 통합이 없었다. 그러면 GPT한테 그냥 물어보는 것과 기능적으로 차이가 없어진다.

inPaser는 그 루프를 닫는다. 파싱 → 실행 → 시스템 통합. Google Calendar 연동이 그 첫 번째 훅이다. 다음은 n8n 웹훅, 그 다음은 B2B API 접근. 이게 완성되면 대체 불가능해진다. 일반 AI 도구가 넘볼 수 없는 워크플로 락인이 생긴다.

지금 Todit은 그 엔진을 증명하기 위한 첫 번째 서비스다.

배운 것

포지셔닝 실패는 제품 실패가 아니다.

제품이 실제로 하는 것을 정확히 말하지 못하면, 유저는 그걸 더 단순한 것으로 분류해버린다. Actonix가 할 일 생성기였는데 요약 도구로 읽혔던 것처럼.

 

약속한 기능은 반드시 동작해야 한다.

Calendar 버튼이 UI에 있는데 동작 안 하는 건, 없는 것보다 나쁘다. 유저는 클릭했다가 실망한다. 동작하는 기능 하나가 동작 안 하는 기능 열 개보다 낫다.

 

실행 루프의 완성도가 방어 가능성을 결정한다.

파싱만 하는 서비스는 ChatGPT로 대체된다. 실행까지 이어지는 서비스는 워크플로에 박힌다. 이 차이가 SaaS의 생존을 가른다.

 

한국 시장에서 크레딧 모델은 생각보다 복잡하다.

수익화 설계 전에 PG 정책부터 읽어야 한다. 구독이 단순히 "자연스러운 선택"이 아니라 규제 관점에서 더 안전한 선택이었다.

이게 Actonix에서 Todit으로 오는 과정이었다.

제품은 바뀌지 않았다. 내가 무엇을 만드는지에 대한 이해가 더 명확해진 것이다.

Todit은 현재 운영 중입니다. todit.app