Microsoft, Excel에 Python 도입 예정

 (theverge.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Microsoft가 Excel 안에서 Python 기반 데이터 분석·시각화를 할 수 있는 통합 기능을 공개 프리뷰로 제공하기 시작함
  • 별도 설치 없이 Excel 리본에서 Python에 접근하고, 기존 수식·차트·PivotTable과 함께 결과를 다듬을 수 있음
  • 새 PY 함수가 Python 데이터를 스프레드시트 그리드에 노출하며, Anaconda 협력으로 pandas, statsmodels, Matplotlib 등을 Excel에서 활용 가능함
  • 계산은 로컬이 아니라 Microsoft Cloud에서 실행된 뒤 워크시트로 돌아오며, Matplotlib과 Seaborn 기반 시각화도 만들 수 있음
  • 공개 프리뷰는 Microsoft 365 Insiders의 Beta Channel에서 Windows부터 시작되고, 프리뷰 종료 뒤에는 유료 라이선스 없이는 일부 기능이 제한됨

Excel 안으로 들어온 Python 분석

  • Microsoft가 Excel에 Python 통합 기능을 추가해, 스프레드시트 안에서 데이터를 조작하고 분석할 수 있게 함
  • 사용자는 Excel 리본에서 Python에 직접 접근할 수 있어, 익숙한 Excel 환경을 벗어나지 않고 고급 분석 작업을 이어갈 수 있음
  • Python으로 만든 플롯과 라이브러리 결과는 Excel의 수식, 차트, PivotTable과 결합해 추가로 다듬을 수 있음

별도 설치 없는 내장 방식

  • Python 통합은 Excel의 내장 커넥터와 Power Query의 일부로 제공됨
  • 추가 소프트웨어 설치나 별도 추가 기능 설정 없이 접근 가능함
  • 새 PY 함수는 Python 데이터를 Excel 스프레드시트 그리드 안에 노출함

Anaconda 라이브러리와 시각화

  • Microsoft는 엔터프라이즈 Python 저장소인 Anaconda와 협력해 Excel에서 주요 Python 라이브러리를 사용할 수 있게 함
  • 사용 가능한 라이브러리에는 다음이 포함됨
    • pandas
    • statsmodels
    • Matplotlib
  • Excel 사용자는 Python 데이터 기반으로 수식, PivotTable, 차트를 만들 수 있음
  • Matplotlib과 Seaborn 같은 차트 라이브러리로 다음 시각화를 생성할 수 있음
    • heatmap
    • violin plot
    • swarm plot

계산은 Microsoft Cloud에서 처리

  • Python 코드는 Excel 스프레드시트 안에서 작성·사용되지만, 계산 처리는 로컬 Excel이 아니라 Microsoft Cloud에서 이뤄짐
  • 실행 결과는 다시 Excel 워크시트로 반환됨

제공 범위와 라이선스 조건

  • Python in Excel 공개 프리뷰는 Microsoft 365 Insiders의 Beta Channel에서 제공됨
  • 초기 제공 대상은 Windows로 제한됨
  • Microsoft는 이후 다른 플랫폼으로도 확대할 예정임
  • 프리뷰 기간에는 Microsoft 365 구독에 포함됨
  • 프리뷰 종료 뒤에는 유료 라이선스가 없으면 일부 기능이 제한됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 예전에 Excel 개발자로 일하면서 Python을 Excel에 넣으려다 실패했던 입장에서, 오늘 이 소식은 반가운 놀라움임
    7년여 전 Excel 팀을 떠날 기회가 있었는데, 당시 상사의 상사가 내가 Python을 Excel에 넣고 싶어 한다는 걸 알고 남으면 그 일을 맡겨주겠다고 했음. 6개월짜리로 생각했던 일이 약 3년 프로젝트가 됐고, Python 쪽은 흐려진 채 결국 JavaScript 사용자 지정 함수를 Excel에 넣는 방향으로 출시됨
    Python도 AzureML v1 기반으로 “클라우드에서” 실행했지만 로컬 실행 여부를 두고 논의가 오갔음. AzureML 파트너 팀의 조직 개편, 재출시, 재채용, PM 이탈이 있었고, 다른 파트너 팀이 우리 코드를 JavaScript를 외부 프로세스에서 실행하는 데 쓸 수 있다는 걸 알아차리면서 Python보다 그 기능 출시에 많은 시간을 쓰게 됨
    핵심 작업은 Excel 계산 엔진을 바꿔 함수가 비동기 계산을 하게 만드는 것이었고, 원격 엔드포인트가 JavaScript든 Python이든 다른 무엇이든 계산하는 동안 사용자가 스프레드시트의 다른 부분을 계속 작업할 수 있게 했음. 예전에는 계산 중 스프레드시트가 잠겼고, 오래 걸리고 끝을 알 수 없는 계산에는 좋지 않았음. 우리가 만든 것 중 일부가 이번 기능에 들어갔는지 궁금함
    “Recalc or die”

    • 비동기 JavaScript 함수 덕분에 xlwings와 Python으로 안정적인 사용자 지정 함수를 출시할 수 있었음
      Office.js의 문제는 평균적인 Excel 사용자에게 npm 의존성 덩어리 때문에 시작이 너무 어렵다는 점이고, 전문 개발자도 꽤 고생함. 사용자가 Node.js를 쓰지 않아도 되게 만든 점은 만족스러움: https://docs.xlwings.org/en/latest/pro/server/officejs_custo...
    • 몇 년 전에 이미 동작하는 “Excel 안의 Python”을 만들었고, 원격으로 SQL과 Matlab/R도 실행됐음
      지금은 버린 프로젝트임: https://alphawolfxl.com/
      베타 테스트를 부탁한 몇몇이 “회사에서 돈을 안 낼 것”이라고 해서 시간을 낭비했다는 인상을 받고 접었는데, 지금 이걸 보니 기분이 복잡함
    • Microsoft가 왜 새 기술의 제대로 된 예제를 만들지 않았는지 궁금함. 제공된 몇 안 되는 예제는 프로그래머용뿐임
      전반적으로 Excel에서 JavaScript가 어떻게 동작하는지 살펴볼 수 있는 실제 동작 코드가 부족하고, 지금은 거의 “부엉이 그리는 법” 수준으로 느껴짐
    • 우리 내부 분석 API를 호출하는 데 JavaScript 사용자 지정 함수를 쓰고 있는데, 작업하기 꽤 좋았음

  • Microsoft Cloud만 쓰는 방식이 아니라 로컬 Python 실행도 지원했으면 좋겠지만, 그래도 이 기능 하나만으로 Excel을 크게 현대화할 수 있을 듯함
    이런 종류의 데이터를 보여주려는 웹사이트 수요를 없앨 수도 있음. 예전 직장에서 내부 몇 명만 쓰는 분석 웹사이트를 만든 적이 있는데, 그때 이런 기능이 있었다면 충분히 이걸로 대체 가능했을 것 같음

    • 이 얘기를 하면 늘 반발을 받음. 사용자는 그냥 Excel로 데이터를 자유롭게 분석하고 싶어 하는데, 내가 속한 IT는 그걸 대신해줄 웹앱을 만들려고 함. 사용자는 결국 만족하지 못하는데, 애초에 원한 건 Excel이었기 때문임
      SQL Server로 데이터 마트를 만들고 ETL 도구로 분석에 필요한 데이터를 채워 넣기만 하면 된다고 계속 설명함. 원본 데이터에는 접근시키지 않으면 됨. 그런데도 다들 이상하게 쳐다보고, 대신 수백만 달러짜리 Tableau 도입 프로젝트를 하려 함. 사용자들은 그걸 원하지 않는데 정말 어처구니없음
    • Excel 팀에서 일하고 있음. 왜 그게 중요한지 요약해서 bgruenbaum@microsoft.com으로 보내주면 PM에게 전달하겠음
      아니면 Excel 웹/데스크톱의 피드백 UI로 보내도 됨. PM들이 그 피드백을 전부 읽음
    • Azure의 인터넷 접근 없는 하이퍼바이저 격리 컨테이너에서 실행하는 데는 몇 가지 중요한 이유가 있음
      모든 사용자에게 일관된 경험을 보장할 수 있음. 시간이 지나며 버전이 갈라지는 상황에서 각자가 로컬 Python 배포판을 유지하고 Excel과 동작을 보장해야 한다고 생각하면 끔찍함
      Excel 통합 문서를 다른 사용자와 공유했을 때 계산이 그냥 동작하게 만들 수 있음. 제각각인 로컬 Python 설치에 의존하면 그게 안 되고 사용자는 크게 좌절할 것임
      보안도 큼. 로컬 사용자 권한으로 Python 코드를 실행할 수 있는 Excel 파일을 여는 상황을 상상해보면 됨
      두 번째 요점에도 전적으로 동의함. 기존 IT 인프라와 통합되는 내부 앱을 Python으로 만드는 건 좋게 봐도 답답한 일임. Excel은 거의 어디서나 이미 IT 인프라 일부이고, 프로그래밍 가능한 반응형 캔버스임
      공개: 이 기능의 설계 팀에서 일하고 있음
    • Microsoft Cloud에서 실행된다는 점 때문에 오히려 우리 회사에서는 매크로보다 유용할 수 있음
      여기서는 매크로가 클라이언트 머신에서 악성코드를 실행하는 경로로 보이고, 그 위험을 감수할 만큼 효용이 크지 않다고 여겨짐
    • 클라우드로 제한하는 건 어느 정도 말이 됨. Python을 Excel 파일 형식의 핵심 일부로 만들면 이식성이 떨어지고 앞으로 온갖 호환성 골칫거리가 생길 수 있음

  • 여기에는 분명 위험 신호가 보임. Excel의 본질적 힘은 통합 문서가 독립적으로 존재할 수 있다는 데서 나오는데, 이제 프로세스가 영원히 클라우드에 묶이게 됨
    3년 뒤 사망한 동료의 통합 문서를 열어야 할 때, 이 통합 기능을 벤더가 계속 지원해주느냐에 좌우됨
    어떤 업무든 첫 단계가 “소프트웨어를 다시 동작하게 만드는 법 찾기”가 되면 끔찍함. 지난 수십 년 동안 Excel, Outlook, Word의 이런저런 추가 기능 때문에 여러 번 겪었고, 그 추가 기능들은 처리 자체를 원격에서 하던 것도 아니었음

    • “아무것도 소유하지 못하겠지만 행복할 것이다”가 이제 스프레드시트까지 따라온 건가. 책상 앞에서 임금노동하며 만드는 것조차 소유하지 못하게 됨
    • 솔직히 이 편이 더 관리하기 쉬워 보임. Anaconda 배포판을 쓰고 있으니 각 통합 문서를 특정 배포판에 묶고 업데이트/롤백 가능성을 두면, 로컬 설치를 관리하는 것보다 훨씬 쉬워짐
    • 클라우드뿐 아니라 구독에도 묶임. 구독을 취소하거나, 발표에서 유료 모듈일 수 있다고 한 그 구독이 없거나, 공급업체가 준 Excel이라 구독이 없으면 그 Excel 시트를 쓰는 데 이미 문제가 생김
    • 지난 7년 정도는 클라우드가 아닌 스프레드시트를 써본 적이 없음. 다만 중요도가 높고 수명이 긴 일에는 Excel을 쓰지 않을 것임. 주로 브레인스토밍이나 발표자료에 스크린샷으로 넣는 용도임
    • 클라우드를 쓰든 안 쓰든 이 문제는 이미 존재함. Excel 워크시트는 이미 웹이나 다른 파일에 대한 외부 링크를 가질 수 있고, 그 웹 리소스나 파일이 없으면 끝임. 오래된 파일은 현대 머신에서 더 이상 실행되지 않는 소프트웨어에서만 열릴 수도 있음
      그래서 가끔 백업을 실제로 복원해보거나, 이런 경우에는 중요한 파일을 검증하는 게 중요함

  • “Excel의 Python”에 신났다가 “클라우드에서 실행”이라는 문구를 보고 식었음. 이건 클라우드 서비스에 묶어두려는 것 말고는 이유가 없어 보임. 안전하지 않은 프린터 잉크로부터 나를 보호해주겠다는 느낌과 너무 비슷함
    보통은 MS Office 제품을 좋아하고 좋게 봐주려는 편임. 락인 말고 Python을 클라우드에서 실행하도록 요구할 그럴듯한 좋은 이유가 있다면 알려줬으면 함

    • 위험 신호임. M$가 사람들을 자기 클라우드로 밀어 넣고 있음. OneDrive로 로컬 파일 시스템을 가로채는 방식은 이미 많은 사람이 겪은 좋은 예임
      M$에서 벗어났어야 할 시점이 이미 5년쯤 지났다고 봄. Windows부터 Office까지 모든 제품에 이미 반소비자 기능이 들어 있음
    • 고객에게 로컬 Python 설치를 관리하라고 하지 않는 건 이유가 될 수 있음
      물론 Excel+Python 고급 사용자는 자기 Python 런타임을 가져오고 유지하는 데 익숙할 가능성이 크다는 점도 이해함
    • 대부분의 Excel 사용자는 Python을 설치하고 실행해본 경험이 없기 때문일 것임. Python을 아는 사람에게도 꽤 귀찮은 일임
      iOS와 Android 기기에서 Excel을 쓰는 사람도 있음. 이 방식이면 그들도 스프레드시트 안의 Python을 사용하고 읽을 수 있음
    • Grist도 있음. Excel 복제판은 아니지만 스프레드시트/하이브리드 데이터베이스라 비슷한 일을 일부 할 수 있고, 가장 중요한 건 수식에 Python을 쓸 수 있으며 로컬에서 돌리고 싶으면 셀프 호스팅 옵션도 있음

  • 2005년에 친구들과 Resolver Systems라는 회사를 만들어 Python이 가능한 스프레드시트 Resolver One을 만들었음
    안타깝게도 시장에서 뜨지 못했고 방향을 바꿔 온라인 코딩·호스팅 환경인 PythonAnywhere를 만들었는데, 이건 꽤 잘됐고 작년에 Anaconda에 인수됨. 그리고 이제 원이 닫힌 셈임
    명확히 하자면 Anaconda 안에서 이 기능을 만드는 팀은 PythonAnywhere 팀과 완전히 별개임. 같은 사람들이었다면 할리우드식 이야기로 딱 좋았을 텐데

    • 좋은 제품이었음. 그 피치가 기억나고, 런던 Python 금융 모임에서도 몇 번 만났음. “Enthought Python Distribution”도 기억남
      다만 Resolver가 IronPython 기반이라 제대로 동작하지 않는 라이브러리가 꽤 있었다는 게 문제였음
    • 첫 앱을 PythonAnywhere에서 만들었음. 거의 10년째 거기서 돌아가는 것들도 있음
      PythonAnywhere 웹앱에서 바로 작은 수정들을 할 수 있는 게 정말 좋았고, GCP/AWS를 쓰기 시작했을 때 그런 기능이 많이 그리웠음
    • PythonAnywhere는 훌륭함. 다른 사람처럼 웹 프로그래밍에 처음 발을 들인 곳이기도 했음
    • 이 소식을 듣자마자 Resolver Systems가 바로 떠올랐음

  • “Python 계산은 Microsoft Cloud에서 실행된다”는 문구를 보고 동료가 농담으로 “Microsoft조차 Windows에서 로컬 Python 설치를 관리하지 못하나 보네…”라고 했음
    하지만 Microsoft가 정말로 로컬 Python 환경 설정 문제를 마침내 해결하고, Excel이 운영체제 전반의 표준 Python 패키지 관리자가 되는 모습을 상상해보면 재밌음
    $ excelpip install fastapi==9.11.23
    fastapi version 11.09.2023 검색 중…

    • 20년 전 Debian의 apt를 만져본 뒤로 Microsoft가 Windows의 패키지 관리를 해결하길 기다려왔음. 비꼬는 게 아니라, Microsoft의 제품 복잡도와 하위 호환성 집착을 보면 오히려 소프트웨어 관리를 진전시킬 만한 주체로 보였음
      문제 공간을 깊이 파고들어 오픈소스 쪽에서 나온 것들을 넘어서는 패키지 관리자를 재발명할 줄 알았음
      대신 지금은 Windows Update, Windows Features, Microsoft Store, Software Center, winget이 있음. winget은 Microsoft가 만든 Windows용 패키지 관리자인데, 또 다른 Microsoft 제작 Windows용 패키지 관리자에서 설치해야 하는 그 도구임
    • 이런 문제가 떠오름. Microsoft가 LTSC 패키지 집합을 고정해야 할까? 한 세대 뒤처진 Excel 버전을 쓰는 $GOV_AGENCY는 세상과 어떻게 협업할까?

  • LibreOffice가 오래전에 분위기를 읽었어야 했음. 원칙적으로 Python 스크립팅은 가능하지만 지나치게 번거롭고 지저분하며, 개선 로드맵도 없어 보임
    같은 경고는 Linux 데스크톱과 그 앱 전반에도 적용됨. 점점 더 많은 독점 플랫폼이 클라우드 기반으로, 종종 Python API를 통해 기존 앱에 고급 “AI” 기능 확장을 넣을 것임
    오픈소스 세계의 여러 흐름이 너무 사일로화되어 있는 게 아쉬움. 부분의 합보다 큰 잠재력이 낭비되고 있음

    • 많은 경우 사람들을 Excel과 다른 독점 제품에 붙잡아두는 건 고급 기능이 아니라 사소해 보이는 것들임
      LibreOffice 스프레드시트와 Apple Numbers에서 가장 불만인 건 비연속 선택 영역 복사/붙여넣기 처리임
      예를 들어 5행 3열 데이터에서 1 2 3, 7 8 9, a b c 행을 선택해 복사한 뒤 d e f 아래에 붙여넣으면 Excel은 선택한 행만 이어 붙임. LibreOffice와 Numbers는 중간 빈 행까지 보존함
      이 동작을 바꾸는 설정을 못 찾았음. Excel도 반대로 간격 보존을 원하는 사람에게는 짜증 날 수 있겠지만, 나는 간격 보존을 원한 적이 거의 없어서 LibreOffice와 Numbers가 불편함
    • LibreOffice는 거의 처음부터 Python 스크립팅을 포함해왔음
      사람들이 크게 신경 쓰지 않는 이유는 오피스 제품군의 가장 인기 있는 사용 사례가 Microsoft 파일 형식과 상호 운용되는 것이기 때문임
    • ScriptForge를 확인해볼 만함: https://help.libreoffice.org/latest/en-US/text/sbasic/shared...
      LibreOffice 안에서 스크립트를 실행하려면 APSO script organiser가 권장됨: https://extensions.libreoffice.org/en/extensions/show/apso-a...
    • 오히려 반대로 보임. Python은 스크립팅이 너무 쉬워서 Excel이 자기 관에 못을 박는 셈이라고 봄
      프로그래밍 언어를 써본 적 없는 고령 사용자층이 나이 들고 은퇴하는 상황에서, Excel에 Python을 결합하는 법을 배우는 사람은 결국 Python을 더 선호하게 될 것임. 더 유연하고 확장 가능하기 때문임
      기본적인 계산판 용도 말고는 Excel을 쓸 이유가 없음. 누가 스프레드시트를 요구하면 Python으로 생성을 자동화해 다시는 직접 다루지 않게 함
    • LibreOffice는 먼저 해결해야 할 다른 문제가 많음. 너무 느림

  • 실망스러움
    “Excel의 Python은 현재 Windows에서 베타 채널을 실행하는 사용자에게 제공됩니다. 이 기능은 빌드 16.0.16818.2000부터 Windows용 Excel에 먼저 배포되고, 이후 다른 플랫폼에 제공됩니다.” [1]
    “Excel의 Python은 Windows용 Excel에서 사용할 수 있습니다. 이 기능은 Mac용 Excel, 웹용 Excel, iPad용 Excel, iPhone용 Excel, Android용 Excel에서는 사용할 수 없습니다. 지원되지 않는 플랫폼에서는 Python이 포함된 통합 문서를 볼 수는 있지만, Python 셀을 다시 계산하면 오류가 표시됩니다.” [2]
    [1] https://techcommunity.microsoft.com/t5/excel-blog/announcing...
    [2] https://support.microsoft.com/en-us/office/introduction-to-p...

  • “Python 계산은 Microsoft Cloud에서 실행된다”라니, 사양함

    • 그 부분이 나도 눈에 띄었음. 왜 이런 모델을 택했는지 궁금함
    • 스프레드시트 제품군에 훌륭한 Python 통합을 간절히 원하지만, 이건 시도할 생각조차 없음

  • 잠깐만. LibreOffice에는 몇 년 전부터 Python이 있었는데 아무도 신경 쓰지 않았고, 대신 “진짜 업무”에는 100% 호환되는 VBA가 필요하다고 불평했음. 그 사람들은 지금 어디 있나?

    • 여기 있음. 문제는 100% 호환 VBA만이 아니라, Excel에서 실행되지 않을 VBA 기반 스프레드시트를 만들기 위해 완전히 새로운 API를 배워야 한다는 것임
      LibreOffice VBA가 Office VBA와 호환됐다면 낡은 Windows 시스템을 어딘가에 계속 보관할 이유가 없었을 것임
      우리가 이걸 하는 이유는 돈을 벌기 위해서고, Excel에서 실행되지 않는 Excel 스프레드시트를 사고 싶어 하는 사람은 없음
    • Excel이 더 많은 걸 할 수 있어 기분 나쁜 게 아니라, LibreOffice에 익숙한 기능이나 강제로 써야 하는 기능이 없어 여전히 불편할 수 있음
    • 고객 중 누군가 LibreOffice를 쓴다면 기꺼이 쓰겠음. 하지만 아무도 안 씀
      Linux에서 LibreOffice Calc로 작업하고, Excel은 Linux 지원이 0이니, 문제없이 고객에게 보낼 수 있을 정도의 호환성이 있으면 좋겠지만 아직 그 근처도 못 감
    • 기능이 별로면 사람들은 쓰지 않음
      존재를 모르면 사람들은 쓰지 않음
      다른 것에 익숙하면 사람들은 그걸 요구함
    • LibreOffice의 문제는 Python 지원이 문서상으로만 존재했다는 데 있었음
답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.