목 차
구성과 관리에 관한 이슈들
0. 작은 것에 연연하지 말라
1. 사소한 경고 메시지라도 무시하지 말라
2. 자동화된 빌드 시스템을 사용하라
3. 버전 컨트롤 시스템을 사용하라
4. 코드 리뷰에 시간을 투자하라
디자인 스타일
5. 하나의 엔티티에는 하나의 역할만을 부여하자
6. 정확성, 간결성, 명확성을 먼저 생각하라
7. 적절한 규모 유지를 위해서는 '언제, 어떻게'를 아는 것이 중요하다
8. 이른 최적화를 피하라
9. 미리 최적화해두어야 할 부분도 있다
10. 전역 데이터와 공유 데이터를 최소화하라
11. 정보를 숨겨라
12. 안전한 공유를 위한 코딩의 시기와 방식을 결정하라
13. 자원은 개체가 가지게끔 하라. RAII와 스마트 포인터를 활용하라
코딩 스타일
14. 런타임 오류보다는 컴파일이나 링크 타임 오류가 낫다
15. const를 사용하라
16. 매크로 사용을 자제하라
17. 마법의 숫자는 쓰지 말라
18. 가능하면 로컬 변수를 선언하여 사용하라
19. 변수는 항상 초기화하여 사용하라
20. 너무 긴 함수와 많은 중첩 구조는 피하라
21. 컴파일 단위 사이의 초기화 의존성을 없애라
22. 정의의 의존성과 순환 의존성을 최소화하라
23. 헤더 파일은 충분히 완성된 형태로 만들어라
24. 내부 #include 가드를 사용하라. 외부 #include 가드를 써서는 안 된다
함수와 연산자
25. 값, (스마트) 포인터, 참조 중 적절한 방식으로 인자를 얻어라
26. 오버로딩된 연산자의 본래 의미를 유지하라
27. 표준적인 형식의 산술 및 할당 연산자를 사용하라
28. ++와 --의 표준적인 형식과 접두 형식을 사용하라
29. 간접적인 타입 변환을 피하기 위해 오버로딩을 활용하라
30. &&, || 그리고 콤마의 오버로딩은 피하라
31. 함수 인자의 처리 순서에 좌우되는 코드는 좋지 않다
클래스 디자인과 상속성
32. 만들고 있는 클래스가 무엇인지 확실히 하라
33. 최소화된 클래스를 사용하라
34. 상속성은 주의해서 사용하라
35. 기반 클래스로 디자인되지 않은 클래스로부터의 상속을 피하라
36. 추상 인터페이스를 활용하라
37. 상속의 정확한 의미를 이해하자. 재사용을 위해 상속하는 것은 아니지만, 재사용은 필요하다
38. 안전한 오버라이딩을 연습하라
39. 가상 함수는 비공용으로, 공용 함수는 비가상으로 설정하라
40. 간접 변환을 피하라
41. 특징 없는 값의 집합(C 스타일의 struct)을 제외하고는 모든 데이터 멤버를 사영으로 유지하라
42. 내부의 것은 너무 노출시키지 말라
43. Pimpl을 적절히 활용하라
44. 비멤버 함수를 활용하라
45. new와 delete는 항상 함께 제공하라
46. 특정한 클래스에 맞는 new를 제공한다면 모든 표준 형식을 제공해야 한다
생성과 파괴 그리고 복사
47. 멤버 변수의 정의와 선언은 같은 순서로 하라
48. 컨스트럭터 내에서 할당 대신 초기화를 사용하라
49. 컨스트럭터와 디스트럭터에서는 가상 함수의 호출을 피하라
50. 기반 클래스 디스트럭터는 공용과 가상 또는 보호와 비가상으로 만들어라
51. 디스트럭터, 재할당 그리고 swap은 절대 실패하지 않는다
52. 일관된 방식으로 복사하고 제거하라
53. 복사의 허용 여부는 명확하게 지정하라
54. 개체의 조각화를 피하라. 기반 클래스 내에서의 복사보다는 Clone을 활용하라
55. 정규형의 할당 방식을 사용하라
56. 필요하다면 실패가 없는 swap을 활용하라
네임스페이스와 모듈
57. 타입과 그의 비멤버 함수는 같은 네임스페이스 내에 넣어라
58. 특별히 함께 작동하게끔 의도된 경우가 아니라면 타입과 함수는 분리된 네임스페이스에 넣어라
59. 헤더 파일 내에 또는 #include 앞에 네임스페이스 using을 써서는 안 된다
60. 서로 다른 모듈에서의 메모리 할당과 해지는 피하라
61. 헤더 파일 내에는 서로 연결된 엔티티를 정의해서는 안 된다
62. 예외가 모듈의 경계를 넘어 전달되는 것을 막아라
63. 모듈의 인터페이스 내에는 충분한 이식성을 갖춘 타입을 사용하라
템플릿과 일반성
64. 정적, 동적인 다형성을 적절히 혼합하라
65. 계획적이고 직접적으로 커스텀화하라
66. 함수 템플릿은 특화해서는 안 된다
67. 계획적이지 않고 일반적이지 않은 코드는 작성하지 말라
오류와 예외의 처리
68. 내부적인 가정과 규칙을 확실하게 명시하라
69. 합리적인 오류 처리 방식을 수립하고, 엄격히 그 방식을 따르라
70. 어디까지가 오류인지 명확히 해두자
71. 오류로부터 안전한 코드를 디자인하고 작성하라
72. 오류 보고에는 예외를 활용하라
73. 예외를 발생시킬 때에는 값으로 하고, 잡아낼 때에는 참조로 하라
74. 목적에 맞게 오류를 보고하고, 제어하고, 변환하라
75. 예외 명세표는 만들 필요가 없다
STL : 컨테이너
76. 표준적으로 vector를 사용하고, 그렇지 않다면 적절한 컨테이너를 선택하라
77. 배열 대신 vector와 string을 사용하라
78. C++ API가 아닌 다른 것들과의 데이터 교환을 위해서는 vector(그리고 string::c_str)를 사용하라
79. 컨테이너에는 값과 스마트 포인터만을 저장하라
80. 요소의 추가에는 push_back을 활용하라
81. 추가 작업에 있어 범위를 지정한 방식을 활용하라
82. 용량의 축소와 요소의 제거에 있어 적절한 방법을 사용하라
STL : 알고리즘
83. 검증된 STL 임플리먼테이션을 사용하라
84. 직접 작성한 루프보다는 알고리즘을 활용하라
85. 적절한 STL 검색 알고리즘을 사용하라
86. 적절한 STL 정렬 알고리즘을 사용하라
87. 술어를 순수한 함수로 만들어라
88. 알고리즘과 비교 인자에는 함수보다 함수 개체를 사용하라
89. 올바른 함수 개체를 만들자
타입 안전
90. 타입의 변환을 피하고, 다형성을 활용하라
91. 표현 방식이 아닌 타입에 의존하라
92. reinterpret_cast 사용을 자제하라
93. 포인터에 대한 static_cast 사용은 피하라
94. const는 캐스팅하지 말자
95. C 스타일의 캐스팅은 사용하지 말라
96. POD가 아닌 데이터를 memcpy 또는 memcmp하지 말라
97. union 사용을 주의하라
98. 가변 인자의 사용을 피하라
99. 올바르지 않은 개체와 안전하지 않은 함수는 사용하지 말라
100. 배열을 다형적으로 다루어서는 안 된다
프로그래밍을 잘하는 법 10가지
1. 꾸준히 한다.
프로그래밍 언어도 언어(?)라서, 하루에 몰아서 하는 것보다 매일 꾸준히 하는 것이 중요하다. 경력이 많은 프로그래머들도 몇달만 코딩을 안해도 감이 많이 떨어지는 것을 느낀다.
특히 프로그래밍을 처음 배우는 사람이라면, 꼭 컴퓨터 앞에 앉지 않더라도 책을 항상 가까이해서 문법 및 표현에 익숙해지도록 하는 것이 중요하다. 자주보는 것이 중요하다.
2. 반복해서 한다.
단지 태권도 교본을 잘 이해했다고 해서 멋진 발차기를 기대할 수 없는 것처럼, 책의 내용을 잘 이해했다고 해서 하루아침에 프로그래밍을 잘할 수 있는 것은 아니다.
이해한 내용을 바탕으로 수많은 반복연습을 통해서만 지식을 진정한 자신의 것으로 만들 수 있다. (같은 예제를 공부하더라도 이리저리 조금씩 변경해서 공부하는 것이 좋다.)
처음 2~3번은 자세히 보고, 그 다음 부터는 하루에 10분간 10페이지를 훑어보는 식으로 반복하자.
몇달 안에 책에 있는 모든 목차와 예제의 위치와 주요내용을 모두 파악할수 있을 것이다.
(적어도 언어책 한권, 데이터베이스책 한권 정도는 이렇게 할 필요가 있다.)
3. 좋은코드를 많이 보고 따라한다.
이미 수많은 선배들이 여러문제들에 대한 코딩을 다 작성해 놓았다. 새로운 방법으로 문제를 풀겠다고 도전하는 것은 별 의미가 없다.
"이럴때는 이렇게 하는 구나..."라는 것을 배우고 유사한 상황에서 활용하면 되는 것이다. 여러분들이 해야할일은 이러한 경험들을 많이 쌓아나가는 일이지,
기존과는 다른 새로운 코딩방식을 만들어 내는 것이 아니다. 좋은 코드는 보기에도 좋다. 잘정리되어 있고, 별로 특별한 것이 없다. 프로그래밍의 각요소들을 잘이해하고,
각 요소들을 적재적소에 바르게 사용하면 되는 것이다. 단지 소스의 라인수를 줄인다고해서 좋은 코딩이 아닌것이다.
로직이 소스코드에 잘 드러날 수 있게 쉽고 평범하게 작성하는 것이 좋은 코드인 것이다. 이창호의 바둑이 평범하듯이...
4. 기본에 충실한다.
빨리 프로그래밍을 배워서 뭔가 해보고 싶은 여러분들의 마음을 이해하지 못하는 것은 아니다.
그러나, 프로그래밍 하루이틀 할 것도 아니고... 처음에 기본을 잘배워놓지 않으면, 그 이후에는 기회가 잘 없다.
실무에서는 매일 개발하기 바쁘고, 새로운 기술 배우기 바쁘고...배울 것이 많다고 생각할지 모르나, 실제로 원리는 모두 같다고 해도 과언이 아니다.
하나를 깊이있게 파고들면 나머지는 다 여러분 손에 있을 것이다.
5. 코드를 작성하기전에 순서도를 그린다.
"프로그래밍 = 코딩"이 아니라 "프로그래밍 = 로직설계 + 코딩"이다. 필자가 생각하는 로직설계와 코딩간의 비율은 8:2정도이다.
포토샵만 잘 한다고 디자이너가 아니라는 것은 여러분들도 잘 알고 있을 것이다. 새로운 기술이나 프로그램을 공부하는 것도 중요하지만,
어떤 과제가 주어졌을때 이를 잘 분석하고 설계하는 능력을 장기적으로 키워나가도록 노력해야할 것이다.(다양한 주제에 대해서 문제를 풀어보고 다양한 종류의 책을 읽자.)
문제를 구성하고 있는 주인공들을 찾아서 나열해 보라. 그리고 이들 간의 관계는 무엇이고, 규칙은 무엇인지 적어보라.(머릿속으로만 생각하지말고!!!)
6. 주석을 가능한 한 많이 적는다.
주석은 매우 유용하고도 중요한 요소이다. 그럼에도 불구하고 많은 사람들이 이를 소홀히 한다. 자신이 작성한 코드도 몇일만 지나면 이해가 안되는 경우가 많다.
적어도 이해하는데 시간이 걸린다. 주석은 이러한 시간들을 절약해줄것이며, 보다 에러가 적은 코드를 작성하는데 도움을 줄 것이다.
특히 여러사람이 공동작업을 하는 경우에는 더욱 더 중요하다. 서로를 위해서...
작업과 관련된 가능한한 많은 정보를 주석에 담도록 하자.
7. 작업일지를 작성한다.
과학자들이 매일 연구한 내용을 일지로 적듯이 여러분들도 일지를 적어보자. 오늘은 이렇게 저렇게 해봤는데 잘 안되었다...
xxx.java의 코드를 이렇게 바꾸었다. 몇시몇분에 xx로 백업받아 놓았다... 라는 식으로 가능한한 자세히 적도록 한다.
이렇게 함으로써 여러분들의 경험을 기록으로 쉽게 보관할수 있으며, 문제해결에 많은 도움이 된다.
8. 자신의 소스를 가꾼다.
보통 코딩을 마치고 나면, 모든 것을 덮어두곤 한다. 원하는 결과를 얻었다고 거기서 그치지 말고 이제 로직과 코드를 보다 효율적으로 개선할 방법이 없는지 고민해보자.
글을 써놓고 좋은 글로 만들기 위해 읽고 또 읽고 다듬듯이 코드를 다듬어보자. 여러분들의 코드를 구사하는 능력이 보다 향상되어가는 것을 느낄 수 있을 것이다.
여러분들을 위한 제안은 작은 프로그램을 만들어서 오랜기간동안 점차 발전시켜 나가는 것이다. 새로운 기능들을 하나씩 추가해가고, 기능을 발전시켜나가보자.
이과정을 통해서 여러분들의 실력은 몰라보게 향상될 것이다.
9. 생각하라.
항상 머릿속에 한 가지 문제를 준비하라. 지하철을 기다리거나, 화장실에서 볼일 볼때 문제를 풀어보자. 유레카를 외치고 뛰어나올지도...^^;
10. 좋은 책을 선택한다.
공부를 시작할때 제일 먼저 하는 일은 아마도 책을 고르는 일일 것이다. 보통 책 하나에 수십시간을 학습하게 되는데,
책을 잘못 선택한 경우 수십시간과 노력을 허비하는 셈이다. 바른 책을 고르는 일은 쉬운일이 아니지만,
최소한 몇시간을 투자해서 최선의 선택을 하도록 노력해야 수십시간을 허비하는 일이 없을 것이다.
책을 고르는 법은 여러가지가 있겠으나, 가장 중요한 것은 본인이다. 서점에서 같은 종류의 몇가지 책을 놓고 서로 비교해보면, 시간을 들인만큼 보다 나은 선택을 할 가능성이 높아진다.
많은 컴퓨터 서적이 독자들의 선택을 어렵게 하고, 컴퓨터 업계 특성상 좋은 책을 만들기 보다 빨리찍어서 파는 것이 더 중요해진 요즘.
독자들의 바른 선택이 보다 나은 책이 출판되는 것을 가능하게 한다는 것을 알았으면 한다.
출처: http://freeboys22.blog.me/130145469242
---
책벌레 카페: 책벌레그룹 http://cafe.naver.com/bookwormkr
책벌레 운영자: 소셜홀릭 https://facebook.com/fbsocialholic
좋아요 335개댓글 74개공유 813회
저는 개발자(developer)보다 프로그래머(programmer)라고 부르는 걸 더 좋아합니다. 왜냐하면 프로그래머라는 단어는 프로그램(program)을 만드는 이라고 명확하게 나타내주기 때문입니다.
개발자라는 단어는 어쩐지 프로그래머라는 직업이 단순 코더(coder)로 인식되기 시작하면서, 그보다 더 많은 일을 하고 있다고 포장하기 위해 그럴듯한 단어로 대체한 것처럼 느껴집니다.
프로그램은 코드(code)입니다. 아무리 많은 기술과 기법을 사용했어도 그 마지막 결과물은 결국 코드입니다. 그래서 저한테 프로그래밍(programming)이란 곧 코딩(coding)을 의미합니다.
또한 코딩은 머릿속 추상적인 개념이 구체화되는 과정이기도 합니다. 언제부터 소프트웨어 공학이 프로그래밍에서 설계와 구현(코딩)을 구분했는지는 모르지만, 제게는 코딩이 곧 프로그래밍의 중심입니다.
나머지는 코딩을 더 잘하기 위해 필요한 도구이며 과정일 뿐입니다. (물론 디버깅도 프로그래밍의 큰 과정 중 하나입니다. 정확하게 요구사항을 분석하는 것, 코딩을 시작하기 위한 기본 개념을
선택하고 설계하는 것 등도 당연히 프로그래머의 일입니다. 하지만, 이 글에서는 코딩이 주인공이라서 다른 부분은 과소평가 할테니 소프트웨어 공학 하시는 분은 태클 걸지 말아 주시길 :)
아무튼, 댓가를 받고 업으로 프로그래밍을 하기 시작한지 약 15년 즈음 되는 지금, 언젠가부터 현업 프로그래머 중에서는 선배보다 후배들이 많아지다 보니,
가끔 술자리에서 실력도 안되는 제게 어려운 질문을 하는 후배들에게 항상 취중에 중언부언하던 개인적인 생각을, (역시 취중에) 대략 세 가지로 감히 정리해 보았습니다.
좋은 코드를 작성하려면 다른 사람의 코드를 많이 읽어야 합니다.
글 쓰는 사람이 책 한 권을 쓰기 위해 열 배 백 배 이상의 독서를 하듯이, 프로그래머도 많은 코드를 읽어야 합니다. 좋은 코드에서는 배움을 얻고,
나쁜 코드에서는 금해야 할 게 무엇인지 알게 됩니다. 그런데, 유독 프로그래머는 다른 사람의 코드를 읽는 일에 인색합니다.
심지어 매뉴얼이나 API 문서에 나온 예제 코드도 읽지 않고, 동료가 작성한 코드도 읽지 않으며 오직 자신이 만든 코드만 읽고 또 읽습니다.
모든 프로그래밍은 모방에서 시작합니다. 우리 용어로 하면 카피 앤 페이스트(copy & paste) 쯤 되겠지요. 하지만, 보는 만큼 아는 만큼 프로그래밍하게 됩니다.
경험이 아무리 많아도 새로운 지식이 없으면 결국 아는 한도 내에서 똑같은 틀의 코드만 계속 만들 뿐, 나아지는 건 없습니다.
참고로, 저는 이런 관점에서 오픈소스 프로젝트를 지지하는 편입니다. 프로그래머를 성장시키는 가장 빠른 방법 중 하나는 오픈소스 프로젝트에 참여시키는 것이라는 말도 공감합니다.
좋은 코드를 작성하려면 많이 쓰고 자주 고쳐야 합니다.
하나의 기능을 구현하기 위해 수없이 많은 시행착오를 겪어야 결국 좋은 코드가 나옵니다. 글 쓰는 사람 예를 다시 들어보면, 한 번 쓴 글을 바로 내보내는 경우는 없습니다.
수없이 다시 쓰고 퇴고의 과정을 거쳐, 심지어 쉼표 하나 마침표 하나까지 고치고 또 고칩니다. 프로그램은 더 고약한 놈이라, 릴리스 이후에도 언제든 다시 손을 대야 합니다.
저는 프로그래밍할때 가장 중요한 부분부터 간단하게 코딩하는 습관이 있습니다. 똑똑한 편이 아니라서, 대부분의 개념은 코딩하면서 구체화되는 경우가 대부분입니다.
변수 이름부터 구조체, API 방식, 동작 알고리즘 모두 계속 코딩하고 테스트하면서 계속 바뀝니다. (보통 다른 사람의 다섯 배 정도는 코드를 다시 고쳐 쓴다고 자부합니다. 자랑은 아닌데…)
그래서 저는 처음에 만든 코드 형태가 그대로 있는 경우가 별로 없습니다.
프로그래머는 결국 코드로 자신의 생각을 표현해야 하고, 자신의 주장을 뒷받침해야 합니다. 코드의 가독성(readability)을 높이기 위해 노력해야 하는 이유이기도 합니다.
쉽게 레벨업 되려는 욕심은 버려야 하지만, 꾸준이 노력하는 습관은 욕심내야 합니다.
프로그래머는 알아야 할 게 너무 많습니다. 새 언어, 라이브러리, 디자인패턴, 기술 , 개발 도구, 플랫폼, 코딩 스타일, 디버깅 기법… 거기에다 글도 잘써야 하고,
영어도 잘해야 하고, 말도 잘해야 하고… 알면 알수록 모르는 게 더 많다는 걸 느끼고 기본 개념이 중요하다는 걸 깨닫게 됩니다. 그리고 좌절과 무기력도 동시에 느낍니다.
이럴때 대부분은 머리가 나빠서, 혹은 소질이 없는 것 같다고 핑계를 대는데… 제 경험엔 모두 핑계일 뿐, 노력하지 않고 게으르거나 또는 투자를 하지 않고 바라기만 하기 때문입니다.
제가 자주 인용하는 표현이지만, 강물에 아무리 돌을 던져도 티가 나지 않습니다. 하지만, 좌절하지 않고 계속 던지다 보면 물 밑에서 돌무더기는 계속 쌓이게 되고,
어느 순간 수면위로 올라오게 되면, 그때부터는 한 개만 던져도 바로 쌓이는 게 티가 납니다. 프로그래밍도 마찬가지라, 어느 순간 흩어져있던 여러 가지가 한 가지로
연결되면서 깨닫게 되는 순간이 있습니다. 이미 알고 있던 지식의 다른 관점, 다른 개념도 조금씩 보이기 시작합니다. 그리고 그 후부터는 조금만 노력해도 다른 사람에 비해 쉽게 이해할 수 있게 됩니다.
하지만, 대부분 이 단계까지 오기 전에 포기하거나, 자기합리화를 선택합니다.
여기까지 적다보니, 역시나 대가들이 했던 말을 앵무새처럼 되풀이하고 있군요. 아, 몇 시간 동안 적은 글 버리기는 아까워 그냥 내버려 두니, 저보다 나중에 시작하시는 분들에게 조금이라도 도움이 되길 바랍니다.
그리고, 지극히 개인적인 생각이라 나중엔 바뀔 수도 있고 논리적 오류도 많을 테지만, 개인 블로그에 돈 받지 않고 적는 글이니, 이렇게 생각하는 사람도 있구나 하고 넘어가 주시길~
구글이 프로그래머를 뽑는 법…
12월 29, 2011에 게시됨| 댓글 26개
입사하기 전 인터뷰(면접)를 할 때부터 구글은 뭔가 다른 회사라는 것을 알 수 있었습니다. 10년 쯤 전이긴 하지만, 삼성에서 면접을 본 경험이 있었는데 구글의 인터뷰는
이와는 전혀 다른 경험이었습니다. 구글은 들어가기 전부터도 벌써 사람을 정말 공들여 뽑고 잘 키우는 회사라는 생각을 들게 만들었습니다.
[구글이 원하는 인재]
1. 우선 구글은 skillset (기술) 보다는 problem solving ability (문제해결능력)에 더 중점을 두어 사람을 뽑습니다. 예를 들어 구글의 Irvine 사무실에서는
대부분 Java룰 사용하지만 저는 Java를 전혀 못하는데도 인터뷰를 할 수 있었고 인터뷰할 때에는 C/C++에 대한 면접만 봤습니다. 구글에서는 어차피 프로그램언어나
개별적인 기술들(skillset)은 5년마다 새로 배워야 하는 것들이라 이보다는 한가지 언어라도 확실히 이해하고 있는지, problem solving을 할 수 있는
전산학의 기초를 제대로 가지고 있는 지가 더 중요하다고 봅니다.
2. 구글은 전산학의 기초를 아주 중요하게 봅니다. 따라서 가장 중요한 인터뷰 질문들은 마치 학부의 data structure 과목 시험문제와 같습니다.
3. 구글은 코딩도 아주 중요하게 봅니다. 그런데 얼마나 넓게 아느냐보다는 얼마나 깊게 아느냐를 봅니다.
예를 들어 Java의 API를 많이 알고 있는 것보다는 Object Oriented 언어의 기본적인 개념을 얼마나 잘 이해하고 있는지를 봅니다.
[인터뷰 진행 방식]
1. 서류심사: 구글은 합격률이 1% 미만이라 어쩔 수 없이 서류심사에서 95%이상이 걸러 집니다.
2. HR (인사과) 전화 interview: 처음이자 마지막 non-technical interview로 경력 등에 대한 20분정도의 문답을 합니다.
일반적으로 면접때 많이 물어 보는 ‘왜 우리회사에 입사하느냐’/’10년후의 목표는 무엇이냐’ 등등의 질문들도 거의 없고 주로 어떤 일을 했는지, 어떤 경험을 가졌는지, 어떤 일을 하고 싶은지 등을 묻습니다.
3. 전화 인터뷰: 실제로 구글에서 일하는 Software Engineer가 전화면접을 합니다. 보통 2번 정도 하는데 질문은 자기소개 및 한 일들에 대한 것들은 간단하게만 묻고
이후로는 30분이상 data structure 및 programming에 대한 질문을 합니다. 종이와 연필을 가지고 써 가면서 문제를 풀어 대답해야 합니다. 문제는 보통 이런 식입니다
(google로 google interview questions라고 찾아봐도 예가 나옵니다 ^^):
integer operation으로 log를 구현하려면 어떻게 하는가? 이경우 총 연산의 수는?
두개의 sort된 행렬을 merge하려면 어떻게 하는가? 이 경우 complexity는 어떻게 되는가?
C++ class의 static variable은 어떤 의미가 있고 어떻게 쓰이는가?
그런데 예상문제를 열심히 풀어 보는게 어느 정도 도움은 되지만 대입시험처럼 그걸로 합격할 수 있지는 않습니다. 그 이유는 뒤에…
4. On-site 인터뷰: 직접 구글 사무실에 가서 5시간 정도 인터뷰를 합니다. 중간에 인터뷰에 포함 안되는 점심시간이 있지만, 거의 쉴 새 없이 엄청난 체력전으로 치러 집니다.
모든 인터뷰는 technical한 내용만 합니다. 5명의 면접관이 한 명씩 면접실에 들어와 한 사람당 45분가량 인터뷰를 합니다.
인터뷰 내용은 전화면접과 비슷한데 programming의 기초에 대한 질문들을 간단히 물어 보고는 위의 행렬 merge 같은 문제를 냅니다.
문제를 풀면 제시한 해답의 complexity를 물어 보고는 이를 칠판에다 손으로 써서 구현하라고 합니다.
그런데 인터뷰의 핵심은 사실 정답을 맞추느냐를 보는 것이 아니라 문제를 푸는 과정을 보는 것입니다. 처음부터 잘 define되지 않은 문제를 주어
면접자의 문제를 정의하는 능력을 보고 또 면접자가 헤메고 있으면 면접관이 옆에서 도와 주며 푸는 과정을 보고, 해답을 제시하면 이보다 더 optimal한 방법은 없을지 찾아 보라고 합니다.
사실 정답이 하나가 아닌 문제들이기 때문에 이렇게 intensive하게, interactive하게 인터뷰를 하면 면접자의 실력이 드러날 수 밖에 없습니다.
구글은 사실 잘나가는 회사이기 때문에 구글의 philosophy는 긴가민가하는 사람은 안 뽑는게 낫다입니다. 못하는 사람을 뽑는 것보다는 잘하는 사람을 놓치는 게 낫다는 거죠
(사람을 해고하기 가장 좋은 시기는 채용하기 전이라는 격언도 있습니다 ^^). 하지만(!) 면접에서 한 번 떨어 진다고 하더라도 6개월만 지나면 다시 지원할 수 있도록 기회를 열어 주고 또 다시 지원하기를 권합니다.
저도 사실 인터뷰에서 떨어진 경험이 있습니다 ^^;
제 경험으로는 한국의 회사들이 구글처럼 공들여 사람을 뽑지는 않는 것 같습니다. 구글 수준의 엘리트들을 뽑는 것은 아니더라도 기본적인 data structure에 대한 이해가 있는지를
알아 보는 것은 중요하고 또 눈 앞에서 칠판에다가 코딩을 해 보라고 하는 것 역시 아주 중요합니다. (미국의) 작은 회사에서 인터뷰를 해 본 어떤 사람이 스펙이 꽤 좋은
사람 중에서도 아주 기본적인 수열 문제조차도 제대로 코딩하지 못하는 경우를 많이 봤다고 합니다. 물론 이를 위해서는 면접관의 능력 역시 중요하죠.
그래서 구글에서는 면접관에 대한 training 역시 따로 합니다.
물론 한국의 일반적인 소프트웨어 회사가 구글처럼 잘할 것 같은 사람들을 막 떨어 뜨릴 여유가 있는 건 아닐지 모릅니다. 취직하려는 사람은 일자리가 없다지만
뽑는 사람들은 뽑을 만한 사람이 없다니까요. 그래도 인터뷰를 제대로 하는 것은 중요합니다. 그래야 응시생들이 기초를 공부하려 하겠지요. 그렇지만 사실 사람을 잘 뽑는 것만큼 뽑은 사람을 잘 키우는 것도 중요합니다.
[뽑은 이후…]
구글의 좋은 점은 좋은 사람을 뽑은 후에 이들이 잘 성장할 수 있는 기회를 많이 준다는 것입니다. 프로그래밍에 대한 training도 많고 여러가지 교육의 기회를 줍니다.
또 유명한 80-20을 통해 자신이 하고싶은 일에 20%의 시간을 투자할 수 있게 해 줍니다.
제가 한국에 있는 회사에서 작성한 코드를 한 번 본 적이 있습니다. 그런데 코딩에 대한 회사차원의 체계가 전혀 없었고 프로그래머는 아니었어도 전산과 출신 직원이
작성한 코드였지는 간단한 optimization에 대한 이해도 없이. 지금 학교에서의 coding 교육이 어떤지는 잘 모르지만, 사실 깔끔한 코딩은 회사에서 체계적인
교육 및 시스템으로 뒷바침하지 않으면 나오기가 쉽지 않습니다.
한가지 더, 한국은 코딩에 대한 인식이 낮고 또 모든 분야에서 어느 정도 경력이 쌓이면 관리직으로 물러나거나 시스템 디자인에만 관여하는
것이 일반적이라 (개인적으로는 아주 큰 문제라고 생각합니다) 소프트웨어 회사에서 좋은 코드를 만들기 위한 체계적인 노력이 부족합니다.
한국회사에서보다는 미국회사에서 일반적인 미국회사에서보다는 구글에서 60세된 프로그래머를 더 쉽게 찾아 볼 수 있습니다.
앞으로 회사를 다니며 더 많이 배우겠지만… 사람을 공들여 뽑고 또 뽑은 사람에게 발전의 기회를 제공할 때에, 또 전산학의 기초와 좋은
코딩을 중요하게 생각할 때에 좋은 소프트웨어가 나온다는 생각입니다.
은실장의 선곡 – Acoustic Jam by Stefan Kartenberg
이 글을 읽는 당신은 아마도 우리 자가발전의 매력에 푹 빠져 그만 “프로그래밍을 배워볼까” 하는 마음을 갖고있을 것이다. 아니라고 느낀다면 아마도
당신은 당신도 모르게 생각하고있을것이다. 정말이다. 그런 마음에 왜 일어났을지 궁금해하는 청취자를 위해 프로그래밍 특집 2탄으로 그대가 왜 프로그래밍에
끌리고있는지를 설명해주는 특집편을 준비해보았다. 이번 방송까지 듣는다면 심장이 쿵쾅거릴 것이다. 끓어오르는 개발인의 혼을 느껴보자.
프로그래밍
프로그래밍은 프로그램을 만드는 것을 말합니다. 우리가 아는 컴퓨터 프로그램을 넘어 TV나 라디오 프로그램, 공연 프로그램 등 다양한 프로그램이 존재합니다.
따라서 오늘 이야기할 주제는 정확하게 컴퓨터 프로그래밍의 영역으로 한정 짓도록 하겠습니다. (그러니 간단히 프로그래머, 프로그래밍으로 지칭하도록 하겠습니다)
프로그래밍은 ‘기술을 다루는 기술’이라고 불리며 이전 화에서 다루었던 프로그래밍 언어로 명령문을 작성한 뒤 예쁘게 포장을 하면 그것이 바로 프로그램이 되는 것입니다.
코딩과 프로그래밍의 차이
그렇다면 코딩과 프로그래밍의 차이는 무엇일까요? 일반적으로 코더(코딩을 하는 사람)는 시키는 대로 프로그램을 짜는 사람, 프로그래머는 직접 생각을 하고
응용해 코드를 만드는 사람이라고 생각합니다. 엄밀히 말해서 코딩은 코드를 쓰는 행위이고 프로그래밍은 프로그램을 만드는 행위입니다. 이 둘의 차이는 관점의 차이가 있으며
서로 다른 작업입니다. 만약 한글을 모스 코드로 바꾼다고 상상을 해보면, 이 행위는 ‘코딩’을 하는 것입니다. 모스 ‘코드’라는 것을 작성하고 있기 때문입니다.
집에 있는 커피머신이 아침 7시에 작동하게 만들었다면 정해진 명령어를 통해 명령문을 작성한 것이니 이것은 프로그래밍을 한 것입니다. 프로그래밍 언어는 각각 가지고 있는 특성이
다르기 때문에 작성하는 사람의 의도를 그대로 반영해 작성하는 데에는 어려움이 있습니다. 번역 작업에 있어 언어학적인 차이가 있달까요? 그렇기 때문에 이 어려운 작업을
더 정확하고 효율적으로 작성하는 것이 코딩 작업입니다. 반대로 프로그래밍은 정해진 명령들을 이용해 논리적으로 원하는 결과를 얻어낼 수 있도록 프로그램을 짜는 작업입니다.
코드와 프로그램의 차이, 그 관점의 차이로 둘을 나누는 것이지 코딩과 프로그래밍의 우열관계는 없습니다. 그럼 개발자는 뭐냐구요? 이 두 능력을 이용해 무언가 개발해내는 사람입니다.
굳이 따지자면 개발자는 머릿속으로 프로그래밍을 한 뒤 코딩 작업을 통해 코드로 옮겨 적으며 프로그램을 개발해 간다고 보면 더 좋겠네요.
프로그래밍에 대한 오해
로봇(인공지능)의 발달로 가장 먼저 없어질 직업은 프로그래머다
대부분의 프로그래밍은 사람이 작업하며 기계가 직접 프로그래밍하는 것은 아주 적습니다. 프로그래머라면 누구나 컴퓨터를 다루는 사람으로서 컴퓨터가 스스로 프로그래밍할 수 있었다면
바로 시키고 놀고 있겠지만, 생각보다 복잡하고 거의 불가능에 가깝습니다. 컴퓨터가 못 하니까 직접 해야지 어쩌겠나요. 그리고 엄밀히 말해 컴퓨터가 할 줄 알게 되면 그것은
더 이상 프로그래밍의 영역으로 보기 어렵습니다. 인공지능 편에서도 이야기했지만 기술의 수준이 높아질수록 기계가 더 많은 작업을 할 수 있지만 이제 당연해진 기술은 프로그래밍이라고
부르지 않습니다. 60화에서 말씀드렸던 컴파일러나 인터프리터를 그 예로 들 수 있습니다. 어셈블리어를 이용해 프로그래밍하던 시절이 있었지만, 컴파일러가 나오면서 고급 언어를
어셈블리어로 대신 바꾸어 코딩을 해주는 프로그램이 나왔는데 그 때문에 프로그래머가 사라졌을까요? 여전히 어셈블리어를 다루는 프로그래머도 있고 그 이외에도 발전을
거듭하며 컴파일러와 함께 일하는 사람들이 많습니다.
프로그래밍을 하려면 영어를 할 줄 알아야 한다
일부분은 사실입니다. 먼저 프로그래밍 언어는 대부분 알파벳(글자)을 기반으로 하고 있지만, 한글이나 한문으로도 프로그래밍할 수 있습니다. 한글로 된 프로그래밍 언어나 한문으로 된
프로그래밍 언어가 있기 때문입니다. 영문으로 된 프로그래밍 언어들을 다루는 것도 영어를 할 줄 아는 것과는 별개의 문제입니다. 대부분 약어와 짧은 단어들로 이루어져 있기 때문에 영어를
한마디도 못 하는 프로그래머들도 비영어권 국가에 상당히 많은 편입니다. (우리나라를 보세요!) 물론 프로그래밍 언어에 대한 사용법이나 프로그래밍에 사용되는 도구들의 설명이 영어로
되어있기 때문에 영어를 할 줄 안다면 더 빠르고 정확하게 배울 수 있기에 유리한 점이 있지만 번역된 서적이나 프로그램도 많아서 영어를 못하면 프로그래밍은 할 수 없다는 말은 잘못된 것입니다.
프로그래밍을 배우면 좋은 점?
아는 게 많아진다
프로그래머들은 대부분 아는 것이 많습니다. 세상의 많은 것들은 겉으로 보이는 것은 빙산의 일각에 불과할 만큼 그 안에서는 수많은 작업들이 이루어지고 복잡한 구조로 구성되어 있습니다.
프로그래머가 어떠한 프로그램을 만들기 위해서는 그와 마찬가지로 내부의 복잡한 구조를 모두 이해해야 좋은 프로그램을 만들 수 있는 것입니다. 따라서 프로그래머들이 아는 것이 많다는 것은
잡상식을 넘어 다양한 분야에 생각보다 그 원리를 깊게 이해하고 있는 사람이 많습니다.
논리에 강해진다
일반적으로 논리에 강한 사람은 변호사나 검사 같은 사자 들어가는 전문직이라고 생각합니다. 하지만 프로그래밍도 그에 준하는 수준의 논리를 요구하며 코드 한 줄 한 줄이 논리에 맞아야
프로그램이 정상적으로 작동합니다. 다만 말이 아닌 프로그래밍 언어로 그 논리를 표현할 뿐입니다. 그렇게 코드를 수십, 수만 줄을 작성하며 작성된 코드 덩어리 간의 논리 또한 알맞게 서로
융화되어야 합니다. 논리력을 키우려면 논리야 놀자 읽지 말고 개발을 한 번 해보세요.
문제해결능력이 상승한다
앞서 말한 대로 프로그래밍을 하려면 아는 것이 많아야 합니다. 또한, 프로그래밍을 할 때는 자기가 사용하고 있는 프로그래밍 언어의 특성, 프로그램이 작동할
사용환경 (하드웨어, 운영체제 등의 지식), 다양한 의존성 (사용하는 함수, 라이브러리들이 서로 겹치는 부분)을 알고 있어야 하기 때문입니다.
이렇게 많은 제약 조건들을 고려해가며 요구사항에 따라 최선의 프로그램을 만들어내는 것은 굉장히 어렵습니다. 이러한 작업을 반복하게 되면 문제 해결 능력이 점점 올라가게 됩니다.
프로그래머가 가지고 있는 지식을 각각 레고 조각이라고 생각한다면 문제 해결 능력은 이 조각들을 이용해 어떤 형태의 구조물을 만들어 낼 수 있는가를 말합니다.
(이는 일부분이며 문제 해결 능력은 여러 가지로 평가하고 관찰될 수 있습니다) 우리가 아는 다국적 IT기업들도 이와 동일한 모습을 가집니다. 구글의 경우 기술 능력보다
문제 해결 능력을 평가에 더 중점을 둡니다. 실례로 구글의 사무실에서 Java를 사용함에도 Java를 사용할 줄 모르는 사람도 면접에서 붙는 경우가 있습니다.
어차피 프로그래밍 언어나 기술들은 시간이 흐를수록 변해가기 때문에 새로 배워야 하는 부분이지만 문제를 해결하는 능력은 그 모든 것의 밑바탕이 되기 때문입니다.
오늘 무엇인가 정리하다가 도대체 프로그래머가 알아야하는 기본 지식은 어디까지일까라는 의문이 들었다. 물론 컴퓨터 기본 구조, 네트워크, 자료 구조, 알고리즘,
C, C++, 자바, 다양한 프레임워크 등등 모든 영역을 잘하면 좋겠지만 모든 영역을 학습하기에는 지금의 지식이 너무 방대하기 때문이다.
그렇다면 프로그래머로 일반화해서 이야기하기는 힘들테니 웹 프로그래머 관점에서 이야기해보자. 내가 처음 웹 프로그래밍을 시작할 때는 웹 프로그래밍은 누구나
할 수 있는 것으로 인식되었다. 웹 프로그래밍이 등장하기 이전의 선배 프로그래머들은 웹 프로그래밍을 하는 프로그래머를 무시하는 경우가 많았다. C도 할 줄 모르고,
자료 구조나 알고리즘도 모르는 놈들이 무슨 프로그래밍을 한다고 설치냐는 인식이 팽배해 있었다. 프로그래머를 하려면 C는 기본으로 할 줄 알아야 하는데 자바부터 시작해서
무슨 프로그래밍을 하겠냐는 인식이 있었다.
그로부터 10년 이상이 지난 지금의 현실을 보면 어떠한가? 10년 전에 자바 기반으로 웹 프로그래밍을 처음 시작한 선배 개발자들은 후배 개발자들을 무시한다. 자바,
JSP, Servlet, Jdbc, 쿼리에 대한 개념도 제대로 가지고 있지 않은 놈들이 무슨 프로그래밍을 하느냐고... 요즘 친구들은 처음부터 Spring, myBatis와 같은
프레임워크 기반에서 개발하다보니 웹에 대한 기본 개념도 모르고 있다면서 말이다. 나도 10년 전부터 시작한 개발자로서 새롭게 시작하는 후배 개발자에게 비슷한 인식을
가지고 있는 것이 사실이다.
그렇다면 내가 처음 웹 프로그래머의 길을 걷기 시작했을 때의 선배들이 했던 이야기들이 맞는 것인가? 그 선배들의 조언에 따라 나는 C를 배우고, 자료구조와 알고리즘에
많은 시간을 투자했어야 하나? 그렇다면 지금 후배 개발자들은 어느 수준까지 지식을 쌓아야 하는 것인가? 이렇게 거슬러 올라가면 어셈블리까지 알아야 되는 것인가?
나는 자바와 웹으로부터 프로그래밍을 시작하면서 기존의 선배들과는 다른 접근 방식으로 프로그래밍을 할 수 있었다고 생각한다. 그렇다면 지금 시작하는 후배 개발자들은
Ruby On Rails와 같이 Full Stack으로 갖추어져 있는 프레임워크로부터 시작한다면 우리와는 완전히 다른 접근 방식을 취할 수도 있지 않을까? 자바 개발자의 경우
수 많은 프레임워크를 학습하고 가장 좋은 조합을 만들기 위해 프레임워크 설정 파일과 싸우는 동안 Ruby On Rails와 같이 Full Stack으로 갖추어진 프레임워크에
익숙한 개발자들은 프레임워크 자체에 대한 관심보다는 서비스 자체에 대한 관심도가 더 높아지지 않을까라는 생각을 해봤다. 자바 기반 웹 개발과 같이 다양한 프레임워크를
조합하고 최상의 조합을 찾는데 시간을 투자하다보니 기술적인 측면에 초점이 맞춰지는 경우가 많은데 Ruby On Rails와 같은 경우에는 사용자 요구사항, 빌드, 배포,
유지보수 등 그 다음 단계에 대한 고민을 하는데 더 많은 시간을 투자할 수 있지 않을까라는 생각을 해봤다. 내가 처음 자바로 시작했을 때 C의 포인터 때문에 머리 아파하지
않고 객체 지향에 좀 더 초점을 맞추면서 프로그래밍을 할 수 있었던 것처럼 말이다.
지금 시점에 우리가 가져야할 태도는 무엇일까? 능력이 된다면 더 많은 지식을 습득하면 좋겠지만 미래를 생각한다면 과거의 너무 많은 지식이 독이 될 수도 있지 않을까?
소프트웨어 아키텍트(SA)
마이크로소프트의 정의에 따르면, 전략, 조직 역학, 프로세스, 커뮤니케이션, 리더십 등 관리능력과 엔지니어링에 대한 깊은 이해를 갖춘 개발 지휘자를 아키텍트라 부른다.
여길 참고하자
엄밀히 말하면 프로그래머가 아니라 기획자다. 조직 관리 능력, 리스크 관리 능력 같이 프로그래밍 능력과는 전혀 관계없는 분야의 지식을 요구한다. 건축 쪽의 아키텍트와
마찬가지로 현장(프로그래밍)을 모르는 채로 될 수 있는 직업은 아니지만 현장 지식만 잔뜩 쌓는다고 될 수 있는 직업도 아니다. 게다가 전문 교육을 이수하는 것만으로는
될 수 없고 경험이 아주 중요한 직종으로써 프로그래머판 도선사와 비슷하다.
풀 스택(Full-stack) 개발자 : 위의 프론트엔드와 백엔드를 모두 다룰 수 있는 개발자. 의외로 그리 드물지 않다. 프론트엔드나 백엔드나 사용하는 기술이 거의 비슷하고
서로 겹치는 게 많기 때문이다. 하지만 실상을 놓고 보면 자신을 풀 스택 개발자라고 소개하는 사람은 아직 본인의 전문 분야가 확립되지 않은 쉽게 말해 '신참' 개발자일 확률이 높다.
그렇지 않다면 홈페이지 제작 프리랜서로 활동한 경력이 긴 일인기업 대표이거나. 둘 중 어디에 속하는지 확인해 보고 만약 후자라면 세 배의 몸값을 제시해서라도 꼭 잡도록 하자.
최소 3인분 이상을 해내는 슈퍼맨이다.
