'IT 이야기'에 해당되는 글 31건

  1. 2018.04.17 코딩 테스트
  2. 2012.06.19 아키텍트의 역할2 1
  3. 2012.06.19 아키텍트의 역할
  4. 2009.06.12 다시 쓰는 UTF
  5. 2009.04.02 다시 성능
  6. 2009.03.26 아키텍트 vs 트러블슈터 vs 컨설턴트
  7. 2009.03.26 튜닝
  8. 2009.03.25 interface
  9. 2009.03.25 Nice game
  10. 2009.03.23 멘탈 2
IT 이야기2018. 4. 17. 18:33


코딩을 거의 1년간 안해서 감을 찾는다는 목적으로 간단한 퀴즈 검색을 했더니

[카카오 신입 공채 1차 코딩 테스트 문제] 라는게 있어서

시험삼아 코딩을 해봄. (파일 첨부. : SecretMap.java)


일단 처음에 문제를 보고 3-4시간 걸릴거라 생각했는데 생각보다 헤매서 중간에 야구 본 시간을 빼더라도 7-8시간 정도 걸림. 익숙하지 않은 키보드도...


가장 오래걸린 문제 - 버스 스탑 - 처음에 접근을 잘못함. 




입사문제로 이게 적합한가에 대해서는 부정적임. 


몇몇의 코딩바보를 걸러낼수는 있지만 

위 문제중 2-3문제를 풀수 있는 사람은 다른 문제도 모두 풀 수 있음. 시간의 조금 더 걸리느냐의 문제일뿐. 


즉 2-3문제를 푼 사람과 모두 푼 사람의 차이는 단지 시간의 차이 문제인데 이런 시간의 차이가 실질 프로그래밍하는데 의미있는 차이를 가지느냐고 한다면 그렇지 않다고 생각함. 즉 변별력이 없음 (프로그래밍 분야에 따라 조금 다르겠지만..) 시간 문제때문에 오히려 변별력을 가지는 적합한 예외처리나 충분한 테스트 그리고 유연한 클래스 디자인등을 할 수 없게 만듬. 


그리고 Util 함수/클래스는 대부분 오픈소스로 미리 구현되어 있는데 LRUCache 같은걸 만들어야 할 이유가 없음. 



적합한 방법은 사실 나도 매번 의문이지만

문제를 내는 방식으로 할 거라면 

메모리 구조/핸들링이나 쓰레드와 관련한 문제를 내지 않을까...





'IT 이야기' 카테고리의 다른 글

아키텍트의 역할2  (1) 2012.06.19
아키텍트의 역할  (0) 2012.06.19
다시 성능  (0) 2009.04.02
아키텍트 vs 트러블슈터 vs 컨설턴트  (0) 2009.03.26
튜닝  (0) 2009.03.26
Posted by bleujin
IT 이야기2012. 6. 19. 22:07



지휘자란 다양한 개성을 가진 연주가들의 집단(오케스트라)을 한데 모으는 머리의 역할
기계와는 달리 버튼을 누르면 움직이는게 아니므로 말하는 것을 듣게 하는 것도 큰일이다.
그래서 무섭거나 상냥하거나 깐깐하거나 친구같기도 하는 등 여러가지 타입의 지휘자가 생겨난다.




지휘관 타입


가장 지휘자다운 것이 지휘관 타입
오케스트라를 군대처럼 취급하여 한치의 흐트러짐 없는 작전 수행이 가능하도록 훈련을 게을리 하지 않고
실수나 명령 무시를 결코 인정하지 않는다.
또한 단원의 채용이나 해고 등 인사권도 발동하여 미소 한번 짓지 않고 모든 것을 장악하는 무서운 타입

어떤 의미로는 최강의 지휘자이지만
조금이라도 약점을 보이거나 실수라도 저지르면 권위가 실추되어 모반이 일어날 위험도 크다.

때문에 한순간의 방심도 용납할 수 없어 스트레스가 쌓인다. 덕분에 현대에는 거의 전멸한 타입


BOSS 타입


다음은 보스 타입,

어떤 때는 엄격하게, 어떤 때는 상냥하게 채찍과 당근을 절묘한 밸런스로 반복해
어느새 이사람의 말이라면 뭐든 듣겠어 라는 생각을 가지게 된다.
지휘의 테크닉과 함께 사람의 마음을 장악(꼬시기)하는 테크닉을 아울러 지니고 있어
마에스트로(가장) 또는 보스라는 애칭으로 불리면서 마음을 한데 모으고 즐기며 음악과 사람을 컨트롤 한다.

젊어서는 미워할 수 없는 타입 혹은 사랑받는 타입으로서 실적으로 올리고
연륜을 쌓으면 아무 말 하지 않아도 오케스트라가 따라오는 거장으로 승격할 수 있는 이상적인 지휘자


중간관리자 타입

한편 작곡가(사장)와 오케스트라(사원) 사이에 끼어서 양쪽에 머리를 숙이며 사이를 중재하는 것이 중간관리자 타입.
지휘자라고 하면 오케스트라에 뭐든 명령할 수 있다고 생각할지 모르나
수많은 대가들과 공연 경험이 있는 대선배 연주가나 혹은 지식이 풍부하여 이론만 내세우는 시끄로운 연주가

그리고 소리치면 울어버리는 젊은 연주가도 있다.
그들 모두를 따르게 하는 것은 여간 어려운 일이 아닐 수 없다.

따라서 오케스트라를 치켜 세워서 좋은 연주를 끌어내는 수단이 필요하게 된다.
예를 들면 "안돼 이렇게 해"가 아니라
"죄송합니다만 여긴 이런 식으로 연주해 주시겠어요" 라든가
"매우 멋진 연주였습니다. 하지만 조금 더 이런 느낌으로 해주신다면 더욱 멋진 연주가 될 것 같은데 어떠신가요?" 라고 말하는 식이다.
지휘자는 위에서 들볶고, 밑에서 규탄받는 힘든 일이기도 하다.
이런 이유로 최근 이런 타입이 많아진 것 같기도 하다.


학자 타입

다른 노선으로 작곡가가 쓴 악보를 100% 재현하는 것이 최고라며 모든 것을 쿨하게 해내는 것이 학자 타입,
음악에 대한 열정 등의 애매한 말은 하지 않고 악보에 적혀 있는 포르테나 피아노, 템포나 다이내믹을 정확하게 음으로 내는 것에 목숨을 건다.

이른바 컴퓨터 같은 과학자 타입, 말하는 것은 이성적이고 엄격하지만,
작품 연구에 전력을 다하기 때문에 설득력이 있어서 오케스트라도 말하는 바를 잘 듣는다.(라기 보다는 들을 수 밖에 없다. )
덕분에 틀리거나 감정이 흘러가는 일이 없어 연주는 편차가 없고 안정적이지만,
너무 이지적이라 음악의 열정(과 미소)는 조금 부족할지도 모르는 것이 옥의 티.



from 피아노의 숲


.......

이제 "지휘자"를 "아키텍트"로 바꿔서 읽어보자..




'IT 이야기' 카테고리의 다른 글

코딩 테스트  (0) 2018.04.17
아키텍트의 역할  (0) 2012.06.19
다시 성능  (0) 2009.04.02
아키텍트 vs 트러블슈터 vs 컨설턴트  (0) 2009.03.26
튜닝  (0) 2009.03.26
Posted by bleujin
IT 이야기2012. 6. 19. 22:04

지휘자는 클래식 음악에서는 작곡가와 견줄만큼 대단한 얼굴을 하고 있지만
생각해보면 조금 불가사의한 일이다.

여러가지 악기를 가진 70명 정도의 사람들이 앉은 큰 오케스트라 앞에서,
홀로 맨 앞의 단상 위에 올라서서 오른손에 가느다란 봉을 잡고 휘두른다.

확실히 곡의 시작이나 마자막의 짜잔~ 하는 음을 끊을 타이밍 등을 알려줄 사람이 필요하다는 건 누구나 알 수 있다.
하지만 나머지는 음악에 맞춰 춤추는 걸로만 보인다.

지휘자는 대체 무엇을 하는 걸까?
지휘자가 없다고 연주할 수 없는 것도 아니지 않은가?
그리고 지휘자에 따라 연주가 그토록 달라지는 것일까?




- 그런 질문에 대해 설명하고자 한다.

지휘자는 영어로 컨덕터(conductor)라고 한다.
때로는 경애를 담아 마에스트로(거장)라고 부르기도 하지만 큰 스승님 과 비슷한 느낌이다.

현재 세계 각 도시에는 반드시 라고 해도 좋을만큼 오케스트라(관현악단이나 교향악단)가 있고,
그들은 콘서트나 오페라(가극) 혹은 TV 방송, CD 녹음 등 날마다 활약하고 있다.

그리고 오케스트라가 연주할 때면
반드시(가장 잘난 듯한 얼굴로) 등장하는 것이 지휘자이다.




하지만 이 지휘자라는 존재가 옛날부터 있었던 것은 아니다.
4-5명 정도인 소 인원의 앙상블(합주)이나 코러스(합창)의 경우에는
누군가 리드하는 한 사람만 신호를 보내고 나머지는 서로 얼굴을 쳐다보며 연주하거나 노래를 부르면 되기 때문이다.

실제로 클래식 음악에서도 18세기 정도까지는
작곡가가 쳄발로(키보드)를 치며 손으로 혹은 가장 안쪽에 앉아 있는 수석 바이올린 연주자가 활로 신호를 보내어 연주했다.

그런데 편성이 커지면서 현악기(바이올린이나 첼로)에 목관악기(플룻이나 클라리넷)와 금관악기(트럼펫이나 호른)까지 가세하여 구성이 커지자
연주하면서 서로 쳐다본다는 것은 사실상 불가능 하게 되었다.

그래서 누구나 볼 수 있는 위치에서 앙상블을 맞취기 위해 지휘를 할 사람이 필요하게 되었고,
이것이 지휘자가 되었다.




하지만 처음의 지휘자는 전문 직업이 아니라 작곡가 겸 연주가인 악단의 리더가 그 역할을 맡아서 하는게 일반적이었다.
아니 그렇다기 보다는 옛날에는 연주하고 곡도 쓰고 지휘도 하는게 음악가였다.

참고로 그 무렵(이른바 바로크 시대)에는 단상위에 서서 굵은 막대(지팡이)로 바닥을 쿵쿵 쳐가며 지휘를 하기도 했다.

지금 생각하면 이상한 느낌이지만 입으로 하나 둘, 하나 둘 이라고 외칠수도 없고

지휘자가 있는 곡의 경우 대인원으로 나팔이나 큰 북이 둥둥 울리는 곡이 많았으니 그렇게 해도 그다지 방해되지는 않았던 것 같다.

하지만 조용한 곡의 경우에는 역시나 쿵쿵대는 소리가 시끄러웠고,
흥분해서 힘이 들어가면 막대로 자신의 발을 찍어서 위험하기도 했다.
실제로 룰리라는 작곡가는 자신의 발을 찍었고, 그 상처가 원인이 되어 사망에 이르렀다고 한다.

그래서 막대로 바닥을 쿵쿵 치는 것은 위험하다는 게 판명되었지만,
오케스트라처럼 50명이나 100명씩 되는 대인원이 연주하게 되면 손을 흔드는 것으로는 무대에서 잘 보이지 않는다.

그래서 누군가가 눈에 띄는 길고 흰 막대를 들고 휘두르는 방법을 생각해냈고,
이것이 지휘봉이 되었다.

이러한 연유로 지금처럼 지휘봉을 들고 지휘하게 된 것은 19세기에 들어서인데
독일의 작곡가 멘델스존(결혼 행진곡이나 바이올린 협주곡으로 유명)이 최초라고 일컬어지고 있다.




그리고 19세기 후반 이른바 낭만파의 시대가 되자 오케스트라의 음악이 한층 복잡해진다.
악상의 변화와 함께 한곡 안에서 템포가 빨라지거나 느려지고, 한창 고조됐다가 조용해지기도 했다.

이렇게 되자 아무래도 하나 둘, 하나 둘 하며 팔을 흔드는 것만으로는 쫓아갈 수 없었고
신호를 알기 쉽게 정확히 전달하는 데만도 전문적인 테크닉이 필요하게 되었다.
게다가 몇시간이나 계속 선 채로 양팔을 휘둘러야 하니 체력과 운동신경도 필요했다.

평소에 피아노 앞에 앉아서 악보를 그리기만 하는 (운동부족인) 작곡가에게는 매우 감당하기 힘든 일이 된 것이다.
그래서 자기 손으로 작곡도, 연주도 하지 않지만
클래식 대가들의 음악을 전문적으로 다루며

오페라 극장에서 매주 오페라를 지휘하거나 오케스트라의 정기 연주를 매달 지휘하는 지휘의 프로가 등장하게 된 것이다.

지휘자의 역할은 음악가라기 보다는 영화 감독 혹은 야구 감독에 가까울지도 모른다.

좌우간 아무 지식없이 보고 있으면, 지휘자는 오케스트라 앞에서 음악에 맞춰 지휘봉을 휘두르는 것으로만 보인다.

그건 영화 감독이 의자에 앉아 잘난 척하며 레디 고를 외치기만 하는 걸로 보이는 것과
야구 감독이 벤치에 떡하니 앉아서 선수에게 불평을 늘어놓기만 하는 것으로 보이는 것과 같은 이치이다.

확실히 배우나 선수에게 지시를 내리는 것이 전부다. 그러니 그렇게 보인들 어쩔 수 없을 수 밖에.





하지만 실제로는 이렇게 음악이나 연기나 스포츠의 프로들을 컨트롤해 하나로 묶어 통솔함으로써 작품 혹은 시합을 완성하여 성공이나 승리를 이끌어 낸다.

그 결과 지휘자나 감독에 따라 그다지 명곡이라 할 수없는 음악이 감동의 명곡이 되기도 하고
예산이 아주 적은 영화가 대히트작이 되거나 약팀이 일약 강팀의 반열에 오르기도 한다.(물론 그 반대도 존재하지만)

한정된 시간(이나 예산)안에서 어떻게 연주가나 배우나 선수를 활용하여 화려한 무대를 만들고, 독특한 작품 세계를 창조하고, 시합을 승리로 이끄는가?
그것이 지휘자나 감독의 역량이라는 것이다.





그렇게 생각하면 충분히 상상이 가리라 생각하는데,
실제로 콘서트나 영화나 시합의 본 무대가 시작되고 나면 지휘자나 감독이 할 수 있는 일은 그다지 없다.
연주가와 배우 혹은 선수들의 활약에 전면적으로 맡기는 수밖에 없는 것이다.
그래서 지휘자가 콘서트 본 공연에서 음악에 맞춰 지휘봉을 휘두르기만 하는 것으로 보이는 것은 충분히 가능한 일이다.

실제로 연주하고 있는 것은 살아있는 연주가들이므로
게임처럼 명령키를 누르면 완번히 컨트롤 할 수 있는 것도 아니고 버튼을 누른다고 안타가 나오는 것도 아니다.
할 수 있는 것은 기껏해야 액셀이나 브레이크로 조정하는 것 정도 뿐.

따라서 사실 본 무대 전의 연습이나 리허설만이 지휘자나 감독들이 제 역량을 발휘 할 수 있는 곳이다.
제대로 리허설을 진행하기만 한다면 본 부대는 "준비, 시작~"만 외쳐도 충분한 것이다.





예를 들면 훈련된 프로 오케스트라라면 초보자가 지휘대에 서서 곡에 맞춰 적당히 지휘봉만 휘둘러도(혹은 춤을 추더라도)
그럭저럭 연주를 할 수 있다. (이상한 춤으로 방해하지 않는다는 가정하에)

일류 스태프가 모여 제대로 훈련을 쌓은 팀이라면 가령 당신이 감독자리에 앉아 레디 고를 외치더라도 그럭저럭 해 나갈수 있을 것이다.
하지만 그렇다고 해서 누가 지휘(감독)해도 마찬가지라는 것은 아니다.

실제 감독은 본무대에 대비해 배우나 스태프나 선수를 선발하고,
각본이나 시함의 흐름을 음미하고, 콘티를 그려 촬영 앵글을 고려해 촬영 순서나 시간의 배분을 짜고,
다양한 트러블이나 상황의 변화에 따라 적합한 지시를 내리고,
배우나 선수를 혼내거나 칭찬하면서 (왜냐면 감독이 하는 말을 들어준다고 단정지울 수 없기 때문이다.) 연습과 리허설을 거듭해
최종적으론 그들이 힘을 완벽히 발휘할 수 있는 최적의 상황을 만들어야만 한다.




그를 위해서 지휘자라면 악보를 읽어서 작품 구석구석까지 알아야만 하며,
음의 실수를 구분해 들을 수 잇는 귀와 악기나 작품에 관한 지식,
다양한 나라의 언어, 나아가 작품의 배경이 되는 역사나 음향학 등의 교양,
때에 따라서는 분위기를 부드럽게 만들 재치까지 필요하다.
그 모든 것이  다 갖춰져야 비로서 오케스트라나 팀을 장악할 수 있는 것이다.
그것이 지휘자나 감독의 역할이다. 



from  피아노의 숲


.......

이제 "지휘자"를 "아키텍트"로 바꿔서 읽어보자..




'IT 이야기' 카테고리의 다른 글

코딩 테스트  (0) 2018.04.17
아키텍트의 역할2  (1) 2012.06.19
다시 성능  (0) 2009.04.02
아키텍트 vs 트러블슈터 vs 컨설턴트  (0) 2009.03.26
튜닝  (0) 2009.03.26
Posted by bleujin
IT 이야기/유니코드2009. 6. 12. 16:14

UTF 얘기는 이미 충분히 글을 적었음에도 다시 포스팅을 하는 이유는 사람들이 자주 헛갈리는 캐릭터셋(charset)과 인코딩(enecoding)의 차이를 이야기 하기 위해서이다. 

"A"라는 글자가 컴퓨터에 이진수로 표현되어 저장된다는 것은 누구나 알고 있을 것이다. 중요한건 2단계를 거치는 것이 중요하다. 첫번째는 "해석"이고 두번째가 "저장"이다. 

첫번째 "해석"이란 컴퓨터가 아닌 사람을 위해 존재한다. "A" 글자를 저장해야 한다고 할때 글자 "A"라는 의미를 어떻게 전달해야 할까가 문제의 시발점이다. 다른 사람에게 "A"가 어떻게 저장되지? 라고 묻는건 올바르지 않다. 좀더 정확하게 말하자면 "2009년 현재 미국에서 사용하고 있는 알파벳의 대문자 A"라고 전달해야 한다. 번거롭기 그지 없다. 게다가 그 다른 사람이 사는 문화권에서는 "에이" 라고 불리는 다른 문자가 있을지도 있을지도 모른다. 원래 말이라는건 오해하기 쉬운 법이다. 

그래서 좀더 쉬운 전달을 위해 모든 문자에 숫자를 할당했다.(숫자은 전세계 모든 사람의 공용어 역할을 한다.) 이제 다른 사람에게 (십진수로) 65(16진수로 표현하면 0x41)번 문자는 어떻게 저장하지? 라고 물으면 된다. 이렇게 해석단계에서 사용하는, 문자에 번호를 매겨놓은게 charset (캐릭터 셋)이다. 컴퓨터가 발명된 초기부터 이렇게 별도의 해석 단계가 있었던건 아니었다. 컴퓨터가 처음 발명된 초기에는 해석 == 저장이었기 때문에 65번 글자인 'A'는 65번으로 저장한다 였다. 초기에는 128개(2^7)에만 번호를 할당했고 저장하였는데 구미지역에서는 이정도면 충분하였다. 

다시 말해서 캐릭터 셋은 해당 캐릭터 셋이 표현가능한 문자의 일종의 단순한 매핑 테이블이다. 이를테면 한글 "가"라는 글자는 KSC5601에서 "0116" 번으로 할당되어 있다. 이제 "0116" 에 해당하는 글자(즉 한글 "가")를 어떻게 컴퓨터의 이진 코드화 시키는가가 인코딩이다. 앞서 해석 - 캐릭터셋에 매핑된 숫자를 읽기 -는 논리적이며 저장 - 인코딩 -은 물리적 과정이기 때문에 서로 같지 않고 당연히 "0116" 글자가 0116 라고 저장되리라는 것을 기대하거나 보장할 수 없다. 

왜냐하면 캐릭터 셋은 논리적 과정이라 얼마든지 새로운 캐릭터 셋을 만들어도 상관이 없지만(물론 이 경우 다양한 단체의 알력싸움에 의해 정해진다.) 인코딩은 물리적 단계이며 이경우 가장 중요한 것은 호환성이다. 예컨데 "A"라는 글자는 KSC5601에서 "3305"번에 할당되어 있는데 디코딩은 인코딩의 역함수이기 때문에 기존에 ASCII로 "0x40"으로 저장된 코드를 "A"라고 읽을 수 없다. 따라서 캐릭터 셋의 번호대로 인코딩이 되지는 않고 실제로는 캐릭터셋의 해쉬 함수 인코딩을 하게 된다. 

KSC5601의 해쉬 함수를 통해 (KSC5601은 일반적으로 캐릭터셋의 의미를 가지지만 때로는 인코딩을 의미하기도 한다. 그래서 이전의 책이나 글에서는 문맥을 통해 구별하는 수밖에 없으며 이는 많은 혼란의 요인이 되었다.) "0116"글자는 "0xAC00"로 인코딩(즉 computer에는 AC00로 저장이 된다.) "3305" 글자는 "0x40"으로 바뀌어서 저장이된다. 문제는 디코딩을 할때 "0xAC00"  코드를 읽어서 화면에 "가"라고 보여줄 수 있느냐이다. 왜냐하면 파일에는 해당 파일의 캐릭터 셋에 대한 정보를 저장하기 않기때문에 이 파일을 읽을때 "0xAC00" 가 정말 "가"인지를 확인할 수 없기 때문이다. 어쩌면 다른 캐릭터 셋의 인코딩으로 "0xAC00"는 다른 글자일지도 모르기 때문이다. (어쩌면 초기에 구미에서 컴퓨터를 발명하면서 파일에 캐릭터 셋을 저장하지 않는 것이 문제의 시발점인지 모른다. )

파일을 인코딩한 해쉬 함수의 역함수는 당연히 캐릭터 셋에 종속이 되기 때문에 해당 파일의 캐릭터 셋을 모르고서는 해당 파일이 제대로 읽을 수 없다. 앞문장의 "제대로" 라는 뜻은 "0xAC00" 라는 코드를 읽어도 해당 파일의 캐릭터 셋을 알지못하면 이를 "가"로 제대로 화면에 보여주지 못한다는 이야기 이다. 

만약 자신의 컴퓨터에서 혼자만 쓰는 파일이라면 상관이 없다. 각 컴퓨터에는 기본 캐릭터셋이 지정되어 있기 때문에 아무런 추가 작업을 하지 않는 이상 기본 캐릭터 셋으로 쓰고 기본 캐릭터 셋으로 읽으면 된다. 그러나 A 컴퓨터에서 작성한 파일을 B 컴퓨터로 전달하는 경우(이메일을 쓰거나 웹에 글을 올리거나 하는 경우도 마찬가지이다. )에 해당 파일이 어떤 캐릭터 셋인지 전달해 주지 않으면 상대편의 컴퓨터에서는 제대로 읽을수가 없다. 설사 말로 알려준다고 하더라도 상대편의 컴퓨터에 해당 캐릭터셋에 대한 정보가 없으면 역함수가 없고 디코딩도 당연히 할수 없다. 

그럼 이쯤에서 나올만한 생각이 있다. 지구의 모든 컴퓨터가 공용으로 사용할 수 있는 캐릭터 셋을 만들면 되지 않을까? 정답이다. 그래서 나온게 유니코드이다. 문제는 유니코드의 발상이 나오기 전에 이미 많은 캐릭터 셋이 많은 컴퓨터에서 사용이 되고 있다는 점과 모든 글자를 담기 위해서는 글자당 할당되는 번호가 길어지고 이는 당연히 저장 공간이 길어지는 2가지 문제가 추가적으로 야기된다. 

둘을 묶어 보면 기존에 호환성을 유지하면서도(여기서 호환성이란 보통 ASCII만을 의미한다.) 수많은 글자를 가능한 작은 저장공간에 인코딩을 할 수 있어야 한다는 얘기이다. 


ASCII
당시의 컴퓨터는 유닉스 기반의 컴퓨터로 7비트가 1바이트인 메모리를 사용하였고 따라서 자연스럽게 하나의 문자를 표현하는데 7비트를 사용하였다. null로 시작하는 32개의 제어문자,공백문자, 94개의 프린트문자, 지움문자로 128개의 비트조합을 배정하였다. 이에 따라 1963년 최초의 ASCII 표준이 제정되었는데 이때까지만 해도 많은 비트 조합이 94개의 프린트 문자 번호로 배정되지 않은 상태였으며 1968년에 오늘날과 같은 ASCII 코드가 만들어져 표준으로 지정되었다. 


ISO 8859
같은 라틴계열의 문자이긴 하지만 별도의 강세문자를 가지는 프랑스나 그리스의 문자는 구미의 알파벳과 조금 달랐고 이런 언어의 표현을 포함하는 캐릭터 셋을 만들려는 국제적인 노력은 ISO8859 시리즈에서 나타났다. ISO 8859-1은 서유럽 언어를 다루기에 충분했으며, ISO 8859-7은 기본적인 그리스 문자, 알파에서 오메가, 발음기호 등 현대의 그리스 문자와 영어를 모두 지원했다. ISO 8859에서는 하나의 문자를 표현하는데 8비트를 사용하며 ASCII 외의 각 나라마다 자신이 사용할 문자는 128 이후에 배치하였다. 즉 ISO 8859는 128개의 세계 공통 문자(주로 알파벳과 숫자, 제어코드)와 128개의 지역 문자(지역별로 다른 문자 할당)의 조합이다. 

ISO 2022
상식적으로 공통으로 사용하는 128개의 문자말고 추가적인 128개의 문자는 지역마다 다르게 정의되었기 때문에 제대로된 문서 교환이 이루어질리 없다. 파일에는 그 파일이 어떤 캐릭터 셋을 사용했는지에 대한 정보가 저장되어 있지 않기 때문에 wrirte할때는 불어 지역문자를 사용하면 러시아에서 read 할때는 제대로 읽혀지지 않는다. 초기에는 네트워크가 활발하지 않았고 대부분 컴퓨터에는 혼자 사용하는 것이라는 인식이 강했지만 이게 문제가 되는 대표적인 예는 이메일(Email)이다. 

프랑스 사람이 러시아 사람에게 프랑스어로 이메일을 작성했을때 러시아인 컴퓨터에서 프랑스어가 제대로 보이기 위해서 이메일은 이스케이프 시퀀스(escape sequence)로 글자별로 캐릭터 셋을 설정하도록 하였다. 즉 프랑스 이메일 클라이언트는 프랑스어 코드가 나올때마다 ISO 2022 문자 인코딩들은 이어서 나오는 문자들에 대한 문자세트를 지시하는 escape sequence를 포함하고 있다. 그럼 저장단계에서 escape를 보고 해당 캐릭터셋의 번호로 저장 하였다. 즉 아직까지는 해석과 저장의 명확한 분리를 하지 않았기 때문에 기본 ASCII가 아닌 문서를 교환하는 것은 이렇게 비효율적인 면이 존재한다. (escape 문자로 인해 data 길이가 늘어나고 여전히 read하는 곳에서 해당 charset을 인식하지 못한다면 읽을 수 없었다.)

ISO 2022 문자세트들은 여전히 많이 사용되고 있으나, 최근에는 최신 이메일 소프트웨어 등 에서 UTF-8과 같은 유니코드 문자 인코딩들을 사용하는 것으로 차츰 변환되고 있다.


KSC 5601

KSC 5601은 94x94의 각 위치(행열)에 한글 문자를 일정한 순서에 따라 배열해 놓은 charset이다. 앞서 말했듯이 한글은 표의문자와 표음 문자 2가지 성격을 모두 가지고 있는 독특한 특성때문에 여러가지 다양한 방법중에서 한글 코드의 KS 제정에서 완성형이 채택된 것은 내부적으로 한글의 출력이 모아쓰기 형태로 이루어지면서 동시에 한자를 섞어서 쓸 수 있어야 한다는 사회적 요구로 조합형을 수용 하기가 어려웠기 때문이다.(물론 정치적인 이유가 없던것은 아니다.)

또 다른 배경은 국가간의 정보교환을 위한 코드 표준화 과정에서 앞의 ISO 2022에서 제정한 코드 체계에 따라 세계 각국의 문자를 처리하는데 기인한다. 이는 1바이트 코드로 한 문자 표현이 불가능한 CJK(Chinese, Japanese, Korean) 문자를 2바이트 코드 영역의 첫 번째 영역에 넣을 수 있도록 영역을 확보해야 했기 때문이다.


KSC 5601은 완성형 한글 2,350자, 한자 4,888자, 기술/학술기호 등 특수문자 432자, 숫자 30자, 한글 낱자 94자, 로마문자 52자, 그리스 문자 48자, 괘선 조각 68자, 라틴 문자 27자, 일본 문자 169자, 러시아 문자 66자 등 총 8,224자와 기타 사용자 정의 영역으로 한글 96자, 한자 95자 정도를 사용하도록 배정하고 있다.(이후 KSX 등의 명칭이 변동된 역사는 이전글을 참조)

를 보면 94*94(8836) 의 매트릭스에 위 문자들이 지정되어 있다. 'A'가 03 * 33에 'a'가 03*65에 지정되어 있고 '가'는 16*01에 할당되어 있다. 위 PDF를 보면 캐릭터 셋과 인코딩의 차이에 대해 좀더 이해할 수 있다. KSC 5601 캐릭터 셋이란 "한국"이라는 지역에서 최소한 지원해야 하는 문자들에게 각각의 번호를 지정해놓은 것이고 인코딩이란 그 번호들을 컴퓨터 이진수로 어떻게 저장할 것인가에 대한 문제이다. 

일반적으로 KSC 5601을 지원하는 인코딩은(이를테면 euc-kr)은 1byte의 첫번째 비트가 0이면 이후 7bit를 ASCII문자에 대응시키고 첫번째 bit가 1이면 다음 바이트까지 묶어서 KSC 5601의 문자번호를 지정된 해쉬함수 계산을 통해 저장된 문자로 인식한다. 

네트워크가 발전하고 CJK에 컴퓨터가 많이 보급되면서 위와같이 지역적인 문사셋을 사용하는 것은 글자깨짐의 문제(파일의 메타정보에는 문자셋을 지정할 수 없다는 것을 기억하자. 대표적으로 HTML안에도 HTML의 문자셋을 HTML 문자 안에 지정해야 한다. 이러한 - 파일 해석을 위한 방법이 파일안에 있는 - 방법이 먹혀드는 이유는 HTML은 규약상 charetSet을 지정하는 부분까지 ASCII를 제외한 다른 문자가 나오지 않아야 한다는 가정때문이다.)때문에 UniCode가 나왔다. 


UNICODE

유니코드(Unicode)는, 컴퓨터에 저장하려는 모든 문서의 글자에 대해 캐릭터 셋을 제공하기 위한 국제 표준이다. 유니코드는 오늘날 실제 사용되는 모든 문자들과, 학자들만 사용하는 문자들, 또 수학기호, 언어학기호, 프로그래밍 언어 기호 등까지 포함하고 있다. 보통 유니코드는 말하거나 문서에 적을때 캐릭터 셋과 인코딩의 두가지 의미를 동시에 가지기 때문에 다소 헛갈리지만 

보통의 경우 
유니코드라고 말하면 캐릭터 셋을, 
USC-2, UCS-4는 캐릭터 셋 혹은 인코딩 2가지 의미를
UTF-8, UTF-16, UTF-32라고 말할때는 인코딩 방법을 의미한다. 

UCS-2는 2byte 숫자로 전세계에서 자주사용하는 문자를 지정해놓은 캐릭터 셋이고(여기에는 기본 ASCII 와 서유럽언어, CJK 언어 일본어 등이 할당되어 있다. 단 65536의 제약이 있기 때문에 모든 글자가 할당되어 있지는 않다.) 이 캐릭터 셋의 번호로 컴퓨터에 저장하면 UCS-2 인코딩을 사용한 경우가 된다. 

USC-4는 4byte의 숫자로 전세계의 모든 문자와 학자들만 사용하는 문자들, 수학기호, 언어학기호, 프로그래밍 언어등까지 포함하고 이후에 새로이 나타나게 될지도 모를 문자들를 위해 많은 여유공간이 있다. 실제로는 0번부터 256^4 까지 순차적으로 번호를 부여하는게 아니라 32bit를 영역별로 쪼개서 언어판(Plane)과 Group를 지정한다. ( Group 1byte + Plane 1byte + CodePoint 2byte를 사용한다. UCS-4가 인코딩의 의미로 사용될때에는 0x00000000 ~ 0x0010FFFF 범위만을 합법적인 코드값으로 갖는다. 00그룹 + (00 - 10 까지의 17개 Plane) + codepoint 2byte)


인터넷에서는 카더라 통신이 많아서 혼란의 소지가 많지만. 위 문서는 유니코드에 대해 가장 잘 설명한 그리고 정확한 문서이다. 

'IT 이야기 > 유니코드' 카테고리의 다른 글

Unicode와 Database  (0) 2009.03.01
Global Software - Unicode와 Programming  (0) 2009.02.26
Global Software - Unicode  (0) 2009.02.25
Global Software  (0) 2009.02.22
Posted by bleujin
IT 이야기2009. 4. 2. 04:55

다시 퍼포먼스 얘기를 해보자.

문제는 아래와 같다.

권한 설정문제인데...
약 10만개의 Tree 형태의 Category Node 가 있다. 권한 정보도 트리 형태로 관리되고 있다. 권한의 종류는 대략 100여가지 정도이다. 그룹과 사용자는 M:N의 관계이며 하나의 그룹은 사용자 혹은 다른 그룹을 하위로 가지고 있다. 사용자는 최대 1000명이 가능하며 그룹은 아마도 수백내외 정도이다.

이제 특정 사용자(혹은 그룹)은 특정 카테고리에 특정 권한을 설정할 수 있다.
이를테면 Category_Read권한을 가진 사용자(혹은 그룹에 속한자)만이 해당 카테고리를 볼 수 있고 해당 권한(혹은 상위 권한)을 가지지 않은 사용자는 해당 Category가 화면에 보이지 않아야 한다.



즉 3개의 Tree 형태를 가지고 권한 정보를 설정하게 된다. 만약 catB에 GroupA가 category_root 권한을 설정하게 되면 GroupA 하위의 모든 그룹에 속하는 사용자는 catB 이하의 모든 카테고리에 대해서 category_root 권한 이하의 모든 권한을 가지게 된다. 단 이때 권한정보에 카테고리 상속여부를 False로 설정하게 되면 catB의 카테고리에 대해서만 권한을 가진다.

그러다가 bleujin 사용자만 catE 카테고리에 대해서는 category_read 권한을 제외하고 싶다면 다시 catE에 bleujin이 category_read 권한을 revoke여부를 true로 설정하게 되면 기존의 권한트리는 변하지 않은채 bleujin의 권한만 재 설정할 수 있다. (이는 DB 모델과 비슷하게 권한이 없다라는 것도 일종의 권한이다 라고 추상화 모델이다. 이경우 상위 카테고리인 catB에는 권한을 주고 하위 카테고리인 catE에는 revoke권한을 주면 catB,catF는 권한을 가지고 catE는 권한이 없다.)

일반적인 시스템처럼 권한정보가 사용자 그리고 카테고리 별 권한별로 row 복제가 되지 않는 다는 점에 주의 하여야 한다. 잘못하면 하나의 권한 정보를 설정할때 수첫만 row가 설정되야 할지도 모르며 이후 관리가 무척 어렵기 때문이다. 권한 정보를 수정하지 않고 특정 사용자가 특정 그룹에서 제외되면 그룹이 가지는 권한은 더이상 적용되지 않는다.

처음 대하면 약간 머리가 핑 돌지만 이 모델은 권한트리에서 생각할 수 있는 가장 유연한 모델이다. 특정 사용자가 특정 카테고리에 특정 권한을 가지는가를 체크하는 것은 그리 어려운 일이 아니다. 특정 사용자의 모든 상위 그룹과 특정 권한의 모든 상위 권한 그리고 특정 카테고리의 모든 상위 카테고리를 읽어서 카테고리 상속여부와 rovoke권한 여부를 잘 조합하면 하나의 SQL로 0.1초 이내의 응답속도를 보장할 수 있다.

문제는 바로 이것이다. 특정사용자가 접근했을때 category_read 이상의 권한을 가진 카테고리 리스트를 Tree 형태로 보여 줄수 있는가... 이다. 이때 특정 사용자가 catE에만 category_read 권한(혹은 그 상위 권한)을 가지고 있다면 catA와 catB에는 category_read 권한이 없어서 내용은 볼수 없지만 카테 고리의 이름은 보여야 한다. 상위 카테고리가 보이지 않으면 Tree 형태의 category모델에서 catE에 접근할 수 조차 없기 때문이다.

이 문제를 더욱 어렵게 하는 것은 카테고리 리스트를 보는 것은 매우 자주 일어나므로 반응 시간이 2초 이내여야 한다는 사실이다. 이게 왜 문제가 되냐면 아무런 특정 로직이 없이 10만개의 category를 Tree 형태로 읽는데에만 약 4-5초가 걸린다는 사실이다. 게다가 단순히 트리 형태의 category를 읽는 것은 아무런 의미가 없고 상위 그릅과 상위 권한도 고려해야 하며 카테고리 상속여부와 revoke 권한도 고려를 해야 하는 로직을 생각하면 일찌감치 날 샌 문제와 마찬가지이다.

catB가 보여야 하나 말아야 하는 정보는 단순히 catB와 관련된 권한 정보만 가지고는 알 수 없다. 어쩌면 catB의 11단계 밑의 카테고리에 해당 사용자가 속하는 상위그룹에게 root 권한이 설정되어 있으면 catB는 Tree 리스트에 보여야 하기 때문에 하위의 모든 카테고리 정보도 보아야 한다.


이제 생각을 해보자. 이전 성능의 첫번째 행동강령은 기준과 목표가 있어야 한다. 였다.
여기서의 기준은 10만개의 카테고리와 수천명의 사용자 그리고 수백개의 권한 정보를 아무런 로직없이 단순히 데이타베이스에서 읽는데만 5초 이상이 걸린다는 기준이 있고 목표는 2초 이내이므로 이미 정상적인 방법으로는 불가능하기 때문에 이때 아무리 멋진 프로그래밍 모델을 생각하더라도 그쪽은 답이 없다.

이때 중요한 점이 바로 이점이다. 이미 정상적인 형태의 connect by start with로는 절대 답이 나올수 없기 때문에 다른 방법을 고려해야 한다는 사실 그 자체를 아는게 중요하다. 기준이 없으면 자신이 올바른 길을 가고 있은지 아닌지를 스스로가 알수 없다.

아까 하나의 카테고리에 특정 사용자가 특정 권한이 있는지 여부를 체크하는데 0.1초가 걸린다고 하였다.(SQL에 익숙하지 않으면 이 SQL을 짜는 것도 쉽지 않다.) 단순히 catA를 보여줘야 하는지 여부를 개별적으로 체크한다면 catA의 모든 하위 카테고리를 조사해야 되고 10만 * 0.1초 이므로 약 2시간 30분이 걸린다. 따라서 이 방법도 답이 될 수 없다.

당시에 약 2달간 생각했지만 위 문제를 풀지 못했다. 그러나 수학은 풀지 못했다고 해결이 되는게 아니라 풀 수 없다고 증명할 수 있어야 하는데 그냥 카테고리만 읽는데만 5초가 걸리는데 어떻게 2초 이내의 응답속도가 가능할까? 라는 근거는 충분한 증명이 되지 못했다.

문제는 하위 카테고리를 "모두" 읽지 않고 상위 카테고리가 보여줄지 여부를 결정 할 수 있느냐의 여부였고 2달이 지난후 약 3일 걸려서 복잡 다양한 설정 Case를 분석해서 0.6초 정도의 반응속도를 보여주는 200라인 정도의 SQL을 짰는데 구문이 대단히 복잡하다거나 그런건 아닌데 발상이 어렵다. 대신 SQL에서 모든 리스트를 구해서 넘겨주므로 프로그램에서는 그냥 보여주기만 하면 된다. 위 문제는 생각하기에 따라서 아주 재미있으므로 흥미가 있다면 직접 작성해보는 것도 도움이 된다.



위 얘기를 하는 것은 성능 문제에 있어 기준과 목표는 가장 중요한 행동강령이라는 사실을 다시 한번 강조하기 위해서이다. 앞의 로그분석 프로그램의 예를 다시 얘기하면 로그가 약 100만건이라면 이를 일단 분석하는 비지니스 로직은 제쳐두고 일단 100만건을 읽는데 보통의 서버급에서 2-3초가 걸린다. 좀더 좋은 서버라면 1초 정도면 가능하다. 이때 이 기준은 매우 중요한 판단 기준이 된다.

만약 해당 프로그램이 100만건을 분석하는데 약 3분이 걸린다면 과연 그 비지니스 로직이 2분 57초가 걸릴만큼 복잡한가에 대해서 자문해볼 수 있는 여지가 있기 때문이다. 그렇지 않다면 내가 해당 데이타를 읽는 방법이 잘못됐거나 비지니스 로직이 잘못됐다는 것을 뜻한다.

따라서 일단 100만건을 분석하는데 단순히 읽는 속도인 2초에 한없이 가깝게 가는게 일차 목표가 된다. 그러나 분석 데이타가 1억건이라면 얘기가 달라진다. 단순히 곱셉을 하면(실제로는 단순곱셈이 아니지만) 1억건을 모두 읽는데 약 200초가 걸리며 200초가 수용할 수 있는 수준이 아니라면 이때는 기존의 단순히 읽는 방법으로는 이미 답이 없음을 뜻한다.

따라서 데이타 분산을 했을때의 읽기 속도, 집계 테이블을 유지했을때의 속도와 단점 등등을 미리 측정해서 알고 있다면 이러한 경우 해답을 찾는 문제가 훨씬 더 단순해진다. 만약 이러한 기준을 모른다면 말 그대로 보물이 나올때까지 삽으로 닥치는 대로 이곳저곳 땅을 파는 것과 같다. 아마도 겨우 동전 몇개를 발견하는 것에 그치겠지만 말이다.




'IT 이야기' 카테고리의 다른 글

아키텍트의 역할2  (1) 2012.06.19
아키텍트의 역할  (0) 2012.06.19
아키텍트 vs 트러블슈터 vs 컨설턴트  (0) 2009.03.26
튜닝  (0) 2009.03.26
interface  (0) 2009.03.25
Posted by bleujin
IT 이야기2009. 3. 26. 18:39

아키텍트

나는 아키텍트란 평범한 말을 하는 사람이라고 정의한다. 대부분의 아키텍쳐 책을 봐도 그렇다. 읽다가 졸리지 않는게 이상할 정도로 당연한 말과 평범한 이야기를 한다.

아이러니한건 아키텍트가 절실히 필요하다고 생각할때는 프로젝트가 아주 위급한 상황일때가 대부분이다. 사실 그때는 트러블슈팅 전문가를 찾아야 하지만 사람들은 아키텍트가 그러한 역할도 해줄수 있다고 생각한다.

아키텍트의 역할은 프로젝트를 위급한 상황으로 만들지 않으려는 사람이지 위급한 상황에서 구할 수 있는 사람은 아니다.

그렇기 때문에 만약 당신이 풀 포기를 잡고 절벽에 간신히 매달려 있을때

프로그래머 : 도와주세요~
아키텍트 : 일단 그 플포기는 당신의 질량을 감당할 수 없어요 당신의 질량과 현재 절벽의 각도, 바람의 세기를 고려하면 최소 굵기 10cm의 밧줄이 필요하죠.

프로그래머 : 저도 풀포기에 의존하고 싶진 않아요 밧줄 좀 주세요
아키텍트 : 아뇨 지금은 밧줄이 없어요. 밧줄은 당신이 등산을 오기전 준비를 했어야 합니다.

프로그래머 : 일단 머 붙잡을거라도 좀 내려 주세요
아키텍트 : 그전에 당신은 거길 왜 내려갔나요?

.. 라는 소리를 듣게 될것이다.

그런데 사람들은 평범한 걸 쉽다고 착각한다. 그렇다. 그건 착각이다. 좀더 정확하게 말하면 평범은 말하기는 무척 쉽지만 지키는 건 무척이나 어렵다.

일일 빌드를 하고, CVS를 사용하고, 명세서를 작성하고, 코드를 작성하기전에 유닛 테스트를 수행하며, 회귀 테스트가 가능해야 하며 테스트 팀의 분리와 .... 등등 모두 평범한 소리지만 이 평범한 것들을 지키는 개발조직은 거의 없다. 조금 생각해 보면 이는 당연한 일일지도 모른다. 누구나 건강이 중요하다고 하지만 건강을 위해서 하루에 4km를 걷고 45분 작업후 10분 정도 스트레칭으로 근육을 풀어주고 술과 담배는 하지 않으며, 정해진 시간에 균형있는 영양 섭취의 식사 등을 하는 사람을 발견하기 어려운 것과 같다.



트러블슈터

트러블슈터는 앞서 말했듯 아키텍트와는 다르다. 트러블슈터는 장애가 발생했을 때 아키텍트와는 반대로 짧은 시간안에 결과를 만들어 내야 하는 사람이다. 따라서 커뮤니케이션 능력이 중요한 아키텍트보다는 조금 더 독단적인 성격이 강하다.

트러블슈팅은 많은 장애 요인을 고려하고 넓은 각도에서 접근해야 하는 원인 분석과정과 해당 장애를 복구하는 2가지 과정으로 나눌 수 있는데 이 중 장애 복구는 true or false 성격이 강하기 때문에 주로 전문 기술직인 경우가 많다.

다만 와인버그의 이 말은 항상 기억해 두어야 한다.
"처음에 어떻게 보이든 문제는 항상 사람이다."




컨설턴트

자기도 할 줄 모르는(혹은 안해본) - 아마도 아무런 도움도 되지 않는 - 두꺼운 문서와 솔루션을 대책없이 제안하는 컨설턴트가 아주 많기 때문에 컨설턴트에 대한 조롱섞인 유머는 아주 많지만 잘 알려진 유머는 아래의 글이다.


어느 마을에 목장을 운영하는 사람이 있었다.
어느날 정장을 잘 차려입은 한 신사가 마을에 나타나서 목장 주인에게 찾아가 다음과 같이 말했다.

"내가 당신 목장에 있는 소 숫자를 정확히 맞추면 당신 소 한마리를 가져가겠소"
목장 주인인 "알겠소. 그럼 한번 해보시오." 라고 하였다.

이윽고 셈을 마친 신사는 목장 주인에게 "당신 목장에 있는 소는 총 XX마리요." 라고 했고
목장 주인은 "당신 정말 대단하오. 정확히 맞추었소. 자, 소는 여기 있소." 라고 말하였다.

그러자 신사는 "그럼 잘 있으시오. 난 이만 가보겠소." 라며가려고 하는데
목장 주인이 신사를 부르며
"신사양반. 잠깐만 멈추어보시오. 내가 당신의 직업을 맞추어 보겠소. 만약 맞추면 그 소를 도로 놓고 가시오" 라고 했다.

신사도 동의하였고 목장주인은 말하기를 "당신 직업은 컨설턴트요." 라고 말했고
신사는 "정확히 맞추었소. 자, 소는 여기있소. 근데 어떻게 알았소?" 라고 물었다.


그러자 목장주인은 다음과 같이 말하였다.

"나는 3가지 점을 통해 당신의 직업이 컨설턴트인지 알았소.
첫째는, 당신은 부르지도 않았는데 나타났다는 점이오.
둘째는, 당신은 내가 알고 있는 것을 알려준다는 점이오. 목장 주인인 내가 기르는 동물 숫자도 모르겠소?
셋째는, 당신은 틀린 것을 알려준다는 점이오. 내가 기르고 있는 것은 소가 아니라 염소요."

그밖에도 "지금이 몇 시인가요?"하고 묻자 "당신 시계를 주시면 내가 몇 시인지 알려주겠소"라고 답하면 컨설턴트인지 알수 있다는 유머도 있다.

컨설턴트라는 직업은 많은 사람들에게 인기를 끌고 있다. 직업 자체에서 풍기는 전문적 이미지와 폭 넓은 관점에서 문제를 조망하면서 조직에 대한 조언을 하는 업의 속성이 매력적으로 보이는 것 같다. 이런 인기에도 불구하고 정작 컨설팅을 받아 본 사람들이 느끼는 가치는 편차가 심한 것 같다.

조금 냉소적으로 정의한다면 일종의 외부에서 데려온 아키텍트로, 평범한 것을 평범하게 말하는 아키텍트와는 달리 평범한 것을 어렵게 말 할수 있는 재주를 가진 사람이다. 악의적으로 들렸을지도 모르지만 사실 개인적으로는 컨설턴트를 좋아하고 컨설팅은 사고의 다른점을 볼 수 있다는 점에서 아주 흥미있다.

IT 컨설턴트로 잘 알려진 Weinberg의 "컨설팅의 비밀"이나 Peter Block의 "완벽한 컨설팅" 책에는 복잡한것을 간단하게 혹은 우아하게 말하는 재능있는 컨설턴트와 번쩍이는 위트의 말들을 볼 수 있다.

'IT 이야기' 카테고리의 다른 글

아키텍트의 역할  (0) 2012.06.19
다시 성능  (0) 2009.04.02
튜닝  (0) 2009.03.26
interface  (0) 2009.03.25
Nice game  (0) 2009.03.25
Posted by bleujin
IT 이야기2009. 3. 26. 00:39


아래글은 그러니까 2003년에 작성한 글인데 지금와서 다시 읽어봐도 새롭다-ㅅ-. 이 글은 너무 길기 때문에 첫번째 조언과 첫번째 행동강령만 읽어도 충분.

이 글의 첫번째 조언에 따르면 이전글의 클라이언트 모델이 서버 커서모델보다 빠르다라는 주장은 아무 쓰잘데기가 없다. 빠르다라는 근거가 메카니즘이고 또 얼마나 빠르다라는 수치를 제공하고 있지 않기 때문이다. 약간의 테스트와 체감으로 수치화 할수는 없고 대략이라고 밖에 말할 수 없을정도로 환경이 다양하다는 이유도 있지만 사실 클라이언트 커서 모델은 단순히 빠르다라는 이유로 선택한 모델이 아니라 구조의 중복을 없애고자 선택하였기 때문이다. 

뒷부분의 행동강령의 첫번째 조언은 기준이 있어야 한다 인데 최근에 로그 분석 프로그램을 만들고 있는 지인으로부터 질문때문에 다시 생각났다. 로그의 특성상 하루에 수십만개 이상의 데이타가 쌓이는데 다양한 시나리오에서 실시간 분석이 가능한 적절한 모델에 대한 질문이었는데 사실 이러한 질문은 우문에 가깝다. 프로그래머라면 자신이 사용하고 잇는 환경에서 10만건 풀스캔과 100만 풀스캔 그리고 1억건의 풀스캔 속도를 알고 있어야 하고 이러한 근거가 있다면 현재 자신이 사용하는 방식의 문제점과 한계점 그리고 이를 극복하기 위한 방안은 이미 명약관화하기 때문이다.


-------------- 이하.

개발자의 대부분은 프로젝트 수행에 있어 성능과 견고성에 많은 관심을 가지고 있습니다. 운 좋게도 이러한 걸 하기 위해 많은 훌륭한 제안이나 권고사항이 책이나 인터넷등에 있습니다. DB 혹은 네트웍 혹은 언어별 관련된 많은 관련사이트와 책들이 있으며 약간의 시간과 비용을 들인다면 감당해내지 못할 정도의 많은 내용을 얻을 수 있습니다.
그러나 아쉽게도 많은 개발자들은 튜닝에 대해 환상을 가지고 있는 듯 합니다. 그동안 튜닝은 오랫동안 시스템 개발을 해왔고 경험도 많은 소위 "전문가" 들의 영역으로 알려져 왔기 때문에 그러한 내용들은 마치 진리인양 위장되기 일쑤입니다. 그렇지만 상당히 많이 알려진 튜닝기법들이 어떤 이론적인 메커니즘에 근거하고 있는 경우가 많으며 전달과정에서 여러가지 오해와 소문의 의해 부풀려진 경우가 많습니다.

 

비록 전문가는 아니지만 제가 하는 튜닝에 대해 첫 번째의 조언은 튜닝에 있어 가장 중요한 것은 성능이 아니라 "얼마만큼"의 성능인가라는 점입니다.


튜닝을 2가지로 나눈다면 첫째로 튜닝을 함으로 무조건 이득을 얻는 경우입니다. 하지만 그 경우의 수는 사실상 많지 않고 이는 사실상 튜닝이라기 보다 어느 하나의 원칙이라고 불려져야 마땅한 경우입니다. 개발자들이 알지 못해서 혹은 잊어버려서 아니면 개발자들의 공통적인 특성인 단지 게을러서 라는 이유로 적용하지 못했을 뿐인 아주 단순한 경우가 대부분입니다. 이를테면 다수사용자의 릴리즈 프로그램에서는 동적 SQL 대신 프로시저를 사용하라는 것은 사실상 원칙입니다. 그 밖에도 이러한 예제는 주로 하드웨어적인 튜닝이나 설정에 관련된 경우가 많습니다.

튜닝에 있어서 두 번째 경우인 대부분의 튜닝이란 무언가를 잃는 대신 그 이상의 효과를 얻는 것입니다. 그렇기 때문에 튜닝을 함에 있어서 가장 중요한 점은 이걸 함으로써 빨라지느냐 혹은 느려지느냐가 아닙니다. 중요한 것은 "얼마"만큼 빨라지느냐? 혹은 "얼마"만큼의 손실을 감수해야 하는가의 그 "얼마"입니다.

예를 들어 '이런 방법을 쓰면 빨라진다더라'는 사실상 전혀 의미가 없습니다. 이런 환경에서 이런 기법을 쓰면 12% 빨라진다 라는 테스트와 양적인 수치가 없으면 이게 과연 가독성 혹은 유지보수에 있어서의 어려움을 포기하면서까지 고려의 가치가 있는지를 판단할 수가 없습니다. 얼마전 어떤 책을 보니 ASP에서 성능을 이유로 주석을 가능한 자제하라라는 구절을 보았습니다. 사실상 이 말은 전혀 도움이 안되는 말일뿐더러 어떤 의미에서는 오히려 나쁜 영향을 줄수도 있습니다. HTML의 주석이 아닌 ASP의 주석은 클라이언트에게 다운로드 되지 않습니다 다음은 이전의 외국 사이트에서 발표된 테스트 결과입니다. 테스트를 위해서 각라인에다 "-" 글자를 80개씩 총 20라인 1600char의 주석을 첨가했습니다.

Benchmark = 5.57 msec/page(주석을 넣지 않았을때)
Response Time = 5.58 msec/page(주석을 넣었을때)
Difference = +0.01 msec (increase 0.1%)

결과는 꽤 주목할만 합니다. 즉 주석을 첨가하는 것은 HTML과 달리 거의 영향을 미치지 않는다는 겁니다. 파일 사이즈는 거의 2배 이상으로 늘어났는데도 불구하고 성능저조는 단지 0.1%에 불과합니다. 사실상 여기서 주목해야 할 것은 느려졌다 빨라졌다가 아닙니다. 얼마만큼 이냐가 중요합니다. 성능을 이유로 주석을 포기 혹은 가능한 자제해야 하는가를 판단하기 위해서는 이 0.1%라는 수치가 중요합니다. 수치가 나오지 않은 튜닝은 사실상 판단에 전혀 도움이 되지 않습니다. 우리는 튜닝에 있어서 가독성 이라든지 간결성 유지 보수성 등의 비수치적 영향도 고려해야 하는데 그러기 위해서는 수량적으로 판단할수 있는 것은 양적인 결과로 이끌어 낼수 있어야 합니다. 우리는 신학을 하는게 아니라 공학을 하고 있기 때문입니다.

 


튜닝에 관련된 두 번째 조언은 직접적인 테스트에 의한 결과가 아닌 단순 메카니즘의 원리에 의한 분석은 믿지 말아라입니다. 많이 알려진 오해의 예를 하나 들어보면 ASP에서 VB Script는 인터프리터 방식으로 실행되므로 컴파일되는 COM 프로그래밍으로 하는것보다 느리다. 라는 것입니다. 언뜻보면 컴파일된 컴이 빠르다는건 당연한 듯 보입니다. 최소한 NT4.0까지는 비교적 맞는 말이었습니다. 하지만 Window2000에 IIS5.0이 사용된 이후부터는 ASP 엔진과 스크립트 엔진의 발달로 오히려 반대의 결과를 내는 경우가 더 많아졌습니다. COM을 사용하는 이유가 단지 성능때문은 아니지만 주요한 이유중의 하나였던 성능은 꼭 그렇다고는 할수 없는 이유가 되어 버렸습니다. 사실상 아주 복잡한 함수등이 아니라면 오히려 더 높은 확률로 COM이 성능이 느렸습니다. 주로 COM 객체의 로드와 해제에 관련되어서 보다 많은 시간이 걸리기 때문이었습니다.

 

우리가 위에서 배울수 있는 세번째 교휸은 그러한 수치는 OS에 따라서 사용하는 언어에 따라서 심지어는 버전에 따라서 전혀 반대의 결과를 내기도 한다는 겁니다. IIS6이 나온지 얼마되지 않았고 아마도 5.0에서의 많은 사실들이 이전의 IIS4에서 IIS5에서 변동이 그랬듯이 IIS6에서는 다른 결과를 내리라 생각합니다. 즉 튜닝에 대한 3번째의 조언은 책을 믿지 말아라-_-입니다. 책이 발표된 시점과 그리고 책에서 사용하고 있는 환경과 지금 내가 사용하고 있는 환경은 다르며 이 차이는 전혀 다른 결론을 이끌어 낼수 있는 정도의 차이입니다. 지구상에 수만 이상의 수많은 직업이 있지만 경험이 별로 도움이 되지 않은 몇 개의 직업을 꼽으라면 그중의 하나는 IT 관련 직업이 꽤 많은 비중을 차지하리라 생각합니다. 경험은 때대로 독이되며 판단에 있어서의 장애요인이 됩니다. 아마도 튜닝에 있어서의 경험으로부터 배울수 있는 확실한 한가지는 이전의 경험은 별로 도움이 되지 않는다는 유연한 사고방식 정도(?) 일것입니다.

 

튜닝에 관련된 네 번째 조언은 잘못된 테스트는 잘못된 결과를 이끌어 낼수 있다입니다. 3번째의 책을 믿지 말아라-_-라는 것과 약간의 관련이 있는데 아마도 대부분의 책에서는 ADO.NET에서 Reader객체가 DataSet객체보다 읽기 성능이 좋다라고 하며 읽기 전용 페이지나 모듈에서는 가능한 Reader 객체를 쓸 것을 권하고 있습니다. C#강좌란에 ADO.NET의 황당함을 올리고 나서 이런저런 테스트를 해보고 나서 이것은 사실상 전혀 의미가 없다는걸 말하고 싶습니다. C# 강좌란에 올렸다시피 Reader와 DataSet의 I/O양은 같고 그렇다면 DB에서의 I/O가 미치는 전체 성능에서의 퍼센테이지를 감안한다면 그 어떤 다른 추가 메커니즘이 결합되었다 하더라도 1% 이하라고 결론지었습니다. 우리나라에서 발간 혹은 번역된 책 그리고 얼마전 본 외국잡지에서 이 두가지 성능을 비교한 결과를 본적이 있는데 500row 까지는 거의 차이가 없다가 1000행쯤 될 때쯤 의미있는 차이(1.5배 정도의)가 생기는 그래프를 보여주며 읽기전용에서 Reade를 쓰라는 권고를 읽은 적이 있는데 이 테스트는 방법에 있어서의 문제를 가지고 있습니다. 정상적이고 튜닝이 잘된 사이트 혹은 모듈이라면 천행을 리턴하는 것 자체에 문제가 있기 때문입니다. 온라인환경에서라면 99.9% 천행이상을 한꺼번에 보지 않고 일정단위의 페이지로 보게 됩니다. 설사 DB에서 천만행을 읽어 집계를 내더라도 그 반환결과는 천행 이상을 리턴한다는 개념 자체가 잘못된 것이며 잘된 시스템이라면 한모듈에서 500개 이상의 로우를 리턴받지 않는게 정상입니다. 즉 테스트에 있어서 문제의 책임을 전혀 엉뚱한데로 돌리고 있는것에 불과하며 두 번째로 다중 사용자인 환경에서 Reader가 가지는 접속유지시간이 더 길다.에는 전혀 언급이 없기 때문에 현실적인 테스트라고 할수 없습니다.

 

튜닝에 있어서의 5번째 조언은 절대원칙을 믿지 마라입니다. 아래 글중의 어떤 글에서 Select a.* From a, b Where a.id = b.id and b.col='aaa'와 같은 쿼리보다는 Select * From a Where id in (select id From b Where col = 'aaa') 방식을 사용하라는 조언을 보았는데 이 2개의 쿼리는 결과는 같지만 사용에 있어서 어떤 것이 좋다라는 것은 말을 결코 할수 없는 각자의 역할을 가지고 있습니다. 이 두 쿼리가 어떤 차이와 역할을 가지고 있는가에 여기에 적기에는 너무 많고 게다가 종종 옵티마이저는 이 2개의 쿼리를 같은 방식(실행계획)으로 처리해버리곤 합니다. 만물의 모든 존재가 이유가 있다 하듯이 쿼리의 사용방식에도 하나의 존재 이유가 있습니다. 중요한건 그 존재이유를 알아 상황에 맞게 적절히 사용하는 것이지 우열을 따질수 있는 문제가 아닙니다. 앞에서 원칙이라고 말한 동적쿼리대신 프로시저를 사용하라는 것도 일부의 상황에서는 예외가 될 수 있습니다. SQL 7.0시절에는 동적 SQL이 프로시저보다 빠른 경우도 있었습니다. 실행계획과 관련하여 분포도와 관련된 문제인데 이야기하기에는 너무 길어지므로 역시 넘어가겠습니다. -_)

 


튜닝에 관련된 6번째 조언은 하나의 튜닝은 다른 하나이상의 결과에 영향을 미친다입니다. 대부분의 고급 개발자들이 조언하듯이 튜닝을 할 때는 하나씩 하고 각각의 테스트를 비교하라고 합니다. 튜닝에 있어서 가장 중요한 것 중의 하나는 중용 즉 균형감각입니다. 앞에서의 조언에서 말했다시피 튜닝은 기본적으로 Trade Off이며 단순히 튜닝에 있어서의 다른쪽의 성능 문제뿐 아니라 가독성, 유지보수, 설계, 안전 등의 상호 다른 요인과 밀접한 관련을 맺고 있기 때문에 조그만 지식을 추구하지 말고 전체적인 지혜의 관점에서 봐야 한다는 겁니다.

 

그렇다고 해서 튜닝에 관련된 책은 사기-_-니 읽지마라라든가 고려할 필요가 없다라는 것은 물론 아닙니다. 저 자신도 사실상 읽는 가장 많은 비중을 차지하는 도서가 설계에 관련된 책 다음으로 튜닝에 관련된 책이며 종종 튜닝에 관련된 책에서는 성능 그 자체보다도 코드 품질에 대한 지식을 얻기도 하기 때문입니다. 또한 자신이 그 많은 상황을 직접 테스트 하지 않고도 상대적으로 짧은 시간에 저자의 다른 많은 지식을 얻을수 있기 때문입니다. 단지 강조하고 싶은건 튜닝에 관련된 책들은 성경이 아니며 그 걸 스스로가 판단하여 적절히(무척 무책임한 말임에도 불구하고) 사용할수 있는 균형감각이라는 것입니다.

 

 

만약에 이쯤에서 이 글에 사용된 여러 가지 예의 진의여부가 의심나서 직접 테스트를 하고자 하는 맘이 들었다면 이 글의 의미를 제대로 읽은 것입니다.

 

제가 다니던 대학교 컴퓨터 동아리에서 한때 "잘~"이라는 말이 유행(?)을 탄적이 있었습니다.
"선배님, 이거 어떻게 하죠?"... "잘~... "
"야~ 너 이거 어떻게 해결하는지 아냐"... "잘~ "

질문은 모두 틀리지만 대답은 오직 한마디 '잘~' 이면 모두 통과였습니다. -_-


앞에서의 튜닝의 진실 혹은 거짓말 1을 요약하자면 세상만사를 의심하고-_- 적절히 '잘~' 사용하란 얘기입니다.

조언이란게 대부분 그렇듯 일주일에 70억 벌기 유머처럼 (일주일에 70억을 어떻게 버냐구요? 하루에 10억씩 벌면 됩니다. 쿨럭~ -_-) 문제의 요지를 교묘히(?) 피해가는 거죠..


그동안 믿고 있었던 성능에 관련한 Myth에 대해 그럴듯한 경고는 해 주지만 막상 튜닝을 해야겠다 하면 무얼 어떻게 해야 하는지 어디서부터 시작해야 하는지에 대한 현실적인 관점에서 앞글은 도움이 안되기 때문에 다음은 좀 구체적인 행동강령(?)을 적어보았습니다. 다음의 행동강령들은 이미 여러 양서에서 암시적이든 아니든 반복 강조된 내용이고 항목 단위로 명확히 쪼갤수 있다기보다 서로간에 긴밀한 관계로 묶여져 있습니다. 

 

1. 목표와 비교기준이 있어야 한다.
마라토너가 달리기위해서는 골인지점이 있어야 하고 줄을 맞추기 위해서는 기준이 있어야 합니다. 자신이 제대로 하고 있다는 것 혹은 잘못 했다는 것을 명확하게 일깨워 줄수 있는 비교기준이 있어야 한다는 겁니다. 쿠베르텡이 주장한 올림픽 표어 "빨리 더 빨리"는 튜닝에 있어서는 허망한 소리에 불과합니다. 예를 들어 사이트 개발에 관해서는 가장 잘 만들어진 사이트를 비교 기준으로 삼아야 합니다. 가장 잘 만들어진 사이트는 어디서 구할까요? 많은 경우 MS나 Sun은 예제사이트 이를테면 PetShop 같은 벤치마크용 샘플을 제공합니다. 그러한 것을 비교기준으로 삼고 현재의 컴퓨터에 설치를 해서 같은 하드웨어 사양에서 같은 - 최소한 비슷한 속력이 나는지 성능테스트 프로그램으로 테스트해봐야 합니다. 같은 의미로 성능이 좋은 사이트를 만들자.. 라는건 그냥 하는말이고-_- 현재의 사양에서 이 테스트 프로그램을 써서 순간 동시접속자 50명 기준으로 rps(Requests per Second)가 200이 나와야 하며 TTLB가 1초 이내여야 한다.. 는 등의 목표가 있어야 합니다.


물론 더 빠르다면 더할나위 없는거고-_- 느리다면 최소한 그 느린 이유를 객관적이며 공학적으로 증명해낼수 있어야 합니다. 그 느린이유가 정당하다면 괜찮지만 느린이유를 잘 모르겠다거나 애매하거나 스스로에게나 다른 이에게나 납득이 안된다면 자신이 잘못 하고 있는 겁니다. 같은 하드웨어 사양에 같은 조건으로 테스트를 하는 입장에서 펫샵도 10건을 가져와서 10건을 화면에 뿌려주는거고 자신이 만든것도 10건을 가져와서 10건을 뿌리는건데 몇배씩 느려질 이유가 없습니다.


그리고 이러한 성능에 관계된 목표들은 '개발을 시작하기 전'에 요구사항 명세서에 이미 정리되어 있어야 합니다. 우리나라의 클라이언트는 '고객이 OK할때까지~'의 막무가내의 인식을 가지고 있기 때문에 초기에 이걸 정의하고 그들을 이해시켜야 합니다. 물론 그러기 위해서는 프로그래머나 PM이 어느정도의 선이 적절한지에 대해 알고 있어야 합니다. 이를테면 무작정 그럴듯해 보인다 하여 비용에 대한 고려없이 '순간 동시사용자 500명을 지원'하겠다든가 '24시간 무정전 시스템을 만들겠다' 적어논다면 이후에 큰 낭패를 겪게 될것입니다.

 


2. 성능 테스트 하는 방법을 알자
앞글의 목표와 비교기준을 설정하기 위해서는 성능테스트를 할 줄 알아야 합니다. 최소한 사이트 개발자라면 MS WAST(MicroSoft Web Application Stress Tool)와 닷넷의 ACT(Application Center Test)등의 툴이나 랭귀지에서 제공하는 방법을 통해 간단한 성능테스트를 할줄 알아야 하니다. Java계열에는 JUnit(자바의 JUnit이나 닷넷의 NUnit 시리즈는 테스트 툴이라기 보담 TDD 툴로 분류하는게 적당하겠지만..)이나 HttpUnit등의 구루(Guru) 개발자들의 공개툴을 이용할수 있습니다. 이들 툴은 대부분 설명서가 영어로 되어 있다는것만 뺀다면 메모장을 다루는 만큼이나 쉽지만 잘 알지 못해서 혹은 시간에 쫓긴다는 이유를 들어 많이 사용되지 않는듯 합니다.

자신이 그러한 툴을 직접 만들수 있을만한 실력이 된다면야 사실 이 말을 할필요도 없고 그렇지 않다면 코드의 전후에 밀리초를 계산하는것보다 위에 언급된 툴을 사용해보길 권합니다. 보통 대부분의 성능테스트 툴은 버그의 존재에 대해서도 경고를 해주며 성능테스트는 한번 하고 그만인 것이 아니기 때문에 여러번 테스트를 해보면서 내가 고친부분으로 인해 어떠한 변화가 있는지에 대한 성능테스트 결과에 대한 리포트 관리등을 해주는 여러가지 유용한 기능을 가지고 있습니다.

예를 들어 새로이 customer_history.aspx를 만들어서 custId로 VICTE를 넘기는 /SampleWeb/customer_history.aspx?custId=VICTE Path를 테스트를 하여 등록할 당시에는 에러가 없었는데 자신이나 혹은 누군가가 모르고 잘못된 수정을 하여 500 에러가 발생하였다면(자신은 이런 에러가 발생하는지 모른 상태에서) 테스트를 시작하는 버튼을 눌러놓고 여유있게 커피를 마시는 동안에 성능테스트 툴은 해당페이지에 에러가 발생하였다고 자동으로 경고를 해줄 것입니다.

 

3. 균형감각
오에 겐자부로의 세븐틴이라는 소설의 주인공처럼 세상을 단순명료 이분법으로 구분하면 적과 아군을 구분하기 쉬우므로 자기 살기에는 편하고 행복할지 몰라도 프로그래머로서는 영 아니올시다입니다. 우리는 절대선, 절대방법의 '절대'가 존재하는 신들의 영역에 살고 있지 않습니다. 우리는 '캘리포니아에 나비가 날자 중국에 태풍이 일어나는 카오스의 세계'에 살고 있으며 프로그래머는 성능에 있어서 외줄을 타고 있는 삐에로처럼 쉴새없이 장대를 조정하며 균형을 유지해야 합니다.

하지만 이것이 한걸음 한걸음 걸을때마다 장대의 크기를 바꾸어야 한다는 의미는 아닙니다. 우리는 프로젝트에 대하여 빠른 코드와 테스트가 쉬운 코드, 또는 빠르지만 위험한 코드와 느리지만 안전한 코드 가운데 선택을 해야 할 상황에 직면했을때 어느쪽의 손을 들어줄것인가에 대한 스스로의 우선 순위를 가지고 있어야 합니다. 팀원의 다른 누군가가 자신이 작성한 코드에 대해 '좀더 빠른.. 혹은 좀더 그럴듯한..' 코드를 보여주며 이렇게 작성한 이유를 물었을때 "글쎄요, 그냥 그렇게 했는데요"라고 대답한다면 혹은 전날에 스타크래프트를 하느라 잠을 잘 못잔 이유로 코드의 형태가 변하거나 아침에 먹은 반찬의 종류에 따라 코드의 우선 순위가 바뀐다면 먼저 잠시 코딩을 멈추고 자신의 우선순위에 대해 정립할 필요가 있습니다.

 

 

4. 생각을 해라
흔히 개발자들끼리는 농당삼아 손가락이 생각을 한다는 표현을 씁니다-_- 그만큼 저를 포함한 많은 프로그래머들이 생각을 하지 않고 프로그램을 짭니다. 생각의 가장 많은 비중을 차지한다는게 "기억력"정도입니다. 95년 7월 27일날의 과거 판례날짜라든가 형법 12조 27항(그게 머냐구요? 저도 모릅니다 -_)을 용케도 기억하고 있는 검사나 변호사에게는 모르겠지만 프로그래머에게는 기억력이라는 건 그렇게 큰 도움이 안됩니다. 자바의 API만 봐도 최소한 그 두껍다는 헌법과 판례책을 모두 합친것보다도 많고 '소년 탐정 김전일'의 작가가 새로 연재하는 'Q 클래스'라는 만화의 소녀탐정의 순간기억능력을 가지지 않는 이상 이전의 그 모든것과 앞으로 나올 그 모든 것을 기억하기란 불가능합니다.

'망각은 신이 인간에게 내린 최고의 선물'이라는 말이 과연 프로그래머에게는 적당한지를 떠나서 그러한 것은 피할수가 없으며 그렇기에 우리는 기억력을 보조하기 위한 많은 책과 저장매체 그리고 정보의 바다라는 인터넷을 활용할수 밖에 없습니다. 이런 이유로 누가 얼마나 많은 함수를 기억하고 있느냐는 오픈북으로 시험을 보고 있는 학생들의 차이처럼 아주 작은 차이입니다.

다음의 5번항에서도 언급하듯이 깊이 있는 생각을 반복하게 되면 그것은 하나의 좋은 습관이 됩니다. 그리고 그 습관은 이후에 우리가 굳이 생각하지 않고도 무의식인 발휘가 가능하도록 해 줍니다. 예를 들어 패턴 카탈로그에 적힌 20-30가지의 객체 프로그래밍 패턴을 읽고 차근차근 이해하기는 어느정도 경험이 있는 프로그래머에게 그리 어려운 일이 아닙니다. 우리는 수십명의 괴한에 둘러싸인 무협지의 주인공이 무공을 펼치때 무의식적인 손짓 발짓 하나가 효과적인 공격과 방어가 되는 것처럼 생각하는 훈련을 토대로 한 무의식적인 적절한 패턴의 사용경지에 이르기 것은 무척이나 어려운 일이지만 그렇기 하기 위한 노력을 게을리 해서는 안됩니다. 소프트웨어 방법론의 전문가인 엘리스테어 코번은 커크 패트릭의 4단계 모델을 예로 들면서 다음과 같은 발전 단계를 이야기 하였습니다. 무의식적 무능력 -> 의식적 무능력 -> 의식적 능력 -> 무의식적 능력

 


5. 습관을 잘 들여라
바둑을 둘줄 아는분은 이해하겠지만 바둑을 잘 두기 위해서 기원에 반만년-_-을 출근해서 날마다 아저씨 바둑을 둔다해서 절대 늘지 않습니다. 고작 5-6급 정도의 어느 선에서 맴돌 뿐이죠 차라리 10년동안 프로대국의 기보를 복기하는게 더 도움이 됩니다. 늦게나마 프로에게 지도바둑을 배운다고 해도 초기 배웠던 '어설픈 기풍'을 버리기 위해서는 그 들였던 시간보다 몇배의 오랜 시간이 흘러야 가능하며 어떤이는 바둑에 있어서 초기교육은 그 사람의 평생에 걸쳐 영향을 미친다고 하기도 합니다.(바둑에 대해 잘 상상이 되지 않는다면 당구에 대해서 생각하셔도 됩니다.)

그러나 프로그래밍에 있어서 프로그래밍 9단에게서 조기교육으로 사사를 받는것은 바둑 9단에게서 사사를 받는 것보다 더욱 힘든 일입니다. 그들은 대부분 매우 바쁘며 그들에게 직접 교육을 받는 다는 것은 엄청나게 많은 비용이 들기 때문에 우리는 '좋은 책'과 '좋은 공부방법'에 대해서 생각해야 합니다.

예전에 Turbo C를 배울때 제가 선배에게 그렇게 배웠듯이 C를 배우고 있는 후배들에게 항상 하는 말은 기초문법을 익히고 난후 다른 따라하기식의 초보자용 책보다는 strcpy등의 C의 기본 라이브러리 함수를 분석해보라고 조언합니다. 좀더 여유가 있다면 자신이 먼저 그러한 함수를 짜보고 라이브러리와 비교해 보면서 무엇이 틀린가에 대해 고민해보라고 합니다. 내가 서른 다섯줄로 구현한 함수와 단 열두줄로 구현된 라이브러리 함수와 도대체 무슨 차이가 있는걸까에 오래 생각해서 자신의 코드를 작성할때 라이브러리 코드식의 흉내를 내 보라고 하였습니다. 그러한 초기에 배우는 작은 습관은 당시에 그들이 생각했던 차이보다 훨씬 더 많은 차이를 가져오게 됩니다. 우리는 '알고리즘'이라며 매우 거창한듯 말하지만 알고리즘이란 그렇게 거창하며 접근하기 어려운 것이 아닙니다. 좋은 예제를 통한 좋은 습관을 들이는 것이 자신의 알고리즘 능력을 향상시키는 지름길이며, 동시에 유일한 길입니다.

 

 

6. 집중할곳에 집중하자
많은 연구결과가 증명하듯이 빠레또의 2:8의 원칙은 튜닝에 있어서도 여전히 유효합니다. 2:8의 원칙은 사회학이나 경제학등의 여러학문에서 약간씩 번형되어 인용되지만 튜닝에 있어서의 2:8의 의미는 코드 전체량의 20%가 전체 성능의 80%를 차지한다로 주장되어집니다. 예를 들어 로그파일의 버틀넥(Bottle Neck)은 전체성능에 큰 영향을 미치기도 합니다. 우리가 매번 메인페이지의 중요성를 강조하는 이유는 불행하게도 모든 메소드와 페이지가 평등하지는 않다는 사실을 인정하면서 부터입니다. 물론 당신이 완전주의자라서 100% 완전 튜닝을 하지않고는 뒤통수가 근질근질해서 밤에 잠을 이루지 못한다고 말한다면 아마도 당신은 죽을때까지 잠을 이루지 못하리라고 생각합니다. 그러한 모든 것을 하기전에 사이트가 바뀌거나 기술이 바뀌거나 DB환경이나 OS가 바뀌거나 하기 때문입니다. 앞마당의 잔디를 모두 손톱깍기로 깍겠다는 생각은 경제적이지 못하며 그것을 제외하더라도 이미 현실성이 떨어집니다. 100% 완전 튜닝이란 '아무리 배부른 사람도 쌀 한톨은 더 먹을수 있다. 그러므로 사람은 무한대의 쌀을 먹을수 있다'라는 논리의 허구성처럼 존재할수 없는 것입니다.

저 같은 경우 사이트 제작시 성능에 집중하는 곳은 오직 2가지입니다. DB 커넥션 담당하는 부분과 DB의 SP입니다. 그 외를 제외한 모든부분에 있어서는 가독성과 유지보수성을 우선합니다.물론 그렇다고 해서 다른 부분에 있어서의 성능을 전혀 고려하지 않는다는 의미는 아닙니다. 우리는 성능과 간결성의 두마리 토끼를 잡을수 있는 효율적인 알고리즘을 사용할수도 있으며 효율적이며 유지보수성도 좋아지는 코드에 대해 연구할 필요가 있습니다. 본질적으로는 성능과 가독성 혹은 성능과 유지보수성은 흑백논리식의 그 시소의 양쪽 끝에 위치하는 관계가 아닙니다. 그러함에도 가끔 특정한 상황에서 서로의 가치가 충돌할때가 있으며 그럴때 저는 주로 가독성과 유지보수성 혹은 테스트 용이성의 손을 들어줍니다.

 


7. 성능보다 설계를 우선해라
일찌기 자바를 개발한 제임스 고슬링은 "시간은 우리편이다" 라고 말한적이 있습니다. 자바가 나온지 꽤 오랜시간이 지나고도 아직까지 기본 아키텍쳐에 있어서의 객체지향언어로서의 그 훌륭함을 유지하고 있는 이유는 성능보다는 아키텍쳐의 설계의 그 우선을 두었기 때문입니다. 초기의 굼뱅이속도-_-는 시간이 감에 따라 하드웨어의 발달, 통신속도의 발달, 그리고 자체적인 가상머신의 발달과 JIT 등의 도입으로 인해 상당히 많은 향상을 이루어 냈습니다. 특히나 서버관련 기술에 있어서의 자바는 사이트의 느린 속도에 대한 일차적인 책임의 멍에를 벗어나게 되었습니다. 만약에 고슬링이 초기의 그 느린속도에 질린 개발자들의 불평을 해결하고자 자바의 아키텍쳐를 번형해서 성능위주로 버전업이 되었다면 지금의 자바가 가지는 그 무게감은 아마도 없을 것입니다.

물론 자바야 몇년동안 발전해왔으니 그렇다 치고 프로젝트가 몇년동안 하드웨어 발전하길 기다릴수는 없겠지만 그래도 기본적으로 설계는 성능보다 우선합니다. 설계를 하는 가장 큰 이유는 우리가 프로젝트의 미래를 예측하기 위해서이지만 또한 이 뜻은 우리는 기본적으로 미래를 전부 다 예측할수 없다는 뜻이기도 합니다. 과거의 단방향적인 폭포수 방법론(WaterFall) 보다 Iteration Design이 보다 환영을 받는 것처럼 요구사항의 변동과 더불어 설계는 부분적으로 변할것이고 그 변화에 빠르고 적절하게 대응하기 위해서는 단순하며 가독성이 뛰어난 코드여야 합니다. 프로젝트 진행중에 성능에 대한 지나친 집착은 코드를 복잡하게 만들며 가독성이 어렵게 만들고 그로 인해 많은 처리하기 어려운 버그를 낳습니다. 요구된 기능이 모두 구현되고 알려진 모든 버그를 모두 잡고 난 이후에 오직 성능만이 문제일때 코드최적화 기법을 쓰십시요.

그러나 주의해야 할 또 하나의 사항은 DB 커넥션과 Query 최적화는 마지막에 해서는 안됩니다. DB에 관해서만은 단지 예제 몇십개의 데이타만을 입력한 상태에서 프로젝트를 진행한다거나 대충 짠 Query로 나중에 해야지라고 하는것은 큰 재앙을 초래할 것입니다. DB에는 현실과 비슷한 량의 샘플데이타를 입력하여 프로젝트를 진행해야 하며 쿼리 하나 하나에는 코드 이상의 많은 노력을 기울여야 합니다. DB커넥션은 성능이라고 보다 프레임웍의 문제이며 적절하지 못한 쿼리에 늦은 발견은 오히려 DB의 설계등에 영향을 미치며 이의 파급효과는 코드 몇줄 변경으로 해결되지 않기 때문입니다. 또한 SP로 제작된 DB Query는 가독성을 해치지 않으며 엄밀하게 Trade Off의 최적화가 아니기 때문입니다.


슬금... -_)

 

'IT 이야기' 카테고리의 다른 글

다시 성능  (0) 2009.04.02
아키텍트 vs 트러블슈터 vs 컨설턴트  (0) 2009.03.26
interface  (0) 2009.03.25
Nice game  (0) 2009.03.25
멘탈 2  (0) 2009.03.23
Posted by bleujin
IT 이야기2009. 3. 25. 22:50


- 부장 : 이쪽은 필이라고 하네, 새로오게 된 법무담당 사외 이사네.
           필은 우리제품의 인터페이스를 더욱더 혼란스럽게 만들어서 고객들이 교육을 받기 위해 돈을 지불하도록 하는 일을 담당하게 될걸세

- Dilbert : 고의는 아니지만 이미 그러고 있는데요

- 부장 : 그렇지. 하지만 언제까지 운에 의존할 수는 없지 않나.



인터페이스는 일반적으로 시스템의 비기능적 요구사항에 속한다. 그래서 테스트와 더불어 프로젝트에 여유가 없을 경우 가장 먼저 제외되는 분야이다. 사실 대부분의 프로젝트에서 좋은 인터페이스란 무언인가에 대해 고민을 해본 경험조차 거의 없기 때문에 시간의 여유가 있더라도 무엇을 해야 할지 모르는 분야이기도 하다.


인터페이스에 관련하여 가장 추천할 말은 Eat your dog food 라는 격언이다. 프로그램을 만든 사람이 프로그램을 사용해보지 않으면 좋은 인터페이스에 대해 고민을 하지 않게 되므로 프로그래머와 기획자 디자이너 등 프로그램에 관여하는 모든 사람들은 자신이 만든 개밥을 매일 먹어봐야 한다.


좋은 인터페이스를 고민할때 두번째로 알아야 할 사실은 무조건 쉽게 만드는게 능사가 아니라는 사실이다. 비난도 많이 듣고 있긴 하지만 MS의 제품은 인터페이스에 관한한 가장 많은 고민을 하는 제품이다. 엑셀의 경우를 보면 초보자가 거의 쓸일 없는 메뉴가 거의 쓰지 않는 메뉴와 혼란스럽게 섞여 있다는게 비판의 주 요지이다. 이른바 80:20의 이론에 따라 자주 사용하는 20%의 메뉴만으로도 충분하지 않겠는가 라는 소리이다. 그럴듯해 보이지만 사실 20%는 엑셀을 사용하는 사람마다 다르기 때문에 어떤 기능이 20%인가에 대해 확실히 규정지울 수 없다는 문제를 가진다.


MS 제품의 인터페이스를 긍정하는 이유는 사용자의 분포에 맞는 인터페이스라고 생각하기 때문이다. 다시 엑셀의 예를 들자면 처음 엑셀을 다를때 지나치게 복잡해 보이는 엑셀의 메뉴와 어렵게 보이는 인터페이스들은 불편하기 짝이없다. 하지만 조금 더 시간이 지나고 좀더 익숙해지면 아 이런 인터페이스도 있었구나 진작 알았으면 편했을껄 이라는 소리를 슬슬 하게 되고 이런 단계를 거쳐 단축키와 매크로등을 사용하는 중급 사용자가 된다. 보통의 제품에서 일반적인 사용자의 분포는 아래 Unability의 역설의 노란 곡선처럼 입문자와 고급 사용자는 적고 중초급의 사용자의 수가 가장많지만 기능의 난이도는 반대로 중급용 기능이 적고 고급과 초급기능이 더 많다.


그래서 단지 쉬운 인터페이스 - 입문자만을 고려한 인터페이스는 초반에 접근하기에는 쉬울지 모르지만 이후 쉽지만 반복적인 인터페이스(쉽고 반복적이도 않는 인터페이스는 당연히 적극 고려해야 하지만 그런건 매우 어렵다.)에 질려하게 된다. 물론 모든 인터페이스를 어렵게 만들어서는 막 새로운 프로그램을 접하는 사람들을 쫓아내서도 안된다. 다만 다소 어려운 인터페이스일지라도 중급자용의 고급 기능을 할 수 잇는 부분은 꼭 필요하다는 얘기이다.


[그림 : Usabiliby의 역설]

'IT 이야기' 카테고리의 다른 글

아키텍트 vs 트러블슈터 vs 컨설턴트  (0) 2009.03.26
튜닝  (0) 2009.03.26
Nice game  (0) 2009.03.25
멘탈 2  (0) 2009.03.23
How vs Who  (0) 2009.03.16
Posted by bleujin
IT 이야기2009. 3. 25. 02:27

이웃의 Samurai-J라는 팀명 아래 뛰어난 팀원들의 자발적인 팀 합류와, 그리고 몇개월간의 준비등의 의욕적인 출발과는 달리 W-K프로젝트는 시작하기 전부터 위기였다.

지난해에 최고의 실적을 올린 PM은 명확히 거부 의사를 밝혔고
이전의 DeathMarch 였던 O-K프로젝트를 성공적으로 마쳤던 신임 스타PM도 부담감을 이유로 난색을 표함에 따라
공식적인 절차도 아니고 사무총장 친분을 앞세워 그넘의 '대의'라는 이유로 거의 떠맡다시피 억지로 맡게 된 PM 자리

CEO도 없는 어수선한 상황에서 충분한 지원은 기대하기 어려웠고 이전의 같이했던 스타 프로그래머들은 나름의 사정으로 모두 합류하기 어려운 상황, 중간관리자 선임에 대한 전권을 달라는 그의 소박한 조건은 되려 자신이 지목한 관리자들의 합류 거절로 무산되고 결국에는 누구나 그렇개 생각하는 한물 간 과거의 인물들로 중간관리자를 꾸려가야 했다.

대규모 프로젝트의 경험부족이 문제라고 생각되어 얼마전 회사와 감정 싸움등으로 나간 백모씨와 지난 1년간 쉬다시피한 김모군등을 반대와 우려속에서도 합류시키고 이전의 O-K 프로젝트의 신입 프로그래머를 위주로 팀을 꾸릴수 밖에 없었다.


옆 회사의 프로젝트들이 일사천리로 진행하고 있을때 해를 넘기면서 새 CEO로 지목되던 사람이 자신해서 물러나는 등의 혼잡스런 상황에서 주축이라고 생각했던 백모씨와 김모군 그리고 베테랑 프로그래머들중 몇몇이 마지막에 합류하지 못하는 등 최악으로 치닿고 상황

외로운 노PM은 묵묵히 자신이 그 모든 부담을 져가며 그다지 이익이 없음에도 자신의 요청에 응해준 팀원들과
"국가가 있고 야구가 있다"라는 촌스러운 말을 하면서 스스로의 말을 지키고자 보름의 짧은 일정동안 자신의 할일을 다했다.


사실 이런 Suicide Project가 제대로 굴러가는 확률은 너구리 라면에서 5개의 다시마 보기처럼 극히 희박하지만 팀원의 자발적인 노력으로 mission impossible project형으로 성격을 바꿀수 있었고, 진행중 예기치 못했던 성과에 환호도 있었고 실수에 대한 탄식도 있었지만 그럼에도 불구하고 최고의 성과를 이끌어넨 W-K 프로젝트 팀원들에게 한마디..

Nice Game....

'IT 이야기' 카테고리의 다른 글

튜닝  (0) 2009.03.26
interface  (0) 2009.03.25
멘탈 2  (0) 2009.03.23
How vs Who  (0) 2009.03.16
프로젝트의 예측  (0) 2009.03.12
Posted by bleujin
IT 이야기2009. 3. 23. 00:31

이승엽 "한국팀의 강한 정신력 믿고 있다"
http://www.viewsnnews.com/article/view.jsp?seq=48129

개인 능력의 열세를 한국 야구 특유의 조직력과 집중력으로 극복한다면 승산은 충분합니다.
http://news.kbs.co.kr/article/baseball/200903/20090322/1743921.html


웬지 이 두기사를 보고 궁금함이 들었다.
첫번째 기사는 그냥 읽었지만 두번째 기사는 웬지 모를 위화감이 들었다.


자발적 헌신과 정신력의 다른 뜻인 집중력과 의욕은 프로젝트에 꼭 필요한 정치요소이자, 프로젝트 관리자가 중점 관리해야 하는 팀 활력의 핵심 요소이다. 하지만 그렇다고 해서 프로젝트 관리자에게 직접적으로 "정신력을 발휘해봐" 라는 말을 듣는 건 그닥 유쾌한 기분이 들지 않는다. 특히 "요즘 팀원들의 정신력이 해이하다" 라고 듣는건 최악이다.


개인적으로 정신력 따위로 프로그래밍을 하는건 아니라고 생각한다. 오랫동안 나는 프로젝트에서 자신의 능력(그게 시간이든 지식이든간에)을 120% 발휘해야 하는게 아닌 80% 정도로 해야 한다고 생각해왔다. 사람이 집중력을 유지할 수 있는 시간은 그리 길지 않고 이 프로젝트가 끝나면 지구가 망하지 않는 이상 다음의 프로젝트나 혹은 지금 당장의 프로젝트를 위해서도 끊임없이 자신의 지식을 쌓고 자기 계발의 시간이 있어야 하기 때문이다. 결국 프로젝트를 성공시키기 위해서는 안정된 능력이 필요하다.


피플웨어에서 톰 디마르코는 개발자들은 대부분이 이미 동기 부여되어 있기 때문에 이런 이야기가 적절하지 않다고 한다.
 " 개발자는 스스로 동기부여할 수 없으며 프로젝트 관리자가 동기부여를 해주어야 한다는 생각만큼 작업자의 의욕을 꺽는 일은 없다. 프로젝트 관리자는 사람들이 얼마나 일을 열심히 하는지 일일이 평가할 필요가 거의 없다. 왜냐하면 그들은 대부분 자신의 일을 좋아하기 때문이다. "


프로그래머와 마찬가지로 소위 국대라고 불리는 스포츠 선수들도 마찬가지라고 생각하기 때문에 경기에 질때 흔히 나오는 정신력 부재 - 단순히 기사량을 채우는 의미 이상이 없는 - 등의 기사에 동의하지 않았다. 그러나 첫번째 기사에서 위화감이 들지 않았던 이유는 무엇일까 ?

그냥 "비를 드니 마당 쓸라 한다" 정도의 의미인걸까? 하루동안 생각하고 난뒤에야 그 미묘한 차이를 의식할 수 있게 되었다. 일단 어휘의 미묘한 차이와 ( "믿고 있다"와 "~면 할수 있다"의 차이) 말하는 사람의 다르면서 생기는 차이이다.


어쨌거나 프로젝트의 성공에 있어서 "긍정적인 자세"와  정신력 - 소위 집중력과 의욕-은 분명 효과가 있고 개발자의 자기 헌신도 필요하다. 하지만 결코 프로젝트 관리자가 입으로 이런걸 직접적으로 요구해서는 안되고 그렇지 않다고 비난하는 말은 더더욱 해서는 안된다. (그런점에서 최근의 MB의 긍정적 사고가 모자라서 그런다라는 말은 역효과만 불러 일으킨다.)


팀원이 충성심을 느끼고 헌신하려는 자세는 프로젝트 관리자의 구호가 아닌 미묘한 동기부여 능력에 많이 달려있다. 카리스마도 어느 정도 중요하다. 프로젝트에 어마어마한 위험이 도사리고 있다고 말해도 팀원들이 지구 끝까지라도 따라가겠다며 의욕을 보이는 경우도 있다. 그러나 무능력한 관리자 밑에서는 외계인으로부터 인류를 구하는 것이 프로젝트의 목표라고 하여도 팀원들은 노력하려고 애쓰지 않는다.



'IT 이야기' 카테고리의 다른 글

interface  (0) 2009.03.25
Nice game  (0) 2009.03.25
How vs Who  (0) 2009.03.16
프로젝트의 예측  (0) 2009.03.12
Scott Adams  (0) 2009.03.11
Posted by bleujin