http://jamestic.egloos.com 소프트웨어 이야기 ko Sun, 08 Nov 2009 13:23:05 GMT Egloos http://pds3.egloos.com/logo/200705/07/89/d0007089.jpg http://jamestic.egloos.com 80 80 소프트웨어 이야기 http://jamestic.egloos.com/2468177 http://jamestic.egloos.com/2468177
얼마 전에 시작한 Learn by Project의 진행 상황을 궁금해 하시는 분이
몇 분 계신 것 같아 알려드립니다.

angle30님, salad님, 이렇게 학생 둘과 진행 중에 있고요.
두 분 모두 총명하고, 열정이 넘쳐서 기분 좋은 프로젝트가 되고 있습니다.

1차 목표는 syslog protocol의 sender side와 receiver side를 구현하는 것이고요.
Linux, Solaris, Windows, VxWorks환경에서 Release quality의 library를 만드는 것입니다.

일반적으로 이야기하는 syslog 맞고요.
그 중에서 syslog protocol 부분에 해당하는 내용입니다.

기술적으로 이야기 하면
RFC 3164, RFC 5424를 구현하는 것이고,
운이 좋다면 RFC 3195까지 도전해보려고 합니다.

Output이 나올 즈음에 또 한번 알려드리도록 하죠.
애정 어린 관심 항상 감사 드리고요.

고맙습니다.

]]> 메인스토리 http://jamestic.egloos.com/2468177#comments Sun, 08 Nov 2009 13:23:05 GMT 제임스 http://jamestic.egloos.com/2457616 http://jamestic.egloos.com/2457616
(가슴 뛰는 회사 중에서 p101~102 / 존 에이브램스)

한 어부 이야기가 있다.

어느 날 오후 그는 아내와 함께 일광욕을 하며 해변에 앉아 있었다.
아침에 커다란 물고기를 잡은 터라 그날은 바다에 더 나가지 않기로 했다.
한 부유한 사업가가 지나가다가 그에게 물었다.

"왜 바다에 나가서 물고기를 더 잡아오지 않나요?"
"왜 그래야 하죠?" 어부가 물었다.
"그러면 돈을 더 벌 테니까요. 아마 배도 한 척 더 사고 사람도 몇 부릴 수 있지 않겠어요?"
"그건 왜 그래야 하죠?" 어부가 다시 물었다.
"그렇게 되면 돈을 더 많이 벌고 배를 더 살 수 있겠지요.
그렇게 몇 년간 더 열심히 일하면 당신은 부자가 될 거예요."
"내가 왜 그렇게 해야 하는데요?"
"그렇게 되면 일을 그만두고 아내와 함께 해변에서 일광욕이나 즐기며 살 수 있을 것 아닙니까?"

"그게 바로 내가 지금 하고 있는 것이잖소?"





두 가지 질문이 떠오르네요.

하나,
'진짜 그런 건가?'

둘,
'내가 하고 싶은 일 중에, 지금 하지 못하고 있는 것이 뭐가 있지?'

(지금 해야겠다는 의미로~)



PS. 좋은 책에 인연을 닿게 해주신, 스트롱베리 님 고맙습니다.

]]> 메인스토리 http://jamestic.egloos.com/2457616#comments Sun, 25 Oct 2009 12:00:33 GMT 제임스 http://jamestic.egloos.com/2452314 http://jamestic.egloos.com/2452314
실무라는 궁금증
학교에서 공부하면서 제일 궁금한 것 중에 하나가 이런 것 아닌가요.
'회사에서 실제 프로젝트를 어떤 식으로 할까? '

인턴 프로그램이라는 것이 있지만, 실제 해보면 실무와는 조금 동떨어진
회사생활의 가벼운 체험 정도에 머무르는 것이 아닌가 하는 생각이 듭니다.
'그런 거 말고, 실무라고 부를 수 있는 치열한 프로젝트에 참여해서 함께 해볼 수는 없을까?'

한편, 회사를 다니면서 실무를 하는 초년생들은 이런 것이 궁금하지 않을까 합니다.
'다른 회사들은 어떻게 프로젝트를 수행할까?'

이런 궁금증을 풀기 위해서, 책도 읽어보고, 세미나도 참석해보고,
선배의 이야기도 들어보고, 스터디 모임도 해보지만, 궁금증을 채우기에는 항상 부족하지 않나요.
'그건, 아마도 경험이란 것은, 쉽게 전달되지 않기 때문 일겁니다.'

이런 질문을 하는 분이고, 소프트웨어의 경험을 좀 더 넓히고 싶은 분이 있다면,
이 프로그램에 관심을 기울여 보십시오.


Learn by Project
실제 적용되는 프로젝트의 작은 부분을 수행하면서 스스로 배우는 방법입니다.
먼저, 어떤 부분을 만들지, 리더와 함께 상의 합니다.
그 다음에 API를 작성하고 설계를 하고, 시험을 하게 되는 방법입니다.

저희 팀에서는 Lego같은 block형태로 소프트웨어 개발을 하는데,
자신의 작은 Lego block을 개발하는 것이 목표라고 할 수 있습니다.
그 목표에 다가가며, 자신도 모르게 배우며 성장하는 것이 희망이고요.

프로젝트 방식
개인의 능력이나, 익숙한 분야에 따라서
무엇을 만들지 Lego block의 범위를 정한 후, 스스로 설계를 하고 코딩을 합니다.
Lego block의 크기는 투입할 수 있는 시간에 따라서 정하면 될 것 같고요.
일주일에 한번 정도 2~3시간 얼굴 보며 미팅을 하고,
나머지는 메일을 통해 진행하면 될 것 같습니다.
물론, 저희 팀에 오셔서 함께 작업을 하는 것은 언제나 환영입니다.

팀에 부담이 되지 않을까요?
네, 사실 팀에 부담이 됩니다. 실제로 가이드를 하며 함께 개발을 하는 것보다,
직접 개발을 하는 것이 더 적은 노력이 들게 되고요.
개발하는 Lego block이 원하는 품질에 다다르지 못할 가능성은 늘 존재합니다.
그래서 C를 어느 정도는 해야 부담이 조금이나마 덜 할 것 같습니다.
리딩은 저희 팀에서 제일 한가한 제가 직접 하게 될 것 같고요.
이 프로젝트는 단지 효율만을 위한 것이 아니기 때문에,
부담에 대해서는 크게 걱정 하지 않으셔도 될 것 같습니다.

C는 어느 정도 하면 되는 거죠?
지원을 하시면, 간단한 C 시험을 할 예정입니다. C를 잘 하면 잘 할 수록 좋겠지만,
이 정도의 문제를 해결 할 수 있다면 기본은 되었다고 보입니다.

string의 글자를 거꾸로 재 배치 하기 - void reverse(char *str)
10개 짜리 array의 integer를 sorting 하기 - void sort(int array[10])
single linked list의 순서를 바꾸기
(한 줄로 쓸 수가 없군요 - pointer의 이해 여부의 확인용입니다)

이 정도입니다.
자전거를 못 타는 사람이 묘기를 부릴 수는 없기 때문에,
C가 부족한 분은, 공부를 더 하신 후에, 다음에 지원하시면 됩니다.

기간은 어느 정도?
프로젝트 기간은 2~3개월로 생각하고 있습니다.
개발 환경에 익숙해지는 시간을 빼면 상당히 적은 시간이고요.
작은 Lego block 하나를 만들 수 있는 시간이라고 보입니다.
1년에 4회를 진행할 예정이고요.

어떻게 지원하죠?
첫 프로젝트는 11/1일에 시작하려고 합니다.
지원은 10/24일 (토) 24:00까지, 메일로 (좌측) 하시면 됩니다.
10/26일(월)부터 10/31일(토) 중 가능한 시간에 간단한 C 코딩 시험을 하시면 되고요.
11/2일(월)에 인원을 확정하여, 그 주중에 미팅을 하는 스케줄입니다.

첫 번째 프로젝트가 어느 정도 성공을 해야, 계속 진행 할 수 있기 때문에
이번에는 가능하면 성공 가능성이 높은 분들께 우선권을 드리고자 합니다.
성공의 가장 큰 가능성이란, 바로 '열정'이고요.
위에 말씀 드린 것과 같이 C가 부족한 분들은 다음 기에 지원하시면 됩니다.
(다음 기는 2/1, 5/1, 8/1에 예상됩니다)

인원은 2명 정도가 적당한 것 같고요.
많아야 3명 정도가 저에게 주어진 시간 내에 가능한 인원이라고 생각됩니다.


팀소개
마지막으로 간단한 저희 팀의 소개입니다.
저희 팀은 Embedded System과 Network management를 하는 platform을 개발 합니다.
Embedded System과 Network management의 host환경은 상당히 다르기 때문에,
한 분야에서 사용한 기술이 다른 쪽에 적용하기가 까다로운 분야지요.
예를 들어, Embedded System은 RTOS (VxWorks나 Embedded Linux) 기반에서
언어는 C를 주로 사용하지만,
Host 환경은 Solaris, Linux, Windows의 OS를 사용하고, C, VC++, Flex (Actionscript),
XML, SQL등을 사용하며, Oracle, SQL Server와 같은 Database도 사용하는 환경입니다.
저희 팀은 이 두 분야를 이어줄 수 있는 platform 형태의 개발 작업을 많이 하고 있고요.


Q. 팀별로 프로젝트를 진행하는 것인가요?
아닙니다. 개인별로 자신의 Lego block을 만드는 것입니다.
2분과 진행한다면, 2개의 Lego block이 만들어 지겠죠.

Q. 참여할 프로젝트의 내용은 정해져 있는 건가요?
그렇지 않습니다. 개인별 능력이나, 시간, 익숙한 분야가 모두 다르기 때문에,
지원하는 분에 맞는 Lego block의 목표를 함께 잡아갈 예정입니다.


이 외 궁금하신 점 있으시면, 리플을 다셔도 되고요.
메일로 직접 물어보셔도 됩니다.

고맙습니다.

제임스 드림



PS. object님께서 알려주신대로 Logo block의 정확한 영어 표현은 Lego brick입니다.
      고맙습니다.

]]> 메인스토리 http://jamestic.egloos.com/2452314#comments Sun, 18 Oct 2009 14:05:38 GMT 제임스 http://jamestic.egloos.com/2448658 http://jamestic.egloos.com/2448658
저희 팀에서는 Lego block과 같은 s/w의 단위를 module이라고 부릅니다.
alarm이라는 module을 작성하기로 하였죠.

alarm이란 매우 간단한 기능입니다.
예를 들어, 2009년 11월 11일 9시 00분 00초에 어떤 일을 하도록 하는 기능이죠.
구현하는 입장에서 보면
현재 시간을 계속 지켜 보다가 설정한 시간과 같으면 등록한 function을 불러주면 됩니다.

휴대폰에서 사용하는 알람 기능이나
Windows에서 사용하는 스케줄러 혹은 구글 캘린더에서 지원되는 흔한 기능입니다.
Linux/Solaris사용자라면 익숙하신 crontab의 기능과도 비슷하고요.

'하루면 끝낼 수 있겠다~' 하고 시작을 합니다.



작업을 하다 보니까, alarm의 기능이란 정확히 말해서는 반복 기능도 포함되더군요.
예를 들어 '매시 00분 00초에 무슨 일을 해라~' 와 같은 기능을 수행해야 합니다.

조금은 복잡해 보이지만, 이틀이면 끝낼 수 있을 것 같습니다.



조금 더 작업을 하다 보니, 반복에는 이런 기능도 필요하다는 것을 알게 되었습니다.
매달 말일에, 혹은 마지막 주의 금요일에 뭔가를 하라는 기능이죠.
정리를 해보니까, 매분, 매시, 매일, 매주, 매달, 매년 식의 기능이 필요하더군요.
이중에서도 매달의 경우에는 이런 방법도 됩니다.
매달 25일, 이건 쉽군요.
반면 요일을 사용하는 경우에는 조금 복잡해집니다.
매달 1번째 수요일, 매달 1번째 주일 (월-금), 매달 마지막 금요일 등과 같이 말입니다.
게다가 2주에 한번 과 같은 기능도 필요하고요.

구현 자체는 해 볼만 한데, 이것을 어떻게 API로 만들지가 고민입니다.
structure형태로 만들다 보니, 참으로 복잡해 지는 군요.
모든 기능을 추가해서 만들어 보니, '이 복잡한 것을 누가 쓸까?' 하는 생각이 듭니다.

게다가 1.1 버전에서 upgrade가 필요하게 되면,
backward compatibility를 지원하는 것이 힘들어 보입니다.



'backward compatibility를 지원하면서도,
쉽게 사용할 수 방법이 없을까?'

생각해낸 것은 시간을 string으로 표현하는 방법입니다.
예를 들어, 매 2주 간격으로 수요일 9시 00분 00초에 를 아래와 같이 표현하는 거죠.

"2 weekly wed 09:00:00"

string이기 때문에, 새로운 형태가 필요하면 쉽게 추가할 수 있습니다.
게다가 직관적이라서, 사용자는 행복할 것 같습니다.

그런데 개발자는 걱정이 태산입니다.
이미 일주일이 지나버렸고, "2 weekly wed 09:00:00" 과 같은 string을 처리하려면
parser도 작성을 해야 되기 때문이죠.

하루면 끝날 것 같았던 module이 1주일을 벌써 넘기고,
앞으로도 적어도 1~2주는 더 써야 할 것 같군요. 이것 참...



alarm 발생 부분의 동작부분은 간단합니다.
시간을 보면서 2009년 11월 11일 9시 00분 00초가 되면 alarm을 발생시키면 됩니다.
그런데 실제로 해보니, 8시 59분 59초에서 한번 돌고, 9시 00분 01초에 program이 도는 경우가
있더군요. 이런 CPU를 받지 못하는 starvation이 발생하기 때문에
시간이 같은지 만을 확인해서는 alarm을 발생시키지 못하는 버그가 발생합니다.

대신 시간을 비교해서, alarm 설정시간이 현재 시간보다 크거나 같으면 발생시켜야 합니다.
그런데, 시간을 비교하는 것이 생각만큼 간단하지 않습니다.
년,월,일,시,분,초를 모두 비교하다 보니,
time을 관리하는 module이 있으면 좋겠다는 생각이 듭니다.

마음이 급하지만, time module을 하나 더 만들기로 합니다.
이왕 하는 것, 2개의 time을 비교하거나, 더하거나, 빼거나 하는 기능도 만들기로 합니다.
현재의 시간을 읽는 interface도 추가를 하고요.

길어야 하루면 될 것 같습니다.



time module을 만든 후에 alarm에 적용을 하니,
CPU를 받지 못하는 starvation이 어느 정도 발생하여도 잘 동작합니다.
다행입니다.
하나의 alarm은 이제 잘 동작하니, 반복 alarm을 구현하고 시험합니다.

다행히, 반복기능의 구현은 쉬웠습니다.
그런데 시험을 하려고 하니, 막막합니다.

매분 alarm을 시험하려면 3~4분 기다리면 되지만,
매시 alarm을 시험하려면 3~4시간을 기다려야 합니다.
그 정도면 할만하지만 매주 alarm은 너무 길군요.
게다가 매월, 매년을 어떻게 시험합니까?
그렇다고 시험도 안 한 module에 완성이라는 도장을 찍을 수는 없고요.
이제 막바지인데, 마음이 답답해 지는 군요.



결국 생각해 낸 것은, '시간을 어떻게 빨리 흐르게 할 수 없을까?' 하는 것이었습니다.
alarm module은 현재시간을 time module로부터 얻기 때문에,
time module에서 현재 시간보다 조금 더 빠르게 시간을 넘겨주면
짧은 시간내에 시험이 가능할 것도 같았습니다.

결국 time module을 upgrade하여, 시간을 몇 배속으로 흐르게 하는 기능을 추가하였습니다.
10배, 100배, 1000배로 시간을 흐르게 하면서 시험을 하는 것이죠.
며칠 전에 time간에 빼거나 더하는 기능이 있어서 쉽게 구현을 했습니다.
시작한 시간에서 현재 시간을 뺀 다음, 여기에 몇 배를 곱한 후에, 다시 더하면 되더군요.

근데 적용을 해보니, alarm module의 시험에는 여러 가지 속도의 시간이 필요합니다.
매일은 10배라면, 매주는 100배, 매달은 1000배 이런 식이죠.
그러다 보니, 10배로 돌다가, 그 다음에 100배로 돌고 하는 연속 기능이 필요하더군요.

time module을 upgrade하는데 또 하루가 지나갑니다.



휴우~, 하루면 될 줄 알았는데, 벌써 한 달이 다되어 갑니다.
그나마 alarm module은 거의 완성이 되어 실제 프로젝트와 integration을 하였습니다.
예상대로 잘 동작합니다. 그렇게 시험을 했으니 잘 돌지 않을 이유가 없죠.

근데, alarm module사용자가 현재 설정된 alarm을 조회할 수 있는 기능을 원하더군요.
쉬운 기능이라고 하며 아래의 string의 list를 넘겨주었습니다.

"2 weekly wed 09:00:00"

사용자는 string을 받아 들고는 황당한 얼굴을 합니다.
UI 스케줄러에 표시를 해야 하는데, '제가 이걸 parsing해야 합니까?' 하는

결국 사용자는 structure 형태의 (XML이던, API던) data를 원했고,
설정은 string으로, 조회는 structure로 하는 일관성이 깨진 interface가 되어 버립니다.

일관성을 위해서는 structure로 설정과 조회를 하면 좋겠지만,
string이 사용하기 편하다는 이유로 그대로 놓아두고 맙니다.
사실 마음속 한구석에서는 이런 말을 하고 있는지도 모르겠습니다.
'parser를 작성하며 사용한 2주의 시간을 의미 없이 버릴 수는 없자나...'



간단해 보이는 alarm module하나도
가보지 않은 상태에서 그것을 예상하기란 참으로,
간단하지 않은 일 같습니다.

고맙습니다.

제임스 드림

]]> 메인스토리 http://jamestic.egloos.com/2448658#comments Tue, 13 Oct 2009 15:12:51 GMT 제임스 http://jamestic.egloos.com/2416697 http://jamestic.egloos.com/2416697
얼마 전, 한 예비 졸업생 친구의 질문이 생각납니다.
'회사에 취직하려면 뭘 준비해야 하나요?'

자신의 원하는 좋은 회사에 취직하려면, 뭘 준비해야 하느냐? 하는 질문 같아서,
TOEFL공부하고, 인터뷰 연습도 하고, 자격증도 열심히 따고,
경력 관리하는 법 배우고, 또 이력서 쓰는 방법도 배우라고 답을 해야겠지만,
정작 그 친구의 내면에서 들려오는 질문은 이런 것 같아 보였습니다.

'저는 S/W를 참 좋아하는데…
어떻게 하면 좋은 회사에 들어가서 즐겁게 오랫동안 일할 수 있을까요?'



대기업에서 일하던 때가 기억납니다.
모두들 대단히 뛰어난 인재들이었죠.
실력이 뛰어난 사람도,
학벌이 훌륭한 사람도,
머리가 뛰어난 사람도 있었지만,
이 사람들이 모두 회사 생활을 즐겁게 하는 것 같지는 않아 보였습니다.
나름대로 개인적인 이유가 있었겠지만,
3자의 입장에서 지켜보면서 이런 것들이 부족하지 않았나 생각해봅니다.


S/W Coding 잘하기
S/W 엔지니어를 하겠다는 사람이 Coding을 잘하는 것은 당연한 것이지만,
실제로 Coding을 잘하는 사람은 그리 많지 않은 것 같습니다.
저도 지금 주로 사용하는 C를 회사에 입사해서야 본격적으로 사용하였으니 말이죠.
나중에 직급이 올라가서 Architecture와 같이 추상적인 작업을 하는 것은 바람직해 보이지만,
처음부터 Coding에 많은 시간을 보내지 않은 분들은 업무 적응에 어려워 했던 것으로 보입니다.
이분들은 직급이 올라가서도 비슷했는데, Code라는 detail없이 S/W를 이야기 하다 보니,
추상적인 이야기로 빠지기 쉽고, 자신감의 결여를 다른 힘의 논리로 해결하다 보니,
팀원들을 리드하는데 어려움이 있다고 많이 이야기 하셨습니다.
역시, 첫 단추는 S/W Coding을 잘하기부터 인 것 같습니다.

'S/W Coding은 어떻게 잘하나요?'
정답은 저도 잘 모르지만, 참고할 만한 제 작은 경험 이야기를 해드리죠.
학교 공부를 열심히 해야 할 대학교 3학년이었는데, 한 친구가 프로젝트를 따왔습니다.
지금 같으면, 작은 마이크로 웹 사이트 하나 만드는 정도의 일이었는데,
방학을 합쳐 3개월 내내 밤을 새워 일을 했는데, 도무지 만들 수가 없더군요.
지금 하라고 하면 쉽게 하겠지만, 그 당시 저의 한계는 거기까지였나 봅니다.
그 프로젝트는 결국 실패를 했고요. 그 친구는 또 다른 프로젝트를 따왔습니다.
또 실패를 하고, 또 실패를 한 이후에, 아주 작은 성공을 했죠.
또 실패를 하고, 작은 성공을 하고 …
그렇게 실패와 성공을 반복하면서 조금씩 실력이 늘어난 것 같습니다.
그때부터 '잘은 모르겠지만, 많은 프로젝트를 하는 게 도움이 됩니다' 라고 생각하는 것 같고요.


영어 잘하기
요즘 학생들은 워낙 영어를 잘하더군요.
하지만 저는 영어를 잘하지 못했습니다.
고등학교 때, 번역을 하면 '소설 쓰냐?' 라는 이야기를 들었으니까요.
대학교에 들어가서도 원서를 가지고 하는 수업에는 애를 먹었습니다.
그래도 번역본을 보거나 친구들에게 도움을 받으려고 했지,
원서를 열심히 보려는 생각은 하지 않았죠.

운이 좋게 회사에 들어왔는데, 팀장님이 공부해서 세미나 하라는 책이 원서더군요. 이런~
업무에 본격적으로 들어가보니, 검토하라고 던져주시는 Spec 또한 전부 영어이고요.
S/W manual도 영어이고, 도대체 영어를 잘 못하면, S/W Coding을 해볼 기회도 없더군요.
'아, 그래서 부모님이, 선생님이 영어를 열심히 하라고 그러셨구나' 하고 깨달았습니다.
조금 늦었지만, 어쩌겠습니까?
다행히 읽는 영어는, 듣거나 말하는 것 같이 까다롭지는 않으니
Terminology를 정리하면서 보니, 조금씩 눈에 들어오기 시작하더군요.
영어 단어를 한글로 번역하면 여러 가지를 사용해서 헷갈리지만,
Terminology는 늘 같은 것을 사용하니,
이것만 잘 정리하면 오히려 영어책이 더 쉬워지기도 한다는 것을 터득하기 시작했습니다.
참으로…


사랑 받는 사람 되기
저도 천성이 엔지니어이다 보니, 사람들의 좋은 점 보다는 좋지 않은 점이 먼저 보입니다.
상대방의 좋지 않은 점을 이야기 하다 보니, 주변에 사람들이 하나 둘씩 없어지더군요.
회사에 들어와서도, 동료나 팀장님께 ‘잘못된 것은 잘못된 것이죠’ 하고 이야기 하니,
'거참 이상한 녀석 하나 들어왔군' 하는 분위기였죠.

주변에 하나씩 사람이 없어지던 차에, 감사하게 누가 지적을 해주더군요.
'인간관계가 얼마나 중요한 것인지…'

'프로가 버그를 만들면 안되죠!' 라고 머리에는 떠오르지만, 큰 숨 들이쉬고 한 박자 쉬며,
'네, 그럴 수도 있죠 뭐, 제가 고칠까요?' 하니, 인간관계가 조금씩 회복되었습니다.

그렇다고 무조건 양보하는 것은 아니지만
상대방이 저를 미워하지 않는 범위 내에서 내 주장을 이야기 하는 법을 터득한다고 할까요.
동료와 후배들과도 조금씩 가까워 지고,
선배님들도 '그 녀석 인간됐네~' 하는 이야기도 하시고 말이죠.
제일 좋은 것은 일을 선택할 수 있는 폭이 넓어졌다는 것일 겁니다.


공부 즐기기
저는 학교가 참 재미없었습니다.
똑똑한 학생도 아니었고, 성적도 그리 좋지도 않았고,
학교 다니는 것은 내 적성이 아니라고 생각했죠.
그런데, 회사에 들어와서, 배움이 즐겁다는 것을 깨달았습니다.

Coding을 해서 새로운 것을 만들어 내는 것은 즐거움이지만,
공부를 통해서 해당 분야의 지식을 얻은 후에의 Coding은
한 단계 계단을 점프하게 해주는 마력 같다는 것을 느꼈거든요.

공부하는 자체는 상당히 인내를 요구하는 일이지만,
그것을 완벽에 가깝게 끝냈을 때 얻을 수 있는 능력은, 배움을 즐겁게 만드는 힘인 것 같아요.

공부야 말로 학생들의 전문 분야이지만, 정작 즐기는 학생들은 별로 없죠. (교육의 잘못인 듯)
이에 반해, 세상은 계속 변하다 보니,
누구던 계속 공부하면서 세상과 속도를 맞추어야 합니다.
공부는 끝나지 않죠.
어차피 공부가 끝나지 않는다면, 즐기는 방법을 배우는 것이 제일 좋은 것 같아요.
그리고 실제로 배움은 즐거운 거구요.




여전히 이 네 가지를 배우고 있는 중이지만,
그 덕분에 S/W를 즐겁게 할 수 있어서, 선배님과 주변 분들께 항상 감사 드린답니다.

질문에는 약간 빗나간 답인 것 같지만,
즐거운 일인 S/W Coding을 여전히 즐겁게 만드는데, 도움이 되었으면 좋겠구요.
우리나라에도 행복한 S/W엔지니어가 많아지기를 바라겠습니다.

고맙습니다.

]]> 메인스토리 http://jamestic.egloos.com/2416697#comments Thu, 03 Sep 2009 01:18:06 GMT 제임스 http://jamestic.egloos.com/2392529 http://jamestic.egloos.com/2392529
결국은 다 지나간다고...
성적 잘 받으려고 아둥바둥 하던 것도,
취업하려고 정신 없이 달렸던 것도,
힘들어서 죽겠다고 생각하는 것도,
결국은 다 지나가는 거라고...

나중에 뒤돌아 봤을 때, 그리고 죽기 직전에
사실 학위, 업적도 중요하겠지만
다른 사람을 아끼고 사랑해주고 사랑받는게
더 남지 않겠느냐고...


<중환자 실의 딸을 돌보시는 어머니가, 병문안 온 친구에게 하시는 말씀>

여유를 좀 찾아야 겠네요.
고맙습니다, 예슬님.


]]> 메인스토리 http://jamestic.egloos.com/2392529#comments Thu, 06 Aug 2009 11:27:42 GMT 제임스 http://jamestic.egloos.com/2368074 http://jamestic.egloos.com/2368074
얼마 전에 SAP를 전문으로 하는 기업의 이사님과 저녁을 할 기회가 있었습니다.
처음 뵙는 분이었는데, 상당히 명석하시고, 쾌활하심이 아직도 기억에 생생하네요.
회사도 매우 독특해서, 팀원들에게 이런 제안도 한다고 해서 놀랐죠.

'이번 독일 프로젝트가 1주일인데, 4일에 끝나고 나머지는 놀러 가자~!'


참으로 독특하신 이사님께, 이런 질문을 드려보았습니다.

"이사님은 어떤 기준으로 사람을 뽑으세요?"


"저희는 학벌이 좋은 친구들은 돌려보내곤 하죠.

처음에는 멋모르고 뽑았어요.
이 친구들, 역시 일을 잘하더군요.
근데, 한 2~3년 되니까, 휙~ 하고 나가버리는 거예요.

저희 업무상, 한 1년은 공부를 시켜야, 좀 일을 시킬 만 해지는데,
학벌이 좋은 친구들은 조금 배웠다 하면 그만두니, 애가 탈 노릇이죠.
아마도 상대적으로 기회가 더 많아서 그런가 봐요.

그래서, 학벌은 조금 좋지 못하더라도, 성실한 사람을 선호하죠.
이 친구들은, 학벌이 조금 좋지 못한 것을 자신도 알다 보니,
살아남는 유일한 길이, 열심히 해서 실력을 쌓는 것뿐이라는 걸 잘 알아요.

그러다 보니, 정말 열심히 합니다.
게다가 한번 정착하면 다른 곳에 가려고 하지 않아요.
사실, 지금까지 함께 있는 많은 팀원들이 이런 친구들이죠.

그래서,
저는 학벌만 좋다고 해서, 무턱대고 받지는 않습니다."


"아 그렇군요.
고맙습니다~ 이사님"


]]> 메인스토리 http://jamestic.egloos.com/2368074#comments Wed, 08 Jul 2009 14:02:36 GMT 제임스 http://jamestic.egloos.com/2358818 http://jamestic.egloos.com/2358818
"얘야, 너는 은행원이 되거라."

"엄마, 은행원이요?"
"으응~"

"은행원이라면…
네, 손님 어서오십시오.
2만원 입금이십니까. 잠깐만 기다리십시오. 처리해드리겠습니다.
이런거요?

은행 문닫고, 밤늦게까지 숫자 맞추다가,
10원이라도 빠지면, 어떻게서든 맞추어야 한다는 그 은행원이요?

은행원이 월급 많이 받고,
안정적인 직장이라서 좋겠지만,
저는 아닌 것 같아요.
숫자만 보면 머리가 아파오거든요.
죄송해요. 엄마.

혹시 돈을 많이 벌지 못하더라도,
저는 제가 정말로 좋아하는 일을 하고 싶어요."





벌써 엄마가 돌아가신지도 오래되었네요.
지금은 엄마가 왜 은행원이 되라고 그러셨는지 아주 잘 알 수 있을 것 같아요.
저를 얼마나 생각하셨는지 잘 알고요.

엄마, 저는 은행원이 되지는 않았어요.
그 대신, 제가 꼭 하고 싶었던 일을 하고 있어요.

그리고, 이 일을 하고 있을 때면,
세상에서 가장 행복한 사람이 된답니다.

보고 싶네요.


]]> 메인스토리 http://jamestic.egloos.com/2358818#comments Sun, 28 Jun 2009 05:30:52 GMT 제임스 http://jamestic.egloos.com/2323502 http://jamestic.egloos.com/2323502
"성아, 어디든 다 비슷하겠지만,
특히 회사 생활에 있어서는 인간관계가 제일 어려운 것 같아.
나도 초년생일 때 정말 많은 실수를 했지. 참 어려워.
그러면서 한 가지를 배웠는데,
그건 사람과 사람간의 커뮤니케이션에는 온도라는 게 있는 것 같아.
예를 들어, 업무 메일을 주고 받다 보면 온도가 떨어지게 되고,
직접 얼굴을 마주보며 커피라도 한잔하면서 이야기하면 온도가 올라가고 말이야.

이렇게 커뮤니케이션에는 온도가 있는 것 같아.
업무 메일이나 업무 문자, 공지라든지, 공식회의 같은 것은 차가운 것들이지.
메신저나 전화, 그리고 직접 얼굴보고 이야기하는 것들은 따뜻한 것들이고.

인간이 따뜻한 동물이다 보니, 어느 정도 온기를 유지시켜줘야,
사람과의 관계가 원만하게 유지되는 것 같아.
나 편하다고, 차가운 업무 메일만 계속 보내다 보면, 온도가 너무 낮아져서 감기에 걸리듯이
가끔씩 '안녕하세요~' 하고 밝게 건네는 한마디로 온도를 높여주어야 하는 것 같아.



아마도 이미 다 알고 있는 이야길 거야.
근데, 궁금한 것은 모두가 따뜻한 커뮤니케이션을 원하면서도
정작 차가운 커뮤니케이션을 쉽게 선택하는 이유는 뭘까?

예를 들어, 그냥 찾아 가서 이야기 하면 될 것을
메일로 '익일 완료 요망' 이라고 보내는 이유 말이야. 하하"

]]> 메인스토리 http://jamestic.egloos.com/2323502#comments Wed, 20 May 2009 15:32:16 GMT 제임스 http://jamestic.egloos.com/2311832 http://jamestic.egloos.com/2311832
몇 년 전으로 거슬러 올라갑니다.
정사장님이 회사를 시작했는데, 기술력 덕분에 순조로웠습니다.
사원들을 아끼는 성품인지라, 팀원들에게 매우 잘해주셨죠.
좋은 유니폼도 사주고, 책상도 의자도 최고로, 다양한 복지도 만들었습니다.
그리고, 아침에 식사를 못하고 출근하는 친구들을 위해 간편한 아침도 제공하였죠.

회사는 날로 번창해져, 인원이 많아 지게 되었습니다.
정사장님은 회사의 외부적인 일에만도 시간이 모자라게 되었고,
내부적인 것은 관리 전문가에게 맡기게 되었죠.

관리 전문가는 효율을 중시하는 분이셨습니다.
방만하다고 생각하신 복지를 조금씩 줄이게 되었고,
그 중에는 간편한 아침도 포함되어, 더 이상 제공되지 않게 되었습니다.

그러던 와중에 초창기부터 함께 하였던 한 사원이
사장님에게 불만의 표시를 하였습니다.

"회사가 아침을 챙겨주는게 당연한거 아닌가요?"




"젬스님, 근데, 아침을 챙겨주는 게 당연한 건가요?"
"글쎄요. 처음부터 함께한 사원입장에서 보면 그런 것 같기도 하고,
관리 부장님 입장에서 보면 그렇지 않은 것 같기도 하고, 잘 모르겠는데요."

"좀 애매하죠?"

"네, 그러고 보면, 점심식사 제공하는 회사도 있고, 그렇지 않은 곳도 있고,
커피 믹스를 제공하는 회사도 있고, 그렇지 않은 곳도 있는데,
'당연히' 라는 생각은 어디에서 생겨나는 것인지 참 흥미롭네요.

어딜까요?"

"이런~ 제가 질문을 드린 건데... 하하"


]]> 메인스토리 http://jamestic.egloos.com/2311832#comments Thu, 07 May 2009 14:35:28 GMT 제임스