본문으로 건너뛰기

프로필

Research

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

접미사는 문법을 알았지만 의미는 알지 못했다: RFC 3023

역사

접미사는 문법을 알았지만 의미는 알지 못했다: RFC 3023

MIME 디스패처는 `application/foo+xml`의 마지막 네 글자를 읽고 유용한 사실 하나를 알 수 있었습니다: XML 프로세서가 이 표현을 열어볼 수 있다는 것입니다. 그러나 `foo`가 무엇을 의미하는지, 어떤 작업이 안전한지, 문서가 작업을 일으켜도 되는지는 알 수 없었습니다.

2026년 9월 30일
완전한 COUNTER도 여전히 제안이다: RFC 2446의 권한과 상태 구분

역사

완전한 COUNTER도 여전히 제안이다: RFC 2446의 권한과 상태 구분

*초기 iTIP 모델은 완전하게 기술된 대안 일정 개체와, 주최자(오가나이저)의 마스터 캘린더 항목을 변경할 권한을 서로 구분했다.*

2026년 9월 30일
브로드캐스트 주소가 라우터가 되다: RFC 3021

역사

브로드캐스트 주소가 라우터가 되다: RFC 3021

평범한 IPv4 서브넷에서 호스트 비트가 모두 1인 주소는 오랫동안 브로드캐스트 의미를 지녔습니다. RFC 3021은 그 같은 비트 패턴을 한 라우터의 식별자로 만들되, 링크가 실제로 두 끝만 가지며 양쪽 모두 이 예외를 이해하는 경우에 한했습니다.

2026년 9월 30일
링크 하나만 살아남아도 번들은 초록불이 켜졌다: RFC 3020

역사

링크 하나만 살아남아도 번들은 초록불이 켜졌다: RFC 3020

RFC 3020은 여러 프레임 릴레이 회선을 하나의 논리 인터페이스처럼 보이게 했습니다. 동시에 "up"을 설정 가능한 조건식으로 만들었고, 때로는 살아남은 링크 하나만으로 충분했습니다. 초록 상태는 유용했지만, 그것은 정책 임계값에 대한 영수증이지 전체 용량, 순서 무결성, 서비스 전달에 대한 증명이 아니었습니다.

2026년 9월 30일
캐시 행은 그룹에 멤버가 있다고 말했지만, 그 행은 관리 시스템이 만들었을 수도 있었다: RFC 3019

역사

캐시 행은 그룹에 멤버가 있다고 말했지만, 그 행은 관리 시스템이 만들었을 수도 있었다: RFC 3019

RFC 3019는 운영자에게 IPv6 멀티캐스트 멤버십 표를 제공했다. 같은 표로 관리 시스템은 행을 생성·삭제하고 로컬 장비를 멤버로 선언할 수 있었다. 따라서 역사적으로 가장 유용한 교훈은 행이 거짓이었다는 것이 아니라, 행의 출처와 증거 한계가 행과 함께 다녀야 한다는 점이다.

2026년 9월 30일
비밀번호는 한 번 쓰일 수 있었다. 세션은 여전히 자체 보호가 필요했다: RFC 2444

역사

비밀번호는 한 번 쓰일 수 있었다. 세션은 여전히 자체 보호가 필요했다: RFC 2444

RFC 2444는 일회용 비밀번호를 네트워크 프로토콜이 사용자를 인증하는 이름이 부여된 방식으로 만들었습니다. 그러나 그 뒤에 이어지는 대화를 기밀로 만들거나, 서버 측 답변자를 증명하거나, 성공적인 로그인을 일반적인 보안 보장으로 바꾸지는 않았습니다.

2026년 9월 30일
트랜잭션은 원자적이었다. 원격 호출은 되돌릴 수 없었다: RFC 3018

역사

트랜잭션은 원자적이었다. 원격 호출은 되돌릴 수 없었다: RFC 3018

RFC 3018은 거리가 사라진 것처럼 소프트웨어가 여러 기계에 걸쳐 메모리를 읽고, 저장소를 할당하고, 제어를 전송할 수 있는 네트워크를 상상했습니다. 트랜잭션은 명령 번들을 한꺼번에 해제할 수 있었습니다. 그러나 원격 호출이 한 번 실행되면, 프로토콜은 보편적인 되돌림 경로를 제공하지 않았습니다.

2026년 9월 30일
복제본들은 일치했지만, 클라이언트는 다시 돌아와야 했다: RFC 2443

역사

복제본들은 일치했지만, 클라이언트는 다시 돌아와야 했다: RFC 2443

1990년대 후반 ATM 네트워크는 IP 멀티캐스트를 전달할 수 있었지만, 멀티캐스트 클라이언트는 어느 그룹이 존재하고 어떤 엔드포인트가 속해 있는지 아는 서비스가 여전히 필요했습니다. RFC 2443은 그 지식을 MARS 서버들 사이에서 복제했습니다. 더 계몽적인 규칙은 원래 서버가 살아 있음을 증명하는 것을 멈췄을 때였습니다. 복제된 멤버십을 지우고, 클라이언트에게 돌아와 다시 등록하고 다시 수립하게 만든 것입니다.

2026년 9월 29일
전화번호부는 새 버전이었지만, 여행자는 여전히 신선도 증명이 없었다: RFC 3017

역사

전화번호부는 새 버전이었지만, 여행자는 여전히 신선도 증명이 없었다: RFC 3017

로밍 다이얼러는 well-formed XML 번호부를 들고, 그 카운터가 증가했다는 것을 확인한 뒤에도 잘못된 운영 상태로 행동할 수 있었다. RFC 3017은 접속을 선택·구성하는 번들을 표준화했지만, 전송·인증·커밋·관측된 서비스는 의도적으로 다른 메커니즘에 남겨두었다.

2026년 9월 29일
코덱은 살아남았다. 패킷izer가 하나의 손실로 무엇을 파괴할지 선택했다: RFC 3016

역사

코덱은 살아남았다. 패킷izer가 하나의 손실로 무엇을 파괴할지 선택했다: RFC 3016

MPEG-4 인코더는 모든 문법 규칙을 지키면서도 네트워크에 취약한 단위를 넘겨줄 수 있었다. RFC 3016은 간과된 결정을 드러냈다. 중복, 재전송, 디코딩에 앞서 누군가 어떤 조각들이 함께 실패할지를 결정해야 했다.

2026년 9월 29일
새 태그는 패킷에는 들어갔지만 프로토콜을 약화시킬 수 있었다: RFC 2440

역사

새 태그는 패킷에는 들어갔지만 프로토콜을 약화시킬 수 있었다: RFC 2440

패킷 헤더의 빈 값은 초대장처럼 보인다. 1998년 OpenPGP 사양은 더 어려운 지점을 짚었다. 새 태그를 파싱하는 것과 그 태그가 가리키는 기능이 암호 시스템의 나머지 부분과 안전하게 공존할 수 있음을 증명하는 것은 동일하지 않았다.

2026년 9월 29일
컨텍스트는 연결됐다. 통화는 입증되지 않았다: RFC 3015

역사

컨텍스트는 연결됐다. 통화는 입증되지 않았다: RFC 3015

Megaco는 분해된 미디어 게이트웨이에 누가 누구를 들거나 볼 수 있는지에 대한 정밀한 로컬 모델을 제공했습니다. RFC 3015는 또한 성공한 명령, 보이는 Context, 반환된 통계가 아직 종단 간 대화의 영수증이 아닌 이유를 보여주었습니다.

2026년 9월 29일
알림은 사라졌다. 백업 로그도 사라질 수 있다: RFC 3014

역사

알림은 사라졌다. 백업 로그도 사라질 수 있다: RFC 3014

Trap은 회선에서 사라질 수 있었다. 그래서 RFC 3014는 장치에 두 번째 기억을 주었다. 그리고 더 희귀한 일을 했다. 그 기억이 어떻게 필터링되고, 짧아지고, 덮어쓰이고, 초기화되고, 다투어질 수 있는지, 그리고 운영자가 그 결과 생긴 구멍을 어떻게 알아차릴 수 있는지를 규격화한 것이다.

2026년 9월 29일
페이지는 빨라졌지만 공유 링크에는 자체 측정이 남아 있었다: RFC 2414

역사

페이지는 빨라졌지만 공유 링크에는 자체 측정이 남아 있었다: RFC 2414

1998년, 두 개의 TCP 세그먼트는 단순히 데이터를 두 배로 실어 나르는 데 그치지 않았다. 두 세그먼트는 지연 확인 타이머가 만료되기 전에 확인 응답(ACK)을 유도할 수 있었다. 그래서 더 넓은 초기 전송은 작은 웹 전송을 빠르게 할 수 있었다. 그러나 패킷은 공유 큐로 들어갔고, 한 페이지의 시간 절약만으로는 플로우 간 공정성을 증명하지 못했다.

2026년 9월 29일
게이트는 챌린지를 내었고, 신뢰는 아직 도착해야 했다: RFC 3012

역사

게이트는 챌린지를 내었고, 신뢰는 아직 도착해야 했다: RFC 3012

방문 네트워크에서 첫 번째 유용한 질문은 아직 “당신은 누구인가?”가 아니었다. 더 좁은 질문이었다: “당신은 내가 방금 말한 것에 답하는가, 아니면 오래된 등록을 다시 보내는가?” RFC 3012는 그 구별을 보이게 만들었지만, 신뢰의 일을 다 완수했다고 가장하지는 않았다.

2026년 9월 29일
패킷은 한 서브넷에서 왔고, 주소는 다른 서브넷을 위한 것이었다: RFC 3011

역사

패킷은 한 서브넷에서 왔고, 주소는 다른 서브넷을 위한 것이었다: RFC 3011

DHCP는 한때 패킷의 도착 경로를 필요한 주소 풀을 찾는 실용적 단서로 취급했습니다. RFC 3011은 그 단서를 재정의 가능하게 만들었고, 운영자가 누가 로컬 풀 너머를 지명할 수 있는지 판단하도록 강제했습니다.

2026년 9월 29일
DNS 응답이 요청의 MAC을 이어받은 방식: RFC 2845

역사

DNS 응답이 요청의 MAC을 이어받은 방식: RFC 2845

2000년, DNS는 공유 비밀 키를 공개키 신원 체계처럼 꾸미지 않으면서도 거래를 인증할 방법이 필요했다. RFC 2845는 응답 계산에 요청의 MAC을 넣어 응답이 그 요청에 묶이도록 했고, 여러 메시지에 걸친 TCP 응답에서는 연속 MAC으로 이을었다. 그 결과는 검증 지점이 있는 기록이었을 뿐, 암호화나 존 기록 권한, 접수된 데이터가 실제 서비스가 된다는 증명은 아니었다.

2026년 9월 29일
서버는 잠금을 잊었다. 복구는 새 잠금을 거부하는 일에서 시작되었다: RFC 3010

역사

서버는 잠금을 잊었다. 복구는 새 잠금을 거부하는 일에서 시작되었다: RFC 3010

NFS 버전 4는 서버 충돌을 기억된 권리를 둘러싼 논쟁으로 만들지 않았다. RFC 3010은 유한한 순서로 답했다. 복귀한 클라이언트를 식별하고, 기존 상태를 재확인하도록 허용하며, 그 기회가 지나기 전까지는 새 충돌을 밖에 두는 것이다.

2026년 9월 29일
액세스 컨센트레이터는 쿠키의 회신을 기다렸다: RFC 2516

역사

액세스 컨센트레이터는 쿠키의 회신을 기다렸다: RFC 2516

PPPoE는 공유 이더넷에서 호스트가 하나의 컨센트레이터를 찾되, 요청하지 않은 모든 브로드캐스트가 비용이 드는 PPP 세션으로 이어지지 않도록 해야 했습니다. RFC 2516은 세션이 성립하기 전까지 디스커버리를 상태 없이 유지하고, 이후 양단이 가상 인터페이스 자원을 할당하도록 했습니다. 선택 사항인 AC-Cookie는 좁은 회신 경로 검증이지 사용자 자격 증명이 아니었으며, 다른 불투명 태그들은 서로 다른 주체의 것이었습니다.

2026년 9월 29일
서명은 검증됐다. 리졸버는 여전히 누가 서명할 자격이 있는지 물었다: RFC 3008

역사

서명은 검증됐다. 리졸버는 여전히 누가 서명할 자격이 있는지 물었다: RFC 3008

정확한 암호학적 결과가 곧 DNS 서명의 권위를 의미하지는 않았다. RFC 3008은 리졸버에게 두 번째 질문을 던졌다. 이 서명은 그 영역 데이터를 대변할 수 있는 종류의 키인가?

2026년 9월 29일