[DeToks] Day 3 - DeToks 리브랜딩과 기획서 구조 수정

4월 22일에는 전날 만든 발표 자료를 단순히 늘리기보다, 기획서가 더 빠르게 읽히도록 다듬는 일에 집중했다. 기능을 새로 붙이기보다는 이미 정리한 내용을 덜 반복되게 만들고, 처음 보는 사람도 바로 이해할 수 있도록 흐름을 손봤다.

이날 가장 크게 바뀐 것은 두 가지였다. 하나는 서비스명이고, 다른 하나는 설명 방식이었다. 원래 이름은 Tokit이었지만, 이름만 들었을 때 무엇을 하는 서비스인지 바로 떠오르지 않는다는 점이 걸렸다. 그래서 서비스가 하는 일을 더 직접적으로 드러내는 DeToks로 방향을 바꿨다.

기획서는 잘 설명하는 것보다 빨리 이해돼야 했다

이날 메모를 보면 목표가 분명했다. 기획서를 더 읽기 쉽게 고치고, 기능 설명과 비교 내용을 다시 정리하고, 서비스 방향과 이름에 맞는 로고 아이디어까지 잡는 것이었다.

실제로 한 일도 거의 그 흐름을 따라갔다.

• 기획서 문장을 단순화하고 중복을 줄였다
• 기능 구성을 다시 정리했다
• Prompt Compiler, Request Analyzer, CLI의 역할을 더 분명하게 나눴다
• Request Type 분류 방식과 구현 방향을 정리했다
• 서비스 로고 시안을 여러 개 보고 방향 피드백을 주고받았다

이날 이슈로 따로 적어둔 내용도 비슷했다. 기획서 내용이 반복되고 문장이 어렵게 보인다는 점, 4.1과 4.2가 따로 노는 점, 로고가 서비스 의미를 충분히 보여주지 못한다는 점이었다.

해결 방향도 명확했다. 기술 설명 위주의 문장을 쉬운 문장으로 바꾸고, 문서 흐름을 맞추고, 정리 / 제거 / 압축의 의미가 보이도록 디자인 방향을 고치는 것이었다.

Tokit보다 DeToks가 더 바로 읽혔다

이날 팀에서 가장 크게 합의한 건 서비스 이름이었다. Tokit은 나쁘지 않았지만, 처음 들었을 때 이 서비스가 무슨 일을 하는지 바로 연결되지는 않았다. 결국 한 번 더 설명이 필요했다. 반면 DeToks는 de-tokenize를 떠올리게 하면서, 불필요한 토큰을 덜어내고 줄이는 서비스라는 인상이 훨씬 직접적이었다.

내 기준에서도 이 변경은 꽤 괜찮았다. 이 프로젝트의 핵심은 멋진 브랜드 이름보다 토큰을 줄이고 흐름을 정리한다는 기능이 빠르게 이해되는 데 있었기 때문이다. Tokit은 이름을 소개한 뒤 설명을 덧붙여야 했지만, DeToks는 이름만 들어도 어느 정도 방향이 읽힌다.

그래서 서비스 설명도 조금 더 간결해졌다.

• Tokit: 프롬프트 컴파일러인지, 작업 흐름 최적화 도구인지 한 번 더 설명해야 함
• DeToks: 토큰을 덜 쓰게 만드는 도구라는 인상이 먼저 들어옴

이 차이는 생각보다 컸다. 발표나 문서에서 서비스명을 말할 때마다 설명이 따라붙으면, 프로젝트가 아직 덜 정리된 느낌을 주기 쉽다. 반대로 이름만으로 핵심 기능이 전달되면 문장 전체도 훨씬 짧아진다.

로고도 기능보다 먼저 시선을 잡는 쪽으로 갔다

이날은 이름만 바꾼 것이 아니라 로고 방향도 함께 다시 봤다. 단순히 예쁜 이미지를 고르는 것이 아니라, README 맨 위에 둘 때 사람들의 시선을 바로 끌 수 있는가를 더 중요하게 봤다. GitHub 저장소를 처음 열었을 때 가장 먼저 보게 되는 영역이 상단 배너나 대표 이미지이고, 그 한 장이 프로젝트의 첫인상을 거의 결정한다고 생각했기 때문이다.

그래서 비교적 강한 인상을 주는 시안을 택하는 쪽으로 기울었다. DeToks 로고는 서비스 기능을 직관적으로 보여주는 점도 있었지만, 한눈에 들어오고 기억에 남는다는 점이 컸다. 팀 안에서도 “README 첫 화면에서 눈길을 잡는 역할”을 기대하는 쪽에 가까웠다.

조금 가볍게 말하면, 개발 커뮤니티에는 일본 애니 캐릭터를 프로필이나 대표 이미지로 쓰는 사람들이 왠지 개발을 잘한다는 식의 속설도 있다. 물론 진짜 실력을 보장하는 건 아니지만, 그런 이미지는 기술 커뮤니티 안에서 눈에 잘 띄고 강한 인상을 남기는 편이다.

이번 로고도 그런 감각을 어느 정도 의식해서 골랐다고 볼 수 있다. 딱딱한 최적화 도구보다, 한 번 보면 기억나는 개발자 도구처럼 보이게 하려는 의도가 있었다.

팀 이름도 T1으로 정리했다

서비스명과 함께 팀 이름도 정했다. 이름은 T1이고, 뜻은 토큰 이찌방이다. 토큰을 가장 효율적으로 다루겠다는 의미를 담은 이름이라서 이번 프로젝트 방향과도 잘 맞았다.

처음엔 다소 장난스럽게 들릴 수도 있지만, 발표용 팀명으로는 오히려 기억에 남는 편이라고 느꼈다. 토큰 최적화라는 프로젝트 주제를 팀명까지 자연스럽게 연결한 셈이고, 짧고 부르기 쉬운 점도 괜찮았다.

프로젝트가 기술적으로는 작업 흐름 최적화, 프롬프트 압축, 상태 관리까지 넓게 다루더라도, 바깥에서 볼 때는 결국 토큰을 가장 효율적으로 쓰려는 팀이라는 한 문장으로 묶을 수 있게 됐다.

이날 느낀 점

4월 22일은 새 기능을 많이 붙인 날이라기보다, 프로젝트를 더 잘 이해되게 만든 날에 가까웠다. 그 과정에서 다시 느낀 건, 기획서는 자세히 설명하는 것보다 빨리 이해되게 만드는 쪽이 더 중요하다는 점이었다. 기능 설명을 더 추가하는 것보다, 흐름을 정리하고 반복을 줄이는 편이 훨씬 효과가 컸다.

그리고 이름도 결국 같은 문제라는 생각이 들었다. Tokit처럼 한 번 더 설명이 필요한 이름보다, DeToks처럼 듣자마자 역할이 어느 정도 그려지는 이름이 지금 단계의 프로젝트에는 더 잘 맞았다. 팀명 T1까지 붙이고 나니, 적어도 밖으로 보여줄 틀은 전날보다 훨씬 선명해졌다.