연구용 코딩시 몇 가지 작성 요령

   대략 5년이 넘는 연구생활 동안 이런저런 작업들을 프로그래밍으로 해결하면서 느꼈던 점을 간략히 말해 보고자 한다. 특히, 몇 가지 요령을 중점으로 얘기해 보고자 한다.

작업 환경 우선, 이야기에 앞서 내가 주로 작업한 환경에 대해 살펴 본다. 아무래도 작업자의 작업 방식은 결국 작업 환경에 의존할 수밖에 없기 때문에, 내가 이야기 할 몇 가지 점들은 특정 운영체제에서만 가능할 수도 있기 때문이다. 나는 연구용 프로그래밍은 거의 대부분 linux에서 gcc를 이용하여 수행한다. 작업을 위한 linux server를 별도로 돌리면서 어디서나 ssh 로 접속하여 작업을 할 수 있게 해 놓았고, 교내에서는 samba로 연결을 해 놓았다. ftp 는 아무래도 불편해서 돌리지 않고 있다. 또한, text editor 는 vi 를 주로 사용하고, 윈도우즈에서도 notepad 보다는 gvim 을 사용한다. 그 가장 결정적인 이유는 치환을 할 때 정규표현식을 쓸 수 있기 때문이기도 하고(이 글의 3번^[각주:1]), 수많은 단축키 때문이기도 하다. 프로그래밍 언어는 주로 C++을 사용하며, 대부분 STL을 사용하기에 포인터는 거의 사용하지 않지만 가끔 속도 때문에 STL 로 된 것을 포인터로 전부 변환하기도 한다. 때때로 파이썬을 사용하기도 한다(비율은 95:5 정도). 윈도우즈에서의 개발 툴은 Visual Studio 2010 을 사용하는데, 주로 그림 파일을 만들 때 사용할 뿐이다.

주석
  
   결과 파일은 흔히 text file로 만들어 지곤 하는데, 이 때 주석으로 사용할 tag 를 미리 지정해 놓으면 좋다. 관례적으로 linux에서는 각 줄의 첫 칸에 나오는 # 이 그 줄이 주석이라는 것을 알리는데, 나 역시 이러한 관례를 따른다. 주석은 의외로 쓸 곳이 굉장히 많은데, 입력받은 파라미터를 출력해 놓는다거나, 결과를 만들기 위해 사용했던 특정 환경 등을 결과 파일 안에 적어 놓을 수 있다. 이러한 내용은 그 파일을 분석하기 위해 다시 사용되지 않는다 하더라도 중간에 잘못된 결과를 발견하였을 때 과정을 확인해 볼 수 있는 중요한 단서가 된다.

   batch

   batch 란 일괄 작업을 의미하는데, 쉽게 이야기 해서 입력받은 파일 10,000 개에 대하여 동일한 작업을 하는 것을 의미한다. 단일 파일만을 처리하도록 프로그래밍 하는 것은 간단한 일이지만 수천, 수만 개의 파일을 처리하도록 하는 것은 은근히 까다로운 경우가 많다. 따라서 단일 처리를 하도록 만든 프로그램을 batch 가 되도록 수정하는 것은 약간의 노고를 필요로 하므로, 아예 애초부터 batch 를 염두에 두고 코딩을 한다. 물론 linux 에서는 find 명령어를, 그 이름이 의미하는 것과는 별개로, 이용해서 batch 가 되도록 할 수 있지만(참고^[각주:2])- 난 이렇게 자주 한다 - 문제는 '시간'이다. 즉, 무턱대고 코딩하면 처리할 파일의 수가 많아지면 처리시간이 급격히 늘어날 수 있다. 따라서 find 로 batch 로 돌리더라도 단일파일처리시간이 되도록 짧으면 좋으므로 될 수 있으면 그렇게 한다.

   configuration

   프로그램, 즉, 작업을 할 때 필요한 환경, 입력 변수 등을 설정해 놓은 파일을 만들어 사용한다. 즉, terminal에서 프로그램을 수행시킬 때는 주로 다음과 같이 입력 파라미터를 공백을 기준으로 분리하여 입력하게 되는데,

logrank_analysis_by_group ../chip_data/GSE6532_6/ ~/surv_clusters/logrank/one_gene/ T.DMFS ./gene_compare_config/AllGene.config 1

만약 입력해야 할 값이 매우 많다면 수행하기 번거로워 진다. 위의 경우 logrank_analysis_by_group 이라는 코드는 입력 파라미터로 5개를 받아 들이고 있다. 이런 것을 일일이 해야 한다면 여간 불편한 것이 아니며, 더구나 이러한 처리를 하도록 코딩을 하는 것 역시 별로 깔끔하지 못하다.

이럴 땐 프로그램이 수행될 때 필요한 변수들을 파일로 저장해 놓고 그 파일들의 값을 읽어 와서 처리를 하도록 하면 편리하다. 한 예를 살펴 보면 다음과 같다.

INIT_DIR        /home/adnoctum/Research/microarray/chip_data/
OUT_DIR /home/adnoctum/Research/microarray/analysis_code/Responsiveness/Cancer/BreastCancer/merged2/
TF_OUT_DIR      /home/adnoctum/Research/microarray/analysis_code/Responsiveness/Cancer/BreastCancer/merged2_tf/
TF_ALLGENE_OUT_DIR      /home/adnoctum/Research/microarray/analysis_code/Responsiveness/Cancer/BreastCancer/merged2_tf_allgene/
OUTPUT_TAG      CancerBreast
GSE17040:GPL887:CANCER  1       0.977528     
GSE21653:GPL570:CANCER  0.977528        1     
GSE3744:GPL570:CANCER   0.955056        0.988764       
GSE5327:GPL96:CANCER    0.949438        0.966292       
GSE5460:GPL570:CANCER   0.966292        0.994382      
GSE7849:GPL8300:CANCER  0.949438        0.983146     
GSE8193:GPL4685:CANCER  0.966292        0.983146     
GSE12093_2:GPL96:CANCER 0.88764 0.966292       
GSE12276:GPL570:CANCER  0.983146        0.994382       
GSE12763:GPL570:CANCER  0.97191 0.988764       
GSE14548:GPL1352:CANCER 0.977528        0.983146       
GSE15116:GPL8253:CANCER 0.977528        0.988764       
GSE16201:GPL8583:CANCER 0.988764        0.988764       
GSE16391:GPL570:CANCER  0.977528        0.994382 

앞쪽에 입력변수가 무엇인지를 알려 주는 값이 있고 두 번째 column 에 그 값이 있다. 관례^[각주:3]상 입력변수를 의미하는 값은 모두 대문자를 사용했다. 이 경우 이 configuration file 을 읽는 부분은 다음과 같이 코딩되어 있다.

클릭을 하면 원본 크기로 볼 수 있는데, 중요한 점은 다음과 같은 부분이다.

223번 째 줄. 즉, configuration file에 알 수 없는 tag 가 존재할 경우, 무시하거나, 에러를 내도록 처리하는 것. 이것은 비슷한 format 의 configuration file 을 다루는 다른 코드를 작성할 때 유용하게 사용된다. 이와 같은 방법은, 또한, pdf file format 처럼 하위 버전의 reader 가 상위 버전으로 만들어 진 파일을 읽을 수 있는 것과 같은 호환성을 제공해 준다. 즉, 모르는 tag 가 있으면 무시하는 것.


결과 파일이 입력 변수 값 출력

입력 변수로 어떤 값을 사용했었는지를 확인해야 할 경우가 '가끔씩' 있다. 물론 이 '가끔' 이라는 것 때문에 무시할 수도 있겠지만, 경험해 본 사람은 알 것이다, 정말 제대로 처리되었는지 확인할 길이 없기 때문에 모든 데이터를 '다시' 처리해야 하는 경우도 있다는 것을. 겨우 몇 십 줄에 1KB 의 메모리도 사용되지 않으므로, 될 수 있으면 결과 파일에 입력받은 파라미터도 같이 출력해 준다. 물론, 이 때, 이 값들은 '확인용'으로만 사용할 가능성이 높으므로 주석으로 처리해도 무방할 것이다. 다음과 같다.

vi는 주석을 붉은 색으로 표시해 줘서 더욱 편리한데, 어쨌든 위처럼 실제 결과 파일에 입력받은 파라미터도 같이 출력해 준다. 물론 그냥 확인용이기 때문에 format 을 맞출 필요는 없지만, 위의 경우, 혹시나 이 값들을 확인하는 루틴을 작성해야 할 경우가 생길지도 몰라서 적절한 format 을 갖도록 해 놓았다. 즉, # 으로 시작하고 tab-delimited 이면서 첫 번째 column 이 Parameters 이면 입력 파라미터 값이고 두 번째 column 은 변수 이름, 세 번째는 변수 값, 이런 식으로.

1. 배워볼만한 프로그램들 [본문으로]
2. 리눅스의 find 명령 [본문으로]
3. 관례는 일관성을 제공해 주고, 일관성은 코드를 볼 때 편리함을 제공해 준다. [본문으로]