
어제, 이런 트윗을 트위터에서 보았습니다.

<blockquote class="twitter-tweet" lang="ko"><p lang="ko" dir="ltr">불안장애가 있는 사람들은 무례한 게 아닙니다&#10;우울증이 있는 사람들은 게으른 게 아닙니다&#10;정신질환이 있는 사람들은 미친 게 아닙니다&#10;자살충동을 느끼는 사람들은 관종이 아닙니다.&#10;이틀지났지만 <a href="https://twitter.com/hashtag/%EC%84%B8%EA%B3%84%EC%A0%95%EC%8B%A0%EA%B1%B4%EA%B0%95%EC%9D%98%EB%82%A0?src=hash">#세계정신건강의날</a> <a href="http://t.co/1JBE8wJnvp">pic.twitter.com/1JBE8wJnvp</a></p>&mdash; Funny Tweets Kor (@Funnytweets_Kr) <a href="https://twitter.com/Funnytweets_Kr/status/653496314940907520">2015년 10월 12일</a></blockquote>

위의 트윗에서 언급되는 질환은 모두 다 힘든 문제입니다.
이런 환자들은 병원에 꼭 가봐야 합니다.
하지만 대부분 병원엔 안가려고 합니다.
주변 인식이 안좋으니까요.
자기 스스로가 병원에 가야할 이유를 납득하지 못합니다.

예를 들어 우울증에 대해 말해보겠습니다.
우울하다는 감정은 누구나 살면서 느낄 수 있습니다.
마치 바다에서 배를 타고 있는데 바람 때문에 배가 출렁일 수 있는 것 처럼 말이죠.
하지만 정신과에 꼭 가야하는 우울증의 경우 자신이 제어할 수 있는 상태가 아닙니다.
위에 든 예로 말하자면 바람이 너무 불어서 배가 전복되게 된 상태인 것이죠.
우울증이 아니라 다른 모든 증상들이 그러합니다.
정말 가볍게 지나가는 바람이라면 며칠 내로 회복이 되겠지만 그렇지 않다면 병원을 가볼 생각을 해야한다고 생각합니다.

사람들은 정신과 라는 장소 자체를 나쁘게 생각합니다.
한국 드라마에서 정신병원에 사람을 가두는 장면이 많이 나와서일지도 모르지만, 그 이전부터 정신과에 대한 나쁜 이미지는 있었다고 생각합니다.
얼마나 나쁘게 생각하냐 하면 자기 자신이나 자기 주변 사람이 가야한다고 하면 못가게 하려고 할 정도죠.

사람들은 정신과에 간다고 하면 일단 반대하고 봅니다.
우울증 같은 것은 아무것도 아니라고 주장하죠.
보통 이러는데에는 다 이유가 있습니다.
우울증을 예로 들자면 자신이 우울해봤던 경험이 있고, 그것을 자신의 힘으로 극복해본 경험이 있으니까 다른 사람도 그렇겠거니 하는 것입니다.
하지만 잘못된 생각입니다.
당신의 우울했던 정도, 당신의 극복력과 상대방의 그것은 분명히 다를 것입니다.
**당신은 정신과 의사가 아닙니다.**
아프면 병원에 가는건 당연한겁니다.
그것이 마음이라고 할지라도요.

정신과는 사실 그렇게 어려운 장소가 아닙니다.
정신과의 기본 치료는 상담입니다.
대부분의 사람들이 가지고 있는 정신적 괴로움은 정신과에서 상담을 받아보면 완화될 수 있습니다.
약물 치료 등의 다른 수단이 필요한 경우는 특별한 경우입니다.
정신적으로 힘든 문제가 있다면 정신과에 가서 상담만 받아도 됩니다.

이 글을 쓰는 저도 정신과 의사가 아닙니다.
오히려 저는 정신과 환자죠.
저는 이제까지 정신질환으로 인해 계속 나쁜 평을 받아왔었고, 그 악순환을 끊기 위해서 제 정신질환과, 그로 인해 어떻게 보여질 수 있는지를 상대방에게 알려 오해를 막으려고 하는 편입니다.
그렇게 해도 이해하고 받아들여지기 힘든게 현실이더군요.
그럼에도 이런 글을 쓰는 것은 조금이라도 더 환자들의 고충을 이해하는 사람이 늘어난다면 지금보다는 더 아픈 사람들이 존중받을 수 있지 않을까 해서 입니다.

아픈 사람을 나무라지 마세요.
아픈 사람도 아프고 싶어서 아픈게 아닙니다.

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>


세계 정신건강의 날에 올라온 트윗을 보고 생각난 것을 적어봅니다.

정신건강에 대한 오해


※ 이 글은 [How to Become a Great JavaScript Developer](http://blog.ustunozgur.com/javascript/programming/books/videos/2015/06/17/how_to_be_a_great_javascript_software_developer.html)의 번역판입니다.

---

저는 커가면서 점차 관심 분야가 다양해지고, 겉으로 보기에는 무관한 영역까지 넓어져 갔습니다.
저는 수학을 역사 만큼 좋아했었죠. 저의 목표는 여러 분야에 능통한 [르네상스 맨](https://en.wikipedia.org/wiki/Renaissance_Man)([박식가](https://en.wikipedia.org/wiki/Polymath))이 되는 것이었습니다.
그것은 아주 힘든 일 이란 것을 알게 되었고, 갑자기 저는 여러 분야를 알지만 한 분야에도 능통하지 못한 사람이 되는 위험성과 마주했습니다.

저는 르네상스 시대의 사람들처럼 될 순 없더라도 적어도 한 분야 만이라도 마스터한 사람이 되기 위해, 확실하게 어떤 분야를 전문적으로 해야겠다고 생각했습니다.
어떻게 하면 소프트웨어 개발에 필요한 어마어마한 양의 지식을 유지하면서 내 전문 분야를 정할 수 있을까요?

이 글을 통해 지난 5년 간의 경험을 바탕으로 제가 훌륭한 JavaScript 개발자가 되기 위해 썼던 기법과 자료를 대략적으로 알려드리고자 합니다.

요즘 거의 모든 웹 개발자는 같은 문제에 시달리고 있습니다.
우리는 데이터베이스로부터 시작해서 백엔드 아키텍쳐, 프론트엔드 사용자 인터페이스, 그리고 CSS 지식으로 UI를 다듬는 부분까지 여러 분야에 모두 능통해야 합니다.

## 책 읽기

가장 우선적이고 중요한 제안은 잘 하기 위해 헌신적인 노력을 해야 한다는 것입니다.
당신이 성의 없이 노력하는 동안은 잡스러운 결과를 얻을 것이 자명합니다.
예를 들자면 몇몇 블로그 게시물을 가끔 읽으면 초기 투자 시간이 적으니 그것이 쉬워 보일 것입니다.
그런 교육은 열정적이고 정제된 학습 과정보다 더 오랜 기간 동안 많은 시간을 할애하게 합니다.
이 딜레마의 해답은 간단합니다.
책을 읽으세요.

책이야 말로 우리 문명을 떠받치고 있는 것입니다.
책 속의 글자는 우리가 지식을 정제된 형태로 현 세대에서 다음 세대로 전달하는 수단입니다.
웹 기술 전문가가 되는 데에 있어 하나의 문제는 당신이 언제 웹 그 자체로부터 거리를 두어야 하는 지를 배워야 한다는 것입니다.
웹 그 자체는 학습 도구로서는 혼란스럽고 집중을 방해하는 매체입니다.
따라서 저의 첫 번째 제안은 주제에 대한 책을 읽는 것입니다.

이 책들로 JavaScript 공부를 시작해보세요.
먼저 더글라스 크락포드의 자바스크립트 핵심 가이드([원서](http://shop.oreilly.com/product/9780596517748.do)/[번역서](http://www.aladin.co.kr/shop/wproduct.aspx?ISBN=8979145985))는 JavaScript의 성경 같은 책입니다.
오래된 책이지만, 여전히 시작하기에 가장 좋은 책입니다.
자바스크립트 완벽 가이드([원서](http://shop.oreilly.com/product/9780596805531.do)/번역서는 절판) 또한 반드시 가지고 있어야 할 책입니다.
당신은 아마 레퍼런스로써 이 책을 소장하게 될 겁니다.
jQuery의 주요 개발자인 John Resig이 쓴 자바스크립트 닌자 비급([번역서](http://www.aladin.co.kr/shop/wproduct.aspx?ISBN=8966261078)) 또한 주목할 만 합니다.
만약 당신이 좋은 (그리고 무료로 온라인에서 볼 수 있는) 책을 찾고 있다면 [JavaScript Allongé](https://leanpub.com/javascript-allonge/), [You Don’t Know JS](https://github.com/getify/You-Dont-Know-JS), 자바스크립트 개론([원서](http://eloquentjavascript.net/)/[원서+주석](https://watchandcode.com/courses/eloquent-javascript-the-annotated-version)/[번역서](http://www.aladin.co.kr/shop/wproduct.aspx?ISBN=8960773867))을 보십시오.
이 책들은 ebook이나 종이 책으로 구입할 수 있습니다.
또한 책은 아니지만 모질라 개발자 네트워크 사이트에도 훌륭한 [JavaScript 가이드](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide)가 있습니다.

## 라이브러리 배우기, 사용하기, 읽기

다음으로 가장 중요한 단계는 라이브러리들을 익히는 것입니다.
책이 당신에게 언어를 어떻게 읽는지 가르쳐 주었다면, 라이브러리는 당신에게 어떻게 말하는 지를 알려줄 것입니다.
당신이 라이브러리로 해야 할 중요한 일은 두 가지입니다.
바로 그것들을 직접 사용해 보고, 소스 코드를 읽는 것입니다.

라이브러리 사용 측면에서는, jQuery, Backbone, underscore 와 React, Angular, Ember 중 한 가지 라이브러리에 익숙해져야 합니다.
이들 중 한 라이브러리를 꼭 사용해야만 한다는 말은 아닙니다.
그러나 JavaScript 개발자라면 최소한 이 라이브러리들에 대한 경험이 좋건 나쁘건 어느 정도 있어야 한다는 것입니다.

당신의 JavaScript 실력을 키우기 위한 두 번째 중요한 일은 이 라이브러리들의 소스 코드를 읽는 것입니다.
이 중에서 저는 Backbone과 underscore의 소스 코드를 강력하게 추천합니다.
저 둘의 소스 코드는 아름답게 작성되어있습니다.
underscore의 소스 코드를 읽고 이해함으로써 당신은 함수형 프로그래밍 실력을 키울 수 있습니다.
소스 코드를 읽기 좋은 또 다른 라이브러리로는, 제가 여러 개발자들로부터 추천 받기도 한 mootools입니다.
(저는 개인적으로 mootools에 대한 경험도, 그것의 소스 코드를 읽어본 적도 없습니다. 단지 메시지를 전달할 뿐입니다.)

목록에 있는 다른 것들도 살펴보세요.
React나 Ember 같은 것들 말이죠.
분명 어려울 것입니다.
하지만 확실히 노력해볼 가치가 있습니다.
하다못해 다른 라이브러리들의 소스 코드 전체를 훑어보기라도 하면서 코드 베이스를 어떻게 설계하는 지를 배우고, 몇 가지 패턴을 발견하기 위해 노력해보세요.
그 외에 d3, highchart, moment.js 등의 라이브러리들도 소스 코드를 읽어볼 만합니다.

## 연습하고, 스스로에게 질문하기

좋은 JavaScript 개발자가 되기 위한 다음 단계는 많은 연습을 해보는 것입니다.
원칙적으로 이 연습들은 DOM이 아니라 언어 그 자체에 초점이 맞춰져 있습니다.
따라서 반드시 테스트들이 node.js에서 돌아갈 수 있게 해야 합니다.
node.js로 작게, 또 많이 연습하세요.
개인 훈련을 하고, JavaScript를 사용하는 다른 방법들을 살펴보세요.
Closures, Prototypes, Array Extras (map, filter) 등이 있습니다.
연습을 하는 동안에는 언제나 JavaScript의 근본적인 철학들을 마음 속에 새겨야 합니다.

제 친구 [Armagan](http://arm.ag/)은 훌륭한 JavaScript 프로그래머이자 교사로서 [Pro JavaScript Design Patterns](http://www.apress.com/9781590599082)을 자신의 수업 교재로 사용하고 있습니다.
그 수업을 통해 이 책의 가치는 입증되었습니다.

이런 질문에 대답해보세요.
"Prototype을 사용한 상속은 어떻게 동작하는가?", "Closure의 정의는 무엇인가?", "`this` 키워드 의미는 어떻게 변하나?", "apply/bind/map/filter/call은 어떻게 사용하나?".
JavaScript 개발자들이 경험하는 일반적인 소스 포인트의 목록을 모아서 당신이 아는 대로 설명해 보세요.
이런 개념들을 다른 사람에게 글이나 구두로 설명해 보는 것은 당신의 실력 향상에 엄청난 도움이 될 것입니다.
이 연습을 하면서 "만약에 이랬더라면?" 하고 발견한 시나리오 들을 시도해 보세요.
예를 들면, "bind를 두 번 썼을 때, `'this'`는 무엇을 의미하는가? 어떻게 jQuery는 `'this'` 키워드를 전역 object가 아닌 jQuery object로 만드는가? 어떻게 이 라이브러리는 어떤 기능을 제공하는가?" 같은 일반적인 질문들을 당신 스스로에게 해봐야 합니다.

## 표준 배우기

다음 단계는 EcmaScript 표준에 대해 더 깊이 알아 가는 것입니다.
최신 EcmaScript 표준을 뽑아 들고 읽어보세요.
이렇게 하면 ES6와 ES7으로부터 JavaScript의 새로 나올 기능들에 대해 배울 수 있습니다.
Nicholas Zakas의 [Understanding EcmaScript 6](https://leanpub.com/understandinges6)나 Dr. Axel Rauschmayer의 [Exploring JS](http://exploringjs.com/) 같은 ES6 관련 책과 함께 표준을 읽으면 Promises, 모듈, 제너레이터, Comprehensions 같은 새로운 기능들의 변화를 알 수 있습니다.
전문가가 되는 길은 지속적으로 주요 소스로부터 표준을 배우고 언어의 새로운 기능을 발견함으로써 가능합니다.

## 웹에 있는 자료 활용하기

저는 앞서서 웹에서 웹에 대해 배우는 것의 위험성을 언급했습니다.
이제 제 마지막 추천은 웹에서 최고의 리소스를 얻는 방법입니다.
Hacker News는 꾸준히 따라가기엔 시간이 많이 들지만 노이즈가 줄어드는 좋은 소스입니다.
대신에, [JavaScript Weekly](http://javascriptweekly.com/) 같은 주간 다이제스트를 목표로 해보세요.
시간이 흐르면 당신은 어느 라이브러리 혹은 기술이 대세를 이끄는지 알 수 있을 겁니다.
트위터에서 영향력 있는 JavaScript 개발자를 찾아보세요.
Tutsplus가 만든 [33명의 팔로우할만한 JavaScript 개발자 목록](http://code.tutsplus.com/articles/33-developers-you-must-subscribe-to-as-a-javascript-junkie--net-18151)은 좋은 출발점입니다.
웹에는 [Toptal Blogs](http://www.toptal.com/section/front-end), [Rebecca Murphey의 블로그](http://rmurphey.com/), [Nicholas Zakas의 블로그](http://www.nczonline.net/) 와 같은 블로그들에도 자료가 있습니다.
(혹시 관심이 있다면 [A Baseline for Front-End [JS] Developers: 2015](http://rmurphey.com/blog/2015/03/23/a-baseline-for-front-end-developers-2015/) 의 글도 읽어보세요.)

(혹시 이 목록에 없는 다른 좋은 블로그가 있다면 저에게 메일로 알려 주세요.)

웹에 있는 또 다른 중요한 자료는 컨퍼런스와 교육 비디오입니다.
컨퍼런스로는 JSConf 시리즈가 질이 좋습니다.
교육 비디오 중에서는 Pluralsight를 강하게 추천합니다.
그들의 숙련된 개발자 부대가 양질의 코스를 준비해 놓았습니다.
(Pluralsgiht의 제휴를 받은 것은 아닙니다.)

## 요약 버전

- 책을 읽는 것부터 시작하세요. 그들이 정제된 정보를 줄 것입니다.
- jQuery, underscore, Backbone 같은 주요한 라이브러리를 배우고, 소스 코드를 읽으세요.
- JavaScript의 여러 개념들을 연습하고 자신이 아는 데로 설명해 보세요. 위 주제에 대해 강의하고 대화해 보세요.
- 최신 버전의 표준 문서를 읽고, 언어의 최신 기능을 도입해 보세요.
- 다이제스트나 블로그를 한 주마다 읽거나 컨퍼런스나 교육 비디오를 보면서 여러 웹 리소스를 따라가세요.

## 마치며

끊임 없이 이 과정을 반복하고 수많은 프로젝트를 해보면 당신의 JavaScript 실력은 엄청나게 향상될 것입니다.
언제나 마음 속에 헌신적인 노력을 하겠다는 마음을 가진다면 머지않아 실력자가 될 수 있습니다.
저는 스스로를 좋은 JavaScript 프로그래머라고 생각하지만 아직도 제가 숙련된 개발자가 되려면 멀었고, 제 여정 중에 그 기술들을 따라갈 것입니다.
제 피드백이 필요하거나 수정할 사항이 있으면 ustun@ustunozgur.com 으로 마음 편히 연락 주세요.

그리고 마지막으로, Ustun Ozgur Software에서는 터키 이스탄불에서 일할 숙련된 JavaScript 개발자를 모집합니다.
모집 상황은 [저희 웹사이트](http://ustunozgur.com/)를 참조해주세요.

즐거운 공부 되시길!

Ustun

여기까지 읽으셨다면 제 트위터 계정, [@ustunozgur](http://twitter.com/ustunozgur)을 팔로우 해보시는 건 어떨까요?

React.js와 고급 JavaScript 훈련에 관심이 있으신가요? [제 개인 training/workshop 사이트](http://reactjs-workshops.com/)를 방문해보세요.

저와 이 글에 대해 초기 논의를 해준 [Engin Arslan](http://enginarslan.com/)에게 감사합니다.

[HackerNews](https://news.ycombinator.com/item?id=9731230)에서 논의해보세요.

## 역자 정보

- 번역: fabulousu([https://medium.com/@fabulousu](https://medium.com/@fabulousu)), item4([https://item4.github.io/](https://item4.github.io))
- 도움: haruair, realignist in 이상한모임


How to Become a Great JavaScript Developer의 번역판입니다.

훌륭한 JavaScript 개발자가 되는 법


어제는 한글날을 맞이하여 [국제 아희 개발자 대회](http://onoffmix.com/event/54794)에 다녀왔습니다.
"대회"라는 글자가 들어가는데, 실제 경기나 시합같은것을 하는 건 아니고, 컨퍼런스입니다.
이번 대회에는 20여명 정도가 참석해주셨는데, lexifdev님이 주최해주시고 여러가지 세션과[^1] 라이트닝 토크, 그리고 기념 행사가 있었습니다.

## 세션

### 알파희 (rpaheui)

파이콘 티셔츠를 입고 오신 youknowone님께서 파이콘때 썼던 발표 자료를 재탕하면서 그때는 하지 못했던 비하인드 스토리를 들려주셨습니다.
눈물나는 알파희 최적화 과정을 들을 수 있었습니다.
이 발표 이후로 모두가 Ahsembly를 [아(흣)셈블리]라고 읽는 장관을 볼 수 있었습니다. (웃음)

### 아희아희

lifthrasiir님께서 만드신 아희로 만든 아희, 아희아희의 구현 이야기를 들을 수 있었습니다.
먼저 Rust로 아희 인터프리터를 구현한 후 아희로 재구현 하고, 그걸 알파희로 돌려서 동일하게 구현이 되었는지 확인하는 방법으로 진행되었다고 합니다.
아희아희아희아희 (아희아희 위의 아희아희 위에서 아희아희 돌리기)를 돌려주실분을 구하신다고 합니다. (...)

### 아희켐

아드님과 함께 오신 분이 계셔서 아쉽게(?) 최연소 참가자 자리를 놓치신 Kkiro님께서 만드신 아희 비주얼 에디터, 아이켐의 개발 이야기를 들어볼 수 있었습니다.
이걸로 정보 올림피아드 공모부분 은상을 타셨다고 하네요!

### 약속

> 21세기엔 21세기 처럼 프로그래밍 해야죠

이사를 하다가 오신 ipkn님의 약속 영업이 있었습니다.
발표자료를 미쳐 준비 못해오셔서 라이브 코딩을 보여주셨습니다.
음성인식을 이용해서 코딩을 하는 모습이 재밌었습니다.

## 라이트닝 토크

### 아희 Jupyter notebook

lexifdev님께서 만드신 아희를 위한 [Jupyter kernel](https://github.com/lexifdev/iaheuikernel)과 그 사용법입니다.
이번 대회에서 가장 유용했다고 하는 우스개소리도 있었습니다.

<blockquote class="twitter-tweet" lang="ko"><p lang="ko" dir="ltr">밟따빠따밣따밟빠뚜&#10;밟따밣나타밦붏땨벏&#10;나다뿌냐벖발뛔빠밟&#10;벍떠뵓너뫃뻐터투너&#10;붇너나볿뿌뻐터벓튜&#10;너볿뻐멓멓누벌멓볼&#10;누벏뻐더너빠볃뽀터&#10;밟나다밣빠따다맣희</p>&mdash; 국립국어원 (@urimaI365) <a href="https://twitter.com/urimaI365/status/652150134717808642">2015년 10월 8일</a></blockquote>

이런 코드를 돌려보는 등의 행사를 가졌습니다.

### 줄리아로 하는 한글 코딩

줄리아로 이런저런 한글 코딩 하는 것을 보여주셨습니다.
아희 인터프리터도 만들기 시작하셨다고 하셨는데, [오늘 아침 확인 결과 Hello, World까지 돌릴 수 있다고 합니다!](https://github.com/wookay/Aheui.jl)

### 하읏 (??)

```
삶은밥과야근밥샤주세양♡밥사밥사밥사밥사밥사땅땅땅빵☆따밦내발따밦다빵맣밥밥밥내놔밥줘밥밥밥밗땅땅땅박밝땅땅딻타밟타맣밦밣따박타맣밦밣따박타맣밦밣따박타맣박빵빵빵빵따따따따맣
```

굉장한 아희 문학이 발굴되었습니다.
아희켐에서 2배속으로 돌려보는 것을 추천(?)합니다.

### 아희 2015 스펙

아희도 발전하는 언어가 되어갑니다.
아희 2015 스펙이 정의중이란 뉴스를 들을 수 있었습니다.
[아희 공식 저장소에서 참여](https://github.com/aheui/aheui.github.io/issues/8)하실 수 있습니다.

## 다음 행사(?)

아희를 만들 수 있게 훈민정음을 창제해주신 세종대왕상 앞에서 사진을 찍었습니다.
한글을 이렇게 쓰라고 창제하신게 아닌 것 같지만 기분 탓입니다.

## 뒷풀이

<blockquote class="twitter-tweet" lang="ko"><p lang="ko" dir="ltr">아희콘 참석자들은 종로를 배회하다 치킨&amp;호프를 발견하자 아무 이의없이 이미 합의된 것처럼 자연스럽게 들어갔다</p>&mdash; 돌숲 (@redomichi) <a href="https://twitter.com/redomichi/status/652423240577486848">2015년 10월 9일</a></blockquote>

치킨을 먹었습니다. (후략)

## 말말말

너무 많아서 그냥 기억나는 것 몇개만 뽑아보았습니다.

> 갆갉가

알파희 개발단계에서 안녕하세요가 나오게 돌렸을때 나온 결과물. 다들 인삿말로 사용중. (...)

> 반반나

치킨을 반씩 나눠서 먹으면서 한 말

> 나보고 그걸 또 만들라고?

lifthrasiir님의 아희 2015를 대비한 아희아희 새 구현 요청에 대한 반응

> 종찬님이 너무 불편한 자세로 앉아(?)계셔서 찍어놓고 싶다

제가 한 말입니다. 거의 요가 수준이었는데 본인은 편하셨다고...

## 후기

상당히 유쾌한 한글날이었습니다.
온라인에서만 뵙된 개발자분들을 뵈니 좋았었고, 다음 대회가 열릴 수 있으면 좋겠네요. (웃음)

[^1]: 맆님 왈, "아희에 대해 이렇게 많은 얘기를 들을 수 있을 준 몰랐어"

<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>


국제 아희 개발자 대회 참가 후기

국제 아희 개발자 대회


대학 동기들이 취업을 해야할 시기가 되자 자기소개서 쓰는 법으로 난리입니다.
저는 그에 관련해서 상당히 많은 질문을 받고 있는데[^1], 다들 상투적이고 재미 없는 자기소개서를 쓰는 것 같아서 제가 생각하는 _그나마 나은_ 자기소개서 쓰는 법을 공유하고자 합니다.
*그나마 나은*이라고 적은 이유는 대부분의 회사들이 자기소개서를 **이유 없이** 받고 있다고 생각하기 때문입니다.
저는 최선의 취업 전략을 입사 지원때 필요하지 않은 것을 요구하지 않는 회사에 지원하는 것이라고 생각하지만, 그래도 어쩔 수 없는 경우의 제 주변 사람들을 위해 이 글을 적습니다.

제 공략법은 간단합니다.
자기소개서의 각 항목 명 앞에 "**이 직장에 오기 위해 내가 해온**"을 붙이는 겁니다.
가령 성장배경이라면 이 직장에 오기 위해 내가 해온 성장 배경, 즉 이 직장에 오기 위해 해온 나의 노력들이 되는 것이죠.
왜 이렇게 바꿔야 하는 이유는 다음과 같습니다.

1. 보통 자기소개서는 대충 읽고 던집니다. 당신의 다른 서류(이력서 등)이 매력적이지 못했다면 당신의 서류가 던져질 곳은 쓰레기통입니다.
2. 보통 자기소개서에 상투적인 문구, 예를 들면 성장 배경에 "저는 n남n녀 중 n째로 태어나서.." 이런 것을 적는데, 이런 이야기는 입사 담당자 입장에서 궁금할 사항이 **아닙니다**.
3. 입사지원을 위해 해야 할 전략은 이 서류를 보고 "이 사람을 꼭 면접장에 불러서 어떤 사람인지 보고 싶다" 라는 인상을 남기는 것입니다. 당연히 이 직장과 관계 있는 이야기를 적어야 눈에 띄겠죠?

눈에 띄는 자기소개서가 되려면 당연히 읽는 사람 입장에서 원하는 이야기를 해줘야 합니다.
예를 들어 웹 개발자로 지원하면서 자기소개서에 "성장 배경"을 작성한다고 칩시다.
저라면 이렇게 적을 것 같습니다.

> 저는 어렸을때부터 컴퓨터에 관심이 많아서 초등학교의 방과후 학교인 컴퓨터 자격증반을 자원하여 수강하였습니다.
> 그렇게 컴퓨터를 배우던 중 HTML으로 만들어지는 웹 페이지가 너무 신기하게 느껴졌고, 중학교 즈음에서부터 본격적으로 PHP를 배워서 자신만의 홈페이지를 만들어 나가기 시작했습니다.
> ...(이하 생략)

회사 입장에서는 이 사람이 어떤 학습 과정을 거쳐서 어떤 기술을 사용할 줄 아는지 구체적인 자료를 볼 수 있게 됩니다.
제 생각엔 이력서는 자신의 능력에 대한 규격화된[^2] 문서라면, 자기소개서는 자신의 능력에 대한 스토리텔링이라고 봅니다.
굳이 자신이 몇남 몇녀였는지, 어떤 가정에서 태어났는지 같은 건 적을 필요가 없는 것이죠.

또 하나 주의할 점이라면 **맞춤법과 표기법**을 준수하는 것 정도 일 것 같습니다.
저도 맞춤법은 잘 지키진 못하고 있지만, 최대한 지켜보려고 노력하는 편입니다.
검사기로는 부산대 맞춤법 검사기를 사용하면 좋습니다.
그리고 표기법도 상당히 중요하다고 생각하는데 고유명사나 단위명 등이 그에 해당합니다.
가령 MySQL에 대한 이야기를 적으면서 "저는 *마이SQL*을 사용해서 ~~~" 이런 식으로 잘못된 표기법을 쓰면 읽는 사람이 얼마나 당혹스럽겠습니까?

그리고 이것도 제 사견인데, **[Buzz words](http://www.urbandictionary.com/define.php?term=buzz+words)를 이유 없이 쓰지 않는 것**도 매우 중요하다고 생각합니다.
예를 들면 "글로벌", "클라우드", "세계화" 같은 말들 말이죠.
정말 클라우드 서비스를 만들었다면 클라우드란 단어를 안 쓸 수 없겠지만, 클라우드랑 전혀 관계 없으면서도 클라우드란 단어를 집어다 쓰는 것은 나쁘다는 의미입니다.
정말 특이한 곳이 아니라면 서류를 읽는 사람들도 해당 분야의 종사자 입니다.
쓸데 없이 미사여구를 붙였다가 해당 분야의 종사자들의 눈에 "허세를 부린다"라는 느낌을 주면 좋을게 없을 것입니다.

[^1]: 당연하지만 저는 취업 관련 전문가가 아닙니다. 물어볼 곳이 없어서 제게 물어보고 있다고 생각합니다.
[^2]: 여기서 규격화라고 한 것은 줄글이 아니라는 의미입니다. 당장에 제 이력서만 하더라도 일반적인 표준 이력서의 양식을 따라하지 않았죠.


다들 상투적이고 재미 없는 자기소개서를 쓰는 것 같아서 제가 생각하는 그나마 나은 자기소개서 쓰는 법을 공유하고자 합니다.

내가 생각하는 그나마 나은 자기소개서 쓰는 법


이번에 오랫동안 알고 지냈던 소프트웨에 마에스트로 5기 김강인군을 도와 모 사이트에 SSL을 적용하는 작업을 하게 되었습니다.
이 글은 그 과정의 문서화입니다.

## 1. EC2 instance 생성

제가 갔을땐 이미 되어있었습니다.
따라서 이 부분은 생략합니다.
EC2 instance 생성법이 필요하신 분은 [아마존 웹 서비스를 다루는 기술 4장 내용](http://www.pyrasis.com/book/TheArtOfAmazonWebServices/Chapter04)을 추천합니다.

이 글에서 전제로 하는 것은 EC2에 80번 포트를 사용하는 **HTTP** 기준으로 세팅된 웹 서버가 있는 것입니다.

## 2. SSL 인증서 발급

Comodo인증서를 대행해주는 곳을 통해 작업했습니다.
인증서 발급 방법은 각 인증사마다 다르므로 문서화 하지 않습니다.
인증서를 발급받으면 Public Key, Private Key, Chain값을 받을 수 있습니다.
이 글에선 앞으로 이 값들을 이용합니다.

## 3. ELB 생성

※ 여기서부터 작업 내용은 AWS가 개편되면 달라질 수 있습니다.
개략적인 내용은 같을 것이므로 순서가 바뀌더라도 염려하지 않으셔도 됩니다.

### 3.1. 생성 버튼 클릭

[AWS Console](https://aws.amazon.com/ko/console/)에 로그인 한 뒤, EC2 > Load Balancers 메뉴로 들어갑니다.
`Create Load Balancer` 버튼을 클릭합니다.

![Create Load Balancer](01.png)

### 3.2. Step 1: Define Load Balancer

그러면 다음과 같은 화면이 나옵니다.

![Step 1: Define Load Balancer](02.png)

`Load Balancer name`의 경우 중복되지 않는 값으로 정해줍니다.
나머지 값들은 그대로 둡니다. `Listener`는 기본 값으로 HTTP만 있는데 좌측 하단의 `Add` 버튼을 클릭하여 스크린샷과 같이 `Load Balancer Protocol`는 `HTTPS (Secure HTTP)`로 설정해주시고 나머지는 그대로 두면 됩니다.(`Load Balancer Port`값이 자동으로 443으로 변경될 것입니다)
다음 단계 진행을 위해 `Next` 버튼을 클릭합니다.

### 3.3. Step 2: Assign Security Groups

![Step 2: Assign Security Groups](03.png)

이미 가지고 있는 Security Group이 있으시다면 재활용해도 되지만 이번엔 새로 만들도록 하겠습니다.

![Create a new security group](04.png)

손 댈것이 없습니다.
혹시라도 이름이 바꾸고 싶으시다면 `Security group name`값만 수정해주시면 됩니다.
저는 혼동을 피하기 위해 `ELB-security-group`이라고 지정해주었습니다.
다음 단계 진행을 위해 `Next` 버튼을 클릭합니다.

### 3.4. Step 3: Configure Security Settings

#### 3.4.1. Select Certificate

아마 처음 진행하시면 인증서를 올리신 적이 없으실 것이므로 인증서를 새로 올리는 절차를 거쳐야 합니다.
`Certificate Type`에서 `Upload a new SSL Certificate` 를 선택합니다.

이제 여기서부턴 #2에서 받았던 인증서가 필요해집니다.
인증서 파일들을 text editor로 열어주세요.

![Upload a new SSL Certificate](05.png)

##### 1. Certificate Name

인증서들을 구분하는 이름입니다.
중복은 불가능합니다.

##### 2. Private Key

파일 중에 다음과 같은 형식으로 구성된 파일이 존재할 것입니다.
해당 파일의 내용을 **한 글자도 빠짐 없이** 그대로 Copy&Paste 해주시면 됩니다.

```
-----BEGIN RSA PRIVATE KEY-----
SOME CONTENTS
-----END RSA PRIVATE KEY-----
```

##### 3. Public Key Certificate

파일 중에 다음과 같은 형식으로 구성된 파일이 존재할 것입니다.
Private Key와 동일한 방식으로 해당 파일의 내용을 **한 글자도 빠짐 없이** 그대로 Copy&Paste 해주시면 됩니다.

```
-----BEGIN CERTIFICATE-----
SOME CONTENTS
-----END CERTIFICATE-----
```

##### 4. Certificate Chain

Optinal이라고 적혀있는데 안적으면 인증서가 Self-signed 취급당합니다.
SSL을 신청하면 받을 수 있는 파일 중에 Chain과 관련된 파일만 모아져있는 디렉토리(폴더)가 있을 것입니다.
인증사별로 Chain의 설정방법은 다르므로 간단히 언급만 하자면, Intermediate certificate가 1개 이상 존재하고 Root certificate 이 1개 존재합니다.
Certificate Chain란에는 다음과 같은 형식으로 적어주시면 됩니다.
(맨 마지막이 Root Cert로 끝나야만 합니다)

```
-----BEGIN CERTIFICATE-----
Intermediate certificate 2
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Intermediate certificate 1
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Root certificate
-----END CERTIFICATE-----
```

#### 3.4.2. Select a Cipher

![Select a Cipher](06.png)

특별한 사유가 있으신 것이 아니라면 `Predefined Security Policy`에 정의되어 있는 것 중 가장 최신의 것을 사용하시면 됩니다.
다음 단계 진행을 위해 `Next` 버튼을 클릭합니다.

### 3.5. Step 4: Configure Health Check

![Step 4: Configure Health Check](06.png)

ELB가 각 instance가 사용가능한지 확인할 방법을 정의합니다.
저의 경우 웹 서비스이므로 무난하게 HTTP를 선택했습니다.
이 경우 `Ping Path`만 수정해주시면 됩니다.
`Ping Path`는 서버가 살아있을때만 접속 가능한 주소여야 합니다.
저의 경우는 `/heart_beat/` 라고 지정해주었습니다.

이제 실제 EC2 instance에 있는 서버에도 약간의 수정이 필요합니다.
저는 Python 개발자이므로 Django와 Flask 기준으로 예를 들겠습니다.(언어/Framework 선택과는 아무 상관 없는 부분)
설정을 마치신 뒤에는 다음 단계 진행을 위해 `Next` 버튼을 클릭합니다.

#### 1. Django

```py
from django.conf.urls import url
from django.http import HttpResponse


def heart_beat(request):
    return HttpResponse("It's Works!", content_type='text/plain')

urlpatterns = [
    ...,
	url('^heart_beat/', heart_beat),
]
```

`urls.py`에 설정해주시면 됩니다.
(당연하지만) view가 굳이 `urls.py`에 같이 있을 필요는 없습니다.

#### 2. Flask

```py
...

@app.route('/heart_beat/')
def heart_beat():
	return "It's Works!"
```

### 3.6. Step 5: Add EC2 Instances

![Step 5: Add EC2 Instances](08.png)

ELB로 묶을 EC2 instance들을 모두 선택해주시면 됩니다.
다음 단계 진행을 위해 `Next` 버튼을 클릭합니다.

### 3.7. Step 6: Add Tags

추가하실 Tag가 있으면 추가하시면 됩니다.
`Review and Create`를 클릭합니다.

### 3.8. Step 7: Review

잘못 설정한 것이 없는지 확인하신 후 `Create`를 클릭합니다.
몇분 정도 소요된 후 ELB가 활성화됩니다.

## 4. Domain 연결

AWS Services 중 Route 53으로 들어갑니다.
저의 경우는 이미 Hosted Zones가 생성되어 있었으므로 생성 과정은 생략합니다.
생성법이 필요하신 분은 [아마존 웹 서비스를 다루는 기술 17장 내용](http://www.pyrasis.com/book/TheArtOfAmazonWebServices/Chapter17)을 추천합니다.

생성/수정시에 유의하실 부분은 A Record의 설정법입니다.
보통 EC2만을 사용한다면 Elastic IP를 상대로 지정을 하겠지만, 우리의 경우에는 ELB에 도메인이 연결되어야만 하고, ELB에는 Elastic IP를 붙일 수 없습니다.
따라서 Alias 기능을 사용합니다.

![Alias](09.png)

`Alias`는 Yes를 선택하시고, `Alias Target`은 ELB를 선택해주시면 됩니다.
ELB를 Primary/Secondary로 구성하실 경우 `Routing Policy`를 Failover로 선택해주시면 됩니다.(ELB가 2개 필요합니다.)

## 5. Test

접속이 되나 확인해보시면 됩니다. :)


AWS의 EC2 instance 앞에 ELB를 두고 접속시 HTTPS가 적용되도록 해보았습니다.

item4 dev story

Posts