세계명작영화 100선

모과이/취미 2011. 2. 27. 16:27

<세계명작영화 100선>

저자:이일범

미국 영화협회에서 발표한 최고의 영화 100편과 LA 비평가 협회, 뉴욕비평가 협회에서 발표한 작품,

그리고 역대 아카데미 수상작을 토대로, 시중에서 DVD나 비디오를 구할 수 있는 작품을 중심으로 선정

 

 

1. 서부 전선 이상 없다(1930)

2. 어느 날 밤에 생긴 일(1934)

3. 스미스씨 워싱턴에 가다(1939)

4. 바람과 함께 사라지다(1939)

5. 폭풍의 언덕(1939)

6. 분노의 포도(1940)

7. 시민 케인(1941)

8. 말타의 매(1941)

9. 꿈속의 낙원(1941)

10. 카사블랑카(1942)

11. 멋진 인생(1946)

12. 위대한 유산(1946)

13. 신사 협정(1947)

14. 올 더 킹스 맨(1949)

15. 이브의 모든 것(1950)

16. 선셋 대로(1950)

17. 아프리카의 여왕(1951)

18. 젊은이의 양지(1951)

19. 욕망이라는 이름의 전차(1951)

20. 사랑은 비를 타고(1952)

21. 하이 눈(1952)

22. 지상에서 영원으로(1953)

23. 이창(1954)

24. 워터 프론트(1954)

25. 마티(1955)

26. 이유 없는 반항(1955)

27. 수색자(1956)

28. 콰이강의 다리(1957)

29. 현기증(1958)

30. 뜨거운 것이 좋아(1959)

31. 북부서로 진로를 돌려라(1959)

32. 벤허(1959)

33. 사이코(1960)

34. 웨스트 사이드 스토리(1961)

35. 앵무새 죽이기(1962)

36. 톰 존스(1962)

37. 아라비아의 로렌스(1962)

38. 닥터 스트레인지러브(1964)

39. 마이 페어 레이디(1964)

40. 닥터 지바고(1965)

41. 졸업(1967)

42. 보니와 클라이드(1967)

43. 2001: 스페이스 오딧세이(1968)

44. 미드나잇 카우보이(1969)

45. 이지 라디어(1969)

46. 내일을 향해 쏴라(1969)

47. 와일드 번치(1969)

48. 프렌치 코넥션(1971)

49. 대부(1972)

50. 차이나타운(1974)

51. 뻐꾸기 둥지 위로 날아간 새(1975)

52. 택시 드라이버(1976)

53. 네트워크(1976)

54. 스타워즈 에피소드4(1977)

55. 미지와의 조우(1977)

56. 애니 홀(1977)

57. 디어 헌터(1978)

58. 지옥의 묵시록91979)

59. 크레이머 대 크레이머(1979)

60. 불의 전차(1981)

61. 보디 히트(1981)

62. 레이더스(1981)

63. 이티(1982)

64. 투씨(1982)

65. 블레이드 러너(1982)

66. 애정의 조건(1983)

67. 파리, 텍사스(1984)

68. 아마데우스(1984)

69. 아웃 오브 아프리카(1985)

70. 플래툰(1986)

71. 언터처블(1987)

72. 레인 맨(1988)

73. 해리가 샐리를 만났을 때(1989)

74. 드라이빙 미스 데이지(1989)

75. 늑대와 춤을(1990)

76. 북회기선(1990)

77. 좋은 친구들(1990)

78. 양들의 침묵(1991)

79. 저수지의 개들(1992)

80. 용서받지 못한 자(1992)

81. 조이 럭 클럽(1993)

82. 도망자(1993)

83. 포레스트 검프(1994)

84. 쇼생크 탈출(1994)

85. 매디슨 카운티의 다리(1995)

86. 쉰들러 리스트(1995)

87. 잉글리쉬 페이션트(1996)

88. 파고(1996)

89. 인생은 아름다워(1997)

90. 타이타닉(1997)

91. 이보다 더 좋을 순 없다(1997)

92. 트루먼 쇼(1998)

93. 세익스피어 인 러브(1998)

94. 라이언 일병 구하기(1998)

95. 플레전트빌(1998)

96. 아메리칸 뷰티(1999)

97. 아이즈 와이드 셧(1999)

98. 내 어머니의 모든 것(1999)

99. 뷰티풀 마인드(2001)

100. 피아니스트(2002)

 

[출처] <세계명작영화 100선>|작성자 찬란한S

저작자표시 비영리 동일조건
Posted by 모과이IT
,

[니츠프로젝트] 익스플로러9에서 폰트 초기화 되는 현상

모과이/프로젝트 2011. 2. 11. 20:06
1. Sub 다이얼로그 폰트 초기화
Ctrl 함수에나 BaseClass 함수 등지에
WM_UPDATEUISTATE 메시지를 삽입 함으로써 해결(?)

2. Main 다이얼로그(웹브라저창)
Sub 다이얼로그에 닫기 버튼을 누르게되면 Main 다이얼로그가 갱신이 안되는 현상(?)
이부분은 차후에 정식 버전이 출시되면 한번더 보기
저작자표시 비영리 동일조건

'모과이 > 프로젝트' 카테고리의 다른 글

AFX_EXT_CLASS를 사용하여 내보내기 및 가져오기  (0) 2011.07.21
[니츠 프로젝트] AfxEnableControlContainer  (0) 2010.11.02
Posted by 모과이IT
,

랩어카운트 관련 정보 인기 펀드매니저

모과이/스크랩 2011. 1. 3. 00:38

창의투자자문 자문형랩 ‘인기몰이’…하루 만에 5,000억

이연선기자bluedash@sed.co.kr
미래에셋 디스커버리펀드 신화를 만든 서재형 펀드매니저가 설립한 창의투자자문의 자문형 랩이 첫날 약 5,000억원 이상의 뭉칫돈을 끌어모으며 인기몰이에 나섰다.

13일 증권업계에 따르면 창의투자자문은 이날 삼성증권, 대우증권, 한국투자증권, 미래에셋증권 등 12개 증권사를 통해 투자자금을 모집한 결과 약 5,000억원의 자금이 몰린 것으로 나타났다. 대형 증권사의 경우 삼성증권, 한국투자증권, 미래에셋증권 등에 증권사별로 700억~800억원이 들어왔고, 동양종합금융증권 등 기타 증권사에도 적게는 50억원에서 많게는 100억원까지 들어왔다.

창의투자자문의 자문형랩에 쏠린 투자자금은 신규자금도 있지만, 기존의 펀드나 자문형랩을 해지하고 갈아타는 경우도 많은 것으로 분석됐다. 김준모 삼성증권 이촌지점 PB는 “서재형 펀드매니저의 인지도가 높은 데다 초기에 들어가야 수익률이 더 높다는 인식 때문에 출시 전부터 투자자들의 문의가 많았다”며 “특히 펀드를 해지하고 가입한 고객들이 꽤 많다”고 말했다. 배준영 미래에셋증권 랩운용팀장도 “코스피가 2,000선에 육박하지만 내년 시장전망이 나쁘지 않다는 전망에 투자자들이 적극적”이라며 “신규가입자와 기존 자문형랩에서 갈아타는 투자자 비율이 1대 4정도 된다”고 설명했다.

하지만 주요 증권사가 인기상품을 동시에 판매하면서 과열경쟁 양상도 나타나고 있다. 대형 증권사의 한 관계자는 “일부 증권사의 경우 지난주부터 수 천억 원 대 사전예약을 받았고, 경쟁사보다 판매액을 늘리려고 치열한 눈치작전을 벌이는 모습도 보인다”고 말했다.

[출처] 창의투자자문 자문형랩 ‘인기몰이’…하루 만에 5,000억 (한국증권 투자클럽) |작성자 청즉무욕

저작자표시 비영리 동일조건

'모과이 > 스크랩' 카테고리의 다른 글

깨끗한 코드 만들기  (0) 2011.09.30
자수성가한 사람의 18가지 성공 비법  (0) 2011.09.11
송화준 투비소프트 소장…”난 아직 프로그래밍이 재밌다”  (0) 2011.07.13
[안철수] 그가 젊은 세대에게 전하는 여섯 가지 조언  (0) 2011.05.30
스티브 잡스가 제시한 '4단계 혁신이론'  (0) 2011.03.10
Posted by 모과이IT
,

큐브 맞추기로 말하는 개발자 실력 향상 시나리오

모과이/경력관리진로 2010. 12. 28. 00:16

[출처] http://toby.epril.com/?p=418


작년 이맘 때쯤에 마소의 호랭이 정희용 편집장(그땐 정기자)의 압력으로 "개발고수 12인이 말하는 실전 노하우" 시리즈의 글을 하나 썼다. 글의 아이디어는 사실 정기자가 준 것이다. "나는 개발고수도 아니고 별 실전 노하우도 없다"고 저항을 했음에도, "큐브랑 개발과의 관계를 무조건 만들어 내서 글을 쓰라"고 계속 압박하는 바람에 맘 착한 나는 머리를 쥐어짜서 그동안 즐겨온 큐브와 역시 즐겨온 개발의 실력향상 관계를 만들어내야 했다. 막상 글을 쓰면서 생각해보니 역시 모든 원리는 다 비슷하다는 생각이 들었다. 재미삼아 읽어보면 나쁘지 않을 듯. 다른 것은 모르겠지만, 결론 - 고수편은 좀 진지하게 생각해온 것이다.


큐브 맞추기로 말하는 개발자 실력 향상 시나리오

소프트웨어 개발에는 끝이 없다는 말이 있다. 더 이상 수정할 필요가 없을 만큼 완벽하게 완성된 소프트웨어란 없다는 뜻이다. 마찬가지로 더 이상 실력향상이 필요 없을 만큼 완벽한 경지에 이른 개발자도 없다. 모든 개발자는 끊임없이 성장해야 한다. 하지만 모든 사람이 같은 속도와 성취도를 가지고 성장하지는 않는다. 효과적인 개발자의 실력향상과 성장에 대해 얘기해본다. 요즘 필자에게 취미를 묻는 사람이 있다면 필자는 주저 없이 ‘큐브 맞추기’라고 대답한다. 많은 사람들이 어릴 때 많이 가지고 놀았던 정육면체의 그 루빅스 큐브(Rubik’s Cube)이다. 큐브는 여섯 가지 색깔을 가진 총 26개의 블록을 이리 저리 회전시켜 모든 면의 색이 같아지도록 하는 간단한 놀이기구다. 기껏해야 6면을 가진 26개의 블록, 그중에서도 고정되어있는 가운데 6개를 제외한 20개의 블록을 움직이는 게임일 뿐이다. 하지만 큐브를 움직여 만들 수 있는 블록의 조합이 무려 43,252,003,274,489,856,000 가지나 된다는 사실을 아는지? 무려 4,000경이나 되는 조합의 수가 나온다는 것이다. 

그 많은 조합을 가진 다양한 방식으로 섞인 큐브를 모든 면이 같은 색을 가지도록 조합하는 것은 그리 간단한 일이 아니다. 그래서 많은 사람들이 큐브를 도전했다가 한 면 정도의 색을 맞춘 뒤 금방 포기하고 만다.알고 보면 큐브의 세계는 나름 심오하다. 그 조합의 수만큼 다양한 색을 맞추는 솔루션들이 있다. 많은 수학자들이 큐브에 담긴 수학적 원리를 연구하고 있기도 하다. 큐브를 자기만의 방식으로 더 빨리 또는 더 적은 횟수로 맞추는 대회가 우리나라를 비롯해 전 세계에서 매년 열리고 있다. 큐브관련 동호회와 카페에서 수만 명의 회원이 활발한 활동을 하고 있다. 최근 몇 년 사이에 불어 닥친 복고 게임의 열풍 덕분에 오래도록 잠잠했던 큐브의 인기가 전 세계를 다시금 강타했고, 급기야 지난해에는 아마존의 게임 베스트셀러 부문 1위를 차지하는 사건을 일으키기도 했다. 개발 노하우를 이야기해야 하는 이 코너에서 필자는 왜 갑자기 큐브 얘기를 하는 걸까? 필자가 보기에 큐브의 실력을 쌓아나가는 것과 개발자의 실력 향상 과정이 무척이나 닮아 있기 때문이다. ‘큐비스트’라 불리는 큐브 전문가가 되기 위해 노력하는 사람들의 모습과 개발자의 모습을 비교하면서 개발자의 실력 향상을 위해 필요한 자세가 무엇인지를 살펴보자.

큐브의 실력은 사용하는 큐브 기술에 따라 초급, 중급, 고급, 그리고 진정한 고수로 구분될 수 있다. 

초보자 – 기본개념 익히며 열심히 따라 하기

큐브 초보자들이 빠지기 쉬운 함정은 바로 처음부터 고수를 흉내 내려는 욕심이다. 고수들은 손이 보이지 않을 만큼의 빠른 회전으로 무작위로 섞여 있는 큐브를 10초대 초반의 짧은 시간 안에 맞춰낸다. 초당 7회전 이상의 빠른 손놀림과 중간에 버벅거림 없이 바로 다음 단계로 넘어가는 모습 등에서 우리는 감탄하게 된다. 그뿐인가. 한손으로 맞추기, 눈 가리고 맞추기, 심지어 발로 맞추기도 가능하다. 어떤 제약 조건과 환경에서도 아무런 주저 없이 척척 해내는 고수들의 모습을 보고 초보자들은 한편으로는 좌절하지만, 다른 한편으로는 강한 도전 욕구를 느끼게 된다. 문제는 어설프게 고수들의 손놀림이나 흉내 내려고 하는 사람들은 이 시점에서 대부분 실패한다는 것. 고급 큐비스트들이나 사용하는 솔루션과 알고리즘 자료를 모아다가 이해도 되지 않은 상태에서 억지로 적용해보려고 애쓰다보면 어느새 큐브에 대한 흥미는 점점 떨어지고 결국엔 그나마 초보자로서 느낄 수 있었던 최소한의 기쁨마저 맛보기 힘들어진다. 착실하게 초보의 단계를 밟아 나가는 사람은 그런 고수들의 어려운 기술보다는 자신에게 맞는 기초 내용에 충실하려고 노력한다. 일단 큐브에서 사용되는 각종 용어들과 기호들에 익숙해진다. 센터, 코너, 엣지 블록이라는 기본 구성요소를 익히고 각 블록의 특징을 이해한다. 큐브는 사실 어떤 면의 색을 맞추는 것이 아니라. 가운데 있는 블록을 제외하고는 2개 이상의 색을 가진 블록의 위치를 맞추는 것이다. 이런 개념과 함께 초보자용 솔루션을 공부하기 위한 회전 기호에 익숙해지도록 연습한다. 외울 것이 제법 많지만 그 장벽을 넘어야 한 시간이 걸려서라도 큐브를 한번이라도 맞춰보는 짜릿한 기분을 느낄 수 있다. 초보 개발자들도 마찬가지다. 어설프게 고급 개발자들이나 보고 연구하는 책을 구해 처음부터 어려운 주제로 폼을 잡으려는 개발자라면 이미 개발자로서의 첫 걸음을 잘못 내디딘 것이다. 일단 가장 기본이 되는 프로그래밍 언어와 기초 개념들을 충실하게 공부하는 것이 초보자의 바른 자세다. 기초는 대충 건너뛰고 바로 중급 이상의 기술로 넘어가려는 욕심은 결국 어느 단계에서 더 이상의 성장을 막는 장애물이 되고 만다. 초보 큐비스트는 일단 가장 기초가 되는 해법을 열심히 외워서라도 큐브 맞추기를 많이 해보는 것이 중요하다. 처음에는 잘 알지 
못한 채 무작정 따라 하기만 했던 솔루션이지만, 어느 단계에 이르면 솔루션 하나하나가 지닌 원리와 심오한 뜻이 무엇이었는지를 자연스레 알게 된다. 물론 초보자용은 좀 지루하다. 필수 회전수도 고급 큐비스트들이 사용하는 것의 2~3배 이상 된다. 하지만, 그것을 충실히 따라하면서 익히는 과정 없이는 결코 다음 단계로 나아갈 수 없다. 필자가 초급 개발자들에게 항상 강조하는 바는 일단 기초적인 내용의 코드라도 잘 만들어진 것을 열심히 분석하면서 흉내 내보라고 하는 것이다. 필자가 처음 프로그래밍을 배울 때는 마소나 컴퓨터 서적에 나온 모든 코드를 일일이 손으로 다 입력하고 그것을 흉내 내서 코딩하는 연습을 했었다. 그리고 그 중에 괜찮은 것이 있으면 그것을 잘 기억했다가 써먹으려고 노력했다. 자신의 실력을 과신하고 처음부터 자기 방식대로 하겠다고 욕심을 부리기보다는 일단은 고수들의 코드와 개발 방식을 겸허하게 받아들여 흉내내볼 필요가 있다. 물론 처음부터 고급 기술을 따라해 보라는 의미는 아니다. 가장 기초가 되는 코드들을 중심으로 그것들이 어떻게 만들어졌는지부터 하나씩 살펴보고 따라해 보는 것이 중요하다. 필자는 지금도 배우고 싶은 새로운 기술이 있다면 관련 서적이나 레퍼런스에 나오는 예제들을 빠짐없이 손으로 다 입력해서 실행해보고 그것을 숙지하려고 노력한다. 튜토리얼이나 예제에 등장하는 내용은 사실 그 기술을 만든 사람이 가장 핵심이라고 생각하는 내용을 간추리고 간추려 모아놓은 것이다. 그 내용과 순서를 완전히 숙지하지 않고 더 깊은 내용만 추구하려는 태도는 기술을 온전히 익히는 데 도움이 되지 않는다. 간단한 예제를 반복적으로 코딩 연습하는 것은 기초적이지만 핵심적인 내용을 빠르게 사용할 수 있는 훈련으로 적합하다. 그러면서 조금씩 원리를 깨닫게 되고, 머지않아 반복되는 패턴이 보이기 시작할 것이다. 기초에 충실하면서도 꾸준한 반복연습을 하는 것이 다음 단계로 나아가는 최적의 지름길이다. 큐브 초보자들은 초보 기술을 이용해 보통 양손으로 1분 이내에 큐브를 맞추는 단계가 될 때까지 연습한다. 처음에는 초보자용 솔루션을 보고 30분에 맞추던 것을 이제는 기초 공식을 보지 않고도 1분 이내에 맞추는 수준으로 올라간다. 처음에는 단순한 CRUD 코드를 작성하는 데도 예제를 봐야 하고 레퍼런스 매뉴얼을 뒤져가며 쩔쩔매다 며칠씩 보내곤 하지만, 이를 꾸준히 반복 연습하다보면 다소 응용된 CRUD를 몇 시간 내에 개발할 수 있는 실력을 얻게 된다. 이쯤 되면 슬슬 자신감이 붙기 시작하지만, 한편으로는 한계를 느끼게 된다. 지금까지 해온 것을 좀 더 빠르고 효과적으로 할 수 없을까라는 의문이 들기 때문이다. 바야흐로 이제 중급으로 올라갈 때다.

중급 – 다양한 응용기술에 관심 돌리기

초급 단계에서 이미 충분한 시간과 여유만 주어진다면 큐브를 다 맞출 수 있는 실력을 갖췄다. 하지만 여전히 그 하나하나 솔루션의 원리가 완전히 이해되진 않는다. 아무래도 기초적인 방법을 따라하면서 숙지하는 식으로 연습했기 때문이다. 그래서 중급이 되면 이제 반복되는 단순한 회전과 비효율적인 해법들을 좀 더 고급스러운 것으로 대치하기 시작한다. 흔히 말하는 각종 중급용 공식들과 팁들을 익혀나간다.
개발자도 마찬가지다. 기초를 충실히 갖춰 웬만한 프로그램은 시간만 충분히 주어진다면 만들 수 있겠지만 그래도 여전히 뭔가 부족하게 느껴진다. 고수들의 그것에 비하면 자신들의 개발 속도와 나오는 코드의 질이 뭔가 달라 보인다. 이제 기초를 넘어선 각종 응용기술과 개발 전략에 눈을 뜰 때이다. 이때 필요한 중요한 두 가지는 개념에 대한 깊이 있는 이해와 다양한 새로운 기술을 익히는 것이다. 자바라는 객체지향 언어를 배워 이제껏 잘 써왔지만 여전히 객체지향적 설계와 프로그래밍에 대한 깊은 이해가 없다면 이제 객체지향 원리들을 충실히 익힐 차례다. 또 개발자들이 부딪치는 많은 문제들에 대한 표준화된 솔루션을 정리해놓은 디자인패턴 같은 것도 공부해야 한다. 그러면서 기존에 그저 흉내 내기에 급급했던 코드들이 왜 그런 식으로 구성되었어야 했는지를 하나씩 깨닫게 마련이다. 중급 큐비스트들도 원리에 대한 이해가 점점 생겨나게 된다. 이전에는 회전을 더 많이 하더라도 가장 단순한 방법을 써서 맞추는 데만 충실했다면 이제는 그 각 회전이 가지는 의미를 알 수 있어야 한다. 큐브 공식에 가장 자주 등장하는 패턴인 ‘공식-역공식’ 패턴의 특성도 이해해야 한다. 또 방향(Orientation)과 조합(Permutation)이라는 큐브 맞추기의 중요한 원리도 이해해야 한다. 그런 것을 학습하면서 그동안 써왔던 기술들이 어떤 원리에 의해 만들어졌는지를 깨닫는 과정에 들어선다. 물론 중급 레벨에서 너무 많은 것을 기대해서는 안 된다. 다만, 이전에는 단순히 외우고 베끼고 따라 하기만 했던 것을 이제는 좀 더 깊이 들여다 볼 수 있도록 훈련하는 것이다. 중급에서 익혀야 할 또 한 가지는 속도의 향상이다. 중급 큐비스트라면 이제 양손으로 30초대에 진입하는 것을 목표로 해야 할 것이다. 초급에서는 사용하지 못했던 단축 솔루션들을 익히고 원리를 응용한 핑거 트릭(Finger Trick)이나 핑거 숏컷(Finger Shortcut) 등을 배우면서 속도의 향상에 힘쓴다. 개발자들은 생산성의 향상에 주목한다. 이제까지는 어떻게 만들던지 코드가 돌아가기만 하면 된다는 생각이었지만, 이제는 가능하면 빠르고 정확하게 동작하는 코드를 어떻게 효율적으로 작성할 수 있는지에 집중해야 한다. 초보 때는 원리를 배우기 위해서라도 가능한 한 직접 모든 것을 만들어 사용했다면 중급에서부터는 효율성을 중시해 다양한 라이브러리와 프레임워크를 도입해 보는 게 좋다. 너무 욕심을 부리지 않는 범위에서라면 새로운 기술을 익히고 그런 잘 만들어진 기술을 활용하는 즐거움에 빠져보기도 하자. 

고급 – 시간과 품질의 싸움

많은 큐비스트들이 큐브도 원하는 대로 맞출 수 있고, 제법 속도도 나는 중급 단계에서 그냥 주저앉는 경우가 많다. 더 이상의 고급 수준으로 가는 것에 대한 욕심이 없기 때문이기도 하고, 고급 실력을 갖추는 데는 사실 엄청난 노력이 필요하기 때문이기도 하다. 개발자들 또한 중급 정도의 실력이면 어디 가서나 눈치 안보고 나름의 실력을 뽐낼 수도 있고, 또한 주어진 일을 해내는 데도 무리가 없으므로 그 정도에서 만족하려는 경향이 있다. 어쩌면 그 가운데 소수의 사람들만이 도전하기 때문에 그 다음 단계가 고급이라고 불리는지도 모르겠다. 상당수의 중급 큐비스트들은 고급 난이도에 도전을 시도한다. 6면을 맞추는 데 30초 대 정도의 큐브 실력이면 어디에든지 충분히 실력을 뽐내 이목을 집중시킬 수 있다. 하지만 이제는 그런 차원이 아니라 진정한 자신에 대한 도전이 시작되는 것이므로 고급 기술을 익혀 시간을 20초대, 더 나아가 10초대 후반까지 도전하려고 한다. 그러기 위해서는 먼저 고급 기술들과 이론들을 익혀나가야 한다. 10대 때 이미 자신만의 고급 큐브 솔루션을 개발한 제시카 프리드리히 교수와 같은 천재적인 사람들에 의해 만들어진 고급 기술들은 초보자가 기억하고 알아야 하는 것보다 10~20배 이상의 공식을 암기하고, 또한 그것을 응용할 수 있는 수 백 가지의 케이스를 빠르게 파악할 수 있는 능력을 요구한다. 이는 며칠, 혹은 몇 주간의 노력으로는 도저히 도달할 수 없는 수준이므로 적어도 몇 달, 혹은 몇 년에 이르는 엄청난 노력이 필요하다. 하루에 12시간씩 연습한다는 사람들의 이야기도 종종 들어본다. 직장인인데도 틈만 나면 큐브를 손에 들고 연습하고 공식을 암기하고 다양한 응용케이스를 풀어보는 훈련을 한다. 그렇게 해서 큐브 맞추는 시간을 5초, 10초 단축하는 데 엄청난 노력을 들이는 것이다. 고급 개발자가 되는 길은 어떠한가? 역시 만만한 것은 아니다. 중급에서는 그저 기능 구현을 직접 하지 않고 남들이 만든 것을 가져다가 응용해 쓰는 훈련을 했다. 이제 고급 개발자가 되면 이제까지 해보지 않고 다루지 않았던 기술과 영역까지 받아 들여 생산성을 극대화 하고 전체 애플리케이션 구조의 효율을 따질 수 있다. 또한 품질과 유연성까지 고려한 개발이 이뤄지는 것이다. 이렇게 하기 위해서는 또한 새롭게 공부하고 훈련할 것이 많다. 품질의 향상과 궁극적인 생산성 극대화를 위해 다양한 툴을 익히고 사용한다. 이전에는 이클립스와 그 번들에만 충실한 채 썼다면 이제는 자신만의 효과적인 개발을 위한 각종 플러그인과 써드 파티 툴들을 익히고 익숙해진다. 또한 테스트 주도 개발처럼 개발의 스타일을 완전히 뒤집어버리는 큰 도전에도 과감히 뛰어들게 된다. 그것이 자신의 실력을 20~30%만 더 향상시켜 준다고 해도 기꺼이 도전할 의지가 있는 것이다. 반대로 기초의 더 아래까지 내려가 가장 깊은 원리를 파고들게 된다. 이전에는 그저 가져다가 잘 쓰기만 하면 됐다고 생각했던 각종 오픈소스 제품들을 이제는 소스코드 레벨을 들여다보며 그 원리를 파악하려고 노력한다. 어떤 개발자는 자바의 바이트코드까지 분석해가면서 성능 향상을 위해 노력하기도 한다. 고급개발자는 그저 개발 경험과 시간이 많다고 저절로 되는 것이 아니다. 부단한 노력과 함께 자신의 실력을 향상시킬 수 있는 
것이라면 무엇이든지 도전해보는 용기가 필요하다. 큐브의 고급공식을 적용하다보면 오히려 중급 때보다도 시간이 더 오래 걸릴 때가 있다. 아무래도 이전에 손에 익숙한 방식이 아닌 탓에 숙련이 되려면 그만큼 시간이 더 필요하다. 물론 충분한 연습이 따르면 이전에 사용하던 기술로는 도저히 따라올 수 없는 대단한 효과를 나타낸다. 고급개발자들이 새로운 프레임워크나 기술을 과감히 적용하려고 하다보면 자꾸 이전에 익숙하게 쓰던 방식이 더 편하지 않았는가라는 유혹에 휩싸일 수 있다. 하지만 그렇더라도 끝까지 포기하면 안 된다. 필자가 가장 넘기 힘들었던 단계는 오랫동안 익숙하게 사용해왔던 자바의 표준 기술 스택들인 JSP, EJB, JDBC 등을 버리고 스프링이나 하이버네이트 같은 프레임워크 기반의 기술을 사용하기 시작할 무렵이었다. 이전에 JSP Model1으로 개발할 때는 3시간이면 충분했던 웹 모듈이 SpringMVC로 개발할 때는 일주일이나 걸렸던 적도 있다. 십수년간 써와서 너무나도 익숙한 네이티브 SQL을 쓰지 않고 ORM이라는 다소 거추장스러워 보이는 기술을 쓰려니 다대다 관계의 테이블들을 읽어오는 것 하나를 하려 해도 매뉴얼을 뒤져야 했고, 또한 이게 맞나 싶어 자꾸 확인하면서 진행하려니 무척 답답했던 게 사실이다. 하지만 그때 포기하지 않고 끝까지 도전한 끝에 지금은 스프링과 하이버네이트 등을 이용해 누구보다도 빠르고 더 깔끔하게 우수한 코드를 작성할 수 있는 단계에 이르렀다고 생각한다. 또 하나 고급의 단계가 되기 위해 요구되는 것은 자신만의 기술과 응용력이다. 다양한 천재적인 큐비스트들에 의해 만들어진 고급 공식들이 있다. 그럼 고급 큐비스트들은 그것을 단순히 외울까? 현존하는 최고급 큐브 공식은 약 1,500개의 시퀀스를 가지고 있다. 각 시퀀스마다 적어도 5~10회전은 필요로 하니 우선 수만 개의 회전조합을 기억하고, 큐브의 상태를 딱 본 후 어떤 것을 어떻게 적용할지를 떠올릴 수 있어야 한다. 과연 그런 방식이 미련하게 암기한다고 되는 것일까? 절대 그렇지 않다. 오히려 그런 고급공식은 큐브의 개념과 원리를 완벽히 이해하고 있다면 자연스럽게 도출해 낼 수 있다. 고급 큐비스트들은 모두 자신만의 솔루션을 가지고 있고, 또 계속해서 그것을 개발해 낸다. 이전보다 조금 더 나은 회전을 할 수 있는 손동작이 있거나 회전 순서, 방식이 있다면 그것들을 끊임없이 찾아내고 자신의 것으로 만들려고 노력한다. 고급 개발자들도 또한 자신만의 노하우와 경험에서 나오는 다양한 팁과 기술들 보유하고 있고 끊임없이 자신만의 새로운 기술을 개발해낸다. 또한 그렇게 만들어진 자신의 기술을 남들과 나누는 것도 고급 개발자의 멋진 모습이 아닐 수 없다. 후배 개발자들에게 좋은 개발 팁과 기술을 알려주고 조언해주는 것, 또 자신이 작성한 좋은 코드를 오픈소스와 갈은 형태로 온라인에 공개해 많은 사람들이 배울 수 있도록 해주는 것. 그런 모습이 없이 진정한 고급 개발자라고 말할 수 있을지 의심스럽다. 이처럼 최고의 기술을 위한 부단한 노력과 자신만의 기술 창조를 위한 수고는 고급 개발자로서의 가치를 멋지게 드러내줄 것이다.

고수 – 고수에겐 끝이 없다

고급 개발자의 레벨을 넘어서서 언젠가는 최고의 경지에 다다른 고수의 길로 가는 사람들도 있다. 현재 3×3×3 큐브의 세계 챔피언은 20대 초반의 한국 청년이다. 그는 다른 사람들은 한 면도 채 맞추기 힘든 11초라는 짧은 시간에 큐브 6면을 모두 맞춰낸다. 그것도 어쩌다 한번이 아니라 여러 번 시도한 평균 시간이다. 그가 큐브를 맞추는 모습을 촬영한 동영상을 아무리 천천히 살펴봐도 그 회전을 제대로 볼 수 없다. 제대로 보려면 아마 초고속 카메라가 필요할 것 같다. 현재 그의 한글 블로그에는 전 세계의 수많은 큐비스트들이 방문해 글을 남기고 간다. 그만큼 인기가 높고, 따르는 사람이 많다. 그런데 그의 블로그를 계속 읽다보면 그 최고의 큐비스트는 그런 인기에 그다지 관심이 없음을 알게 된다. 대신 오늘도 0.1초를 더 줄이기 위해 더 나은 방법이 없을까를 고민하며 세계의 많은 큐비스트의 사이트 등을 뒤지고, 그 과정에서 좋은 것을 발견하면 그것을 연습하고 그 결과를 블로그 등에 공개하며 살고 있다. 물론 연습은 끝이 없다. 날마다 빠짐없이 자신의 기록을 측정하고 공개한다. 고수라는 것은 마치 도를 닦다가 뭔가 깨달음을 얻어 어떤 경지에 다다르는 것처럼 어느 순간 끝이 보이는 그런 위치로 가는 것을 의미하진 않는다고 생각한다. 과연 개발자의 끝이 있을까? 현재 세계 최고의 개발자라고 칭송받는 사람이 그대로 가만히 있어도 여전히 최고수의 자리를 지킬 수 있을까? 그렇지 않다. 오히려 최고의 개발자라고 불리는 사람일수록  꾸준히 자신의 실력을 향상시키고 새로운 기술과 좋은 전략을 배우기 위해 노력하고 있다. 세계적으로 유명한 개발자들을 만나 그의 강연이나 얘기를 듣다보면 다음과 같은 그들의 말에 종종 놀라게 된다. “저는 이곳 모임에서 여러 분들을 만나 이번엔 이런 것을 배울 수 있었습니다.” 그 들은 자신보다 실력이 부족하다고 생각되는 다른 개발자들에게서도 무엇인가를 끊임없이 배우려고 노력한다. 그 겸손한 자세야말로 그들을 진정한 고수의 자리에 올려놓은 힘이 아닐까 생각해 본다. 이처럼 최고의 큐비스트와 최고의 개발자들이 지닌 공통점은 결국은 겸손이 아닐까 싶다. 자신의 실력에 자만하지 않고 노력을 
게을리 하지 않으며, 끊임없이 배우려는 자세와 자신의 것을 남들과 공유하려는 마음가짐. 그것은 결국 모든 개발자가 지향해야 할 궁극적인 고수의 자세일 것이다.
저작자표시 비영리 동일조건

'모과이 > 경력관리진로' 카테고리의 다른 글

어떻게 공부할까? 프로그래머를 위한「공부론」  (0) 2011.09.11
프로그래머 경력 3년차, 이제 어디로 갈까?  (0) 2011.05.22
[TIP]프로그래머의 경력 관리는 어떻게?  (0) 2011.05.09
12명의 아키텍트에게 물어본 "아키텍트의 길!"  (0) 2010.12.09
[IT직종] 30. 응용소프트웨어개발자(응용 프로그래머)  (0) 2010.12.09
Posted by 모과이IT
,

12명의 아키텍트에게 물어본 "아키텍트의 길!"

모과이/경력관리진로 2010. 12. 9. 23:19

아키텍트로서 성장하기 위한 길은 막막하게 느껴지곤 한다. 누구에게 아키텍트로서 가야 하는 길을 물어야 할 것인가? 산전수전 다 겪은 나이가 지긋한 아키텍트로 활동 중인 사람을 만나기란 하늘의 별따기다. 따라서 필자는 업계 최고의 아키텍트들의 조언을 모아 가상의 인터뷰를 진행해 봤다. 이 인터뷰의 내용은 필자가 PLoP라는 패턴학회에서 만난 해외 거장들과의 토론과 조만간 출간될 번역서인 『아키텍트가 알아야 할 97가지』의 내용을 모아 만들었다.


손영수 안녕하십니까? 여러 선배님들. 아직 ‘Architecture’의 ‘A’자도 깨우치지 못했지만, 여러 선배님들에게 아키텍트로 성장하기 위한 방법과 또 아키텍트로서 올바른 아키텍처를 바라보는 방법들을 여쭤 보고자 합니다. 많은 이들이 궁금해 하는 질문일텐데, 여러 선배님들처럼 훌륭한 아키텍트가 되기 위해선 어떠한 것들을 준비해야 할까요? 실제 현업에서 아키텍팅할 때 어떠한 부분을 고려해야 할지 여러분들의 얘기를 듣고 싶습니다.

 

요구사항

 

Rick Kazman

실제 프로젝트는 요구사항 분석에서부터 시작한다고 할 수 있죠. 이때 아키텍트가 가져야 할 중요한 덕목은 소통과 협상 능력입니다. 설계 능력 못지않게 중요한 능력이 Social Skill입니다. 다양한 이해당사자들이 모두 만족할 수 있는 시스템을 만든다는 것은 어쩌면 불가능에 가까운 일입니다.

 

이해당사자들의 요구사항들이 서로 충돌하는 경우도 많이 경험했습니다. 빠른 메시지 전송뿐만 아니라 높은 보안 수준을 요구한다거나, 자원의 제약이 심한 임베디드 시스템에서 고성능 PC에서나 가능한 퍼포먼스를 요구하는 것들을 예로 들 수 있죠.

 

아주 적은 금액으로 모든 문제를 해결해 엄청난 효과를 누리려는 이해당사자에게 정말 기간 내 구현 가능하고 필요한 기능을 뽑아 현실에서 실현 가능한 상황에 대해 이해시키는 것이 중요합니다. 만약 여기서 이해당사자들과의 합의를 이끌어내지 못하거나, 정확한 요구사항을 파악하지 못한다면 프로젝트는 초창기부터 산으로 가게 됩니다. 그 만큼 소통과 협상 능력은 아키텍트에게 설계 능력만큼 중요한 요소라는 점을 기억해 주시길 바랍니다.

 

Mark Richards 저도 비슷한 사례를 말하고 싶네요. 전 프로젝트를 시작할 때 항상 꺼내는 이야기가 있습니다.  소프트웨어 아키텍트들이 알아야만 하고, 이해해야 하는, 그리고 고객, 동료와 함께 꼭 프로젝트 시작 전 나눠야 하는 이야기가 있습니다. 1620년대에 스웨덴과 폴란드의 전쟁에서 나온 ‘Vasa호’라는 배 이야기입니다.

 

스웨덴 국왕은 전쟁을 빨리 끝내고 싶어서 Vasa호라는 특별한 배를 만들라고 주문했습니다. 이 배가 갖춰야 했던 조건(요구사항)들은 그 당시의 어떤 배와도 비교할 수 없었습니다. 선체가 200피트 정도 더 길고, 2개의 갑판에 64개의 총을 적재할 수 있고, 300명의 군사를 안전하게 태워 폴란드로 가는 바다를 가로지를 수 있는 수송 능력을 가져야 했습니다. 배를 건조하는 데드라인(시간)을 엄수해야 했으며, 재정(자금)적으로도 여유롭지 않았습니다.

 

또한 배 설계자(아키텍트)는 이렇게 생긴 배를 이전까지는 설계한 적이 없었습니다. 크기가 작고 총을 실을 수 있는 갑판이 한 개만 있는 배를 만드는 것이 그가 주로 한 일이었습니다. 그럼에도 불구하고, 설계자는 그의 예전 경험을 기반으로 추정하고 Vasa를 설계하고 건조하기 시작했습니다. 그 배는 결국 설계대로 건조되었고 마침내 배를 띄우는 날이 왔습니다. 어떻게 되었을까요? Vasa호는 위풍당당하게 항구를 출항했지만 예포를 쏘고 난 뒤 바로 바다 저 밑으로 가라앉고 말았습니다.

Vasa호의 문제는 명확합니다.

 

그 어느 누구도 1600~1700년에 큰 전투함에서 갑판을 본적이 없었고 이러한 배의 갑판은 특히 전쟁 중에 붐비고 안전하지 않다는 것을 알았습니다. 전투함과 운송선 2개의 역할을 다하는 하나의 배를 건조하는 것은 큰 실수였죠. 국왕의 모든 소원을 충족하려고 한 배 설계자는 균형이 맞지 않고, 불완전한 배를 만들 수밖에 없었던 것입니다. 저희 소프트웨어 설계자들은 Vasa호로부터 많은 것을 배울 수 있습니다. 이와 같은 불행한 사건을 소프트웨어 아키텍처의 설계에 적용할 수도 있겠죠. 하지만 Vasa호와 같이 모든 요구사항을 충족시키려는 시도는 궁극적으로 아무것도 수행할 수 없는 불완전한 아키텍처를 만들게 됩니다.

 

 

손영수 정말 깊이 새겨야 할 교훈이네요. 그렇지만 많은 관리자나 고객이 수많은 요구사항들을 결국 쏟아내는데요. 이 사람들을 설득하고 요구사항 간에 균형을 맞추는 방법은 무엇일까요?

 

 

Rick Kazman 이해당사자들 간에 서로 상충되는 요구사항들을 우선순위화해서 아키텍처를 도출하는 ATAM(Architecture Tradeoff Analysis Method)이라는 방법이 있습니다. 이해당사자들 간에 제한된 투표권을 준 다음 정말 중요한 것 몇 개만 선택하게 하는 거죠. 그래서 정말 중요한 것들을 우선순위화할 수 있게 됩니다. 좀더 자세한 내용은 제가 쓴 『소프트웨어 아키텍처 이론과 실제(Software Architecture in Practice)』에 자세히 설명되니 읽어 보시길 바랍니다.

 

 

손영수 그 외에 요구사항을 파악할 때 더 주의해야 할 것은 없을까요?

 

Eben Hewitt 여러분에게 시스템 구축을 의뢰한 고객은 여러분의 진정한 고객이 아닙니다. 여러분의 고객의 고객이 진정한 고객이지요.

 

손영수 무슨 의미인지 정확히 이해되지 않는데요. 좀 더 자세히 설명해 주십시오.

 

Eben Hewitt

여러분이 전자상거래를 구축해야 한다면 여러분의 고객보다는 최종 웹사이트를 이용하는, 즉 웹사이트에서 물건을 구매하는 사람들에게 더 주의를 기울여야 합니다.

 

실제 웹사이트 사용자들은 전송 보안(transport security)을 필요로 할 것입니다. 그들은 저장된 데이터 암호화가 필요한 것입니다. 여러분의 고객은 이러한 요구사항을 언급하지 않을 수도 있습니다. 고객의 고객이 필요로 하는 것을 여러분의 고객이 빼먹은 것을 안다면, 왜 이러한 것들이 필요한지 언급하고 그 이유에 대해 자세히 설명해야 합니다.

 

만약 여러분의 고객이 실제 웹사이트 사용자에게 꼭 필요한 기능에 관심이 없다면, 프로젝트에서 잠시 물러서 제 3자의 입장에서 고려하십시오. 공격적인 고객(Sally Customer)은 매년마다 SSL에 대해 라이선스 비용을 치르기를 원하지 않고, 구축비용이 적게 든다는 이유만으로 그들의 신용카드 정보가 간단한 텍스트로 저장되기를 원할 수도 있습니다. 이미 알고 있는 나쁜 생각들을 실행하는 것에 여러분이 동의하게 되면, 여러분은 요구사항 수집에 실패한 것입니다.

 

손영수 그런 깊은 뜻이 있었군요. 앞으로 명심하겠습니다. ‘고객의 고객을 고려하라.’ 정말 의미 깊은 조언이었습니다. 그럼 계속해서 다른 이야기를 나눠 보도록 하죠. 아키텍트로서 고려해야 할 다른 것들이 있으면 조언 바랍니다.

 

프로세스와 팀 구축

 

 

James O. Coplien 전 프로세스와 조직에 대한 이야기를 꺼내고 싶습니다. 혹시 Conway의 법칙을 아시나요?

 

이는 여러분이 하나의 컴파일러를 만들기 위해 4개의 팀을 만든다면, 여러분은 4단계(four-pass) 컴파일러를 얻게 된다는 것입니다. 즉 조직구조에 의해 소프트웨어 구조가 정해진다는 얘기입니다.

 

이미 팀이 구성된 후 요구사항을 분석한다면, 팀 구조에 맞춰 분석이 이뤄지기 때문에, 팀 구조 그대로 소프트웨어 구조가 나올 수밖에 없습니다. 소프트웨어의 특성을 파악하기도 전에 소프트웨어의 큰 구조를 정하는 우를 범한 것입니다.

 

 

만약 팀 구성 후, 어느 팀도 맡기 애매한 요구사항을 발견했다면, 이 사각지대를 서로 맡지 않기 위해 여러 가지 복합적인 일들(정치, 책임회피 등)이 발생하게 됩니다. 이 경우 종종 프로젝트가 산으로 올라가게 됩니다. 그야말로 길을 잃는 것이지요. 그래서 팀을 구축하기 이전에 비즈니스 프로세스를 정제할 필요가 있습니다. 비즈니스 프로세스를 정제한 후에 조직을 구성해야 책임의 사각지대가 생기는 것을 막을 수 있죠.

 

 

손영수 그렇군요. 효율적으로 팀을 구축하기 이전에 어떻게 해야 할까요?

 

Krysztof Cwalina

프로젝트 관리자는 팀을 구성하기 이전에, 애플리케이션의 특성을 고려해 ‘땅콩버터나 마천루(적합한 프로세스)’를 선택해야 합니다.

 

땅콩버터(Peanut Butter)는 ‘Feature들이 중심이 되어 소프트웨어를 만드는 Bottom-Up 방식의 프로세스’를 말합니다. Bottom-Up 프로세스는 기존의 비교 대상도 없고, 전혀 새로운 소프트웨어를 만들 때 주로 사용하는 방법입니다. 이 방식은 견고하고 더디지만 모든 Feature들이 골고루 기능 향상을 가져올 수 있는 장점이 있습니다. 실제 땅콩버터처럼 모든 기능들이 골고루 퍼지고 진화할 수 있어서 땅콩버터 방식이라고 말합니다. 흔히 하위 레벨의 프레임워크나 저 수준의 라이브러리를 개발할 때는 이러한 방식이 선호됩니다.

 

만약 여러분의 소프트웨어가 고객의 요구사항들을 다수 받아들여야 하고 다양한 시나리오를 요구하는 경우인데도 Feature에 초점을 맞춘 땅콩버터 식의 프로세스와 조직을 구성하게 되면 어떻게 될까요? 위에서 언급한 것과 같이 새로운 시나리오가 탄생하면 많은 조직들이 협업해야 될 뿐만 아니라, 기능을 명쾌하게 나누기가 애매한 경우 많은 정치와 책임의 분배 문제 등이 발생됩니다.

 

이와 상반된 방식으로 마천루(Skyscraper) 방식이 있습니다. 시나리오가 마천루처럼 높이 솟아 전체 소프트웨어의 기능을 구현하기 위한 좋은 기준이 된다는 것입니다. 명백한 기준이 있다는 것은 많은 시행착오를 줄일 수 있을 뿐만 아니라, 고객의 관점에서 소프트웨어를 생각할 수 있는 장점을 가질 수 있습니다. 흔히 우리가 알고 있는 시나리오를 만들고 프로토타입(Prototype) 방식으로 개발해 나가는 것이라고 생각하면 됩니다. 바로 Top-Down 방식의 프로세스가 여기에 해당되죠.

 

여러분의 소프트웨어가 상위 레벨의 응용 소프트웨어로서, 많은 사람들에 의해 사용된다면 당연히 시나리오 기반(Sky scraper)의 방식으로 팀을 구성해야 합니다.

 

 

손영수 제가 알기론 마이크로소프트에서는 Feature Crew라는 이름으로 이미 시나리오 기반으로 팀원들이 구성되어 있다고 들었습니다. 또한 애자일(Agile)에서는 Cross-Functional Team이라고 부르기도 합니다. 정말 시나리오 기반의 애플리케이션을 개발하는 곳에서는 좋은 방법일 것 같습니다.

 

 

Rick Kazman 좋은 얘기를 해주셨네요. 우리가 설계하고자 하는 최종 소프트웨어를 고려한 형태로 조직과 프로세스가 선택되어야 합니다. 단순히 애자일의 바람이 불어서, 또는 RUP가 좋으니 이걸 사용하자는 식보다는 소프트웨어의 특성, 조직의 문화 등을 고려해 적용하는 것이 중요합니다. UML의 창시자 Ivar Jacobson 역시 RUP를 넘어 EssUP(Essential Unified Process)라는 새로운 것을 내놓았는데, 핵심은 조직과 소프트웨어 특성에 맞게 적합한 프로세스를 고려하라는 것입니다.

 

 

설계

손영수 그럼 설계 시 고려해야 할 것은 무엇입니까?

 

Kevlin Henney 여러분이 설계 시 둘 중 하나를 선택해야 한다면 대부분은 중요한 것을 선택합니다. 하지만 설계(소프트웨어 또는 다른 것들) 시에는 그렇게 해선 안 됩니다. 두 가지 선택사항이 존재한다는 것은 설계 시 불확실성을 고려할 필요가 있다는 것을 알려주는 지표(indicator)입니다.

 

A와 B 두 가지 중 하나를 결정하려고 시도하는 것보다는 A와 B 사이의 결정을 덜 중요하게 만들기 위해 어떻게 설계해야 할지를 고민해야 합니다. 흥미로운 것은 A와 B 사이의 (적절한) 선택이 존재한다는 것입니다. 설계 시 변경되는 결정을 쉽게 수용할 수 있는 분할(separation) 또는 캡슐화 기법을 고민할 필요가 있습니다.

 

 

손영수 그럼 좀 더 SoC(Separation of Concerns)와 캡슐화를 잘 하기 위해선 어떻게 해야 할까요?

 

Einar Landre

넬슨 제독이 1805년 트라팔가에서 프랑스와 스페인 함대를 격파한 이후, ‘분할 후 정복(Divide and Conquer)’ 또는 ‘걱정거리의 분리(Separation of Concern)’는 복잡하고 어려운 문제를 다루는 슬로건(상징)이 되었죠. 걱정거리의 분리로부터 우리는 캡슐화를 얻게 되고, 캡슐화로부터 우리는 경계와 인터페이스를 얻게 됩니다.

 

Kevlin Henney가 말하는 것처럼 아키텍트가 가장 크게 겪는 난제는 동작하는 시스템을 구축하기 위해 필요한 인터페이스를 정의하고 경계를 정하는 자연스러운 위치를 찾는 것이죠. ‘결합도는 낮추고 응집도는 높여라’와 ‘정보 교환이 자주 발생하는 영역들은 나누지 말라’와 같은 오래된 명언들이 몇 가지 지침을 제공하지만, 어떻게 이해당사자들에게 가능성 있는 해결방안과 문제들에 대해 쉽게 소통할 수 있는지는 알려주지 않습니다.

 

 

손영수 그렇군요. 결국 이해당사자들과 소통 속에서 적합한 균형을 찾아야 된다는 말씀이군요. 그럼 어떻게 하면 이러한 균형을 잘 찾을 수 있을까요?

 

 

 

Einar Landre

Eric Evans의 책인 『Domain-Driven Design』에 나온 Bounded Context(문맥 정합)와 Context mapping(문맥 맵핑)의 개념이 앞에서 언급한 이해당사자들과 소통의 문제를 잘 해결해 줍니다. Bounded Context는 모델이나 개념을 고유하게 정의하는 영역입니다. 그리고 우리는 Bounded Context를 설명부를 가진 구름 또는 거품으로 표현합니다. 이 설명부는 도메인에 가까운 모델 또는 개념의 역할과 책임을 정의합니다. 한 가지 예를 들면, 운송 시스템은 화물 운송, 화물 일정, 항구 이송과 같은 Context(문맥)를 포함합니다. 다른 도메인에서는 다른 이름들을 사용하는 게 적합할 것입니다.

 

Bounded Context들을 화이트보드 위에 식별하고 같이 그림으로써, Context 간에 연관관계를 그리는 것을 시작할 수 있습니다. 이러한 연관 관계들은 조직적, 기능적, 기술적 의존성을 설명하면 좋습니다. 이러한 행위의 결과로, Context 간에 인터페이스와 동일한 의미로 인식한 Context의 집합을 나타내는 Context Map이 생기게 됩니다.

 

Context Map은 아키텍트에게 무엇을 같은 걸로 볼지, 별개의 것으로 볼지 초점을 맞출 수 있고, 좀 더 현명하게 대화를 나눔으로써 분할 후 정복할 수 있는 강력한 도구를 제공합니다. 이런 지침을 통해 약한 결합, 높은 응집, 잘 설계된 인터페이스로 구성된 시스템으로 재설계할 수 있습니다.

 

 

손영수 결국 고객의 대화를 잘 이해함으로써 이러한 균형점을 찾을 수 있다는 정말 와 닿는 얘기입니다. 그럼 아키텍트가 설계 시 추가적으로 고려해야 할 사항은 무엇일까요?

 

 

 

Doug Crawford 변화의 충격을 이해할 필요가 있습니다. 뛰어난 아키텍트는 복잡도를 최소한으로 줄일 수 있어야 하며, 단단한 기본 구조를 취하면서도 급변하는 상황에 적절히 대처할 수 있는 실용적인 해결책들을 설계할 수 있어야 합니다.

 

뛰어난 아키텍트는 고립된 소프트웨어 모듈에서뿐만 아니라 사람과 사람 사이, 시스템과 시스템 사이에서 일어나는 변화의 충격을 이해해야 합니다. 변화는 기능 위주의 요구사항 변경, 요구사항의 진화, 수정된 시스템 인터페이스들, 팀원의 변동과 같은 다양한 형태로 나타날 수 있습니다.

 

소프트웨어 프로젝트 변화의 광범위함과 복잡함을 미리 추측한다거나, 모든 잠재적 문제를 미리 예측해 해결한다는 것은 불가능합니다. 하지만 아키텍트는 이러한 변화가 발생했을 때, 다른 객체나 모듈에 변화를 전파시키지 않고 변화의 충격을 완화시켜 수용할 수 있는 시스템을 구축해야 합니다. 이러한 변화를 완화하기 위한 도구나 기법으로는 다음과 같은 것들이 있습니다.

 

  • 반복 가능한 테스트 케이스를 만들고 자주 실행하기
  • 쉬운 테스트 케이스를 만들기
  • 의존성 추적하기
  • 조직적으로 행동하고 반응하기
  • 반복적인 태스크는 자동화하기

또한 위험을 미리 측정하는 Premortem은 어떠한 부분에 집중적으로 시간을 투자해야 할지 알려주는 유용한 도구입니다. 아키텍트는 프로젝트 범위의 관점에서 시간, 예산과 같은 변화의 영향을 미리 추정해야 하고 변화로 인해 엄청난 영향을 받는 부분에 더 많은 시간을 투자해야 합니다.

 

 

손영수 변화를 수용할 수 있는 구조, 소프트웨어 개발 생명주기의 관점에서 볼 때, 유지보수에 70%의 비용이 드는 관점으로 볼 때는 정말 중요한 말씀이군요. 저 같은 경우는 설계 시 실제 아키텍처를 검증하기 위해 몇 가지 프로토타입을 만들어 종종 검증합니다. 이것은 어떨까요?

 

 

Clint Shank

좋은 방법입니다. 애플리케이션 아키텍처를 구현하고 검증하고 진화시키는 유용한 전략 중 하나로 Alistair Cockburn이 이야기한 ‘걸어 다니는 해골(walking skeleton)’이 있습니다. 걸어 다니는 해골은 종단(예를 들어 UI부터 DB까지) 간을 오가며 수행되는 시스템의 가벼운 구현체입니다. 모든 주요 아키텍처상의 컴포넌트는 전부 연결합니다.

 

모든 호출(Com munication) 경로를 실험할 수 있게 작동하는 작은 시스템부터 시작한다면, 옳은 방향으로 설계 및 개발해 나갈수 있습니다.

 

 

손영수 그럼 이제 개발 과정에서 아키텍트는 어떠한 일을 하는지 궁금합니다.

 

 

개발

 

 

Erik Doernenburg 아키텍트는 현재 개발하고 있는 소프트웨어가 얼마나 잘 개발되고 있는지를 파악할 수 있어야 합니다.

 

사용자에게 가치 있는 소프트웨어도 중요하지만, 내부적으로 좋은 품질을 유지하는 것도 중요하죠. 좋은 품질을 얻기 위해서는 쉽게 소프트웨어를 이해, 유지보수, 확장할 수 있어야겠죠. 그럼 소프트웨어가 잘 개발되고 있는지 매 순간 상황을 파악하기 위한 방법에는 어떤 것이 있을까요?

 

많은 이들이 UML로 그려진 아키텍처 다이어그램을 사용합니다. 하지만 아키텍처 다이어그램에서 작은 상자들은 전체 시스템을 나타내며 상자 간의 선은 시스템 간의 의존성, 데이터 흐름, 버스와 같은 공유자원 등 모든 것이 될 수 있습니다.

 

마치 비행기에서 보는 풍경과 같은 30,000피트 뷰입니다. 너무나 추상화되어 있는 관점이죠. 반면에 0피트, 즉 바닥 레벨의 뷰를 보기도 합니다. 즉 소스 코드를 보는 것이지요. 바닥 레벨의 뷰는 연관 있는 몇 개의 객체 구조도 보지 못할 정도로 너무나 많은 정보를 제공합니다.

 

즉 이 두 뷰는 소프트웨어 품질에 대한 많은 정보를 제공하지 못한다는 것이지요. 그래서 0피트와 30,000피트 사이에 적절한 뷰가 필요합니다. 바로 1,000피트의 뷰입니다. Dependency Structure Metrics로 모듈 간의 의존성을 파악할 수 있으며 Code Metrics를 이용해 클래스의 크기를 파악할 수 있습니다.

 

특정 클래스가 거대하다는 것은 너무나 많은 책임(역할)을 가지고 있다는 의미죠. 이러한 다양한 지표들(클래스 팬아웃, 메소드 개수, Circular Dependency 등)을 지원하는 사용 툴들(NDepend, XDepend, JDepend)을 이용하면 됩니다.

 

 

손영수 1,000피트의 뷰라니 정말 멋있는 표현입니다. 저 역시 리팩토링할 때 DSM과 Code Metrics를 즐겨 이용하는 편인데, 다행히 방향은 제대로 잡은 것 같습니다. 그럼 다른 조언도 부탁합니다.

 

 

Dave Quick

거울로 보이는 문제는 실제 보이는 것보다 클 수 있습니다. 많은 소프트웨어 프로젝트에 참여했던 그 동안의 경험에 비춰 보면, 각 팀의 구성원들은 팀이 예상한 것보다 더 많은 문제를 가지고 있습니다. 소규모의 팀은 이런 문제들을 초기에 확인할 수 있지만, 대부분 잊어버리거나 무시합니다. 그 이유는 프로젝트 초기에는 이 문제가 얼마나 프로젝트 후기에 큰 영향을 미치는지를 이해하지 못하기 때문입니다. 이러한 문제를 초기에 대처하기 위한 몇 가지 전략이 있는데 다음과 같습니다.

 

  • 리스크를 관리하는 조직화된 접근 방법을 만들어야 합니다. 리스크를 관리하는 간단한 방법은 여러분이 버그를 추적할 때와 같은 방식으로 리스크를 관리하는 것입니다. 누구나 리스크를 발견할 수 있고, 각각의 리스크가 더 이상 리스크가 아닐 때까지 추적할 수 있습니다.

그 후 리스크들에 우선순위를 매기고 리스크의 상태가 변화하거나 새로운 정보가 있을 때마다 리뷰를 합니다. 리뷰는 토론를 통해 감정적인 면을 배제하도록 도와주고 주기적으로 리스크를 재평가함으로써 쉽게 기억하도록 도와줍니다.

 

 

  • 주류의 의견에 반대할 때는 나머지 팀원들이 자신의 의견을 더 쉽게 이해하도록 만드는 방법을 찾아야 합니다. 반대 의견의 가치를 인식하고 모든 팀원에게 용기를 주십시오. 그리고 토론 시 팀원들이 중립적인 자세를 가지도록 하십시오.
  • ‘구린 냄새(Bad smells)’를 주의해야 합니다. 아직 명확한 근거가 없다면 사실을 확인할 수 있는 가장 간단한 테스트 방법을 찾으세요.
  • 지속적으로 팀과 고객에 대해 이해하는 내용을 테스트해 보세요. 사용자 이야기(user story)로 우선순위 목록을 정하는 툴의 도움을 받을 수 있지만, 정기적으로 고객과 대화를 나누는 열려 있는 자세를 대체할 순 없겠죠.
  • 맹점이란 그 말 의미 자체가 말해주듯이 스스로 인지하기 어렵습니다. 여러분이 필요로 할 때 말하기 힘든 사실을 말해주는 믿음직한 사람이 여러분의 귀중한 자산입니다.

 

 

손영수 개발 도중에도 아키텍처만 그려주고 사라지는 아키텍트가 아닌, 팀원 간 또는 이해당사자 간에 소통이 잘되는 문화를 만들고 잘못된 방향으로 흘러가면 가이드해서 바로 잡아야 한다는 조언이군요. 그럼 아키텍트가 가져야 할 자세에 대해서도 조언 바랍니다.

 

 

아키텍트로서 갖춰야 할 자세

 

 

Dave Quick 아키텍트는 자신이 최고라는 대문자 ‘I’보다는, 일원이라는 의미를 가지는 소문자 ‘i’의 자세가 필요합니다. 아키텍처를 수립할 때, 여러분 스스로가 최악의 적이 될 수도 있습니다. 여러분이 고객보다 요구사항을 더 잘 이해한다고 생각하거나, 개발자를 아이디어를 구현하기 위한 단순한 자원으로 보거나, 여러분의 생각에 도전하는 개발자나 팀원을 무시한 경험이 있습니까? 성공이나 사회적 지위로 인해 자만하거나 다른 사람들이 우리를 존경한다는 착각을 가지고 있고, 자신이 만든 설계에 도전하는 것을 여러분 자신의 인격에 대한 도전으로 받아들인 경험이 있을 것입니다. 이것은 과거의 성공에 빠져 여러분을 더 작은 한계에 가두는 짓입니다.

 

아키텍트로서 스스로 성장하고 성공하는 프로젝트를 만들기 위해서는 여러분의 마음가짐을 바꿔야 합니다. 전 후배 여러분들에게 다음과 같은 자세를 요구합니다.

 

  • 요구사항은 거짓말을 하지 않습니다. 요구사항이 제공하는 비즈니스 가치를 이해하기 위해 고객과 가까이 일하십시오. 아키텍처를 여러분이 이끌려 하지 말고 요구사항이 이끌도록 하십시오. 여러분은 최선을 다해 그들의 필요를 섬겨야 합니다.

 

  • 팀에 집중하십시오. 팀은 자원이 아닙니다. 그들은 여러분의 설계 협력자이자 여러분의 안전망입니다. 진가를 인정받지 못하는 사람은 보잘 것 없는 안전망을 만듭니다. 아키텍처는 팀의 것이지 혼자만의 것이 아닙니다. 여러분은 가이드라인을 제공하고 모든 사람이 협력해 함께 이끄는 것이라는 마음가짐을 가져야 합니다.

 

  • 여러분의 업무를 점검하십시오. 모형은 아키텍처가 아닙니다. 이것은 아키텍처가 동작하는 방법에 대한 여러분의 이해일 뿐입니다. 프로젝트 아키텍처가 각 요구사항을 어떻게 지원하는지 검증하는 테스트 항목을 정하기 위해 여러분의 팀과 함께 일하십시오.

 

  • 여러분을 돌아보십시오. 자기의 일을 방어하고, 이기적인 관심에 집중하고, 우리 자신을 방 안에서 가장 영리한 사람으로 여기는 우리의 본능과 싸워야 합니다. 매일 몇 분 동안 여러분의 행동에 심사숙고해 보십시오. 여러분은 모든 사람의 아이디어에 그들이 마땅히 받아야 할 존경과 인정을 주었습니까? 여러분은 선의의 참여에 부정적으로 대하지는 않았습니까? 누군가가 여러분의 접근 방법에 왜 불응했는지 이해하기 위해 노력해 보신 적이 있습니까? 자기 자신을 되돌아 볼 필요가 있습니다.

 

손영수 저도 그렇게 생각합니다. 제가 소문으로 들었던 몇몇 아키텍트들은 많은 반대에도 불구하고 자신의 생각을 관철시키곤 했습니다. 설계 자체의 옳고 그름을 떠나 개발자들과 소통 없이 일방적으로 자신의 생각을 강요했죠. 그 결과로 설계 따로, 개발 따로 하는 프로젝트가 되었다는 이야기를 들었습니다. 개발자를 이해하는 아키텍트, 그리고 아키텍트를 이해하는 개발자들이 모여야 정말 좋은 프로젝트로 갈 수 있을 것입니다. 마음가짐에 대한 또 다른 의견도 듣고 싶습니다.

 

 

David Bartlett    아키텍트는 쇼맨십을 뛰어넘는 가치 있는 청지기 의식(Stewardship)을 가져야 합니다.

 

아키텍트들은 프로젝트에 착수할 때, 자신의 가치를 입증하려는 갈망이 있죠.

소프트웨어 회사에서 아키텍트 역할을 맡는다는 것은 아키텍트의 기술적 리더십을 회사의 일부분으로 절대 신뢰한다는 의미입니다.

 

그런데 불행히도 자신의 가치를 입증하기 위해 개인의 기술적 탁월함과 쇼맨십으로 팀원들을 이끌어야 한다고 오해하는 아키텍트들이 있습니다. 사람들에게 어필하는 행동인 쇼맨십은 마케팅에서는 중요할지도 모릅니다. 하지만 소프트웨어 개발 프로젝트에 있어서는 역효과를 나타낼 뿐입니다.

 

아키텍트는 확고한 리더십으로 그들 팀의 존경을 얻어야만 하고 기술과 팀이 운영하는 비즈니스 도메인의 이해가 있어야 합니다. 책임지고 다른 이들을 돌보는 청지기 의식은 아키텍트에게 꼭 필요한 자질입니다. 아키텍트는 고객을 위해 최선을 다해야 하지, 고객의 요구를 이용하려고 해서는 안 됩니다.

 

소프트웨어 아키텍처는 고객의 요구들을 수행하는 것으로, 보통 탁월한 능력을 소유한 도메인 전문가의 방향 제시로 이뤄집니다. 성공적인 소프트웨어 개발을 추구하는 것은 아키텍트가 프로젝트에 주어진 시간과 노력에 대비해 구현의 복잡성과 비용 사이에 균형이 잡힌 절충된 솔루션을 만들게 합니다.

 

최신의 따끈따끈한 프레임워크나 기술 전문 유행어로 이뤄진 과도하게 복잡한 시스템은 비용 지출의 희생을 담보로 합니다. 아키텍트의 활동은 투자 브로커처럼 합리적인 ROI(투자 대비 수익률)를 창출할 수 있다는 전제 하에 고객의 돈을 사용하도록 해야 합니다. 여러분이 다른 사람의 돈을 사용하고 있음을 절대 잊어버려서는 안 됩니다.

 

손영수 아키텍트 명함을 가지고 다니는 사람들 중에는 신기술로 도배된 제품을 팔기 위한 비즈니스맨인지, 아키텍트인지 구분하기 힘든 이들이 있습니다. 청지기 의식이라는 것을 통해 많은 것을 되돌아보게 되었습니다.

지금까지 여러분의 소중한 조언을 들을 수 있었습니다. 설계만 잘하기 위한 공학적인 기법만큼 외부와 소통 및 협상하고, 팀원들을 이끄는 정신도 중요하다는 것을 깨우치는 시간이 되었습니다. 이 가상 인터뷰가 아키텍트를 꿈꾸는 많은 이들에게 유용한 시작점이 되었으면 합니다.

 


저작자표시 비영리 동일조건

'모과이 > 경력관리진로' 카테고리의 다른 글

어떻게 공부할까? 프로그래머를 위한「공부론」  (0) 2011.09.11
프로그래머 경력 3년차, 이제 어디로 갈까?  (0) 2011.05.22
[TIP]프로그래머의 경력 관리는 어떻게?  (0) 2011.05.09
큐브 맞추기로 말하는 개발자 실력 향상 시나리오  (0) 2010.12.28
[IT직종] 30. 응용소프트웨어개발자(응용 프로그래머)  (0) 2010.12.09
Posted by 모과이IT
,

[IT직종] 30. 응용소프트웨어개발자(응용 프로그래머)

모과이/경력관리진로 2010. 12. 9. 16:15

30. 응용소프트웨어개발자(응용 프로그래머)

응용소프트웨어개발자는 각종 응용소프트웨어를 개발하는 프로그래머를 뜻한다.

응용소프트웨어개발자는 각종 응용소프트웨어를 개발하고 설계하는 사람을 뜻한다. 응용소프트웨어를 개발하는 과정은 곧 프로그램을 짜는 과정이므로 응용소프트웨어개발자는 프로그래머를 뜻한다. 일반적으로 특별한 조건 없이 프로그래머라고 말하면 응용소프트웨어를 개발하는 응용소프트웨어개발자를 뜻한다. 응용소프트웨어가 아닌 게임이나 모바일 프로그램을 개발할 경우에는 게임프로그래머 모바일프로그래머 등으로 좀더 세분화된 업무내용이 '프로그래머'라는 직업이름 앞에 붙는다.

과거에는 프로그래머의 영역이 컴퓨터로 한정되었기 때문에 프로그래머의 종류는 두 종류로 구분되었다. 시스템 관련 프로그램을 개발하는 시스템프로그래머와 응용 프로그램을 개발하는 응용프로그래머 두 종류로 크게 구분했다. 시스템 프로그램은 컴퓨터시스템에서 사용하는 프로그램으로 운영체제나 네트워크 프로그램, 각종 자료 입출력 프로그램과 같이 시스템을 움직이는데 필요한 기본적인 프로그램을 뜻한다. 응용프로그램은 시스템 프로그램 위에서 실행시키는 프로그램을 뜻하는데, 컴퓨터 사용자가 일반적으로 사용하는 프로그램이 여기에 속한다. 엑셀과 같은 표계산 프로그램, 한글 훈민정음 MS워드와 같은 글틀 프로그램, 포토샵 같은 그림 프로그램, 각종 게임 등이 응용프로그램에 속한다. 그러니까 우리가 흔히 사용하는 사무용, 교육용, 게임 프로그램이 응용프로그램에 속하고, 이런 프로그램을 개발하는 사람을 응용소프트웨어개발자라고 부르는 것이다. 보통 프로그래머라고 부르는 직종은 일반적으로 응용소프트웨어개발자를 가리킨다.

요즘은 응용소프트웨어의 분야가 넓기 때문에 게임을 개발하는 응용소프트웨어개발자는 게임프로그래머로 따로 분류하고, 모바일 관련 프로그래머는 모바일프로그래머로 따로 분류한다. 때문에 요즘 좁은 의미의 응용소프트웨어개발자는 주로 PC나 기업 전산망에서 사용하는 인사관리 회계관리와 같은 기업용 프로그램, 데이터베이스관리 프로그램, CAD 설비제어 등의 산업용 프로그램, 학습 교육 관련 프로그램 등을 개발하는 프로그래머를 가리킨다.

응용소프트웨어는 일반인에게 대량으로 판매하는 패키지 프로그램과 주문받아서 개발하는 주문 프로그램으로 나눌 수 있다. 엑셀, MS워드, 게임, 각종 교육용 CD롬타이틀은 패키지로 포장되어 판매되는 패키지 프로그램에 속한다. 반면 특정 기업의 업무에 최적화된 기업 인사관리, 회계관리 프로그램 등은 대부분 주문받아서 제작해주는 주문 프로그램이다. 어떤 프로그램을 개발하느냐에 따라서 프로그래머의 근무 환경이나 일하는 형태, 작업도구가 크게 달라진다. 주문 프로그램을 개발하는 프로그래머는 아무래도 촉박한 납기 시일 안에 프로그램을 완성시켜야 하므로 시간에 많이 쫓기고, 시간 대비 노동에 가까운 작업이므로 성장폭이 낮다. 대신 대기업이나 중견기업에 취업이 가능하므로 안정적인 생활이 가능하다. 물론 기업용 프로그램을 개발하는 프로그래머가 꼭 중소개발사에만 취업하는 것은 아니다. 대기업이나 중견기업, 공공기관의 전산실에 근무하면서 응용 프로그램을 개발하거나 전산 프로그램 개발을 맡는 경우도 많다.

패키지 프로그램을 개발하는 프로그래머는 여유도 있는 편이고, 개발한 상품이 성공했을 때 보상 효과도 큰 편이지만 대부분의 패키지 프로그램 개발회사가 영세한 편이라 보수나 근무 환경이 좋지 않다는 점이 단점이다. 따라서 안정성을 추구한다면 기업용 프로그램을 개발하는 기업이나 기관의 응용소프트웨어개발자로 취업하는 것이 좋다. 안정성보다는 모험을 추구한다면 패키지 프로그램 개발사에 취업해 독창적인 프로그램 개발에 몰두하기를 권한다.


스트레스가 심한만큼 성취욕도 강한 직종이다.

어떤 업무를 맡건 프로그램 개발 작업은 여러 명이 팀을 이루어 개발한다. 따라서 프로그램 개발 과정에 가장 어려운 부분은 팀원과 협력하는 일이다. 우선 자기 회사의 동료들과 호흡이 맞아야 한다. 이 과정에서 갈등을 일으킬 경우 일하기 매우 어렵다. 하청업체로 주문받아 개발하는 경우에는 프로그램 발주업체 직원과도 적절한 조화를 이루어야 하는데, 업무과정에서 호흡을 맞추기란 의외로 어렵다. 이 때문에 프로그래머가 가장 힘들어하는 부분은 사람관계가 된다.

개발자라는 업무 특성 때문에 작업 시간은 불규칙한 편이다. 개발 기간에 맞추다보면 며칠 밤을 지새는 일도 허다하다. 이 때문에 의외로 체력이 많이 요구된다. 그렇지만 '프로그래머 생활 1년이면 느는 것은 뱃살'이라는 말처럼, 하루 종일 책상에 앉아 컴퓨터와 씨름하는 프로그래머 직업의 특성 상 체력을 유지하며 건강을 챙기기는 쉽지 않다. 그래서 프로그래머가 되면 가장 신경 써야 할 부분이 자신의 건강을 챙기는 일이다.

일반적으로 응용소프트웨어개발자가 되기 위해서는 대학교에서 컴퓨터나 전산, 정보, 통신 관련 학과를 전공하면서 프로그래밍 기술을 배워 취업하는 것이 일반적이다. 하지만 프로그램 실력만 뛰어나다면 전공이나 학벌 불문하고 취업이 가능하다. 응용소프트웨어개발자 중에는 고졸 이하의 학력을 가진 사람도 12%가 넘는데, 학벌의 영향을 적게 받는 직종 중 하나다. 어느 정도의 학벌 부족은 프로그래밍 실력으로 충분히 뛰어넘을 수 있는 직종이다. 따라서 비전공자라도 책을 통한 독학이나 학원과정을 통해 프로그래밍 실력을 익힌 후에 프로그래머로 취업할 수 있다.

관련자격증으로는 정보관리기술사, 정보처리기사,정보처리산업기사, 정보처리기능사, 전자계산기조직응용기술사, 전자계산기조직응용기사, 전자계산기조직응용산업기사, 정보기술산업기사 등이 있지만 실질적으로 이런 자격증과 취업의 연관성은 매우 적다. 응용소프트웨어개발자로 취업할 때 가장 중요한 기준은 해당 언어에 대한 숙련도(실력)다.

응용소프트웨어개발자가 되려면 C/C++ 언어를 잘 하는 것이 가장 좋다. VC++, MFC와 같은 MS사 계열의 언어를 잘 해도 좋다. 자바를 배워도 응용소프트웨어개발자로 취업할 수 있지만 C++ 계열 언어에 비하면 경쟁력이 약하다. ASP와 같은 스크립트 언어를 배워서는 응용소프트웨어개발자로 취업하기 어렵다.

응용소프트웨어개발자의 절반 이상이 30인 이하의 소규모벤처기업에서 일하고 있다는 상황에서 알 수 있는 것처럼 응용소프트웨어개발자의 근무환경은 좋지 않으며 연봉도 높지 않다. 응용소프트웨어개발자는 평균 200만원 정도를 받고 있는데 신입이나 경력이 많지 않은 경우, 중소기업에서 일하는 경우에는 월 130만원 정도의 적은 급여를 받으며 일하고 있다. 대신 40대나 50대의 나이에도 응용소프트웨어개발자로 근무하는 사람이 꽤 될 정도로 수명이 긴 직종 중 하나다. 또한 IT의 기본이자 꽃이라는 프로그래밍 기술을 가지고 있기 때문에 다른 직종으로 이직하기에 가장 좋은 직종이기도 하다.

응용소프트웨어 분야는 IT 분야 중에서 아직까지 가장 많은 부분을 차지하는 부분이며 앞으로도 가장 높은 비중을 차지할 분야다. 따라서 일자리가 가장 풍부한 직종이며, 프로그래밍 실력만 갖춘다면 취업하기 가장 쉬운 직종이라 할 수 있다.

응용소프트웨어개발자는 개발과정에서 정신적 육체적으로 많은 스트레스를 받는다. 하지만 자신이 원하는 기능을 구현하고 자신이 개발한 것이 상품화되거나 사람들이 사용하는 것을 보면서 큰 성취감을 느낀다. 이런 성취감이 있기 때문에 응용소프트웨어개발자 즉, 프로그래머의 길을 가려는 사람들이 많은 것이다.

또한 응용소프트웨어개발자는 독창적인 프로그램을 개발해 세계적인 기업으로 키우겠다는 희망을 품을 수 있는 직종이다. 언젠가는 자신의 힘으로 멋진 응용프로그램을 만들어 회사를 성장시키겠다는 희망을 가질 수 있기에 힘이 들어도 프로그래머라는 직업은 도전해볼 가치가 큰 매력적인 직업이다.


저작자표시 비영리 동일조건

'모과이 > 경력관리진로' 카테고리의 다른 글

어떻게 공부할까? 프로그래머를 위한「공부론」  (0) 2011.09.11
프로그래머 경력 3년차, 이제 어디로 갈까?  (0) 2011.05.22
[TIP]프로그래머의 경력 관리는 어떻게?  (0) 2011.05.09
큐브 맞추기로 말하는 개발자 실력 향상 시나리오  (0) 2010.12.28
12명의 아키텍트에게 물어본 "아키텍트의 길!"  (0) 2010.12.09
Posted by 모과이IT
,

Microsoft MVP 되는 법..

모과이/MoGuWai's Mind 2010. 11. 8. 17:40
Microsoft MVP 공식 홈페이지 둘러보기

우석님의 이글루에서 MVP Summit 등록시에 받는 배지 라는 글을 읽고 생각이 나서 몇자 끄적끄적여 본다.. 자주 받게되는 질문에 대한 정리겸 해서..

작년에 이어 올해도 잘하면, Outstanding MVP에 선정되어 Microsoft MVP Summit에 항공료도 지원받으며 다녀올 수 있을 것도 같기는 한데 올해는 못가게 되어 난 등록을 하지 않았다.. 작년처럼 2월에 했으면 다녀왔을 텐데, 하필 4월에 하는 바람에 울 아가가 그때쯤 세상에 나오는지라 못가게 되었다.. 언제 태어날지 모르므로 5분대기조 해야 한다.. 흐흐..
빌게이츠 얼굴 보느라 울 아가 태어나는 모습을 못보게 될 수는 없지 않은가..

Microsoft MVP가 되면 각종 혜택을 많이 받는데, 가장 좋은 것은 일반인들은 얻기 힘든 Microsoft와 제품에 관한 정보들을 보다 빠르게 많이 얻을 수 있다는 점이다.. 물론, 다른 물질적인 혜택들도 많다.. MSDN 유니버설 1년 가입도 시켜주고 (MS의 모든 제품을 정품으로 죄다 사용할 수 있으니 쥑인다..), 그외의 제품들도 기념품 격으로 많이 준다.. (마우스, 키보드, 조이스틱, 게임패트, 무선 네트워크 베이스, 무선 랜카드, 시계, 볼펜, 가방, 옷 등등 현재 내 방은 온통 Microsoft 로고가 새겨진 것들로 가득하다..) 물론, 매년 본사에서 열리는 Summit에 참가해 MS 캠퍼스 구경도 하고 유명한 MS 직원들도 직접 보고 이야기 나눌 수 있는 것도 좋은 점 중에 하나다.. MS 제품의 소스코드도 일부 MVP들에게 공개되기도 한다..

그럼 이런 Microsoft의 MVP 자격을 얻는 방법은 여러가지가 있는데..
1. Microsoft 기술에 대한 지식과 경험이 탁월한 경우
2. Microsoft 기술에 관한 저서, 커뮤니티 운영 등의 업적이 탁월한 경우
3. Microsoft 커뮤니티에 대한 공헌이 탁월한 경우

나를 포함한 많은 사람들이 가장 쉽게 접근할 수 있는 방법이 3번이 아닌가 싶다.. Microsoft의 커뮤니티란 Microsoft Public Newsgroup을 말한다..

접속방법과 간단한 사용법은 여기를 참조하면 된다.. 사실 내가 이 커뮤니티에 탁월한 공헌을 했다기 보다는 난 내가 뭘 더 배웠다고 생각하는데, 아무튼 이런걸 보고 일석이조라고 하는게 아닐까.. 공부도 하고, MVP도 되고.. 헐헐..

자신이 아는 내용은 남을 위해 답변을 달아주고, 자신이 모르던 내용은 다른 사람의 답변을 통해 얻게되고, 내가 모르는 내용은 질문을 올리기도 하고, 이런 과정을 통해 비슷한 관심사를 가진 사람들과 친하게 되고..
그러다 잘하면 Microsoft MVP도 되고.. Microsoft 제품을 많이 사용하며, 유사한 업종에 종사중인 사람들은 Microsoft Public Newsgroup으로 오시라..

영문 뉴스그룹도 많지만 .kr 이 들어가는 한글 뉴스그룹도 무자게 많다.. 뉴스그룹 하면 영어에 대한 부담을 느낄 필요가 없으니 많은 사람들이 모여 의견을 나눠볼 수 있으면 좋겠다..
저작자표시 비영리 동일조건

'모과이 > MoGuWai's Mind' 카테고리의 다른 글

개발자에게 습관이란...  (0) 2017.10.03
공무원을 지망하는 사람 Vs 자기가 좋아하는 일을 하는 사람  (0) 2014.09.21
훌륭한 프로그래머란  (0) 2010.09.27
프로그래머가 언어를 대하는 자세  (0) 2010.09.27
개발자에게 가장 두려운 것  (0) 2010.09.27
Posted by 모과이IT
,

[니츠 프로젝트] AfxEnableControlContainer

모과이/프로젝트 2010. 11. 2. 16:02

http://msdn.microsoft.com/en-us/library/x1se4y1y(VS.80).aspx

Visual C++(exe,dll 등 포함) 에서 ocx 혹은 OLE 컨트롤을 사용할 경우엔

초기화하는 부분
VC++ 초기화 하는 함수 즉 InitInstance() 안에서
AfxEnableControlContainter() 함수를 호출해주어야지 정상적으로 
실행이된다. 이걸 해주지 않으면 널포인터 에러가 발생한다
 
저작자표시 비영리 동일조건

'모과이 > 프로젝트' 카테고리의 다른 글

AFX_EXT_CLASS를 사용하여 내보내기 및 가져오기  (0) 2011.07.21
[니츠프로젝트] 익스플로러9에서 폰트 초기화 되는 현상  (0) 2011.02.11
Posted by 모과이IT
,

훌륭한 프로그래머란

모과이/MoGuWai's Mind 2010. 9. 27. 11:09
PMP를 구입한 이후 너무 책 읽는 것에 소홀해져 나름대로 다시 한번 예전의 감각을 찾아보기 위해서 시간 날때마다 읽으려고 구입한 '패턴을 활용한 리펙터링'을 구입했다.

몇년째 관심을 가지고 있지만 과연 이것이 유용한 것인지 대답을 찾지 못했던 패턴이라는 주제와 언제나 실력의 벽에 부딛히도록 만드는 리펙터링이라는 주제를 함께 다룬 책이기에 제목만으로도 구입할 수 밖에 없도록 만들었다.

이 책의 45페이지에 보면 Martin Fowler가 한 말을 인용한 구문이 나온다.

컴퓨터가 이해하는 코드는 어느 바보나 다 짤 수 있다. 훌륭한 프로그래머는 사람이 이해할 수 있는 코드를 짠다.

이걸 읽는 순간 "두둥!"하고 머릿속에서 울리는 느낌이 들었다.
코드를 보면서 문맥을 놓치게 만들거나 "왜?"라는 의문이 들게하는 코드가 생기게 하는 것은 보는 사람의 실력이 떨어져서가 아니라 만든 사람의 실력이 부족하기 때문이다.

어떤 프로그래머가 보든지 한눈에 쭉 읽어가며 "대단해~"이라는 찬사를 보낼 수 있도록 만드는 코드를 만드는 것이 진정한 실력.

난 아직도 너무나 부족하다.
저작자표시 비영리 동일조건

'모과이 > MoGuWai's Mind' 카테고리의 다른 글

개발자에게 습관이란...  (0) 2017.10.03
공무원을 지망하는 사람 Vs 자기가 좋아하는 일을 하는 사람  (0) 2014.09.21
Microsoft MVP 되는 법..  (0) 2010.11.08
프로그래머가 언어를 대하는 자세  (0) 2010.09.27
개발자에게 가장 두려운 것  (0) 2010.09.27
Posted by 모과이IT
,

프로그래머가 언어를 대하는 자세

모과이/MoGuWai's Mind 2010. 9. 27. 11:06
'프로그래머로 회사에 입사하면 하는 업무는?' 당연히 프로그래밍이다.
하지만 프로그래밍만 하는 것은 아니다. 기안서도 작성해야 하고 지출결의서도 작성해야 하며 마음에 드는 책을 구입하려면 책 구매 신청서도 내야 하고 휴가라도 가고 싶다면 휴가원을 제출해야 한다. (휴가원 제출하기 귀찮아서 2년간 휴가 한번 쓰지 않은 나같은 인간도 물론 있겠지만 회사를 다니며 이런 서류 한번 제출하지 않고 다니기는 쉽지 않다.)

프로그래밍을 아무리 잘 한다고 해도 서류 한번 잘 못 결재 올렸다간 욕먹기 쉽상이고 아무리 똑똑한 사람일지라도 경영팀에게는 멍청하고 부주의한 사람으로 찍혀버리는 것도 순식간이 되어버린다. 심하면 사회 부적응자라는 평가를 받기도 한다. (노파심에 이야기하자면 절대 지금 다니고 있는 회사가 그렇다는 말은 아니다.)

그러므로 멋진 회사원으로 사람들에게 좋은 이미지를 심어주기 위해서는 자기 일 뿐만 아니라 서류 작성도 잘 해야 하고 회의때 자신의 의견을 조리있게 이야기할 수 있어야 하며 아이디어를 그럴듯하게 보여지는 문서로 만들어내는 능력도 필요하고 격식에 맞는 이메일을 작성할 정도의 예의도 갖추고 있어야 한다.

다행스러운 것은 프로그래밍을 할 수 있는 것 만큼의 능력을 요구하는 것은 아니기에 남들 하는 만큼만 해도 충분히 인정을 받을 수 있다는 점이다.

프로그래밍의 영역만 따져 들어가보면 역시 마찬가지이다.
C++만 할 줄 안다면 그것으로 충분할까? 최근의 경향은 난 다른 언어는 전혀 쓸 줄 몰라요 라는 말로 버티기가 쉽지 않다. 자신이 잘 하는 언어 한가지 이외에 데이터베이스도 다룰 줄 알고 자바 스크립트정도는 보고 이해할 수 있어야 하며 Lua나 Ruby와 같은 스크립트 언어 한가지를 필요에 따라 쓸 수 있고 인스톨패키지를 만들 수 있도록 NSIS나 인스톨쉴드정도는 필요하다면 쓸 수 있을 정도가 되어야 한다.

그렇다고 만능 프로그래머가 되어야 한다는 이야기는 아니다.
잘하는 언어 한가지. 그 한가지를 갖춘 상황에서 다른 언어에 관심을 외면해선 안된다는게 프로그래머로써의 내 생각이다. 다행스러운 것은 한가지 언어에 대해서 어느 정도 알고 있다면 다른 언어를 익히는데 그렇게 어렵지는 않다는 점이다.

너무 잡다하게 많은 언어를 하는 것은 물론 도움이 되지 않는다. 하지만 다른 언어를 익히는 것에 경시하는 것은 좋은 자세가 아니라고 생각한다. 지금 당장 프로그래머로서 뭘 해야 할지 막막하고 무엇을 해야 할지 모르겠다면 다른 언어를 익혀보자. 분명 스스로 발전할 수 있는 도화선이 되어줄 것이다.

저작자표시 비영리 동일조건

'모과이 > MoGuWai's Mind' 카테고리의 다른 글

개발자에게 습관이란...  (0) 2017.10.03
공무원을 지망하는 사람 Vs 자기가 좋아하는 일을 하는 사람  (0) 2014.09.21
Microsoft MVP 되는 법..  (0) 2010.11.08
훌륭한 프로그래머란  (0) 2010.09.27
개발자에게 가장 두려운 것  (0) 2010.09.27
Posted by 모과이IT
,

티스토리툴바