• 프로그래밍을 하기 위한 방법
• 상철이의 말말말
  • 프리랜서 현업자의 말
  • 전 구글 개발자의 말
  • 제품의 흐름이란
  • 삼성전자 3년다니고 퇴직하신 개발자님의 말
  • 컨설턴트님이 내게 해주신 말씀(솔직히 여기에 쓰기 쪽팔리긴 하지만 그래도 혹시나 이 글을 읽고 누군가 많은 걸 느끼실 수도 있으니 써야겠다ㅎㅎ)

프로그래밍을 하기 위한 방법

\<나의 생각들\>

자작 프로그램. 자신의 업무를 보조하기 위해서 만들어 쓰는 프로그램. 업무 외로 자신의 삶을 위해 프로그래밍한 것?

• 태도
  • 코딩에 물리적인 시간을 투자한다.
  • 남보다 먼저 시작, 도전(최신 기술)해야 된다.
  • 항상 공부하고 배우려는 마음가짐이어야 한다.
  • 왜? 라는 의문을 갖자.
  • 기본에 충실하자.
  • 비유를 잘 쓰자.
  • 글쓰기를 연습하자.
  • 초등학생을 이해시킬 정도가 되자.
  • 실력자의 바지를 붙잡고 늘어지자.
  • 표준을 지키자
  • Convention을 따르자.
  • 내 자신을 노출하자.(github, 티스토리)
  • 절박해야 된다.
  • 외국어로 된 자료라도 꼼꼼히 읽어보자.
  • 각 기술의 공식 문서를 본다.
  • MDN을 자주 본다.
  • 기술 뉴스레터를 본다.
  • 중간 중간에 피드백을 받자.
  • 튜토리얼이나 책 보다는 작은 Toy project.
  • 작은 봉우리를 쌓아서 크게 키워 나가자.
  • 영어 신문을 읽자.(API 문서 읽기를 위해)
• 영어
  • 전화 영어 1년
  • 아리랑 TV를 하루 1시간씩
• 공부하는 방법
  • 생각
    1. 이게 무엇인가?
    2. 이걸 간단한 정보 처리 과정(그림, 도식, 다이어그램 등)으로 나타내면 어떻게 되는가?
    3. 간단한 문장으로 설명한다.
    4. 그림을 그려본다.
    5. 왜 그렇게 되는가?
    6. 이걸 우리가 원하는 결과물(프로그램)으로 만들려면 어떻게 해야 하는가?
    7. 예를 들어, AI 음악 작곡 프로그램이 있을 때 "음악이란 무엇인가?"부터 찾자.
  • 실습
    1. 일단 아무 것도 하지 말고 가만히 있어보자.
    2. 하고싶은 게 생긴다. 코딩이든, 게임이든
    3. 내가 배워야 하는 기술로 만들어진 가벼운 게임을 분석해 본다.
    4. 구글 영문 검색을 해서 오픈소스로 공개된 작은 게임을 찾아낸다.(테트리스, 애니팡, 포커, 블랙잭, 마리오, word count, ToDoApp 등등)
    5. 코드에 주석을 단다.
    6. 백지에 다시 쳐본다.
    7. 또 다시 쳐본다.
    8. 이해 갈 때 까지 쳐본다.
    9. 포팅을 한다.(다른 언어로 옮겨본다.)
    10. 재조립을 해서 조금 다른 게임으로 만들어 본다.(게임의 일부를 바꿔본다, 게임의 내용을 바꿔본다)
    11. 내가 이 기술(언어)에서 배워야 하는 부분을 게임으로 구현해 본다.
    12. 이것 모두 github에 올리자.
  • 이론
    1. 레퍼런스, 컨벤션 먼저 읽자.
    2. 이론과 실습을 왔다갔다하자.
    3. github에 올리자.
    4. 티스토리에 올리자.
• 공부할 순서(현재부터)
  1. Servlet/JSP
  2. filter, listener, Servlet 배포 방법, web.xml의 이해 - http://egloos.zum.com/kwon37xi/v/2793511 -
  3. JSTL과 EL 이해
  4. JSP 1.2와 2.0의 차이점 이해
  5. Custom Tag handler 작성 가능
  6. Database
  7. ERD 작성 가능
  8. CRUD
  9. Inner join, outer join
  10. index에 대한 이해
  11. explain, view
  12. fail over, master-slave, replication 개념을 알기
  13. 정규화/역정규화를 통한 기본적 성능 향상 방법의 이해
  14. 적절한 인덱싱과 인라인 쿼리의 사용을 통한 기본 SQL Tunning 가능(plan 사용)
  15. Hibernate와 iBatis등의 OR-Mapping 프레임워크의 등장 배경과 사용 이유에 대한 이해
  16. Spring(SI에 입사하기 위한 방편)
  17. 아주 작은 것이라도 본인만의 프레임워크를 만드는 것이 중요
  18. DI
  19. AOP 이해와 사용
  20. EJB 컨테이너가 bean을 관리함으로써 얻는 이점
  21. Struts 구조 파악
  22. Frontend
  23. HTML
  24. CSS
  25. AJax
  26. DOM
  27. JavaScript
  28. JSON을 이용한 Ajax 프로그래밍
  29. XHTML과 HTML의 차이점과 등장배경, 코딩
  30. DOM API를 이용해 동적화면 표현
  31. Data Structure
  32. You have to make a habit. - 의사코드를 보고 절차형, 함수형, 객체 지향 언어로 구현해보기
  33. 알고리즘 공부에서 중요한 것 - 알고리즘을 스스로 생각해낼 수 있는 능력 - 다른 알고리즘과 효율을 비교할 수 있는 능력 - 알고리즘을 컴퓨터와 다른 사람이 이해할 수 있는 언어로 표현할 수 있는 능력 - 정상 작동 여부를 검증해내는 능력 - 실세계의 문제를 직접 다뤄보자(실전의 알고리즘들), ACM의 ICPC의 문제들. - 같은 문제를 풀고, 또 풀고, 또 다시 처음부터 풀어보기 3.
  34. 스택
  35. 큐
  36. 트리
  37. 이진검색트리
  38. 해쉬(체인, 오픈어드레스)
  39. 퀵
  40. 머지
  41. 기수
  42. 링크드리스트
  43. Algorithm
  44. 코딩테스트를 볼 정도
  45. 책을 읽자.
  46. Character Incoding
  47. Design Pattern
• 디자인패턴 학습에서의 문제 잡지에 연재되거나 서적으로 출간된 혹은 세미나에서 진행되었던 디자인패턴 '강의'를 몇 가지 접했습니다. 훌륭한 강의도 많았지만 그렇지 못한 것도 있었습니다. 몇 가지 문제점을 지적하겠습니다. -
• ◆패턴을 지나치게 실체화, 정형화해 설명한다. ◆컨텍스트와 문제 상황에 대한 설명이 없거나 부족하다. 결과적으로 문제를 해결하기 위해 패턴이 도입된 것이 아니라 패턴을 써먹기 위해 패턴이 도입된 느낌을 준다. ◆문제의식을 먼저 형성하게 하지 않고 답을 먼저 보여준 뒤 그걸 어디에 써먹을지 가르친다. 왜 이걸 쓰는 게 좋은지는 일언반구 언급이 없다. 독자는 '어린아이가 망치를 들고 있는 오류'에 빠질 것이다. ◆패턴이 어떻게 생성되었는지 그 과정을 보여주지 못한다. 즉, 스스로 패턴을 만들어내는 데 도움이 전혀 되지 않는다. ◆해당 패턴이 현실적으로 가장 자주 쓰이는 맥락을 보여주지 못한다. 대부분 장난감 문제(Toy Problem)에서 끝난다.
  1. Design Patterns Explained
  2. Design Patterns Java Workbook 이 두 책을 읽자.
  3. 사고방식을 알기
  4. 개인 프로젝트를 할 때 디자인 패턴을 적용/신경쓰기.
  5. 운영체제(리눅스 중심)
  6. 메모리 디스크 프로세스 등에 대한 내용의 큰그림
  7. 리눅스
  8. Docker
  9. AWS or GCP or Azure
  10. 네트워크
  11. http
  12. https
  13. ip
  14. TCP
  15. UDP
  16. ssh
  17. apache Or nginx (name based virtual host랑 ip based virtual host의 차이)
  18. 보안
  19. XSS
  20. CSRF
  21. SQL injection
  22. Open redirect
  23. command injection
  24. Directory Traversal
  25. Appscan이나 Burp와 같은 시큐리티 테스트 툴 이용.
  26. 서버 접근권한 제한, 로그인 비밀번호 암호화 방식, 기초 보안등…
  27. 이외
  28. Nosql, 스파크, angualr.js
• 리팩토링 수련법 제가 고안, 사용한 몇 가지 리팩토링 수련법을 알려드립니다. -
• ①일취집중후각법: 앞에 소개한 본지 2001년 11월호에서 인용된 글 참조 ②주석 최소화: 주석을 최소화하되 코드의 가독성이 떨어지지 않도록(혹은 오히려 올라가도록) 노력합니다. 이렇게 하면 자동으로 리팩토링이 이뤄지는 경우가 많습니다. ③OAOO 따르기: OAOO 법칙을 가능하면 최대한, 엄격하게 따르려고 합니다. 역시 자동으로 좋은 리팩토링이 이뤄집니다. 여기서 디자인패턴이 창발하기도 합니다. GoF 책을 한번도 보지 못한 사람이 디자인패턴을 자유자재로 부리는 경우를 보게 됩니다. ④디미터 법칙(Law of Demeter) 따르기: 디미터 법칙을 가능하면 지키려고 합니다. 어떤 리팩토링이 저절로 이뤄지거나 혹은 필요 없어지는가요? ⑤짝(Pair) 리팩토링: 함께 리팩토링합니다. 혼자 하는 것보다 더 빨리, 더 많은 걸 배우게 됩니다. 특히, 각자 작성했던 코드를 함께 리팩토링하고, 제3자의 코드를 함께 리팩토링해 봅니다. 사람이 많다면 다른 짝이 리팩토링한 것과 서로 비교하고 토론합니다. ⑥'무엇'과 '어떻게'를 분리: 어떻게에서 무엇을 분리해 내도록 합니다. 어떤 리팩토링이 창발합니까? -
• 질문하는 방법
  1. 본인이 공부한 과정이나 레퍼런스, 웹사이트, 참고서적을 말하자.
  2. 자신이 이해하고 있는 바를 최대한 자세히 적자.
  3. 검색을 했다면 어떤 키워드로 검색했는지 말하자.
• 이력서
  1. gmail을 쓰자.
  2. PDF를 쓰자.
• 디버깅하는 법

Caused by: java.lang.NullPointerException at com.mycompany.service.impl.PortalManagerImpl.deleteMenuItem(PortalManagerImpl.java:603) at com.mycompany.service.impl.PortalManagerImpl.deletePortal(PortalManagerImpl.java:358)

'com.mycompany.service.impl.PortalManagerImpl' 클래스의 'deletePortal' 메소드 358라인에서 같은 클래스의 'deleteMenuItem'메소드를 호출했는데 해당 메소드 603번 째 줄에서 널포인터 예외가 발생했다'

널 포인터에서 예외가 발생했다면 널 포인트의 의미를 정확하게 파악해서 가능성을 좁히자.

남은 일은 '카드'를 'Card' 클래스로, '카드를 섞는다'를 'shuffle()'이라는 메서드로 모델링하는 일입니다.

좋은 모델은 주석을 보지 않고도 모델이 나타내는 실세계의 개념에 비추어 자연스럽게 읽히는 형태입니다. 예컨대 'CardDeck'이란 클래스에 'cards: List\<Card\>'라는 속성이 있고 'shuffle()'이라는 메서드가 있다면 특별히 주석을 달지 않아도, 어떻게 하면 카드덱의 카드를 섞을 수 있는지 직관적으로 알 수 있을 것입니다.

반면 'CardGame.shuffle()' 같은 메서드를 만들었다면 카드를 섞는행위는 카드 게임의 동작이라기 보다는 카드덱이나 플레이어의 동작으로 생각하는 것이 더 자연스럽다는 점을 감안하면 좋지 못한 모델링이 될 수 있습니다.

본문에 빠뜨렸지만, 객체지향 모델링을 하는 한 가지 쉬운 방법을 소개하면, 우선 도메인의 유즈 케이스 - 예를들어, 카드 게임에서 새 카드를 받는 시나리오를 '플레이어가 카드를 뽑는다'와 같이 평이한 문장으로 적어서 나열합니다.

그 다음에 문장들에서 반복적으로 등장하는 명사를 추려내서 이를 빈 인터페이스로 코딩합니다:

interface Card {}interface Player {}//…

한편 명사들 중에는 '카드의 숫자'와 같은 다른 개념에 종속적인 내용이 있을 것입니다. 이런 부분은 앞서 작성한 인터페이스에 속성으로 추가합니다:

interface Card {intgetNumber();}

객체 지향 모델링을 하는 방법

마지막으로 문장에서 동사를 추려내서 적절한 인터페이스의 메서드로 작성합니다. 예컨대 '카드덱에서 새 카드를 뽑는다'라면 다음과 같이 '카드덱'을 나타내는 인터페이스에 메서드를 추가할 수 있습니다:

interface CardDeck { Card draw();}

여기까지 완료되면 남은 것은 해당 인터페이스들이 서로 연계되어 동작할 수 있도록 모양을 만들어 주는 것입니다. 예를들어 다섯장의 카드를 뽑아서 플레이어에게 주어야 한다면 다음과 같이 표현할 수 있습니다:

for (int i = 0; i \< 5; i++) { for (player : players) { Card card = deck.draw(); player.receiveCard(card); } }

중요한 것은, 여기까지 오면서 실제 인터페이스의 구현에 대해서는 신경을 쓰지 않았다는 것입니다. 좋은 객체지향 설계에서는 구현이 없어도 각 유형의 공용 API만 보아도 어떻게 서로 연관지어서 구동되는 지 이해할 수 있어야 합니다.

구현을 채워 넣는 것은 이런식으로 추상적인 개념 수준에서 전체적으로 돌아가는 모양의 윤곽이 잡혔을 때 단위 테스트를 작성해가면서 채워 넣어도 늦지 않습니다.

첸 형이 해준 말

• 웹 개발은 하지 마라.
• C++ or Java 는 무조건 필수 깊게 파야된다. 파이썬도 필수(딥러닝할 때 해야된다), Node.js도 필수다.
• 어차피 나중에 가면 다 하게 되는 걸 알 수 있다.
• 영어 공부 좀 해라.

참조

• http://ahnheejong.name/articles/becoming-better-programmer/
• https://kr.rellat.com/
• https://okky.kr/article/372485
• https://github.com/devJang/developer-roadmap

\<이민석 교수님 slide share에 있는 말\>

• 소프트웨어를 만들 때 쓰는 시간
  • 진짜 프로그램 짜는 시간은 매우 적다. 기술적 설계와 수학적 설계, 인간 관계 등등이 대부분이므로 기본이 가장 중요하다.
• 코딩의 자세
  • 매뉴얼을 읽자
    • Compiler Manual
    • Reference
    • Coding Convention
  • Source Reading은 종이에 출력해서 읽자
  • Compiler
    • Warning Message Level을 최고로 높인다.
    • 모든 Warning Message를 없앤다
  • Tools와 문서
    • 설계를 도와주는 모델링 도구, 설계 문서, Code Review를 도와주는 도구, 전체 소스를 정적 분석하는 도구
  • 최적화는 뒤로 미루자. 일단 예쁜 코드로 돌게 하는 것이 중요하다. 설계 단계에서 구조적인 최적화를 고민하자.
  • 읽기 어려운 코드는 Reuse도 하지 말자.
  • 있는 디버거를 꼭 사용하자.
    • printf()는 기본적으로 모니터링 수단.(모든 가능성이 없을 때 디버깅 용도로 사용)
  • 디렉터리의 구조, 파일, 변수 이름은 예측이 가능하도록, 다른 사람이 찾기 쉽도록
• 진도 나가고 문제 풀이만 하면 문제 낸 자를 능가하지 못 한다.
• Code는 무조건 Review를 해야하고 Test도 해봐야 한다.
• 훌륭한 개발자란?
  • 언제시작했는지도모르게코딩하고있는나를종종발견한다. ?최근에새로운프로그래밍언어, 도구, 수학개념을배웠다. ?관심있게보고있는오픈소스프로젝트가3개이상이다. ?지난6개월동안, 커뮤니티에서뭔가발표를해본적이있다. ?누군가의멘토이며, 또누군가의멘티이다. ?개인프로젝트를위한소스리파지터리를유지하고있다. ?전에작성한내코드가너무깔끔해서감동한적이있다. ?코딩에쓰는시간이주당몇시간인지정확히알고있다. ?참여하고있는프로젝트의전체구조를바로설명할수있다. ?내가만든소프트웨어의사용자에귀기울이고있다.

필자는 학교숙제를 비롯해 어떤 개발을 하더라도 코딩 시간을 20% 이상 할애하지 않으려고 한다. 가끔 전혀 모르는 언어를 사용해서 개발하거나 생소한 분야의 개발을 해야 할때는 50% 까지도 코딩 시간이 늘어날 수 있지만 기본적으로 대부분의 시간을 분석, 그 다음에 설계에 시간을 들인다. 이 방법이 가장 빠르고 품질 좋은 제품을 만들어 낼 뿐 아니라 1,000명의 개발자가 같이 개발을 해야 하는 경우에는 필수적이기 떄문이다.

더 나은 개발자가 되려면? 책 빌려서 읽기, 테스트 주도 개발을 하자. 테스트 주도 개발이라는 책을 읽자. 저자 켄트 백, Junit, mockito, htmlunit, dbunit, 로그를 잘 남겨야함. 다른 개발자 코드를 보자 spring petclinic, 혼자 공부하지말자, 디버깅을 잘하자.

최소 1, 2년은 꾸준히 학습에 집중 투자해야 한다.

• 애인과의 만남 시간 조정,
• 친구들과의 관계 끊기
• TV 보지 않기, 게임하지 않기
• 프로그래밍 관련 책만 읽기
• 야근하면서 토이 프로젝트하기

이해가 공부를 방해한다. 무조건 실습을 해야 한다. 일단 해보고 말하자.

자신의 시간을 쏟아부어야 한다. 개발 업무에 많은 시간을 투자하고, 여유 시간에 운동과 자기계발에 투자해야한다. 처음 신입 1년 동안은 워라벨을 따지지 말자

convention을 먼저 지키자.

절박함, 물리적인 시간, 노출(블로그, github, 세미나), 남보다 먼저 시작하기 그러나 기본(원리 위주, 항상 왜?라는 의문을 갖자)을 확실히 하기 취업시장에서 원하는 능력이 뭔지

놀면서 돈벌자. 웅얼거리지말고 자기 방어 하지말고 비유 잘쓰고 초등학생에게 가르쳐줄 수 있을 정도. 몸에 배여있어야 한다.

영어, 외국어로 된 자료들, 끝까지 포기하지 않고 문제를 해결하려고 하는 ‘프로’근성

최대한 단 기간에 해야된다. 목표를 가지고

무조건 실력자의 바지를 붙잡고 늘어져야 합니다. 모방해서 자기 것으로 만드세요.

자신의 코드를 보여주는 것에 용기를 가지세요.

똑같이 코딩해본다. 코딩하면서 이해한다. 모두 지우고 다시 코딩한다. 몇 번을 다시 계속 하면 원 코드를 안 봐도 동일한 동작을 한다. 거기서 궁금한 거 1~2개를 알아본다. 그러면서 살을 붙인다. 처음에는 오래 걸리지만, 점점 빨라진다.

상철이의 말말말

1. 잘하는 사람이 되어야 괴롭힘을 당하지 않는다.
2. 개발자는 좁은 사회다. 서로 다 안다.
3. 잘하는 사람들과 많이 알아야 한다. 잘하는 사람들이 가르쳐 주는 정보가 다르다.
4. 상철이는 주변 사람들이 잘하는 사람들이었다.
5. 해커톤을 함으로써 잘하는 사람들을 만날 수 있다. 대외활동. sopt, nexters, 연합 IT 동아리. 연합 동아리 한 번 들어가면 인맥의 질이 달라진다.
6. 내 이미지를 어떻게 변화시켜나갈 것인가.
7. IT업계는 추천서가 있어서 인맥이 중요
8. 블로그를 꼭 해라. 댓글로 인연이 되는 경우가 있다.
9. 블로그 하나 잘 만들면 내 가치를 더 뿌릴 수 있다.
10. 스트레터지 패턴이면 분석적으로 해놓으면 좋다.
11. 컨퍼런스나 세미나 있을 때 가보자. 세미나도 해봐라.
12. 알린 만큼 잘 해야된다. 유명한 만큼 잘해야됨. 입 코딩 하지마라.
13. 좋은 사람이면서 못 하는 사람이면 더 무시받는다.
14. 인프라는 큰 개념. REST하게 만드는 게 백엔드 개발. 대용량 트래픽을 처리하기 위한 것들… 그런 게 백엔드 개발.
15. 다른 언어 공부할 생각하지 말고 자바라도 잘해라. 백엔드로 spring 하나만 잘하는 것도 어렵다.
16. 프론트가 하고 싶은 건지, 백엔드를 하고 싶은 건지, 앱을 하고 싶은 건지…
17. 삼성전자에 취업하면 그냥 좋은 사람으로 남을 수 있다. 회사는 회사고. 커리어 패스를 생각해라.
18. 이것저것 블록체인, 빅데이터 이런 거 하지말고 그냥 자바나 제대로 해라.
19. 어중간 하게 알지말고 알고리즘을 하면 알고리즘만 파거나 언어를 팔거면 언어만 파라.
20. 자바 코드를 까보는 게 좋다. JVM을 까보든지… 인터페이스를 까보고.
21. 프로젝트를 끝내는 게 가장 좋다. 이걸 할 수 있을까. 처음하기 때문에 얼마나 걸릴지 모른다. 목표를 너무 크게 잡지 마라.
22. 2가지가 제일 좋다. 하나는 채팅, 하나는 테트리스. 멀티 스레드, 통신, 동기화, 임계영역등 다룰 수 있다. 웹 화면에서 채팅하고 쪽지날리고 그런 것들.
23. 2학기 프로젝트를 최우선으로 해라. 여유가 되면 서버를 두 개로 가져가봐라. 하나는 인증서버, 하나는 RESTful 서버로. 서버를 나누면 세션 유지가 안 되기 때문에 토큰을 써야하는데 엄청나게 꼬인다.
24. 테트리스와 채팅이 베이직. 로그인같은 것도 넣어봐라.
25. 서버를 MSA로 분리시켜라.
26. 주어진 기능을 잘 짜봐라. TDD로 짜보기. 원래 test 폴더에서 TDD를 짜는 것.
27. 민국이형이 추천해준 거. 에듀싸피를 축소해서 로그인 버리고 게시판 CRUD만들고 로그인 붙이고, 회원권한 나누고, 관리자는 회원 관리 페이지를 만들고.
28. 스프링 시큐리티라는 라이브러리. REST로 바꿔보기.
29. redis같은 건 간단하지만 설정이 어렵다.
30. 토큰은 시간이 되면 찾아보기.
31. jwt라는 토큰?
32. 내 포트폴리오를 쌓고 싶으면 배포를 해보기, GCP나 Azure나 AWS나 그런 걸로 배포를 해보자. AWS를 무조건 써보기
33. 작은 단위에서 붙여나가는 것도 좋지만 설계를 다 만들어놓고 개발해보는 것도 중요하다. url 패스를 만들어보는데 여기에도 restful을 공부하기
34. 유연하게 만들면 좋다.
35. 팀원이 너무 중요하다. 이 프로젝트에 올인을 해봐라.
36. 프로젝트할 때 룰을 잘 정하자. 늦으면 안 된다든지, 흥얼거린다든지…
37. 풀리퀘, 리베이스만 잘 써도 좋다.
38. IoT 절대 하지마라. 블록체인은 계륵같음. 빅데이터도 파이썬할 거 아니면 하지마라. 클라우드를 무조건 해라.
39. 면접 때 어차피 다 물어본다. 개발을 진짜 좋아하는지.
40. 채팅하는 거 상철이 코드.
41. git관리를 잘 해놔라
42. 알고리즘
43. jsp위에 Vue하는 게 말도 안되는 일.
44. Vue는 싱글 페이지 기반. 원래는 HTML하나만 있어야 하는 것. Vue는 createElement같은 걸 해주는 게 Vue.
45. JSTL쓰는 회사는 망한 회사라고 보면 된다.
46. 프론트와 백을 토큰으로 관리.
47. url짜는 게 그런 것.
48. IT순위. 1등은 라인, 2등은 배민(지금 들어가기에 너무 좋다. 개발할 게 많아서), 3등은 네이버, 4등은 네이버 계열사들, 카카오. 삼전은 30위쯤…ㅋㅋㅋ 토스는 신입 안 뽑음. 스타트업 중에는 지그재그(너무 좋은 곳), 하이퍼커넥트는 가기 힘들다, 리디북스도 진짜 좋다, 당근마켓도 좋음, 야놀자, 쿠팡, 티몬 등등 좋다. 게임 업계는 절대 가지 말라. 일이 엄청 많고 게임은 24시간 들어가야되고… 이혼률이 엄청 높다. C++로 만드니까. 회사를 들어가면 Linkedin을 관리해라. 깃도 잘 관리하고. 은행권은 완전 지옥. 그냥 개발 안하겠다는 소리. 은행가면 옛날 코드를 짠다. 공기업은 정치 잘해야되고, 들어가기 힘들다. 왜 개발해? 이런 느낌. 코스콤? 그런 기업 좋다.
49. 랭크드인으로 가보면 라인이 1등을 먹고 있다.

대기업을 가려면 알고리즘, 운영체제, 네트워크만 공부하면 된다. 잘 해야된다.

4000이하 주는 곳 아니면 가지마. cnc, cns, sds. CNS가 좋다. 되게 좋아졌다. 사실 3대 말고는 가지마. 문서 작업을 할 확률이 높다. PS는 허영된 것이라고 생각해라. 이직할 때는 PS를 치지 않는다. 그래서 삼성전자에서 이직할 때 무조건 깎이고 가는 것.

제조업(연봉 높음) -> IT IT IT -> 통신사. 그러면 베스트. 하지만 이렇게 하기 쉽지 않다. 요즘은 네이버 카카오만 왔다갔다하는 게 대세… 개발자가 갑… 그래서 관리로 빠지면 4~50대. 클라우드 벤더로 가는 게 가장 낫지 않나… PM이 전형적인 삼성전자 테크. 하지만 나쁘지 않다. 4~50대까지 개발하는 건 쉽지 않다.

선생테크타는 게 진짜 좋다. 패스트캠퍼스. 강사같은 거 하면 좋다. 이제는 중학생도 개발을 한다. 우리 세대의 영어가 미래 세대의 개발한다.

polling, longpoll, 웹 소켓을 통해서 계속 쏘는 방식, on(), emit()이라는… 중계 서버가 Redis, pub/sub. 굳이 막 쓰지마라. 모르는데 쓰지마라. 토큰은 JWT를 쓰면 된다. 토큰 개념이 어렵다, 쓰는 건 괜찮음 Oath2. 이게 왜 믿을 수 있지? 라는 걸 생각해보면서 공부하면 된다. Restful!! // 백엔드는 TDD를 한 번 해봐라. TDD가 매우 중요하다. view단이 없으면 확인할 게 없다. 그래서 TDD를 해야 된다. Spring boot의 어노테이션들을 까봐라. 스프링을 잘 아는 게 더 중요하다.

프리랜서 현업자의 말

• 책을 많이 읽자.
• 야근은 절대 하지 말자. 빨리 집에 가서 혼자 공부해라.
• 스타트업에서 고생한다고 실력 늘지 않는다
• 사수가 중요한데 정말 웬만하면 좋은 사수는 없다.
• 직장을 선택할 때 워라밸을 신경쓰는 이유는 어차피 집에 와서 혼자 공부해야하기 때문이다. 어.차.피 혼자 공부해야된다

전 구글 개발자의 말

• 코딩을 습관으로 만들기(매일매일코딩)
• 컴퓨터 언어 하나는 확실히 알기
• 다른 사람의 코딩을 읽기
• 사용자를 이해하려고 노력하기
• 다른 엔지니어와 대화
• 혼자 코딩은 하지말자
• 알고리즘은 삼성 상시 테스트에서 Pro정도는 따야된다.

제품의 흐름이란

• 제품을 만들기 위해서 개발 언어가 존재하는 것.
• 제품에는 고객이 있어야 한다.
• 고객을 생각하면서 만들어야 한다.
• 기획, 디자인, 개발(퍼블리싱, 프론트엔드, 백엔드), 테스트, 배포의 순서를 거친다.

삼성전자 3년다니고 퇴직하신 개발자님의 말

• 대기업이라고 다가 아니고 중소기업이라고 다가 아니다.
• 그렇게 좋다고 하는 삼성도 입사하고 2주 지나면 퇴사하고 싶은 생각이 들 것이다.
• 당연한 소리지만 개발자는 개발 실력이 좋아야 한다.
• 자신이 개발을 잘 하는지 알아보려면 다른 사람들이랑 팀프로젝트를 할 때 내 자신이 얼마나 기여를 하는지 보면 된다.
• 개발자가 잘하면 회사에서 잡는다.
• 회사다니면서 개발 일 하기는 쉽지 않다. 주말에 아무리 해도… 쉽지 않다.
• 사수를 잘 만나야된다. 그게 가장 중요하다.
• 대기업을 가면 부품으로 사용될 수 밖에 없다. 또한 대기업을 간 후 애기를 낳게 된다면 정말 막 굴린다. 그래서 신입사원 연수할 때 뽕을 잔뜩 넣어준다.
• 시간을 아껴라. 32세가 되기 전까지는 진짜 진심으로 열심히 해야된다. CS랑 알고리즘, 프로젝트. 3가지를 진짜 열심히 해야된다.
• SI는 아래로 계속 내려가는 조직구조다. 하청의 하청의 하청…
• 개발을 정말 좋아한다면 SI나 제조사같은 기업은 안된다. 진짜 IT기업을 가야된다.
• 돈은 버는 만큼 더 쓰게된다. 그래서 삼성전자 부장급이 되어도 돈을 더 벌고싶어한다. 사회구조가 그렇게 되어있다.

컨설턴트님이 내게 해주신 말씀(솔직히 여기에 쓰기 쪽팔리긴 하지만 그래도 혹시나 이 글을 읽고 누군가 많은 걸 느끼실 수도 있으니 써야겠다ㅎㅎ)

1. (취업관련)서울대 갈 실력도 아닌데 서울대가 좋은지 연세대가 좋은지 계속 고민하고 있는 것 같다.
2. 어딜 가든 성장할 사람은 성장한다.
3. 1년 뒤에 제대로 해볼까 하는 생각을 하는 건 분명히 1년 뒤에도 똑같은 생각을 하게 될 거다.
4. 개발 잘하는 사람은 망설하지 않고 그냥 계속 코딩을 한다. 10시간 정도 코딩하다가 2시간 정도 게임하고…
5. 알고리즘은 원래 대학교 때 했어야 된다. 3시간 정도 매일 꾸준히 투자해라.
6. 심지어 프로젝트도 시간 날 때 재미삼아서 그냥 한다.
7. 가장 중요한 건 실천력. 바로 하면 된다.
8. 내가 쓰고 있는 게 뭔지, 이게 없으면 어떤 일이 일어나는지, 이걸 왜 써야하는지 알아야 한다.