[Tokit] Day 2 기획서 정리와 발표

4월 21일에는 Tokit_기획서_v2.pptx를 바탕으로 프로젝트 내용을 정리해서 발표했다. 전날까지는 방향을 다시 잡는 데 가까웠다면, 오늘은 그 방향을 다른 사람에게 설명할 수 있는 문서로 옮기는 일이 중심이었다.

이번 발표 자료에서 가장 중요했던 건 Tokit을 단순 프롬프트 압축기가 아니라, 입력, 출력, 세션 상태를 함께 다루는 LLM 작업 흐름 최적화 도구로 설명한 점이었다.

오늘 발표에서 정리한 핵심

발표 자료에서 먼저 잡은 것은 문제 정의였다.

• LLM으로 개발할 때 불필요한 토큰 때문에 비용과 응답 길이가 계속 늘어난다
• 세션이 길어질수록 중복 컨텍스트가 누적되고 효율이 떨어진다
• 긴 출력과 반복 설명 때문에 실제 개발 흐름이 자꾸 끊긴다

그리고 원인도 세 가지로 정리했다.

• 입력 프롬프트에 중복 정보가 많이 들어간다
• 모델이 필요 이상으로 길게 답하는 경향이 있다
• 세션 상태 관리가 약해서 이미 전달한 내용을 반복해서 보내게 된다

그래서 해결 방향도 비교적 명확하게 잡았다.

• 입력은 다시 정리해서 불필요한 컨텍스트를 덜어낸다
• 한국어 요청은 더 짧은 영어 프롬프트로 컴파일한다
• 출력은 다음 단계에 필요한 핵심 정보 위주로 압축한다
• 세션 상태를 관리해서 반복 전달 자체를 줄인다

이렇게 정리하고 보니 Tokit을 설명하는 문장도 조금 더 단단해졌다. “프롬프트를 잘 바꾸는 도구”보다 “개발 작업 전체에서 낭비를 줄이는 도구”라고 말하는 편이 훨씬 맞았다.

누가 쓰는지도 더 구체화했다

오늘 자료에는 페르소나와 유저맵도 넣었다. Tokit이 누구에게 필요한지 더 분명하게 보여줘야 했기 때문이다.

정리한 대상은 크게 세 쪽이었다.

• 개인 개발자: 적은 크레딧으로 더 많은 작업을 하고 싶은 사람
• 테크 매니저: 팀 전체의 AI 사용량과 예산을 관리해야 하는 사람
• 환경에 민감한 개발자: OS나 권한 문제 때문에 재시도가 자주 생기는 사람

이렇게 나누고 나니 Tokit의 가치도 조금 더 또렷해졌다.

• 개인에게는 비용 부담을 줄여주는 도구가 되고
• 팀에는 프롬프트 사용 편차를 줄여주는 기준이 되고
• 환경 이슈가 많은 사람에게는 재시도와 충돌을 줄여주는 안전장치가 된다

전날에는 차별점을 주로 기술 구조에서 찾았다면, 오늘은 그것을 실제로 쓰는 사람이 겪는 문제와 연결해서 설명할 수 있게 됐다.

통계와 근거를 붙이면서 발표 문장이 정리됐다

기획서에는 단순한 아이디어 설명만 넣지 않고, 왜 이런 문제가 실제로 의미가 있는지도 같이 붙였다.

발표에서 쓴 근거는 대략 이런 흐름이었다.

• 미국 기업의 AI 유료 도입률이 빠르게 올라가고 있다
• 주류 AI 챗봇 시장은 소수 모델 중심으로 굳어져 있다
• 한국어는 영어보다 토큰 소모가 더 크다
• 긴 컨텍스트는 오히려 추론 정확도를 떨어뜨릴 수 있다

이 네 가지를 묶으면 Tokit이 어디에 서야 하는지 보인다.

• AI 도구 사용은 계속 늘고 있다
• 비용 최적화는 실제 문제다
• 한국어 사용자는 토큰 비용에서 불리하다
• 긴 입력을 무작정 보내는 방식은 품질에도 불리하다

즉, Tokit은 단순히 “토큰을 줄이면 좋다”는 이야기가 아니라, 비용과 품질을 같이 다루는 도구로 설명할 수 있게 됐다.

MVP 범위도 꽤 선명해졌다

오늘 발표 자료에서 개인적으로 제일 좋았던 부분은 기능 범위가 많이 좁혀졌다는 점이다. 처음부터 다 하려 하지 않고, 실제로 보여줄 수 있는 최소 기능을 세 개로 나눴다.

1. Prompt Compiler

• 한국어 입력을 영어 프롬프트로 컴파일
• 불필요한 문장을 줄이고 구조를 정리
• 입력 토큰 절감 효과를 직접 비교 가능

2. Basic CLI Wrapper + LLM 실행

• 기존 CLI 위에 Tokit을 덧붙임
• 쓰는 사람은 새 앱을 배우는 대신 기존 방식 그대로 사용
• 인터랙티브 셸 형태로 실제 동작 환경을 만듦

3. Output Compression + Simple State

• 출력에서 핵심 정보만 남겨 다음 단계에 전달
• 세션의 최소 상태를 유지해서 같은 설명을 반복하지 않게 함

정량 목표도 같이 넣었다.

• 입력 토큰 20~40% 감소
• 출력 토큰 20~50% 감소
• 총 토큰 사용량 25~50% 감소
• 반복 설명 없이 다음 작업으로 넘어가는 비율 90% 이상

수치가 완벽하게 맞아떨어질지는 나중에 검증이 필요하겠지만, 적어도 “무엇을 성공으로 볼 것인가”는 훨씬 분명해졌다.

일정과 역할도 발표 기준으로 정리했다

일정은 기획, 설계, 구현, 테스트, 발표 순서로 나눴고, 이후에는 확장과 웹 UI 개선까지 이어지도록 잡았다. 중요한 건 처음 10일 안에 핵심 기능 3개를 보여주는 데 집중한다는 점이었다.

역할 분담도 발표 자료에 맞춰 다시 정리했다.

• 규철님: 기획, 일정 관리, CLI 개발
• 나는 Task Graph와 Workflow 쪽
• 지호님은 State & Context 쪽
• 시호님은 AI 프롬프트 엔지니어링 쪽

내 입장에서는 내가 맡은 범위가 좀 더 명확해진 날이었다. 특히 여러 작업이 섞인 요청을 어떻게 나누고, 어떤 순서로 실행할지, 그 결과를 세션과 어떻게 이어 붙일지가 내가 맡아야 할 축이라는 점이 분명해졌다.

오늘 느낀 점

4월 20일이 방향을 다시 세우는 날이었다면, 4월 21일은 그 방향을 발표할 수 있는 말로 바꾸는 날이었다.

좋았던 점은 세 가지였다.

• 문제 정의가 전날보다 훨씬 간결해졌다
• 쓰는 사람, 근거, 기능, 일정이 한 문서 안에서 이어졌다
• MVP 범위가 현실적인 수준으로 정리됐다

반대로 아직 남아 있는 것도 분명했다.

• 정량 목표가 실제 테스트에서 얼마나 재현될지는 아직 모른다
• 발표에서 한 말과 실제 구현이 어긋나지 않도록 더 다듬어야 한다
• B2B나 대시보드 쪽은 지금 단계에서는 조금 뒤로 미루는 게 맞아 보인다

그래도 오늘 기준으로 Tokit은 전날보다 훨씬 설명하기 쉬운 프로젝트가 됐다. 아이디어를 말하는 단계에서, 적어도 문제-사용자-해결 방식-MVP가 이어진 기획서 단계로는 넘어왔다고 본다.