Showing posts with label review. Show all posts
Showing posts with label review. Show all posts

Thursday, December 5, 2019

Book review - 그래서 컴퓨터는 어떻게 동작하나요?

그래서 컴퓨터는 어떻게 동작하나요? - 10점
J. 클라크 스코트 지음, 지유록 옮김/인사이트

컴퓨터의 기본 동작방법에 대한 설명이 잘 나와 있는 책이다.

이걸 보고 느꼈던 점은 20년 전에 대학 학부시절에 배웠던 논리회로 공부했던 것과 컴퓨터 구조와 원리 과목떄 공부했던 내용들이 떠올랐다는 것이다. 그렇다는 것은 컴퓨터의 기본 원리는 변하지 않고 동작 방식 역시 크게 바뀌지 않았다는 뜻일 것이다.

특히 비전공자들이 코딩하는 방법을 배우고 실무에 들어가서 일을 하는데 있어서 가끔 "전공 지식을 공부하는건 어떨까?" 싶다는 생각이 들기도 할 건데 그때 이책을 보면 된다. 국내 대학에 컴퓨터 전공 학부생 1,2학년 생이라면 이 내용을 반드시 배우게 되어 있기 때문이다. 그리고 실제 코딩하는 것과 크게 상관이 없어 보인다는 현타가 오면 전공자들이 흔히 농담식으로 얘기하는 "전공 공부 할 필요 없다"가 무슨 뜻인지 알게 될 수도 있다.

실제 코딩하는 데 있어서도 조금 이해가 되고 도움이 될 만한 부분은 bit, byte 간의 관계 그 연산 방법 bit shift가 뜻하는 것도 자연스럽게 알 수 있으며 and, or, not 같은 코딩 문법의 진짜 원리를 알 수 있는 기본적인 걸 논리 회로도와 함께 알 수 있게 된다.

다 읽고 나면 컴퓨터가 이런 원리로 동작 하는 구나를 알 수 있는데 컴퓨터 이론서가 필요하긴 한데 교과서 적인거 말고 교양서 수준으로 읽고 싶은 사람한테는 좋은 책일 것 같다.

Monday, November 25, 2019

book review - 나는 LINE 개발자입니다.

나는 LINE 개발자입니다 - 10점
강윤신 외 지음, LINE Developer Relations 팀 엮음/한빛미디어
오랜만에 쓰는 책 리뷰이다.

책 내용이 무겁지도 않은데다가 LINE 개발자의 LINE 입성기, LINE 자랑 정도의 글인데 순식간에 읽어 나갔다. 심지어 같은 사람이 쓴 글이 아닌 12명의 개발자들이 쓴 글이라 글 스타일이 다른데도 말이다.

크게 느끼는 부분이 몇 가지가 있어서 적어본다.
  • 정말 중요하고 소중하게 느껴지는 코드 리뷰의 문화
    • 나의 경우에도 제대로된 코드 리뷰를 해 본지도 꽤 오래된거 같다. 모두 각자 맡은 프로젝트가 있고 바쁘다 보니 코드 리뷰는 거의 사치가 되어 간다. 나는 내 코드를 스스로 리뷰한다. 리뷰-리팩토링-고민-리뷰로 이어지는 스스로의 리뷰는 남들과 함께 하는 리뷰에 많이 목이 마르다.
    • 그렇다고 회사에서 코드 리뷰를 하지 말라고도 하지 않았고, 해도 큰 문제는 없어 보인다. 그렇지만 뭔가 더 생산적인 일을 해야 한다는 느낌을 강하 받는다. 그건 누가 얘기하지도 않고 강요한 사람도 없지만, 모인 사람들의 분위기가 그렇게 되는 것 같다.
    • 라인은 대기업인데도 스타트업(?)의 느낌을 살려 팀 단위로 일을 하고 코드리뷰를 한다고 한다. 코드리뷰를 잘 하고 못하고의 문제가 아니라 한다는 게 권장되는 문화가 매우 부럽다.
  • 문서화의 중요성
    • 이건 나도 100% 동감하는 부분인데, 문서화는 정말 중요하다.
    • 라인에서도 역시 문서화를 중요하게 생각하는데 내가 생각한거 보다 더 많은 문서를 작성하는 거 같다. 팀이 모든 문서를 보고 공유를 한다고 하고 팀의 누구와 얘기해도 내용이 공유가 된다고 하니, 이것 또한 부러울 따름이다.
    • 그렇다고 회사에서 문서화를 안하느냐 그런건 아니다. 업무 진행과 이슈에 관련된 문서는 다른 회사들도 마찬가지로 잘 적는 편인데, 기술 문서에 대한 부분이 조금 부족한 것 같다. 나는 그런 문서가 중요하다고 생각해서 잘 적는 편이지만 공유가 된다기 보다는 그냥 참고용 정도로만 취급하는 정도라 중요도에 있어서는 크지는 않다.
  • 스스로 해야 할 일을 찾는 자율성
    • 이건 우리 회사도 크게 다르지는 않지만, 방향이 좀 다르다.
    • 라인은 해야 할 일을 찾아서 하지만 팀원들과 함께 부족한 부분을 찾는다던가 지속적으로 대화하고 공유하는 형태이다.
    • 우리 회사는 도달해야 하는 목표치를 정해 놓고 그 안에서 자율적으로 움직인다. 협업이라기 보다는 이슈가 생기지 않게 잘 하고 보고를 하는 형태라 조금 그 느낌이 다르게 느껴진다.
    • 다만, 개발쪽으로는 최대한 많은 자율성을 보장해 주므로 필요하다면 얼마든지 원하는 기술과 할 일을 찾아서 할 수 있긴 하다.
책에 나온 사람들은 뭔가 대단한걸 했던 사람들이고 당연히 이런 사람들이 LINE에서 일한다는 어떤 예시를 든거 같다. 그건 어떻게 보면 좋은 조직의 문화가 좋은 사람들을 모이게 한다는 뜻이기도 할 것이다. 우리 회사도 그런 문화를 가진 회사로 발전했으면 좋겠고 거기에 내가 많은 참여와 기여를 할 수 있었으면 한다.

Thursday, March 14, 2019

프로그래머가 되기 까지의 회고 (5) - 복학 후 각성할 때 까지

프로그래머가 되기 까지의 회고 (1) - 초등학교 시절
프로그래머가 되기 까지의 회고 (2) - 중고등학교 시절
프로그래머가 되기 까지의 회고 (3) - 대학 입학 부터 군 입대 전까지
프로그래머가 되기 까지의 회고 (4) - 군 시절

----

2001년 복학 했을 당시에도 공부를 열심히 하지 못했던 것 같다. 막연한 진로는 게임 프로그래머이긴 했지만 자신이 없었다. 당장 수업듣는 과목들도 자료구조, 마이크로프로세서, 이산수학 등 또 이론적인 과목들 뿐이었고 과제로 내주는 C 언어 프로그래밍은 동기나 후배들꺼 보고 겨우 이해해서 수정해서 내는 수준이었다.

지금은 상상할 수 없지만 그 당시만 해도 강의실에 흔한 빔프로젝터나 PC 같은게 있지 않았었다. 새로 지은 건물에는 구축이 되어 있었지만 80~90년대 부터 쓰던 강의실에는 그런걸 설치해 두지 않아서 누군가 수업시간 전에 빔 프로젝터와 노트북PC를 세팅해야 하는 일을 해야 했다. 물론 과대라 읽고 심부름꾼(시다바리)이라 쓰는 사람이 한다.

사실 과대가 될 생각은 해보지도 못했고 전혀 그런걸 할 생각도 없었는데, 어떤 계기로 인해 졸업할 때 까지 과대 혹은 반장이 되었다.

복학 후 자료구조 첫 수업 시간이었다. 지금도 그러는지 모르겠는데 첫 수업 시간은 대략적인 강의 설명, 리포트, 과제, 시험방식 점수 산정 방법 등등을 설명하고 1시간이 채 되지 않은 시간에 끝냈는데, 그때도 그랬다.

교수님이 대충 설명 끝날 때 쯤에 매 수업시간 마다 빔프로젝터와 노트북PC를 세팅할 사람(호구) 손 들라고 했다. 물론 아무도 손을 들지 않았다. 교수님이 혹하는 제안을 했는데 무려 2만원에 달하는 자료구조 책을 준다고 했다. 그래도 아무도 손을 들지 않았다. 무슨 생각이었는지 그 책을 그냥 갖고 싶다는 생각이 들었다. 그래서 손을 들었는데 바로 당첨되었다.

그후 모든 수업마다 내 동기들과 후배는 이런 일을 할 사람을 찾는 교수님의 눈빛을 보면 "반장~"을 외쳐댔고 그게 내가 되었다. 그렇게 계속 심부름 하면서 다니고 과대도 되었다. 그렇게 졸업할 때 까지 우리 반의 충실한 심부름꾼이 되었다. 기억에 남는건 학교에서 주는 용돈 수준의 과대비와 교수님과 동기 후배들의 잡일 처리였다. 아직도 나를 부르는 동기들의 목소리가 머릿속에 맴돈다. "반장~!"

<얘네들이 하는 말 믿지 마.
왜요?
그냥 믿지마!
저 이미 과대인데요?
빨리 탈출해 어서!
출처: http://young.hyundai.com/magazine/campus/detail.do?seq=16532>

이제 개발 얘기를 해 보자면, 2학년도 마치고 3학년이 되었지만 난 여전히 그저 그런 흔한 컴공생이었다. 과제는 점점 더 어려워지고 있었고 배우는 프로그래밍 언어도 C에서 JavaScript, C++ 등 해야 할 게 더 많아졌다. 더 하기 싫어져서 PC방에서 게임하던가 동아리방에서 놀던가 하는 걸로 시간을 보냈다. 지금 생각해 보면 그렇게 시간낭비를 하지 말았어야 했지만, 그때는 코딩이 너무도 하기 싫었고 코딩 안하는 과목 쪽에 눈을 많이 돌렸다. 소프트웨어 공학이라던가 데이터베이스와 같은 과목들.

그러던 중 프로그래밍에 눈을 조금 뜨게 된 중요한 계기가 몇 있었다. 객체지향 프로그래밍이라고 해서 C++의 class 개념을 추가해 객체지향적인 프로그래밍 과정을 이해하는 과목이 있었는데 초반 과제는 그럭저럭 했다. 그러나 중반 이후가 되니까 class, object 에 대한 이해를 하지 못하면 C언어로 짜듯이 주먹구구식으로 할 수 밖에 없고 결국 할 수 없는 수준이 되다 보니 정말 시간을 내서 이해를 해야 할 시간이 닥쳐오게 됐다.

내가 제대로 모르고 하는 부분이 뭐가 있는지 탐색해 나가다 보니 결국 포인터 부터였다. 그래서 연습하고 이해하고 연습하고 이해하고를 학교 실습실, 집에서 계속 반복해 가면서 이해해 갔다. 변수 이름 앞에 * 붙였다가 뗐다 하면서 오류 나는지 확인하고, 역시 & 붙였다 뗐다 하면서 오류 나는지 확인하고를 계속 반복하면서 알아보고 스스로 깨닫고 이해해 나갔다. 어떤 날은 새벽까지 집에서 그 짓을 하고 있을 때도 있었고 그 동안 스스로 하지 못했던 과제들을 포인터를 쓰고 안쓰고의 차이를 직접 해 보면서 알아 가기도 했다. 학교에서는 오후 늦게쯤 항상 가던 동이리방도 안가고 실습실에 야간 수업 들으러 오는 친구들 수업 시작하기 전 까지 몰입해서 했을 때도 있었다. 이러다 보니 야간반 애들하고도 안면이 트고 친해지는 계기도 되고 야간반 과대랑 졸업여행 계획도 같이 세우게 된 좋은 계기가 생긴것도 덤이긴 했다.

한 2주 지나고 보니 포인터의 규칙이 선명해 지면서 다른 모르는 부분들도 조금씩 이해가 되기 시작했다. Swap 함수가 왜 포인터의 주소로 념겨지는지, 함수의 포인터를 왜 넘겨주는지도 알게 되었다. new를 하면 메모리가 heap에 생기고 포인터 주소를 잃어버리면 어떻게 되는지 등. 학기 마지막 쯤 되니까 이미 1, 2학년 때 배우고 알고 있어야 하는 걸 그제서야 알았다. 사실 남들보다 한참 늦게 알게 된 것이다.

<이런 원리도 모르고 이해도 못한 채 코딩을 했던 시절이 있었다는 것이다.
출처: https://slideplayer.com/slide/5097101/>

목돈도 굴리려면 종자돈을 마련해야 한다는 얘기가 있듯이, 포인터에 대한 개념과 이해라는 종자돈을 잘 챙겨 두니까 이후에 파일 입출력 같은 것들도 목돈 불리듯이 술술 풀리게 되었다. 이 때 부터 내가 스스로 "각성"이라 불리는 상태에 돌입했던 것 같다. 학기 마지막 과제가 자동판매기 시뮬레이터였는데, 그걸 class 구조로 짜 나가면서 이해를 하기 시작했고, 새벽에 후배들과 문자 메시지를 주고 받으면서 설명해 주고 자랑(?)도 하고 그랬다.

그 열기는 여름방학 때에도 계속 이어갔다. 그 당시에는 Win32 API나 MFC로 Window 프로그래밍을 하는게 대세여서 후배들과 학교에 모여 스터디도 하고 C++ 관련된 책도 읽다 보니 STL이나 Effective c++ 같은 책들도 같이 보게 됐다. 2학기가 되고 나서 부터는 왠만한 과제는 스스로 배우고 풀기 위해 시간을 더 쓰게 되었고 어떻게든 혼자 힘으로 해결해 보려고 애썼다.


<Java 수업 시간에 class와 객체지향 개념 조금 알려준 후에 교수님이 과제로 내준 게, 스네이크 게임 만들기였다. 그때만 해도 말도 안된다고 생각했는데, 하다 보면 또 좋은 훈련이 되기도 한다.
출처: 위키피디아 뱀 게임>


교수님들이 내주는 과제는 너무 빡셌지만 그럴 때 마다 해내려고 하다 보니 재미도 생기고 자신감도 생기고 그랬다. 2학기 때는 Java도 했는데, 빡센 Java 과제를 해 나가면서 C++과는 또 다른 객체지향 개념에 대해 이해를 해 나갔고, 2학기가 끝나갈 무렵이 되자 어렴풋이 다음과 같은 느낌을 받았다. 이제 프로그래밍 문법 몰라서 못하는 수준은 아니고 튜토리얼이나 API 문서 같은거 보고 조금 따라 쳐본 후에 계속 API 참고 해 가면서 해 나갈 수준 까지는 됐던 것 같다.

거의 1년이 채 안된 기간 안에 많은 걸 이루어 냈다. 객체와 메모리 덩어리들이 머릿속에서 array, sort로 움직이고 포인팅하는 화살표 선이 이어지는 상상까지 할 수 있을 정도였고, 이제 내가 대학에 온 이유를 실현하기 위한 마지막 힘을 쏟기 위해 3학년 2학기가 끝나갈 무렵 게임 프로그래밍 학원 6개월 과정도 다녔다.

Sunday, February 10, 2019

2018년 정리

일종의 회고 같은 글인데 나도 회고를 써 볼겸 해서 정리해 본다.

회사에서의 성과


프로젝트들


회사에서 진행한 프로젝트는 꽤나 다양하다. 이걸 1년치를 기억해서 한꺼번에 적기는 어렵기 때문에 내 영문 이력서를 참고하는게 도움이 될 것 같다.

프로젝트 명, 기간, client, 내가 담당한 부분, 기술 스택과 같은 부분을 상세하게 적었으니 참고하면 좋을 것이다.
http://indeed.com/me/KimJongFeel

링크만 달랑 적으면 성의 없어 보이니 Client 이름, 프로젝트 이름만 나열해 본다.

  • ETRI, SmartFactory AR
  • APROS, IoT Monitoring AR
  • KoreaTech, Job training simulation VR
  • SMIC, SmartFactoryAR
  • Virnect, NetworkLibrary
  • NRICH, 황룡사 중문 복원 AR
  • KEPCO, 연구과제 2차년도 AR
  • KEPCO, 연구과제 3차년도 AR
  • Doosan ICT, IoT 연구과제 AR


2017년에 비해 더 다양한 디바이스와 다양한 플랫폼에 대한 경험을 한 것 같다.
ARCore, ARKit을 활용해서 개발한 점도 그렇고, vuforia 역시 간단한 것 말고 복잡한 것 까지 추가로 구현한 점들 역시 좋은 경험 중에 하나였던 것 같다. => 하나의 image target을 가지고 상황에 따라 다른 game object를 증강시키는 방법 들
그 외에 현재 AR 기술의 한계점과 더 R&D 해야 할 부분들도 알게 되었다. 제일 중요한건 회사에서 R&D 연구소와, AR 개발팀이 별도로 분리가 되고 난 AR 개발팀에서 제품 개발에 대한 더 중요한 일들을 하고 맡게 되었다는 점이다. 업무 분담은 잘 되어 있는 편이고, 팀장과 대화를 많이 해서 내가 할 수 있는 일과 더 많이 도와 줄 수 있는 일을 찾아서 함께 진행하고 있다.

버넥트 블로그 - AR 개발팀 소개
https://m.blog.naver.com/virnect/221345263436

소프트웨어 공학을 접목 시키기 위한 노력


이런 말 하면 이상하게 생각할지도 모르지만 난 개발 프로세스도 없고, 개발 문화가 없는 스타트업을 선호하는 편이다. 왜냐하면 내가 그런 걸 알고 있기 때문에 그런 게 없는 회사가 개발팀에 가서도 얼마든지 좋은 사람들과 함께 만들어 나갈 수 있기 때문이다. 역으로 이미 좋은 개발 문화와 프로세스가 있는 회사라면 배우는데는 좋은데 내가 뭔가 이끌어나간다는 역량을 키우는 데는 부족할 수 있기 때문에 현재 내 포지션이 어딘지 잘 판단하고 회사를 잘 선택해야 한다. 제일 중요한건 좋은 개발문화와 프로세스가 없어도 같이 일 하는 사람들이 쓸데없는 고집이 있지 않고 열린 마음을 가진 사람들이어야 하고 나 역시도 그들과 함께 일하기 위해서 꼰대짓 하지 말고 좋은 개발 문화가 뭔지 뭘 하면 좋을지에 대한 걸 잘 얘기하고 그들에게 모범을 보여주는 게 중요하다고 생각한다.

그런 차원에서 1인 팀에서 6인팀으로 늘어나는 과정에서 내가 전파하거나 받아들인 문화는 아래와 같다.

  • 유닛 테스트
  • Azure DevOps 사용 (아직까지는 repository만)
  • 사내 스터디 활성화
  • 프로젝트 리뷰
  • CI/CD 도입
  • 기술 블로그 장려

등이다.

사실 junior level에서는 이런거 신경쓰는거 보다 당장 내가 맡아야 하는 프로젝트 일을 끝내는 데에 더 신경쓰고 있으므로 상대적으로 senior level인 내가 이끌어야 할 내용들이다. 여기서 사내 스터디 활성화는 내가 주도하는 건 아니고 내가 있는 개발팀의 팀장이 주최해서 참여하고 있는 것이다.

커뮤니티 활동


인천 GDG 개발자 커뮤니티


2018년 봄 쯤에 알게 되었는데 처음부터 이 커뮤니티에 들어가려고 했던 건 아니었고 여기 멤버 중 한 분인 승빈님이 git study를 열어서 참여하게 되었고 그러면서 자연스럽게 이 커뮤티니를 알게 되었다. 사실 git study 내용 자체는 알고 있던 거라 review 차원에서 듣게 된 것이고 여기서 내 개발활동의 영역을 넓혀 보고자 한 거였는데 git study는 study로 끝났고 인천 GDG 커뮤니티 활동을 조금씩 하게 된 건 좋은 것 같았다.

그러고 나서 보니 깨달은 바가 있었는데, 존 손메즈의 소프트 스킬이라는 책이 있는데 거기서 지역 개발자 커뮤니티 활동을 해보라는 얘기가 떠올랐다. 사실 이 책은 썩 좋은 책은 아닌데 쓸데없는 부동산 얘기와 피트니스 얘기가 있어서 그렇지만 다른 내용들은 꽤 볼만하다. 여기서 지역 커뮤니티 활동이 미국에서만 가능한 얘기인 줄 알았는데 내가 살고 있는 인천에도 이렇게 지역 개발자 커뮤니티가 있고 활동할 수 있게 된 건 매우 잘한 일이라고 생각한다.

페이스북
https://www.facebook.com/gdgincheon/

여기 말고 슬랙 채널에 가입하는게 더 확실한 방법이다.
http://slack.gdg.kr/

하코사 커뮤니티 하반기 발표


http://cafe.naver.com/hacosa/240727

이 까페는 웹 개발자 까페 중 가장 활성화된 까페를 찾다가 알게 되었고 가입 후 멘토링을 해주는 글을 올리면서 활동하기 시작했다. 실제로 여기서 멘티 분을 두분을 만나 멘토링을 해 줬고, 기타 고민 상담 글에 대한 댓글을 좀 과격하게 달아 주면서 활동하고 있었다.

그러다가 하반기 세미나 발표 때 발표자를 모집한다고 해서 내가 그 동안 웹 프론트엔드 기술 동향에 대해 생각한 걸 정리하면서 내 멘토링 활동 소개, 그리고 개발 잘 하는 방법 등을 발표하는 자리가 됐으면 해서 신청 했고 운 좋게 선정되서 발표도 하게 되었다.

난 주로 회사 개발 일 위주로 일을 해 왔고 커뮤니티 활동은 잘 안했었는데 이번 계기를 통해 오프라인으로도 커뮤니티 활동을 하게 된 계기가 됐고 여기 운영진 분들에게 매우 고맙다는 말을 전하고 싶다.

발표 자료는 잘 모르는 사람이 보다 보면 약팔이로 느낄 수 있으나 끝까지 보면 결코 약팔이 발표자료가 아님을 알 수 있으니, 대충 보고 욕하지 말았으면 한다.

스터디 그룹


스터디 모임에 대해 짧게 얘기해 보면 스터디 그룹은 조금 비추하는 편이다. 왜 그런가 하면 열심히 하는 사람도 드물고, 핑계대면서 빠지는 사람도 많은 데다가 그런 사람들과 함께 하면 나까지 게을러지기 때문이다. 사실 아는 사람들 끼리 해야 스터디 모임이 활성화가 되는데 그렇게 하면 또 친목 모임으로 변질되서 새로 들어오는 사람들이 적응을 못하는 현상도 생긴다. 그럼에도 불구하고 계속 시도하려는 이유는 사람들과 만나 얘기를 하고 새로운 생각들과 개발에 대한 관점을 얘기해 보고 싶었기 때문이다. 솔직히 기술 실력 높이는 건 스터디 그룹에서는 할 수 없는 일인 것 같다.

git - 기초 스터디


git 스터디는 위에 잠깐 얘기한 대로 승빈님의 스터디 그룹에 참여하는 것 부터 시작해서 진행했다. 물론 이 모임도 잘 참여하는 사람 아닌 사람 좀 갈리긴 했지만, 멤버 절반 이상이 인천 GDG 멤버였기 때문에 끝까지 잘 진행되기는 했다. 여기서 내가 배운 건 여렴풋이 알고 있었던 git flow에 대한 간단한 실습을 해봤다는 것이고, 역시 혼자 하는 거 보다 같이 하는게 좋다는 걸 알게 된 스터디였다.

이 스터디 모임 내용은 아래 링크에서 확인할 수 있다.
https://github.com/jongfeel/git2018

알고리즘 스터디 참여 - 백준 알고리즘 문제 풀기


혼자 프로젝트 오일러 문제를 풀다가 질릴 때 쯤 온라인으로 알고리즘 문제 풀고 코드 공유하는 식의 스터디 모임이 있길래 참여했는데 2주도 안되서 폭파 됐다. 폭파된 문제는 뻔한 거였는데 사람들의 참여율이 1주 만에 엄청 낮았다는 거였고, 2주만에 1/3, 3주차에 나를 제외한 한명만 참여하고 있었던 점이다. 쉬운거 부터 차례대로 풀어서 코드 공유하는 건데, 그것 마저도 아무 얘기 없이 안하는 사람들이 있었다는건, 스터디 모임은 유지되기가 어렵다는 걸 얘기해 주며 온라인 모임은 더더욱 유지되기 어렵다는 걸 반증하는 것 같다.

이 스터디 모임 관련된 내용은 아래 링크에서 더 확인할 수 있다.
https://github.com/jongfeel/BaekjoonOnlineJudge

node.js - ecma2015 문법 정리


하반기에 다시 승빈님이 주최한 스터디 모임이어서 주저 없이 신청했다. 스터디 모임은 참여하기 쉬운 반면에 주최하는 쪽은 준비도 많이 해야 하고 신경써야 할 것도 많기 때문에 참여하는 쪽으로 하게 된 거고, 승빈님이 발표자료 준비를 잘 해오기 때문에 편한 것도 있었다. 내용은 ecma2015 문법 정리 + express를 통한 간단한 rest api 및 DB 연결 까지였다. 새로운 멤버들도 있었고, 기존 인천 GDG 운영자 분들도 있어서 잘 진행된 스터디였고 중간에 나오다 안나온 사람 둘 빼고는 잘 진행된 것 같았다. ecmascript2015야 하코사 발표 할 때도 엄청 많이 봤었고 그 전에 실무에서도 썼었기 때문에 역시 리뷰하는 마음으로 참여 했는데 진행하다 보니 역시 사람들의 생각은 조금씩 달랐고 그 대화에 참여하는 것 만으로도 즐거웠던 스터디 모임이었다.

역시 아래 링크에서 내용 확인이 가능하다.
발표 자료는 승빈님 링크에서 확인 가능하고 내 git repository는 소스 코드만 있다.
https://www.slideshare.net/sungbeenjang/es6-for-nodejs-study
https://github.com/jongfeel/ES6_Node_Study

알고리즘 훈련 - 오일러 프로젝트


이건 몇 년 전에 봐온 영국의 어떤 프로그래머 분에게 영감을 얻어 나도 수학 문제를 풀고 알고리즘 해결 방법에 대해 생각해 보자는 취지해서 시작한 것이다. 사실 시작할 생각은 훨씬 전부터 했지만 내가 멘토링을 진행하는 분 중에 알고리즘 문제를 푸는 연습을 하시는 분이 있어서 내가 모범이 되고자 시작한 계기가 제일 크다.
알고리즘 문제 푸는 방법은 다른 인터넷 글에 많이 나와 있으니 그대로 하면 재미 없을 것 같아서 내가 생각했던 방법과 잘못 생각하고 있었던 것, 나만의 생각의 흐름 정리, 마지막으로 코드 기교 부리기 정도로 해서 진행했다. 현재 15번 까지인가 풀고 잠깐 쉬는 중인데 올해도 조금씩 진행할 예정이다.

아래 링크를 참고하면 알고리즘 문제 진행한 내용에 대해 확인할 수 있다.
https://github.com/jongfeel/ProjectEuler

송도 알고리즘 스터디 - 프로그래머스 문제 풀기


송도 GDG에서 알게된 백지훈님이 주최하는 모임에 참여하게 되서 진행한 온라인 스터디 모임이다. 백준 알고리즘 온라인 모임은 이미 죽어 있는 상태에서 다시 온라인 모임을 한다고 해서 참여하게 됐는데 여기 지훈님이 C++에 대해서 아주 잘 알고 있는 분인데다가 부지런한 분이어서 나도 같이 부지런히 알고리즘 문제 푸는 모임을 진행하고 있다. 문제는 프로그래머스라는 사이트에서 두 문제를 선택해 문제를 풀고 순서가 되면 문제 푸는 방법을 설명하는 식으로 진행하는 것이다. 이 모임 역시 안하는 사람이 절반이 넘기 때문에 그 사람들은 걸러 내고 지훈님과 나는 100% 참여율이고 나머지 몇 몇 분들이 조금씩 문제를 풀어와 같이 리뷰하는 식으로 하고 있다.

여기서 내가 중요하게 생각하는 건 알고리즘 문제 푸는 방법을 뛰어 넘어서 내가 선택한 언어가 어떻게 전략적으로 코드가 나오는지, 여러 다른 언어들로 풀어 가면서 나의 생각 정리하기 정도를 더 추가하고 있다. 알고리즘 문제 푸는 거 정리하는 거 쯤은 다른 블로그 쓰는 사람들도 하는 거라 나는 좀 더 차별성을 두고 진행하고 있다.

여태까지 진행 내용에 대한 공유 문서,
https://docs.google.com/spreadsheets/d/1UOVxD362DiHKsXeG-_bhAIHg_RCA9LCJ3gaYqLuPqEg/edit#gid=0

내가 푼 문제는 여기에 정리하고 있다.
https://github.com/jongfeel/SongDoAlgorithmStudy

멘토링


아무래도 2018년을 한 문장으로 정리해 보라고 한다면 "멘토링 활동" 이라고 하고 싶다.

https://jongfeel.github.io/Software/

소프트웨어라는 제대로된 개념을 전파하기 위한 나름 나만의 활동인데, 현재까지 내 인생에서 제일 잘하고 있는 걸 꼽으라면 이 활동을 얘기하고 싶을 정도로 매우 중요한 활동이다. 학생, 취업준비생, 현업 개발자 등 다양한 분들과 함께 대화하고 소통하면서 그 분들에게 필요한 역량과 생각이 무엇인지 그리고 제대로 하기 위해서 뭘 해야 하는지를 알려주는 역할에 충실히 하고 있다. 나 역시 항상 가르쳐 주기만 하고 알려주기만 한다고 생각할 수 있지만 어린 분들이지만 남다른 생각을 가진 것과 대화하면서 더 배우기도 하는 점도 있는 등 좋은 면이 훨씬 많다.

기타


그 밖에 소소하게 진행한 것들 중에 아래와 같은 것 들이 있다.

정보처리기사 자격증 취득


여태까지 딸 생각이 없었다가 따게 된 계기 부터 해서 정리된 건 내 블로그 글을 확인하는게 좋을 것이다.
https://developerfeel.blogspot.com/2018/05/blog-post.html

한국사 1급 실패


정보처리기사는 내 전공과 관련된 거다 보니 아내와 함께 할만한걸 찾다가 한국사 시험을 보기로 했다. 사실 한국사 1회 시험을 본 적도 있고 떨어진 기억도 있기에 다시 해볼까 해서 해봤는데 아내와 다 둘다 실패. 점수도 50점 대로 합격과는 거리가 먼 점수였는데 기출문제 외우는 수준으로 한국사 1급은 딸 수 없다는게 내 생각이다. 한국사에 대한 매우 깊은 이해가 없이는 문제를 풀기가 매우 어렵기 떄문에 준비를 많이 해야 하는 시험이다.

베이스 기타 연주


전에 교회를 다닌 적이 있고 베이스 연주를 하다 보니 가끔 베이스 연주를 하곤 하는데, 합주는 안되니까 RockSmith 게임 동영상을 YouTube에서 재생하고 거기에 맞춰서 연주하는 수준으로 점심시간에 가끔 즐긴다.


요건 Fray의 How to Save a Life, Bass 연주하기도 쉬운데다 노래가 좋다.

아래 링크는 내가 직접 연주한 UpTown Funk intro 연주 부분



딸 다은이의 성장


갓난 아이였던 다은이가 이제 많이 성장해서 말도 하고 뛰어 다닌다. 집에 있을 때는 나에게 최고의 행복을 주는 아이.

오랜 기간 소통하지 않았던 친구들과의 소통


사실 만날 일이 별로 없기도 하지만 인천으로 이사도 왔고 다은이도 좀 커서 친구들도 다시 만나봐야 겠다는 생각이 들 쯤에 친구 한놈이 결혼한다고 해서 그 일을 계기로 다시 잘 지내보려 한다. 올해 부터는 여행 계획을 세워서 여행을 잘 다녀보기로 했다.

영화 리뷰


영화 많이 보기가 내 주요 취미임에도 불구하고 뭔가 리뷰 같은걸 적어 본게 별로 없다. 예전에 블로그에 적은건 CGV에서 썼던 링크인데 그마저도 다 날아가고 해서 다시 제대로 써볼 겸 해서 쓰고 있다. 작년 5월 부터 부지런히 쓰고 있고 계속해서 쓰고 있으니 칭찬할 만 하다.
영화 리뷰 글은 내 또 다른 블로그에서 볼 수 있다.
https://feelcommonlife.blogspot.com/