LLM 서비스의 통신은 겉보기엔 “요청 보내고 응답 받는 API”지만, 실제로는 다음 요구가 겹칩니다. 체감 속도(TTFT) : 첫 토큰을 빨리 보여주고 싶다 긴 응답 시간 : 수 초~수십 초 동안 응답이 이어진다 취소/중단 : 생성 중 cancel이 자주 필요하다(비용과 UX) 이벤트 : tool-call, progress, usage, error 같은 상태 이벤트를 흘려야 한다 대규모 동시성 : 연결 유지 비용, LB idle timeout, 재연결 폭주 등 운영 이슈 여기서 흔히 후보로 올라오는 게: 일반 HTTPS(요청-응답) SSE(Server-Sent Events, 서버→클라 스트리밍) WebSocket(양방향 지속 연결) 중요한 포인트 하나: SSE와 WebSocket도 결국 TLS 위에서 동작 합니다. 즉 “HTTPS vs SSE vs WebSocket” 비교는 엄밀히 말해 (A) 일반 HTTPS 요청-응답 vs (B) HTTPS 위 SSE 스트림 vs (C) TLS 위 WebSocket(wss) 비교로 보면 됩니다. 1) 세 가지의 성격을 한 문장으로 정리 방식 한 줄 정의 LLM에 잘 맞는 상황 일반 HTTPS(요청-응답) “보내고, 끝나면 한 번에 받기” 짧은 응답 / 최대 처리량 / 운영 단순 SSE “요청 1번 → 서버가 이벤트/토큰을 계속 흘려줌(단방향)” 토큰 스트리밍 UX / 상태 이벤트 WebSocket “하나의 연결로 양방향 메시지 계속 주고받기” 세션형 에이전트/실시간 상호작용 2) LLM 통신에서 중요한 평가 기준 LLM 통신은 “RPS(초당 요청 수)”보다 아래가 더 중요해지는 순간이 많습니다. 동시 요청(활성 생성) 수 = 평균 생성 시간 × 유입률 연결 유지 비용 = 동시 연결 수 × (FD/메모리/버퍼/keepalive) 재연결 폭주 : 장애나 네트워크 흔들림에서 reconnect storm 취소 전파 : 사용자가 취소하면...
# 바이브코딩 을 전제로한 모델별 사용감(주관적!) 요즘은 ハッシュタグ # gemini 가 대세 인 듯 많은 포스팅이 난무하는데요.. 각 ai는 쓰임새가 다르니 하나만 몰빵하지 않는 것을 추천합니다. 게다가 많은 분들이 모델 보다 툴을 평가하시는데.. 바이브코딩용 툴은 거의 ハッシュタグ # electron 프로젝트 기반이고 이 electron 은 다시 ハッシュタグ # chromium 프로젝트 기반이라 뿌리는 모두 같다고 생각하시면 됩니다. 그래도 조금씩은 차이가 있지만 요즘같은 바이브코딩 시대에는 스스로 ハッシュタグ # mcp 서버를 바이브코딩으로 만들어 넣으면 툴의 차이는 0이 되어버리는 것이죠. ( ハッシュタグ # antigravity 가 나오기 전까진 mcp로 ハッシュタグ # vscode 에서 브라우저 컨트롤 했거든요..) 때문에 툴 비교는 전혀 무의미한게 아닌가 싶습니다. 저는 모델이 심각하게 차이가 나는 거 같아서 설명을 좀 드릴까 하는데요. "이게 맞다" 가 아니라 "이런 느낌이었다" 인 것이므로 어디까지나 참고해주시구요, 사람마다 대화 방식과 만족감이 다르니 자신에게 맞는 모델을 쓰시기를 권합니다. 1. ハッシュタグ # gpt5 .1 설명은 잘하는데, 산으로 많이감. 복잡해지면 딴짓을 많이 함. 일부러 지정 안해도 task list를 만들어서 처리해 주는 부분은 마음에 듬. 폴더내 문서 정리 등은 탁월. 2. ハッシュタグ # claude sonnet 4.5 내 요청을 일단 정리해서 보여줌. 그에 맞는 처리를 해줌. 코드가 깔끔. 리팩토링 잘해줌. 세션내 토큰 허용량이 gemini보다는 작다는 느낌. 자주 메모리에서 날렸는지 확인이 필요. 디자인은 좀 떨어짐. 우선 gemini로 프론트 만들고 claude로 코드를 완성시키는게 좋은 듯. 3. ハッシュタグ # gemini3 이넘 때문에 이 글을 쓰게 된건데.. 코드를 잘 짜는 것 처럼 보이지만 사용자를 기만함. ...