-
Notifications
You must be signed in to change notification settings - Fork 10
/
0216.txt
223 lines (223 loc) · 16.2 KB
/
0216.txt
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
26
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
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
오늘은 이제 저희가 그런 얘기 하잖아요 건물을 지으시는 분들이 이제
설계사 모아 키텍 이런 식으로 얘길 해요
그리고 이제 우린 소프트웨어 설계 아는 사람은 소프트웨어 앞이 텍 이라고
하죠
물로 이제 큰 회사에 가면 은 아키 탱 말하시는 분들이 있고 코딩은 전혀
안하시는 분들이 있죠
그냥 그분들은 코딩을 하면서 테스트해보고 이런건 하죠 근데 이제
결과적으로는 이렇게 전체적인 수첩 잡아주고
2 다른 모듈과 다른 컴퓨터 어떻게 서로 통신하는 얘기하고
api 정의해 주고 뭐 기타등등 을 하죠
이제
사람들 그런 얘길 많이 했어 옛날부터 제모 우리가 소프트웨어 늦어서 이가
소프트웨어 엔지니어 라고 부르 잖아요 근데 실제 엔지니어링 하시는 분들은
보급이 웃어요
이제 그 엔지니어 기라고 하는 게 자체가 뭐냐면 굉장히 잘 정형화된
프로세스가 있죠 뭐 당연히 처음에 건물을 지을 때는 수도 없이 많이
무너져 있겠고
요즘은 건물을 다 누가 찍고 설계하고 뭐 한다 그럴 때 기본적으로 건물이
무너져 생각을 안 하잖아요
그 사람들이 다 계산하는 무슨 뭐 뭐
공대 가면 흐름 하더라구요 뭐라 그러지 이게
수학 중의 하나인데 제가 이름을 까먹었어요
칼 필러스 쪽인 것 같은데 몸이 문 적분 뭐 이런 비슷한 건데 이게 과연
어떻게 뭐 뭐 울리 하기도 하고
하중을 얼마나 받으면 이게 뭐 무너지고 그렇게 하중을 덜 받기에 뭐 이런
지군을 동그라미 원형으로 하면 좀 잘 버티고 뭐 이런 것들이 이미 전혀
화가 되어 있고 뭐 이제 시뮬레이션 도 많이하고
그래서 굉장히 정형화된 과정을 거쳐 단지 하는거고 이 사람들은 건물이
무너지면 사람이 죽기 때문에 그렇게 뭐 당연히 가끔 무너지지 만
일반적으로
건물을 지음 일단 무너지지 않는다는 확신을 가지고 시작하는 게 있어요
그래서 이제 그런 게 굉장히 정애가 되고 사람의 안전하고 관련된 거기
때문에 그런 상황에 왔는데
이제 저희는 소프트웨어 엔지니어링 이 그렇게 될 거다 라는 식으로 얘기를
많이 했어요 많은 사람들이
아 결론부터 말씀 드리면 안 그래요 그럴 수가 없는 이유가
이제 일부분에 소프트웨어 엔지니어링은 있어요 당연히 그런 사람의 목숨을
다루고 뭐 그런거 에서는 당연히 이런 올바른 아키텍트 해야되고 올바른
엔지니어링 해야되고 올바른 프로세서 거쳐야 되고 올바른 취업이 까지
거쳐야 되는 게 정상이죠
그 전에도 말씀 몇번이나 말씀드렸듯이 보인 4
아 뭐 메디칼 줘 이런 애들은 다 그래요 근데 대부분의 소프트웨어 직종
이라는게 사실 그 쪽 일이 아니에요 저희는 저희 시스템이 다운드 죽는
사람 맞고요
애매모호 서버가 다운의 도 오락을 못하고 돈이 잘 안 들어올 뿐인데
차라리 그게 평생 다운의 안되는걸 만들기 위해 애들의 천 배 시간을 갈아
넣느냐 아니면 1000배 인건비를 아끼고 가끔 1년에 하루 따라오는데
아냐 그럼 그러면 이제
1000배 한국보다 3배 아끼는 거잖아요
그 그런데 그 차이에요 사실은 그래서
오버 엔지니어링 1 많이 나온것도 그 거에요 이제 오버 엔진이 필요한
곳에서 아무리 오버 엔진으로 해독은 오버 엔진이 아니에요
걔네는 그래야 말하는 거고 그래 뭐 하는 거에요 근데 문제는 일반적인
소프트웨어 업계에서 일반적인 소프트웨어 분야에서는
내가 해서 돈을 1100 낭비하게 써 회삿돈을 근데 회사의 가져오는 것은
적당히 끝내고 그 상황에서 세상의 돈과 점에서 적당히 유지보수가 되는것과
유지보수가 안 되는 말이 안되죠
그 정도면 은 풀어 빛이 나고 회사도 버티고 제 식당도 이렇게 계속
가지고 올 수 있고 그의 정보에요
정말 사람들이 원하는 것도 완벽한 게 아니거든요
정말 완벽해야 된다면 아이폰 같은게 떨 수도 없구요 아이폰이 얼마나 큰
씨가 - 시작할 때 엔조이 떨 수가 없어요
사람들은 어느 정도의 실수가 나는거 그게 정말 아주 중요한 실수가 아닌
이상은
인정을 한다는 거에요 일단 그거를 이 해야되요
자기가 있는 분야 것 이냐 자기의 고객이 어디냐
요즘게임 하다가도 부족하면 게임 다운 되잖아요 하루중에 게임 하면 게임
카신 하잖아요
저처럼 게임 만들 때는 재 게임을 한다 를 눌러 도전에 큰 씨가 안날
정도로 게임을 만들어야 했거든요
어쩌면 그 때는 오버 엔진이 여행 이었죠 근데 그뒤에 게임이 큰 c
나면서부터
사람들이 큰 힘을 받아 들이는데 재미있는 것은 세이브로 잃어버리면 클래식
난 받아드려요 그래서 제일 중요하게 오토 세이브 기능이 나온 거야 그
다음부터 안 읽
오토 세이브 가 나오기 전에 세이브 포인트 좋죠 사람들이 클러치 날 때
되면서 미리 세이브를 해
그러다가 나중에는 오토세이버 다니까 세이브 할 필요가 없는 거예요
결국에는 5분전 정도만 읽는 일 잃어 버리는 거지
그때까지 풀어갈 수 있거든
ms 워드 똑같아요 ms 워드가 깜빡 나 줘 가끔 다운 돼요 근데 모이세
오오토리 커버링 자동을 뒤에서 오딧세이 하고 있다가 얻어 저번에 뻑
났는데 이거 리커버리 해갖고 다시 쓸래
한 5분정도 1척 그 얘기에요 사람들은 리커버리 가 되면 은 크게 완벽한
동작에 신경을 안 쓰게 되는게 대부분이에요 사실은 뭐 그 아우 리는
계속적 개판으로 만들어 되냐
이건 우리만 5개 파야 이냐 것도 아니에요 실제 우리 주변에 존재하는
온갖
그런 가구 라던가 이렇다 제품 하자가 있고 그걸 고쳐 쓰고 아니면 뭐
그게 아주 커다란 하자가 아내 이상은 목숨에 해직 해가 없고 와 주
심각한거 아니 서는 태충 고쳐 쓰고 받아들이지 않아요
그리고 말 그대로 소프트웨어 퀄리티가 그렇게 중요한 거였다
그러면 뭐 하드웨어 퀄리티 스터 중요하죠 크면 하드디스크 백업 이런게 왜
있어요 하드디스크가 뻑이 않으면 되는 거죠
* 과즙은 디텍트 란 거기다 있는 거거든요 어느 정도까지 유지 라고 어느
정도까지의 고객을 잃지 않고 어느 정도까지 해야
미친 듯한 그런 인건비를 쓰지 않느냐 며 저요
이게 왜 하느냐 결과적으론 소프트웨어 아키텍트 에 대해서 얘기하려고 해요
이제 빌딩 아키텍트 는 검 컨 축사 자기가 만드는 빌딩에 알만 알맞은
자제와 설계와 이런거 해요
그러면 자재비 가만히 되면 개는 토록 오빠 이러니까 빌딩은
아 보통 제 융자를 받아서 찍구요 용자 끝나고 분양하면서 돈을 벌고
끝나는 과정이 거든요 근데 내가 이렇게 팔 수 있는 건물을
10억을 들어서 만들었다면 그건 이미 망 거에요 그래서 이 사람들은 그게
확실히 해
그리고 그 4 그래서 932 돈을 많이 버는 거기도 하고 내가 일침 짜리
집을 짓는데
고층아파트 57 짜리 지는거 만큼 마음속에 g 빔 받고 이런 건 말이 안
되는 거야 사실상 누군가 그 돈을 주지 않는 이사
그래서 그게 빌딩 아키텍처는 아키텍트 는 자기의 필요에 맞은
일단 최소한의 품질이 되는거 와 거기 엑스트라를 놓았고 만드는게 아케
태교 먹어도 예쁜 디자인을 놓았고 그게 뭐 같이 기독교 자기 그것도
높인다면 은 크게 회사를 망하게 하지 않는 이상 아 또 하겠죠
소프트웨어 아키텍트 는 조금 이상해요
자기 직종에 대한 책임감이 없다 고전 봐요 뭐냐면
그럼 전부가 아니라 그런 분들이 있다고
저희가 이제 소프트웨어 아키텍트 이쪽에서 가끔 듣는 얘기 들을 있으면 뭐
학교 쪽이 나 아니면 무슨 뭐 정말 굉장히 야
대규모 에서 아키텍트 빡세게 는 회사
그런데 있잖아요 아까 자 보이며 맨날 내게 되는데 그런 수 절대 - 라면
안되는 건 내서 우린 아키텍트 이렇게 했고 우리는 이제 3일을 방지하게
일어났을 쫙 도입을 했다 그래요 그러면
좀 생각없는 소프트웨어 아키텍트 들은 아 저거 정말 대단한 거 뻔히
생각에 잇는거 정말 대단한것 하는거 맞아요 근데 자기 프로젝트가 국어가
필요가 없는데 그걸 도입하려고 하는 거예요
새로운 거니까 시도해 보고 싶고 또 괜히 멋져 보이고
그리고 프로그래머가 상당히 많은 수가 완벽주의자 들이 많거든요
정말 완벽해 보이거든 근데 중요한 건 은
그럼 뭐라 그럴까 복잡한 아키텍트 그런 대규모 아키텍트 를 위해서 그런
식으로 뭔가를 만든다 보면요
그만큼 이런 것도 있어요 최근에 얘기하는 마이크로 서비스 이런 개념도
릴리스 프로세스가 완벽하게 잡혀 있어야만 되고 그리고 마이크로 프로세서와
다 이제 뭐가 빼 일이 났을 때 그런걸 등록세 1호 거라던가 아니면 너무
기계 제대로 한다던가 그런게 제대로 잡혔을 때 그리고 그 지원돼 쏠수
컨트롤이나 그 예를 들어서 이제 마이크 서비스 단위로 하다보면 디버깅이
어려워 지는 것도 있잖아요 근데 뭐 내 컴퓨터 에서 디버깅 해보고 싶어
그러면 그 그 개발한 경우 내껄 어떻게 그대로 부여 늘 하고 그것을 모두
다 디버깅 할 정도의 그런 자동화가 있느냐 이런 것도 굉장히 중요하거든요
그리고 어쩐 만큼 서비스를 받는데 그래요 완벽한 서비스 타조와 그만큼
마이크 없이 오버 있다 좀 더 많은 것도 사실이에요
왜냐면 서버 하나에 돌린 게 아니라 각 서비스가 따른 서버 가 되니까
그럼 그 상황에서
이게 우리가 동 접수가 나라 오시면 거에요 근데 오시면서 무슨 마이콘
서비스 서버 간에 1대의 그 마이크 소스 여기에 합쳐 라도 통제 50명에
리퀘스트 10개 10개 50개 왜 나야 할 봐야죠 뭐
기껏해봐야 뭐 500개의 2000개 이 정도에요 서버 하나로 핸들
되거든요
그러면 서버 한대 두대 로 핸들 되는것을 썩을 15 올리는 거에요 그러면
이거 드는 비용은 어떡할 거야 그래 이런 여러 가지가 있어요 그러니까
그런 대규모의 완벽한 것 하기 위해서 통쾌한 굉장히 많아요
뭐 예를 들어서 매일같이 컴퓨터를 포맷을 해야 되는 경우도 있고
뭐요 완벽한 안전 특별한 프로그램이 따로 깔려고 안되는 경우 얻기 위해서
인터넷 끊고 이쪽에서 비행으로 돌리는 경우도 있고 아까 말한 그 모든
것들도 있고 한마디로 개발에서 나오는거라 속도 프로액티브 일에는 줄어들
수밖에 없어요
그러면 왜 필요하지도 않은 걸 해서 회사 전체의 이션 씩 로모 성능 성능
효율성 을 절반으로 줄여 하는 거에요
그런 얘기도 많이 자라 효율이 좋은 회사가 살아난다 이런 얘기도 하잖아요
그러면 또 뭐하자는 건지 모르겠어요 저한테 그런 경우에
또 제가 정말 소프트 아케 테가 때 좋은 소프트웨어 아키텍트 라면은
언제나 그걸 봐요 내가 어디까지 필요한 거냐 뭐 아인슈타인도 그런 얘기
뜨잖아요 간단하게 제일 좋은거라고 근데 너무 간 보지 필요한 만큼만
간단하게 좋은거라 그랬나
딱 그게 되게 중요한 말인데 그걸 읽을 줄 아는 눈이 있어요 소프트웨어
아키텍트 예요
그걸 일정한 눈이 없으며 쏙 딱해서 절대 안 거야 더
제 그런경우 많이 봤어요 이제 완벽 주의자 그리고 우리 빠지기 쉽고 이제
나는 돈을 생각하기 싫어요 내 일만 할 거야 나 그대 지금 완벽한
엔지니어링 할 거야
근데 이런 엔지니어는 뭐라 그럴까
소프트웨어 밖에는 별로 없다고 보셔야 맞아 외부에서 말하며 엔지니어 라는
것은 정확한 스펙과 정확한 금액과 이걸 다 해 왔고 그 모든걸 계산
하였고
딱 정말 필요한 솔루션을 만들 수 있는 거 그리고 돈이 부족하다 그러면
정말 있어 필요한 솔루션을 만들어 이 정도 돈이 필요하고 까지 이렇게
뭐랄까 수치로서 계산해서 보일 수 있는 사람의 엔지니어 이거든요
써 얼 마케팅이라고 엔지니어 이건 다른 중 하나 박희태 그런 거거든요
더 크게 되게 아쉬운 거에요 그래서 심지어는
뭐 어느 굉장히 한국에서 큰 게임 회사에서 엄청나게 스타 팀이 하나
있었죠 그 팀이 말 그대로 똑같은 짓을 했고 그 뭣이 퍼프 이런거
새로운거 나오는거 그런거 써보자 이러다가 코드 개판으로 만들고
뭐 결국엔 게임 못나오고 몇 년 동안 뭐 심지어는 게임 개발 한 건도
구청 안된 상황에서 한 5년 6년 7년 8년 9년 10년 여 인지
모르겠지만 그 녀석만 회사 돈 낭비하고 되어줘 팀 쪼개지고
이런 경우도 많거든요 뭐 제거 풀때는
모르겠어요 왜 왜 그러는지 그럼 그리고 자기에 대한 프라우드 가 있을 수
모르겠어요 자기가 팀을 말아 먹었다는 건데
우리는 이렇게 뛰어난 게임 1 원칙 에서는 프라이를 평생 먹고살 여는
건지 아니면 우리 엔진 일까 엔지니어링 많이 자라는데
완벽한 코드 베이스 만들면 돼 새로운 번다 써봐야 이런건지
그리고 또 하나 이제 같은 얘기 따라서 얘긴데
뭐 다음에 분명히 메타 프로그램이 얘기할 때 잠깐 얘기 할 것 같은데
그 건축 아키텍처 빌딩 아키텍트 는 새로운 아이디어 라고 무조건 수용하지
나요
이게 정말 어떤 장점과 단점이 있고 그러다 확인해 본 다음에 사람을
죽이지 않겠다 상품을 갖고 하는 거죠
이제 소프트웨어 아키텍트 레 문제는 아까 말들이 완벽한 세상을 추구
한다고 하면 더 그 망상에 빠져 있으면서 불구하고 새로운 걸 받아들일 때
새로운 거에 너무 흥분하는 그런 개 있어요
여기에서 오는 단점이 뭔지 가 명백해 보이는 데도
그걸 해결할 방안을 찾지 않은 채 장점이 더 단점보다는 크다는 확신도
없고 안무 확신 까지나 해도 50% 이상의 믿음도 없으면 없으면서 그냥
뭐 새로운 거 재미있는거 큰 회사 할까나 따라야지
뭐 이런 어찌보면 그냥 뭐라 그럴까
그런거 있죠 왜 그래서 어디 가서 이렇게 학벌 닭이 타이트 딱 이런 얘기
있잖아요
뭐 그런거랑 거의 비싼게 된거나 이런 새로운 가해왔다 이런거를 하기
위해서 우리 회사 돈을 중 내고 있는 게 아니라 생각돼요
그래서 오늘 하려고 했던 얘기는
소프트웨어 아키텍트 라는 걸 정말 자랑스러워 내면
저희는 편식이 좀 더 받는다고 생각을 하고요
우리는 소프트웨어 있기 때문에 현실을 보지 않아도 되
이정도의 마인드로 자기 합류를 하면서
어 새로운 우리는 이제 소프트웨어 뭐야 뭐야 엔지니어인 1회 비리가
아키텍트 처럼 그렇게 대단한 직업이라는 생각을 하는 그런 이중적인 자태
좀 맘에 안 들고
제 가려고 했던 얘기는
최종 고객과 최종 제품과 어디까지 필요하고 회사의 내가 는 아키텍트
주는 가치까지도 생각을 해야 될것 같아요 진짜 그게 음
으 어찌 보면은
뭐랄까 것 제가 속해있는 분야에 대한 적당한 비판이 기도했고
제가 하는 일에 대한 적당한 아니기도 한 것 같아요 아
어 그 정도로 암울하게 보기 tv 는 끝내 거죠 예 뽑혔습니다