COBOL이 오랫동안 “죽은” 상태였다는 할아버지의 기록

 (wumpus-cave.net)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 1992년 6월 Technical Support 잡지에 실린 글은 이미 COBOL의 죽음을 선언했지만, 30년이 지난 뒤에도 그 언어가 완전히 사라지지 않았다는 점이 핵심임
  • 당시의 4GL 같은 유행어는 대부분 오래가지 못했지만, COBOL은 상당수 후발 대안보다 오래 버틴 사례로 남음
  • COBOL을 계속 움직이게 한 결정적 계기는 Y2K 문제였고, 실제 대응에는 새로운 COBOL 프로그래머 세대를 훈련시키는 일이 필요했음
  • 한때 설치 기반이 컸던 언어는 갑자기 사라지기보다 신규 학습자가 줄어드는 긴 꼬리를 남기며 유지될 수 있음
  • 글쓴이의 할아버지는 2024년 9월 1일 91세로 사망했고, 개인적 회고와 오래된 기술 예측이 함께 겹쳐지는 글임

1992년에 이미 나온 “죽은 COBOL” 선언

  • 글쓴이의 할아버지는 1992년 6월 Technical Support 잡지에 COBOL의 죽음을 선언하는 글을 발표함
  • 당시 글에는 4GL 같은 시대적 용어가 등장하며, 글쓴이는 Wikipedia의 4GL 예시 목록 중 상당수보다 COBOL이 더 오래 살아남았다고 덧붙임
  • 원문 텍스트는 NaSPA 아카이브에 남아 있음: http://www.naspa.net/magazine/1992/t9206003.txt
  • 1992년 글은 “dead”라는 단어의 의미를 나누며, COBOL을 죽었지만 사라지지 않은 Zombie 같은 존재로 다룸
    • Autocoder도 COBOL의 전신으로 소개되며, 죽은 언어로 여겨지지만 일부 흔적은 남아 있을 수 있는 사례로 비교됨

Y2K가 만든 COBOL의 긴 수명

  • COBOL 좀비를 계속 움직이게 한 큰 요인은 Y2K 문제였음
    • 당시 뉴스에서 크게 다뤄졌고 이후 아무 일도 없었던 것처럼 보였지만, 실제로는 거대한 문제였음
    • 대응 과정에서 새로운 COBOL 프로그래머 세대를 훈련시켜야 했음
    • 이 과정이 COBOL을 더 오래 유지시키는 데 기여했을 수 있음
  • 글쓴이는 이제 프로그래밍 언어에 dead라는 표현을 잘 쓰지 않음
    • 한때 큰 설치 기반을 가진 언어는 완전히 죽기 어려움
    • 대신 신규 프로그래머가 배우지 않으면서 점차 희미해지는 긴 꼬리를 남김

개인적 회고로 이어지는 기술사의 한 장면

  • 글쓴이의 할아버지는 2024년 9월 1일 91세로 사망함
    • 공식 사인은 폐렴임
    • 할머니는 그해 4월에 사망했고, 할아버지는 치료를 받지 않겠다고 요청했음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 글이 4GL을 언급하는데, 정말 오랜만에 듣는 용어임
    COBOL도 “사람이 읽는 문장처럼 보여서 더는 프로그래머가 필요 없을 것”이라는 약속을 했고, 이는 요즘의 로우코드 플랫폼이나 LLM 생성 코드와 닮아 있음
    문제는 보통 사람이 동작하는 해법이 나올 만큼 충분히 자세히 문제를 설명하고 쪼개지 못한다는 것임. 그 과정을 해내면 결국 프로그래머가 되는 셈이고, COBOL의 핵심 교훈은 프로그래머가 필요한 이유가 컴퓨터 인터페이스나 언어 때문만은 아니라는 데 있음

    • 대체로 동의하지만, COBOL은 “평균적인 사람”이 쓰라고 만든 게 아니라 도메인 지식이 깊은 사람이 쓰도록 의도된 언어였다고 봄
      업무 프로세스를 잘 아는 사람이 컴퓨터 동작 방식을 많이 배우지 않고 COBOL로 옮겨 적을 수 있게 하려는 쪽에 가까웠고, SQL로 데이터베이스와 대화하는 분석가나 데이터 담당자와 비슷한 면이 있음
      COBOL과 4GL은 급여, 은행, 인사, 재고 같은 업무 애플리케이션 구축이 주목적이었고, 특히 정산처럼 반복적인 대량 작업을 줄이는 배치 처리에 초점이 있었음
      전용 DBMS가 없던 시절의 산물이라 파일 구성과 파일 관련 동사가 매우 발달했고, 오늘날의 SQL과 닮은 부분도 있음
    • “비싼 프로그래머가 더는 필요 없다”는 LLM 기반 접근에도 같은 본질적 한계가 있다고 느낌
      LLM이 마법처럼 해법을 생성한다고 해도, 문제를 간결하고 정확히 표현해야 하는 책임이 위로 올라갈 뿐임
      결국 프롬프트로 “프로그래밍”하고, LLM이 제안한 형식화된 결과물인 코드를 검토하게 됨. 프로그래밍의 성격이 프롬프트 엔지니어링으로 바뀔 수는 있어도, 형식 언어인 코드를 이해해야 하는 일은 남아 있음
    • 4GL은 일반 논리, 단순 자료구조, 산술을 넘어 더 많은 것을 다루기 위해 언어에 자연어 비슷한 구성을 더 넣으려던 흐름이었음
      글에서는 1990년대 초 4GL이 대유행이었다고 하지만, 메인프레임 바깥에서도 그랬는지는 의심스러움. 4GL 운동은 처음부터 강하게 메인프레임 지향이었고, 위키백과도 초기 목표로 프로그램에 필요한 천공카드 수를 줄이는 것을 언급함
      1992년이면 이미 Linux가 나왔고 Python 작업도 진행 중이었으며, Perl은 인기를 얻고 Haskell도 초기 버전이 나온 상태였음. 기술의 전선은 비싼 워크스테이션에서 소비자용 PC로 이동하고 있었고, 언어 설계자들은 dBase, HyperTalk, AppleScript처럼 결과적으로 4GL로 볼 수 있는 것을 만들 때도 4GL 개념을 크게 의식하지 않았다고 봄
      자연어 같은 텍스트가 대부분의 프로그래밍 용도에 나쁜 아이디어라는 데는 동의하지만, 4GL 운동이 실패한 이유는 그 때문만은 아니라고 생각함. 대부분의 4GL은 3GL인 COBOL보다 더 자연어 같지도 않았음
      더 큰 문제는 4GL 운동이 새 세대가 무엇인지, 무엇이 유용한지 제대로 정의하지 못했다는 점임. 2GL은 어셈블리에서 기계어로의 번역, 3GL은 컴파일이라는 혁명적 변화를 가져왔지만, 4GL에서 그나마 정의 가능한 변화는 “외부 루틴이나 라이브러리에 있던 기능을 언어 안에 더 넣자” 정도였음
      이 접근은 도메인 특화 언어에서는 잘 먹혔고, 그래서 SQL, R, MATLAB 같은 성공적인 4GL이 나왔음. 반면 범용 4GL이라는 개념은 결국 지나치게 비대한 언어로 귀결될 운명이었다고 봄
    • 변하는 게 많아 보여도 결국 같은 패턴이 반복됨
    • “더는 프로그래머가 필요 없다”는 말이 놀랍지만, 당시의 프로그래밍이 종이에 직접 기계어를 써서 맞게 동작시키는 능력을 뜻했다면 어느 정도는 맞는 말이었을 수 있음
      오늘날에는 그런 일을 할 수 있거나 해야 하는 사람이 거의 없음

  • 이 맥락에서는 Scala가 떠오름. 글에서 COBOL을 묘사한 방식으로 보면 Scala도 사실상 죽은 상태에 가깝다고 생각함
    여전히 Scala로 작성된 핵심 컴포넌트를 가진 기업과 서비스가 많지만, 새 프로젝트에서의 관심도는 크게 꺼졌음
    2012~2014년에는 HN에서 “Scala로 X 하기” 글을 계속 봤던 것 같은데 이제는 거의 보이지 않음. 자연스럽고 피할 수 없는 현상일 수 있지만, Scala가 다른 주류 언어들이 아직도 못 챙긴 좋은 점들을 갖고 있었다는 점에서는 아쉬움

    • Apple의 몇몇 엔지니어링 팀은 기존 시스템을 유지하면서도 Scala 신규 프로젝트를 하고 있음
      테스트 시스템처럼 회사 생태계에 꽤 중요한 프로젝트도 있고, 예전에 이런 시스템을 만든 엔지니어들은 지금 대부분 고위 관리자가 됐음
      당시 기술 선택을 여전히 지지하는 사람도 있지만, 돌아볼 기회를 주면 더 열린 태도를 보이는 사람도 있음. 대체로 그때 Kotlin이 있었거나 Swift가 백엔드 서비스에 쓸 만했다면 Scala를 선택하지 않았을 것이라는 분위기임
    • Scala는 아직 활발히 살아 있음
      https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2...
      초기 과열은 식었지만 괜찮음. 모든 언어에는 과열 주기가 있고, 예측도 대개 빗나감. 주류 프로그래밍 언어는 이제 COBOL처럼 죽기 어려움
      Java는 2001년부터 죽는다고 했지만 닷컴 버블, .NET, LAMP의 P, Ruby, JS, Go를 모두 견뎠음. Python도 3 버전 전환 때 사람들이 Ruby로 옮겨가며 죽을 거라고 했음
      Scala는 세계에서 가장 인기 있는 함수형 프로그래밍 언어이고, 도구와 라이브러리가 좋으며, Scala 3는 훌륭한 업그레이드라고 봄
    • 오늘날의 Perl이 COBOL에 더 가깝다고 생각함
      한때는 엄청나게 컸고 어디에나 있는 것처럼 느껴졌지만, 지금은 점점 틈새로 밀려나고 있음. COBOL처럼 실제 현장에는 Perl 코드가 아직 많이 남아 있음
    • Writer에서는 모든 새 서비스를 Scala로 만들고 있음
      Jack Henry, SiriusXM, Starbucks, Disney 스트리밍 서비스, Capitol One도 지난 5년부터 지금까지 데이터 과학이 아닌 서비스 부문에서 Scala 신규 프로젝트를 만들고 있음
      물론 더 많은 팀이 있지만, 바로 떠오르는 유명한 곳만 꼽아도 이 정도라서 죽었다고 보기 어렵다
      다만 Play, Akka 중심의 프레임워크 일자리와 Airflow가 아닌 순수 Spark 작업은 줄어드는 듯함. 이들은 Scala 생태계에서 나온 프레임워크 일자리였을 뿐, Scala 자체는 부차적이었던 경우가 많았다고 봄
    • Scala는 COBOL처럼 죽을 수 없음. 애초에 COBOL처럼 널리 살아 있었던 적이 없었기 때문임
      Scala를 좋아하지만 늘 변두리 언어였고, COBOL은 정말 어디에나 있었음

  • 언젠가 Fortran, COBOL, Ada, APL 같은 레거시 언어들을 직접 앉아서 만져봐야겠다고 생각함
    인기는 확실히 떨어졌지만 여전히 중요한 곳에서 쓰이는 언어들임
    동시에 엄청난 양의 Java 코드도 떠오름. Java는 좋든 나쁘든 기업용 영역을 거의 먹어치웠는데, 30~40년 뒤에는 은퇴자들만 오래된 은행 시스템을 유지하려고 Java를 쓰는 모습이 될 이유가 있을까 싶음

    • COBOL이 남아 있는 건 COBOL 자체 때문이라기보다 벤더·플랫폼 종속 때문이라고 봄
      거대한 단일 코드베이스나 플랫폼이라는 점도 있을 듯함. 언어가 난해하고 어려운 것도 아니고, 그저 구조가 잘 보이지 않는 코드가 너무 많을 뿐임
    • Ada는 다른 예시들보다 한 자릿수 규모로 더 현대적이고 정교한 언어임
      앞으로 100년 동안 시장의 0.05% 정도는 차지할 것 같음
    • Fortune 100 회사의 Android 앱을 개발하는데, 누군가 Java 파일을 수정한 마지막 커밋이 지난주였음
      다만 최근 몇 년간 새 코드는 대부분 Kotlin으로 작성됨
    • APL은 워낙 다른 패러다임이라 직접 경험해볼 가치가 있음
      개인적으로도 애착이 있는데, 90년대에 회사에서 PC로 실제로 썼음. 데이터를 어떻게 넣을지 알아내는 일이었고, 결국 부동소수점 숫자를 1과 0의 벡터처럼 다루며 비트를 바꿔 Microsoft 형식에서 IEEE 형식으로 변환하는 루틴을 작성했음
      물론 허리띠에 양파를 매고 있던 시절 이야기임
    • 순수한 수치 계산만 한다면 Fortran은 꽤 쓰기 좋음
      순수 수치 시뮬레이션을 한다면 C++나 Python보다 Fortran을 선호할 것 같음. NumPy를 제외하면 말인데, NumPy 자체도 결국 Fortran과 C++에 기대고 있음

  • 2025 Carolina Code Conference에서 여전히 COBOL 발표자를 찾고 있음
    특히 GnuCOBOL이 최근 업데이트된 만큼, 한동안 COBOL 발표를 넣고 싶었음
    https://gnucobol.sourceforge.io/
    https://carolina.codes

    • www.cobolworx.com. 우리 작업에 대해 이야기할 장소를 늘 찾고 있음

  • “2000년의 언어가 어떻게 생겼을지는 모르지만, 이름은 Fortran일 것이다.” —Tony Hoare
    COBOL은 시대마다 계속 바뀌었기 때문에 살아 있다고 볼 수 있음. 현대 COBOL은 사람들이 그 이름을 들었을 때 본능적으로 떠올리는 1950년대 COBOL과 꽤 다름
    마치 Java가 Algol-94 같은 이름으로 불렸고, 그래서 우리가 여전히 Algol로 프로그래밍한다고 말하는 것과 비슷함

    • 이제는 아무도 MULTIPLY A BY B GIVING C ON SIZE ERROR STOP RUN. 같은 식으로 쓰지 않음
    • Kemeny와 Kurtz는 이미 1968년에 Fortran을 “구식”이라고 불렀음
      <https://dtss.dartmouth.edu/sciencearticle/index.html>
    • 더 정확히는 “2000년의 언어가 뭐라고 불릴지는 모르지만, Fortran처럼 생겼을 것이다”에 가까울 수 있음
    • 2000년에는 거의 맞는 말이었지만 지금은 아님. 세상은 느리게라도 바뀜
    • 그런데 70년대, 80년대, 90년대의 기존 시스템들이 현대 COBOL을 쓰고 있기는 한가?

  • COBOL은 죽지 않았지만 접근하기가 어려움. Linux에서 쓸 수 있는 오픈소스 도구가 거의 없기 때문임
    OCamlPro에서는 GnuCOBOL 오픈소스 컴파일러를 중심으로 오픈소스 환경을 만들기 위해 SuperBOL이라는 프로젝트를 시작했음. GnuCOBOL은 이미 성숙했고 기업에서도 쓰이고 있음
    이미 COBOL용 LSP가 들어간 VSCode 확장을 공개해 현대적인 IDE 경험을 제공하고 있고, 고객 요구에 따라 다른 도구들도 작업 중임

  • 늘 그렇듯 이런 논의는 “죽었다”와 “살아 있다”를 어떻게 정의하느냐에 달려 있음
    어떤 기술 위에 새 비즈니스가 더는 만들어지지 않으면 죽었다고 부를 수 있다면, COBOL은 죽었다고 봐도 무방함. 보통 COBOL의 대리표현처럼 쓰이는 IBM 390x, 즉 Z/OS 플랫폼도 마찬가지임
    반대로 운영 환경에서 아직 쓰이면 살아 있다고 본다면 COBOL은 당연히 살아 있고, 자신보다 젊은 많은 기술보다 훨씬 더 살아 있음
    다만 이것을 COBOL이나 메인프레임 생태계의 장점으로 받아들일 필요는 없음. 조직은 처음 잘 동작한 것을 계속 붙잡는 경향이 있고, 초기 디지털화의 주역이었던 정부, 은행, 항공사 같은 곳에서는 그 첫 선택이 대개 IBM 메인프레임과 그 위의 소프트웨어였을 뿐임

    • 메인프레임을 없애기 어려운 이유는, 메인프레임 수준의 동시 입출력 처리량을 감당할 다른 플랫폼이 사실상 없기 때문임
      우리 메인프레임은 시간당 1억 건의 트랜잭션을 여유 있게 처리함. 게다가 대부분 동기식이고, 각 트랜잭션이 여러 SQL 트랜잭션으로 이어짐
      최종적 일관성도 방법이긴 하지만 금융 분야와는 매우 맞지 않고, 군사·보험·의료·보건에서도 그럴 가능성이 큼. 작업을 파티션으로 나눌 수도 있지만, 샤드 경계를 넘을 때 일관성 문제가 생김
      COBOL은 아직 죽지 않았지만 천천히 그쪽으로 가고 있음. 메인프레임을 벗어나려 적극적으로 작업하지 않는 은행은 하나도 모름. 그래도 본 예상치들은 메인프레임과 COBOL이 적어도 2050년까지는 남는다고 말함
      즉 앞으로 26년 동안 COBOL 코드를 쓴다는 뜻임. COBOL 프로그래머는 수요도 높고 보수도 좋은 편이라, 지금 COBOL 프로그래머로 커리어를 시작해도 거의 평생에 가까운 근무 기간을 채울 수 있음
    • 새 비즈니스를 말 그대로 스타트업으로 본다면, 메인프레임은 60~70년대에도 사실상 그런 시장이 아니었음
      진입 장벽은 늘 극단적으로 높았고, 당시 주요 고객도 오래된 보험사, 은행, 정부 같은 곳이었음. 새 회사가 컴퓨팅을 하는 일이 가능해진 건 미니컴퓨터 이후에 가까움
      그런 의미에서는 크게 달라진 게 없고, 제품의 목표 시장을 생각하면 플랫폼의 생사 판단 기준으로 “새 비즈니스가 쓰는가”는 적절하지 않다고 봄
    • 은행이나 대형 금융기관이 핵심 업무 흐름을 COBOL 표준으로 삼았을 가능성을 빼면 안 됨
      새 사업부나 내부 스타트업 팀, 예를 들어 새 보험 상품 카테고리도 은행의 나머지 시스템과 통합하려면 일부를 COBOL로 작성할 수 있음
      최소한 COBOL로 직접 쓰지 않더라도, 새 x86 랙과 이를 관리할 사람을 살 예산이 없어서 기존 COBOL 실행 인프라, 즉 Z/OS 위에 올릴 수도 있음
    • COBOL은 언데드임

  • 클라우드는 새로운 메인프레임인데, 더 나쁜 버전임. 단점은 다 갖고 있으면서 가장 큰 장점은 없음
    예전에는 CICS로 매우 안정적이고 성능 좋은 서비스를 만들고, 같은 트랜잭션 안에서 다른 서비스를 호출할 수 있었음. 플랫폼이 데이터 무결성 유지 같은 복잡한 일을 처리해줬음
    같은 트랜잭션 안에서 서로 호출하는 AWS Lambda를 한번 작성해보면 차이가 드러남

    • “단점을 다 갖고 있다”는 게 단일 벤더 종속, 엄청난 설비투자와 운영비, 관련 기술을 아는 사람이 교육을 받거나 경험자여야만 하는 상황을 뜻하는가?
      그리고 왜 비교 대상이 “같은 트랜잭션 안에서 서로 호출하는 AWS Lambda”인지 모르겠음. 메인프레임 배포도 개발자에게 접근 권한을 준 API에 코드가 든 .zip을 던지는 것만큼 간단했나?

  • 일부가 내가 현대 언어보다 COBOL을 고르거나 선호한다고 받아들여 비판하는데, 그런 뜻은 아님. 틀 밖에서 보는 악마의 변호인식 관찰을 한 것뿐임
    아이러니하게도 Rust보다 읽고 이해하기 쉬운 메모리 안전하고 안정적인 언어가 COBOL로 이미 있었음. 하지만 아무도 쓰고 싶어 하지 않으니 “죽은” 언어가 됐고, 정작 현대를 가능하게 만든 시스템들은 그 위에서 돌아감
    예시로 숫자를 입력받아 짝수·홀수를 출력하는 Rust 코드와 COBOL 코드를 비교하면, COBOL 쪽이 더 직접적으로 읽힘

    • 이상한 관점임. 오래된 언어의 좋은 기능들이 사라졌다가 나중 언어에서 재발견되는 일은 있지만, COBOL이 정말 Rust가 풀려는 문제들을 모두 해결하는지는 의문임
      같은 수준의 성능을 내는지, 다른 언어의 네이티브 코드와 같은 방식으로 연동되는지, 합성과 하위 호환성을 돕는 모듈 시스템 위에 쓸 만한 패키지 관리자가 있는지, Rust의 대수적 자료형처럼 데이터와 오류의 형태를 편하게 표현할 수 있는지 모르겠음
      COBOL이 여전히 쓰이는 이유가 있듯, 새 언어들이 만들어진 데에도 좋은 이유가 있음
    • 두 프로그램을 비교 가능하다고 말하기는 애매함. COBOL 버전은 오류를 처리하지 않지만 Rust 프로그램은 패닉이라도 일으키며 처리하기 때문임
      실제로 필요한 보일러플레이트를 붙여 실행 가능한 COBOL 프로그램을 만들면, abc 입력에 “even”을 출력하고 12 입력에 “odd”를 출력함
      Rust 문법을 특별히 문제 삼는 것도 특이함. 요즘 대부분 언어처럼 Rust도 대체로 C 계열 문법이고 OCaml 요소가 조금 섞인 정도임. 문법을 떠나 Rust와 COBOL은 목표가 매우 다르기 때문에 “그냥 COBOL을 쓰자”로 Rust의 존재 이유가 사라지지는 않음
    • IBM 문서의 예시는 COBOL이 메모리 안전하지 않은 언어임을 보여주는 듯함
      https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statement-ex...
      ALLOCATE, 포인터 주소 설정, FREE 같은 코드가 등장함
    • 셸 스크립트도 메모리 안전하지만, 100줄 넘는 프로그램을 거기에 쓰지 않는 데는 이유가 있음
    • 이상한 비교임. 컴퓨터 근처에 가도 되는 개발자라면 Rust가 맞는 자리에 COBOL을 고르거나, 그 반대를 고르지는 않을 것임

  • 이 트윗이 묘하게 좋음
    https://x.com/grauhut/status/1000017084435312642
    번역하면 “고객사에서 COBOL을 발견했다. 괜찮다. 메인프레임이다. 특별할 건 없다. 마지막 주석은 1985년 것이었다. 작성자는 우리 어머니였다”라는 내용임

답변달기