현재 독일은 긴 휴일중이고, 집에서 애들이 즐겁게 뛰어노는 가운데 논문작업의 집중에 약간의 한계를 느껴서 막간을 할애해서 글타래를 열어보았습니다. 필자는 현재 인텔맥 Big Sur환경을 사용하고 있고, 그 배경 및 환경설정에 대한 이야기를 한번씩 정리해서 올린적이 있습니다. 혹시 궁금하신 분들을 위해 그동안 올린 글들의 링크를 정리해두었습니다. 1. 그동안 사용한 맥들의 소희 (1, 2), 2. iTerm2 + Emacs 환경설정, 3. Intel oneAPI (Intel compiler / MKL / Time Profiler) 환경설정, 4. 연구용 Python / Jupyter 환경설정 및 기본 활용 예시 .
0. 들어가는 글
연구 워크플로우에 대한 요약이야기는 여러가지 단계로 생각하고 있습니다만, 오랫동안 사용해오던 환경에 대해서 최대한 드라이하게 전달하는게 맞다고 생각합니다. 이는 사용 환경과 방법에 더함이나 덜함없이 없이 보여서, 어디까지가 필자가 손에 익어서 집중에 방해받지 않고 일할수 있는 환경인지를 인지하는것도 중요하기 때문입니다. 또 한편으로는, 특별한 ‘환상’을 심지 않는것도 매우 중요하다고 생각합니다.
당연하게도, 중요한 도구들을 구성하여 그것들로 생산성을 높이는것은 매우 중요합니다. 하지만, 필자가 더 중요하게 여기는것은, 그 도구의 자유도로 인하여 지금 생각하고 있는 문제에 대한 집중력을 잃지 않는 것입니다. 어떤 의미에서는, 도구를 매우 손에 익게 만들어서 마음가는대로 쓸 수 있어야 한다는 이야기 일 수도 있습니다. 하지만 더 중요하게 생각하는 부분은, 절제력이라 생각합니다. 너무 많은 강력한 도구들로 워크플로우를 구성하려는 과욕은, 직접적인 생산성 향상에 큰 도움이 되지 않는다는 부분을 말씀 드리고 싶습니다. 늘 그렇듯, 인지영역의 한계는, 본인이 집중하고 싶은 문제 그 자체에서 멀어지게 만들곤 합니다. 그 순간의 ‘약간’의 집중력의 향상은 ‘드라마틱하게’ 문제의 접근 속도를 올려주곤 합니다. 인지영역을 넘어서는 도구는, 대체 불가능한 중요한 도구를 제외하고는 (결과적으로) 취미의 영역에서나 사용하게 됩니다. 그건 취미이기때문에 또 다른 재미가 있지만, 실제 워크플로우에 들어가는 경우는 극히 드물었던 것 같습니다.
위에서 ‘환상’에 대한 이야기를 했습니다만, 이는 필자의 경험에 국한적인 부분으로서 오래전에 리눅스에서 맥으로 넘어오면서 가지고 있던 몇가지 환상들이 있었습니다. 오랜기간동안, 수치해석->시뮬레이션->이론연구로 연구의 방향을 조금씩 틀면서 상당히 하드하게 맥을 사용해오던 입장에서 생각외로 여러곳에서 불편함을 느끼곤 했습니다. 슈퍼컴퓨터를 많이 쓸때도 은근히 Linux UI와 제 맥에서 다룰때 스크립트를 수정해야할때가 있어서 고통을 받기도 했고요 (예시를 들자면 한도 없지만, 의외로 생각해보려면 잘 생각안나는 그런게 많습니다.) 항상 그렇지만 ‘자잘함’이 모이면 ‘큰 문제’가 되는 경우가 많습니다. 이런 문제를 파악해보면, 시스템 환경설정이 미묘하게 다르다거나 하는 문제와 연결되는데 (예를들어 sed같은 경우…) 그런걸 매번 검색해서, 여기는 되고 안되는 이유를 완전히 파악하기는 힘이 들지요. 다시말하지만, 저는 컴퓨터 기술자가 아니라 과학에서 연구일을 하는 사람입니다. 덧붙여, OS X의 메이저 업데이트마다 패키지 관리소들이 엉키곤 해서 많은 고통을 받곤 했었습니다. 썰을 풀자면 제법 많지만, 저의 부족함에 대한 이야기이므로 여기까지 하겠습니다. 다만, 이러한 ‘부족한’사람 입장에서 주요 폴더의 구조 및 권한 설정이 메이저 업데이트 마다 바뀌게 되면, 기존에 잘 돌아가는 소프트웨어를 그대로 잘 돌아가기 위해 하루에서 길면 몇일씩 구글검색하면서 문제 해결해야 한다면, OS X는 그리 적절한 환경은 아니었던 것 같습니다. 사실 필자의 작업 환경은 몇가지 소프트웨어를 제외하면 리눅스의 주요 배포판에서 더욱 안정적으로 사용할수있습니다. Long-term support (LTS)이면 금상첨화이지요. 사실 지금도 맥을 쓰는 이유는, 이런 일들을 겪다보니 어느정도 내성이 생긴것도 사실인데다가, 일반적인 리눅스 머신에서 제공하지 못하는 활용성들이 있기 때문이지 않을까 생각합니다.
1. 논문 집필 환경: LaTex (Emacs – RefTex – SyncTex + Skim)
LaTex는 현재까지도, 문헌작성의 가장 중요한 도구중 하나입니다. 현재 제가 관여한 대부분의 저널은 LaTex 템플릿을 제공하거나 (보통은 퍼블리셔 템플릿을 사용하게 되지요 Elsarticle이나 Revtex – 특히 AIP쪽 -, 이거나 혹은 최근에 많이 이슈가 되고 있는 MDPI쪽도 마찬가지입니다) 혹은 오픈 템플릿인경우도 있습니다. 해당 글은, Tex자체의 사용에 대한 글이 아니라 (좋은 메뉴얼이 많이 있습니다) 그냥 환경설정 및 몇가지 필자가 사용하는 워크플로우에 대한 소개입니다.
1-1. Emacs
필자의 경우에는 기본 에디터로 Emacs를 활용하고 있습니다. Emacs에서 LaTex관련 중요한 도구들이 많이 있습니다만 그건 아래에서 소개해드리도록 하고, 여기서는 Emacs 자체에 대한 이야기를 진행하도록 하겠습니다.
사실, 지난번 Emacs설정에 대한 글을 적을때 테마나 기타등등에 대한 이야기를 했었는데, 이 때 가장 중요한 영향을 미친 것이 바로 LaTex환경입니다. 제가 사용하는 테마 (지난번 글)를 사용하는 경우, 기본적으로 수식이 명료하게 확인되고, 내용 확인에 눈이 편합니다. 각종 커맨드등이 명확하게 구분되는것도 매우 유용합니다. 코멘트들이 비교적 잘 안보이는 편입니다만 이는 의도적으로 dark red를 사용해서 발생되는 현상입니다. 코멘트의 경우 mark 기능 (C-space) 활용을 통해 필요시 코멘트의 컨트라스트를 올려서 확인시키는게 저는 편합니다.
여기서 Emacs의 기본적인 네비게이션 기능은 사실 생각하지 않고 그냥 몸에 익어야 하는 것 같습니다. 처음 공부할때가 잘 기억나지는 않는데 처음 시작할때는 생각보다 비직관적이어서, 시간이 많이 걸렸던 것 같습니다. 지금은 오히려 반대라서, 다른 도구들마저도 Emacs의 Keybinding을 사용하도록 설정하곤 합니다. 예를들어 지금 생각하고 적으려니 오히려 힘든 (그래서 움직여보고 다시 키를 받아쓰는) C-p/C-n/C-f/C-b 뿐만아니라 M-< / M->, 혹은 C-v/M-v, 마킹인 C-space, 그리고 찾기에 핵심인 C-s까지는 숨쉬는것, 걷는것 같은 느낌이어야 큰 불편없이 집필이 진행되는 것 같습니다. 필자역시 M-g g 나 C-x r k / C-x r y / C-x r t 같은 기능들은 생각하면서 움직이는 편입니다. 그리고 그 이외 부가적은 기능들은 대부분 M-x를 활용합니다. 예로 들어 “replace-string”은 의외로 자주 사용하는 기능이면서 따로 키바인딩을 생각하지 않습니다. 덧붙여 컴파일 기능인 C-c가 있네요.
1-2. RefTex
많은 집필 환경과 마찬가지로, Emacs의 LaTex환경에서 가장 중요하게 사용되는 기능은 cross-reference 및 citation기능을 함께 가지고 있는 강력한 도구인 RefTex입니다. 저의 경험상, Emacs LaTex환경이 설치되어있으면 함께 따라옵니다만, 일단은 RefTex임을 인지하는것도 중요하다고 생각합니다.
Emacs기본 네비게이션을 제외하고, RefTex를 활용하는 중요한 네비게이션은 C-=, table of contents (toc)입니다. 기본적으로 각 섹션위주로 보여주고, 계층 제어를 할 수 있습니다. 예로들어 특별 항목을 Section에서 subsection으로 혹은 반대로 제어할수 있는 기능도 있고, 여기에 navigation기능이 함께 포함되어있습니다. 소문자 ‘L’을 눌러서 각종 label을 확인 할 수 있습니다. Label은 LaTex에서의 cross-reference의 핵심 기능으로서 현재의 수식이나 그래프, 각종 그림, 섹션등에 이름을 붙여주는 기능입니다. 명료한 label의 사용은 toc (C-=)에서 손쉽게 (소문자 ‘L’) 확인을 할 수 있게 해주고, 여기에 navigation기능이 합쳐지면 매우 강력한 도구가 됩니다. 예로들어 toc에서 ‘f’키의 옵션을 켜두게 되면 navigation따라 자동으로 추적해줍니다. ‘space’의 경우 해당 섹션이나 (섹션은 toc에서 다른 레이블 없이 나타납니다. 물론 레이블을 넣는 경우도 자주 있습니다) 특정 레이블이 있는 곳을 즉각적으로 보여줍니다. 만약 ‘return’을 사용하면 toc는 사라지고 그 공간으로 가 있습니다. ‘tab’을 사용하게 되면 toc는 살아있고 그 공간으로 가 있습니다. 다양한 네비게이션 기능이 있지만, 필자가 다른 생각을 요하지 않고 즉각적으로 toc에서 쓰는 기능들은 대부분 소문자 ‘l’과 ‘tab’, ‘space’입니다. 그 이상은 한번쯤 생각해보게 됩니다.
단순히 navigation만이 중요한게 아니라, cross-reference를 생성하고 특히 가져오는데 특화되어있습니다. 물론 수식에 이름(레이블)이 아직붙어있지 않다면 직접 가서 C-(로 입력하면 됩니다 (혹은 직접 \label{eq:xxx}) 이미 잘 정의한 이름이 있는 경우에는 그리고 기억한다면 그냥 타이핑 해도 됩니다. 그런데 솔직히 말하자면, 한창 작업중인 논문인 경우에도 레이블 이름이 잘 기억안날때가 잘 날때보다 많습니다. 그럴때는 C-) -> “f”/”e”/”s” 등 첫 문자를 입력하면 알아서 toc에서 해당 키로 시작되는 label을 보여줍니다. 위의 예시의 경우 fig: eq: sec: 등으로 구성되어있습니다. 좋은것은 여기서 한줄 수식도 (Tex 코드형태로) 보여줍니다. Figure (“f”)의 경우 caption 앞머리가 보여집니다. 이중에서 선택하면 자동으로 cross-reference를 가져옵니다.
위에 언급한 “C-(“, “C-)”가 cross-reference라면 실질적인 reference의 경우 “C-[“가 담당합니다. “C-[“이후 간략한 저자명이나 코드 혹은 연도, 타이틀에 들어가는 단어등을 입력하면 ‘연결된’ biblatex를 색인하여 찾아줍니다. 그 중에서 정확한 자료를 선택하면 자동으로 reference를 달아줍니다. 이 때 RefTex에서 검색하는 biblatex는 (1) 해당 tex파일에 연결된 .bib 파일과 (2) RefTex에서 인위적으로 설정해준 .bib 파일입니다. 필자는 예전에는 global bib파일을 사용하였고 다음과 같이 .emacs에 추가했었습니다. 앞에 ;;코멘트화 되어있는것은 현재는 사용하지 않는 옵션을 의미합니다.
;; (setq reftex-default-bibliography '("~/path_to_bib/biblatex_papers.bib"))
;; (setq reftex-biblography-commands '("bibliography" "nobibliography" "addbibresource"))
이때 .bib파일의 경우 Papers 3시절에 자주 전체문헌 리스트를 .bib 파일로 export시켜두고 사용했었습니다. 최근들어서는, 해당 기능을 사용하지 않고 그냥 프로젝트별로 따로 .bib를 구성시켜서 사용하고 있습니다. 만약 그 순간 없다면 그냥 손으로 TODO-bib: Apple et al. (1111) 등으로 적어두고 나중에 일괄적으로 처리합니다.
Global한 bib 파일을 더이상 구성하지 않는데에는 여러가지 이유가 있는데, 가장 큰 이유는 더이상 연구 소노트들을 org-mode를 이용해서 구성하지 않기때문입니다. (요즈음에는 Devonthink에서 rich text로 구성해둡니다.) 해당 주제에 대해서는 한 번 더 글타래를 열어 볼 예정입니다. 그래서, LaTex로 작업하는 문서의 경우 이미, 적어도 중간단계에 해당되는 문헌으로서 기본적인 참고문헌 리스트가 이미 참고문헌 관리 시스템에 구성되어 있습니다 (현재는 Bookends를 사용합니다). 소프트웨어에서 제공하는 자동 매칭이 조금 틀린데가 있더라도, 이를 일괄적으로 .bib파일로 넘겨서 사용하고, 실질적으로 논문 작업시는 세세한 디테일때문에 betterbib패키지를 이용해 한차례 가공한 다음, 직접 디테일을 수정합니다 (이 경우 해당 수정부분을 스크립트화 시켜서 일반적으로 bib_control.sh와 같은 스크립트 코드를 수정하곤 합니다. 여기서 betterbib의 경우 아마도 pyenchant와 enchant가 설치되어야 하는 듯 하네요.
brew install enchant python -m pip install pyenchant betterbib
1-3. SyncTex + Skim
필자의 집필 환경에서 기본 pdf 뷰어는 Skim을 사용합니다. 이는 다양한 Skim의 기능들을 활용하겠다는 의미보다는, SyncTex와 결합하여 Emacs <-> Skim의 상호 인터랙션을 강화시키고자 하는 생각입니다.
쉽게 말씀드리자면, Emacs에서 C-c C-v를 누르게 되면 Skim에서 pdf파일에 있는 현재 Emacs에서 선택된 라인으로 이동하면서 하이라이트가 다음 스크린샷처럼 보여집니다. 빨간색 포인터가 현재 커서의 위치를 나타내는데, 그렇게 정확한것 같지는 않습니다.
이번에는 Skim에서 특정 지점에서 Shift-Command + 클릭을 하게 되면 Emacs에서 해당 라인에 해당되는 코드로 가게 됩니다. 이 쌍방향 인터랙션은 문헌 수정에 있어서 아주 큰 역할을 담당합니다. 사실 의외로 문헌작성에 있어서 navigation에 소모되는 시간이 제법 됩니다. 머리속으로 생각한 것이 어디에 있는지 찾는것은 편리한 검색기능이 있다고 하더라도, 매번 교차해서 찾는것보다는 한번에 찾아주는게 좋지요. 물론 모던 LaTex편집기에는 이와 비슷한 기능들이 하나씩은 있는걸로 알고있습니다.
이와같은 설정을 위해 이전글에서는 언급한적이 있던 Emacs server를 사용할 필요가 있습니다. 원래 Emacs server기능의 목적은 빠른 로딩 및 여러가지 편의성을 증대시키기 위해 나왔습니다. 하지만 필자의 경우 emacs -nw / emacs / emacsclient 세가지의 활용이 번거롭고, 매번 헷갈리기 일쑤여서 emacs server를 사용하지는 않습니다. (emacs server를 본격적으로 활용하기 위해서는 emacsclient로 실행할 필요가 있습니다). Emacs server의 경우 어떤 emacs에서든지 M-x server-start로 수행할 수 있습니다. 만약 .emacs에 다음 코드를 삽입하면, Emacs시작시 자동으로 수행하곤 합니다. 물론 이경우 조건문이 없는경우 server를 Emacs가 실행될때마다 시작하려 하지만, 막상 기본적으로 하나를 열수있는 구조이므로 에러가 날 수 있습니다.
;; (server-start)
이와는 별개로 다음 설정들이 .emacs에 필요합니다.
(setq TeX-view-program-selection '((output-pdf "PDF Viewer")))
(setq TeX-view-program-list
'(("PDF Viewer" "/Applications/Skim.app/Contents/SharedSupport/displayline -b -g
덧붙여 다음 부분을 .latexmkrc에 추가합니다 (만약 파일이 없다면 그냥 만들어도 됩니다)
$pdflatex = 'pdflatex -interaction=nonstopmode -synctex=1
$pdf_previewer = 'open -a skim';
$clean_ext = 'bbl rel
이후, 이맥스에서는 C-c latexmk로 컴파일하고 C-c view로 skim을 열면 됩니다.
Leave a Reply