[Tokit] Extra 1 - 구조, 차별점, 우선순위 정리

한 줄 정의

Tokit은 한국어 개발자 프롬프트를 영어 coding prompt로 컴파일하고, CLI 세션 안에서 컨텍스트와 출력을 관리해 전체 토큰 비용을 줄이는 래퍼다.

Tokit이 하는 일

입력

• 한국어 개발자 요청 받기
• 요청 성격 분류하기
• 불필요한 표현 줄이기
• 코드 블록, 파일 경로, 명령어는 보호하기
• 영어 coding prompt로 변환하기

출력

• 응답을 그대로 버리지 않고 다음 턴에 유리한 형태로 정리하기
• 전체 코드 재출력 대신 diff/patch 중심으로 유도하기
• 긴 설명은 세션 상태로 압축해서 다시 쓰기

세션

• 이전 턴 요약 저장
• 이미 처리한 작업 상태 저장
• 같은 컨텍스트 재사용
• 중복 맥락 반복 전달 줄이기

핵심 기준

팀 대화 기준으로 변하지 않는 조건은 이거다.

• 토큰은 줄여야 한다
• 성능 저하는 나오면 안 된다
• CLI라서 체감 속도도 중요하다
• 출력 토큰은 강제로 줄이기보다 세션 단위로 관리하는 쪽이 더 현실적이다

정리하면:

입력은 동적으로 정제하고, 출력은 보수적으로 다루고, 진짜 절감은 세션 구조에서 만든다.

Tokit 동작 흐름

1. 입력 분석

• debug / review / explain / generation 분류
• 길이 제약, 출력 형식 제약 추출
• 보호 구간 식별

2. 프롬프트 컴파일

• 한국어 입력을 영어 명령형 프롬프트로 변환
• 의미 유지
• 길이 절감
• 출력 형식 제어 포함

3. 모델 실행

• 컴파일된 프롬프트를 LLM 또는 타겟 CLI에 전달

4. 출력 후처리

• diff/patch 중심으로 정리
• 다음 턴에 필요한 상태만 저장
• 중복 설명은 세션으로 흡수

5. 세션 최적화

• 이전 결과 재사용
• 중복 컨텍스트 제거
• 캐싱
• 다음 턴 전달량 최소화

바로 적용할 기술

NLP

1. 텍스트 전처리

• 공백 정리
• 반복 표현 제거
• 보호 구간 분리
• /, @, ! pass-through

2. 작업 유형 분류

• TF-IDF + Logistic Regression baseline 가능
• 이유:
  • 빠름
  • 해석 쉬움
  • MVP 기준점으로 적절함

3. 규칙 기반 조건 추출

• 길이 제약
• 출력 형식 제약
• 코드 관련 여부
• 파일/경로 포함 여부

시스템

1. 세션 상태 관리

• 이전 턴 요약 저장
• 작업 상태 저장
• 필요한 정보만 다음 턴 전달

2. 토큰 측정과 benchmark

• 원문 입력 토큰
• 최적화 후 입력 토큰
• 출력 토큰
• 전체 응답 시간
• 품질 체크 기준

3. fallback

• 짧은 입력은 그대로 통과
• 보호 구간 비율이 높으면 최적화 생략
• 품질이 흔들리면 보수 모드로 전환

현재 범위

1차 MVP에서 바로 할 것

1. 입력 전처리
2. 보호 구간 분리와 pass-through
3. 작업 유형 분류 baseline
4. 규칙 기반 제약 추출
5. 한국어 -> 영어 프롬프트 컴파일
6. 세션 상태 저장
7. 토큰/속도 측정

2차로 붙일 것

1. diff/patch 자동 병합 고도화
2. 세션 요약 압축 전략
3. 캐싱 강화
4. 유사 요청 검색
5. 템플릿 추천

지금은 미룰 것

1. fine-tuning
2. 무거운 reasoning 모델 추가
3. 과도한 출력 토큰 강제 압축
4. 복잡한 멀티모델 파이프라인

이건 지금 들어가면 프로젝트 중심이 흐려질 가능성이 크다.

논의 내용과 맞는지 체크

맞는 부분

• 정적인 skill 방식이 아니라 동적 분류/변환 구조
• 한국어 입력 -> 영어 변환은 입력 토큰 절감에 유리
• 출력 토큰은 보수적으로 접근
• 진짜 절감은 세션 관리에서 나올 가능성이 큼
• /benchmark는 검증 기능에 가까움
• diff/patch 유도가 중요함

표현상 조심할 부분

1. “시스템 프롬프트를 씌운다”

이 표현은 피하는 게 맞다.

정확히는 Tokit 내부의 프롬프트 컴파일 규칙 또는 변환 로직에 가깝다.

2. “출력을 강하게 압축한다”

이 표현도 현재 논의와는 안 맞는다.

지금 방향은:

• 장문을 무조건 줄이는 것

보다

• diff/patch 중심 유도
• 세션 상태 관리
• 다음 턴 전달량 절감

쪽이다.

3. “큰 모델을 더 붙이면 해결된다”

이것도 현재 방향과 다르다.

지금 Tokit은 모델을 키우는 프로젝트가 아니라, 기존 모델을 덜 낭비하게 만드는 프로젝트에 가깝다.

공개 레포 비교

부분적으로 비슷한 건 이미 많다.

• 입력 압축 도구 있음
• 세션 캐싱 도구 있음
• diff/patch CLI 있음

그런데 한국어 개발자 입력 -> 작업 분류 -> 프롬프트 컴파일 -> 세션 최적화 -> patch 중심 출력을 한 흐름으로 묶은 건 거의 못 찾았다.

1. 구조 비교용 레포

정리하면:

• prompt-optimizer는 입력 쪽 조각
• token-optimizer-mcp는 세션 쪽 조각
• gptdiff는 출력 쪽 조각

Tokit은 이 셋을 한 흐름으로 붙이는 쪽에 가깝다.

2. 한국어 맥락 참고 레포

이쪽은 Tokit과 구조가 비슷한 레포라기보다, 한국어 입력을 어떻게 다룰지 참고할 때 볼 만한 레포다.

정리하면:

• 구조 비교는 위 3개 레포를 보는 게 맞고
• 한국어 처리 방향은 이 참고 레포들을 따로 보는 게 맞다

Tokit의 위치

Tokit은 입력 최적화 도구, 세션 최적화 도구, diff/patch 기반 출력 도구를 한국어 개발자 워크플로 기준으로 한 흐름으로 묶는 프로젝트다.

MoSCoW

한눈에 보기

Must Have

1. 한국어 개발자 입력 -> 영어 coding prompt 컴파일

해야 하는 일:

• 한국어 개발자 요청을 영어 명령형 프롬프트로 변환
• 작업 내용, 제약, 출력 형식을 유지
• 불필요한 표현은 줄이고 핵심 작업만 남기기

어떻게 구현할 수 있나:

• 컴파일 전용 프롬프트 템플릿 정의
• 출력 규칙 고정:
  • 영어만 출력
  • 명령형 문장
  • 제약 유지
  • 최종 프롬프트만 반환
• 초기에는 LLM 기반 컴파일로 시작하고, 반복 패턴은 규칙 기반으로 보완

2. 보호 구간 분리와 pass-through

해야 하는 일:

• 코드 블록, 파일 경로, 에러 메시지, 명령어를 최적화 대상에서 분리
• 건드리면 안 되는 구간은 원문 그대로 유지

어떻게 구현할 수 있나:

• 정규식으로 보호 구간 먼저 추출
• /, @, ! 시작 명령은 즉시 pass-through
• 보호 구간은 placeholder로 치환한 뒤 나머지 텍스트만 처리
• 최종 결과에서 보호 구간 원복

3. 작업 유형 분류 기반 최적화

해야 하는 일:

• 요청을 debug / review / explain / generation 등으로 분류
• 작업 유형별로 다른 압축 전략과 출력 지시 적용

어떻게 구현할 수 있나:

• 1차는 규칙 기반 키워드 분류
• 2차는 TF-IDF + Logistic Regression baseline
• 유형별 컴파일 템플릿 분리
  • debug: 원인, 재현, fix 중심
  • review: 위험 포인트 중심
  • explain: 길이 제약 완화 가능

4. 세션 상태 관리

해야 하는 일:

• 이전 턴 결과를 저장
• 다음 턴에 필요한 정보만 다시 전달
• 중복 컨텍스트 반복 전송 줄이기

어떻게 구현할 수 있나:

• 세션별 state 객체 유지
• 저장 항목 예시:
  • recent_tasks
  • protected_context
  • prior_outputs
  • summaries
• 긴 출력은 그대로 보관하지 않고 요약 상태로 저장
• 같은 요청/같은 문맥이면 캐시 재사용

5. 토큰/속도 측정과 benchmark

해야 하는 일:

• 최적화 전후 입력/출력 토큰 측정
• 전체 응답 시간 기록
• 품질 저하 여부 같이 확인

어떻게 구현할 수 있나:

• 요청마다 로그 레코드 저장
  • original_input_tokens
  • compiled_input_tokens
  • output_tokens
  • latency_ms
• /benchmark 명령으로 원문 vs 컴파일 버전 비교
• 같은 요청에 대해 반복 측정 가능하게 설계

6. 한국어 입력 기준 차별성 유지

해야 하는 일:

• Tokit이 영어권 일반 optimizer와 다르다는 점을 기능으로 보여주기
• 한국어 개발자 요청에 맞는 흐름 유지

어떻게 구현할 수 있나:

• 한국어 조사/완곡 표현 제거 규칙 추가
• 한국어 개발자 요청 예시 세트 구성
• 자주 나오는 요청 패턴을 샘플 데이터로 관리

요약:

• Tokit이 Tokit답기 위해 가장 먼저 필요한 축
• 1차 MVP에서 반드시 들어가야 함

Should Have

1. diff/patch 중심 출력 유도

해야 하는 일:

• 전체 코드 재출력 대신 변경 부분만 반환하게 유도
• 후속 작업에서 출력 토큰 낭비 줄이기

어떻게 구현할 수 있나:

• 출력 지시문에 diff/patch 우선 규칙 추가
• 함수 단위 변경, unified diff, line patch 중 한 형식으로 제한
• 로컬에서 patch apply 또는 merge 처리

2. 캐싱

해야 하는 일:

• 반복 요청과 반복 컨텍스트를 재사용
• 세션 비용과 지연 줄이기

어떻게 구현할 수 있나:

• 입력 + 작업 유형 + 보호 구간 해시로 캐시 키 생성
• compiled prompt 캐시
• 세션 요약 캐시
• 최근 파일/문맥 캐시

3. 구조화된 내부 표현

해야 하는 일:

• 입력을 그냥 문자열이 아니라 내부 상태 객체로 관리

어떻게 구현할 수 있나:

• 내부 JSON 구조 예시:

{
  "intent": "debug",
  "constraints": ["brief", "only bug"],
  "protected_segments": ["path", "codeblock"],
  "output_preference": "diff"
}

• 컴파일, 세션 저장, 출력 제어에서 같은 구조 재사용

4. fallback 전략

해야 하는 일:

• 최적화 실패나 품질 저하 시 원문 또는 보수 모드로 되돌리기

어떻게 구현할 수 있나:

• 짧은 입력은 그대로 통과
• 보호 구간 비율이 높으면 최적화 생략
• 분류 확신도 낮으면 기본 템플릿 사용
• benchmark 결과가 나쁘면 해당 전략 비활성화

5. diff/patch 결과 검증

해야 하는 일:

• patch 적용 후 결과가 실제로 유효한지 확인

어떻게 구현할 수 있나:

• apply 전후 diff 비교
• 파일 파싱 가능 여부 확인
• 실패 시 rollback
• 원문 보존

요약:

• 1차 MVP 다음 단계에서 바로 붙일 만한 항목
• 체감 효율과 안정성을 크게 올려줌

Could Have

1. 유사 요청 검색

해야 하는 일:

• 과거 요청과 비슷한 패턴을 찾아 재사용

어떻게 구현할 수 있나:

• 임베딩 저장
• cosine similarity 기반 검색
• 최근 성공 사례 우선 추천

2. 템플릿 추천

해야 하는 일:

• 작업 유형에 맞는 프롬프트 포맷 추천

어떻게 구현할 수 있나:

• 유형별 베이스 템플릿 저장
• benchmark 결과 좋은 템플릿 우선 추천

3. 시각화 대시보드

해야 하는 일:

• 절감량과 세션 흐름을 보기 쉽게 보여주기

어떻게 구현할 수 있나:

• 토큰 절감 그래프
• cache hit rate 시각화
• 요청 유형별 성능 비교

4. IDE 플러그인 확장

해야 하는 일:

• CLI 밖에서도 같은 흐름을 쓰게 만들기

어떻게 구현할 수 있나:

• VS Code extension
• editor selection -> compile -> apply 흐름 연결

요약:

• 있으면 좋지만 초반 성공 여부를 가르는 핵심은 아님

Won’t Have For Now

1. fine-tuning

지금 안 하는 이유:

• Tokit의 핵심은 모델 학습보다 사용 레이어 최적화에 있음
• 프로젝트 범위가 너무 커짐

2. 무거운 멀티모델 파이프라인

지금 안 하는 이유:

• 속도 저하 가능성 큼
• 구조가 복잡해짐
• 현재 논의 기준과 안 맞음

3. 과도한 출력 토큰 강제 압축

지금 안 하는 이유:

• 코드 품질/설명 품질이 먼저 깨질 수 있음
• 현재 방향은 “짧게 만들기”보다 “작게 나오게 설계하기”에 가까움

4. 모든 요청 완전 자동 최적화

지금 안 하는 이유:

• 범용성을 너무 크게 잡으면 기준이 흐려짐
• 초기에는 개발자 요청 중심 패턴부터 잡는 게 맞음

요약:

• 지금 넣으면 프로젝트 중심이 흐려질 가능성이 큼
• 구조가 잡힌 뒤 다시 검토하는 게 맞음

결론

지금 기준으로 Tokit의 성공 조건은 이거다.

한국어 개발자 요청을, 작업 성격에 맞게, 안전하게 압축하고, 세션 단위로 비용까지 줄여주는가.

지금 해야 할 일은 기능을 넓히는 게 아니라, 이 문장에 직접 연결되는 것부터 먼저 만드는 것이다.