죽어가던 소프트웨어: relayd(8)와 httpd(8)의 지속적인 진화

기존 OpenBSD 개발자들의 관심이 줄면서 정체됐던 relayd(8)와 httpd(8) 개발이 실제 운영 수요를 가진 기여자들의 참여로 다시 활발해짐 LLM이 코딩 지식을 대신하는 시기일수록 직접 C를 익히고 도전해야 한다는 판단에서 출발해, relayd(8)의 수제 imsg 체계부터 현대화함 2024~2026년 tech@ 메일링 리스트의 미반영 패치와 기존 GitHub 미러의 오래된 이슈를 대부분 정리하고, 신규 기여자를 위한 Git 미러와 README도 마련함 relayd(8)는 안전한 imsg API와 TLS·요청 파싱 보안을 강화하고 재로딩 충돌을 수정했으며, httpd(8)는 요청 스머글링 방어, 사용자 정의 헤더, 정적 파일 캐시 제어 등을 추가함 두 데몬의 보안·안정성·확장성이 함께 나아졌지만 작업 과정에서 백로그도 늘어나 아이디어와 피드백을 계속 받고 있음 관심을 잃은 프로젝트를 다시 살린 배경 OpenBSD 7.8 주요 변경점에서 다뤘듯 relayd(8)와 httpd(8) 개발은 정체된 상태였음 여러 기여자가 tech@ 메일링 리스트에 패치를 보냈지만 저장소에 반영된 것은 거의 없었음 기존 OpenBSD 개발자들이 두 데몬에 더 이상 관심을 두지 않은 것이 주된 원인이었음 kirill@와 함께 두 데몬을 정기적으로 사용하며 실제 활용 사례를 다뤄온 경험을 바탕으로 적극적인 개발을 시작함 복잡한 httpd(8)·relayd(8) 구성으로 OpenBSD 고객을 지원해야 하는 실무 수요도 직접적인 동력이 됨 LLM 시대에 C로 돌아간 이유 가장 큰 계기는 LLM의 등장이었음 과거에는 현대적인 C++ 코드를 전문적으로 작성했지만, 이후 솔루션 아키텍처와 플랫폼 엔지니어링, 팀 구축으로 옮겨가며 실제 코드를 거의 쓰지 않게 됐음 주로 선언형 YAML을 작성하고 OpenBSD ports(7)를 위해 코드를 읽고 포팅하는 정도에 머물렀음 “코딩은 해결됐다”는 주장과 달리, 지식이 외부로 위임되는 시기일수록 직접 그 지식을 갖추는 일이 더 중요하다고 판단함 C++와 Rust는 어려운 판단 일부를 대신하지만 C는 그렇지 않다는 점을 도전 과제로 삼아 relayd(8)와 httpd(8)에 기여하기로 결정함 동기보다 규율로 이어간 기여 오픈소스 기여는 몇 주 만에 좌절로 끝날 수 있지만, 초기의 고통스러운 단계를 지나 꾸준히 작업할 수 있는 상태에 도달함 처음에는 코드베이스를 수동적으로 읽으며 여러 부분에서 낙담...