코딩 및 AI 앱을 위한 하나의 콘솔: 변경 사항 및 활용 방법

TokenLab Console은 코딩 어시스턴트 모드와 AI 애플리케이션 모드가 하나의 작업 영역으로 통합되면서 단순한 대시보드 이상의 의미를 갖게 되었습니다. 이제 파이프라인 내에서 요청, 응답, 그리고 그와 관련된 계정 상태가 한곳에 모여 있습니다. 이로 인해 모든 세션에서 컨텍스트 전환이 제거되었으며, 응답이 느릴 때 이를 확인하는 방식도 바뀌었습니다.

핵심 요약

• 코딩 어시스턴트 모드와 AI 애플리케이션 모드가 이제 TokenLab Console 내에서 함께 작동하며, 기존의 두 진입점이 하나로 통합되었습니다.
• 기존 링크는 여전히 작동하며, 이전 대화 내용도 그대로 유지됩니다. 수동으로 마이그레이션할 필요가 없습니다.
• 응답은 마지막에 한꺼번에 나타나는 대신 모델이 생성함에 따라 스트리밍됩니다. 인터페이스에는 첫 번째 토큰 생성 시간이 표시됩니다.
• 첫 번째 토큰 지연 시간(First-token latency)은 인터페이스 전용 장식이 아니라 기록된 요청 신호(요청 로그의 ttft_ms)입니다.
• 대화 도중 잔액이 부족해지면, 별도의 결제 페이지로 이동할 필요 없이 대화창 옆에서 바로 충전할 수 있습니다.
• 콘솔의 모델 선택은 공개 카탈로그를 따릅니다. 현재 옵션은 모델 디렉터리에서 확인하세요. 현재 카탈로그 예시로는 Claude Sonnet 5와 DeepSeek V4 Pro가 있습니다.

TokenLab Console의 변경 사항 및 유지 사항

이번 변경은 두 번의 변경 로그 항목으로 배포되었습니다. 2026년 8월 4일의 콘솔 통합(Console convergence)을 통해 기존의 두 진입점이 하나의 콘솔로 이동했습니다. 2026년 8월 18일의 콘솔 채팅 스트리밍(Console chat streaming)을 통해 채팅 스트리밍 기능이 추가되었습니다. 두 변경 사항은 한 달 간격으로 적용되었으므로, 첫 번째 변경 사항을 놓친 팀도 두 번째 변경 사항을 자동으로 적용받게 됩니다.

이는 동작 방식이 아닌 인터페이스의 변화입니다. 모델 호출, 키, 결제 방식은 그대로 유지됩니다. 기존 링크는 계속 작동하며, 통합 과정에서 기존 대화 내용도 모두 보존되었습니다. 수동 마이그레이션 단계는 없습니다.

통합 단계는 진입점에 관한 것이지 모델 액세스에 관한 것이 아닙니다. 스트리밍 단계는 응답이 나타나는 방식에 관한 것이지 토큰 과금 방식에 관한 것이 아닙니다. 제품 인터페이스의 변화가 동작의 변화를 숨길 수 있는데, 이번 경우에는 그렇지 않았기 때문에 중요합니다. 이제 코딩 어시스턴트 모드와 AI 애플리케이션 모드가 한곳을 공유하므로, 세션 시작 시 어떤 진입점을 열지 고민할 필요가 없습니다.

팀 내 런북(runbook)에 이전 진입점이 명시되어 있다면, 가능한 시점에 라벨을 업데이트하십시오. 이전 링크도 여전히 작동하므로 런북이 중단되지는 않습니다. 새로운 작업은 콘솔을 즐겨찾기에 추가하여 사용하세요. 어떤 모드에서든 모델을 선택할 때 선택지는 공개 카탈로그를 따르므로 모델 디렉터리를 확인하십시오. 현재 카탈로그 예시로는 Claude Sonnet 5와 DeepSeek V4 Pro가 있습니다.

TokenLab Console의 스트리밍이 세션 확인 방식을 바꾸는 방법

스트리밍은 무언가 진행 중이라는 사실을 즉시 알 수 있게 해줍니다. 파이프라인에서 콘솔 게이트웨이 클라이언트는 스트리밍 채팅 요청을 생성하고, 응답은 점진적으로 렌더링됩니다. 인터페이스는 첫 번째 토큰 생성 시간을 표시하므로 모델이 언제 답변을 시작하는지 확인할 수 있습니다. 콘솔은 이 신호를 요청 로그의 선택적 열인 ttft_ms로 기록합니다.

첫 번째 토큰 생성 시간은 첫 번째 토큰이 도착한 시점을 알려주며, 총 지연 시간은 전체 응답이 완료된 시점을 알려줍니다. 이 둘은 서로 다른 질문이므로, 응답이 느리게 느껴진다면 먼저 ttft_ms를 확인하십시오. 첫 번째 토큰이 늦게 도착한다면 생성 전 단계에서 지연이 발생한 것이고, 첫 번째 토큰은 빨리 도착했지만 응답이 길어진다면 스트림의 나머지 부분에서 지연이 발생한 것입니다.

느린 세션을 확인할 때, 우리는 스피너(로딩 아이콘)를 보며 추측하는 대신 ttft_ms를 다른 요청 증거와 비교합니다. 요청 수준의 증거는 조직 범위로 제한되며 라우팅, 결제 상태, 캐시 상태, 그리고 요청 이면의 모델 및 키 컨텍스트를 포함합니다. 콘솔은 로그에서 직접 찾아야 했을 동일한 요청 기록을 노출합니다.

첫 번째 토큰 신호를 읽는 예시:

# 콘솔 요청 로그는 `ttft_ms`를 선택적 열로 노출합니다.
# 1. 확인하려는 요청으로 요청 로그를 필터링합니다.
# 2. `ttft_ms`를 읽습니다.
# 3. 같은 행의 요청 총 지연 시간과 `ttft_ms`를 비교합니다.

정확한 스트리밍 요청 형태는 최신 TokenLab API 문서를 참조하십시오. 임의의 필드가 포함된 복사된 요청 예시보다는 해당 이름을 정의하는 문서 페이지가 더 유용합니다.

스트리밍은 과금 대상에 영향을 주지 않습니다. 동일한 토큰이 생성되지만 도착하는 즉시 볼 수 있을 뿐입니다. 응답이 스트리밍되므로, 세션이 중단되어도 아무것도 보이지 않는 대신 부분적인 응답을 확인할 수 있습니다. 이는 세션 중간의 실패를 진단하는 방식을 바꿉니다. 채팅 스트림으로 처리할 수 없는 장기 실행 작업은 비동기 이미지 생성 작업 가이드를 참조하십시오.

추측 없이 느린 세션을 확인하는 방법

스피너가 아닌 요청 로그에서 시작하십시오. ttft_ms 열이 첫 번째 토큰이 도착한 시점을 알려주기 때문입니다. 이 수치가 높다면 모델이 아직 답변을 시작하지 않은 것입니다. 수치가 낮다면 모델이 일찍 시작했지만 나머지 스트림이 시간을 소요한 것입니다. 이러한 구분은 경로의 잘못된 부분을 탓하지 않도록 도와줍니다.

요청 기록은 조직 범위로 제한됩니다. 여기에는 요청을 처리한 경로, 결제 상태, 캐시 상태, 그리고 모델 및 키 컨텍스트가 포함됩니다. 이러한 필드들이 함께 위치하므로 세션을 별도의 페이지를 조합할 필요 없이 하나의 이벤트로 읽을 수 있습니다. 동일한 요청 기록은 대시보드에서도 사용할 수 있으며, 이는 콘솔 뷰와 계정 수준 데이터를 비교할 때 도움이 됩니다. Request Console 가이드에서 해당 증거가 어디에 있는지 설명합니다.

예를 들어, 첫 번째 토큰은 빨리 도착했지만 응답이 길어진다면, 나머지 스트림이 문제이므로 ttft_ms가 주요 신호는 아닙니다. 동일한 요청 기록에서 경로와 캐시 상태를 살펴볼 수 있습니다. 요청이 캐시에 적중했는지 아니면 모델로 전달되었는지 확인할 수 있습니다. 어떤 키와 모델 컨텍스트가 연결되었는지도 볼 수 있습니다.

이 정보만으로 전체 상황을 파악할 수는 없지만, 함께 살펴보면 문제의 원인을 찾을 수 있습니다. 느린 세션을 확인할 때 요청 로그에는 필요한 세부 정보가 모두 담겨 있습니다. 결론을 내리기 전에 ttft_ms를 다른 요청 수준의 증거와 비교하십시오.

동일한 워크플로우는 요청이 실패하거나 잔액 부족으로 일시 중지될 때도 도움이 됩니다. 요청 기록에는 결제 상태가 포함되어 있으므로 실패 원인이 미스터리가 아닙니다. 충전 항목은 대화창 옆에 있으므로 수정 작업이 같은 창 내에서 이루어집니다. 다음 단계를 찾기 위해 세션을 떠날 필요가 없으므로, 충전 후 바로 대화를 이어갈 수 있습니다.

잔액이 충분하다면 라우팅, 캐시 상태, 모델 선택으로 넘어갈 수 있습니다. 핵심은 요청 수준의 증거를 순서대로 읽는 것입니다. 먼저 첫 번째 토큰이 언제 도착했는지 묻고, 그다음 어떤 경로가 이를 처리했는지, 그리고 기록에 결제, 캐시, 모델, 키 컨텍스트에 대해 무엇이 적혀 있는지 확인하십시오. 이 순서는 간단하며 콘솔이 데이터를 제시하는 방식과 일치합니다.

제한 사항

스트리밍은 처리량(throughput)이 아닌 진행 상황을 보여줍니다. 스트림이 빠르게 시작되어도 완료까지는 오래 걸릴 수 있기 때문입니다. 첫 번째 토큰이 빠르다고 해서 전체 요청이 빠른 것은 아닙니다. 첫 번째 토큰 시간은 모델과 경로에 따라 다릅니다. 모델 간 비교보다는 모델 내에서 비교하십시오.

ttft_ms의 변화는 프롬프트뿐만 아니라 라우팅, 캐시 상태, 모델 선택을 반영할 수 있습니다. ttft_ms를 요청 로그의 하나의 신호로 취급하십시오. 결론을 내리기 전에 다른 요청 수준의 증거와 함께 고려하십시오. 이는 세션을 읽기 위한 인터페이스이지 모델 순위를 매기기 위한 벤치마크가 아닙니다.

콘솔은 채팅 스트림을 작업 실행기(job runner)로 바꾸지 않습니다. 장기 실행 이미지 작업이 있다면 채팅 스트림을 열어두는 대신 비동기 이미지 생성 작업 가이드를 사용하십시오. 스트리밍 인터페이스는 토큰 단위로 도착하는 응답을 위한 것입니다. 비동기 가이드는 채팅 응답 외부에서 실행되는 작업을 위한 것입니다.

또한 요청 수준의 증거는 조직 범위로 제한되며, 요청을 주변 계정 컨텍스트와 연결한다는 점을 기억하십시오. 이는 하나의 요청을 글로벌 벤치마크로 취급해서는 안 된다는 의미이기도 합니다. 기록은 해당 요청에 대한 라우팅, 결제 상태, 캐시 상태, 모델 및 키 컨텍스트를 다룹니다. 이는 진단을 시작하기에 좋은 곳이지만, 공급자나 모델의 순위를 매기는 것은 아닙니다. 세션을 비교할 때는 동일한 모델과 동일한 경로군 내에서 비교해야 공정한 비교가 가능합니다.

FAQ

기존 콘솔 링크는 여전히 작동하나요?

네. 기존 링크는 계속 작동하며, 기존 대화 내용은 통합 과정에서 보존되었습니다. 수동으로 마이그레이션할 필요가 없습니다. 콘솔 페이지를 즐겨찾기에 추가했다면 그대로 작동합니다.

첫 번째 토큰 시간은 실제로 무엇을 측정하나요?

스트리밍 응답에서 첫 번째 토큰이 도착하는 시점을 측정하며, 콘솔은 이를 인터페이스에 표시하고 요청 로그의 선택적 열인 ttft_ms로 기록합니다. 총 지연 시간이나 처리량을 측정하지는 않습니다.

대화 도중 잔액이 부족하면 어디서 충전하나요?

대화 도중 잔액이 부족해지면 나타나는 대화창 옆의 충전 항목을 사용하십시오. 세션을 떠나지 않고도 잔액 문제를 해결할 수 있습니다. 대시보드의 결제 페이지는 더 광범위한 계정 작업을 위한 곳으로 유지됩니다.

서로 다른 모델 간에 첫 번째 토큰 시간을 비교할 수 있나요?

아니요, 명확한 비교는 어렵습니다. 첫 번째 토큰 시간은 모델과 경로에 따라 다르므로 모델 간 비교보다는 모델 내에서 비교하십시오. ttft_ms를 모델 순위가 아닌 요청 수준의 신호로 사용하십시오.

API 키를 생성하고 대시보드의 새 콘솔에서 세션을 실행해 보세요.