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