평일 낮 사무실에서는 집중하기가 어렵다. 가장 바쁠 때인 탓도 있지만 기본적으로 언제 날아올지 모르는 일거리와 전화에 전전긍긍하다보면 금방 하루가 간다. 최대 집중할 수 있는 단위가 15분 정도다. 그런 상황에서 그나마 할 수 있는 것이라곤 코드 짜는 것 정도일까. 그래서다. 보스의 책에서 제공하는 SAS 코드를 R로 바꾸는 작업을 지난주부터 쭉 하고 있는 이유가. 이제 절반쯤 짰고, 논리 뿐만이 아니라 출력까지 똑같이 SAS로 맞추는 욕심을 내다 보니 속도가 생각보다 안 나긴 했다. 당연하지. PROC UNIVARIATE 에 완전히 일대일대응하는 함수가 없으니 일일히 다 짜는 수 밖에 없으니까.
이 과정에서 얻게 되는 것도 많다. 내가 왜 그렇게 SAS 배우는 게, SAS로 DATA MANAGEMENT하는 게 왜 그리 힘들었는지 좀 더 정확히 알 수 있었다. 정확한 표현이 맞는지 모르겠는데, SAS는 태생 자체가 프로그램 언어는 아닌 것 같다. 그러다보니 뭐랄까, C같은 프로그램 언어를 배운 사람들이 기본적인 문법을 배워 이렇게 하면 되겠지 하고 뭘 짜면 왠만한 건 거의 다 안 돌아간다. 기본적인 이중 루프 만드는 거나, 계산 결과를 계속해서 붙여나가는거나, 기본적인 연산 단위인 변수를 만들어서 한번에 돌린달까. 그런 게 있다. 근데 이런 SAS특유의 독특한 문법을 한 번만 배워두면 코드가 꽤나 짧고 깔끔하게 나오는 장점 무시 못하겠다. 똑같은 결과를 만드는 코드를 짜더라도, SAS가 R보다 왠만한 건 더 짧게 나오더라.
반면 R은 글자 그대로 프로그램 언어. 기본적인 규칙을 알기만 하면 응용해서 내가 PSUEDO CODE만들고 실제 코드를 짜는 데 별다른 불편함이 없다. 다만 프로그램 언어에 익숙하지 않은 사람은 좀 더 시간이 걸리겠지만. 완성된 코드를 직관적으로 이해하기는 SAS보다 R이 낫다고 본다.
그러나 다른 거 다 떠나서, GRAPHICS는 R의 완벽에 가까운 승리. R GRAPHICS COOKBOOK이라는 좋은 레퍼런스가 있는 탓도 있지만, 더 중요한 건 ggplot2와 같이, 레이어 개념으로 그림을 그리는 툴이 있다는 것. sas graphics도 있긴 하지만 코드의 직관성과 논리성은 물론, 편리성에서 상대가 안 된다는게 두 가지를 다 써본 내 생각이다.
군말. 프로그램 "언어" 두 가지를 쓰다 보니, 번역하시는 분들에 대해 경외감을 더 품게 된다. 어떻게하면 이걸 더 직관적으로, 쉽게, 짧게 쓸까. 이건 동일한 고민이기에.
