생각 토큰을 끄니 초기화가 15배 빨라졌다

CLI 도구를 생성할 때 초기 설정 단계(리딩)가 2분 반 이상 걸리던 문제를 해결했다. 원인은 두 가지였다: Large Language Model의 thinking 토큰이 활성화되어 있었고, 실제로는 필요 없는 stdin 대기가 3초씩 추가되고 있었다.

왜 thinking 토큰이 초기 설정을 느리게 만들었나

우리가 사용하는 LLM API에서 MAX_THINKING_TOKENS는 모델이 최종 응답을 생성하기 전에 "내부적으로 생각하는 시간"을 허용한다. 이 과정에서 소비된 토큰들은 사용자에게 직접 보이지 않지만, API 호출 시간에는 고스란히 반영된다. 이론적으로는 더 정확한 답변을 얻을 수 있다는 장점이 있다.

하지만 초기 설정 단계는 상황이 다르다. 리딩이나 티저 같은 초기화 작업은:
- 다양한 추론이 필요 없다 (정해진 패턴)
- 속도가 사용자 경험에 직결된다 (대기 시간이 길어지면 개발 flow가 깨진다)
- 이미 충분히 테스트된 로직이다 (틀릴 가능성 낮음)

따라서 이 단계에서는 thinking 토큰 활성화가 순수 오버헤드였다. 약 2분의 추론 시간 중 상당 부분이 사실 불필요한 내부 생각 시간이었던 것이다.

stdin 대기가 왜 있었고, 왜 제거했는가

초기 설정 흐름에 3초씩 stdin(표준 입력) 대기가 있었다. 이것은 아마도 사용자가 콘솔에서 뭔가 입력할 가능성을 대비해 넣은 로직일 것 같다. 하지만 리딩/티저 같은 자동 초기화 단계에서는:
- 사용자가 상호작용하지 않는다
- 스크립트 또는 자동화된 흐름이다
- 따라서 3초 대기는 불필요하다

이 두 가지 조치(thinking 토큰 비활성화 + stdin 대기 제거)를 동시에 적용한 결과가 극적이었다.

실측 성능 개선

2분 반이 10초가 되었다는 건, 개발자 입장에선 엄청난 차이다. 특히 초기화가 여러 번 반복되는 CI/CD 파이프라인이나 로컬 테스트 사이클에서 누적되는 시간 낭비가 해소된 것이다.

팀장으로서 배운 점

이런 최적화 작업을 진행하면서 몇 가지 원칙을 다시 확인했다:

1. 측정 우선: 추측하지 말고 실제로 시간을 잰다. 어디가 느린지 명확해야 의사결정할 수 있다.
2. 기능별 요구사항 분화: thinking 토큰이 모든 상황에 나쁜 건 아니다. 복잡한 추론이 필요한 작업에서는 오히려 품질 향상이다. 초기화처럼 빠른 응답이 중요한 단계에서만 비활성화한다.
3. 누적 효과: 3초짜리 stdin 대기 같은 "작은" 지연도 중요하다. 팀 전체가 이 초기화를 반복하면 월 단위로 엄청난 시간이 낭비된다.
4. 의도적 변경: 왜 이게 있었는지 이해하고 제거한다. 무작정 빠르게 만드는 게 아니라, 각 요소의 필요성을 판단한 후 불필요한 부분만 제거한다.

비슷한 상황에 있다면 체크해 볼만한 포인트들:
- API 호출 시 모델의 사고 시간(thinking) 설정 — 정말 필요한가?
- I/O 대기 로직 — 실제 사용 흐름에 필요한가?
- 반복 호출되는 부분의 미세한 지연들 — 누적 효과는?

결국 성능 최적화는 기술 문제가 아니라 의사결정 문제다. 무엇을 우선하고(speed vs accuracy), 어디에 비용을 쓸 것인가(compute vs latency)를 팀과 함께 정의하는 과정이 핵심이다.

🛒 이 글과 어울리는 추천 상품

• 노트북 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.