요약하자면 ASN.1, D 언어, 그리고 컴파일러 자체에 대해 이야기하고 싶었음
하지만 일관된 형식을 찾지 못해 관련된 생각들을 모아 블로그 글로 묶었음
완성도는 높지 않지만, 짧게 다루기 어려운 주제라 양해 바람
교차 예시(intersection example)가 의도한 대로 동작하지 않는 것 같음
수학적으로 보면 {0} ∪ ({2} ∩ {4,5,6,7,8}) = {0}이므로 결과적으로 단일 값만 허용됨
D 언어 이야기를 꺼내면 Walter Bright를 소환하는 셈임
개인적으로 D는 정말 좋아하지만, 현실적으로는 Go와 Rust가 훨씬 더 널리 쓰이고 있음
나도 ASN.1 데이터를 다뤄본 적이 있는데, 특히 인증서 관련 작업이 고통스러웠음
글쓴이의 고생에 깊이 공감함
글을 정말 재미있게 읽었음
D를 사랑하지만 오랫동안 손을 놓고 있었음
예전에 파서와 프로토콜 구현을 해본 경험이 있어 더욱 흥미로웠음
블로그는 결국 자신의 공간이니, 본인 방식대로 계속 이어가길 바람
“OMG ASN.1”이라니, 정말 반가운 주제임
인터넷이 성장하던 시절, IETF가 프로토콜을 발전시키던 때를 기억함
당시 기업들은 인터넷에 관심이 없었고, 학계와 IETF가 주도했음
하지만 기업들이 돈이 된다고 깨닫자 Protocol Wars 가 시작됨
ASN.1은 그 전쟁의 산물이자 기업 문화와 학문 문화의 충돌을 보여주는 사례임
기업은 ‘레시피 문화’, 학계는 ‘기능 문화’로 비유할 수 있음
이 사고방식의 차이는 오늘날 AI 개발 문화에도 시사점을 줌
예전에 영화 Father of the Bride를 보다가 X.25 네트워킹 이야기가 나와서 깜짝 놀랐음
그때 인터넷이 아닌 “CN=wikipedia, OU=org, C=US” 같은 주소 체계로 갔을 수도 있다고 생각하니 아찔했음
“OMG ASN.1”을 내 다음 밴드 이름으로 정해야겠다는 생각이 들었음
이야기의 일부는 맞지만, 주된 행위자를 ‘기업’으로 표현한 건 다소 부정확함
실제로는 ITU와 ISO가 중심이었음
이후 90년대 후반에는 또 다른 ‘프로토콜 전쟁’이 있었고, 이번엔 IETF가 졌음
이 전쟁은 인터넷의 초기 상업화(en-shittification) 과정이기도 했음
ISO는 완벽을 추구하다 느려졌고, IETF는 “나중에 고치자”는 태도로 빠르게 움직였음
그 결과 프로토콜이 굳어버리는 문제를 겪었음
또 1990년대 C용 ASN.1 구현이 형편없었던 것도 문제였음
기업 관점이란 결국 메인프레임 관점이었다는 점이 핵심임
터키 속담에 “이건 사람이 쓸 물건이 아님!”이라는 표현이 있음
이 말을 디자인 철학의 모토로 삼고 싶음
또한 “판결을 내린 자가 직접 칼을 휘둘러야 한다”는 Game of Thrones의 대사처럼, 스펙을 만든 사람은 직접 파서를 구현해야 함
실제 작동하는 파서와 테스트가 함께 제출되어야 스펙이 승인되는 식으로 바뀌면 품질이 훨씬 좋아질 것 같음
D 언어를 정말 좋아함
Raylib만 의존해 vim 스타일 텍스트 에디터를 직접 구현 중임
D의 장점은 다음과 같음
어디서든 unit test를 작성할 수 있음
version(unittest) 블록으로 테스트 전용 코드 관리가 쉬움
enum, union, assert, 계약 프로그래밍 등 언어적 지원이 훌륭함
문서를 참고하거나 ChatGPT에 물어보면 항상 우아한 해결책을 찾을 수 있었음
D는 나에게 달콤쌉싸름한 언어임
설계 철학적으로 완벽에 가깝지만, 도구와 생태계가 Rust나 Go 수준이었다면 훨씬 성공했을 것임
D의 기능은 좋지만 점점 언어가 시끄러워지는(noisy) 경향이 있음
Phobos 표준 라이브러리는 작은 불편이 너무 많아 결국 포기했음
새 버전인 Phobos V3가 진행 중이지만 인력이 적어 기대 반, 걱정 반임
“ASN.1이 복잡하다고 말한 적 있던가?”
스키마와 데이터 포맷 모두 복잡하지만, 대부분은 무시 가능한 복잡성임
나는 ASN.1 스키마 표기법을 쓰지 않고, 직접 DER 구현체를 C로 작성했음
DER은 표준 인코딩 중 유일하게 쓸 만하다고 생각함
또한 DSER, SDSER, TER 같은 자체 인코딩 포맷도 만들었음 ANY DEFINED BY 같은 구조도 여전히 유용하게 사용 중이며,
효율적인 인코딩을 위해 OBJECT IDENTIFIER RELATIVE TO라는 비표준 기능도 추가했음
나도 ASN.1 컴파일러를 만들어본 경험이 있음
X.681~X.683의 일부 기능만 구현했지만, 한 번의 코덱 호출로 전체 인증서를 재귀적으로 디코딩할 수 있게 했음
ASN.1은 단순한 문법이 아니라 강력한 타입 시스템임
과소평가받지만 정말 멋진 기술임
예전에 Swift용 ASN.1 컴파일러를 만든 적이 있음 ASN1Codable 프로젝트로, Heimdal의 libasn1을 활용해
ASN.1을 JSON AST로 변환해 파싱을 단순화했음
libasn1의 README에는 ASN.1에 대한 은근한 혐오감이 느껴짐
“JSON으로 바꾸자”는 말은 결국 상처받은 개발자의 외침 같음 😄
이상하게도 ASN.1 작업이 즐겁게 느껴짐
언젠가 Rust용 ASN.1 컴파일러를 직접 만들어보고 싶음
현재 Rust 구현체들은 대부분 derive 매크로나 수동 체이닝 방식이라 아쉬움
일반적으로 표준을 구현할 때는 80% 기능을 20% 시간에 완성하지만,
ASN.1의 나머지 20%는 평생이 걸릴 수도 있음
예전에 Netscape 코드베이스의 ASN.1 파서를 확장해 PKCS#12를 지원했음
RSA 표준과 ASN.1 정의를 너무 깊이 알게 되어 후회했지만,
블로그 작성자의 끈기와 약간의 마조히즘에는 존경을 보냄
Hacker News 의견
요약하자면 ASN.1, D 언어, 그리고 컴파일러 자체에 대해 이야기하고 싶었음
하지만 일관된 형식을 찾지 못해 관련된 생각들을 모아 블로그 글로 묶었음
완성도는 높지 않지만, 짧게 다루기 어려운 주제라 양해 바람
수학적으로 보면
{0} ∪ ({2} ∩ {4,5,6,7,8}) = {0}이므로 결과적으로 단일 값만 허용됨개인적으로 D는 정말 좋아하지만, 현실적으로는 Go와 Rust가 훨씬 더 널리 쓰이고 있음
글쓴이의 고생에 깊이 공감함
D를 사랑하지만 오랫동안 손을 놓고 있었음
예전에 파서와 프로토콜 구현을 해본 경험이 있어 더욱 흥미로웠음
“OMG ASN.1”이라니, 정말 반가운 주제임
인터넷이 성장하던 시절, IETF가 프로토콜을 발전시키던 때를 기억함
당시 기업들은 인터넷에 관심이 없었고, 학계와 IETF가 주도했음
하지만 기업들이 돈이 된다고 깨닫자 Protocol Wars 가 시작됨
ASN.1은 그 전쟁의 산물이자 기업 문화와 학문 문화의 충돌을 보여주는 사례임
기업은 ‘레시피 문화’, 학계는 ‘기능 문화’로 비유할 수 있음
이 사고방식의 차이는 오늘날 AI 개발 문화에도 시사점을 줌
그때 인터넷이 아닌 “CN=wikipedia, OU=org, C=US” 같은 주소 체계로 갔을 수도 있다고 생각하니 아찔했음
실제로는 ITU와 ISO가 중심이었음
이후 90년대 후반에는 또 다른 ‘프로토콜 전쟁’이 있었고, 이번엔 IETF가 졌음
ISO는 완벽을 추구하다 느려졌고, IETF는 “나중에 고치자”는 태도로 빠르게 움직였음
그 결과 프로토콜이 굳어버리는 문제를 겪었음
또 1990년대 C용 ASN.1 구현이 형편없었던 것도 문제였음
터키 속담에 “이건 사람이 쓸 물건이 아님!”이라는 표현이 있음
이 말을 디자인 철학의 모토로 삼고 싶음
또한 “판결을 내린 자가 직접 칼을 휘둘러야 한다”는 Game of Thrones의 대사처럼,
스펙을 만든 사람은 직접 파서를 구현해야 함
실제 작동하는 파서와 테스트가 함께 제출되어야 스펙이 승인되는 식으로 바뀌면 품질이 훨씬 좋아질 것 같음
D 언어를 정말 좋아함
Raylib만 의존해 vim 스타일 텍스트 에디터를 직접 구현 중임
D의 장점은 다음과 같음
version(unittest)블록으로 테스트 전용 코드 관리가 쉬움문서를 참고하거나 ChatGPT에 물어보면 항상 우아한 해결책을 찾을 수 있었음
설계 철학적으로 완벽에 가깝지만, 도구와 생태계가 Rust나 Go 수준이었다면 훨씬 성공했을 것임
Phobos 표준 라이브러리는 작은 불편이 너무 많아 결국 포기했음
새 버전인 Phobos V3가 진행 중이지만 인력이 적어 기대 반, 걱정 반임
“ASN.1이 복잡하다고 말한 적 있던가?”
스키마와 데이터 포맷 모두 복잡하지만, 대부분은 무시 가능한 복잡성임
나는 ASN.1 스키마 표기법을 쓰지 않고, 직접 DER 구현체를 C로 작성했음
DER은 표준 인코딩 중 유일하게 쓸 만하다고 생각함
또한 DSER, SDSER, TER 같은 자체 인코딩 포맷도 만들었음
ANY DEFINED BY같은 구조도 여전히 유용하게 사용 중이며,효율적인 인코딩을 위해 OBJECT IDENTIFIER RELATIVE TO라는 비표준 기능도 추가했음
나도 ASN.1 컴파일러를 만들어본 경험이 있음
X.681~X.683의 일부 기능만 구현했지만, 한 번의 코덱 호출로 전체 인증서를 재귀적으로 디코딩할 수 있게 했음
ASN.1은 단순한 문법이 아니라 강력한 타입 시스템임
과소평가받지만 정말 멋진 기술임
예전에 Swift용 ASN.1 컴파일러를 만든 적이 있음
ASN1Codable 프로젝트로, Heimdal의 libasn1을 활용해
ASN.1을 JSON AST로 변환해 파싱을 단순화했음
“JSON으로 바꾸자”는 말은 결국 상처받은 개발자의 외침 같음 😄
이상하게도 ASN.1 작업이 즐겁게 느껴짐
언젠가 Rust용 ASN.1 컴파일러를 직접 만들어보고 싶음
현재 Rust 구현체들은 대부분 derive 매크로나 수동 체이닝 방식이라 아쉬움
일반적으로 표준을 구현할 때는 80% 기능을 20% 시간에 완성하지만,
ASN.1의 나머지 20%는 평생이 걸릴 수도 있음
예전에 Netscape 코드베이스의 ASN.1 파서를 확장해 PKCS#12를 지원했음
RSA 표준과 ASN.1 정의를 너무 깊이 알게 되어 후회했지만,
블로그 작성자의 끈기와 약간의 마조히즘에는 존경을 보냄