[용병] 가장 기억에 남았던 질문 BEST ⑤

Posted at 2010.09.28 10:49 // in Project Life // by MOOVA 무바㏇
4. 나도 형처럼 용병이 되고  싶어요.

현재 Si에 만 2년차로 근무중에 있습니다. 2년동안 열심히 한 탓에 일에 대한 자신감이 붙어서 프리랜서로 전향하려고 합니다. 어떤 프로젝트부터 시작해야할지..조금 막막합니다. 프리랜서를 하려면 어떤 자질과 능력을 키워야 하는지 궁금합니다. 그리고 프리랜서를 하게되면 파견업무를 주로할텐데, 파견업무가 많이 힘드나요? 프리랜서를 선언하려면 어떻게 해야하나요?

2010:09:25 08:51:27


LG프로젝트를 진행하면서 아끼던 후배가 했던 질문이다. "프리랜서를 선언한다"라.. 참으로 멋진 말이다. 방송국이나 TV프로의 연애인처럼 그 후배는 개발자들도 프리랜서를 공개적으로 선언해서 활동할 수 있다는 인식을 갖고 있었던 것이다.
개발자가 프리랜서를 굳이 선언할 필요는 없다. 자신이 충분히 프리랜서의 자질을 갖고 있다고 생각하면 하면 되는 것이다. 단 자금의 유통이 그렇게 잘 돌아가지 않았다는것만 유념할 필요가 있다. 본인은 프리랜서를 시작할 때 어떤 프로젝트에서 3개월 이상 월급을 못 받은 적도 있었다. 이런 경우 노동부에 알리고 자신의 권익을 보호해야 했지만, 초보 프리랜서 시절 그러지 못했다는 안타까움이 있다. 프리랜서를 지향하는 사람이 가져야 할 좋은 자세 몇개를 추려봤다.

  1. 각종 세미나를 수시로 활용해서 학습의 연결선을 유지하도록 하자.

  2. 현 프로젝트가 끝났다면 추가로 계약할지 아니면 다른 프로젝트를 찾아야 할지 결정해야 한다. 다른 프로젝트를 결정되지 못하고 현 프로젝트를 마무리 했다면 그대로 2개월 이상 놀 수 있다는 것을 염두해야 한다.

  3. 각종 세금명세서와 명함을 정리하는 습관을 들이자.

  4. 계약 진행 과정중 생기게 되는 문서나 프로젝트에서 얻게 되는 문서들을 잘 보관하자. 꼭 나중에 활용할 수 있을 때가 올 것이다.

  5. 자신이 프로젝트에서 했던 일에 대해 근거를 남기자. 본인은 구글캘린더를 종종 사용한다.

  6. 주변 프리랜서들이 최근 관심있어 하는 사항에 귀를 귀울이자. 

  7. 인맥네트워크를 형성하자. 정직이든 계약직이든 프리랜서든 사장이든 어떤 인맥이라도 Winwin할 수 있는 수준이라면 인관관계를 유지하도록 하자. 단! 자신에게 도움은 커녕 피해만 주는 사람들은 멀리하자.

  8. 배풀자. 프리랜서는 가만히 있어도 더 높은 월급을 받고 있기 때문에 주변 무리의 입방아에 자주 오르락 내리락한다. 10년전이나 지금이나 똑같다. 그럼으로 주변 사람들에게 온정을 배푸는 습관을 가지도록 한다. 단 허용범위를 초과해서는 안 된다. 나중에 개털될 수도 있다는 의미

  9. 프로젝트의 인사급들과 친분을 쌓자.

  10. 계약 후 너무 무리한 요구사항이 빈번히 발생된다면 계약서상에 추가 요구사항에 관련된 란을 기입하도록 한다.

  11. 일이 끝나면 공부하자. 공부하고 신기술 익히고 다듬고 노력하자. 본인은 프리랜서라면 실력이 좋아야 한다고 믿는 사람중에 하나다. 눈에 보이지 않게 노력하자.

  12. 소스코드관리를 잘 하자. 한 곳에서 사용했던 노하우나 코드들은 반드시 재사용할 날이 종종 찾아온다. ( 필자는 삼성프로젝트를 나올 때 가지고 있던 소스와 문서들을 몽땅날린 기억이 있다. ㅠㅠ)

  13. 메모하는 습관을 기르자. 개인일정 관리 노트를 관리하는 것도 좋은 방법이고 Sticky pad와 같은 유틸을 쓰는 것도 좋은 방법이다.

  14. 노동법 관련된 법률적 상식을 익혀두는 것이 좋다. 이것을 잘 모르면 악덕사장에게 당할 수 있다. 본인도 당해본 기억이 있다.:) 아웃소싱 근로법이나 노동법 책자를 구매해서 읽어보도록 하자.

  15.  계약서를 쓸 때 초반에 바로 싸인하지 말자. 먼저 계약서를 이메일로 보내달라고 요청하여 계약서에 불공정거래에 관련된 사항은 없는지 미리 파악하자. ( 이거 정말 중요하다.). 실제로 계약서를 쓰는 당일이 오면 어떤 요소들을 수정해 달라고 요청하자.

  16. 계약서를 쓸 때 업체 사장으로부터 날조된 계약서를 쓴적 있다. 그 사장을 믿었던 내가 바보였다. 몇 달 뒤에 집에서 계약서를 유심히 살펴보니 계약기간이 2년이나 더 추가되어 있었다. 아주 작은 글씨로 써져 있었던 것이다. 보이지 않은 계약 노예화가 된 것이다. 이 사건이후 계약서는 꼼꼼히 훑어보는 습관을 지니고 있다.

  17. IT 노동처를 자주 이용하자. 프리랜서는 개인대 기업과의 거래이기 때문에 상당한 불이익을 받을 수 있다. 이것을 보호하기 위해선 공익단체를 활용하는 것도 좋은 방법이다.

  18. 투입전에 미리 프로젝트에 대해 상세히 알아본다. ( 업체들, 인력들, 기술들, 메니저들, 평판들 )

  19. 가능한 한 을 이상의 업체나 이름값을 하는 업체와 계약을 하도록 한다.

  20. 업체가 불공정거래나 인권유린과 같은 행위를 한다면 만천하에 공개한다. 개발자 커뮤니티를 이용하자.:), 녹취를 하고 자료를 보관하자.

더 기억나는 게 있다면 수시로 업데이트 하겠습니다.
저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

[Java 7] 재미있는 람다함수 지원

Posted at 2010.09.28 10:44 // in Language/Java // by MOOVA 무바㏇
Java에서 클로저 도입에 대한 이력

2005년 샌프란 시스코에서 개최된 JavaOne의 Technical General Session에거 최초로 언급됨
2006년 Gilad Bracha, Neal Gafter, James Gosling, Petervander Ahe에 의해 공동으로 제안됨(BGGA)
2008년 11월 Devoxx에서 Mark Reinhold가 클로저의 도입을 보류한다고 밝힘.
2009년 11월 Devoxx에서 Mark Reinhold는 클로저의 도입을 부활한다고 밝힘.

Java SE에서 클로저가 필요한 이유 - CPU의 멀티 코어 동향때문

CPU의 멀티 코어 동향이 Java의 lambda함수의 필요성을 촉진 시켰다.. Java는 등장 초기부터 Thread클래스 하위에 다중의 프로세스를 허용하고 있다. J2SE 5.0 Concurrency Utilities는 작업 단위로 병렬 처리를 가능하게 했다. 하지만 CPU의 멀티 코어 동향을 살리기 위해 더 작은 입자도 병렬로 실행하는 체제가 필요했다. 그래서 Concurrency Utilties에서는 보다 세분화된 작은 업무를 취급하기 위해 fork - join 체제를 Java SE7에서 도입 예정이다. fork - join을 실현하기 위해서는 상당히 많은 인터페이스가 있어야 하는데 그래서 주목해야 할 부분이 클로저이다. 클로저로 작업을 하면 유연한 병렬 실행이 자유롭다. 이것이 바로 JavaSE7에서 클로저를 도입하게 된 가장 큰 원인이다.

fork - join  : 포크와 같이 분산되었다가 결국엔 병합되는 큐단위



참고 URL :

Project Lambda



1. 람다식


람다 표현식을 작성하는 방법은 2가지가 있다.

#(인수)(식)
#(인수)(차단)

#이 lambda식의 시작을 나타낸다. 즉 #은 함수를 위한 리터럴이라고 해도 무방하다.
실제로 lambda식을 써 보면

#()(20)

항상 20을 반환하는 람다식이다. 인자가 없으므로 처음 괄호에 아무것도 지정하지 않았다.
물론 단일타입 이외에 객체를 반환할 수도 있다.

# ((new Timestamp ())
# ((new ArrayList <Integer> ())
# (((1, 2, 3))

다음은 인자가 있는 람다식이다.

# (int x) (x + x)
# (int x, int y) (x * y)
# (double time) (new Date (time))

인자가 여러개라면 ,로 구분해서 인자로 넘겨준다. 리턴값은 두 번째 가로에 묶인 식의 결과 값이다.
블록을 작성하는 경우라도 마찬가지이다.

# (int x) (x + x;)
# (int x) (return x + x;)

return을 미지정해도 return값을 받을 수 있으므로 1식과 2식은 같다. 물론 람다식에도 분기문을 사용할 수 있다.

# (int x) (if (x> 0) (return true;) else (return false;))

JavaSE7에서 제안 된 lambda식은 너무나도 쉽고 편하다.

2. 람다함수

람다식은 람다함수로 지정할 수 있다. 람다함수의 정의는 다음과 같다.

# 반환값의 형식 (인수 형식) (throws 예외)


# int () five = # () (5);
# int (int) dbler = # (int x) (x + x);
# int (int, int) multiple = # (int x, int y) (x * y);
# Date (long) timestampFactory = # (long time) (new Timestamp (time));
# boolean (int) booleanCheck = # (int x) (if (x> = 0) (return true;) else (return false;));

# void (String) myLogger = # (String message) (System.out.println (message);)

마지막은 람다 함수의 반환값이 없으면 void로 작성한다. 또한 return문에 람다 식을 직접 사용할 수도 있다.

# double () bar (# double (int) func) (... return # () (Math.random ());)

람다 표현식에 예외를 throw하려면 인수 형식 뒤에 괄호를 사용하여 작성한다.

# String (String) (throws Exception) fileReader = # (String filename) (... throw IOException (); ... return ...;)

3. 람다함수의 실행

2섹션에서 정의한 람다함수를 실행한다.

five() / / 10을 반환
dbler(10) / / 20이 반환
multiple(5, 8) / / 40이 반환
timestampFactory(0L); / / 1970/1/1 00:00 : 00 GMT 나타내는 Date 객체를 반환
booleanCheck(10) / / true를 반환
myLogger( "Hello, World!"); / / Hello, World!가 표준 출력으로 출력된다

메소드의 인자로 람다식을 넘겨줄 수도 있다. 필자가 가장 좋아해야 할 수밖에 없는 부분이 인자에 람다함수를 넘겨주는 방법이다. 만약 자바에 이것만 확실히 도입된다면 정적으로 타이핑했던 프로그램방식이 Python이나 Ruby와 같이 동적인 프로그램으로서의 발전을 기할 수 있으리라 본다.

public int [] map (int [] first, # int (int) func) (
 int [] second = new int [first.length];
 for (int i = 0; i <first.length; i + +) (
  second [ i] = func (first [i]);
 )
 return second;
)


4. 람다의 사용


java는 ActionListener인터페이스와 Runnable 인터페이스와 같이 메소드를 1개만 정의하는 인터페이스가 정말 많다.

예를들어 아래와 같은 식이

Button button = ...;
button.addActionListener( new ActionListener() {
 public void actionPerformed(ActionEvent event) {
  ...
 }
});


아래와 같이 사용된다. 단한줄로 처리할 수 있다는 이야기

Button button = ...; button.addActionListener (# () (/ / 이벤트 처리));

Comparator 인터페이스를 사용하는 sort관련 기능을 보자.

List <String> stringer = ...;
Collections.sort (stringer , new Comparator <String> () (
    public int compare (String first, String second) (
        return first.length () - second.length ();
    )
));

위와 같은 식이 아래와 같이 간단히 바뀐다.

Collections.sort (stringer # (String first, String second) (first.length () - second.length ()));

정말 행복한 코드이다. Python과 Ruby의 sort식과 비슷해졌다. 점점 자바도 스크립트류 언어를 사용하는 개발자들에게 더욱 친숙해져간다.


람다식에서 가장 눈여겨 볼만한 기술은 인자에 람다식을 넘기는 방법인데 이는 다른 스크립트류의 언어에서 볼 수 있는 동적인 타이핑을 가능하게 해 주는 장점을 지니고 있다. yield와 같은 키워드가 제공될지는 아직 미지수지만 필자는 자바의 람다식과 람다함수의 지원을 적극적으로 찬성하고 있는 입장이다.

(필자 주 : 역시나 API는 언제나 변한다. API는 외우는 것이 아니라 감각을 알고 찾아쓰는 것이다:
이 포스트의 키 포인트는 역시나 람다함수의 이점과 자바진형의 동향을 파악하기 위함이다.)


저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'Language > Java' 카테고리의 다른 글

[Java 7] 재미있는 람다함수 지원  (0) 2010.09.28
25+ Free Java FX Books  (0) 2010.01.12
블로그코리아에 블UP하기

댓글을 남겨주세요.

2010년 9월 27일, 미투데이

Posted at 2010.09.28 10:31 // in SNS // by MOOVA 무바㏇

이 글은 moova님의 미투데이 내용입니다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'SNS' 카테고리의 다른 글

2010년 10월 7일, 미투데이  (0) 2010.10.07
2010년 10월 6일, 미투데이  (0) 2010.10.06
2010년 9월 27일, 미투데이  (0) 2010.09.28
2010년 9월 15일, 미투데이  (0) 2010.09.16
2010년 9월 14일, 미투데이  (0) 2010.09.15
2010년 9월 13일, 미투데이  (1) 2010.09.14
블로그코리아에 블UP하기

댓글을 남겨주세요.

[재활로그] 7차 후. 인내와 용기

Posted at 2010.09.27 19:29 // in Hospital // by MOOVA 무바㏇

인생은 평화와 행복만으로는 지속될 수 없다. 고통과 노력이 필요하다. 고통을 두려워하지 말고 슬퍼하지 마라. 참고 인내하면서 노력해 가는 것이 인생이다. 희망은 언제나 고통의 언덕 너머에서 기다린다.

- 맨스필드


"15~17일" ~ "추석"

몸 상태가 정말 좋지 못했다. 가장 힘들었던 시기가 아닐까 싶다.

3일동안 약물치료가 있었고,  주변 사람들의 권유로 딱딱하고 차가운 음식을 씹는 바람에 
복통이 엄청났다. 고통이 8시간안 지속됐고 응급처방의 도움으로 되살아났다. 수술 후 8개월이나 지났지만 아직 특정음식에 대한 비결이 없었던 것이 화근이었다. 지식적으론 음식을 선별하는 것 만큼 쉬운 것도 없지만, 일단 음식 섭취를 하다 보면 남 다른 식성 때문에 잘 씹지 않고 넘기는 버릇이 있다. 상당한 주의를 요한다.

치료를 받고 추석 기간 내내 복통의 여파로 상당히 고생했다. 한번 틀어진 몸의 변화. 그것을 회복하려면 일주일가량의 시간이 필요했다. 약물치료기간중이라 몸의 재생능력도 떨어지기 때문이다. 또 한 번 이 기간이 지나가면 입맛이 다시 살아나고, 운동을 다시 시작하게 된다. 그리곤..평소와 같이 활동한다. 하지만, 그것도 잠시뿐이다. 바로 다음 차수에 대한 약물치료를 해야 하고, 또 한 번 지겨운 고통의 10일을 인내해야 한다. 또 10일이 지나면 살만해진다. 대체 몇 차까지 할 참인가... 점점 상실감이 커지고 있긴 하지만, 아직까지는 버틸만하다. 예정은 12차까지 있다고 한다. 반 이상은 온 셈이다. 9차를 끝낸 뒤 결과가 좋으면 9차까지만 했으면 하는 바램이다. 몸도 마음도 많이 손상됐다..


2010:09:27 13:06:07


하지만, 이 기간동안 마음만큼은 편안했다. 왜일까? 주변 사람들이 내 눈앞에서 노트북과 전용 데스크탑을 치워버렸다. 건강이 우선이니까... 허용할 수 밖에 없었다. 일주일 내내 컴퓨터와 멀리 지냈고, 추석기간 내내 친지와 친척들, 그리고 양주까지 찾아와 줬던 친구들과 그동안 하지 못했던 이야기들을 정말 많이 나눴다. 그리고 좋은 방향으로 나아가고 있는 동료도 보았다. 그래서 매우 평안했다.

하늘에 감사의 기도를 올린다. 오늘도 신선한 공기를 마실 수 있다는 행복감과 사소한 것으로부터 나오는 만족감과 매 초 감사함을 느낄 수 있다는 기쁨 때문에 오늘도 난 웃을 수밖에 없다.

"이 기간동안 나는 또 배운다. 고통이 있다고 해서 좌절하지 말것이며, 원하는데로 안 된다고 화낼 필요 없다. 이 고통을 통해서 인내와 용기를 배운다."
"생각만 바꾸면 세상이 달라진다. 세상은 나에게 불행을 가져다 주지 않는다. 세상은 오히려 가만히 있다. 불행을 만드는것은 당신 자신의 생각이다. 생각을 바꾸자. 그럼 세상도 바뀐다. 그래서 이렇게 편하다"



저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'Hospital' 카테고리의 다른 글

고비다! 하지만 자연을 생각하다.  (4) 2010.10.04
퇴원 그리고..  (0) 2010.10.01
[재활로그] 7차 후. 인내와 용기  (0) 2010.09.27
[재활로그] 5차.. 그리고 Next.  (4) 2010.08.10
[재활로그] 2010년 7월 9일.  (0) 2010.07.09
[투병로그] CT촬영 전.  (14) 2010.07.03
블로그코리아에 블UP하기

댓글을 남겨주세요.

[패턴] 가장 기억에 남았던 질문 BEST ④

Posted at 2010.09.27 18:07 // in Project Life // by MOOVA 무바㏇
4. 디자인 패턴을 사용하면 좋나요?

디자인패턴을 동료와 학습해서 제가 맡은 모듈에 적용해 보고 있습니다. 하지만, 아직 감이 잘 오지 않아요. Strategy 패턴을 적용해서 활용하고 있긴 한데, 대체 어떤 점이 좋은지 모르겠습니다. 그냥 사용하는 것보다 적절하게 응용할 수 있는 능력이 필요한데, 아직 수준 미달이라 그냥 학습한 것을 적용하는 수준밖에는 안 돼요. 모든 프로그램에 디자인 패턴을 사용하면 좋나요?

이 질문은 다음의 책자로 대신한다. 패턴과 리펙터링에 대한 좋은 로드맵을 받을 수 있다.
필자는 이 책을 사서 지나가는 후배를 빌려주는 바람에 얼마전 다시 한번 구입하기도 했다.
오늘 RSS를 확인해 보니 이 서적으로 스터디를 시작한 곳이 있다. 파이팅하길.~

패턴을활용한리팩터링
카테고리 컴퓨터/IT > 컴퓨터공학 > 디자인패턴
지은이 조슈아 케리에브스키 (인사이트, 2006년)
상세보기


디자인 패턴을 학습해서 사용하는 것은 좋은데 패턴자체를 무조건 맹신하는 태도는 좋지 못하다.
필자도 예전엔 프로그램에 디자인 패턴을 도입하면 그 자체로 개인이나 팀의 가치를 올릴 수 있다고 생각했다. 그래서 디자인패턴을 수시로 난발했다. 이 관점을 버리기까지 많은 시간이 필요했는데 실제로 쓰지 말아야 할 곳에 디자인패턴을 적용하여 오히려 시간과 노력 그리고 복잡성만을 증가시켰던 경험을 해 보았기 때문에 패턴사용의 무조건적 맹신에 대해 그다지 찬성하지 않는다.

"따라서 Refactoring to Patterns을 읽을 때 상당히 공감된 부분이 많았고, 깊은 감명을 받았다."

한번은 팀 내에서 PDF를 출력하는 개발을 하고 있었다. 이때 사용했던 라이브러리는 Apache iText였는데 다단계 계층의 컨덴츠를 손쉽게 산출하기에 좋은 API로 구성되어 있었다. 난 이 라이브러리를 가지고 같은 팀 내의 개발자와 짝 프로그래밍과 리팩터링(SS의 wonbo님^^)을 하면서 지속적으로 유틸리티 모듈을 만들어내고 개정하고 있었다. 결국, 공통의 슈퍼클래스와 여러 개의 서브클래스로 구성된 하나의 모듈이 완성되었다. 서브클래스로 구성된 것들은 객체의 생성은 각각 달랐지만 엘리먼트를 생성하는 알고리즘은 비슷했기 때문에, 객체를 생성하는 createObject(Object... object) 메소드를 move method로 슈퍼클래스로 이관시켰다. 그리고 그것을 abstract로 변형시켰고 슈퍼클래스는 자동으로 추상클래스가 되었다. 이것을 상속한 서브클래스는 createObject만 제정의 하면 나머지는 알아서 처리해주는 소위 Factory Method 패턴으로 승화시켰다. 다시 생각해보면 그 모듈은 더 이상의 서브클래스는 필요 없었을뿐더러 추가로 발생하는 요구사항도 없었던 것이다. 오히려 Factory Method를 사용해서 시간과 노력을 낭비한 사례라고 볼 수 있다.

실제로 위와 같은 실수는 정말 많았다. 적절하게 사용했다고 자부했던 코드들도 나중엔 분명히 수정을 가해야 했으니, 제3자의 평가가 없는 곳에선 그것들 적절하게 사용했다고 볼 수는 없다.

패턴 사용의 노하우를 키우기 위해선 실무에 활용했던 경험이 필수다. 그래야만 적절한 곳에 적당한 패턴을 도입할 수 있게 된다. 물론 나조차도 아직까지 이런실수를 하고 있고 앞으로도 그럴것이다. 하지만 예전 패턴을 맹신했던 어릴적 시절보다 지금은 더 현명하게 패턴을 사용하고 있다고 생각한다. 패턴의 진정한 승부는 실수를 통해 시기적절하게 사용했을 때 그 빛을 달한다. 어떤 무술의 고수가 정권찌르기를 하루에 만번이상 연습하는 것처럼 패턴사용도 수십 번 혹은 수천 번 사용해서 실수를 경험해 봐야 진정한 설계/개발자로서 거듭날 수 있지 않을까?



1. 디자인패턴은 습관적인 리펙터링을 통해 점진적으로 개선 / 발전할 수 있다.
2. 리펙터링과 디자인패턴은 상호보완 관계
저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

[학습] 가장 기억에 남았던 질문 BEST ③

Posted at 2010.09.27 17:50 // in Project Life // by MOOVA 무바㏇
3. 개발공부를 어떻게 해야하나요?

여러 선배의 코드를 보면 제각각입니다. 그냥 복사해서 붙여 넣은 사람들이 대부분이고, 프레임웍을 사용한 프로젝트에서는 개발자 개개인의 코딩 특색은 점점 사라지는 것 같아요. 프로젝트에 코딩 규칙이라고 정해놓았지만, 그것도 자신의 코딩 실력을 키우는 데는 별로 도움을 못 주는 것 같아요. 정교한 코드를 만들어서 남들이 볼 때 참 잘 만들었다는 느낌이 들 수 있도록 실력을 키우고 싶은데, 어떤 노력을 해야 하는지 궁금합니다.

그동안 수십번씩이나 개발자로부터 받았던 질문 중 하나에 속한다. 사실 이 질문을 접했을 때 본인은 얼굴이 붉어졌다. 개인적으로 생각할 때 그렇게 최고급 수준의 질 좋은 코드작성 능력은 모두 국외 오픈소스로부터 배운게 전부이다. 그래서 남들보다 월등한 코딩 실력을 갖고 있다고 생각지는 않다.한국개발자들의 코드의 수준은 잘 모르겠지만, 매번 연습했던 해외 오픈소스에서 쏟아져 나오는 질 좋은 코드들을 보고 항상 고개를 숙였던 그런 나였기 때문이다. 하지만, 주변사람들과 선배들이 오승택이는 개발하나는 딱 부러지게 했었다는 평들이 많았기 때문에 그 힘을 빌려서 몇 자 적어보고자 한다.

본인이 생각할 때 개발자들은 코드를 작성 하는것에 너무 집중한다고 생각한다. 창조적으로 코딩하든, 복사해서 붙여넣기로 코딩하든, 분기문이나 루프문 메소드 생성규칙만 알면 누구나 쉽게 개발을 할 수 있다. 하지만, 저 사람이 '개발을 잘 한다'는 타이틀은 얻기 어렵다. 왜 그럴까? 코드를 작성하려는 노력만 기울이다 보면 어느새 자기만의 세계에 빠지기 십상이다. 내가 잘하는지 못하는지도 모른 채 평생을 그 자리에서 맴돌 뿐이다. 운이좋아 코드리뷰나 짝 프로그래밍을 할 때는 쉽사리 동조하거나 함께 가려는 사람은 매우 드물다. 왜 그럴까?

본인이 신입 개발자나 이 일을 막 시작한 이들에게 강조하는 것은 코드를 작성하는 노력보다 코드를 분석하는 것에 더 많은 시간을 투자하라고 한다. 국외 오픈소스를 분석하면 단기간에 자신의 코드의 질을 향상할 수 있다고 장담하기 때문이다. 사실 국외 오픈소스의 코드의 품질은 세계적인 명석들이 작성한 것도 많으므로 그것을 눈앞에서 볼 수 있다는 것을 영광으로 생각해야 한다.그래서 최근엔 주변개발자들이나 후배들에게 국외 오픈소스코드를 다운로드 받아 실제로 그 짜임새가 어떻게 구성되어 있는지 분석하라고 당부한다.

두 번째 해야 할 일은 리팩터링의 연습이다. 코드에서 냄새가 날 때 바로 리팩터링할 수 있는 습관을 들여야 한다. 너무 잦은 코드의 수정은 별로 좋지 않은 습관이지만 주기적으로 적당한 리팩터링을 해 나가면 개인의 깨달음 수준에서도 그렇고 제품의 품질면에서도 보장할 수 있는 수준의 코드를 생성해 낼 수 있다. 

세 번째는 주변 실력있는 개발자들의 코드를 분석하는 일이다. 가끔 주화입마에 빠진 개발자들을 만나면 꼭 그들의 코드부터 살피자. 분명히 값어치 있는 코드 기법들이 쏟아져 나올 것이다.

네 번째는 코드의 품질을 높일 수 있는 서적을 참고한다. 본인이 가장 기억에 남았던 관련된 책으로는 Code Complete, Refactoring, Pattern and Refactoring, Design Pattern(GOF)을 꼽는다. 원리와 기초 사상이 중요하다는 것은 아무리 이야길 해도 지나치지 않다. 리팩터링 관련된 서적은 몽땅 읽어보는 것이 좋다.:)

다섯 번째는 자신의 코드를 주변개발자들과 검증을 통해 개선하는 일이다. 완벽할 수 없는 게 사람이다. 아무리 명석한 두뇌를 가진 사람이라도 실수는 하게 마련이다. 피로와 멍한 상태의 잔존기운이 남아 있을 때 주변 개발자들에게 요청하자. "내 코드 좀 봐 주시겠습니까?"하고 말이다. 절대로 창피한 일이 아니다. 오히려 멋진 일이고 회사의 입장과 개발자끼리의 입장까지 고려한 아주 용기있고 지혜있는 일이라 생각한다.

2010:09:25 07:00:07
그림출처 : 구글

아래의 추천서적은 필자가 적극 추천하는 책이다. 필자도 가끔씩 기억이 가물가물할때 찾아 빼서 읽어보는 소중한 책들이기 때문에 개발에 종사하는 사람이라면 꼭 한번 필독하길 바란다.

리팩토링
카테고리 컴퓨터/IT > 프로그래밍/언어 > 어셈블러/컴파일러/포트란
지은이 마틴 파울러 (대청미디어, 2002년)
상세보기

CodeComplete
카테고리 과학/기술 > 컴퓨터 > 소프트웨어
지은이 McConnell, Steve (Microsoft, 1970년)
상세보기

실용주의프로그래머
카테고리 컴퓨터/IT > 프로그래밍/언어 > 프로그래밍일반
지은이 앤드류 헌트 (인사이트, 2007년)
상세보기

ASPECTJINACTION(엑스퍼터J)
카테고리 미분류
지은이 RANNIVAS LADDAD (그린(윤덕우), 2005년)
상세보기

패턴을활용한리팩터링
카테고리 컴퓨터/IT > 컴퓨터공학 > 디자인패턴
지은이 조슈아 케리에브스키 (인사이트, 2006년)
상세보기

PragmaticUnitTestingInJavaWithJunit
카테고리 과학/기술 > 컴퓨터 > 프로그래밍
지은이 Hunt, Andy/ Thomas, Dave (O'Reilly, 2004년)
상세보기

GOF의디자인패턴
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 ERICH GAMMA 외 (피어슨에듀케이션코리아, 2002년)
상세보기

자바디자인패턴과리팩토링
카테고리 컴퓨터/IT > 컴퓨터공학 > 디자인패턴
지은이 박지훈 (한빛미디어, 2003년)
상세보기

소프트웨어개발의지혜(AGILESOFTWAREDEVELOPMENT)
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 로버트 C.마틴 (야스미디어, 2004년)
상세보기



기타 해드 퍼스트 시리즈와 The Pragmatic Programmers시리즈를 적극 추천한다.
저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

[상세함] 가장 기억에 남았던 질문 BEST ②

Posted at 2010.09.27 13:34 // in Project Life // by MOOVA 무바㏇
2. 빠르게? VS 상세하게?

우리팀은 소스관리를 하지 않습니다. FTP에서 소스를 내려받아 수정하고 컴파일해서 올리는 수준이라, 다른사람과의 마찰이 상당히 많습니다. 그런데도 불구하고 이 체계를 고치려하지 않습니다. 심지어는 자신이 해야할 코드조차도 남에게 보여주기 싫어 개발자 개별마다 눈치를 보며 코드를 올리지 않습니다. 이런분위기에서 상세하게 설계를 하고 구현작업까지 잘 할 수 있을지 의문입니다. 기간은 촉박한데, 상세하게 해야할 설계도 덕지덕지 붙여서 작업하고 있습니다. 점점 팀이 막장을 향해가고 있습니다. 어떻게 해야 할까요?

2010:09:24 20:20:59

프리랜서 친구가 질문했던 내용이다.
위와 같은 분위기는 본인도 수차례 경험해 본적 이 있기 때문에 그 속에서 일한다는 것이 얼마나 비생산적인지 글을 읽는 사람도 공감할 수 있을 것이다. 만약 저런 상황에 자신이 프로젝트리더라면 어떻게 해야 할까? 본인이라면 문제점을 정리하고 우선순위를 부여해서 이슈들을 하나하나 제거해 나갈 것이다. 단 일정이 촉박하지 않다면 말이다. 일정이라는 것은 정말 중요하다. 일을 빠르게 해야하는 것과 상세하게 해야하는 결정도 이 일정이라는 것이 항상 연루되어 있기 때문이다.

기간은 3개월인데 고객이 요구했던 기능은 너무 벅차다. 그래서 상세하게 해야하는 일엔 소홀해지고 오로지 빠른 속도로 일을 마무리 해야할때가 바로 이런때다. 차 후 유지보수나 확장성, 재사용성과 관련된 부분은 나중 이야기다. 일정이 촉박하니까 상세한것 보다 빠른 것에 집중한다. 대부분 이런 환경속에선 우리의 고객은 빠른 결과물을 보기 원한다. 이런 경우 일정을 조율할 시간도 없다. 때론 O군이라는 엔지니어는 이런 환경속에서도 제대로 틀을 잡고 진행하려고 애를 쓴다. 아무리 기간이 짧아도 더욱 상세하게 설계작업을 했을 때 나중에 퍼포먼스가 몇 배나 나온다는 경험때문이다. 하지만, 이것은 어디까지나 이례적인 일이다. 컨설턴트나 SE가 아닌 개발자들은 이렇게 미련한 시도는 하지 말자.|=)

반면 기간이 1년이상이라고 해보자. 제대로 된 회의를 통해서 요구사항을 정제할 수 있다. 특징을 분석하는 일, 기능요구사항과 비기능요구사항을 사전에 정의하는 일, 테스팅과 테스트 시나리오, 용어사전, 개발환경의 선택, 콘텍스트 맵 정의, 공통규격과 표준정의. 교육, 설계리뷰,코드리뷰, 팀 미팅, 분할된 아키텍쳐 정의등등등.. 소프트웨어와 관련된 수많은 단계와 프로세스를 채택할 수 있다. 이런 환경은 정말 행복한 환경이다. 굳이 구현작업을 빠르게 해야 할 필요도 없고 각 단계별로 해야 할 일을 종종 찾아오는 병목현상을 제거하면서 적당히 끝내두면 그만이기 때문이다. 이런곳은 배울점도 많을뿐더러 자신의 캐리어를 상승시킬 수 있는 아주 행복한 곳이다. 한가지 강조하고 싶은것은 큰 프로젝트같은 경우 콘텍스트 맵을 제대로 개선해야 할 필요가 있다는 것인데, 적당한 문맥툴을 도입하면 프로젝트의 문맥을 손상하지 않는 범위내에서 점진적으로 확장 또는 개선해 나갈 수 있다.

빠르게 해야 할지 상세하게 해야 할지는 주변의 상황을 고려한 본인의 선택에 달려있다.
두  가지를 선택하는 갈림길에 앞서 가장 신경 써야 할 부분은 일정이라는 점을 기억하자. 저질 같은 일정이라도 일정은 일정이다.


"가끔씩 두마리의 토끼를 잡으려 하던 미련한 소프트웨어 엔지니어가 한 명 있기도 하지만.."


참고 : 프로젝트에 콘택스트 맵 개선에 효과를 볼 수 있는 툴

저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

[프레임웍] 가장 기억에 남았던 질문 BEST ①

Posted at 2010.09.27 13:34 // in Project Life // by MOOVA 무바㏇
1. 프레임웍을 사용하고 있지만....

최신 웹 프레임웍을 쓰고 있긴 하지만, 어느정도 시간이 지나면 기술에 대한 흥미가 줄어듭니다. 프로그램 성격상 데이터베이스에 넣고 빼는 것이 전부이기 때문에 반복되는 업무가 지겨워진 것도 한 몫합니다. 웹프로그램에 MVC패턴을 쓰긴 쓰고는 있는데, 그것도 '요청>결과확인'이 전부아닌가요? 요청과 결과확인 x3 ;;;; 항상 똑같습니다. ㅠㅠ

2010:09:24 20:24:45

프로젝트 진행중 친한 후배가 진심이 담긴 표정으로 던졌던 질문이다. (이 질문은 프로젝트에서 수 차례 접했던 질문중 하나에 속한다.) 최신 기술을 쓰고 있긴 한데 디비에 인풋하고 아웃풋하는 반복되는 업무때문에 좀처럼 일의 능률을 올릴 수 없다는 것이었다. 하지만 이 정도 질문을 하는 사람이라면 충분히 생각을 하고 일을 하고 있다는 반증이기도 한데, 역시나 나 조차도 그런 반복되는 일상을 잘 알고 있기 때문에 동질감을 느끼면서 소프트웨어 구조에 대한 이야기를 잠깐 해 주었다.


2010:09:23 22:58:45

그림1. 정형화된 웹MVC

그는 술자리에서 푸념을 늘어놓으면서 벽에 가상의 그림을 그렸다. 일반적인 요청에 결과값을 리턴받는 구조이다. 어떤 요청이라도 콘트롤러를 거쳐야 하며 디비조회 후 생성된 모델을 뷰영역까지 운반하는 정형화된 패턴이다. 이 때 차용했던 이 패턴은 오픈소스의 Best Practice에서 그대로 배껴 가져왔다고 한다.  바로 위와 같이 구축해 놓은 정형화된 패턴 때문에 일이 너무 반복적이고 배울게 없다는 그의 한탄이었다. 어떻게 설명하려 고민하다가 위와같이 정말 재미없는 구조에 넌지시 한가지 도형을 추가했다.

2010:09:23 23:21:50

그림2. 웹MVC에 추상 컴포넌트를 추가한 모습

그가 알고 있는 웹개발영역(티어를 나누어 놓은 개념)위에 좀 더 크게 시야를 확보할 수 있는 추상 기능단위인 콤포넌트를 손으로 그려주면서 웹애플리케이션은 잘만 설계된다면 단순히 요청에 값을 확인하는 일뿐만이 아니라는 것을 지적했다. 사용자가 요청을 하면 매번 디비에서 조회해 오는 단순한 그림을 지우고 애플리케이션 영역에서 작은 기능들을 합치고 분류하면 좀 더 크게 생각의 영역을 그룹지을 수 있는 중요함을 설명했다. 그러자 그 친구의 얼굴에 화색이 돌았다.( 그때 이 후배는 다른이보다 좀 더 이해도가 높은 모습을 보여주었다. 항상 생각하고 일을 하는 그의 근성때문이리라 )

그 친구는 이 하나의 그림으로 설계와 개발이란것이 단순히 요청에 대한 값 확인이 아니라, 보다 응집된 애플리케이션의 모습으로 구축될 수 있다는 희망을 얻었다.  그가 경험하고 있었던 반복되는 일상의 지루함에서 좀 더 가치있는 영역을 탐독할 수 있는 탈출구가 되었으리라 본다. 본인이 의도했던 것은 OOAD의 자세한 단계와 리펙터링 또는 패턴의 발판단계를  설명하려 했지만 이 질문에 포괄적인 답변을 몇마디로 압축하기가 매우 곤란했다.

아마도 이 친구는 그 때 추천해 주었던 서적과 관련된 사상(OOAD,패턴,소프트웨어정제기법)으로 몇 년간 바른 로드맵[각주:1]을 걷고 있었을 지도 모로겠다.

2010:09:24 20:36:50


사실 위의 개념을 제대로 알기 위해선, 소프트웨어 아키텍쳐와 방법론에 대한 지식, 디자인패턴과 프레임웍,OOAD에 대한 충분한 학습이 필요하다. 하지만 위의 추상컴포넌트 그림으로 앞으로 무엇을 해야할지 발판을 마련해 주었다고 본다. 우리가 일하는 영역은 단순노무가 아니란 점, 그리고 시야를 점점 확장하면서 점진적으로 커 나갈 수 있는 정말 값진 일을 하고 있다는 것을 깨달았으면 좋겠다. 단, 개개인의 발전을 수용할만한 곳이 별로 없다는 것이 흠이긴 하다.




그림3. OOAD
저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

좋은 꼴값 한번 떨어보자.

Posted at 2010.09.27 12:58 // in Fun Data // by MOOVA 무바㏇
종종 우리는 사물의 겉모습을 보고 '꼴'이라는 단어를 쓴다. '저 모습', '이 모습'을 보고 부정적인 어조를 섞어놓아 '저 꼴', '이 꼴'이라 말한다. 흔히 '꼴'을 포함하는 말은 비아냥 섞인 말이라던지 부정적인 의미를 담아 많이 쓰고 있다. 하지만, 이 '꼴'이 사물의 표현을 넘어서 사람을 지칭하게 되었을때는 좀더 색깔있는 의미로 변형될 수 있다.

우리는 "저 꼴을 봐라" 혹은 "꼴 값을 떤다" 라고 흔히들 말한다.

그렇다면 꼴값이라는 것은 무엇일까? 사람의 '꼴'은 바로 사람의 겉모습이나 그 사람을 대표하는 얼굴이 된다. '저 꼴이 추하다', '꼴이 보기 좋다'. 라고 하는 말은 대체로 그 사람의 얼굴을 보고 하는 말이 된다. 그렇다면 얼굴이 잘생겨서 '꼴'이 좋다고 할 수 있을까? 또한, 얼굴이 못생겨서 '꼴'이 추하다고 할 수 있을까? 곰곰이 생각해 보면, 얼굴이나 사람의 외관만을 보고 그 사람의 '꼴'을 판단할 수는 없을 것이다. 그렇다면 우리가 사람에게 사용하는 이 '꼴값'이라는 말은 자연스레 얼굴로 비치는 그 사람의 품(品)에서 비롯된다고 볼 수 있다. 품이란 우리말로 꼴이라고 말한다. 그리고 품격이란 그 사람의 됨됨이를 말한다. 품질 혹은 품격이 좋다는 것은 사람의 겉모습이 아닌 내면의 아름다움이 자연스레 풍겨나왔을 때 제대로 된 '꼴값을 한다'고 볼 수 있다.

얼굴을 치장하고, 명품으로 자신의 품을 숨기고, 좋은 음식을 먹고, 좋은 직장을 다니면 꼴이 좋다고 볼 수 있을까? 결코, 그러할 수 없다. 꼴은 그 사람의 품이므로 사람의 외관만으로 그 사람의 품을 표현하는 것은 아니기 때문이다. 꾸미고, 치장하고, 과도하게 홍보하고.. 우리는 쓸데없는 시간낭비의 망각에너지 속에서 허우적대고 있을지도 모른다. 요즘은 왜 자연스럽게 꼴값을 하는 사람을 좀처럼 볼 수 없을까? 외관을 짐짓 꾸미는 것보다 자신의 내면을 강하고 온화하게 가꾸며, 본질을 보고 달려갈 줄 아는 사람만이 진정한 꼴값을 떤다고 할 수 있지 않을까? 제대로 꼴값을 떠는 사람은 가만히 있어도 후광이 비치게 마련이다, 입은 옷이 남루하고 허름해도 전체의 품격과 됨됨이는 진국이라는 이야기다.

하지만 이 시대, 우리 땅에서는 제대로 된 꼴값을 떨기가 정말 힘들다. 
얼마 전 명품4억녀의 소동이 일어났다. 그녀는 자신에 몸에 두른 명품만 해도 무려 4억이 넘는다고 포장하고 나왔는데, 지금은 방송국의 단순한 대본이었다며 다시 한번 방송국에 소송을 걸었다. 누구말이 맞는지는 잘 모르겠지만 이 시대를 풍자하여 웃게 만든것이 아닌 씁쓸한 사회상의 단면을 반영한 모습이라고 볼 수 있다. 그녀는 꼴값을 잘 떨었을까? 

두 번째는 신정환과 관련된 이야기다. 연애인 한 명이 도박에 연루됐다고 TV며 신문에 떠들썩하게 나왔던 장면을 보고 우린 다시 한번 곱씹어 볼 필요가 있다. 그 사건이 그렇게 이슈가 되어야 할까? 지금 정치판에 앉아 있는 사람중 많은 사람들이 내부적 암묵의 범법자인 것은 하늘이 다 아는 사실이다.  또 기업인들은 어떨까? 돈이면 다 되는 세상에서 범죄행위하나 감추려고 행언을 돈으로 사고 팔고 있다. 그럼에도 불구하고 그 범죄행위는 기사의 일면에 TOP으로 나오진 않는다. 이 시대를 이끌어나가는 리더들의 범법행위는 묵인한채 방관만 하고, 그깟 연애인 한명이 도박 몇 번 했다고 광적인 집단 이기주의로 변모하여 한 사람을 도마위에 올려야 할까? 정말 미친짓이다.

그리고 곰곰이 생각해 볼 일이다.


재차 이야기하건데, 지금 이 시대는 제대로 된 꼴값을 떨기가 무척 힘들다. 옳고 그른것도 범법적인 행위로 빛을 잃어 간다. 오히려 그런 범법행위들이 찬사를 받고 있는 현실이니, 제대로 된 가치를 표현할 수도 없는 노릇이다. 그런것들이 통용될 수 없는 사회니 앞으로 웃을 수 있는 날이 그리 많지는 않은 것 같다. 하지만, 한가지 희망이 있기에 우린 웃어야 할꺼다. 좋은 꼴값을 떨기 위한 날이 반드시 오리란  희망과 소수의 노력이 아직도 부단하게 움직이고 있기 때문일 것이다.


저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

2010년 9월 15일, 미투데이

Posted at 2010.09.16 10:30 // in SNS // by MOOVA 무바㏇
  • 항암칠차중 .. 이터레이션의 감사함(me2mms me2photo) #

    me2photo

  • 심심할까봐 병원에 싸들고온 '50번째 법칙' 별로 재미는 없다만…(me2mms me2photo) #

    me2photo

이 글은 moova님의 미투데이 내용입니다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'SNS' 카테고리의 다른 글

2010년 10월 6일, 미투데이  (0) 2010.10.06
2010년 9월 27일, 미투데이  (0) 2010.09.28
2010년 9월 15일, 미투데이  (0) 2010.09.16
2010년 9월 14일, 미투데이  (0) 2010.09.15
2010년 9월 13일, 미투데이  (1) 2010.09.14
2010년 9월 12일, 미투데이  (1) 2010.09.13
블로그코리아에 블UP하기

댓글을 남겨주세요.

[재활로그] 7차를 시작하며. 인생정말 감사하다.

Posted at 2010.09.15 22:19 // in Associate // by MOOVA 무바㏇
6차진단결과 상태 이상 무를 확인하고 다시 한 번 예방차원의 남은 치료를 받으러 병원에 들어왔다.
치료를 받으면 한 차례 컨디션이 10일정도 완전히 다운 됐다가, 11일이 지나면 다시 컨디션을 되찾는다.
신기할 뿐...

이렇게 내 몸을 이터레이션 돌리니 중간마다 요령도 생기어 어느정도 적응이 된다. 신기하다.
빡빡한 차수에 대한 이터레이션 속에 부담감도 반복되는 일상 속에 스스로 키우는 적응력을 확인하다니.. 사람의 몸이란 이렇게 신비한 것이다.

현재 한 업체에 원격에서 정보컨설팅을 해 주고 있는데(물론 보상은 받고 있다.) 이렇게 병상중이라도
할 것은 하는 게 매우 위안이 되고 감사하다고 생각한다. 계속 일을 하다가 쉬게 되면 며칠은 참을 수는 있다. 하지만, 그것도 잠시뿐이다. 회도 먹어본 사람이 그 맛을 잘 안다고 일도 쭈욱 한 사람이 일의 즐거움을 아는 것이다.


"감사함.."

얼마 전 한국 IT환경의 악폐에 대한 것에 반추해서, 획기적인 프로세스를 개발하고 그것을 자사에 활용하겠다고 한 Subin대표님이 전화를 주셨다. 대기업에서 붙잡았던 좋은 요건에도 벤처를 차리신 Subin대표님이 다시 한번 강조한 이야기가 떠오른다. "능력껏 보상받고, 행복하게 일하자. 일에 대한 가치만큼 받고, 충분히 잘하는 이가 인정받을 수 있는 회사를 만들자." 이 맨트와 더불어서 진심으로 많이 걱정해 주심에 다시 한번 감사를 드린다. 쪽쪽 피 빨아먹고 내팽개치는 그런류의 대기업의 횡포와는 차원이 다른 사람이다.

나에게 지속적인 열정을 불어넣어 주신 종광 T에게도 병상중에 아직 열정을 잃지 말라고 조언해 준 것에 감사함을 느낀다. 그분은 아직까지 개발이 좋아 재야에서 썩고 있는 인재분이다. 쉽게 자신을 내놓지 않으려하며 자기 주변의 인물들에게 꾸준히 그리고 지속적으로 적당한 조언과 충고, 그리고 열정을 유지할 수 있도록 도와준다. 정말 진정한 선의를 할 줄 아는 선배다.

나아게 아키텍트적인 자질을 키워줬던 PTC사람과 STX사람들에게 감사하다. 프레임웍을 넘어서 도메인특화가 무엇인지, 진정한 MDA와 MDD가 무엇인지, 실전 OO가 무엇인지 적지 않았던 기간에 폭넓은 사고를 주었던 영역이다. 비단 기술적인 도움은 없었더라도 정모PM(ProgramManagaer), 양차장님, 노부장님, 안대리님에게 감사함을 표한다.

다시한번 만나서 행복하게 일할 수 있는 여건을 만들어 주시려하는 윤수석님에게 미처 연락을 못 드려 죄송하다는 말을 드리고 싶다. (하지만 삼성은 내가 있을 곳이 아니다. 이렇게 여운을 남기는것도 좋은 방법중에 하나이다.)

CCC형에게 감사하다. IT란 무엇인가에 대해 10년전부터 영감을 주셨던 분이다. 참 어려웠을 때 물질적으로나 심적으로 조언을 주셨던 분이다. 닉네임은 CCC지만 한국 인터넷 서비스업계에 네임밸류가 있는 분이다. 역시 재야의 고수는 가만히 있어도 빛을 발한다.

종광T,기흥T,청훈T
내 열정을 유지하게 해주어 정말 감사하다. 설령 기술적으로 그들에게 배운것은 없다 하더라도 난 그들의 인간미를 인정하고, 진짜 선배가 무엇인지 깨닫게 해준 분들이라, 다시한번 화이팅을 날린다.
아무나 선배가 되고 아무나 알짜배기가 되는 것이 아니다. 후배를 이해하고 정말 어려운 환경에도 따뜻한 말 한마디 건네는 사람이 정말 인간미가 되어 있는 선배이다. 어려움을 경험했던 사람만이 후배의 어려움을 잘 아는 것이다. 내가 후배를 아끼고 좋아하게 된 습성은 모두 이분들에게 배웠다. 그 좋은 사상을 물려 주어야한다.

기타 나와 같이 공부하고 같이 놀고 같이 울고 같이 싸고 같이 먹고 한 모든 사람들에게 감사하다. 또한 긍정적인 사고를 심어주려했던 분들에게도 정말 감사하다

앞으로, 예전과 같이 여러 대기업을 주 무대로 무한 도전을 할 수 있을지는 의문이다. 그 열정이 아직도 내 맘속 미련함으로 남아 있다. 하지만 그것 어디까지나.. 남아 있는 욕심일 뿐이다. 현실을 인정해야 한다.

야구선수가 야구를 할 수 없다면 그만한 고통도 없겠지만..  사람은 버릴 때 미련없이 버릴 줄도 알아야 한다. 그래야만 그 비워진 그릇에 다른 열정을 집어넣을 수 있을 테니까.

바쁜와중에 항상 연락해 주고 지방까지 찾아와주는 
석필,허덕,건헌,경우,성수,홍식,성범,미진,태범,연호,유선,미옥,경호,영만,동춘,민우,동현,만기햄,은제,지혜,보라,밤가시,석임햄,선피리,승훈,성수,지택,기택,진택,효상,영상햄,정헌,태진에게 고맙다. 정말 친구와 동료와 후배에 대한 존재를 다시 한번 생각하게 해 주는 그런 사람들이다. ( 이 곳에 없는 친구들까지 포함해서~~ )

그리고 내 가족, 친척들.. 이분들은 감사함은 아무리 말을 해도 지나치지 않다.
너무나 확실하게 솔직히 명확하게 종종 때때로 기가막히게 감사하신 분들이다.

그리고 결정적으로 시야를 넓게 확보해준 내 책들에게 감사하다.


"참 인생 정말 즐겁다 까꿍~~**"
저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기
  1. Favicon of http://architect.tistory.com BlogIcon 짱가

    2010.09.16 10:05 신고 [수정/삭제] [답글]

    이런말이 경우에 맞는지는 모르겠지만,,,
    승택님은 정말 행복한 사람인것 같습니다. ^^
    삶에 대한 열정과 사람에 대한 사랑, 신뢰....
    본받고 싶네요

댓글을 남겨주세요.

2010년 9월 14일, 미투데이

Posted at 2010.09.15 10:31 // in SNS // by MOOVA 무바㏇
  • 미안한데..스프링은 그들은 만나기 3년전부터 연구해왔던 과제임. 블랙박스와의 조합을 위해서:) #

이 글은 moova님의 미투데이 내용입니다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'SNS' 카테고리의 다른 글

2010년 9월 27일, 미투데이  (0) 2010.09.28
2010년 9월 15일, 미투데이  (0) 2010.09.16
2010년 9월 14일, 미투데이  (0) 2010.09.15
2010년 9월 13일, 미투데이  (1) 2010.09.14
2010년 9월 12일, 미투데이  (1) 2010.09.13
2010년 9월 12일, 미투데이  (0) 2010.09.12
블로그코리아에 블UP하기

댓글을 남겨주세요.

통일장 이론의 한계

Posted at 2010.09.14 11:54 // in Principle // by MOOVA 무바㏇
아인슈타인은 죽기전까지도 통일장이론[각주:1]을 완성하려 했다.

모든 물리학 법칙에 적용되는 이론을 단 하나의 이론으로 설명하기 위함이었다.
과학자들은 어떤 학문을 연구할 때 그것과 관련된 파생된 연결고리를 묶어서, 통합된 하나의 이론으로 설명하려고 하는 이상과 목표가 있다고 한다. 그들이 목표로 삼고 있는 통일장 이론...
그들이 생각하고 있는 것 처럼 전혀 연관성 없는 학문도 하나의 이론만으로 설명되어 진다면 얼마나 간편하고 위대해질까?

일전의 포스트에서 신과 태양의 관계를 설명하면서, 태양을 알기 위해서 태양을 연구하는 것이 얼마나 바보같은 행위인지 설파했다. 태양자체를 연구하는 광적인 광신도의 행위보다 태양이 가져다주는 편의성과 행복감을 느낄 수 있으면, 그 힘의 존재를 그저 인정하게 된다는 말이었다.

적절한 예시였다고 생각한다.

우리가 어떤 목표로 갈 때 우리는 우리의 잣대로 사물을 판단하고 이해하려한다.
만약 어떤 것이 진리인 양 사람들을 현혹하고 있다면 진실을 쫓는 사람은 그 본질을 쫓기 위해 그 자체를 연구하려 들것이다. 하지만 이것은 시간 낭비다. 자신의 시야만 편협해질 뿐이다. 자신의 울타리 내에서만 통일을 시도하려 하는 것이다. 정작 자신은 통일장 이론이라고 주장하겠지만, 이것은 어디까지나 한 울타리내에 통일장 이론에 불과하다. 더 높고 넓은 시야를 볼 의지가 있다면 그 자체의 본질만을 따지지 말고 한차례 뒤로 물러서서 조용히 흘러가는 구름들을 관찰하기 바란다. 그렇게 된다면 나와 내가 속한 공동체가 얼마나 비굴하고 역겨운지 또는 얼마나 우물안 개구리였는지 깨닫게 될 수 있을 것이다.

2010:09:14 11:26:14

통일장이론을 완성하려고 했던 아인슈타인

자신만이 갖고 있고, 설법하려 했던 이론들이나 지식은 이미 누군가가 현실에서 써먹었다고 생각하면 된다. 마치 자신이 어떤 금형서에 못으로 침을 박아 그 이론들이 자신에게만 나올 수 있는 것인양 착각하는 오류는 범하지 말기로 하자. 어느정도 홍보와 설법을 하는 것도 하나의 재주에 속하겠지만, 그것을 정리하게 된 계기나 시도가 마치 전부 자신이 했던 업적인양 착각하는 바보가 되진 말자. 대 부분 그러한 사람이 금형서에 새긴 문구들은 나 같은 피라미 조차도 이미 현실속에서 써먹고 알리려고 했던 지나가는 그저 일상생활과 이론에 불과했다.

멀찌감치 떨어져서 구경한번 해보자. 구경하는 자체가 얼마나 자신에게 넓은 시야를 가져다주는지 곧 이해할 수 있으리라. 만약 그런 시도 자체도 하지 못한다면,

"우린 언제나 도진 개진일 뿐이다."

# 무엇하나 했다고 해서 통일하려 들지말자. 자신이 가지고 있는 편협한 지식을 통일하려 하지 말자. 누군가는 때때로 그 상위에서 놀고 구경하면서 지켜볼 수도 있는 노릇이니까:)
# 온라인의 한계. 종종 누군가는 그 편협한 잣대 속에서 살아가고 판단하고 있다. 사람은 온라인에서  판단할 수 있는 그런 종류가 아니다.

  1. 통일장 이론은 자연계의 4가지 힘인 중력, 전자기력, 약한 상호작용 그리고 강한 상호작용을 통합하려는 시도의 대표적인 접근 방식이다.&#10;&#10;중력장과 전기장, 자기장 그리고 핵력장이 같은 근원을 지닌다는 자연 철학이다.&#10; [본문으로]
저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

2010년 9월 13일, 미투데이

Posted at 2010.09.14 10:30 // in SNS // by MOOVA 무바㏇
  • 비결은 Foreign Exchange. #

이 글은 moova님의 미투데이 내용입니다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'SNS' 카테고리의 다른 글

2010년 9월 15일, 미투데이  (0) 2010.09.16
2010년 9월 14일, 미투데이  (0) 2010.09.15
2010년 9월 13일, 미투데이  (1) 2010.09.14
2010년 9월 12일, 미투데이  (1) 2010.09.13
2010년 9월 12일, 미투데이  (0) 2010.09.12
2010년 9월 10일, 미투데이  (0) 2010.09.10
블로그코리아에 블UP하기
  1. Favicon of http://hanrace.tistory.com BlogIcon 꿈꾸던 시절을 찾아서

    2010.09.14 20:11 신고 [수정/삭제] [답글]

    미투데이가 뭐죠?트위터와 관련된 내용인가요?
    모르는게 많네요.ㅠㅠ

댓글을 남겨주세요.

[주말 가톨릭] 우리는 캐릭터일 뿐

Posted at 2010.09.13 16:52 // in Church art // by MOOVA 무바㏇
어느 러시아 우주인이 지구로 귀환하여 "하느님을 보지 못했노라"고 말했을 때, 루이스는 그건 햄릿이 셰익스피어를 찾겠다고 다락방엘 올라가는 거랑 다름없다고 일갈했다.

신이 존재한다 할지라도, 그는 실험실에 갖다놓고 경험적인 방법으로 분석할 수 있는 어떤 물체가 아니다. 극작가가 자신의 극에 등장하는 인물에게 말을 걸듯이, 신은 그렇게 우리에게 말을 건다. 캐릭터인 우리들은 극작가에 관해서 많은 것을 알지도 모르지만, 작가가 스스로에 대한 정보를 얼마만큼 연극 안에다 내놓기로 하느냐에 달려있다. 따라서 우리는 그 어떤 경우에도, 마치 완전히 우리 우주 안에 있는 산소나 수소 같은 물체라든지 태평양의 어느 섬처럼, 신의 존재를 증명할 수는 없다.

2010:09:13 16:49:11

믿는다는 것은 그 자체를 연구하는 일이 아니다.
그 자체를 연구하면 시력만 잃게되게 때문이다. 광신도들이 이에 속한다.

내가 태양이 떳다고 믿는 것은 단순히 눈으로 태양을 보기 때문만이 아니라, 태양으로 인해 만물을 보기 때문이다. 내가 신의 존재를 믿는 것도 꼭 같은 이치다. 태양을 연구하겠노라고 태양을 쳐다본다고 상상해보라. 그럴 수는 없다. 눈이 다 망가지고 시각 능력은 엉망이 될 테니까. 태양의 존재, 그 힘, 그 본성을 배우기 위한 훨씬 더 좋은 방법은, 태양이 보여주는 세상을 바라보는 것이며, 태양이 어떻게 눈에 보이는 모든 것을 부양하고 우리로 하여금 만물을 볼 수 있게 해주는지를 깨닫는 것이다.

그렇다면 신에 대해 정면으로 반박하는 행위가 얼마나 부질없는 짓인지를 깨달아야 한다. 우리는 이 세상 그 어느것도 성취할 수 없는 사랑과 아름다움을 동경한다. 우리는 의미와 목적을 알고 싶은 뿌리 깊은 욕망을 지니고 있다. 과연 세계관이 이런것들을 가장 속 시원히 설명해 주는 걸까?

만약 성경의 하나님이 존재한다면, 그는 벽장 속에 숨어있는 존재가 아니라 '삶의 극작가'이다. 경험론적인 조사를 통해서 수동적인 어떤 물체를 찾듯이 그 하나님을 찾을 수는 없다는 뜻이다. 그보다 우리는 그 신이 우리 영혼속에, 우주 속에, 써놓은 그의 실체의 단서를 찾아야 한다. 그렇기 때문에 신이 존재한다면, 우린 그가 우리의 합리적 기능에 호소함을 깨닫게 될 것으로 기대한다. 우리가 "그의 형상을 따라" 합리적이고 개별적인 존재로서 창조되었다면, 이 것을 또한 이성만으로는 충분치 않다는 의미다.

이 "극작가"를 알게 되는 것은 오로지 개별적인 계시에 의해서만 가능하다. 신과 인간조건에 대해 성경이 뭐라고 말하고 있는지를 봐야하는 이유가 여기에 있다.

우리가 알아야 할 것은 태양을 연구하는 일이 아니라 태양이 어떻게 세상을 밝히고 있는지 인정하는 것이다.
저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

티스토리 툴바