Python에서 현재 설치된 라이브러리(패키지) 목록을 확인하는 방법은 여러 가지가 있습니다. 주로 pip 패키지 관리자를 사용하여 설치된 패키지 목록을 조회합니다. 아래는 다양한 방법으로 현재 설치된 라이브러리 목록을 확인하는 방법을 설명합니다.
1. pip list 명령어 사용
가장 일반적인 방법은 터미널 또는 명령 프롬프트에서 pip list 명령을 사용하여 설치된 모든 패키지 목록을 조회하는 것입니다.
pip list
위 명령을 실행하면 설치된 모든 패키지의 목록이 출력됩니다.
2. pip freeze 명령어 사용
pip freeze 명령은 pip list와 유사하게 현재 환경에 설치된 패키지와 그 버전을 출력합니다. 이 명령은 보통 requirements.txt 파일을 생성하는 데 사용됩니다.
pip freeze
3. Python 스크립트를 통한 확인
Python 스크립트 내에서 pkg_resources 모듈을 사용하여 현재 설치된 패키지를 조회할 수 있습니다.
import pkg_resources
# 현재 설치된 패키지 목록 조회
installed_packages = pkg_resources.working_set
installed_packages_list = sorted(["%s==%s" % (i.key, i.version) for i in installed_packages])
for package in installed_packages_list:
print(package)
4. conda list (conda 환경에서)
만약 Anaconda 또는 Miniconda와 같은 conda 패키지 관리자를 사용하고 있다면, conda list 명령을 사용하여 현재 환경에 설치된 패키지 목록을 확인할 수 있습니다.
conda list
위 방법 중 하나를 선택하여 현재 Python 환경에 설치된 모든 패키지 목록을 확인할 수 있습니다.
책임감 있는 AI, 일명 RAI(Responsible AI)에 대한 관심이 더욱 높아지고 있다. RAI는 신뢰와 도입부터 LLM 환각 관리, 유해한 생성형 AI 콘텐츠 제거에 이르기까지 모든 것을 추진하는 핵심 요소다. 효과적인 RAI로 기업은 더 빠르게 혁신하고, 비즈니스를 더 개선하고, 미래의 AI 규정을 준수하고, 평판이 손상되거나 규제를 어기는 일 없이 계속 경쟁에 참여할 수 있다.
안타깝게도 RAI가 실제로 무엇인지, 무엇을 제공하는지, 어떻게 달성할 수 있는지에 대한 혼란이 있다. 치명적인 결과를 초래할 수 있는 문제다. 그러나 RAI 이니셔티브가 제대로 수행되지 않으면 혁신이 방해받고 지연과 비용이 추가된다. RAI의 정의와 목적에 대한 좋은 해석도 있지만 잘못된 통념과 오해도 만연해 있다. 기업은 RAI는 비용이 많이 들고 비효율적이며 시간 낭비라는 잘못된 통념을 깨뜨리고 AI에 기반해 가치를 창출하는 원동력으로 전환해야 한다.
RAI에 대한 오해 중 가장 문제적인 것은 무엇일까? 그리고 지속 가능한 이니셔티브를 추진하기 위해 RAI를 가장 잘 정의하려면 어떻게 해야 할까?
잘못된 통념 1 : RAI는 원칙론일 뿐
어느 거대 IT 기업에서나 설명 가능성, 공정성, 개인정보 보호, 포용성, 투명성과 같은 RAI 원칙을 찾아볼 수 있 수 있다. 이렇게 널리 퍼진 여러 원칙이 있으니 RAI의 중심에 원칙이 있다고 해도 문제가 없을 것이다. 이런 기본적인 기업 원칙은 책임감 있는 개인에게 기대하는 것과 정확히 같은 종류이므로 책임감 있는 AI 보장에 핵심이 된다고 하면 맞는 말일까?
아니, 틀렸다. 모든 기업에는 이미 원칙이 있다. 일반적으로 기업 원칙은 RAI와 정확히 동일할 것이다. 공정, 투명성, 포용에 반대한다고 밝힐 기업이 있을까? 만약 그런 기업이 있다고 해도, AI에는 투명성을 적용하고 기업의 나머지에는 투명성을 적용하지 않을 수가 있을까?
또한 원칙은 AI에 대한 신뢰를 불러일으키는 것보다 사람과 기업에 대한 신뢰를 끌어내는 데에 훨씬 효과적이다. 항공사의 비행기가 목적지까지 안전하게 데려다 줄 것이라고 믿는 이유가 그 회사가 원칙을 지키기 때문인지 생각해 보자. 아니, 엄격하게 시행되는 프로세스를 따르고, 신중하게 테스트하고 정기적으로 검사한 장비를 사용하는 숙련된 조종사, 기술자, 항공 교통 관제사가 있어서 신뢰하는 것이다.
비행기 여행과 마찬가지로 RAI의 핵심은 원칙을 실현하고 시행하는 사람, 프로세스, 기술이다. 독자 모두 이미 올바른 원칙을 정해두었을 것이다. 문제는 실행이다.
잘못된 통념 2 : RAI는 윤리와 관계가 있다
RAI는 AI를 윤리적으로 사용하고, 모델이 공정하게 작동하도록, 새로운 차별이 생겨나지 않도록 하는 지침일 뿐이라고 생각한다면 틀렸다.
신용 평가에 사용되거나 이력서를 심사하거나 실직 여부를 결정하는 모델 등 실제로 윤리나 공정성을 고려하는 AI 사용례는 극히 일부일 뿐이다. 당연히 이러한 사용례를 책임감 있게 처리하는 것도 RAI의 목적이지만, 다른 모든 AI 솔루션의 안전과 안정적 개발 및 사용, 또 기업의 성능 및 재무 요구 사항 충족도 RAI가 필요한 부문이다.
설명 가능성을 제공하고, 편향성을 확인하고, 개인정보 보호를 보장하는 데 사용하는 도구는 정확성, 신뢰성 및 데이터 보호를 보장하는 데 사용하는 도구와 정확히 같다. RAI는 공정성을 고려해야 할 때 AI를 윤리적으로 사용하는 데 도움이 되지만, 다른 모든 AI 사용례에서도 마찬가지로 중요하다.
잘못된 통념 3 : RAI를 알려면 설명 가능성부터 알아야 한다
AI를 신뢰하고 책임감 있게 사용하기 위해서는 설명 가능성, 즉 해석 가능성이 필요하다는 것이 일반적인 생각이지만, 사실은 아니다. 비행기 여행에 안심하기 위해서 비행기의 작동 원리를 알아야 할 필요가 없듯, AI를 신뢰하기 위해 설명 가능성을 꼭 이해할 필요는 없다.
인간의 결정이 좋은 예다. 인간은 거의 대부분 자신의 결정 이유를 설명할 수 있지만, 사실 설명은 의사 결정 행동의 실제 동인과는 거의 관련이 없는, 사후에 지어낸 이야기라는 증거가 많다.
그러나 쉽게 이해할 수 있는 '화이트박스' 모델과 LIME 및 ShAP과 같은 방법을 사용하는 AI 설명 가능성은 모델이 올바르게 작동하는지 테스트하는 데 중요하다. 잘못된 상관관계와 잠재적인 불공정한 차별을 식별하는 데 도움이 되기 때문이다. 패턴을 쉽게 감지하고 설명할 수 있는 간단한 사용례에서는 신뢰도를 높이는 지름길이 될 수 있다. 그러나 패턴이 충분히 복잡한 경우에는 어떤 설명도 기껏해야 어떤 결정이 어떻게 내려졌는지에 대한 암시만 제공할 뿐이며, 최악의 경우 완전한 중언부언이나 횡설수설에 지나지 않을 것이다.
즉, 요컨대, 설명 가능성은 있으면 좋지만, 이해관계자와의 신뢰를 의미 있게 이끌어내는 방식으로 제공하는 것은 불가능할 때가 많다. RAI는 모든 AI 사용례에 대한 신뢰를 보장하는 것으로, 이는 개발 및 운영에 사용되는 사람, 프로세스, 기술(특히 플랫폼)을 통해 신뢰를 제공하는 것을 의미한다.
책임감 있는 AI는 곧 위험 관리
결국 RAI는 AI 및 머신러닝 모델을 개발하고 사용할 때 위험을 관리하는 관행이다. 여기에는 비즈니스 위험(성능 저하 또는 신뢰할 수 없는 모델 등), 법적 위험(규제 벌금, 고객사나 또는 직원 소송 등), 심지어 사회적 위험(차별이나 환경 피해 등)까지 관리해야 한다.
이러한 위험은 사람, 프로세스, 기술의 형태로 RAI 역량을 구축하는 다층적 전략을 통해 관리된다. 사람 측면에서는 RAI를 책임지는 리더(예: 최고 데이터 분석 책임자, 최고 AI 책임자, 데이터 과학 책임자, ML 부사장)의 역량을 강화하고 실무자와 사용자가 책임감 있게 AI를 개발, 관리, 사용할 수 있도록 교육해야 한다.
프로세스 측면에서는 데이터 액세스 및 모델 학습에서 모델 배포, 모니터링 및 재학습에 이르는 엔드투엔드 수명 주기를 관리하고 통제해야 한다. 기술 측면에서 특히 중요한 것은 측면에서 플랫폼은 대규모로 사람과 프로세스를 지원하고 활성화하는 플랫폼이다. 플랫폼은 설명 가능성, 편향성 감지, 편향성 완화, 공정성 평가, 드리프트 모니터링 등 RAI 방법에 대한 액세스를 민주화하고, AI 아티팩트 거버넌스, 계보 추적, 문서 자동화, 승인 워크플로 조율, 데이터 보안은 물론 RAI 프로세스를 간소화하는 수많은 기능을 제공한다.
제약, 금융 서비스, 보험 등 규제가 심한 산업의 고급 AI 팀이 이미 이러한 기능을 구축하여 가치 창출에 나서고 있다. 이들 선도 업체는 빠른 구현, 더 큰 채택, 더 나은 성능, 향상된 안정성 등의 이점을 통해 모든 AI, 특히 생성형 AI에 대한 신뢰를 대규모로 구축하고 있다. AI 규제 마련에 대비하여 AI 이니셔티브를 미래에 대비할 뿐 아니라 무엇보다도 모든 사용자를 더 안전하게 만드는 데에도 유용하다. 책임감 있는 AI는 대규모의 AI 가치를 실현하는 열쇠지만, 그러려면 먼저 잘못된 통념을 깨야 한다.
윈도우에서 리눅스로 전환할 때 가장 큰 어려움이 바로 소프트웨어다. 윈도우에서 쓰던 것을 리눅스에서 쓰지 못할지 우려한다. 하지만 리눅스에서도 특수 목적 애플리케이션 외에 다양한 소프트웨어를 사용할 수 있다.
ⓒ IDG 기본적으로 리눅스는 윈도우와 다르다. 윈도우와 다르게 작동, 구성되며 윈도우 프로그램을 바로 실행할 수 없다. 다만, 가상화 또는와인(Wine)을 사용해 리눅스에서도 윈도우 프로그램을 사용할 수 있다. 반면 윈도우에서 이미 오픈소스 소프트웨어를 많이 써왔다면 리눅스 환경에서도 쉽게 적응할 수 있다.리브레 오피스, 파이어폭스, 썬더버드,VLC와 같은 프로그램은 리눅스와 윈도우에서 모두 똑같이 사용할 수 있으며, 작동 방식도 거의 같다. 이들 외에 다른 애플리케이션도 다양하지만, 일부 기능과 작동 방식은 윈도우용 프로그램과 다소 차이가 있다. 어느 정도 익숙해지는 시간이 필요하다.
리눅스에서 소프트웨어 설치하기
윈도우 10 또는 11에서는 마이크로소프트 스토어를 통해 새 소프트웨어를 설치하고 업데이트할 수 있다. 여기서 제공되지 않는 것은 제조업체의 웹사이트나 기타 다른 곳에서 내려받은 설치 파일을 사용한다. 이런 소프트웨어를 표준화된 관리 기능이 없으므로 업데이트가 자동으로 이뤄지지 않을 수 있다.
리눅스 시스템은 윈도우와 달리 각 배포판의 리포지토리에서 소프트웨어를 가져온다. 중앙 패키지 데이터베이스가 있으며, 업데이트는 시스템과 설치된 모든 프로그램에 적용됩니다. 따라서 프로그램 패키지를 확인하고 서명하기 때문에 높은 수준의 보안이 보장된다.
문제는우분투 22.04또는리눅스 민트 21.2와 같은 LTS(long-term support) 리눅스 배포판은 5년의 지원 기간 동안 새로운 소프트웨어가 거의 제공되지 않는다는 점이다. 파이어폭스나 썬더버드 같은 보안에 중요한 소프트웨어는 정기적으로 업데이트되지만, 리브레 오피스와 같은 프로그램은 기본 버전이 그대로 유지된다. 시스템의 안정성을 더 중요하게 생각하기 때문이다.
사용할 수 있는 업데이트에 대해 자동으로 알려준다. 시스템과 설치된 모든 애플리케이션에 대한 설치가 중앙 집중식으로 이루어진다. ⓒ IDG 리눅스용 최신 프로그램: LTS 배포판 사용자가 최신 소프트웨어를 계속 받을 수 있도록 우분투와 리눅스 민트는 표준 패키지 관리 외에도 스냅(Snap)과 플랫팩(Flatpak) 등 2가지 컨테이너 형식을 사용한다. 프로그램과 필요한 모든 시스템 파일을 별도의 영역에 설정해 시스템의 나머지 부분이 최신 파일의 영향을 받지 않는 장점이 있다. 반면 기존 패키지 설치보다 하드 드라이브에 더 많은 공간이 있어야 하는 것은 단점이다.
사용자 관점에서 처음에는 패키지의 정확한 형식이 중요하지 않다. 우분투에서는 "우분투 소프트웨어(Ubuntu Software)" 도구를 통해, 리눅스 민트에서는 "애플리케이션 관리(Application Management)"를 통해 패키지 관리가 여전히 중앙 집중화되어 있기 때문이다. 여기서 프로그램을 검색하거나 프로그램을 추천받을 수 있다.
하지만 새 프로그램을 설치할 때는 사용 가능한 버전이 여러 가지인 경우가 많으므로 버전에 주의해야 한다. 우분투 소프트웨어에서 "스냅 스토어(Snap Store)"와 "ubunt-jammyuniverse(deb) 또는 이와 유사한 소스(Source) 중 선택할 수 있다. 스냅 스토어의 프로그램은 일반적으로 더 최신 버전이며, "프리뷰/엣지(preview/edge)"가 추가된 프리 릴리즈 버전도 있다. 리눅스 민트도 비슷합니다. 일반적으로 오래된 "시스템 패키지(system package)"와 "플랫팩, 플랫텁(Flatpak, Flathub)" 및 "플랫팩, 플랫텁 베타(Flatpak, Flathub Beta)" 중 선택할 수 있다. 클래식 시스템 패키지와 스냅, 플랫팩 컨테이너를 병렬로 설치할 수도 있다.
리브레 오피스는 광범위한 기능을 제공한다. 메뉴 대신 리본을 활성화할 수 있어 마이크로소프트 오피스와 비슷하다. ⓒ IDG
리눅스용 오피스 패키지
마이크로소프트 오피스는 가장 널리 쓰이는 생산성 앱이다. 워드 프로세싱, 스프레드시트의 전 세계 표준이다. 하지만 가끔 메일을 사용하거나 문서를 작성하는 정도라면 우분투와 리눅스 민트에 사전 설치된 리브레 오피스로도 충분하다.
다른 사람과 문서를 자주 주고받거나 마이크로소프트 인프라에 의존하는 환경에서 작업한다면 리눅스를 자신 있게 추천하기 힘들다. 리브레 오피스는 마이크로소프트 서식 문서를 읽을 수 있지만, 복잡한 문서의 경우 서식이 항상 올바르게 표시되는 것은 아니다. 특히 표나 매크로 등이 깨질 가능성이 있다. 가장 큰 어려움은 아마도 스프레드시트다. 리브레 오피스의 스프레드시트 앱인 칼크(Calc)는 엑셀과 비슷한 기능을 제공하지만, 전체적으로 같은 기능이라고 할 수는 없다.
또한, 리브레 오피스는 기본적으로 클래식 메뉴 모음을 표시한다. 마이크로소프트 오피스에 익숙하다면 보기 > 사용자 인터페이스에서 "탭에서(In tab)"를 선택해 활성화하는 리본을 선호할 수도 있다. "모두(For all)"를 클릭하면 이 설정이 오피스 제품군의 모든 하위 프로그램에 적용된다.
리브레 오피스 대신 리눅스에서 사용할 만한 생산성 앱을 더 찾는다면, 마이크로소프트의무료 온라인 오피스 제품도 살펴볼 만하다. 오피스닷컴(www.office.com)에 마이크로소프트 계정으로 로그인하기만 하면, 웹 브라우저에서 워드, 엑셀, 파워포인트 프로그램을 무료로 쓸 수 있다. 단, 웹용 오피스는 설치용 마이크로소프트 365와 같은 기능이 아니며, 자세한 차이점은 여길 참고하면 된다. 제약이 있기는 하지만 외부에서 마이크로소프트 오피스 파일을 편집하거나 다른 사람과 파일을 교환할 때 유용하다. 이렇게 만든 오피스 파일은 클라우드 원드라이브에 저장된다. 오프라인에서 문서 작업을 하려면 파일을 내려받아야 한다. 웹용 오피스에서는 리브레 오피스 형식의 파일을 가져오고 내보낼 수도 있다.
김프는 사진 편집은 물론, 여러 레이어와 마스크가 있는 복잡한 그래픽 작업까지 지원한다. ⓒ IDG
이미지 편집과 그래픽
리눅스에는 이미 간단한 이미지 뷰어가 설치돼 있다. 그놈(Gnome) 데스크톱이 설치된 우분투에는 그놈 이미지 뷰어, 리눅스 민트에는 X 뷰어가 있다. 두 프로그램을 이용하면 슬라이드쇼를 표시하고 이미지를 회전할 수 있다. 간단한 편집 기능이 필요하다면 우분투에서는 샷웰(Shotwell)을, 리눅스 민트에서는 픽스(Pix)를 쓰면 된다. 기능은 비슷하다. 적목 제거, 색상 및 밝기 조정, 이미지 자르기 등을 지원한다.
이 중에서디지캠(Digikam)은 사진 관리 앱이다. 앨범, 태그 또는 키워드에 따라 이미지를 정렬하고 분류할 수 있다. 톤 보정, 적목 제거, 프레임 추가 등 다양한 사진 편집 툴을 쓸 수 있다. RAW 파일을 보거나, 화이트 밸런스 같은 보정을 할 수 있다. 물론 로 테라피(Raw Therapee)나 다크테이블(Darktable)과 맞먹을 정도는 아니다. 더 많은 기능이 필요하면 전문가용 앱을 찾아야 한다.
김프(Gimp)는 주로 윈도우에서 포토샵을 쓰던 사용자를 대상으로 한 이미지 툴이다. 이 프로그램은 페인팅 도구, 레이어, 마스크, 자동 향상, 다양한 필터를 제공한다. 사진을 수정하고, 이미지를 자르거나 변형할 수 있다. 포토샵과 마찬가지로 대부분 기능은 즉시 액세스할 수 없고, 특정 효과는 마스크와 레이어를 적절히 조합해야만 쓸 수 있다. 하지만 널리 보급돼 사용되고 있으므로 궁금한 점은 구글링으로 대부분 해결할 수 있다.김프 홈페이지의 문서(www.gimp.org/docs)가 좋은 출발점이다.
크리타(Krita)는 김프와 비슷하지만 더 쓰기 쉽다. 이 소프트웨어는 원래 페인팅 프로그램으로 만들어졌고, 드로잉 태블릿에서도 쓸 수 있다. 기본적으로 이미지를 선명하게 하거나 노이즈를 줄이는 등 사진에 대한 다양한 자동 보정과 최적화 도구를 지원한다. 크리타는 이미지를 예술적으로 바꾸는 다양한 효과도 제공한다. '이미지(Image)' 메뉴의 명령으로 크기 조정, 회전, 자르기를 빠르고 쉽게 할 수 있다.
잉크스케이프(Inkscape)는 어도비 일러스트레이터와 비슷하다. 벡터 그래픽 프로그램으로, 만화, 클립아트, 로고, 전단지, 브로셔, 다이어그램과 같은 예술적, 기술적 일러스트레이션 작업에 적합하다. 해상도와 관계없이 화면 및 인쇄용 요소를 선명하고 손실 없이 만들 수 있다. 잉크스케이프에서 사용하는 파일 형식은 SVG(Scalable Vector Graphics)다.
VLC 미디어 플레이어는 윈도우 버전과 거의 비슷하며 똑같이 작동한다. 일반적인 미디어 형식을 안정적으로 재생한다. ⓒ IDG
오디오와 비디오용 소프트웨어
리눅스는 멀티미디어 기능에 있어서 아쉬운 것이 없다. 운영체제에 기본적으로 포함된 프로그램이 대부분 동영상 형식을 문제없이 재생하고, 필요한 경우 추가 코덱을 설치하면 된다.
대표적인 동영상 플레이어인VLC는 윈도우에서 자주 사용되는데, 리눅스에서도 사용할 수 있다. 모든 일반적인 코덱이 포함돼 있어 거의 모든 동영상 형식을 재생한다. 복사 방지된 DVD를 재생하려면 추가 라이브러리가 필요하지만, 이는 다른 모든 미디어 플레이어와 마찬가지다. 복사 방지 DVD 재생 라이브러리를 설치하려면 일단 터미널을 연다.
sudo apt install libdvd-pkg
다음 명령으로 설치를 완료한다.
sudo dpkg-reconfigure libdvd-pkg
VLC 대신 쓸 수 있는 동영상 플레이어를 찾는다면Sm플레이어(Smplayer)가 있다. 때에 따라 실행 속도가 조금 더 빠르고 별도 테마를 통해 인터페이스를 사용자 지정할 수 있는 것이 특징이다. Sm플레이어에는 중요한 오디오, 비디오 코덱도 모두 포함돼 있다.오픈샷(Openshot)은 동영상을 편집하고, 효과를 추가하고, 여러 형식으로 저장하는 소프트웨어다. 인터페이스가 직관적이어서 초보자도 쉽게 이해하고 사용할 수 있다.
리브레 오피스 구성 폴더의 구조는 윈도우와 리눅스에서 같다. 따라서 파일을 리눅스 시스템으로 간단히 복사할 수 있다. ⓒ IDG
윈도우의 앱 설정을 그대로 리눅스로 옮기는 방법
윈도우에서 리눅스로 전환해 필요한 소프트웨어를 사용할 때 리브레 오피스와 같이 복잡한 구성의 프로그램은 윈도우에서 데이터를 복사하는 방식으로 설정하는 시간을 줄일 수 있다. 인터페이스를 일관되게 사용할 수 있을 뿐만 아니라 자동 텍스트 모듈, 자체 사전 또는 매크로도 그대로 쓸 수 있다. 단, 이렇게 설정을 그대로 옮기려면 두 프로그램의 버전이 일치해야 한다.
윈도우용 리브레 오피스의 구성을 리눅스로 옮기기 구체적인 방법은 다음과 같다.
1단계 : 윈도우에서 리브레 오피스를 종료하고 윈도우 탐색기의 주소 표시줄에 %appdata%를 입력한 후 엔터 키를 눌러 확인한다. 그런 다음 하위 폴더 "LibreOffice\4"로 변경하고 "user" 폴더를 ZIP 파일로 압축한다. 이 파일을 리눅스 홈 디렉터리에 복사한다.
2단계 : 아직 리눅스에서 오피스 패키지를 실행한 적이 없다면, 리브레 오피스를 시작하고 프로그램을 다시 닫는다. 파일 관리자에서 홈 디렉터리로 이동해 ZIP 파일의 압축을 풀고 Ctrl-C를 사용하여 "사용자" 폴더를 복사한다.
3단계: 파일 관리자에서 Ctrl-H를 사용해 숨겨진 파일을 표시하고 ".config/libreoffice/4" 폴더로 변경한다. 디렉터리 이름을 "user"로 바꾸고 윈도우에서 복사한 폴더를 Ctrl-V로 붙여 넣는다. 이제 리브레 오피스를 시작하면 윈도우에서 설정한 그대로 사용할 수 있다.
파이어폭스의 구성 옮기기 파이어폭스에서 데이터를 옮기려면 리눅스용 파이어폭스 버전이 윈도우 버전과 같거나 최신 버전이어야 한다. 버전 번호는 도움말 > 파이어폭스 정보에서 햄버거 메뉴를 클릭해 확인할 수 있다. 구체적인 방법은 다음과 같다.
파이어폭스의 윈도우에서 햄버거 메뉴(대시 3개)를 클릭하고 도움말 > 추가 문제 해결 정보를 선택한다. "일반 정보" 아래에서 "프로필 폴더" 다음에 있는 "폴더 열기"를 클릭합니다. 파이어폭스를 종료한다. 표시된 폴더를 ZIP 파일로 압축한 다음 리눅스 홈 디렉터리에 복사해 압축을 푼다.
리눅스에서 파이어폭스를 시작하고 윈도우와 마찬가지로 프로필 폴더를 만든다. 파이어폭스를 종료한다. 윈도우 백업의 프로필 폴더에 있는 모든 파일을 리눅스 프로필 폴더로 복사하고 기존 파일을 모두 덮어쓴다.
썬더버드의 구성 옮기기 여기서도 두 프로그램 버전이 같거나 리눅스 버전이 최신 버전이어야 한다. 파이어폭스와 마찬가지로 프로필 폴더를 정하고 썬더버드를 닫은 다음 폴더를 ZIP 파일로 압축한다. 리눅스에서 이 파일의 압축을 풀고 썬더버드 프로필 폴더를 확인한다. 이제 썬더버드를 닫고 윈도우 프로필의 파일을 이 폴더에 복사한다.
소프트웨어 개발이 쉽다고 생각하는 사람은 아무도 없지만, 이렇게나 다양한 방식으로 어려울 수 있다고 누가 생각했을까? 에반스 데이터에 따르면, 전 세계의 소프트웨어 개발자는 약 2,690만 명으로 추산된다.
최근 AWS의 알리 스피텔이 트위터를 통해 던진 "개발자로서 일하면서 가장 어려운 부분이 무엇인가?"라는 질문에 100명 이상의 개발자가 답했다. 답변은 대부분 몇 가지 핵심 주제에 수렴할 것으로 예상했지만, 실제로는 매우 다양했다. 개발자의 삶을 개선할 방법을 찾고자 하는 기업이라면, 이들 응답을 자세히 살펴볼 가치가 있다. 개발자들의 이야기를 들어보자.
점점 늘어나는 프로젝트 범위 때때로 우리는 개발자를 너무 사랑한다. 우리는 개발자(새로운 킹메이커와 퀸메이커)에게 의존해 혁신을 이루고 혁신을 지속한다. 카일 쉐블린은 "제품과 디자인에 대한 끊임없는 범위 확대의 위협"이 개발자의 삶을 어렵게 만든다고 지적했다. 이는 개발자의 재능에 대한 건강한 믿음에서 비롯된 것이지만, 무분별한 범위 확대는 잔뜩 부풀어 오른 소프트웨어를 낳고 이런 소프트웨어는 유지 관리도 어렵다. 브라이언 심쿠스가 강조한 것처럼 여기에 "비개발자가 설정한 비현실적인 마감일"이 더해지면 이중고를 겪게 된다.
또한 다니엘레 헤벌링이 지적하듯이 개발자는 "실제로 구축해야 하는 것과 기대되는 결과물에 대한 팀 내 의견 불일치"를 싫어한다. 개발자는 항상 "더 나은 솔루션이 있는지 끊임없이 의심"하게 된다. 물론 더 나은 솔루션은 존재하기 마련이다. 다만 뒤늦게 그 해결책에 도달할 뿐이다. 핵심은 자비어 곤잘레스가 주장하듯이 "완벽주의의 무한 루프를 멈출 때"를 파악하는 것이다. 코드는 결코 완벽할 수 없다. 이를 받아들이고 계속 나아가야 한다.
학습의 속도 수십 년 동안 코볼에 대한 이해에 안주해 온 모든 개발자는 오늘날 프레임워크의 유동성이라는 현실에 직면해 있다. 브랜던 트래본은 개발자에게 "언어와 프레임워크의 끊임없는 변화를 따라잡는 것"은 심각한 도전이 될 수 있다고 지적했다. "가장 주목받을 수 있다고 생각되는 것을 골라 거기서부터 시작”할 수 있지만, 그것만으로는 충분하지 않다. "물론 새로운 것으로 '전환'할 준비가 되어 있어야 한다." 프레임워크는 개발자가 데이터베이스나 기타 시스템을 제대로 활용하지 못하게 만드는 경우가 많지만, 때로는 개발자가 혁신의 속도를 따라잡을 수 있는 유일한 방법이기도 하다. 그럼에도 불구하고 쉬운 일은 아니다. 프레임워크가 도움이 되긴 하지만 프레임워크도 변화하고, 그 변화가 문제를 일으킨다.
이와 관련된 것은 애플리케이션 자체의 아키텍처이다. 마이클 자크제스키에 따르면, "애플리케이션이 어떻게 발전할지 예상해 최상의 아키텍처를 준비하되, 처음부터 무리하지 말아야 한다." 어려운 일이다. 예를 들어, 개발자는 확장에 대비해야 할 수도 있지만, 미리 비용을 초과할 정도로 과도하게 프로비저닝해서는 안 된다.
'더 많이 코딩할 수만 있다면' 루크 프로서는 "코딩하지 않는 모든 것"은 소프트웨어 개발을 어렵게 만든다고 말한다. 일부 조사에 따르면, 개발자는 전체 시간 중 5%만 코드를 작성하고 나머지 70%는 코드를 이해하려고 노력하거나 코드와 관련이 없어 보이는 일을 하는 데 소비한다. 이를 "코딩 프로세스를 시작하기 위해 모든 세부 사항을 파악하려고 노력하는 것"이라고 표현하기도 한다. 또 다른 까다로운 문제가 있는데, 바로 "팀 간 협업, 특히 대기업의 경우"이다. 0과 1에 초점을 맞추고 싶지만 소프트웨어 개발은 궁극적으로 사람이 하는 것이며, 사람은 어렵다.
AI가 소프트웨어 개발에서 인간을 배제할 것이라는 일반적인 두려움은 어떤가? AI가 사람을 대체할 수는 없다. 지금은 물론 앞으로도 없을 것이다. 그러니 "매일 아침 일어나서 내가 여전히 이 일과 이 산업에 관심이 있다고 스스로를 설득해야 하는", "LLM이 우리를 비롯한 모든 실제 가치를 창출하는 사람들을 쓸모없게 만들 것이라고 예측하는 관리자들이 걱정하는" 제시카 리와 나머지 모든 숙련된 소프트웨어 개발자들에게 이 말로 끝을 맺고 싶다. “기계가 소프트웨어 개발의 지루한 작업을 더 많이 맡게 되면서 진정으로 사려 깊고 혁신적인 작업은 여러분과 같은 창의적이고 훌륭한 개발자가 영원히 수행할 것이다.”
새로운 최고 AI 책임자를 고용해야 할 정도로 생성형 AI가 중요할까? 코파일럿 키를 내장한 키보드를 구입해야 할까? 부풀려진 기대와 투자로 속에서 기업들은 생성형 AI에 대해 어느 정도의 성과를 거두고 있을까?
생성형 AI는 종전 일회성 머신러닝(ML) 모델에서 벗어날 가능성을 제시한다. 다양한 분야에서 활용될 수 AI 도구의 가능성이다. 그러나 모든 낙관적인 전망에는 함정이 있기 마련이다.
여러 연구에 따르면 많은 사람들이 이미 정기적으로 생성형 AI 도구를 사용하고 있다. 최근페이지듀티의 연구에 따르면 포춘 1000대 기업 중 98%가 생성형 AI를 실험하고 있다. 하지만 동시에 많은 조직이 생성형 AI에 대해 신중한 접근 방식을 취하고 있는 것으로 보인다. 예를 들어,파운드리의 2023 AI 우선순위 연구에 참여한 IT 의사결정권자 중 4분의 1이 생성형 AI 기술을 시험적으로 사용하고 있다고 응답했지만, 이중 배포 단계로 나아간 비율은 20%에 불과했다.
CCS 인사이트의 직원 기술 및 업무 환경 혁신 설문조사에 참여한 고위급 리더들의 응답도 비슷했다. 2023년 말을 기준으로 18%는 이미 전체 직원에게 생성형 AI를 배포했고 22%는 배포할 준비가 되었다고 답했다. CCS 인사이트의 엔터프라이즈 리서치 디렉터 볼라 로티비는 "단 올해 중 생성형 AI의 현실 활용을 기대하는 조직이 많다”라고 말했다.
또 인텔의 2023년 ML 인사이더 설문조사에 참여한 AI 전문가와 같은 IT 팀들의 응답에 따르면, 2023년에 차세대 AI 솔루션을 비즈니스 현장에 도입한 조직은 10%에 불과했다.
현장 배포에 대한 준비 생성형 AI 투자, 파일럿 및 계획을 가진 기업은 많지만, 생산성 향상이나 ROI의 구체적인 내용에 대해 이야기하는 조직은 상대적으로 적다. 예를 들어 골드만삭스, IHG, 메르세데스 벤츠와 같은 많은 구글 고객사들은 최근 구글 클라우드 넥스트 컨퍼런스에서 제미니 생성형 AI 도구를 사용한 사례에 대해 발표했지만, 대개 배포가 아닌 파일럿 단계의 것들이었다.
물론 단순한 실험 수준을 넘어선 파일럿일 수 있다. 맥킨지에 따르면 산업 디자인 팀이 LLM 기반의 연구 요약 기능과 AI 이미지 생성 기능을 사용하는 경우 제품 개발 주기를 70% 이상 단축할 수 있다. 그러나 이러한 디자인 팀이 현실적으로 제조할 수 있는 제품을 만들기 위해서는 평가 및 수정 작업을 추가적으로 해야 한다. 또 정책을 설정하고 직원을 교육해야 한다.
화장품 기업 에스티 로더는 고객 인사이트, 행동 연구 및 시장 동향에 대해 내부 챗봇 훈련과 같은 파일럿 프로젝트를 적용했다. 그러나 이러한 가치를 현실화하는 방법은 여전히 연구 단계에 있다.
현실적인 가치를 이미 얻고 있다는 기업도 있다. 마이크로소프트는 자사 직원들이 마이크로소프트 365용 코파일럿을 비롯한 생성형 AI 도구를 통해 상당한 가치를 얻고 있다고 주장한다. 회사의 최신 업무 및 비즈니스 애플리케이션 부문 CVP인 제라드 스파타로는 "수준급 사용자들은 한 달에 10시간 이상을 절약하고 있다"라며, 사용자의 70%는 생산성이 향상되어 최대 1/3까지 더 빠르게 작업할 수 있다고 전했다.
그러나 포레스터의 수석 분석가인 JP 가운더는 한 달에 5시간 정도의 절약이 일반적이라며, 또 다른 문제는 조직 전체에의 확장 문제라고 말했다. 그는 이어 지금까지 코파일럿 도입이 ‘포켓’에서 이루어지는 경향이 있다고 지적했다. 이는 마케팅 및 영업, 서비스 및 지원, 제품 개발 등의 일부 부서에서 대부분의 생성형 AI 배포가 이루어지고 있다는 맥킨지의 보고서와 일치한다.
해당 보고서에 따르면 설문조사에 참여한 통신사들은 낙관적인 가운데에서도 효과 범위를 제한하고 있었다. 대다수는 생성형 AI를 통해 비용을 절감하고 콜센터 상담원의 생산성이 향상되고 개인화된 콘텐츠를 통해 마케팅 전환율이 개선되었다고 답했으며, 두 모델 모두 몇 달이 아닌 몇 주 만에 배포되었다고 답했다. 그러나 고객 서비스나 매핑 네트워크 인프라 외에는 그 영향이 미미했다.
조직 전체로 확장 마이크로소프트의 초기 테스트 고객 중 일부는 이미 광범위한 배포 단계에 진입했다. 빠르게 마이크로소프트 365 코파일을 테스트한 글로벌 로펌 기업 클리포드 챈스는 현재 애저 오픈AI를 기반으로 구축한 맞춤형 AI 도구인 ‘클리포드 챈드 어시스트’를 전체 직원에게 배포하고 있다. 이 회사는 생성형 AI의 모든 법적 결과물을 자격을 갖춘 변호사가 명확하게 확인하고 분류한다며, 주요 이점은 실시간 기록, 회의 요약, 회의에서 암묵적으로 약속하고 합의한 작업 등 지식 근로자의 생산성 향상이라고 전했다.
가운더는 “생산성을 높이고 시간을 절약하며 훌륭한 인간 비서가 될 수 있는 놀라운 기술이다. 그러나 지난 40년 동안 컴퓨팅 분야에서 출시되어 온 도구와는 다른 성격을 지닌다. 성공을 위해 알아야 할 특징들이 있다”라고 말했다. 그는 조직의 AI 지수를 평가하기 위한 몇 가지 질문을 다음과 같이 제시했다.
- AI와 프롬프트 엔지니어링의 작동 방식에 대한 기본적인 이해가 있는가? - 교육을 받은 적이 있는가? - 이러한 것들을 배울 수 있다는 자신감이 있는가? - 참여하고 싶은 동기가 있는가? - 무엇이 잘못될 수 있고 어떻게 윤리적 사용자가 될 수 있는지 알고 있는?
또 다른 문제는 직원들이 생성형 AI 도구를 워크플로우의 일부로 활용하도록 하는 것이다. "코파일럿에 대해 매우 낙관적이며 호의적인 이들이 있다. 하지만 사용자의 절반은 도구를 사용하지 않는다. 이는 교육에 대한 투자가 부족하기 때문일 수 있다”라고 그는 말했다.
그에 따르면 마이크로소프트 365용 코파일럿을 검토하는 거의 모든 주요 기업은 1시간 정도의 직원 교육만 계획한다면서, 10시간 정도가 적정 수치라고 제안했다. 가운더는 "이것은 핵심 기술이며, 교육에 투자하지 않으면 손해를 볼 수 있기 때문에 교육에 투자해야 한다"라고 말했다.
현실 성공 사례 문서 엔지니어링과 같은 일부 분야에서는 이미 구체적인 생성형 AI 성공 사례가 나타나고 있다. 일례로 도큐가미(Docugami)는 문서 생성 및 데이터 추출에 사용할 수 있는 맞춤형 소형 언어 모델을 통해 고객의 복잡한 문서로부터 지식 그래프를 구축해 성과를 거두고 있다.
회사의 진 파올리 CEO는 특히 보험 분야의 기업들이 가치 평가서, 보험 증서, 갱신 날짜, 위약금 및 책임이 포함된 보험 문서를 위해 도큐가미의 솔루션을 채택해왔다고 전했다. 과거에는 개별 고객과 전체 포트폴리오의 위험을 설명하는 중요한 정보를 반영해 새로운 견적을 생성하거나 재보험사에게 포트폴리오를 설명하는 작업이 수동으로 이뤄졌다는 설명이다. "이러한 시나리오는 몇 백 달러가 아니라 수백만 달러를 절약할 수 있는 실제 시나리오다"라고 파올리는 말했다.
회사의 앨런 예이츠 최고 비즈니스책임자는 또 생명과학 분야의 한 고객 기업의 경우 임상시험 문서화, 규정 준수 및 데이터 탐색을 위해 도큐가미의 플랫폼을 사용하고 있다면서, "이전에는 이 작업을 수행하는 데 6개월이 걸렸지만 지금은 1주일이면 충분하다”라고 말했다.
생성형 AI를 본격적으로 활용하는 또 다른 분야로는 소프트웨어 개발이 있다. 하지만 초기에는 생산성 향상 효과가 낮을 수 있다. 시스코가 6,000명의 자사 개발자에게 깃허브 코파일럿을 배포했을 때, 생성된 코드를 수락한 비율은 19%에 불과했다. 지금은 코드 제안의 거의 절반이 받아들여지고 있다.
한편 전문 지식이 부족한 시민 개발자가 로우 코드 플랫폼을 사용하는 경우 AI로 인한 이득이 훨씬 더 클 수 있다. 디지털 보험 에이전시인 N슈어닷컴은 자동화 흐름을 자연어로 설명할 수 있도록 함으로써 큰 성과를 거뒀다. 생성 및 구성하는 데 4시간이 걸리던 워크플로우가 파워 오토메이트용 코파일럿을 사용해 40분 만에 처리할 수 있게 됐다.
또한 PG&E는 파워 플랫폼의 로우코드 코파일러스 스튜디오 생성형 AI 도구로페기(Peggy)라는 IT 헬프데스크 챗봇을 구축해 직원 요청의 25~40%를 처리함으로써 연간 110만 달러 이상을 절감했다고 마이크로소프트 코파일럿 책임자 노아 게신은 전했다. 그에 따르면 페기가 직원들에게 SAP에 대한 액세스 권한을 잠금 해제하는 과정을 안내함으로써 헬프데스크 팀에서만 연간 840시간을 절약할 수 있었다.
총 비용에 유의 주문형 생성형 AI 도구의 관련 비용을 정확하게 예측하기는 어렵기 때문에 배포를 주저할 수 있다. 개별 생성형 AI 서비스 비용을 저렴할지라도 전사적 배포에서는 큰 비용이 될 수 있기 때문이다.
링크드인의 수석 소프트웨어 엔지니어인 후안 보타로는 "외부 공급업체를 이용하든 내부에서 개발하든, 생성형 AI에서 가장 먼저 고려해야 할 사항은 비용”이라고 강조했다. 그의 팀은 최근 프리미엄 사용자를 대상으로 채용 공고에 적합한지, 어떤 기술이나 자격을 갖추면 채용 가능성을 높일 수 있는지 제안하는 새로운 생성형 AI 기능을 출시했다.
그는 "더 빠르게 움직이고 싶었지만, 사용 가능한 용량과 GPU가 충분하지 않아서 기다리기로 결정했다"라고 말했다. 새 워크플로우의 비용을 예측하기는 어렵고, 사람들의 상호 작용 방식이 매우 다르기에 사용량에 대한 가정을 확신할 수 없었기 때문이다. 대신 소수의 사용자에게 배포하고 그들의 행동을 통해 추론하기로 했다고 그는 덧붙였다.
보타로는 이어 "우리는 한두 달 만에 현재 프리미엄 경험에서 볼 수 있는 것과 매우 유사한 것을 만들 수 있었다"라고 전했다.
CCS 인사이트의 로티비는 생성형 AI 파일럿의 경우 다른 클라우드 서비스와 마찬가지로 API 관리 게이트웨이를 통해 클라우드 AI 서비스에 대한 쿼터 및 아웃바운드 요청 속도 제한을 고려할 수 있다고 설명했다. 그에 따르면 대다수 기업은 생성형 AI의 사용을 특정 역할, 개인 또는 팀으로 제한할 계획이며, 이는 비용 문제 때문인 경우가 많다. "조직 전체에 적용하기에는 너무 비쌀 수 있다"라고 그는 말했다.
무엇을 ‘측정’할 것인가 가우더는 자체 보고된 생산성이 생성형 AI 성공을 측정하는 최선의 방법은 아니며, 배포에 따라 중요한 지표가 달라질 수도 있다고 지적했다. 그는 "티어 1 지원 전체를 생성형 AI에 맡기고 정말 좋은 자연어를 보유하고 있다면 성공률이 높아질 것이다. 하지만 인간의 경험은 다른 문제다. 통화 시간보다는 고객 만족도에 대한 측정 지표가 더 중요할 수 있다"라고 말했다.
또 인공지능 결과의 품질과 정확도를 측정하기란 까다로울 수 있다. 동일한 입력을 해도 매번 다른 결과가 나올 가능성이 높기 때문에 더 어려워진다. 때로는 평가를 위한 벤치마크를 만들어야 한다. 보타로는 “어떤 것이 옳은지 그른지를 정의하는 것은 매우 주관적이고 측정하기 어렵다"라고 말했다.
그의 팀은 도구를 평가하기 위해 좋은 응답이 어떤 모습인지에 대한 공유 지침을 만들었다. 마이크로소프트도 코파일럿 포 애저를 지원하는 애스크 런 API에 대해 답변 품질을 테스트할 근거 데이터와 메트릭을 나타내는 참조 데이터로 구성된 '황금 데이터 세트'를 구축한 바 있다.
가우더는 ROI 입증해야 한다는 압박감이 있지만 대다수 기업이 아직은 그 단계에 이르지 못했다고 경고했다. 영업용 코파일럿의 경우 전환율, 거래 흐름 또는 통화 해결까지의 평균 시간 개선을 참고할 수 있기는 하지만, 변수가 너무 많은 상황에서 직접적인 인과 관계를 가정하는 것은 주의해야 한다고 그는 덧붙였다.
아울러 정량화할 수 없는 이점도 TCO 측면에서 가치가 있을 수 있음을 감안해야 한다. 가우더는 "코파일럿을 제공함으로써 시간을 절약할 수 있을 뿐만 아니라 지루한 업무를 덜어준다고 가정해 보라. 이는 직원 경험 개선으로 이어질 수 있다. 직원 경험 혜택은 이직률을 낮추고 직원들의 동기 부여와 참여도를 높이는 경향이 있다"라고 말했다.
한편 보타로는 생성형 AI와 LLM에 대한 열망이 상황을 복잡하게 만든다고 말했다. "구축이 결정된 상황에서 가치를 측정하는 방법을 찾으려는 접근법이 흔하다. 이는 잘못된 접근 방식이다”라며, 일부 사용 사례에서는 기존 AI로도 충분할 수 있다는 가능성을 열어두라고 제안했다.
생성형 AI 실패 막으려면… 생성형 AI를 도입하는 것이 적절한지, 사용자가 부정확한 답변을 반박할 수 없는 진실로 받아들이는 것을 막는 방법은 무엇인지, 학습 세트에 저작권과 부적절한 자료가 포함되지는 않는 지와 같은 질문을 진지하게 검토해야 한다.
보고된 생성형 AI 실패 사례 다수는 모델 자체의 내재적 문제보다는 경계를 넘나드는 사용자의 무책임한 행동이나 조직이 충분한 AI 기반 보호 도구를 마련하지 않은 것에서 비롯된 경우가 많다. 딥페이크나 단순한 디지털 위조, 학습에 사용된 데이터의 저작권과 관련된 잠재적인 법적 위험, 민감한 데이터나 기밀 데이터에 생성형 AI를 사용할 때 규정 준수에 대한 문제 등이 생성형 AI와 관련된 주요 우려 요소로 손꼽힌다.
아울러 클라우드 생성형 AI 서비스의 경우, 모든 클라우드 모델과 마찬가지로 공동 책임이라는 개념을 수용해야 한다. AI 제공업체는 안전하게 사용할 수 있는 모델과 서비스를 제공해야 하지만, AI 서비스를 채택하는 조직은 모델 카드와 투명성 노트를 읽고 사용 방식을 적절히 제한하고 있는지 테스트해야 한다.
가운더는 "일부 조직은 챗봇을 지나치게 확장하고 일관성 없는 답변을 제공하고 있음을 뒤늦게 깨닫는다”라며, "그렇다고 포기해야 한다는 말은 아니다. 고객에게 출시하기 전에 프로젝트를 철회하고 오프라인에서 반복 작업을 시도할 수 있다"라고 말했다.
한편 생성형 AI에 대한 조직의 성숙도는 일반적으로 기존 AI의 성숙도를 뒤따르는 경향이 있다. 가운더는 "예측 AI, 컴퓨터 비전, 머신러닝에 더 많은 투자를 해온 기업들에서 성공 비율이 높다. 자체 AI 도구를 구축하는 기업들은 여러 기술을 사용하고 있으며, 생성형 AI를 하나의 요소로 취급한다”라고 말했다.
보타로 또한 생성형 AI에 대한 과대광고를 극복하는 방법으로 이를 또 하나의 도구로 보는 것이라고 말했다.
구글이 플러터 팀의 인력을 감축한 데 이어 다트, 파이썬 팀을 인력도 줄이고 있다는 소식이다. 구글은 그러나 해고 사실을 묻는 인포월드의 문의에 응답하지 않았다.
일부 직원들의소셜 미디어 포스트에 따르면 구글은 5월 중 개최하는 연례 I/O 개발자 컨퍼런스를 앞둔 현재, 이들 팀의 인력 일부를 해고하고 있다. 그러나 구체적인 팀, 역할, 대상자 수 등은 알려지지 않고 있다.
플러터와 다트의 한 PM은 X에 게재한 글에서 이번 정리해고가 "많은 팀"에 영향을 미쳤으며 "많은 훌륭한 프로젝트에서 인력을 잃었다"라고 말했다. 레딧에 게재된 다른 게시물에서 또 다른 네티즌은 이번 해고로 영향을 받은 파이썬 팀이 내부 파이썬 런타임과 툴체인을 관리하고 OSS 파이썬을 다루는 직원들이라고 언급했다.
현재까지의 정보를 살펴보면 구글은 4월 24일에 제출된 WARN 공지를 통해 일부 해고 인원을 발표한 것으로 관측된다. 캘리포니아 근로자 조정 및 재교육 통지법(WARN)에 따르면 100명 이상의 직원을 둔 고용주는 정리해고 60일 전에 통지해야 한다. 구글은 해당 서류에서 서니베일의 세 곳에서 총 50명의 직원을 해고한다고 밝혔다.
[python] 생성된 엑셀을 Frequency 순으로, 동일 Frequency 이면 단어순으로 정렬
import pandas as pd
from collections import Counter
import re
def read_text_file(file_path):
"""텍스트 파일을 읽고 내용을 반환"""
with open(file_path, 'r', encoding='utf-8') as file:
return file.read()
def count_word_frequencies(text):
"""주어진 텍스트에서 단어 빈도수 계산"""
words = re.findall(r'\b\w+\b', text.lower())
return Counter(words)
def save_frequencies_to_excel(frequencies, output_file):
"""단어 빈도수를 엑셀 파일로 저장"""
# 판다스 DataFrame으로 변환
df = pd.DataFrame(list(frequencies.items()), columns=['Word', 'Frequency'])
# 빈도수 내림차순, 단어 알파벳순 오름차순으로 정렬
df = df.sort_values(by=['Frequency', 'Word'], ascending=[False, True])
# 데이터를 엑셀 파일로 저장
df.to_excel(output_file, index=False)
# 파일 경로
file_path = 'example.txt'
output_excel = 'word_frequencies.xlsx'
# 파일 읽기
text = read_text_file(file_path)
# 빈도수 분석
frequencies = count_word_frequencies(text)
# 엑셀로 저장
save_frequencies_to_excel(frequencies, output_excel)
print("단어 빈도수가 정렬되어 엑셀 파일로 저장되었습니다.")
DataFrame 변환 및 정렬: pandas.DataFrame을 사용하여 빈도수 데이터를 DataFrame으로 변환한 후, sort_values 메소드를 사용하여 먼저 Frequency 열에 대해 내림차순으로, 동일한 빈도를 가진 항목에 대해서는 Word 열을 기준으로 오름차순 정렬합니다. ascending=[False, True] 파라미터는 각각 Frequency와 Word 열에 적용됩니다.
