프로그래밍 규칙은 마치 코딩을 더 지루하게 만들기 위해 존재하는 것처럼 보일 때가 가끔 있다. 전처리기를 사용해 소프트웨어 개발의 재미를 되찾을 수 있는 14가지 방법을 소개한다.

개발자는 프로그래밍 언어를 무척 좋아하지만 그 언어가 구속복처럼 느껴지는 경우도 많다. 프로그래밍 언어는 구문 규칙이 복잡하게 얽힌 덩어리이며, 그 규칙을 한 번이라도 어기면 컴파일러는 오류 메시지를 요란하게 쏟아내기 시작한다. 최선의 변수 명명 방법이나 코드 들여쓰기 방법과 같은 사소한 모든 부분에 규칙이 존재한다. 언어 설계자는 이러한 제약이 버그가 아니라 기능이라고 주장한다.

ⓒ sivivolk/Shutterstock

<이미지를 클릭하시면 크게 보실 수 있습니다>

그러나 프로그래밍 언어가 꼭 그래야 할 필요는 없다. 영리한 개발자는 몇 년 동안 자신만의 독특한 스타일로 코드를 작성하기 위한, 어떻게 보면 교활하고 어떻게 보면 그렇지 않은 여러 방법을 고안했다. 전처리기는 그 빈 틈을 메우는 방법으로, 코드가 컴파일되기 전에 파이프라인에 개입해 코딩의 재미를 위한 이상한 변형과 저마다의 스타일을 수정한다.

전처리기는 새로운 것은 아니다. C와 같은 언어는 오래전부터 전처리기에 의존해왔다. 그러나 최근 들어 프로그래머가 원하는 방식대로 소프트웨어를 작성하기 위해 더 표현적인 여러 방법을 고안해 내면서 전처리기의 인기도 함께 높아지고 있다. 컴파일 시점이 되면 각 프로그래머들의 고유한 스타일이 소리 없이 제거되고 엄격한 언어 규칙에 부합하는 최종 버전이 만들어진다.

구속복에서 벗어나려는 프로그래머들을 위해 코드를 전처리하는 여러 방법을 소개한다. 이 중에는 언어별 전처리기, 데이터 과학자와 개발자 사이의 간극을 메우는 전처리기, 심지어 미국식 영어를 대서양 건너편 영국 개발자의 입맛에 맞게 바꿔주는 전처리기도 있다.

LESS와 SASS

CSS의 힘과 책임이 너무 커진 나머지, 이제는 현대 사이트의 여기저기서 볼 수 있는 복잡다단한 레이아웃에 질서를 부여할 방법이 필요해졌다. LESS(Leaner CSS)와 SASS(Syntactically Awesome StyleSheets)는 CSS 레이아웃을 단순화하는 변수 및 기타 함수를 배포해서 좀 더 프로그래머답게 움직일 수 있게 해주는 전처리기다. 웹사이트 디자인에 어느 한 색상이 지배적으로 사용되는 경우 이 색상을 한 번만 정의해주면 된다. SASS는 둘 중에서 더 강력한 전처리기로, 루프와 같은 더 복잡한 옵션을 제공한다. LESS도 SASS에 비해 간소할 뿐이지 마찬가지로 강력하다. 두 가지 툴 모두 프로그래머의 손길과 감각으로 끝이 없어 보이는 CSS 레이아웃 옵션을 목록을 정리할 수 있게 해준다.

업서드JS(AbsurdJS)

일관성을 좋아해서 한 가지 특정 언어로 작업하는 편을 선호하는 사람들도 있다. 자바스크립트의 팬이고 자바스크립트의 힘을 CSS를 꾸미는 데 사용하고 싶다면 업서드JS라는 전처리기를 사용하면 된다. 이름에 JS라는 문자가 있지만 목표는 CSS다. 업서드JS에서는 상속과 같은 프로그래밍 개념의 힘을 사용해 정교한 CSS 레이아웃을 만들 수 있다. LESS, SASS와 마찬가지로 디자이너가 아닌 프로그래머의 입장에서 생각할 수 있게 해주는 전처리기다.

바이썬(Bython)

개발자에 따라 중괄호를 사용해 코드 블록을 정의하기를 좋아하기도 하고, 스페이스바와 탭 키를 선호하기도 한다. 파이썬은 깔끔한 들여쓰기를 좋아하는 프로그래머에게 좋은 언어다. 이제 파이썬이 더 강력하고 더 광범위하게 사용되는 언어가 된 만큼 중괄호를 좋아하는 사람들 일부도 파이썬 라이브러리와 툴을 사용해보고 싶을 수 있다. 바이썬은 중괄호와 파이썬 라이브러리를 모두 유지할 수 있게 해주는 전처리기다. 평상시처럼 코딩하면 나머지는 바이썬이 알아서 해준다. 중괄호를 들여쓰기로 자동으로 대체하므로 스페이스바를 누를 일이 없다.

파이프리프로세서(Pypreprocessor)

C 언어는 오래전부터 C 코더들에게 전처리 문을 사용해 코드에 대한 복잡한 의사 결정을 내릴 수 있는 기회를 제공해왔다. 예를 들어 #ifdef를 사용해서 큰 코드 블록을 켜고 끌 수 있다. 이제 파이썬 프로그래머들도 플래그와 메타변수를 사용해 자유롭게 코드를 없애고 다시 나타나게 할 수 있는 동적 라이브러리인 파이프리프로세서로 똑같이 할 수 있다.

타입스크립트

자바스크립트는 원래 대부분이 HTML로 만들어진 웹사이트에 작은 코드 블록을 추가해야 했던 웹 프로그래머를 위해 만들어진 언어다. 변수의 타입을 명시하지 않아도 큰 문제가 되지 않았다. 자바스크립트 코드 블록은 작고 이해하기도 쉬웠기 때문이다. 하지만 상황이 바뀌어 이제는 많은 개발자가 수천 줄의 자바스크립트로 정교하고 매우 동적인 사이트를 구축한다.

자바스크립트의 범위가 워낙 넓어서 이제 일부 개발자는 강한 타입 코드에서 비롯되는 확실성을 원한다. 타입스크립트는 그 요구에 대한 답이며 매우 효과적인 타협안이다. 일반 자바스크립트는 타입스크립트에 계속 허용된다. 즉, 추가하는 모든 타입 정보는 선택 사항이다. 타입스크립트의 전처리 단계는 오류를 두 번 확인한 다음 일반 자바스크립트 엔진이 처리할 수 있는 정보를 내보낸다. 인기 있는 자바스크립트 프레임워크 중에서 앵귤러 등이 현재 강한 타입을 위해 타입스크립트에 의존한다.

커피스크립트

C 스타일의 구문을 작성하고자 하는 파이썬 프로그래머가 많다면 파이썬의 자유와 간소함을 원하는 자바스크립트 프로그래머도 그에 못지않게 많다. 이런 경우 답은 커피스크립트다. 커피스크립트에서는 현재 토피스크립트(ToffeeScript), 시벳(Civet), 스토리매틱(Storymatic), 커피스크립트 II: 칸의 분노(The Wrath of Khan)를 비롯해 십여 개의 변형이 있다. 이러한 언어는 모두 오른쪽 새끼손가락을 들어 세미콜론 키를 누르는 고된 일을 할 필요가 없게 해준다. 또한 비동기 문법, 메타프로그래밍을 위한 정교한 메커니즘과 같은 멋진 기능도 제공한다. 결과적으로 구두점을 덜 사용하고 적어도 커피스크립트 프로그래머의 관점에서는 훨씬 더 읽기 쉬운, 더 깔끔한 코드가 만들어진다.

핸들바(Handlebars)와 퍼그(Pug)

보통 현대 코드에는 최종적으로 사용자를 위한 메시지가 있는 많은 텍스트 블록이 포함된다. 많은 경우 이러한 블록은 삽입과 맞춤 설정으로 가득 차 있다. 핸들바, 퍼그와 같은 템플릿 시스템은 사람이 읽을 수 있는 이러한 텍스트 블록을 작성하는 속도를 높이는 데 도움이 된다. 문자열을 연결하는 데 필요한 저수준 코드를 작성할 필요 없이 텍스트만 작성하면 모든 부분을 이어 붙이는 작업은 템플릿 시스템이 알아서 해준다.

AWK

이 유닉스 명령줄 툴은 순수 텍스트를 다루는 데 있어 가장 간단하고 강력한 툴이라고 할 수 있다. AWK라는 이름은 3명의 제작자 이름(Alfred V. Aho, Peter J. Weinberger, Brian W. Kernighan)에서 한 글자씩 가져온 것이다. AWK는 코드에서 데이터를 추출, 정렬, 필터링하기 위해 여러 명령을 연결한다. AWK를 사용해서 전체 보고서를 작성할 수 있다. 또한 프로그래머는 주 프로그램이 가져오기 전에 처리 파이프라인에서 원시 데이터를 정리하는 용도로 AWK를 사용할 수도 있다.

베이퍼(Vapour)

R은 많은 부분을 통계학자들이 만든 강력한 언어다. 통계학자들은 일반적으로 컴퓨터 프로그래머보다는 수학자의 관점에서 생각한다. 그 자체가 나쁜 것은 아니지만 프로그래밍 설계 분야에서 이뤄진 유익한 발전이 R에는 적용되지 않아 R의 모든 훌륭한 라이브러리를 사용하는 데 장애물이 될 수 있다. 베이퍼는 R 사용자가 프로그래머, 구체적으로 타입 시스템을 사용해 버그를 잡고 구조를 강제하기를 좋아하는 프로그래머의 관점에서 생각할 수 있게 해주는 전처리기다. 아직 초기 알파 단계이므로 앞으로 새로운 기능이 추가되고 구문이 조정될 수 있다. 목표는 사용자들의 요구에 따라 빠르게 툴이 발전하도록 하는 것이다.

스피핑(Spiffing)

같은 영어 사용자라고 해도, 특히 대륙과 문화권이 다른 경우 언어를 사용하는 방식이 다를 수 있다. 스피핑은 미국식 영어로 작성된 코드를 영국식 영어로 변환해주는 전처리기다. 약간 엉성하지만 문화적 차이를 잇는 능력은 확실히 유용하다. 이 툴이 인기를 얻게 된다면 언젠가 개발자가 이 전처리기를 더 확장해서 직접적인 미국식 표현을 절제된 영국식 스타일로 변환해줄 수도 있을 것이다. 예를 들어 if-then 문 대신 perchance-otherwise 구문을 사용하게 될지도 모른다.

린팅 전처리기

코드를 변환하는 전처리기만 있는 것은 아니다. 일부는 개발자가 지나간 자리를 살피며 놓친 버그를 찾아 주기도 한다. 원래는 유닉스 명령줄 툴인 린트(lint)가 전이되어 이제는 많은 언어 개발 스택의 전처리기에서 린트 기능을 볼 수 있다. 이 같은 린팅 툴, 또는 린터는 서식을 바로잡고 명명 규칙을 적용하고 구문 및 의미 오류를 수정하기도 한다. 일부는 잘못된 로직에서 발생하는 잠재적인 보안 결함을 표시하는 규칙을 적용한다. 인기 있는 버전으로는 루비 코드용 루보캅(RuboCop), 파이썬용 파이린트(Pylint), 자바스크립트(ECMA스크립트)용 ES린트(ESLint)가 있다.

문서화를 위한 전처리기

실행 가능한 코드 외의 다른 것을 생산하는 전처리기도 있다. 스핑크스(Sphinx), Mk독스(MkDocs), 독시젠(Doxygen)과 같은 툴은 파일을 분석하고, 코드에서 주석이 달린 교차 참조 문서 파일 집합을 생성한다. 이러한 툴은 여러 언어에서 작동하지만 거의 모든 언어에는 자체적인 공식 전처리기가 있다. 자바독(Javadoc), 러스트독(Rustdoc), 고독(Godoc), JS독(JSDoc) 등이 많이 사용된다.

통합 데이터 보고를 위한 전처리기

데이터 과학자가 R 언어만 사용하는 것은 아니다. 이들은 R로 생성된 차트, 표, 그래프가 포함된, 사람의 언어로 만들어진 복잡한 데이터 보고서도 작성한다. 데이터 과학자들은 오랜 시간에 걸쳐 R뿐만 아니라 타입세팅 언어인 라텍(LaTex)을 위한 복잡한 전처리기를 만들어왔다. 과학자가 모든 것을 R과 인간 언어로 작성하면 전처리기가 이를 분할해서 계산 명령은 R로, 타입세팅 명령은 라텍으로 보낸다. 또한 R로 생성된 그림이 문서의 적절한 위치에 배치되도록 각 부분을 조정하고, 이후 파일의 인간 언어 부분에서 생성된 최종 PDF 안에 이를 접어 넣는다. 이 모든 작업을 하면서 동시에 페이지 참조와 그림 번호의 일관성도 유지한다.

각자의 장점이 있는 다양한 옵션이 있다. R 마크다운은 일반적인 마크다운의 변형으로, 계산 분석과 데이터 분석을 병합할 수 있다. 또한 파이썬 또는 SQL과 같은 언어의 결과를 병합해서 슬라이드, 문서, 책, 웹사이트를 생성할 수도 있다. 니터(Knitr)와 그 전신인 스위브(Sweave)는 R스튜디오에서 충실히 지원되는 밀접하게 연관된 전처리기다. 파이썬과 라텍을 병합하고자 한다면 P위브(Pweave)도 있다. 언젠가는 이 모두를 하나의 큰 전처리기로 병합하는 메타 버전도 나올 수 있다.

전처리에 AI 사용하기

모든 전처리기에는 얼마간의 구성이 필요하다. AI에 이 부분을 맡기면 되지 않을까? 이미 LLM(대규모 언어 모델)에 전처리기를 업로드해서 잘못된 부분을 수정하도록 요청하는 사람들도 있다. 한 사례를 보자. Agda 컴파일러를 최신 상태로 만들기 위해 다시 작성하려면 100만 달러가 넘게 들 수 있다는 개발자의 말을 들은 회계 담당자는 화가 머리 끝까지 났다. 이때 누군가가 500개가 넘는 코드베이스의 파일을 모두 앤트로픽의 소넷-3.5에 업로드하자는 아이디어를 냈다. 그렇게 하자 실제로 눈깜짝할 사이에 컴파일러가 타입스크립트로 변환됐다. 개발자가 보고한 바에 따르면 대부분의 코드가 자신의 개입 없이 잘 실행됐다고 한다. LLM은 완벽하지는 않지만, 손짓만 하면 기계가 마법처럼 지시에 따라 움직이는 세상을 조금씩 더 현실화하고 있는 것은 사실이다.
editor@itworld.co.kr

Peter Wayner editor@itworld.co.kr
저작권자 한국IDG & ITWorld, 무단 전재 및 재배포 금지