● 3D TV의 구현 방식과 관련된 LG의 선공에 대하여 삼성이 대대적으로 반격을 했다고 한다. 많은 신문들이 오늘 삼성의 발표회를 참관했고, 보도자료를 받아 거의 대동소이한 기사를 쏟아내고 있다. 

● 이 기사들의 수준이란 것이 참 답답하다. 논쟁이 있는 이슈에 대해서, 기자가 주관적으로 쓴 내용이라고는 마지막에 한줄, "비교 시연결과 화질차이가 뚜렸했다" 정도다. 이런 기사, Copy & Paste 만 할 줄 알면 다 쓰는 것 아닌가. 

● 아마도, 이번 논쟁에 관심있는 대부분의 기자들은 LG측의 시연회에도 참석했을 것이고, 삼성측의 시연회에도 참석했을 것이다. 그렇다면, 직접 본 입장에서 어떤 차이가 있었는지, 어떤 느낌이었는지 주관적인 의견이 있어야 옪지 않은가. 기자는 왜 판단을 유보하는가? 결국 두 거대 기업의 눈치보기에 급급한 것 아닌가. 

● 더구나, 이번 삼성의 발표회에는 "객관적" 인 자료들이 대거 동원되었다. 삼성측의 주장에는 꽤 많은 수의 논문이 포함되어있었고, 해외평가기관의 공신력 있는 자료들이 제시되었다. 반면에 LG측은 보다 많은 체험단이 참석한 시연회가 있었다. 양측의 주장은 어떻게든 재검증 (Review)가 있어야 했고, 그 역할을 해야 하는게 IT 전문 기자들 아닌가. 
  논문이 있다면 그 논문을 구해서 읽어보고, 저자에게 재차 확인을 해볼 수도 있는 일이고, 해외평가기관과 관련해서도 LG의 최신 제품도 테스트를 해봤는지, 편광식에 대해서 어떻게 생각하는지 같은 내용들이 보충이 되어야 한다. LG의 주장에 대해서도, 좀 더 다양한 환경과 위치에서 양사의 제품을 더 많은 체험단에게 테스트를 해보는 방식으로 내용 검증이 있었어야 한다. 

● 이건 뭐, 그냥 쑈 잘보고와서 나눠준 팜플렛 보면서 추천평 쓰는 것도 아니고, 적어도 "기자" 고 "언론" 이라면 뭔가 기사에 성의가 들어갔다는 생각이 드는 글을 토해내야 하는 것 아닌가. 이건 너무 쉽게 씌여지는 기사고, 그나마 신문사마다 다 똑같아서, 클릭하는 시간도 아깝다. 좀 부끄러운 줄 알아야 한다. 
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

● 바야흐로 새학기고, 기업들의 취업 설명회 시즌이다. 조금 더 있으면 신입사원 채용이 있을 것이고, 필기시험을 통과한 사람들에게는 기술 면접을 위한 프레젠테이션 준비가 필요할 것이다. 이 모든 채용과정을 통과해 신입사원이 된다면, 회사에서 직무 적응을 위한 이른바 "신입사원 세미나" 준비를 시작하게 될 것이다. 이게 일반적인 IT 관련 회사의 모습이다. 

● IT 관련 세미나를 준비하는 것은 쉽지 않다. 여라가지 이유가 있겠지만, 우선 IT관련 신기술들은 대부분 미국에서 만들어지고, 관련된 최신 자료는 당연히 영어로 되어있다. 독해를 하는 것도 쉽지 않은데, 독해한 내용을 이해하고 요약정리하는 것은 훨씬 더 어려운 일이다.  둘째로, 간혹 번역된 자료를 찾는다 하더라도, 오역되거나, 문장의 앞뒤가 안맞는 경우가 종종있다. 심지어, 번역하는 기간 (짧게는 1달, 길게는 1년 이상)  사이에 스펙이나 컨셉이 바뀌어 버리는 경우도 있다. 셋째로, 공대생들은 일반적으로 다른 사람 앞에서 자신이 아는 바를 명쾌하게 발표하는 것이 어렵다. 아는 것을 쭈욱 나열하는 것은 잘하지만, 열심히 준비한만큼, 나열할 것도 많아 스토리가 없는 이야기가 되기 쉽다. 특히, 자신은 열심히 공부해서 잘 아는 내용을 IT배경지식이 없는 사람에게 풀어 설명하는 능력이 없는 경우가 많다. 실제로, 4학년 때 모의면접 시험장에서 졸업작품에 대해 설명해 보라는 질문에 우리과 탑이던 학생의 대답이, "802.16 WAVE 관련 프로토콜 에뮬레이터를 제작했습니다." 라고 대답을 했다. "그게 뭔가요?" 라는 면접관에 질문에 WAVE 란 단어를 반복하며 자신이 한 일을 설명했는데, 졸업작품을 같이 했던 네 명 외에는 강의실 안에서 그 설명을 알아들었을 사람이 아무도 없었다. 

● 이번에 신기술 관련 세미나를 준비하면서 알게된 몇가지 팁을 공유하려 한다. 전통적인 방법도 있고, 새로운 방법도 있다. 모쪼록 기술 면접을 준비하는 학생들과 선배들 앞에서 세미나 준비하느라 밤을 지새고 있을 신입사원들에게 도움이 되었으면 좋겠다. 

   1. 기본은 책. 세권 이상 읽어라  
 

  세미나를 준비하게 되는 내용은, 보통은 책이 한 두권은 나온 상태일 것이다. 그 책이 번역본일 수도 있고, 아직 원서 밖에 안나온 경우도 있겠지만, 책이 기본이다. 스펙문서를 책의 저자가 한번 정리를 해서 책으로 엮은 것이기 때문에, 나름의 스토리를 잡기가 편리하다. 

  어떤 주제에 대해 공부를 할 때, 서로 다른 저자가 쓴 같은 분야의 책을 여러권 읽는 것은 "다치바나 다카시" 의 방법이다. "나는 이런 책을 읽어왔다" 에 보면, 그는 새로운 탐구대상이 정해지면 책을 3m, 혹은 30만엔 어치 읽는 다고 한다. 그렇게 어떤 분야의 책을 여러권 읽다 보면 각각의 책 마다 중복되는 내용이 있기 마련인데, 바로 그 부분이 그 분야에서 가장 중요한 내용이란 뜻이다. 그럼, 다시 그 중요한 부분에 대해 심화 설명한 책을 찾아 읽어가는 방식이 다치바다 다카시가 연구할 때 사용하는 방식이다. 세미나를 준비하면서 그와 관련된 책을 여러권 읽어보면 그 분야에서 가장 중요한 부분이 보이기 시작한다. 

   2. 책의 내용을 스펙 문서에서 확인하라
 

  앞서 말했듯이, 책은 출간되는데 시간이 걸린다. 원서라 하더라도 현재 최신 스펙과는 다소간의 차이가 있을 수 있다. 안드로이드 같이 계속해서 발전해 나가는 분야의 경우 몇달 사이에 새 버전이 나오면서 기존 API가 완전히 달라지거나 쓸모없는 내용이 되버리는 경우도 있다. 연구하는 분야가 신기술, 살아 움직이는 프로젝트에 관련된 것이라면 반드시 최신 스펙문서와 책에서 참고한 스펙문서와의 차이점을 확인해야 한다. 

  이 부분을 간과했다가는 세미나나 기술면접 자리에서 바보될 수도 있다. 

   3. 영문판 위키피디아 (Wikipedia) 를 활용하라 
 

  반드시, 영문판 위키피디아를 활용하라. 한글판은 안된다. 가장 큰 이유는 한글판은 영문판에 비하여 내용이 부실한 경우가 많다. 가장 한국적인 주제라고 할 수 있는 "화차 - 신기전" 에 관한 내용도 영문판 위키피디아의 내용이 한글판을 압도한다. (직접 확인해 보기 바란다. 깜짝 놀랄 것이다.) 미국에서 개발된 IT 신기술에 관해서는 더 말할 필요도 없다. 
 
  다만, 어떤 내용에 있어서는 책에서 중요하다고 생각하는 내용과 위키피디아에서 중요하다고 생각하는 부분이 다를 수 있다. 이런 경우 2번을 믿는 편이 좋다. 위키피디아는 시간이 없을 때, 특정 용어에 대한 정의를 내리고 요점을 파악하고, 연관된 다른 기술분야를 빠르게 탐색하는데는 도움이 되지만, 경험상 "발표자료용 스토리"를 짜는 데는 도움이 되지 않는다. 중요한 내용을 골라내는 것은 1번의 방법이 기본이다. 


★★ 여기부터는 중요체크 ★★


   4. 다른 사람의 세미나를 들어라  
 

  구글을 검색해 보면, 특히 IT 분야의 경우, 다른 사람이 관련 주제를 가지고 세미나나 프레젠테이션을 한 동영상을 쉽게 찾을 수 있다. 유튜브 (https://www.youtube.com), 비메오 (http://www.vimeo.com), TED (http://www.ted.com/) 등이 유명한데, 기술적인 자료는 TED에는 별로 없을 것이다. 소스가 어디이던 간에, 구글 검색하면 다 나온다. 

  이곳에서 공부하고자 하는 분야의 세미나를 들어라. 간혹 MC 스나이퍼 저리가라 할 정도의 속사포 랩을 구사하는 사람도 있고, 알아듣기 어려운 인도식 영어를 하는 경우도 있지만, 왠만하면 알아들을 만은 하다. 영어를 완전히 알아듣지 못할지라도 발표자료와 어느 부분이 중요한지 강조하는 부분, 발표 스킬과 눈을 끄는 자료와 사진, Demo 등은 충분히 구할 수 있다. 부장님 이하 모든 사람을 자게 만들 뻔한 세미나를 모든 사람이 유쾌하게 웃으며 듣는 세미나로 바꿀 수도 있다. 자료, 비유, 데모 만 건져도 성공이다. 

  기술면접에 있어서도 마찬가지다. 슬라이드나 참고자료, 데모는 따오지 못하겠지만, 발표 주제에 대한 핵심 내용을 파악하는 것은 충분히 가능하다. 그리고 이미 들어본 주제에 대한 "아는 척" 하는 데는 이보다 더 좋은 방법이 없다. 

   5. 다른 사람의 슬라이드를 참고하라  
 

  참 고맙게도, 세미나 동영상 외에 슬라이드와 핵심 내용을 공유하는 사이트가 있다. 슬라이드쉐어 (http://www.slideshare.net/) 이 그곳이다. 간단한 회원 가입만으로 기술 세미나 관련 슬라이드를 다운 받을 수 있다. 그말은 곧, 뛰어난 이미지, 그래프, 소스코드 (PPT용으로 캡춰된 것이지만) 등을 내 세미나에 사용할 수 있다는 뜻이다. 4번 못지 않게 귀중한 자료들을 얻을 수 있다. 다만, 슬라이드와 함께 했던 발표내용은 좀 단편적인 요약밖에 없다는 것이 단점이다. 


   6. 결국, 영어다.  
 

  불행히도, 최신 자료는 영어로 되어있다. 참고할 만한 세미나도, 발표자료도 영어로 되어있다. 영어가 안되면 모든게 그림의 떡이다. 

  공대생이라면, TOEIC 점수에 매달리기 전에, 원서와 씨름하고 매달려라. 스펙문서, 기술자료, 최신 트렌드 관련된 블로그 포스팅 하나라도 더 보고, 직접 번역도 해봐라. 공대 1, 2 학년 때 해야 하는 일 중 가장 중요한 일은 프로그래밍 언어를 읶히는 것 보다영어능력 향상이라고 생각한다. 프로그래밍 언어는 신기술 나오면 자신이 공부하지 않은 분야로 갈야타는 일도 빈번하지만, 영어는 죽을 때까지 쓰는 거고, 신기술 나오면 더 절실해 지는 것이 영어다. 스펙 보다다, 책 보다가 막히는 부분이 있으면 저자에게 직접 문의 메일을 쓸 수 있는 수준의 영어는 갖춰놓으면 좋겠다. 

   7. 세미나, 기술면접도 스토리가 필요하다
 

  사실, 이 포스팅을 시작한 것은 4번, 5번 관련된 조언을 하고 싶어 포스팅을 하게 되었다. 하지만, 역시 기본은 책이다. 책을 읽고 듣는 세미나와 그냥 듣는 세미나는 천지차이다. 참고는 하되, 결국 자기 세미나를 자기 스토리를 가지고 해야 하는 것이다. 

  세미나던 기술면접이던간에, 사람들 앞에서 발표하는 것은 "이야기"하는 것이고 "이야기"는 기승전결을 갖춘 스토리가 필요하다. 세미나와 면접은 주로 두괄식으로 주제를 먼저 이야기 하고 설명해 나가는 방식이 되겠지만, "왜" 이런 기술이 나오게 되었는지 설명하는 배경(기)부터 어떻게 진행되어 왔고 (승) 현재 어떤 문제점, 난관이 있으며 (전), 앞으로는 어떻게 진행되어 나갈 것이다 (결) 는 한편의 스토리가 있어야 한다. 

  IT 기술은 갑자기 툭 튀어나온 것이 아니다. iPhone 이전에 iOS가 있었고, 피쳐폰 시장이 있었다. 모든 것은 기승전결의 스토리를 만들 수 있다. 서사구조를 갖춘 이야기를 할 때에 세미나던 기술면접이던 사람들이 집중해서 듣는 발표를 할 수 있다. 

  발표 자료 양이 많다고 느껴진다면, 과감하게 뺄건 빼고 자신의 이야기만 남겨라. 나머지는 "다음에 새로운 주제로 발표하겠다" 거나 "더 알고 싶으신 분은 이 자료를 참고하라" 고 레퍼런스를 제공하면 되는 것이다. 모든 것을 다 하겠다는 공대생의 욕심이 화를 불러온다. 기술면접도 마찬가지다. 거짓말만 안하면 된다. 아는 것을 설명하는 기술을 보는 것이지, 모든걸 다 아는 사람을 뽑는 자리가 아니다. 

  

● 몇년 만에 세미나 준비를 하다보니 나름 노하우가 많이 생겨있다는 것을 느껴서 포스팅을 합니다. 후배님들에게 많은 도움이 되었으면 좋겠습니다. 
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2011.03.05 21:43
    댓글 주소 수정/삭제 댓글
    크게 공감가는 내용입니다.
    졸업을 1여년 앞두고 딱히 스펙이라 할 만한 것들은 갖췄는데,
    부끄러운 영어 실력임에도 불구하고 스펙이 갖춰졌다는 것 자체가 아이러니한 것 같아
    수개월째 지구 반대편까지 건너와서 어학연수를 나와있네요.

    그런게 영어 공부를 하면서 한번씩 영화나 드라마 영자막 번역을 하며 느낀바로는...
    한국어 공부도 만만치 않게 해야할 듯 합니다. :)
    • 2011.03.06 08:06 신고
      댓글 주소 수정/삭제
      물론, 내용을 "번역" 하려면 한국어 공부도 많이 해야 합니다. 한국어 는 어미변화가 풍부해서, 정말 쉽지 않은 말이지요. 제 블로그에도 조엘 온 소프트웨어 블로그의 글을 번역한 것들이 좀 있습니다.

      다행히 IT 필드에서는 굳이 번역하지 않고 원어 그대로 써는 편이 더 이해하기 좋은 편이기 때문에, 약간은 더 쉬운 편입니다. 중요한 것은 핵심을 캐치하는 것이겠지요.

● 오늘도 휴대폰과 이메일을 통해서 스팸 메일이 날아든다. 문자 메세지 받을 때 마다 거의 한건도 안빼놓고 스팸신고를 하고, 스팸 편지함도 열심히 비우지만, 시간이 갈수록 양은 점점 늘어난다. 내 개인정보가 샌다는 것도 몹시 기분 나쁜일이지만, 각 통신사와 포털들이 스팸 필터링을 강화하겠다고 열심히 주장함에도 불구하고 여전히 뾰족한 해결책이 나오지 않는 것은 이해하기가 어렵다. 

● 왜냐하면, 스팸 필터링에 대한 궁극의 해결방법이 있기 때문이다. 2005년에 출간된 폴 그레이엄의 "해커와 화가" 에서 "스팸을 위한 계획" 이란 글에서 그 방법을 소개하고 있다. 간단하게 설명하면, 내용 기반으로 스팸을 필터링 하는 방법이다. 

● 현재의 필터링 방식은 특정 단어나 문자열이 들어간 것을 걸러내는 방식이다. 예를 들어, "사과" 라는 단어가 보기 싫으면 "사과" 라는 단어를 필터에 등록하고, 이후 "사과" 가 들어간 문자 메세지나 이메일은 사용자에게 보여주지 않는다. 하지만, 이 방식은 한계가 분명해서, "사 과", "사★과" "4과" 와 같이 문자열을 회피해 버리면 아무 소용이 없다. 더 나아가 "상감", "ㅅㄱ", "죄송" 과 같이 "사과" 를 유추할 수 있는 다른 단어를 들이대는 경우 필터는 아무 힘을 쓰지 못한다. 이런 방식의 스팸필터 때문에 아무리 열심히 신고를 하고, 스팸 메일로 등록을 해도 회피하는 수단이 생겨버린다. 더 나아가, 반어법이나 외국어까지 동원해서 - ㅅr 과 - 사용할 경우, 더 체크하기가 어렵다. 

● 내용 기반 필터링의 경우는 좀 다른다. 스팸 메일도 어떤 "정보" 를 수신인에게 전달하기 위한 것이기 때문에, 문자열을 깨던, 특수 기호를쓰던 어떤 "내용" 을 담고 있다. 어떤 메일을 수신한 사람들이 그 메일을 스팸으로 신고하게 되면, 이후 그 메일과 내용이 비슷한 메일이 또 오면 그 메일은 메일 서버가 모두 버려버리는 방식이다. 10명 이상의 신고, 95% 이상의 유사율 과 같이 역치를 설정할 수 있고, 역치를 적절히 조정하면 스팸 필터의 정확도는 더 올라간다. 추가로 사람이 약간만 개입하면 99.9% 이상의 스팸을 걸러낼 수 있다. 필요한 것은 스팸 신고를 열심히 해주는 사람들이 필요한데, 각 포털사의 직원들만 확실하게 신고해줘도 충분한 표본을 얻을 수 있을 것이다. 

● 얘기가 조금 벗어나지만, 불법 의료행위, 불법 도박장, 불법 사채, 불법 유흥업소 같은 것들을 경찰이 모른 다는 것도 이해가 잘 되지 않는다. 위에 예로든 것들은 모두 고객을 모으기 위해서 "광고" 를 해야 하는데, 이런 내용은 당연히 많은 사람이 보도록 광고를 한다. 아주 규모가 작은 상태에서 점조직으로 운영하는 경우라면 쉽게 알기 어렵겠지만, 사업 확장을 위해 불특정 다수를 상대로 광고를 하기 시작하는 시점부터는 모든 정보를 공개되는 것과 마찬가지기 때문에, 경찰만 모를 수는 없는 일이다. 

● 이미 강력한 해결책이 나온 상태에서 아직도 스팸 필터링이 완벽해지지 못하는 이유는 무엇일까? 뭔가 통신사나 포털의 수입과 연관된 부분이 있는 것인가? 아니면 알고리즘을 다 알려준 상태에서도 실제 구현이 어렵기 때문일까? 이건 마치 우리 주변에 어디 어디 가면 불법 경마장이 있고, 어디에 가면 여전히 불법 오락실이 돌아가고 있는 것을 알지만 경찰력이 미치지 못하는 것과 비슷한 것일까? 

● 아침부터 한무더기 스팸 메일을 지우다 문듣 생각이 나서 몇자 적는다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  전에도 포스팅을 했었지만, 문명 5는 센세이션을 일으키고 있고, 엄청나게 재미있고, 또 엄청나게 중덕성이 강한 게임이다. 그러나, 분명한 한가지는 문명 5는 느리다. 최신의 I5 CPU와 4GB 메모리, SSD를 장치하고도 한턴 한턴이 상당히 느린데, 인터넷을 찾아본 결과로는 일단 그래픽카드 쪽을 이야기하는 글이 상당히 많다. 그러나, 내 생각에는 AI 연산이 더 큰 문제일 것 같은데, 이유는 Map이 small map이어도 느리고, 그래픽카드 설정은 문명5가 스스로 설정하는 방식으로 되어있기 때문이다.

  인터넷에서 찾은 몇가지 부정적인 리뷰를 번역하여 옮긴다.

 
   Civ 5 sucks 문명 5는 형편없다. 
 

Civ 5 sucks
  원문보기 : http://www.halfsigma.com/2010/09/civ-5-sucks.html

  한 주 전에도 문명5가 출시된다는 글을 썼습니다.

  예, 전 이 게임을 했고, 이건 별로입니다. 엄청나게 지루합니다. 전 다시는 이 우습기짝이없는 반응없는 게임을 하지 않을겁니다. (컴퓨터가 각각의 움직임마다 생각을 지나치게 오래합니다.)  또, 짜증날정도로 어수선한 인터페이스는 계속해서 메세지창을 클릭하게 합니다. 이 게임을 오랜시간 플레이해본 사람은 누구나 정말 떨어지는 AI와 문명 4에의 뛰어난 점이었던 "전술의 조합"이 결여된 점에 대하여 불만을 표시합니다.

  저는 문명 5보다 문명 4를 강력 추천합니다. 아마존에서 문명 4 BTS 확장팩은 $10.49 밖에 안하는데 비하여 문명 5는 $50나 하기 때문인데, 이건 엄청 큰 세일이빈다. (주 : 문명 4 확장팩이 겨우 만 3천원 정도이군요.) 

  댓글 중,

 #1 오, 정말 사실입니다. 저도 막 문명 5를 구입해서 이틀 동안 플레이 했지만, 이게 새로 사서 할만한 가치가 있는지 잘 모르겠습니다. 이건 별로입니다. 전 문명 5를 싫어하고, 다시 문명 4로 돌아갈 예정입니다. 문명 시리즈를 더 망쳐놓는 사람들은 엉덩이를 차버려야 합니다.

#2 동의합니다. 문명 4가 훨씬 더 재미있는 게임입니다. 문명 5의 컨셉 - 특히 유닛들 (한 타일에 한 개만 머무름, 빠른 움직임, 운거리 공격가능) 은 좋아하고, 도시 내졍 (City states)에 관해서도 문제가 없습니다. 하지만, 개발진은 식량 / 생산 / 금 (Food / Production / Gold)간의 전통적인 균형을 날려버리고, 오직 금만이 세상을 지배하게 만들었습니다. 재미없어요.
 
#3 "번역 : HS는 느린 컴퓨터를 가지고 있습니다. 이 게임에 대한 좋은 리뷰가 계속 올라오고 있습니다."

  이 게임은 하이 엔드 시스템에서도 너무 느리게 돌아갑니다. 게임 관련 언론사들로부터 계속해서 크고 작은 호평을 담은 리뷰들이 올라오지만, 그건 그들의 광고 수입이 어디로부터 오는지를 알기 때문입니다. 마찬가지로, 대형 언론메체의 게임 리뷰는 피상적인 수준입니다. 전 그 리뷰어들이 몇시간 이상 게임을 해보지 않았을 것이라고 생각합니다.

  그럼에도 불구하고, 팬들의 의견은 거의 만장일치로 이 게임은 후진 똥차같고, 바보 같다는 것입니다.


 음, 아직까지는 문명 5가 대단하다는 평이 한국 블로그들의 대다수 인 듯 합니다만, 저와 비슷한 생각을 같고 계신 분들이 조금씩 늘어나지 않을까 싶습니다. 문명 5는 분명히 아주 많이 느리고, 앞으로 많은 튜닝 - 전작도 패치가 3.18까지 갔습니다. - 이 필요할 것 같습니다. 튜닝이 좀 진행되서 속도가 나아지면, 그 때 다시 봉인을 풀 생각입니다.



Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 지나가는 행인
    2010.10.08 22:43
    댓글 주소 수정/삭제 댓글
    글쎄요.. 저는 i7에 램이 6기가에 hd4850쓰고있는데 솔직히 게임을 하면서 오래걸린다는생각은 안해봤네요..
    그래픽적인 풀옵일경우 게임이 좀 끊끼는거 빼면 옵션타협주고(타협줘도 그래픽은 깔끔한게 좋더군요)
    하는데 정말 큰맵은 해본적은 없지만 스몰이던 타이니던 다 해봤지만 300턴갈때까지 ai로 인해 큰 렉이 걸린적은 없네요...

    그래픽관련셋팅은 몬한다고 되어있는데 실제 자세한 사항은 하지 못해도 엥간한 설정은 다 가능하구요

    하이엔드에서도 끊낀다고 마구 그러는데 저는 잘모르겠네요. 그리고 제컴도 지금으로 치면
    하이엔드급이라고 말하기엔 급이 떨어지는편이죠..

    지금와서 문명4가격을 문명5가격하고 비교하는 외국인은 참 넌센스네요.
    5년전에 발매된게임을 지금 갓나온 게임가격하고 비교하다니...

    직접 플레이를 많이해본지는 모르겠지만 금으로 모든게 해결된다는게 말은 맞지만
    기본적으로 유닛이나 건물완성시키는 돈이 몇백단위인데 쉬운것도 아니죠.
    여전히 망치의 위력은 엄청난 물량을 순식간에 뽑는게 가능하고 식량이야
    전이랑 마찬가지이고 돈같은 경우는 문화면에서는 꽤나 유용해졌지만
    돈으로 모두 해결한다고 말하는거 보면 문명5를 많이 안해본것 같네요.
    (오히려 망치로 계획도시 만들면 유닛 돈쌓이는거 보다 훨씬 빠른속도로 생산가능합니다.)

    역으로 까고 문명4를 찬양하는 외국인들에게 문명5를 얼마나 즐겨봤는지 물어보고 싶네요 :D
    • 2010.10.09 09:40 신고
      댓글 주소 수정/삭제
      저도 글에 적은 것 처럼 i5에 4G RAM에 SSD 까지 쓰지만, 음, 문명 4에 비하면 아주 많이 답답합니다. 게임이 좀 많이 답답하네요.
      i7 이라면 좀 더 많이 개선이 되었을수도 있겠습니다만, 기본적으로 멀티코어 성능을 다 끌어내지 못하는 것이 아닌가 싶습니다.
  2. ee
    2010.10.09 09:22
    댓글 주소 수정/삭제 댓글
    좀 하다보면 버벅이던데 게임 자체의 문제인 것 같네요. 다른 게임은 그렇지 않으니까요.

  몇년전에 치뤘던 입사 시험 중, 영어 토론 면접이 있었다.  8명의 지원자가 면접장에 들어가기 직전에 주제를 제시받고, 바로 방안에 들어가 면접을 진행하는 방식이었는데, 우리 조가 받은 주제는 "한자 교육은 강화되어야 하는가" 였다.

  8명중 두명은 꽤 유창하게 말했고, 나를 포함한 다른 6명은 그냥 그랬다. 기본 커트라인이 토익 650 정도였으니, 다들 일반 회화는 무리가 없었으나, 저런 주제와 관련해서 이야기하는 것은 조금 무리가 있었고, 우리나라 분위기 상 옆에 앉은 지원자를 공격하는 형식이 되기도 어려워 토론은 되지 않고, 그저 외국인 면접관에게 주제에 관한 자기의 생각을 한마디씩 하는 정도였다.

  앞서 유창하게 말한 두 명은 한자 교육이 필요하다 - 한국어의 단어의 어원이 많아 많이 아는 것이 유리하다 - 는 내용으로 발표를 해서, 난 필요 없다는 취지로 말했다. 본래 내 생각과도 같기도 했고, 조금 다를 필요가 있다고 생각했기 때문이다.

  영어로 뭐라고 말했는지는 잘 기억이 나지 않으나, 문장이 자주 끊겼고, 단어 위주로 말했던 걸로 기억된다. 그당시 내 영어 실력이 그정도 였고... 그나마 다행인건 말도 못하고 가만히 있기 보다는 뭐라고 계속 말을 했다는 점이다. 내용은 "사람들이 외국어를 쓰는 것은 자신의 모국어에 부족한 단어를 보충해줄 세컨 랭기지가 필요하기 때문이다. 로마인들은 그리스어를 배웠고, 미국인들은 라틴어나 프랑스어의 도움을 받는다. 우리 선조들은 한자의 도움을 받았지만, 오늘날은 영어로 충분하다" 였는데, 영어로는 상당히 부끄럽게 말했다.

  그 뒤로 이 질문에 대해 영어로 대답을 만들어 보는 것은 내가 심심할 때 마다 해보는 일이 되었다. 어떤 단어로 어떻게 문장을 만들었으면 더 잘했을 텐데 하는 생각을 지금도 한다. (아, 회사는 합격했었다.) 다양한 논거로 대답을 만들어보고, 어떤 단어가 필요하다는 생각이 들면 사전도 찾아보곤 한다.

  만약 오늘 다시 면접을 보고, 같은 주제를 준다면 이렇게 말했을 것 같다.



 " As you know, Korean character, 한글, doesn't have capital latter. So, parents used Chinese characters to highlite,  & distinguish some words. Sometimes to emphasise the meaning of words, writers used Chinese characters. 20 years ago, many company names & logos used Chinese characters. For example, 삼성, 금성, 선경, 제일제당, 포항제철, etc. But, nowadays, Samsung no more use Chinese characters on ther logo, 금성 became LG, 선경 became SK, 제일제당 became CJ, 포항제철 became POSCO. It's a trend. Englsh is more powerful then Chinese characters now. I think, English is enough."

  여러분이 아시듯이, 한글에는 대문자가 없습니다. 그래서 아버지 세대에는 한자를 몇몇 단어들을 강조하거나 구분하기 위해서 사용했습니다. 종종 단어의 뜻을 강조하기 위하여 한자를 사용했습니다. 20년전만해도, 많은 회사이름과 로고에 한자를 사용했습니다. 예를들면, 삼성, 금성, 선경, 제일제당, 포항제철 등 입니다. 하지만, 오늘날에는, 삼성은 로고에 더이상 한자를 사용하지 않습니다. 금성은 LG가 되었고, 선경은 SK, 제일제당은 CJ가 되었고, 포항제철은 POSCO가 되었습니다. 이것은 트렌드 입니다. 요즘에는 영어가 한자보다 더 강력합니다. 제 생각에는, 영어면 충분합니다.



  뭐 논거는 좀 이상하고, 이야기의 흐름에 비약이 있는 것도 사실이지만, 회사 영어 면접이라면, 난 저렇게 이야기할 것이다. 쉬운 영어에, 이해하기 쉽고, 느낌이 오고, 재미있고, 기업들의 이야기를 하니까. 입사 대상 회사를 맨 앞에 말하고, 혹은 회사의 옜날과 지금 로고를 손으로 그려서 보여주기라도 한다면 효과는 몇 배가 될 것이다. 

 PS. 삼성과 금성의 옜날 로고를 기억하시나요? ㅋㅋ 20년쯤 전의 잡지에서는 쉽게 찾을 수 있답니다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  요즘들어 부쩍 팀에 급박한 일정이 늘어났다. 말도 안되는 수준으로 일정을 막무가내로 당기고 있는데, 이건 개발을 하자는 건지 실패를 하자는 건지 이해가 안된다. "S/W 공학의 사실과 오해"에 나오던 이야기가 생각난다. 개발에 관해서 가장 모르는 사람이 일정을 잡는다는 말 말이다. 주로 회사의 경영쪽 사장님이나 영업 담당자들의 입김이 들어갈 때 이런 일이 벌어지는데, 작금의 사태도 어처구니가 없을 정도다.

  곰곰히 뒤를 돌아봤다. 올해들어 경제가 어렵다는 이유로 연봉은 작년과 동일하게 동결되었지만, 실질적으로는 20% 이상 줄었다. 각종 수당과 성과급이 이런 저런 이유로 삭감 될 예정이기 때문이다. 다시 생각헤봤다. "지금과 같은 수준의 연봉이었다면 이 회사에 입사를 결정했을까?" 대답은 "고민을 많이 했을 것이다" 이다. 난 대학교 4학년 4월에 입사 확정되고 다른 회사는 쳐다도 안보고 입사를 했다. 내 또래에서, 입사 지원서 딱 한장 써봤고 면접 딱 한번 해봤다는 사람이 나 말고 또 있을지 모르겠다. 솔직히 몇몇 사람들은 내가 이런 얘기 하면 똘아이 보듯이 본다.

  이런 결정을 내렸던데는 무엇보다 연봉 수준이 마음에 들었고, 둘째로 일의 역동성 - 100일동안 집에 못들어가서 여자친구에게 차였다던가, 일년의 절반을 출장으로 나가있다가 들어오니 변기 물이 다 말라있었다 등의 전설들 - 이 마음에 들었기 때문이다. 근데, 요즘에 와서, 이 조건들이 경력이 쌓이는 것과는 반대 방향으로 줄어들고 있다.

  조엘 온 소프트웨어에서 말하는 좋은 개발자를 구하기 위한 기본적인 조건 중 하나는 "경쟁력 있는 월급" 이다. 아무리 채용시장이 얼어붙고, 취직이 어렵다고 해도, 상위 1%는 살아남는다. 그리고, 그 1%는 실제로 30%이상의 회사에 복수 합격한 사람들이다. 내 입사 동기중에는 서울의 그저 그런 대학을 나왔지만, 우리 회사 외에 S ,P, K 같은 쟁쟁한 회사에 모두 합격한 친구도 있었다. 결국 회사 입장에서는 아무리 사람 뽑기가 쉬워도, 똑똑한 개발자를 구하기 위해서는 다른 회사보다는 경쟁력있는 조건을 유지해야 한다는 것이다.

  특히 경기가 않좋다는 이유로 피부에 와닿는 부분을 줄일 때 직원들은 마음에 상처를 받는다. 야근수당, 특근수당, 출장수당 같은 비용적인 부분들과 식대지원, 경조사 지원 같은 부분들에 손을 대면 회사에 대한 신뢰도에 큰 상처를 받는다. 법을 준수하고, 직원을 정말로 가족같이 생각하는 회사라는 생각에 영향을 준다는 얘기다. 개발자에게 좋은 컴퓨터 지급을 미루는 것은 "시간으로 때워"라고 말하는 것과 같은 의미다.

  취업 대란이라는 말, 회사 입장에서는 대단히 좋은 기회처럼 보이겠지만 - 대통령부터 나서서 신입사원들 연봉 깎으라는 망발을 해대니 말이다 - 우수인재는 한정되어 있고, 결국 채용은 이 한정된 우수인재를 두고 더 많은 회사들이 벌이는 싸움이다. 이런 저런 이유로 직원들에 대한 지출을 줄이면 결국 고만고만한 평범한 사람들만 꾸역꾸역 모여들 뿐이다. 개발자는 특히 더하다. 조금만 이 쪽 일을 해본 사람이라면, 똑똑한 사람 7명이 300의 직원과 30명의 과장이 있는 팀 보다 더 나은 결과를 낼 수있다는 사실을 잘 알것이다.

  아하.. 간만에 무료봉사를 하니 별생각이 다드누나.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009.06.10 14:59 신고
    댓글 주소 수정/삭제 댓글
    회사는 우수한 인재를 원합니다. 살아 남는데 우수한 인재요~
    • 2009.06.12 00:05 신고
      댓글 주소 수정/삭제
      살아 남는다라... 요리조리 잘 빠져나가는 사람을 뜻하는 걸까요? 그런 사람을 몇명 본 적도 있는 것 같습니다만...
  2. 2009.06.11 23:53
    댓글 주소 수정/삭제 댓글
    블로그 제목이 '컴공과 1학년'이어서 학생인줄로 착각하고 있었습니다. ^^;
    허긴 내용의 내공이 너무 깊어서 좀 이상하다 했지요 ^^;
  3. 밍밍
    2010.06.16 17:20
    댓글 주소 수정/삭제 댓글
    님의 글이 재미있고 공감되는부분이많아 자주보게되네요..
    블로그이름을 좀더 창의적으로 바꾸면 더 많은 사람들이 찾아 올것 같은데요...
    우선 엔지니어 이신것 같은데 공대 나오더라도 다시 mba도 따고 자기개발을 하시면 언젠가 스텝보다 라인이 될수있지않을 까요.. 좀더 나이들때를대비해 ..

  직원들 개개인에 대한 평가는 인사권자의 권한이자 상사의 고유한 권한이다. 그리고 대부분의 회사들은 인사평가에 의하여 다음해 연봉을 결정 짓는다.

  고과를 매기는 기준으로 수없이 많은 기준들이 제시되어 왔다. 그중 가장 대표적인 것이 근속연수와 업적평가 일 것이다. 근속연수는 말 그대로 회사에서 업무에 종사한 기간에 따라 고과를 매기는 것이고, 업적평가는 그 직원이 회사의 이익에 기여한 정도를 평가한다. 둘 다 객곽적인 지표로 인정받으며 널리 사용된다.

  문제는 이 두가지 지표가 충돌하는 상황이다. 과거 제조업의 시대에는 같은 일에 한 달이라도 먼저 투입된 사람이 더 나은 결과를 가져왔다. 나사를 조여도 하나라도 더 조였고, 어려운 문제가 생겼을 때는 경험에서 나오는 노하우를 이용해 문제를 해결하는 능력도 더 좋았다. 이 시대에는 문제 될 것이 별로 없었다.

  하지만, 오늘날, 특히 IT분야에서는 시간에 대한 능력차이는 미미하다. 오히려 대학에서 막 학위를 받아 온 사람이 회사에서 같은 일을 반복한 사람보다 더 신기술에 익숙한 경우도 많다. 신입사원으로 입사했지만, 병역특례나 아르바이트, 혹은 독학으로 3 ~ 10년에 이르는 경험을 갖고 있는 경우도 흔해졌다. IT분야에서 점점 더 중요시되는 어학능력의 경우, 근속연수와 아무런 상관 관계가 없다.

  하지만, 한국 사회에서는, 특히 대기업에서는 여전히 연차가 중시되는 분위기다. 특히 승진을 앞둔 사람들을 배려해서 좋은 고과를 몰아주는 경우가 많은데, 이로 인해서 능력이 좋은 신입사원들이 불리한 평가를 받는 경우가 종종있다. 객관적으로 평가를 하겠다고 공언하지만, 입사년도 라는 객관적 자료를 "승진을 위한 배려"라는 이름으로 주관적으로 해석하는 경우가 생긴다. 이에 대해서는 찬반 의견이 많다. 승진을 앞둔 사람들은 당연히 찬성할 것이고, 조직의 화합이라는 측면에서 바라보는 사람도 찬성하는 사람들이 많다.

  문제가 생겼다. 연차를 중시한 인사에 불만을 품고 우수한 신입사원이 퇴사를 결정했다. "우수한" 신입사원임은 퇴사 후에 객관적으로 증명됬다. 예를 들면, 경쟁회사로 옮기거나, 선도회사에 입사하거나, 아주 수준 높은 대학에 진학하는 경우 등이 있겠다. 고과평가의 결과 우수 사원을 잃어버린 것이다. 고과평가가 잘못되었다 라고 결론을 내릴 수 있을 것이다.

  이 잘못된 고과평가는 누구의 잘못인가? 누가 책임을 져야 하는가? 우수 인재를 놓침에 따라 줄어든 회사의 이익은 누가 보전하는가? 또, 잘못된 인사고과에 관한 이야기를 듣고 입사를 포기하는 우수 인재들이 발생한다면, 이는 누구의 잘못인가? 회사의 분위기, 조직문화를 잘 못만들어낸 CEO의 책임인가? 아니면 신입사원에게 희생을 강요한 인사권자의 잘못인가? 우수한 신입사원을 설득하지 못한 직속 상사의 잘못인가/

  대개의 경우, 이런 경우 책임지는 사람은 아무도 없다. 우선, 퇴사한 직원이 우수한 신입사원이었다는 객관적 증거를 수집하려는 사람이 없다. 결국 자기 목을 죌 올가미가 되기 때문이다. 둘째로, 이 사원의 퇴사에 의하여 줄어들 미래의 수익은 어디까지나 가정된 손해에 불과하므로 정확한 측정이 불가능하다.

  그럼에도 불구하고, 남아있는 사람들은 이런 저런 이야기 - 누구는 나가서 무엇을 한다더라, 누구는 어디로 유학을 간다더라, 누구는 어디로 가서 몇배를 번다더라, 나도 어렸을 때 화학은 참 잘했는데, 약대나 갈걸 등등 - 를 하며 침체를 겪게 되고, 무엇보다 인사권자에 대한 불신은 그대로 남는다. 내가 아무리 우수해도 연차대로 간다는 회사의 방침은 그냥 연차나 쌓자 - 다시 말해, 시간이나 때우자 - 라는 무기력을 낳게 된다. 어떠한 켐페인과 표어도 잘못된 평가에 의한 무기력을 이기지는 못한다. 결국, 아무도 책임지지 않지만, 회사에는 고스란히 피해로 남는다. 평가는 그래서 중요하다. 정확한 평가 - 회사에 이익을 주는 사람에게 좋은 평가를 주는 것 - 를 하는 관리자도 그래서 중요하다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009.05.15 08:15 신고
    댓글 주소 수정/삭제 댓글
    이건 한국이라면 좀 힘든 부분이 아닐까 합니다.
    연차 = 나이가 되고, 나이어린 상사들 밑에서 일하는걸 좋아하는 사람은 없으니까요.
    방법이라면 애초부터 조직문화 자체를 철저하게 객관적 데이터 기반으로만 평가하도록 만드는 것인데..
    사실 이또한 쉬운일은 아니죠. 참 이래저래 딜래마인듯 -_-ㅋ
    • 2009.05.15 19:40 신고
      댓글 주소 수정/삭제
      그러게요. 그럼 성과주의라는 말이나 하지 말던가 말이죠. 결과적으로 좋은 인재들은 알아서 먼저 나가버리니, 그것 또한 문제죠. 다들 밋딧릿이나 찾으니..

  새로운 프로젝트가 시작되면서 협력업체의 도움을 받기로 했다. 인력이 부족하다는 판단에서 상부에서 결정한 것이지만, 맨먼스 미신의 신봉자로써, 이번에도 결과는 별로 좋지 않을 것으로 생각된다. 내가 직접 하는 것보다 더 일이 빨리 될 것 같지도 않고, 오히려 커뮤니케이션에 문제만 있을 것 같은데... 위에서 시키는 일이라 어쩔 수는 없다. 

  사실, 협력업체분이 제대로 준비되지 않은 상태에서 일을 시작하는 것과, 평소에 하던 일을 하던 사람이 투입되서 일을 하는 것은 속도와 효율에 차이가 클 수 밖에 없다. 작업결과에 대한 머지는 결국 내일이 될 것이고... 나중에 정말 급한 문제가 생기면 또 내가 수정하게 될 것이고... 인력을 이런식으로 투입한다고 더 효율이 올라가지 않는 다는건 이미 수없이 많은 프로젝트에서 증명된 명제 아닌가. 이러니 IT가 아니고 제조업이라고 자꾸 투덜대는 일이 생긱는거다.

  위에서 야근 시키면 열라 짜증내던 난데, 이젠 야근을 강요하고 강제하는 입장이 되버리는 거다. 참 불합리한건데, 장비 하나 제대로 갖추지 못해서 일 시키는데만 일주일 가까이 딜레이가 된거다. 시뮬레이터도 없어서, 다운 받아가면서 확인하면 작업이 얼마나 비효율 적인지 알면서도 "몇일 까지 하라고 팍팍 쫘요" 라고 위에서 날 쪼는데, 참. 이건 아닌데...  그러잖아도 "하청은 IT의 막장"이라는 말이 나오는데, 미안하게도 거기에 내가 일조하게 된 것 같아 기분이 좋지 않다.

  언젠가는, 나도 과장이되고 (잘하면) 부장이 되서 개발에서 손 떼고 인력관리에 집중하라는 압박을 받을 텐데, 벌써부터 걱정이된다. "우리팀은 애자일 방식으로 8시간 근무 철저히 준수하고, 매일 스크럼 하고 코딩은 반드시 패어로 합니다" 라고 말하고 팀을 운영한다면, 위에서는 "왜 니네팀은 다른 팀 다 남아있는데 집에 가냐?" 는 질문을 받을테고 밑에 사람들한테는 "일하기도 바빠 죽겠는데 무슨 놈의 스크럼이냐"  혹은 "둘이 나눠 짜도 다 못하는데 언제 둘이 같이 짜고 있냐" 같은 말을 들을 것 같아서 그렇다. 그럼 난 뭐라고 둘러대야 하지?

  아니면, 그냥 내 선배들이 그랬던 것 처럼 나도 짜증나는 또 한명의 과장이 되는 것이 필연인가... (바둑에서 말하는 필연 말이다. 이 행마를 진행할 수 밖에 없는 필연적 국면같은...)

  아 이런일 하기 정말 싫은데... 정말 싫은데... 그냥 내가 야근하고 말지. 이건 정말 아니다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009.05.10 13:07 신고
    댓글 주소 수정/삭제 댓글
    사실 야근을 직접 하는것 보다도 시키게 되는 입장이 더 난감하죠. 물론 좀 지나면 내성이 생깁니다만 ㅎㅎ
    뭐랄까..한국 IT는 오히려 다른곳보다 더 경직된 곳이 아닐까 싶어요.
    하드웨어는 최신기술을 만지고 있지만 소프트웨어와 시스템 자체는 예전껄 고집하죠.

  요즘 케이블에서 자주 보게되는 프로그램 중에 하나가 EBS에서 제작한 "극한직업" 이다. 대부분이 블루워커 일들이고 - 외과의사 도 있기는 했지만 - 특히 배 타는 어부들의 일이 자주 나온다. 막장보다 배 타는 것이 더 힘들다는 말이 사실인 것 같다. 이 프로그램을 보고 있으면, 세상에 힘들일이 정말 많지만, 도둑질이나 강도짓 안하고 자기 힘으로 열심히 사는 사람들이 더 많다는 생각이 든다. 힘들게 일하는 사람들 덕분에 우리의 식탁이 풍요롭고, 우리가 꼭 필요로하는 1차 산업이 유지되고 있다는 생각을 하는 사람은 많지 않을 것이다. 이 프로그램은 특히 중, 고등학생들이 볼만한 프로그램이라고 생각한다.

  오늘도 제주도 갈치잡이 어선의 이야기가 나왔다. 거의 잠을 못자며 밥먹을 시간도 없이, 비와 바람을 뚥고 조업을 하는 어부들을 보면서, 저렇게도 일을 하는구나, 저렇게도 배를 타는구나 란 생각을 한다. 내가 저 자리에 서서 일하는 모습은 어떠한 상황에서도 대입이 되지를 않는다.

  IT쪽의 일이 힘들다는 일을 많이 한다. 잔특근은 당연한 일이고, 월급은 적고, 끊임없이 공부해야만 살아남을 수 있고, 30대 후반만 되도 관리직으로 전환을 준비해야 하고 , 미래는 불안정하다는 등이 IT가 힘든 이유로 꼽힌다. 프로젝트 막판이 되면 회사에서 일주일에서 한달 정도 철야하는 일은 당연한거고, 더 작은 회사들은 아얘 1년 12달 365일 회사에 출근한다는 이야기도 한다. 내시경과 디스크 검사를 위한 MRI가 유행이라는 웃지못할 이야기도 한다. 심지어, 영국 EA에서도 우리 못지않은 험악한 근로조건 때문에, 한 프로그래머의 여자친구가 블로그에 올린 비난 글 한편이 큰 파장을 불러일으킨 일이 있다.

  가슴에 손을 얻고 생각해 볼때, 배 타는 것보다 더 힘들지는 않다. 다행히 우리 회사는 육체적 근로 조건은 조금씩 조금씩 나아지고 있고, 잔특근비는 줄어도 휴가는 좀 더 늘어나고, 관리자들도 휴가에 관해서는 조금씩 관대해지고 있다는 것을 매년 느낀다. 매년 근로조건은 조금씩 나아지고 있다. (우리 회사만 좋아지고 있는 걸지도 모르겠다. )

  그럼에도, 여전히 IT는 힘들다고 생각한다. 그 이유는, 배를 타시는 분들은 30년, 40년도 타신다. 자신이 스스로 내리기 전에는 내리라고 강요하는 사람은 없다. 극한직업 프로그램에 나오시는 분들도, 선장님들은 30년 이상의 경력자시고, 선원 분들도 그에 못지 않은 기간 배를 타신 분들이다. 그럼, IT는 어떨까? 솔직히, 입사할 때 부터 15년을 버티는 것이 목표였다. 지금 같아서는, 10년 이상 개발을 하는 것이 목표다. 관리직으로 넘어가지 않고 좋아하는 일을 계속 할 수 있다면 정말 행복할텐데, 과연 그런 내 욕심이 받아들여질지는 의문이다.

  더 어려운 것은, 발전하지 못하고 가진 것을 빼앗기기만 한다는 느낌이 다는 것이다. 의사는 수술을 할 수록 자신의 기술이 느는 것을 느낄 것이다. 요리사도, 도공도, 하다못해 이삿짐을 나르는 분들도 경력이 쌓이면 쌓일 수록 자신이 나아지고 있다고 느낄 것이다. 그러나... 지금 내 포지션에서 이런 부분이 결여되어 있다. 입사 1년차때 내가 하던 일이나 4년차때 하는 일이 별반 차이가 없는 것. 이것이 지금 내가 받고 있는 가장 큰 스트레스 인 것 같다. 마치, 덤벨을 계속해서 다는데도 불구하고 알통이 생기지 않는 것 같은, 그래서 휴일에도 컴퓨터 앞을 벗어나면 뭔가 큰일이 날 것 같고, 손에서 책을 놓으면 큰 죄를 짓는 듯한 느낌. 이게 지금 내가 받는 가장 큰 스트레스이다.

  단언컨데. IT는 극한직업이 맞다. 어부는 배에서 내리고도 내일 고기잡는 법을 잊을까 걱정하지는 않지 않는가. 나는... 내 기술이 하루아침에 무용지물이 될 수 있다는 생각을 한다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009.05.02 00:43 신고
    댓글 주소 수정/삭제 댓글
    포스팅 하신 글 처럼 국내 IT 개발자의 환경이나 대우가 나날히 낮아지는 건 사실입니다.
    근데 말씀 하시는 것 처럼 IT 의 산업이 자신에게서 자꾸 발전보다는 자신의 것에서 빼앗아 가는건
    아닐까 하는 생각을 할수도 있습니다. 저 역시 그랬엇구요.
    뭐 모든 것이 그렇진 않겠지만 다들 지식산업의 막장이라는 말을 하면서 밤새워 일하고 있죠... 이짓(?)해서 과연 뭐가 될까 라는 생각도 합니다. 하지만 IT 라는 것은 새로운 것에 끊임없이 노력하는 것에 기반을 둔 산업입니다. 시대의 트랜드에 변화가 많은 산업이긴 합니다. 언급하신 의사와 다른 것이 의사역시
    그 일을 하면서 노하우가 생긴다고 하지만 전문의나 다른 과목에 대한 선 지식을 요충하기 위해서는
    그 사람들 역시 밤새워서 별도의 자신에 대한 개발을 진행합니다. 뭐 그 의사와는 다른 성향이기겠지만
    우리 IT 산업인들은 조금 더 힘든 상황에 있긴 합니다.. 근데 아예 빛이 없는 것은 아니겟죠..?
    시대의 흐름을 잘 파악하고 자신의 일에서 더아가기 위해 준비 하는 자세를 가지고 있으면
    언제든 새로운 기회를 찾아볼 수 잇다는 것이 이 IT의 단점이자 장점이겠죠? 기술의 생명이 짧아지는 주기
    가 있지만 기존에 자신이 가진 인프라에서 새로운 것을 창출하고 만들어가고자 하는 자세라면..
    빛을 볼 수 있으니까요..
    IT programmer 직종중에 windows mobile 하위 Stack 알고리즘가능한 개발자들의 연봉이 갑자기
    너무나 올라버렸네요 그 사람들은 스마트폰에 대한 흐름을 보고 미리 대처한 결과겠죠...?
    돈을 자기고 가치를 말씀드리는게 외람된 말이지만
    그만큼 트랜드형 개발자들은 높은 우대를 받고 있습니다
    그 업무에 대한 개발자가 없어서
    요즘 중소기업이나 대기업측에서도 해당 엔지니어들을 뽑느라 고심하는 거겠죠. 제가 다니는 곳도
    마찬가지구요..
    끊임없는 새로운 것들과 지금 하고 잇는 것들의 기술적 인프라..
    그런 것들이 생각하시고 계신 IT 개발자의 미래를 다르게 변화시킬수 있다는 말을 전하고 싶네요..

    어쩌면 저도 그래서 밤에 Apple SDK 나 Windows Mobile 포팅작업을 하고 있는지도 모르겠네요

    힘내세요 ^^
    두서 없이 몇자 적고 갑니다.
    • 2009.05.02 09:28 신고
      댓글 주소 수정/삭제
      긴 답글 감사합니다.

      가장 답답한 것은 말씀하신 것 같은 기회가 안보이는 것 같습니다. 새로운 기술이 뜰 것 같은 것은 보이는데, 뭔가 새로운 것을 해볼 기회가 주어지지 않는 것이 현재 제 상황이랍니다.
  2. 2009.05.02 12:20
    댓글 주소 수정/삭제 댓글
    비밀댓글입니다
  3. 2009.05.03 22:32 신고
    댓글 주소 수정/삭제 댓글
    극한이라고 까지는 생각하지 않습니다만.. 그래도 너무 현실적으로 보여준다면 시청률이 안나올것 같은데요?ㅋㅋ
    • 2009.05.04 00:36 신고
      댓글 주소 수정/삭제
      그래도 한번 찍어는 봤으면 좋겠습니다. 프로젝트 막판 3일만 찍는다면 어부들 못지 않을지도 모르지요.
  4. 2009.05.03 23:33
    댓글 주소 수정/삭제 댓글
    비밀댓글입니다

오늘 하루 종일 기분이 몹시 우울하다. 오늘 기분의 흐름은 이러했다. 

1. 우현히  회사에서  "어느 과학자의 7년 '출연연' 체험기" 를 읽었다. 음. 지금 원문 사이트를 가보니 더 우울하다. MB 정부 이후, 아니 7년 체험기니까 그 이전 정부를 포함하는 이야기일 것이다. 결론부터 말하면 이공계 찬밥이란 말이다. 그 이전에는 이런 공무원과 얽혀서 일하는 이공계가 특히 더 짜증나는 상황을 많이 겪는다는 글을 읽은 적이 있었다. 예를 들어, 출연연에서 일할 때는 개무시하던 9급 공무원이 대학 교수가 되서 돌아오자 굽신거리기가 얼마나 심한지, 자기를 알아 보지도 못하더라 같은 이야기들 말이다. 이 글도 상황이 별반 다르지 않다. 우울함이 시작되었다.

2. 내가 미쳤지. 이 시점에 다시 찾아 읽은 글이 "공생전" 이었다. 각주와 후기까지 꼼꼼히 읽었다. 농담같이 않다. 특히나 카이스트나 포공, 서울대 출신은 우리 회사에서도 거의 찾아보기 어렵다는 점에서 이 글이 현실임을 잘 알고 있다. (혹은 이들은 따로 뽑는다는 얘기가 있었다" 어느쪽이든, 나같은 평범한 개발자는 하고 싶은 일을 하기 보다는 소모될 가능성이 상당하다는 얘기가 된다. 공생전 저자와 친구들처럼 밋딧릿을 치던지 다른 분야로 옮길 여력도 없는 사람에게는 우울함만 남는다.

3. 거기에 쐐기를 박은게, 오늘 인사를 하던, 이직하는 후배였다. 공기업 전산실로 옮긴다고 한다. 뭔가, 대단하다는 생각이 먼저 들었다. 지금 부서를 떠난다는 생각도 별로 해본적이 없는데, 후배가 어느새 준비해서 이직을 한다는 것이 참 대단하다는 생각이 들었고, 내가 작아보였다. 이것 참... 지금 내 바탕화면은 곧 이사할 아파트 평면도가 올려져있다. 어제 계약을 할 때만해도 너무너무 기분이 좋았는데, 오늘 갑자기, 이걸 과연 잘한걸까 라는 생각이 들었다. 이걸 감당한다는 것은 곧 앞으로 적어도 2년은 더 이곳에서 살면서 회사를 다닐 것이라는 얘기인데, 정말 잘한걸까, 후회하지 않을까? 결혼이고 뭐고 지금이라도 다른 방향을 모색해봐야 하는 것은 아닐까란 생각이 머리속을 복잡하게 했다. 내가 들어갈 집에 살던 분은 고졸로 입사해서 10년 가까이 회사를 다니다가 결혼을 미루고 여자 친구와 유학을 결정했다고 한다. 내가 그 집을 인수하는게 잘하는 건지 모르겠다. 정작, 유학은 내가 나가야하는 것은 아닌가... 하고 생각이 많아진다.

4. 요즘 번역하고 있는 조엘의 글은 뛰어난 개발자를 "모시기" 위해서 애쓰는 이야기가 계속해서 나온다. 좋은 개발자를 얻기 위해 투자하는 것을 아까와하지 않아야 한다는 그의 주장은 천국의 이야기를 듣는 것 같다. 아마도 몇년 더 지나면 관리자로 전향할 것은 요구받게 될텐데, 난 재미있는 개발을 계속 하고 싶다. 아키텍트나 프로그램 매니져 같은 직무를 해보고 싶은데, 이 조직에는 그런 포지션 조차 없고, 내 선임자들이 나를 독립시키거나 할 것 같지도 않다. 이게 가장 큰 우울의 이유일지도 모른다. 발전이 보이지 않는다는 것. 시키는 일만 하게 될 것이라는 것. 조직이 답답하게 느껴진다는 것. 끝모를, 아니 눈에 보이는 불안감.

5. 어느 사원은 입사 3년차를 맞는 소감을 "삼년이 지났지만, 이길은 아닌가보다" 라고 적었다.  대한민국 이공계가 우울해서인지, 우리회사가 우울해서인지, 아니면 이래저래 이사를 앞두고 내가 심난해서인지, 좋은 칼럼 번역하느라 내 눈높이가 너무 높아져 버린 것인지. 무엇이 진짜 원인인지는 모르겠지만, (아마도 복합적일 것이겠다)  난 오늘 몹시 우울하다. 아 우울해.

6. 마지막으로... 다음주 쯤 지방에 친구 결혼식이 있어 내려갈 일이 생겼는데, 하루 일찍 내려가서 방을 같이 쓸 사람을 찾았더니, 또 다른 친구가 자기 여자친구와 내려가서 내 옆방을 잡겠단다. 노총각을 말려죽일 생각인가. 사실 이게 제일 큰 이유일거다 ㅋ
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009.04.29 00:40 신고
    댓글 주소 수정/삭제 댓글
    지그프리드님 덕분에 공생전과 대덕넷의 기사를 읽게 되었습니다.
    잘 보고 갑니다. :(

  오늘 읽은 글. S/W 전공자를 대상으로 한 입사 면접 시험에서 나온 질문. "S/W 개발자에게 가장 필요한 덕목은 무엇인가?" 라는 질문에 대하여 많은 입사 지원자들은 "성실성", "끈질긴 탐구능력", "창의성" 등의 대답을 했다. 글의 저자는 "지두력"이란 도서를 예로 들면서, 프로그래머에게 가장 필요한 덕목은 "문제해결력"이라고 꼽았다. 문제를 분석하고 가장 효율적인 해결방법을 찾는 능력이 프로그래머의 최고의 덕목이라고 생각한다는 취지의 글이었다.

  처음 컴퓨터언어를 공부할 때, 같은 문제에 대한 내 대답은 입사지원자와 비슷했다. 알고리즘을 만들기 위한 순간의 번뜩임과 디버깅 과정에서 끈질기에 물고 늘어지는 성실함. 한줄 한줄 짜나가다보면 못짤 프로그램이 없다고 믿던 시기였다.

  4년차에 접어든 요즘, 프로그래머에게 가장 필요한 것이 무었기냐고 묻는다면 나는 "의사소통능력" 이라고 답할 것이다. 더이상 혼자서 뚝딱뚝딱 짜는 프로젝트는 없다. 대부분의 상용프로그램은 적어도 세명, 많게는 수천명의 공동작업으로 이루어진다. 따라서, 다른 사람에게 "의사"와 "정보"를 전달하는 능력이 가장 중요하다. 코딩을 해도, 효율적인 코딩보다는 읽기 쉬운 코드가 더 인정을 받는다. 컴퓨팅 파워가 인건비보다 싸기 때문이다. 복잡한 비트연산은 지양하고, 변수 하나 하나가 의미를 갖도록 선언하고 함수 하나하나의 역할을 작게 나누어 이름과 다른 동작이 없도록 짜는 것이 더 효율적이다.

  더 나아가, 의사소통 능력에는 문서를 읽고 이해하는 능력과 문서를 작성하는 능력도 포함된다. 동료 개발자나 서드 파티에서 작성한 레퍼런스를 읽고 혼자서도 작업이 가능한 것도 능력이고,  좋은 매뉴얼을 찾아 읽는 것도 능력이다. 스펙과 컨셉문서를 읽고 작성자의 의도를 이해하고 부족한 부분을 미리 찾아내는 능력. 자신의 작업 결과를 전파하기 쉽도록 레퍼런스로 작성하는 능력 등이 굉장히 중요하다. 열명 내외의 팀이라면 세미나나 구두 전달로도 정보의 공유와 수평전파가 가능하지만, 몇백명 단위의 팀이라면 문서작성 및 공유 없인는 불가능하다. 이 능력을 갖추지 못하면 문맹과 다름없다.

  마지막으로, 현업 프로그래머에게 의사소통 능력이란 영어능력과도 크게 다르지 않다. 특히, 외국인들과 얽히는 일이 많은 요즘, 영어로 화내고, 영어로 야단치고, 영어로 비꼬고 갈구는 능력도 필요하다. 물론 이런 말을 알아듣는 능력도 필요하겠다. "프로그래머는 코드로 말한다"는 낡은 명제다. 이제는 "프로그래머는 영어로 말한다" 가 맞다.

  영어의 중요성은 아무리 강조해도 부족하지 않다. 대학 입학 직후는 학교를 낮춰왔다는 생각에 적잖이 심난한 때였다. 하지만, 1학년 때 부터 교양 서적 두 권을 빼고는 모두 영어 원서를 준비하라는 말을 듣고 마음을 놓았었다. 물론 처음엔 많이 어려웠고, 실제로 한글 번역본을 따로 구하거나, 교과서 읽기는 포기하고 공부하는 친구들도 있었지만, 영어 원서를 본다는 것은 미국 대학생들과 같은 수준의 공부를 한다는 인상을 주었고, 그저 열심히 하기로 마음을 다잡는 계기가 되었다. 그 때 교수님께서 하셨던 말씀. "영어를 잘해야 한다. 영어로 인터넷에 올라온 자료를 보면 일주일 된 자료를 보는 것이요, 영어로 된 책을 읽으면 1년된 자료를 보는 것이요, 한글로 번역된 책을 보면 2~3년 이상된 자료를 보는 것이다. IT는 정신없이 변하는데, 3년된 자료를 봐서 뭘 하자는 것이냐" 는 것이 말씀의 취지셨다. 백번 옳은 이야기다.

  혹시나 이 글을 읽는 대학 초년생들이 있으시다면, 부디 명심하시기를. 혼자서 다니지 말고 친구를 사귀시라. 인터넷에 물어물어 어줍잖은 대답을 듣기 보다는 선배에게 물어서 배우시라. 원서가 어렵다고 포기하지 말고, 차라리 영어를 습득하시라. 이 모든 것이 의사소통 능력이고, 이것이 좋은 프로그래머가 되기위한 필수 조건입니다.

 
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009.04.29 00:09 신고
    댓글 주소 수정/삭제 댓글
    좋은 말씀 잘 들었습니다. (__)

  원문은 아주 오래된 게시판에서 읽었던 것으로 기억합니다. 하이텔 만큼 오래전인지, 학교 게시판에서였는지는 모르겠지만, 어딘가 유명한 유머 게시판에 원문이 올라왔었고요. 그래서 다시 적습니다만, 원저자는 미상이라고 밝히는 것이 맞을 듯 합니다.


‘공대생 테스트’라는 게시물도 있습니다.

‘당신은 뼛속까지 공대생인가?’에 대한 이 테스트는 몇 개의 영어단어만으로 공대생과 인문대생을 쉽게 구별해줍니다.

당신은 뼛속까지 공대생이 아닌가요??? 아니라구요???

그럼 다음 단어의 뜻은 무엇일까요?

probability
equation
evaluate
frequency
function

아래로 바로 넘기지 말고 잠시 생각을…




















probability - 확률
equation - 방정식 등식
evaluate - 계산하다
frequency - 주파수
function - 함수
라고 생각하신 분 그대는 뼛속까지 공대생!

실제로 사전을 찾아보면 주요 의미가..
probability : 실제로 있음직함, 개연성, 일어남직함.
equation : 평균화, 동일화, 동등화, 균일화, 평형.
evaluate : 평가하다, 견적하다.
frequency : 자주 일어나기, 빈발, 빈번.
function : 기능, 작용, 효용, 직무, 구실.

억울하다구요? 그럼 "정의" 가 영어로 뭘까요


definition 이라고 생각한 당신은 역시나 공대생! =_=
justice 라고 생각하신 당신은 인문대생.
(정말 우리방에서 모두 Definition을 생각했다...=_=;;;;;)

그럼 다음 단어의 뜻은 무엇일까요?
critical function..

임계 함수?

라고 생각하신분 그대는 뼛속까지 공돌이 =ㅅ=...
사회과학쪽 전공 서적에서는.........

비판적인 기능...



================================================================================

여기까지는 퍼온거고, 이하는 내 오리지널 스토리. 물론 모두 다 실화다.

1. 교회 전도사님에게 길을 알려주고 있었다. 미금역 지나셔서요 고기리 방향으로 계속 직진하시다가 사거리에서 좌회전을 하세요. 사거리 두 개를 더 지나시고 나면 세번째 사거리에서...  

  4 사분면에 있습니다.


2. 역시 교회에서.

오빠 요즘 뭐하세요?

응, 나 요즘 C++ 바이블 공부해.

어머, 오빠 성경공부 시작하셨어요?

성경공부... 우리가 보는 저 무식하게 두꺼운 책은 과연 성경이었던가...



3. 학원 강사로 아르바이트를 하던 시절에 이야기다.

김선생님, 혹시 호치키스 알 있으세요?

아뇨. 아, 알이 다 떨어졌나요?  음. 저한테 백업이 있습니다.

아 근데 이전 좀 작겠는데요. 찍을게 많은데...

음 그럼 알만 이쪽으로 옮겨서 쓸수는 없을까요? 아.. 호환이 안되는구나.

김선생님.... 컴공과라고 하셨던가요 ㅋㅋ



4. 당구장에서

흰공, 점공, 빨간공 두개가 모두 일자로 섰다. 대부분의 친구들은 이걸 "일랭" 이라고 부른다. 하지만...

공이 선형이구나... 

그러게. 리니어 시스템(Linear system)이네. 방정식 풀어봐라

이러고 논다.


5. 역시 당구장에서. 나 고등학교 때.

처음 당구를 배울 때, 날 가르쳤던 친구는 "우라"를 이렇게 설명했다.

봐, 공은 여기있고 수구는 여기서 치잖아. 그럼 이 벡터랑 이 벡터랑 만나면 공은 이 벡터로 간다는거지.

서울시 물리경시대회 장려상에 빛나던 친구였다.


6. 개강 첫 수업 때.

교수님께서 리포트 제출에 관해서 말씀하고 계셨다.

각 과제 끝날 때 마다 레포트는 주어진 형식대로 빠진 내용 없도록 작성해서 시간내로 제출하세요. FTP서버 공지할테니 워드로 작성해서 제출하세요.

저 교수님, 워드가 없는데, 한글로 작성해도 됩니까?

예, 한글도 괜찮습니다.

저 교수님, 전 둘 다 없는데, 워드패드로 작성해도 됩니까?

아 없으면 학교에서 써도 되잖아요. 그래요. 워드패드로라도 내세요.

저 교수님, 훈민정음도 됩니까?

-_-;; 알았어요. 그걸로 내세요.

저 교수님, 아리랑도 됩니까?

순간 정적... 복학생들의 킥킥거림과 현역들의 "아리랑이 뭐야?" 소리

자네, 행정병으로 갔다왔나? (공대생들, 특히 컴공과 출신은 유난히 행정, 정산병이 많다. 절반은 행정이었던 것 같다.)

예  그렇습니다.

아리랑은 안되니 그냥 학교 컴퓨터로 워드로 작성해서 내세요.


아리랑 : 군대에서(만) 쓴다는 워드프로세서 프로그램


뭐 암튼 공대생들은 저러고 놀았다. 

그때가 좋았는데 :-)







Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  1. 2009.04.24 00:35
    댓글 주소 수정/삭제 댓글
    재미있습니다 ^^.
    그리고 Code 도 컴공인과 문과생들이 다르게 쓰는 단어지요.
    특히 Coding 처럼 동사로도 쓰인다는거 문과생들은 상상도 못하던데요.^^
    Joel의 번역글들도 잘 보고있습니다. 좋은글 계속 부탁~
    • 2009.04.24 21:06 신고
      댓글 주소 수정/삭제
      아 조엘글 번역을 보고 계신 분이 계시긴 계셨군요. 어렵게 번역하면서 너무 반응이 없어서 항상 고민중이랍니다. 많이 소문내 주세요 :-)
  2. Jacob
    2009.04.26 01:10
    댓글 주소 수정/삭제 댓글
    저도 잘 봤습니다. 조엘글.. 번역 잘하시는데요
    단어 선택하시느라고 고생많이 하신 것 같아요
    매끄럽게 이해가 잘 되는데요
    프로그래머가 다들 관심있어 하는 부분이고...
    • 2009.04.26 07:58 신고
      댓글 주소 수정/삭제
      감사합니다. 실제로 우리말 문법에 거스르지 않으면서 수 많은 부사들과 수식어들을 살리려고 고민을 많이 하고 있습니다. 시간이 많이 걸리네요.
  3. 2009.04.29 00:15 신고
    댓글 주소 수정/삭제 댓글
    전자공학 2학년인 저..

    얼마 전, 당구장에서 '선형'이라고 대답하는 저를 보고 놀랬습니다..ㅠ

    공대생 기질이 50% 정도 뼛 속에 습득된 것 같네요. :P
  4. 2009.05.01 23:28 신고
    댓글 주소 수정/삭제 댓글
    ㅋㅋ 잼있네요 블로그 제목이 컴공과 1학년 이신데 5년전 저의 시각으로 본다면 1학년의 aspect는 이미 벗어나신듯 ㅋ 혹시 대학원 1학년생 아님? -_-;; ㅋ
    저의 경우엔 미팅자리에서 circuler wait이 발생한후 결국에 starvation이 발생한 친구를 보고 안타까워
    하면서 이미 전 공대생임을 깨달았죠 ㅋ

  지금 진행하는 작업은 세 개의 테이블이 서로 얽히고 섥혀서 돌아가는 어플리케이션이다. 좀더 상세하게는, 특별한 복사본을 갖고있는 두 개의 테이블과, 테이블 간의 관계를 관리하는 테이블 한개를 포함해서 여섯개의 테이블이 맞물려 있다. 특히 어려운 점은, 이 테이블들이 동시에 설계된 것이 아니고 전혀 별개의 기능들을 구현하면서 설계된 테이블인데다 이 기능을 위한 특화된 테이블 들도 아니라는 점이다.

 이런 상황에서 문제를 해결하기 위해, 복잡한 알고리즘을 고안하기 보다는, 끊임없이 테이블간의 싱크를 맞추는 방법을 선택했다. 어떤 동작을 할 때 마다, 화면의 갱신이 있을 때 마다 가장 최신의 정보를 모든 테이블이 동일하게 갖을 수 있도록 쿼리를 짰다. DB를 사용하면 편한점이, 일일이 루프를 돌려서 경신할 필요가 없이 쿼리를 DB에 던져주는 것 만으로도 모든 열들의 갱신이 이루어진다는 점이다.

  내 설계는 DB의 갱신이 일어날 때 마다 모든 테이블의 상태를 일치시켜주는 방식으로 진행이 되었다. 이 방식의 장점은 명확한 동작과 기능간의 인터랙션 설계가 없는 상태에서 안정된 구현이 가능하다는 점이다. 각각의 기능 중 한쪽에만 수정 사항이 보이는 일은 일어나지 않고, 혹시나 놓질 수 몇몇 예외상황에 대해서도 곧 회복이 되어 정상동작으로 돌아간다는 점이다. 구현도 어렵지 않았고, 무엇보다 핵심 기능을 쿼리들이 수행해 주기 때문에, 나중에 컨셉이 바뀌거나 세부 요구사항이 변경될 때도 수정이 쉽다는 장점이 있다.

  문제는 이런 방식은 임베디드 디비에서 동작하기에는 부하가 크다는 점이다. 더구나 각각의 기능들의 엔트리가 Max 1000개 까지 지원되는 상황에서 이 기능들이 Full Sync가 일어나는 상황에서는 약 30초 정도 화면이 멈춘 듯이 보이기도 한다. (모래시계를 돌려야 한다.) 이를 방지하기 위해서 쿼리 최적화에 굉장히 공을 많이 들였지만, 한계가 있었다. 특히 날짜 계산에서 여러가지 예외상황과 추가 요구사항에 대응하기 위하여 더 복잡한 쿼리를 사용하게 되었다. (이 쿼리에 관한 내용은 다음에 글을 쓸 기회가 있을 것이다.)

  결론을 이야기 하면, 결국 대부분의 코드를 최근에 추가되거나 수정된 엔트리만 다른 테이블에도 업데이트하도록 수정을 할 수 밖에 없었다. 가장 큰 이유는 Full Sync 동작에서 메모리 부족으로 리셋이 나는 것이 발견되었고, 그 오류가 서드 파티 라이브러리 내부의 문제라서 내가 손을 댈 수 있는 영역 밖이었다. 둘째는 속도 문제였는데, 이 또한 라이브러리 내부에서 가비지 콜렉션이 부족해서 발생하는 것으로 실험 결과 증명되었다. 서드 파티 라이브러리를 쓰는 것이 이런 문제를 안고 가기 때문에 항상 쉽지 않다.

  결국, 내가 구현한 기능이 아닌 다른 기능의 흐름을 철저하게 분석할 수 밖에 없었고, 그 상황에서 필요한 동작에서 최소한의 업데이트만 수정하도록 쿼리와 함수를 고쳤다. 참고로, 난 다른 기능의 구현 상황을 전혀 알지 못했고, 더군다나 이번에 처음 분석을 한 기능은 두 가지였다.

  처음에는 Full Sync 방식이 쉽게 쉽게 가면서 동작에서의 오류를 최소할 수 있는 종은 방법이라고 생각했지만, 결과적으로 기능 분석을 통해 최소한의 부하를 갖는 방식으로 갈 수 밖에 없었다. 지금길로 간다고 생각했지만, 거대한 삽질을 했던 것에 불과하다. 3월 한달이 이 엄청난 튜닝작업에 소모되었다. 특히 막판 수정으로 이틀을 날렸다. 토요일에 풀타임 근무를 할 수밖에 없었다.

  교훈 : 쉬운 길이 문제가 아니다. 결국은 최고 효율을 낼 수 있는 제대로된 설계와 구현이 필요하다.

  더 큰 교훈 : 이 프로젝트의 시작에 요구사항 분석과 설계가 결여되어 있었을 뿐 아니라, 함께 연동되는 기능들 간에 의사소통이 너무 적었다. 젠장.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  문제가 굉장히 심각하다.

  맡은 기능을 구현함에 있어서, 요구사항 문서를 명확하게 확인하지 못한게 문제의 시작이었다. 이미 납품된 레퍼런스 폰이 있어서, 문서 분석을 등한시하고 작업을 시작한 것이 일을 크게 만들었다. 문제는, 납품되었던 레퍼런스 폰이 요구사항을 자의적으로 해석해서 잘못 적용한 폰이었다는 것이다. 그걸 따라한 나도 바보가 되어 버렸다.

  요구사항 분석은 모든 구현 작업에 선행되어서 꼼꼼하게 진행되어야 함에도 불구하고, 난 가장 기본을 무시하고 진행을 했던 것이다. 프로젝트 시작 몇달 전에 문서를 읽어본 것이 다고, UI 문서는 몇번 더 읽었지만 정작 요구사항 문서가 뭔지, 어떤 의미를 갖는지, 뭐가 더 중요시되야 하는 문서인지 전혀 배경지식도 없이 일을 진행하고 있었다. 이건 시말서를 쓰라고 해도 할 말이 없고, 욕을 먹어도 할 말이 없는 상황이다.

  토요일 집에서 쉬고 있는데도 뭔가 미심쩍고 마음이 무거워서 (사실 마음이 무거웠던 이유는 퍼포먼스 문제가 해결이 덜 된 상태였기 때문이다) 사무실에 나가서 갑 쪽의 피드백과 초기 요구사항 문서를 다시 뒤져 보았다. 이런 젠장. 내 잘못이다. 빼도 박도 못할 정도로...

  지난 주에 처음 이슈가 올라왔을 때, 레퍼런스 폰 개발팀에 확인 요청 메일을 보냈었는데, 거기도 요구사항에서 그런 내용 본적 없다는 뻘 답변을 보내왔던 것도 웃기는 상황이지만, 어쨌든 재대로 요구사항 분석을 하지 못했던 내 탓이다. 내 문제다. 끙...

  입사 4년차. 한껏 잘난 척하고 우쭐대던 내 모습이 부끄럽기 그지없다. 그동안 읽은 소프트웨어 엔지니어링 관련 책들과 문서들은 도대체 무엇을 위함이었던가. 처음으로 단덕으로 맡은 업무를 이따위로 해놨으니...

  월요일에 사수님 만나서 자아비판 부터 해야겠다. 아 완전 바보가 된 느낌이다.

  오늘의 교훈 : 절대로, 구현 완료된 상황을 믿지 말라. 업체 요구사항 문서만을 신뢰하고 미심쩍은 부분은 바로 피드백하라. 문서로 시작해서 문서로 끝나야 한다. 스스로 판단하기에는 아직 어리숙하다는 점을 다시금 깨달았다.

 
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


  네이버에 이런 질문이 올라왔다.

안녕하세요 컴퓨터프로그래머가 되고싶은 중3 학생입니다

 

저는 초등학교 6학년때부터 컴퓨터프로그래머에 푹빠졌습니다

 

그리고 그생각만 가지고 보니 중3 이였습니다

 

저는 워드프로세서 1,2,3 ITQ 한글, 파워포인트 정보처리기능사 자격증을따냈습니다

 

하지만 자격증만으론 안되고 C언어 C++ JAVA 등 여러가지를 공부해야합니다

 

하지만 저는 중학교입학할때부터 컴퓨터공부를 전혀하지 않았습니다

 

자격증만 있고 확고한 자신감만있으면 된다고 생각한저였으니까요

 

지금은 공부할 마음이 생깁니다

 

어떻게하면 컴퓨터프로그래머가 될수있을지

 

또 어떻게공부해야지 나의 진로를 갈수있을지

 

도와주세요..


 뭐 도와주고 싶은 생각이야 든다만, 과연 프로그래머가 뭐하는 사람인지 잘 모르고 있는 것 같다는 생각이 먼저 들었다. 그래서 이렇게 답변을 달았다.

열심히 공부해서 좋은 대학에 가세요

컴퓨터프로그래머가 되고 싶다면, 가장 기본적인 조건은 대학교에서 컴퓨터를 전공하는 것입니다. 대부분이 회사들이 컴퓨터공학 전공이나 컴퓨터과학 전공의 학위를 요구하기 때문입니다. 좋은 프로그래머가 되고 싶으시다면, 중학생인 지금은 컴퓨터관련 자격증이나 C언어를 공부하는 것은 아무 의미가 없습니다. 그런 공부는 대학에 가서 하셔도 충분합니다.

  컴퓨터 프로그래머는 "어떤 문제를 해결하기 위한 알고리즘을 만들어서, 그 알고리즘을 컴퓨터 언어를 이용해 컴퓨터가 이해할 수 있는 프로그램을 만드는 사람"을 뜻합니다. 지금 질문자님께서 생각하시는 부분은 컴퓨터 언어를 이용해서 프로그램을 만드는 부분만 생각하고 계신 것 입니다. 하지만 실제로 좋은 프로그래머는 문제를 해결하기 위한 좋은 알고리즘을 만드는 사람입니다. 그리고 좋은 알고리즘을 만들기 위해서는 생각이 깊고 현명한 사람이 되어야 합니다. 생각이 깊고 현명한 사람이 되기 위해서는 좋은 대학에서 체계적인 교과과정에서 따라서 열심히 공부하는 것이 가장 필요한 일입니다.

 다시 말씀드립니다만, 지금 중3이라면 학교 공부 열심히 하시는 것을 권해드립니다. 수학과 영어를 열심히 하시는 것이 특히 중요합니다. 그래서 좋은 학교를 가세요. 특히 우리나라는 좋은 학교와 그렇지 않은 학교 사이에 수준차이가 많이 납니다.

  너무 현실적인 답변이었을까? 사실 지금 내가 하는 일도 프로그래머는 이런 일을 한다고 소개하는 수많은 에세이들과 비교하면 노가다에 더 가깝다는 생각도 든다. 좀더 정신노동, 창조적인 일을 하길 원하는데 실상은 그렇지 못한 면이 많다. 내 실력도 그런 일을 할 만큼 뛰어나진 않다고 느끼고 있고. 무엇보다 대학 때 배운 것들이 국제적인 기준에서 너무 수준이 낮았다. 만약 내가 아르바이트로라도 프로그래밍을 하지 았았다면 난 지금보다도 실력이 한참 모자라는 얼치기 개발자에 불과했을 것이다.

  요즘의 대침체 이전에 미국의 최고 장래성있는 직업은 S/W Engineer 였고, 석사 출신 신입의 초봉이 평균 10만 달러에 육박했었다. 대한민국의 프로그래머는 여전히 3D와 화이트칼라의 경계를 걷고 있고, 대우는 많이 부족하다. 거기에다 동종업게 이직금지라는 노예제도까지 존재하고 있다. 공생전 같은 글이 괜히 나오는 것이 아니라는 뜻이다.

 개인적으로, 프로그래밍을 정말 좋아한다. 이 일은 The Mythical Man Month에서 나오는 것과 같이, 새로운 것을 만드는 창조적인 일이고 아름다운 코드를 만든 예술적인 일이다. 목수가 책상 다리에 못을 박고서 예술적으로 박았다고 느끼는 지는 모르겠다. 하지만 프로그래머들은 코드를 몇줄 적어놓고 "아름답다" 고 말한다. 프로그래머는 사람의 언어 대신 컴퓨터의 언어로 글을 쓰는 작가들이기도 하다. 그래서 난 이 일을 사랑하는 것 같다.

 프로그래머가 되고 싶다면, 이 일을 얼마나 사랑할 수 있을지 고민을 좀 해보는 것이 필요하다. 정말 해주고 싶은 말은 이것이다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  처음 이 블로그를 시작한 것은 다른 많은 블로거들 - 특히 티스토리의 블로거 분들이 - 100 달러짜리 구글 수표를 블로그에 올려 놓은 것을 보면서이다. 그전에 네이버 블로그야 검색을 통해서 제법 많은 사람들이 다녀가곤 했지만, 100달러 짜리 수표를 돌려주진 못했다. 한달 내내 야근해야 겨우 용돈 정도 버는 상황에서 100달러짜리 수표는 야근을 안하는 것이 전혀 아쉽지 않게 해 줄만한, 말 그대로 적지 않은 돈이었다.

 근데... 이건 좀 심하지 않은가... 12만 명이 다녀가도 겨우 몇십달라.. 트래픽 폭주는 아무 의미가 없고... 구글 쪽에서는 클릭 뿐만 아니라 1,000회 노출에 대해서도 비용을 지불하겠다고 했는데, 12만명이면 1,000회 노출이 120회다. 1,000회 노출에 1달러만 지불해도 이건 적지 않은 수인데 말이다.

 음... 이건 좀 억울하다는 느낌이 드는데... 너무 큰 기대를 갖고 시작한 것이 문제였던가. 차라리 블로그에 올린 글들을 잘 정리해서 책을 펴내는 것이 빠르겠다.

 근데, 책을 낼만한 실력은 되는거야?
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  아키텍트( Architect). 소프트웨어 프로젝트를 진행할 때 가장 먼저 요구사항을 분석하고 전체 구조를 잡는 사람을 뜻한다. 프로젝트 매니져 (Project Manager)와 비슷한 의미로 쓰기도 하는 것 같다만, 하는 역할만 놓고 본다면 아키텍트(건축가)가 더 맞는 것 같다.

  우리 프로젝트를 진행하는 데도 아키텍트가 꼭 필요한데, 문제는 아무도 이 역할을 맡으려 하지 않는 다는 것이다. 애초에 아키텍트가 있어 본적이 없는 것도 문제지만, 정말 임원과 부장님들이 아키텍트의 필요성을 인지하지 못하고 있는 것인지도 의문이다.

  사업자 요구사항은 단순한 UI설계도로 넘어왔다. 그에 대한 분석을 UX팀이 대응을 했다. 개발팀에서도 참여한 사람들이 있었는지 모르겠지만, 없었던 것 같다. 이건 정말 쉽지 않은 일인데, 그저 피상적이고 최소한의 UI문서만 가지고 작업이 진행되었고, 드디어 가장 어려운 문제들이 터져 나오는 중이다. 90%의 버그는 이미 처리가 되었지만, 숨어있어 악질 문제들이 발견되고 있다. 더 심각한 것은 검증팀이 전혀 발견하지 못했고, 컨셉에는 아얘 나와있지도 않다.

  아키텍트가 있었다면 어땠을까? 프로젝트 킥 오프 단계에서 요구사항에 대한 좀 더 세세한 분석과 사업자측 요구사항 중 미진한 부분에 대한 문서화 요청이 있었을 것이다. 또한 연관 기능들에 대하여 관련 개발자들간의 미팅이 있었을 것이고, 서로 연동되는 부분들에 대한 인터페이스 설계와 타이밍에 대한 규정이 있었을 것이다. UX팀은 폰 기능을 불행하게도 정말 잘 모른다. 특히나 기능과 기능이 충돌하면서 발생될 수 있는 여러가지 상황들에 대한 이해가 절대적으로 부족하다. 결국 아키텍트 외에는 각 기능들 간의 조율을 담당할 사람이 없다. 문제는 아키텍트가 없다.

  과연... 이 프로젝트는 어떻게 진행이 될 것인가. 또, 아키텍트 없이 우리팀은 계속 프로젝트를 꾸려갈 수 있을 것인가. 지금까지 꾸려진게 용할 정도지만...
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  조엘 온 소프트웨어 (Joel on software) 에서도 여러번 다룬 이야기지만, 막상 평가를 당하는 대상이 되면 이건 전혀 다른 이야기다. 특히나 우리회사 같이 큰 회사에서 많은 수의 사원들을 대상으로 랜덤이 돌아가고 있다고 느껴진다면 이건 정말 큰 문제가 된다. 프로그래머들은 의욕을 잃고, 능력이 부족한 동료 때문에 자기에게 추가 업무가 전가되는 것에 짜증을 내기 시작한다. 불투명한 고과가 팀웍을 깬다. 그건 곳 그 고과권자가 무능함을 뜻한다.

  조엘이 자신의 글에서 실증적인 예를 들었듯이, 프로그래머를 평가하는 객관적인 방법은 없다. 어떠한 잣대를 들이대더라도 프로그래머는 빠져나갈 구멍을 만들 것이며, 어떠한 잣대도 프로그래머의 창의성을 저해할 것이다. 평가를 받는 프로그래머의 목표는 더이상 가장 뛰어난 프로그램을 만드는 것이 아니기 때문이다. 그의 목표는 당연히 고과 기준에 맞는 일을 하는 것이 될 것이다. 심지어 그것이 의도적인 버그를 숨기는 일이 될지라도 말이다.

  특히나, 우리회사 같은 곳에서는 문제가 더 심각하다. 대한민국 100대 기업 안에든다는 회사가 나 입사할 때만 해도 조엘 점수가 12점 만점에 8.5점을(매우 후하게 준 것이다) 겨우 넘기는 정도였다. 조엘은 자신의 책에서 11점 미만은 가서는 안된다고 단언을 했지만, 우리회사는 입사 경쟁률이 꽤 높았다. 지금은 많이 개선되어서 11점 정도 되었다. 하지만 아직도 가장 Critical한 문제가 남아있다. 바로 채용의 문제인데, 프로그래머를 채용하면서 프로그래밍 능력을 묻지 않는다. 하하...

  프로그래머의 고과를 객관적으로 매길 수 없다면, 처음부터 A급 프로그래머를 뽑는 수 밖에 없다. B급 프로그래머의 10배 일을 하는 A급 프로그래머들로 팀을 꾸리고 모두에게 A고과를 줘라. 그리고 그들이 마음대로 뛰어놀 수 있도록 풀어놔라. 맨먼스 미신에서 말하는 것 처럼, 300명의 프로그래머와 25명의 관리자 보다 뛰어난 25명이 그냥 일을 하는 편이 더 좋다. 내가 입사하기 전에도 제품은 출시가 되었고, 인원이 두 배가된 지금도 버그는 엄청나게 숨어있다. 결국, 인원이 늘어났지만 나아진 것은 별로 없다는 뜻이다. 아니, 문제는 더 늘어나고 있는 걸지도 모른다. 제대로된 프로그래머를 채용하지 않는다면 인원이 늘어날 수록 문제도 따라 늘어날 것이다. 제발 인사쪽에서 제조업 마인드를 버렸으면 좋겠다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  지난 금요일에 회사 노조위원장이 방송에 나와서 임금협상 결과를 발표했다.  어느정도 신문과 방송을 통해 알고 있던 내용이지만, 역시나 완전동결. 잔업비 없음. 연월차 수당 없음.

  다만, 한국말은 정말 아 다르고 어 다르다 말처럼, 같은 상황도 어떻게 말하느냐에 따라서 다를 수가 있다는 걸 느꼈다. 연봉동결은 이 어려운 상황에 사람 안줄이는 것만 해도 감사한거고, 잔업비를 없앤 것은 사원들의 복지를 위한 것이고, 연월차 수당이 없어지는 것은 여름 겨울 장기 휴가를 통해 직원 사기 진작을 위한 것이라고 한다. 과연, 정말 그렇게 생각하는 것일까?

 올 여름에 정말로 일주일 휴가를 쭉 붙여서 쓸 수 있다면 진실이 드러나겠지. 뭐 좋아. 난 일찍 집에 갈테다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  대통령이 "공기업 신입사원들 초봉을 줄여라" 로 언급하며 시작된 임금 삭감이 연일 계속되는 가운데, 우리회사도 분위기가 흉흉하기 그지없다. 가장 웃기는 것은, 야근비는 없어졌으나 예전에 하던 만큼 야근은 유지하는 것이 좋겠다는 이야기가 나온다는 것인데, 오늘 부장님의 구두 공지에도 비슷한 내용의 협박이 있었다.

 IMF 때는 20%를 내보냈었고 지금도 하반기까지 계속 경기가 좋지 못하면 그런 일이 반복될 수 있다. 국제 경기를 민감하게 살피고 "알아서" 처신하라. 는 내용이었는데, 결국 결론은 돈 안줘도 야근해라 로 귀결되는 것 같다. 이야기를 반영하듯이, 오늘도 꽤 많은 수의 사람들이 예전과 다름없이 남아있었고, 모 책임님은 앞으로는 저녁이나 먹고 들어가라고 (저녁 먹으면 30분 근무를 더 해야 했는데,이젠 프리하게 먹으라는 뜻이다.) 하시더라. 나는 오늘은 6시에 나왔고, 내일도 치과 핑계로 하루 온전히 휴가를 냈다.

 회사 분위기가 이런식으로 흉흉해지는 것은 정말 싫다. 작년에는 야근 안하면 잉여인력 취급하더니, 올해는 야근비 안준다고 집에 일찍가면 그동안 생계형 잔업한 것으로 취급하겠다고 한다. 말이나 못하면...

  처음 입사했을 때, 그리고 작년까지는 솔직히 많이 받았다. 근데, 연차가 쌓여가는데도 여전히 변함없는 것이, 특히나 올해는 잘못한 것도 없는데 국제경기를 들어 큰폭의 삭감을 가져가는 것에 불만이 많다. 그동안도 동종업계에서 많은 것이 아니었는데, 이번 인사정책 변화로 이젠 다시 많아질 가능성마져 사라져 버렸다. 아 짜증나.

 결혼에 대한 의무감만 없다면 벌써 해외 유학의 길을 찾아나섰으리라.. 부모님 봉양하고 결혼해서 손주도 보여드려야 한다는 마음이 날 오늘도 그냥 그렇게 버티게 만든다. 마음이 아프다. 생각은 많아지고.

 PS. 진급 누락된 사람들도 상당히 있다. 아들 돌잔치 하고 출장나와서 90일 있다가 들어갔는데도 누락이란다. 뭘 어떻게 하라는 건지 모르겠다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

  루머 : 잔특근비가 3월부터 없어진다는 소문. 대략 300만원 대의 수입이 줄어들 예정이다. 냐하..

 수입이 없어지는 만큼 삶의 질이 올라갈 수 있다면 충분히 감당할 수 있겠다만, 여전히 분위기적인 잔특근이 이루어질 것 같아 상당히 걱정이 된다. 아이고야...

  사실상 연봉에 계산을 넣고 있는 성과급까지 상당히 줄어들면 자칫 거의 천만원 정도 수입이 줄어들텐데... 과연 견딜수 있을지. 이 땅의 엔지니어들은 항상 이렇게 약자일 수 밖에 없는 건가... 참 꽁기꽁기한 하루다. 닥쳐봐야 진짜 느낌이 올 것 같다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절

 회사의 가족마당 이라는 게시판이 있다. 관리주체가 아마도 본사인 듯 한데, 처음 만든 취지는 모든 직원들의 자사제품에 대한 불만사항을 취합하여 대응한다는 뜻이다. 언제나 그렇듯이, 처음 시작 취지는 좋았다.

  새로산 휴대폰이 문제가 좀 있었다. 크리티컬한 문제도 좀 있었고, 재현이 잘되는 문제도 있었다. 기능 설계가 엉망인 것도 있었다. (이건 UX팀의 무심함이 문제다) 두 차례에 걸쳐서 고객의 소리 게시판에 글을 올렸다. 오늘은 CS팀의 꽤 높은 분에게서 연락이 왔었다. 반응이 너무 격렬하더라. 뭐 욕을 하고 이런건 아니지만, 제발 그 게시판만은 피해달라는 취지였다. 좋게말하면 빠르고 적극적인 반응이지만, 나쁘게 말하면 내용과 관계없이 반응이 나온다는 뜻이다. 내가 글을 올린 취지는 어디까지나 시장불량을 이전에 막는 것이 좋지 않겠냐는 것이었고, 내가 쓰기 불편한 점이 있다는 점이었다.

  내가 CDMA 개발팀이었다면 직접 개발자에게 리포트를 했을테고, 검증팀에 아는 사람이라도 있었다면 그쪽으로 리포트를 했겠지만, 그런 부분에 대해서는 접근할 수가 없으니까 이쪽 게시판을 이용했던 것인데, 반응이 너무 격렬해 더는 뭐라고 말하기가 어려울 것 같다. 아직 하고 싶은 얘기는 좀 더 남아있는데...

  회사가 너무 경직되었다고 할까. 아니면 서비스 정신이 너무나 투철하다고 할까. 꼭 필요한 이야기인데, 너무 많은 사람들에게 어려움을 줬던 것 같다. 이런식이 계속 된다면 결국 아무리 좋은 의도를 가지고 시작한 게시판도 결국 맛이 가버릴 것이다.
Posted by 지그프리드 지그프리드

댓글을 달아주세요:: 네티켓은 기본, 스팸은 사절


BLOG main image
일상, 프로그래밍, IT 그리고 직장생활, Dive, 여행 by 지그프리드

카테고리

Class List (402)
Studies (30)
Exercise & Quizz (10)
Term Project (0)
ECIM list (Help!) (10)
Issues & News (0)
Gossip about IT & Job (22)
Tools (2)
Think about the Justice (23)
Book Review (170)
조엘 온 소프트웨어(번역) (28)
Diary (87)
Vacations (9)
Clash of clans 클래시 오브.. (11)

글 보관함

달력

«   2020/08   »
            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          
Total : 321,752
Today : 9 Yesterday : 10