|
개발자라면 누구나 알 것이다. 코드 몇 줄을 쓰고 테스트하고 리포지토리에 체크인한다. 이제 일을 멈추고 휴식을 취할 시간이다. 코드의 장엄함에 대해 돌아보기도 한다. 그리고 최근에 집착하는 프로그래머 신조에 대한 생각으로 돌아간다.
이번 가을부터 프로그래밍 강좌를 처음 수강할 사람이든 앨테어(Altair) 시절부터 비트 뱅잉 코드를 써온 베테랑이든 마찬가지다. 올바름 또는 정확함 등의 일상적인 것들에 대한 이야기에 푹 빠진다. 코드가 사양을 충족하는지에 대해 이야기하는 것은 고객뿐이다.
진짜 아드레날린은 시인처럼 황야를 떠돌면서 코드 작성 기술의 섬세한 부분에 고뇌하고 괴로워하는 데 있다. 변수와 함수를 연결하는 작업은 지루하다. 흐름에 동참하고, 카리스마 넘치는 천재를 따라 줄을 서고, 컴퓨터에 대한 지시의 세세한 부분을 두고 벌이는 격렬한 논쟁에 동참할 때, 삶에서 비로소 살 만한 가치를 느낄 수 있다.
프로그래머들이 도취되기 쉬운 10가지 달콤한 음료수를 소개한다.
마술 같은 공백 가장 격렬한 논쟁 중 하나부터 시작해 보자. 관건은 코드에서 공백의 구조를 어떻게 설계하느냐다. 말 그대로 눈에 보이지도 않고, 많은 경우 코드에 아무런 영향조차 없는 주제에 관한 논쟁이다. 그러나 아무리 쓸데없다 해도 상관없다. 프로그래머들은 코드에서 탭을 사용하느냐 스페이스를 사용하느냐를 두고, 심지어 라인 내에 공백을 포함하는 방법을 두고 몇 시간이고 논쟁을 벌일 수 있기 때문이다.
한 코드 리뷰어가 프로젝트 관리자에게 필자의 코드가 기준에 한참 미달이라서 화면에 코드를 띄우자마자 심각한 결함을 볼 수 있을 정도라고 말했다. 그 “기준”이란 것은 악명 높은 에어비엔비(Airbnb) 스타일 가이드의 19.4번 기준이었다. 이 스타일 가이드는 에어비엔비가 선호하는 자바스크립트 서식을 기술한 문서다. 필자의 실수는 등호의 양쪽 모두에 공백을 넣지 않은 것이었다. (필자는 이 일을 아직도 부끄럽게 생각한다. 공개적인 수치심 고백은 필자의 12단계 계획 중 일부다.) 그 리뷰어는 필자의 스크립트를 너무도 당당하게 “기준 미달”이라고 표현했다. 왜? 누군가가 사뭇 준엄하고 진지한 규칙 목록을 만들었고, 팀은 아무 생각없이 그 규칙을 채택하기로 결정했기 때문이다.
여기서 대부분의 파싱 알고리즘은 공백에 대해 그다지 개의치 않고 스페이스와 탭이 나와도 멈추지 않고 그냥 지나간다는 사실에 너무 집착하지 말자. “공백 지상주의자”라고 불러봤자 그들의 화만 돋울 뿐이다. 대신 순수주의자라고 불러주고 세세한 부분에 대한 이들의 관심을 칭찬하도록 하자. 요즘은 이처럼 세밀한 부분에 관심을 쏟는 경우가 너무 드물다.
중괄호냐, 탭이냐 C언어는 우리에게 여러 놀라운 아이디어를 제공했지만 가장 논란이 되는 점은 중괄호를 사용해서 코드 블록의 처음과 끝을 나타낸다는 것이다. 일부 사람들은 중첩된 블록을 분석하고 중괄호의 각 쌍이 어떻게 구성되어 있는지 쉽게 파악한다. 이들은 중괄호가 줄 번호와 GOTO 문을 사용했던 시절에서 큰 진전을 이뤘음을 이해한다.
그러나 중괄호의 수를 세고 짝짓는 일을 거추장스럽게 여기고 과거의 스파게티 코드에 비해 그다지 진전된 부분도 없다고 생각하는 사람들도 있다. 이들에게는 들여쓰기로 중첩 블록의 시작과 끝을 나타내는 파이썬과 같은 새로운 언어 및 YAML과 같은 데이터 형식이 훨씬 더 마음에 든다. 물론 이들은 중괄호 대신 스페이스와 탭의 수를 열심히 세지만, 어쨌든 그것을 진전이라고 생각한다.
이 혼란을 무심히 건너뛰고, 식 블록은 그냥 식 블록일 뿐이라고 생각할 수도 있지만 그렇게 되면 논란에 끼어들 수 없다. 중괄호와 탭, 두 독약 중 하나를 선택하고, 일단 선택하면 절대 뒤돌아보지 말라.
함수형 프로그래밍 코더는 단순하고 간결한 라인으로 컴퓨터를 위한 명령어를 쓰기를 좋아하며, 이러한 명령을 편의에 따라 필요할 때 내리기를 좋아한다. 문제는 입출력이 명확하게 정의된 블랙박스 구조의 깔끔한 함수로 명령어가 배열되면 분석하고 최적화하기가 훨씬 더 쉽다는 사실을 누군가 발견했다는 것이다. 다른 변수를 증분하거나 어떤 기능을 끄는, 언뜻 뜬금없는 명령어(함수형 프로그래머들이 “부작용”으로 부르는 것)는 문제를 더욱 복잡하게 만든다.
함수형 프로그래밍을 신조로 삼는 이들은 모두가 아무 때나 부작용을 일으키지 않는 깔끔한 함수 구조를 열망해야 한다고 믿는다. 그렇게 하면 버그 없는 고도의 스레드형 코드를 만들기가 훨씬 더 간단해진다고 믿는다.
현재 함수형 접근 방식의 진정한 신도들을 위한 언어는 십여 가지가 있다. 그 중 상당수는 부작용이 코드 작성과 유지를 더 쉽게 해준다는 현실을 인정한다. 스칼라, 프레게와 같은 함수형 언어는 보편적인 자바 가상머신이 지원하는 세계 내에 존재하며, 러스트는 시스템 코드를 작성해야 하는 사람들을 위한 최신 선택지다.
비함수형 프로그래밍 함수형 프로그래밍 추종자 중에서는 추상적인 수학적 주제를 다루는 복잡한 알고리즘, 달리 말하자면 함수형 방식으로 작성하기 가장 쉬운 알고리즘을 작성하는 학계 종사자인 경우가 많다. 나머지 세계는 깔끔하게 중첩된 함수적 추상화라는 사고방식과는 거리가 먼 사람들을 위한 더 복잡한 사용자 인터페이스와 씨름한다.
가장 널리 사용되는 프로그래밍 언어 목록에서 함수형 언어는 극소수다. 가장 큰 이유는 프로그래머들이 보편적인 애플리케이션을 함수형이라는 강박 내에서 구축하는 데 지쳤다는 점이다. 명령형, 선언형, 객체 지향 프로그래밍과 같은 이름의 대안이 등장했다. 이러한 대안은 대항 운동보다는 함수형 신조에 빠져들지 않고 확고부동하게 동참을 거부해온 프로그래머들의 모임에 더 가깝다.
형식 지정 프로그래밍 1세대 언어에서 프로그래머들을 CPU 내의 레지스터를 추적하고 x와 같은 변수 이름으로 데이터를 참조해야 할 필요성에서 해방됐다. 그러자 프로그래머들은 즉시 이 자유를 남용해서, 온갖 종류의 데이터를 온갖 곳에서 변수에 집어넣기 시작했다. 너무 혼란스러워지자 현명한 프로그래밍 언어 설계자들은 프로그래머들에게 초기 변수 선언 다음에 몇 개의 문자만 더 추가할 것을 제안했다. 변수에 집어넣을 데이터의 형식을 명시하는 문자다. 그러면 컴퓨터는 계산을 이중으로 확인하고 최소한 함수에 들어가는 모든 데이터가 올바른 형식을 갖고 있음을 확인할 수 있다.
수학적 사고방식을 가진 일단의 프로그래머들은 계산의 끝에 반환될 단 하나의 진정한 버그 없는 진실로 수렴되는, 우아하고 세련된 형식의 계층 구조를 지향하는 정교한 형식 지정 데이터 이론을 고안했다. 형식 지정 언어 신조는 이 아름다운 이상에 근접하는 프로그램 만들기에 열중한다. 이들은 엄격히 정의된 형식을 원한다. 그러면 컴파일러는 잘못된 형식으로 인한 버그가 없음을 확실히 보장할 수 있게 된다. 형식 비지정 프로그래밍 형식 지정 언어 애호가들이 세력을 형성하자 곧 대항 운동이 일어나면서 데이터 형식 지정 작업은 대부분 시간 낭비라는 선언이 나왔다. 프로그래머들이 문자열과 정수를 추가한다고 해서 프로그램이 실행되는 즉시 예외를 일으키며 다운되지는 않는다. 겨우 몇 분 전에 이 문제에 플래그를 지정한다고 해서 컴파일러에서 많은 시간이 절약되는 것도 아니다.
형식 비지정 지지자들은 정의할 때마다 형식을 지정하는 수고를 할 가치가 없다고 생각한다. 또한 형식 지정은 계산 중에 더 많은 데이터를 사용할 수 있게 됨에 따라 적응하고 개선되는 유연한 데이터 구조 생성을 크게 제약한다.
게다가 프로그래머의 의도를 읽고 적절한 변수 유형을 추론하는 일부 자동화된 컴파일러의 역량이 대폭 향상되는 중이다. 컴퓨터가 알아서 처리할 수 있다면 소소한 그런 일들은 그냥 컴퓨터에 맡기는 편이 낫지 않을까?
로우 코드/노코드 소프트웨어를 쓰는 일은 어렵다. 따라서 프로그래머들이 쓰는 코드의 양을 줄일 수 있는 자동화에 끌리는 것은 당연하다. 이 자동화가 어느정도 높은 수준에 도달하면 개발자는 누구나 아주 적은 코드로, 또는 아예 코드 없이 정밀한 소프트웨어를 만들 수 있다고 호언하기 시작한다.
문제는 숨겨진 추상화와 정교한 데이터 구조에 대해 여전히 프로그래머처럼 생각해야 한다는 것이다. 이 생각을 JSON 파일 또는 XML 등 어떤 방법으로든 코드화해서 명시해야 한다. 자동화 지지자들은 일반적으로 이 작업을 단순한 구성으로 치부하지만, 우리는 공식 프로그래밍 언어로 작성된 명령어를 붙잡고 씨름하는 시간 못지않게 구성 파일과 관련해서도 많은 시간을 소비하곤 한다.
이와 같은 세세한 부분은 별로 중요하지 않다. 프로그래머들은 같은 일을 두 번 하기를 싫어하기 때문에 항상 자동화에 끌린다. 더 중요한 점은 경영진은 항상 자동화가 비용을 줄이고 수익성을 개선해줄 것으로 꿈꾼다는 것이다. 코드를 없앨 방법을 찾아 헤매는 동안 로우 코드 또는 노코드 신조를 지탱하는 힘이 바로 이 꿈이다.
장황한 코드 지난30-40년 동안 프로그래밍 분야의 여러 유명 인사들은 앞으로 개발자들이 아이콘을 클릭하고 플로우차트를 이리저리 드래그하거나 손을 흔들어 기계에 작업을 지시하게 될 것이라고 예언해왔다. 텍스트 파일에 키보드를 직접 두드려 입력하는 방식을 제외한 모든 방법이 거론됐다. 그러나 온갖 예언에도 불구하고, 명령줄과 텍스트 기반 프로그래밍 언어는 좀처럼 사라지지 않는다. 오히려 프로그래머들은 갈수록 직접 입력하기를 더 즐기는 듯하며 심지어 전체 텍스트는 최근 대세다.
프라이버시의 수호자 누구나 프라이버시를 중시하며 프로그래머도 예외는 아니다. 사실 프로그래머는 컴퓨터가 얼마나 프라이버시를 침해할 수 있는지를 잘 안다. 문제는 고객이 원하는 것을 예상하는 정교한 소프트웨어에 의존하는 비즈니스 모델이 많다는 것이다. 물론 사람들에게 직접 물어볼 수도 있지만 대부분의 사람들은 너무 바빠서 설문 따위에 응하지 않는다. 따라서 이러한 비즈니스 모델을 가동하기 위한 유일한 방법은 프라이버시에 대한 우려를 잠시, 이 경우에 한해서만 접어두는 것이다. 일자리와 타인의 프라이버시 중에서 선택하라고 하면 대부분 고민할 여지조차 없다.
흥미로운 절충안도 일부 있으며 경우에 따라서는 프라이버시를 보존하는 방식의 계산이 가능하다. 프라이버시 비슷한 것을 제공하면서 고객의 마음을 읽는 새로운 멋진 기능도 구현할 수 있는 고차원적인 방법도 존재한다.
개방성의 수호자 모두 오픈소스와 개방형 표준이라는 개념을 좋아한다. 경쟁자들의 번창을 허용함으로써 스스로의 비즈니스 모델과 충돌하기 전까지는 그렇다. 오픈소스 소프트웨어의 가장 유력한 기업 중 일부는 동시에 가장 폐쇄적인 비밀 소스를 지키고 있다. 예를 들어 구글은 훌륭한 여러 오픈소스 프로젝트를 후원했고 콘텐츠 제작자에게 수익을 안겨주는 디지털 권한 관리 소프트웨어에 대한 공개적인 반대 캠페인을 벌이기도 했다. 그러나 검색 엔진 순위 알고리즘에 대해 물으면 구글은 선을 긋는다. 거긴 개방되지 않은 영역이다.
구글만이 아니다. 대부분의 기업은 개방성에 대해 유연한 접근 방식을 취한다. 개방성은 다른 사람의 비즈니스 모델에 적용될 때는 항상 좋지만 내 비즈니스 모델에 적용될 때는 그렇지 않다.
다른 무엇보다 중요한 것 지금까지 살펴본 신조는 모두 절대적인 진리처럼 들린다. 열렬한 추종자들은 자신이 믿는 신조가 마치 언제든 천둥을 내리칠 수 있는 분노한 신이 내려준 규율인 듯이 행동하지만, 현실의 프로그래밍 세계는 정의를 제멋대로 늘릴 수 있는 교묘한 트릭으로 가득 차 있다. 적당한 방법만 알면 서로 정 반대로 보이는 두 가지 신조에 동시에 참여하는 것도 가능하다.
예를 들어 일부 함수형 언어는 매우 유연해서 필요에 따라 비함수적 트릭을 사용할 수 있다. C와 같은 저명한 비트 뱅잉 툴도 궁극적으로는 함수형 프로그래밍 언어다. 형식을 싫어하는 사람들 일부는 모든 함수가 형식 계층 구조에서 가장 포괄적인 개체를 취하도록 정의하는 단순한 방법으로 형식 확인 언어의 기반을 약화시킨다.
각각의 요소가 아무리 상충하는 것처럼 보이든 자기만의 조합으로 다양한 원칙을 섞어 직접 신조를 만들지 못할 이유도 없다. 코드를 쓰는 사람, 명령을 내리는 사람은 결국 자기 자신이다. editor@itworld.co.kr
원문보기:
http://www.itworld.co.kr/news/132883?page=0,1#csidx67066f26f2bfd59ac912c5d237b36d5
|
