메인프레임 COBOL 프로그래머인 어머니와의 인터뷰 (2016)

메인프레임 COBOL 프로그래머인 어머니 인터뷰

• 어머니는 태어나기 전부터 EU 내에서 가장 큰 은행 중 하나에서 근무하고 있음.
• 은행 프로그래밍 세계는 대부분의 사람들이 익숙한 것과는 완전히 다른 세계임.
• 어머니와 그녀의 팀이 일을 그만두면 은행은 몇 주 안에 망할 것임.

1991년

• 어머니는 Nordbanken(현재 Nordea)에서 내부 교육을 시작함.
• 다양한 테스트를 치르고 IQ 테스트, 심리 검사, 멀티태스킹 테스트를 통과함.
• IBM 메인프레임 COBOL 프로그래머로 시작하여 25년 후에도 같은 은행에서 같은 직무를 수행함.

COBOL

• COBOL은 함수형 Haskell이나 동시성 Golang과 같은 멋진 프로그래밍 언어는 아님.
• COBOL은 명령형, 절차적 언어이며 2002년부터 객체 지향적임.
• 메인프레임 프로그래밍 맥락에서 COBOL을 아는 사람이 거의 없음.

데이터베이스

• 주 데이터베이스는 IMS라고 불리며, IBM이 아폴로 프로그램을 위해 만든 계층적 데이터베이스임.
• DB2로의 마이그레이션 시도 중이지만, 이는 수년이 걸릴 작업임.
• DB2 데이터베이스는 현재 약 10TB의 데이터를 보유하고 있음.

배치

• 시스템의 약 80%는 배치 작업으로 구성됨.
• 배치 작업은 특정 시간이나 간격으로 실행되며, 데이터 처리나 다른 은행/기관에 데이터를 전송함.

은행이 직면한 문제들

• 메인프레임을 사용하는 은행들은 처리해야 할 많은 문제들이 있음.
• 프로그래머들이 늙어가고 있으며, 새로운 직원이 독립적으로 일하기까지 2-3년이 걸림.
• 수십 년 된 프로그램들이 있으며, 아무도 그것들이 무엇을 하는지 모름.

최종 단어

• Nordea와 다른 은행들이 앞으로 몇 년 동안 어떤 새로운 기술을 도입할지 매우 흥미로움.

Q & A

• IBM 메인프레임 COBOL 프로그래밍을 선택한 이유? 컴퓨터와 함께 일하고 싶었기 때문.
• 하루 중 가장 나쁜 일은? 동료가 중요한 시스템 모듈에 점을 빼먹어 은행이 16시간 동안 다운됨.
• 은행의 미래는 어떻게 될까? 메인프레임을 현대적인 것으로 교체해야 함을 인식하고 있음.
• 90년대에 여성 프로그래머로서 직면한 도전은? 문제 없었음.
• 20년 넘게 같은 코드베이스로 일하는 것이 지루해지나? 새로운 시스템을 만드는 것은 항상 재미있었음.
• 은행을 위한 코드를 작성하는 것이 무섭나? 매우 무섭지만, 테스트 환경이 견고해서 대부분 원활하게 진행됨.
• 은행을 위한 큰 실수를 한 적이 있나? 1997년에 은퇴 저축 계좌에서 불법적으로 돈을 인출할 수 있게 만드는 실수를 함.
• 작업 환경은 어떤가? 개인 책상에서 열린 공간으로 이동했으며, 이를 매우 싫어함.

GN⁺의 의견

• 메인프레임과 COBOL 언어는 여전히 금융 산업에서 중요한 역할을 하고 있으며, 이 기술에 대한 전문 지식은 매우 가치가 있음.
• 은행 시스템의 복잡성과 오래된 기술에 대한 의존도는 새로운 시스템으로의 전환을 어렵게 만들고, 이는 큰 도전 과제임.
• 이 인터뷰는 기술의 빠른 발전과 비교하여 일부 산업에서 여전히 오래된 기술을 사용하고 있음을 보여주며, 이는 흥미로운 대조를 이룸.

[GN⁺]

Hacker News 의견들

• 2016년 원래 HN 제출은 https://news.ycombinator.com/item?id=12096250였음
  “은행 프로그래밍 세계는 우리 대부분이 익숙한 것과 완전히 다른 세계”라는 주제에 더 읽을거리를 찾는다면 An oral history of Bank Python도 좋음: https://calpaterson.com/bank-python.html
  예전에 HN에도 올라왔음: https://news.ycombinator.com/item?id=29104047

  • 벌써 7년 전이라니 놀라움. 어머니가 Michigan Algorithm Decoder로 메인프레임을 프로그래밍하던 이야기를 인터뷰하려고 했는데 결국 못 했음
    https://news.ycombinator.com/item?id=12097032

• “20살 메인프레임 프로그래머라면 나이가 엄청난 가치가 있으니 고액 연봉을 받을 것”이라고들 자주 생각하지만, 현실은 보통 평균적이거나 심지어 평균 이하라서 인재 파이프라인 문제가 생김
  진짜 가치 있는 건 “COBOL을 안다” 같은 기술 자체가 아니라, COBOL 속에 쌓인 거대한 업무 로직에 대한 조직 지식임. 평균적인 개발자도 COBOL은 배울 수 있지만, 은퇴한 COBOL 프로그래머가 연 50만 달러 계약으로 돌아오는 건 COBOL 때문이 아니라 누적된 기관 지식 때문임
  은행과 기관들이 젊은 메인프레임 프로그래머에게 정말 고액을 줬다면 지금의 인구 구조 문제는 덜 심했을 것임

  • 대학원에서 그런 상황에 있던 사람을 만났음. 그는 은행에서 일하다 금융위기 때 해고됐고, 은행은 기존 시스템을 Java 같은 것으로 이전하려고 했음
    프로젝트가 거의 끝났다고 보고, 재작성 팀이 COBOL에 충분히 익숙해졌으니 나머지는 그 없이 할 수 있다고 판단했지만, 실제로는 COBOL은 이해해도 그의 기관 지식이 절실했음. 결국 그는 전환이 끝날 때까지 터무니없이 높은 컨설팅 단가로 파트타임 복귀했고, 그동안 대학원을 병행하며 역량을 키웠음
  • 대형 보험사에서 COBOL 핵심 시스템을 다뤘는데 완전히 동의함. 회사가 돈을 낸 건 COBOL 지식 자체가 아니라, 코드 안의 문서화되지 않은 특이점과 함정을 아는 사람들이었음
    괜찮은 프로그래머라면 COBOL 프로그램을 읽고 따라갈 수는 있음. 하지만 10-K 신고용 데이터 추출 중 핵심 내보내기가 왜 죽는지는 모름. 누군가 특정 레코드 수가 3000을 넘지 않을 거라고 보고, 그 값을 넘으면 그냥 오류를 내도록 하드코딩했기 때문임
  • 처음 일할 때 은행/보험 메인프레임 업무를 했는데, 근무 환경은 복장 규정 같은 사소한 것부터 끔찍하게 낡은 레거시 코드베이스 같은 난해한 것까지 꽤 별로였음. 돈을 잘 줬다면 참았겠지만 그렇지도 않았음
    실제로는 전 직장인 물리 케이블 설비 설치, 즉 광섬유와 구리 이더넷 설치보다 훨씬 적게 받았고, 그 일을 택한 이유도 사무실에 에어컨이 있다는 정도였음. 경력으로 삼고 싶은 일은 아니었음
    클라우드 제공사에서 고객 응대 전화 지원을 하는 중급 Windows 시스템 관리자로 일할 때 은행/보험사의 주니어 메인프레임 담당 때보다 거의 30% 더 벌었음. 희소한 기술이고 고가치 산업인데도 메인프레임 일이 훨씬 낮게 보상됐고, 그 회사에서는 메인프레임 개발자가 모든 경력 수준에서 개발자 중 가장 낮은 보상을 받았음. 제대로 보상받던 사람은 은퇴 전 30년 일했던 독립 계약자뿐이었음
  • COBOL 경험이 있고, 메인프레임에서도 해봤으며 다시 할 의향도 있음. COBOL 프로그래머 기준으로는 아직 젊어서 누군가는 나를 20년 더 활용할 수도 있음
    하지만 그런 역할의 임금은 다른 기술로 받을 수 있는 보상에 비해 처참하고, 현대 생활은 더 큰 급여를 좇도록 강하게 압박함
  • 실제로 그런 경우가 있음. 미국에 본사를 둔 다국적 은행에서 일했는데, 본사 팀이 최근 컴퓨터과학 졸업생을 데려오기 위한 화려한 프로그램을 만들었음
    이 프로그램은 업계 초급직의 “공정한” 시장가를 제시하고, 첫해에 2~3개 팀이나 부서를 경험하게 했음. 끝날 때 회사가 여전히 마음에 들어 하면 후보자가 정규직으로 갈 팀을 고를 수 있었지만, 급여 인상은 없었고 그 시점에는 빠르게 성과를 내지 못한 사람들은 이미 걸러진 상태였음
    회사 입장에서는 결과가 훌륭했음. 새 동료보다 COBOL에 더 능숙한 젊은 프로그래머들을 연 6만~7만 달러에 쓸 수 있었고, 시니어 또는 장기 근속 동료들은 경우에 따라 20만~40만 달러를 받았음

• 할머니는 천공 카드로 프로그래밍했는데 어떤 하드웨어였는지는 모르고, 이제 물어보기엔 늦었음. 아버지는 소련 메인프레임에서 Fortran과 COBOL을 많이 했고, 이후 미국에서 Y2K 작업도 많이 했음
  그중 가장 멋진 물건은 아버지가 예전에 찍은 산 사진의 64mm 대형 필름을 감싸려고 세 조각으로 찢어 쓴 Fortran 프로그램 출력물임. 아마 Minsk-32 메인프레임에서 나온 것 같고, 프로그램 이름은 MATR1이며 행렬 조작을 하고 주석에는 지형을 언급함. 지금은 작업대 근처 벽에 액자로 걸어두었음
  나도 평생 여러 언어로 코딩해왔고, 이제 10대 자녀가 고등학교에서 Java와 Python을 하며 코딩에 관심을 보임. 4대째 프로그래머를 향하여

  • 세대를 따라 같은 코드베이스가 전해지는 영화 아이디어 같음. 레거시 코드라는 제목이 어울림

• 기술 관점에서 은행의 가장 중요한 자리라는 말이 맞다면, Nordea의 스웨덴 및 북유럽 시장 점유율을 감안할 때 그 팀이 사라지면 스웨덴, 어쩌면 북유럽 경제까지 흔들릴 수 있음. 그러면 EU에도 꽤 영향을 줄 것 같음
  이 글을 읽은 뒤로, 이런 은행을 굴러가게 하는 COBOL 프로그래머들이 세계 여러 경제권에서 엄청나게 과소평가된 버스 팩터가 아닐까 계속 궁금했음. 그런 상황에 대한 백업 계획이 무엇인지도 궁금함
  [0] https://en.wikipedia.org/wiki/Nordea

  • APL 프로그래머도 비슷한 상황일지 궁금해짐. 꽤 많은 대기업이 APL을 쓰는 것으로 알고 있음
  • 그런 상황의 백업 계획이란 악명 높게도 몇 주 동안 작동을 멈추는 것일 수 있음: https://en.wikipedia.org/wiki/TSB_Bank_(United_Kingdom)#Migration_to_the_Sabadell_Proteo_banking_platform
    그 참사에는 기관 지식 상실이 큰 요인이었을 것이라고 봄
  • 버스에 치여 본 프로그래머로서, 그것도 서부 그리스 종점까지 5시간 타고 간 바로 그 버스에 치였던 입장에서 말하면, 차에 치여 죽을 위험이 훨씬 큼
    보행자와 자전거 이용자에게 더 위험한 SUV 판매 증가까지 더하면, 은행이 죽은 프로그래머 때문에 무너지지 않고 나쁜 회계와 사기로 무너진다는 사실이 오히려 놀라울 수 있음

• “개인 책상이 있었는데 이제는 아무 자리나 골라 앉는 열린 공간으로 옮겼고 정말 싫다”는 대목이 메인프레임 일을 해본 적이 없어도 이상하게 크게 와닿음

  • 나도 개인 책상을 훨씬 선호함. 사람이 자기 취향과 선호에 맞게 환경을 세팅하는 건 아주 자연스러운데, 일부 사무실 설계자가 그걸 고려하지 않는다는 게 이해 안 됨
  • 우리처럼 대부분 사무실도 “유연 좌석제”라고 해놓고 실제로는 모두 자기 자리가 있어서 출근하면 늘 같은 책상에 앉고, 대체로 서로 그걸 존중하는지 궁금함
    의자, 모니터 위치와 밝기, 책상 높이 등이 자기에게 맞춰져 있으니 핫데스킹 개념 자체가 우스워짐. 차라리 공식적으로 포기했으면 좋겠음

• 금융 서비스 분야에서 시스템 통합 컨설턴트로 일할 때 이런 코어 뱅킹 시스템과 통합을 많이 해야 했음
  보통 완전히 새 인터페이스를 협상하면 기술적·사업적·규제 준수 측면의 마찰이 커서 프로젝트가 1~2년 이상 쉽게 밀릴 수 있었기 때문에, 이전 프로젝트의 기존 통합 지점을 재사용하려고 했음
  통합은 대개 야간 일괄 처리를 위해 저녁 특정 시각 전까지 구조화된 문서를 전달하는 방식임. 오프셋 기반 데이터 문서에는 향후 업데이트와 사용을 위해 아직 배정되지 않은 영역이 설계상 들어 있고, 새 정보가 필요하면 그중 어떤 바이트를 쓸 수 있는지 협상함
  데이터 추출 쪽에서는 좀 더 “현대적인” API를 찾을 때도 있지만, 세밀한 REST 같은 것을 너무 기대하면 안 됨. 비용이 큰 신규 개발을 피할 방법을 찾기 위해 규제와 준수 담당자와 회의하는 일이 잦음
  덧붙이면, 준수 담당자들이 IT보다 훨씬 실용적이고 해결 지향적일 때가 많았음. 규정의 문구가 반드시 가장 제한적으로 문자 그대로 해석되어야 한다는 뜻은 아니라고 우리 팀을 설득하는 일이, 준수 담당자와 합의하는 것보다 더 어려울 때가 많았음
  이런 통합 층이 수십 년 동안 수백 개 프로젝트로 쌓였다고 상상하면, 왜 코어 시스템 교체가 그렇게 어려운지 처음으로 감이 올 것임

• 장모님은 보험사 IT 부서에서 평생 일했음. 프로그래밍을 많이 하진 않았지만 시간이 지나며 도메인 지식의 원천이 되었음
  예전 이야기가 많음. 제대로 된 컴퓨터 시스템 이전에는 당연히 모든 것이 물리 문서로 저장됐고, 대학 졸업 후 첫 프로젝트는 본사가 세운 새 전략에 맞게 지점의 파일 시스템을 재정리하러 위성 사무소들을 돌아다니는 일이었음
  팀이 말 그대로 모든 문서를 꺼내고 라벨을 다시 붙이고 다시 넣는 동안 그 지점 업무는 멈췄고, 전체 프로젝트는 1년 넘게 걸렸음. 내 일에 대한 관점이 좀 달라졌음

  • 당시 은행들이 종이의 한계를 밀어붙이던 걸 생각하면, 현대 은행의 복잡성은 상상하기 어렵다. 금융을 충분히 몰라서 어디서부터 감을 잡아야 할지도 모르겠음

• 할머니가 치매에 걸리기 전에 더 많이 이야기해둘 걸 그랬음. 수학자이자 프로그래머였다는 건 알았지만, 몇 년 전 잠깐 이야기할 때 소련에서 위성 궤도를 계산하는 일을 했다고 했음
  적어도 위성이었길 바람

  • 비슷한 처지임. 어머니는 AEGIS 시스템용 소프트웨어 시뮬레이션을 다뤘음. 1980년대 흑인 여성에게는 흔한 일이 아니었음
    20살에 3년 만에 수학 학위를 땄고, 1970년대에는 천공 카드로 컴퓨터를 프로그래밍했음.
    이제는 신발 끈도 안정적으로 묶지 못함. 너무 늦기 전에 사랑하는 사람들의 성취와 삶의 이야기를 기록해두길 바람
  • 이런 일을 생각해본 적이 있다면 꼭 해보길 권함. 시작 방법을 고민한다면 StoryCorps 앱을 추천함
    쓰기 쉽고 미리 만들어진 질문도 많으며 직접 질문을 만들 수도 있음. 휴대폰에 바로 녹음하고, 원한다면 인터뷰를 미국 의회도서관에 업로드할 수도 있음
    https://storycorps.org/participate/storycorps-app/
  • 둘 다였을 수도 있음: https://en.wikipedia.org/wiki/Fractional_Orbital_Bombardment_System#Development_history_and_deployment

• 할머니가 올해 95세가 되었음. 아직도 구소련권의 연구소에 매일 출근해 Fortran과 Maple로 수치 시뮬레이션을 작성함
  동료들은 여전히 은퇴를 원하지 않고, 할머니도 매년 은퇴를 미루고 있음. 수치해석과 수학 지식이 탁월해서 정말 자랑스러움

• 첫 프로그래밍 일자리는 운송 기업이었고, 15~20년 이상 일한 프로그래머가 많았으며 그중 상당수는 사업을 돌리는 COBOL을 주로 유지보수했음
  그 시니어 프로그래머들 중에는 여성이 많았고, 시니어 그룹에서는 50%를 넘는 느낌이었음. 슬펐던 건 젊은 프로그래머들은 여전히 여성도 꽤 있었지만 대체로 남성이었다는 점임
  그 회사는 주로 지역 공대에서 채용했기 때문에, 시간이 지나며 소프트웨어공학 전공에 진입하는 여성 수가 어떻게 줄었는지 보여주는 흥미로운 사례처럼 보였음

  • 옛날에는 컴퓨터 프로그래밍이 타자나 비서 업무와 비슷하게 여겨져서 처음에는 주로 여성들을 끌어들였다고 들은 기억이 있음