Regular Expression (정규표현식) 정의 : 문자열에 대한 표현을 메타 문자로 표기하는 것

Regular Expression 실행 : 실제 문자열을 정규표현식과 매칭여부 검증


import re


^

Matches the beginning of a line
문자열의 처음과 일치 (행의 시작)

$

Matches the end of the line
문자열의 마지막과 일치 (행의 마지막)

.

Matches any character
모든 문자와 일치, 개행문자(\n) 제외

\s

Matches whitespace
공백 문자와 매치 (\t, \n, \r, \f, \v)

\S

Matches any non-whitespace character
공백 문자가 아닌 문자와 매치 

*

Repeats a character zero or more times 

0회 이상 반복

*?

Repeats a character zero or more times (non-greedy)
0회 이상 반복 (최소일치)

+Repeats a character one or more times
1회 이상 반복
+?Repeats a character one or more times (non-greedy)
1회 이상 반복 (최소 일치)
[aeiou]

Matches a single character in the listed set
소문자와 일치

[^XYZ]Matches a single character not in the listed set
[a-z0-9]

The set of characters can include a range
범위내에 해당하는 문자, 숫자 (ex. 숫자찾기 - find_num = re.findall('[0-9]+',text) )

(

Indicates where string extraction is to start
( ) 괄호 안의 내용을 그룹화, reference를 생성

)Indicates where string extraction is to end
( ) 괄호 안의 내용을 그룹화, reference를 생성을 종료

 match( )

 문자열의 처음부터 정규식과 일치하는지 확인

 search( )

 정규식과 일치하는지 문자열 전체에서 검색

 findall( )

 정규식과 일치하는 모든 문자열(substring)을 리스트로 반환 

 finditer( )

 정규식과 일치하는 모든 문자열(substring)을 iterator 객체로 반환

 sub( )

 정규식과 일치하면 변경

 split( ) 정규식과 일치하면 split 하여 반환


저작자 표시 비영리 동일 조건 변경 허락
신고

Comment



■ 본문 중에서


# 스탠바이 – 023p.

퍼즐이나 알고리즘 문제를 풀 때, 심지어 회사에서 어떤 문제를 해결하고자 할 때 이런 파괴와 창조는 유용하다. 미국에서는 보통 이런 걸 ‘상자 밖에서(out of box)’ 생각한다고 표현한다. 자기 머리가 유연하지 않다는 생각, ‘나는 왜 이런 문제를 풀지 못하지?’라는 생각이 드는 사람은 자기가 올해 읽은 시집이 몇 권인지 생각해보면 답이 나올 것이다. 아니, 시집의 권 수를 세는 것이 아니라 제대로 읽은 시가 몇 편인지 따져보아도 답이 나올 것이다.

상상이라는 말을 하는 사람은 많지만, 상상을 잘하기 위해서 노력하는 사람은 드물다. 하지만 상상을 하는 힘을 의미하는 상상력은 숨쉬고 밥을 먹으면 생기는 것이 아니다. 매일 헬스클럽에 다니는 사람의 배에 초콜렛 복근이 생기는 것처럼, 매일 시를 읽는 사람의 뇌에는 상상을 위한 복근이 생긴다. 시를 읽자. 심지어 좋은 시가 담아내는 고도의 추상은 객체지향이나 함수 패러다임이 포착하는 고도의 추상과 맥을 같이 한다. 매일 코드만 들여다보는 사람의 머리는 2차원이지만, 코딩을 하면서 시와 소설을 함께 읽는 사람의 머리는 3차원이다.

- 책에 심어놓은 5개의 뉭앙스 이야기 : http://www.snujn.com/news/18286



# 컴퓨터공학과의 인기 – 33-35p.

슈뢰딩거의 고양이는 우리가 상자를 여는 순간 삶과 죽음이 결정되지만, SI의 늪에서 고생하는 개발자 다수의 삶은 우리가 보지 않아도 존재한다. 무지막지한 하청구조의 결과로 육체적 생명을 담보잡힌 채 살아가는 그들의 삶은 관찰자의 유무와 상관없이 저기, 언제나 존재한다. 그들은 매일 마감일에 쫓기고, 야근에 시달리고, 박봉에 피눈물을 흘리고, 병원으로 실려가고, 학원 출신이라는 경멸 앞에서 고개를 숙인다. 판교의 개발자들이 노트북을 챙겨들고 커피전문점에서 코딩과 SNS를 즐기는 동안, SI 개발자들은 개발이라는 노동을 하며 시들어간다.

이러한 양극화가 심각한 이유는 간단하다. 판교의 개발자들이 꽃이면, SI개발자들은 흙이다. 흙이 비옥하지 않으면 꽃이 필 수 없다. 흙 없이 존재하는 꽃은 생명이 아니라 뿌리가 잘린 장식물에 불과하다. 수적으로 비교해도 그렇다. SI 개발자가 다수다. 프로그래밍을 공부하는 학생들 다수가 장차 취직을 하게 되는 곳은 판교가 아니라 SI라는 뜻이다. 따라서 SI 시장이 규제와 혁신을 통해서 변화하지 않으면 지금 불고 있는 컴퓨터공학과의 인기는 오래 갈 수 없다.

(중략)

미국에서는 소프트웨어 엔지니어라는 직업이 기본적으로 ‘좋은’ 직업으로 인식된다. 평균보다 높은 연봉, 좋은 복지, 유연한 근무 시간, 쉬운 이직. 구글이나 페이스북이 아니더라도 상관없다. 이름도 없고 작지만 훌륭한 회사가 즐비하다. 선택의 폭이 넓기 때문에 원하는 프로젝트를 고를 수 있는 여유도 있다. 연봉을 많이 받는 회사와 상대적으로 적게 받는 회사의 차이, 즐겁고 활기찬 회사와 느리고 지루한 회사의 차이는 있지만, 야근과 박봉에 시달리는 곳은 없다. 높낮이의 굴곡은 있을지언정 평균이 튼튼하고 강하다. 한국의 IT 시장이 지향해야 할 목표 지점도 이런 곳이어야 한다. 엘리트 개발자만 여유 있는 삶을 누리고 나머지는 고통받는 현실은 경쟁력을 갖추기도 어렵고 지속되기도 어렵다.



# 빅데이터와 스몰데이터 – 159p.

불변, 고계 함수, 커링 등 함수 패러다임에서 사용하는 개념들은 객체지향 패러다임을 사용하는 개발자에게도 그렇게 어렵지 않다. 그런데 그게 전부가 아니다. 카테고리 이론, 펑터, 모노이드, 모나드와 같은 괴상한 이름이 등장하면서 아직 함수 패러다임에 익숙하지 않은 사람들의 기를 눌리게 만든다. 그래서 실제로 미국에 있는 함수 개발자 중에서는 자성의 목소리가 터져나오기도 했다. 상대방이 모른다는 이유로 사실 자기도 모르는 걸 함부로 떠들지 말자.

자기도 정확하게 이해한 것이 아니면서 함부로 어려운 용어를 들먹이면서 함수 언어에 대한 진입장벽을 세우지 말자는 이야기다. 우리 업계에서는 불행하게도 그런 사람이 많다. 빅데이터나 머신러닝의 경우는 조금 다르다. 카테고리 이론이 잘난척하고 싶어 하는 개발자의 치기 때문에 언급된다고 하면, 빅데이터와 머신러닝은 기술적인 내용을 이해하지 못한 상태에서 자기 목적을 달성하려고 애쓰는 세일즈맨이나 언론에 의해서 의미가 확장되고 왜곡되는 경우에 해당한다. 단어 주변에 설탕과 밀가루가 잔뜩 묻은 채 부풀려져서 실제 의미에 접근하려는 사람의 발목을 붙잡는다.



# 머신러닝이란 – 167-168p.

영어에 ‘A on steroid’라는 표현이 있다. A는 A인데 그것이 스테로이드라는 약물을 복용했기 때문에 원래 A보다 더 강력한 무엇이 되었다는 의미다. 예를 들어서 스칼라 언어에 있는 패턴매치를 설명할 때 ‘Java switch on steroid’라는 표현이 흔히 사용된다. 자바에서 사용하는 스위치 구문과 비슷한데, 훨신 풍부하고 강력한 기능을 가지고 있다는 의미다.

개발자의 입장에서 보았을 때 머신러닝은 일종의 ‘알고리즘 on steroid’다. 흔히 하는 말로 약빤 알고리즘이다. 알고리즘이기 때문에 API만 있으면 코드 내부에서 쉽게 사용할 수 있지만, 약을 빨아들였기 때문에 기존 알고리즘보다 훨씬 강력하다.

기존 알고리즘에 비해서 강력해진 부분은 머신러닝 알고리즘은 동적이고, 피드백을 받으며 개선되어 나간다는 점이다. 기존의 알고리즘은 한번 작성되면 그것으로 끝이다. 나중에 다시 코드를 수정해서 개선하는 경우가 있긴 하지만 그건 알고리즘 자체가 변하는 경우를 의미한다. 머신러닝 알고리즘의 경우, 알고리즘은 그대로 있지만 알고리즘에게 적용되는 모델이 변한다. 모델은 수의 집합이다. 벡터로 불러도 좋고, 행렬이라고 불러도 좋다.




# NLP연구의 기초자산 – 말뭉치 – 186-187p.

요즘은 오픈소스와 인터넷의 발달로 개인이라고 해도 NLP에 대한 연구를 상당한 수준까지 진행할 수 있게 되었다. 다만 말뭉치의 경우 방대한 양의 텍스트에 대해 수작업으로 주석을 달아줘야 하는 관계로 개인이 만들기가 쉽지 않다. 이는 공개된 한글 말뭉치가 적은 것이 한글을 이용한 NLP 연구가 뒤쳐지게 되는 커다란 원인이 되고 있다.

일본의 경우 대학을 중심으로 여러 종류의 말뭉치가 공개되어 있으며, 위키피디아의 데이터를 이용한 명사 말뭉치도 꾸준하게 업데이트되어 공개되어 많은 NLP 연구자들이 편리하게 사용한다.

국내에 공개된 대표적인 한글 말뭉치로는 국립국어원에서 21세기 세종계획의 성과물로 내놓은 말뭉치가 있는데, 인터넷에 공개하지 않는 대신 학술 목적의 이용을 약속하면 CD 형태로 송부해준다. 문제는 이 말뭉치의 내부에 깨진 문자가 다수 존재한다든지 주석이나 태깅에 오류가 있다. 그래서 NLP 연구자가 사용하기엔 적지 않은 수고를 들여 수정해야만 사용이 가능하다. 개인적으로 국립국어원에서 하루빨리 이러한 문제점들을 인식하여 문제점을 보완해 깃허브와 같이 일반인들이 편리하게 접근할 수 있는 통로를 마련해 주었으면 하는 바램이다.




# 개발자와 알고리즘 – 214-215p.

http://www.zdnet.co.kr/column/column_view.asp?artice_id=20150622080223

대학에서 학생들이 배우는 것은 특정한 API를 다루는 ‘코딩’이 아니라 주어진 문제를 해결하기 위해서 규칙을 이해하고 (혹은 규칙을 정의하고!) 해당 규칙을 단계별로 적용해서 문제를 해결하는 능력이다. 다시 말해서 코딩이 아니라 알고리즘이다. 코딩이라는 것은 (우리가 앞에서 정의한 넓은 범위에서의) 알고리즘이 겉으로 드러나는 하나의 방식일 뿐이다. 즉, 코딩은 외공이고 알고리즘은 내공이다.


이런 이유 때문에 대학에서는 학생들에게 단편적인 코딩 능력이 아니라, 문제를 해결할 수 있는 능력, 즉 알고리즘을 길러줘야 한다. 코딩은 살에 새긴 문신과 같다. 내 몸의 일부지만 지우거나 덧칠할 수 있는 표면적인 존재다. 대학에서 배우지 않더라도 훗날 MOOC, 학원, 스터디그룹 등을 통해서 얼마든지 배울 수 있다. 하지만 뼈에 녹아서 나와 한 몸이 되는 알고리즘은 나와 분리할 수 없다. 그 자체로 내 프로그래밍 능력, 프로그래머로서의 정체성을 규정하는 화학적 구성물이다. 그래서 알고리즘은 배워야 하는 시기가 따로 있다. 시기를 놓치면 제대로 익히기 어렵다.


요즘처럼 기술 변화의 속도가 바른 시대에는 특정 기술, 플랫폼, 언어, API에 종속되는 코딩 기술의 가치가 전보다는 크지 않다. 오히려 낡은 기술을 버리고 새로운 기술을 익히는 능력이 더 중요하다. 전투기의 생명이 방향을 빠르게 전환하는 기동성(maneuverability)에 달려 있는 것처럼, 현대 프로그래머의 생명도 방향 전환 능력에 달려 있다. 알고리즘은 그런 방향 전환을 가능하게 만들어주는 일종의 ‘메타 능력’이다.


그래서 미국의 IT 회사들은 (특별히 예외적인 경우를 제외하면) 특정 기술이나 API에 정통한 사람을 찾지 않는다. 기본적인 능력, 즉 문제를 해결하는 알고리즘 능력을 갖춘 상태에서 새로운 기술을 빠르게 습득할 수 있는 사람을 찾는다. 앞에서 황금열쇠라고 표현한 것이 바로 이런 능력을 의미하는 것임은 다시 설명할 필요가 없다.


프로그래밍이라는 기술은 이렇게 알고리즘이라는 세포로 이루어져 잇다. 그리고 알고리즘이라는 세포 내부에 존재하는 DNA는 논리다. 일반적으로 논리적인 사람은 좋은 코드를 작성하지만, 논리적 사고가 결여되어 있는 사람은 아무리 열심히 ‘코딩’을 배워도 좋은 코드를 작성하지 못한다.

다시 질문으로 되돌아 가보자.

“프로그래밍을 하려면 알고리즘을 꼭 알아야 하는가?”

“개발자에게 알고리즘은 얼마나 중요한가?”

그렇다. 프로그래밍을 하려면 알고리즘을 반드시 알아야 하고, 개발자에게 알고리즘은 대단히 중요하다. 다른 답을 기대했던 사람에게는 미안하지만 프로그래밍을 하려면 알고리즘이라는 메타 능력이 필수적으로 요구된다. 알고리즘이라는 능력 없이 프로그래밍을 하려는 것은 한 수 이상 앞을 내다보지 못하는 사람이 바둑을 두는 것과 마찬가지다. 물에 뜨지 못하는 사람이 수영을 하려는 것이다. 프로그래밍은 알고리즘이다.



# 알고리즘은 개인기다 – 226p.

개발자에게 알고리즘은 축구선수에게 있어서 개인기와 같다. 개인기만 앞세우는 선수가 세계적인 선수가 되기는 어렵지만, 세계적인 선수 중에서 개인기가 부족한 사람은 없다. 박지성 선수가 맨체스터 유나이티드에서 활약할 때 호날두나 긱스 같은 선수와 비교해서 개인기가 부족하지 않은가 하는 비판을 받았는데, 설령 그렇다고 해도 그의 개인기는 이미 세계적인 수준에 도달해 있었다. 무슨 이야기인가 하면 훌륭한 회사에서, 훌륭한 프로젝트에서, 자신의 실력을 마음껏 과시하며 코딩에 열중할 수 있으려면 알고리즘에 대한 깊은 이해와 문제 해결 능력이 필수라는 뜻이다.

book.algospot.com



# 페이스북 개발자 해외 취업 그룹 – 284-285p.

http://www.moreagile.net/2014/08/it.html 

영어 공부의 다섯 가지 원칙

1. 사운드 퍼스트의 원칙 (Sound First) 

먼저 귀가 뚤려야 한다. 이해를 하지는 못하더라도 우선 말로서 들릴수 있어야 한다. 인간의 뇌는 소리에 대해서 필터링을 적용하여 언어와 그 외의 소리(노이즈)로 구분하여 처리하는데, 외국어에 대해서는 언어가 아닌 노이즈로 인식을 하게 된다. 귀를 뚫는데 있어서 저자가 제시한 포인트는 다음과 같다. 원어민의 발음에 최대한 가깝게 소리를 낼 수 있게 발음과 억양을 연습하는것이 맨 처음 이뤄져야 한다. 영어에 사용되는 음을 머저 이해하지 않으면 듣기도 읽기도 잘 늘지 않는다. 처음에는 의미를 이해하지 못하는게 당연하다. ‘음’에 대한 감을 단련해 두자. 


2. 다이렉트 이해의 원칙 (Direct Understanding)

영어를 번역해서 생각하지말고 영어 그대로 이해한다. 영어는 한국어로 1대1 번역이 불가능하다.


3. 스피킹중심의 원칙(Speaking Centered)

네이티브의 발음과 억양을 흉내내어 음독하는것은 영어를 유창하게 말하기 위한 초필살기이다. 단, 한국식 발음으로는 해 봤자 아무소용 없다. 반드시 네이티브의 발음을 최대한 흉내낼것!

음독시에는 스마트폰의 녹음기 기능등을 이용해 자신의 발음을 체크해보라.


4. 문맥이해의 원칙 (Contextual Experienced)

자잘한 단어나 문법이 아닌 전체적인 문맥으로서 대량의 문장을 이해하라. 단어도, 표현도 그 상황 안에서 의미를 파악해야 한다. 같은 상황에서 몇번이고 같은 표현을 마주함으로서 그 의미가 자연히 통하게 된다. 단어나 문법을 따로 공부할 필요는 없다. 그것보다 실생활의 영어를 대량으로 접해보자. 그러면 자연스럽게 몸에 익혀진다. 


5. 선택과 집중의 원칙(Choice and Focus)

영어는 크게 미국식과 영국식이 있어 어느쪽이든 선택해야만 한다. 자신이 주로 사용하고 싶은 쪽으로 타겟팅을 해서 그쪽 분야의 영어를 집중적으로 공략한다. 예를들면 저자는 애자일 개발이라는 분야를 목표로 해서 집중적으로 공부했다.


# 기획에서 테스트까지 – 322p.

www.quora.com에서 개발자들 사이에 마세라티 문제(https://www.quora.com/Whats-a-Maserati-Problem)가 논쟁이 되고 있다. 이탈리아 슈퍼카인 마세라티를 사기도 전에 마세라티를 사고 나서 생겨나는 문제를 고민한다는 것을 의미한다. 개발에 있어서도 이런 문제가 존재한다. 단순한 쇼핑몰과 웹 호스팅을 만들면 될 것을, 많은 개발자를 투입해 그보다 못한 서비스를 큰 비용으로 만드는 것이다. 마켓은 기다려주지 않는다. 성공할 타이밍을 놓칠 뿐만 아니라, 개발에 따른 스트레스도 날로 커진다. 장기간 개발의 끝에서 실패를 만난다. 전통적인 폭포수 모델이 이러하다.



# PC방 알바 – 373p.

냉정하게 보았을 때 김종민 게스트는 운이 좋았다. 타고난 재능과 멈추지 않는 노력이 밑바탕이 된 것은 의심할 여지가 없다. 하지만 그건 <청년의 방>에 등장하는 청년들도 마찬가지다. 그들은 이미 인간으로서, 물리적으로, 더 이상 할 수 없는 수준의 노력을 기울이고 있다. 그럼에도 현실은 지옥이다. PC방 알바 시절의 김종민 게스트는 알지 못했겠지만 그의 재능과 (이후에 펼쳐지는) 노력이 가리키고 있는 방향은 (운 좋게도) 전 세계적으로 수요와 혁신이 풍부하게 넘쳐 흐르는 시장을 향했다.

지연이나 학연으로 똘똘 뭉치는 패거리문화가 만연한 나라에서, 고졸이면 대통령도 무시하는 나라에서 김종민 게스트는 그런 천박한 문화가 개입할 여지가 없는 시장을 자신의 무대로 선택했다. 그게 운이다. 10년 전에 부산의 한 PC방에서 게임에 몰두하는 고등학생에게 컵라면을 가져다주고, PC를 수리하고, 게임을 설치하던 김종민 게스트를 상상하면서 지금 이 순간 전국의 모든 PC방에서, 편의점에서, 주유소에서, 주차장에서, 삶은 모든 현장 구석구석에서 치열하게 방황하고 있는 젊음들을 떠올려본다.

그들의 마음속에도 ‘내가 나중에 무엇을 할 수 있을까? 앞으로 어떻게 살아야 할까?’ 이런 생각이 멈추지 않고 떠오르기를 희망한다. 아무리 끔찍한 지옥이라도 그 마지막 생명줄을 놓지 않기 바란다. PC방에서 정상급 개발자로 발돋움한 김종민 게스트의 이야기는 예외적인 신화가 아니다. 누구에게나 일어날 수 있는 정상적인 일이다. 끝까지 생명줄을 놓지 않는 진지함과, 장인이 되고자 하는 어린 시절의 꿈을 망각하지 않은 일관성과, 뭐든 시작하면 성취를 이루고야 마는 집중력이 낳은 평범한 성공이다.


http://cmiscm.com/#/aboutme/



# 상경, 그리고 공부 – 377-378p.

프로그래머에게 실력의 궁극은 창조다. 반드시 많은 사람이 사용하는 언어나 플랫폼을 창조할 필요는 없다. 잘 알려진 오픈소스나 깃허브 코드일 필요도 없다. 자기가 다니는 회사에서, 혹은 자기가 수행하는 프로젝트에서, 원래 의도한 목적을 제대로 수행하는 코드를 만들면 그게 창조다. 그게 제일 중요하고, 제일 기본이다. 그래서 회사와 같은 현장에서는 실제로 사용되는 시스템을 설계하고 구현한 최초의 창시자가 가장 중요한 위치에서 다른 개발자를 리드하는 경우가 많다. 나중에 합류하는 프로그래머의 코딩 실력이 더 윗길인 경우도 있지만, 창시자의 철학과 비전은 실력 이상의 의미를 갖기 때문에 존중을 받는다.



# 개발자의 연봉 – 417p.

그들은 왜 구글이라는 엄청난 브랜드를 포기하고 뉴욕의 이름없는 스타트업 회사로 자리를 옮겼을까? 임팩트 때문이다. 자기가 짠 코드가 세상에 어떤 임팩트, 즉 어떤 영향을 주는 모습을 확인하고 싶기 때문이다. 세상에 엄청난 영향을 끼치는 작업을 수행하는 개발자는 구글에 많이 있다. 하지만 엄밀한 의미에서 그들은 소수다. 상당히 많은 구글 개발자가 거대한 조직 속에서 소리 소문 없이 사라지는 코드를 만들며 속상해한다. 다른 그룹의 개발자와 객체의 이름을 어떻게 붙여야 하는지 논쟁하며 하루를 보내고 허무한 심정으로 퇴근을 한다. 그런 개발자들은 회사의 브랜드를 포기하더라도 세상에 직접적인 영향을 끼치는 프로젝트에서 일하기 위해 다른 회사를 선택한다. 연봉 수준이 유지된다는 조건은 물론 기본이다.

이걸 우리나라의 상황에 대입해보자. 삼성전자에 다니는 개발자 중에서 비슷한 고민을 하는 사람이 있다고 해보자. 거대한 조직 속에서 소리 소문 없이 사라지는 코드를 만들며 좌절하고, 매일 의미없는 논쟁을 되풀이하며 지쳐간다. 그에겐 세상에 커다란 임팩트를 주는 프로젝트에서 일하고 싶은 욕망이있다. 그러던 그의 눈에 흥미로운 프로젝트가 발견되었다. 인포섹이라는 작은 중소업체에서 진행하는 프로젝트다. 자, 그가 삼성을 떠나서 인포섹에 들어가는 것이 가능할까? 천만의 말씀이다. 1억 연봉을 받다가 2,000만 원을 받으면서 일할 수 있는 사람은 세상에 없다. 그는 눈을 감는다. 그래, 하는 일은 재미없어도 1억을 받잖아. 버티자. 업계 전체를 놓고 보았을 때 이건 동맥경화다. 흐르지 않는 물이다. 개발자 연봉의 빈익빈 부익부, 양극화 현상은 이런식으로 업계 전체를 서서히 마비시킨다.




<팟캐스트 나는 프로그래머다 2탄>

임백준, 정도헌

한빛미디어, 2016



팟캐스트 나는 프로그래머다 2탄
국내도서
저자 : 임백준,정도현
출판 : 한빛미디어 2016.07.01
상세보기


저작자 표시 비영리 동일 조건 변경 허락
신고

Comment



■ 본문 중에서


# 보안전문가의 보안범죄 - 031-033p.

객체지향, 리팩토링, NoSQL 등의 분야에서 잘 알려진 마틴 파울러(Martin Fowler)는 프로그래머의 윤리와 관련된 강연을 여러 차례 수행했다. 2010년 QCon 런던에서는 '소프트웨어 개발의 윤리 the ethics of software development'라는 제목으로, GOTO 2014 행사에서는 '그저 코드 몽키인 것은 아니야 Not Just Code Monkeys'라는 제목으로 강연을 했다. 이러한 강연을 통해서 그가 전한 질문은 이런 것이었다.

"고객이 도덕적으로, 혹은 심지어 법적으로 하자가 있는 요청을 해올 때 프로그래머는 그것을 구현해야 하는가?"


법적으로는 문제가 없어도 윤리적인 문제를 가지고 있는 경우를 묶어서 파울러는 '다크 패턴(dark patterns)'이라고 불렀다. 겉에 보이는 링크와 실제로 도달하는 URL을 다르게 만든다든지, 사용자가 모르는 사이에 광고를 누르도록 만든다든지, 스파이웨어를 몰래 설치하는 것 등이 모두 다크 패턴의 사례다. 예컨대 악성 코드를 설치하기 위해서 중동호흡기증후군(메르스) 안내문자를 무작위로 뿌리는 것은 악질적인 다크 패턴이다. 파울러는 진정한 프로그래머라면 그런 요청을 단호하게 뿌리쳐야 한다고 말한다. 당연하다.

(중략)

내가 하는 일이 윤리적으로 혹은 법적으로 정당한가라는 질문은 간단하지 않다. 쉽게 답을 찾을 수 없는 경우가 많고, 심지어 질문 자체를 의식하지 못하는 경우가 흔하다. 그래서 프로그래머는 세상 공부를 열심히 해야 한다. 무엇이 옳고 무엇이 그른지 판단하는 윤리적 힘은 저절로 갖춰지는 것이 아니기 때문이다. 그런 노력을 게을리 하는 사람은 누구든지 샤오헤이의 유혹에 흔들릴 수 있다. 10억 원의 유혹 앞에서 흔들리지 않을 수 있는 사람이, 불행하게도 그렇게 많지 않은 세상이다. 맨홀 뚜껑이 땅으로 꺼져서 속수무책으로 사고를 당한 사람들처럼, 다크 패턴의 유혹에 바지는 것도 한 순간이다. 나만큼은 윤리적이라고 자신하지 말자.




# 전자정부 프레임워크의 족쇄 - 39-40p.

회사에서 일을 하다 보면 반드시 해야 하는 일보다 '프레임워크'에 집중하는 타입의 개발자가 있다. 초보자보다는 중급 개발자 중에 이런 사람이 많은데, 스스로 고급 개발자라고 주장하는 사람 중에서도 그런 사람이 적지 않다. 코드의 확장성이나 재사용성에 대한 어설픈 이해 때문에 아무도 사용하지 않을 프레임워크를 개발하면서 소중한 시간을 허비하는 사람들이다. 그렇게 시간을 보내느라 정작 구현해야 하는 비즈니스 요구사항은 뒷전으로 밀려난다.

모든 프레임워크는 시간이 지나면 족쇄로 변한다. 그렇기 때문에 '좋은 프레임워크'보다 아예 존재하지 않는 프레임워크가 더 좋다. 내가 최근에 번역한 『브루스 테이트의 세븐 랭귀지』 (한빛미디어, 2015)의 저자인 브루스 테이트는 2004년에 이미 프레임워크의 족쇄에 갇힌 자바 언어를 신랄하게 비판했다. 그가 2004년에 출간한 『더 낫고, 빠르고, 가벼운 자바 Better, Faster, Lighter Java』라는 책은 프레임워크에 갇힌 자바를 이렇게 소개했다. 2004년의 이야기라는 점을 기억하기 바란다.

"때로는 가장 단순한 해법이 최선이다. 악순환의 늪에 빠진 자바의 복잡성에 길들여진 엔터프라이즈 자바 개발자들은 간단한 방법이 있을 때조차 지나치게 복잡한 해결책을 선택하는 습관을 갖게 되었다. 웹로직, 제이보스, 웹스피어와 같은 '헤비급' 자바 기반 아키텍처를 이용해서 서버를 구축하는 것은 많은 비용을 발생시키고 번거롭다. 실제 문제를 해결하는 것보다 선택된 프레임워크를 지원하기 위해서 더 많은 시간을 보내는 지점에 도달하게 되었다면, 무언가 단순한 방법에 대해서 고민을 해보아야 하는 시점이 된 것이다."

내가 보기에 전자정부프레임워크는 브루스 테이트가 비판하는 2004년의 기업용 프레임워크보다 더 나쁘다. 헤비급 아키텍처는 비록 비싸고 번거로운 단점이 있더라도 시장에서 타제품과 경쟁을 하며 기능을 향상시킬 수 밖에 없었다. 개발자들이 여러 제품 사이에서 최선을 찾기 위해서 노력할 공간이 존재했던 것이다. 그에 비해서 전자정부프레임워크는 삼성, LG, SK 등 지정 과정에 참여한 소수 SI 업체의 이익을 반영할 뿐, 그 안에서 개발자들이 숨 쉴 공간이 없다.




# 새로운 언어를 공부한다는 것 - 108p.

거듭 이야기하지만 새로운 언어를 공부한다는 것은 그 언어의 '문법'을 익히는 것이 아니다. 당연히 문법도 포함되어야 하겠지만, 언어를 배우는 것은 그 언어를 둘러싼 철학과 패러다임, 생태계, 도구, 그리고 라이브러리를 두루두루 익히는 것을 의미한다. 그렇기 때문에 새로 배울 언어를 선택할 때는 새 연인을 만나는 것처럼 신중해야 한다. 한 번 선택했으면 한눈을 팔거나 다른 사람의 눈치를 보지 말아야 한다. 사랑은 아무 망설임 없이 온몸을 던져서 할 때 결실을 맺는 법이다.



# '빌드'로 보여준 존재감 - 210p.

MS는 그 동안 적으로 삼았던 리눅스와 리눅스 가상화 컨테이너 기술인 도커를 자사 클라우드인 애저에서 지원했으며, 안드로이드에 오피스와 안드로이드를 위한 개발 환경까지 제공함으로써 소비자의 가치를 우선으로 하겠다는 변화된 모습과 개방성을 만천하에 과시했다.

개발자들의 마음은 어찌 보면 단순하다. 원하는 것은 유저, 소비자를 만족시키는 솔루션을 제공하는 회사에게 있다. 요 몇 년 전까지 구글이 개발자들을 열광시켰고, 이 바통을 이어받아 페이스북이 힙스터의 면모를 보여줬다.

최초로 소프트웨어 라이선스를 만든 장수 기업인 MS는 천천히 준비했고 모바일과 클라우드를 아우르는 개발자를 위한 모든 것을 선사했다. 변화하고자 하는 의지로 화석이라 조롱받았던 MS는 깨어나 이렇게 멋지게 시장을 주도하게 되었다.



# 데이터센터 vs 클라우드 - 226-227p.

DevOps는 개발(Development)과 운영(Operations)을 합성해서 만들어낸 신조어로 개발, 빌드, 배포, 테스트를 하나의 사이클로 만들어 끊임없이 반복하는 개발 프로세스와 이를 실천하기 위해 필요한 기술, 툴링을 총칭하는 하나의 개발 패러다임이다. 클라우드 컴퓨팅과 DevOps는 두 가지 접점을 가진다. 한 가지는 클라우드 컴퓨팅에서는 스케일 아웃이나 스케일 업에 대응하기 위해 인프라 구성 작업이 매우 빈번하게 이루어지게 된다는 점이고 또 한 가지는 이러한 구성 작업이 단순한 설정 작업에 그치는 것이 아니라 서버 애플리케이션의 릴리스에 따른 애플리케이션 버전 관리, 데이터 마이그레이션, 그리고 이를 테스트하기 위한 버전별 자동화 테스트에 이르기까지 복잡한 일련의 작업들이 자동화되어 빠르고 정확하게 이루어져야 한다는 점이다.

다시말해 클라우드 컴퓨팅에서의 DevOps는 서비스의 생명이라 할 수 있는 생산성과 유연성 그리고 안정성을 확보하기 위해 가장 적합한 플랫폼이라고 할 수 있다.



# 핀테크, 메가 트렌드인가 버즈워드인가? 

- 242p.

"그들이 우리 점심을 빼앗아 먹으려 하고 있다. They all want to eat our lunch"

여기에서 '그들'은 실리콘밸리고 '우리'는 월스트리트다. 그(제이미 다이먼)의 말은 실리콘밸리를 거점으로 하는 핀테크 스타트업 회사들에 대한 기존 금융기관의 공포와 우려를 대변하는 말로 유명해졌다. 하지만 월스트리트의 회사들이 핀테크의 흐름을 지켜보면서 두려움만 느끼고 있는 것은 아니다.

핀테크가 몰고 오고 있는 변화가 일시적인 유행이 아님을 깨달은 미국의 기존 금융기관들은 오히려 실리콘밸리의 스타트업과 제휴하거나 자본을 대는 방식으로 공생을 꾀하고 있다. 비트코인 지갑 서비스를 제공하는 회사인 코인베이스(Coinbase)를 적극적으로 지원하는 뉴욕증권거래소가 대표적이다.


- 249p.

의구심, 상상력, 소프트웨어 기술은 핀테크라는 나무를 떠받치는 세 개의 줄기다. 의문이 떠올랐을 때 각종 규제와 현실의 벽을 생각하고 움츠러들면 씨앗이 싹을 틔우지 못한다. 머릿속에서 맴도는 의문으로 끝나기 때문에 육화되어 세상에 모습을 드러내지 못한다. 일단 의심해서 싹을 틔웠으면 온 힘을 다해 상상해야 한다. 이때도 현실의 벽 따위는 생각하지 않는 게 좋다. 상상을 하는 동안 생각의 속도로 소프트웨어를 작성하는 것도 중요하다. 그렇게 하기 위해서는 빠르고 정확하게 소프트웨어를 구현할 수 있는 끼와 재능이 있어야 한다.

우리나라에서 핀테크와 관련된 이야기는 언제나 현실적 규제, 법적 장치, 대형 은행의 이익, 이런 부분을 중심으로 진행된다. 답답하고 지루하다. 핀테크를 생각하는 사람은 상상의 범위를 우리나라로 국한시키지 말아야 한다. 핀테크의 '비즈니스'적인 요소는 특정 나라의 법적 규제를 받을지 몰라도 '기술적'인 요소는 그런 구속이 필요 없기 때문이다. 핵심은 기술을 상상하는 것이다. 그런 상상에는 국경이 없다.



# 국세청 홈택스, 국가 프로젝트의 단면 268-270p.

임작가: 홈택스? 그게 뭐에요

데니스: 세무 관련 사이트를 통합한 겁니다. 문제는 액티브X 8개를 사이트에 모아놨는데요. 8개를 하나의 심플한 액티브X를 만든 게 아니라 여러 프로그램이 덕지덕지 붙은 괴물이 나왔죠.

임작가: 홈택스라는 게 일반 시민들이 세금 정산할 때 사용하는 사이트라는 거죠?

데니스: 네, 그 때문에 세금을 못 낸 사람도 있고, 에러가 나서 해외에서 접속을 못한 사람도 있구요, 맥에서 버추얼박스나 패러럴즈에서 사용하는 유저들도 사용에 불편을 겪었죠. 이번에 워낙 에러가 많으니 홈페이지 메인에 전화문의 말고 메일로만 접수해달라는 공지가 있었죠.

임작가: 그럼 안 보겠단 얘기잖아 ㅋㅋㅋ

데니스: 네 그래서 지금 정부의 세금, 세무 관련 분들이 분노 폭발 직전이죠.

임작가: 누가 만든 거에요 그 사이트는?

데니스: 그 유명한 임작가 님 출신의 그 회사 모 회사.

임작가: 진짜요? 그?

데니스: 다음 이슈는 뭐냐면요 분기마감 등 이럴 때 딱 나올 거예요. 세금대란. 홈택스 문제 있다. 안정화 아직도 못하고 있어요 제대로... 어떤 경우가 있냐면요, 세금계산서를 발행했는데 상대가 받지 못하는 거예요.

임작가: 야... 이거는 창피하다.

데니스: 그렇죠... 창피한 이슈죠. 발코딩이 이슈가 아니예요 이건...

임작가: 아니... 대한민국 최고기업이, 대한민국에서 최고로 중요한 웹 사이트를 만들었는데 이런 일이 발생하다니요.

데니스: 우간다에서도 이런 일이 없는데, 우리나라에서 발생했습니다.

(중략)

국세청에서 개발한 국세 관련 프로그램은 2015년 2분기부터 대혼란을 일으켰다. 기존 프로그램을 단순하게 하나로 모은 것이기 때문에 다양한 액티브X를 설치하고 웹 브라우저의 보안 레벨도 극도로 낮춰야 동작하는 등, 보안적인 면에서 좋지 않은 시스템을 만들었다. 

심지어 홈택스는 SSL에 대해서 웹 브라우저에서 안전하지 못하다는 보안경고가 2015년 9월 말 현재까지 발생하고 있다. 보안 취약점 문제로 이미 MS가 사용을 금지한 액티브X 기반의 보안 프로그램을 덕지덕지 올려 국민 PC의 안정성을 해치는 국세청 프로그램의 문제를 용납하기 힘들다.

http://www.etnews.com/20150224000210



# 여자 개발자라는 블루오션 

- 340-342p.

전수현 개발자의 이야기를 듣다가 내가 개인적으로 가장 놀란 부분이 여기다. 6개월 동안 혼자 마음을 앓다가 퇴사라는 극단적인 선택을 할 수밖에 없었는데 그걸 배려로 알고 있더란다. 여성의 입장에서는 심각한 차별이었던 것을 남성들은 자기 입장에서 배려로 생각한 것이다. 엄청난 착각이다. 생각하는 바가 화성과 금성의 거리만큼 떨어져 있다. 이런 인식의 거리가 한 사회가 열려있는 정도를 나타내는 척도에 해당한다. 나도 한국에서 생활했으면 이런 착각으로부터 자유롭지 못했을 것이다.

(중략)

성차별에는 '임신'에 대한 차별이 포함되어 있다. 나이에 따른 차별을 이야기할 때 차별받는 입장에 속하는 나이는 대략 40세를 전후로 한다. 회사에 다니고 있는 직원은 말할 것도 없고, 새로운 사람을 채용하기 위한 면접을 진행할 때 위에서 언급한 종류의 내용, 즉 인종, 신념, 피부색, 나이, 성별, 종교, 출신 나라와 관련된 이야기는 아예 언급 자체가 금지되어 있다. 만약 그런 내용이 농담으로라도 발설되고, 피면접인이 그러한 발언 때문에 불쾌하거나 불편한 기분을 느꼈다면, 그것은 즉각적인 소송감이며 회사는 불리한 입장에 처하게 된다. 그래서 미국 회사들은 손해를 보지 않기 위해서라도 직원들 교육에 정성을 들인다. 하지만 이런 차별에 대한 정확한 인식과 행동은 교육 이전에 시민의식과 상식의 문제다.

차별을 금지하는 법과 정책이 존재하는 이유는 사실 차별이 있기 때문이다. 알려진 바와 같이 미국은 조금만 껍질을 벗기면 흑백갈등이 적나라하게 드러나는 나라다. 이슬람 종교와 테러리스트를 연결 짓거나 대통령 후보에게 성경을 글자 하나 빼놓지 않고 모두 믿느냐고 질문하는 식의 종교적 차별도 존재하고, 나이에 대한 차별도 실제로는 얼마든지 있다. 하지만 일반적인 직장에서 이와 같은 차별에 대한 속마음을 여과 없이 드러냈다가는 감당할 수 없는 결과를 초래하게 된다.


- 349p.

여자들이 남자들의 영역, 즉 야근이나 맹목적인 충성 같은 부분에서 남자들에게 뒤처질 거라고 생각해서 채용을 꺼리는 것은 편협하다. 여자들도 그런 일을 남자만큼 잘 할 수 있다고 말하려는 게 아니다. 남자들의 영역이라고 생각되는 것, 그런 관념의 틀 자체를 깨야 한다는 말이다. 여자가 왜 남자의 영역으로 들어가야 하는가. 여자는 여자의 영역이 있고, 기업의 생산성이라는 측면에서 생각하면 여자의 영역과 남자의 영역이 조화롭게 공존할 때 최고의 성과를 거둘 수 있음이 분명하다. 그건 심지어 자연의 법칙이기도 하다.

우리나라의 여성 인구가 100명이고 남성 인구도 100이라고 가정하자. 여자 100명 중에서 10명이 개발자로서 재능을 가지고 있고, 남자 중에서도 10이 개발자로서 재능을 가지고 있다고 하자. 이 경우 전 사회적으로 프로그래밍에 재능이 있는 사람의 수는 20명이다. 이제 우리나라에서 필요한 컴푸터 프로그래머의 수가 20명이라고 하자. 남녀 구별 없이 실력과 재능에 따라서 채용을 하면 20명의 자리를 모두 재능 있는 사람으로 채울 수 있다. 하지만 단지 여자라는 이유로 면접결과를 취소한다면 적어도 10명의 자리는 재능이 없는 남자로 채워질 수밖에 없다. 최선이 아니다.



# 개발자와 영어, 뜨거운 애증관계에 대하여 - 373-375p.

듣기는 외국 생활 '짬밥'에 정비례한다. 외국에서 살면 들리는 것이 영어이기 때문에 늘지 않을 수가 없다. 그리고 영어듣기는 생각보다 어렵지 않다. 아직 영어가 들리지 않는 사람도 내 말을 믿기 바란다. 미국으로 오기 전에 나도 회사에서 보라는 토익시험을 보면 점수가 바닥을 기었지만 막상 미국에 건너가 수업을 따라가는 데 아무 지장이 없었다. 사람을 직접 보고 이야기를 들으니 듣기 훈련이 되어 있지 않은 상태에서도 의미를 이해하는 것이 어렵지 않았다(물론 "휘리리톡" 같은 것은 예외다).

그렇기 때문에 한국에서도 영어로 된 뉴스나 방송, 혹은 프로그래밍 관련 팟캐스트 같은 것을 열심히 들으면 영어듣기 능력을 필요한 수준 이상으로 향상시키는 것이 얼마든지 가능하다. 듣기는 그야말로 듣는 양에 정비례 한다. 장소는 큰 의미가 없다.

하지만 말하기는 조금 다르다. 듣기가 짬밥이라면 말하기는 상황이다. 무슨 말인가 하면 말을 해야 하는 상황에 자신을 밀어넣어야만 말하기 능력이 늘 수 있다는 뜻이다. 공부라는 차원이 아니다. 말하기는 생활의 일부가 되지 않으면 늘기 어렵다. 미국에서 나보다 오래 생활한 한국인을 만났을 때 영어말하기 능력이 내가 처음 미국에 왔을 때랑 다르지 않아서 놀라는 경우가 있다. 한인들을 상대로 비즈니스를 하거나 연구소에서 하루 종일 아무 말도 하지 않고 지내는 사람이 대개 그렇다. 말을 할 일이 없으니 말하기 능력이 달라지지 않는다. 10년이 지나도 마찬가지다.

(중략)

영어 때문에 스트레스받지 않기 바란다. 내가 이렇게 할 수 있었음을 생각해보면 한국에서 평균적인 수준으로 영어를 공부한 사람은 누구나 이미 해외에 나가서 살아가는 데 아무런 지장이 없다. 문제는 영어가 아니라 영어라는 그릇에 담는 내용물이다. 개발자 영어라 했을 때 방점을 찍어야 하는 부분은 영어가 아니라 개발이라는 뜻이다. 내용에 집중하다 보면 형식은 저절로 따라온다. 그래야 진짜다.



# SI 이노베이션은 개발자 처우 개선부터 - 403p.

속담에도 절이 싫으면 중이 떠나라는 말이 있습니다. 개인이 조직을 바꾼다는 것은 상당히 어렵습니다. 그런 의미에서 (라쿠텐) 홍보를 좀 하자면 좋은 곳을 찾아 떠나는 것도 한 가지 방법이 될 수 있습니다. 결과적으로 좋은 회사로 인력이 이동하다 보면 좋은 업체들만이 살아남을 수 있겠죠. 그리고 해외 이직도 한 가지 방법이 될 수 있습니다. 너무 국내에서만 찾으려 하지 마시고 해외로 조금만 눈을 돌려보시면 얼마든지 좋은 조건에 일하실 수 있는 기업들이 있으니 꼭 한 번 알아보시기 바랍니다.





<팟캐스트 나는 프로그래머다>

임백준, 정도현, 김호광 지음

한빛미디어, 2015


팟캐스트 나는 프로그래머다
국내도서
저자 : 임백준,정도현,김호광
출판 : 한빛미디어 2015.11.01
상세보기


저작자 표시 비영리 동일 조건 변경 허락
신고

Comment