Monday, December 15, 2014

독서의 시간

최근에 개발 관련된 글을 많이 보면서 그 동안 읽지 않았던 책을 읽어 나가고 있다.

- 폴리글랏 프로그래밍
- 익스트림 프로그래밍
- 프로그래밍 심리학
- 유니티로 만드는 게임 개발 총론
- 3D MAX 2014 기초부터 활용까지

물론 읽고 있는 책은 프로그래밍 심리학이고, 어제 다 읽은 책은 폴리글랏 프로그래밍이라는 책이다.

주말에 와이프한테 우리 책 읽는 시간을 가져보는게 어떻겠냐고 제안했는데
자기도 남편이랑 주말에 커피숍 같은데서 책 읽고 커피 마시고 얘기하는 거 좋아한다고 해서 가자고 했다.
- 응? 여태까지 그런 적은 별로 없었던 것 같은데...?

저녁 시간.
집 근처 커피숍에 갔는데 내 신용카드로 할인 받을 수 있는 곳으로 가자고 해서 투썸플레이스로 갔다.

<투썸플레이스 사진, 출처: http://claire244.egloos.com/viewer/5095238>
폴리글랏 프로그래밍은 JAVA와 C#, Scala라는 프로그래밍을 통해 프로그래밍 언어라는게 어떻게 발전을 해 오고 문제를 해결해 나가고 있는지에 대한 얘기를 풀어놓은 책이다. Scala는 경험이 없지만 JAVA와 C#은 알고 있기에 재밌게 읽었다.

<개발 경험이 많고 언어 자체에 관심이 많을 수록 재미있게 읽을 수 있는 책.
출처: http://www.yes24.com/24/Goods/12204890?Acode=101>
책 내용이 중요한 건 아니고...
사실 책은 읽어야 하는데 집에서 읽으려고 하면 TV 보고 싶고, PC로 게임하고 싶은 유혹을 뿌리치고 책을 읽을 수 있는 환경이 되지 않아 내 스스로의 변명을 방패 삼아 나가게 된 것도 있고

더 중요한 이유 중 하나는 이제 책 읽는 습관을 조금씩 들여서 앞으로 태어날 우리의 2세에게 모범적인 모습을 보여주는게 좋을 것 같아서인 이유도 있다.

서울에 이사오기 전에는 출퇴근 시간에 책을 읽었는데, 모바일 게임에 빠지다 보니 책 읽는 걸 좀 등한시 한 것 같다. 어떻게든 1주일에 한번이라도 책을 읽고 싶다는 생각이 든다.
이제 다시 독서의 시간으로 빠져들 때인 듯.

Wednesday, December 3, 2014

C++ STL 프로그래밍 책을 읽고

http://www.yes24.com/24/Goods/13563034?Acode=101

해당 책은 위의 링크를 참조

최근에 위의 제목을 가진 책을 읽었다.
C++ 언어 자체를 코딩 안한지는 거의 3년이 되어 간다.
하지만 읽는데 큰 어려움은 없었다.
코딩이야 해보진 않았지만 개념은 알고 있었기 때문이다.

이 책을 읽는데 2시간 정도 걸렸는데 (코드 예제는 생략하고)
예전의 나와 지금의 나는 STL을 경험하는 자세가 다른 것 같다.

STL을 처음 접했을 때가 2002년 학부 시절에
STL 프로그래밍 책을 읽고 많은 부분을 이해하고 따라하려던 때가 있었다.

Linked list도 제대로 몰라 후배꺼 대충 베껴서 과제 제출 했던 적이 있었는데, STL을 하겠다고 덤볐던 것 부터가 어려웠던 것 같다.
- 솔직히 고백하지만 베끼긴 했어도 내가 이해하고 다시 만들긴 했다. 어쨌든 내가 처음부터 만든 건 아니었으니 코딩을 잘 하는 학부생은 아니었다.

지금은 STL이 어렵고 쉽고를 떠나서
그냥 알게된 기술이 된 것 같다. 언제 부터 잘 알았는지도 기억이 희미하다.
코드는 보면 이해가 되고 설명이 가능하기 때문에 굳이 타이핑 해 보지 않아도 된다고 생각한다.

이유는 실무에 자주 썼고, 내 스스로 미션을 세워서 코딩 연습을 하는데 많이 사용했었기 때문이다.

그래서 리뷰 형태로 읽었다는 생각이 들고
다 읽고 괜히 읽었다는 생각도 든다.
이미 알고 있는 걸 보는게 리뷰 그 이상 그 이하도 아니기에.

내 스스로 이걸 코딩할 수 있냐 없냐가 중요한 게 아니라
이걸 어떤 시스템을 만드는데 쓰고, 같이 일하는 사람들이 이걸 알고 있는지, 만약 모르는 사람이 있다면 이걸 어떻게 알려줘야 하는지 그런게 더 생각나는 것 같다.

결국 일이 떨어지면 같은 기술을 공유하고 같이 일하는 건 내가 같이 일하는 사람이니까 그 사람이 중요한 것 같다. 이걸 내가 아냐 모르냐가 아니라.

책 읽고 난 후기가 좀 뜬금없네.

Tuesday, December 2, 2014

개발자 면접 코딩 테스트 과연 옳은 일인가?

개발자를 채용하는 과정에 있어서 능력을 측정하는 방법은 여러가지가 있는 것 같다.
구글의 화이트보드 pseudo code 테스트라던가 일부 회사들의 코딩 테스트에 대한 이야기는 뭐 검색만 조금 해봐도 유명한 방법 중에 하나일 것이다.

그런데 난 여기서 조금 문제가 있다고 본다. 그 이유는

경력의 경우 대체로 경력이 많을 수록 더 많은 언어와 더 많은 프레임워크 더 많은 개발 도구를 경험했을 터인데 그런 사람들에게 고작 테스트 한다는게 소트 알고리즘 아나 모르나 칠판에 써가면서 혹은 종이에 펜으로 써가면서 그걸 지켜보고 있는게 과연 옳은가? 이다.

물론 언어가 중요하지 않고 문제 해결 능력만을 본다고 했을 때 좋은 테스트 방법이라고 생각하는 사람이 있을 수는 있다.
하지만 요즘 같은 시대에 소트 알고리즘을 만들어서 쓰는 사람이 과연 얼마나 되는지 묻고 싶다. 알고리즘이야 검색만 하면 다 나오고, 심지어 알고리즘 코드를 만들지 않고 인터페이스 구현 (IComapre 같은) 후 알고리즘 함수 호출 한번으로 해주는 방법도 있는데 굳이 그런걸 평가하는건 옳은 건 아닌 것 같다. (오히려 C++의 STL이라던지, C#의 Sort 하기 위한 인터페이스 구현 방법 등을 물어 보는게 나은 거 같다)

여기에 수긍이 가는 좋은 글이 있어 링크를 걸어 본다.
Putting Developers to the Test

요지는 개발자들이 개발을 하는데 화이트보드에 써서 개발하지 않고 최적화된 개발툴과 거기에 맞는 OS, Framework, 개발 언어를 적절하게 선택해서 빠른 시간에 개발할 수 있는 능력을 테스트 하는게 맞다고 하는 글이다. 마치 화이트보드 코드 테스트는 잘못된 거라고 비웃듯(?) 써 놓은 글이다.

나도 면접 때 종이에 버블 소트 알고리즘에 대해 구현해 보라고 했던 적이 있었는데, 적잖이 당황했었다. 버블 소트 알고리즘을 알고 구현하는 과정이 옳은가? 에 대한 걸 평가하는 거라면 뭐라 할 말은 없지만, 버블 소트 알고리즘을 코드로 구현 가능한가?에 대한 평가라면 잘못된 평가라고 본다.

그때는 내가 당황에서 역공격을 하지 못했는데, 만약 지금 다시 그런 식으로 면접보는 곳이 있다고 했을때는 난 확실히 역공격을 하고 싶다.
"면접관님은 혹시 알고리즘 짜실 때 화이트보드에 직접 짜시는지요? 그러면 퀵 소트 알고리즘 부터 화이트보드에 보여주시면, 제가 버블 소트 알고리즘 테스트에 응해보도록 하겠습니다. 아! 만약 못하시겠으면 PC를 주세요. 어차피 저희들 다 PC에 앉아서 개발하잖아요?" 라고 말이다.

정말 면접자에게 필요한 코딩 테스트는 알고리즘 코딩 따위가 아니라

  • 면접자가 실제 진행했던 프로젝트의 개발 환경 (OS, Development tools, Framework, Language)에 대해 물어보고 왜 그런 환경으로 개발을 하는지에 대한 이해도 측정 질문
  • 이슈 관리 시스템(redmine, trac 등등), 버전 관리 시스템(svn, git 등등), 빌드 관리 시스템(jenkins, maven 등등) 등 개발에 필요한 시스템 구축에 대한 이해가 되어 있는지(이런 시스템의 필요성 정도만, 허접한 회사가 아닌 이상 사용은 해봤을테니), 그리고 이런 시스템을 사용하면서 느꼈던 에피소드 등을 유도하는 질문 (항상 빌드를 깨뜨리는 친구가 있었는데 벌금을 물게 했다던지 하는 그 사람만의 이야기)
  • 사용했던 라이브러리가 있었다면 그걸 설치해 보라고 하고 어떤 기능을 만들기 위해 썼는지에 대해 보여주는 정도 그리고 여러웠던 점이 무엇이었는지 - 실제로 면접자가 이 라이브러리에 대한 이해도가 어느정도 인지를 측정하는 것으로 본인이 필요에 의해서 쓴 라이브러리라면 코딩이 절로 나올 수 있다.
이런 것들이 되야 하지 않을까 싶다.

그래서 PC를 주고 코딩을 시키는게 아니라 저런걸 찾고 설명해 줄 수 있는 능력?
어차피 시키는 일만 열심히 했던 개발자였고 본인 능력 안키웠으면 저런거 설치해 본 적도 없을 테고, 왜 필요한지도 모를 것이기 때문에 설명을 할 수 없을 것이다.
설마 설명을 했다 한들 본인의 에피소드 얘기를 들어보면 시키는 대로 했는지 본인이 해결하려 했는지 정도는 파악되지 않을까?

회사에서 바로 써먹어야 하는 경력자는 알고리즘을 코딩할 수 있냐 없냐로 측정하는 개발자가 아닌, 개발 환경에 대한 이해를 정확히 하고 본인이 경험했던 이야기를 끄집어 내서 이런 시스템이 왜 필요한지, 문제가 뭐였는지, 어떻게 해결했는지에 대한 진솔한 얘기를 할 수 있는 개발자여야 할 것 같다.

만약 위의 것들을 할 수 있는 개발자라면 당장 내일 출근하라고 해서 개발 환경 세팅하라고 하면 별 다른 문제 없을 할 수 있을 것이다. 게다가 어차피 회사에서 시킬 일은 그 사람이 알고 있던 개발 지식과는 무관할 수 있다. 지원하려는 회사에서 만들어야 하는 시스템의 도메인 지식은 (정말 똑같은 사업을 하는 회사가 아니라면) 새로 배워야 할 가능성이 매우 높기 때문에 어차피 그럴 꺼면 툴 깔고 개발 환경이 뭔지 아는 개발자 데려오는게 시간 낭비를 덜 하는 방법일 것이다.

Monday, October 27, 2014

면접에 대한 이야기 (8)

8. 작지만 자유로운 회사 (Final)

이제 면접 이야기는 이게 마지막이다.

7번 면접 이야기와 조금은 겹치는 부분이 있었지만
따로 더 얘기해 보자면

5월 쯤 되서 욕심을 버리고 내가 찾아가야 할 자리로 가야 겠다고 생각했다.
조금 힘이 들더라도 중간 관리자 겸 개발도 가능한 위치를 찾으려 했었다.
SI 성 급 프로젝트가 있다고 해서 연락 왔던 걸 제외하면
7, 8번 회사가 최종 회사라 생각했다.

회사는 판교에 있었다.
소기업 및 벤처 기업들이 입주해 있는 어떤 건물이었는데 5층 복도 맨 끝이었다.

면접 보러 갈 때 생각났던 건
- 7번 회사에서 연락 와서 채용하려고 하니 본인 의사가 어떤지에 대한 전화가 왔다는 것.
- 회사 건물에 빵집, 커피숍, 음식점 등등 좋은 환경이구나 한 생각.
- 회사 들어가려고 하는데 여직원 네명이 갑자기 나와서 뭐라뭐라 하고 지나갔는데, 조그만 회사에 여직원이 많구나 한 점.
- 회사 들어가서 면접 보러 왔다고 했는데, 무려 오후 2시에 LOL을 하고 있는 직원과 그걸 지켜보던 직원이 있었다는 점.
이 정도다.

면접은
내가 여태까지 봤던 어느 면접보다 가장 빠르고 가장 정확하며 가장 만족스러운 면접을 진행했던 것 같다.
여러 면접관 없이 이사님 한 분과 면접을 진행했는데
사실상 기술 면접은 통과된 것이나 다름 없었고, 임원 면접의 성격도 아니었음에도 불구하고 면접 본 자리에서 바로 채용 제의가 들어와 승락했었다.

그래서 마음에 들었던 점들을 얘기해 보자면
첫번째는, 면접 시에 나의 경력에 대해 아주 흥미로워 했다.
아주 많은 WPF 관련 프로젝트를 진행 했다는 것과 웹 관련 프로젝트도 진행했다는 걸 마음에 들어 했고,
특히 윈도우 개발과 웹 개발을 동시에 진행할 수 있는 인력이라는 점에서 어느 걸 더 잘 하느냐에 대한 확인만 했을 뿐 면접 시 나오는 뻔한 질문인 당신의 능력을 읊어 주세요가 아닌 면접을 진행했다는 점에서도 나도 마음에 들었다.

두번째는 이 회사에서 진행하고 있는 사업에 대해 설명을 해주고 어떤 일을 해야 하는지를 설명 했다는 점이다.
여태까지의 면접은 내가 어떤 위치에서 어떤 역할을 해야 하는 지는 물어봐야 알려주거나 정해진게 없었는데 면접시 내가 해야 할 일이 정확했다.
회사에 기술 개발 연구원들은 있는데 정작 UI 개발자는 신입들 뿐이라 UI 관련 개발에 대한 팀장급 역할을 하고 신입 개발자들을 가르쳐 주면서 해야 한다는 점이었다.
생각해 보면 내 역할과 위치를 알아내는게 면접 볼 때 중요한 질문 중에 하나였는데, 나는 마지막 면접때가 되어서야 이걸 알게 된 것 같다.

세번째는 이 면접에 있어서 우연하게도 들어맞은 점이었는데
WPF를 사용한 윈도우 개발은 사실 개발 능력은 있었지만 도메인 지식은 금융 쪽이라 절반의 역할만 할 수 있다고 봤는데
웹 개발 쪽은 내가 전 회사에서도 진행하다가 온 네트워크 관련 쪽이어서 그쪽 솔루션 개발을 웹으로 했었다고 하니 더 마음에 들어 했었다.

윈도우는 개발 능력은 있고 도메인 지식은 없지만, 웹은 개발 능력도 있고 도메인 지식도 어느 정도 있는 상태여서 맞춤형 인력을 면접을 봤다고 해서 마음에 들어 했던 것이었다.
사실 나도 우연 치고는 나의 능력에 대해 조금 더 어필할 수 있는 사업을 진행하는 회사였다는 건 운이 좋았다고 볼 수 있었다.

게다가 신입 직원들 가르쳐 주면서 일 진행했던 게 한두번이 아니어서 신입 직원들 가르쳐 주면서 일 진행할 수 있다고 했더니 그 점도 마음에 들어 했다.

어떤 얘기를 해도 척하면 딱 이런 수준의 얘기어서 신기하기도 했고, 나도 너무 오버해서 얘기하지 않아도 원하는 수준을 알 수 있어서 아주 즐거운 면접이었던 것 같다.

게다가 위의 얘기는 거의 20분도 안되서 끝이 났었고, 마지막으로 연봉 얘기를 꺼냈을 때도 아주 시원하게 얘기를 끝낼 수 있었다.
면접을 진행한 이사님 께서 전 직장의 연봉 수준이 어느정도였냐고 해서 솔직하게 얘기하고 희망 연봉도 얘기했는데,
그거보다 더 많은 액수를 줄 수 있다고 얘기해서 속으로는 무척이나 놀랐다.
왜냐하면 여태까지 진행한 어느 면접에서도 희망연봉보다 더 높은 연봉을 회사쪽에서 먼저 제시한 면접을 진행해 본 적이 없었기 때문이었다.

암튼 제시해준 연봉으로 생각하겠다고 했고 면접을 끝냈다.
이사님 본인은 채용할거라고 했고 연봉 부분만 사장님하고 얘기해 보면 될 것 같다고 했다.
그리고 여의도에서 사무실이 있는데 거기로 출퇴근 하는게 더 좋지 않겠냐고 해서 나야 그렇다고 했다. 여의도 출퇴근이면 출근 시간이 30분도 안걸리니까.
그러고 나와서 시계를 보니 총 면접을 진행한 시간이 30분도 안걸렸다.

그리고 이틀 후 채용 하기로 결정했다고 했고 바로 다음주 월요일 출근 가능하냐고 물어봐서 그렇다고 하고 지금 이 회사를 다니고 있는 중이다.

나의 면접 이야기는 여기까지다.
생각해 보면 면접관이나 면접자나 서로 힘들어하지 않고 얼마든지 좋은 방향으로 얘기가 가능함에도 불구하고, 여러가지 상황이나 면접에 대한 고정관념 같은 것 때문에 서로 스트레스를 받는 것 같다.

이런 글을 썼던 이유는 누군가에게 도움이 되기 위해 썼다기 보단
내 스스로의 어떤 느낌을 기록하고자 한 글이다.
나중에 한번 보면 그 때 면접이 그랬었지 하며 추억할 수 있을 정도였으면 좋겠다.

Monday, September 29, 2014

면접에 대한 이야기 (7)

7. 소규모 제조업체 겸 솔루션 회사

6번 회사를 마지막으로 이제 큰 회사 지원은 그만두게 되었다.

5월을 시작으로 작지만 개발자가 많고 자체 기술력도 있으면서
내 포지션에 들어갈 역할이 필요한 그런 회사를 찾아 봤다.

사실 job search 해보면 알겠지만
2~3달 해보면 다 거기서 거기인 회사들만 있고
새로운 회사는 가끔 올라오긴 하지만
내 포지션에 맞는 description이 아닌 경우가 허다하다.

그러다가 일산에 위치한 모 회사에서 지원했는데 면접 제의가 들어와 면접을 보게 됐다.

여기서 발생한 문제는 이후에 쓰게 될 8번 회사에 대한 이야기인데
거의 동시에 면접 제의를 받게 되었고
7번 회사의 경우 내가 월요일에 면접 시간을 요청했는데 8번 회사에서도 월요일을 요청해서 8번 회사에 화요일이 가능하다고 다시 연락을 해서 화요일로 옮기게 되었다.

그러니까 7번 8번 회사의 면접을 월요일 화요일에 보게 된 것이다.
정확히는 5월 12일, 13일이고 각각 오후 2시였다.

7번 회사는 일산이었는데 집에서 가기에는 애매한 위치였다.
우선 김포공항 근처까지 버스를 타고 거기서 다시 일산 가는 버스를 타고 가야 했다.
대충 1시간 정도 걸린 듯 하다.

위치는 아파트형 사무실 같은 곳에 위치해 있었는데
홈페이지에 적힌 위치와 실제 사무실 위치가 다른 곳에 있어서 좀 당황했다.

암튼 제 시간에 도착하여 회의실로 자리를 안내 받고
면접을 진행했는데,
이번 면접 역시 기술+임원 면접까지 한번에 하는 one stop 면접이었다.
인사팀으로 보이는 분까지 같은 자리에 있었고
총 면접관은 6명이었다.

솔직히 이렇게 많은 사람과 면접을 진행한 건 처음이었지만
내게 질문 한번 안한 사람이 두명이나 있었으니
면접 시간에 참석한 모든 인원이 면접관은 아닌 셈이었다.

역시나 내가 싫어하는 자기소개 시간 부터 시작했는데
기계적으로 잘 얘기해줬고
질문에 대한 답 보다는 나의 기술력과 자랑 위주로 얘기를 많이 했던 것 같다.

워낙에 윈도우 프로그래머 경력직의 포지션이 적다 보니 그런 걸 수도 있는데
이 회사에서는 날 뽑고 싶어하는 눈치였고
나 역시 조건만 괜찮다면 들어갈 생각은 하고 있었다.

개발 인력은 여직원을 포함해서 몇 명 안된다는 얘기를 듣긴 했지만
6번 회사 면접 이후 마음을 돌린 상태라 면접은 훈훈한 분위기에서 잘 마무리 되었다.

음...
결론적으로는 이 회사에 입사하지 않았는데
마지막 8번 회사로 입사를 결정하게 되어서 그렇다.
그것도 8번 회사 면접보러 가는 길에 연락이 와서 채용하고 싶다고 했는데
솔직히 오늘 면접보러 가는 곳이 있다
거기 면접까지 보고 생각해 보겠다고 해서 입사를 보류했다가 내린 결정이었다.

여기까지가 끝이긴 하지만
7번 회사에 대한 얘기를 조금 더 해보자면

8번 회사에 입사 결정이 내려지고 첫 출근을 하던 날
7번 회사의 대표님에게 연락이 왔다.

사실 내가 너와 같은 고등학교 선배다,
면접 때 얘기하면 학연으로 의심할까봐 얘긴 하지 않았다
로 시작한 전화는
자기 회사에 입사를 다시 한번 생각해 보는 게 어떻겠냐였다.

아무래도 내 위치의 개발자를 구하기가 쉽지가 않은데
우리도 상당히 아쉬워서 그러니까 다시 생각해 보라는 얘기였는데
지금 당장 대답 안해도 되니까 결정 되면 연락 다시 달라고 하곤 통화를 끝냈다.

뭐 길게 끌 것도 없이 몇 시간 후에 연락 해서
안되겠다고는 했는데...
그 회사도 어지간히 사람 뽑기 힘들었던 모양이었던 것 같다.

놀랍게도 4달이나 지난 지금 그 회사는 아직도 내 포지션 급의 개발자를 채용하는 채용 공고를 끝없이 올리고 있다.
우리나라에 정말 윈도우 프로그램 개발하는 사람이 정녕 없는 것인가?

Thursday, August 14, 2014

면접에 대한 이야기 (6)

6. 국내 대기업 모바일 서비스 회사

이제 눈 높이는 높아질 대로 높아져서 여기까지 달려오게 됐다.
여기까지가 눈 높이 구직 활동의 마지막이라 보면 된다.

시작은 이렇다.
마지막 면접 전, 전전 회사의 아는 형이 문득 카톡으로 전체 메시지를 보내왔다.
같이 일했던 개발자 몇 명을 추가해서 MS에서 구직 추천을 해줬는데 여기 지원해 볼 사람은 지원해 보라고 한 것이었다.

요구 조건은 Window Application 개발 경력 10년
거기에 Windows Phone 8, Silverlight, WPF, ASP.NET 등등
Window 플랫폼 개발만 쭉 판 개발자를 찾는 무시무시한 구직이었다.

그런데
이 엄청난 조건에 맞는 사람이 그 형과 나 둘 뿐이었고
난 형도 지원하는 거냐 물어봤지만 고민 중이라고만 했다. (결국 지원은 하지 않았다.)

그래서 내가 지원해 보겠다고 해서 지원을 하게 됐다.

이곳 역시 판교에 위치에 있는 회사였고
MS의 한 담당 부장님을 통해 지원해 놓고 기다렸다.

기다리고...
기다리고......
또 기다리고......

그러던 어느 날 연락이 왔다.
2년 전에 우리 회사에 한번 지원한 경력 있지 않냐고.
오 내가 2년 전에 지원했던 것 까지 DB에 저장해 뒀구나 하고 놀랐지만
채용 부서가 달랐기에 인사팀에서만 알 뿐 그냥 그렇다라고만 얘기했다.

그리고 또 기다렸다.
결국 3주 정도 기다린 끝에 면접 제의 연락이 왔고
면접 날 판교로 향했다.

면접의 결과는
나의 무지함의 끝을 볼 수 있었던 매우 부끄러운 면접이었고
더 이상의 변명이 필요 없을 정도로
난 이 회사가 원하는 인재가 아닌 걸 스스로 알게 된 면접을 보게 됐다.

면접은 처음에는 무난하게 진행됐다.
뭘 했는지, 본인의 장점이 뭔지에 대해 가다가
어느 순간 부터 본격적인 개발 관련된 질문과 문제를 주기 시작했다.

MVVM에 관련된 코드를 print 해 와서 보여주고 MVVM 맞냐고 물어본 건 시작에 불과했고
timer 관련된 문제 중에 틀린 곳 찾기
-> 이건 면접 끝나고 엘리베이터 타고 내려갈 때 생각났다. 제길.
난 정확히 오답을 얘기했고 듣고 싶었던 대답은 UI Thread 관련된 문제였다.

또 소트 알고리즘 직접 손코딩 하기 등등
내가 제대로 알고 있는지 조차 의심스러 정도로 힘들었다.

물론 모르는 건 아니다.
그런 문제들은 학부때 혹은 실무 시작한지 얼마 안될 때
흥미롭게 한 부분이고
지금이야 그냥 어떤 방법의 하나로 가져다 쓰는 수준인 건데
그걸 아냐 모르냐에 대한게 아니라 직접 코딩할 수 있냐 없냐 수준으로 가니까 당황한 것이다. 그것도 종이에 펜으로 써 가면서.

마치 2차 방정식이나 미분에 대해 아냐고 물어봤을 때
안다고 대답할 수 있지만
그 문제를 내고 풀어보라 했을 때 과연 제대로 풀 수 있는 지에 대한 얘기와 마찬가지다.
학교 다닐 때 수학을 안 배운 사람은 없다.
하지만 제대로 아는지 모르는지를 수학을 배운 지 10년이 넘는 사람에게 해보라고 하는 건 정말 그 의도로 물어본 것인지는 잘 모르겠다.

지금 와서 생각해 보건데
이런 면접 방식은 좋을 수 있으나
정말 사람을 뽑으려 한 건지, 그냥 떠보려고 하는 건지 알 수 없을 수도 있다.
아니면 정말 답을 알고 있는 지를 보고 싶은 게 아니라
압박 면접일 수도 있고 (당황스러운 문제를 내고 어떻게 해결하는지)
정말 과정이 올바른가를 보고 싶은 것일 수도 있다.

정말 그런 거라면 면접을 제대로 한 것이고
개발을 제대로 할 줄 아는 개발자를 걸러내는 데 좋은 방법인 것 같다.
그리고 난 그 기대에 부응하지 못한 개발자였던건 사실이다.

그래서
그날 면접의 충격 이후
난 조금 더 내 스스로 생각하고 할 수 있는 능력을 키우기 위해
사소한 코드들이라도 한번이라도 생각하고 가져오던가 만들던가 한다.
그리고 같이 일하는 신입에게도 그런 자세가 중요하다고 늘 가르친다.

말이 많았지만
어쨌든 난 제대로 문제를 풀어낼 수 없었고
거의 자괴감 같은 게 들 정도로 며칠 동안 힘이 없는 상태로 지냈다.

만약 내가 제대로 대답해서 이 회사를 들어갔다면 좋았을 수도 있다.
연봉도 높았을테고, 환경도 좋았을 테고...

그런데 지금 다니는 회사 분위기와 개발 환경 나의 위치 등을 생각해 봤을 때
과연 지금 보다 더 좋았을까?에 대한 부분은 잘 모르겠다.
돈은 많이 벌 수 있을지는 몰라도 내가 하고 싶은 걸 할 수 있었을까?에 대한 질문에는 아니오로 대답할 확률이 더 클 것 같다.

그리고 그 때 이걸 깨달았던 것 같다.
내가 원하는 게 안정적인 회사 높은 연봉 정말 이것만 생각했지
나의 실력과 앞으로 살아가게 될 나의 위치 및 경험 대해서는 생각해보지 않았다는 것.
그냥 내 경력이 이 정도니까 할 수 있는 거야.
이렇게만 생각했다.

그래서 다시 작전을 바꿨다.
내가 확실한 위치를 잡고 내 능력을 보여주고 내가 하고 싶은 대로의 방향으로 회사를 움직일 수 있는 그런 곳으로 가야 겠다고.

그렇게 생각을 바꾸고 날짜를 보니 5월이 되었다.
지난 한 달 간 지내온 시간이 헛될 수도 있겠지만
나에게 다시 내 자신을 돌이켜 볼 좋은 경험을 해 준
판교의 K사 직원에게 고맙다는 말을 해 주고 싶다.

Tuesday, August 12, 2014

넥서스5 유리 깨져서 수리함 (Nexus 5 crashed)

삼일 전 주말에 일어난 일이었다.

화장실에서 볼일을 보고 화장지 걸이대 위에 살포시 휴대폰을 얹어 두고 열심히 샤워를 했는데
휴대폰을 있는 줄도 모르고 수건을 꺼내다가 휴대폰이 바닥에 툭 하고 떨어지는 사건이 발생했다.
뭐 그 전에도 휴대폰을 화장실 바닥에 많이 떨어뜨려서 대수롭지 않게 생각했는데
이번엔 모서리 쪽으로 제대로 떨어졌는지 휴대폰 화면 절반이 유리가 갈라진 모양으로 있었다.

으아아아아앙ㅇㅇ아ㅏ아아!!!!!!!

<줏어온 이미지, 뭐 이 정도 수준의 Crash는 아니었다.
출처: http://forums.androidcentral.com/google-nexus-4/228888-have-you-cracked-your-nexus-4-yet.html>

다행히 터치는 됐지만 갈라진 유리 위에 손가락으로 터치하고 슬라이드 까지 하려니 손가락이 베일 것 같았다.
어쨌든 이 시점에 두 가지 판단을 했다.

1. 유리가 깨진 채로 몇 달 더 쓰고 새로운 넥서스 모델이 나오면 중고로 싸게 팔고 갈아탄다.
2. 지금 당장 쓰기 불편하니 유리 교체 비용이 아깝더라도 수리해서 쓰자.

30초 고민하고 2번 작전으로 하기로 했다.

작년
넥서스4를 쓰던 시절에도 술마시다가 떨어뜨려서 유리가 깨졌고 아예 터치 자체가 되지 않았던 적이 있었다.
그때 기억으로는 11만원 정도 주고 수리했던 기억이 있다.
학동역 근처와 송파쪽에 수리 센터에 가서 고생하다
강남역에 가서 제대로 그리고 빠른 시간에 수리한 기억이 있어서
지체 없이 그 지점으로 월요일 아침 첫 시간인 9:30에 예약을 했다.

뭐 모든 건 예상대로 진행됐고,
순조롭게 유리 교체를 해서 피 같은 돈 116500원이 날아갔다.
인터넷 예약해서 1000원 할인해 줬다고는 하나 아깝긴 아까웠다.

그런데 문제는 또 있었다.

휴대폰 전면 유리만 교체했을 뿐인데, 잘 되던 무선 충전이 안되는 것이었다.
속으로는 무선 충전 부품을 몰래 빼돌린 거 아닌가 하는 나쁜 생각도 했고
다시 오늘 오전 9:30에 같은 시간에 똑같이 예약 하고 갔는데...

조립하는 과정에서 케이스를 꽉 끼지 않아서 생기는 문제라며
케이스를 꽉꽉 눌러주니 무선 충전이 잘 되는 게 아닌가?

무선 충전 부품을 빼돌린 게 아닐까 생각했던 내 자신을 반성하며
내 넥서스5 유리 교체 얘기는 끝.

3줄 요약
1. 넥서스5 유리 깨지면 수리비용은 116500원.
2. 강남역 서비스센터는 빛의 속도로 빨리 처리해준다.
3. 혹시 서비스 받고 무선 충전이 잘 되지 않으면 케이스를 꽉 눌러줘본다.

Wednesday, July 30, 2014

면접에 대한 이야기 (5)

5. 보안 관련 외국계 대기업 회사

이제 조금 급할 때도 된 것 같긴 하지만
어쨌든 안정적이고 큰 회사로 가고 싶은 욕망 만큼은 아직 꺾이지 않은 시기였다.

광탈 연락을 받자마자 다시 job search에 들어갔는데 괜찮은 job을 발견했다.

우선 job description이 맞긴 맞았는데, 회사가 좀 먼데 있다는 게 단점이었다.
인천 송도.

거기에 뭔가 회사가 많이 유치되고 있다는 건 알고 있었는데
거기까지 출퇴근 하기에는 무리지 않을까 싶었지만,
예전에 인천-서울로 출퇴근 하는 거리를 체감해 봤던 터라 크게 거부감이 들지는 않았다.

일단 job description에 대한 게 상당히 맞았기 때문에 채용 공고를 올린 헤드헌터에게 연락을 했고 빠른 시간에 contact 할 수 있었다.

담당자와 얘기해봤을 때는 이 회사와 상당히 연관이 있는 것으로도 판단이 되고
거기 팀장과도 아는 사이라고 주장해서 그런가 보다 싶었다.
그리고 여기 헤드헌터 회사 이외에는 job description이 올라온 곳은 없었기 때문에 믿을 수 밖에 없었다.

특이한 점은 자기들은 사람을 보고 판단하기 때문에
직접 회사로 와서 방문하여 얘기를 나눠야 한다는 점이었다.

지금껏 여러 헤드헌터들을 겪어 봤지만 직접 만나야 한다는 조건을 건 헤드헌터는 처음이었기에 신선하기도 했고, 위치도 마포 쪽이어서 가깝기도 했기에 선뜻 응했다.

마포의 조그만 오피스텔에 헤드헌터 회사인데,
실제 담당 헤드헌터와 얘기 하는데 큰 문제는 없었다.
이력서 수정만 조금 잘 하면 될 거라고 했고 연봉도 자기들이 생각한 수준으로 얘기하면 될 거라고 해서 연봉도 정해줬다.
뭐 마지막 연봉보다야 높은 편이라 큰 불만 없이 받아들였고 순조롭게 진행되는 듯 하였으나...

그 회사 쪽에서 나 외에 대리급 개발자 한명 더 필요한데 이왕이면 같이 일해서 호흡을 맞춰 본 사람이면 좋겠다고 해서 다른 건 대충 얘기했는데 이 부분을 너무 강조해서 얘기했다. 생각나는 사람이 있긴 했지만 재직중이라 얘기하기도 껄끄럽고 어쨌든 안된다는 생각으로 찾아는 보겠다고 영혼없는 대답을 해 줬다.

마지막으로 또 하나는 외국계 회사다 보니 추천서를 받아와야 하는데, 전 직장에 아시는 분에게 부탁해 보라고 해서 뜻하지 않게 전 직장에 가야 할 상황이 왔다.
솔직히 전 직장은 가기 싫었다. 아직까지 부장님에 대한 불만의 앙금이 남아 있던 터라 전전 직장의 부장님을 찾아 갔고 오랜만에 또 만나서 이런 저런 얘기를 했다.

추천서는 귀찮았는지 포맷만 주고 알아서 하라고 던져 줘서 내가 대충 맞춰서 쓰면 될 것 같았고, 사람은 진짜 타이밍 좋게도 같이 일했던 개발자가 곧 퇴직한다 해서 그 친구를 추천해 봐야 겠다 생각했다.

집에 오는 길에 집에서 놀고 있는 그 친구에게 연락해서 내가 헤드헌터 통해 구직중인데 같은 직장에 지원해 보라는 얘기가 있으니 한번 같이 해보자 해서 그 친구도 이력서를 제출해서 같이 지원했다.

그렇게 별 문제 없이 이력서 지원을 했는데 생각보다 면접 연락이 오지 않았다. 서류 심사는 통과된 것 같은데 조금 더 기다려 보라고 한지 2주째.
드디어 면접의 날이 왔고 송도까지 머나먼 여행을 한 끝에 면접을 진행했다.

안내 데스크 옆에 넓은 대기실도 있었고 음료도 마실 수 있고 잡지, 신문 등도 있어서 지루하지 않게 기다릴 수 있었다. 드디어 내 면접 차례가 왔는데, 책상 위에 둔 면접 대상자 리스트를 곁눈질로 보게 되었다. 총 5명이었고 내가 마지막이었는데, 같이 지원했던 그 친구 이름은 보이지 않아서, 서류 심사에서 탈락했구나 생각했다.

면접은 생각보다 대충 보진 않았다. 중요한 기술적인 질문 몇 개를 했고 나름 잘 대답하긴 했으나, 면접 보고 나서 항상 드는 생각은 더 좋은 대답과 내가 알고 있는 대답이 있었음에도 불구하고 대답을 잘 못했다는 점 그게 아쉬운 부분이었던 것 같다.

C#의 메모리 해제 문제 (Weak reference)도 그랬고, UI 쪽 뿐 아니라 실제 설계하고 본인이 만들고 문제를 해결해 나갔던 그런 부분에 대한 질문에도 분명 형식적인 대답을 하지 않았는데도 면접관들은 내가 능력이 없어서 못한 것 처럼 생각하고 있었다. - 결국 본인이 해결한 건 없다는 뜻이네요. 라는 말까지 들었으니.

어쨌든 면접이 끝나고 나서 안될 것 같다 라는 걸 조금은 직감했다.
내가 분명 좋은 대답을 못한 것도 있지만, 이 회사에서 내가 필요로 하진 않는 것 같다는 느낌이 조금 더 강했던 것 같다.
면접 진행시에 면접관 한 명이 그냥 아무말 없이 나갔던 것도 그렇고, 그렇게 시계를 봐 가면서 짧게 끝낸 것도 그렇고... 느낌상 난 마지막에 헤드헌터가 억지로 끼워 넣어서 면접 진행했던 한 명이었던 것 같은 그런 느낌.

실제로 며칠 후에 결과도 그래서 크게 아쉽거나 그러진 않았다.
그 보다 더 아쉬웠던 건 도대체 어떤 개발자를 뽑아서 일을 시키려고 한 건지는 모르겠지만 이후에 최근까지 job search 했을 때도 이 회사는 사람을 뽑고 있었다. (적어도 올해 6월 까지는 그랬다.)

이렇게 해서 3월도 결국 이 회사 지원하기 위해서 썼던 시간이 되어 버렸다.
그런데 아쉽거나 그러지 않았다. 다음 회사 면접 진행을 위해 또 준비하면 되겠지 였고, 실제로 진행했으니까.

3월 말.
뜻하지 않게 전전 직장의 정말 개발 잘 하고 친했던 형이 이름만 대면 알만한 회사에서 구직한다는 걸 전해 들었는데 나를 포함하여 몇몇 개발자들에게 지원해 보라 했다.
내가 보기엔 그 형이 지원하는게 더 확실하고 좋을 것 같았는데, 그 형은 지금 회사에 눈치 보인다고 해서 거절했고, 내게 지원해 보라고 해서 또 쉴틈 없이 다음 면접을 위해 시간을 보내게 되는 스토리가 6번 얘기가 될 예정이다.

---

원래 시간 될 때 마다 면접 관련된 글을 쓰고 싶었는데
이런 저런 바쁘다는 핑계와 게으름 때문에 제대로 못하고 있는 것 같다.
4월 얘기면 벌써 3달전 얘긴데 기억이 가물가물 하여 빠른 시간에 모든 이야기를 마무리 지을까 한다.

Tuesday, July 22, 2014

데이트 통장 (혹은 커플 통장)에 대한 계속되는 나의 주장

작년에 데이트 통장 관련된 글을 쓴 후 실제로 실천해 옮겨서 좋은 결과를 얻어 냈고
여자친구와 결혼해서도 가계부를 쓰는 걸로 업그레이드가 되서
서로 지출내역과 잔액 통장관리 등을 계속해서 해 나가고 있다.

데이트 통장 1부
데이트 통장 2부

이쯤되면 적어도 나와 와이프 사이에서는 데이트 통장이 없는 버전으로 잘 해냈다고 생각한다.

그러다가 문득 네이버에서 다음과 같은 걸 발견했다.

커플통장 만드는게 좋을까? 당신의 생각은?

커플통장에 대한 설문조사를 한 건데 아무래도 찬성의 의견이 조금 더 많은 듯 싶다.

문제는 반대표를 던진 사람들의 의견인데 대부분이 헤어졌을 때의 뒷처리 곤란 문제가 대다수이다.
내가 언급했던 문제점에 대한 글을 보고 보완한다면 좋을 방향으로 갈 수 있지 않을까 싶다.

실제 작성했던 스프레드시트는 공개가 불가능하지만 예제로 만든 시트는 보여줄 수 있다. 꼭 이렇게 하라는 건 아니고 단지 예시일 뿐이니 이정도로만 관리해 줘도 누가 얼마만큼 썼고 서로 얼마만큼의 돈으로 써야 하는지 관리가 된다.

2014 커플 통장 예시

사실 실물 통장을 만드는게 서로에게 더 물리적인 연결 고리를 만들어 주지 않을까 하는 생각에 내 방법이 마음에 들지 않을 수 있다.

하지만 그건 기우에 불과하며 통장 관리의 귀찮음보다는 실제 서로 얼마를 썼고 앞으로 어떻게 돈을 써야 하는지에 대한게 관심사이다 보니 내 방법으로 하는게 더 좋다고 자부한다.

내 블로그를 방문해서 이 글을 보는 커플들이 내가 제안한 방법을 써서 효과를 봤으면 좋겠다.

Monday, July 21, 2014

WPF globalization language, using singleton class indexer property (WPF 다국어 작업, 동적으로 해보자)

지난 포스트에 이어...

쉽게 하는 방법

지난 포스트는 쉽게 하는 방법에 대해 쓴 것이다.
단!
요구사항이 프로그램 실행중에 언어를 변경해도 런타임시에 변경되지 않아야 한다는 조건에서다.
왜냐하면 CurrentUICulture는 처음 실행될 때 세팅해 줄 수 있고, 그 이후에는 그 언어에 맞는 리소스 dll 파일을 가져와 바인딩 하기 때문에 런타임시에 변경이 불가능하기 때문이다.

그리고 이러한 요구사항은 아래와 같은 이유로 종종 타협이 되서 런타임시 언어 변경 기능은 빼는 경우가 있다.

1. 규모가 큰 프로그램의 경우 리소스를 사용하는 갯수가 수백 수천개이기 때문에, 일일이 리소스 별로 변경되는 걸 Notify 해 주기가 어렵다. (즉, 바인딩 된 언어 리소스의 Notify가 쉽지 않기 때문에) 라고 실드치는 경우. 이유는 명백하다, 처음부터 다국어를 고려하지 않고 만들었기 때문이다.

2. 크롬이나 기타 윈도우 프로그램 (심지어 윈도우 OS)의 경우도, 언어 변경 후 프로그램을 재 시작하라는 메시지와 함께 재시작 하는걸 당연하게 생각하는 사용자가 있기에 우리 프로그램도 런타임 시에 언어 변경이 고객의 필수(?) 요구사항이 아닌 이상 굳이 그렇게 까지 해야 하나? 라고 반문하는 경우.

그래서 첫 포스팅의 경우 처럼 개발자도 작업하기 쉽고, 언어 변경 후 프로그램 다시 재시작 하는게 크게 어려운 일이 아니기에 쉬운 방법으로 많이들 사용한다.

그럼에도 불구하고!
런타임시에 언어 변경이 아주 불가능한건 아니기 때문에 이번에 한번 소개해 보고자 한다.
이건 c#의 indexer를 PropertyChanged 이벤트를 줄 수 있기 때문에 착안한 것이며, 이걸 Singleton 패턴으로 instance를 관리하여 작성하였다.

프로젝트 환경은 다음과 같다.
OS: Windows 8.1
Framework: .NET Framework 4.5
Development Tool: Visual Studio Ultimate 2013
Language: C#
Project: WPF Class LIbrary


* Source description

1. Single instance (Singleton)
한 언어별 리소스들을 일괄로 관리하기 위해서 Singleton 패턴을 사용하여 하나의 인스턴스로 관리한다. 나중에 일괄로 PropertyChanged할 때 용이하다.


private static volatile LanguageResources instance;
private static object syncRoot = new Object();


public static LanguageResources Instance
{
    get
    {
        if (instance == null)
        {
            lock (syncRoot)
            {
                if (instance == null)
                {
                    instance = new LanguageResources();
                }
            }
        }
        return instance;
    }
}


2. Managed dictionary collection
내부적으로 key-value로 관리할 dictionary 클래스를 사용한다. 리소스 자체가 key-value pair이기 때문에 이만한 collection이 없다. 그리고 dictionary가 변경될 때 마다 PropertyChanged를 걸어준다. "item[]"(Binding.Indexer)을 PropertyName으로 주면 indexer에 바인딩이 걸린 모든 Binding path에 notify가 간다. 5번에서도 설명될 것이지만 각 ViewModel의 PropertyChagned도 여기서 모두 걸어준다.


private Dictionary<stringstring> _resourceDictionary;
public Dictionary<stringstring> ResourceDictionary
{
    set
    {
        _resourceDictionary = value;
        if (_resourceDictionary != null && PropertyChanged != null)
        {
            // Set property name "Binding.IndexerName" for PropertyChanged event
            PropertyChanged(thisnew PropertyChangedEventArgs("Item[]"));
            // call PropertyChanged in registered viewmodels implement INotifyPropertyChanged interface
            foreach (var item in NotifyPropertyChangedDictoionary)
            {
                if (item.Key != null && item.Value != null)
                {
                    foreach (string propertyname in item.Value)
                    {
                        PropertyChanged(item.Key, new PropertyChangedEventArgs(propertyname));
                    }
                }
            }
        }
    }
    get
    {
        return _resourceDictionary;
    }
}

3. Using indexer
인덱서의 경우는 c# 기본적인 것이니 자세한 설명은 생략하고, Singleton 객체에 indexer property를 노출시킨다. 직관적으로 key값을 주면 내부 dictionary에서 검색하여 value를 리턴하는 식으로 만든다. code behind에서 동적으로 세팅해 주는게 편할 수도 있지만, xaml 코드에서 정적으로 binding 하는게 더 강력하다. 왜냐하면 이 indexer에 PropertyChanged가 걸리기 때문이다.


public string this[string key]
{
    get
    {
        string value = key == null ? "" : key;
        if (ResourceDictionary != null && ResourceDictionary.ContainsKey(key) == true)
        {
            value = ResourceDictionary[key];
        }
        else
        {
            value = string.Format(Settings.RESOURCE_NOT_FOUND_MESSAGE, key);
        }
        return value;
    }
}

4. Load resource file (DataContractJsonSerializer)
JSON 포맷으로 되어있는 텍스트 파일을 읽어와서, 최종적으로 dictionary의 key, value collection 형태로 만든다. 단, Serialize 가능하게 만드는 것이 file read, write 할때도 직관적이면서 쉽다. 예제의 경우에는 JSON 포맷으로 텍스트 파일을 만들었으며, DataContractJsonSerializer 클래스를 사용하여 serialize 했다.


private void LoadResource()
{
    string fileStream = "";
    try
    {
        string filepath = string.Format(Settings.LANGUAGE_FILE_PATH, CultureName);
        if (DesignerProperties.GetIsInDesignMode(new DependencyObject()) == false)
        {
            fileStream = File.ReadAllText(filepath);
        }
        else
        {
            fileStream = File.ReadAllText(Settings.TARGET_PROJECT_NAME + Settings.OUTPUT_PATH + filepath);
        }
        DataContractJsonSerializer dcjs = new DataContractJsonSerializer(typeof(Dictionary<stringstring>));
        byte[] fileByte = Encoding.UTF8.GetBytes(fileStream);
        MemoryStream ms = new MemoryStream(fileByte);
        if (ResourceDictionary != null)
        {
            ResourceDictionary.Clear();
            ResourceDictionary = null;
        }
        ResourceDictionary = dcjs.ReadObject(ms) as Dictionary<stringstring>;
    }
    catch
    {
        Debug.Assert(false);
    }
}

5. Support ViewModel binding
사실 언어 리소스는 xaml에 정적 바인딩 해 두고 indexer에서 PropertyChanged로 변경 가능하게 하는게 가장 정석이지만, MVVM으로 만들어 둔 ViewModel의 Property에 PropertyChanged가 될 때 각 Property의 get에서 뭔가 string format 처리라던지 분기 처리를 통한 적절한 리소스를 보여주고 싶을 때가 있을 때도 지원 가능하도록 처리를 해 두었다.


#region NotifyPropertyChangedDictoionary
private Dictionary<INotifyPropertyChangedstring[]> _NotifyPropertyChangedDictoionary = null;
private Dictionary<INotifyPropertyChangedstring[]> NotifyPropertyChangedDictoionary
{
    get
    {
        if (_NotifyPropertyChangedDictoionary == null)
        {
            _NotifyPropertyChangedDictoionary = new Dictionary<INotifyPropertyChangedstring[]>();
        }
        return _NotifyPropertyChangedDictoionary;
    }
    set
    {
        _NotifyPropertyChangedDictoionary = value;
    }
}
#endregion
 
#region SetRegisterNotifyPropertyChanged
public void SetRegisterNotifyPropertyChanged(INotifyPropertyChanged sender, params string[] propertynames)
{
    if (NotifyPropertyChangedDictoionary != null)
    {
        NotifyPropertyChangedDictoionary.Add(sender, propertynames);
    }
}

#endregion


어쨌든 이런 식으로 리소스를 관리하면 런타임시에 언어 변경이 된다.
다만 언어별 텍스트 read, write시에 JSON notation error나
중복된 key 입력 정도만 조심하면 된다.

JSON notation error는 웹 상의 json viewer 같은 걸로 체크해 주면 되고
Dictionary class를 deseriazlize 하기 때문에 언어 파일에 중복키가 들어가게 되면 예외가 발생하게 된다. 이 부분을 조심하자.

* Benefit

1. Language resources changed on run time.

손쉽게 런타임 시에 언어 리소스 변경이 가능하다. 애초에 이 목적으로 만들어졌기 때문에 당연히 장점이 된다.

2. Can view design time.

디자인 타임에 리소스를 확인해 볼 수 있는 기능은 어찌 보면 별거 아니지만
실제 사용해 보면 상당히 편하고 좋은 기능임을 알 수 있다.

3. One time called all PropertyChanged event by indexer

Singleton instance에 CultureName이 변경되면 즉시 설정된 리소스 파일을 로딩하게 되고 그 과정에서 PropertyChanged 이벤트가 걸리게 되기 때문에 indexer를 사용하는 모든 binding된 property는 변경이 (저절로 되는 것처럼) 된다. 자세한 내용은 파일 다운로드해서 보면 알 수 있다.


* How to use LocalizationResource project library

1. Set output directory

Project properties -> Build -> Output
여기에 리소스를 사용할 프로젝트의 output 경로를 적는다.



<당연한 얘기지만 리소스를 빌드하면 dll 파일이 나오고 이걸 사용할 프로젝트에 출력 경로로 세팅해 주는 것이다>
 
2. Add reference library to target project.

다국어를 사용할 프로젝트에 이 라이브러리 프로젝트를 참조시킨다.

 
<역시 당연한 얘기지만 참조를 추가해 주는 건 기본>

3. Edit language resource files.

ko-KR, en-US가 기본으로 있으며 테스트용으로 key-value 값이 몇 개 들어 있다.
사용하고 싶은 key-value 값을 두 파일에 동일하게 추가해서 리소스 파일을 만들어 간다.


<Resources.en-US.txt>
<Resources.ko-KR.txt>
4. Use resource to xaml. You can see resource values design time.

디자인 타임에 실시간으로 리소스의 키를 입력했을 때 값이 확인되는 건 더할 나위 없이 좋은 기능임을 강조하고 싶다. 실제 쓸 때도 static binding으로 세팅만 해 두면 나중에 언어가 변경되더라도 PropertyChanged가 걸려서 언어에 맞는 리소스로 변경되서 보여진다.

<디자인타임에도 리소스가 보이는 걸 볼 수 있다.>
5. To see other property binding, download sample zip file.

Static binding 뿐 아니라 MVVM의 ViewModel binidng 까지 예제가 있으니 다운로드 해서 확인해 보면 된다.

LocalizationResources sample project file

<한국어>

파일 다운로드 방법
- 링크를 눌러 새 창이 뜨면 Ctrl+S 를 누른다.
- 아니면 메뉴에 파일 > 다운로드를 클릭한다.

<English>

How to download zip file.
- Link click, new tab opened -> press key 'Ctrl+s'
- or File > Download menu click.

Friday, July 18, 2014

WPF globalization language, using resx file (WPF 다국어 작업, 쉬운 방법)

WPF로 다국어 작업을 해야 하는데 이것저것 검색해 보면 다음과 같은 것들을 접할 수 있다.

Resgen.exe
Al.exe
LocBaml.exe
msbuild.exe
uid

이것저것 검색해 봐도 쉽고 직관적으로 할 수 있는 방법은 없는 것 같고
뭔가 command line 명령으로 파일 생성하고 수정하고 해서 로딩해 오는 방법을 써야 한다.

결국 이런 방법들의 공통점은 아래와 같다.
1. resource 가 있는 파일이 있고
2. 내가 원하는 언어를 선택하여 언어에 맞게 resource를 로딩해 오면
3. 그걸 사용하는 것이다.
4. 그것도 정적으로!

이게 무엇인고 하니 시작하기 전에 System.Threading.Thread.CurrentUICulture를 세팅해서 쓰는 건 뭔 짓을 해도 공통이라는 것이다.

런타임시에 동적으로 언어 변경하는 건 다음 포스팅에서 설명하기로 하고
우선 정적으로라도 하는 방법, 그것도 쉽게 하는 방법을 써보자.

이것 만큼 쉽게 하는 방법은 없다고 본다.
(만약 있다면 제보 부탁!)

WPF이니 Window일 것이고 내 개발 환경은 다음과 같다.
OS: Windows 8.1
Framework: .NET Framework 4.5
Development Tool: Visual Studio Ultimate 2013
Language: C#
Project: WPF Application

<그냥 WPF 프로젝트 만들면 볼 수 있는 친숙한 화면>

이름을 ResourcesSample로 생성하면 기본적으로 위와 같은 화면이 나올 것이다.
여기서 부터 순서대로 해보면,

1. Add resource value in Resources.resx
이 파일을 열면 기본 리소스를 관리할 수 있는 엑셀 파일 같은게 나오는데 두 개를 추가해 본다.
String1=야옹, String2=멍멍

<Resource.resx 파일을 열면 리소스 관리가 가능하다>


2. Static binding text in MainWindow.xaml
리소스를 사용해 본다.
xmlns:res="clr-namespace:ResourcesSample.Properties"를 추가해 주고
TextBlock에 Text="{x:Static res:Resources.String1}"을
쓰면 디자인 타임에도 볼 수 있듯이 "야옹"이라는 글자가 잘 나온다.

<Design time에도 방금 추가한 리소스가 잘 바인딩이 되는 걸 볼 수 있다>

3. Change access modifier
그런데 실제 빌드해 보고 실행하려 하면 오류가 난다. 왜냐하면 String1은 internal 한정자라 public으로 바꿔줘야 하는데 아래 처럼 엑세스 한정자를 public으로 바꿔준다. String1뿐 아니라 Resource내에 모든 리소스가 public으로 변경 된다. 일단 실행은 잘 된다.

<엑세스 한정자를 public으로 변경한다. 그래야 String1의 키 값이 public으로 변경되고 접근할 수 있게 된다.>

<진짜 별거 없지만, 바인딩 된 "야옹" 텍스트가 잘 나오는게 확인 된다>


4. Add other Resource file
지금은 한국어용 리소스를 넣고 테스트 한 것이고, 영어 리소스를 넣어야 한다.
여기서 주의해야 할 것은 리소스 파일 이름을 CultureInfo 클래스의 Name대로 이름을 명명해야 한다는 것이다. 관련된 건 구글 좀 찾아보면 나오니 자세한 설명은 생략하겠다. 기존에 Resources.resx 파일과 같은 namespace 상에 있어야 하기 때문에 Resources.resx 파일을 Ctrl+C, Ctrl+V해서 추가한 뒤에 이름을 Resources.en-US.resx로 바꿔준다. 그리고 같은 String1, String2라는 이름을 가진 값을 "Yaong", "MeongMeong"으로 추가해 본다. 

<추가한 "Resources - 복사본.resx" 파일을 "Resources.en-US.resx"로 변경한다.>

5. Confirm output folder after build.
그리고 빌드를 해서 output 폴더(프로젝트 폴더의 bin/Debug/)를 보면 "en-US"라는 폴더가 생기고 그 안에 ResourcesSample.resources.dll 파일이 있는 걸 볼 수 있다.

<드디어 영어 리소스 파일이 생긴 것이다>
6. Set CultureInfo
그럼 마지막으로 App에 아래와 같은 코드를 추가한다.
이건 프로그램이 시작하기 전에 CultureInfo를 세팅하는 것인데 "en-US" 리소스를 추가했기 때문에 "en-US"로 생성한다.
그리고 CurrentUICulture에 세팅하면 모든 리소스가 우리가 추가한 언어의 리소스로 변경이 된다.
System.Threading.Thread.CurrentThread.CurrentUICulutre = new CultureInfo("en-US");

<CurrentUICulture에 "en-US"의 CultureInfo 객체를 세팅하면 끝이다>

<확인해 보면 별거 없지만, CurrentUICulture에 세팅한 대로 "Yaong" 텍스트가 나온다>

WPF 한 사람 치고 이 정도 했는데 다국어 못하겠다고 한 사람은 없을 것이다.
이후 작업은 이름-값에 해당하는 리소스들을 계속 추가해 주고 쓰는 것 뿐이다. 시간 싸움이라는 뜻이기도 하다.

그런데 다들 이런 식 -> 이런 식이라 함은 프로그램 시작시 리소스를 로딩해 와서 바인딩이 되는 식이라는 뜻이다. 런타임 시에 동적으로 되는 예제가 몇 있긴 한데 그것도 역시 리소스 파일을 가져와서 바꿔치기 하는 식이고 리소스 key-value를 메모리에 올려서 쓰겠다는 뜻이기도 하다.

다음 포스트에는 런타임시에 다국어 적용에 대해 써볼까 한다.


<한국어>
파일 다운로드 방법
- 링크를 눌러 새 창이 뜨면 ctrl+s를 누른다.
- 아니면 메뉴에 파일->다운로드를 클릭한다.

<English>
How to download to zip file.
- Link click, new tab opened -> press key 'ctrl+s'
- or File -> Download menu click.

Monday, June 30, 2014

면접에 대한 이야기 (4)

4. 대기업 그룹계열 UX팀

네번째 면접 얘기에 앞서 이와 관련된 히스토리가 있다.
이름하여 네번째 면접 Begins.

---
때는 작년 9월 경의 일이다.

부장님과의 면담 이후 홧김에 여긴 안되겠다 싶어
나와 관련된 job search를 했었다.

그 면담이 무엇인고 하니
부장님은 나에게 업무시간에 딴짓하지 말고 업무에 집중해라
자꾸 딴짓하는게 눈에 띄는데 그러면 나와 같이 일할 수 없다.
이런 것이었다.
사실 내가 딴짓을 해서 업무에 차질이 생겼고 계속되는 지적에 문제가 생겼다면 할말 없지만
딴짓을 해도 업무에 관련된 딴짓을 한거고
진짜 딴짓을 해서 지적을 받은건 한번 뿐이었는데
그게 그렇게 눈에 거슬렸는지 따로 면담이었다고는 했지만
엄청난 욕을 먹은 거나 마찬가지였던 시간이 있었다.

당시 부장님의 스타일은 내 판단이 맞으니 시키면 시키는대로 해라 스타일이여서
뭐 반론이나 변명 따위도 통하지 않는 그런 분이었다.

그런 얘기를 듣고 기분이 썩 좋지 않아서 정말 홧김에 job search를 한 것 뿐이다.

검색하다 보니 마침 대기업 그룹사 UX 팀에서 사람을 뽑는데
디자인을 할 수 있는 개발자를 뽑는 특이한 곳이었다.

분명 skill set은 나와 90% 일치하는데
업무는 UI고 팀이 UX다 보니 조금 고민하긴 했는데
정신차려 보니 이미 헤드헌터에게 이메일을 보낸 후였다는거.

헤드헌터 역시 의외로 쿨하게 접수해 주겠다고 해서
편한한 마음으로 기다렸다.

- 사실 헤드헌터 들은 안된다는 얘기는 잘 안한다
본인 판단하에 왠만하면 되게 만들려고 한다.
java하는 사람을 구하는데 C 경력 이런 것만 아니라면
그정도 skill set에 대한 판단은 헤드헌터가 알아서 하는 편.

하지만 2주 정도 기다려보니 안된다는 답변이 와서
그냥 안되나보다 했다.

이 헤드헌터의 기억나는 특징 두가지는
1. 여자 헤드헌터
2. 두달 후에도 적절한 job이 있는데 지원해 보라는 연락이 옴.
이정도다.

...
여기까지가 begins story다.

다시 지금 시점으로 돌아와...
세번째 면접도 만족스럽지 못하게 끝나다 보니
다음 job을 찾아야 겠구나 생각이 들 때 쯤!
정말 타이밍 적절하게도
작년에 연락이 왔던 헤드헌터에게 연락이 온 것이다.
그것도 면접 후 합격 여부를 기다리고 있었던 때에.

사실 이 헤드헌터가 연락을 다시 해 온것도 반가웠는데
작년에 지원했던 그 대기업 그룹사의 UX팀에서 다시 나를 찾았다는 점에서
상당히 고무되어 있었던건 사실이다.

그렇지 않고서야 몇 달이 흐른 후에 연락을 다시 하겠으며
그쪽 팀에서 적극적으로 면접의사를 밝혀와서 헤드헌터가 연락을 해 온 것이기에
계속되는 구직 실패로 인한 스트레스 따위는 생길리가 없었다.

이때가 설 명절 후에 받은 연락이었고
쉴 틈 없이 면접 준비를 해야 했다.
왜냐하면 면접시에 진행했던 프로젝트에 대한 간략 설명+스크린샷+본인역할 등을 발표하라고 해서 그걸 준비해야 했고
PPT 파일로 만들어서 USB 메모리에 담아오라는 친절한 안내까지 해준 터라
없는 돈에 Office 365 한달 계정을 끊어서 PPT 파일도 만들고 그랬다.

면접날에는 별 다른 건 없었다.
그룹사 계열이긴 하지만 보안 절차 등이야 내겐 익숙한 것이었기 때문에 특별히 신기할 것도 없었다.

준비해온 PPT 파일을 바탕으로 기술 면접이 진행됐는데
확실했던 건 이 사람들이 원하는 스펙이 명확하다는 점이었다.
UX 팀엔 전부 디자이너들 뿐인데, 이게 개발팀으로 넘어가서 서로 communication 해 가며 수정하고 또 보완하고 하는 과정에서
서로가 알지 못하는 기술적 부분이나, 떠넘기려고 하는 부분 때문에 업무 진행이 원활하지 않다는 점을 얘기하며
그 역할을 내가 해줄 수 있으면 좋겠다라는 점을 어필했다.

그래서 내가 디자인팀에는 개발자 출신(비록 UI를 하긴 하지만)이 없냐고 물었더니 없다고 했고 개발자를 면접본 것도 내가 처음이라고 했다.
약간 미심쩍은 부분 (개발 스킬을 가진 디자이너를 뽑으려고 하는 부분)에 대한 부분은 명확하게 못했지만 암튼 원하는게 뭔지 알았기에
그 부분에 대해서는 잘할 수 있을 것이라고 나 역시 강조했다.
- 실제로 내가 주로 한 개발 영역이 UI 쪽이다.

뭐 퇴사 이유야 뻔한 얘기라 이제 심경을 건드릴 수준은 아니었던 것 같고
어쨌든 서로 원하는 점이 분명했기에 1차 기술 면접은 잘 진행했던 것 같다.

기술 면접이 끝난 후에 간단한 질문에 대한 대답을 하는 온라인 테스트가 있다고 하여
30분 정도 진행했는데
상식적인 질문 중간중간에 회사와 노조 그리고 개인적 성향을 판단해 볼 수 있는 이상한 질문들이 섞여 있는 테스트를 했다.
하다 보니 회사에 반항적인지 아닌지를 걸러내는 테스트라고 생각이 될 때 즈음
난 이미 테스트의 2/3 정도를 진행한 후여서
뭐 될대로 되라지 하고 진행했다.

그리고 정확히 1주일 후 2차 임원 면접을 진행했다.
임원 면접의 수준이야 거기서 거기라고 생각했던 나는
별 긴장 안하고 들어갔다가 엄청 긴장했다.

여태까지 봤던 임원 면접을 통틀어서 가장 정확하고 핵심을 찌르면서 면접자에 대한 생각을 볼 수 있는 질문과 진실인지 거짓인지를 판별할 수 있는 수준의 난이도 있는 질문들로 날 당황시켰다.
어쩌면 이 임원들은 진짜 실무에서 실력으로 올라간 임원들이 아닐까 싶을 정도로 실무진 보다 더 기술면접 스러운 질문도 있었다.
난 나름대로 열심히 얘기를 했지만 돌이켜 보면 그 분들에 기대치에 못 미치는 그런 대답을 했던 것 같다.
이 이유로 이 회사 입사에 성공하지 못한 원인이 50% 이상은 되지 않나 판단해 본다.
너무 정신이 없어서 면접 후에 헤드헌터에게도 잘 봤다는 말을 못할 정도였다.

그리고 1차 면접 후 진행했던 테스트...
그것도 뭔가 큰 원인으로 작용한게 아닌가 싶었다.

여기에 되면 좋겠다는 희망사항은 역시 3주라는 시간이 흐른 것으로 보답이 되었고
난 이제 백수가 된지 거의 두 달이 되어가는 시점이 왔다.

Friday, June 13, 2014

면접에 대한 이야기 (3)

3. 금융 계열 대기업 회사

사실 저번 면접때 기분이 안좋아서 시간을 갖고 천천히 알아봐야 겠다는 생각을 하려고 할 때 쯤 이틀도 되지 않아 또 다른 면접 제의가 들어왔다.

년초에 마감일이 걸려 있어서 이력서를 만들어서 지원만 해 둔 상태였는데
면접을 보고 싶다고 연락이 온 것이다.
오호 이쯤 되면 면접 운은 타고난 게 아닌가 싶을 정도로 딱 맞는 타이밍이었다.

전화도 직접 오고 메일로도 안내해 주고 해서 마음의 준비를 한 후
다음주 면접일에 맞춰 갔다.

마포 어딘가에 위치한 이 회사는 놀랍게도 지하철역 출구에 나오자마자 있는 빌딩에 위치한 회사여서 출퇴근 하는데는 문제가 없을 정도로 위치선정이 탁월한 곳이었다.
1층 안내데스크에서 면접 보러 왔다고 하니 출입구 카드를 대 주고 올라가라고 했다.

그리고 안내받자마자 마음에 안든 건 회사 탕비실 같은 곳에서 기다리라고 한 점이었다.
진짜 이런 곳에서 면접자들을 대기시키다니... 아무리 대기업이라고 해도 그렇지.
생각해 보니 대기업일 수록 더 대우가 좋아야 하는거 아닌가?
사람들 복도로 왔다갔다 하고 물마시러, 커피마시러 사람들 들락날락 하고 그래서 기분이 썩 좋진 않았다.
옆 자리에 나와 같은 포지션으로 지원한 듯한 사람이 앉아 있었는데
그 사람이 먼저 말을 걸어왔다.

몇 마디 주고 받다 보니 경력이 있다 하기엔 아직 젊은 나이고
특별한 경력사항도 없어서 그런가 보다 생각했었다.
면접 시간이 됐다고 해서 안내를 받았는데
옆자리에 앉은 사람과 같이 면접을 보는 다대다 면접 형식이었다.

여태 경력직 면접 중 다대다 면접은 신입때 빼곤 없었기에
대기업이라 이렇게 하나 싶었지만
옆 사람과 경력으로 승부하기엔 스킬이나 년차로 보나 상당한 차이가 있었기에
같이 면접을 봐서 뭘 얻으려고 하는지 알 수 없었다.

아니나 다를까
너가 누군지 한번 읊어봐로 시작한 딱딱한 분위기의 면접.
뭘 했는지에 대해서 말을 하도 많이 하다 보니 기계적으로 어렵지 않게 술술 말이 나왔다.
옆사람은 면접을 많이 안봤는지 약간 어리버리 한 것도 있었고
대답도 시원치 않게 하길래 긴장 많이 했나보다 생각됐다.
- 실제로도 면접관이 긴장 풀으라고 얘기도 했었으니...

나 같은 개발직은 기술면접-임원면접이 정석인데 (혹은 기술면접에서 바로 채용하던지)
특이한 점이 기술 20%, 임원 80%를 함께 진행하는 원스톱 면접이었다.
그나마 기술 20%도 형식적인 리뷰 정도.

임원이 질문하는 것도 그냥 대기업에서 하는 그저 그런 수준의 면접
- 삼국지 얘기와 게임 얘기가 있었는데 그런 질문과 대답을 듣고 어떤 인재상을 원하는 건지 알 수는 없었다.
그 당시만 해도 이런 질문과 대답이 오가는 것이 특별히 나쁘다곤 생각 안했기에
삼국지는 조조 좋아하고 그 이유도 얘기했고, 게임 얘기도 하려 했는데 시간 관계상 짤렸다.
게임 얘기 신나게 할 생각에 기다렸었는데 그건 좀 아쉬웠다.

또 기억나는 건 핵심적인 질문이었는데
이 회사에서 하는 사업과 관련해 내가 어떤 생각과 마음가짐으로 일할 수 있는가에 대해서도 물어봤었다.
평이한 수준으로 대답을 하긴 했는데, 결국 나의 기술적인 능력에 대해서는 그다지 궁금해 하지 않는 것 같다는 느낌을 강하게 받아서 면접이 끝난 후에 같이 면접본 사람에게 이 얘기를 해줬다.

"여긴 개발자를 뽑으려고 하는 것 같지가 않다. 별로다."

라고 했지만, 그 사람은 별 대답 없었고, 얘기가 하고 싶지 않았는지 간단히 인사만 하고 자기 갈길을 갔다.

면접 진행 후 그 주 안에 연락이 올 것으로 기대했는데 별 다른 연락이 없었다.
또 내가 직접 연락해서 언제까지 기다리면 될지에 대해서 문의했는데
다음 주 중에 알려준다고 해서 기다렸지만
채용이 되지 않았다는 반갑지 않은 메일을 받고 끝을 내야 했다.

이 메일을 봤을 때, 정말 진짜 레알 이상한 점은
수신인이 같이 면접 봤던 그 사람(일 거라고 추측되는 메일 주소)과 내 메일 주소를 함게 적고 채용 거부 메일을 보냈다는 것이었다.
그 때 면접 진행한 팀이 우리 말고 다른 팀이 없었던 것을 생각해 봤을 때
힘들게 채용공고 올려 놓고 이력서 필터링 해서 사람 둘 데려와서 면접 진행한 다음에 둘 다 마음에 안들어서 짤라내고 다시 똑같은 짓을 반복하겠다는 뜻으로 해석했다.
최소한 각각 메일을 보내던가 하면 이런 생각도 안했을텐데
면접 본 사람이 둘인데 둘한테 채용 안한다는 메일을 보냈다라...

이 모든 의문의 출발점은 항상 이 질문부터로 시작된다.
대기업이라 그런가?

Wednesday, June 11, 2014

지난 2년간 느껴왔던 개발에 대한 생각

마지막 포스트를 끝으로 2년간 있었던 일들을 간략히 정리해 보겠다.

어쨌든 난 WPF Application을 개발하는 개발자이고
그 개발에 대한 경험이 많은 개발자이다 보니
이와 관련된 일을 하는게 맞다고 생각할 법도 하다.

3~4년 전 부터 느껴온 거지만
새로운 개발 환경
새로운 개발 언어
새로운 업무 - 도메인 지식을 동반한
이 세가지 중에
제일 중요한게 뭐냐고 물었을 때 난 "업무"가 나와야 하는게 맞다고 본다.
새로운 개발 환경과 언어는 배우면 되는 것이다.
(그러고 보니 업무도 배우면 되는 건데...)

배운다는게
개발 환경과 언어는 개발자가 온전히 지고 가야 하는 배움이라면
업무는 이 일과 관련된 일을 하는 사람 모두가 알아야 하는 배움이라는데에 차이가 있다.

그렇다면 개발자자 개발에 관련된 지식을 얻는게 맞는데
과연 이것 보다 업무가 더 우선순위가 있다는 것인가?

정말 그렇다.

개발은 고객이 원하는 요구사항에 맞는 제품을 만들어내는 것이지
그 제품이 어떤 기술이 필요하고 어떤 환경이 필요한 지에 대해서는
우리 개발자가 정하면 된다는 것이다.

다시 WPF 얘기로 돌아가 보면

난 처음에 WPF로 만들어진 솔루션에
고객이 요구하는 기능 개발, 또 기능 추가, 디버깅 작업, 유지보수 등등을 해 왔는데
플랫폼이 Window Application에서 Web Application으로 바뀌었다고 해서
고객이 요구하는 기능이 바뀌지는 않는다는 걸 알게 되었다.
웹 환경은 ASP.NET MVC3
웹서버는 당연하게도 IIS
또 너무나 당연하게도 DB는 SQL Sever
이 환경에서 처음부터 시작했는데, 시간은 좀 걸렸어도 아예 못하지는 않았다.

이렇게 서로 다른 환경에서 한가지 기능에 두 가지 플랫폼이 존재하는 제품을 만들어 가다 보니
내가 어떤 언어를 알고 어떤 플랫폼을 아는 지에 대해서는 고객의 입장에서는 무의미하다는 뜻이기도 하다.

3년 전 쯤에 이걸 느꼈고
1년 전에는 확실히 알았다.

이 과정을 겪고 난 이후
난 새로운 개발 언어와 새로운 개발 플랫폼을 알아 가는 과정이
힘들다거나 어렵다거나 두렵다거나 하지 않았다.
(솔직히 귀찮은건 있다)

오히려 그것은 개발자 자신이 만들어내는 하나의 핑계거리에 불과할 수도 있다.
- 전 JAVA만 해봐서요 Java script는 잘 몰라요 -- 웃긴건 JAVA와 Java script가 같은 것인지 아는 사람이 상당히 많다
- 아 전 C로 되어 있는 서버만 만들어 봐서, C#으로 된 서버는 잘 몰라요.
- asp.net으로 해본게 있긴 한데, php는 모르겠네요

이런 핑계는 다시 이런 질문으로 바뀌어야 한다.
- 단순 데이터 조회 서비스라면 어떤 웹 서비스가 좋을지 찾아보고 그걸로 해보겠다.
- 웹에서 새로고침 없이 실시간 데이터가 나오게 하려면 어떤 기술이 필요한지 찾아보고 그걸로 가자.
- 윈도우 설치형 프로그램에 데이터가 아주많은 성능 차트가 나와야 하는데 Win32로 가느냐 WPF로 가느냐를 검토하고 성능 좋은 걸로 결정하자.

물론 경험이 부족한 개발자의 경우
또 한가지 플랫폼의 한가지 언어에 집중해야 하는 일을 해왔을 경우
두려움과 어려움, 시간 부족 - 심지어 귀찮음의 이유를 들어
난색을 표하는데
사실 경험이 많은 개발자일 수록 이렇게 얘기하는 사람은 드물다.
만약 아닌 개발자가 있다면?
환경이 그렇게 만든 것일 수도 있지만, 하나의 일에 너무 안주한것이 아닌가 되돌아 보는 것도 필요할 듯 하다.
개발자의 피가 흐른다면 새롭고 흥미로운 신기술에 대한 호기심 정도는 있어야 한다고 보니까.

또 한가지 중요한건
경험삼아, 취미삼아, 시간나서 개발을 하는 것과
돈을 버는 일로 개발을 하는 것이 다르기 때문에
최근의 경우도 Node.js 서버에 대해 상당히 관심이 많았음에도 불구하고
실제 Node.js 서버가 필요한 프로젝트에 투입이 되어서야
제대로 된 경험을 할 수 있었다.

그 전에 해봤던건 그냥 잘 도나 안도나 정도 해봤던 예제 코드들 돌려본게 전부이다 보니
목표도 없고, 돈되는 일도 아니고 해서
그냥 해봤으면 좋겠다라는 간절한 생각만 들었을 뿐이다.

실제로 Node.js 서버를 구축하여 프로젝트를 해본 경험이 없음에도 불구하고
짧은 시간에 Overview를 정독 후, 원하는 기능을 구현하는 예제 소스들을 확인한 후
바로 거침없이 기능 구현에 몰두해 요구사항을 만족하는 Node.js 서버를 만들었다.
- 사실 Node.js 서버가 크게 어려운건 아니다, Simple, light, fast and java script base 이런게 모토다 보니 두려움만 없다면 누구나(?) 할 수 있다.

이제 난 개발이 두렵지 않다.
정확히 얘기하면 요구사항에 맞는 개발 플랫폼 및 언어를 배워 개발을 하는게 두렵지 않다.

Tuesday, June 3, 2014

PC방 정액 요금 계산에 대한 문제

PC 게임을 가끔 즐겨하는데
엄청난 순발력과 센스를 요구하는 LOL 같은 게임보다는
느긋하게 할 수 있는 문명류의 게임을 좋아한다.
주로 시뮬레이션, 아케이드, 보드게임류등.

블리자드엔터테인먼트에서 나온 하스스톤: 워크래프트의 영웅들이 정식 서비스 된지 몇 달 됐는데
몇 년 전에 했던 매직 더 개더링의 냄새가 살짝 나는 카드 게임이기도 하고 해서 하루에 몇 게임 정도는 꼭 하는 편이다.
음 매직 더 개더링 보다는 조금 더 스피디하고 캐쥬얼하게 바뀐 게임이라고나 할까 그런 느낌이었다.

<하스스톤 게임 스크린샷, 출처: 하스스톤 공식 사이트>

암튼 하스스톤 PC방 이벤트가 며칠 전 부터 진행되고 있는데
PC방에서 로그인한 유저에게 매일 100골드를 선물해 준다는 소식을 접해듣고
그날 바로 동네 PC방에 달려가서 6시간 정액 요금제를 결제했다. 가격은 5000원.

내가 생각한 PC방 정액요금의 시간 계산법은 다음과 같다.
- 잔여시간: 6:00
- PC방 회원 로그인
- 10분 사용
- 로그아웃
- 잔여시간: 5:50

그런데 내 동네 PC방의 경우는 계산이 이렇다.
- 잔여시간: 6:00
- PC방 회원 로그인
- 10분 사용
- 로그아웃
- 잔여시간: 5:00

응???
첫날은 로그아웃 하고 가서 몰랐고
그 다음날 로그인하고 알았다. 1시간이 사라졌다는 걸...
뭔가 이상하다 생각은 들었지만
정액 요금은 나올 때 충전한거라 처음 후불 요금제로 기본 1시간이 계산되서 그냥 빠져나갔겠거니 했다.

그런데 그 다음날!
다시 1시간이 없어졌다.
뭔가 이상한걸 느낀 난 알바생에게 어제 로그인-로그아웃 시간좀 봐달라고 했는데
알바한지 며칠 안되서 잘 모른다고만 했다.
이쯤 되니 뭔가 화가 났다. 하지만 알바가 잘 모른다고 했으니 어쩔 도리가 없었다.
그리고 그날은 피곤해서 그냥 집에 들어갔다.

그리고 어제.
또 PC방에 가서 로그인을 하니 1시간이 또 줄어 있었다.
이쯤 되니 나도 폭발해서 알바에게 따지고 들었다.
알바도 내가 어제 오늘 의혹을 제기하니 그제서야 사장님에게 물어보겠다고 전화를 했는데
뭔가 서로 통화 하더니 날 바꿔줬다.

사장 얘기를 들어보니
- 1시간 이상 사용 안하면 기본 1시간이 빠지는게 우리 PC방 정책이다. (후불 요금제도 그렇다라는 이유로)
- 기본 요금이 천원=1시간 아니냐, 그래서 1시간 이상 사용해라, 우리 PC방 손님들도 다 그렇게 알고 PC방 이용한다.
- 잘못된건 아니지만 손님도 모르셨고, 알바도 처음와서 안내를 안드린 잘못도 있으니 빠졌던 시간은 다시 넣어주겠다.

이 얘기를 듣고, 내가 여태 다녔던 PC방과 계산을 다르게 하고 있다는 걸 확실히 알게 됐다.
그리고 바로 든 생각은 이렇게 계산 안하는 다른 PC방을 가야겠다라는 생각 뿐.

이왕 이렇게 된거 1시간 하고 갈까 생각도 들었지만
그냥 속편하게 다른 PC방에 가는게 나을 것 같았다.
아무 잘못 없는 알바에게는 화내서 미안하다고 했지만
우리동네 PC방. 많이 실망했다.

정액 요금이라도 1시간 미만 사용시 1시간이 빠지는 PC방이 많은지
쓴 시간만큼만 빠지는지도 궁금해져서 이리저리 검색해 봤지만 별다른 결과가 나오진 않는 것 같다.

결론.
내 생각대로 정액 시간 계산되는 PC방으로 가야겠구나.

Monday, June 2, 2014

면접에 대한 이야기 (2)

2. 중견 헬스케어회사 면접

첫 이직 시도는 그렇게 해서 없던 일이 되었지만
아직 회사를 그만둔 건 아니었기에
"계속 다닌다고 할까?" 라는 생각이 들 법도 했지만
여기에서 일하는 건 아니라고 생각했기에 바로 다음 회사를 물색했다.

경기도 어딘가에 있는 한 중견 헬스케어회사였는데(이니셜은 I)
특이한 점은 내가 가지고 있는 개발 스킬을 이용해 뭔가 하는 것 같은데
헬스케어 회사에서 나의 개발스킬이 필요한게 뭐가 있을까? 하는 의문은 뒤로하고
우선은 지원을 해 둔 상태에서 퇴사일을 손꼽아 기다리고 있었다.

작년 12월 까지였는데 남은 연차 소진을 해야 해서
아마 12월 3주차 까지만 일하고 그만두는 걸로 했다.
그리고 마지막 날 전주에 외근 일정이 있었는데
그때 회사에서 연락이 왔다.

면접 진행에 대한 안내 메일을 보내주고, 자사 이력서 양식이 있으니 거기에 맞게 이력서를 써 달라는 그런 내용이었다.
연락이 온게 목요일 쯤이었는데 내가 내일까지 보내준다고 했던게 실수였다.
이력서 포맷을 막상 보니 적어야 할게 꽤 많았고,
진행했던 과제에 대한 스크린샷 혹은 사이트, 프로그램까지 요구하는 칸이 있어서
우선 다음주 월요일까지 작성해서 준다고 다시 메일에 회신을 보내고
주말 시간까지 쪼개서 미친듯이 이력서를 썼다.

뭐 잡코리아나 사람인에 등록된 이력서 말고 자사 양식 이력서를 요구하는 회사가 꽤 된다.
내 기억에는 이 회사 이력서 양식이 적을 게 꽤 많았고 솔직히 귀찮았다.
그래도 중견기업이니까... 라는 생각에 성의를 다해 썼다.

다음주 월요일이 되자 마자 메일을 보내고 회신을 기다렸지만
연말 휴일이 겹쳐서 내년 (2014년)에 면접 일정을 다시 잡을테니 기다리라는 대답 뿐이었다.

뭐 회사도 그만뒀겠다. 연말 분위기좀 내면서 그렇게 2013년의 마지막을 잘 보내고
그 다음주에 첫 기술 면접을 진행헀다.
집에서 거리는 좀 되는 편이었는데, 예전에 인천에서 다닐 때 만큼은 아니었던 것 같고 해서 결과가 좋으면 다닐만 하겠다라는 생각을 했다.

회사 도착 해서 면접 진행하기 전에 또 스킬셋에 대해 적는 쪽지를 줘서 그거 신나게 적고 있는데 되는 거에만 적으라고 해서 바로 그만뒀다.
빨리 좀 알려주지... 아는건 죄다 적어 내려갔는데...

면접은 내 기억엔 괜찮았었다.
쓸떼 없는 질문은 전 직장 퇴사한 이유 정도가 다였고
(사실 이거 물어보는 것도 좀 짜증나긴 하지만...)
역시나 너와 나의 최대 관심사인 연봉 문제에 대해 언급을 했다.

전 직장 연봉이 이러하니, 여기까지만 줘도 문제 없을 거라고 얘기해 줬다.
사실상 인상 없이 들어가겠다고 먼저 굽히고 들어간건데
내 연봉이 세다고 느껴졌는지 윗분들이 연봉 조정을 좀 할 것 같다는 걱정어린 눈치를 주길래 그것 까지 알았다고 했다.

그리고 그 다음주.
임원면접을 진행하겠다고 해서 전화가 왔는데 따로 메일로 전달받은 것 없이
어느 날짜에만 오라고 해서 메일 안주냐고 했더니 그런거 없단다.
그럼 몇 시에 가냐 하니 전에 왔던 시간에 오란다.

여기까지 통화를 하고 느낀 건
임원들이 직원 뽑는데 별로 관심이 없구나 하는 거였다.
그 부서의 개발자 들만 채용 의지가 있었을 뿐이라는 느낌이 들어서 거기서 부터 좀 별로라고 생각했다.
사실상 1차 면접 때는 전에 면접 봤을 때와 마찬가지로 연봉 부분 빼면 거의 채용 확정이나 다름 없는 얘기를 했었기 때문에
임원 면접은 도대체 뭘 하나... 하는 생각이 들기도 했다.

어찌됐든 채용 프로세스의 정석대로
그 다음주에 임원 면접을 진행했다.
임원 면접을 진행하기 앞서, 영업파트에 계신 분과 약간 pre-면접 형식의 얘기를 했는데
그 분이 성격이 좀 쾌활하고 말도 시원하게 할 뿐만 아니라
내 인상을 상당히 좋게 평가해 줘서
그 이후에 나눴던 대화는 크게 문제가 되지 않았다.

실제 임원 면접시 내가 제일 싫어하는 말이 나오기 전까지 말이다.

"나는 너를 잘 모르니 너가 누군지 한번 읊어보렴" 하는 식으로 첫 말이 나오면
진짜 속 뒤집어 진다.
면접을 많이 봐서 익숙해질 때도 됐는데
난 사실 이 질문이 제일 짜증난다.
저건 좀 어그로성 발언이고 실제는 이렇게 말한다.
"자기소개 한번 해보세요."

에휴
개인 신상 및 실제 한 일이야 이력서에 다 있는 건데 무슨 소개가 듣고 싶은 건지 모르겠다.
그렇게 얘기하는 면접관에게는 난 항상 이력서에 있는 내용 고대로 얘기해준다.
너의 질문이 쓸데없는 질문이라는걸 확인시켜주려고...

면접을 보러 오는 사람 역시 그 회사가 뭘 하는지 사전에 파악하고 온다.
그럼 면접관도 최소한 면접보러 오는 사람이 누구인지는 서류를 보고 파악해야 하는게 서로에 대한 최소한의 예의인데
진자 이력서도 안보고 들어와서 자기소개 해보라고 하는 건 면접관의 자격이 없다고 여겨진다.
이 글 보는 면접관 중에 찔리는 사람 있으면 진짜 내가 한 말 똑바로 쳐 들으렴!.

이라곤 했지만
실제로 임원 면접이 아주 좋은 분위기 속에 잘 진행이 되었고
바로 채용 할 것 처럼 연락을 주겠다고 했다.

하지만 두번째 회사도 문제는 연봉이었다.
내 연봉이 그렇게 높다고 생각되지도 않고
전직장 연봉 그대로 받겠다는게 희망연봉이었는데
며칠 뒤 뭘 더 연봉을 깎으려고 하는지 알 수 없는 전화가 걸려왔다.

솔직히 200정도만 깎았어도
"에이, 그냥 갈까?" 생각이라도 해보는데
이건 뭐... 말도 안되는 연봉을 깎아 내리면서 안되겠냐고...

면접은 정말 잘 진행해 놓고
이런 식으로 비굴하게 들어오면 나도 어쩔 수 없다.
"안돼! (이놈들아!)"

그래서 안됐(했)다.
너희들이 정말 원하는 인력이었으면 연봉 깎으려고도 안했겠지.
구걸하는 모양새를 봐선 필요한 인력이라는 건 확실한거 같은데
왜 돈을 안주려고 하는지 이해를 할 수가 없었다.
그래서 쿨하게 다른 인력 찾아보라고 했다.

이렇게 해서 의미 없는 한달을 보내게 된 것이다.

하지만 이건 시작에 불과한 일이라는 걸 그땐 알지 못했다는게 함정.

세번째 면접 이야기는 다음에 시간날때...

Thursday, May 29, 2014

면접에 대한 이야기 (1)

최근에 이직에 성공하여 한참 바쁜 나날을 보내고 있는 중에
문득 면접에 대한 얘기를 써 보면 어떨까 싶어서 첫 글을 써본다.

생각해 보면 이 회사에 온게 이직에 성공했다라기 보다는
운 좋게 이직을 하게 된 셈인데
지난 몇 달간 봐 왔던 면접과 달리 상당히 마음에 드는 면접이었고
다른 면접들과 상당히 대비되는 부분이 많아
이런 저런 느낌과 생각들을 정리해 보려고 한다.

우선 내가 회사를 그만두기 전에 처음 회사를 알아보고 면접을 봤던 부분부터 차례대로 얘기해 보겠다.

1. 스타트업 회사에서의 면접
회사를 그만둔다고 하기 전 시점부터 미리 알아보고 연락해서 면접을 진행했던 회사다.
서울 역삼역 부근에 위치한 W 회사인데
내가 그동안 쌓아왔던 스킬에 맞는 소프트웨어 제품을 개발, 판매하는 회사였고
스타트업 회사치고는 유명세를 많이 탄 그런 회사였다.

특별히 채용 공고도 없었고
홈페이지에 상시 채용에 대한 내용이 있어 주저 없이 문의 했는데
답변이 바로 와서 한번 만나보고 얘기하자고 해서
외근 일정이 잡혀 있는 날을 선택해 방문을 했다.

처음 방문했을때 난 면접이라고 생각했는데
그 분들은 그냥 내가 누구인지 얘기 정도만 나누고 싶었던 것 같았다.
그런데 얘기를 하다 보니 어느 순간 면접처럼 되어 버린 게 함정이라면 함정.

그 회사 분 중에 하나가 내가 예전에 같이 일했던 분을 알고 있어서
어느 정도 공감대도 형성 됐었고
내 경력에 대해서는 아주 마음에 들어했었다.
게다가 자기들이 어떤 제품을 만들고 어떤 비전으로 일을 하는 지에 대해서 얘기를 해 줘서
분위기가 매우 좋은 스타트업 회사로 인식 했고 좋게 받아들였다.
물론 나 또한 몇 년 전에 작은 팀(3명)에서 큰 부서(30명)로 커가는 과정에서 일을 해봤기 때문에
다시 작은 팀에서 일해서 크게 키우고 싶다는 생각이 든 것도 사실이었다.

면접이 끝날 무렵 채용 의사는 확실했고
연봉 부분에 대해서만 조율하면 되는 걸로 마무리를 했다.

이직 결심 후 첫 면접이 너무 잘 진행되고 있는 것 같아서 좋긴 했지만
문제가 있었다.

이후에 진행되어 가는 과정이 매끄럽지 않았다.
내가 연락을 기다리는 입장인데도 시간을 좀 끄는 것 같았고,
내가 먼저 어떻게 진행되고 있는지를 물어봐서야
연봉 조정 문제 때문에 연락을 빨리 못했었던 것을 알았다.

결국엔 내가 연봉하향까지 고려해서 얘기한 연봉보다
더 못줄 것 같다는 연락을 끝으로 채용이 성사되지 못했다.

이 면접이 기억이 나는 것은
불필요한 내용으로 사람 피곤하게 만든 것이 없었다는 것이다.

서로 원하는게 뭔지 알고 얘기하는 수준이었기 때문에
서류통과 - 실무면접 - 임원면접과 같은 피곤하지만 정석인 채용 프로세스를 거치지도 않았고
지구가 멸망할 날이 얼마 남지 않았을 때 뭘 하겠냐와 같은 뜬금포 압박 질문도 없었다.

연봉 부분에 대해 서로 만족하는 수준이었다면
별 문제 없이 첫 면접을 본 회사를 다니지 않았을까 한다.

Saturday, April 26, 2014

CGV의 'I GREEN it' 그린 캠페인에 반대한다.

CGV에서 최근 진행하는 그린 예매 캠페인이 있다.
물론 취지는 아주 좋다.
환경을 생각해서 영수증+입장권 형태로 나오는 종이 출력을 하지 않고
스마트폰의 모바일 티켓을 이용하자는 것이다.

아래 링크가 그 캠페인 화면이다.
http://www.cgv.co.kr/Event/140401_GreenIt.aspx

그냥 하면 재미가 없으니
캠페인 참여 일수 및 스탬프 갯수도 나오고
나무 일러스트도 나온다고 하니 뭐 모으는 재미도 있을 것이다.

하지만...하지만...
문제가 있다.

나 같이 CGV VVIP 등급은
특별관 8000원 현장 발권 혜택이 있기 때문에
참여를 할래야 할 수가 없다.

CGV를 이용하는 사람들에게는 그린예매 캠페인에 동참하라고 하지만
VVIP 등급들은 참여를 하라는 건지 말라는 건지 모르겠다.
물론 특별관이 아닌 일반 영화를 예매해서 참여하는 건 가능하지만
모든 영화 예매를 모바일 티켓으로만 하고 싶은 나같은 사람에게는 어쩌란 말인가?

그래서 이런 방법을 쓰는게 어떨까 생각해 본다.

1.
현장 발권도 아예 모바일 티켓으로 해 주는 것이다.
예매가 아닌 현장 결제라는 점에서 이미 '그린 예매 캠페인'이 아닌 '그린 결제 캠페인'이 되어 버리긴 하지만 그냥 '예매'라는 타이틀을 버리고 이참에 그냥 '그린 캠페인'으로 바꿔서 현장 발권도 모바일티켓으로 해주는 걸로 확대하는 것이다.
CJONE 카드 긁으면 누군지 회원 정보가 나오니까
입장권도 영수증도 아닌 종이 뽑지 말고 바로 모바일 티켓으로 나오게 해 주면 좋을 것 같다.
어차피 이거 뽑는거 줄이자는 캠페인이니 이상할 거 하나 없다.
이게 사실상 제일 쉬운 방법 중에 하나가 아닐까 싶다.

2.
몇 년째 계속 되고 있는 건데
VVIP의 특별관 8000원 할인 혜택은 무조건 현장 발권만 된다.
심지어 그 혜택을 누가 얼마나 받는지 수기로 기록하는 장부도 있는데 - 영화관 마다 다 있다
그 장부 나중에 전산으로 관리하는 것도 일일텐데
그걸 직원한테 일일이 수기로 적게 하는 것도 웃긴다.
당장이야 수기로 적는게 편하고 좋긴 하겠지만
전산 시스템을 개발해서 관리하는게 차후 몇 년을 내다보면 더 현명한 일일 것이다.

말이 길어졌는데,
VVIP 특별관 할인 혜택을 온라인에서 해 주면 해결 될 것 같다.
대리 결제 및 계정 도용 같은 일 때문에
시대를 역행하는 방법을 쓰고 있는 것 같긴 한데
CGV 측에서 좀 합리적인 방법으로 고려해 봤으면 좋겠다.



다시 생각해 보니 2번이 될려면 시간이 좀 걸릴테니 당장 1번이라도 해주면 좋을 듯 하다.
어차피 POS기로 좌석 지정 및 결제 까지 다 해주는 거니 출력만 안하면 되지 않을까 싶다.

현장발권->모바일티켓이 현실화 된다면
난 그제서야 그린 캠페인에 찬성할 것 같다.

영화 리뷰: 페이스 오브 러브

http://www.cgv.co.kr/community/review/review_view.aspx?idx=83125