--- title: "클로드를 유저스페이스 IP 스택처럼 굴려서 핑을 보내보면 얼마나 느릴까" published: 2026-05-10T23:02:31.000Z canonical: https://jeff.news/article/2556 --- # 클로드를 유저스페이스 IP 스택처럼 굴려서 핑을 보내보면 얼마나 느릴까 저자는 Claude Code에게 IP 패킷을 직접 읽고 ICMP echo reply를 조립하게 만들어, 말 그대로 LLM을 유저스페이스 IP 스택처럼 동작시켰다. Claude는 IPv4 헤더와 ICMP 체크섬을 손으로 계산해 응답 패킷을 만들었고, 실제 ping은 성공했지만 왕복 시간은 약 42.6초였다. 쓸모는 거의 없지만, “마크다운이 코드이고 LLM이 그 코드를 실행하는 프로세서”라는 장난스러운 실험으로는 꽤 재밌다. - 저자가 Claude Code를 유저스페이스 IP 스택처럼 굴려보는 괴상하지만 재밌는 실험을 함 - 목표는 Claude가 IP 패킷을 직접 읽고, ICMP echo request를 파싱하고, 올바른 echo reply를 만들어 ping에 응답하게 하는 것 - 저자 표현대로 “말도 안 되고, 토큰 낭비지만, 재밌는” 실험임 - 구조는 `/dev/tun0`에서 패킷을 읽고 쓰는 얇은 헬퍼 위에 Claude를 올리는 방식임 - Python 헬퍼는 TUN 장치와 FIFO 입출력을 연결해줌 - Claude는 `READ` 명령으로 raw IPv4 패킷의 hex 문자열을 받고, `WRITE `로 응답 패킷을 돌려보냄 - 중요한 조건은 IP 로직을 라이브러리나 스크립트 없이 Claude의 추론으로 처리한다는 것 ```mermaid sequenceDiagram participant 핑명령 as ping 명령 participant TUN as TUN 장치 participant 헬퍼 as FIFO 헬퍼 participant 클로드 as Claude Code 핑명령->>TUN: ICMP echo request 전송 TUN->>헬퍼: raw IPv4 패킷 전달 헬퍼->>클로드: hex 패킷 제공 클로드->>클로드: IPv4·ICMP 파싱 및 체크섬 계산 클로드->>헬퍼: echo reply hex 작성 헬퍼->>TUN: 응답 패킷 주입 TUN->>핑명령: ICMP echo reply 반환 ``` - Claude가 해야 하는 일은 생각보다 진짜 네트워크 스택스러움 - IPv4 헤더에서 버전, IHL, 전체 길이, TTL, 프로토콜, 체크섬, 출발지·목적지 IP를 파싱함 - 프로토콜이 `0x01`, 즉 ICMP인지 확인함 - ICMP 헤더에서 타입 `0x08` echo request, 코드, 식별자, 시퀀스 번호, payload를 읽음 - 응답 패킷을 만들 때는 원본을 살짝 고치는 수준이지만, 체크섬 때문에 손계산이 필요함 - IP 헤더에서는 TTL을 64로 맞추고, 출발지와 목적지 IP를 뒤집고, 헤더 체크섬을 0으로 둔 뒤 다시 계산함 - ICMP 메시지는 타입을 `08`에서 `00` echo reply로 바꾸고, ICMP 체크섬도 다시 계산함 - 16비트 워드 단위로 더하고, carry를 접고, 1의 보수를 취하는 고전적인 체크섬 알고리즘을 그대로 따라감 > [!IMPORTANT] > 실제 결과는 성공이었다. ping 1개를 보냈고 1개를 받았으며 패킷 손실은 0%였지만, RTT는 42,592.723ms였다. 네트워크가 아니라 편지 왕복에 가까운 속도임. - 예시 실행에서는 84바이트짜리 IPv4 패킷을 받음 - 출발지는 `172.16.0.1`, 목적지는 `172.16.0.2` - ICMP id는 `000d`, sequence는 `0001` - Claude는 IP 헤더 체크섬을 `0x60DD`, ICMP 체크섬을 `0x5CF5`로 계산해 응답 패킷을 조립함 - Haiku 4.5처럼 빠른 모델을 써도 결과는 45초 안팎의 느린 ping임 - 기사에 나온 실제 ping 출력은 `64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=42593 ms` - 왕복 시간 통계도 min/avg/max가 모두 `42592.723ms` - 그러니까 “LLM이 패킷을 처리할 수 있나?”에는 예스, “그걸 네트워크 스택으로 쓰겠나?”에는 당연히 노 - 그래도 이 실험이 재밌는 이유는 LLM 실행 모델의 이상한 경계를 보여주기 때문임 - 마크다운 지시문을 코드처럼 쓰고, LLM을 그 코드를 실행하는 프로세서처럼 다룸 - 저수준 프로토콜 처리도 형식과 절차가 명확하면 어느 정도 따라갈 수 있음을 보여줌 - 동시에 토큰 기반 추론은 마이크로초 단위 네트워크 처리와 완전히 다른 세계라는 것도 숫자로 박아줌 --- ## 기술 맥락 - 이 실험의 핵심 선택은 커널 IP 스택을 우회하고 Claude에게 패킷 처리 절차를 맡긴 거예요. TUN 장치가 IP 패킷을 사용자 공간으로 넘겨주기 때문에, Claude는 운영체제가 평소에 하던 파싱과 응답 생성을 흉내 낼 수 있었어요. - 체크섬을 직접 계산하게 한 이유는 “진짜 프로토콜 처리”인지 확인하려는 거예요. ICMP 타입만 바꾸면 끝나는 게 아니라, IPv4 헤더와 ICMP 메시지의 검증값이 맞아야 커널과 ping 명령이 정상 패킷으로 받아들이거든요. - 여기서 Claude는 빠른 런타임이 아니라 느린 추론 엔진이에요. 그래서 84바이트 패킷 하나를 처리하는 데 42초 넘게 걸렸고, 이 숫자가 실험의 결론을 거의 다 말해줘요. - 그래도 의미가 있는 건, 프로토콜 명세가 충분히 구조화돼 있으면 LLM이 절차적 작업을 따라갈 수 있다는 점이에요. 실무에 쓰자는 얘기가 아니라, 명세·코드·실행의 경계가 어디까지 흐려질 수 있는지 보여주는 데 가까워요. ## 핵심 포인트 - Claude Code가 TUN 장치에서 읽은 IPv4 패킷을 바이트 단위로 파싱 - ICMP echo request를 echo reply로 바꾸고 IP·ICMP 체크섬을 직접 계산 - 실제 ping 결과 1패킷 송수신 성공, RTT는 약 42,592.723밀리초 - Haiku 4.5 기준으로도 네트워크 스택이라 부르기엔 터무니없이 느리지만 실험 자체는 성공 ## 인사이트 이건 실용성보다 경계 실험에 가깝다. LLM이 저수준 프로토콜을 이해하고 형식적으로 맞는 패킷을 만들 수는 있지만, 실행 모델이 토큰 추론인 이상 ‘네트워크 스택’이라는 말이 얼마나 우스꽝스러워지는지도 같이 보여준다.