loading...

개발자들이 선호하는 전처리기 14

이 글은 IDG의 아티클을 전재하여 제공합니다.
[원문보기]

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

20241209_1 image Credit: Sivivolk/Shutterstock

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

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

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

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

1. LESS와 SASS

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

2. 업서드JS(AbsurdJS)

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

3. 바이썬(Bython)

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

4. 파이프리프로세서(Pypreprocessor)

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

5. 타입스크립트(TypeScript)

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

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

6. 커피스크립트(CoffeeScript)

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

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

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

8. AWK

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

9. 베이퍼(Vapour)

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

10. 스피핑(Spiffing)

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

11. 린팅 전처리기(Linting preprocessors)

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

12. 문서화를 위한 전처리

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

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

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

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

14. AI 기반의 전처리

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

IDG logo

▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.


이 글이 좋으셨다면 구독&좋아요

여러분의 “구독”과 “좋아요”는
저자에게 큰 힘이 됩니다.

subscribe

구독하기

subscribe

Peter Wayner
Peter Wayner
CIO

CIO의 Contributing Writer

공유하기