[Tokit] Day 1 방향 재정의와 역할 분담 정리

Tokit 프로젝트의 실제 첫날이었다. 오늘 한 일은 코드를 많이 짠 것보다, 이 프로젝트가 어떤 문제를 풀어야 하는지를 다시 잡는 일이었다.

처음에는 Tokit을 “프롬프트를 더 짧게 바꿔주는 도구” 정도로 생각했는데, 하루 동안 팀원들과 이야기하고 자료를 정리해보니 그 정도로는 너무 평범했다. 기존 서비스와 겹쳐 보일 가능성도 컸고, 교수님 피드백처럼 커버리지가 애매해질 위험도 있었다.

그래서 오늘 가장 크게 바뀐 건 한 문장이다.

Tokit은 단순 프롬프트 최적화 도구가 아니라, LLM CLI 앞단에서 작업 흐름을 줄여주는 도구다.

오늘 정리한 핵심

오늘 기준으로 Tokit을 다시 설명하면 이렇다.

• 한국어 개발자 프롬프트를 더 짧고 명확한 영어 명령형 프롬프트로 컴파일한다
• 출력 길이를 제어해서 불필요한 장문 응답을 줄인다
• 반복 요청에서 context, state, cache를 관리해 세션 전체 토큰 비용을 낮춘다
• 가능하면 전체 코드 재출력 대신 diff/patch 중심으로 유도한다

즉, 한 번의 입력 문장만 다듬는 게 아니라 반복되는 개발 작업 흐름 전체를 덜 낭비하게 만드는 것이 핵심이라는 쪽으로 이해가 바뀌었다.

이 생각이 중요했던 이유도 분명했다.

• 프롬프트 최적화만 강조하면 기존 도구와 차별성이 약하다
• 반대로 workflow 최적화까지 포함하면 Tokit만의 구조가 생긴다
• 발표나 문서에서도 “왜 이걸 굳이 만들었는가”를 더 설득력 있게 설명할 수 있다

오늘 실제로 한 작업

이미지 기준으로 보면 오늘 목표는 팀 정보 확정과 프로젝트 기획서 작성이었다. 실제로 한 일도 이 흐름에서 크게 벗어나지 않았다.

• 프로젝트 팀 편성을 마무리했다
• 프로젝트 기획서 초안을 작성했다
• 사용할 사람의 페르소나와 유저 플로우를 일부 정리했다
• 통계 자료와 유사 서비스 비교 내용을 기획서에 넣었다
• 기존 서비스와 어떤 점이 다른지 다시 정리했다
• MVP에서 꼭 가져갈 목표와 요구사항만 남겼다
• 역할을 Task Graph / State / CLI 중심으로 나눴다

진행률로 봐도 체감이 비슷했다. 팀 편성은 거의 마무리됐고, 기획 문서는 초안이 잡히긴 했지만 완성이라고 보기엔 아직 60% 정도였다.

방향을 왜 다시 잡았는가

오늘 가장 큰 이슈는 “이 프로젝트가 기존 프롬프트 최적화 서비스와 너무 비슷한 것 아니냐”는 문제였다.

실제로 그 질문은 꽤 아팠다. 프롬프트를 줄이고, 영어로 바꾸고, 출력 길이를 줄인다는 설명만 놓고 보면 이미 비슷한 이야기들이 많다. 이 상태로 가면 Tokit은 새 프로젝트라기보다 기존 아이디어를 조합한 수준처럼 보일 수 있다.

그래서 해결 방식도 명확했다.

• 단일 프롬프트 최적화가 아니라 세션 단위 최적화로 시야를 넓히기
• 반복 작업에서 context reuse, state 전달, caching을 핵심 축으로 잡기
• 전체 코드 재생성 대신 diff/patch처럼 실제 비용 절감이 큰 지점을 강조하기
• 범용 시스템처럼 크게 벌리기보다 10일 MVP 기준으로 구현 범위를 줄이기

이렇게 정리하고 나니 프로젝트 설명이 훨씬 단단해졌다. “문장을 잘 바꾸는 도구”보다 “개발 workflow에서 생기는 낭비를 줄이는 시스템”이라고 말하는 편이 훨씬 맞아 보였다.

비교한 서비스와 느낀 차이

오늘은 비슷한 결의 서비스도 직접 들어가 보고 비교했다. 이번에 본 대상은 아래 세 개였다.

• RTK
• HAM
• Headroom

셋 다 “LLM 사용 효율을 높인다”는 큰 방향은 비슷했지만, 실제로 초점은 꽤 달랐다.

RTK는 가장 직관적이었다. 소개 페이지를 보면 CLI 출력 노이즈를 줄여서 context window를 덜 오염시키는 도구라는 색깔이 분명했다. 테스트 출력이나 git diff 같은 결과를 압축해서 더 긴 세션과 더 낮은 비용을 만든다는 설명이 강해서, 이쪽은 입력 이전보다 출력 이후 필터링에 더 가깝다고 느꼈다.

HAM은 메모리 시스템이라는 표현이 더 잘 맞았다. 디렉터리 단위로 context를 관리하고 필요한 범위만 남겨서 토큰 사용량을 줄이는 구조라서, 프롬프트를 다시 쓰는 도구라기보다 메모리와 컨텍스트 구조화에 더 초점이 있었다.

Headroom은 이름 그대로 context optimization layer 쪽에 가까웠다. LLM 애플리케이션에서 context를 덜 낭비하게 만든다는 점은 Tokit과 맞닿아 있었지만, 내가 오늘 정리한 Tokit처럼 한국어 입력 컴파일, task 이해, state 전달, CLI 흐름까지 한 번에 묶는 구조와는 결이 조금 달랐다.

오늘 비교해 보고 내가 정리한 차이는 이랬다.

• RTK는 출력 필터링에 강하다
• HAM은 메모리/컨텍스트 구조화에 강하다
• Tokit은 입력, 중간 상태, 출력까지 포함한 workflow 전체를 다뤄야 한다

이걸 한눈에 보려고 표도 같이 정리했다.

한 줄로 줄이면 아래처럼 정리할 수 있다.

• RTK -> 출력 필터
• HAM -> 메모리 구조
• Tokit -> 전체 워크플로우 오케스트레이션

이 비교를 넣고 나서 Tokit을 설명하는 문장도 더 분명해졌다. 단순히 “우리도 토큰을 줄인다”가 아니라, 입력 전처리, task graph, state 전달, 출력 제어를 묶어서 workflow 전체를 최적화한다고 말해야 Tokit답다는 생각이 들었다.

역할 분담

오늘은 역할도 꽤 구체적으로 정리했다. 단순히 백엔드, 프론트엔드처럼 나누기보다 Tokit 구조 자체를 기준으로 나눴다는 점이 좋았다. 그리고 여기서 지현이 바로 나다.

Role 1. AI 프롬프트 엔지니어 (AI Compiler & NLP) - 시호

역할은 한국어 입력을 영어로 컴파일하고, 복합 작업을 Task Graph 형식의 JSON으로 추출하는 프롬프트를 설계하는 것이다.

• 한국어 입력을 영어 명령형 프롬프트로 컴파일
• 의도, 공유 컨텍스트, 작업 순서 등을 JSON 구조로 추출
• 모델이 항상 일관된 JSON 스키마를 출력하도록 형식 강제
• 토큰 소모량을 최소화하는 프롬프트 설계 담당

Role 2-1. Task Graph & Workflow Engineer - 지현

내가 맡은 역할은 멀티태스크 요청을 분해한 뒤, 작업 순서와 의존성을 관리하는 실행 흐름 쪽이다.

• Task Graph 생성
• depends_on 기반 실행 순서 정의
• 순차 실행 / 병렬 실행 기준 정리
• task 단위 실행 파이프라인 연결

이 역할은 결국 Tokit이 “한 번 답하고 끝나는 도구”가 아니라, 여러 작업을 흐름으로 다룰 수 있게 만드는 축에 가깝다.

Role 2-2. State & Context Engineer - 지호

이 역할은 이전 단계 결과를 다음 단계에 전달할 수 있도록 상태와 컨텍스트를 압축하고 구조화하는 쪽이다.

• shared_context / task_context 분리
• 단계별 결과를 JSON 상태로 정리
• 다음 단계 전달용 요약 구조 설계
• 중복 context 제거 및 핵심 정보 유지

반복 작업이 길어질수록 context가 눈덩이처럼 커지기 쉬운데, 이 역할은 그걸 제어하는 데 핵심이다.

Role 3. CLI/시스템 엔지니어 (System & CLI Core) - 규철

이쪽은 터미널 환경과 직접 맞닿는 인터페이스를 개발하고, 실제로 Tokit을 쓸 수 있는 형태로 만드는 역할이다.

• CLI 인터페이스 구현
• 기존 명령어(/, @, !) pass-through 처리
• 파일 시스템 접근, 로그, 파일 경로 파싱 처리
• OS 환경별 에러 제어와 터미널 출력 가독성 담당

아무리 모델 쪽 설계가 좋아도 CLI 환경에서 버그가 나면 쓸 수 없기 때문에, 실제 사용성을 책임지는 축이라고 볼 수 있다.

Role 4. QA, 데이터 측정 및 Quality Assurance & Metrics

이 역할은 1, 2, 3번 흐름이 어느 정도 만들어진 뒤에 붙는 검증 역할이다.

• “정말 비용이 줄었는가?”
• “성능은 유지되는가?”
• 이 두 질문에 답할 수 있도록 벤치마크 테스트셋과 지표를 만든다

주요 업무는 아래처럼 정리됐다.

• 다양한 엣지 케이스 수집
• 더러운 로그, 복잡한 코드 같은 입력 준비
• Role 1과 Role 2가 로직을 개선할 수 있도록 피드백 루프 설계

결국 Tokit은 “좋아 보이는 설명”보다 “정말 토큰이 줄었는지”를 보여줘야 하니까, 마지막에는 이 QA와 측정 파트가 꼭 필요하다는 얘기까지 나왔다.

내일 할 일

내일 계획도 자연스럽게 이어진다.

• 프로젝트 기획서 계속 작성하고 피드백 반영하기
• GitHub 레포지토리 포함 개발환경 구축하기
• 역할별 세부 기능 정리하기
• MVP 범위 안에서 무엇을 먼저 구현할지 확정하기

오늘이 개념 정리의 날이었다면, 내일은 문서와 환경을 실제 실행 가능 상태로 바꾸는 날에 가까울 것 같다.

오늘 느낀 점

오늘은 감정적으로도 약간 복잡했다. 처음에는 내가 낸 아이디어가 아닌 프로젝트에 참여하다 보니, 개념 정리와 구조화가 완전히 내 머릿속에 들어와 있지 않아서 조금 혼란스러웠다. 비슷한 서비스는 이미 꽤 존재하는데, 방법론이 다르다는 점을 확인하면서도 그 차이를 얼마나 설득력 있게 설명할 수 있을지가 계속 신경 쓰였다.

특히 어려웠던 건 머릿속에 프로세스가 명확히 그려지지 않은 상태에서 팀원들과 컨센서스를 맞추는 일이었다. 그래도 오늘 하루 지나고 나니 최소한 무엇을 해야 하는 프로젝트인지, 그리고 어떤 Role이 필요한지는 전보다 훨씬 명확해졌다.

결국 Day 1의 성과는 구현보다 방향이었다. 오늘 Tokit은 조금 더 구체적인 이름이 되었고, 나도 그 안에서 따라가야 할 속도가 무엇인지 더 분명하게 알게 됐다.