기능이 아니라 '철학'으로 본 두 언어의 차이
제약 업계 커리어를 시작한 뒤, 저는 사실상 SAS만 사용했습니다.
통계 분석, 리포트, 규제 제출용 테이블까지 모두 SAS 해결 됐고, "임상통계는 SAS"라는 말이 전혀 어색하지 않은 환경이죠.
SAS는 제게 비싼 세단 같은 존재입니다.
유지비는 많이 들지만, 한번 시동을 걸면 언제나 똑같은 결과를 재현할 수 있고, 고객이나 규제 기관에 내놓아도 "믿을 수 있다"는 신뢰가 따라옵니다.
그런데 AI와 클라우드 이야기가 커질수록,
저는 Python이라는 오프로드 트럭 쪽으로 눈을 돌리게 되었습니다.
핸들은 뻑뻑하고, 타이어 소음은 크고, 가끔은 시동이 안 걸리 때도 있지만, 이상하게 못 가는 길이 없는 차 처럼 느껴졌기 때문입니다.
오늘은 통계학자인 제가 이 두대의 차를 모두 몰아본 입장에서
SAS와 Python의 차이를 "기능"이 아닌 "철학"의 관점에서 정리해보려고 합니다.
1. SAS의 철학: "우리는 틀리지 않는다"
SAS를 사용할 때 가장 편한 점은 "제조사에 대한 무한한 신뢰" 입니다. SAS의 문법, 특히 PROC 명령어들은 수십 년간 검증되었습니다. 20년 전에 작성한 코드를 오늘 돌려보아도 똑같은 결과가 나옵니다.
FDA 와 같은 규제기관이 사랑하는 이유가 바로 이겁니다.
철학: "사용자는 고민하지 마라. 결과는 우리가 보증한다"
장단점: 블랙박스가 없습니다. 누군가 "이 결과 맞아요?" 라고 물으면 "SAS로 돌렸습니다" 라는 말 한마디로 방어가 됩니다. 다만, 정해진 도로 (정형 데이터)가 아니면 사용하기가 힘듭니다. 비정형 데이터를 분석하거나 최신 딥러닝 모델을 얹으려 하면, 세단에 트랙터 바퀴를 끼우는 것 처럼 어색합니다.
2. Python의 철학: "네가 가는 방향이 곧 길이다"
Python은 운전자에게 끊임없이 "정비"를 요구합니다. 라이브러리 버전이 안 맞으면 어제 잘 돌아가던 코드가 오늘은 에러를 내뱉습니다. 인덱스는 0 부터 시작해서 숫자 계산하는 사람을 헷갈리고하고, 패키지마다 사용법도 제각각입니다.
하지만 이 불편함 뒤에는 '무한한 자유'라는 철학이 있습니다.
철학: "길이 없으면 만들어서 가라. 도구는 세상에 널려 있다"
장단점: 못 가는 곳이 없습니다. 이미지든, 텍스트든, Python의 짐칸에 다 실립니다. AWS 클라우드같은 광활한 대지 위에서 수만 명의 환자 데이터를 병렬로 처리할 때, 이 트럭의 마력은 폭발합니다. 다만, 결과에 대한 책임은 온전히 나에게 있습니다. "이 라이브러리에 버그가 있어서 결과가 틀렸네요" 라는 변명은 규제 기관에 통하지 않습니다. 그래서 끊임없이 의심하고 검증해야 합니다.
3. 두 핸들을 모두 쥐었을 때
처음엔 Python이 낯설고 불편했습니다. MERGE 한 줄이면 끝날 일을, pd.merge에 how, on 옵션을 일일이 지정하며 사용해야 하나 싶었죠.
하지만 '데이터의 성격' 에 따라 차를 바꿔 타는 법을 배우게 되었습니다.
탐험 할 때: 거친 원석 같은 RWE를 처음 받으면 Phython을 이용합니다. 결측치를 시각화해서 뜯어보고, 머신러닝으로 변수 중요도를 빠르게 훑어봅니다. 정해진 길이 없는 곳을 헤집고 다니기에 충분합니다.
증명 할 때: 인사이트를 최종적으로 입증하고, 보고서를 쓸 때에는 SAS로 갈아탑니다. 엄격한 통계적 가정을 검증하고, 규제 기관이 요구하는 표준 테이블을 뽑아내는 정교함은 여전히 SAS가 압도적입니다.
4. 마치며: 중요한 건 '차'가 아니라 '드라이버'
후배들이 "SAS를 버리고 Python만 파야 하나요?" 물으면 저는 이렇게 답합니다.
"어떤 차가 좋냐는 의미가 없다. 너가 지금 정글을 헤치고 있는지, 고속도로를 달리는지 파악하는게 먼저다"
도구의 화려함에 매몰될 필요는 없습니다. SAS의 엄밀함과 Python의 유연함을 모두 이해한 사람만이, 험난한 데이터의 숲에서 길을 잃지 않고 목적지에 도달할 수 있습니다.