사람들이 여전히 VBA를 사용하는 이유

• 많은 조직에서 Excel이 업무 프로세스의 기반이 되면서, 작은 자동화가 필요할 때 VBA가 사실상 기본 선택지가 됨
• 사례 조직은 13개 데이터 플랫폼과 여러 자동화 도구를 갖고 있지만, 필요한 데이터 소스에 폭넓게 접근할 수 있는 도구는 VBA와 PowerShell 정도로 좁혀짐
• CyberSecurity가 Python, Ruby, Node, Rust 같은 고수준 언어 설치를 거부했고, 대안인 Power Platform은 데이터 접근성과 복잡한 알고리듬 유지보수에서 한계를 보임
• Lotus Notes와 IBM BPM 이전 사례는 IT 주도 시스템이 지원 종료, 미완성 마이그레이션, 유지보수 공백에 취약할 수 있음을 보여줌
• VBA는 낡고 약점도 있지만 Office에 포함되어 누구나 접근할 수 있고, SME가 업무 로직과 데이터 이전을 직접 검증할 수 있는 통제권을 제공함

---

VBA가 계속 선택되는 직접적인 이유

• 2021년 /r/vba 설문에서 VBA 사용자의 다수는 다른 선택지가 없어서 VBA를 쓴다고 답함
• 많은 조직은 전체 업무 프로세스를 Excel로 운영하며, 약간의 자동화가 필요할 때 VBA가 가장 먼저 선택되는 경우가 많음
• “스프레드시트로 인프라 일부를 제어한다”는 비판 뒤에는 조직이 제공하는 도구, 데이터 접근성, 유지보수 구조의 제약이 있음

데이터 접근성과 자동화 도구의 제약

• 사례 조직의 엔지니어링 부문은 여러 자동화 플랫폼을 사용할 수 있음
  • OnPrem: PowerShell, Excel의 VBA / 제한된 OfficeJS / OfficeScripts / PowerQuery, PowerBI Desktop, SAP Analysis for Office
  • OnCloud: PowerApps, Power BI, 비프리미엄 PowerAutomate
  • 샌드박스 환경: ArcGIS의 ArcPy, MapInfo의 MapBasic, InfoWorks ICM의 Ruby, ArcGIS Online
• IT가 관리하는 데이터 플랫폼은 D1부터 D13까지 있으며, 지리공간 DB, SAP DB, 텔레메트리 플랫폼, SharePoint, Lotus Notes, IBM BPM, 파일 시스템, Hydraulic Model Information 등을 포함함
• 필요한 데이터 소스에 연결할 수 있는 자동화 플랫폼은 VBA와 PowerShell 정도로 정리됨
  • Power BI Desktop은 조직에 도입되었지만 VBA가 접근하는 모든 플랫폼을 포괄하지 못함
  • 접근 범위가 같더라도 Power BI는 프로세스 자동화에 쓰기 어렵고, 다른 데이터셋을 다루려면 CSV를 만들어 SharePoint에 저장하는 방식이 쓰임
  • 그 CSV 생성도 VBA가 맡는 경우가 있음
• VBA의 일부 OnCloud 서비스 연결은 직접 시도에 기반하며, SAP BW4HANA와 다른 클라우드 서비스도 VBA로 인터페이스할 수 있다고 보지만 인증 요구사항과 프로토콜은 아직 해결되지 않음

고수준 언어와 Power Platform의 한계

• 조직은 업무 자동화를 위해 Python, Ruby, Node, Rust 같은 고수준 언어를 쓰고 싶어 했지만, 팀이나 비즈니스 전반에 설치하는 요청은 CyberSecurity에 의해 모두 거부됨
• 거부 이유는 최종 사용자에게 고수준 프로그래밍 언어 접근을 허용하는 것이 회사의 기술 전략 비전에 어긋난다는 것이었음
• 대안으로 거론되는 PowerAutomate, PowerApps는 필요한 데이터에 거의 접근하지 못함
• 데이터 접근이 가능하더라도 Power Platform은 대부분의 프로세스를 수행하기에 부족함
  • 필요한 알고리듬이 복잡해 PowerAutomate 솔루션은 유지보수가 어렵고 IT 인력에게도 이해하기 힘들 수 있음
  • 예시로 projection algorithms이 언급됨
• 결국 실용적으로 남는 도구는 PowerShell v3와 VBA임
  • PowerShell v3는 클래스 문법을 지원하지 않고 모듈 설치도 불가능함
  • VBA는 현대적 기준에서 합리적인 언어로 보강하기 위해 수백 시간을 들여 open source VBA libraries를 만들게 된 대상임

유지보수 보장으로서의 VBA

• 2000년대에 많은 시스템이 IBM Lotus Notes 데이터베이스 위에 구축됨
• Lotus Notes는 2019년 HCL에 인수된 뒤 지원 지속성이 흔들렸고, 2024년 6월 공식 지원 종료가 예정돼 있었음
• 2019년부터 기술팀은 여러 시스템을 새 기술로 이전하려 했고, 조직은 Lotus Notes DB 하나를 대체하기 위해 IBM Business Process Manager 기반 시스템 개발에 큰 비용을 투입함
• 계획은 D11에 D10 데이터를 모두 채운 뒤 D10을 아카이브하는 것이었지만, 2023년 시점의 상태는 달랐음
  • 공식 지원 종료까지 8개월 남음
  • 기술팀은 IBM BPM 지원 계약을 없앰
  • IBM BPM과 Lotus Notes DB 모두에 대한 대체 시스템이 보이지 않음
  • IBM BPM 솔루션은 유지보수가 부족하고 필요한 대로 동작하지 않음
  • 목적에 맞지 않는 솔루션을 IBM BPM에 억지로 넣은 상태임
  • REST API가 있지만 기술팀과 SME에게 거의 쓸모가 없음
    • 일부 REST 호출은 문자열로 인코딩된 JavaScript를 사용함
    • 다른 호출은 XML 안의 JSON 안에 HTML을 넣어야 함
    • DB 테이블은 이름이 아니라 GUID로 쿼리됨
    • 어떤 GUID가 어떤 테이블이나 프로세스에 대응하는지 문서가 없음
  • D10 데이터는 실제로 D11로 이전되지 않아 비즈니스는 1개가 아니라 2개 시스템을 쓰고 있음
  • D11 데이터 모델도 D10 데이터를 제대로 지원하지 않음
• SME는 도구를 매일 사용하고 시스템 변경 필요사항을 결정하는 주체임
• SME가 VBA를 쓰면 필요한 만큼 시스템을 직접 통제하고 유지할 수 있으며, 이는 IT 시스템에서는 보장되지 않는 유지보수 보장으로 작동함

통제권과 SME 협업 문제

• 최근 프로젝트는 비즈니스 핵심 스프레드시트를 대체하는 새 통합 IT 시스템을 만드는 것이었고, 성공하면 D6의 중요도는 C 등급으로 내려갈 예정이었음
• 초기 명세는 단순했음
  • NodeJS 서버와 MySQL 데이터베이스
  • React UI
  • 관리자와 SME에게 코드베이스와 git 접근 권한 제공
  • IT와 SME가 협업해 시스템 구축
• 기술팀은 다른 요구를 내놓음
  • 관리자와 SME는 코드에 접근하지 못함
  • 프런트엔드는 “Strategic Vision”에 맞춰 Microsoft PowerApps로 구축함
  • 백엔드는 “Strategic Vision”에 맞춰 Microsoft Azure Pipelines로 구축함
• SME 입장에서는 이 요구가 여러 문제를 만듦
  • 기술팀은 현업 업무를 이해하지 못하므로 비즈니스 로직과 계산을 이해하기 어려움
  • 개발자가 비즈니스 로직을 작성하면 오류가 생기기 쉬움
  • 기술팀은 맞춤형 기술 프로젝트를 자주 방치해 유지보수와 개선 리소스가 사라짐
  • SME와 협업하면 최소한 한 팀은 시스템 유지 리소스를 유지할 수 있음
  • SME는 산출물을 신뢰할 수 있어야 하지만, 코드가 보이지 않으면 모든 엣지 케이스에서 동작하는지 확인하기 어려움
  • 단위 테스트가 있더라도 코드가 보이지 않으면 테스트가 존재하고 자주 실행되는지 검증하기 힘듦
  • SME는 기존 레거시 시스템을 개선·유지하고 시스템 간 상호작용에 대한 지식이 많음
  • 새 시스템으로 모든 데이터가 정확히 이전되고 표현되는지 확인하려면 백엔드 접근이 필요함
• 코드가 VBA에 남아 있으면 SME와 비즈니스가 통제권을 유지함
• 기술팀은 비즈니스 팀에 통제권을 거의 넘기지 않으며, SME는 소프트웨어가 모듈식으로 제대로 개발되고 느슨하게 이어진 기술 덩어리가 되지 않도록 확인할 수 있음

익숙한 환경 안의 사용자 경험

• 대부분의 엔지니어는 일상 업무에서 스프레드시트를 사용함
• VBA는 스프레드시트 안에 내장되어 있어 익숙한 환경에서 낯선 도구를 제공할 수 있음
• 낯선 환경에서 낯선 도구를 제공하는 것보다, 익숙한 환경 안에 새로운 기능을 넣는 편이 사용자에게 더 강력할 수 있음

결론: VBA의 약점과 현실적 선택

• 조직이 스프레드시트와 VBA를 선택하는 이유는 여러 가지임
  • 보안 우려 때문에 IT가 제공하는 대안이 빈약함
  • 대안 도구가 소스 시스템에 제대로 연결되지 못하며, 보통 아직 진행 중인 상태임
  • 일부 사용 사례를 반영하지 못한 IT 전략 문제가 있음
  • 보안과 유지보수 우려 때문에 SME와 협업하려 하지 않음
  • 사용자, 관리자, SME가 대체 시스템 교육을 충분히 받지 못함
  • 사용자와 SME는 시스템의 비즈니스 로직에 대해 일정 수준의 통제권을 원함
  • Office에 포함되어 모두가 사용할 수 있는 유일하게 실행 가능한 기술임
• VBA의 약점이 없는 것은 아님
• mataroa의 글에는 일부 맞는 부분이 있음
• 때로 관리는 형편없지만, 조직의 많은 사람은 주어진 도구 안에서 옳은 일을 하려고 노력함

[GN⁺]

Hacker News 의견들

• 기업에는 비재고 소프트웨어 승인을 받기 위해 관리층, 상위 관리층, 프로젝트 등록, 예산, 프로젝트 매니저 배정 등을 거치지 않아도 되는 개발 환경이 이미 Excel 안에 있음
  네트워크 데이터 저장소와 웹 인터페이스까지 원하면 SharePoint를 붙이면 됨. 이런 최종 사용자 방향에서 해법이 나오고, 그 해법은 VBA로 만들어짐

  • 기업이라는 디스토피아적 환경에서는 자기 기기에 소프트웨어를 요청하거나 설치할 수 있다고 기대하면 안 됨. 이미 있는 것만 쓸 수 있고, 바꾸려면 관료제와 싸워야 해서 가치가 없음
    예전에는 Word VBA로 만든 끔찍한 보고 엔진이 파일 공유에서 보고서 정의를 읽고 템플릿 조각을 잘라 붙인 뒤 출력했음. 퇴사자가 쓰던 PC를 IT가 회수하지 않아 그걸로 하루 종일 .doc를 돌려 엔지니어링 보고서를 만들었는데, CAD/CAM 소프트웨어의 보고 옵션을 구매하는 것보다 훨씬 빠르고 쌌음. 그 옵션은 최소 18개월, 컨설턴트, 프로젝트 예산 소모가 필요했을 것임
    사람들이 Excel VBA로 끔찍한 일을 한다고 욕할 때, 원인은 더 위쪽 스택에 있을 가능성이 큼. 또 다른 원인은 “원숭이 망치”인데, 원숭이에게 망치를 주면 뭐든 두드리듯 가진 도구가 VBA뿐이면 모든 것이 VBA 해법처럼 보임. 지금은 조금 더 진화한 영장류가 됐음
  • 부서 관리자가 뭔가 필요하지만 개발팀을 귀찮게 할 수 없거나 그러기 싫어서 “이게 얼마나 어렵겠어”로 시작하는 장면을 적어도 두 번은 봤음. 그러다 보면 어느새 몇백 줄짜리 VBA가 생겨서 자기 필요를 해결함
    다음 단계에서는 Jim도 돌리고 싶어서 스크립트가 복사되고, Jane은 다른 VBA 버전을 써서 수정되고, 이제 “이것도!” 하게 되며 확장됨. 결국 1500줄짜리 누더기가 되고, 유지보수를 개발팀에 넘기려 함
  • 친구가 Excel로 자기 일을 전부 자동화했음. 하루치 일을 15분에 끝내고 나머지는 쉬는 식이라고 함
    회사 컴퓨터는 매우 잠겨 있어서 아무것도 설치 못 하고, 화이트리스트에 없는 사이트도 못 가지만 Excel은 있음
  • Visual Basic 자체도 매우 강력한 언어임. Excel 매크로 같은 환경에서는 그 힘을 꽤 크게 끌어낼 수 있고, 많은 기업의 파워 유저들이 실제로 그렇게 씀
    예전의 “Emacs 운영체제” 패러다임을 다른 맥락에 적용한 것과 꽤 비슷함
  • VBA는 거기 있고, 작동함. 코딩하고 반복하기에 매우 접근성 좋고 직관적인 언어이며, 외부 의존성 설치나 라이브러리 지옥, 컴파일 단계로 시간을 낭비하지 않아도 됨
    그래서 VBA가 기업에 여전히 매우 가치 있는 건 놀랍지 않음. 다른 도구와 언어, 성숙한 빌드 절차가 있는 환경에서도 제품 매니저들이 VBA로 입이 벌어질 정도로 복잡한 비즈니스 분석을 하는 걸 봤고, 손에 쥔 문제에는 그게 맞는 도구였음

• 전문 개발자들도 Excel/VBA를 보조 도구로 많이 쓰는 걸 보고 놀랐음
  몇 년 전 큰 헤지펀드와 일할 때 데이터 분석가가 직접 만든 Excel 모델을 보내줬는데, .xlsm 확장자를 보고 VBA 코드가 들어 있구나 싶었음. “매크로 녹화 카우보이들이 뭘 했나 보자” 했는데, 내부에는 VBA가 많았고 작성자는 Caltech 컴퓨터과학 출신에 Python을 아주 잘하는 데이터 분석가였음
  VBA는 데이터베이스에서 데이터를 가져와 시트에 넣고, 수식을 만들고, 보기 좋게 서식을 입히는 용도였고 UserForm도 몇 개 있었음. “VBA요? 거긴 또 뭐 써요? 조면기랑 증기삽?” 하고 놀렸는데, 예상과 달리 Excel과 VBA를 크게 칭찬해서 놀랐음
  그가 한 말이 기억에 남음. “Excel은 계산이 암시하는 의존성 구조를 이해하기 쉽게 해줘요. 이걸 Python으로 했으면 하루 종일 질문에 답하고 있었을 겁니다”

  • 개발자로 경험이 쌓일수록 일에 맞는 도구를 쓰는 게 중요해짐. 게으른 해법이 이해 불가능한 아이디어 덩어리보다 훨씬 나을 때가 있음
  • VBA에는 문제가 있긴 하지만(https://sancarn.github.io/vba-articles/issues-with-vba.html), 최악의 도구와는 거리가 멂. 예를 들면 PowerAutomate 같은 것보다 나음
    VB6에는 꽤 큰 커뮤니티가 있고, https://twinbasic.com/이 최근 VBA와 VB6 커뮤니티를 통합하는 데 많이 도움을 줬음. 그래서 개발자 커뮤니티에서 약간의 부활이 있을 수도 있음
  • 운영하는 사업이 Google Sheets에 크게 의존함. 값을 주입하고 계산된 값을 읽어오는 방식으로 꽤 복잡한 비즈니스 로직을 스프레드시트 형태로 정의할 수 있고, 사업·재무 담당자들이 쉽게 조정할 수 있음. 모두 이 해법에 매우 만족함
  • Excel은 많은 일에 훌륭한 인터페이스이고, 어느 정도까지는 사람들이 데이터를 이해하는 데 도움을 줌. 반대로 사람들은 그 데이터 모델에 익숙해져 있어서, 조금 복잡해지면 질문하지 않고 자기 탓으로 돌리는 경향도 있음
    스웨덴에는 38쪽짜리 사용자 설명서가 딸린 3GB Excel/VBA 연금 예측 모델도 있음. 그런데 Excel을 아주 잘 활용한 사례라고 보긴 어려움: https://www.pensionsmyndigheten.se/statistik-och-rapporter/p...
  • 대형 대학병원의 수술 전 입원 클리닉을 Excel로 운영했음
    VBA는 강력하고 프로토타이핑과 반복이 빠름. 심지어 VB6가 CRUD 앱의 정점이었다고도 말할 수 있음

• “놀랍기 때문”임
  예전에 JP Morgan 네트워크에 Access 데이터베이스가 2만 개 넘게 있었다는 얘기를 들었음. 여러 회사의 데이터 분석가들은 어느 날 매일 하는 일이 싫어졌고, “매크로 기록” 버튼을 살펴봄. 어떤 사람은 그게 꽤 편하다고 느끼고 계속 사용함. 더 똑똑하게 굴어 매크로가 뱉은 코드를 들여다보고, 조금 배워서 바꿔보려는 사람도 생김
  소수는 자료구조와 알고리즘까지 배워 Django를 흉내 낸 인증·권한 시스템을 만들고, UserForm UI를 처음부터 다시 만들고, Markdown, SAX 파싱, 커스텀 스크롤바, 로깅, 게임까지 구현함
  답은 아마 데이터 분석가가 매일 하는 일에 지루해졌기 때문임

  • IT 부서가 상아탑에서 너무 많은 절차를 내려보내서 사람들이 섀도 IT로 밀려난 것일 수도 있음. 대기업에서 분석가들이 자신들이 만든 프랑켄슈타인을 제대로 된 수준으로 끌어올릴 능력이 있는데도 “프로젝트를 시작하고 티켓, 일정, 요구사항을 만들어야 한다”는 식으로 막히는 걸 봤음
    물론 누구나 들어와 배워야 하는 무언가를 지원해야 한다는 건 타당한 우려임. 하지만 비즈니스가 문제를 해결할 도구에 접근할 수 있는 한, “지루한” 사람들은 방법을 찾음. 마찰이 너무 큼
  • “매크로 기록”이 핵심임. Microsoft가 C#, JavaScript, Python 등으로 바꾸더라도, 그 버튼만 붙이면 가능함
  • 금융에서 시작해 데이터 엔지니어링이나 시스템 구현 쪽으로 옮기는 많은 사람들과 같은 경험임
    Excel 안에서 어느 정도 복잡한 걸 만들고 네트워크 공유에 올리는 편이, IT를 거쳐 IDE를 설치하고 뭔가 만들고 보안 절차를 거쳐 배포하는 것보다 쉽기 때문에 당분간 끝나지 않을 것 같음. 모든 문제가 Jira 프로젝트와 과하게 복잡한 해법을 필요로 하지는 않음
    다만 큰 것을 VBA로 만드는 데는 전적으로 반대함. 몇 개 셀 값 변화에 따라 한 시스템의 큐브를 조회하고 다른 시스템의 테이블 데이터와 합치는 작은 스크립트 정도는 괜찮지만, 어느 지점부터는 다른 곳으로 가야 함
    대부분의 프로젝트에는 서버 라이선스가 있어 자동화할 수 있다는 전제하에 Alteryx+Tableau/PowerBI 스택을 매우 선호함
  • 솔직히 비슷한 걸 했다가 C#으로 옮겼고, 지금은 그냥 소프트웨어 개발자가 됐음

• 분석가들을 위한 간단한 CRUD 인터페이스를 만들어야 했음
  첫 문제는 분석가들이 모든 CRUD 단계를 Excel 안에서 처리하길 원했다는 것임. Excel이 실제 인터페이스였으므로 Excel 안에서 실행할 수 있는 뭔가가 필요했음
  IT 부서는 명령줄 접근을 허용하지 않았고, 승인되지 않은 개발 도구 설치도 거부했음. 승인받으려면 몇 달이 걸릴 수 있었음. 데이터베이스 관리자들은 기존 Oracle DB에 새 DB를 추가하는 걸 탐탁지 않아 했고, IT 부서는 직접 DB를 운영하는 것도 싫어했음
  심지어 Excel에 새 추가 기능을 넣는 것만으로도 IT 담당자에게 빌어야 함. 운이 좋으면 어느 날 갑자기 추가 기능이 나타나지만, 하루가 걸릴지 일주일이 걸릴지 한 달이 걸릴지는 모름
  그래서 현실적인 유일한 대안은 VBA였고, 결국 분석가들이 2주에 한 번 쓰는 임시 고정 해법을 띄우는 데 성공함

• 어느 정보기관에서 일할 때 아프가니스탄에 배치된 사람들을 위한 앱을 만들어야 했음. 그들이 쓸 수 있는 컴퓨터는 잠긴 Windows XP뿐이었고 새로 설치할 방법이 없었음
  이미 검증되어 설치된 Office에 묶여 있었기 때문에, Linux를 쓰는 사람인 나도 Office에 묶였음. 순수 VBA만으로 꽤 많은 프랑켄슈타인을 만들어 좋은 평가를 받았음

  • 중동에 배치됐던 입장에서도 같은 경험임. 완전히 망분리된 XP 컴퓨터에서 VBA로 가능한 많은 부분을 자동화했음
  • 비슷하지만 같지는 않은 상황에서, script 태그에 JavaScript 코드를 넣은 HTML 파일로 버텼음. 기계가 망분리였는데도 IE 실행이 막혀 있었던 건지, 아니면 JavaScript보다 VBA가 더 편했는지 궁금함

• 인정하자면 IT는 현대의 관료제 부서이고, 스스로 만든 문제로 95% 바쁘며 서비스 지향성은 5%쯤임. 외부자에게 프로세스는 불투명하고 보통 도움이 안 됨
  IBM BPM 설명에서 이런 부분을 읽고 정말 웃었는데, 문제의 상당 부분을 잘 요약함
  “IBM BPM에는 REST API가 있긴 하지만, 이 REST API는 기술팀과 중소기업에는 거의 쓸모없다. 어떤 REST 호출은 문자열로 인코딩된 JavaScript를 쓰고, 다른 호출은 XML 안 JSON 안 HTML을 요구한다. 데이터베이스 테이블은 이름이 아니라 GUID로 조회된다. 어떤 GUID가 어떤 테이블/프로세스와 연결되는지 문서가 없다”
  많은 것들이 터무니없이 복잡해져서 IT 밖의 누구도 다루려 하지 않고, 때로는 IT 안에서도 다루지 않음. AJAX부터 개발 노력의 절반이 프런트엔드 코드와 백엔드 서비스를 설계하는 데 들어가기 시작했는데, 이는 최종 사용자 자동화 문제와는 사실 거의 관계가 없음. 그 뒤로 더 나빠졌고, 요즘 UI는 현대적으로 보이지만 만드는 데 쓰인 기술 스택만큼이나 사용자에게 적대적임
  Excel에서는 UI가 그냥 “거기” 있고, 매크로 기록기라는 코드 생성기도 있으며, IT 부서가 내 권한을 따지거나 내 비즈니스 문제를 도울 시간과 예산이 없다고 하지도 않음. 그래서 VBA는 사용자가 IT 부서를 우회하는 우회로임. 완벽하진 않지만 다른 대안보다는 나음

  • VBA는 궁극의 애자일 프로그래밍 언어임. 회사 IT, 즉 관료제 부서는 Scrum, Squad 같은 것에 묶여 있지만, 다른 부서 사람들은 Excel/VBA로 일을 끝냄
    달라진 건 없음. 지난 세기에도 이런 일이 있었고 자동화의 섬이라고 불렸음. 당시 내 주변에서는 좋은 전략으로 여겨졌고, 부서들이 먼저 가지고 놀게 한 뒤 가능성이 보이면 통합했음
  • 충분히 오래 찾으면 어느 부서에서든 나쁜 예시는 찾을 수 있음. IT가 관리하는 것들 중에도 제정신이 아닌 수준에 가까운 것이 있느냐면 당연히 있음. 하지만 그게 섀도 IT를 만들 좋은 변명은 아님
    분석가 몇 명이 모여 자기들만의 작은 VBA 도구를 해킹하는 건 전혀 거슬리지 않음. 그런 정신은 칭찬할 만하고, 그 결과 내 일상을 더 잘 이해하게 될 수도 있음
    거슬리는 건 그 분석가들이 어느 순간 자기 개인 프로젝트에 맞춰 내 시스템 아키텍처가 어떻게든 수용해주길 기대할 때임. 문서를 달라고 하면 없고, 아키텍처 개요도 없고, 그 괴물의 저장소 접근 권한을 달라 하면 “저장소가 뭐죠?”가 됨
    왜 그들의 스프레드시트가 내 처리 파이프라인에 데이터를 주입하면 안 되냐고 묻고, YouTube 영상을 반쯤 보고 배운 REST 조각에 맞춰 내가 컨트롤러를 작성해야 한다고 여김. 회의에서 “인증이 필요하다는 게 무슨 뜻이죠? 왜 IT는 항상 일을 복잡하게 만들죠?”라는 질문이 나옴
    VBA든 로우코드든 무엇이든 사람들이 도구를 만드는 건 좋음. 나도 같은 일을 하고, 다만 나는 그것을 셸 스크립트라 부르며 Git 저장소에 둠. 하지만 내 CLI 도구를 프로덕션 서버에 풀어놓지 않듯, 코드 리뷰 한 번 거치지 않은 것도 그렇게 두지 않을 것임
  • 첫 정규 소프트웨어 엔지니어링 일 중 하나가 은행 트레이딩 플로어에서 통화 트레이더 옆에 앉아 일하는 것이었음
    나를 고용한 건 시장위험관리 책임자였고, 그는 은행이 하루에 너무 많은 돈을 잃지 않게 하는 역할이었음. 공식 승인된 IT 부서가 자기 알고리즘 구현 코드를 제대로 쓸 것이라 믿지 못해서 나를 고용했음. 예를 들어 그들은 곱셈이 덧셈보다 우선한다는 연산자 우선순위를 이해하지 못해 틀린 적이 있었음
    시장위험 계산에 모든 거래를 입력으로 넣어야 했고, 2000년대 초였던 당시 책상 밑 PC에 Apache와 Perl CGI를 설치해 트레이더들이 거래를 입력하고 포지션을 추적하는 작은 앱을 만들었음. 트레이더들은 공식 IT 해법보다 쓰기 쉽고 포지션을 보기 편해서 이걸 더 선호하기 시작했음
    많은 기업 환경에서는 IT를 우회하는 방법을 찾는 것이 중요한 기능임. Excel로 돌아오면, 트레이더들은 계산과 시뮬레이션에 Excel을 썼고 우리는 Excel에 꽂히는 도구를 제공해 그들이 이미 하던 일을 활용하려 했음
  • 기사에 이게 회사의 명시적 정책 결정이라고 적힌 문장이 있음
    “최종 사용자에게 고수준 프로그래밍 언어 접근을 허용하는 것은 회사의 기술 전략 비전에 반한다”고 되어 있음
  • 답은 이거임. 기업이 설치하지 않기로 선택할 수 없는 유일한 프로그래밍 언어가 VBA이기 때문임
    “엔터프라이즈”의 경이로움임. 사람들이 그걸 장점이나 변명처럼 꺼낼 때마다 놀라움

• 최근까지 좋은 대안이 없었기 때문임. 미래는 새 Office 추가 기능 모델에 있음: https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...
  TypeScript에 대해 뭐라 하든 최소한 VBA보다는 나음. 다만 VBA와 달리 Excel 안에서 바로 프로그래밍할 수 없다는 게 큰 문제임. 가끔은 재사용을 전제로 한 본격적인 추가 기능 프로젝트를 시작하고 싶지 않고, 지금 당장 뭔가 고치기 위해 대충 한 번 실행할 스크립트만 원함. 이걸 쓰다가 Script Lab(https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...)을 알게 됐는데, 도움이 될지도 모르겠음

  • “VBA와 달리 Excel 안에서 바로 프로그래밍할 수 없다”는 건 거의 거래 중단 사유임
    게다가 명백한 질문이 있음. 추가 기능을 권한 없는 사용자가 IT 부서 개입 없이 설치할 수 있는가? 스프레드시트에 포함할 수 있는가? 전자가 “아니오”라면 진짜로 치명적이고, 후자가 “아니오”여도 채택에 악영향을 줌. 매크로와 VBA의 장점은 보안 설정을 제외하면 모든 Excel 인스턴스가 추가 설치 없이 곧바로 실행할 수 있다는 것임
  • 댓글 끝의 Script Lab 언급을 못 봤음. Microsoft Script Lab이면 바로 그걸 할 수 있음: https://www.microsoft.com/en-us/garage/profiles/script-lab/
    다른 문제는 최종 사용자에게 추가 기능을 공유하는 게 사소하지 않다는 점임. 마켓플레이스나 SharePoint에 게시해야 하고, 사이드로드에는 SMB 서버와 GPO가 필요함. 다만 어디에도 잘 언급되지 않는 선택지가 하나 있는데, 문서에 포함시키면 처음 열 때 사용자 확인 후 설치되게 할 수 있음
  • 데이터 입력이나 시각화를 위한 멋진 UI만 보여주는 용도라면 좋지만, OfficeJS는 안타깝게도 VBA가 할 수 있는 일의 절반도 못 함. 추가 기능 시스템에 FFI만 있었다면 영원히 갈아탔을 것임
    또 다른 큰 문제는 OfficeJS를 쓰려면 웹 서버를 호스팅할 수 있어야 한다는 점임. 보통 최종 사용자 대부분은 그런 접근 권한이 없음

• VB(A)는 Python과 비슷함. 예쁘지는 않지만 일을 해냄. 예쁘다고 생각한다면 경험이 부족해서 더 나은 대안을 많이 모르는 것임
  실제 일을 끝낼 수 있게 해주는 좋은 생태계, 즉 도구·라이브러리·통합을 가진 도구는 유용함. 데스크톱 앱 개발 시스템으로서 Visual Basic은, DB 이점을 더한 MS Access와 함께 많은 상황에서 매우 유용했음. 그걸 넘어설 정도가 되면 “진짜” 해법으로 확장할 돈도 있었을 것임
  VBA 기반 시스템으로 엄청난 돈이 벌린 것은 의심할 여지가 없음. 금융 개발을 주로 외부자 입장에서 했던 경험상, 가장 큰 Excel/VBA 재작성은 2008년 전후로 신용부도스와프에서 큰돈을 번 회사의 것이었음. 재작성 전에는 통합 문서가 열리는 데 5분 걸렸지만, VBA가 많은 무거운 일을 처리하고 있었음. 지식을 가진 사람들은 회사와 자신을 위해 보너스로 큰돈을 벌고 있었음
  여기서 배울 점은 도구가 이상적인지보다, 해당 도구를 쓰도록 특별히 훈련받지 않은 사람에게 접근 가능한지가 더 중요하다는 것임. Python이 클라이언트 웹 브라우저 밖에서 1위가 된 이유도 그와 같음. 최고라는 뜻은 아니지만, 일을 해내고 접근 가능하다는 뜻임

  • Python은 예쁜 언어라고 주장할 만하고, 클래스와 일급 함수 지원을 갖춘 완전한 언어이면서도 비교적 단순하고 접근하기 쉬움
    하지만 그게 인기의 유일한 이유는 아님. 가장 견고한 데이터 과학 도구를 갖고 있어서 압도적 효과가 생겼고, Django와 Flask 같은 괜찮은 웹 프레임워크도 있음. 많은 대학에서 Java를 대신해 “첫 학습 언어”가 된 것도 인기 상승의 이유임. VBA는 그렇지 않음
  • Python은 예쁘고, 공백을 쓰는 방식이 중괄호, begin/end, if/else 같은 블록 표시 전략보다 낫다고 봄
    경험이란 예쁜지 아닌지에 주관적 요소가 있다는 것도 아는 것임. VBA는 “가혹한” 조건에서 진화했기 때문에 이상한 점들이 어느 정도 설명됨
  • Python이 Scheme은 아니지만, 프로그래밍 언어 중에서는 확실히 예쁜 편이고 많은 경우 더 나은 대안이 없음. 수십 개 언어로 약 25년 프로그래밍한 기준임

• VBA는 객체지향 프로그래밍을 지원하는 괜찮은 언어임. 상속은 없지만 합성은 가능함. Excel에 깊게 접근하고 제어할 수 있으며, 성숙하고 안정적임. Microsoft가 더 이상 크게 바꾸지 않기 때문임
  “진짜 프로그래머”들이 VBA를 싫어하는 건 대체로 비즈니스 담당자들이 작성한 아마추어식 스파게티 VBA 코드가 많고, 가끔 프로그래머들이 그걸 디버깅해 달라는 요청을 받기 때문임

  • 반론하자면 VBA는 Excel, Word 등에 접근하고 제어할 수 있다는 점을 빼면 끔찍한 언어임
    코드 안의 제어 문자가 지역화되는 등 이상한 특성이 가득함.[1][2] 영어가 아닌 설치본에서도 코드가 돌게 하고 싶다면 Application.International(xlDecimalSeparator) 같은 자리표시자를 써서 해당 함수에 넘기는 문자열을 동적으로 만들어야 하고, 코드 가독성은 크게 떨어짐. 이 이유로 코드가 깨지면 오류 메시지는 믿을 수 없을 만큼 도움이 안 되고, 개발자가 VBA의 잠재적 문제임을 모르면 재현 자체가 사실상 불가능함. 재현하려면 모를 수도 있는 언어로 인터페이스 언어를 바꿔야 함
    적어도 Word에서는 현재 문단 뒤에 문단을 삽입하는 등 가장 유용한 함수의 절반쯤이 표 셀의 마지막 문단에서 쓰면 깨져서, 스파게티식 우회가 잔뜩 필요함
    DOM 요소의 innerHtml 속성을 참조하는 것처럼 여러 서식을 포함한 텍스트 문자열을 주고받고 싶다면, 해키한 스크립트 기반 선택과 복사/붙여넣기를 쓰지 않는 한 쉽지 않음
    다른 스레드에서 Bash와 비교한 사람이 있었는데, 실제로 동의함. 어느 언어로도 복잡한 것을 작성하면 안 됨
    [1] https://stackoverflow.com/questions/20652409/using-vba-to-de...
    [2] https://stackoverflow.com/questions/29832281/vba-range-funct...
  • VBA 라이브러리(https://github.com/sancarn/stdVBA)를 만드는 데 엄청난 시간을 투자했고 VBA를 좋아하지만, 언어에 큰 제약이 되는 실제 문제가 있음(https://sancarn.github.io/vba-articles/issues-with-vba.html)
    다만 VBA가 받는 혐오의 상당 부분은 VBA 프로젝트들의 상태에서 온 것도 맞음(https://sancarn.github.io/vba-articles/why-is-vba-most-dread...)
  • On Error Resume Next 같은 잘못된 기능을 포함한 환경을 곱지 않게 보는 건 공정하다고 봄

• Excel과 스프레드시트 전체를 생각하면, 스프레드시트 언어가 반응형 함수형 프로그래밍을 얼마나 잘 구현했는지 외부에서는 잘 이해하지 못하는 사람이 많음. React/Angular가 10번 넘는 릴리스 동안 제대로 하려고 애쓰는 바로 그 부분임
  또 많은 사람이 최종 사용자에게 스프레드시트가 왜 그렇게 편한지 이해하지 못하고, 그 결과 실제로는 더 어렵게 만드는 열등한 UI를 제공함
  때로는 한 발 물러서서, 그래픽 UI가 없던 시절에도 옛사람들이 제대로 했다는 걸 이해해야 함. 초기에도 비즈니스는 돌아갔고, 대부분의 시간 동안 기업에 필요한 것은 표 형태 보기와 그 위에서 반응형 함수 계산을 할 수 있는 선택지임. 중소기업에서 일하는 친구에게 물어보면 확인해줄 것임

  • 웹 개발에 들어가는 노력의 상당 부분은 표현에 쓰임. 데이터만 필요하다면 스프레드시트보다 나아지기 어렵다는 말에 동의함
  • Excel은 지금까지 발명된 것 중 최고의 최종 사용자용 IDE라고 볼 수 있음