문제 상황 : 대답없는 Cursor AI
어느 날 갑자기 Cursor AI가 응답하지 않는 상황이 발생했다.
네트워크 연결에는 문제가 없었는데, 질의에 대한 응답 기능이 동작하지 않는 것이었다.
이에 순간적인 개발환경의 문제로 판단했다.
원인 발견 : HTTP 프로토콜 버전의 차이
문제 해결을 위해 Cursor AI 공식 홈페이지를 확인해보니, 흥미로운 정보를 발견했다. Cursor AI는 HTTP/2 프로토콜만 정상적으로 지원한다는 내용이었다.
공식 문서에 따르면, Cursor는 AI 기능의 많은 부분이 스트리밍 응답을 처리하기 위해 HTTP/2 프로토콜에 의존하고 있다. HTTP/2가 지원되지 않는 네트워크에서는 코드 인덱싱 실패나 Cursor의 AI 기능 사용 불가와 같은 문제가 발생할 수 있다고 이야기한다.
이 문제를 더 정확히 진단하기 위해 터미널에서 아래 명령어를 실행해보았다.
curl -I --http2 -v https://api2.cursor.sh
#######
## `-I`: HTTP 헤더 정보만 요청
## `--http2`: HTTP/2 프로토콜 사용
## `-v`: 상세한 연결 정보 출력
#######
* Host api2.cursor.sh:443 was resolved.
* IPv6: (none)
* IPv4: 3............
..........
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted http/1.1
........
* subjectAltName: host "api2.cursor.sh" matched certs "api2.cursor.sh"
* issuer: C=KR; O=Somansa; CN=Somansa Root CA
* SSL certificate verify ok.
* using HTTP/1.x
> HEAD / HTTP/1.1
> Host: api2.cursor.sh
> User-Agent: curl/8.7.1
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
........
< access-control-allow-credentials: true
access-control-allow-credentials: true
< access-control-expose-headers: Grpc-Status, Grpc-Message, Grpc-Status-Details-Bin, Content-Encoding, Connect-Content-Encoding, traceparent, backend-traceparent, x-amzn-trace-id, x-request-id
access-control-expose-headers: Grpc-Status, Grpc-Message, Grpc-Status-Details-Bin, Content-Encoding, Connect-Content-Encoding, traceparent, backend-traceparent, x-amzn-trace-id, x-request-id
<
* Connection #0 to host api2.cursor.sh left intact
이 구문은 Cursor AI의 API 서버에 HTTP/2 프로토콜을 사용하여 연결하고, 응답 헤더 정보를 확인하는 명령어다.
이 명령어를 유선/무선 환경에 각각 실행해보니 차이가 드러난다.
확인 결과 :
- 사내 유선망: HTTP/1.x 사용 (응답 헤더에 `HTTP/1.1` 표시)
- 사내 무선망: HTTP/2 사용 (응답 헤더에 `HTTP/2` 표시)
HTTP/2를 사용하는 무선망으로 접속해보니 Cursor AI가 정상적으로 동작했다!
임시 해결책 : 무선망 사용
이후 HTTP/2 환경이 보장된 무선망에서만 작업을 진행했다.
하지만 개발 업무에서 환경에 따라 IDE 기능이 제한된다는 것은 매우 중요한 제약사항이었다. 여기저기 어떤 환경에서 업무가 진행될지 모르는 개발자들에게 치명적인 요소아닌가? 라는 생각이 머리를 떠나지 않는다. 곧장 이 문제를 hedge 할 수 있는 방안을 찾아야 겠다는 생각이 들었다.
근본적인 해결책: HTTP/2 제한 옵션 설정
현 상황에서 더 나은 해결책을 찾아보니, Cursor AI 옵션에서 HTTP/2 사용을 제한하는 설정이 있다는 것을 발견했다.
공식 문서에 따르면, Cursor는 이제 HTTP/1.1 폴백(fallback) 기능을 제공하고 있다. 이 옵션은 속도는 느리지만 Cursor의 AI 기능을 사용할 수 있게 해준다.
이 옵션을 활성화하는 방법:
이 옵션을 설정한 후 HTTP/1.x 환경에서 테스트해보니 정상적으로 동작했다.
- `CMD/CTRL + ,`를 눌러 설정을 연다.
- `HTTP/2`를 검색한다.
- `Disable HTTP/2` 옵션을 활성화한다.
HTTP/1.x와 HTTP/2의 차이
이 문제를 이해하기 위해서는 HTTP/1.x와 HTTP/2의 차이를 알아야 한다.
HTTP/1.x: 외길 1차선 도로
- 한 번에 한 대의 차만 통행 가능 (단일 연결에서 한 번에 하나의 요청만 처리)
- 차량이 지나갈 때마다 통행료를 내야 함 (헤더 정보가 반복적으로 전송되어 대역폭 낭비)
- 교통 체증이 자주 발생 (페이지 로딩 속도가 상대적으로 느림)
HTTP/2: 다차선 고속도로
- 여러 차량이 동시에 통행 가능 (단일 연결에서 여러 요청을 동시에 처리)
- 통행료를 한 번만 내면 됨 (헤더 압축으로 대역폭 절약)
- 교통 흐름이 원활함 (서버 푸시 기능으로 성능 향상)
- 목적지까지 빠르게 도착 (페이지 로딩 속도가 빠름)
Cursor AI는 마치 8차선 고속도로를 필요로 하는데, 우리 사내 유선망은 외길 1차선 도로와 같은 HTTP/1.x를 사용하고 있었던 것이다.
왜? 프로토콜 사용을 제약하는걸까?
Cursor AI가 HTTP/2를 기본으로 하고 HTTP/1.1을 옵션으로 제공하는 이유는 어떤 이유에서 일까?
성능 최적화
- HTTP/2는 멀티플렉싱, 헤더 압축, 서버 푸시 등 성능 향상 기능을 제공
- AI 기능은 대용량 데이터 스트리밍이 필요하므로 HTTP/2가 더 효율적
- 기본적으로 최적의 성능을 제공하기 위해 HTTP/2를 기본값으로 설정
리소스 효율성
- HTTP/1.1 폴백은 서버 리소스를 더 많이 소모
- 모든 사용자에게 HTTP/1.1을 기본으로 제공하면 서버 부하 증가
- 필요한 사용자만 HTTP/1.1을 사용하도록 옵션화하여 리소스 효율성 확보
기술적 복잡성
- 자동 감지 기능은 추가적인 개발 리소스와 복잡성 필요
- 현재 단계에서는 명시적 옵션 설정이 더 간단하고 안정적인 접근법
Fallback 메커니즘의 중요성
이 사례는 소프트웨어 개발에서 "Fallback" 메커니즘의 중요성을 보여준다. Fallback은 기본 기능이 실패할 경우 대체 기능을 제공하는 메커니즘이다. Cursor AI가 HTTP/2를 지원하지 않는 환경에서도(에서라도..) 작동할 수 있도록 Fallback 옵션을 제공한 것은 좋은 설계 결정이었다.
8차선 고속도로가 공사 중이거나 막혀있을 때 임시로 1차선 도로를 통해 통행할 수 있게 하는 것과 같다. 비록 속도는 느리지만, 목적지까지 도달할 수 있는 방법을 제공한다.
공식 문서에 따르면, Cursor 팀은 향후 자동 감지 및 폴백 기능을 추가할 계획이라고 한다. 이는 사용자 경험을 크게 향상시키는 좋은 방향이라고 생각한다.
Cursor AI의 현재 접근법은 "완벽보다는 실용성"을 선택한 것으로 보인다. 모든 사용자에게 완벽한 경험을 제공하기보다는, 대부분의 사용자에게 최적의 경험을 제공하고, 필요한 사용자만 추가 설정을 하도록 하는 전략적 선택으로 보인다. 이는 많은 소프트웨어 제품이 채택하는 점진적 개선 접근법으로, 향후 자동 감지 기능 추가는 제품의 성숙도가 높아짐에 따른 자연스러운 발전 과정일 것이다.
UX와 기술적 제약의 균형
이 경험은 나의 개발 가치관인 "좋은 시스템은 사용자가 아무것도 몰라도 사용할 수 있어야 한다"라는 관점과 기술적 제약 사이의 균형점에 대한 생각을 불러일으킨다. Cursor AI가 HTTP/2만 지원한다면, 사용자에게 이 제약사항을 명확히 알려주고, 가능한 경우 자동으로 적절한 설정을 적용하는 것이 좋을 것 같다. 하지만 현재처럼 옵션으로 제공하는 것도 사용자가 자신의 환경에 맞게 조정할 수 있는 유연성을 제공한다.
이러한 기술적 세부사항을 몰라도 소프트웨어를 사용할 수 있어야 한다는 것은 이상적이지만, 때로는 이러한 지식이 문제 해결에 큰 도움이 될 수 있다. 개발자로서 이러한 기술적 배경을 이해하는 것은 매우 중요하다.
이 경험을 통해 네트워크 프로토콜의 차이가 실제 개발 환경에 미치는 영향과, 소프트웨어가 다양한 환경에서 작동할 수 있도록 설계하는 것의 중요성을 배웠다. 마치 외길 1차선 도로에서 8차선 고속도로로 이어지는 여정처럼, 기술의 발전은 우리의 개발 환경을 더욱 효율적으로 만들어주는 것이다.
근데 이걸어쩌나... HTTP\3 알아?
