천객만래 [千客萬來] (It has an interminable succession of visitors)

201가지 소프트웨어 개발원칙



201가지 소프트웨어 개발원칙


일반원칙
1. 품질이 제일이다.
2. 품질의 정의는 보는 사람에 따라 다르다,
3. 생산성과 품질은 불가분의 관계이다.
4. 고품질의 소프트웨어를 개발할 수 있다.
5. 사후에 품질을 만들어 넣으려 하지 말라.
6. 성능보다 신뢰성이 더 중요하다.
7. 시제품을 고객에게 빨리 보여준다.
8. 고객이나 사용자와 충분히 협의한다.
9. 개발자와 고객에게 적합한 보상기준을 마련한다.
10. 처음 시도하는 것은 폐기할 작정으로 개발한다.
11. 적절한 유형의 시제품을 개발한다.
12. 적절한 기능을 시제품화 한다.
13. 일회용 시제품은 빨리 개발한다.
14. 시스템을 점증적으로 개발한다.
15. 보면 볼수록 더 많은 것을 원한다.
16. 개발중의 변경은 피할 수 없다.
17. 가능하면 개발하기 보다는 구매한다.
18. 사용자 매뉴얼이 간단하게 되도록 소프트웨어를 개발한다.
19. 아무리 복잡한 문제라도 해결책은 있다.
20. 가정한 것이 있으면 이를 기록한다.
21. 다른 단계에는 다른 언어를 사용한다.
22. 도구를 사용하기 전에 기법을 배운다.
23. 도구는 현실적으로 사용한다.
24. 소프트웨어 도구는 우수한 개발자에게만 제공한다.
25. CASE도구는 고가이다.
26. "Know-How"만큼 "Know-When"도 중요하다.
27. 목적을 달성하면 중단한다.
28. 정형적 방법을 알아야 한다.
29. 조직의 평판을 중시한다.
30. 대세를 따를 때는 주의해야 한다.
31. 기술을 무시하면 안된다.
32. 문서 표준을 사용한다.
33. 모든 문서에는 용어정의를 한다.
34. 모든 문서에는 색인을 부여한다.
35. 같은 개념에는 같은 명칭을 사용한다.
36. 연구결과의 기술이전은 즉시 되지 않는다.
37. 책임을 질 줄 알아야 한다.

요구공학 원칙
38. 요구사항이 불명확할수록 비용예측은 어렵다.
39. 요구사항을 기록하기 전에 문제를 확실하게 결정한다.
40. 지금 요구사항을 결정한다.
41. 요구명세상의 오류는 즉시 수정해야 한다.
42. 시제품으로 사용자 인터페이스 선정의 위험을 줄인다.
43. 요구사항 항목의 선정근거를 기록한다.
44. 최소 요구사항을 식별한다.
45. 요구사항을 검토한다.
46. 요구분석단계에서 설계하지 않는다.
47. 올바른 기법을 사용한다.
48. 여러 관점으로 요구사항을 분석한다.
49. 요구사항을 현명하게 조직화한다.
50. 요구사항의 우선순위를 정한다.
51. 간결하게 기록한다.
52. 모든 요구사항에 유일한 식별번호를 부여한다.
53. 요구사항의 모호성을 줄인다.
54. 자연어는 정형모델로 보완만 하고 대체하지는 말라.
55. 먼저 자연어로 기록하고 정형모델을 작성하라.
56. 요구명세서는 읽기 쉬워야 한다.
57. 신뢰성에 대하여 구체적으로 명시한다.
58. "수용 불가능한" 환경조건을 명시한다.
59. 미결정항목은 각주와 함께 작성한다.
60. 요구명세서를 데이터베이스에 저장한다.

설계 원칙
61. 요구사항에서 설계로의 전환은 어렵다.
62. 설계산출물에서 요구사항을 추적한다.
63. 대안을 평가한다.
64. 문서가 없는 설계는 설계가 아니다.
65. 캡슐화 한다.
66. 가능하면 재사용한다.
67. 단순하게 개발한다.
68. 특수한 경우를 많이 만들지 않는다.
69. 지적인 거리를 최소화 한다.
70. 설계를 지적 통제하에 둔다.
71. 개념적 무결성을 유지한다.
72. 개념적 오류는 문법적 오류보다 심각하다.
73. 결합도는 낮추고 응집도는 높인다.
74. 변경이 쉽게 설계한다.
75. 유지보수를 고려하여 설계한다.
76. 오류수정이 쉽게 설계한다.
77. 일반성을 띄게 소프트웨어를 개발한다.
78. 유연성 있게 소프트웨어를 개발한다.
79. 효율적인 알고리즘을 사용한다.
80. 사용자가 필요로 하는 모든 정보는 모듈명세서에 있다.
81. 설계는 다차원적이다.
82. 뛰어난 설계는 뛰어난 설계자가 한다.
83. 어플리케이션에 대해서 숙지한다.
84. 큰 투자 없이도 재사용할 수 있다.
85. 무효한 값을 입력하면 적절한 오류 메세지를 출력하도록 한다.
86. 소프트웨어 신뢰성은 중복성을 통해 얻을 수 있다.

코딩원칙
87. 트릭을 사용하지 않는다.
88. 광역변수를 사용하지 않는다.
89. 하향식으로 읽을 수 있도록 작성한다.
90. 부작용을 제거한다.
91. 의미 있는 명칭을 사용한다.
92. 사람을 위한 프로그램을 작성한다.
93. 최적의 자료구조를 사용한다.
94. 빨리 하기 보다는 올바르게 한다.
95. 코드를 완성하기 전에 주석을 작성한다.
96. 코딩을 시작하기 전에 문서화한다.
97. 모든 구성요소를 책상 위에서 실행시켜 본다.
98. 코드 검사를 실시한다.
99. 비구조적 언어도 사용할 수 있다.
100. 구조화된 코드가 반드시 좋은 코드는 아니다.
101. 너무 깊이 중첩 시키지 않는다.
102. 적절한 언어를 사용한다.
103. 프로그래밍 언어를 핑계 삼아서는 안된다.
104. 언어에 대한 지식은 중요하지 않다.
105. 프로그램의 체계를 정비한다.
106. 코딩을 너무 빨리 시작하지 말아라.

시험원칙
107. 시험에서 요구사항을 추적한다.
108. 시험하기 훨씬 이전에 시험을 계획한다.
109. 자신이 개발한 소프트웨어를 자신이 시험하지 않는다.
110. 자신이 개발한 소프트웨어의 시험계획은 남이 세운다.
111. 시험은 결함을 드러나게 할 뿐이다.
112. 오류의 많고 적음과 소프트웨어의 가치는 무관하다.
113. 오류를 찾아야 성공적인 시험이다.
114. 15% 모듈에서 50%의 오류가 발견된다.
115. 블랙박스시험과 화이트박스시험을 실시한다.
116. 시험사례에는 예상결과를 포함시킨다.
117. 무효한 값으로 시험한다.
118. 항상 스트레스 시험을 한다.
119. 빅뱅설을 적용하면 안된다.
120. McCabe의 복잡도 척도를 사용한다.
121. 효과적인 시험종료 척도를 사용한다.
122. 시험 적용범위를 효과적으로 활용한다.
123. 단위시험이 끝나기 전에 통합하지 않는다.
124. 소프트웨어에 특정한 시험용 코드를 내장시킨다.
125. 오류의 원인을 분석한다.
126. 오류를 개인적인 차원으로 생각하지 않는다.

관리원칙
127. 뛰어난 관리는 뛰어난 기술보다 중요하다.
128. 적절한 해결책을 이용한다.
129. 읽은 것을 모두 믿지 않는다.
130. 고객의 우선순위를 알아야 한다.
131. 사람이 성공의 열쇠이다.
132. 많은 사람보다는 소수정예요원이 더 낫다.
133. 부하 직원의 말을 경청한다.
134. 부하 직원을 신뢰해야 한다.
135. 항상 기대치를 높이 가진다.
136. 능숙한 의사소통 기술은 필수적이다.
137. 진심으로 부하직원을 위해준다.
138. 사람은 의외의 것으로 동기부여 받는다.
139. 사무실 분위기를 조용히 유지한다.
140. 인력과 시간은 대체할 수 없다.
141. 소프트웨어 개발자의 능력차이는 크다.
142. 원하는 목표로 최적화 할 수 있다.
143. 자료수집을 강요하면 안된다.
144. 코드 1줄 당 비용은 무시한다.
145. 완벽한 생산성 측정방법은 없다.
146. 비용산정 모델을 조정한다.
147. 일정은 현실적으로 계획한다.
148. 불가능한 것은 피한다.
149. 측정하기 전에 무엇을 측정할 지 알아야 한다.
150. 생산성 자료를 수집한다.
151. 팀의 생산성을 잊지 않는다.
152. 인월 당 행수(LOC/PM)은 언어와 관계없다.
153. 일정을 믿는다.
154. 정확하게 산정한 비용견적이라도 완전히 맞지는 않는다.
155. 일정을 정기적으로 재조정한다.
156. 약간 적은 견적을 항상 나쁘다고 할 수는 없다.
157. 자원을 적절히 할당한다.
158. 프로젝트를 치밀하게 계획한다.
159. 계획을 최신 버전으로 유지한다.
160. 잦은 계획변경의 파급효과에 주의한다.
161. 최상위 10개의 위험항목을 알아야 한다.
162. 직면한 위험을 이해한다.
163. 적절한 프로세스 모델을 사용한다.
164. 방법론이 당신을 구해주지는 못한다.
165. 기적적인 생산성 향상 비법은 없다.
166. 진척도의 의미를 정확히 알아야 한다.
167. 계획과의 차이만 관리한다.
168. 하드웨어에 과중한 부하를 주지 않는다.
169. 하드웨어의 발전에는 낙천적으로 대응한다.
170. 소프트웨어의 발전에는 비관적으로 대응한다.
171. 예상치 못한 사고로 인해 대혼란이 자주 초래된다.
172. 프로젝트의 사후 검토회를 실시한다.

제품보증 원칙
173. 제품보증 수준은 프로젝트에 맞게 조정한다.
174. 형상관리 절차를 조기에 확립한다.
175. 소프트웨어 프로세스에 SCM을 적용한다.
176. SCM은 프로젝트 관리에 독립적으로 조직화한다.
177. 개발과 제품보증업무 사이를 순환보직화 한다.
178. 모든 중간산출물에 명칭과 버전 번호를 부여한다.
179. 기준선을 통제한다.
180. 모든 것을 보존한다.
181. 모든 변경을 계속 추적한다.
182. 변경관리를 해야 한다.
183. 변경요청에 우선순위를 부여하고 일정계획을 세운다.
184. 대규모 개발에는 검증과 확인(V&V)을 적용한다.

진화원칙
185. 소프트웨어는 계속 변화한다.
186. 소프트웨어의 엔트로피는 증가한다.
187. 고장나지 않았으면 고치지 않는다.
188. 증상이 아닌 근본적인 문제를 수정한다.
189. 요구사항을 먼저 변경한다.
190. 릴리즈 전의 오류는 릴리즈 후의 오류의 원인이 된다.
191. 프로그램은 오래되면 될수록 유지보수하기 어려워진다.
192. 언어는 유지보수성에 영향을 미친다.
193. 때로는 처음부터 수정하는 방법이 좋다.
194. 최악의 구성요소는 처음부터 다시 개발한다.
195. 유지보수는 개발보다 많은 오류를 발생시킨다.
196. 변경한 후에는 반드시 회기 시험을 실시한다.
197. 변경사항이 간단하다고 방심하면 잘못 변경하게 된다.
198. 비구조적인 코드는 구조화해도 개선되지 않는다.
199. 최적화하기 전에 프로파일러를 사용한다.
200. 시스템에 친밀감을 갖는다.
201. 시스템은 환경변화에 따라 계속 변화한다.


출처 : '201가지 소프트웨어 개발원칙' 목차


Posted by SB패밀리

[연봉통계] 2007년3월 디자인,CAD분야

출처: jobkorea.co.kr








Posted by SB패밀리

[연봉통계] 2007년3월 소프트웨어,솔루션,ASP분야 직급별

jobkorea.co.kr










Posted by SB패밀리

[연봉통계] 2007년3월 소프트웨어,솔루션,ASP분야

출처 : jobkorea.co.kr


경력년차별 연봉차이...








Posted by SB패밀리



대한민국 개발자의 우울, 자기책임론에서 구조개혁론으로




김국현(IT평론가)   2007/10/01

 

2007년 우리네 개발자의 자화상은 유난히 수척하고 우울하다. 연이어 터져 나오는 개발자 처우에 대한 보도와 칼럼들은 IT를 이공계 기피의 공식 상징으로 만들어 버렸다. 이런…… 별로 낭만적이지 않다. 

어느덧 개발자의 후생(厚生)은 나의 최우선 관심사가 되어 버렸다. 

우리는 누구나 자기가 좋아하는 일을 하는 삶을 꿈꾸고, 또 그 일이 사회에 가져다 주는 가치에 걸맞은 대가를 받기를 바란다. 낭만적 인생의 얼개란 의외로 단순하다. 그렇다면 개발자들은 적어도 자기가 좋아하는 일이 무언지 안다는 면에서는 행복한 이들이다. '알고리즘의 오르가즘', 즉 내 논리가 증명될 때의 기쁨에 끌려 이 바닥에 들어 왔기 때문이다. 허나 이 '손맛' 누구나 맛볼 수는 있지만, 그 대가는 천차만별이다. 스톡옵션과 인센티브 덕에 벤츠를 모는 프로그래머도 있지만, 그 동갑내기는 소위 말하는 SI 막장의 트러블 프로젝트 속에서 요구분석조차 제대로 되지 않은 시스템을 무한 반복적으로 수정하고 있기도 하다. 전자는 한 사람의 개발자가 세상을 흔들 가치의 원천임을 증명한 셈이지만, 동시에 후자는 정부가 정한 단가표로 조달 가능한 부품에 불과함을 증명하고 있다. 

이 차이의 원인은 어디에 있을까? 운이라고 말하면 성의 없는 대답이지만, 노력 탓이라고 말하는 것도 잔인한 기만이다. 지금 개발자들이 겪는 우울은 이 격차에 대한 울분이라기보다, 후자에서 전자로 이어지는 연속된 흐름이 발견되지 않는 구조적 모순에 있다. 닮고 싶은 롤모델도 없고, 괴로운 나날을 지킬 비전도 없다. 그도 그럴 만 하다. 안타깝게도 우리 주위에는 기술의 힘에 의해 기업의 지속 가능성(Sustainability)를 확보한 곳은 찾기 힘들다. 대신 기묘한 다단계의 착취 구조의 잉여 축적으로 지속 가능성을 근근이 유지하는 곳만 즐비하다. 가치를 발휘할 대상을 찾지 못하는 이들이 가치를 발휘할 리 없다. 악순환이다. 그렇기에 대부분의 경우 자기책임론은 무책임한 말이다.

어떻게 하면 좋을까? 가치를 둘러싼 사회의 문제란 결국 경제적 문제다. 그리고 경제적 부조리의 대부분은 수요와 공급의 구조 변화에서 온다. 우리는 이 구조를 간과해 왔다. 이를 알아차린 혹자는 의사나 변호사처럼 이익을 대변할 길드를 형성해야 한다고 말하고, 또 다른 이는 구조적 문제를 해소할 '당'을 만들어야 한다고 농담 같은 진담을 해 오기도 한다. 공급자의 입장에서 공급을 조절하는 구조를 꿈꾸는 기초적 반항심이다. 

그러나 이는 더 본질적 문제를 간과하고 있다. 그 것은 '업', 즉 프랙티스(practice)라는 개념이 완성되는 과정이다. 의사도 변호사도 모두 구조적 절차, 예컨대 선별 과정과 자성 절차를 통해 자신들의 업을 정의하게끔 하고 그 정의에 맞는 수행을 하도록 스스로를 단련하고 있다. 이 것이 구조의 힘이다. 

우리는 스스로를 개발자라고 말하지만, 이는 그냥 운동선수라고 말해 버리는 것과 마찬가지의 뭉툭한 묶음이다. IT라는 산업 역시 산업으로서의 스포츠 전체와 같아서, 어떠한 종목을 선택할지에 따라 이 산업에 참여한 신인의 미래는 크게 달라진다. 인기, 비인기 여부, 그리고 프로 리그의 존재 여부, 여기에 자신의 적성 및 특기, 비전이 더해져서 스포츠인으로서의 인생은 구조 안에서 만들어 지는 것이다. 

이 적응과 선택이 합리적이고 타당한 분기점과 분배구조를 통해 거쳐 가면서 누구는 맨유의 일원으로 또 누구는 마포구 조기축구회의 일원으로 각각 나름의 땀을 흘리게 된다. 이 것이 성숙된 구조를 지닌 산업의 일원에게 주어진 낭만성이다. 가장 인간적이며 원초적인 파이팅 정신을 스포츠에서 찾게 되는 이유는 어쩌면 이 절차적 투명성 덕일지 모른다. 스포츠는 이를 가능하게 하는 구조를 완성했다. 고대 그리스 시절부터. 

우리네 IT에게 결여된 것은 이러한 구조다. 우리는 왜 훌륭한 선수가 되지 못하냐는 질책은 있었지만, 어떠한 종목을 선택하는 것이 바람직한지 귀띔을 듣지 못했다. 그런 일을 태릉선수촌을 만든 정부에 기대해 보면 좋겠지만, IT에게 주어진 정책은 축구가 인기니까 6개월 과정으로 축구 선수를 배출하자는 근시안적인 방책뿐이었다. 그 덕에 98년에 엔터프라이즈 자바를 처음 하던 시절에 받던 '선생님' 대우가, 불과 10년도 안돼 단순 노무직의 신세가 되어 버린다. 더 아이러니한 것은 10년 동안 아무리 훌륭한 축구 스킬을 쌓았어도 이를 알아 주는 이는 없고, 넘치는 축구 선수 지망생 속에 스트라이커는 묻혀 버린다. 오늘 아침 조기축구회에 처음 나온 이도 박지성도 모두 똑같은 과기처 단가표를 받아 든다. 그나마 다행히 박지성은 특급일 것이다. 

더 큰 문제는 야구 선수마저 축구를 해야 하는 상황이다. 유난히 획일적인 사회 덕인지 모르지만, 어느 한 기술이 선택되면 업계 전체에 그 쏠림 현상은 무지막지하고, 여기에는 일종의 종교적 교조주의까지 가세한다. 눈치 보듯 동종 업계의 흐름을 뛰어 넘지 않는 RFP로 발주가 나고, 어느 누구도 새로운 것을 시도하지 않은 채 그저 그런 시스템이 계속 완성된다. 그리고 IT는 점점 새로운 것을 기피하며 혁신과 거리가 멀어진다. 

개발자의 생산성을 비약적으로 향상시킬 방안이 있어도, 그 기술을 쓰는 개발자의 단가가 비싸다는 이유로 기각되곤 한다. 이는 혁신의 상실일뿐더러 기회의 상실이다. ‘보이지 않는 손’의 위업이라 해버리면 그만이지만, 정책이란 이러한 상실을 지키기 위한 것 아니었던가. 

어쩌면 국가나 정부의 정책이 밸런스를 맞추는 일은 애초에 무리일지 모른다. IT에서 일어나는 대부분의 변화는 정책 수행이나 입안 주체가 지닌 능력이나 태도의 문제나 차원을 넘어 초국가적 IT 트렌드의 결과이기 때문이니까. 그러나 아무리 글로벌화로 평평한 세계가 되어도 여전히 국가의 경계가 주는 문화적 경제적 사회적 기회의 차이는 지대하기에, 지렛대가 되어야 할 정책의 몫은 여전하다. 한 국가의 스포츠 정책이 생활 체육보다 엘리트 체육에 치중하는 이유도 이 차이의 가시적 해소를 위함이다. 왜 오프쇼어가 존재하는지, 왜 전세계의 IT 시스템이 여전히 미국발 플랫폼에 의존하고 있는지를 기억해 보자. 아무리 세계가 평평해져도 물리적 IT강국과 그 가치의 흐름은 존재한다. 

한국 내에도 IT에 특화된 수많은 공공 단체들이 있지만 이에 대한 심도 깊은 고찰이 어디에서 이루어지고 있는 지 궁금하다. 예컨대 국가가 나서서 오픈소스를 이야기하지만, 오픈소스가 국내 개발자의 전체적 후생에 어떠한 영향을 미치는지 설명책임이 없다. 정책자 들은 오픈소스가 우리의 미래라고는 하지만, 우리에게는 아직 북구나 북미에서처럼 오픈소스 커미터로 활동하는 일에 대한 직업적 환경이 형성되지 못했다. 글로벌 벤더가 북구나 북미에서처럼 이들을 한국에서 고용하지도 않고, 또 그렇지 않더라도 돈을 받지 않고 연구에 몰두할 수 있는 사회적 안전망을 국가나 학계가 갖추어 주지 않는다. ‘스캔디나비안 객체 지향 학풍’, '핀란드의 기나긴 겨울'과 같은 은유적 여유조차 없는 우리에게 오픈소스는 '소프트웨어는 거저'라는 잘못된 인식의 획득뿐이고, 그 결과 세계에 기여는 안 하면서 가져다 쓰기만 하는 기형적 오픈소스 문화만 남게 되었다. 구조적 문제의 일례다. 

도대체 무엇이 우리의 미래인가? IT 강국이라고 공염불은 하지만 그 실체는 없고, 참여자는 좌절하고 있다. 좋아서 시작은 했지만, 어떻게 하면 가치를 발휘할 수 있는지 알려 주지 않는다. 축구 선수는 늘어났지만 클럽이 없다. 운이 좋아 프로 축구단에 소속되면 다행이지만, 일부 개인에게 돌아간 이 요행을 산업 전체에 바랄 수는 없다. 그렇다면 야구가 있음을 알려야 한다. 올림픽을 열어야 한다. 세계 선수권에 나가야 한다. 새로운 종목에 도전해야 한다. 여자 양궁을 찾아야 한다. 쇼트 트랙을 찾아내야만 한다. 

업계에 참여하는 개개인 모두가 IT의 미래를 날카롭게 읽어 내어 그 길을 내달리고 또 시장까지 열어 줄 수 있는 성과물을 만들어 주기를 바란다면 이는 욕심이다. 우리는 지금껏 그 욕심 속에서 자책해 왔다. 개인이 내달릴 수 있는 구조가 없는 곳에서, 개인이 움직여 주지 않는다 해봐야 아무 일도 일어나지 않는다. 

다행히 구조의 왜곡을 먼저 읽어 내는 이들은 분명 존재한다. 그들은 기업인일수도, 마케터일수도, 에반젤리스트일수도, 블로거일수도, 정책가일수도, 혹은 이 글을 읽는 여러분 일수도 있다. 이 업계의 이 사회의 구조를 바꾸는 일, 우리의 몫이다. 구조 개혁은 어쩌면 길을 먼저 읽어 낸 이들의 책임이다. 미래란 그들이 뜯어 고칠 이 구조의 결과인 것이다. 개인은 구조의 영향을 받지만, 그 구조를 만드는 것은 개인이라는 사실. 이 것이 우리가 지닌 가장 큰 희망이기도 하다. @
 


Posted by SB패밀리

[개발/컬럼] 소프트웨어는 누가 개발해야 하는가?


소프트웨어는 누가 개발해야 하는가?

김국현(IT평론가)   2006/07/27  
     



소프트웨어는 누가 개발해야 하는가? 세상에 이런 우문이 어디 있느냐 생각할지도 모르겠다. 그리고 '개발자'라 짧게 대답할 것이다. 개발자라는 세 글자에는 외부에서 고용된, 그마저도 몇 단계의 하청을 거쳐, SI 업의 하류 공정을 묵묵히 맡고 있는 젊은이의 초상이 투영된다. 

정말 소프트웨어는 그들만의 몫일까? 일견 당연해 보이는 이 상식을 이제는 벗어 버려야 할 때다. 소프트웨어란 '갑'이, 그 중에서도 '현업'이 개발해야 하는 것이다. '을'이 개발하고 ‘갑’은 검수를 하는 현재의 안이한 세태로는 기업이 지녀야 할 속도와 유연성은 참 갖추기 힘든 일이다.

요즈음, 기업의 IT 시스템을 짓는 일을 기업의 사옥을 짓는 일에 섣불리 비유하는 일이 위험해지고 있다 생각하게 되었다. 오늘날의 세태를 생각해 보면 사옥을 지으라 시켜 놓고, 팔짱 끼고 있는 발주자의 모습만이 떠오르기 때문이다. 무언가를 만드는 일의 설렘을 총체적으로 잊어 가는 사회 속에서 주인님이 함께 손에 흙을 묻힐 리가 없는 일이다. 

건축이란 적어도 100년, 길게는 세기를 넘긴 미래를 만드는 일이다. 그렇기에 장인의 정성, 즉 고용된 프로페셔널 만으로도 가능한 일이다. 한번 타오른 열정, 100년은 갈 수 있으니 아깝지 않다. 그렇지만 기업의 IT는 오늘을 만드는 일이다. 내일의 비즈니스를 위한 오늘을 매일 매일 만들어야 하는 일인 것이다. 이 사실을 잊을 때 시스템에 우환이 찾아 든다. 기업이 맞닥뜨리게 될 변화의 힘과 속도는 팔짱 낀 방관자적 IT를 두고 볼 정도의 여유가 없다. 

시스템을 1년에 걸쳐 치밀히 구축해 봤자, 남는 것은 그 시간 동안 변해 버린 환경과 이를 고려하지 않은 시스템뿐이다. 우리는 이러한 풍경을 수도 없이 목격한다. 새 집을 지어 줬다고 생각했지만, 정작 사용자는 낡고 쓸모 없다 구박한다. 현장의 사용자, 즉 현업이 원하는 그들 마음에 쏙 드는 시스템은 영원히 만들어지지 않는다. 이를 회피하기라도 하듯 현업의 요구는 억제되고, 비즈니스의 혁신은 프로젝트 일정에 의해 묵살된다. 누구를 위한 것인지 알 수 없는 개발 프로젝트는 종료를 향해 앞으로만 내달려 간다. 

SI에서 일어나는 관습적 악순환이다. 파견직 개발자들은 자신이 쓸 프로그램이 아니므로, 자신이 유지 보수할 프로그램이 아니므로 정성껏 만들지 않는다. '남'을 위해 짜주는 코드와 '나'를 위해 짠 코드의 질이 같을 리가 없다. 개인이나 집단의 태도나 자질의 문제가 아니다. 인간 본성이다. 훌륭한 프로그램은 남의 집에서 만들어지지 않는 것이다. 

미래를 살아 남을 기업은 지금과 같은 태평한 시스템 구축을 견디지 못할 것이다. 그들은 혁신을 위해 더 많은 요구를 할 것이고 그 요구가 받아들이지 못하면 다른 길을 찾을 것이다. 

미래 기업은 ① 이상계, 즉 인터넷 서비스 기업이 정성껏 만들어 준 온라인 소프트웨어를 사용하거나, ② 현실계에서 현업 사용자 스스로 직접 소프트웨어를 개발할 것이다. 

①은 현재 진행형이다. 온라인 너머로 기업 시스템을 옮기는 SaaS(Software as a Service)라는 행위가 벌어지고 있다. 세일즈포스닷컴(salesforce.com)은 대표적 사례다. 어설프게 개발한 시스템, 어설프게 운영되는 전산실보다 아예 경험 많은 이상계 기업에게 자신의 정보를 업로드해도 괜찮을 것 같다는 정서가 본격적으로 도래할지 모른다. 마치 개인들이 자신의 이메일을 포털에 맡기는 것처럼. 

②는 허황된 소리로 들릴지 모르겠다. 비즈니스 수행에 바쁜 기업의 직원들이 언제 프로그래밍 공부하겠냐 할 것이다. 그러나 미래 기업에게는 많은 옵션이 생길 것이다. BPMN(Business Process Modeling Notation)이라는 비전문가도 알 수 있는 단순 조작으로 모듈화된 서비스를 재조합하여 늘 새로운 시스템을 만들자는 SOA의 철학은 엔드 유저 컴퓨팅(EUC)이라는 이루지 못한 꿈을 다시 꾼다. 마치 위키를 쓰듯, 기업 시스템을 현업이 스스로 '매시업(mash-up)'해 주무르는 IBM의 QEDWiki는 ‘사용자가 직접 개발’하는 웹 2.0적 '참여의 아키텍처'를 꿈꾼다. 마이크로소프트 오피스 차기 버전에 새롭게 등장한 Excel Services는 엑셀로 서버 프로그래밍을 가능하게 한다. 회계사 겸 서버 프로그래머, 서버 프로그래밍을 할 줄 아는 보험 업무 담당자가 대거 등장할 것이다.

일을 하다가 필요한 부분은 현업이 직접 만들어 쓰는, 그 정도까지는 아니라도 혁신을 위한 변경은 스스로 수행하는 회사에 어떤 기업이 당할 수 있을까? 전산실에 의뢰하고, 전산실은 외부 발주하여 6개월 뒤에나 오픈할 수 있는 기업과, 오늘 판단하여 내일 바뀔 수 있는 기업 중 누가 승리에 가까이 있을까?

처음에만 외주 개발을 하고 유지 보수를 포함한 2차 개발을 스스로 해결하려는 기업이 생겨나고 있다. 이미 실력 있는 개발자를 '전문 위원'이라고 계약 고용을 하고 있는 기업들이 생기고 있다. 그들은 적극적으로 양질의 개발 인력을 직접 확보하려고 애쓰고 있다. 그들은 그들의 변화 속도, 그들의 혁신을 스스로 제어하고 싶은 것이다. 

IT를 관리 대상이나 설비로 본다면 이러한 행태는 착오라 해야 할 것이다. 핵심 역량이 아닌 것은 아웃소싱해야 하니까. 그러나 IT를 비즈니스의 거울, 비즈니스 수행의 주체라 생각한다면 ②의 용기를 내는 기업은 내일의 서바이벌이 두렵지 않다. 

IT 시스템을 MVC, 즉 모델, 뷰, 컨트롤의 큰 덩어리로 나뉠 때 적어도 모델 정도는 충분히 현업이 만들어 낼 수 있음을 이제는 인지해야 한다. 그러나 현실계의 기업들이 이 가능성을 인지하지 못하고 하도급 공정에 안주한 채 변화에 둔감해 있다면, 그나마 있던 현실의 기회와 가치들은 모두 현실계를 떠나 이상계로 넘어 가 버릴지 모르는 일이다. 적어도 이상계나 환상계는 남을 시키지 않고 자기 스스로 직접 개발하고 있다. 남을 위한 노동은 나를 위한 작품을 보통은 이길 수 없는 법이다. 

1970년대에 알란 케이는 그의 꿈 다이나북을 위해, 프로그래밍 언어이자 동시에 사용자 인터페이스인 스몰토크를 구상했다. 짜는 것과 쓰는 것을 떼어 생각하지 않았던 것이다. 그가 꿈꿨던 하드웨어의 미래는 오늘 우리 무릎 위에 있지만, 그가 꿈꿨던 소프트웨어의 미래는, 그리고 그가 꿈꿨던 '소프트웨어를 만드는 사용자'들은 아직 우리 곁에 보이지 않는다. "사용자는 공동 개발자로 여겨져야 한다"는 웹 2.0적 참여의 이상이 익어 갈 무렵에는 '소프트웨어를 만드는 사용자'들을 우리 곁에서 찾아 볼 수 있을까?@

 

출처 : 인터넷

Posted by SB패밀리

[이론] IT 솔루션이란?

IT 솔루션이란 해결책을 제시하는 소프트웨어나 하드웨어가 될 수 있다.

정의를 내리자면 "과제 해결을 위해 공동으로 동작하는 소프트웨어 단위"라고 할수도 있다.

 

솔루션이라는 용어가 컴퓨터 분야에 사용될 때에는, 사용자 요구에 적합하면서 특정한 형태의 컴퓨터 소프트웨어 패키지나 응용프로그램과 연계된 문제를 처리해 주는 하드웨어 또는 소프트웨어를 의미한다

솔루션은 사용자가 하드웨어, 소프트웨어, 서비스, 응용프로그램, 파일형식, 회사, 상표명, 운영체계 등을 일일이 구별해야 하는 어려움을 겪지 않고도 원하는 해결책을 구입하기 원할 때 주로 사용되는 다분히 영업적인 용어이다. 

따라서 보통 솔루션에 관한 요구는, 수량이 많고 여러가지 작업 및 다양한 제작자의 제품들이 함께 간여되어 있는 경우에 필요하다

 




Posted by SB패밀리

프로그래머를 위한 사용자 인터페이스 설계론
홈페이지: http://korean.joelonsoftware.com/index.html



제 1 부
제 2 부
제 3 부
제 4 부
제 5 부
제 6 부
제 7 부
제 8 부
제 9 부

일별 빌드(Daily Builds)가 당신 곁에 있습니다
2001년 1월 27일 토요일

일별 빌드란 전체 소스 트리를 자동화하여 전체를 일일 주기로 구축하는 작업이다. 일별 빌드(Daily Builds)가 당신 곁에 있습니다 

손쉬운 버그 추적법
2000년 11월 8일 수요일

프로그래머 혼자서 단독으로 코드를 개발하는 경우라도, 체계적인 버그 관리 없이는 좋은 코드를 만들어낼 수 없다. 손쉬운 버그 추적법

손쉬운 기능 스펙 작성법
2000년 10월 2일 월요일

제 2부 : 스펙이란 무엇인가?
제 4부 : 효과적인 스펙 작성 요령
제 1부 : 왜 스펙이 필요한가?
제 3부 : 그렇다면, 어떻게 작성할 것인가?

The Joel Test: 나은 코딩을 위한 12단계
2000년 8월 9일 수요일

SEMA에 대해서 들어보신 적이 있습니까? 소프트웨어 팀이 얼마나 잘하는지를 재는 나름대로 복잡한 시스템입니다. 앗, 아니! 그 링크를 누르지 마세요. SEMA를 "이해"만 하는데 아마 6년정도가 걸릴것입니다. 그래서 소프트웨어 팀이 얼마나 좋은지 등급을 매길 수 있는 - 좀 무책임하고 되는대로의 - 자체적인 버젼의 테스트를 만들었습니다. 이 테스트의 장점은 3분정도밖에 걸리지 않는다는 것입니다. 절약되는 시간으로 의대에 가서 공부할 수도 있을 것입니다. The Joel Test

손쉬운 소프트웨어 스케줄 관리법
2000년 3월 29일 수요일

그렇다면, 왜 아무도 스케줄을 만들려 하지 않을까? 주된 이유는 두 가지다. 첫째는 스케줄을 짜고 관리하는 것이 매우 골치 아픈 일이기 때문이고, 두 번째 이유는 아무도 그것이 그만한 수고의 가치가 있는 일이라고 믿지 않기 때문이다. 스케줄이 지켜지지도 않을 거라면 도대체 왜 그런 수고를 해야 한단 말인가?

제대로 된 소프트웨어 개발을 위한 자본 투자 노하우
2000년 3월 21일 화요일

소프트웨어 회사의 목표가 특정한 문제를 해결하는 것이 아니라 프로그래머를 동원하여 자본을 코드로 변환하는 것이라고 생각해보자.



Joel Spolsky는 뉴욕에 위치한 작은 소프트웨어 회사인 Fog Creek Software의 창업자입니다. 예일 대학교를 졸업하고 Microsoft, Viacom, Juno등에서 프로그래머와 매니저로 일했습니다.
Posted by SB패밀리

소프트웨어는 누가 개발해야 하는가?

김국현(IT평론가)   2006/07/27  
    



소프트웨어는 누가 개발해야 하는가? 세상에 이런 우문이 어디 있느냐 생각할지도 모르겠다. 그리고 '개발자'라 짧게 대답할 것이다. 개발자라는 세 글자에는 외부에서 고용된, 그마저도 몇 단계의 하청을 거쳐, SI 업의 하류 공정을 묵묵히 맡고 있는 젊은이의 초상이 투영된다.

정말 소프트웨어는 그들만의 몫일까? 일견 당연해 보이는 이 상식을 이제는 벗어 버려야 할 때다. 소프트웨어란 '갑'이, 그 중에서도 '현업'이 개발해야 하는 것이다. '을'이 개발하고 ‘갑’은 검수를 하는 현재의 안이한 세태로는 기업이 지녀야 할 속도와 유연성은 참 갖추기 힘든 일이다.

요즈음, 기업의 IT 시스템을 짓는 일을 기업의 사옥을 짓는 일에 섣불리 비유하는 일이 위험해지고 있다 생각하게 되었다. 오늘날의 세태를 생각해 보면 사옥을 지으라 시켜 놓고, 팔짱 끼고 있는 발주자의 모습만이 떠오르기 때문이다. 무언가를 만드는 일의 설렘을 총체적으로 잊어 가는 사회 속에서 주인님이 함께 손에 흙을 묻힐 리가 없는 일이다.

건축이란 적어도 100년, 길게는 세기를 넘긴 미래를 만드는 일이다. 그렇기에 장인의 정성, 즉 고용된 프로페셔널 만으로도 가능한 일이다. 한번 타오른 열정, 100년은 갈 수 있으니 아깝지 않다. 그렇지만 기업의 IT는 오늘을 만드는 일이다. 내일의 비즈니스를 위한 오늘을 매일 매일 만들어야 하는 일인 것이다. 이 사실을 잊을 때 시스템에 우환이 찾아 든다. 기업이 맞닥뜨리게 될 변화의 힘과 속도는 팔짱 낀 방관자적 IT를 두고 볼 정도의 여유가 없다.

시스템을 1년에 걸쳐 치밀히 구축해 봤자, 남는 것은 그 시간 동안 변해 버린 환경과 이를 고려하지 않은 시스템뿐이다. 우리는 이러한 풍경을 수도 없이 목격한다. 새 집을 지어 줬다고 생각했지만, 정작 사용자는 낡고 쓸모 없다 구박한다. 현장의 사용자, 즉 현업이 원하는 그들 마음에 쏙 드는 시스템은 영원히 만들어지지 않는다. 이를 회피하기라도 하듯 현업의 요구는 억제되고, 비즈니스의 혁신은 프로젝트 일정에 의해 묵살된다. 누구를 위한 것인지 알 수 없는 개발 프로젝트는 종료를 향해 앞으로만 내달려 간다.

SI에서 일어나는 관습적 악순환이다. 파견직 개발자들은 자신이 쓸 프로그램이 아니므로, 자신이 유지 보수할 프로그램이 아니므로 정성껏 만들지 않는다. '남'을 위해 짜주는 코드와 '나'를 위해 짠 코드의 질이 같을 리가 없다. 개인이나 집단의 태도나 자질의 문제가 아니다. 인간 본성이다. 훌륭한 프로그램은 남의 집에서 만들어지지 않는 것이다.

미래를 살아 남을 기업은 지금과 같은 태평한 시스템 구축을 견디지 못할 것이다. 그들은 혁신을 위해 더 많은 요구를 할 것이고 그 요구가 받아들이지 못하면 다른 길을 찾을 것이다.

미래 기업은 ① 이상계, 즉 인터넷 서비스 기업이 정성껏 만들어 준 온라인 소프트웨어를 사용하거나, ② 현실계에서 현업 사용자 스스로 직접 소프트웨어를 개발할 것이다.

①은 현재 진행형이다. 온라인 너머로 기업 시스템을 옮기는 SaaS(Software as a Service)라는 행위가 벌어지고 있다. 세일즈포스닷컴(salesforce.com)은 대표적 사례다. 어설프게 개발한 시스템, 어설프게 운영되는 전산실보다 아예 경험 많은 이상계 기업에게 자신의 정보를 업로드해도 괜찮을 것 같다는 정서가 본격적으로 도래할지 모른다. 마치 개인들이 자신의 이메일을 포털에 맡기는 것처럼.

②는 허황된 소리로 들릴지 모르겠다. 비즈니스 수행에 바쁜 기업의 직원들이 언제 프로그래밍 공부하겠냐 할 것이다. 그러나 미래 기업에게는 많은 옵션이 생길 것이다. BPMN(Business Process Modeling Notation)이라는 비전문가도 알 수 있는 단순 조작으로 모듈화된 서비스를 재조합하여 늘 새로운 시스템을 만들자는 SOA의 철학은 엔드 유저 컴퓨팅(EUC)이라는 이루지 못한 꿈을 다시 꾼다. 마치 위키를 쓰듯, 기업 시스템을 현업이 스스로 '매시업(mash-up)'해 주무르는 IBM의 QEDWiki는 ‘사용자가 직접 개발’하는 웹 2.0적 '참여의 아키텍처'를 꿈꾼다. 마이크로소프트 오피스 차기 버전에 새롭게 등장한 Excel Services는 엑셀로 서버 프로그래밍을 가능하게 한다. 회계사 겸 서버 프로그래머, 서버 프로그래밍을 할 줄 아는 보험 업무 담당자가 대거 등장할 것이다.

일을 하다가 필요한 부분은 현업이 직접 만들어 쓰는, 그 정도까지는 아니라도 혁신을 위한 변경은 스스로 수행하는 회사에 어떤 기업이 당할 수 있을까? 전산실에 의뢰하고, 전산실은 외부 발주하여 6개월 뒤에나 오픈할 수 있는 기업과, 오늘 판단하여 내일 바뀔 수 있는 기업 중 누가 승리에 가까이 있을까?

처음에만 외주 개발을 하고 유지 보수를 포함한 2차 개발을 스스로 해결하려는 기업이 생겨나고 있다. 이미 실력 있는 개발자를 '전문 위원'이라고 계약 고용을 하고 있는 기업들이 생기고 있다. 그들은 적극적으로 양질의 개발 인력을 직접 확보하려고 애쓰고 있다. 그들은 그들의 변화 속도, 그들의 혁신을 스스로 제어하고 싶은 것이다.

IT를 관리 대상이나 설비로 본다면 이러한 행태는 착오라 해야 할 것이다. 핵심 역량이 아닌 것은 아웃소싱해야 하니까. 그러나 IT를 비즈니스의 거울, 비즈니스 수행의 주체라 생각한다면 ②의 용기를 내는 기업은 내일의 서바이벌이 두렵지 않다.

IT 시스템을 MVC, 즉 모델, 뷰, 컨트롤의 큰 덩어리로 나뉠 때 적어도 모델 정도는 충분히 현업이 만들어 낼 수 있음을 이제는 인지해야 한다. 그러나 현실계의 기업들이 이 가능성을 인지하지 못하고 하도급 공정에 안주한 채 변화에 둔감해 있다면, 그나마 있던 현실의 기회와 가치들은 모두 현실계를 떠나 이상계로 넘어 가 버릴지 모르는 일이다. 적어도 이상계나 환상계는 남을 시키지 않고 자기 스스로 직접 개발하고 있다. 남을 위한 노동은 나를 위한 작품을 보통은 이길 수 없는 법이다.

1970년대에 알란 케이는 그의 꿈 다이나북을 위해, 프로그래밍 언어이자 동시에 사용자 인터페이스인 스몰토크를 구상했다. 짜는 것과 쓰는 것을 떼어 생각하지 않았던 것이다. 그가 꿈꿨던 하드웨어의 미래는 오늘 우리 무릎 위에 있지만, 그가 꿈꿨던 소프트웨어의 미래는, 그리고 그가 꿈꿨던 '소프트웨어를 만드는 사용자'들은 아직 우리 곁에 보이지 않는다. "사용자는 공동 개발자로 여겨져야 한다"는 웹 2.0적 참여의 이상이 익어 갈 무렵에는 '소프트웨어를 만드는 사용자'들을 우리 곁에서 찾아 볼 수 있을까?@

 

출처 : 인터넷

Posted by SB패밀리

프로젝트를 진행하기 위해서 기획단계에서부터 구현이전단계까지 스토리보드라는 것이 만들어집니다.

그러면, 이 스토리라는 것은 무엇이고 스토리보드에 필요한 것은 무엇인지 알아보자.

스토리보드란 프로젝트를 설계하는 디자인 설명서입니다. 개발 기획서가 프로젝트 개발의 청사진이라면 플로우차트는 타이틀의 인터랙션을 나타내는 것이고 스토리보드는 설계도이자 구체적인 작업지침서입니다.
스토리보드가 완성되면 디자이너는 스토리보드에 명시된 내용에 따라 화면 디자인을 하고 일러스트를 제작합니다.
프로그래머는 스토리보드를 보고 프로그램 설계를 하고 각 세부 로직을 프로그래밍하게 됩니다.
스토리보드는 프로젝트 기획이 완성되었다고 할 수 있는 산출물이며 설계 및 구현을 위한 리소스라고 할 수 있습니다.

스토리보드에 대한 더 자세한 설명이 아래 사이트에 있으니 참조하기 바랍니다.

링크 http://blog.naver.com/jooshe12/100051451581

아래 링크에는 스토리보드 작성법이 설명되어 있습니다.
링크 http://blog.naver.com/jooshe12/100051451534



쌈꼬쪼려 소백촌닭
Posted by SB패밀리

웹사이트를 검색엔진에서 제대로 검색되게 끔 하기 위해 알아야 할 15가지 사이트맵(site map) 제작 규칙에 대하여 알아본다.

사이트맵은 사이트 전체의 메뉴구조나 페이지 분류를 설명할 수 있는 것으로 일종의 가이드라인, 지도, 안내표 라고 할 수 있습니다.
검색엔진에서 로봇이 웹사이트를 들러들러 방문해서 정보,키워드,를 가져갈 때 사이트맵이 있다면... 더 많은 정보를 로봇에게 전달할 수 있을 것입니다...

아래 링크에서 괜찮은 내용을 전달하는 것 같아서 링크를 걸어봅니다.


링크 : http://blog.naver.com/jooshe12/100051453726


쌈꼬쪼려 소백촌닭
Posted by SB패밀리

스토리보드(Storyboard)란?

 

스토리보드는 멀티미디어 타이틀 개발의 설계도이며 구체적인 작업 지침서이다. 즉 멀티미디어 설계 단계의 최종 목표를 달성하기 위한 내용을 컴퓨터 화면상에 맞도록 종이 위에 구성화한 형태이다. 즉, 애니메이션과 비디오가 음악과 결합하여 어떻게 진행되는지를 명확하게 보여주기 위해 사용된다. 개발 기획서가 멀티미디어 타이틀 개발의 청사진이라면 플로우 차트는 타이틀의 인터랙션을 나타내는 것이고, 스토리보드는 멀티미디어 타이틀 개발의 설계도이며, 구체적인 작업 지침서이다.

스토리보드가 완성되면, 디자이너는 스토리보드에 명시된 내용을 가지고, 화면 디자인부터 시작하여 각각의 일러스트 데이터를 그린다. 프로그래머는 스토리보드를 보고 프로그램 설계를 하고 각 세부 로직을 프로그램 코딩하게 된다. 그러므로 스토리보드가 완성되면 타이틀 개발의 기획이 완성되었다고 말할 수 있으며 구체적인 데이터 제작만이 남게 된다. 만일 스토리보드가 잘못되어 있거나 불충분하여 중간에 개념과 로직이 바뀌면 어떤 일이 벌어질까? 그것은 말할 필요도 없이 프로그램과 그림 데이터가 그려진 것 만큼 손해를 입게 된다. 프로그램은 다시 작업을 하여야 하며, 그래픽 데이터는 사이즈와 내용이 맞지 않아 전혀 쓸모없는 것이 되어버리고 일정은 완전히 망가지게 된다.

잘못된 설계도를 가지고 작업하면 완전히 잘못된 개념의 집을 짓게 되어 기초가 무너지게 되는 것과 같다. 그러므로 스토리보드는 치밀하고 정확하게 작성되어야 한다.

 

스토리보드 작성시 체크 포인트

 

(1)    스토리보드는 누가 보아도 프로그램의 흐름과 내용을 쉽게 이해할 수 있도록 표현하는 것이 중요하다.

(2)    기술해야 할 내용은 많고 지면은 한정되어 있는 관계로 가능한 체계적이고 간략한 기호(영문 알파벳)를 써서 표현의 간결함을 꾀해야 한다.

(3)    프로젝트의 성격에 따라 효율적인 S/B 양식을 만들어 사용하는 것이 효과적이다. (예를들면 비디오가 없는 프로젝트의 경우 비디오난은 의미가 없으므로 당연히 삭제하는 것이 적당하다.또 애니메이션이 복잡한 프로젝트의 경우 칸을 넓혀 주는 것이 당연하다.)

(4)    화면 플로우차트는 화면의 전개 순서와 로직을 정확하게 이해할 수 있도록 표현하며 시작과 끝이 정확하게 표현되어야 한다.

(5)    S/B는 가능한 모듈별로 작성하여 이해의 간결성을 도모하는 것이 좋다.

(6)    각 요소는 파일의 종류에 따라 통일적이고 체계적으로 일련번호를 부여하여 전체작업의 효율성을 기하는 것이 좋다.

(7)    위치와 크기, 시간 등을 보여 주거나 실행 특성을 명기하는 것이 좋다.

(8)    스토리보드 양식자의 크기는여유있고 알기쉽게 표현하기 위해서는 A3용지가 좋으나 제작과 정상 프로그래머용, 디자이너용, 일러스트용, 원고 필자용 사운드 작업용 등이 필요하며 디버깅의 효율성을 취해서도 다량의 복사본이 필요하게 되므로 관리상 A4용지가 좋다.

(9)    계속되는 수정사항이 발견되면서, 항상 버전관리를 신속히 하기 위해서 컴퓨터상의 양식으로 만들어 관리하는 것이 편리하다.

스토리보드 작성법

 

Project:  (1)

화면주제

(3)

화면ID

(4)

화면경로

(5)

page

(2)

 

화면구성

 

(6)

화면설명

(7)

 

F/C & Logic

(8)

 

Graphic

Text

Anim./Video

Music

Effect

Narration

Function Key

 

(9)

 

 

(10)

 

(11)

 

(12)

 

(12)

 

(12)

 

(13)

 

 항목 설명 

(1)프로젝트 명

타이틀 또는 프로젝트 명(or 사이트 url)을 기입한다. 

(2)Page 번호

Page번호는 스토리보드의 단순한 일련 번호이다. 하지만 외형상 그리 중요한 의미를 갖지 않는 것처럼 보이는데 반해, 수많은 스토리보드 속에서 특정한 위치를 찾아가기 위해서나 분실시에 쉽게 번호를 체크할 수 있기 때문에 Page 번호는 빠질 수 없는 요소이다 또한, 화면 플로우차트에도 화면전환 표시로 이 Page번호를 사용한다. 이것은 흐름을 쉽게 이해하고 찾아가기 위해서다. 

(3)화면 주제

해당 화면의 내용, 용도를 이해하기 쉽게 기획자가 명기한다. 예를 들면 표지 타이틀, 메인 메뉴, 회사역사, 만든 사람들, 끝내기 등 개발 참여자 모두가 쉽게 이해할 수 있는 이름으로 짓는 것이 좋다. 

(4)화면 ID

이 화면에 해당하는 코드명이다. 플로우챠트의 프레임 명으로 표기되며, 해당 프레임의 배경 그래픽 파일명과도 동일하게 쓰인다. 예) about.html

(5)화면 경로

처음 시작되는 화면에서 현재 화면에 오기까지의 경로를 코드명으로 표시한다. 예를 들어 타이틀로그. 인트로 무비/ 메인 메뉴의 코드 순으로 표시하며, 구조가 복잡할 경우 KEY 프레임이나 현재화면이 분지되어 나온 주 메뉴화면부터 표기하여도 무방하다. 예) 홈/회사소개/회사연혁

(6)화면 구성

각 작업자가 화면의 내용과 구성을 시각적으로 쉽게 이해하도록 스케치로 표현한다. 선택 가능한 아이콘의 개수 구성물의 위치, 애니메이션이 이루어지는 지점 등을 가능한 한 정확히 묘사해야 디자이너와 일러스트레이터가 작업할 때 쉽게 이해하고 불필요한 작업상의 손실을 막을 수 있다. 

(7)화면 설명

그림이나 플로우차트로 표현하기 어려운 화면 분위기 ? 요구 사항을 글로 설명하는 부분이다. 특별히 강조되는 기획의도를 디자이너와 프로그래머에게 각인시킬 필요에서 명기하는 것이다. 애니메이션의 순서나 화면이 뜨는 순서, 특정한 부분에 대해 설명한다. 

(8)Flow Chart 와 Logic

화면 내에서 이루어지는 인터렉션을 표시한다. 화면의 시작에서 다음 화면으로 연결되는 흐름을 논리적으로 정확하게 표현한다. 사용자가 요구하는 의도에 따라 제시되는 화면의 순서나 강제적으로 표현되는 미디어들, 화면을 움직이는 조직, 연결되는 프레임을 명확히 기록한다. 

(9)그래픽

그래픽 요소는 실제로 작업에 들어가는 그래픽 데이터를 표현하는 곳이다. 배경그림, 캐릭터, 아이콘, 버튼 등 그래픽 요소를 디자이너가 작업할 수 있도록 명확히 설명하고 작업을 요구하는 곳이다. 요소의 이름은 이미 약속된 코드체제에 의해 표기되어지고, 코드명 중 중복되는 부분은 생략하여 표기하여도 좋다. 

(10)텍스트

화면에 나타나는 텍스트 내용을 적는 곳이다. 그래픽으로 처리된 제목이나 글씨는 제외하고 텍스트로서 편집 가능한 데이터는 모두 적는다 폰트의 사이즈와 내용의 길이를 고려하여 한 화면에 표현될 수 없다면 어떤 인터렉션에 의해 나타내 줄 것인지는 FlowChart에 표시되어져야 한다. 

(11)애니메이션/비디오

애니메이션과 비디오를 표시하는 곳이다. 보통 애니메이션과 비디오는 사운드와 텍스트를 포함하고 있다. 이 경우 제작하는 화면의 성격을 명확히 하고 하나의 파일로 묶어서 처리하는 것이 좋다. 비디오는 디스플레이되는 위치, 사이즈를 고려해야 한다. 애니메이션이 긴 경우 지면 관계상 다 설명할 수 없기 때문에 영역별 파일을 따로 만들기도 한다. 자세한 그래픽의 묘사는 애니메이션의 순서 등을 표기하는 경우가 있는데 될 수 있으면 최대한의 공간을 활용하여 한 페이지 안에 모든 화면 요소를 기입하는 것이 바람직하다. 

(12)사운드

사운드는 성격상 뮤직(Music), 효과음(Effect), 나레이션(Narration) 등으로 나눌 수 있다. 세가지 요소는 모두 소리라는 점에서는 동일 하지만 제작 공정에서 서로 다른 특징을 가지고 있기 때문에 서로 나누어서 표시하는 것이 좋다. 뮤직은 배경 음악과 실제 상황에서 나가는 주제곡이 있다. 음악은 작곡과 연주 과정을 거쳐 생성된다. 라이센스가 보장되면 분위기에 어울리는 음악을 선곡하여 사용하여도 된다. 효과음은 실제로 내용과 상황에 어울리는 자연음을 만들어 내는 것이 가장 좋은 방법이지만 많은 돈과 연출력이 요구되는 분야이다. 보통은 스튜디오에서 효과음 라이브러리를 활용하여 편집하거나 신디사이즈로 합성하여 만들어 사용한다. 나레이션은 대사 내용으로 스튜디오에서 성우의 목소리와 연출로 생성된다. 

(13)기능키 정의

기능키는 현재의 화면에 사용되는 특수한 목적에 쓰여지는 키를 정의하는 곳이다. 한 화면에서 특정한 키에 기능을 부여하려면 여기에 명시하면 된다. 

(14)로직(logic)

특히 게임류의 타이틀에 필요한 요소로서 게임 진행시 획득되는 점수나 보상 등의 인터렉션을 표시한다.

(15) 작성자 : 해당 페이지 스토리보드의 분식을 막고, 화면전환 표시로 사용한다.
 


. 스토리보드의

 

(1) 아동용 타이틀의

 

Project :

화면주제

메인메뉴

화면ID

MA

화면경로

LG/IN/MA

page

3

화면구성

화면 이미지

 

화면설명

기본 언어는 영어

처음 화면이 뜨면 캐릭터 해리가 나타나서 도움말을 주면서 손을 좌우로 흔들면서 선택을 대기한다.

FlowChart

 

플로우차트 그림

 

 

 

Graphic

Text

Anim/Video

Music

Effect

Narration

FunctionKey

MAG01 배경

펼친책 그림

아이콘 포함

English

Spanish

Japanese

MAC01

해리 캐릭터

MAA01

배경음악으로 앙증맞고 귀여운 춤곡

MAE01

마우스클릭시 효과음

MAN01

안녕 나는 해리야, 나하고 놀자

ESC: 프로그램 종료

F1: 도움말

 

 

(2) 어학용 타이틀 스토리보드

 

Project :

화면주제

UNIT 16 CG1 : 연주회

화면 ID

U16C1

화면경로

메인-D서브-unit16드라마-CG1

화면설명

 준식과 경미가 피아노 연주회에 가서 나란히 앉아 있는 모습. 준식과 경미만 밝게 처리되어 있고 다른 청중들은 선으로만 표현되어 있다. 대화가 시작되기 클래식 음악이 잠깐 나오는데, 준식은 졸고 있다. 준식의 콧방울이 터진다. 반면 경미는 초롱초롱 열심히 듣고 있다. 대사가 끝나고 나면 준식의 얼굴은 빨개진다.

배경id

ACGBAK.gif

화면구성

만화화면

TEXT

 

 

 

 

 

 

 

 

 

F/C

 

 

 

Video

Narration

#1 (피아노 연주회장이다. 준식과 경미는 피아노 연주를 들으며 객석에 앉아 있다 연주가 진행되는 동안 준식은 몹시 따분해한다. 주위를 둘러보다가 손을 만지작거리다가 연신 하품을 댄다. 그러다가 결국 눈을 감고 잔다. 경미는 음악에 심취해 있어서 준식이 자는 것도 모른다.)

 

경미: (상기된 얼굴로) 준식씨, 음악회 어땠어요?

준식: (당황하면서) , . 너무 감동적이었어요/

경미: (혼자 도취돼서) 전음반을 듣는 것보다 훨씬 좋아서 이런 자주 와요. 준식씨는

어떤 연주가 제일 마음에 들었어요?

준식: (팜플렛을 슬쩍 들여다보며) 라흐마니노프 3번이 제일 좋았어요. 제가 제일 좋아하는 작곡가가 라흐마니노프거든요. 아지 연주하기 어려운 곡인데 정말 잘하던데요.

경미: (의아해하며) 오늘 곡은 연주 했잖아요.

준식: (멋적어하며) 그랬나요? 사실 제가 어젯밤에 잠을 못자서……

 

Graphic

U16CG101.gif: 어두운 연주회장에 앉아 있는 경미와 준식, 준식은 반쯤 졸린표정

02:  콧방울이 올라간다.

03: 준식이 얼굴이 빨개지는 표정

 

Effect

  U16CG1E01.wav: 박수소리

 

Music

 U16CG1S01 : 피아노 연주곡 (바이올린 )

 

화면이동 기능

: 도움말            : 메인 메뉴로

: 드라마로          : 서브메뉴로

: 사전아: 종료      : 한국의 문화

CG1     CG2

A:  text보이기(한국)  B: 번역(일어)

 

 

 

 (3) 에듀테인먼트 타이틀의

 

Project :

화면주제

스테이지1(연료실기)

화면ID : ST1FO

   (스테이지1, 연료 실기를 의미)

화면경로

로고->Intro->메인메뉴->비쥬얼1->스테이지

화면내용

황량한 해왕성 지표면과 시커먼 하늘을 배경으로 아래쪽에 우주선이 있다. 앞쪽에 연료를 담은 드럼통이 늘어서있다 드럼통에는 각각의 숫자들이 찍혀있다. 마우스로 드럼퉁을 클릭하면 나레이션과 함께 드럼통이 확대되며 숫자에 대한 애니메이션이 나온다.

SCREEN

   화면의 비쥬얼적인 부분을 표시

Hypermedia

드럼통1 -1 관한 애니메이션

드럼통 2-2 관한 애니메이션

드럼통3에서 10까지 동일

Graphic/Video

G01 : 배경화면으로 해왕성 지표면에 10개의 드럼통이 나열되어 있다. 드럼통마다 1부터 10까지 숫자가 적혀 있다.

G02 : 연료 게이지

F/C

Effect

S01 : 슈퍼빽이 날아올 때의 웅장한 굉음

S02 : 연료통을 클릭한 연료가 들어가는 소리

S03 : 연료를 채운 슈퍼빽이 이륙하는 소리

Back Ground Sound(배경음악)

우주여행을 나타내는 배경음악

( : 스타워즈 배경음악)

TEXT

Hyperlink(화면이동)

  연료를 채우면 비주얼 2 진행<현재 화면에서 이용 가능한 메뉴를 의미>

  버튼 1 : 종료로

  버튼 2 : 메인 메뉴로

  버튼 3 : 도움말

  버튼 4 : 풍선도움말

로직 수치변화

 

   연료 게이지가 숫자를 클릭 때마다 10% 증가

 

 
 
출처 : 인터넷, 지식인
 
좋은 정보 감사합니다.
쌈꼬쪼려 소백촌닭
Posted by SB패밀리

작성 : 데브뱅크 운영자 skyoh

 

먼저 스토리보드가 무엇이며, 왜 웹사이트 제작에 스토리보드를 사용하게 되었는지 부터 말씀드리려고 합니다.

 

원래 스토리보드는 영화나 TV CF, 만화, 그림등의 영상물이나 창작물을 제작할 때 사용되었던 방법으로 의뢰자와 제작자가 작품을 제작하기 전에 제작 전반에 걸친 내용을 간단하게 여러 개의 화면에 전달하고 싶은 영상을 시간적 흐름에 따라 그림으로 표현한 것이었습니다.

 

보다 구체적으로 설명하자면 제작자 또는 의뢰자가 생각하는 이미지를 시각화하는 작업으로 영화나 CF 제작에 들어가기 전에 각 장면에 대한 카메라와 피사체의 움직임을 설명, 어떤 내용을 어떻게 찍을 것인가를 그림으로 표현, 촬영에 필요한 모든 것을 미리 파악하게 해주는 일종의 설계도와 같은 것입니다.

 

의뢰자는 스토리 보드를 보고 실제 작품이 만들어 졌을 때 어떤 내용과 이미지를 갖는지 사전에 확인할수 있고, 현재 제작하려는 작품이 과연 효과적인 안인가 아닌가를 검증해 볼 수가 있습니다. 특히 영상매체 제작에는 필수적인 항목이지요.

 

그럼 웹사이트로 다시 돌아와서, 인터넷 사이트는 기존의 텍스트환경의 네트워크를 탈피하여, 웹을 기반으로 시각, 청각등의 모든 멀티미디어가 표현가능한 종합예술(?)로서의 기능을 가지고 있는 바, 일반적인 말로서의 설명과 구조적인 설명만을 가지고, 아직 제작이 되지 않은 사이트를 설명하기가 힘들어 졌습니다. 또한 어느정도의 규모만 되어도 적어도 기획자, 디자이너, 프로그래머 이 세그룹이 힘을 합해 한가지 작품을 만들어야 하며, 의뢰자의 기존 생각과도 일치 하도록 만들어야 합니다. 다시 말씀드리면 의뢰자, 기획자, 프로그래머, 디자이너, 이렇게 4가지 부류의 사람들이 아직 제작되지 않은 작품에 대해 동일한 컨셉과 이미지를 가지고 제작이 시작되어야 한다는 점입니다.

 

현재 웹기획자들은 여러분야에서 다른 전공을 가지고 일을 하다가 전업을 하게된 경우가 많습니다. 그중의 한분야가 CF나 기타 영상메체의 프로듀서를 하시던 분들입니다. 어찌되었던 만들어지는 표현의 차이일 뿐 전체를 프로듀싱한다는 점에서는 같으니 말이죠.. 이런분야에서 전업하신 기획자님들의 사이트는 그래픽이 섬세하고, 기능적인 부분에 치우치는 경우가 가끔 있다는 단점이 있기는 하지만 이분들이 스토리보드라는 개념들도 같이 가지고 들어오셔서 웹기획일에 또 한가지 중요한 툴을 갖추게 되었죠.

 

어찌되었건 웹사이트 제작에 있어서 스토리보드의 역할은 의뢰자, 기획자, 디자이너, 프로그래머가 사이트를 제작하기 전에 미리 웹사이트의 조금은 디테일한 내용을 머리속에 같은 그림으로 그릴 수 있다는 점과, 사이트의 설계도로서의 역할을 한다는 것입니다.

 

스토리 보드의 제작시점은 사이트의 초기 기획서와 견적서가 제출되고, 계약이 이루어지고, 본격적으로 일이 시작되는 시점에 가장 먼저 그리고 가장 중요한 작업이 됩니다.

 

스토리 보드가 제작되면 의뢰자에서 승인을 받아야 하는 경우도 있고, 스토리 보드 조차도 잘 이해 못하는 의뢰자라면 디자이너가 먼저 중요페이지를 보여주는 부분만 제작하여 승인을 받는 경우도 있습니다. 

 

그럼 이제 스토리보드 제작의 방법에 대해 설명드리도록 하겠습니다.

 

스토리보드의 제작은 사이트의 기획과 제작을 이끌어나가는 기획자의 성향에 따라 매우 다양한 방법으로 진행되고, 표현방법 도 아주 다양합니다. 아직 적립되지 않은 툴이라 모든 기획자가 나름대로 스토리 보드를 제작하고 있고, 모든 기획자가 다 다르다고 봐도 과언을 아닐 듯합니다. 이 이야기는 제가 지금부터 설명드릴 스토리보드 제작에 대한 방법 또한 일반적인 툴이 아니라는 말씀입니다. 사실은 저만의 방법이었으며, 저는 앞에서 말씀드린 것 처럼 방송쪽의 프로듀서나 CF계통 출신이 아닌 만큼 원래의 스토리보드는 본 적도 없습니다. 제 나름으로 사이트를 제작하기 전에 어떻게 하면 좀 더 모든 사람들이 제작완료 단계의 사이트를 상상할 수 있는 설계도를 작성할 수 있을까? 그리고, 어떻게 하면 이문서를 보고 OK한 사람이 다 만들어진 사이트를 보고 [아니 처음 말한것과 왜 다르냐]는 말을 안나오게 정확한 표현이 가능할 까를 연구한 끝에, 그리고 사이트 제작을 한건, 두건 진행하면서 쌓아온 나만의 방법입니다.

 

자꾸 이런 말씀을 드리는 것은 개인의 취향에 따라 사이트가 다르게 나오듯이 자신에게 맞는 스토리보드 제작방법이 있으니 사이트 제작 경험을 쌓으시면서 자신만의 방법을 찾으시기를 바라는 때문이며, 저의 방법이 아직은 완벽하지 않음이 많이 있기 때문입니다.

 

  

1단계. 사이트구조도 작성..

 

먼저 사이트의 구성에 대한 구조가 확립되어야 합니다. 저의 방법은 의뢰자로부터 요청된 내용, 그리고 기획자의 아이디어, 그리고 벤치마킹을 통해 추가되어야 할 부분이라고 생각되는 내용, 또한 최근 인터넷의 흐름 등등 모든 기획적인 요소가 복합적으로 작성되어 사이트의 뼈대가 만들어 집니다.

 

일단 사이트에 들어가야할 모든 내용을 나열합니다. 그리고는 내용적으로 또는 기능적으로 유사내용끼리 묶음을 만들어 갑니다. 이것이 추후 사이트 메뉴의 기본 틀로 구성됩니다. 내용과 카테고리가 많은 경우 트리구조로 엮어지기도 합니다.

 

저의 경우 트리구조로 작성된 이 사이트 구조도를 의뢰자와 작업에 참여할 프로그램머, 디자이너와의 각각 상담을 통해 완성 짓고 결정짓습니다. 첫 단추에 승인을 받지 않고 넘어가면 추후 모든 작업을 다시 하거나 곤란에 봉착하는 일들이 많아지더군요..

 

2단계. 사이트 맵 작성

 

사이트구조도가 완성되면 좀더 자세히 사이트맵을 작성합니다. 이 사이트 맵은 추후 스토리보드의 목차역할을 할 뿐 아니라 사이트 제작의 근간이 되기도 합니다. 이 사이트 맵에는 사이트에 들어가는 모든 페이지가 보여져야 합니다.

 

사이트 맵이 완성되면 그 사이트의 규모나 구조등이 완전히 결정이 되게 됩니다. 항상 반복해서 말씀드리지만 한단계 한단계를 의뢰자의 승인과 함께 같이 프로젝트에 참여하는 모든 사람들의 동의를 얻으십시오. 기획자가 프로그램, 디자인, 기획등 모든 일에 완벽하게 다 알고 있다면 몰라도, 기획자는 신이 아닙니다. 귀를 열고 많은 부분을 받아들이고, 그 다음에 주관을 가지고 결정하신 후 의뢰자의 승인을 받으세요.. 많은 부분들을 설득시키기도 하셔야 할 거고, 새로 추가되어야 하는 내용들도 많이 있을 겁니다. 처음에 완벽한 설계도 작성의 추후에 업무량을 많이 줄여 줍니다(경험).

 

많은 사이트들이 사이트 맵을 보여주고 있습니다. 이용자들의 편의를 고려하고, 이용자들이 이 사이트에서 제공하는 부분을 가장 쉽게 알 수 있는 페이지 이지요.. 여기서 만드는 사이트 맵은 일반 사이트에서 보여주는 사이트 맵과는 조금은 차이가 있습니다. 모든 페이지가 다 들어있어야 하고, 각 페이지 마다 넘버링을 하여야 합니다. 모든 페이지에 대한 넘버링은 추후 스토리보드의 목차역할을 하게 되는 것입니다. 넘버링 하는 방법은 기획자의 재량이지만 이왕이면 넘버만 보고도 어느 부분에 속하는 페이지인지 알 수 있도록 하는 것이 유리하겠지요. 알파벳약자와 숫자를 섞어 쓰는 것이 좋습니다.

 

자 사이트 맵이 완성되셨으면 이제 스토리보드를 만드실 모든 준비를 하신 겁니다. 이제는 스토리보드를 한장 한장 그려보도록 하겠습니다

 

저는 스토리보드를 만들기 전에 사이트맵을 가지고 브레인스토밍을 합니다.

브레인스토밍이란 회의 참가자들이 이견을 제시하지 않고 생각나는 모든 아이디어를 추출하는 회의를 말합니다. 이건 회의시간도 단축되고, 많은 아이디어를 끌어모을 수 있는 아이디어회의 방법중에 하나지요.

 

프로젝트에 참여하는 기획자, 디자이너, 프로그래머가 모여 브레인스토밍을 한 후 거기서 나온 것을 스토리보드를 만들 때 많이 반영도록 합니다.

 

그럼 스토리보드에는 어떤 요소들이 들어가야 하는 지를 살펴보시죠.

 

우선 그 페이지의 구성이 들어가야 합니다.

프레임을 사용하는 지 아닌지, 메뉴의 구성이 상단에 있는 지 좌측에 있는 지 어느 곳에 어떤 내용을 보여 줄 것인지 등 전체적인 화면구성을 보여 주어야 합니다. 메뉴구성을 포함한 페이지의 구성은 디자인 요소 중 아주 중요한 부분을 차지 하게 됩니다. 페이지 구성시 사용자 편의를 최우선으로 하시구요..

 

두번째로 그 페이지의 정보를 보여 줍니다.

지금 작성하고 있는 페이지의 정보를 간략하게 보여줍니다. 저장될 디렉토리, 화일이름, 페이지 title등을 기입하여 주는 것이 좋습니다. 사실 디자인을 하다보면 많은 페이지들을 카피해서 사용하게 되고 페이지의 제목(html코드상)에 소홀하게 되는 경우가 많이 있습니다. 하지만 검색엔진의 로보트가 들어온 경우 페이지의 제목이 아주 유용하게 사용됩니다. 메타네임등을 기입할 필요가 있으

면 이것도 적어 주시면 좋구요..

 

세번째로 링크정보를 보여줍니다.

페이지에 들어간 링크정보를 정리하여 적어 줍니다. 링크를 기입하는 방법은 각 페이지에 넘버를 설정하여 적어주는 경우도 있고 미리 화일네임과 디렉토리를 다 설정하여 적어주는 경우도 있습니다만 서로의 장단점이 있습니다. 물론 후자의 경우로 하는 것이 작업에 많은 도움을 줍니다만, 지면상 아주 협소해 지는 경우가 있으니 잘 생각하셔서 작업을 하세요..

 

네번째로 프로그램요소를 보여줍니다.

스크립트 기능을 사용하는 경우, ASP PHP등의 프로그램을 사용하는 경우 DB를 오픈하고 쿼리를 사용하는 경우등을 표시하고, 그 기능을 적어줍니다.

 

그리고 기타로 꼭 설명이 필요한 것을 적습니다. 어떤 부분을 작업할 때 유의해야 할 부분이나, 꼭 신경써서 만들어야 할 부분등 프로그래머나 디자이너에게 알려줘야 할 부분을 적어 줍니다.

 

이 정도면 어느정도 스토리 보드에 들어갈 부분이 정리가 되는 듯 하네요..

 

그럼 이런 많은 정보를 어떻게 하면 모든 사람이 쉽게 볼 수 있고, 스토리보드를 그리기 쉽게 할 수 있을 까요? 기획자마다 아직은 여러가지 스타일로 만들고 있습니다. 기획자 자신과 또 같이 일을 하는 팀원이 잘 이해할 수 있고, 사이트 제작을 의뢰한 의뢰자가 납득하기 쉬운 폼이라면 어떤 폼이라도 관계없겠지요? 그럼 그런 방법을 한번 알아보겠습니다. 물론 제방법이지만요.

  

 

이제 화면에다 스토리보드를 그려보도록 하겠습니다.

회원님들의 요청에 의해 지금 자료실에다 스토리보드 예제를 올려 놓았습니다.

필요하신분은 그 화일을 받아 프린트하신후 보시면서 글을 읽으시면 좀 더 쉽게 이해하실 수 있을 듯 하네요. 화일은 엑셀로 되어있는 데 이건 제가 엑셀을 잘 다루고 익숙해져서 그렇구요. 파워포인트나 다른 어떤 툴로 작업을 하셔도 아님 손으로 그리셔도 됩니다.

 

다들 잘 보이시나요? 잘 안보이신다구요.. 그럼 제가 대략적인 그림을 보여드릴께요.. 영차!!

 


 

그림이 좀 무겁네요.. 잘 보이시나요? 그래도 안보인다구요? 그럼 그림을 클릭하면 크게 보이실 거예요.. 전체창으로 보이니 불편하시죠? 그럼 그림을 오른쪽마우스로 클릭하시구요. 다른이름으로 대상저장을 누르셔서 화일을 저장하신 후보셔도 되구요.. 설명과 같이 보시려면 한장 프린트 하셔서 옆에 두고 보세요.

 

~ 자 그럼 이제 잘 보인다고 믿고 한가지씩 설명을 드리겠습니다.

 

1. 화면 제일 좌측상단에 Name란에는 화일이름을 표시하구요.. 사실 초기에 화일이름을 일일히 다 결정하지 않고 작업을 하는 경우에 페이지마다 넘버를 부여해서 사용하는 경우도 있습니다. 그런데 제가 작업을 해본 결과 화일네임을 앞장에서 말씀드렸던 사이트맵 작성하실 때 미리 다 만드시구요.. 화일네임으로 작업을 하시면 미리 링크를 걸수 있어서 좋습니다. 단지 제 방법이구요.. 편리하신 데로 하세요.

 

2. 고 바로옆에 Floder를 적는 란을 마련했습니다. 현재 작업하시는 파일의 디렉토리를 적어 주시면 됩니다. 링크를 걸 때 상대적인 주소를 사용하게 되는 경우는 이 화일이 있는 위치를 파악하고 있으 면 편리 하지요. 링크를 거는 사람에 대한 배려입니다요..

 

3. 우측상단에는 타이틀과 Meta라고 적혀있는 부분이 있지요?

Title에는 그 페이지의 제목을 적어 줍니다. html 페이지 상단에 title 코드를 넣게 되는 데 이곳에 제목을 넣게 되면 그 페이지를 열었을 때 모니터 하단에 창이 열렸다는 표시에도 표시가 되구요. 브라우저 제일위에도 보여주게 됩니다. 그리고 더 중요한 것은 메타정보들과 함께 타이틀을 가져가는 로보트들이 있습니다. 검색엔진에서 사용하는 로보트들이 사이트에 들어온 경우 모든 페이지를 읽어가서 자신의 검색사이트에 올리게 되는 데 이 때 타이틀에 제목을 안 적어 준 페이지는 제목없음으로 나오게 되지요.. 그리고 메타네임은 주로 메인페이지에 많이 적어주는 데 자세한 내용은 프로그래머나 디자이너에 맡기시구요. 메인페이지라면 적어도 메타 키워드하고 디스크립션 정도는 적어주십시오. 웹페이지들을 만들다보면 비슷한 페이지를 카피해서 사용하는 경우도 많구요. 제목에 소홀해 지는 경우가 많은 데 작은 곳에서 부터 마켓팅을 준비하시는 자세가 필요합니다.

 

아직 프린트 하신 거 가지고 계시죠? 무슨 프린트냐구요? 우쉬~

운영자(오종혁)가 스토리보드 예제 만들어 드린 거요.. 없으시면 스토리보드의 제작(5)에 가셔서 그림클릭하시고 한장 인쇄하세요. 그 거 보면서 설명 읽으시는 것이 훨씬 도움이 되실 거 같아요..

 

이 예제는 물론 눈치채셨겠지만 데브뱅크 사이트 입니다. 기존에 작업했던 거 가지고 사용할려고 했더니 보안이다 뭐다해서 공시할 수 있는 게 없네요. 사실 데브뱅크는 제가 기획, 프로그램, 디자인, 강좌 다 하거든요. 이럴때는 스토리 보드가 필요없답니다. 나 혼자하는 데 그게 왜 필요하겠어요? 머리속에 다 있고, 제 손발은 제 머리하고 연결되어 있거든요. 하지만 혼자 모든 일을 하게되는 일은 거의 없죠.. 의뢰자, 프로그래머, 디자이너와 공동컨셉을 가지고 작업을 해야되고, 사이트가 만들어지기 이전에 이미 모든 걸 공유하고, 승인이 나야 하니까요.. 그리고 만들면서도 설계도 역할을 하니 작업하면서 서로 군소리를 줄일 수 있고 작업효율도 향상되지요.

 

그래도 회원님들의 요청을 뿌리치지 못하고 운영자가 한장 그렸습니다. 그림솜씨는 없지만 예쁘게 봐 주세요..

어디까지 설명을 드렸더라? ! 메타네임.. 그럼 이번시간에는 아래부터 설명을 드리겠습니다. 페이지의 아래를 보세요.

 

4. 화면의 좌측하단에 보시면 Link정보라는 란을 마련해 두었습니다. 링크되는 곳과 링크페이지를 보여주어야 하는 데 화면에다가 다 적으면 여기저기 적다가 나중에 적을 곳이 없어서 선을 찍~빼서 적기도 하고 나중에 그것도 안되면, 문방구에 가게됩니다. 큰 종이사러~..

그래서 코드화 했습니다. 물론 제방법이지만 링크는 {}를 사용해서 Link에서 따온 약자 L을 넣고 일련번호를 넣었지요. {L01}, {L02}, {L03}이런 넘버들이 보이시죠.. 이 표시를 메인창 링크들어가는 곳에 넣으시고 그 정보는 하단에 적으시면 편리합니다. 중괄호 { 가 불편하시면 < # 등을 사용하시는 것도 좋구요. 링크정보를 적으실 때 디렉토리까지 적으시면 다른 페이지가 만들어지지 않

은 상황에서 미리 링크를 걸어 놓을 수 있지요. 하지만 미리 링크를 거신 경우에 끊어진 링크가 있는 지 수시로 확인하시고, 사이트가 다 만들어진 경우에 모두 클릭해 보시고 확인해 보셔야 합니다. 끊어진 링크는 사이트의 신뢰를 무지하게 떨어뜨리는 요인이 됩니다.

 

5. 다음은 페이지 우측하단인데요.. 요건 예전엔 안쓰다가 최근에 제가 좀 업데이트를 해서 사용하고 있는 부분입니다. Program란에는 이 페이지에 프로그램 요소가 들어있는 지 유무를 넣는 란이지요.. O, X로 넣기도 하구요. ASP, PHP로 넣기도 합니다.

그리고, DB Query란에는 이페이지에 DB에서 불러오거나 입력 또는 수정하거나 DB내용을 컨트롤 하는 쿼리를 사용하는 지 유무를 체크해 주는 란이구요..그리고 Script라고 써있는 부분은 자바스크립트나 VB스크립트가 이페이지에 사용되는지의 유무를 표시해 줍니다. 마지막으로 Image부분은 이페이지에 필요한 이미지 특히 새로 만들어야 하는 이미지의 숫자를 표시하고 있습니다.

요부분은 프로그래머나 디자이너가 스토리보드를 볼 때 이부분을 보면 대략적으로 이 페이지를 만들 때 어느 정도의 일을 해야하고 어떤 부분을 사용해야 하는지 보여주는 곳으로 일일히 내용을 읽지 않고도 어느 정도 알 수 있지요. 프로그래머나 디자이너들이 좋아하더라구요. 한번 사용해 보세요..

 

인쇄하신 스토리보드 종이 아직 버리지 마세요.. 만일 벌써 버리셨다면 스토리보드의 제작 (5)에 가셔서 또는 자료실에 가셔서 다시 한장 받아오시구요. 아참 아무리 운영자가 그림을 못그려도 그렇지 벌써 버리시다니..

 

6. 우측하단에 연결Table이란 곳이 보이시지요?

이부분은 Table기획이 끝나고 나서 스토리보드를 만드는 것이 좋다는 것을 미리 알려주고 있습니다. 프로그래머가 DB의 어떤 Table을 사용해야 하는 지를 보여주는 부분인 데, 어떤 분들은 이건 월권이다. DB설계는 프로그래머의 고유권한이다.. 라고 하시는 분들도 있을 지 모르겠습니다. 하지만 웹기획자는 사이트의 모든 부분을 기획하시는 것이 좋습니다. DB기획은 프로그램머와 같이 합니다. 사실 DB기획은 다른 강좌에서 자세하게 설명하겠지만 사이트가 성장(?)했을 때 엄청난 파급효과를 가져오는 부분으로 기획자가 미리 이 사이트가 테이블 별로 어느 시점에 어느 정도 성장할 지 각 테이블이 추후 어떻게 사용이 될지에 대한 정보를 프로그래머에게 주시고, 프로그래머와 잘 상의하셔서 Table에 대한 설계를 하셔야 합니다.

DB가 필요한 부분은 {D01}, {D02}, {D03}같은 코드를 저는 사용하고 있습니다. 메인창에 코드를 표시하고 이곳에다가 Table명을 기입하고 있지요. 프로그램작업하실 때 많이 편리하실 겁니다. 물론 사용하는 컬럼네임까지 적어주면 좋겠지만 지면 관계상 적지 않고 있습니다. DB가 중요한 사이트라면 항목을 한번 만들어 보시는 것도 좋겠네요..

 

7. 다음은 우측중간에 있는 내용입니다.

여기는 메모창입니다. 창에 각 요소마다 주석을 달아야하는 데 이곳에 적습니다. 저는 코드를 <A>, <B>, <C> 이런 형태로 사용하는 데 이건 좋으실 대로 하세요. 가나다를 쓰시던지 1234를 쓰시던지 말리지 않겠습니다. 주석을 적으실 때는 주석정보를 보실 분, 디자이너 또는 프로그래머에게 의사가 정확하게 전달될 수 있도록 하시고 간결하게 표현하시는 것이 좋습니다. 저의 경우 공간이 부족한 부분은 메인창 뿐아니라 어떤 곳이라도 테그를 달고 이곳에 적습니다. 사용하다보면 공간이 부족한 부분이 많이 생기실 겁니다. 지금 예제에도 메타 Description항목에 <J> 라는 코드가 붙어있고 그 내용이 내용의 <J>에 들어 있지요.. 이렇게 사용하시면 됩니다.

다시 한번 노파심에 말씀 드리지만 지금의 예제는 정형화 된 폼이 아닙니다. 이건 제가 사용하는 방법이구요. 이걸 힌트로 기획자님들 각자의 멋진 폼을 만드시고 같이 일하시는 프로그래머, 디자이너가 쉽게 모든 정보를 알 수 있도록 만드시면 됩니다. 그리고, 사이트의 문외한인 의뢰자가 보고도 그 페이지가 어떻게 구성될 지 알 수 있도록 하면서 빨리 작성할 수 있는 툴을 만드십시오.

 

프린트하신 페이지의 좌측 중앙부분의 넓은 창이 있지요

 

 이 곳에 이 페이지의 구성이 들어갑니다. 물론 제 방법이구요. 이곳에다가 상세한 디자인을 그리지는 않습니다. 다만 어떤 부분이 어느 곳에 들어갈지 전체 구성이 들어가지요. 디자인에 대한 컨셉을 설명하기는 하지만 실제 디자인 작업은 디자이너의 몫이라고 생각합니다.

자 그럼 하나씩 집어보면서 각 코드부분과 내용부분을 찾아 보시면 이해가 되실 듯 한데 먼저 메인창의 젤 위에 A라는 주석표시가 보이시죠. 이건 내용부분에 이에 대한 설명이 있다는 표시입니다. 내용에 보시면 A항목에 topmenu.asp삽입이라고 되어있지요.. 이 화일을 이곳에 삽입하라는 말이지요. 실제로 지금 데브뱅크 사이트의 상단 메뉴는 화일삽입으로 처리하고 있습니다. 제일 아래쪽에 주석I도 하단메뉴를 삽입하라는 내용임을 아시겠지요? 네 이렇게 표시하시는 겁니다. 쉽지요?

그리고 네모들이 보이시죠.. 작은 네모, 중간네모, 큰네모, 그건 내용을 구분해 주고 있구요. 페이지의 전반적인 구성도을 보여주고 있습니다. 이걸 토대로 디자이너는 html 테이블 설계를 하게되고 그안에 디자인들을 그리게 됩니다. 이 페이지에서는 작은 네모들은 제목들을 표시하고 있구요. 큰 네모들은 내용을 넣을 공간들을 표시해 주었습니다. 전 주로 이런 네모들을 사용하는 데 그림을 잘 그리시는 회원분들은 더 멋지게 그리시리라 생각되네요..

주석A 아래 작은 네모에 보면 주석B 표시가 있지요. ? 여기저기 많이 있네요. 주석B의 내용을 보니 배경에 이미지를 삽입하라는 내용입니다. 데브뱅크 메인페이지를 보면 제목을 보여주는 부분에 같은 이미지들이 여러개 보이죠? 바로 이것입니다. 배경으로 넣어주고 그위에 제목을 적고 있음을 알 수 있지요. 같은 내용의 주석은 이렇게 같은 주석으로 여러곳에 표시하시면 편리합니다.

지금처럼 데브뱅크 메인페이지를 보시면서, 스토리보드 예제를 보시면 좀 이해가 쉽지 않을까 하는 생각이 드네요. 이게 거기 거든요. 이 스토리보드가 실제로 어떻게 구현되는 지 한번 잘 살펴 보세요. 링크 주소들은 좀 달라지긴 했습니다만. 똑같습니다.

또 그림을 찬찬히 보시면 아까 설명드린 링크표시들 DB표시들도 보이시지요? 각 코드 번호에 해당되는 곳을 찾아가시면 사이트를 만드는 데 그 부분에서 참고해야할 내용들이 들어있지요. 함 잘 찾아 보시구요..

자 사이트에 대한 설계도 처럼 보이시나요? 이것만 보면 이 페이지가 어떻게 만들어 질 지가 보이시나요? 만일 그렇다면 전 성공한 거구요. 아니라면 이 페이지는 실패입니다.

아 그럼 간단하게(?) 스토리보드에 대한 장황한 설명을 일단 일단락 지을 시간이 된 것 같네요.. 더 발전되고 향상된 내용이 있으면 다시 올리도록 하겠습니다. 제가 스토리보드를 만드는 방법이 많이 미흡한 방법이지만 조금이나마 도움이 되셨으면 좋겠네요. 여러번 연습해 보시구요. 자신의 팀에 꼭 맞는 가장 좋은 툴을 찾아가시기를 바랍니다.


출처: 데브뱅크 대표이사 오종혁

좋은 정보 감사합니다.
쌈꼬쪼려 소백촌닭
Posted by SB패밀리

그린컴퓨터 최중구님의 글입니다. http://greenpc.co.kr/programmer.htm
-----------------------------------------------------------------
프로그래머의 글
1) 글을 시작하면서

오늘 이 글을 통해 혼란한 국내 소프트웨어 개발(프로그래머) 직종을 이해할 수 있는 설명을 하고자 합니다. 더 나아가 프로그래머라는 직종을 이해하는 것을 시작으로 프로그래머의 길을 걷고자 하시는 많은 분들이 밟아 올라가야할 방향을 제시할 수 있기를 바라는 마음에서 이 글을 적어봅니다.

2) 프로그래머에 대한 아마추어적인 발상

최근들어 인터넷이 사회적인 이슈로 떠오르면서 자연히 소프트웨어 개발에 대한 관심이 증대되고, 자연히 프로그래머라는 직업을 갖고싶어 하는 사람들이 늘고 있습니다. 하지만 소프트웨어 개발에 대한 잘못된 시각때문에 전문 직종으로 분류되어야할 프로그래머가 일반 직종으로 분류되고 있는 기현상을 보이고 있는 점은 프로그래머가 되고자 노력하고 있는 한 사람으로서 가장 걱정되는 부분입니다.

프로그래머라는 직업을 의사라는 직종을 예로들어 비교를 해본다면, 의사가 되기 위해서는 의대의 정규과정을 이수한 후 국가공인 자격시험을 통해 인턴/레지던트/전문의 순서를 밟아야 합니다. 이 처럼 의사라는 직종은 분야도 확실하게 나뉘어져 있을뿐만 아니라 의사로서의 자질을 평가하는 제도적인 체계가 정확하게 잡혀있습니다. 하지만, 프로그래머라는 직종은 그렇지 못합니다. 전산과를 나온다고해서 프로그래머가 되는 것도 아니고, 대학을 나오지 않았다고 해서 프로그래머가 되지말라는 법도 없습니다. 정보처리 관련 국가공인 자격증을 갖고있다고 해서 프로그래머가 되는 것은 더더욱 아니고 분야 또한 정확하게 구분할 수 없는 것이 프로그래머라는 직종입니다.

이처럼 프로그래머에 관한 정확한 정의가 내려지지 못하고 있는 상황에서 사회적 분위기는 소프트웨어 인력시장에 있어 큰 혼란을 초래하고 있는 것이 사실입니다. 때문에 프로그램 공부를 시작하려는 많은 사람들에게 혼란을 주고 있는 것이라 생각되는군요. 분야와 개인의 노력여부에 따라 틀리겠지만, 단순히 학원에서 몇 개월 과정을 이수한 것이나 프로그램 몇가지를 개발해본 경력으로 자신을 프로그래머라 칭하고 또 인정하는 사회적인 분위기에는 문제가 있습니다. 저도 올해로 프로그램을 시작한지 15년째고 실무경력은 15년 이지만, 지금도 저 자신을 프로그래머라 부르기에는 부끄러운 점이 많습니다. 사실 프로그래머라는 직종은 전문직에 속하는 것입니다. 의사보다는 훨씬 못하겠지만 그에 못지 않게 오랜 기간동안 공부하고 경험을 쌓아야만 비로소 프로그래머가 될 수 있는 것인데, 프로그래머라는 직종을 보는 일반적인 시각은 너무 쉽게 생각하는 경향이 있지 않는가 하는 생각이 들 때가 많습니다.

3) 풍요속의 빈곤

이러한 잘못된 사회적 통념이 굳어져 가고 있는 우리나라의 프로그래머 인력시장의 구조를 살펴보면 그 문제점을 가장 단적으로 알 수 있습니다. 우리나라 소프트 업계의 인력시장의 구조는 초보자로 부터 시작해 고급자로 균형이 있게 올라가는 정상 피라미드와는 많은 차이가 있습니다. 초급에 해당하는 아래부분은 비정상적 포화상태를 띠고있는 반면에 중급자 및 고급자들은 거의 찾아보기 힘든 구조를 나타내고 있습니다.

이러한 현상은 프로그래머라는 직종에 단순한 흥미와 사회적 분위기에 휩쓸려 뛰어드는 사람들은 많지만, 체계적인 교육과 평가 방법의 부재 및 영세한 국내 소트웨어 업계의 투자부족으로 인하여 중급이상으로 발전하는 프로그래머 지망생이 없기 때문에 나타나는 현상으로 볼 수 있습니다.

이와는 별도로 외국기술과 객관적으로 비교해 봤을때 훨씬 뒤진 기술조차 공유하는 것을 꺼려하고 있다는 점 또한 국내 소프트웨어 업계의 발전을 저해하는 요소로 지적할 수 있습니다. 하루가 다르게 변모하고 있는 세계적인 소프트웨어 업계와 경쟁하려는 생각은 하지 않고 오히려 지금 갖고 있는 지금까지 해왔던 일들만 편하게 하려는 안일한 생각들은 물론이고 그 보잘것 없는 기술을 통해 기득권을 유지하려는 잘못된 생각이 가장 큰 문제점이라 할 수 있습니다.

이러한 비정상적 인력시장 구조 속에서 정말 필요로 하는 프로그래머를 찾기란 하늘의 별따기와도 같으리라는 점은 누가 봐도 자명한 사실입니다. 풍요속의 빈곤이라는 용어가 어울릴정도로 프로그래머로 일하려는 사람은 많은 반면 정말 실력있는 프로그래머는 손에 꼽는 현상이 나타나는 것입니다.

4) 프로그래머가 갖추어야할 자질

프로그래머가 되기 위해 갖추어야할 자질에는 여러가지가 있습니다. 그 모두가 천재적인 재능을 필요로 한다기 보다는 끊임없는 노력을 통해 얻어질 수 있는 것이라 할 수 있는 것들입니다.

첫째, 집요하고 꼼꼼해야 합니다.

프로그래머의 직업병이라고도 할 수 있는 집요함이 있어야 합니다. 문제점을 찾아내고 해결하기 위해서 집요하게 들러 붙어 있을 수 있는 근성이 필요합니다. 차분하고 꼼꼼하면서 끈질긴 성격을 가진 분들은 어디가나 성공하시겠지만 프로그래머에게는 필수조건이라고 할 수 있습니다. 차분한 성격은 타고나는 것도 있겠지만 훈련을 통해 개발될 수도 있는 것입니다. 예를 들면, 마인스위퍼를 한다던가~ ^^퍼즐등을 통해서 키워질 수 있겠죠.

둘째, 논리력이 뛰어나야 합니다.

프로그램의 거의 대부분을 차지하는 것은 조건판단, 분기, Loop문을 작성하는 것입니다. 논리력이 없이는 할 수 없는 일들입니다. 일반적으로 남성에 비해 여성이 논리력이 뒤진다는 속설이 있어서 그런지는 모르지만 이 점 때문에 여성 프로그래머가 많지 않다고들 합니다. 집요하면서도 꼼꼼하게 논리를 구축해야 Bug 없는 프로그램을 작성할 수 있다고 봐도 과언이 아닙니다. 논리력 또한 훈련을 통해서 개발될 수 있는 것이죠. 역시 마인스위퍼를 한다던가~ ^^ 논리학등을 공부하고 일상생활에서 논리적인 사고를 하기위해 노력을 함으로써 개발할 수 있겠죠. 전 세가지 다 했습니다.

셋째, 세상을 보는 관찰력과 추상력이 뛰어나야 합니다.

프로그램은 추상화를 기본으로 하고 있습니다. 실세계를 축소해 놓은 것이 프로그램이라고 말해도 과언이 아닐 정도록 현실과 밀접한 관계를 갖고 있는 것이 프로그램입니다. 때문에 관찰력과 추상력이 필요합니다. 실세계의 특징을 찾아내고 단순화 하고 추상화하는 과정은 프로그램의 설계부분에 들어가기 때문에 전체적인 성능을 좌우하는 중요한 요소로 작용하기 때문입니다. 관찰력과 추상력은 경험을 통해서 개발될 수 있을 겁니다. 꼼꼼한 성격도 한몫을 할 수 있겠죠.

이러한 기본 자질들은 상호보완적인 관계속에서 프로그래머의 능력 개발에 도움을 줄 수 있는 것들입니다. 이러한 자질만을 갖고 있다고 해서 프로그래머가 될 수 있는 것은 아닙니다. 기본적인 전산이론은 물론 기타 관련 이론에 대한 공부가 필수적입니다.


첫째, 전산개론

일종의 상식공부라고 할 수 있습니다. 전산의 변천사는 물론 전산의 폭넓은 분야를 아는 것이 지금의 자신의 위치를 알 수 있는 가장 중요한 방법이 되기 때문입니다.

둘째, Hardware의 구조 및 동작원리

프로그래머는 Hardware는 몰라도 된다는 식의 발상은 정확하게 틀린 말입니다.Software는 Hardware상에서 구동되는 것이기 때문에 Hardware의 구조가 어떻고 어떤 원리와 절차에 의해서 구동되는지에 관한 특성을 알지 못하면 Hardware에 맞는 최적화된 Program을 개발할 수 없기 때문입니다. Pentium 계열의 CPU 에서 Pipeline Optimize의 개념을 알지 못한다면 Speed 최적화를 할 수 없는 것과 마찬가지입니다. 고급 프로그래머가 되기 위해서는 결코 등한시 해서는 안되는 점임을 잊지 마시기 바랍니다.

셋째, OS 이론

모든 프로그램은 OS 환경가 제공하는 환경에서 구동되도록 되어 있습니다. HW와의 복잡한 일들을 모두 맞아서 처리해주는 것은 물론 기타 유용한 Service를 제공해주는 OS를 몰라서는 그 OS에서 구동되는 프로그램을 개발할 수가 없습니다. 보다 넓은 시야를 갖고 전체적인 그림을 그리기 위해서는 OS를 어떻게 만들 것인가에 관한 이론들을 아는 것이 중요합니다. OS도 만드는데 다른 프로그램을 왜 못 만들겠습니까?

넷째, 자료구조/알고리즘 이론

프로그램의 꽃이라 할 수 있는 기본 이론들입니다. 프로그램에서 가장 중요한 부분인 자료의 저장과 처리에 관한 방법론들을 정리해 놓은 이론들로서 반드시 거쳐야하는 난코스라고도 할 수 있습니다. 자료구조/알고리즘을 모른다면 단순 Coder도 못된다는 결론이 날정도로 프로그래머가 되기위한 가장 기본적인 조건입니다.

다섯째, 전산언어론

C/Pascal/Fortran 등의 언어가 없을때는 어떻게 프로그램을 했을까? 라는 질문에 대한 답을 던져줄 수 있는 이론들입니다. Assembler로 부터 4GL까지의 발전사를 알 수 있을 뿐 아니라 C/C++와 같은 언어를 어떻게 만들 것인가를 정리하는 이론들입니다. Compiler 를 어떻게 만들 것인가에 대해 고민해보신적 있습니까? Compiler를 만든다면 그 Compiler가 번역하는 언어는 자유자제를 넘어 신의 경지에 오를 수 있지 않겠습니까?

여섯째, 개발방법론

전산언어론과는 또 다른 개념의 이론들을 모아놓은 것으로써 소프트웨어를 생산에 공학개념을 도입하고자 하는 이론들입니다. 체계화된 방법론을 통해 소프트웨어 개발의 생산성을 높이고자 하는 목적을 갖는 이론들입니다. 생산성을 생각하지 못한다면 경쟁력을 갖지 못하는 것은 당연한 것 아니겠습니까?

일곱째, 전산언어

C/C++과 같은 언어의 문법을 배우는 단계입니다. 가장 처음 프로그래머가 되겠다고 마음 먹은 사람들이 가장 많이 만나는 첫번째 적수이지요. 하지만 전체적인 그림속에서 전산언어가 차지하는 비중은 제일 마지막에 속하고 있다는 점을 유념하시기 바랍니다. 어떤 언어를 사용하는가는 중요하지 않다는 점입니다. 언어는 도구일 뿐이지 목적이 아니라는 점을 다시한번 강조하고 싶군요.

위에 나열된 주제들은 대부분의 전산과 교과목에 포함되어 있는 내용들입니다. 모두 한학기 분량이지만 결코 한학기 안에 끝낼 수 있는 내용들이 아닙니다. 1년 동안 세가지를 끝낸다고 해도 2년이 넘는 시간이 필요하다는 단순계산이 나옵니다. 결코 만만한 일은 아니죠.

여덟째, 실무경험

위의 조건들을 갖춘 대부분의 사람들은 일반적으로 실무경험이 부존한 것이 현실입니다. 단순히 이론적인 것으로만 접근해서는 좋은 프로그램이 나올 수 없습니다. 프로그램의 최종 사용자는 고객입니다. 고객의 입장에서 만들어야 가장 좋은 프로그램이 될 수 있습니다. 고객이 되어 본 사람은 좋은 프로그램을 만들 수 있습니다. 왜냐하면 고객은 그 업무를 가장 잘 알기 때문입니다.

5) 기본위에 쌓여진 경험

2년 안에 위에서 나열한 기본들을 모두 마스터 한다고 해도 Coder로 인정받기란 쉬운 일이 아닙니다. 원론을 그대로 적용해 해결할 수 있는 문제는 하나도 없다는 것은 너무나도 당연한 사실입니다. 책 속의 이론이 내안의 경험으로 쌓일때 비로소 내것이 될 수 있는 것입니다.

지금의 저 또한 그 기본위에 경험을 쌓기 위해 노력중인 사람이라고 말씀드리고 싶습니다. 항상 따라가도 먼저 뛴 사람들은 저만큼 앞서 가고 있다는 걸 느낄때마다 프로그래머라는 직업이 얼마나 피곤한 직업인가를 새삼 깨닫고 있으니까 말입니다.

6) 글을 맺으며... 세상 밖으로...

장황하게 나마 프로그래머라는 직종에 대해 설명을 해보았습니다. 글을 읽다 짜증이나시지나 않았나 모르겠군요. 하지만 이것이 지금의 제가 보고 있는 국내 업계의 현실입니다. 물론 상황에 따라 부분적으로 틀릴 수도 있겠지만 큰틀에서 본다면 제 글에서 벗어나는 것이 없습니다.

그 것은 바로 얼마전까지 워드프로세서를 만들던 한 소프트웨어 업체가 국내 소프트웨어 업계를 대표했었다는 사실만 봐도 알 수 있습니다. 그 폐단은 지금에 와서 더더욱 커지고 있죠. 외국과의 자료교환이 불가능 하다는 결정적인 문제점을 남겨놓고 무책임하게도 사라져버리지 않았습니까? 한국의 빌게이츠라는 말이 창피할 정도로 몰락하고만 기업에서 한동안 일을 했던 경험이 이렇게 더 큰 분노를 만들고 있습니다.

기본을 무시하고 사상누각을 쌓았던 한국병이 이 소프트웨어 업계에도 어김없이 자리잡고 있다는 것을 왜 아무도 지적하지 않는지 모르겠습니다. 밴쳐라는 이름아래 개혁의 면죄부를 받고 있는 기업들이 지금도 많다는 것에 안타까울 뿐입니다.

눈을 한번 돌려보시죠. 어느 나라가 워드프로세서 업체를 자국의 소프트웨어 대표기업이라고 떠들어대는지를...

우리는 아직 멀었습니다
Posted by SB패밀리

http://www.zdnet.co.kr/builder/system/etc/0,39031682,39147115,00.htm

 

 

버그 없는 프로그램은 없다

최진호 (한국 IBM 소프트웨어)   2006/05/04
때는 바야흐로 거미줄력 12년, 버너스 경이 웹과 브라우저를 만들고 웹의 지배 아래 세상이 마우스 클릭질로 시끄럽기 그지없던 시절이었다. 초기의 웹은 그저 집 없는 개인 사용자의 한풀이용으로 홈페이지 제작 기술을 위해 쓰이던 것이었지만 점차 그 허접하던 초기 기술적인 한계를 극복하고 수많은 천재들과 박사들의 컨설팅, 아키텍팅 그리고‘노가다’를 바탕으로 이제는 꽤나 위험할 듯 하고 시스템이 중지되어 버리면 범국가적 위기 상황으로 번질 만한 부분에도 웹이 야금야금 지배하기 시작했다. 바야흐로 전 세계가 거미줄에 대롱대롱 매달려서 살아가고 있는 것이다.

웹은 편하고 단순하고 빠르다. 게다가 돈도 별로 들지 않는다. 이렇게 너도 나도 다 웹 동네에서 살다보니‘가지 많은 나무 바람 잘 날 없다’고 웹 시민들을 끊임없이 괴롭히는 존재가 있었으니 바로 버그라는 놈이었다. 웹 버그는 웹 초기에는 단순히 소스코드 상에서만 숨어있어서 웹 개발자들이 쉽게 끄집어내어 처리하는 것이 가능했으나 점차 웹의 세계가 복잡해지면서 단순히 개발자가 처리할 수 있는 수준을 넘어서게 되었고 이 버그를 해결하는 데 수많은 인력이 투입되기 시작한다. 범기업적, 범국가적, 범세계적으로 문제를 일으킬만한 버그들이 하나 둘 씩 모습을 드러내면서 웹 시민들은 더 이상 이 웹을 좌시할 수 없게 되었으니 이것이 바로 버그 사냥꾼이라는 직업이 태어나게 된 계기가 되었다.

버그 사냥꾼이란?
그렇다면 버그 사냥꾼은 어떤 사람들이며 무슨 일을 하는가? 앞에서도 말을 했지만 웹이 주체할 수 없을 만큼 거대하고 복잡해져 버렸다. 우리가 웹 기반 하에서 서비스를 개발하면 과거에는 해당 서비스를 위해 필요한 다양한 아키텍처적인 요소들을 고려해서 해당 요소들을 거의 모두 개발해야만 했다. 왜냐? 기반이 없었으니까. 즉 보안이나 신뢰성, 성능, 데이터 정합성, 트랜잭션, 확장성 등 거의 모든 부분에서 개발자와 아키텍트들은 그들의 창조성과 능력을 발휘할 수 있었고 그들의 역량에 따라 프로젝트의 실패 유무가 잇따랐다.

사람들은 어떻게 하면 더 예술적이고 효율적으로 시스템을 개발할 수 있을지 고심했고 더 나은 시스템 아키텍처가 있으면 감탄했고 박수를 보냈다. 그러나 시간이 흘러가면서 사람들은 그것이 얼마나 위험천만한 일이고 고비용이 들어가는 일인지를 깨달았고 개발자와 아키텍트가 선별하고 고심해야 했던 아키텍처 요소들을 대신 처리해줄 수 있는 여러 컴포넌트와 미들웨어 제품들을 사용하기 시작했다. 이러한 선택은 웹 시스템 개발에 들어가는 인력과 시간을 줄여주는 듯해 보였고, 점차 순수한 소프트웨어 아키텍트는 손가락을 빨게 됐다. 이제 개발자가 하는 일이라고는 웹 화면의 단순한 인터페이스 노가다이거나 단순 로직에 대한 작업 등을 벗어나지 못했고 이러한 단순 노가다만으로도, 별다른 수고없이 보안이나 성능, 트랜잭션, 확장성 등이 어느 정도 이상 충족되어 가고 있었다. 결국 개발자가 작업한 내용은 전체 시스템에서 보자면 빙산의 일각이었고 눈에 보이는 소스코드 이면에는 그것들에 대한 아키텍처 요건들을 처리해주는 수많은 컴포넌트와 미들웨어 제품들이 얽혀있는 상황이 된 것이다.

문제는 여기에서 발생한다. 웹 시스템에 버그가 발생했을 때 이제는 개발자 한 두 사람이 분석해서 원인을 파악하는 것이 불가능해질 정도로 종합적인 문제 분석 능력이 필요해진 것이다. 때문에 웹 시스템에 버그가 발견되면 해당 사이트에 하드웨어 전문가와 네트워크 전문가, DB전문가, 미들웨어 전문가, 개별 컴포넌트 제품 전문가, 개발자, 운영자 등이 모여서 어디서 문제가 발생한 것인지를 종합적으로 분석해야 하는 상황이 발생하는 경우가 다반사가 되었다. 그래서 이 장애 전문 해결사로서 버그 사냥꾼이라는 직종이 탄생하게 되었다.

버그 사냥꾼 중에서도 특히 미들웨어 전문가의 역할이 매우 중요하게 되었는데, 거의 모든 문제가 발생하는 첫 번째 장소이자 시작 시점으로 거론되는 곳이 바로 이 미들웨어 쪽이기 때문이다. 즉 과거에는 개발로서 해결하던 여러 가지 요소들이 미들웨어 쪽에서 처리되면서 크리티컬한 부분에서의 버그 역시 미들웨어가 처리하게 되었다. 때문에 미들웨어 쪽 버그 사냥꾼의 지식 체계는 넓고 깊다. 왜냐하면 실제로는 하드웨어나 네트워크에 문제가 있어도 일단은 미들웨어에서 문제가 감지되고 소스코드 상에서 버그가 있어도 미들웨어에서 발견할 수 있다. 성능이 문제여도 미들웨어 쪽에서 전체적인 분석을 해야 하는 상황이다 보니 미들웨어 쪽 버그 사냥꾼은 만물박사가 되지 않을 수가 없다. 그들은 때때로 성능이나 개발에 대한 작은 컨설팅까지 해가며 웹 시민들의 안녕을 위해 고군분투하고 있다.

버그 사냥꾼 스파이크
그래서 이번 기사에서는 버그 사냥꾼 스파이크씨를 소개할까 한다. 그는 모 회사에서 판매하고 있는 웹 애플리케이션 서버 제품에 대한 기술지원을 담당하고 있는 경력 5년의 버그 사냥꾼이다. 그가 주로 하는 일은 회사가 판매하고 있는 제품을 구매해서 쓰고 있는 고객들이 개발이나 운영 중에 제품에 문제가 발생했을 때 문제를 해결해주는 것이다. 그러나 웹 애플리케이션 서버라는 것이 위로는 사용자의 요청을 받아서 일차적으로 처리하는 웹 애플리케이션과 맞닿아 있고 아래로는 DB나 네트워크, 하드웨어, Legacy 등의 리소스와 연결되어 있다보니 일단 고객이 뭔가 서비스가 되지 않으면 무조건 스파이크씨를 부른다. 그러면 스파이크씨는 전체 시스템을 모니터링하면서 문제의 원인을 분석하고 고객에게 해결책을 알려주는 것이다. 이런 그에게 최근 웹 시스템에서 발생하는 버그의 유형에 대해 의견을 물어보았다.

버그요? 말도 마세요. 버그 같은 버그, 정말 웹 애플리케이션 서버에 문제가 있어서 생기는 버그면 말도 안하죠. 미들웨어라는 게 눈에 보이지는 않으면서 하는 일은 무진장 많으니까 걸핏하면 저를 호출하는데요, 사실 일어나는 문제 중의 상당수는 개발 쪽이나 DB 그리고 서버에서 생기는 문제예요. 사이징을 제대로 하지 못해서 생기는 경우도 많죠. 그래도 일단 에러 로그는 웹 애플리케이션 서버 쪽에서 나오니까 일단 고객은 저를 부르는 거에요. 그런데 사실 요새에는 개발 쪽에서 생기는 버그도 많질 않아요. 워낙에 개발자들의 능력도 좋아졌지만 개발자들이 웹 개발에서 해볼만한 게 없거든요. 대부분의 중요한 로직들은 웹 애플리케이션이 해결해주니까 단순한 버그는 많지 않은거죠. 다들 버그, 버그 하지만 요새처럼 버그 잡기 어려운 시절이 어디 있겠어요? 버그 잡는 거 쉬운 노릇이 아니거든요. 하드웨어부터 개발까지 IT 지식 전반적인 것들을 다 알아야만 버그를 잡을 수가 있는거죠. 아무나 버그 사냥꾼 하는거 아니거든요.

횡설수설하는 스파이크씨의 인터뷰를 통해서 그가 얼마나 쌓여있는 할 말이 많은지 알 수가 있다. 버그 사냥꾼의 입장에서 과연 최근의 웹 기반 시스템에서 발생하는 버그의 유형은 어떠한 것들이 있는지 살펴보자.

버그의 종류
스파게티 코드와 리소스에 대한 정확한 사용
세상이 많이 변하고 변했지만 아직까지도 이런 허접한 코드를 보면 왕짜증이죠. 개인 홈페이지 만드는 것도 아니고 명색이 대기업 홈페이지라고 해서 들어가 보았더니 JSP 코드에 DB 호출하려고 JNDI 룩업해서 직접 DB랑 쿵작쿵작하는 걸 박아놓고 있더라구요. 정말 한숨부터 나옵니다. 그래도 좀 안다 하는 운영자분들은 미안해하기라도 하지요. 요즘 웹 개발에서 그나마 전체 시스템을 망가뜨릴 수 있는 이슈는 리소스 관리에요. 예를 들어 개발자가 코딩하면서 DB 리소스만 공손하게 사용해준다면 웹 애플리케이션에서 생기는 버그의 반 이상은 방지할수 있을 거예요. 그런데 JSP 코드에 로직과 뷰가 분리되기는커녕 오묘한 조화로 손잡고 있으면 정말 버그 잡기도 힘들 뿐더러 리소스에 대한 반환이 제대로 되는지 파악조차 사실 잘 안 되거든요. 확장성에도 문제가 있고. 아무튼 이런 구석기 시대코드는저질버그를양산하는창고같은역할을하는거죠.

스파이크씨도 과거에는 웹 개발자였다. 특히 그는 php 전문 개발자였는데 초짜시절에 그 역시 php로 무수한 스파게티 코드를 작성한 경험이 있다. 자유로운 php라는 언어의 특성상 개발 속도가 빨랐고 단시일 내에 원하는 사이트를 개발하는 것은 어렵지 않았지만, 초짜시절 그는 지인을 통해 아르바이트로 자그마한 컴퓨터 회사의 홈페이지를 php로 개발하게 되었다. 하루가 지나니 게시판이 생기고 또 하루 지나니 견적 페이지가 만들어졌다. 그렇게 후다닥 만들어진 홈페이지는 고객과 홈페이지 주인의 원망을 듣는 버그 투성이 사이트로 전락해버렸다. 객체지향이고 뭐고 없이 생각나는 대로 만들어진 스파게티 코드는 나중에 다시 고쳐보려 해도 어찌할 수 없을 만큼 복잡해진 말썽꾸러기가 되어버리고 만 것이다. 그러나 이런 사례는 사실 요 근래에는 많이 찾아볼 수 없거나 혹은 이러한 로직과 뷰의 분리가 완전히 되어 있지는 않더라도 중요한 비즈니스 로직 정도는 컴포넌트화 시켜놓는 것이 요 근래의 추세이다. 이것은 그동안 웹 기반 개발자들이 양적으로 뿐만 아니라 질적으로도 많은 향상을 보여왔음을 뜻하는 것이다.

스파게티 코드와 함께 웹 기반 시스템에서 웹 개발자가 실수하는 것들 중의 하나가 리소스에 대한 해제를 제대로 해주지 않아서 전체 시스템에 무리가 가게 만든다는 것이다. 또한 서블릿 사용시 쓰레드 기반 프로그래밍에 익숙하지 않은 개발자가 리소스 변수에 대한 잘못된 사용으로 인해 부하를 일으키는 경우도 종종 있는 일이다. 사실 이러한 현상은 무조건 개발자의 탓으로만 돌릴 것이 아니라 문제가 될 만한 소지가 있는 부분들을 미연에 방지할 수 있도록 별도의 공통 컴포넌트로 끄집어내서 통합관리를 하는 등의 개발 환경을 구축해 놓아야만 해결될 수 있을 것이다.

몇 달 전 스파이크씨가 고객의 요청으로 들어간 사이트에서 있었던 일이다. 평소에는 이상 없이 잘 돌아가던 시스템이 부하가 어느 정도 쌓이면 갑자기 행(hang) 현상이 발생하면서 웹 애플리케이션 서버가 죽어버렸다. 늘 있어왔던 현상이고 이런 경우 대부분 애플리케이션에서 리소스 관리를 제대로 하지 못했기 때문에 발생하는 경우가 다반사였다. 역시나 문제는 애플리케이션 쪽이었다. 각각의 JSP 코드에서 직접 DB 리소스를 가져와서 함부로 썼던 것이다. 즉 그 수많은 JSP 코드에서 직접 DB를 연결하여 필요한 작업을 수행하고서는 때때로 연결을 닫지 않기도 하고 예외처리도 엉성하게 되어 있었다. 더구나 JSP 코드는 로직과 뷰가 전혀 분리되지 않은 상태이다보니 문제를 해결하는것도 어렵기 그지없었다. 천상 스파이크씨는 고객에게 애플리케이션에서 DB 리소스 해제를 제대로 해주지 않은 것이 문제여서 발생한 것임을 보고했고, 되도록이면 DB 제어에 대한 부분은 기업 공통 컴포넌트를 작성하여 그것을 전사적으로 사용할 것을 권했다. 또한 웹 개발자들에게 좀 더 좋은 교육의 기회를 제공하여 웹 프레임워크나 기타 기업 내의 프레임워크 등에 대한 가이드라인을 다시 한 번 제시할 것을 권고했다.

이러한 스파게티 코드와 정확치 않은 리소스 사용으로 인한 버그는 많이 발생하기도 하지만 문제의 원인이 분명한 만큼 스파이크씨가 짜증내는 일면 쉽게 해결할 수 있는 범위에 속한다는 측면에서 반가운 현상이기도 하다. 하지만 스파이크씨가 다음으로 언급하는 여러 상황들은 스파이크씨에게도 참으로 버거운 버그들, 고급 버그들이다.

시스템 및 프레임워크에 대한 이해 부족
생각있는 운영자들이 가장 꺼려하는 것 중의 하나가 무엇인지 아세요? 최신 기술입네 하고 무턱대고 개발자들이 인기있는 오픈소스 프레임워크를 도입해서 써버리는 경우에요. 문제는 그 프레임워크가 얼마나 신뢰할만 하냐는 거죠. 그 프레임워크를 썼는데 막상 운영하고 보니 치명적인 문제가 발생하면 대체 누구에게 하소연하겠습니까? 개발자는 그제서야 부랴부랴 오픈소스를 뜯어고치거나 이미 어디론가 회사를 옮겨버린 후란 말이죠. 게다가 무턱대고 프레임워크를 도입해버리면 그 프레임워크를 알고 있는 개발자는 어떻게든 문제를 해결한다하더라도 향후 업그레이드나 확장을 해야 할 시점이 왔을 때 생소한 프레임워크 때문에 개발에 드는 비용보다 프레임워크를 이해하는 데 드는 비용이 더 커져버린다 이겁니다. 저도 지원을 하다보면 이렇게 프레임워크에서 문제가 발생한 경우에는 어떻게 손을 쓸 수가 없어요. 그 프레임워크를 들어내라고 할수도 없고 말이죠. 게다가 프레임워크의 철학을 제대로 이해하지도 못하고 써버리면 문제는 아주 골치아파지는 거죠.

자바 엔터프라이즈 기술 중 EJB는 상당히 성공한 컴포넌트 기반의 기술이다. 수많은 서적에서 EJB를 다루었고 마치 JEE의 수준 높은 개발을 이루려면 EJB를 써야 하는 것처럼 보이기도 한다. EJB는 결국 웹 기반 서비스에서 트랜잭션과 분산처리가 꼭 필요한 요소가 있을 때 그러한 위험을 대신 처리해주기 위해 탄생했다. 물론 비즈니스 로직에 대하여 EJB로 만들어두고 추후 두고두고 쓰겠다고 마음먹겠다면, 그리고 EJB라는 좋은 프레임워크 안에서 개발을 하겠다는데 말릴 사람은 아무도 없을 것이다.

그러나 EJB를 통해서 얻을 수 있는 것이 있다면 반대로 잃는 것이 있게 마련이다. 우선 속도의 문제를 들을 수 있다. RMI Call을 통한 분산 컴포넌트 기술이다보니 아무래도 직접 메쏘드 호출에 드는 비용보다 많을 수밖에 없다. 또한 EJB 기술을 충분하게 숙지하지 않은 개발자일 경우 잘못된 설계와 사용으로 인하여 오히려 사용 안하느니만 못한 결과를 종종 가져올 수 있다. 왜냐하면 EJB는 성숙한 JEE 기반의 설계 지식을 바탕으로 개발되었을 때 그 기능을 십분 발휘할 수 있는 것이지, 비즈니스 로직과 도메인 로직에 대한 분리 개념 없이 접근했다가는 큰코 다칠 기술이기 때문인 것이다. 이런 이유로 가뜩이나 무거운 JEE 환경에서 EJB 호출이 너무나 빈번히 발생하여 전체 시스템에 오버헤드가 일어나는 경우 그 결과는 느려진 서비스와 고비용으로 귀결될 뿐이다.

재차 강조하자면 앞에서도 언급했듯이 웹 기반 시스템에서의 버그가 점점 개별적인 소스코드에서 프레임워크나 전체 시스템단으로 옮겨오는 추세이다. 때문에 전체 시스템과 도입된 프레임워크에 대한 충분한 이해 없이 개발된 시스템은 결국 버그를 양산해낸다. 그 중에서도 프레임워크에 따른 폐해는 정말 심각하다. 문제는 해당 프레임워크가 검증되지 않았다는 것과 프로젝트에 참여하는 개발자 전원이 프레임워크에 대한 이해가 충분하느냐에 있다. 소프트웨어는 단지 바이너리 데이터 덩어리만을 의미하지는 않는다. 소프트웨어에는 고객이 있고 개발 프로세스가 있고 문서가 있으며 유지보수에 따른 절차가 포함된다. 이러한 소프트웨어의 필요충분조건을 무시하고 신뢰성에 대한 검증과 유지보수에 대한 확실한 책임 소지를 분명히 하지 않을 경우 어줍잖은 프레임워크 도입은 오히려 더 큰 버그를 양산하는 요소가 된다.

충분한 테스트 없이 운영
요새 프로젝트를 보면 개발에 걸리는 시간보다는 테스트에 걸리는 시간이 훨씬 많이 소요되고 그 중요성이 증대되고 있는것 같아요. 그만큼 운영 환경에서의 검증작업을 확실하게 한다는 얘긴데요. 그럼에도 불구하고 평상시에는 잘 돌아가던 것들이 운영 때만 되면 꼭 문제가 일어나요. 테스트할 때 제대로 운영 환경에 맞추어 시나리오를 구성하지 못했다는 것이고 운영 환경을 제대로 예측하지 못한 결과이기도 하죠.

지금도 여전히 스파이크씨는 운영 하루 만에 시스템이 정지된 고객의 현장에 출동하느라 여념이 없다. 그만큼 운영과 테스트는 다르다는 것을 입증하는 것이리라. 또한 이것은 단순히 운영과 테스트가 다르기 때문에 일어나는 당연한 현상이라고 넘겨버리기에는 아쉬운 무언가가 있다. 즉, 고객이 테스트의 중요성을 제대로 인식하지 못한 경우에 발생한다는 것이다.

며칠 전 스파이크씨는 고객의 신규 오픈 사이트 통합 테스트 현장에 출동했다. 테스트 중 웹 애플리케이션 서버에서 문제가 발생했을 때를 대비하여 같이 모니터링을 요청한 것이다. 테스트 현장에는 몇 명의 애플리케이션 개발자와 운영자 그리고 부하테스트 전문가들이 모여 있었다. 늦은 밤 시간이었고 개발자들은 하나같이 초췌함 일색이었다. 저녁 9시에 성능 테스트가 시작됐다. 그런데 테스트는 단 30분도 더 진행시킬 수가 없었다.왜냐하면 애플리케이션에서 버그가 발생했기 때문이었다!

스파이크씨는 황당했다. 분명 그 통합 테스트는 성능 테스트였다. 그렇다면 적어도 한번쯤은 애플리케이션에 대한 단위 테스트 정도는 해보았을 것이 아닌가? 스파이크씨가 개발자에게 물어보니 단 한번도 애플리케이션에 대한 통합 테스트를 이전까지 진행해본 적이 없다고 한다. 결국 그 날의 테스트 현장은 파장되었고 개발자는 성능 테스트에서 발생하여 접수된 버그를 해결하기 위해 밤을 샜다.

통합 테스트는 운영 테스트와 성능 테스트로 분류할 수 있고 이러한 통합 테스트 이전에 각각의 애플리케이션들에 대한 충분한 단위 테스트와 애플리케이션 별 통합 테스트가 선행되어야만 한다. 그런데 이러한 순차적인 과정을 무시하고 오픈이 얼마 남지도 않은 시점에서 개별 애플리케이션들에 대한 기본적인 버그조차 해결되지 않은 상황에서 성능 테스트한답시고 밤을 새워가며 애플리케이션 성능이 나오지 않음을 탓하는 경우를 스파이크씨는 가끔 목격하곤 한다. 테스트는 아무리 강조해도 지나치지 않으며 테스트 기간 산정은 시스템의 신뢰성을 가름하는 가장 중요한 잣대가 될 수도 있다.

제품에 문제가 있는 경우
버그 중에 저 같은 버그 사냥꾼들이 가장 무서워하는 것이 제품 버그죠. 새 버전의 웹 애플리케이션 서버가 출시되면 일단 처음에 겁부터 나요. 이번엔 어떤 버그가 있을까? 하구요. 제가 담당하고 있는 제품이 그래도 이 바닥에서는 유명하고 검증받은 제품인데도 가끔씩 황당한 버그를 발견하곤 하거든요. 세상에 버그없는 소프트웨어가 어디 있겠어요? 하지만 특히 웹 애플리케이션 서버 버그는 찾기도 어렵고 치명적인 경우가 많아서 신경이 많이 쓰이죠. 보통 문제가 발생한 사이트에 나가면 문제의 원인이 어디에 있는지 추적해 들어가는데, 전체 IT 인프라부터 개별 애플리케이션까지 다 추적해보거든요. 그런데 결국 추적의 방향이 웹 애플리케이션 서버 자체의 결함으로 결론지어지면 고객에게 할 말이 곤궁해져요. 금방 고칠 수 있는 거면 고치지만 제가 개발한 것도 아니다보니 시간이 길어질 수밖에 없어요. 아무튼 이런 경우 입이 바짝 바짝 마릅니다.

보통 고객에게 제품을 판매하기 전에 정말 이 제품이 제 성능을 발휘하는 지를 보여주기 위해 때때로 벤치마크 테스트를 고객이 보는 앞에서 시연하는 경우가 있다. 스파이크씨는 몇 달 전 고객에게 웹 애플리케이션 서버의 성능을 보여주기 위해 벤치마크 테스트에 참여했다. 테스트는 클러스터링된 환경에서 여러가지 패일오버(Failover)와 세션 클러스터링 그리고 고객의 샘플 애플리케이션에 대한 성능 테스트였다. 웹 애플리케이션 서버에서 클러스터링 기능은 가장 기본이 되는 기능이기 때문에 비록 새 버전의 제품이기는 하지만 결국 같은 제품 라인이므로 스파이크씨는 큰 무리없이 테스트가 진행되리라 생각했다.

그러나 이후 엄청 황당한 경험을 해야 했다. 클러스터링으로 묶여있는 서버군 중 하나의 서버를 임의로 중지시키고 다시 가동시켰더니 나머지 다른 하나의 서버가 죽어버리는 현상이 발생한 것이다. 아마도 세션 정보를 서로 공유하다가 무언가가 꼬여버린 것 같은데 전날 테스트할 때에는 아무런 문제가 없다가 특정 상황에서 그것도 하필 고객이 바로 옆에 있는 그 상황, 너무나 중요한 그 상황에서 제품은‘엿 먹으라는 듯’버그를 발생시키고 만 것이다. 스파이크 씨를 비롯한 회사의 모든 사람들의 얼굴은 흙빛이 되었고 그 날 테스트는 그것으로 끝이 났다. 그 이후로 스파이크씨는 밤새도록 제품 개발자와 문제를 재현하여 해결하는데 많은 시간을 들였고 결국 단순히 하나의 클래스를 교체함으로써 더 이상 해당 버그는 발생하지 않았다.

앞서 언급한 것처럼 웹 시스템 개발자가 담당하는 역할 상 리소스에 대한 제대로 된 사용만 철저히 한다면 전체 시스템에 걸쳐 영향을 미칠 수 있을만한 여지가 적은 반면에 미들웨어에서 상대적으로 처리해주는 기능이 많아지다 보니 만약에 이러한 미들웨어가 부실한 신뢰성을 가진다면 그 파급 효과는 상당한 것이다. 때문에 미들웨어를 선택할 때에는 신뢰할만한지 지원은 얼마나 철저한지를 제대로 점검해보지 않으면 두고두고 전체 IT 인프라를 좀먹을 수 있는‘악의 근원’이 될 소지가 있다.

나무를 보지 말고 숲을 보자
가장 황당한 버그는, 사실 이건 버그도 아닌데요. 사람들은 문제가 발생하면 아무래도 시야가 좁아지죠. 개발자는 소스에 이상이 없는지만 살피게 되고 운영자는 운영 환경만 살펴보게 되죠. 그런데 문제는 정말 엉뚱하게도 너무나 당연하게 생각했던 부분에서 해결되는 경우가 많아요. 이를테면 네트워크 선이 뽑아져 있었다든지, DB 서버가 잠시 죽어있었다든지 우리가 평소에 당연히 되리라고 믿어 의심치 않는 요소들이 문제여서문제 상황이 지체되는 경우가 심심치 않게 일어나죠. 그래서 가끔 지원나갔다가 랜선 뽑아져 있던거 연결해주거나 시스템만 한 번 껐다 켜주고 돌아오는 경우가 의외로 많지요. 이런 상황이 있으니 저처럼 미들웨어 쪽 기술 지원하는 사람이 만능박사가 될 수밖에 없는 거죠. 일도 많지만 그만큼 전체 시스템을 보게 되는 힘을 기를 수 있어서 즐겁습니다.

어느 중요한 고객으로부터 스파이크씨에게 연락이 왔다. 엄청나게 성능 좋은 서버를 도입해서 프로젝트를 진행하고 오픈이 얼마 남지 않았는데 성능이 제대로 나오질 않아서 난리가 났다고 한다. 허접한 오픈소스 제품으로 돌릴 때만도 못한 성능이 나오니 이것은 분명 스파이크씨가 담당한 제품의 문제이고 이것을 해결하지 못하면 앞으로 장사 못할 줄 알아라고 말한다. 다급한 스파이크씨 곧장 고객에게 달려간다.

실제로 문제 상황을 보니 같은 웹 애플리케이션을 실행하는데 유독 스파이크씨가 담당한 제품에서만 느린 것을 확인했다. 스파이크씨는 당연히 제품만의 문제로 규정하고 제품의 버그를 찾기 시작했다. 애플리케이션의 알고리즘을 바꿔보기도 하고 버그 리스트를 찾아보기도 했으며 다른 서버 환경에서의 차이점도 분석해보았다. 그러기를 며칠, 결론은 제품의 문제인 것 같기는 하지만 다른 서버에서는 전혀 발생하지 않는 문제라는 것이다. 결국 문제는 고객이 최신 기종이랍시고 들여온 서버에 문제가 있음을 검증하는 단계에 이르렀고 스파이크씨가 며칠 동안을 애써가며 웹 애플리케이션 서버안의 문제를 파헤쳤던 수고는 공염불이 돼버렸다. 즉, 애초에 스파이크씨가 문제의 원인을 좀 더 다각도로 바라보았다면 일찍 서버에 문제가 있었음을 간파할 수있었을 것이며 상황은 훨씬 빨리 종결될 수 있었을 것임에도 불구하고 고정관념에 사로잡혀 하나의 포인트만을 바라보다 보면 숲을 보지 못하는 결과가 생길 수 있음을, 즉 문제는 의외로 다양한 곳에서 복합적으로 일어날 수 있음을 간과한 결과라고 할 수 있겠다.

이렇게 숲을 보지 못해서 쉽게 해결할 수도 있는 문제가 오래동안 여러 사람의 밤잠을 설치게 하는 경우는 스파이크씨에게 비일비재하다. 밤늦게 전화가 온다. 급하게 어느 사이트에서 장애가 발생했는데 웹 애플리케이션 서버 쪽 문제인 것 같다. 그러니 빨리 와 달라. 그래서 찾아간 고객의 사이트에서 스파이크씨가 한 일이라고는 고작 랜 선 꽂아주고 라우터 한 번 껐다 켜준 일 밖에 없을 때 고객과 스파이크씨는 서로 얼마나 X씹은 얼굴일지 상상해보라. 그러니 문제가 발생했을 때에는 일단은 먼저 숲을 바라봐야 한다. 숲을 바라본 다음에 우리가 가진, 문제의 원인일 것이라고 생각하는 고정관념을 배제한 상태에서 문제의 원인을 추적해 들어가는 것. 그것이 웹 기반 시스템에서 문제를 접하는, 스파이크씨가 권하는 방법론이다.

웹 기반 시스템 버그 해결 프로세스
앞서 버그 사냥꾼 스파이크씨의 경험을 토대로 웹 기반 하의 시스템에서 어떠한 버그들이 있는지 사례별로 살펴보았다. 스파이크씨의 말처럼 웹 기반에서의 시스템이 일으키는 버그는 여타 다른 아키텍처에 비하여 상당히 복합적이고 다층적인 관점에서 문제 해결 능력을 필요로 한다는 것을 여실히 느낄 수 있을 것으로 생각한다.

<그림 1> 웹 기반 시스템 버그 해결 프로세스

여기서 짚고 넘어가야 할 것은 어느 문제 상황에서나 스파이크씨처럼 다양한 문제 해결 경험을 가진 이가 여러분 곁에 있을수는 없다는 것이다. 버그는 사람을 가리지 않고, 오히려 상황이 다급하고 주위에 전문가가 없을 때 더 잘 나타난다. 그게 버그의 습성이다. 따라서 필자는 스파이크씨에게 과연 웹 기반 시스템에서 버그를 해결하기 위한 방법론은 없겠는가 물어보았다. 스파이크씨는 비록 웹 기반 시스템이 복합적인 성격을 가지고 다양한 지식과 경험을 가진 이의 분석을 필요로 하는 것은 맞지만 그럼에도 불구하고 어느 정도의 수준을 가진 개발자 내지 운영자가 문제를 해결하는 데 있어 쉽게 접근해 볼 만한 방법론을 제시했다.

어디서 시작할까?
문제가 발생하고 버그가 예상되었을 때 디버깅을 하기 이전에 먼저 전체 웹 시스템이 어떻게 운영되는지를 점검해볼 필요가 있다. 만약 시스템 아키텍처에 대한 간략한 구성도가 있다면 그것을 보면서 점검해보면 좋을 것이다. 과연 아키텍처 각각의 구성원들이 서로 어떻게 연결되어 있는지를 살펴보자. 웹을 구성하고 있는 아키텍처 상에는 생각보다 상당히 많은 구성원들과 리소스 그리고 메시지 프로토콜로 이루어져 있는 것을 알아챌 수 있으며 이와 관련하여 당신이 운영자가 아니라면 운영자와 대화를 통해 각 구성상의 취약점은 없었는지 그리고 최근에 벌어졌던 다른 문제 상황과 변경된 사항들을 먼저 수집해 나가야 한다.

던져야 할 질문들
넓고 넓은 시스템 아키텍처 중에서 가장 먼저 살펴봐야 할 그 곳은 어디일까? 그 곳을 찾는 것이 문제 분석의 첫걸음이다. 이 결정을 위해 몇 가지 간단한 질문을 스스로에게 던져보아야 한다. 첫 번째로 이 문제의 증상은 무엇인가? 만약 에러 메시지가 클라이언트 브라우저에서 발생한 것이라면 아무래도 클라이언트와 맞물려 있는 여러 구성요소들을 의심해 볼 만할 것이다. 아니면 특정 프로세스가 죽거나 행 현상이 발생했다면 이것 역시 가장 먼저 살펴 볼 그 곳을 결정하는 데 중요한 단서가 된다. 물론 해당 프로세스가 죽거나 행 현상이 발생했다면 다음 절차는 해당 프로세스에 대한 행동을 기록하고 있던 로그 파일을 보는 행위가 될 것이 명백하다.

두 번째로 가져야 할 질문은‘언제 해당 증상이 발생하는가?’이다. 발생하는 시간과 발생하는 주기 등이 문제의 본질에 대해 이해하는 데 매우 중요한 단서가 된다. 예를 들어 사용자가‘계정 정보’페이지를 클릭할 때면 무조건 에러 메시지가 출력된다면 너무나 당연하게도‘계정 정보’와 관련된 소스코드를 먼저 볼것이다. 반면에 사용자 트래픽이 매우 높을 때에만 발생하는 현상이라면 무언가 시스템 리소스와 관련이 있는 문제라는 것을 직감할 수 있을 것이다. 반면에 아무런 시기적인 유사성이 없는 상황에서 발생하는 문제라면 이 문제에 제3의 구성원의 개입이 있을 수 있거나 좀 더 시간과 상황에 따른 유사성을 발견해내야할 것이다. 하지만 이렇게 간헐적으로 발생하는 문제가 가장 해결하기 어려운 문제임은 확실하므로 단단히 긴장해야 한다.

세 번째로 가져야 할 질문은‘최근에 시스템 변경사항은 무엇이었는가?’이다. 최근에 애플리케이션 혹은 시스템에 변경 사항은 없었는가? 무언가가 변경이 되었다면 그것이 원인이 되어 발생한 문제 혹은 버그임을 우선 의심할 수 있을 것이다.

버그를 고립시키기
쥐를 잡아본 적이 있는가? 쥐를 잡으려면 일단 쥐가 어디에 숨어있는지를 알아야 하고 위치를 알았다면 적절한 도구로 쥐를 야금야금 몰아가야 한다. 자 이제 어디에 버그가 숨어있는지를 눈치 챘다면 적절한 도구로 버그 사냥에 들어간다.

디버깅 툴
웹 기반 시스템에서 발생한 버그라는 것이 대부분 런타임 환경에서 발생하는 경우가 많기 때문에 디버깅하기가 상당히 까다롭기는 해도 요즘 출시되고 있는 각종 개발 툴에서는 런타임에서의 디버깅 환경이 꽤 유용할 만큼의 환경을 제공해준다. 그럼에도 불구하고 디버깅 툴에는 어느 정도 한계가 있다. 그 첫 번째가 운영환경에서의 버그일 경우 디버깅 툴로서는 잡아내는 게 여의치 않다는 것이다. 이를테면 사용자 접속이 얼마 이상일 때 발생하는 버그일 경우 주로 객체와 메시지 자체에 대한 정보만을 바라볼 수 있는 디버깅 툴만으로는 현상 파악에 무리가 있는 것이다. 따라서 자세한 정보를 위해서라면 한 손에는 디버깅 툴을 그리고 다른 손에는 또 다른 유용한 툴을 지니고 있어야 한다.

로그 파일
거의 대부분의 프레임워크와 미들웨어 및 리소스 관리 툴에서는 로그 파일을 남긴다. 때때로 특정 제품의 경우 성능 등의 이유로 최소한의 로그만을 남기는 경우가 있는데 대부분 로깅 수준을 조절하여 더 세밀한 정보를 볼 수가 있다. 로그 파일에는 단순히 각각의 서버가 제공하여 주는 것들 이외에도 JVM이나 네트워크스위치 등이 제공해줄 수 있는 파일(쓰레드 덤프와 힙 덤프 등)들도 있다. 이 뿐만 아니라 문제가 발생하고 있는 부분에 대한 자세한 추적을 위한 로그를 별도로 추가함으로써 문제의 원인을 좀 더 막다른 골목으로 좁혀볼 수 있을 것이다. 따라서 전체 시스템 아키텍처 구성도를 바탕으로 해서 하나라도 빠짐없이 로그파일을 챙기는 것이 문제 원인을 해결할 수 있는 지름길이다.

모니터링 툴
요즘 출시되고 있는 DB 서버나 웹 애플리케이션 서버, 웹 서버,메시징 엔진 제품 등은 더 편리한 관리 환경을 위해 비주얼한 형태의 모니터링 툴을 제공하여 자원의 상태 등을 파악하고 런타임 환경이 제대로 운영 중인지 파악하는 데 많은 도움을 주고 있다. 또한 이러한 적절한 툴이 없다 할지라도 간단한 스크립트를 이용하여 서버 상황을 이해하는 데 기본이 되는 여러 가지 정보를 추출하는 것이 가능하다. 이를테면 네트워크 연결 수나 DB 연결수 그리고 CPU와 메모리 활용 상태 등은 간단한 스크립트로도 추출하는 것이 가능하다. 이러한 툴을 쓰는데 인색하지 말라.

숙련된 버그 사냥꾼이 필요하다
이제까지 버그 사냥꾼 스파이크씨의 경험을 토대로 웹 환경에서의 버그의 유형과 이러한 버그를 잡아내는 대략적인 방법론에 대한 이야기를 들어보았다. 우리는 흔히 버그 없는 소프트웨어는 없다고 하고 단 백 줄도 안되는 소스코드에서도 얼마든지 버그는 존재한다고 한다. 그만큼 개발자에게 있어 버그는 여름철의 모기처럼 평생을 따라다니는 숙명과도 같은 존재다. 그럼에도 불구하고 웹 기반 시스템은 날이 갈수록 그 복잡도를 더해가서 하나의 웹 사이트 안에 포함되어 있는 프레임워크나 미들웨어 제품 그리고 각종 부가적인 서버들의 종류가 점점 더 다양해져가고 있다.

이는 곧 웹 기반 시스템이 점점 더 단순한 개발자로서의 능력보다는 전체 시스템에 대한 안목과 다양한 경험을 아우르는 능력을 가진 인력을 더 필요로 함을 반증하는 것이기도 하다는 생각이다. 때문에 이렇게 복잡해져가는 시스템에 대한 문제 해결 능력을 기르는 것은 개발 본연의 경험과 함께 매우 중요한 능력이라 생각하며 본 기사를 통해 더 깊은 웹 기반 시스템 문제 분석가의 길에 매력을 느끼는 독자들이 많아지면 바랄 것이 없겠다.

* 이 기사는 ZDNet Korea의 제휴매체인 마이크로소프트웨어에 게재된 내용입니다.
Posted by SB패밀리