Github 페이지를 이용해서 이력서 만들기

삽질 기록 2018.09.27 21:31 Posted by 아는 개발자 아는 개발자

이력서를 웹사이트에 공개하는 방법으로 LinkedIn을 사용하는 것이 가장 간단하고 대중적이지만 포맷이 정해져 있어 심심하고 다른 사람들과 차별화를 줄 포인트가 없다는 것이 단점이다. 그래서 일부 개발자들은 자신의 이력서를 HTML 형태로 이쁘게 디자인하고 호스팅을 해서 다른 사용자가 쉽게 볼 수 있게끔 만든다.


링크드인 보다 덜 식상한 것 같다


그런데 이력서 한 장 띄우자고 유료 웹 호스팅 서비스를 이용하는 건 부담스러운 일이라 개발자들은 Github에서 저장소 별로 제공하는 페이지 기능을 활용해서 이력서를 만든다. 깃허브 페이지 기능이 궁금하신 분들은 이 사이트에서 친절히 설명하는 영상이 있으니 참고하길 바란다. 자세한 사용 방법은 알려주지 않는 것 같다.


사실 페이지 기능을 사용하는 법을 몰라도 이미 개발자들이 resume-template을 많이 만들어 둬서 가져다가 쓰면 간편하다 나는 https://github.com/jglovier/resume-template  template을 사용하고 있는데 템플릿이 이쁘고 수정하는 방법도 쉬워 잘 사용하고 있다. 이번 포스트에서는 이 템플릿을 이용하는 방법을 간단히 다룬다.


0. Github 계정 만들기


계정이 없다면 https://github.com/ 사이트로 가서 계정을 하나 만든다. 이미 있으면 패쓰 


1. Github resume template 저장소 fork하기


https://github.com/jglovier/resume-template 저장소를 내 저장소로 Fork한다. Fork는 원격 저장소를 미러링한 형태로 내 저장소에 복사하는 기능인데 원리는 몰라도 상관 없다. 아래 그림의 맨 오른쪽 버튼을 누르자.



2. 저장소 이름 바꾸기


Fork가 완료되면 내 저장소에 resume-template이라고 저장소가 생긴다. 저장소 이름을 토대로 이력서 웹페이지 주소가 설정되니 괜찮은 이름으로 바꾸자. resume-template 버튼을 클릭하고 Setting Tab을 누르면 이름을 수정 할 수 있다. 




3. 내 페이지가 보이는지 테스트


변경한 이름을 토대로 저장소의 웹페이지에 접속해보자. { 사용자 ID }.github.io/{ 변경한 저장소 이름 } 으로 접속하면 아래 그림과 같은 페이지가 나온다. 


Github 404 접속 에러 페이지가 나오는 경우도 있는데 이런 경우에는 10~15분 정도 후에 다시 접속하면 된다. 적용되는데 시간이 어느정도 소요 되는 것 같다.




4. 프로필 정보 업데이트하기


Lisa Simpson으로 되어 있는 현재 페이지를 내 프로필에 맞춰서 바꾸자. _config.yml 파일과 _data/ 폴더 안의 내용들을 바꾸면 현재 포맷을 유지한 상태로 쉽게 업데이트 할 수 있다. 코드가 직관적이니까 영어만 사용할 줄 알면 부담 없이 수정이 가능하다.


ruby와 jekyll에 능숙한 사람들은 포맷을 간단히 수정해봐도 좋을 것 같다. 나는 잘 모르겠다오. 


5. 로컬 서버에서 확인


수정한 정보를 서버에 올리기 전에 아래 명령어를 이용해서 로컬 서버에서 확인 해보고 가자. 


0. cd "이력서 저장소 위치"
1. bundle install // 처음에만
2. bundle exec jekyll serve


첫번째 명령어는 저장소에서 들고있는 ruby 패키지들을 설치하는 작업이니 딱 한번만 실행하면 된다. 두번째 명령어는 현 저장소에 있는 jekyll 프레임워크(이렇게 부르는게 맞나?)를 실행하는 명령어다. 실행하고 나서 크롬이나 파이어폭스를 열고 주소 창에 localhost:4000을 입력하자. 코드에 문제가 없으면 아래처럼 이력서 페이지가 나온다.




* 가끔 bundle install 하다가 1.9.21 버전을 설치 할 수 없다는 에러가 뜨는데 이때는 이 패키지들을 설치하면 된다.

sudo apt-get install ruby-dev
sudo apt install libffi-dev


6. 수정된 정보 업데이트


로컬 서버에서 문제가 없으면 수정한 코드를 저장소에 커밋한다. 1~2분 정도 지나야 커밋한 내용이 반영되니 바로 업데이트가 되지 않았다고 초조해하지 마시길. 


커밋하는 방법이 모르시는 분은 간단히 아래의 코드를 입력해서 업데이트 할 수 있다.


git add -A
git commit -m "Update resume info"
git push origin gh-pages


말하기와 듣기 - 개발자로서 갖춰야할 기본 덕목

2017.11.18 16:56 Posted by 아는 개발자 아는 개발자

  대학교 1학년 이었던 것 같습니다. 학창시절 리눅스는 커녕 윈도우 커맨드 창 한번 두들겨 본 적이 없을 정도로 개발에 무관심 했던 저는 오로지 취업 안정성 하나만을 바라보고 컴퓨터 공학부에 입학 했습니다. 전공 선택의 목적이 컴퓨터에 대한 흥미나 학문의 대한 열망 보단 먹고 사는 문제를 해결하는 것이었고 당시 신문과 뉴스에선 대기업 개발자들의 희망 퇴직, 사오정 같은 고용불안정에 대한 기사를 쏟아냈기 때문에 자연스럽게 저의 학부 시절의 목표는 '뛰어난 개발자가 되어 이 직업으로 오래오래 먹고 사는 것'이 됐습니다. 다소 엉뚱하고 현실적인 목표를 세우면서도 철학적인 질문이 들었습니다. 뛰어난 개발자'란 어떤 사람을 일컫는 것일까요?


 참 속시원하게 답하기 힘든 질문인 것 같습니다. 도대체 어떤 기준으로 개발자들의 뛰어남을 측정 할 수 있을까요? 개발자 랭크를 매기는 사이트가 따로 있는것도 아닌데 말이죠. 이 질문에 대한 답변에 앞서 다른 직업 영역에서 정한 뛰어남의 기준을 생각해봅시다. 호날두와 메시 같은 축구선수들은 매우 객관적인 수치로 평가 받습니다. 공격수는 넣은 골의 수로, 공수를 조율하는 미드필더는 볼 점유율로, 수비수와 골키퍼는 실점 수로 판단 받습니다. 경기가 끝날 때마다 해설위원들이 선수별 개인 평점도 매겨줍니다. 해설 위원들 마다 선호하는 스타일이 있지만 대체로 공통된 의견으로 수렴됩니다. 의사와 변호사는 평점과 같은 객관적인 수치는 없지만 평가 척도는 명확합니다. 의사의 본 업무는 환자의 건강을 보살피고 약과 도구를 통해 병을 치료하는 일이고 변호사는 의뢰인의 법률적인 고민을 해결하는 일을 합니다. 물론 훌륭한 성품까지 지니면 더 좋겠지만 본업을 잘하는것 만으로도 뛰어난 의사 또는 변호사라고 평가하는 것에는 별다른 이견이 없을 것 같습니다. 


사진 1. 축덕들의 유명한 떡밥인 메시vs호날두 입니다. 스탯 상으론 메시가 좀더 앞서는것 같네요(2015년기준)


  모든 직업 마다 자신이 현재 하고 있는 일을 잘하는 사람을 뛰어난 사람을 평가 할 수 있는 것 같습니다. 개발자도 동일한 기준을 적용해 봅시다. 개발자는 개발을 하는 사람이니 개발을 잘하는 사람이 뛰어나다고 할 수 있겠지요?. 그리고 개발을 잘한다는 것의 기준은 다양한 기술 지식을 겸비하며 다른 사람들이 해결하지 못한 기술적인 어려움들을 척척 풀어내는 사람을 뛰어난 개발자라고 명할 수 있을 것 같습니다. 학부시절엔 이 기준에 맞춰 뛰어남을 평가 했던 것 같습니다. MacOS와 비교했을 때 윈도우가 얼마나 볼품없는 운영체제인지를 설명하던 친구가 새삼 대단해 보였고(지금 생각해보면 터무니없는 근거들 이었습니다) 학점은 바닥이었지만 알고리즘 대회에서 우수한 성적을 거두고 목에 힘주고 다니는 친구들이 부러웠습니다. 이런 친구들이 장차 뛰어난 개발자가 될 것이라고 생각했습니다.


 그런데 막상 실무에 들어가면 개발을 잘한다는 것의 기준이 매우 모호해집니다. 의사와 변호사와 다르게 개발자는 개인의 역량이 미치는 크기가 다소 제한적이기 때문입니다. 물론 혼자 일하는 경우나 소수 팀에선(2-3명) 영향력이 크겠으나 중규모 팀(5명 이상)에서 부터는 미미해집니다. 이유는 간단합니다. 혼자서 모든 일을 할 수 없기 때문입니다. 팀원의 수가 늘어나면서 프로젝트의 스케일은 커지게 되고 필요한 도메인 지식은 깊고 넓어집니다. 인간의 뇌가 아무리 무한한 능력을 지니고 있다곤 하지만 이 모든걸 혼자 습득하고 기술적 난제들을 해결하긴 쉽지 않습니다.


  실무에서 맞서게 되는 기술적인 문제는 교과서의 범위내에서 출제되는 수능 시험 문제와 다릅니다. 그쪽 방면의 지식이 없어 어쩌면 쉽게 풀릴 수 있는 문제를 며칠 째 골골 싸매고 있을 수도 있고 쉽게 풀릴 것이라고 생각 했던 것이 전혀 예상하지 못했던 에러로 당황하게 될 수도 있습니다. 리눅스 오디오 드라이버를 개발하는 팀을 예로 들어 봅시다. 리눅스 오디오 드라이버를 개발하기 위해선 일단 오디오에 대해서 정확하게 알고 있는 개발자가 필요합니다. 개발하려는 드라이버가 리눅스 타입이니 리눅스에도 정통한 사람이면 좋겠지요? 하지만 여기서 끝이 아닙니다. 리눅스에서 진동수를 관리하는 메커니즘과 오디오 정보의 전달 방식에 대한 것도 빠삭해야 합니다. 이것 저것 다 고려하니 인터럽트도 알아야하고 DMA도 알아야 하게 됐습니다. 리눅스와 오디오만 알면 될 줄 알았는데 예상외로 공부 할 것이 많습니다. 혼자 하기엔 벅찬 양입니다


사진 2. 마크 저커버그 혼자선 페이스북의 모든 기능을 만들 순 없었을 것입니다.


 결국 개발할때는 내가 모르는 것을 아는 사람과 같이 일해야 합니다. 이러면서 대두되는 것이 개발과는 전혀 무관 할 것 같았던 말하기와 듣는 능력입니다. 우리의 약점이기도 하지요? 실무에서 개발하게 되면 다른 사람이 물어보는 것을 설명해주기도 하고 내가 어떤 것을 모르는 것을 질문하기도 해야 합니다. 그런데 참 쉬워보이는게 예상외로 무척 어렵습니다. 내 머릿속에선 이미 완벽한 메커니즘이 잡혀있는데 이걸 옆에 있는 사람에게 설명하자니 뭐 부터 말해야 할지 감이 오지 않습니다. 들을 때도 속이 타긴 마찬가지입니다. 동료는 전문적인 용어를 쏟아내면서 말하는데 내겐 생소한 단어들입니다. 5분 넘게 대화했는데 머릿속에 남는건 없습니다. 이해가 되지 않아 다시 찾아갑니다. 이제 슬슬 짜증나는 티를 내기 시작합니다. 끝내 이해는 했지만 자존심이 상합니다.


사진 3. 사실 말하고 듣는건 모두 초등학교때 배웠던 내용입니다


  '말 할때는 청자의 입장을 고려해서 말하고 들을 때는 상대방의 말을 끝까지 집중해서 들어야 한다'고 배웠습니다만 개발팀에선 잘 이뤄지지 않고 있습니다. 개발자 특유의 아집 때문인지 남들이 모르는 지식을 전달이 아니라 뽐내고 싶어하기도 하고 상대방의 발언 중에 잘못된 것이 있으면 발언자에게 망신을 주면서까지 잡아내기도 합니다. 망신을 준 사람이 아무리 기술적 깊이가 뛰어난다고 해도 그 사람과는 아무도 같이 일하고 싶어하지 않게 됩니다. 이런 사람이 한사람이라도 있으면 팀내 전체 분위기가 흐트러집니다. 결과적으로 팀원들의 개인별 역량은 출중할지도 모르지만 팀의 역량은 그 합이 아니라 그 이하가 되버리고 말겁니다. 


 아직 어떤 사람을 뛰어난 개발자라고 말할 수 있을지는 모르겠습니다. 하지만 기술적 난제를 척척 해결하고 도메인 지식이 깊고 넓더라도 말하기와 듣는 능력이 부족한 사람을 뛰어난 개발자라고 할 순 없을 것 같습니다. 개발은 혼자 할 수 있는 일이 아닙니다. 운동경기만큼 팀플레이가 중요한 일입니다. 나 혼자 잘났다고 다른 팀원을 밟고 올라서려 한다면 개인플레이로 팀을 망치는 선수일 뿐입니다. 혼자선 즐거울 수 있지만 결코 팀에는 도움이 되지 못하는 개발자이지요. 뛰어난 개발자가 되기에 앞서 과연 나는 팀에 도움이 되는 개발자인지 고민해볼 필요가 있지 않을까요?


사진 1. 메시vs호날두 끝나지 않은 전쟁 http://news.donga.com/3/05/20150509/71146083/1