박연오

클로저 코드는 정말 읽기 어려운가?

2022-06-17T12:00:00+09:00

프로그래머를 위한 이름 짓는 원리

2021-09-24T12:00:00+09:00

장고 ORM으로 역방향 참조 외래 키 찾기

2020-11-29T12:00:00+09:00

(번역) PWA 시대의 캐시 전략

2020-09-23T12:00:00+09:00

(번역) 서버에서 클라이언트로

2020-06-22T12:00:00+09:00

리눅스에서 씽크패드 X1 카본 6세대 언더볼팅하기 (throttled)

2020-04-27T21:00:00+09:00

throttled
sysbench 성능 테스트
- sysbench 설치
- sysbench 실행
적절한 전압 조정치 찾기
- 중요한 팁
- 조정치 찾는 순서
결과

언더볼팅(CPU에 걸리는 전압을 낮추기)을 하면 CPU의 발열과 전력소모를 줄일 수 있다. 배터리 모드에서는 배터리 사용 시간을 늘릴 수 있고, 외부 전원을 사용할 때는 발열 감소로 쓰로틀링에 도달하는 시간을 늦춰 성능 향상을 노릴 수 있다. 하지만 전압을 과도하게 낮추면 CPU가 올바르게 동작하지 못해 시스템이 다운된다. 주의가 필요하긴 하지만 적절히 활용하면 노트북을 효율적으로 사용할 수 있다.

언더볼팅 설명: https://en.wikipedia.org/wiki/Dynamic_voltage_scaling

throttled는 리눅스에서 언더볼팅을 할 수 있게 해주는 프로그램이다. 윈도우의 ThrottleStop 프로그램과 비슷하다. throttled는 원래 씽크패드 노트북의 리눅스 환경에서 쓰로틀링이 과다하게 걸리는 문제를 해결하기 위해 만든 것이라고 한다. 외부 전원 사용시의 CPU 온도가 80°C 미만일 때 쓰로틀링이 걸려서 성능을 제대로 내지 못하는 문제(관련 내용)가 있다. 그러므로 언더볼팅을 하지 않더라도 사용을 고려해볼만하다.

나는 이 프로그램을 이용해 씽크패드 X1 카본 6세대 노트북 + 만자로 리눅스(아크 리눅스 변종)에서 언더볼팅을 해봤다.

throttled

throttled 설치

아크 리눅스에서는 그냥 throttled 를 설치하면 된다.

sudo pacman -S --needed throttled

다른 배포판의 설치법은 throttled 깃허브 문서에서 확인하기 바란다.

throttled 설정

데몬을 실행하기 전에 설정 파일을 확인해보자. /etc/lenovo_fix.conf 파일을 열어보면 된다. 이 파일의 모든 항목은 위험할 수 있으니 문서를 자세히 읽어보고 수정해야 한다. 다음은 언더볼팅과 관련된 설정 항목만 꼽은 것이다.

[GENERAL]
Enabled: True    # 스크립트 사용 여부

[BATTERY]
Trip_Temp_C: 85  # 배터리 사용시 쓰로틀링 전까지 허용할 온도

[AC]
Trip_Temp_C: 95  # 외부 전원 사용시 쓰로틀링 전까지 허용할 온도

[UNDERVOLT.BATTERY]
CORE: 0          # 배터리 사용시 CPU 코어 전압 조정치
GPU: 0           # 배터리 사용시 내장 GPU 전압 조정치
CACHE: 0         # 배터리 사용시 CPU 캐시 전압 조정치
UNCORE: 0        # 배터리 사용시 시스템 에이전트 전압 조정치
ANALOGIO: 0      # 배터리 사용시 아날로그 입출력 전압 조정치

[UNDERVOLT.AC]
CORE: 0          # 외부 전원 사용시 CPU 코어 전압 조정치
GPU: 0           # 외부 전원 사용시 내장 GPU 전압 조정치
CACHE: 0         # 외부 전원 사용시 CPU 캐시 전압 조정치
UNCORE: 0        # 외부 전원 사용시 시스템 에이전트 전압 조정치
ANALOGIO: 0      # 외부 전원 사용시 아날로그 입출력 전압 조정치

전압 조정은 언더볼팅만 허용하기 때문에 음수로 입력해야 한다. (예: CORE: -50) 적절한 언더볼팅 값은 테스트하면서 찾아야 하기 때문에 처음에는 설정치를 수정하지 않은 상태에서 throttled를 켜보자.

throttled 사용

systemd를 이용해 throttled 데몬을 실행할 수 있다. 서비스 이름은 lenovo_fix다. 아래 명령으로 enabled 설정을 해 두면 부팅 때마다 자동으로 실행되며 언더볼팅 설정도 적용된다.

sudo systemctl enable lenovo_fix.service

이대로는 다음 부팅 때야 실행되므로, 지금 바로 사용해 보려면 start 명령으로 실행한다.

sudo systemctl start lenovo_fix.service

설정을 수정한 경우에는 throttled 서비스를 재시작한다.

sudo systemctl restart lenovo_fix.service

sysbench 성능 테스트

sysbench 프로그램을 이용하면 시스템에 부하를 걸고 시간당 작업량을 확인할 수 있다. (시스템에 부하만 걸고 다른 방법으로 모니터링 하려면 stress 같은 프로그램을 이용해도 된다.)

sysbench 설치

sudo pacman -S --needed sysbench

sysbench 실행

sysbench cpu --threads=8 --time=120 run

--threads는 CPU의 쓰레드 개수만큼 지정하고, --time은 120초 이상으로 설정해 준다. 위 명령을 실행하면 120초 동안 테스트를 진행하고 다음과 같이 결과를 낸다.

sysbench 1.0.18 (using system LuaJIT 2.0.5)

Running the test with following options:
Number of threads: 8
Initializing random number generator from current time


Prime numbers limit: 10000

Initializing worker threads...

Threads started!

CPU speed:
    events per second:  7785.85

General statistics:
    total time:                          120.0008s
    total number of events:              934320

Latency (ms):
         min:                                    0.92
         avg:                                    1.03
         max:                                   16.15
         95th percentile:                        1.03
         sum:                               959858.55

Threads fairness:
    events (avg/stddev):           116790.0000/74.80
    execution time (avg/stddev):   119.9823/0.00

결과에서 General statistics total number of events 를 확인하면 작업 시간동안 수행한 작업 총량을 확인할 수 있다.

테스트 시간이 너무 짧으면 발열에 따른 성능 저하가 반영되지 않으므로 테스트 시간을 2분 이상으로 설정하는 것이 좋다. 또, 열이 쌓인 상태에서 테스트를 하면 측정치가 정확하지 않을 수 있으므로 테스트를 여러 번 할 때는 열이 완전히 식은 상태에서 시작할 수 있도록 테스트마다 5분 정도씩 간격을 두는 것이 좋다.

적절한 전압 조정치 찾기

이제 조정치를 적절히 수정하고 테스트를 반복하면서 시스템에 맞는 조정치를 찾으면 된다. 윈도우에서 ThrottleStop으로 하는 것과 크게 다르지 않다.

중요한 팁

외부 전원을 연결한 채로 언더볼팅을 한다. 처음에는 외부 전원을 연결했을 때의 전압 조정치만 수정한다. 조정치가 과도하면 시스템이 멈춘 뒤 부팅이 안 될 수 있다. 이 때는 전원을 빼고 배터리로 부팅한다. 배터리 모드의 전압을 조정하지 않았으므로 부팅이 될 것이다.

시스템 에이전트(UNCORE)와 아날로그 입출력(ANALOGIO)의 조정치는 수정할 필요가 없다. 리스크에 비해 얻는 것이 별로 없다.

조정치 찾는 순서

/etc/lenovo_fix.conf 파일에서 CORE, GPU, CACHE의 조정치를 -10 낮춘다.
throttled를 재시작한다. (sudo systemctl restart lenovo_fix.service)
sysbench로 2분 이상 스트레스 테스트를 해본다.
A) sysbench가 성공했으면 점수를 기록하고, 1로 가서 조정치를 더 낮춰 본다.
B) 시스템에 이상이 발생했으면 배터리 모드로 컴퓨터를 껐다 켜고, 마지막에 성공한 조정치를 사용한다. 마지막에 성공한 것보다 조금 더 안전한 조정치를 사용하는 것도 좋다.

적절한 조정치를 찾았으면 /etc/lenovo_fix.conf 파일에 기록해두고 외부 전원을 뽑은 채로 배터리용 조정치도 같은 방법으로 찾으면 된다.

결과

다음은 내가 씽크패드 X1 카본 6세대(Intel Core i5-8250U)를 언더볼팅한 결과다.

POWER	CORE	GPU	CACHE	SCORE
AC	0	0	0	901211
AC	-80	-80	-80	931802
AC	-110	-110	-110	935153
AC	-115	-115	-115	935268
AC	-120	-120	-120	934320
AC	-125	-125	-125	(dead)
BATTERY	0	0	0	659796
BATTERY	-110	-110	-110	659691

-120 mV 에서는 화면이 이상해지는 문제가 생겼고, -125 mV에서는 시스템이 멈췄다. -110 mV 정도가 적당한 것 같다. 조정을 하지 않았을 때에 비해 성능이 3% 가량 향상되었다.

배터리 모드에서는 쓰로틀링이 걸리기 때문에 -110 mV로 조정하더라도 점수의 향상은 없었다. 하지만 같은 연산을 하는 데 드는 발열이 덜한 만큼 배터리 소모가 덜해질 것이라고 기대해 본다. 아쉽게도 이 경우의 온도와 전력 소모를 정확하게 측정할 방법을 찾지 못했다.

언더볼팅을 마치고, 시스템 안정성과 배터리 사용 시간을 고려해 쓰로틀링 진입 제한 온도를 전원: 92°C, 배터리: 69°C로 설정해 두었다.

날짜 구간에 값을 매핑하는 방법 (그리고 RangeKeyDict)

2019-12-16T12:00:00+09:00

[책소개] 『파이썬으로 데이터 주무르기』

2018-03-28T11:00:00+09:00

데이터 분석 과정을 보여주는 책
- 실습하고 응용하며 배우기

페이스북 그룹 ‘Python Korea’에 데이터 분석 학습 모임 광고가 뜬 걸 보고 참가 신청했다. ‘데이터 분석 스터디’라는 페이스북 그룹의 모임이다. 지원자들이 스무 명 가까이 줄을 설 만큼 인기가 많았다. 나도 친구들과 함께 참가하고 싶었지만 모임에 빈 자리가 없어 혼자만 끼게 됐다. 이 모임에서 『파이썬으로 데이터 주무르기』를 교재로 학습했다.

데이터 분석 과정을 보여주는 책

좋은 스토리를 쓰려면 설명하지 말고 보여주라고 했다. 저자가 그 격언에 따른 것인지, 이 책에는 설명이 별로 없는 대신 흥미진진한 예제로 가득하다. ‘저렴한 주유소 찾는 법’처럼 가벼운 일상 프로젝트부터 ‘인구 소멸 지역 분석’처럼 연구 주제로 다뤄볼만한 프로젝트까지, 데이터 분석가가 실제로 할 법한 중규모 프로젝트들을 보여준다.

데이터 분석 전체 과정을 다루는만큼 소개하는 내용이 적지 않다. 수작업과 크롤링으로 데이터를 수집하는 과정, 수집한 데이터를 정리정돈하는 과정, 데이터의 특징을 요모조모 살펴보고 조작해보는 과정, 플롯팅·매핑 등 여러 가지 시각화해보는 과정 등이 소개된다. 실습에 쓰이는 도구도 많아서, 파이썬, 팬더스(Pandas), 넘파이(NumPy), 폴리엄(Folium), 뷰티플 솝(Beautiful Soup), 셀레늄(Selenium), 구글 맵스, KoNLPy 등 여러 도구가 쉴새 없이 등장한다. 분량이 다소 많을 수 있으나, 진행 과정이 처음부터 끝까지 차례차례 나오므로 조금 노력하면 대부분의 사람들이 따라할 수 있을 것 같다.

데이터 분석에 필요한 지식과 도구를 모두 익힌 뒤에 일을 하고자 한다면 엄두를 내기 어려울 것이다. 저자는 독자들이 세부 사항을 스스로 학습할 것이라고 믿고, 독자들이 데이터 분석 실무 과정을 체험하도록 하는 데 집중한다. 덕분에 입문자들이 전체 그림을 파악하기에 좋은 책이 된 것 같다. 데이터 분석을 시작해볼까 고민하는 분들, 어떻게 시작해야 할지 알고 싶은 분들이 보기 좋다. 나도 이 책을 학습하고는 팬더스와 통계학을 좀 더 공부해보고 싶은 마음이 생겼다. 함께 학습한 스터디 그룹에서도 다음에 학습할 책으로 『파이썬 라이브러리를 활용한 데이터 분석』이 선정되었다.

실습하고 응용하며 배우기

1장부터 6장까지 책 내용에 따라 실습을 해 봤다. 설명이 많지 않아 스스로 고민하고 찾아 봐야 하는 부분도 적지 않지만, 전체적으로는 무난하게 실습이 가능했다. 7장과 8장은 읽어보기만 하고 실습은 생략했다.

내가 진행한 실습 코드: https://github.com/bakyeono/study-python-ds

데이터 분석을 파이썬으로만 하란 법은 없으니 책 내용을 응용해서 R, 클로저(Clojure), 자바스크립트 등 다른 언어로 해 보는 것도 재미있을 것 같다.

미식가 친구 김동욱 씨가 “더본코리아 프랜차이즈 기업의 음식점들을 안내하는 지도가 필요하다”고 얘기하곤 했는데, 책에 나온 내용을 응용해 볼 겸 하여 지도에 매장을 표시해 봤다. 음식점 정보는 더본코리아 웹사이트에서 구할 수 있고, 파이썬 스크립트를 작성해 수집했다. 지도에 표시하는 것은 리플릿(Leaflet) 라이브러리로 했다. 폴리엄도 이 라이브러리를 쓴다.

책을 눈으로만 보기보다는 이렇게 실습해보고, 응용도 해보는 편이 학습 효율이 좋다.

자바스크립트, 세미콜론을 써야 하나 말아야 하나

2018-01-19T02:29:00+09:00

요약
문장 부호와 문장의 끝
- 세미콜론의 필요성
- 세미콜론은 꼭 필요한가?
자바스크립트에서의 세미콜론
결론
참고
P.S.

자바스크립트에서는 문장의 끝에 세미콜론을 써도 되고 안 써도 된다. 물론, 한 코드 안에서는 세미콜론을 쓰거나 안 쓰거나 한 방식으로 통일하는 것이 바람직하다. 그렇다면, 어느 쪽으로 통일해야 할까?

요약

자바스크립트에서는 세미콜론을 굳이 넣지 않아도 된다. 나는 앞으로는 세미콜론을 생략하는 스타일로 코드를 작성할 생각이다. 이것이 과감한 주장이나 허튼 소리처럼 느껴진다면, 계속 읽어봐 주시길.

문장 부호와 문장의 끝

세미콜론의 필요성

C 계열 언어에서는 문장의 끝을 나타내기 위해 세미콜론을 사용한다. 이 방식의 장점은 코드의 스타일을 프로그래머가 좀 더 자유롭게 구사할 수 있다는 것이다. 예를 들어, 다음과 같이 C 코드를 작성해도 문법적으로 문제가 없다.

C 코드:

int       i =
1; double j =
2.0;

세미콜론은 국어 문법에서 마침표와 같은 기능을 한다. 한국어로 치면 다음과 비슷한 양식으로 글을 쓴 셈이다.

한국어 글:

밥을
먹었다. 똥을
쌌다.

개행이 제멋대로 된 탓에 둘 다 똥같은 코드와 글이지만, 우리는 이것들이 각각 세 개씩의 문장이 아니라 두 개씩의 문장으로 이루어졌다는 것을 알 수 있다. 세미콜론과 마침표라는 문장 부호 덕분에 말이다.

세미콜론은 꼭 필요한가?

그런데 위의 예를 보면 알겠지만, 코드 작성 스타일이 자유로워진다는 장점은 곧, 나쁜 스타일이 허용된다는 단점도 동시에 의미한다. 그래서 C 계열 언어의 여러 스타일 가이드에서는 예외적인 경우를 제외하고는 한 행에 하나의 문장만을 작성하도록 하는 권고를 하고 있다. 그런 권고를 따른다면 위의 코드와 글은 다음과 같이 수정해야 한다.

C 코드:

int    i = 1;
double j = 2.0;

한국어 글:

밥을 먹었다.
똥을 쌌다.

이렇게 행 하나에 문장 하나씩이 되도록 정리하면, 코드가 더 정돈되어 보이고 구조 파악이 쉽고 혼란도 덜하다. 그런데 정리하고 보니, 굳이 마침표나 세미콜론같은 문장 부호가 없더라도 어디서부터 어디까지가 한 문장인지를 알 수 있지 않은가? 행의 시작이 문장의 시작이고, 개행이 문장의 끝이니 말이다. 위 코드와 글에서 문장 부호를 빼 보자.

C 코드:

int    i = 1
double j = 2.0

한국어 글:

밥을 먹었다
똥을 쌌다

정말로, 문장 부호가 없더라도 문제가 되지 않음을 알 수 있다. (물론, 세미콜론이 없어 C 컴파일러로 위의 코드를 컴파일 할 수는 없겠지만, 스타일에 관해서만 이야기하자.) 그런데 여기서 좀 더 생각을 발전시킬 수 있다. 굳이 별도의 문장 부호를 사용하기보다, 개행으로 문장의 끝을 나타내도록 약속한다면 어떨까? 어차피 스타일 권고안에 따라 모든 문장을 각각 한 행으로 기술한다면, 세미콜론은 과잉 정보 아닌가 말이다.

이 점에 착안해 프로그래머가 특정한 스타일로 코드를 작성하도록 권하는 언어도 있다. 파이썬이 대표적이다. 파이썬은 기본적으로 문장을 한 행에 하나씩 작성하도록 한다.¹ 즉, 파이썬에서는 개행이 곧 문장의 끝을 나타낸다.² 덕분에 파이썬 코드는 여러 사람이 작성하더라도 스타일이 대동소이하다.

나는 문장 부호를 제공함으로써 스타일을 자유롭게 하는 것보다는, 파이썬처럼 개행으로 문장을 끝내도록 하여 스타일을 통일하는 편이 더 낫다고 생각한다.

자바스크립트에서의 세미콜론

한편 자바스크립트에서도 문장의 끝에 세미콜론을 반드시 붙이지 않아도 된다. 하지만 파이썬의 방식과는 차이가 있다. 파이썬에서는 세미콜론을 붙이지 않는 것이 기본이지만, 자바스크립트에서는 세미콜론을 붙이는 것이 기본이다.

자바스크립트에서는 엄연히 (개행이 아니라) 세미콜론으로 문장의 끝을 구별한다. 하지만 실제로는 세미콜론을 붙이지 않더라도 인터프리트 과정에서 구문 오류가 발생하지는 않는다. 그것은 인터프리터가 ‘문장의 끝이라고 생각되는 지점’에 세미콜론을 자동으로 붙여주기 때문이다. 이 기능을 세미콜론 자동 삽입(ASI, automatic semicolon insertion)이라고 한다. 이 기능을 만든 의도는 아마 초보 프로그래머들의 실수를 교정해주려는 배려였던 것 같다. 하지만 ASI는 규칙이 매우 복잡하고 동작을 예측하기 힘들어 말썽을 빚는다고 한다.

ASI로 인한 문제

인터프리터가 ‘세미콜론을 빠트렸음직한 부분’이라고 판단하는 곳은 어디일까? 그냥 코드를 작성하고 싶을 뿐인데 이런 것을 고민해야 하는 것은 참 성가시다. 하지만 그것을 무시하고 코딩하자니 ASI의 동작을 예측하지 못해 곤란을 겪을 우려가 있다. 세미콜론 논쟁의 핵심은 이런 ASI로 인한 문제를 어떻게 피할 것인가에 있는 것 같다.

세미콜론을 반드시 넣어야 한다는 사람들은 ASI의 동작을 예측하기 힘들기 때문에 모든 문장의 끝에 세미콜론을 넣으라고 한다. 반대로, 세미콜론을 넣지 않아도 된다(그리고 더 나아가 넣지 말라)고 주장하는 사람들은 ASI의 동작을 예측하기가 어렵지 않으며, 세미콜론을 명시적으로 붙이는 것과 ASI의 동작과는 관계가 없다고 한다. 각각의 주장을 따져보자.

세미콜론을 써야 한다는 주장

일단 자바스크립트의 기본 규칙은 문장의 끝에 세미콜론을 붙이는 것이다. 그래서인지, 과거에 나온 자바스크립트 교재를 보면 대부분 세미콜론을 넣는 것이 바람직하다고 설명하고 있다. 예를 들어, 『읽기 좋은 자바스크립트 코딩 기법(Maintainable Javascript)』(니콜라스 자카스 지음, 김광호 옮김)에 다음과 같은 설명이 있다. 조금 길지만 해당 내용을 전체 인용해 본다.

ASI는 코드에서 세미콜론이 필요한 자리를 찾고 없으면 세미콜론을 넣어주는데. 대부분 정확하게 찾아 문제가 없습니다. 그러나 ASI가 세미콜론을 찾는 규칙은 기억하기 어려울 정도로 복잡하므로 명시적으로 세미콜론을 넣기를 권장합니다. 디음과 같은 상황을 고려해 봅시다.
// 원래 코드
function getData() {
    return
        {
            title: 'Maintainable Javascript',
            author: 'Nicholas C. Zakas'
        }
}

// 파서가 생각하는 코드
function getData() {
    return;
        {
            title: 'Maintainable Javascript',
            author: 'Nicholas C. Zakas'
        };
}
이 예제에서 우리가 보기에 getData()는 데이터가 포함된 객체를 반환하는 힘수입니다. 하지만 ASI는 return 문 이후에 새로운 줄이 있으니 당연히 세미콜론을 삽입합니다. 따라서 getData 함수는 undefined를 반환합니다. 이 문장을 다음 예제처럼 return 문과 같은 줄에 중괄호를 표기하면 정상 값을 반환합니다.
// 세미콜론은 빠졌지만 정상 동작합니다.
function getData() {
    return {
        title: 'Maintainable Javascript',
        author: 'Nicholas C. Zakas'
    }
}
일반적으로 ASI가 수행되는 시나리오는 정해져 있습니다. 보통 두 가지 상황에서 ASI 에러가 발생하는데 ASI 동작 방식에 대한 이해 없이 코드를 작성하거나 ‘세미콜론이 없어도 ASI에서 알아서 넣어주겠지.’라는 안일한 생각으로 코드를 작성할 때입니다. 특히 경험이 부족한 개발자가 세미콜론을 빠뜨리는 실수를 자주 합니다.

더글라스 크락포드의 자바스크립트를 위한 코드 컨벤션, jQuery 코어 스타일 가이드, 구글 자바스크립트 스타일 가이드, Dojo 스타일 가이드에서도 모두 세미콜론 사용을 권장합니다. 또 JSLint와 JSHint 모두 기본적으로 세미콜론이 없으면 경고 메시지를 출력합니다.

자카스가 지적하는 것처럼, ASI의 동작을 잘 모른 채로 특정한 스타일로 코드를 작성할 경우 ASI로 인한 오류를 겪을 수 있다. 그런데 곰곰이 따져 보면, 문제를 일으키는 스타일은 ‘세미콜론을 넣느냐 안 넣느냐’가 아니라, ‘어디에서 개행하느냐’라는 것을 알 수 있다. 자카스가 ASI 문제를 우회한 코드에서도 세미콜론은 붙이지 않았다. (“세미콜론은 빠졌지만 정상 동작합니다.”라는 주석은 원문에서 그대로 인용한 것.) 즉, 세미콜론을 모든 문장의 끝에 붙인다 하더라도 자카스가 소개한 ASI 문제는 그대로 겪을 수 있다는 말이다.

결국 세미콜론을 넣느냐 마느냐는 기호의 문제이지, ASI 문제를 피하는 것과는 관계 없는 것 아닌가?

세미콜론을 쓰지 않아도 된다(쓰지 말아야 한다)는 주장

내가 세미콜론에 대해 다시 생각하게 된 것은 유명 자바스크립트 라이브러리에서 세미콜론을 사용하지 않는 코드를 종종 봤기 때문이다. 그 전까지는 세미콜론을 전혀 넣지 않는 자바스크립트 코드는 생각해 본 적도 없었기에 이상하게 생각되었다. 고집스럽게 세미콜론을 계속 넣기보다는 고수들이 왜 세미콜론을 안 넣는지 찾아 봐야 했다.

몇몇 블로그 글들을 읽어봤는데, JavaScript Standard Style(코드 형식 통일 프로그램)을 만든 Feross Aboukhadijeh의 글 「Never Use Semicolons」이 가장 근거가 분명하고 이해하기 쉬웠다. 장황한 내 글보다 훨씬 간결하니 직접 읽어보셔도 좋다. 그의 논점을 간단히 요약하자면, ASI와 명시적 세미콜론 삽입 스타일은 연관이 없으며, 세미콜론을 붙이는 것보다는 ASI의 동작을 이해하는 것이 중요하다는 것이다.

자카스도 지적했듯이, ASI는 대개는 적절한 위치를 추론하기 때문에 문제를 자주 일으키지는 않는다. 게다가 자카스가 든 예도 세미콜론을 명시적으로 붙여야 할 근거가 되기 보다는, ASI 문제가 특정한 코딩 스타일에서 발생한다는 것을 보여줄 뿐이다. ASI는 우리가 세미콜론을 명시적으로 넣든 안 넣든, 동작할 곳에서 동작한다. ASI 문제를 피하려면 ASI의 동작 원리를 이해하고 그에 맞게 코딩 스타일을 정립하는 것이 핵심이지, 세미콜론을 넣는 것을 강제할 필요는 없다.

그런데 Aboukhadijeh는 세미콜론을 넣지 않아도 된다는 데서 더 나아가, 세미콜론을 쓰지 말아야 한다고 주장하는 데까지 나아간다. 그 근거는 “모든 문장에 세미콜론을 넣어라”라는 규칙이 생각보다 따르기가 쉽지 않다는 것이다. 예를 들어, 다음과 같이 세미콜론을 붙이면 안 되는 위치들이 있다. (「Never Use Semicolons」에서 인용한 코드)

function foo () {
  return 42; // ok
};           // <– AVOID!

함수 정의는 그나마 간단하지만 클래스 정의 구문에서는 더 성가시다. (역시 「Never Use Semicolons」에서 인용한 코드)

class Foo {
  constructor () {
    if (baz) {
      return 42; // ok
    };           // <– AVOID!
    return 12;   // ok
  };             // <– AVOID!
};               // <– AVOID!

물론, 충분한 주의를 기울이고 편집기와 Lint 도구 등의 도움을 받으면 세미콜론을 찍을 위치와 안 찍을 위치를 가려내는 것이 크게 어렵지는 않다. 하지만 굳이 세미콜론을 고집해야 할까? 세미콜론을 아예 생략하기로 한다면 이런 성가신 문제를 전혀 신경쓰지 않아도 된다. 바로 이 순간, ASI가 일을 방해하는 기능에서 정말로 편의를 제공하는 기능으로 탈바꿈한다!

게다가 Aboukhadijeh에 따르면, ASI가 일을 방해하지 않도록 하려면 딱 한 가지 규칙만 기억하면 된다고 한다. 그것은 바로 행의 시작을 [, (, `으로 하지 않는 것이다. 꼭 그렇게 해야 한다면, 다음과 같이 세미콜론으로 행을 시작하면 된다고 한다. (역시 「Never Use Semicolons」에서 인용한 코드)

;[1, 2, 3].forEach(bar)

물론 이런 코드를 작성해야 할 경우는 거의 없을 것이니 안심해도 된다. 자바스크립트에서 식(expression)만을 덩그러니 써 놓는 코드를 쓸 일이 거의 없을 테니까 말이다. 즉, 대개는 let foo = [1, 2, 3].forEach(bar), 또는 return [1, 2, 3].forEach(bar)와 같이 문을 나타내는 키워드를 먼저 쓰기 마련이다.

결론

자바스크립트에서는 세미콜론을 굳이 넣지 않아도 된다. 그 전까지는 세미콜론을 반드시 넣자는 것이 압도적 다수파였던 것 같지만, 현재는 세미콜론을 넣지 말자는 주장도 힘이 커지고 있다. 여전히 논쟁거리인 것 같긴 하다. 내가 보기에는 세미콜론을 넣지 않아도 된다는 주장이 좀 더 설득력 있게 느껴진다. 나는 앞으로는 세미콜론을 생략하는 스타일로 코드를 작성할 생각이다.

참고

니콜라스 자카스의 책 『읽기 좋은 자바스크립트 코딩 기법(Maintainable Javascript)』의 일부 내용을 비판하기는 했지만, 전체적으로 매우 훌륭한 책이다. 번역도 꼼꼼하게 잘 되어 있다. 나도 이 책에서 많은 도움을 받았고, 이 책에서 제시하는 코딩 스타일을 대부분 따르고 있다. 자바스크립트 코딩 스타일에 관심이 있다면 읽어봐도 좋다.

세미콜론을 꼭 써야 한다고 생각하는 근거가 있거나, 내가 쓴 글에서 잘못된 내용이 있다면 알려주시기 바란다.

P.S.

그런데 간단히 정리하고 싶지만 또 그러기가 어려운 것이…

TC39(ECMA 인터내셔널의 ECMA 스크립트 담당 기술 위원회)에서는 향후에 언어가 확장되면서 발생할 수 있는 문제를 방지하기 위해서, 세미콜론을 넣는 스타일을 권장하는 듯하다.

관련 트위터 반응: https://twitter.com/BrendanEich/status/951554266535141377

나는 일단은 세미콜론 생략을 해 보려 하지만 나중에 가면 또 분위기가 변할 수도 있을 것 같다.

원한다면 파이썬에서도 세미콜론으로 문장의 끝을 표시하여 한 행에 여러 문장을 서술할 수도 있지만, 가능하다는 것이지 권장사항은 아니다. ↩
값·식·문이 한 행에서 끝나지 않는 경우는 예외. 이와 관련된 구문 규칙은 합리적이고 파서가 잘 해석한다. ↩

(번역) 2차원 회문(사토르 마방진) 탐색

2018-01-11T19:20:00+09:00

2차원 회문 탐색
- 사토르 마방진
- 파이썬으로 찾아 보자
한국어 2차원 회문

2차원 회문 탐색

이 글은 블라드스톤 필루(Wladston Filho)의 글 「Finding Magic Word Squares」를 허락을 구하여 번역한 것이다.

‘회문’에 관해서는 들어본 적이 있을 것이다. 회문은 그 속의 글자들을(대소문자 구별이나 문장 부호는 빼고) 앞에서부터 읽든, 뒤에서부터 읽든, 똑같은 문장으로 읽을 수 있다. 다음 회문들을 한번 앞뒤로 읽어 보시라.

Live not on evil.
Race fast, safe car!
Never odd or even.

사토르 마방진

하지만 흔해 빠진 그냥 회문을 소개하려고 이 글을 쓰는 것은 아니다. 오늘 소개하려는 것은 두둥~ ‘2차원 회문’이라는 물건이다. 아래 그림은 ‘사토르 마방진’이라는 것으로, 고대 로마 시대에 만들어진 유명한 2차원 회문이다.

그림: 고대 로마의 사토르 마방진

이 사토르 마방진은 라틴어 표현 sator arepo tenet opera rotas¹을 써 둔 것이다. 이 마방진의 대단한 점은 위에서 아래, 아래에서 위, 좌에서 우, 우에서 좌 어떤 방향으로든 읽을 수가 있다는 것이다.

그림: 사토르 마방진 읽기

그야말로 궁극의 회문이다. 고대 로마인들은 이 마방진에 매료되어 이것을 집집마다, 신전마다, 온갖 비석에, 그리고 심지어 물그릇에까지 새겨두곤 했다. 완벽한 대칭 속에 잡귀를 쫓고 행운을 불러오는 힘이 있다고 믿었던 것이다.

로마인들이 이런 2차원 라틴어 회문을 찾은 것은 굉장한 우연이었거나, 아니면 엄청난 수고를 들여 이뤄낸 일이었을 것이다. 2차원 회문의 존재를 알게 된 후, 나는 혹시 영어 단어 중에는 5x5 크기의 2차원 회문이 없을지 계속 고민해왔다.

파이썬으로 찾아 보자

컴퓨터를 이용하면 쉽게 찾을 수 있지 않을까? 그래서 간단한 파이썬 프로그램을 짜 봤다. 처리과정을 소개해본다.

먼저, 다섯 글자로 된 모든 영어 단어가 필요하다. 인터넷에 공개된 단어 목록을 활용하면 된다.

import urllib.request
src = "http://raw.githubusercontent.com"
src += "/codenrg/sator-square/master/words-en.txt"
fp = urllib.request.urlopen(src)
words = [str(line, 'utf-8').rstrip() for line in fp]

이것을 실행하면 words에 모든 영어 단어의 리스트가 저장된다. 2차원 회문을 만들려면 다섯 글자로 된 단어만 필요하므로 그것들만 선별하자.

words = filter(lambda x: len(x) == 5, words)

단어를 2차원 회문에서 쓸 수 있으려면 그것을 뒤집은 단어도 2차원 회문 속에 있어야 한다. 예를 들어, ‘stop’이라는 단어는 후보가 될 수 있다. 그것을 뒤집은 ‘pots’도 올바른 영어 단어이니까. 하지만 ‘coder’는 그렇지가 못하다. ‘redoc’은 올바른 영어 단어가 아니기 때문이다.

뒤집었을 때 탈락하는 단어들을 걸러내자. 먼저 단어들을 모두 집합에 넣고, 각 단어마다 그것을 뒤집은 단어가 집합에 들어있는지 검사한다.

words = set(words)
rev = lambda w: "".join(reversed(list(w)))
words = [w for w in words if rev(w) in words]

이제 후보가 될 수 있는 단어들은 다 추렸다. 이것들을 조합해 2차원 회문을 찾아보는 일만 남았다.

squares = []
for w1 in words:
    w2_match = lambda x: x[0] == w1[1] and x[-1] == w1[-2]
    for w2 in filter(w2_match, words):
        w3_match = lambda x: x[0] == w1[2] and x[1] == w2[2]
        for w3 in filter(w3_match, words):
            if w3 == rev(w3):
                square = [w1, w2, w3, rev(w2), rev(w1)]
                squares.append(square)

for x in squares:
    print("%s\n%s\n%s\n%s\n%s\n\n" % tuple(x))

이렇게 뽑아낸 단어들을 이용해 2차원 회문을 세 개 발견할 수 있었다. 그 중 가장 그럴듯한 것을 소개한다.

P A R T S
A P A R T
R A D A R
T R A P A
S T R A P

다른 언어에서도 2차원 회문을 찾을 수 있는지 확인해봐주면 좋곘다. 코드에서 개선할 점도 환영한다. 깃허브(https://github.com/codenrg/sator-square)에서 풀 요청을 보내주면 된다.

한국어 2차원 회문

여기서부터는 내가 추가한 내용이다. -박연오

필로의 프로그램을 이용해 한국어로 2차원 회문을 만들 수 있는지 찾아 보자.

먼저, 한국어 단어 목록이 필요하다. 나는 KoNLPy (파이썬 한국어 NLP)에 포함된 ‘Hannanum 시스템 사전’을 사용했다. 이것은 다음과 같이 하여 다운로드할 수 있다.

import urllib.request
fp = urllib.request.urlopen('https://raw.githubusercontent.com/konlpy/konlpy/master/konlpy/java/data/kE/dic_system.txt')
words = [str(line, 'utf-8').rstrip() for line in fp]

다운로드한 사전을 확인해 보면 한글로 시작하지 않는 단어들이 있다. 이것들을 걸러내자.

def is_hangul(ch):
    return '가' <= ch <= '힣'

def starts_with_hangul(word):
    return is_hangul(word[0])

words = [word for word in words if starts_with_hangul(word)]

또, 사전에는 가치체계 ncn처럼 품사가 태그되어 있다. 품사를 제거하여 가치체계와 같이 단어만 남기자.

def remove_tag(word):
    return word.split()[0]

words = [remove_tag(word) for word in words]

이제 한국어 단어 목록이 준비됐다. 나머지는 필로가 작성한 코드에 단어 목록을 적용해 2차원 회문을 찾아보는 것뿐이다.

이렇게 해서 만든 한국어 2차원 회문 탐색 프로그램은 깃허브에 올려두었다. https://github.com/bakyeono/sator-square/blob/master/find-sator-squares-in-korean.py

하지만 아쉽게도 별 재미는 보지 못했다. 적어도 내가 사용한 사전에서는 다섯 글자로 된 2차원 회문은발견할 수 없었기 때문이다. 글자 제한을 조금 줄이면 더 나오지 않을까? 그래서 네 글자로 찾아 보니 “하하하하” 처럼 모두 같은 글자로 이루어진 단어들밖에 안 나왔다. 세 글자로 된 2차원 회문을 찾아보니 개수가 너무 많이 나오는데, 대부분 사람 이름이 섞여 있어 마음에 들지 않는다. 아래는 그 가운데 그나마 쓸만한 것을 몇 개 추린 것이다.

대구대
구로구
대구대

경성대
성장성
대성경

주사파
사회사
파사주

대전대
전격전
대전대

식용유
용불용
유용식

알파벳보다 글자수가 훨-씬- 많은 한글의 특성상 2차원 회문이 되기가 좀 더 어려운 것이 아닌가 싶다. 사전을 다른 것(인명이 포함되지 않고, 한국어 단어의 활용을 어느 정도 반영한 것)으로 하면 더 찾을 수 있을지도 모른다.

적당히 번역하면 “농부 아레포가 쟁기(바퀴)로 작업한다”라는 뜻이라고 한다. (https://en.wikipedia.org/wiki/Sator_Square) ↩