본문으로 건너뛰기

프로필

Research

Research 프로필 인텔리전스는 BTW.MEDIA 보도의 주제를 비교하는 독자를 위해 인물, 기업, 기관 등 다양한 개체에 대한 취재를 하나로 연결합니다. 이 페이지는 공개 프로필, 관련 이벤트, 증거 패키지, 역할 변화, 운영 현황, 거버넌스 노출, 조직 간 연결, 시장 내 관련성을 비교하면서, 조직과 인물 기록을 일반적인 뉴스 연표와 구분하여 다룹니다. 독자는 헤드라인 뒤에 있는 주제, 그 프로필을 뒷받침하는 증거, 그리고 프로필을 중요하게 만드는 인프라 및 시장 관계를 이해할 수 있습니다. 또한 프로필이 누구 또는 무엇을 대표하는지, 어떤 공개 자료가 이를 뒷받침하는지, 기업·시장·거버넌스 기구·이벤트와 어떻게 연결되는지, 그리고 주제가 변화함에 따라 어떤 변화가 지속적인 관심을 필요로 하는지 확인할 수 있습니다.

RFC 9876: CoAP 레지스트리 번호는 상호운용성 판정이 아니다

IETF

RFC 9876: CoAP 레지스트리 번호는 상호운용성 판정이 아니다

프로토콜에서 가장 작은 숫자가 가장 큰 제도적 오해를 담을 수 있습니다. CoAP 콘텐츠 형식 식별자는 제약 환경 기기가 자신이 보내는 표현을 압축적으로 나타내게 해 줍니다. RFC 9876은 그 번호의 할당이 틀리기 훨씬 어렵게 만들지만, 배포된 두 제품이 바이트를 같게 파싱하고 모든 파라미터를 구현하며 안전하게 실패한다는 것은 보여 주지 않습니다. 거버넌스 과제는 두 기록을 모두 보존하는 것입니다. 번호가 왜 할당되었는지, 그리고 실제 인코더와 디코더가 그것을 사용했을 때 무슨 일이 있었는지.

2026년 9월 24일
RFC 9874: 한 클라이언트의 EPP 삭제가 다른 클라이언트의 DNS를 깨뜨릴 수 있다

IETF

RFC 9874: 한 클라이언트의 EPP 삭제가 다른 클라이언트의 DNS를 깨뜨릴 수 있다

삭제 명령은 보내는 클라이언트에게는 완전히 승인된 작업일 수 있지만, 다른 클라이언트가 관리하는 도메인에는 위험할 수 있습니다. RFC 9874는 이 명령 권한과 운영 영향 사이의 간극을 설명합니다. 따라서 EPP 응답만으로는 부족하며, 의존 관계, DNS 상태, 통지, 복구 기간, 실제 삭제 완료를 기록하는 영수증이 필요합니다.

2026년 9월 24일
Remco van Mook, IPv4 이웃이 없는 IPv4 게이트웨이

리더

Remco van Mook, IPv4 이웃이 없는 IPv4 게이트웨이

IPv4 기본 게이트웨이는 보통 호스트가 ARP로 찾을 수 있는 주소처럼 보입니다. Remco van Mook의 IETF 제안은 그 기대를 뒤집습니다. `192.0.0.11`은 발견해야 할 이웃이 아니라, IPv6가 이미 발견한 이웃을 재사용하라는 지시입니다. 이 경제성은 실재합니다. 새로운 의존성 사슬도 실재합니다.

2026년 9월 24일
네트워크는 루트가 다운되었다고 합의했다. 그러나 크래시를 증명하지는 않았다: RFC 9866

IETF

네트워크는 루트가 다운되었다고 합의했다. 그러나 크래시를 증명하지는 않았다: RFC 9866

RFC 9866은 저전력 네트워크가 현재 라우팅 루트를 더 이상 사용할 수 없다는 조율된 결론에 도달하도록 허용한다. 루트가 여전히 전원이 켜져 있고 물리적 원인이 불명인 상황에서도 이 결론은 운영상 옳을 수 있다. `GLOBALLY DOWN`을 포렌식 판정처럼 다루면 안전한 라우팅 조치와 인과적 증명의 구분이 사라진다.

2026년 9월 24일
John Ousterhout와 클리닝 부채가 된 빠른 쓰기

리더

John Ousterhout와 클리닝 부채가 된 빠른 쓰기

로그 구조 파일 시스템은 작은 쓰기를 긴 순차 전송의 일부로 만들어 거의 무력처럼 보이게 했다. 그 더 깊은 교훈은 비용이 사라졌다는 것이 아니라, 비용이 어디서 돌아오는지—클리닝, 여유 용량, 분류 오류, 복구—를 시스템이 계산해야 한다는 것이다.

2026년 9월 24일
RFC 2350은 문을 묘사했을 뿐, 노크 이후에 일어난 일까지 증명하지 않았다

역사

RFC 2350은 문을 묘사했을 뿐, 노크 이후에 일어난 일까지 증명하지 않았다

CSIRT는 서비스 설명을 아무리 정교하게 공개하더라도 특정 인시던트 자체를 증명하지는 못한다. RFC 2350은 대외 인터페이스를 이해 가능하게 만들었지만, 연락처·서비스 이름·협력 정책을 케이스 증거로 바꾸지는 않았다.

2026년 9월 24일
서버는 세 장의 메일 지도를 그렸지만, 우편함이 존재한다는 증거는 아니었다: RFC 2342

역사

서버는 세 장의 메일 지도를 그렸지만, 우편함이 존재한다는 증거는 아니었다: RFC 2342

RFC 2342는 IMAP 서버가 개인, 타 사용자, 공유 우편함의 명명 규칙을 공개하도록 했다. 접두어와 계층 구분자는 클라이언트가 다음 질문을 어떻게 던져야 하는지 알려줄 수 있었다. 그러나 특정 우편함이 존재하는지, 목록에 나타나는지, SELECT를 받아들이는지, 메시지를 노출하는지, 독자에게 도달하는지는 답해 줄 수 없었다.

2026년 9월 23일
하나의 경로, 네 가지 대수, 그리고 하나의 전염성 있는 미지수: RFC 2215

역사

하나의 경로, 네 가지 대수, 그리고 하나의 전염성 있는 미지수: RFC 2215

네트워크 경로는 많은 수치로 기술될 수 있지만, 그 수치들이 하나의 법칙을 따르지는 않습니다. RFC 2215는 이 구분을 운영 가능한 형태로 만들었습니다. 결손은 논리 OR로 전파되고, 인지 홉은 계수되며, 대역폭과 패킷 크기는 최솟값으로 좁혀지고, 지연은 누적됩니다. 더 중요한 것은, 미지수 기여가 하류에서도 미지수로 남는다는 점입니다. 따라서 합성 값은 자격이 부여된 경로 특성화일 뿐이며, 예약도, 전달된 성능의 측정도, 애플리케이션 결과의 영수증도 아닙니다.

2026년 9월 23일
패킷은 화면과 소리를 담았지만 재생 영수증은 담지 않았다: RFC 2343

역사

패킷은 화면과 소리를 담았지만 재생 영수증은 담지 않았다: RFC 2343

RFC 2343은 MPEG-2 비디오 슬라이스와 오디오 프레임을 하나의 RTP 페이로드에 묶었다. 이 결정은 온디맨드 비디오에 유용한 경계와 시간 관계를 명시적으로 만들었다. 그러나 아무리 완벽한 패킷이라도 도착 여부, 디코더가 올바른 상태를 유지했는지, 누군가 출력물을 실제로 보고 들었는지는 알 수 없었다.

2026년 9월 23일
서비스에 이름이 있었다. 그 이름은 거의 아무것도 증명하지 못했다: RFC 2216

역사

서비스에 이름이 있었다. 그 이름은 거의 아무것도 증명하지 못했다: RFC 2216

1997년 인터넷 공학 커뮤니티는 품질보장(QoS) 서비스에 네임스페이스를 부여했다. 그러나 RFC 2216은 더 어려운 점을 먼저 밝혔다. 서비스 번호는 명세로 들어가는 주소일 뿐이었다. 증명은 이름 이후에 시작되었다. 호출자, 트래픽 계약, 요소의 입장 허가 상태, 패킷 처리 규칙, 요청 병합 방식, 그리고 실제 관찰된 동작에서.

2026년 9월 23일
깨끗한 단일 매치가 감춘 어려운 질문들: RFC 2345와 기업명 조회

역사

깨끗한 단일 매치가 감춘 어려운 질문들: RFC 2345와 기업명 조회

기업명을 입력하면 기업명과 URL이 돌아왔다. RFC 2345는 1998년의 브라우저 애드인과 포트 43 서버를 위해 그 교환을 의도적으로 충분히 작게 만들었다. 경제성이 핵심이었다. 그러나 응답 라인에는 도메인을 누가 등록했는지, 그 이름이 어떤 법인을 가리키는지, 디렉터리가 항목을 어떻게 선정하고 순위를 매겼는지, 무엇을 생략했는지, 누가 페이지를 통제하는지, 사용자가 정상 작동하는 서비스를 받게 될지에 대한 어떤 증명도 담지 않았다. 유용한 방향은 여전히 방향일 뿐이었다.

2026년 9월 23일
지도는 도로가 아니었다: RFC 2333이 NHRP에게 허용한 것—그리고 결코 증명할 수 없었던 것

역사

지도는 도로가 아니었다: RFC 2333이 NHRP에게 허용한 것—그리고 결코 증명할 수 없었던 것

깨끗한 NHRP 캐시 줄은 문제의 끝처럼 보일 수 있다. 그 줄은 IP 목적지를 NBMA 주소에 연결하고 권위 등급과 보유 시간을 담았다. 그러나 RFC 2333은 그 줄을 훨씬 긴 사슬에 놓았다. 라우팅이 먼저 경로를 정해야 했다. NHRP는 그다음 적절한 다음 홉을 해석할 수 있었다. 연결 지향 NBMA 계층은 여전히 회로를 만들어야 했다. 패킷은 여전히 그것을 건너야 했고, 원격 시스템은 여전히 응답해야 했으며, 애플리케이션은 여전히 마무리되어야 했다. 지도가 유용했던 정확한 이유는 그것이…

2026년 9월 23일
RFC 2210: 경로 요약의 신뢰를 무효화하던 비트

역사

RFC 2210: 경로 요약의 신뢰를 무효화하던 비트

RSVP 수신자는 숫자로 가득한 객체를 받을 수 있었습니다: 홉 수, 대역폭, 최소 지연, MTU, 보장 서비스 파라미터. 그러나 RFC 2210은 먼저 단 하나의 비트를 읽도록 요구했습니다. 이 비트가 일반적인 단절을 알리면 ADSPEC의 나머지 값들은 종단 간 설명으로서 신뢰할 수 없게 되었습니다. 이 선택은 드문 규율을 드러냅니다: 네트워크 요약은 시스템이 이를 해석할 자격의 조건까지 함께 보존할 때만 유용합니다.

2026년 9월 23일
리졸버 주소는 리졸버가 아니었다

케이스 파일

리졸버 주소는 리졸버가 아니었다

APNIC Labs가 이중 스택 권위 네임서버를 하나 더 추가하자 테스트당 평균 쿼리 수가 3.43에서 2.57로 떨어졌다. 실험은 원인을 밝히지 못했다. 대신 더 곤란한 사실 하나를 드러냈다. 공용 재귀 리졸버 주소는 흔히 라우팅 핸들일 뿐, 각 결정을 내리는 장비의 충실한 신원이 아니라는 것이다.

2026년 9월 23일
성공한 ESRO 결과가 실패로 끝날 수 있을 때

역사

성공한 ESRO 결과가 실패로 끝날 수 있을 때

ESRO에서 수행자는 작업을 마치고 성공 결과를 보낸 뒤, 호출자가 이미 그 결과를 수용했음에도 실패 표시를 받을 수 있었습니다. RFC 2188은 두 관찰이 모두 참일 수 있는 여지를 남겼습니다. 이 문서의 가장 오래가는 교훈은 잊힌 1990년대 전송 최적화가 아니라 근거에 관한 것입니다. 프로토콜 효율성, 핸드셰이크 설계, 엔드포인트별 지식은 서로 다른 것이며, 한 엔드포인트의 최종 이벤트가 자동으로 다른 엔드포인트의 역사가 되지는 않습니다.

2026년 9월 23일
Adrian Farrel과 컨트롤러에만 존재하는 경로

리더

Adrian Farrel과 컨트롤러에만 존재하는 경로

긍정적인 PCEP 응답은 어떤 라우터도 그 경로를 수락하기 전에 운영자 화면에 깨끗한 경로를 올려놓을 수 있습니다. Adrian Farrel의 PCE 아키텍처가 중요한 이유는 무엇이 실제로 일어났는지—그리고 무엇이 아직 일어나지 않았는지—정확히 말할 수 있게 해주기 때문입니다.

2026년 9월 23일
WebAuthn 원격 클라이언트는 RP ID를 검증할 수 있다. 로컬 권한은 그 검증이 이루어졌음을 증명하지 못한다

케이스 파일

WebAuthn 원격 클라이언트는 RP ID를 검증할 수 있다. 로컬 권한은 그 검증이 이루어졌음을 증명하지 못한다

WebAuthn Level 4의 첫 공개 초안은 원격 데스크톱 로그인을 위한 신중한 인계 방식을 제안합니다. 로컬 브라우저는 원격 기기가 제공한 클라이언트 데이터를 사용할 수 있지만, 오리진별 권한 부여가 선행되어야 합니다. 그 권한은 로컬 기능을 여는 것일 뿐, 이 의식(세리머니)이 의존하는 원격 오리진 판단에 대한 증거를 보존하지 않습니다.

2026년 9월 23일
RFC 2187의 캐시 계층 구조는 거리가 아니라 권한에 관한 것이었다

역사

RFC 2187의 캐시 계층 구조는 거리가 아니라 권한에 관한 것이었다

*parent*와 *sibling*이라는 단어는 인터넷 캐시 계층 구조를 네트워크 전역에 그려진 가계도처럼 보이게 합니다. RFC 2187은 그보다 덜 기하학적이고 더 운영적인 것, 즉 캐시 미스 이후의 처리에 대한 권한 분할을 설명했습니다. 두 종류의 이웃 모두 확인된 히트는 충족할 수 있지만, 캐시되지 않은 객체를 향해 계속 진행하도록 요청받을 수 있는 것은 부모뿐이었습니다. 이 경계 덕분에 계층 구조는 구성된 요청 처리 관계가 되었고, ICP는 가능한 다음 출처를 고르기 위한 제한된 근거만을…

2026년 9월 23일
RFC 2186는 빠른 캐시 힌트와 증명 사이에 엄격한 경계를 그렸다

역사

RFC 2186는 빠른 캐시 힌트와 증명 사이에 엄격한 경계를 그렸다

1997년 ICPv2는 좁은 운영 문제를 다루었다. 웹 캐시는 더 무거운 교환의 지연을 감수하기 전에 이웃을 선택해야 하는 경우가 있었다. 그래서 프로토콜은 불확실성을 빠르고 범위가 제한된 신호로 압축했다. 이 프로토콜의 역사적 관심사는 신호가 무엇을 증명할 수 있는지만큼 무엇을 증명할 수 없는지에도 있다.

2026년 9월 22일
Robin Milner와 탐색이 만들 수 없었던 정리

학계 인사

Robin Milner와 탐색이 만들 수 없었던 정리

증명 택틱은 수천 개의 분기를 탐색하고 성공을 선언할 수 있습니다. LCF 구조에서 그 선언은 승인 사건이 아닙니다. 결정적인 것은 보호된 공리와 추론 규칙 함수 집합을 통해서만 만들어질 수 있는 정리 값입니다. Robin Milner의 영속적 기여는 자동화가 야심적이고 오류 가능한 채로 남도록 두면서, 결과가 정리가 되는 경로를 좁힌 것이었습니다.

2026년 9월 22일