▲

Webbol - COBOL로 작성된 미니멀 정적 웹 서버

 (github.com/jmsdnns)
1P by GN⁺ 9일전 | ★ favorite | 댓글 2개
  • COBOL로 작성된 미니멀 정적 웹 서버로, GnuCOBOL을 이용해 현대적인 시스템 프로그래밍이 가능함을 보여줌
  • 현재 디렉터리의 정적 파일 제공, MIME 타입 자동 감지, HTTP 상태 코드 처리(200/403/404/413), 경로 탐색 공격 차단, 리퀘스트 로그 출력 등 기능을 제공
  • 단일 스레드로 한 번에 하나의 요청만 처리 가능하며, 파일 크기는 최대 64KB 지원
  • GnuCOBOL이 설치된 POSIX 호환 환경(Linux/macOS/BSD) 에서 동작하며, make로 컴파일 후 ./webserver 명령으로 8080 포트에서 실행 가능
  • COBOL 언어로 작성된 네트워크 프로그램의 예로서, 레거시 언어로도 현대적 웹서버를 구현할 수 있음을 입증하는 프로젝트

프로젝트 개요

  • Webbol은 COBOL 언어와 GnuCOBOL 컴파일러를 이용해 개발된 미니멀 정적 웹 서버임
  • 목적은 간단한 정적 파일 제공과 COBOL의 현대적 사용성을 입증하는 것

주요 기능

  • 현재 디렉토리의 정적 파일 서빙
  • 일반적인 파일 형식에 대해 자동 MIME 타입 감지
  • HTTP 상태 코드 200(OK), 403(Forbidden), 404(Not Found), 413(Payload Too Large) 지원
  • 경로 이동 공격(../ 등) 방지
  • 전체 HTTP 헤더를 포함한 청결한 요청 로그 기록
  • 루트 경로 요청 시 index.html 기본 제공

시스템 요구 사항

  • GnuCOBOL (cobc) 컴파일러 필요
  • POSIX 호환 운영체제 필요 (Linux, macOS, BSD)
  • make 도구 필요

동작 예시 및 접근 방법

구조와 파일 구성

  • Makefile: 빌드 설정
  • README.md: 설명 안내 파일
  • config.cpy, socket-defs.cpy, http-structs.cpy, file-structs.cpy: 서버, 소켓, HTTP, 파일 처리 구조 정의
  • path-utils.cbl: 경로 검증 및 정리
  • mime-types.cbl: MIME 타입 판단 로직
  • file-ops.cbl: 파일 읽기 작업
  • http-handler.cbl: HTTP 요청/응답 처리
  • webserver.cbl: 메인 서버 프로그램

지원 MIME 타입

  • HTML: text/html
  • CSS: text/css
  • JavaScript: application/javascript
  • JSON, XML, Plain text, PNG, JPEG, GIF, SVG, ICO, PDF 등
  • 추가 MIME 타입 등록은 mime-types.cbl 파일에서 가능

보안 기능

  • 경로 이동 방지: ‘..’ 시퀀스가 포함된 요청 차단
  • 디렉토리 접근 제한: 현재 디렉토리 및 하위 디렉토리 파일만 제공
  • 안전한 파일 핸들링: 파일 시스템 접근 전 경로 검증 및 유효성 검사

제한 사항

  • 싱글 스레드 기반: 한 번에 하나의 요청만 처리 가능
  • SSL/TLS(HTTPS) 미지원
  • 최대 파일 크기: 64KB
  • 라인 순차 파일 구성(텍스트 파일)만 지원
  • 캐시, 압축, 범위 요청 등 미지원
▲
yangeok 9일전  [-]

주석도 되게 신기하게 생겼네요,,

답변달기
▲
GN⁺ 9일전  [-]
Hacker News 의견

  • COBOL의 고정 형식 모드가 실제로 사용되고 있는 것을 보니 반가움
    COBOL은 자유 형식(free mode)과 고정 형식(fixed format mode) 두 가지 모드가 있음
    고정 형식은 펀치 카드 시대의 유산을 따라 특정 열에 따라 구분함

    • 1~6번 열: 행 번호

    • 7번 열: 인디케이터 문자(예: *는 주석, 예제 코드에서 확인 가능)

    • 8~11번 열: 특별한 division 마커, 가끔 그 이상을 차지함(예시 파일)

    • 12~72번 열: 실제 COBOL 명령문

    • 73~80번 열: 프로그래머 주석 등 자유롭게 사용
      이 구조는 요즘 개발자와 툴에 부담이 되기 때문에 자유 형식 모드가 권장됨
      하지만 고정 형식 모드 특유의 매력도 있어서 2025년에 COBOL을 쓸 거면 진짜 옛날 감성을 즐겨보기를 추천함

    • 73~80번 열은 카드가 흩어졌을 때 정렬기계로 다시 정렬할 수 있도록 순번 표시용으로 쓰이기도 했음
      COBOL 카드의 실감을 느끼려면 이 링크에서 COBOL 카드를 선택해볼 수 있음
      더 옛날 느낌을 원하면 먼저 코딩 폼에 프로그램을 쓰고, 그걸 어시스턴트가 keypunch 하는 식으로 해볼 수도 있음(샘플)

    • 예전 Fortran도 고정 열 구조를 썼는데, 열 배치만 다름
      공통점은 73~80번 열을 카드 정렬용 순번 등에 비워 두는 것
      나는 실제 카드를 써본 적 없지만 카드를 떨어뜨리거나 순서를 틀리기 쉽기 때문에 순서 번호와 정렬기가 엄청 유용했으리라 생각함

    • 이 부분 나도 인상 깊었음
      그런데 Makefile에서는 cobc의 -free 옵션을 쓰고 있던 점이 재미있었음

  • 사람들은 “일에 맞는 최고의 도구를 쓰라”고 하면서, 정작 COmmon Business Oriented probLems에는 COBOL은 고르지 않는 모습임

    • 이건 MUMPS에도 똑같이 적용됨
      사람들은 자신이 대단한 선택을 할 수 있다는 걸 간과함

    • COBOL을 선택하지 않는 게 아니라, 아예 고려조차 하지 않는다는 점이 더 큼

    • 언제, 왜 "일에 가장 좋은 도구"라는 말을 쓰는지 궁금함

  • 우리 회사는 40~50년 이상 된 곳임
    지금도 비즈니스 운영의 90%가 COBOL 기반임
    현업 직원들은 RM/COBOL과 RM/PANELS로 만든 블루스크린에서 일하고 있음
    2010년대까지도 COBOL로 HTML을 생성했지만 HTTP 요청을 직접 받지는 않았음
    대신 Apache 뒤에 RPC 레이어를 두고, HTTP 요청을 CGI로 변환해서 COBOL로 전달함
    COBOL 프로그램이 HTML 문자열을 CGIRPC 인터페이스로 보내고, 그 결과가 웹페이지로 브라우저에 나옴
    여전히 XML 서비스 등으로 이를 사용하면서 기존 웹앱을 보조하고 있음
    솔직히 이 프로젝트는 그보다 훨씬 멋진 경험임

  • 코드의 거의 모든 줄에 주석이 달려 있음을 보니 흥미로움
    "코드는 스스로 문서가 되어야 한다"는 말의 전제를 다시 생각해 보게 됨
    이는 코드를 읽는 사람이 언어를 알고 있다는 전제가 깔려 있고, 경우에 따라 "셀프-다큐먼팅"이 가능해야 한다는 뜻임
    아마도 COBOL에 익숙한 사람들은 COBOL도 충분히 셀프-다큐먼팅 될 수 있다고 말하겠지만, 나는 잘 모르겠음

    • 깃 커밋 d9a5e3e에서 "궁금해하는 사람들이 각 줄이 뭘 하는지 이해할 수 있도록 주석을 추가함"이라는 내용을 확인할 수 있음

    • "코드는 언어를 아는 사람이 읽는다"는 말은 맥락에 따라 다르다고 생각함
      혼자 또는 남을 위해 배우면서 작성하는 코드는 각 줄이 뭐하는지 주석을 다는 것이 자연스럽다고 봄
      반면 전문 환경에서는 팀이 언어를 잘 알 거라는 가정으로 대체로 주석 없이 구조적으로 관리하는 것이 더 좋은 선택이 될 수 있음

    • 은행에서 COBOL 코드는 원래 자연어 같다고 하면서 셀프-다큐먼팅이라고 주장하는 사람도 있더라서, 나는 그 얘기를 듣고 웃음이 나올 뻔했음

  • 이건 농담인 것 같지만 정말 궁금증이 생겨서 질문을 남김
    COBOL에서 보안 관련 보장에 대해 잘 아는 분이 있을까 궁금함
    예를 들어, COBOL은 메모리 범위 초과 접근을 허용하는지, C나 Rust처럼 '실수'로 보안 구멍이 발생할 위험은 어떤지 알고 싶음

    • COBOL에서 메모리 범위 초과 접근은 현대 컴파일러라면 에러를 뱉고, 만약 컴파일이나 실행이 된다면 런타임 오류나 곧바로 크래시 상황을 맞게 됨
      다만, COBOL의 reference modification 기능으로 의도적으로 데이터 경계 밖 메모리를 참조할 수 있는 점이 존재함
      완벽히 안전하진 않고, 다만 컴파일 단계에서 많은 실수나 오용이 잡히기에 실수 발생률이 꽤 낮아지는 셈임

    • http handler를 보며 나도 같은 점이 궁금했음
      메소드와 패스 사이에 공백이 빠진 경우 버퍼 오버런 가능성이 있을 것 같았음
      직접 돌려보지는 않았지만, 이런 류의 고민이 들었음

  • CALL "socket"이 뭘 하는지 더 알고 싶다는 생각임
    CALL은 서브프로그램 호출인데 "socket"이 어디에 정의되어 있는지 모르겠음
    예전에도 COBOL 웹서버를 만들어볼까 생각했는데, GnuCOBOL FAQ에서 CGI로 가능하다고만 보고 더 진행을 못 했었음(FAQ 참고)
    이 프로젝트를 더 깊이 살펴보고 싶음
    정말 흥미로운 느낌임

    • "socket"은 시스템 콜 호출일 수도 있음

  • COBOL이 일부 정부기관과 기업 웹사이트 백엔드로 쓰이던 시절이 있었음
    그 시절 사이트는 HTML이 100열 고정폭 포맷으로 출력되는 특유의 형태로 쉽게 알아볼 수 있었음

  • 나는 어떤 언어도 다 프로그래밍할 수 있다고 생각했는데, 이 COBOL 프로젝트를 보니 Assembly가 오히려 깔끔하고 우아하게 느껴질 정도임
    Jms Dnns! 이 프로젝트는 정말 사고를 넓혀 주는 멋진 작업임

    • 첫 직장에서 제조 시스템은 COBOL로, 금융 시스템은 Assembler로 지원하는 일이었음
      두 언어의 수십cm 쌓인 소스코드를 다뤄 본 입장에서 COBOL 쪽이 머릿속에 정리하기 훨씬 쉬웠음
      사람마다 다를 수는 있음

  • 정말 멋진 프로젝트임
    COBOL 입문에 관한 팁 있으면 듣고 싶음

  • 이제 COBOL on Cogs의 비전에 한 발 더 다가선 셈임
    coboloncogs.org에서 더 확인할 수 있음

답변달기