2019.10.04

"개발자라면 누구나" 한번쯤 빠져 보는 10가지 소프트웨어 '종파'

Peter Wayner | InfoWorld
개발자라면 누구나 알 것이다. 코드 몇 줄을 쓰고 테스트하고 리포지토리에 체크인한다. 이제 일을 멈추고 휴식을 취할 시간이다. 코드의 장엄함에 대해 돌아보기도 한다. 그리고 최근에 집착하는 프로그래머 신조에 대한 생각으로 돌아간다.
 
이번 가을부터 프로그래밍 강좌를 처음 수강할 사람이든 앨테어(Altair) 시절부터 비트 뱅잉 코드를 써온 베테랑이든 마찬가지다. 올바름 또는 정확함 등의 일상적인 것들에 대한 이야기에 푹 빠진다. 코드가 사양을 충족하는지에 대해 이야기하는 것은 고객뿐이다.

진짜 아드레날린은 시인처럼 황야를 떠돌면서 코드 작성 기술의 섬세한 부분에 고뇌하고 괴로워하는 데 있다. 변수와 함수를 연결하는 작업은 지루하다. 흐름에 동참하고, 카리스마 넘치는 천재를 따라 줄을 서고, 컴퓨터에 대한 지시의 세세한 부분을 두고 벌이는 격렬한 논쟁에 동참할 때, 삶에서 비로소 살 만한 가치를 느낄 수 있다.
 
프로그래머들이 도취되기 쉬운 10가지 달콤한 음료수를 소개한다.
 

마술 같은 공백

가장 격렬한 논쟁 중 하나부터 시작해 보자. 관건은 코드에서 공백의 구조를 어떻게 설계하느냐다. 말 그대로 눈에 보이지도 않고, 많은 경우 코드에 아무런 영향조차 없는 주제에 관한 논쟁이다. 그러나 아무리 쓸데없다 해도 상관없다. 프로그래머들은 코드에서 탭을 사용하느냐 스페이스를 사용하느냐를 두고, 심지어 라인 내에 공백을 포함하는 방법을 두고 몇 시간이고 논쟁을 벌일 수 있기 때문이다.
 
한 코드 리뷰어가 프로젝트 관리자에게 필자의 코드가 기준에 한참 미달이라서 화면에 코드를 띄우자마자 심각한 결함을 볼 수 있을 정도라고 말했다. 그 “기준”이란 것은 악명 높은 에어비엔비(Airbnb) 스타일 가이드의 19.4번 기준이었다. 이 스타일 가이드는 에어비엔비가 선호하는 자바스크립트 서식을 기술한 문서다. 필자의 실수는 등호의 양쪽 모두에 공백을 넣지 않은 것이었다. (필자는 이 일을 아직도 부끄럽게 생각한다. 공개적인 수치심 고백은 필자의 12단계 계획 중 일부다.) 그 리뷰어는 필자의 스크립트를 너무도 당당하게 “기준 미달”이라고 표현했다. 왜? 누군가가 사뭇 준엄하고 진지한 규칙 목록을 만들었고, 팀은 아무 생각없이 그 규칙을 채택하기로 결정했기 때문이다.
 
여기서 대부분의 파싱 알고리즘은 공백에 대해 그다지 개의치 않고 스페이스와 탭이 나와도 멈추지 않고 그냥 지나간다는 사실에 너무 집착하지 말자. “공백 지상주의자”라고 불러봤자 그들의 화만 돋울 뿐이다. 대신 순수주의자라고 불러주고 세세한 부분에 대한 이들의 관심을 칭찬하도록 하자. 요즘은 이처럼 세밀한 부분에 관심을 쏟는 경우가 너무 드물다.
 

중괄호냐, 탭이냐

C언어는 우리에게 여러 놀라운 아이디어를 제공했지만 가장 논란이 되는 점은 중괄호를 사용해서 코드 블록의 처음과 끝을 나타낸다는 것이다. 일부 사람들은 중첩된 블록을 분석하고 중괄호의 각 쌍이 어떻게 구성되어 있는지 쉽게 파악한다. 이들은 중괄호가 줄 번호와 GOTO 문을 사용했던 시절에서 큰 진전을 이뤘음을 이해한다.
 
그러나 중괄호의 수를 세고 짝짓는 일을 거추장스럽게 여기고 과거의 스파게티 코드에 비해 그다지 진전된 부분도 없다고 생각하는 사람들도 있다. 이들에게는 들여쓰기로 중첩 블록의 시작과 끝을 나타내는 파이썬과 같은 새로운 언어 및 YAML과 같은 데이터 형식이 훨씬 더 마음에 든다. 물론 이들은 중괄호 대신 스페이스와 탭의 수를 열심히 세지만, 어쨌든 그것을 진전이라고 생각한다.
 
이 혼란을 무심히 건너뛰고, 식 블록은 그냥 식 블록일 뿐이라고 생각할 수도 있지만 그렇게 되면 논란에 끼어들 수 없다. 중괄호와 탭, 두 독약 중 하나를 선택하고, 일단 선택하면 절대 뒤돌아보지 말라.
 

함수형 프로그래밍

코더는 단순하고 간결한 라인으로 컴퓨터를 위한 명령어를 쓰기를 좋아하며, 이러한 명령을 편의에 따라 필요할 때 내리기를 좋아한다. 문제는 입출력이 명확하게 정의된 블랙박스 구조의 깔끔한 함수로 명령어가 배열되면 분석하고 최적화하기가 훨씬 더 쉽다는 사실을 누군가 발견했다는 것이다. 다른 변수를 증분하거나 어떤 기능을 끄는, 언뜻 뜬금없는 명령어(함수형 프로그래머들이 “부작용”으로 부르는 것)는 문제를 더욱 복잡하게 만든다.
 
함수형 프로그래밍을 신조로 삼는 이들은 모두가 아무 때나 부작용을 일으키지 않는 깔끔한 함수 구조를 열망해야 한다고 믿는다. 그렇게 하면 버그 없는 고도의 스레드형 코드를 만들기가 훨씬 더 간단해진다고 믿는다.
 
현재 함수형 접근 방식의 진정한 신도들을 위한 언어는 십여 가지가 있다. 그 중 상당수는 부작용이 코드 작성과 유지를 더 쉽게 해준다는 현실을 인정한다. 스칼라, 프레게와 같은 함수형 언어는 보편적인 자바 가상머신이 지원하는 세계 내에 존재하며, 러스트는 시스템 코드를 작성해야 하는 사람들을 위한 최신 선택지다.
 

비함수형 프로그래밍

함수형 프로그래밍 추종자 중에서는 추상적인 수학적 주제를 다루는 복잡한 알고리즘, 달리 말하자면 함수형 방식으로 작성하기 가장 쉬운 알고리즘을 작성하는 학계 종사자인 경우가 많다. 나머지 세계는 깔끔하게 중첩된 함수적 추상화라는 사고방식과는 거리가 먼 사람들을 위한 더 복잡한 사용자 인터페이스와 씨름한다.
 
가장 널리 사용되는 프로그래밍 언어 목록에서 함수형 언어는 극소수다. 가장 큰 이유는 프로그래머들이 보편적인 애플리케이션을 함수형이라는 강박 내에서 구축하는 데 지쳤다는 점이다. 명령형, 선언형, 객체 지향 프로그래밍과 같은 이름의 대안이 등장했다. 이러한 대안은 대항 운동보다는 함수형 신조에 빠져들지 않고 확고부동하게 동참을 거부해온 프로그래머들의 모임에 더 가깝다.
 

형식 지정 프로그래밍

1세대 언어에서 프로그래머들을 CPU 내의 레지스터를 추적하고 x와 같은 변수 이름으로 데이터를 참조해야 할 필요성에서 해방됐다. 그러자 프로그래머들은 즉시 이 자유를 남용해서, 온갖 종류의 데이터를 온갖 곳에서 변수에 집어넣기 시작했다. 너무 혼란스러워지자 현명한 프로그래밍 언어 설계자들은 프로그래머들에게 초기 변수 선언 다음에 몇 개의 문자만 더 추가할 것을 제안했다. 변수에 집어넣을 데이터의 형식을 명시하는 문자다. 그러면 컴퓨터는 계산을 이중으로 확인하고 최소한 함수에 들어가는 모든 데이터가 올바른 형식을 갖고 있음을 확인할 수 있다.
 
수학적 사고방식을 가진 일단의 프로그래머들은 계산의 끝에 반환될 단 하나의 진정한 버그 없는 진실로 수렴되는, 우아하고 세련된 형식의 계층 구조를 지향하는 정교한 형식 지정 데이터 이론을 고안했다. 형식 지정 언어 신조는 이 아름다운 이상에 근접하는 프로그램 만들기에 열중한다. 이들은 엄격히 정의된 형식을 원한다. 그러면 컴파일러는 잘못된 형식으로 인한 버그가 없음을 확실히 보장할 수 있게 된다.
 



2019.10.04

"개발자라면 누구나" 한번쯤 빠져 보는 10가지 소프트웨어 '종파'

Peter Wayner | InfoWorld
개발자라면 누구나 알 것이다. 코드 몇 줄을 쓰고 테스트하고 리포지토리에 체크인한다. 이제 일을 멈추고 휴식을 취할 시간이다. 코드의 장엄함에 대해 돌아보기도 한다. 그리고 최근에 집착하는 프로그래머 신조에 대한 생각으로 돌아간다.
 
이번 가을부터 프로그래밍 강좌를 처음 수강할 사람이든 앨테어(Altair) 시절부터 비트 뱅잉 코드를 써온 베테랑이든 마찬가지다. 올바름 또는 정확함 등의 일상적인 것들에 대한 이야기에 푹 빠진다. 코드가 사양을 충족하는지에 대해 이야기하는 것은 고객뿐이다.

진짜 아드레날린은 시인처럼 황야를 떠돌면서 코드 작성 기술의 섬세한 부분에 고뇌하고 괴로워하는 데 있다. 변수와 함수를 연결하는 작업은 지루하다. 흐름에 동참하고, 카리스마 넘치는 천재를 따라 줄을 서고, 컴퓨터에 대한 지시의 세세한 부분을 두고 벌이는 격렬한 논쟁에 동참할 때, 삶에서 비로소 살 만한 가치를 느낄 수 있다.
 
프로그래머들이 도취되기 쉬운 10가지 달콤한 음료수를 소개한다.
 

마술 같은 공백

가장 격렬한 논쟁 중 하나부터 시작해 보자. 관건은 코드에서 공백의 구조를 어떻게 설계하느냐다. 말 그대로 눈에 보이지도 않고, 많은 경우 코드에 아무런 영향조차 없는 주제에 관한 논쟁이다. 그러나 아무리 쓸데없다 해도 상관없다. 프로그래머들은 코드에서 탭을 사용하느냐 스페이스를 사용하느냐를 두고, 심지어 라인 내에 공백을 포함하는 방법을 두고 몇 시간이고 논쟁을 벌일 수 있기 때문이다.
 
한 코드 리뷰어가 프로젝트 관리자에게 필자의 코드가 기준에 한참 미달이라서 화면에 코드를 띄우자마자 심각한 결함을 볼 수 있을 정도라고 말했다. 그 “기준”이란 것은 악명 높은 에어비엔비(Airbnb) 스타일 가이드의 19.4번 기준이었다. 이 스타일 가이드는 에어비엔비가 선호하는 자바스크립트 서식을 기술한 문서다. 필자의 실수는 등호의 양쪽 모두에 공백을 넣지 않은 것이었다. (필자는 이 일을 아직도 부끄럽게 생각한다. 공개적인 수치심 고백은 필자의 12단계 계획 중 일부다.) 그 리뷰어는 필자의 스크립트를 너무도 당당하게 “기준 미달”이라고 표현했다. 왜? 누군가가 사뭇 준엄하고 진지한 규칙 목록을 만들었고, 팀은 아무 생각없이 그 규칙을 채택하기로 결정했기 때문이다.
 
여기서 대부분의 파싱 알고리즘은 공백에 대해 그다지 개의치 않고 스페이스와 탭이 나와도 멈추지 않고 그냥 지나간다는 사실에 너무 집착하지 말자. “공백 지상주의자”라고 불러봤자 그들의 화만 돋울 뿐이다. 대신 순수주의자라고 불러주고 세세한 부분에 대한 이들의 관심을 칭찬하도록 하자. 요즘은 이처럼 세밀한 부분에 관심을 쏟는 경우가 너무 드물다.
 

중괄호냐, 탭이냐

C언어는 우리에게 여러 놀라운 아이디어를 제공했지만 가장 논란이 되는 점은 중괄호를 사용해서 코드 블록의 처음과 끝을 나타낸다는 것이다. 일부 사람들은 중첩된 블록을 분석하고 중괄호의 각 쌍이 어떻게 구성되어 있는지 쉽게 파악한다. 이들은 중괄호가 줄 번호와 GOTO 문을 사용했던 시절에서 큰 진전을 이뤘음을 이해한다.
 
그러나 중괄호의 수를 세고 짝짓는 일을 거추장스럽게 여기고 과거의 스파게티 코드에 비해 그다지 진전된 부분도 없다고 생각하는 사람들도 있다. 이들에게는 들여쓰기로 중첩 블록의 시작과 끝을 나타내는 파이썬과 같은 새로운 언어 및 YAML과 같은 데이터 형식이 훨씬 더 마음에 든다. 물론 이들은 중괄호 대신 스페이스와 탭의 수를 열심히 세지만, 어쨌든 그것을 진전이라고 생각한다.
 
이 혼란을 무심히 건너뛰고, 식 블록은 그냥 식 블록일 뿐이라고 생각할 수도 있지만 그렇게 되면 논란에 끼어들 수 없다. 중괄호와 탭, 두 독약 중 하나를 선택하고, 일단 선택하면 절대 뒤돌아보지 말라.
 

함수형 프로그래밍

코더는 단순하고 간결한 라인으로 컴퓨터를 위한 명령어를 쓰기를 좋아하며, 이러한 명령을 편의에 따라 필요할 때 내리기를 좋아한다. 문제는 입출력이 명확하게 정의된 블랙박스 구조의 깔끔한 함수로 명령어가 배열되면 분석하고 최적화하기가 훨씬 더 쉽다는 사실을 누군가 발견했다는 것이다. 다른 변수를 증분하거나 어떤 기능을 끄는, 언뜻 뜬금없는 명령어(함수형 프로그래머들이 “부작용”으로 부르는 것)는 문제를 더욱 복잡하게 만든다.
 
함수형 프로그래밍을 신조로 삼는 이들은 모두가 아무 때나 부작용을 일으키지 않는 깔끔한 함수 구조를 열망해야 한다고 믿는다. 그렇게 하면 버그 없는 고도의 스레드형 코드를 만들기가 훨씬 더 간단해진다고 믿는다.
 
현재 함수형 접근 방식의 진정한 신도들을 위한 언어는 십여 가지가 있다. 그 중 상당수는 부작용이 코드 작성과 유지를 더 쉽게 해준다는 현실을 인정한다. 스칼라, 프레게와 같은 함수형 언어는 보편적인 자바 가상머신이 지원하는 세계 내에 존재하며, 러스트는 시스템 코드를 작성해야 하는 사람들을 위한 최신 선택지다.
 

비함수형 프로그래밍

함수형 프로그래밍 추종자 중에서는 추상적인 수학적 주제를 다루는 복잡한 알고리즘, 달리 말하자면 함수형 방식으로 작성하기 가장 쉬운 알고리즘을 작성하는 학계 종사자인 경우가 많다. 나머지 세계는 깔끔하게 중첩된 함수적 추상화라는 사고방식과는 거리가 먼 사람들을 위한 더 복잡한 사용자 인터페이스와 씨름한다.
 
가장 널리 사용되는 프로그래밍 언어 목록에서 함수형 언어는 극소수다. 가장 큰 이유는 프로그래머들이 보편적인 애플리케이션을 함수형이라는 강박 내에서 구축하는 데 지쳤다는 점이다. 명령형, 선언형, 객체 지향 프로그래밍과 같은 이름의 대안이 등장했다. 이러한 대안은 대항 운동보다는 함수형 신조에 빠져들지 않고 확고부동하게 동참을 거부해온 프로그래머들의 모임에 더 가깝다.
 

형식 지정 프로그래밍

1세대 언어에서 프로그래머들을 CPU 내의 레지스터를 추적하고 x와 같은 변수 이름으로 데이터를 참조해야 할 필요성에서 해방됐다. 그러자 프로그래머들은 즉시 이 자유를 남용해서, 온갖 종류의 데이터를 온갖 곳에서 변수에 집어넣기 시작했다. 너무 혼란스러워지자 현명한 프로그래밍 언어 설계자들은 프로그래머들에게 초기 변수 선언 다음에 몇 개의 문자만 더 추가할 것을 제안했다. 변수에 집어넣을 데이터의 형식을 명시하는 문자다. 그러면 컴퓨터는 계산을 이중으로 확인하고 최소한 함수에 들어가는 모든 데이터가 올바른 형식을 갖고 있음을 확인할 수 있다.
 
수학적 사고방식을 가진 일단의 프로그래머들은 계산의 끝에 반환될 단 하나의 진정한 버그 없는 진실로 수렴되는, 우아하고 세련된 형식의 계층 구조를 지향하는 정교한 형식 지정 데이터 이론을 고안했다. 형식 지정 언어 신조는 이 아름다운 이상에 근접하는 프로그램 만들기에 열중한다. 이들은 엄격히 정의된 형식을 원한다. 그러면 컴파일러는 잘못된 형식으로 인한 버그가 없음을 확실히 보장할 수 있게 된다.
 



X