예술가와 기술자 - 당신은 작품을 만드는가

당신이 만든 그 결과물은 당신의 작품인가?

나는 지금 비록 프로그래머이지만 한 때는 작곡가를 꿈꾸던 음악인이었고, 지금도 다양한 예술 활동을 펼치고 있는 중이다. 나는 엔지니어 이전에 아티스트였고, 그러한 성향이 평소에든 일을 할 때든 많이 드러나곤 했다.

내가 만든 프로그램은 그 누구에게 보여주어야 할 결과물 이전에 나만의 작품이다. 이러한 생각이 일에 도움이 될 때는 누구보다 훌륭한 결과물을 만들어내지만 괜히 내 맘대로 뭘 해보려다가 일을 망치는 경우도 많았다.

예전에 동아리 활동에서 대자보를 만드는 일이 많았는데, 나는 심각한 고민과 구상 끝에 꼼꼼한 크레파스질과 가위질로 예술작품을 만드는 반면에, 다른 후배는 대충(내가 볼 때) 인터넷에서 자료를 참고한 뒤 쓱싹쓱싹 순식간에 우리에게 정말 필요한 것(내가 보기에 아름다운 것이 아니라)을 만들어내는 것이었다. 덕분에 많은 자유시간이 확보됨은 물론 내 스트레스도 사라졌다. 이 일로 해서 내 예술가적 기질이 얼마나 사람들과 나 자신을 피곤하게 하는가에 대해 다시 한 번 생각해보게 되었다.

예술가 테스트 문항

아래는 내가 직접 만든 테스트이다. 아래 항목에 해당하는 경험이 많을 수록 당신은 예술가이다.

1. 교수님이 내는 과제가 시시하다고 생각할 때가 있다.

교수님이 쉬운 과제를 내면 옳다구나 하고 기뻐하면 될 일인데, 예술가는 꼭 상대방의 요구사항에 자신의 생각을 덧붙인다.

2. 나는 가끔 천재적인 기질을 보일 때가 있다.

신이시여, 이 영화를 정녕 제가 만들었단 말입니까? - <벤허>를 감독한 와일러

3. 내가 설치한 윈도우가 아니면 내 컴퓨터가 아니다.

모든 환경은 완벽하고 통제 가능해야 한다.

4. 바탕화면을 고르는데 30분 이상 걸린다.

예술을 위해서는 나만의 작업 공간이 필요하다.

5. 우리 학교에는 하찮은 교수님이 많다.

자존심과 자만심이야말로 예술가의 본성이다.

6. 특별한 이유 없이 예전에 했던 과제나 프로젝트를 이따금씩 꺼내본다.

일을 한 것이 아니라 작품을 만들었기 때문이다.

7. 파이썬은 자바보다 아름답다. (혹은 그 반대)

아름다움을 왜 따짐?

8. 교수님들은 내가 낸 과제의 가치를 제대로 평가하지 않는다.

나만의 관점, 나만이 알 수 있는 아름다움을 제대로 평가받고 싶은 욕구가 많으며, 대체로 이것은 잘 채워지지 않는다.

9. 시시한 논문에는 차라리 내 이름을 빼고 싶다.

예술가는 경력보다 자존심이 먼저다. 아무리 나에게 도움이 되는 일이라도 부끄럽지 않아야 한다.

일할 때 특징

일을 하다 보면, 혹은 일을 시켜보면 예술가 기질의 사람과 기술자 기질의 사람은 몇 가지 차이가 있다. 때로는 큰 차이처럼 느껴지기도 하고, 결국 별거 아니라는 생각도 든다.

아무래도 내가 예술가 기질이기 때문에 약간의 자학 개그를 섞어 보았다. ㅎㅎ

장) 예술가 : 자신만의 아이디어가 풍부하다.

단) 기술자 : 시키는 대로만 한다.

장) 기술자 : 시키는 대로는 잘 한다.

단) 예술가 : 시키는 대로 안 한다.

장) 예술가 : 누구보다 열정적으로 일한다.

단) 기술자 : 보수를 보고 일한다.

장) 기술자 : 보수만큼은 일한다.

단) 예술가 : 보수 이상으로 열심히 하다(기획만 하다) 혼자 퍼진다.

장) 예술가 : 요구사항 외에 여러 가지 필요한 기능을 생각해온다.

단) 기술자 : 요구하는 기능 외에는 프로그램이 어떻게 굴러가든 관심이 없다.

장) 기술자 : 요구하는 기능은 잘 구현한다.

단) 예술가 : 요구사항과 영 상관이 없는 결과물을 가지고 와서 클라이언트를 설득하려고 든다.

장??) 예술가 : 시시한 일에는 관심이 없다.

단) 기술자 : 일이기 때문에 관심을 가진다.

장) 기술자 : 꼭 필요한 일에 집중한다.

단??) 예술가 : 쓸데없는 일에 관심이 많다.

쓸데없는 일이 정말 쓸데없는 지는 아무도 모를 일이다. 예술가는 자기 호기심을 자극하는 여러 가지 일들에 두루 관심이 많기 때문에 쓸데없는 것에 시간을 잡아먹는 것 같기도 하지만, 더 좋은 결과물과 방향을 제시할 때가 많다. 하여튼 시키는 대로 할 생각이 없다. ㅋㅋㅋ

성격을 보완할 부분

예술가든 기술자든 그 성격이 다듬어지고 완성되면 결국 비슷해진다. 성격과 상관없이 직무에 있어서 요구되는 사항은 똑같은데 개선할 방향이 다르다.

예술가는 자기 하고 싶을 때만 열심히 하는 것처럼 보인다. 자기 주장이 강하고, 때로는 자기 자존심만 챙기려 들 때가 많다. 또한 완벽주의 성격이 다른 사람을 힘들게 한다.

 - 하기 싫은 일은 결국 해야 한다. 얼른 하는 것이 스트레스를 줄이는 최선이다.

 - 내 자존심보다 다수의 행복이 중요하다.

 - 클라이언트보다 우리 회사 직원이 더 중요하다.
 - 일단 시키는 대로 해보는 것도 시킨 사람에 대한 예의다.

 - 상대방의 언어로 얘기하는 것도 능력이다.

 - 싸우지 말자.

기술자는 시키는 대로만 하고 결과를 책임지지 않는 것처럼 보인다. 자기개발에 소홀히 할 때가 많다. 타인의 감정과 형편을 이해하지 못할 때가 많다.

 - 이번 일을 잘 끝내야 다음 일도 타올 수 있다.

 - 뒤쳐지지 않는 가장 좋은 길은 최고가 되려고 노력하는 것이다.

 - 내가 도움을 주면 언젠가 남도 나를 도울 일이 있다.

 - 특별한 사람들을 특별하게 생각해주면, 특별한 일을 해낸다.

Read More

서태지 이후 30년, 대중가요 흐름을 바꾼 가수들

모든 것은 서태지로부터 시작되었다.


나는 서태지 세대임과 동시에 서태지 광팬이기도 하다. 다양한 스펙트럼을 가진 서태지 팬들 중에서도 나는 그냥 가요를 좋아하는 사람이다. 30년간 가요계도 수도 없이 흐름이 바뀌었는데, 곰곰이 돌아보면 눈에 띄는 가수 몇몇이 생각난다. 해서 그들이 누구인지 적어보면서 추억을 회상해보고 싶다.

30년간의 가요계를 몇 몇의 등장으로 정리하는 건 너무 심하게 퉁치는 것 같기도 하다. 중요한 몇 가지만 제외하고는 대충대충 생략해본다.
선정 기준은 새로운 흐름을 창시하고 주도했느냐이다. 이전 시대의 유행을 끝내고 새로운 유행을 가져온, 혁신적인 전환을 주도했던 그룹을 추리고 추려서 꼽아본다.

서태지와 아이들

우선 서태지. 그리고 아이들. 서태지는 하두 얘기할 게 많은데, 우선 세계적인 음악 흐름을 단기간에 우리나라 가요계로 당겨오는데 큰 공을 세운다. 음악 수입상, 음악 백화점. 물론 우리나라 가요 흐름이나 퀄리티가 당장 팝을 따라잡지는 못했으나, 겨우 트로트 아니면 일본 가요 표절에 머물러 있던 시절을 극복해내는 시발점이 된다.

당시 서태지 노래를 좋아하던 내 기억에는 서태지 말고 다른 음악은 쓰레기같이 들렸던 추억을 가지고 있다. 서태지는 뭔가 음악이 꽉 들어차 있고 풍성한데 반해 다른 노래는 영 허접하게 들렸는데 그 이유를 몰랐었다. 지금 다시 들어보니 한 마디로 사운드가 다르다. 음원 소스부터 완전히 차별적이었던 것이다.
서태지 노래가 좋았던 또 다른 이유는 랩/댄스/메탈이 적절히 섞인 종합 음악이었기 때문이다. 특히 부드럽고 세련된 멜로디가 강력한 사운드 위에 얹어졌을 때, 참 그게 매력적이었다.

그리고 또 서태지가 좋았던 이유는 그냥 락을 좋아해서도 있다. 이 시절 가요탑텐에서 락 음악을 하는 건 오직 서태지와 김종서 뿐이었다. 락 음악의 대중화는 서태지의 가장 큰 공로일 것이다.

서태지 이전에도 댄스 음악은 있었다. 그러나 서태지 이후로는 댄스 그룹이 있다. 당시에는 노래하는 창렬이와 랩하는 재용이가 따로 있는게 유행이라서 쿨에는 박성수가 있고 R.ef에는 박철우가 있었다. 이 모든 게 이주노가 뒤에서 암 말도 안 하고 춤만 추면서도 멋있는 걸 보여줬기 때문이었다. 댄스 그룹은 항상 역할이 분담되어 있고 춤만 추는 놈, 랩만 하는 놈이 따로 있었다. 그래서 나온 말이 '저게 가수냐~' 이다. 가수가 아닌 것 같은 놈들이 가수 행세를 시작한 시대가 바로 여기부터이고, 그래서 '나는 가수다' 를 외치며 노래 잘하는 가수가 대접받기까지 참 오랜 세월이 걸렸다. 서태지는 완전한 음악인이었는데, 유행은 비음악이었다.

랩을 빼놓고 서태지를 얘기할 수 없다. 랩 뿐만 아니라 힙합 문화를 들여오는데 선구자 역할을 했다. 듀스니 현진영이니 하는 것은 그 사람들의 음악적 성과가 너무 평가절하되는 것이 안타까워서 끼워줄 뿐, 사실 독보적인 선구자는 서태지다.
서태지가 보여줬던 것이 본격적인 랩이 아니라고 평가하는 사람들도 있다. 진정한(??) 랩의 시작은 서태지가 아니라고들 한다. 그래 좋다, 서태지가 우리나라 랩의 시초가 아니라고도 할 수 있겠으나, 서태지가 랩댄스의 시초라고 한다면 여기에는 누구나 동의할 것이다. 랩댄스, 랩과 댄스가 한 부류이던 그 시절을 서태지가 불러온 것이다. 대중은 아무런 준비도 없이 김진표와 드렁큰 타이거를 맞이할 수 없다. 우선 댄스처럼 즐기고 익숙해지고 나면 컴백홈도 나오고 하는 것이지.
이 당시의 랩댄스는 천편일률적인 유행가일 뿐이라고 생각했지만, 사실 2020년이 다 되어 세계에서 사랑받는 KPOP은 결국 정통힙합도 아니고 정통락도 아니고 랩과 댄스가 어우러진 바로 요 랩댄스 음악이다.

그리고 가장 중요한 것, 다양성과 파격성이다. 서태지 이후 실험적이고 다양한 음악이 90년대 초중반을 수놓았다. 그리고 음악성과 개성을 중요시했던 그의 팬들은 나중에도 파격적이고 실험적인 음악을 하는 많은 아티스트들의 후원자가 되었다.

서태지 이후 2018년 지금까지 대한민국의 가요계는 서태지가 남긴 유산에서 자유로울 수 없었다. 서태지 바로 직후였던 HOT는 더더욱 그랬다.

HOT

90년대는 HOT 이전과 이후로 나눈다. HOT는 서태지와 아이들을 단번에 구세대로 만들었다. HOT 이후의 댄스 가수들은 이전보다 더욱 획일화되었다. 당시에는 이런 유머가 있었다.

요즘 나오는 애들 공통점
1. 격렬한 음악에 맞춰서 다같이 똑같은 군무로 춤을 추다가
2. 한 놈이 나와서 시끄럽게 랩을 한다
3. 또 한 놈이 나와서 인상을 쓰면서 랩을 한다.
4. 후렴에는 항상 이쁘장한 애가 나와서 노래를 한다.
5. 마지막에는 다같이 자빠지면서 끝난다.

하두 그놈이 그놈 같아서 어른들이 ㅉㅉ 혀를 차던 시절이었지.

이 시절 음악을 관통하는 키워드 중 하나는 사회비판이다. 랩 처음 시작하는 사람들이 이유없는 분노를 멋으로 생각하듯, 이 때는 사회비판이 그냥 유행이었다. HOT는 당연했고, 베이비복스같은 그룹도 민주주의가 어쩌구 저쩌구 하는 가사를 담았었다.

그리고 패션에도 문제가 좀 있었는데, 가수가 아니고서 평상복으로는 절대 입을 수 없는 옷이 유행이었다. 빤짝이 재질의 힙합바지.

이 모든 것을 유행시킨 시작은 역시 HOT다.

HOT가 해체되자, 오히려 가요계는 황금기를 맞이하여 다양한 음악의 천국이 된다. 그냥 막 떠올려봐도 패닉, 이정현, GOD, 자우림, 체리필터, 크라잉넛, 거북이, 고요테, 1TYM, MC 스나이퍼, 돌아온 서태지 등등등.. 다양한 음악이 판을 치고 이박사를 필두로 엽기 유행까지 불면서 대단한 난장판이었던 시절이었다.
그래도 이 시절 1등 메타를 꼽으라면 역시 테크노... 라는 탈을 쓴 뽕댄스다. 댄스 비트 위에 트로트 멜로디를 얹어서 노래방에서 신나게 부르기 좋은 노래들이 단연 유행이었다.

SG 워너비

이 모든 난장판을 끝낸 것이 SG 워너비다. 아.. 개인적으로는 이 시절을 굉장히 싫어한다. 하필 이 시절에 군대를 다녀왔는데, 이 때 선임들이랑 노래방 가면 죄다 미친 발라드만 불러 ㅋㅋ

워너비 이전 시절이 자극적이고 다양한 음악이 유행했다면 워너비 이후로 다시 가수와 노래 중심의 가요계로 재편된다.
이 시절 가요는 발라드가 아니다. 이거슨, 뽕짝 + 소몰이와 미디엄템포다. 개나 소나 소를 몰고 다니던 시절, 투탑은 역시 박효신과 환희. 그리고 MC THE MAX, 그리고 버즈. 서태지 이후 멜로디가 가장 사랑받던 시절이다.

이 시절 가요는 특히나 쉽고 간단하다. 90년대 발라드의 고급스러운 전반부는 모두 사라지고 한 소절만 끝나면 바로 후렴으로 뛰기 일쑤였다. 김동률, 윤미래가 보여주던 복잡한 리듬도 온데간데 없다. 심심한 멜로디의 빈 공간은 미디엄 템포로 채우고, 부족한 가창력과 감성은 소몰이로 채운다. 편곡은 천편일률적이고, 멜로디도 곡구성도 죄다 비슷하다. 배우기 쉽고 따라부르기 쉽고, 감정이입이 간편하다.

이 모든 특징은 트로트와 똑같다. 그리하여 과거 트로트가 가졌던 지위를 대신 가져갔다. 지금도 드라마 OST는 이때 만들어진 음악을 쓰고 있다. 싸고 좋은 음악으로서 지금도 많은 사랑을 받고 있다.

빅뱅

대 멜로디 시대를 끝내고 일렉트로의 바람을 불러온 그룹이 바로 빅뱅이다. 이들은 가요계의 중심을 다시 10대로 가져왔고, 아이돌의 시대를 재시작했다. 전 세계적으로도 신스기반의 전자 음악이 다시 유행을 타고 있었다. 이 흐름을 가요계에 잘 가져왔다고 본다.

서태지가 트로트의 시대를 끝냈듯이 빅뱅은 앞서 말한 통속 가요의 시대를 끝냈다. 이것만으로도 충분히 손에 꼽을 이유가 된다.

이들의 음악을 뭘로 정의할까. 내 기준에는 그냥 랩댄스 음악이다. 랩으로 시작해서 노래로 끝나는 전형적인 가요. 대신 90년대보다 훨씬 세련된 음악과 패션과 이미지를 들고 왔다. 머리 꼬라지라든지 옷이라든지 볼 때 90년대와는 비교할 수 없을 만큼 세련되어졌고 음악도 더 성숙해졌다.
빅뱅은 새천년의 과도기를 지나 새로운 21세기 댄스그룹의 롤모델을 제시했다. 비스트, 엑소, BTS에 이르기까지 이들이 세워놓은 개념에서 크게 벗어나지 않는다. 음악에도 스타일에도, 그리고 얼굴 생김새에도 지대한 영향을 행사했던 대단한 그룹으로 기억될 것이다.

한편 빅뱅 이전에 동방신기가 있었는데 사실 그들이 한국 가요에 미친 영향력은 이유야 어찌됐든 결과적으로 크지 않았다. 동방신기는 지금의 아이돌보다는 오히려 과거 유행했던 엔싱크라든지 백스트리트보이즈와 같은 컨셉이었다.

2NE1

마지막으로 소개할 그룹이다. 걸그룹을 유행시켰던 할머니를 꼽으라면 당연히 소녀시대와 원더걸스겠지만, 물론 그들의 스타일도 한때 큰 유행이었지만, 가요계의 큰 흐름을 바꾸고 후대에 가장 큰 영향을 준 그룹이라면 역시 2NE1이다.

2NE1 하면 떠오르는 키워드 두 가지는 실력과 개성이다. 2NE1을 기점으로 해서 드디어 얼굴만 예쁘고 아무것도 못하는, '가수 아닌 가수'들의 생명력이 끝난다. 대신 못생기고 노래 잘 하는 가수들이 인정받고 메이저가 된다. 이효리의 시대가 가고 옥주현의 시대가 온 것이다.
CL보고 이쁘다고 하는 말은 반쯤은 그저 응원이나 팬심이 만들어낸 거짓말이다. 하지만 그게 문제가 아니라 나머지 반이 더 중요하다. 나머지 반, 반쯤은 진심이라는 것이다. 미의 기준을 다시 세우고 멋있고 세련된 워너비가 뭔지를 확실하게 보여줬다.

물론 이 모든 것이 2NE1으로부터 나온 것은 아니겠지, 당연히. 나는 가수다, 슈퍼스타K등 오디션 프로가 실력이라는 것에 집중하도록 만들었고, 브라운아이드걸스나 기타 노래 잘하는 가수들이 열심히 활동해온 것도 사실이다. 야, 그렇게 따지면 서태지 말할 때도 언더그라운도 언급도 해야 되고, 그런 식이면 끝도 없다. 내가 말하는 것은 화룡정점, 확실하게 느낌표를 팍 찍은 사람이 누구냐 하는 것이지 뭐. 대중들의 인식을 단번에 바꾼 그룹이 누구냐!

2NE1을 밑거름으로 씨스타, 걸스데이, 마마무의 시대까지 이어지면서 테레비에 나오는 가수들의 실력이라는 것이 올라갈 만큼 올라가버렸다. 이제는 대중들의 귀가 하두 좋아져서 조금만 노래 못 부르면 다 알아채버린다.
90년대 가요랑은 아예 비교가 안 되는 수준이고, 앞선 걸그룹인 원더걸스나 소녀시대, 티아라만 놓고 비교해봐도 몇 배는 나아졌다.

2NE1의 음악적 영향이라면 과감한 일렉트로, 랩스타일의 변화라고 할 수 있다.
나쁜 기집애, COME BACK HOME, CAN'T NOBODY 와 같은 곡들 보면 매우 과감한 비트와 일렉트로 음향이 섞여 있는데, 이런 것들을 대중에게 거부감이 없도록 유행시켰다. 이로 해서 더 다양하고 세련된 음악이 사랑받을 수 있는 토대를 만들었다. 대한민국 가요는 더 이상 기승전결의 멜로디나 뻔한 곡 구성으로 정해지지 않게 되었다. 얼마든지 개성있고 실험적인 음악이 메이저에 올라올 수 있게 된 것이다.
CL의 혀꼬부라진 랩은 당시에는 놀림감이기도 했다. 옛날에 2NE1 기사에 베뎃으로 올라간 댓글에는 "갈만큼 가궸쥐 오눌봠도 길궸쥐 분위기 타겠쥐 줠줠똬롸 월퉤쥐~ " 이렇게 랩 스타일을 비웃는 것도 많았다. 그러나 지금은 당연한 문법이 되었고, 지금 쇼미에 나오는 애들도 다 이런 랩만 한다. 2NE1이 이런 스타일을 퍼트리는데 1등공신이었다.

후대에 미친 영향과 별개로 2NE1의 음악특징 하나를 꼽으라면 모던락 감성이다. 가장 먼저 떠오르는 가수가 바로 마룬5. 전세계적으로 유행하는 멜로디 스타일 을 잘 채용해서 자칫 부족할 수도 있는 감성적인 느낌을 잘 메꿨다.


----

어떻게 해서 소방차가 BTS로 바뀌었나. 그 30년동안 끊임없는 변화와 가치를 만들었던 뮤지션들이 있었고, 그와 동시에 대중들도 엄청난 성장을 했다. 이제 우리나라에는 좋은 음악을 골라들을 줄 아는 고급귀가 널리고 널렸다.
축구에서도 자국 리그가 잘 되야 하는 것처럼 KPOP도 홈그라운드에 좋은 관중을 두고 있어서 해외에서 잘 나가는게 아닌가 싶다.

Read More

손 글씨 잘 쓰는 법

나는 어렸을 때부터 악필로 대단했다. 커서도 잘 고쳐지지 않다가 스물 후반이 다 되어서야 어느 정도 교정이 되었는데, 그제서야 필기에 흥미를 느낀 탓이다.

지금도 글씨를 잘 쓰는 편은 아니지만 대충 가지런하게는 쓸 수 있다. 악필에서부터 어떻게 벗어났는지 살짝 노하우를 공개하고자 한다.

우선 인간이 왜 글씨를 못 쓰게 되는가? 부터 생각해보자. 내 경우에는 글씨 쓰는 것 자체에 흥미를 느끼지 못했다. 모든 숙제고 글쓰기고 몽땅 귀찮다. 굳이 잘 써야 할 이유도 모르겠고. 그런 상태로 고등학교까지 졸업하고 나면 거의 평생 악필이 된다.

악필을 벗어나는 데는 단순한 연습량보다 중요한 것이 있다. 악필이라고 글씨 쓰는 횟수가 적은 것이 아니다. 문제는 글씨를 쓰면서 모양에 집중을 하지 않으니 아무리 글씨를 많이 써봐도 소용이 없는 것이다. 어떤 모양으로 글씨를 써야겠다는 목표가 우선 있어야 하고, 그 목표를 위해 천천히 차분하게 쓰는 연습을 해야 한다. 그러므로 글씨 모양에 관심과 흥미를 가지고 집중할 수 있도록 해야 한다.

흥미를 유발하는 가장 좋은 방법은 적절한 난이도와 적절한 보상이다. 그러므로 이 포스팅에서는 아주 간단히 몇 가지만 신경쓰면 바로 글씨가 달라질 수 있도록 팁을 소개한다. 한 번 예쁜 글씨에 재미를 붙이고 나면 그 뒤로는 스스로 잘 쓸 것이다.

무턱대고 글씨 예쁘게 써라, 또박또박 써라 하면, 쓰는 사람으로서는 참으로 막막하다. 그냥 또박또박 힘주어서 쓰면 자동으로 글씨가 예뻐진단 말이냐? 절대로 그렇지 않다. 사실 우리는 초등학교 때, 글씨 쓰는 요령을 다 배운다, 그런데 너무 많이 배우는 것이 문제이다. 모든 규칙을 다 지키면서 정자로 쓰는 건 너무 어렵다. 흥미를 가지기도 전에 너무 어려우면 안 된다. 

1. 정자체

고전적으로 내려오는 필기체 방식으로서 방금 언급했던, 교과서에 나오는 글씨 쓰기 방법이다.
대략 이런 식..

가장 단정하면서도 자연스러운 필기가 가능한데.. 구도가 복잡하고 정해진 모양들이 있어서 배울게 많고 연습도 어렵다. 자음을 작게 써야 하기 때문에 굵은 연필로 연습하는 것도 쉽지 않다.

이 필기에 첫 발을 내딛으려면 우선 다음 사항을 신경써보자.

  1. 세로 획의 시작점을 맞춘다.

  

2. 삼각형 모양에 주의하자.

  3. 그리고 가로 폭을 일정하게 맞춘다.

우선 이렇게 세 가지만 집중해서 연습해보자. 세 가지도 너무 어렵다면 첫 번째, 세로획의 시작점을 맞추는 연습, 딱 한 가지만 열심히 해도 글씨는 금방 좋아진다.

2. 인쇄체

인쇄체란 말은 내가 만들었다. 컴퓨터나 인쇄물에서 흔히 볼 수 있는 형태라는 뜻이다.

이 글씨의 특징은 사각형을 빈틈없이 채우는 것에 있다. 마치 한문처럼 글자가 들어가는 사각의 영역을 빈틈없이 채우는 것이다. 이 글쓰기를 연마할 때는 단 한 가지만 집중하면 된다, 네모재기에 글씨를 꽉꽉 채워서 쓸 것. 여기서 핵심은 자음인데, 초성도 크게 쓰고, 밭침도 가로로 넓게 써야 네모를 다 채울 수 있다.

이 글씨를 연습하다 보면 자연스럽게 글자 크기가 동일하게 맞춰진다. 글자에 대한 구도 역시 특별하게 설명하지 않아도 자연스럽게 잡혀진다. 무엇보다 쉽다. 어려운 구도와 모양을 생각해야 하는 정자체에 비해서 아무런 배움 없이도 그냥 시작할 수 있는 것이 바로 이 인쇄체이다.

문제는 생각보다 이쁘지 않다는 것이다. 네모에 글자를 잘 채워넣었다고 해서 당장 글씨가 예뻐지지는 않는다. 빠르게 필기할 때도 부자연스럽다.



3. 광수체

그냥 광수체로 부르기로 했다, 나 혼자. 이런 류의 글꼴 중에서는 광수체가 제일 유명하기 때문에.

핵심은 모든 자모를 똑같은 크기로 쓰는 것이다. 글씨 구도고 나발이고 다 때려치고 똑같은 크기로 쓰는 연습만 하면 된다. 매우 설명이 쉽고 간편한 반면에 글씨 예쁨의 향상은 완전 드라마틱하다. 누구나 하루만 투자하면 예쁜 글씨를 금방 쓸 수 있기 때문에 빅추천. 그리고 왠지 귀엽기 때문에 또 추천.

그리고 애초에 또박또박 쓸 수 밖에 없어서 의외로 가독성이 뛰어나다. 아래와 같이 개발 새발 써도 뭔 글씨인지는 일단 알아본다.

쓰는 속도도 빠르고 간편한데 가독성도 좋기 때문에 논술고사용으로도 좋다.

중요한 부분! 앞서서 정자체는 맨 위의 부분을 맞췄는데 여기서는 세로 방향으로 중앙을 맞춰야 한다. 어쩐지 나는 못 맞춘 것 같다...

잘 연마하면 자기 스타일에 따라 다음과 같이 변형도 가능하다.

나는 잘 못하지만 연습하는 사람에 따라서는 귀욤귀욤 글씨체로 넘어갈 수도 있겠다. 모든 자모를 똑같은 크기로 하지 않고 ㄹ이나 ㅂ을 크게 쓴다든지 하는 변형을 하기 시작하면 점점 예술의 영역이 된다. 실제로 여러 캘리그래피를 보면 글자의 균형이ㄱ 맞지 않고 크기가 제멋대로이다.

모든 사진 예는 내가 직접 쓴 것인데.. ㅋㅋ 너무 못 써서 부끄럽지만 한 때는 최악의 악필이었다는 점을 감안해주시길 바라며... 본인도 글씨를 못 쓰면서 이런 포스팅을 할 자격이 있느냐? 그래도 말하고자 하는 바는 어쨌든 간단한 목표가 있으면 그 때부터는 글씨 쓰기가 재미있어진다는 것이다! 그리고 실질적으로  글씨가 개선된다.



----


요렇게 마치고 부록으로 글씨에 대해 조금만 더 덧붙이고자 한다.

피지컬적인 요소는 어떨까? 기타나 피아노를 칠 때도 손가락의 힘과 유연성을 기르기 위해 노력하는데 필기에도 그런 연습이 필요하지 않을까?

피아노의 하농처럼 피지컬만 기르는 방법이 있다. 손목과 손날을 바닥에 붙인 채로 직선을 그어본다. 긋는 방향은 360도 방향을 다 해본다. 좌에서 우로 해봤으면 우에서 좌로도 해본다. 대각선 방향이나 30도 방향 등 모든 각도로 다 해보면 직선이 어려운 방향이 있을 것이다. 이 방향으로 왔다갔다 그려보기만 해도 금방 손가락 근육에 피로가 오면서 훈련이 된다.

대부분 어릴 때 처음 글씨를 배우게 되면 손가락에 힘이 없고, 손가락 근육은 컨트롤도 쉽지 않다. 그래서 글씨를 손가락으로 쓰지 않고 그저 연필을 꽉 쥔 뒤, 손목이나 팔로 글씨를 쓴다. 탁구나 테니스 운동을 제대로 배워보면, 스윙 동작에서는 미세한 손목이나 손가락을 쓰는 것이 아니라 허리, 어깨 등 큰 근육을 쓰는 것부터 배운다. 작은 근육보다 큰 근육이 컨트롤이 쉽고 힘이 세기 때문이다.

여러 글씨 교정 학원에 가면 연필 쥐는 법과 바른 자세부터 가르친다. 우리가 아는 일반적인 바른 자세는 큰 근육이 아니라 미세한 손가락 근육을 활용하게 된다. 손가락 쓰기에 능숙하면 필체를 바꾸기도 편하고 유연한 글쓰기가 가능하다.

글씨의 예쁨이라는 것은 크게 구도의 아름다움과 획의 아름다움으로 나뉜다. 위에서 제시하는 팁은 주로 구도의 아름다움을 얘기하고 있다. 획은 개개인의 개성이 너무 강하니까.

어떤 글씨가 예쁘게 보이는가? 결국 일정하게 쓴 글씨가 예쁘다. 가끔 개발새발 휘갈겨썼는데도 멋있게 느껴지는 글씨가 있다. 획은 개판으로 그렸어도 구도가 예쁘기 때문이다.

Read More

git 튜토리얼 (1)

들어가면서

Git을 자주 쓰는 사람들은 Git이 대세라고 확신할테고, 심한 경우에는 "요즘 Git도 안 쓰고 개발이 되냐"고 말하기도 한다. 그러나 아직 많은 사람들이 Git에 손을 못 대고 있거니와, 쓰더라도 자세히 모르고 그냥 쓰는 경우도 많다.

Git의 장점은 그냥 강력하다는 것이고, 단점은 개발의 핵심도 아닌 도우미 프로그램 치고는 너무 복잡하다는 것이다. 여기서 한 가지 위안거리가 있는데, Git의 기능 중 한 가지라도 배우면 그건 반드시 유용하게 써먹게 된다. 강력하고 어려운데 쓸데없다면 그게 왠 똥인가 말이다. 그런데 Git은 최소한 다 쓸모있다. 배운만큼 써먹자.

형상 관리 프로그램

형상관리 프로그램을 사용하지 않으면서 버전 관리를 할 수 있는 대표적인 방법은, 프로젝트 통째로 zip으로 압축하고 이름에 날짜를 적어 보관하는 것이다. 과거의 코드를 보고 싶으면 특정한 날짜의 압축을 풀어서 확인하면 된다. 매번 중요한 순간마다 zip으로 압축하는 것이 git에서 커밋(commit)이랑 똑같다.

커밋이란 말은 앞으로 자주 쓸 텐데, 지금은 소스 코드에 대한 청사진, 혹은 스냅샷 정도로 생각하면 좋다. 그냥 소스코드 버전으로 생각해도 된다. 특별히 결정적인 순간마다 저장해서 나중에 두고두고 꺼내보고 비교해볼 수 있다. 한 번 커밋한 내용은 원칙적으로 수정이 불가능하다.

형상관리 프로그램을 이용하면 매번 zip으로 압축해서 소스 코드를 보관할 필요가 없다. 대신 커밋으로 빠르게 코드를 보관하고 복원할 수 있다. 여러 사람이 작업할 때도 간편하게 버전을 관리할 수 있다. 버전 간의 차이점을 확인하고 싶을 때도 편리하게 툴을 이용할 수 있다.

SVN과 차이점

SVN에서는 모든 소스 버전 정보를 서버에서 관리한다. 프로그래머는 서버에 접속해서 특정한 버전의 커밋을 다운받고 편집한 뒤 새 버전으로 서버에 커밋한다. 반면에 Git은 모든 정보를 서버로부터 카피(clone)해서 로컬에 저장한다. 커밋도 로컬에서 한다. 서버와는 단지 sync를 맞출 뿐이다.

SVN이 웹메일이나 클라우드 컴퓨팅처럼 동작한다면, Git은 Google Drive처럼 동작한다.

Git과 GitHub

  GitHub는 Git으로 생성된 저장소를 운영하는 사이트이다. 기존 Git에 사용자 관리, 이슈 관리, 웹 소스 편집 등 기능을 붙여서 만들었다. GitHub 이전에 오픈 소스의 성지로 불리던 곳은 SourceForge인데 SVN으로 운영된다. 사람들은 SourceForge를 즐겨 이용하면서도 한 편으로는 자신만의 저장소를 만들고 싶어했다. 왜냐하면 SourceForge가 없어질 경우 모든 관리 데이터를 잃어버리기 때문이다. 이것은 모든 계란을 한 바구니에 담는 것과 마찬가지이다. 그래서 Google이나 Microsoft 등 굴지의 회사들은 SourceForge 이외에 자신들만의 저장소를 만들어서 운영하고자 했다. 그런데 GitHub가 나타나면서 모든 고민은 사라지고 GitHub 세상이 됐다. 이 세상 거의 모든 오픈소스 프로젝트를 GitHub에 담으면서도 사람들은 예전처럼 불안해하지 않는다. 서버와 동일한 관리 정보가 바로 자신의 컴퓨터에 있기 때문이다.

GitHub를 사용하면서도 한편으로 얼마든지 자신만의 서버를 만들어서 모든 내용을 GitHub와 공유할 수 있다. 로컬 컴퓨터의 내용을 두 군데 서버와 동시에 싱크를 맞추면 그만이다.

도우미 GUI  프로그램

Git은 기본적으로 command line으로 동작하게 만들어졌다. 윈도우 95가 나오면서 GUI 혁명이 이뤄진지 20년이 훨씬 지나가지만 아직도 command line방식을 고수하고 있는 프로그램이 있는데 Git 또한 그렇다고 하겠다.  이를 참다 못한 사람들이 Git API를 이용해서 GUI로 만들어놨다. 이것들은 사용하면 좋긴 한데, 자칫 Git에 대해 오해한 상태에서 계속 쓸 여지도 있다. 하여 우선 본 튜토리얼은 command line으로 진행하고, 나중에 GUI 프로그램도 살펴본다. 핵심 내용만 짚으면 별로 복잡한 명령어도 없다.

지금부터 튜토리얼 시작

이제 진짜 시작이다.

GUI 프로그램을 활용하면 쉬워보이기는 하는데 핵심적인 원리와 내용을 설명하기가 어렵다. 그래서 우선은 커맨드 라인으로 진행하고, 나중에 GUI도 설명할 계획이다. 사실 커맨드 라인으로 다룰 줄 알게 되면, GUI 프로그램은 자동으로 그냥 사용법을 이해하게 된다. 진짜, 뻥 아니고.

위에서 잠깐 언급했듯이 Git은 기본적으로 서버 없이 로컬에서 돌아가는 프로그램이다. 만약 혼자 간편하게 소스코드를 관리할 목적으로 git을 사용한다면 GitHub도 필요 없고, 서버도 필요없이 간단하게 Git만 설치하면 된다.

모든 설명 과정은 윈도우 사용자 기준으로 진행된다. 리눅스 사용자들은 아무래도 알아서 잘 하는 습관이 되있을테고 이런 설명도 필요 없겠지.

Git을 설치하는 방법에는 여러 가지가 있는데, Visual Studio를 설치하다 보면 같이 번들로 설치되기도 한다. 어쨌든 가장 보통의 방법은 직접 다운받는 것이다. 대뜸 깃허브로 들어가면 다운 못 받는다. 거기는 git서비스를 제공하는 곳이고 https://git-scm.com 으로 들어간다. 첫 화면에 바로 다운로드 버튼이 보인다.

설치 과정 중에 default editor를 선택하게 된다. git에서 왠 에디터냐? 파일끼리 병합하고 어쩌고 하는데 에디터가 필요하다. 사실 여기 튜토리얼을 진행할 때는 별 필요가 없으므로 일단 적당히 아무거나 선택하고 넘어가자.

나머지는 그냥 대충 Next를 눌러도 상관이 없을 것 같다.

자, 이제 Git을 시작해보자. Git은 데이터베이스가 필요없다. 모든 소스 관리 정보를 소스코드가 들어있는 그 폴더 속에 저장한다.

커맨드 창(Command Prompt)을 띄우고 대뜸 git이라고 입력해보자.

아무 내용이나 막 나오면 일단 잘 깔렸다. 방금은 git.exe라는 프로그램을 실행한 것이다. 앞으로 이것을 git 프로그램이라 부르겠다.

이제 소스 코드가 들어있는 폴더로 이동한다. 이미 소스 코드가 들어있어도 상관없고, 빈 폴더에서 시작해도 좋다. 어쨌든 폴더로 가야 하는데, 커맨드 입력이 서툴면 아래 그림을 참고한다.



하여튼 드라이브를 옮길 때는 X: 와 같이 콜론을 이용하고, cd 명령어를 통해 폴더로 들어간다. 폴더에서 나오려면 "cd .." 을 입력하면 된다.

우선 나는 빈 폴더를 만들어서 시작할 것이다. 최초의 저장소를 생성하는 명령어는 git init이다. 앞서 말했지만 git init명령은 반드시 빈 폴더에서 할 필요가 없다. 이미 잘 돌아가고 있는 소스를 Git으로 관리하고 싶을 때도 그 시작은 git init이다.

명령이 실행되고 나면 .git 이라는 숨김 폴더가 생성된다. 리눅스에서 '.'으로 시작하는 이름은 무조건 숨김 속성이 되는데, 윈도우에서는 Hidden속성이 따로 부여된다. 폴더 내에 .git 폴더가 있으면 그것은 git으로 관리되는 폴더라고 할 수 있다. git프로그램은 반드시 .git폴더가 보이는 곳에서 실행해야 한다.

.git 폴더에는 Git 관리 정보가 다 들어간다. SVN으로 따지면 서버에 저장되어야 할 모든 정보들이 .git 폴더에 저장되는 것이다. 당연히 용량이 상당한데, 보통 관리되는 소스코드의 1/2 정도 크기이다. 나름의 방식으로 압축이 된다.

Git으로 관리되는 소스 코드를 카피할 때, .git 폴더만 카피해도 된다. 모든 커밋 정보가 .git 폴더에 들어있기 때문이다. 실제 소스 코드는 .git속에 들어있는 커밋을 이용해서 복원하면 그만이다. 서버에서 소스를 다운받을 때(clone) 실제로는 .git 폴더를 다운받는다.

현재 저장소의 상태를 확인하는 명령어는 git status이다.

뭐라고 영어로 나오는데 뭔 말인지 하나씩 살펴보자.

On branch master => 현재 branch를 나타낸다. 지금은 branch를 소스코드의 어떤 갈래, 분기점이라고 이해하자. branch가 아예 없으면 안 되니까 기본으로 하나 생성해주는데, 그 이름이 master이다.

No commits yet => 아직 아무 커밋도 없는 백지상태이다.

nothing to commit => commit할 파일이 없음을 나타낸다. 마지막 커밋과 비교해볼때 내가 작업한 내용이 없다는 뜻이다.

이제 이 폴더에 아무 작업이나 해보자. 여기서는 file.txt를 만들고 아무 내용이나 넣어보자. 기왕이면 두 개를 만들자.

이제 git status 를 다시 입력하면 다음과 같이 나타난다.

Untracked files 라는 문구가 있다. 처음 보는 파일, 혹은 관리되지 않는 파일이라는 뜻이다. 소스 코드 내의 모든 파일은 매 커밋 때마다 변화를 추적하는데, 이 파일은 아예 첨 본다는 뜻이다.

이제 새로 만든 파일을 커밋할텐데, 그러려면 파일을 스테이지에 올리는 작업이 필요하다. 이게 무슨 말이냐? 수정된 파일이 엄청 많은데, 그 중에서 필요한 파일만 꼭 커밋하고 나머지는 임시로 만든 것이니 그대로 두고 싶을 수 있다. 그럴 때 필요한 파일만 스테이지에 올려서 커밋하고, 나머지는 그대로 둔다. 대체로는 소스를 빌드해서 생긴 exe파일이나 기타 임시 파일들은 커밋하지 않고 소스 파일만 커밋한다.

여기 예제에서는 file.txt를 커밋하고 싶으니 이것만 스테이지에 올린다. git add 명령을 이용한다.

스테이지에 올라간 파일은 커밋 대기 상태가 되며, 이 순간 파일의 내용은 임시로 저장된다. 만약 파일이 너무 많으면 "git add --all"로 모든 언스테이지 파일을 스테이지에 올릴 수 있다. 참고로 별표(*)를 이용하는 것도 가능하다.

스테이지에 파일을 올렸는데 지우거나 수정하면 어떻게 되나? 직접 해 보면 안다.

스테이지에 올라간 상태를 기점으로 해서 변경된 내용은 언 스테이지 상태가 된다. 만약 이 상태로 커밋하면 스테이지에 올릴 당시 저장되었던 file.txt의 내용이 커밋된다. 하여튼 스테이지에 올린다는 것은, 커밋할 내용을 고르기 + 임시로 저장하기 정도로 생각하면 된다.

만약 스테이지에 올리고 수정 후 또 올리고 .. 를 반복한다면 ? 스테이지가 여러 개 생기느냐? 그건 아니고 그냥 하나의 스테이지가 계속 누적되어 유지된다.

하여튼 원점으로 돌아와서 file.txt를 다시 만들고 add 명령으로 재차 스테이지에 올렸다, 치고. 이제 진짜 커밋을 해보자.

대충

git commit -m "첫 커밋이다!"

라고 입력하면 아래와 같이 뜬다.

이게 뭔 말이냐, 이메일과 이름이 없다는 뜻이다. 커밋할 때는 작성자, 이메일, 메시지(설명), 이 세 가지 정보가 무조건 들어가야 한다.

그러므로 다음과 같이 입력하면 커밋이 되긴 된다.

git commit -m "첫 커밋이다!" --author="myname <myemail@aaa.com>"

여기서 잠깐, 이름과 이메일은 아무거나 넣어도 되나? 네. 그렇다. 깃허브에 올릴 때도? 아 물론이죠. 이름과 이메일을 남기는 것은.. 사실 그냥 주석의 연장선으로 보면 된다.

다만 GitHub를 이용할 경우, 왠만하면 GitHub에서 쓰는 아이디를 넣어주는 것이 좋다. 나중에 연동되는 기능이 있기 때문이고, 그냥 보기에도 좋기 때문이다. 여러 개의 저장소를 동시에 쓴다면? 아 몰랑..~ 이름 여러 개는 넣을 수 없으니 그땐 뭐 알아서 하는 거지.

하여튼...

매번 이름과 이메일을 넣기 귀찮으니 global 속성으로 정해줄 수 있다. 위의 캡쳐 화면처럼 따라서 입력하면 된다. 좀 길지만 한 번만 하면 되는 거니 참자.

그러고 나서 다시 git commit -m "메시지" 를 입력하면 대망의 커밋이 된다.

git status를 입력하면 아까 초록색으로 스테이지 됐던 것이 사라졌다? 어디갔어? 커밋했으니까 이제 없지. 대신 빨간색 언스테이지 파일은 그대로이다. 이제 git log를 입력해보자.

git log를 입력하면 현재까지의 모든 커밋을 쭉 볼 수 있다. 길어질 경우 나가는 키가 'q'다. 자.. 근데 한글이 깨져 있다! ㅜㅜ 해결 하는 방법이 아예 없는 것은 아니지만 괜히 인코딩만 더 꼬일 수 있으므로 그냥 두는게 좋다. 어차피 GUI 툴을 쓰면 다 해결된다.

.
.
.

다음 튜토리얼에서는 커밋을 실용적으로 활용하는 예 - 수정된 부분 확인, 분기, 병합 등을 해볼 것인데.. 과연 안 귀찮을 수 있을지..

Read More

영어 비슷한 한국 발음 랩, 노래 잘 하는 법, 해외파 흉내내기!

이런 비법도 내가 소개할 줄 몰랐다.

옛날에 2004년도인가 군대에 있을 때 한참 타블로가 잘나갈 때, 한 선임이 말했다. 얘네 발음에 너무 미쿡물이 많이 들었다. 근데 듣기 좋다. 그 때는 몇 몇 가수들 뿐이었는데 나중에 보니깐 씨엘이고 뭐고 전부 발음을 굴리는게 유행이 됐다.

'조 프룬 뷜딩위로우~'

그 때는 저렇게 랩 하는 거 따라해볼래도 잘 안 됐는데 지금은 어떻게 하는지 안다.

혀 끝을 아랫니에 살짝 댄다. 그리고 절대 떼지 않고 노래든 랩이든 하면 된다.

ㅋㅋㅋㅋㅋㅋㅋ

원래 영어 발음이 대부분 혀끝에서 이루어진다.

이제부터 당신은 교포 2세 해외파~

Read More

우분투에서 C++ 개발하기 (1) - 컴파일 과정 및 gcc

이 글은 윈도우에서 Visual Studio만 쓰다가 Ubuntu를 생소하게 생각하는, 나와 같은 사람을 위해 쓴다.

글쓰기에 들어가기 전에 Visual Studio와 같은 통합 환경에 비해 리눅스에서 C++과 같은 언어를 개발한다는 것이 얼마나 복잡한 일인가부터 상기시켜야겠다. C++ 자체가 원래 언어차원에서부터 빌드가 영 까다로운 부분이 있다. 리눅스 사용자는 그 문제를 그대로 정면으로 맞이해야 한다.  그나마 편리하게끔 만든 것이 3편에서 나오는 CMake 정도인데, 이것마저도 복잡한 스크립트를 직접 입력해야 한다.

자유롭고 오픈될 수록 불편하고 복잡하다. 자유도가 높다는 것은 그 자유를 누릴 수 있을 수준으로 공부와 노력을 들여야 겨우 좀 사용할만하다는 뜻이 된다. 

하여튼 글 쓰기의 계획은 이렇다.

1. 맨 땅에 삽질하는 심정으로 g++컴파일러를 직접 이용해본다.
2. makefile을 이용해본다.
3. CMake를 이용해본다.
4. vscode를 활용하여 개발환경을 구축해본다.

그 첫번째, 맨 땅에 삽질하기.

1. C++의 컴파일 과정

VS만 쓰다보면 컴파일러 개념이 희박해지는데, 이는 당연한 것이다. VS라는 훌륭한 툴이 있기 때문에 우리는 아무 것도 신경 안 써도 된다. 원래 정치 선진국일수록 국민들이 정치에 무지하다. 그러나 리눅스를 제대로 이용하려면 컴파일에 대해서 좀 자세히 알아야 한다.

컴파일 과정을 모르는 사람을 위해 최대한 자세히 설명해본다.

컴파일 과정은 다음과 같다.

[소스코드] -> [바이너리] -> [실행파일]

소스코드는 사람이 읽을 수 있는 텍스트 파일이다. 이것을 컴퓨터 명령코드(기계어)로 번역하게 되는데, 이렇게 번역된 결과물을 보통 '오브젝트 파일', 혹은 '바이너리 파일'로 부른다. 두 명칭 모두 약간 애매모호한 점이 있어서 설명해본다.

우선 '오브젝트 파일'이란 말은 컴파일의 목적이 된다는 뜻에서 나왔다. 또 다른 말로 '타겟 파일' 혹은 '오브젝트 코드', '타겟 코드' 이런 말들로 불리는데 다 같은 말이다. 소스의 반댓말이 타겟 아니겠는가.

'바이너리 파일'란 말은 본래 '텍스트 파일'의 반댓말로서, 아스키 코드로 작성되어 텍스트로 읽을 수 있는 파일이 아닌 것들의 집합이다. 즉, 사람이 읽을 수 없는 파일이란 뜻이다. 소스코드는 사람이 읽을 수 있는 텍스트 파일의 일종이다. 반대로 기계어로 번역된-컴파일된 파일은 사람이 읽을 수 있는 텍스트 파일이 아니다. 이런 의미에서 컴파일된 결과물을 바이너리라고 부르는 것이다.

파일은 두 가지로 나뉜다. 프로그램과 프로그램이 아닌 것. 프로그램은 실행이 가능한 명령어로 구성된 것이고, 그렇지 않은 문서파일, MP3등은 프로그램이 아니다. 여기서 바이너리는 큰 의미에서 프로그램으로 봐야 한다. 얘기하다 보니 점점 산으로 간다.

하여튼 우리가 작성한 C++코드는 바이너리(프로그램)으로 번역된다. 바이너리는 여러 개일 수 있다. 그런데 이들은 바로 실행할 수 없다. 이들을 묶어서 OS가 실행할 수 있는 실행파일로 만들어주는 작업이 링크이다. 바이너리는 다시 말해서 프로시져(함수)들의 묶음이다. 이 함수들 중에 main이란 놈이 있다면, 이것을 시작점(엔트리 포인트)으로 해서 프로그램을 실행한다. 그래서 main 함수는 무조건 하나 있어야 하며, 한 개만 있어야 한다.

main이 없으면 바로 실행할 수는 없지만 라이브러리는 될 수 있다. 정적 라이브러리, 동적 라이브러리, 이런 친구들이 될 수 있다는 것이다. 이런 라이브러리들은 main이 없다.

결론적으로 컴파일 작업을 수행하는 컴파일러와 링크 작업을 수행하는 링커는 엄연히 다른 존재다. 그러나 보통 컴파일러라고 하면 링커의 기능도 들어있다.

2. 컴파일러 잡설, gcc

컴파일러는 소스코드를 기계어로 번역하는 작업을 한다고 했다. 그런데 우리는 한 가지 기계(컴퓨터, CPU)만 가지고 있는 것이 아니다.

재미삼아 미약한 지식을 동원하여 컴퓨터의 역사를 살펴보면 옛날에는 컴퓨터란 놈이 표준이 없고 우후죽순으로 각자 자기만의 컴퓨터를 개발해서 쓰곤 했다. 완전히 다른 컴퓨터들이었기 때문에 서로 명령어와 구조가 달랐고, 그래서 각자 컴파일러를 따로 가지고 있었고, 프로그램 호환도 전혀 안 됐다. 그러다 IBM에서 자신들의 CPU 아키텍쳐를 오픈하면서 시장을 거의 점령했고, 이 IBM 구조의 CPU 시장을 점령한 회사가 인텔, 그리고 AMD이다(약 80년대 후반부터). 이 IBM호환 기종에서도 약간 변종이 있는데, 80386 CPU 시절 개발된 x86(32bit) 구조, 그리고 AMD에서 개발한 x86-64(64bit) 구조가 있다. 현재는 이 두 가지 정도 쓰이고 있는데 점점 64bit로 점령되는 추세이다. x86시리즈는 대부분 윈도우 운영체제가 탑재되며 리눅스도 많이 쓰인다. MacOS도 x86으로 갈아탔다.

여기까지는 일반적인 데스크톱 컴퓨터의 얘기인데, 임베디드 - 소형화된 컴퓨터에서는 사정이 좀 다르다. 아직도 다양한 경쟁사들이 저마다의 CPU 아키택쳐로 경쟁하고 있는 형국이며, 그 중에서도 단연 1위는 ARM이다. 스마트폰에 들어가는 CPU가 대부분(내가 알고 있는 전부는) ARM으로 되어 있고 라즈베리파이도 ARM이다. 운영체제는 전부 리눅스(안드로이드)이다. ARM은 버전 6부터 시작해서 현재 8까지 나와있다. 

컴파일러는 CPU구조, 그리고 운영체제에 따라서 달라진다. 그 말인 즉슨, 프로그램을 하나 만들었을 때, 이 프로그램이 실행될 수 있는 CPU, 그리고 운영체제가 정해져 있다는 것이다. 

여러분들이 CPU를 하나 만들었다고 하자. 그러면 그 CPU를 동작시킬 수 있는 예제 코드가 필요할 것이다. 그리고 그 코드는 보통(100%) C언어가 된다. C언어로 Hello World를 만든 뒤, 이것을 내가 만든 CPU 명령어로 번역할 수 있는 컴파일러가 필요하다. 그래서 CPU를 만들면 반드시 컴파일러도 같이 만들어줘야 한다. 이 컴파일러 프로그램을 따로 만들어서 사람들에게 나눠줄 수도 있지만, 그냥 다들 컴파일에는 gcc를 쓰고 있으니, 내 CPU에 대한 컴파일 기능을 gcc에 추가한다.

gcc는 모든 리눅스에서 공통으로 쓰는 컴파일러 모음을 뜻한다. 더 멀리는 원래 GNU프로젝트를 시작하기 위해 만들었다는데, 알게 뭐냐. 하여튼 컴파일러 = gcc이다. gcc는 리눅스 운영체제위에서 실행된다는 가정아래 x86, x86-64, armv6, v7, v8 모두를 커버할 수 있다. 그 외에도 듣도 보도 못한 CPU까지 커버한다. 앞서 설명했듯이 모든 CPU 제조사가 gcc에 자기 CPU를 추가하기 때문이다. 아래 링크를 참고하자. 

https://gcc.gnu.org/install/specific.html

그래서 결론 : 컴파일러에는 gcc만 있는 것은 아니지만 그런데 gcc면 왠만큼 다 해결이 된다는 것이다.

크로스 컴파일이란 빌드 머신과 타깃 머신이 다른 경우를 말한다. 빌드 머신이란 현재 컴파일이 수행되고 있는 컴퓨터이다. 타깃 머신이란 컴파일 결과물이 실행될 컴퓨터이다. 안드로이드의 경우가 가장 대표적이다. 안드로이드 폰에서 돌아가는 프로그램을 안드로이드에서 개발하는 경우는 거의 없다. 휴대폰에서 엄지손가락으로 코딩하고 그걸 빌드하는 사람이 있겠는가? 보통은 리눅스나 윈도우에서 개발을 해서 apk까지 빌드하고, 이 파일을 안드로이드에 보낸다. apk가 실행되는 타깃머신은 안드로이드인데, apk를 만들어낸 개발 머신은 윈도우이다. 이런 경우를 가리켜 크로스 컴파일이라고 한다. 라즈베리 파이나 그보다 작은 소형 임베디드 보드는 거기서 직접 컴파일 하고 디버깅하고 어쩌구 하기가 매우 불편하니까 대개 크로스컴파일을 하게 된다.

그럼 자바, C#, 파이썬은 어떻게 동작하는가? 이들 언어는 동작하는 방식이 C와 꽤 다르다. 너무 산으로 가면 안 되니 생략.

g++은 gcc의 일부분으로서 C++언어의 컴파일러이다. 요즘 나오는 우분투에는 기본으로 깔려 있다. 여기서 재미있는 사실은 gcc는 C언어의 컴파일러인데 이건 C++로 만들었다. 마인크래프트에 보면 손으로 나무 깎아서 나무 곡괭이 만들고 그걸로 돌캐서 돌곡괭이 만들고 그걸로 철 캐서 철도끼 만들고 철도끼로 나무 캐고 그렇게 하듯이 컴퓨터 언어의 세계도 비슷하다. 포트란으로 C컴파일러 만들고 C컴파일러로 C++컴파일러 만들고 그걸로 다시 C컴파일러 만들고 그걸로 파이썬 만들고 파이썬으로 파이썬 컴파일러 만들고 ...

만약 gcc가 안 깔려있으면 깔아줘야 한다. 우분투에서는 C 언어 프로그래밍 개발에 필요한 것들을 패키지로 묶어서 배포한다.

$sudo apt install build-essential

요렇게 입력하면 gcc랑 make랑 cmake 등등 필요한 것들이 설치될 것이다.

3. 간단한 빌드

드디어 잡설을 끝내고!

본격적으로 개발에 들어가보자.

대충 폴더 하나를 만들고, 그 속에 main.cpp 파일을 작성한다.

<main.cpp>

#include <iostream>



int main()



{



    std::cout << "U**** F***** UBUNTU!\n";



    return 0;



}

다음과 같이 실행해본다.

g++ -c main.cpp #main.o 파일 생성

이렇게 하면 main.o 파일이 자동으로 생성된다. main.o는 앞서 말한 오브젝트 파일 : 바이너리다. 바이너리 파일은 바로 실행할 수 없다. 메인 함수가 물론 포함되어 있지만 그래도 곧바로 실행할 수는 없고, 리눅스가 실행할 수 있는 형식의 파일로 만들어야 한다.

g++ -o test main.o #main 파일 생성



./test #실행

main.o 파일이 바이너리 파일이고, 확장자가 없는 test 파일이 실행파일이다.

하나의 c/cpp 파일은 하나의 바이너리를 생성한다. 그런데 만약 파일이 여러개라면 어떻게 될까? 아래와 같이 파일을 만들어보자.

<my.h>

int myfunc(int val);

<my.cpp>

#include "my.h"



int myfunc(int val)



{



    return val + 1;



}

<main.cpp>

#include <iostream>



#include "my.h"






int main()



{



    std::cout << "calling up myfunc : " << myfunc(3) << std::endl;



    return 0;



}

이제 다음과 같이 명령어를 입력한다.

g++ -c main.cpp

컴파일러는 main.cpp파일을 들여다보고 my.h 파일을 현재 디렉토리에서 찾아낸다. my.h에는 myfunc에 대한 정의가 있으므로 컴파일에는 문제가 없다. main.o 파일이 생성된다.

g++ -c my.cpp

myfunc의 구현이 컴파일되어 my.o 에 담긴다. 이제 main.o와 my.o를 묶어서 test라는 실행 프로그램을 만들면 된다.

g++ -o test main.o my.o

이 실행의 결과로 test파일이 생성된다. 오브젝트 파일이 더 많을 경우에는 줄줄이 다 갖다 붙이면 된다.

여러 개의 바이너리 파일 중 main함수는 단 한개만 있어야 한다. 두 개 있거나 없으면 실행파일이 안 만들어진다.

이 쯤 되서 헤더파일이 무엇인지, 컴파일과 링크가 무엇인지 다시 한 번 생각해보자. 헤더 파일은 함수의 스펙을 적어놓는 것이다. myfunc 함수를 이용해야겠는데, 그 함수가 입력값이 어떤지 출력은 어떤 타입인지 알 수가 없다. 그래서 이 함수는 이렇소이다~ 하고 소개해놓은 것이 헤더파일이다. main.c에서는 헤더 파일의 정보만 보고 프로그램이 잘 돌아갈 지 생각해본다. 헤더에 의하면 입력은 int 한 개이고 출력도 int이다. 문법적으로 문제가 없으면 일단 OK, main은 컴파일이 가능하다.

컴퓨터 조립을 할 때, 부품을 하나의 공장에서 생산하지 않는다. CPU는 인텔에서 만들고 메인보드는 MSI에서 만들 때, 서로 통일된 스펙과 인터페이스만 맞춰놓고 각자 만든다. 나중에 컴퓨터 조립을 할 때, 각자 만든 부품을 연결해서 완성시킨다. 컴파일 과정도 마찬가지인데, 두 개의 바이너리가 각자 빌드된다(컴파일). 서로의 인터페이스에 대한 정보는 헤더파일을 참고한다. 나중에 링커를 통해서 그 둘을 연결(링크)하면 비로서 하나의 프로그램이 된다.

4. 라이브러리 참조

우리가 앞서서 #include <iostream> 이라고 작성했을 때, 무슨 일이 일어났는지 다시 생각해보자. iostream은 헤더 파일 이름이다. (확장자가 아예 없다.) 이 파일은 내 시스템 어딘가에 위치해 있는데, 보통은 /usr/include/c++/4.xxx/ 디렉토리에 들어있다. 본래 어떤 헤더 파일이든지 include 하려면 그 헤더파일이 들어있는 경로를 컴파일러에 알려줘야 한다. 하지만 왠만한 프로그램에서 다 쓰는 이런 스탠다드 라이브러리는 미리 디폴드 경로가 등록되어있다. 이것을 확인하고 싶으면 다음과 같이 명령어를 입력해본다.

g++ -v

혹은

export CPLUS_INCLUDE_PATH

이제 iostram파일을 포함하여 컴파일 하는 데는 문제가 없다. 하지만 링크 과정에서 iostream에 있는 함수와 클래스들이 어디에 어떤 파일로 로 구현되어있는지를 알려줘야 한다. 이것도 디폴트로 등록되어 있다.
우선 라이브러리 파일(바이너리)의 이름은 libstdc++.so.6 이고 파일의 위치는 대체로 /usr/lib 이다. 이 디렉토리는 환경변수 $LD_LIBRARY_PATH에 등록되어 있다.

지금까지 봐왔던 .o 파일이 아니라 .so 인 이유는 동적 라이브러리이기 때문이다. 동적 라이브러리는 윈도우로 치면 dll파일이다. 정적 라이브러리는 링크할 때 직접 그 내용이 실행 파일 안에 복사된다. 그래서 바이너리 파일 크기만큼 실행 파일의 크기가 늘어난다. 반면에 동적 라이브러리는 프로그램에 포함되지 않는다. 대신 프로그램 실행할 때 위치만 알려주면 된다. 그래서 실행파일의 크기가 늘어나지는 않지만, 실행파일 단독으로 프로그램 실행이 안 되고, 꼭 동적 라이브러리를 옆에 붙여줘야 한다. 여러 프로그램에서 동시에 쓰는 바이너리 파일이 있다면 동적 라이브러리가 되는게 유리하다.

만약에 다른 라이브러리를 추가하고 싶으면 다음 세 가지를 컴파일러에 알려줘야 한다.

*관련 헤더파일의 검색 경로
*관련 라이브러리 검색 경로
*관련 라이브러리 파일 이름

헤더파일의 경로에는 -I(대문자 아이) 옵션,  라이브러리 검색 경로에는 -L옵션, 라이브러리 파일 이름에는 -l(소문자 엘) 옵션을 준다. 누구야 첨에 이거 만든 사람 왤케 헷갈리게 I랑 l이랑 섞어놨어..

myfunc을 라이브러리화 해서 추가한다면 다음과 같이 명령어를 입력한다.

#my를 컴파일하여 my.o를 생성한다.


g++ -c my.cpp

#my.o를 묶어서 static library로 만든다. (libmy.a 생성)


ar rcs libmy.a my.o

여기서 ar은 오브젝트 파일을 정적 라이브러리로 만들어주는 툴이다. 오브젝트 파일과 정적 라이브러리는 사실상 차이가 없으며 형식상 약간 다를 뿐이다. 정적 라이브러리란 오브젝트 파일들의 집합이라고 표현할 수도 있으므로 zip으로 묶어주는 것과 비슷한 개념으로 생각해도 좋다.
또한 여기서 라이브러리 이름에 lib라고 붙인 것은 gcc에서 관습적으로 쓰는 표현인데 꼭 지켜야 한다. 해당 파일이 라이브러리임을 나타낸다. 확장자가 a라는 것만 봐도 라이브러리임이 명확한데 굳이 파일 이름에 prefix까지 붙이는 건지 나로서는 이해할 수가 없다.

이제 다음과 같이 입력한다.

#실행파일 'test' 생성

g++ -o test main.cpp -lmy -L./

여기서 -l, -L옵션과 뒤에 나오는 인자 사이에 공백을 두지 않음에 유의한다. libmy.a 파일에서 앞의 lib와 확장자 .a는 빼야 한다. 기호 "./"는 현재 경로라는 뜻으로서 libmy.a 파일이 들어있는 경로를 밝혀줘야 한다. l은 숫자 1이 아니라 소문자 알파벳 k다음에 나오는 l 이다.

동적라이브러리 만드는 과정은 더 쉽다. 그건 알아서 찾아보자.. ㅎㅎ

라이브러리 한 두개 정도는 이런 식으로 추가가 가능하지만 일반적인 프로젝트는 수십개의 오브젝트파일과 수십개의 라이브러리를 묶어서 컴파일하기 마련이다. 이러한 컴파일 옵션을 간소화하기 위해 makefile이 생겨났고, makefile도 작성하기 힘들어서 CMake와 같은 빌드 툴이 개발됐다. 다음 화에서 차차 살펴볼 것이다.

우분투에서 C++ 개발하기 (2) - Make

https://ladofa.blogspot.com/2020/08/c-2.html

우분투에서 C++ 개발하기 (3) - CMake

https://ladofa.blogspot.com/2020/09/c-3-cmake.html

Read More

로지텍 G102 : 가성비 최고의 게이밍 마우스

예전에 노트북 리뷰에서도 밝혔지만 가성비가 좋다는 말은 결코 칭찬이 아니다. 가격대 성능비 라는 말에서 성능이란 센서의 감도나 기능을 뜻한다고 볼 수 있는데, 그런 것들을 제외하고 정숙성, 내구성, 클릭감, 기타 재료 마감 등에서 분명히 아쉬운 부분이 있기 때문이다. 어쨌든 모든 사람이 고급을 쓸 필요는 없다. 중요한 것은 자신이 원하는 마우스를 원하는 가격대에 사는 것이다.




6버튼 마우스이다. 좌 / 우 / 휠버튼 / DPI 조정 버튼 / 오른쪽 엄지부분에 앞, 뒤 네비게이션 으로 구성되어 있다. 모든 버튼은 커스터마이징이 가능하다. 하드웨어 매크로도 지원해준다.

DPI는 400부터 8000까지 폭넓게 지원하며 50단위로 조정 가능하다. 최대 5개까지 미리 저장해놓은 뒤, 버튼을 눌러서 원하는 DPI를 선택할 수 있다.




마우스 엉덩이의 불빛도 조절할 수 있다. 아예 끄거나, 밝기를 어둡게 하거나, 일정 시간이 움직임이 없으면 꺼지도록 설정할 수 있다. 컴퓨터 키고 잘 때나 어두운 곳에서 영화볼 때, 불빛을 약하게 해두면 좋을 것이다.

동영상으로 찍으면 소리가 다소 과장되긴 하지만 그 누가 들어도 마우스 클릭 소리가 큰 편이다. 오른쪽 엄지 버튼도 클릭감이 영 싸구려같다. 마우스 선도 그저 그런 재질이다.

가장 큰 특징은 마우스 전체 재질이 가벼운 ABS 플라스틱이며, 기타 다른 마감은 아무 것도 없다. 손에 닿는 것은 순수하게 플라스틱이다. 고급스럽지는 못하겠으나 내구성이 좋고 청소가 편하다. 고무로 덧씌워져 있는 것들은 1년만 지나면 죄다 벗겨지기 마련이다. 손톱이 닿지 않아도 1년만 지나면 금방 닳아서 벗겨지고, 그 다음부터는 계속 벗겨진 부분이 거슬려서 못 쓴다. 사람마다 다르겠으나 나에게는 플러스 점수.

휠만 고무로 되어 있는데, 물렁하거나 미끄럽지 않아서 좋고 청소하기 편한 구조로 되어 있다.

그냥 까만 색상에 아담한 크기의 양손 마우스라서 사무실에서 쓰기에도 부담이 없다. 징그러운 디자인 보다는 이렇게 수수한게 좋더라.

크기가 작아서 손바닥 전체를 감싸지 못한다. 대신 클로그립이나 핑거그립에는 안성맞춤. 손바닥이 뜨거운 나같은 사람들은 이렇게 작은게 좋다.

성능은 어떠하냐. 우선 DPI는 8000까지 확보되어서 만족.

위의 그림에서 위쪽은 폴링 레이트 125Hz, 아래쪽은 1000Hz이다. 레이트가 낮으면 빠른 원 그리기에서 계단 현상이 나타난다. 하지만 직선으로 천천히 움직일 때는 부드럽게 그려진다.
반대로 레이트가 높으면 마우스가 빠르게 움직일 때도 계단 현상 없이 움직임을 잘 잡아준다. 반대로 서서히 직선을 그으면 삐쭉삐쭉 튀는 모습이 보인다. 저렇게 튀는 것이 마우스 센서의 정직한 정확도이다.
왜 125Hz에서 직선이 부드러운가? 1000Hz라면 8번 나누어서 센싱할 것을 평균 내기 때문이다. 평균을 내니 노이즈가 제거된다.

5년 전인가 비싼 돈 주고 산 스틸시리즈의 센세이와 비교해보면 거의 비슷한 느낌이다. 하드웨어 매크로 기능같은 것도 옛날에는 7만원 이상의 고가 마우스에만 탑재됐었는데 지금은 2만원대에서 그런 기능을 다 맛볼 수 있게 됐다.

http://support.logitech.com/en_in/product/g102-prodigy-gaming-mouse/downloads
설정 프로그램은 윈도우만 지원한다. 보드에 메모리가 있어서 한 번만 설정해두면 프로그램 없이도 설정한 대로 잘 동작한다. 물론 설정은 한 가지만 지원하며 DPI만 여러 개 돌려쓰기 가능.



설정 프로그램 설치하면 끼워팔기가 있다....

결론적으로..
너무 싸지도, 너무 비싸지도 않은 적절한 가격과 성능에 각종 편의 기능이 잘 조립된 마우스라고 할 수 있다. 게임용으로도 사무용으로도 적당하고 아이손 어른손 가리지 않는 적절한 크기라서 매우 범용성이 높다.
적절한 가격/성능에 청소가 편리한 점까지 합쳐서 PC방에서 쓰기 딱 좋다.

소음에 민감한 사람은 한 번 더 생각해보라.



----------------------------

현재 로지텍에서 지원하는 드라이버가 두 가지 버전으로 나뉘어져 있는 형국이다. 하나는 Logitech G HUB이고 다른 하나는 Logitech Gaming Software이다. 2020년 8월 현재는 모든 커뮤니티에서 구버전에 해당하는 LGS를 추천하고 있다. G HUB는 온디바이스 프로파이을 제대로 지원하지 않는다.

https://support.logi.com/

여기 들어가서 다운로드 페이지를 보면 된다.

참고로 그냥 꽂아서 잘 되고 셋팅에 불만이 없으면 드라이버 필요없다. 온디바이스 설정 한 번 잘 해놓은 사람도 재차 드라이버를 설치할 필요 없다.

Read More

레오폴드 FC750R 실버(은축) 리뷰

레오폴드에서 드디어 은축(스피드축) 모델이 나왔다. 나름 깔끔한 마감으로 소문이 난 레오폴드라서 스피드축 입문에는 아주 좋을 듯 하다.

1. 스피드축에 대해서

스피드축은 스트로크 깊이가 짧아짐과 동시에 키 입력을 감지하는 입력 깊이가 매우 짧아져서 아주 살짝만 눌러도 바로 인식이 된다. 이 점에 대해 기존 적축/리니어 유저라도 적응하지 못하는 사람이 꽤 있는 듯.

키보드를 타이핑하는 습관은 손목의 움직임과 손가락 움직임이 합쳐져 있다. 손목을 많이 쓰면 타이핑하는 힘이 좋지만 정교함은 다소 떨어진다. 반면에 손가락을 오물오물 움직이면 키를 누르는 힘은 떨어지지만 더욱 정교한 움직임이 가능하고 키보드에 따라서는 더 빠른 타이핑이 가능하다. 거의 손목으로 치는 사람들은 대체로 흑축이나 청축의 반발력을 좋아하기 마련이고, 스피드축을 활용하면 오히려 오타가 많이 날 수 있다. 예를 들어 손목을 크게 움직여서 ㅌ 키를 눌렀을 경우 손 모양에 따라 ㅎ이나 다른 키가 살짝 같이 눌릴 수 있기 때문이다. 스피드축은 될 수 있으면 손목의 움직임은 제한하면서 손가락을 열심히 놀려서 타이핑하는 것이 좋다. 그리고 이렇게 했을 때, 에너지를 덜 쓰면서 편안한 타이핑이 가능하고, 소음이 상당히 줄어든다. 다만 팬터그래프를 쓸 때 처럼 아예 손가락만을 이용해서 타이핑하기에는 스트로크 깊이가 애매하게 깊다. 하여튼 치다 보면 키보드에 맞는 움직임으로 적응하게 된다.

글을 쓰는 본인이 가장 마지막에 사용한 키보드가 청축이다. 청축을 쓰다가 스피드축을 써보니 그 심심함과 가벼움이 확 와닿아서 당혹스러웠다. 기존에 파워풀한 흑축/청축을 쓰던 유저들은 입문하는데 상당한 인내가 필요하다.

한 가지 덧붙여서, 적축은 윤활을 안 하면 서걱임이 상당한데, 스피드축은 서걱임이 별로 없다. 윤활 잘 된 변흑 쓰던 추억이 떠오를 정도.

2. 레오폴드에 대해서

키캡은 레오폴드에서 자체개발한 PBT 이중사출. 기존의 이중사출은 대부분 ABS인 것에 비하면 10배는 고급이다. 이중사출은 애초에 두 가지 색의 플라스틱을 이용해서 만들기 때문에 각인이 지워질 수가 없다. 기존의 레이저 각인 PBT가 까슬까슬한 감촉이었다면 이번 레오폴드 이중사출 키캡은 오돌토돌한 감촉에 아기자기한 느낌이 난다. 안 그래도 가벼운 스피드축이 더 가벼운 느낌으로 다가오게 만든다. 차라리 표면이 맨질맨질하면 더 키감이 좋겠다는 생각이 든다. 그리고 조금 더 무거웠으면 좋겠다.

그래서 체리 POM 무각을 끼워봤다. 체리 정품 POM은 더 두껍고 맨질맨질하다. 그래 이 맛이야 ㅜㅜ 훨씬 더 정숙해지고 단정하고 단단한 느낌이다. 역시 리니어 스위치에는 무조건 무겁고 단단한 키캡이 최고.

1, 2, 3, 4 자리에 POM 키캡을 끼워봤다. 소리가 다르지? 키감도 달라 ㅜㅜ

\

같은 모델 청축과 비교했을 때.

레오폴드의 마감은 현재 기성품중에서는 최고 수준이다. 스테빌라이저(SHIFT, ENTER에 쓰임)도 아주 경쾌해서 이질감이 없다. 심심한 디자인은 취향에 따라 다를 것이다. 키보드가 뒤틀릴 경우 힘을 주어서 바로 잡으면 된다는데, 애초에 뒤틀리는게 잘못 아닌가. 레오폴드는 뒤틀림 그런 거 없다. 레오폴드가 통울림이 크다는 사람은 최소 마제 안 써본 사람.

후면의 딥스위치를 조절하면 컨트롤과 캡스락의 위치를 바꿀 수 있다. 더불어 키캡도 따로 제공해준다. 그리고 나머지 딥 스위치도 이런 저런 키배열 수정이 가능한데, 다 쓸모없는 것 같다. 제일 필요한 건 'ESC'와 '~'를 바꿔주는 것인데, 이런 거 왜 안 나오는지 모르겠네.

3. 결론

기계식 키보드 대신 멤브레인을 선호하는 사람들이 내 주변에도 가끔 있는데, 그들이 공통적으로 말하는 기계식 키보드의 단점은 첫째로 시끄러운 소리, 둘째로 너무 깊은 스트로크, 그리고 세 번째로 험악한 디자인이다. 이런 단점을 모두 커버할 수 있는 키보드라고 할 수 있으므로 기계식 입문으로 자신있게 추천한다.

Read More

Visual Studio 2017 + 파이썬 + Tensor Flow 셋팅

Windows에서 파이썬이 돌아간다는 사실은 모두가 알면서도 막상 딥러닝 프레임워크를 돌릴 때는 리눅스를 사용하게 된다. 프레임워크를 사용한 수많은 예제들이 모두 리눅스 기반으로 돌아가기도 하거니와 왠지 윈도우 파이썬은 뭔가 호환이 안 될것 같은 기분 탓이다. 요즘은 파이참(PyCharm)이라는 좋은 개발 환경도 있고, Visual Studio에서도 파이썬을 기본으로 서포트해주기 때문에, 윈도우에서도 특별한 고생 없이, 어쩌면 리눅스보다 더 편하게 파이썬을 사용할 수 있다.

그러나 시작은 언제나 두려운 법. 파이썬 초보들도 쉽게 Tensor Flow를 셋팅할 수 있도록 튜토리얼을 작성해본다.

우선 Visual Studio를 깔아야한다. 2017버전을 설치할 때, Python 개발 환경을 체크해야 한다. 혹시 설치할 때, 체크하는 것을 놓쳤다면 나중에라도 Visual Studio Installer를 실행해서 추가 설치가 가능하다.

여기서 파이썬을 선택한 뒤 수정 버튼을 누른다.

설치를 진행하면 VS의 파이썬 코딩 툴 뿐 아니라 파이썬 자체가 새로 설치된다. 이미 기존에 파이썬이 설치되어 있더라도 마찬가지이다. 여기서 의문이 드는 점은 여러 개의 파이썬을 설치할 경우 어떻게 되느냐 이다. 파이썬은 다양한 버전이 존재하고, 사람마다, 소스마다 써야 하는 버전이 다르기 때문에 자연스럽게 여러 가지 버전을 모두 설치하게 된다. Visual Studio 역시 이러한 파이썬의 사정을 잘 알고 있기 때문에, 설치된 파이썬 버전을 직접 관리할 수 있도록 기능이 제공된다.

개별 파이썬 버전은 폴더 단위로 관리된다. 설치 폴더 밑에 python.exe가 있고, 하위 폴더로 Scripts, Lib 등이 있다.

여러 개의 파이썬이 설치될 때는 위와 같은 폴더가 여러 개 생성된다.

이제 VS에서 파이썬 프로젝트를 만들어보자.

파이썬 프로젝트를 선택하면 된다.

솔루션 탐색기에서 Python 환경을 보면 Python 3.6 (64-bit) 라고 되어 있고 바로 뒤에 (전역 기본값) 이라고 되어 있다. 새 프로젝트를 만들고 나서 특별히 환경을 지정하지 않았으므로 기본값이 지정된 것이다. 특별히 다른 파이썬 버전으로 현재 프로젝트를 구동하고 싶다면 환경에서 오른쪽을 눌러서 고를 수 있다.

이쯤에서 소개할 것은 아나콘다이다. 아나콘다는 파이썬 배포판 중 하나라고 할 수 있다. 예를 들어 리눅스가 래드햇, 페도라 등 다양한 배포판을 가지고 있는 것과 같다. 리눅스 배포판이 핵심 커널 뿐 아니라 다양한 유틸리티를 포함하고 있는 것처럼 아나콘다도 자주 쓰는 라이브러리를 미리 탑재하고 있다.

파이썬 환경에서 중요한 포인트 중 하나는 각각의 파이썬 환경마다 다른 라이브러리를 설치할 수 있다는 것이다. 파이썬에서 설치한 라이브러리는 Lib 폴더에 저장된다.

파이썬에서는 라이프러리를 패키지 단위로 관리한다. 패키지란 라이브러리 묶음으로 생각하면 될 것이다. 예를 들어 우리가 OpenCV를 설치할 때, 각각의 lib파일을 개별적으로 다운받는 것이 아니라 OpenCV라는 묶음으로 설치한다. 이렇듯 패키지란 개념은 이미 일상에서 자연스럽게 사용하고 있다. 파이썬에서는 패키지 다운로드를 위한 툴을 기본적으로 탑재하고 있는데, 그것이 바로 pip이다. pip로 다운받은 패키지는 파이썬 폴더/Lib/site-packages 폴더에 저장된다.

Visual Studio를 사용하면 pip를 좀 더 쉽게 사용할 수 있다. 메뉴에서 [도구]->[Python]->[Python 환경]으로 들어가면 조그만한 도킹 창이 뜬다. 맨 위에서 원하는 환경을 선택한다. 아나콘다를 설치했거나, 기타 다른 버전의 파이썬을 설치했다면 해당 환경을 고를 수 있다. 만약 설치한 환경이 보이지 않는다면 수동으로 추가해야 한다.

 가운데 콤보박스에서 패키지(PyPI)를 고른다.

설치된 패키지가 나타나는데, 특별히 다른 것을 설치하지 않았다면 달랑 pip, setuptools 정도 보일 것이다. X표를 누르면 패키지를 지울 수 있고 화살표를 누르면 최신 버전으로 업데이트한다.

패키지 검색 창에 tensorflow라고 입력해보자. 엄청나게 많은 항목이 뜨는데 대부분의 것들은 텐서플로우를 보조하는 툴이거나 실험 버전 등이고 중요한 것은 그냥 'tensorflow', 그리고 'tensorflow-gpu' 이다. 'tensorflow-gpu'는 말 그대로 GPU 버전이고 그냥 tensorflow는 CPU only 버전이다. 둘 다 설치하면 어떻게 될까? 조금 꼬이긴 하는데 마지막에 설치된 버전이 적용된다. Keras를 사용하면 내부적으로 tensorflow를 참조하는데, 여기서도 마지막에 설치된 버전을 참조한다.

일단 CPU 버전인 'tensorflow'를 설치해보자. 클릭 한 번이면 설치가 시작되고, 설치 과정은 [출력] 창에 표시되는데, 이게 아무래도 좀 불친절하다. 프로그래스 바, 혹은 진행중 표시가 없으니 설치가 되는 건지 됐다는 건지 안 됐다는 건지 알 수가 없다. 하여튼 설치됨 메시지가 뜨면 완료된 것이다.

설치 과정을 잘 읽어보면 알겠지만 필요한 라이브러리들은 자동으로 설치된다. 만약 설치가 안 된다면 pip 버전을 업데이트 한 후 다시 설치해보자.

설치가 끝났으면 이제 헬로 텐서플로우를 외쳐볼 시간이다. 솔루션에서 .py 파일을 하나 선택한 뒤 다음과 같이 입력한다.

import tensorflow as tf

hello = tf.constant('Hello, TensorFlow!')
sess = tf.Session()
print(sess.run(hello))

참고로 솔루션에서 진하게 표시된 파일이 F5를 누를 때 처음 시작될 파일이다. 파이썬은 Matlab과 마찬가지로 메인함수가 없고 아무 파일이나 골라서 먼저 실행할 수 있다.

2018-04-27 08:34:58.484009: I T:\src\github\tensorflow\tensorflow\core\platform\cpu_feature_guard.cc:140] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2
b'Hello, TensorFlow!'
Press any key to continue . . .

위와 같이 메시지가 뜨면 성공이다. 맨 윗 줄에 Your CPU supports 어쩌구 하는 경고 메시지는 무시해도 된다. 원래 Tensorflow를 최적화하려면 CPU에 맞게 다시 빌드해야 하는데, 현재는 범용으로 컴파일된 라이브러리를 쓰고 있기 때문에 나타나는 메시지이다.

여기까지 진행되면 CPU 버전 텐서플로우 설치가 완료된 것이다. 이제 tensorflow-gpu를 설치해보자. GPU버전은 사용하려면 CUDA를 지원하는 NVidia 그래픽 카드가 있어야 하고, CUDA, cudnn 설치도 해야 하서 좀 복잡하고 귀찮지만 CPU버전에 비해 거의 20배 빠르기 때문에 충분히 해볼만한 가치가 있다. 사실 GPU가 아니면 딥러닝은 시작되지도 못했다.

Tensorflow 버전에 따라서 요구하는 CUDA, cudnn 버전이 다르다. 확실히 하려면 Tensorflow 홈페이지를 방문해서 확인해보면 된다. 영 귀찮으면 그냥 최신 버전을 설치하면 그냥 저냥 잘 될테지?? 라고 생각하면 오산이다. 텐서플로우 버전에 정확히 맞는 것을 찾아서 설치해야 한다. 현재 tensorflow 1.7 버전은 CUDA 9.0, cudnn 7.1.x 에서 동작한다.

우선 CUDA를 설치해야 하는데, 구글에서 cuda를 검색하면 자연스럽게 다운로드 페이지로 이동한다. 자신의 OS를 잘 선택하고 windows버전을 골라서 다운로드한다. 설치 과정은.. 그냥 next만 누르면 알아서 잘 설치된다. 설치 도중에 화면이 깜빡거릴 수 있으며 단순히 다음을 눌러서 간편 설치를 할 경우 그래픽 드라이버도 새로 설치된다.

다음은 cudnn을 설치해야 하는데, 우선 다운로드 하려면 NVidia ID로 로그인을 해야 한다. ID가 없으면 새로 만들고 로그인한다.

로그인 후 버전을 선택한다. 자신의 CUDA 버전에 맞는 것으로 잘 골라서 다운로드 하면 된다.

CUDA는 설치 프로그램이 알아서 설치를 했지만 cndnn은 받아보면 그냥 압축 파일이다. 아무곳이나 편리한 곳에 풀어놓은 뒤, 설치경로/cuda/bin 폴더를 PATH로 잡아줘야 한다.

혹시 PATH 잡는 법을 모르는 사람들을 위해 안내까지 만들었다~ 시작메뉴에서 제어판을 검색해서 실행한 뒤 아래처럼 폴더 경로를 넣는다. 캡쳐하기 귀찮아서 한꺼번에 모아서 캡쳐 ㅎㅎ

변경된 환경변수를 적용하기 위해서는 재로그인/혹은 재부팅을 해야 한다.

이제 Python pip에서 tensorflow-gpu를 다운로드하고 실행해보면 된다. 다운로드하는데 20분이 걸릴 수도 있으니 천천히 기다려보자.

2018-04-27 23:38:33.037407: I T:\src\github\tensorflow\tensorflow\core\platform\cpu_feature_guard.cc:140] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX2
2018-04-27 23:38:33.783060: I T:\src\github\tensorflow\tensorflow\core\common_runtime\gpu\gpu_device.cc:1344] Found device 0 with properties:
name: GeForce GTX 965M major: 5 minor: 2 memoryClockRate(GHz): 1.15
pciBusID: 0000:01:00.0
totalMemory: 2.00GiB freeMemory: 1.64GiB
2018-04-27 23:38:33.789763: I T:\src\github\tensorflow\tensorflow\core\common_runtime\gpu\gpu_device.cc:1423] Adding visible gpu devices: 0
2018-04-27 23:38:34.209099: I T:\src\github\tensorflow\tensorflow\core\common_runtime\gpu\gpu_device.cc:911] Device interconnect StreamExecutor with strength 1 edge matrix:
2018-04-27 23:38:34.213833: I T:\src\github\tensorflow\tensorflow\core\common_runtime\gpu\gpu_device.cc:917]      0
2018-04-27 23:38:34.216125: I T:\src\github\tensorflow\tensorflow\core\common_runtime\gpu\gpu_device.cc:930] 0:   N
2018-04-27 23:38:34.218824: I T:\src\github\tensorflow\tensorflow\core\common_runtime\gpu\gpu_device.cc:1041] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 1405 MB memory) -> physical GPU (device: 0, name: GeForce GTX 965M, pci bus id: 0000:01:00.0, compute capability: 5.2)
b'Hello, TensorFlow!'
Press any key to continue . . .

위와 같이 나오면 성공 ^^

Read More